planninglisted

# Planning Skill Phase 2.0 of the governed workflow. The orchestrator and plan-advisor teammate collaborate to produce an execution plan with scope embedded in each execution item, 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`, `tasks`, and `scope`. Sub-phases map to execution cycles (3.1, 3.2, ...) — each goes through implementation, validation, review, and commit. **Default: one sub-phase.** A small or single-area change — for example, adding a service and repository layer to an existing backend feature — is always exactly ONE sub-phase. Do not split it. **Split only for genuinely large jobs** that change a lot of code across clearly different areas, where each area should be fully implemented and validated before the next area begins. A concrete example of a large new feature that war