The Claude Fable 5
Prompt Library

You are helping me decide which parts of my work are worth escalating to Claude Fable 5. Do not execute any of the work yet. Your job is to inspect my context, find strong candidates, and turn the best ones into ready-to-run Fable briefs.

My role and current goals:

[Describe your role, priorities, team, business goals, creative goals, or personal operating constraints.]

Use this context:

[List the sources you can inspect: repositories, project folders, docs, Notion, Slack, Linear/Jira, email, calendar, analytics, customer research, previous agent sessions, task lists, or anything else relevant.]

Constraints:

[List deadlines, privacy boundaries, accounts or tools you may not use, budget, sensitive areas, approval rules, and work that must remain human.]

First, inspect the available context. Do not brainstorm generic examples.

Build an inventory of:

1. Active projects.
2. Repeated workflows.
3. Stalled decisions.
4. Messy backlogs.
5. Work that spans several tools or sources.
6. Work where better planning, judgment, verification, or follow-through would materially improve the result.

Then identify the best candidates for Fable.

Score each candidate from 1 to 5 on:

1. Multi-source context.
2. Delegation fit.
3. Judgment required.
4. Clear finish line.
5. Leverage.
6. Fable fit.

Recommend Fable only when the task is large enough to justify a slower, more expensive run. Down-rank work that is short, obvious, highly interactive, hard to verify, or better handled by a faster Claude model or a human.

Return:

1. The top 10 Fable-worthy use cases, ranked.
2. The evidence you found for each one.
3. Why each one is or is not worth Fable specifically.
4. The expected deliverable.
5. The verification method.
6. The likely context, tools, and permissions needed.
7. Risks, blockers, or human decisions required.
8. A ready-to-run Fable Brief for the top three candidates.

For each ready-to-run Fable Brief, include:

- The problem to solve.
- The final outcome.
- Sources to inspect.
- Constraints.
- Suggested workflow.
- Human checkpoints.
- Evidence required before completion.

Stop after the ranked list and the three briefs. Do not start any Fable task until I choose one.

I want you to solve this problem:

[Describe the underlying problem. Include the first task or deliverable only if it helps explain the problem.]

The result I want is:

[Describe the final outcome, what good looks like, and how the result will be used.]

Use these sources:

[List the repositories, documents, research, data, meeting notes, Slack threads,
examples, tools, accounts, and other context available to the agent.]

Important constraints:

[List the audience, deadline, budget, scope, approvals, security boundaries,
brand rules, and decisions that must remain human.]

Use dynamic workflows, subagents, loops, verification, and installed skills
when they fit the job.
For software work, use Compound Engineering's LFG pipeline. After a
meaningful run, use Compound Engineering to save the lessons worth keeping.

Before executing:

1. Inspect the source material.
2. Restate the problem you believe you are solving.
3. Identify missing context, conflicting instructions, and assumptions that could
   change the result.
4. Decide whether the task requires a loop, a dynamic workflow, new
   infrastructure, or a simpler direct approach.
5. Show me the proposed approach and the evidence you will use to verify the result.

After approval, execute the work. Delegate independent work to subagents and keep
going while they run. Pause only for a destructive or irreversible action, a real
change in scope, or information only I can provide. Do not stop at analysis or
recommendations if you have the tools and permission to ship the result.

Before reporting progress or completion, audit every claim against a tool result
from this session. If something is not verified, say so plainly.

When finished, return:

1. The outcome, in one sentence
2. What you completed and the most important decisions you made
3. Evidence that the result works
4. Anything you could not verify
5. What should be saved or improved so the next run is better

I'm handing you this task to run unsupervised overnight: [describe the task]

Done means: [definition of done]

Use this context: [repository, documents, access, constraints]

Work through the task to completion. If you hit a blocker, do not stop. Use mocks,
stubs, or documented assumptions where appropriate. Record each workaround and
continue with everything that does not require my decision.

By morning, leave me:

1. What you completed
2. What you worked around and why
3. What still needs my decision
4. The evidence that the work functions as intended

Here is a session log from an agent attempting this workflow: [describe workflow]

It struggled with: [time, cost, errors, poor outputs, or repeated failures]

Analyze where the current tool, skill, or workflow breaks down. Identify the root
cause instead of patching the latest symptom.

Inspect the session logs, tools, skills, and source files. Find the structural
bottleneck, then build the smallest reusable improvement: a skill, command-line
tool, hook, workflow, context file, or underlying system change.

Test the upgraded workflow against a comparable task. Use a fresh verifier to
compare the old and new results on quality, time, cost, and failure rate.

Return:

1. The root cause
2. The change you made
3. The before-and-after result
4. The infrastructure that faster or cheaper models can reuse
5. Any failure you could not resolve

Use the attached source pack to analyze [business area, launch, audience, or funnel].

Sources include: [survey data, customer research, analytics dashboards, website
context, planning documents, meeting notes, Slack discussions, and internal goals]

Our goal is [specific business goal] for [target customer or profile].

Test our assumptions against the evidence. Do not treat internal consensus as fact.

First produce:

1. The 10 findings most likely to change how we operate
2. A ranked list of 10 things we should ship, test, or stop doing
3. The evidence behind each recommendation
4. Source conflicts, stale rules, unclear metric definitions, and assumptions
   that need verification

Flag conclusions that depend heavily on one source or internal rule. Then stop
for me to choose what to act on.

After I choose, execute the approved work. For software changes, use the
Compound Engineering LFG pipeline to brainstorm, plan, build, review, test, and
prepare a pull request. Build missing infrastructure when it blocks the result.
Verify the work in the real environment and do not merge or deploy without my
explicit approval.

Build a first working version of [product, website, or tool].

Product specification: [paste specification]
Users: [who it serves]
Domain context: [terms, workflows, examples, and constraints]
Tricky cases: [edge cases]
Required behavior: [requirements]
Acceptable rough edges: [scope boundaries]

Use Compound Engineering's LFG pipeline to brainstorm, plan, build, review, and
test the first version. Keep the implementation to the stated scope. Test it in
the environment where it will be used and prepare a pull request.

When you finish, give me:

1. Instructions for trying it
2. The main decisions you made
3. What you left out
4. Test results and other evidence
5. The areas I should review most carefully

Before writing code, help me plan [project or feature].

Current context: [what it does, who it serves, and where it runs today]

Where it is going: [expected scale, timeline, and release stage]

Challenge any infrastructure or abstraction that does not fit this stage. Avoid
planning for scale we do not have and avoid shortcuts that will make an imminent
release fragile.

Work through the tradeoffs with me until we agree on the architecture.

Then create one artifact I can share with the team: an HTML page or markdown
document with diagrams, the chosen architecture, the alternatives we rejected,
and why.

For every change you make to [application or feature], attach evidence that it works.

Exercise the real flows using [staging or test account] and representative data.
Capture screenshots of every screen you changed, including error states and edge
cases. Record a short video of the main flow.

Review your own captures. Scrub through the video and flag broken animations,
layout shifts, missing states, and anything a user could encounter that the tests
did not cover.

Return the test results, screenshot gallery, video, issues you found, and any
remaining uncertainty.

I need [codebase or module] ported from [language A] to [language B] because [reason].

Before starting the port, design the workflow and show it to me in code. The
workflow should:

1. Map the existing system and write a specification of its behavior.
2. Translate it module by module.
3. Test each module as it is translated.
4. Run an adversarial review at the end for omissions and behavior changes.
5. Document anything deliberately excluded from the port and why.

After I approve the workflow, run it from start to finish.

When the port is complete, show me where it improves on the original, where
behavior may differ, and which areas deserve the closest human review.

Collect feedback about [product, feature, or workflow] from: [Slack channel,
support tickets, screen recordings, screenshots, production logs, customer calls,
and meeting notes]

Group the feedback into themes. Separate:

1. Changes that are clearly actionable
2. Decisions that require my judgment
3. Requests that conflict with our strategy, user profile, or product direction
4. The evidence supporting each theme

Keep a record of what you have already processed so feedback is not duplicated.
Create one coherent plan for the actionable changes. After I approve the plan,
use Compound Engineering's LFG pipeline to implement them as one batch. Run
product polish and verification before handing the result back.

Return what changed, what you skipped, what still needs review, the pull request,
and the evidence that the changes work. Leave merging and closing the feedback
loop to me.

I need you to complete this complex task:

[Describe the task, final outcome, and why it matters.]

Available context and tools:

[List the sources, repositories, tools, accounts, environments, and constraints.]

Use Claude's dynamic workflows to orchestrate the work.

The workflow should:

1. Break the task into phases with a clear purpose and completion test.
2. Decide which phases can run in parallel and which depend on earlier work.
3. Assign research, building, testing, and adversarial review to separate subagents
   where useful.
4. Persist important intermediate findings so later phases can use them.
5. Re-plan when new evidence invalidates the current path.
6. Continue until the definition of done is satisfied, even if the workflow
   changes along the way.

Show me the workflow, likely failure points, and the small number of checkpoints
where human judgment is genuinely required.

After approval, execute it from start to finish. Keep independent subagents
running in parallel and re-plan when evidence changes. Return the result, the
evidence, the workflow you used, and the places where it changed.

I want to turn this recurring job into a loop:

[Describe the recurring input, desired output, current process, and frequency.]

Examples of previous inputs and outputs:

[Attach representative examples, including failures and human corrections.]

Use Claude's loop capability to design and test a loop that:

1. Collects or detects new input.
2. Tracks what it has already processed and avoids duplicate work.
3. Decides whether the input is actionable.
4. Plans and delegates the work.
5. Produces or ships the output.
6. Verifies the result against explicit standards.
7. Routes decisions that require human judgment.
8. Retries recoverable failures and records unrecoverable ones.
9. Captures corrections and updates the system so the next run improves.

Identify the trigger, schedule, context, tools, permissions, state, memory, and
model-routing rules the loop needs. Use Fable for the hard judgment and
orchestration; use faster models for routine stages. Build the smallest working
version.

Return:

1. A diagram or written map of the loop
2. The working implementation or implementation plan
3. The human checkpoints
4. The verification method
5. How learning will be saved between runs

Audit the context available for this body of work:

[Describe the project, role, or recurring workflow.]

Current sources:

[List folders, documents, databases, repositories, meeting notes, style guides,
examples, and memory files.]

Design an agent-ready context system.

The system should:

1. Give Claude Code one concise CLAUDE.md starting file.
2. Explain what each source contains and when to use it.
3. Separate stable rules from temporary project context.
4. Identify conflicts, duplication, stale guidance, and missing information.
5. Include examples of excellent output and known failure modes.
6. Keep large source files available without forcing every run to load everything.
7. Move repeatable procedures into skills instead of bloating CLAUDE.md.
8. Define how new decisions and corrections should be saved.

Create the directory, index files, or markdown templates required to make the
system usable. Implement the structure when you have the tools and permission.

Return the new context map, what you changed, unresolved conflicts, and
instructions for keeping it current.

Help me develop this writing idea:

[Describe the idea, tension, question, or story you are considering.]

Use this context:

[Attach interview transcripts, reporting, notes, previous drafts, relevant code
or product history, style guidance, and examples of your work.]

The piece should ultimately accomplish:

[Describe the audience, intended effect, central tension, and what a strong piece
would make the reader understand or feel.]

Explore the material before drafting.

1. Inspect the context and identify the most interesting tensions, surprises,
   scenes, and unresolved questions.
2. Interview me about the choices that require my judgment or personal experience.
3. Propose several possible arguments or narrative shapes.
4. Explain what each version emphasizes and leaves out.
5. Wait for me to choose a direction.

After I choose, create an outline that sequences information for a reader who
does not share my context. Then draft the piece.

Keep the exploratory material separate from the final draft. Flag where the draft
relies on an assumption, lacks evidence, or drifts from the outcome I described.

Add this instruction to your agent setup:

After every completed agent session, ask me: "Do you want to compound this
session?" Do not run the compound process automatically. Wait for my approval.

Use Compound Engineering's compound skill to review this completed agent session:

[Attach the prompt, plan, outputs, tool calls, test evidence, human feedback, and
final result.]

Determine what should be learned from this run.

Separate:

1. Durable lessons that apply to future work
2. Project-specific facts that belong in project context
3. Personal or team preferences
4. Tool or workflow improvements
5. Mistakes that should not become general rules
6. One-off details that should not be saved

For every proposed learning:

- Cite the evidence from the session.
- Explain where it should be stored.
- Show the exact change you propose.
- Check for conflicts with existing instructions.

Store durable solutions in the project's knowledge system with enough title,
metadata, vocabulary, and cross-links for a future agent to find them. Update
CLAUDE.md only for concise instructions that belong in every session. Put
repeatable procedures in skills. Keep each change small and specific.

Return:

1. What you saved
2. Where you saved it
3. What you deliberately did not save
4. How the next run should improve