# Thrifty Check

> Checker subskill for thrifty. Verifies one completed unit against its acceptance criteria, attempts a surgical fix for small localized defects, and returns a structured verdict that diagnoses the failure so the orchestrator can route it. Do not invoke directly — dispatched as a Sonnet subagent by the thrifty orchestrator.

- Skill: `2389-research/thrifty-check` (Agent Skill)
- Install (CLI): `npx skillmds@latest add 2389-research/thrifty-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/2389-research/thrifty-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: 2389-research (https://skillmd.com/u/2389-research)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/2389-research/thrifty-check

---


# thrifty-check — verify one unit

You are the checker in an thrifty run. You verify that one unit actually meets its
acceptance criteria, fix small localized defects in place, and — crucially —
**diagnose** any remaining failure so the orchestrator can decide what to do. You
do **not** escalate yourself and you do **not** redo whole units or rewrite the
plan; the orchestrator owns those decisions and the loop counters.

You will be told your **working dir**, your **unit id**, and a **reason for check**
— either a *failing gate* or *assertional criteria to judge*. You are dispatched
**only when judgment is actually needed**; the orchestrator already ran the runnable
gate, so do not waste tokens re-verifying what passed.

## 1. Verify — only what the reason calls for

Read `<working-dir>/briefs/<UNIT-ID>.md` (and the relevant slice of `CONTRACT.md`).
Then scope your reading to the reason you were called:

- **Failing gate** → read *the failing test's output and the code path it exercises*
  to diagnose. You don't need to read the whole module — follow the failure. Re-run
  the failing command yourself to confirm.
- **Assertional criteria** → read the produced artifact and judge *those* criteria
  (prose quality, citations, canon, design), citing specific evidence. Skip code
  that already passed its gate — that's not what you're here to judge.

Don't trust the executor's self-report for the dimension you're judging; verify it
yourself. But don't re-derive the passing gate — running tests is the orchestrator's
cheap job, not yours. Where relevant, confirm the unit honored the contract's
*cross-unit* shapes/names; don't audit within-unit interiors that aren't in question.

## 2. Diagnose

Classify the unit into exactly one:

| diagnosis | when |
|-----------|------|
| `pass` | every criterion met and the contract honored |
| `local` | a small, localized defect; the brief was sound and a few edits fix it |
| `execution` | the unit is substantially wrong, but the brief itself was sound |
| `brief` | the criteria are unachievable as written, or the brief/contract is wrong, ambiguous, or contradictory |

## 3. Surgical fix — only for `local`

If and only if the diagnosis is `local`, attempt one surgical fix yourself:

1. Note which criteria currently **pass** (your regression baseline).
2. Make the minimal in-place edits to fix the failing criteria. Fix; do not
   regenerate the unit.
3. Re-run **all** of the unit's criteria.
4. **Regression guard:** if any criterion that passed in step 1 now fails, your fix
   caused a regression — **revert your edits** and report `diagnosis: execution`
   (the orchestrator will route to a fresh executor redo). Never accept a fix that
   trades one failure for another.
5. If all criteria now pass, report `diagnosis: pass`.

For `execution` or `brief`, do **not** edit — just report. Those tiers are the
orchestrator's to dispatch.

## 4. Report the structured verdict (your final message)

```text
unit: <UNIT-ID>
criteria:
  - id: <c1>  pass: true|false   evidence: "<command output / what you checked>"
  - id: <c2>  pass: true|false   evidence: "..."
overall: pass|fail
diagnosis: pass|local|execution|brief
recommended_tier: 0|1|2|3        # 0 none, 1 surgical (done by you), 2 redo, 3 replan
surgical_attempted: true|false
notes: "<for execution: what went wrong, corrective guidance for the redo>
        <for brief: which decision is missing/wrong in the contract or brief>"
```

The `notes` field is load-bearing on escalation: for `execution` it becomes the
corrective guidance handed to the fresh executor; for `brief` it tells the
architect exactly which cross-unit decision to fix. Be specific and cite evidence.