Original author: Meta Alchemist
Original translation: Peggy, BlockBeats
Editor's note: Claude Fable 5 was released on June 9, 2026, and Anthropic positions it as a Mythos level model that excels in long-cycle software engineering tasks and has stronger safety features.
After the new model went live, developers quickly began exploring its applications in real engineering scenarios: the repository audit Prompt shared by @meta_alchemist is a typical case. It allows Fable 5 not only to generate code but also to systematically review the code repository like an experienced technical lead in four phases: first organizing the project structure and technology stack, then checking architecture, security, testing, performance, dependencies, and documentation issues based on actual files and line numbers, followed by refining improvement strategies, and breaking them down into tasks with priorities and workload estimates. Some users have already used it to clear technical debt, discover security vulnerabilities and efficiency issues overlooked by old models, while others encountered early issues such as unstable sandbox environments.
Overall, the release of Fable 5 is not only an upgrade in model capabilities but also further promotes AI from "code writing assistant" to "engineering audit and project improvement collaborator."
Here is the original text:
Have you already used Claude Fable 5?
The first thing you should do is upgrade your core projects with it to significantly improve all the work you have been pushing forward.
Please run the following "audit and project improvement prompt" (directly copy and paste it) in every code repository that matters to you:
Code Repository Audit and Improvement Plan
Prompt generated by Claude Fable 5
You are a world-class, chief engineer level software engineer and technical audit expert. Your task is to conduct a deep analysis of this code repository, provide an honest audit report, and deliver a prioritized, executable improvement plan. Please strictly follow the four phases in order without skipping steps.
All judgments must be based on actual file references: please cite file paths and line numbers. If something cannot be verified, please state clearly rather than guessing.
Phase 1 / Discovery and Organization: Read first, then judge
Before forming any conclusions, please systematically explore the entire code repository:
· Organize the directory structure, identify the project type, language, framework, and running goals.
· Identify entry files, core modules, and the main data and control flows in the system.
· Read package manifest, lockfile, build configuration, CI configuration, environment/configuration files, and all documentation, including README, CONTRIBUTING, ADR, etc.
· Determine the purpose of this project: its goals, expected users, and current maturity—whether it is a prototype, internal tool, production service, or a library.
· Record the conventions already adopted by the project, including naming conventions, module boundaries, error handling patterns, testing styles, etc., so that subsequent suggestions can align with existing engineering culture rather than contradicting it.
Output of this phase: a concise "code repository map," including project purpose, technology stack, architecture sketch, key directories with one-sentence descriptions, and any surprising elements.
Phase 2 / Audit: Evidence-based and severity marked
Please audit each of the following dimensions.
For each finding, record:
a) What you discovered
b) Where you found it, in the format: file:line number
c) Why this is important, i.e., specific consequences rather than abstract principles
d) Severity: Critical / High / Medium / Low
Architecture and Design
Module boundaries, coupling/cohesion, circular dependencies, abstraction leaks, god objects/god files, layering violations, scalability bottlenecks.
Code Quality
Duplicate code, dead code, complexity hotspots, including the longest functions, functions with the most branches; inconsistent patterns; error handling gaps, such as swallowed exceptions, missing edge cases; type safety vulnerabilities.
Security
Hardcoded keys or credentials, injection risks, unsafe deserialization, missing input validation, authentication/authorization weaknesses, outdated dependencies with known CVEs, overly lenient configurations.
Testing
Testing coverage gaps, especially in core business logic; testing quality, i.e., whether tests are verifying behavior or just ensuring they run; missing types of tests, including unit tests, integration tests, end-to-end tests; flaky test patterns; hard-to-test code.
Performance
N+1 queries, unnecessary allocations or copies, blocking calls in asynchronous paths, missing caching or indexing, uncontrolled growth issues, such as memory, files, queues.
Dependencies
Outdated, unmaintained, redundant, or unnecessary heavyweight dependencies; license risks; maintenance status of lockfiles.
Developer Experience and Operations
Build/start costs, CI/CD gaps, lack of lint/formatting enforcement, logging and observability quality, error reporting, deployment paths.
Documentation
Accuracy of README, onboarding paths, undocumented critical behaviors, outdated documentation that contradicts the code.
Rules of this phase
Prefer to provide 15 high-confidence findings rather than 50 speculative findings.
Distinguish between facts and judgments. For example:
· Fact: "This function has no error handling: src/api/client.ts:142"
· Judgment: "The responsibility boundaries of this module feel unclear."
And clearly label which is which.
Also list the strengths of this code repository. Advantages are equally important as they determine what should be retained.
Output of this phase: an "audit report." Please group by dimension, prioritize by severity, and include a Strengths section. Don’t forget to highlight the ugliest problems that need priority attention.
Phase 3 / Improvement Strategy
Consolidate audit results into a set of strategies:
· Identify 3–5 themes that explain most issues, for example, "no enforced boundaries between layers" or "error handling is too ad-hoc."
· For each theme, propose a target state and the principles behind it.
· Clearly state trade-offs: which problems you suggest not fixing for now and why you don’t recommend fixing them, such as mismatched investment vs. benefit, higher risks, or temporarily unnecessary project maturity.
· Define what "done" means—provide measurable signals such as "CI will fail due to lint errors," "core module test coverage ≥ 80%," "zero critical issues."
Phase 4 / Detailed Task Plan
Translate the strategies into an execution plan:
Break work down into individual tasks. Each task must include:
· Title and a description of the task
· Affected files/areas
· Acceptance criteria, i.e., how to validate that it is completed
· Workload estimate: S = less than 2 hours, M = half a day, L = 1-2 days, XL = needs further breakdown
· Risk of the change itself, i.e., whether it could break existing functionality
· Dependencies on other tasks
Please sort tasks by milestone:
Milestone 0
Safety net: items that must be completed before a safe refactor, such as critical path testing, CI gate, backups.
Milestone 1
Critical fixes: security issues and correctness issues.
Milestone 2
High leverage improvements: changes that make all subsequent work easier.
Milestone 3
Quality and polishing: remaining medium to low priority issues worth addressing.
Please highlight quick wins separately, i.e., high impact, S workload tasks that can be completed immediately.
For the top three tasks, please attach a brief implementation outline, including method, key steps, and common pitfalls.
Final delivery format
Please generate a single document that includes the following sections:
Executive Summary: No more than 10 sentences. Provide an overall health rating A–F and explain why; list the top 3 risks and the top 3 opportunities.
Repo Map
Audit Report
Improvement Strategy
Task Plan: including milestones, task list, and quick wins
Open Questions: list information that requires human decisions, such as product intent, deprecated modules, performance goals, etc.
Constraints
During this audit, do not modify any code. Only perform analysis.
Do not fill in the report. If a dimension is healthy, state it in one sentence and then move on.
Calibrate suggestions based on project maturity. Unless the project owner’s goals truly require it, do not recommend enterprise-level infrastructure for a weekend prototype project.
Analyze the real needs of the project and provide suggestions in the most effective manner.
If the code repository is large, prioritize an in-depth analysis of the core 20% of the code that accounts for 80% of the workload and indicate which areas were only superficially reviewed.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
