skilldrop

npm license

Browse the catalogue → — all 56 skills, filterable by pack, tag, and model tier.

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:

npx skilldrop-cli install --pack product-manager     # or: solution-architect, dev-team,
npx skilldrop-cli list                               #     sre-oncall, stakeholder-comms, ai-engineering

Originally scoped to solution architects, now broadly useful to PMs, founders, consultants, engineering leaders, exec assistants — anyone who turns ideas into stakeholder-ready artifacts.

Every skill is a plain SKILL.md folder — the Agent Skills open standard 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.

Why skilldrop over heavier agent platforms: every skill is a plain folder (SKILL.md + manifest.json + supporting files) and installs by copy, never transformation — what runs in your IDE is byte-identical to what's reviewed in this repo. The flat layout doubles as an open catalog contract: any repo shaped like this one is installable through the same CLI. Skills are opinionated — each ships a quality bar, anti-patterns, and acceptance evals, so the output is an artifact, not a vibe.

How skilldrop works

skilldrop runs two value streams, and nothing comes out of either until it passes a review gate. Both diagrams render on GitHub; the Mermaid sources live in docs/ for easy re-rendering.

Knowledge-work pipeline

Raw input becomes a stakeholder-ready artifact — and loops back through review until it's approved.

%%{init: {'theme':'base','themeVariables':{'fontFamily':'Segoe UI, Helvetica, Arial','fontSize':'15px','lineColor':'#9AA5B1'},'flowchart':{'curve':'basis','rankSpacing':70,'nodeSpacing':50,'padding':16}}}%%
flowchart LR
    classDef input  fill:#FFF4E0,stroke:#E8A93B,stroke-width:2px,color:#7A4E00,font-weight:bold;
    classDef gen    fill:#E8F0FE,stroke:#4C7DF0,stroke-width:1.5px,color:#1A3A8F;
    classDef review fill:#FDEAEA,stroke:#E05B5B,stroke-width:1.5px,color:#8A1F1F;
    classDef ship   fill:#E6F7EC,stroke:#34A853,stroke-width:2px,color:#0F6B33,font-weight:bold;

    IN(["Raw input<br/>notes · ticket · transcript"]):::input
    brief["Structure the brief"]:::gen
    gens["Draft the artifact"]:::gen
    crit["Review and refine"]:::review
    ART(["Stakeholder-ready<br/>artifact"]):::ship

    IN --> brief --> gens --> crit
    crit -- "revise" --> brief
    crit == "approved" ==> ART

Code: implement and verify

A feature spec becomes shippable code through a self-correcting loop — generate, adversarially challenge, close the gaps, re-check — until the review is clean or a 3-round cap is hit. This is the feature-implement-loop skill.

%%{init: {'theme':'base','themeVariables':{'fontFamily':'Segoe UI, Helvetica, Arial','fontSize':'15px','lineColor':'#9AA5B1'},'flowchart':{'curve':'basis','rankSpacing':70,'nodeSpacing':50,'padding':16}}}%%
flowchart LR
    classDef input  fill:#FFF4E0,stroke:#E8A93B,stroke-width:2px,color:#7A4E00,font-weight:bold;
    classDef gen    fill:#E8F0FE,stroke:#4C7DF0,stroke-width:1.5px,color:#1A3A8F;
    classDef review fill:#FDEAEA,stroke:#E05B5B,stroke-width:1.5px,color:#8A1F1F;
    classDef gate   fill:#FBE3A2,stroke:#D9971E,stroke-width:2px,color:#6B4500,font-weight:bold;
    classDef ship   fill:#E6F7EC,stroke:#34A853,stroke-width:2px,color:#0F6B33,font-weight:bold;

    IN(["Feature / story<br/>description + acceptance criteria"]):::input
    gC["Write and update<br/>code and tests"]:::gen
    revC["Challenge the code"]:::review
    gate{"Gaps found?"}:::gate
    SHIP(["Feature ready<br/>to be shipped"]):::ship

    IN --> gC --> revC --> gate
    gate -- "yes (up to 3 rounds)" --> gC
    gate == "no" ==> SHIP

Skills in this repo

Pipeline glue

Skill What it does
brief-intake Upstream collector. Takes raw mess — a Slack thread, meeting transcript, ticket, email chain, paragraph of notes — and emits a structured brief shaped for whichever downstream skill comes next (ADR, design doc, runbook, exec summary, deck, comparison matrix, decision log). Every field is tagged [explicit] / [implied] / [inferred] / [missing] with verbatim quotes from the source.
doc-critique Counterpart reviewer. Takes an existing doc (ADR, design doc, runbook, exec summary, comparison matrix, deck, decision log) and produces a structured critique against the same rubrics the generators enforce — verdict + severity-tagged findings (blocker / major / minor / nit) with quoted evidence and concrete fixes, plus a "what's working" section.

Planning & delivery

Skills for the SDLC steps around the code itself — turning raw requirements into shippable, testable units of work and tracking them to release. (feature-implement-loop under Dev workflow is the natural downstream of these.)

Skill What it does
capacity-cost-model Build a capacity and cost model for a service or feature — sized from a demand driver and its growth curve, never from a chosen instance count. Everything expressed as unit economics (cost per request / tenant / GB, so it projects and optimizes); peak-vs-average and headroom written as explicit money-vs-incident decisions; cost at 1×/3×/10× with the scaling cliffs named (tier jumps, cross-AZ egress, single-node→sharded) instead of a linear extrapolation that hides them; the forgotten line items checklisted (egress, observability ingestion, backups×retention×copies, non-prod, always-on NAT/LB) because their absence is what makes a model land 40% low; cost-drivers ranked; ranges not false precision; and a unit-cost-at-scale check that flags rising per-unit cost as an architecture problem.
business-case Business case for a build/buy/defer investment decision, written so a sponsor can approve, challenge, or kill it on its merits. Option 0 (do nothing) always present and costed; every benefit is a re-runnable calculation with sourced inputs and a confidence tag (adjective benefits don't survive); all three cost layers per option — build, run (the year-2+ layer where cases go to die), and opportunity with the displaced work named; ranges instead of false precision ("327% ROI" from three guesses fails the doc); the flip-assumption identified with a de-risking step when confidence is low; a singular committal recommendation that states the runner-up's best argument fairly; and the ask in the first 40 words.
requirements-interview Per-stakeholder interview kits for feature discovery — sponsor, end users, ops/support, security/legal, finance — built only for stakeholders holding open unknowns. ≤7 questions per kit ranked by design impact, each annotated with the decision it informs and how the answer moves the design; problems-and-the-past phrasing only ("the last time", never "would you use…"); a mandatory kill-question per script with what a kill-answer looks like; and an assumptions-to-validate ledger where every assumption has a falsification condition (or gets flagged as needing data/prototype instead). Notes flow to brief-intakeprd-draft.
prd-draft Draft a Product Requirements Document from a feature idea or brief-intake output — the missing link before design starts. Problem statement with zero solution nouns (tested: could it justify a different solution than the one in everyone's head?), personas specific enough to find one, a measurable "we'll know it worked when" line per goal, testable MoSCoW-prioritized requirements with a mandatory Won't-have list, minimum 3 non-goals (the scope-creep firewall), open questions with owners and dates, and every claim tagged [reported by …] / [data: …] / [assumption]. Sized for a 30-minute read; hands off to user-story-splitter, nfr-spec, success-metrics, and design-doc.
nfr-spec Sweep a feature through the full non-functional-requirements catalog — performance, throughput, availability/SLO, durability/DR, privacy/retention, accessibility, i18n, observability, operability, compatibility, cost. Every category lands in exactly one of three states: measurable target with a verification method, explicit n/a with a reason, or archetype default tagged [assumption] — silence is forbidden, and the output ledger proves the sweep happened. Targets are calibrated by system archetype and the "what happens if it's down for an hour" answer (anti-five-nines-cargo-cult); retention/deletion is first-class per data class; observability is written as 3am questions, not tool names. Feeds design-doc, test-plan-generator, and threat-model.
success-metrics Define how a feature's success will be measured before it's built. Exactly one primary metric — an outcome, not an output or vanity count — with baseline, target, and timeframe (no baseline? measuring it becomes milestone 1); leading indicators for steering; guardrails with current values and alert thresholds; a counter-metric naming how the primary could be gamed and what catches it; an instrumentation plan where every metric maps to a named event marked exists/must-build (must-build = launch blocker, not fast-follow); and a pre-committed, action-shaped decision rule so a missed target triggers an agreed action instead of a "directionally positive" debate.
user-story-splitter Split an epic, feature request, or PRD chunk into independently shippable vertical-slice user stories — SPIDR slicing patterns, walking-skeleton-first build order, 3–7 Gherkin acceptance criteria per story (always including an edge case), tagged [assumption]s, and an explicit "out of scope / not covered" ledger so nothing silently disappears. Each emitted story is shaped to hand straight to feature-implement-loop.
test-plan-generator Generate a risk-based test plan for a feature, PR, or release. Risks ranked likelihood × impact before any test case is written (effort tracks priority); each case pushed to the lowest pyramid level that catches the failure (unit > integration > e2e, with e2e placement justified); every acceptance criterion mapped in a coverage table; edge-case taxonomy sweep (boundaries, idempotency, concurrency, dependency failure, timezones, …); observable entry/exit criteria; and a mandatory "Not tested — accepted risks" section. Takes user-story-splitter output, a diff/PR, or a prose brief.
release-notes Turn git history between two refs (default: last tag → HEAD) into two artifacts: customer-facing release notes rewritten in reader benefits — no commit-speak, no ticket IDs, no "various improvements" — and an internal Keep-a-Changelog version with a commit hash on every line. Breaking changes hoisted to the top of both with an "Action required" line (detected via !: markers, removed public API, migration files, major bumps); internal noise (refactors, CI, deps) never leaks into customer notes; vague commits land in a "Needs review" list instead of being guessed at.
bug-triage Turn a vague bug report ("it's broken on mobile sometimes") into a ticket an engineer can start without contacting the reporter: searchable symptom-plus-condition title, numbered repro steps from a clean state (or an explicit "no repro yet" with the exact diagnostics to collect), expected-vs-actual with the verbatim error string, every claim tagged [reported] / [verified] / [assumption], severity and priority judged independently (S4/P1 is a legitimate combination), ≤3 hypotheses each with a 5-minute check, and duplicate-search hints. One bug per ticket — multi-symptom reports get split.
migration-plan Phased migration/rollout plan (schema change with live backfill, API version, datastore/auth/platform swap) built on the parallel-change pattern: expand → migrate → contract. One change per phase (a failed phase implicates exactly one thing); every phase carries an observable gate with bake time, a tested rollback with an explicit data story, and a blast radius; at most one named point of no return; backfill specified idempotent + resumable + rate-limited with 3-depth parity checks; dual-write requires a named reconciler; the contract phase gets a date and an owner so "we'll remove the old path later" actually happens.

Product strategy

Skills for the direction-setting layer above any single feature — testing whether a product idea deserves a team, analyzing a market position, and turning strategy into aligned goals. (business-case under Planning & delivery is the natural costed follow-on.)

Skill What it does
prfaq Write an Amazon-style PR/FAQ — the launch press release for a product that doesn't exist yet, plus customer and internal FAQs that force the hard questions before engineering starts. Problem stated in the customer's words (no jargon-laundering); solution names a mechanism, not a category; an adoption hypothesis with a behavioral first-success event (never "ships to beta" — that's the team's action, not the customer's); at least one customer-FAQ answer concedes a real trade-off; the internal FAQ names the riskiest assumption, a concrete acquisition path, a success metric that counts the first-success event, and a kill condition. Zero spec content — hands off to prd-draft or business-case if the idea survives.
strategy-analysis Run a strategy framework — SWOT/TOWS, Porter's Five Forces, or PESTLE — chosen to fit the question, not the request (a "SWOT" that's really "should we enter this market" gets Five Forces suggested). Every cell must be specific, evidence-tagged, and carry a so-what — horoscope cells ("strong team") are banned; SWOT never ships without TOWS crossings; every Five Forces rating names the mechanism (who holds the power and why). Ends with ranked, action-shaped implications tied to a named decision and a verdict that takes a side and states what would change it.
okr-cascade Cascade company OKRs to team level with the two things cascades usually hide: a ranked gap registry (objectives no team credibly owns) and a causal metric tree (Mermaid) connecting every team KR to the north-star via a written causal sentence. Output KRs flagged at intake ("launch v2" → what outcome does it serve?); every team KR scorable 0.0–1.0 and measurable at the team's own scope; no alignment theater (teams with no credible contribution to an objective simply don't appear under it); company OKRs kept verbatim so the roll-up stays honest. Org-level counterpart to success-metrics, which takes each team KR into full feature-level measurement design.

Dev workflow

Skill What it does
feature-implement-loop Implement a feature/story so it ends up verified, not just generated. Takes a description + acceptance criteria, writes code and tests, then runs a review panel (delegating to the devils-advocate, security-reviewer, and code-quality subagents in parallel where available, sweeping the lenses inline elsewhere) to find gaps — broken edge cases, baked-in assumptions, acceptance criteria with no asserting test — and re-generates to close them. Loops until the review is clean or a hard 3-round cap is hit, then reports status (VERIFIED / VERIFIED WITH OPEN ITEMS / BLOCKED), an acceptance-criteria coverage table, and a per-round log. The build-cycle counterpart to the artifact pipeline.
pre-merge-review Gate an existing change before merge with one command that fires the whole review fleet: a deterministic mechanical gate (scripts/gate.py runs the project's lint + typecheck + tests; its exit code decides — un-bypassable) and the three-reviewer panel — devils-advocate (correctness), security-reviewer (exploitability), code-quality (craft) — dispatched in parallel, then a single READY / NOT READY verdict (READY only when the gate is green and no blocker/major stands). Where feature-implement-loop generates and loops, this judges a diff you already have; design disagreements escalate to council-review.
devils-advocate Adversarial review of just-generated code, run right after an agent (or human) declares a feature done. Sweeps four lenses — edge cases the first pass missed, assumptions baked in that won't survive 6 months, what a staff engineer would push back on in review (concurrency, error handling, security, observability, blast radius), and test-coverage gaps. Produces severity-tagged findings (blocker / major / minor / nit) with file:line evidence, reproducible scenarios, and concrete fixes — plus a "what's solid" section. The code counterpart to doc-critique.
council-review The "Claude Council." Convenes five distinct senior-engineer personas — 🏛 Architect, 🔒 Security, 🛠 Operator/SRE, ⚖️ Pragmatist, 👤 User-Advocate (plus optional bench seats: Performance, Cost, Data & Migration, Accessibility, Compliance) — to deliberate a decision, design, or code change. Each seat takes an independent stance (🟢 support / 🟡 conditions / 🔴 oppose / ⚪ abstain) with evidence; the genuine disagreements surface as named cruxes; a Chair issues a reconciled verdict (PROCEED / WITH CONDITIONS / REVISE / RECONSIDER / SPLIT) that names the tradeoff chosen, records dissent, and states what would change the decision. Where devils-advocate is one voice, the council is many that can disagree. Use for architecture decisions, risky changes before merge, RFC scrutiny, "should we adopt X?", or a pre-mortem.
threat-model STRIDE threat model from a design doc, architecture description, or reverse-architecture output — before the code exists. Establishes assets / entry points / trust boundaries first, runs STRIDE per boundary crossing, and writes every threat as a concrete actor → path → result scenario (severity 🟥/🟧/🟨/⚪ calibrated to this system's assets, not CVSS theater). Credits existing mitigations as verified-vs-assumed, attaches a verification step to every recommendation, and forces the two classic blind-spot sweeps: authz (tenant→tenant, authn ≠ authz) and insider/compromised-credential. Design-phase counterpart to devils-advocate.
accessibility-audit Adversarial WCAG 2.2 AA audit of a UI — component code, page markup, screenshot, or a described flow. The UI counterpart to devils-advocate: every finding cites a specific success criterion (number + name + level), names the user group and assistive tech it blocks (no victim, no finding), is severity-tagged by task-completion impact (🟥 blocker → ⚪ nit), and carries a concrete fix. Computes real contrast ratios (not eyeballing), sweeps the high-yield checks scanners miss (focus order, name/role/value, alt-text quality, error recovery, reflow, target size), tags each finding [auto] vs [manual] so CI-gateable issues are split from the human-only ones, and states the input's coverage limits — a screenshot audit never claims keyboard operability passes. Ships the WCAG catalog and a worked example.
sonar-onboard One-shot scaffold to make a repo Sonar-compliant. Supports both SonarQube server (self-hosted) and SonarCloud (SaaS) — user picks at setup. Emits sonar-project.properties with language-detected source/test/coverage paths, a GitHub Actions workflow that runs the scanner on push + PR and blocks merge on quality-gate failure, and a README snippet documenting the gate.
sonar-review Per-change Sonar compliance review. Runs the scanner against the current branch, fetches the quality-gate verdict + issues + security hotspots from the Sonar API, and produces a structured markdown report scoped to changed files: gate PASS/FAIL on top, then severity-tagged findings (🟥 blocker / 🟧 critical / 🟨 major / ⚪ minor) grouped into five lenses (bugs, vulnerabilities, security hotspots, code smells, coverage + duplication), each with file:line, the Sonar rule ID, why it matters, and a concrete fix. Auto-detects server vs cloud from sonar-project.properties. Sister skill to devils-advocate.

Diagrams

Skill What it does
architecture-diagrams Turn a written description of a system into a renderable Mermaid, PlantUML, or C4 diagram. Supports AWS / Azure / GCP cloud shapes, sequence flows, container diagrams, and ER models.
reverse-architecture Reverse-engineer a system's "as-is" architecture from existing code, IaC (Terraform / CloudFormation / CDK / Pulumi / Bicep), Kubernetes manifests, docker-compose, package manifests, database schema, or OpenAPI. Emits a structured node/edge extraction, a written description suitable for architecture-diagrams, and a first-draft Mermaid / C4 diagram with every node tied to a source-of-truth file path.
figma-diagrams Read structure from existing Figma/FigJam files and produce FigJam-importable diagram specs (and comments) via the Figma REST API. Useful when your final deliverable lives in Figma.
user-journey-map Map one persona's end-to-end journey toward one outcome — 3–6 goal-phase stages (never one-per-screen), each with actions / reasoned emotion scores / pains / outcome-shaped opportunities (no solutioning — "add SSO" belongs downstream), rendered as a Mermaid journey emotion arc. Declares its evidence level up front ([observational] / [survey/analytics] / [assumption-based]) so a hypothesis never masquerades as research; marks the steepest dips, the peak, and the ending emotion (peak-end rule); and ranks opportunities down to 1–2 named improvement targets instead of an unranked pain inventory. Hands committed targets to prd-draft / user-story-splitter and measurement to success-metrics.

Documentation

Skill What it does
adr-generator Generate an Architecture Decision Record in MADR or Nygard format from a context-decision-consequences brief, with sensible numbering and filename.
design-doc Generate a Google-style engineering design doc (problem → goals/non-goals → alternatives → proposal → risks → rollout) from a feature brief.
runbook-generator Generate an operational runbook for a service — deploy/rollback, top 5 incident playbooks, SLOs, on-call escalation, dependencies.
observability-plan Design the telemetry that makes a service detectable-before-users-complain and debuggable-at-3am. SLIs defined from user journeys (good/valid events), not resource graphs — latency SLIs as threshold counts at a percentile, never averages; SLOs with an error budget in human terms and a spend policy (what freezes when it's gone); symptom-based, multi-window burn-rate alerting where a page means a human must act now and every page is runbook-linked (the alert-fatigue fix); the three pillars split by purpose (metrics for SLOs/alerts with bounded cardinality, structured sampled logs for debugging, tail-sampled traces for cross-service attribution); and a cardinality + cost budget so observability doesn't become the surprise invoice. Expands nfr-spec's observability row; feeds runbook-generator, incident-comms, postmortem-generator.
postmortem-generator Generate a blameless incident postmortem from raw response material (Slack scrollback, pager timeline, notes). Quantified impact table (numbers or [missing] — never "significant impact"); UTC timeline with computed detection and mitigation gaps; 2+ contributing factors with "human error" structurally banned; mandatory what-went-well / poorly / where-we-got-lucky lists; ≤8 action items each with owner role, prevent/detect/mitigate class, and a verifiable done-condition; ends with paste-ready runbook deltas for runbook-generator.
guide-builder Turn raw notes or a spec into an easy-to-follow guide, auto-styled to the content: a setup/quickstart (prerequisites → steps → verify → troubleshooting), a design walkthrough (mental model → flow → key decisions → where the code lives), or an API/event-schema reference (typed contracts + example payloads + error catalog). Distinct from runbook-generator (SRE/on-call) and design-doc (proposal for review).
api-contract-draft Draft an OpenAPI 3.1 contract from a feature brief, before the code — resource-oriented paths (plural nouns, no RPC verbs), full RFC 9457 error catalog with machine-readable codes per operation, cursor pagination / Idempotency-Key / URL versioning decided at draft time instead of retrofitted, production-realistic examples on every operation, and typing rules that ban the classic regrets (float money, naked timestamps, unbounded strings). Emits a decisions log alongside the YAML so reviewers argue choices, not line numbers. Handles event/webhook contracts (AsyncAPI-shaped) with the same rigor. Designing new contracts only — documenting an existing API is guide-builder's job.
db-schema-design Design a database schema from the queries backward — the access patterns (frequency, selectivity, consistency) come before any table is drawn. Paradigm chosen with a reason tied to those patterns (relational is the default and needs none; every move past it justifies itself); keys designed from queries (surrogate PK by default, NoSQL partition+sort key to avoid hot partitions, no random UUIDv4 as a clustered key); 3NF then denormalize only for a named hot read with its sync obligation; indexes mapped one-to-one to real queries (composite order = equality→range→sort); money/time/enum types right at the schema; explicit multitenancy and unbounded-growth-table decisions; and a verification table proving every access pattern has a supporting path, full scans flagged. Distinct from data-contract (published-dataset guarantee) and api-contract-draft (sync interface); hands evolution to migration-plan.
data-contract Draft a data contract for a dataset, table, or event stream others depend on — the data-engineering counterpart to api-contract-draft. Schema specified with per-field semantics and units (the cents-vs-dollars, UTC-vs-local, gross-vs-net firewall), measurable quality SLAs across freshness / completeness / validity / uniqueness / distribution — each with a threshold, a check, and a breach action — a schema-evolution policy that names the silent killer (changing a field's meaning under a stable name/type is breaking, and no validator catches it), enumerated consumers (so "breaking" is defined and notices have an address), a named owner, and per-field PII classification. Marks aspirational-vs-met SLAs honestly on existing assets.
tech-comparison-matrix Produce a weighted comparison matrix for a tech-selection question (e.g. "Postgres vs DynamoDB") with criteria, weights, scores, and a recommendation.

Agent engineering

Designing the agentic systems themselves — the loops, orchestrations, and budgets that turn "prompting an agent" into infrastructure a team can run unattended. (feature-implement-loop under Dev workflow is the in-repo worked example of a supervised loop; llm-eval-harness below builds the verifier's quality gate.)

Skill What it does
agent-loop-design Design a supervised agent loop as an implementable loop spec: a strict generate→verify→gate state machine (no mushy "reflect" states), an observable done-condition (never "output looks good"), verifier structurally ≠ generator (self-grading inflates), both caps as numbers (revision cap defaulting to 3, budget cap per run), human gates at every irreversible action with decision-shaped digests (never transcripts), findings flowing into the next round (else it's retry, not iteration), three specified failure routes (cap-hit / can't-judge / systemic early-stop), and a telemetry row so the loop's degradation shows up before its output does.
subagent-design Decompose a task into orchestrator + subagents — starting from "the default answer is one agent": fan-out must earn itself via context separation, independence, or role conflict, or the plan says so. One-mission role cards (typed output contracts, explicit context-isolation lines, least-privilege tools, structured failure behavior), topology chosen with the reason attached (pipeline default; barriers only for named cross-item dependencies; judge panels with a vote rule), depth capped at one level, an adversarial verification stage that is never a generator, and a budget line per fleet.
agent-budget The spend spec for an agentic workflow: cheapest-adequate tier per stage (light/standard/heavy — heavy verification is never downgraded to save money), three numbers per stage (expected, hard cap, on-cap action — "warn and continue" banned), a run-level cap below the sum of stage caps, a degradation ladder where verification is last and never cut, and cost-per-outcome as the governing metric with a comparison line against the manual alternative — so "$900/week" becomes answerable. Estimates tagged [assumption] until calibrated on real runs.
agent-threat-model Security review of an agent's capability surface against the lethal trifecta — private data, untrusted content, an exfiltration vector. Inventories data reach transitively (the filesystem tool reaches every secret in .env), applies a writer-authorization test that classifies almost every content source untrusted, and sweeps egress past the obvious network tool (rendered markdown images, CI logs, error text, DNS). Scores paths, not toolsfetch is fine alone and lethal beside a secrets file — then names the architectural fix that breaks a leg, with a verification step. Structurally refuses the two answers teams reach for first: a system prompt telling the model to ignore injected instructions is not a control, and an injection classifier is defense in depth, never a broken leg.

| agents-md-generator | Generate or audit the AGENTS.md that Claude Code, Codex, Cursor, Copilot, Kiro and Antigravity all read before your prompt. Built around one rule: every command traces to evidence in the repo — a CI step, a Makefile target, a package.json script — or it appears as [missing: no test command in CI or manifests] rather than a guess, because an invented command is a fault the agent will trust over the filesystem. Convention lines must pass a counterfactual test (without this line, would a competent agent do the wrong thing?); virtue instructions — "clean", "best practice", "thorough" — are stripped, not softened, since they spend context and change no behaviour. Names forbidden actions explicitly, the section most files omit. Hard ~150-line cap when generating, a warning when auditing, because an existing file may be long for good reason. Audit mode emits a diff, never a silent rewrite. Satellites (CLAUDE.md, .github/copilot-instructions.md) are opt-in and delta-only — a satellite that repeats AGENTS.md is guaranteed drift. |

AI adoption & observability

Skill What it does
agent-adoption-stage 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 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 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 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 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 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 dep