Implement Change

2. Execute tasks in order

For each unchecked task:

1. Understand the task and affected files
2. Implement the change
3. Validate (build/run/tests or targeted checks as appropriate)
4. Mark the task complete in tasks.md

Proceed sequentially unless reordering is clearly required for correctness.

3. Validation

• Prefer targeted checks when a full build is unnecessary
• Ensure changes align with Success Criteria in spec.md
• Ask the user to test or validate only if the agent cannot run the needed checks

4. Failure handling

If a task fails:

1. Fix obvious issues and retry once
2. If still failing: stop, explain the blocker, propose next steps, ask how to proceed

Do not introduce workarounds that change intent or degrade quality without approval.

5. Task evolution (allowed)

• Refine wording for clarity
• Split tasks into smaller steps
• Reorder tasks if needed for correctness

Do not alter task intent in a way that would change the spec.

6. Spec change handling

If implementation reveals incorrect assumptions, missing constraints, or a better approach that changes intent:

1. Propose the spec update clearly
2. Do not implement that divergent path yet
3. Wait for user approval
4. Update spec.md only after approval

7. Keep context accurate

• Keep tasks.md in sync with progress
• Add brief notes for edge cases, follow-ups, or partial work

Stop conditions

Stop and ask if:

• A task cannot be completed after one retry
• A required spec change is identified
• The task list is insufficient or conflicts with the spec

Completion

Implementation is complete when:

• All tasks are completed or explicitly resolved
• Code satisfies Success Criteria in spec.md
• No unresolved blockers remain

Then:

1. Summarize: tasks completed, deviations or notes, validation results. Be concise.
2. Ask: Should I clean up and proceed with documentation?
3. If yes: begin the document-change skill if available; otherwise document per repo conventions