EdbertChan Thrash → reflect + automate (no re-prompt)
Generalized from a real repo's hand-built QA loop (a swarm-grading pipeline with independent judges + a mechanical precheck): the specifics below assume some repo-owned grading/validation script and a repo-owned principle-doc skill exist already. Adapt the trigger and the "codify" target to whatever this repo actually has — the discipline (no re-prompt, fix the class, land code and doc together) transfers regardless.
When a grading/validation board comes back FAIL / NEEDS_WORK, the user
says /thrash, or token_audit.py flags intervention-must-automate
(same-type complaint, forced restatement, "you fucked up/messed up" aimed
at the agent), do not wait for a long "after every failure reflect
and automate" phrase — run the sequence below immediately. User
involvement of that class is FAIL, same as a board FAIL. The
token_audit.py trigger is already fired for you by the
engine/hooks/reflect-on-thrash/ Stop hook; this skill is what runs once
it fires.
Auto sequence (every FAIL turn)
- Reflect (short): why it shipped, the class of bug, why it was missed.
- Fix the class, not just the named instance — the ticker, the file, the one input that happened to trigger it. If this repo has a companion "assert invariants, not the last bug" skill, prefer it here.
- Codify the invariant in the relevant skill/rule/doc, in assert language ("X must always Y") — not "remember when Z broke."
- Automate a catch: one concrete mechanical check that would catch this next time (a CI gate, a mechanical precheck in the grading script, a new regression test). Prefer whatever the failing board's own recommended-fix/root-cause field already suggests.
- Re-validate if that was the active loop — do not claim fixed without a new passing board/run.
Do not
- Skip reflect on FAIL because a mechanical/automated check happened to pass.
- Ask "should I reflect?" — just do it.
- Commit or open any auto-generated automation editor unless the user asks.
- Paraphrase away a FAIL on the judgment board.
- Land step 3 (codify in the skill) without step 2 (the matching code fix) —
a documented invariant with no code enforcing it is invisible drift until
the next validation run happens to catch it. See
principle-assert-invariants-not-last-bug. Mechanically:scripts/check_codify_has_code.py(run by make-pr's preflight) fails a diff that adds rule-shaped prose to skills or rules with no code change.
Related
If there's no grading/validation board yet, just repeated failed attempts on one problem within a single live session, that's narrow-the-scope, not this skill.
If the question is instead about a done/shipped claim needing live evidence (not a FAIL/NEEDS_WORK board), that's prove-it-ship-gate.