First verify "whether what is being done is what the user truly wants", then verify "whether the scheme and code are correct". It is not considered successful if both models agree on the same wrong contract.

• Users explicitly require two models to collaborate, cross-validate or "revise until ACK": fully use this Skill.
• Complex solutions, cross-module development, migration, security, major refactoring, pre-release acceptance: proactively use this Skill.
• Low-risk, well-defined, easily rollback small fixes: completed by a single model by default; do not add four rounds of model calls for formality unless the user specifies.

• Automatically identifying the primary and selecting the other CLI;
• Unified handoff, schema and commands, preventing each project from reinventing prompts;
• Intent/Plan stopping wrong requirements or schemes early;
• Plan continuing from Intent, revision rounds continuing from Implementation, only cold-starting when anchoring is needed;
• Structured fail-closed, avoiding repeated manual judgment on half-finished outputs;
• Using state files to automatically determine the next gate, reducing manual session tracking and missed reviews.

max

• The user's original words and subsequent corrections, placed in the

  <raw_user_request>

  tag, must be quoted verbatim, not just the primary's summary.
• Expected business results, observable behaviors, out-of-scope items.
• Current facts and evidence paths; distinguish between facts, inferences, and assumptions.
• Project agreements, related code/documents, dirty worktree and permission boundaries.
• Deliverables of the current phase: scheme, diff, test results, migration drills or screenshots.
• Unverified content and questions that need peer challenge.

AGENTS.md

CLAUDE.md

• If the user explicitly requires Claude and Codex to collaborate this time, it is considered permission to call both ends within the scope of the current task, but tokens, cookies, credentials and irrelevant personal data must still be excluded.
• If triggered proactively by the primary, when discovering restrictions on external models, single suppliers, confidentiality or data residency requirements, must first ask the user; do not call the peer without authorization.
• Keep the handoff as "the minimum dataset sufficient for complete review", prioritize controlled paths, do not copy irrelevant repository content.

--cwd

--add-dir /absolute/read-only/evidence-directory

Read/Grep/Glob

BLOCKED

--add-dir

BLOCKED

<raw_user_request>...</raw_user_request>
<artifact_manifest>...</artifact_manifest>
<validation_evidence>...</validation_evidence>
<known_gaps>...</known_gaps>

• User's original words;
• Acceptable product results;
• Key deliverable paths;
• Diff and validation evidence in the implementation phase;
• Known limitations and unfinished items.

1. What does the user truly want, rather than what is literally requested?
2. Which product assumptions are unvalidated?
3. Will current boundaries cause "technically correct, but business invalid"?
4. Which acceptance must use real data or user-visible behaviors?

python3 <skill-dir>/scripts/invoke_peer.py \
  --peer auto --phase intent --cwd <project-root> \
  --task-id <stable-project-task-id> \
  --prompt-file <intent-handoff.md>

NOT_ACK

Read/Grep/Glob

sandbox_mode=read-only + approval_policy=never

git diff

• Original requirements and accepted contract;
• Plan and change files;
• Readable path to complete

  git diff

  ;
• Test commands, pass count and failure output;
• Real data/visual/migration evidence;
• What was not done and why.

python3 <skill-dir>/scripts/invoke_peer.py \
  --peer auto --phase implementation --cwd <project-root> \
  --task-id <stable-project-task-id> \
  --add-dir <diff-or-evidence-dir> \
  --prompt-file <implementation-handoff.md>

• Intent and Plan have been ACKed;
• Implementation has no unclosed P0/P1;
• The primary has completed necessary self-verification;
• User-visible results and real data have been verified;
• Out-of-scope items are not treated as "not needed by user";
• Unfinished items are clearly stated, no pretence of completion.

--task-id

--state-file

• intent

  creates the workflow.

• plan

  only accepts ACKed intent, and must continue from the intent session.
• The first round of

  implementation

  must be a new cold review session; revision rounds must continue from this implementation session.

• final

  only accepts that intent / plan / implementation are all ACKed.
• Once a gate is ACKed, it cannot be overwritten; when the user corrects requirements, use a new state file and restart from intent.

• ACK

  : Contract and current phase evidence are sufficient, no blocking findings.

• NOT_ACK

  : There are issues that need repair or redefinition of requirements.

• BLOCKED

  : Lack of evidence, permissions, CLI or user decision, unable to make honest judgment.

peer finding
  → primary reviews with evidence
  → accepts and fixes, or rejects with evidence
  → primary self-tests
  → resumes the same review session to close items one by one
  → requests fresh scan
  → ACK / NOT_ACK / BLOCKED

• The peer is not a voter; conclusions must be accompanied by files, behaviors or evidence.
• The primary cannot outsource testing responsibilities to the peer.
• Do not modify the same worktree in parallel. If peer coding is needed, an independent worktree must be used, and reviewed by the primary before merging; this is not the default.
• Do not write unfinished work as ACK due to token, time or CLI stuck issues.
• If the peer ends with tool request, plan or no verdict, it is considered unfinished; do not manually rewrite natural language fragments into ACK, repair the call or continue review to obtain a structured report again.
• When requirements are overturned by user acceptance, return to Gate A, old ACK automatically becomes invalid.

--peer auto|claude|codex
--phase intent|plan|implementation|final
--cwd PROJECT_ROOT
--add-dir DIR           # Repeatable; mandatory when Claude reads evidence outside cwd
--task-id ID            # Recommended; automatically isolate persistent state by project and task
--state-file PATH       # Advanced usage; choose one with --task-id
--prompt-file PATH      # Choose one with --prompt / stdin
--prompt TEXT
--session-id ID         # Continue review
--timeout-seconds 1800
--save-raw DIR          # Only use when complete CLI events need to be saved
--dry-run

{
  "peer": "claude",
  "phase": "implementation",
  "sessionId": "...",
  "verdict": "NOT_ACK",
  "report": {
    "summary": "...",
    "findings": []
  }
}

--save-raw

• Claude uses

  opus

  alias +

  max

  effort by default, enables safe mode, disables custom MCP, restricts to Read/Grep/Glob; on macOS, use

  sandbox-exec

  to prohibit writing to cwd/evidence directories. Override with

  DUAL_AGENT_CLAUDE_MODEL

  ,

  DUAL_AGENT_CLAUDE_EFFORT

  .
• Codex uses the native configured model by default, and enforces

  max

  reasoning; override with

  DUAL_AGENT_CODEX_MODEL

  ,

  DUAL_AGENT_CODEX_REASONING

  .
• Do not hardcode full model version numbers that will expire. Report the actual model returned by the CLI or the requested model upon delivery.

• Who is the primary and who is the peer.
• Which gates were passed, and the final verdict of each gate.
• What the peer found, and how the primary handled it.
• What verification the primary ran on its own.
• Unfinished content or items requiring user acceptance.

• Codex primary → Claude peer completes real fresh and resume, and obtains structured verdict and state changes.
• Claude primary → Codex peer completes real fresh and resume, and obtains structured verdict and state changes.
• The contents of the central repository, Codex, and Claude Code directories are consistent.
• New CLI sessions of Codex and Claude Code can discover and trigger this Skill.

<artifact_manifest>

--add-dir

BLOCKED

__pycache__/

*.pyc

*.pyo

.DS_Store

1. Copy to a unique staging directory in the same parent directory of each target directory, and perform content comparison first.
2. If the old version exists, atomically rename it to a unique backup; then atomically rename the staging to the official directory.
3. Delete the backup only after both targets are verified consistent.
4. If any target fails, restore the backup of all replaced targets, clean up staging, and re-perform three-party consistency check.

python3 <skill-dir>/scripts/install_skill.py \
  --source <central-skill-dir> \
  --target <codex-skill-dir> \
  --target <claude-skill-dir> \
  --dry-run

--dry-run

uv run --with pyyaml \
  <skill-creator-dir>/scripts/quick_validate.py \
  <dual-agent-collaboration-dir>

Skill is valid!