justincordova Executing Plans
Overview
Execute implementation work. Can load from a plan file (if one exists) or from a design doc, or just follow the developer's direct instructions for small iterations.
Announce at start: "Using execute skill to implement this plan."
Plans live in: docs/plans/
Design docs live in: docs/designs/
The Process
Step 1: Load Context
Determine which starting mode applies:
- Plan file exists — read the plan file from
docs/plans/ - Design doc exists (no plan) — read the design doc from
docs/designs/ - Small iteration (no plan, no design doc) — use the developer's instructions directly
In all cases, read docs/SPEC.md for context on design decisions. Review critically — identify questions or concerns. If concerns: raise them before starting. If no concerns: create task list and proceed.
Step 2: Determine Batches
A batch ends wherever a human reviewer would want a checkpoint. Use these rules in order:
Always end a batch before any of these:
- Database or schema change — migrations, new tables, destructive alters
- Public API contract change — new endpoints, changed signatures, removed fields
- New dependency — adding a package, service, or infrastructure component
- Cross-cutting refactor — changes that touch 5+ files across different modules
- Phase boundary in the plan — if the plan defines phases, each phase is at least one batch
- Anything with destructive or hard-to-reverse effects — data migration, file deletion, force push
Otherwise, group tasks into the same batch when:
- They touch the same module, feature, or component
- They share test files or integration points
- Splitting them would leave the codebase in a broken intermediate state
Default: when in doubt, make the batch smaller. Small batches = faster feedback loops = less wasted work when something's wrong.
Examples:
| Tasks | Batch Decision | Why |
|---|---|---|
| 8 tasks all building auth module | 1 batch | Same component, no destructive effects |
| 6 auth tasks + 2 DB schema tasks | 2 batches | Schema change is a checkpoint trigger |
| 4 tasks: add dep, build service, add route, write tests | 2 batches (dep alone, then the rest) | New dependency is a checkpoint trigger |
| 3 unrelated bugfixes in different modules | 3 batches | No cohesion, each worth reviewing separately |
| Phase 1 (5 tasks) + Phase 2 (4 tasks) | 2+ batches, never combined | Phase boundary is a hard break |
Present your batch grouping to the user before executing. Call out which checkpoint rule triggered each split.
Step 3: Execute Batch
For each task:
- Mark as in_progress
- Follow the steps described in the plan
- Run verifications as specified
- Mark as completed
Step 4: Report
When batch complete:
- Show what was implemented
- Show verification output
- Say: "Ready for feedback."
Step 5: Continue
Based on feedback:
- Apply changes if needed
- Execute next batch
- Repeat until complete
Step 6: Wrap Up
After all tasks complete and verified:
- Run full test suite
- Run build
- Report completion
- If docs feel stale or the feature involved multiple iterations, suggest running sync-docs. Otherwise say nothing — sync-docs is on-demand, not automatic.
When to Stop and Ask
STOP immediately when:
- Hit a blocker (missing dependency, test fails, instruction unclear)
- Plan has critical gaps
- You don't understand an instruction
- Verification fails repeatedly
Ask for clarification rather than guessing.
Key Principles
- Review plan critically first
- Reference SPEC.md for design context
- Follow plan steps — don't skip ahead
- Don't skip verifications
- Batch by cohesion, not count
- Between batches: report and wait for feedback
- Stop when blocked, don't guess
- Don't commit unless explicitly asked