[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70FRN8THYBT2DJVX99XQ3CM":3,"skill-same:01M70FRN8THYBT2DJVX99XQ3CM":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},"01M70FRN8THYBT2DJVX99XQ3CM","fix-plan-reviewer",null,"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.","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\u002Ffix-plan-reviewer\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"fix","reviewer","plan","plan reviewer","fix plan reviewer","as","attacks","revise","addresses","integrity","defense","diagnosis","review","issues","mode","re","pipeline","regression","scope","coverage","2026-11-10 10:12:30",false,"---\nname: fix-plan-reviewer\ndescription: >\n  Single-agent adversarial reviewer for fix plans. Reads diagnosis.md and\n  fix-plan.md, verifies the plan actually addresses the diagnosed cause,\n  attacks the plan from multiple angles (cause coverage, defense adequacy,\n  scope correctness, regression risk, rollback integrity, test plan integrity,\n  risk honesty), and produces fix-review.md with severity-rated issues. Does\n  NOT propose fixes for the issues — that is the revise mode of\n  adversarial-fix-plan. Does NOT re-investigate the diagnosis. Trigger as the\n  review stage of a fix-pipeline, after adversarial-fix-plan has produced\n  fix-plan.md.\n---\n\n# Fix Plan Reviewer\n\n## Overview\n\nA single procedural reviewer that attacks fix-plan.md and produces fix-review.md. The reviewer is itself the adversarial pressure on the plan; this skill does not run Agent Teams or multiple rounds.\n\n**Worker routing.** The orchestrator may run this skill locally (Claude lead) or dispatch to a Codex worker — same pattern as `proposal-reviewer` in the build pipeline. Codex is the recommended default because the fix-plan was produced by Claude (in `adversarial-fix-plan`); an external Codex review catches Claude-side blind spots. Local Claude execution is the fallback when Codex is unavailable.\n\nThe orchestrator uses fix-review.md's severity counts to decide:\n\n- **CRITICAL > 0** → escalate to user (fix-plan has a fundamental problem; possibly the diagnosis is wrong)\n- **BLOCKING > 0** → re-dispatch adversarial-fix-plan in revise mode\n- **Only ADVISORY** → advance to fix-coding (or revise at user discretion)\n\n## When to Use\n\n- After `adversarial-fix-plan` produces `fix-plan.md` and before `fix-coding`\n- The reviewer runs once per fix-plan version. After a revise pass produces fix-plan.md (v2), the reviewer is NOT automatically re-run unless the orchestrator decides another review pass is warranted.\n\n**Expected runtime**: ~5–10 min single-agent. The skill is bounded by the size of fix-plan.md, the number of files it touches (each must be read per Hard Rule 3), and the depth of the diagnosis. Larger fix plans with many files or PARTIALLY CONVERGED diagnoses run longer.\n\n## When NOT to Use\n\n- **No fix-plan.md exists.** Hard refusal — see Hard Rules.\n- **fix-plan.md has BLOCKED status** (INSUFFICIENT EVIDENCE diagnosis). The plan is already blocked; reviewing it adds no value. Orchestrator should escalate, not review.\n- **Re-reviewing the same fix-plan.md without changes.** Wasted work.\n- **Build-pipeline reviews.** Use `proposal-reviewer` for those.\n\n## Hard Rules\n\n1. **Attack the plan, do not propose fixes.** Issues describe *what is wrong* and *why*, not *how to fix*. Proposing fixes belongs to the revise mode of adversarial-fix-plan.\n2. **Verify against the diagnosis, not just the plan.** The reviewer must read diagnosis.md and answer: \"would the proposed changes actually make the diagnosed cause stop happening?\" Trusting the plan's self-claim is forbidden.\n3. **Read the actual code that would be touched.** When the plan says it will modify file X, the reviewer reads file X and confirms its structure matches the plan's assumptions. Trusting the plan's description of the code is forbidden.\n4. **Always produce fix-review.md.** Empty issue sections are acceptable. Silent failure is forbidden.\n5. **Severity ratings are conservative.** When uncertain between two levels, choose the higher (more severe). Under-rating ships bad fixes; over-rating adds a revision pass.\n6. **Do not re-investigate.** This skill does not challenge the diagnosis itself. It checks whether the plan addresses what the diagnosis says. If the plan misinterprets the diagnosis, that is a CRITICAL issue. If the diagnosis itself seems wrong, that is OUT OF SCOPE — flag the concern in fix-review.md but do not re-diagnose.\n7. **Single agent, no sub-agents.** This skill does not spawn teammates and does not run adversarial rounds.\n8. **No code changes.** This skill produces a review document. It does not modify source code or fix-plan.md.\n\n## Required Reads\n\nBefore writing the review:\n\n1. `{output_dir}\u002Ffix-plan.md` — the plan being reviewed\n2. `{output_dir}\u002Fdiagnosis.md` — the diagnosis the plan must address\n3. `{output_dir}\u002Fproblem-statement.md` — original problem context\n4. `{output_dir}\u002Frepro.md` — if present, repro context\n5. `~\u002F.claude\u002Fskills\u002Ffix-plan-reviewer\u002Freferences\u002Ffix-review-format.md` — output template (authoritative)\n\nOptional:\n\n- `.claude\u002Fforge-project.yml` (fallback: `~\u002F.claude\u002Fforge-project.yml`) — project config. Useful when reviewing test plans for protected pages (auth config) or when env-specific service settings affect the rollback assessment. Skip if not present.\n\nIf `--original-slug` is provided, also read for context (read-only):\n\n7. `.dev\u002Fproposals\u002F{original-slug}\u002Ffinal-plan.md`\n8. `.dev\u002Fproposals\u002F{original-slug}\u002Fimplementation.md`\n9. `.dev\u002Fproposals\u002F{original-slug}\u002Fcoder-report.md`\n\nThe reviewer ALSO reads the actual source files the plan proposes to touch. This is mandatory — see Hard Rule 3.\n\n## Inputs\n\nRequired:\n\n- `--output-dir` — path to the fix directory. fix-plan.md lives here; fix-review.md will be written here.\n- `--env prod | dev` — affects severity weighting. Prod issues weight higher (rollback rigor, deployment risk, regression blast radius).\n\nOptional:\n\n- `--original-slug` — slug of the original build pipeline. Enables read-only context access.\n\n## Phase 0: Config + Inputs\n\n1. Read `.claude\u002Fforge-project.yml` if present (optional — see Required Reads). Skip without error if absent.\n2. Read `fix-plan.md` from `--output-dir`\n3. **Empty-args short-circuit.** If `--output-dir` is missing, `--env` is missing, or `fix-plan.md` does not exist, stop:\n   ```\n   FIX-PLAN-REVIEWER ERROR: Missing required input. Provide --output-dir,\n   --env (one of `prod` | `dev`), and ensure fix-plan.md exists.\n   ```\n4. **Status check.** If fix-plan.md has `Status: BLOCKED`, stop:\n   ```\n   FIX-PLAN-REVIEWER ERROR: fix-plan.md has BLOCKED status. Reviewing a\n   blocked plan adds no value. The orchestrator should escalate.\n   ```\n5. Read `diagnosis.md`, `problem-statement.md`, `repro.md` (if present)\n6. If `--original-slug` is provided, confirm `.dev\u002Fproposals\u002F{original-slug}\u002F` exists; read its artifacts\n\n## Phase 1: Attack Surface Mapping\n\nParse fix-plan.md and extract:\n\n- The cited root cause (from Diagnosis Reference)\n- The fix approach (Surgical \u002F Robust \u002F synthesized position)\n- Each file the plan proposes to modify, add, or remove\n- Each defense the plan adds (with stated justification)\n- Each test the plan calls for\n- The rollback plan\n- The risk assessment claims\n\nThis is the structured target list for the review attack.\n\n## Phase 2: Read the Actual Code\n\nFor each file the plan proposes to touch:\n\n- Read the file\n- Confirm the file exists at the stated path\n- Confirm the structure matches the plan's assumptions (function names, class layouts, dependencies)\n- Note discrepancies between what the plan describes and what's actually there\n\nThis phase is mandatory and is the basis for many CRITICAL findings. A plan that misdescribes the code it touches will produce a fix that doesn't compile or doesn't behave as intended.\n\n## Phase 3: Attack Angles\n\nThe reviewer runs each of these attacks against the plan. Each attack is a question the reviewer must explicitly answer in fix-review.md, even if the answer is \"no issues found.\"\n\n### 3A. Cause Coverage\n\n**Question: Would the proposed changes actually make the diagnosed cause stop happening?**\n\n- Map each diagnosed cause element to the plan changes that address it\n- Identify any cause element with no corresponding change\n- Identify any change that doesn't serve any cause element (potential scope creep — see 3C)\n\nA miss here is typically CRITICAL. The fix doesn't fix.\n\n### 3B. Defense Adequacy\n\n**Question: For PARTIALLY CONVERGED diagnoses, did the plan address the alternative causes? For all diagnoses, are the defenses (if any) defending against the right things?**\n\n- Check Defense section against the diagnosis's alternative causes (if any)\n- Check each defense against its stated justification — is the justification grounded in real fragility, or cargo-culted?\n- Check whether obvious adjacent fragilities (related code paths that could fail similarly) are addressed or explicitly ignored with rationale\n\nMisses here are typically BLOCKING.\n\n### 3C. Scope Correctness\n\n**Question: Is the fix appropriately scoped — neither too narrow nor too broad?**\n\nTwo directions:\n\n- **Too narrow**: are there obvious adjacent fragilities the fix should address?\n- **Too broad**: are there changes that don't serve the diagnosis (unrelated refactors, scope creep)?\n\nToo narrow is typically BLOCKING. Too broad is typically ADVISORY unless the over-broad change introduces real risk, in which case BLOCKING.\n\n### 3D. Regression Risk\n\n**Question: What could break that the test plan doesn't cover?**\n\n- For each file touched, identify dependents (other files that import or call into it)\n- Identify dependents whose tests would NOT exercise the changes\n- Identify behaviors of the changed code that the change might inadvertently alter\n\nMisses here are typically BLOCKING for prod, ADVISORY for dev.\n\n### 3E. Rollback Integrity\n\n**Question: Will the rollback plan actually work?**\n\nEspecially important for prod. The reviewer asks:\n\n- Are there schema or data changes that can't be cleanly reverted?\n- Are there cascading effects (one revert requires another)?\n- Does \"just revert the commit\" actually restore working state, or does it leave intermediate state?\n- For prod: are deployment considerations realistic? Monitoring named?\n\nMisses here are typically BLOCKING for prod, ADVISORY for dev.\n\n### 3F. Test Plan Integrity\n\n**Question: Do the proposed tests actually prove the fix works AND the regressions don't happen?**\n\nThe killer question: **would the proposed tests have caught the original bug?**\n\n- A test that passes before and after the fix because it doesn't exercise the failing path is worthless\n- Verify the test plan exercises the actual cause, not adjacent code\n- Verify regression tests actually exercise the dependents identified in 3D\n\n**When repro.md is absent**, the killer question is harder to answer because the concrete shape of the original bug is less explicit. Fall back to: \"do the proposed tests exercise the diagnosed cause path identified in `diagnosis.md`'s evidence chain?\" This is weaker than the repro-driven check but still actionable — a test that doesn't traverse the cited file:line locations from the evidence chain almost certainly wouldn't catch the bug.\n\nMisses here are typically BLOCKING.\n\n### 3G. Risk Assessment Honesty\n\n**Question: Did the planner downplay risks or miss any?**\n\n- Cross-reference the plan's stated risks against the reviewer's attack findings — are findings from 3A-3F that should have appeared in the plan's Risk Assessment actually there?\n- Check for honesty about blast radius\n- Check for honesty about deployment risk (prod only)\n\nMisses here are typically ADVISORY unless they materially change the risk calculus, in which case BLOCKING.\n\n### 3H. Plan-vs-Diagnosis Interpretation\n\n**Question: Does the plan correctly interpret what the diagnosis says?**\n\n- Does the cited root cause in fix-plan match what diagnosis.md actually committed to?\n- For PARTIALLY CONVERGED: does the plan acknowledge the alternatives the diagnosis flagged?\n\nMisses here are typically CRITICAL — the plan is solving a different problem than the diagnosis identified.\n\n### 3I. Diagnosis-Doubt Flag (out of scope)\n\n**Question (always answered, even if empty): In the course of reviewing the plan, did I see any signal that the diagnosis itself is wrong (not just the plan's interpretation of it)?**\n\nThis angle is checked on every run, parallel to 3A–3H. The reviewer must explicitly answer in fix-review.md's \"Diagnosis Concerns\" section — even when the answer is \"no concerns observed.\" Passive noticing is not enough; an empty section means the reviewer affirmatively saw no signal, not that the reviewer forgot to look.\n\nIf concerns ARE observed, the reviewer flags them in the \"Diagnosis Concerns\" section with severity ADVISORY (because the reviewer is not a re-investigator). The orchestrator decides whether to re-run investigate.\n\nThis is NOT a CRITICAL issue against the plan — the plan can only be as good as the diagnosis. It's an out-of-band signal to the orchestrator. Concrete plan-vs-diagnosis discrepancies still surface as CRITICAL via 3H; 3I is for reviewer-side suspicion that the upstream diagnosis itself missed the mark.\n\n## Phase 4: Severity Assignment\n\nEach finding from Phase 3 gets a severity:\n\n| Severity | Meaning | Orchestrator Action |\n|---|---|---|\n| **CRITICAL** | Fix doesn't address the diagnosis, plan misinterprets diagnosis, or plan has fatal flaw | Escalate to user; possibly re-run investigate |\n| **BLOCKING** | Fix has problems that must be addressed before fix-coding | Re-dispatch adversarial-fix-plan in revise mode |\n| **ADVISORY** | Fix is fundamentally sound but has improvable aspects | Advance to fix-coding (or revise at user discretion) |\n\nSeverity guidance:\n\n- Cause coverage misses (3A): CRITICAL if any cause element is unaddressed; BLOCKING if addressed but inadequately\n- Plan-vs-diagnosis misinterpretation (3H): CRITICAL\n- Test plan that doesn't exercise the failing path (3F): BLOCKING\n- Rollback that won't work for prod (3E with --env prod): BLOCKING\n- Defense missing for stated PARTIALLY CONVERGED alternative (3B): BLOCKING\n- Scope too narrow with named adjacent fragility (3C): BLOCKING\n- Scope too broad without risk (3C): ADVISORY\n- Risk assessment downplay without material consequence (3G): ADVISORY\n\nWhen uncertain between two severities, choose the higher.\n\n## Phase 5: Write fix-review.md\n\nWrite `{output_dir}\u002Ffix-review.md` following the structure in `references\u002Ffix-review-format.md` (authoritative). The template below is a preview for orientation; if it diverges from the reference file, the reference file wins.\n\n```markdown\n# Fix Plan Review — {slug}\n\n## Verdict\n{APPROVE | REVISE | REJECT}\n- APPROVE: no CRITICAL or BLOCKING issues (ADVISORY-only, or no issues at all). fix-plan can advance to fix-coding.\n- REVISE: BLOCKING issues present (and no CRITICAL). fix-plan needs revision via revise mode.\n- REJECT: any CRITICAL issue present. fix-pipeline should escalate to user.\n\n## Environment\n{prod | dev}\n\n## Critical Issues\n{Issues with severity CRITICAL. Empty section if none.}\n\nFor each:\n- **Issue**: brief title\n- **Target Section**: which section of fix-plan.md the issue applies to\n- **Finding**: what is wrong\n- **Why It Matters**: why this is a problem, with reference to diagnosis or code\n- **Required Resolution**: what the plan needs to address (NOT how to fix it)\n\n## Blocking Issues\n{Issues with severity BLOCKING. Same per-issue structure. Empty section if none.}\n\n## Advisory Issues\n{Issues with severity ADVISORY. Same per-issue structure. Empty section if none.}\n\n## Diagnosis Concerns\n{Out-of-scope concerns about the diagnosis itself. Empty if none. Severity always ADVISORY at this layer.}\n\n## Strengths\n{What the plan got right. This helps the reviser preserve good parts during revise mode.\n Brief — no need to praise everything; just call out what specifically should be preserved.}\n\n## Attack Angle Summary\n{One line per attack angle (3A-3H), confirming it was checked and the result.\n Required for transparency — the reviewer must show its work.}\n\n| Angle | Result |\n|---|---|\n| 3A Cause Coverage | \u003Cissues found \u002F clean> |\n| 3B Defense Adequacy | \u003Cissues found \u002F clean \u002F N\u002FA for CONVERGED diagnoses> |\n| 3C Scope Correctness | \u003Cissues found \u002F clean> |\n| 3D Regression Risk | \u003Cissues found \u002F clean> |\n| 3E Rollback Integrity | \u003Cissues found \u002F clean> |\n| 3F Test Plan Integrity | \u003Cissues found \u002F clean> |\n| 3G Risk Assessment Honesty | \u003Cissues found \u002F clean> |\n| 3H Plan-vs-Diagnosis Interpretation | \u003Cissues found \u002F clean> |\n\n## Confidence + Blocking Items\nCONFIDENCE: HIGH | MEDIUM | LOW\nBLOCKING_ITEMS: N\n\n(BLOCKING_ITEMS = count of CRITICAL + BLOCKING issues. ADVISORY does not count toward blocking.)\n```\n\nThe Attack Angle Summary table is mandatory — it forces the reviewer to confirm each angle was checked, even when no issues were found. This prevents silent skipping.\n\n## Phase 6: Output Quality Gate (Self-Check Before FORGE_DONE)\n\nBefore signaling completion, verify the written `fix-review.md` on disk:\n\n1. The file exists at `{output_dir}\u002Ffix-review.md` and is non-empty\n2. All required sections are present, in this order:\n   - Verdict (with one of APPROVE \u002F REVISE \u002F REJECT)\n   - Environment\n   - Critical Issues\n   - Blocking Issues\n   - Advisory Issues\n   - Diagnosis Concerns (may be empty, but the section header must exist with the explicit answer to 3I)\n   - Strengths\n   - Attack Angle Summary\n   - Confidence + Blocking Items (last two lines exactly)\n3. The Attack Angle Summary table contains a row for each of 3A, 3B, 3C, 3D, 3E, 3F, 3G, 3H — no row may be missing or marked \"skipped\"\n4. The Verdict matches the severity counts:\n   - APPROVE iff no CRITICAL and no BLOCKING\n   - REVISE iff no CRITICAL but at least one BLOCKING\n   - REJECT iff at least one CRITICAL\n5. The last two lines are exactly `CONFIDENCE: {HIGH|MEDIUM|LOW}` and `BLOCKING_ITEMS: {N}`, where N = count of CRITICAL + BLOCKING\n6. The reviewer touches `fix-review.md` last so its mtime reflects review completion (lets the downstream revise-mode mtime check work correctly)\n\nIf any check fails, fix the file and re-verify. The Attack Angle Summary table specifically is a load-bearing transparency mechanism — a missing row means the reviewer skipped an attack angle silently, which violates Hard Rule 4 in spirit even if the file exists.\n\nOnce the self-check passes, signal FORGE_DONE.\n\n## Error Recovery\n\n| Error | Action |\n|---|---|\n| `forge-project.yml` not found | Skip without error (optional input) |\n| `--output-dir` missing | Stop, report missing input |\n| `--env` missing | Stop, report missing input |\n| `fix-plan.md` not found | Stop, report missing input |\n| `diagnosis.md` not found | Stop, report missing diagnosis |\n| `fix-plan.md` has BLOCKED status | Stop, report — reviewing blocked plan adds no value |\n| Plan references files that don't exist | Record as CRITICAL issue under 3A or 3H |\n| Plan structure doesn't match real code | Record as CRITICAL or BLOCKING under 3H |\n| Cannot read source files (permissions, missing) | Record as note in fix-review.md, downgrade affected attack angles to \"could not verify\" |\n\n## Output Directory\n\n```\n{output_dir}\u002F\n├── problem-statement.md     ← Input\n├── repro.md                 ← Input (if present)\n├── diagnosis.md             ← Input\n├── fix-plan.md              ← Input (the plan being reviewed)\n└── fix-review.md            ← Output (this skill writes this)\n```\n\n## What This Skill Does NOT Do\n\n- Does not propose fixes for issues found (that's revise mode of adversarial-fix-plan)\n- Does not re-investigate or challenge the diagnosis (only flags interpretation issues)\n- Does not modify fix-plan.md or any source code\n- Does not spawn sub-agents or run adversarial rounds\n- Does not have an interactive mode\n- Does not skip attack angles silently — every angle gets explicit confirmation in the Attack Angle Summary\n\n## Reference Files\n\n| File | When to read | Purpose |\n|---|---|---|\n| `references\u002Ffix-review-format.md` | When writing fix-review.md | Template for the output artifact |\n\n## Invocation\n\n```\nfix-plan-reviewer \\\n  --output-dir .dev\u002Ffixes\u002F{original-slug}\u002F{fix-slug}\u002F \\\n  --env prod \\\n  --original-slug {original-slug}\n```\n\nThe orchestrator is responsible for:\n\n- Invoking this skill after adversarial-fix-plan produces fix-plan.md\n- Reading the resulting fix-review.md\n- Routing based on severity counts:\n  - CRITICAL > 0 → escalate to user\n  - BLOCKING > 0 → re-dispatch adversarial-fix-plan (revise mode auto-detects fix-review.md)\n  - Only ADVISORY → advance to fix-coding (or revise at user discretion)\n\nThis skill is responsible for:\n\n- Reading inputs\n- Performing all 8 attack angles + diagnosis-doubt flag\n- Writing fix-review.md with severity-rated findings and the Attack Angle Summary\n- Reporting completion via standard FORGE_DONE callback (handled by orchestrator dispatch protocol)\n","# Fix Plan Reviewer\n\n## Overview\n\nA single procedural reviewer that attacks fix-plan.md and produces fix-review.md. The reviewer is itself the adversarial pressure on the plan; this skill does not run Agent Teams or multiple rounds.\n\n**Worker routing.** The orchestrator may run this skill locally (Claude lead) or dispatch to a Codex worker — same pattern as `proposal-reviewer` in the build pipeline. Codex is the recommended default because the fix-plan was produced by Claude (in `adversarial-fix-plan`); an external Codex review catches Claude-side blind spots. Local Claude execution is the fallback when Codex is unavailable.\n\nThe orchestrator uses fix-review.md's severity counts to decide:\n\n- **CRITICAL > 0** → escalate to user (fix-plan has a fundamental problem; possibly the diagnosis is wrong)\n- **BLOCKING > 0** → re-dispatch adversarial-fix-plan in revise mode\n- **Only ADVISORY** → advance to fix-coding (or revise at user discretion)\n\n## When to Use\n\n- After `adversarial-fix-plan` produces `fix-plan.md` and before `fix-coding`\n- The reviewer runs once per fix-plan version. After a revise pass produces fix-plan.md (v2), the reviewer is NOT automatically re-run unless the orchestrator decides another review pass is warranted.\n\n**Expected runtime**: ~5–10 min single-agent. The skill is bounded by the size of fix-plan.md, the number of files it touches (each must be read per Hard Rule 3), and the depth of the diagnosis. Larger fix plans with many files or PARTIALLY CONVERGED diagnoses run longer.\n\n## When NOT to Use\n\n- **No fix-plan.md exists.** Hard refusal — see Hard Rules.\n- **fix-plan.md has BLOCKED status** (INSUFFICIENT EVIDENCE diagnosis). The plan is already blocked; reviewing it adds no value. Orchestrator should escalate, not review.\n- **Re-reviewing the same fix-plan.md without changes.** Wasted work.\n- **Build-pipeline reviews.** Use `proposal-reviewer` for those.\n\n## Hard Rules\n\n1. **Attack the plan, do not propose fixes.** Issues describe *what is wrong* and *why*, not *how to fix*. Proposing fixes belongs to the revise mode of adversarial-fix-plan.\n2. **Verify against the diagnosis, not just the plan.** The reviewer must read diagnosis.md and answer: \"would the proposed changes actually make the diagnosed cause stop happening?\" Trusting the plan's self-claim is forbidden.\n3. **Read the actual code that would be touched.** When the plan says it will modify file X, the reviewer reads file X and confirms its structure matches the plan's assumptions. Trusting the plan's description of the code is forbidden.\n4. **Always produce fix-review.md.** Empty issue sections are acceptable. Silent failure is forbidden.\n5. **Severity ratings are conservative.** When uncertain between two levels, choose the higher (more severe). Under-rating ships bad fixes; over-rating adds a revision pass.\n6. **Do not re-investigate.** This skill does not challenge the diagnosis itself. It checks whether the plan addresses what the diagnosis says. If the plan misinterprets the diagnosis, that is a CRITICAL issue. If the diagnosis itself seems wrong, that is OUT OF SCOPE — flag the concern in fix-review.md but do not re-diagnose.\n7. **Single agent, no sub-agents.** This skill does not spawn teammates and does not run adversarial rounds.\n8. **No code changes.** This skill produces a review document. It does not modify source code or fix-plan.md.\n\n## Required Reads\n\nBefore writing the review:\n\n1. `{output_dir}\u002Ffix-plan.md` — the plan being reviewed\n2. `{output_dir}\u002Fdiagnosis.md` — the diagnosis the plan must address\n3. `{output_dir}\u002Fproblem-statement.md` — original problem context\n4. `{output_dir}\u002Frepro.md` — if present, repro context\n5. `~\u002F.claude\u002Fskills\u002Ffix-plan-reviewer\u002Freferences\u002Ffix-review-format.md` — output template (authoritative)\n\nOptional:\n\n- `.claude\u002Fforge-project.yml` (fallback: `~\u002F.claude\u002Fforge-project.yml`) — project config. Useful when reviewing test plans for protected pages (auth config) or when env-specific service settings affect the rollback assessment. Skip if not present.\n\nIf `--original-slug` is provided, also read for context (read-only):\n\n7. `.dev\u002Fproposals\u002F{original-slug}\u002Ffinal-plan.md`\n8. `.dev\u002Fproposals\u002F{original-slug}\u002Fimplementation.md`\n9. `.dev\u002Fproposals\u002F{original-slug}\u002Fcoder-report.md`\n\nThe reviewer ALSO reads the actual source files the plan proposes to touch. This is mandatory — see Hard Rule 3.\n\n## Inputs\n\nRequired:\n\n- `--output-dir` — path to the fix directory. fix-plan.md lives here; fix-review.md will be written here.\n- `--env prod | dev` — affects severity weighting. Prod issues weight higher (rollback rigor, deployment risk, regression blast radius).\n\nOptional:\n\n- `--original-slug` — slug of the original build pipeline. Enables read-only context access.\n\n## Phase 0: Config + Inputs\n\n1. Read `.claude\u002Fforge-project.yml` if present (optional — see Required Reads). Skip without error if absent.\n2. Read `fix-plan.md` from `--output-dir`\n3. **Empty-args short-circuit.** If `--output-dir` is missing, `--env` is missing, or `fix-plan.md` does not exist, stop:\n   ```\n   FIX-PLAN-REVIEWER ERROR: Missing required input. Provide --output-dir,\n   --env (one of `prod` | `dev`), and ensure fix-plan.md exists.\n   ```\n4. **Status check.** If fix-plan.md has `Status: BLOCKED`, stop:\n   ```\n   FIX-PLAN-REVIEWER ERROR: fix-plan.md has BLOCKED status. Reviewing a\n   blocked plan adds no value. The orchestrator should escalate.\n   ```\n5. Read `diagnosis.md`, `problem-statement.md`, `repro.md` (if present)\n6. If `--original-slug` is provided, confirm `.dev\u002Fproposals\u002F{original-slug}\u002F` exists; read its artifacts\n\n## Phase 1: Attack Surface Mapping\n\nParse fix-plan.md and extract:\n\n- The cited root cause (from Diagnosis Reference)\n- The fix approach (Surgical \u002F Robust \u002F synthesized position)\n- Each file the plan proposes to modify, add, or remove\n- Each defense the plan adds (with stated justification)\n- Each test the plan calls for\n- The rollback plan\n- The risk assessment claims\n\nThis is the structured target list for the review attack.\n\n## Phase 2: Read the Actual Code\n\nFor each file the plan proposes to touch:\n\n- Read the file\n- Confirm the file exists at the stated path\n- Confirm the structure matches the plan's assumptions (function names, class layouts, dependencies)\n- Note discrepancies between what the plan describes and what's actually there\n\nThis phase is mandatory and is the basis for many CRITICAL findings. A plan that misdescribes the code it touches will produce a fix that doesn't compile or doesn't behave as intended.\n\n## Phase 3: Attack Angles\n\nThe reviewer runs each of these attacks against the plan. Each attack is a question the reviewer must explicitly answer in fix-review.md, even if the answer is \"no issues found.\"\n\n### 3A. Cause Coverage\n\n**Question: Would the proposed changes actually make the diagnosed cause stop happening?**\n\n- Map each diagnosed cause element to the plan changes that address it\n- Identify any cause element with no corresponding change\n- Identify any change that doesn't serve any cause element (potential scope creep — see 3C)\n\nA miss here is typically CRITICAL. The fix doesn't fix.\n\n### 3B. Defense Adequacy\n\n**Question: For PARTIALLY CONVERGED diagnoses, did the plan address the alternative causes? For all diagnoses, are the defenses (if any) defending against the right things?**\n\n- Check Defense section against the diagnosis's alternative causes (if any)\n- Check each defense against its stated justification — is the justification grounded in real fragility, or cargo-culted?\n- Check whether obvious adjacent fragilities (related code paths that could fail similarly) are addressed or explicitly ignored with rationale\n\nMisses here are typically BLOCKING.\n\n### 3C. Scope Correctness\n\n**Question: Is the fix appropriately scoped — neither too narrow nor too broad?**\n\nTwo directions:\n\n- **Too narrow**: are there obvious adjacent fragilities the fix should address?\n- **Too broad**: are there changes that don't serve the diagnosis (unrelated refactors, scope creep)?\n\nToo narrow is typically BLOCKING. Too broad is typically ADVISORY unless the over-broad change introduces real risk, in which case BLOCKING.\n\n### 3D. Regression Risk\n\n**Question: What could break that the test plan doesn't cover?**\n\n- For each file touched, identify dependents (other files that import or call into it)\n- Identify dependents whose tests would NOT exercise the changes\n- Identify behaviors of the changed code that the change might inadvertently alter\n\nMisses here are typically BLOCKING for prod, ADVISORY for dev.\n\n### 3E. Rollback Integrity\n\n**Question: Will the rollback plan actually work?**\n\nEspecially important for prod. The reviewer asks:\n\n- Are there schema or data changes that can't be cleanly reverted?\n- Are there cascading effects (one revert requires another)?\n- Does \"just revert the commit\" actually restore working state, or does it leave intermediate state?\n- For prod: are deployment considerations realistic? Monitoring named?\n\nMisses here are typically BLOCKING for prod, ADVISORY for dev.\n\n### 3F. Test Plan Integrity\n\n**Question: Do the proposed tests actually prove the fix works AND the regressions don't happen?**\n\nThe killer question: **would the proposed tests have caught the original bug?**\n\n- A test that passes before and after the fix because it doesn't exercise the failing path is worthless\n- Verify the test plan exercises the actual cause, not adjacent code\n- Verify regression tests actually exercise the dependents identified in 3D\n\n**When repro.md is absent**, the killer question is harder to answer because the concrete shape of the original bug is less explicit. Fall back to: \"do the proposed tests exercise the diagnosed cause path identified in `diagnosis.md`'s evidence chain?\" This is weaker than the repro-driven check but still actionable — a test that doesn't traverse the cited file:line locations from the evidence chain almost certainly wouldn't catch the bug.\n\nMisses here are typically BLOCKING.\n\n### 3G. Risk Assessment Honesty\n\n**Question: Did the planner downplay risks or miss any?**\n\n- Cross-reference the plan's stated risks against the reviewer's attack findings — are findings from 3A-3F that should have appeared in the plan's Risk Assessment actually there?\n- Check for honesty about blast radius\n- Check for honesty about deployment risk (prod only)\n\nMisses here are typically ADVISORY unless they materially change the risk calculus, in which case BLOCKING.\n\n### 3H. Plan-vs-Diagnosis Interpretation\n\n**Question: Does the plan correctly interpret what the diagnosis says?**\n\n- Does the cited root cause in fix-plan match what diagnosis.md actually committed to?\n- For PARTIALLY CONVERGED: does the plan acknowledge the alternatives the diagnosis flagged?\n\nMisses here are typically CRITICAL — the plan is solving a different problem than the diagnosis identified.\n\n### 3I. Diagnosis-Doubt Flag (out of scope)\n\n**Question (always answered, even if empty): In the course of reviewing the plan, did I see any signal that the diagnosis itself is wrong (not just the plan's interpretation of it)?**\n\nThis angle is checked on every run, parallel to 3A–3H. The reviewer must explicitly answer in fix-review.md's \"Diagnosis Concerns\" section — even when the answer is \"no concerns observed.\" Passive noticing is not enough; an empty section means the reviewer affirmatively saw no signal, not that the reviewer forgot to look.\n\nIf concerns ARE observed, the reviewer flags them in the \"Diagnosis Concerns\" section with severity ADVISORY (because the reviewer is not a re-investigator). The orchestrator decides whether to re-run investigate.\n\nThis is NOT a CRITICAL issue against the plan — the plan can only be as good as the diagnosis. It's an out-of-band signal to the orchestrator. Concrete plan-vs-diagnosis discrepancies still surface as CRITICAL via 3H; 3I is for reviewer-side suspicion that the upstream diagnosis itself missed the mark.\n\n## Phase 4: Severity Assignment\n\nEach finding from Phase 3 gets a severity:\n\n| Severity | Meaning | Orchestrator Action |\n|---|---|---|\n| **CRITICAL** | Fix doesn't address the diagnosis, plan misinterprets diagnosis, or plan has fatal flaw | Escalate to user; possibly re-run investigate |\n| **BLOCKING** | Fix has problems that must be addressed before fix-coding | Re-dispatch adversarial-fix-plan in revise mode |\n| **ADVISORY** | Fix is fundamentally sound but has improvable aspects | Advance to fix-coding (or revise at user discretion) |\n\nSeverity guidance:\n\n- Cause coverage misses (3A): CRITICAL if any cause element is unaddressed; BLOCKING if addressed but inadequately\n- Plan-vs-diagnosis misinterpretation (3H): CRITICAL\n- Test plan that doesn't exercise the failing path (3F): BLOCKING\n- Rollback that won't work for prod (3E with --env prod): BLOCKING\n- Defense missing for stated PARTIALLY CONVERGED alternative (3B): BLOCKING\n- Scope too narrow with named adjacent fragility (3C): BLOCKING\n- Scope too broad without risk (3C): ADVISORY\n- Risk assessment downplay without material consequence (3G): ADVISORY\n\nWhen uncertain between two severities, choose the higher.\n\n## Phase 5: Write fix-review.md\n\nWrite `{output_dir}\u002Ffix-review.md` following the structure in `references\u002Ffix-review-format.md` (authoritative). The template below is a preview for orientation; if it diverges from the reference file, the reference file wins.\n\n```markdown\n# Fix Plan Review — {slug}\n\n## Verdict\n{APPROVE | REVISE | REJECT}\n- APPROVE: no CRITICAL or BLOCKING issues (ADVISORY-only, or no issues at all). fix-plan can advance to fix-coding.\n- REVISE: BLOCKING issues present (and no CRITICAL). fix-plan needs revision via revise mode.\n- REJECT: any CRITICAL issue present. fix-pipeline should escalate to user.\n\n## Environment\n{prod | dev}\n\n## Critical Issues\n{Issues with severity CRITICAL. Empty section if none.}\n\nFor each:\n- **Issue**: brief title\n- **Target Section**: which section of fix-plan.md the issue applies to\n- **Finding**: what is wrong\n- **Why It Matters**: why this is a problem, with reference to diagnosis or code\n- **Required Resolution**: what the plan needs to address (NOT how to fix it)\n\n## Blocking Issues\n{Issues with severity BLOCKING. Same per-issue structure. Empty section if none.}\n\n## Advisory Issues\n{Issues with severity ADVISORY. Same per-issue structure. Empty section if none.}\n\n## Diagnosis Concerns\n{Out-of-scope concerns about the diagnosis itself. Empty if none. Severity always ADVISORY at this layer.}\n\n## Strengths\n{What the plan got right. This helps the reviser preserve good parts during revise mode.\n Brief — no need to praise everything; just call out what specifically should be preserved.}\n\n## Attack Angle Summary\n{One line per attack angle (3A-3H), confirming it was checked and the result.\n Required for transparency — the reviewer must show its work.}\n\n| Angle | Result |\n|---|---|\n| 3A Cause Coverage | \u003Cissues found \u002F clean> |\n| 3B Defense Adequacy | \u003Cissues found \u002F clean \u002F N\u002FA for CONVERGED diagnoses> |\n| 3C Scope Correctness | \u003Cissues found \u002F clean> |\n| 3D Regression Risk | \u003Cissues found \u002F clean> |\n| 3E Rollback Integrity | \u003Cissues found \u002F clean> |\n| 3F Test Plan Integrity | \u003Cissues found \u002F clean> |\n| 3G Risk Assessment Honesty | \u003Cissues found \u002F clean> |\n| 3H Plan-vs-Diagnosis Interpretation | \u003Cissues found \u002F clean> |\n\n## Confidence + Blocking Items\nCONFIDENCE: HIGH | MEDIUM | LOW\nBLOCKING_ITEMS: N\n\n(BLOCKING_ITEMS = count of CRITICAL + BLOCKING issues. ADVISORY does not count toward blocking.)\n```\n\nThe Attack Angle Summary table is mandatory — it forces the reviewer to confirm each angle was checked, even when no issues were found. This prevents silent skipping.\n\n## Phase 6: Output Quality Gate (Self-Check Before FORGE_DONE)\n\nBefore signaling completion, verify the written `fix-review.md` on disk:\n\n1. The file exists at `{output_dir}\u002Ffix-review.md` and is non-empty\n2. All required sections are present, in this order:\n   - Verdict (with one of APPROVE \u002F REVISE \u002F REJECT)\n   - Environment\n   - Critical Issues\n   - Blocking Issues\n   - Advisory Issues\n   - Diagnosis Concerns (may be empty, but the section header must exist with the explicit answer to 3I)\n   - Strengths\n   - Attack Angle Summary\n   - Confidence + Blocking Items (last two lines exactly)\n3. The Attack Angle Summary table contains a row for each of 3A, 3B, 3C, 3D, 3E, 3F, 3G, 3H — no row may be missing or marked \"skipped\"\n4. The Verdict matches the severity counts:\n   - APPROVE iff no CRITICAL and no BLOCKING\n   - REVISE iff no CRITICAL but at least one BLOCKING\n   - REJECT iff at least one CRITICAL\n5. The last two lines are exactly `CONFIDENCE: {HIGH|MEDIUM|LOW}` and `BLOCKING_ITEMS: {N}`, where N = count of CRITICAL + BLOCKING\n6. The reviewer touches `fix-review.md` last so its mtime reflects review completion (lets the downstream revise-mode mtime check work correctly)\n\nIf any check fails, fix the file and re-verify. The Attack Angle Summary table specifically is a load-bearing transparency mechanism — a missing row means the reviewer skipped an attack angle silently, which violates Hard Rule 4 in spirit even if the file exists.\n\nOnce the self-check passes, signal FORGE_DONE.\n\n## Error Recovery\n\n| Error | Action |\n|---|---|\n| `forge-project.yml` not found | Skip without error (optional input) |\n| `--output-dir` missing | Stop, report missing input |\n| `--env` missing | Stop, report missing input |\n| `fix-plan.md` not found | Stop, report missing input |\n| `diagnosis.md` not found | Stop, report missing diagnosis |\n| `fix-plan.md` has BLOCKED status | Stop, report — reviewing blocked plan adds no value |\n| Plan references files that don't exist | Record as CRITICAL issue under 3A or 3H |\n| Plan structure doesn't match real code | Record as CRITICAL or BLOCKING under 3H |\n| Cannot read source files (permissions, missing) | Record as note in fix-review.md, downgrade affected attack angles to \"could not verify\" |\n\n## Output Directory\n\n```\n{output_dir}\u002F\n├── problem-statement.md     ← Input\n├── repro.md                 ← Input (if present)\n├── diagnosis.md             ← Input\n├── fix-plan.md              ← Input (the plan being reviewed)\n└── fix-review.md            ← Output (this skill writes this)\n```\n\n## What This Skill Does NOT Do\n\n- Does not propose fixes for issues found (that's revise mode of adversarial-fix-plan)\n- Does not re-investigate or challenge the diagnosis (only flags interpretation issues)\n- Does not modify fix-plan.md or any source code\n- Does not spawn sub-agents or run adversarial rounds\n- Does not have an interactive mode\n- Does not skip attack angles silently — every angle gets explicit confirmation in the Attack Angle Summary\n\n## Reference Files\n\n| File | When to read | Purpose |\n|---|---|---|\n| `references\u002Ffix-review-format.md` | When writing fix-review.md | Template for the output artifact |\n\n## Invocation\n\n```\nfix-plan-reviewer \\\n  --output-dir .dev\u002Ffixes\u002F{original-slug}\u002F{fix-slug}\u002F \\\n  --env prod \\\n  --original-slug {original-slug}\n```\n\nThe orchestrator is responsible for:\n\n- Invoking this skill after adversarial-fix-plan produces fix-plan.md\n- Reading the resulting fix-review.md\n- Routing based on severity counts:\n  - CRITICAL > 0 → escalate to user\n  - BLOCKING > 0 → re-dispatch adversarial-fix-plan (revise mode auto-detects fix-review.md)\n  - Only ADVISORY → advance to fix-coding (or revise at user discretion)\n\nThis skill is responsible for:\n\n- Reading inputs\n- Performing all 8 attack angles + diagnosis-doubt flag\n- Writing fix-review.md with severity-rated findings and the Attack Angle Summary\n- Reporting completion via standard FORGE_DONE callback (handled by orchestrator dispatch protocol)\n",{"name":5,"description":7},"main","50bb36677eced958128cea262c304bf9ceee4d4e","skills\u002Ffix-plan-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 fix-plan-reviewer",{"tool":55,"command":56},"bunx","bunx skills add SirTheOracle\u002Fforge-toolkit --skill fix-plan-reviewer",{"tool":58,"command":59},"pnpm","pnpm dlx skills add SirTheOracle\u002Fforge-toolkit --skill fix-plan-reviewer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Ffix-plan-reviewer\u002FSKILL.md",true,[63],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Ffix-review-format.md","REFERENCE","参考文档",7972,"https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Ffix-plan-reviewer\u002Freferences\u002Ffix-review-format.md",[70,97,117,137,158,172],{"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,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96],"forge","orchestrator","forge orchestrator","bridge","map","code","tasks","across","work","audit","multi-agent","logging","tmux","for","audit logging","workers","stage","with","multi","state",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"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",[],[104,18,77,105,106,34,107,108,31,109,110,111,82,112,85,20,113,114,115,116],"runner","forge fix runner","quick","actionable","time","qa","gating","when","verification","human","run","at","issue",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"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,124,125,126,127,128,129,130,131,132,133,134,135,136],"forge coder","coder","diffs","tests","execution","commit","changes","artifact","procedural","report","codebase","implementation","coding",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"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",[],[144,145,18,146,147,148,149,34,150,151,152,153,154,155,156,111,93,94,96,157],"reproducer","fix reproducer","deterministic","evidence","executor","diagnose","Reproducible","environment","trigger","branches","dev","single","repro","first",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"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",[],[18,165,125,148,36,34,33,166,167,126,168,129,19,20,169,170,23,171,150,152],"fix coder","failing","mechanical","files","bug","path","test plan",{"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},"01M70FREVCBF0YX1FX8WNAQTGP","docs-refresh","Generates and maintains living documentation from the current codebase state. Reads a project-local manifest (.claude\u002Fdocs-refresh.yml) that declares doc targets, sections, source inventories, and refresh boundaries. Uses marker blocks in docs to safely regenerate content without trampling manual prose.","https:\u002F\u002Fgithub.com\u002FSirTheOracle\u002Fforge-toolkit\u002Fblob\u002Fmain\u002Fskills\u002Fdocs-refresh\u002FSKILL.md",[],[179,180,181,182,183,184,185,186,96,187,134,188,189,190,191,192,193],"refresh","docs refresh","docs","project","manual","local","manifest","documentation","targets","blocks","doc","prose","source","content","marker"]