Test Suite Health Analysis
When you need test suite health analysis candidates from CI run history, duration distributions, reruns, quarantine lists, duplicate tests, maintenance records, coverage, and defect evidence.
StatusStable
TypeAtomic Skill
DomainSoftware testing
SDLCTest design
Good forQA
LanguageChinese / English
EvalsEvals ✓
Synced2026-09-15
Why this Skill
It turns this Skill's method into a quality input that can be executed, reviewed, and reused.
- Do not execute tests, assume missing rules, versions, thresholds, data, or outcomes, or treat candidate counts as coverage proof.
- File presence, names, design declarations, and Eval configuration are not runtime evidence.
- Mark unknowns unassessed, blocked, or pending clarification instead of filling them with convention.
- Do not turn a method name, file presence, or candidate count into test execution, coverage, pass, or release evidence when scope or evidence is incomplete.
When to use
Use this Skill
- When you need test suite health analysis candidates from CI run history, duration distributions, reruns, quarantine lists, duplicate tests, maintenance records, coverage, and defect evidence.
- When you need selection rationale, applicability constraints, evidence gaps, and the smallest validation action.
- When inputs are incomplete but a bounded first pass can preserve blocked or unassessed boundaries.
Common pitfalls
- Do not turn a method name, file presence, or candidate count into test execution, coverage, pass, or release evidence when scope or evidence is incomplete.
- Do not fill in missing rules, thresholds, data, environments, or results from convention; preserve unassessed, blocked, and pending items.
- Do not expand this specialist design or review into a complete strategy, full test cases, runtime execution, or a release decision.
Input
Minimum Input
- Read prompts/test-suite-health-analysis.md and provide the objective, scope, material, environment, and evidence.
Recommended Input
- Project goal
- Test scope
- Constraints
Optional Context
- Relevant code or configuration
- Historical results
- Logs and metrics
Output
The output follows this Skill's method and makes facts, assumptions, risks, and next steps explicit.
These are the Skill's expected output requirements, not evidence that it ran in a real project.
- 01Read prompts/test-suite-health-analysis.md and provide the objective, scope, material, environment, and evidence.
- 02Complete the known, missing, conflicting, stale, out_of_scope, and assumptions input audit before findings.
- 03Record TSH-## with the subject, preconditions, concern, source evidence, and validation, plus impact/priority, owner role, close condition, and evidence state.
- 04Preserve conflicts, unknown constraints, and open questions when evidence is incomplete.
How It Works
- 01Read prompts/test-suite-health-analysis.md and provide the objective, scope, material, environment, and evidence.
- 02Complete the known, missing, conflicting, stale, out_of_scope, and assumptions input audit before findings.
- 03Record TSH-## with the subject, preconditions, concern, source evidence, and validation, plus impact/priority, owner role, close condition, and evidence state.
- 04Preserve conflicts, unknown constraints, and open questions when evidence is incomplete.
Install & Quick Start
Install command / SHELL
npx skills add \
https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/test-suite-health-analysis
-gtest-suite-health-analysis.prompt
@skill test-suite-health-analysis
Using the current project context, produce an actionable result following this Skill.
Additional context:
[Paste project context or requirement]---
name: test-suite-health-analysis
description: Use this skill when you need to assess test-suite health from duration, flakiness, duplication, quarantine, and maintenance evidence; triggers include 测试套件健康分析 and test suite health analysis.
---
# Test Suite Health Analysis
identify test-suite health risks from run history, duration, flakiness, duplication, isolation, and maintenance records. Produce TSH-## findings. This Skill organizes traceable test-suite governance candidates only; it does not execute tests or turn a design inventory into coverage, pass, or release evidence.
## When to Use
- When you need test suite health analysis candidates from CI run history, duration distributions, reruns, quarantine lists, duplicate tests, maintenance records, coverage, and defect evidence.
- When you need selection rationale, applicability constraints, evidence gaps, and the smallest validation action.
- When inputs are incomplete but a bounded first pass can preserve blocked or unassessed boundaries.
Do not use it to execute tests, invent behavior conclusions, replace a complete strategy, or accept risk for a Human.
## Output Format Options
- Use Markdown by default; use tables, JSON, or CSV only when explicitly requested or required by the delivery format.
- Separate static analysis, unexecuted work, evidence states, and Human decisions; keep items unassessed, blocked, or NOT_RUN when runtime evidence is absent.
## How to Use
1. Read prompts/test-suite-health-analysis.md and provide the objective, scope, material, environment, and evidence.
2. Complete the known, missing, conflicting, stale, out_of_scope, and assumptions input audit before findings.
3. Record TSH-## with the subject, preconditions, concern, source evidence, and validation, plus impact/priority, owner role, close condition, and evidence state.
4. Preserve conflicts, unknown constraints, and open questions when evidence is incomplete.
## Core Constraints
- Do not execute tests, assume missing rules, versions, thresholds, data, or outcomes, or treat candidate counts as coverage proof.
- File presence, names, design declarations, and Eval configuration are not runtime evidence.
- Mark unknowns unassessed, blocked, or pending clarification instead of filling them with convention.
- Do not edit requirements, code, test assets, or target systems.
## Pre-delivery Check
- [ ] Recorded the known, missing, conflicting, stale, out_of_scope, and assumptions input audit.
- [ ] Every TSH-## has source, evidence state, impact/priority, owner role, close condition, and validation.
- [ ] Facts, inferences, recommendations, unexecuted work, and Human decisions remain separate.
- [ ] Findings are not execution results, coverage proof, or release claims.
## Reference Files
- Read evals/eval.yaml and matching cases for regression; configuration does not prove project results.
- Use evals/trigger-prompts.csv and evals/local-rules.json for trigger checks; missing skill.selection evidence is BLOCKED.
## Common Pitfalls
- Do not turn a method name, file presence, or candidate count into test execution, coverage, pass, or release evidence when scope or evidence is incomplete.
- Do not fill in missing rules, thresholds, data, environments, or results from convention; preserve unassessed, blocked, and pending items.
- Do not expand this specialist design or review into a complete strategy, full test cases, runtime execution, or a release decision.
## Best Practices
- Complete the six-part input audit before selecting the smallest traceable and verifiable finding scope.
- Keep the source, evidence state, impact/priority, owner role, close condition, validation method, and residual risk for every finding.
- Write validation suggestions as next actions; do not upgrade package structure, candidate counts, or local Eval configuration into real quality conclusions.