discovery
Installation
SKILL.md
Discovery interview → ./plans/<feature>/discovery.md with go/no-go verdict. Pipeline: discovery → product → design → engineering → plan.
Rules
- Language barrier: User is a product person. Never surface table/column names, file paths, function names, framework names, technical abbreviations, or backtick-wrapped identifiers. Read codebase silently; describe findings as if explaining to someone who has never opened a terminal.
| Technical (never say) | Plain language (say this) |
|---|---|
"The candidates table has an optional userId FK" |
"Candidates are already tracked with a link to user accounts" |
| "No search infrastructure — no vector DB, no embeddings" | "There's no search feature today — this would be built from scratch" |
- Discovery altitude: Stay at concept/capability level. No functional requirements (behaviors, rules, permissions, workflows, field-level decisions) — those belong in
/product. No implementation details. Redirect: "Good question for requirements — let's stay on discovery."- Discovery-level: "Text-only or media?" / "Self-service or admin-managed?"
- Requirements-level (defer): "Should profiles lock during voting?" / "What approval flow?"
- Relentless questioning: When framing is vague, don't accept it — drill to a concrete capability before feasibility matters. Push on evidence: how many users asked? What do they do today? What would they stop using? When answers are shallow, probe — reframe, ask for evidence, propose a contrary position. Record as assumption only when user genuinely can't resolve.
- Code-first: Explore codebase before asking questions it could answer. State what exists, what's missing, what would change — at capability level. When codebase has competing patterns, surface the conflict. After user answers, verify against codebase.