Update to get-fable

{
  "description": "Perform an independent, evidence-grounded review of git diffs against requested specifications, architectural invariants, and code standards. Use when reviewing pull requests, inspecting code changes before merge, auditing diffs for regressions, or performing pre-commit sanity reviews — even if the user does not explicitly say \"fable-review\" (e.g. \"review this diff\", \"check this PR\", \"critique my changes\", \"code review this branch\"). Do NOT use for implementing fixes directly (use fable-tdd/fable-execute) or executing tests (use fable-verify).",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 401
    },
    {
      "relative_path": "evals/scenarios.json",
      "size_in_bytes": 4308
    },
    {
      "relative_path": "examples/code-review-finding.md",
      "size_in_bytes": 369
    },
    {
      "relative_path": "references/behavioral-diff-review-playbook.md",
      "size_in_bytes": 2982
    },
    {
      "relative_path": "references/diff-review-checklist.md",
      "size_in_bytes": 1627
    },
    {
      "relative_path": "skill.package.json",
      "size_in_bytes": 451
    },
    {
      "relative_path": "templates/review-finding.template.md",
      "size_in_bytes": 754
    }
  ],
  "name": "fable-review",
  "skill_md_contents": "---\nname: fable-review\ndescription: \"Perform an independent, evidence-grounded review of git diffs against requested specifications, architectural invariants, and code standards. Use when reviewing pull requests, inspecting code changes before merge, auditing diffs for regressions, or performing pre-commit sanity reviews — even if the user does not explicitly say \\\"fable-review\\\" (e.g. \\\"review this diff\\\", \\\"check this PR\\\", \\\"critique my changes\\\", \\\"code review this branch\\\"). Do NOT use for implementing fixes directly (use fable-tdd/fable-execute) or executing tests (use fable-verify).\"\nversion: 1.3.0\npack: proof\ninputs:\n  - implementation_diff\nrequires:\n  - target_scope\nproduces:\n  - review_evidence\n  - review_verdict\ngates:\n  - grounded_diff_read\n  - actionable_findings\nfallback: fable-recover\nmutatesWorkspace: false\nparallelSafe: true\nneural_links:\n  precursors:\n    - fable-verify\n  continuations:\n    - fable-security\n    - fable-release\n  lateral_peers:\n    - fable-security\n  recovery: fable-recover\n---\n\n# Fable Review\n\nReview the change as an independent engineer trying to find plausible defects, not as the implementer explaining why the patch is probably fine.\n\n## Mission\nA useful review connects a concrete line/change to a concrete failure mode. It prioritizes correctness, invariants, compatibility, lifecycle behavior, and test adequacy before style preference.\n\nThe reviewer should be skeptical without manufacturing noise.\n\n## Activate When\n- a diff/PR/implementation is ready for independent inspection;\n- verification is green but human/semantic risks remain;\n- repository conventions or public contracts may have been violated;\n- a release/merge needs grounded review evidence.\n\n## Do Not Activate When\n- no diff or concrete change exists;\n- the main task is automated execution evidence (`fable-verify`);\n- the requested work is threat modeling/security specialization (`fable-security`);\n- blocking behavior is already known and needs implementation (`fable-execute`).\n\n## Review Classification\nClassify the change because different diffs deserve different review depth.\n\n| Change | Primary review focus |\n| --- | --- |\n| Bug fix | root cause, regression test, adjacent paths |\n| New feature | contract, error states, lifecycle, compatibility |\n| Refactor | invariant preservation, accidental behavior delta |\n| Concurrency | ordering, shared state, cleanup, race/deadlock |\n| Persistence/migration | partial failure, transactions, compatibility, rollback |\n| Public API/CLI | callers, defaults, error/exit behavior, versioning |\n| Dependency upgrade | changed semantics, transitive behavior, config |\n| Packaging/build | exports, artifact contents, generated files, runtime entrypoints |\n\n## Review Protocol\n\n### Stage 1 — Reconstruct intent independently\nRead:\n- user/issue/card acceptance;\n- diff against the correct base;\n- relevant existing contracts/tests/instructions.\n\nState the intended behavior in your own words before judging the implementation.\n\n### Stage 2 — Read the whole diff, then trace risky changes\nDo not review isolated snippets only. Identify:\n- public/observable behavior delta;\n- state/data-flow delta;\n- control-flow/error delta;\n- lifecycle/resource delta;\n- concurrency delta;\n- config/generated/package delta.\n\nTrace important changes into callers/callees where a local diff cannot establish correctness.\n\n### Stage 3 — Check invariants and failure paths\nFor each material change ask:\n- What must remain true before/after?\n- What happens on invalid input?\n- What happens when dependency call fails/partially succeeds?\n- Are cleanup/rollback paths complete?\n- Can retries duplicate side effects?\n- Can async work outlive ownership/lifecycle?\n- Can old/new formats/callers coexist?\n\n### Stage 4 — Check tests as evidence, not decoration\nAsk:\n- Does a test fail on the pre-fix bug/old behavior where appropriate?\n- Does it exercise the real changed boundary?\n- Are important negative/error/concurrency/compatibility paths missing?\n- Were tests weakened/snapshots blindly updated?\n- Could implementation be wrong while tests still pass?\n\nDo not demand tests for trivial static changes when no meaningful behavior is testable.\n\n### Stage 5 — Check scope and maintainability only after correctness\nLook for:\n- hidden unrelated refactors;\n- duplicated logic that creates inconsistent behavior;\n- new abstractions whose complexity exceeds need;\n- API/config names that misrepresent semantics;\n- comments/docs inconsistent with new behavior.\n\nAvoid style-only comments unless repository rules make them blocking or they materially reduce readability/correctness.\n\n### Stage 6 — Calibrate findings\nEach finding must include:\n- severity: blocking / important / suggestion;\n- exact file/line or changed symbol;\n- concrete failure scenario;\n- why existing evidence does not rule it out;\n- minimal repair direction where useful.\n\nIf you cannot describe a plausible failure mode, it is probably not a defect finding.\n\n### Stage 7 — Produce verdict\n- **APPROVE**: no blocking/important correctness issues found; remaining suggestions are optional.\n- **CHANGES_REQUIRED**: at least one grounded issue can cause incorrect behavior, contract violation, or unacceptable risk.\n- **INCOMPLETE**: review cannot establish correctness because required context/diff/evidence is missing.\n\n## Decision Rules\n- Never approve without reading the actual diff against a known base.\n- A passing test suite lowers some risk but does not cancel a code-level defect visible in the diff.\n- A suspicious pattern is not a finding until tied to a realistic failure mode.\n- Missing test is blocking only when the untested behavior is material and existing evidence cannot cover it.\n- For concurrency, reason about interleavings/ownership, not just whether promises are awaited.\n- For error handling, trace where the error goes and what state may already have changed.\n- For migrations, consider partial execution and mixed-version operation.\n- For package/config changes, review the user-installed/runtime artifact path, not just source shape.\n- If a blocking issue is narrow and understood, produce one repair card to `fable-execute`; if root cause is uncertain/repeated, route to `fable-recover`.\n\n## Invariants\n- Review is independent and read-only.\n- Findings are grounded in changed code or directly affected contracts.\n- No severity inflation to fill a quota.\n- No style preference masquerades as correctness.\n- Approval does not claim security proof unless security review actually ran.\n- Review verdict covers the actual diff/base inspected.\n\n## Failure Taxonomy\n### Rubber stamp\nReviewer relies on tests/author summary and barely reads diff. Re-run full diff review.\n\n### Pattern matching without failure model\nReviewer flags a pattern because it \"looks bad\" but cannot show impact. Investigate or drop it.\n\n### Local-only review\nChange is correct locally but breaks caller/contract/lifecycle. Trace affected boundary.\n\n### Test deference\nReviewer assumes green tests prove all semantics. Inspect test adequacy and changed risk.\n\n### Scope blindness\nUnrelated mutation or accidental behavior change hides in a large diff. Compare against card/non-goals.\n\n### Noise overload\nMany cosmetic suggestions obscure a real defect. Prioritize by impact and remove quota-driven comments.\n\n## Anti-Patterns\n- approving based on PR description alone;\n- line-by-line style commentary before understanding behavior;\n- \"add error handling\" without naming a failing error path;\n- \"add tests\" without naming the missing risk;\n- flagging every `any`, TODO, or long function independent of change impact;\n- assuming an awaited promise means concurrency is safe;\n- reviewing only files changed without following a public contract to callers;\n- treating absence of findings as evidence the review was deep.\n\n## Finding Template\n\n```text\nSeverity:\nLocation:\nChanged behavior/invariant:\nFailure scenario:\nWhy current evidence does not cover it:\nSuggested bounded repair:\n```\n\n## Completion Criteria\nReview completes when:\n- complete relevant diff/base was read;\n- intended behavior and changed risks were reconstructed;\n- important invariants/error/concurrency/compatibility/test surfaces were checked as applicable;\n- every reported issue has a concrete failure mode and location;\n- low-value noise is removed;\n- verdict is APPROVE, CHANGES_REQUIRED, or INCOMPLETE with evidence.\n\n## Progressive Resources\n- Deep guide: `references/behavioral-diff-review-playbook.md`\n- Existing checklist: `references/diff-review-checklist.md`\n- Example: `examples/code-review-finding.md`\n"
}