skilldrop-cli 0.9.1 → 0.9.3

package/README.md

@@ -3,9 +3,9 @@
 [![npm](https://img.shields.io/npm/v/skilldrop-cli)](https://www.npmjs.com/package/skilldrop-cli)
 [![license](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
 
-**[Browse the catalogue →](https://sananthanarayan.github.io/skilldrop/)** — all 51 skills, filterable by pack, tag, and model tier.
+**[Browse the catalogue →](https://sananthanarayan.github.io/skilldrop/)** — all 56 skills, filterable by pack, tag, and model tier.
 
-**51 portable AI-agent skills for the deliverables knowledge workers 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:
+**56 portable AI-agent skills for the deliverables knowledge workers 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:
 
 ```bash
 npx skilldrop-cli install --pack product-manager     # or: solution-architect, dev-team,
@@ -160,6 +160,11 @@ Designing the agentic systems themselves — the loops, orchestrations, and budg
 
 | Skill | What it does |
 |---|---|
+| [`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. |
+| [`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. |
+| [`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. |
+| [`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. |
+| [`ai-usage-policy`](skills/ai-usage-policy/SKILL.md) | Draft the organisation-wide acceptable-use policy — **three** data tiers (five aren't memorable at the moment of pasting) with concrete examples from *this* org, permitted/prohibited uses stated as behaviours, and a human-review matrix keyed to **consequence** rather than to model names that age out in months. Every prohibition names a permitted alternative, because a ban with no sanctioned path moves the work to personal accounts where you can't see it — and there's always an exception route with a turnaround time. |
 | [`ai-usage-report`](skills/ai-usage-report/SKILL.md) | Turn a CSV/JSONL of AI usage events (exported from an MCP server or other telemetry source) into a per-user, team-rollup, or effectiveness-focused report. Surfaces volume, breadth, session depth, and — where the data supports it — whether AI outputs were actually consumed in shipped artifacts vs generated and discarded (the "AI theater" question). Refuses to generate an aggregate rollup for teams smaller than 5 to preserve anonymity. |
 | [`llm-eval-harness`](skills/llm-eval-harness/SKILL.md) | Design the **dev-loop quality gate** for an LLM-powered feature (prompt, RAG, agent, classifier) — so prompt and model changes ship on numbers, not vibes. A versioned golden set in three deliberate buckets (representative from real logs, adversarial/edge, and regression cases frozen from every past failure); the **cheapest adequate grading method per case** (programmatic → structured assertions → LLM-as-judge only when quality is genuinely subjective, and then validated against human labels with bias controls); a metric matched to the task with **both gates set before the first run** (no-regression + critical-subset-at-100%); a failure taxonomy that points iteration at the biggest bucket; and cost/latency tracked beside quality. Enforces the held-out split and the no-tuning-on-test rule. Provider-neutral. |
 

package/model-routing.json

@@ -114,6 +114,11 @@
     "slide-outliner": { "tier": "standard", "rationale": "Outlines a deck to a time budget. Structuring, not deep reasoning." },
     "sonar-review": { "tier": "standard", "rationale": "Formats Sonar API findings into a report. The hard analysis is Sonar's; this is synthesis. Escalate on very large diffs." },
     "ai-usage-report": { "tier": "standard", "rationale": "Tabulates telemetry into a report. Mostly mechanical, but the 'AI theater' effectiveness call needs judgment." },
+    "ai-readiness-assessment": { "tier": "standard", "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." },
+    "agent-adoption-stage": { "tier": "standard", "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." },
+    "ai-use-case-triage": { "tier": "standard", "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." },
+    "ai-adoption-rollout": { "tier": "standard", "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." },
+    "ai-usage-policy": { "tier": "standard", "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." },
     "feature-implement-loop": { "tier": "standard", "rationale": "Code + test generation against acceptance criteria. The adversarial pass delegates to devils-advocate (heavy) where available; the loop itself is generation." },
     "pre-merge-review": { "tier": "standard", "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." },
     "user-story-splitter": { "tier": "standard", "rationale": "Decomposes an epic into INVEST slices with testable ACs. Structured synthesis; escalation rules cover large or contradictory PRDs." },

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "skilldrop-cli",
-  "version": "0.9.1",
-  "description": "Portable AI-agent skills for the deliverables knowledge workers ship \u2014 diagrams, ADRs, PRDs, runbooks, decks, reviews \u2014 installable into Claude Code, Cursor, Kiro, and any IDE that takes custom instructions. One command per skill or per role-based pack.",
+  "version": "0.9.3",
+  "description": "Portable AI-agent skills for the deliverables knowledge workers ship — diagrams, ADRs, PRDs, runbooks, decks, reviews — installable into Claude Code, Cursor, Kiro, and any IDE that takes custom instructions. One command per skill or per role-based pack.",
   "author": {
     "name": "Sanjay Ananthanarayan",
     "url": "https://github.com/sananthanarayan"

package/packs.json

@@ -38,7 +38,8 @@
         "user-story-splitter",
         "success-metrics",
         "exec-summary",
-        "doc-critique"
+        "doc-critique",
+        "ai-use-case-triage"
       ]
     },
     "dev-team": {
@@ -83,7 +84,7 @@
       ]
     },
     "ai-engineering": {
-      "description": "Build and run AI systems: agent loop design, subagent orchestration, spend budgets, agent security review, eval harnesses, AI-usage reporting, and the data contracts AI pipelines depend on.",
+      "description": "Adopt and build AI systems: readiness assessment, use-case triage, rollout and acceptable-use policy, plus agent loop design, subagent orchestration, spend budgets, agent security review, eval harnesses, AI-usage reporting, and the data contracts AI pipelines depend on.",
       "skills": [
         "agent-loop-design",
         "subagent-design",
@@ -91,7 +92,12 @@
         "agent-threat-model",
         "llm-eval-harness",
         "ai-usage-report",
-        "data-contract"
+        "data-contract",
+        "ai-readiness-assessment",
+        "ai-use-case-triage",
+        "ai-adoption-rollout",
+        "ai-usage-policy",
+        "agent-adoption-stage"
       ]
     }
   }

package/skills/agent-adoption-stage/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: agent-adoption-stage
+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).
+---
+
+# agent-adoption-stage
+
+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.
+
+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.
+
+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.
+
+## The ladder
+
+| Stage | Shape | Observable | The bottleneck |
+|---|---|---|---|
+| **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 |
+| **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 |
+| **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 |
+| **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 |
+| **4 · Intent-steered** | steer by intent | **~1000+**, loop closed, monitor by exception | **finding and automating the work**, with the right guardrail per work type |
+
+## How to respond
+
+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.
+
+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.
+
+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.")
+
+4. **Prescribe exactly one unlock.** The next step, never a backlog of ten. The transitions:
+   - **0 → 1:** an approved path to run agents and land their output. Executive alignment, not tooling.
+   - **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.
+   - **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.
+   - **3 → 4:** scaled automation of domain-specific work (migrations, fuzzing, remediation) with per-work-type guardrails.
+
+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.
+
+6. **Route the unlock to something concrete.** Each unlock has an implementation:
+
+   | Unlock | Where it's implemented |
+   |---|---|
+   | a trusted self-verification loop | [`pre-merge-review`](../pre-merge-review/SKILL.md) — a mechanical gate whose exit code decides, plus the reviewer panel |
+   | automated review that isn't the queue | the reviewer panel (`devils-advocate`, `security-reviewer`, `code-quality`) |
+   | loops and routines | [`agent-loop-design`](../agent-loop-design/SKILL.md) — generate→verify→gate with exit criteria and a cap |
+   | parallel agents without collision | [`subagent-design`](../subagent-design/SKILL.md) — topology, isolation, typed contracts |
+   | token efficiency as volume climbs | [`agent-budget`](../agent-budget/SKILL.md) + a provider-neutral model tier per task |
+   | encoding standards so agents inherit them | [`agents-md-generator`](../agents-md-generator/SKILL.md) and skills themselves |
+   | guardrails for autonomous work | [`agent-threat-model`](../agent-threat-model/SKILL.md) |
+
+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."
+
+## Quality bar
+
+- **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.**
+
+## When to use this skill
+
+- ✅ "How far along are we with coding agents, really?"
+- ✅ Adoption plateaued and nobody can name why.
+- ✅ A leader wants to scale agent usage and needs to know whether the loop can carry it yet.
+- ✅ Re-measuring a quarter after a previous placement.
+
+## When NOT to use this skill
+
+- ❌ 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).
+- ❌ Planning how a tool reaches people — cohorts, enablement, comms — that's [`ai-adoption-rollout`](../ai-adoption-rollout/SKILL.md).
+- ❌ Choosing which use cases to build — that's [`ai-use-case-triage`](../ai-use-case-triage/SKILL.md).
+- ❌ Reporting measured usage from telemetry — that's [`ai-usage-report`](../ai-usage-report/SKILL.md).
+- ❌ Designing one specific loop or fleet — that's `agent-loop-design` / `subagent-design`, which this skill routes *to*.
+
+## Anti-patterns to avoid
+
+- ❌ **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.
+- ❌ **A stage claimed from ambition.** Licences bought, a mandate announced, or one enthusiastic staff engineer are not a stage. Median engineer, observable behaviour.
+- ❌ **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.
+- ❌ **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.
+- ❌ **Prescribing the whole ladder.** Handing someone stages 2, 3 and 4 at once guarantees stage 1 forever.
+- ❌ **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.
+
+**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.

package/skills/agent-adoption-stage/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "How far along are we with coding agents?",
+    "should_trigger": true
+  },
+  {
+    "query": "Our AI adoption has plateaued — what's the next unlock?",
+    "should_trigger": true
+  },
+  {
+    "query": "Which stage of agentic coding maturity is my team at?",
+    "should_trigger": true
+  },
+  {
+    "query": "We want engineers running more agents — are we ready to scale that?",
+    "should_trigger": true
+  },
+  {
+    "query": "Assess whether our organisation's data and governance are ready for AI",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan the rollout cohorts and enablement for this tool",
+    "should_trigger": false
+  },
+  {
+    "query": "Which AI use cases should we build first?",
+    "should_trigger": false
+  },
+  {
+    "query": "Design the subagent topology for this specific fleet",
+    "should_trigger": false
+  }
+]

package/skills/agent-adoption-stage/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "agent-adoption-stage",
+  "evals": [
+    {
+      "id": 1,
+      "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?",
+      "assertions": [
+        "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"
+      ]
+    }
+  ]
+}

package/skills/agent-adoption-stage/manifest.json

@@ -0,0 +1,39 @@
+{
+  "name": "agent-adoption-stage",
+  "version": "0.1.0",
+  "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).",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "agent-budget",
+    "agent-loop-design",
+    "agent-threat-model",
+    "agents-md-generator",
+    "ai-adoption-rollout",
+    "ai-readiness-assessment",
+    "ai-usage-report",
+    "ai-use-case-triage",
+    "devils-advocate",
+    "pre-merge-review",
+    "subagent-design"
+  ],
+  "tags": [
+    "ai-adoption",
+    "agentic-coding",
+    "maturity-ladder",
+    "orchestration",
+    "engineering-leadership",
+    "bottleneck"
+  ],
+  "model": {
+    "tier": "standard",
+    "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."
+  }
+}

package/skills/ai-adoption-rollout/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: ai-adoption-rollout
+description: Plan the human rollout of an AI tool or workflow to an organisation — sized cohorts, enablement per cohort, named champions, a comms plan that states what will not change, and an adoption gate every wave must pass before the next one opens. Use when a tool has been chosen and the question is how it reaches people without stalling or backlash. Do NOT use to phase a technical cutover (that's migration-plan) or to choose which use case to roll out (that's ai-use-case-triage).
+---
+
+# ai-adoption-rollout
+
+The tool is chosen; the risk now is **people**. This plans the human rollout: who gets it when, what they're taught, who they ask, what they're told, and the observable that must hold before the next cohort opens.
+
+Rollouts fail quietly. Licences get assigned, a launch email goes out, usage spikes for a week and decays, and nobody can say which step failed. Every wave here carries a gate so that decay is visible while it's still fixable.
+
+## How to respond
+
+1. **Restate what's being rolled out, to whom, and the adoption outcome.** Not "increase AI usage" — a behaviour: "support agents draft first responses with assistance on the top 3 categories". Usage is a proxy; the behaviour is the goal. Cap clarifying questions at 2.
+
+2. **Design cohorts, smallest first.** Default three waves — **pilot** (5–15 volunteers, highest tolerance) → **early** (one whole team or function, includes sceptics) → **general**. Each cohort names who is in it and *why they're next*: the pilot proves the workflow, the early wave proves it survives people who didn't ask for it. Skipping straight to general is the most common failure and this skill refuses it.
+
+3. **Specify enablement per cohort, not one training deck.** What each cohort must be able to *do* before they're counted as enabled — a 30-minute hands-on with their own real task beats an hour of slides. Name the format, the time cost, and who delivers it. Later cohorts get shorter enablement built from what the pilot actually got stuck on.
+
+4. **Name champions by role, with a time budget.** One per cohort, with hours protected. An unbudgeted champion is a volunteer who quietly stops answering. State what they own: first-line questions, collecting friction, running the office hour.
+
+5. **Write the comms plan — including what will not change.** Three messages: the announcement (what, why, what's in it for the reader), the reassurance (**explicitly: whether this affects headcount, evaluation, or how work is judged**), and the follow-up. Silence on the reassurance point is read as bad news and is the single biggest driver of quiet non-adoption.
+
+6. **Put an adoption gate on every wave.** Observable, with a threshold and a bake time, before the next cohort opens. ✅ "≥60% of the pilot used it on a real task in week 2, and no unresolved 🟥 issue in the friction log — hold 1 week." A gate that is "the pilot went well" is not a gate. Each wave also names its **rollback**: what happens if the gate fails — extend, narrow, or stop.
+
+7. **Name the friction loop.** Where friction is captured, who triages it weekly, and how a fix reaches the next cohort. A rollout with no feedback path teaches the organisation that complaints go nowhere.
+
+## Quality bar
+
+- **Cohorts get smaller-to-larger with a stated reason each**, and the plan refuses a single big-bang wave.
+- **Every wave has an adoption gate with an observable, a threshold, and a bake time** — plus a rollback if it fails.
+- **The outcome is a behaviour, not a usage number.** Licences activated is not adoption.
+- **The comms plan states explicitly what will not change** (headcount, evaluation, how work is judged). Omitting it is a defect, not a tone choice.
+- **Champions are roles with protected hours**, never names, and never unbudgeted.
+- **Enablement is per cohort and hands-on with the participant's own work** — a single deck for everyone is the failure mode.
+- **The friction loop names an owner and a cadence.**
+
+## When to use this skill
+
+- ✅ A tool or AI workflow is chosen and now has to reach real people.
+- ✅ A previous rollout decayed after launch and you're planning the retry.
+- ✅ Leadership wants a timeline with checkpoints rather than a launch date.
+
+## When NOT to use this skill
+
+- ❌ Phasing a *technical* cutover (schema, API version, datastore) — that's `migration-plan`, which sequences systems, not people.
+- ❌ Choosing which use case to roll out — that's [`ai-use-case-triage`](../ai-use-case-triage/SKILL.md).
+- ❌ Deciding whether the organisation is ready at all — that's [`ai-readiness-assessment`](../ai-readiness-assessment/SKILL.md).
+- ❌ Writing the rules for what may be put into the tool — that's [`ai-usage-policy`](../ai-usage-policy/SKILL.md).
+- ❌ Reporting on adoption that already happened — that's `ai-usage-report`.
+
+## Anti-patterns to avoid
+
+- ❌ **Big-bang rollout.** Everyone at once means no cohort to learn from and no way to stop. The gate structure exists to prevent exactly this.
+- ❌ **Counting licences as adoption.** Seats assigned, logins, "activated users" — all measure procurement, not behaviour change.
+- ❌ **A launch email as the comms plan.** One announcement with no reassurance and no follow-up is how a rollout gets read as a threat.
+- ❌ **Champions with no time.** Naming an enthusiastic person and adding nothing to their calendar is delegation of blame.
+- ❌ **Training everyone identically.** The pilot's stumbling blocks should shorten the next cohort's enablement; if the deck never changes, nobody was listening.
+- ❌ **A gate with no rollback.** "Proceed if it goes well" is not a decision rule — say what happens when it doesn't.
+
+**Non-interactive:** with no user to ask, derive cohorts from the stated org size and tag them `[assumption]`. If the input names no tool or workflow to roll out — only a wish to "drive AI adoption" — emit `BLOCKED: need the specific tool or workflow being rolled out and the population it reaches`.

package/skills/ai-adoption-rollout/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Plan how we roll this AI tool out to the org",
+    "should_trigger": true
+  },
+  {
+    "query": "How do we drive adoption without a backlash?",
+    "should_trigger": true
+  },
+  {
+    "query": "Design the cohorts and enablement for our AI launch",
+    "should_trigger": true
+  },
+  {
+    "query": "Our last AI rollout decayed after launch — plan the retry",
+    "should_trigger": true
+  },
+  {
+    "query": "Plan the phased migration of our database schema",
+    "should_trigger": false
+  },
+  {
+    "query": "Which use case should we roll out first?",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the rules for what people can put into these tools",
+    "should_trigger": false
+  },
+  {
+    "query": "Report on how much AI our team is using",
+    "should_trigger": false
+  }
+]

package/skills/ai-adoption-rollout/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "ai-adoption-rollout",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We've picked an AI assistant for our 300-person support org. Plan the rollout.",
+      "assertions": [
+        "Cohorts are sized smallest-first (pilot, early, general) with a stated reason each cohort is next",
+        "A single big-bang wave is explicitly refused",
+        "Every wave has an adoption gate with an observable, a threshold, and a bake time, plus a rollback if the gate fails",
+        "The adoption outcome is stated as a behaviour rather than a usage or licence number",
+        "The comms plan explicitly states what will not change regarding headcount, evaluation, or how work is judged",
+        "Champions are named as roles with protected hours",
+        "Enablement differs per cohort and is hands-on with the participant's own work",
+        "A friction loop names an owner and a cadence"
+      ]
+    }
+  ]
+}

package/skills/ai-adoption-rollout/manifest.json

@@ -0,0 +1,33 @@
+{
+  "name": "ai-adoption-rollout",
+  "version": "0.1.0",
+  "description": "Plan the human rollout of an AI tool or workflow to an organisation — sized cohorts, enablement per cohort, named champions, a comms plan that states what will not change, and an adoption gate every wave must pass before the next one opens. Use when a tool has been chosen and the question is how it reaches people without stalling or backlash. Do NOT use to phase a technical cutover (that's migration-plan) or to choose which use case to roll out (that's ai-use-case-triage).",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "ai-readiness-assessment",
+    "ai-usage-policy",
+    "ai-usage-report",
+    "ai-use-case-triage",
+    "migration-plan"
+  ],
+  "tags": [
+    "ai-adoption",
+    "rollout",
+    "change-management",
+    "enablement",
+    "cohorts",
+    "comms"
+  ],
+  "model": {
+    "tier": "standard",
+    "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."
+  }
+}

package/skills/ai-readiness-assessment/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: ai-readiness-assessment
+description: Score an organisation's or team's readiness to adopt AI tooling across six gating dimensions — data, tooling, skills, governance, process, and culture — with an evidence line per score and the blocking gaps ranked by what stops adoption first. Use when the user asks "are we ready for AI", wants an AI maturity or readiness baseline, or needs to know what to fix before rolling tools out. Do NOT use to pick which use cases to build (that's ai-use-case-triage) or to plan the rollout itself (that's ai-adoption-rollout).
+---
+
+# ai-readiness-assessment
+
+Produce a **baseline a leadership team can act on**: where the organisation actually stands on the six things that gate AI adoption, what the evidence is for each score, and which gaps block adoption *first*. The output is a scored table plus a ranked gap list — not a maturity label and not a slide.
+
+Readiness assessments fail in one of two ways: a number with no evidence behind it, or a diagnosis with no next action. This skill refuses both.
+
+## How to respond
+
+1. **Establish scope and the decision it feeds.** Whose readiness — one team, a function, the whole company? And what happens with the answer (a go/no-go, a budget request, a sequencing decision)? Scope changes what counts as evidence. Cap clarifying questions at 2.
+
+2. **Score the six dimensions.** These are fixed — do not invent new ones for a single engagement, and do not drop one because it's awkward to assess. Score each **0–4** (0 absent · 1 ad hoc · 2 repeatable · 3 managed · 4 optimised):
+
+   | Dimension | The question it answers |
+   |---|---|
+   | **Data** | Is the material these tools need reachable, current, and permitted to be used? |
+   | **Tooling** | Are licences, access, and environments actually in people's hands? |
+   | **Skills** | Can people write a decent prompt, judge an output, and know when not to trust it? |
+   | **Governance** | Is there a rule for what may be put in, and a named owner for it? |
+   | **Process** | Does the workflow have a place for a machine draft plus a human review gate? |
+   | **Culture** | Is the incentive to use it, or to hide that it was used? |
+
+3. **Attach evidence to every score.** One line naming what you observed — a system, a document, a stated practice, a number. A score with no evidence line is deleted, not softened. Where the input doesn't support a score, emit `[insufficient evidence: <what to collect>]` rather than guessing a middle number.
+
+4. **Rank the gaps by what blocks first, not by what scores lowest.** A 1 in Governance that blocks every use case outranks a 0 in Culture that blocks nothing yet. Name the dependency: "Skills cannot move until Tooling ≥ 2 — people can't practise on access they don't have."
+
+5. **Give each gap a first action and an owner role.** Concrete and small enough to start this quarter. ❌ "Improve data governance." ✅ "Name a data owner for the three systems in scope and publish an allowed-use tier for each — legal + platform lead, 2 weeks."
+
+6. **State the overall posture in one sentence, and what would change it.** ✅ "Ready for a bounded pilot in engineering; not ready for company-wide rollout until Governance reaches 2." Never a bare maturity label.
+
+## Quality bar
+
+- **Every score carries an evidence line.** A number with nothing behind it is the failure mode this skill exists to prevent — cut it or mark it `[insufficient evidence]`.
+- **All six dimensions appear**, including the ones the input is thin on. Silence on a dimension reads as a pass, and that's how readiness reports mislead.
+- **Gaps are ranked by blocking order, not by score.** The lowest number is not automatically the first problem, and the plan must say why.
+- **Every gap has a first action and an owner role** — a role, never a person's name, so the assessment doesn't go stale when someone changes teams.
+- **The posture sentence takes a position** and names the condition that would change it. "It depends" is a refusal to do the job.
+- **No invented facts.** Where the input is silent, say so; a fabricated observation is worse than an admitted gap.
+
+## When to use this skill
+
+- ✅ "Are we ready to roll out AI tooling?" — before committing budget or a timeline.
+- ✅ Establishing a baseline to re-measure against in two quarters.
+- ✅ A leadership team disagrees about whether the blocker is tools, skills, or policy.
+
+## When NOT to use this skill
+
+- ❌ Choosing *which* workflows to automate — that's [`ai-use-case-triage`](../ai-use-case-triage/SKILL.md).
+- ❌ Planning the rollout once you've decided to go — that's [`ai-adoption-rollout`](../ai-adoption-rollout/SKILL.md).
+- ❌ Writing the rules for what people may put into a tool — that's [`ai-usage-policy`](../ai-usage-policy/SKILL.md).
+- ❌ A market or competitive question ("should we enter this space?") — that's `strategy-analysis`.
+- ❌ Measuring adoption that has already happened — that's `ai-usage-report`.
+- ❌ **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.
+
+## Anti-patterns to avoid
+
+- ❌ **A maturity label as the deliverable.** "You are Level 2 of 5" tells a leader nothing they can fund. The ranked gap list is the product; the score is just its index.
+- ❌ **Scoring what's easy to score.** Tooling is countable, Culture is not — and a report that goes deep on licences and hand-waves incentives has measured the wrong thing.
+- ❌ **Middle scores as a hedge.** A 2 everywhere means the assessment refused to commit. If the evidence is thin, say `[insufficient evidence]` and name what to collect.
+- ❌ **Gaps with no owner.** An unowned action is a wish. Roles, not names.
+- ❌ **Recommending tools.** This assesses readiness; vendor selection is a different decision (`tech-comparison-matrix`) and mixing them lets a vendor pitch masquerade as a diagnosis.
+
+**Non-interactive:** with no user to ask, derive the scope from the input and tag it `[assumption]`. If the input contains no observable evidence for any dimension — a request with no organisational context — emit `BLOCKED: need observable context (systems, current practice, or stated policy) for at least three dimensions` rather than scoring from imagination.

package/skills/ai-readiness-assessment/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Are we ready to adopt AI?",
+    "should_trigger": true
+  },
+  {
+    "query": "Assess our AI maturity and tell me what's blocking us",
+    "should_trigger": true
+  },
+  {
+    "query": "Give me an AI readiness baseline for our engineering org",
+    "should_trigger": true
+  },
+  {
+    "query": "What do we need to fix before rolling out AI tools?",
+    "should_trigger": true
+  },
+  {
+    "query": "Which AI use cases should we build first?",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan how we roll this tool out to 200 people",
+    "should_trigger": false
+  },
+  {
+    "query": "Write our AI acceptable-use policy",
+    "should_trigger": false
+  },
+  {
+    "query": "Run a SWOT on our market position",
+    "should_trigger": false
+  }
+]

package/skills/ai-readiness-assessment/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "ai-readiness-assessment",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're a 200-person fintech. Engineering has Copilot licences that about a third of people use, we have no written AI policy, our docs are spread across Confluence and Notion, and leadership keeps asking when we'll 'be an AI company'. Are we ready?",
+      "assertions": [
+        "All six dimensions (data, tooling, skills, governance, process, culture) are scored 0-4 — none is omitted",
+        "Every score carries a one-line evidence reference drawn from the input, or is marked [insufficient evidence: <what to collect>]",
+        "Gaps are ranked by what blocks adoption first, with the dependency named — not simply sorted by lowest score",
+        "Every gap has a concrete first action and an owner expressed as a role, not a person's name",
+        "The posture sentence takes a position and names the condition that would change it",
+        "No facts are invented beyond what the prompt supplies"
+      ]
+    }
+  ]
+}

package/skills/ai-readiness-assessment/manifest.json

@@ -0,0 +1,35 @@
+{
+  "name": "ai-readiness-assessment",
+  "version": "0.1.0",
+  "description": "Score an organisation's or team's readiness to adopt AI tooling across six gating dimensions — data, tooling, skills, governance, process, and culture — with an evidence line per score and the blocking gaps ranked by what stops adoption first. Use when the user asks \"are we ready for AI\", wants an AI maturity or readiness baseline, or needs to know what to fix before rolling tools out. Do NOT use to pick which use cases to build (that's ai-use-case-triage) or to plan the rollout itself (that's ai-adoption-rollout).",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "agent-adoption-stage",
+    "ai-adoption-rollout",
+    "ai-usage-policy",
+    "ai-usage-report",
+    "ai-use-case-triage",
+    "strategy-analysis",
+    "tech-comparison-matrix"
+  ],
+  "tags": [
+    "ai-adoption",
+    "readiness",
+    "maturity-assessment",
+    "governance",
+    "change-management",
+    "baseline"
+  ],
+  "model": {
+    "tier": "standard",
+    "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."
+  }
+}

package/skills/ai-usage-policy/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: ai-usage-policy
+description: Draft an organisation's AI acceptable-use policy — three data-sensitivity tiers with what may be put into a tool at each, permitted and prohibited uses stated as behaviours, a human-review matrix keyed to consequence, an approved-tool list with an exception route, and a named owner per rule. Use when a team needs rules for what people may put into AI tools, or asks for an AI acceptable-use or governance policy. Do NOT use to write a repo's agent-tooling policy (that's agents-md-generator) or to analyse one agent's capability surface (that's agent-threat-model).
+---
+
+# ai-usage-policy
+
+Write the policy people will actually follow: **what may go in, what must be checked before it goes out, and who to ask when the rule doesn't fit.** The audience is every employee, not the security team — so it reads as rules for a job, not controls for an auditor.
+
+A policy that prohibits without offering a permitted path doesn't reduce risk; it moves the same work onto personal accounts where nobody can see it. Every prohibition here carries an alternative.
+
+## How to respond
+
+1. **Establish scope and the regulatory floor.** Which population, which tools, and any regime already binding (sector rules, customer contracts, an existing data-classification scheme). If the organisation already classifies data, **reuse those tier names** rather than inventing a parallel scheme — two classification systems means neither is followed. Cap clarifying questions at 2.
+
+2. **Define three data tiers and what may enter a tool at each.** Three, because five is not memorable and one is not a policy:
+
+   | Tier | Examples | Rule |
+   |---|---|---|
+   | **Open** | public docs, published marketing, open-source code | any approved tool |
+   | **Internal** | internal docs, non-personal telemetry, private repo code | approved tools with data-retention off / enterprise terms |
+   | **Restricted** | personal data, credentials, customer content under contract, regulated records | never pasted; only via a named reviewed integration, if at all |
+
+   Give each tier **two concrete examples from this organisation's actual work** — abstract tiers are the reason policies get ignored.
+
+3. **State permitted and prohibited uses as behaviours.** ✅ "Drafting a first version of a customer email, then editing before sending." ❌ "Inappropriate use." Every prohibition names the **permitted alternative**: "Do not paste customer records to summarise them — use the approved integration, which does the same thing without the data leaving."
+
+4. **Build the human-review matrix on consequence, not on technology.** What must a human check before an AI-assisted output is acted on? Key it to blast radius: reaches a customer · commits money or a legal position · changes production · informs a personnel decision. Each row says who reviews and what "reviewed" means. Low-consequence internal drafting needs no gate — say so, or the policy loses credibility everywhere else.
+
+5. **List approved tools, and give an exception route.** Named tools with the tier they're cleared to. Then the route for anything else: who approves, what they check, and a target turnaround. **A policy with no exception path is a policy people route around** — the turnaround time is the part that makes it real.
+
+6. **Name an owner per section, a review date, and the disclosure rule.** Owners as roles. A review date, because tool terms change. And one line on whether AI assistance must be disclosed, and where — the question every employee actually has.
+
+## Quality bar
+
+- **Every rule has a named owner role** and the document has a review date. An unowned policy is a document, not a control.
+- **Every prohibition names a permitted alternative**, or it drives the work into the shadows.
+- **Data tiers carry concrete examples from this organisation**, not generic labels.
+- **The review matrix is keyed to consequence, not to tool or model.** Model names age out in months; consequences don't.
+- **There is an exception route with a turnaround time.**
+- **Written for the whole staff.** If a non-technical reader hits an unexplained term, rewrite it — the audience is everyone, and unread rules govern nothing.
+- **No invented regulation.** Cite only regimes the user named; where applicability is unclear, mark `[confirm with counsel]` rather than asserting a legal position.
+
+## When to use this skill
+
+- ✅ "What are people allowed to put into these tools?" — the question every rollout hits in week one.
+- ✅ Standing up governance before or alongside an AI rollout.
+- ✅ Replacing an informal "be sensible" norm with something reviewable.
+
+## When NOT to use this skill
+
+- ❌ Writing a repository's agent-tooling policy (`AGENTS.md` — build commands, conventions, what agents may edit) — that's `agents-md-generator`.
+- ❌ Threat-modelling one agent's data reach and exfiltration paths — that's `agent-threat-model`.
+- ❌ Planning how the tool reaches people — that's [`ai-adoption-rollout`](../ai-adoption-rollout/SKILL.md).
+- ❌ Assessing whether governance is mature enough yet — that's [`ai-readiness-assessment`](../ai-readiness-assessment/SKILL.md).
+- ❌ A security review of a design — that's `threat-model`.
+
+## Anti-patterns to avoid
+
+- ❌ **Prohibition without an alternative.** "Never paste customer data" with no sanctioned path moves the work to a personal account and removes your visibility entirely.
+- ❌ **Naming models and versions in the rules.** They change quarterly; consequence-based rules survive. Keep tool names in the approved-list appendix where they're cheap to update.
+- ❌ **Five or more tiers.** Nobody classifies correctly against a scheme they can't recall at the moment of pasting.
+- ❌ **Writing for auditors.** A policy in control language gets filed, not followed. Plain rules for a working day.
+- ❌ **No exception route.** Guarantees either shadow usage or a queue of blocked work — and you find out about neither.
+- ❌ **Requiring review of everything.** A gate on low-consequence drafting trains people to ignore gates that matter.
+
+**Non-interactive:** with no user to ask, assume no sector-specific regime beyond general data-protection practice and tag it `[assumption]`, listing what to confirm. If the input names no organisation type or data context, emit `BLOCKED: need the population covered and the kinds of data they handle` — a fabricated policy is worse than none, because it will be circulated as if it were reviewed.

package/skills/ai-usage-policy/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write our AI acceptable-use policy",
+    "should_trigger": true
+  },
+  {
+    "query": "What are people allowed to put into these AI tools?",
+    "should_trigger": true
+  },
+  {
+    "query": "We need AI governance rules before we roll this out",
+    "should_trigger": true
+  },
+  {
+    "query": "Draft data-handling tiers for AI tool usage",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate the AGENTS.md for this repository",
+    "should_trigger": false
+  },
+  {
+    "query": "Threat model our agent's data access and exfiltration paths",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan the rollout cohorts and enablement",
+    "should_trigger": false
+  },
+  {
+    "query": "Assess whether our governance is mature enough",
+    "should_trigger": false
+  }
+]

package/skills/ai-usage-policy/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "ai-usage-policy",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write an AI acceptable-use policy for our 500-person company. We handle customer support data including names and order history, and people are already pasting things into chatbots.",
+      "assertions": [
+        "Exactly three data tiers are defined, each with concrete examples drawn from the organisation described",
+        "Permitted and prohibited uses are stated as behaviours, not abstractions like 'inappropriate use'",
+        "Every prohibition names a permitted alternative path for the same work",
+        "The human-review matrix is keyed to consequence (customer-facing, financial, production, personnel) rather than to tool or model names",
+        "An approved-tool list is accompanied by an exception route with an approver and a turnaround time",
+        "Every section names an owner role and the document carries a review date",
+        "The disclosure rule states whether and where AI assistance must be declared",
+        "No regulation is asserted beyond what the prompt names; unclear applicability is marked [confirm with counsel]"
+      ]
+    }
+  ]
+}

package/skills/ai-usage-policy/manifest.json

@@ -0,0 +1,33 @@
+{
+  "name": "ai-usage-policy",
+  "version": "0.1.0",
+  "description": "Draft an organisation's AI acceptable-use policy — three data-sensitivity tiers with what may be put into a tool at each, permitted and prohibited uses stated as behaviours, a human-review matrix keyed to consequence, an approved-tool list with an exception route, and a named owner per rule. Use when a team needs rules for what people may put into AI tools, or asks for an AI acceptable-use or governance policy. Do NOT use to write a repo's agent-tooling policy (that's agents-md-generator) or to analyse one agent's capability surface (that's agent-threat-model).",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "agent-threat-model",
+    "agents-md-generator",
+    "ai-adoption-rollout",
+    "ai-readiness-assessment",
+    "threat-model"
+  ],
+  "tags": [
+    "ai-adoption",
+    "governance",
+    "acceptable-use",
+    "policy",
+    "data-classification",
+    "compliance"
+  ],
+  "model": {
+    "tier": "standard",
+    "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."
+  }
+}

package/skills/ai-use-case-triage/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: ai-use-case-triage
+description: Turn a pile of candidate AI use cases into a ranked portfolio — each scored on value, feasibility, and risk with the weights shown, a recommended first slice that can prove or kill the thesis, and an explicit not-yet list with the condition that would promote each entry. Use when a team has more AI ideas than capacity and needs to choose, or asks "where should we actually start with AI". Do NOT use to assess whether the organisation is ready at all (that's ai-readiness-assessment) or to price a single decision (that's business-case).
+---
+
+# ai-use-case-triage
+
+Most AI adoption stalls not from lack of ideas but from too many, all sounding equally promising. This produces a **ranked portfolio with rejections**: what to do first, what to hold, and the condition that would move a held item onto the list.
+
+A triage that promotes everything has triaged nothing. The not-yet list is the deliverable's spine.
+
+## How to respond
+
+1. **Inventory the candidates.** From whatever the user brought — a brainstorm, a backlog, interview notes. Each candidate is stated as **a workflow and a person**, not a technology: ✅ "Support agents drafting first-response replies" — ❌ "Use LLMs in support." If a candidate is a technology looking for a job, say so and either recast it or drop it.
+
+2. **Score each on three axes, 1–5, and show the weights.** Default weights: **value 40 · feasibility 35 · risk 25**. State them, and restate them if the user's context justifies different ones (a regulated environment legitimately weights risk higher). Hidden weights make a ranking an opinion.
+   - **Value** — time recovered, quality lifted, or revenue/cost moved. Quantify where the input allows; mark `directional` where it doesn't. Never invent a number.
+   - **Feasibility** — is the input data reachable, is the output checkable, does the workflow already have a review step? A task whose output nobody can verify is not feasible, however easy the prompt.
+   - **Risk** — blast radius if the output is wrong and someone acts on it. Score the *consequence*, not the technology's reputation.
+
+3. **Rank, then sanity-check the top.** The highest score wins only if its **failure is survivable and visible**. A high-value, high-risk item where a wrong answer reaches a customer unreviewed is not a first slice, whatever the arithmetic says — demote it and say why.
+
+4. **Name the first slice, and what it proves.** One use case, with the observable that would confirm or kill the thesis and a time box. ✅ "Draft first-response replies for the top 3 ticket categories; the thesis dies if agents edit more than half the draft body after 4 weeks." A first slice with no kill condition is a pilot that runs forever.
+
+5. **Write the not-yet list with promotion conditions.** Every rejected candidate gets one line saying what would change the answer — "when the knowledge base is deduplicated", "when a human review step exists in the workflow". A rejection with no condition reads as a permanent no and gets re-litigated next quarter.
+
+6. **Hand off.** The first slice's economics → `business-case`; how success will be measured → `success-metrics`; how it reaches people → [`ai-adoption-rollout`](../ai-adoption-rollout/SKILL.md); whether the output can be evaluated at all → `llm-eval-harness`.
+
+## Quality bar
+
+- **The weights are shown and justified in one line.** A ranking with hidden weights is an opinion wearing a table.
+- **Every score has a one-line reason.** A bare 4 is not a judgement anyone can challenge.
+- **The not-yet list is non-empty**, and every entry carries a promotion condition. If nothing was rejected, the triage didn't happen.
+- **Each candidate names a workflow and a person**, not a technology.
+- **The first slice has a kill condition** with an observable and a time box.
+- **Unknown numbers are marked `directional`**, never invented — a fabricated ROI figure poisons every decision downstream.
+
+## When to use this skill
+
+- ✅ More AI ideas than capacity, and the team needs a defensible order.
+- ✅ "Where should we start with AI?" from a leader who has heard a dozen pitches.
+- ✅ Re-triaging a stalled portfolio where three pilots are half-running.
+
+## When NOT to use this skill
+
+- ❌ Assessing whether the organisation can adopt anything yet — that's [`ai-readiness-assessment`](../ai-readiness-assessment/SKILL.md).
+- ❌ Pricing one option properly (build vs buy, Option 0, cost layers) — that's `business-case`.
+- ❌ Planning the human rollout of a chosen use case — that's [`ai-adoption-rollout`](../ai-adoption-rollout/SKILL.md).
+- ❌ Writing requirements for the thing you picked — that's `prd-draft`.
+
+## Anti-patterns to avoid
+
+- ❌ **A portfolio with no rejections.** Ranking ten ideas 1–10 and calling it a roadmap is capacity denial, not triage.
+- ❌ **Scoring the technology instead of the workflow.** "RAG: 5/5" is not a use case. The unit is a person doing a job.
+- ❌ **Invented value numbers.** A confident "$400k/yr saved" with no source is the single fastest way to lose a room that includes a finance lead.
+- ❌ **Ignoring verifiability.** Feasibility is not "can a model produce this?" — it is "can someone tell whether it's right, before it matters?"
+- ❌ **A first slice that can't fail.** If no observable would kill it, it isn't a pilot; it's a commitment with a pilot's label.
+
+**Non-interactive:** with no user to ask, use the default weights and tag them `[assumption]`. If the input contains no candidate use cases — only a general request to "use AI" — emit `BLOCKED: need at least three candidate workflows to triage` rather than inventing a portfolio.

package/skills/ai-use-case-triage/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Which AI use cases should we do first?",
+    "should_trigger": true
+  },
+  {
+    "query": "Rank these AI ideas by value and feasibility",
+    "should_trigger": true
+  },
+  {
+    "query": "We have more AI ideas than capacity — help us choose",
+    "should_trigger": true
+  },
+  {
+    "query": "Where should we actually start with AI?",
+    "should_trigger": true
+  },
+  {
+    "query": "Are we ready to adopt AI at all?",
+    "should_trigger": false
+  },
+  {
+    "query": "Build the business case for this one investment",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the PRD for the feature we picked",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan the rollout to our support team",
+    "should_trigger": false
+  }
+]

package/skills/ai-use-case-triage/evals/evals.json

@@ -0,0 +1,18 @@
+{
+  "skill_name": "ai-use-case-triage",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Our support org has five AI ideas: draft first replies, auto-tag tickets, summarise call recordings, generate KB articles, and predict churn from ticket sentiment. Where do we start?",
+      "assertions": [
+        "Each candidate is restated as a workflow and a person, not a technology",
+        "Every candidate is scored on value, feasibility, and risk with the weights shown and justified",
+        "Every score carries a one-line reason",
+        "The not-yet list is non-empty and each entry names the condition that would promote it",
+        "The recommended first slice names an observable kill condition and a time box",
+        "Feasibility reasoning addresses whether the output can be verified before it matters",
+        "Value figures absent from the input are marked directional rather than invented"
+      ]
+    }
+  ]
+}

package/skills/ai-use-case-triage/manifest.json

@@ -0,0 +1,34 @@
+{
+  "name": "ai-use-case-triage",
+  "version": "0.1.0",
+  "description": "Turn a pile of candidate AI use cases into a ranked portfolio — each scored on value, feasibility, and risk with the weights shown, a recommended first slice that can prove or kill the thesis, and an explicit not-yet list with the condition that would promote each entry. Use when a team has more AI ideas than capacity and needs to choose, or asks \"where should we actually start with AI\". Do NOT use to assess whether the organisation is ready at all (that's ai-readiness-assessment) or to price a single decision (that's business-case).",
+  "entrypoint": "SKILL.md",
+  "deps": {
+    "npm": [],
+    "pip": []
+  },
+  "env": {
+    "required": [],
+    "optional": []
+  },
+  "related": [
+    "ai-adoption-rollout",
+    "ai-readiness-assessment",
+    "business-case",
+    "llm-eval-harness",
+    "prd-draft",
+    "success-metrics"
+  ],
+  "tags": [
+    "ai-adoption",
+    "prioritization",
+    "use-cases",
+    "portfolio",
+    "value-vs-feasibility",
+    "pilot"
+  ],
+  "model": {
+    "tier": "standard",
+    "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."
+  }
+}

package/skills/bug-triage/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Turn this vague bug report into an actionable ticket",
+    "should_trigger": true
+  },
+  {
+    "query": "A customer says it's broken on mobile sometimes — triage it",
+    "should_trigger": true
+  },
+  {
+    "query": "Write up this Slack complaint as a proper bug with repro steps",
+    "should_trigger": true
+  },
+  {
+    "query": "Triage and prioritize this support ticket",
+    "should_trigger": true
+  },
+  {
+    "query": "Review this diff for bugs and edge cases",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the blameless postmortem for the outage",
+    "should_trigger": false
+  },
+  {
+    "query": "Split this epic into user stories",
+    "should_trigger": false
+  },
+  {
+    "query": "Write a test plan for this release",
+    "should_trigger": false
+  }
+]

package/skills/bug-triage/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "bug-triage",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Triage this report: 'checkout is broken on mobile sometimes, a customer complained in Slack this morning'.",
+      "assertions": [
+        "An engineer could start work without contacting the reporter — either the repro steps stand alone, or a no-repro diagnostics list states exactly what to collect",
+        "The title is findable by symptom search, containing the words a future reporter would type",
+        "Repro steps are numbered and start from a clean state",
+        "Expected versus actual behaviour are stated separately",
+        "Every factual claim is tagged [reported], [verified], or [assumption] — nothing is asserted untagged",
+        "Severity is assigned with a stated reason rather than inherited from the reporter's tone"
+      ]
+    }
+  ]
+}

package/skills/migration-plan/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Plan the migration for this schema change",
+    "should_trigger": true
+  },
+  {
+    "query": "How do we roll this datastore swap out safely with no downtime?",
+    "should_trigger": true
+  },
+  {
+    "query": "Give me a phased expand-migrate-contract plan for this API version",
+    "should_trigger": true
+  },
+  {
+    "query": "We're switching auth providers — plan the cutover and rollback",
+    "should_trigger": true
+  },
+  {
+    "query": "Design the new database schema and its indexes",
+    "should_trigger": false
+  },
+  {
+    "query": "Split this migration work into user stories",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the runbook for the on-call team",
+    "should_trigger": false
+  },
+  {
+    "query": "Write an ADR recording why we chose this datastore",
+    "should_trigger": false
+  }
+]

package/skills/migration-plan/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "migration-plan",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Plan the migration from our single-tenant Postgres schema to a multi-tenant one, with no downtime.",
+      "assertions": [
+        "The plan is phased expand-migrate-contract by default",
+        "Every phase is reversible, or is explicitly named as the point of no return — a reader can answer 'how do we get back from here?' for every phase",
+        "Every gate is observable with a bake time and a threshold, not 'looks good'",
+        "Each phase carries exactly one change, so a failed phase implicates one thing",
+        "Rollback steps are stated per phase rather than as a single end-of-plan afterthought"
+      ]
+    }
+  ]
+}

package/skills/test-plan-generator/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write a test plan for this feature",
+    "should_trigger": true
+  },
+  {
+    "query": "What should we test before this release, ranked by risk?",
+    "should_trigger": true
+  },
+  {
+    "query": "Map these acceptance criteria to test cases",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate a risk-based QA plan for this PR",
+    "should_trigger": true
+  },
+  {
+    "query": "Split this epic into user stories with acceptance criteria",
+    "should_trigger": false
+  },
+  {
+    "query": "Review my code and tell me which tests are missing",
+    "should_trigger": false
+  },
+  {
+    "query": "Run the Sonar scan on my branch",
+    "should_trigger": false
+  },
+  {
+    "query": "Draft the PRD for this feature",
+    "should_trigger": false
+  }
+]

package/skills/test-plan-generator/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "test-plan-generator",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write the test plan for this release — a new discount-code feature touching checkout, pricing, and the orders API.",
+      "assertions": [
+        "A risk table ranked by likelihood times impact precedes the test cases, and depth of coverage tracks that ranking rather than being uniform",
+        "Every test case states a concrete expected result — a specific status code, error code, or value, not 'an appropriate error is shown'",
+        "Every acceptance criterion appears in a coverage table, with uncovered ACs listed explicitly rather than omitted",
+        "Each test is pushed to the lowest pyramid level that would catch the failure",
+        "Out-of-scope areas are named rather than silently skipped"
+      ]
+    }
+  ]
+}

package/skills/user-story-splitter/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Split this epic into user stories",
+    "should_trigger": true
+  },
+  {
+    "query": "Break this feature down into independently shippable slices",
+    "should_trigger": true
+  },
+  {
+    "query": "Turn this PRD section into stories with Gherkin acceptance criteria",
+    "should_trigger": true
+  },
+  {
+    "query": "What's the right build order for these stories?",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the product requirements document for this feature",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the test plan covering these acceptance criteria",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan the phased rollout of this schema change",
+    "should_trigger": false
+  },
+  {
+    "query": "Turn this bug report into an actionable ticket",
+    "should_trigger": false
+  }
+]

package/skills/user-story-splitter/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "user-story-splitter",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Split this epic into shippable stories: 'Customers can save their cart, return later on any device, and check out with a saved payment method.'",
+      "assertions": [
+        "Every story is demoable to a non-engineer — a story whose demo is 'look at this database table' is re-cut as a vertical slice",
+        "Every acceptance criterion is pass/fail without interpretation and written in Gherkin",
+        "Acceptance criteria are concrete enough that a tester who has not seen the epic can verdict them",
+        "Dependencies between stories are stated, and a recommended build order follows from them",
+        "Stories are independently shippable rather than layered horizontally (all backend, then all frontend)"
+      ]
+    }
+  ]
+}