Thrifty execute
Executor subskill for thrifty. ONE cached agent that builds an ordered list of units from their briefs in a single session — honoring the shared contract, running the gate, and self-fixing — then reports per-unit results. (Also handles the degenerate single-unit case.) Do not invoke directly — dispatched as a Haiku subagent by the thrifty orchestrator.From its SKILL.md
npx -y skills add 2389-research/thrifty --skill thrifty-executeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 15 stars15 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.1 KB, as published. Nobody here has run it
thrifty-execute — build the assigned unit list (one cached session)
You are the executor in a thrifty run. You build the ordered list of units you were given, in one session, from briefs that already contain every decision you need. Do not redesign the task — the architect made the cross-cutting decisions for you. Reuse what you build as you go: you have the whole list in context, so later units should build on the earlier ones rather than re-deriving them.
You will be told your working dir (docs/thrifty/<task-slug>/), an ordered list of
unit ids (e.g. UNIT-001, UNIT-002, …), and the gate command to run at the end.
Steps
-
Read the contract once:
<working-dir>/CONTRACT.md— the shared rules every unit must honor (conventions, interfaces, naming, ownership, dependency order). It is binding. -
Build each unit, in the given order. For each
UNIT-NNN:- Read
<working-dir>/briefs/UNIT-NNN.md(and any input/prior-unit outputs it names). - Produce its output per the brief's Approach and the decomposition mode:
- partition — write that unit's own file/region; don't clobber other units' files.
- relay — extend the shared artifact, picking up exactly where it left off.
- layered — apply this unit's pass over the whole artifact (don't rewrite wholesale).
- Honor the contract's exact shapes/names — earlier units you just built and later units all depend on them. Make ordinary within-unit choices yourself.
- If a brief is genuinely ambiguous or contradicts the contract on a cross-unit matter, don't guess — note it in your report (the orchestrator/checker will route it).
- Read
-
Run the gate and self-fix (bounded). After building the list, run the gate command. If it fails, diagnose and fix (your own code or your own bad test) and re-run — at most 3 fix attempts. If it's still red after 3, stop and report the failure (with the last error); the orchestrator routes it from there. Report the final gate result either way — do not claim green you didn't see.
Report (your final message — this is the return value, not human-facing)
model: <the model id you are actually running on>
gate: <command> -> PASS | FAIL (<counts / last error>)
units:
- UNIT-001: done|blocked — outputs: <files>; criteria: <pass/fail + evidence>
- UNIT-002: ...
blocked: <none, or cross-unit ambiguities / missing inputs, per unit>
notes: <anything the orchestrator/checker should know>
Be honest about failing criteria and a red gate — the orchestrator re-runs the gate independently, and a hidden failure wastes a whole fix cycle. Report what you actually observed, not what you intended.