Back to Details

rule-creator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Rule Creator

规则创建器

Create effective user rules that customize AI behavior for projects and personal preferences.
创建可自定义AI行为的有效用户规则，适配项目需求和个人偏好。

What Are User Rules?

什么是用户规则？

User rules are custom instructions that modify how the AI assistant behaves. They can define:
  • Coding standards - Style, patterns, and conventions
  • Language preferences - Response language, terminology
  • Project configuration - Framework choices, file structure
  • Workflow guidelines - Git, testing, documentation practices
用户规则是用于修改AI助手行为的自定义指令，可定义以下内容：
  • 编码标准 - 风格、模式和约定
  • 语言偏好 - 响应语言、术语使用
  • 项目配置 - 框架选择、文件结构
  • 工作流指南 - Git、测试、文档实践

Rule Creation Workflow

规则创建工作流

Step 1: Identify Rule Purpose

步骤1：明确规则用途

Ask the user:
  1. What behavior do you want to modify?
  2. Is this a project rule (shared) or personal preference?
  3. Are there exceptions to this rule?
询问用户以下问题：
  1. 你想要修改AI的哪项行为？
  2. 这是项目规则（共享使用）还是个人偏好规则？
  3. 该规则是否存在例外情况？

Step 2: Choose Rule Category

步骤2：选择规则分类

Common categories:
  • coding-style
    - Code formatting, syntax preferences
  • language
    - Response language, communication style
  • project
    - Framework-specific, architecture decisions
  • git
    - Commit messages, branching, PR guidelines
  • naming
    - Variable, function, file naming conventions
  • security
    - Authentication, secrets, input validation
  • testing
    - Test coverage, naming, mocking practices
  • documentation
    - Comments, README, JSDoc requirements
For templates and examples, see references/rule-patterns.md.
常见分类如下：
  • coding-style
    - 代码格式化、语法偏好
  • language
    - 响应语言、沟通风格
  • project
    - 框架专属规则、架构决策
  • git
    - 提交信息、分支管理、PR指南
  • naming
    - 变量、函数、文件命名约定
  • security
    - 身份认证、密钥管理、输入校验
  • testing
    - 测试覆盖率、命名规范、Mock实践
  • documentation
    - 注释、README、JSDoc要求
如需模板和示例，请查看 references/rule-patterns.md。

Step 3: Write the Rule

步骤3：编写规则

Follow these principles:
  1. Be specific - Use concrete examples
  2. Be actionable - Clear instructions, not vague guidance
  3. Include examples - Show correct usage
  4. Define exceptions - When the rule doesn't apply
For detailed writing guidelines, see references/best-practices.md.
遵循以下原则：
  1. 具体明确 - 使用具象示例
  2. 可执行 - 指令清晰，避免模糊引导
  3. 包含示例 - 展示正确用法
  4. 定义例外 - 说明规则不适用的场景
如需详细编写指南，请查看 references/best-practices.md。

Step 4: Format the Rule

步骤4：格式化规则

Use this format:
undefined
使用以下格式：
undefined

[Category]: [Short Title]

[分类]: [简短标题]

[Clear instruction in imperative form]
Example: [Code or text example showing correct usage]
Exception: [When this rule doesn't apply, if any]
undefined
[祈使句形式的清晰指令]
示例： [展示正确用法的代码或文本示例]
例外：[规则不适用的场景（如有）]
undefined

Step 5: Validate the Rule

步骤5：校验规则

Check against this list:
  • Clear and unambiguous?
  • Specific context defined?
  • Actionable instruction?
  • Example included (if complex)?
  • Exceptions documented?
  • No conflicts with existing rules?
对照以下列表检查：
  • 清晰无歧义？
  • 定义了具体适用上下文？
  • 指令可执行？
  • 包含示例（规则复杂时）？
  • 例外情况已记录？
  • 与现有规则无冲突？

Quick Templates

快速模板

Coding Style Rule

编码风格规则

undefined
undefined

Coding: [Title]

编码: [标题]

[What to do and how to do it]
✅ Correct: [good example]
❌ Avoid: [bad example]
undefined
[规则要求及实现方式]
✅ 正确示例： [符合要求的示例]
❌ 避免使用： [不符合要求的示例]
undefined

Project Configuration Rule

项目配置规则

undefined
undefined

Project: [Title]

项目: [标题]

Use [technology/pattern] for [purpose].
Configuration: [relevant settings or file structure]
undefined
为[目标场景]使用[技术/模式]。
配置项： [相关配置或文件结构]
undefined

Workflow Rule

工作流规则

undefined
undefined

Workflow: [Title]

工作流: [标题]

[Step-by-step process or checklist]
  1. [First step]
  2. [Second step]
  3. [Third step]
undefined
[分步流程或检查清单]
  1. [第一步]
  2. [第二步]
  3. [第三步]
undefined

Managing Rules

规则管理

Adding Rules

添加规则

Create or append to the user's rules file. Group related rules under clear headers.
创建规则或追加到用户的规则文件中，将相关规则归类到清晰的标题下。

Updating Rules

更新规则

When updating, preserve existing rules unless explicitly asked to replace them.
更新规则时，除非用户明确要求替换，否则保留现有规则。

Organizing Rules

整理规则

Suggest organizing rules by:
  1. Priority (security > performance > style)
  2. Category (coding, git, testing, etc.)
  3. Scope (project-wide vs file-specific)
建议按以下维度整理规则：
  1. 优先级（安全 > 性能 > 风格）
  2. 分类（编码、git、测试等）
  3. 适用范围（项目全局 vs 文件专属）

Output Location

输出位置

Rules must be saved in the 
.agent/rules/
directory with one file per rule category:
.agent/rules/
├── git-commit.md          # Git commit format rules
├── coding-style.md        # Coding style rules
├── naming-conventions.md  # Naming rules
├── security.md            # Security rules
└── testing.md             # Testing rules
规则必须保存在 
.agent/rules/
目录下，每个规则分类对应一个文件：
.agent/rules/
├── git-commit.md          # Git提交格式规则
├── coding-style.md        # 编码风格规则
├── naming-conventions.md  # 命名规则
├── security.md            # 安全规则
└── testing.md             # 测试规则

File Naming

文件命名

  • Use kebab-case: 
    {rule-name}.md
  • Name should reflect the rule category or purpose
  • Examples: 
    git-commit.md
    , 
    coding-style.md
    , 
    api-design.md
  • 使用 kebab-case 格式：
    {规则名称}.md
  • 名称应体现规则分类或用途
  • 示例：
    git-commit.md
    、
    coding-style.md
    、
    api-design.md

File Structure

文件结构

Each rule file should include YAML frontmatter with activation mode, followed by the rule content:
markdown
---
activation: always_on  # or: manual, model_decision, glob
description: Brief description for model decision mode
globs: ["*.ts", "src/**/*.tsx"]  # only for glob activation
---
每个规则文件需包含带有激活模式的YAML前置元数据，后面跟随规则内容：
markdown
---
activation: always_on  # 可选值: manual, model_decision, glob
description: 模型决策模式下的简短描述
globs: ["*.ts", "src/**/*.tsx"]  # 仅glob激活模式下需要
---

[Rule Category Title]

[规则分类标题]

Brief description of what this rule covers.
规则覆盖范围的简短描述。

Rule 1: [Title]

规则1: [标题]

[Rule content with examples]
[带示例的规则内容]

Rule 2: [Title]

规则2: [标题]

[Rule content with examples]
undefined
[带示例的规则内容]
undefined

Activation Modes

激活模式

Rules can be activated in different ways:
ModeFrontmatterDescription
Manual
activation: manual
Activated via @mention in input (e.g., 
@git-commit
)
Always On
activation: always_on
Always applied to all conversations
Model Decision
activation: model_decision
Model decides based on 
description
field
Glob
activation: glob
Applied to files matching 
globs
patterns
规则支持多种激活方式：
模式前置元配置描述
手动
activation: manual
通过输入中的@提及激活（例如 
@git-commit
）
始终生效
activation: always_on
对所有会话永久生效
模型决策
activation: model_decision
模型根据
description
字段判断是否激活
路径匹配
activation: glob
对匹配
globs
规则的文件生效

Examples

示例

Always On (recommended for general rules):
yaml
---
activation: always_on
---
Manual (for specific workflows):
yaml
---
activation: manual
---
Model Decision (context-dependent):
yaml
---
activation: model_decision
description: Apply when working with git commits or version control
---
Glob (file-type specific):
yaml
---
activation: glob
globs: ["*.ts", "*.tsx", "src/**/*.js"]
---
始终生效（通用规则推荐使用）：
yaml
---
activation: always_on
---
手动激活（特定工作流使用）：
yaml
---
activation: manual
---
模型决策（上下文依赖规则使用）：
yaml
---
activation: model_decision
description: 处理git提交或版本控制相关内容时激活
---
路径匹配（特定文件类型规则使用）：
yaml
---
activation: glob
globs: ["*.ts", "*.tsx", "src/**/*.js"]
---

@Mentions (File References)

@提及（文件引用）

Reference other files in rules using 
@filename
:
Path TypeExampleResolution
Relative
@../shared/common.md
Relative to rule file location
Absolute
@/docs/api.md
First tries true absolute path, then workspace-relative
Workspace
@app/types.ts
Relative to workspace/repository root
使用
@文件名
在规则中引用其他文件：
路径类型示例解析逻辑
相对路径
@../shared/common.md
相对于规则文件所在位置解析
绝对路径
@/docs/api.md
优先尝试真实绝对路径，再尝试工作区相对路径
工作区路径
@app/types.ts
相对于工作区/仓库根目录解析

Use Cases

使用场景

Referencing shared documentation:
markdown
For API conventions, see @/docs/api-guidelines.md
Including type definitions:
markdown
All API responses must follow the types in @app/types/api.types.ts
Linking related rules:
markdown
See also: @coding-style.md for naming conventions
引用共享文档：
markdown
API约定请查看 @/docs/api-guidelines.md
引入类型定义：
markdown
所有API响应必须遵循 @app/types/api.types.ts 中定义的类型
关联相关规则：
markdown
另见：@coding-style.md 查看命名约定

Creating Rules

创建规则

  1. Check if 
    .agent/rules/
    directory exists, create if not
  2. Check if a file for this category already exists
  3. If exists: append new rules to the file
  4. If not: create new file with proper structure
  1. 检查 
    .agent/rules/
    目录是否存在，不存在则创建
  2. 检查该分类对应的规则文件是否已存在
  3. 已存在：将新规则追加到文件末尾
  4. 不存在：按照规范结构创建新文件