Menü
Use when you need to verify work is complete before making completion claims
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | arc-verifying |
| description | Use when you need to verify work is complete before making completion claims |
Claiming work is complete without verification is dishonesty, not efficiency.
arc-verifying owns producing fresh evidence for completion claims. It does not own authoring spec artifacts (that is arc-refining) and it does not own reconciling spec/code drift after implementation (that is the optional, separate, future arc-syncing-spec workflow — never folded into the SessionStart bootstrap or the arc-using router). Spec/code drift checks may quote verification evidence as input, but verification itself is not a spec-sync skill.
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the verification command in THIS message, you cannot claim it passes.
BEFORE claiming any status or expressing satisfaction:
Skip any step = lying, not verifying
| Claim | Requires | NOT Sufficient |
|---|---|---|
| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
| Build succeeds | Build command: exit 0 | Linter passing |
| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
| Agent completed | VCS diff shows changes | Agent reports "success" |
| Requirements met | Line-by-line checklist | Tests passing |
If claiming a bug is fixed, require a true regression check:
1. Run failing test (RED)
2. Apply fix
3. Run test again (GREEN)
Skipping RED means you don't know the test proves anything.
If claiming requirements are met:
Core principle: Cannot verify ≠ skip verification. Must inform user and choose alternative.
digraph cannot_verify {
"Cannot run verification?" [shape=diamond];
"Inform user immediately" [shape=box];
"User chooses" [shape=diamond];
"Fix the blocker" [shape=box];
"Add debug output" [shape=box];
"User reports result" [shape=box];
"Cannot run verification?" -> "Inform user immediately" [label="yes"];
"Inform user immediately" -> "User chooses";
"User chooses" -> "Fix the blocker" [label="fix env"];
"User chooses" -> "Add debug output" [label="manual test"];
"Add debug output" -> "User reports result";
}
| Situation | Action |
|---|---|
| Build fails | Fix build first, then verify |
| Cannot run Simulator/Emulator | Ask user: fix blocker OR add debug print |
| Requires manual UI testing | Describe expected behavior, ask user to verify |
| Excuse | Reality |
|---|---|
| "Should work now" | Assumption ≠ verification |
| "I changed it, should be fine" | Changed ≠ verified |
| "Continue for now, verify later" | Cannot verify = stop here |
| Excuse | Reality |
|---|---|
| "Should work now" | RUN the verification |
| "I'm confident" | Confidence ≠ evidence |
| "Just this once" | No exceptions |
| "Agent said success" | Verify independently |
| "Partial check is enough" | Partial proves nothing |
| "Too simple to verify" | Complexity irrelevant |
| "I already ran it earlier" | Run it again, now |
| "The logs look fine" | Logs ≠ verification |
Tests:
✅ [Run test command] [See: 34/34 pass] "All tests pass"
❌ "Should pass now" / "Looks correct"
Build:
✅ [Run build] [See: exit 0] "Build passes"
❌ "Linter passed" (linter doesn't check compilation)
Agent delegation:
✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
❌ Trust agent report
Requirements:
✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
❌ "Tests pass, phase complete"
Discoverable from: arc-using when a task is approaching a completion claim and verification guidance would help.
Also embedded in:
.arcforge-epic) — verify tests before offering merge optionsInvoke this skill explicitly before finishing. Embedded verification in other skills is an additional layer, not a replacement.
Use when running autonomous unattended loops — cross-session execution of DAG tasks without human intervention
Use when converting design documents to structured specs, when spec quality is below threshold, or when requirements need formal acceptance criteria
Use when maintaining ArcForge itself by creating, editing, or verifying ArcForge skills before deployment
Use when optional learning is enabled and observations should become reviewable candidates, inactive drafts, and explicitly activated artifacts.
Use when user asks about behavioral patterns, requests instinct status, or wants to confirm/contradict a detected pattern
Use when executing task lists where each task requires isolated execution