Claude Fable 5 프롬프트 15개 완벽 정리 — 인스타 창업자가 실제로 쓰는 실전 라이브러리

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, docs, Notion, Slack, Linear/Jira, email, calendar, analytics, customer research, previous agent sessions, task lists.]
Constraints: [List deadlines, privacy boundaries, accounts or tools you may not use, budget, 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.

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.

Return: the top 10 Fable-worthy use cases (ranked), the evidence, why each is/isn't worth Fable, the deliverable, the verification method, the context/tools/permissions needed, risks, and a ready-to-run Fable Brief for the top three. Stop after the ranked list and three briefs.

I want you to solve this problem: [Describe the underlying problem.]
The result I want is: [Describe the final outcome, what good looks like, and how the result will be used.]
Use these sources: [repositories, documents, research, data, meeting notes, Slack threads, examples, tools, accounts.]
Important constraints: [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.

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. 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 if you have the tools to ship.
Before reporting, 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 key decisions 3. Evidence that it works 4. Anything you could not verify 5. What should be saved 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 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. Then stop for me to choose what to act on.
After I choose, execute the approved work and verify it in the real environment. Do not 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]

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 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 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, implement them as one batch with verification.
Return what changed, what you skipped, what still needs review, and the evidence. Leave merging and closing the 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.

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. Return the result, the evidence, the workflow you used, and 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. Use Fable for the hard judgment; use faster models for routine stages. Build the smallest working version.
Return: 1. A map of the loop 2. The working implementation or 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 templates required. Implement the structure when you have 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, 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.

Review this completed agent session: [Attach the prompt, plan, outputs, tool calls, test evidence, human feedback, and final result.]
Determine what should be learned. Separate: 1. Durable lessons that apply to future work 2. Project-specific facts 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, explain where it should be stored, show the exact change you propose, and check for conflicts with existing instructions.
Store durable solutions in the project's knowledge system with enough title, metadata, 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.
Return: 1. What you saved 2. Where you saved it 3. What you deliberately did not save 4. How the next run should improve