feat(self-driving): ground custom-scout gap analysis in for-agents context

context/skills/self-driving/references/6b-tailor-scouts.md

@@ -28,7 +28,7 @@ Reach these PostHog tools through the `exec` tool — `info` then `call` for `ll
 
    **Soft-degrade if it 404s** (older PostHog deploy that doesn't seed companions): read a built-in scout body via `llma-skill-get` (e.g. `signals-scout-general`) and use it as your only template. If neither is readable, record a follow-up ("add custom scouts once the authoring guide is available") and continue to step 7.
 
-2. **Do the gap analysis — this is the thinking step, take it seriously.** Lay the project evidence (the setup report's event taxonomy above all, plus the step-2 checklist: funnel structure, payment/LLM/survey surfaces, warehouse sources, integrations) against what the built-in troop already watches. For each candidate surface ask, in order:
+2. **Do the gap analysis — this is the thinking step, take it seriously.** Start from the repo's for-agents context when present — `AGENTS.md`, `CLAUDE.md`, `ARCHITECTURE.md`, `.cursor/rules/`, `.github/copilot-instructions.md`, and any docs written for agents. They are a distilled, maintained map of what the product does, its domain vocabulary, and its moving parts — surfaces like background jobs, integrations, billing flows, and internal pipelines that neither the event list nor a raw source scan reveals cheaply. Read them before scanning source, name proposed scouts in the product's own vocabulary, and cross-check that a "gap" isn't a surface those docs say is deliberately out of scope. Then lay the project evidence (the setup report's event taxonomy above all, plus the step-2 checklist: funnel structure, payment/LLM/survey surfaces, warehouse sources, integrations) against what the built-in troop already watches. For each candidate surface ask, in order:
    - **Is it watchable?** Concrete events with names you can list, a funnel with ordered steps, a domain loop with a success/failure pair. "It's a web app" is not a surface.
    - **Is it uncovered?** Three things can already own a surface, and a custom scout that duplicates any of them adds noise, not coverage: (1) a built-in scout step 6 kept enabled — the 1–2 specialists or `signals-scout-general`, which sweeps cross-product surfaces every run (e.g. generic anomalies belong to `signals-scout-anomaly-detection` if it was picked); (2) a **native source** — error tracking and session replay are consumed as sources in step 4, so never propose a custom scout for error bursts or replay analysis even though their built-in scouts are now disabled. If the surface is only watched by a built-in scout step 6 *disabled* (not `general`, not a native source), it is genuinely uncovered and fair game.
    - **Would its scout pass the quality bar?** You must be able to name its signal-vs-noise discriminator and 2–4 concrete explore patterns *before* proposing it. If you can't, the surface isn't ready for a scout — record it as a report note instead.