Playbook library
Starter playbooks, written to be enforceable.
An empty playbook is worth nothing on day one. These are opinionated starting points — every rule here is specific enough that a senior reviewer could judge it pass or fail from the lines a pull request adds, which is exactly what Normik sees.
That bar rules things out. “Say in the description why you added this dependency” and “never edit a migration that already ran” are good review standards, and neither is in this library: the gate reads added lines, not PR descriptions and not a file's history, so it could only stay silent or guess. Standards like those are worth writing down — in your review checklist, not as a gate rule that blocks a merge.
They are not universal law. Some of these rules will be wrong for your codebase, and a couple will be wrong for everyone's. Take them as a first draft of an argument, not a standard to comply with.
API security baseline
The boundary rules that generated CRUD endpoints keep missing.
Teams shipping HTTP APIs — Node, Python, Go, any framework.
10 rules6 error4 warning
Next.js App Router conventions
Server/client boundary discipline, where generated code leaks hardest.
Product teams on Next.js 14+ with the App Router.
11 rules4 error6 warning1 info
Terraform & infrastructure as code
Rules for the diffs where a review miss deletes a database.
Platform and infrastructure teams reviewing Terraform or OpenTofu pull requests.
10 rules6 error2 warning2 info
TypeScript backend service
Runtime honesty: types you actually checked, failures you actually handle.
Node/TypeScript service teams — API servers, workers, jobs.
11 rules6 error4 warning1 info
Database migrations & schema change
Zero-downtime rules for the PRs that lock a table at peak hour.
Teams doing rolling deploys against a live Postgres or MySQL database.
11 rules6 error3 warning2 info
Multi-tenant data isolation
The one bug class where a single missed filter is a breach notification.
SaaS teams where one database serves many customers — including agencies running client workspaces.
10 rules7 error3 warning
AI-generated code guardrails
The failure modes that are specific to code an agent wrote.
Any team where agents (Claude Code, Cursor, Copilot) write a meaningful share of the diff.
10 rules4 error5 warning1 info
How to use these
Importing a playbook wholesale is the fastest way to make your team resent the gate. The three steps below are the ones that make the difference between a playbook people maintain and one they route around.
01
Take the ones you'd actually argue about
A playbook earns its place when a violation would genuinely change your mind in review. Copy the rules that match a conversation your team keeps having, and drop the rest — a rule nobody believes in only produces noise the team learns to ignore.
02
Rewrite them in your own words
Replace our example paths with your real ones, name your actual shared modules, and say why the rule exists in your codebase. The model judges better when the statement carries your intent rather than a generic one.
03
Start with fewer errors than you think
Only severity error blocks a merge. Import a playbook mostly as warnings, watch a few weeks of real pull requests, then promote the rules that turned out to matter. A gate that blocks on day one gets switched off in week two.
What separates a rule that works from one that generates noise is covered in the playbook documentation. You can also point a coding agent at an existing repository and let Normik draft rules from what it finds — they arrive pending human review, never active on their own.
Want to see one of these fire on real code before signing up? The sandbox runs a live analysis on a snippet you paste, or create a free account and add the rules you kept — one at a time, or drafted for you from a repository you point an agent at.