AI Learn
Anthropic · Claude Code Tutorial

Create a useful CLAUDE.md for a real repository

Put durable repository rules, commands and architecture context into CLAUDE.md so Claude Code starts each session with the right working agreements.

Reviewed September 19, 2026Independent tutorialFeatures may vary
Not official support. AI Learn is an independent education site and is not affiliated with Anthropic. Check the provider’s current documentation for plan-specific limits, pricing and feature availability.
Before you start

Use CLAUDE.md for stable repository guidance, not a dump of every fact. Keep it short enough that important rules stay visible and update it when the project changes.

1. Start from recurring mistakes

List the instructions you repeat in many sessions: package manager, test command, folder boundaries, generated files, style rules and forbidden changes.

2. Write commands exactly

Record the real install, lint, typecheck and test commands. If a command only applies to one package or directory, say where it should run.

3. Explain architecture in decisions, not history

Describe which module owns what, where new code normally belongs, and which interfaces must remain stable. Avoid a long narrative about how the repository evolved.

4. Add safety boundaries

Name secrets, production files, migrations, dependency changes or destructive commands that require approval. Tell Claude Code what it may inspect but should not modify.

5. Test the file in a fresh session

Start a new Claude Code session and ask it to summarize the repository rules before editing. If it misses a critical rule, rewrite CLAUDE.md to make that rule clearer.

Try this prompt

Before changing anything, read CLAUDE.md and summarize the five rules that most constrain this task. Then inspect the relevant files, propose a minimal plan, and stop before editing if the task conflicts with a repository rule.

Common mistakes

Turning CLAUDE.md into a giant handbook; documenting commands that no longer work; putting one-off task instructions into permanent memory; assuming a rule is effective without testing a new session.

Finish check

A new session can identify the correct commands, architecture boundaries and approval points before touching code.

开始之前

CLAUDE.md 适合放长期稳定的项目指导,不适合把所有资料都塞进去。保持精简,让真正重要的规则始终醒目;项目变化后也要同步更新。

1. 从反复出现的错误开始

列出你在很多会话里重复强调的内容:包管理器、测试命令、目录边界、生成文件、代码风格和禁止修改的区域。

2. 把命令写到可以直接执行

记录真实的安装、lint、类型检查和测试命令。如果某条命令只能在某个 package 或目录运行,要把路径写清楚。

3. 讲架构决策,不要写项目史

说明哪个模块负责什么、新代码通常放哪里、哪些接口必须保持稳定。不要写一大段仓库历史。

4. 写清安全边界

标出密钥、生产配置、迁移、依赖变化或破坏性命令等需要批准的事项,并说明哪些内容可以查看但不应修改。

5. 用全新会话验证

新开 Claude Code 会话,让它在编辑前先总结项目规则。如果关键规则被漏掉,就回头把 CLAUDE.md 写得更明确。

可以直接套用的提示词

修改任何内容之前,先读取 CLAUDE.md,并总结这次任务最受约束的 5 条规则。然后检查相关文件,提出最小改动方案;如果任务与仓库规则冲突,请在编辑前停下来说明。

常见错误

把 CLAUDE.md 写成巨大手册;记录已经不能运行的命令;把一次性任务要求写成永久规则;从不新开会话验证规则是否真的生效。

完成检查

完成后,新会话应该能在改代码之前准确说出正确命令、架构边界和需要人工批准的事项。

開始之前

CLAUDE.md 適合放長期穩定的專案指導,不適合把所有資料都塞進去。保持精簡,讓真正重要的規則始終醒目;專案變化後也要同步更新。

1. 從反復出現的錯誤開始

列出你在很多會話里重復強調的內容:包管理器、測試指令、目錄邊界、生成檔案、代碼風格和禁止修改的區域。

2. 把指令寫到可以直接執行

記錄真實的安裝、lint、類型檢查和測試指令。如果某條指令只能在某個 package 或目錄運行,要把路徑寫清楚。

3. 講架構決策,不要寫專案史

說明哪個模塊負責甚麼、新代碼通常放哪裡、哪些接口必須保持穩定。不要寫一大段倉庫歷史。

4. 寫清安全邊界

標出密鑰、生產配置、遷移、依賴變化或破壞性指令等需要批准的事項,並說明哪些內容可以查看但不應修改。

5. 用全新會話驗證

新開 Claude Code 會話,讓它在編輯前先總結專案規則。如果關鍵規則被漏掉,就回頭把 CLAUDE.md 寫得更明確。

可以直接套用的提示詞

修改任何內容之前,先讀取 CLAUDE.md,並總結這次任務最受約束的 5 條規則。然後檢查相關檔案,提出最小改動方案;如果任務與倉庫規則衝突,請在編輯前停下來說明。

常見錯誤

把 CLAUDE.md 寫成巨大手冊;記錄已經不能運行的指令;把一次性任務要求寫成永久規則;從不新開會話驗證規則是否真的生效。

完成檢查

完成後,新會話應該能在改代碼之前準確說出正確指令、架構邊界和需要人工批准的事項。

Official references

Check current product details at the source

Related practical tutorials

Continue with another single-task workflow.

All tutorials →