Claude Fable 5's Top Priority: A Comprehensive Audit of Your Code Repository

Original Author: Meta Alchemist

Original Compilation: Peggy, BlockBeats

Editor's Note: Claude Fable 5 was released on June 9, 2026. Anthropic positions it as a Mythos-level model specializing in long-cycle software engineering tasks with enhanced 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 enables Fable 5 to go beyond just generating code, systematically reviewing code repositories in four stages like a senior technical lead: first, sorting out the project structure and tech stack; then checking architecture, security, testing, performance, dependencies, and documentation issues based on actual files and line numbers; subsequently refining improvement strategies; and finally breaking them down into task milestones with priorities and workload estimates. Some users have already leveraged this to clear technical debt, uncover security vulnerabilities and efficiency issues missed by older models, while others have encountered early-stage issues like instability in the sandbox environment.

Overall, the release of Fable 5 is not just an upgrade in model capability but also pushes AI further from being a "code-writing assistant" towards a "collaborator for 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 advancing.

Run this "Audit & Project Improvement Prompt" on every code repository that matters to you (just copy and paste it directly):

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 deliver a prioritized, actionable improvement plan. Please strictly follow the four stages below in order, without skipping steps.

All judgments must be based on actual file evidence: cite file paths and line numbers. If something cannot be verified, clearly state that rather than making assumptions.

Stage 1 / Discovery and Mapping: Read First, Then Judge

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

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

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

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

· Determine the project's purpose: its goals, intended users, and its apparent maturity level – whether it's a prototype, internal tool, 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 subsequent recommendations align with the existing engineering culture rather than working against it.

Output of this stage: A concise "Repository Map" including the project's purpose, tech stack, architectural sketch, key directories with their one-sentence descriptions, and anything that surprised you.

Stage 2 / Audit: Evidence-Based, with Severity Ratings

Please audit each of the following dimensions.

For each finding, record:

a) What you found

b) Where it was found, formatted as: file:line number

c) Why this matters, i.e., 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

Duplicated code, dead code, complexity hotspots (including the longest functions, functions with the most branches), inconsistent patterns, error handling gaps (e.g., exceptions swallowed, 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 permissive configurations.

Testing

Test coverage gaps, especially for core business logic; test quality (whether tests verify behavior or just validate execution); missing test types (unit, integration, end-to-end); flaky test patterns; hard-to-test code.

Performance

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

Dependencies

Outdated, unmaintained, duplicated, or unnecessarily heavy dependencies; license risks; lockfile health.

Developer Experience & Operations

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

Documentation

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

Rules for this stage

Better to have 15 high-confidence findings than 50 speculative ones.

Differentiate 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 what this code repository does well. Strengths are equally important as they determine what should be preserved.

Output of this stage: An "Audit Report". Group by dimension, sort by severity, and include a Strengths section. Do not forget to highlight the ugliest, most urgent issues.

Stage 3 / Improvement Strategy

Synthesize the audit results into a strategy:

· 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 principles behind it.

· Clearly state trade-offs: which issues you recommend deferring and why, such as low ROI, high risk, or the project's maturity doesn't yet require it.

· Define what "done" looks like – give measurable signals, e.g., "CI fails on lint errors," "Core module test coverage >= 80%," "Zero Critical-level issues."

Stage 4 / Detailed Task Plan

Transform the strategy into an execution plan:

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

· Title and task description

· Affected files/areas

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

· Effort estimate: S = less than 2 hours, M = half a day, L = 1–2 days, XL = needs further breakdown

· Risk of the change itself (whether it might break existing functionality)

· Dependencies on other tasks

Please sort tasks into milestones:

Milestone 0

Safety Net: Things that must be done before safe refactoring, e.g., critical path tests, CI gates, backups.

Milestone 1

Critical Fixes: Security and correctness issues.

Milestone 2

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

Milestone 3

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

Separately mark quick wins (high impact, S effort, doable immediately).

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

Final Deliverable Format

Generate a single document containing the following sections:

Executive Summary: No more than 10 sentences. Provide an overall health score 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, deprecatable modules, performance targets, etc.

Constraints

Do not modify any code during this audit. Perform analysis only.

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

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

Analyze the project's actual needs and provide the most effective recommendations.

If the code repository is large, prioritize deep analysis of the core 20% of the code (the part handling 80% of the work). Specify which areas received only a shallow review.

Original Link