testing-doctrine
Skill7 starsChanged 4 days agoMITView on GitHub
Testing cadence, quick checks, handoff gates, nightly QA, release certification. Apply interval-specific coverage and evidence reuse when enabled; design-validation creates checks.
In this repository22 other files it gives its agents.
- AGENTS.mdAGENTS.md
- audit-and-resolveSkill
- context-pagingSkill
- coordinate-workSkill
- design-skillSkill
- design-time-triggered-skillSkill
- design-validationSkill
- diagnose-and-repairSkill
- indefinite-loopSkill
- install-dev-skillsSkill
- operate-workflowSkill
- polish-docsSkill
- run-experimentSkill
- contract-disciplineSkill
- documentation-styleSkill
- evidence-disciplineSkill
- git-disciplineSkill
- scratch-spaceSkill
- context-compaction-procedureSkill
- maintain-scratchSkill
- refine-skillSkill
- security-hygiene-checkSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
Keep a compact project catalog mapping expensive scenarios to change/symptom triggers, required platforms, target/maximum age, and release …
- Very specific: line 33
Read and update scratch records in agents/scratch/: candidate identity, selected/reused/passed/failed/blocked/deferred checks, retained …
≈ “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
Testing doctrine
Match validation to the decision at hand. Use the project's runners and acceptance contracts; explicit test prohibitions and budgets take precedence. A skipped gate remains unverified, even when committing or publishing work is authorized.
Intervals
| Interval | Required approach |
| During implementation | Run the smallest meaningful checks for the changed behavior, including a failing reproduction for repairs and the unchanged passing rerun. Use filtered tests and cheap syntax/build checks; expand when failures or uncertain impact warrant it. |
| Task completion or feature handoff | Run the project’s routine gate for the change type: current-source build, unit/contract suites, and language/configuration checks as applicable. Documentation-only work needs document checks, not unrelated runtime suites. Add acceptance scenarios triggered by the changed behavior. A quick filtered pass alone is not a routine-gate pass. |
| Scheduled staging integration | Validate the combined candidate on required platforms. Run routine coverage once, then use a bounded window to rotate complete expensive scenarios: changed behavior or reported defects first, maximum-age breaches next, then oldest-due coverage. Preserve time for rotation and cleanup; record displaced work for the next run. |
| Periodic capacity review | Compare upcoming coverage with available execution time. Set target and maximum evidence ages per scenario/platform using risk and measured cost. If the schedule cannot meet them, surface the conflict; do not silently extend validity. Consider a weekly capacity review. |
| Release-candidate stabilization | Test the production build and packaged artifact, real startup and critical user paths, supported platforms, and every required release obligation. Fix defects and rerun affected checks. Routine success alone cannot certify the candidate. |
| Promotion to main or release | Verify that acceptance evidence covers the exact candidate being promoted. Reconcile intervening changes and revalidate affected obligations. Missing required coverage blocks certification unless the responsible owner explicitly accepts a recorded limitation. |
Task completion on a developer branch, or directly on main, uses the handoff interval. A commit or push does not itself require the entire release suite; release promotion does.
Selection and evidence
- Keep a compact project catalog mapping expensive scenarios to change/symptom triggers, required platforms, target/maximum age, and release obligations. Expensive coverage runs when triggered or due; inexpensive checks remain routine. New tests must belong to a discoverable group.
- Reuse accessible passing evidence only when relevant source inputs, build flags, dependencies, environment, platform, scenario, and checker remain compatible and within maximum age. Record compatibility across intervening changes. A matching commit alone is insufficient. Avoid duplicate execution through nested runners.
- Budget complete scenarios, including setup and cleanup. Use isolated parallel workers for independent checks; serialize shared-resource and timing-sensitive work. Never shorten a scenario or weaken assertions to fit the window.
- Match proof to the claim: use actual entrypoints, rendered behavior, real services or peers, and shipped artifacts where those properties matter. Component tests and simulations establish only what they exercise. Zero matches, skipped bodies, missing capabilities, and an exit code without completion assertions are not passes.
- Preserve first failures and counterevidence. Investigate with focused checks; a passing retry without an explanation does not erase the failure. Track unresolved defects and overdue coverage across intervals.
Read and update scratch records in agents/scratch/: candidate identity, selected/reused/passed/failed/blocked/deferred checks, retained evidence, limitations, and next due work. These conventions do not install a scheduler.
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.