Original Author: Meta Alchemist
Translation: Peggy, BlockBeats

Editor's Note: Published by Claude Fable 5 on June 9, 2026, Anthropic positioned it as a Mythos-level model specializing in long-cycle software engineering tasks with enhanced security features.

After the new model went live, developers quickly began exploring its real-world applications: the repository audit prompt shared by @meta_alchemist is a typical case. It enabled Fable 5 to not only generate code but also systematically review the code repository like a seasoned tech lead in four phases: first, outlining the project structure and tech stack; then, checking architecture, security, testing, performance, dependencies, and documentation issues based on actual files and line numbers; next, refining improvement strategies and breaking them down into milestone tasks with priorities and estimated workload. Some users have used this to clean up technical debt, uncover security vulnerabilities and efficiency issues missed by the old model, while others have encountered early-stage issues like unstable sandbox environments.

Overall, the release of Fable 5 is not just a model's capability upgrade but also a further step towards AI evolving from a "code-writing assistant" to an "engineering audit and project improvement collaborator."

Below is the original text:

Have you started using Claude Fable 5?

The first thing you should do is use it to upgrade your core project, significantly improving all the work you have been advancing.

Run the following "Audit and Project Improvement Prompt" in each of your critical code repositories (simply copy and paste):

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 deeply analyze this code repository, provide an honest audit report, and offer a prioritized, actionable improvement plan. Please strictly follow the following four phases sequentially without skipping steps.

All assessments must be based on actual file references: please cite file paths and line numbers. If something cannot be verified, state it explicitly rather than guessing.

Phase 1 / Discovery and Scoping: Read First, Judge Later

Before drawing any conclusions, systematically explore the entire code repository:

· Review the directory structure to identify the project type, programming languages used, frameworks, and the project's goals.

· Identify entry points, core modules, as well as the main data flow and control flow within the system.

· Read the package manifest, lockfile, build configuration, CI configuration, environment/config files, and all documents, including README, CONTRIBUTING, ADR, etc.

· Determine the project's purpose: its goals, intended users, and current apparent maturity—is it a prototype, an internal tool, a production service, or a library?

· Document the conventions already adopted by the project, including naming conventions, module boundaries, error-handling patterns, testing styles, etc., so that subsequent recommendations can align with the existing engineering culture rather than work against it.

Output of this phase: A concise "Code Repository Map," including the project's purpose, technology stack, architecture overview, key directories with one-sentence descriptions, and any surprising findings.

Phase 2 / Audit: Evidence-Based, Severity-Tagged

Conduct an audit on the following dimensions.

For each discovery, make sure to record:

a) What you found

b) Where you found it, formatted as: File:Line

c) Why it is important, i.e., the specific consequences, not abstract principles

d) Severity: Critical / High / Medium / Low

Architecture & Design

Module boundaries, coupling/cohesion, circular dependencies, leaky abstractions, god objects/god files, layering violations, scalability bottlenecks.

Code Quality

Duplicate code, deprecated code, complexity hotspots including longest functions, most branching functions; inconsistent patterns; error-handling gaps such as swallowed exceptions, missing edge cases; type safety vulnerabilities.

Security

Hardcoded keys or credentials, injection risks, insecure deserialization, lack of input validation, authentication/authorization weaknesses, outdated dependencies with known CVEs, overly permissive configurations.

Testing

Test coverage gaps, especially in core business logic; test quality, i.e., whether tests are verifying behavior or just validating the ability to run; missing test types including unit tests, integration tests, end-to-end tests; flaky test patterns; code that is hard to test.

Performance

N+1 Query, unnecessary allocation or copying, blocking calls in asynchronous paths, lack of caching or indexing, unbounded growth issues such as memory, file, queue.

Dependencies

Outdated, unmaintained, duplicate or unnecessary heavy dependencies; licensing risks; lockfile maintenance.

Development Experience and Operations

Build/startup costs, CI/CD gaps, missing lint/formatting enforcement, log and observability quality, error reporting, deployment paths.

Documentation

README accuracy, onboarding process, undocumented key behaviors, outdated documentation conflicting with the code.

This Phase's Rule

Prefer to provide 15 high-confidence findings rather than 50 speculative findings.

Differentiate between facts and judgments. For example:

· Fact: "This function lacks error handling: src/api/client.ts:142"

· Judgment: "The responsibility boundary of this module feels unclear"

And clearly label which category is which.

Also, list the strengths of this code repository. Strengths are equally important as they dictate what should be preserved.

Output of This Phase: An "Audit Report." Group by dimension, sort by severity, and include a Strengths section. Don't forget to point out the ugliest, most critical issues that need immediate attention.

Phase 3 / Improvement Strategy

Synthesize the audit results into a set of strategies:

· Identify 3–5 key themes that can explain most of the issues, such as "Lack of enforced boundaries between layers" or "Error handling is too ad-hoc."

· For each theme, propose a target state and the underlying principles.

· Clearly state trade-offs: which issues you recommend deferring fixes for, why you should postpone, such as mismatched investment and return, high risk, or the project's current maturity not requiring it.

· Define what "done" means — provide measurable signals, like "CI will fail due to lint errors," "Core module test coverage ≥ 80%," "Zero Critical-level issues."

Phase 4 / Detailed Task Plan

Translate Strategy into an Execution Plan:

Break down the work into individual tasks. Each task must include:

· Title and a brief task description

· Affected files/areas

· Acceptance criteria, i.e., how to verify it is completed

· Work estimate: S = Less than 2 hours, M = Half a day, L = 1–2 days, XL = Requires further breakdown

· Risk of the change itself, i.e., whether it could disrupt existing functionality

· Dependencies on other tasks

Please order the tasks by milestone:

Milestone 0

Safety Net: Items that must be completed before safety refactoring, such as critical path testing, CI gate, backup.

Milestone 1

Critical Fixes: Security issues and correctness problems.

Milestone 2

High-Leverage Improvements: Changes that make all subsequent work easier.

Milestone 3

Quality and Polish: Remaining low-medium priority items worth addressing.

Identify quick wins, i.e., high-impact, S-level tasks that can be completed immediately.

For the top three ranked tasks, please provide a brief implementation outline, including approach, key steps, and potential pitfalls.

Final Delivery Format

Please create a single document containing the following sections:

Executive Summary: Not more than 10 sentences. Provide an overall health grade A–F and explain the reasons; 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 decision-making, such as product intent, deprecable modules, performance goals, etc.

Constraints

Do not modify any code during this audit. Analysis only.

Do not overfill the report. If a dimension is healthy, a single sentence explanation is sufficient, then proceed to the next.

Based on project maturity calibration advice. Unless the project owner's goal specifically requires it, do not recommend enterprise-grade infrastructure for a weekend prototype project.

Analyze the project's true needs and provide recommendations in the most efficient way.

If the code repository is large, prioritize a deep analysis of the most critical 20% of the code, which accounts for 80% of the work, and indicate which areas have only undergone a more superficial review.

[Original Article Link]

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia