verify

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=promote
• live_reviewers, live_payloads, live_verdict for --gate=live
• audit_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:

1. Return to the implementer with a fix directive summarizing landed findings. Verdict so far is BLOCKED.
2. Implementer fixes the code and commits. The fix commit SHA goes in the "Fixes & re-review" subsection alongside the landed finding.
3. Implementer re-invokes /verify with the same --payload, --strategy, and --gate.
4. /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.
5. Append the re-review result to the "Fixes & re-review" subsection: re-reviewer name, re-review verdict (SURVIVED / WEAKENED / LANDED).
6. 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.