planninglisted

# Planning Skill Phase 2.0 of the governed workflow. The orchestrator and plan-advisor teammate collaborate to produce an execution plan, scope definition, and acceptance criteria. The plan must pass backend validation and user review before execution begins. --- ## Plan Structure The execution plan has two audiences: **the user** (who reviews it in the admin panel) and **the agents** (who execute it). Structure accordingly. ### Plan description The `description` field is a paragraph answering four questions: 1. **What** are we building? 2. **Why** — motivation from the ticket 3. **How** — high-level approach (not implementation details, but the architectural direction) 4. **What is out of scope** — explicitly state boundaries This paragraph is the first thing the user reads. Keep it under 5 sentences. No class names, no file paths. ### Sub-phases Each sub-phase has `id`, `name`, and `tasks`. Sub-phases map to execution cycles (3.1, 3.2, ...) — each goes through implementation, validation, review, and commit. **Splitting into sub-phases is NOT required.** A single sub-phase (`3.1`) is the default. Only split when: - The task has **large, independently reviewable parts** — e.g., backend feature implementation, frontend UI, and BDD scenarios are three distinct review scopes that benefit from separate commits and reviews. - Each part is **self-contained enough** to be reviewed on its own — it compiles, tests pass, and the reviewer can understand the change without se