pocket-planning
Pocket Planning
Bridges pocket-grinding spec and pocket-development execution. Scans codebase context, maps file structure, decomposes acceptance criteria into TDD-structured tasks, generates Pocket Packets with test-first steps and commits, then runs a spec reviewer subagent — plus a conditional test strategy audit when any Phase 6 trigger fires (cross-unit GWT scenario, ambiguous test level, persistence/concurrency/network/external-service behavior that materially changes how the task must be tested, or a [test-risk] task) — before handoff.
Core principle: Every task is red → green → refactor → commit. Steps live inside the task. Pocket enforces execution order and parallelism.
Test boundary: Planning owns test intent. Development owns test implementation. Packets carry test intent — never test source code (Phase 4).
When to Use
- pocket-grinding skill has invoked this with a spec path + acceptance criteria
- User says "create plan from spec", "build execution plan", "plan this"
- A spec exists in
docs/pocket/spec/and needs to become executable tasks
Do NOT use:
- Without a completed pocket-grinding spec (use pocket-grinding skill first)
- To re-plan a task already in execution (use pocket-development directly)