AEO

---
name: aeo
description: "Build, measure and grow an Answer Engine Optimization program for a product or site. Finds out what ChatGPT, Claude, Perplexity, Gemini, Google AI Overviews and Copilot actually say about a brand, diagnoses why they say it, and ships the fix. Produces a dated report plus a step-by-step gameplan you can re-read months later. Use when the user mentions AEO, GEO, LLMO, AI search, answer engine optimization, generative engine optimization, AI visibility, AI citations, LLM mentions, AI share of voice, AI brand monitoring, llms.txt, AI crawlers, GPTBot, ClaudeBot, zero-click search, or asks things like 'why don't we show up in ChatGPT', 'what does AI say about us', 'how do we get cited by AI', 'optimize for Perplexity', 'are we blocking AI bots', 'do LLMs know what we do', 'get us into AI Overviews', or asks for an AI search audit, report or plan. Runs inside the app repo or the marketing site repo. Distinct from a keyword SEO audit (rankings and clicks) and from a content engine (writing one piece): this owns brand-level presence inside generated answers, across on-page, off-page and technical work."
metadata:
  version: 1.0.0
---

# AEO

Answer engines do not return a menu. They return a verdict. Ranking makes you eligible for that verdict. This skill decides whether you are in it, and what it says about you.

The unit of work is not a page and not a keyword. It is an **attribute**: one specific thing you want to be known for, in the words your buyers actually use. Every run moves attributes from where they are to where you want them.

Run this inside the repo where the product or the marketing site lives. Being in the repo is the advantage: the codebase is the only unambiguous source of truth about what your product does, what it costs, and what it integrates with. That truth is what you test the answer engines against.

---

## What it produces

Two durable artifacts, regenerated every run, plus the state behind them.

| Artifact | What it is |
|---|---|
| `.aeo/report.md` | The dated state of the world. Mention rates per attribute per platform, the citation supply chain, gaps routed to a cause, technical readiness, accuracy failures, crawl and referral data, and an explicit method section saying what was measured, at what sample size, and what was not. Written to be re-read in six months by someone who was not there. |
| `.aeo/gameplan.md` | The ordered, checkable action list. Every item names the finding it closes, the route it takes, the effort, the expected effect, and the exact file, command or URL. Grouped Now / Next / Later / Done, with the Done section carrying the ship date and the observed effect. |

The gameplan is the deliverable people act on. The report is the deliverable people cite. Neither is a wall of advice: every line traces to a number this skill measured.

---

## How a run works

Call it with no argument and it detects which phase the program is in, then runs the next needed one. Named modes override that.

| Mode | Does |
|---|---|
| *(none)* | Auto-detect and run the next needed phase |
| `setup` | Phase 0 only: config, truth file, identity, attributes |
| `audit` | Phases 2 and 3: measure, diagnose, write the report |
| `plan` | Phase 4 only: regenerate the gameplan from existing findings |
| `fix` | Phase 5: execute approved on-page and technical items |
| `remeasure` | Re-run the existing prompt set, diff against the last run, update the report |
| `report` | Rebuild both artifacts from stored data. Spends nothing. |

The phases:

```
0  Foundation    who you are, what you sell, what you want to be known for      once, then rarely
1  Prompt set    attributes become a portfolio of testable prompts              once, then quarterly
2  Measure       run the prompts, read the citations, crawl the site            every run
3  Diagnose      route every gap to a cause: technical, comprehension, trust    every run
4  Gameplan      turn causes into ordered, concrete actions                     every run
5  Execute       do the on-page and technical work, brief the off-page work     every run
```

Steady state is 2 through 5, then deploy, wait, and go again. Two to four weeks between measurement runs. Answer engines move slowly and daily readings are noise.

---

## Non-negotiable rules

These hold in every phase. Breaking one produces a confident wrong answer, which is worse than no answer.

1. **Never report a rate from one sample.** Answer engines are non-deterministic. One response is an anecdote. Sample size travels with every number you print, and `references/measurement.md` carries the margin-of-error table that says whether a change is real.
2. **Never ask a leading question.** "Which AEO tools are best, like [Brand]?" produces a worthless number. Measure the question a buyer would ask, not the answer you want.
3. **Never contact anyone.** This skill writes outreach briefs and punch lists. A human sends them. No emails, no posts, no comments, no review submissions, no third-party listing edits.
4. **Never fabricate a source, a statistic or a quote.** If a number is unknown, print `unknown` and say what would resolve it.
5. **Never manufacture consensus.** No astroturfing, no incentivized reviews, no sockpuppets, no bot-only content. It violates the platforms' rules, it is detectable, and it poisons the very signal you are trying to shape.
6. **Never serve engines different content than humans.** Cloaking is the one technical shortcut here that can get a domain removed outright.
7. **Never claim causation from one correlation.** A page update followed by a rate rise is a hypothesis. Say so, log the input, and let the next run test it.
8. **Never auto-commit, auto-publish or auto-deploy.** Show the diff and hand it over.
9. **Never spend without a preflight.** Before any paid data call, state the exact call count and cost shape, and stop for approval.
10. **Never refuse for a missing tool.** Every capability in `references/tools.md` has a free or manual fallback. Degrade, label the degradation in the report's method section, and continue.
11. **Never recommend a tool nothing degraded without.** Name instrumentation only when a specific measurement this run actually failed, lead with the free options, quote the run's own cost math, and say plainly when the free path was enough. Ask once and record a decline. The rules are in `references/tools.md` section 7.

---

## Asking the user

Three checkpoints stop the run and wait for a human. Use your harness's structured-question tool if it has one (`AskUserQuestion`, `ask_followup_question`, or equivalent). If it has none, ask in plain text and stop. Do not proceed on an assumption at a checkpoint.

| Checkpoint | Phase | Why it cannot be guessed |
|---|---|---|
| **Identity and attributes** | 0 | Everything downstream inherits this. A wrong attribute list produces a perfectly measured answer to the wrong question. |
| **Spend preflight** | 2 | The user is paying per call. Show the arithmetic first. |
| **Gameplan approval** | 4 to 5 | Deciding which items to execute now is a resourcing call, not a data call. |

Everywhere else, decide and move. Do not ask permission to run a free check.

---

## Phase 0: Foundation

Full method in `references/foundation.md`. Skip entirely if `.aeo/config.json` and `.aeo/brand.md` already exist. Never overwrite an existing foundation file.

1. **Detect the repo.** Is this the application, the marketing site, or both? Find the public domain, the content surface, the sitemap, `robots.txt`, `llms.txt`, and any server or CDN logs. Store it in `.aeo/config.json`.
2. **Build the truth file.** Read the codebase for what is actually true: plan and price definitions, feature flags, integration list, dependency manifest, OAuth and webhook handlers, public docs, changelog. Write `.aeo/truth.md` as a claim table. This is the ground truth every fact-check prompt is scored against, and it is the reason running in-repo beats running from outside.
3. **Decide who you are.** One page, confirmed by a human. The forcing template: