rules-create-global

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create Rules: Set Up Your Project's Global Rules

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

Inputs: wire the arguments first

输入：先配置参数

This skill takes up to two optional paths and uses them to pick your lane. Read whatever was passed and classify each by its content:

```
$path1
```
: the first path, if any.
```
$path2
```
: the second path, if any.

A passed path that is...	Lane	Use it as
a PRD (intent, what/why, from `plan-create-prd` )	greenfield	product context (the "what this is"), NOT the source of technical rules
an architecture / spec doc (the how, from `plan-architecture` )	greenfield	the technical decisions your rules derive from (may be the same file as the PRD, if the architecture was folded in as an `## Architecture` section)
a codebase-analysis doc (a large-repo `/prime-codebase` + subagent fan-out)	brownfield	the source of "what is"

Pick the lane from what you were given:

Greenfield if a PRD and/or architecture path was passed, or the workspace is a bare scaffold: derive what should be from the architecture decisions (
```
$path2
```
, or
```
$path1
```
if that is where they live).
Brownfield if no path was passed, or a codebase-analysis path was: derive what is from the analysis doc if one was passed, otherwise from the primed codebase in this conversation.

Brownfield, not primed yet? If no path was passed and this conversation has not been primed on the code, run /prime-codebase
first (or offer to) so you derive from real files, then continue. Never invent rules from nothing.

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

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

传入的路径类型...	模式	用途
PRD（目标、内容/原因，来自 `plan-create-prd` ）	Greenfield	产品上下文（即“项目是什么”），不能作为技术规则的来源
架构/规范文档（实现方式，来自 `plan-architecture` ）	Greenfield	推导规则的技术决策依据（如果架构部分被整合为 `## Architecture` 章节，可能与PRD是同一文件）
代码库分析文档（大型仓库的 `/prime-codebase` + 子代理扩展输出）	Brownfield	现状参考来源

根据传入内容选择模式：

Greenfield模式：若传入了PRD和/或架构路径，或工作区为空白脚手架：从架构决策（
```
$path2
```
，若架构内容在
```
$path1
```
则使用该路径）推导应有的规则。
Brownfield模式：若未传入路径，或传入了代码库分析路径：若有分析文档则从文档推导现有规则，否则从对话中已预处理的代码库推导。

存量项目未预处理？ 若未传入路径且对话未对代码进行预处理，请先运行**
/prime-codebase
**（或主动提出运行），确保基于真实文件推导规则，之后再继续。禁止凭空生成规则。

What global rules are (30-second intro)

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

Your global rules — CLAUDE.md
(Claude-native) or AGENTS.md
(the open cross-tool standard) — are the always-on steering document, read on every task. Four kinds of content earn that always-on slot:

A map of the codebase — the dirs/files that matter, each with a one-line what it is + why it lives there.
Ground rules — the specific conventions this project follows (how you do type safety, your error philosophy, your git workflow). State the choice, not a slogan.
Commands the agent should run itself — the real lint / type-check / test / tooling CLIs (with their flags), so it can check its own work. (Not slash-commands — those are skills.)
Working principles (agent steering) — how you want the agent to operate here: its thinking/reasoning posture (plan before non-trivial work, ask when ambiguous instead of guessing, keep scope tight) and the engineering primitives you hold (fail fast, explicit errors, single responsibility, simplest thing that works). These don't live in the code — you state them. They're the part deriving-from-the-codebase can never produce — and the part an agent won't reliably follow unless you make it explicit.

It's all composition. Rules, references, and skills are just markdown the agent loads when it needs them — so any of the above can live always-on or in an on-demand

references/

doc or in a skill; you choose where each piece lives. Everything not needed every task loads on demand, or belongs in a per-task plan — not here.

你的全局规则文件——CLAUDE.md
（Claude原生格式）或**

AGENTS.md

（跨工具开放标准）——是始终生效的指导文档**，每次任务都会读取。以下四类内容适合放入该文件：

代码库地图——重要的目录/文件列表，每个条目用一行说明“是什么+存在的原因”。
基础规则——项目遵循的具体约定（类型安全实现方式、错误处理理念、Git工作流等）。需明确说明选择，而非空泛口号。
代理应自行运行的命令——真实的 lint/类型检查/测试/工具CLI命令（含参数），以便代理能自检工作成果。（注意：不是斜杠命令——那些属于skills。）
工作原则（代理指导）——你希望代理在此项目中的操作方式：思考/推理模式（非琐碎工作前先规划、歧义时询问而非猜测、严格控制范围）以及你秉持的工程准则（快速失败、显式错误、单一职责、最简可行方案）。这些内容不会出现在代码中——需要你明确声明。这是从代码库推导无法得到的部分，且只有明确声明，代理才会可靠遵循。

一切皆为组合。规则、参考资料和skills只是代理需要时加载的Markdown文件——因此上述内容既可以放在全局规则中，也可以放在按需加载的

references/

文档或某个skill中，由你决定每个内容的存放位置。所有非每次任务都需要的内容应按需加载，或放入特定任务的计划中——而非全局规则。

Two situations, one motion

两种场景，同一流程

Global rules encode technical truth — so you derive them from technical decisions, never from a product spec:

You have...	Derive rules from...	"Truth" is...
Greenfield, a new project, mostly a scaffold	your architecture decisions (the technical "how" you settled with the AI), passed as `$path2`	what should be
Brownfield, an existing codebase with no AI Layer	your primed codebase ( `/prime-codebase` ), or a codebase-analysis doc passed as a path for a large repo	what is

Greenfield note: your rules come from your architecture decisions (the spec), not the PRD. The flow: discuss what you're building with the AI and capture it as a PRD (
plan-create-prd
), then settle the architecture with
plan-architecture
(stack, patterns, directory structure, conventions). Those decisions are what this skill derives rules from. A PRD captures the product (what/why): useful context, but technical rules don't live there.

Brownfield note: this skill does not explore the codebase for you. Prime first: run /prime-codebase
so the structure, key files, and conventions are loaded into this conversation, then run this skill with no path. (Large repo? Optionally fan out a few built-in subagents to explore areas in parallel, aggregate a short
codebase-analysis.md
, and pass that path instead.) This skill packages the derive → extract → seams → prune → check steps, not the exploration.

Before you run this — protect any existing rules. If the project already has a
CLAUDE.md
/
AGENTS.md
, copy or rename it first (e.g.
CLAUDE.md.bak
) so this skill doesn't overwrite something you want to keep. Even better, feed it in as input — point the skill at it ("read my existing
CLAUDE.md
first") so the derivation builds on what's already there instead of starting from scratch.

全局规则编码技术事实——因此需从技术决策推导，而非产品规格：

你拥有...	规则推导来源...	“事实”指...
Greenfield，新项目，多为空白脚手架	你的架构决策（与AI确定的技术“实现方式”），传入为 `$path2`	应有的规则
Brownfield，无AI Layer的现有代码库	你的预处理代码库（ `/prime-codebase` ），或传入大型仓库的代码库分析文档路径	现有的规则

Greenfield模式注意事项：规则来自你的架构决策（规范），而非PRD。流程：与AI讨论要构建的内容并整理为PRD（
plan-create-prd
），然后通过
plan-architecture
确定架构（技术栈、模式、目录结构、约定）。这些决策才是本技能推导规则的依据。PRD记录的是产品（内容/原因）：作为有用的上下文，但技术规则不会来源于此。

Brownfield模式注意事项：本技能不会为你探索代码库。请先预处理：运行**
/prime-codebase
**，将代码结构、关键文件和约定加载到对话中，然后不带路径运行本技能。（大型仓库？可选择调用几个内置子代理并行探索不同区域，汇总生成简短的
codebase-analysis.md
，然后传入该路径。）本技能包含的是推导→提取→梳理→精简→检查步骤，而非代码探索。

运行前注意——保护现有规则：若项目已存在
CLAUDE.md
/
AGENTS.md
，请先复制或重命名（例如
CLAUDE.md.bak
），避免本技能覆盖你需要保留的内容。更好的方式是将其作为输入传入——让技能先读取现有
CLAUDE.md
，以便在已有内容基础上推导规则，而非从零开始。

Required reading (do this first) — and pick the file

必读内容（先完成）——选择规则文件

First, which rules file does this project use? Detect it, then read the matching guidance (don't rely on a snapshot):

CLAUDE.md
(Claude Code's native file) → Anthropic memory + best practices: https://code.claude.com/docs/en/memory · https://code.claude.com/docs/en/best-practices
AGENTS.md
(the open cross-tool standard, read by dozens of agents) → the AGENTS.md spec: https://agents.md
Both present? Usually the shared content lives in AGENTS.md
and
```
CLAUDE.md
```
is a single line —
```
@AGENTS.md
```
— so Claude Code auto-loads AGENTS.md and there's one source of truth. In that case, write to AGENTS.md.
Neither yet?
```
CLAUDE.md
```
for a Claude-Code-only project;
```
AGENTS.md
```
if the team is multi-tool.

Content + structure are ~90% identical either way — everything below is "your rules file," not one vendor's. Use the structure laid out below (it works as an AGENTS.md just as well).

首先，确定项目使用哪种规则文件？ 检测后阅读对应指南（不要依赖快照）：

CLAUDE.md
（Claude Code原生文件）→ Anthropic内存+最佳实践： https://code.claude.com/docs/en/memory · https://code.claude.com/docs/en/best-practices
AGENTS.md
（跨工具开放标准，被数十个代理支持）→ 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）。

The methodology (bake this in)

方法论（融入流程）

What goes always-on: the map + ground rules (specific conventions) + the working principles (agent steering). Everything true project-wide, every task.
Working principles are elicited, not derived. The map + ground rules come from the code/decisions; the working principles come from you — so ask: "how should the agent work here — plan-first? clarify before coding? scope discipline? which engineering primitives do you hold?" Keep only the ones that actually change behavior and reflect your stance — not a generic lecture the model already follows.
The four destinations — sort every candidate line:
- Keep always-on → map / ground rules.
- Push to on-demand → a recurring but task-type-specific pattern → an on-demand reference (
```
.claude/references/<topic>.md
```
  on Claude Code; anywhere your tool looks — e.g.
```
.agent/
```
  — it's just markdown) or a skill.
- Move to a plan → task-specific "what to build next" content → it was never a rule.
- Delete → redundant, or a slogan the model already follows ("write clean code", "KISS/DRY").
State the choice, not the slogan: "derive types with
```
z.infer
```
", not "type safety is critical".
Brownfield = "what is", not "what should be": every rule must point to the file that proves it; if you can't, leave it out. Aspirational rules make the agent fight the codebase.
Lean: don't bloat it to the point it eats context or the agent starts ignoring its own rules. No magic line number — cut anything that wouldn't cause a mistake if removed.

全局规则包含内容：地图+基础规则（具体约定）+工作原则（代理指导）。所有项目范围内、每次任务都需要的内容。
工作原则需主动询问，而非推导。地图+基础规则来自代码/决策；工作原则来自你——因此需询问用户：“代理在此项目中应如何工作——先规划？编码前先澄清？严格控制范围？你秉持哪些工程准则？”仅保留能实际改变行为且反映你的立场的原则——而非模型已默认遵循的通用内容。
四个处理方向——对每个候选内容分类：
- 保留在全局规则 → 地图/基础规则。
- 移至按需加载 → 重复出现但特定任务类型的模式 → 按需参考文档（Claude Code中为
```
.claude/references/<topic>.md
```
  ；其他工具中可放在任意指定位置——例如
```
.agent/
```
  ——本质都是Markdown）或skill。
- 移至计划 → 特定任务的“下一步构建内容” → 这从不属于规则。
- 删除 → 冗余内容，或模型已默认遵循的口号（如“编写整洁代码”、“KISS/DRY”）。
明确说明选择，而非空泛口号：例如“使用
```
z.infer
```
推导类型”，而非“类型安全至关重要”。
Brownfield模式=“现状”，而非“理想状态”：每条规则必须指向能证明它的文件；若无法找到，请勿添加。理想化规则会导致代理与代码库冲突。
简洁：不要过度膨胀，避免占用过多上下文或导致代理忽略规则。没有固定行数限制——删除任何移除后不会引发错误的内容。

Workflow

工作流程

1. Read the inputs

1. 读取输入

Greenfield: read the architecture / spec doc you passed as
```
$path2
```
(or
```
$path1
```
, if that is where the architecture lives): stack, patterns, directory structure, conventions, security choices, plus any scaffold files. (A PRD passed as
$path1
is product context: read it for what you're building and why, not for the technical rules.) No path passed but the workspace is a fresh scaffold? Ask for the architecture doc, or settle the decisions now with
```
plan-architecture
```
first.
Brownfield: derive from the primed codebase already loaded in this conversation (from
```
/prime-codebase
```
); or, if a
```
codebase-analysis.md
```
path was passed, read that (with its file:line citations). Spot-check the actual code either way. Not primed and no path passed? Run
```
/prime-codebase
```
first.
If a rules file already exists: read it first and treat it as a starting point — and make sure it's backed up (see "protect any existing rules" above) so nothing you wrote by hand is lost.
Read the best-practices docs above. Follow the structure laid out in this skill.

Greenfield模式：读取传入的架构/规范文档（
```
$path2
```
，若架构内容在
```
$path1
```
则使用该路径）：技术栈、模式、目录结构、约定、安全选择，以及任何脚手架文件。（传入
```
$path1
```
的PRD是产品上下文：读取以了解要构建的内容及原因，而非技术规则。）若未传入路径但工作区为空白脚手架？询问用户提供架构文档，或先通过
```
plan-architecture
```
确定决策。
Brownfield模式：从对话中已加载的预处理代码库（来自
```
/prime-codebase
```
）推导；若传入了
```
codebase-analysis.md
```
路径，则读取该文档（含文件:行引用）。无论哪种方式，都需抽查实际代码。若未预处理且未传入路径？先运行
```
/prime-codebase
```
。
若已存在规则文件：先读取并将其作为起点——确保已备份（见上方“保护现有规则”），避免手动编写的内容丢失。
阅读上方的最佳实践文档。遵循本技能列出的结构。

2. Derive the root

CLAUDE.md

2. 生成根目录

CLAUDE.md

Fill the template's sections, sourced from the input:

What this is — one paragraph + the stack in one line.
Architecture map — the tree of dirs/files that matter, one-line what/why each.
Ground rules — the specific conventions (greenfield: decided in your architecture spec, not the PRD; brownfield: observed in the code, each traceable to a file).
Working principles (agent steering) — ask the user (this can't be derived from code): how should the agent operate here? Capture the thinking/reasoning posture (plan-first, clarify-don't-guess, scope discipline, verify against the real suite) + the engineering primitives they hold (fail fast, explicit errors, single responsibility, simplest-thing-that-works). State the project's actual stance; keep it lean.
Commands — the few you actually run (install / test / type-check / lint / run).
On-demand pointers — where detail loads when needed. Don't dump the PRD or the analysis in. Link to them.

Fill the template's sections, sourced from the input:

项目概述——一段描述+一行技术栈说明。
架构地图——重要目录/文件的树形结构，每个条目用一行说明内容及存在原因。
基础规则——具体约定（Greenfield模式：来自架构规范中的决策，而非PRD；Brownfield模式：从代码中观察到的，每条都可追溯到具体文件）。
工作原则（代理指导）——询问用户（无法从代码推导）：代理在此项目中应如何操作？记录思考/推理模式（先规划、澄清而非猜测、范围管控、对照真实测试套件验证）+ 用户秉持的工程准则（快速失败、显式错误、单一职责、最简可行方案）。明确项目的实际立场；保持简洁。
命令——实际常用的少数命令（安装/测试/类型检查/lint/运行）。
按需参考指向——需要时加载详细内容的位置。请勿直接粘贴PRD或分析文档内容，应链接到它们。

3. Extract on-demand context

3. 提取按需上下文

Pull recurring, task-type-specific patterns out into

.claude/references/<topic>.md

stubs (a paragraph each, not full docs). Test: does it recur every time you touch that area? → guide. One-off → leave in the source doc.

将重复出现的特定任务类型模式提取到

.claude/references/<topic>.md

** stub文件**（每个文件一段内容，无需完整文档）。判断标准：每次处理该领域内容时都会用到吗？ → 是则放入。一次性内容则留在源文档中。

4. Find the seams

4. 梳理集成点

Add a short "where new code goes" section — the interfaces/folders where new work plugs in. This is what makes the agent extend the codebase instead of bolting on. (Greenfield: the seams are designed from the architecture, not discovered.)

添加简短的**“新代码存放位置”章节——新工作内容接入的接口/文件夹。这能让代理扩展代码库，而非简单附加。（Greenfield模式：集成点是从架构中设计**出来的，而非发现的。）

5. Prune to lean

5. 精简内容

First draft is always too big. Delete generic advice, restated defaults, and anything that can't point to its evidence. Apply the per-line test: would removing this cause a mistake? If not, cut it.

初稿通常过于冗长。删除通用建议、重复的默认内容，以及无法提供依据的内容。对每一行进行测试：移除这一行会导致错误吗？若不会，删除它。

6. Report

6. 输出报告

Files created/changed.
A 3–5 line summary of what went into
```
CLAUDE.md
```
and why.
What was pushed to on-demand context (and where).
Next step: the rules are ready — start the first PIV loop.

创建/修改的文件列表。
3-5行总结
```
CLAUDE.md
```
的内容及生成原因。
移至按需上下文的内容及存放位置。
下一步：规则已准备就绪——启动第一个PIV循环。

Quality checks

质量检查

✅ Root
```
CLAUDE.md
```
is a map + ground rules, not documentation or a PRD/analysis copy.
✅ Every ground rule is a specific choice (brownfield: traceable to a file) — no slogans.
✅ A working-principles / agent-steering section exists — elicited from the user (plan / clarify / scope posture + engineering primitives), lean and behavior-changing, not generic filler.
✅ Recurring task-type detail lives in
```
.claude/references/
```
, not always-on.
✅ Lean enough that nothing earns its slot without paying rent.

✅ 根目录
```
CLAUDE.md
```
是地图+基础规则，而非文档或PRD/分析文档的副本。
✅ 每条基础规则都是具体选择（Brownfield模式：可追溯到文件）——无空泛口号。
✅ 存在工作原则/代理指导章节——从用户处获取（规划/澄清/范围模式+工程准则），简洁且能改变行为，非通用填充内容。
✅ 重复出现的特定任务细节存放在
```
.claude/references/
```
，而非全局规则。
✅ 足够简洁，所有内容都有存在的必要。

Notes

注意事项

Rules evolve — revisit
```
CLAUDE.md
```
as the project grows and after major model releases, and run
```
/rules-check-drift
```
before merges so the map never drifts.
Greenfield: run after you've settled the architecture with
```
plan-architecture
```
(and after
```
plan-create-prd
```
, if you wrote a PRD for the product); pass those paths in as
```
$path1
```
(PRD) and
```
$path2
```
(architecture). Brownfield: run after
```
/prime-codebase
```
, or after a large-repo fan-out produces a
```
codebase-analysis.md
```
you pass in.

规则会演进——随着项目发展和模型重大更新，重新审视
```
CLAUDE.md
```
，并在合并前运行
```
/rules-check-drift
```
，确保地图不会与实际代码脱节。
Greenfield模式：在通过
```
plan-architecture
```
确定架构后（若编写了产品PRD，也需在
```
plan-create-prd
```
之后）运行；将PRD和架构路径分别传入
```
$path1
```
（PRD）和
```
$path2
```
（架构）。Brownfield模式：在
```
/prime-codebase
```
之后运行，或在大型仓库扩展生成
```
codebase-analysis.md
```
并传入该路径后运行。

rules-create-global

Original

Translation

Create Rules: Set Up Your Project's Global Rules

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

Inputs: wire the arguments first

输入：先配置参数

What global rules are (30-second intro)

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

Two situations, one motion

两种场景，同一流程

Required reading (do this first) — and pick the file

必读内容（先完成）——选择规则文件

The methodology (bake this in)

方法论（融入流程）

Workflow

工作流程

1. Read the inputs

1. 读取输入

2. Derive the root
`CLAUDE.md`

2. 生成根目录
`CLAUDE.md`

3. Extract on-demand context

3. 提取按需上下文

4. Find the seams

4. 梳理集成点

5. Prune to lean

5. 精简内容

6. Report

6. 输出报告

Quality checks

质量检查

Notes

注意事项

rules-create-global

Original

Translation

Create Rules: Set Up Your Project's Global Rules

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

Inputs: wire the arguments first

输入：先配置参数

What global rules are (30-second intro)

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

Two situations, one motion

两种场景，同一流程

Required reading (do this first) — and pick the file

必读内容（先完成）——选择规则文件

The methodology (bake this in)

方法论（融入流程）

Workflow

工作流程

1. Read the inputs

1. 读取输入

2. Derive the root CLAUDE.md

2. 生成根目录CLAUDE.md

3. Extract on-demand context

3. 提取按需上下文

4. Find the seams

4. 梳理集成点

5. Prune to lean

5. 精简内容

6. Report

6. 输出报告

Quality checks

质量检查

Notes

注意事项

2. Derive the root
`CLAUDE.md`

2. 生成根目录
`CLAUDE.md`