[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FP4MRH3X1B1F0DAQC1854":3,"skill-same:01M70FP4MRH3X1B1F0DAQC1854":85},{"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},"01M70FP4MRH3X1B1F0DAQC1854","adversarial-lite",null,"Codex-native lightweight adversarial proposal workflow for low-risk, bounded planning tasks. Uses isolated Codex subagents for two independent proposal passes plus a high-capacity synthesis pass that writes final-plan.md under .dev\u002Fproposals\u002F{issue-slug}\u002F. Use only when the user explicitly asks for \"adversarial-lite\", \"lite proposal\", \"quick adversarial plan\", \"cheap\u002Ffast adversarial proposal\", or explicitly wants a lower-cost bounded planning pass. Do not trigger for generic \"investigate\", \"propose a fix\", \"come up with a plan\", or high-confidence planning requests; use adversarial-proposal instead for ambiguous, high-risk, multi-service, or broad changes.","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-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","proposals","risk","do","subagents","bounded","ambiguous","issue","native","plan","tasks","workflow","when","only","fix","up","proposal","quick","2026-11-10 10:12:30",false,"---\nname: adversarial-lite\ndescription: >\n  Codex-native lightweight adversarial proposal workflow for low-risk, bounded planning tasks.\n  Uses isolated Codex subagents for two independent proposal passes plus a high-capacity synthesis\n  pass that writes final-plan.md under .dev\u002Fproposals\u002F{issue-slug}\u002F. Use only when the user explicitly\n  asks for \"adversarial-lite\", \"lite proposal\", \"quick adversarial plan\", \"cheap\u002Ffast adversarial\n  proposal\", or explicitly wants a lower-cost bounded planning pass. Do not trigger for generic\n  \"investigate\", \"propose a fix\", \"come up with a plan\", or high-confidence planning requests;\n  use adversarial-proposal instead for ambiguous, high-risk, multi-service, or broad changes.\n---\n\n# Adversarial Lite\n\n## Purpose\n\nUse this skill to produce a fast, lower-cost `final-plan.md` for a small, low-risk bug, feature, refactor, or isolated architecture decision. The workflow preserves the key adversarial value: two isolated investigators analyze the same problem through different lenses, then a fresh synthesizer reads source first and produces the final plan.\n\nThis is intentionally weaker than `adversarial-proposal`: no A\u002FB critique round, no C reconciliation round, and shorter proposals. When in doubt, escalate to `adversarial-proposal`.\n\n## Codex Rules\n\n- Treat an explicit `adversarial-lite` request as permission to use Codex subagents for isolated analysis.\n- Do not use this skill for generic planning requests unless the user explicitly asks for lite\u002Fquick\u002Fcheap adversarial planning or the task is clearly low-risk and bounded.\n- Do not simulate independent proposals in one shared context. If isolated subagents or isolated external sessions are unavailable, stop and say the skill cannot be followed faithfully.\n- Prefer subagents returning proposal markdown to the lead; the lead writes artifacts locally. This avoids relying on forked-workspace file merges.\n- Do not ask subagents to modify production code. They are read-only investigators for this skill.\n\n## Native Model Policy\n\nPrefer this mapping when model overrides are available:\n\n| Pass | Preferred model | Rationale |\n|------|-----------------|-----------|\n| Proposer A | `gpt-5.4-mini` | Lower-cost structured investigation |\n| Proposer B | `gpt-5.4-mini` | Same as A |\n| Synthesizer C | `gpt-5.4` or the current high-capacity model | Source-first judgment and final decisions |\n\nIf model overrides are unavailable, omit them and continue with the current model. Tell the user that the adversarial structure still applies but the cost split may not.\n\n## Scope Gate\n\nEscalate to `adversarial-proposal` if any of these are true:\n\n- More than 7 source files need to be read, more than 5 files are likely to change, or source volume is roughly over 2000 lines.\n- The task touches auth, billing\u002Fpayment, tenant isolation, secrets, security boundaries, data deletion, database migrations, concurrency\u002Flocking, or destructive operations.\n- The change spans multiple services, repositories, or independently deployed systems.\n- Requirements are ambiguous or cannot be stated in 2-3 concrete sentences.\n- The problem is hybrid with unclear primary type, such as bug fix plus refactor or feature plus architecture decision.\n- The user asks for high-confidence analysis or an implementation strategy with broad blast radius.\n\nProceed only when the task is bounded, low-risk, single-service, and maps cleanly to one problem type.\n\n## Output\n\nWrite artifacts under:\n\n```text\n{project}\u002F.dev\u002Fproposals\u002F{slug}\u002F\n├── problem-statement.md\n├── execution-method.md\n├── proposal-A.md\n├── proposal-B.md\n└── final-plan.md\n```\n\nIf the output directory already exists, archive it to `{slug}-{YYYYMMDD-HHMMSS}\u002F` before writing a new run.\n\n## Workflow\n\n### Step 0: Setup\n\n1. Clarify or infer a concise problem statement.\n2. Discover relevant source files with `rg` \u002F `rg --files`; read enough code locally to set the source list and run the scope gate.\n3. Classify the task:\n\n| Type | Strategy A | Strategy B |\n|------|------------|------------|\n| `bug_fix` | Trace forward from the entry point | Trace backward from the symptom |\n| `feature` | Minimal viable change | Robust\u002Fextensible design |\n| `architecture` | Optimize for simplicity | Optimize for scalability |\n| `refactoring` | Incremental migration | Clean-break rewrite |\n\n4. Create `.dev\u002Fproposals\u002F{slug}\u002F`.\n5. Save `problem-statement.md` with the verbatim user request, source files, problem type, strategy pair, timestamp, git branch, and git HEAD.\n6. Save `execution-method.md` describing:\n   - Which subagents or isolated sessions will produce A, B, and C.\n   - How A\u002FB isolation is preserved.\n   - Whether model overrides are available.\n7. Read the needed references:\n   - `references\u002Fproposer-lite.md`\n   - `references\u002Fsynthesizer-lite.md`\n   - `references\u002Fproposal-format-lite.md`\n   - `references\u002Fworkflow.md` when you need prompt templates.\n\n### Step 1: Two Isolated Proposals\n\nSpawn A and B in parallel when possible. Use separate subagents with `fork_context: false` so each receives only the prompt you provide.\n\nPrompt each proposer with:\n\n- Problem statement.\n- Explicit source file list.\n- Its assigned strategy.\n- Full `references\u002Fproposer-lite.md`.\n- Full `references\u002Fproposal-format-lite.md`.\n- Isolation rule: do not read the other proposal, final plan, or proposal-directory artifacts.\n- Output instruction: return the complete proposal markdown in the final response; do not edit code.\n\nAfter both finish, the lead writes their returned markdown to `proposal-A.md` and `proposal-B.md`.\n\n### Step 2: Quality Gate\n\nEach proposal must pass:\n\n- All required proposal sections exist.\n- At least 3 concrete code references exist.\n- Evidence table has at least 3 rows.\n- Core finding has a confidence annotation, plus at least 2 other annotated claims.\n- All listed source files are mentioned or explicitly ruled irrelevant.\n- Alternatives Considered includes at least one rejected hypothesis and one rejected approach.\n- Risks and tests cite specific files, functions, endpoints, or commands.\n\nIf one proposal fails, request one revision from the same isolated perspective. If it still fails, continue only if the remaining material is enough for C, and mark the quality gap in C's prompt. If both fail, abort and preserve `problem-statement.md`.\n\n### Step 3: Convergence Check\n\nMark proposals `CONVERGED` only if all are true:\n\n- Same root cause or core finding, including same function\u002Ffile target and same mechanism.\n- Same general solution approach, including same files and same intervention point.\n- Shared evidence overlap: both cite at least one common code path supporting the same conclusion.\n- Neither proposal relied on the strategy escape hatch to abandon its lens.\n\nOtherwise mark `DIVERGED`.\n\nC always runs. Convergence changes C's mode; it never skips the source-first synthesis pass.\n\n### Step 4: Source-First Synthesis\n\nSpawn a fresh C subagent whenever possible. C must not share A or B's context.\n\nPrompt C with:\n\n- Source file list and instruction to read source before reading proposals.\n- Problem statement.\n- Paths to `proposal-A.md` and `proposal-B.md`.\n- Full `references\u002Fsynthesizer-lite.md`.\n- Mode: `CONVERGED` or `DIVERGED`.\n- Output instruction: return complete `final-plan.md` markdown.\n\nAfter C finishes, write its returned markdown to `final-plan.md`.\n\nIf C cannot be run in a fresh isolated context, stop and recommend `adversarial-proposal` unless the user explicitly accepts a reduced-confidence lead synthesis.\n\n### Step 5: Final Gate\n\nBefore presenting the result, check `final-plan.md` contains:\n\n- Header metadata with problem type, strategy pair, convergence state, and overall confidence.\n- Source file inventory.\n- Numbered implementation plan items with file\u002Ffunction targets.\n- Specific test files or commands.\n- Risk assessment tied to specific code or endpoints.\n- Open assumptions and low-confidence items.\n\nFor anything beyond the smallest fixes, recommend `proposal-reviewer` or `adversarial-implementation` before coding.\n\n## Error Handling\n\n| Failure | Recovery |\n|---------|----------|\n| Scope gate escalates | Stop lite; preserve `problem-statement.md`; recommend `adversarial-proposal`. |\n| No isolated subagent\u002Fsession support | Stop; do not simulate independence. |\n| One proposer fails | Retry once; if still failing, C reviews single proposal and notes reduced confidence. |\n| Both proposers fail | Abort and preserve setup artifacts. |\n| Quality gate fails after retry | Continue only if C has enough evidence; flag the gap in C prompt and final plan. |\n| Isolation contamination | Discard contaminated proposal; retry once from a fresh subagent. |\n| C fails | Retry once; if it fails again, present raw proposals and recommend full workflow. |\n| C says both proposals are wrong | Accept as valid; final plan must explain why, mark low confidence, and recommend full workflow. |\n| Source changes during run | Record git HEAD mismatch and ask C to note it in confidence assessment. |\n\n## References\n\n- `references\u002Fproposer-lite.md`: role prompt for A\u002FB proposers.\n- `references\u002Fsynthesizer-lite.md`: role prompt for C.\n- `references\u002Fproposal-format-lite.md`: required A\u002FB proposal shape.\n- `references\u002Fworkflow.md`: Codex prompt templates and orchestration details.\n","# Adversarial Lite\n\n## Purpose\n\nUse this skill to produce a fast, lower-cost `final-plan.md` for a small, low-risk bug, feature, refactor, or isolated architecture decision. The workflow preserves the key adversarial value: two isolated investigators analyze the same problem through different lenses, then a fresh synthesizer reads source first and produces the final plan.\n\nThis is intentionally weaker than `adversarial-proposal`: no A\u002FB critique round, no C reconciliation round, and shorter proposals. When in doubt, escalate to `adversarial-proposal`.\n\n## Codex Rules\n\n- Treat an explicit `adversarial-lite` request as permission to use Codex subagents for isolated analysis.\n- Do not use this skill for generic planning requests unless the user explicitly asks for lite\u002Fquick\u002Fcheap adversarial planning or the task is clearly low-risk and bounded.\n- Do not simulate independent proposals in one shared context. If isolated subagents or isolated external sessions are unavailable, stop and say the skill cannot be followed faithfully.\n- Prefer subagents returning proposal markdown to the lead; the lead writes artifacts locally. This avoids relying on forked-workspace file merges.\n- Do not ask subagents to modify production code. They are read-only investigators for this skill.\n\n## Native Model Policy\n\nPrefer this mapping when model overrides are available:\n\n| Pass | Preferred model | Rationale |\n|------|-----------------|-----------|\n| Proposer A | `gpt-5.4-mini` | Lower-cost structured investigation |\n| Proposer B | `gpt-5.4-mini` | Same as A |\n| Synthesizer C | `gpt-5.4` or the current high-capacity model | Source-first judgment and final decisions |\n\nIf model overrides are unavailable, omit them and continue with the current model. Tell the user that the adversarial structure still applies but the cost split may not.\n\n## Scope Gate\n\nEscalate to `adversarial-proposal` if any of these are true:\n\n- More than 7 source files need to be read, more than 5 files are likely to change, or source volume is roughly over 2000 lines.\n- The task touches auth, billing\u002Fpayment, tenant isolation, secrets, security boundaries, data deletion, database migrations, concurrency\u002Flocking, or destructive operations.\n- The change spans multiple services, repositories, or independently deployed systems.\n- Requirements are ambiguous or cannot be stated in 2-3 concrete sentences.\n- The problem is hybrid with unclear primary type, such as bug fix plus refactor or feature plus architecture decision.\n- The user asks for high-confidence analysis or an implementation strategy with broad blast radius.\n\nProceed only when the task is bounded, low-risk, single-service, and maps cleanly to one problem type.\n\n## Output\n\nWrite artifacts under:\n\n```text\n{project}\u002F.dev\u002Fproposals\u002F{slug}\u002F\n├── problem-statement.md\n├── execution-method.md\n├── proposal-A.md\n├── proposal-B.md\n└── final-plan.md\n```\n\nIf the output directory already exists, archive it to `{slug}-{YYYYMMDD-HHMMSS}\u002F` before writing a new run.\n\n## Workflow\n\n### Step 0: Setup\n\n1. Clarify or infer a concise problem statement.\n2. Discover relevant source files with `rg` \u002F `rg --files`; read enough code locally to set the source list and run the scope gate.\n3. Classify the task:\n\n| Type | Strategy A | Strategy B |\n|------|------------|------------|\n| `bug_fix` | Trace forward from the entry point | Trace backward from the symptom |\n| `feature` | Minimal viable change | Robust\u002Fextensible design |\n| `architecture` | Optimize for simplicity | Optimize for scalability |\n| `refactoring` | Incremental migration | Clean-break rewrite |\n\n4. Create `.dev\u002Fproposals\u002F{slug}\u002F`.\n5. Save `problem-statement.md` with the verbatim user request, source files, problem type, strategy pair, timestamp, git branch, and git HEAD.\n6. Save `execution-method.md` describing:\n   - Which subagents or isolated sessions will produce A, B, and C.\n   - How A\u002FB isolation is preserved.\n   - Whether model overrides are available.\n7. Read the needed references:\n   - `references\u002Fproposer-lite.md`\n   - `references\u002Fsynthesizer-lite.md`\n   - `references\u002Fproposal-format-lite.md`\n   - `references\u002Fworkflow.md` when you need prompt templates.\n\n### Step 1: Two Isolated Proposals\n\nSpawn A and B in parallel when possible. Use separate subagents with `fork_context: false` so each receives only the prompt you provide.\n\nPrompt each proposer with:\n\n- Problem statement.\n- Explicit source file list.\n- Its assigned strategy.\n- Full `references\u002Fproposer-lite.md`.\n- Full `references\u002Fproposal-format-lite.md`.\n- Isolation rule: do not read the other proposal, final plan, or proposal-directory artifacts.\n- Output instruction: return the complete proposal markdown in the final response; do not edit code.\n\nAfter both finish, the lead writes their returned markdown to `proposal-A.md` and `proposal-B.md`.\n\n### Step 2: Quality Gate\n\nEach proposal must pass:\n\n- All required proposal sections exist.\n- At least 3 concrete code references exist.\n- Evidence table has at least 3 rows.\n- Core finding has a confidence annotation, plus at least 2 other annotated claims.\n- All listed source files are mentioned or explicitly ruled irrelevant.\n- Alternatives Considered includes at least one rejected hypothesis and one rejected approach.\n- Risks and tests cite specific files, functions, endpoints, or commands.\n\nIf one proposal fails, request one revision from the same isolated perspective. If it still fails, continue only if the remaining material is enough for C, and mark the quality gap in C's prompt. If both fail, abort and preserve `problem-statement.md`.\n\n### Step 3: Convergence Check\n\nMark proposals `CONVERGED` only if all are true:\n\n- Same root cause or core finding, including same function\u002Ffile target and same mechanism.\n- Same general solution approach, including same files and same intervention point.\n- Shared evidence overlap: both cite at least one common code path supporting the same conclusion.\n- Neither proposal relied on the strategy escape hatch to abandon its lens.\n\nOtherwise mark `DIVERGED`.\n\nC always runs. Convergence changes C's mode; it never skips the source-first synthesis pass.\n\n### Step 4: Source-First Synthesis\n\nSpawn a fresh C subagent whenever possible. C must not share A or B's context.\n\nPrompt C with:\n\n- Source file list and instruction to read source before reading proposals.\n- Problem statement.\n- Paths to `proposal-A.md` and `proposal-B.md`.\n- Full `references\u002Fsynthesizer-lite.md`.\n- Mode: `CONVERGED` or `DIVERGED`.\n- Output instruction: return complete `final-plan.md` markdown.\n\nAfter C finishes, write its returned markdown to `final-plan.md`.\n\nIf C cannot be run in a fresh isolated context, stop and recommend `adversarial-proposal` unless the user explicitly accepts a reduced-confidence lead synthesis.\n\n### Step 5: Final Gate\n\nBefore presenting the result, check `final-plan.md` contains:\n\n- Header metadata with problem type, strategy pair, convergence state, and overall confidence.\n- Source file inventory.\n- Numbered implementation plan items with file\u002Ffunction targets.\n- Specific test files or commands.\n- Risk assessment tied to specific code or endpoints.\n- Open assumptions and low-confidence items.\n\nFor anything beyond the smallest fixes, recommend `proposal-reviewer` or `adversarial-implementation` before coding.\n\n## Error Handling\n\n| Failure | Recovery |\n|---------|----------|\n| Scope gate escalates | Stop lite; preserve `problem-statement.md`; recommend `adversarial-proposal`. |\n| No isolated subagent\u002Fsession support | Stop; do not simulate independence. |\n| One proposer fails | Retry once; if still failing, C reviews single proposal and notes reduced confidence. |\n| Both proposers fail | Abort and preserve setup artifacts. |\n| Quality gate fails after retry | Continue only if C has enough evidence; flag the gap in C prompt and final plan. |\n| Isolation contamination | Discard contaminated proposal; retry once from a fresh subagent. |\n| C fails | Retry once; if it fails again, present raw proposals and recommend full workflow. |\n| C says both proposals are wrong | Accept as valid; final plan must explain why, mark low confidence, and recommend full workflow. |\n| Source changes during run | Record git HEAD mismatch and ask C to note it in confidence assessment. |\n\n## References\n\n- `references\u002Fproposer-lite.md`: role prompt for A\u002FB proposers.\n- `references\u002Fsynthesizer-lite.md`: role prompt for C.\n- `references\u002Fproposal-format-lite.md`: required A\u002FB proposal shape.\n- `references\u002Fworkflow.md`: Codex prompt templates and orchestration details.\n",{"name":5,"description":7},"main","50bb36677eced958128cea262c304bf9ceee4d4e","codex-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\u002Fcodex-skills\u002Fadversarial-lite\u002FSKILL.md",true,[63,69,73,77,81],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"agents\u002Fopenai.yaml","REFERENCE","参考文档",230,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-lite\u002Fagents\u002Fopenai.yaml",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fproposal-format-lite.md",2011,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-lite\u002Freferences\u002Fproposal-format-lite.md",{"path":74,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fproposer-lite.md",2230,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-lite\u002Freferences\u002Fproposer-lite.md",{"path":78,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fsynthesizer-lite.md",2590,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-lite\u002Freferences\u002Fsynthesizer-lite.md",{"path":82,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fworkflow.md",2226,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fadversarial-lite\u002Freferences\u002Fworkflow.md",[86,112,131,151,172,195],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"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",[],[93,94,95,96,97,98,30,99,100,101,102,103,104,105,106,107,108,109,110,111],"forge","orchestrator","forge orchestrator","bridge","map","code","across","work","audit","multi-agent","logging","tmux","for","audit logging","workers","stage","with","multi","state",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"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",[],[119,34,93,120,37,121,122,123,124,125,126,32,98,127,100,29,128,129,130,27],"runner","forge fix runner","pipeline","actionable","time","issues","qa","gating","verification","human","run","at",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"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",[],[93,138,139,140,141,142,143,144,145,146,147,148,149,150],"forge coder","coder","diffs","tests","execution","commit","changes","artifact","procedural","report","codebase","implementation","coding",{"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":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",[],[158,159,34,160,161,162,163,121,164,165,166,167,168,169,170,32,108,109,111,171],"reproducer","fix reproducer","deterministic","evidence","executor","diagnose","Reproducible","environment","trigger","branches","dev","single","repro","first",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"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",[],[179,34,180,29,181,182,183,184,121,185,186,124,187,188,189,190,191,192,193,194],"fix plan reviewer","reviewer","plan reviewer","coverage","scope","regression","re","mode","review","diagnosis","defense","integrity","addresses","revise","attacks","as",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"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",[],[34,202,139,162,183,121,185,203,204,140,205,143,180,29,206,207,194,208,164,166],"fix coder","failing","mechanical","files","bug","path","test plan"]