Step 1: Preparing Rules for Public Sharing
Redaction checklist: remove references to internal services (replace 'use the @internal/logger package' with 'use a structured JSON logger'), remove domain-specific business rules (rules about your specific product's logic), remove internal URLs and endpoints (replace with placeholders), and remove any references to proprietary tools or infrastructure. Keep: language conventions, framework patterns, testing standards, error handling patterns, and security rules. AI rule: 'Most rules survive redaction unchanged. The 5% that reference internal specifics: replace with generic equivalents. The generic version is often better — it applies to more projects.'
Generalization: some rules reference your specific tech stack. Before sharing: generalize where appropriate. Your rule: 'Use Drizzle ORM for all database queries.' Generalized: 'Use the project's ORM for all database queries. Never write raw SQL unless the ORM cannot express the query.' The generalized version: works for any ORM (Prisma, Drizzle, SQLAlchemy, GORM). Keep stack-specific rules when the template is stack-specific (a Next.js template: should specify Next.js patterns).
Structure for reuse: organize the public rules into sections with clear headings. Each section: self-contained (teams can adopt individual sections without the full file). Include comments explaining the 'why' behind each rule — public rules need more context because the reader does not have your team's background knowledge. AI rule: 'Public rules need more 'why' than internal rules. Your team knows why you use the Result pattern. A community reader: needs the explanation.'
Your internal rule: 'Use @internal/logger for all logging.' Generalized for public sharing: 'Use a structured JSON logger. Log fields: timestamp, level, message, requestId, service.' The generic version: works for any logging library (pino, winston, bunyan). It is actually a better rule — it describes the pattern instead of prescribing the tool. Many teams find that generalizing for public sharing improves their internal rules too.
Step 2: Publishing and Maintaining
Repository structure: create a repository (e.g., github.com/org/ai-rules-templates). Include: templates/ directory with stack-specific templates (templates/nextjs-app-router.md, templates/nestjs-backend.md, templates/go-microservice.md), a README with: overview, how to use, how to customize, and how to contribute, a LICENSE (MIT or Apache 2.0 — permissive licenses encourage adoption), and a CONTRIBUTING.md explaining how to submit template improvements.
Discoverability: add topics to the GitHub repo (ai-rules, claude-md, cursorrules, coding-standards). Write a clear README title that includes keywords people search for. Share on: dev.to, Twitter/X, Hacker News, and relevant Discord/Slack communities. A well-written README: makes the difference between a repo that is discovered and one that is not. AI rule: 'The README is the sales page. First sentence: what this repo provides. Second sentence: how to use it. Everything else: details for those who are interested.'
Maintenance: community-shared rules need maintenance just like internal rules. Accept pull requests for: new stack templates, improvements to existing templates, and bug fixes (rules that generate incorrect code). Review contributions with the same rigor as internal rule changes. Tag releases so users can pin to a specific version. AI rule: 'A shared template that is not maintained: becomes stale and harms the community. If you share: commit to reviewing PRs and tagging releases at least quarterly.'
CONTRIBUTING.md: describes conventions in prose. Contributors read it (maybe) and try to follow it (partially). CLAUDE.md: encodes conventions in a format the contributor's AI tool reads automatically. The contributor does not need to remember the conventions — the AI applies them. For open source maintainers: adding CLAUDE.md to your repo is the single most effective contribution quality improvement. Zero contributor effort. Maximum convention compliance.
Step 3: Alternative Sharing Approaches
In your open source project: the simplest sharing approach. Include CLAUDE.md (and .cursorrules, .github/copilot-instructions.md) in your open source repository. Contributors' AI tools: automatically use your rules when contributing to the project. No separate repository needed. The rules: maintained as part of the project itself. AI rule: 'For open source maintainers: adding a CLAUDE.md to your repo is the highest-impact contribution guide you can provide. Contributors' AI generates code following your conventions from the first PR.'
Blog post with embedded rules: write a blog post explaining your AI rules philosophy, then include the rule file as a downloadable template. The blog post: provides context that a bare template cannot. Why you chose these conventions. What problems they solve. How they evolved over time. The template: is a starting point that readers customize. AI rule: 'A blog post + template: more effective than a template alone. The blog explains the thinking. The template provides the artifact. Together: the reader understands AND implements.'
Community rule registries: as AI rules become more common, community registries may emerge (similar to eslint-config-* packages). Early sharing: positions your rules in the community and establishes your team as a thought leader in AI-assisted development practices. AI rule: 'Sharing rules publicly: a form of technical marketing. It demonstrates your team's engineering depth. Candidates, customers, and partners: notice.'
You share a Next.js rule template. 500 developers adopt it. 6 months later: Next.js releases a major version with new patterns. Your template: still references the old patterns. 500 developers' AI tools: generating outdated code because they trust your template. If you share: commit to maintaining. Tag releases. Accept PRs. Update for major framework releases. A maintained template: helps the community. An abandoned template: misleads it.