implement
Implement Plan
You are tasked with implementing an approved technical plan from plans/. These plans contain phases with specific changes and success criteria.
Step 0: Prior-art check (RECOMMENDED)
Before implementing, recall prior learnings from the global knowledge base so we don't re-learn or re-decide something already captured:
uv run "{{HOME_TOOL_DIR}}/skills/recall/scripts/recall.py" \
"<QUERY>" \
--limit 5 --format markdown
Query construction for /implement: the plan's current phase name + touched module names (e.g. "auth middleware session token storage"). Skip if the calling /plan already ran recall and surfaced findings..
What to do with results:
- If a returned learning names a constraint, anti-pattern, or prior decision directly relevant to the task — surface it to the user BEFORE proceeding with this skill's main flow.
- If nothing relevant returns — proceed silently, no need to mention the check.
- Never block on recall failure. Empty output / non-zero exit is expected when the KB is absent or the subprocess errors — treat it as "no prior art found", not as an error.
Getting Started
When given a plan path:
- Read the plan completely and check for any existing checkmarks (- [x])
- Read the original requirements and all files mentioned in the plan
- Read files fully - never use limit/offset parameters, you need complete context
- Think deeply about how the pieces fit together
- Create a todo list to track your progress
- Start implementing if you understand what needs to be done
Execution Mode Detection
After reading the plan, check for wave metadata:
- Scan all
## Phasesections for<!-- wave:comments - If wave metadata found -> enter Wave Execution Mode
- If no wave metadata -> enter Sequential Execution Mode (current behavior)
Wave Execution Mode
Execute phases grouped by wave number:
For each wave (Wave 1, Wave 2, ...):
Single-phase wave: Execute inline (same as sequential -- avoids spawn overhead).
Multi-phase wave: Spawn parallel Task agents:
For each phase in this wave, spawn:
Task(
prompt: "Implement Phase {N}: {title}
Plan: {plan_path}
Phase: {N} only
Read the plan and implement ONLY Phase {N}.
Follow Changes Required exactly.
Run Success Criteria checks.
Update plan checkboxes when done.
Files you own (ONLY modify these): {files from wave comment}
Report: what was implemented, tests passing, any deviations.",
subagent_type: "general-purpose"
)
Wait for ALL agents in the wave before starting next wave.
On failure: Stop and report:
Wave {N} execution:
Succeeded: Phase {X}, Phase {Y}
Failed: Phase {Z} -- {reason}
Options:
1. Retry failed phase only
2. Continue to next wave (skip failed)
3. Fall back to sequential for remaining phases
After each wave: Verify no file ownership conflicts via git diff --name-only.
Sequential Execution Mode
If no plan path provided, ask for one.
Implementation Philosophy
Plans are carefully designed, but reality can be messy. Your job is to:
- Follow the plan's intent while adapting to what you find
- Implement each phase fully before moving to the next
- Verify your work makes sense in the broader codebase context
- Update checkboxes in the plan as you complete sections
When things don't match the plan exactly, think about why and communicate clearly. The plan is your guide, but your judgment matters too.
If you encounter a mismatch:
- STOP and think deeply about why the plan can't be followed
- Present the issue clearly:
Issue in Phase [N]: Expected: [what the plan says] Found: [actual situation] Why this matters: [explanation] How should I proceed?
Implementation Steps
Phase-by-Phase Execution
For each phase in the plan:
-
Understand the Phase:
- Read the phase overview and success criteria
- Identify all files that need changes
- Understand the dependencies between changes
-
Implement Changes:
- Make the specified code changes
- Follow the existing code style and conventions
- Add necessary imports and dependencies
- Ensure changes are consistent across files
-
Verify as You Go:
- After implementing a component, run relevant tests
- Fix any issues before proceeding
- Don't let errors accumulate
-
Update Progress:
- Check off completed items in the plan using Edit
- Update your TodoWrite list
- Document any deviations from the plan
-
Update project state (if
.planning/exists):- After completing each phase: Update
.planning/STATE.mdwith progress - Record deviations in
.planning/phases/{phase}/SUMMARY.mdif it exists - Mark completed requirements in
.planning/REQUIREMENTS.md
- After completing each phase: Update
Verification Approach
After implementing a phase:
- Run the automated success criteria checks
- Fix any issues before proceeding
- Update your progress in both the plan and your todos
- Check off completed items in the plan file itself using Edit
Don't let verification interrupt your flow - batch it at natural stopping points.
Checkpoint Handling
When you encounter a checkpoint marker in the plan:
[CHECKPOINT:human-verify]:
- Present what was built and verification steps
- Wait for user approval
- On "approved": continue to next phase
- On issues reported: fix and re-present
[CHECKPOINT:decision]:
- Present the options with trade-offs from the plan
- Wait for user to choose
- Document the decision in plan file
- Continue with chosen path
[CHECKPOINT:human-action]:
- Clearly state what the user needs to do
- Wait for confirmation that it's done
- Verify the action took effect (if possible)
- Continue implementation
Automation-first rule: Before creating any checkpoint, verify Claude cannot perform the action itself via CLI, API, or file operations. Checkpoints verify after automation, never replace it.
Testing Strategy
Follow the plan's testing strategy:
- Write unit tests for new functionality
- Update existing tests affected by changes
- Run integration tests to verify end-to-end behavior
- Document any manual testing performed
Handling Issues
When Something Doesn't Work
-
First, verify your understanding:
- Re-read the relevant part of the plan
- Check if you've missed a dependency
- Look for related code that might provide context
-
Debug systematically:
- Use logging to understand what's happening
- Check error messages carefully
- Verify assumptions about data flow
-
If stuck, document and ask:
- Clearly describe what you expected
- Show what actually happened
- Explain what you've tried
- Ask for specific guidance
When the Codebase Has Changed
If the codebase has evolved since the plan was written:
- Document the differences you've found
- Propose adaptations that maintain the plan's intent
- Get confirmation before proceeding with major changes
Resuming Work
If the plan has existing checkmarks:
- Trust that completed work is done
- Pick up from the first unchecked item
- Verify previous work only if something seems off
Best Practices
-
Maintain Forward Momentum:
- Complete one thing fully before starting another
- Don't leave partially implemented features
- Fix issues as you encounter them
-
Communicate Progress:
- Update the plan document with checkmarks
- Use TodoWrite to track detailed progress
- Report completion of major milestones
-
Quality Over Speed:
- Ensure each change is correct and tested
- Follow existing patterns and conventions
- Don't skip verification steps
-
Document Deviations:
- If you need to deviate from the plan, document why
- Propose alternatives that achieve the same goal
- Get approval for significant changes
Completion Checklist
Before considering implementation complete:
- All phases implemented
- All automated tests passing
- Manual verification completed
- Plan document updated with all checkmarks
- Any deviations documented
- Code follows project conventions
- No TODO comments left unresolved
- Performance considerations addressed
Remember: You're implementing a solution, not just checking boxes. Keep the end goal in mind and maintain forward momentum.
More from stevengonsalvez/agents-in-a-box
frontend-design
Frontend design skill for UI/UX implementation - generates distinctive, production-grade interfaces
31commit
Create well-formatted git commits for changes made during the session
14reflect
|
2plan-tdd
Create a test-driven development plan for the project
1oracle
Best practices for using the oracle CLI (prompt + file bundling, engines, sessions, and file attachment patterns).
1gh-issue
Analyze and fix the specified GitHub issue
1