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