skilldrop-cli 0.13.1 → 0.13.2

package/README.md

@@ -8,8 +8,8 @@
 **63 portable AI-agent skills for the deliverables knowledge workers actually ship** — diagrams, design docs, ADRs, PRDs, runbooks, decks, decision logs, threat models, adversarial reviews — installable into **Claude Code**, **Cursor**, **Kiro**, **Codex**, **GitHub Copilot**, and any AI tool that accepts custom instructions, one skill or one role-based pack at a time:
 
 ```bash
-npx skilldrop-cli install --pack product-manager     # or: solution-architect, dev-team,
-npx skilldrop-cli list                               #     sre-oncall, stakeholder-comms, ai-engineering, claude-api
+npx skilldrop-cli install --pack product-manager     # or: solution-architect, dev-team, sre-oncall,
+npx skilldrop-cli list                               #     stakeholder-comms, ai-engineering, claude-api (each brings core)
 ```
 
 Originally scoped to solution architects, now broadly useful to PMs, founders, consultants, engineering leaders, exec assistants — anyone who turns ideas into stakeholder-ready artifacts.
@@ -425,17 +425,18 @@ 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) defines six role-based bundles — packs overlap where a skill serves several roles, and every skill belongs to at least one:
+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:
 
-| Pack | Skills | For |
-|---|---|---|
-| `solution-architect` | 17 | Design-phase artifacts: diagrams, ADRs, design docs, contracts, schemas, threat models, and the reviews that gate them |
-| `dev-team` | 14 | Build-and-ship loop: implementation with adversarial review, test plans, triage, migrations, release notes, quality gates, pre-ship hygiene |
-| `product-manager` | 13 | Direction to requirements: PR/FAQs, strategy frameworks, OKRs, PRDs, journey maps, story splitting, success measurement |
-| `ai-engineering` | 12 | Build and run AI systems: agent loop design, subagent orchestration, spend budgets, eval harnesses, usage reporting, data contracts |
-| `stakeholder-comms` | 9 | Non-technical audiences: audience profiling, deck outlines and real `.pptx` decks, exec summaries, decision logs, guides |
-| `sre-oncall` | 5 | 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 |
+| Pack | Skills | Loops | For |
+|---|---|---|---|
+| `core` | 4 | `ship-a-draft` | Every role: structured intake, document critique, the review council, output hygiene. Comes with every role pack |
+| `dev-team` | 14 + core | `build`, `release` | Build-and-ship: story splitting, implementation with adversarial review, test plans, triage, migrations, launch readiness, release notes, quality gates |
+| `solution-architect` | 11 + core | `design` | Design-phase artifacts: diagrams, ADRs, design docs, contracts, schemas, threat models |
+| `ai-engineering` | 11 + core | — | Adopt and build AI systems: readiness, use-case triage, rollout and policy, agent loop design, subagents, spend budgets, agent threat models, evals, usage reporting |
+| `product-manager` | 8 + core | `discover` | Direction to requirements: PR/FAQs, strategy frameworks, OKRs, business cases, interviews, PRDs, journey maps, success measurement |
+| `stakeholder-comms` | 6 + core | — | Non-technical audiences: audience profiling, deck outlines and real `.pptx` decks, exec summaries, decision logs, guides |
+| `sre-oncall` | 5 + core | `operate` | Operate the service: runbooks, observability design, incident comms, postmortems, capacity/cost models |
+| `claude-api` | 4 | — | Build on the Anthropic API: prompt caching strategy, token budgeting, eval generation for skills, tool-use schema writing. A specialist add-on; it does not bring core |
 
 ```bash
 python3 pack.py                                  # list packs
@@ -445,7 +446,7 @@ 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 design decision).
+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).
 
 ## Outcomes — browse by why you're here
 
@@ -485,7 +486,7 @@ npx skilldrop-cli install --loop --pack sre-oncall      # every loop that pack d
 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; cp -R never tells you
+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 --json                            # machine-readable: list/info/packs/agents/outdated (RFC-0021)
 ```
@@ -504,17 +505,19 @@ Then take the whole catalogue, or just your role's pack:
 
 ```text
 /plugin install skilldrop@skilldrop             # all 63 skills + 3 reviewer subagents
-/plugin install solution-architect@skilldrop    # 17 skills
-/plugin install dev-team@skilldrop              # 14 skills + the 3 reviewer subagents
-/plugin install product-manager@skilldrop       # 13 skills
-/plugin install ai-engineering@skilldrop        # 12 skills
-/plugin install stakeholder-comms@skilldrop     # 9 skills
-/plugin install sre-oncall@skilldrop            # 5 skills
+/plugin install dev-team@skilldrop              # 18 skills (incl. core) + the 3 reviewer subagents
+/plugin install solution-architect@skilldrop    # 15 skills (incl. core)
+/plugin install ai-engineering@skilldrop        # 15 skills (incl. core)
+/plugin install product-manager@skilldrop       # 12 skills (incl. core)
+/plugin install stakeholder-comms@skilldrop     # 10 skills (incl. core)
+/plugin install sre-oncall@skilldrop            # 9 skills (incl. core)
+/plugin install claude-api@skilldrop            # 4 skills
+/plugin install core@skilldrop                  # 4 skills, on their own
 ```
 
 Every skill then invokes as `/<plugin>:<name>` (e.g. `/skilldrop:prfaq`). The whole-catalogue plugin ships the flat `skills/` and `agents/` trees at the repo root unchanged — same copy-install premise, expressed in Claude's own plugin format.
 
-The six **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 six 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`. 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. 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.
 
 `.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).
 

package/bin/skilldrop.js

@@ -13,6 +13,7 @@ const fs = require("fs");
 const path = require("path");
 const os = require("os");
 const { execFileSync } = require("child_process");
+const crypto = require("crypto");
 
 const ROOT = path.resolve(__dirname, "..");
 const LEDGER = ".skilldrop.json";
@@ -48,7 +49,9 @@ Usage:
                                           (--no-skills for the loop alone) (RFC-0028)
   skilldrop install --panel review        install the review panel — the 3 reviewer subagents +
                                           the pre-merge-review orchestrator that fires them (RFC-0020)
-  skilldrop update                        re-copy installed skills whose version changed
+  skilldrop update [--force]              re-copy installed skills whose version changed; files
+                                          you edited are kept and the new copy lands beside them
+                                          as <file>.upstream (--force overwrites) (RFC-0032)
   skilldrop outdated                      show installed vs current versions, change nothing
   skilldrop uninstall <skill...>          remove skills (and wiring files this tool wrote)
   skilldrop uninstall --agent <name...>   remove subagents
@@ -264,6 +267,15 @@ function packsOf(cat) {
   const p = path.join(cat.dir, "packs.json");
   return fs.existsSync(p) ? readJSON(p).packs : null;
 }
+/* RFC-0033: a pack installs together with the packs it `requires` (in practice, core), so
+   one --pack still delivers a role's whole toolkit now that shared skills have one home. */
+function packMembers(ps, name, key) {
+  const req = (ps[name].requires || []).filter((r) => ps[r]);
+  const out = [];
+  for (const n of [...req, name]) for (const x of ps[n][key] || []) if (!out.includes(x)) out.push(x);
+  if (req.length) console.log(`pack '${name}' includes ${req.join(", ")}`);
+  return out;
+}
 function profilesOf(cat) {
   const p = path.join(cat.dir, "profiles.json");
   return fs.existsSync(p) ? readJSON(p).profiles : null;
@@ -709,7 +721,7 @@ function expandNames(args, cat) {
     if (!ps) die(`catalog '${cat.source}' has no packs.json — install skills by name`);
     const p = ps[args.flags.pack];
     if (!p) die(`unknown pack '${args.flags.pack}' in catalog '${cat.source}'`);
-    return p.skills.slice();
+    return packMembers(ps, args.flags.pack, "skills");
   }
   if (!args._.length) die("nothing to install — pass skill names, --pack <name>, or --all");
   for (const s of args._) if (!skillExists(cat, s)) die(`unknown skill '${s}' in catalog '${cat.source}'`);
@@ -721,10 +733,64 @@ function copyOne(cat, s, dest, ide, l, notes) {
   fs.cpSync(skillDir(cat, s), path.join(dest, s), { recursive: true });
   const note = writeWiring(ide, dest, s, m.description);
   if (note && notes) notes.push(note);
-  l.data[s] = { version: m.version, source: cat.source };
+  l.data[s] = { version: m.version, source: cat.source, files: fileHashes(skillDir(cat, s)) };
   return m;
 }
 
+/* RFC-0032: per-file SHA-256 of a skill as the catalog shipped it, recorded in the ledger at
+   copy time. It is the baseline `update` compares against, so a file the user edited is never
+   overwritten. Paths are forward-slash relative; *.upstream files are this tool's output. */
+function sha256(buf) { return crypto.createHash("sha256").update(buf).digest("hex"); }
+function fileHashes(dir) {
+  const out = {};
+  (function walk(d, rel) {
+    for (const e of fs.readdirSync(d, { withFileTypes: true })) {
+      const r = rel ? `${rel}/${e.name}` : e.name;
+      if (e.isDirectory()) walk(path.join(d, e.name), r);
+      else if (e.isFile() && !e.name.endsWith(".upstream")) out[r] = sha256(fs.readFileSync(path.join(d, e.name)));
+    }
+  })(dir, "");
+  return out;
+}
+
+/* Update one skill file by file against the ledger baseline (RFC-0032):
+     upstream unchanged            -> leave the local file alone, edited or not
+     local untouched, or new file  -> take the new version
+     local edited, upstream moved  -> keep the local file, write the new one as <file>.upstream
+   A file the catalog dropped is removed only if the user never touched it. The new baseline is
+   what the catalog ships now, so a kept edit stays "edited" until the user merges it. */
+function mergeOne(cat, s, dest, ide, l, notes) {
+  const m = manifestOf(cat, s);
+  const src = skillDir(cat, s), dst = path.join(dest, s);
+  const base = l.data[s].files, next = fileHashes(src);
+  const kept = [], orphaned = [];
+  const at = (root, rel) => path.join(root, ...rel.split("/"));
+  const localHash = (rel) => { try { return sha256(fs.readFileSync(at(dst, rel))); } catch (e) { return null; } };
+  for (const [rel, h] of Object.entries(next)) {
+    const mine = localHash(rel), to = at(dst, rel);
+    if (mine === h) { fs.rmSync(to + ".upstream", { force: true }); continue; }
+    if (h === base[rel]) continue;
+    fs.mkdirSync(path.dirname(to), { recursive: true });
+    if (mine === null ? !(rel in base) : mine === base[rel]) {
+      fs.copyFileSync(at(src, rel), to);
+      fs.rmSync(to + ".upstream", { force: true });
+    } else {
+      fs.copyFileSync(at(src, rel), to + ".upstream");
+      kept.push(rel);
+    }
+  }
+  for (const rel of Object.keys(base)) {
+    if (rel in next) continue;
+    const mine = localHash(rel);
+    if (mine === base[rel]) fs.rmSync(at(dst, rel), { force: true });
+    else if (mine !== null) orphaned.push(rel);
+  }
+  const note = writeWiring(ide, dest, s, m.description);
+  if (note && notes) notes.push(note);
+  l.data[s] = { version: m.version, source: cat.source, files: next };
+  return { m, kept, orphaned };
+}
+
 /* Install a whole review panel — the reviewer subagents + the orchestrator skill — in one
    command (RFC-0020). Needs a target with BOTH a subagent and a skill format, so it accepts
    the default (Claude Code), --project, --ide kiro, or --dest; other IDEs install the halves
@@ -874,18 +940,30 @@ function installedRows(flags) {
 function update(args) {
   const { dest, ide, l, rows } = installedRows(args.flags);
   if (!rows.length) return console.log(`nothing installed at ${dest}`);
-  let n = 0;
+  let n = 0, conflicts = 0;
   for (const r of rows) {
     if (!r.current) { console.log(`skip ${r.s}: source '${r.src}' unreachable or skill gone from it`); continue; }
     if (r.current === r.installed) continue;
     const problems = checkSkill(r.cat, r.s);
     if (problems.length) { console.log(`skip ${r.s}: fails structural check in '${r.src}' (${problems[0]})`); continue; }
-    copyOne(r.cat, r.s, dest, ide, l);
-    console.log(`updated ${r.s} ${r.installed} -> ${r.current} (${r.src})`);
+    // No baseline (installed before RFC-0032) or --force: overwrite as before, and record one.
+    const entry = l.data[r.s];
+    if (args.flags.force || typeof entry !== "object" || !entry.files) {
+      copyOne(r.cat, r.s, dest, ide, l);
+      console.log(`updated ${r.s} ${r.installed} -> ${r.current} (${r.src})`);
+    } else {
+      const { kept, orphaned } = mergeOne(r.cat, r.s, dest, ide, l);
+      console.log(`updated ${r.s} ${r.installed} -> ${r.current} (${r.src})`);
+      for (const f of kept) console.log(`  kept your edits in ${f} — new version at ${f}.upstream`);
+      for (const f of orphaned) console.log(`  kept ${f} — dropped upstream, but you edited it`);
+      conflicts += kept.length;
+    }
     n++;
   }
   saveLedger(l);
   console.log(n ? `\n${n} skill(s) updated.` : "everything up to date.");
+  if (conflicts)
+    console.log(`${conflicts} file(s) kept your edits. Merge each <file>.upstream into its file, then delete it — or rerun with --force to take every new version.`);
 }
 
 function outdated(args) {
@@ -1013,7 +1091,7 @@ function installLoops(args) {
     if (!ps) die(`catalog '${cat.source}' has no packs.json`);
     const pk = ps[args.flags.pack];
     if (!pk) die(`unknown pack '${args.flags.pack}' in catalog '${cat.source}'`);
-    names = (pk.loops || []).slice();
+    names = packMembers(ps, args.flags.pack, "loops");
     if (!names.length) die(`pack '${args.flags.pack}' declares no loops`);
   }
   if (!names.length && args.flags.all) names = available.slice();
@@ -1182,13 +1260,13 @@ function listPacks(args) {
       catalog: cat.source,
       count: ps ? Object.keys(ps).length : 0,
       packs: Object.entries(ps || {}).map(([name, p]) => ({
-        name, description: p.description || null, skills: p.skills || [],
+        name, description: p.description || null, skills: p.skills || [], requires: p.requires || [],
       })),
     });
   if (!ps) return console.log(`catalog '${cat.source}' defines no packs.`);
   const w = Math.max(...Object.keys(ps).map((n) => n.length));
   for (const [n, p] of Object.entries(ps))
-    console.log(`${n.padEnd(w)}  (${p.skills.length} skills)  ${p.description}`);
+    console.log(`${n.padEnd(w)}  (${p.skills.length} skills${(p.requires || []).length ? ` + ${p.requires.join(", ")}` : ""})  ${p.description}`);
   console.log("\nInstall one: skilldrop install --pack <name>");
 }
 

package/contracts/pack.schema.json

@@ -2,7 +2,7 @@
   "$schema": "https://json-schema.org/draft/2020-12/schema",
   "$id": "https://github.com/sananthanarayan/skilldrop/contracts/pack.schema.json",
   "title": "skilldrop packs.json",
-  "$comment": "RFC-0001 / RFC-0026 / RFC-0029. Packs and outcomes are METADATA ONLY — skills never move out of flat skills/<name> folders. Packs answer WHO needs a skill; outcomes answer WHY someone opened the catalogue. Both get the same two-way membership check in validate.py.",
+  "$comment": "RFC-0001 / RFC-0026 / RFC-0029 / RFC-0033. Packs and outcomes are METADATA ONLY — skills never move out of flat skills/<name> folders. RFC-0033: each skill and loop sits in exactly one pack; shared skills live in `core`, which other packs pull in via `requires`. Packs answer WHO needs a skill; outcomes answer WHY someone opened the catalogue. Both get the same two-way membership check in validate.py.",
   "type": "object",
   "additionalProperties": false,
   "required": ["version", "packs", "outcomes"],
@@ -20,7 +20,14 @@
           "description": { "type": "string", "description": "One line — who this pack is for." },
           "skills": { "type": "array", "items": { "type": "string" }, "minItems": 1,
                       "description": "Real skill folders. Every skill must appear in at least one pack." },
-          "loops": { "type": "array", "items": { "type": "string" },
+          "requires": {
+      "type": "array",
+      "items": {
+       "type": "string"
+      },
+      "description": "RFC-0033. Packs installed together with this one (in practice, `core`). One level only: a required pack may not itself require."
+     },
+     "loops": { "type": "array", "items": { "type": "string" },
                      "description": "RFC-0028. Real loops/ folders. Every loop must appear in at least one pack." }
         }
       }

package/package.json

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

package/packs.json

@@ -1,12 +1,22 @@
 {
-  "$comment": "Virtual skill packs — role-based bundles for one-command install. Packs are METADATA ONLY: skills stay in flat skills/<name> folders (golden rule: skills are discovered by path), a skill may belong to several packs, and every skill must belong to at least one (validate.py enforces both directions). Install a pack with `python3 pack.py <pack> --install`; see README. Rationale: docs/rfcs/0001-skill-packs.md. `outcomes` (RFC-0026) is the second browse axis: packs say WHO needs a skill, outcomes say WHY someone opens the catalogue. It is the README's nine categories restated as seven outcomes and made machine-readable so the site cannot drift from them. Outcomes are a browse aid only — not an install unit — and validate.py enforces the same two-way check packs get.",
-  "version": "0.1.0",
+  "$comment": "Virtual skill packs — role-based bundles for one-command install. Packs are METADATA ONLY: skills stay in flat skills/<name> folders (golden rule: skills are discovered by path), every skill and every loop belongs to exactly one pack (RFC-0033 — the shape a later physical packs/<name>/ layout needs), and a pack may `requires` the `core` pack, which every installer then installs with it. validate.py enforces all of this. Install a pack with `python3 pack.py <pack> --install`; see README. Rationale: docs/rfcs/0001-skill-packs.md. `outcomes` (RFC-0026) is the second browse axis: packs say WHO needs a skill, outcomes say WHY someone opens the catalogue. It is the README's nine categories restated as seven outcomes and made machine-readable so the site cannot drift from them. Outcomes are a browse aid only — not an install unit — and validate.py enforces the same two-way check packs get.",
+  "version": "0.2.0",
   "packs": {
+    "core": {
+      "description": "The cross-role toolkit every pack builds on: structured intake, document critique, the review council, and output hygiene, plus the ship-a-draft wrapper. Installed automatically with every role pack.",
+      "loops": ["ship-a-draft"],
+      "skills": [
+        "brief-intake",
+        "doc-critique",
+        "output-hygiene",
+        "council-review"
+      ]
+    },
     "solution-architect": {
       "description": "Design-phase artifacts: diagrams, decision records, design docs, contracts, schemas, threat models, and the reviews that gate them.",
-      "loops": ["design", "ship-a-draft"],
+      "requires": ["core"],
+      "loops": ["design"],
       "skills": [
-        "brief-intake",
         "architecture-diagrams",
         "reverse-architecture",
         "figma-diagrams",
@@ -14,22 +24,17 @@
         "design-doc",
         "tech-comparison-matrix",
         "threat-model",
-        "agent-threat-model",
-        "agents-md-generator",
         "api-contract-draft",
         "data-contract",
         "db-schema-design",
-        "nfr-spec",
-        "capacity-cost-model",
-        "council-review",
-        "doc-critique"
+        "nfr-spec"
       ]
     },
     "product-manager": {
-      "description": "Direction to requirements: PR/FAQs, strategy frameworks, OKRs, PRDs, journey maps, story splitting, and success measurement.",
-      "loops": ["discover", "ship-a-draft"],
+      "description": "Direction to requirements: PR/FAQs, strategy frameworks, OKRs, business cases, interviews, PRDs, journey maps, and success measurement.",
+      "requires": ["core"],
+      "loops": ["discover"],
       "skills": [
-        "brief-intake",
         "prfaq",
         "strategy-analysis",
         "okr-cascade",
@@ -37,23 +42,19 @@
         "requirements-interview",
         "prd-draft",
         "user-journey-map",
-        "user-story-splitter",
-        "success-metrics",
-        "exec-summary",
-        "doc-critique",
-        "ai-use-case-triage"
+        "success-metrics"
       ]
     },
     "dev-team": {
-      "description": "Build-and-ship loop: story implementation with adversarial review, test plans, triage, migrations, release notes, agent-policy files, and code-quality gates.",
-      "loops": ["build", "release", "ship-a-draft"],
+      "description": "Build-and-ship: story splitting, implementation with adversarial review, test plans, triage, migrations, launch readiness, release notes, agent-policy files, and code-quality gates.",
+      "requires": ["core"],
+      "loops": ["build", "release"],
       "skills": [
         "agents-md-generator",
         "user-story-splitter",
         "feature-implement-loop",
         "pre-merge-review",
         "devils-advocate",
-        "council-review",
         "test-plan-generator",
         "bug-triage",
         "migration-plan",
@@ -61,41 +62,39 @@
         "sonar-onboard",
         "sonar-review",
         "accessibility-audit",
-        "output-hygiene",
         "contribution-wizard",
         "launch-readiness"
       ]
     },
     "sre-oncall": {
       "description": "Operate the service: runbooks, observability design, incident communications, postmortems, and capacity/cost models.",
-      "loops": ["release", "operate"],
+      "requires": ["core"],
+      "loops": ["operate"],
       "skills": [
         "runbook-generator",
         "observability-plan",
         "incident-comms",
         "postmortem-generator",
-        "capacity-cost-model",
-        "launch-readiness"
+        "capacity-cost-model"
       ]
     },
     "stakeholder-comms": {
       "description": "Non-technical audiences: audience profiling, deck outlines and real .pptx decks, exec summaries, decision logs, and guides.",
-      "loops": ["ship-a-draft"],
+      "requires": ["core"],
+      "loops": [],
       "skills": [
-        "brief-intake",
         "audience-profile",
         "slide-outliner",
         "deck-builder",
         "exec-summary",
         "decision-log",
-        "guide-builder",
-        "doc-critique",
-        "output-hygiene"
+        "guide-builder"
       ]
     },
     "ai-engineering": {
-      "description": "Adopt and build AI systems: readiness assessment, use-case triage, rollout and acceptable-use policy, plus agent loop design, subagent orchestration, spend budgets, agent security review, eval harnesses, AI-usage reporting, and the data contracts AI pipelines depend on.",
-      "loops": ["design", "build"],
+      "description": "Adopt and build AI systems: readiness assessment, use-case triage, rollout and acceptable-use policy, plus agent loop design, subagent orchestration, spend budgets, agent security review, eval harnesses, and AI-usage reporting.",
+      "requires": ["core"],
+      "loops": [],
       "skills": [
         "agent-loop-design",
         "subagent-design",
@@ -103,7 +102,6 @@
         "agent-threat-model",
         "llm-eval-harness",
         "ai-usage-report",
-        "data-contract",
         "ai-readiness-assessment",
         "ai-use-case-triage",
         "ai-adoption-rollout",