I work on .NET and Angular projects with Claude Code. For every new project I kept writing the same instructions again: which stack to use, how to handle Git, what Claude must never do on its own, how to ask questions. So I put all of it in one place: claude-config, a public template of rules plus a small Claude Code plugin.

Repository: https://github.com/AngeloDotNet/claude-config

What is in the repository

Claude Code loads the files under .claude/rules/ by itself, so the rules are copied into each project and nothing is installed globally. The modules are:

Module When it loads What it covers
core.md always stack, tests, observability, Docker scope, interaction rules
git.md always branches and commits
security.md always authentication, secrets, input, CSP, supply chain, OWASP Top 10 2025 and ASVS 5.0
frontend.md when editing *.ts, *.html, *.css, *.scss Angular
backend.md, backend-architecture.md, backend-app.md when editing C# or project files .NET
docker.md Dockerfiles and Compose files containers

Optional modules (email, infrastructure, feature workflow) live in .claude/rules-optional/ and are switched on only when a project needs them.

The rules are written in Italian, because that is the language I work in, while code, identifiers and commit messages stay in English. You can change that to suit your own team.

Rules that do most of the work

A few of the rules in core.md shape almost every session:

  • One question at a time. When Claude is unsure, it stops, asks a single question and waits for the answer before going on. It never bundles several questions together.
  • Claude makes only local commits by default. It does not push, open pull requests, create tags or publish releases unless the project explicitly approves those operations in its CLAUDE.md, one operation at a time. Without that approval, they stay with the developer.
  • Plan before substantial work. For features, non-trivial fixes and refactorings, Claude writes a plan file first, then executes it one step at a time, ticking each step only after build and tests.
  • No trusting memory for fast-moving APIs. For libraries that change often, Claude checks the documentation of the installed version.
  • Verify before declaring done. Build and tests run first, and any errors are reported as they are.

The plugin: kit-config

Written rules are only a suggestion, so the plugin turns the most important ones into hooks:

  • a reminder of the one-question rule on every prompt;
  • a check that allows only one question per AskUserQuestion call;
  • a guard on shell commands that always blocks git init, forced pushes (git push --force and its variants), deleting remote branches, git reset --hard, git clean -f, --no-verify and forced recursive deletes. Pushes, tag creation, gh pr create/merge and gh release are blocked until the project approves them in its CLAUDE.md. Read-only commands such as git status, git log or gh pr view remain allowed;
  • a session-start hook that gives Claude the plan and the rules to re-read;
  • a watcher that notices when the rules in a project have changed during a session or differ from the template.

Install it once per machine:

claude plugin marketplace add AngeloDotNet/claude-config claude plugin install kit-config@claude-config

The current version is 1.8.0.

Using it in a project

The documentation covers three situations:

  1. New project: copy the rules and the CLAUDE.md template, fill in the project fields, then ask Claude to start the project.
  2. Existing project without rules: use the "Git only" mode, which keeps only the core and git modules and leaves the existing code alone.
  3. Existing project with rules: bring the rules up to the latest template version.

The CLAUDE.md in each project holds only what is specific to that project. Choices such as architecture, ORM, database, multi-tenancy or the ASVS level are never assumed: the template asks for them and they are recorded once. The copia-regole.bat script copies the rules and root files into a project folder and can update the rules already present.

Caveats

This is my own opinionated setup, not a universal standard. Some details are not yet verified against their sources, and the changelog says so openly. For example, the exact PostgreSQL row-level security syntax and passkey support in ASP.NET Core Identity on .NET 10 are marked to be checked the first time they are used. Treat the rules as a starting point and adapt them to your projects.

Links

If you try it on a real project, I would like to hear what breaks first.