Claude Fable 5 Prompt Library

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