skilldrop-cli 0.13.4 → 0.13.6

package/README.md

@@ -3,581 +3,58 @@
 [![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 63 skills, filterable by outcome, pack, tag, and model tier.
+**Portable AI-agent skills for the deliverables knowledge workers actually ship:** ADRs, design docs, PRDs, runbooks, threat models, decks, postmortems and adversarial reviews. Each one is a folder you copy into Claude Code, Cursor, Kiro, Codex or Copilot.
 
-**63 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, sre-oncall,
-npx skilldrop-cli list                               #     stakeholder-comms, ai-engineering, claude-api (each brings core)
-```
-
-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**](https://agentskills.io) Anthropic ratified — so the same folder runs unchanged in Claude.ai, Claude Code, the Claude Agent SDK, Cursor, Kiro, Codex, Copilot, Antigravity, and anything else that reads the format. Portable by construction: no runtime, no platform, no lock-in.
-
-**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 layout doubles as an open catalog contract: [any repo shaped like this one](guides/how-to/publish-a-catalogue.md), or with a plain flat `skills/` folder, 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 ships **loops**, not just parts. A loop is a named sequence of stages over existing skills with a gate between them: [`packs/<pack>/loops/<name>/LOOP.md`](packs/) is what an agent reads, `loop.json` is the machine-readable contract ([RFC-0028](docs/rfcs/0028-loops-as-a-primitive.md)). **Nothing comes out of a loop until it passes that loop's gate.**
-
-A loop *sequences* skills — it never contains one. Every skill stays independently installable and runnable on its own, which is what keeps a single-folder copy working in Cursor, Kiro, or Aider.
-
-Five loops cover the lifecycle, and they are separated by **reversibility** — how expensive the mistake is to unwind — which is why each gets its own gate rather than folding into a neighbour:
-
-| Loop | Takes | Gate | Produces | Mistake costs |
-|---|---|---|---|---|
-| [`discover`](packs/product-manager/loops/discover/LOOP.md) | interviews, journeys, a strategy question | **G0** human — a person ratifies the brief | a ratified requirement | a re-brief |
-| [`design`](packs/solution-architect/loops/design/LOOP.md) | a ratified requirement | **G1** review — `council-review`'s panel | a recorded decision (ADR) | months, unwound in code |
-| [`build`](packs/dev-team/loops/build/LOOP.md) | an agreed requirement or triaged defect | **G2** mechanical — `pre-merge-review`'s gate script decides | merged code | a revert |
-| [`release`](packs/dev-team/loops/release/LOOP.md) | merged code | **G2.5** review — `launch-readiness` on evidence; **G2.6** human go/no-go | a live, reversible rollout | users and data, often irreversible |
-| [`operate`](packs/sre-oncall/loops/operate/LOOP.md) | a shipped service | **G3** human — the incident is closed | a postmortem and runbook deltas | live users, irreversible |
-
-Plus one **wrapper**, which is not a lifecycle stage but the two passes either side of *any* generator:
-
-| Wrapper | Takes | Gate | Produces |
-|---|---|---|---|
-| [`ship-a-draft`](packs/core/loops/ship-a-draft/LOOP.md) | raw notes, a transcript, a ticket | **G4** review — `doc-critique`'s verdict | a stakeholder-ready artifact |
-
-Every gate emits a verdict from one shared vocabulary ([`contracts/terminals.json`](contracts/terminals.json)) in five classes — pass, conditional, revise, redirect, blocked — so `READY`, `PROCEED` and `SHIP IT` are recognisably the same kind of answer. The diagrams below render on GitHub; their Mermaid sources live in [`docs/loops/`](docs/loops/) for re-rendering.
-
-*Diagrams below are generated from each loop's `loop.json` by [`build_loops.py`](build_loops.py) — edit the contract, not the picture.*
-
-### `discover` — raw signal to a ratified requirement
-
-Interviews, journeys and strategy questions become one tagged brief, then numbered requirements a **human ratifies** before any design starts.
-
-<!-- loop:discover:start -->
-
-```mermaid
-%%{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 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;
-
-    gather["gather<br/><small>requirements-interview +2</small>"]:::gen
-    structure["structure<br/><small>brief-intake</small>"]:::gen
-    specify["specify<br/><small>prd-draft</small>"]:::gen
-    ratify["ratify<br/><small>doc-critique</small>"]:::gate
-    G0{"G0 · human"}:::gate
-    DONE(["complete"]):::ship
-
-    gather --> structure
-    structure --> specify
-    specify --> ratify
-    ratify --> G0
-    G0 == "PROCEED" ==> DONE
-
-    G0 -- "REVISE (max 3)" --> structure
-```
-
-<!-- loop:discover:end -->
-
-### `design` — a requirement to a recorded decision
-
-Constraints first, then structure and diagrams, then an attack, then a panel that must agree — and only then is the decision written down as an ADR.
-
-<!-- loop:design:start -->
-
-```mermaid
-%%{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 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;
-
-    constrain["constrain<br/><small>nfr-spec</small>"]:::gen
-    shape["shape<br/><small>design-doc·architecture-diagrams</small>"]:::gen
-    threat["threat<br/><small>threat-model</small>"]:::review
-    ratify["ratify<br/><small>council-review</small>"]:::gate
-    record["record<br/><small>adr-generator</small>"]:::gen
-    G1{"G1 · review"}:::gate
-    DONE(["complete"]):::ship
-
-    constrain --> shape
-    shape --> threat
-    threat --> ratify
-    ratify --> G1
-    G1 == "PROCEED" ==> record
-    record --> DONE
-
-    G1 -- "REVISE (max 3)" --> shape
-```
-
-<!-- loop:design:end -->
-
-### `build` — a requirement to merged code
-
-A vertical slice becomes shippable code through a self-correcting loop, gated by a script whose exit code decides. The inner generate-challenge cycle is the [`feature-implement-loop`](packs/dev-team/skills/feature-implement-loop/SKILL.md) skill.
-
-<!-- loop:build:start -->
-
-```mermaid
-%%{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 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;
-
-    shape["shape<br/><small>user-story-splitter·bug-triage</small>"]:::gen
-    implement["implement<br/><small>feature-implement-loop</small>"]:::gen
-    verify["verify<br/><small>pre-merge-review</small>"]:::review
-    decide["decide<br/><small>council-review</small>"]:::gate
-    G2{"G2 · mechanical"}:::gate
-    G2_1{"G2.1 · human"}:::gate
-    DONE(["complete"]):::ship
-
-    shape --> implement
-    implement --> verify
-    verify --> G2
-    G2 == "READY" ==> decide
-    decide --> G2_1
-    G2_1 == "PROCEED" ==> DONE
-
-    G2 -- "NOT READY (max 3)" --> implement
-    G2_1 -- "REVISE (max 3)" --> shape
-```
-
-<!-- loop:build:end -->
-
-### `release` — merged code to live users
-
-Plan the rollout and the way back, judge readiness on evidence, draft the release notes, then a human makes the go/no-go call. The gap between a merge you can revert and a launch you often cannot.
-
-<!-- loop:release:start -->
-
-```mermaid
-%%{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 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;
-
-    plan["plan<br/><small>migration-plan</small>"]:::gen
-    ready["ready<br/><small>launch-readiness</small>"]:::review
-    announce["announce<br/><small>release-notes</small>"]:::gen
-    go["go<br/><small>council-review</small>"]:::gate
-    G2_5{"G2.5 · review"}:::gate
-    G2_6{"G2.6 · human"}:::gate
-    DONE(["complete"]):::ship
-
-    plan --> ready
-    ready --> G2_5
-    G2_5 == "PROCEED" ==> announce
-    announce --> go
-    go --> G2_6
-    G2_6 == "PROCEED" ==> DONE
-
-    G2_5 -- "REVISE (max 3)" --> plan
-    G2_6 -- "REVISE (max 3)" --> plan
-```
-
-<!-- loop:release:end -->
-
-### `operate` — a shipped service through detection and learning
-
-Instrument, write the runbook, communicate the incident, then feed the postmortem's runbook deltas straight back into the runbook. The one loop whose failures are live.
-
-<!-- loop:operate:start -->
-
-```mermaid
-%%{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 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;
-
-    instrument["instrument<br/><small>observability-plan</small>"]:::gen
-    document["document<br/><small>runbook-generator</small>"]:::gen
-    respond["respond<br/><small>incident-comms</small>"]:::gen
-    learn["learn<br/><small>postmortem-generator</small>"]:::review
-    G3{"G3 · human"}:::gate
-    DONE(["complete"]):::ship
-
-    instrument --> document
-    document --> respond
-    respond --> learn
-    learn --> G3
-    G3 == "PROCEED" ==> DONE
-
-    G3 -- "REVISE (max 3)" --> document
-```
-
-<!-- loop:operate:end -->
-
-### `ship-a-draft` — raw input to a stakeholder-ready artifact
-
-The wrapper: structured intake before any generator, critique and a machine-residue scrub after. Loops back through intake — not the draft — until it's approved.
-
-<!-- loop:ship-a-draft:start -->
-
-```mermaid
-%%{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 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;
-
-    intake["intake<br/><small>brief-intake</small>"]:::gen
-    draft["draft<br/><small>*</small>"]:::gen
-    critique["critique<br/><small>doc-critique</small>"]:::review
-    polish["polish<br/><small>output-hygiene</small>"]:::review
-    G4{"G4 · review"}:::gate
-    DONE(["complete"]):::ship
-
-    intake --> draft
-    draft --> critique
-    critique --> G4
-    G4 == "SHIP IT" ==> polish
-    polish --> DONE
-
-    G4 -- "MAJOR REWRITE (max 3)" --> intake
-```
-
-<!-- loop:ship-a-draft:end -->
-
-## Skills in this repo
-
-### Pipeline glue
-
-| Skill | What it does |
-|---|---|
-| [`brief-intake`](packs/core/skills/brief-intake/SKILL.md) | 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`](packs/core/skills/doc-critique/SKILL.md) | 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`](packs/core/skills/output-hygiene/SKILL.md) | 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`](packs/sre-oncall/skills/capacity-cost-model/SKILL.md) | 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`](packs/product-manager/skills/business-case/SKILL.md) | 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`](packs/product-manager/skills/requirements-interview/SKILL.md) | 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`](packs/product-manager/skills/prd-draft/SKILL.md) | 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`](packs/solution-architect/skills/nfr-spec/SKILL.md) | 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`](packs/product-manager/skills/success-metrics/SKILL.md) | 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`](packs/dev-team/skills/user-story-splitter/SKILL.md) | 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`](packs/dev-team/skills/test-plan-generator/SKILL.md) | 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`](packs/dev-team/skills/release-notes/SKILL.md) | 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`](packs/dev-team/skills/bug-triage/SKILL.md) | 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`](packs/dev-team/skills/migration-plan/SKILL.md) | 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. |
-| [`launch-readiness`](packs/dev-team/skills/launch-readiness/SKILL.md) | 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. |
-
-### 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`](packs/product-manager/skills/prfaq/SKILL.md) | 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`](packs/product-manager/skills/strategy-analysis/SKILL.md) | 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`](packs/product-manager/skills/okr-cascade/SKILL.md) | 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`](packs/dev-team/skills/feature-implement-loop/SKILL.md) | 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`](packs/dev-team/skills/pre-merge-review/SKILL.md) | 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`](packs/dev-team/skills/devils-advocate/SKILL.md) | 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`](packs/core/skills/council-review/SKILL.md) | 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`](packs/solution-architect/skills/threat-model/SKILL.md) | 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`](packs/dev-team/skills/accessibility-audit/SKILL.md) | 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`](packs/dev-team/skills/sonar-onboard/SKILL.md) | 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`](packs/dev-team/skills/sonar-review/SKILL.md) | 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`](packs/solution-architect/skills/architecture-diagrams/SKILL.md) | 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`](packs/solution-architect/skills/reverse-architecture/SKILL.md) | 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`](packs/solution-architect/skills/figma-diagrams/SKILL.md) | 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`](packs/product-manager/skills/user-journey-map/SKILL.md) | 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`](packs/solution-architect/skills/adr-generator/SKILL.md) | Generate an Architecture Decision Record in MADR or Nygard format from a context-decision-consequences brief, with sensible numbering and filename. |
-| [`design-doc`](packs/solution-architect/skills/design-doc/SKILL.md) | Generate a Google-style engineering design doc (problem → goals/non-goals → alternatives → proposal → risks → rollout) from a feature brief. |
-| [`runbook-generator`](packs/sre-oncall/skills/runbook-generator/SKILL.md) | Generate an operational runbook for a service — deploy/rollback, top 5 incident playbooks, SLOs, on-call escalation, dependencies. |
-| [`observability-plan`](packs/sre-oncall/skills/observability-plan/SKILL.md) | 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`](packs/sre-oncall/skills/postmortem-generator/SKILL.md) | 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`](packs/stakeholder-comms/skills/guide-builder/SKILL.md) | 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`](packs/solution-architect/skills/api-contract-draft/SKILL.md) | 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`](packs/solution-architect/skills/db-schema-design/SKILL.md) | 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`](packs/solution-architect/skills/data-contract/SKILL.md) | 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`](packs/solution-architect/skills/tech-comparison-matrix/SKILL.md) | 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`](packs/ai-engineering/skills/agent-loop-design/SKILL.md) | 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`](packs/ai-engineering/skills/subagent-design/SKILL.md) | 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`](packs/ai-engineering/skills/agent-budget/SKILL.md) | 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`](packs/ai-engineering/skills/agent-threat-model/SKILL.md) | 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. |
-
-| [`agents-md-generator`](packs/dev-team/skills/agents-md-generator/SKILL.md) | 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`](packs/ai-engineering/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`](packs/ai-engineering/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`](packs/ai-engineering/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`](packs/ai-engineering/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`](packs/ai-engineering/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`](packs/ai-engineering/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`](packs/ai-engineering/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. |
-
-### 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`](packs/claude-api/skills/prompt-caching-advisor/SKILL.md) | 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`](packs/claude-api/skills/token-budget-estimator/SKILL.md) | 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`](packs/claude-api/skills/eval-harness-generator/SKILL.md) | 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`](packs/claude-api/skills/tool-use-schema-writer/SKILL.md) | 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 |
-|---|---|
-| [`contribution-wizard`](packs/dev-team/skills/contribution-wizard/SKILL.md) | Guides an author through creating a new skilldrop skill from scratch — single-block intake, then one response generating the manifest, SKILL.md, 8 eval cases, README row, and pack and outcome placement. Enforces schema compliance and names the `python3 validate.py` check as the gate before opening a PR. |
-
-### Stakeholder communication
-
-| Skill | What it does |
-|---|---|
-| [`audience-profile`](packs/stakeholder-comms/skills/audience-profile/SKILL.md) | 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. |
-| [`slide-outliner`](packs/stakeholder-comms/skills/slide-outliner/SKILL.md) | Outline an architecture-review or pitch deck — slide titles, key points, and speaker notes — sized to a target time budget. Doesn't generate PPTX. |
-| [`deck-builder`](packs/stakeholder-comms/skills/deck-builder/SKILL.md) | Generate a real PowerPoint (`.pptx`) file from content + audience + a brand `.potx`/`.pptx` template or colour palette. Uses `python-pptx`; 10 layouts including charts, tables and images, audience-tuned density. Pairs naturally with `audience-profile` + `slide-outliner`. |
-| [`exec-summary`](packs/stakeholder-comms/skills/exec-summary/SKILL.md) | 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`](packs/stakeholder-comms/skills/decision-log/SKILL.md) | Extract decisions, action items, owners, and due dates from meeting notes, Slack threads, or transcripts into a structured log with source attribution. |
-| [`incident-comms`](packs/sre-oncall/skills/incident-comms/SKILL.md) | 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). |
-
-## 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](docs/rfcs/0034-physical-pack-layout.md)), 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 invokes
-```
-
-The `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).
-
-## Cost-aware model routing (provider-neutral)
-
-Different skills need different horsepower — `decision-log` is mechanical extraction, `devils-advocate` is adversarial reasoning. Running both on the same frontier model wastes money on the cheap one; running both cheap loses the hard one. So each skill carries an **abstract tier** describing the *task*, decided once:
-
-| Tier | For |
-|---|---|
-| 🟢 `light` | Mechanical mapping / extraction |
-| 🔵 `standard` | Most generation (the default) |
-| 🟣 `heavy` | Adversarial reasoning / weighted judgment (never downgraded) |
-
-The tier is **not tied to Claude.** A `providers` map in [`model-routing.json`](model-routing.json) resolves each tier to a concrete model for whatever tool you use — Claude Code, Cursor, Codex, Kiro, or anything else. Set `active_provider` to your tool and fill in its three model names (Claude Code ships filled in; the rest are templates). The same routing decisions then work everywhere.
-
-The tier lives in each skill's `manifest.json` (`model` block, travels with the skill) and in `model-routing.json` (the source of truth). [`MODEL-ROUTING.md`](MODEL-ROUTING.md) is the human-readable table, the provider setup, and the mechanical escalation rules (escalate on large/ambiguous input; honor explicit user model choice).
-
-**Three ways to use it:**
-
-- **Manual (any tool):** look up the skill's tier in [`MODEL-ROUTING.md`](MODEL-ROUTING.md) → look up your tool's model for that tier → set it → invoke the skill.
-- **Pure-rules CLI (any tool, no API key, no network):** [`route.py`](route.py) decides the tier deterministically from keyword + length signals with transparent, tunable weights, and prints the resolved model:
-
-  ```bash
-  python3 route.py --skill devils-advocate --input diff.txt
-  git diff | python3 route.py --skill sonar-review --files 12 --json
-  ```
-
-- **Automated agent (Claude Code today):** the [`model-router`](.claude/agents/model-router.md) agent — pinned to the lightest model so routing is nearly free — runs `route.py`, resolves your active provider's model, and runs the skill on a subagent at that model:
-
-  > Use the model-router agent to run `decision-log` on these meeting notes: …
-
-  Other tools read the **same table** / call the **same `route.py`**, so routing decisions are identical everywhere.
-
-Why not have an LLM pick the model live on every call? Because that pays tokens and latency *every time* to answer a question whose answer is fixed per skill. Routing is a table lookup; the model budget is spent on the work, not on deciding.
-
-## Skill packs — install a role's toolkit in one command
-
-Categories (above) say what a skill *is*; packs say *who needs it*. Each pack is a folder, [`packs/<pack>/`](packs/), and every skill and loop sits in **exactly one** of them ([RFC-0033](docs/rfcs/0033-core-pack-and-single-home-skills.md), [RFC-0034](docs/rfcs/0034-physical-pack-layout.md)). Skills every role uses live in **`core`**, and each role pack `requires` it, so installing a role pack installs `core` with it in the same command:
-
-| Pack | Skills | Loops | For |
-|---|---|---|---|
-| `core` | 4 | `ship-a-draft` | Every role: structured intake, document critique, the review council, output hygiene. Comes with every role pack |
-| `dev-team` | 14 + core | `build`, `release` | Build-and-ship: story splitting, implementation with adversarial review, test plans, triage, migrations, launch readiness, release notes, quality gates |
-| `solution-architect` | 11 + core | `design` | Design-phase artifacts: diagrams, ADRs, design docs, contracts, schemas, threat models |
-| `ai-engineering` | 11 + core | — | Adopt and build AI systems: readiness, use-case triage, rollout and policy, agent loop design, subagents, spend budgets, agent threat models, evals, usage reporting |
-| `product-manager` | 8 + core | `discover` | Direction to requirements: PR/FAQs, strategy frameworks, OKRs, business cases, interviews, PRDs, journey maps, success measurement |
-| `stakeholder-comms` | 6 + core | — | Non-technical audiences: audience profiling, deck outlines and real `.pptx` decks, exec summaries, decision logs, guides |
-| `sre-oncall` | 5 + core | `operate` | Operate the service: runbooks, observability design, incident comms, postmortems, capacity/cost models |
-| `claude-api` | 4 | — | Build on the Anthropic API: prompt caching strategy, token budgeting, eval generation for skills, tool-use schema writing. A specialist add-on; it does not bring core |
-
-Every pack has a page with **what to try first**, how to tell it worked, and what to do if nothing happens: [sananthanarayan.github.io/skilldrop/packs/](https://sananthanarayan.github.io/skilldrop/packs/). The CLI prints the same thing after a pack install, or any time with `npx skilldrop-cli info --pack <name>` ([RFC-0032](docs/rfcs/0032-pack-landing-pages-and-safe-updates.md)).
-
-```bash
-python3 pack.py                                  # list packs
-python3 pack.py product-manager                  # list a pack's skills
-python3 pack.py product-manager --install        # install into ~/.claude/skills/ (user scope)
-python3 pack.py product-manager --install --project      # into .claude/skills/ (project scope)
-python3 pack.py product-manager --install --dest .cursor/skills   # any dir, for non-Claude IDEs
+```text
+messy input → a skill with a quality bar → a gate that can say no → your decision
 ```
 
-For non-Claude IDEs, `--dest` drops the folders where your tool expects them; the per-IDE wiring steps below still apply. A skill is still one self-contained folder, so a per-skill copy works the same as before; only the path changed, to `cp -R packs/<pack>/skills/<name> …` ([RFC-0034](docs/rfcs/0034-physical-pack-layout.md)). A pack's metadata — description, what it `requires`, what to try first — is in `packs/<pack>/pack.json`.
-
-## Outcomes — browse by why you're here
-
-Packs answer *who am I*. Outcomes answer *why did I open this*. The seven below are the nine
-categories above, restated as the things people actually arrive wanting to do, and they live in
-the `outcomes` block of [`catalogue.json`](catalogue.json) so the [catalogue site](https://sananthanarayan.github.io/skilldrop/)
-can filter on them. Every skill belongs to at least one; `validate.py` enforces it.
+[Browse the packs](https://sananthanarayan.github.io/skilldrop/packs/) · [Search all skills](https://sananthanarayan.github.io/skilldrop/catalogue/) · [Docs](https://sananthanarayan.github.io/skilldrop/docs/) · [Install options](guides/how-to/install.md) · [Contribute](CONTRIBUTING.md)
 
-| Outcome | Skills | What it covers |
-|---|---|---|
-| `design-the-system` | 15 | Decision records, design docs, diagrams, contracts, schemas, migration and threat models, agentic design |
-| `decide-what-to-build` | 11 | Press releases, strategy frameworks, OKRs, business cases, requirements, PRDs, success metrics |
-| `build-and-review-software` | 11 | Supervised implementation, review panels, test plans, triage, accessibility and static-analysis passes |
-| `explain-it-to-decision-makers` | 6 | Audience profiling, deck outlines and real decks, exec summaries, decision logs, guides |
-| `govern-ai-use` | 6 | Readiness, use-case triage, rollout, acceptable-use policy, adoption staging, usage reporting |
-| `run-and-recover-the-service` | 5 | Runbooks, observability design, release notes, incident comms, postmortems |
-| `get-a-draft-ready-to-ship` | 3 | Collect a messy input, critique the argument, strip the machine artifacts |
+## Choose your role
 
-Outcomes are a browse aid, not an install unit — there is no `--outcome` flag. Install by skill
-or by pack.
+Install one pack. Every role pack also brings `core` (intake, critique, review council, output hygiene). Each pack page has a starter prompt to paste and says what a good result looks like.
 
-## Installing a skill into your IDE
+- **Product managers:** `product-manager` — PR/FAQs, strategy, OKRs, business cases, PRDs, success metrics. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/product-manager/)
+- **Architects:** `solution-architect` — diagrams, ADRs, design docs, API and data contracts, threat models. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/solution-architect/)
+- **Software teams:** `dev-team` — story splitting, implementation with adversarial review, merge gates, launch readiness, release notes. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/dev-team/)
+- **SRE and on-call:** `sre-oncall` — observability, runbooks, incident comms, postmortems, capacity. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/sre-oncall/)
+- **Explaining things to decision-makers:** `stakeholder-comms` — audience profiles, exec summaries, decision logs, guides. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/stakeholder-comms/)
+- **On-brand decks and flyers:** `design` — capture your brand once, then build `.pptx` decks and print-ready flyers with your logo, colours and fonts. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/design/)
+- **Adopting and building AI:** `ai-engineering` — readiness, use-case triage, policy, agent loops, budgets, agent threat models, evals. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/ai-engineering/)
+- **Building on the Claude API:** `claude-api` — prompt caching, token budgets, eval generation, tool schemas. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/claude-api/)
+- **Everyone:** `core` on its own. [Open pack](https://sananthanarayan.github.io/skilldrop/packs/core/)
 
-### Quickest: the skilldrop CLI
-
-The repo ships as the npm package **`skilldrop-cli`** (command: `skilldrop`) — a zero-dependency installer that copies skills byte-identical into your tool's location, and writes a pointer file only where the tool needs one to find them (Cursor):
+## Start in one command
 
 ```bash
-npx skilldrop-cli install --pack product-manager        # Claude Code, user scope (~/.claude/skills)
-npx skilldrop-cli install --pack dev-team --project     # .claude/skills — also read by GitHub Copilot CLI
-npx skilldrop-cli install prfaq --ide cursor            # + writes .cursor/rules/prfaq.mdc
-npx skilldrop-cli install --pack sre-oncall --ide kiro  # .kiro/skills — Kiro IDE + Kiro CLI, discovered natively
-npx skilldrop-cli install adr-generator --dest .agents/skills   # Codex + Copilot CLI (see below)
-npx skilldrop-cli loops                                 # the six loops, their stages and gates
-npx skilldrop-cli install --loop build                  # a loop + every stage skill it sequences (RFC-0028)
-npx skilldrop-cli install --loop --pack sre-oncall      # every loop that pack declares
-npx skilldrop-cli agents                                # the reviewer subagents
-npx skilldrop-cli install --agent devils-advocate       # -> ~/.claude/agents/ (RFC-0012)
-npx skilldrop-cli install --panel review                # the whole review fleet: 3 subagents + the pre-merge-review orchestrator (RFC-0020)
-npx skilldrop-cli outdated && npx skilldrop-cli update  # skills improve; files you edited are kept, new copy as <file>.upstream
-npx skilldrop-cli list | skilldrop info <skill> | skilldrop info --pack <name> | skilldrop packs | skilldrop uninstall <skill>
-npx skilldrop-cli list --json                            # machine-readable: list/info/packs/agents/outdated (RFC-0021)
-```
-
-`--loop` installs a loop as an invokable skill (its `LOOP.md` is already `SKILL.md`-shaped) plus the skills its stages name — add `--no-skills` for the loop alone, which still runs because each stage degrades through its declared `fallback`. `--with-related` also pulls each skill's companions. From a clone (or before the package is published): `node bin/skilldrop.js <same args>`. Scope and design: [RFC-0002](docs/rfcs/0002-skilldrop-cli.md), full command surface in [`docs/designs/skilldrop-cli-design.md`](docs/designs/skilldrop-cli-design.md).
-
-### Or: the Claude Code plugin marketplace
-
-skilldrop is also a **Claude Code plugin marketplace** — one marketplace, nine plugins (the whole catalogue, plus one per pack), no npm step. Add it once:
-
-```text
-/plugin marketplace add sananthanarayan/skilldrop
+npx skilldrop-cli install --pack dev-team
 ```
 
-Then take the whole catalogue, or just your role's pack:
+The install prints a starter prompt for the pack. For `dev-team`, ask your agent:
 
 ```text
-/plugin install skilldrop@skilldrop             # all 63 skills + 3 reviewer subagents
-/plugin install dev-team@skilldrop              # 18 skills (incl. core) + the 3 reviewer subagents
-/plugin install solution-architect@skilldrop    # 15 skills (incl. core)
-/plugin install ai-engineering@skilldrop        # 15 skills (incl. core)
-/plugin install product-manager@skilldrop       # 12 skills (incl. core)
-/plugin install stakeholder-comms@skilldrop     # 10 skills (incl. core)
-/plugin install sre-oncall@skilldrop            # 9 skills (incl. core)
-/plugin install claude-api@skilldrop            # 4 skills
-/plugin install core@skilldrop                  # 4 skills, on their own
-```
-
-Every skill then invokes as `/<plugin>:<name>` (e.g. `/skilldrop:prfaq`). The whole-catalogue plugin is the repo root itself: its `plugin.json` lists each `packs/<pack>/skills/` folder, and `agents/` sits at the root — same copy-install premise, expressed in Claude's own plugin format.
-
-The eight **pack plugins** work differently, because a plugin's skills have to sit in a `skills/` folder inside the plugin. A role pack's plugin also has to carry `core`'s skills and loops, since a plugin installs on its own and cannot reach outside its folder. Rather than copy `core` into every pack folder on `main`, the marketplace entries use Claude's `git-subdir` source to point at `packs/<name>/` on a generated [`plugins`](https://github.com/sananthanarayan/skilldrop/tree/plugins) branch, rebuilt by CI on every push to main, where each pack is assembled with `core` folded in. You still only ever type the one `marketplace add`. A pack carries the reviewer subagents its own skills delegate to, so `dev-team` brings the review panel and `sre-oncall` does not.
-
-`.claude-plugin/{marketplace,plugin}.json` are generated from `package.json` + the `packs/` folders by [`build_marketplace.py`](build_marketplace.py) (`--check` guards drift in CI; `--dist` renders the branch). Use the CLI above when you want per-skill granularity, another IDE, or hooks; use the marketplace when you're in Claude Code. Rationale: [RFC-0027](docs/rfcs/0027-retire-agentbundle-export.md).
-
-### Everything else about installing
-
-The long-form install material moved to [`guides/`](guides/) so this page stays scannable:
-
-| If you want to | Read |
-|---|---|
-| Install by hand into a specific IDE | [Install a skill into your IDE](guides/how-to/install-per-ide.md) |
-| Wire a skill to an event (opt-in hooks) | [Wire a skill to an event](guides/how-to/wire-a-hook.md) |
-| Publish your own catalogue for `--from` | [Publish your own catalogue](guides/how-to/publish-a-catalogue.md) |
-| Use the two skills that ship scripts | [Skills that ship scripts](guides/reference/skills-with-scripts.md) |
-| Add a skill or a loop to this repo | [Author a skill](guides/how-to/author-a-skill.md) · [Author a loop](guides/how-to/author-a-loop.md) |
-| Understand why it is built this way | [Why loops](guides/explanation/loops.md) · [ARCHITECTURE.md](ARCHITECTURE.md) |
-| See one change go through the loops | [Follow one change through the loops](guides/tutorial/follow-a-change-through-the-loops.md) |
-| Point a model at this repo | [`llms.txt`](llms.txt) — a generated index so a tool reads the few relevant pages instead of the tree |
-
-### Reviewer subagents
-
-Three personas you delegate review to, rather than invoke as a skill: [`devils-advocate`](agents/devils-advocate.md) ("will this break?"), [`code-quality`](agents/code-quality.md) ("will the next engineer hate this?") and [`security-reviewer`](agents/security-reviewer.md) ("how would someone abuse this?"). A subagent runs in its own context with its own tool allowlist — a contract a skill can't express — which is why they live in [`agents/`](agents/) instead of a pack's `skills/`.
-
-```bash
-npx skilldrop-cli agents                                    # list them
-npx skilldrop-cli install --agent devils-advocate           # ~/.claude/agents/
-npx skilldrop-cli install --agent code-quality --project    # .claude/agents/, shared with the repo
+Is this branch safe to merge? Run a pre-merge review on the current diff.
 ```
 
-Then delegate by name: *"use the devils-advocate agent on this diff."*
-
-Six targets, each projecting only as much as the tool's format demands:
-
-| Target | Writes | Projection |
-|---|---|---|
-| *(default)* | `~/.claude/agents/<name>.md` | none — the file already is Claude Code's format |
-| `--ide copilot` | `.github/agents/<name>.agent.md` | a rename |
-| `--ide kiro` | `.kiro/agents/<name>.json` | generated JSON; tool names mapped to Kiro's built-ins |
-| `--ide codex` | `~/.codex/agents/<name>.toml` (`--project` for repo) | generated TOML |
-| `--ide antigravity` | `~/.gemini/config/agents/<name>.md` (`--project` → `.agents/agents/`) | frontmatter rewritten, `subagent: true` added |
-| `--dest <dir>` | `<dir>/<name>.md` | none |
-
-The Kiro emitter maps `Read`/`Grep`/`Glob`/`Bash` to `read`/`grep`/`glob`/`shell` against [Kiro's built-in tool reference](https://kiro.dev/docs/cli/reference/built-in-tools/), and **names any tool it can't map instead of dropping it silently** — a mistranslated permission is worse than a missing one. It omits `allowedTools` so you're prompted per tool call.
-
-Each generated target omits the permission field it cannot map safely rather than guessing one: Kiro's `allowedTools` and Codex's `sandbox_mode` are both left unset, so an agent inherits the session's permissions and is prompted per call. A widened permission nobody asked for is worse than an extra prompt.
+A good result runs your lint, typecheck and tests through a gate script, then a reviewer panel, and ends with `READY` or `NOT READY`. To see any pack's starter, run `npx skilldrop-cli info --pack <name>`.
 
-**Every surveyed tool now installs.** Only Cursor is absent, because it has no agent file format at all — use a custom mode ([`agents/README.md`](agents/README.md) has the steps).
+In Claude Code you can use the plugin marketplace instead: run `/plugin marketplace add sananthanarayan/skilldrop`, then `/plugin install dev-team@skilldrop`. [Every install route](guides/how-to/install.md) covers single skills, other IDEs, loops, reviewer subagents, profiles and updates.
 
-## Reviewer agents
+## How it works
 
-The [`agents/`](agents/) folder ships **portable reviewer personas** — single-file agents you delegate code and test review to, packaged in Claude Code subagent format (frontmatter + system prompt) but written so the body pastes into Cursor, Codex, Kiro, Continue, Cline, or Aider just as cleanly.
+- **A skill produces one file you own.** Each ships a quality bar, named anti-patterns and acceptance evals, so the output is an artifact, not a conversation. See [every skill, by category](guides/reference/skill-catalogue.md).
+- **Loops order skills, and a gate decides when work moves on.** Five loops cover the lifecycle (`discover`, `design`, `build`, `release`, `operate`), plus the `ship-a-draft` wrapper for any document. Each gate is a script, a review panel or a person, chosen by how expensive the mistake is to undo. See [the loops, stage by stage](guides/reference/loops.md) and [why loops](guides/explanation/loops.md).
+- **Copy, never transform.** A skill is a plain `SKILL.md` folder in the [Agent Skills](https://agentskills.io) format, at `packs/<pack>/skills/<name>/`. What runs in your agent is byte-identical to what is reviewed here. There is no runtime, and the tooling has zero dependencies.
+- **Updates keep your edits.** `npx skilldrop-cli update` replaces files you haven't touched. For any file you changed, it leaves the new version beside it as `<file>.upstream`. See [upgrade installed skills](guides/how-to/upgrade-skills.md).
 
-| Agent | Reviews for | Question it answers |
-|---|---|---|
-| [`devils-advocate`](agents/devils-advocate.md) | Correctness — edge cases, broken assumptions, staff-engineer pushback, test gaps | "Will this break?" |
-| [`code-quality`](agents/code-quality.md) | Craft — naming, structure, duplication, complexity, readability | "Will the next engineer hate this?" |
-| [`security-reviewer`](agents/security-reviewer.md) | Exploitability — injection, authz gaps, secret handling, unsafe deserialisation | "How would someone abuse this?" |
+## Go deeper
 
-No tool auto-discovers a folder named `agents/`; it's the canonical source of truth. See [`agents/README.md`](agents/README.md) for where to copy each file in your tool — `.claude/agents/` for Claude Code, a custom mode for Cursor, an `AGENTS.md` section for Codex, a steering file or custom agent for Kiro.
+- **Use it:** [docs portal](https://sananthanarayan.github.io/skilldrop/docs/) · [install in any IDE](guides/how-to/install-per-ide.md) · [profiles](guides/how-to/profiles.md) · [hooks](guides/how-to/wire-a-hook.md) · [publish your own catalogue](guides/how-to/publish-a-catalogue.md)
+- **Reviewers:** three subagents that push back on generated work: `devils-advocate`, `security-reviewer` and `code-quality`. See [`agents/`](agents/README.md).
+- **Cost:** each skill declares a provider-neutral model tier (`light`, `standard` or `heavy`). See [MODEL-ROUTING.md](MODEL-ROUTING.md).
+- **How it is built:** [ARCHITECTURE.md](ARCHITECTURE.md) · [machine-readable contracts](contracts/) · [decision records](docs/rfcs/) · [`llms.txt`](llms.txt) for tools
+- **Contribute:** [CONTRIBUTING.md](CONTRIBUTING.md) · [author a skill](guides/how-to/author-a-skill.md) · [author a loop](guides/how-to/author-a-loop.md) · [repository conventions](AGENTS.md)
 
 ## License