[FEATURE] Tool based rule sets.

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code loads all rules from CLAUDE.md or /rules regardless of whether it is reading files during research or writing/editing files. This means every rule — including code style enforcement, testing requirements, and file conventions — is loaded into context even during pure read operations like tracing a function, understanding an architecture, or searching for a bug.

Proposed Solution

• Read rules — loaded only when Claude is reading/researching the codebase
• Write rules — loaded only when Claude is creating or modifying files
• Read+write rules — always loaded (current default behavior)

Alternative Solutions

_No response_

Priority

Low - Nice to have

Feature Category

File operations

Use Case Example

Project: Full-Stack TypeScript Monorepo

my-app/
├── CLAUDE.md
├── packages/
│   ├── api/
│   ├── web/
│   └── shared/

Current CLAUDE.md (flat, no scoping)

# Project Rules

## Architecture
- This is a NestJS + React monorepo using Turborepo
- API lives in packages/api, frontend in packages/web
- Shared types in packages/shared

## Code Style
- Use strict TypeScript — no `any`, no type assertions without comment
- All API endpoints must have a corresponding Zod validation schema
- React components must be functional, no class components
- CSS is Tailwind only — no inline styles, no CSS modules
- All async functions must handle errors explicitly — no unhandled promise rejections
- Services must be injected via NestJS DI, never instantiated directly
- Every new file needs a barrel export in its directory's index.ts
- Database queries must go through the repository layer — no raw Prisma calls in services
- Branch naming: feat/, fix/, chore/ prefixes required

## Testing
- Unit tests required for all service methods
- Integration tests required for all API controllers
- Test files must sit adjacent to source files, named *.spec.ts

The Problem In Practice

When a developer asks:

"How does the authentication flow work? Trace it from the HTTP request through to the JWT being issued."

Claude is doing pure research — reading auth.controller.ts, auth.service.ts, jwt.strategy.ts, users.repository.ts. It is not writing anything. But the entire ruleset is loaded into context anyway, including rules that are completely irrelevant to reading code:

• "Every new file needs a barrel export" — no files are being created
• "Branch naming: feat/, fix/, chore/ prefixes required" — not committing anything
• "Unit tests required for all service methods" — not writing any methods
• "CSS is Tailwind only" — not touching CSS

This wastes context window tokens on noise. In long research sessions across a large codebase, that overhead compounds. It can also cause Claude to interject write-related caveats ("note that if you modify this, you will need to update the barrel export") when the developer just wants to understand what the code does.

---

What the Feature Would Enable

With read/write rule scoping, the CLAUDE.md could be structured like this:

# Project Rules

## [mode: read+write] Architecture
- This is a NestJS + React monorepo using Turborepo
- API lives in packages/api, frontend in packages/web
- Shared types in packages/shared

## [mode: write] Code Style
- Use strict TypeScript — no `any`, no type assertions without comment
- All API endpoints must have a corresponding Zod validation schema
- React components must be functional, no class components
- CSS is Tailwind only — no inline styles, no CSS modules
- All async functions must handle errors explicitly
- Services must be injected via NestJS DI, never instantiated directly
- Every new file needs a barrel export in its directory's index.ts
- Database queries must go through the repository layer
- Branch naming: feat/, fix/, chore/ prefixes required

## [mode: write] Testing
- Unit tests required for all service methods
- Integration tests required for all API controllers
- Test files must sit adjacent to source files, named *.spec.ts

During the auth flow trace, Claude loads only the Architecture block — enough to understand the system shape without carrying irrelevant rules. When the developer switches to "now add a refresh token endpoint", the full Code Style and Testing rules activate because writes are happening.

---

Why This Matters Beyond Tidiness

Token budget: In a large project, CLAUDE.md files can run to several hundred lines. During a research session that touches 15–20 files, loading write rules on every file read adds meaningful context pressure, crowding out actual code.

Behavioral interference: Rules written for code generation can cause Claude to reframe read-only explanations around what should be done rather than what is done — which is the opposite of what is useful during research.

Multi-step tasks: When Claude Code naturally breaks a task into a research phase followed by a write phase, a flat ruleset gives no mechanical way to say "these constraints only apply once you start generating output." The developer has to either repeat that instruction in every prompt, or accept the noise.

---

Note: The [mode: read] / [mode: write] / [mode: read+write] syntax above is illustrative — the actual syntax would be up to the team to decide.

Additional Context

_No response_