About testing-boss
testing-boss is a skill that guides agents through choosing and evaluating software tests. It emphasizes observable behavior, existing test layers, and evidence-based delivery checks.
Key features
- 01Select tests at the layer that owns the behavior
- 02Assert observable results
- 03Use mocks at I/O boundaries
- 04Evaluate regression and AI-generated tests
- 05Run relevant checks and delivery gates
Use cases
- 01Choosing a test suite for a changed invariant
- 02Assessing tests generated by an agent
- 03Investigating flaky or brittle tests
- 04Validating regression fixes before delivery
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ marcioaltoe/ skills --skill testing-bossAfter installing, type/testing-bossin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
references/ai-writes-tests.mdantipatterns.mdci-automation.mdfoundations.mdllm-eval.mdpatterns.mdsources.mdDetails
From the project READMETesting Boss
Choose tests that can expose the changed behavior's failure. Use the existing suite at the lowest layer that can observe the invariant; reuse fixtures and utilities before creating new files.
- Assert observable results, not mock behavior or implementation structure. Keep mocks at unit-test I/O boundaries; use real integration evidence for integration claims.
- When a test exposes a regression, fix production code. Change an incorrect test only with evidence that its contract is wrong or intentionally changed; preserve valid coverage.
- Existing tests or stronger build/codegen/link/render checks may already own the invariant. Do not add prose, CSS, generated-output, configuration, or snapshot tests without a real artifact contract and a reason the owning gate is insufficient.
- Coverage and mutation scores help find blind spots; they do not replace a behavioral oracle. Do not add production branches or methods solely for tests.
- Run affected checks, then the project's delivery gates. Reuse results for unchanged inputs and expand only for a failure, relevant edit, or unresolved risk. Match regression reproduction to the failure; avoid a second ceremony when red/green evidence already exists.
References by Question
Read the relevant section, including its contract dependencies, when the question arises; test authorship by an agent does not itself require every reference.
| Question | Reference |
|---|---|
| Which layer or suite owns the invariant? | references/foundations.md |
| How should selectors, waits, data, or mocks work? | references/patterns.md |
| Why is a test brittle or passing for the wrong reason? | references/antipatterns.md |
| How should agent-generated tests be evaluated? | references/ai-writes-tests.md |
| How should flakiness or contract/property/mutation checks be handled? | references/ci-automation.md |
| How should an LLM/agent outcome be evaluated? | references/llm-eval.md |
references/sources.md holds supporting sources. Completion evidence can be a concise command/result summary; no separate report is needed unless the task's artifact contract requires one.