AnswerLens

Audit product pages, review the report, and fix what AI assistants cannot read clearly.

Language: English / 简体中文

CI handoff

Turn one useful local audit into a GitHub Action.

Use this page after the demo and one real-site run. It shows the files to copy, where secrets belong, and how to review the first CI result.

CI setup

Use these files after the local report makes sense.

The setup gives you the same report set in CI: site settings, competitors, prompts, runtime defaults, and a pinned Action.

  1. 1

    Run a real-site audit

    Start with one useful local audit so the reports already make sense.

    Open quickstart
  2. 2

    Copy the starter files

    Move the .github/answerlens files and workflow into the repository you want to audit.

    Open sources
  3. 3

    Set runtime defaults

    Keep non-secret eval defaults in runtime.yaml and keep provider keys in secrets.

    Open runtime
  4. 4

    Use the pinned Action

    Run the reviewed stable release tag in pull requests or workflow_dispatch runs.

    Open workflow

External repo layout

Setup files

.github/
  answerlens/
    brand.yaml
    competitors.yaml
    prompts.yaml
    runtime.yaml
  workflows/
    answerlens.yml

This is the same layout used by examples/consumer-repo.

File roles

What each file does

  • brand.yaml: product name, domain, proof-page hints, and optional site_display_name.
  • competitors.yaml: the declared comparison set for the category you actually sell into.
  • prompts.yaml: buyer, comparison, and citation questions for your real audience.
  • runtime.yaml: non-secret eval defaults for provider, model, locale, samples, timeout, and optional base URL.
  • answerlens.yml: the GitHub Actions workflow that runs AnswerLens in CI and uploads the same report files, pinned to the current stable Action release.

The current starter workflow uses YSCJRH/ai-visibility-auditor@v0.3.2; after a newer release, update that pin only after reviewing the release notes.

Keep API keys in GitHub secrets or local environment variables, not in runtime.yaml.

Review flow

Report review order

share-summary.md

Use this for the audit overview and PR summary.

scorecard.md

Use this to inspect coverage, checks, and scoring.

recommendations.md

Use this as the fix list after review.

Then use pr-snippet.md for GitHub copy and run.json for machine-readable metadata.

Public example

Starter example result

Example site: Example Product public site

This public example runs the starter files against the sample site so external teams can inspect the reports before wiring their own site.

Set up your repo

What to do next

After the files are copied, keep the first run intentionally small:

  1. Replace the example product, domain, competitors, and prompts.
  2. Set non-secret eval defaults in runtime.yaml and keep API keys in secrets.
  3. If you want the lowest-friction first eval before hand-tuning fields, start with profile: fast-first-eval.
  4. If you already have one readable OpenAI baseline and want a search-shaped second opinion, use profile: perplexity-cross-check as a temporary override.
  5. Move into GitHub Actions when the local run already feels reviewable.

What this connects to

Related proof pages

  • Examples: see the live demo report files first.
  • Docs: activation references, scoring notes, and canonical Markdown.
  • Integrations: see how the starter files fit into GitHub Actions.
  • Releases: use release assets as the second public front door.