[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FP8EGXFS3R995H04DVW88":3,"skill-same:01M70FP8EGXFS3R995H04DVW88":98},{"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},"01M70FP8EGXFS3R995H04DVW88","adversarial-proposal",null,"Multi-perspective adversarial proposal framework for investigating bugs, planning features, or solving complex technical problems. Requires truly isolated proposal generation: Proposal A and Proposal B must be produced by separate agent sessions that do not share context or see each other's outputs. Proposal C then synthesizes both, followed by separate A\u002FB critiques of C, and a reconciled final plan. Do not simulate independence inside a single session. If isolated execution is unavailable, stop and tell the user the skill cannot be followed as specified. Use this skill whenever the user wants to investigate a bug fix, plan a feature, create an implementation strategy, or says things like \"propose a fix\", \"investigate this issue\", \"come up with a plan\", \"adversarial review\", \"multi-proposal\", or \"debate approach\". Also trigger when the user wants thorough analysis before implementation.","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-proposal\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","adversarial proposal","proposal","do","as","framework","context","stop","agent sessions","issue","bug","features","plan","create","review","analysis","when","fix","up","debate","2026-11-10 10:12:30",false,"---\nname: adversarial-proposal\ndescription: >\n  Multi-perspective adversarial proposal framework for investigating bugs, planning features, or solving\n  complex technical problems. Requires truly isolated proposal generation: Proposal A and Proposal B must be\n  produced by separate agent sessions that do not share context or see each other's outputs. Proposal C then\n  synthesizes both, followed by separate A\u002FB critiques of C, and a reconciled final plan. Do not simulate\n  independence inside a single session. If isolated execution is unavailable, stop and tell the user the\n  skill cannot be followed as specified. Use this skill whenever the user wants to investigate a bug fix,\n  plan a feature, create an implementation strategy, or says things like \"propose a fix\", \"investigate this\n  issue\", \"come up with a plan\", \"adversarial review\", \"multi-proposal\", or \"debate approach\". Also trigger\n  when the user wants thorough analysis before implementation.\n---\n\n# Adversarial Proposal Framework\n\n## Overview\n\nThis skill runs an adversarial investigation workflow that forces multiple independent perspectives on a problem before committing to a solution. Instead of one analysis pass (which risks tunnel vision), it requires separate agent sessions to generate competing proposals, cross-examines them, and reconciles the results into a battle-tested plan.\n\n## Non-Negotiable Constraint\n\nThe independence requirement is strict:\n\n- Proposal A and Proposal B must be produced by different agent sessions or workers.\n- Those sessions must not see each other's outputs before their own proposal is complete.\n- You must not claim \"independent\" or \"separate agent\" analysis when both proposals were produced in one shared-context session.\n- If the environment cannot support real isolation, stop and tell the user exactly that. Do not silently downgrade to a single-session version.\n- The same rule applies to the critique round: A-feedback and B-feedback must be produced from separate perspectives with no cross-contamination.\n\n## When to Use\n\n- Bug investigation and fix planning\n- Feature implementation planning\n- Architecture decisions\n- Refactoring strategies\n- Any technical problem where you want high confidence before implementing\n\n## Workflow\n\n```\nROUND 1: Two isolated investigations\n  Agent\u002FSession A ─────── Agent\u002FSession B\n  (surgical\u002Fdirect)       (systemic\u002Fholistic)\n          │                       │\n          └─────────┬─────────────┘\n                    ▼\nROUND 2: Synthesis\n  Agent\u002FSession C reviews A + B, states disagreements,\n  produces a superior combined proposal\n                    │\n         ┌──────────┴─────────────┐\n         ▼                        ▼\nROUND 3: Isolated critique\n  Agent\u002FSession A'            Agent\u002FSession B'\n  critiques C                 critiques C\n  (can know A + C only)       (can know B + C only)\n         │                        │\n         └──────────┬─────────────┘\n                    ▼\nROUND 4: Reconciliation\n  Reconciler produces final-plan.md\n```\n\n## How to Execute\n\n### Step 0: Gather Context\n\n1. Get the **problem statement** from the user\n2. Identify the **relevant source files** — ask the user or search the codebase\n3. Create the output directory: `{project}\u002F.dev\u002Fproposals\u002F{issue-slug}\u002F`\n4. Save the problem statement as `problem-statement.md`\n5. Verify you have a real isolated-execution path for separate agents\u002Fsessions\n6. If you do not, stop and tell the user the skill cannot be executed faithfully in the current environment\n7. **Read all the source files** thoroughly before starting any proposals — the quality of the entire process depends on deep understanding of the code\n\n### Step 0.5: Prepare Isolated Execution\n\nBefore Proposal A starts, define the isolation method in writing inside the proposal directory:\n\n- What tool\u002Fsession mechanism is being used for Agent A\n- What tool\u002Fsession mechanism is being used for Agent B\n- How you are preventing shared context between them\n- How A-feedback and B-feedback will be isolated later\n\nSave this as `execution-method.md`.\n\nAccepted approaches:\n\n- Separate worker sessions managed by an external dispatcher\n- Separate `codex exec` or equivalent runs that do not share prior outputs in context\n- Separate human-run agent sessions where each agent only receives the allowed inputs\n\nRejected approaches:\n\n- \"Mental reset\" in the same conversation\n- \"Treat Proposal B as independent\" after Proposal A was already written in the same session\n- Any single-session workflow where both proposals are generated by the same live context\n\n### Step 1: Proposal A — The Surgical Perspective\n\nRead `agents\u002Fproposer-alpha.md` for the full mindset.\n\nInputs allowed for Agent A:\n- `problem-statement.md`\n- Relevant source files\n- Referenced skill files\n\nInputs forbidden for Agent A:\n- `proposal-B.md`\n- Any notes summarizing Proposal B\n- Any synthesis notes\n\nInvestigate the problem with this lens:\n- What is the most direct root cause?\n- What is the smallest, lowest-risk fix?\n- Trace the exact code path from input to broken output\n- Occam's razor — prefer simple explanations\n\nWrite the proposal following the format in `references\u002Fproposal-format.md`.\nSave as `proposal-A.md`.\n\n### Step 2: Proposal B — The Systemic Perspective\n\nRead `agents\u002Fproposer-beta.md` for the full mindset.\n\nProposal B must be executed in a different isolated session from Proposal A.\n\nInputs allowed for Agent B:\n- `problem-statement.md`\n- Relevant source files\n- Referenced skill files\n\nInputs forbidden for Agent B:\n- `proposal-A.md`\n- Any notes summarizing Proposal A\n- Any synthesis notes\n\n**CRITICAL: Approach the problem fresh.** Do NOT simply extend, react to, or refine Proposal A. Investigate from scratch with a different lens:\n- Is this a symptom of a deeper architectural issue?\n- What would prevent this entire class of bugs?\n- Where are the missing validations, contracts, or guarantees?\n- Are there other places where the same pattern breaks?\n\nWrite the proposal following the format in `references\u002Fproposal-format.md`.\nSave as `proposal-B.md`.\n\nThe value of this framework comes from genuinely different analytical perspectives. If B just agrees with A and adds minor points, the process has failed. B should investigate independently and may arrive at a completely different root cause.\n\n### Step 3: Proposal C — Synthesis\n\nRead `agents\u002Fsynthesizer.md` for the full role.\n\nProposal C may read both `proposal-A.md` and `proposal-B.md`, but it must not rewrite history by pretending A and B were isolated if they were not. If isolation was not achieved, abort instead of synthesizing.\n\nNow review both proposals:\n1. Analyze each proposal — do a strict review to see if each is sound or missing anything\n2. State specifically what you disagree with in each\n3. Identify where they agree (high-confidence areas) and where they diverge (needs resolution)\n4. Produce a new proposal that lists the analysis of both proposals first, then the best path forward\n5. Attribute key decisions: what came from A, what from B, what's new in C\n\nSave as `proposal-C.md`.\n\n### Step 4: Feedback — A and B Critique C\n\nRead `agents\u002Fcritic.md` for the feedback approach.\n\nNow run two isolated critique passes:\n\n- A-feedback session can read `proposal-A.md` and `proposal-C.md`, but not `proposal-B.md`\n- B-feedback session can read `proposal-B.md` and `proposal-C.md`, but not `proposal-A.md`\n\nDo not critique C from both perspectives inside one shared-context session if you can avoid it. The critique round should preserve the original separation.\n\n**From A's perspective** (surgical\u002Fminimal lens):\n- What did C lose from A's focused approach?\n- Did scope creep in? Are there unnecessary changes?\n- Does C introduce risks that A's simpler approach avoided?\n- Where is C's proposal stronger than A's?\n\n**From B's perspective** (systemic\u002Fholistic lens):\n- Did C take the quick fix over the right fix?\n- Are there still systemic vulnerabilities C ignores?\n- Did C incorporate the structural improvements from B?\n- Where is C's proposal stronger than B's?\n\nDo not save separate feedback files — carry the feedback directly into the next step.\n\n### Step 5: Final Plan — Reconciliation\n\nRead `agents\u002Freconciler.md` for the reconciliation approach.\n\nTake C's proposal and the feedback from both perspectives:\n1. Review each piece of feedback honestly\n2. Incorporate what's valid — if A or B caught a real issue, fix it\n3. Reject what's not applicable, with clear reasoning\n4. Produce the final implementation plan\n\nSave as `final-plan.md`.\n\nThe final plan must include:\n- Problem statement (refined through the full deliberation)\n- Root cause (final determination with confidence level)\n- Implementation plan (step-by-step, in execution order, with specific files and changes)\n- Feedback reconciliation (what was accepted\u002Frejected from A and B feedback, and why)\n- Risks and mitigations\n- Testing strategy\n\n### Step 6: Present to User\n\nPresent the final plan. Offer to:\n- Show the full deliberation trail\n- Explain specific decisions\n- Proceed to implementation\n- Re-run any round with a different angle\n\n## Isolation Validation Checklist\n\nBefore claiming the skill was followed correctly, confirm all of the following:\n\n- Proposal A and Proposal B were authored in separate agent contexts\n- Proposal B did not read Proposal A before completion\n- A-feedback did not read Proposal B\n- B-feedback did not read Proposal A\n- `execution-method.md` documents the isolation method used\n- If any item above is false, you did not execute this skill correctly\n\nIf you cannot satisfy this checklist, say so explicitly and stop.\n\n## Adapting to Problem Type\n\n| Problem Type | Proposal A Emphasis | Proposal B Emphasis |\n|-------------|-------------------|-------------------|\n| Bug fix | Trace exact data flow breakpoint | Find missing validation\u002Fcontract |\n| Feature | Minimal viable implementation | Full design with extensibility |\n| Architecture | Incremental migration path | Clean-slate ideal design |\n| Refactoring | Targeted surgical changes | Structural pattern improvement |\n\n## Output Directory\n\n```\n{project}\u002F.dev\u002Fproposals\u002F{issue-slug}\u002F\n├── problem-statement.md\n├── proposal-A.md\n├── proposal-B.md\n├── proposal-C.md\n└── final-plan.md\n```\n\n## Agent Roles Reference\n\nRead these files for full role instructions when executing each round:\n\n| Agent | File | Used In | Lens |\n|-------|------|---------|------|\n| Proposer Alpha | `agents\u002Fproposer-alpha.md` | Round 1 (A) | Surgical, minimal, trace-the-exact-bug |\n| Proposer Beta | `agents\u002Fproposer-beta.md` | Round 2 (B) | Systemic, holistic, prevent-the-bug-class |\n| Synthesizer | `agents\u002Fsynthesizer.md` | Round 3 (C) | Impartial reviewer, best-of-both |\n| Critic | `agents\u002Fcritic.md` | Round 4 | Pressure-test C from both perspectives |\n| Reconciler | `agents\u002Freconciler.md` | Round 5 | Make final calls, produce actionable plan |\n","# Adversarial Proposal Framework\n\n## Overview\n\nThis skill runs an adversarial investigation workflow that forces multiple independent perspectives on a problem before committing to a solution. Instead of one analysis pass (which risks tunnel vision), it requires separate agent sessions to generate competing proposals, cross-examines them, and reconciles the results into a battle-tested plan.\n\n## Non-Negotiable Constraint\n\nThe independence requirement is strict:\n\n- Proposal A and Proposal B must be produced by different agent sessions or workers.\n- Those sessions must not see each other's outputs before their own proposal is complete.\n- You must not claim \"independent\" or \"separate agent\" analysis when both proposals were produced in one shared-context session.\n- If the environment cannot support real isolation, stop and tell the user exactly that. Do not silently downgrade to a single-session version.\n- The same rule applies to the critique round: A-feedback and B-feedback must be produced from separate perspectives with no cross-contamination.\n\n## When to Use\n\n- Bug investigation and fix planning\n- Feature implementation planning\n- Architecture decisions\n- Refactoring strategies\n- Any technical problem where you want high confidence before implementing\n\n## Workflow\n\n```\nROUND 1: Two isolated investigations\n  Agent\u002FSession A ─────── Agent\u002FSession B\n  (surgical\u002Fdirect)       (systemic\u002Fholistic)\n          │                       │\n          └─────────┬─────────────┘\n                    ▼\nROUND 2: Synthesis\n  Agent\u002FSession C reviews A + B, states disagreements,\n  produces a superior combined proposal\n                    │\n         ┌──────────┴─────────────┐\n         ▼                        ▼\nROUND 3: Isolated critique\n  Agent\u002FSession A'            Agent\u002FSession B'\n  critiques C                 critiques C\n  (can know A + C only)       (can know B + C only)\n         │                        │\n         └──────────┬─────────────┘\n                    ▼\nROUND 4: Reconciliation\n  Reconciler produces final-plan.md\n```\n\n## How to Execute\n\n### Step 0: Gather Context\n\n1. Get the **problem statement** from the user\n2. Identify the **relevant source files** — ask the user or search the codebase\n3. Create the output directory: `{project}\u002F.dev\u002Fproposals\u002F{issue-slug}\u002F`\n4. Save the problem statement as `problem-statement.md`\n5. Verify you have a real isolated-execution path for separate agents\u002Fsessions\n6. If you do not, stop and tell the user the skill cannot be executed faithfully in the current environment\n7. **Read all the source files** thoroughly before starting any proposals — the quality of the entire process depends on deep understanding of the code\n\n### Step 0.5: Prepare Isolated Execution\n\nBefore Proposal A starts, define the isolation method in writing inside the proposal directory:\n\n- What tool\u002Fsession mechanism is being used for Agent A\n- What tool\u002Fsession mechanism is being used for Agent B\n- How you are preventing shared context between them\n- How A-feedback and B-feedback will be isolated later\n\nSave this as `execution-method.md`.\n\nAccepted approaches:\n\n- Separate worker sessions managed by an external dispatcher\n- Separate `codex exec` or equivalent runs that do not share prior outputs in context\n- Separate human-run agent sessions where each agent only receives the allowed inputs\n\nRejected approaches:\n\n- \"Mental reset\" in the same conversation\n- \"Treat Proposal B as independent\" after Proposal A was already written in the same session\n- Any single-session workflow where both proposals are generated by the same live context\n\n### Step 1: Proposal A — The Surgical Perspective\n\nRead `agents\u002Fproposer-alpha.md` for the full mindset.\n\nInputs allowed for Agent A:\n- `problem-statement.md`\n- Relevant source files\n- Referenced skill files\n\nInputs forbidden for Agent A:\n- `proposal-B.md`\n- Any notes summarizing Proposal B\n- Any synthesis notes\n\nInvestigate the problem with this lens:\n- What is the most direct root cause?\n- What is the smallest, lowest-risk fix?\n- Trace the exact code path from input to broken output\n- Occam's razor — prefer simple explanations\n\nWrite the proposal following the format in `references\u002Fproposal-format.md`.\nSave as `proposal-A.md`.\n\n### Step 2: Proposal B — The Systemic Perspective\n\nRead `agents\u002Fproposer-beta.md` for the full mindset.\n\nProposal B must be executed in a different isolated session from Proposal A.\n\nInputs allowed for Agent B:\n- `problem-statement.md`\n- Relevant source files\n- Referenced skill files\n\nInputs forbidden for Agent B:\n- `proposal-A.md`\n- Any notes summarizing Proposal A\n- Any synthesis notes\n\n**CRITICAL: Approach the problem fresh.** Do NOT simply extend, react to, or refine Proposal A. Investigate from scratch with a different lens:\n- Is this a symptom of a deeper architectural issue?\n- What would prevent this entire class of bugs?\n- Where are the missing validations, contracts, or guarantees?\n- Are there other places where the same pattern breaks?\n\nWrite the proposal following the format in `references\u002Fproposal-format.md`.\nSave as `proposal-B.md`.\n\nThe value of this framework comes from genuinely different analytical perspectives. If B just agrees with A and adds minor points, the process has failed. B should investigate independently and may arrive at a completely different root cause.\n\n### Step 3: Proposal C — Synthesis\n\nRead `agents\u002Fsynthesizer.md` for the full role.\n\nProposal C may read both `proposal-A.md` and `proposal-B.md`, but it must not rewrite history by pretending A and B were isolated if they were not. If isolation was not achieved, abort instead of synthesizing.\n\nNow review both proposals:\n1. Analyze each proposal — do a strict review to see if each is sound or missing anything\n2. State specifically what you disagree with in each\n3. Identify where they agree (high-confidence areas) and where they diverge (needs resolution)\n4. Produce a new proposal that lists the analysis of both proposals first, then the best path forward\n5. Attribute key decisions: what came from A, what from B, what's new in C\n\nSave as `proposal-C.md`.\n\n### Step 4: Feedback — A and B Critique C\n\nRead `agents\u002Fcritic.md` for the feedback approach.\n\nNow run two isolated critique passes:\n\n- A-feedback session can read `proposal-A.md` and `proposal-C.md`, but not `proposal-B.md`\n- B-feedback session can read `proposal-B.md` and `proposal-C.md`, but not `proposal-A.md`\n\nDo not critique C from both perspectives inside one shared-context session if you can avoid it. The critique round should preserve the original separation.\n\n**From A's perspective** (surgical\u002Fminimal lens):\n- What did C lose from A's focused approach?\n- Did scope creep in? Are there unnecessary changes?\n- Does C introduce risks that A's simpler approach avoided?\n- Where is C's proposal stronger than A's?\n\n**From B's perspective** (systemic\u002Fholistic lens):\n- Did C take the quick fix over the right fix?\n- Are there still systemic vulnerabilities C ignores?\n- Did C incorporate the structural improvements from B?\n- Where is C's proposal stronger than B's?\n\nDo not save separate feedback files — carry the feedback directly into the next step.\n\n### Step 5: Final Plan — Reconciliation\n\nRead `agents\u002Freconciler.md` for the reconciliation approach.\n\nTake C's proposal and the feedback from both perspectives:\n1. Review each piece of feedback honestly\n2. Incorporate what's valid — if A or B caught a real issue, fix it\n3. Reject what's not applicable, with clear reasoning\n4. Produce the final implementation plan\n\nSave as `final-plan.md`.\n\nThe final plan must include:\n- Problem statement (refined through the full deliberation)\n- Root cause (final determination with confidence level)\n- Implementation plan (step-by-step, in execution order, with specific files and changes)\n- Feedback reconciliation (what was accepted\u002Frejected from A and B feedback, and why)\n- Risks and mitigations\n- Testing strategy\n\n### Step 6: Present to User\n\nPresent the final plan. Offer to:\n- Show the full deliberation trail\n- Explain specific decisions\n- Proceed to implementation\n- Re-run any round with a different angle\n\n## Isolation Validation Checklist\n\nBefore claiming the skill was followed correctly, confirm all of the following:\n\n- Proposal A and Proposal B were authored in separate agent contexts\n- Proposal B did not read Proposal A before completion\n- A-feedback did not read Proposal B\n- B-feedback did not read Proposal A\n- `execution-method.md` documents the isolation method used\n- If any item above is false, you did not execute this skill correctly\n\nIf you cannot satisfy this checklist, say so explicitly and stop.\n\n## Adapting to Problem Type\n\n| Problem Type | Proposal A Emphasis | Proposal B Emphasis |\n|-------------|-------------------|-------------------|\n| Bug fix | Trace exact data flow breakpoint | Find missing validation\u002Fcontract |\n| Feature | Minimal viable implementation | Full design with extensibility |\n| Architecture | Incremental migration path | Clean-slate ideal design |\n| Refactoring | Targeted surgical changes | Structural pattern improvement |\n\n## Output Directory\n\n```\n{project}\u002F.dev\u002Fproposals\u002F{issue-slug}\u002F\n├── problem-statement.md\n├── proposal-A.md\n├── proposal-B.md\n├── proposal-C.md\n└── final-plan.md\n```\n\n## Agent Roles Reference\n\nRead these files for full role instructions when executing each round:\n\n| Agent | File | Used In | Lens |\n|-------|------|---------|------|\n| Proposer Alpha | `agents\u002Fproposer-alpha.md` | Round 1 (A) | Surgical, minimal, trace-the-exact-bug |\n| Proposer Beta | `agents\u002Fproposer-beta.md` | Round 2 (B) | Systemic, holistic, prevent-the-bug-class |\n| Synthesizer | `agents\u002Fsynthesizer.md` | Round 3 (C) | Impartial reviewer, best-of-both |\n| Critic | `agents\u002Fcritic.md` | Round 4 | Pressure-test C from both perspectives |\n| Reconciler | `agents\u002Freconciler.md` | Round 5 | Make final calls, produce actionable plan |\n",{"name":5,"description":7},"main","50bb36677eced958128cea262c304bf9ceee4d4e","codex-skills\u002Fadversarial-proposal","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-proposal",{"tool":60,"command":61},"bunx","bunx skills add SirTheOracle\u002Fforge-toolkit --skill adversarial-proposal",{"tool":63,"command":64},"pnpm","pnpm dlx skills add SirTheOracle\u002Fforge-toolkit --skill adversarial-proposal","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-proposal\u002FSKILL.md",true,[68,74,78,82,86,90,94],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"agents\u002Fcritic.md","REFERENCE","参考文档",2068,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-proposal\u002Fagents\u002Fcritic.md",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"agents\u002Fopenai.yaml",321,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-proposal\u002Fagents\u002Fopenai.yaml",{"path":79,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":80,"sourceHtmlUrl":81},"agents\u002Fproposer-alpha.md",1620,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-proposal\u002Fagents\u002Fproposer-alpha.md",{"path":83,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":84,"sourceHtmlUrl":85},"agents\u002Fproposer-beta.md",2005,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-proposal\u002Fagents\u002Fproposer-beta.md",{"path":87,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":88,"sourceHtmlUrl":89},"agents\u002Freconciler.md",2543,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-proposal\u002Fagents\u002Freconciler.md",{"path":91,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":92,"sourceHtmlUrl":93},"agents\u002Fsynthesizer.md",3057,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-proposal\u002Fagents\u002Fsynthesizer.md",{"path":95,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fproposal-format.md",1760,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-proposal\u002Freferences\u002Fproposal-format.md",[99,126,146,166,187,208],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"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",[],[106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125],"forge","orchestrator","forge orchestrator","bridge","map","code","tasks","across","work","audit","multi-agent","logging","tmux","for","audit logging","workers","stage","with","multi","state",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"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",[],[133,40,106,134,135,136,137,138,139,140,141,39,111,142,114,35,143,144,145,32],"runner","forge fix runner","quick","pipeline","actionable","time","issues","qa","gating","verification","human","run","at",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"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",[],[106,153,154,155,156,157,158,159,160,161,162,163,164,165],"forge coder","coder","diffs","tests","execution","commit","changes","artifact","procedural","report","codebase","implementation","coding",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"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",[],[173,174,40,175,176,177,178,136,179,180,181,182,183,184,185,39,122,123,125,186],"reproducer","fix reproducer","deterministic","evidence","executor","diagnose","Reproducible","environment","trigger","branches","dev","single","repro","first",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":193,"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",[],[194,40,195,35,196,197,198,199,136,200,201,139,37,202,203,204,205,206,207,27],"fix plan reviewer","reviewer","plan reviewer","coverage","scope","regression","re","mode","diagnosis","defense","integrity","addresses","revise","attacks",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":214,"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",[],[40,215,154,177,198,136,200,216,217,155,218,158,195,35,33,219,27,220,179,181],"fix coder","failing","mechanical","files","path","test plan"]