Every skill, by category
All the skills grouped by what they produce, one line each, plus the anatomy every skill folder shares.
The catalogue site is the searchable version of this page, with a page per pack. This is the long-form list.
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. |
output-hygiene | Pre-ship surface pass. Runs a stdlib-only script over agent-written text to find what the machine put there — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — reporting each with its codepoint and line, then sweeps the prose for the tells a script cannot see and quotes every one with a rewrite. Separates what is safe to auto-apply from what needs a decision, and holds the provenance class where an academic, employer, or contribution policy requires disclosure. |
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. |
lean-canvas | A lean canvas that finds what could kill an idea: the nine boxes filled only from what the person said, each tagged evidence or assumption, the assumptions ranked by risk, the cheapest test with a pass line set in advance for the riskiest, and unit economics computed by its script when price and costs are given. |
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-intake → prd-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 | Release notes from a git log, a PR list or rough notes, for the audience and in the format you name (changelog page, email, in-app "what's new", store text, CHANGELOG.md). Nothing the input doesn't say; a vague change written only as far as it was described; reverted work left out; breaking changes and required actions first, phrased for how the audience gets the release; internal noise and working notes kept out of the text. |
pr-description-writer | The title and description for one pull request, written from the diff and commits: why, what changed, how it was tested with only the checks really run, where a reviewer should look first, risk and rollback, and what the diff contains that the commits don't mention (dependency bumps, deleted tests, migrations, API changes). |
tech-debt-register | A ranked technical-debt register from notes, TODOs and incident write-ups: each item with where it lives, the cost it imposes today with its evidence, the fix size, a decision (pay now, schedule, accept, watch) and the trigger that reopens it, led by the few items worth paying down this quarter. Costs without evidence are marked as such, never estimated. |
refactor-plan | Plan paying down one debt item as small behaviour-preserving steps, each its own PR with main releasable after it: characterisation tests before untested code is touched (pinning the bugs callers rely on), a target with a measured baseline and a stop point, a scope fence, a technique per step with its reason, and what clashes with in-flight feature work. The plan can stop after any step with the code better than before. |
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. |
behaviour-equivalence | Prove a rewritten or migrated component behaves the same as the old one: inputs and outputs recorded from the old system at a boundary, the old system run twice to find what varies on its own, normalisation rules one field at a time with a reason, and every remaining difference triaged as a defect, an approved change or missing normalisation. A script does the diff; the verdict is EQUIVALENT, EQUIVALENT EXCEPT LISTED CHANGES, NOT EQUIVALENT or NOT PROVEN. |
rollout-plan | Progressive exposure of a code change behind a flag or canary: each step's cohort, decision and guardrail metrics with a baseline and a threshold against the control group, how long the step must run to detect the regression worth catching (computed by its script), promote / hold / roll back rules set in advance, and what turning the flag off does not undo. Hands schema and data moves to migration-plan. |
launch-readiness | Go/no-go readiness report for a merged change before it reaches users. It lists the change's own failure modes first, then judges seven checks in order: rollback, detection, response, measured NFR targets, data & privacy, comms, staged exposure. Each row is met / not met / n/a-with-reason, with an evidence link and an owner role, and a row with no evidence is not met. The verdict (PROCEED / PROCEED WITH CONDITIONS / REVISE / BLOCKED) follows mechanically from the rows, and a missing rollback blocks on its own. Gaps go to migration-plan, observability-plan or runbook-generator instead of being drafted inline. The ready stage of the release loop. |
backlog-triage | Triage of a whole Jira, Linear or GitHub backlog export: confirmed duplicate pairs, missing owners and acceptance criteria, stale and oversized items, priority conflicts, a reasoned ordering and an applicable change list. |
cloud-cost-review | Ranked savings review of an actual AWS/GCP/Azure cost export: month-over-month movers, idle and unattached resources, evidence-gated rightsizing, storage tiering, data transfer hot spots, commitment coverage and untagged share, each with a bill-derived monthly saving, confidence and ease. |
delivery-metrics-report | DORA metrics (deployment frequency, change lead time, change fail rate, failed deployment recovery time) plus WIP, cycle-time p50/p85 and throughput for one service, computed by a stdlib script from deploy/incident/PR CSVs, with weekly trends, named data gaps and a refusal to rank teams. |
tracker-brief-sync | PRD or brief to tracker-ready epics and stories (Jira CSV, mapped CSV or gh commands) linked back to doc sections, plus a drift report between doc and tracker. |
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 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 |
|---|---|
dependency-upgrade-review | A merge verdict on a dependency-upgrade PR: release notes read for every skipped version, everything the lockfile changes beyond the title (transitive bumps, new packages, install scripts), each SHA pin checked against its tag or marked unverified, whether CI ran the changed code, the repo's uses of changed APIs, and the rollback. MERGE, MERGE AFTER CHECKS or DO NOT MERGE, from fixed rules. |
codebase-tour | A tour of an unfamiliar repo scoped to one change: commands from CI and package scripts marked run or read, the path the change touches cited to file:line, where the README is wrong, the traps (generated files, a second copy of the logic, untested code, env vars), and a first step that can be checked. |
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 a code change before it merges. The merge answer first, then the bugs that would bite, most consequential first, each traced through the code before it is reported and given a fix as code when it is small. Every test or clean run you cite is judged: could it have caught the bug, and if not, why it passed and which test would fail. Sized to the ask ("top 3", "skip the nits"); invents nothing about the codebase. |
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. |
interactive-diagram | One self-contained interactive HTML diagram (architecture, data flow, workflow, lifecycle, ERD, sequence, class, tree, timeline or waterfall) from a repo, a description, a schema, incident notes or a trace. Every part and connection cites its file and line or the words it came from, inferred ones are drawn dashed as assumptions, and citations are checked against the repository before the page is written. Laid out automatically, with long flows wrapped onto rows; pan, zoom, click-through evidence, paths, walkthroughs, light and dark, SVG / PNG / Mermaid export; no CDN. Python 3 standard library only. |
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. |
feedback-synthesis | Ranked themes from tickets, NPS verbatims, reviews and interview notes, each a problem rather than a feature request, counted by distinct people (a script does the counting), with severity apart from frequency, verbatim quotes with source IDs, what people value, where sources disagree, and what the sample cannot tell. |
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. |
slo-spec | SLOs from a service's user journeys: each SLI good events over valid events, measured where users feel it; a target checked against what the dependencies allow; the error budget in minutes and bad requests (computed by its script); multi-window burn-rate alerts with the budget each consumes when it fires; and an error-budget policy with owners. |
postmortem-generator | A blameless postmortem from chat scrollback, alerts and notes, at the length and for the audience you name. The cause is the change and the gap that let it through, never a person, even when the notes name one; who or what noticed first, and how long before any alert; known kept apart from still open; checkable follow-ups with owners only where given; runbook edits when a procedure proved wrong. No invented figures, severities or placeholders. |
guide-builder | Turn notes, a spec or a thread into a guide someone can follow (setup, how-to, onboarding walkthrough, or developer reference) at the length its reader needs. Only what the notes say, with inferences marked in place; steps ordered so nothing is used before it is set up; open questions kept in the reply so the guide can be sent as it stands; the reader told who to ask where the notes leave a gap. 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. |
context-graph | The graph of decisions behind a codebase, from its ADRs and RFCs: what governs a file now, what it replaced, and the rationale quoted from the record. Finds supersessions only one side records, current decisions pointing at deleted code, two current decisions on the same path, and references to records that don't exist; says "no recorded decision" when there is none. |
event-contract-draft | An event or message contract as AsyncAPI 3.0 plus a decisions page: past-tense event names, an envelope with an event id for deduplication, the partition key and the ordering it does and doesn't give, at-least-once delivery with idempotent consumers, personal data kept to what a named consumer needs, and additive-only versioning with a dated deprecation. Says no to global ordering and exactly-once up front. |
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. |
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. |
mcp-pairing | Which MCP servers a loop or workflow needs, stage by stage: the context each stage needs, a server only the user named or the vendor publishes, the narrowest scopes (read-only by default, never write on a review or gate stage), what it must not do, an export-file fallback, and the stages that need none. |
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 tools — fetch 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. |
agent-config-review | Whether a coding agent's setup gives more access than the work needs, read across every scope that applies (Claude Code user, project, local and managed settings; hooks; MCP servers; subagent tools; Codex profiles), with each finding's file and line, what it lets happen, and the exact replacement config. SAFE AS CONFIGURED, TIGHTEN BEFORE USE or DO NOT USE. |
judge-audit | Whether an LLM judge can be trusted for the decision its scores drive: chance-corrected and weighted agreement with expert labels, broken down by the variants being compared so a bias toward one arm shows, each run reported separately, rare-class precision and recall with intervals, position and length bias, checked against the user's own gate. |
agent-incident-response | The first hour after an AI agent or its tooling went wrong (a leaked key, a destructive command, a runaway bill, a malicious MCP server, an injected agent): the answer to the question asked, then the first 15 minutes in order, revoking at the provider before anyone touches git, with exact recovery steps and who to tell by when. |
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 | An AI use policy or staff guidance at the length and in the voice your audience needs: what is allowed first, every "don't" paired with what to do instead (or that no approved way exists yet and who decides), and what to do if data has already gone into a tool. Claims nothing about a tool's data handling, seats, owners, turnarounds or laws that you didn't give it, and reports a vendor's assurances as the vendor's. |
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 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 | 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. |
Claude API
Skills for teams building directly on the Anthropic API — prompt caching strategy, token budgeting, eval generation for skills, and tool-use schema authoring.
| Skill | What it does |
|---|---|
prompt-caching-advisor | Analyzes a prompt or conversation structure and identifies the highest-value cache_control breakpoints — which blocks to cache, where to place the checkpoint, and estimated hit rate. Warns when a cacheable block is below the minimum threshold (~1,024 tokens for Haiku, ~2,048 for Sonnet/Opus). Produces an annotated messages array and a one-paragraph cache strategy summary. |
token-budget-estimator | Breaks down token usage for an agentic workflow by component — system prompt, injected context, tool definitions, tool results, context accumulation, and output — surfaces the dominant cost driver, and recommends concrete max_tokens controls. Covers extended thinking (budget_tokens) when relevant. |
eval-harness-generator | Takes a SKILL.md and generates 8–12 eval cases (happy path, edge, anti-pattern, refusal) ready to drop into the skill's evals/cases.json. Each case has a realistic trigger, checkable expected_shape criteria, and must_not_include guards from the skill's own quality bar. |
tool-use-schema-writer | Converts a function description into a valid Anthropic tool_use JSON schema with typed properties, required arrays, and decision-condition descriptions. Validates that required arrays are present and enum values are described. Produces a Python client.messages.create(tools=[...]) usage snippet. |
Skill authoring
| Skill | What it does |
|---|---|
skill-author | Writes a portable Agent Skill folder from a described task: routable description, decisive steps, quality bar, boundaries naming siblings, evals, and per-tool install paths. |
skill-review | Audits a skill folder for routing, sibling collisions, portability, safety (OWASP AST IDs), structure and evals, with a stdlib lint script and a READY / FIX FIRST / REWRITE verdict. |
Stakeholder communication
| Skill | What it does |
|---|---|
audience-profile | Translate an audience type (exec, board, technical, sales, investor, internal, partner, customer) into structural rules — slide count, density, tone, must-have sections. Reusable input for the next three skills. |
exec-summary | Compress a long technical document into a one-page executive summary structured around an Ask, business impact, cost/timeline, risks, and what you need from the audience. |
decision-log | Extract decisions, action items, owners, and due dates from meeting notes, Slack threads, or transcripts into a structured log with source attribution. |
incident-comms | Draft the messages you send while an incident is still burning — audience-segmented into customer status-page posts, internal stakeholder updates that arm the relayer, and three-sentence exec briefs (business impact + the ask). Every message leads with reader-facing impact (not internal symptom), uses the precise status vocabulary (investigating / identified / monitoring / resolved), commits only to the next-update time (never a fix ETA or speculative cause you'd have to retract), and stays blameless and screenshot-safe. Acknowledge → update-on-committed-cadence → verified resolve. Completes the operate triad with runbook-generator (how to fix) and postmortem-generator (what to say after). |
team-status-report | Weekly status report from tracker data: shipped, in progress, blocked with blocker and owner, slipped against plan, risks and asks, with script-computed numbers and a RAG status stating its rule. |
Design and brand
Capture a brand once, and plan a deck for its audience. brand-kit writes the brand.json that the Word and PowerPoint converters apply with --brand.
| Skill | What it does |
|---|---|
brand-kit | Capture a brand as a reusable brand.json: logo files (and an on-dark version), five colour roles as hex codes, heading and body fonts, voice (words to use and avoid), imagery rules, a PowerPoint template, contact details and legal footer. Every value is traced to its source and tagged [explicit] or [inferred]; a stdlib checker fails malformed hex codes, text contrast below 4.5:1 and missing files, and flags SVG logos PowerPoint can't use. Writes a one-page BRAND.md too. |
slide-outliner | Outline an architecture-review or pitch deck — slide titles, key points, and speaker notes — sized to a target time budget. Doesn't generate PPTX. |
Converters
| Skill | What it does |
|---|---|
file-to-markdown | Clean Markdown from .docx, .pptx, .xlsx, .html, .csv, .json or PDF, keeping headings, lists, tables, links and speaker notes, with a report of everything dropped. |
md-to-docx | Markdown to a Word .docx with real Heading styles (navigation pane, TOC), live links, lists, tables, code, embedded images, optional brand fonts, and a warning per dropped construct. |
md-to-pptx | Markdown to a PowerPoint deck with nothing to install: one heading per slide, real tables and embedded images, comments as speaker notes, and a section too long for one slide split onto "continued" slides at full size. The reply names every split, everything dropped, and any speaker note that would go out with the file. |
md-to-confluence | Markdown to a Confluence page in storage format: real code blocks, tables, tasks and panels, images listed as attachments, and an optional publish that first shows which page it will change and at what version, refuses stale or wrong-space overwrites, and reads credentials only from the environment. |
md-to-xlsx | Markdown tables, CSV or JSON to an Excel .xlsx: one sheet per table named from its heading, typed numbers, currency, percentages and dates, frozen filtered header, formulas inert by default. |
Data & analytics
| Skill | What it does |
|---|---|
dashboard-spec | A dashboard brief built from a decision: prioritised questions, one chart per question with its type and defined metric, filters, freshness SLA, layout and a cut list. |
sql-review | A correctness-first SQL review: join fan-out, NULL traps, timezone and date boundaries, integer division, window frames, then performance, each finding with the wrong result and corrected SQL. |
Experience design
| Skill | What it does |
|---|---|
content-design | Content spec for a page from user needs: need statements, prioritised questions, structure, plain-language draft with a stdlib before/after readability check, and a cut list. |
design-system-spec | Component spec: purpose and boundary, numbered anatomy, variant axes, every state by token name, behaviour, content rules, keyboard/ARIA/contrast cited to checked WCAG 2.2 criteria, and engineering questions. |
information-architecture | Sitemap and navigation model from a content inventory: task-based groups, user-word labels with a rationale table, global/local/utility nav, Mermaid diagram, findability risks, and a tree-test or card-sort plan. |
service-blueprint | Service blueprint for one scenario: evidence, customer, frontstage, backstage and support lanes with the three lines, owners, fail points and waits, pains traced to causes, Mermaid, ranked fixes. |
ux-writing | Interface string table for a flow: every button, label, error, empty, loading and success string with context, character budget, a variant, and a terminology list. |
Governance, risk & compliance
| Skill | What it does |
|---|---|
dpia | A GDPR DPIA draft for one processing activity in Article 35(7) order: data inventory, lawful basis per purpose, risks to individuals, measures, residual risk, prior-consultation view, DPO questions. |
risk-register | A risk register CSV with cause-event-consequence risks, inherent and residual scores on a defined scale, owners, treatments and review triggers, plus a script-checked heat map and top decisions. |
soc2-evidence-map | Controls mapped to the SOC 2 criteria in scope, with the Type I or Type II evidence, source system, owner, frequency and gaps per control, as a table and CSV. |
security-questionnaire-response | Draft answers to a customer security questionnaire from your own policies and reports: Yes, No, Partial or Not applicable with a short response and the document and section behind it. Uncovered questions are marked as needing input, and conflicts, stale evidence and answers that commit to future work are flagged for the security owner. |
Infrastructure as code
| Skill | What it does |
|---|---|
terraform-module | A reusable Terraform module: versions.tf, typed and validated variables, secure defaults, a merged tags variable, a basic usage example, and a README with inputs and outputs tables. |
terraform-plan-review | A pre-apply review of a terraform plan: every destroy and replace with its cause, stateful and access changes, drift, out-of-scope changes, and a SAFE / CARE / DO NOT APPLY verdict. |
Frontend
| Skill | Produces |
|---|---|
web-performance-review | What makes a page slow for real users, from a Lighthouse or PageSpeed Insights report: field p75 decides whether there is a problem and the lab run explains why, the LCP element and its slowest phase, what shifts and why, and fixes ranked by how much each moves the failing vital. |
rendering-strategy | How each route of a web app is rendered (static, revalidated, server, client, edge or a mix), decided per route from freshness, personalisation, indexing, cost and interactivity, with each route's cache key, invalidation event and failure mode. |
bundle-size-review | What makes a JavaScript bundle heavy and what can safely come out, from webpack, esbuild or Vite stats: exact byte sizes of what each entry loads before first render, the import chain behind each heavy module, duplicates with both install paths, and polyfills checked against the repo's own browser targets. Given before and after stats, what grew, why, and which per-entry budget would have caught it. |
Research
| Skill | What it does |
|---|---|
hypothesis-comparison | Analysis of competing hypotheses: consistency matrix, hypotheses ranked by evidence against them, diagnostic evidence and linchpins, and the next observation that discriminates. |
research-plan | A decision-led research plan: precise question, sub-questions with the finding that would change the decision, method per sub-question, inclusion criteria, search strings, stopping rule. |
source-synthesis | What a set of supplied sources supports on your question, in the size you asked for: nothing from outside unless labelled where it appears, echoes counted once, the sources' own sums checked, and a labelled estimate when you need a figure they don't settle. A fully cited literature review, with a citation checker, when that is the ask. |
Job applications
| Skill | What it does |
|---|---|
role-shortlist | Sort every open role on a careers page, a job-board export or a folder of saved postings into apply, maybe, skip and not read, against one resume. Each role is judged only from its own posting; a role it could not read is listed as unread, never guessed from its title; an unmet licence, location, right-to-work or required degree takes a role out whatever else fits; the same role posted twice counts once. |
job-fit-analysis | A posting compared with a resume: a verdict, the screening requirements first, each requirement marked met, partly, not shown or not met with the resume line behind it, and questions about what the resume doesn't show. |
resume-tailor | A resume reworked for one posting in its own format (Markdown, Typst, LaTeX, Word) with every employer, title, date and number unchanged, lists of what was cut, what was added from outside the resume and what it cannot claim, and a script that lists figures and names the original doesn't contain. |
cover-letter | A cover letter under a page from the resume and the posting, with no enthusiasm, company facts or experience the person didn't supply, checked by the same script. |
application-form-answers | An answer sheet for a job application form in the form's own order: answers drafted from the resume inside each word limit, the questions that could screen the application out named first, and declarations (right to work, salary, conflicts, monitoring) handed back unanswered with what on the resume bears on them. |
What's in a skill
Every skill folder follows the same layout, so installation is the same anywhere. It lives in its pack, at packs/<pack>/skills/<skill-name>/ (RFC-0034), and is self-contained: copy that one folder and it works.
packs/<pack>/skills/<skill-name>/
├── SKILL.md # The instructions the AI agent reads — entry point
├── manifest.json # Name, description, version, declared deps, required env vars
├── requirements.txt # (optional) Python deps if the skill has scripts
├── reference.md # (optional) Long-form reference material
├── examples/ # (optional) Worked examples the agent can study
├── templates/ # (optional) Starter snippets the agent can copy from
├── evals/ # (optional) Acceptance checks — evals.json (prompt + assertions) + eval_queries.json (trigger phrases)
└── scripts/ # (optional) Executable helpers the agent invokesThe manifest.json is the canonical machine-readable summary: its deps block lists pip / npm packages, and env.required lists env vars that must be set before the skill works. Its related block lists the sibling skills this one hands off to, builds on, or names as alternatives — the companions to install if you want the pipelines to work end-to-end. Its model block declares the cost-effective model tier for the skill (see below).