Execute approved tasks
Read execution, planning, collaboration, memory, artifacts, and safety.
Entry gate
Require an approved plan, satisfied dependencies, and identifiable verification commands. Stop if the plan is stale, contradicts the specification, or overlaps unrelated user changes unsafely.
Procedure
- Execute inline by default. Select one ready task; do not mix tasks or waves in one implementation unit.
- Read the full task, linked specification clauses, required context, applicable instructions, relevant memory, and current Git status.
- Confirm allowed files and state the task contract before editing.
- For behavior changes, write the focused failing test first and observe the expected failure.
- Implement only the approved actions with the smallest sufficient change.
- Run focused verification, then the relevant broader suite.
- Inspect the complete diff for scope, correctness, safety, and prohibited behavior.
- Write the execution summary specified by execution and update state only from fresh evidence.
- Continue to the next ready task only when the current result is
COMPLETEor an acceptedCAVEATS. - After all tasks, set
REVIEW_REQUIREDand recommend$flow-simplifyor$flow-review.
Blockers and corrections
On NEEDS_ADVICE, stop edits, persist the structured question, and request one decision. For fix plans, follow the same lifecycle and enforce the maximum correction cycles. Never silently redesign scope.
Collaboration and Git
Use collaborating workers only when the user explicitly requests delegation or parallel agent work. Never assign overlapping writers and independently verify returned claims.
Do not commit, push, create a branch, clean files, or rewrite history unless the user explicitly authorizes that exact action. Leave the diff reviewable.
Output
Return task status, summary path, changed files, verification evidence, open concerns, phase state, and next valid action.