Code Forge — Verify

⚡ Execution Entry Point (READ THIS FIRST)

When this skill is loaded, you MUST immediately begin executing the Workflow below — do not wait, do not summarize, do not ask "what should I do now". Skills are operational manuals, not reference documents. Read the first executable step, perform it, then the next, etc., until the workflow completes or you reach an AskUserQuestion checkpoint.

If the harness shows you Successfully loaded skill · N tools allowed, that message means the SKILL.md content was injected into your context — it does NOT mean the skill has run. Skills do not "run" autonomously; you run them by executing the Detailed Steps below.

If you find yourself about to say "the skill didn't produce output", "skill 仍未输出", "falling back to manual verification", "回退到手动 verify", or anything similar, STOP. You have misunderstood how skills work. Go directly to the first executable step and start.

The first user-visible action of this skill should be either (a) the output of the first step, or (b) an AskUserQuestion if the first step needs disambiguation. Never an apology, never a fallback, never silence.

---

Evidence-based completion verification. Run before claiming any work is done.

When to Use

• About to say "tests pass", "build succeeds", "bug is fixed", or "feature is complete"
• Before committing, creating a PR, or marking a task as done
• After any code change that should be verified
• When reviewing sub-agent output before trusting it

Note: code-forge:impl runs verification automatically. This skill is for general use.

Iron Law

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.

No exceptions. Not "it should work." Not "I just ran it." Not "the agent said it passed."

The Gate

Every completion claim must pass through this gate — because false claims waste reviewer time and erode trust in automated workflows. A single unverified "tests pass" can mask a regression that reaches production.

IDENTIFY → RUN → READ → VERIFY → CLAIM

1. IDENTIFY the verification command (test, build, lint, type-check)
2. RUN the command fresh (not from memory, not from a previous run)
3. READ the complete output (not skimmed, not truncated)
4. VERIFY the output matches the claim (zero failures, exit code 0)
5. ONLY THEN make the claim

Example:

• Before: "I fixed the off-by-one error, tests should pass now."
• Run: npm test → Output: 42 passed, 0 failed
• After: "Off-by-one fix verified — 42 tests pass (0 failures, exit 0)."

Forbidden Words

These words in a completion claim are red flags — they mean you haven't verified:

• "should work" / "should pass"
• "probably" / "likely"
• "seems to" / "appears to"
• "I believe" / "I think"
• "based on the changes"
• "it worked before"

Replace with evidence: "All 34 tests pass (output: 34 passed, 0 failed, exit code 0)."

If no automated verification exists, state that explicitly: "No automated test covers this — manual verification required: [steps]." This is honest, not hedging.

Verification Patterns

Tests

Run command → See "X passed, 0 failed" → Claim "all tests pass"

NOT: "Tests should pass now" or "I fixed the issue so tests will pass."

Regression Test

Write test → Run (PASS) → Revert fix → Run (MUST FAIL) → Restore fix → Run (PASS)

The revert-and-fail step proves the test actually catches the bug.

Build

Run build → See exit code 0, no errors → Claim "build passes"

Requirements Checklist

For each requirement:
  [ ] Identified verification method
  [ ] Ran verification
  [ ] Evidence recorded

NOT: "Tests pass, so the feature is complete."

Sub-Agent Output

Agent claims success → Check VCS diff → Run tests yourself → Verify changes

NEVER trust agent reports without independent verification.

Common Mistakes

• Trusting memory of a previous test run instead of running fresh
• Reading only the last line of output, missing errors above
• Claiming "build passes" after only running tests (or vice versa)
• Verifying one aspect but claiming completeness for all aspects
• Skipping verification "just this once" because it's a small change