skilldrop-cli 0.13.2 → 0.13.3

package/README.md

@@ -20,7 +20,7 @@ Every skill is a plain `SKILL.md` folder — the [**Agent Skills open standard**
 
 ## 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: [`loops/<name>/LOOP.md`](loops/) 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.**
+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.
 
@@ -28,17 +28,17 @@ Five loops cover the lifecycle, and they are separated by **reversibility** —
 
 | Loop | Takes | Gate | Produces | Mistake costs |
 |---|---|---|---|---|
-| [`discover`](loops/discover/LOOP.md) | interviews, journeys, a strategy question | **G0** human — a person ratifies the brief | a ratified requirement | a re-brief |
-| [`design`](loops/design/LOOP.md) | a ratified requirement | **G1** review — `council-review`'s panel | a recorded decision (ADR) | months, unwound in code |
-| [`build`](loops/build/LOOP.md) | an agreed requirement or triaged defect | **G2** mechanical — `pre-merge-review`'s gate script decides | merged code | a revert |
-| [`release`](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`](loops/operate/LOOP.md) | a shipped service | **G3** human — the incident is closed | a postmortem and runbook deltas | live users, irreversible |
+| [`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`](loops/ship-a-draft/LOOP.md) | raw notes, a transcript, a ticket | **G4** review — `doc-critique`'s verdict | a stakeholder-ready artifact |
+| [`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. Both diagrams render on GitHub; the Mermaid sources live in [`docs/`](docs/) for easy re-rendering.
 
@@ -112,7 +112,7 @@ flowchart LR
 
 ### `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`](skills/feature-implement-loop/SKILL.md) skill.
+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 -->
 
@@ -250,9 +250,9 @@ flowchart LR
 
 | Skill | What it does |
 |---|---|
-| [`brief-intake`](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`](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`](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. |
+| [`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
 
@@ -260,18 +260,18 @@ Skills for the SDLC steps around the code itself — turning raw requirements in
 
 | Skill | What it does |
 |---|---|
-| [`capacity-cost-model`](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`](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`](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`](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`](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`](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`](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`](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`](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`](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`](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`](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. |
+| [`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
 
@@ -279,46 +279,46 @@ Skills for the direction-setting layer above any single feature — testing whet
 
 | Skill | What it does |
 |---|---|
-| [`prfaq`](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`](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`](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. |
+| [`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`](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`](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`](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`](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`](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`](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`](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`](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`. |
+| [`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`](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`](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`](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`](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`. |
+| [`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`](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`](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`](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`](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`](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`](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`](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`](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`](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`](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. |
+| [`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
 
@@ -326,24 +326,24 @@ Designing the agentic systems themselves — the loops, orchestrations, and budg
 
 | Skill | What it does |
 |---|---|
-| [`agent-loop-design`](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`](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`](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`](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. |
+| [`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`](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. |
+| [`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`](skills/agent-adoption-stage/SKILL.md) | Place an engineering team on the agentic-coding ladder — **0 gated → 1 assisted (~1 agent) → 2 parallel (~10) → 3 supervised autonomy (~100) → 4 intent-steered (~1000+)** — from observables (agents in flight, who writes the code, what still gets reviewed), never from licence counts or ambition. The load-bearing idea is that **the bottleneck moves**: your attention → review throughput → trust in the loop → finding the work to automate, so the fix that unlocked the last step does nothing for the next. Forces **exactly one stage** and **exactly one unlock**, names the guardrail to *retire* (reading every diff is right at stage 1 and arithmetically impossible at stage 3), and routes each unlock to the skill that implements it (`pre-merge-review`, `agent-loop-design`, `subagent-design`, `agent-budget`). Adapted from Boris Cherny's *Steps of AI Adoption*, stated as capabilities rather than products so it survives the next vendor release. |
-| [`ai-readiness-assessment`](skills/ai-readiness-assessment/SKILL.md) | Score readiness to adopt AI across **six fixed dimensions** — data, tooling, skills, governance, process, culture — each 0–4 with a **one-line evidence reference**, or `[insufficient evidence]` rather than a guessed middle number. Gaps are ranked by **what blocks first**, not by lowest score, with the dependency named ("Skills can't move until Tooling ≥ 2"), and each carries a first action and an owner *role*. Ends with a posture sentence that takes a position and names what would change it — never a bare maturity label, because "you are Level 2 of 5" is not something a leader can fund. |
-| [`ai-use-case-triage`](skills/ai-use-case-triage/SKILL.md) | Rank candidate AI use cases on value × feasibility × risk with the **weights shown** (default 40/35/25). Each candidate is restated as *a workflow and a person*, never a technology; feasibility asks whether the output can be **verified before it matters**, not whether a model can produce it. Produces a recommended first slice with an **observable kill condition** and a time box, plus a mandatory **not-yet list** where every rejection carries the condition that would promote it. A portfolio with no rejections hasn't triaged anything. |
-| [`ai-adoption-rollout`](skills/ai-adoption-rollout/SKILL.md) | Plan the **human** rollout (the counterpart to `migration-plan`'s technical one) — cohorts smallest-first with a reason each is next, per-cohort hands-on enablement built from what the pilot actually got stuck on, champions as roles **with protected hours**, and an adoption **gate per wave** (observable + threshold + bake time + rollback). The comms plan must state explicitly **what will not change** about headcount and evaluation; silence there is read as bad news and is the biggest driver of quiet non-adoption. Licences activated is not adoption. |
-| [`ai-usage-policy`](skills/ai-usage-policy/SKILL.md) | Draft the organisation-wide acceptable-use policy — **three** data tiers (five aren't memorable at the moment of pasting) with concrete examples from *this* org, permitted/prohibited uses stated as behaviours, and a human-review matrix keyed to **consequence** rather than to model names that age out in months. Every prohibition names a permitted alternative, because a ban with no sanctioned path moves the work to personal accounts where you can't see it — and there's always an exception route with a turnaround time. |
-| [`ai-usage-report`](skills/ai-usage-report/SKILL.md) | Turn a CSV/JSONL of AI usage events (exported from an MCP server or other telemetry source) into a per-user, team-rollup, or effectiveness-focused report. Surfaces volume, breadth, session depth, and — where the data supports it — whether AI outputs were actually consumed in shipped artifacts vs generated and discarded (the "AI theater" question). Refuses to generate an aggregate rollup for teams smaller than 5 to preserve anonymity. |
-| [`llm-eval-harness`](skills/llm-eval-harness/SKILL.md) | Design the **dev-loop quality gate** for an LLM-powered feature (prompt, RAG, agent, classifier) — so prompt and model changes ship on numbers, not vibes. A versioned golden set in three deliberate buckets (representative from real logs, adversarial/edge, and regression cases frozen from every past failure); the **cheapest adequate grading method per case** (programmatic → structured assertions → LLM-as-judge only when quality is genuinely subjective, and then validated against human labels with bias controls); a metric matched to the task with **both gates set before the first run** (no-regression + critical-subset-at-100%); a failure taxonomy that points iteration at the biggest bucket; and cost/latency tracked beside quality. Enforces the held-out split and the no-tuning-on-test rule. Provider-neutral. |
+| [`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
 
@@ -351,34 +351,34 @@ Skills for teams building directly on the Anthropic API — prompt caching strat
 
 | Skill | What it does |
 |---|---|
-| [`prompt-caching-advisor`](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`](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`](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 `skills/<name>/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`](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. |
+| [`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`](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 packs.json addition. Enforces schema compliance and names the `python3 validate.py` check as the gate before opening a PR. |
+| [`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`](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`](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`](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`](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`](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`](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). |
+| [`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:
+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.
 
 ```
-skills/<skill-name>/
+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
@@ -425,7 +425,7 @@ Why not have an LLM pick the model live on every call? Because that pays tokens
 
 ## Skill packs — install a role's toolkit in one command
 
-Categories (above) say what a skill *is*; packs say *who needs it*. [`packs.json`](packs.json) gives every skill and every loop **exactly one home** ([RFC-0033](docs/rfcs/0033-core-pack-and-single-home-skills.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:
+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 |
 |---|---|---|---|
@@ -438,6 +438,8 @@ Categories (above) say what a skill *is*; packs say *who needs it*. [`packs.json
 | `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
@@ -446,13 +448,13 @@ python3 pack.py product-manager --install --project      # into .claude/skills/
 python3 pack.py product-manager --install --dest .cursor/skills   # any dir, for non-Claude IDEs
 ```
 
-For non-Claude IDEs, `--dest` drops the folders where your tool expects them; the per-IDE wiring steps below still apply. Packs are metadata only — skills stay in flat `skills/<name>` folders, so per-skill `cp -R` installs keep working unchanged ([RFC-0001](docs/rfcs/0001-skill-packs.md) records the original decision; [RFC-0033](docs/rfcs/0033-core-pack-and-single-home-skills.md) replaced its overlapping packs with `core` and one home per skill).
+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 [`packs.json`](packs.json) so the [catalogue site](https://sananthanarayan.github.io/skilldrop/)
+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.
 
 | Outcome | Skills | What it covers |
@@ -487,7 +489,7 @@ 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 packs | skilldrop uninstall <skill>
+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)
 ```
 
@@ -515,11 +517,11 @@ Then take the whole catalogue, or just your role's pack:
 /plugin install core@skilldrop                  # 4 skills, on their own
 ```
 
-Every skill then invokes as `/<plugin>:<name>` (e.g. `/skilldrop:prfaq`). The whole-catalogue plugin ships the flat `skills/` and `agents/` trees at the repo root unchanged — same copy-install premise, expressed in Claude's own plugin format.
+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. Rather than duplicate every skill into eight directories on `main` — physical packs, which [RFC-0001](docs/rfcs/0001-skill-packs.md) rejected — 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. Nothing moves in the source tree, and you still only ever type the one `marketplace add`. Each role pack's plugin also carries `core`'s skills and loops, since a plugin installs on its own. A pack carries the reviewer subagents its own skills delegate to, so `dev-team` brings the review panel and `sre-oncall` does not.
+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` + `packs.json` 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).
+`.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
 

package/agents/README.md

@@ -24,7 +24,7 @@ npx skilldrop-cli install --agent devils-advocate --ide kiro   # .kiro/agents/*.
 | [`code-quality`](code-quality.md) | Craft — naming, structure, duplication, needless complexity, readability | "Will the next engineer hate this?" |
 | [`security-reviewer`](security-reviewer.md) | Security — authz, injection, secret exposure, SSRF, unsafe deserialization, weak crypto, risky deps | "What can an attacker do with this?" |
 
-They are deliberately **split, not merged.** A single "review my code" agent dilutes all three — bug-hunting, craft, and exploitability pull in different directions. Run them as separate passes; together they are the reviewer panel [`feature-implement-loop`](../skills/feature-implement-loop/SKILL.md) drives after each generation round. `devils-advocate` here is the subagent form of the [`devils-advocate` skill](../skills/devils-advocate/SKILL.md); same persona, packaged for a tool's native agent slot instead of on-demand skill invocation.
+They are deliberately **split, not merged.** A single "review my code" agent dilutes all three — bug-hunting, craft, and exploitability pull in different directions. Run them as separate passes; together they are the reviewer panel [`feature-implement-loop`](../packs/dev-team/skills/feature-implement-loop/SKILL.md) drives after each generation round. `devils-advocate` here is the subagent form of the [`devils-advocate` skill](../packs/dev-team/skills/devils-advocate/SKILL.md); same persona, packaged for a tool's native agent slot instead of on-demand skill invocation.
 
 ## Fire them as a panel
 
@@ -35,7 +35,7 @@ npx skilldrop-cli install --panel review            # 3 subagents + the pre-merg
 npx skilldrop-cli install --panel review --project  # .claude/ (shared with the repo)
 ```
 
-The [`pre-merge-review`](../skills/pre-merge-review/SKILL.md) skill is the **portable orchestrator** — it dispatches the three as **parallel subagents** where the tool has a native subagent runner, and sweeps the lenses inline otherwise. The orchestration lives in the *skill* (portable); the reviewers are *native subagents* (per-tool):
+The [`pre-merge-review`](../packs/dev-team/skills/pre-merge-review/SKILL.md) skill is the **portable orchestrator** — it dispatches the three as **parallel subagents** where the tool has a native subagent runner, and sweeps the lenses inline otherwise. The orchestration lives in the *skill* (portable); the reviewers are *native subagents* (per-tool):
 
 | Tool | How the panel fires in parallel |
 |---|---|
@@ -46,7 +46,7 @@ The [`pre-merge-review`](../skills/pre-merge-review/SKILL.md) skill is the **por
 | **Copilot** | Agents install (`--agent … --ide copilot`); the skill drives them — sequentially unless your Copilot build exposes parallel subagents. |
 | **Cursor** | No agent format — `pre-merge-review` sweeps the three lenses inline (no subagents). |
 
-Designing your own fleet? Use [`subagent-design`](../skills/subagent-design/SKILL.md) — the reviewer panel is its "judge panel" topology.
+Designing your own fleet? Use [`subagent-design`](../packs/ai-engineering/skills/subagent-design/SKILL.md) — the reviewer panel is its "judge panel" topology.
 
 ## Installing an agent into your tool