{"id":18045,"plugin_id":"plugins_6a7da17696b081918e2d9debd654a099","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:35.254Z","digest":"1930a42084d5d20e9b78d9ae103f9aa128e733d8365b598cb39f64e155d377f6","against":null,"payload":{"description":"Implement one accepted, bounded work card with immediate local verification, invariant preservation, and zero scope drift. Use when executing a planned work card, applying a well-defined code change, implementing an isolated function, or performing targeted single-scope edits — even if the user does not explicitly say \"fable-execute\" (e.g. \"implement this card\", \"write the code for this step\", \"apply the agreed changes\", \"build this component\"). Do NOT use when new architectural decisions are required (use fable-plan) or when tests are repeatedly failing (use fable-recover).","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":369},{"relative_path":"evals/scenarios.json","size_in_bytes":4197},{"relative_path":"examples/bounded-card-execution.md","size_in_bytes":340},{"relative_path":"references/bounded-mutation-and-failure-classification.md","size_in_bytes":2659},{"relative_path":"references/mutation-containment.md","size_in_bytes":1270},{"relative_path":"skill.package.json","size_in_bytes":469},{"relative_path":"templates/execution-receipt.template.md","size_in_bytes":625}],"name":"fable-execute","skill_md_contents":"---\nname: fable-execute\ndescription: \"Implement one accepted, bounded work card with immediate local verification, invariant preservation, and zero scope drift. Use when executing a planned work card, applying a well-defined code change, implementing an isolated function, or performing targeted single-scope edits — even if the user does not explicitly say \\\"fable-execute\\\" (e.g. \\\"implement this card\\\", \\\"write the code for this step\\\", \\\"apply the agreed changes\\\", \\\"build this component\\\"). Do NOT use when new architectural decisions are required (use fable-plan) or when tests are repeatedly failing (use fable-recover).\"\nversion: 1.3.0\npack: core\ninputs:\n  - accepted_card\nrequires:\n  - bounded_scope\nproduces:\n  - implementation_diff\n  - card_completion\ngates:\n  - invariants_preserved\n  - acceptance_checked\nfallback: fable-plan\nmutatesWorkspace: true\nparallelSafe: false\nneural_links:\n  precursors:\n    - fable-plan\n    - fable-tdd\n    - fable-delegate\n  continuations:\n    - fable-verify\n  lateral_peers:\n    - fable-simplify\n  recovery: fable-recover\n---\n\n# Fable Execute\n\nImplement one accepted change without turning a bounded card into an unreviewable wandering session.\n\n## Mission\nExecution owns implementation, not architecture discovery. The agent should make the smallest coherent change that satisfies the accepted card, keep invariants visible, validate immediately, and stop when new facts invalidate the plan.\n\n\"Minimal\" means minimal behaviorally complete diff, not necessarily the fewest changed lines.\n\n## Activate When\n- scope and acceptance are explicit;\n- load-bearing architecture/external facts are settled;\n- the card can be implemented without inventing a new public contract;\n- the task is a bounded static/config/docs change where TDD adds no meaningful proof;\n- a TDD Skill has already established RED and implementation is ready.\n\n## Do Not Activate When\n- a behavior change still needs a valid RED (`fable-tdd`);\n- implementation reveals a new architecture decision (`fable-plan`);\n- a repeated failure needs diagnosis (`fable-recover`);\n- the task is to independently verify or review an existing diff (`fable-verify`/`fable-review`).\n\n## Change Classification\nBefore editing, classify the card:\n\n| Change | Execution concern |\n| --- | --- |\n| Local behavior | preserve surrounding contract |\n| Config/manifest | precedence, generated source, packaging |\n| Public API/CLI | compatibility and caller impact |\n| Data/persistence | transaction/migration invariant |\n| Generated output | edit source/generator, regenerate once |\n| Dependency wiring | lifecycle/cleanup/error propagation |\n| Repair after TDD | satisfy RED without widening behavior |\n| Repair after review | fix only grounded finding + affected proof |\n\n## Protocol\n\n### Stage 1 — Re-read the card against current workspace\nConfirm:\n- objective;\n- owned scope;\n- prohibited scope;\n- dependencies/assumptions;\n- acceptance evidence;\n- current git/workspace state.\n\nIf the workspace changed since planning in a way that invalidates assumptions, stop and replan rather than force the old card through.\n\n### Stage 2 — Inspect before mutation\nRead the exact target code and its immediate contracts/callers/tests. Avoid broad rediscovery, but do not edit from stale memory.\n\nIdentify invariants that must stay true during the change.\n\n### Stage 3 — Choose the smallest coherent mutation\nPrefer:\n- existing repository patterns;\n- source-of-truth over generated output;\n- local compatibility over speculative abstractions;\n- reversible changes when uncertainty remains;\n- one behavior change at a time.\n\n### Stage 4 — Mutate and record impact\nTrack:\n- files/surfaces changed;\n- new/changed contract;\n- generated artifacts affected;\n- acceptance command required after this mutation.\n\nIf an edit crosses card boundaries, pause and explain why before continuing.\n\n### Stage 5 — Immediate acceptance check\nRun the narrowest meaningful acceptance evidence as soon as the coherent mutation exists.\n\nA command exit code alone is insufficient if it does not exercise the changed behavior.\n\n### Stage 6 — Classify failure before another edit\nOn failure ask:\n- expected RED from ongoing TDD?\n- typo/compile issue introduced by current edit?\n- incorrect implementation hypothesis?\n- stale/build/config/harness problem?\n- hidden dependency/architecture change?\n\nOnly make another mutation if the failure provides new information that justifies it.\n\n### Stage 7 — Clean the diff\nBefore handoff:\n- remove debug output/dead experiments;\n- inspect accidental formatting or generated noise;\n- verify no unrelated file changed;\n- regenerate deterministic outputs from source when required;\n- preserve user-owned concurrent changes.\n\n### Stage 8 — Handoff for independent verification\nSend `fable-verify`:\n- card objective;\n- diff/touched surfaces;\n- acceptance command/result;\n- invariants considered;\n- generated/config impacts;\n- residual risk and unverified surfaces.\n\n## Decision Rules\n- New load-bearing unknown → stop and route to discover/research/plan.\n- New architecture/public contract decision → `fable-plan`; do not hide it as implementation detail.\n- Behavior change with no valid regression test where one is feasible → `fable-tdd`.\n- Generated file requested → locate generator/source and mutate source; regenerate output afterward.\n- Existing user/unrelated changes in target file → preserve them and make the smallest contextual edit; do not reset/overwrite wholesale.\n- Acceptance fails for a clearly introduced syntax/type error → repair directly, rerun, and keep scope bounded.\n- Similar implementation hypothesis fails repeatedly → `fable-recover`; arbitrary \"try again\" loops are forbidden.\n- Acceptance command passes but does not exercise the changed path → do not claim card completion; strengthen acceptance or hand off with that gap explicit.\n\n## Invariants\n- Card scope does not expand silently.\n- User/unrelated changes are preserved.\n- Source-of-truth is edited instead of derived output when applicable.\n- Every meaningful mutation makes prior verification stale.\n- No unrelated cleanup is bundled into a repair unless required for correctness.\n- Acceptance evidence corresponds to the changed behavior.\n\n## Failure Taxonomy\n### Local implementation defect\nCurrent edit causes a direct syntax/type/assertion failure. Fix within card.\n\n### Hypothesis failure\nCode is valid but behavior remains wrong. Revise hypothesis; repeated similar failures route to recovery.\n\n### Hidden dependency\nCorrect behavior requires a component/contract outside the accepted card. Stop and replan scope.\n\n### Harness/artifact mismatch\nCommands execute stale build, wrong env, wrong branch, or generated artifact. Route to recovery when this obscures causal evidence.\n\n### Acceptance weakness\nCheck passes without exercising the change. Strengthen proof before completion.\n\n### Concurrent-work conflict\nTarget contains legitimate changes not owned by this card. Preserve them, narrow edit, or coordinate ownership; never overwrite for convenience.\n\n## Anti-Patterns\n- \"while I'm here\" refactors;\n- editing generated files directly;\n- broad search/architecture work after execution starts;\n- retrying the same patch with superficial syntax changes;\n- replacing an entire user-modified file for a small fix;\n- accepting a build pass as functional proof when behavior is not exercised;\n- adding abstraction/configurability not required by the card;\n- hiding an architecture decision inside implementation.\n\n## Execution Packet\n\n```text\nCard:\nOwned scope:\nFiles/surfaces changed:\nBehavior/contract delta:\nAcceptance command/result:\nInvariants checked:\nGenerated/config impacts:\nUnexpected facts:\nResidual risk:\nRecommended verify scope:\n```\n\n## Completion Criteria\nExecution completes when:\n- the accepted behavior is implemented within explicit scope;\n- immediate acceptance evidence is green or any proof gap is explicitly handed off;\n- diff contains no accidental/unrelated mutation;\n- new architecture decisions have not been smuggled into implementation;\n- the verification specialist has a precise map of what changed and what remains to falsify.\n\n## Progressive Resources\n- Deep containment guide: `references/bounded-mutation-and-failure-classification.md`\n- Existing containment reference: `references/mutation-containment.md`\n- Example: `examples/bounded-card-execution.md`\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}