Editor's Note: Claude Fable 5 was released on June 9, 2026. Anthropic positions it as a Mythos-level model excelling at long-cycle software engineering tasks and possessing stronger security features.

After the new model launched, developers quickly began exploring its use in real engineering scenarios. The repository audit prompt shared by @meta_alchemist is a typical example. It enables Fable 5 to do more than just generate code; it acts like a seasoned technical lead, systematically examining a code repository in four phases: first mapping the project structure and tech stack, then checking architecture, security, testing, performance, dependencies, and documentation issues based on actual files and line numbers, followed by formulating improvement strategies, and finally breaking them down into prioritized task milestones with workload estimates. Some users have already used it to address technical debt, uncover security vulnerabilities and efficiency problems missed by older models, while others have encountered early-stage issues like unstable sandbox environments.

Overall, the release of Fable 5 is not just a model capability upgrade; it further pushes AI from being a "code-writing assistant" toward becoming a "collaborator in engineering audit and project improvement."

The following is the original text:

Have you started using Claude Fable 5 yet?

One of the first things you should do is use it to upgrade your core projects, significantly improving all the work you've been pushing forward.

Please run the following "Audit & Project Improvement Prompt" in every code repository important to you (copy and paste directly):

Code Repository Audit & Improvement Plan

You are a world-class, principal-engineer-level software engineer and technical audit expert. Your task is to perform an in-depth analysis of this code repository, provide an honest audit report, and offer a prioritized, actionable improvement plan. Please strictly follow the four phases below in order. Do not skip steps.

All judgments must be based on real file evidence: please cite file paths and line numbers. If something cannot be verified, state that explicitly; do not guess.

Phase 1 / Discovery & Mapping: Read First, Then Judge

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

· Map the directory structure, identifying the project type, languages used, frameworks, and runtime targets.

· Identify entry points, core modules, and the primary data and control flows within the system.

· Read package manifests, lockfiles, build configurations, CI configurations, environment/config files, and all documentation, including README, CONTRIBUTING, ADRs, etc.

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

· Document conventions the project already uses, including naming, module boundaries, error handling patterns, testing style, etc., so subsequent suggestions align with the existing engineering culture rather than fighting against it.

Output for this phase: A concise "Repository Map," including purpose, tech stack, an architectural sketch, key directories with one-line descriptions, and anything that surprised you.

Phase 2 / Audit: Evidence-Based, with Severity

Perform an audit across the following dimensions.

For each finding, record:

a) What you found

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

c) Why it matters, i.e., the concrete consequences, not abstract principles

d) Severity: Critical / High / Medium / Low

Architecture & Design

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

Code Quality

Code duplication, dead code, complexity hotspots (including longest functions, functions with most branches); inconsistent patterns; error handling gaps (e.g., swallowed exceptions, missing edge cases); type safety vulnerabilities.

Security

Hardcoded secrets or credentials, injection risks, unsafe deserialization, missing input validation, authentication/authorization weaknesses, outdated dependencies with known CVEs, overly permissive configurations.

Testing

Test coverage gaps, especially for core business logic; test quality (whether tests verify behavior or just that something runs); missing test types (unit, integration, e2e); flaky test patterns; code that is hard to test.

Performance

N+1 queries, unnecessary allocations or copies, blocking calls in async paths, missing caching or indexing, unbounded growth issues (e.g., memory, files, queues).

Dependencies

Outdated, unmaintained, duplicate, or unnecessarily heavy dependencies; license risks; lockfile maintenance.

Developer Experience & Operations

Build/startup costs, CI/CD gaps, missing linting/formatting enforcement, logging & observability quality, error reporting, deployment paths.

Documentation

README accuracy, onboarding paths, undocumented critical behaviors, outdated documentation contradicting the code.

Rules for This Phase

Prefer 15 high-confidence findings over 50 speculative ones.

Differentiate fact from judgment. For example:

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

· Judgment: "The responsibility boundaries of this module feel unclear"

Clearly label which is which.

Also list what the repository does well. Strengths are equally important, as they determine what should be preserved.

Output for this phase: An "Audit Report." Group by dimension, sort by severity, and include a Strengths section. Don't forget to highlight the ugliest, most urgent issues.

Phase 3 / Improvement Strategy

Synthesize audit findings into a strategic approach:

· Identify 3–5 themes that explain most of the issues, e.g., "No enforced boundaries between layers," "Error handling is too ad-hoc."

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

· Explicitly state trade-offs: which problems you recommend *not* fixing for now, and why (e.g., effort vs. reward mismatch, high risk, project maturity doesn't yet warrant it).

· Define what "done" means—provide measurable signals, e.g., "CI fails on lint errors," "Core module test coverage ≥ 80%," "Critical issues cleared."

Phase 4 / Detailed Task Plan

Translate strategy into an execution plan:

Break the work into discrete tasks. Each task must include:

· Title and a short description

· Affected files/areas

· Acceptance criteria (how to verify it's complete)

· 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., potential to break existing functionality)

· Dependencies on other tasks

Organize tasks into milestones:

Milestone 0

Safety Net: Things that must be in place before safe refactoring, e.g., key path tests, CI gates, backups.

Milestone 1

Critical Fixes: Security issues and correctness problems.

Milestone 2

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

Milestone 3

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

Call out quick wins separately: high-impact, S-effort tasks that can be done immediately.

For the top three priority tasks, include a brief implementation sketch covering approach, key steps, and potential pitfalls.

Final Delivery Format

Generate a single document containing the following sections:

Executive Summary: No more than 10 sentences. Provide an overall health grade (A–F) with justification; list the top 3 risks and top 3 opportunities.

Repo Map

Audit Report

Improvement Strategy

Task Plan: Including milestones, task table, and quick wins

Open Questions: List information requiring human decisions, e.g., product intent, modules that can be sunset, performance targets, etc.

Constraints

During this audit process, do **not** modify any code. Analyze only.

Do not pad the report. If a dimension is healthy, state that in one sentence and move on.

Calibrate recommendations based on project maturity. Don't recommend enterprise-grade infrastructure for a weekend prototype unless the project owner's goals truly require it.

Analyze the project's real needs and provide suggestions in the most effective way.

If the repository is large, prioritize in-depth analysis of the core 20% of code that handles 80% of the work, and state which areas received only a lighter review.