use-agentz 0.1.0

package/registry/r/skill.diagnosing-bugs.json

@@ -0,0 +1,23 @@
+{
+  "schemaVersion": 1,
+  "name": "diagnosing-bugs",
+  "type": "skill",
+  "title": "Diagnosing bugs",
+  "description": "Diagnosis loop for hard bugs and performance regressions: build a red-capable feedback loop before hypothesising, then reproduce, rank causes, instrument, fix at a seam. Use when asked to diagnose or debug a stubborn failure, or when a bug resists a quick fix.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: diagnosing-bugs\nlabel: \"Diagnosing bugs\"\nsource: https://github.com/mattpocock/skills\ndescription: >\n  Diagnosis loop for hard bugs and performance regressions: build a red-capable\n  feedback loop before hypothesising, then reproduce, rank causes, instrument,\n  fix at a seam. Use when asked to diagnose or debug a stubborn failure, or when\n  a bug resists a quick fix.\n---\n<!-- Adapted from mattpocock/skills (MIT, (c) 2026 Matt Pocock) -->\n\n> Build the feedback loop first. Everything else just consumes it.\n\nDiscipline for hard bugs. Skip a phase only with an explicit reason.\n\n## Phase 1: build a feedback loop\n\n**This is the skill.** With a tight pass/fail signal that goes red on _this_ bug, bisection, hypothesis-testing and instrumentation all just consume it. Without one, staring at code will not save you. Spend disproportionate effort here — be aggressive, be creative, refuse to give up.\n\nWays to construct one, roughly in order:\n\n- Failing **test** at whatever seam reaches the bug (unit / integration / e2e).\n- **Curl / HTTP script** against a running dev server.\n- **CLI invocation** with a fixture input, diffing stdout vs a known-good snapshot.\n- **Headless browser** (Playwright / Puppeteer) — drives the UI, asserts DOM/console/network.\n- **Replay a captured trace** — save a real request/payload/event log, replay it through the code path in isolation.\n- **Throwaway harness** — minimal subset of the system (one service, mocked deps) exercising the bug path in one call.\n- **Property / fuzz loop** — \"sometimes wrong output\" → 1000 random inputs, watch for the failure.\n- **Bisection harness** — bug appeared between two known states → automate \"boot at state X, check, repeat\" for `git bisect run`.\n- **Differential loop** — same input through old vs new (or two configs), diff outputs.\n- **HITL bash script** — last resort when a human must click; drive them with `scripts/hitl-loop.template.sh` so the loop stays structured and its output feeds back to you.\n\nTighten the loop — treat it as a product:\n\n- Faster (cache setup, skip unrelated init, narrow scope).\n- Sharper signal (assert the specific symptom, not \"didn't crash\").\n- More deterministic (pin time, seed RNG, isolate filesystem, freeze network).\n\nA 2-second deterministic loop is a superpower; a 30-second flaky one is barely better than none. For non-deterministic bugs the goal is a **higher reproduction rate**, not a clean repro — loop the trigger 100×, parallelise, add stress, inject sleeps. 50%-flake is debuggable; 1% is not.\n\n**Cannot build a loop?** Stop and say so. List what you tried. Ask the user for (a) access to an environment that reproduces it, (b) a captured artifact (HAR, log dump, core dump, timestamped recording), or (c) permission for temporary instrumentation. Do not hypothesise without a loop.\n\nDone when you can name **one command** — script path, test invocation, curl — that you have **already run** (paste invocation + output) and that is:\n\n- [ ] **Red-capable** — drives the real bug code path and asserts the user's exact symptom; goes red now, green once fixed. Not \"runs without erroring\".\n- [ ] **Deterministic** — same verdict every run (flaky bugs: pinned high reproduction rate).\n- [ ] **Fast** — seconds, not minutes.\n- [ ] **Agent-runnable** — runnable unattended; a human only in the loop via the HITL script.\n\nIf you catch yourself reading code to build a theory before this command exists, **stop** — jumping to a hypothesis is the exact failure this prevents. **No red-capable command, no Phase 2.**\n\n## Phase 2: reproduce + minimise\n\nRun the loop. Watch it go red. Confirm:\n\n- [ ] It produces the failure the **user** described — not a different one nearby. Wrong bug = wrong fix.\n- [ ] Reproducible across runs (non-deterministic: at a high enough rate to debug against).\n- [ ] Exact symptom captured (error message, wrong output, slow timing) so later phases can verify the fix.\n\nThen **minimise** — shrink to the smallest scenario that still goes red. Cut inputs, callers, config, data, steps **one at a time**, re-running after each cut. Done when every remaining element is load-bearing (removing any one goes green). A minimal repro shrinks the hypothesis space and becomes the clean regression test. Do not proceed until reproduced **and** minimised.\n\n## Phase 3: hypothesise\n\n- Generate **3–5 ranked hypotheses** before testing any. Single-hypothesis generation anchors on the first plausible idea.\n- Each must be **falsifiable** — state its prediction: \"If X is the cause, changing Y makes the bug disappear / changing Z makes it worse.\" No prediction = a vibe; discard or sharpen it.\n- **Show the ranked list to the user before testing.** They often re-rank instantly (\"we just deployed a change to #3\") or know ones already ruled out. Cheap checkpoint. Don't block — proceed with your ranking if the user is AFK.\n\n## Phase 4: instrument\n\n- Each probe maps to a specific Phase-3 prediction. **Change one variable at a time.**\n- Prefer debugger / REPL inspection (one breakpoint beats ten logs); then targeted logs at the boundaries that distinguish hypotheses. Never \"log everything and grep\".\n- **Tag every debug log** with a unique prefix, e.g. `[DEBUG-a4f2]`, so cleanup is a single grep. Untagged logs survive; tagged logs die.\n- **Perf regressions:** logs are usually wrong. Establish a baseline (timing harness, `performance.now()`, profiler, query plan), then bisect. Measure first, fix second.\n\n## Phase 5: fix + regression test\n\nWrite the regression test **before the fix**, but only if a **correct seam** exists — one where the test exercises the real bug pattern as it occurs at the call site. A too-shallow seam (single-caller test for a multi-caller bug, unit test that can't replicate the triggering chain) gives false confidence.\n\n- **No correct seam is itself the finding** — note it; the architecture is preventing the bug from being locked down.\n- Correct seam exists: turn the minimised repro into a failing test at that seam → watch it fail → apply the fix → watch it pass → re-run the Phase 1 loop against the original (un-minimised) scenario.\n\n## Phase 6: cleanup\n\nRequired before declaring done:\n\n- [ ] Original repro no longer reproduces (re-run the Phase 1 loop).\n- [ ] Regression test passes (or absence of a seam is documented).\n- [ ] All `[DEBUG-...]` instrumentation removed (grep the prefix).\n- [ ] Throwaway prototypes deleted (or moved to a clearly-marked debug location).\n- [ ] The hypothesis that proved correct is stated in the commit / PR message, so the next debugger learns.\n\nThen ask: **what would have prevented this bug?** If the answer is architectural (no good test seam, tangled callers, hidden coupling), record the recommendation — after the fix is in, not before; you know more now than at the start.\n",
+      "kind": "skill-md"
+    },
+    {
+      "path": "scripts/hitl-loop.template.sh",
+      "content": "#!/usr/bin/env bash\n# Adapted from mattpocock/skills (MIT, (c) 2026 Matt Pocock)\n# Human-in-the-loop reproduction loop.\n# Copy this file, edit the steps below, and run it.\n# The agent runs the script; the user follows prompts in their terminal.\n#\n# Usage:\n#   bash hitl-loop.template.sh\n#\n# Two helpers:\n#   step \"<instruction>\"          → show instruction, wait for Enter\n#   capture VAR \"<question>\"      → show question, read response into VAR\n#\n# At the end, captured values are printed as KEY=VALUE for the agent to parse.\n\nset -euo pipefail\n\nstep() {\n  printf '\\n>>> %s\\n' \"$1\"\n  read -r -p \"    [Enter when done] \" _\n}\n\ncapture() {\n  local var=\"$1\" question=\"$2\" answer\n  printf '\\n>>> %s\\n' \"$question\"\n  read -r -p \"    > \" answer\n  printf -v \"$var\" '%s' \"$answer\"\n}\n\n# --- edit below ---------------------------------------------------------\n\nstep \"Open the app at http://localhost:3000 and sign in.\"\n\ncapture ERRORED \"Click the 'Export' button. Did it throw an error? (y/n)\"\n\ncapture ERROR_MSG \"Paste the error message (or 'none'):\"\n\n# --- edit above ---------------------------------------------------------\n\nprintf '\\n--- Captured ---\\n'\nprintf 'ERRORED=%s\\n' \"$ERRORED\"\nprintf 'ERROR_MSG=%s\\n' \"$ERROR_MSG\"\n",
+      "kind": "raw"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "source": "https://github.com/mattpocock/skills"
+  }
+}

package/registry/r/skill.diagrams.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "diagrams",
+  "type": "skill",
+  "title": "Diagrams & rendered docs",
+  "description": "Generating architecture/ER/flow diagrams and rendered docs as code: Mermaid first, Python tooling (diagrams, matplotlib) for images that need rendering. Use when asked to create diagrams, schema visualizations, or image/doc artifacts.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: diagrams\nlabel: \"Diagrams & rendered docs\"\ndependencies: [python3, pip]\ndescription: >\n  Generating architecture/ER/flow diagrams and rendered docs as code:\n  Mermaid first, Python tooling (diagrams, matplotlib) for images that need\n  rendering. Use when asked to create diagrams, schema visualizations, or\n  image/doc artifacts.\n---\n\nDiagrams are code: text sources in the repo, rendered artifacts reproducible.\n\n## Tool choice\n\n- **Mermaid** (default): flowcharts, sequence, ER, state — renders natively on GitHub/GitLab; embed fenced ```mermaid blocks directly in markdown, no toolchain needed.\n- **Python `diagrams`** (`pip install diagrams`, needs graphviz): cloud/infra architecture with provider icons → PNG/SVG.\n- **matplotlib/plotly**: data plots for docs.\n- Pick the lightest tool that the target platform can display.\n\n## Mermaid rules\n\n- ER: `erDiagram` with crow's-foot cardinality (`||--o{`) and key columns only — diagrams show relationships, not full DDL.\n- Keep one diagram per concern; >15 nodes means split it.\n- Quote labels with special characters; prefer `LR` direction for wide flows, `TB` for hierarchies.\n- Render to SVG only when the platform can't render Mermaid: `npx -y @mermaid-js/mermaid-cli -i x.mmd -o x.svg`.\n\n## Python rendering\n\n- Run via a venv/uv, never global pip: `python3 -m venv .venv && .venv/bin/pip install diagrams`.\n- Scripts live next to their output (`docs/diagrams/architecture.py` → `architecture.png`); regenerating must be a single command, documented in the script header.\n- Commit BOTH source and rendered artifact; CI may re-render to detect drift.\n\n## Doc hygiene\n\n- Every generated image gets alt text and a caption referencing its source file.\n- Date or version diagrams that describe evolving systems.\n- Never hand-edit a rendered artifact — fix the source and re-render.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "python3",
+      "pip"
+    ]
+  }
+}

package/registry/r/skill.docx-create.json

@@ -0,0 +1,20 @@
+{
+  "schemaVersion": 1,
+  "name": "docx-create",
+  "type": "skill",
+  "title": "DOCX creation",
+  "description": "Creating and editing Word documents with the docx npm package on Bun: reports, memos, letters, templates, headings, tables, images, TOC, headers/footers, and tracked changes/comments via the XML-edit path. Use whenever asked to produce, generate, or edit a .docx / Word document.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: docx-create\nlabel: \"DOCX creation\"\ndependencies: [bun]\nsource: https://github.com/anthropics/skills/tree/main/skills/docx\ndescription: >\n  Creating and editing Word documents with the docx npm package on Bun:\n  reports, memos, letters, templates, headings, tables, images, TOC,\n  headers/footers, and tracked changes/comments via the XML-edit path. Use\n  whenever asked to produce, generate, or edit a .docx / Word document.\n---\n\n# DOCX creation (docx-js)\n\nGenerate Word docs from code — reproducible scripts, no GUI tools.\n\n## Tool choice\n\n- **Create from scratch** (reports, memos, letters, templates): write a script\n  with the [`docx`](https://docx.js.org) package and run it with\n  `bun --install=fallback script.ts` — Bun auto-resolves the import.\n- **Edit an existing doc / tracked changes / comments**: a `.docx` is a ZIP of\n  XML. Unpack, edit the XML directly, repack (see Editing below).\n- Python alternative if the JS toolchain is unavailable: `python-docx` covers\n  creation, `pandoc --track-changes=all` reads tracked changes.\n\n## docx-js basics\n\n```ts\nimport { Document, Packer, Paragraph, TextRun, HeadingLevel, PageOrientation } from \"docx\"\n\nconst doc = new Document({\n  styles: { default: { document: { run: { font: \"Arial\", size: 24 } } } }, // 24 = 12pt\n  sections: [{\n    properties: { page: {\n      size: { width: 12240, height: 15840 },              // US Letter DXA\n      margin: { top: 1440, right: 1440, bottom: 1440, left: 1440 }, // 1440 = 1 inch\n    } },\n    children: [\n      new Paragraph({ heading: HeadingLevel.HEADING_1, children: [new TextRun(\"Quarterly Report\")] }),\n      new Paragraph({ children: [new TextRun(\"Body text.\")] }),\n    ],\n  }],\n})\nawait Bun.write(\"report.docx\", await Packer.toBuffer(doc))\n```\n\n- **DXA units**: 1440 DXA = 1 inch. US Letter 12240 x 15840, content width 9360.\n- **Set page size explicitly** — docx-js defaults to A4, not US Letter.\n- **Landscape**: pass portrait dims (short edge as `width`, long as `height`)\n  plus `orientation: PageOrientation.LANDSCAPE`; docx-js swaps them internally.\n- Override built-in heading styles via exact IDs `\"Heading1\"`, `\"Heading2\"`;\n  set `outlineLevel` (0 for H1) — required for a working TOC.\n\n## docx-js gotchas (invalid XML or broken rendering)\n\n- **Never `\\n`** — one `Paragraph` per line; `PageBreak` must sit inside a\n  `Paragraph`.\n- **Never unicode bullets** (`•`) — use a `numbering` config with\n  `LevelFormat.BULLET`. Same `reference` continues numbering; a new one restarts.\n- **Tables need dual widths**: set `columnWidths` on the table AND `width` on\n  each cell (must match), always `WidthType.DXA` — `PERCENTAGE` breaks in Google\n  Docs. Table width = sum of `columnWidths`. Use `ShadingType.CLEAR` (never\n  SOLID → black boxes); add cell `margins` for padding.\n- **Never use tables as dividers/rules** — empty cells render as boxes. Use a\n  bottom `border` on a `Paragraph` instead; two-column footers via tab stops.\n- `ImageRun` requires `type` (`\"png\"`/`\"jpg\"`/...) and a full `altText`.\n- TOC requires `HeadingLevel`-only headings — no custom styles on those paras.\n\n## Editing existing documents (unpack → edit → pack)\n\n`.docx` is a ZIP of XML. Unpack, edit `word/document.xml` with the Edit tool\n(not Python scripts — direct string replacement is clearer), repack.\n\n- **Use \"Claude\" as the author** for tracked changes/comments unless told\n  otherwise.\n- **Smart quotes**: insert XML entities so they survive — `&#x2019;` (’),\n  `&#x201C;`/`&#x201D;` (“ ”).\n- Add `xml:space=\"preserve\"` to any `<w:t>` with leading/trailing spaces.\n\n### Tracked changes\n\nInsertion `<w:ins>`, deletion `<w:del>` (use `<w:delText>` not `<w:t>` inside):\n\n```xml\n<w:del w:id=\"1\" w:author=\"Claude\" w:date=\"2025-01-01T00:00:00Z\">\n  <w:r><w:delText>30</w:delText></w:r>\n</w:del>\n<w:ins w:id=\"2\" w:author=\"Claude\" w:date=\"2025-01-01T00:00:00Z\">\n  <w:r><w:t>60</w:t></w:r>\n</w:ins>\n```\n\n- Mark only what changes; replace whole `<w:r>` blocks and copy the original\n  `<w:rPr>` into the change runs to keep formatting.\n- Deleting a whole paragraph: also mark the paragraph mark deleted\n  (`<w:del/>` inside `<w:pPr><w:rPr>`), else accepting leaves an empty para.\n- Reject another author's insertion by nesting your `<w:del>` inside their\n  `<w:ins>`; restore their deletion by adding a fresh `<w:ins>` after it.\n\n## QA (always)\n\n- Reload with `Packer`/re-open; assert the file exists, is non-empty.\n- Extract text (`pandoc --track-changes=all doc.docx -o out.md`) and grep for\n  required content and leftover placeholders.\n- Validate the XML after any hand-edit; fix nesting/relationship errors before\n  declaring success. Render to PDF (LibreOffice) and eyeball tables/images if\n  layout matters.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "meta": {
+    "systemDependencies": [
+      "bun"
+    ],
+    "source": "https://github.com/anthropics/skills/tree/main/skills/docx"
+  }
+}

package/registry/r/skill.domain-modeling.json

@@ -0,0 +1,18 @@
+{
+  "schemaVersion": 1,
+  "name": "domain-modeling",
+  "type": "skill",
+  "title": "Domain modeling",
+  "description": "Actively build and sharpen a project's domain model. Use when pinning down domain terminology or a ubiquitous language, recording an architectural decision, or when another skill needs to maintain the domain model.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: domain-modeling\nlabel: \"Domain modeling\"\nsource: https://github.com/mattpocock/skills\ndescription: >\n  Actively build and sharpen a project's domain model. Use when pinning down\n  domain terminology or a ubiquitous language, recording an architectural\n  decision, or when another skill needs to maintain the domain model.\n---\n\n<!-- Adapted from mattpocock/skills (MIT, (c) 2026 Matt Pocock) -->\n\n# Domain Modeling\n\nActively build and sharpen the domain model *as you design* — challenge terms,\ninvent edge-case scenarios, write the glossary and decisions down the moment\nthey crystallise. Merely *reading* a glossary for vocabulary is not this skill;\nthis is for when you are *changing* the model.\n\nKeep the glossary and decisions wherever the repo already keeps such docs (a\n`GLOSSARY.md`/`CONTEXT.md`, an `docs/adr/` or `docs/decisions/` dir). Create\nlazily — only when there is a term to resolve or a decision to record.\n\n## During the session\n\n- **Challenge against the glossary.** A term that conflicts with existing\n  language: call it out at once. \"Glossary defines 'cancellation' as X, you\n  seem to mean Y — which?\"\n- **Sharpen fuzzy language.** Vague or overloaded term: propose a precise\n  canonical one. \"'account' — Customer or User? Different things.\"\n- **Probe with concrete scenarios.** Stress-test domain relationships with\n  specific edge cases that force precision about boundaries between concepts.\n- **Cross-reference the code.** User states how something works: check the code\n  agrees. Contradiction: surface it.\n- **Capture inline.** A term resolved: write it to the glossary right there,\n  don't batch. The glossary is a glossary — no implementation details, no spec,\n  no scratch pad.\n\n## Record decisions sparingly\n\nRecord an architectural decision (an ADR, however the repo files them) only\nwhen all three hold:\n\n1. **Hard to reverse** — changing your mind later costs something real.\n2. **Surprising without context** — a future reader will ask \"why this way?\"\n3. **A real trade-off** — genuine alternatives existed, you picked one for\n   specific reasons.\n\nAny one missing: skip it. Each decision record states the context, the\ndecision, and the trade-off — enough that a future explorer does not\nre-litigate it.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "source": "https://github.com/mattpocock/skills"
+  }
+}

package/registry/r/skill.frontend-qa.json

@@ -0,0 +1,19 @@
+{
+  "schemaVersion": 1,
+  "name": "frontend-qa",
+  "type": "skill",
+  "title": "frontend-qa",
+  "description": "Tiered verification gate for frontend work. Use when asked to verify, QA, or visually test a frontend change, or when a visual change is clearly risky (new page, layout overhaul, theming): real-browser checks (Playwright), light/dark theme, contrast, accessibility, console errors, forced-state walks, and screenshot evidence. Load design-taste alongside as the aesthetic foundation.",
+  "dependencies": [
+    "skill:design-taste",
+    "tool:a11y-quick",
+    "tool:design-lint"
+  ],
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: frontend-qa\ndescription: >\n  Tiered verification gate for frontend work. Use when asked to verify, QA, or\n  visually test a frontend change, or when a visual change is clearly risky (new\n  page, layout overhaul, theming): real-browser checks (Playwright), light/dark\n  theme, contrast, accessibility, console errors, forced-state walks, and\n  screenshot evidence. Load design-taste alongside as the aesthetic foundation.\nrequires: [design-taste]\n---\n\n# frontend-qa\n\n## Scope\n\nFinal gate for visual or UI change: new screens, redesigns, component edits,\ncopy tweaks, theming, micro-frontend work. First classify the change into a\ntier (section 0), then run the static gate (section 1), then run the browser\nloop at the depth the tier requires (T0 = none, T1 = one page, T2 = full\nmatrix). Nothing ships on \"looks right in the code\".\n\n## 0. Tier classification\n\nClassify the change FIRST; it decides how deep the browser loop goes. The\nstatic gate (section 1) runs at every tier.\n\n| Tier | Change scope | Verification |\n|---|---|---|\n| T0 static-only | Copy tweak; single token/class change; logic-only change touching UI files; one-field add with no layout impact. | Static gate on touched files (design-lint + a11y-quick + contrast-check pair). NO browser. |\n| T1 spot-check | New or edited component on an existing screen; style change WITH layout impact; state logic on one view. | Static gate + ONE page in the browser: screenshot BOTH themes + zero new console errors. No forced-state walk, no tab-through, no multi-width. |\n| T2 full matrix | Redesigns; new screens or layouts; theming or token changes; bulk design work; complicated UI (wizards, dashboards, data tables); anything touching 3+ screens. | Static gate + full matrix (Marketing or Product per the selection rule in section 5). |\n\nEscalation rule: uncertain which tier fits → go one tier up. A T0 or T1 check\nthat hints at layout breakage → escalate one tier and re-verify at that depth.\n\n## 1. Static gate (run first, fix before opening a browser)\n\nRun order, tools live in `.opencode/tool/`:\n\n1. `design-lint`: banned fonts, banned hexes, em-dashes in visible strings,\n   AI cliche copy, fake brand names.\n2. `a11y-quick`: missing alt text, unlabeled icon buttons, suppressed focus\n   styles, broken heading order.\n3. `contrast-check`: key pairs in BOTH themes: body/background,\n   muted-foreground/muted, primary-foreground/primary, CTA text/CTA surface.\n4. `token-validate`: only when the project has a design-tokens convention\n   (semantic tokens required, raw palette/hex banned).\n\nOnly ERROR findings block. Fix the code, re-run the failing tool, THEN start\nthe browser loop. Screenshotting a page that fails static checks wastes a full\nloop. WARN/INFO findings do NOT block: carry them into the QA report as review\nnotes, fix them only when they are real problems in context.\n\nTools are heuristics. A skill rule or a deliberate documented design choice\nbeats a tool WARN.\n\n## 2. Browser loop (Playwright)\n\nPrefer the playwright MCP server when available (`browser_navigate`,\n`browser_resize`, `browser_take_screenshot`, `browser_snapshot`,\n`browser_console_messages`). Otherwise use the script below. One-time setup\nper repo: `bun add -d playwright && bunx playwright install chromium`.\n\n```js\n// qa.mjs  usage: bun qa.mjs <url> <prefix> [widths] [mode]\n//   mode = media (default) | class   e.g. bun qa.mjs http://localhost:3000/crm crm 1280,1024,375 class\nimport { chromium } from \"playwright\";\nconst [url, prefix = \"qa\", widthArg = \"1280,1024\", mode = \"media\"] = process.argv.slice(2);\nconst widths = widthArg.split(\",\").map(Number);\nconst browser = await chromium.launch();\nconst errors = [];\nfor (const theme of [\"light\", \"dark\"]) {\n  const page = await browser.newPage({ colorScheme: theme });\n  page.on(\"console\", m => { if (m.type() === \"error\") errors.push(`[${theme}] ${m.text()}`); });\n  page.on(\"pageerror\", e => errors.push(`[${theme}] ${e.message}`));\n  await page.goto(url, { waitUntil: \"networkidle\" });\n  // class-based theming: toggle the .dark class on the dark pass\n  if (mode === \"class\" && theme === \"dark\") await page.evaluate(() => document.documentElement.classList.add(\"dark\"));\n  for (const w of widths) {\n    await page.setViewportSize({ width: w, height: 800 });\n    await page.screenshot({ path: `${prefix}-${theme}-${w}.png`, fullPage: true });\n    const hscroll = await page.evaluate(() => document.documentElement.scrollWidth > document.documentElement.clientWidth);\n    if (hscroll) errors.push(`[${theme}] horizontal scroll at ${w}px`);\n  }\n  console.log(`[${theme}] aria:`, (await page.locator(\"body\").ariaSnapshot()).slice(0, 1500));\n  await page.close();\n}\nawait browser.close();\nif (errors.length) { console.error(\"FAIL\\n\" + errors.join(\"\\n\")); process.exit(1); }\nconsole.log(\"PASS: screenshots written, 0 console errors\");\n```\n\nSteps, in order, per page under QA:\n\n1. Render the REAL page (dev server or host shell). No static HTML mocks.\n2. Screenshot + ARIA snapshot in BOTH themes (light and dark).\n3. Widths 1280 and 1024. Inside the host shell the sidebar consumes width,\n   so the remote must survive 1024 minus the sidebar: verify no squeezed\n   columns, no clipped toolbars, no overflow in the remote region.\n4. Forced state walk: loading (throttle or block the API route), empty\n   (empty fixture or filter to zero results), error (abort the route).\n   Screenshot each state.\n5. Tab through the page: focus visible on every interactive element, focus\n   order matches visual order, no keyboard traps.\n6. Console: zero NEW errors across all steps and both themes.\n7. Marketing pages only: repeat screenshots at 375 width; horizontal scroll\n   at 375 is a critical failure.\n\n## 3. Platform overlays\n\nPlatform overlays may add host-shell-specific QA contexts (in-shell versus\nstandalone, page enumeration, development-port maps) on top of this loop. Load\nthe relevant overlay skill when working on that platform.\n\n## 4. Honesty rules\n\n- \"Should render fine\" is NOT verification. Only screenshots, snapshots, and\n  command output count.\n- Stack not running and cannot be started: output exactly\n  \"untested: stack not running\". Do not soften or hide it.\n- Report what was ACTUALLY checked: pages, themes, widths, states, artifact\n  paths. List omissions explicitly.\n- Never tick a box from memory or from reading source. Every ticked box has\n  an artifact or command output behind it.\n- T0 (static-only) work reports \"static-verified, not browser-tested\" - a valid\n  done-state. Never claim \"browser-verified\" at T0, or at any tier without the\n  screenshots and console output to back it.\n\n## 5. Pre-flight checklists\n\n### Matrix selection (T2)\n\nA T2 change (section 0) runs a full matrix. Pick which by the skill that governs\nthe screen: `design-taste` (marketing/landing/public-facing) → Marketing matrix;\n`product-ui` (app/dashboard/admin/data) → Product matrix. The T1 spot-check\nbelow is the lighter tier, not part of the full matrix.\n\n### Marketing matrix (design-taste screens)\n\nCopy and content:\n1. Em-dash and en-dash count in visible strings = 0; ranges use hyphens.\n2. No AI cliche copy, no fake brands (design-lint clean).\n3. Eyebrow count <= ceil(sections / 3); zero numbered meta-labels.\n\nTypography and hero:\n4. H1 renders in <= 2 lines at 1280 desktop.\n5. Hero fits the initial viewport at 1280x800: headline, subtext, CTAs\n   visible without scrolling.\n6. No banned fonts (design-lint); one type system; tabular-nums on data.\n\nLayout:\n7. No horizontal scroll at 375.\n8. Multi-column collapses to one column below 768.\n9. Bento grids: N items = N cells, zero empty cells.\n10. Max 2 consecutive image+text zigzag splits; no layout family repeated\n    on one page.\n11. Content max-width applied; no full-bleed text walls.\n\nColor and theme:\n12. Page-level background not pure #000/#fff; white cards/surfaces are fine.\n13. ONE accent color, saturation below 80 percent, one gray family.\n14. No banned hexes, no AI purple-blue gradient (design-lint).\n15. Both themes pass: light and dark screenshots reviewed, no broken tokens.\n16. contrast-check passes key pairs in both themes (4.5:1 body, 3:1\n    large text and UI).\n17. CTA and button text contrast passes on every background it sits on.\n\nInteraction and accessibility:\n18. Focus visible on every interactive element; tab order matches visual\n    order.\n19. Targets >= 44px marketing.\n20. Icon-only buttons have labels or tooltips (a11y-quick clean).\n21. prefers-reduced-motion collapses ALL motion to static.\n22. Animations touch transform and opacity only; no scroll event listeners.\n\nStates, data, console:\n23. Loading, empty, and error states exist and were force-rendered.\n24. ONE primary CTA per view (hero: 1 primary + max 1 secondary).\n25. Real images with alt text; no div-built fake screenshots; empty cells\n    show \"-\" or \"Not set\".\n26. Zero new console errors across the whole loop, both themes.\n27. token-validate passes when the project has a tokens convention.\n\n### Product matrix (product-ui screens)\n\nTokens and theme:\n1. token-validate passes when the project has a tokens convention; semantic\n   tokens only, no raw palette/hex in markup.\n2. Both themes pass: light and dark screenshots reviewed, no broken tokens.\n3. contrast-check passes key pairs in both themes (4.5:1 body, 3:1\n   large text and UI).\n\nLayout and data:\n4. No overflow at 1024 minus the sidebar: no squeezed columns, clipped\n   toolbars, or overflow in the remote region.\n5. ONE primary action per view; secondary actions are visually subordinate.\n6. tabular-nums on numeric columns; numbers right-aligned, headers aligned to\n   their data.\n\nInteraction and accessibility:\n7. Focus visible on every interactive element; tab order matches visual\n   order.\n8. Targets >= 32px dense product UI.\n9. Icon-only buttons have labels or tooltips (a11y-quick clean).\n10. prefers-reduced-motion collapses ALL motion to static.\n\nStates, console, i18n:\n11. Loading, empty, and error states exist and were force-rendered.\n12. Empty cells show \"-\" or \"Not set\"; no div-built fake screenshots.\n13. Zero new console errors across the whole loop, both themes.\n14. Labels survive +30 percent text length (German); strings go through\n    `t()` where the project uses i18n.\n\n### T1 spot-check (new/edited component on an existing screen, layout-impacting style change, single-view state logic)\n\nStatic gate on touched files, then ONE page in the browser. Single page only:\nno forced-state walk, no tab-through, no multi-width sweep - that is T2.\n\n1. Em-dash and en-dash count 0 in changed strings.\n2. No AI cliche words in changed copy (design-lint on touched files).\n3. Contrast passes on touched elements (contrast-check pair).\n4. Both-theme screenshot of the changed view (light and dark).\n5. Zero new console errors on that page, both themes.\n6. Labels survive +30 percent text length (German); strings go through\n   `t()` where the project uses i18n.\n\n### Proportionality\n\n- T0 (static-only): copy tweaks, single token/class change, logic-only change\n  touching UI files, one-field add with no layout impact. Minimum = the static\n  gate on touched files; no browser. Report \"static-verified, not\n  browser-tested\".\n- T1 (spot-check): new/edited component on an existing screen, layout-impacting\n  style change, single-view state logic. Static gate + one-page browser check\n  above.\n- T2 (full matrix): new screens, new layouts, state work, theming, redesigns,\n  bulk work, complex UI, 3+ screens. Full Marketing or Product matrix per the\n  selection rule.\n- T0 minimum = the static gate on touched files. The browser only opens at T1\n  and above; there is no browser floor below T1.\n\n## 6. Failure protocol\n\nAny failed REQUIRED box = the work is NOT done. No partial credit.\n\n1. Fix the failing item in code.\n2. Re-run the static gate (cheap, catches regressions).\n3. Re-run the browser loop for affected pages.\n4. Repeat until every box passes, then report the final checklist state\n   with artifact paths.\n",
+      "kind": "skill-md"
+    }
+  ]
+}

package/registry/r/skill.go-architecture.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "go-architecture",
+  "type": "skill",
+  "title": "Go architecture & design",
+  "description": "Go architecture and design. Use when structuring packages, designing APIs, wiring dependency injection, modelling concurrency, or accessing databases in Go.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-architecture\nlabel: \"Go architecture & design\"\ndependencies: [go]\nsource: https://github.com/samber/cc-skills-golang\ndescription: >\n  Go architecture and design. Use when structuring packages, designing APIs,\n  wiring dependency injection, modelling concurrency, or accessing databases in\n  Go.\n---\n\nDesign Go for clarity and change — composition over inheritance, small interfaces, explicit wiring.\n\n## Patterns\n\n- Functional options for extensible constructors; builders only for genuinely complex assembly.\n- Accept interfaces, return structs. Define interfaces where they are CONSUMED, keep them 1-3 methods.\n- Middleware as `func(next) next` chains; circuit breakers/retries at the boundary, not sprinkled through logic.\n- Modernize: range-over-int, `min`/`max` builtins, iterators (`iter.Seq`), stdlib `slices`/`maps`/`cmp`/`slog`.\n\n## Concurrency\n\n- Plain functions + sync primitives by default; channels when ownership transfers, mutexes when guarding state.\n- Every goroutine has a defined exit path (ctx cancel, closed channel) — no fire-and-forget.\n- `errgroup.Group` for parallel fan-out with error propagation; worker pools for bounded parallelism; pipelines for streaming.\n- Always run `go test -race` in CI.\n\n## Context\n\n- `ctx context.Context` as the first param on anything that blocks, does IO, or loops. Never store it in a struct.\n- Propagate cancellation and deadlines; `signal.NotifyContext` for ctrl-C. `context.Value` only for request-scoped metadata, never optional args.\n\n## Dependency injection\n\n- Constructor injection with interfaces is enough for most apps — wire dependencies explicitly in `main`.\n- Reach for a framework only when the graph hurts: `google/wire` (compile-time), `uber/dig`/`fx` (runtime). Don't adopt DI magic prematurely.\n\n## Database\n\n- Always parameterize queries; configure the pool (`SetMaxOpenConns`, lifetimes). Scope transactions tightly and handle rollback on every error path.\n- Migrations are versioned, forward-only, and reviewed. Codegen (`sqlc`/`sqlboiler`) over hand-mapped rows for type safety.\n\nFor depth see [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang) (`golang-design-patterns`, `golang-concurrency`, `golang-context`, `golang-dependency-injection`, `golang-database`, `golang-modernize`).\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ],
+    "source": "https://github.com/samber/cc-skills-golang"
+  }
+}

package/registry/r/skill.go-ci.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "go-ci",
+  "type": "skill",
+  "title": "Go CI/CD",
+  "description": "Go CI/CD with GitHub Actions. Use when setting up or improving Go project CI: test/lint/vet workflows, SAST and vulnerability scanning, coverage gates, Dependabot/Renovate, GoReleaser release pipelines, or Docker image builds.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-ci\nlabel: \"Go CI/CD\"\ndependencies: [go]\nsource: https://github.com/samber/cc-skills-golang\ndescription: >\n  Go CI/CD with GitHub Actions. Use when setting up or improving Go project CI:\n  test/lint/vet workflows, SAST and vulnerability scanning, coverage gates,\n  Dependabot/Renovate, GoReleaser release pipelines, or Docker image builds.\n---\n\nTreat CI as a quality gate. Setup order: test → lint → security → release. Improving an existing pipeline? Read current workflows first, fill gaps, do not duplicate steps.\n\n## Pipeline stages\n\n| Stage | Tool |\n| --- | --- |\n| Test + race | `go test -race -shuffle=on` |\n| Coverage | `codecov/codecov-action` |\n| Lint | `golangci-lint` (MUST run on every PR) |\n| Vet | `go vet` |\n| SAST | `gosec`, CodeQL, Bearer |\n| Vuln scan | `govulncheck` |\n| Deps | Dependabot / Renovate |\n| Release | GoReleaser |\n\n## Testing workflow\n\n- `-race` is mandatory in CI — data races are undefined behavior.\n- `-shuffle=on` catches inter-test order dependencies; `-count=1` on integration tests defeats caching that hides flaky service calls.\n- `go mod tidy && git diff --exit-code` fails the build if go.mod drifts.\n- Adapt the Go version matrix to `go.mod`; use `fail-fast: false` so one version failing does not cancel others.\n\n## Security\n\n- `govulncheck` MUST run — reports only vulns in code paths you call, unlike generic CVE scanners.\n- CodeQL suites: `security-extended` or `security-and-quality`. Trivy for container images.\n\n## Release & deps\n\n- GoReleaser: cross-compiled binaries + checksums + GitHub Release for CLIs; minimal skip-build config for libraries; per-`cmd/` builds for monorepos.\n- Dependabot groups minor/patch into one PR, majors separate. Renovate adds native automerge, `gomodTidy`, regex managers, monorepo awareness.\n\n## Security guardrails\n\n- Pin action versions to a major (`@vN`), never `@master`.\n- Least-privilege `permissions` block per job; scope release/push jobs tightly.\n- Dependabot auto-merge needs `contents: write` + `pull-requests: write` — keep the `github.actor == 'dependabot[bot]'` guard AND branch protection with required checks (actor checks are spoofable; branch protection is the real net).\n- `push: false` on PRs so untrusted code never publishes an image. Never hardcode registry credentials.\n\nFor workflow YAML templates, codecov/CodeQL/Dependabot configs, GoReleaser variants, and repo security settings, see [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang) (`golang-continuous-integration`).\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ],
+    "source": "https://github.com/samber/cc-skills-golang"
+  }
+}

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

@@ -0,0 +1,20 @@
+{
+  "schemaVersion": 1,
+  "name": "go-cli",
+  "type": "skill",
+  "title": "Go CLI development",
+  "description": "Go CLI development. Use when building a Go command-line tool: structuring the command tree with cobra or stdlib flag, threading context and cancellation, or cross-compiling with goreleaser.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-cli\nlabel: \"Go CLI development\"\ndependencies: [go]\ndescription: >\n  Go CLI development. Use when building a Go command-line tool: structuring the\n  command tree with cobra or stdlib flag, threading context and cancellation,\n  or cross-compiling with goreleaser.\n---\n\nBuild CLIs in Go — single static binary, instant startup, trivial cross-compile.\n\n## Structure\n\n- `cmd/<tool>/main.go` stays tiny: parse, wire, call into `internal/`.\n- Small tools: stdlib `flag` is enough. Command trees: `spf13/cobra` (commands as files, `RunE` returning errors — never `os.Exit` inside commands).\n- Pass `context.Context` from main (`signal.NotifyContext` for ctrl-C) through every command; respect cancellation in loops and subprocesses.\n\n## Conventions\n\n- Print results to stdout, diagnostics to stderr (`fmt.Fprintln(os.Stderr, ...)`).\n- Return wrapped errors (`fmt.Errorf(\"loading config: %w\", err)`); main converts the final error to exit code 1 and a one-line message.\n- `--json` output via `encoding/json` on a dedicated struct — never marshal internal types directly.\n- Version via `-ldflags \"-X main.version=...\"`; expose `--version`.\n\n## Build & release\n\n- `go build ./...` must always pass; CI runs `go vet` + `golangci-lint`.\n- Cross-compile: `GOOS=linux GOARCH=arm64 go build` — no toolchain gymnastics.\n- Release automation: goreleaser (archives, checksums, homebrew taps) from a tag.\n\n## Testing\n\n- Table-driven tests for arg/flag parsing and core logic.\n- `t.TempDir()` for filesystem work; golden files for rendered output.\n- Integration: build once in `TestMain`, run the binary with `exec.CommandContext`, assert stdout/stderr/exit code.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ]
+  }
+}

package/registry/r/skill.go-data-structures.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "go-data-structures",
+  "type": "skill",
+  "title": "Go data structures",
+  "description": "Go data structures. Use when choosing or optimizing slices, maps, arrays, or container/list/heap/ring, building strings with strings.Builder vs bytes.Buffer, writing generic collections, or reasoning about slice/map internals, pointers, and copy semantics.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-data-structures\nlabel: \"Go data structures\"\ndependencies: [go]\nsource: https://github.com/samber/cc-skills-golang\ndescription: >\n  Go data structures. Use when choosing or optimizing slices, maps, arrays, or\n  container/list/heap/ring, building strings with strings.Builder vs\n  bytes.Buffer, writing generic collections, or reasoning about slice/map\n  internals, pointers, and copy semantics.\n---\n\nChoose the right structure by reasoning about memory layout, allocation cost, and access patterns — not familiarity.\n\n## Best practices\n\n- Preallocate when size is known: `make([]T, 0, n)` / `make(map[K]V, n)` — avoids repeated growth copies and rehashing. Pre-grow before bulk append with `slices.Grow`.\n- NEVER rely on slice capacity growth timing — the algorithm changed between Go versions and may change again.\n- `strings.Builder` for pure string building (avoids the copy in `String()`); `bytes.Buffer` when you need `io.Reader`/byte manipulation. Both support `Grow(n)`.\n- Generic collections use the tightest constraint: `comparable` for map keys, `cmp.Ordered` for sorting, custom interfaces for domain ordering.\n\n## Slices & maps\n\n- A slice is a 3-word header (pointer, len, cap); multiple slices can share a backing array — mind aliasing.\n- Growth: doubles below 256 elements, ~25% above; each growth copies the whole backing array (O(n)).\n- Maps are hash tables with 8-entry buckets and overflow chains; reference types (assigning copies the pointer, not the data). Maps never shrink.\n- `slices` / `maps` packages (Go 1.21+): `Sort`, `BinarySearch`, `Contains`, `Compact`, `Clone`, `Equal`, `Collect`, `Keys`, `Values`.\n- Large value types in maps: use `map[K]*V` — map access copies the entire value.\n\n## Arrays & containers\n\n- Arrays are fixed-size value types, comparable (usable as map keys). Prefer only for compile-time-known sizes (digests, IPv4, matrices); slices otherwise.\n- `container/heap` for priority queues, `container/list` ONLY for frequent middle insertion (poor cache locality — benchmark first), `container/ring` for circular buffers. These use `any` — wrap in generics for type safety.\n\n## Pointers & copy semantics\n\n- `unsafe.Pointer` MUST follow the 6 valid spec conversion patterns; NEVER store in a `uintptr` across statements — GC can move the object, leaving a dangling reference.\n- `weak.Pointer[T]` (Go 1.24+) for caches and canonicalization maps — lets GC reclaim entries.\n- Value copy (deep): scalars, arrays, structs. Header/reference copy (shared): slice (use `slices.Clone`), map (use `maps.Clone`), channel, pointer.\n\nThird-party: `emirpasic/gods`, `deckarep/golang-set`, `gammazero/deque`. For Go package facts prefer `godig` (see go-tooling) over Context7.\n\nFor internals deep dives (slice header diagram, map bucket chains, generic container patterns, pointer spec patterns), see [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang) (`golang-data-structures`, `golang-safety`).\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ],
+    "source": "https://github.com/samber/cc-skills-golang"
+  }
+}

package/registry/r/skill.go-dependencies.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "go-dependencies",
+  "type": "skill",
+  "title": "Go dependency management",
+  "description": "Go dependency management. Use when adding, removing, or upgrading Go dependencies, editing go.mod/go.sum, auditing vulnerabilities, resolving version conflicts, pinning CLI tools, setting up go.work workspaces, or automating dependency updates.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-dependencies\nlabel: \"Go dependency management\"\ndependencies: [go]\nsource: https://github.com/samber/cc-skills-golang\ndescription: >\n  Go dependency management. Use when adding, removing, or upgrading Go\n  dependencies, editing go.mod/go.sum, auditing vulnerabilities, resolving\n  version conflicts, pinning CLI tools, setting up go.work workspaces, or\n  automating dependency updates.\n---\n\nTreat every new dependency as a long-term maintenance commitment. Ask if the standard library already solves it first.\n\n## Rule: ask before adding\n\nBefore `go get` for a NEW dependency, ask the user. Agents suggest unmaintained or unnecessary packages. `go get -u` to upgrade an existing dep is safe. Before proposing, weigh: stdlib coverage, license, alternatives, why it is needed. Favor `golang.org/x/...` and established orgs over obscure packages.\n\n## Key rules\n\n- Commit `go.sum` — it records checksums; `go mod verify` detects supply-chain tampering.\n- `govulncheck ./...` before every release — catches known CVEs in code paths you actually call.\n- `go mod tidy` before every commit that changes deps — adds missing, removes unused.\n\n## Commands\n\n```bash\ngo get github.com/google/uuid@v1.6.0   # add/pin\ngo get -u=patch ./...                   # safer routine upgrade (patch only)\ngo get github.com/google/uuid@none && go mod tidy  # remove\ngo mod why -m github.com/some/module    # why a dep exists\ngo mod graph                            # requirement graph\ngo mod vendor                           # hermetic builds; commit vendor/\n```\n\nUpgrade flow: `go get -u=patch ./... && go mod tidy && go test ./... && go vet ./... && govulncheck ./...`. Review changelogs for deps touching persistence, serialization, networking, auth, crypto, or public APIs.\n\n## Pinning CLI tools\n\nGo 1.24+: `tool` directives in `go.mod`, not a `tools.go` blank-import file.\n\n```bash\ngo get -tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest\ngo tool golangci-lint run ./...   # run reproducibly\ngo install tool                    # install all into GOBIN when needed\n```\n\nGo <1.24 only: legacy `//go:build tools` blank-import fallback. Do not bump the `go` directive just to add tools; only raise it deliberately (`go mod edit -go=1.26 && go mod tidy`) when the project targets those APIs.\n\nFor MVS internals, conflict resolution (`replace`/`exclude`/`retract`), `go.work` workspaces, Dependabot/Renovate, and binary-size analysis (`goweight`), see [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang) (`golang-dependency-management`).\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ],
+    "source": "https://github.com/samber/cc-skills-golang"
+  }
+}

package/registry/r/skill.go-dev.json

@@ -0,0 +1,20 @@
+{
+  "schemaVersion": 1,
+  "name": "go-dev",
+  "type": "skill",
+  "title": "Go development",
+  "description": "Idiomatic Go development. Use when writing or reviewing any Go code, laying out packages, wrapping errors, threading context, or writing concurrent code and table-driven tests.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-dev\nlabel: \"Go development\"\ndependencies: [go]\ndescription: >\n  Idiomatic Go development. Use when writing or reviewing any Go code, laying\n  out packages, wrapping errors, threading context, or writing concurrent code\n  and table-driven tests.\n---\n\nWrite boring, idiomatic Go — clarity beats cleverness, the standard library beats frameworks.\n\nFor depth, load the sibling Go skills: `go-architecture` (package/service design, DI), `go-quality` (review, safety, security), `go-qa` (testing, benchmarking, profiling).\n\n## Layout & modules\n\n- One module per repo by default; a multi-module monorepo wired with `go.work` is legitimate when parts version independently. Packages named for what they provide (`storage`, not `utils`/`common`/`helpers`).\n- `internal/` for everything not meant for external import; `cmd/<name>/` for binaries.\n- Accept interfaces, return structs; define interfaces where they are CONSUMED, keep them small (1-3 methods).\n\n## Errors\n\n- `fmt.Errorf(\"opening config: %w\", err)` — wrap with context at every boundary; check with `errors.Is/As`.\n- Sentinel errors as package vars (`var ErrNotFound = errors.New(...)`) only when callers must branch on them.\n- No panics in library code; panic only for programmer errors at startup.\n- Handle every error or explicitly `_ =` it with a comment why.\n\n## Context & concurrency\n\n- `ctx context.Context` as first param on anything that blocks, IOs, or loops; never store ctx in structs.\n- Prefer plain functions + sync primitives; reach for channels when ownership transfers, mutexes when guarding state.\n- `errgroup.Group` for parallel fan-out with error propagation.\n\n## Testing & tooling\n\n- Table-driven tests with subtests (`t.Run`); `t.TempDir()`, `t.Setenv()` for isolation.\n- Golden files for complex output; `-update` flag convention to regenerate.\n- `go vet`, `gofmt`/`gofumpt`, `golangci-lint` in CI; race detector (`go test -race`) always on in CI.\n- Benchmarks for hot paths before optimizing — `go test -bench . -benchmem`.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ]
+  }
+}

package/registry/r/skill.go-documentation.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "go-documentation",
+  "type": "skill",
+  "title": "Go documentation",
+  "description": "Go documentation. Use when writing or reviewing godoc comments, package comments, README/CONTRIBUTING/CHANGELOG, Example test functions, API docs, or llms.txt for a Go library or application.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-documentation\nlabel: \"Go documentation\"\ndependencies: [go]\nsource: https://github.com/samber/cc-skills-golang\ndescription: >\n  Go documentation. Use when writing or reviewing godoc comments, package\n  comments, README/CONTRIBUTING/CHANGELOG, Example test functions, API docs, or\n  llms.txt for a Go library or application.\n---\n\nDocumentation is a first-class deliverable — accurate, example-driven, written for a reader who has never seen the codebase.\n\n## Writing principles\n\n- **Concision** — shortest version that carries the idea; never drop facts, warnings, or requested depth.\n- **Intent over paraphrase** — code shows _what_; docs explain _why_ it exists, _when_ to use it, _what constraints_ apply. A comment that restates the signature wastes the reader's time.\n- **No invented context** — no marketing vocabulary (`seamlessly`, `robust`, `enterprise-grade`), no groundless future promises. Leave gaps visible.\n- **Preserve modality when editing** — `must`/`should`/`may` are different obligations; keep conditions and warnings intact.\n\n## Doc comments\n\nEvery exported function, method, and type MUST have a doc comment. Package comment (`// Package foo ...`) MUST exist. Comment starts with the identifier name, then a verb phrase — godoc requires the name prefix; what it forbids is stopping there. Document parameters, return values, error cases, constraints, and a usage example. Skip test functions.\n\nDeprecation: `// Deprecated:` marker. Note bugs with `// BUG(who):`.\n\n## Project files by priority\n\nDoc comments + package comment → README → LICENSE → getting started → working examples → CONTRIBUTING → CHANGELOG. Libraries add `ExampleXxx` tests and Playground demos; apps add install/CLI-help/config docs.\n\n- **README** section order: title, badges (shields.io), 1-2 sentence summary, demo, getting started, features, contributing, contributors, license.\n- **CONTRIBUTING** — get a contributor building in under 10 minutes; if longer, add a Makefile/docker-compose/devcontainer.\n- **CHANGELOG** — Keep a Changelog format or GitHub Releases. Each entry answers what changed for the reader; internal refactors belong in commit history.\n\n## Library & AI-friendly extras\n\n- `ExampleXxx()` in `_test.go` = executable docs verified by `go test`; link Playground URLs with `// Play: https://go.dev/play/p/xxx`.\n- godoc renders on pkg.go.dev; preview locally with `go doc`.\n- `llms.txt` at repo root gives LLMs a structured overview.\n- API docs: OpenAPI (swaggo/swag) for REST, protobuf/buf for gRPC — prefer auto-generation from annotations.\n\nFor the full comment format, README/CONTRIBUTING templates, and per-project-type deep dives, see [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang) (`golang-documentation`).\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ],
+    "source": "https://github.com/samber/cc-skills-golang"
+  }
+}

package/registry/r/skill.go-ecosystem.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "go-ecosystem",
+  "type": "skill",
+  "title": "Go libraries & frameworks",
+  "description": "Go libraries and frameworks. Use when choosing between the stdlib and a third-party dependency, or wiring the samber/* ecosystem, cobra/viper, or API frameworks (gRPC, GraphQL, swagger) into Go.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-ecosystem\nlabel: \"Go libraries & frameworks\"\ndependencies: [go]\nsource: https://github.com/samber/cc-skills-golang\ndescription: >\n  Go libraries and frameworks. Use when choosing between the stdlib and a third-party\n  dependency, or wiring the samber/* ecosystem, cobra/viper, or API frameworks\n  (gRPC, GraphQL, swagger) into Go.\n---\n\nReach for the standard library first; add dependencies only when they earn their keep.\n\n## Stdlib-first\n\n- `net/http`, `encoding/json`, `slog`, `slices`/`maps`/`cmp`, `context` cover most needs. `errgroup` is not stdlib — it lives in `golang.org/x/sync/errgroup` (the official extended libraries), reach for it for parallel fan-out. Add a framework only for real, recurring complexity.\n- Pin and tidy: meaningful `go.mod`, `go mod tidy` in CI, minimal `replace` directives, tool deps tracked.\n\n## samber/* ecosystem\n\n- `samber/lo` — generic slice/map/channel helpers (`Map`, `Filter`, `GroupBy`); `lop` for parallel. Avoid where a plain `for` is clearer.\n- `samber/mo` — `Option`/`Result`/`Either` for explicit nullability and error flow.\n- `samber/do` — type-safe DI container with lifecycle and graceful shutdown.\n- `samber/oops` — structured errors with codes, stack traces, and context attributes.\n- `samber/slog-*` — multi-handler routing, sampling, and 20+ sinks for `slog`.\n- `samber/hot` — in-memory cache with LRU/LFU/S3FIFO/ARC, TTL, and metrics.\n\n## CLI & config\n\n- `spf13/cobra` for command trees (`RunE` returning errors, shell completion); `spf13/viper` for layered config with flag > env > file > default precedence.\n- For tiny tools, stdlib `flag` beats pulling in cobra.\n\n## APIs\n\n- gRPC: organize `.proto`, generate code, use interceptors for cross-cutting concerns, map errors to status codes.\n- GraphQL: `gqlgen` (schema-first, dataloaders to kill N+1). REST docs: `swaggo/swag` annotations → OpenAPI.\n\nFor per-library guides see [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang) (`golang-popular-libraries`, `golang-samber-*`, `golang-spf13-cobra`, `golang-spf13-viper`, `golang-grpc`, `golang-graphql`, `golang-swagger`).\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ],
+    "source": "https://github.com/samber/cc-skills-golang"
+  }
+}

package/registry/r/skill.go-qa.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "go-qa",
+  "type": "skill",
+  "title": "Go testing & performance",
+  "description": "Go testing and performance. Use when writing table-driven or fuzz tests, benchmarking, profiling, optimizing, adding observability, or debugging Go in production.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-qa\nlabel: \"Go testing & performance\"\ndependencies: [go]\nsource: https://github.com/samber/cc-skills-golang\ndescription: >\n  Go testing and performance. Use when writing table-driven or fuzz tests,\n  benchmarking, profiling, optimizing, adding observability, or debugging Go in\n  production.\n---\n\nProve it works, prove it's fast, see it in production.\n\n## Testing\n\n- Table-driven tests with subtests (`t.Run`); isolate with `t.TempDir()`, `t.Setenv()`, `t.Context()`.\n- `stretchr/testify` (`assert`/`require`/`mock`/`suite`) for ergonomic assertions; golden files for complex output with a `-update` flag.\n- Fuzz untrusted parsers (`func FuzzX(f *testing.F)`); detect leaks with `goleak`; run `-race` always in CI.\n- Build the binary once in `TestMain` for integration tests; assert stdout/stderr/exit code.\n\n## Benchmarking & performance\n\n- `go test -bench . -benchmem`; use `b.Loop()` (Go 1.24+) and compare runs with `benchstat`. Never optimize without a benchmark first.\n- Profile with `pprof` (CPU/heap/block/mutex) and `go tool trace`; find the hot path before touching code.\n- Cut allocations: reuse buffers (`sync.Pool`), preallocate slices/maps, avoid interface boxing in hot loops. Tune GC (`GOGC`/`GOMEMLIMIT`) only with evidence.\n\n## Observability\n\n- Structured logging with `slog` (leveled, keyed fields — never `fmt.Println` debugging in prod).\n- Prometheus metrics (RED/USE), OpenTelemetry traces propagated via `ctx`; expose `pprof` behind an internal endpoint.\n- Alert on symptoms (latency, error rate, saturation), not causes.\n\n## Debugging\n\n- Reproduce with a failing test first. Use `delve`, the race detector, and `GODEBUG` tracing for pointed investigation rather than guesswork.\n\nFor depth see [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang) (`golang-testing`, `golang-benchmark`, `golang-performance`, `golang-observability`, `golang-troubleshooting`, `golang-stretchr-testify`).\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ],
+    "source": "https://github.com/samber/cc-skills-golang"
+  }
+}

package/registry/r/skill.go-quality.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "go-quality",
+  "type": "skill",
+  "title": "Go code quality",
+  "description": "Go code quality and defensive coding. Use when reviewing or hardening Go code, enforcing style and naming, handling errors, guarding nil/slice/map safety, or closing security holes (injection, crypto, secrets).",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-quality\nlabel: \"Go code quality\"\ndependencies: [go]\nsource: https://github.com/samber/cc-skills-golang\ndescription: >\n  Go code quality and defensive coding. Use when reviewing or hardening Go\n  code, enforcing style and naming, handling errors, guarding nil/slice/map\n  safety, or closing security holes (injection, crypto, secrets).\n---\n\nShip Go that is safe by default and reads like the standard library.\n\n## Style & naming\n\n- `gofmt`/`gofumpt` + `goimports`; `golangci-lint` in CI — formatting is non-negotiable, not a debate.\n- MixedCaps, never snake_case. No `Get` prefix on getters. Packages named for what they provide, never `utils`/`common`/`helpers`/`base`.\n- Short receiver names (1-2 letters), consistent per type. Acronyms keep case: `userID`, `HTTPServer`, not `userId`/`HttpServer`.\n- Exported identifiers get a doc comment starting with the name; document the why, not the obvious.\n\n## Errors\n\n- Wrap with context at every boundary: `fmt.Errorf(\"loading config: %w\", err)`; inspect with `errors.Is`/`errors.As`, combine with `errors.Join`.\n- Sentinel `var ErrX = errors.New(...)` only when callers branch on it; custom error types to carry structured context.\n- Error strings: lowercase, no trailing punctuation. The single rule: an error is either logged OR returned — never both.\n\n## Safety\n\n- Check nil before deref; never index a map result without the comma-ok when absence matters.\n- `append` aliases — copy before mutating a re-sliced backing array; size slices with `make([]T, 0, n)` on known capacity.\n- Maps are not concurrency-safe: guard with a mutex or use `sync.Map`/sharding. Never compare floats with `==` — use an epsilon.\n- Design zero values to be useful; guard integer conversions against overflow.\n\n## Security\n\n- Parameterize SQL; never string-concat queries. Avoid `os/exec` with a shell — pass args as a slice. Escape/contextually encode untrusted output.\n- `crypto/rand` for secrets/tokens, never `math/rand`. Use `crypto/subtle` for constant-time compares.\n- No secrets in code, logs, or errors — load from env/secret store. Validate and clean file paths (`filepath.Clean`) before use; reject traversal.\n\nFor deep dives (per-topic checklists, review modes) see [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang) (`golang-naming`, `golang-error-handling`, `golang-safety`, `golang-security`, `golang-lint`).\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ],
+    "source": "https://github.com/samber/cc-skills-golang"
+  }
+}

package/registry/r/skill.go-refactoring.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "go-refactoring",
+  "type": "skill",
+  "title": "Go refactoring",
+  "description": "Safe Go refactoring at scale. Use when restructuring existing Go code: renaming at scale, extracting functions/interfaces, moving types across packages, breaking import cycles, splitting packages, or cleaning up a code smell without changing behavior.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-refactoring\nlabel: \"Go refactoring\"\ndependencies: [go]\nsource: https://github.com/samber/cc-skills-golang\ndescription: >\n  Safe Go refactoring at scale. Use when restructuring existing Go code:\n  renaming at scale, extracting functions/interfaces, moving types across\n  packages, breaking import cycles, splitting packages, or cleaning up a code\n  smell without changing behavior.\n---\n\nChange internal structure, never observable behavior. Prove it with tools and a green test net.\n\n## Core loop\n\nUnderstand → safety net → small tool-driven step → verify → atomic commit. Repeat.\n\n- **Understand** — map blast radius with gopls (references, call hierarchy, package API) before touching anything.\n- **Safety net** — inadequate coverage over the blast radius? Add characterization tests first. Gate strategy on the blast radius's coverage, not global coverage.\n- **Small step** — prefer a mechanical transform over a hand-edit.\n- **Verify** — `go build ./... && go vet ./... && go test ./...`; add `-race` for concurrency, `benchstat`-backed `-bench` for hot paths.\n- **Commit** — purely structural OR purely behavioral, never both.\n\n## Hard rules\n\n- Never mix structural and behavioral changes in one commit/PR. A rename and a feature need different review postures.\n- Split a code move from a code optimization into two sequential PRs — different verification (gopls+build vs benchmarks), same code so they conflict in parallel. Aim 100-500 lines/PR.\n- Prefer gopls Rename/Inline over hand-edits — behavior-preserving by construction; Rename refuses on shadowing or interface breakage instead of producing a bad diff.\n- Recurring change across many sites: generate a rewrite tool, escalate `gofmt -r` → `eg` → `gopatch` → `go/analysis` fixer. Reviewable, re-runnable, testable.\n- Moving a type across packages: leave a `type A = B` alias for gradual code repair — old and new names interchangeable while callers migrate.\n- Break import cycles with a consumer-side interface first, before a package split (Go resolves interfaces implicitly).\n- Grep for struct-tag / `text/template` / `reflect` references after any rename — gopls only guards compilation breakage, not tag desync.\n- Start each step from a clean committed baseline; revert rather than debug forward when a step goes red.\n- Pause for human sign-off before: cross-package move, package split, exported-API change/deprecation, deletion, new major version, or touching untested code.\n\n## When not to refactor\n\nCode works and nothing planned will touch it; critical prod code with no tests; tight deadline; no clear purpose. Refactoring only pays off if a future change spends the investment.\n\nFor the Fowler catalog mapped to Go, the tool escalation ladder, coverage thresholds, PR ordering, and the git/worktree model, see [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang) (`golang-refactoring`, `golang-gopls`).\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ],
+    "source": "https://github.com/samber/cc-skills-golang"
+  }
+}

package/registry/r/skill.go-tooling.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "go-tooling",
+  "type": "skill",
+  "title": "Go tooling: gopls & godig",
+  "description": "Semantic Go tooling. Use when navigating or refactoring Go code with gopls (go-to-definition, find references, call/implementation hierarchy, diagnostics, safe rename, extract/inline), or when exploring the published ecosystem with godig/pkg.go.dev (package docs, symbols, versions, importers, licenses, CVEs).",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-tooling\nlabel: \"Go tooling: gopls & godig\"\ndependencies: [go]\nsource: https://github.com/samber/cc-skills-golang\ndescription: >\n  Semantic Go tooling. Use when navigating or refactoring Go code with gopls\n  (go-to-definition, find references, call/implementation hierarchy, diagnostics,\n  safe rename, extract/inline), or when exploring the published ecosystem with\n  godig/pkg.go.dev (package docs, symbols, versions, importers, licenses, CVEs).\n---\n\nTwo tools, two scopes. `gopls` reasons about your locally resolved build; `godig` queries the published ecosystem. Reach for semantic tools over grep whenever a question is about the resolved build — grep finds text, these find meaning.\n\n## gopls — your local build\n\nOfficial Go language server. Answers only about your workspace plus deps as pinned in `go.sum` (including `replace`d forks).\n\nThree ways to reach it, in preference order:\n\n- **gopls MCP server (preferred)** — agent-native: `go_*` tools take names, paths, and fuzzy queries. `claude mcp add gopls -- gopls mcp`. Headless, only sees files saved to disk.\n- **native `LSP` tool** — editor-style, keyed by `line`/`character` (useful once you have a location). Pushes compiler diagnostics into context after every edit. Needs `ENABLE_LSP_TOOL=1` + the gopls-lsp plugin.\n- **`gopls` CLI** — same engine, `gopls <cmd> <file:line:col>`. Documented as experimental/debugging-only; last-resort fallback.\n\nUse it for: navigation (definition, implementation, call graph), code discovery (`go_workspace`, `go_search`, `go_package_api`), diagnostics after edits, formatting, and safe refactors (rename blocks interface-breaking changes; extract/inline/fill/rewrite).\n\nWorkflow: `go_workspace` once at session start, then baseline `go_vulncheck`. Before modifying a definition, `go_symbol_references` to judge blast radius; after each edit, `go_diagnostics` on changed files; run `go test <changed-pkg>`, not `./...`.\n\nGotchas: `references` reflects only the queried file's build config (re-run under other `GOOS`/tags); `call_hierarchy` shows static calls only (interface/func-value calls invisible); extract/inline sometimes drop comments and skip `DO NOT EDIT` files.\n\n## godig — the published ecosystem\n\npkg.go.dev API client (CLI + MCP), read-only, no auth. Works even for packages not yet in your `go.mod`. Prefer it over Context7 for any Go package fact.\n\n```bash\ngo install github.com/samber/godig/cmd/godig@latest\nclaude mcp add pkg-go-dev -- godig mcp   # or hosted: https://godig.samber.dev/mcp\n```\n\nUse for: available versions, CVEs of a dep, package/symbol docs, who imports a package, licenses.\n\n```bash\ngodig overview github.com/samber/lo -o md        # start here — compact summary\ngodig symbol doc github.com/samber/lo Map -o md  # token-efficient vs package doc\ngodig versions <path> --filter 'deprecated==false' -o md\ngodig imported-by <path> --limit 20 -o md\ngodig vulns <path> -o md\n```\n\nAlways pass `-o md`. Prefer `overview` and per-`symbol` commands over LARGE package-wide `doc`/`examples`/`licenses`. Every command is a self-contained read-only HTTP query — parallelize independent lookups.\n\n## Which tool\n\n- Local symbols, call sites, resolved-source navigation, safe rename → gopls.\n- Published versions, licenses, ecosystem-wide importers, CVEs of a not-yet-added package → godig.\n- Whole-tree vulnerability audit (CI gate) → `govulncheck` (see go-ci). Non-Go or unindexed docs → Context7 fallback.\n\nFor every gopls tool/CLI/LSP mapping and the full godig command and filter reference, see [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang) (`golang-gopls`, `golang-pkg-go-dev`).\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ],
+    "source": "https://github.com/samber/cc-skills-golang"
+  }
+}

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

@@ -0,0 +1,20 @@
+{
+  "schemaVersion": 1,
+  "name": "go-tui",
+  "type": "skill",
+  "title": "Go TUI development",
+  "description": "Charm-stack Go interfaces: Bubble Tea event loops, Lip Gloss styling, and Bubbles controls for full-screen terminals.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-tui\nlabel: \"Go TUI development\"\ndependencies: [go]\ndescription: >\n  Charm-stack Go interfaces: Bubble Tea event loops, Lip Gloss styling, and\n  Bubbles controls for full-screen terminals.\n---\n\nBuild TUIs in Go with the Charm stack — Elm architecture, composable, testable.\n\n## Preferred libraries\n\n- `charmbracelet/bubbletea` — the runtime/event loop (`Model` with `Init/Update/View`).\n- `charmbracelet/lipgloss` — styling and layout (colors, borders, padding, joins).\n- `charmbracelet/bubbles` — ready-made components: `textinput`, `list`, `table`, `viewport`, `spinner`, `progress`, `help`, `key`.\n- `charmbracelet/log` for structured logs (to a file, never stdout while the UI runs).\n\n## Architecture\n\n- One `Model` struct holds all state; `Update(msg) (Model, Cmd)` is the only mutator — pure, no IO.\n- Side effects are `tea.Cmd` returning a `tea.Msg`; never block in `Update`. Long work runs in a `Cmd` and reports back via a message.\n- Compose sub-models: parent embeds child models and routes `Update`/`View` to them.\n- Key handling: define a `key.Binding` set + `help.Model`; match in `Update` via `key.Matches(msg, keys.X)`.\n- Use `tea.WindowSizeMsg` to size views; pass width/height down to children.\n\n## Conventions\n\n- `tea.NewProgram(m, tea.WithAltScreen())` for full-screen; add `tea.WithMouseCellMotion()` only if needed.\n- Keep `View()` a pure render of state — no side effects, fast (it runs every frame).\n- Respect `NO_COLOR`; Lip Gloss auto-detects terminal color profile.\n- Provide a non-TUI fallback path when stdin/stdout is not a TTY (`isatty`) for scripting and CI.\n\n## Testing\n\n- Drive the model directly in tests: build it, feed messages to `Update`, assert on the resulting model and emitted `Cmd`/`Msg`. No terminal needed.\n- `charmbracelet/x/exp/teatest` for golden-file end-to-end TUI tests when render output matters.\n- Keep business logic outside the model so it can be unit-tested independently.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ]
+  }
+}

package/registry/r/skill.go-types.json

@@ -0,0 +1,21 @@
+{
+  "schemaVersion": 1,
+  "name": "go-types",
+  "type": "skill",
+  "title": "Go structs & interfaces",
+  "description": "Go struct and interface design. Use when designing Go types, defining or implementing interfaces, embedding, writing type assertions or type switches, adding struct field tags, choosing pointer vs value receivers, or applying \"accept interfaces, return structs\".",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: go-types\nlabel: \"Go structs & interfaces\"\ndependencies: [go]\nsource: https://github.com/samber/cc-skills-golang\ndescription: >\n  Go struct and interface design. Use when designing Go types, defining or\n  implementing interfaces, embedding, writing type assertions or type switches,\n  adding struct field tags, choosing pointer vs value receivers, or applying\n  \"accept interfaces, return structs\".\n---\n\nFavor small, composable interfaces and concrete return types. Design for testability and clarity, not abstraction for its own sake.\n\n## Interface design\n\n- Keep interfaces small — 1-3 methods. \"The bigger the interface, the weaker the abstraction.\" Compose large contracts from small ones (`io.ReadWriteCloser`).\n- Define interfaces where they are CONSUMED, not where implemented — keeps the consumer in control, avoids importing a package just for its interface.\n- Accept interfaces, return structs. NEVER return an interface from a constructor — callers lose access to the concrete type's fields/methods.\n- Don't design with interfaces, discover them. No premature interface — wait for a 2nd implementation or a test mock. Start concrete.\n\n## Types & safety\n\n- Make the zero value useful (`var buf bytes.Buffer` just works); lazy-init nil maps in methods rather than requiring a constructor.\n- Prefer generics (`[T comparable]`) over `any`/`interface{}` — reserve `any` for true boundaries (JSON, reflection).\n- Compile-time interface check near the type: `var _ io.ReadWriter = (*MyBuffer)(nil)` — costs nothing, fails the build if satisfaction breaks.\n- Honor canonical stdlib method signatures — a `String()` method must match `fmt.Stringer`; never invent `ToString()`/`ReadData()`.\n\n## Assertions & embedding\n\n- Type assertions MUST use comma-ok: `s, ok := val.(string)`. Bare `val.(string)` panics.\n- Optional-behavior pattern: `if f, ok := w.(Flusher); ok { f.Flush() }` — checks a capability without requiring it (like `http.Flusher`).\n- Embedding is composition, not inheritance — promotes the inner type's methods; the outer type can override. Embed to expose the full inner API (\"is a\"); use a named field when the dependency is internal (\"has a\").\n\n## Receivers & tags\n\n- Pointer receiver when a method mutates, the struct is large, or it holds a `sync.Mutex`; value receiver when small/immutable/read-only. Receiver type MUST be consistent across all methods of a type.\n- Exported fields in serialized structs MUST have tags: `json:\"user_id\" db:\"user_id\"`; `json:\"-\"` excludes, `,omitempty` omits zero values.\n- Structs holding a mutex/channel/internal pointer must not be copied — embed a `noCopy` sentinel so `go vet` catches copies; always pass by pointer.\n\n## Dependency injection\n\nAccept dependencies as interfaces in constructors (`NewUserService(store UserStore) *UserService`). Tests pass a mock satisfying the interface — no real database.\n\nFor struct-tag directive tables, the stdlib interface reference, and worked embedding examples, see [samber/cc-skills-golang](https://github.com/samber/cc-skills-golang) (`golang-structs-interfaces`).\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "systemDependencies": [
+      "go"
+    ],
+    "source": "https://github.com/samber/cc-skills-golang"
+  }
+}

package/registry/r/skill.grilling.json

@@ -0,0 +1,18 @@
+{
+  "schemaVersion": 1,
+  "name": "grilling",
+  "type": "skill",
+  "title": "Grilling (plan interview)",
+  "description": "Grill the user relentlessly about a plan or design before building. Use when asked to stress-test a plan or resolve open design decisions, or on any \"grill\" trigger phrase.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: grilling\nlabel: \"Grilling (plan interview)\"\nsource: https://github.com/mattpocock/skills\ndescription: >\n  Grill the user relentlessly about a plan or design before building. Use when\n  asked to stress-test a plan or resolve open design decisions, or on any\n  \"grill\" trigger phrase.\n---\n\n<!-- Adapted from mattpocock/skills (MIT, (c) 2026 Matt Pocock) -->\n\nInterview me relentlessly about every aspect of this plan, design, decision, or idea until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.\n\nAsk the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.\n\nIf a *fact* can be looked up — in the codebase or via any available tool or environment (docs, web, filesystem, running the thing) — look it up rather than asking me. The *decisions*, though, are mine — put each one to me and wait for my answer.\n\nDo not enact the plan until I confirm we have reached a shared understanding.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "source": "https://github.com/mattpocock/skills"
+  }
+}

package/registry/r/skill.improve-architecture.json

@@ -0,0 +1,18 @@
+{
+  "schemaVersion": 1,
+  "name": "improve-architecture",
+  "type": "skill",
+  "title": "Improve architecture (deepening scan)",
+  "description": "Scan a codebase for deepening opportunities — refactors that turn shallow modules into deep ones — present them as candidates, then grill through the one you pick. Use when hunting architectural friction to improve testability and navigability.",
+  "files": [
+    {
+      "path": "SKILL.md",
+      "content": "---\nname: improve-architecture\nlabel: \"Improve architecture (deepening scan)\"\nsource: https://github.com/mattpocock/skills\ndescription: >\n  Scan a codebase for deepening opportunities — refactors that turn shallow\n  modules into deep ones — present them as candidates, then grill through the\n  one you pick. Use when hunting architectural friction to improve testability\n  and navigability.\n---\n\n<!-- Adapted from mattpocock/skills (MIT, (c) 2026 Matt Pocock) -->\n\n# Improve Architecture\n\nSurface architectural friction and propose **deepening opportunities** —\nrefactors that turn shallow modules into deep ones. Aim: testability and\nnavigability.\n\nBuilt on shared design vocabulary — run the `software-design` skill for the\nterms (**module**, **interface**, **depth**, **seam**, **adapter**,\n**leverage**, **locality**, the **deletion test**) and use them exactly; don't\ndrift into \"component\", \"service\", or \"boundary\". The domain glossary names\ngood seams; recorded decisions (ADRs) mark what not to re-litigate.\n\n## Process\n\n### 1. Explore\n\n**Scope before you scan — YAGNI.** Deepening pays off on code that keeps\nchanging, so weight recent hot spots. If the user named a direction, take it.\nOtherwise walk back the commit history (`git log --oneline`) to find the files\nthat keep coming up; scattered with no hot spot → widen the net.\n\nRead the domain glossary and any decisions in the area first. Then explore\norganically (an `explore` subagent helps) and note friction:\n\n- Understanding one concept means bouncing between many small modules.\n- **Shallow** modules — interface nearly as complex as the implementation.\n- Pure functions extracted only for testability, while the real bugs hide in\n  how they are called (no **locality**).\n- Tightly-coupled modules leaking across their seams.\n- Parts untested or hard to test through the current interface.\n\nApply the **deletion test** to anything you suspect is shallow: would deleting\nit *concentrate* complexity or just move it? \"Concentrates\" is the signal.\n\n### 2. Present candidates\n\nFor each candidate: the **files** involved, the **problem** (why the current\nshape causes friction), the **solution** in plain English, the **benefits** in\nterms of locality/leverage and improved tests, a before/after sketch of the\nshallowness and the deepening, and a **recommendation strength** (`Strong`,\n`Worth exploring`, `Speculative`). End with a top recommendation.\n\nUse the domain vocabulary for concepts and the `software-design` vocabulary for\narchitecture. If a candidate contradicts a recorded decision, surface it only\nwhen the friction is real enough to warrant reopening that decision. Do **not**\npropose interfaces yet — ask the user which candidate to explore.\n\n### 3. Grill the pick\n\nOnce the user picks one, run the `grilling` skill to walk the decision tree —\nconstraints, dependencies, the shape of the deepened module, what sits behind\nthe seam, which tests survive. Keep the domain model current inline (run\n`domain-modeling`): add new concept names to the glossary, sharpen fuzzy terms,\nand if the user rejects a candidate for a load-bearing reason, offer to record\nit so future scans don't re-suggest it. For alternative interfaces, use\n`software-design`'s design-it-twice pattern.\n",
+      "kind": "skill-md"
+    }
+  ],
+  "standalone": false,
+  "meta": {
+    "source": "https://github.com/mattpocock/skills"
+  }
+}