Claude Code, but with a sense of blast radius.
Out of the box, Claude Code will happily rewrite your auth middleware, drop a column, and refactor three unrelated files on the way to fixing a CSS bug. This kit gives it the three things a senior teammate has and a fresh model does not: an idea of what is dangerous, a written procedure per kind of task, and a context budget that something actually enforces.
How it works
Four things happen on every task. You do not trigger any of them — describe the work in plain language and 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. A one-line CSS fix goes straight through. Anything touching auth, payments, database schema, CI/CD, secrets or infrastructure is Tier 3 or higher — which means 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.
-
It verifies the specific thing it changed
Targeted test for behavior, 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 to back it.
| You say | It routes to |
|---|---|
| "fix the broken link on the login page" | bug-hunter |
| "add a settings page" | senior-engineer |
| "redesign the checkout flow" | feature-plan + security-guard |
| "add SBOM generation to the Docker CI" | devops-guard |
| "add a column to the users table" | db-guard — plan first, no migration without approval |
Install
Three lines, all typed inside Claude Code.
/plugin marketplace add mtvrkan/senior-dev-kit
/plugin install senior-dev-kit@senior-dev-kit
/kit-setup
The third line is a one-time step, and it exists for a structural reason: Claude Code
loads path-scoped rules and permission rules only from your settings directory, and a
plugin is not allowed to write there. /kit-setup 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. Updates come from
/plugin marketplace update.
Or install the files into your own settings directory
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 # see exactly what would change
node scripts/install.mjs # then do it
Nothing you already had is destroyed: the protocol goes into your
CLAUDE.md inside markers, the deny rules are merged into your
settings.json, and anything overwritten is backed up first. Pick one path or
the other — not both.
What's inside
Guards that cannot write
Four of them 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.
A procedure per task shape
Fix a bug, add a page, review a migration, gate a release — each is a written discipline the model follows instead of improvising. Most trigger on task shape; a few are manual-only by design.
A context budget with a gate behind it
Only three files load every turn, under a combined line cap a script enforces. The rest load on a path-glob match, and the 16 reference docs load only when a skill actually needs one.
House conventions per stack
Web, backend, mobile, ORM, database and infrastructure. Each ships a full document and a short one, so several stacks compose by concatenation. The kit offers to seed a project that has none — it offers rather than writes.
Secrets the model cannot read
.env, private keys, service-account JSON, Terraform state, kubeconfig. Not
a prompt asking nicely — permission rules the harness enforces before a tool ever runs.
Every claim on this page is derived
The numbers here are counted from the repository at build time, never typed by hand, and a consistency check fails the build if anyone tries. The kit holds itself to what it asks of you.
How it's built
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 the things a test suite normally cannot.
npm run check runs the unit tests, the frontmatter and routing validators, a
link check, the consistency checks, plugin-manifest validation, type-check, lint, markdown
lint and a dependency audit. The consistency checks re-derive every count from disk, pin the
always-loaded line budget, verify each rule's globs actually reach the layouts it claims,
grade the kit's own code examples against the prose around them, and fail if any preset
recommends a tool a rule file retires.
Findings get closed at the root and the closing check gets written down, so the same class cannot come back unnoticed. That is the whole method.