test-quality-audit
Test Quality Audit
Judge tests by signal, not volume.
The core question is: What realistic bug or regression would this catch?
If the answer is vague, trivial, controlled by the test, or unrelated to user/caller/system behavior, the test is weak.
Goal
Identify which tests protect meaningful behavior and which mostly prove mocks, fixtures, snapshots, implementation details, or coverage.
Do not ask for more tests by default. Prefer a smaller suite that fails for the right reasons.
Success Criteria
- Each judgment is tied to realistic bug-finding value.
- Meaningful behavior currently protected by the tests is identified.
- Weak, redundant, tautological, brittle, or overfit tests are named concretely.
More from marcellocurto/skills
github-issue-create
Draft and create GitHub issues with `gh`. Use for bugs, tasks, features, PRDs, specs, epics, sub-issues, blockers, and tracer-bullet vertical issue breakdowns. Draft first. After approval, create issues and approved native GitHub relationships in the same turn.
11wild-frontend
Explicit-only skill for unconstrained, highly creative frontend design. Use only when the user explicitly says to use wild-frontend or asks to invoke this exact skill. Do not trigger automatically for normal frontend, styling, beautification, product UI, design-system, or production polish requests.
8bug-fix-planner
Plan a concrete fix for a specific bug, regression, crash, failing test, error, or broken behavior without changing code. Use when the user wants a path forward from a bug report, GitHub issue, stack trace, logs, screenshots, repro steps, or failing test. Do not use for new features, broad refactors, general debugging advice, or requests to directly implement the fix.
7design-system-ui
Design and implement polished frontend UI that feels native to the existing product, codebase, component library, and design system. Use for normal production frontend work where the result should extend real project patterns rather than invent a disconnected visual direction.
7relentless-review
Relentlessly stress-test proposals, plans, implementations, designs, strategies, or answers. Use when the user asks "is this actually the best we can do?", wants assumptions challenged, edge cases explored, failure modes examined, or asks to push harder, red-team, find holes, or be relentless. The answer may be that the current work is already the best path and should not change. Do not use for proofreading, encouragement-only feedback, minor style review, or requests where the user only wants implementation.
7simplify-code-solution
Simplify code fixes and feature proposals by grounding them in real requirements and existing code. Use when a coding plan feels overbuilt, speculative, too abstract, or needs assumptions challenged before implementation.
6