{"id":18068,"plugin_id":"plugins_6a7da17696b081918e2d9debd654a099","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:35.924Z","digest":"2c2daa62c9dd3240963329ecaa4194e7e0c4dfbd7373b60279fc0580acdce34b","against":null,"payload":{"description":"Orchestrate software engineering workflows across the canonical get-fable coding lifecycle with deterministic routing and evidence precedence. Use when starting a complex coding task, navigating lifecycle phases, resuming work with durable .fable state, or routing between research, planning, testing, verification, and recovery — even if the user does not explicitly say \"get-fable\" (e.g. \"follow fable lifecycle\", \"orchestrate this project\", \"what is the next engineering step\", \"route my task\"). Do NOT use when an individual specialist skill already has clear isolated ownership of a bounded subtask.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":351},{"relative_path":"evals/scenarios.json","size_in_bytes":4282},{"relative_path":"examples/lifecycle-walkthrough.md","size_in_bytes":702},{"relative_path":"references/lifecycle-routing-matrix.md","size_in_bytes":1778},{"relative_path":"references/stateful-routing-and-precedence.md","size_in_bytes":2535},{"relative_path":"registry.json","size_in_bytes":24311},{"relative_path":"skill.package.json","size_in_bytes":456},{"relative_path":"templates/lifecycle-state.template.json","size_in_bytes":539}],"name":"get-fable","skill_md_contents":"---\nname: get-fable\ndescription: \"Orchestrate software engineering workflows across the canonical get-fable coding lifecycle with deterministic routing and evidence precedence. Use when starting a complex coding task, navigating lifecycle phases, resuming work with durable .fable state, or routing between research, planning, testing, verification, and recovery — even if the user does not explicitly say \\\"get-fable\\\" (e.g. \\\"follow fable lifecycle\\\", \\\"orchestrate this project\\\", \\\"what is the next engineering step\\\", \\\"route my task\\\"). Do NOT use when an individual specialist skill already has clear isolated ownership of a bounded subtask.\"\nversion: 1.3.0\npack: core\ninputs:\n  - task_description\n  - current_state\nrequires:\n  - repo_access\nproduces:\n  - routing_decision\ngates:\n  - state_schema_valid\nfallback: null\nmutatesWorkspace: false\nparallelSafe: true\nneural_links:\n  precursors: []\n  continuations:\n    - fable-discover\n    - fable-research\n    - fable-plan\n  lateral_peers:\n    - fable-spark\n  recovery: fable-recover\n---\n\n# get-fable\n\nChoose the next engineering mode from the actual state of the work, not from the loudest keyword in the user's last message.\n\n## Mission\n`get-fable` is the lifecycle orchestrator. It decides **which specialist should own the next decision**, preserves continuity across long sessions, and prevents later phases from skipping evidence that earlier phases have not earned.\n\nGood routing is stateful. \"Ship it\" does not mean release if verification is stale. \"Fix it\" does not mean execute if the same hypothesis already failed twice. \"Use this API\" does not mean code from memory if the contract is current and unknown.\n\n## Activate When\n- a substantial engineering request enters the workspace;\n- the next Skill is ambiguous;\n- work resumes from `.fable` state or a handoff;\n- a phase transition is requested;\n- new evidence invalidates the current route;\n- a failure/review/security/release gate may override ordinary execution.\n\n## Do Not Activate When\n- a specialist is already executing a bounded, still-valid contract and no routing condition changed;\n- the user asks only for a raw command output that a current Skill already owns;\n- repeated re-routing would add ceremony without changing the next safe action.\n\n## Routing Classification\nClassify the dominant reason the next action exists.\n\n| Situation | Preferred owner |\n| --- | --- |\n| repository/runtime facts unknown | `fable-discover` |\n| current external fact/API uncertain | `fable-research` |\n| architecture/decomposition/contract choice | `fable-plan` |\n| testable behavior change | `fable-tdd` |\n| genuinely independent bounded cards | `fable-delegate` |\n| bounded accepted implementation | `fable-execute` |\n| fresh falsification required | `fable-verify` |\n| independent diff correctness review | `fable-review` |\n| trust boundary/vulnerability/security work | `fable-security` |\n| repeated/contradictory failure | `fable-recover` |\n| candidate is ready for distribution decision | `fable-release` |\n| another session/agent must resume | `fable-handoff` |\n| agent-control change needs benchmark proof | `fable-eval` |\n| next atomic move is unclear inside active work | `fable-spark` |\n\n## Orchestration Protocol\n\n### Stage 1 — Read intent and durable state\nConsider together:\n- user's current request;\n- active card/phase;\n- failure streak;\n- mutation vs verified generation;\n- open review/security findings;\n- unresolved load-bearing unknowns;\n- release/handoff state.\n\nThe last sentence in chat does not erase the lifecycle state.\n\n### Stage 2 — Apply precedence gates\nBefore intent scoring, check hard overrides:\n1. corrupted/invalid state → diagnose/repair state before trusting it;\n2. repeated failure or contradictory evidence → recover;\n3. explicit security-sensitive request → security specialist;\n4. stale verification when completion/release is requested → verify;\n5. blocking unknown that changes design → discover/research;\n6. otherwise route by task ownership.\n\nPrecedence exists to stop a plausible but unsafe lower-level action.\n\n### Stage 3 — Distinguish task type from requested outcome\nExamples:\n- \"Publish this\" is an outcome; current state may still require verify/review first.\n- \"Fix this\" is an outcome; unknown root location may require discovery.\n- \"Make it faster\" may be research/measurement/planning before execution.\n- \"Review and fix\" is two stages; review should identify grounded findings before mutation unless user explicitly asks for direct repair and evidence is already clear.\n\n### Stage 4 — Route to one primary owner\nChoose the Skill that owns the **next load-bearing decision**, not every Skill that might eventually participate.\n\nReturn:\n- selected Skill;\n- reason/precedence;\n- evidence/state used;\n- gate that will permit the next transition.\n\n### Stage 5 — Persist only meaningful transitions\nUpdate lifecycle state when the route changes actual work phase or evidence freshness. Do not churn state for read-only explanatory turns.\n\n### Stage 6 — Re-route on new evidence\nA route is not permanent. Recompute when:\n- an assumption is disproved;\n- scope expands;\n- a failure repeats;\n- security risk appears;\n- mutation makes proof stale;\n- a worker discovers a dependency collision;\n- release candidate changes.\n\n## Decision Rules\n- `failureStreak >= 2` with materially similar attempts outranks execution and routes to recovery.\n- Explicit vulnerability/threat/authz/secret/trust-boundary work routes to security even if the diff also needs general review later.\n- Current external API/version uncertainty routes to research; repository-local uncertainty routes to discovery.\n- If implementation cannot proceed without choosing a new contract/architecture, plan before execute.\n- A testable bug/behavior change should route through TDD unless a valid regression harness is impossible or already established.\n- \"Done\", \"merge\", \"ship\", or \"release\" cannot bypass stale/missing verification.\n- A passing receipt/research note is not completion-capable evidence.\n- Delegation is selected for real independence, not simply because there are multiple subtasks.\n- Handoff is selected when continuity itself is the deliverable; it does not substitute for verification.\n- Prefer the narrowest specialist that owns the next decision; avoid keeping the orchestrator active once ownership is clear.\n\n## Invariants\n- One primary Skill owns the next load-bearing decision.\n- State/evidence precedence can override textual intent when necessary for correctness.\n- No completion/release route relies on evidence older than relevant mutation.\n- Repeated failed hypotheses do not route back into blind execution.\n- Research and discovery are distinct: external current fact vs repository/runtime fact.\n- Routing explanations remain traceable to intent/state, not hidden scoring alone.\n\n## Failure Taxonomy\n### Keyword capture\nRouter sees \"release\", \"security\", or \"test\" and ignores the actual state/task. Re-evaluate precedence and ownership.\n\n### State blindness\nRouter uses the last prompt but ignores failure streak, stale proof, or active card. Re-read durable state.\n\n### Over-orchestration\nEvery small step returns through the router although specialist ownership remains valid. Keep the active specialist until a routing condition changes.\n\n### Under-routing\nExecution continues after a new architecture unknown, repeated failure, or security boundary appears. Stop and re-route.\n\n### Multi-owner ambiguity\nSeveral Skills seem plausible. Select the one that owns the earliest unresolved decision; encode later Skills as continuations/gates, not simultaneous primary owners.\n\n### Stale-state corruption\nState does not match repository reality. Diagnose/repair before using it as a routing oracle.\n\n## Anti-Patterns\n- routing by one keyword;\n- treating user's desired final outcome as the immediate next action;\n- re-routing every turn for ceremony;\n- using Spark as a substitute for specialist selection;\n- sending a repeated failure back to execute;\n- sending unknown external API details to repository discovery;\n- accepting stale verification because the user said \"ship it\";\n- selecting multiple primary Skills with no order.\n\n## Routing Packet\n\n```text\nIntent/outcome:\nCurrent phase/card:\nState overrides: failure / stale evidence / security / unknowns\nPrimary next decision:\nSelected Skill:\nWhy this Skill now:\nGate to leave it:\nLikely continuation(s):\n```\n\n## Completion Criteria\nOrchestration for a turn is complete when:\n- the next load-bearing decision has one clear owner;\n- precedence gates were checked;\n- route is consistent with current evidence/state;\n- specialist receives enough context to begin without reinterpreting the whole conversation;\n- no later lifecycle claim is implied before its evidence exists.\n\n## Progressive Resources\n- Deep guide: `references/stateful-routing-and-precedence.md`\n- Existing matrix: `references/lifecycle-routing-matrix.md`\n- Example: `examples/lifecycle-walkthrough.md`\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}