[项目名] — 项目专属 Context

这是项目级 CLAUDE.md，叠加在你全局 / 上层的 CLAUDE.md 之上。 只写这个项目特有的接续规则，不复述上层已经有的全局规则。

新会话醒来的头 30 秒

先判断单工作流还是多工作流（看 brain/ 下的文件命名）：

• 只有 STATUS.md / HANDOFF.md → 走"单工作流"分支
• 有多个 STATUS_<工作流>.md 文件 → 走"多工作流"分支（v2.1）

单工作流（默认）

必读两份（都在 brain/ 下）：

1. brain/MAP.md — 项目地图。回答"这个项目长什么样、文档去哪找？"
2. brain/STATUS.md — 当前状态。回答"现在停在哪、下一步做什么？"

如果存在 brain/HANDOFF.md —— 也读它。这是上一班的交班记录：醒来第一件事、在等谁、还有什么只在上一班脑子里。

读完后简短回报：项目识别 + 当前进度 + 上次卡点。不要静默动手 —— 确认理解对了再开始干。

多工作流（v2.1）

先读项目级共享文件：brain/MAP.md（含第 6 节工作流清单）+ brain/PROJECT.md（如需）。

**认清这个窗口归哪条工作流 —— 不要猜。**只认明确的信号：窗口是照这条工作流起的名（工作流名加序号，例如 web-6），或用户开窗时说了是哪条。否则简短回报并询问：

"我看到这是多工作流项目，有 [列出所有工作流名]。这个窗口做哪个？"

再读对应工作流的 brain/STATUS_<工作流>.md + brain/HANDOFF_<工作流>.md，然后做和单工作流一样的简短回报（「别的工作流交来的」里有等着的，一并说）。

几个窗口同时开（v2.8 —— MAP §6 有「现在谁在接」表）：再看一眼别的工作流 STATUS 的「交给别的工作流的」，有交给自己这条、还是「已发」的，回报时一并说。用户确认、开始干活后，把自己那条工作流那一行改成这个窗口的名字和日期 —— 只改这一格，单独提交。提到别的工作流写工作流名，不写窗口名（陷阱 18）。

如果同会话内用户让窗口切换工作流 —— 必须重新读新工作流的 STATUS + HANDOFF，不要混用上一个工作流的记忆（陷阱 14）。

什么时候读其他接续层文件

• 范围模糊 / 有人问"这个项目能不能加 X 功能" → 读 brain/PROJECT.md（看是不是被"刻意不做什么"挡了）
• 想搞清楚"为什么现在长成这样、为什么这里这么绕" → 读 brain/DECISIONS.md
• 想知道 brain/topics/ 下某份文件在哪 → 回 brain/MAP.md 第 5 节文档索引

什么时候读 brain/topics/ 内容

brain/MAP.md 第 5 节会给每份 topic 文档标"何时读"。按触发条件读，不要每次都全部读。

⚠️ TODO ⚠️ —— 高频入口（例如："记忆逻辑 → topics/systems/MEMORY.md"）

项目红线（写代码前先读）

⚠️ TODO ⚠️ —— 填写红线，或者写明"本项目无显式红线"

更新职责

核心原则（METHODOLOGY §4.1，v2.9.1）：brain/ 是写给下一个窗口的，不是写给用户的。STATUS / HANDOFF / MAP 登记（包括认领「现在谁在接」那一格）/ RUNBOOK 追加，工作落定就写，不问、不报备；写了就提交，提交说明写清改了什么，git 是唯一的记录。只有一件事要问用户，而且只在拿不准的时候问：这算定了吗？ DECISIONS 和 PROJECT 跟着答案走；用户明说过的直接记。

判断分工（重要）：

• 用户决定"现在该不该记"
• AI 决定"具体记什么、每条怎么写"（用户不知道每个文件内部怎么运作 —— 不要把这种判断推回去）
• 用户拥有对 AI 判断的批准 / 否决权

具体节奏：

• 用户说"更新项目脑" → 跑"判断 + 清单"工作流：基于本次会话发生了什么，主动判断哪些文件该更新、写什么，给一份带理由的清单让用户审（见 METHODOLOGY §4.4）
• AI 感觉"那段像是决策" → 温柔询问："这算定下来了吗？要不要追加到 DECISIONS？" —— 不要断言（见 METHODOLOGY §4.5）
• 模块新增 / 删除 → 更新 brain/MAP.md 第 2 节
• 新增文档 / 废弃文档 → 登记进 brain/MAP.md 第 5 节
• 用户暗示会话结束（"就这样 / 我先走了 / 该切了"）→ 覆写 brain/STATUS.md（软上限 80 行 / 约 6000 字）
• 用户说切窗口 / 交接 / 换班 → 先把旧 brain/HANDOFF.md 里仍然有效的挪走（在等的 → STATUS，办法和坑 → brain/topics/operations/RUNBOOK.md），归档到 brain/handoffs/YYYY-MM-DD-HHMM.md，再按模板六段写新的交班记录；Claude Code 下顺手刷新自动记忆指针（METHODOLOGY §3.4，v2.7）
• 用户显式说"更新 STATUS / 记一条决策" → 直接做，不要再问

多工作流（v2.1）：上面所有涉及 STATUS / HANDOFF / handoffs 的，都按当前窗口所属工作流来 —— STATUS_<当前>.md / HANDOFF_<当前>.md / handoffs/<当前>/。PROJECT / MAP / DECISIONS / topics 共享，不分工作流。详见 METHODOLOGY §3.5 + §4.7。

几个窗口同时开（v2.8，一个工作目录里几个窗口）：只写自己那条工作流的 STATUS / HANDOFF；共用文件（MAP / DECISIONS / PROJECT）只改自己那一处 —— 先重读、再定点改，不整份重写；按文件名暂存，每次提交前先 git diff --cached --stat；别的工作流管的范围（MAP §6）不动手，交给它：自己的 STATUS 记进「交给别的工作流的」，对方接下时记进它的「别的工作流交来的」，工具能给别的会话发消息就顺手发一条。详见 METHODOLOGY §3.6。

完整机制：见 METHODOLOGY.md §4。

MAP 自我校准规则：在 brain/MAP.md 末节。