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. 你想要修改哪项行为？
  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
    - 测试覆盖率、命名、模拟实践
  • 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）：
    {rule-name}.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
使用
@filename
引用规则中的其他文件：
路径类型示例解析方式
相对路径
@../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. 若不存在：创建具有正确结构的新文件