Claude Code Rules

Personal collection of Claude Code behavioral rules — markdown files loaded automatically to enforce consistent tone, commit format, tool usage, and workflow guidelines across every project.

Rules

Rule	Trigger	Effect
casual-tone	All conversations	French replies, light tone; neutral in artifacts
concise-comments	Code editing	One-line comments max, no obvious or task-specific remarks
context7-mcp	Library/framework work	Fetch up-to-date docs via Context7 MCP before answering
conventional-commit	Commit messages	Enforce Conventional Commits v1.0.0 format and types
docker-compose-first	Projects with compose.yaml	Run commands via docker compose exec/run, not on host
doc-sync	All tasks	Check whether project documentation needs updating at end of task
sourced-docs	Markdown files	Link to authoritative sources for standards and specs
dx-report-format	Reviews, audits, reports	Structured format with severity icons and summary table
git-commit-guard	All git operations	Never commit without explicit confirmation; stage by name
no-em-dash	All text output	Replace em dash with colon, comma, or two sentences
objective-analysis	Code analysis, proposals	Facts and trade-offs only; no unsupported opinions
oss-contribution	OSS issue/PR work	Read issue fully, check CONTRIBUTING, no direct main commit
pr-description	Pull request creation/update	Write summary after diff is final; no ghost entries, no checklists
pragmatic-design	Code design decisions	No premature abstractions; match scope to actual needs
precise-tech-terms	Technical communication	Reserved words (push, merge, deploy) only for exact operations
reliable-information	Any factual claim	Verify before stating; flag uncertainty; no invented URLs

File format

Each rule is a plain markdown file. Add frontmatter only when the rule should apply to specific paths:

---
paths: ["src/**/*.ts"]
---

When doing X:

- Do this
- Not that

Omit frontmatter for global rules (most rules should be global).

Adding a rule

1. Create a kebab-case.md file in .claude/rules/, named after the concern (not the solution)
2. Open with the trigger context: "When writing commit messages:", "When the project contains a docker-compose.yml:"
3. Use bullet points or short sections — avoid prose walls
4. Include a concrete example (good vs bad) when the rule involves a format or style choice
5. Keep it focused: one concern per file

Notes

• Rules are global: they apply to every project where this config is loaded
• This repo contains no code, no tests, no CI — rules only
• Context7 MCP is installed globally (user scope) and used by context7-mcp