use-agentz 0.1.0

package/registry/r/preset.full.json

@@ -0,0 +1,67 @@
+{
+  "schemaVersion": 1,
+  "name": "full",
+  "type": "preset",
+  "title": "Full (trio + MCPs + tools)",
+  "description": "Everything in the trio plus the designer agent and design skill group, Context7, Playwright and the scratchpad tool.",
+  "dependencies": [
+    "agent:orchestrator",
+    "agent:quick",
+    "agent:scout",
+    "agent:developer",
+    "agent:analyst",
+    "agent:designer",
+    "skill:caveman",
+    "skill:code-review",
+    "skill:cost-aware-orchestration",
+    "skill:design-system",
+    "skill:design-taste",
+    "skill:diagnosing-bugs",
+    "skill:domain-modeling",
+    "skill:frontend-qa",
+    "skill:grilling",
+    "skill:improve-architecture",
+    "skill:product-ui",
+    "skill:resolving-merge-conflicts",
+    "skill:software-design",
+    "skill:tdd",
+    "skill:visual-assets",
+    "skill:wayfinder",
+    "mcp:context7",
+    "mcp:playwright",
+    "tool:a11y-quick",
+    "tool:contrast-check",
+    "tool:design-lint",
+    "tool:design-search",
+    "tool:scratchpad",
+    "tool:token-validate",
+    "rule:routing",
+    "rule:use-question-tool"
+  ],
+  "meta": {
+    "agentsMd": "lean",
+    "disableDefaults": true,
+    "models": {
+      "cheap": {
+        "opencode": "github-copilot/gpt-5.6-luna",
+        "copilot": "gpt-5.6-luna",
+        "claude": "haiku",
+        "codex": "gpt-5.6-luna",
+        "kilocode": "github-copilot/gpt-5.6-luna",
+        "hermes": "github-copilot/gpt-5.6-luna"
+      },
+      "normal": {
+        "opencode": "github-copilot/claude-opus-4.8",
+        "copilot": "claude-opus-4.8",
+        "claude": "opus",
+        "codex": "claude-opus-4.8",
+        "kilocode": "github-copilot/claude-opus-4.8",
+        "hermes": "github-copilot/claude-opus-4.8"
+      }
+    },
+    "skillGroups": [
+      "design",
+      "engineering-process"
+    ]
+  }
+}

package/registry/r/rule.always-cross-review.json

@@ -0,0 +1,25 @@
+{
+  "schemaVersion": 1,
+  "name": "always-cross-review",
+  "type": "rule",
+  "title": "Always cross-model review",
+  "description": "Review policy: every substantial/risky change gets an opposite-family cross-model review without being asked. Mutually exclusive with never-cross-review.",
+  "files": [
+    {
+      "path": "always-cross-review.md",
+      "content": "# Always cross-model review\n\nReview policy: every substantial or risky implementation gets an independent\ncross-model review without being asked.\n\n**Enforced** without being asked, after a substantial or risky change:\n\n- run the cross-model review per the `cross-model-review` skill\n- route to the reviewer of the OPPOSITE model family: GPT work (terra/sol) →\n  `reviewer-anthropic`; Anthropic work (opus/fable) → `reviewer-gpt`\n- fold the reviewer's findings back before declaring the work done\n\n**Forbidden:**\n\n- shipping a substantial change with no cross-model review\n- reviewing work with a same-family reviewer\n\n**Per-task escape** — trivial change, or the user says \"no review\", \"skip\nreview\": skip the cross-model pass for that task.\n\nRequires the `cross-model-review` skill and the `reviewer-gpt` /\n`reviewer-anthropic` agents (install the cross-model-review pack).\n\nMutually exclusive with the `never-cross-review` rule — both installed: flag\nthe conflict, ask which to keep.\n",
+      "kind": "raw"
+    }
+  ],
+  "config": {
+    "rules": {
+      "placement": "instructions"
+    }
+  },
+  "markerId": "rule-always-cross-review",
+  "meta": {
+    "contradicts": [
+      "never-cross-review"
+    ]
+  }
+}

package/registry/r/rule.always-design.json

@@ -0,0 +1,25 @@
+{
+  "schemaVersion": 1,
+  "name": "always-design",
+  "type": "rule",
+  "title": "Always Designer & UIUX skills",
+  "description": "Design policy: UI work loads the designer/UIUX skill stack without being asked.",
+  "files": [
+    {
+      "path": "always-design.md",
+      "content": "# Always Designer & UIUX skills\n\nDesign policy: UI work loads the designer/UIUX skill stack without being asked.\n\n**Enforced** for any UI-touching task:\n\n- load design-taste (aesthetic foundation) plus the matching skill: product-ui for app/dashboard screens, design-system for tokens/themes\n- apply them to layout, typography, spacing, and color decisions\n\n**Per-task escape** — the user's request contains a never-design trigger (\"no design\", \"no designer\", \"quick UI\"): skip the design stack, make the minimal edit matching existing styles.\n\nMutually exclusive with the `never-design` rule — both installed: flag the conflict, ask which to keep.\n",
+      "kind": "raw"
+    }
+  ],
+  "config": {
+    "rules": {
+      "placement": "instructions"
+    }
+  },
+  "markerId": "rule-always-design",
+  "meta": {
+    "contradicts": [
+      "never-design"
+    ]
+  }
+}

package/registry/r/rule.always-qa.json

@@ -0,0 +1,25 @@
+{
+  "schemaVersion": 1,
+  "name": "always-qa",
+  "type": "rule",
+  "title": "Always QA (Playwright)",
+  "description": "QA policy: every UI-affecting change gets a Playwright/browser QA pass without being asked.",
+  "files": [
+    {
+      "path": "always-qa.md",
+      "content": "# Always QA (Playwright)\n\nQA policy: every UI-affecting change gets a browser QA pass.\n\n**Enforced** without being asked:\n\n- run a Playwright/browser check after UI changes: load the page, walk the changed states, check console errors\n- lint pass on touched frontend files\n- screenshot evidence for visual changes\n- delegated UI tasks include the QA pass in the slice\n\n**Forbidden:**\n\n- declaring UI work done without browser verification\n\n**Per-task escape** — the user's request contains a never-qa trigger (\"no playwright\", \"no QA\", \"no UIUX revision loops\", \"quick edit\"): skip QA for that task, the user tests it themselves.\n\nMutually exclusive with the `never-qa` rule — both installed: flag the conflict, ask which to keep.\n",
+      "kind": "raw"
+    }
+  ],
+  "config": {
+    "rules": {
+      "placement": "instructions"
+    }
+  },
+  "markerId": "rule-always-qa",
+  "meta": {
+    "contradicts": [
+      "never-qa"
+    ]
+  }
+}

package/registry/r/rule.always-test.json

@@ -0,0 +1,25 @@
+{
+  "schemaVersion": 1,
+  "name": "always-test",
+  "type": "rule",
+  "title": "Always Test",
+  "description": "Testing policy: write and run tests for every change without being asked.",
+  "files": [
+    {
+      "path": "always-test.md",
+      "content": "# Always Test\n\nTesting policy: every change ships with tests.\n\n**Enforced** without being asked:\n\n- write or extend tests for every new or changed piece of logic (meaningful assertions at stable seams — no snapshot spam, no testing trivia)\n- run the relevant test suite after changes and report results\n- delegated implementation tasks include tests as part of the slice\n\n**Forbidden:**\n\n- shipping a change without running its tests\n- deferring test writing to a later task unless the user explicitly says so\n\n**Per-task escape** — the user's request contains a never-test trigger (\"prototype\", \"proof of concept\", \"poc\", \"alpha\", \"no tests\", \"no new tests\"): skip test writing for that task, no debate.\n\nMutually exclusive with the `never-test` rule — both installed: flag the conflict, ask which to keep.\n",
+      "kind": "raw"
+    }
+  ],
+  "config": {
+    "rules": {
+      "placement": "instructions"
+    }
+  },
+  "markerId": "rule-always-test",
+  "meta": {
+    "contradicts": [
+      "never-test"
+    ]
+  }
+}

package/registry/r/rule.caveman-ultra.json

@@ -0,0 +1,23 @@
+{
+  "schemaVersion": 1,
+  "name": "caveman-ultra",
+  "type": "rule",
+  "title": "Caveman ultra",
+  "description": "Every agent runs the caveman skill in ultra mode — terse fragments, full substance.",
+  "files": [
+    {
+      "path": "AGENTS.md",
+      "content": "# Agent Operating Rules (AgentZ)\n\n## Caveman ultra\n\nEvery agent loads the `caveman` skill, mode **ultra**: terse fragments, full\ntechnical substance, code blocks normal. One statement per fact. Standard tech\nacronyms (DB/API/HTTP) OK; never invent abbreviations (cfg/impl/req/res/fn) and\nno causal arrows — tokenizer splits them the same, zero tokens saved. Security\nwarnings and irreversible actions stay verbose.\n",
+      "kind": "raw"
+    }
+  ],
+  "config": {
+    "rules": {
+      "placement": "agents-md"
+    }
+  },
+  "markerId": "opencode-rules",
+  "meta": {
+    "order": 10
+  }
+}

package/registry/r/rule.never-cross-review.json

@@ -0,0 +1,25 @@
+{
+  "schemaVersion": 1,
+  "name": "never-cross-review",
+  "type": "rule",
+  "title": "Never cross-model review unless asked",
+  "description": "Review policy: no cross-model review on your own initiative; only when explicitly requested. Mutually exclusive with always-cross-review.",
+  "files": [
+    {
+      "path": "never-cross-review.md",
+      "content": "# Never cross-model review unless asked\n\nReview policy: no cross-model review on your own initiative; only when the user\nexplicitly asks.\n\n**Forbidden** unless explicitly requested:\n\n- kicking off a cross-model review pass on your own\n- routing work to `reviewer-gpt` / `reviewer-anthropic` uninvited\n\n**Instead:**\n\n- finish the change, hand it back, the user requests review if they want it\n- if a change is risky enough that skipping review feels wrong: one short note\n  suggesting a review follow-up, then stop\n\n**Trigger examples** confirming this policy: \"no review\", \"don't review\",\n\"skip cross-review\".\n\n**Per-task escape** — the user explicitly asks (\"review this\", \"cross-review\nit\", \"get the other model to check\"): run the review for that task per the\n`cross-model-review` skill.\n\nMutually exclusive with the `always-cross-review` rule — both installed: flag\nthe conflict, ask which to keep.\n",
+      "kind": "raw"
+    }
+  ],
+  "config": {
+    "rules": {
+      "placement": "instructions"
+    }
+  },
+  "markerId": "rule-never-cross-review",
+  "meta": {
+    "contradicts": [
+      "always-cross-review"
+    ]
+  }
+}

package/registry/r/rule.never-design.json

@@ -0,0 +1,25 @@
+{
+  "schemaVersion": 1,
+  "name": "never-design",
+  "type": "rule",
+  "title": "Never Designer & UIUX skills",
+  "description": "Design policy: no designer/UIUX skills unless design work is explicitly requested.",
+  "files": [
+    {
+      "path": "never-design.md",
+      "content": "# Never Designer & UIUX skills unless asked\n\nDesign policy: do not load designer/UIUX skills unless the user explicitly asks for design work.\n\n**Forbidden** unless explicitly requested:\n\n- loading design-taste / product-ui / design-system / visual-assets for routine UI edits\n- unsolicited redesigns, restyling, or \"while I'm here\" polish\n\n**Instead:**\n\n- match existing styles and patterns, minimal diff\n\n**Trigger examples** confirming this policy for a task: \"no design\", \"no designer\", \"quick UI\".\n\n**Per-task escape** — the user explicitly asks (\"design\", \"redesign\", \"make it beautiful\", \"polish the UI\"): load the design stack for that task.\n\nMutually exclusive with the `always-design` rule — both installed: flag the conflict, ask which to keep.\n",
+      "kind": "raw"
+    }
+  ],
+  "config": {
+    "rules": {
+      "placement": "instructions"
+    }
+  },
+  "markerId": "rule-never-design",
+  "meta": {
+    "contradicts": [
+      "always-design"
+    ]
+  }
+}

package/registry/r/rule.never-qa.json

@@ -0,0 +1,25 @@
+{
+  "schemaVersion": 1,
+  "name": "never-qa",
+  "type": "rule",
+  "title": "Never QA (Playwright) unless asked",
+  "description": "QA policy: no Playwright/browser QA loops unless explicitly requested.",
+  "files": [
+    {
+      "path": "never-qa.md",
+      "content": "# Never QA (Playwright) unless asked\n\nQA policy: no Playwright/browser QA loops unless the user explicitly asks.\n\n**Forbidden** unless explicitly requested:\n\n- Playwright/browser QA passes\n- lint-only QA sweeps\n- UIUX revision loops (iterate–screenshot–fix cycles)\n- instructing subagents to QA on their own initiative\n\n**Instead:**\n\n- make the edit, keep it quick, the user tests it themselves\n- if a change is risky enough that skipping QA feels wrong: one short note suggesting a QA follow-up, then stop\n\n**Trigger examples** confirming this policy for a task: \"no playwright\", \"no QA\", \"no UIUX revision loops\".\n\n**Per-task escape** — the user explicitly asks (\"QA this\", \"verify in browser\", \"run playwright\", \"check it visually\"): run the QA pass for that task.\n\nMutually exclusive with the `always-qa` rule — both installed: flag the conflict, ask which to keep.\n",
+      "kind": "raw"
+    }
+  ],
+  "config": {
+    "rules": {
+      "placement": "instructions"
+    }
+  },
+  "markerId": "rule-never-qa",
+  "meta": {
+    "contradicts": [
+      "always-qa"
+    ]
+  }
+}

package/registry/r/rule.never-test.json

@@ -0,0 +1,25 @@
+{
+  "schemaVersion": 1,
+  "name": "never-test",
+  "type": "rule",
+  "title": "Never Test unless asked",
+  "description": "Testing policy: no new tests unless explicitly requested; running the existing suite is fine.",
+  "files": [
+    {
+      "path": "never-test.md",
+      "content": "# Never Test unless asked\n\nTesting policy: do not write tests unless the user explicitly asks.\n\n**Forbidden** unless explicitly requested:\n\n- writing or extending test files\n- adding test scripts, test dependencies, or CI test steps\n- instructing subagents to add tests on their own initiative\n\n**Allowed** without asking:\n\n- running the EXISTING test suite to verify a change\n\n**Trigger examples** confirming this policy for a task: \"prototype\", \"proof of concept\", \"alpha\", \"no tests\", \"no new tests\". When present: zero tests, even if the change looks risky — one short risk note max, then move on.\n\n**Per-task escape** — the user explicitly asks (\"write tests\", \"TDD\", \"add coverage\", \"cover this with tests\"): write tests for that task. \"Make it robust\" is NOT an ask.\n\nMutually exclusive with the `always-test` rule — both installed: flag the conflict, ask which to keep.\n",
+      "kind": "raw"
+    }
+  ],
+  "config": {
+    "rules": {
+      "placement": "instructions"
+    }
+  },
+  "markerId": "rule-never-test",
+  "meta": {
+    "contradicts": [
+      "always-test"
+    ]
+  }
+}

package/registry/r/rule.routing.json

@@ -0,0 +1,26 @@
+{
+  "schemaVersion": 1,
+  "name": "routing",
+  "type": "rule",
+  "title": "Agent roster & routing",
+  "description": "Cheapest-capable-agent routing across the scout/developer/expert trio.",
+  "files": [
+    {
+      "path": "AGENTS.md",
+      "content": "## Agents\n\nRoster and routing live in each agent's own prompt. Cheapest capable agent\nwins; escalate only on failure or high stakes.\n\nManage this setup (agents, skills, models, presets) with the `agentz` CLI.\n{{?agentsMdFull}}\n\n## Routing\n\n| Agent | Tier | Job |\n|---|---|---|\n| `scout` | cheap | read, summarize, plan — nothing technical |\n| `developer` | normal | understand code, implement, refactor, infra, debug |\n| `expert` | very expensive | prepared prompts only, one round-trip, catches what others miss |\n\nThe main agent routes each task to the cheapest agent that can do it well and\nescalates only on failure or high stakes. For quick fixes and usage questions\nthe `quick` agent skips orchestration and hands back when a task outgrows it.\n{{/agentsMdFull}}\n",
+      "kind": "raw"
+    }
+  ],
+  "config": {
+    "rules": {
+      "placement": "agents-md"
+    }
+  },
+  "flags": [
+    "agentsMdFull"
+  ],
+  "markerId": "rule-routing",
+  "meta": {
+    "order": 20
+  }
+}

package/registry/r/rule.use-question-tool.json

@@ -0,0 +1,20 @@
+{
+  "schemaVersion": 1,
+  "name": "use-question-tool",
+  "type": "rule",
+  "title": "Use the question tool to interrogate",
+  "description": "Orchestrator agents: use the opencode question tool (multiple questions, structured options) when grilling or interrogating the user instead of plain-text replies.",
+  "files": [
+    {
+      "path": "use-question-tool.md",
+      "content": "# Use the question tool to interrogate\n\nOrchestrator agents only. When grilling (the `grilling` skill, `grill-me`\ncommand) or otherwise interrogating the user with questions, use the opencode\n`question` tool instead of asking in a plain reply.\n\n- it renders better in opencode than plain-text questions\n- batch multiple questions in one call; give each structured options\n- keep questions short and concrete\n\nApplies to real interrogation moments — grilling, resolving open design\ndecisions, disambiguating a request. A single throwaway clarification in prose\nis still fine.\n",
+      "kind": "raw"
+    }
+  ],
+  "config": {
+    "rules": {
+      "placement": "instructions"
+    }
+  },
+  "markerId": "rule-use-question-tool"
+}

package/registry/r/skill.bun-cli.json

@@ -0,0 +1,20 @@
+{
+  "schemaVersion": 1,
+  "name": "bun-cli",
+  "type": "skill",
+  "title": "Bun CLI development",
+  "description": "Bun CLI development. Use when building a command-line tool on Bun/TypeScript: wiring the bin entry, parsing Bun.argv, compiling single-file executables, or testing with `bun test`.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: bun-cli\nlabel: \"Bun CLI development\"\ndependencies: [bun]\ndescription: >\n  Bun CLI development. Use when building a command-line tool on Bun/TypeScript:\n  wiring the bin entry, parsing Bun.argv, compiling single-file executables, or\n  testing with `bun test`.\n---\n\nBuild CLIs on Bun — fast startup, TypeScript-native, zero build step in dev.\n\n## Project wiring\n\n- Entry: `src/cli.ts` with `#!/usr/bin/env bun` shebang; `package.json` `\"bin\": { \"tool\": \"src/cli.ts\" }`.\n- `\"type\": \"module\"`; import with explicit `.ts` extensions.\n- Args from `Bun.argv.slice(2)`. Prefer a small hand-rolled parser or `util.parseArgs` over heavy frameworks — startup time is the feature.\n\n## Bun specifics\n\n- `Bun.which(\"binary\")` to detect system tools; `Bun.spawn`/`Bun.$` for subprocesses (`` await $`git status`.text() ``).\n- `Bun.file(path)` / `Bun.write()` for fast IO; `import.meta.dir` for module-relative paths — but resolve user paths against `process.cwd()`.\n- `bun --install=fallback script.ts` auto-resolves missing deps when shipping standalone scripts.\n- Env: `Bun.env` / `import.meta.env`.\n\n## Distribution\n\n- Dev: run the `.ts` directly via bin entry.\n- Standalone: `bun build --compile --minify src/cli.ts --outfile tool` produces a single binary (per platform; use `--target bun-linux-x64` etc. in CI).\n- npm: publish with the `.ts` bin only if consumers run bun; otherwise prebundle with `bun build --target node`.\n\n## Testing\n\n- `bun test` with `describe/test/expect` from `bun:test`.\n- Test the pure logic (arg parsing, planning) directly; integration-test the binary via `Bun.spawn` and assert stdout/stderr/exit code.\n- Use `mkdtempSync(tmpdir())` scratch dirs; never write into the repo during tests.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "bun"
+    ]
+  }
+}

package/registry/r/skill.bun-tui.json

@@ -0,0 +1,20 @@
+{
+  "schemaVersion": 1,
+  "name": "bun-tui",
+  "type": "skill",
+  "title": "Bun TUI development",
+  "description": "Interactive Bun terminal flows: use Ink for stateful full-screen interfaces or @clack/prompts for lightweight setup wizards.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: bun-tui\nlabel: \"Bun TUI development\"\ndependencies: [bun]\ndescription: >\n  Interactive Bun terminal flows: use Ink for stateful full-screen interfaces\n  or @clack/prompts for lightweight setup wizards.\n---\n\nBuild TUIs on Bun — React-style components for rich UIs, Clack for quick prompts.\n\n## Preferred libraries\n\n- `ink` — React renderer for the terminal. Use for stateful, full-screen, or multi-region UIs.\n  - Companions: `ink-text-input`, `ink-select-input`, `ink-spinner`, `ink-table`, `ink-big-text`.\n- `@clack/prompts` — polished, dependency-light prompts (`intro`, `text`, `select`, `confirm`, `spinner`, `outro`). Use for linear wizards and setup flows where a full React tree is overkill.\n- `picocolors` for color (respects `NO_COLOR`); avoid heavy chalk alternatives.\n\n## Choosing the tool\n\n- Linear question→answer flow (init, login, scaffolding): `@clack/prompts`. Handle `isCancel()` on every prompt and exit cleanly.\n- Live/interactive dashboard, lists, concurrent regions, keyboard navigation: `ink`.\n\n## Ink architecture\n\n- Components return JSX of `<Box>`/`<Text>`; layout is Flexbox (`flexDirection`, `gap`, `borderStyle`).\n- State via `useState`/`useReducer`; side effects in `useEffect` with cleanup.\n- Input via `useInput((input, key) => …)`; exit via `useApp().exit()`.\n- Render with `render(<App/>)`; keep async work (subprocess, fetch) in effects, not render.\n- Bun runs `.tsx` directly — no build step in dev; set `\"jsx\": \"react-jsx\"` and import from `react`.\n\n## Conventions\n\n- Detect a TTY (`process.stdout.isTTY`); fall back to plain non-interactive output for pipes/CI.\n- Logs and progress to stderr; final machine-readable result to stdout.\n- Trap `SIGINT` to restore the terminal and exit with code 130.\n\n## Testing\n\n- `ink-testing-library` (`render`, `lastFrame()`, `stdin.write()`) to assert rendered frames and simulate keypresses.\n- Keep core logic in plain functions tested with `bun test`; reserve frame tests for the view layer.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "bun"
+    ]
+  }
+}

package/registry/r/skill.caveman-compress.json

@@ -0,0 +1,17 @@
+{
+  "schemaVersion": 1,
+  "name": "caveman-compress",
+  "type": "skill",
+  "title": "caveman-compress",
+  "description": "Compress a prose file (CLAUDE.md/AGENTS.md/notes) into caveman format to cut input tokens, preserving all technical substance. Backs up before overwriting; never touches code/config/data.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: caveman-compress\ndescription: >\n  Compress a prose file (CLAUDE.md, AGENTS.md, todos, notes, preferences) into caveman format\n  to cut input tokens, preserving all technical substance. Safe: never touches code/config/data files,\n  backs up the original before overwriting, validates and retries. Trigger: /caveman-compress FILEPATH,\n  \"compress memory file\", \"shrink CLAUDE.md\", \"caveman-compress this\".\nsource: https://github.com/juliusbrussee/caveman\n---\n\n# Caveman Compress\n\nCompress prose file into caveman speak. Cut input tokens. Keep all substance.\nOverwrite original. Backup first.\n\n## Trigger\n\n`/caveman-compress <filepath>` or user asks compress memory/prose file.\n\n## File-type boundary (hard)\n\nOnly compress prose: `.md .txt .markdown .rst .typ .typst .tex` and\nextensionless prose (CLAUDE.md-style memory, TODO).\n\nNEVER touch code/config/data:\n`.py .js .ts .tsx .json .yaml .yml .toml .env .lock .css .scss .html .xml\n.sql .sh` etc. Known code basenames win over extension: `Dockerfile`,\n`Makefile`, `CMakeLists.txt`, `*file` (Gemfile/Rakefile/...).\n\nExtensionless: shebang `#!` = code. Valid JSON/YAML = config. >40% code-like\nlines = code. Else prose.\n\nUnsure code or prose: leave unchanged.\n\nRefuse sensitive files before read (contents ship to an LLM API):\n`.env* .netrc credentials* secrets* password* id_rsa authorized_keys\n*.pem *.key *.p12 *.crt`, or path under `.ssh .aws .gnupg .kube .docker`, or\nname token secret/credential/apikey/token/privatekey. False positive: user\nrename file.\n\n## Process\n\n1. Detect file type. Not prose: skip, report, stop.\n2. Guard: file exist, is file, <500KB, non-empty, not sensitive, not\n   `*.original.md` backup.\n3. Split YAML frontmatter off. Keep verbatim. Compress body only.\n4. Compress body per rules below.\n5. Reject bad output: empty, or identical to input (LLM refused / already\n   caveman). Original untouched, no backup written.\n6. Backup original OUT of source tree (so skill auto-loaders stop re-ingesting\n   it), then read-back-verify backup equals original before touching input.\n   Backup name `<stem>.original.md`. Backup already exists: abort, no data loss.\n7. Write `frontmatter + compressed body`.\n8. Validate. Fail: cherry-pick fix (targeted, no recompress), retry up to 2.\n   Still failing: restore original, remove backup, report.\n\n## Preserve EXACTLY (never modify)\n\n- Fenced ``` ``` and indented code blocks — read-only regions\n- Inline `backtick` content\n- URLs, markdown links, file paths, CLI commands\n- Technical terms, library/API names, protocols, proper nouns\n- Dates, version numbers, all numeric values\n- Environment variables (`$HOME`, `NODE_ENV`)\n- Headings (exact text), bullet nesting, list numbering, table structure,\n  YAML frontmatter\n\nAnything inside ``` copied byte-for-byte: no comment removal, no reorder, no\ncommand shortening. Only compress text OUTSIDE code regions. Do not merge\nsections across code blocks.\n\n## Compress\n\nDrop articles (a/an/the), filler (just/really/basically/actually/simply),\npleasantries, hedging (\"it might be worth\", \"you could consider\"). \"in order\nto\" to \"to\", \"utilize\" to \"use\". Fragments OK. Drop \"you should / make sure to\n/ remember to\" — state action. Merge redundant bullets. Keep one example per\npattern.\n\nOriginal:\n> You should always make sure to run the test suite before pushing any changes to the main branch. This is important because it helps catch bugs early.\n\nCompressed:\n> Run tests before push to main. Catch bugs early.\n\n## Mechanics\n\nPlugin `caveman-compress` (opencode) carries the safe mechanics: type detect,\nsensitivity refuse, size guard, backup + read-back verify, write, restore.\nThis skill carries the compression rules the model applies. Skill = rules,\nplugin = safe file I/O.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "meta": {
+    "source": "https://github.com/juliusbrussee/caveman"
+  }
+}

package/registry/r/skill.caveman.json

@@ -0,0 +1,20 @@
+{
+  "schemaVersion": 1,
+  "name": "caveman",
+  "type": "skill",
+  "title": "caveman (ultra)",
+  "description": "Ultra-compressed replies, 65% fewer output tokens, full technical accuracy. Every agent runs it on mode ultra.",
+  "dependencies": [
+    "rule:caveman-ultra"
+  ],
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: caveman\ndescription: >\n  Ultra-compressed communication mode. Cuts output tokens 65% (measured) by speaking like caveman\n  while keeping full technical accuracy. Supports intensity levels: lite, full, ultra (default here),\n  wenyan-lite, wenyan-full, wenyan-ultra.\n  Use when user says \"caveman mode\", \"talk like caveman\", \"use caveman\", \"less tokens\",\n  \"be brief\", or invokes /caveman. Also auto-triggers when token efficiency is requested.\n  In this setup EVERY agent loads this skill at session start and runs mode ULTRA.\n---\n\nRespond terse like smart caveman. All technical substance stay. Only fluff die.\n\n## Persistence\n\nACTIVE EVERY RESPONSE. No revert after many turns. No filler drift. Still active if unsure. Off only: \"stop caveman\" / \"normal mode\".\n\nDefault in this setup: **ultra**. Switch: `/caveman lite|full|ultra`.\n\n## Rules\n\nDrop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not \"implement a solution for\"). No tool-call narration, no decorative tables/emoji, no dumping long raw error logs unless asked — quote shortest decisive line. Standard well-known tech acronyms OK (DB/API/HTTP); never invent new abbreviations (cfg/impl/req/res/fn) — tokenizer split them same as full word: zero token saved, reader still decode. Full word cheaper AND clearer. No causal arrows (→) either — own token, save nothing. Technical terms exact. Code blocks unchanged. Errors quoted exact.\n\nPreserve user's dominant language. User write Portuguese → reply Portuguese caveman. User write Spanish → reply Spanish caveman. Compress the style, not the language. No forced English openings or status phrases. ALWAYS keep technical terms, code, API names, CLI commands, commit-type keywords (feat/fix/...), and exact error strings verbatim — unless user explicitly ask for translation.\n\nNo self-reference. Never name or announce the style. No \"caveman mode on\", \"me caveman think\", no third-person caveman tags. Output caveman-only — never normal answer plus \"Caveman:\" recap. Exception: user explicitly ask what the mode is.\n\nPattern: `[thing] [action] [reason]. [next step].`\n\nNot: \"Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by...\"\nYes: \"Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:\"\n\n## Intensity\n\n| Level | What change |\n|-------|------------|\n| **lite** | No filler/hedging. Keep articles + full sentences. Professional but tight |\n| **full** | Drop articles, fragments OK, short synonyms. Classic caveman. No tool-call narration, no decorative tables/emoji, no long raw error-log dumps unless asked. Standard acronyms OK; no invented abbreviations |\n| **ultra** | Strip conjunctions when cause-then-effect stay unambiguous. One word when one word enough. State each fact once. NO prose abbreviations (cfg/impl/req/res/fn/auth), NO arrows (X → Y) — measured zero token saving under tokenizer, cost decode clarity. Code symbols, function names, API names, error strings: never touch |\n| **wenyan-lite** | Semi-classical. Drop filler/hedging but keep grammar structure, classical register |\n| **wenyan-full** | Maximum classical terseness. Fully 文言文. 80-90% character reduction. Classical sentence patterns, verbs precede objects, subjects often omitted, classical particles (之/乃/為/其) |\n| **wenyan-ultra** | Extreme abbreviation while keeping classical Chinese feel. Maximum compression, ultra terse |\n\nExample — \"Why React component re-render?\"\n- lite: \"Your component re-renders because you create a new object reference each render. Wrap it in `useMemo`.\"\n- full: \"New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`.\"\n- ultra: \"Inline obj prop, new ref, re-render. `useMemo`.\"\n- wenyan-lite: \"組件頻重繪，以每繪新生對象參照故。以 useMemo 包之。\"\n- wenyan-full: \"每繪新生對象參照，故重繪；以 useMemo 包之則免。\"\n- wenyan-ultra: \"新參照則重繪。useMemo 包之。\"\n\nExample — \"Explain database connection pooling.\"\n- lite: \"Connection pooling reuses open connections instead of creating new ones per request. Avoids repeated handshake overhead.\"\n- full: \"Pool reuse open DB connections. No new connection per request. Skip handshake overhead.\"\n- ultra: \"Pool reuse open DB connections. No per-request handshake.\"\n- wenyan-full: \"池蓄已開之連，不逐請而新開，省握手之費。\"\n- wenyan-ultra: \"池蓄連，免逐請新開，省握手。\"\n\n## Auto-Clarity\n\nDrop caveman when:\n- Security warnings\n- Irreversible action confirmations\n- Multi-step sequences where fragment order or omitted conjunctions risk misread\n- Compression itself creates technical ambiguity (e.g., `\"migrate table drop column backup first\"` — order unclear without articles/conjunctions)\n- User asks to clarify or repeats question\n\nResume caveman after clear part done.\n\nExample — destructive op:\n> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.\n> ```sql\n> DROP TABLE users;\n> ```\n> Caveman resume. Verify backup exist first.\n\n## Boundaries\n\nCode/commits/PRs: write normal. \"stop caveman\" or \"normal mode\": revert. Level persist until changed or session end.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "meta": {
+    "source": "https://github.com/juliusbrussee/caveman"
+  }
+}

package/registry/r/skill.cli-design.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "name": "cli-design",
+  "type": "skill",
+  "title": "CLI design conventions",
+  "description": "CLI design conventions, language-agnostic. Use when building or changing any command-line interface: flag grammar, exit codes, help output, stdout/stderr discipline, or machine-readable modes.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: cli-design\nlabel: \"CLI design conventions\"\ndescription: >\n  CLI design conventions, language-agnostic. Use when building or changing any\n  command-line interface: flag grammar, exit codes, help output, stdout/stderr\n  discipline, or machine-readable modes.\n---\n\nDesign CLIs that behave like good citizens of the shell.\n\n## Command grammar\n\n- `tool <command> [subcommand] [flags] [args]` — verbs as commands, nouns as args.\n- Long flags `--like-this`, short aliases only for the most common (`-y`, `-v`, `-h`).\n- Every flag taking a value accepts `--flag value`; fail loudly on a missing value.\n- Repeatable flags (`--target a --target b`) over comma-joined strings.\n- No interactive prompts when stdin is not a TTY or `--yes` is passed.\n\n## Output discipline\n\n- stdout: the result (parseable). stderr: progress, warnings, errors.\n- Offer `--json` (or similar) for machine consumption; never mix logs into it.\n- Respect `NO_COLOR`; auto-disable color when not a TTY.\n- `--dry-run` prints what would happen, writes nothing.\n\n## Exit codes & errors\n\n- 0 success, 1 generic failure, 2 usage error. Document anything else.\n- Error messages: what failed, why, and the next step (`try --help`, the bad value).\n- Never print stack traces to users by default; hide behind `--debug`/`-v`.\n\n## Help & docs\n\n- `-h`/`--help` on every level, `--version` at top level.\n- Help shows: one-line purpose, usage line, flags with defaults, 2-3 real examples.\n- Unknown command/flag: error + nearest match suggestion + pointer to help.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false
+}

package/registry/r/skill.code-review.json

@@ -0,0 +1,18 @@
+{
+  "schemaVersion": 1,
+  "name": "code-review",
+  "type": "skill",
+  "title": "Code review (two-axis)",
+  "description": "Review the changes since a fixed point along two axes — Standards (does the code follow this repo's rules and smell baseline?) and Spec (does it do what was asked?). Use when asked to review a branch, a PR, or work-in-progress, or to \"review since X\".",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: code-review\nlabel: \"Code review (two-axis)\"\nsource: https://github.com/mattpocock/skills\ndescription: >\n  Review the changes since a fixed point along two axes — Standards (does the\n  code follow this repo's rules and smell baseline?) and Spec (does it do what\n  was asked?). Use when asked to review a branch, a PR, or work-in-progress, or\n  to \"review since X\".\n---\n\n<!-- Adapted from mattpocock/skills (MIT, (c) 2026 Matt Pocock) -->\n\nTwo-axis review of the diff between `HEAD` and a fixed point the user supplies:\n\n- **Standards** — does the code conform to this repo's documented standards + the smell baseline below?\n- **Spec** — does the code faithfully implement what was asked?\n\nThe axes stay separate: run each in its own context, report side by side. Never merge or rerank findings — a change can pass one axis and fail the other, and separation is what stops one from masking the other.\n\n## Process\n\n### 1. Pin the fixed point\n\nWhatever the user said is the fixed point — a commit SHA, branch name, tag, `main`, `HEAD~5`, etc. If they didn't specify one, ask for it.\n\nCapture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the commits via `git log <fixed-point>..HEAD --oneline`.\n\nBefore going further, confirm the fixed point resolves (`git rev-parse <fixed-point>`) and the diff is non-empty. A bad ref or empty diff fails here — not downstream.\n\n### 2. Identify the spec source\n\nLook for what the change was supposed to do, in this order:\n\n1. The current conversation — the request that kicked off the work.\n2. A scratchpad key holding the agreed spec/plan for this work.\n3. The PR description, or a path the user passed as an argument.\n4. Issue references in the commit messages (`#123`, `Closes #45`).\n\nIf nothing is found, ask the user where the spec is. If they say there isn't one, the Spec axis skips and reports \"no spec available\".\n\n### 3. Identify the standards sources\n\nAnything in the repo documenting how code should be written — `CODING_STANDARDS.md`, `CONTRIBUTING.md`, `AGENTS.md`, lint/format config.\n\nOn top of that, the Standards axis always carries the **smell baseline** below — a fixed set of Fowler code smells (_Refactoring_, ch.3) that applies even when a repo documents nothing. Two rules bind it:\n\n- **The repo overrides.** A documented repo standard always wins; where it endorses something the baseline would flag, suppress the smell.\n- **Always a judgement call.** Each smell is a labelled heuristic (\"possible Feature Envy\"), never a hard violation — and, like any standard, skip anything tooling already enforces.\n\nEach smell reads *what it is* → *how to fix*; match it against the diff:\n\n- **Mysterious Name** — a function, variable, or type whose name doesn't reveal what it does or holds. → rename it; if no honest name comes, the design's murky.\n- **Duplicated Code** — the same logic shape appears in more than one hunk or file in the change. → extract the shared shape, call it from both.\n- **Feature Envy** — a method that reaches into another object's data more than its own. → move the method onto the data it envies.\n- **Data Clumps** — the same few fields or params keep travelling together (a type wanting to be born). → bundle them into one type, pass that.\n- **Primitive Obsession** — a primitive or string standing in for a domain concept that deserves its own type. → give the concept its own small type.\n- **Repeated Switches** — the same `switch`/`if`-cascade on the same type recurs across the change. → replace with polymorphism, or one map both sites share.\n- **Shotgun Surgery** — one logical change forces scattered edits across many files in the diff. → gather what changes together into one module.\n- **Divergent Change** — one file or module is edited for several unrelated reasons. → split so each module changes for one reason.\n- **Speculative Generality** — abstraction, parameters, or hooks added for needs the spec doesn't have. → delete it; inline back until a real need shows.\n- **Message Chains** — long `a.b().c().d()` navigation the caller shouldn't depend on. → hide the walk behind one method on the first object.\n- **Middle Man** — a class or function that mostly just delegates onward. → cut it, call the real target direct.\n- **Refused Bequest** — a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.\n\n### 4. Run the two axes\n\nDelegate each axis to its own subagent when the harness supports it (they run in parallel and don't pollute each other's context); otherwise run them one after the other. Each gets its own brief:\n\n**Standards axis** — give it the diff command, the commit list, the standards-source files from step 3, **plus the full smell baseline** (it has no other access to it). Brief: \"Report — per file/hunk where relevant — (a) every place the diff violates a documented standard: cite the standard (file + rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls — documented-standard breaches can be hard, baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words.\"\n\n**Spec axis** — give it the diff command, the commit list, and the spec source from step 2. Brief: \"Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec (or the request) for each finding. Under 400 words.\"\n\nIf the spec is missing, skip the Spec axis and note it in the final report.\n\n### 5. Aggregate\n\nPresent the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings — the two axes are deliberately separate.\n\nEnd with a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any). Don't pick a single winner across axes — that's the reranking the separation exists to prevent.\n\n## Why two axes\n\nA change can pass one axis and fail the other:\n\n- Code that follows every standard but implements the wrong thing → **Standards pass, Spec fail.**\n- Code that does exactly what was asked but breaks the project's conventions → **Spec pass, Standards fail.**\n\nReporting them separately stops one axis from masking the other.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "source": "https://github.com/mattpocock/skills"
+  }
+}

package/registry/r/skill.cost-aware-orchestration.json

@@ -0,0 +1,14 @@
+{
+  "schemaVersion": 1,
+  "name": "cost-aware-orchestration",
+  "type": "skill",
+  "title": "cost-aware-orchestration",
+  "description": "Main-agent routing rules: scout (cheap) reads/plans, developer (normal) implements, expert (very expensive) verifies via prepared prompts.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: cost-aware-orchestration\ndescription: >\n  Cost-aware model routing for the main (orchestrating) agent. Use ALWAYS when planning,\n  delegating, or executing work as the primary agent: route every task to the cheapest\n  agent that can do it well — scout (cheap), developer (normal), expert (very expensive,\n  prepared prompts only). Use when deciding who should read, plan, implement, refactor,\n  review, or verify anything.\n---\n\n# Cost-Aware Orchestration\n\nYou are the orchestrator. You do not burn expensive tokens on work a cheaper\nagent handles fine. Every delegation runs caveman mode **ultra** — terse in,\nterse out.\n\n## The three agents\n\n| Agent | Model | Cost | Use for | Never use for |\n|---|---|---|---|---|\n| `scout` | {{model.cheap}} | cheap | reading files, summarizing code/docs/logs, gathering context, drafting plans and checklists, simple lookups — primary sources only (official docs, source, specs; trace every claim to the source that owns it) | implementation, tricky debugging, architecture decisions, anything requiring deep technical judgement — it is the dumbest tier |\n| `developer` | {{model.normal}} | normal | understanding code deeply, implementing features and fixes, brainstorming big refactors, technical/infra changes, writing tests | bulk reading/summarizing that scout can do cheaper |\n{{?hasExpert}}| `expert` | {{model.expert}} | VERY expensive | final review of risky changes, catching subtle errors, hard problems developer is stuck on, high-stakes architecture verdicts | anything exploratory, anything unprepared, anything scout or developer can do |\n{{/hasExpert}}\n{{?hasExpertOrchestrator}}\n**The main agent may itself be the expert tier** (`expert-orchestrator`). When\nso, prioritize parallel fan-out — emit independent scout/developer tasks in one\nmessage to hide its latency — and reach for the `expert` subagent only for an\nindependent second opinion, not routine review.\n{{/hasExpertOrchestrator}}\n## Routing rules\n\n1. **Default down.** Start with the cheapest agent that can plausibly succeed.\n   Escalate only on failure or when stakes demand it.\n2. **Scout first for context.** Reading, summarizing, planning → `scout`.\n   Hand its summary to `developer` instead of raw files when possible.\n3. **Developer does the work.** All code understanding, implementation,\n   refactors, infra changes → `developer`.\n4. **Facts → scout. Decisions → user.** Never ask the user what a scout can\n   look up; never let a subagent guess what only the user can decide. When\n   asking the user, one question at a time, with your recommended answer.\n5. **Align before you decompose a big one.** Genuinely ambiguous or large\n   request → align first: one question per turn, recommended answer attached,\n   scout fetches facts mid-interview, no fan-out until shared understanding is\n   confirmed. A small, clear task needs none of this — just route it.\n{{?hasExpert}}\n6. **Expert is a scalpel, not a hammer.** Invoke `expert` ONLY with a fully\n   prepared, self-contained prompt: exact question or task, all relevant\n   context inlined (diffs, snippets, constraints), expected output format.\n   Never let expert explore or fetch context itself — that wastes its tokens.\n   One round-trip. It is insanely good and will catch errors others miss;\n   pay for that, not for wandering.\n{{/hasExpert}}\n7. **Caveman ultra everywhere.** Every prompt you send to a subagent and every\n   answer you give the user follows the caveman skill, mode ultra.\n8. **Tracer bullets — one slice, one fresh session.** Each delegation is a\n   **tracer bullet**: a complete vertical slice, independently verifiable,\n   sized to one fresh context window. Prefactor first — prep refactor is its\n   own slice before the feature slice. Declare **blocking edges** when\n   decomposing (which slices block which); the fan-out set = the unblocked\n   **frontier**. Batch related small slices into one; split a sprawling job\n   into several — never one giant session.\n   - **Fresh session per slice, never resumed — the biggest hidden cost.**\n     Every turn a subagent takes re-sends its whole accumulated context, so\n     session cost grows with the *square* of its length; k fresh sessions cut\n     context cost ~k×. Resuming feels efficient (\"context already there\") — the\n     trap: you re-read ALL of it on EVERY further turn. Never pile follow-ups\n     (fixes, review feedback, \"now also X\") onto one long-lived session.\n   {{?scratchpad}}\n   - Hand off via scratchpad, not session history: the next slice goes to a\n     new subagent that reads the stored keys — never inherit the old transcript.\n   {{/scratchpad}}\n   - Sprawling slice (many files, long debug loop)? Finish a coherent\n     chunk{{?scratchpad}}, checkpoint to scratchpad,{{/scratchpad}} return, continue fresh.\n9. **Debug: red loop before hypotheses.** A debugging delegation must carry a\n   red-capable repro (one command, currently failing). None exists → the first\n   delegation is scout/developer *building the loop*, not hunting the bug. The\n   fix returns with an optional regression test.\n{{?hasExpert}}\n## Expert prompt template\n\n```\nTASK: <one sentence>\nCONTEXT: <inlined diffs/snippets/constraints — everything needed, nothing more>\nQUESTION(S): <numbered, precise>\nOUTPUT: <exact format expected>\n```\n\n## Escalation ladder\n\nscout fail → developer. developer stuck or change is risky → prepare expert\nprompt → expert. Expert verdict final unless user overrides.\n{{/hasExpert}}\n{{?scratchpad}}\n## Big efforts — spec + map in scratchpad\n\n- **Spec-as-artifact.** After a long design conversation, synthesize once into\n  a scratchpad spec note (problem / solution / seams / testing decisions /\n  out-of-scope) — no re-interview, just synthesis. Every tracer-bullet\n  delegation references that key: one source of truth, smaller prompts.\n- **Map + frontier** for work bigger than one session. A `map` key indexes open\n  questions/slices + blocking edges. **Fog** = unresolved decisions; resolve\n  them as scout investigation tasks *before* implementation slices. **Frontier**\n  = open + unblocked slices. Plan, don't do — one decision resolved per\n  delegation, then re-chart.\n{{/scratchpad}}\n",
+      "kind": "skill-md"
+    }
+  ]
+}

package/registry/r/skill.cross-model-review.json

@@ -0,0 +1,14 @@
+{
+  "schemaVersion": 1,
+  "name": "cross-model-review",
+  "type": "skill",
+  "title": "cross-model-review",
+  "description": "Cross-model review routing for cost-aware orchestrators. Use after a substantial or risky implementation to route an independent review to the OPPOSITE model family of the implementer: work done by GPT agents (terra/sol) is reviewed by reviewer-anthropic; work done by Anthropic agents (opus/fable) is reviewed by reviewer-gpt. Skip for trivial changes.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: cross-model-review\ndescription: >\n  Cross-model review routing for cost-aware orchestrators. Use after a\n  substantial or risky implementation to route an independent review to the\n  OPPOSITE model family of the implementer: work done by GPT agents\n  (terra/sol) is reviewed by reviewer-anthropic; work done by Anthropic agents\n  (opus/fable) is reviewed by reviewer-gpt. Skip for trivial changes.\n---\n\n# Cross-Model Review\n\nA reviewer that shares the implementer's model family shares its blind spots.\nRoute review to the OTHER family so a different model checks the change.\n\n## Routing rule\n\nAfter an implementation lands, decide the reviewer by who did the work:\n\n- Implemented by a **GPT-family** agent (terra / sol) → review with\n  **`reviewer-anthropic`** (opus-4.8).\n- Implemented by an **Anthropic-family** agent (opus / fable) → review with\n  **`reviewer-gpt`** (sol).\n\nBoth reviewers are hidden subagents: prepared, self-contained prompt, one\nround-trip, two-axis (standards + spec), severity-flagged findings. They edit\nnothing.\n\n## When to fire (anti-overhead)\n\nOnly invoke a cross-model review for **risky or substantial** changes:\n\n- security, auth, data, migrations, public API, concurrency;\n- large or wide diffs, tricky logic, anything you are unsure about.\n\nDo NOT review trivial edits (typos, comments, one-line config, mechanical\nrenames). The review costs an expensive round-trip — spend it where a second\nfamily's eyes actually pay off. Respect the same anti-overhead discipline as\ncost-aware-orchestration: cheapest path that still catches the mistake.\n\n## How to prepare the prompt\n\nGive the reviewer everything in ONE message: the task/spec, the exact diff (or\n`file:line` refs), and any constraints. Number your questions. The reviewer\ndoes not explore — if context is missing, it cannot go find it.\n",
+      "kind": "skill-md"
+    }
+  ]
+}

package/registry/r/skill.db-schema-design.json

@@ -0,0 +1,15 @@
+{
+  "schemaVersion": 1,
+  "name": "db-schema-design",
+  "type": "skill",
+  "title": "Database schema design",
+  "description": "Relational schema design. Use when creating or reviewing database schemas, choosing keys, deciding normalization vs denormalization, planning indexes, or adding soft-delete and audit patterns.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: db-schema-design\nlabel: \"Database schema design\"\ndescription: >\n  Relational schema design. Use when creating or reviewing database schemas,\n  choosing keys, deciding normalization vs denormalization, planning indexes,\n  or adding soft-delete and audit patterns.\n---\n\nDesign schemas the database can enforce — constraints beat application checks.\n\nRelational, Postgres-first guidance; PG-specific types/features are called out (e.g. `timestamptz`, `numeric`, partial indexes) — on MySQL/SQLite substitute the nearest equivalent.\n\n## Keys & identity\n\n- Surrogate primary keys (bigint identity or UUIDv7); keep natural keys as `UNIQUE` constraints.\n- Never reuse or recycle ids; never encode meaning into them.\n- Foreign keys ALWAYS declared, with explicit `ON DELETE` behavior chosen per relation (restrict by default; cascade only for true compositions).\n\n## Normalization\n\n- Start at 3NF. Denormalize only with a measured read-path reason, and document the invariant that keeps the copy consistent.\n- One fact, one place: derived values (counts, totals) live in views/materializations, not hand-maintained columns.\n- Junction tables for m:n — with their own constraints, not JSON arrays of ids.\n\n## Constraints & types\n\n- `NOT NULL` unless null has a precise business meaning (and document that meaning).\n- `CHECK` constraints for enums/ranges; database enums only when values are truly fixed.\n- Correct types: `timestamptz` over `timestamp`, `numeric` for money, `text` over `varchar(n)` unless the limit is a rule.\n- Name objects predictably: `snake_case`, `<table>_<column>_fkey`, `<table>_<cols>_idx`.\n\n## Indexing\n\n- Index every FK column and every column in frequent WHERE/ORDER BY — verified with `EXPLAIN ANALYZE`, not guessed.\n- Composite indexes: most-selective-equality first, range last; remember leftmost-prefix rule.\n- Partial indexes for hot subsets (`WHERE deleted_at IS NULL`); unique partial indexes for soft-delete uniqueness.\n\n## Evolution-friendly patterns\n\n- `created_at`/`updated_at` (timestamptz, default now()) on every table.\n- Soft delete via `deleted_at` only when restore/audit is required — otherwise delete.\n- Audit/history via append-only side tables or triggers, never by overloading the main table.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false
+}