Sharing AI Development Rules Across Your Organization
Source: Dev.to
How centralized‑rules achieved 74.4 % token savings and consistent AI behavior with progressive disclosure and context‑aware rule loading.
The AI Rules Governance Problem
Every developer on a team tends to keep a personal AI rules file:
- One
CLAUDE.mdsays “always write tests.” - Another insists on “use TypeScript strict mode.”
- A third just copies whatever worked on the last project.
AI coding assistants (Claude Code, Cursor, GitHub Copilot, Gemini) then receive inconsistent instructions across projects and people. The consequences are:
- Tribal knowledge – best practices live only in individual heads and personal config files.
- Copy‑paste chaos – rules are shared via Slack and drift immediately.
- Onboarding friction – new developers spend days figuring out “how we do AI here.”
- Token waste – loading all rules even when only a subset is needed for the current context.
At scale (hundreds of developers), you can’t audit what instructions your AI tools receive, enforce security rules consistently, or measure compliance with AI development standards.
One Source of Truth: Centralized Rules
The core insight is simple: a single, version‑controlled repository of AI development rules, loaded only when relevant. This avoids overwhelming the model and wasting tokens.
Progressive Disclosure
- Detect context – scan the project for language markers (
package.json,pyproject.toml,go.mod). - Match keywords – analyze the prompt for task‑specific terms (e.g.,
test,security,refactor). - Display banner – show which rules apply to the current task.
- Apply rules – the AI follows only the relevant coding standards.
Four‑Dimensional Rule Structure (MECE)
| Dimension | Description |
|---|---|
| Base | Universal rules for all projects (git workflow, code quality, security principles). |
| Language | Language‑specific rules (Python, TypeScript, Go, Java, C#, Rust). |
| Framework | Framework‑specific rules (React, Django, FastAPI, Express, Spring Boot). |
| Cloud | Cloud‑provider rules (AWS, Vercel, Azure, GCP – extensible). |
Each rule lives in exactly one dimension, ensuring no duplication and complete coverage of common scenarios.
Automatic Detection & Loading
The install script inspects the repository and loads the appropriate rule set.
# Language detection
pyproject.toml → Load Python rules
package.json → Load JavaScript/TypeScript rules
go.mod → Load Go rules
# Framework detection
"fastapi" in dependencies → Load FastAPI rules
"react" in dependencies → Load React rules
# Cloud detection
vercel.json → Load Vercel rulesMeasured Impact
| Task Type | Files Loaded | Tokens Used | Tokens Saved | Savings |
|---|---|---|---|---|
| Code Review | 2 | 3,440 | 21,796 | 86.4 % |
| Write Tests | 2 | 11,163 | 14,073 | 55.8 % |
| FastAPI Endpoint | 3 | 8,608 | 16,628 | 65.9 % |
| Git Commit | 2 | 2,618 | 22,618 | 89.6 % |
| Average | 2.25 | 6,457 | 18,779 | 74.4 % |
Across a variety of tasks, loading only the relevant rule files reduced token consumption dramatically while delivering consistent AI behavior.
Installation
The installation is a single command and idempotent (safe to run multiple times).
# Global installation (all projects)
curl -fsSL https://raw.githubusercontent.com/paulduvall/centralized-rules/main/install-hooks.sh | bash# Project‑specific installation
curl -fsSL https://raw.githubusercontent.com/paulduvall/centralized-rules/main/install-hooks.sh | bash -s -- --localGet Started
The repository is open source under the MIT license:
github.com/PaulDuvall/centralized-rules
Star it, try it, and feel free to suggest any changes.