Skip to content
Back to skills

Get Fable

ASecurity

Route and orchestrate the canonical get-fable coding lifecycle — discover, research, plan, build, verify, review, secure, release, recover — from durable .fable state and incoming intent. Use when starting any substantial engineering task, resuming from a handoff, navigating lifecycle phase transitions, or determining the next load-bearing specialist when the current path is ambiguous. Do NOT use when a specific fable-* specialist already has clear, still-valid ownership of an in-progress bou...

  • 7 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 3, 2026
ai-agentsrustgonodegitapisecurity

Works with

  • api

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned September 3, 2026

npx -y skills add imMamdouhaboammar/get-fable --skill get-fable --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Get Fable?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Get Fable
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/immamdouhaboammar-get-fable/badge)](https://www.skillsdirectory.com/skills/immamdouhaboammar-get-fable)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: get-fable
description: "Route and orchestrate the canonical get-fable coding lifecycle — discover, research, plan, build, verify, review, secure, release, recover — from durable .fable state and incoming intent. Use when starting any substantial engineering task, resuming from a handoff, navigating lifecycle phase transitions, or determining the next load-bearing specialist when the current path is ambiguous. Do NOT use when a specific fable-* specialist already has clear, still-valid ownership of an in-progress bounded task."
---

# get-fable — Repository-Local Lifecycle Adapter

This is the host-installed adapter. The **canonical semantic source** lives in:

- `skills/get-fable/SKILL.md` — full orchestration protocol
- `skills/get-fable/registry.json` — all 25 skill nodes, routing graph, precedence gates
- Root `skills/fable-*/SKILL.md` — specialist skill instructions
- Root `AGENTS.md` — working contract, invariants, verification commands

---

## What get-fable does

`get-fable` is a lifecycle harness, not a prompt pack. It surrounds any coding agent with:

```
DISCOVER → RESEARCH → PLAN → TDD → DELEGATE → EXECUTE
                                       ↓
                              VERIFY → REVIEW → SECURITY
                                       ↓
                              RELEASE or RECOVER → HANDOFF
```

Every transition is **evidence-gated**. Completion cannot be claimed unless fresh, mutation-current evidence passes. Research receipts and execution logs do not substitute for behavior verification.

---

## Routing Decision Table

| Situation | Specialist to activate |
|---|---|
| Repository/runtime facts unknown | `fable-discover` |
| External API / current version uncertain | `fable-research` |
| Architecture or contract decision needed | `fable-plan` |
| Testable behavior change or bug fix | `fable-tdd` |
| Genuinely independent, disjoint bounded cards | `fable-delegate` |
| Single accepted bounded implementation card | `fable-execute` |
| Fresh falsification evidence required | `fable-verify` |
| Independent diff correctness review | `fable-review` |
| Trust boundary / auth / secret / vulnerability | `fable-security` |
| Merge / publish / release readiness | `fable-release` |
| Cross-session / cross-agent continuation | `fable-handoff` |
| Agent-control change needs benchmark proof | `fable-eval` |
| Repeated or contradictory failure (≥ 2 attempts) | `fable-recover` |
| Next atomic move unclear inside active work | `fable-spark` |
| Reduce complexity, remove dead code | `fable-simplify` |
| Persistent memory / cross-session facts | `fable-memory` |
| Recurring poll / CI babysit / interval loop | `fable-loop` |
| Live runtime smoke test / start server | `fable-run` |
| Harness config / settings change | `fable-config` |
| Independent oracle / headless contract test | `fable-simulator` |
| Autonomous scoped background work | `fable-cowork` |
| Data visualization / chart / dashboard | `fable-dataviz` |
| Technical proposal / architecture diagram | `fable-artifact` |
| Author new V2-standard skill | `skill-creator` |

---

## Precedence Gates (hard overrides before intent scoring)

Apply in order before routing by intent:

1. **Corrupted/invalid `.fable` state** → diagnose/repair state.
2. **Failure streak ≥ 2** with materially similar attempts → `fable-recover`.
3. **Explicit security-sensitive request** (auth, secrets, trust boundaries) → `fable-security`.
4. **Stale verification** when completion or release is requested → `fable-verify` first.
5. **Load-bearing unknown** that would change the design → `fable-discover` or `fable-research`.
6. Otherwise → route by task ownership in the table above.

---

## Routing Protocol (condensed)

### Stage 1 — Read durable state + intent together
Consider: active card, failure streak, mutation vs verified generation, open review/security findings, unresolved unknowns, release/handoff state. The last chat message does not erase lifecycle state.

### Stage 2 — Apply precedence gates
Check hard overrides before intent scoring.

### Stage 3 — Distinguish outcome from task type
- "Ship it" is an outcome; verification may still be required.
- "Fix this" is an outcome; root location may still be unknown.
- "Make it faster" may be research + measurement before execution.

### Stage 4 — Route to one primary owner
Output: selected skill · reason · evidence used · gate that permits the next transition.

### Stage 5 — Persist only meaningful transitions
Update `.fable` lifecycle state only when the route changes actual work phase or evidence freshness.

### Stage 6 — Re-route on new evidence
A route is not permanent. Recompute when: an assumption is disproved, scope expands, a failure repeats, security risk appears, mutation makes proof stale.

---

## Decision Rules

- `failureStreak >= 2` with materially similar attempts outranks execution → recovery.
- Explicit vulnerability/auth/secret/trust-boundary work routes to security even if the diff also needs general review.
- Current external API uncertainty → `fable-research`. Repository-local uncertainty → `fable-discover`.
- A testable bug/behavior change routes through `fable-tdd` unless a regression harness is impossible.
- "Done", "merge", "ship", "release" cannot bypass stale or missing verification.
- A passing receipt or research note is not completion-capable evidence.
- Delegation requires real semantic independence — not just different-looking files.
- Handoff delivers continuity; it does not substitute for behavior verification.
- Prefer the narrowest specialist. Keep the orchestrator routing until one specialist clearly owns the next decision.

---

## Invariants

- One primary skill owns the next load-bearing decision.
- State/evidence precedence can override textual intent when necessary for safety.
- No completion or release route relies on evidence older than the current mutation.
- Repeated failed hypotheses do not route back to blind execution.
- Research (external current fact) and discovery (repository/runtime fact) are distinct routes.
- Routing explanations are traceable to intent and state — not hidden scoring alone.

---

## Anti-Patterns to Refuse

- Routing by one keyword while ignoring the full lifecycle state.
- Treating the user's desired final outcome as the immediate next action.
- Re-routing every conversational turn for ceremony when the active specialist still has valid ownership.
- Using `fable-spark` as a substitute for specialist selection.
- Sending a repeated failure back to execute without recovery.
- Accepting stale verification because the user said "ship it".
- Selecting multiple primary skills with no ordering.

---

## Routing Packet Template

```
Intent / outcome:
Current phase / card:
State overrides: failure / stale evidence / security / unknowns
Primary next decision:
Selected skill:
Why this skill now:
Gate to leave it:
Likely continuation(s):
```

---

## Completion Criteria for This Skill

A routing turn is complete when:
- The next load-bearing decision has exactly one clear specialist owner.
- All six precedence gates were checked.
- The route is consistent with current evidence and `.fable` state.
- The specialist receives enough context to begin without reinterpreting the full conversation history.
- No later lifecycle claim is implied before its evidence exists.

---

## Key Session Learnings Installed Here

From session 2026-08-28 (`docs/learning/session-2026-08-28-skill-pack-svg-release.md`):

- **Logo sourcing**: probe `<product>.dev/icon.svg` or official GitHub repo first; CDN is fallback only.
- **Icon-table discipline**: merge logo `<img>` inline with the agent name; never a separate Icon column; one agent per row.
- **state.json hygiene**: `git checkout -- .fable/state.json` before every `bun run check` or `npm publish`; tests mutate it to schema v3.
- **Version bump**: use `scripts/bump-version.ts <version>` then `bun run check` to verify all 30+ reference points.
- **README professionalism**: remove any sentence that reads like a dev retrospective or self-deprecating checklist commentary before publishing.
- **Delegation safety**: confirm disjoint file ownership before dispatching parallel subagents.

---

*Canonical routing source: `skills/get-fable/SKILL.md` · Registry: `skills/get-fable/registry.json`*

Files in this skill

  • SKILL.md8.2 KB
  • agents/openai.yaml271 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…