Coverage Check

<!--
Copyright 2025-2026 Simon Martinelli and the AI Unified Process contributors.
Part of the AI Unified Process — https://unifiedprocess.ai
Licensed under the Apache License, Version 2.0. See LICENSE and NOTICE.
-->

Coverage Check

Instructions

Audit the artifact $ARGUMENTS — a use case (UC-XXX) or a test case (TC-XXX) — against the code and tests that are supposed to realize it, and report the result.

This skill is the front door to the read-only uc-coverage sub-agent of this plugin. The audit checklist — how coverage units are derived, which markers to search for, how each unit is judged — lives in agents/uc-coverage.md at the plugin root (locate it with a glob for **/agents/uc-coverage.md) and is deliberately not repeated here, so the two cannot drift apart. Your job is argument parsing, delegation, faithful presentation of the report, and offering the next step.

The report is the deliverable. You do not fix what it finds.

Arguments

Everything is parsed out of $ARGUMENTS; the tokens may appear in any order.

Three parsing rules carry weight:

• A mode is only narrowed by a standalone qualifier token. In a sentence — "is UC-001 fully implemented?" — the word implemented is prose, not a mode: run both. Silently narrowing to implementation recreates the very gap this skill exists to close.
• State the resolved arguments in one line before delegating (Auditing UC-001, mode both.), so a wrong parse costs one rerun instead of producing a wrong verdict.
• If the id resolves to no file under docs/use_cases/ or docs/use-cases/ (both spellings are in use), list the near matches and ask. Never audit against a specification you inferred from code.

Workflow

1. Parse $ARGUMENTS into the id or ids, the mode, and the work-in-progress flag. With no id, go to Sweeps.
2. Confirm the specification exists — docs/use_cases/UC-XXX-*.md (also check docs/use-cases/) or docs/test_cases/TC-XXX-*.md. Stop and ask if it does not.
3. State the resolved arguments in one line.
4. Delegate the audit — see Delegation.
5. Present the returned report unchanged. When this conversation already holds an audit of the same id and mode, add the comparison — see Repeated Runs.
6. Offer the gap-closing commands — see After the Report. Then stop.

Delegation

Hand the audit to the read-only uc-coverage sub-agent of this plugin (it may appear as aiup-angular-jpa:uc-coverage). Pass exactly the id, the mode, and — when it applies — work in progress, and nothing else:

UC-001 both
UC-001 tests
UC-001 implementation work in progress
TC-001 tests

Do not add a summary of the specification, a list of the files you believe implement it, or what you expect the answer to be. The agent must find its own evidence; a caller-supplied file list is the fastest way to turn an audit into a rubber stamp.

Present the report as it came back — the heading, the score line, the full matrix, ### Gaps, ### Drift, and ### Suggested status. Do not summarize it into prose, do not drop the covered rows to save space, and do not change a verdict. The matrix is the deliverable; if you disagree with a verdict, say so underneath it and leave the row alone.

After the Report

• Turn each gap into the command that closes it: /implement for implementation gaps (backend or Angular); /spring-boot-test for backend test gaps; /vitest-test for Angular component or service test gaps; /playwright-test for browser or journey gaps. Offer them; run one only if the user says yes.
• Drift is not a gap with a known fix. For each drift item, ask the user which side is right — the specification (/use-case-spec UC-XXX adds the behaviour) or the code (/implement removes it) — and offer only the command that matches the answer. Never pick a side yourself: changing the specification to match the code, or the code to match the specification, without that decision is what sends /spec-review and /coverage-check round in circles.
• Do not close gaps yourself, and do not close one "quickly because it is only one line". A one-line fix from the auditor is still an unreviewed change to a verdict you have just issued.
• The agent cannot run builds or tests. Before repeating any Tested suggestion, ask whether the suite passes.
• Pass the ### Suggested status on as a suggestion, and name the line that would change. Do not edit the specification's **Status:** line as part of this report.

Repeated Runs

The agent starts from scratch every time and does not know its previous verdicts; you do. When this conversation already holds a report for the same id and mode, add one section under the report — the matrix itself stays exactly as the agent returned it:

### Since the last run

- Closed: BR-002, A1
- New: A3 — `PersonForm.java` changed since the last run
- Changed without a change: Step 4 Covered → Partial; neither the specification nor the files
  named in the row changed
- Still open after a fix aimed at it: Post-S-1

• A verdict that changed although neither the specification nor the evidence files changed is the auditor's judgment wobbling, not new work. Say so, and ask the user whether to act on it; do not offer a command for it.
• A gap still open after a fix aimed at it: do not offer the same command again. State what the auditor wants and what the code does, and ask the user to settle it — it may be the specification that needs to change, which is a decision, not a gap.
• When every unit is Covered or n/a, the audit is finished. Do not suggest a further run.