Discovery
Required Inputs
- Question or request: What to investigate, analyze, or research.
Callers MUST NOT pre-classify or pass a subtype hint.
Discovery Types
- technical-code — understanding a proposed codebase change: affected files, call chains, change points, risks.
- agentic-dev — changes to Claude Code surfaces: skills, hooks, agents, plugins, MCP wiring, frontmatter.
- tool-research — web-grounded investigation of an external library, tool, API, or technology.
- documentation — auditing existing docs for drift, missing surfaces, or stale references.
- general — anything that doesn't fit the above.
Process
- Read the request and pick the best-matching type from the list above.
- If two types are genuinely ambiguous, ask one clarifying question via
AskUserQuestion before proceeding. Otherwise self-classify and proceed.
Read ${CLAUDE_SKILL_DIR}/playbooks/<type>.md (substituting the chosen type) and follow its instructions verbatim.- Note the chosen type at the start of the response if it would be useful to the caller.
Asking the User During Research
When research surfaces an ambiguity that would materially change your recommendation, ask the user via AskUserQuestion before finalizing the output. Group related questions into one focused round — don't drip them out.
Before asking, do this check. For each candidate question, re-scan the original prompt for any sentence that names the same decision. If you find one, the question is answered — even if the phrasing is informal ("I like X", "another pair can be created", "the only time it wouldn't happen is…"). If you'd have to ignore or re-litigate something the user already said in order to ask the question, don't ask it. Bias hard toward "the user already told me" — they invoked an autonomous skill on purpose.
Ask when:
- The approach hinges on a user preference you don't know
- Scope could plausibly be much larger or much smaller than assumed
- A constraint you discovered (in code or docs) would change the recommendation if it applies
Don't ask when:
- The user's prompt already states a preference on this exact topic, even informally — quote it back in the output instead of re-asking
- It's minor enough to leave as an "Open question" in the output
- You can answer it yourself with more reading or one more doc fetch
- It's a stylistic preference rather than a load-bearing decision
This is a single focused round, not a conversation. If the request is vague enough to need extended back-and-forth, that's requirements-creation's job, not this one. Open questions in the final output should be the less critical unknowns; the load-bearing ones get asked.
Information-Gathering Note
Where a playbook directs you to do external research, use any available information-gathering tool (e.g. Perplexity, Gemini, context7, WebSearch/WebFetch).
1---2name: discovery3description: Use when asked to "investigate", "analyze", "what would be involved", "scope this work", "research", "discover", "look into", "audit docs", or "research [tool/library]". Self-classifies the discovery type and dispatches to a playbook. Callers must not pass a subtype.4---56# Discovery78## Required Inputs910- **Question or request**: What to investigate, analyze, or research.1112Callers MUST NOT pre-classify or pass a subtype hint.1314## Discovery Types1516- **technical-code** — understanding a proposed codebase change: affected files, call chains, change points, risks.17- **agentic-dev** — changes to Claude Code surfaces: skills, hooks, agents, plugins, MCP wiring, frontmatter.18- **tool-research** — web-grounded investigation of an external library, tool, API, or technology.19- **documentation** — auditing existing docs for drift, missing surfaces, or stale references.20- **general** — anything that doesn't fit the above.2122## Process23241. Read the request and pick the best-matching type from the list above.252. If two types are genuinely ambiguous, ask one clarifying question via `AskUserQuestion` before proceeding. Otherwise self-classify and proceed.263. `Read` `${CLAUDE_SKILL_DIR}/playbooks/<type>.md` (substituting the chosen type) and follow its instructions verbatim.274. Note the chosen type at the start of the response if it would be useful to the caller.2829## Asking the User During Research3031When research surfaces an ambiguity that would materially change your recommendation, ask the user via `AskUserQuestion` before finalizing the output. Group related questions into one focused round — don't drip them out.3233**Before asking, do this check.** For each candidate question, re-scan the original prompt for any sentence that names the same decision. If you find one, the question is answered — even if the phrasing is informal ("I like X", "another pair can be created", "the only time it wouldn't happen is…"). If you'd have to ignore or re-litigate something the user already said in order to ask the question, don't ask it. Bias hard toward "the user already told me" — they invoked an autonomous skill on purpose.3435Ask when:3637- The approach hinges on a user preference you don't know38- Scope could plausibly be much larger or much smaller than assumed39- A constraint you discovered (in code or docs) would change the recommendation if it applies4041Don't ask when:4243- The user's prompt already states a preference on this exact topic, even informally — quote it back in the output instead of re-asking44- It's minor enough to leave as an "Open question" in the output45- You can answer it yourself with more reading or one more doc fetch46- It's a stylistic preference rather than a load-bearing decision4748This is a single focused round, not a conversation. If the request is vague enough to need extended back-and-forth, that's `requirements-creation`'s job, not this one. Open questions in the final output should be the _less critical_ unknowns; the load-bearing ones get asked.4950## Information-Gathering Note5152Where a playbook directs you to do external research, use any available information-gathering tool (e.g. Perplexity, Gemini, context7, WebSearch/WebFetch).
langadventurellc