regression-curation
Skill1 starsChanged 2 months agoMITView on GitHub
Keep a regression suite fast and meaningful — prune duplicates and zombies, tier tests by feedback loop, select tests by impacted code, and enforce a suite-time budget. Use when the suite is slow, when nobody trusts it, or before adding yet another test to a bloated suite.
In this repository34 other files it gives its agents.
- a11y-auditSkill
- api-contract-testingSkill
- autonomous-explorationSkill
- bug-reproSkill
- chaos-resilienceSkill
- ci-wiringSkill
- contract-testing-pactSkill
- coverage-ratchetSkill
- database-testingSkill
- e2e-authoringSkill
- environment-paritySkill
- exploratory-chartersSkill
- false-positive-hunterSkill
- flake-forensicsSkill
- i18n-l10n-testingSkill
- load-and-stressSkill
- mutation-proofSkill
- never-break-prodSkill
- payment-testingSkill
- perf-budgetSkill
- qa-triageSkill
- release-gateSkill
- responsive-mobile-testingSkill
- risk-mapSkill
- root-cause-protocolSkill
- security-regressionSkill
- smoke-and-sanitySkill
- state-machine-testingSkill
- test-data-managementSkill
- test-strategySkill
- tracking-testingSkill
- transactional-email-testingSkill
- unit-test-authoringSkill
- visual-regressionSkill
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 25
Delete on sight, no ceremony:
- Very specific: line 44
Test selection: run only what the diff can affect (vitest related, jest --changedSince, dependency-graph selection).
≈ “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
Regression Curation
Suites die two deaths: too slow to run, or too noisy to believe. Both are curation failures, and both are reversible.
Tier by feedback loop
| Tier | Budget | Runs | Contents |
| T0 smoke | < 90s | every push | build is alive (smoke-and-sanity) |
| T1 core | < 8 min | every PR | all P0 risks, unit + API, a handful of E2E journeys |
| T2 full | < 40 min | merge to main | everything else, all browsers, all breakpoints |
| T3 deep | nightly | scheduled | soak, load, mutation, full a11y, cross-browser matrix |
A PR that waits 40 minutes for feedback gets merged without reading the result. Suite time is a quality feature: budget it, measure it, defend it.
Prune
Delete on sight, no ceremony:
- Zombies — cover removed features and still pass (
FP-21). - Duplicates — n tests that always fail together cover one behavior; keep the clearest.
- Vacuous — everything on the
false-positive-hunterP0 list. A deleted false positive is a net increase in suite trust. - Permanently skipped — a test skipped for more than a sprint is a lie in the report. Fix it or delete it; either way the pretense ends.
- Redundant E2E — an E2E test whose assertion is fully covered by an API test. Push it down the pyramid; you keep the coverage and buy back minutes.
Record what you deleted and why in .qa-supreme/state.md. Deletion without a record reads as
carelessness later.
Speed levers, in order of payoff
- Push coverage down a level (E2E -> API -> unit). Biggest win, always.
- Parallelize and shard (
--shard=1/4), with per-worker data isolation. - Reuse expensive setup: auth
storageState, containers, migrated database per run. - Test selection: run only what the diff can affect (
vitest related,jest --changedSince, dependency-graph selection). Keep the full suite on main — selection is for the PR loop. - Cache dependencies and browsers in CI before optimizing test code.
Guard the ratchet
Track suite duration per run and fail the build if T1 exceeds its budget. Same discipline as
coverage-ratchet, applied to time — otherwise the budget erodes one test at a time.
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.