| name | minimal-test-gate |
| description | Use only after the main path exists to choose and implement 1-3 critical-path tests that prove the MVP closes the loop. Not for broad coverage goals, full E2E suites, or testing every edge case. |
| origin | ECC-derived |
Minimal Test Gate
Source Lineage
Primary inherited sources:
legacy/ecc-source/agents/tdd-guide.mdlegacy/ecc-source/skills/tdd-workflow/SKILL.mdlegacy/ecc-source/skills/verification-loop/SKILL.mdlegacy/ecc-source/skills/ai-regression-testing/SKILL.mdlegacy/ecc-source/skills/eval-harness/SKILL.mdlegacy/ecc-source/agents/code-reviewer.mdlegacy/ecc-source/commands/tdd.md
Inherited methods:
- preserve RED -> GREEN -> REFACTOR reasoning even under time pressure
- start from user journeys and stable behavior, not implementation trivia
- define the proof target before implementation whenever possible
- write a regression test for a reproduced bug before fixing it
- verify the smallest set of checks that proves readiness
- report what remains risky instead of pretending coverage is complete
When To Use
Use this after the core path is implemented and before final handoff.
If you are still before implementation, use it briefly to define the minimum proof target first, then come back after the main path exists.
Expected Outputs
- a tiny test plan
- a one-line verification standard or acceptance target
- 1-3 tests that prove the MVP works
- one short note about what is intentionally untested
Default Test Selection
Pick only the highest-signal cases:
- happy path
- one key validation or failure path
- one archetype-specific check if it proves real value
Examples:
- gateway/proxy: valid route, invalid request, upstream failure normalization
- tool agent: tool selection, invalid tool args
- retrieval: retrieval hit, empty or no-match response
- workflow: successful step sequence, early failure reporting
Test Workflow
- Write down the user journey or system journey you must prove before implementation.
- Prefer the smallest failing test that demonstrates the missing behavior.
- For a bug fix, reproduce the bug with a regression test first.
- Implement or adjust only enough code to pass that test.
- Rerun the smallest meaningful check after each fix.
- Stop once the main loop is credibly proven.
Verification First
Before writing code, define one of these:
- a minimal automated acceptance test
- a minimal regression test for the known bug
- a minimal manual verification method if the stack or timebox blocks automation
If you cannot automate first, still write down the exact proof you will use. Do not start implementation with no test target at all.
Reporting Format
- Tests selected:
- Verification standard:
- Why these tests matter:
- What remains intentionally untested:
Test Standard
- make tests small
- assert stable behavior, not implementation trivia
- prefer regression-proof tests for bugs that were actually observed
- stop once the main loop is credibly proven
What Not To Do
- do not chase coverage numbers
- do not build a full browser suite unless the prompt depends on UI behavior
- do not add tests that duplicate the contract without adding confidence
- do not spend the final 20 minutes converting a working MVP into a full pyramid
