high-value-testing
Skill2 starsChanged 36 days agoMITView on GitHub
High-value testing: requirements and scenario bindings for application-boundary acceptance tests. Use when designing, implementing, or reviewing high-value tests, whether or not the work uses TDD.
In this repository22 other files it gives its agents.
- atddSkill
- automated-checksSkill
- bddSkill
- behavior-specificationSkill
- choose-orchestrationSkill
- codebase-designSkill
- code-reviewSkill
- compile-instructionSkill
- computer-use-wizardSkill
- gherkinSkill
- goal-loopSkill
- goal-superviseSkill
- hvtddSkill
- idiot-bossSkill
- retroSkill
- setup-engineering-skillsSkill
- tddSkill
- test-implementationSkill
- testingSkill
- ubuntu-desktop-computer-useSkill
- ubuntu-machine-configurationSkill
- writing-for-agentsSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
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 8
Use these requirements for high-value acceptance tests.
- Distinctive: line 12
Use the acceptance-test runner for the concrete acceptance examples.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
High-value testing
Use these requirements for high-value acceptance tests. They describe the selected testing approach, independently of the implementation workflow.
Application coverage
Use the acceptance-test runner for the concrete acceptance examples.
Cover successes and failures in extreme detail, including every meaningful edge case in scope. A use case normally earns many high-value unit tests.
Collaborators
Exercise the agreed public seams with real collaborators. Use no mocks.
Verification-mode annotation
Each test contains exactly one simple comment that names its verification mode: // result verification, // state verification, or // communication verification.
Scenario bindings and verification
For bindings and acceptance verification of existing or approved .feature scenarios, read Scenario execution.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

