oz-verify-claim

Independently re-runs tests and checks receipts to verify claims with PASS, FAIL, or UNPROVEN verdicts.

1|3|Updated Mar 9, 2026
One-click install
npx skills add https://github.com/AIKAGRYA/dharma_swarm --skill oz-verify-claim-aikagrya
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: oz-verify-claim
Source: https://github.com/AIKAGRYA/dharma_swarm/tree/main/.warp/skills/oz-verify-claim
Command: npx skills add https://github.com/AIKAGRYA/dharma_swarm --skill oz-verify-claim-aikagrya

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often accept "done" claims, PR descriptions, or completion assertions at face value, letting phantom artifacts and untested code slip through. This Skill provides a decorrelated, separate-harness verifier that re-runs the actual commands behind any claim and confirms cited artifacts and receipts truly exist before a verdict is trusted. ## Core Features & Use Cases - Falsifiable Claim Decomposition: Breaks a PR, commit, or "done" assertion into an explicit checklist of runnable commands and files that must exist. - Phantom Detection: Confirms every cited artifact and Runtime Truth Spine receipt exists on disk, flagging narrated-as-done work with missing evidence. - Structured Verdicts: Posts a PASS, FAIL, UNPROVEN, or BLOCKED verdict comment via gh pr comment and writes a JSON receipt under reports/loop_closure/oz_verify/. - Use Case: A teammate claims "Loop 5b closure shipped with receipt written." The verifier re-runs the closure command, finds the run green but the receipt file missing, and reports FAIL with the exact evidence row. ## Quick Start Ask the agent to independently verify a specific PR or done-claim by re-running its tests and confirming its cited artifacts and receipts exist.

Frequently Asked Questions about oz-verify-claim

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I independently verify a PR claim before merging?▼

Decompose the claim into runnable assertions, re-run each test or command yourself, and confirm every cited artifact exists on disk. The verifier posts a PASS, FAIL, or UNPROVEN verdict with a table of checks and exit codes as evidence.

What is a phantom artifact in code verification?▼

A phantom artifact is a file or receipt a claim references that does not actually exist on disk. The verifier checks each cited path directly, and any missing artifact turns the verdict into a FAIL regardless of passing tests.

Can the verifier approve or merge a pull request?▼

No. The verifier operates under a hard authority boundary: it may read code, run tests, and post verdict comments, but it must never merge, approve, push, edit source, or expose secrets. Steps requiring that authority are reported as BLOCKED.

When is a claim marked UNPROVEN instead of FAIL?▼

UNPROVEN applies only when a claim is genuinely unfalsifiable, meaning there is no runnable check and no artifact to confirm. If a check exists but is inconvenient, the verifier must run it rather than defaulting to UNPROVEN.

Why must verification run on a separate harness from the builder?▼

Running on a different session or clean checkout prevents the verifier from inheriting the builder's shell state or conversation context. This decorrelation ensures the verdict derives only from commands the verifier ran and files it confirmed itself.