prospec-verify

Prospec Verify Skill

Activation

When triggered, briefly describe:

• That you'll perform a comprehensive audit of the implementation
• All 5+1 verification dimensions will be checked (task completion, spec compliance, Constitution full audit, Knowledge ↔ implementation consistency, tests, and design consistency if UI scope applies)
• That the dimensions are adjudicated by two different authorities: 1/5, 4/5 and 5/5 by the deterministic prospec check engine (you interpret and narrate its verdicts, you do not decide them), 2/5 and 6 by an independent fresh-context reviewer, 3/5 by both (mechanical rule inventory, judged violations)
• A quality grade (S/A/B/C/D) with deployment recommendation will be provided

CLI Prerequisite (required)

The prospec CLI is a required file for this skill — its deterministic steps call prospec commands. Probe BEFORE any other step; there is no manual fallback.

1. Run prospec --version (Bash).
2. Command not found / not executable → STOP. Ask the user to install the prospec standalone executable — the one-click installer script from the project README (macOS/Linux install.sh, Windows install.ps1) or a release binary from GitHub Releases; prospec is NOT published to npm. Then re-run this skill.
3. Version older than 2.1.0 → STOP. Report the installed vs required version and ask the user to upgrade, then re-run this skill.

Hand-executing a CLI-owned mutation is NEVER the fallback — that re-introduces the nondeterministic serialization this contract exists to remove.

Startup Loading

1. [STABLE] Read prospec/CONSTITUTION.md — for full audit
2. [DYNAMIC] Read .prospec/changes/[name]/tasks.md — task completion status
3. [DYNAMIC] Read .prospec/changes/[name]/plan.md — design intent (skip for scale: quick/backfill — no plan by contract)
4. [DYNAMIC] Read .prospec/changes/[name]/delta-spec.md — file specifications (skip for scale: quick — no delta-spec by contract; 2/5 is not-applicable)
5. [DYNAMIC] Read .prospec/changes/[name]/proposal.md — acceptance scenarios
6. [DYNAMIC] Read .prospec/changes/[name]/metadata.yaml — current status (updated on pass; see Status Update)
7. [DYNAMIC] Load the Feature Spec requirements this change touches — for each REQ id the delta-spec names, run prospec spec show <feature> --req <ids> (Bash), the **Feature:** field giving the feature. Quote them for the 2/5 comparison; never read the whole prospec/specs/features/ directory or a whole spec file — 2/5 compares this change against the REQs it touches, and one spec can run to tens of thousands of tokens of unrelated capability record. Add --story <US-N> when a REQ's surrounding story matters. An ADDED REQ is expected to be missing here: requirements graduate into the trust zone at prospec-archive Phase 3.5, so the command reports every ADDED id as unmatched and exits non-zero — that is the designed state, never a 2/5 finding. Read the MODIFIED/REMOVED ids from the spec (they exist), and take each ADDED REQ's text from the delta-spec entry itself; --story <US-N> is what shows you the section an ADDED REQ will land in. (skip for scale: quick — no delta-spec REQs to compare)
8. [DYNAMIC] Read prospec/specs/product.md — understand product-level overview
9. [DYNAMIC] Run prospec check --json (Bash), then read the prospec-report.json file — the deterministic verdicts for Verification 1/5, 4/5 and 5/5, plus the Constitution rule inventory 3/5 audits against (the same engine the CI gate runs). --json writes the file; stdout is a human-readable summary, not JSON — take structured facts from the file. Its shape (checks keyed by id under structural.checks[], problems under structural.findings[], freshness under structural.knowledge_health.modules[], rules under structural.constitution.rules[]) is documented in references/drift-report-format.md — consult it instead of reverse-engineering the JSON. The CLI is a required file (see CLI Prerequisite — a missing engine is a STOP at the probe, never a gradable state); never adjudicate a machine dimension yourself