一键导入
fable-orchestrated-feature-dev
Use when designing and implementing a new software feature from scratch — triggers the Fable-plan → implement → review pipeline.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when designing and implementing a new software feature from scratch — triggers the Fable-plan → implement → review pipeline.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when declaring or checking the token budget / model tier for this session. Triggers on: "set effort", "how much budget do we have", "low on tokens", "use opus", "use sonnet", "constrained this week", or any explicit model-tier selection. Can also be called mid-session to downgrade tier when tokens run low.
Generate an implementation-ready Product Requirements Document for a feature: self-clarify the open questions (no user interview), then write a structured PRD — goals, one-session tasks with verifiable acceptance criteria, numbered functional requirements, non-goals — saved to /tasks/prd-<feature-name>.md, ready for the `tasks` skill to convert into an executable plan. Use when the user asks "create a prd", "write a prd for X", "plan this feature", "spec out X", "requirements for X", or after running `build-options` (its Phase 4 hands the winning option here).
Convert a PRD markdown file (typically `/tasks/prd-<feature>.md` from the `prd` skill) into `prd.json` — an ordered, dependency-sorted execution plan where every acceptance criterion is a boolean check an agent can pass or fail without a human. Use when the user asks "convert prd", "create tasks", "prd to json", "generate tasks from prd", or after running `/prd` at the end of the `/market-validation → /build-options → /prd → /tasks` chain.
Map and maintain the founder-skills <-> PlatAtlas integration surface: the fable-org-audit endpoint map (with its known drift against the live worker), the market-validation market-map sink (nodes.json + flows.json into workflow-atlas, shape-valid but load-untested), adoption guidance for PlatAtlas rail agent seats, and the documented-not-executed mirror plan into workflow-atlas's own plugin convention. Use when a maintainer says "how does founder-skills connect to PlatAtlas", "is the org-audit endpoint map still current", "prove the market-map sink", "load the market map into PlatAtlas", "can the rail agents use these skills", "mirror founder-skills into workflow-atlas", or "what drifted on the PlatAtlas side".
Decide WHAT to build after a market is validated: generate divergent build options, score them with an independent judge panel into a weighted decision matrix, adversarially stress-test the top, recommend one (with kill criteria), render a Tufte decision matrix, and hand the winner to the `prd` skill. Use when the user asks "what should I build", "what are my build options", "which option should we build", "decide what to build", or after running `market-validation`.
Use when you need to verify that a customer organization on your platform is healthy and getting full value — a live integration audit that probes real API signals across eight dimensions, not a code review. Triggers on: "audit this org", "is <org> healthy", "health-check the integration", "why does this org feel off", or a scheduled pre-demo / weekly org check.
| name | fable-orchestrated-feature-dev |
| description | Use when designing and implementing a new software feature from scratch — triggers the Fable-plan → implement → review pipeline. |
Fable plans and orchestrates. Advanced models implement. Fable reviews.
Fable must never write implementation code. Its role is analysis, planning, and post-implementation review only. Every capable model available today can implement a well-written spec faithfully — use that.
digraph feature_flow {
"Feature request received" [shape=doublecircle];
"Step 1: Fable writes plan → .md file" [shape=box];
"Token budget?" [shape=diamond];
"Step 3b: hand plan file to external executor" [shape=box];
"Ample tokens?" [shape=diamond];
"Step 3a: Opus 4.8 implements" [shape=box];
"Step 3a: Sonnet 4.6 implements" [shape=box];
"Step 4: Fable reviews output vs plan" [shape=box];
"Surface findings to operator" [shape=doublecircle];
"Feature request received" -> "Step 1: Fable writes plan → .md file";
"Step 1: Fable writes plan → .md file" -> "Token budget?";
"Token budget?" -> "Step 3b: hand plan file to external executor" [label="exhausted / ~100%"];
"Token budget?" -> "Ample tokens?" [label="tokens available"];
"Ample tokens?" -> "Step 3a: Opus 4.8 implements" [label="yes / high-complexity"];
"Ample tokens?" -> "Step 3a: Sonnet 4.6 implements" [label="no / cost-conscious"];
"Step 3a: Opus 4.8 implements" -> "Step 4: Fable reviews output vs plan";
"Step 3a: Sonnet 4.6 implements" -> "Step 4: Fable reviews output vs plan";
"Step 4: Fable reviews output vs plan" -> "Surface findings to operator";
"Step 3b: hand plan file to external executor" -> "Surface findings to operator";
}
Spawn Fable as a planning-only agent. Fable must:
.md file at ~/.claude/plans/<slug>-YYYY-MM-DD.mdAgent({
model: "fable",
prompt: `You are the planner. Analyse the codebase and write a complete
implementation plan for: <feature description>.
Save the plan to ~/.claude/plans/<slug>-<date>.md.
Return only the absolute file path as your response.
Do NOT write implementation code. Planning and specification only.`,
})
Gate: Do not proceed to Step 2 until the .md file exists on disk.
Read the token budget from context: operator statements ("short on tokens"), session compression signals, or explicit weekly usage notes in memory.
| Signal | Model |
|---|---|
| Tokens ample, feature is complex | claude-opus-4-8 |
| Tokens moderate or cost-conscious week | claude-sonnet-4-6 |
| Approaching 100% / operator says exhausted | External-executor fallback → Step 3b |
If genuinely unsure, ask one question: "Opus or Sonnet this week?"
Open a new Claude Code session or Agent call with the chosen model, passing the plan file path:
Agent({
model: "opus" | "sonnet", // resolved in Step 2
prompt: `Implement the feature described in <plan-path> exactly as specified.
Follow all acceptance criteria. Do not deviate from the plan without flagging it.
When done, summarise what was built and note any deviations.`,
})
Hand the plan file to an external executor (hand the plan file to a cheaper Claude session, Haiku 4.5, or a third-party plan-runner such as Codex). The executor reads the plan and implements autonomously — no further orchestration required from this session. Surface the plan path to the operator so they can monitor the run.
The plan's acceptance criteria are already a rubric. For long or unattended implementation runs, hand the plan to a Claude Managed Agents session and let the hosted iterate → grade → revise loop execute it:
tasks skill enforces).{ "type": "user.define_outcome",
"description": "Implement the feature exactly as specified in /workspace/repo/<plan>.md",
"rubric": { "type": "text", "content": "<the acceptance criteria as markdown>" },
"max_iterations": 5 }
satisfied, max_iterations_reached (default 3, max 20), or failed.This replaces Step 4's manual review with a built-in grading loop — still run Fable's review for judgment calls the rubric can't capture.
After implementation completes, invoke Fable to review against the plan:
Agent({
model: "fable",
prompt: `Review the implementation against the plan at <plan-path>.
Check every acceptance criterion. Report: which are met, which are missing,
and any deviations from the spec. Report findings only — do not rewrite code.`,
})
Surface Fable's findings to the operator before closing the session.
| Model ID | Alias | Role |
|---|---|---|
claude-fable-5 | fable | Planner, orchestrator, reviewer — never coder |
claude-opus-4-8 | opus | Implementer — complex features, ample token budget |
claude-sonnet-4-6 | sonnet | Implementer — standard features, cost-conscious weeks |
| External executor | — | Token-exhausted fallback implementer (any plan-runner, e.g. a cheaper Claude session or Codex) |
| Mistake | Fix |
|---|---|
| Fable writes implementation code | Fable prompt must say "planning only" explicitly — reject any code output |
Skipping the .md file | The plan file is the handoff artifact; an external executor needs it as a file path, not inline text |
| Choosing Opus when tokens are tight | Check budget signal before spawning the implementer, not after |
| Passing plan content inline instead of path | Always pass the absolute file path — lets executors and future sessions re-read it |
| Letting Fable review its own plan | Fable reviews the implementation output, not the plan it wrote |