Rule Creator

What Are User Rules?

• Coding standards - Style, patterns, and conventions
• Language preferences - Response language, terminology
• Project configuration - Framework choices, file structure
• Workflow guidelines - Git, testing, documentation practices

Rule Creation Workflow

Step 1: Identify Rule Purpose

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?

Step 2: Choose Rule Category

• 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

Step 3: Write the Rule

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

Step 4: Format the Rule

## [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]

Step 5: Validate the Rule

• Clear and unambiguous?
• Specific context defined?
• Actionable instruction?
• Example included (if complex)?
• Exceptions documented?
• No conflicts with existing rules?

Quick Templates

Coding Style Rule

## Coding: [Title]

[What to do and how to do it]

✅ Correct:
[good example]

❌ Avoid:
[bad example]

Project Configuration Rule

## Project: [Title]

Use [technology/pattern] for [purpose].

Configuration:
[relevant settings or file structure]

Workflow Rule

## Workflow: [Title]

[Step-by-step process or checklist]

1. [First step]
2. [Second step]
3. [Third step]

Managing Rules

Adding Rules

Updating Rules

Organizing Rules

1. Priority (security > performance > style)
2. Category (coding, git, testing, etc.)
3. Scope (project-wide vs file-specific)

Output Location

.agent/rules/

.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

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

File Structure

---
activation: always_on  # or: manual, model_decision, glob
description: Brief description for model decision mode
globs: ["*.ts", "src/**/*.tsx"]  # only for glob activation
---

# [Rule Category Title]

Brief description of what this rule covers.

## Rule 1: [Title]

[Rule content with examples]

## Rule 2: [Title]

[Rule content with examples]

Activation Modes

activation: manual

@git-commit

activation: always_on

activation: model_decision

description

activation: glob

globs

Examples

---
activation: always_on
---

---
activation: manual
---

---
activation: model_decision
description: Apply when working with git commits or version control
---

---
activation: glob
globs: ["*.ts", "*.tsx", "src/**/*.js"]
---

@Mentions (File References)

@filename

@../shared/common.md

@/docs/api.md

@app/types.ts

Use Cases

For API conventions, see @/docs/api-guidelines.md

All API responses must follow the types in @app/types/api.types.ts

See also: @coding-style.md for naming conventions

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