Claude config: rules and guardrails for Claude ... (Update: 14/11/2026)

This is the follow-up to my 10/11/2026 update.

If you missed it: claude-config is a template repository of rule files for Claude Code on .NET + Angular projects, plus a personal plugin, kit, that turns the most important rules into hooks and slash commands.

In four days the plugin went from 1.10.0 to 1.14.0. Here is what actually changed, and why.

The short version

Area	Before (10/11)	Now (14/11)
Plugin	1.10.0	1.14.0
Slash commands	a handful	21 (`/kit:...`)
Hooks	fewer, stricter	13 checks, fewer blocking ones
Rules	`core.md` 3.3x	`core.md` 3.44, `git.md` 1.9, `lavoro.md` 1.3
Docker module	loaded with the rest	optional, only on explicit request

1. Fewer blocks, more written rules

The first lesson of using hooks for a few days: a hook should block what is dangerous, not what is merely stylistic. I removed from guard-commands:

the block on git init (it stays a written rule: Claude never initialises a repository by itself);
the checks on commit-message shape (capital letter, trailing full stop, 72 characters). The hook now only verifies the type(scope): description format.

attesa-test (arbitrary waits in tests) and nowarn became warnings instead of blocks. A legitimate exception is still declared in the code with kit-allow: <id> — <reason>.

What stays blocked: push --force, reset --hard, --no-verify, clean -f, rm -rf, git add -A, real secrets in appsettings*.json, and a few unsafe code patterns.

2. A real release flow: tag, bump, GitHub release

Tags and releases used to be "somebody should do this". Now they are rules and a check:

Tag format is X.Y.Z (no v prefix), annotated, created only after the merge on main, pointing at the merge commit.
guard-commands blocks the creation of a tag with a different name or from a branch other than main. Listing and deleting tags still work.
At the end of every completed plan, Claude proposes the bump commit (SemVer version with the reason, version file, ### Release X.Y.Z entry in the changelog) on a release/X.Y.Z branch. It never decides the version alone and never commits on main or develop.
Tag, tag push and gh release each need an explicit yes. The user's yes cannot be verified by a hook, so this one is a written rule.
Pull requests and releases through gh work only if the project's CLAUDE.md declares the GitHub CLI as installed. Claude asks that once per project.

3. Commit and PR skills: launching them is the green light

Three skills cover the daily git loop:

/kit:commit-passo creates the commits in sequence, with no intermediate confirmations, never on main/develop (it creates the working branch itself). It stops with a single question only in anomalous cases: possible secret, ambiguous type, a file with changes for different commits, red build or tests, failed hook.
/kit:pr-develop opens the PR from feature/* or bugfix/* to develop. It is the only skill Claude may launch on its own, and only after proposing it with one question at the end of commit-passo.
/kit:pr-main opens the PR to main, checks whether main is ahead of develop first (merge commit, never squash, to avoid add/add conflicts on the next PR), and after your confirmed merge cleans up the merged working branches and aligns main and develop with git pull --ff-only.

The merge itself is always yours.

4. Review skills that cannot edit files

There are now 13 review-style skills (/kit:review-regole, /kit:consegna, /kit:verifica, /kit:sicurezza, /kit:verifica-frontend, /kit:qualita-test, /kit:dati-efcore, /kit:accessi-api, /kit:gdpr-dati, /kit:accessibilita-ui, /kit:colori-tema, /kit:localizzazione, ...). A review that silently "fixes" things defeats its purpose, so they now have:

disable-model-invocation: they run only when you type them;
disallowed-tools for Edit and Write: they report, they don't modify.

Two of them are new in this round, /kit:verifica-frontend and /kit:sicurezza, next to /kit:verifica:

/kit:verifica runs the .NET checks (restore, format, warning-free build, tests, vulnerable packages, EF model, compose, whitespace).
/kit:verifica-frontend does the same for Angular (install, lint, Prettier, tests with coverage, production build, npm audit, any, hard-coded colours, missing translations).
/kit:sicurezza checks the security items of the delivery checklist (threat model, hostile-input tests, fail closed, resource abuse, logs and alerts, SECURITY.md), runs /security-review and merges the results.

Every skill also declares a model (Haiku for mechanical ones, Sonnet for the rest) and opens its answer with a "Model in use" line, so you can see the effect. A caveat I verified only by hand: the documentation does not confirm that the model override applies to skills with disable-model-invocation: true launched via /name. It works on my machine; check yours.

Also renamed: /kit:code-review is now /kit:review-regole, to stop clashing with the built-in /code-review.

5. Rules: smaller, clearer, labelled

MUST / PREFER everywhere. In backend.md and frontend.md every rule now says whether it is binding (MUST) or a default you can override with a stated reason (PREFER), with Rule / Reason / Exception kept separate. Mixed entries were split (for example OpenAPI: the MUST part, "UI only in Development", is separated from the PREFER part, which UI to use).
docker.md is optional. It lives in rules-optional/ and is activated only if you explicitly ask ("create a Dockerfile"). Not every project ships with Docker, so the rules shouldn't assume it.
/clear or /compact? lavoro.md now has the criterion: /clear when the restart state is already on files (PIANO.md, CHECKLIST.md, uncommitted changes) or the next job is unrelated; /compact when the work continues and the files don't yet hold everything. Claude suggests one; it can't run either.
Verified sources. The ICU plugin licences and versions for Angular i18n were read from the npm registry (MIT), instead of being marked "unverified".
Documentation follows the work. /kit:aggiorna-docs and /kit:buonasera update README, CHANGELOG and, if the project has one, the documentation wiki, without asking. Claude asks once whether a wiki exists and stores the answer.

6. Updating

Plugin (once per machine):

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

Already have the rules in a project? Open Claude Code there and run:

/kit:aggiorna-regole

It compares your files with the template, shows the differences, asks for one confirmation, keeps .bak copies, removes modules that no longer exist in the template and realigns the rules-related lines of your CLAUDE.md.

New project: "Start a new project" (or /kit:avvia-progetto). Existing project without rules: /kit:copia-regole.

Honest limits

The hooks read the code line by line. Multi-line constructs can slip through, so human review is still needed.
129 plugin tests pass, but they test the hooks, not the quality of what Claude writes.
The hook cannot verify that you said yes before a tag or a release. That is why those steps remain written rules.
The rules themselves are in Italian; code, identifiers and commit messages are in English.