[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FQTXCAAWS5A4HBKZHXMK8":3,"skill-same:01M70FQTXCAAWS5A4HBKZHXMK8":81},{"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":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":13,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":62},"01M70FQTXCAAWS5A4HBKZHXMK8","adversarial-lite",null,"Lightweight adversarial proposal for low-risk, bounded tasks. 2-round version of adversarial-proposal: Sonnet investigators + Opus synthesizer. No feedback loop. Use for small features, clear bugs, focused refactoring. For high-risk, ambiguous, or multi-service problems, use adversarial-proposal instead. Trigger on: \"lite proposal\", \"quick proposal\", \"adversarial lite\", or when the lead confirms a problem is low-risk and bounded. Do NOT trigger on generic \"investigate\" or \"propose\" requests — those should use the full adversarial-proposal.","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\u002Fskills\u002Fadversarial-lite\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"adversarial lite","adversarial","generic","risk","feedback","do","bounded","opus","sonnet","full","lead","ambiguous","features","refactoring","tasks","when","loop","problem","proposal","quick","2026-11-10 10:12:30",false,"---\nname: adversarial-lite\ndescription: >\n  Lightweight adversarial proposal for low-risk, bounded tasks.\n  2-round version of adversarial-proposal: Sonnet investigators + Opus synthesizer.\n  No feedback loop. Use for small features, clear bugs, focused refactoring.\n  For high-risk, ambiguous, or multi-service problems, use adversarial-proposal instead.\n  Trigger on: \"lite proposal\", \"quick proposal\", \"adversarial lite\", or when the lead\n  confirms a problem is low-risk and bounded. Do NOT trigger on generic \"investigate\"\n  or \"propose\" requests — those should use the full adversarial-proposal.\n---\n\n# Adversarial Lite\n\nFast first-pass adversarial planning for low-risk, bounded tasks. Two Sonnet investigators examine the problem independently using different strategies, then one Opus synthesizer produces the final plan in a single pass.\n\n**This is NOT the full adversarial-proposal.** It trades the feedback loop (Rounds 3-4) for speed and cost. Use `adversarial-proposal` when you need high-confidence analysis with multiple rounds of critique.\n\n## When to Use\n\n- Bug fixes with clear symptoms and bounded scope\n- Small features (changes likely touch 1-5 files)\n- Focused refactoring within a single module\n- Quick architecture decisions for isolated components\n- Problem can be clearly stated in 2-3 sentences\n\n## When NOT to Use\n\nUse `adversarial-proposal` instead for:\n\n- **High-risk domains**: auth, billing\u002Fpayment, data deletion, database migrations, security boundaries, tenant isolation, secrets handling, concurrency\u002Flocking\n- **Multi-service changes** or cross-service coordination\n- **Ambiguous requirements** that need exploration before planning\n- **Hybrid problems** (bug + refactor, feature + architecture decision) with unclear primary classification\n- Changes likely to touch **more than 5 files** or read **more than 7 source files**\n- When the user explicitly requests **high-confidence analysis**\n\nWhen in doubt, use the full version. The cost of a wrong lite plan exceeds the savings.\n\n## Architecture\n\n```\nRound 0 (Lead):   Setup + complexity gate\nRound 1 (Sonnet): A and B investigate in parallel\nRound 2 (Opus):   C synthesizes → final-plan.md\n```\n\nThree agents, two rounds, one final deliverable. C **always runs** — convergence changes C's mode (verify vs synthesize), never skips it.\n\n## Output\n\n```\n{project}\u002F.dev\u002Fproposals\u002F{slug}\u002F\n├── problem-statement.md   (Round 0)\n├── proposal-A.md          (Round 1, Sonnet)\n├── proposal-B.md          (Round 1, Sonnet)\n└── final-plan.md          (Round 2, Opus)\n```\n\n---\n\n## Round 0: Setup\n\n### Step 1: Detect Problem Type\n\nClassify the problem from the user's description:\n\n| Type | Signal |\n|------|--------|\n| `bug_fix` | Something is broken, wrong behavior, error, regression |\n| `feature` | New capability, missing functionality, enhancement |\n| `architecture` | Structural change, performance, scaling concern |\n| `refactoring` | Code quality, technical debt, reorganization |\n\n### Step 2: Select Strategy Pair\n\n| Problem Type | Strategy A | Strategy B |\n|-------------|-----------|-----------|\n| Bug fix | Trace FORWARD from entry point through the code path | Trace BACKWARD from the symptom to find where things went wrong |\n| Feature | MINIMAL viable approach — smallest change that delivers | ROBUST\u002Fextensible approach — design for future needs and edge cases |\n| Architecture | Optimize for SIMPLICITY — fewest moving parts | Optimize for SCALABILITY — handle growth, performance, flexibility |\n| Refactoring | INCREMENTAL migration — stages, old and new coexist | CLEAN-BREAK rewrite — replace coherently in one change |\n\n### Step 3: Complexity Gate\n\nRun this multi-factor check. **Any single ESCALATE factor triggers recommendation to use the full version.**\n\n**ESCALATE if ANY of:**\n- Source files to read > 7 OR estimated total source lines > 2000\n- Problem touches high-risk domains: auth, billing\u002Fpayment, data deletion, database migrations, security boundaries, tenant isolation, secrets handling, concurrency\u002Flocking\n- Problem spans multiple services or requires cross-service coordination\n- Requirements are ambiguous — cannot state the problem in 2-3 clear sentences\n- Problem is hybrid (e.g., \"bug fix + refactor\") with unclear primary classification\n- User explicitly requests high-confidence analysis\n\n**PROCEED if ALL of:**\n- Problem is bounded and can be clearly stated\n- Source files to read \u003C= 7 AND changes likely touch \u003C= 5 files\n- No high-risk domain involvement\n- Single service, single concern\n- Problem type maps cleanly to one category\n\n**On escalation:** Stop the lite workflow. Preserve `problem-statement.md` and source discovery so the user doesn't restart from scratch. Print:\n\n```\nThis problem exceeds adversarial-lite scope:\n- {reason(s) for escalation}\n\nRecommend using adversarial-proposal for full 4-round analysis.\nProblem statement preserved at: {output_dir}\u002Fproblem-statement.md\n```\n\n### Step 4: Create Output Directory\n\n```bash\noutput_dir=\"{project}\u002F.dev\u002Fproposals\u002F{slug}\"\n```\n\nIf directory exists with artifacts from a previous run, archive it:\n```bash\nmv \"{output_dir}\" \"{output_dir}-$(date +%Y%m%d-%H%M%S)\"\n```\n\nCreate fresh directory:\n```bash\nmkdir -p \"{output_dir}\"\n```\n\n### Step 5: Save Problem Statement\n\nRecord the problem statement and git HEAD hash:\n\n```markdown\n# Problem Statement\n\n{user's problem description, verbatim}\n\n## Source Files\n{list of source files to investigate}\n\n## Metadata\n- **Type:** {problem_type}\n- **Strategy pair:** {Strategy A} vs {Strategy B}\n- **Git HEAD:** {output of git rev-parse HEAD}\n- **Created:** {timestamp}\n```\n\n### Step 6: Read Agent Role Files\n\nRead the following files to embed their full content in agent prompts:\n- `~\u002F.claude\u002Fskills\u002Fadversarial-lite\u002Fagents\u002Fproposer-lite.md`\n- `~\u002F.claude\u002Fskills\u002Fadversarial-lite\u002Fagents\u002Fsynthesizer-lite.md`\n- `~\u002F.claude\u002Fskills\u002Fadversarial-lite\u002Freferences\u002Fproposal-format-lite.md`\n\n---\n\n## Round 1: Independent Investigation\n\nSpawn both proposers **in the same message** for true parallel execution. See `references\u002Fworkflow.md` for the exact prompt templates.\n\n```\nAgent({\n  description: \"Proposer A: {problem_type} investigation\",\n  model: \"sonnet\",\n  prompt: \"{problem + sources + proposer-lite role + format-lite + Strategy A + isolation rule}\",\n  run_in_background: true\n})\n\nAgent({\n  description: \"Proposer B: {problem_type} investigation\",\n  model: \"sonnet\",\n  prompt: \"{problem + sources + proposer-lite role + format-lite + Strategy B + isolation rule}\",\n  run_in_background: true\n})\n```\n\n**Model:** `model: \"sonnet\"` — investigation is the high-volume, lower-judgment work. If the runtime rejects the model parameter, agents inherit the parent model. Warn the user that cost savings may not apply.\n\n**Wait** for both agents to complete (background notification). **Timeout:** 5 minutes per proposer.\n\n**The wait is watchdogged.** A background notification that never arrives is indistinguishable from work in progress, so:\n\n1. **Poll for output.** Verify bytes on disk at `{output_dir}\u002Fproposal-A.md` and `{output_dir}\u002Fproposal-B.md` — the `.md`, never the `.tmp`. A notification you did not receive is not evidence of a proposer still working.\n2. The 5-minute budget above is measured against an **absent file**, not against silence.\n3. **Ping once** via SendMessage when the budget expires — a ping can wake a wedged proposer. **No reply does not mean dead:** a pinged proposer can surface minutes later, so never conclude a silent one is gone.\n4. **Any replacement writes to a distinct path** (`proposal-A.md` → `proposal-A-r2.md`) so a late-waking original cannot clobber it.\n\n### Quality Gate\n\nAfter both proposals arrive, read each and run checks.\n\n**Structural checks (pass\u002Ffail):**\n- All 7 required sections present (Problem Statement, Investigation Findings, Core Analysis, Solution Plan, Alternatives Considered, Risk Assessment, Testing Strategy)\n- At least 3 specific code references (file:function or file:line)\n- Confidence annotations on core finding and at least 2 other claims\n- Evidence table present with at least 3 rows\n- Proposal between 100-350 lines\n\n**Semantic checks (lead judgment):**\n- Evidence table: claims backed by specific file:line references, not vague assertions?\n- Source coverage: are all listed source files referenced in the investigation?\n- Alternatives Considered: at least 1 substantive rejected hypothesis with evidence-based reasoning?\n- Risk specificity: risks cite specific affected code\u002Fendpoints?\n\n**On failure:** Re-run the failed proposer with feedback identifying what's missing. Allow **one retry**. If retry also fails, proceed to Round 2 with available material and flag the quality gap to C.\n\n### Convergence Check\n\nAfter quality gate passes, evaluate convergence. **All three conditions must be met:**\n\n1. **Same root cause \u002F core finding:** Both proposals cite the same function(s) or file location(s) as the root cause AND explain the same mechanism\n2. **Same general approach:** Both propose changes to the same files with the same strategy (not just \"add validation\" — must agree on where and how)\n3. **Evidence overlap:** Both proposals reference at least one common code path or function with specific file:line citations supporting the same conclusion\n\n**NOT convergence (false positive guards):**\n- Same root cause label but different mechanisms (\"both say validation, but A validates at request level, B validates at DB level\")\n- Same approach but different confidence levels on core finding (A says `[HIGH]`, B says `[LOW]`)\n- Both proposers invoked the strategy escape hatch — convergence from abandoning strategies is not meaningful\n- Same diagnosis but different implementation targets (different files or functions)\n\nRecord the result: CONVERGED or DIVERGED.\n\n---\n\n## Round 2: Synthesis\n\n**C always runs.** Convergence changes C's mode, not whether C is spawned.\n\nSee `references\u002Fworkflow.md` for the exact prompt templates for each mode.\n\n**If CONVERGED:**\n```\nAgent({\n  description: \"Verify and consolidate converged proposals\",\n  model: \"opus\",\n  prompt: \"{source files to read FIRST + problem + proposals + synthesizer-lite role, Mode: CONVERGED}\"\n})\n```\n\n**If DIVERGED:**\n```\nAgent({\n  description: \"Synthesize divergent proposals into final plan\",\n  model: \"opus\",\n  prompt: \"{source files to read FIRST + problem + proposals + synthesizer-lite role, Mode: DIVERGED}\"\n})\n```\n\n**Model:** `model: \"opus\"` — synthesis is the high-judgment work that justifies the cost.\n\n**Timeout:** 8 minutes.\n\n**The wait is watchdogged**, same four rules:\n\n1. **Poll for output.** Verify bytes on disk at `{output_dir}\u002Ffinal-plan.md` — the `.md`, never the `.tmp`.\n2. The 8-minute budget above is measured against that absent file.\n3. **Ping once** via SendMessage when it expires. **No reply does not mean dead:** a wedged synthesizer can wake minutes after the ping, so keep waiting rather than declaring it gone.\n4. **A re-spawned C writes to a distinct path** (`final-plan-r2.md`) so a late-waking original cannot clobber it.\n\n---\n\n## Completion\n\nAfter `final-plan.md` is written:\n\n1. **Clean up:** Remove any `.tmp` files in the output directory\n2. **Present:** Read and present `final-plan.md` to the user\n3. **Recommend next step:** For anything beyond the smallest fixes, suggest:\n   - `adversarial-verify` for validation\n   - `adversarial-implementation` for producing exact code diffs\n   - Or direct implementation if the plan is straightforward\n\n---\n\n## Error Handling\n\n| Failure | Recovery |\n|---------|----------|\n| One proposer fails | Retry once, the retry writing to a **distinct path** (`proposal-A-r2.md`). If still fails, C reviews single proposal with blind-spot check. Note reduced confidence. |\n| Both proposers fail | Abort. Report to user. Preserve problem-statement.md. |\n| Proposal fails quality gate after retry | Proceed to Round 2 with available proposals. Flag gap to C. |\n| Isolation violation (A references B) | Discard contaminated proposal. Re-run once to a **distinct path** (`proposal-A-r2.md`). If repeats, single-proposal path. |\n| C fails | Re-spawn once to a **distinct path** (`final-plan-r2.md`). If second failure, present raw proposals. Recommend full version. |\n| C produces partial file | .tmp exists but .md does not. Remove .tmp, re-spawn C to a **distinct path** (`final-plan-r2.md`) — the original may still wake and write. |\n| C concludes both proposals wrong | Valid outcome. C writes final-plan.md with own approach, LOW confidence, recommends full version. |\n| Complexity gate escalates | Stop lite. Preserve problem-statement.md. Print escalation reason. |\n| Output directory collision | Archive existing as {slug}-{timestamp}\u002F before starting. |\n| Model parameter rejected | Fall back to default model. Warn user about cost. Proceed — structural benefits still apply. |\n| Timeout (5 min proposer, 8 min C) | Treat as failure for that round. Apply recovery. |\n\n---\n\n## Model Configuration\n\n| Agent | Model | Rationale |\n|-------|-------|-----------|\n| Proposer A | `model: \"sonnet\"` | Investigation is structured, directive — Sonnet follows the format well at lower cost |\n| Proposer B | `model: \"sonnet\"` | Same as A |\n| Synthesizer C | `model: \"opus\"` | Synthesis requires judgment, bias awareness, resolving disagreements — worth the Opus cost |\n\nIf the `model` parameter is not available in the runtime, all agents inherit the parent model. The skill still provides value through independent investigation and anti-anchoring. Print a warning about cost.\n","# Adversarial Lite\n\nFast first-pass adversarial planning for low-risk, bounded tasks. Two Sonnet investigators examine the problem independently using different strategies, then one Opus synthesizer produces the final plan in a single pass.\n\n**This is NOT the full adversarial-proposal.** It trades the feedback loop (Rounds 3-4) for speed and cost. Use `adversarial-proposal` when you need high-confidence analysis with multiple rounds of critique.\n\n## When to Use\n\n- Bug fixes with clear symptoms and bounded scope\n- Small features (changes likely touch 1-5 files)\n- Focused refactoring within a single module\n- Quick architecture decisions for isolated components\n- Problem can be clearly stated in 2-3 sentences\n\n## When NOT to Use\n\nUse `adversarial-proposal` instead for:\n\n- **High-risk domains**: auth, billing\u002Fpayment, data deletion, database migrations, security boundaries, tenant isolation, secrets handling, concurrency\u002Flocking\n- **Multi-service changes** or cross-service coordination\n- **Ambiguous requirements** that need exploration before planning\n- **Hybrid problems** (bug + refactor, feature + architecture decision) with unclear primary classification\n- Changes likely to touch **more than 5 files** or read **more than 7 source files**\n- When the user explicitly requests **high-confidence analysis**\n\nWhen in doubt, use the full version. The cost of a wrong lite plan exceeds the savings.\n\n## Architecture\n\n```\nRound 0 (Lead):   Setup + complexity gate\nRound 1 (Sonnet): A and B investigate in parallel\nRound 2 (Opus):   C synthesizes → final-plan.md\n```\n\nThree agents, two rounds, one final deliverable. C **always runs** — convergence changes C's mode (verify vs synthesize), never skips it.\n\n## Output\n\n```\n{project}\u002F.dev\u002Fproposals\u002F{slug}\u002F\n├── problem-statement.md   (Round 0)\n├── proposal-A.md          (Round 1, Sonnet)\n├── proposal-B.md          (Round 1, Sonnet)\n└── final-plan.md          (Round 2, Opus)\n```\n\n---\n\n## Round 0: Setup\n\n### Step 1: Detect Problem Type\n\nClassify the problem from the user's description:\n\n| Type | Signal |\n|------|--------|\n| `bug_fix` | Something is broken, wrong behavior, error, regression |\n| `feature` | New capability, missing functionality, enhancement |\n| `architecture` | Structural change, performance, scaling concern |\n| `refactoring` | Code quality, technical debt, reorganization |\n\n### Step 2: Select Strategy Pair\n\n| Problem Type | Strategy A | Strategy B |\n|-------------|-----------|-----------|\n| Bug fix | Trace FORWARD from entry point through the code path | Trace BACKWARD from the symptom to find where things went wrong |\n| Feature | MINIMAL viable approach — smallest change that delivers | ROBUST\u002Fextensible approach — design for future needs and edge cases |\n| Architecture | Optimize for SIMPLICITY — fewest moving parts | Optimize for SCALABILITY — handle growth, performance, flexibility |\n| Refactoring | INCREMENTAL migration — stages, old and new coexist | CLEAN-BREAK rewrite — replace coherently in one change |\n\n### Step 3: Complexity Gate\n\nRun this multi-factor check. **Any single ESCALATE factor triggers recommendation to use the full version.**\n\n**ESCALATE if ANY of:**\n- Source files to read > 7 OR estimated total source lines > 2000\n- Problem touches high-risk domains: auth, billing\u002Fpayment, data deletion, database migrations, security boundaries, tenant isolation, secrets handling, concurrency\u002Flocking\n- Problem spans multiple services or requires cross-service coordination\n- Requirements are ambiguous — cannot state the problem in 2-3 clear sentences\n- Problem is hybrid (e.g., \"bug fix + refactor\") with unclear primary classification\n- User explicitly requests high-confidence analysis\n\n**PROCEED if ALL of:**\n- Problem is bounded and can be clearly stated\n- Source files to read \u003C= 7 AND changes likely touch \u003C= 5 files\n- No high-risk domain involvement\n- Single service, single concern\n- Problem type maps cleanly to one category\n\n**On escalation:** Stop the lite workflow. Preserve `problem-statement.md` and source discovery so the user doesn't restart from scratch. Print:\n\n```\nThis problem exceeds adversarial-lite scope:\n- {reason(s) for escalation}\n\nRecommend using adversarial-proposal for full 4-round analysis.\nProblem statement preserved at: {output_dir}\u002Fproblem-statement.md\n```\n\n### Step 4: Create Output Directory\n\n```bash\noutput_dir=\"{project}\u002F.dev\u002Fproposals\u002F{slug}\"\n```\n\nIf directory exists with artifacts from a previous run, archive it:\n```bash\nmv \"{output_dir}\" \"{output_dir}-$(date +%Y%m%d-%H%M%S)\"\n```\n\nCreate fresh directory:\n```bash\nmkdir -p \"{output_dir}\"\n```\n\n### Step 5: Save Problem Statement\n\nRecord the problem statement and git HEAD hash:\n\n```markdown\n# Problem Statement\n\n{user's problem description, verbatim}\n\n## Source Files\n{list of source files to investigate}\n\n## Metadata\n- **Type:** {problem_type}\n- **Strategy pair:** {Strategy A} vs {Strategy B}\n- **Git HEAD:** {output of git rev-parse HEAD}\n- **Created:** {timestamp}\n```\n\n### Step 6: Read Agent Role Files\n\nRead the following files to embed their full content in agent prompts:\n- `~\u002F.claude\u002Fskills\u002Fadversarial-lite\u002Fagents\u002Fproposer-lite.md`\n- `~\u002F.claude\u002Fskills\u002Fadversarial-lite\u002Fagents\u002Fsynthesizer-lite.md`\n- `~\u002F.claude\u002Fskills\u002Fadversarial-lite\u002Freferences\u002Fproposal-format-lite.md`\n\n---\n\n## Round 1: Independent Investigation\n\nSpawn both proposers **in the same message** for true parallel execution. See `references\u002Fworkflow.md` for the exact prompt templates.\n\n```\nAgent({\n  description: \"Proposer A: {problem_type} investigation\",\n  model: \"sonnet\",\n  prompt: \"{problem + sources + proposer-lite role + format-lite + Strategy A + isolation rule}\",\n  run_in_background: true\n})\n\nAgent({\n  description: \"Proposer B: {problem_type} investigation\",\n  model: \"sonnet\",\n  prompt: \"{problem + sources + proposer-lite role + format-lite + Strategy B + isolation rule}\",\n  run_in_background: true\n})\n```\n\n**Model:** `model: \"sonnet\"` — investigation is the high-volume, lower-judgment work. If the runtime rejects the model parameter, agents inherit the parent model. Warn the user that cost savings may not apply.\n\n**Wait** for both agents to complete (background notification). **Timeout:** 5 minutes per proposer.\n\n**The wait is watchdogged.** A background notification that never arrives is indistinguishable from work in progress, so:\n\n1. **Poll for output.** Verify bytes on disk at `{output_dir}\u002Fproposal-A.md` and `{output_dir}\u002Fproposal-B.md` — the `.md`, never the `.tmp`. A notification you did not receive is not evidence of a proposer still working.\n2. The 5-minute budget above is measured against an **absent file**, not against silence.\n3. **Ping once** via SendMessage when the budget expires — a ping can wake a wedged proposer. **No reply does not mean dead:** a pinged proposer can surface minutes later, so never conclude a silent one is gone.\n4. **Any replacement writes to a distinct path** (`proposal-A.md` → `proposal-A-r2.md`) so a late-waking original cannot clobber it.\n\n### Quality Gate\n\nAfter both proposals arrive, read each and run checks.\n\n**Structural checks (pass\u002Ffail):**\n- All 7 required sections present (Problem Statement, Investigation Findings, Core Analysis, Solution Plan, Alternatives Considered, Risk Assessment, Testing Strategy)\n- At least 3 specific code references (file:function or file:line)\n- Confidence annotations on core finding and at least 2 other claims\n- Evidence table present with at least 3 rows\n- Proposal between 100-350 lines\n\n**Semantic checks (lead judgment):**\n- Evidence table: claims backed by specific file:line references, not vague assertions?\n- Source coverage: are all listed source files referenced in the investigation?\n- Alternatives Considered: at least 1 substantive rejected hypothesis with evidence-based reasoning?\n- Risk specificity: risks cite specific affected code\u002Fendpoints?\n\n**On failure:** Re-run the failed proposer with feedback identifying what's missing. Allow **one retry**. If retry also fails, proceed to Round 2 with available material and flag the quality gap to C.\n\n### Convergence Check\n\nAfter quality gate passes, evaluate convergence. **All three conditions must be met:**\n\n1. **Same root cause \u002F core finding:** Both proposals cite the same function(s) or file location(s) as the root cause AND explain the same mechanism\n2. **Same general approach:** Both propose changes to the same files with the same strategy (not just \"add validation\" — must agree on where and how)\n3. **Evidence overlap:** Both proposals reference at least one common code path or function with specific file:line citations supporting the same conclusion\n\n**NOT convergence (false positive guards):**\n- Same root cause label but different mechanisms (\"both say validation, but A validates at request level, B validates at DB level\")\n- Same approach but different confidence levels on core finding (A says `[HIGH]`, B says `[LOW]`)\n- Both proposers invoked the strategy escape hatch — convergence from abandoning strategies is not meaningful\n- Same diagnosis but different implementation targets (different files or functions)\n\nRecord the result: CONVERGED or DIVERGED.\n\n---\n\n## Round 2: Synthesis\n\n**C always runs.** Convergence changes C's mode, not whether C is spawned.\n\nSee `references\u002Fworkflow.md` for the exact prompt templates for each mode.\n\n**If CONVERGED:**\n```\nAgent({\n  description: \"Verify and consolidate converged proposals\",\n  model: \"opus\",\n  prompt: \"{source files to read FIRST + problem + proposals + synthesizer-lite role, Mode: CONVERGED}\"\n})\n```\n\n**If DIVERGED:**\n```\nAgent({\n  description: \"Synthesize divergent proposals into final plan\",\n  model: \"opus\",\n  prompt: \"{source files to read FIRST + problem + proposals + synthesizer-lite role, Mode: DIVERGED}\"\n})\n```\n\n**Model:** `model: \"opus\"` — synthesis is the high-judgment work that justifies the cost.\n\n**Timeout:** 8 minutes.\n\n**The wait is watchdogged**, same four rules:\n\n1. **Poll for output.** Verify bytes on disk at `{output_dir}\u002Ffinal-plan.md` — the `.md`, never the `.tmp`.\n2. The 8-minute budget above is measured against that absent file.\n3. **Ping once** via SendMessage when it expires. **No reply does not mean dead:** a wedged synthesizer can wake minutes after the ping, so keep waiting rather than declaring it gone.\n4. **A re-spawned C writes to a distinct path** (`final-plan-r2.md`) so a late-waking original cannot clobber it.\n\n---\n\n## Completion\n\nAfter `final-plan.md` is written:\n\n1. **Clean up:** Remove any `.tmp` files in the output directory\n2. **Present:** Read and present `final-plan.md` to the user\n3. **Recommend next step:** For anything beyond the smallest fixes, suggest:\n   - `adversarial-verify` for validation\n   - `adversarial-implementation` for producing exact code diffs\n   - Or direct implementation if the plan is straightforward\n\n---\n\n## Error Handling\n\n| Failure | Recovery |\n|---------|----------|\n| One proposer fails | Retry once, the retry writing to a **distinct path** (`proposal-A-r2.md`). If still fails, C reviews single proposal with blind-spot check. Note reduced confidence. |\n| Both proposers fail | Abort. Report to user. Preserve problem-statement.md. |\n| Proposal fails quality gate after retry | Proceed to Round 2 with available proposals. Flag gap to C. |\n| Isolation violation (A references B) | Discard contaminated proposal. Re-run once to a **distinct path** (`proposal-A-r2.md`). If repeats, single-proposal path. |\n| C fails | Re-spawn once to a **distinct path** (`final-plan-r2.md`). If second failure, present raw proposals. Recommend full version. |\n| C produces partial file | .tmp exists but .md does not. Remove .tmp, re-spawn C to a **distinct path** (`final-plan-r2.md`) — the original may still wake and write. |\n| C concludes both proposals wrong | Valid outcome. C writes final-plan.md with own approach, LOW confidence, recommends full version. |\n| Complexity gate escalates | Stop lite. Preserve problem-statement.md. Print escalation reason. |\n| Output directory collision | Archive existing as {slug}-{timestamp}\u002F before starting. |\n| Model parameter rejected | Fall back to default model. Warn user about cost. Proceed — structural benefits still apply. |\n| Timeout (5 min proposer, 8 min C) | Treat as failure for that round. Apply recovery. |\n\n---\n\n## Model Configuration\n\n| Agent | Model | Rationale |\n|-------|-------|-----------|\n| Proposer A | `model: \"sonnet\"` | Investigation is structured, directive — Sonnet follows the format well at lower cost |\n| Proposer B | `model: \"sonnet\"` | Same as A |\n| Synthesizer C | `model: \"opus\"` | Synthesis requires judgment, bias awareness, resolving disagreements — worth the Opus cost |\n\nIf the `model` parameter is not available in the runtime, all agents inherit the parent model. The skill still provides value through independent investigation and anti-anchoring. Print a warning about cost.\n",{"name":5,"description":7},"main","50bb36677eced958128cea262c304bf9ceee4d4e","skills\u002Fadversarial-lite","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit","https:\u002F\u002Fgithub.com\u002FSirTheOracle","2026-10-20 00:50:37",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add SirTheOracle\u002Fforge-toolkit --skill adversarial-lite",{"tool":55,"command":56},"bunx","bunx skills add SirTheOracle\u002Fforge-toolkit --skill adversarial-lite",{"tool":58,"command":59},"pnpm","pnpm dlx skills add SirTheOracle\u002Fforge-toolkit --skill adversarial-lite","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fadversarial-lite\u002FSKILL.md",true,[63,69,73,77],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"agents\u002Fproposer-lite.md","REFERENCE","参考文档",4555,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fadversarial-lite\u002Fagents\u002Fproposer-lite.md",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"agents\u002Fsynthesizer-lite.md",8176,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fadversarial-lite\u002Fagents\u002Fsynthesizer-lite.md",{"path":74,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fproposal-format-lite.md",4885,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fadversarial-lite\u002Freferences\u002Fproposal-format-lite.md",{"path":78,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fworkflow.md",15256,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fadversarial-lite\u002Freferences\u002Fworkflow.md",[82,108,130,150,171,194],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":38},"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",[],[89,90,91,92,93,94,32,95,96,97,98,99,100,101,102,103,104,105,106,107],"forge","orchestrator","forge orchestrator","bridge","map","code","across","work","audit","multi-agent","logging","tmux","for","audit logging","workers","stage","with","multi","state",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":38},"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",[],[115,116,89,117,37,118,119,120,121,122,123,33,94,124,96,125,126,127,128,129],"runner","fix","forge fix runner","pipeline","actionable","time","issues","qa","gating","verification","plan","human","run","at","issue",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":38},"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",[],[89,137,138,139,140,141,142,143,144,145,146,147,148,149],"forge coder","coder","diffs","tests","execution","commit","changes","artifact","procedural","report","codebase","implementation","coding",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":38},"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",[],[157,158,116,159,160,161,162,118,163,164,165,166,167,168,169,33,104,105,107,170],"reproducer","fix reproducer","deterministic","evidence","executor","diagnose","Reproducible","environment","trigger","branches","dev","single","repro","first",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":38},"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",[],[178,116,179,125,180,181,182,183,118,184,185,121,186,187,188,189,190,191,192,193],"fix plan reviewer","reviewer","plan reviewer","coverage","scope","regression","re","mode","review","diagnosis","defense","integrity","addresses","revise","attacks","as",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":38},"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",[],[116,201,138,161,182,118,184,202,203,139,204,142,179,125,205,206,193,207,163,165],"fix coder","failing","mechanical","files","bug","path","test plan"]