planlisted

# Plan — Research-First Task Planning Transform feature descriptions, bug reports, or improvement ideas into well-structured, research-grounded implementation plans. The governing principle: **80% planning and research, 20% execution.** A plan written from assumptions is worse than no plan — it lends false confidence to a wrong approach. ## When to use Activate when: - The user says "plan", "how should we", "let's think through", "what's the best approach" - Starting any feature or change touching 3+ files - The task involves unfamiliar parts of the codebase - Before any architectural decision ## When not to use - Trivial single-file edits where the approach is obvious — just do it - Pure questions that need an answer, not a plan - When the user has explicitly asked for speed over thoroughness on a small task ## Philosophy **Never plan in the dark.** Every plan should be grounded in: 1. What the codebase actually looks like today — not assumptions 2. Existing patterns the project already uses 3. Past solutions to similar problems (check `docs/solutions/` and `docs/decisions/` if they exist) 4. Clarified requirements — not guesses 5. Known risks and constraints ## The planning process ### Phase 0: Idea refinement Before researching, understand the request: 1. **Check for existing plans** — search `docs/plans/` for plans related to this feature. If one exists, present it and ask: continue from it, update it, or start fresh? 2. **Check for past solutions** — search