Standing acceptance criteria for all skill work filed in this batch (#9-18) and going forward — not a new deliverable, a gate on how the others get executed.
The repo already has this methodology fully specified in superpowers-writing-skills (RED-GREEN-REFACTOR for skills: baseline a pressure-scenario subagent WITHOUT the skill, document verbatim rationalizations/failures, write the minimal skill addressing exactly those, re-test WITH the skill, close loopholes). It has not consistently been applied — several existing skills read as academic-review-only, never pressure-tested.
Gate for #9-18 (new skills: adr/traceability/lineage; edits: spec-driven-dev/feature-spec/tdd/debug/receiving-code-review):
RED: run a pressure scenario via subagent before writing/editing, document baseline behavior.
GREEN: write the minimal skill/edit addressing the documented gap. Token targets apply — frequently-loaded skills <200 words, others <500, still concise.
REFACTOR: re-test, close loopholes, build the rationalization table from what actually happened, not hypothetical cases.
Small robust tools over prose, where the technique is mechanizable. Per writing-skills: "if it's enforceable with regex/validation, automate it — save documentation for judgment calls." Concretely for this batch: traceability (graph edges) and lineage (git archaeology search patterns) are the two most likely candidates for a small script (scripts/) rather than pure instructions — e.g. a git log --all --grep wrapper for lineage, a graph-query helper for traceability. Don't ship a skill that's all prose when a 20-line script would make the technique actually executable instead of aspirational.
No skill ships without having been run against a subagent that didn't have it first — that's the actual failing-test-first bar, not "I read it and it looks clear."
Don't batch-deploy untested — one skill through the full RED-GREEN-REFACTOR cycle at a time, per writing-skills' own "STOP: Before Moving to Next Skill" rule.
Standing acceptance criteria for all skill work filed in this batch (#9-18) and going forward — not a new deliverable, a gate on how the others get executed.
The repo already has this methodology fully specified in `superpowers-writing-skills` (RED-GREEN-REFACTOR for skills: baseline a pressure-scenario subagent WITHOUT the skill, document verbatim rationalizations/failures, write the minimal skill addressing exactly those, re-test WITH the skill, close loopholes). It has not consistently been applied — several existing skills read as academic-review-only, never pressure-tested.
**Gate for #9-18 (new skills: adr/traceability/lineage; edits: spec-driven-dev/feature-spec/tdd/debug/receiving-code-review):**
1. RED: run a pressure scenario via subagent before writing/editing, document baseline behavior.
2. GREEN: write the minimal skill/edit addressing the documented gap. Token targets apply — frequently-loaded skills <200 words, others <500, still concise.
3. REFACTOR: re-test, close loopholes, build the rationalization table from what actually happened, not hypothetical cases.
4. **Small robust tools over prose, where the technique is mechanizable.** Per writing-skills: "if it's enforceable with regex/validation, automate it — save documentation for judgment calls." Concretely for this batch: `traceability` (graph edges) and `lineage` (git archaeology search patterns) are the two most likely candidates for a small script (`scripts/`) rather than pure instructions — e.g. a `git log --all --grep` wrapper for lineage, a graph-query helper for traceability. Don't ship a skill that's all prose when a 20-line script would make the technique actually executable instead of aspirational.
5. No skill ships without having been run against a subagent that didn't have it first — that's the actual failing-test-first bar, not "I read it and it looks clear."
Don't batch-deploy untested — one skill through the full RED-GREEN-REFACTOR cycle at a time, per writing-skills' own "STOP: Before Moving to Next Skill" rule.
The batch this bar governs (#9-18, plus #20) is complete. Closing it as satisfied, with an honest account of where it held and where it did not — since a bar that reports itself met is exactly what it exists to prevent.
Clause 5 — "no skill ships without having been run against a subagent that didn't have it first"
Held, for every skill in the batch. Twelve runs across nine issues.
And it was worth it, because the RED phase refuted the premise three times out of four.#14's two techniques, the unaided baseline already performed. #12's inline-context proposal, the baseline argued against — correctly, on drifting-sources grounds — which reshaped the feature rather than being overridden. #9's baseline wrote an ADR with a "Cost of reversal" section nobody asked for.
That result is the bar's real payoff. Without it I would have shipped four skills claiming to fix gaps that were not there, and written them up as fixes. What the RED phases did find was unglamorous and real: a -race checklist box a Python project can never tick, a rule with no answer for ImportError, a Go exemplar that teaches a pytest anti-pattern when translated literally, and a house format no model can guess.
Clause 3 — REFACTOR from what actually happened
Held, and this is where the value concentrated. The GREEN runs found 43 defects across the batch, and the ones that mattered were self-inflicted:
debug's new rule banned likelihood labels while the output template and all three worked examples still used them. "Prose loses to a format block every time."
debug's description — the only text a router sees — still described the behaviour the rewrite existed to prevent.
python.md's worked example was the evaluation task, so the run could measure copying and nothing else. The same mistake #12's run had caught hours earlier.
The adr skill contradicted itself in its first sentence.
lineage.sh printed, in its own voice, the inference its skill's anti-pattern table forbids.
None of those is findable by review. Every one came from making a model use the thing.
Clause 4 — small robust tools over prose
Held, and both nominated skills got one. lineage/lineage.sh and traceability/trace.sh, twelve tests between them. Beyond the batch, the same clause produced check-surfaces, check-session-log, check-escalation, generate-index and newer-version — the day's most durable output is gates, not documents.
The clause needs a corollary, learned the hard way today: a tool is a claim, and a claim needs probing. Two gates I shipped were falsified within hours of writing them, both by traceability's step 5:
The escalation ratchet's "this list only shrinks" — asserted in five places, enforced in none.
check-session-log grepped the file rather than the payload, so the regression it existed to prevent passed cleanly with one line of prose.
Both had tests. Both were green. Both were wrong in exactly the way #19 warns prose is wrong — "if it's enforceable with regex/validation, automate it" is not the whole rule, because an automation that does not enforce what it claims is worse than the note it replaced. It carries authority the note never had.
Clause 1-2 — RED first, minimal edit
Held. Token targets were not measured, so treat that half as unevidenced rather than met.
Where the bar did not hold
typescript.md, rust.md and java.md have never been pressure-tested. Written from knowledge, which is precisely the standard this issue rejects. Stated on #18 rather than buried.
The clean-code / solid / code-review Python references are likewise untested. Stated on #20.
"One at a time" was violated deliberately: three agents ran concurrently on disjoint skills to fit the session. No cross-contamination was observed, but I do not have evidence it is safe in general — only that it did not visibly hurt here.
What replaces this issue
Nothing, and that is the point — the bar is now in the repo rather than in a ticket. README.md's contributing steps name the pressure-test requirement as step 4, so the next person meets it before writing rather than after being told.
The batch this bar governs (#9-18, plus #20) is complete. Closing it as satisfied, with an honest account of where it held and where it did not — since a bar that reports itself met is exactly what it exists to prevent.
## Clause 5 — "no skill ships without having been run against a subagent that didn't have it first"
Held, for every skill in the batch. Twelve runs across nine issues.
**And it was worth it, because the RED phase refuted the premise three times out of four.** #14's two techniques, the unaided baseline already performed. #12's inline-context proposal, the baseline argued *against* — correctly, on drifting-sources grounds — which reshaped the feature rather than being overridden. #9's baseline wrote an ADR with a "Cost of reversal" section nobody asked for.
That result is the bar's real payoff. Without it I would have shipped four skills claiming to fix gaps that were not there, and written them up as fixes. What the RED phases *did* find was unglamorous and real: a `-race` checklist box a Python project can never tick, a rule with no answer for `ImportError`, a Go exemplar that teaches a pytest anti-pattern when translated literally, and a house format no model can guess.
## Clause 3 — REFACTOR from what actually happened
Held, and this is where the value concentrated. The GREEN runs found **43 defects** across the batch, and the ones that mattered were self-inflicted:
- `debug`'s new rule banned likelihood labels while the output template and all three worked examples still used them. *"Prose loses to a format block every time."*
- `debug`'s `description` — the only text a router sees — still described the behaviour the rewrite existed to prevent.
- `python.md`'s worked example **was the evaluation task**, so the run could measure copying and nothing else. The same mistake #12's run had caught hours earlier.
- The `adr` skill contradicted itself in its first sentence.
- `lineage.sh` printed, in its own voice, the inference its skill's anti-pattern table forbids.
None of those is findable by review. Every one came from making a model use the thing.
## Clause 4 — small robust tools over prose
Held, and both nominated skills got one. `lineage/lineage.sh` and `traceability/trace.sh`, twelve tests between them. Beyond the batch, the same clause produced `check-surfaces`, `check-session-log`, `check-escalation`, `generate-index` and `newer-version` — the day's most durable output is gates, not documents.
**The clause needs a corollary, learned the hard way today: a tool is a claim, and a claim needs probing.** Two gates I shipped were falsified within hours of writing them, both by `traceability`'s step 5:
- The escalation ratchet's "this list only shrinks" — asserted in five places, enforced in none.
- `check-session-log` grepped the file rather than the payload, so the regression it existed to prevent passed cleanly with one line of prose.
Both had tests. Both were green. Both were wrong in exactly the way #19 warns prose is wrong — *"if it's enforceable with regex/validation, automate it"* is not the whole rule, because an automation that does not enforce what it claims is worse than the note it replaced. It carries authority the note never had.
## Clause 1-2 — RED first, minimal edit
Held. Token targets were not measured, so treat that half as unevidenced rather than met.
## Where the bar did not hold
- **`typescript.md`, `rust.md` and `java.md` have never been pressure-tested.** Written from knowledge, which is precisely the standard this issue rejects. Stated on #18 rather than buried.
- **The `clean-code` / `solid` / `code-review` Python references** are likewise untested. Stated on #20.
- **"One at a time"** was violated deliberately: three agents ran concurrently on disjoint skills to fit the session. No cross-contamination was observed, but I do not have evidence it is safe in general — only that it did not visibly hurt here.
## What replaces this issue
Nothing, and that is the point — the bar is now in the repo rather than in a ticket. `README.md`'s contributing steps name the pressure-test requirement as step 4, so the next person meets it before writing rather than after being told.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Standing acceptance criteria for all skill work filed in this batch (#9-18) and going forward — not a new deliverable, a gate on how the others get executed.
The repo already has this methodology fully specified in
superpowers-writing-skills(RED-GREEN-REFACTOR for skills: baseline a pressure-scenario subagent WITHOUT the skill, document verbatim rationalizations/failures, write the minimal skill addressing exactly those, re-test WITH the skill, close loopholes). It has not consistently been applied — several existing skills read as academic-review-only, never pressure-tested.Gate for #9-18 (new skills: adr/traceability/lineage; edits: spec-driven-dev/feature-spec/tdd/debug/receiving-code-review):
traceability(graph edges) andlineage(git archaeology search patterns) are the two most likely candidates for a small script (scripts/) rather than pure instructions — e.g. agit log --all --grepwrapper for lineage, a graph-query helper for traceability. Don't ship a skill that's all prose when a 20-line script would make the technique actually executable instead of aspirational.Don't batch-deploy untested — one skill through the full RED-GREEN-REFACTOR cycle at a time, per writing-skills' own "STOP: Before Moving to Next Skill" rule.
The batch this bar governs (#9-18, plus #20) is complete. Closing it as satisfied, with an honest account of where it held and where it did not — since a bar that reports itself met is exactly what it exists to prevent.
Clause 5 — "no skill ships without having been run against a subagent that didn't have it first"
Held, for every skill in the batch. Twelve runs across nine issues.
And it was worth it, because the RED phase refuted the premise three times out of four. #14's two techniques, the unaided baseline already performed. #12's inline-context proposal, the baseline argued against — correctly, on drifting-sources grounds — which reshaped the feature rather than being overridden. #9's baseline wrote an ADR with a "Cost of reversal" section nobody asked for.
That result is the bar's real payoff. Without it I would have shipped four skills claiming to fix gaps that were not there, and written them up as fixes. What the RED phases did find was unglamorous and real: a
-racechecklist box a Python project can never tick, a rule with no answer forImportError, a Go exemplar that teaches a pytest anti-pattern when translated literally, and a house format no model can guess.Clause 3 — REFACTOR from what actually happened
Held, and this is where the value concentrated. The GREEN runs found 43 defects across the batch, and the ones that mattered were self-inflicted:
debug's new rule banned likelihood labels while the output template and all three worked examples still used them. "Prose loses to a format block every time."debug'sdescription— the only text a router sees — still described the behaviour the rewrite existed to prevent.python.md's worked example was the evaluation task, so the run could measure copying and nothing else. The same mistake #12's run had caught hours earlier.adrskill contradicted itself in its first sentence.lineage.shprinted, in its own voice, the inference its skill's anti-pattern table forbids.None of those is findable by review. Every one came from making a model use the thing.
Clause 4 — small robust tools over prose
Held, and both nominated skills got one.
lineage/lineage.shandtraceability/trace.sh, twelve tests between them. Beyond the batch, the same clause producedcheck-surfaces,check-session-log,check-escalation,generate-indexandnewer-version— the day's most durable output is gates, not documents.The clause needs a corollary, learned the hard way today: a tool is a claim, and a claim needs probing. Two gates I shipped were falsified within hours of writing them, both by
traceability's step 5:check-session-loggrepped the file rather than the payload, so the regression it existed to prevent passed cleanly with one line of prose.Both had tests. Both were green. Both were wrong in exactly the way #19 warns prose is wrong — "if it's enforceable with regex/validation, automate it" is not the whole rule, because an automation that does not enforce what it claims is worse than the note it replaced. It carries authority the note never had.
Clause 1-2 — RED first, minimal edit
Held. Token targets were not measured, so treat that half as unevidenced rather than met.
Where the bar did not hold
typescript.md,rust.mdandjava.mdhave never been pressure-tested. Written from knowledge, which is precisely the standard this issue rejects. Stated on #18 rather than buried.clean-code/solid/code-reviewPython references are likewise untested. Stated on #20.What replaces this issue
Nothing, and that is the point — the bar is now in the repo rather than in a ticket.
README.md's contributing steps name the pressure-test requirement as step 4, so the next person meets it before writing rather than after being told.