Rules Configuration

ByteBuddy provides a powerful rule system that supports multiple configuration methods to define AI assistant behavior guidelines, ensuring generated code meets project standards and team specifications.

Rule Configuration Methods

ByteBuddy supports three main rule configuration approaches:

1. Configuration File Rules (config.yaml)

Define rules directly in the config.yaml file in your project root.

2. Rules Folder (.bytebuddy/rules/)

Place Markdown format rule files in the .bytebuddy/rules/ directory.

3. Codebase Rule Files (rules.md)

Place rules.md files anywhere in your codebase. Rules are automatically applied to that directory and its subdirectories.

Configuration File Rule Formats

String Rules

Simple rule definitions that directly describe requirements:

# config.yaml
name: My ByteBuddy Config
version: 0.0.1
schema: v1

rules:
  - "Always include type annotations"
  - "Follow existing code style"
  - "Add comments for complex logic"

Object Rules

Detailed rules with names and descriptions:

rules:
  - name: "comment-complex"
    rule: "Add comments for complex logic"
    description: "Add comments for complex functions over 5 lines"
  - name: "test-coverage"
    rule: "Ensure test coverage is not below 80%"
    globs: ["**/*.ts", "**/*.js"]

Markdown Rule File Format

Basic Markdown Rules

In the .bytebuddy/rules/ directory or codebase rules.md files:

---
name: "typescript-style"
globs: ["**/*.ts", "**/*.tsx"]
description: "TypeScript coding standards"
---

# TypeScript Coding Standards

All TypeScript files must follow these standards:

1. Use 2 spaces for indentation
2. All function parameters must include type annotations
3. Prefer interface over type
4. Avoid using any type

Advanced Markdown Rules

---
name: "component-rules"
globs: ["src/components/**/*.{js,jsx,ts,tsx}"]
regex: ["^[A-Z]"]
alwaysApply: true
invokable: false
---

# React Component Rules

React components must follow these specifications:

- Component names must start with uppercase letter
- Use function components instead of class components
- Each component file should include corresponding style file

Rule Field Descriptions

Basic Fields

• name: Rule name (recommended for identification and reference)
• rule: Rule content in Markdown format
• description: Rule description (optional)

Application Control Fields

• globs: File matching patterns, string or array format
• regex: Regular expression patterns for file content matching
• alwaysApply: Whether to always apply this rule (default: false)
• invokable: Whether to allow users to manually trigger this rule (default: false)
• sourceFile: Rule source file path (automatically set)

File Matching Patterns

Glob Pattern Examples

# Match specific file types
globs: ["**/*.ts", "**/*.tsx"]

# Match specific directories
globs: ["src/components/**/*"]

# Exclude specific files
globs: ["**/*.ts", "!**/*.test.ts"]

# Multiple pattern combinations
globs: ["src/**/*.{js,ts}", "!src/**/*.d.ts"]

Regex Pattern Examples

# Match file content
regex: ["console\\.log", "TODO|FIXME"]

# Complex regular expressions
regex: ["^\\s*function\\s+\\w+", "class\\s+\\w+.*extends"]

Rule Directory Structure

Global Rules Directory

.bytebuddy/
├── rules/
│   ├── global-style.md      # Global style rules
│   ├── security.md          # Security rules
│   └── performance.md       # Performance rules
└── prompts/
    ├── code-review.md       # Code review prompts
    └── debugging.md         # Debugging prompts

Codebase Rules Example

src/
├── components/
│   ├── Button.tsx
│   └── rules.md            # Component-specific rules
├── utils/
│   ├── helper.ts
│   └── rules.md            # Utility function rules
└── rules.md                # src directory rules

Rule Examples

1. Configuration File Rules

# config.yaml
name: My ByteBuddy Config
version: 0.0.1
schema: v1

models:
  - name: "gpt-4"
    provider: "openai"
    model: "gpt-4"
    apiKey: "${OPENAI_API_KEY}"
    roles: ["chat"]

rules:
  - "Always include type annotations"
  - "Follow existing code style"
  - name: "typescript-strict"
    rule: "TypeScript code must be in strict mode"
    globs: ["**/*.ts", "**/*.tsx"]
    alwaysApply: true

2. Markdown Rule Files

---
name: "react-components"
globs: ["src/components/**/*.{js,jsx,ts,tsx}"]
alwaysApply: true
invokable: false
---

# React Component Development Standards

All React components must follow these specifications:

## Component Structure

- Use function components instead of class components
- Component names must start with uppercase letter
- Use default export

## Type Definitions

- All props must define TypeScript interfaces
- Use React.FC or explicit return type
- Avoid using any type

## Style Handling

- Prefer CSS Modules or styled-components
- Avoid inline styles
- Consider responsive design

3. Specific Directory Rules

---
name: "test-coverage"
globs: ["**/*.test.{js,ts}", "**/*.spec.{js,ts}"]
regex: ["test|it\\("]
---

# Test File Specifications

Test files must include:

1. **Descriptive test names**
2. **Arrange-Act-Assert structure**
3. **Edge case testing**
4. **Error handling testing**

Each test function must have clear assertions, ensuring test coverage is not below 80%.

Advanced Features

Invokable Rules

Rules with invokable: true can be manually triggered in chat:

---
name: "code-review"
invokable: true
description: "Comprehensive code review"
---

# Code Review Rules

Please conduct a comprehensive review of the provided code, checking:

1. **Code Quality**: Readability, maintainability
2. **Security**: Potential security vulnerabilities
3. **Performance**: Performance optimization suggestions
4. **Testing**: Test coverage
5. **Documentation**: Documentation completeness

Provide specific improvement suggestions and best practices.

Rule Priority

1. Colocated Rules: rules.md in the same directory as files
2. Global Markdown Rules: Rules in .bytebuddy/rules/ directory
3. Configuration File Rules: Rules defined in config.yaml

Conditional Matching Rules

---
name: "production-safety"
globs: ["src/**/*.{js,ts}"]
regex: ["console\\.(log|warn|error)", "debugger"]
---

# Production Environment Safety Check

The following should not appear in production code:

- ❌ console.log(), console.warn(), console.error()
- ❌ debugger statements
- ❌ Hardcoded API keys
- ❌ Commented-out debug code

Please use appropriate logging systems and environment variable management.

Rule Management Best Practices

1. Rule Organization

• Organize rule files by functional modules
• Use clear naming conventions
• Regularly review and update rules

2. Team Collaboration

---
name: "team-standards"
globs: ["**/*.{js,ts,jsx,tsx}"]
description: "Team coding standards"
---

# Team Coding Standards

This rule defines all team coding standards. Please ensure all new code complies with these specifications.

## Naming Conventions

- Components: PascalCase
- Variables/Functions: camelCase
- Constants: UPPER_SNAKE_CASE
- File names: kebab-case

## Code Organization

- Organize files by functional modules
- Keep file sizes reasonable (< 300 lines)
- Use index.ts to export public interfaces

3. Rule Testing

• Use example code to verify rule effectiveness
• Regularly review actual rule application
• Adjust rule content based on team feedback

Troubleshooting

Common Issues

Rules Not Taking Effect

1. Check file paths and glob patterns
2. Verify YAML frontmatter format
3. Confirm rule file locations are correct

Rule Conflicts

1. Rules are applied by priority, later rules may override earlier ones
2. Use alwaysApply: true to ensure rules always take effect
3. Check globs and regex matching logic

Performance Issues

1. Avoid overly complex regex patterns
2. Use globs reasonably to limit rule application scope
3. Regularly clean up unnecessary rule files