Templates: 80% Pre-Built, 20% Customizable
A rule template: a pre-built CLAUDE.md for a specific tech stack (Next.js App Router, NestJS backend, Go microservice, Python FastAPI) that a team can adopt in 15 minutes. The template provides: 80% of the rules ready-to-use (common conventions that most teams follow), 20% clearly marked as customizable (team-specific decisions like error handling pattern, naming variations, and project-specific rules). The team: copies the template, fills in the 20%, and starts using it immediately.
Why templates matter: writing AI rules from scratch takes 2-4 hours. Adopting a template takes 15-30 minutes. The template: eliminates the blank-page problem (where do I start?), provides proven structure (tested by other teams), and covers common conventions (security, testing, error handling) that most teams need. The customization: makes it their own without reinventing the common parts.
Template vs prescriptive rules: a template says 'Error handling: [choose: Result pattern / try-catch / custom error classes] for business logic. Describe your chosen approach here.' A prescriptive rule says 'Error handling: use the Result pattern.' The template: invites the team to make the decision. The prescriptive rule: makes the decision for them. Templates are more adoptable because teams feel ownership over the customized result.
Step 1: Template Structure Design
Header section: project context (tech stack, framework version, architecture). This section: fully customizable. The template provides placeholders: '## Project Context\n\nThis is a [Next.js 16 App Router / NestJS / FastAPI] application with [your database: PostgreSQL/MySQL/MongoDB] and [your ORM: Drizzle/Prisma/SQLAlchemy]. Architecture: [monolith / microservices / serverless].' The team fills in the brackets. The AI reads a concrete project description, not a generic template.
Convention sections: organized by category with a mix of fixed and customizable rules. Fixed rules (pre-filled, most teams keep as-is): security rules (parameterized queries, no secrets in code), naming conventions (camelCase for TypeScript, snake_case for Python), and testing basics (test framework specified, assertion style). Customizable rules (marked with [CUSTOMIZE]): error handling pattern, import grouping preferences, and project-specific rules. AI rule: 'Fixed rules: the common conventions that 90% of teams agree on. Customizable rules: the decisions that vary by team. Mark each clearly.'
Summary section: a bullet-point checklist of all rules in the template. Purpose: the team can scan the summary and quickly identify which rules to customize. Each bullet: references the section where the full rule is described. AI rule: 'The summary section: a table of contents for the rules. The team reads the summary in 2 minutes and knows exactly which sections need their input.'
Security: parameterized queries (every team agrees). Testing: tests co-located with source (most teams agree). Naming: camelCase for TypeScript (convention). These rules: rarely need customization. They are the 80% of the template that works out of the box. The team: adopts them without discussion. The value: they do not have to write these rules themselves. One hour saved. The 20% that needs customization: error handling pattern, specific libraries, project-specific conventions. That is where the team's input matters.
Step 2: Parameterization for Customization
Placeholder syntax: use a consistent format for customizable sections. Options: [CUSTOMIZE: description of what to fill in], <!-- TODO: your error handling pattern here -->, or { YOUR_ORM: Drizzle | Prisma | SQLAlchemy }. The syntax: clearly distinguishes customizable sections from pre-built rules. The team: searches for the placeholder pattern and fills in each one. AI rule: 'Use one consistent placeholder format throughout the template. The team finds all customization points with a single search.'
Decision trees for customizable rules: for rules where the choice depends on the project's characteristics, provide a decision tree. Example: 'Error handling: If your project uses TypeScript with strict types → Result<T, E> pattern (recommended). If your project wraps a legacy codebase → try-catch with custom error classes. If your framework requires specific error patterns (Express, NestJS) → framework-specific error handling.' The decision tree: guides the team to the right choice without prescribing.
Default values: for customizable rules, provide a recommended default. Example: '[CUSTOMIZE: test coverage minimum. Recommended: 80% for new code. Adjust based on your project's testing maturity.]' The default: saves the team a decision if they do not have a strong preference. The team can: accept the default (fast) or override with their preference (flexible). AI rule: 'Defaults speed up adoption. A team that accepts all defaults: has a working rule file in 5 minutes. A team that customizes every field: has a tailored file in 30 minutes. Both are valid paths.'
A template with no defaults: every field requires a decision. The team stalls: 'What should our error handling pattern be? Let us discuss in the next sprint planning.' Adoption: delayed 2 weeks. A template with smart defaults: the team accepts the defaults and starts using the rules in 5 minutes. Later: they customize the defaults that do not fit. The defaults: get the team started. The customization: makes the rules theirs. Both are needed. Defaults first, customization later.
Step 3: Creating Stack-Specific Templates
One template per stack: create separate templates for each tech stack your organization or community uses. Examples: Next.js App Router (TypeScript, Tailwind, tRPC or Server Actions), NestJS Backend (TypeScript, Prisma or TypeORM, Swagger), Go Microservice (standard library or Echo/Gin, GORM or sqlx), Python FastAPI (Pydantic, SQLAlchemy, pytest), and React Native Mobile (Expo or bare, React Navigation, AsyncStorage). Each template: covers the stack's specific conventions, patterns, and best practices.
Template testing: before publishing a template, test it with 5 representative prompts (from the rule testing tutorial). Verify: the AI generates idiomatic code for the stack. Common template issues: rules that reference the wrong framework version, rules that assume a specific library the template does not specify, and rules that conflict with each other. Testing: catches these before teams adopt the template. AI rule: 'Test every template with 5 prompts before publishing. An untested template with bugs: erodes trust in all your templates.'
Template versioning: version templates alongside the frameworks they target. Template: nextjs-app-router-v16.md (for Next.js 16). When Next.js 17 releases: create nextjs-app-router-v17.md with updated rules. Keep the old version: available for teams that have not upgraded. The version: in the filename AND in the template header. AI rule: 'Version templates by framework version. A template without a version: becomes ambiguous when the framework updates. Versioned templates: explicit about which framework version they target.'
You publish a Next.js template. A team adopts it. The AI generates: import getServerSideProps from 'next' (a Pages Router pattern). The template: referenced the wrong framework version. The team: loses trust in the template AND in AI rules generally. They go back to writing rules from scratch. One bug in one template: costs the trust of every team that tried it. Test with 5 prompts. Verify the AI generates idiomatic code for the target stack. Then publish.
Rule Template Summary
Summary of building reusable AI rule templates.
- Philosophy: 80% pre-built (common conventions), 20% customizable (team decisions)
- Structure: header (project context), convention sections (fixed + customizable), summary (checklist)
- Placeholders: consistent format ([CUSTOMIZE: description]). Searchable for all customization points
- Decision trees: guide teams to the right choice for customizable rules
- Defaults: recommended values for every customizable rule. Accept all = 5 min. Customize all = 30 min
- Stack-specific: one template per tech stack. Covers framework-specific conventions and patterns
- Testing: 5 prompts before publishing. Catch bugs before teams adopt
- Versioning: template version matches framework version. Old versions available for non-upgraded teams