Hierarchical Rule Files with Collocation: Context at the Point of Need

James Phoenix
James Phoenix

Summary

Global rules can’t capture domain-specific constraints, forcing developers to mentally context-switch and LLMs to hallucinate patterns. The hierarchical rule files pattern collocates documentation and configuration files (CLAUDE.md, ESLint configs, learning files) as close as possible to the code they govern. This creates semantic locality where context lives at the point of need, reducing cognitive load and improving LLM code generation accuracy.

Udemy Bestseller

Learn Prompt Engineering

My O'Reilly book adapted for hands-on learning. Build production-ready prompts with practical exercises.

4.5/5 rating
306,000+ learners
View Course

The Problem

Monolithic root-level rule files (CLAUDE.md, .eslintrc) don’t scale to large codebases with multiple domains. Global rules miss domain-specific constraints (API patterns vs database migrations vs UI components), forcing developers to remember context and LLMs to guess patterns. When context is far from code, it becomes stale, unused, and eventually wrong. Teams waste time searching for relevant documentation across scattered files.

The Solution

Apply the collocation principle: ‘Rules should live as close as possible to the code they govern.’ Create a hierarchy of rule files that mirror your codebase structure. Root files contain architecture and global principles. Domain directories contain domain-specific patterns. Module directories contain implementation details. This creates semantic locality where LLMs and developers always have relevant context without searching.

Related Concepts

References

Topics
Architectural PatternsClaude MdCollocationContext ManagementDocumentation StrategyDomain Specific RulesEslint ConfigHierarchical RulesInstitutional MemoryRule Proximity

More Insights

Cover Image for Thought Leaders

Thought Leaders

People to follow for compound engineering, context engineering, and AI agent development.

James Phoenix
James Phoenix
Cover Image for Systems Thinking & Observability

Systems Thinking & Observability

Software should be treated as a measurable dynamical system, not as a collection of features.

James Phoenix
James Phoenix