# Aeo Visibility > AEO Visibility — find out whether you show up when buyers ask an AI which product to use, and what to fix first. Point an agent team at your brand and the questions your buyers actually ask, and get an AEO Scorecard: the verdict per question (you're cited / a competitor is and you aren't / nobody is), and a fix queue ordered by impact and effort with an owner on every line. Use when I say "do we show up in ChatGPT", "are we cited in AI answers", "AEO check", "AEO audit", "answer engine optimization", "why does Perplexity recommend our competitor", "check our AI search visibility", "are we in AI Overviews", or ask whether buyers asking an AI would find us. Runs answer-sampler (once per question, up to 10, concurrently) → visibility-auditor, and writes to my-work/aeo-visibility/. Every verdict is dated: this is a read of one moment, never a rank tracker. - Skill: `bluerock-io/aeo-visibility` (Agent Skill) - Install (CLI): `npx skillmds@latest add bluerock-io/aeo-visibility` - Raw SKILL.md: https://api.skillmd.com/api/skills/bluerock-io/aeo-visibility/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: bluerock-io (https://skillmd.com/u/bluerock-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/bluerock-io/aeo-visibility --- Run the AEO Visibility team and produce an **AEO Scorecard** — Answer Engine Optimization, which is the discipline of being the source an AI answer draws on when someone asks it what to use. The scorecard says where the builder shows up today, where a competitor owns the answer instead, and what to fix first. **What it replaces:** asking an AI a dozen buyer questions by hand, writing down who it named, then trying to work out which of twenty possible site changes would actually move any of it. **Time saved:** about 1.5 hours by hand, estimated and not yet timed. The timed baseline (E6-26) replaces this figure when it lands. ## The honesty rule this whole skill is built around — read it first AI answers are **generated fresh each time and vary between runs.** The same question, asked twice an hour apart, can name different companies and cite different pages with nothing having changed on anyone's website. Everything this skill produces is therefore a **dated sample of one moment**, and the wording never drifts from that: - **Every verdict carries its sampled-on date.** In `inputs.md`, in every sample file, in `aeo-scorecard.md`, and on the artifact's masthead where it cannot be scrolled away from. - **Never claim rank tracking, position, share, or trend.** There is no rank here. Two runs a month apart are two samples, not a before and after, and the skill says so rather than drawing an arrow between them. - **Never imply reproducibility.** Do not tell the builder they can "re-run and check progress." Tell them a re-run is another sample. - **The count is a count, never a grade.** "Cited in 3 of 7 questions, sampled 2026-09-03" is a fact about one sample. A composite score out of 100 is an invention; never produce one, however much it would look like a scorecard. - **A fix changes what is findable, not what an AI will say.** Fixes are stated as "this makes the answer retrievable from your site" — never as "this will get you cited." **What we can and cannot reach.** This matters more here than anywhere else in the toolkit, and the builder is told it plainly rather than discovering it later: - The team **cannot log into ChatGPT, Perplexity, or Google AI Overviews.** There is no API key, no session, and inventing a transcript would be the worst possible failure for a tool about honesty. - What the team **can** do is sample **the retrieval layer** — run the buyer's question as a real web search and read what actually comes back, which is the pool an answer engine draws from when it answers that question. That is a genuine, defensible proxy, and it is labeled as exactly that: `[retrieval sample]`. - If the builder wants the real answer text, **they can paste it in** — the skill offers this at intake. A pasted answer is the strongest evidence in the run and is labeled `[pasted answer · · ]`. It is never summarized; the brands and links it names are captured verbatim. ## First — anchor to the project The scorecard, its working folder, and the `voice.md` / `objectives.md` the run reads all live in the builder's project. Two generations exist: the project ships inside the workspace image (usually the folder `my-workspace`); projects made before 2026-08 were cloned and carry whatever name the builder chose. **Assume neither — identify it by its signature.** In an SSH/cloud container the chat may start in the project itself or in the **home folder** with the project one level down — both are normal. Run `ls`; see `CLAUDE.md` and `design/` side by side? You're in the project. If not, find it: `ls */CLAUDE.md`, then `ls ~/*/CLAUDE.md`, else `find ~ -maxdepth 3 -path '*/design/dashboard.html'`. `cd` in, capture the **absolute path** with `pwd`, and use that full path throughout. Can't find it? Ask the builder which folder their project is in. ## Before the questions — read what the builder already has Check, without asking: `objectives.md` and `voice.md` at the project root, and the latest doc under `my-work/messaging-doc/` if one exists. These sharpen the run — they are never required for it. - **If they're real**, use them to pre-fill the intake: the messaging doc in particular names the category the brand competes in and the phrases it uses, which is most of what step 2's proposed questions are built from. - **If they're placeholder templates or absent**, say so once, plainly, and keep moving: *"Your `objectives.md` / `voice.md` are still the placeholder templates, so I'll build the buyer questions from your site alone. Happy to run anyway — running `/bluerock:onboard` would sharpen future runs."* Never make setup homework the price of the first scorecard. - **If a prior run exists**, its `inputs.md` pre-fills the same way (propose, confirm, don't re-ask cold) — the questions especially, since asking the same questions again is what makes two samples comparable at all. ## Intake — one question per step, short, then confirm Ask these one at a time. Keep each ask to a line or two; don't stack questions or explain the whole flow up front. **Skip what they already gave you** — if the opening request named the brand or the domain, say what you're taking as given (`Brand: Acme · Domain: acme.com`) so a wrong reading gets corrected early, then pick up at the first step that's actually missing. **Which prompt shape for which step:** use the question picker (`AskUserQuestion`) only where the answer is genuinely a choice between a few options — steps 2 and 4. Everywhere else the answer is free text in the builder's own words; ask in the message and let them type. Where the picker isn't available in this client, ask in the message. 1. **Brand and domain.** "What brand are we checking, and what's the website?" One line. The domain is what presence is judged against, so take it exactly — apex or www, and note any second domain (a docs site, a separate product site) they also own. 2. **The buyer questions — you propose, they confirm.** This is the step that decides the whole run, so do the work before asking. **Fetch two or three pages of their site** (homepage, a product or solutions page, a pricing page if there is one) and read what they sell, to whom, and against what. Then propose **5 to 10 questions in the shape a buyer would actually type into an AI**, drawn across three kinds — this is the intent spread the method calls for, and a list that is all one kind produces a useless sample: - **Category questions** — the buyer knows what they want to buy. *"What's the best for ?"*, *"Top tools 2026"* - **Problem-aware questions** — they feel the pain, not the category. *"How do I stop ?"*, *"Why does happen?"* - **Comparison and buying questions** — they are close to a decision. *" alternatives"*, *" vs "*, *"How much does cost?"* Show the list numbered, say where each came from in one clause, then: *"These are what I'd ask on your behalf. Edit any of them, delete what's wrong, add what I missed — the ones your buyers actually type matter far more than the ones I guessed."* Take their edits **verbatim**; a question reworded into our phrasing is no longer their buyer's question. Cap the confirmed list at 10. 3. **Competitors — optional.** "Who should I watch for in the answers? Names are enough." Optional and never blocks: without names the sampler still reports every brand the answers name, which is often how a builder discovers a competitor they weren't tracking. With names, the scorecard can say *absent, and is there instead*, which is the sharpest line on the whole card. 4. **A real answer, if they have one — optional, and worth offering properly.** Explain the trade in one breath, because it changes what the run can claim: *"I can't log into ChatGPT or Perplexity, so by default I sample what a search actually returns for each question — the pool those engines draw on. If you want the real thing in the mix, paste what ChatGPT or Perplexity said for any of these questions and I'll read it verbatim."* (options: I'll paste some answers · sample the retrieval layer, that's fine). Take whatever they paste, whole, and note which engine and what date each came from — an undated pasted answer is asked about once, because the date is the whole point. 5. **Confirm before we run.** Play back brand, domain, the numbered questions, competitors, and which questions have a pasted answer, then: "Good to go, or anything to edit?" **Carry the questions forward verbatim from here.** **The moment the builder approves**, set the expectation for the wait in one message of its own, then go quiet until the report: the samples run concurrently and the audit follows, so this takes several minutes — a good moment to grab a coffee or switch tasks, and the scorecard will be ready when they check back. No further chatter between this and the report. ## Set up the run 6. **Make the working folder:** `my-work/aeo-visibility/-/`. Dated on purpose — runs accumulate and are never overwritten. `my-work/` is builder-owned. 7. **Check for a previous run:** list `my-work/aeo-visibility/`. If a prior dated folder holds an `aeo-scorecard.md`, note its path and date for the auditor. **A previous run is a previous sample, not a baseline** — the auditor is told this explicitly, and the words "improved", "declined", "up", and "down" never appear about the pair. 8. **Write `inputs.md`** into the working folder: brand, domain, the confirmed questions verbatim and numbered, competitors, which pasted answers were supplied and their engine and date, which project files were real enough to read, and **the sampled-on date**. This is the record of what shaped the scorecard and the seed the next run pre-fills from. ## Run the agents Dispatch these as ordinary subagents. Do not use agent-teams tooling; this runs identically in every client. 9. **Dispatch one `answer-sampler` per confirmed question — all in a single message so they run concurrently.** Each gets: its one question **verbatim**, the brand and domain, the competitor names if given, any pasted answer for *that* question in full, and the working folder's **absolute path** in the dispatch prompt itself (a subagent starts wherever the session started; the path you pass is the handoff). Each writes `sample-.md`. Wait for all of them. - **Ten concurrent samplers is the cap** because the confirmed list is capped at 10. If a builder insists on more, run the first 10 and say plainly which were not sampled rather than silently truncating. 10. **Dispatch `visibility-auditor`** with the working folder path, the brand and domain, and, when step 7 found one, the previous `aeo-scorecard.md` path. It reads `inputs.md` and every sample, audits the builder's **own** pages against the eight-step method, and writes `aeo-scorecard.md`: the verdict, the per-question grid, and the fix queue. ## Publish the artifact — you, not the agents 11. When `visibility-auditor` finishes, read `aeo-scorecard.md` and **publish it as a Claude Artifact** yourself, in this conversation, following the design contract below. The agents write markdown only; the finished, shareable view is yours to render. If artifact publishing isn't available in my environment, don't block — the markdown is saved; say so and give the path. ### The artifact — design contract (follow it exactly) **The artifact is a tool the builder works from, not a report they scroll** (product decision, 2026-08-31). One question on screen at a time, reachable in one click; the verdict readable by color before it is read as words. Read-only and honest: no CTAs, no dead controls, nothing that pretends to fetch or save — a dead button in a sandboxed artifact is worse than no button. Interactivity is navigation, never chrome. A single self-contained HTML page. **CSP rules: exactly one external request, the Google Fonts stylesheet below. All CSS in one `