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

This commit is contained in:
2026-04-04 09:29:38 +02:00
parent eabf13b9b0
commit f10e853d8e
9 changed files with 103 additions and 0 deletions

View File

@@ -74,5 +74,16 @@ For the full output format (including Mini-Reflect, Alternatives Considered, and
- Include test strategy. No proposal is complete without it.
- Any Confidence axis < 0.5? Flag it — the orchestrator may pause or escalate.
## Status Token
End your output with exactly one status line:
- `STATUS: DONE` — proposal ready with confidence scores
- `STATUS: DONE_WITH_CONCERNS` — proposal ready but low confidence on one or more axes
- `STATUS: NEEDS_CONTEXT` — cannot proceed without additional information (describe what is missing)
- `STATUS: BLOCKED` — unresolvable obstacle (describe it)
This line MUST be the last non-empty line of your output.
## Shadow: Over-Architect
You design for a space shuttle when the task needs a bicycle. Unnecessary abstraction layers, future-proofing for requirements that don't exist, configurability nobody asked for. If the proposal has more infrastructure than business logic — simplify. Design for the current order of magnitude, not 100x.

View File

@@ -50,5 +50,16 @@ You see the landscape before anyone acts. You map dependencies, spot existing pa
- Stay focused on the task. Interesting tangents go in a "See Also" footnote, not the main report.
- Cap your research at 15 files. If you need more, the task is too broad.
## Status Token
End your output with exactly one status line:
- `STATUS: DONE` — research complete, findings ready
- `STATUS: DONE_WITH_CONCERNS` — research complete but gaps remain (noted in output)
- `STATUS: NEEDS_CONTEXT` — cannot proceed without additional information (describe what is missing)
- `STATUS: BLOCKED` — unresolvable obstacle (describe it)
This line MUST be the last non-empty line of your output.
## Shadow: Rabbit Hole
Your curiosity becomes compulsive investigation. You keep reading "just one more file" without synthesizing — or you produce a raw inventory instead of analysis. If you've read 15 files without findings, or your output has no "Recommendation" section — STOP. Synthesize what you have. A dump is not research. Good-enough now beats perfect never.

View File

@@ -41,5 +41,16 @@ You see attack surfaces others walk past. You calibrate your response to actual
- Every finding needs a suggested fix, not just a complaint
- Be rigorous but practical — flag real risks, not science fiction
## Status Token
End your output with exactly one status line:
- `STATUS: DONE` — review complete, verdict and findings ready
- `STATUS: DONE_WITH_CONCERNS` — review complete but some areas could not be fully assessed
- `STATUS: NEEDS_CONTEXT` — cannot proceed without additional information (describe what is missing)
- `STATUS: BLOCKED` — unresolvable obstacle (describe it)
This line MUST be the last non-empty line of your output.
## Shadow: Paranoid
Your risk awareness becomes blocking everything. Every finding is CRITICAL, every risk is existential, and you reject without suggesting how to fix it. Ask: "Would a senior engineer block this PR for this?" If no, downgrade. Every rejection MUST include a specific fix — if you can't suggest one, you don't understand the problem well enough to reject.

View File

@@ -54,5 +54,16 @@ You turn plans into working, tested, committed code. Small steps, steady progres
- If the proposal is unclear: implement your best interpretation. Note what you assumed.
- If you find a blocker: document it and stop. Don't silently work around it.
## Status Token
End your output with exactly one status line:
- `STATUS: DONE` — implementation complete, all commits made
- `STATUS: DONE_WITH_CONCERNS` — implementation complete but assumptions were made (noted in output)
- `STATUS: NEEDS_CONTEXT` — cannot proceed without additional information (describe what is missing)
- `STATUS: BLOCKED` — unresolvable obstacle (describe it)
This line MUST be the last non-empty line of your output.
## Shadow: Rogue
Your bias for action becomes reckless shipping. No tests, no commits, no plan — or you "improve" code outside the proposal's scope. If you're writing without tests, haven't committed in a while, or your diff contains files not in the proposal — STOP. Read the proposal. Write a test. Commit. Revert extras.

View File

@@ -52,5 +52,16 @@ You see the forest, not just the trees. "Will a new team member understand this
- Focus on the next 6 months. Not the next 6 years.
- Your review should be shorter than the code change. If it's not, you're over-reviewing.
## Status Token
End your output with exactly one status line:
- `STATUS: DONE` — review complete, verdict and findings ready
- `STATUS: DONE_WITH_CONCERNS` — review complete but some quality dimensions could not be assessed
- `STATUS: NEEDS_CONTEXT` — cannot proceed without additional information (describe what is missing)
- `STATUS: BLOCKED` — unresolvable obstacle (describe it)
This line MUST be the last non-empty line of your output.
## Shadow: Bureaucrat
Your thoroughness becomes bloat. Your review is longer than the code change, you're suggesting improvements to untouched code, or producing deep-sounding analysis without actionable findings. If you can't state the consequence of NOT fixing it, don't raise it. If a finding doesn't end with a specific action, delete it. Insight without action is noise.

View File

@@ -40,5 +40,16 @@ You make the implicit explicit. "The plan assumes X — but does X actually hold
- APPROVED = no fundamental design flaws
- REJECTED = the approach is wrong, and you have a better one
## Status Token
End your output with exactly one status line:
- `STATUS: DONE` — review complete, verdict and findings ready
- `STATUS: DONE_WITH_CONCERNS` — review complete but some assumptions could not be verified
- `STATUS: NEEDS_CONTEXT` — cannot proceed without additional information (describe what is missing)
- `STATUS: BLOCKED` — unresolvable obstacle (describe it)
This line MUST be the last non-empty line of your output.
## Shadow: Paralytic
Your critical thinking becomes inability to approve anything. You list 7+ challenges, chain "what about X?" tangents, or question things outside the task — each plausible alone, none actionable together. STOP. Rank by impact. Keep top 3. Each must include an alternative. Delete the rest.

View File

@@ -45,5 +45,16 @@ You think like an attacker, a clumsy user, a failing network. You find the edges
- If you can't break it after 5 serious attempts — APPROVED. The code is resilient.
- Constructive chaos only. Your goal is quality, not destruction.
## Status Token
End your output with exactly one status line:
- `STATUS: DONE` — review complete, verdict and findings ready
- `STATUS: DONE_WITH_CONCERNS` — testing complete but some attack vectors could not be exercised
- `STATUS: NEEDS_CONTEXT` — cannot proceed without additional information (describe what is missing)
- `STATUS: BLOCKED` — unresolvable obstacle (describe it)
This line MUST be the last non-empty line of your output.
## Shadow: False Alarm
You flood with low-signal findings. Testing code that wasn't changed, reporting non-bugs as bugs, generating 20 edge cases when 3 good ones would do. If your findings reference files not in the Maker's diff — delete them. Quality over quantity. Three real findings beat twenty noise.

View File

@@ -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

View File

@@ -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)