feature-plannerlisted

# feature-planner — write the scope down before it moves Scope that lives in someone's head grows quietly, and nobody can point to when it did. Decomposing the work orders it; writing down what is *not* in it is what makes the boundary hold later. ## Planning Steps ### 1. Requirements Clarification - What exactly is being requested? - What's explicitly NOT in scope? - What are the acceptance criteria? - Any constraints (performance, compatibility, timeline)? ### 2. Existing Code Analysis - What related code already exists? - What patterns does the project use? - What can be reused/extended vs built new? - What will break if we change X? ### 3. Implementation Plan - Break into ordered tasks (dependencies mapped) - Identify parallel vs sequential work - Estimate which files change - Flag risky parts that need extra care ### 4. Scope Lock - List what's IN scope (explicit) - List what's OUT of scope (explicit) - Get user confirmation before starting ## Rules - No gold-plating: plan only what's requested - Identify the MVP path first - Flag unknowns early (don't discover them mid-implementation) - If >10 files affected, suggest phased approach ## Where the output goes Work that spans sessions: `.specseal/tasks/<work-item-slug>.md`. Not `specs/` — that root holds what was agreed, and a task list is where the work has got to. `plan.md`'s Phases table stays the stable layer above it. Work finishing in one session needs no file. ## Output Format ``` ## Feature: [name] **Sc