القائمة
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 المهني
| 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.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.