Rule Creator 是一个用于创建和管理用户规则（user rules）的技能，这些规则是自定义指令，用于修改 AI 助手的行为，使其适配项目需求和个人偏好。
【用途】 用户规则可以定义编码标准（风格、模式与约定）、语言偏好（回复语言、术语）、项目配置（框架选择、文件结构）以及工作流程指南（Git、测试、文档实践）。
【规则创建工作流】
- 识别规则用途：询问用户想修改什么行为、是项目规则（共享）还是个人偏好、是否存在例外。
- 选择规则分类：常见分类包括 coding-style（代码格式、语法偏好）、language（回复语言、沟通风格）、project（框架相关、架构决策）、git（提交信息、分支、PR 指南）、naming（变量、函数、文件命名约定）、security（认证、密钥、输入校验）、testing（测试覆盖率、命名、mock 实践）、documentation（注释、README、JSDoc 要求）。模板与示例见 references/rule-patterns.md。
- 编写规则：原则为具体（使用具体示例）、可执行（清晰指令而非模糊指导）、包含示例（展示正确用法）、定义例外（规则不适用的情况）。详细写作指南见 references/best-practices.md。
- 格式化规则：使用格式「## [分类]: [简短标题]」加祈使句形式的清晰指令，并附示例与例外（如有）。
- 校验规则：检查是否清晰无歧义、是否定义了具体上下文、是否可执行、复杂时是否包含示例、是否记录例外、是否与现有规则冲突。
【快速模板】
- 编码风格规则：标题、做法与做法说明，并给出正确与应避免的示例。
- 项目配置规则：针对某用途使用某技术/模式，并列出相关配置或文件结构。
- 工作流规则：分步骤流程或检查清单。
【管理规则】 添加规则时，创建或追加到用户的规则文件，将相关规则归入清晰的标题下。更新规则时，除非明确要求替换，否则保留现有规则。组织规则可按优先级（security > performance > style）、分类（coding、git、testing 等）或作用域（项目级 vs 文件级）进行。
【输出位置】 规则必须保存在 .agent/rules/ 目录中，每个规则分类一个文件，例如 git-commit.md、coding-style.md、naming-conventions.md、security.md、testing.md。文件命名使用 kebab-case：{rule-name}.md，名称应体现规则分类或用途，例如 git-commit.md、coding-style.md、api-design.md。
【文件结构】 每个规则文件应包含带激活模式的 YAML frontmatter，其后是规则内容，例如 activation、description、globs 等字段，然后以「# [规则分类标题]」开头，附简要说明及若干带标题和示例的规则条目。
【激活模式】
- Manual：activation: manual，通过输入中的 @mention 激活（如 @git-commit）。
- Always On：activation: always_on，始终应用于所有对话。
- Model Decision：activation: model_decision，模型根据 description 字段决定。
- Glob：activation: glob，应用于匹配 globs 模式的文件。
【@Mentions（文件引用）】 可在规则中用 @filename 引用其他文件：相对路径（如 @../shared/common.md，相对于规则文件位置）、绝对路径（如 @/docs/api.md，先尝试真正的绝对路径，再尝试工作区相对路径）、工作区路径（如 @app/types.ts，相对于工作区/仓库根目录）。用例包括引用共享文档、包含类型定义、链接相关规则。
【创建规则步骤】 检查 .agent/rules/ 目录是否存在，不存在则创建；检查该分类的文件是否已存在；若存在则追加新规则到文件；若不存在则创建带有正确结构的新文件。