The Rules System

What Are Rules?

My AI deleted a production config file on day 8. It edited code without reading it first on day 12. It started a dev server during an implementation on day 15, draining my laptop battery to zero. Every one of those failures became a rule — and none of them happened again.

Rules are markdown files in ~/.claude/rules/ that automatically load at the start of every Claude Code session. While CLAUDE.md defines identity, rules define behavior. They are the guardrails that prevent your AI from going off-script. For a business, rules ensure consistent quality across every interaction.

Rule File Naming Convention

Rules are numbered with a two-digit prefix. This controls the loading order. Lower numbers load first and have higher priority.

00-core-identity.md      # Who the AI is (highest priority)
01-routing.md            # Which agent handles which task
02-enforcement.md        # Tool access restrictions
03-agent-orchestration.md # How to spawn and manage agents
04-context-injection.md  # What context to give agents
05-continuity.md         # Session handoff rules
06-read-before-write.md  # Always check before creating

Essential Rules for Your business

Rule 1: Routing Table

The routing table tells your AI which agent handles which type of request. This prevents the AI from trying to do everything itself.

# Routing Table

Match task DOMAIN before task OPERATION. Specialist beats generic.

| Trigger | Agent |
|---------|-------|
| Research, find out, analyze | researcher |
| Create file, edit file, write | file-executor |
| Bug, error, fix, debug | code-debugger |
| Plan, break down, strategy | task-planner |
| Morning, status, priorities | chief-of-staff |
| Evening, wrap up, summary | chief-of-staff |

**Rule:** If unsure which agent, ask — do not guess.

Rule 2: Read Before Write

This rule prevents your AI from creating duplicate files or overwriting existing work. It is one of the highest-value rules in any system.

# Read Before Write

Before responding to ANY request:

1. Check existing files for relevant content
2. Read the target file before editing
3. Use existing patterns, not raw generation

## NEVER
- Create a file without checking if it exists
- Edit code without reading it first
- Generate content without checking the knowledge base

Rule 3: Observe Before Editing

# Observe Before Editing

Before editing code to fix a bug, confirm what the system actually produced.

## DO
1. Check if expected output exists
2. Read logs and error messages
3. Run the failing command to see the actual error
4. Only then edit code

## DON'T
- Assume what the error is without checking
- Edit code based on what you think should happen
- Make multiple changes at once

Rule 4: Agent Constraints

Create a dedicated rule file that defines what each agent must NEVER do. This is your institutional memory of failures — every time an agent makes a mistake, add a constraint. These constraints tie directly back to the agents you defined in Chapter 3: Building Your First Agents.

# Agent Constraints (DON'Ts)

## {agent_name}
1. DON'T [most common failure mode]
2. DON'T [quality issue to prevent]
3. DON'T [safety boundary]
4. DON'T [scope limitation]
5. DON'T [process skip to prevent]

## Enforcement
These constraints should be:
1. Loaded by agents at startup (via protocol read)
2. Checked by verification hooks
3. Flagged in post-work audits

Rule 5: Server Management

Running dev servers during implementation wastes battery, RAM, and can cause port conflicts. Define a rule: servers OFF during build, ON only for demo.

# Server Management Protocol

## Before Implementation
Kill any running dev servers before starting work.

## During Implementation
Do NOT start dev servers. Use build commands to verify code compiles.
Fix errors in build output, not in the browser.

## After Implementation (Demo Time)
Only start servers when the human asks to see the result.

Rule 6: Data Migration Safety

When data moves from one location to another, never change the protocol until the data is migrated AND verified. This rule prevents data loss during system evolution.

1. 1Create a migration script BEFORE touching any protocol.
2. 2Execute migration and verify completeness (count source vs target).
3. 3Update protocols with dual-source fallback (read new first, fall back to old).
4. 4Monitor for 3+ successful sessions with the new source.
5. 5Only then remove the fallback and archive the old source.

Rules are only as strong as their enforcement. Writing 'read before write' as a rule is step one — Chapter 6: The Enforcement System shows you how to build hooks that mechanically block violations, turning wishes into guarantees.