regression-suite
Skill0 starsChanged 4 months agoMITView on GitHub
Map test coverage to GDD critical paths, identify fixed bugs without regression tests, flag coverage drift from new features, and maintain tests/regression-suite.md. Run after implementing a bug fix or before a release gate. ShiningPlague-adopted: adapts to the project's headless harness pattern ({{TEST_HARNESS}}, e.g. tools/<step>_<feature>_check.gd) + scene parse-checks + deferred test-framework decision.
11 other projects use a version of this, 8 of them edited.
Adopted by
Most recently taken up by
- striderZA/OpenCodeGameStudiosedited, first seen Nov 4, 2026
- takayoshitoyoda05/claude-ml-templatetheir own version, first seen Oct 20, 2026
- Donchitos/Claude-Code-Game-Studiosedited, first seen Oct 19, 2026
- venus2099/codex-game-studiosedited, first seen Oct 17, 2026
- HunLuanZhiZhu/Game-Studios-Pluginedited, first seen Oct 5, 2026
- dawn840705/claude-code-studiosedited, first seen Aug 28, 2026
Used with
Projects with it also use vertical-slice.
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.
hongyuancSkillvertical-slice
Build and evaluate a production-quality vertical slice before advancing from Pre-Production to Production.
Also in 3 projects that use this
Other versions11 projects use a version of this.
Word for word · 0
None found.
Edited · 8
- Donchitos/Claude-Code-Game-Studios★ 27k17% same
- striderZA/OpenCodeGameStudios★ 11835% same
- dawn840705/codex-code-studios★ 1732% same
- lilangMax/ClaudeCodeGameStudios★ 835% same
- hongyuanc/codex-game-studios★ 525% same
- dawn840705/claude-code-studios★ 132% same
- HunLuanZhiZhu/Game-Studios-Plugin★ 133% same
- venus2099/codex-game-studios★ 118% same
Wrote their own version · 3
- cenconq25/claude-code-app-studio★ 40same name
- takayoshitoyoda05/claude-ml-template★ 1same name
- skn-alarmas/agentic-testing★ 0same name
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.
In this repository68 other files it gives its agents.
- adoptSkill
- architecture-decisionSkill
- architecture-reviewSkill
- art-bibleSkill
- asset-specSkill
- brainstormingSkill
- bug-reportSkill
- bug-triageSkill
- code-reviewSkill
- consistency-checkSkill
- content-auditSkill
- create-architectureSkill
- create-control-manifestSkill
- create-epicsSkill
- create-storiesSkill
- day-one-patchSkill
- design-reviewSkill
- design-systemSkill
- dev-storySkill
- dispatching-parallel-agentsSkill
- estimateSkill
- executing-plansSkill
- finishing-a-development-branchSkill
- gate-checkSkill
- goal-add-minorSkill
- goal-checkSkill
- goal-setSkill
- godot-engineSkill
- helpSkill
- map-systemsSkill
- narrative-designerSkill
- project-stage-detectSkill
- propagate-design-changeSkill
- qa-planSkill
- quick-designSkill
- red-flag-scanSkill
- retrospectiveSkill
- review-all-gddsSkill
- safety-pushSkill
- scope-checkSkill
- security-auditSkill
- session-closeSkill
- setup-engineSkill
- sprint-planSkill
- startSkill
- story-doneSkill
- story-readinessSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- team-artSkill
- team-audioSkill
- team-combatSkill
- team-economySkill
- team-infraSkill
- team-levelSkill
- team-marketingSkill
- team-narrativeSkill
- team-polishSkill
- team-releaseSkill
- team-securitySkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
8 rules. 1 is common, 2 are distinctive, and 5 are very specific to this project.
1
Common
Most of the 9 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 50
No argument — run update if sprint active, else audit
- Distinctive: line 80
Test location (file:line)
- Very specific: line 114
Read {{GDD_PATH}} or per-system GDDs.
- Very specific: line 224
Ask: "May I write/update tests/regression-suite.md with the current regression suite manifest?"
- Common: line 230
After writing (if approved):
- Distinctive: line 233
If bug regression gaps > 0: "These bugs can silently return without regression tests.
- Very specific: line 234
If coverage drift detected: "Regression suite may be drifting.
- Very specific: line 259
If a cross-step regression runner is parked in system_registry.json → next_session_priorities as a deferred item, note that when it lands …
“Common” is measured: kept by at least 6 in 10 of the 9 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
Regression Suite
🌱 ShiningPlague-adopted. Originally Donchitos; battle-tested on a shipped Godot project. Upstream pattern preserved (capture-as-test + coverage drift detection + manifest at
tests/regression-suite.md); project test types added (headless script harness, Python validators, scene parse-checks).
Core principle: every fixed bug should have a regression test that would have caught it. A regression suite is not a new test category — it is a curated list of tests already in tools/ and tests/ that collectively cover critical paths and known failure points. This skill maintains that list.
Output: tests/regression-suite.md
If an artifact named here is absent: say so plainly in one line, skip that step, and continue. Never invent the file to satisfy a checklist, and never fail a close because an optional artifact was never created.
When to fire
- 🟢 After every bug fix lands — capture-as-test pattern. The bug becomes a test that would have caught it pre-fix.
- 🟢 After each step ships end-to-end — coverage gap pass. Identify which step features lack coverage.
- 🟢 On-demand — designer asks "are we covered for X?" / "do we have a regression test for the slot drift bug?"
- 🟢 Before a major refactor — confirm the existing test coverage will catch breakage.
- 🟢 Before a release gate —
/gate-check polishrequires regression suite exists. - 🟢 As part of sprint close — detect coverage drift.
Arguments
/regression-suite update— scan new bug fixes this sprint, check for regression test presence, add new tests to manifest/regression-suite audit— full audit of GDD critical paths vs existing coverage; flag paths with no test/regression-suite report— read-only status report (no writes), suitable for sprint reviews- No argument — run
updateif sprint active, elseaudit
In-scope test types (project pattern — {{TEST_HARNESS}})
| Type | Where it lives | Example |
| Headless script harness | {{TEST_HARNESS}} (e.g. tools/<step>_<feature>_check.gd) | e.g. tools/step3_your_system_check.gd |
| Headless data validation | Python script in tools/ | tools/consistency_check.py (cross-doc checks) |
| Scene parse-check | godot --headless scene.tscn parse output | entry scene loads with no SCRIPT ERROR |
| Cross-step regression runner | tools/regression_check.gd (if built — check registry) | runs all step harnesses in sequence |
| Manual smoke test | run in editor + designer eyeball | in-engine smoke test at step ship |
A full test-framework adoption (e.g. GUT for Godot) may be a deferred decision per the project's CLAUDE.md — until then, scene-based + headless-script verification.
Procedure: capture-as-test mode (fires after a bug fix)
- Identify the bug. What was the symptom? What was the root cause? What commit fixed it?
- Identify the test layer. Where would the test live?
- Pure data layer (JSON validity) → Python script
- Engine logic (apply/tick/expire) → headless GDScript harness
- Scene loading → headless scene parse check
- User-facing render → manual smoke test (no automation possible without engine running)
- Write the failing test. Reproduce the bug as a test case that would have failed PRE-fix. Verify it passes POST-fix.
- Add to the relevant harness file (or create a new harness if none exists for that domain).
- Append entry to
tests/regression-suite.mdwith:- Bug description + commit hash
- Test location (file:line)
- Critical path coverage tag (combat / map / data / etc.)
- Verify the harness runs cleanly:
godot --headless --path . --script "res://tools/<harness>.gd"shows N+1/N+1 PASS (the +1 is the new test). - Commit + push:
test(<step>): add regression for <bug short> (closes commit <hash>).
Procedure: coverage-gap mode (fires after a step ships)
- List every system/feature shipped in the step. From
system_registry.json → recently_changed_*+ the step's spec. - For each, ask: is there a test that would catch a regression?
- Classify gaps:
- 🔴 No test exists for a critical path (blocks player from playing)
- 🟠 No test exists for a feature explicitly marked in spec
- 🟡 No test for an edge case or polish detail
- Write tests for the 🔴 cases inline. Propose
/writing-plansfor 🟠+ batch if 3+ items. - Update
tests/regression-suite.mdwith new coverage rows + flag critical gaps insystem_registry.json → flagged_for_designer_review.
Procedure: on-demand audit (designer asks "are we covered for X?")
- Find the relevant tests. Grep
tools/for keywords related to X. - Read each test's assertions. Are they actually covering the behaviour, or just sanity-checking?
- Report coverage assessment: strong / partial / none, with file:line references.
- Propose new tests if gaps exist.
Procedure: full audit mode (Donchitos pattern, adapted)
For audit mode:
Step A — Load existing manifest
Read tests/regression-suite.md if it has been written. Extract total registered tests, last updated date, any flagged as STALE/QUARANTINED. The installer seeds this file, so existence proves nothing — a copy still carrying the scaffold-seed: unwritten marker near the top is the blank skeleton. If it is blank or absent: note "No regression suite registered yet — filling the seeded skeleton." Fill the seeded file in place and delete its marker line; never write a second copy beside it.
Step B — Load test inventory
Glob all test files (tools/*_check.gd, tools/*.py, tests/). For each file, note system + filename.
Step C — Load GDD critical paths
Read {{GDD_PATH}} or per-system GDDs. For each MVP-tier system, extract Acceptance Criteria, Formulas, Edge Cases. These define critical paths.
Step D — Load closed bugs
From system_registry.json → flagged_for_designer_review[] with resolved_in_commit. For each, check if a test references the bug or its scenario.
Step E — Map coverage
For each critical path/bug, assign:
| Status | Meaning |
| COVERED | Test file exists targeting this criterion's logic |
| PARTIAL | Test exists but doesn't cover all cases (happy path only) |
| MISSING | No test found for this critical path |
| EXEMPT | Visual/Feel/UI criterion — not automatable by design |
Elevate MISSING items that correspond to formulas/state machines to HIGH PRIORITY.
Step F — Detect coverage drift
- Stories completed this sprint with no test files
- New systems in registry since last regression-suite update
- GDD sections added/revised since manifest last updated
- Manifest
Last Updateddate — if gap > 2 sprints, flag stale
Output Report Format
## Regression Suite Status
**Mode**: [update | audit | report]
**Existing registered tests**: [N]
**Test files scanned**: [N]
### Critical Path Coverage (audit mode only)
| System | Total ACs | Covered | Partial | Missing | Exempt |
|--------|-----------|---------|---------|---------|--------|
| [name] | [N] | [N] | [N] | [N] | [N] |
**Coverage rate (non-exempt)**: [N]%
### Bug Regression Coverage
| Bug ID | System | Severity | Has Regression Test? |
|--------|--------|----------|----------------------|
| BUG-NNN | [system] | S[N] | YES / NO ⚠ |
**Bugs without regression tests**: [N]
### Coverage Drift Indicators
[List new systems or stories with no test coverage, or "None detected."]
### Recommended New Regression Tests
| Priority | System | Suggested Test File | Covers |
|----------|--------|---------------------|--------|
| HIGH | [system] | `tools/<step>_<bug>_check.gd` | BUG-NNN / AC-[N] |
| MEDIUM | [system] | `tools/<step>_<feature>_check.gd` | [criterion] |tests/regression-suite.md schema
# Regression Suite Manifest
> Last Updated: [date]
> Total registered tests: [N]
> Coverage: [N]% of GDD critical paths
## How to run
godot --headless --path . --script "res://tools/<harness>.gd"
python tools/consistency_check.py
## Registered Regression Tests
### [System Name]
| Test File | Test Function | Covers | Added |
|-----------|---------------|--------|-------|
| `tools/<harness>.gd:line` | `test_<scenario>` | AC-N / BUG-NNN | [date] |
## Known Gaps
| Priority | System | Suggested Path | Covers | Reason Not Yet Written |
|----------|--------|----------------|--------|------------------------|
| HIGH | [system] | `tools/<path>` | BUG-NNN | Bug fixed without test |
## Quarantined Tests
| Test File | Function | Reason | Quarantined Since |
|-----------|----------|--------|-------------------|Known regression test gaps (seed entries)
These are bugs that shipped without regression tests — every one is a future-firing of this skill:
None currently logged. Append new gap entries here as bugs ship without regression tests.
Template for new entries:
<bug name>(commit<hash>). <where the test should live + what it should assert>.
Write Output
Ask: "May I write/update tests/regression-suite.md with the current regression suite manifest?"
For update mode: append new entries; never remove existing entries (use Edit with targeted insertions).
For audit mode: rewrite the full manifest with updated coverage data.
For report mode: do not write anything.
After writing (if approved):
- For each HIGH priority gap: "Consider creating the missing regression test before the next sprint."
- If bug regression gaps > 0: "These bugs can silently return without regression tests. The next sprint should include a story to write the missing tests."
- If coverage drift detected: "Regression suite may be drifting. Consider running
/regression-suite auditat the next sprint boundary."
Verdict: COMPLETE — regression suite updated. (If user declined write: Verdict: BLOCKED.)
Collaborative Protocol
- Never remove existing regression tests from the manifest without explicit user approval
- Gaps are advisory, not blocking — surface them clearly but don't prevent other work (except at release gate)
- Quarantine is not deletion — flaky tests should be quarantined (noted in manifest), not removed; they should be fixed, and a bug filed with
/bug-reportif the cause is not obvious - Ask before writing — always confirm before creating or updating the manifest
What this skill does NOT do
- Replace
verification-before-completion(which verifies CURRENT change, not builds regression suite for FUTURE changes) - Auto-write tests without designer review on test approach (especially 🟠+ cases)
- Touch the GUT framework adoption decision — that's a future technical-director call
Cross-link
If a cross-step regression runner is parked in system_registry.json → next_session_priorities as a deferred item, note that when it lands it provides the cross-step runner this skill writes tests for.
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.

