Testing Boss
SkillMonitoring & opsThis skill gives your AI a testing playbook so the tests it writes and reviews actually catch bugs instead of passing for the wrong reason. It covers everyday software tests as well as checks for AI features, and guides choices like where a test belongs, when to add a mock, and how to handle tests that fail unpredictably.
Available today. Use it from your connected AI after setup.
No other account needed.
After adding it, ask your AI to write, review, or generate tests for your project, or to build an evaluation suite for an AI feature. It will follow this testing guidance while it works.
Then ask your AI: use the Testing Boss skill
What your AI can do with it
- Write tests that reveal real bugs rather than passing for the wrong reason
- Review existing tests and point out ones that pass without proving anything
- Add mocks where a test needs them
- Decide where a new test belongs
- Sort out tests that fail unpredictably
- Design evaluation suites that check how well an AI feature works
What this skill tells your AI
The instructions your AI receives, as published by compozy/compozy in .agents/skills/testing-boss/SKILL.md and read by ahel’s review.
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.
Signals
- GitHub stars
- 3k
- Forks
- 177
- Last commit
- Sep 2026
ahel recommends instead
Advanced
- Catalog kind
- skill
- Gateway key
testing-boss- Source
- github.com/compozy/compozy