doc-feature

# /doc-feature — Feature Documentation Generator ## Position in Ecosystem ``` product-discovery → requirements docs → [dev phase] → doc-feature (JTBD, RICE) (PRD, contracts) (code) (feature doc) ``` **doc-feature fills the gap between product specs and code-level docs.** Routing decisions (where each piece of information belongs) come from the `doc-routing` skill. ## Usage ``` /doc-feature [Feature Name] /doc-feature Reports Phase 2 /doc-feature Search Module ``` ## Output Location `docs/features/{kebab-case-name}.md` --- ## ⛔ MANDATORY RULES (NON-NEGOTIABLE) 1. **NEVER skip Phase 2 (PRESENT & ASK)** — always show what you understood and ask clarifying questions 2. **NEVER generate the doc without the user's answer or an explicit "skip"** — wait for a response 3. **ALWAYS read the actual source code** — don't just list files, READ the implementation 4. **ALWAYS check project memory** (e.g. `.claude/memory/MEMORY.md` or your auto-memory file) — it contains API gotchas, decisions, and patterns already documented 5. **ALWAYS fill ALL template sections** — use "N/A — [reason]" for empty sections, NEVER omit them 6. **ALWAYS include real API response shapes** — not placeholders, actual `{ field: type }` from the type definitions 7. **ALWAYS trace data flow through code** — follow imports: page/entry point → hook/service → API call → type → response 8. **ALWAYS capture the business WHY** — not just "what it does" but "why the user needs this"...