test-maintainability-auditor
Purpose
Audit the long-term maintainability of a test suite, including duplication, brittleness, overcoupling, and poor abstractions.
Trigger this skill when
- You need automation work at this specific test level or concern rather than a vague “write some tests” request.
- You want explicit artifacts, assertions, and maintenance tradeoffs instead of brittle generated code.
- You need a reusable output that can hand off cleanly to the next testing skill.
Expected inputs
- test suite structure
- common helpers
- duplication patterns
- history of test churn
Deliverables
- maintainability findings
- refactor suggestions
- brittleness hotspots
- suite health notes
Operating procedure
- Clarify the target behavior, boundary, or automation goal and what would count as evidence.
- Structure the test asset so setup, action, and assertions are observable and separated.
- Minimize hidden assumptions around data, timing, environment, and ordering.
- Produce lean outputs with enough rationale that another agent or developer can continue the work safely.
Quality gates
- Prefer stable, explainable automation over superficially broad coverage.
- Keep assertions tied to observable outcomes, not vague expectations.
- Be explicit about flake risks, environmental dependencies, and setup or cleanup needs.
- Do not hide uncertainty; name assumptions and residual risk.
Handoff targets
- regression-suite-curator
- test-readability-reviewer
- mock-vs-stub-selector
Output style
- Be explicit about uncertainty, infeasibility, and residual risk.
- Prefer compact, explainable artifacts over bloated lists.
- Tie tests back to behaviors, contracts, or flows.
- Make expected outcomes observable.
Failure modes to avoid
- Do not over-automate unstable or poorly specified behavior without naming the risk.
- Do not create tests whose assertions are weaker than the stated goal.
- Do not bury fixture, selector, timing, or dependency assumptions.
Minimum output skeleton
## Summary
## Findings
## Structured outputs
## Coverage / rationale
## Assumptions
## Open questions
## Recommended next skill
1---2name: test-maintainability-auditor3description: test-maintainability-auditor4---5# test-maintainability-auditor67## Purpose8Audit the long-term maintainability of a test suite, including duplication, brittleness, overcoupling, and poor abstractions.910## Trigger this skill when11- You need automation work at this specific test level or concern rather than a vague “write some tests” request.12- You want explicit artifacts, assertions, and maintenance tradeoffs instead of brittle generated code.13- You need a reusable output that can hand off cleanly to the next testing skill.1415## Expected inputs16- test suite structure17- common helpers18- duplication patterns19- history of test churn2021## Deliverables22- maintainability findings23- refactor suggestions24- brittleness hotspots25- suite health notes2627## Operating procedure281. Clarify the target behavior, boundary, or automation goal and what would count as evidence.292. Structure the test asset so setup, action, and assertions are observable and separated.303. Minimize hidden assumptions around data, timing, environment, and ordering.314. Produce lean outputs with enough rationale that another agent or developer can continue the work safely.3233## Quality gates34- Prefer stable, explainable automation over superficially broad coverage.35- Keep assertions tied to observable outcomes, not vague expectations.36- Be explicit about flake risks, environmental dependencies, and setup or cleanup needs.37- Do not hide uncertainty; name assumptions and residual risk.3839## Handoff targets40- regression-suite-curator41- test-readability-reviewer42- mock-vs-stub-selector4344## Output style45- Be explicit about uncertainty, infeasibility, and residual risk.46- Prefer compact, explainable artifacts over bloated lists.47- Tie tests back to behaviors, contracts, or flows.48- Make expected outcomes observable.4950## Failure modes to avoid51- Do not over-automate unstable or poorly specified behavior without naming the risk.52- Do not create tests whose assertions are weaker than the stated goal.53- Do not bury fixture, selector, timing, or dependency assumptions.5455## Minimum output skeleton56```md57## Summary58## Findings59## Structured outputs60## Coverage / rationale61## Assumptions62## Open questions63## Recommended next skill64```