| name | goal-verifier |
| description | Goal-backward verification — validates implementation results match stated goals using 4-level substantiation (exists/substantive/wired/data-flow) |
| user-invocable | false |
Goal Verifier
Validates that implementation RESULTS match stated GOALS. Works backward from goals to code. Complements code reviewers (which check code quality) — this checks: does it actually work?
Phase 0: Load Project Context
Read if exists:
AGENTS.md or CLAUDE.md — project conventions- The implementation plan/spec that was executed
git log --oneline -10 — recent commits
Verification Discipline
- No approval without fresh evidence. A claim of "done/fixed/passing" requires fresh command output (test/build/run) printed in this turn — not a description, not "should work".
- Hedge words auto-reject. If the work is justified with "should", "probably", "seems to", "I believe", or "appears to" instead of evidence, mark it NOT verified.
- Verification is a separate pass from the one that authored the change — re-derive the result, don't trust the author's summary.
- Work is done when verification passes — not when it compiles. A missing "yes" means "no".
When to Use
- After Phase 5 (Test) in
dev-orchestrator — before review
- After completing an implementation plan
- As part of the
review-orchestrator pipeline for feature branches
4-Level Substantiation
For each stated goal, verify through 4 levels:
Level 1: EXISTS
Does the artifact exist?
- Check files present:
test -f "path/to/file"
- Check functions exist:
grep -n "func HandleX" file.go
Level 2: SUBSTANTIVE
Is it real implementation, not a stub?
- Check for TODO/panic/NotImplemented/placeholder/lorem
- Verify function has real logic (>5 lines, calls dependencies)
- Check components render real content
Level 3: WIRED
Is it connected to the system?
- Routes registered in router
- Services injected via constructor
- Components imported and rendered
- Migrations in sequence
Level 4: DATA-FLOW
Does real data flow through?
- Handler reads from request (json.Decode, chi.URLParam)
- Service calls repo methods
- Repo executes real SQL (INSERT, SELECT, not hardcoded)
- Frontend calls real API (requestJSON, useQuery — not mock)
Output Format
## Goal Verification Report
### Overall: PASS / NEEDS-ATTENTION / NEEDS-REMEDIATION
### Results
| Goal | EXISTS | SUBSTANTIVE | WIRED | DATA-FLOW |
|------|--------|-------------|-------|-----------|
| goal 1 | ✅ | ✅ | ✅ | ✅ |
| goal 2 | ✅ | ✅ | ✅ | ⚠️ |
### Issues
1. [goal] [level] — description + evidence
### Verdict
- PASS — all goals pass all 4 levels
- NEEDS-ATTENTION — some goals ≤3 levels; list the exact in-place fixes
- NEEDS-REMEDIATION — any goal fails EXISTS or SUBSTANTIVE; re-plan with reasons
IMPORTANT: Actually read files and run grep. Don't assume — verify.
