/verify — Comprehensive Validation

Forked context. This skill runs in an isolated fork — you do not have access to prior conversation history. All state must come from files on disk.

1. Locate Plan Files

1. If $ARGUMENTS specifies a task name, use it. Otherwise find the most recently modified *-ORCHESTRATOR.md in .claude/plans/.
2. Derive the matching *-PLAN.md from the same task name prefix.
3. If neither file exists, report an error and stop:

   No orchestrator or plan files found in .claude/plans/.
   Run /plan and /parallelize first.

2. Verify All Phases Marked Complete

Read the orchestrator file. Parse every ### Phase N section and check the **Status:** field.

• If any phase is not marked Complete, report which phases are incomplete and stop:

  Cannot verify — the following phases are not yet complete:
  - Phase 2: [Phase Name] — Status: Not Started
  - Phase 4: [Phase Name] — Status: In Progress
  
  Run /execute to finish execution first, or re-run /verify after completion.

3. Per-Phase Implementation Verification

For each phase in the orchestrator:

1. Read the PLAN.md reference section for that phase. Extract:

   • Goals and implementation details
   • Expected code patterns
   • Key quality criteria assigned to this phase

2. Read the orchestrator phase section. Extract:

   • Files Modified list
   • Deliverables checklist
   • Implementation Steps

3. Verify implementation matches requirements:

   • Confirm every file listed in "Files Modified" exists on disk
   • Read each modified file and check that the implementation aligns with the PLAN.md description
   • Verify each deliverable is actually implemented (not just stubbed)
   • Check that code patterns match what the plan specified

4. Check code quality against the phase's key criteria:

   • If the phase emphasizes Correctness (#1): look for missed edge cases, boundary conditions
   • If the phase emphasizes No Regressions (#4): verify existing behavior is preserved
   • If the phase emphasizes Simplicity (#5): flag unnecessary complexity
   • If the phase emphasizes Modularity (#6): check coupling and extensibility
   • If the phase emphasizes Testability (#7): verify components are independently testable
   • If the phase emphasizes Readability (#9): check that code is self-documenting

4. Run Project-Wide Validation Commands

Determine validation commands using this fallback chain:

1. Read .claude/plan-config.json — use validation.test, validation.lint, validation.typecheck
2. If no config file, check CLAUDE.md for documented commands
3. If neither, auto-detect:
   • package.json with scripts? Use the appropriate package manager (npm run, pnpm, yarn)
   • Makefile with test:/lint: targets? Use make test, make lint
   • pyproject.toml? Use pytest, ruff check .

Run each detected command:

• Tests: Run the full test suite
• Lint: Run the linter across the project
• Type checking: Run the type checker if available

Capture output from each command. Note pass/fail status and any specific errors.

5. Report Structured Results

Present results in this format:

=== VERIFICATION REPORT ===
Plan: .claude/plans/{task}-PLAN.md
Orchestrator: .claude/plans/{task}-ORCHESTRATOR.md
Phases: N total

--- Per-Phase Results ---

Phase 1: [Phase Name]
  Files: All exist
  Deliverables: [X/Y complete]
  Implementation: Matches plan | Deviations noted
  Quality: No issues | [specific concerns]

Phase 2: [Phase Name]
  ...

--- Project-Wide Validation ---

Tests:      PASS | FAIL (N failures)
Lint:       PASS | FAIL (N issues)
Typecheck:  PASS | FAIL (N errors)

--- Summary ---

[PASS] All phases verified and project-wide validation passing.

or

[ISSUES FOUND]
- Phase 2: Deliverable "unit tests for toggle" not implemented
- Phase 3: File `src/admin/colors.ts` not migrated as specified
- Tests: 3 failures in packages/frontend/src/ThemeToggle.test.ts
- Lint: 2 issues in packages/shared/src/hooks/useTheme.ts

Recommendation: [specific remediation steps]

Do NOT attempt to fix any issues found. Report them clearly so the user can decide how to proceed.