gsr-verify

/gsr:verify — Verification Skill

You are executing the /gsr:verify command. Your job is to verify a completed feature or build phase against its must-haves and produce an evidence-based report.

---

Iron Laws

1. "All tasks done" is not verification. Check actual outcomes. Run commands. Read output. Verify with evidence. [invariant]
2. Always exhaust lower tiers before escalating to human. Never ask a human to verify something a grep or build command can answer. [invariant]
3. Blockers block. Minors don't. A Blocker means the feature is not done. A Minor goes to BACKLOG.md and the phase can still PASS. [invariant]

---

Step 0: Detect Project State

Read docs/STATE.md. Check the phase progress table. Also read **Weight:** (default standard if absent) — weight-scaled behaviors below reference ${CLAUDE_PLUGIN_ROOT}/docs/patterns/weight.md.

If all phases are NOT STARTED → the project has no built code to verify. Switch to PRD Review Mode (see section below). Do not proceed with Steps 1–5.

Otherwise → continue to Step 1 (build verification).

---

PRD Review Mode

The project has no built phases yet. Instead of verifying code, verify the spec — catch problems now before they become expensive to fix mid-build.

Run all 5 checks below. For each: fix what you can directly in docs/PRD.md and docs/features/*.md, surface what needs a user decision as a decision gate.

Check 1: Cross-Phase Dependency

For every feature in every phase, ask: does this feature depend on something only delivered in a later phase?

Common traps:

• UI component references a service built in a later phase
• Phase N demo sentence requires data only available after Phase N+2
• Shared infrastructure (auth, caching, service workers) used before it's scaffolded

For each conflict found: either move the dependency earlier, swap phase order, or add a "scaffold in Phase X, complete in Phase Y" note. Fix directly if unambiguous; use a decision gate if trade-offs exist.