get-fable

fable-recover

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

fable-release

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

fable-research

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

fable-review

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

fable-run

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

fable-security

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

fable-simplify

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

fable-simulator

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

fable-skill-creator

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.

fable-spark

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

fable-tdd

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

fable-verify

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

get-fable

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.