[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FP07PS3M0KZ9WVRN4HERC":3,"skill-same:01M70FP07PS3M0KZ9WVRN4HERC":102},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":13,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M70FP07PS3M0KZ9WVRN4HERC","adversarial-implementation",null,"Adversarial implementation framework that turns a vetted plan into a precise `implementation.md` with exact code diffs, test specifications, and a plan-item coverage matrix. This Codex copy preserves the generalized multi-agent protocol from the authoritative Claude version while keeping Codex-specific discoverability and execution patterns. Use this skill after `adversarial-proposal` produces a `final-plan.md`, or whenever the user wants to \"create an implementation\", \"implement the plan\", \"write an implementation doc\", \"adversarial implementation\", or prove that every plan item maps to a specific code change and test before coding begins.","SirTheOracle\u002Fforge-toolkit","SirTheOracle","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F264051384?v=4","01M70FNRYMQR4XHVN77S3NJPAW","01M70FNRZAGW58XJ1CC6JRY1PA",0,"MIT","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-implementation\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"adversarial","implementation","adversarial implementation","execution","framework","coding","multi-agent","patterns","doc","matrix","write","change","plan","create","maps","code","discoverability","diffs","proposal","coverage","2026-11-10 10:12:30",false,"---\nname: adversarial-implementation\ndescription: >\n  Adversarial implementation framework that turns a vetted plan into a precise `implementation.md`\n  with exact code diffs, test specifications, and a plan-item coverage matrix. This Codex copy\n  preserves the generalized multi-agent protocol from the authoritative Claude version while keeping\n  Codex-specific discoverability and execution patterns. Use this skill after `adversarial-proposal`\n  produces a `final-plan.md`, or whenever the user wants to \"create an implementation\", \"implement\n  the plan\", \"write an implementation doc\", \"adversarial implementation\", or prove that every plan\n  item maps to a specific code change and test before coding begins.\n---\n\n# Adversarial Implementation Framework\n\n## Overview\n\nThis skill takes a `final-plan.md` (typically from the adversarial-proposal skill) and produces a complete, vetted `implementation.md` with exact code diffs, test specifications, and a coverage matrix that proves every plan item is addressed.\n\nThe same adversarial process that works for planning applies here: two agents independently produce implementation documents from the same plan, a synthesizer merges the best of both, the original agents critique the synthesis, and the synthesizer reconciles into a final implementation document.\n\nThe critical output is the **coverage matrix** — a table mapping every plan item to a specific code diff and a specific test. Zero gaps allowed.\n\nThe final document must be mechanically executable by `$forge-coder`, not merely understandable to a human reviewer. Parser-safe structure, unique `old_string` values, runnable commit-group tests, and exact new-file encoding are mandatory.\n\nThis Codex copy keeps the generalized Claude workflow but expects Codex-native delegation. When the upstream docs mention teammate APIs, translate them to Codex subagents or use the file-based fallback.\n\n## When to Use\n\n- After `adversarial-proposal` produces a `final-plan.md`\n- When you have any implementation plan and want vetted, exact diffs before coding\n- When previous implementations have missed items from the plan\n- When testing coverage is critical\n\n## Prerequisites\n\nThis skill follows the generalized multi-agent protocol from the authoritative Claude version.\n\n- In Codex, prefer native subagents to preserve isolation between A, B, and C.\n- When the upstream docs mention teammate APIs, map them to Codex delegation primitives such as `spawn_agent`, `send_input`, and `wait_agent`.\n- If persistent subagent messaging is not practical, use `references\u002Fsubagent-fallback.md`.\n\n## Architecture\n\n```\nINPUT: final-plan.md (from adversarial-proposal or any plan)\n─────────────────────────────────────────────────\n\nROUND 0: Setup\n─────────────────────────────────────────────────\n  Lead reads final-plan.md → extracts source files + plan items\n  Strategy pair: A=Surgical, B=Coverage\n\nROUND 1: Independent Implementation Planning (parallel)\n─────────────────────────────────────────────────\n  Agent A (Surgical)              Agent B (Coverage Guardian)\n  ┌──────────────────┐            ┌──────────────────┐\n  │ Own context       │            │ Own context       │\n  │                   │            │                   │\n  │ Sees ONLY:        │            │ Sees ONLY:        │\n  │ - final-plan.md   │            │ - final-plan.md   │\n  │ - Source files    │            │ - Source files     │\n  │ - Test files      │            │ - Test files       │\n  │                   │            │                   │\n  │ Focus: minimal    │            │ Focus: complete    │\n  │ diffs, correct    │            │ coverage, tests    │\n  │ ordering          │            │ for everything     │\n  │                   │            │                   │\n  │ CANNOT see B ─────┼── ✗ ──────┼── CANNOT see A    │\n  │                   │            │                   │\n  │ → impl-A.md       │            │ → impl-B.md       │\n  └───────────────────┘            └───────────────────┘\n\n  ◄── Quality check + Convergence check ──►\n\nROUND 2: Synthesis\n─────────────────────────────────────────────────\n  Synthesizer C\n  ┌──────────────────────────────────────┐\n  │ Phase 0: Reads plan + source files   │\n  │ Phase 1-2: Reads impl-A + impl-B    │\n  │ Phase 3: Verifies diffs against src  │\n  │ Phase 4: Merges into impl-C.md      │\n  │ Phase 5: Writes isolated reviews     │\n  │                                      │\n  │ → impl-C.md       (lead-only)       │\n  │ → review-for-A.md (A's eyes only)   │\n  │ → review-for-B.md (B's eyes only)   │\n  └──────────────────────────────────────┘\n\nROUND 3: Feedback (parallel, ISOLATED)\n─────────────────────────────────────────────────\n  Agent A                          Agent B\n  ┌──────────────────┐             ┌──────────────────┐\n  │ Reads ONLY:       │             │ Reads ONLY:       │\n  │ - review-for-A.md │             │ - review-for-B.md │\n  │ + own impl-A.md   │             │ + own impl-B.md   │\n  │                   │             │                   │\n  │ → feedback        │             │ → feedback        │\n  └──────────────────┘             └──────────────────┘\n\nROUND 4: Reconciliation\n─────────────────────────────────────────────────\n  Synthesizer C\n  ┌──────────────────────────────────────┐\n  │ Receives feedback from A and B       │\n  │ Verifies disputed diffs against src  │\n  │ Reconciles into implementation.md    │\n  │ → implementation.md                  │\n  └──────────────────────────────────────┘\n\nOUTPUT: implementation.md (in same directory as final-plan.md)\n```\n\n### Why Two Strategies\n\n| Agent | Strategy | Focus | Catches |\n|-------|----------|-------|---------|\n| A (Surgical) | Minimal diffs, correct ordering | Unnecessary changes, over-engineering | —  |\n| B (Coverage) | Complete tests, nothing dropped | Missed plan items, untested changes, broken existing tests | — |\n\nThe natural tension: A wants to do less, B wants to cover more. The synthesis finds the right balance — every plan item addressed, but no unnecessary bloat.\n\n---\n\n## How to Execute\n\nWhen the user triggers this skill, you (the lead) orchestrate the entire workflow.\n\nFor Codex, interpret the teammate-specific call patterns in the upstream references as conceptual. Preserve the same round structure, isolation rules, and artifact flow with Codex subagents or the fallback workflow.\n\n### Step 0: Gather Context\n\n1. Get the **path to `final-plan.md`** from the user's command\n2. **Read the final plan** — extract:\n   - All source file paths referenced\n   - All test file paths referenced (or derive them from source paths)\n   - Every discrete plan item (these become the coverage matrix rows)\n3. **Determine output directory** — same directory as `final-plan.md`\n4. **Rename existing review files** if they exist from the proposal phase:\n   - `review-for-A.md` → `proposal-review-for-A.md`\n   - `review-for-B.md` → `proposal-review-for-B.md`\n5. Read the agent role files to embed in prompts:\n   - `agents\u002Fimplementer.md`\n   - `agents\u002Fguardian.md`\n   - `agents\u002Fsynthesizer.md`\n   - `agents\u002Fcritic.md`\n   - `agents\u002Freconciler.md`\n   - `references\u002Fimplementation-format.md`\n\n### Step 1: Round 1 — Spawn A and B (Parallel)\n\nSpawn both agents **in the same turn** for parallel execution.\n\n**Agent A prompt must include:**\n- Full content of `final-plan.md`\n- List of source file paths to read and verify\n- Implementer role (from `agents\u002Fimplementer.md`)\n- Implementation format (from `references\u002Fimplementation-format.md`)\n- Strategy assignment: **Surgical** — minimal diffs, correct ordering\n- Output path: `{output_dir}\u002Fimpl-A.md`\n- Investigation notes path: `{output_dir}\u002Fimpl-notes-A.md`\n- Isolation rule: do NOT read impl-B.md or any other impl files\n\n**Agent B prompt must include:**\n- Same plan and source files\n- Guardian role (from `agents\u002Fguardian.md`)\n- Same implementation format\n- Strategy assignment: **Coverage** — complete tests, nothing dropped\n- Output path: `{output_dir}\u002Fimpl-B.md`\n- Investigation notes path: `{output_dir}\u002Fimpl-notes-B.md`\n- Isolation rule: do NOT read impl-A.md or any other impl files\n\n**Both prompts must instruct the agent to WAIT after completing**, not exit.\n\nMonitor inbox for \"done\" messages from both.\n\nAfter both arrive: **quality check** then **convergence check**. Treat forge-coder executability as part of the quality check, not a later nice-to-have.\n\n### Step 1.5: Quality Check\n\nVerify each implementation doc has:\n1. Plan items inventory — all items from the plan listed\n2. Implementation steps with exact `old_string → new_string` diffs\n3. Every modification step uses an `old_string` that is unique in the current target file\n4. Every new-file step uses `**Action**: new_file`, `# old_string` with the literal body `# new file`, and a `# new_string` block containing the full file content\n5. No standalone `# new_file` blocks, prose placeholders, partial snippets for new files, or \"rest of file unchanged\" shortcuts\n6. Coverage matrix with Status column\n7. Test specifications (new and modified)\n8. Every step includes a concrete verification command\n9. Commit groups with tests that are runnable immediately after that group's steps are applied\n10. Definition of done\n\nIf a doc fails, message the agent with specific feedback and request revision. Do not advance a document that is human-readable but not forge-coder-executable.\n\n### Step 1.6: Convergence Check\n\nIf both implementations produce the same diffs and same tests for all plan items, skip Rounds 2-3. Spawn C for a lightweight review (verify diffs against source, check for missed items), then produce `implementation.md` directly.\n\n### Step 2: Round 2 — Spawn C\n\n```\nSpawn synthesizer with:\n- Instruction to read source files FIRST (Phase 0)\n- Then read impl-A.md and impl-B.md\n- Synthesizer role (from agents\u002Fsynthesizer.md)\n- Produce THREE files: impl-C.md, review-for-A.md, review-for-B.md\n- Isolation rules for review files\n- Wait for instructions\n```\n\n### Step 3: Round 3 — Message A and B\n\nWhen C completes, message both agents with their review files. Same isolation rules as the proposal skill.\n\n### Step 4: Round 4 — Forward Feedback to C\n\nWhen both feedback messages arrive, forward to C with the reconciler role. C produces `implementation.md`.\n\n### Step 4.5: Forge-Coder Compatibility Gate\n\nBefore presenting the final `implementation.md`, do a final mechanical review:\n\n1. Every step has exactly one `File` and exactly one `old_string\u002Fnew_string` diff pair\n2. Every modification `old_string` is copied from the current source and is unique enough for an edit tool to apply without ambiguity\n3. Every new file uses the canonical format:\n   - `**Action**: new_file`\n   - `# old_string` body is exactly `# new file`\n   - `# new_string` contains the full file contents\n4. No step relies on prose like \"insert this near...\" or \"rest of file unchanged\"\n5. Every commit-group test command can run after the steps in that group, without depending on files created in later groups\n6. Coverage matrix, test specifications, and definition of done are all still present after reconciliation\n\nIf any of these checks fail, send the document back to the reconciler with concrete fixes. Do not present it as final.\n\n### Step 5: Cleanup and Present\n\nShutdown all agents. Present `implementation.md` to the user only after the compatibility gate passes. Offer to:\n- Show the full deliberation trail\n- Explain specific decisions\n- Proceed to execute the implementation\n- Re-run any round\n\n---\n\n## Building the Agent Prompts\n\nEach prompt must be **self-contained** — embed everything inline.\n\n### What to Embed in Every Prompt\n\n1. **The full content of `final-plan.md`** — verbatim\n2. **Source file paths** — explicit list of every file to read and verify\n3. **Test file paths** — existing tests that may need updating\n4. **The agent role** — full content from the relevant `agents\u002F*.md` file\n5. **The implementation format** — full content from `references\u002Fimplementation-format.md`\n6. **The output path and filename** — exact save location\n7. **The isolation rule** — for A and B in Rounds 1 and 3\n8. **The strategy assignment** — Surgical for A, Coverage for B\n9. **The \"wait\" instruction** — tell agents to wait after completing\n\n### Critical Instruction for All Agents\n\n> \"You MUST read every source file referenced in the plan BEFORE writing any diffs. Verify that line numbers, function signatures, and variable names in the plan match the actual code. If they don't, use the actual code — do not copy stale references from the plan.\"\n\n---\n\n## Error Handling\n\n### Agent Timeout \u002F Exit Recovery\n\n| Round | Failure | Recovery |\n|-------|---------|----------|\n| Round 1 | One agent fails | Wait for the other. C reviews single doc for gaps. |\n| Round 1 | Both fail | Abort workflow. Report to user. |\n| Round 2 | Synthesizer fails | Re-spawn C. If second attempt fails, present both raw docs. |\n| Round 3 | One agent fails | Proceed to Round 4 with available feedback. |\n| Round 3 | Both fail | Proceed to Round 4 with no feedback. C reconciles from synthesis alone. |\n| Round 4 | Synthesizer fails | Re-spawn reconciler. If second attempt fails, present impl-C.md. |\n\n### Quality Gate Failures\n\nIf an implementation doc fails the quality check after Round 1, message the agent with specific feedback and request revision before proceeding.\n\n---\n\n## Known Tradeoffs\n\n**Reconciler bias toward own synthesis**: Same as the proposal skill — C naturally favors its own impl-C.md when reconciling. The reconciler role includes bias awareness guidance, but for critical implementations, review the synthesis yourself before feedback rounds.\n\n**Diff staleness**: Between the time agents read source files and the time `implementation.md` is produced, the source code could change (if someone is actively coding). The implementation doc captures a point-in-time snapshot. If the code changes, diffs may need re-verification.\n\n---\n\n## Invoking the Skill\n\n### Direct Prompt\n\n```\n\u002Fadversarial-implementation .dev\u002Fproposals\u002Fcaption-audio-sync-drift\u002Ffinal-plan.md\n```\n\n### As a Reusable Command Wrapper\n\nSave as the equivalent command wrapper for your environment:\n\n```\nRead the installed adversarial implementation skill and use the workflow it describes.\nUse the workflow described to produce an implementation document from the given plan.\n\nCreate three isolated workers: implementer-a (Surgical) and implementer-b (Coverage Guardian) work\nindependently (FULLY ISOLATED), synthesizer-c reviews both and produces a synthesis. Then A\nand B critique C. C reconciles into a final implementation.md.\n\nPlan path: $ARGUMENTS\n```\n\n---\n\n## Output Directory\n\nFiles are saved in the **same directory** as the input `final-plan.md`:\n\n```\n{project}\u002F.dev\u002Fproposals\u002F{issue-slug}\u002F\n├── final-plan.md                ← Input\n├── impl-A.md                   ← Round 1: Surgical Implementer\n├── impl-B.md                   ← Round 1: Coverage Guardian\n├── impl-notes-A.md             ← Round 1: A's investigation notes (subagent fallback)\n├── impl-notes-B.md             ← Round 1: B's investigation notes (subagent fallback)\n├── impl-C.md                   ← Round 2: Synthesis (lead-only)\n├── review-for-A.md             ← Round 2: C's review for A\n├── review-for-B.md             ← Round 2: C's review for B\n├── impl-feedback-A.md          ← Round 3: A's feedback (subagent fallback)\n├── impl-feedback-B.md          ← Round 3: B's feedback (subagent fallback)\n└── implementation.md            ← Round 4: FINAL DELIVERABLE\n```\n\n---\n\n## Reference Files\n\n| File | When to Read | Purpose |\n|------|-------------|---------|\n| `references\u002Fimplementation-format.md` | When building agent prompts | Implementation doc template to embed |\n| `references\u002Fsubagent-fallback.md` | If persistent teammate messaging is not available | Alternative workflow using Codex subagents or file coordination |\n| `agents\u002Fimplementer.md` | When building A's prompt | Surgical implementer role |\n| `agents\u002Fguardian.md` | When building B's prompt | Coverage guardian role |\n| `agents\u002Fsynthesizer.md` | When building C's Round 2 prompt | Synthesis role |\n| `agents\u002Fcritic.md` | When messaging A and B in Round 3 | Feedback guidance |\n| `agents\u002Freconciler.md` | When messaging C in Round 4 | Reconciliation + bias awareness |\n\n## Agent Roles Summary\n\n| Agent | File | Used In | Purpose |\n|-------|------|---------|---------|\n| Implementer | `agents\u002Fimplementer.md` | Round 1 (A) | Surgical: minimal exact diffs |\n| Guardian | `agents\u002Fguardian.md` | Round 1 (B) | Coverage: tests for everything, nothing dropped |\n| Synthesizer | `agents\u002Fsynthesizer.md` | Round 2 (C) | Merge best of both, verify against source |\n| Critic | `agents\u002Fcritic.md` | Round 3 (A and B) | Review synthesis, flag issues |\n| Reconciler | `agents\u002Freconciler.md` | Round 4 (C) | Reconcile feedback, produce final implementation.md |\n","# Adversarial Implementation Framework\n\n## Overview\n\nThis skill takes a `final-plan.md` (typically from the adversarial-proposal skill) and produces a complete, vetted `implementation.md` with exact code diffs, test specifications, and a coverage matrix that proves every plan item is addressed.\n\nThe same adversarial process that works for planning applies here: two agents independently produce implementation documents from the same plan, a synthesizer merges the best of both, the original agents critique the synthesis, and the synthesizer reconciles into a final implementation document.\n\nThe critical output is the **coverage matrix** — a table mapping every plan item to a specific code diff and a specific test. Zero gaps allowed.\n\nThe final document must be mechanically executable by `$forge-coder`, not merely understandable to a human reviewer. Parser-safe structure, unique `old_string` values, runnable commit-group tests, and exact new-file encoding are mandatory.\n\nThis Codex copy keeps the generalized Claude workflow but expects Codex-native delegation. When the upstream docs mention teammate APIs, translate them to Codex subagents or use the file-based fallback.\n\n## When to Use\n\n- After `adversarial-proposal` produces a `final-plan.md`\n- When you have any implementation plan and want vetted, exact diffs before coding\n- When previous implementations have missed items from the plan\n- When testing coverage is critical\n\n## Prerequisites\n\nThis skill follows the generalized multi-agent protocol from the authoritative Claude version.\n\n- In Codex, prefer native subagents to preserve isolation between A, B, and C.\n- When the upstream docs mention teammate APIs, map them to Codex delegation primitives such as `spawn_agent`, `send_input`, and `wait_agent`.\n- If persistent subagent messaging is not practical, use `references\u002Fsubagent-fallback.md`.\n\n## Architecture\n\n```\nINPUT: final-plan.md (from adversarial-proposal or any plan)\n─────────────────────────────────────────────────\n\nROUND 0: Setup\n─────────────────────────────────────────────────\n  Lead reads final-plan.md → extracts source files + plan items\n  Strategy pair: A=Surgical, B=Coverage\n\nROUND 1: Independent Implementation Planning (parallel)\n─────────────────────────────────────────────────\n  Agent A (Surgical)              Agent B (Coverage Guardian)\n  ┌──────────────────┐            ┌──────────────────┐\n  │ Own context       │            │ Own context       │\n  │                   │            │                   │\n  │ Sees ONLY:        │            │ Sees ONLY:        │\n  │ - final-plan.md   │            │ - final-plan.md   │\n  │ - Source files    │            │ - Source files     │\n  │ - Test files      │            │ - Test files       │\n  │                   │            │                   │\n  │ Focus: minimal    │            │ Focus: complete    │\n  │ diffs, correct    │            │ coverage, tests    │\n  │ ordering          │            │ for everything     │\n  │                   │            │                   │\n  │ CANNOT see B ─────┼── ✗ ──────┼── CANNOT see A    │\n  │                   │            │                   │\n  │ → impl-A.md       │            │ → impl-B.md       │\n  └───────────────────┘            └───────────────────┘\n\n  ◄── Quality check + Convergence check ──►\n\nROUND 2: Synthesis\n─────────────────────────────────────────────────\n  Synthesizer C\n  ┌──────────────────────────────────────┐\n  │ Phase 0: Reads plan + source files   │\n  │ Phase 1-2: Reads impl-A + impl-B    │\n  │ Phase 3: Verifies diffs against src  │\n  │ Phase 4: Merges into impl-C.md      │\n  │ Phase 5: Writes isolated reviews     │\n  │                                      │\n  │ → impl-C.md       (lead-only)       │\n  │ → review-for-A.md (A's eyes only)   │\n  │ → review-for-B.md (B's eyes only)   │\n  └──────────────────────────────────────┘\n\nROUND 3: Feedback (parallel, ISOLATED)\n─────────────────────────────────────────────────\n  Agent A                          Agent B\n  ┌──────────────────┐             ┌──────────────────┐\n  │ Reads ONLY:       │             │ Reads ONLY:       │\n  │ - review-for-A.md │             │ - review-for-B.md │\n  │ + own impl-A.md   │             │ + own impl-B.md   │\n  │                   │             │                   │\n  │ → feedback        │             │ → feedback        │\n  └──────────────────┘             └──────────────────┘\n\nROUND 4: Reconciliation\n─────────────────────────────────────────────────\n  Synthesizer C\n  ┌──────────────────────────────────────┐\n  │ Receives feedback from A and B       │\n  │ Verifies disputed diffs against src  │\n  │ Reconciles into implementation.md    │\n  │ → implementation.md                  │\n  └──────────────────────────────────────┘\n\nOUTPUT: implementation.md (in same directory as final-plan.md)\n```\n\n### Why Two Strategies\n\n| Agent | Strategy | Focus | Catches |\n|-------|----------|-------|---------|\n| A (Surgical) | Minimal diffs, correct ordering | Unnecessary changes, over-engineering | —  |\n| B (Coverage) | Complete tests, nothing dropped | Missed plan items, untested changes, broken existing tests | — |\n\nThe natural tension: A wants to do less, B wants to cover more. The synthesis finds the right balance — every plan item addressed, but no unnecessary bloat.\n\n---\n\n## How to Execute\n\nWhen the user triggers this skill, you (the lead) orchestrate the entire workflow.\n\nFor Codex, interpret the teammate-specific call patterns in the upstream references as conceptual. Preserve the same round structure, isolation rules, and artifact flow with Codex subagents or the fallback workflow.\n\n### Step 0: Gather Context\n\n1. Get the **path to `final-plan.md`** from the user's command\n2. **Read the final plan** — extract:\n   - All source file paths referenced\n   - All test file paths referenced (or derive them from source paths)\n   - Every discrete plan item (these become the coverage matrix rows)\n3. **Determine output directory** — same directory as `final-plan.md`\n4. **Rename existing review files** if they exist from the proposal phase:\n   - `review-for-A.md` → `proposal-review-for-A.md`\n   - `review-for-B.md` → `proposal-review-for-B.md`\n5. Read the agent role files to embed in prompts:\n   - `agents\u002Fimplementer.md`\n   - `agents\u002Fguardian.md`\n   - `agents\u002Fsynthesizer.md`\n   - `agents\u002Fcritic.md`\n   - `agents\u002Freconciler.md`\n   - `references\u002Fimplementation-format.md`\n\n### Step 1: Round 1 — Spawn A and B (Parallel)\n\nSpawn both agents **in the same turn** for parallel execution.\n\n**Agent A prompt must include:**\n- Full content of `final-plan.md`\n- List of source file paths to read and verify\n- Implementer role (from `agents\u002Fimplementer.md`)\n- Implementation format (from `references\u002Fimplementation-format.md`)\n- Strategy assignment: **Surgical** — minimal diffs, correct ordering\n- Output path: `{output_dir}\u002Fimpl-A.md`\n- Investigation notes path: `{output_dir}\u002Fimpl-notes-A.md`\n- Isolation rule: do NOT read impl-B.md or any other impl files\n\n**Agent B prompt must include:**\n- Same plan and source files\n- Guardian role (from `agents\u002Fguardian.md`)\n- Same implementation format\n- Strategy assignment: **Coverage** — complete tests, nothing dropped\n- Output path: `{output_dir}\u002Fimpl-B.md`\n- Investigation notes path: `{output_dir}\u002Fimpl-notes-B.md`\n- Isolation rule: do NOT read impl-A.md or any other impl files\n\n**Both prompts must instruct the agent to WAIT after completing**, not exit.\n\nMonitor inbox for \"done\" messages from both.\n\nAfter both arrive: **quality check** then **convergence check**. Treat forge-coder executability as part of the quality check, not a later nice-to-have.\n\n### Step 1.5: Quality Check\n\nVerify each implementation doc has:\n1. Plan items inventory — all items from the plan listed\n2. Implementation steps with exact `old_string → new_string` diffs\n3. Every modification step uses an `old_string` that is unique in the current target file\n4. Every new-file step uses `**Action**: new_file`, `# old_string` with the literal body `# new file`, and a `# new_string` block containing the full file content\n5. No standalone `# new_file` blocks, prose placeholders, partial snippets for new files, or \"rest of file unchanged\" shortcuts\n6. Coverage matrix with Status column\n7. Test specifications (new and modified)\n8. Every step includes a concrete verification command\n9. Commit groups with tests that are runnable immediately after that group's steps are applied\n10. Definition of done\n\nIf a doc fails, message the agent with specific feedback and request revision. Do not advance a document that is human-readable but not forge-coder-executable.\n\n### Step 1.6: Convergence Check\n\nIf both implementations produce the same diffs and same tests for all plan items, skip Rounds 2-3. Spawn C for a lightweight review (verify diffs against source, check for missed items), then produce `implementation.md` directly.\n\n### Step 2: Round 2 — Spawn C\n\n```\nSpawn synthesizer with:\n- Instruction to read source files FIRST (Phase 0)\n- Then read impl-A.md and impl-B.md\n- Synthesizer role (from agents\u002Fsynthesizer.md)\n- Produce THREE files: impl-C.md, review-for-A.md, review-for-B.md\n- Isolation rules for review files\n- Wait for instructions\n```\n\n### Step 3: Round 3 — Message A and B\n\nWhen C completes, message both agents with their review files. Same isolation rules as the proposal skill.\n\n### Step 4: Round 4 — Forward Feedback to C\n\nWhen both feedback messages arrive, forward to C with the reconciler role. C produces `implementation.md`.\n\n### Step 4.5: Forge-Coder Compatibility Gate\n\nBefore presenting the final `implementation.md`, do a final mechanical review:\n\n1. Every step has exactly one `File` and exactly one `old_string\u002Fnew_string` diff pair\n2. Every modification `old_string` is copied from the current source and is unique enough for an edit tool to apply without ambiguity\n3. Every new file uses the canonical format:\n   - `**Action**: new_file`\n   - `# old_string` body is exactly `# new file`\n   - `# new_string` contains the full file contents\n4. No step relies on prose like \"insert this near...\" or \"rest of file unchanged\"\n5. Every commit-group test command can run after the steps in that group, without depending on files created in later groups\n6. Coverage matrix, test specifications, and definition of done are all still present after reconciliation\n\nIf any of these checks fail, send the document back to the reconciler with concrete fixes. Do not present it as final.\n\n### Step 5: Cleanup and Present\n\nShutdown all agents. Present `implementation.md` to the user only after the compatibility gate passes. Offer to:\n- Show the full deliberation trail\n- Explain specific decisions\n- Proceed to execute the implementation\n- Re-run any round\n\n---\n\n## Building the Agent Prompts\n\nEach prompt must be **self-contained** — embed everything inline.\n\n### What to Embed in Every Prompt\n\n1. **The full content of `final-plan.md`** — verbatim\n2. **Source file paths** — explicit list of every file to read and verify\n3. **Test file paths** — existing tests that may need updating\n4. **The agent role** — full content from the relevant `agents\u002F*.md` file\n5. **The implementation format** — full content from `references\u002Fimplementation-format.md`\n6. **The output path and filename** — exact save location\n7. **The isolation rule** — for A and B in Rounds 1 and 3\n8. **The strategy assignment** — Surgical for A, Coverage for B\n9. **The \"wait\" instruction** — tell agents to wait after completing\n\n### Critical Instruction for All Agents\n\n> \"You MUST read every source file referenced in the plan BEFORE writing any diffs. Verify that line numbers, function signatures, and variable names in the plan match the actual code. If they don't, use the actual code — do not copy stale references from the plan.\"\n\n---\n\n## Error Handling\n\n### Agent Timeout \u002F Exit Recovery\n\n| Round | Failure | Recovery |\n|-------|---------|----------|\n| Round 1 | One agent fails | Wait for the other. C reviews single doc for gaps. |\n| Round 1 | Both fail | Abort workflow. Report to user. |\n| Round 2 | Synthesizer fails | Re-spawn C. If second attempt fails, present both raw docs. |\n| Round 3 | One agent fails | Proceed to Round 4 with available feedback. |\n| Round 3 | Both fail | Proceed to Round 4 with no feedback. C reconciles from synthesis alone. |\n| Round 4 | Synthesizer fails | Re-spawn reconciler. If second attempt fails, present impl-C.md. |\n\n### Quality Gate Failures\n\nIf an implementation doc fails the quality check after Round 1, message the agent with specific feedback and request revision before proceeding.\n\n---\n\n## Known Tradeoffs\n\n**Reconciler bias toward own synthesis**: Same as the proposal skill — C naturally favors its own impl-C.md when reconciling. The reconciler role includes bias awareness guidance, but for critical implementations, review the synthesis yourself before feedback rounds.\n\n**Diff staleness**: Between the time agents read source files and the time `implementation.md` is produced, the source code could change (if someone is actively coding). The implementation doc captures a point-in-time snapshot. If the code changes, diffs may need re-verification.\n\n---\n\n## Invoking the Skill\n\n### Direct Prompt\n\n```\n\u002Fadversarial-implementation .dev\u002Fproposals\u002Fcaption-audio-sync-drift\u002Ffinal-plan.md\n```\n\n### As a Reusable Command Wrapper\n\nSave as the equivalent command wrapper for your environment:\n\n```\nRead the installed adversarial implementation skill and use the workflow it describes.\nUse the workflow described to produce an implementation document from the given plan.\n\nCreate three isolated workers: implementer-a (Surgical) and implementer-b (Coverage Guardian) work\nindependently (FULLY ISOLATED), synthesizer-c reviews both and produces a synthesis. Then A\nand B critique C. C reconciles into a final implementation.md.\n\nPlan path: $ARGUMENTS\n```\n\n---\n\n## Output Directory\n\nFiles are saved in the **same directory** as the input `final-plan.md`:\n\n```\n{project}\u002F.dev\u002Fproposals\u002F{issue-slug}\u002F\n├── final-plan.md                ← Input\n├── impl-A.md                   ← Round 1: Surgical Implementer\n├── impl-B.md                   ← Round 1: Coverage Guardian\n├── impl-notes-A.md             ← Round 1: A's investigation notes (subagent fallback)\n├── impl-notes-B.md             ← Round 1: B's investigation notes (subagent fallback)\n├── impl-C.md                   ← Round 2: Synthesis (lead-only)\n├── review-for-A.md             ← Round 2: C's review for A\n├── review-for-B.md             ← Round 2: C's review for B\n├── impl-feedback-A.md          ← Round 3: A's feedback (subagent fallback)\n├── impl-feedback-B.md          ← Round 3: B's feedback (subagent fallback)\n└── implementation.md            ← Round 4: FINAL DELIVERABLE\n```\n\n---\n\n## Reference Files\n\n| File | When to Read | Purpose |\n|------|-------------|---------|\n| `references\u002Fimplementation-format.md` | When building agent prompts | Implementation doc template to embed |\n| `references\u002Fsubagent-fallback.md` | If persistent teammate messaging is not available | Alternative workflow using Codex subagents or file coordination |\n| `agents\u002Fimplementer.md` | When building A's prompt | Surgical implementer role |\n| `agents\u002Fguardian.md` | When building B's prompt | Coverage guardian role |\n| `agents\u002Fsynthesizer.md` | When building C's Round 2 prompt | Synthesis role |\n| `agents\u002Fcritic.md` | When messaging A and B in Round 3 | Feedback guidance |\n| `agents\u002Freconciler.md` | When messaging C in Round 4 | Reconciliation + bias awareness |\n\n## Agent Roles Summary\n\n| Agent | File | Used In | Purpose |\n|-------|------|---------|---------|\n| Implementer | `agents\u002Fimplementer.md` | Round 1 (A) | Surgical: minimal exact diffs |\n| Guardian | `agents\u002Fguardian.md` | Round 1 (B) | Coverage: tests for everything, nothing dropped |\n| Synthesizer | `agents\u002Fsynthesizer.md` | Round 2 (C) | Merge best of both, verify against source |\n| Critic | `agents\u002Fcritic.md` | Round 3 (A and B) | Review synthesis, flag issues |\n| Reconciler | `agents\u002Freconciler.md` | Round 4 (C) | Reconcile feedback, produce final implementation.md |\n",{"name":5,"description":7},"main","50bb36677eced958128cea262c304bf9ceee4d4e","codex-skills\u002Fadversarial-implementation","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit","https:\u002F\u002Fgithub.com\u002FSirTheOracle","2026-10-20 00:50:37",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add SirTheOracle\u002Fforge-toolkit --skill adversarial-implementation",{"tool":60,"command":61},"bunx","bunx skills add SirTheOracle\u002Fforge-toolkit --skill adversarial-implementation",{"tool":63,"command":64},"pnpm","pnpm dlx skills add SirTheOracle\u002Fforge-toolkit --skill adversarial-implementation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-implementation\u002FSKILL.md",true,[68,74,78,82,86,90,94,98],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"agents\u002Fcritic.md","REFERENCE","参考文档",2207,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-implementation\u002Fagents\u002Fcritic.md",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"agents\u002Fguardian.md",3460,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-implementation\u002Fagents\u002Fguardian.md",{"path":79,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":80,"sourceHtmlUrl":81},"agents\u002Fimplementer.md",3335,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-implementation\u002Fagents\u002Fimplementer.md",{"path":83,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":84,"sourceHtmlUrl":85},"agents\u002Fopenai.yaml",268,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-implementation\u002Fagents\u002Fopenai.yaml",{"path":87,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":88,"sourceHtmlUrl":89},"agents\u002Freconciler.md",4488,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-implementation\u002Fagents\u002Freconciler.md",{"path":91,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":92,"sourceHtmlUrl":93},"agents\u002Fsynthesizer.md",3608,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-implementation\u002Fagents\u002Fsynthesizer.md",{"path":95,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fimplementation-format.md",4957,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-implementation\u002Freferences\u002Fimplementation-format.md",{"path":99,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fsubagent-fallback.md",7293,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-implementation\u002Freferences\u002Fsubagent-fallback.md",[103,128,151,167,188,210],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":43},"01M70FS350DG1MT6NBPYRPBFBQ","forge-orchestrator","tmux-based orchestrator for multi-agent building. Coordinates work across Claude Code and two Codex workers via forge-bridge. Translates user requests into dispatched tasks with structured audit logging. Replaces forge-dispatch, forge-state.yml, and stage-routing-map.yml.","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fforge-orchestrator\u002FSKILL.md",[],[110,111,112,113,114,38,115,116,117,118,29,119,120,121,122,123,124,125,126,127],"forge","orchestrator","forge orchestrator","bridge","map","tasks","across","work","audit","logging","tmux","for","audit logging","workers","stage","with","multi","state",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":43},"01M70FRYFZC51YWHVNNS3862PY","forge-fix-runner","Drain the GitHub `forge-fix` issue queue through the forge fix pipeline, one service at a time. Tallies actionable issues worst-first, scouts a service into a routing plan (clusters + quick\u002Ffull tiers), gets human approval, then dispatches fixes (quick = dispatched fix-code; full = forge-pipeline), gating every `Closes #N` on per-issue verification. Trigger when the user wants to fix triaged QA issues, \"work the forge-fix queue\", or \"run the fix runner\".","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fforge-fix-runner\u002FSKILL.md",[],[135,136,110,137,138,139,140,141,142,143,144,145,38,146,117,35,147,148,149,150],"runner","fix","forge fix runner","quick","pipeline","actionable","time","issues","qa","gating","when","verification","human","run","at","issue",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":43},"01M70FRVVW3JAGQQK3FFR2VYRC","forge-coder","Procedural coding skill. Reads implementation.md, validates diffs against the codebase, applies changes in execution order, runs tests after each commit group, and produces a coder-report.md artifact.","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fforge-coder\u002FSKILL.md",[],[110,158,159,40,160,26,161,162,163,164,165,166,24,28],"forge coder","coder","tests","commit","changes","artifact","procedural","report","codebase",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":43},"01M70FRRYF6E22ECC8AGYYJEQ7","fix-reproducer","Optional first stage of the fix-pipeline. Verifies a reported bug is reproducible and captures deterministic repro steps, environment state, and evidence. Single procedural executor — does not spawn sub-agents and does not diagnose. Branches by environment: dev path runs the bug locally; prod path gathers observational evidence from the deployed environment. Always writes repro.md, even on NOT REPRODUCED. Trigger when the user invokes a fix-pipeline with the reproduce step enabled.","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Ffix-reproducer\u002FSKILL.md",[],[174,175,136,176,177,178,179,139,180,181,182,183,184,185,186,145,124,125,127,187],"reproducer","fix reproducer","deterministic","evidence","executor","diagnose","Reproducible","environment","trigger","branches","dev","single","repro","first",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"publishedAt":43},"01M70FRN8THYBT2DJVX99XQ3CM","fix-plan-reviewer","Single-agent adversarial reviewer for fix plans. Reads diagnosis.md and fix-plan.md, verifies the plan actually addresses the diagnosed cause, attacks the plan from multiple angles (cause coverage, defense adequacy, scope correctness, regression risk, rollback integrity, test plan integrity, risk honesty), and produces fix-review.md with severity-rated issues. Does NOT propose fixes for the issues — that is the revise mode of adversarial-fix-plan. Does NOT re-investigate the diagnosis. Trigger as the review stage of a fix-pipeline, after adversarial-fix-plan has produced fix-plan.md.","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Ffix-plan-reviewer\u002FSKILL.md",[],[195,136,196,35,197,42,198,199,139,200,201,142,202,203,204,205,206,207,208,209],"fix plan reviewer","reviewer","plan reviewer","scope","regression","re","mode","review","diagnosis","defense","integrity","addresses","revise","attacks","as",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":216,"publishedAt":43},"01M70FRHGG6HN0VW483NDKX161","fix-coder","Mechanical single-executor that applies a vetted fix plan to the codebase. Reads fix-plan.md (the Changes, Defenses, and Test Plan sections), translates file-level changes into concrete diffs, applies them, runs the test plan, validates that the bug is no longer reproducible (dev) or that the test exercising the failing path passes (prod), and produces a single fix commit. Stays strictly in scope: does NOT modify the plan, does NOT re-investigate, does NOT touch files outside the plan. Always writes fix-coder-report.md, even on failure. Trigger as the implementation stage of a fix-pipeline, after fix-plan-reviewer has approved fix-plan.md.","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Ffix-coder\u002FSKILL.md",[],[136,217,159,178,198,139,200,218,219,40,220,161,196,35,221,222,209,223,180,182],"fix coder","failing","mechanical","files","bug","path","test plan"]