write-planlisted

## Objective Guide the user from an idea or spec to a reviewed, step-by-step implementation plan ready for `/implement-plan`. The process has two modes: interactive discussion (you talk to the user), and isolated review passes (fresh sub-agents each handle one concern). ## Phase 1: Discussion (interactive) If `$ARGUMENTS` is provided, read it as requirements context (spec, user stories, discovery notes, or a rough plan). ### Explore the codebase 1. Read `./CLAUDE.md` at the project root (if it exists). 2. Identify which areas of the codebase are relevant to the user's idea. Read key source files to understand current patterns, types, and architecture. 3. Check for nested `CLAUDE.md` files in relevant directories. ### Clarify with the user Ask questions to narrow the scope. Focus on: - **What**: What exactly should the feature/change do? What are the acceptance criteria? - **Where**: Which parts of the codebase are affected? Are there existing patterns to follow? - **How**: What technical approach? Are there trade-offs to decide? - **Boundaries**: What should NOT change? What's out of scope? - **Testing**: What scenarios need test coverage? Keep asking until you have enough to write a precise plan. The user signals readiness by saying something like "OK", "let's go", "write it", "that's enough", etc. ## Phase 2: Draft the plan Write the plan to `plans/YYYY-MM-DD_slug.md` where: - `YYYY-MM-DD` is today's date - `slug` is a short kebab-case name derived from the feat