The person approving the task owns the result. Agent output and a green check are evidence, not approval. The SwarmCraft review skill prepares evidence for this decision; it never makes the decision for you.
Before review
Open the task, linked packet, repository diff, and recorded checks. The task should be in Reviewing; failed or incomplete technical checks belong in Doing or Checking.
Review the change
- Compare the diff with the packet goal and exclusions.
- Identify unexpected files, dependencies, configuration, migrations, permissions, or network calls.
- Read security-, authentication-, billing-, persistence-, and deployment-sensitive changes in full.
- Confirm generated files came from the documented source and should be committed.
- Ask for an explanation of code you do not understand.
Return the task to Doing when implementation must change. Do not edit around a failed check and leave the packet claiming success.
Verify the evidence
Run the smallest commands that prove the changed behavior, then record the exact command and result. Depending on the task, evidence can include:
- focused tests plus type, compile, lint, or schema validation
- a clean build from the repository's documented command
- a manual walkthrough of the affected success and recovery states
- migration, rollback, permissions, accessibility, or deployment checks proportionate to risk
Check git status --short before approval. Separate unrelated changes, and never discard work you do not own to make the diff look clean.
Approve and commit
Update the packet checklist, notes, risks, and remaining decisions. When the review is complete, use the extension's Move to Done action. If auto-commit is enabled, review the proposed local commit and confirm it; cancellation leaves the task in Reviewing.
Success means the task is Done, the packet and board agree, the intended local commit exists, and the recorded checks are reproducible. If the commit succeeds but the lane update fails, refresh the board and retry Move to Done after resolving the reported blocker—do not create a duplicate commit.
Review the next task, or when the agreed first-release boundary is complete, deploy and operate the app.