Claude Fable 5 最該做的事：對程式碼倉庫來一次全面審計

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-class model, excelling in long-cycle software engineering tasks with enhanced safety features.

After the new model launch, developers quickly began exploring its applications in real engineering scenarios. A repository audit Prompt shared by @meta_alchemist is a prime example. It enables Fable 5 to not just generate code, but systematically review a code repository in four stages, like a senior technical lead: first, mapping the project structure and tech stack; second, examining architecture, security, testing, performance, dependencies, and documentation issues based on actual files and line numbers; third, distilling improvement strategies; and fourth, breaking them down into prioritized task milestones with effort estimates. Some users have already used this to clear technical debt and uncover security vulnerabilities and efficiency issues missed by older models, while others have encountered early issues like unstable sandbox environments.

Overall, the release of Fable 5 is not just a model upgrade; it further pushes AI 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 pushing forward.

Run the following "Audit and Project Improvement Prompt" on every code repository that matters to you (just copy and paste 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 these four stages in order, without skipping steps.

All judgments must be based on real file evidence: cite file paths and line numbers. If something cannot be verified, state it explicitly rather than guessing.

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

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

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

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

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

·Determine the purpose of this project: its goals, intended users, and its apparent maturity—whether it is a prototype, internal tool, production service, or library.

·Document the conventions the project has already adopted, including naming conventions, module boundaries, error handling patterns, testing styles, etc., so subsequent recommendations fit the existing engineering culture rather than fighting against it.

Output of this stage: A concise "Repository Map," including project purpose, tech stack, architectural sketch, key directories with a one-sentence description, and anything that surprises you.

Stage 2 / Audit: Evidence-Based with Severity Marking

Please audit each of the following dimensions.

For each finding, document:

a) What you found

b) Where it was found, in the format: File:LineNumber

c) Why this matters, i.e., the specific consequences, not abstract principles

d) Severity: Critical / High / Medium / Low

Architecture and Design

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

Code Quality

Duplicated code, dead code, complexity hotspots including the longest functions and functions with the most branches; inconsistent patterns; error handling gaps, such as exceptions being swallowed, missing edge cases; type safety vulnerabilities.

Security

Hardcoded keys or credentials, injection risks, insecure deserialization, missing 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 verify behavior or just check for exceptions; missing test types, including unit, integration, and 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 indexes, unbounded growth issues (e.g., memory, files, queues).

Dependencies

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

Developer Experience and Operations

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

Documentation

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

Rules for this stage

Prefer 15 high-confidence findings over 50 speculative ones.

Distinguish facts from judgments. For example:

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

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

Clearly label which is which.

Also list what the code repository does well. Strengths are equally important because 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, highest-priority issues.

Stage 3 / Improvement Strategy

Synthesize the audit results into a strategy:

·Identify 3–5 themes that explain most of the problems, 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 leaving for now and why, e.g., low return on investment, high risk, or the project's current maturity doesn't require it.

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

Stage 4 / Detailed Task Plan

Translate the strategy into an execution plan:

Break the 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 verify it is 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, i.e., could it break existing functionality

·Dependencies on other tasks

Please sort the tasks into milestones:

Milestone 0

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

Milestone 1

Critical Fixes: Security issues and correctness problems.

Milestone 2

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

Milestone 3

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

Separately mark quick wins: high-impact, S-effort tasks that can be done immediately.

For the top three tasks, include a brief implementation sketch covering 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, modules that can be deprecated, performance targets, etc.

Constraints

During this audit, do not modify any code. Only analyze.

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

Calibrate recommendations based on project maturity. Do not recommend enterprise-grade infrastructure for a weekend prototype unless that is the project owner's goal.

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

If the code repository is large, prioritize an in-depth analysis of the core 20% of the code that does 80% of the work, and specify which areas received only a superficial review.

Original Link