tdd
Skill1 starsChanged 16 days agoMITView on GitHub
Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.
We split this skill into the rules it gives an agent
11 rules. 0 are common, 11 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 179 edited versions we read keep these.
11
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
When fixing a bug with a clear, cheap test path, make the broken behavior executable before changing production code.
- Distinctive: line 16
Choose the narrowest executable check: Prefer the closest unit, component, integration, or regression test already used for that codepath.
- Distinctive: line 17
Write the failing test first: Add the smallest focused test that would have caught the bug.
- Distinctive: line 24
Use the closest executable regression check instead: a targeted script, manual reproduction command, browser automation, snapshot …
- Distinctive: line 26
Prefer no new test over a bad test.
- Distinctive: line 30
Do not change tests merely to match a wrong implementation.
- Distinctive: line 31
Do not weaken existing assertions unless the expected behavior has genuinely changed and the reason is clear.
- Distinctive: line 32
Keep the regression test focused on the bug.
- Distinctive: line 33
If the bug is flaky, make the test deterministic where possible and document the signal being locked down.
- Distinctive: line 34
If the bug exposes a broader class of failures, first land the focused regression path, then consider additional sibling coverage.
- Distinctive: line 42
If failing-before evidence could not be demonstrated, state why and describe the closest regression check used instead.
“Common” is measured: kept by at least 6 in 10 of the 179 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
TDD Bug Fix
When fixing a bug with a clear, cheap test path, make the broken behavior executable before changing production code. The goal is a focused regression test that fails before the fix and passes after it.
Do not force a test when it would be impractical. If the available test would require broad harness setup, brittle mocks, slow end-to-end infrastructure, production-only state, vague reproduction steps, or large unrelated fixture churn, skip adding a new test and use the closest useful verification instead.
Workflow
- Understand the bug. Identify the intended behavior, current behavior, affected path, and smallest observable reproduction.
- Choose the narrowest executable check. Prefer the closest unit, component, integration, or regression test already used for that codepath. If no practical test path is obvious, do not create one from scratch just to satisfy the workflow.
- Write the failing test first. Add the smallest focused test that would have caught the bug. The test should encode intended behavior, not mirror the current implementation.
- Run the new test before fixing. Confirm it fails for the intended reason. If it passes or fails for an unrelated reason, correct the test or reproduction before editing the implementation.
- Fix the bug. Make the smallest production change that satisfies the intended behavior while preserving nearby contracts.
- Rerun the regression test. Confirm the test now passes.
If a Failing Test Is Impractical
Use the closest executable regression check instead: a targeted script, manual reproduction command, browser automation, snapshot comparison, log assertion, or focused integration check.
Prefer no new test over a bad test. A bad test is one that mostly tests mocks, encodes current implementation details, depends on timing or unrelated global state, needs expensive infrastructure for a small fix, or would be deleted immediately after proving the fix.
Guardrails
- Do not change tests merely to match a wrong implementation.
- Do not weaken existing assertions unless the expected behavior has genuinely changed and the reason is clear.
- Keep the regression test focused on the bug. Avoid broad fixture churn or unrelated coverage expansion.
- If the bug is flaky, make the test deterministic where possible and document the signal being locked down.
- If the bug exposes a broader class of failures, first land the focused regression path, then consider additional sibling coverage.
Final Response
Report the evidence, not just the outcome:
- Name the failing-before test or executable check and the failure it produced.
- Name the passing-after test run and any nearby validation performed.
- If failing-before evidence could not be demonstrated, state why and describe the closest regression check used instead.
Trending
Cooling: 0 new projects took it in the last 4 weeks, 0× the 4 weeks before.thin data
Other versions201 projects use a version of this.
Word for word · 14
- backnotprop/pstack★ 3.3k100% same
- uzairansaruzi/p3-stack★ 126100% same
- dsebban/skills★ 71100% same
- mariusflorescu/pstack-t3★ 9100% same
- adjohn/pstack★ 4100% same
- alexnthnz/keel★ 4100% same
- itsyasirkhandev/skills★ 4100% same
- lucasheriques/pstack★ 3100% same
- fullerzz/agent-skills★ 2100% same
- PickleBoxer/pstack★ 1100% same
4 more not listed
Edited · 6
- jtaroreh/agystack★ 12891% same
- overextended/skills★ 2279% same
- Scino/fstack★ 1876% same
- creedants/pstack-t3★ 1799% same
- kkgogogo17/pi-pstack★ 985% same
- danjdewhurst/dotclaude★ 685% same
Wrote their own version · 181
- mattpocock/skills★ 309ksame name
- Yeachan-Heo/oh-my-claudecode★ 40ksame name
- Yeachan-Heo/oh-my-claude-sisyphus★ 40ksame name
- QuivrHQ/quivr★ 40ksame name
- ryoppippi/ccusage★ 19ksame name
- ccusage/ccusage★ 19ksame name
- MODSetter/SurfSense★ 17ksame name
- GreyDGL/PentestGPT★ 16ksame name
- open-metadata/OpenMetadata★ 16ksame name
- prowler-cloud/prowler★ 15ksame name
171 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use poteto-mode and setup-pstack.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
jtarorehSkillpoteto-mode
poteto's agent style for concise, detailed responses, deliberate subagents, unslopped prose, simple code, and verified work. Use for poteto, /poteto-mode, or requests to work in this style.
Also in 5 projects that use this
bnemaSkillsetup-pstack
Configure which Pi models pstack uses per role. Detects available provider/model specs and writes pstack's user configuration. Use for /setup-pstack, "configure pstack models", or changing pstack model choices.
Also in 22 projects that use this
In this repository58 other files it gives its agents.
- verify-herdr-orchestratorSkill
- architectSkill
- arenaSkill
- automate-meSkill
- benchmark-checklistSkill
- blast-radiusSkill
- broSkill
- control-cliSkill
- control-uiSkill
- correctSkill
- create-formal-verification-skillSkill
- create-verification-skillSkill
- deslopSkill
- figure-it-outSkill
- herdr-orchestratorSkill
- howSkill
- interrogateSkill
- in-your-own-wordsSkill
- ketchupSkill
- maintain-formal-verification-skillSkill
- maintain-verification-skillSkill
- no-commentsSkill
- poteto-modeSkill
- principle-attack-the-premiseSkill
- principle-boundary-disciplineSkill
- principle-build-the-leverSkill
- principle-encode-lessons-in-structureSkill
- principle-exhaust-the-design-spaceSkill
- principle-experience-firstSkill
- principle-explain-the-numberSkill
- principle-fix-root-causesSkill
- principle-foundational-thinkingSkill
- principle-guard-the-context-windowSkill
- principle-laziness-protocolSkill
- principle-make-operations-idempotentSkill
- principle-migrate-callers-then-delete-legacy-apisSkill
- principle-minimize-reader-loadSkill
- principle-model-the-domainSkill
- principle-never-block-on-the-humanSkill
- principle-outcome-oriented-executionSkill
- principle-prove-it-worksSkill
- principle-redesign-from-first-principlesSkill
- principle-separate-before-serializing-shared-stateSkill
- principle-sequence-verifiable-unitsSkill
- principle-subtract-before-you-addSkill
- principle-test-behavior-not-implementationSkill
- principle-type-system-disciplineSkill
- pstack-herdrSkill
- recallSkill
- reflectSkill
- sharpenSkill
- show-me-your-workSkill
- swarmSkill
- teachSkill
- technical-writingSkill
- typescript-best-practicesSkill
- unslopSkill
- whySkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.