Appropriate use
Use during suite cleanup, feature changes, migration, onboarding, or before moving cases into a test-management system.
Scope and intent
A controlled workflow specification
This page defines the behaviour, controls, evidence, and outputs required from the skill. It does not claim that a language model can enforce security or correctness by wording alone.
Non-goals
Do not use to bulk-delete tests without owner approval or to rewrite expected behaviour from implementation alone.
- 8
- versioned workflow phases
- 3
- explicit approval gates
- 6
- defined result states
- 9
- versioned output artifacts
Material changes to the source, environment, identity, approved actions, or expected behaviour invalidate dependent approvals and require revalidation.
Workflow
The 8 phases
Each phase has explicit inputs and outputs. Approval gates are hard stops bound to exact versions and hashes.
Phase 1: Suite and source preflight Gate 1 · approve review scope
Resolve suite revision, requirements, supported platforms, recent defects, execution history, ownership, and review scope.
suite ID · revision · source requirements · owner · history
Phase 2: Inventory and traceability
Map case IDs, titles, requirements, risks, platforms, priorities, preconditions, data, automation links, and last execution.
test map · orphan cases · duplicate IDs · missing source
Phase 3: Correctness review
Check that expectations match approved requirements, steps are executable, preconditions are sufficient, and cases do not depend on hidden knowledge.
requirement accuracy · atomicity · observability · determinism
Phase 4: Quality and maintenance analysis
Detect vague steps, repeated setup, excessive detail, missing cleanup, brittle values, combined scenarios, outdated UI terms, and environment coupling.
clarity · maintenance · data · cleanup · portability
Phase 5: Coverage and duplication analysis
Group exact and semantic duplicates, identify gaps, distinguish intentional platform variants, and map cases to current risks.
duplicate cluster · gap · platform variant · obsolete coverage
Phase 6: Automation and layer recommendation
Recommend keep manual, automate, move to lower layer, merge, rewrite, archive, or delete with evidence and ownership.
value · frequency · determinism · layer · cost
Phase 7: Review decisions Gate 2 · approve changes
Present case-level recommendations, examples, risk of removal, proposed owners, and migration order.
keep · rewrite · merge · automate · archive · delete
Phase 8: Publish reviewed suite Gate 3 · publish revision
Create a change set, preserve old case history, update traceability, and validate that required risk coverage remains after approved removals.
change log · redirects · coverage check · new revision
Approval contract
Every gate approves an exact decision object
An approval cannot be reused after its environment, source, action plan, or approved document changes.
| Gate | Decision | Required binding |
|---|---|---|
| 1 | Gate 1 · approve review scope | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 2 | Gate 2 · approve changes | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 3 | Gate 3 · publish revision | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
Result model
Defined states prevent vague conclusions
Attempt outcomes remain separate from these workflow results. Errors, cancellations, and invalid context are never silently converted into a pass.
KEEP
The case is correct, useful, maintainable, and appropriately placed.
REWRITE
The coverage is useful but the case is unclear, brittle, incomplete, or outdated.
MERGE
The case duplicates another without a distinct risk or platform reason.
AUTOMATE OR MOVE LAYER
The behaviour is better protected through repeatable automation or a lower test layer.
ARCHIVE
The case is not currently required but should remain historically discoverable.
DELETE
The case is invalid, obsolete, or provides no distinct coverage and has approved removal.
Evidence contract
Evidence must directly support the claim
Evidence has provenance, capture context, privacy classification, retention, and integrity metadata. A convenient artifact is not automatically sufficient proof.
| Claim | Primary evidence | Required validation |
|---|---|---|
| Case identity | Suite revision and stable case ID | The reviewed case can be traced after migration. |
| Expectation | Approved requirement reference | Expected behaviour is current and sourced. |
| Execution value | History and defect linkage | The case protects a meaningful current risk. |
| Duplication | Case comparison | Differences in data, role, platform, or state are evaluated. |
| Maintainability | Step and fixture analysis | Hidden setup and brittle values are visible. |
| Removal safety | Post-change coverage map | Deleting or merging does not erase required risk coverage. |
Trust and safety
Controls that must be enforced outside the prompt
These controls belong in the runtime, connector permissions, sandbox, renderer, storage layer, and review process.
Runtime control
History preservation
Archived and replaced cases keep links and reasons.
Runtime control
No metric gaming
Case-count reduction is not treated as quality unless coverage remains.
Runtime control
Requirement integrity
The reviewer cannot rewrite behaviour to match current test steps.
Runtime control
Owner approval
Delete and merge decisions require responsible suite ownership.
Runtime control
Platform distinction
Similar wording does not make hardware or browser cases duplicates.
Runtime control
Automation realism
Only stable, valuable, executable behaviour is recommended for automation.
Decision policy
Ordered outcomes, not averaged pass counts
The first applicable high-severity outcome takes precedence. A manual override is recorded separately and never rewrites the calculated result.
REVIEW BLOCKED
Requirements, ownership, or suite revision is unavailable.
MAJOR REWORK
A material portion of the suite is invalid, duplicated, or misleading.
TARGETED CLEANUP
Useful coverage remains but selected cases need rewrite, merge, or migration.
HEALTHY
The reviewed suite is current, traceable, and maintainable.
Known limitations
Uncertainty and coverage limits remain visible
The workflow documents what it cannot prove and what further evidence would change confidence.
- Limit 1. Execution history may be incomplete or biased toward recent releases.
- Limit 2. Old cases can still encode valuable incidents not linked in the system.
- Limit 3. Automation suitability depends on environment and test architecture.
- Limit 4. Manual usability and visual exploration should not be automated solely for speed.
- Limit 5. Bulk wording changes can hide semantic differences.
- Limit 6. A suite needs continued ownership after cleanup.
Outputs
Versioned records for review and continuation
Human summaries are generated from validated structured records. They are not maintained as separate, drifting sources of truth.
review-context.jsonVersioned output produced by the workflow.
case-inventory.csvVersioned output produced by the workflow.
traceability-map.yamlVersioned output produced by the workflow.
duplicate-clusters.jsonVersioned output produced by the workflow.
case-recommendations.csvVersioned output produced by the workflow.
coverage-after-change.mdVersioned output produced by the workflow.
change-set.mdVersioned output produced by the workflow.
review-log.jsonlVersioned output produced by the workflow.
test-case-review.htmlVersioned output produced by the workflow.
artifacts/qa/test-case-review/<run-id>/ ├── review-context.json ├── case-inventory.csv ├── traceability-map.yaml ├── duplicate-clusters.json ├── case-recommendations.csv ├── coverage-after-change.md ├── change-set.md ├── review-log.jsonl └── test-case-review.html
Example
Example request and controlled output
Input
Review the legacy SCOS manual regression suite. Find duplicates, outdated steps, missing expected results, cases to automate, and cases that should be archived.
Output excerpt
Suite assessment: MAJOR REWORK Reviewed: 186 cases. Findings: - 31 semantic duplicates - 22 cases reference removed UI - 17 cases have no observable expected result - 14 stable API-driven cases should move below UI level - 9 historical hardware cases should be archived, not deleted Safety: No case is removed until the post-change risk map confirms equivalent coverage.
Production readiness
Required before operational use
The written skill is only one layer. The repository, runtime, connectors, evidence storage, and publication path must implement these requirements.
- Required. Tool, filesystem, repository, command, secret, and network permissions are enforced outside the model.
- Required. Every source, environment, build, plan, and approval has a version or content hash.
- Required. Untrusted values are escaped, length-bounded, path-safe, and separated from executable instructions.
- Required. Attempt outcomes, scenario verdicts, workflow decisions, and publication status remain separate.
- Required. Raw evidence, publishable evidence, access control, retention, redaction, and deletion are defined.
- Required. Concurrent runs use unique IDs, locks, idempotency keys, and conflict-aware updates.
- Required. Material changes invalidate dependent approvals and outcomes.
- Required. The repository validator passes before the skill is considered production-ready.
In one line
/test-case-review
Audits existing manual test cases for correctness, clarity, traceability, duplication, maintainability, execution value, automation suitability, and obsolete assumptions.