From spec-mirror
Cross-reference existing tests against the specs/ directory to find untested flows, endpoints, and invariants. Use when the user wants to see how much of the spec is actually covered by tests, before relying on the test suite as a safety net. Triggers include "spec coverage", "test coverage vs spec", "what's untested", "coverage report", "스펙 커버리지", "테스트 커버리지", "안 테스트된 거 뭐야". Produces specs/COVERAGE.md. Never modifies existing tests or specs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/spec-mirror:coverageThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Find the gaps between what the **spec describes** and what the **tests actually verify**. A 100% spec-coverage suite is a real safety net; anything less is partial.
Find the gaps between what the spec describes and what the tests actually verify. A 100% spec-coverage suite is a real safety net; anything less is partial.
This is distinct from line-coverage tools (nyc, coverage.py, go test -cover): those measure code-execution coverage. This measures specification coverage — whether each documented behavior has at least one test asserting it.
/spec-mirror:gen-tests to confirm new stubs are detected.Pre-condition: specs/ directory exists. Tests are optional — if none, the skill reports 0% and lists what should be tested.
Writes exactly one file: specs/COVERAGE.md. Never modifies tests or specs.
# Spec Coverage Report
- **Generated at:** <ISO timestamp>
- **Test framework(s):** <detected list>
- **Verdict:** [GOOD | PARTIAL | LOW]
## Summary
| Layer | Elements | Covered | Coverage % |
|----------|----------|---------|------------|
| frontend | N | N | N% |
| backend | N | N | N% |
| domain | N | N | N% |
| flows | N | N | N% |
| **Total** | **N** | **N** | **N%** |
## Stub status
| Status | Count | Meaning |
|---|---:|---|
| active todo | N | Collected by a test command, but not real coverage yet |
| inactive planning stub | N | Not collected by default; planning artifact only |
| real assertion coverage | N | Existing tests with executable assertions |
## Uncovered (🔴)
### Backend endpoints
- `POST /api/auth/oauth` — `specs/layers/backend.md#post-apiauthoauth` (no integration test found)
### Flows
- Flow: bulk-export — `specs/flows/04-bulk-export.md` (no e2e test found)
### Domain invariants
- `User.email must be unique` — `specs/layers/domain.md#user-email-uniqueness` (no unit test asserting)
## Partially covered (🟡)
*Tests exist but don't cover every documented scenario.*
…
## Possibly testing removed code (🔵)
*Tests with no matching spec element — may be obsolete.*
- `tests/legacy/old-payment.test.ts` — references no current spec element
## Suggested next steps
- Run `/spec-mirror:gen-tests` to scaffold the missing stubs above.
- Review possibly-obsolete tests; if confirmed dead, delete.
GOOD — ≥90% total coverage AND zero critical-flow gaps (e.g. auth flows).PARTIAL — 50–89% total OR at least one critical-flow gap.LOW — <50% total.Critical-flow tagging: a flow is "critical" if its file contains **Criticality:** high in its frontmatter or first 10 lines. Default: not critical.
Same detection logic as /spec-mirror:gen-tests. A project may have multiple frameworks — pick them all up.
Scan all test files (project-conventional patterns: *.test.*, *.spec.*, tests/**, __tests__/**, etc.). For each test, extract:
describe(...) / it(...) / test(...) / def test_* / func Test* / etc.Spec source, Test command, and Collection headers written by /spec-mirror:gen-tests.it.todo, it.skip, xit, describe.skip, skipped pytest tests, or *.spec-stub.* files with no real assertions are not covered. They are planned coverage.
Parse specs/layers/*.md and specs/flows/*.md. For each element, extract:
backend:POST /api/auth/signup).as: <alias> lines).→ src/...:line line — if you imports this file, that's strong signal.Heuristic matching, in priority order:
Spec source: specs/... is an explicit match (this is what /spec-mirror:gen-tests writes).A spec element with no executable match → uncovered. A spec element with only todo/skip/stub matches → planned, not covered. A test with no match → possibly obsolete.
For elements that matched at the file level, check whether every documented scenario is covered. The spec's micro-template encourages listing scenarios as bullet points or sub-headings. For each scenario, look for either:
it() whose description references it, ORit() that mentions the scenario keyword.Missing scenarios → "Partially covered" finding.
Todo-only scenarios → "Planned but not covered" finding. Do not include them in the covered count.
Render specs/COVERAGE.md. Post a chat summary: verdict, overall %, top 3 uncovered items, path to the full report.
Safe for CI / pre-commit. Never prompts.
specs/COVERAGE.md exists with the summary table.Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
npx claudepluginhub edonghyun/donghyuns-agent-tools --plugin spec-mirror