Testing strategy
40 portable full-SDLC agent skills for Claude Code, Cursor, Codex, and GitHub Copilot — deep-work autonomy, contract-guard for external interfaces, TDD, code review, PR babysitting. Install: npx github:IcodeNet/agent-skills
npx -y skills add IcodeNet/agent-skills --skill testing-strategyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Designs test coverage plans and verification gates. Use when writing tests, planning coverage, asking how to test a change, or designing a test plan before implementation. Do not use for red-green-refactor implementation loops (use tdd) or stop-the-line failure triage (use debug).
SKILL.md
1.6 KB, as published. Nobody here has run it
Testing Strategy
Pick the smallest layer that catches the risk. Encode gates before coding.
Workflow
- Name the risk — what breaks for users or contracts if this change is wrong?
- Choose layer — unit → component → integration → e2e → mutation/property. Prefer the lowest layer that would have caught the bug. See
references/layer-matrix.md. - Write the plan — for each behavior: test name, command, pass/fail check.
- Regression first for bugs — failing test before fix.
- Feature/bug sign-off — include behavior verification beyond smoke (targeted e2e or exploratory checklist with expected outcomes).
- Strengthen — mutation, property, or contract tests when logic is high-risk or shared.
Constraints
- Prefer the project's package scripts; do not invent ad-hoc runners or silence output.
- Smoke-only green is not enough to claim “fixed” or “delivered” when user-visible behavior changed.
- Prefer behavior assertions over implementation-detail tests.
Verification
- Each planned behavior has a named test + command
- Layer choice justified (not “e2e for everything”)
- Sign-off gates listed for the change type
- Blockers stated if a gate cannot run