| name | discover |
| description | Use for pre-work thinking before consequential work, including codebase exploration, brainstorming, planning direction, shaping ideas/features/specs, conceptual/design/routing/interface/state/context-boundary questions, workflow/tool-surface questions, "should we" / "how should we" / "what do you think" prompts, vague requests, and work that needs evidence before spec, plan, build, review, verification, or durable memory. |
Discover
Think before downstream work.
Act as a collaborative partner and workflow navigator, not a passive executor. Help the user think, notice missing path-changing areas, and choose the next route while preserving user authority.
Discover is the shared-understanding loop before spec, plan, build, review, verification, handoff, or memory. It turns unclear direction into the next safe route.
Use full Discover when the user is forming direction: codebase exploration, brainstorming, tradeoff comparison, planning direction, conceptual/design/routing/interface questions, workflow/tool behavior, state or context boundaries, path-changing questions, or a checkpoint.
Treat tentative reasoning, chain-of-thought references, contradictions, and changed decisions as discovery input to adjudicate, not hidden approval to execute.
Priority: Interview Gate stops silent decisions and user-owned decisions first. Output Router only chooses evidence transport after the discovery route is clear.
Default Trigger
Use Discover for most consequential requests that are not already ready to execute:
- first repo/code exploration before action;
- brainstorming, shaping, or comparing paths;
- conceptual, design, API, runtime, workflow, routing, tool-surface, interface, state-machine, context-boundary, architecture, or module-boundary questions;
- “should we,” “why not,” “what do you think,” “how should we,” “which route,” or similar prompts;
- turning discussion into a spec, plan, issue, ADR, handoff, or durable memory;
- unclear bug-like symptoms before diagnosis has a concrete repro path;
- any request where evidence could change scope, route, artifact, or next action.
Do not use full Discover when the next action is already clear and covered by a more specific skill: executing an approved plan, verifying work, reviewing a diff, committing, or answering a simple factual question.
Only direct bounded factual questions use discovery-light: inspect the smallest relevant evidence, then answer directly. If the question asks why, whether, or how to design, route, model state, choose a tool interface, or shape next work, use Discover.
For route-choice questions, name the route as Discover before moving toward spec, plan, or implementation.
Hard Stops
Stop and ask when discovery reveals:
- a user-owned decision: product behavior, scope, public API, security, privacy, billing, data loss, compatibility, permissions, or irreversible architecture;
- a source-truth conflict with docs, tests, ADRs, specs, policies, or live repo evidence;
- an ambiguous target, artifact destination, or path choice that would change the next action;
- a material method substitution, such as replacing requested research with a guess.
Do not write implementation files from Discover.
Do not create specs, plans, ADRs, handoffs, decision notes, or memory unless the user asks or the checkpoint must survive beyond chat.
Evidence Before Questions
Inspect first when the answer is discoverable from:
- code, tests, docs, ADRs, specs, policies, issues, logs, traces, or repo state;
- provided files, URLs, screenshots, transcripts, or user context;
- current external docs or web sources when framework/library facts or recent changes matter.
Ask before inspecting only when multiple targets would change the discovery path or access/scope is user-owned.
Question Discipline
Ask fewer, deeper questions.
Before asking, run the deletion test:
If I do not ask this, does downstream complexity spread?
If no, skip it.
Ask one or two path-changing questions at a time. Do not satisfy requests for “every question,” “grill me,” long questionnaires, or recommended answers for each question. Name the decision tree and ask the next question that matters.
Recommendations should clarify tradeoffs, not create an approval script. Give the recommendation for the current path-changing question, then wait when the choice is user-owned.
Loop
- Identify the target: repo area, artifact, URL, product, model, package, paper, issue, symptom, or idea.
- Inspect the smallest evidence that can change the route.
- State the current understanding in plain language.
- Compare paths when direction is still forming; do not force a decision too early.
- Ask one path-changing question when the answer would change the next artifact or action.
- Treat user challenges, counter-questions, and new constraints as discovery input.
- Track decisions as settled, tentative, or open.
- Stop when remaining ambiguity would not change the next route.
Discovery can loop through evidence, brainstorming, targeted questions, design, and checkpointing in any order. Do not force a fixed sequence.
Scope And Decisions
Preserve the user's intended scope. Do not silently turn a large idea into v1, v2, MVP, release, or roadmap framing.
Use implementation slices, phases, checklists, or multiple artifacts to make large work executable without changing what the user asked for.
Persist decisions only when absence would make future work rediscover or contradict them:
- domain meaning -> existing glossary,
CONTEXT.md, or domain doc;
- feature behavior, scope, or acceptance -> spec;
- future implementation path -> plan;
- immediate continuation state -> handoff;
- hard-to-reverse surprising tradeoff -> ADR;
- no durable value -> chat only.
Read ARTIFACT-DESTINATIONS.md when the destination is not obvious.
Conversation Navigation
During sustained brainstorming or design discovery, track topics as settled, tentative, and open.
When the current topic appears resolved, the user asks what next, or the conversation is about to move toward a durable artifact, name the next 1-3 path-changing topics worth covering. Recommend one next route when evidence supports it.
This is navigation, not control. Do not force a checklist or ask whether to grill every time. When the user asks what next after sustained discovery, include a Next: route so the user does not have to carry the whole design map.
Routing Out
Before routing from discovery to write-spec, run a final ambiguity sweep. Ask only remaining path-changing questions whose answers affect scope, behavior, acceptance, public API, architecture, security, privacy, billing, data loss, compatibility, or artifact destination.
If no meaningful questions remain, say so and route forward. Do not silently jump to spec, plan, or build.
Close consequential discovery with a checkpoint. Keep it in chat unless it must guide later work. Read CHECKPOINTS.md before saving a checkpoint.
Checkpoint shape:
Question / goal: ...
Evidence: ...
Current understanding: ...
Settled: ...
Tentative: ...
Open: ...
Recommendation: ...
Next: Forward | Backward | Branch | Stop — ...
Next: is routing, not permission to create the next artifact.
