Place an engineering team on the agentic-coding adoption ladder (0 gated → 4 intent-steered) using observables like agents-in-flight per engineer and who writes the code, name the one bottleneck gating the next step, prescribe the single next unlock, and state which current guardrail must change. Use when a leader asks "how far along are we with coding agents", "why has our AI adoption plateaued", or "what do we do next to get more out of this". Do NOT use to assess organisational preconditions like data, policy, and culture (that's ai-readiness-assessment) or to plan a tool's human rollout (that's ai-adoption-rollout).
In Claude Code, with the ai-engineering plugin installed, invoke it as:
/ai-engineering:agent-adoption-stage
Try it
A realistic prompt from the skill's acceptance evals:
We bought Claude Code for our 60 engineers six months ago. Most people use it like autocomplete for one task at a time and still read every diff before merging. Two staff engineers run several sessions at once. Tests are flaky so nobody trusts them. Where are we and what's next?
What a good result looks like
Exactly one stage, cited to observables. No ranges, no "between 2 and 3" — and never a placement asserted from ambition or licence count.
Placement is on the median engineer, with the distribution named when it's lopsided.
Exactly one unlock. A list of ten is a backlog, and it guarantees none of them happens.
The bottleneck is the one gating the *next* step, not a general complaint about AI.
A guardrail to retire is named, not only one to add — stage-appropriateness cuts both ways.
Every unlock routes to a concrete implementation, never to a product name.
Vendor-neutral throughout. Capabilities, not SKUs; a skill that names this quarter's products is wrong by next quarter.
The source framework is credited.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 86% of its checks, against 43% without it, and a blind judge preferred it. How skills are checked
22 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
Places the team on exactly one stage — no range — citing the observables from the prompt (one agent at a time, every diff read)
Places on the median engineer and calls out the two power users as an outlier rather than counting them as the stage
Names the bottleneck as attention/trust rather than review throughput, and connects it to the untrusted test suite
Prescribes exactly one unlock — a self-verification loop the engineer trusts — not a list of improvements
Names a guardrail to retire (reading every diff) alongside the one to introduce
Routes the unlock to a concrete implementation rather than to a product name
Ends with an observable that would prove the unlock landed and a re-measure date
Credits the source framework
It judges adoption from the telemetry rather than the survey or the CTO memo: about half the engineers (34 of 64) were active in the last 30 days, and active engineers mostly run one agent at a time
It says the CTO memo's claim that agents write about 80% of the code is contradicted by the telemetry (81 of 374 merged PRs in September, about 22%, were agent-authored), and notes the survey is self-reported from 29 of 64 engineers
It identifies code review as what is holding progress back, citing the roughly three-day wait for agent PRs and/or the 19 agent PRs closed unreviewed, and links it to the rule requiring two human reviewers including a senior engineer
The recommended next step does not depend on buying the Enterprise tier, because the CFO has frozen new tooling contracts and upgrades until April 2027
It does not rank individual engineers, and says the telemetry is only broken down by team
It does not invent figures, teams or policies that are not in the files
It fits on one page (roughly 500 words or fewer)
It gives an assessment and a recommendation in this reply rather than asking questions first
It says adoption is uneven: one developer works with several agents at once while the other three mostly use it as autocomplete
It names the lead developer's review load as a limit on getting more value, since more agent output means more for her to review
It recommends one main next step rather than a long list of options
It does not suggest letting changes go live without review; any change to the review process keeps a check before changes go live
It does not invent usage figures, costs or productivity numbers that were not given
It is a few bullets in plain language, without unexplained technical jargon
When it should and shouldn't activate
Should activate:
How far along are we with coding agents?
Our AI adoption has plateaued — what's the next unlock?
Which stage of agentic coding maturity is my team at?
We want engineers running more agents — are we ready to scale that?
Should leave to another skill:
Assess whether our organisation's data and governance are ready for AI
Plan the rollout cohorts and enablement for this tool
Which AI use cases should we build first?
Design the subagent topology for this specific fleet