| description | Gate-level cross-model verification. Picks a reviewer from a different model family than the implementing agent, hands it an in-repo skill as its checklist, records findings in the strategy's prosecution doc, and closes the fix-and-re-review loop before returning a verdict. |
| metadata | {"github-path":"skills/verify","github-ref":"refs/tags/v1.1.0","github-repo":"https://github.com/recallnet/recall-skills","github-tree-sha":"266ce6c2c50dcdb0ac8124c4fb7084b6d8af9ff2"} |
| name | verify |
/verify — Cross-Model Gate Verification
Purpose
Run a cross-model verification pass against a specific in-repo checklist (the "payload"). Write findings to the strategy's prosecution doc. If the reviewer lands any finding, loop on fix-and-re-review until nothing remains landed. Return a verdict.
This is the single entry point for gate-level cross-model review. Callers (build-executor, /trade-path-audit, any custom gate flow) invoke /verify with a payload — they do not invoke oracle skills directly.
When to use this vs. /adversarial-verifier
| Skill | Question it answers | Cross-model? | Writes prosecution doc? | When to use |
|---|
/verify | "I'm at a gate. I need a cross-family stamp in the prosecution doc before I can progress." | Always | Always | Called from gate flows, or whenever gate-level cross-model verification is required |
/adversarial-verifier | "I want to pressure-test a specific claim in my own session, right now, without launching another model." | No (same-session) | No | Ad hoc same-session deep-dive. Also used as a --payload for /verify (the oracle runs its methodology). |
/adversarial-verifier is methodology. /verify is orchestration that applies that (or another) methodology via a cross-family reviewer and closes the loop on findings.
Core rule: different families only
Same-family review shares pretraining blind spots and does not satisfy this skill. /verify refuses to run if the only available reviewer is in the same family as the implementing agent.
Pairing table
This is the single authoritative copy. Other docs link here; they do not duplicate it.
| Implementing agent's family | Cross-model reviewer options (different families) |
|---|
| Anthropic (Claude) | /codex-oracle, /gemini-oracle |
| OpenAI (Codex / GPT) | /claude-oracle, /gemini-oracle |
| Google (Gemini) | /claude-oracle, /codex-oracle |
| Other / local | Any oracle from a provider different from yours |
For --reviewers=2: the two reviewers must also be in different families from each other.
Inputs
| Argument | Required | Values |
|---|
--payload=<slug> | Yes | strategy-verification, trade-path-audit, adversarial-verifier, trading-attacks, live-mode-checks, or a free-text focus string |
--reviewers=1|2 | No (default 1) | Number of cross-family reviewers to invoke. Use 2 at LIVE gate. |
--strategy=<slug> | No (defaults to current experiment slug) | Which prosecution doc to write/update. Looked up at research/evidence/prosecution-<slug>.md. |
--gate=promote|live|audit | Yes | Which section of the prosecution doc to populate. |
Payload meanings
strategy-verification — oracle runs .agents/skills/strategy-verification/SKILL.md's protocol against the scoring output + scorer source + replay engine. Catches replay leaks, empty-book fills, capital accounting bugs, determinism violations.trade-path-audit — oracle runs .agents/skills/trade-path-audit/SKILL.md's protocol. For retrofits and externally-built executors. Comprehensive (inventory, gate-check, parity-audit, 21 error classes).adversarial-verifier — oracle runs .agents/skills/adversarial-verifier/SKILL.md's Chain-of-Verification protocol with Saboteur / New Hire / Security Auditor personas. Use at LIVE for generic deep-verification methodology (parity bugs, credentials, reconciliation, architecture).trading-attacks — oracle runs .agents/skills/build-executor/references/adversarial-trading.md's Backtester + Live Operator + Data Skeptic checklists.live-mode-checks — oracle focuses on parity bugs (live-only branches that aren't venue plumbing / unknown-order / budget gate), credential handling, timeout & reconciliation, secrets in logs.- Free-text focus — anything not covered above; the string is passed directly to the oracle. Use sparingly; the named payloads exist so review methodology stays reproducible.
Protocol
1. Detect or confirm implementing agent's family
Check the strategy's prosecution doc frontmatter for implementing_family. If absent, prompt the implementer:
What model family is the implementing agent? (anthropic | openai | google | other)
Cache the answer in frontmatter. Do not re-prompt on subsequent /verify runs for the same strategy.
2. Pick reviewers
Using the pairing table, pick N reviewers from families different from the implementing agent's family. For N=2, the two reviewers must also be in families different from each other.
If the pairing table produces fewer candidates than --reviewers, stop and report. Do not run with an invalid configuration.
3. Compose the oracle prompt
Read the full text of the payload skill's SKILL.md (or, for free-text, use the string directly).
Compose the prompt handed to the oracle:
Read the protocol defined in `.agents/skills/<payload>/SKILL.md` of the current repo. Follow that protocol on the diff between <base-ref> and <head-ref>. Produce the report format that skill specifies. Do not invent your own checklist — use the skill's.
Focus on findings that materially affect the trading edge, correctness, or live safety. Grade each finding: SURVIVED (attack fired but the code held), WEAKENED (attack partially landed — quantify how much of the claimed edge survives), or LANDED (attack fully landed — this blocks the gate).
Produce your findings as a markdown table matching the "Attacks" section of `executors/execution-template/research/evidence/TEMPLATE-prosecution.md`.
For --reviewers=2 at LIVE, vary the payload per reviewer per the caller's instructions (typically: reviewer 1 runs trading-attacks + strategy-verification; reviewer 2 runs adversarial-verifier focused on live-mode threats).
4. Invoke the oracle
Invoke the selected oracle skill with the composed prompt. Capture the full report.
5. Write or append to the prosecution doc
Target file: research/evidence/prosecution-<strategy-slug>.md. If it doesn't exist, copy from executors/execution-template/research/evidence/TEMPLATE-prosecution.md first.
Update the frontmatter for the current gate:
promote_reviewer, promote_payload, promote_verdict for --gate=promotelive_reviewers, live_payloads, live_verdict for --gate=liveaudit_reviewers, audit_payloads, audit_verdict for --gate=audit
Append the reviewer's findings to the corresponding ## <GATE> gate section's Attacks table. Include the reviewer name, payload name, date, and full finding-by-finding breakdown.
6. Fix-and-re-review loop
If any attack in the reviewer's output is verdict LANDED:
- Return to the implementer with a fix directive summarizing landed findings. Verdict so far is
BLOCKED.
- Implementer fixes the code and commits. The fix commit SHA goes in the "Fixes & re-review" subsection alongside the landed finding.
- Implementer re-invokes
/verify with the same --payload, --strategy, and --gate.
/verify detects existing LANDED entries in the prosecution doc. It re-invokes the same reviewer with the same payload against the new diff, focused specifically on the previously-landed findings.- Append the re-review result to the "Fixes & re-review" subsection: re-reviewer name, re-review verdict (SURVIVED / WEAKENED / LANDED).
- Loop until no
LANDED entries remain.
7. Return final verdict
Verdict is the composite across attacks:
- SURVIVED — no LANDED findings; all attacks survived.
- WEAKENED (acceptable, with rationale) — attacks partially landed but the implementer has documented why the remaining edge is still worth shipping. Requires explicit rationale in the gate's verdict section.
- BLOCKED — at least one LANDED finding remains unresolved.
Update the gate's *_verdict frontmatter field accordingly. Commit the prosecution doc.
Retrofit / audit caveat
For the /trade-path-audit flow, the gate is audit, --reviewers=2, and the prosecution doc gets an ## AUDIT section instead of (or in addition to) ## PROMOTE / ## LIVE. Audit verdict flows through the same fix-and-re-review loop. See /trade-path-audit for the full retrofit protocol.
What this skill does NOT do
- Same-session deep-dives — use
/adversarial-verifier directly.
- Same-session trading attacks — apply the personas from
adversarial-trading.md inline while building. That's a building practice, not a verification step.
- Content judgment —
/verify enforces the protocol (cross-family reviewer, prosecution doc, fix loop). The reviewer owns the judgment. Don't second-guess the reviewer's verdict in /verify; challenge it via a second /verify with a different reviewer if needed.
QA enforcement
pnpm qa (via scripts/qa/check-experiment-docs.ts) enforces that experiments at shadow / live / active-edge status have a prosecution doc whose promote_verdict is not pending, landed, or blocked. For live / active-edge: two live_reviewers required and live_verdict not pending/landed/blocked. This catches the most consequential lie: agent skipped cross-model verification.
Attack-table content is reviewer judgment — not enforced.
References
- Pairing table rationale and model-family definitions: this file (authoritative).
- Prosecution doc template:
executors/execution-template/research/evidence/TEMPLATE-prosecution.md.
- Building-time adversarial checklists:
.agents/skills/build-executor/references/adversarial-trading.md.
- Deep-verification methodology:
/adversarial-verifier.
- Strategy verification methodology:
/strategy-verification.
- Retrofit audit flow:
/trade-path-audit.
