Task Execution Simple

Use after task-preparation has finished task-local docs and routine follow-up, and the task is ready for straightforward direct execution.

Owns branch/worktree isolation, readiness, implementation edits, verification, docs/status updates caused by implementation, implementation review, and branch closing. Does not own roadmap decomposition or task-local spec.md and plan.md authoring.

Required Gates

Gate	Required behavior
Branch	Default never implement on the current branch; create a dedicated task branch by default unless the user explicitly chooses otherwise or a worktree workflow is specifically needed.
Readiness	Handle branch/worktree isolation and any other pre-code readiness work before implementation edits.
Verification	Verify implementation and update docs/status in the same round when behavior, API shape, or task state changed.
Review	Stop for implementation review before destructive cleanup or branch deletion.
Closing	Resolve only any remaining hard gate such as branch deletion or destructive cleanup after implementation review.

After an implementation review pause, treat any clear forward-motion message as approval to follow the recommended non-destructive next step. Ask a separate approval question only for hard gates.

Branch Isolation

• Default to creating a dedicated task branch in the current workspace.
• Use a worktree workflow only when the user explicitly wants one or when parallel or high-conflict execution makes a separate workspace specifically valuable.
• User explicitly asks to stay on current branch: proceed only with explicit user choice.

Branch Closing

• Use superpowers:finishing-a-development-branch for merge/PR/keep/discard options.
• Use superpowers:using-git-worktrees cleanup rules; removing a worktree does not remove its task branch.
• Confirm before deleting any branch or worktree. If merge plus cleanup is chosen, confirm whether cleanup includes deleting the fully merged task branch.
• If the user asks to move forward, keep moving through non-destructive wrap-up steps, but stop before deleting a branch or worktree.

Testing and Verification

• Follow the task-local spec.md and optional plan.md for testing and verification expectations.
• If relevant existing automated tests fail during the task, do not ignore them just because the task did not require adding new unit tests.
• Prefer fixing production code so existing tests keep expressing the same behavior.
• If existing tests need semantic changes because the task intentionally changes behavior, explain the reason and get user confirmation before changing what those tests assert.
• Small test-file repairs that preserve the original assertion intent do not need separate confirmation.

Docs Boundaries

Code is source of truth when code and docs diverge. If implementation changes behavior, API shape, task status, architecture assumptions, or stable constraints, update the relevant docs in the same round. Move stable rules out of docs/context/.

Detailed Rules and References

Use the existing execution references when needed:

• references/task-execution-detailed-rules.md

Workflow

1. Receive handoff context from task-preparation.
2. Create branch/worktree isolation and complete readiness work before code edits.
3. Implement one concrete task.
4. Verify behavior and update docs/status affected by implementation.
5. Stop for implementation review.
6. Resolve branch closing and cleanup hard gates only when explicitly confirmed.

When To Use

Use when a concrete task already has its task-local spec.md and optional plan.md, and the next work is direct implementation through the repository's simple execution path rather than delegated or specialized execution. Do not use before task-local docs are ready.

Do not use when:

• milestone/module/task structure is still being decided; use milestone-planning
• task-local spec.md or plan.md work still needs to be written or reviewed; use task-preparation
• the repository needs a delegated or specialized execution path instead of the simple direct path

Common Mistakes

• Starting implementation before branch/worktree isolation is complete
• Treating a normal forward-motion message as approval for destructive cleanup
• Rewriting roadmap or task structure here instead of routing back to milestone-planning