get-fable

View saved version →

---
name: fable-artifact
description: "Design and author structured technical proposals, responsive artifacts, architecture diagrams, Mermaid charts, and interactive components. Use when creating standalone markdown reports, architectural specifications, Mermaid diagrams, or interactive artifact widgets — even if the user does not explicitly say \"fable-artifact\" (e.g. \"create an artifact\", \"draw an architecture diagram\", \"write a technical proposal\", \"generate a mermaid flowchart\"). Do NOT use for quick one-line conversational answers."
version: 1.3.0
pack: system
inputs:
  - artifact_spec
requires:
  - design_requirements
produces:
  - artifact_document
  - interactive_ui
gates:
  - hierarchy_clear
  - theme_adaptive
fallback: fable-plan
mutatesWorkspace: true
parallelSafe: true
neural_links:
  precursors:
    - fable-dataviz
    - fable-plan
  continuations:
    - fable-verify
    - fable-review
  lateral_peers:
    - fable-dataviz
  recovery: fable-recover
---

# Fable Artifact

Turn requirements and evidence into a standalone artifact whose content, structure, diagrams, links, and rendered output can all be checked independently.

## Mission
An artifact is not successful because the Markdown parses or the diagram looks polished. It must communicate the right claims to the right audience, preserve source truth, make assumptions visible, and render in the medium the user will actually consume.

## Activate When
- producing RFCs, architecture proposals, technical reports, runbooks, decision records, diagrams, or rich standalone documentation;
- packaging analysis/results into a durable document;
- creating a diagram or interactive explanatory artifact from established requirements/evidence.

## Do Not Activate When
- a one-paragraph answer is sufficient;
- application logic itself needs modification (`fable-execute`);
- the main work is numerical chart selection (`fable-dataviz`);
- facts required by the artifact have not been researched/discovered yet.

## Artifact Classification
| Artifact | Primary contract |
| --- | --- |
| RFC/proposal | decision, alternatives, trade-offs, acceptance/rollout |
| Architecture doc | boundaries, data/control flow, invariants, deployment |
| Runbook | trigger, prerequisites, executable steps, rollback/escalation |
| Incident/report | timeline/evidence/impact without invented causality |
| Decision record | context, decision, alternatives, consequences |
| Diagram | semantic topology/sequence/state, not decorative boxes |
| Interactive explainer | accessible interaction + deterministic content/source |

## Protocol
### Stage 1 — Define audience and job
State who will use the artifact and what decision/action it must support. One artifact can contain multiple sections, but it should have one primary communication job.

### Stage 2 — Build a claim/source map
Before writing polished prose, identify:
- measured/source-backed facts;
- design decisions;
- assumptions/inferences;
- unresolved items;
- data/visual sources;
- claims that need citations/links.

Do not invent examples, metrics, architecture components, test results, or citations to make the document feel complete.

### Stage 3 — Choose structure from artifact type
Examples:
- RFC: context → goals/non-goals → evidence → options → decision → design → risks → rollout/rollback → acceptance;
- runbook: symptom/trigger → safety prerequisites → diagnosis → action → verification → rollback/escalation;
- architecture: scope → context → components/boundaries → flows → data/state → failure/security → deployment/operations → decisions.

Avoid generic template sections that do not serve the document's job.

### Stage 4 — Design diagrams semantically
Each node/edge should represent a real component, state, dependency, event, or data/control flow. Label direction/meaning where ambiguity exists.

For Mermaid or other text diagrams:
- validate syntax;
- quote/escape labels safely;
- avoid giant unreadable graphs;
- split views by question (con

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-config
description: "Configure and audit AI agent harness settings, permissions allowlists, environment variables, editor keybindings, and lifecycle hook integrations. Use when modifying settings.json, adjusting tool permissions, setting up environment variables, or configuring agent lifecycle hooks — even if the user does not explicitly say \"fable-config\" (e.g. \"update settings\", \"allow command permissions\", \"configure agent hooks\", \"setup environment variables\"). Do NOT use for application-level business configuration."
version: 1.3.0
pack: system
inputs:
  - config_change
requires:
  - target_harness
produces:
  - settings_diff
gates:
  - valid_json
  - safe_permissions
fallback: fable-plan
mutatesWorkspace: true
parallelSafe: false
neural_links:
  precursors:
    - fable-plan
  continuations:
    - fable-verify
    - get-fable
  lateral_peers:
    - fable-plan
  recovery: fable-recover
---

# Fable Config

Change harness/configuration behavior with explicit precedence, least privilege, secret-safe handling, and a verified rollback path.

## Mission
Configuration is executable behavior. A syntactically valid JSON/TOML/YAML file can still disable a guard, broaden permissions, write to the wrong scope, or be ignored because another source has higher precedence.

The Skill must prove both **configuration validity** and **effective behavior**.

## Activate When
- changing host/harness settings, permissions, hooks, keybindings, model/tool config, or environment references;
- adding/removing lifecycle enforcement;
- troubleshooting why a setting is not taking effect;
- configuring safe command/tool allowlists;
- migrating configuration formats/scopes.

## Do Not Activate When
- storing raw credentials/secrets;
- application business logic is the real change;
- a host capability is unknown and needs research/discovery first;
- the requested change is to weaken a safety boundary merely to bypass an error without understanding it.

## Configuration Classification
| Change | Main risk |
| --- | --- |
| Permission/allowlist | excessive privilege/wildcard scope |
| Hook registration | hook exists but is never invoked / blocks wrong phase |
| Environment config | precedence, secret leakage, type/format |
| Host settings | wrong user/project scope, unsupported keys |
| Model/tool config | changed behavior/cost/access unexpectedly |
| Keybindings/UI | collision/override |
| Generated config | manual edit overwritten by generator |

## Protocol
### Stage 1 — Locate source and effective scope
Identify:
- target host/version;
- project vs user/global scope;
- all configuration sources and precedence;
- generated vs hand-maintained files;
- existing user customizations to preserve.

Do not edit the first file with the right name until you know it is effective.

### Stage 2 — Define desired behavior and least privilege
State exactly what capability should become allowed/blocked/triggered and what must remain unchanged.

For permissions, prefer narrow command/tool/path patterns. Wildcards need explicit justification and threat consideration.

### Stage 3 — Protect secrets
Configuration may reference environment variable names or secure stores, but should not embed raw tokens/passwords/private keys unless the target's secure format explicitly requires protected encrypted storage.

If an existing secret is found in plaintext, do not echo it; route exposure handling appropriately.

### Stage 4 — Make a minimal merge
Preserve unknown/user-defined settings. Avoid replacing an entire config object/file when one scoped key can be merged.

For generated config, modify source/generator then regenerate.

### Stage 5 — Validate structure and semantics
Run available parser/schema/host diagnostics. Check:
- syntax;
- key types/enums;
- duplicate/conflicting entries;
- unsupported/deprecated keys;
- permission pattern scope;
- hook command/path existence.

### Stage 6 — Prove effective behavior
A valid file is not enough. Test the c

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-cowork
description: "Execute autonomous multi-step cowork sessions with silent tool chaining, outcome-first progress reporting, and strict safety boundary enforcement. Use when executing complex background tasks autonomously, running multi-tool refactoring workflows without conversational noise, or performing deep automated passes — even if the user does not explicitly say \"fable-cowork\" (e.g. \"run autonomously in background\", \"cowork mode\", \"execute quietly and report results\", \"silent refactor pass\"). Do NOT use when active user dialogue or step-by-step confirmation is required."
version: 1.3.0
pack: system
inputs:
  - autonomous_task
requires:
  - scoped_goal
produces:
  - autonomous_deliverable
  - outcome_summary
gates:
  - no_mid_chain_noise
  - outcome_first
fallback: fable-execute
mutatesWorkspace: true
parallelSafe: true
neural_links:
  precursors:
    - get-fable
  continuations:
    - fable-execute
    - fable-verify
    - fable-handoff
  lateral_peers:
    - fable-spark
  recovery: fable-recover
---

# Fable Cowork

Carry a scoped engineering objective through multiple tool calls and lifecycle stages with minimal conversational interruption, while preserving the same safety, evidence, and scope rules as interactive work.

## Mission
Autonomy is not permission to improvise indefinitely. Cowork mode should reduce conversational overhead—not remove checkpoints, verification, stop conditions, or user intent.

The agent owns execution between meaningful boundaries. It must still stop when the task requires a new product decision, destructive authorization, unavailable external permission, or a contradiction that changes the agreed goal.

## Activate When
- the user explicitly delegates a multi-step task end-to-end;
- the objective and success criteria are clear enough to continue without routine questions;
- the work may span discovery, planning, implementation, verification, review, and handoff;
- repeated narration would add noise while tool evidence can drive progress.

## Do Not Activate When
- the job is a simple answer or one bounded edit;
- core requirements are genuinely ambiguous and different choices materially change the product;
- an external irreversible action lacks authorization;
- work must wait for a future event rather than execute now;
- autonomy would require inventing credentials, access, or user intent.

## Autonomy Classification
| Task state | Cowork posture |
| --- | --- |
| Clear bounded sequence | execute silently through evidence gates |
| Multiple independent cards | delegate with explicit ownership |
| New architecture decision emerges | stop/replan; do not choose silently if material |
| Repeated failure | enter recovery before more mutation |
| External auth/permission unavailable | stop at hard wall with exact handoff |
| Destructive/public action authorized | execute with release/security checks |
| Destructive/public action not authorized | prepare/verify only; do not perform it |

## Protocol
### Stage 1 — Lock the objective and boundaries
Before long execution, capture:
- requested outcome;
- non-goals/protected surfaces;
- authorization boundaries;
- repository/worktree state;
- acceptance evidence;
- hard stop conditions.

Do not convert a broad aspiration into unlimited scope.

### Stage 2 — Route internally by lifecycle
Use the same specialist sequence as interactive get-fable work. Cowork is an execution mode across Skills, not a replacement for discovery/TDD/recovery/review.

### Stage 3 — Work in bounded chunks
For each card/phase:
- perform the necessary tool calls;
- collect evidence immediately;
- update state/checkpoint;
- continue only if the next dependency is already authorized and determined.

Keep user-visible updates sparse but meaningful for long work: surfaced finding, changed blocker, completed milestone—not narration of every command.

### Stage 4 — Detect drift
Stop autonomous forward motion if:
- requested outcome changed;
- new archit

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-dataviz
description: "Design and generate accessible, cohesive data visualizations, SVG charts, metric cards, and dashboard tiles with theme-adaptive styling and verified viewports. Use when creating SVG charts, rendering metrics plots, designing dashboard visuals, or visualizing performance trends — even if the user does not explicitly say \"fable-dataviz\" (e.g. \"make a chart of this data\", \"plot these benchmarks\", \"create an SVG graph\", \"visualize these metrics\"). Do NOT use for non-visual text-only data summaries or generic code edits."
version: 1.3.0
pack: system
inputs:
  - data_source
requires:
  - metric_specs
produces:
  - visualization_artifact
  - svg_chart
gates:
  - theme_contrast_valid
  - viewbox_defined
fallback: fable-execute
mutatesWorkspace: true
parallelSafe: true
neural_links:
  precursors:
    - fable-discover
  continuations:
    - fable-artifact
    - fable-run
    - fable-verify
  lateral_peers:
    - fable-artifact
  recovery: fable-recover
---

# Fable DataViz

Turn data into a visual claim that is easy to read **without changing what the data actually says**.

## Mission
A chart is an argument about magnitude, trend, distribution, relationship, uncertainty, or composition. The first job is to choose a visual encoding that matches that question. The second is to preserve statistical meaning. Styling comes after both.

A valid SVG with attractive colors can still be a bad visualization if it truncates axes deceptively, aggregates incompatible groups, hides missing data, implies causality from correlation, or invents precision the source does not support.

## Activate When
- a metric/trend/distribution/comparison/relationship needs visual explanation;
- benchmark/eval results need charts or stat graphics;
- a report/artifact needs an evidence-backed visual;
- raw data must be transformed into SVG/chart code or a visual specification.

## Do Not Activate When
- there is no actual data and the request would require inventing values;
- a plain table is more accurate/readable for a small lookup task;
- the core task is document structure rather than visual encoding (`fable-artifact`);
- the user requests an illustrative image rather than a data visualization.

## Question Classification
| Question | Useful first encoding | Typical misuse |
| --- | --- | --- |
| Compare categories | bar/dot plot | pie with many similar slices |
| Trend over ordered time | line/area with careful baseline | unordered category line chart |
| Distribution | histogram/box/violin/dot | average-only bar |
| Relationship | scatter/bubble with scale caveats | dual-axis correlation theater |
| Part-to-whole | stacked bar/100% bar; limited pie | sum components that are not one whole |
| Ranking | sorted bar/dot | alphabetic order hiding rank |
| Single KPI + context | stat + baseline/change | giant number without denominator/timeframe |
| Uncertainty | interval/band/error bars | precise point with hidden variance |

## Protocol
### Stage 1 — Establish data provenance and semantic contract
Record:
- source/dataset/version/time window;
- unit and denominator;
- category/time definitions;
- missing/null semantics;
- whether values are counts, rates, percentages, currency, estimates, or modeled outputs;
- uncertainty/precision available.

If source or metric meaning is ambiguous, stop and resolve it before rendering.

### Stage 2 — State the visual question
Write one sentence: `This chart should help the reader see ___`.

If there are multiple unrelated questions, create separate views rather than forcing one overloaded chart.

### Stage 3 — Validate transformations
Before plotting, explicitly define:
- filters;
- grouping/aggregation;
- normalization/denominator;
- sorting;
- date bucketing/time zone;
- handling of missing/outliers;
- derived metrics/calculations.

Check totals/ranges before and after transformation. Never silently drop records that change the claim.

### Stage 4 — Choose encoding and scales
Use p

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-delegate
description: "Delegate independent subtasks to parallel workers or subagents with strict disjoint ownership, bounded scope, and explicit acceptance contracts. Use when coordinating multiple independent tasks, parallelizing multi-file work without merge conflicts, or managing subagent task assignments — even if the user does not explicitly say \"fable-delegate\" (e.g. \"split this work among workers\", \"delegate these subtasks\", \"run parallel agents\", \"assign independent pieces\"). Do NOT use for tightly coupled sequential tasks or when shared mutable state causes edit collisions."
version: 1.3.0
pack: build
inputs:
  - bounded_cards
requires:
  - disjoint_ownership
produces:
  - delegation_contracts
  - worker_results
gates:
  - ownership_explicit
  - acceptance_explicit
fallback: fable-plan
mutatesWorkspace: true
parallelSafe: true
neural_links:
  precursors:
    - fable-plan
  continuations:
    - fable-execute
    - fable-verify
  lateral_peers:
    - fable-tdd
  recovery: fable-recover
---

# Fable Delegate

Use parallel workers when independence is real, not merely because there are multiple tasks.

## Mission
Delegation should reduce latency without multiplying ambiguity. The parent remains responsible for decomposition, contract stability, integration, and final proof.

A worker is not a place to dump context. It receives one bounded responsibility with enough evidence to act independently and a return contract that makes integration reviewable.

## Activate When
- two or more cards can proceed without waiting for each other's decisions;
- specialist perspectives can investigate independent hypotheses in parallel;
- separate components have stable interfaces and independent acceptance checks;
- independent review/research can be parallelized without shared mutation.

## Do Not Activate When
- workers would change the same unstable contract or invariant;
- one card's design result changes another card's requirements;
- a tiny task costs more to explain/integrate than to execute;
- the parent has not established enough context to write precise worker contracts;
- all workers depend on one unresolved architectural decision.

## Independence Classification
For each candidate pair, classify coupling:

| Coupling | Parallel? | Why |
| --- | --- | --- |
| Different files + different contracts | usually yes | low semantic overlap |
| Different files + shared unstable contract | no | semantic conflict despite path separation |
| Same integration file + separate components | maybe, but serialize integration | component work may parallelize; integration does not |
| Shared read-only evidence | yes | no ownership conflict |
| Same database schema/invariant | usually no | one worker can invalidate another's assumptions |
| Independent research hypotheses | yes | merge conclusions, not source edits |
| Parent decision required by both | no | resolve decision first |

## Delegation Protocol

### Stage 1 — Prove independence
Check:
- write ownership;
- shared contracts/invariants;
- dependency order;
- generated artifacts;
- migration/state coupling;
- integration hotspot;
- whether one worker failure changes another worker's assumptions.

If independence cannot be explained in one short paragraph, do not parallelize yet.

### Stage 2 — Write a worker contract
Each contract includes:
- objective;
- context/evidence already established;
- owned paths or semantic area;
- forbidden scope;
- dependencies assumed stable;
- acceptance evidence to produce;
- expected return packet;
- stop/escalation conditions.

Do not ask a worker to "handle X" with an entire repository and no boundary.

### Stage 3 — Decide mutation ownership
Prefer one writer per semantic area. Multiple read-only investigators may inspect overlapping files; multiple writers should not independently redefine the same contract.

For a shared integration file, assign integration to the parent or one named worker after component work converges.

#

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-discover
description: "Gather the smallest set of repository, environment, documentation, and runtime evidence needed before planning or changing code. Use when load-bearing facts are unknown, tracing execution paths, inspecting unfamiliar packages, or resolving codebase contradictions — even if the user does not explicitly say \"fable-discover\" (e.g. \"explore the codebase\", \"how does this work\", \"where is this implemented\", \"find where this route is handled\"). Do NOT use when the bounded edit is already known (use fable-execute), for external API/version research (use fable-research), or for running existing test suites (use fable-verify)."
version: 1.3.0
pack: core
inputs:
  - exploration_target
requires:
  - codebase_access
produces:
  - repository_evidence
  - execution_path
gates:
  - load_bearing_unknowns_resolved
fallback: fable-recover
mutatesWorkspace: false
parallelSafe: true
neural_links:
  precursors:
    - get-fable
  continuations:
    - fable-research
    - fable-plan
    - fable-execute
  lateral_peers:
    - fable-memory
  recovery: fable-recover
---

# Fable Discover

Build the smallest reliable mental model of an unfamiliar code path before anyone commits to a design or edit.

## Mission
Discovery is not "read a lot of files." It is uncertainty reduction.

The Skill should leave the next specialist with enough evidence to make a decision without rediscovering the repository, while stopping before exploration becomes archaeology.

## Activate When
- entry points, ownership, or execution flow are not known;
- a request spans an unfamiliar package/subsystem;
- generated code, plugins, runtime configuration, queues, jobs, or dependency injection may change the real execution path;
- the user describes behavior but not where it is implemented;
- a previous assumption about the repository has been contradicted.

## Do Not Activate When
- the exact bounded edit and target file are already known;
- the job is purely external API/version research (`fable-research`);
- the task is only to run existing checks (`fable-verify`).

## Situation Classification
Classify the unknown before searching.

| Unknown | First evidence to seek | Common trap |
| --- | --- | --- |
| Topology | manifests, workspace config, package boundaries | assuming root package owns runtime |
| Entry point | CLI/server/job/plugin bootstrap | starting from a similarly named helper |
| Execution path | calls, handlers, events, data transitions | following imports without proving runtime reachability |
| Configuration | env/schema/defaults/feature flags | reading defaults while production overrides them |
| Generated behavior | build scripts, codegen outputs, generated manifests | editing generated output instead of source |
| Plugin/extension path | registration, discovery, loader contracts | missing dynamic loading because grep finds no direct import |
| Persistence/data path | repositories, schemas, transactions, queues | stopping at service layer before side effects |
| Test architecture | harness, fixtures, test entry points | assuming tests exercise the same artifact users run |

## Discovery Protocol

### Stage 1 — Frame the unknowns
Write 2-7 questions whose answers would materially change the plan. Mark each as `load-bearing` or `nice-to-know`.

Examples:
- Which process receives this request?
- Is the package source executed directly or from `dist/`?
- Where is this plugin registered?
- Which storage boundary commits the state?

Do not start broad search until the questions are explicit.

### Stage 2 — Establish repository topology
Read project instructions and manifests first. Identify:
- workspace/package roots;
- build/test commands;
- generated directories;
- host/plugin manifests;
- source vs distribution entry points;
- configuration sources;
- relevant ownership boundaries.

### Stage 3 — Trace a real path
Start from an observable entry point and follow concrete symbols/events toward the target behavior.

For e

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-eval
description: "Evaluate changes to agent prompts, skills, routing policies, and harnesses against reproducible baselines, held-out suites, and regression benchmarks. Use when optimizing agent system prompts, measuring skill triggering accuracy, evaluating routing changes, or running benchmark regressions — even if the user does not explicitly say \"fable-eval\" (e.g. \"benchmark this prompt\", \"evaluate agent behavior\", \"test skill performance\", \"run the eval suite\"). Do NOT use for routine application unit tests (use fable-verify)."
version: 1.3.0
pack: evolution
inputs:
  - candidate_modification
requires:
  - reproducible_baseline
produces:
  - eval_verdict
  - regression_evidence
gates:
  - baseline_frozen
  - holdout_tested
  - rollback_defined
fallback: fable-plan
mutatesWorkspace: false
parallelSafe: true
neural_links:
  precursors:
    - skill-creator
  continuations:
    - fable-plan
    - fable-execute
  lateral_peers:
    - fable-verify
  recovery: fable-recover
---

# Fable Eval

Measure whether an agent-control change improves the behavior it claims to improve without quietly overfitting the benchmark or breaking neighboring behavior.

## Mission
An eval is a decision instrument, not a scoreboard. It needs a frozen comparison point, representative semantic families, oracle isolation, explicit failure costs, and a rollback decision.

A candidate should not win because the prompts resemble its instructions, because holdouts leaked into authoring, or because one average score hides a severe regression.

## Activate When
- changing Skills, prompts, routers, hooks, agent profiles, policies, or model-control logic;
- comparing candidate prompt/agent configurations;
- measuring trigger precision/recall or action compliance;
- validating a new behavioral maturity claim;
- investigating whether an apparent improvement is robust or benchmark-specific.

## Do Not Activate When
- verifying ordinary application behavior (`fable-verify`);
- authoring a Skill before its intended behavior is clear (`skill-creator`);
- running a one-off subjective prompt demo with no acceptance decision.

## Evaluation Classification
| Change | Primary eval risk |
| --- | --- |
| Router/trigger | false positives, false negatives, precedence |
| Skill instruction | action correctness, forbidden shortcuts, boundary behavior |
| Spark/next-action | top-1 action, unsafe suggestion, silence precision |
| Hook/guard | enforcement, false blocking, bypasses |
| Prompt/persona | task quality + regressions + instruction conflicts |
| Tool policy | correct tool choice, unsafe/missing action |
| Model/config | quality/latency/cost variance across representative tasks |

## Protocol
### Stage 1 — Define the decision before running tests
State:
- candidate being evaluated;
- baseline/control;
- exact behavior expected to improve;
- metrics and thresholds;
- unacceptable regressions;
- rollback action.

Avoid inventing metrics after seeing results.

### Stage 2 — Build semantic scenario families
Cover distinct decisions, not wording variants. Include as applicable:
- straightforward positive case;
- non-trigger/boundary case;
- ambiguous competing action;
- adversarial shortcut pressure;
- partial/contradictory evidence;
- failure/recovery path;
- legacy/constrained environment;
- unseen holdout.

Record family coverage separately from raw prompt count.

### Stage 3 — Freeze baseline and corpus identity
Bind the run to:
- corpus hash/version;
- candidate/baseline identity;
- evaluator/scorer version;
- provider/model/config where external;
- timestamp/repository revision.

Changing the subject, oracle, corpus, or scoring logic invalidates direct comparability unless explicitly normalized.

### Stage 4 — Protect the oracle
Provider-facing requests must not reveal expected actions, forbidden actions, category labels, holdout identity, scoring implementation, or answer-bearing metadata.

Do not draft the candidate while repeatedly reading 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-execute
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)."
version: 1.3.0
pack: core
inputs:
  - accepted_card
requires:
  - bounded_scope
produces:
  - implementation_diff
  - card_completion
gates:
  - invariants_preserved
  - acceptance_checked
fallback: fable-plan
mutatesWorkspace: true
parallelSafe: false
neural_links:
  precursors:
    - fable-plan
    - fable-tdd
    - fable-delegate
  continuations:
    - fable-verify
  lateral_peers:
    - fable-simplify
  recovery: fable-recover
---

# Fable Execute

Implement one accepted change without turning a bounded card into an unreviewable wandering session.

## Mission
Execution 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.

"Minimal" means minimal behaviorally complete diff, not necessarily the fewest changed lines.

## Activate When
- scope and acceptance are explicit;
- load-bearing architecture/external facts are settled;
- the card can be implemented without inventing a new public contract;
- the task is a bounded static/config/docs change where TDD adds no meaningful proof;
- a TDD Skill has already established RED and implementation is ready.

## Do Not Activate When
- a behavior change still needs a valid RED (`fable-tdd`);
- implementation reveals a new architecture decision (`fable-plan`);
- a repeated failure needs diagnosis (`fable-recover`);
- the task is to independently verify or review an existing diff (`fable-verify`/`fable-review`).

## Change Classification
Before editing, classify the card:

| Change | Execution concern |
| --- | --- |
| Local behavior | preserve surrounding contract |
| Config/manifest | precedence, generated source, packaging |
| Public API/CLI | compatibility and caller impact |
| Data/persistence | transaction/migration invariant |
| Generated output | edit source/generator, regenerate once |
| Dependency wiring | lifecycle/cleanup/error propagation |
| Repair after TDD | satisfy RED without widening behavior |
| Repair after review | fix only grounded finding + affected proof |

## Protocol

### Stage 1 — Re-read the card against current workspace
Confirm:
- objective;
- owned scope;
- prohibited scope;
- dependencies/assumptions;
- acceptance evidence;
- current git/workspace state.

If the workspace changed since planning in a way that invalidates assumptions, stop and replan rather than force the old card through.

### Stage 2 — Inspect before mutation
Read the exact target code and its immediate contracts/callers/tests. Avoid broad rediscovery, but do not edit from stale memory.

Identify invariants that must stay true during the change.

### Stage 3 — Choose the smallest coherent mutation
Prefer:
- existing repository patterns;
- source-of-truth over generated output;
- local compatibility over speculative abstractions;
- reversible changes when uncertainty remains;
- one behavior change at a time.

### Stage 4 — Mutate and record impact
Track:
- files/surfaces changed;
- new/changed contract;
- generated artifacts affected;
- acceptance command required after this mutation.

If an edit crosses card boundaries, pause and explain why before continuing.

### Stage 5 — Immediate acceptance check
Run the narrowest meaningful acceptance evidence as soon as the coherent mutation exists.

A command

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-handoff
description: "Compact session decisions, durable evidence, open blockers, and exact next actions into structured continuation state for cross-session resumption. Use when pausing a coding session, transferring context to another agent, summarizing long-running work, or creating durable continuation checkpoints — even if the user does not explicitly say \"fable-handoff\" (e.g. \"save context for next session\", \"create a handoff\", \"pause work here\", \"summarize where we left off\"). Do NOT use as a substitute for verifying code changes (use fable-verify)."
version: 1.3.0
pack: delivery
inputs:
  - current_state
requires:
  - session_context
produces:
  - handoff_evidence
  - continuation_state
gates:
  - next_action_explicit
fallback: get-fable
mutatesWorkspace: false
parallelSafe: true
neural_links:
  precursors:
    - fable-release
    - fable-loop
  continuations:
    - get-fable
  lateral_peers:
    - fable-memory
  recovery: fable-recover
---

# Fable Handoff

Leave enough verified context that another agent can resume the work without replaying the whole conversation or rediscovering the repository.

## Mission
A handoff is not a summary. It is a **resumption contract**.

The receiving agent should know what was requested, what was actually changed, which claims are proven, which evidence is stale or missing, what is currently blocked, and the first safe action to take next.

## Activate When
- pausing a long-running task;
- transferring work to another agent/human/session;
- context is becoming too large and needs durable compaction;
- a release/PR remains incomplete but execution must stop;
- an automation/cowork loop needs a durable checkpoint.

## Do Not Activate When
- there is nothing durable to preserve beyond a trivial completed turn;
- the next action itself is unclear because planning/diagnosis is unfinished;
- a handoff would be used to hide missing verification or unresolved failure.

## Continuity Classification
| State | Handoff emphasis |
| --- | --- |
| Clean completed card | exact evidence + next card |
| Dirty worktree | owned vs unrelated changes + safe resume point |
| Failed attempt | reproduction, attempts, revised/remaining hypotheses |
| Review pending | diff/base, findings, verification state |
| Release pending | candidate SHA/version, channel states, external blockers |
| Research/discovery pending | measured facts, unresolved load-bearing questions |
| Delegated work pending | worker ownership, returned/missing packets |

## Protocol
### Stage 1 — Reconstruct the durable task
Capture the original/current user outcome in one concise statement. Separate it from implementation tactics discovered later.

### Stage 2 — Snapshot exact repository/work state
Record when available:
- branch/worktree and candidate commit SHA;
- active card/phase;
- files/surfaces intentionally changed;
- unrelated user changes that must be preserved;
- generated artifacts/state files intentionally not committed;
- open PR/issues/release/tag identifiers.

### Stage 3 — Separate facts, decisions, and guesses
Use distinct buckets:
- **Measured facts**: observed repository/runtime/provider evidence;
- **Decisions**: selected architecture/contract and why;
- **Inferences**: plausible but not yet proven;
- **Rejected hypotheses**: avoid repeating failed reasoning;
- **Unresolved questions**: only those that can change the next action.

### Stage 4 — Record evidence with freshness
For each important claim record:
- command/probe/source;
- result;
- relevant mutation/commit/artifact;
- whether it is **fresh**, **stale**, or **not checked**.

Never turn `NOT_CHECKED` into prose that sounds like PASS.

### Stage 5 — Record failures and attempted repairs
Include only attempts that teach the receiver something. State what was tried, what happened, and why that changed or did not change the hypothesis.

### Stage 6 — State blockers precisely
A blocker must say what external fact/permission/environment is m

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-loop
description: "Execute bounded recurring polling loops, CI build babysitting, interval-based status monitors, and self-paced test cycles with explicit timeouts and backoff. Use when monitoring async CI/CD pipelines, polling external service status, running interval test watches, or tracking long-running jobs — even if the user does not explicitly say \"fable-loop\" (e.g. \"babysit this build\", \"poll until completed\", \"watch CI status\", \"wait for deployment\"). Do NOT use for synchronous one-shot commands or unbounded infinite polling loops."
version: 1.3.0
pack: system
inputs:
  - loop_condition
requires:
  - exit_criteria
produces:
  - loop_receipt
gates:
  - budget_bounded
  - exit_condition_explicit
fallback: fable-recover
mutatesWorkspace: false
parallelSafe: true
neural_links:
  precursors:
    - fable-run
  continuations:
    - fable-verify
    - fable-handoff
  lateral_peers:
    - fable-run
  recovery: fable-recover
---

# Fable Loop

Repeat a check only when repetition can reveal new state, with explicit termination, backoff, error classification, and zero ambiguity about why the loop stopped.

## Mission
Polling is not "run the same command until it turns green." A good loop models a changing external condition, distinguishes pending from failure, respects rate/cost budgets, and terminates on success, terminal failure, cancellation, or exhausted budget.

If repeated execution cannot produce new information, the task belongs in diagnosis—not a loop.

## Activate When
- waiting for CI/deployment/build/batch-job state to change;
- monitoring a bounded asynchronous operation;
- checking eventually-consistent external state;
- repeating a safe measurement while a known process progresses;
- running a finite stabilization sample where repetition itself is the measurement.

## Do Not Activate When
- one command/probe is enough (`fable-run`/`fable-verify`);
- the same deterministic failure is repeating with no external state change (`fable-recover`);
- user expects a future notification/scheduled task rather than an in-session bounded loop;
- polling would create repeated non-idempotent side effects;
- no termination criteria or budget can be defined.

## Loop Classification
| Loop type | Success/terminal semantics |
| --- | --- |
| CI/build | pending → success or terminal failure/cancelled |
| Deployment | progressing → healthy/rolled back/failed |
| Batch job | queued/running → completed/failed |
| Eventual consistency | old state → expected state within deadline |
| Rate-limited API | pending/retryable → success or terminal auth/schema error |
| Stabilization sampling | N bounded observations → distribution/variance verdict |

## Protocol
### Stage 1 — Define the state machine
Before iteration, enumerate:
- success state;
- pending/retryable states;
- terminal failure states;
- malformed/unknown states;
- cancellation condition.

A loop that treats every non-success as "try again" is unsafe.

### Stage 2 — Set budgets
Define at least:
- maximum elapsed time/deadline;
- maximum iterations or request budget where relevant;
- initial interval/backoff policy;
- maximum interval;
- API/cost/rate constraints.

Use the stricter bound when several apply.

### Stage 3 — Check idempotency and side effects
Polling operation should be read-only/idempotent. If the endpoint/command triggers work, separate trigger from status observation and ensure retries cannot duplicate the action.

### Stage 4 — Execute one iteration and classify result
Record:
- iteration/time;
- observed state/value;
- transport/command result;
- classification: success / pending / retryable error / terminal failure / unknown;
- next delay/reason.

### Stage 5 — Apply backoff intelligently
Use a fixed interval when the expected update cadence is known and inexpensive; exponential/backoff+jitter when rate limits/transient service errors matter.

Respect explicit `Retry-After`/provider guidance where applicable. Do not make sub-second aggre

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-memory
description: "Manage persistent file-based memory, indexing cross-session user preferences, feedback, and architectural constraints in structured MEMORY.md stores. Use when recording user feedback, storing project conventions, recalling cross-session architectural constraints, or indexing durable project memory — even if the user does not explicitly say \"fable-memory\" (e.g. \"remember this preference\", \"save to memory\", \"what are my project rules\", \"recall user feedback\"). Do NOT use for volatile task state stored in .fable/state.json."
version: 1.3.0
pack: system
inputs:
  - memory_fact
requires:
  - fact_metadata
produces:
  - memory_record
  - updated_index
gates:
  - single_fact_file
  - index_synced
fallback: fable-discover
mutatesWorkspace: true
parallelSafe: true
neural_links:
  precursors:
    - fable-discover
  continuations:
    - fable-plan
    - fable-discover
  lateral_peers:
    - fable-handoff
  recovery: fable-recover
---

# Fable Memory

Persist only facts that deserve to survive the session, with provenance and contradiction handling strong enough that old memory does not silently become a new source of error.

## Mission
Memory is not a chat archive. It should reduce rediscovery without freezing temporary guesses into permanent instructions.

A durable record needs scope, provenance, confidence, freshness, and a way to be superseded when the user or repository changes.

## Activate When
- the user explicitly asks to remember a durable preference/constraint;
- a stable project convention or architectural decision will materially affect future work;
- cross-session continuity repeatedly depends on the same fact;
- a prior durable fact needs correction, supersession, or retrieval.

## Do Not Activate When
- the information is temporary execution state (`.fable/state`, ledger, handoff);
- it is a one-off conversational detail unlikely to affect future decisions;
- it is a guess/inference not yet stable enough to persist;
- it contains a password, token, private key, session cookie, or other secret.

## Memory Classification
| Type | Example | Durability rule |
| --- | --- | --- |
| User preference | preferred package manager | persist when explicit/stable |
| Project constraint | runtime Bun >=1.3 | bind to project/source |
| Architecture decision | use outbox for events | store rationale + supersession path |
| Repeated workflow rule | verify package clean-install before release | persist if project-specific and durable |
| External fact | API behavior/version | usually cite/research at use time; avoid timeless storage |
| Temporary state | current failing test | handoff/state, not memory |
| Sensitive credential | API token | never memory |

## Protocol
### Stage 1 — Decide whether it deserves memory
Ask:
- will this likely matter in another session?
- is it stable, explicit, or source-backed?
- is there a narrower existing record to update?
- could persistence create privacy/security risk?

If not durable, leave it in current context/handoff only.

### Stage 2 — Normalize the fact
Store one coherent decision/fact with:
- canonical statement;
- scope (user/project/repo/subsystem);
- type;
- source/provenance;
- confidence/status;
- created/updated timestamp if supported;
- supersedes/superseded-by relation when relevant.

### Stage 3 — Check conflicts before write
Search for existing records with same subject. Compare:
- exact agreement → update provenance/freshness rather than duplicate;
- narrower/wider scope → preserve both only if scopes are genuinely different;
- contradiction → do not keep two active truths; resolve or mark conflict explicitly.

### Stage 4 — Write atomically and index
Update one canonical fact record and synchronize index/catalog. Preserve unrelated records.

### Stage 5 — Validate retrieval meaning
Read back the record as a future agent would. Ensure it does not overgeneralize:
- `use Bun in get-fable` is not `user always uses Bun everywhere`;
- `API v4 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-plan
description: "Convert discovery evidence into bounded, testable work cards with explicit acceptance criteria and architectural invariants. Use when designing multi-file features, planning complex refactors, decomposing architectural migrations, or structuring multi-step implementation tasks — even if the user does not explicitly say \"fable-plan\" (e.g. \"plan this feature\", \"design the architecture\", \"break this task down\", \"create an implementation plan\"). Do NOT use when load-bearing facts remain unknown (use fable-discover first) or for trivial single-scope bug fixes (use fable-tdd or fable-execute)."
version: 1.3.0
pack: core
inputs:
  - requirements
  - evidence
requires:
  - load_bearing_unknowns_resolved
produces:
  - accepted_card
  - acceptance_condition
gates:
  - bounded_scope
  - named_acceptance
fallback: fable-discover
mutatesWorkspace: false
parallelSafe: false
neural_links:
  precursors:
    - fable-discover
    - fable-research
  continuations:
    - fable-tdd
    - fable-delegate
    - fable-execute
  lateral_peers:
    - fable-config
  recovery: fable-recover
---

# Fable Plan

Turn grounded evidence into an executable change strategy with explicit dependencies, risk boundaries, acceptance proof, and integration ownership.

## Mission
A plan is not a list of files to edit. It is a set of decisions that makes implementation boring enough to execute safely.

The planner should remove architectural uncertainty, expose order constraints, define what "done" means, and separate work only where the pieces can genuinely be reasoned about and verified independently.

## Activate When
- the task spans multiple files/components or introduces a new contract;
- a migration, schema change, public API change, or cross-package refactor is required;
- implementation requires sequencing or rollback reasoning;
- parallel workers may help but ownership/integration must be designed;
- requirements are understood but not yet decomposed into verifiable work.

## Do Not Activate When
- load-bearing facts are still unknown (`fable-discover`/`fable-research`);
- the change is truly bounded to one obvious edit with clear acceptance (`fable-execute`);
- the immediate job is to reproduce a behavior in a test (`fable-tdd`).

## Change Classification
Classify before decomposing.

| Change type | Main planning concern |
| --- | --- |
| Bounded behavior | acceptance and regression surface |
| Cross-module feature | contracts + integration points |
| Refactor | invariant preservation + staged compatibility |
| Data/schema migration | forward/backward compatibility + rollback |
| Public API/CLI | compatibility + versioning + docs/tests |
| Dependency upgrade | behavior delta + transitive risk |
| Security-sensitive | trust boundaries + fail-closed behavior |
| Release/distribution | artifact boundaries + external verification |

## Planning Protocol

### Stage 1 — Restate the contract
Capture:
- requested outcome;
- non-goals;
- evidence already established;
- externally visible behavior that must not regress;
- unresolved items and why they are non-blocking.

If a blocking unknown remains, stop and route back to discovery/research.

### Stage 2 — Map the change graph
Identify:
- components touched;
- contracts between them;
- data/state transitions;
- migration or compatibility edges;
- shared integration hotspots;
- generated artifacts and their sources;
- verification surfaces.

Represent ordering as dependencies, not just numbered tasks.

### Stage 3 — Choose seams for decomposition
A card should have one coherent reason to change and one clear acceptance story.

Do **not** require disjoint files as a universal rule. Two cards may touch one integration file sequentially if ownership/order is explicit. Conversely, two cards touching different files may still be unsafe to parallelize if they change one shared invariant or contract.

### Stage 4 — Plan risk-first
Move high-uncertainty or irreversible decisions ea

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-recover
description: "Diagnose repeated command failures, stale build caches, branch drift, or contradictory evidence before attempting further code edits. Use when commands fail repeatedly, tests stay red after attempted fixes, build output contradicts source code, or the execution path is confused — even if the user does not explicitly say \"fable-recover\" (e.g. \"still failing\", \"why did this fail again\", \"stuck in a failure loop\", \"diagnose this error\"). Do NOT use for routine first-time test failures in fresh TDD (use fable-tdd)."
version: 1.3.0
pack: core
inputs:
  - failure_evidence
requires:
  - failure_streak
produces:
  - revised_hypothesis
  - bounded_repair
gates:
  - diagnosis_changed
fallback: fable-discover
mutatesWorkspace: false
parallelSafe: false
neural_links:
  precursors:
    - fable-tdd
    - fable-execute
    - fable-verify
  continuations:
    - fable-discover
    - fable-plan
    - fable-execute
  lateral_peers:
    - fable-discover
  recovery: fable-discover
---

# Fable Recover

Stop spending mutations on a failing hypothesis. Rebuild causal confidence before changing code again.

## Mission
Recovery exists for the moment an agent is most likely to become expensive and irrational: the same task has failed more than once, output contradicts expectations, or edits appear to have no effect.

The goal is not to "try something different." The goal is to explain why previous attempts failed, falsify competing causes, and issue one repair that is justified by new evidence.

## Activate When
- the same command/test/behavior fails after two materially similar implementation attempts;
- output appears stale or unaffected by known source changes;
- tests/runtime disagree;
- evidence contradicts a load-bearing assumption;
- failures alternate or depend on timing/environment;
- the agent is about to repeat a command/patch without new diagnostic information.

## Do Not Activate When
- first failure is a trivial syntax/type error introduced by the current edit;
- architecture is simply unknown and no repeated failure occurred (`fable-discover`);
- expected RED in TDD is being observed correctly;
- a narrow review finding already has an obvious bounded repair.

## Failure Classification
Start by classifying the evidence, not the code.

| Class | Typical signals | First probes |
| --- | --- | --- |
| Harness | assertion never reached, fixture/mock/setup error | prove test path and fixture |
| Environment | local/CI/OS/env-specific | versions, env, cwd, permissions |
| Artifact/cache | source changes not reflected | entrypoint, build timestamps, cache, dist |
| Execution path | edited code never executes | tracing/instrumentation/registration |
| Dependency/version | unexpected API/runtime semantics | lockfile, resolved version, official source |
| Data/state | only some fixtures/accounts/orders fail | minimal failing state, persistence boundaries |
| Concurrency/timing | intermittent/order-sensitive | deterministic coordination, shared state |
| Product logic | harness/path proven, assertion consistently wrong | isolate algorithm/branch |
| Invariant/design | local fixes move failure elsewhere | identify violated cross-component rule |

Do not jump to product logic until cheaper external explanations are falsified.

## Recovery Protocol

### Stage 1 — Freeze mutation
No new production edits until the diagnosis changes. Preserve the failing state and collect exact evidence.

Record:
- command/action;
- exact error/output;
- workspace/commit/mutation generation;
- attempts already made and what differed;
- expected observation.

### Stage 2 — Reproduce minimally
Find the smallest reliable reproduction. If the failure is flaky, capture seeds/order/time/environment and work on determinism before another fix.

### Stage 3 — Build a hypothesis queue
Create 2-5 plausible causes ranked by:
- ability to explain all observed evidence;
- probability given recent changes;
- cost/safety of falsification.

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-release
description: "Audit and certify repository merge and release readiness against required quality gates, clean git working trees, and verified distribution artifacts. Use when preparing a release tag, validating release checklist criteria, publishing npm/PyPI packages, or certifying a branch for merge — even if the user does not explicitly say \"fable-release\" (e.g. \"prepare the release\", \"is this ready to merge\", \"ship to production\", \"publish the package\"). Do NOT use when verification is stale, failing, or missing (use fable-verify first)."
version: 1.3.0
pack: delivery
inputs:
  - completion_evidence
requires:
  - clean_worktree
produces:
  - release_readiness
gates:
  - required_checks_pass
  - no_blocking_findings
fallback: fable-verify
mutatesWorkspace: false
parallelSafe: false
neural_links:
  precursors:
    - fable-verify
    - fable-review
    - fable-security
  continuations:
    - fable-handoff
  lateral_peers:
    - fable-handoff
  recovery: fable-recover
---

# Fable Release

Prove that the exact commit and artifact users will receive are ready to ship, then distinguish readiness from actual distribution.

## Mission
A release is an external state transition. Source tests can be perfect while the package omits files, the tag points at another commit, the registry still serves an old version, or a published artifact cannot start in a clean environment.

This Skill closes that gap by tying release claims to exact version, commit, artifact, workflow, tag, and registry evidence.

## Activate When
- preparing a branch for merge or a version for release;
- creating/pushing a version tag;
- publishing npm/package/plugin artifacts;
- finalizing a GitHub Release;
- verifying that a distribution channel actually serves the intended version;
- assessing whether release evidence is current after last-minute changes.

## Do Not Activate When
- implementation is still changing (`fable-execute`/`fable-tdd`);
- functional verification is incomplete (`fable-verify`);
- blocking review/security findings remain;
- the user has not authorized an irreversible publish action. Readiness checks may run; publishing itself requires the applicable authorization.

## Release Classification

| Release type | Extra concerns |
| --- | --- |
| Merge only | branch/base freshness, required CI, review |
| Package registry | package contents, clean install, registry verification |
| Git tag/GitHub Release | tag→SHA binding, notes/assets, draft/prerelease state |
| Plugin/marketplace | manifest/version parity, submission/approval state |
| Migration-bearing release | rollout order, backward compatibility, rollback |
| Security-sensitive release | advisory/secrets/dependency gates, disclosure constraints |

## Protocol

### Stage 1 — Freeze the candidate
Identify the exact candidate:
- version;
- commit SHA;
- target branch/tag;
- distribution channels;
- required CI/review/security evidence.

Any source/config/package mutation after this point invalidates relevant release evidence and creates a new candidate.

### Stage 2 — Validate version semantics
Check:
- version does not already exist in target registry/tag namespace;
- SemVer matches actual compatibility impact;
- all canonical version locations/manifests agree;
- changelog/release notes describe user-visible changes accurately;
- prerelease state is intentional.

Do not choose patch/minor/major purely for convenience.

### Stage 3 — Reconfirm fresh quality gates
Verify required functional/build/review/security evidence belongs to the candidate SHA/mutation generation. If evidence was produced before candidate changes, rerun it.

### Stage 4 — Inspect the artifact boundary
Build/dry-run the exact artifact and inspect its manifest/content.

Check:
- required entrypoints/assets/manifests are present and non-empty;
- secrets, temp files, tests/fixtures/internal holdouts are excluded unless intentionally public;
- generated files are current;
- executable permission

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-research
description: "Resolve current external facts, official documentation, library behaviors, and API contracts against primary sources before implementation. Use when consulting library documentation, checking breaking changes, investigating external APIs, or verifying framework versions — even if the user does not explicitly say \"fable-research\" (e.g. \"check the latest docs\", \"what is the API for X in version Y\", \"look up SDK specs\", \"verify library support\"). Do NOT use for repository-local code exploration (use fable-discover) or for writing implementation code directly (use fable-tdd or fable-execute)."
version: 1.3.0
pack: intelligence
inputs:
  - research_query
requires:
  - primary_sources
produces:
  - research_evidence
  - source_backed_facts
gates:
  - primary_source_grounding
fallback: fable-discover
mutatesWorkspace: false
parallelSafe: true
neural_links:
  precursors:
    - fable-discover
  continuations:
    - fable-plan
    - fable-tdd
    - fable-execute
  lateral_peers:
    - fable-discover
  recovery: fable-recover
---

# Fable Research

Resolve external facts that can change the implementation, using current primary evidence instead of model memory.

## Mission
Research is not link collection. The output must be a decision-ready statement tied to the exact version, environment, or contract the repository will use.

## Activate When
- SDK/API signatures, limits, defaults, lifecycle semantics, or compatibility may have changed;
- a design depends on current cloud/provider behavior;
- the repository pins a version that may differ from current docs;
- multiple official sources appear to disagree;
- an error may come from a documented breaking change or deprecation;
- a standard/RFC/security requirement must be interpreted precisely.

## Do Not Activate When
- the fact is repository-local (`fable-discover`);
- the implementation is already grounded and only needs execution (`fable-execute`/`fable-tdd`);
- the task is general brainstorming where no external claim changes the decision.

## Research Classification
Classify the question first.

| Question type | Best primary evidence | Extra risk |
| --- | --- | --- |
| API signature | versioned official docs + source/types | docs may show latest, repo pins older |
| Runtime behavior | official docs + upstream implementation/tests | marketing docs may omit edge behavior |
| Compatibility | release notes/changelog + version matrix | transitive dependency constraints |
| Standard/protocol | normative spec/RFC | examples may be non-normative |
| Cloud/product limit | current vendor docs | region/tier/account differences |
| Security guidance | official security docs/advisories | stale blog summaries |
| Deprecation/migration | migration guide + release notes | old and new APIs coexist |

## Protocol

### Stage 1 — Turn the task into answerable claims
Break a broad request into the smallest external claims that can affect design.

Bad: "Research the new SDK."

Good:
- Does version 4.2 expose streaming tool-call deltas?
- Which parameter enables them?
- Is the callback ordered?
- What minimum runtime version is required?

### Stage 2 — Bind to repository reality
Before accepting current docs as applicable, record:
- package/version actually used;
- runtime/language version;
- relevant feature flags/tier/region if applicable;
- whether the repository uses generated types or a wrapper that changes the public contract.

### Stage 3 — Use a source hierarchy
Prefer, in order when available:
1. normative specification or official versioned reference;
2. official upstream source/types/tests;
3. official release notes/migration guides/advisories;
4. vendor examples authored for the relevant version;
5. secondary sources only as leads.

Never use an unsourced search snippet as final evidence.

### Stage 4 — Reconcile version and source conflicts
If latest docs disagree with the pinned package:
- inspect versioned docs/release notes/source for the pin

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-review
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)."
version: 1.3.0
pack: proof
inputs:
  - implementation_diff
requires:
  - target_scope
produces:
  - review_evidence
  - review_verdict
gates:
  - grounded_diff_read
  - actionable_findings
fallback: fable-recover
mutatesWorkspace: false
parallelSafe: true
neural_links:
  precursors:
    - fable-verify
  continuations:
    - fable-security
    - fable-release
  lateral_peers:
    - fable-security
  recovery: fable-recover
---

# Fable Review

Review the change as an independent engineer trying to find plausible defects, not as the implementer explaining why the patch is probably fine.

## Mission
A 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.

The reviewer should be skeptical without manufacturing noise.

## Activate When
- a diff/PR/implementation is ready for independent inspection;
- verification is green but human/semantic risks remain;
- repository conventions or public contracts may have been violated;
- a release/merge needs grounded review evidence.

## Do Not Activate When
- no diff or concrete change exists;
- the main task is automated execution evidence (`fable-verify`);
- the requested work is threat modeling/security specialization (`fable-security`);
- blocking behavior is already known and needs implementation (`fable-execute`).

## Review Classification
Classify the change because different diffs deserve different review depth.

| Change | Primary review focus |
| --- | --- |
| Bug fix | root cause, regression test, adjacent paths |
| New feature | contract, error states, lifecycle, compatibility |
| Refactor | invariant preservation, accidental behavior delta |
| Concurrency | ordering, shared state, cleanup, race/deadlock |
| Persistence/migration | partial failure, transactions, compatibility, rollback |
| Public API/CLI | callers, defaults, error/exit behavior, versioning |
| Dependency upgrade | changed semantics, transitive behavior, config |
| Packaging/build | exports, artifact contents, generated files, runtime entrypoints |

## Review Protocol

### Stage 1 — Reconstruct intent independently
Read:
- user/issue/card acceptance;
- diff against the correct base;
- relevant existing contracts/tests/instructions.

State the intended behavior in your own words before judging the implementation.

### Stage 2 — Read the whole diff, then trace risky changes
Do not review isolated snippets only. Identify:
- public/observable behavior delta;
- state/data-flow delta;
- control-flow/error delta;
- lifecycle/resource delta;
- concurrency delta;
- config/generated/package delta.

Trace important changes into callers/callees where a local diff cannot establish correctness.

### Stage 3 — Check invariants and failure paths
For each material change ask:
- What must remain true before/after?
- What happens on invalid input?
- What happens when dependency call fails/partially succeeds?
- Are cleanup/rollback paths complete?
- Can retries duplicate side effects?
- Can async work outlive ownership/lifecycle?
- Can old/new formats/callers coexist?

### Stage 4 — Check tests as evidence, not decoration
Ask:
- Does a test fail on the pre-fix bug/old behavior where appropriate?
- Does it exercise the real changed boundary?
- Are important negative/error/concurrency/compatibility paths missing?
- W

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-run
description: "Launch, manage, and verify live applications across CLI binaries, web servers, TUIs, Electron apps, and background daemons with readiness probes and clean teardown. Use when starting development servers, executing live smoke tests, testing interactive CLI binaries, or driving runtime smoke verification — even if the user does not explicitly say \"fable-run\" (e.g. \"start the dev server\", \"launch the app\", \"test the running CLI\", \"smoke test the web app\"). Do NOT use for static analysis or unit testing without a running process (use fable-verify)."
version: 1.3.0
pack: system
inputs:
  - app_target
requires:
  - built_artifact
produces:
  - runtime_evidence
  - smoke_proof
gates:
  - process_clean_exit
  - status_200
fallback: fable-recover
mutatesWorkspace: false
parallelSafe: false
neural_links:
  precursors:
    - fable-dataviz
    - fable-execute
  continuations:
    - fable-verify
    - fable-release
  lateral_peers:
    - fable-verify
  recovery: fable-recover
---

# Fable Run

Execute the real artifact in a bounded environment and collect runtime evidence without confusing "process started" with "application works."

## Mission
Runtime work needs lifecycle ownership: exact command/artifact, working directory, environment, ports, readiness criteria, output bounds, timeout, and cleanup.

A server PID, HTTP 200 from the wrong process, or CLI exit 0 that never exercised the feature is not sufficient proof.

## Activate When
- a server/service must run to verify behavior;
- a built/published CLI or executable needs a smoke test;
- browser/runtime integration requires a live process;
- a runtime path differs materially from unit-test/source execution;
- verification needs empirical entrypoint/lifecycle evidence.

## Do Not Activate When
- unit/integration tests can prove behavior without a persistent live process (`fable-verify`);
- code still needs implementation (`fable-execute`);
- repeated runtime failure/staleness needs diagnosis (`fable-recover`);
- launching the process would cause an unauthorized/destructive external side effect.

## Runtime Classification
| Target | Important controls |
| --- | --- |
| one-shot CLI | cwd/env/args, exit, stdout/stderr, side effects |
| HTTP server | port ownership, readiness, health vs feature probe, cleanup |
| worker/daemon | startup readiness, queue/input fixture, termination |
| browser app | server URL, browser readiness, console/network errors |
| packaged binary | exact artifact/version/path, clean environment |
| multi-service | dependency startup order, ports, teardown, correlation |

## Protocol
### Stage 1 — Identify the exact artifact
Record:
- command/binary path;
- version/hash/build if relevant;
- cwd;
- required environment/config;
- expected process type;
- safe input/probe;
- destructive/external side effects to avoid.

Do not assume `foo` on PATH is the artifact just built—resolve it when identity matters.

### Stage 2 — Establish resource ownership
Before launch determine:
- requested/available port;
- whether an existing process owns it;
- temp directories/files;
- child-process behavior;
- timeout/budget;
- cleanup method.

Never kill an unrelated process merely to acquire a preferred port.

### Stage 3 — Launch with bounded observation
Capture PID/process handle, stdout/stderr, startup errors, and timestamps. Use output/timeout limits so a noisy/hung service cannot consume unbounded resources.

### Stage 4 — Distinguish startup from readiness
A successful spawn only means the OS accepted the process.

Readiness may require:
- port accepting connections;
- health endpoint with expected payload;
- dependency initialization complete;
- CLI command reaches expected branch;
- browser page loads without fatal console/runtime errors.

Use a bounded readiness loop with backoff rather than a fixed arbitrary sleep when possible.

### Stage 5 — Probe the behavior that matters
Health 200 proves health only. If the changed feature is 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-security
description: "Conduct threat modeling, vulnerability assessments, secret sanitization, and security reviews across trust boundaries, auth flows, and untrusted inputs. Use when auditing authentication/authorization logic, inspecting APIs for injection/CORS/CSRF risks, checking for hardcoded credentials, or reviewing security-sensitive diffs — even if the user does not explicitly say \"fable-security\" (e.g. \"security audit this code\", \"check for vulnerabilities\", \"verify auth logic\", \"scan for leaked secrets\"). Do NOT use for general style reviews (use fable-review) or non-security bug fixes (use fable-tdd)."
version: 1.3.0
pack: proof
inputs:
  - security_scope
requires:
  - threat_boundary
produces:
  - security_evidence
  - threat_boundary_verdict
gates:
  - threat_surface_checked
  - no_exposed_secrets
fallback: fable-plan
mutatesWorkspace: false
parallelSafe: true
neural_links:
  precursors:
    - fable-verify
    - fable-review
  continuations:
    - fable-release
  lateral_peers:
    - fable-review
  recovery: fable-recover
---

# Fable Security

Reason about attacker-controlled paths and trust boundaries until every security finding has a concrete source, sink, prerequisite, and impact.

## Mission
Security review is not a secret scan plus a generic checklist. It asks what an attacker can control, which privilege/data boundary that input can cross, what enforcement must hold, and whether the changed code preserves that property under failure and concurrency.

A clean scanner is evidence about scanner coverage, not a proof that the design is secure.

## Activate When
- authentication, authorization, sessions, tokens, permissions, tenancy, or privileged actions change;
- untrusted input reaches parsers, queries, templates, files, URLs, shells, webhooks, or deserializers;
- secrets/credentials or cryptographic material are handled;
- a diff changes trust boundaries, network exposure, storage access, package/install logic, or sandboxing;
- a reported vulnerability/finding needs validation or severity calibration;
- repository/package supply-chain behavior needs security review.

## Do Not Activate When
- the task is only functional verification with no security question (`fable-verify`);
- a generic maintainability review has no trust-boundary impact (`fable-review`);
- a vulnerability is already validated and the user wants only a bounded fix (`fable-execute`, while preserving security acceptance).

## Security Work Classification
| Mode | Primary question |
| --- | --- |
| Threat model | what assets/actors/boundaries/abuse paths exist? |
| Security diff review | what security property changed in this diff? |
| Finding validation | can attacker-controlled data actually reach a sensitive sink? |
| Repository audit | which exposed surfaces deserve deeper inspection? |
| Secret hygiene | can sensitive values enter source/logs/artifacts? |
| Supply-chain/package | can dependency/install/build boundaries be abused? |

## Protocol
### Stage 1 — Define assets, actors, and trust boundaries
Identify:
- protected assets/data/operations;
- authenticated/unauthenticated/privileged actors;
- tenant/user ownership boundaries;
- external systems/webhooks/plugins;
- process/filesystem/network privilege transitions.

Security conclusions without a named boundary are usually too vague.

### Stage 2 — Trace attacker-controlled input to effect
For each relevant entrypoint follow:
`source → parsing/normalization → validation → authorization → transformation → sensitive sink/side effect`

Record where each security property is enforced and whether later transformations can invalidate earlier validation.

### Stage 3 — Check the property appropriate to the boundary
Consider as relevant:
- authentication vs authorization separation;
- object/tenant ownership (IDOR/BOLA);
- CSRF/state binding and redirect validation;
- injection/query/template/shell boundaries;
- path traversal/symlink/archive extraction;
- SSRF an

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: fable-simplify
description: "Refactor and simplify settled, recently modified code to improve readability, remove dead branches, flatten deeply nested logic, and reduce duplication while preserving behavior. Use when cleaning up complex functions, eliminating boilerplate, deduplicating logic, or improving code altitude after tests pass — even if the user does not explicitly say \"fable-simplify\" (e.g. \"simplify this code\", \"clean up this function\", \"refactor this logic\", \"make this cleaner\"). Do NOT use when tests are failing (use fable-recover) or for speculative architectural rewrites (use fable-plan)."
version: 1.3.0
pack: system
inputs:
  - target_module
requires:
  - passing_tests
produces:
  - simplified_diff
gates:
  - behavior_preserved
  - tests_pass
fallback: fable-verify
mutatesWorkspace: true
parallelSafe: false
neural_links:
  precursors:
    - fable-execute
  continuations:
    - fable-verify
    - fable-review
  lateral_peers:
    - fable-execute
  recovery: fable-recover
---

# Fable Simplify

Reduce accidental complexity while proving the externally relevant behavior and contracts did not change.

## Mission
Simplification is not permission for a broad rewrite. It should make the code easier to reason about through small, reviewable transformations backed by characterization/invariant evidence.

"Cleaner" is subjective. Behavior preservation, reduced duplication/branching/indirection, and clearer ownership can be demonstrated.

## Activate When
- duplicated logic creates divergence risk;
- nested/control-flow complexity obscures invariants;
- dead code/obsolete indirection is proven unused;
- a refactor is explicitly requested with no intended behavior change;
- a completed implementation needs bounded cleanup before review.

## Do Not Activate When
- user-visible behavior/API/schema is intended to change (`fable-tdd`/`fable-execute`);
- behavior is not characterized well enough to preserve;
- architecture itself is being redesigned (`fable-plan`);
- a cleanup opportunity is unrelated to the active card.

## Simplification Classification
| Smell | Safe first move |
| --- | --- |
| duplicated behavior | prove equivalence, extract shared rule |
| nested branching | identify decision table/invariants, flatten incrementally |
| dead code | prove no runtime/registration/reflection reachability |
| wrapper/indirection | prove callers/semantics before collapse |
| data transformation chain | characterize representative + boundary inputs |
| public/internal API clutter | preserve public contract; simplify behind boundary |
| generated code noise | change generator/source, not output manually |

## Protocol
### Stage 1 — Establish preservation contract
State what must not change:
- public inputs/outputs/errors;
- side effects/state transitions;
- serialization/order/timing where contractual;
- package/API/CLI compatibility;
- performance requirements if material.

Capture baseline tests/fixtures/runtime evidence. If coverage is weak, add characterization before structural mutation.

### Stage 2 — Identify the complexity to remove
Name it concretely: duplicated condition, unnecessary branch, dead adapter, repeated parsing, ownership split, obsolete compatibility path.

Avoid "modernize this module" as an unbounded objective.

### Stage 3 — Prove reachability/deadness before deletion
Search callers plus dynamic registration/plugin/reflection/generated paths. "grep found no import" is not enough for code that may load dynamically.

### Stage 4 — Refactor one semantic step at a time
Examples:
- extract a shared pure rule;
- replace nested branch with explicit guard/decision table;
- collapse wrapper whose contract is identical;
- remove dead branch after reachability proof.

Run the narrow preservation checks after each meaningful step.

### Stage 5 — Watch for accidental contract changes
Review diff for:
- changed exception/error type/message relied on by callers;
- iteration/order changes;
- truthiness

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-simulator
description: "Verify complex code changes against independent mathematical oracles, derived specifications, headless browser environments, and isolated sandbox states. Use when deriving independent verification oracles, testing algorithms against reference models, verifying UI with headless browsers, or testing state transitions in sandboxes — even if the user does not explicitly say \"fable-simulator\" (e.g. \"simulate this workflow\", \"verify with an independent oracle\", \"headless browser check\", \"derive a test oracle\"). Do NOT use for simple unit test runs (use fable-verify)."
version: 1.3.0
pack: system
inputs:
  - verification_target
requires:
  - independent_oracle
produces:
  - oracle_evidence
  - causal_verification_matrix
gates:
  - oracle_independent
  - untracked_files_preserved
fallback: fable-verify
mutatesWorkspace: false
parallelSafe: false
neural_links:
  precursors:
    - fable-verify
  continuations:
    - fable-verify
    - fable-review
  lateral_peers:
    - fable-verify
  recovery: fable-recover
---

# Fable Simulator

Create an independent model of expected behavior and compare it with the candidate without pretending the simulation itself is production evidence.

## Mission
Simulation is useful when ordinary tests risk sharing the same assumptions as the implementation, when a UI/agent flow needs controlled playthrough, or when failure injection can expose paths that are hard to reproduce safely.

The Skill must preserve a hard boundary between **simulated/oracle evidence** and **real runtime verification**.

## Activate When
- an algorithm/rewrite needs an independently derived oracle;
- a contract is implicit across callers and needs reconstruction;
- UI/agent state transitions benefit from scripted playthrough/failure injection;
- testing destructive/rare conditions safely requires a model/sandbox;
- differential testing between two independent implementations is valuable.

## Do Not Activate When
- normal tests/runtime evidence already proves the claim cheaply;
- the proposed oracle is derived from the same code/assumptions under test;
- simulation would be reported as proof that an external production system actually behaved that way.

## Simulation Classification
| Mode | Independence requirement |
| --- | --- |
| Golden fixtures | fixture expected outputs come from trusted contract/observations |
| Reference implementation | independently written/maintained logic |
| Differential provider/model | separate implementation/model with blinded oracle |
| State-machine simulation | transitions/invariants defined from product contract |
| Failure injection | controlled faults with explicit modeled assumptions |
| UI playthrough | browser actions + observable DOM/network/runtime evidence |

## Protocol
### Stage 1 — Define the claim and oracle independence
State what candidate behavior is being checked and why the oracle does not simply repeat candidate logic.

List shared assumptions. If a shared assumption could cause both candidate and oracle to be wrong identically, record that coverage gap.

### Stage 2 — Derive contract from independent sources
Use public interfaces, callers, specs, historical golden outputs, primary docs, or separately maintained reference behavior. Avoid reading implementation details solely to recreate the same algorithm.

### Stage 3 — Build representative and edge corpus
Include normal, boundary, invalid, stateful, adversarial, and failure cases relevant to the claim. Preserve user/untracked workspace files and run in isolated temp/sandbox locations where possible.

### Stage 4 — Execute candidate and oracle separately
Capture inputs, outputs, errors, side effects/state transitions, timing only when required, and tool/environment identity.

### Stage 5 — Compare semantically
Normalize only differences that the contract declares irrelevant. Do not normalize away a real behavioral difference just to reach zero diff.

For UI, compare causal rows:
`a

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-skill-creator
description: "Author, evaluate, refine, optimize, and package autonomous AI agent skills across multi-agent ecosystems with BinEval scoring and description tuning. Use when creating a new skill from scratch, editing an existing skill that misfires or undertriggers, authoring test suites for skills, optimizing skill descriptions, or packaging skills for distribution — even if the user does not explicitly say \"fable-skill-creator\" (e.g. \"create a skill\", \"build a new skill\", \"optimize skill description\", \"package this skill\", \"teach the agent to do X\"). Do NOT use for general application code changes or non-skill tasks."
version: 1.3.0
pack: creator
inputs:
  - user_intent
  - workflow_trace
  - reference_sources
requires:
  - clear_capability_scope
produces:
  - structured_skill_package
  - eval_benchmark_suite
gates:
  - lack_of_surprise
  - objective_eval_criteria
fallback: fable-plan
mutatesWorkspace: true
parallelSafe: false
neural_links:
  precursors:
    - fable-discover
    - fable-research
  continuations:
    - fable-eval
    - fable-verify
    - fable-review
  lateral_peers:
    - fable-artifact
    - fable-config
  recovery: fable-recover
---

# Skill Creator

Create Skills that change agent behavior under pressure, not Skills that merely describe good practice.

## Mission
A production Skill is a compact operating manual for a recurring class of decisions. It should help an agent recognize the situation, choose among plausible actions, collect the right evidence, reject tempting shortcuts, and hand off cleanly when another specialist is better suited.

A schema-valid `SKILL.md` is not enough. A Skill that only says "inspect, plan, implement, verify" is documentation, not a behavioral capability.

## Activation Contract
Use this Skill when the requested work is to:
- create a new reusable Skill;
- strengthen or refactor an existing Skill;
- improve triggering accuracy or reduce overlap with neighboring Skills;
- add references, examples, templates, agents, or evals;
- convert a repeated workflow into a portable agent capability;
- prove that a Skill behaves correctly across more than a happy-path example.

Do not use it for ordinary application changes, bug fixes, or repository maintenance. Route those to the appropriate lifecycle Skill.

## Inputs
- **`user_intent`**: capability, behavior, or workflow to encode.
- **`workflow_trace`**: observed sequence of decisions/tools/failures, when available.
- **`reference_sources`**: primary docs, schemas, domain rules, or proven internal patterns.

## Skill Depth Classification
Before authoring, classify the capability:

| Class | Typical shape | Required depth |
| --- | --- | --- |
| Rule | One stable decision with few branches | concise Skill, strong boundaries |
| Procedure | Multi-step repeatable operation | staged protocol + evidence |
| Diagnostic | Symptoms map to competing causes | failure taxonomy + falsification |
| Orchestrator | Chooses/delegates among specialists | routing table + handoff contracts |
| Domain expert | Requires substantial specialist knowledge | deep references + examples + eval families |

If the capability is Diagnostic, Orchestrator, or Domain expert, a short checklist is presumptively insufficient.

## Skill Contract V2
Every non-trivial Skill must answer these questions explicitly.

### 1. When does it activate?
Define positive triggers, negative triggers, prerequisites, and escalation conditions. Include near-neighbor tasks that should *not* select this Skill.

### 2. What situation is the agent in?
Provide a small classification that changes behavior. Examples: bounded vs architectural, deterministic vs flaky, local vs external, reversible vs destructive, known vs uncertain.

### 3. What decisions must be made?
Use decision tables or branching rules for ambiguous cases. Do not hide judgment behind vague language such as "when appropriate" without defining the evidence that makes it appropriate.

##

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 13 — file references are metadata, not package contents.

View saved version →

---
name: fable-spark
description: "Predict the smallest atomic next engineering action from current workspace state, evidence gates, and mutation freshness with situational silence. Use when evaluating what immediate atomic step to take next, checking situational awareness, or determining if the current state requires action or silence — even if the user does not explicitly say \"fable-spark\" (e.g. \"what is my next move\", \"spark hint\", \"check next action\", \"what should I do now\"). Do NOT use as a substitute for broad architectural planning (use fable-plan)."
version: 1.3.0
pack: system
inputs:
  - current_state
requires:
  - situational_context
produces:
  - spark_suggestion
gates:
  - minimal_action_tested
fallback: get-fable
mutatesWorkspace: false
parallelSafe: true
neural_links:
  precursors:
    - get-fable
    - fable-cowork
  continuations:
    - get-fable
  lateral_peers:
    - get-fable
  recovery: fable-recover
---

# Fable Spark

Choose one small next move that improves the state of the current task—or deliberately say nothing.

## Mission
Spark is not a planner, router, motivational assistant, or todo generator. It is a micro-policy for moments when the task is already in motion and the best next action should be small, concrete, and justified by current state.

The quality bar is not "a helpful suggestion." It is **the least action that unlocks the next piece of evidence or safely advances the active Skill**.

## Activate When
- an edit/test/failure/state transition just happened;
- a long session needs the next atomic step rather than another full plan;
- verification freshness/gates determine what should happen next;
- an active specialist has a clear ownership boundary but the immediate move is unclear;
- silence vs intervention itself is a useful decision.

## Do Not Activate When
- no primary Skill has been selected for substantial new work (`get-fable`);
- architecture/decomposition is the unresolved problem (`fable-plan`);
- repeated failure requires a diagnosis (`fable-recover` owns the work; Spark may only point there);
- the user asked for execution, not a suggestion, and the executing Skill already knows its next step.

## Situation Classification
| State signal | Spark posture |
| --- | --- |
| repeated failure | stop mutation; diagnose |
| mutation newer than verification | refresh relevant proof |
| explicit active gate missing | satisfy that gate |
| review finding unresolved | repair/replan finding |
| active card blocked by unknown | discover/research/plan |
| complete/idle with no intent | silence |
| specialist owns next obvious step | usually silence; avoid narration |
| several equally plausible non-atomic moves | defer to orchestrator/plan |

## Next-Move Protocol
### Stage 1 — Read state before intent embellishment
Inspect phase, current Skill/card, mutation/verified generation, failure streak, evidence, unresolved findings, blockers, and latest user intent.

### Stage 2 — Apply safety precedence
Prefer in order when applicable:
1. diagnose repeated/contradictory failure;
2. refresh stale proof after mutation;
3. satisfy explicit blocking gate;
4. resolve a named load-bearing unknown;
5. continue the active specialist's smallest next action;
6. silence.

### Stage 3 — Make the action atomic
A Spark suggestion should usually be one observable verb-object step:
- `run the affected auth tests`;
- `reproduce the race with a barrier`;
- `inspect the registered CLI entrypoint`;
- `review the current diff against the card`;
- `capture the provider response bundle`.

Avoid multi-stage suggestions such as "research, plan, implement, test, and release."

### Stage 4 — Require a reason tied to evidence
The reason should reference state/evidence, e.g. verification stale after mutation, failure streak reached recovery threshold, release gate missing, or active card has unresolved API contract.

### Stage 5 — Check actionability
Before speaking, ask:
- can the action be done now with available c

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 10 — file references are metadata, not package contents.

View saved version →

---
name: fable-tdd
description: "Drive testable behavior changes and bug fixes through disciplined red-green-refactor cycles with observable regression tests. Use when implementing new features with unit/integration tests, fixing reproducible bugs, modifying business logic, or writing test-first behavior contracts — even if the user does not explicitly say \"fable-tdd\" (e.g. \"fix this bug test-first\", \"write a test and make it pass\", \"add this feature with tests\", \"TDD this logic\"). Do NOT use for broad exploratory prototyping without clear assertions (use fable-discover or fable-plan) or for post-implementation reviews (use fable-review)."
version: 1.3.0
pack: build
inputs:
  - behavior_contract
requires:
  - test_harness
produces:
  - regression_test
  - behavior_change
gates:
  - red_observed
  - green_observed
fallback: fable-recover
mutatesWorkspace: true
parallelSafe: false
neural_links:
  precursors:
    - fable-plan
  continuations:
    - fable-execute
    - fable-verify
  lateral_peers:
    - fable-execute
  recovery: fable-recover
---

# Fable TDD

Prove the behavior is missing or broken before changing production code, then make the smallest change that satisfies the right test at the right level.

## Mission
TDD is not "write any failing test first." The red state must demonstrate the intended behavior gap through a trustworthy harness. A syntax error, broken fixture, stale build, or mock-only expectation does not earn the right to change production code.

The Skill optimizes for three things:
- **causal confidence**: the test fails because the behavior is wrong;
- **minimal intervention**: implementation changes only what the behavior requires;
- **durable regression proof**: the test would catch the bug if it returned.

## Activate When
- fixing a reproducible bug or regression;
- adding behavior with a stable enough contract to assert;
- changing validation, state transitions, calculations, API behavior, persistence, or integration semantics;
- refactoring where an invariant needs executable characterization first.

## Do Not Activate When
- the behavior cannot yet be located or reproduced (`fable-discover`);
- the main uncertainty is external API semantics (`fable-research`);
- the change is non-executable docs/metadata with no meaningful behavior test (`fable-execute`);
- the required test harness is itself broken or executing stale artifacts (`fable-recover`).

## Change Classification
Classify the behavior before choosing a test.

| Class | Preferred proof |
| --- | --- |
| Pure/domain logic | focused unit/property test |
| Boundary validation/error mapping | unit or contract test at boundary |
| Cross-module interaction | integration test through the changed contract |
| Database/queue/cache behavior | integration test with realistic boundary where feasible |
| HTTP/CLI/public API | contract/integration test at public entry point |
| UI user flow | component/integration first; E2E for high-value cross-boundary behavior |
| Concurrency/timing | deterministic coordination test, not sleep-and-hope |
| Legacy behavior with poor seams | characterization test at nearest stable boundary |
| Refactor/no intended behavior change | characterization/invariant tests before movement |

Use the lowest test level that proves the real behavior **without mocking away the thing under test**.

## Protocol

### Stage 1 — Write the behavior contract
State:
- initial state/input;
- trigger/action;
- expected observable result;
- relevant side effects;
- error/boundary behavior;
- invariant that must remain true.

For a bug, capture the concrete reproduction separately from the proposed implementation.

### Stage 2 — Validate the harness
Before RED, confirm the chosen test actually executes the relevant path.

Check when applicable:
- source vs built artifact;
- test discovery/config;
- fixture realism;
- feature flags/env;
- mock boundaries;
- asynchronous completion;
- cleanup/isolation;
- whether the assertion observ

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: fable-verify
description: "Falsify software implementations and gather fresh, machine-checked acceptance proof across tests, builds, typechecks, and runtime smoke checks before completion. Use when running test suites, checking type correctness, validating acceptance criteria, or verifying post-mutation code integrity — even if the user does not explicitly say \"fable-verify\" (e.g. \"verify my changes\", \"run all tests and typecheck\", \"check if everything passes\", \"prove this works\"). Do NOT use for planning (use fable-plan) or diff code review (use fable-review)."
version: 1.3.0
pack: core
inputs:
  - implementation_diff
requires:
  - test_suite
produces:
  - verification_evidence
  - falsification_verdict
gates:
  - fresh_mutation_covered
  - machine_checked
fallback: fable-recover
mutatesWorkspace: false
parallelSafe: true
neural_links:
  precursors:
    - fable-execute
    - fable-tdd
  continuations:
    - fable-review
    - fable-security
    - fable-release
  lateral_peers:
    - fable-simulator
    - fable-run
  recovery: fable-recover
---

# Fable Verify

Try to prove the implementation wrong, then report only the claims that survive fresh evidence.

## Mission
Verification is not "run the test suite." It is coverage of changed risk with evidence that is both relevant and fresh.

A green command proves only what it actually exercised. Build success does not prove runtime behavior. Security success does not prove functional correctness. Unit success does not prove a packaging or integration path. Old evidence does not prove a newer mutation.

## Activate When
- implementation or repair is ready for independent proof;
- a completion claim needs fresh evidence;
- a review/release gate requires test/build/runtime evidence;
- stale evidence must be refreshed after mutation;
- the suspected regression surface spans more than the focused TDD test.

## Do Not Activate When
- writing the implementation (`fable-execute`/`fable-tdd`);
- deciding architecture (`fable-plan`);
- reviewing design/maintainability from the diff (`fable-review`);
- diagnosing repeated confusing failures (`fable-recover`).

## Risk Classification
Map each changed surface to the evidence capable of falsifying it.

| Changed surface | Typical evidence |
| --- | --- |
| pure behavior | focused unit/property + affected suite |
| cross-module contract | integration/contract test |
| public CLI/API | invocation/smoke + contract tests |
| build/export/package | build + package/clean-install smoke |
| persistence/migration | integration + migration/compatibility fixtures |
| async/concurrency | deterministic ordering/stress supplement |
| config/feature flag | tests under relevant config branches |
| browser/UI | component/integration/E2E as appropriate |
| security boundary | security-specific checks **plus** functional evidence |
| performance-sensitive path | targeted measurement when requirement exists |

## Verification Protocol

### Stage 1 — Read the diff and execution packet
Do not choose commands from habit alone. Identify:
- behavior changed;
- files/contracts touched;
- tests added/changed;
- generated/package/config surfaces;
- residual risks from implementation;
- current mutation generation.

### Stage 2 — Build a verification matrix
For each material risk, write:
- claim;
- failure mode;
- evidence/command that would catch it;
- whether evidence must be narrow, integration, runtime, build, E2E, security, or package-level.

Remove duplicate checks that prove the same narrow fact; add missing checks for untested surfaces.

### Stage 3 — Run narrow, causal checks first
Start with the focused changed behavior and affected tests. Fast local evidence helps distinguish implementation failure from unrelated suite noise.

### Stage 4 — Expand according to blast radius
Run broader typecheck/build/test/integration/E2E/package gates only where the change can affect them or where repository release policy requires them.

Do not skip required 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: get-fable
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."
version: 1.3.0
pack: core
inputs:
  - task_description
  - current_state
requires:
  - repo_access
produces:
  - routing_decision
gates:
  - state_schema_valid
fallback: null
mutatesWorkspace: false
parallelSafe: true
neural_links:
  precursors: []
  continuations:
    - fable-discover
    - fable-research
    - fable-plan
  lateral_peers:
    - fable-spark
  recovery: fable-recover
---

# get-fable

Choose the next engineering mode from the actual state of the work, not from the loudest keyword in the user's last message.

## Mission
`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.

Good 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.

## Activate When
- a substantial engineering request enters the workspace;
- the next Skill is ambiguous;
- work resumes from `.fable` state or a handoff;
- a phase transition is requested;
- new evidence invalidates the current route;
- a failure/review/security/release gate may override ordinary execution.

## Do Not Activate When
- a specialist is already executing a bounded, still-valid contract and no routing condition changed;
- the user asks only for a raw command output that a current Skill already owns;
- repeated re-routing would add ceremony without changing the next safe action.

## Routing Classification
Classify the dominant reason the next action exists.

| Situation | Preferred owner |
| --- | --- |
| repository/runtime facts unknown | `fable-discover` |
| current external fact/API uncertain | `fable-research` |
| architecture/decomposition/contract choice | `fable-plan` |
| testable behavior change | `fable-tdd` |
| genuinely independent bounded cards | `fable-delegate` |
| bounded accepted implementation | `fable-execute` |
| fresh falsification required | `fable-verify` |
| independent diff correctness review | `fable-review` |
| trust boundary/vulnerability/security work | `fable-security` |
| repeated/contradictory failure | `fable-recover` |
| candidate is ready for distribution decision | `fable-release` |
| another session/agent must resume | `fable-handoff` |
| agent-control change needs benchmark proof | `fable-eval` |
| next atomic move is unclear inside active work | `fable-spark` |

## Orchestration Protocol

### Stage 1 — Read intent and durable state
Consider together:
- user's current request;
- active card/phase;
- failure streak;
- mutation vs verified generation;
- open review/security findings;
- unresolved load-bearing unknowns;
- release/handoff state.

The last sentence in chat does not erase the lifecycle state.

### Stage 2 — Apply precedence gates
Before intent scoring, check hard overrides:
1. corrupted/invalid state → diagnose/repair state before trusting it;
2. repeated failure or contradictory evidence → recover;
3. explicit security-sensitive request → security specialist;
4. stale verification when completion/release is requested → verify;
5. blocking unknown that changes design → discover/research;
6. otherwise route by task ownership.

P

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 8 — file references are metadata, not package contents.