feat: add structured status tokens to all agents and run skill

skills/check-phase/SKILL.md

@@ -13,6 +13,7 @@ Multiple reviewers examine the Maker's implementation in parallel. Each agent de
 2. **Read the actual code.** Use `git diff` on the Maker's branch. Don't review descriptions alone.
 3. **Structured findings.** Use the standardized finding format below for every issue.
 4. **Clear verdict:** `APPROVED` or `REJECTED` with rationale.
+5. **Status tokens are separate from verdicts.** The `STATUS: DONE` line signals the agent finished successfully. The `APPROVED`/`REJECTED` verdict is domain output. A reviewer can be `STATUS: DONE` with verdict `REJECTED` — that is normal. Parse both independently.
 
 ## Finding Format
 

skills/run/SKILL.md

@@ -166,6 +166,31 @@ Use `resolve_model` when spawning each agent to pass the correct model. The reso
 
 ---
 
+### Status Token Protocol
+
+Every agent ends its output with a `STATUS:` line. The orchestrator parses this to decide the next action.
+
+**Parsing:**
+
+```bash
+STATUS=$(tail -20 "$AGENT_OUTPUT" | grep -oE 'STATUS: (DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED)' | head -1)
+STATUS="${STATUS#STATUS: }"
+if [[ -z "$STATUS" ]]; then STATUS="DONE"; fi
+```
+
+**Status to action mapping:**
+
+| Status | Action |
+|--------|--------|
+| `DONE` | Proceed to next phase or agent |
+| `DONE_WITH_CONCERNS` | Log concerns in event data, proceed |
+| `NEEDS_CONTEXT` | Pause run, request missing information from user |
+| `BLOCKED` | Abort phase, report blocker to user |
+
+Include the parsed status in the `agent.complete` event data: `"status":"<STATUS>"`.
+
+---
+
 ### 1. Plan Phase
 
 #### 1a. Explorer (if standard or thorough)