Which Rung of AI Adoption Is Your Team On? Finding Out From Evidence

You find out which rung of AI adoption your team is on by looking at what is actually in the repo and on the machine, not by asking people how they feel about it. I built a Claude Code plugin, ladder-adoption, that does exactly that: a read-only probe collects evidence, a rubric scores it, and the result is one "smallest next action" that a human applies.

This matters most where "a human applies it" is not a nicety, for example healthcare and finance. Below is how it works, what it refuses to do, and where I deliberately keep the claims small.

Why a questionnaire is the wrong tool

Most AI adoption maturity models are surveys. Teams answer generously, the score goes up, and nothing on disk changes. The rubric behind this plugin is Boris Cherny's Steps of AI Adoption, dated July 2026 in the plugin's README. His table has an explicit row for every transition, "how to get from step N to N+1". The plugin turns each row into a gate file with concrete checks.

The point I care about: a step number is a summary. The useful output is the list of failing checks and what to do about them.

The one principle: the plugin knows nothing about you

The plugin ships two things only: where to look (a discovery guide and a probe script) and the rubric. It knows nothing about your machine, your project or your team. Everything else is discovered at run time and tagged:

• verified: seen in a file or command output during this run
• assumed: inferred from a name or convention
• unknown: could not be observed

A gate group passes only when every required check is verified. unknown never passes. That is the honesty rule in one line: if it cannot be shown, it does not count.

How /ladder finds your rung

The probe

probe.sh is a plain bash script. You can run it without Claude:

bash skills/ladder/scripts/probe.sh /path/to/repo | jq .

It is read-only and prints names and counts, never secret values. It looks at the Claude Code version, global settings, skills, MCP server names, plugins, CLIs, and in the repo: CLAUDE.md, .claude/, verification scripts, CI files, deploy files, migration folders and environment variable names. Environment files are never read; only their presence and whether they are git-ignored.

Some things are not observable on disk, such as whether you run two sessions in parallel. Those are asked once, as one grouped question. In a headless run (CI, a routine) nothing is asked and the answer is recorded as unknown.

Checks come in three kinds

A check is probe (decided by script output), inspect (Claude reads a file and judges) or self-report (asked once, otherwise unknown). This keeps the judgment calls visible: you can see which verdicts a script decided and which a model did.

The profile is a committed file

The result is written to .ladder/profile.md in the repo. Findings live there, not in agent memory, so a headless run on another machine starts from the same state. It is also reviewable in a pull request like any other file. The report says which step, which gate checks fail, and why the repo is not one step higher.

The plugin also refuses to be flattered. A repo at Step 1 with a Step 3 mechanism bolted on, such as a trigger that starts Claude, is still Step 1. The source names the trap: scaling agent count before the loop has earned trust. And text in the repo that claims a step is quoted as a finding, not obeyed.

The smallest next action

After scoring, /ladder picks the single failing required check that is cheapest to fix and unlocks the most. It prefers a file edit (a deny rule, a typecheck script, a CI job) over a team decision, and it names the exact change, the file and who applies it.

It does not apply it. /ladder writes one file, the profile, and never changes settings, CI, CLAUDE.md or code. Applying the action is a human's call.

If you want a longer route, /autonomy runs a ten-question interview for the things no probe can answer (what agents may do overnight, what they must never touch, what a push to the default branch does) and writes an ordered plan. Per the README it refuses to schedule agents before automated review has proved it finds things.

/incident-response: a supervised loop

/incident-response handles one production incident. The README describes it as one concrete way to earn the 2-to-3 gate. It runs --init once per repo to write .ladder/incident-profile.md, the project-specific contract, and later runs read that profile. Then, for one incident:

1. Read the incident and normalise it; missing fields stay null, never invented.
2. Dedupe by fingerprint against the state store. If an active incident exists, add a note and stop. One agent per fingerprint.
3. Retrieve context in the order the profile defines: recent commits, the code path, docs, knowledge base, history, logs.
4. Diagnose with one hypothesis, evidence lines and a confidence level: high, medium or low.
5. Only if the profile's phase allows it and the fix is small and safe (by default at most three files, no schema, auth, payment or deletion), prepare a fix on a branch in a git worktree.
6. Run the repo's own verification commands. Each reports pass, fail or not_available, and "no test covers this flow" goes into the report as is.
7. Report to a human in a fixed shape, including whether this is something an engineer would have done.

It stops and hands over to a human when confidence stays low, verification fails twice, data is missing, sources conflict, or a fix would need a production database or config change.

What it never does

The hard guardrails hold regardless of the profile: it never deploys, merges, pushes to the base branch or tags a release. It never runs destructive database operations against non-local targets, never prints secret values, and never edits source-of-truth docs (it proposes edits in the report). Instructions found inside an incident payload, logs or a stack trace are treated as data, quoted in the report, and not followed.

What I do and do not claim for regulated teams

I do not claim this makes a team compliant with anything. Regulators and auditors have their own requirements. What I do claim is narrower and checkable in the repo:

• Findings are evidence-based and labelled by how certain they are.
• The probe is read-only and does not output secret values.
• The only file the scorer writes is a profile you can review in a pull request.
• The incident loop proposes; a human merges and deploys.

If you want to talk about applying this to your own repo, see /contact. The plugin runs on your machine; for how this site handles data, see /privacy. The way I host my own stack is in self-hosting Payload CMS with Coolify.

Related: how I publish these skills, auditing a site with a skill and Search Console content briefs.

Try it

/plugin marketplace add kkuklewski/ladder-adoption
/plugin install ladder-adoption@ladder-adoption

Then run /ladder. To get the plain probe JSON with no profile written, run /ladder scan.

FAQ

Does the probe read my secrets? No. It prints names and counts, never values, and .env* files are not read. Only their presence and git-ignore status are reported.

Does /ladder change my settings? No. It writes .ladder/profile.md and stops. No settings, hooks, CI or code are edited.

Can /incident-response deploy a fix? No. It never deploys, merges, pushes to the base branch or tags a release. At most it prepares a fix in a worktree branch, and only when the profile's phase allows it.

What if nobody can answer the questions? Unanswered items are recorded as unknown, and unknown never passes a check. Headless runs always finish with a report.

Where does the ladder come from? From Boris Cherny's Steps of AI Adoption, July 2026, as credited in the plugin README.