用途：把代码变更中隐含的工程决策提炼为显式规则，存放在 docs/rules/ 下，供智能体与人类遵循，避免重复推导。流程为交互式，写入前需用户确认规则及其措辞，不可跳过确认环节。
主要能力与用法：
- 确定范围：运行 git status --porcelain；若有未提交改动（暂存、未暂存或未跟踪）即以这些文件为范围，否则询问具体提交或落后当前分支的提交数，默认建议 HEAD。排除无工程决策的文件（如 .agents/、skills-lock.json、锁文件、生成文件），并说明排除了哪些。
- 阅读变更：读取范围内的 diff（git diff、git diff --cached 或 git show/git diff HEAD~N）及周边文件，理解改动原因。
- 提炼规则：规则是通用原则，而非对某次 diff 的描述。每条规则须归入固定顶层分类之一：Infrastructure（Deployment、CI、Scaffolding、Docker、Folders）、Application（Framework、Security、Domain、Common）、Test（E2E、Unit、Performance、Integration）、Database（Persistence）、Documentation（Markdown）。顶层分类固定，子分类可新增并明确说明。跨子分类时逐个处理，其余暂存。每条规则需展示推理并等待用户确认。
- 与现有规则对照：规则位于 docs/rules/<category>/<subcategory>.md（小写 kebab-case）。分类为 Add、Update（保留原编号）或 Conflict（呈现两版由用户决定，不得静默覆盖）。
- 形式化：使用固定模板，标题为 ## <category>-<subcategory>-0000: <短标题>，含 WHEN、THEN、Example。编号按文件从 0001 起，标识符永久，不重编号、不复用已删除编号。标题约六词以内，陈述立场而非主题。示例须基于本仓库真实路径与名称，优先用列表、前后对比表或代码片段。
- 写入：写入目标文件，必要时创建目录与文件；新文件以 # <Category> / <Subcategory> 开头；新规则追加在末尾，按标识符顺序排列；## 标题是唯一分隔，不加水平线。
- 精简：重读刚写入的规则，删去重复、旁白、多余限定与示例行，只简化措辞不改实质，直接应用到文件，无需再次确认，并在总结时说明删减内容。
- 指向规则：仅当本次会话写入仓库首条规则时执行。读取仓库的智能体指南，若已有 docs/rules/ 章节则无需处理；否则询问用户是否添加 Coding Rules 章节，展示确切文本与位置，未经同意不得写入。
适用场景：从代码审查纠正、diff 确立的约定中沉淀规则，供后续变更遵循。
限制：分类固定不可自创顶层；标识符永久；冲突不得静默覆盖；写入前必须用户确认；未提供具体收费、平台或效果信息。