rules-create-global

创建规则：设置项目的全局规则

输入：先接入参数

此技能最多接受 两个可选路径，并据此选择处理方式。读取传入的内容，并按内容分类：

• $path1：第一个路径（如有）。
• $path2：第二个路径（如有）。

传入的路径是……	处理方式	用途
PRD（意图、做什么／为什么，来自 plan-create-prd）	全新项目	产品背景（“这是做什么的”），而不是技术规则的来源
架构／规范文档（如何实现，来自 plan-architecture）	全新项目	规则所依据的技术决策（可能与 PRD 是同一个文件，如果架构内容已合并到 ## Architecture 一节中）
代码库分析文档（大型仓库的 /prime-codebase + 子 Agent 分析）	既有项目	“现状”的来源

根据传入内容选择处理方式：

• 全新项目：如果传入了 PRD 和／或架构路径，或者工作区只是一个空白脚手架，则根据架构决策（$path2，或架构内容所在的 $path1）推导出应该是什么。
• 既有项目：如果没有传入路径，或者传入的是代码库分析路径，则根据分析文档（如有）推导出现状；否则根据本次对话中已检查的代码库推导。

既有项目尚未检查代码？ 如果没有传入路径，且本次对话尚未检查代码，请先运行 /prime-codebase（或提出运行建议），以便从实际文件中推导，然后再继续。切勿凭空编造规则。

全局规则是什么（30 秒简介）

你的全局规则——CLAUDE.md（Claude 原生）或 AGENTS.md（开放的跨工具标准）——是始终生效的指导文档，每项任务都会读取。以下四类内容适合纳入这份始终生效的文档：

1. 代码库地图——列出重要目录／文件，并各用一句话说明它是什么，以及为什么放在那里。
2. 基本规则——项目遵循的具体约定（如何确保类型安全、错误处理理念、Git 工作流）。陈述具体选择，而不是空泛口号。
3. Agent 应自行运行的命令——真实的 lint／类型检查／测试／工具 CLI（含其标志），让 Agent 能自行检查工作成果。（不是斜杠命令——那些属于技能。）
4. 工作原则（Agent 指导）——你希望 Agent 在此处如何行动：思考／推理方式（非简单工作先制定计划；遇到歧义时先询问，不要猜；严格控制范围），以及你坚持的工程原则（快速失败、明确错误、单一职责、采用能解决问题的最简单方案）。**这些原则不会体现在代码中——需要由你明确说明。**从代码库中推导永远无法得出这些原则；如果不明确写出，Agent 也无法可靠遵循。

一切都是内容组合。 规则、参考资料和技能都只是 Agent 在需要时加载的 Markdown 内容——上述任何内容都可以放在始终生效的文档、按需加载的 references/ 文档或技能中；由你决定每项内容放在哪里。不是每项任务都需要加载的内容应按需加载，或放在单项任务的计划中——而不是放在这里。

两种情况，一种操作

全局规则描述的是技术事实，因此应从技术决策中推导，绝不能从产品规格中推导：

你有……	从……推导规则	“事实”是……
Greenfield，一个新项目，基本上只是脚手架	你的架构决策（你与 AI 确定的技术“实现方式”），通过 $path2 传入	应该是什么
Brownfield，一个没有 AI 层的现有代码库	你已预热的代码库（/prime-codebase），或在大型仓库中通过路径传入的代码库分析文档	是什么

Greenfield 说明： 规则源自你的架构决策（规格），而不是 PRD。流程：先与 AI 讨论你要构建的内容，并将其记录为 PRD（plan-create-prd），然后通过 plan-architecture 确定架构（技术栈、模式、目录结构、约定）。这些决策才是此技能推导规则的依据。PRD 描述的是产品（是什么／为什么）：这是有用的背景信息，但技术规则不在其中。

Brownfield 说明： 此技能不会替你探索代码库。请先预热：运行**/prime-codebase**，将结构、关键文件和约定加载到此对话中，然后不带路径运行此技能。 （仓库很大？你可以选择调用几个内置子 Agent 并行探索不同区域，汇总成一份简短的 codebase-analysis.md，然后传入该路径。）此技能包含推导 → 提取 → 缝隙 → 精简 → 检查 这些步骤，而不是探索。

运行前——保护现有规则。 如果项目已有 CLAUDE.md／ AGENTS.md，请先复制或重命名（例如 CLAUDE.md.bak），以免此技能覆盖你想保留的内容。更好的做法是将其作为输入——告诉技能（“先读取我现有的 CLAUDE.md”），这样推导过程就会基于现有内容，而不是从头开始。

必读内容（请先阅读）——并选择文件

首先，这个项目使用哪个规则文件？ 先检测，再阅读对应的指南（不要依赖快照）：

• CLAUDE.md（Claude Code 的原生文件）→ Anthropic 记忆与最佳实践： https://code.claude.com/docs/en/memory · https://code.claude.com/docs/en/best-practices
• AGENTS.md（开放的跨工具标准，数十种 Agent 都会读取）→ AGENTS.md 规范：https://agents.md
• 两者都有？ 通常共享内容位于 AGENTS.md 中，而 CLAUDE.md 只有一行—— @AGENTS.md——这样 Claude Code 会自动加载 AGENTS.md，并且只有一个事实来源。这种情况下，请写入 AGENTS.md。
• 两者都没有？ 仅使用 Claude Code 的项目选 CLAUDE.md；团队使用多种工具时选 AGENTS.md。

无论选择哪种方式，内容和结构都约有 90% 相同——下文所说的都是**“你的规则文件”**，而非某个厂商的文件。 请使用下文所列的结构（它同样适用于 AGENTS.md）。

方法论（将其融入其中）

• 始终加载哪些内容： 地图 + 基本规则（具体约定）+ 工作原则 （Agent 引导）。适用于整个项目、每项任务的内容。
• 工作原则应当征询，而非推导。 地图 + 基本规则来自代码/决策；工作原则来自你——所以要询问：“Agent 在这里应该如何工作——先规划？编码前先澄清？严格控制范围？你坚持哪些工程基本原则？”只保留那些确实会改变行为并反映你的立场的原则——不要写模型本来就遵循的泛泛说教。
• 四种归类方式——对每条候选内容进行分类：
  • 始终保留 → 地图 / 基本规则。
  • 移至按需加载 → 反复出现但仅适用于特定任务类型的模式 → 按需参考文档（Claude Code 使用 .claude/references/<topic>.md；也可以放在工具会查找的位置，例如 .agent/——它就是 Markdown 文件）或技能。
  • 移入计划 → 特定任务的“接下来要构建什么”内容 → 它本来就不是规则。
  • 删除 → 冗余内容，或模型本来就会遵循的口号（“编写整洁的代码”、“KISS/DRY”）。
• 说明具体做法，而非口号： “使用 z.infer 推导类型”，而非“类型安全至关重要”。
• 棕地项目 = “现状”，而非“应然”： 每条规则都必须指向能够证明它的文件；如果无法做到，就不要写。理想化规则会让 Agent 与代码库对着干。
• 精简： 不要写得臃肿，以免占用过多上下文，或导致 Agent 开始忽略自己的规则。没有神奇的行数限制——删掉移除后不会导致错误的内容。

工作流

1. 阅读输入

• 绿地项目： 阅读通过 $path2 传入的架构 / 规格文档（如果架构内容在 $path1 中，则读取 $path1）：技术栈、模式、目录结构、约定、安全选型，以及任何脚手架文件。（通过 $path1 传入的 PRD 属于产品背景：阅读它以了解要构建什么以及为什么，而不是技术规则。） 如果没有传入路径，但工作区是全新的脚手架？请索取架构文档，或先通过 plan-architecture 确定这些决策。
• 棕地项目： 从本次对话中已加载的预热代码库（来自 /prime-codebase）推导；或者，如果传入了 codebase-analysis.md 路径，就读取该文件（及其中的文件:行号引用）。无论哪种方式，都要抽查实际代码。代码库未预热且未传入路径？先运行 /prime-codebase。
• 如果已有规则文件： 先读取它，并将其作为起点——同时确保已做好备份（见上文“保护任何现有规则”），避免丢失你手动编写的内容。
• 阅读上文提到的最佳实践文档。遵循此技能规定的结构。

2. 推导根目录 CLAUDE.md

根据输入填写模板的各个部分：

• 项目简介——一段话 + 一行技术栈。
• 架构地图——列出重要目录/文件的树状结构，并逐项用一句话说明其用途。
• 基本规则——具体约定（绿地项目：由架构规格文档决定，而非 PRD；棕地项目：从代码中观察所得，且每条规则都能追溯到文件）。
• 工作原则（Agent 引导）——询问用户（无法从代码推导）：Agent 在这里应该如何运作？记录思考/推理方式（先规划、澄清而不猜测、严格控制范围、对照实际测试套件验证）+ 用户坚持的工程基本原则（快速失败、明确报错、单一职责、以可行方案为准求简单）。说明项目的实际立场，并保持精简。
• 命令——实际会运行的少数命令（安装 / 测试 / 类型检查 / lint / 运行）。
• 按需加载指引——需要时加载详细信息的位置。 不要把 PRD 或分析内容全部塞进去。提供它们的链接。

3. 提取按需上下文

将反复出现、特定任务类型的模式提取到 .claude/references/<topic>.md 存根中（每个存根一段，而非完整文档）。测试：每次处理该领域时都会重复出现吗？ → 放入指南。只出现一次 → 留在源文档中。

4. 找到接入点

添加一个简短的 **“新代码放在哪里”**部分——说明新工作接入的接口／文件夹。这能让 Agent 扩展代码库，而不是另起炉灶。（全新项目：接入点是根据架构设计出来的，而非发现出来的。）

5. 精简内容

初稿总是太长。删除通用建议、重复陈述的默认设置，以及任何无法指出依据的内容。逐行检查：删掉这一行会导致错误吗？如果不会，就删掉。

6. 汇报

• 创建／更改的文件。
• 用 3–5 行总结 CLAUDE.md 中写入了什么，以及原因。
• 哪些内容移到了按需上下文中（以及所在位置）。
• 下一步：规则已就绪——开始第一个 PIV 循环。

质量检查

• ✅ 根目录的 CLAUDE.md 是地图 + 基本规则，而非文档或 PRD／分析副本。
• ✅ 每条基本规则都是一个具体选择（现有项目：可追溯到某个文件）——没有口号。
• ✅ 存在一个工作原则／Agent 引导部分——由用户提供信息得出（规划／澄清／范围把握的方式 + 工程原语），内容精简且能改变行为，而非泛泛的填充内容。
• ✅ 反复出现的特定任务类型细节放在 .claude/references/ 中，而非始终加载。
• ✅ 内容足够精简，每一项都物有所值。

备注

• 规则会演进——随着项目发展以及主要模型版本发布，重新审视 CLAUDE.md，并在合并前运行 /rules-check-drift，确保地图始终与实际情况一致。
• 全新项目：在通过 plan-architecture 确定架构之后运行（如果为产品编写了 PRD，也要在 plan-create-prd 之后运行）；将这些路径作为 $path1（PRD）和 $path2（架构）传入。现有项目：在 /prime-codebase 之后运行，或在大型仓库的并行分析生成 codebase-analysis.md 并将其传入之后运行。