Writing Rules

Writing Rules

Overview

Rules are constraints that guide behavior. Good rules are specific, testable, and have clear thresholds for when they apply.

When to Create

Create a rule when:

• Same guidance given 3+ times manually
• Behavior needs to be consistent across sessions
• Mistake pattern keeps recurring
• Process discipline is required

Don't create for:

• Occasional edge cases (document as patterns instead)
• User preferences that change frequently
• One-time instructions

Structure Template

## Rule Name

**When:** [Specific trigger conditions]
**Confidence:** [high/medium/low - when to apply vs ask]
**Action:** [What to do]

### Examples
- Good: [Correct application]
- Bad: [Incorrect application]

### Exceptions
[When this rule doesn't apply]

Quality Checklist

• Clear trigger condition (not vague)
• Confidence threshold defined
• Both good AND bad examples
• Exceptions explicitly listed
• Testable (can verify rule was followed)
• No overlap with existing rules
• Assigned to correct category (process/domain/project)

Testing Requirements

1. Create test cases - 5+ scenarios where rule should apply
2. Create negative cases - 5+ scenarios where rule should NOT apply
3. Run through agent - Verify correct activation
4. Measure false positive rate - Target < 10%
5. Monitor for 3 sessions - Auto-rollback if quality drops

Examples

Good Rule:

## Import Path Verification

**When:** Adding or modifying import statements
**Confidence:** high
**Action:** Verify path exists by checking 3+ existing examples in codebase

### Examples
- Good: Check `src/components/Button.tsx` exists before importing
- Bad: Assume `@/components/Button` works without verification

### Exceptions
- Standard library imports (React, Node built-ins)
- Well-known packages from package.json

Bad Rule:

## Be Careful

**When:** Doing things
**Action:** Think before acting

(Too vague, not testable, no examples)

Common Mistakes