[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FQ2QCTDEMFRNATFCPVB4M":3,"skill-same:01M70FQ2QCTDEMFRNATFCPVB4M":69},{"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},"01M70FQ2QCTDEMFRNATFCPVB4M","proposal-reviewer",null,"Independent review skill for critiquing a `final-plan.md` produced by the adversarial proposal framework. Performs a fresh pass over the problem statement, relevant code, and final plan to find incorrect root-cause assumptions, missing steps, hidden regressions, rollout gaps, and weak tests before implementation begins. Use this skill after `adversarial-proposal`, when the user wants an independent plan review, or when pointed at a proposals directory or `final-plan.md`.","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\u002Fproposal-reviewer\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"reviewer","proposal reviewer","proposal","use","tests","missing","problem statement","for","proposals","framework","at","directory","plan","fresh","review","code","rollout","when","problem","relevant","2026-11-10 10:12:30",false,"---\nname: proposal-reviewer\ndescription: >\n  Independent review skill for critiquing a `final-plan.md` produced by the adversarial proposal\n  framework. Performs a fresh pass over the problem statement, relevant code, and final plan to\n  find incorrect root-cause assumptions, missing steps, hidden regressions, rollout gaps, and weak\n  tests before implementation begins. Use this skill after `adversarial-proposal`, when the user\n  wants an independent plan review, or when pointed at a proposals directory or `final-plan.md`.\n---\n\n# Proposal Reviewer\n\n## Overview\n\nThis skill is the fresh review pass that happens after the adversarial proposal workflow. Two independent investigators (A and B) produced proposals, a synthesizer (C) combined them, A and B critiqued C, and C reconciled everything into a `final-plan.md`. This skill treats that result as untrusted until it has been checked against the actual codebase.\n\nYour job is to catch what that process missed. You are not anchored by any of the prior proposals. Read the problem statement, inspect the code directly, and evaluate the final plan on its own merits.\n\n## Input\n\nThis skill takes either a proposals directory or a direct path to `final-plan.md`:\n\n```text\n\u002Fproposal-reviewer .dev\u002Fproposals\u002F{slug}\n\u002Fproposal-reviewer .dev\u002Fproposals\u002F{slug}\u002Ffinal-plan.md\n```\n\nArguments passed: `$ARGUMENTS`\n\n## Path Resolution\n\nBefore reviewing anything:\n\n1. Resolve the target proposals directory before reviewing anything.\n2. If `$ARGUMENTS` is non-empty:\n   - If it points to `final-plan.md`, use that file's parent directory.\n   - Otherwise treat it as the proposals directory path.\n3. If `$ARGUMENTS` is empty:\n   - If the current working directory contains `final-plan.md`, use the current directory.\n   - Otherwise search downward for `**\u002Ffinal-plan.md`.\n   - If exactly one match exists, use that parent directory.\n   - If multiple matches exist, stop and ask the user to rerun the command with the specific proposals directory or `final-plan.md` path.\n   - If no match exists, stop and tell the user no proposal directory could be resolved.\n4. Confirm the resolved directory up front before writing the review.\n\n## When to Use\n\n- After the adversarial proposal framework produces a `final-plan.md`\n- When the user wants an independent check before implementing\n- When pointed at a `.dev\u002Fproposals\u002F{issue}\u002F` directory\n\n## What to Read\n\nRead the files in this order:\n\n1. `problem-statement.md` — understand the original problem first\n2. The relevant source files mentioned in the problem statement — understand the actual code\n3. `final-plan.md` — the plan you're reviewing\n4. `proposal-A.md`, `proposal-B.md`, `proposal-C.md` — the deliberation trail (to understand what was considered and rejected)\n\nReading the source code is critical. You cannot review a technical plan without understanding the code it proposes to change.\n\n## How to Review\n\n### 1. Validate the Root Cause\n\nThe most important thing to get right. Ask yourself:\n\n- Does the root cause identified in the final plan actually explain the observed symptom?\n- Is there evidence in the code that confirms this root cause?\n- Could there be a different root cause that explains the same symptom?\n- Did all three proposals agree on the root cause? If not, was the disagreement resolved convincingly?\n- Trace the data flow yourself — don't trust the plan's description of it. Verify it in the actual code.\n\n### 2. Audit the Implementation Steps\n\nFor each step in the implementation plan:\n\n- **Correctness**: Will this change actually do what the plan says it does?\n- **Completeness**: Are there files or functions that need to change but aren't listed?\n- **Ordering**: Do the steps need to happen in a specific order? Is that order correct?\n- **Side effects**: What else does this change affect that isn't mentioned?\n- **Rollback**: If this step fails, what happens to the steps already completed?\n\n### 3. Find What's Missing\n\nThings the adversarial process commonly misses:\n\n- **Edge cases**: What happens with empty inputs, null values, missing data, concurrent access?\n- **Error handling**: What happens when the fix encounters unexpected state?\n- **Configuration**: Are there environment-specific behaviors (dev vs prod, different configs)?\n- **Data migration**: Does existing data need to change, not just future data?\n- **Dependencies**: Are there upstream or downstream systems affected?\n- **Race conditions**: Can the timing of operations cause the fix to fail intermittently?\n- **Backwards compatibility**: Does this break any existing behavior that callers depend on?\n- **UI discoverability**: For wizard flows, multi-step forms, or repeated navigation patterns, verify that the primary action stays in the same expected navigation container on every step and is not buried below the fold inside page content.\n\n### 4. Evaluate the Testing Strategy\n\n- Does the testing strategy actually verify the fix works?\n- Are the test cases specific enough to catch a regression?\n- Are there test cases for the edge cases you identified?\n- Is manual verification described clearly enough that someone could follow it?\n- For wizard flows, do E2E tests assert the primary action inside the expected container rather than anywhere on the page?\n- If a test uses a page-wide selector such as `page.getByRole(\"button\", { name: \"Save\" })`, would it still pass if the button existed but was 2000px below the fold? If yes, flag a discoverability gap.\n- Audit conditional navigation renders. Patterns like `{step \u003C TOTAL && \u003CButton>}` often omit the last-step submit\u002Fsave action from the nav bar.\n- Prefer a scoped pattern such as `const wizardNav = page.getByTestId(\"wizard-nav\"); await expect(wizardNav.getByRole(\"button\", { name: \"Save\" })).toBeVisible();`. If the repo contains a reference spec that demonstrates this pattern, treat it as the standard.\n\n### 5. Check for Anchoring Bias\n\nThe adversarial process can still produce anchored results if A and B both made the same wrong assumption. Look for:\n\n- Assumptions that all three proposals shared without questioning\n- Alternative explanations that none of the proposals considered\n- Parts of the codebase that none of the proposals examined\n\n## Output Format\n\nSave your review as `review-codex.md` in the same proposals directory.\n\nStructure:\n\n```markdown\n# Independent Review of Final Plan\n\n## Review Summary\n[2-3 sentence verdict: Is this plan ready to implement, needs changes, or has fundamental issues?]\n\n## Confidence Level\n[High \u002F Medium \u002F Low — how confident are you in the final plan's correctness?]\n\n## Root Cause Validation\n[Is the root cause correct? Did you verify it in the code? Any alternative explanations?]\n\n## Implementation Audit\n\n### Step-by-Step Review\n[For each implementation step: correct\u002Fincorrect\u002Fincomplete, with specifics]\n\n### Missing Steps\n[Steps that should be added]\n\n### Ordering Issues\n[Any steps that are in the wrong order]\n\n## What Was Missed\n\n### Edge Cases\n[Edge cases not covered by the plan]\n\n### Risk Factors\n[Risks not identified in the plan's risk section]\n\n### Assumptions to Verify\n[Things the plan assumes that should be explicitly confirmed]\n\n## Testing Gaps\n[What the testing strategy doesn't cover]\n\n## Anchoring Check\n[Any shared assumptions across all proposals that should be questioned]\n\n## Recommendations\n[Specific, actionable changes to the final plan before implementing]\n```\n\n## Guidelines\n\n- Be specific. \"The plan has gaps\" is useless. \"Step 3 modifies `generate_prompt()` but doesn't account for shots where `character.dialogue` is an empty string vs null\" is useful.\n- Reference actual code — file paths, function names, line numbers when possible.\n- Don't repeat what the plan already says. Focus on what it doesn't say.\n- If the plan is solid, say so. Don't manufacture criticism for the sake of it.\n- Prioritize your findings — lead with what would cause the fix to fail, not style preferences.\n- If you find a fundamental issue with the root cause, flag it immediately and clearly. Everything else is secondary if the root cause is wrong.\n- For UI reviews, distinguish \"element exists in the DOM\" from \"primary action is discoverable to a real user without scrolling or hunting.\" Treat that as a correctness issue, not polish.\n","# Proposal Reviewer\n\n## Overview\n\nThis skill is the fresh review pass that happens after the adversarial proposal workflow. Two independent investigators (A and B) produced proposals, a synthesizer (C) combined them, A and B critiqued C, and C reconciled everything into a `final-plan.md`. This skill treats that result as untrusted until it has been checked against the actual codebase.\n\nYour job is to catch what that process missed. You are not anchored by any of the prior proposals. Read the problem statement, inspect the code directly, and evaluate the final plan on its own merits.\n\n## Input\n\nThis skill takes either a proposals directory or a direct path to `final-plan.md`:\n\n```text\n\u002Fproposal-reviewer .dev\u002Fproposals\u002F{slug}\n\u002Fproposal-reviewer .dev\u002Fproposals\u002F{slug}\u002Ffinal-plan.md\n```\n\nArguments passed: `$ARGUMENTS`\n\n## Path Resolution\n\nBefore reviewing anything:\n\n1. Resolve the target proposals directory before reviewing anything.\n2. If `$ARGUMENTS` is non-empty:\n   - If it points to `final-plan.md`, use that file's parent directory.\n   - Otherwise treat it as the proposals directory path.\n3. If `$ARGUMENTS` is empty:\n   - If the current working directory contains `final-plan.md`, use the current directory.\n   - Otherwise search downward for `**\u002Ffinal-plan.md`.\n   - If exactly one match exists, use that parent directory.\n   - If multiple matches exist, stop and ask the user to rerun the command with the specific proposals directory or `final-plan.md` path.\n   - If no match exists, stop and tell the user no proposal directory could be resolved.\n4. Confirm the resolved directory up front before writing the review.\n\n## When to Use\n\n- After the adversarial proposal framework produces a `final-plan.md`\n- When the user wants an independent check before implementing\n- When pointed at a `.dev\u002Fproposals\u002F{issue}\u002F` directory\n\n## What to Read\n\nRead the files in this order:\n\n1. `problem-statement.md` — understand the original problem first\n2. The relevant source files mentioned in the problem statement — understand the actual code\n3. `final-plan.md` — the plan you're reviewing\n4. `proposal-A.md`, `proposal-B.md`, `proposal-C.md` — the deliberation trail (to understand what was considered and rejected)\n\nReading the source code is critical. You cannot review a technical plan without understanding the code it proposes to change.\n\n## How to Review\n\n### 1. Validate the Root Cause\n\nThe most important thing to get right. Ask yourself:\n\n- Does the root cause identified in the final plan actually explain the observed symptom?\n- Is there evidence in the code that confirms this root cause?\n- Could there be a different root cause that explains the same symptom?\n- Did all three proposals agree on the root cause? If not, was the disagreement resolved convincingly?\n- Trace the data flow yourself — don't trust the plan's description of it. Verify it in the actual code.\n\n### 2. Audit the Implementation Steps\n\nFor each step in the implementation plan:\n\n- **Correctness**: Will this change actually do what the plan says it does?\n- **Completeness**: Are there files or functions that need to change but aren't listed?\n- **Ordering**: Do the steps need to happen in a specific order? Is that order correct?\n- **Side effects**: What else does this change affect that isn't mentioned?\n- **Rollback**: If this step fails, what happens to the steps already completed?\n\n### 3. Find What's Missing\n\nThings the adversarial process commonly misses:\n\n- **Edge cases**: What happens with empty inputs, null values, missing data, concurrent access?\n- **Error handling**: What happens when the fix encounters unexpected state?\n- **Configuration**: Are there environment-specific behaviors (dev vs prod, different configs)?\n- **Data migration**: Does existing data need to change, not just future data?\n- **Dependencies**: Are there upstream or downstream systems affected?\n- **Race conditions**: Can the timing of operations cause the fix to fail intermittently?\n- **Backwards compatibility**: Does this break any existing behavior that callers depend on?\n- **UI discoverability**: For wizard flows, multi-step forms, or repeated navigation patterns, verify that the primary action stays in the same expected navigation container on every step and is not buried below the fold inside page content.\n\n### 4. Evaluate the Testing Strategy\n\n- Does the testing strategy actually verify the fix works?\n- Are the test cases specific enough to catch a regression?\n- Are there test cases for the edge cases you identified?\n- Is manual verification described clearly enough that someone could follow it?\n- For wizard flows, do E2E tests assert the primary action inside the expected container rather than anywhere on the page?\n- If a test uses a page-wide selector such as `page.getByRole(\"button\", { name: \"Save\" })`, would it still pass if the button existed but was 2000px below the fold? If yes, flag a discoverability gap.\n- Audit conditional navigation renders. Patterns like `{step \u003C TOTAL && \u003CButton>}` often omit the last-step submit\u002Fsave action from the nav bar.\n- Prefer a scoped pattern such as `const wizardNav = page.getByTestId(\"wizard-nav\"); await expect(wizardNav.getByRole(\"button\", { name: \"Save\" })).toBeVisible();`. If the repo contains a reference spec that demonstrates this pattern, treat it as the standard.\n\n### 5. Check for Anchoring Bias\n\nThe adversarial process can still produce anchored results if A and B both made the same wrong assumption. Look for:\n\n- Assumptions that all three proposals shared without questioning\n- Alternative explanations that none of the proposals considered\n- Parts of the codebase that none of the proposals examined\n\n## Output Format\n\nSave your review as `review-codex.md` in the same proposals directory.\n\nStructure:\n\n```markdown\n# Independent Review of Final Plan\n\n## Review Summary\n[2-3 sentence verdict: Is this plan ready to implement, needs changes, or has fundamental issues?]\n\n## Confidence Level\n[High \u002F Medium \u002F Low — how confident are you in the final plan's correctness?]\n\n## Root Cause Validation\n[Is the root cause correct? Did you verify it in the code? Any alternative explanations?]\n\n## Implementation Audit\n\n### Step-by-Step Review\n[For each implementation step: correct\u002Fincorrect\u002Fincomplete, with specifics]\n\n### Missing Steps\n[Steps that should be added]\n\n### Ordering Issues\n[Any steps that are in the wrong order]\n\n## What Was Missed\n\n### Edge Cases\n[Edge cases not covered by the plan]\n\n### Risk Factors\n[Risks not identified in the plan's risk section]\n\n### Assumptions to Verify\n[Things the plan assumes that should be explicitly confirmed]\n\n## Testing Gaps\n[What the testing strategy doesn't cover]\n\n## Anchoring Check\n[Any shared assumptions across all proposals that should be questioned]\n\n## Recommendations\n[Specific, actionable changes to the final plan before implementing]\n```\n\n## Guidelines\n\n- Be specific. \"The plan has gaps\" is useless. \"Step 3 modifies `generate_prompt()` but doesn't account for shots where `character.dialogue` is an empty string vs null\" is useful.\n- Reference actual code — file paths, function names, line numbers when possible.\n- Don't repeat what the plan already says. Focus on what it doesn't say.\n- If the plan is solid, say so. Don't manufacture criticism for the sake of it.\n- Prioritize your findings — lead with what would cause the fix to fail, not style preferences.\n- If you find a fundamental issue with the root cause, flag it immediately and clearly. Everything else is secondary if the root cause is wrong.\n- For UI reviews, distinguish \"element exists in the DOM\" from \"primary action is discoverable to a real user without scrolling or hunting.\" Treat that as a correctness issue, not polish.\n",{"name":5,"description":7},"main","50bb36677eced958128cea262c304bf9ceee4d4e","codex-skills\u002Fproposal-reviewer","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 proposal-reviewer",{"tool":55,"command":56},"bunx","bunx skills add SirTheOracle\u002Fforge-toolkit --skill proposal-reviewer",{"tool":58,"command":59},"pnpm","pnpm dlx skills add SirTheOracle\u002Fforge-toolkit --skill proposal-reviewer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fproposal-reviewer\u002FSKILL.md",true,[63],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"agents\u002Fopenai.yaml","REFERENCE","参考文档",294,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fcodex-skills\u002Fproposal-reviewer\u002Fagents\u002Fopenai.yaml",[70,95,116,135,156,177],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"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",[],[77,78,79,80,81,33,82,83,84,85,86,87,88,25,89,90,91,92,93,94],"forge","orchestrator","forge orchestrator","bridge","map","tasks","across","work","audit","multi-agent","logging","tmux","audit logging","workers","stage","with","multi","state",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"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",[],[102,103,77,104,105,106,107,108,109,110,111,35,33,112,84,30,113,114,28,115],"runner","fix","forge fix runner","quick","pipeline","actionable","time","issues","qa","gating","verification","human","run","issue",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"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",[],[77,123,124,125,22,126,127,128,129,130,131,132,133,134],"forge coder","coder","diffs","execution","commit","changes","artifact","procedural","report","codebase","implementation","coding",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"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",[],[142,143,103,144,145,146,147,106,148,149,150,151,152,153,154,35,91,92,94,155],"reproducer","fix reproducer","deterministic","evidence","executor","diagnose","Reproducible","environment","trigger","branches","dev","single","repro","first",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"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",[],[163,103,18,30,164,165,166,167,106,168,169,109,32,170,171,172,173,174,175,176],"fix plan reviewer","plan reviewer","coverage","scope","regression","re","mode","diagnosis","defense","integrity","addresses","revise","attacks","as",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"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",[],[103,184,124,146,166,106,168,185,186,125,187,127,18,30,188,189,176,190,148,150],"fix coder","failing","mechanical","files","bug","path","test plan"]