Executes implementation plans with progress tracking, checkpoint validation, and quality gates. Use after planning is complete and tasks are ready to implement.
Executes implementation plans with progress tracking, checkpoint validation, and quality gates. Use after planning is complete and tasks are ready to implement.
No implementation plan exists (use Skill(attune:project-planning) first)
Still planning or designing (complete planning phase before execution)
Single isolated task (execute directly without framework overhead)
Exploratory coding or prototyping (use focused development instead)
Integration
With superpowers:
Uses Skill(superpowers:executing-plans) for systematic execution
Uses Skill(superpowers:systematic-debugging) for issue resolution
Uses Skill(superpowers:verification-before-completion) for validation
Uses Skill(superpowers:test-driven-development) for TDD workflow
With imbue:
Uses Skill(imbue:graduated-implementation) at the ramp gate so
each increment's ambition is earned by demonstrated understanding
of the prior one, not ramped on completion alone
Without superpowers:
Standalone execution framework
Built-in checkpoint validation
Progress tracking patterns
Execution Framework
Pre-Execution Phase
Actions:
Load implementation plan
Validate project initialized
Check dependencies installed
Review task dependency graph
Identify starting tasks (no dependencies)
Validation:
✅ Plan file exists and is valid
✅ Project structure initialized
✅ Git repository configured
✅ Development environment ready
Task Execution Loop
For each task in dependency order:
1. PRE-TASK
- Verify dependencies complete
- Review acceptance criteria
- Create feature branch (optional)
- Set up task context
IMPLEMENT (TDD Cycle)
Write failing test (RED)
Implement minimal code (GREEN)
Refactor for quality (REFACTOR)
Repeat until all criteria met
VALIDATE
All tests passing?
All acceptance criteria met?
Code quality checks pass?
Documentation updated?
RAMP GATE (before the next, more ambitious task)
Invoke Skill(imbue:graduated-implementation)
Demonstrate understanding of THIS increment, sized to stakes:
CHECKPOINT
Mark task complete IMMEDIATELY (do NOT batch)
Update execution state
Report progress
Identify blockers
2.
-
-
-
-
3.
-
-
-
-
4.
-
-
low-stakes on the evidence gate (green tests plus a recorded
tradeoff), high-stakes on the human explaining the diff unaided
- On a clean demonstration, record it in the ramp ledger and
mark the rung widened; below the band, hold and split the next
task smaller instead of ramping
5.
-
-
-
-
Task Completion Discipline: Always call TaskUpdate(taskId: "X", status: "completed") right after finishing each task. Never defer completions to end of session.
Verification: Run pytest -v to verify tests pass.
Post-Execution Phase
Actions:
Verify all tasks complete
Run full test suite
Check code quality metrics
Generate completion report
Prepare for deployment/release
Record lessons learned (see below)
Record Lessons Learned (decision journal)
Implementation is where the honest lessons appear: the approach that had to be
reworked, the blocker that cost a day, the assumption from planning that did
not hold. Capture these in docs/lessons-learned.md now, blamelessly, instead
of letting them vanish into "done." Draft and confirm one entry per
substantive lesson:
If leyline is installed, invoke Skill(leyline:decision-journal) and follow
it to append a lesson entry: what_happened, what_didnt_work,
root_cause, and a concrete action. Set phase to execute. Show the
draft; append on confirmation (status starts open).
Fallback (leyline absent): append to docs/lessons-learned.md by hand using
the in-file ENTRY TEMPLATE; assign the next LL-NNN id.
Trigger this whenever execution involved rework, a failed approach, or a
blocker that exhausted the two-challenge / 3-attempt limit. A clean run with no
surprises needs no entry.
Terminal Phase Notice
This is the final phase of the attune workflow. No auto-continuation occurs after execution completes. The workflow terminates here. Unlike brainstorming, specification, and planning phases, execution does NOT auto-invoke any subsequent phase.
Task Execution Pattern
TDD Workflow
RED Phase:
# Write test that failsdeftest_user_authentication():
user = authenticate("user@example.com", "password")
assert user.is_authenticated
# Run test → FAILS (feature not implemented)
Verification: Run pytest -v to verify tests pass.
GREEN Phase:
# Implement minimal code to passdefauthenticate(email, password):
# Simplest implementation
user = User.find_by_email(email)
if user and user.check_password(password):
user.is_authenticated = Truereturn user
returnNone# Run test → PASSES
Verification: Run pytest -v to verify tests pass.
REFACTOR Phase:
# Improve code qualitydefauthenticate(email: str, password: str) -> Optional[User]:
"""Authenticate user with email and password."""
user = User.find_by_email(email)
if user isNone:
returnNoneifnot user.check_password(password):
returnNone
user.mark_authenticated()
return user
# Run test → STILL PASSES
Verification: Run pytest -v to verify tests pass.
Checkpoint Validation
Quality Gates:
- [ ] All acceptance criteria met
- [ ] All tests passing (unit + integration)
- [ ] Code linted (no warnings)
- [ ] Type checking passes (if applicable)
- [ ] Documentation updated
- [ ] No regression in other components
Verification: Run pytest -v to verify tests pass.
Automated Checks:
# Run quality gates
make lint # Linting passes
make typecheck # Type checking passes
make test# All tests pass
make coverage # Coverage threshold met
