chief-rule

你正在帮助用户将一条规则记录到 .chief/_rules/ 中。这是 /chief-retro 的主动对应方式——只要用户心中有一条规则并想立即写下来，就使用此流程。

每次调用只能记录一条规则（路径 2），或仅搭建目录结构（路径 1）。如需记录更多规则，请重新运行。

步骤

1. 预检

只检查——此时不要创建任何内容。记录以下信息，供后续使用：

• .chief/ 是否存在
• .chief/_rules/ 是否存在
• .chief/_rules/README.md 是否存在

目录结构搭建（创建 .chief/、.chief/_rules/ 和 README）要在所选路径的末尾进行，而不是现在。如果用户中途退出，文件系统应保持不变。

2. 访谈前分流

向用户询问，并且只能提供两个选项：

选择一项：

1. 仅搭建 .chief/_rules/（我稍后会手动编写规则，或在工作完成后使用 /chief-retro）
2. 采访我——现在编写一条规则

如果选择 1 → 执行下面的搭建目录结构流程，然后停止。 如果选择 2 → 继续步骤 3。（稍后在步骤 7 中，与规则写入一起搭建目录结构。）

搭建目录结构流程（路径 1 使用；如果 _rules/ 不存在，路径 7 也使用）

1. 如果 .chief/ 不存在，则创建它。

2. 如果 .chief/_rules/ 不存在，则创建它。

3. 如果 .chief/_rules/README.md 不存在，则写入以下内容：

   # .chief/_rules/
   
   Global rules that govern this project's autonomous AI work. Lower priority than `AGENTS.md`, higher than milestone goals.
   
   ## Categories
   
   - `_standard/` — Coding standards, architecture constraints
   - `_contract/` — Data models, API contracts, schemas
   - `_goal/` — High-level goals (shared across milestones)
   - `_verification/` — Test commands, build requirements, definition of done
   
   Subfolders are created **lazily** — on first rule in that category. Empty subfolders are not required.
   
   Use `/chief-rule` to add rules proactively, or `/chief-retro` to capture them after a milestone retrospective.
   

4. 不要创建四个类别子目录。它们会在各自类别中首次添加规则时再创建。

完成路径 1 的目录结构搭建后：告知用户 README 的路径，然后停止。

3. 访谈（每次只问一个重点问题）

分别询问每个问题。等用户回答后再继续。问题要简短。如果用户回答“skip”或“n/a”，则跳过对应问题——但不要跳过 Q1（内容）。

1. 规则是什么？——用一句话陈述规则。
2. 为什么需要这条规则？——说明动机：事件、偏好、约束或决策。
3. 何时、何处适用？——适用范围：始终适用／特定区域／特定里程碑／特定文件类型等。
4. 有代码或文本示例吗？——可选。提供一段简短片段，展示正确与错误的写法，或给出具体示例。
5. 文件名？——使用简短的 kebab-case 名称（例如 commit-style、db-naming、pr-size）。无需添加 .md 后缀。

4. 分类

根据用户的回答，建议归入以下四个类别之一：

• _standard/ — 编码规范、命名、格式、架构约束、“我们如何编写代码”
• _contract/ — 数据模型、API 契约、架构、类型级不变量
• _goal/ — 跨里程碑共享的高层目标、产品方向
• _verification/ — 测试命令、构建要求、完成定义、CI 门禁

告知用户你选择的类别及原因（一句话）。请用户确认或改选。

5. 起草文件

使用纯 Markdown，不添加 frontmatter来撰写草稿：

# <The rule statement, as a single declarative sentence>

**Why:** <motivation from Q2>

**How to apply:** <scope from Q3>

## Example

<code or prose example from Q4 — omit this section if user skipped Q4>

向用户展示渲染后的草稿。只询问一次：“要将此内容写入 .chief/_rules/<category>/<filename>.md 吗？”

如果用户要求修改，则应用修改并重新展示。最多进行三轮修改——如果始终无法达成一致，就写入当前草稿，并告知用户可以手动编辑。

6. 冲突处理（基于内容）

写入前，检查 .chief/_rules/<category>/<filename>.md 是否已存在。

如果存在，先读取现有文件，然后判断两者的关系并提出恰当的处理方式：

关系	判断信号	操作
完全相同	新规则的陈述、原因和应用方式与现有规则基本一致	跳过。告知用户该规则已收录。停止。
细化／扩展	关注点相同，但新规则补充了细节（例如明确范围、添加示例、措辞更严谨）	合并：生成统一版本，并保留两者的内容。展示差异。将现有文件备份为 <filename>.md.bak。确认后写入。
相矛盾	新规则推翻或取代了现有规则	替换：并排展示旧规则与新规则。将现有文件备份为 <filename>.md.bak。确认后写入。
关注点不同，但文件名冲突	虽然文件名相同，但现有文件的 H1／原因讨论的是不同内容	建议改用更具体的文件名。返回步骤 3 的问题 5（文件名），继续询问用户。

绝不在未备份到 .bak 的情况下覆盖。绝不跳过冲突时的先读后写步骤。

7. 写入并报告

1. 如果 .chief/_rules/ 尚不存在，先运行步骤 2 中的脚手架例程（创建 .chief/、.chief/_rules/ 和 _rules/README.md）。
2. 如果目标类别子文件夹不存在，则创建它（这是延迟创建点）。例如：.chief/_rules/_standard/。
3. 写入规则文件。

然后报告：

• 写入路径
• 备份路径（如果冲突触发了 .bak）
• 提醒：chief-agent 会在下次读取 .chief/_rules/** 时加载此规则

停止。不要询问“还要添加一条吗？”——每次调用只处理一条规则。用户可重新运行以处理下一条。

重要规则

• 此技能仅创建规则文件（以及首次运行时的 .chief/_rules/README.md）。不要搭建里程碑、project.md 或任何其他内容。
• 绝不创建空的类别子文件夹——类别子文件夹按需创建。只有首次添加对应类别的规则时，才创建 _standard/、_contract/、_goal/ 或 _verification/。
• 绝不在没有 .bak 备份且未获得用户确认的情况下覆盖现有规则文件。
• 绝不读取或修改 .chief/_rules/ 之外的文件（但如需了解上下文，可以读取 AGENTS.md——通常并不需要）。
• 保持访谈简短。每次只问一个重点问题，不要提出复合问题。
• 使用纯 Markdown。不要添加 frontmatter。仓库中现有的 .chief/_rules/ 文件都是纯 Markdown——保持这一惯例。
• 如果用户选择路径 1（仅搭建脚手架），不要继续访谈。写入 README 后即停止。