Feature discovery

Feature-discovery traces how an existing feature, module, or behavior works and reports it in chat, evidence-cited: another engineer comes away knowing what it is, how it works, where it is used, and what remains uncertain.

Inputs

Intake may be structured — Projects Affected: plus a What: block — or free-form; infer the projects and topic. Questions are for blocking clarifications only; user away → state the assumption and continue best-effort.

Rules

• Read-only, chat-only. Do not edit code, config, docs, native memory, ADRs, prompts, issues, or generated artifacts while discovering — CONTEXT.md and artifact edits wait for step 6 approval. Never create docs/discovery/ files, and do not read legacy discovery files unless the user names one — they go stale. No git fetch, git pull, installs, migrations, or destructive commands.
• Code is the source of truth when evidence conflicts with prose docs, issues, or comments. Cite evidence for every claim (Evidence style below); separate confirmed facts from inference; never invent rationale. The tell: a comment, issue, or native memory outranking the code it describes.
• If graphify-out/graph.json exists (project root, else workspace root), query it before raw search; older than ~7 days → suggest graphify update .; missing → skip graphify. Scope with graphify query/path/explain before broad rg sweeps. Verify graph answers against current code and flag staleness — never run graphify update . yourself; discovery stays read-only. Do not hunt for a graph elsewhere or suggest installing it.
• Trace behavior, not just symbols. Follow definitions to callers and user-facing flows from entry points down; flag seam-reuse when similar behavior exists in multiple paths. The tell: a symbol dump with no usage site or user-visible effect.
• Keep scope thin. Broad intake gets split; discover the first slice before expanding. Near ~120K tokens with core unknowns unresolved, stop and recommend a scope split or handoff. The tell: drifting into product discovery or experiment design without an explicit pivot.
• Stop after presenting the report. Suggest the next skill; never invoke it or start implementation without a fresh request. Grillable unknowns stay as open decisions for /feature-prompt or /grill-with-docs; ungrillable ones ("needs to feel/see it") route to /handoff + /prototype (when installed; else state the uncertainty plainly). Destination or open questions still foggy → suggest /wayfinder, not /feature-prompt; a PR-sized prompt cannot be written through fog.
• Emit Stage / Found / Next / Needs user at each phase transition — one line per field. Phases: parsed, discovered, validated, report.
• Sub-agents: dispatch local lanes automatically for independent work — never cloud agents; announce the lane count at dispatch and report each lane as it completes. Summaries back, not transcripts; synthesis stays in the main session.