skilldrop-cli 0.9.2 → 0.11.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +6 -3
- package/agents/README.md +1 -1
- package/model-routing.json +224 -55
- package/package.json +2 -2
- package/packs.json +2 -1
- package/skills/agent-adoption-stage/SKILL.md +89 -0
- package/skills/agent-adoption-stage/evals/eval_queries.json +34 -0
- package/skills/agent-adoption-stage/evals/evals.json +19 -0
- package/skills/agent-adoption-stage/manifest.json +39 -0
- package/skills/ai-readiness-assessment/SKILL.md +1 -0
- package/skills/ai-readiness-assessment/manifest.json +1 -0
package/README.md
CHANGED
|
@@ -3,16 +3,16 @@
|
|
|
3
3
|
[](https://www.npmjs.com/package/skilldrop-cli)
|
|
4
4
|
[](LICENSE)
|
|
5
5
|
|
|
6
|
-
**[Browse the catalogue →](https://sananthanarayan.github.io/skilldrop/)** — all
|
|
6
|
+
**[Browse the catalogue →](https://sananthanarayan.github.io/skilldrop/)** — all 56 skills, filterable by pack, tag, and model tier.
|
|
7
7
|
|
|
8
|
-
**
|
|
8
|
+
**56 portable AI-agent skills for the deliverables you actually ship** — diagrams, design docs, ADRs, PRDs, runbooks, decks, decision logs, threat models, adversarial reviews — installable into **Claude Code**, **Cursor**, **Kiro**, **Codex**, **GitHub Copilot**, and any AI tool that accepts custom instructions, one skill or one role-based pack at a time:
|
|
9
9
|
|
|
10
10
|
```bash
|
|
11
11
|
npx skilldrop-cli install --pack product-manager # or: solution-architect, dev-team,
|
|
12
12
|
npx skilldrop-cli list # sre-oncall, stakeholder-comms, ai-engineering
|
|
13
13
|
```
|
|
14
14
|
|
|
15
|
-
Originally scoped to solution architects, now broadly useful to PMs, founders, consultants, engineering leaders, exec assistants — anyone who turns ideas into stakeholder-ready artifacts.
|
|
15
|
+
Originally scoped to solution architects, now broadly useful to PMs, founders, consultants, engineering leaders, exec assistants — anyone who turns ideas into stakeholder-ready artifacts.
|
|
16
16
|
|
|
17
17
|
Every skill is a plain `SKILL.md` folder — the [**Agent Skills open standard**](https://agentskills.io) Anthropic ratified — so the same folder runs unchanged in Claude.ai, Claude Code, the Claude Agent SDK, Cursor, Kiro, Codex, Copilot, Antigravity, and anything else that reads the format. Portable by construction: no runtime, no platform, no lock-in.
|
|
18
18
|
|
|
@@ -160,6 +160,7 @@ Designing the agentic systems themselves — the loops, orchestrations, and budg
|
|
|
160
160
|
|
|
161
161
|
| Skill | What it does |
|
|
162
162
|
|---|---|
|
|
163
|
+
| [`agent-adoption-stage`](skills/agent-adoption-stage/SKILL.md) | Place an engineering team on the agentic-coding ladder — **0 gated → 1 assisted (~1 agent) → 2 parallel (~10) → 3 supervised autonomy (~100) → 4 intent-steered (~1000+)** — from observables (agents in flight, who writes the code, what still gets reviewed), never from licence counts or ambition. The load-bearing idea is that **the bottleneck moves**: your attention → review throughput → trust in the loop → finding the work to automate, so the fix that unlocked the last step does nothing for the next. Forces **exactly one stage** and **exactly one unlock**, names the guardrail to *retire* (reading every diff is right at stage 1 and arithmetically impossible at stage 3), and routes each unlock to the skill that implements it (`pre-merge-review`, `agent-loop-design`, `subagent-design`, `agent-budget`). Adapted from Boris Cherny's *Steps of AI Adoption*, stated as capabilities rather than products so it survives the next vendor release. |
|
|
163
164
|
| [`ai-readiness-assessment`](skills/ai-readiness-assessment/SKILL.md) | Score readiness to adopt AI across **six fixed dimensions** — data, tooling, skills, governance, process, culture — each 0–4 with a **one-line evidence reference**, or `[insufficient evidence]` rather than a guessed middle number. Gaps are ranked by **what blocks first**, not by lowest score, with the dependency named ("Skills can't move until Tooling ≥ 2"), and each carries a first action and an owner *role*. Ends with a posture sentence that takes a position and names what would change it — never a bare maturity label, because "you are Level 2 of 5" is not something a leader can fund. |
|
|
164
165
|
| [`ai-use-case-triage`](skills/ai-use-case-triage/SKILL.md) | Rank candidate AI use cases on value × feasibility × risk with the **weights shown** (default 40/35/25). Each candidate is restated as *a workflow and a person*, never a technology; feasibility asks whether the output can be **verified before it matters**, not whether a model can produce it. Produces a recommended first slice with an **observable kill condition** and a time box, plus a mandatory **not-yet list** where every rejection carries the condition that would promote it. A portfolio with no rejections hasn't triaged anything. |
|
|
165
166
|
| [`ai-adoption-rollout`](skills/ai-adoption-rollout/SKILL.md) | Plan the **human** rollout (the counterpart to `migration-plan`'s technical one) — cohorts smallest-first with a reason each is next, per-cohort hands-on enablement built from what the pilot actually got stuck on, champions as roles **with protected hours**, and an adoption **gate per wave** (observable + threshold + bake time + rollback). The comms plan must state explicitly **what will not change** about headcount and evaluation; silence there is read as bad news and is the biggest driver of quiet non-adoption. Licences activated is not adoption. |
|
|
@@ -472,6 +473,8 @@ The [`agents/`](agents/) folder ships **portable reviewer personas** — single-
|
|
|
472
473
|
| [`devils-advocate`](agents/devils-advocate.md) | Correctness — edge cases, broken assumptions, staff-engineer pushback, test gaps | "Will this break?" |
|
|
473
474
|
| [`code-quality`](agents/code-quality.md) | Craft — naming, structure, duplication, complexity, readability | "Will the next engineer hate this?" |
|
|
474
475
|
|
|
476
|
+
| [`security-reviewer`](agents/security-reviewer.md) | Exploitability — injection, authz gaps, secret handling, unsafe deserialisation | "How would someone abuse this?" |
|
|
477
|
+
|
|
475
478
|
No tool auto-discovers a folder named `agents/`; it's the canonical source of truth. See [`agents/README.md`](agents/README.md) for where to copy each file in your tool — `.claude/agents/` for Claude Code, a custom mode for Cursor, an `AGENTS.md` section for Codex, a steering file or custom agent for Kiro.
|
|
476
479
|
|
|
477
480
|
## Skill Usage
|
package/agents/README.md
CHANGED
|
@@ -24,7 +24,7 @@ npx skilldrop-cli install --agent devils-advocate --ide kiro # .kiro/agents/*.
|
|
|
24
24
|
| [`code-quality`](code-quality.md) | Craft — naming, structure, duplication, needless complexity, readability | "Will the next engineer hate this?" |
|
|
25
25
|
| [`security-reviewer`](security-reviewer.md) | Security — authz, injection, secret exposure, SSRF, unsafe deserialization, weak crypto, risky deps | "What can an attacker do with this?" |
|
|
26
26
|
|
|
27
|
-
They are deliberately **split, not merged.** A single "review my code" agent dilutes
|
|
27
|
+
They are deliberately **split, not merged.** A single "review my code" agent dilutes the first three — bug-hunting, craft, and exploitability pull in different directions. Run them as separate passes; together those three are the **code reviewer panel** that [`feature-implement-loop`](../skills/feature-implement-loop/SKILL.md) and [`pre-merge-review`](../skills/pre-merge-review/SKILL.md) drive after each generation round. `devils-advocate` here is the subagent form of the [`devils-advocate` skill](../skills/devils-advocate/SKILL.md); same persona, packaged for a tool's native agent slot instead of on-demand skill invocation.
|
|
28
28
|
|
|
29
29
|
## Fire them as a panel
|
|
30
30
|
|
package/model-routing.json
CHANGED
|
@@ -98,60 +98,229 @@
|
|
|
98
98
|
}
|
|
99
99
|
],
|
|
100
100
|
"skills": {
|
|
101
|
-
"
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
"
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
"
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
"
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
"
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
"
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
"
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
"
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
"
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
"
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
"
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
"
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
"
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
"
|
|
154
|
-
|
|
155
|
-
|
|
101
|
+
"accessibility-audit": {
|
|
102
|
+
"tier": "heavy",
|
|
103
|
+
"rationale": "Adversarial review against WCAG success criteria — cheaper models fault alt-text presence over quality, under-call severity, miss focus-order/name-role-value issues, and claim AT passes from screenshots. Never downgrade."
|
|
104
|
+
},
|
|
105
|
+
"adr-generator": {
|
|
106
|
+
"tier": "standard",
|
|
107
|
+
"rationale": "Structures a decision into MADR/Nygard. Some judgment on title/consequences; not adversarial."
|
|
108
|
+
},
|
|
109
|
+
"agent-adoption-stage": {
|
|
110
|
+
"tier": "standard",
|
|
111
|
+
"rationale": "Places a team on a fixed 5-stage ladder from observables and routes one unlock. Bounded diagnosis against a rubric; escalate via ambiguous-input when the observables are contradictory or the distribution is heavily skewed."
|
|
112
|
+
},
|
|
113
|
+
"agent-budget": {
|
|
114
|
+
"tier": "standard",
|
|
115
|
+
"rationale": "Quantitative spec synthesis against a fixed tier vocabulary and degradation ladder. Cap-setting judgment is bounded by the 3-5x rule; escalate via ambiguous-input when the workflow itself is undefined."
|
|
116
|
+
},
|
|
117
|
+
"agent-loop-design": {
|
|
118
|
+
"tier": "standard",
|
|
119
|
+
"rationale": "Design synthesis against a fixed state-machine pattern and exit-criteria catalog. The gate-placement judgment is bounded by the blast-radius rule; escalate via ambiguous-input when the task itself is contested."
|
|
120
|
+
},
|
|
121
|
+
"agent-threat-model": {
|
|
122
|
+
"tier": "heavy",
|
|
123
|
+
"rationale": "Adversarial reasoning over a capability graph — the judgment is which mitigations are architectural versus theatrical, and that call is exactly where a weaker model produces a confident wrong answer. Never downgraded."
|
|
124
|
+
},
|
|
125
|
+
"agents-md-generator": {
|
|
126
|
+
"tier": "standard",
|
|
127
|
+
"rationale": "Repo inspection plus synthesis against a fixed section order and line budget — the same shape as reverse-architecture. The judgment is the counterfactual test on each convention line, which is bounded; escalate via large-input on monorepos."
|
|
128
|
+
},
|
|
129
|
+
"ai-adoption-rollout": {
|
|
130
|
+
"tier": "standard",
|
|
131
|
+
"rationale": "Generates a phased people-rollout with gates and enablement from a stated tool and population. Structured planning against a fixed shape; escalate via ambiguous-input for large or politically contested rollouts."
|
|
132
|
+
},
|
|
133
|
+
"ai-readiness-assessment": {
|
|
134
|
+
"tier": "standard",
|
|
135
|
+
"rationale": "Scores six fixed dimensions against a rubric and ranks gaps by blocking order. Bounded structured judgment, not adversarial reasoning; escalate via ambiguous-input when the evidence is thin or contested."
|
|
136
|
+
},
|
|
137
|
+
"ai-usage-policy": {
|
|
138
|
+
"tier": "standard",
|
|
139
|
+
"rationale": "Drafts a policy document against a fixed structure (tiers, behaviours, review matrix, exception route). Bounded generation; escalate via ambiguous-input where a regulatory regime is named or contested."
|
|
140
|
+
},
|
|
141
|
+
"ai-usage-report": {
|
|
142
|
+
"tier": "standard",
|
|
143
|
+
"rationale": "Tabulates telemetry into a report. Mostly mechanical, but the 'AI theater' effectiveness call needs judgment."
|
|
144
|
+
},
|
|
145
|
+
"ai-use-case-triage": {
|
|
146
|
+
"tier": "standard",
|
|
147
|
+
"rationale": "Scores candidates on weighted axes and forces a rejection list. Structured comparison with stated weights; escalate via ambiguous-input when candidates are numerous or the value data is contested."
|
|
148
|
+
},
|
|
149
|
+
"api-contract-draft": {
|
|
150
|
+
"tier": "standard",
|
|
151
|
+
"rationale": "Schema synthesis against fixed conventions. The resource modeling needs judgment; the conventions bound it. Escalate via ambiguous-input on contested multi-team contracts."
|
|
152
|
+
},
|
|
153
|
+
"architecture-diagrams": {
|
|
154
|
+
"tier": "standard",
|
|
155
|
+
"rationale": "Translates prose to diagram syntax. Correctness matters; reasoning is bounded."
|
|
156
|
+
},
|
|
157
|
+
"audience-profile": {
|
|
158
|
+
"tier": "light",
|
|
159
|
+
"rationale": "Maps a fixed set of audience archetypes to structural rules. Lookup against a rubric, not synthesis."
|
|
160
|
+
},
|
|
161
|
+
"brief-intake": {
|
|
162
|
+
"tier": "standard",
|
|
163
|
+
"rationale": "Extraction + tagging [explicit]/[implied]/[inferred]. The tagging needs care — above light, below heavy."
|
|
164
|
+
},
|
|
165
|
+
"bug-triage": {
|
|
166
|
+
"tier": "standard",
|
|
167
|
+
"rationale": "Extraction plus judgment calls (severity vs priority, hypothesis ranking) — same shape as brief-intake: above light, below heavy."
|
|
168
|
+
},
|
|
169
|
+
"business-case": {
|
|
170
|
+
"tier": "heavy",
|
|
171
|
+
"rationale": "Weighted multi-option judgment with a committal recommendation — same failure mode as tech-comparison-matrix: cheaper models mis-weight costs, inflate benefits, and miss the flip-assumption. Never downgrade."
|
|
172
|
+
},
|
|
173
|
+
"capacity-cost-model": {
|
|
174
|
+
"tier": "standard",
|
|
175
|
+
"rationale": "Quantitative projection from a demand model against a fixed cost catalog. Headroom and scaling-cliff judgment is bounded by the reference; escalate via ambiguous-input on novel architectures."
|
|
176
|
+
},
|
|
177
|
+
"council-review": {
|
|
178
|
+
"tier": "heavy",
|
|
179
|
+
"rationale": "Multi-perspective deliberation + weighted reconciliation across distinct expert seats. Cheaper models collapse the seats into one voice and either manufacture or miss the real cruxes. Never downgrade."
|
|
180
|
+
},
|
|
181
|
+
"data-contract": {
|
|
182
|
+
"tier": "standard",
|
|
183
|
+
"rationale": "Schema + SLA synthesis against fixed quality dimensions and an evolution matrix. Semantics capture needs care; bounded by the catalog. Escalate via large-input on wide schemas."
|
|
184
|
+
},
|
|
185
|
+
"db-schema-design": {
|
|
186
|
+
"tier": "standard",
|
|
187
|
+
"rationale": "Design synthesis from access patterns against a fixed paradigm/indexing/anti-pattern reference. Paradigm and denormalization judgment is bounded; escalate via ambiguous-input on contested scale/consistency tradeoffs."
|
|
188
|
+
},
|
|
189
|
+
"decision-log": {
|
|
190
|
+
"tier": "light",
|
|
191
|
+
"rationale": "Extracts decisions/owners/dates from notes. Pattern extraction; escalate on long transcripts via large-input rule."
|
|
192
|
+
},
|
|
193
|
+
"deck-builder": {
|
|
194
|
+
"tier": "standard",
|
|
195
|
+
"rationale": "Generates pptx content + runs a script. Content shaping, not hard reasoning."
|
|
196
|
+
},
|
|
197
|
+
"design-doc": {
|
|
198
|
+
"tier": "standard",
|
|
199
|
+
"rationale": "Synthesizes a design doc from a brief. Escalate to heavy via large-input or ambiguous-input when alternatives are genuinely contested."
|
|
200
|
+
},
|
|
201
|
+
"devils-advocate": {
|
|
202
|
+
"tier": "heavy",
|
|
203
|
+
"rationale": "Adversarial code review across four lenses. Cheaper models miss edge cases and under-call severity — the whole value is the hard thinking. Never downgrade."
|
|
204
|
+
},
|
|
205
|
+
"doc-critique": {
|
|
206
|
+
"tier": "heavy",
|
|
207
|
+
"rationale": "Adversarial doc review against rubrics. Same as devils-advocate: the value is catching what a fast pass misses. Never downgrade."
|
|
208
|
+
},
|
|
209
|
+
"exec-summary": {
|
|
210
|
+
"tier": "standard",
|
|
211
|
+
"rationale": "Compression to one page. Needs to keep the right signal; escalate on very long source docs."
|
|
212
|
+
},
|
|
213
|
+
"feature-implement-loop": {
|
|
214
|
+
"tier": "standard",
|
|
215
|
+
"rationale": "Code + test generation against acceptance criteria. The adversarial pass delegates to devils-advocate (heavy) where available; the loop itself is generation."
|
|
216
|
+
},
|
|
217
|
+
"figma-diagrams": {
|
|
218
|
+
"tier": "standard",
|
|
219
|
+
"rationale": "API calls + spec generation. Bounded transformation."
|
|
220
|
+
},
|
|
221
|
+
"guide-builder": {
|
|
222
|
+
"tier": "standard",
|
|
223
|
+
"rationale": "Shapes notes into a styled guide. Generation, not adversarial review."
|
|
224
|
+
},
|
|
225
|
+
"incident-comms": {
|
|
226
|
+
"tier": "standard",
|
|
227
|
+
"rationale": "Audience-segmented message generation under a strict don't-retract discipline. Same shape as exec-summary/audience-profile — translation and altitude, not adversarial reasoning."
|
|
228
|
+
},
|
|
229
|
+
"llm-eval-harness": {
|
|
230
|
+
"tier": "standard",
|
|
231
|
+
"rationale": "Methodology synthesis against a fixed decision tree and pitfall catalog. Grading-method and metric choices need judgment but are bounded; escalate via ambiguous-input on novel task types."
|
|
232
|
+
},
|
|
233
|
+
"migration-plan": {
|
|
234
|
+
"tier": "standard",
|
|
235
|
+
"rationale": "Phased plan synthesis with a strong template. Ordering judgment is bounded by the expand/migrate/contract pattern; escalate via ambiguous-input on contested, high-stakes cutovers."
|
|
236
|
+
},
|
|
237
|
+
"nfr-spec": {
|
|
238
|
+
"tier": "standard",
|
|
239
|
+
"rationale": "Rubric-driven sweep with archetype defaults; the judgment is calibrating targets to business reality. Bounded by the catalog; escalate via ambiguous-input on contested SLOs."
|
|
240
|
+
},
|
|
241
|
+
"observability-plan": {
|
|
242
|
+
"tier": "standard",
|
|
243
|
+
"rationale": "Methodology synthesis against fixed SRE practices (golden signals, burn-rate alerting, pillar split). SLO calibration needs judgment but is bounded; escalate via ambiguous-input on contested reliability targets."
|
|
244
|
+
},
|
|
245
|
+
"okr-cascade": {
|
|
246
|
+
"tier": "standard",
|
|
247
|
+
"rationale": "Structured derivation against a fixed roll-up discipline; the causal-sentence and gap judgments need care but the template bounds them. Escalate via ambiguous-input when the company objectives themselves are contested."
|
|
248
|
+
},
|
|
249
|
+
"postmortem-generator": {
|
|
250
|
+
"tier": "standard",
|
|
251
|
+
"rationale": "Synthesizes a structured doc from incident notes. Contributing-factor chains need judgment but are bounded; escalate via large-input on huge scrollbacks."
|
|
252
|
+
},
|
|
253
|
+
"prd-draft": {
|
|
254
|
+
"tier": "standard",
|
|
255
|
+
"rationale": "Synthesizes a structured requirements doc from a brief. The solution-language discipline needs care; bounded by the template. Escalate via ambiguous-input on contested scope."
|
|
256
|
+
},
|
|
257
|
+
"pre-merge-review": {
|
|
258
|
+
"tier": "standard",
|
|
259
|
+
"rationale": "Orchestration: runs a deterministic gate script, dispatches the (heavy) reviewer subagents, and renders a rule-based go/no-go. The adversarial reasoning is delegated to the panel, so the skill itself is coordination."
|
|
260
|
+
},
|
|
261
|
+
"prfaq": {
|
|
262
|
+
"tier": "standard",
|
|
263
|
+
"rationale": "Synthesizes a press release and FAQs from a product concept against a fixed format. The specificity discipline needs care but the template bounds it; escalate via ambiguous-input when the concept itself is contested."
|
|
264
|
+
},
|
|
265
|
+
"release-notes": {
|
|
266
|
+
"tier": "standard",
|
|
267
|
+
"rationale": "Classifies commits and rewrites them for a reader. The audience translation needs judgment; escalate via large-input on very long ranges."
|
|
268
|
+
},
|
|
269
|
+
"requirements-interview": {
|
|
270
|
+
"tier": "standard",
|
|
271
|
+
"rationale": "Question banks are rubric-shaped, but ranking by design impact and deriving falsification conditions for the specific feature is synthesis — above light."
|
|
272
|
+
},
|
|
273
|
+
"reverse-architecture": {
|
|
274
|
+
"tier": "standard",
|
|
275
|
+
"rationale": "Extracts architecture from code/IaC. Escalate to heavy on large codebases where cross-file inference is heavy."
|
|
276
|
+
},
|
|
277
|
+
"runbook-generator": {
|
|
278
|
+
"tier": "standard",
|
|
279
|
+
"rationale": "Operational doc from service facts. Bounded synthesis."
|
|
280
|
+
},
|
|
281
|
+
"slide-outliner": {
|
|
282
|
+
"tier": "standard",
|
|
283
|
+
"rationale": "Outlines a deck to a time budget. Structuring, not deep reasoning."
|
|
284
|
+
},
|
|
285
|
+
"sonar-onboard": {
|
|
286
|
+
"tier": "light",
|
|
287
|
+
"rationale": "Scaffolds config from detected language + a template. Deterministic fill-in; little judgment."
|
|
288
|
+
},
|
|
289
|
+
"sonar-review": {
|
|
290
|
+
"tier": "standard",
|
|
291
|
+
"rationale": "Formats Sonar API findings into a report. The hard analysis is Sonar's; this is synthesis. Escalate on very large diffs."
|
|
292
|
+
},
|
|
293
|
+
"strategy-analysis": {
|
|
294
|
+
"tier": "heavy",
|
|
295
|
+
"rationale": "Framework selection plus evidenced multi-factor judgment ending in a ranked, committal verdict. Cheaper models fill cells with generic filler, skip the TOWS crossings, and refuse to take a side. Never downgrade."
|
|
296
|
+
},
|
|
297
|
+
"subagent-design": {
|
|
298
|
+
"tier": "standard",
|
|
299
|
+
"rationale": "Design synthesis against a fixed topology catalog and role-card template. The fan-out-or-refuse judgment is bounded by the three-reasons rule; escalate via ambiguous-input on genuinely novel workflow shapes."
|
|
300
|
+
},
|
|
301
|
+
"success-metrics": {
|
|
302
|
+
"tier": "standard",
|
|
303
|
+
"rationale": "Structured measurement design; the primary-metric and counter-metric choices need judgment but the template bounds it. Escalate via ambiguous-input when the goal itself is contested."
|
|
304
|
+
},
|
|
305
|
+
"tech-comparison-matrix": {
|
|
306
|
+
"tier": "heavy",
|
|
307
|
+
"rationale": "Weighted multi-criteria judgment with a recommendation. Mis-weighting is the failure mode; heavy is worth it. Never downgrade."
|
|
308
|
+
},
|
|
309
|
+
"test-plan-generator": {
|
|
310
|
+
"tier": "standard",
|
|
311
|
+
"rationale": "Synthesizes a structured plan from a change description. Risk ranking needs judgment but is bounded; escalate via ambiguous-input on contested or high-stakes releases."
|
|
312
|
+
},
|
|
313
|
+
"threat-model": {
|
|
314
|
+
"tier": "heavy",
|
|
315
|
+
"rationale": "Adversarial reasoning over a design — cheaper models emit checklist residue, miss authz/insider paths, and inflate severity. Never downgrade."
|
|
316
|
+
},
|
|
317
|
+
"user-journey-map": {
|
|
318
|
+
"tier": "standard",
|
|
319
|
+
"rationale": "Structured synthesis into a fixed four-row stage model plus bounded ranking judgment. Escalate via ambiguous-input when the persona or outcome is contested or research inputs conflict."
|
|
320
|
+
},
|
|
321
|
+
"user-story-splitter": {
|
|
322
|
+
"tier": "standard",
|
|
323
|
+
"rationale": "Decomposes an epic into INVEST slices with testable ACs. Structured synthesis; escalation rules cover large or contradictory PRDs."
|
|
324
|
+
}
|
|
156
325
|
}
|
|
157
326
|
}
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "skilldrop-cli",
|
|
3
|
-
"version": "0.
|
|
4
|
-
"description": "Portable AI-agent skills for the deliverables knowledge
|
|
3
|
+
"version": "0.11.0",
|
|
4
|
+
"description": "Portable AI-agent skills for the deliverables knowledge work actually ships — diagrams, ADRs, PRDs, runbooks, decks, threat models and adversarial reviews — installable into Claude Code, Cursor, Kiro, and any IDE that takes custom instructions. One command per skill or per role-based pack.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Sanjay Ananthanarayan",
|
|
7
7
|
"url": "https://github.com/sananthanarayan"
|
package/packs.json
CHANGED
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: agent-adoption-stage
|
|
3
|
+
description: 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).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# agent-adoption-stage
|
|
7
|
+
|
|
8
|
+
Answer one question honestly: **which rung is this team actually on, and what is the single next thing that moves them up?** Not a scorecard, not a tool list — a placement backed by observables, the bottleneck that gates the next step, and one unlock.
|
|
9
|
+
|
|
10
|
+
Adapted from Boris Cherny's *Steps of AI Adoption* (2026-07-16). The stage names and the bottleneck-shift are his; the guardrail changes and the routing here are skilldrop's, and everything is stated as a **capability** rather than a product so it stays true across tools and across years.
|
|
11
|
+
|
|
12
|
+
The load-bearing idea: **the bottleneck moves.** Each stage is limited by something different, so a fix that unlocked the last step does nothing for the next one. Diagnosing the *current* bottleneck is the whole job; the stage number is just its index.
|
|
13
|
+
|
|
14
|
+
## The ladder
|
|
15
|
+
|
|
16
|
+
| Stage | Shape | Observable | The bottleneck |
|
|
17
|
+
|---|---|---|---|
|
|
18
|
+
| **0 · Gated** | no real access | tools unapproved, gateways slow, no path to run outputs | approval process — a legacy security posture optimising cost-per-token instead of outcomes |
|
|
19
|
+
| **1 · Assisted** | you + one agent | **~1 agent**, synchronous, you read nearly every change | **your attention.** Low trust and no self-verification, so you watch instead of moving on |
|
|
20
|
+
| **2 · Parallel** | you orchestrate | **~5–10 agents**, isolated checkouts, agent checks its own work first | **review throughput.** You're checking six streams instead of writing one |
|
|
21
|
+
| **3 · Supervised autonomy** | manager of managers | **~100**, agent writes nearly all code, agents start agents | **trust in the loop**, and token efficiency as volume climbs |
|
|
22
|
+
| **4 · Intent-steered** | steer by intent | **~1000+**, loop closed, monitor by exception | **finding and automating the work**, with the right guardrail per work type |
|
|
23
|
+
|
|
24
|
+
## How to respond
|
|
25
|
+
|
|
26
|
+
1. **Place the team on exactly one stage, from observables.** Ask for (or extract) three things: how many agents a typical engineer has in flight, who writes most of the code now, and what gets reviewed — every diff, final diffs, or exceptions. Quote the evidence. **A range is a refusal** — pick the stage the team is *operating at*, not the best day it ever had. Cap clarifying questions at 2.
|
|
27
|
+
|
|
28
|
+
2. **Discount aspiration.** A team that bought licences for 200 people and has three power users is at stage 1 with an outlier, not stage 2. Place on the median engineer, and say so when the distribution is lopsided — the spread is itself a finding.
|
|
29
|
+
|
|
30
|
+
3. **Name the current bottleneck in one sentence,** and check it against the table. If the team's stated pain doesn't match the stage's bottleneck, that mismatch is the most interesting thing in the assessment — surface it. ("You say review is the constraint, but engineers still run one agent at a time; the constraint is trust, not throughput.")
|
|
31
|
+
|
|
32
|
+
4. **Prescribe exactly one unlock.** The next step, never a backlog of ten. The transitions:
|
|
33
|
+
- **0 → 1:** an approved path to run agents and land their output. Executive alignment, not tooling.
|
|
34
|
+
- **1 → 2:** **a self-verification loop the engineer trusts** — tests, build, lint, typecheck running *before* they look — plus more than one agent at a time and pre-approved safe commands so permission prompts stop blocking.
|
|
35
|
+
- **2 → 3:** context and delegation — let agents read the code, docs and discussions; automate review so it isn't the queue; break work into loops and routines; let agents start agents.
|
|
36
|
+
- **3 → 4:** scaled automation of domain-specific work (migrations, fuzzing, remediation) with per-work-type guardrails.
|
|
37
|
+
|
|
38
|
+
5. **State which guardrail must change**, not just what to add. Guardrails are stage-appropriate, and carrying the old one forward is what stalls teams: reading every diff is right at stage 1 and *arithmetically impossible* at stage 3, where the control moves to the loop (automated review, sandboxing, isolation) and humans review by exception. Name the one to retire and the one to introduce.
|
|
39
|
+
|
|
40
|
+
6. **Route the unlock to something concrete.** Each unlock has an implementation:
|
|
41
|
+
|
|
42
|
+
| Unlock | Where it's implemented |
|
|
43
|
+
|---|---|
|
|
44
|
+
| a trusted self-verification loop | [`pre-merge-review`](../pre-merge-review/SKILL.md) — a mechanical gate whose exit code decides, plus the reviewer panel |
|
|
45
|
+
| automated review that isn't the queue | the reviewer panel (`devils-advocate`, `security-reviewer`, `code-quality`) |
|
|
46
|
+
| loops and routines | [`agent-loop-design`](../agent-loop-design/SKILL.md) — generate→verify→gate with exit criteria and a cap |
|
|
47
|
+
| parallel agents without collision | [`subagent-design`](../subagent-design/SKILL.md) — topology, isolation, typed contracts |
|
|
48
|
+
| token efficiency as volume climbs | [`agent-budget`](../agent-budget/SKILL.md) + a provider-neutral model tier per task |
|
|
49
|
+
| encoding standards so agents inherit them | [`agents-md-generator`](../agents-md-generator/SKILL.md) and skills themselves |
|
|
50
|
+
| guardrails for autonomous work | [`agent-threat-model`](../agent-threat-model/SKILL.md) |
|
|
51
|
+
|
|
52
|
+
7. **End with the re-measure date and what would prove the unlock landed.** An observable: "median agents-in-flight ≥ 3 and engineers stop reading intermediate diffs, in 6 weeks."
|
|
53
|
+
|
|
54
|
+
## Quality bar
|
|
55
|
+
|
|
56
|
+
- **Exactly one stage, cited to observables.** No ranges, no "between 2 and 3" — and never a placement asserted from ambition or licence count.
|
|
57
|
+
- **Placement is on the median engineer**, with the distribution named when it's lopsided.
|
|
58
|
+
- **Exactly one unlock.** A list of ten is a backlog, and it guarantees none of them happens.
|
|
59
|
+
- **The bottleneck is the one gating the *next* step**, not a general complaint about AI.
|
|
60
|
+
- **A guardrail to retire is named**, not only one to add — stage-appropriateness cuts both ways.
|
|
61
|
+
- **Every unlock routes to a concrete implementation**, never to a product name.
|
|
62
|
+
- **Vendor-neutral throughout.** Capabilities, not SKUs; a skill that names this quarter's products is wrong by next quarter.
|
|
63
|
+
- **The source framework is credited.**
|
|
64
|
+
|
|
65
|
+
## When to use this skill
|
|
66
|
+
|
|
67
|
+
- ✅ "How far along are we with coding agents, really?"
|
|
68
|
+
- ✅ Adoption plateaued and nobody can name why.
|
|
69
|
+
- ✅ A leader wants to scale agent usage and needs to know whether the loop can carry it yet.
|
|
70
|
+
- ✅ Re-measuring a quarter after a previous placement.
|
|
71
|
+
|
|
72
|
+
## When NOT to use this skill
|
|
73
|
+
|
|
74
|
+
- ❌ Assessing organisational preconditions — data, policy ownership, incentives — that's [`ai-readiness-assessment`](../ai-readiness-assessment/SKILL.md), a different axis (a team can be governance-ready and stuck at stage 1).
|
|
75
|
+
- ❌ Planning how a tool reaches people — cohorts, enablement, comms — that's [`ai-adoption-rollout`](../ai-adoption-rollout/SKILL.md).
|
|
76
|
+
- ❌ Choosing which use cases to build — that's [`ai-use-case-triage`](../ai-use-case-triage/SKILL.md).
|
|
77
|
+
- ❌ Reporting measured usage from telemetry — that's [`ai-usage-report`](../ai-usage-report/SKILL.md).
|
|
78
|
+
- ❌ Designing one specific loop or fleet — that's `agent-loop-design` / `subagent-design`, which this skill routes *to*.
|
|
79
|
+
|
|
80
|
+
## Anti-patterns to avoid
|
|
81
|
+
|
|
82
|
+
- ❌ **Scaling agent count before the loop has earned trust.** The named trap of stage 2→3: more agents on an unverified loop multiplies review burden instead of output. Trust first, count second.
|
|
83
|
+
- ❌ **A stage claimed from ambition.** Licences bought, a mandate announced, or one enthusiastic staff engineer are not a stage. Median engineer, observable behaviour.
|
|
84
|
+
- ❌ **Carrying stage-1 guardrails upward.** "Read every diff" doesn't scale to ten streams and is arithmetically impossible at a hundred; insisting on it is what caps a team at stage 1 while everyone blames the model.
|
|
85
|
+
- ❌ **Answering with a product list.** Tools don't move a team up a rung — a trusted verification loop does. Name the capability and the loop change.
|
|
86
|
+
- ❌ **Prescribing the whole ladder.** Handing someone stages 2, 3 and 4 at once guarantees stage 1 forever.
|
|
87
|
+
- ❌ **Treating the stage as a status symbol.** Stage 4 is not better for a team whose work doesn't need it; the right stage is the one the work and the trust support.
|
|
88
|
+
|
|
89
|
+
**Non-interactive:** with no user to ask, infer the stage from whatever observables the input contains and tag the placement `[assumption]`, naming what to confirm. If the input has no observable at all — no agent counts, no review posture, no statement of who writes the code — emit `BLOCKED: need at least one observable (agents in flight per engineer, who writes most of the code, or what gets reviewed)` rather than guessing a stage, because a wrong placement prescribes the wrong unlock.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
[
|
|
2
|
+
{
|
|
3
|
+
"query": "How far along are we with coding agents?",
|
|
4
|
+
"should_trigger": true
|
|
5
|
+
},
|
|
6
|
+
{
|
|
7
|
+
"query": "Our AI adoption has plateaued — what's the next unlock?",
|
|
8
|
+
"should_trigger": true
|
|
9
|
+
},
|
|
10
|
+
{
|
|
11
|
+
"query": "Which stage of agentic coding maturity is my team at?",
|
|
12
|
+
"should_trigger": true
|
|
13
|
+
},
|
|
14
|
+
{
|
|
15
|
+
"query": "We want engineers running more agents — are we ready to scale that?",
|
|
16
|
+
"should_trigger": true
|
|
17
|
+
},
|
|
18
|
+
{
|
|
19
|
+
"query": "Assess whether our organisation's data and governance are ready for AI",
|
|
20
|
+
"should_trigger": false
|
|
21
|
+
},
|
|
22
|
+
{
|
|
23
|
+
"query": "Plan the rollout cohorts and enablement for this tool",
|
|
24
|
+
"should_trigger": false
|
|
25
|
+
},
|
|
26
|
+
{
|
|
27
|
+
"query": "Which AI use cases should we build first?",
|
|
28
|
+
"should_trigger": false
|
|
29
|
+
},
|
|
30
|
+
{
|
|
31
|
+
"query": "Design the subagent topology for this specific fleet",
|
|
32
|
+
"should_trigger": false
|
|
33
|
+
}
|
|
34
|
+
]
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
{
|
|
2
|
+
"skill_name": "agent-adoption-stage",
|
|
3
|
+
"evals": [
|
|
4
|
+
{
|
|
5
|
+
"id": 1,
|
|
6
|
+
"prompt": "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?",
|
|
7
|
+
"assertions": [
|
|
8
|
+
"Places the team on exactly one stage — no range — citing the observables from the prompt (one agent at a time, every diff read)",
|
|
9
|
+
"Places on the median engineer and calls out the two power users as an outlier rather than counting them as the stage",
|
|
10
|
+
"Names the bottleneck as attention/trust rather than review throughput, and connects it to the untrusted test suite",
|
|
11
|
+
"Prescribes exactly one unlock — a self-verification loop the engineer trusts — not a list of improvements",
|
|
12
|
+
"Names a guardrail to retire (reading every diff) alongside the one to introduce",
|
|
13
|
+
"Routes the unlock to a concrete implementation rather than to a product name",
|
|
14
|
+
"Ends with an observable that would prove the unlock landed and a re-measure date",
|
|
15
|
+
"Credits the source framework"
|
|
16
|
+
]
|
|
17
|
+
}
|
|
18
|
+
]
|
|
19
|
+
}
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "agent-adoption-stage",
|
|
3
|
+
"version": "0.1.0",
|
|
4
|
+
"description": "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).",
|
|
5
|
+
"entrypoint": "SKILL.md",
|
|
6
|
+
"deps": {
|
|
7
|
+
"npm": [],
|
|
8
|
+
"pip": []
|
|
9
|
+
},
|
|
10
|
+
"env": {
|
|
11
|
+
"required": [],
|
|
12
|
+
"optional": []
|
|
13
|
+
},
|
|
14
|
+
"related": [
|
|
15
|
+
"agent-budget",
|
|
16
|
+
"agent-loop-design",
|
|
17
|
+
"agent-threat-model",
|
|
18
|
+
"agents-md-generator",
|
|
19
|
+
"ai-adoption-rollout",
|
|
20
|
+
"ai-readiness-assessment",
|
|
21
|
+
"ai-usage-report",
|
|
22
|
+
"ai-use-case-triage",
|
|
23
|
+
"devils-advocate",
|
|
24
|
+
"pre-merge-review",
|
|
25
|
+
"subagent-design"
|
|
26
|
+
],
|
|
27
|
+
"tags": [
|
|
28
|
+
"ai-adoption",
|
|
29
|
+
"agentic-coding",
|
|
30
|
+
"maturity-ladder",
|
|
31
|
+
"orchestration",
|
|
32
|
+
"engineering-leadership",
|
|
33
|
+
"bottleneck"
|
|
34
|
+
],
|
|
35
|
+
"model": {
|
|
36
|
+
"tier": "standard",
|
|
37
|
+
"rationale": "Places a team on a fixed 5-stage ladder from observables and routes one unlock. Bounded diagnosis against a rubric; escalate via ambiguous-input when the observables are contradictory or the distribution is heavily skewed."
|
|
38
|
+
}
|
|
39
|
+
}
|
|
@@ -54,6 +54,7 @@ Readiness assessments fail in one of two ways: a number with no evidence behind
|
|
|
54
54
|
- ❌ Writing the rules for what people may put into a tool — that's [`ai-usage-policy`](../ai-usage-policy/SKILL.md).
|
|
55
55
|
- ❌ A market or competitive question ("should we enter this space?") — that's `strategy-analysis`.
|
|
56
56
|
- ❌ Measuring adoption that has already happened — that's `ai-usage-report`.
|
|
57
|
+
- ❌ **Assessing how far an engineering team's agent practice has actually got** — agents in flight, who writes the code, what still gets reviewed — that's [`agent-adoption-stage`](../agent-adoption-stage/SKILL.md). It's the orthogonal axis: this skill scores whether the *organisation* can adopt at all; that one scores how far the *practice* has got. A team can be governance-ready and stuck at stage 1, or running ten agents with no policy at all — run both when the answers disagree.
|
|
57
58
|
|
|
58
59
|
## Anti-patterns to avoid
|
|
59
60
|
|