メニュー
WHEN: About to claim implementation is complete or working. HARD-GATE: Run verification, see output, THEN claim success. Never "should pass", "confident", "should work".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
WHEN: You need to detect performance regressions before merge — TTFB, response time, bundle size. Run as part of forge-eval-gate or standalone before raising a PR.
WHEN: A decision is being superseded, deprecated, or has aged out. Archive it without deletion — marks as warm→cold→archived with full audit trail.
WHEN: You are writing a new decision, superseding an old one, or querying relationships across decisions. Create semantic edges between decisions and link concepts across products/projects/time.
WHEN: You are about to make a decision and need to check if prior art or past learnings exist. Recall decisions, patterns, and gotchas from the brain before proceeding.
WHEN: You need to trace the full provenance of a specific decision — who made it, when, why, and what alternatives were considered. Shows why, when, by whom, evidence, alternatives, outcome.
WHEN: You need to record a decision, lock a spec, log an eval run, or document learnings in the brain.
| name | forge-verification |
| description | WHEN: About to claim implementation is complete or working. HARD-GATE: Run verification, see output, THEN claim success. Never "should pass", "confident", "should work". |
| type | rigid |
| version | 1.0.1 |
| preamble-tier | 3 |
| triggers | ["run verification","verify implementation","check implementation is complete"] |
| allowed-tools | ["Bash","Read"] |
Iron Law: Evidence before assertions. Always.
| Rationalization | The Truth |
|---|---|
| "I'm confident the code works, the logic is sound" | Confidence is not evidence. Production requires proof from actual test runs. |
| "The previous test run passed, this shouldn't have changed" | Previous runs prove nothing about current state. Dependencies, cache, timing all matter. |
| "The changes are small, I should verify manually" | Manual spot-checks miss edge cases. Automated verification is the only complete record. |
| "Unit tests pass, that's sufficient proof" | Unit tests verify components in isolation. Full verification tests integration, real conditions, end-to-end flows. |
| "It should work based on my understanding of the code" | Understanding is subjective. Output is objective. Never substitute belief for evidence. |
| "Verification takes too long, I'll assume it passes" | The time cost of verification is negligible vs. the cost of undetected failures in production. |
| "The code review looked good, that's verification enough" | Code review is about correctness; verification is about observable behavior. They are orthogonal. |
| "I tested locally, it works there" | Local testing != production verification. Environment differences, ordering, concurrency, state matter. |
| "These are boring infrastructure tests, probably fine" | Boring tests catch boring bugs that break production in boring ways. Skip none. |
| "I can just describe what passed instead of showing logs" | Logs are the only source of truth. Descriptions are filtered through human interpretation. |
| "Running verification a second time would just duplicate effort" | Running verification confirms repeatability. Flaky tests need investigation. Do not skip. |
RUN THE VERIFICATION COMMAND AND OBSERVE THE OUTPUT BEFORE CLAIMING SUCCESS. CONFIDENCE IS NOT EVIDENCE — OBSERVED OUTPUT IS EVIDENCE.
When work depends on ~/forge/brain/products/<slug>/codebase/ (council, tech plans, eval paths): if SCAN.json exists, run python3 tools/verify_scan_outputs.py <codebase-dir> and require exit 0 (retry up to 3× with 1s delay before claiming the scan is load-bearing). The forge_scan.py CLI already verifies after each run unless FORGE_SCAN_SKIP_VERIFY=1. Treat verify failure like missing tests — no success claims until the brain tree is whole or the gap is explicitly waived in writing.
When a task-id has ~/forge/brain/prds/<task-id>/tech-plans/*.md and you are about to claim plans are merge-ready or REVIEW_PASS: run python3 tools/verify_forge_task.py --task-id <id> --brain ~/forge/brain --strict-tech-plans (or python3 tools/verify_tech_plans.py alone) and require exit 0 — see docs/forge-task-verification.md. Teams that hit structural PASS / semantic thin slips should add --strict-0c-inventory in CI (inventory GAP rows + required citations when Confluence mirror, touchpoints/, or QA CSV exist). This catches missing Section 0c anchors and misplaced ### 1b.2a; it does not replace reading prd-locked.md end-to-end, but it blocks the common “chat-only self-review” slip.
If you notice any of these, STOP and do not proceed:
Phase Authority Check (before running any verification command):
Read ~/forge/brain/prds/<task-id>/conductor.log tail to confirm the current phase:
[P4.0-TDD-RED] logged for the repo (tests written and confirmed failing — no production feature code yet)[P4.1-DISPATCH] for the relevant repo (implementation started, not yet eval)[P4.0-SEMANTIC-EVAL] or [P4.1-DISPATCH] complete[P4.4-EVAL-PASS] before forge-verification is used as final gateDo not claim verification results as eval evidence if conductor.log shows the task is still in a TDD phase ([P4.0-TDD-RED] present, [P4.1-DISPATCH] absent).
Before beginning a new verification run, check whether a PASS verdict already exists for the current commit and is less than 7 days old. If so, you may skip re-running and cite the existing evidence — but only if no code has changed since that commit.
TASK_ID="${FORGE_TASK_ID:-unknown}"
BRAIN="${FORGE_BRAIN:-${FORGE_BRAIN_PATH:-$HOME/forge/brain}}"
VERDICT_FILE="$BRAIN/prds/$TASK_ID/review-verdicts.jsonl"
CURRENT_COMMIT=$(git rev-parse HEAD 2>/dev/null || echo "")
NOW_EPOCH=$(date -u +%s)
SEVEN_DAYS=$((7 * 24 * 3600))
if [ -f "$VERDICT_FILE" ] && [ -n "$CURRENT_COMMIT" ]; then
MATCH=$(grep "\"$CURRENT_COMMIT\"" "$VERDICT_FILE" | grep "\"PASS\"" | tail -1)
if [ -n "$MATCH" ]; then
TS=$(echo "$MATCH" | sed 's/.*"timestamp":"\([^"]*\)".*/\1/')
ENTRY_EPOCH=$(date -u -d "$TS" +%s 2>/dev/null || date -u -j -f "%Y-%m-%dT%H:%M:%SZ" "$TS" +%s 2>/dev/null || echo 0)
AGE=$(( NOW_EPOCH - ENTRY_EPOCH ))
if [ "$AGE" -lt "$SEVEN_DAYS" ]; then
echo "VERIFICATION PASS (cached — verified $(( AGE / 3600 ))h ago for commit $CURRENT_COMMIT)"
echo "Stop here. Re-run /forge-verification explicitly to force a fresh check."
else
echo "WARNING: Last PASS for this commit is $(( AGE / 86400 )) days old — re-verification required."
fi
fi
fi
If the output prints "VERIFICATION PASS (cached…)" — stop. If it prints nothing or the warning — proceed with the full workflow below.
For each verification target:
Run the command exactly as written (no shortcuts, no assumptions)
# Example: full test suite
npm test -- --coverage --verbose
# Example: integration suite
cargo test --release -- --test-threads=1
# Example: e2e eval
/invoke forge-eval-gate
Observe and capture output
Do NOT interpret — just record facts:
Run the command appropriate for the surface being verified. Capture full output — do not paraphrase.
API / Backend (HTTP):
# Health check
curl -f -s -o /dev/null -w "%{http_code}" http://localhost:<PORT>/health
# Endpoint smoke test
curl -X POST http://localhost:<PORT>/api/<endpoint> \
-H "Content-Type: application/json" \
-d '{"key": "value"}' | jq .
Web Frontend:
# Check dev server is running
curl -f http://localhost:<PORT>/ | grep -o '<title>[^<]*</title>'
# Screenshot via CDP (if eval driver available)
node -e "const CDP=require('chrome-remote-interface'); CDP(async c=>{ await c.Page.navigate({url:'http://localhost:<PORT>'}); const s=await c.Page.captureScreenshot(); require('fs').writeFileSync('verify-screenshot.png', Buffer.from(s.data,'base64')); process.exit(0); })"
Android:
# Verify app is running on device/emulator
adb shell dumpsys activity activities | grep -i "<package>"
# Check logs for errors
adb logcat -d -s "<TAG>" | tail -50
# Assert no crash
adb shell am start -n "<package>/<activity>" && echo "Launch OK"
iOS:
# Verify simulator is booted
xcrun simctl list devices | grep "Booted"
# Launch and verify app
xcrun simctl launch booted <bundle-id> && echo "Launch OK"
Database:
# Check schema matches expected
psql $DATABASE_URL -c "\dt" | grep "<expected_table>"
# Verify migration ran
psql $DATABASE_URL -c "SELECT version FROM schema_migrations ORDER BY version DESC LIMIT 1;"
Cache (Redis):
redis-cli -h localhost -p 6379 PING # expect PONG
redis-cli -h localhost -p 6379 INFO server | grep redis_version
HARD-GATE: Paste the actual command output in your verification report. "It works" without output is not verification.
Input: Verification output + acceptance criteria
Check each criterion:
If gap found:
Output statement format:
VERIFICATION PASS
- Test suite: 47/47 passed, 0 skipped
- Coverage: 92% lines, 88% branches
- E2E eval: all 8 scenarios green
- Performance: p95 latency 145ms (SLA: 200ms)
Evidence: [link to full test output log]
Persist the verdict to the review dashboard (REQUIRED on every PASS):
TASK_ID="${FORGE_TASK_ID:-unknown}"
BRAIN="${FORGE_BRAIN:-${FORGE_BRAIN_PATH:-$HOME/forge/brain}}"
VERDICT_FILE="$BRAIN/prds/$TASK_ID/review-verdicts.jsonl"
mkdir -p "$(dirname "$VERDICT_FILE")"
COMMIT=$(git rev-parse HEAD 2>/dev/null || echo "unknown")
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
echo "{\"commit\":\"$COMMIT\",\"timestamp\":\"$TIMESTAMP\",\"verdict\":\"PASS\",\"task_id\":\"$TASK_ID\"}" >> "$VERDICT_FILE"
Before claiming success, complete all items:
Situation: Verification tool itself is buggy or invalid. It crashes, produces nonsensical output, or has false positives.
Example: Test framework hangs on invalid assertion syntax. Verification script crashes mid-test. Coverage report shows 200% coverage (mathematically impossible).
Do NOT: Trust output from broken tools or claim verification passed based on suspect output.
Action:
Situation: Verification runs, produces output, but output is hard to parse or understand.
Example: Test output is 50MB log with no summary. Test names are cryptic (test_0001, test_0002). Output format differs from expected (JSON instead of TAP, etc.).
Do NOT: Summarize output in words ("looks like it passed"). Output must be human-readable.
Action:
Situation: Verification suite passes all tests, but human testing or production finds bugs. Tool missed real issues.
Example: All unit tests pass. Integration tests pass. Manual testing discovers "user can't export data" feature doesn't work.
Do NOT: Ignore human findings. Verification tools are not infallible.
Action:
Output: PASS (with evidence from working tools) or BLOCKED (verification tool broken, output unreadable, infrastructure down, unresolvable flakiness)
Symptom: Verification passes on run N (47 tests, all pass). On run N+1 after a code change, 44 tests pass — but the implementer claims "nothing was deleted." The 3 missing tests were silently removed.
Do NOT: Accept a passing run if the test count has decreased without a documented reason.
Action:
Symptom: Local npm test shows 47/47 passing. CI pipeline shows 41/47 with 6 failures. The implementer argues "it works on my machine."
Do NOT: Accept local verification as evidence when CI contradicts it.
Action:
CI=true npm test or use the same env vars as CI.env entries, implicit dependency on global tools not in CIBefore claiming a task complete:
verify_forge_task.py was run and its output included, not assumed.