Building CLAUDE.md Configs

Create project configurations that shape how Claude Code behaves in any codebase or domain. A CLAUDE.md is the highest-leverage file in the Claude Code ecosystem — and MyClaude is the only place to buy, sell, and discover them.

Every Claude Code session begins by reading the CLAUDE.md at the root of your project. It tells Claude what stack you use, what rules to follow, what patterns to prefer, and what to avoid. A great CLAUDE.md is the difference between Claude Code that guesses and Claude Code that knows your project.

MyClaude was built using a CLAUDE.md — over 150 lines that encode architecture decisions, security rules, design system tokens, and documentation standards across 80+ sessions. That file is a product category on MyClaude. The platform selling CLAUDE.md configs is itself powered by one.

What is a CLAUDE.md product?

A CLAUDE.md product is a pre-built configuration file that buyers install into .claude/rules/. Claude Code loads it automatically — no invocation needed.

Who creates CLAUDE.md configs?

Anyone with opinions about how work should be done in a specific domain.

• Tech leads — encode team coding standards, architecture patterns, PR conventions
• Framework specialists — create configs for Next.js, Django, Rails, Flutter — teach Claude the right patterns
• Domain experts — configure Claude for healthcare compliance, financial regulation, academic writing
• Solo founders — package your project setup so others can start with your validated approach
• Consultants — sell your methodology as a Claude Code config that clients install and immediately benefit from

Create your first CLAUDE.md product

Let's build a CLAUDE.md for TypeScript projects with strict conventions.

Scaffold

$ myclaude init strict-typescript --type claude-md
$ cd strict-typescript

Write the CLAUDE.md

A great CLAUDE.md has clear sections. Here's a production-ready example:

# Strict TypeScript — Opinionated Project Config

## Stack
- TypeScript 5+ with strict mode enabled
- No `any` — ever. Use `unknown` with type guards.
- Prefer `const` assertions and discriminated unions.

## Code Rules
- Named exports only (except page components).
- Pure functions first. Side effects isolated and explicit.
- Error handling: Result types over try/catch for business logic.
- No default exports except Next.js pages/layouts.

## Testing
- Write tests BEFORE implementation (TDD).
- Unit tests for pure logic. Integration tests for API boundaries.
- No mocks for what you own. Mock only external services.

## Architecture
- Feature folders, not type folders (group by domain, not by file type).
- Server/client boundary is sacred — never import server code in client files.
- Database queries in repository files only — never in components or routes.

## Communication
- Be direct. No filler. Lead with the answer.
- When uncertain, say so with a confidence level.
- Suggest the simpler approach first, complex only if needed.

## What NOT to do
- Don't add dependencies without checking if one already exists.
- Don't refactor code outside the current task scope.
- Don't create abstractions for single-use patterns.
- Don't add comments explaining obvious code.

Wire vault.yaml

name: strict-typescript
version: 1.0.0
type: claude-md
title: "Strict TypeScript — Opinionated Project Config"
description: "Zero-tolerance TypeScript config: no any, TDD mandatory, feature folders, strict server/client boundaries. For teams that ship production code."
price: 4.99
tags:
  - typescript
  - strict
  - tdd
  - architecture

Test locally

Copy your CLAUDE.md to .claude/rules/ and start a Claude Code session:

$ mkdir -p .claude/rules
$ cp CLAUDE.md .claude/rules/strict-typescript.md

Ask Claude to write some code. Does it avoid any? Does it suggest tests first? Does it use named exports? If the config is working, Claude's behavior visibly shifts.

Publish

$ myclaude validate
$ myclaude publish

What makes a great CLAUDE.md product

The best CLAUDE.md configs are opinionated and specific. Generic configs add no value — Claude Code already knows general best practices. Your config's value is the specificity of decisions already made.

Domain-specific configs (non-dev)

CLAUDE.md isn't just for code. Claude Code is used across many domains:

Marketing config example:

# Marketing Strategy Config

## Voice
- First person plural ("we"), never third person about the brand.
- Active voice always. Passive voice is lazy writing.
- One idea per paragraph. If it needs two, it needs two paragraphs.

## Content Rules
- Every piece starts with the audience's pain point, not our solution.
- Stats require sources. No fabricated data points.
- CTAs are specific actions, not "learn more."

## Review Protocol
- Check: Does this pass the "so what?" test on every paragraph?
- Check: Would I share this if it weren't from our brand?
- Check: Is there a clearer way to say this?

Research config example:

# Academic Research Config

## Methodology
- State hypotheses before analysis, never after.
- Distinguish correlation from causation explicitly.
- All claims require evidence classification: empirical, inferential, or testimonial.

## Writing
- Abstract: 250 words max. Problem, method, finding, implication.
- Never use "clearly" or "obviously" — if it were obvious, you wouldn't need to say it.
- Cite primary sources. Secondary sources only when primary is inaccessible.

Common questions

How is a CLAUDE.md different from a Mind?

A CLAUDE.md configures behavior for a specific project context — coding standards, architecture rules, domain constraints. A Mind shapes how Claude thinks across any context. CLAUDE.md is local project rules. A Mind is a cognitive lens.

Can multiple CLAUDE.md products be installed at once?

Yes. Files in .claude/rules/ are all loaded. They compose — a TypeScript config and a TDD config can coexist. If rules conflict, the more specific file typically wins.

Should I include my tech stack in the config?

Yes. The more context Claude has about your stack, the better its suggestions. Stack information helps Claude avoid suggesting incompatible patterns.

Related pages

• What People Build — real examples including the MyClaude dogfood case study
• Building Minds — if your product is about thinking, not project rules
• vault.yaml Specification — manifest reference
• Publishing Guide — the basics of publishing