Either mode needs the tool binding below on first run.

Read what is actually connected before asking anything. Then propose one tool per job and ask only about the jobs with no connected option.

No vendor is required. Name a tool when it is connected, fall back to the next connected option when it is not, and say plainly when a job has nothing behind it rather than working around the gap silently. Never state that a tool is connected without having seen it.

If a tool needs a login, hand the browser over and let the user sign in. Never type credentials.

Copy and track this checklist:

Topic pipeline progress:
- [ ] Step 1: Pull live keyword and prompt volumes for the topic
- [ ] Step 2: Build the question map
- [ ] Step 3: Write the brief
- [ ] Step 4: Hand over the numbers table as evidence

Full per-tool procedure, match types, and the no-data path: references/research-protocol.md.

Turn the topic into the questions people actually type. Evaluator questions first: what it is, when to use it, how it compares, how to do it, what good looks like, and the real limits. Product-specific questions after.

Google's AI features fan a single query out into concurrent related queries and synthesise across all of them, so the unit that gets retrieved is the cluster, not the keyword. Brainstorm the five to ten queries the engine is likely to fan out to and check the site covers them somewhere, rather than aiming one narrow page at one string.

Every question has to be one a person would ask out loud. Keyword-stuffed pseudo-questions ("what is the best ai data analyst tool for teams in 2026") read as machine output to both readers and answer engines. Mark questions the page already answers as covered and drop them from the map.

Template: references/brief-template.md. Copy it rather than improvising the shape.

A brief is short and decision-shaped. It carries why the page exists, the SEO decisions (title, meta, H1, canonical, primary and secondary keywords with their volumes attached), a north star for tone, a handful of ideas to land, the page shape, the questions worth answering, and public sources the writer can actually cite.

It does not carry an internal feature dump, a section-by-section outline that leaves the writer nothing to decide, private wiki URLs, or invented stats, quotes, and product behaviour.

A new brief is a new file. Revising a topic means writing the next brief, not overwriting the record of what was asked for last time.

The pipeline ends with a numbers table, not an assurance that the research was done. Every figure carries its source, scope, and date window, and every gap says "No data" rather than going blank. The table format is in .

What each cadence checks and what earns a message: references/monitoring.md.

Track answer engines separately. ChatGPT and Perplexity overlap on roughly a tenth of cited domains, so a single "AI visibility" number averages two unrelated results into one that describes neither. Name the engine beside every figure.

Report state changes, not state. Clicks or impressions moving roughly 20% or more, average position worsening meaningfully, or 5xx and 404 counts jumping are worth a message; a flat week is not. Never fabricate a metric to fill a report: if access failed, say which property and move on. Track what has already been reported so the same drop is not raised twice.

For the scheduling itself, use the harness ( for a recurring cloud run, for an in-session interval). This skill defines what to check, not how to fire it.

Findings go in chat. Write a file only when the user asked for one, and never leave research notes, CSVs, or scratch exports behind in the repo.