Run a visibility sprint

Needs and produces

Start with the workspace site, its brand, audience, conversion goal, competitor context, locale, decision, and measurement window. For a performance question, check the Search Console connection before using its data. Preserve the selected property, date range, ingestion time, freshness, and completeness. A missing or expired connection is a typed blocker, not evidence that a page has no performance.

The baseline keeps traditional-search evidence separate from answer-engine evidence. Search evidence is scoped by query, country or language, property, device when known, date window, and source. Answer-engine evidence keeps each prompt's stable id and text, engine, locale, run time, mentions, citations, cited domains, sentiment when available, and source evidence. These records answer different questions and are not combined into one health score.

The sprint produces a report that identifies the site or property, observation window, source freshness and completeness, measured findings, assumptions, prioritized actions, query-set scope, provider coverage, completed versus expected runs, exact denominators, weak prompts, and limitations. It then produces two briefs with target query and intent, evidence line, destination, conversion goal, and content track, plus one article saved to the article surface.

Establish a baseline before recommending work

In the AI Visibility analytics screen, select the site and exact observation window. Architect uses the visibility skill to inspect existing evidence before any refresh, scan, or probe. For movement claims, it uses the current window and an immediately preceding window of equal length. A missing search row can mean no impressions, incomplete ingestion, property mismatch, or a provider bound. It does not prove rank zero.

Keep clicks, impressions, CTR, average position, query, page, country, device, and dates with the result that returned them. CTR needs its impression denominator, and average position is an impression-weighted observation rather than a fixed rank held all day. A SERP snapshot is one observed result set for a query and locale, while Search Console evidence is property performance over a window.

For answer engines, read the tracked prompt set and per-prompt evidence before creating a new probe. The visibility percentage for one prompt is citations or qualifying mentions divided by eligible completed runs for that prompt, engine set, locale, and window. Preserve citations, completed-run count, and percentage together. Zero citations across zero completed runs is unavailable, not zero percent.

Choose gaps from evidence

Prioritize a gap by likely business impact, effort, confidence, and dependency. A useful recommendation names the evidence, assumption, expected mechanism, leading indicator, and review date. Favor queries whose intent matches the conversion, whose evidence is current, and where a specific page can own the answer. Label volume, implementation cost, and conversion assumptions when they are not measured.

Technical evidence is URL-specific and observed at a time. Discovery, crawl permission, fetch and render, indexability, experience, and search presentation are separate layers. A clean robots file does not prove indexability, a fast page does not prove discoverability, and an llms.txt file does not prove a crawler used it. Preserve the URL, check id, observation time, evidence excerpt or metric, severity, scope, and confidence for each issue.

For a weak answer-engine prompt, connect the opportunity to its cited competitors or domains, missing evidence, and a page-level content gap. Do not infer absence from a failed run, silently average prompt percentages, or attribute a citation to an engine that was not queried. Changing prompt wording, locale, active state, or engine coverage revises the query-set instrument and requires a separate baseline.

Build briefs and save an article

Hand the selected gaps to the writing skill. A ready brief includes the target query or keyword verbatim with its informational, comparison, or transactional intent; current rank, impressions, clicks, CTR, and date range, or a note that evidence is insufficient; target conversion; classic search, generative answer, or both tracks; known competing URLs; and a new-page or existing-URL destination.

Writing reads workspace Context, relevant evidence, and prior published work before drafting. A business claim needs a workspace-wiki revision, bounded workspace evidence, or dated external source. It preserves provenance, freshness, limitations, and injection warnings in the claim ledger. If a source does not support a requested number or promise, the draft flags insufficient evidence instead of inventing a sentence.

Before creating a new article, Writing checks whether an existing page already owns the thesis. A new title or keyword over the same argument is a revision candidate. For a generative-answer brief, each major claim needs a named specific or concrete statistic with an inline citation. For a classic-search brief, use the target query naturally in the title, first heading, and a subheading, without treating keyword density as a target.

1. 1

   Read the bounded baseline

   Architect uses visibility to inspect the selected site, evidence window, Search Console status, and tracked prompts. In AI Visibility analytics, check that every reported metric carries its source, time window, and completeness.
2. 2

   Choose two specific gaps

   Architect ranks measured gaps by impact, effort, confidence, and dependency. Check that each choice points to a page, query, prompt, or technical layer rather than a broad unsupported topic.
3. 3

   Prepare two briefs

   Architect hands evidence to writing. Check that each brief retains the query, intent, evidence line, destination, conversion goal, track, competitors when observed, and evidence gaps.
4. 4

   Ground and save one article

   Writing reads Context and existing published work, then saves a complete article and reads it back. Check the returned article state, current revision, and body instead of treating unsaved chat copy as an article.
5. 5

   Report the next measurement

   Architect returns the saved article, baseline limitations, leading indicator, and review date. Check that the report does not claim a rank or citation improvement before an equal-scope later measurement exists.

Credits and completion

Existing evidence can be enough for a decision. Do not start a probe merely because a cached timestamp exists. Refreshes, scans, readiness runs, SERP snapshots, and probes can mutate state, spend credits, or run asynchronously, so inspect the exact current contract, scope, and expected cost first. A queued scan is not an audit result, and a probe start is not a new baseline.

For a paid live measurement, use the returned estimate and maximum-credit ceiling. Preserve the batch id after a new probe, then poll its status or the current run ledger without launching another batch. Completion means expected and completed terminal runs reconcile, or the provider reports a bounded or partial terminal state. Read per-prompt results only after that terminal evidence exists.

When it goes wrong

If Search Console is disconnected, expired, or bound to a different property, report that typed limitation and retain the exact site, property, and requested window. Do not estimate performance or treat missing rows as zero. If evidence is stale, read the existing observation first and refresh only when the decision needs newer evidence. If a scan is queued or partially complete, report that state and wait for its terminal read.

If prompt coverage is empty, preserve the empty denominator and say that visibility is unavailable. If a provider-bounded or failed run exists, do not infer that an engine failed to cite the site. Continue pagination when the question needs full coverage. If the prompt set changed, label the comparison as a new baseline or restrict it to unchanged prompts rather than merging incompatible windows.

If Writing lacks a traceable business fact, it should retain the saved draft work and ask for the missing source rather than fill the gap. A stale revision, failed destination, or missing authority also requires an exact read and repair path. For a failed run that the visibility screen cannot explain, continue with Find out why something failed and keep the run identifiers and returned state.

Leading metric and next play

The leading metric is priority gaps resolved with saved, evidence-grounded content. The near-term proof is a complete baseline, two reviewable briefs, and one saved article with a readback. Rank, traffic, and citation gains are later observations that need an equal-scope comparison; they are not promised by completing this sprint.

Use Build a founder posting system when the evidence establishes themes that should become short-form drafts. Use Weekly review to keep the finished runs, credit ledger, and measurement limitations visible across active work.