One Size Does Not Fit All Stacks
A generic rule template: covers TypeScript basics (naming, error handling, testing). But: a Next.js App Router project needs Server Component rules that a NestJS project does not. A Go microservice needs error-handling-as-values rules that a Python project does not. A React Native project needs platform-specific rules (iOS vs Android) that a web project does not. Per-stack templates: provide the framework-specific conventions that generic templates miss. The AI: generates idiomatic code for each stack because the template encodes that stack's patterns.
The template library: a collection of stack-specific templates maintained by the organization. Each template: 15-25 rules covering the stack's conventions. New projects: select the template matching their stack. The template: provides 80% of the rules ready-to-use. The team: customizes 20% (project-specific conventions). The library: maintained alongside the organization's technology strategy — when a new framework is adopted, a new template is created.
Who maintains the library: the platform team or DevEx team maintains the library structure. Each template: maintained by the organization's expert in that technology (the Go template by the Go tech lead, the Next.js template by the frontend lead). The expert: knows the stack's conventions, stays current with framework updates, and ensures the template reflects current best practices. AI rule: 'Technology experts maintain their stack's template. The platform team maintains the library infrastructure. This division: ensures both technical accuracy and organizational consistency.'
Step 1: Create a Template for Each Stack
The extraction process (from the framework ruleset tutorial): for each stack, answer three questions. (1) How are files organized? (directory structure, file naming, module boundaries). (2) How are code units structured? (component patterns, service patterns, handler patterns). (3) How does data flow? (state management, API calls, database access). The answers: become the stack-specific rules. Add: the stack's testing conventions, error handling pattern, and any framework-specific rules.
Example templates: Next.js App Router template (18 rules): Server Components default, Client Components with 'use client', data fetching in Server Components, Server Actions for mutations, next/image for images, Tailwind for styling, tRPC or route handlers for APIs. NestJS template (20 rules): modules with controllers + services, constructor DI, decorators for routing, validation pipes, Prisma for database, Swagger for API docs. Go microservice template (15 rules): error-as-values, explicit error checking, interfaces for abstraction, table-driven tests, standard project layout (cmd/, internal/, pkg/). Each: covers the stack's core conventions.
Template testing: after creating each template, test with 5 stack-specific prompts. Next.js: 'Create a new page that fetches data from the API.' NestJS: 'Create a new module with CRUD endpoints.' Go: 'Create a new HTTP handler with error handling.' The AI output: should be idiomatic for the stack. If not: refine the template rules until the output matches what a stack expert would write. AI rule: 'The test: does the AI generate code that a stack expert would approve? If yes: the template is ready. If no: the template needs refinement. Test before publishing.'
Creating a stack-specific template: 2-3 hours of the stack expert's time. Answering 3 questions (1 hour) + writing 15-20 rules (30 min) + testing with 5 prompts (30 min) + documenting (30 min). The return: every new project using that stack gets idiomatic AI output from the first prompt. For an organization that creates 10 new projects per year on the same stack: the template saves 10 × 2 hours (from-scratch rule writing per project) = 20 hours saved. The 3-hour investment: pays for itself on the second project.
Step 2: Organize the Template Library
Library structure: a central repository (github.com/org/ai-rule-templates) with one directory per stack. templates/nextjs-app-router/ (CLAUDE.md, README with usage instructions), templates/nestjs-backend/, templates/go-microservice/, templates/python-fastapi/, templates/react-native-expo/. Each template directory: the CLAUDE.md (the actual rules), a README (what the template covers, how to customize, and what framework version it targets), and a test-prompts.md (the 5 prompts used to validate the template).
Template selection guide: the library README includes a decision table. 'Building a web frontend? → nextjs-app-router. Building a REST API with TypeScript? → nestjs-backend. Building a high-performance microservice? → go-microservice. Building a data API with Python? → python-fastapi. Building a mobile app? → react-native-expo.' The guide: helps developers who are not sure which template to choose. AI rule: 'The selection guide: 30 seconds to read. The developer finds the right template without browsing every option.'
Versioning: each template is versioned independently (nextjs-app-router v2.1, nestjs-backend v1.5). The version: corresponds to the framework version the template targets (nextjs-app-router v2.x targets Next.js 16). When a framework releases a major version: create a new template version with updated rules. Keep old versions: for projects that have not upgraded. AI rule: 'Template versions match framework versions. Next.js 16 → template v2.x. Next.js 17 → template v3.x. Clear version mapping prevents template-framework mismatch.'
A developer creates a new project. Without a selection guide: they browse 6 templates, read each README, and guess which one fits. With a decision table: 'Building a web frontend? → nextjs-app-router. REST API with TypeScript? → nestjs-backend. High-performance service? → go-microservice.' The developer: reads one line, selects the template, and starts. The selection guide: eliminates browsing and guessing. It is the most-read part of the library README.
Step 3: Maintain and Grow the Library
Quarterly template review: each template expert reviews their template quarterly. Questions: does the template reflect the framework's current best practices? Are there new framework features that need rules (React Server Components, Go generics, Python type unions)? Have any rules become outdated (deprecated patterns, removed features)? The review: produces 1-3 rule updates per template per quarter. The templates: stay current with their frameworks.
Adding new stacks: when the organization adopts a new technology (Rust, Elixir, SvelteKit): create a new template. The process: the new technology's expert extracts conventions (3-question framework), writes 15-20 rules, tests with 5 prompts, and publishes to the library. Time: 2-3 hours for a new template. The template: immediately available for all projects using the new technology.
Community contributions: developers who use the templates and discover improvements: propose changes via PR. The template expert: reviews and merges. Over time: the templates improve from collective experience, not just the expert's individual knowledge. The templates: become a shared organizational asset, maintained by the community and curated by experts. AI rule: 'Templates grow from expert authoring + community contributions. The expert provides the foundation. The community refines it. Both: essential for long-term template quality.'
The Next.js App Router template v2.0: written for Next.js 16 (Server Components, Server Actions, route.ts). A developer uses it with Next.js 14 (Pages Router, getServerSideProps, api/*.ts routes). The AI: generates App Router code in a Pages Router project. Build errors. Confusion. The fix: the template clearly states 'For Next.js 16+. For Next.js 14: use template v1.x.' Template-framework version mismatch: the most common cause of template failures. Make the version requirement prominent.
Per-Stack Template Summary
Summary of creating AI rule templates per technology stack.
- Need: generic templates miss framework-specific conventions. Per-stack templates generate idiomatic code
- Extraction: 3 questions per stack (file structure, code patterns, data flow) + testing + error handling
- Examples: Next.js (18 rules), NestJS (20 rules), Go (15 rules), Python FastAPI, React Native
- Testing: 5 stack-specific prompts. Output must match what a stack expert would write
- Library: central repo with one directory per stack. README, CLAUDE.md, and test-prompts.md each
- Selection guide: decision table in the library README. 30-second lookup for the right template
- Versioning: template version matches framework version. Old versions available for non-upgraded projects
- Maintenance: quarterly review by stack expert. Community PRs for improvements. 1-3 updates per quarter