Give your AI code reviewer a rulebook: deterministic DevOps reviews with Claude Code

Anmol Nagpal — Sun, 30 Aug 2026 02:27:12 +0000

An AI reviewer that says "looks good to me" on a Terraform PR that ships a public S3 bucket is worse than no reviewer, it launders a bad change through a trusted-looking check. The fix isn't a smarter model, it's a rulebook: a fixed catalog of findings, each with a stable ID, each backed by a test, so the review is the same on Tuesday as it was on Monday.

That's what devops-skills is, 18 review and scaffolding skills for Claude Code (and Cursor, and Codex), where every finding carries a rule ID from a canonical registry and every rule has a fixture behind it.

Install

$ /plugin marketplace add anmolnagpal/devops-skills
$ /plugin install clouddrove@devops-skills
✔ Plugin "clouddrove" installed (1.5.0)

Or everything (Cursor rules + Codex AGENTS.md + MCP), one line:

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/anmolnagpal/devops-skills/main/scripts/bootstrap.sh)" -- --all

What a review actually looks like

Point it at a Terraform module before you raise the MR:

> review my terraform before I raise the MR

BLOCKING, Must fix before MR
[main.tf:14] TF-STATE-001 No remote backend, state would live on a laptop
 -> add a backend "s3" block with DynamoDB state locking
[rds.tf:31] TF-VAR-001 Hardcoded DB password in `default`
 -> move to a variable, mark sensitive = true, source from Secrets Manager
[s3.tf:8] SEC-PUB-001 Bucket exposed via `acl = "public-read"`
 -> remove the public ACL; add a public_access_block with all four flags true

ADVISORY, Should fix
[s3.tf:8] TF-RES-001 Bucket missing required tags (Environment, Team, ManagedBy)

Summary: 3 blocking issue(s), 1 advisory issue(s).

Notice the IDs. TF-STATE-001 means the same thing every run, in every repo, to every teammate. You can waive one in a baseline and the waiver still makes sense next quarter. The same IDs come out of auditkit's deep audit engine, so an inline review and a full audit speak one language.

"Tested findings, not asserted", what that means

Each rule ships a fixture pair: a bad input that must trip it, and a clean input that must not. Static, model-free, CI-runnable:

$ bash skills/tf/evals/validate.sh
OK [tf]: 17 case(s) valid against 30 catalog rule(s).

$ bash scripts/check-rule-ids.sh
check-rule-ids: 179 canonical, 173 emitted, 6 reserved, 0 planned.

If a skill invents a rule ID that isn't in the registry, CI rejects the PR. If a fixture references a rule the catalog doesn't define, the eval fails. The rulebook can't drift from the tests.

A real one: is your audit log actually on?

Everyone "has logging." Fewer people have an audit log that is on, complete, off the node that wrote it, and tamper-proof. The logging skill checks exactly that across k8s, GKE, AKS, and CloudWatch. Here's the interesting part, we ran it against a real k3s cluster instead of trusting the fixture.

$ kubectl get --raw=/metrics | grep apiserver_audit_event_total
apiserver_audit_event_total 0 # 325-day-old cluster, zero audit events

$ cat /etc/rancher/k3s/config.yaml
disable:
 - traefik
node-ip: 192.168.13.108 # no kube-apiserver-arg, no audit-policy-file

Three independent signals, one conclusion, audit logging is off. The skill's finding matches the ground truth:

BLOCKING, Must fix before deploy
[/etc/rancher/k3s/config.yaml:1] LOG-K8S-001 k3s server has no audit logging:
 kube-apiserver-arg omits audit-policy-file / audit-log-path (off by default)
 -> add audit-policy-file, audit-log-path, and an audit-webhook backend

Summary: 1 blocking issue.

LOG-K8S-002 (policy too coarse) and LOG-K8S-003 (log stays node-local) correctly stayed silent, there's no policy to be coarse and the log isn't merely local, it's absent. A rule that fires on a real cluster the way it fires on its fixture is a rule you can trust.

Mapped to the frameworks

Every security and infra skill declares which controls it enforces, MITRE ATT&CK, NIST CSF 2.0, D3FEND, generated into a machine-readable index.json and a coverage table:

$ jq '.count, (.skills | map(select(.frameworks!={})) | length)' index.json
18
15

So "which of my controls does this skill check" is a lookup, not a guess.

Try it on your worst repo

> review my helm values for prod
> is this plan safe to apply to prod? # reads tfplan.json
> is audit logging on for this cluster?

It's MIT, actively maintained, and conforms to the agentskills.io open standard. Repo: https://github.com/anmolnagpal/devops-skills. If you break it or want a rule it doesn't have, open an issue, the last three shipped rules came straight from real gaps.