A guard
Read-only by tool grant, not by instruction: there is no Edit or Write tool in its configuration to reach for. It produces a plan and stops.
Claude Code configuration kit · v1.2.0
Give the model a sense of blast radius.
Out of the box, Claude Code will rewrite your auth middleware, drop a column, and refactor three unrelated files on the way to fixing a CSS bug. This kit gives it what a senior teammate has and a fresh model does not: your project's own conventions, an idea of what is dangerous, and the discipline to read only what the task needs.
MIT licensed · no dependencies · Node.js 18+
$ claudeadd a column to the users table ◆ tier 3 — database schema · routed to db-guard read-only. nothing has been written. PLAN 1 ALTER TABLE users ADD COLUMN plan text NULL 2 backfill in batches, no table lock 3 rollback: DROP COLUMN plan awaiting your approval- Agents
- 8
- Skills
- 28
- Rule files
- 12
- Presets
- 28
- Reference docs
- 18
- Deny rules
- 450
01 — Side by side
Same sentence. Two completely different outcomes.
One line typed into Claude Code: add a column to the users table. Flip the switch to see what the kit changes about everything that comes after it.
add a column to the users table ● Edit prisma/schema.prisma● Edit src/types/user.ts● Bash npx prisma migrate dev --name add_plan Drop and recreate `users`? … applied 47 rows lost Done! I added the column and updated the types.add a column to the users table ◆ tier 3 — DB schema · ESCALATE TO: db-guard db-guard holds no Edit or Write tool. PLAN — additive, zero-downtime 1 ADD COLUMN plan text NULL (no lock) 2 backfill in batches of 1000 3 rollback: DROP COLUMN plan awaiting your approval30files written
01plans shown
01approvals asked
The guard is read-only by tool grant, not by instruction — there is no Edit or Write tool in its configuration to reach for. It is not being asked nicely to hold back.
02 — Mechanics
Four things happen on every task.
You trigger none of them. Describe the work in plain language; the routing is automatic.
-
It reads the project before it edits
Once per session: package manager, config, CI/CD, ORM and migration layout, architecture shape, and the real test command. What it cannot detect it marks
UNKNOWNrather than guessing — a wrong assumption is worse than a stated gap. -
It sizes the blast radius before it plans
Every task lands in a tier, decided before a single file is opened. A one-line CSS fix goes straight through. Anything touching auth, payments, database schema, CI/CD, secrets or infrastructure lands higher.
0 – 2 straight through, smallest safe diff 3 – 4 plan mode, read-only, no edits until you say yes -
It routes to whoever owns that surface
A guarded noun outranks a task verb: "fix the CSS in the login form" is a security question, not a styling one. Rule files load the same way — by path glob, so a Flutter project never pays for the REST-API rules.
tier 3+ tier 0 – 2 An implementer
Works inside the conventions it just read, changes the smallest thing that fixes the problem, and leaves the refactor you did not ask for alone.
-
It verifies the specific thing it changed
Targeted test for behaviour, lint plus test for a new file, a build for a new route, a type-check for a type change. Never the full suite for a one-file edit, and no "done" without the command output behind it.
What that looks like in practice
Ordinary requests, and where each one lands before a single file is touched.
-
fix the broken link on the login page
-
add a settings page
-
redesign the checkout flow
-
add SBOM generation to the Docker CI
-
add a column to the users table
03 — Context economy
You pay for what the task touches.
A configuration kit is a standing tax on every prompt you ever send. This one is measured, capped, and mostly not loaded.
452lines load on every turn
18% of the rule set2558 lines in total
- Unconditional
- 3 files, capped at 500 lines
- Path-scoped
- 10 rule files
- On demand
- 18 reference docs
- Three files load unconditionally — the protocol and the two rules with no path scope. Their combined line count is capped, and the cap fails the build, so "always-loaded" cannot quietly become "always-loaded and bloated".
- The other 10 rule files wait for a path match — a Flutter project never pays for the REST-API rules, and touching a migration pulls in the database rules by itself.
- 18 reference docs load only when a skill asks — the per-stack command table, the zero-downtime migration playbook, the dependency-audit guide. Read once, when needed, rather than carried all session.
- Trivial work skips the survey entirely — a single file under ten lines runs no boot sequence: no manifest read, no config scan, no architecture detection.
- Verification is targeted, and reading is delegated — the test for the thing that changed rather than the whole suite, and read-heavy sweeps go to subagents with their own context window, so only the conclusion comes back.
04 — Install
Three lines, typed inside Claude Code.
Recommended
-
/plugin marketplace add mtvrkan/senior-dev-kitRegisters this repository as a plugin marketplace. -
/plugin install senior-dev-kit@senior-dev-kitPulls the agents, skills, commands and stack presets. -
/kit-setupWrites the two things a plugin structurally cannot: the path-scoped rules and the permission rules. It shows you exactly what it will do, waits for a yes, and backs up anything it touches.
Restart Claude Code, then run /kit-doctor to confirm every piece landed.
Updates arrive through /plugin marketplace update.
Or install the files yourself
Node.js 18 or newer, no dependencies.
git clone https://github.com/mtvrkan/senior-dev-kit.git
cd senior-dev-kit
node scripts/install.mjs --dry-run
node scripts/install.mjs
Nothing you had is destroyed: the protocol goes into your CLAUDE.md inside
markers, deny rules are merged into your settings.json, and anything
overwritten is backed up first. Pick one path, not both.
05 — Inside
What you actually get.
agents
Guards that cannot write
Four are read-only by tool grant, not by instruction: there is no Edit or Write tool in their configuration to reach for. They produce a plan and stop. The other three implement.
skills
A procedure per task shape
Fix a bug, add a page, review a migration, gate a release — each a written discipline the model follows instead of improvising. Most trigger on task shape; a few are manual-only by design.
rule files
A context budget with a gate behind it
Three files load every turn, under a combined line cap a script enforces. The rest load on a path-glob match, and the 18 reference docs load only when a skill needs one.
450
deny rules
Files the model is not allowed to open
Not a prompt asking nicely — permission rules the harness enforces before a tool ever runs, so a secret cannot reach the context window in the first place.
.env
.env.*
*.pem
*.key
id_rsa
.ssh/
serviceAccountKey.json
*.tfstate
kubeconfig
secrets/
28 stack presets · house conventions per stack
Stack presets included: angular, astro, django, docker, dotnet, drizzle, fallback, fastapi, flutter, go-api, kubernetes, laravel, mongodb, nestjs, nextjs-saas, node-express, nuxt, postgres, prisma, rails, react-native, react-vite, rust-axum, spring-boot, supabase, sveltekit, swiftui, terraform.
06 — Verified
Every number on this page is derived, not typed.
A configuration kit rots quietly. Nothing crashes when a rule file starts recommending a tool another rule retired, or when a README claims a count that stopped being true six commits ago.
So the repository checks what a test suite normally cannot. On every change, the consistency checks:
- Re-derive every count from disk — the figures in the rail at the top of this page come from that same derivation at build time.
- Pin the line budget of the three files that load on every turn, so the context cost of the kit cannot creep.
- Verify each rule's globs actually reach the layouts it claims to cover.
- Grade the kit's own code examples against the prose around them — the example that logged a user's email nineteen lines under "never log PII" is why.
- Fail the build if a preset recommends a tool a rule file retires.
Findings get closed at the root, and the check that closes one gets written down, so the same class cannot come back unnoticed. That is the whole method. Even the step list on the right is read out of the gate runner rather than transcribed next to it.
- test
- validate
- link-check
- consistency-check
- docs-check
- routing-evalstatic only — live scoring needs RUN_ROUTING_EVAL=1 and the claude CLI
- behavior-evalstatic only — live scoring needs RUN_BEHAVIOR_EVAL=1 and the claude CLI
- check-plugin
- check-installcopy installs only — where there is none it compares nothing, and says so in its own output
- typecheck
- lint
- markdown-lint
- audit