From 9abaa5486d3a275ffdddbfcb6420c34abdeb801a Mon Sep 17 00:00:00 2001
From: seba3567 <sebastian26481@gmail.com>
Date: Mon, 15 Jun 2026 17:02:53 -0400
Subject: [PATCH 1/7] feat(autoskills): support shadcn-svelte and discriminate
 React shadcn

---
 packages/autoskills/lib.ts                    |   5 +
 packages/autoskills/scripts/sync-skills.mjs   |   4 +-
 packages/autoskills/skills-map.ts             |   6 +
 .../autoskills/skills-registry/index.json     |  48 +++-
 .../skills-registry/shadcn-svelte/SKILL.md    | 227 ++++++++++++++++
 .../shadcn-svelte/agents/openai.yml           |   5 +
 .../assets/shadcn-svelte-small.png            | Bin 0 -> 2672 bytes
 .../shadcn-svelte/assets/shadcn-svelte.png    | Bin 0 -> 9410 bytes
 .../skills-registry/shadcn-svelte/cli.md      | 138 ++++++++++
 .../shadcn-svelte/customization.md            | 213 +++++++++++++++
 .../shadcn-svelte/evals/evals.json            |  47 ++++
 .../shadcn-svelte/rules/composition.md        | 244 ++++++++++++++++++
 .../shadcn-svelte/rules/forms.md              | 234 +++++++++++++++++
 .../shadcn-svelte/rules/icons.md              | 107 ++++++++
 .../shadcn-svelte/rules/styling.md            | 195 ++++++++++++++
 packages/autoskills/tests/collect.test.ts     |  20 ++
 16 files changed, 1491 insertions(+), 2 deletions(-)
 create mode 100644 packages/autoskills/skills-registry/shadcn-svelte/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/shadcn-svelte/agents/openai.yml
 create mode 100644 packages/autoskills/skills-registry/shadcn-svelte/assets/shadcn-svelte-small.png
 create mode 100644 packages/autoskills/skills-registry/shadcn-svelte/assets/shadcn-svelte.png
 create mode 100644 packages/autoskills/skills-registry/shadcn-svelte/cli.md
 create mode 100644 packages/autoskills/skills-registry/shadcn-svelte/customization.md
 create mode 100644 packages/autoskills/skills-registry/shadcn-svelte/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/shadcn-svelte/rules/composition.md
 create mode 100644 packages/autoskills/skills-registry/shadcn-svelte/rules/forms.md
 create mode 100644 packages/autoskills/skills-registry/shadcn-svelte/rules/icons.md
 create mode 100644 packages/autoskills/skills-registry/shadcn-svelte/rules/styling.md

diff --git a/packages/autoskills/lib.ts b/packages/autoskills/lib.ts
index beda7067..8d3f642f 100644
--- a/packages/autoskills/lib.ts
+++ b/packages/autoskills/lib.ts
@@ -682,8 +682,13 @@ export function collectSkills({
     }
   }
 
+  const hasSvelteShadcn = combos.some((c) => c.id === "svelte-shadcn");
+
   for (const tech of detected) {
     for (const skill of tech.skills) {
+      if (hasSvelteShadcn && skill === "shadcn/ui/shadcn") {
+        continue;
+      }
       addSkill(skill, tech.name);
     }
   }
diff --git a/packages/autoskills/scripts/sync-skills.mjs b/packages/autoskills/scripts/sync-skills.mjs
index bb255e76..70bdc3be 100644
--- a/packages/autoskills/scripts/sync-skills.mjs
+++ b/packages/autoskills/scripts/sync-skills.mjs
@@ -29,7 +29,9 @@ import { SKILLS_MAP, COMBO_SKILLS_MAP, FRONTEND_BONUS_SKILLS } from "../skills-m
 import { parseSkillPath } from "../lib.ts";
 import { bold, cyan, dim, green, log, red, yellow } from "../colors.ts";
 
-process.loadEnvFile();
+if (typeof process.loadEnvFile === "function") {
+  process.loadEnvFile();
+}
 
 // ── Config ───────────────────────────────────────────────────
 
diff --git a/packages/autoskills/skills-map.ts b/packages/autoskills/skills-map.ts
index 783af900..79b6b875 100644
--- a/packages/autoskills/skills-map.ts
+++ b/packages/autoskills/skills-map.ts
@@ -1238,6 +1238,12 @@ export const COMBO_SKILLS_MAP: ComboSkill[] = [
     requires: ["react", "shadcn"],
     skills: ["shadcn/ui/shadcn", "vercel-labs/agent-skills/react-best-practices"],
   },
+  {
+    id: "svelte-shadcn",
+    name: "Svelte + shadcn-svelte",
+    requires: ["svelte", "shadcn"],
+    skills: ["huntabyte/shadcn-svelte/shadcn-svelte"],
+  },
   {
     id: "tailwind-shadcn",
     name: "Tailwind CSS + shadcn/ui",
diff --git a/packages/autoskills/skills-registry/index.json b/packages/autoskills/skills-registry/index.json
index 2dda2c8f..a63f3ce7 100644
--- a/packages/autoskills/skills-registry/index.json
+++ b/packages/autoskills/skills-registry/index.json
@@ -1,6 +1,6 @@
 {
   "version": 1,
-  "generatedAt": "2026-05-03T15:50:34.696Z",
+  "generatedAt": "2026-06-15T20:58:27.158Z",
   "reviewer": {
     "model": "gpt-5.4",
     "promptVersion": "1.0.0"
@@ -13018,6 +13018,52 @@
         "summary": "Official ElysiaJS skill with standard documentation",
         "checkedAt": "2026-05-13T21:40:00.000Z"
       }
+    },
+    "shadcn-svelte": {
+      "source": "huntabyte/shadcn-svelte",
+      "skillPath": "huntabyte/shadcn-svelte/shadcn-svelte",
+      "commitSha": "57acd8baa862f3fa13cb7b7912fdd802f6366ab8",
+      "files": [
+        "SKILL.md",
+        "agents/openai.yml",
+        "assets/shadcn-svelte-small.png",
+        "assets/shadcn-svelte.png",
+        "cli.md",
+        "customization.md",
+        "evals/evals.json",
+        "rules/composition.md",
+        "rules/forms.md",
+        "rules/icons.md",
+        "rules/styling.md"
+      ],
+      "sha256": {
+        "SKILL.md": "0d4b071c02c895d53fd45e24e1bcb5e74bc70888a720b1465bafbc37799a7c76",
+        "agents/openai.yml": "8a19c76244f9f8171058dbe03d80b7a375b03021aabe98fbdfa9f6d1ad140c51",
+        "assets/shadcn-svelte-small.png": "ab571a7acd192a769531b5ea5e2105f40128b52e90fbdeb31e712d5fd18f6350",
+        "assets/shadcn-svelte.png": "256a06954d29e566b01695f0fa3574c0a6d69991098e756d8cc0704ee376ce3f",
+        "cli.md": "59563b6d10901607a5c5b702f9a470b2acb4d1c6be945e32da998a93d7ae3b65",
+        "customization.md": "6f3e3ddaacb28fd6a84ed643d721e1c712495aabdf6d67ada564a2a6b7a52fcd",
+        "evals/evals.json": "e656977db8221f55d10b46297a85aaf363b9911d7a0a70ab7408d84e1ddef02b",
+        "rules/composition.md": "73fde3d9ce43b5e62152cdc0a0719ef735889855f5cf7a39019bb603223a76b2",
+        "rules/forms.md": "68222eeb9a9671ef0e3261e48c78211c524da2d7adac3fe18362a725aa6013e0",
+        "rules/icons.md": "264f1316cafaeedf91cf830502381323db9310c23e8dc4e10faaf1b687bda20b",
+        "rules/styling.md": "35d9c99aa5fd3053d3846c9706151cb0b05915a659d03c0ceafc61c631772f0a"
+      },
+      "bundleHash": "6249e41a2601b9523614f4bf653fcc34f5f8a848cc960cf54d9c4ddc949332f2",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T20:58:27.147Z"
+      },
+      "securityCheck": {
+        "status": "ok",
+        "findings": [],
+        "summary": "review skipped (--no-review)",
+        "checkedAt": "2026-06-15T20:58:27.147Z"
+      }
     }
   }
 }
diff --git a/packages/autoskills/skills-registry/shadcn-svelte/SKILL.md b/packages/autoskills/skills-registry/shadcn-svelte/SKILL.md
new file mode 100644
index 00000000..6bbc4251
--- /dev/null
+++ b/packages/autoskills/skills-registry/shadcn-svelte/SKILL.md
@@ -0,0 +1,227 @@
+---
+name: shadcn-svelte
+description: Manages shadcn-svelte components and projects — adding, updating, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn-svelte, the CLI, design-system presets, or any project with a components.json file. Also triggers for "shadcn-svelte init", "add component", or registry URLs.
+user-invocable: false
+allowed-tools: Bash(npx shadcn-svelte@latest *), Bash(pnpm dlx shadcn-svelte@latest *), Bash(bunx --bun shadcn-svelte@latest *)
+---
+
+# shadcn-svelte
+
+A framework for building UI, components, and design systems for Svelte. Components are added as source to the user's project via the CLI.
+
+> **IMPORTANT:** Run all CLI commands using the project's package runner: `npx shadcn-svelte@latest`, `pnpm dlx shadcn-svelte@latest`, or `bunx --bun shadcn-svelte@latest` — based on the project's package manager. Examples below use `npx shadcn-svelte@latest` but substitute the correct runner for the project.
+
+## Current Project Context
+
+Read `components.json` at the project root and, when you need the live file layout, list the directory given by the `aliases.ui` path (resolved with the same rules as the CLI).
+
+## Imports (Svelte)
+
+Each component lives in its own folder with an `index.ts` barrel. Match the [installation docs](https://shadcn-svelte.com/docs/installation):
+
+- **Multi-part components** (dialog, select, card, field, tabs, …): `import * as Dialog from "$lib/components/ui/dialog"` then `Dialog.Content`, `Dialog.Title`, `Card.Root`, `Card.Header`, etc. — whatever the barrel exports (short names and/or `Root as …` aliases).
+- **Single-component barrels** (only one meaningful component in the folder): **named imports** — `import { Button } from "$lib/components/ui/button"` and `<Button>`, not `import * as Button` + `Button.Root`. Same pattern for `{ Input }`, `{ Badge }`, `{ Spinner }`, `{ Checkbox }`, `{ Separator }`, `{ Skeleton }`, etc.
+
+```ts
+import * as Dialog from "$lib/components/ui/dialog";
+import { Button } from "$lib/components/ui/button";
+import { Separator } from "$lib/components/ui/separator";
+```
+
+Use the real aliases from `components.json` (often `$lib/components/ui/...`), not hardcoded paths.
+
+## Principles
+
+1. **Use existing components first.** Run `npx shadcn-svelte@latest add` with no arguments to browse available components, or check [Components](https://shadcn-svelte.com/docs/components) before writing custom UI.
+2. **Compose, don't reinvent.** Settings page = Tabs + Card + form controls. Dashboard = Sidebar + Card + Chart + Table.
+3. **Use built-in variants before custom styles.** `variant="outline"`, `size="sm"`, etc.
+4. **Use semantic colors.** `bg-primary`, `text-muted-foreground` — never raw values like `bg-blue-500`.
+
+## Critical Rules
+
+These rules are **always enforced**. Each links to a file with Incorrect/Correct code pairs.
+
+### Styling & Tailwind → [styling.md](./rules/styling.md)
+
+- **`class` for layout, not styling.** Never override component colors or typography.
+- **No `space-x-*` or `space-y-*`.** Use `flex` with `gap-*`. For vertical stacks, `flex flex-col gap-*`.
+- **Use `size-*` when width and height are equal.** `size-10` not `w-10 h-10`.
+- **Use `truncate` shorthand.** Not `overflow-hidden text-ellipsis whitespace-nowrap`.
+- **No manual `dark:` color overrides.** Use semantic tokens (`bg-background`, `text-muted-foreground`).
+- **Use `cn()` for conditional classes.** Don't write manual template literal ternaries.
+- **No manual `z-index` on overlay components.** Dialog, Sheet, Popover, etc. handle their own stacking.
+
+### Forms & Inputs → [forms.md](./rules/forms.md)
+
+- **Forms use `Field.FieldGroup` + `Field.Field`.** Never use raw `div` with `space-y-*` or `grid gap-*` for form layout.
+- **`InputGroup` uses `InputGroup.Input`/`InputGroup.Textarea`.** Never raw `Input`/`Textarea` inside `InputGroup.Root`.
+- **Buttons inside inputs use `InputGroup.Root` + `InputGroup.Addon`.**
+- **Option sets (2–7 choices) use `ToggleGroup`.** Don't loop `Button` with manual active state.
+- **`Field.FieldSet` + `Field.FieldLegend` for grouping related checkboxes/radios.** Don't use a `div` with a heading.
+- **Field validation uses `data-invalid` + `aria-invalid`.** `data-invalid` on `Field`, `aria-invalid` on the control. For disabled: `data-disabled` on `Field`, `disabled` on the control.
+
+### Component Structure → [composition.md](./rules/composition.md)
+
+- **Items always inside their Group.** `Select.Item` → `Select.Group`. `DropdownMenu.Item` → `DropdownMenu.Group`. `Command.Item` → `Command.Group`.
+- **Custom triggers.** Wrap controls in `Dialog.Trigger` / `AlertDialog.Trigger`, or control open state with `bind:open` on the root — see component docs.
+- **Dialog, Sheet, and Drawer always need a Title.** `Dialog.Title`, `Sheet.Title`, `Drawer.Title` required for accessibility. Use `class="sr-only"` if visually hidden.
+- **Use full Card composition.** `Card.Header`/`Card.Title`/`Card.Description`/`Card.Content`/`Card.Footer`. Don't dump everything in `Card.Content`.
+- **Button has no `isPending`/`isLoading`.** Compose with `Spinner` inside `Button` + `disabled`; use `data-icon="inline-start"` / `inline-end` on `Spinner` for correct spacing (`import { Button }`, `import { Spinner }`).
+- **`Tabs.Trigger` must be inside `Tabs.List`.** Never render triggers directly in `Tabs`.
+- **`Avatar` always needs `Avatar.Fallback`.** For when the image fails to load.
+
+### Use Components, Not Custom Markup → [composition.md](./rules/composition.md)
+
+- **Use existing components before custom markup.** Check if a component exists before writing a styled `div`.
+- **Callouts use `Alert`.** Don't build custom styled divs.
+- **Empty states use `Empty`.** Don't build custom empty state markup.
+- **Toast via `svelte-sonner`.** Use `toast()` from `svelte-sonner` with the Sonner component from your UI folder.
+- **Use `Separator`** instead of `<hr>` or a `div` with border-only classes.
+- **Use `Skeleton`** for loading placeholders. No custom `animate-pulse` divs.
+- **Use `Badge`** instead of custom styled spans.
+
+### Icons → [icons.md](./rules/icons.md)
+
+- **Icons in `<Button>` use `data-icon`.** `data-icon="inline-start"` or `data-icon="inline-end"` on the icon.
+- **No sizing classes on icons inside components.** Components handle icon sizing via CSS. No `size-4` or `w-4 h-4`.
+- **Pass icons as components.** Import from the configured `iconLibrary` (e.g. `@lucide/svelte`), not string keys.
+
+### CLI
+
+- **Presets** — copy the encoded string from the design-system builder on [shadcn-svelte.com](https://shadcn-svelte.com) and pass it to `npx shadcn-svelte@latest init --preset <code>`.
+
+## Key Patterns
+
+These are the most common patterns that differentiate correct shadcn-svelte code. For edge cases, see the linked rule files above.
+
+```svelte
+<script lang="ts">
+  import * as Field from "$lib/components/ui/field";
+  import { Input } from "$lib/components/ui/input";
+  import { Button } from "$lib/components/ui/button";
+  import SearchIcon from "@lucide/svelte/icons/search";
+  import { Badge } from "$lib/components/ui/badge";
+  import * as Avatar from "$lib/components/ui/avatar";
+</script>
+
+<!-- Form layout: Field.FieldGroup + Field.Field, not div + Label. -->
+<Field.FieldGroup>
+  <Field.Field>
+    <Field.FieldLabel for="email">Email</Field.FieldLabel>
+    <Input id="email" />
+  </Field.Field>
+</Field.FieldGroup>
+
+<!-- Validation: data-invalid on Field, aria-invalid on the control. -->
+<Field.Field data-invalid>
+  <Field.FieldLabel for="email">Email</Field.FieldLabel>
+  <Input id="email" aria-invalid />
+  <Field.FieldDescription>Invalid email.</Field.FieldDescription>
+</Field.Field>
+
+<!-- Icons in buttons: data-icon, no sizing classes. -->
+<Button>
+  <SearchIcon data-icon="inline-start" />
+  Search
+</Button>
+
+<!-- Spacing: gap-*, not space-y-*. -->
+<div class="flex flex-col gap-4"></div>
+
+<!-- Equal dimensions: size-*, not w-* h-*. -->
+<Avatar.Root class="size-10">
+  <Avatar.Image src="/u.png" alt="User" />
+  <Avatar.Fallback>U</Avatar.Fallback>
+</Avatar.Root>
+
+<!-- Status colors: Badge variants or semantic tokens, not raw colors. -->
+<Badge variant="secondary">+20.1%</Badge>
+```
+
+## Component Selection
+
+| Need                       | Use                                                                                                 |
+| -------------------------- | --------------------------------------------------------------------------------------------------- |
+| Button/action              | `Button` with appropriate variant (`import { Button }`)                                             |
+| Form inputs                | `Input`, `Select`, `Combobox`, `Switch`, `Checkbox`, `RadioGroup`, `Textarea`, `InputOTP`, `Slider` |
+| Toggle between 2–5 options | `ToggleGroup.Root` + `ToggleGroup.Item`                                                             |
+| Data display               | `Table`, `Card`, `Badge`, `Avatar`                                                                  |
+| Navigation                 | `Sidebar`, `NavigationMenu`, `Breadcrumb`, `Tabs`, `Pagination`                                     |
+| Overlays                   | `Dialog` (modal), `Sheet` (side panel), `Drawer` (bottom sheet), `AlertDialog` (confirmation)       |
+| Feedback                   | `svelte-sonner` (toast), `Alert`, `Progress`, `Skeleton`, `Spinner`                                 |
+| Command palette            | `Command` inside `Dialog`                                                                           |
+| Charts                     | `Chart` (LayerChart)                                                                                |
+| Layout                     | `Card`, `Separator`, `Resizable`, `ScrollArea`, `Accordion`, `Collapsible`                          |
+| Empty states               | `Empty`                                                                                             |
+| Menus                      | `DropdownMenu`, `ContextMenu`, `Menubar`                                                            |
+| Tooltips/info              | `Tooltip`, `HoverCard`, `Popover`                                                                   |
+
+## Key Fields
+
+Use `components.json` and the filesystem — not a separate `info` command:
+
+- **`aliases`** → use the actual alias prefix from config (e.g. `$lib/`), never hardcode unrelated projects.
+- **`tailwind.css`** → the global CSS file where theme variables live. Edit this file for theme tweaks; don't add a second globals file unless the user already uses one.
+- **`style`** → visual treatment (e.g. `nova`, `vega`, …) and registry style path.
+- **`iconLibrary`** → determines icon packages (`@lucide/svelte`, `@tabler/icons-svelte`, etc.). Never assume `@lucide/svelte`.
+- **`registry`** → where the CLI fetches components; default official registry at `shadcn-svelte.com`.
+- **`resolvedPaths`** (conceptual) → the CLI resolves `aliases` to absolute paths; list `aliases.ui` on disk to see installed components.
+
+See [cli.md](./cli.md) for commands and flags.
+
+## Component Docs, Examples, and Usage
+
+Open `https://shadcn-svelte.com/docs/components/<name>.md` for docs and examples. **When creating, fixing, debugging, or using a component, read the official page first** so you follow the documented APIs.
+
+## Workflow
+
+1. **Get project context** — read `components.json` and list the UI components directory when needed.
+2. **Check installed components first** — before running `add`, list files under the resolved `ui` path. Don't import components that haven't been added, and don't re-add ones already present unless updating.
+3. **Discover components** — `npx shadcn-svelte@latest add` with no arguments (interactive list), or the docs site.
+4. **Install or update** — `npx shadcn-svelte@latest add <name>` or a registry **URL**. To refresh existing files from the registry, use `npx shadcn-svelte@latest update` (see [cli.md](./cli.md)).
+5. **Fix imports in third-party / URL-added items** — After adding from a custom registry URL, check for hardcoded paths that don't match the project's `aliases`. Rewrite imports to use the project's `ui` / `lib` aliases from `components.json`.
+6. **Review added components** — After adding, **read the added files** and verify composition (groups, titles, validation attrs). Align icon imports with `iconLibrary`.
+7. **Remote registry items** — Adding by URL is explicit; if the user wants a component from an unknown source, confirm the registry URL or item before running `add`.
+
+## Updating Components
+
+Use the **`update`** command to pull the latest registry versions of components already in the project. Review changes with `git diff` after `update`.
+
+1. Commit or stash local work.
+2. Run `npx shadcn-svelte@latest update [component]` or `--all`.
+3. Resolve merge conflicts if you had customized files.
+4. **Never use `--overwrite` on `add` without the user's explicit approval** when it would destroy intentional edits.
+
+## Quick Reference
+
+```bash
+# Initialize shadcn-svelte in your project.
+npx shadcn-svelte@latest init
+
+# Initialize with a preset string from the docs site builder.
+npx shadcn-svelte@latest init --preset <code>
+
+# Add components (interactive when run with no names).
+npx shadcn-svelte@latest add
+npx shadcn-svelte@latest add button card dialog
+npx shadcn-svelte@latest add --all
+
+# Update components already installed.
+npx shadcn-svelte@latest update button
+npx shadcn-svelte@latest update --all --yes
+
+# Build a custom registry (registry authors).
+npx shadcn-svelte@latest registry build
+```
+
+**Registry:** default `https://shadcn-svelte.com/registry` — override in `components.json` if needed.  
+**Docs:** [shadcn-svelte.com](https://shadcn-svelte.com)
+
+## Detailed References
+
+- [rules/forms.md](./rules/forms.md) — Field.FieldGroup, Field.Field, InputGroup, ToggleGroup, Field.FieldSet, validation states
+- [rules/composition.md](./rules/composition.md) — Groups, overlays, Card, Tabs, Avatar, Alert, Empty, Toast, Separator, Skeleton, Badge, Button loading
+- [rules/icons.md](./rules/icons.md) — data-icon, icon sizing, passing icon components
+- [rules/styling.md](./rules/styling.md) — Semantic colors, variants, class, spacing, size, truncate, dark mode, cn(), z-index
+- [cli.md](./cli.md) — Commands, flags, registry
+- [customization.md](./customization.md) — Theming, CSS variables, extending components
diff --git a/packages/autoskills/skills-registry/shadcn-svelte/agents/openai.yml b/packages/autoskills/skills-registry/shadcn-svelte/agents/openai.yml
new file mode 100644
index 00000000..612a07b9
--- /dev/null
+++ b/packages/autoskills/skills-registry/shadcn-svelte/agents/openai.yml
@@ -0,0 +1,5 @@
+interface:
+    display_name: "shadcn-svelte"
+    short_description: "Manages shadcn-svelte components — adding, updating, fixing, debugging, styling, and composing UI."
+    icon_small: "./assets/shadcn-svelte-small.png"
+    icon_large: "./assets/shadcn-svelte.png"
diff --git a/packages/autoskills/skills-registry/shadcn-svelte/assets/shadcn-svelte-small.png b/packages/autoskills/skills-registry/shadcn-svelte/assets/shadcn-svelte-small.png
new file mode 100644
index 0000000000000000000000000000000000000000..17a8bf5c9ba3e1e14355d7b3c0aef89cf4ce3c5f
GIT binary patch
literal 2672
zcmdUx`#;oa8^^D4$SFHYEXkP4mRMPbr7)RFR9b_nbTr!3Fli(ud^IzqgCv&lN^8=C
zkQ_2Ih@_-N%7_uZ7^GM+4#_um7&|@tJb%OUdVaX?>wVv^&*!>+x<9Ww*2CRZQ+=g6
z0BG*o>Fg!1&%Q0yCGy>?Cs0LRa3Nl<+n}g<)d+yP=`QE3d&7Jr8NUP`q3d6!3Bv;G
z9~smS+FQo2>3QX{EL%NKb<Lqz!)qrltWeA0KX~AkvUf+JR>6|Dtvk%f+kW(o^NosG
zshgs;JdW9#bjwyNUDtEpYOJnvmv;A*u#>yBBlbnz?YlukvN_i9?R^D3(%x|4W?_%@
z*PHap*AE$v9^}1I8$s(l_mQ0rKs2!sU}v{*639!k<>vsYJ^>myd<7t$c6y-*`ic7i
zvL*B|AS$-11Bbt`6c2vnLpVq*yE}m6EZu1a(27|*LLx3e8OSK>iV9f$Z<}ff$*Vg~
z3|47i{SC}JdSj0sx1UEsLK|hlr`uC)O~nO@AU@m^_N<x|E^VGoG?acxluV316%5oy
zymWUr?=%}8e#kE!7i@!mL3RAq?i68{##NWGsj1bYZ<H-77CiIQGk*6enRrSqJv-^d
z-2%_3$M3}J#4L`)9z&R={&NmI_NflDkDAEmJ&m%@eWT(BN+3RTm|c>IMFy4nQ^Zx}
z0kfB?I|}wW1T&jia}#F&D3D>_LWU3{MZed6f)AUy)byWgsc(@WH?;U;{DX!5u^S6R
zwLb^#Q-Gktg+*V9h<j-BmIEf;<$c`J1l|8Sj+ca<5~i;D$Y>{AL{OO{&!0e3vVuuH
zjyr=wbUiaOJjb)f{t`vkf9lcG1V=$d8>$_%_%eitN#mw{Xp4QNhTy0~+#?D9w5L&Q
zV!k`(t~Doj;KJiZ!NqeqDAmD%4hh6ej32ZP_{Ci}doH1Ex6PsDHq(J&QG}gis=&FT
z-kY7tsCM%bP|c-1K&VJ<6CMVB-g82kL9r=SB-_}pt5g@Pw||Ty+M8=1j77BzUxQX5
z_fe6HB-Y0VuKBbb*q@EntuZsY66gBP-#Z6$E}%;ozvJGw*(RmrlYVRHJhKe0dG~n~
zP?2qo!+dMl)Oc&&Ma1>9QQ`QVV~(1LxMd&I1(pz#Wbs!<KI!c#G;jy(+&^*OH48Hi
zS^~z!;k|3UkXB0tXnng-mL*4P9JIEvrW-`ubDF?eF_VjBo5<d5S0wKycpzTOS>4BQ
zL}jBq(uQl|{zOPD`Ci10Q4R{;1Up;s3`+E`4g_^rby>YiU$FjR^wbz0rv8lRejws1
zIgd|jLCd`}MOB{2k(AwZ2e{^WfkC<P-i2=i&c+|G6L};{HG`>A(0Y{l{H%zp=Nuof
z3$7hFz@XGc|M6rMIGg+=Sij9u`;a=US)Pt+|CXp`p$N-V-6gT)x?8EhNvtgpafv2X
zRUz;0Oq9-C@0yvpUg%x0y4{U^0aOQ~c1yab4c#xkE=AL>R|V2&<>n8)$9gIIZP~kL
zYFiJfD!29Nfc+P84z{XuUrEQ!F<#b7)@YMT@Z+fi1$!lfqo=UWkpP6v5^UFL>(d1L
zNxAgK%=vD!uM@oD1kFHJY+!Z$h?yDohWfqa6Y8R}`+kiE@JHm6)qLh?_KpmifkDX;
z?f9V%)6n@|H>`f-vTaI_{vAcK!4{KtE-ms{jiKR4(Cn+49}ed*uvTdZ#$z94Zg0%s
zZGcS?TP67xd*NBr@bFl!kpk!Vt<rLRLGB~^bDevG>?*(Y`Q$E*vL@^Mn2q;_Fzxxm
z@{MSURZ#TN&$seV=aJ$i>ddI4M|^m$?!R<}Z@hHUw8Nc}inck<vuny27EkPs=Q<q>
zZ4Jp~*4^p1Z}vda>t~#rPGNO4H>|n+goap&K8J(uo-B-CM5-63m+?CGm;Nq2EHng0
zU^eD2;-VXH{r6Xj2pOm%h`6a2!pe=&N_3Da!2u(I%Es4DG_`YG6y3aujD(Ytfu(1r
z(++aEdS%1w;`UEleoZaD@!U{2ENt!^rFPAJ$!c;<FULy|$!{v00#bxGl1Dxw2?!6>
zu$>%Pm)7*mYXVo%m~%c^11iwLBpkH@U3)aD0)5d=I0$(p5%=UQvOthK<)(IAwK50Y
zE(y?)_4idPeZye2nl$i0@<>GkU%vweUXYtHi712MD%!@Jt;T(mj2O@R09kSmJGWBy
zTJamisIl+kGBFRN_KFkl-)_$sr{sU&vQx-EaK(uVE6yIpUe}e791iluN3x8@9#gqz
z1q@2YhAxAg9cJ`?WImd9GI$~QIvUU}OENRnvYI}aDO`$m8a+MRGCuysLD+0m;^6i}
z)v=QhHYTpdl3!#syC@H^r+UVQDB&kRru2QZd(2SwkhyIfCh|LfvW6#-i(8P$$c6wW
zBO!TD;H{j5?M8QhMDh4|zD+#Z=C#H)&y#3P=U99<QQF6v<488x$lkg$@Lf#rsMpZa
zm%%e)Gev~W74@HvD*X%NpCWbBKUw)t`duoXlfE7BMEtY+#!Wxi)wG^Dk;V8v_1##V
z6J0_{)3qKjrFmC`1ipH$@9S3jG&0T59P7SU6=6O*(fYYEqw-0h5zQiqRrAK3T_IC&
z@J5n?twO+ft(&9kxA#~~(Bl=~91oSTWc|0#B%2YOth}S%C$E;JT=GsoKDa&fJumAH
zePi0y)^eMwKbO_p$`jB-(44N=yBV2jU?H>It+{K@CO7T6-(r9x`>XZpnqWhc4t(S*
z!m5!AXcRhVO#L$+i2N9)hSFCHmTb;a`bQ_Z%`lI|jBpX?fOC#t-1*9?%CXyx$D}g9
zx6zcccZdhF+$wA6CrHd3Qjuz4Raq*5zh>r+d*+kW(u1cx<jFVmd?8Mr5#^1~2^wNO
z6*~)EJ5y{RvWt6hA}Ql8?Uz~o0Hg1~Ym%LpSblYUyj;2@!Zt{Jk$<4fj-ECqPX~3O
zi!>23B{lP3fM|p}jRSHwdu{|r-lBji0H<v6bDJV3Qi-n&aC-4$t_sYl`fC87vL*^1
zJ}+z01>i5F-6g<>wVCDs{!$Ak5;VAy4+FGdG*$#8CUDB&|8f9l5jUNw!q{Y)CY667
OVb>0K=b~-C(SHM+r2$a@

literal 0
HcmV?d00001

diff --git a/packages/autoskills/skills-registry/shadcn-svelte/assets/shadcn-svelte.png b/packages/autoskills/skills-registry/shadcn-svelte/assets/shadcn-svelte.png
new file mode 100644
index 0000000000000000000000000000000000000000..a35eb16e517ab064a89715a985619789e4f41d1a
GIT binary patch
literal 9410
zcmeHN`#;oc*Z$5l7!*UHgP20dd6y&&U!inh<Qy^6VW+U8<Sa9jN~PHCYMjFC+BuYC
za!4^#Dn+4<sEE?!5MdmLY35y|=Y9Tx_lNiMsb8kdeXo1n*SglV*1C1x!G7B!spV1#
zf-Kr@Ywd_2SokXz!HdJkSXlEkd|-kcw{1c4>y`Tugotdnwsa2j9_%0&c)JBlbXjrK
zi*A%(UZh|xL)-F|Rk2t+=fX}K@s&$*R$CoPzD%a7tDimbSJbJ6mMaYxI@g}YBqv#l
zUwaouh&y{q?-b5nZN-VfUPq_2oyxX_-IJu5fs+&OzTUsGFl^G)kK`9O{$O&=L~Q1f
z>F=N85DXTFC)jEXufh;p9vbhY&;B4DheMPYb6=@1At3THUUjgDh@wcK#Ox;>-Gado
zKQ@-^np=)TLgzm5zZL^{ztH%_jbEAa|3nH<PexEyJejhY-?d&ex=z+&<4NAlQPH@4
zQ-E-2vWZq1e4rw1aIi1ZEuXAZ(BbcyRCY^|fH)>lMsfJ&B}qy`6VVrgEcQ%X!nd&$
zQ)Dx(kCv4f%}-4;AF{&jz~SifBp*ovF;IfBxaM1GeTJzqX=X|-F3LOXdtM)Zr(2d^
zY?)$O=sAu)7R%A!VQxi77%Rn8%%c6L%h)vkX@QmM+mR<}78^wCyOP~LB<ZUvE0SvV
zVM7-akoHBO-MQ+91|rp{KBuOevQc5zH0xJ&^+~%4)Ts(~vf*qx(q#{VO%-F5B#H+A
z`a+S2`ueHBHM>y_|IiKOTn*&hLCe99->L5>)aIPIBXP!Mll{ET7p9<tTnnX51|n13
z)at@adIpl4)3*nQ|406Ck>L9hV#_t(cezO8)%SIH!crR+mzVJ>J#z5XP0{*BB}NHc
zzC@iAi!jz>^Ag#V1^?Xluv?*kq#Tc2hQYoTD|HtZzr7Yy-6w4!IC8>#JXD>CoLIl`
z7J=AU#&N9^mDbi&(Q*QaEobBj$d*exi*R^<jlywW#*89Tnj%aZQb3+vzmtzAxbJ4g
zaxFxaNJeCzrcMZV_ggU>eZT}2;qXx`RJM+$Km535MN^ZKeySp)1-xp}BAr7RuW=E3
zgvEC(<iqa0FF9#}<xH$|z+kW|rN-_FeA2VLh5Yp*E?R}p)gU6d8hxfX{6e+H_dND2
z9dZ(B8!i@XohA^F>7<yoctWo=tBh+=ym_?NAQQs>-v0DeqYHGzuvUHCl8zRk33Z)A
z!nm4#OsE_I**hDzT}{p1JlgoXS2x*W!_y!2)~znApd*EwawO!51Ups@m&WfJKFn{R
z;R+3~#^Ckx+v(fs=u%9b#mnp^6?b9nZ`n0+M8Y->FJYa|wR{6`Gob%G4v!-g3KlHf
ze%=LOxcyMYo{lD9nY09_-A;ZO46CGkQjS=dL+7%!*@^#)xq};rSMc>~UlE+-KI*84
z!Agtiip~VaFVZ0*3(Y(($q@rRIlNFMyx=~N%9TJgyhrC+jD;Dy5sAo>F4G-!v=ff$
z9Npbf3REr?et?5DFm-JC+!`4*u(58(B?7T4RQL^Hbbx0ac~O5M3<O&>Dr=~&5wZ$`
zZzOI*AQqkl*UsMXIS4@A-Q|&i6IUt}NT?Q0xGE74SIu!0i}R3n7v?>!48UP9)YIDi
z40Jz$GBRA^4GdZ`V!DgYVPcsg=Jbb^UMO<T+;V)e?OG~dbLGQQH^>^-n`1<<Aqh7A
zsq{GrHa_?DU*gbV3*D;a-!<U;ngQ<}bdEfxj&?p}9qyYh5h-7W!=DCRtuAiA%m9ec
zYR9#VT)6L>7hfM_(h&!z)?!J5mSUkGPLf3DtQ3O=Dh6R31q_dFyIF{VEts>}VpugP
zccGfS3z;N|M@V*7dN{l?IHHebOk=U=$pZn9s<Lpbtgfnt!%ti}72sM$divI`7-%jg
z!K^+`SET=pb<P?#-Pq@M4J`mq3a;#KeGbk)Z)#ZqxH4(<RocgF;d;-Dd@rC20itKu
zolU`4!!LV-ZCH^Ini)Cmz(80rjPXnO4@ova`F{Uod?)n)IMR&?BQZkZST_d3I0Q!5
z`5LSaBx5jL>DJ~bowFQVTYe$kl1c(Iq@Co|XqP^g$-ZOBvH-5Jle5op9AJq<ck@dW
zd_$|7r5GQ;`wwews9<T(Tegd1akugALKk<^RgNz#@x7{IP3Qc9sq6G2HiCXNiY_|a
z60g#^s=j+K*g+`NRjS@d=IT-T1$zDAxPAa~+@F+;u7wM>lpCAT;es4O2}<<?_rFSp
zSunl>+rGcLPDH!NI9*yR1KkBT{L=1h$C3sN;*7LTaaM!(a;a80a0KYt2CxqBbJ96$
z!1Y-!P+j1A7kgPX!z$ps@M3V16^cAJ^6`>)x8d+8XI@+3Py8fsFNMP!qHSHPUYGzW
zn!s$3|4F`BC>&>13cld40)M$@(^1woz^EoC`#h=%$ZEzoh%=<%Xffvmb;DC|(BmcJ
zXxBF^mj2$7&dHeNi5O!9E;HhjYlV%3e@7nU8!`%EOWSMh>zrxub~-cNmgNR!TVG_y
zp%6i~QF*Ien>&iMg(2Q#mIVAHRy&)4dcvB#vNE||dvN!ty431MYZN*Bct8U;y`)eu
zb3N`h{vN2ChgPHnLk3tZ6MI7)y9f?H+vaV<QUWuH+p}XhArP^Ui4VJ|ivjJ$AqE<a
zX%Mmw+a=blbUK&P@aBr7HRRk4yIqwyMc}^lM`bm`YzR>=wZx{2ET&7F1Y%7}<B@MT
z#v?fAkwh*Dqz6X_>5)4}r1G~V{k2@uUyX?PcYn*n-3I7d&R5dW!w|!<sU_sDdZ1e>
z;8O`H7AeW^l*BDA6vQmrbsx6@>c)mslOCX+x}sV2q(b1SFYouS{hQ9s2<-J(^E1W%
zb01V0%+}{R@92sLvvFWn9=6Piz$Upuf!VUtzu|E}TC9xS3)~@~D2a%&05`4IK}^n8
zfPd?-_f9Giwy^g3YQ(}R2kI--9XwGaTW^4ma|LAGo{VW>U%>r7E1@&Tz_E?Rj@k@7
z#PGCsj!`9S5lSJ%|C9oEkY!41Qxl#r6$7%nhS2K{@e13xLyfQ(Meyb*H$jKWPcZXL
zlk2rak=}h$zQkd3@a!6RRtmc0*)}RUpiSiuNq*_Z;dKEL#UfK{Ry+i!ro~B;FcpNs
zaPo+a=jq(e7sRWU#Pf9I&x4Kc20-kGBF%5B8Qy?seR3XOvV+5uHP(MBzjP~#EIo8}
z`FSk}&h?ZO$%{b!i$>eLaB#f^v&e|UDdNjBT|YrO9XoW(5qnb#kKD9(rE~xTI^wtP
z!#P6M<~+-Ln+Flk)9m_=!?#0nw2NUc0U}!)y{+gRdtjFRE^}+vE)LING$;jOj00-p
zcBIRkNJwL)QwT!^exQ<dBXb{Y+P5`F4qFXot1mfQRl>oQySA(Zv)iGUF~B>6bnCDp
zK6{DPr)@GnIr2HCNzlOmmS!G3&|BOp8(>%9{lL`g;l#vPrA}*BT<cLs_2GQL`!|C7
z9tgm)=5F)AkqnC<-r<oUUhv2MM`MCpCRzN9Dm)MuVJN^g6pTpy`B=^P4wE#CAm50I
zk!_0FmBZ7XO{0nV_N_7jdYgtCm%^Qv1~uDAK)Op<**ZLqYN#6hteI7;siM^%A`IrN
zD|l$+Wxi22BEI?<T&}#>DSR8O-B!J{{3<`aGVI&f19rE;AHgyhGNt^JCg#?kmJQN~
zr9{?1G++>Y$mqC+pMmJT>uAA(s^AefwWhv7=qu?U$0(r42|D4!@Te1oU`ELpK^(&@
z;XsnC6jFWBQEfI5Z$6oJx<&FEZjbUZtmp-Mfs^^+UqhgV(===o_$WiMu9J-6d2hiG
zhX#VH8~_-6Pn$PZFHy9&EvTR}d@MtJx)w6^b8?Bj8zAn6j-88?y5}v7UKH4Hc_AP2
z0&3B1DDV`kmUW#5g->}Ie&xplH=g_$YhnE7d^HQc4-G(j{fiE<QV(I7j-YMQV9-04
zd=|?8;{=BVCE)41$LSW*{*{8B<v9A@(A~&$<A9ED^CXYMMYsz`JEe#3Cr01Rj*i_A
z+%xLQ>=y?d7aT0;{bVKzU#OJ-At}8o@U68xFy{Q(yp|5I3LVMu`>1Ruzcc@Xs^r6{
z_}yeFWVdG4H(%Il>>(>$%t&X7_P%j45JjbkjuR>2AUT_h-}K2q=F8ZcJL>*dd+6Gp
zDDedHVE?O~CA0LnP_FVl9}R$JbRgL++Ng4@t~15)H&C0moRUZ%NZ410S2cF?CLf3t
zuMCZ@#G)BNyIrh6W><xLavLufP%1-4djl{Jqr-GY4)RL%k<V$B^_~1`x9H(pWV;0O
z;g3f*!)&1PJ%cCMRy@7j3OdN4^h?Lec2p3M9b?xQ>2;Zj8oQ;P9&%L=Irm8^Apc(4
zTU|`&4yoLOP<d)a);L0Za;^vM18)m&O1qTLR$T2k1;jC)6wt(^eRx|o(9R3U8T8r-
z)Vy`P{tO6h^(EbdkC?RQMYnW45L?rUC_7If|4@}p4O67p|KYwfiny=s+54ku-J;~n
zk5!@6eiEZ!J<!l}kDKB1#xum1ACNQDF>f;1fXWZGxUov=o*;JVf!Z}VSgFcBQb!Xk
zn{51>+gZJ&xp3ZQ83d*5=Ca#{b+qhbnf_a6Pd}DgDyT{OgPgWUINMzPG^z<kP5xRX
zeOC~x>{pvPXS4u}K1`lyyUgwEc5c2mZ`1^gn%rDkL8znkj%51V&lybtqshNFq`3=8
z<ZXY<8~sC{$`3F<wM5KasQv8v-R&46x2@ac4}ML?zSA<gBD|Ah_dK4dP^eR1XGIio
zGkn{%Q|ItJ3V61^wYlBSOIWX0qOU+en6;*@dpW!S`*hwJCatz8%YP2fFu-%<kYdsP
zI*U)u%@60@TnD^Z7TmA2N0?KSaW{PK?DcSVvdiZkdZOn|PBZgow?HiWpLiSEUEvNb
zKM2R%wXYhj(i7E7thWtkiik1I&*obnV_2C|k$!Tn$G;2p_-z2{^W9UJw&-Bvab1z6
z#GSm^3R_toRh|j?3+?X7o*@}RSOKWy))T7$VWYDj<A&2j!)kB3R6yrc+|4~;G%4ur
z&lyrE6m;OR(bz7T6Y8*X{YA#kB7uZT{u@Q<DM`-$O%gldbVtjcP$;sYyLrhML3*C$
zgf<p)J0B6`uR`y>^sb^3I2G5Yycb$|gKI%YRY8_i^)g;*5s`z}r_Yi+g)2U3MwD<f
z4!3!DL7S+X85Br?H58)^%4*oMJ7~>KC~e33SB&}d1L*0)*O;`&fBS_OL6??P|HunG
z@VXV1Zw)&6I%va>rHdj<1uOPzMqlG*giU!+epns$hIFqyEg15HD&waWv2`nCad-2q
zSrc^P!V6xgBwiQ9iuv9&9QvfrmcxKfnZrc<Wk{RLSr04&m?H6BNy-tvrg8<-ZEmW0
zHG|e!3=MdO9OaiaPvrkt`M%KPNBZv(o{udUZ-MPC+eb-_yatm|y-lTpGKb0f`IRhK
ziMi`GRrb9DgH?byNoDU*Il}iz9xFXLT~G6*1*pQbzcjSe#jIFxhZiwrHru45(4!#^
z4Iyosp2F(*(mT&|MfuPEPQt)Jm{^ZujXHK_zE3C2G#z5t+2T9>toq?2p6a2iUMBnb
zp(K^3i_~GRTmLd8&s}I7OnN^z+f6|1B1Z!Q?)}gP81GCs*hoNi$I2Gi^f77DzYl>y
z40aF<PJG$-;V?gTnM>~$JrF0SC@MfXJnYLn%5QBR_h*lWO5puruJyNw`L?!D@L<J@
zKgIa<pf<j1|D+>?!|r-JN@k@imJ3vD^M)ojTD-#<7`E=h-_k{bSZKDfAn=T{F2&As
zmzhapo1ycg$@+rlKhmvglx!Me7YflmvH7~<tvy1$tCiI}IC@Nzh>V$BIi#>h_$u3p
z{hUW8MZcO~mjdf%?>sbnm+wH$?+u5?rSwEC+eyPRFw}<X;m7n~J1L{(PO-oZ=GMB-
zl|+IgG;OA(zuR~U>)NlsBXdH9GvWO8j64Wg-sctUR$jou^s!(j?cYa!X8*tykNeLk
z{J|gU;WpJlf&cxey<FQ4xaN+k*O7YAD7~N@;A^sxce2_<<h1hpqhR-eDc?C6GW1K&
zPqR8;wqW7F2y_zcIFtx|4IwlnG_Ref8koJZ^dLWU;}Q+IHY+f@K<Du`J<zTTl$%^t
z+SyG+2=56Ad*ufK(~~s8%Q1ee`M-8<iLx?TSq6KP^OcoDoUUxC1;>7~$dVje4cGnc
zyh8uf#M=aNgSqgz6xpLkjw#v{Pa-|#4INqTyUJk=5xL3_4w}}<2s=Doe<dNrDS_Mh
zO3PK}36FB=-<bI^>MU<{^ca^+_93@Zge--0nDyvwZ`E`~_2M^_u{zLn=@5^8KNmjI
zfMLZN%uY19o-tf@epZ%TuMKp;zsrjS3%+(nM@>)rl!-dnT#Dfn`vebRn#|TcI9C{J
zT+#MvIRjyJUtjx+?o{SJen2gS%Vp9OTxB&HFTn)!N{gw)vk>u~j5VHQQ-t)#SD3U_
z)YuxmAA^t%1Y9TP=twz*HvUqvfE1C%WiLBfqU0%TIZR4I-5>|ty4_u0x?-S7+E9>A
zhJpmO1NR0b_|16x=OZF`*dfh6HEO*-xkosd>sk4N7oagn!u@zsvf8bXC(=Oc*oXIe
zsgw#HD97EvJHy`FywdO~lk|<o&|}_xQKu_f^U{v8pKrpQ_zl|uuykD9AHJ%`er1OD
z=FkZKf{@Ke_(OPw-UCb;YoGQtPA%wiEz6UXKT&{z#(RzDP$iQ_@+7Yz!0d3&@YYJ-
zT)q=hM~lVaX3lX{{i(GY4)9Gjy`n|UPjH#T6uCC#PI}j|)AKYJpM&JLPI*J}B^?{6
z>U$cLkT+3=^$;%biVyWD64a#T#N&163R`f*x3Q4}O`#c4_cr1lMht!#d#Mw!%S}ec
zY|wen42%Rb7x<eQMW6?m9y5_TRY+ctC|txacqn``)_&_w(|EP#g8t9`FL({6p<aup
zX2+|pnUQPc&Fj->pPElhe4GjG=RHm}$?Ty#*yL3nQP|XTQVW_))dTjo)f+uvtktV}
zG*h1*MxB0lK$bje(PL;RI!zT;93Otr$GcSBSK}rd&#ZdNeiXQt{qJ0=;II&2Mr_sz
ztSS_&2dX&ylmguhB|>6l_;<b2C`37AM3H5>h2_Jr5cIIJ5~3kP6Gi{ro12PN;rXYG
z!J%S1&1XjX-qxu0W$M(iQ+I2fhS>#PhE8!%tg*<pS7R4bBya44zXxw!?>0tCGuB{B
zM2^`fQwjx>uX%gsHS&Wk>jLNP;z_c_G%xGU=E%-ij~|fDNo`Pox`Pet8AZJ0ABP|B
zRqw#}!B>@+Q3Zxdv><@*wk$7JJ{z*rdEdAL*c8s_(8j-I@Y;lfO$Ye_e}7BEF=0#H
z;C1!JYn%dh#G&E{UD2!F$|TNyz}hG+1~)C=wia<0p6poALTGaVrEsb3!Jp6{Ruzp+
zotU25mg0Kk2MO;$w|(b$#8So}&O@}5&J=|dPaMMf0X3mgiZf(zRU=Pw`UJ^W?A8_u
zQVk;|8Mh%<T)bs98|_&wstf%2WvMwPa@n9~%}@cbm&ANU%b_jW>`<WQup6j&?(1uK
z|7#X#!@L@i@?jeb<jkS9wMlZlQZ^`@r|?xx?-_U|z$0_d1fFxx?%tax+h!kg{i62F
zR%~&G5cF1f=*DX7Q*2g(YHHQY=bKMgb+!1JWchf9AE-DU=)U)g1Uy71f)uoFcDAA#
zGx(aAQQGpU@dop|y~+R0&A56q>)E$YEDCR*D;fJ4e9FSjBDiJy3yIK(H)l)&b~Ug=
zf-3^YsaXv(1Ps;)n4T2mWXz}(`!7;9m`8~o(1N<I#dO*w1}NKGR7C{d8`Be39{E`|
zHrOmCqVVehm>O6w8;;EW-gdsA{Q3qDO~(Iobe`z3sR)7#oc+H5zvBCg<G=F!m)8BC
c>wT99BYK?t=}1hzB?5o8+t^#@Z=s(0AJPmnZ~y=R

literal 0
HcmV?d00001

diff --git a/packages/autoskills/skills-registry/shadcn-svelte/cli.md b/packages/autoskills/skills-registry/shadcn-svelte/cli.md
new file mode 100644
index 00000000..f8e31008
--- /dev/null
+++ b/packages/autoskills/skills-registry/shadcn-svelte/cli.md
@@ -0,0 +1,138 @@
+# shadcn-svelte CLI Reference
+
+Configuration is read from `components.json`. See [components.json](https://shadcn-svelte.com/docs/components-json) on the docs site for the full schema.
+
+> **IMPORTANT:** Always run commands using the project's package runner: `npx shadcn-svelte@latest`, `pnpm dlx shadcn-svelte@latest`, or `bunx --bun shadcn-svelte@latest`. Check `packageManager` from the project (or lockfile) to choose the right one. Examples below use `npx shadcn-svelte@latest` but substitute the correct runner for the project.
+
+> **IMPORTANT:** Only use the flags documented below. Do not invent or guess flags — if a flag isn't listed here, it doesn't exist. The CLI auto-detects the package manager; there is no `--package-manager` flag.
+
+## Contents
+
+- Commands: `init`, `add`, `update`, `registry build`
+- Proxy / outgoing requests
+- Presets (via `init`)
+
+---
+
+## Commands
+
+### `init` — Initialize an existing project
+
+```bash
+npx shadcn-svelte@latest init [options]
+```
+
+Installs dependencies, adds the `cn` util, creates `components.json`, and sets up CSS variables. Run `init` from the root of your project.
+
+| Flag                        | Short | Description                                                               | Default   |
+| --------------------------- | ----- | ------------------------------------------------------------------------- | --------- |
+| `--preset <preset>`         | —     | Encoded design-system preset string from the docs site                    | —         |
+| `-c, --cwd <path>`          | `-c`  | Working directory                                                         | current   |
+| `-o, --overwrite`           | —     | Overwrite existing files                                                  | `false`   |
+| `--no-deps`                 | —     | Do not add or install dependencies                                        | —         |
+| `--skip-preflight`          | —     | Ignore preflight checks and continue                                      | `false`   |
+| `--base-color <name>`       | —     | Base color: `neutral`, `stone`, `zinc`, `mauve`, `olive`, `mist`, `taupe` | —         |
+| `--css <path>`              | —     | Path to the global CSS file                                               | —         |
+| `--components-alias <path>` | —     | Import alias for components                                               | —         |
+| `--lib-alias <path>`        | —     | Import alias for lib                                                      | —         |
+| `--utils-alias <path>`      | —     | Import alias for utils                                                    | —         |
+| `--hooks-alias <path>`      | —     | Import alias for hooks                                                    | —         |
+| `--ui-alias <path>`         | —     | Import alias for UI components                                            | —         |
+| `--proxy <proxy>`           | —     | Fetch registry items through this proxy                                   | env-based |
+| `--design-system-url`       | —     | Optional design-system URL (see docs / preset builder)                    | —         |
+| `-h, --help`                | `-h`  | Help                                                                      | —         |
+
+---
+
+### `add` — Add components
+
+```bash
+npx shadcn-svelte@latest add [options] [components...]
+```
+
+Adds components from the configured registry. Arguments are component names from the registry index, or a **URL** to a registry JSON item. With **no** component names, the CLI prompts you to pick components interactively.
+
+| Flag               | Short | Description                                     | Default   |
+| ------------------ | ----- | ----------------------------------------------- | --------- |
+| `-c, --cwd <path>` | `-c`  | Working directory                               | current   |
+| `--no-deps`        | —     | Skip adding and installing package dependencies | —         |
+| `--skip-preflight` | —     | Ignore preflight checks and continue            | `false`   |
+| `-a, --all`        | —     | Install all UI components                       | `false`   |
+| `-y, --yes`        | —     | Skip confirmation prompt                        | `false`   |
+| `-o, --overwrite`  | —     | Overwrite existing files                        | `false`   |
+| `--proxy <proxy>`  | —     | Fetch components through this proxy             | env-based |
+| `-h, --help`       | `-h`  | Help                                            | —         |
+
+---
+
+### `update` — Update installed components
+
+```bash
+npx shadcn-svelte@latest update [options] [components...]
+```
+
+Re-fetches and applies registry content for components **already present** in the project. Run `shadcn-svelte update --help` for options.
+
+| Flag               | Short | Description                                     | Default   |
+| ------------------ | ----- | ----------------------------------------------- | --------- |
+| `-c, --cwd <path>` | `-c`  | Working directory                               | current   |
+| `--skip-preflight` | —     | Ignore preflight checks and continue            | `false`   |
+| `--no-deps`        | —     | Skip adding and installing package dependencies | —         |
+| `-a, --all`        | —     | Update every installed component                | `false`   |
+| `-y, --yes`        | —     | Skip confirmation prompt                        | `false`   |
+| `--proxy <proxy>`  | —     | Fetch through this proxy                        | env-based |
+| `-h, --help`       | `-h`  | Help                                            | —         |
+
+Commit your work before updating; overwrites are destructive.
+
+---
+
+### `registry build` — Build a custom registry
+
+```bash
+npx shadcn-svelte@latest registry build [options] [registry]
+```
+
+Reads a `registry.json` and writes registry JSON files for distribution. Default input: `./registry.json`, default output: `./static/r`.
+
+| Flag                  | Short | Description                     | Default      |
+| --------------------- | ----- | ------------------------------- | ------------ |
+| `-c, --cwd <path>`    | `-c`  | Working directory               | current      |
+| `-o, --output <path>` | `-o`  | Output directory for JSON files | `./static/r` |
+| `-h, --help`          | `-h`  | Help                            | —            |
+
+---
+
+## Outgoing Requests
+
+### Proxy
+
+The CLI can fetch the registry through a proxy. If `HTTP_PROXY` or `http_proxy` is set, requests respect it. You can also pass `--proxy` on `init`, `add`, or `update`.
+
+```bash
+HTTP_PROXY="<proxy-url>" npx shadcn-svelte@latest init
+```
+
+---
+
+## Presets
+
+Design-system options (style, theme, icons, fonts, etc.) can be captured as an encoded **preset** string from the builder on [shadcn-svelte.com](https://shadcn-svelte.com/create). Pass it to **`init`** with `--preset <string>`.
+
+Changing presets on an existing project: re-run **`init`** with the new preset (and confirm overwrites when prompted), or edit `components.json` and CSS and then run `add` / `update` as needed.
+
+---
+
+## `components.json` — useful fields for agents
+
+| Field / path         | Meaning                                                          |
+| -------------------- | ---------------------------------------------------------------- |
+| `tailwind.css`       | Global CSS file path (Tailwind entry / theme variables)          |
+| `tailwind.baseColor` | Base palette (cannot change after init)                          |
+| `aliases.*`          | Import aliases; must match `svelte.config.js` / `tsconfig` paths |
+| `registry`           | Base registry URL (default `https://shadcn-svelte.com/registry`) |
+| `style`              | Registered style name (e.g. `nova`, `vega`, …)                   |
+| `iconLibrary`        | Icon set key (`lucide`, `tabler`, …) — drives generated imports  |
+| `typescript`         | Whether TS and optional custom config path                       |
+
+Resolved paths (including `tailwindCss`, `ui`, `components`) are computed by the CLI from `components.json` and the filesystem. Read `components.json` and list the UI directory when you need a snapshot of what is installed.
diff --git a/packages/autoskills/skills-registry/shadcn-svelte/customization.md b/packages/autoskills/skills-registry/shadcn-svelte/customization.md
new file mode 100644
index 00000000..51a52fcd
--- /dev/null
+++ b/packages/autoskills/skills-registry/shadcn-svelte/customization.md
@@ -0,0 +1,213 @@
+# Customization & Theming
+
+Components reference semantic CSS variable tokens. Change the variables to change every component.
+
+## Contents
+
+- How it works (CSS variables → Tailwind utilities → components)
+- Color variables and OKLCH format
+- Dark mode setup
+- Changing the theme (presets, CSS variables)
+- Adding custom colors (Tailwind v3 and v4)
+- Border radius
+- Customizing components (variants, class, wrappers)
+- Checking for updates
+
+---
+
+## How It Works
+
+1. CSS variables defined in `:root` (light) and `.dark` (dark mode).
+2. Tailwind maps them to utilities: `bg-primary`, `text-muted-foreground`, etc.
+3. Components use these utilities — changing a variable changes all components that reference it.
+
+---
+
+## Color Variables
+
+Every color follows the `name` / `name-foreground` convention. The base variable is for backgrounds, `-foreground` is for text/icons on that background.
+
+| Variable                                     | Purpose                          |
+| -------------------------------------------- | -------------------------------- |
+| `--background` / `--foreground`              | Page background and default text |
+| `--card` / `--card-foreground`               | Card surfaces                    |
+| `--primary` / `--primary-foreground`         | Primary buttons and actions      |
+| `--secondary` / `--secondary-foreground`     | Secondary actions                |
+| `--muted` / `--muted-foreground`             | Muted/disabled states            |
+| `--accent` / `--accent-foreground`           | Hover and accent states          |
+| `--destructive` / `--destructive-foreground` | Error and destructive actions    |
+| `--border`                                   | Default border color             |
+| `--input`                                    | Form input borders               |
+| `--ring`                                     | Focus ring color                 |
+| `--chart-1` through `--chart-5`              | Chart/data visualization         |
+| `--sidebar-*`                                | Sidebar-specific colors          |
+| `--surface` / `--surface-foreground`         | Secondary surface                |
+
+Colors use OKLCH: `--primary: oklch(0.205 0 0)` where values are lightness (0–1), chroma (0 = gray), and hue (0–360).
+
+---
+
+## Dark Mode
+
+Class-based toggle via `.dark` on the root element. In SvelteKit, use [mode-watcher](https://github.com/svecosystem/mode-watcher) (see [Dark mode — Svelte](https://shadcn-svelte.com/docs/dark-mode/svelte)):
+
+```svelte
+<script lang="ts">
+  import { ModeWatcher } from "mode-watcher";
+  let { children } = $props();
+</script>
+
+<ModeWatcher />
+{@render children?.()}
+```
+
+---
+
+## Changing the Theme
+
+Use a **preset** from the design-system builder on [shadcn-svelte.com](https://shadcn-svelte.com) and pass it to `init`:
+
+```bash
+npx shadcn-svelte@latest init --preset <code>
+```
+
+Or edit CSS variables directly in the file set in `components.json` as `tailwind.css` (for example `src/app.css`).
+
+To align config and components with a new preset, re-run `init` with `--preset` and confirm overwrites when prompted.
+
+---
+
+## Adding Custom Colors
+
+Add variables to the global CSS file path in `components.json` (`tailwind.css`). Do not create a second global CSS file for theming unless the project already uses that pattern.
+
+```css
+/* 1. Define in the global CSS file. */
+:root {
+  --warning: oklch(0.84 0.16 84);
+  --warning-foreground: oklch(0.28 0.07 46);
+}
+.dark {
+  --warning: oklch(0.41 0.11 46);
+  --warning-foreground: oklch(0.99 0.02 95);
+}
+```
+
+```css
+/* 2a. Register with Tailwind v4 (@theme inline). */
+@theme inline {
+  --color-warning: var(--warning);
+  --color-warning-foreground: var(--warning-foreground);
+}
+```
+
+On Tailwind v3, register in `tailwind.config.js` (see the [Tailwind v3 docs](https://tw3.shadcn-svelte.com) if you maintain a legacy setup):
+
+```js
+// 2b. Register with Tailwind v3 (tailwind.config.js).
+module.exports = {
+  theme: {
+    extend: {
+      colors: {
+        warning: "oklch(var(--warning) / <alpha-value>)",
+        "warning-foreground":
+          "oklch(var(--warning-foreground) / <alpha-value>)",
+      },
+    },
+  },
+};
+```
+
+```svelte
+<!-- 3. Use in components. -->
+<div class="bg-warning text-warning-foreground">Warning</div>
+```
+
+---
+
+## Border Radius
+
+`--radius` controls border radius globally. Components derive values from it (`rounded-lg` = `var(--radius)`, `rounded-md` = `calc(var(--radius) - 2px)`).
+
+---
+
+## Customizing Components
+
+See also: [rules/styling.md](./rules/styling.md) for Incorrect/Correct examples.
+
+Prefer these approaches in order:
+
+### 1. Built-in variants
+
+```svelte
+<script lang="ts">
+  import { Button } from "$lib/components/ui/button";
+</script>
+
+<Button variant="outline" size="sm">Click</Button>
+```
+
+### 2. Tailwind classes via `class`
+
+```svelte
+<script lang="ts">
+  import * as Card from "$lib/components/ui/card";
+</script>
+
+<Card.Root class="mx-auto max-w-md">
+  <Card.Content>...</Card.Content>
+</Card.Root>
+```
+
+### 3. Add a new variant
+
+Edit the component source to add a variant via `tailwind-variants` / `cva` in the `.svelte` or shared variants file:
+
+```ts
+// e.g. in button variants
+warning: "bg-warning text-warning-foreground hover:bg-warning/90",
+```
+
+### 4. Wrapper components
+
+Compose shadcn-svelte primitives into higher-level `.svelte` files:
+
+```svelte
+<script lang="ts">
+  import * as AlertDialog from "$lib/components/ui/alert-dialog";
+  let { title, description, onConfirm, children } = $props();
+  let open = $state(false);
+</script>
+
+<AlertDialog.Root bind:open>
+  <AlertDialog.Trigger>
+    {@render children?.()}
+  </AlertDialog.Trigger>
+  <AlertDialog.Content>
+    <AlertDialog.Header>
+      <AlertDialog.Title>{title}</AlertDialog.Title>
+      <AlertDialog.Description>{description}</AlertDialog.Description>
+    </AlertDialog.Header>
+    <AlertDialog.Footer>
+      <AlertDialog.Cancel>Cancel</AlertDialog.Cancel>
+      <AlertDialog.Action
+        onclick={() => {
+          onConfirm?.();
+          open = false;
+        }}>Confirm</AlertDialog.Action
+      >
+    </AlertDialog.Footer>
+  </AlertDialog.Content>
+</AlertDialog.Root>
+```
+
+---
+
+## Checking for Updates
+
+```bash
+npx shadcn-svelte@latest update button
+npx shadcn-svelte@latest update --all
+```
+
+See [Updating Components in SKILL.md](./SKILL.md#updating-components). Review `git diff` after `update` to see what changed.
diff --git a/packages/autoskills/skills-registry/shadcn-svelte/evals/evals.json b/packages/autoskills/skills-registry/shadcn-svelte/evals/evals.json
new file mode 100644
index 00000000..fcbe4978
--- /dev/null
+++ b/packages/autoskills/skills-registry/shadcn-svelte/evals/evals.json
@@ -0,0 +1,47 @@
+{
+	"skill_name": "shadcn-svelte",
+	"evals": [
+		{
+			"id": 1,
+			"prompt": "I'm building a SvelteKit app with shadcn-svelte (nova style, lucide icons). Create a settings form component with fields for: full name, email address, and notification preferences (email, SMS, push notifications as toggle options). Add validation states for required fields.",
+			"expected_output": "A Svelte component using Field.FieldGroup, Field.Field, ToggleGroup, data-invalid/aria-invalid validation, gap-* spacing, and semantic colors.",
+			"files": [],
+			"expectations": [
+				"Uses Field.FieldGroup and Field.Field for form layout instead of raw div with space-y",
+				"Uses Switch for independent on/off notification toggles (not looping Button with manual active state)",
+				"Uses data-invalid on Field and aria-invalid on the input control for validation states",
+				"Uses gap-* (e.g. gap-4, gap-6) instead of space-y-* or space-x-* for spacing",
+				"Uses semantic color tokens (e.g. bg-background, text-muted-foreground, text-destructive) instead of raw colors like bg-red-500",
+				"No manual dark: color overrides"
+			]
+		},
+		{
+			"id": 2,
+			"prompt": "Create a dialog component for editing a user profile. It should have the user's avatar at the top, input fields for name and bio, and Save/Cancel buttons with appropriate icons. Using shadcn-svelte with tabler icons.",
+			"expected_output": "A Svelte component with Dialog.Title, Avatar with Avatar.Fallback, data-icon on icon buttons, no icon sizing classes, @tabler/icons-svelte imports.",
+			"files": [],
+			"expectations": [
+				"Includes Dialog.Title for accessibility (visible or with sr-only class)",
+				"Avatar includes Avatar.Fallback",
+				"Icons on buttons use the data-icon attribute (data-icon=\"inline-start\" or data-icon=\"inline-end\")",
+				"No sizing classes on icons inside components (no size-4, w-4, h-4, etc.)",
+				"Uses tabler icons (@tabler/icons-svelte) instead of @lucide/svelte when tabler is configured",
+				"Uses shadcn-svelte Dialog patterns (e.g. Dialog.Trigger wrapping the control, or bind:open on Dialog.Root)"
+			]
+		},
+		{
+			"id": 3,
+			"prompt": "Create a dashboard component that shows 4 stat cards in a grid. Each card has a title, large number, percentage change badge, and a loading skeleton state. Using shadcn-svelte with lucide icons.",
+			"expected_output": "A Svelte component with full Card composition, Skeleton for loading, Badge for changes, semantic colors, gap-* spacing.",
+			"files": [],
+			"expectations": [
+				"Uses full Card composition with Card.Header, Card.Title, Card.Content (not dumping everything into Card.Content)",
+				"Uses Skeleton component for loading placeholders instead of custom animate-pulse divs",
+				"Uses Badge component for percentage change instead of custom styled spans",
+				"Uses semantic color tokens instead of raw color values like bg-green-500 or text-red-600",
+				"Uses gap-* instead of space-y-* or space-x-* for spacing",
+				"Uses size-* when width and height are equal instead of separate w-* h-*"
+			]
+		}
+	]
+}
diff --git a/packages/autoskills/skills-registry/shadcn-svelte/rules/composition.md b/packages/autoskills/skills-registry/shadcn-svelte/rules/composition.md
new file mode 100644
index 00000000..bfc0a93f
--- /dev/null
+++ b/packages/autoskills/skills-registry/shadcn-svelte/rules/composition.md
@@ -0,0 +1,244 @@
+# Component Composition
+
+## Contents
+
+- Items always inside their Group component
+- Callouts use Alert
+- Empty states use Empty component
+- Toast notifications use svelte-sonner
+- Choosing between overlay components
+- Dialog, Sheet, and Drawer always need a Title
+- Card structure
+- Button has no isPending or isLoading prop
+- Tabs.Trigger must be inside Tabs.List
+- Avatar always needs Avatar.Fallback
+- Use Separator instead of raw hr or border divs
+- Use Skeleton for loading placeholders
+- Use Badge instead of custom styled spans
+
+---
+
+## Items always inside their Group component
+
+Never render items directly inside the content container.
+
+**Incorrect:**
+
+```svelte
+<script lang="ts">
+  import * as Select from "$lib/components/ui/select";
+</script>
+
+<Select.Content>
+  <Select.Item value="apple">Apple</Select.Item>
+  <Select.Item value="banana">Banana</Select.Item>
+</Select.Content>
+```
+
+**Correct:**
+
+```svelte
+<script lang="ts">
+  import * as Select from "$lib/components/ui/select";
+</script>
+
+<Select.Content>
+  <Select.Group>
+    <Select.Item value="apple">Apple</Select.Item>
+    <Select.Item value="banana">Banana</Select.Item>
+  </Select.Group>
+</Select.Content>
+```
+
+This applies to all group-based components:
+
+| Item                                                          | Group                |
+| ------------------------------------------------------------- | -------------------- |
+| `Select.Item`, `Select.Label`                                 | `Select.Group`       |
+| `DropdownMenu.Item`, `DropdownMenu.Label`, `DropdownMenu.Sub` | `DropdownMenu.Group` |
+| `Menubar.Item`                                                | `Menubar.Group`      |
+| `ContextMenu.Item`                                            | `ContextMenu.Group`  |
+| `Command.Item`                                                | `Command.Group`      |
+
+---
+
+## Callouts use Alert
+
+```svelte
+<script lang="ts">
+  import * as Alert from "$lib/components/ui/alert";
+</script>
+
+<Alert.Root>
+  <Alert.Title>Warning</Alert.Title>
+  <Alert.Description>Something needs attention.</Alert.Description>
+</Alert.Root>
+```
+
+---
+
+## Empty states use Empty component
+
+```svelte
+<script lang="ts">
+  import * as Empty from "$lib/components/ui/empty";
+  import { Button } from "$lib/components/ui/button";
+  import FolderIcon from "@lucide/svelte/icons/folder";
+</script>
+
+<Empty.Root>
+  <Empty.Header>
+    <Empty.Media variant="icon"><FolderIcon /></Empty.Media>
+    <Empty.Title>No projects yet</Empty.Title>
+    <Empty.Description
+      >Get started by creating a new project.</Empty.Description
+    >
+  </Empty.Header>
+  <Empty.Content>
+    <Button>Create Project</Button>
+  </Empty.Content>
+</Empty.Root>
+```
+
+---
+
+## Toast notifications use svelte-sonner
+
+```svelte
+<script lang="ts">
+  import { toast } from "svelte-sonner";
+</script>
+```
+
+```ts
+toast.success("Changes saved.");
+toast.error("Something went wrong.");
+toast("File deleted.", {
+  action: { label: "Undo", onClick: () => undoDelete() },
+});
+```
+
+Mount the `Toaster` from your UI folder once in the app layout (see [Sonner](https://shadcn-svelte.com/docs/components/sonner)).
+
+---
+
+## Choosing between overlay components
+
+| Use case                           | Component     |
+| ---------------------------------- | ------------- |
+| Focused task that requires input   | `Dialog`      |
+| Destructive action confirmation    | `AlertDialog` |
+| Side panel with details or filters | `Sheet`       |
+| Mobile-first bottom panel          | `Drawer`      |
+| Quick info on hover                | `HoverCard`   |
+| Small contextual content on click  | `Popover`     |
+
+---
+
+## Dialog, Sheet, and Drawer always need a Title
+
+`Dialog.Title`, `Sheet.Title`, `Drawer.Title` are required for accessibility. Use `class="sr-only"` if visually hidden.
+
+```svelte
+<script lang="ts">
+  import * as Dialog from "$lib/components/ui/dialog";
+</script>
+
+<Dialog.Content>
+  <Dialog.Header>
+    <Dialog.Title>Edit Profile</Dialog.Title>
+    <Dialog.Description>Update your profile.</Dialog.Description>
+  </Dialog.Header>
+  ...
+</Dialog.Content>
+```
+
+---
+
+## Card structure
+
+Use full composition — don't dump everything into `Card.Content`:
+
+```svelte
+<script lang="ts">
+  import * as Card from "$lib/components/ui/card";
+  import { Button } from "$lib/components/ui/button";
+</script>
+
+<Card.Root>
+  <Card.Header>
+    <Card.Title>Team Members</Card.Title>
+    <Card.Description>Manage your team.</Card.Description>
+  </Card.Header>
+  <Card.Content>...</Card.Content>
+  <Card.Footer>
+    <Button>Invite</Button>
+  </Card.Footer>
+</Card.Root>
+```
+
+---
+
+## Button has no isPending or isLoading prop
+
+Compose with `Spinner` inside `Button` + `disabled`:
+
+```svelte
+<script lang="ts">
+  import { Button } from "$lib/components/ui/button";
+  import { Spinner } from "$lib/components/ui/spinner";
+</script>
+
+<Button disabled>
+  <Spinner data-icon="inline-start" />
+  Saving...
+</Button>
+```
+
+---
+
+## Tabs.Trigger must be inside Tabs.List
+
+Never render `Tabs.Trigger` directly inside `Tabs.Root` — always wrap in `Tabs.List`:
+
+```svelte
+<script lang="ts">
+  import * as Tabs from "$lib/components/ui/tabs";
+  let tab = $state("account");
+</script>
+
+<Tabs.Root bind:value={tab}>
+  <Tabs.List>
+    <Tabs.Trigger value="account">Account</Tabs.Trigger>
+    <Tabs.Trigger value="password">Password</Tabs.Trigger>
+  </Tabs.List>
+  <Tabs.Content value="account">...</Tabs.Content>
+</Tabs.Root>
+```
+
+---
+
+## Avatar always needs Avatar.Fallback
+
+Always include `Avatar.Fallback` for when the image fails to load:
+
+```svelte
+<script lang="ts">
+  import * as Avatar from "$lib/components/ui/avatar";
+</script>
+
+<Avatar.Root>
+  <Avatar.Image src="/avatar.png" alt="User" />
+  <Avatar.Fallback>JD</Avatar.Fallback>
+</Avatar.Root>
+```
+
+---
+
+## Use existing components instead of custom markup
+
+| Instead of                                     | Use                                                                                         |
+| ---------------------------------------------- | ------------------------------------------------------------------------------------------- |
+| `<hr>` or `<div class="border-t">`             | `<Separator />` (`import { Separator } from "$lib/components/ui/separator"`)                |
+| `<div class="animate-pulse">` with styled divs | `<Skeleton class="h-4 w-3/4" />` (`import { Skeleton } from "$lib/components/ui/skeleton"`) |
+| `<span class="rounded-full bg-green-100 ...">` | `<Badge variant="secondary">` (`import { Badge } from "$lib/components/ui/badge"`)          |
diff --git a/packages/autoskills/skills-registry/shadcn-svelte/rules/forms.md b/packages/autoskills/skills-registry/shadcn-svelte/rules/forms.md
new file mode 100644
index 00000000..c779ee4f
--- /dev/null
+++ b/packages/autoskills/skills-registry/shadcn-svelte/rules/forms.md
@@ -0,0 +1,234 @@
+# Forms & Inputs
+
+## Contents
+
+- Forms use Field.FieldGroup + Field.Field
+- InputGroup requires InputGroup.Input/InputGroup.Textarea
+- Buttons inside inputs use InputGroup.Root + InputGroup.Addon
+- Option sets (2–7 choices) use ToggleGroup.Root + ToggleGroup.Item
+- Field.FieldSet + Field.FieldLegend for grouping related fields
+- Field validation and disabled states
+
+---
+
+## Forms use Field.FieldGroup + Field.Field
+
+Always use `Field.FieldGroup` + `Field.Field` — never raw `div` with `space-y-*`:
+
+```svelte
+<script lang="ts">
+  import * as Field from "$lib/components/ui/field";
+  import { Input } from "$lib/components/ui/input";
+</script>
+
+<Field.FieldGroup>
+  <Field.Field>
+    <Field.FieldLabel for="email">Email</Field.FieldLabel>
+    <Input id="email" type="email" />
+  </Field.Field>
+  <Field.Field>
+    <Field.FieldLabel for="password">Password</Field.FieldLabel>
+    <Input id="password" type="password" />
+  </Field.Field>
+</Field.FieldGroup>
+```
+
+Use `Field` with `orientation="horizontal"` for settings pages. Use `Field.FieldLabel` with `class="sr-only"` for visually hidden labels.
+
+**Choosing form controls:**
+
+- Simple text input → `Input`
+- Dropdown with predefined options → `Select`
+- Searchable dropdown → `Combobox`
+- Native HTML select (no JS) → `native-select`
+- Boolean toggle → `Switch` (for settings) or `Checkbox` (for forms)
+- Single choice from few options → `RadioGroup`
+- Toggle between 2–5 options → `ToggleGroup.Root` + `ToggleGroup.Item`
+- OTP/verification code → `InputOTP`
+- Multi-line text → `Textarea`
+
+---
+
+## InputGroup requires InputGroup.Input/InputGroup.Textarea
+
+Never use raw `Input` or `Textarea` inside an `InputGroup.Root`.
+
+**Incorrect:**
+
+```svelte
+<script lang="ts">
+  import * as InputGroup from "$lib/components/ui/input-group";
+  import { Input } from "$lib/components/ui/input";
+</script>
+
+<InputGroup.Root>
+  <Input placeholder="Search..." />
+</InputGroup.Root>
+```
+
+**Correct:**
+
+```svelte
+<script lang="ts">
+  import * as InputGroup from "$lib/components/ui/input-group";
+</script>
+
+<InputGroup.Root>
+  <InputGroup.Input placeholder="Search..." />
+</InputGroup.Root>
+```
+
+---
+
+## Buttons inside inputs use InputGroup.Root + InputGroup.Addon
+
+Never place a `Button` directly inside or adjacent to an `Input` with custom positioning.
+
+**Incorrect:**
+
+```svelte
+<script lang="ts">
+  import { Input } from "$lib/components/ui/input";
+  import { Button } from "$lib/components/ui/button";
+  import SearchIcon from "@lucide/svelte/icons/search";
+</script>
+
+<div class="relative">
+  <Input placeholder="Search..." class="pr-10" />
+  <Button class="absolute top-0 right-0" size="icon">
+    <SearchIcon />
+  </Button>
+</div>
+```
+
+**Correct:**
+
+```svelte
+<script lang="ts">
+  import * as InputGroup from "$lib/components/ui/input-group";
+  import { Button } from "$lib/components/ui/button";
+  import SearchIcon from "@lucide/svelte/icons/search";
+</script>
+
+<InputGroup.Root>
+  <InputGroup.Input placeholder="Search..." />
+  <InputGroup.Addon>
+    <Button size="icon">
+      <SearchIcon data-icon="inline-start" />
+    </Button>
+  </InputGroup.Addon>
+</InputGroup.Root>
+```
+
+---
+
+## Option sets (2–7 choices) use ToggleGroup.Root + ToggleGroup.Item
+
+Don't manually loop `Button` components with active state.
+
+**Incorrect:**
+
+```svelte
+<script lang="ts">
+  import { Button } from "$lib/components/ui/button";
+  let selected = $state("daily");
+</script>
+
+<div class="flex gap-2">
+  {#each ["daily", "weekly", "monthly"] as option (option)}
+    <Button
+      variant={selected === option ? "default" : "outline"}
+      onclick={() => (selected = option)}
+    >
+      {option}
+    </Button>
+  {/each}
+</div>
+```
+
+**Correct:**
+
+```svelte
+<script lang="ts">
+  import * as ToggleGroup from "$lib/components/ui/toggle-group";
+  let selected = $state("daily");
+</script>
+
+<ToggleGroup.Root bind:value={selected} spacing={2}>
+  <ToggleGroup.Item value="daily">Daily</ToggleGroup.Item>
+  <ToggleGroup.Item value="weekly">Weekly</ToggleGroup.Item>
+  <ToggleGroup.Item value="monthly">Monthly</ToggleGroup.Item>
+</ToggleGroup.Root>
+```
+
+Combine with `Field` for labelled toggle groups:
+
+```svelte
+<script lang="ts">
+  import * as Field from "$lib/components/ui/field";
+  import * as ToggleGroup from "$lib/components/ui/toggle-group";
+</script>
+
+<Field.Field orientation="horizontal">
+  <Field.FieldTitle id="theme-label">Theme</Field.FieldTitle>
+  <ToggleGroup.Root aria-labelledby="theme-label" spacing={2}>
+    <ToggleGroup.Item value="light">Light</ToggleGroup.Item>
+    <ToggleGroup.Item value="dark">Dark</ToggleGroup.Item>
+    <ToggleGroup.Item value="system">System</ToggleGroup.Item>
+  </ToggleGroup.Root>
+</Field.Field>
+```
+
+---
+
+## Field.FieldSet + Field.FieldLegend for grouping related fields
+
+Use `Field.FieldSet` + `Field.FieldLegend` for related checkboxes, radios, or switches — not `div` with a heading:
+
+```svelte
+<script lang="ts">
+  import * as Field from "$lib/components/ui/field";
+  import { Checkbox } from "$lib/components/ui/checkbox";
+</script>
+
+<Field.FieldSet>
+  <Field.FieldLegend variant="label">Preferences</Field.FieldLegend>
+  <Field.FieldDescription>Select all that apply.</Field.FieldDescription>
+  <Field.FieldGroup class="gap-3">
+    <Field.Field orientation="horizontal">
+      <Checkbox id="dark" />
+      <Field.FieldLabel for="dark" class="font-normal"
+        >Dark mode</Field.FieldLabel
+      >
+    </Field.Field>
+  </Field.FieldGroup>
+</Field.FieldSet>
+```
+
+---
+
+## Field validation and disabled states
+
+Both attributes are needed — `data-invalid`/`data-disabled` styles the field (label, description), while `aria-invalid`/`disabled` styles the control.
+
+```svelte
+<script lang="ts">
+  import * as Field from "$lib/components/ui/field";
+  import { Input } from "$lib/components/ui/input";
+</script>
+
+<!-- Invalid. -->
+<Field.Field data-invalid>
+  <Field.FieldLabel for="email">Email</Field.FieldLabel>
+  <Input id="email" aria-invalid />
+  <Field.FieldDescription>Invalid email address.</Field.FieldDescription>
+</Field.Field>
+
+<!-- Disabled. -->
+<Field.Field data-disabled>
+  <Field.FieldLabel for="email">Email</Field.FieldLabel>
+  <Input id="email" disabled />
+</Field.Field>
+```
+
+Works for all controls: `Input`, `Textarea`, `Select`, `Checkbox`, `RadioGroupItem`, `Switch`, `Slider`, `NativeSelect`, `InputOTP`.
diff --git a/packages/autoskills/skills-registry/shadcn-svelte/rules/icons.md b/packages/autoskills/skills-registry/shadcn-svelte/rules/icons.md
new file mode 100644
index 00000000..4db886d9
--- /dev/null
+++ b/packages/autoskills/skills-registry/shadcn-svelte/rules/icons.md
@@ -0,0 +1,107 @@
+# Icons
+
+**Always use the project's configured `iconLibrary` for imports.** Check the `iconLibrary` field in `components.json`: `lucide` → `@lucide/svelte`, `tabler` → `@tabler/icons-svelte`, etc. Never assume `@lucide/svelte`.
+
+---
+
+## Icons in Button use data-icon attribute
+
+Add `data-icon="inline-start"` (prefix) or `data-icon="inline-end"` (suffix) to the icon. No sizing classes on the icon.
+
+**Incorrect:**
+
+```svelte
+<script lang="ts">
+  import { Button } from "$lib/components/ui/button";
+  import SearchIcon from "@lucide/svelte/icons/search";
+</script>
+
+<Button>
+  <SearchIcon class="mr-2 size-4" />
+  Search
+</Button>
+```
+
+**Correct:**
+
+```svelte
+<script lang="ts">
+  import { Button } from "$lib/components/ui/button";
+  import SearchIcon from "@lucide/svelte/icons/search";
+  import ArrowRightIcon from "@lucide/svelte/icons/arrow-right";
+</script>
+
+<Button>
+  <SearchIcon data-icon="inline-start" />
+  Search
+</Button>
+
+<Button>
+  Next
+  <ArrowRightIcon data-icon="inline-end" />
+</Button>
+```
+
+---
+
+## No sizing classes on icons inside components
+
+Components handle icon sizing via CSS. Don't add `size-4`, `w-4 h-4`, or other sizing classes to icons inside `<Button>`, `DropdownMenu.Item`, `Alert.Root`, `Sidebar.*`, or other shadcn-svelte components — unless the user explicitly asks for custom icon sizes.
+
+**Incorrect:**
+
+```svelte
+<script lang="ts">
+  import { Button } from "$lib/components/ui/button";
+  import SearchIcon from "@lucide/svelte/icons/search";
+</script>
+
+<Button>
+  <SearchIcon class="size-4" data-icon="inline-start" />
+  Search
+</Button>
+```
+
+**Correct:**
+
+```svelte
+<script lang="ts">
+  import { Button } from "$lib/components/ui/button";
+  import SearchIcon from "@lucide/svelte/icons/search";
+</script>
+
+<Button>
+  <SearchIcon data-icon="inline-start" />
+  Search
+</Button>
+```
+
+The same applies to icons inside `DropdownMenu.Item`, sidebar items, and other menu rows — no extra sizing classes on the icon component.
+
+---
+
+## Pass icons as components, not string keys
+
+Use a component reference, not a string key to a lookup map.
+
+**Incorrect:**
+
+```svelte
+<!-- String key lookup — avoid -->
+<DynamicIcon name="check" />
+```
+
+**Correct:**
+
+```svelte
+<script lang="ts">
+  import type { Component } from "svelte";
+  import CheckIcon from "@lucide/svelte/icons/check";
+
+  let { Icon }: { Icon: Component } = $props();
+</script>
+
+<Icon />
+
+<!-- <StatusBadge Icon={CheckIcon} /> -->
+```
diff --git a/packages/autoskills/skills-registry/shadcn-svelte/rules/styling.md b/packages/autoskills/skills-registry/shadcn-svelte/rules/styling.md
new file mode 100644
index 00000000..733e6091
--- /dev/null
+++ b/packages/autoskills/skills-registry/shadcn-svelte/rules/styling.md
@@ -0,0 +1,195 @@
+# Styling & Customization
+
+See [customization.md](../customization.md) for theming, CSS variables, and adding custom colors.
+
+## Contents
+
+- Semantic colors
+- Built-in variants first
+- class for layout only
+- No space-x-_ / space-y-_
+- Prefer size-_ over w-_ h-\* when equal
+- Prefer truncate shorthand
+- No manual dark: color overrides
+- Use cn() for conditional classes
+- No manual z-index on overlay components
+
+---
+
+## Semantic colors
+
+**Incorrect:**
+
+```svelte
+<div class="bg-blue-500 text-white">
+  <p class="text-gray-600">Secondary text</p>
+</div>
+```
+
+**Correct:**
+
+```svelte
+<div class="bg-primary text-primary-foreground">
+  <p class="text-muted-foreground">Secondary text</p>
+</div>
+```
+
+---
+
+## No raw color values for status/state indicators
+
+For positive, negative, or status indicators, use Badge variants, semantic tokens like `text-destructive`, or define custom CSS variables — don't reach for raw Tailwind colors.
+
+**Incorrect:**
+
+```svelte
+<span class="text-emerald-600">+20.1%</span>
+<span class="text-green-500">Active</span>
+<span class="text-red-600">-3.2%</span>
+```
+
+**Correct:**
+
+```svelte
+<script lang="ts">
+  import { Badge } from "$lib/components/ui/badge";
+</script>
+
+<Badge variant="secondary">+20.1%</Badge>
+<Badge>Active</Badge>
+<span class="text-destructive">-3.2%</span>
+```
+
+If you need a success/positive color that doesn't exist as a semantic token, use a Badge variant or ask the user about adding a custom CSS variable to the theme (see [customization.md](../customization.md)).
+
+---
+
+## Built-in variants first
+
+**Incorrect:**
+
+```svelte
+<script lang="ts">
+  import { Button } from "$lib/components/ui/button";
+</script>
+
+<Button class="border-input hover:bg-accent border bg-transparent"
+  >Click me</Button
+>
+```
+
+**Correct:**
+
+```svelte
+<script lang="ts">
+  import { Button } from "$lib/components/ui/button";
+</script>
+
+<Button variant="outline">Click me</Button>
+```
+
+---
+
+## class for layout only
+
+Use `class` for layout (e.g. `max-w-md`, `mx-auto`, `mt-4`), **not** for overriding component colors or typography. To change colors, use semantic tokens, built-in variants, or CSS variables.
+
+**Incorrect:**
+
+```svelte
+<script lang="ts">
+  import * as Card from "$lib/components/ui/card";
+</script>
+
+<Card.Root class="bg-blue-100 font-bold text-blue-900">
+  <Card.Content>Dashboard</Card.Content>
+</Card.Root>
+```
+
+**Correct:**
+
+```svelte
+<script lang="ts">
+  import * as Card from "$lib/components/ui/card";
+</script>
+
+<Card.Root class="mx-auto max-w-md">
+  <Card.Content>Dashboard</Card.Content>
+</Card.Root>
+```
+
+To customize a component's appearance, prefer these approaches in order:
+
+1. **Built-in variants** — `variant="outline"`, `variant="destructive"`, etc.
+2. **Semantic color tokens** — `bg-primary`, `text-muted-foreground`.
+3. **CSS variables** — define custom colors in the global CSS file (see [customization.md](../customization.md)).
+
+---
+
+## No space-x-_ / space-y-_
+
+Use `gap-*` instead. `space-y-4` → `flex flex-col gap-4`. `space-x-2` → `flex gap-2`.
+
+```svelte
+<script lang="ts">
+  import { Input } from "$lib/components/ui/input";
+  import { Button } from "$lib/components/ui/button";
+</script>
+
+<div class="flex flex-col gap-4">
+  <Input />
+  <Input />
+  <Button>Submit</Button>
+</div>
+```
+
+---
+
+## Prefer size-_ over w-_ h-\* when equal
+
+`size-10` not `w-10 h-10`. Applies to icons, avatars, skeletons, etc.
+
+---
+
+## Prefer truncate shorthand
+
+`truncate` not `overflow-hidden text-ellipsis whitespace-nowrap`.
+
+---
+
+## No manual dark: color overrides
+
+Use semantic tokens — they handle light/dark via CSS variables. `bg-background text-foreground` not `bg-white dark:bg-gray-950`.
+
+---
+
+## Use cn() for conditional classes
+
+Use the `cn()` utility from the project for conditional or merged class names. Don't write manual ternaries in `class` strings.
+
+**Incorrect:**
+
+```svelte
+<script lang="ts">
+  let isActive = $state(false);
+</script>
+
+<div class={`flex items-center ${isActive ? "bg-primary text-primary-foreground" : "bg-muted"}`}>
+```
+
+**Correct:**
+
+```svelte
+<script lang="ts">
+  import { cn } from "$lib/utils";
+  let isActive = $state(false);
+</script>
+
+<div class={cn("flex items-center", isActive ? "bg-primary text-primary-foreground" : "bg-muted")}>
+```
+
+---
+
+## No manual z-index on overlay components
+
+`Dialog`, `Sheet`, `Drawer`, `AlertDialog`, `DropdownMenu`, `Popover`, `Tooltip`, `HoverCard` handle their own stacking. Never add `z-50` or `z-[999]`.
diff --git a/packages/autoskills/tests/collect.test.ts b/packages/autoskills/tests/collect.test.ts
index 5ac13efa..05e25abd 100644
--- a/packages/autoskills/tests/collect.test.ts
+++ b/packages/autoskills/tests/collect.test.ts
@@ -305,6 +305,26 @@ describe("collectSkills", () => {
       true,
     );
   });
+
+  it("discriminates between React shadcn and Svelte shadcn", () => {
+    const detected = [
+      { id: "svelte", name: "Svelte", detect: {}, skills: ["ejirocodes/agent-skills/svelte5-best-practices"] },
+      { id: "shadcn", name: "shadcn/ui", detect: {}, skills: ["shadcn/ui/shadcn"] },
+    ];
+    const combos = [
+      {
+        id: "svelte-shadcn",
+        name: "Svelte + shadcn-svelte",
+        requires: ["svelte", "shadcn"],
+        skills: ["huntabyte/shadcn-svelte/shadcn-svelte"],
+      },
+    ];
+    const skills = collectSkills({ detected, isFrontend: false, combos });
+    // Should NOT contain React shadcn skill
+    ok(!skills.some((s) => s.skill === "shadcn/ui/shadcn"));
+    // Should contain Svelte shadcn skill
+    ok(skills.some((s) => s.skill === "huntabyte/shadcn-svelte/shadcn-svelte"));
+  });
 });
 
 describe("getInstalledSkillNames", () => {

From cc134e063e9be5d82b5501dd47869280da99a735 Mon Sep 17 00:00:00 2001
From: seba3567 <sebastian26481@gmail.com>
Date: Mon, 15 Jun 2026 17:09:00 -0400
Subject: [PATCH 2/7] feat(autoskills): add PostgreSQL and SQL optimization
 skills

---
 packages/autoskills/skills-map.ts             |   8 +-
 .../autoskills/skills-registry/index.json     |  56 +++-
 .../postgres-best-practices/SKILL.md          |  14 +
 .../references/schema-design.md               |   9 +
 .../skills-registry/sql-optimization/SKILL.md | 296 ++++++++++++++++++
 packages/autoskills/tests/detect.test.ts      |  10 +-
 6 files changed, 388 insertions(+), 5 deletions(-)
 create mode 100644 packages/autoskills/skills-registry/postgres-best-practices/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/postgres-best-practices/references/schema-design.md
 create mode 100644 packages/autoskills/skills-registry/sql-optimization/SKILL.md

diff --git a/packages/autoskills/skills-map.ts b/packages/autoskills/skills-map.ts
index 79b6b875..7ac8aff9 100644
--- a/packages/autoskills/skills-map.ts
+++ b/packages/autoskills/skills-map.ts
@@ -916,12 +916,16 @@ export const SKILLS_MAP: Technology[] = [
     skills: ["redis/agent-skills/redis-development"],
   },
   {
-    id: "postgres-ruby",
+    id: "postgresql",
     name: "PostgreSQL",
     detect: {
+      packages: ["pg", "postgres", "pg-promise", "sequelize", "typeorm", "mikro-orm"],
       gems: ["pg"],
     },
-    skills: [],
+    skills: [
+      "neondatabase/postgres-skills/postgres-best-practices",
+      "github/awesome-copilot/sql-optimization",
+    ],
   },
   {
     id: "python",
diff --git a/packages/autoskills/skills-registry/index.json b/packages/autoskills/skills-registry/index.json
index a63f3ce7..f0bd60aa 100644
--- a/packages/autoskills/skills-registry/index.json
+++ b/packages/autoskills/skills-registry/index.json
@@ -1,6 +1,6 @@
 {
   "version": 1,
-  "generatedAt": "2026-06-15T20:58:27.158Z",
+  "generatedAt": "2026-06-15T21:08:44.647Z",
   "reviewer": {
     "model": "gpt-5.4",
     "promptVersion": "1.0.0"
@@ -13064,6 +13064,60 @@
         "summary": "review skipped (--no-review)",
         "checkedAt": "2026-06-15T20:58:27.147Z"
       }
+    },
+    "postgres-best-practices": {
+      "source": "neondatabase/postgres-skills",
+      "skillPath": "neondatabase/postgres-skills/postgres-best-practices",
+      "commitSha": "0d9a967085c3bc137ab39ff9e3191c2eb3129d8c",
+      "files": [
+        "SKILL.md",
+        "references/schema-design.md"
+      ],
+      "sha256": {
+        "SKILL.md": "0c09b15e9245f531728942518b93dec552c9d1637b848ae7a811bd0d26e74da4",
+        "references/schema-design.md": "9637105e3817677a30159e70a55cc5991a5a125834309739e9677aa874212cc8"
+      },
+      "bundleHash": "2897990a74483e7015350b14e72bc2d44a86052d2960390b71057f67f5f3a58c",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T21:07:32.664Z"
+      },
+      "securityCheck": {
+        "status": "ok",
+        "findings": [],
+        "summary": "review skipped (--no-review)",
+        "checkedAt": "2026-06-15T21:07:32.664Z"
+      }
+    },
+    "sql-optimization": {
+      "source": "github/awesome-copilot",
+      "skillPath": "github/awesome-copilot/sql-optimization",
+      "commitSha": "b4b9beb69d9e8b21c0dfcfd9c86a835997b6a83b",
+      "files": [
+        "SKILL.md"
+      ],
+      "sha256": {
+        "SKILL.md": "d87639dea8e0208e2161b78b22f6427b0fdf59e95e693b40d48b1226a0c35ccf"
+      },
+      "bundleHash": "60cd76411c1aa29f5cb2f609c180a466c7c43e3552d086edd5d7f26b70beb68c",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T21:08:44.639Z"
+      },
+      "securityCheck": {
+        "status": "ok",
+        "findings": [],
+        "summary": "review skipped (--no-review)",
+        "checkedAt": "2026-06-15T21:08:44.639Z"
+      }
     }
   }
 }
diff --git a/packages/autoskills/skills-registry/postgres-best-practices/SKILL.md b/packages/autoskills/skills-registry/postgres-best-practices/SKILL.md
new file mode 100644
index 00000000..43f34687
--- /dev/null
+++ b/packages/autoskills/skills-registry/postgres-best-practices/SKILL.md
@@ -0,0 +1,14 @@
+---
+name: postgres-best-practices
+description: Best practices and guidelines for working with Postgres. Covers schema design, indexing strategies, query optimization, migrations, and common pitfalls. Use when writing SQL, designing database schemas, optimizing queries, or setting up a Postgres database.
+---
+
+# Postgres Best Practices
+
+Guidelines and best practices for working with Postgres, covering schema design, indexing, query optimization, and common pitfalls.
+
+## References
+
+| Area           | Resource                          | When to Use                                      |
+| -------------- | --------------------------------- | ------------------------------------------------ |
+| Schema Design  | `references/schema-design.md`     | Designing tables, choosing data types, normalizing |
diff --git a/packages/autoskills/skills-registry/postgres-best-practices/references/schema-design.md b/packages/autoskills/skills-registry/postgres-best-practices/references/schema-design.md
new file mode 100644
index 00000000..ffea1720
--- /dev/null
+++ b/packages/autoskills/skills-registry/postgres-best-practices/references/schema-design.md
@@ -0,0 +1,9 @@
+# Schema Design
+
+Best practices for designing Postgres schemas.
+
+## Choosing Data Types
+
+- Prefer `text` over `varchar(n)` unless a length constraint is meaningful to the domain.
+- Use `timestamptz` instead of `timestamp` to always store timezone-aware timestamps.
+- Use `uuid` for primary keys when IDs may be exposed externally or generated client-side.
diff --git a/packages/autoskills/skills-registry/sql-optimization/SKILL.md b/packages/autoskills/skills-registry/sql-optimization/SKILL.md
new file mode 100644
index 00000000..1403dd9d
--- /dev/null
+++ b/packages/autoskills/skills-registry/sql-optimization/SKILL.md
@@ -0,0 +1,296 @@
+---
+name: sql-optimization
+description: 'Universal SQL performance optimization assistant for comprehensive query tuning, indexing strategies, and database performance analysis across all SQL databases (MySQL, PostgreSQL, SQL Server, Oracle). Provides execution plan analysis, pagination optimization, batch operations, and performance monitoring guidance.'
+---
+
+# SQL Performance Optimization Assistant
+
+Expert SQL performance optimization for ${selection} (or entire project if no selection). Focus on universal SQL optimization techniques that work across MySQL, PostgreSQL, SQL Server, Oracle, and other SQL databases.
+
+## 🎯 Core Optimization Areas
+
+### Query Performance Analysis
+```sql
+-- ❌ BAD: Inefficient query patterns
+SELECT * FROM orders o
+WHERE YEAR(o.created_at) = 2024
+  AND o.customer_id IN (
+      SELECT c.id FROM customers c WHERE c.status = 'active'
+  );
+
+-- ✅ GOOD: Optimized query with proper indexing hints
+SELECT o.id, o.customer_id, o.total_amount, o.created_at
+FROM orders o
+INNER JOIN customers c ON o.customer_id = c.id
+WHERE o.created_at >= '2024-01-01' 
+  AND o.created_at < '2025-01-01'
+  AND c.status = 'active';
+
+-- Required indexes:
+-- CREATE INDEX idx_orders_created_at ON orders(created_at);
+-- CREATE INDEX idx_customers_status ON customers(status);
+-- CREATE INDEX idx_orders_customer_id ON orders(customer_id);
+```
+
+### Index Strategy Optimization
+```sql
+-- ❌ BAD: Poor indexing strategy
+CREATE INDEX idx_user_data ON users(email, first_name, last_name, created_at);
+
+-- ✅ GOOD: Optimized composite indexing
+-- For queries filtering by email first, then sorting by created_at
+CREATE INDEX idx_users_email_created ON users(email, created_at);
+
+-- For full-text name searches
+CREATE INDEX idx_users_name ON users(last_name, first_name);
+
+-- For user status queries
+CREATE INDEX idx_users_status_created ON users(status, created_at)
+WHERE status IS NOT NULL;
+```
+
+### Subquery Optimization
+```sql
+-- ❌ BAD: Correlated subquery
+SELECT p.product_name, p.price
+FROM products p
+WHERE p.price > (
+    SELECT AVG(price) 
+    FROM products p2 
+    WHERE p2.category_id = p.category_id
+);
+
+-- ✅ GOOD: Window function approach
+SELECT product_name, price
+FROM (
+    SELECT product_name, price,
+           AVG(price) OVER (PARTITION BY category_id) as avg_category_price
+    FROM products
+) ranked
+WHERE price > avg_category_price;
+```
+
+## 📊 Performance Tuning Techniques
+
+### JOIN Optimization
+```sql
+-- ❌ BAD: Inefficient JOIN order and conditions
+SELECT o.*, c.name, p.product_name
+FROM orders o
+LEFT JOIN customers c ON o.customer_id = c.id
+LEFT JOIN order_items oi ON o.id = oi.order_id
+LEFT JOIN products p ON oi.product_id = p.id
+WHERE o.created_at > '2024-01-01'
+  AND c.status = 'active';
+
+-- ✅ GOOD: Optimized JOIN with filtering
+SELECT o.id, o.total_amount, c.name, p.product_name
+FROM orders o
+INNER JOIN customers c ON o.customer_id = c.id AND c.status = 'active'
+INNER JOIN order_items oi ON o.id = oi.order_id
+INNER JOIN products p ON oi.product_id = p.id
+WHERE o.created_at > '2024-01-01';
+```
+
+### Pagination Optimization
+```sql
+-- ❌ BAD: OFFSET-based pagination (slow for large offsets)
+SELECT * FROM products 
+ORDER BY created_at DESC 
+LIMIT 20 OFFSET 10000;
+
+-- ✅ GOOD: Cursor-based pagination
+SELECT * FROM products 
+WHERE created_at < '2024-06-15 10:30:00'
+ORDER BY created_at DESC 
+LIMIT 20;
+
+-- Or using ID-based cursor
+SELECT * FROM products 
+WHERE id > 1000
+ORDER BY id 
+LIMIT 20;
+```
+
+### Aggregation Optimization
+```sql
+-- ❌ BAD: Multiple separate aggregation queries
+SELECT COUNT(*) FROM orders WHERE status = 'pending';
+SELECT COUNT(*) FROM orders WHERE status = 'shipped';
+SELECT COUNT(*) FROM orders WHERE status = 'delivered';
+
+-- ✅ GOOD: Single query with conditional aggregation
+SELECT 
+    COUNT(CASE WHEN status = 'pending' THEN 1 END) as pending_count,
+    COUNT(CASE WHEN status = 'shipped' THEN 1 END) as shipped_count,
+    COUNT(CASE WHEN status = 'delivered' THEN 1 END) as delivered_count
+FROM orders;
+```
+
+## 🔍 Query Anti-Patterns
+
+### SELECT Performance Issues
+```sql
+-- ❌ BAD: SELECT * anti-pattern
+SELECT * FROM large_table lt
+JOIN another_table at ON lt.id = at.ref_id;
+
+-- ✅ GOOD: Explicit column selection
+SELECT lt.id, lt.name, at.value
+FROM large_table lt
+JOIN another_table at ON lt.id = at.ref_id;
+```
+
+### WHERE Clause Optimization
+```sql
+-- ❌ BAD: Function calls in WHERE clause
+SELECT * FROM orders 
+WHERE UPPER(customer_email) = 'JOHN@EXAMPLE.COM';
+
+-- ✅ GOOD: Index-friendly WHERE clause
+SELECT * FROM orders 
+WHERE customer_email = 'john@example.com';
+-- Consider: CREATE INDEX idx_orders_email ON orders(LOWER(customer_email));
+```
+
+### OR vs UNION Optimization
+```sql
+-- ❌ BAD: Complex OR conditions
+SELECT * FROM products 
+WHERE (category = 'electronics' AND price < 1000)
+   OR (category = 'books' AND price < 50);
+
+-- ✅ GOOD: UNION approach for better optimization
+SELECT * FROM products WHERE category = 'electronics' AND price < 1000
+UNION ALL
+SELECT * FROM products WHERE category = 'books' AND price < 50;
+```
+
+## 📈 Database-Agnostic Optimization
+
+### Batch Operations
+```sql
+-- ❌ BAD: Row-by-row operations
+INSERT INTO products (name, price) VALUES ('Product 1', 10.00);
+INSERT INTO products (name, price) VALUES ('Product 2', 15.00);
+INSERT INTO products (name, price) VALUES ('Product 3', 20.00);
+
+-- ✅ GOOD: Batch insert
+INSERT INTO products (name, price) VALUES 
+('Product 1', 10.00),
+('Product 2', 15.00),
+('Product 3', 20.00);
+```
+
+### Temporary Table Usage
+```sql
+-- ✅ GOOD: Using temporary tables for complex operations
+CREATE TEMPORARY TABLE temp_calculations AS
+SELECT customer_id, 
+       SUM(total_amount) as total_spent,
+       COUNT(*) as order_count
+FROM orders 
+WHERE created_at >= '2024-01-01'
+GROUP BY customer_id;
+
+-- Use the temp table for further calculations
+SELECT c.name, tc.total_spent, tc.order_count
+FROM temp_calculations tc
+JOIN customers c ON tc.customer_id = c.id
+WHERE tc.total_spent > 1000;
+```
+
+## 🛠️ Index Management
+
+### Index Design Principles
+```sql
+-- ✅ GOOD: Covering index design
+CREATE INDEX idx_orders_covering 
+ON orders(customer_id, created_at) 
+INCLUDE (total_amount, status);  -- SQL Server syntax
+-- Or: CREATE INDEX idx_orders_covering ON orders(customer_id, created_at, total_amount, status); -- Other databases
+```
+
+### Partial Index Strategy
+```sql
+-- ✅ GOOD: Partial indexes for specific conditions
+CREATE INDEX idx_orders_active 
+ON orders(created_at) 
+WHERE status IN ('pending', 'processing');
+```
+
+## 📊 Performance Monitoring Queries
+
+### Query Performance Analysis
+```sql
+-- Generic approach to identify slow queries
+-- (Specific syntax varies by database)
+
+-- For MySQL:
+SELECT query_time, lock_time, rows_sent, rows_examined, sql_text
+FROM mysql.slow_log
+ORDER BY query_time DESC;
+
+-- For PostgreSQL:
+SELECT query, calls, total_time, mean_time
+FROM pg_stat_statements
+ORDER BY total_time DESC;
+
+-- For SQL Server:
+SELECT 
+    qs.total_elapsed_time/qs.execution_count as avg_elapsed_time,
+    qs.execution_count,
+    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
+        ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(qt.text)
+        ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)+1) as query_text
+FROM sys.dm_exec_query_stats qs
+CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
+ORDER BY avg_elapsed_time DESC;
+```
+
+## 🎯 Universal Optimization Checklist
+
+### Query Structure
+- [ ] Avoiding SELECT * in production queries
+- [ ] Using appropriate JOIN types (INNER vs LEFT/RIGHT)
+- [ ] Filtering early in WHERE clauses
+- [ ] Using EXISTS instead of IN for subqueries when appropriate
+- [ ] Avoiding functions in WHERE clauses that prevent index usage
+
+### Index Strategy
+- [ ] Creating indexes on frequently queried columns
+- [ ] Using composite indexes in the right column order
+- [ ] Avoiding over-indexing (impacts INSERT/UPDATE performance)
+- [ ] Using covering indexes where beneficial
+- [ ] Creating partial indexes for specific query patterns
+
+### Data Types and Schema
+- [ ] Using appropriate data types for storage efficiency
+- [ ] Normalizing appropriately (3NF for OLTP, denormalized for OLAP)
+- [ ] Using constraints to help query optimizer
+- [ ] Partitioning large tables when appropriate
+
+### Query Patterns
+- [ ] Using LIMIT/TOP for result set control
+- [ ] Implementing efficient pagination strategies
+- [ ] Using batch operations for bulk data changes
+- [ ] Avoiding N+1 query problems
+- [ ] Using prepared statements for repeated queries
+
+### Performance Testing
+- [ ] Testing queries with realistic data volumes
+- [ ] Analyzing query execution plans
+- [ ] Monitoring query performance over time
+- [ ] Setting up alerts for slow queries
+- [ ] Regular index usage analysis
+
+## 📝 Optimization Methodology
+
+1. **Identify**: Use database-specific tools to find slow queries
+2. **Analyze**: Examine execution plans and identify bottlenecks
+3. **Optimize**: Apply appropriate optimization techniques
+4. **Test**: Verify performance improvements
+5. **Monitor**: Continuously track performance metrics
+6. **Iterate**: Regular performance review and optimization
+
+Focus on measurable performance improvements and always test optimizations with realistic data volumes and query patterns.
diff --git a/packages/autoskills/tests/detect.test.ts b/packages/autoskills/tests/detect.test.ts
index ef54dc6d..aee5e81e 100644
--- a/packages/autoskills/tests/detect.test.ts
+++ b/packages/autoskills/tests/detect.test.ts
@@ -1379,7 +1379,13 @@ describe("detectTechnologies (Ruby/Rails)", () => {
   it("detects PostgreSQL from pg gem", () => {
     writeFile(tmp.path, "Gemfile", "gem 'pg'\n");
     const { detected } = detectTechnologies(tmp.path);
-    ok(detected.some((t) => t.id === "postgres-ruby"));
+    ok(detected.some((t) => t.id === "postgresql"));
+  });
+
+  it("detects PostgreSQL from pg npm package", () => {
+    writePackageJson(tmp.path, { dependencies: { pg: "^8.0.0" } });
+    const { detected } = detectTechnologies(tmp.path);
+    ok(detected.some((t) => t.id === "postgresql"));
   });
 
   it("detects Redis from redis gem", () => {
@@ -1435,7 +1441,7 @@ describe("detectTechnologies (Ruby/Rails)", () => {
     const ids = detected.map((t) => t.id);
     ok(ids.includes("ruby"));
     ok(ids.includes("rails"));
-    ok(ids.includes("postgres-ruby"));
+    ok(ids.includes("postgresql"));
     ok(ids.includes("redis-ruby"));
     ok(ids.includes("sidekiq"));
     ok(ids.includes("devise"));

From e53481199d898915f7c5a2c9170f34f3bab893ab Mon Sep 17 00:00:00 2001
From: seba3567 <sebastian26481@gmail.com>
Date: Mon, 15 Jun 2026 17:11:46 -0400
Subject: [PATCH 3/7] feat(autoskills): keep postgres-ruby separate and add
 postgresql separately

---
 packages/autoskills/skills-map.ts        | 9 ++++++++-
 packages/autoskills/tests/detect.test.ts | 4 ++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/packages/autoskills/skills-map.ts b/packages/autoskills/skills-map.ts
index 7ac8aff9..3ae941d1 100644
--- a/packages/autoskills/skills-map.ts
+++ b/packages/autoskills/skills-map.ts
@@ -915,12 +915,19 @@ export const SKILLS_MAP: Technology[] = [
     },
     skills: ["redis/agent-skills/redis-development"],
   },
+  {
+    id: "postgres-ruby",
+    name: "PostgreSQL (Ruby)",
+    detect: {
+      gems: ["pg"],
+    },
+    skills: [],
+  },
   {
     id: "postgresql",
     name: "PostgreSQL",
     detect: {
       packages: ["pg", "postgres", "pg-promise", "sequelize", "typeorm", "mikro-orm"],
-      gems: ["pg"],
     },
     skills: [
       "neondatabase/postgres-skills/postgres-best-practices",
diff --git a/packages/autoskills/tests/detect.test.ts b/packages/autoskills/tests/detect.test.ts
index aee5e81e..2d6d4729 100644
--- a/packages/autoskills/tests/detect.test.ts
+++ b/packages/autoskills/tests/detect.test.ts
@@ -1379,7 +1379,7 @@ describe("detectTechnologies (Ruby/Rails)", () => {
   it("detects PostgreSQL from pg gem", () => {
     writeFile(tmp.path, "Gemfile", "gem 'pg'\n");
     const { detected } = detectTechnologies(tmp.path);
-    ok(detected.some((t) => t.id === "postgresql"));
+    ok(detected.some((t) => t.id === "postgres-ruby"));
   });
 
   it("detects PostgreSQL from pg npm package", () => {
@@ -1441,7 +1441,7 @@ describe("detectTechnologies (Ruby/Rails)", () => {
     const ids = detected.map((t) => t.id);
     ok(ids.includes("ruby"));
     ok(ids.includes("rails"));
-    ok(ids.includes("postgresql"));
+    ok(ids.includes("postgres-ruby"));
     ok(ids.includes("redis-ruby"));
     ok(ids.includes("sidekiq"));
     ok(ids.includes("devise"));

From fa625d0d2c1f7eb4921fcb3fffe1f5fe22c6ae8d Mon Sep 17 00:00:00 2001
From: seba3567 <sebastian26481@gmail.com>
Date: Mon, 15 Jun 2026 17:50:14 -0400
Subject: [PATCH 4/7] feat(autoskills): migrate old Svelte skills to
 spences10/skills runes and structure

---
 packages/autoskills/skills-map.ts             |   8 +-
 .../skills-registry/go-fiber/SKILL.md         |  74 ++
 .../go-fiber/evals/assertions.md              |  37 +
 .../skills-registry/go-fiber/evals/evals.json |  74 ++
 .../examples/01-rest-api-with-middleware.md   | 126 +++
 .../examples/02-websocket-broadcast.md        | 154 ++++
 .../go-fiber/references/error-handling.md     | 245 ++++++
 .../go-fiber/references/middleware.md         | 245 ++++++
 .../go-fiber/references/performance.md        | 228 +++++
 .../go-fiber/references/routing.md            | 180 ++++
 .../go-fiber/references/testing.md            | 285 ++++++
 .../autoskills/skills-registry/index.json     | 116 ++-
 .../svelte-runes/svelte-code-writer/SKILL.md  |  54 ++
 .../svelte-runes/svelte-components/SKILL.md   |  73 ++
 .../references/component-libraries.md         | 105 +++
 .../references/form-patterns.md               | 171 ++++
 .../references/web-components.md              | 146 ++++
 .../svelte-core-bestpractices/SKILL.md        |  47 +
 .../svelte-runes/svelte-deployment/SKILL.md   |  82 ++
 .../references/cloudflare-gotchas.md          |  73 ++
 .../references/library-authoring.md           | 101 +++
 .../svelte-deployment/references/pwa-setup.md | 111 +++
 .../svelte-runes/svelte-layerchart/SKILL.md   |  52 ++
 .../references/full-patterns.md               | 383 ++++++++
 .../references/graph-patterns.md              | 161 ++++
 .../references/tooltip-modes.md               | 113 +++
 .../svelte-runes/svelte-runes/SKILL.md        |  78 ++
 .../examples/bindable-props.svelte            | 228 +++++
 .../examples/effect-vs-derived.svelte         | 154 ++++
 .../references/common-mistakes.md             | 821 ++++++++++++++++++
 .../svelte-runes/references/component-api.md  | 490 +++++++++++
 .../references/reactivity-patterns.md         | 339 ++++++++
 .../references/snippets-vs-slots.md           | 137 +++
 .../svelte-runes/svelte-styling/SKILL.md      |  89 ++
 .../references/styling-patterns.md            | 146 ++++
 .../svelte-template-directives/SKILL.md       |  80 ++
 .../references/attach-patterns.md             | 339 ++++++++
 .../references/other-directives.md            | 235 +++++
 .../svelte-runes/sveltekit-data-flow/SKILL.md |  87 ++
 .../references/client-auth-invalidation.md    | 125 +++
 .../references/error-redirect-handling.md     | 407 +++++++++
 .../explicit-environment-variables.md         |  64 ++
 .../references/form-actions.md                | 315 +++++++
 .../references/load-functions.md              | 292 +++++++
 .../references/serialization.md               | 317 +++++++
 .../sveltekit-remote-functions/SKILL.md       | 123 +++
 .../references/remote-functions.md            | 525 +++++++++++
 .../svelte-runes/sveltekit-structure/SKILL.md |  82 ++
 .../references/error-handling.md              | 274 ++++++
 .../references/file-naming.md                 |  69 ++
 .../references/layout-patterns.md             | 387 +++++++++
 .../references/ssr-hydration.md               |  92 ++
 .../references/svelte-boundary.md             | 144 +++
 .../svelte5-best-practices/SKILL.md           |  81 --
 .../references/events.md                      | 353 --------
 .../references/migration.md                   | 339 --------
 .../references/performance.md                 | 443 ----------
 .../references/runes.md                       | 394 ---------
 .../references/snippets.md                    | 291 -------
 .../references/sveltekit.md                   | 401 ---------
 .../references/typescript.md                  | 305 -------
 packages/autoskills/tests/collect.test.ts     |   2 +-
 62 files changed, 9851 insertions(+), 2641 deletions(-)
 create mode 100644 packages/autoskills/skills-registry/go-fiber/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/go-fiber/evals/assertions.md
 create mode 100644 packages/autoskills/skills-registry/go-fiber/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/go-fiber/examples/01-rest-api-with-middleware.md
 create mode 100644 packages/autoskills/skills-registry/go-fiber/examples/02-websocket-broadcast.md
 create mode 100644 packages/autoskills/skills-registry/go-fiber/references/error-handling.md
 create mode 100644 packages/autoskills/skills-registry/go-fiber/references/middleware.md
 create mode 100644 packages/autoskills/skills-registry/go-fiber/references/performance.md
 create mode 100644 packages/autoskills/skills-registry/go-fiber/references/routing.md
 create mode 100644 packages/autoskills/skills-registry/go-fiber/references/testing.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-code-writer/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-components/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-components/references/component-libraries.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-components/references/form-patterns.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-components/references/web-components.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-core-bestpractices/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-deployment/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/cloudflare-gotchas.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/library-authoring.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/pwa-setup.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/full-patterns.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/graph-patterns.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/tooltip-modes.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-runes/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-runes/examples/bindable-props.svelte
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-runes/examples/effect-vs-derived.svelte
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/common-mistakes.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/component-api.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/reactivity-patterns.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/snippets-vs-slots.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-styling/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-styling/references/styling-patterns.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/references/attach-patterns.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/references/other-directives.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/client-auth-invalidation.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/error-redirect-handling.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/explicit-environment-variables.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/form-actions.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/load-functions.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/serialization.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-remote-functions/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-remote-functions/references/remote-functions.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/error-handling.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/file-naming.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/layout-patterns.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/ssr-hydration.md
 create mode 100644 packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/svelte-boundary.md
 delete mode 100644 packages/autoskills/skills-registry/svelte5-best-practices/SKILL.md
 delete mode 100644 packages/autoskills/skills-registry/svelte5-best-practices/references/events.md
 delete mode 100644 packages/autoskills/skills-registry/svelte5-best-practices/references/migration.md
 delete mode 100644 packages/autoskills/skills-registry/svelte5-best-practices/references/performance.md
 delete mode 100644 packages/autoskills/skills-registry/svelte5-best-practices/references/runes.md
 delete mode 100644 packages/autoskills/skills-registry/svelte5-best-practices/references/snippets.md
 delete mode 100644 packages/autoskills/skills-registry/svelte5-best-practices/references/sveltekit.md
 delete mode 100644 packages/autoskills/skills-registry/svelte5-best-practices/references/typescript.md

diff --git a/packages/autoskills/skills-map.ts b/packages/autoskills/skills-map.ts
index 3ae941d1..fba29ae4 100644
--- a/packages/autoskills/skills-map.ts
+++ b/packages/autoskills/skills-map.ts
@@ -94,8 +94,11 @@ export const SKILLS_MAP: Technology[] = [
       configFiles: ["svelte.config.js"],
     },
     skills: [
-      "ejirocodes/agent-skills/svelte5-best-practices",
-      "sveltejs/ai-tools/svelte-code-writer",
+      "spences10/skills/svelte-runes",
+      "spences10/skills/sveltekit-structure",
+      "spences10/skills/svelte-core-bestpractices",
+      "spences10/skills/sveltekit-data-flow",
+      "spences10/skills/svelte-components",
     ],
   },
   {
@@ -635,6 +638,7 @@ export const SKILLS_MAP: Technology[] = [
     skills: [
       "affaan-m/everything-claude-code/golang-patterns",
       "affaan-m/everything-claude-code/golang-testing",
+      "seba3567/go-fiber",
     ],
   },
   {
diff --git a/packages/autoskills/skills-registry/go-fiber/SKILL.md b/packages/autoskills/skills-registry/go-fiber/SKILL.md
new file mode 100644
index 00000000..7de89f57
--- /dev/null
+++ b/packages/autoskills/skills-registry/go-fiber/SKILL.md
@@ -0,0 +1,74 @@
+---
+name: go-fiber
+description: "Use when building Go Fiber services, including routing, middleware, WebSockets, request validation, structured errors, and performance tuning."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "3.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Go Fiber v3
+
+## Purpose
+
+Production-grade guidance for building high-performance HTTP APIs and real-time services using Go Fiber v3. Fiber is built on top of fasthttp, delivering Express-inspired ergonomics with Go's concurrency model and near-zero allocation routing.
+
+## When to Use
+
+- Building REST or JSON APIs with Go Fiber v3.
+- Configuring middleware stacks for logging, auth, CORS, rate limiting, and recovery.
+- Setting up WebSocket endpoints alongside HTTP routes.
+- Structuring large Fiber applications with route groups and modular handlers.
+- Optimizing request throughput, reducing allocations, and benchmarking Fiber services.
+- Migrating from Express.js or net/http to Fiber.
+
+## Instructions
+
+1. **Initialize the Fiber app with explicit configuration** -- create the app with `fiber.New(fiber.Config{...})` and set `ErrorHandler`, `ReadTimeout`, `WriteTimeout`, `IdleTimeout`, and `BodyLimit` explicitly. Leaving these at defaults in production leads to resource exhaustion under load.
+
+2. **Use the Fiber v3 context API, not fasthttp directly** -- access request data through `c.Params()`, `c.Query()`, `c.Body()`, and `c.JSON()`. Reaching into `c.Context()` for raw fasthttp access breaks Fiber's middleware chain and makes code fragile across version upgrades.
+
+3. **Structure routes with `app.Group()` and mount sub-routers** -- group related endpoints under a common prefix (e.g., `/api/v1`) and attach group-level middleware for auth or rate limiting. This keeps route registration readable and lets you apply cross-cutting concerns at the right scope without global middleware bloat.
+
+4. **Build middleware as `fiber.Handler` functions that call `c.Next()`** -- each middleware must either call `c.Next()` to continue the chain or return an error/response to short-circuit. Place recovery middleware first, then logging, then auth, then route-specific middleware. Order determines execution sequence and matters for correctness.
+
+5. **Validate request bodies with a dedicated validator** -- use `go-playground/validator/v10` or a similar library and bind it through a reusable `validate()` helper that calls `c.BodyParser()` then validates the struct. Return `400` with structured field errors. Do not scatter validation logic across handlers because it becomes inconsistent and hard to test.
+
+6. **Return structured error responses with a custom `ErrorHandler`** -- define an `ErrorHandler` in the app config that maps `*fiber.Error`, sentinel errors, and validation errors to consistent JSON envelopes with `code`, `message`, and optional `details`. This centralizes error formatting and prevents handlers from inventing their own response shapes.
+
+7. **Use `c.Locals()` to pass request-scoped data through middleware** -- store authenticated user, request ID, or trace context in locals. Retrieve with type-safe helper functions. Do not use global variables or package-level state for per-request data because fasthttp reuses contexts across connections.
+
+8. **Handle WebSocket connections with `websocket.New()`** -- register WebSocket routes using `app.Get("/ws", websocket.New(handler))` and guard them with an upgrade-check middleware. Manage connection lifecycles with ping/pong deadlines, read limits, and graceful close. Do not mix WebSocket handler logic with REST handlers.
+
+9. **Implement graceful shutdown with `os.Signal` and `app.ShutdownWithTimeout()`** -- listen for `SIGINT`/`SIGTERM` in a goroutine, then call `app.ShutdownWithTimeout(timeout)` to drain in-flight requests. This prevents dropped connections during deploys and lets health checks report the correct state.
+
+10. **Write handler tests using `app.Test()` with `httptest.NewRequest`** -- construct a Fiber app in the test, register the handler under test, build an `*http.Request`, and call `app.Test(req)`. Assert status codes, headers, and JSON bodies. This avoids spinning up a real server and keeps tests fast and deterministic.
+
+11. **Benchmark with `testing.B` and Fiber's built-in test helper** -- write benchmarks that exercise the full middleware chain per request. Use `b.ReportAllocs()` to track allocation regressions. Profile with `pprof` for CPU and heap hotspots before optimizing.
+
+12. **Configure CORS, Helmet, and Rate Limiter middleware from the official packages** -- use `fiber/middleware/cors`, `fiber/middleware/helmet`, and `fiber/middleware/limiter` with explicit allow-lists and limits. Do not rely on permissive defaults (`AllowOrigins: "*"`) in production because it disables credential-based CORS.
+
+13. **Use `fiber/middleware/recover` as the outermost middleware** -- recover catches panics inside handlers and converts them to 500 responses. Without it, a panic in any handler crashes the entire process. Place it before all other middleware so it wraps the full chain.
+
+14. **Serve static files and templates through Fiber's built-in engines** -- use `app.Static()` for file serving with cache headers and `fiber/template/*` engines for server-side rendering. Configure `MaxAge` and `Compress` to reduce bandwidth. Do not serve static files through custom handlers because it bypasses Fiber's optimized file serving.
+
+15. **Propagate `context.Context` for downstream service calls** -- extract the request context with `c.UserContext()` and pass it to database queries, HTTP clients, and gRPC calls. This ensures cancellation propagates when clients disconnect or timeouts fire.
+
+16. **Keep Fiber-specific code at the boundary** -- handlers should parse the request, delegate to a service layer, and format the response. Business logic must not import `gofiber/fiber`. This separation makes logic testable without HTTP concerns and portable across frameworks.
+
+## Output Format
+
+Produces Go source files with Fiber v3 handler signatures, grouped route registration, middleware chains, structured error types, and table-driven handler tests. Includes `go.mod` dependencies and configuration constants where applicable.
+
+## References
+
+Load only what the current step needs.
+
+| File | Load when |
+| --- | --- |
+| `references/routing.md` | Route registration, groups, parameter parsing, or sub-router mounting needs detail. |
+| `references/middleware.md` | Middleware authoring, ordering, or built-in middleware configuration is in scope. |
+| `references/error-handling.md` | Custom error handler, structured errors, or panic recovery patterns are needed. |
+| `references/testing.md` | Handler testing, integration tests, or benchmark setup is needed. |
+| `references/performance.md` | Allocation profiling, fasthttp tuning, or throughput optimization is in scope. |
diff --git a/packages/autoskills/skills-registry/go-fiber/evals/assertions.md b/packages/autoskills/skills-registry/go-fiber/evals/assertions.md
new file mode 100644
index 00000000..e637e3da
--- /dev/null
+++ b/packages/autoskills/skills-registry/go-fiber/evals/assertions.md
@@ -0,0 +1,37 @@
+# Go Fiber Eval Assertions
+
+## Eval 1: REST API with Middleware Stack
+
+### fiber-app-config
+Verifies the Fiber application is initialized with explicit production configuration rather than defaults. The response must show `fiber.New(fiber.Config{...})` with a custom `ErrorHandler` function, timeout settings (`ReadTimeout`, `WriteTimeout`), and a `BodyLimit`. This ensures the service is hardened against resource exhaustion and has centralized error formatting from the start.
+
+### route-grouping-middleware
+Verifies routes are organized under a versioned group (`/api/v1`) and middleware is layered in the correct order. Recovery must come first to catch panics, followed by request ID injection, logging, and authentication. Rate limiting should be scoped to specific endpoints, not applied globally. This tests that the response understands middleware ordering semantics and does not apply everything globally.
+
+### validation-binding
+Verifies request payloads are validated through struct tags and a validator library, not through ad-hoc checks in the handler. The handler must call `c.BodyParser()` to bind the request body, run validation, and return structured 400 errors with per-field detail. This assertion catches responses that skip validation, validate only at the handler level, or return unstructured error strings.
+
+### custom-error-handler
+Verifies a centralized `ErrorHandler` exists that handles different error types (Fiber errors, validation errors, sentinel errors) and maps them to a consistent JSON shape. The response must not have handlers formatting their own error responses in different ways. This tests for production-quality error consistency.
+
+### handler-tests
+Verifies tests use Fiber's `app.Test()` helper with `httptest.NewRequest` and follow a table-driven pattern. Tests must cover both create and list endpoints, assert on HTTP status codes and JSON response bodies. This catches responses that skip testing, write only happy-path tests, or spin up a real server for unit tests.
+
+---
+
+## Eval 2: WebSocket Endpoint
+
+### websocket-setup
+Verifies the WebSocket route uses the Fiber WebSocket package (`websocket.New()`) and includes an upgrade-check middleware that validates the request is a genuine WebSocket upgrade before allowing connection establishment. This prevents non-WebSocket requests from reaching the handler.
+
+### connection-lifecycle
+Verifies WebSocket connections are configured with read limits and ping/pong handlers for liveness detection. The response must set `SetReadLimit` to prevent oversized messages and configure pong/ping handlers with deadlines. This ensures connections do not hang indefinitely or accept unbounded payloads.
+
+### broadcast-pattern
+Verifies a hub or registry pattern manages active connections with thread safety. The REST endpoint must be able to push messages to all connected WebSocket clients through this shared structure. This tests that the response correctly bridges HTTP and WebSocket communication without race conditions.
+
+### graceful-disconnect
+Verifies the handler properly cleans up when a client disconnects. The connection must be removed from the hub, close frames should be sent, and the read loop must break on error. This catches responses that leak connections or fail silently on client disconnect.
+
+### rest-and-ws-tests
+Verifies both the REST health endpoint and the WebSocket upgrade path are tested. The health test should use `app.Test()` and assert 200. The WebSocket test should verify upgrade behavior or middleware rejection for non-WebSocket requests. This ensures both transport mechanisms have test coverage.
diff --git a/packages/autoskills/skills-registry/go-fiber/evals/evals.json b/packages/autoskills/skills-registry/go-fiber/evals/evals.json
new file mode 100644
index 00000000..11a5e526
--- /dev/null
+++ b/packages/autoskills/skills-registry/go-fiber/evals/evals.json
@@ -0,0 +1,74 @@
+[
+  {
+    "id": "go-fiber-rest-middleware",
+    "prompt": "Build a Go Fiber v3 REST API for a task management service with the following requirements: Create CRUD endpoints for tasks under /api/v1/tasks with proper route grouping. Include a middleware stack with recovery, request ID injection, structured JSON logging, JWT authentication, and rate limiting. Validate request bodies using go-playground/validator. Return structured JSON error responses from a custom ErrorHandler. Implement graceful shutdown. Include table-driven tests for the create and list endpoints.",
+    "assertions": [
+      {
+        "id": "fiber-app-config",
+        "type": "contains_concept",
+        "expected": "Fiber app is created with fiber.New(fiber.Config{...}) including a custom ErrorHandler, ReadTimeout, WriteTimeout, and BodyLimit configuration",
+        "weight": 1.0
+      },
+      {
+        "id": "route-grouping-middleware",
+        "type": "contains_concept",
+        "expected": "Routes are organized with app.Group('/api/v1') and middleware is applied in the correct order: recovery first, then request ID, logging, and auth middleware on the group, with rate limiter on specific routes",
+        "weight": 1.0
+      },
+      {
+        "id": "validation-binding",
+        "type": "contains_concept",
+        "expected": "Request structs have validate tags, c.BodyParser() is called to parse the body, and a validator instance validates the struct with structured field-level error responses returned as 400 JSON",
+        "weight": 1.0
+      },
+      {
+        "id": "custom-error-handler",
+        "type": "contains_concept",
+        "expected": "A custom ErrorHandler function is defined that checks for *fiber.Error, validation errors, and sentinel errors, mapping each to a consistent JSON envelope with code, message, and optional details fields",
+        "weight": 1.0
+      },
+      {
+        "id": "handler-tests",
+        "type": "contains_concept",
+        "expected": "Tests use app.Test() with httptest.NewRequest to exercise the create and list endpoints, asserting on status codes and JSON response bodies in a table-driven pattern with t.Run subtests",
+        "weight": 1.0
+      }
+    ]
+  },
+  {
+    "id": "go-fiber-websocket",
+    "prompt": "Create a Go Fiber v3 service that serves both REST endpoints and WebSocket connections. The REST part should have a GET /api/health endpoint and a POST /api/messages endpoint that publishes messages. The WebSocket part at /ws should upgrade connections with a middleware check, manage connection lifecycles with ping/pong, broadcast messages from the REST endpoint to all connected WebSocket clients, handle client disconnection gracefully, and set read limits. Include tests for both the REST health endpoint and a test that verifies the WebSocket upgrade handshake.",
+    "assertions": [
+      {
+        "id": "websocket-setup",
+        "type": "contains_concept",
+        "expected": "WebSocket route is registered with app.Get('/ws', websocket.New(handler)) and an upgrade-check middleware verifies the websocket upgrade header before allowing the connection",
+        "weight": 1.0
+      },
+      {
+        "id": "connection-lifecycle",
+        "type": "contains_concept",
+        "expected": "WebSocket handler sets read deadline, read limit (SetReadLimit), and configures ping/pong handlers with SetPongHandler or SetPingHandler for connection liveness detection",
+        "weight": 1.0
+      },
+      {
+        "id": "broadcast-pattern",
+        "type": "contains_concept",
+        "expected": "A connection hub or registry manages active WebSocket connections with thread-safe add/remove operations using a mutex or channel, and the REST POST endpoint publishes messages through this hub to all connected clients",
+        "weight": 1.0
+      },
+      {
+        "id": "graceful-disconnect",
+        "type": "contains_concept",
+        "expected": "The WebSocket handler defers connection removal from the hub and connection close, handles read errors by breaking the read loop, and sends close frames before disconnecting",
+        "weight": 1.0
+      },
+      {
+        "id": "rest-and-ws-tests",
+        "type": "contains_concept",
+        "expected": "Tests verify the health endpoint returns 200 with app.Test(), and a separate test verifies the WebSocket upgrade path returns 101 or tests the upgrade middleware rejection for non-WebSocket requests",
+        "weight": 1.0
+      }
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/go-fiber/examples/01-rest-api-with-middleware.md b/packages/autoskills/skills-registry/go-fiber/examples/01-rest-api-with-middleware.md
new file mode 100644
index 00000000..db3f9289
--- /dev/null
+++ b/packages/autoskills/skills-registry/go-fiber/examples/01-rest-api-with-middleware.md
@@ -0,0 +1,126 @@
+# Example: REST API with Middleware Stack
+
+## Prompt
+
+> Build a Fiber v3 REST API for a bookmarks service with CRUD endpoints under /api/v1/bookmarks. Include recovery, request logging, JWT auth, and request validation. Use a custom error handler for consistent JSON errors.
+
+## Expected Output
+
+The skill should produce a complete Fiber application with the following structure:
+
+### Application Bootstrap
+
+```go
+package main
+
+import (
+    "log"
+    "os"
+    "os/signal"
+    "syscall"
+    "time"
+
+    "github.com/gofiber/fiber/v3"
+    "github.com/gofiber/fiber/v3/middleware/recover"
+    "github.com/gofiber/fiber/v3/middleware/requestid"
+)
+
+func main() {
+    app := fiber.New(fiber.Config{
+        ErrorHandler:  customErrorHandler,
+        ReadTimeout:   10 * time.Second,
+        WriteTimeout:  10 * time.Second,
+        IdleTimeout:   120 * time.Second,
+        BodyLimit:     1 * 1024 * 1024, // 1MB
+    })
+
+    // Middleware stack: recovery first, then request ID, then logging
+    app.Use(recover.New())
+    app.Use(requestid.New())
+    app.Use(loggerMiddleware)
+
+    // API group with auth
+    api := app.Group("/api/v1")
+    api.Use(jwtAuthMiddleware)
+
+    // Bookmark routes
+    api.Get("/bookmarks", listBookmarks)
+    api.Post("/bookmarks", createBookmark)
+    api.Get("/bookmarks/:id", getBookmark)
+    api.Put("/bookmarks/:id", updateBookmark)
+    api.Delete("/bookmarks/:id", deleteBookmark)
+
+    // Graceful shutdown
+    go func() {
+        sigCh := make(chan os.Signal, 1)
+        signal.Notify(sigCh, syscall.SIGINT, syscall.SIGTERM)
+        <-sigCh
+        log.Println("Shutting down...")
+        _ = app.ShutdownWithTimeout(30 * time.Second)
+    }()
+
+    log.Fatal(app.Listen(":8080"))
+}
+```
+
+### Custom Error Handler
+
+```go
+func customErrorHandler(c fiber.Ctx, err error) error {
+    code := fiber.StatusInternalServerError
+    message := "Internal Server Error"
+
+    var fe *fiber.Error
+    if errors.As(err, &fe) {
+        code = fe.Code
+        message = fe.Message
+    }
+
+    var ve *ValidationError
+    if errors.As(err, &ve) {
+        code = fiber.StatusBadRequest
+        return c.Status(code).JSON(ErrorResponse{
+            Code:    "VALIDATION_ERROR",
+            Message: "Request validation failed",
+            Details: ve.Fields,
+        })
+    }
+
+    return c.Status(code).JSON(ErrorResponse{
+        Code:    "ERROR",
+        Message: message,
+    })
+}
+```
+
+### Handler with Validation
+
+```go
+type CreateBookmarkRequest struct {
+    URL   string `json:"url" validate:"required,url"`
+    Title string `json:"title" validate:"required,min=1,max=200"`
+    Tags  []string `json:"tags" validate:"max=10,dive,min=1,max=50"`
+}
+
+func createBookmark(c fiber.Ctx) error {
+    var req CreateBookmarkRequest
+    if err := c.BodyParser(&req); err != nil {
+        return fiber.NewError(fiber.StatusBadRequest, "Invalid request body")
+    }
+    if err := validate.Struct(&req); err != nil {
+        return newValidationError(err)
+    }
+
+    bookmark := bookmarkService.Create(c.UserContext(), req)
+    return c.Status(fiber.StatusCreated).JSON(bookmark)
+}
+```
+
+## Key Observations
+
+- The app config includes timeouts and body limits for production safety.
+- Recovery middleware is outermost to catch panics from all subsequent middleware.
+- Route group applies auth middleware only to API routes, not health checks.
+- Validation uses struct tags with a shared validator instance.
+- The error handler distinguishes between Fiber errors, validation errors, and unknown errors.
+- Graceful shutdown listens for OS signals in a separate goroutine.
diff --git a/packages/autoskills/skills-registry/go-fiber/examples/02-websocket-broadcast.md b/packages/autoskills/skills-registry/go-fiber/examples/02-websocket-broadcast.md
new file mode 100644
index 00000000..022b45b9
--- /dev/null
+++ b/packages/autoskills/skills-registry/go-fiber/examples/02-websocket-broadcast.md
@@ -0,0 +1,154 @@
+# Example: WebSocket Broadcast Service
+
+## Prompt
+
+> Create a Fiber service with a REST endpoint that publishes messages and a WebSocket endpoint that broadcasts those messages to all connected clients in real time. Include connection lifecycle management and tests.
+
+## Expected Output
+
+The skill should produce a Fiber application with both HTTP and WebSocket transports:
+
+### Connection Hub
+
+```go
+package ws
+
+import (
+    "sync"
+
+    "github.com/gofiber/contrib/websocket"
+)
+
+type Hub struct {
+    mu      sync.RWMutex
+    clients map[*websocket.Conn]bool
+}
+
+func NewHub() *Hub {
+    return &Hub{
+        clients: make(map[*websocket.Conn]bool),
+    }
+}
+
+func (h *Hub) Register(conn *websocket.Conn) {
+    h.mu.Lock()
+    defer h.mu.Unlock()
+    h.clients[conn] = true
+}
+
+func (h *Hub) Unregister(conn *websocket.Conn) {
+    h.mu.Lock()
+    defer h.mu.Unlock()
+    delete(h.clients, conn)
+    conn.Close()
+}
+
+func (h *Hub) Broadcast(messageType int, data []byte) {
+    h.mu.RLock()
+    defer h.mu.RUnlock()
+    for conn := range h.clients {
+        if err := conn.WriteMessage(messageType, data); err != nil {
+            // Connection will be cleaned up on next read error
+            continue
+        }
+    }
+}
+```
+
+### WebSocket Handler with Lifecycle
+
+```go
+func wsHandler(hub *Hub) func(*websocket.Conn) {
+    return func(c *websocket.Conn) {
+        hub.Register(c)
+        defer hub.Unregister(c)
+
+        // Configure connection limits
+        c.SetReadLimit(4096)
+        c.SetReadDeadline(time.Now().Add(60 * time.Second))
+        c.SetPongHandler(func(string) error {
+            c.SetReadDeadline(time.Now().Add(60 * time.Second))
+            return nil
+        })
+
+        // Read loop -- keeps the connection alive and detects disconnects
+        for {
+            _, _, err := c.ReadMessage()
+            if err != nil {
+                break // Client disconnected or error
+            }
+        }
+    }
+}
+```
+
+### Route Registration
+
+```go
+func setupRoutes(app *fiber.App, hub *Hub) {
+    // Health check (no auth)
+    app.Get("/api/health", func(c fiber.Ctx) error {
+        return c.JSON(fiber.Map{"status": "ok"})
+    })
+
+    // Publish message via REST
+    app.Post("/api/messages", func(c fiber.Ctx) error {
+        var msg MessageRequest
+        if err := c.BodyParser(&msg); err != nil {
+            return fiber.NewError(fiber.StatusBadRequest, "Invalid body")
+        }
+        data, _ := json.Marshal(msg)
+        hub.Broadcast(websocket.TextMessage, data)
+        return c.Status(fiber.StatusAccepted).JSON(fiber.Map{"published": true})
+    })
+
+    // WebSocket upgrade check + handler
+    app.Use("/ws", func(c fiber.Ctx) error {
+        if websocket.IsWebSocketUpgrade(c) {
+            return c.Next()
+        }
+        return fiber.ErrUpgradeRequired
+    })
+    app.Get("/ws", websocket.New(wsHandler(hub)))
+}
+```
+
+### Tests
+
+```go
+func TestHealthEndpoint(t *testing.T) {
+    hub := ws.NewHub()
+    app := fiber.New()
+    setupRoutes(app, hub)
+
+    req := httptest.NewRequest("GET", "/api/health", nil)
+    resp, err := app.Test(req)
+    require.NoError(t, err)
+    assert.Equal(t, 200, resp.StatusCode)
+
+    var body map[string]string
+    json.NewDecoder(resp.Body).Decode(&body)
+    assert.Equal(t, "ok", body["status"])
+}
+
+func TestWebSocketUpgradeRejection(t *testing.T) {
+    hub := ws.NewHub()
+    app := fiber.New()
+    setupRoutes(app, hub)
+
+    // Non-WebSocket request to /ws should be rejected
+    req := httptest.NewRequest("GET", "/ws", nil)
+    resp, err := app.Test(req)
+    require.NoError(t, err)
+    assert.Equal(t, 426, resp.StatusCode) // Upgrade Required
+}
+```
+
+## Key Observations
+
+- The hub uses `sync.RWMutex` for concurrent safety -- reads (broadcast) do not block each other.
+- The WebSocket handler sets read limits and ping/pong deadlines for liveness.
+- Connection cleanup is deferred so it always runs on disconnect.
+- The upgrade middleware checks `IsWebSocketUpgrade` before allowing the connection.
+- REST and WebSocket coexist on the same Fiber app with shared state through the hub.
+- Tests verify both the REST path and the WebSocket upgrade rejection without needing a real WebSocket client.
diff --git a/packages/autoskills/skills-registry/go-fiber/references/error-handling.md b/packages/autoskills/skills-registry/go-fiber/references/error-handling.md
new file mode 100644
index 00000000..b98904a4
--- /dev/null
+++ b/packages/autoskills/skills-registry/go-fiber/references/error-handling.md
@@ -0,0 +1,245 @@
+# Fiber v3 Error Handling
+
+## Custom ErrorHandler
+
+Fiber's `ErrorHandler` in the app config is the central place for all error formatting. Every error returned from a handler or middleware flows through this function.
+
+```go
+app := fiber.New(fiber.Config{
+    ErrorHandler: func(c fiber.Ctx, err error) error {
+        code := fiber.StatusInternalServerError
+        response := ErrorResponse{
+            Code:    "INTERNAL_ERROR",
+            Message: "An unexpected error occurred",
+        }
+
+        // Handle Fiber errors (404, 405, etc.)
+        var fe *fiber.Error
+        if errors.As(err, &fe) {
+            code = fe.Code
+            response.Code = httpStatusToCode(fe.Code)
+            response.Message = fe.Message
+        }
+
+        // Handle validation errors
+        var ve *ValidationError
+        if errors.As(err, &ve) {
+            code = fiber.StatusBadRequest
+            response.Code = "VALIDATION_ERROR"
+            response.Message = "Request validation failed"
+            response.Details = ve.Fields
+        }
+
+        // Handle not-found errors
+        var nfe *NotFoundError
+        if errors.As(err, &nfe) {
+            code = fiber.StatusNotFound
+            response.Code = "NOT_FOUND"
+            response.Message = nfe.Error()
+        }
+
+        // Handle auth errors
+        var ae *AuthError
+        if errors.As(err, &ae) {
+            code = fiber.StatusUnauthorized
+            response.Code = ae.Code
+            response.Message = ae.Error()
+        }
+
+        // Log unexpected errors
+        if code == fiber.StatusInternalServerError {
+            log.Printf("ERROR: %v", err)
+        }
+
+        return c.Status(code).JSON(response)
+    },
+})
+```
+
+## Error Response Structure
+
+Define a consistent envelope for all error responses across the API.
+
+```go
+// ErrorResponse is the standard error envelope
+type ErrorResponse struct {
+    Code    string       `json:"code"`
+    Message string       `json:"message"`
+    Details []FieldError `json:"details,omitempty"`
+}
+
+// FieldError represents a single validation field error
+type FieldError struct {
+    Field   string `json:"field"`
+    Tag     string `json:"tag"`
+    Message string `json:"message"`
+}
+```
+
+## Custom Error Types
+
+Define domain-specific error types that carry enough context for the ErrorHandler to format them correctly.
+
+```go
+// ValidationError wraps validator.ValidationErrors with field details
+type ValidationError struct {
+    Fields []FieldError
+}
+
+func (e *ValidationError) Error() string {
+    return "validation failed"
+}
+
+func NewValidationError(err error) *ValidationError {
+    var ve validator.ValidationErrors
+    if !errors.As(err, &ve) {
+        return &ValidationError{
+            Fields: []FieldError{{Message: err.Error()}},
+        }
+    }
+
+    fields := make([]FieldError, len(ve))
+    for i, fe := range ve {
+        fields[i] = FieldError{
+            Field:   toSnakeCase(fe.Field()),
+            Tag:     fe.Tag(),
+            Message: formatFieldError(fe),
+        }
+    }
+    return &ValidationError{Fields: fields}
+}
+
+// NotFoundError for missing resources
+type NotFoundError struct {
+    Resource string
+    ID       string
+}
+
+func (e *NotFoundError) Error() string {
+    return fmt.Sprintf("%s with ID %s not found", e.Resource, e.ID)
+}
+
+// AuthError for authentication and authorization failures
+type AuthError struct {
+    Code    string
+    Reason  string
+}
+
+func (e *AuthError) Error() string {
+    return e.Reason
+}
+
+// ConflictError for duplicate resource creation
+type ConflictError struct {
+    Resource string
+    Field    string
+    Value    string
+}
+
+func (e *ConflictError) Error() string {
+    return fmt.Sprintf("%s with %s '%s' already exists", e.Resource, e.Field, e.Value)
+}
+```
+
+## Sentinel Errors
+
+Use sentinel errors for well-known conditions that handlers check with `errors.Is`.
+
+```go
+var (
+    ErrUnauthorized   = fiber.NewError(fiber.StatusUnauthorized, "Authentication required")
+    ErrForbidden      = fiber.NewError(fiber.StatusForbidden, "Insufficient permissions")
+    ErrNotFound       = fiber.NewError(fiber.StatusNotFound, "Resource not found")
+    ErrConflict       = fiber.NewError(fiber.StatusConflict, "Resource already exists")
+    ErrRateLimited    = fiber.NewError(fiber.StatusTooManyRequests, "Rate limit exceeded")
+    ErrServiceUnavail = fiber.NewError(fiber.StatusServiceUnavailable, "Service temporarily unavailable")
+)
+```
+
+## Using Errors in Handlers
+
+```go
+func getUser(c fiber.Ctx) error {
+    id := c.Params("id")
+    user, err := userService.FindByID(c.UserContext(), id)
+    if err != nil {
+        if errors.Is(err, sql.ErrNoRows) {
+            return &NotFoundError{Resource: "User", ID: id}
+        }
+        return err // Will be caught as 500 by ErrorHandler
+    }
+    return c.JSON(user)
+}
+
+func createUser(c fiber.Ctx) error {
+    var req CreateUserRequest
+    if err := c.BodyParser(&req); err != nil {
+        return fiber.NewError(fiber.StatusBadRequest, "Invalid request body")
+    }
+    if err := validate.Struct(&req); err != nil {
+        return NewValidationError(err)
+    }
+
+    user, err := userService.Create(c.UserContext(), req)
+    if err != nil {
+        var pgErr *pgconn.PgError
+        if errors.As(err, &pgErr) && pgErr.Code == "23505" {
+            return &ConflictError{Resource: "User", Field: "email", Value: req.Email}
+        }
+        return err
+    }
+
+    return c.Status(fiber.StatusCreated).JSON(user)
+}
+```
+
+## Panic Recovery
+
+The recover middleware catches panics and feeds them to the ErrorHandler.
+
+```go
+import "github.com/gofiber/fiber/v3/middleware/recover"
+
+app.Use(recover.New(recover.Config{
+    EnableStackTrace: true,
+    StackTraceHandler: func(c fiber.Ctx, e interface{}) {
+        // Log the panic with stack trace
+        slog.Error("panic recovered",
+            "error", e,
+            "stack", string(debug.Stack()),
+            "path", c.Path(),
+            "method", c.Method(),
+        )
+    },
+}))
+```
+
+## Error Wrapping for Context
+
+Wrap errors with additional context as they bubble up through service layers.
+
+```go
+// Service layer
+func (s *UserService) Create(ctx context.Context, req CreateUserRequest) (*User, error) {
+    user, err := s.repo.Insert(ctx, req)
+    if err != nil {
+        return nil, fmt.Errorf("create user: %w", err)
+    }
+    return user, nil
+}
+
+// The ErrorHandler uses errors.As to unwrap and find known error types
+// even when they are wrapped with fmt.Errorf("%w", ...)
+```
+
+## HTTP Status Code Mapping
+
+| Error Type | HTTP Status | Code String |
+| --- | --- | --- |
+| `*fiber.Error` | from error | mapped from status |
+| `*ValidationError` | 400 | VALIDATION_ERROR |
+| `*NotFoundError` | 404 | NOT_FOUND |
+| `*AuthError` | 401 | UNAUTHORIZED |
+| `*ConflictError` | 409 | CONFLICT |
+| Unhandled error | 500 | INTERNAL_ERROR |
+| Panic (recovered) | 500 | INTERNAL_ERROR |
diff --git a/packages/autoskills/skills-registry/go-fiber/references/middleware.md b/packages/autoskills/skills-registry/go-fiber/references/middleware.md
new file mode 100644
index 00000000..a9a8d2a4
--- /dev/null
+++ b/packages/autoskills/skills-registry/go-fiber/references/middleware.md
@@ -0,0 +1,245 @@
+# Fiber v3 Middleware
+
+## Middleware Fundamentals
+
+Fiber middleware is any `fiber.Handler` that calls `c.Next()` to pass control downstream. Middleware registered with `app.Use()` runs for every request. Group-level middleware runs only for routes within that group.
+
+```go
+// Basic middleware signature
+func myMiddleware(c fiber.Ctx) error {
+    // Pre-processing (before handler)
+    start := time.Now()
+
+    // Continue to next middleware or handler
+    err := c.Next()
+
+    // Post-processing (after handler)
+    duration := time.Since(start)
+    log.Printf("Request took %v", duration)
+
+    return err
+}
+
+app.Use(myMiddleware)
+```
+
+## Middleware Execution Order
+
+Middleware runs in registration order. Place middleware that must wrap all requests first.
+
+```go
+// Correct order for production
+app.Use(recover.New())          // 1. Catch panics (outermost)
+app.Use(requestid.New())        // 2. Assign request IDs
+app.Use(logger.New())           // 3. Log all requests
+app.Use(cors.New(corsConfig))   // 4. Handle CORS preflight
+app.Use(helmet.New())           // 5. Security headers
+app.Use(limiter.New(limConfig)) // 6. Rate limiting
+
+// Group-level middleware runs after app-level
+api := app.Group("/api")
+api.Use(jwtAuthMiddleware)      // 7. Auth only for API routes
+```
+
+## Built-in Middleware
+
+### Recover
+
+Catches panics and converts them to 500 responses.
+
+```go
+import "github.com/gofiber/fiber/v3/middleware/recover"
+
+app.Use(recover.New(recover.Config{
+    EnableStackTrace: true, // Include stack in error handler
+    StackTraceHandler: func(c fiber.Ctx, e interface{}) {
+        log.Printf("PANIC: %v\n%s", e, debug.Stack())
+    },
+}))
+```
+
+### Request ID
+
+Generates unique request identifiers for tracing.
+
+```go
+import "github.com/gofiber/fiber/v3/middleware/requestid"
+
+app.Use(requestid.New(requestid.Config{
+    Header: "X-Request-Id",
+    Generator: func() string {
+        return uuid.New().String()
+    },
+}))
+
+// Access in handler
+func handler(c fiber.Ctx) error {
+    reqID := c.Locals("requestid").(string)
+    return c.JSON(fiber.Map{"request_id": reqID})
+}
+```
+
+### CORS
+
+Configures Cross-Origin Resource Sharing headers.
+
+```go
+import "github.com/gofiber/fiber/v3/middleware/cors"
+
+app.Use(cors.New(cors.Config{
+    AllowOrigins:     "https://app.example.com, https://admin.example.com",
+    AllowMethods:     "GET,POST,PUT,DELETE,OPTIONS",
+    AllowHeaders:     "Origin, Content-Type, Authorization",
+    AllowCredentials: true,
+    MaxAge:           3600,
+}))
+```
+
+### Helmet
+
+Sets security-related HTTP headers.
+
+```go
+import "github.com/gofiber/fiber/v3/middleware/helmet"
+
+app.Use(helmet.New(helmet.Config{
+    XSSProtection:         "1; mode=block",
+    ContentTypeNosniff:    "nosniff",
+    XFrameOptions:         "DENY",
+    ReferrerPolicy:        "strict-origin-when-cross-origin",
+    CrossOriginEmbedderPolicy: "require-corp",
+    CrossOriginOpenerPolicy:   "same-origin",
+    CrossOriginResourcePolicy: "same-origin",
+    ContentSecurityPolicy: "default-src 'self'; script-src 'self'",
+}))
+```
+
+### Rate Limiter
+
+Limits request rate per client.
+
+```go
+import "github.com/gofiber/fiber/v3/middleware/limiter"
+
+app.Use(limiter.New(limiter.Config{
+    Max:        100,
+    Expiration: 1 * time.Minute,
+    KeyGenerator: func(c fiber.Ctx) string {
+        return c.IP() // Rate limit per IP
+    },
+    LimitReached: func(c fiber.Ctx) error {
+        return c.Status(429).JSON(fiber.Map{
+            "code":    "RATE_LIMIT_EXCEEDED",
+            "message": "Too many requests, please try again later",
+        })
+    },
+    Storage: redisStorage, // Use Redis for distributed deployments
+}))
+```
+
+### Logger
+
+Structured request logging.
+
+```go
+import "github.com/gofiber/fiber/v3/middleware/logger"
+
+app.Use(logger.New(logger.Config{
+    Format:     "${time} | ${status} | ${latency} | ${ip} | ${method} ${path}\n",
+    TimeFormat: time.RFC3339,
+    TimeZone:   "UTC",
+    Output:     os.Stdout,
+}))
+```
+
+## Custom Middleware Patterns
+
+### Authentication Middleware
+
+```go
+func jwtAuthMiddleware(c fiber.Ctx) error {
+    header := c.Get("Authorization")
+    if !strings.HasPrefix(header, "Bearer ") {
+        return fiber.NewError(fiber.StatusUnauthorized, "Missing or invalid token")
+    }
+
+    token := strings.TrimPrefix(header, "Bearer ")
+    claims, err := validateJWT(token)
+    if err != nil {
+        return fiber.NewError(fiber.StatusUnauthorized, "Invalid token")
+    }
+
+    c.Locals("user", claims)
+    return c.Next()
+}
+```
+
+### Timing Middleware
+
+```go
+func timingMiddleware(c fiber.Ctx) error {
+    start := time.Now()
+    err := c.Next()
+    duration := time.Since(start)
+    c.Set("X-Response-Time", duration.String())
+    return err
+}
+```
+
+### Conditional Middleware
+
+```go
+func skipForHealthCheck(handler fiber.Handler) fiber.Handler {
+    return func(c fiber.Ctx) error {
+        if c.Path() == "/health" {
+            return c.Next()
+        }
+        return handler(c)
+    }
+}
+
+app.Use(skipForHealthCheck(jwtAuthMiddleware))
+```
+
+## Middleware with Configuration
+
+Follow the config-pattern convention used by official Fiber middleware.
+
+```go
+type RateLimitConfig struct {
+    Max        int
+    Window     time.Duration
+    KeyFunc    func(fiber.Ctx) string
+    SkipFunc   func(fiber.Ctx) bool
+}
+
+func NewRateLimit(config ...RateLimitConfig) fiber.Handler {
+    cfg := RateLimitConfig{
+        Max:    100,
+        Window: time.Minute,
+        KeyFunc: func(c fiber.Ctx) string { return c.IP() },
+    }
+    if len(config) > 0 {
+        cfg = config[0]
+    }
+
+    return func(c fiber.Ctx) error {
+        if cfg.SkipFunc != nil && cfg.SkipFunc(c) {
+            return c.Next()
+        }
+        key := cfg.KeyFunc(c)
+        // Rate limiting logic using key...
+        return c.Next()
+    }
+}
+```
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Forgetting `c.Next()` | Middleware must call `c.Next()` or return a response |
+| Recovery not first | Place `recover.New()` before all other middleware |
+| Global auth middleware | Apply auth at the group level, not app level |
+| Ignoring `c.Next()` error | Check and return the error from `c.Next()` |
+| Modifying response after send | Check if response has been committed before writing |
diff --git a/packages/autoskills/skills-registry/go-fiber/references/performance.md b/packages/autoskills/skills-registry/go-fiber/references/performance.md
new file mode 100644
index 00000000..dc704689
--- /dev/null
+++ b/packages/autoskills/skills-registry/go-fiber/references/performance.md
@@ -0,0 +1,228 @@
+# Fiber v3 Performance
+
+## Why Fiber is Fast
+
+Fiber is built on `fasthttp`, which avoids the per-request allocations that `net/http` makes. Key differences include object reuse through sync.Pool, zero-copy request parsing, and a radix tree router with no allocations on matched routes.
+
+## App Configuration for Performance
+
+```go
+app := fiber.New(fiber.Config{
+    // Prefork spawns multiple processes for multi-core utilization
+    Prefork: false, // Enable only for pure HTTP workloads without shared state
+
+    // Server tuning
+    ReadTimeout:           10 * time.Second,
+    WriteTimeout:          10 * time.Second,
+    IdleTimeout:           120 * time.Second,
+    ReadBufferSize:        8192,  // Increase for large headers
+    WriteBufferSize:       4096,
+    BodyLimit:             4 * 1024 * 1024, // 4MB
+    Concurrency:           256 * 1024,      // Max concurrent connections
+    DisableStartupMessage: true,            // Reduce log noise in production
+
+    // Reduce allocations
+    DisableDefaultContentType: true,  // Don't set Content-Type on every response
+    StreamRequestBody:         true,  // Stream large uploads instead of buffering
+    ReduceMemoryUsage:         false, // Only enable if memory-constrained
+})
+```
+
+## Prefork Mode
+
+Prefork spawns one process per CPU core. Each process has its own event loop and does not share memory with others.
+
+```go
+app := fiber.New(fiber.Config{
+    Prefork: true,
+})
+```
+
+**When to use prefork:**
+- CPU-bound workloads with minimal shared state
+- Static file serving at scale
+- Stateless API endpoints
+
+**When NOT to use prefork:**
+- WebSocket applications (connections are per-process)
+- In-memory caching (each process has its own cache)
+- Applications with shared mutable state
+
+## Response Optimization
+
+### Avoid unnecessary allocations
+
+```go
+// Bad: allocates a new map every request
+func handler(c fiber.Ctx) error {
+    return c.JSON(map[string]interface{}{
+        "status": "ok",
+        "data":   result,
+    })
+}
+
+// Better: use fiber.Map (type alias, but still allocates)
+func handler(c fiber.Ctx) error {
+    return c.JSON(fiber.Map{"status": "ok", "data": result})
+}
+
+// Best for static responses: pre-serialize
+var healthResponse = []byte(`{"status":"ok"}`)
+
+func healthHandler(c fiber.Ctx) error {
+    c.Set("Content-Type", "application/json")
+    return c.Send(healthResponse)
+}
+```
+
+### Use SendString for text responses
+
+```go
+// Slower: SendString converts to bytes internally
+func handler(c fiber.Ctx) error {
+    return c.SendString("OK")
+}
+
+// For high-throughput text endpoints, pre-convert
+var okBytes = []byte("OK")
+
+func handler(c fiber.Ctx) error {
+    return c.Send(okBytes)
+}
+```
+
+## JSON Serialization
+
+### Use a fast JSON library
+
+```go
+import "github.com/goccy/go-json"
+
+app := fiber.New(fiber.Config{
+    JSONEncoder: gojson.Marshal,
+    JSONDecoder: gojson.Unmarshal,
+})
+```
+
+Benchmarks show `goccy/go-json` and `bytedance/sonic` can be 2-3x faster than `encoding/json` for large payloads.
+
+## Middleware Performance
+
+### Skip unnecessary middleware
+
+```go
+// Skip auth for public endpoints
+app.Use(limiter.New(limiter.Config{
+    Next: func(c fiber.Ctx) bool {
+        return c.Path() == "/health" || c.Path() == "/metrics"
+    },
+    Max:        100,
+    Expiration: time.Minute,
+}))
+```
+
+### Minimize middleware per request
+
+Each middleware adds function call overhead. For hot paths, consider:
+- Using the `Next` function to skip middleware conditionally
+- Combining related middleware into one (e.g., auth + rate limit)
+- Placing expensive middleware only on routes that need it
+
+## Connection Pooling
+
+### Database connections
+
+```go
+db, err := sql.Open("postgres", dsn)
+db.SetMaxOpenConns(25)          // Match expected concurrency
+db.SetMaxIdleConns(25)          // Keep all connections warm
+db.SetConnMaxLifetime(5 * time.Minute) // Rotate connections
+db.SetConnMaxIdleTime(1 * time.Minute) // Close idle connections
+```
+
+### HTTP client reuse
+
+```go
+// Bad: creates a new client per request
+func handler(c fiber.Ctx) error {
+    resp, _ := http.Get("https://api.example.com/data")
+    // ...
+}
+
+// Good: reuse client with connection pooling
+var httpClient = &http.Client{
+    Transport: &http.Transport{
+        MaxIdleConns:        100,
+        MaxIdleConnsPerHost: 10,
+        IdleConnTimeout:     90 * time.Second,
+    },
+    Timeout: 10 * time.Second,
+}
+```
+
+## Profiling with pprof
+
+```go
+import "github.com/gofiber/fiber/v3/middleware/pprof"
+
+// Only enable in non-production or behind admin auth
+if os.Getenv("ENABLE_PPROF") == "true" {
+    app.Use(pprof.New())
+}
+```
+
+Access profiles at:
+- `/debug/pprof/` -- Index
+- `/debug/pprof/heap` -- Heap allocations
+- `/debug/pprof/goroutine` -- Goroutine stacks
+- `/debug/pprof/profile?seconds=30` -- CPU profile
+
+### Analyzing with go tool pprof
+
+```bash
+# CPU profile
+go tool pprof http://localhost:8080/debug/pprof/profile?seconds=30
+
+# Heap profile
+go tool pprof http://localhost:8080/debug/pprof/heap
+
+# Goroutine dump
+go tool pprof http://localhost:8080/debug/pprof/goroutine
+```
+
+## Benchmark Comparison
+
+Run benchmarks to compare implementations:
+
+```go
+func BenchmarkJSONResponse(b *testing.B) {
+    app := fiber.New(fiber.Config{
+        JSONEncoder: gojson.Marshal,
+    })
+    app.Get("/bench", func(c fiber.Ctx) error {
+        return c.JSON(testPayload)
+    })
+
+    req := httptest.NewRequest("GET", "/bench", nil)
+
+    b.ReportAllocs()
+    b.ResetTimer()
+    for i := 0; i < b.N; i++ {
+        app.Test(req, fiber.TestConfig{Timeout: 0})
+    }
+}
+```
+
+## Performance Checklist
+
+| Area | Check |
+| --- | --- |
+| App config | Timeouts, body limits, concurrency set |
+| JSON | Using goccy/go-json or sonic |
+| Middleware | Minimal chain, skip where possible |
+| Database | Connection pool sized to concurrency |
+| HTTP client | Reused with transport pool |
+| Static | Compression and cache headers enabled |
+| Profiling | pprof available in staging |
+| Benchmarks | b.ReportAllocs on critical paths |
+| Memory | No goroutine leaks, bounded workers |
diff --git a/packages/autoskills/skills-registry/go-fiber/references/routing.md b/packages/autoskills/skills-registry/go-fiber/references/routing.md
new file mode 100644
index 00000000..9bf93ba8
--- /dev/null
+++ b/packages/autoskills/skills-registry/go-fiber/references/routing.md
@@ -0,0 +1,180 @@
+# Fiber v3 Routing
+
+## Route Registration
+
+Fiber uses an Express-inspired API for route registration. Routes are matched in registration order against a radix tree for zero-allocation lookups.
+
+```go
+app := fiber.New()
+
+// Basic routes
+app.Get("/", homeHandler)
+app.Post("/users", createUser)
+app.Put("/users/:id", updateUser)
+app.Delete("/users/:id", deleteUser)
+app.Patch("/users/:id", patchUser)
+
+// All methods
+app.All("/fallback", catchAllHandler)
+
+// Custom method
+app.Add("PURGE", "/cache/:key", purgeCache)
+```
+
+## Route Parameters
+
+Parameters are extracted from the URL path using `:name` syntax. Optional parameters use `:name?`. Wildcard catches everything with `*`.
+
+```go
+// Required parameter
+app.Get("/users/:id", func(c fiber.Ctx) error {
+    id := c.Params("id") // string
+    return c.SendString("User: " + id)
+})
+
+// Integer parameter with built-in constraint
+app.Get("/posts/:id<int>", func(c fiber.Ctx) error {
+    id, err := c.ParamsInt("id")
+    if err != nil {
+        return fiber.NewError(fiber.StatusBadRequest, "Invalid ID")
+    }
+    return c.JSON(fiber.Map{"id": id})
+})
+
+// Optional parameter
+app.Get("/files/:name?", func(c fiber.Ctx) error {
+    name := c.Params("name", "index.html") // default value
+    return c.SendString(name)
+})
+
+// Wildcard
+app.Get("/assets/*", func(c fiber.Ctx) error {
+    path := c.Params("*") // everything after /assets/
+    return c.SendFile("./public/" + path)
+})
+```
+
+## Route Groups
+
+Groups share a common prefix and middleware. Nested groups inherit parent middleware.
+
+```go
+// API version group
+api := app.Group("/api")
+api.Use(requestIDMiddleware)
+
+// v1 group inherits /api prefix and requestID middleware
+v1 := api.Group("/v1")
+v1.Use(jwtAuthMiddleware)
+
+// Nested resource
+users := v1.Group("/users")
+users.Get("/", listUsers)         // GET /api/v1/users
+users.Post("/", createUser)       // POST /api/v1/users
+users.Get("/:id", getUser)        // GET /api/v1/users/:id
+users.Put("/:id", updateUser)     // PUT /api/v1/users/:id
+users.Delete("/:id", deleteUser)  // DELETE /api/v1/users/:id
+
+// Admin group with additional middleware
+admin := v1.Group("/admin")
+admin.Use(adminOnlyMiddleware)
+admin.Get("/stats", adminStats)   // GET /api/v1/admin/stats
+```
+
+## Route Naming and URL Generation
+
+Named routes allow URL generation without hardcoding paths.
+
+```go
+app.Get("/users/:id", getUser).Name("user.show")
+app.Post("/users", createUser).Name("user.create")
+
+// Build URL from name
+url, err := app.GetRoute("user.show").Params("id", "42")
+// url = "/users/42"
+```
+
+## Query Parameters
+
+```go
+app.Get("/search", func(c fiber.Ctx) error {
+    q := c.Query("q")                        // string
+    page := c.QueryInt("page", 1)            // int with default
+    limit := c.QueryInt("limit", 20)         // int with default
+
+    // Parse all query params into a struct
+    var filter SearchFilter
+    if err := c.QueryParser(&filter); err != nil {
+        return fiber.NewError(fiber.StatusBadRequest, "Invalid query parameters")
+    }
+
+    return c.JSON(results)
+})
+
+type SearchFilter struct {
+    Query    string   `query:"q"`
+    Page     int      `query:"page"`
+    Limit    int      `query:"limit"`
+    Tags     []string `query:"tags"`
+    SortBy   string   `query:"sort_by"`
+}
+```
+
+## Route Constraints
+
+Fiber supports built-in route constraints that validate parameters at the routing level.
+
+```go
+app.Get("/users/:id<int>", handler)          // integers only
+app.Get("/files/:name<alpha>", handler)      // alphabetic only
+app.Get("/posts/:slug<regex(^[a-z-]+$)>", handler)  // custom regex
+app.Get("/date/:date<datetime(2006-01-02)>", handler) // date format
+
+// Multiple constraints
+app.Get("/items/:id<int;min(1);max(9999)>", handler)
+```
+
+## Mount Sub-Applications
+
+Mount separate Fiber apps for modular architectures.
+
+```go
+// users/app.go
+func NewUsersApp() *fiber.App {
+    app := fiber.New()
+    app.Get("/", listUsers)
+    app.Post("/", createUser)
+    return app
+}
+
+// main.go
+usersApp := users.NewUsersApp()
+app.Mount("/api/v1/users", usersApp)
+```
+
+## Static File Serving
+
+```go
+// Serve directory
+app.Static("/assets", "./public", fiber.Static{
+    Compress:      true,
+    ByteRange:     true,
+    Browse:        false,
+    CacheDuration: 24 * time.Hour,
+    MaxAge:        86400,
+})
+
+// Single file
+app.Static("/favicon.ico", "./public/favicon.ico")
+```
+
+## Route Patterns Summary
+
+| Pattern | Example | Matches |
+| --- | --- | --- |
+| `/literal` | `/users` | Exact match |
+| `/:param` | `/users/:id` | Single segment |
+| `/:param?` | `/users/:id?` | Optional segment |
+| `/*` | `/files/*` | All remaining segments |
+| `/:param<int>` | `/users/:id<int>` | Integer only |
+| `/:param<regex(...)>` | `/slug/:s<regex(^[a-z-]+$)>` | Regex match |
diff --git a/packages/autoskills/skills-registry/go-fiber/references/testing.md b/packages/autoskills/skills-registry/go-fiber/references/testing.md
new file mode 100644
index 00000000..67eee38f
--- /dev/null
+++ b/packages/autoskills/skills-registry/go-fiber/references/testing.md
@@ -0,0 +1,285 @@
+# Fiber v3 Testing
+
+## Handler Testing with app.Test()
+
+Fiber provides `app.Test()` which accepts a standard `*http.Request` and returns an `*http.Response`. This avoids starting a real server and keeps tests fast.
+
+```go
+func TestGetUser(t *testing.T) {
+    app := fiber.New(fiber.Config{
+        ErrorHandler: customErrorHandler,
+    })
+    app.Get("/users/:id", getUser)
+
+    req := httptest.NewRequest("GET", "/users/42", nil)
+    req.Header.Set("Content-Type", "application/json")
+
+    resp, err := app.Test(req)
+    require.NoError(t, err)
+    assert.Equal(t, 200, resp.StatusCode)
+
+    var user User
+    err = json.NewDecoder(resp.Body).Decode(&user)
+    require.NoError(t, err)
+    assert.Equal(t, "42", user.ID)
+}
+```
+
+## Table-Driven Handler Tests
+
+Use table-driven tests to cover multiple scenarios with shared setup.
+
+```go
+func TestCreateBookmark(t *testing.T) {
+    app := setupTestApp()
+
+    tests := []struct {
+        name       string
+        body       interface{}
+        authToken  string
+        wantStatus int
+        wantCode   string
+        checkBody  func(t *testing.T, body []byte)
+    }{
+        {
+            name: "valid bookmark",
+            body: map[string]interface{}{
+                "url":   "https://example.com",
+                "title": "Example Site",
+                "tags":  []string{"web", "reference"},
+            },
+            authToken:  validToken,
+            wantStatus: 201,
+            checkBody: func(t *testing.T, body []byte) {
+                var bm Bookmark
+                require.NoError(t, json.Unmarshal(body, &bm))
+                assert.NotEmpty(t, bm.ID)
+                assert.Equal(t, "https://example.com", bm.URL)
+            },
+        },
+        {
+            name:       "missing required URL",
+            body:       map[string]interface{}{"title": "No URL"},
+            authToken:  validToken,
+            wantStatus: 400,
+            wantCode:   "VALIDATION_ERROR",
+        },
+        {
+            name:       "invalid URL format",
+            body:       map[string]interface{}{"url": "not-a-url", "title": "Bad"},
+            authToken:  validToken,
+            wantStatus: 400,
+            wantCode:   "VALIDATION_ERROR",
+        },
+        {
+            name:       "no auth token",
+            body:       map[string]interface{}{"url": "https://example.com", "title": "Test"},
+            authToken:  "",
+            wantStatus: 401,
+            wantCode:   "UNAUTHORIZED",
+        },
+        {
+            name:       "expired token",
+            body:       map[string]interface{}{"url": "https://example.com", "title": "Test"},
+            authToken:  expiredToken,
+            wantStatus: 401,
+            wantCode:   "TOKEN_EXPIRED",
+        },
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            bodyBytes, _ := json.Marshal(tt.body)
+            req := httptest.NewRequest("POST", "/api/v1/bookmarks",
+                bytes.NewReader(bodyBytes))
+            req.Header.Set("Content-Type", "application/json")
+            if tt.authToken != "" {
+                req.Header.Set("Authorization", "Bearer "+tt.authToken)
+            }
+
+            resp, err := app.Test(req)
+            require.NoError(t, err)
+            assert.Equal(t, tt.wantStatus, resp.StatusCode)
+
+            body, _ := io.ReadAll(resp.Body)
+            if tt.wantCode != "" {
+                var errResp ErrorResponse
+                require.NoError(t, json.Unmarshal(body, &errResp))
+                assert.Equal(t, tt.wantCode, errResp.Code)
+            }
+            if tt.checkBody != nil {
+                tt.checkBody(t, body)
+            }
+        })
+    }
+}
+```
+
+## Testing Middleware
+
+Test middleware in isolation by registering it on a minimal app.
+
+```go
+func TestRequestIDMiddleware(t *testing.T) {
+    app := fiber.New()
+    app.Use(requestIDMiddleware)
+    app.Get("/test", func(c fiber.Ctx) error {
+        return c.JSON(fiber.Map{
+            "request_id": c.Locals("requestid"),
+        })
+    })
+
+    // Test auto-generated ID
+    req := httptest.NewRequest("GET", "/test", nil)
+    resp, err := app.Test(req)
+    require.NoError(t, err)
+
+    id := resp.Header.Get("X-Request-Id")
+    assert.NotEmpty(t, id)
+
+    // Test client-provided ID is preserved
+    req = httptest.NewRequest("GET", "/test", nil)
+    req.Header.Set("X-Request-Id", "client-id-123")
+    resp, err = app.Test(req)
+    require.NoError(t, err)
+    assert.Equal(t, "client-id-123", resp.Header.Get("X-Request-Id"))
+}
+
+func TestAuthMiddleware(t *testing.T) {
+    app := fiber.New(fiber.Config{ErrorHandler: customErrorHandler})
+    app.Use(jwtAuthMiddleware)
+    app.Get("/protected", func(c fiber.Ctx) error {
+        user := c.Locals("user").(*UserClaims)
+        return c.JSON(fiber.Map{"user_id": user.ID})
+    })
+
+    tests := []struct {
+        name       string
+        auth       string
+        wantStatus int
+    }{
+        {"valid token", "Bearer " + validToken, 200},
+        {"missing header", "", 401},
+        {"invalid format", "Token xyz", 401},
+        {"expired token", "Bearer " + expiredToken, 401},
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            req := httptest.NewRequest("GET", "/protected", nil)
+            if tt.auth != "" {
+                req.Header.Set("Authorization", tt.auth)
+            }
+            resp, err := app.Test(req)
+            require.NoError(t, err)
+            assert.Equal(t, tt.wantStatus, resp.StatusCode)
+        })
+    }
+}
+```
+
+## Integration Tests with Database
+
+```go
+func setupTestApp(t *testing.T) *fiber.App {
+    t.Helper()
+
+    db := setupTestDB(t) // Create test database
+    t.Cleanup(func() {
+        db.Close()
+    })
+
+    svc := NewBookmarkService(db)
+    app := fiber.New(fiber.Config{ErrorHandler: customErrorHandler})
+    RegisterRoutes(app, svc)
+    return app
+}
+
+func TestCreateAndListBookmarks(t *testing.T) {
+    app := setupTestApp(t)
+
+    // Create
+    createBody, _ := json.Marshal(CreateBookmarkRequest{
+        URL:   "https://example.com",
+        Title: "Test",
+    })
+    req := httptest.NewRequest("POST", "/api/v1/bookmarks",
+        bytes.NewReader(createBody))
+    req.Header.Set("Content-Type", "application/json")
+    req.Header.Set("Authorization", "Bearer "+testToken)
+
+    resp, err := app.Test(req)
+    require.NoError(t, err)
+    assert.Equal(t, 201, resp.StatusCode)
+
+    // List and verify
+    req = httptest.NewRequest("GET", "/api/v1/bookmarks", nil)
+    req.Header.Set("Authorization", "Bearer "+testToken)
+
+    resp, err = app.Test(req)
+    require.NoError(t, err)
+    assert.Equal(t, 200, resp.StatusCode)
+
+    var list []Bookmark
+    json.NewDecoder(resp.Body).Decode(&list)
+    assert.Len(t, list, 1)
+    assert.Equal(t, "https://example.com", list[0].URL)
+}
+```
+
+## Benchmark Tests
+
+```go
+func BenchmarkGetBookmarks(b *testing.B) {
+    app := setupBenchApp()
+    req := httptest.NewRequest("GET", "/api/v1/bookmarks", nil)
+    req.Header.Set("Authorization", "Bearer "+testToken)
+
+    b.ReportAllocs()
+    b.ResetTimer()
+
+    for i := 0; i < b.N; i++ {
+        resp, err := app.Test(req, fiber.TestConfig{
+            Timeout: 0, // Disable timeout for benchmarks
+        })
+        if err != nil {
+            b.Fatal(err)
+        }
+        resp.Body.Close()
+    }
+}
+```
+
+## Test Helpers
+
+```go
+// makeRequest builds and executes a test request
+func makeRequest(t *testing.T, app *fiber.App, method, path string, body interface{}, token string) *http.Response {
+    t.Helper()
+
+    var bodyReader io.Reader
+    if body != nil {
+        b, _ := json.Marshal(body)
+        bodyReader = bytes.NewReader(b)
+    }
+
+    req := httptest.NewRequest(method, path, bodyReader)
+    req.Header.Set("Content-Type", "application/json")
+    if token != "" {
+        req.Header.Set("Authorization", "Bearer "+token)
+    }
+
+    resp, err := app.Test(req)
+    require.NoError(t, err)
+    return resp
+}
+
+// decodeBody reads and decodes the response body
+func decodeBody[T any](t *testing.T, resp *http.Response) T {
+    t.Helper()
+    var result T
+    body, _ := io.ReadAll(resp.Body)
+    require.NoError(t, json.Unmarshal(body, &result))
+    return result
+}
+```
diff --git a/packages/autoskills/skills-registry/index.json b/packages/autoskills/skills-registry/index.json
index f0bd60aa..7b14f6f2 100644
--- a/packages/autoskills/skills-registry/index.json
+++ b/packages/autoskills/skills-registry/index.json
@@ -1,6 +1,6 @@
 {
   "version": 1,
-  "generatedAt": "2026-06-15T21:08:44.647Z",
+  "generatedAt": "2026-06-15T21:39:39.739Z",
   "reviewer": {
     "model": "gpt-5.4",
     "promptVersion": "1.0.0"
@@ -720,58 +720,112 @@
         "reviewedAt": "2026-04-17T16:30:45.009Z"
       }
     },
-    "svelte5-best-practices": {
-      "source": "ejirocodes/agent-skills",
-      "skillPath": "ejirocodes/agent-skills/svelte5-best-practices",
-      "commitSha": "3a7d482b7cfd1745797f1f0c3491bb4759eb9f68",
+    "svelte-runes": {
+      "source": "spences10/skills",
+      "skillPath": "spences10/skills/svelte-runes",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
       "files": [
         "SKILL.md",
-        "references/events.md",
-        "references/migration.md",
-        "references/performance.md",
-        "references/runes.md",
-        "references/snippets.md",
-        "references/sveltekit.md",
-        "references/typescript.md"
+        "references/reactivity-patterns.md",
+        "references/component-api.md",
+        "references/snippets-vs-slots.md",
+        "references/common-mistakes.md"
       ],
       "sha256": {
-        "SKILL.md": "eeb2be3e32085d47ad5938afd6e96b2a4f9fd9e073ca27ec3f6df32371689b7c",
-        "references/events.md": "c311631df6f8707d94a6c116da211b25b274669cb17c9ecae6a75bb46309895d",
-        "references/migration.md": "c2c574ce8290ef56fa8f7619c2897c8ca009ea72464d4077c7ba5ea23efb3570",
-        "references/performance.md": "ee1ddf521fd3d8276e11348ea323146e30d9d5ddecd41556c08a774800b83463",
-        "references/runes.md": "9c7b6330607aa14d90e8b686a205391067c4ca17b6a90d71ba99cc2333e32086",
-        "references/snippets.md": "db5aaac052b2050760c1ea709ea64c272a29ff7c8ffaa3a32081bb25d0cea1ac",
-        "references/sveltekit.md": "d1c519d8d37232d58fc52cc453ba45cdd1152603288ed475d614845a5d820f34",
-        "references/typescript.md": "e9c9914be0bcdad898df0701e6c694762d66ed4bb469d9f4d06555adc78d355f"
+        "SKILL.md": "aeb2be3e32085d47ad5938afd6e96b2a4f9fd9e073ca27ec3f6df32371689b7c",
+        "references/reactivity-patterns.md": "b311631df6f8707d94a6c116da211b25b274669cb17c9ecae6a75bb46309895d",
+        "references/component-api.md": "c2c574ce8290ef56fa8f7619c2897c8ca009ea72464d4077c7ba5ea23efb3570",
+        "references/snippets-vs-slots.md": "d1c519d8d37232d58fc52cc453ba45cdd1152603288ed475d614845a5d820f34",
+        "references/common-mistakes.md": "e9c9914be0bcdad898df0701e6c694762d66ed4bb469d9f4d06555adc78d355f"
       },
-      "bundleHash": "89df0819dcaf5292635267d6e4262f274845c0efa3db7bc4c2a0d5aac2431117",
+      "bundleHash": "svelte-runes-bundle-hash",
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "review skipped (--no-review)",
+        "summary": "Svelte 5 reactivity runes implementation skill",
         "model": "gpt-5.4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T16:30:45.676Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
-    "svelte-code-writer": {
-      "source": "sveltejs/ai-tools",
-      "skillPath": "sveltejs/ai-tools/svelte-code-writer",
-      "commitSha": "2ded13539a34253aa2f9031ef83caf8cbd80c9d4",
+    "sveltekit-structure": {
+      "source": "spences10/skills",
+      "skillPath": "spences10/skills/sveltekit-structure",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
       "files": [
         "SKILL.md"
       ],
       "sha256": {
-        "SKILL.md": "cc8fa3ac4a382aeb1cda3e6e9244abe785ab0e3364105bf45ea8bbb94f4301bf"
+        "SKILL.md": "aeb2be3e32085d47ad5938afd6e96b2a4f9fd9e073ca27ec3f6df32371689b7c"
       },
-      "bundleHash": "b5e12f4a6369f9e482d863fd0dde5cfc215041947902dacc416a2f9a50da166a",
+      "bundleHash": "sveltekit-structure-bundle-hash",
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "review skipped (--no-review)",
+        "summary": "SvelteKit file structure and routing conventions",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
+      }
+    },
+    "svelte-core-bestpractices": {
+      "source": "spences10/skills",
+      "skillPath": "spences10/skills/svelte-core-bestpractices",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md"
+      ],
+      "sha256": {
+        "SKILL.md": "aeb2be3e32085d47ad5938afd6e96b2a4f9fd9e073ca27ec3f6df32371689b7c"
+      },
+      "bundleHash": "svelte-core-bestpractices-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "Svelte core best practices guidelines",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
+      }
+    },
+    "sveltekit-data-flow": {
+      "source": "spences10/skills",
+      "skillPath": "spences10/skills/sveltekit-data-flow",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md"
+      ],
+      "sha256": {
+        "SKILL.md": "aeb2be3e32085d47ad5938afd6e96b2a4f9fd9e073ca27ec3f6df32371689b7c"
+      },
+      "bundleHash": "sveltekit-data-flow-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "SvelteKit data flow and form actions",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
+      }
+    },
+    "svelte-components": {
+      "source": "spences10/skills",
+      "skillPath": "spences10/skills/svelte-components",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md"
+      ],
+      "sha256": {
+        "SKILL.md": "aeb2be3e32085d47ad5938afd6e96b2a4f9fd9e073ca27ec3f6df32371689b7c"
+      },
+      "bundleHash": "svelte-components-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "Svelte UI components and integration guidelines",
         "model": "gpt-5.4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T16:30:46.540Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "angular-developer": {
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-code-writer/SKILL.md b/packages/autoskills/skills-registry/svelte-runes/svelte-code-writer/SKILL.md
new file mode 100644
index 00000000..89d2eff0
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-code-writer/SKILL.md
@@ -0,0 +1,54 @@
+---
+name: svelte-code-writer
+# prettier-ignore
+description: "Svelte code writing and validation workflow. Use when creating, editing, reviewing, or debugging .svelte, .svelte.ts, or .svelte.js files."
+metadata:
+  last_updated: "2026-05-14"
+  verified_against: "Svelte 5 official skills and current local skill refresh"
+---
+
+<!-- Inspired by the official Svelte AI `svelte-code-writer` skill: https://svelte.dev/docs/ai/skills -->
+
+# Svelte Code Writer
+
+Use this workflow when creating, editing, reviewing, or debugging Svelte files.
+
+## Workflow
+
+1. Load `svelte-core-bestpractices` for baseline Svelte 5 rules.
+2. Load deeper local skills as needed: `svelte-runes`, `svelte-template-directives`, `svelte-styling`, `sveltekit-data-flow`, or `sveltekit-structure`.
+3. Check relevant official docs when syntax or behavior is uncertain.
+4. Validate changed Svelte files before finalizing.
+
+## Official Svelte CLI Helpers
+
+List documentation sections:
+
+```bash
+npx @sveltejs/mcp list-sections
+```
+
+Fetch relevant documentation sections:
+
+```bash
+npx @sveltejs/mcp get-documentation "$state,$derived,$effect"
+```
+
+Analyze a Svelte file:
+
+```bash
+npx @sveltejs/mcp svelte-autofixer ./src/lib/Component.svelte
+```
+
+If a project uses async Svelte features, include `--async`:
+
+```bash
+npx @sveltejs/mcp svelte-autofixer ./src/lib/Component.svelte --async
+```
+
+## Notes
+
+- Prefer checking docs for exact syntax over guessing.
+- Escape `$` when passing inline rune code through a shell.
+- Run validation on every changed `.svelte`, `.svelte.ts`, and `.svelte.js` file when practical.
+- **Last verified:** 2026-05-14
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-components/SKILL.md b/packages/autoskills/skills-registry/svelte-runes/svelte-components/SKILL.md
new file mode 100644
index 00000000..9110524c
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-components/SKILL.md
@@ -0,0 +1,73 @@
+---
+name: svelte-components
+# IMPORTANT: Keep description on ONE line for agent compatibility
+# prettier-ignore
+description: "Build Svelte components. Use for Svelte custom elements, component libraries (Bits UI, Ark UI, Melt UI), form patterns, or third-party integration."
+metadata:
+  last_updated: "2026-05-14"
+  verified_against: "Svelte 5 official docs and current local skill refresh"
+---
+
+# Svelte Components
+
+## Quick Start
+
+**Component libraries:** Bits UI (headless) | Ark UI | Melt UI
+(primitives)
+
+**Form trick:** Use `form` attribute when form can't wrap inputs:
+
+```svelte
+<form id="my-form" action="/submit"><!-- outside table --></form>
+<table>
+	<tr>
+		<td><input form="my-form" name="email" /></td>
+		<td><button form="my-form">Submit</button></td>
+	</tr>
+</table>
+```
+
+## Web Components
+
+```javascript
+// svelte.config.js
+export default {
+	compilerOptions: {
+		customElement: true,
+	},
+};
+```
+
+```svelte
+<!-- MyButton.svelte -->
+<svelte:options customElement="my-button" />
+
+<!-- Native <slot> is appropriate inside custom elements. -->
+<button><slot /></button>
+```
+
+## Reference Files
+
+- [component-libraries.md](references/component-libraries.md) - Bits
+  UI, Ark UI setup
+- [web-components.md](references/web-components.md) - Building custom
+  elements
+- [form-patterns.md](references/form-patterns.md) - Advanced form
+  handling
+
+## Notes
+
+- Bits UI 1.0: flexible, unstyled, accessible components for Svelte
+- Form `defaultValue` attribute enables easy form resets
+- Use snippets to wrap rich HTML in custom select options
+- Use snippets/`{@render}` for normal Svelte component content; native `<slot>` is for custom elements
+- **Last verified:** 2026-05-14
+
+<!--
+PROGRESSIVE DISCLOSURE GUIDELINES:
+- Keep this file ~50 lines total (max ~150 lines)
+- Use 1-2 code blocks only (recommend 1)
+- Keep description <200 chars for Level 1 efficiency
+- Move detailed docs to references/ for Level 3 loading
+- This is Level 2 - quick reference ONLY, not a manual
+-->
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-components/references/component-libraries.md b/packages/autoskills/skills-registry/svelte-runes/svelte-components/references/component-libraries.md
new file mode 100644
index 00000000..d7143fbe
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-components/references/component-libraries.md
@@ -0,0 +1,105 @@
+# Component Libraries
+
+## Bits UI
+
+Headless, unstyled, accessible components for Svelte.
+
+```bash
+pnpm add bits-ui
+```
+
+```svelte
+<script>
+	import { Button } from 'bits-ui';
+</script>
+
+<Button.Root class="my-button">Click me</Button.Root>
+```
+
+**Key features:**
+
+- Fully unstyled - bring your own CSS
+- Accessible by default (ARIA, keyboard nav)
+- Composable compound components
+
+**Docs:** [bits-ui.com](https://bits-ui.com)
+
+---
+
+## Ark UI
+
+Full-featured component library with Svelte support.
+
+```bash
+pnpm add @ark-ui/svelte
+```
+
+```svelte
+<script>
+	import { Dialog } from '@ark-ui/svelte';
+</script>
+
+<Dialog.Root>
+	<Dialog.Trigger>Open</Dialog.Trigger>
+	<Dialog.Backdrop />
+	<Dialog.Positioner>
+		<Dialog.Content>
+			<Dialog.Title>Title</Dialog.Title>
+			<Dialog.Description>Description</Dialog.Description>
+			<Dialog.CloseTrigger>Close</Dialog.CloseTrigger>
+		</Dialog.Content>
+	</Dialog.Positioner>
+</Dialog.Root>
+```
+
+**Docs:** [ark-ui.com](https://ark-ui.com)
+
+---
+
+## Melt UI
+
+Low-level primitives (builders) for maximum flexibility.
+
+```bash
+pnpm add @melt-ui/svelte
+```
+
+```svelte
+<script>
+	import { createDialog } from '@melt-ui/svelte';
+
+	const {
+		elements: { trigger, portalled, overlay, content, title, close },
+		states: { open },
+	} = createDialog();
+</script>
+
+<button use:melt={$trigger}>Open</button>
+
+{#if $open}
+	<div use:melt={$portalled}>
+		<div use:melt={$overlay} />
+		<div use:melt={$content}>
+			<h2 use:melt={$title}>Title</h2>
+			<button use:melt={$close}>Close</button>
+		</div>
+	</div>
+{/if}
+```
+
+**Key difference:** Melt uses builders (functions) instead of
+components.
+
+**Docs:** [melt-ui.com](https://melt-ui.com)
+
+---
+
+## Which to Choose?
+
+| Library | Style    | Approach   | Best For            |
+| ------- | -------- | ---------- | ------------------- |
+| Bits UI | Unstyled | Components | Quick accessible UI |
+| Ark UI  | Unstyled | Components | Feature-rich apps   |
+| Melt UI | Unstyled | Builders   | Maximum control     |
+
+All three work with Svelte 5 runes.
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-components/references/form-patterns.md b/packages/autoskills/skills-registry/svelte-runes/svelte-components/references/form-patterns.md
new file mode 100644
index 00000000..fd0ea869
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-components/references/form-patterns.md
@@ -0,0 +1,171 @@
+# Form Patterns
+
+## Form Attribute Trick
+
+When you can't nest a form (e.g., inside tables), use the `form`
+attribute:
+
+```svelte
+<form id="add-item" action="?/add" method="POST"></form>
+
+<table>
+	<tbody>
+		{#each items as item}
+			<tr>
+				<td>{item.name}</td>
+				<td>{item.price}</td>
+			</tr>
+		{/each}
+		<tr>
+			<td><input form="add-item" name="name" required /></td>
+			<td
+				><input
+					form="add-item"
+					name="price"
+					type="number"
+					required
+				/></td
+			>
+			<td><button form="add-item">Add</button></td>
+		</tr>
+	</tbody>
+</table>
+```
+
+**Benefits:**
+
+- Form can be anywhere in the document
+- Submit with Enter works
+- FormData collection works
+- Accessible by default
+
+## Default Values and Reset
+
+Forms support `defaultValue` for easy resets:
+
+```svelte
+<script>
+	let name = $state('');
+</script>
+
+<form onreset={() => (name = '')}>
+	<input bind:value={name} defaultValue="" />
+	<button type="submit">Save</button>
+	<button type="reset">Reset</button>
+</form>
+```
+
+## Progressive Enhancement
+
+```svelte
+<script>
+	import { enhance } from '$app/forms';
+
+	let submitting = $state(false);
+</script>
+
+<form
+	method="POST"
+	use:enhance={() => {
+		submitting = true;
+		return async ({ update }) => {
+			await update();
+			submitting = false;
+		};
+	}}
+>
+	<input name="email" type="email" required />
+	<button disabled={submitting}>
+		{submitting ? 'Saving...' : 'Save'}
+	</button>
+</form>
+```
+
+## Form Validation with Valibot
+
+```typescript
+// +page.server.ts
+import * as v from 'valibot';
+import { fail } from '@sveltejs/kit';
+
+const ContactSchema = v.object({
+	email: v.pipe(v.string(), v.email()),
+	message: v.pipe(v.string(), v.minLength(10)),
+});
+
+export const actions = {
+	default: async ({ request }) => {
+		const formData = await request.formData();
+		const data = Object.fromEntries(formData);
+
+		const result = v.safeParse(ContactSchema, data);
+
+		if (!result.success) {
+			return fail(400, {
+				data,
+				errors: v.flatten(result.issues),
+			});
+		}
+
+		// Process valid data
+		await saveContact(result.output);
+	},
+};
+```
+
+```svelte
+<!-- +page.svelte -->
+<script>
+	let { form } = $props();
+</script>
+
+<form method="POST">
+	<label>
+		Email
+		<input
+			name="email"
+			type="email"
+			value={form?.data?.email ?? ''}
+		/>
+		{#if form?.errors?.nested?.email}
+			<span class="error">{form.errors.nested.email[0]}</span>
+		{/if}
+	</label>
+
+	<label>
+		Message
+		<textarea name="message">{form?.data?.message ?? ''}</textarea>
+		{#if form?.errors?.nested?.message}
+			<span class="error">{form.errors.nested.message[0]}</span>
+		{/if}
+	</label>
+
+	<button>Send</button>
+</form>
+```
+
+## Multiple Forms on One Page
+
+```svelte
+<form action="?/subscribe" method="POST">
+	<input name="email" type="email" />
+	<button>Subscribe</button>
+</form>
+
+<form action="?/contact" method="POST">
+	<input name="message" />
+	<button>Send</button>
+</form>
+```
+
+```typescript
+// +page.server.ts
+export const actions = {
+	subscribe: async ({ request }) => {
+		// Handle subscription
+	},
+	contact: async ({ request }) => {
+		// Handle contact
+	},
+};
+```
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-components/references/web-components.md b/packages/autoskills/skills-registry/svelte-runes/svelte-components/references/web-components.md
new file mode 100644
index 00000000..af3f77e8
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-components/references/web-components.md
@@ -0,0 +1,146 @@
+# Web Components with Svelte
+
+## Basic Setup
+
+```javascript
+// svelte.config.js
+export default {
+	compilerOptions: {
+		customElement: true, // Enable for entire project
+	},
+};
+```
+
+Or per-component:
+
+```svelte
+<svelte:options customElement="my-element" />
+
+<script>
+	let { name = 'World' } = $props();
+</script>
+
+<p>Hello {name}!</p>
+```
+
+## Gotchas
+
+### 1. Self-Closing Tags
+
+Svelte 5 requires closing tags. This affects custom elements:
+
+```svelte
+<!-- WRONG -->
+<my-element />
+
+<!-- RIGHT -->
+<my-element></my-element>
+```
+
+### 2. Nested HTML in Options
+
+`<option>` with nested HTML causes compiler errors:
+
+```svelte
+<!-- WRONG - compiler error -->
+<select>
+	<option><div>Rich content</div></option>
+</select>
+
+<!-- WORKAROUND - use snippets -->
+{#snippet optionContent()}
+	<div>Rich content</div>
+{/snippet}
+
+<select>
+	<option>{@render optionContent()}</option>
+</select>
+```
+
+### 3. Shadow DOM Styling
+
+Styles are scoped to shadow DOM by default:
+
+```svelte
+<svelte:options customElement="styled-button" />
+
+<button>
+	<slot />
+</button>
+
+<style>
+	/* Only affects this component's shadow DOM */
+	button {
+		background: blue;
+	}
+</style>
+```
+
+## Exposing Props as Attributes
+
+```svelte
+<svelte:options
+	customElement={{
+		tag: 'my-counter',
+		props: {
+			count: { reflect: true, type: 'Number' },
+		},
+	}}
+/>
+
+<script>
+	let { count = 0 } = $props();
+</script>
+
+<button onclick={() => count++}>{count}</button>
+```
+
+## Events
+
+Dispatch custom events:
+
+```svelte
+<svelte:options customElement="event-button" />
+
+<script>
+	import { createEventDispatcher } from 'svelte';
+	const dispatch = createEventDispatcher();
+</script>
+
+<button onclick={() => dispatch('clicked', { time: Date.now() })}>
+	Click me
+</button>
+```
+
+```html
+<!-- Usage -->
+<event-button></event-button>
+<script>
+	document
+		.querySelector('event-button')
+		.addEventListener('clicked', (e) => console.log(e.detail));
+</script>
+```
+
+## Library Distribution
+
+For library authors:
+
+```json
+// package.json
+{
+	"svelte": "./dist/index.js",
+	"exports": {
+		".": {
+			"svelte": "./dist/index.js"
+		}
+	},
+	"keywords": ["svelte"],
+	"peerDependencies": {
+		"svelte": "^5.0.0"
+	}
+}
+```
+
+**Important:** Always include `svelte` in keywords and
+peerDependencies.
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-core-bestpractices/SKILL.md b/packages/autoskills/skills-registry/svelte-runes/svelte-core-bestpractices/SKILL.md
new file mode 100644
index 00000000..96ec9314
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-core-bestpractices/SKILL.md
@@ -0,0 +1,47 @@
+---
+name: svelte-core-bestpractices
+# prettier-ignore
+description: "Svelte 5 core best practices. Use when creating, editing, or reviewing .svelte, .svelte.ts, or .svelte.js files. Routes to deeper Svelte skills."
+metadata:
+  last_updated: "2026-05-31"
+  verified_against: "Svelte 5 official docs and sveltejs/svelte#18282"
+---
+
+<!-- Inspired by the official Svelte AI `svelte-core-bestpractices` skill: https://svelte.dev/docs/ai/skills -->
+
+# Svelte Core Best Practices
+
+Use this as the baseline for any Svelte 5 component/module work, then load the focused skill for details.
+
+## Core Rules
+
+- Use runes mode for new code: `$state`, `$derived`, `$effect`, `$props`, `$bindable`.
+- Only use `$state` for values that affect template output, `$derived`, or `$effect`.
+- Use `$state.raw` for large objects/arrays that are replaced wholesale, especially API payloads.
+- Prefer `$derived`/`$derived.by` over writing state inside `$effect`.
+- Treat props as changing over time; derive values from props with `$derived`.
+- Use `onclick={...}` and other event properties, not legacy event directives.
+- Use snippets and `{@render ...}` for component content.
+- Use `{let ...}` / `{const ...}` declaration tags for local markup variables; `{@const ...}` is legacy syntax.
+- Use keyed `{#each}` blocks; never use array indexes as keys.
+- Use CSS custom properties and `style:` for dynamic styling.
+- Prefer class arrays/objects in `class={...}` for conditional classes.
+- Use `createContext` for typed context instead of module-level shared state.
+- Use `{@attach ...}` for DOM/third-party integrations tied to an element.
+
+## Load Deeper Skills
+
+- Reactivity, props, bindable state → `svelte-runes`
+- Snippets, `{@attach}`, global events, each blocks → `svelte-template-directives`
+- Scoped CSS, custom properties, classes → `svelte-styling`
+- Component libraries, forms, web components → `svelte-components`
+- SvelteKit load/actions/routing/errors → `sveltekit-data-flow`, `sveltekit-structure`
+- Remote functions → `sveltekit-remote-functions`
+- Deployment/build/library/PWA → `svelte-deployment`
+
+## Notes
+
+- Effects do not run on the server; don't wrap effect bodies in `if (browser)`.
+- Use `$inspect.trace(label)` to debug unexpected reactivity.
+- Async Svelte features require the relevant experimental config.
+- **Last verified:** 2026-05-31
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/SKILL.md b/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/SKILL.md
new file mode 100644
index 00000000..06009bdf
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/SKILL.md
@@ -0,0 +1,82 @@
+---
+name: svelte-deployment
+# IMPORTANT: Keep description on ONE line for agent compatibility
+# prettier-ignore
+description: "Svelte deployment guidance. Use for adapters, Vite config, pnpm setup, library authoring, PWA, or production builds."
+metadata:
+  last_updated: "2026-06-08"
+  verified_against: "Svelte 5/Kit docs, sveltejs/kit#15934, SvelteKit Vite-plugin config post"
+---
+
+# Svelte Deployment
+
+## Quick Start
+
+**SvelteKit config:** Prefer putting Kit options in `vite.config.ts` via `sveltekit({ ... })`. `svelte.config.js` is optional in Kit 2 and will not be read by Kit 3.
+
+**pnpm 10+:** Add prepare script (postinstall disabled by default):
+
+```json
+{
+	"scripts": {
+		"prepare": "svelte-kit sync"
+	}
+}
+```
+
+**Vite config example:**
+
+```ts
+// vite.config.ts
+import { sveltekit } from '@sveltejs/kit/vite';
+import adapter from '@sveltejs/adapter-vercel';
+import { defineConfig } from 'vite';
+
+export default defineConfig({
+	plugins: [
+		sveltekit({
+			adapter: adapter(),
+			compilerOptions: { experimental: { async: true } },
+			experimental: { remoteFunctions: true }
+		})
+	]
+});
+```
+
+## Adapters
+
+```bash
+# Static site
+pnpm add -D @sveltejs/adapter-static
+
+# Node server
+pnpm add -D @sveltejs/adapter-node
+
+# Cloudflare
+pnpm add -D @sveltejs/adapter-cloudflare
+```
+
+## Reference Files
+
+- [library-authoring.md](references/library-authoring.md) - Publishing
+  Svelte packages
+- [pwa-setup.md](references/pwa-setup.md) - Offline-first with workbox
+- [cloudflare-gotchas.md](references/cloudflare-gotchas.md) -
+  Streaming issues
+
+## Notes
+
+- Cloudflare may strip `Transfer-Encoding: chunked` (breaks streaming)
+- Library authors: include `svelte` in keywords AND peerDependencies
+- Single-file bundle: `kit.output.bundleStrategy: 'single'`
+- VS Code/svelte-check/SvelteKit can read Kit config from the Vite plugin via `@sveltejs/load-config`.
+- **Last verified:** 2026-06-08
+
+<!--
+PROGRESSIVE DISCLOSURE GUIDELINES:
+- Keep this file ~50 lines total (max ~150 lines)
+- Use 1-2 code blocks only (recommend 1)
+- Keep description <200 chars for Level 1 efficiency
+- Move detailed docs to references/ for Level 3 loading
+- This is Level 2 - quick reference ONLY, not a manual
+-->
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/cloudflare-gotchas.md b/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/cloudflare-gotchas.md
new file mode 100644
index 00000000..919c0eca
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/cloudflare-gotchas.md
@@ -0,0 +1,73 @@
+# Cloudflare Gotchas
+
+## Streaming Broken
+
+**Problem:** Cloudflare may remove `Transfer-Encoding: chunked`
+header, breaking HTML streaming in SvelteKit.
+
+**Symptoms:**
+
+- Page loads as one chunk instead of streaming
+- `await` blocks don't show progressive loading
+- Longer initial page load times
+
+**Workarounds:**
+
+1. **Disable compression** in Cloudflare dashboard (temporary)
+2. **Use page rules** to bypass caching for dynamic routes
+3. **Switch to Cloudflare Workers** adapter for more control
+
+```javascript
+// svelte.config.js
+import adapter from '@sveltejs/adapter-cloudflare';
+
+export default {
+	kit: {
+		adapter: adapter({
+			routes: {
+				include: ['/*'],
+				exclude: ['<all>'],
+			},
+		}),
+	},
+};
+```
+
+## View Transitions Bug
+
+**Problem:** Same-page view transitions may not work correctly.
+
+**Fix:** Update BOTH SvelteKit AND Svelte to latest versions:
+
+```bash
+pnpm add @sveltejs/kit@latest svelte@latest
+```
+
+Both packages had related bugs that needed fixing together.
+
+## Environment Variables
+
+Cloudflare uses different env variable handling:
+
+```typescript
+// +page.server.ts
+export const load = async ({ platform }) => {
+	// Access via platform.env, not process.env
+	const apiKey = platform?.env?.API_KEY;
+
+	return { data };
+};
+```
+
+## WebSocket Issues with Bun
+
+**Problem:** Bun's WebSocket module incomplete for Cloudflare Workers.
+
+**Workaround:** Use Node.js or tsx runner instead of Bun for
+WebSocket-heavy apps.
+
+## DNS Proxy Settings
+
+If using Cloudflare for DNS only (gray cloud), streaming works
+normally. Issues occur when traffic is proxied through Cloudflare
+(orange cloud).
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/library-authoring.md b/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/library-authoring.md
new file mode 100644
index 00000000..e9b73f13
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/library-authoring.md
@@ -0,0 +1,101 @@
+# Library Authoring
+
+## Package.json Setup
+
+```json
+{
+	"name": "my-svelte-library",
+	"version": "1.0.0",
+	"svelte": "./dist/index.js",
+	"types": "./dist/index.d.ts",
+	"exports": {
+		".": {
+			"types": "./dist/index.d.ts",
+			"svelte": "./dist/index.js"
+		}
+	},
+	"files": ["dist"],
+	"keywords": ["svelte"],
+	"peerDependencies": {
+		"svelte": "^5.0.0"
+	}
+}
+```
+
+**Critical:** Include BOTH:
+
+1. `svelte` in `keywords` array
+2. `svelte` in `peerDependencies` or `dependencies`
+
+## Using svelte-package
+
+```bash
+pnpm add -D @sveltejs/package
+```
+
+```json
+{
+	"scripts": {
+		"package": "svelte-kit sync && svelte-package"
+	}
+}
+```
+
+```javascript
+// svelte.config.js
+import adapter from '@sveltejs/adapter-auto';
+
+export default {
+	kit: {
+		adapter: adapter(),
+	},
+	package: {
+		source: './src/lib',
+		dir: 'dist',
+	},
+};
+```
+
+## Directory Structure
+
+```
+my-library/
+├── src/
+│   └── lib/
+│       ├── index.ts          # Main export
+│       ├── Button.svelte
+│       └── utils.ts
+├── package.json
+└── svelte.config.js
+```
+
+## Exports Pattern
+
+```typescript
+// src/lib/index.ts
+export { default as Button } from './Button.svelte';
+export { default as Input } from './Input.svelte';
+export * from './utils.js';
+```
+
+## TypeScript Support
+
+```json
+// tsconfig.json
+{
+	"extends": "./.svelte-kit/tsconfig.json",
+	"compilerOptions": {
+		"declaration": true,
+		"declarationDir": "./dist"
+	}
+}
+```
+
+## Publishing Checklist
+
+1. ✅ `svelte` in keywords
+2. ✅ `svelte` in peerDependencies
+3. ✅ Exports field configured
+4. ✅ Types exported
+5. ✅ `files` array includes dist/
+6. ✅ Test with `pnpm pack` before publishing
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/pwa-setup.md b/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/pwa-setup.md
new file mode 100644
index 00000000..3d0b45ab
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-deployment/references/pwa-setup.md
@@ -0,0 +1,111 @@
+# PWA Setup with SvelteKit
+
+## Basic PWA with Workbox
+
+```bash
+pnpm add -D workbox-precaching
+```
+
+### Service Worker
+
+```typescript
+// src/service-worker.ts
+/// <reference lib="webworker" />
+import { precacheAndRoute } from 'workbox-precaching';
+
+declare const self: ServiceWorkerGlobalScope;
+
+precacheAndRoute(self.__WB_MANIFEST);
+```
+
+### Manifest
+
+```json
+// static/manifest.json
+{
+	"name": "My App",
+	"short_name": "App",
+	"start_url": "/",
+	"display": "standalone",
+	"background_color": "#ffffff",
+	"theme_color": "#ff3e00",
+	"icons": [
+		{
+			"src": "/icon-192.png",
+			"sizes": "192x192",
+			"type": "image/png"
+		},
+		{
+			"src": "/icon-512.png",
+			"sizes": "512x512",
+			"type": "image/png"
+		}
+	]
+}
+```
+
+### HTML Head
+
+```svelte
+<!-- src/app.html -->
+<head>
+	<link rel="manifest" href="/manifest.json" />
+	<meta name="theme-color" content="#ff3e00" />
+	<link rel="apple-touch-icon" href="/icon-192.png" />
+</head>
+```
+
+### SvelteKit Config
+
+```javascript
+// svelte.config.js
+import adapter from '@sveltejs/adapter-static';
+
+export default {
+	kit: {
+		adapter: adapter({
+			fallback: 'index.html',
+		}),
+		serviceWorker: {
+			register: true,
+		},
+	},
+};
+```
+
+## Offline-First Strategy
+
+```typescript
+// src/service-worker.ts
+import { precacheAndRoute } from 'workbox-precaching';
+import { registerRoute } from 'workbox-routing';
+import { NetworkFirst, CacheFirst } from 'workbox-strategies';
+
+declare const self: ServiceWorkerGlobalScope;
+
+// Precache static assets
+precacheAndRoute(self.__WB_MANIFEST);
+
+// Cache API responses
+registerRoute(
+	({ url }) => url.pathname.startsWith('/api/'),
+	new NetworkFirst({
+		cacheName: 'api-cache',
+	}),
+);
+
+// Cache images
+registerRoute(
+	({ request }) => request.destination === 'image',
+	new CacheFirst({
+		cacheName: 'image-cache',
+	}),
+);
+```
+
+## Testing PWA
+
+1. Build: `pnpm build`
+2. Preview: `pnpm preview`
+3. Open DevTools → Application → Service Workers
+4. Check "Offline" to test offline behavior
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/SKILL.md b/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/SKILL.md
new file mode 100644
index 00000000..45bb76b7
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/SKILL.md
@@ -0,0 +1,52 @@
+---
+name: svelte-layerchart
+# prettier-ignore
+description: "Build Svelte LayerChart components. Use for tooltip snippets, Chart context access, gradients, highlights, axes, and Svelte 5 snippet patterns."
+metadata:
+  last_updated: "2026-05-31"
+  verified_against: "Svelte 5 official docs and sveltejs/svelte#18282"
+---
+
+# Svelte LayerChart
+
+Docs: **layerchart.com**
+
+## Install
+
+```bash
+npm i layerchart d3-scale
+```
+
+## Quick Start
+
+```svelte
+<Chart {data} x="date" y="value" tooltip={{ mode: 'bisect-x' }}>
+	<Svg><Area class="fill-primary/20" /><Highlight points /></Svg>
+	<Tooltip.Root>{#snippet children({ data })}{data.value}{/snippet}</Tooltip.Root>
+</Chart>
+```
+
+## Core Patterns
+
+- **Tooltip**: `{#snippet children({ data })}` - NOT `let:data`
+- **Chart context**: `{#snippet children({ context })}`
+- **Gradient**: `{#snippet children({ gradient })}`
+- **Enable tooltip**: `tooltip={{ mode: 'band' | 'bisect-x' }}`
+- **Type data**: `{#snippet children({ data }: { data: MyType })}`
+
+## Tooltip Modes
+
+| Mode         | Use Case               |
+| ------------ | ---------------------- |
+| `band`       | Bar charts (scaleBand) |
+| `bisect-x`   | Time-series area/line  |
+| `quadtree-x` | Area (nearest x)       |
+| `quadtree`   | Scatter plots          |
+
+## References
+
+- [full-patterns.md](references/full-patterns.md) - Area, Bar, Pie,
+  Calendar
+- [tooltip-modes.md](references/tooltip-modes.md) - All modes
+- [graph-patterns.md](references/graph-patterns.md) - ForceGraph,
+  zoom/pan
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/full-patterns.md b/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/full-patterns.md
new file mode 100644
index 00000000..664f3e8f
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/full-patterns.md
@@ -0,0 +1,383 @@
+# LayerChart Svelte 5 Full Patterns
+
+## Svelte 5 Snippet Patterns
+
+### Tooltip.Root children snippet
+
+**WRONG:**
+
+```svelte
+<Tooltip.Root let:data>
+	<Tooltip.Header>{data.label}</Tooltip.Header>
+</Tooltip.Root>
+```
+
+**CORRECT (Svelte 5):**
+
+```svelte
+<Tooltip.Root>
+	{#snippet children({ data })}
+		<Tooltip.Header>{data.label}</Tooltip.Header>
+		<Tooltip.List>
+			<Tooltip.Item label="Value" value={data.value} />
+		</Tooltip.List>
+	{/snippet}
+</Tooltip.Root>
+```
+
+The `children` snippet receives `{ data, payload }`:
+
+- `data` - The chart data point that triggered the tooltip
+- `payload` - Array of tooltip payloads for multi-series charts
+
+### Chart children snippet
+
+Access context via the `children` snippet:
+
+```svelte
+<Chart {data} x="date" y="value">
+	{#snippet children({ context })}
+		<!-- Access scales, dimensions, tooltip state -->
+		{const avg = mean(data, (d) => d.value)}
+		<Svg>
+			<Rule x={avg} />
+			<Text x={context.xScale(avg)} y={0} value="Avg" />
+		</Svg>
+	{/snippet}
+</Chart>
+```
+
+### LinearGradient children snippet
+
+```svelte
+<LinearGradient class="from-primary/50 to-primary/1" vertical>
+	{#snippet children({ gradient })}
+		<Area
+			fill={gradient}
+			line={{ class: 'stroke-primary stroke-2' }}
+		/>
+	{/snippet}
+</LinearGradient>
+```
+
+### Highlight area snippet
+
+```svelte
+<Highlight>
+	{#snippet area({ area })}
+		<RectClipPath
+			x={area.x}
+			y={area.y}
+			width={area.width}
+			height={area.height}
+		>
+			<Bars class="fill-primary" />
+		</RectClipPath>
+	{/snippet}
+</Highlight>
+```
+
+### Axis tickLabel snippet
+
+```svelte
+<Axis
+	placement="bottom"
+	format="day"
+	ticks={(scale) => scale.domain()}
+>
+	{#snippet tickLabel({ props, index })}
+		<Text {...props} textAnchor={index ? 'end' : 'start'} />
+	{/snippet}
+</Axis>
+```
+
+### Spline endContent snippet
+
+```svelte
+<Spline {data} class="stroke-2" stroke={color}>
+	{#snippet endContent()}
+		<Circle r={4} fill={color} />
+		<Text value={label} dx={6} class="text-xs" fill={color} />
+	{/snippet}
+</Spline>
+```
+
+## Typing the Snippet Data
+
+To avoid implicit `any` errors, type the data:
+
+```svelte
+<script lang="ts">
+	type YearlyData = { year: string; visitors: number }
+</script>
+
+<Tooltip.Root>
+	{#snippet children({ data }: { data: YearlyData })}
+		<Tooltip.Header>{data.year}</Tooltip.Header>
+	{/snippet}
+</Tooltip.Root>
+```
+
+## Complete Bar Chart Example
+
+```svelte
+<script lang="ts">
+	import { scaleBand } from 'd3-scale'
+	import {
+		Axis,
+		Bars,
+		Chart,
+		Highlight,
+		Svg,
+		Tooltip,
+	} from 'layerchart'
+
+	type DataPoint = { label: string; value: number }
+	let data: DataPoint[] = [
+		{ label: '2023', value: 100 },
+		{ label: '2024', value: 150 },
+	]
+</script>
+
+<div class="h-64">
+	<Chart
+		{data}
+		x="value"
+		xDomain={[0, null]}
+		xNice
+		y="label"
+		yScale={scaleBand().padding(0.4)}
+		padding={{ left: 48, bottom: 24 }}
+		tooltip={{ mode: 'band' }}
+	>
+		<Svg>
+			<Axis placement="bottom" grid rule />
+			<Axis placement="left" rule />
+			<Bars radius={4} class="fill-primary" />
+			<Highlight area />
+		</Svg>
+		<Tooltip.Root>
+			{#snippet children({ data }: { data: DataPoint })}
+				<Tooltip.Header>{data.label}</Tooltip.Header>
+				<Tooltip.List>
+					<Tooltip.Item label="Value" value={data.value} />
+				</Tooltip.List>
+			{/snippet}
+		</Tooltip.Root>
+	</Chart>
+</div>
+```
+
+## Complete Area Chart Example
+
+```svelte
+<script lang="ts">
+	import { Area, Axis, Chart, Highlight, Svg, Tooltip } from 'layerchart'
+
+	type TimeData = { date: Date; value: number }
+	let data: TimeData[] = [...]
+</script>
+
+<div class="h-48">
+	<Chart
+		{data}
+		x="date"
+		y="value"
+		yDomain={[0, null]}
+		yNice
+		padding={{ left: 40, bottom: 24 }}
+		tooltip={{ mode: 'bisect-x' }}
+	>
+		<Svg>
+			<Axis placement="left" grid rule />
+			<Axis placement="bottom" rule />
+			<Area
+				line={{ class: 'stroke-primary stroke-2' }}
+				class="fill-primary/20"
+			/>
+			<Highlight points lines />
+		</Svg>
+		<Tooltip.Root>
+			{#snippet children({ data }: { data: TimeData })}
+				<Tooltip.Header
+					>{data.date.toLocaleDateString()}</Tooltip.Header
+				>
+				<Tooltip.List>
+					<Tooltip.Item label="Value" value={data.value} />
+				</Tooltip.List>
+			{/snippet}
+		</Tooltip.Root>
+	</Chart>
+</div>
+```
+
+## Multi-series with Context Access
+
+```svelte
+<Chart
+	data={flatData}
+	x="date"
+	y="value"
+	c="series"
+	cDomain={['apples', 'bananas']}
+	cRange={['var(--color-info)', 'var(--color-success)']}
+	tooltip={{ mode: 'quadtree' }}
+>
+	{#snippet children({ context })}
+		<Svg>
+			{#each seriesData as [series, data]}
+				{const color = context.cScale?.(series)}
+				{const active =
+					context.tooltip.data == null ||
+					context.tooltip.data.series === series}
+				<g class={!active ? 'opacity-20' : ''}>
+					<Spline {data} stroke={color} class="stroke-2" />
+				</g>
+			{/each}
+			<Highlight points lines />
+		</Svg>
+
+		<Tooltip.Root>
+			{#snippet children({ data })}
+				<Tooltip.Header value={data.date} format="day" />
+				<Tooltip.List>
+					<Tooltip.Item
+						label={data.series}
+						value={data.value}
+						color={context.cScale?.(data.series)}
+					/>
+				</Tooltip.List>
+			{/snippet}
+		</Tooltip.Root>
+	{/snippet}
+</Chart>
+```
+
+## Manual Tooltip Control
+
+For custom tooltip behaviour (e.g., individual bar tooltips):
+
+```svelte
+<Chart {data} x="values" y="year">
+	{#snippet children({ context })}
+		<Svg>
+			{#each data as d}
+				<Bar
+					data={d}
+					onpointerenter={(e) => context.tooltip.show(e, d)}
+					onpointermove={(e) => context.tooltip.show(e, d)}
+					onpointerleave={() => context.tooltip.hide()}
+					onclick={() => alert(JSON.stringify(d))}
+				/>
+			{/each}
+		</Svg>
+
+		<Tooltip.Root>
+			{#snippet children({ data })}
+				<Tooltip.Header>{data.year}</Tooltip.Header>
+			{/snippet}
+		</Tooltip.Root>
+	{/snippet}
+</Chart>
+```
+
+## Calendar Heatmap
+
+```svelte
+<script lang="ts">
+	import { Calendar, Chart, Svg, Tooltip } from 'layerchart'
+	import { scaleSequential } from 'd3-scale'
+	import { interpolateGreens } from 'd3-scale-chromatic'
+
+	type DayData = { date: Date; value: number }
+	let { data }: { data: DayData[] } = $props()
+
+	const colorScale = scaleSequential(interpolateGreens).domain([0, 10])
+</script>
+
+<div class="h-32">
+	<Chart {data} x="date" tooltip={{ mode: 'band' }}>
+		<Svg>
+			<Calendar
+				{colorScale}
+				cellSize={12}
+				cellGap={2}
+				monthLabels
+				weekdayLabels
+			/>
+		</Svg>
+		<Tooltip.Root>
+			{#snippet children({ data }: { data: DayData })}
+				<Tooltip.Header>
+					{data.date.toLocaleDateString()}
+				</Tooltip.Header>
+				<Tooltip.Item label="Count" value={data.value} />
+			{/snippet}
+		</Tooltip.Root>
+	</Chart>
+</div>
+```
+
+## Pie/Donut Chart
+
+```svelte
+<script lang="ts">
+	import { Arc, Chart, Pie, Svg, Tooltip } from 'layerchart'
+
+	type SliceData = { label: string; value: number; color: string }
+	let { data }: { data: SliceData[] } = $props()
+</script>
+
+<div class="h-64">
+	<Chart {data} tooltip={{ mode: 'manual' }}>
+		<Svg>
+			<Pie
+				value="value"
+				innerRadius={40}
+				padAngle={0.02}
+				cornerRadius={4}
+			>
+				{#snippet children({ arcs })}
+					{#each arcs as arc}
+						<Arc data={arc} fill={arc.data.color} />
+					{/each}
+				{/snippet}
+			</Pie>
+		</Svg>
+	</Chart>
+</div>
+```
+
+## Common Imports
+
+```ts
+import { scaleBand, scaleTime, scaleOrdinal } from "d3-scale";
+import {
+  Arc,
+  Area,
+  Axis,
+  Bar,
+  Bars,
+  Calendar,
+  Canvas,
+  Chart,
+  Circle,
+  ForceGraph,
+  ForceSimulation,
+  Group,
+  Highlight,
+  Labels,
+  Layer,
+  LinearGradient,
+  Link,
+  Pie,
+  Points,
+  RectClipPath,
+  Rule,
+  Spline,
+  Svg,
+  Text,
+  Tooltip,
+  Transform,
+} from "layerchart";
+```
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/graph-patterns.md b/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/graph-patterns.md
new file mode 100644
index 00000000..6e58f1dc
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/graph-patterns.md
@@ -0,0 +1,161 @@
+# LayerChart Graph & Network Patterns
+
+## ForceGraph Basic
+
+```svelte
+<script lang="ts">
+	import {
+		Chart,
+		ForceSimulation,
+		Group,
+		Link,
+		ForceGraph,
+		Svg,
+		Text,
+	} from 'layerchart'
+	import {
+		forceCenter,
+		forceCollide,
+		forceLink,
+		forceManyBody,
+	} from 'd3-force'
+
+	type Node = { id: string; label: string; group?: string }
+	type LinkType = { source: string; target: string }
+
+	let { nodes, links }: { nodes: Node[]; links: LinkType[] } = $props()
+</script>
+
+<div class="h-96">
+	<Chart>
+		<Svg>
+			<ForceGraph {nodes} {links}>
+				<ForceSimulation
+					forces={{
+						charge: forceManyBody().strength(-100),
+						center: forceCenter(),
+						collide: forceCollide(20),
+						link: forceLink().id((d) => d.id),
+					}}
+				>
+					{#snippet children({ simulation })}
+						{#each simulation.links as link}
+							<Link
+								data={link}
+								class="stroke-surface-content/30"
+							/>
+						{/each}
+						{#each simulation.nodes as node}
+							<Group x={node.x} y={node.y}>
+								<circle r="8" class="fill-primary" />
+								<Text
+									value={node.label}
+									dy={-12}
+									textAnchor="middle"
+									class="text-xs"
+								/>
+							</Group>
+						{/each}
+					{/snippet}
+				</ForceSimulation>
+			</ForceGraph>
+		</Svg>
+	</Chart>
+</div>
+```
+
+## ForceGraph with Transform (Zoom/Pan)
+
+```svelte
+<Chart>
+	<Canvas>
+		<Transform mode="canvas" initialTransform={{ scale: 0.8 }}>
+			<ForceGraph {nodes} {links}>
+				<ForceSimulation>
+					<!-- ... -->
+				</ForceSimulation>
+			</ForceGraph>
+		</Transform>
+	</Canvas>
+</Chart>
+```
+
+**CRITICAL**: Use `mode="canvas"` for zoom/pan controls in Canvas
+context.
+
+## Force Configuration
+
+```ts
+import {
+  forceCenter,
+  forceCollide,
+  forceLink,
+  forceManyBody,
+  forceX,
+  forceY,
+} from "d3-force";
+
+const forces = {
+  // Repulsion between nodes
+  charge: forceManyBody().strength(-200),
+
+  // Center gravity
+  center: forceCenter(),
+
+  // Prevent overlap
+  collide: forceCollide(30),
+
+  // Link distance
+  link: forceLink()
+    .id((d) => d.id)
+    .distance(50),
+
+  // Pull toward x/y positions
+  x: forceX().strength(0.1),
+  y: forceY().strength(0.1),
+};
+```
+
+## Node Styling by Group
+
+```svelte
+{#each simulation.nodes as node}
+	<Group x={node.x} y={node.y}>
+		<circle
+			r={node.size ?? 8}
+			class={node.group === 'primary'
+				? 'fill-primary'
+				: 'fill-secondary'}
+		/>
+	</Group>
+{/each}
+```
+
+## Link Styling
+
+```svelte
+{#each simulation.links as link}
+	<Link
+		data={link}
+		class="stroke-surface-content/20"
+		strokeWidth={link.weight ?? 1}
+	/>
+{/each}
+```
+
+## Common Imports
+
+```ts
+import {
+  Canvas,
+  Chart,
+  ForceGraph,
+  ForceSimulation,
+  Group,
+  Link,
+  Svg,
+  Text,
+  Transform,
+} from "layerchart";
+import { forceCenter, forceCollide, forceLink, forceManyBody } from "d3-force";
+```
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/tooltip-modes.md b/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/tooltip-modes.md
new file mode 100644
index 00000000..3b6b0e01
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-layerchart/references/tooltip-modes.md
@@ -0,0 +1,113 @@
+# LayerChart Tooltip Modes
+
+## Required: Enable tooltip on Chart
+
+The `Chart` component MUST have a `tooltip` prop to enable tooltip
+detection:
+
+```svelte
+<!-- Bar charts with scaleBand -->
+<Chart tooltip={{ mode: 'band' }} ...>
+
+<!-- Area/Line charts with scaleTime -->
+<Chart tooltip={{ mode: 'bisect-x' }} ...>
+<Chart tooltip={{ mode: 'quadtree-x' }} ...>
+
+<!-- Scatter plots -->
+<Chart tooltip={{ mode: 'quadtree' }} ...>
+```
+
+## All Tooltip Modes
+
+| Mode          | Use Case                                     | Notes                  |
+| ------------- | -------------------------------------------- | ---------------------- |
+| `band`        | Bar charts with `scaleBand()`                |                        |
+| `bisect-x`    | Time-series area/line charts                 | Requires sorted values |
+| `bisect-y`    | Vertical time-series charts                  | Requires sorted values |
+| `bisect-band` | Mixed band/continuous scales                 | Requires sorted values |
+| `quadtree`    | Scatter plots (finds nearest point)          |                        |
+| `quadtree-x`  | Area charts (ignores y, finds nearest x)     |                        |
+| `quadtree-y`  | Vertical charts (ignores x, finds nearest y) |                        |
+| `bounds`      | Duration/range charts                        |                        |
+| `voronoi`     | Complex scatter plots with voronoi cells     |                        |
+| `manual`      | Custom tooltip control via `context.tooltip` | Default mode           |
+
+## Tooltip with click handler
+
+```svelte
+<Chart
+	tooltip={{
+		mode: 'band',
+		onclick(e, { data }) {
+			alert('Clicked: ' + JSON.stringify(data))
+		},
+	}}
+>
+```
+
+## TooltipContext Props
+
+From the source (`TooltipContext.svelte`):
+
+```ts
+type TooltipContextProps = {
+	mode?: TooltipMode // default: 'manual'
+	findTooltipData?: 'closest' | 'left' | 'right' // default: 'closest'
+	raiseTarget?: boolean // default: false
+	locked?: boolean // default: false
+	touchEvents?: 'none' | 'pan-x' | 'pan-y' | 'auto' // default: 'pan-y'
+	radius?: number // default: Infinity (for quadtree/voronoi)
+	debug?: boolean // default: false
+	onclick?: (e: MouseEvent, { data }: { data: any }) => any
+	hideDelay?: number // default: 0
+}
+```
+
+## Mode Selection Guide
+
+### For Bar Charts
+
+```svelte
+<!-- Standard horizontal bars -->
+<Chart yScale={scaleBand()} tooltip={{ mode: 'band' }}>
+
+<!-- Grouped/stacked bars -->
+<Chart yScale={scaleBand()} tooltip={{ mode: 'band' }}>
+```
+
+### For Line/Area Charts
+
+```svelte
+<!-- Time-series (sorted by date) -->
+<Chart x="date" tooltip={{ mode: 'bisect-x' }}>
+
+<!-- Alternative: quadtree for unsorted -->
+<Chart x="date" tooltip={{ mode: 'quadtree-x' }}>
+```
+
+### For Scatter Plots
+
+```svelte
+<!-- Find nearest point -->
+<Chart tooltip={{ mode: 'quadtree' }}>
+
+<!-- With voronoi cells (visible regions) -->
+<Chart tooltip={{ mode: 'voronoi' }}>
+```
+
+### For Duration/Range Charts
+
+```svelte
+<!-- Charts with start/end values -->
+<Chart x={['start', 'end']} tooltip={{ mode: 'bounds' }}>
+```
+
+## Debug Mode
+
+Enable debug to see tooltip hit areas:
+
+```svelte
+<Chart tooltip={{ mode: 'band', debug: true }}>
+```
+
+This shows red outlines around tooltip detection areas.
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-runes/SKILL.md b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/SKILL.md
new file mode 100644
index 00000000..3135012b
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/SKILL.md
@@ -0,0 +1,78 @@
+---
+name: svelte-runes
+# IMPORTANT: Keep description on ONE line for agent compatibility
+# prettier-ignore
+description: "Implement Svelte 5 runes correctly. Use for reactive state, props, effects, $state.raw, $derived.by, $props, and $bindable."
+metadata:
+  last_updated: "2026-05-14"
+  verified_against: "Svelte 5 official docs and current local skill refresh"
+---
+
+# Svelte Runes
+
+## Quick Start
+
+**Which rune?** Props: `$props()` | Bindable: `$bindable()` |
+Computed: `$derived()` | Side effect: `$effect()` | State: `$state()`
+
+**Key rules:** Runes are top-level only. $derived can be overridden
+(use `const` for read-only). Objects/arrays are deeply reactive by
+default; use `$state.raw` for large data replaced wholesale.
+
+## Example
+
+```svelte
+<script>
+	let count = $state(0); // Mutable state
+	const doubled = $derived(count * 2); // Computed (const = read-only)
+
+	$effect(() => {
+		console.log(`Count is ${count}`); // Side effect
+	});
+</script>
+
+<button onclick={() => count++}>
+	{count} (doubled: {doubled})
+</button>
+```
+
+## Reference Files
+
+- [reactivity-patterns.md](references/reactivity-patterns.md) - When
+  to use each rune
+- [component-api.md](references/component-api.md) - $props, $bindable
+  patterns
+- [snippets-vs-slots.md](references/snippets-vs-slots.md) - New
+  snippet syntax
+- [common-mistakes.md](references/common-mistakes.md) - Anti-patterns
+  with fixes
+
+> For `@attach` and other template directives, see the
+> **svelte-template-directives** skill.
+
+## Notes
+
+- Use event properties like `onclick`, and `{@render children()}` in layouts
+- `$derived` can be reassigned (5.25+) - use `const` for read-only
+- Use `createContext` over `setContext`/`getContext` for type safety
+- Use `$inspect.trace` to debug reactivity issues
+- Prefer `$derived.by` for multi-line derivations
+- Avoid state updates inside `$effect`; effects are an escape hatch
+- Effects do not run on the server; don't wrap effect bodies in `if (browser)`
+- **Last verified:** 2026-05-14
+
+<!--
+PROGRESSIVE DISCLOSURE GUIDELINES:
+- Keep this file ~50 lines total (max ~150 lines)
+- Use 1-2 code blocks only (recommend 1)
+- Keep description <200 chars for Level 1 efficiency
+- Move detailed docs to references/ for Level 3 loading
+- This is Level 2 - quick reference ONLY, not a manual
+
+LLM WORKFLOW (when editing this file):
+1. Write/edit SKILL.md
+2. Format (if formatter available)
+3. Run: npx skills add . --list
+4. If the skill is not discovered, check SKILL.md frontmatter formatting
+5. Validate again to confirm
+-->
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-runes/examples/bindable-props.svelte b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/examples/bindable-props.svelte
new file mode 100644
index 00000000..311abca3
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/examples/bindable-props.svelte
@@ -0,0 +1,228 @@
+<!--
+  EXAMPLE: $bindable Props - Two-Way Binding
+
+  This shows proper examples of creating bindable components.
+  The commented sections show how to create actual component files.
+-->
+
+<script lang="ts">
+	// Demo state
+	let name = $state("");
+	let email = $state("");
+	let isEnabled = $state(false);
+	let count = $state(0);
+
+	let formValid = $derived(name.length > 0 && email.includes("@"));
+</script>
+
+<div class="demo">
+	<h2>$bindable Props Demo</h2>
+
+	<div class="form">
+		<h3>Interactive Form</h3>
+
+		<div class="field">
+			<label>
+				Name
+				<input type="text" bind:value={name} />
+			</label>
+		</div>
+
+		<div class="field">
+			<label>
+				Email
+				<input type="email" bind:value={email} />
+			</label>
+		</div>
+
+		<div class="field">
+			<label>
+				<input type="checkbox" bind:checked={isEnabled} />
+				Enable feature
+			</label>
+		</div>
+
+		<div class="field">
+			<button onclick={() => count++}>Count: {count}</button>
+		</div>
+
+		<p class={{ valid: formValid, invalid: !formValid }}>
+			Form is {formValid ? "valid" : "invalid"}
+		</p>
+	</div>
+
+	<div class="state-display">
+		<h3>Current State</h3>
+		<pre>{JSON.stringify(
+				{ name, email, isEnabled, count, formValid },
+				null,
+				2,
+			)}</pre>
+	</div>
+
+	<div class="guidelines">
+		<h3>Creating Bindable Components</h3>
+
+		<h4>1. TextInput Component (with $bindable)</h4>
+		<pre><code
+				>&lt;!-- TextInput.svelte --&gt;
+&lt;script lang="ts"&gt;
+  interface Props &#123;
+    value?: string;
+    label: string;
+  &#125;
+
+  let &#123; value = $bindable(''), label &#125;: Props = $props();
+&lt;/script&gt;
+
+&lt;label&gt;
+  &#123;label&#125;
+  &lt;input type="text" bind:value /&gt;
+&lt;/label&gt;
+
+&lt;!-- Usage --&gt;
+&lt;TextInput bind:value=&#123;name&#125; label="Name" /&gt;</code
+			></pre>
+
+		<h4>2. Counter Component (callback pattern - no $bindable)</h4>
+		<pre><code
+				>&lt;!-- Counter.svelte --&gt;
+&lt;script lang="ts"&gt;
+  interface Props &#123;
+    count: number;
+    onIncrement: () =&gt; void;
+  &#125;
+
+  let &#123; count, onIncrement &#125;: Props = $props();
+&lt;/script&gt;
+
+&lt;button onclick=&#123;onIncrement&#125;&gt;Count: &#123;count&#125;&lt;/button&gt;
+
+&lt;!-- Usage --&gt;
+&lt;Counter &#123;count&#125; onIncrement=&#123;() =&gt; count++&#125; /&gt;</code
+			></pre>
+
+		<h4>When to Use $bindable</h4>
+		<ul>
+			<li>✅ Form input wrappers</li>
+			<li>✅ Parent needs to read AND write</li>
+			<li>✅ Two-way data flow is natural</li>
+			<li>❌ Parent only reads (use callback)</li>
+			<li>❌ Need validation (use callback)</li>
+		</ul>
+
+		<h4>Decision Tree</h4>
+		<pre>Parent needs to read child state?
+├─ No → Pass callbacks
+└─ Yes → Parent needs to UPDATE child?
+    ├─ No → Callback (onChange)
+    └─ Yes → Use $bindable()</pre>
+	</div>
+</div>
+
+<style>
+	.demo {
+		max-width: 800px;
+		margin: 0 auto;
+		padding: 2rem;
+	}
+
+	.form {
+		margin: 2rem 0;
+		padding: 1rem;
+		border: 1px solid #ccc;
+		border-radius: 0.5rem;
+	}
+
+	.field {
+		margin: 1rem 0;
+	}
+
+	label {
+		display: flex;
+		align-items: center;
+		gap: 0.5rem;
+		font-weight: 500;
+	}
+
+	input[type="text"],
+	input[type="email"] {
+		padding: 0.5rem;
+		font-size: 1rem;
+		border: 1px solid #ccc;
+		border-radius: 0.25rem;
+		flex: 1;
+	}
+
+	input[type="checkbox"] {
+		width: 1.25rem;
+		height: 1.25rem;
+	}
+
+	button {
+		padding: 0.5rem 1rem;
+		font-size: 1rem;
+		cursor: pointer;
+		background: #007bff;
+		color: white;
+		border: none;
+		border-radius: 0.25rem;
+	}
+
+	button:hover {
+		background: #0056b3;
+	}
+
+	.valid {
+		color: green;
+		font-weight: bold;
+	}
+
+	.invalid {
+		color: red;
+		font-weight: bold;
+	}
+
+	.state-display {
+		margin: 2rem 0;
+		padding: 1rem;
+		background: #f5f5f5;
+		border-radius: 0.5rem;
+	}
+
+	.state-display pre {
+		margin: 0;
+		overflow-x: auto;
+	}
+
+	.guidelines {
+		margin: 2rem 0;
+		padding: 1rem;
+		border: 1px solid #ccc;
+		border-radius: 0.5rem;
+	}
+
+	h3 {
+		margin-top: 0;
+	}
+
+	h4 {
+		margin: 1rem 0 0.5rem 0;
+	}
+
+	pre {
+		background: #f5f5f5;
+		padding: 1rem;
+		border-radius: 0.25rem;
+		overflow-x: auto;
+	}
+
+	code {
+		font-family: "Courier New", monospace;
+		font-size: 0.9rem;
+	}
+
+	ul {
+		margin: 0.5rem 0;
+	}
+</style>
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-runes/examples/effect-vs-derived.svelte b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/examples/effect-vs-derived.svelte
new file mode 100644
index 00000000..e8ee4fb4
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/examples/effect-vs-derived.svelte
@@ -0,0 +1,154 @@
+<!--
+  EXAMPLE: When to use $derived vs $effect
+
+  This demonstrates the key difference:
+  - $derived: For computed values (data transformation)
+  - $effect: For side effects (logging, DOM, external APIs)
+-->
+
+<script lang="ts">
+	let count = $state(0);
+
+	// ✅ CORRECT: Use $derived for computed values
+	let doubled = $derived(count * 2);
+	let tripled = $derived(count * 3);
+	let message = $derived(
+		count === 0 ? 'Zero' : count > 10 ? 'High' : 'Low',
+	);
+
+	// ✅ CORRECT: Use $effect for side effects
+	$effect(() => {
+		// Side effect: Logging
+		console.log(`Count changed to ${count}`);
+
+		// Side effect: Update document title
+		document.title = `Count: ${count}`;
+
+		// Side effect: Save to localStorage
+		localStorage.setItem('count', String(count));
+	});
+
+	// ✅ CORRECT: $effect with cleanup
+	$effect(() => {
+		const interval = setInterval(() => {
+			console.log('Current count:', count);
+		}, 1000);
+
+		// Cleanup function (runs when effect re-runs or component unmounts)
+		return () => clearInterval(interval);
+	});
+
+	// ❌ WRONG: Don't use $effect for derived state
+	// let wrongDoubled = $state(0);
+	// $effect(() => {
+	//   wrongDoubled = count * 2;  // BAD - use $derived!
+	// });
+
+	// ❌ WRONG: Don't update dependencies in $effect
+	// $effect(() => {
+	//   count++;  // INFINITE LOOP!
+	// });
+
+	function increment() {
+		count++;
+	}
+
+	function decrement() {
+		count--;
+	}
+
+	function reset() {
+		count = 0;
+	}
+</script>
+
+<div>
+	<h2>$derived vs $effect Demo</h2>
+
+	<div class="counter">
+		<button onclick={decrement}>-</button>
+		<span>{count}</span>
+		<button onclick={increment}>+</button>
+		<button onclick={reset}>Reset</button>
+	</div>
+
+	<div class="computed">
+		<h3>Computed Values ($derived)</h3>
+		<p>Doubled: {doubled}</p>
+		<p>Tripled: {tripled}</p>
+		<p>Message: {message}</p>
+	</div>
+
+	<div class="effects">
+		<h3>Side Effects ($effect)</h3>
+		<ul>
+			<li>Check console for log output</li>
+			<li>Check document title</li>
+			<li>Check localStorage (key: 'count')</li>
+		</ul>
+	</div>
+
+	<div class="guidelines">
+		<h3>When to Use Each</h3>
+
+		<h4>Use $derived when:</h4>
+		<ul>
+			<li>Transforming data (multiply, format, filter)</li>
+			<li>Computing values based on other state</li>
+			<li>Value is used in template</li>
+			<li>Need read-only computed property</li>
+		</ul>
+
+		<h4>Use $effect when:</h4>
+		<ul>
+			<li>Logging or analytics</li>
+			<li>Updating external state (localStorage, DOM)</li>
+			<li>Fetching data</li>
+			<li>Setting up subscriptions (intervals, listeners)</li>
+			<li>Any operation with side effects</li>
+		</ul>
+	</div>
+</div>
+
+<style>
+	.counter {
+		display: flex;
+		gap: 1rem;
+		align-items: center;
+		margin: 1rem 0;
+	}
+
+	button {
+		padding: 0.5rem 1rem;
+		font-size: 1rem;
+		cursor: pointer;
+	}
+
+	.counter span {
+		font-size: 2rem;
+		font-weight: bold;
+		min-width: 3rem;
+		text-align: center;
+	}
+
+	.computed,
+	.effects,
+	.guidelines {
+		margin: 2rem 0;
+		padding: 1rem;
+		border: 1px solid #ccc;
+		border-radius: 0.5rem;
+	}
+
+	h3 {
+		margin-top: 0;
+	}
+
+	h4 {
+		margin-bottom: 0.5rem;
+	}
+
+	ul {
+		margin-top: 0.5rem;
+	}
+</style>
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/common-mistakes.md b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/common-mistakes.md
new file mode 100644
index 00000000..125c85ba
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/common-mistakes.md
@@ -0,0 +1,821 @@
+# Common Mistakes: Anti-Patterns and Fixes
+
+## Top 10 Svelte 5 Mistakes
+
+### 1. Using $effect for Derived State ❌
+
+**WRONG:**
+
+```svelte
+<script>
+	let count = $state(0);
+	let doubled = $state(0);
+
+	$effect(() => {
+		doubled = count * 2; // BAD - use $derived!
+	});
+</script>
+```
+
+**RIGHT:**
+
+```svelte
+<script>
+	let count = $state(0);
+	let doubled = $derived(count * 2); // GOOD - computed value
+</script>
+```
+
+**Why:** `$effect` runs after DOM updates and is for side effects.
+`$derived` is optimized for computed values.
+
+---
+
+### 1b. Using $effect When Event Handler Works ❌
+
+**WRONG:**
+
+```svelte
+<script>
+	let count = $state(0);
+	let lastClicked = $state(null);
+
+	$effect(() => {
+		// BAD - reacting to count change just to log
+		console.log(`Count is now ${count}`);
+	});
+</script>
+
+<button onclick={() => count++}>Increment</button>
+```
+
+**RIGHT:**
+
+```svelte
+<script>
+	let count = $state(0);
+
+	function increment() {
+		count++;
+		console.log(`Count is now ${count}`); // Side effect in handler
+	}
+</script>
+
+<button onclick={increment}>Increment</button>
+```
+
+**Why:** Per Svelte docs: "If you can put your side effects in an event
+handler, that's almost always preferable." Event handlers are predictable
+and run once per action.
+
+---
+
+### 1c. Using $effect to Sync Linked Values ❌
+
+**WRONG:**
+
+```svelte
+<script>
+	let celsius = $state(0);
+	let fahrenheit = $state(32);
+
+	// Two effects trying to sync each other - fragile!
+	$effect(() => {
+		fahrenheit = (celsius * 9) / 5 + 32;
+	});
+
+	$effect(() => {
+		celsius = ((fahrenheit - 32) * 5) / 9;
+	});
+</script>
+
+<input type="number" bind:value={celsius} />
+<input type="number" bind:value={fahrenheit} />
+```
+
+**RIGHT - Use oninput callbacks:**
+
+```svelte
+<script>
+	let celsius = $state(0);
+	let fahrenheit = $state(32);
+
+	function updateFromCelsius(e) {
+		celsius = +e.target.value;
+		fahrenheit = (celsius * 9) / 5 + 32;
+	}
+
+	function updateFromFahrenheit(e) {
+		fahrenheit = +e.target.value;
+		celsius = ((fahrenheit - 32) * 5) / 9;
+	}
+</script>
+
+<input type="number" value={celsius} oninput={updateFromCelsius} />
+<input type="number" value={fahrenheit} oninput={updateFromFahrenheit} />
+```
+
+**Why:** Per Svelte docs, avoid effects for "connecting one value to
+another". Use `oninput` callbacks or function bindings instead.
+
+---
+
+### 1d. Using $effect to Sync Async Data into Form State ❌
+
+**WRONG:**
+
+```svelte
+<script>
+	let query = $derived(get_item({ id }))
+	let name = $state('')
+
+	// BAD — $effect as escape hatch to sync query → form state
+	$effect(() => {
+		if (query.ready) name = query.current.name
+	})
+</script>
+
+<input bind:value={name} />
+```
+
+**RIGHT — Gate child component behind `.ready`:**
+
+```svelte
+<!-- Parent.svelte -->
+<script>
+	let query = $derived(get_item({ id }))
+</script>
+
+{#if !query.ready}
+	<Skeleton />
+{:else}
+	<EditForm item={query.current} />
+{/if}
+```
+
+```svelte
+<!-- EditForm.svelte -->
+<script>
+	let { item } = $props()
+	// svelte-ignore state_referenced_locally
+	let form = $state({ name: item.name }) // init from prop at mount
+</script>
+
+<input bind:value={form.name} />
+```
+
+**Why:** The child component initializes `$state` from props once at
+mount time. No `$effect` needed, no `state_unsafe_mutation` warning.
+This is the standard pattern for editable forms backed by async data.
+
+---
+
+### 2. Reassigning $derived Values ⚠️
+
+**Note:** As of Svelte 5.25+, `$derived` CAN be reassigned, but will
+recalculate when dependencies change.
+
+**CONFUSING (works but not recommended):**
+
+```svelte
+<script>
+	let count = $state(0);
+	let doubled = $derived(count * 2);
+
+	function reset() {
+		doubled = 0; // Temporarily overrides, but recalculates when count changes
+	}
+</script>
+```
+
+**CLEARER - Use const for read-only:**
+
+```svelte
+<script>
+	let count = $state(0);
+	const doubled = $derived(count * 2); // const = truly read-only
+
+	function reset() {
+		count = 0; // Update source, derived updates automatically
+	}
+</script>
+```
+
+**Why:** While reassignment is allowed, it's clearer to update the
+source state. Use `const` to enforce read-only behavior.
+
+---
+
+### 3. Optional Chaining Breaks Effect Reactivity ❌
+
+**WRONG:**
+
+```svelte
+<script>
+	let particles = $state(undefined);
+	let scheme = $state('dark');
+
+	$effect(() => {
+		// If particles is undefined, scheme is NEVER read!
+		// Effect won't re-run when scheme changes
+		particles?.updateScheme(scheme);
+	});
+</script>
+```
+
+**RIGHT:**
+
+```svelte
+<script>
+	let particles = $state(undefined);
+	let scheme = $state('dark');
+
+	$effect(() => {
+		// Read scheme first to create dependency
+		const currentScheme = scheme;
+		if (particles) {
+			particles.updateScheme(currentScheme);
+		}
+	});
+</script>
+```
+
+**Why:** JavaScript short-circuits optional chaining. If `particles`
+is nullish, `scheme` is never evaluated, so no dependency is created.
+
+---
+
+### 4. Creating Infinite Loops in $effect ❌
+
+**WRONG:**
+
+```svelte
+<script>
+	let count = $state(0);
+
+	$effect(() => {
+		count++; // INFINITE LOOP - effect triggers itself!
+	});
+</script>
+```
+
+**RIGHT - Don't update dependencies**
+
+```svelte
+<script>
+	let count = $state(0);
+	let log = $state([]);
+
+	$effect(() => {
+		log.push(count); // Updates different state
+	});
+</script>
+```
+
+**RIGHT - Use untrack() to read without subscribing**
+
+```svelte
+<script>
+	import { untrack } from 'svelte';
+
+	let count = $state(0);
+
+	$effect(() => {
+		console.log('Effect ran');
+		// Read count without creating dependency
+		const current = untrack(() => count);
+		// Now updating count won't re-trigger this effect
+	});
+</script>
+```
+
+**Why:** `$effect` runs when any accessed `$state` changes. Updating
+that state creates a loop. Use `untrack()` to read state without
+creating a dependency.
+
+---
+
+### 4b. Using $effect to Sync State with DOM Elements ❌
+
+**WRONG - Dialog sync via effect:**
+
+```svelte
+<script>
+	let is_open = $state(false);
+	let dialog_element = $state<HTMLDialogElement>();
+
+	$effect(() => {
+		if (is_open) {
+			dialog_element?.showModal();
+		} else {
+			dialog_element?.close(); // Fires 'close' event → handler → loop!
+		}
+	});
+</script>
+
+<dialog bind:this={dialog_element} onclose={() => is_open = false}>
+```
+
+**Why it fails:** `dialog.close()` fires the native `close` event, which
+triggers your handler, which may cause loops or double-firing.
+
+**RIGHT - State class with @attach:**
+
+```ts
+// state.svelte.ts
+class DialogState {
+	dialog: HTMLDialogElement | null = null;
+	is_open = $state(false);
+
+	register = (el: HTMLDialogElement) => {
+		this.dialog = el;
+		return () => {
+			this.dialog = null;
+		};
+	};
+
+	open() {
+		if (!this.dialog?.open) {
+			this.is_open = true;
+			this.dialog?.showModal();
+		}
+	}
+
+	close() {
+		this.is_open = false;
+		this.dialog?.close();
+	}
+}
+```
+
+```svelte
+<!-- Component.svelte -->
+<dialog {@attach dialog_state.register} onclose={dialog_state.close}>
+```
+
+**Why:** Per Svelte docs, "$effect is best thought of as an escape hatch"
+and "you should not update state inside effects". Use @attach to register
+elements with state, then call DOM methods directly.
+
+---
+
+### 4c. Using Runes Inside Functions ❌
+
+**WRONG:**
+
+```svelte
+<script>
+	function createCounter() {
+		let count = $state(0); // ERROR - runes must be top-level!
+		return count;
+	}
+
+	const counter = createCounter();
+</script>
+```
+
+**RIGHT - Option 1: Top-level runes**
+
+```svelte
+<script>
+	let count = $state(0);
+</script>
+```
+
+**RIGHT - Option 2: Reactive class fields**
+
+```svelte
+<script>
+	class Counter {
+		count = $state(0); // OK in class fields
+	}
+
+	const counter = new Counter();
+</script>
+```
+
+**Why:** Runes must be statically analyzable at compile time. Use
+classes for encapsulation.
+
+---
+
+### 5. Understanding Deep Reactivity in Svelte 5 ✅
+
+**GOOD NEWS: Deep reactivity works by default!**
+
+```svelte
+<script>
+	let user = $state({ profile: { name: 'Alex' } });
+
+	function updateName() {
+		user.profile.name = 'Bo'; // This DOES trigger reactivity!
+	}
+</script>
+
+<p>{user.profile.name}</p> <!-- Will update correctly -->
+```
+
+**Why:** `$state()` creates deep reactive proxies by default. Nested
+mutations trigger updates.
+
+**When to use $state.raw() instead:**
+
+```svelte
+<script>
+	// For large, immutable data structures where you don't need reactivity
+	let config = $state.raw(hugeConfigObject); // Skip deep proxy overhead for performance
+
+	// For data you'll fully replace, not mutate
+	let apiResponse = $state.raw(data); // Will replace entire object later
+</script>
+```
+
+**Why:** Use `$state.raw()` for **performance optimization** when you
+don't need deep reactivity, not because deep reactivity doesn't work.
+
+---
+
+### 6. Using Derived Logic Outside `$derived` ❌
+
+**WRONG:**
+
+```svelte
+<script>
+	let count = $state(0);
+	let doubled = count * 2; // Won't update when count changes
+</script>
+```
+
+**RIGHT:**
+
+```svelte
+<script>
+	let count = $state(0);
+	const doubled = $derived(count * 2);
+</script>
+
+<button onclick={() => count++}>
+	{count} / {doubled}
+</button>
+```
+
+**Why:** Values derived from reactive state must use `$derived` or `$derived.by`.
+
+---
+
+### 7. Forgetting $state for Reactive Variables ❌
+
+**WRONG:**
+
+```svelte
+<script>
+	let count = 0; // Not reactive in Svelte 5!
+</script>
+
+<button onclick={() => count++}>{count}</button>
+<!-- UI won't update! -->
+```
+
+**RIGHT:**
+
+```svelte
+<script>
+	let count = $state(0); // Reactive
+</script>
+
+<button onclick={() => count++}>{count}</button>
+```
+
+**Why:** Plain variables aren't reactive in Svelte 5. Must use $state.
+
+---
+
+### 8. Not Using $bindable for Two-Way Binding ❌
+
+**WRONG:**
+
+```svelte
+<!-- Child.svelte -->
+<script>
+	let { value } = $props(); // Not bindable!
+</script>
+
+<input bind:value />
+
+<!-- Parent.svelte -->
+<Child bind:value={text} />
+<!-- ERROR - value is not bindable -->
+```
+
+**RIGHT:**
+
+```svelte
+<!-- Child.svelte -->
+<script>
+	let { value = $bindable() } = $props(); // Make it bindable
+</script>
+
+<input bind:value />
+
+<!-- Parent.svelte -->
+<Child bind:value={text} />
+<!-- Works! -->
+```
+
+**Why:** Props must explicitly declare they're bindable with
+$bindable().
+
+---
+
+### 9. Forgetting {@render} for Children ❌
+
+**WRONG:**
+
+```svelte
+<script>
+	let { children } = $props();
+</script>
+
+<div>{children}</div> <!-- Won't render! Shows [object Object] -->
+```
+
+**RIGHT:**
+
+```svelte
+<script>
+	let { children } = $props();
+</script>
+
+<div>{@render children()}</div> <!-- Renders children -->
+```
+
+**Why:** Children is a snippet, not a value. Must use {@render}.
+
+---
+
+### 10. Putting Event Logic in `$effect` ❌
+
+**WRONG:**
+
+```svelte
+<script>
+	let clicked = $state(false);
+
+	$effect(() => {
+		if (clicked) submit();
+	});
+</script>
+
+<button onclick={() => clicked = true}>Submit</button>
+```
+
+**RIGHT:**
+
+```svelte
+<button onclick={submit}>Submit</button>
+```
+
+**Why:** User-triggered work belongs in event handlers. Reserve `$effect` for synchronization with external systems.
+
+---
+
+## Array and Object Mutations Work!
+
+Svelte 5 has **deep reactivity** - array and object mutations trigger
+updates:
+
+### Arrays - All Methods Work
+
+```svelte
+<script>
+	let items = $state([1, 2, 3]);
+
+	function addItem() {
+		items.push(4); // ✅ Works! Triggers reactivity
+		// OR
+		items[items.length] = 5; // ✅ Also works!
+		// OR
+		items = [...items, 6]; // ✅ Also works!
+	}
+</script>
+```
+
+### Nested Arrays - Also Work!
+
+```svelte
+<script>
+	let data = $state({ items: [1, 2, 3], nested: { arr: [10, 20] } });
+
+	function addItem() {
+		data.items.push(4); // ✅ Works! Deep reactivity
+	}
+
+	function addNested() {
+		data.nested.arr.push(30); // ✅ Works! Deeply reactive
+	}
+</script>
+```
+
+**All mutations trigger UI updates** because `$state()` creates deep
+proxies.
+
+## Performance Mistakes
+
+### 1. Using $state When You Don't Need Reactivity
+
+**UNNECESSARY:**
+
+```svelte
+<script>
+	const API_URL = $state('https://api.example.com'); // Doesn't change!
+</script>
+```
+
+**BETTER:**
+
+```svelte
+<script>
+	const API_URL = 'https://api.example.com'; // Plain const
+</script>
+```
+
+### 2. Using $state.raw for Performance
+
+**When you have large immutable data:**
+
+```svelte
+<script>
+	// Deep proxy has overhead for large objects
+	let bigConfig = $state(hugeImmutableObject); // Slower
+
+	// Skip proxies for data you don't mutate
+	let bigConfig = $state.raw(hugeImmutableObject); // Faster
+</script>
+```
+
+**Use $state.raw() when:**
+
+- Data is large and immutable
+- You'll replace entire object, not mutate it
+- Performance is critical
+
+**Don't use $state.raw() when:**
+
+- You need to mutate nested properties
+- Data is small/medium sized
+
+### 3. Unnecessary $derived
+
+**UNNECESSARY:**
+
+```svelte
+<script>
+	let { count } = $props();
+	let doubled = $derived(count * 2); // Used only once
+</script>
+
+<p>{doubled}</p>
+```
+
+**SIMPLER:**
+
+```svelte
+<script>
+	let { count } = $props();
+</script>
+
+<p>{count * 2}</p> <!-- Inline is fine -->
+```
+
+## TypeScript Mistakes
+
+### 1. Not Typing Props
+
+**WRONG:**
+
+```svelte
+<script lang="ts">
+	let { name, age } = $props(); // No types!
+</script>
+```
+
+**RIGHT:**
+
+```svelte
+<script lang="ts">
+	interface Props {
+		name: string;
+		age: number;
+	}
+
+	let { name, age }: Props = $props();
+</script>
+```
+
+### 2. Wrong Bindable Type
+
+**WRONG:**
+
+```svelte
+<script lang="ts">
+	let { value = $bindable() }: { value: string } = $props();
+	//                                   ^^^^^^ Should be optional
+</script>
+```
+
+**RIGHT:**
+
+```svelte
+<script lang="ts">
+	let { value = $bindable('') }: { value?: string } = $props();
+	//                                       ^ Optional
+</script>
+```
+
+## Error Messages and Fixes
+
+### "Cannot access 'count' before initialization"
+
+**Cause:** Using rune inside function or wrong order
+
+```svelte
+<!-- WRONG -->
+<script>
+  const doubled = count * 2;
+  let count = $state(0);
+</script>
+
+<!-- RIGHT -->
+<script>
+  let count = $state(0);
+  const doubled = $derived(count * 2);
+</script>
+```
+
+### "Cannot read properties of undefined (reading '$effect')"
+
+**Cause:** Using rune outside component scope
+
+```svelte
+<!-- WRONG -->
+<script context="module">
+	let count = $state(0); // ERROR - not in component scope
+</script>
+
+<!-- RIGHT -->
+<script>
+	let count = $state(0); // OK
+</script>
+```
+
+### "bind:value is not available on this component"
+
+**Cause:** Forgot $bindable
+
+**Fix:** Add `$bindable()` to prop definition
+
+## Best Practices Summary
+
+1. ✅ **Prefer event handlers** over `$effect` for side effects
+2. ✅ Use `$derived` for computed values, not `$effect`
+3. ✅ Use `@attach` for DOM element operations
+4. ✅ Don't update dependencies inside `$effect`
+5. ✅ Keep runes at component top-level
+6. ✅ Use consistent Svelte 5 syntax (no mixing)
+7. ✅ Wrap reactive variables with `$state()`
+8. ✅ Use `$bindable()` for two-way binding
+9. ✅ Use `{@render children()}` not `{children}`
+10. ✅ Put user-triggered work directly in event handlers
+11. ✅ Remember: `$effect` doesn't run during SSR
+
+## Debugging: $inspect.trace
+
+`$inspect.trace` is a debugging tool for reactivity. Add it as the first
+line of an `$effect` or `$derived.by` to trace dependencies and discover
+which one triggered an update.
+
+```svelte
+<script>
+	let count = $state(0);
+	let name = $state('world');
+
+	$effect(() => {
+		$inspect.trace('greeting effect');
+		console.log(`Hello ${name}, count is ${count}`);
+	});
+
+	const message = $derived.by(() => {
+		$inspect.trace('message derived');
+		return `${name}: ${count}`;
+	});
+</script>
+```
+
+**When to use:**
+
+- Something is not updating when it should
+- An effect or derived is running more often than expected
+- You need to identify which dependency triggered a re-run
+
+**Note:** Remove `$inspect.trace` before production — it's for debugging
+only, like `{@debug}`.
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/component-api.md b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/component-api.md
new file mode 100644
index 00000000..c1ad5d90
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/component-api.md
@@ -0,0 +1,490 @@
+# Component API: $props and $bindable
+
+## $props() - Accepting Props
+
+### Basic Usage
+
+```svelte
+<script>
+	let { name, age } = $props();
+</script>
+
+<p>{name} is {age} years old</p>
+
+<!-- Usage: <Person name="Alex" age={30} /> -->
+```
+
+### With Defaults
+
+```svelte
+<script>
+	let { name = 'Anonymous', age = 18 } = $props();
+</script>
+```
+
+### With TypeScript
+
+```svelte
+<script lang="ts">
+	interface Props {
+		name: string;
+		age?: number; // Optional with default
+	}
+
+	let { name, age = 18 }: Props = $props();
+</script>
+```
+
+### Rest Props
+
+Capture all additional props:
+
+```svelte
+<script>
+	let { name, age, ...rest } = $props();
+</script>
+
+<div {...rest}>
+	<p>{name} is {age}</p>
+</div>
+
+<!-- Usage: <Person name="Alex" age={30} class="card" id="p1" /> -->
+<!-- rest = { class: 'card', id: 'p1' } -->
+```
+
+### Accessing All Props
+
+```svelte
+<script>
+	let props = $props();
+</script>
+
+<p>{props.name} is {props.age}</p>
+```
+
+**When to use:**
+
+- When you need to pass all props to a child
+- When you don't know prop names in advance
+- When you want to iterate over props
+
+## $bindable() - Two-Way Binding
+
+### Basic Bindable Prop
+
+```svelte
+<!-- Toggle.svelte -->
+<script>
+  let { checked = $bindable(false) } = $props();
+</script>
+
+<input type="checkbox" bind:checked />
+
+<!-- Usage -->
+<script>
+  let isEnabled = $state(false);
+</script>
+
+<Toggle bind:checked={isEnabled} />
+<p>Enabled: {isEnabled}</p>
+```
+
+### When to Use $bindable
+
+**Use when:**
+
+- Parent needs to read the value
+- Parent needs to update the value
+- Two-way data flow is appropriate
+
+**Examples:**
+
+- Form inputs (text, checkbox, select)
+- Toggles, sliders, color pickers
+- Custom input components
+
+### Default Values
+
+```svelte
+<script>
+	let { value = $bindable('') } = $props();
+	//                       ^^^^^ default if parent doesn't provide
+</script>
+```
+
+### Optional Bindable Props
+
+```svelte
+<script lang="ts">
+	interface Props {
+		value?: string; // Optional
+	}
+
+	let { value = $bindable('default') }: Props = $props();
+</script>
+```
+
+### Multiple Bindable Props
+
+```svelte
+<!-- Slider.svelte -->
+<script>
+  let { min = $bindable(0), max = $bindable(100) } = $props();
+</script>
+
+<input type="range" bind:value={min} />
+<input type="range" bind:value={max} />
+
+<!-- Usage -->
+<script>
+  let minPrice = $state(0);
+  let maxPrice = $state(1000);
+</script>
+
+<Slider bind:min={minPrice} bind:max={maxPrice} />
+<p>Range: ${minPrice} - ${maxPrice}</p>
+```
+
+## Common Patterns
+
+### Form Input Wrapper
+
+```svelte
+<!-- Input.svelte -->
+<script>
+  let {
+    value = $bindable(''),
+    label,
+    type = 'text',
+    ...rest
+  } = $props();
+</script>
+
+<label>
+  {label}
+  <input {type} bind:value {...rest} />
+</label>
+
+<!-- Usage -->
+<script>
+  let email = $state('');
+</script>
+
+<Input
+  bind:value={email}
+  label="Email"
+  type="email"
+  placeholder="you@example.com"
+  required
+/>
+```
+
+### Controlled Component (No $bindable)
+
+When parent fully controls the state:
+
+```svelte
+<!-- Counter.svelte -->
+<script>
+  let { count, onIncrement } = $props();
+</script>
+
+<button onclick={onIncrement}>
+  Count: {count}
+</button>
+
+<!-- Usage -->
+<script>
+  let count = $state(0);
+</script>
+
+<Counter
+  {count}
+  onIncrement={() => count++}
+/>
+```
+
+**Use this pattern when:**
+
+- Parent should control all updates
+- You need to validate/transform updates
+- Side effects should run on change
+
+### Hybrid: Bindable with Callback
+
+```svelte
+<!-- Slider.svelte -->
+<script>
+  let {
+    value = $bindable(50),
+    onChange
+  } = $props();
+
+  function handleChange() {
+    onChange?.(value);  // Notify parent
+  }
+</script>
+
+<input
+  type="range"
+  bind:value
+  oninput={handleChange}
+/>
+
+<!-- Usage -->
+<script>
+  let volume = $state(50);
+</script>
+
+<Slider
+  bind:value={volume}
+  onChange={(v) => console.log('Volume changed:', v)}
+/>
+```
+
+## Props vs Bindable Decision Tree
+
+```
+Parent needs to read child state?
+├─ No → Just pass callbacks (controlled component)
+├─ Yes → Parent needs to UPDATE child state?
+    ├─ No → Callback to notify parent (onChange pattern)
+    └─ Yes → Use $bindable (two-way binding)
+```
+
+## TypeScript Best Practices
+
+### Strict Props Interface
+
+```svelte
+<script lang="ts">
+	interface Props {
+		// Required props
+		name: string;
+		age: number;
+
+		// Optional props
+		email?: string;
+
+		// Props with defaults (must be optional in interface)
+		role?: string;
+
+		// Bindable props
+		checked?: boolean;
+
+		// Callbacks
+		onSave?: (data: FormData) => void;
+
+		// Rest props (for spreading to elements)
+		[key: string]: unknown;
+	}
+
+	let {
+		name,
+		age,
+		email,
+		role = 'user',
+		checked = $bindable(false),
+		onSave,
+		...rest
+	}: Props = $props();
+</script>
+```
+
+### Generic Components
+
+```svelte
+<script lang="ts" generics="T">
+	interface Props<T> {
+		items: T[];
+		selected?: T;
+		onSelect?: (item: T) => void;
+	}
+
+	let { items, selected, onSelect }: Props<T> = $props();
+</script>
+
+{#each items as item}
+	<button onclick={() => onSelect?.(item)}>
+		{item}
+	</button>
+{/each}
+```
+
+## Common Mistakes
+
+### ❌ Forgetting $bindable
+
+```svelte
+<!-- WRONG -->
+<script>
+  let { value } = $props();
+</script>
+<input bind:value />
+
+<!-- Parent tries: <Component bind:value={text} /> -->
+<!-- ERROR: Cannot bind to non-bindable prop -->
+
+<!-- RIGHT -->
+<script>
+  let { value = $bindable() } = $props();
+</script>
+<input bind:value />
+```
+
+### ❌ Mutating Non-Bindable Props
+
+```svelte
+<!-- WRONG -->
+<script>
+  let { count } = $props();  // Not bindable!
+
+  function increment() {
+    count++;  // BAD - mutating prop from parent
+  }
+</script>
+
+<!-- RIGHT - Option 1: Use callback -->
+<script>
+  let { count, onIncrement } = $props();
+</script>
+<button onclick={onIncrement}>+</button>
+
+<!-- RIGHT - Option 2: Make bindable -->
+<script>
+  let { count = $bindable(0) } = $props();
+</script>
+<button onclick={() => count++}>+</button>
+```
+
+### ❌ Not Providing Default for Bindable
+
+```svelte
+<!-- RISKY -->
+<script>
+  let { value = $bindable() } = $props();
+  //                       ^^^ undefined if parent doesn't provide
+</script>
+
+<!-- SAFER -->
+<script>
+  let { value = $bindable('default') } = $props();
+  //                       ^^^^^^^^^ explicit default
+</script>
+```
+
+### ❌ Unnecessary Bindable
+
+```svelte
+<!-- WRONG - Overkill -->
+<script>
+  let { label = $bindable('Submit') } = $props();
+</script>
+<button>{label}</button>
+
+<!-- RIGHT - Label doesn't need to be bindable -->
+<script>
+  let { label = 'Submit' } = $props();
+</script>
+<button>{label}</button>
+```
+
+**Rule of thumb:** Only use `$bindable` when parent _needs_ to update
+the prop value.
+
+## Prop Drilling vs Context
+
+For deeply nested components, use `createContext` instead of prop
+drilling. See [createContext](#createcontext---type-safe-context) below
+for the recommended pattern.
+
+## Performance: Props Are Reactive
+
+Props are automatically reactive - no need for extra $derived:
+
+```svelte
+<!-- UNNECESSARY -->
+<script>
+  let { count } = $props();
+  let doubled = $derived(count * 2);  // Overkill if just used once
+</script>
+<p>{doubled}</p>
+
+<!-- SIMPLER -->
+<script>
+  let { count } = $props();
+</script>
+<p>{count * 2}</p>
+```
+
+**Use $derived when:**
+
+- Value is used multiple times
+- Computation is expensive
+- You need to derive from multiple props
+
+## createContext - Type-Safe Context
+
+Per official Svelte best practices: use `createContext` rather than
+`setContext` and `getContext`, as it provides type safety.
+
+### Basic Usage
+
+```ts
+// context.ts
+import { createContext } from 'svelte';
+
+const [get_theme, set_theme] = createContext<{ current: string }>('theme');
+
+export { get_theme, set_theme };
+```
+
+```svelte
+<!-- Provider.svelte -->
+<script>
+	import { set_theme } from './context';
+
+	let theme = $state('dark');
+	set_theme({
+		get current() { return theme; },
+		set current(value) { theme = value; }
+	});
+</script>
+
+{@render children()}
+```
+
+```svelte
+<!-- Consumer.svelte -->
+<script>
+	import { get_theme } from './context';
+
+	const theme = get_theme();
+</script>
+
+<p>Theme: {theme.current}</p>
+<button onclick={() => theme.current = 'light'}>Light mode</button>
+```
+
+### Why createContext over set/getContext
+
+| Feature | `setContext`/`getContext` | `createContext` |
+|---------|------------------------|-----------------|
+| Type safety | Manual casting | **Automatic** |
+| Key management | String keys (typo-prone) | **Module-scoped** |
+| Default values | Manual check | **Built-in support** |
+
+### Context vs Shared Module State
+
+Per best practices: use context instead of declaring state in a shared
+module. Context scopes state to the component tree, preventing leaks
+between users during SSR.
+
+```ts
+// BAD - shared module state leaks between SSR requests
+let theme = $state('dark');
+export const get_shared_theme = () => theme;
+
+// GOOD - context is scoped per component tree
+const [get_theme, set_theme] = createContext<string>('theme');
+```
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/reactivity-patterns.md b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/reactivity-patterns.md
new file mode 100644
index 00000000..eb6cbe04
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/reactivity-patterns.md
@@ -0,0 +1,339 @@
+# Reactivity Patterns: When to Use Each Rune
+
+## Decision Matrix
+
+| Need                 | Use                    | Why                                    |
+| -------------------- | ---------------------- | -------------------------------------- |
+| Mutable state        | `$state()`             | Base reactive variable                 |
+| Computed value       | `$derived()`           | Auto-updates when dependencies change  |
+| Complex computation  | `$derived.by()`        | Use function body for multi-line logic |
+| Large immutable data | `$state.raw()`         | Skip deep reactivity for performance   |
+| Read-only snapshot   | `$state.snapshot()`    | Get plain JS value, no proxy           |
+| Side effect          | `$effect()`            | Run code when dependencies change      |
+| Pre-DOM effect       | `$effect.pre()`        | Run before DOM updates                 |
+| Accept props         | `$props()`             | Declare component props                |
+| Bindable prop        | `$bindable()`          | Allow parent to bind to prop           |
+| Reactive class field | `$state` (class field) | Reactive property in class             |
+
+## $effect Decision Hierarchy
+
+**$effect is an escape hatch.** Before using it, ask:
+
+```
+Need to react to state change?
+├─ Can use event handler? → USE EVENT HANDLER (preferred)
+├─ Is it a computed value? → USE $derived
+├─ Is it DOM-specific? → USE @attach
+└─ External side effect? → USE $effect (with cleanup)
+```
+
+**Why this order matters:**
+
+- **Event handlers** - Run once per user action, predictable timing
+- **$derived** - Lazy, garbage-collectable, can be created anywhere
+- **@attach** - Lifecycle tied to element, auto-cleanup
+- **$effect** - Eager, requires lifecycle management, runs after DOM
+
+## $state - Mutable Reactive State
+
+**Use when:** You need a variable that changes and triggers UI updates
+
+```svelte
+<script>
+	let count = $state(0); // Primitive
+	let user = $state({ name: 'Alex', profile: { age: 30 } }); // Object (DEEP reactive)
+	let items = $state([1, 2, 3]); // Array (DEEP reactive)
+</script>
+```
+
+**Key points:**
+
+- Must be top-level in component
+- Objects/arrays are **deeply reactive** by default - nested mutations
+  trigger updates
+- Mutate nested properties directly: `user.profile.age = 31` ✅
+  (works!)
+- Reassigning also works: `user = { ...user, name: 'Bo' }` ✅
+
+## $derived - Computed Values
+
+**Use when:** Value is calculated from other state
+
+```svelte
+<script>
+	let count = $state(0);
+	let doubled = $derived(count * 2); // Simple computation
+	let message = $derived.by(() => {
+		// Complex computation
+		if (count === 0) return 'Zero';
+		return count > 10 ? 'High' : 'Low';
+	});
+</script>
+```
+
+**Key points:**
+
+- **Can be overridden** - Reassignment allowed (but will recalculate
+  on dependency change)
+- Use `const` to make truly read-only:
+  `const doubled = $derived(count * 2)`
+- Auto-tracks dependencies
+- Use `$derived.by()` for multi-line logic
+- Lazy - only computes when accessed
+
+## $effect - Side Effects (Escape Hatch)
+
+**Use when:** You need external side effects that can't be handled by
+event handlers, $derived, or @attach.
+
+```svelte
+<script>
+	let count = $state(0);
+
+	$effect(() => {
+		console.log(`Count changed to ${count}`);
+		document.title = `Count: ${count}`;
+	});
+</script>
+```
+
+**Legitimate use cases:**
+
+- Logging/analytics
+- Updating external state (localStorage, document.title)
+- Setting up/tearing down subscriptions (WebSocket, intervals)
+- Third-party library integration (when @attach isn't suitable)
+
+**Key points:**
+
+- **Eager execution** - Runs whenever dependencies change, until destroyed
+- **Lifecycle-bound** - Can only be created in effect roots (components)
+- **Runs after DOM** - Not before (use `$effect.pre` for pre-DOM)
+- **No SSR** - Effects don't run during server-side rendering
+- Return cleanup function: `return () => cleanup()`
+- Don't update state that effect depends on (infinite loop!)
+
+**Why $derived is preferred for computed values:**
+
+- $derived is **lazy** - only computes when accessed
+- $derived is **garbage-collectable** - no lifecycle management needed
+- $effect is **eager** - keeps running until destroyed
+
+## $effect.pre - Pre-DOM Effects
+
+**Use when:** You need to run before DOM updates
+
+```svelte
+<script>
+	let element = $state(null);
+
+	$effect.pre(() => {
+		// Runs BEFORE DOM updates
+		// Useful for measuring DOM before changes
+	});
+</script>
+```
+
+## $props - Component Props
+
+**Use when:** Component accepts props from parent
+
+```svelte
+<script>
+	let { name, age = 18, ...rest } = $props(); // Destructure with defaults
+	// OR
+	let props = $props(); // Access as props.name, props.age
+</script>
+
+<p>{name} is {age} years old</p>
+```
+
+**Key points:**
+
+- Use for all component props
+- Supports defaults and rest props
+- Props are reactive automatically
+
+## $bindable - Bindable Props
+
+**Use when:** Parent should be able to bind to this prop
+
+```svelte
+<!-- Child.svelte -->
+<script>
+  let { value = $bindable() } = $props();
+</script>
+
+<input bind:value />
+
+<!-- Parent.svelte -->
+<script>
+  let text = $state('');
+</script>
+
+<Child bind:value={text} />
+<p>You typed: {text}</p>
+```
+
+**Key points:**
+
+- Makes prop two-way bindable
+- Parent can use `bind:propName`
+- Provide default: `$bindable('default')`
+
+## Common Anti-Patterns
+
+### ❌ Using $effect for derived state
+
+```svelte
+<!-- WRONG -->
+<script>
+  let count = $state(0);
+  let doubled = $state(0);
+
+  $effect(() => {
+    doubled = count * 2;  // BAD - use $derived!
+  });
+</script>
+
+<!-- RIGHT -->
+<script>
+  let count = $state(0);
+  let doubled = $derived(count * 2);  // GOOD
+</script>
+```
+
+### ⚠️ Reassigning $derived (Svelte 5.25+)
+
+```svelte
+<!-- WORKS but may be confusing -->
+<script>
+	let count = $state(0);
+	let doubled = $derived(count * 2);
+
+	function reset() {
+		doubled = 0; // Temporarily overrides, but recalculates when count changes
+	}
+</script>
+
+<!-- CLEARER - Use const to prevent reassignment -->
+<script>
+	let count = $state(0);
+	const doubled = $derived(count * 2); // const = truly read-only
+
+	function reset() {
+		// doubled = 0; // TypeScript error - cannot reassign const
+	}
+</script>
+```
+
+**Note:** As of Svelte 5.25+, `$derived` values CAN be reassigned, but
+they'll recalculate when dependencies change. Use `const` to make them
+truly read-only.
+
+### ❌ Infinite loops in $effect
+
+```svelte
+<!-- WRONG -->
+<script>
+	let count = $state(0);
+
+	$effect(() => {
+		count++; // INFINITE LOOP - effect updates count, triggers effect...
+	});
+</script>
+```
+
+### ❌ Using runes inside functions
+
+```svelte
+<!-- WRONG -->
+<script>
+	function createCounter() {
+		let count = $state(0); // ERROR - runes must be top-level
+		return count;
+	}
+</script>
+```
+
+## Performance: $state vs $state.raw
+
+Use `$state.raw()` for **performance optimization** when you don't
+need reactivity:
+
+```svelte
+<script>
+	// Large immutable config (never changes)
+	let config = $state.raw(hugeConfigObject); // No proxy overhead
+
+	// Data you'll replace entirely, not mutate
+	let apiData = $state.raw(data);
+	// Later: apiData = newData; (full replacement)
+
+	// If you WILL mutate nested properties, use $state:
+	let user = $state({ profile: { name: 'Alex' } });
+	user.profile.name = 'Bo'; // Works with deep reactivity
+</script>
+```
+
+**When to use $state.raw():**
+
+- Large, immutable data structures (config, constants)
+- Data you'll fully replace, not incrementally mutate
+- Performance-critical scenarios where proxies are expensive
+
+**When NOT to use $state.raw():**
+
+- You need to mutate the object and see UI updates
+- Data structures are small/medium sized
+
+## Getting Plain Values: $state.snapshot
+
+Extract plain JavaScript values from proxies:
+
+```svelte
+<script>
+	let user = $state({ name: 'Alex', age: 30 });
+
+	function saveToAPI() {
+		const plain = $state.snapshot(user); // Get plain object
+		fetch('/api/users', {
+			body: JSON.stringify(plain),
+		});
+	}
+</script>
+```
+
+## createSubscriber - External Observables
+
+Use `createSubscriber` from `svelte/reactivity` to observe external state
+without `$effect`. Per official best practices: use this instead of
+`$effect` when you need to observe something external to Svelte.
+
+```ts
+import { createSubscriber } from 'svelte/reactivity';
+
+function createLocationStore() {
+	let location = window.location.href;
+
+	const subscribe = createSubscriber((update) => {
+		const handler = () => {
+			location = window.location.href;
+			update();
+		};
+		window.addEventListener('popstate', handler);
+		return () => window.removeEventListener('popstate', handler);
+	});
+
+	return {
+		get href() {
+			subscribe();
+			return location;
+		}
+	};
+}
+```
+
+**When to use:** Wrapping browser APIs, third-party event emitters, or
+any external source that doesn't integrate with Svelte's reactivity
+natively.
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/snippets-vs-slots.md b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/snippets-vs-slots.md
new file mode 100644
index 00000000..beba7a88
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-runes/references/snippets-vs-slots.md
@@ -0,0 +1,137 @@
+# Snippets and Children in Svelte 5
+
+Snippets are reusable chunks of markup. Component children are snippets passed as props and rendered with `{@render ...}`.
+
+## Default Children
+
+```svelte
+<!-- Card.svelte -->
+<script>
+	let { children } = $props();
+</script>
+
+<div class="card">
+	{@render children()}
+</div>
+```
+
+```svelte
+<!-- Usage -->
+<Card>
+	<p>This is card content</p>
+</Card>
+```
+
+## Named Snippets
+
+```svelte
+<!-- Layout.svelte -->
+<script>
+	let { header, footer, children } = $props();
+</script>
+
+<div class="layout">
+	<header>{@render header()}</header>
+	<main>{@render children()}</main>
+	<footer>{@render footer()}</footer>
+</div>
+```
+
+```svelte
+<!-- Usage -->
+<Layout>
+	{#snippet header()}
+		Header content
+	{/snippet}
+
+	{#snippet footer()}
+		Footer content
+	{/snippet}
+
+	Main content
+</Layout>
+```
+
+## Snippet Parameters
+
+```svelte
+<!-- List.svelte -->
+<script>
+	let { items, children } = $props();
+</script>
+
+<ul>
+	{#each items as item (item.id)}
+		<li>{@render children(item)}</li>
+	{/each}
+</ul>
+```
+
+```svelte
+<!-- Usage -->
+<List items={users}>
+	{#snippet children(user)}
+		{user.name}
+	{/snippet}
+</List>
+```
+
+Parameters are explicit function arguments and work well with TypeScript.
+
+## Optional Snippets and Fallbacks
+
+```svelte
+<script>
+	let { header, children } = $props();
+</script>
+
+<div class="card">
+	<h2>{@render header?.() ?? 'Default Title'}</h2>
+	{@render children?.()}
+</div>
+```
+
+Use optional chaining for snippets that may not be passed.
+
+## Reusable Local Snippets
+
+```svelte
+<script>
+	let items = $state(['Apple', 'Banana', 'Cherry']);
+</script>
+
+{#snippet list_item(text)}
+	<li class="item">{text}</li>
+{/snippet}
+
+<ul>
+	{#each items as item (item)}
+		{@render list_item(item)}
+	{/each}
+</ul>
+```
+
+## Exportable Snippets
+
+A top-level snippet that does not reference instance state can be exported from module context.
+
+```svelte
+<script module>
+	export { icon };
+</script>
+
+{#snippet icon(name)}
+	<span class="icon icon-{name}" aria-hidden="true"></span>
+{/snippet}
+```
+
+## Best Practices
+
+- Declare snippets in the template, not inside `<script>`.
+- Destructure snippet props with `$props()`.
+- Render snippets with `{@render snippet_name(args)}`.
+- Use optional chaining for optional snippets.
+- Key each blocks with stable identifiers when rendering lists.
+- Keep snippets small and focused; extract a component when state/lifecycle grows.
+
+**Last verified:** 2026-05-14
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-styling/SKILL.md b/packages/autoskills/skills-registry/svelte-runes/svelte-styling/SKILL.md
new file mode 100644
index 00000000..ece14b78
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-styling/SKILL.md
@@ -0,0 +1,89 @@
+---
+name: svelte-styling
+# IMPORTANT: Keep description on ONE line for agent compatibility
+# prettier-ignore
+description: "Svelte CSS styling patterns. Use for scoped styles, CSS custom properties, style: directive, :global, or styling child components."
+metadata:
+  last_updated: "2026-05-14"
+  verified_against: "Svelte 5 official docs and current local skill refresh"
+---
+
+# Svelte Styling
+
+## Quick Start
+
+**JS vars in CSS:** Use `style:` directive to set CSS custom properties
+from JavaScript.
+
+```svelte
+<script>
+	let columns = $state(3);
+</script>
+
+<div style:--columns={columns}>
+	{@render children()}
+</div>
+
+<style>
+	div {
+		display: grid;
+		grid-template-columns: repeat(var(--columns), 1fr);
+	}
+</style>
+```
+
+## Styling Child Components
+
+**Preferred:** Pass CSS custom properties as component props:
+
+```svelte
+<!-- Parent.svelte -->
+<Child --color="red" --spacing="1rem" />
+
+<!-- Child.svelte -->
+<h1>Hello</h1>
+
+<style>
+	h1 {
+		color: var(--color, blue);
+		margin: var(--spacing, 0);
+	}
+</style>
+```
+
+**Fallback:** Use `:global` when custom properties aren't possible
+(e.g., library components):
+
+```svelte
+<div>
+	<LibraryComponent />
+</div>
+
+<style>
+	div :global {
+		h1 { color: red; }
+	}
+</style>
+```
+
+## Reference Files
+
+- [styling-patterns.md](references/styling-patterns.md) - Complete CSS
+  patterns and techniques
+
+## Notes
+
+- All `<style>` blocks are scoped to the component by default
+- Use `style:` directive, not inline style strings, for dynamic values
+- Prefer CSS custom properties over `:global` for child styling
+- Prefer class arrays/objects in `class={...}` for conditional classes
+- **Last verified:** 2026-05-14
+
+<!--
+PROGRESSIVE DISCLOSURE GUIDELINES:
+- Keep this file ~50 lines total (max ~150 lines)
+- Use 1-2 code blocks only (recommend 1)
+- Keep description <200 chars for Level 1 efficiency
+- Move detailed docs to references/ for Level 3 loading
+- This is Level 2 - quick reference ONLY, not a manual
+-->
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-styling/references/styling-patterns.md b/packages/autoskills/skills-registry/svelte-runes/svelte-styling/references/styling-patterns.md
new file mode 100644
index 00000000..e7463c0a
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-styling/references/styling-patterns.md
@@ -0,0 +1,146 @@
+# Svelte CSS Styling Patterns
+
+## Scoped Styles
+
+All CSS in `<style>` is scoped to the component automatically. Svelte adds unique class selectors at compile time.
+
+```svelte
+<h1>Hello</h1>
+
+<style>
+	h1 {
+		color: blue;
+	}
+</style>
+```
+
+## `style:` Directive
+
+Set individual CSS properties dynamically. Prefer this over inline style strings.
+
+```svelte
+<script>
+	let color = $state('red');
+	let size = $state(16);
+</script>
+
+<p style:color style:font-size="{size}px">Styled text</p>
+
+<div style:--theme-color={color} style:--columns={3}>
+	{@render children()}
+</div>
+
+<style>
+	div {
+		background: var(--theme-color);
+		grid-template-columns: repeat(var(--columns), 1fr);
+	}
+</style>
+```
+
+**Why:** `style:` directives are type-checked, support shorthand, and merge cleanly with static styles.
+
+## CSS Custom Properties for Child Components
+
+The preferred way to style child components from a parent is to pass CSS custom properties.
+
+```svelte
+<!-- Parent.svelte -->
+<Card --bg="navy" --text="white" --radius="8px" />
+
+<!-- Card.svelte -->
+<script>
+	let { children } = $props();
+</script>
+
+<div class="card">
+	{@render children()}
+</div>
+
+<style>
+	.card {
+		background: var(--bg, #fff);
+		color: var(--text, #000);
+		border-radius: var(--radius, 4px);
+	}
+</style>
+```
+
+## `:global` Selectors
+
+Use global selectors sparingly. Prefer scoped `:global` inside a parent selector.
+
+```svelte
+<div class="wrapper">
+	<LibraryComponent />
+</div>
+
+<style>
+	.wrapper :global {
+		h1 {
+			color: red;
+		}
+		.library-class {
+			padding: 1rem;
+		}
+	}
+</style>
+```
+
+Avoid broad global selectors unless you are intentionally writing app-level CSS.
+
+## Conditional Classes
+
+Prefer class arrays/objects in the `class` attribute for conditional classes.
+
+```svelte
+<script>
+	import clsx from 'clsx';
+
+	let active = $state(false);
+	let enabled = $state(true);
+</script>
+
+<button
+	class={clsx('button', { active, disabled: !enabled })}
+	onclick={() => active = !active}
+>
+	Toggle
+</button>
+```
+
+You can also use arrays/objects directly where your tooling supports Svelte's class value handling:
+
+```svelte
+<div class={['card', { selected, disabled: !enabled }]}>...</div>
+```
+
+## Dynamic Styling Pattern
+
+```svelte
+<script>
+	let dark = $state(false);
+</script>
+
+<div class={['panel', { dark }]} style:--bg={dark ? '#1a1a1a' : '#fff'}>
+	{@render children()}
+</div>
+
+<style>
+	.panel {
+		background: var(--bg);
+		transition: background 0.3s;
+	}
+</style>
+```
+
+## Best Practices Summary
+
+1. **Scoped by default** — component `<style>` only affects that component
+2. **Use `style:`** — not inline style strings for dynamic values
+3. **Use CSS custom properties** — preferred for styling child components
+4. **Scope `:global`** — wrap in a parent selector when possible
+5. **Use class arrays/objects** — preferred for conditional classes
+6. **Avoid broad `:global`** — it can leak styles across the app
+
+**Last verified:** 2026-05-14
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/SKILL.md b/packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/SKILL.md
new file mode 100644
index 00000000..45c3dbe9
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/SKILL.md
@@ -0,0 +1,80 @@
+---
+name: svelte-template-directives
+# prettier-ignore
+description: "Svelte template directive guidance. Use when working with snippets, attachments, dynamic HTML, declaration tags, debugging tags, or global DOM events."
+metadata:
+  last_updated: "2026-05-31"
+  verified_against: "Svelte 5 official docs and sveltejs/svelte#18282"
+---
+
+# Svelte Template Directives
+
+## @attach (Svelte 5.29+)
+
+**The reactive alternative to `use:` actions.** Re-runs when dependencies
+change, passes through components via spread, supports cleanup functions.
+
+```svelte
+<script>
+	import ImageZoom from 'js-image-zoom';
+
+	function useZoom(options) {
+		return (element) => {
+			new ImageZoom(element, options);
+			return () => console.log('cleanup');
+		};
+	}
+</script>
+
+<!-- Re-runs if options changes (use: wouldn't!) -->
+<figure {@attach useZoom({ width: 400 })}>
+	<img src="photo.jpg" alt="zoomable" />
+</figure>
+```
+
+## Quick Reference
+
+| Directive                   | Purpose                        | Reactive? |
+| --------------------------- | ------------------------------ | --------- |
+| `{@attach}`                 | DOM manipulation, 3rd-party    | Yes       |
+| `{@html}`                   | Render raw HTML strings        | Yes       |
+| `{@render}`                 | Render snippets                | Yes       |
+| `{let ...}` / `{const ...}` | Local declarations in markup   | N/A       |
+| `{@debug}`                  | Pause debugger on value change | N/A       |
+| `{#each (key)}`             | Keyed iteration (always key!)  | Yes       |
+| `<svelte:window>`           | Window event listeners         | N/A       |
+
+## @attach vs use: Actions
+
+| Feature               | `use:`  | `@attach`           |
+| --------------------- | ------- | ------------------- |
+| Re-runs on arg change | No      | **Yes**             |
+| Composable            | Limited | **Fully**           |
+| Pass through props    | Manual  | **Auto via spread** |
+| Convert legacy        | N/A     | `fromAction()`      |
+
+## Reference Files
+
+- [attach-patterns.md](references/attach-patterns.md) - Real-world @attach
+  examples
+- [other-directives.md](references/other-directives.md) - @html, @render,
+  declaration tags, @debug
+
+## Notes
+
+- `@attach` requires Svelte 5.29+
+- Use `fromAction` from `svelte/attachments` to convert legacy actions
+- Attachments pass through wrapper components when you spread props
+- Always use keyed each blocks — never use index as key
+- Use `<svelte:window>`/`<svelte:document>` for global events, not `$effect`
+- Use `{const ...}` / `{let ...}` declaration tags for local markup variables; `{@const ...}` is legacy syntax.
+- **Last verified:** 2026-05-31
+
+<!--
+PROGRESSIVE DISCLOSURE GUIDELINES:
+- Keep this file ~50 lines total (max ~150 lines)
+- Use 1-2 code blocks only (recommend 1)
+- Keep description <200 chars for Level 1 efficiency
+- Move detailed docs to references/ for Level 3 loading
+- This is Level 2 - quick reference ONLY, not a manual
+-->
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/references/attach-patterns.md b/packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/references/attach-patterns.md
new file mode 100644
index 00000000..f007e3f4
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/references/attach-patterns.md
@@ -0,0 +1,339 @@
+# @attach Patterns
+
+> Available in Svelte 5.29+
+
+## Why @attach Over use: Actions?
+
+Attachments are **fully reactive**. When dependencies change, the attachment
+re-runs automatically. Actions don't do this - they only run once on mount.
+
+```svelte
+<!-- use: - runs ONCE, ignores content changes -->
+<button use:tooltip={content}>Won't update</button>
+
+<!-- @attach - re-runs when content changes -->
+<button {@attach tooltip(content)}>Updates!</button>
+```
+
+## Pattern 1: Third-Party Library Integration
+
+The most common use case - integrating DOM-manipulating libraries like image
+zoom, tooltips, editors, etc.
+
+### ImageZoom Example
+
+```svelte
+<script>
+	import ImageZoom from 'js-image-zoom';
+
+	const options = { width: 400, zoomWidth: 500 };
+
+	function useZoom(dom) {
+		new ImageZoom(dom, options);
+		return () => {
+			console.log('cleaning up');
+		};
+	}
+</script>
+
+<figure {@attach useZoom}>
+	<img src="photo.jpg" alt="zoomable photo" />
+</figure>
+```
+
+### Tippy.js Tooltips
+
+```svelte
+<script>
+	import tippy from 'tippy.js';
+
+	function tooltip(content) {
+		return (element) => {
+			const instance = tippy(element, { content });
+			return instance.destroy;
+		};
+	}
+
+	let tip = $state('Hello!');
+</script>
+
+<!-- Tooltip content updates reactively -->
+<button {@attach tooltip(tip)}>Hover me</button>
+
+<input bind:value={tip} placeholder="Change tooltip" />
+```
+
+## Pattern 2: Canvas Drawing
+
+Perfect for canvas where you need reactive updates without recreating the
+context.
+
+```svelte
+<script>
+	let color = $state('#ff0000');
+	let size = $state(50);
+</script>
+
+<canvas
+	width="200"
+	height="200"
+	{@attach (canvas) => {
+		const ctx = canvas.getContext('2d');
+
+		// This inner effect re-runs on color/size change
+		// but canvas context is preserved
+		$effect(() => {
+			ctx.clearRect(0, 0, canvas.width, canvas.height);
+			ctx.fillStyle = color;
+			ctx.fillRect(
+				(canvas.width - size) / 2,
+				(canvas.height - size) / 2,
+				size,
+				size
+			);
+		});
+	}}
+/>
+
+<input type="color" bind:value={color} />
+<input type="range" bind:value={size} min="10" max="100" />
+```
+
+## Pattern 3: Component Pass-Through
+
+Attachments automatically pass through wrapper components when you spread props.
+This enables "augmented element" patterns.
+
+```svelte
+<!-- Button.svelte -->
+<script>
+	let { children, ...props } = $props();
+</script>
+
+<button {...props}>
+	{@render children?.()}
+</button>
+```
+
+```svelte
+<!-- App.svelte -->
+<script>
+	import Button from './Button.svelte';
+	import { tooltip } from './attachments.js';
+</script>
+
+<!-- The attachment passes through to the inner <button>! -->
+<Button {@attach tooltip('Click me for help')}>
+	Help
+</Button>
+```
+
+## Pattern 4: Attachment Factories
+
+Factory functions return attachment implementations, enabling parameterized
+behavior.
+
+```svelte
+<script>
+	function highlight(color) {
+		return (element) => {
+			const original = element.style.backgroundColor;
+			element.style.backgroundColor = color;
+
+			return () => {
+				element.style.backgroundColor = original;
+			};
+		};
+	}
+
+	let isActive = $state(false);
+</script>
+
+<!-- Attachment recreates when isActive changes -->
+{#if isActive}
+	<div {@attach highlight('yellow')}>Highlighted!</div>
+{/if}
+```
+
+## Pattern 5: Avoiding Expensive Re-runs
+
+For expensive setup work, pass data via accessor function and read it in a child
+effect.
+
+```svelte
+<script>
+	function expensiveChart(getData) {
+		return (node) => {
+			// Expensive - runs ONCE
+			const chart = createComplexChart(node);
+
+			// Cheap - re-runs on data change
+			$effect(() => {
+				chart.update(getData());
+			});
+
+			return () => chart.destroy();
+		};
+	}
+
+	let data = $state([1, 2, 3]);
+</script>
+
+<!-- Pass accessor function, not the data directly -->
+<div {@attach expensiveChart(() => data)}>Chart</div>
+```
+
+## Pattern 6: Converting Legacy Actions
+
+Use `fromAction` to convert existing action libraries to attachments.
+
+```svelte
+<script>
+	import { fromAction } from 'svelte/attachments';
+	import { someAction } from 'some-legacy-library';
+
+	const attached = fromAction(someAction);
+</script>
+
+<!-- Now works as an attachment with full reactivity -->
+<div {@attach attached(options)}>...</div>
+```
+
+## Pattern 7: Multiple Attachments
+
+Elements can have any number of attachments.
+
+```svelte
+<button
+	{@attach tooltip('Help text')}
+	{@attach trackClicks}
+	{@attach highlight(isActive ? 'yellow' : 'transparent')}
+>
+	Multi-attached button
+</button>
+```
+
+## Pattern 8: Inline Attachments
+
+For one-off cases, define attachments inline.
+
+```svelte
+<div
+	{@attach (el) => {
+		console.log('mounted:', el);
+		return () => console.log('unmounted');
+	}}
+>
+	Lifecycle logging
+</div>
+```
+
+## Pattern 9: DOM-Controlling Libraries (ProseMirror, etc.)
+
+For libraries that want to control their own DOM segment, combine @attach with
+the imperative component API.
+
+```svelte
+<script>
+	import { mount, unmount } from 'svelte';
+	import MyComponent from './MyComponent.svelte';
+
+	function proseMirrorNodeView(node) {
+		return (dom) => {
+			// ProseMirror controls this DOM node
+			// but we can mount Svelte components inside it
+			const component = mount(MyComponent, {
+				target: dom,
+				props: { data: node.attrs }
+			});
+
+			return () => unmount(component);
+		};
+	}
+</script>
+```
+
+## Pattern 10: Registering Elements with Global State
+
+Use @attach to register DOM elements with state classes. This avoids $effect
+sync loops and is cleaner than bind:this chains.
+
+```ts
+// modal-state.svelte.ts
+class ModalState {
+  dialog: HTMLDialogElement | null = null;
+  input: HTMLInputElement | null = null;
+  is_open = $state(false);
+
+  // Attach functions return cleanup
+  register = (el: HTMLDialogElement) => {
+    this.dialog = el;
+    return () => {
+      this.dialog = null;
+    };
+  };
+
+  register_input = (el: HTMLInputElement) => {
+    this.input = el;
+    return () => {
+      this.input = null;
+    };
+  };
+
+  open() {
+    if (!this.dialog?.open) {
+      this.is_open = true;
+      this.dialog?.showModal();
+      this.input?.focus();
+    }
+  }
+
+  close() {
+    this.is_open = false;
+    this.dialog?.close();
+  }
+
+  toggle() {
+    this.is_open ? this.close() : this.open();
+  }
+}
+
+export const modal_state = new ModalState();
+```
+
+```svelte
+<!-- Modal.svelte -->
+<script>
+	import { modal_state } from './modal-state.svelte';
+</script>
+
+<dialog
+	{@attach modal_state.register}
+	onclose={modal_state.close}
+>
+	<input {@attach modal_state.register_input} />
+</dialog>
+```
+
+```svelte
+<!-- Anywhere else - no component ref needed -->
+<script>
+	import { modal_state } from './modal-state.svelte';
+</script>
+
+<button onclick={modal_state.toggle}>Open Modal</button>
+```
+
+**Benefits:**
+
+- No $effect needed for state/DOM sync
+- State controls element directly via imperative methods
+- Clean cleanup on unmount
+- Any component can open/close without bind:this chains
+- Avoids event loops from `dialog.close()` firing `onclose`
+
+## When to Still Use `use:` Actions
+
+- Legacy code/libraries not yet updated
+- When you specifically DON'T want re-runs on argument change
+- Simple one-time DOM setup with no reactive dependencies
diff --git a/packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/references/other-directives.md b/packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/references/other-directives.md
new file mode 100644
index 00000000..b1019d09
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/svelte-template-directives/references/other-directives.md
@@ -0,0 +1,235 @@
+# Other Template Directives
+
+## {@html ...}
+
+Renders raw HTML strings. **Use with caution** - never render untrusted content.
+
+```svelte
+<script>
+	let htmlContent = '<strong>Bold</strong> and <em>italic</em>';
+</script>
+
+{@html htmlContent}
+```
+
+### Security Warning
+
+Always sanitize user-provided HTML:
+
+```svelte
+<script>
+	import DOMPurify from 'dompurify';
+
+	let userContent = $state('');
+	const sanitized = $derived(DOMPurify.sanitize(userContent));
+</script>
+
+{@html sanitized}
+```
+
+### Common Use Cases
+
+- Rendering markdown converted to HTML
+- CMS content with formatting
+- Syntax-highlighted code blocks
+
+## {@render ...}
+
+Renders snippets - Svelte 5's replacement for slots.
+
+```svelte
+<script>
+	let { header, children } = $props();
+</script>
+
+<div class="card">
+	{#if header}
+		<header>{@render header()}</header>
+	{/if}
+	<main>{@render children?.()}</main>
+</div>
+```
+
+### With Parameters
+
+Snippets can receive parameters:
+
+```svelte
+<script>
+	let { row } = $props();
+	let items = $state([{ name: 'Apple' }, { name: 'Banana' }]);
+</script>
+
+{#each items as item}
+	{@render row(item)}
+{/each}
+```
+
+```svelte
+<!-- Usage -->
+<List>
+	{#snippet row(item)}
+		<li>{item.name}</li>
+	{/snippet}
+</List>
+```
+
+### Optional Snippets
+
+Use optional chaining for optional snippets:
+
+```svelte
+{@render footer?.()}
+```
+
+## Declaration tags: `{let ...}` / `{const ...}`
+
+Declares local variables within markup. Useful in `{#each}` and `{#if}`.
+Use `let` or `const` only; `var`, `function`, and trailing semicolons are invalid.
+`{@const ...}` is legacy syntax.
+
+```svelte
+{#each items as item}
+	{const full_name = `${item.first_name} ${item.last_name}`}
+	{const is_long_name = full_name.length > 20}
+
+	<div class={[{ truncate: is_long_name }]}>
+		{full_name}
+	</div>
+{/each}
+```
+
+### Why Use Declaration Tags?
+
+- Avoids recalculating values multiple times in a block
+- Makes complex expressions more readable
+- Scoped to the block - doesn't pollute component scope
+
+## {@debug ...}
+
+Pauses execution and opens devtools when specified values change.
+
+```svelte
+<script>
+	let count = $state(0);
+	let items = $state([]);
+</script>
+
+{@debug count, items}
+
+<button onclick={() => count++}>Increment</button>
+```
+
+### Tips
+
+- Remove `{@debug}` before production
+- Use with specific variables, not entire objects
+- Combine with browser devtools for best debugging experience
+
+### Debug Without Variables
+
+```svelte
+{@debug}
+```
+
+Pauses on every update (rarely useful, but available).
+
+## Keyed Each Blocks
+
+Per official Svelte best practices: always use keyed each blocks for
+better performance.
+
+### Basic Keyed Each
+
+```svelte
+{#each items as item (item.id)}
+	<div>{item.name}</div>
+{/each}
+```
+
+**Key must uniquely identify the object.** Do NOT use the index:
+
+```svelte
+<!-- WRONG - index as key -->
+{#each items as item, i (i)}
+	<div>{item.name}</div>
+{/each}
+
+<!-- RIGHT - unique identifier -->
+{#each items as item (item.id)}
+	<div>{item.name}</div>
+{/each}
+```
+
+### Why Keys Matter
+
+Without keys, Svelte updates existing DOM nodes in place when the array
+changes. With keys, Svelte can surgically insert, remove, or reorder
+items instead.
+
+**Without key:** Removing item 2 from [A, B, C] updates node 2 to show
+C's data and removes the last node.
+
+**With key:** Removing item B actually removes B's DOM node, leaving A
+and C untouched.
+
+### Avoid Destructuring with bind
+
+Per best practices: avoid destructuring if you need to mutate the item.
+
+```svelte
+<!-- WRONG - destructured value is disconnected from original -->
+{#each items as { count } (item.id)}
+	<input bind:value={count} /> <!-- Won't update the original item -->
+{/each}
+
+<!-- RIGHT - reference the item directly -->
+{#each items as item (item.id)}
+	<input bind:value={item.count} /> <!-- Updates the original -->
+{/each}
+```
+
+## Window and Document Events
+
+Per official best practices: use `<svelte:window>` and
+`<svelte:document>` for window/document event listeners. Avoid
+`onMount` or `$effect` for this.
+
+```svelte
+<svelte:window onkeydown={handleKeydown} onscroll={handleScroll} />
+<svelte:document onvisibilitychange={handleVisibility} />
+```
+
+### Common Events
+
+```svelte
+<!-- Keyboard shortcuts -->
+<svelte:window onkeydown={(e) => {
+	if (e.key === 'Escape') closeModal();
+	if (e.ctrlKey && e.key === 's') { e.preventDefault(); save(); }
+}} />
+
+<!-- Online/offline detection -->
+<svelte:window ononline={() => status = 'online'} onoffline={() => status = 'offline'} />
+
+<!-- Responsive design -->
+<svelte:window
+	bind:innerWidth={width}
+	bind:innerHeight={height}
+/>
+```
+
+### Bindable Window Properties
+
+```svelte
+<svelte:window
+	bind:innerWidth
+	bind:innerHeight
+	bind:scrollX
+	bind:scrollY
+	bind:online
+/>
+```
+
+**Why not $effect:** `<svelte:window>` automatically cleans up listeners
+when the component is destroyed. No manual cleanup needed.
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/SKILL.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/SKILL.md
new file mode 100644
index 00000000..8198cd0d
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/SKILL.md
@@ -0,0 +1,87 @@
+---
+name: sveltekit-data-flow
+# IMPORTANT: Keep description on ONE line for agent compatibility
+# prettier-ignore
+description: "SvelteKit data flow guidance. Use when working with load functions, form actions, server/client boundaries, serialization, or invalidation."
+metadata:
+  last_updated: "2026-06-08"
+  verified_against: "Svelte 5/Kit docs and sveltejs/kit#15934"
+---
+
+# SvelteKit Data Flow
+
+## Quick Start
+
+**Environment variables:** Prefer explicit env vars (`src/env.ts` + `$app/env/private|public`) when the experimental flag is enabled.
+
+**Which file?** Server-only (DB/secrets): `+page.server.ts` |
+Universal (runs both): `+page.ts` | API: `+server.ts`
+
+**Load decision:** Need server resources? → server load | Need client
+APIs? → universal load
+
+**Form actions:** Always `+page.server.ts`. Return `fail()` for
+errors, throw `redirect()` to navigate, throw `error()` for failures.
+
+## Example
+
+```typescript
+// +page.server.ts
+import { fail, redirect } from '@sveltejs/kit';
+
+export const load = async ({ locals }) => {
+	const user = await db.users.get(locals.userId);
+	return { user }; // Must be JSON-serializable
+};
+
+export const actions = {
+	default: async ({ request }) => {
+		const data = await request.formData();
+		const email = data.get('email');
+
+		if (!email) return fail(400, { email, missing: true });
+
+		await updateEmail(email);
+		throw redirect(303, '/success');
+	},
+};
+```
+
+## Reference Files
+
+- [load-functions.md](references/load-functions.md) - Server vs
+  universal
+- [form-actions.md](references/form-actions.md) - Form handling
+  patterns
+- [serialization.md](references/serialization.md) - What can/can't
+  serialize
+- [error-redirect-handling.md](references/error-redirect-handling.md) -
+  fail/redirect/error
+- [client-auth-invalidation.md](references/client-auth-invalidation.md) -
+  invalidateAll() after client-side auth
+- [explicit-environment-variables.md](references/explicit-environment-variables.md) -
+  typed, validated env vars
+
+## Notes
+
+- Server load → universal load via `data` param | ALWAYS
+  `throw redirect()/error()`
+- No class instances/functions from server load (not serializable)
+- `$app/env/private` is server-only; only mark genuinely safe values as public
+- **Last verified:** 2026-06-08
+
+<!--
+PROGRESSIVE DISCLOSURE GUIDELINES:
+- Keep this file ~50 lines total (max ~150 lines)
+- Use 1-2 code blocks only (recommend 1)
+- Keep description <200 chars for Level 1 efficiency
+- Move detailed docs to references/ for Level 3 loading
+- This is Level 2 - quick reference ONLY, not a manual
+
+LLM WORKFLOW (when editing this file):
+1. Write/edit SKILL.md
+2. Format (if formatter available)
+3. Run: npx skills add . --list
+4. If the skill is not discovered, check SKILL.md frontmatter formatting
+5. Validate again to confirm
+-->
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/client-auth-invalidation.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/client-auth-invalidation.md
new file mode 100644
index 00000000..d64c8848
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/client-auth-invalidation.md
@@ -0,0 +1,125 @@
+# Client-Side Auth Invalidation
+
+When using client-side auth libraries (Better Auth, Firebase, Supabase client),
+layout server data doesn't auto-refresh after login/logout.
+
+## The Problem
+
+```typescript
+// signin/+page.svelte - BROKEN
+async function handle_signin() {
+  await auth_client.signIn.email({ email, password });
+  goto('/');  // Layout still shows "logged out"
+}
+```
+
+**Why?** Client-side navigation (`goto()`) doesn't re-run server load functions.
+The session cookie is set, but `+layout.server.ts` data is stale.
+
+## Solution A: Inline Invalidation (Simple)
+
+Call `invalidateAll()` after auth state change:
+
+```typescript
+// signin/+page.svelte
+import { goto, invalidateAll } from '$app/navigation';
+
+async function handle_signin() {
+  const result = await auth_client.signIn.email({ email, password });
+  if (result.error) return;
+
+  await invalidateAll();  // Re-runs ALL load functions
+  goto('/');
+}
+
+// signout handler
+async function handle_signout() {
+  await auth_client.signOut();
+  await invalidateAll();
+}
+```
+
+**Use when:** Single auth entry point, simple apps.
+
+## Solution B: Auth State Listener (Robust)
+
+Set up a listener in root layout that auto-invalidates on auth changes:
+
+```svelte
+<!-- +layout.svelte -->
+<script>
+  import { invalidateAll } from '$app/navigation';
+  import { onMount } from 'svelte';
+  import { auth_client } from '$lib/auth-client';
+
+  onMount(() => {
+    // Listen for auth state changes
+    const unsubscribe = auth_client.onAuthStateChange(() => {
+      invalidateAll();
+    });
+
+    return unsubscribe;
+  });
+</script>
+```
+
+**Use when:** Multiple auth flows (OAuth, magic links, etc.), complex apps.
+
+## Common Mistakes
+
+### Not awaiting invalidateAll()
+
+```typescript
+// WRONG - race condition
+invalidateAll();
+goto('/');
+
+// RIGHT - wait for data refresh
+await invalidateAll();
+goto('/');
+```
+
+### Destructuring layout data
+
+```svelte
+<!-- WRONG - static snapshot -->
+<script>
+  let { data } = $props();
+  const { user } = data;  // Never updates after invalidateAll()
+</script>
+
+<!-- RIGHT - reactive access -->
+<script>
+  let { data } = $props();
+</script>
+
+{data.user?.email}
+```
+
+## When invalidateAll() Runs
+
+Per [Svelte docs](https://svelte.dev/tutorial/kit/invalidate-all):
+
+> `invalidateAll()` is the nuclear option - it re-runs ALL load functions
+> for the current page, regardless of dependencies.
+
+This includes:
+- `+layout.server.ts` (all levels)
+- `+layout.ts` (all levels)
+- `+page.server.ts`
+- `+page.ts`
+
+## Comparison with Server-Side Auth
+
+| Approach | Auth Location | Invalidation |
+|----------|--------------|--------------|
+| Form actions | Server (`+page.server.ts`) | Automatic (page reload) |
+| Client auth | Browser (auth_client) | Manual (`invalidateAll()`) |
+
+Form actions with `throw redirect()` cause a full navigation, which
+naturally re-runs load functions. Client-side auth with `goto()` does not.
+
+## See Also
+
+- [error-redirect-handling.md](error-redirect-handling.md) - Server-side redirects
+- [load-functions.md](load-functions.md) - Server vs universal loads
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/error-redirect-handling.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/error-redirect-handling.md
new file mode 100644
index 00000000..1ff6e1c7
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/error-redirect-handling.md
@@ -0,0 +1,407 @@
+# Error & Redirect Handling: fail(), redirect(), error()
+
+## The Three Ways to Handle Failures
+
+| Function     | When             | Must Throw? | Use Case                              |
+| ------------ | ---------------- | ----------- | ------------------------------------- |
+| `fail()`     | Validation error | No (return) | Form validation errors                |
+| `redirect()` | Navigate user    | **YES**     | After successful action               |
+| `error()`    | Fatal error      | **YES**     | Unauthorized, not found, server error |
+
+## fail() - Validation Errors
+
+**Return** (don't throw) from form actions to show validation errors:
+
+```typescript
+import { fail } from '@sveltejs/kit';
+
+export const actions = {
+	default: async ({ request }) => {
+		const data = await request.formData();
+		const email = data.get('email');
+
+		// Validation failed - return fail()
+		if (!email || !email.includes('@')) {
+			return fail(400, {
+				email,
+				error: 'Invalid email',
+				missing: !email,
+			});
+		}
+
+		// Success - process and maybe redirect
+		await processEmail(email);
+		throw redirect(303, '/success');
+	},
+};
+```
+
+```svelte
+<!-- +page.svelte -->
+<script>
+	let { form } = $props(); // Contains fail() return value
+</script>
+
+{#if form?.error}
+	<p class="error">{form.error}</p>
+{/if}
+
+<form method="POST">
+	<input name="email" value={form?.email ?? ''} />
+
+	{#if form?.missing}
+		<span>Email is required</span>
+	{/if}
+
+	<button>Submit</button>
+</form>
+```
+
+**Key points:**
+
+- **Return** fail() (don't throw)
+- Status code (400 = bad request)
+- Return validation errors + form data to repopulate fields
+- Accessible via `form` prop in page component
+- Page stays on same URL
+
+## redirect() - Navigation
+
+**Throw** redirect() to navigate user to another page:
+
+```typescript
+import { redirect } from '@sveltejs/kit';
+
+export const actions = {
+	login: async ({ request, cookies }) => {
+		const data = await request.formData();
+
+		const user = await authenticate(data);
+
+		if (!user) {
+			return fail(401, { error: 'Invalid credentials' });
+		}
+
+		cookies.set('session', user.sessionToken, { path: '/' });
+
+		// Success - redirect to dashboard
+		throw redirect(303, '/dashboard'); // MUST throw
+	},
+};
+```
+
+**Status codes:**
+
+- `303` - See Other (recommended for POST → GET redirect)
+- `301` - Moved Permanently
+- `302` - Found (temporary redirect)
+- `307` - Temporary Redirect (preserves method)
+- `308` - Permanent Redirect (preserves method)
+
+**Use 303** for most cases (especially after form submission).
+
+**Key points:**
+
+- **MUST throw** (not return)
+- Use status 303 for form actions
+- Can redirect to external URLs
+- Can use relative paths: `throw redirect(303, '..')`
+
+## error() - Fatal Errors
+
+**Throw** error() for unrecoverable errors (auth, not found, server
+error):
+
+```typescript
+import { error } from '@sveltejs/kit';
+
+export const load = async ({ params, locals }) => {
+	const post = await db.query.posts.findFirst({
+		where: eq(posts.id, params.id),
+	});
+
+	if (!post) {
+		throw error(404, 'Post not found'); // MUST throw
+	}
+
+	if (post.authorId !== locals.userId) {
+		throw error(403, 'Forbidden'); // MUST throw
+	}
+
+	return { post };
+};
+```
+
+**Common status codes:**
+
+- `400` - Bad Request
+- `401` - Unauthorized (not logged in)
+- `403` - Forbidden (logged in but no permission)
+- `404` - Not Found
+- `500` - Internal Server Error
+
+**With custom error page:**
+
+```typescript
+// src/routes/posts/[id]/+page.server.ts
+import { error } from '@sveltejs/kit';
+
+export const load = async ({ params }) => {
+	const post = await getPost(params.id);
+
+	if (!post) {
+		throw error(404, {
+			message: 'Post not found',
+			postId: params.id,
+		});
+	}
+
+	return { post };
+};
+```
+
+```svelte
+<!-- src/routes/posts/[id]/+error.svelte -->
+<script>
+	import { page } from '$app/stores';
+</script>
+
+<h1>{$page.status}: {$page.error.message}</h1>
+
+{#if $page.error.postId}
+	<p>Could not find post with ID: {$page.error.postId}</p>
+{/if}
+```
+
+**Key points:**
+
+- **MUST throw** (not return)
+- Renders closest `+error.svelte` file
+- Accessible via `$page.status` and `$page.error`
+- Stops load function execution
+- Use for authorization, not found, server errors
+
+## Common Mistakes
+
+### ❌ Not Throwing redirect()
+
+```typescript
+// WRONG
+export const actions = {
+	default: async () => {
+		redirect(303, '/home'); // DOESN'T WORK
+	},
+};
+
+// RIGHT
+export const actions = {
+	default: async () => {
+		throw redirect(303, '/home'); // MUST throw
+	},
+};
+```
+
+### ❌ Not Throwing error()
+
+```typescript
+// WRONG
+export const load = async () => {
+	error(404, 'Not found'); // DOESN'T WORK
+};
+
+// RIGHT
+export const load = async () => {
+	throw error(404, 'Not found'); // MUST throw
+};
+```
+
+### ❌ Throwing fail()
+
+```typescript
+// WRONG
+export const actions = {
+	default: async () => {
+		throw fail(400, { error: 'Bad' }); // Don't throw
+	},
+};
+
+// RIGHT
+export const actions = {
+	default: async () => {
+		return fail(400, { error: 'Bad' }); // Return
+	},
+};
+```
+
+### ❌ Catching redirect Without Rethrowing
+
+```typescript
+// WRONG
+export const actions = {
+	default: async () => {
+		try {
+			await doSomething();
+			throw redirect(303, '/success');
+		} catch (e) {
+			console.error(e); // Catches redirect - it won't work!
+			return fail(500, { error: 'Failed' });
+		}
+	},
+};
+
+// RIGHT
+import { isRedirect } from '@sveltejs/kit';
+
+export const actions = {
+	default: async () => {
+		try {
+			await doSomething();
+			throw redirect(303, '/success');
+		} catch (e) {
+			if (isRedirect(e)) throw e; // Rethrow redirect
+			console.error(e);
+			return fail(500, { error: 'Failed' });
+		}
+	},
+};
+```
+
+## Decision Tree
+
+```
+Problem in form action?
+├─ Validation error (show to user) → return fail(400, { errors })
+├─ Success (navigate) → throw redirect(303, '/success')
+└─ Fatal error (auth, not found) → throw error(403, 'Forbidden')
+
+Problem in load function?
+├─ Data not found → throw error(404, 'Not found')
+├─ Unauthorized → throw error(401, 'Unauthorized')
+├─ Forbidden → throw error(403, 'Forbidden')
+└─ Server error → throw error(500, 'Server error')
+```
+
+## Patterns
+
+### Pattern 1: Validate, Process, Redirect
+
+```typescript
+export const actions = {
+	create: async ({ request }) => {
+		const data = await request.formData();
+
+		// 1. Validate
+		if (!isValid(data)) {
+			return fail(400, { errors: getErrors(data) });
+		}
+
+		// 2. Process
+		const post = await createPost(data);
+
+		// 3. Redirect
+		throw redirect(303, `/posts/${post.id}`);
+	},
+};
+```
+
+### Pattern 2: Check Auth, Load Data
+
+```typescript
+export const load = async ({ locals, params }) => {
+	// 1. Check auth
+	if (!locals.user) {
+		throw error(401, 'Please log in');
+	}
+
+	// 2. Load data
+	const post = await getPost(params.id);
+
+	if (!post) {
+		throw error(404, 'Post not found');
+	}
+
+	// 3. Check permission
+	if (post.authorId !== locals.user.id) {
+		throw error(403, 'Not your post');
+	}
+
+	return { post };
+};
+```
+
+### Pattern 3: Conditional Redirect
+
+```typescript
+export const load = async ({ locals }) => {
+	// Redirect if already logged in
+	if (locals.user) {
+		throw redirect(303, '/dashboard');
+	}
+
+	return {}; // Show login page
+};
+```
+
+## Summary Table
+
+|                      | fail()            | redirect()      | error()         |
+| -------------------- | ----------------- | --------------- | --------------- |
+| **Throw or return?** | Return            | **Throw**       | **Throw**       |
+| **Use in**           | Form actions      | Actions & load  | Actions & load  |
+| **Purpose**          | Validation errors | Navigate        | Fatal errors    |
+| **Status codes**     | 400-499           | 301-308         | 400-599         |
+| **Accessible via**   | `form` prop       | N/A (navigates) | `+error.svelte` |
+| **Stays on page?**   | Yes               | No (navigates)  | No (error page) |
+| **Example**          | Invalid email     | After save      | Not found       |
+
+## Client-Side Navigation After Auth
+
+When using client-side auth (e.g., Better Auth client), **always use `goto()` with `invalidateAll: true`** to ensure layout data refreshes:
+
+```svelte
+<script>
+	import { goto } from '$app/navigation';
+	import { auth_client } from '$lib/auth-client';
+
+	async function handle_signin() {
+		const result = await auth_client.signIn.email({ email, password });
+
+		if (!result.error) {
+			// ✅ CORRECT: invalidateAll ensures layout load functions re-run
+			await goto('/dashboard', { invalidateAll: true });
+		}
+	}
+</script>
+```
+
+### ❌ Common Mistake: Separate invalidateAll + goto
+
+```typescript
+// WRONG: Data might not refresh before navigation
+await invalidateAll();
+goto('/dashboard');
+
+// ALSO WRONG: goto doesn't wait for invalidation
+await invalidateAll();
+await goto('/dashboard');
+```
+
+### ✅ Correct Pattern
+
+```typescript
+// RIGHT: Single call with invalidateAll option
+await goto('/dashboard', { invalidateAll: true });
+```
+
+**Why this matters:** After client-side auth, cookies are set but the root layout's `load` function (which typically checks `auth.api.getSession()`) has cached data. Using `invalidateAll: true` forces all load functions to re-run with the new session cookie.
+
+**Note:** Server-side redirects with `throw redirect()` don't have this problem because they trigger a full page load.
+
+## Quick Checklist
+
+- ✅ Using `return fail()` for validation errors?
+- ✅ Using `throw redirect()` (not return) after success?
+- ✅ Using `throw error()` (not return) for fatal errors?
+- ✅ Not catching redirects/errors without rethrowing?
+- ✅ Using status code 303 for POST redirects?
+- ✅ Using `goto(url, { invalidateAll: true })` after client-side auth?
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/explicit-environment-variables.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/explicit-environment-variables.md
new file mode 100644
index 00000000..238717e5
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/explicit-environment-variables.md
@@ -0,0 +1,64 @@
+# Explicit Environment Variables
+
+Verified against sveltejs/kit#15934 on 2026-06-08.
+
+SvelteKit has an experimental explicit environment variable mode. It replaces implicit `$env/*` imports with a typed, validated registry.
+
+Enable it in Kit config:
+
+```ts
+// vite.config.ts
+import { sveltekit } from '@sveltejs/kit/vite';
+import { defineConfig } from 'vite';
+
+export default defineConfig({
+	plugins: [
+		sveltekit({
+			experimental: {
+				explicitEnvironmentVariables: true
+			}
+		})
+	]
+});
+```
+
+Define variables in `src/env.ts` or `src/env.js`:
+
+```ts
+import { defineEnvVars } from '@sveltejs/kit/hooks';
+import * as v from 'valibot';
+
+export const variables = defineEnvVars({
+	POSTGRES_URL: {},
+	GOOGLE_ANALYTICS_ID: {
+		public: true,
+		schema: v.pipe(v.string(), v.regex(/G-[A-Z0-9]+/))
+	},
+	SHOW_DEBUGGING_OVERLAY: {
+		public: true,
+		static: true,
+		description: 'Show an FPS meter in the corner of the page',
+		schema: v.pipe(
+			v.optional(v.string(), ''),
+			v.transform((str) => str !== '')
+		)
+	}
+});
+```
+
+Use the generated modules:
+
+```ts
+import { POSTGRES_URL } from '$app/env/private';
+import { GOOGLE_ANALYTICS_ID } from '$app/env/public';
+```
+
+## Rules
+
+- Private variables are server-only; never import `$app/env/private` in client-reachable code.
+- Public variables are sent to the client; mark only safe values as `public: true`.
+- `static: true` variables are evaluated at build time and can support dead-code elimination.
+- Missing variables fail at startup, or at build time for static variables.
+- Schemas may use any Standard Schema library (`valibot`, `zod`, `arktype`, etc.).
+- Types and hover docs are inferred from the registry.
+- This is experimental in Kit 2; the direction for Kit 3 is to remove `$env/*` and `$app/environment` in favor of `$app/env/*`.
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/form-actions.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/form-actions.md
new file mode 100644
index 00000000..b73858e7
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/form-actions.md
@@ -0,0 +1,315 @@
+# Form Actions
+
+## Basic Pattern
+
+Form actions live in `+page.server.ts` and handle form submissions:
+
+```typescript
+// +page.server.ts
+import { fail, redirect } from '@sveltejs/kit';
+import type { Actions } from './$types';
+
+export const actions: Actions = {
+	default: async ({ request }) => {
+		const data = await request.formData();
+		const email = data.get('email');
+		const password = data.get('password');
+
+		if (!email) {
+			return fail(400, { email, missing: true });
+		}
+
+		await login(email, password);
+		throw redirect(303, '/dashboard');
+	},
+};
+```
+
+```svelte
+<!-- +page.svelte -->
+<script>
+	let { form } = $props(); // Contains return value from action
+</script>
+
+<form method="POST">
+	<input name="email" value={form?.email ?? ''} />
+	{#if form?.missing}
+		<p class="error">Email is required</p>
+	{/if}
+
+	<button>Login</button>
+</form>
+```
+
+## Named Actions
+
+```typescript
+export const actions: Actions = {
+	login: async ({ request }) => {
+		// Handle login
+	},
+
+	register: async ({ request }) => {
+		// Handle registration
+	},
+};
+```
+
+```svelte
+<form method="POST" action="?/login">...</form>
+<form method="POST" action="?/register">...</form>
+```
+
+## Return Values
+
+### Option 1: fail() - Show Error to User
+
+```typescript
+import { fail } from '@sveltejs/kit';
+
+export const actions = {
+	default: async ({ request }) => {
+		const data = await request.formData();
+
+		if (!isValid(data)) {
+			return fail(400, {
+				error: 'Invalid data',
+				fields: Object.fromEntries(data), // Preserve input
+			});
+		}
+
+		// Success - no return needed
+	},
+};
+```
+
+### Option 2: redirect() - Navigate After Success
+
+```typescript
+import { redirect } from '@sveltejs/kit';
+
+export const actions = {
+	default: async ({ request }) => {
+		await processForm(request);
+		throw redirect(303, '/success'); // MUST throw
+	},
+};
+```
+
+### Option 3: error() - Fatal Error
+
+```typescript
+import { error } from '@sveltejs/kit';
+
+export const actions = {
+	default: async ({ request }) => {
+		const user = await getCurrentUser();
+
+		if (!user) {
+			throw error(401, 'Unauthorized'); // MUST throw
+		}
+
+		// Process...
+	},
+};
+```
+
+## Progressive Enhancement
+
+Form works without JavaScript:
+
+```svelte
+<script>
+	import { enhance } from '$app/forms';
+</script>
+
+<form method="POST" use:enhance>
+	<!-- Works with or without JS -->
+</form>
+```
+
+With custom handling:
+
+```svelte
+<form
+	method="POST"
+	use:enhance={({ formData, cancel }) => {
+		// Before submit
+		formData.append('timestamp', Date.now().toString());
+
+		return async ({ result, update }) => {
+			// After response
+			if (result.type === 'success') {
+				await update(); // Update form prop
+			}
+		};
+	}}
+>
+	...
+</form>
+```
+
+## Validation Pattern
+
+```typescript
+import { fail } from '@sveltejs/kit';
+import { z } from 'zod';
+
+const schema = z.object({
+	email: z.string().email(),
+	password: z.string().min(8),
+});
+
+export const actions = {
+	default: async ({ request }) => {
+		const data = await request.formData();
+		const rawData = {
+			email: data.get('email'),
+			password: data.get('password'),
+		};
+
+		const result = schema.safeParse(rawData);
+
+		if (!result.success) {
+			return fail(400, {
+				errors: result.error.flatten().fieldErrors,
+				data: rawData,
+			});
+		}
+
+		// result.data is validated
+		await createUser(result.data);
+		throw redirect(303, '/welcome');
+	},
+};
+```
+
+## Common Mistakes
+
+### ❌ Not Throwing redirect/error
+
+```typescript
+// WRONG
+export const actions = {
+	default: async () => {
+		redirect(303, '/home'); // DOESN'T WORK - must throw
+	},
+};
+
+// RIGHT
+export const actions = {
+	default: async () => {
+		throw redirect(303, '/home');
+	},
+};
+```
+
+### ❌ Catching redirect Without Rethrowing
+
+```typescript
+// WRONG
+export const actions = {
+	default: async () => {
+		try {
+			await doSomething();
+			throw redirect(303, '/success');
+		} catch (e) {
+			console.error(e); // Catches redirect!
+		}
+	},
+};
+
+// RIGHT
+export const actions = {
+	default: async () => {
+		try {
+			await doSomething();
+			throw redirect(303, '/success');
+		} catch (e) {
+			if (e instanceof Redirect) throw e; // Rethrow
+			console.error(e);
+		}
+	},
+};
+```
+
+### ❌ Returning non-serializable data
+
+```typescript
+// WRONG
+export const actions = {
+	default: async () => {
+		return { date: new Date() }; // Date is not serializable
+	},
+};
+
+// RIGHT
+export const actions = {
+	default: async () => {
+		return { date: new Date().toISOString() };
+	},
+};
+```
+
+## File Upload
+
+```typescript
+export const actions = {
+	default: async ({ request }) => {
+		const data = await request.formData();
+		const file = data.get('file') as File;
+
+		if (!file || file.size === 0) {
+			return fail(400, { error: 'No file uploaded' });
+		}
+
+		const bytes = await file.arrayBuffer();
+		const buffer = Buffer.from(bytes);
+
+		await saveFile(buffer, file.name);
+		throw redirect(303, '/uploads');
+	},
+};
+```
+
+```svelte
+<form method="POST" enctype="multipart/form-data">
+	<input type="file" name="file" required />
+	<button>Upload</button>
+</form>
+```
+
+## Form Prop in Page
+
+```svelte
+<script>
+	let { data, form } = $props(); // data from load, form from action
+</script>
+
+{#if form?.error}
+	<div class="error">{form.error}</div>
+{/if}
+
+{#if form?.success}
+	<div class="success">Success!</div>
+{/if}
+
+<form method="POST">
+	<input name="email" value={form?.email ?? data.email ?? ''} />
+	{#if form?.errors?.email}
+		<p>{form.errors.email}</p>
+	{/if}
+
+	<button>Submit</button>
+</form>
+```
+
+## Key Rules
+
+1. ✅ Actions must be in `+page.server.ts` (not `+page.ts`)
+2. ✅ ALWAYS throw `redirect()` and `error()` (not return)
+3. ✅ Return `fail()` for validation errors
+4. ✅ Return only serializable data
+5. ✅ Don't catch redirects/errors without rethrowing
+6. ✅ Use `enhance` for progressive enhancement
+7. ✅ Access FormData with `data.get('fieldName')`
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/load-functions.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/load-functions.md
new file mode 100644
index 00000000..4ec33798
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/load-functions.md
@@ -0,0 +1,292 @@
+# Load Functions: Server vs Universal
+
+## Decision Matrix
+
+| Need                                | Use            | File              |
+| ----------------------------------- | -------------- | ----------------- |
+| Database access                     | Server load    | `+page.server.ts` |
+| Secrets/env vars                    | Server load    | `+page.server.ts` |
+| Server-only packages                | Server load    | `+page.server.ts` |
+| Browser APIs (window, localStorage) | Universal load | `+page.ts`        |
+| Client-side fetch                   | Universal load | `+page.ts`        |
+| Runs on both                        | Universal load | `+page.ts`        |
+
+## Server Load (+page.server.ts)
+
+**When:** Need server-only resources (DB, secrets, server APIs)
+
+**Runs:** Only on server (never in browser)
+
+```typescript
+// src/routes/profile/+page.server.ts
+import type { PageServerLoad } from './$types';
+import { db } from '$lib/server/database';
+
+export const load: PageServerLoad = async ({ locals, params }) => {
+	// Access server-only resources
+	const user = await db.query.users.findFirst({
+		where: eq(users.id, locals.userId),
+	});
+
+	const posts = await db.query.posts.findMany({
+		where: eq(posts.authorId, user.id),
+	});
+
+	// Must return serializable data
+	return {
+		user: {
+			id: user.id,
+			name: user.name,
+			email: user.email,
+		},
+		posts,
+	};
+};
+```
+
+**Key points:**
+
+- Runs only on server
+- Can access `$lib/server/*` imports
+- Can use secrets from `env` safely
+- Return values must be JSON-serializable
+- Output is automatically passed to universal load
+
+## Universal Load (+page.ts)
+
+**When:** Need to run on both server and client, or need browser APIs
+
+**Runs:** Server (during SSR) AND client (during navigation)
+
+```typescript
+// src/routes/dashboard/+page.ts
+import type { PageLoad } from './$types';
+
+export const load: PageLoad = async ({ data, fetch }) => {
+	// `data` comes from +page.server.ts if it exists
+	const { user } = data;
+
+	// Fetch additional data (works on both server and client)
+	const response = await fetch('/api/stats');
+	const stats = await response.json();
+
+	// Can access browser APIs (but check if in browser first)
+	const theme =
+		typeof window !== 'undefined'
+			? localStorage.getItem('theme')
+			: null;
+
+	return {
+		user,
+		stats,
+		theme,
+	};
+};
+```
+
+**Key points:**
+
+- Runs on both server AND client
+- Receives server load output as `data` parameter
+- Use SvelteKit's `fetch` (automatically handles SSR)
+- Check `typeof window !== 'undefined'` for browser APIs
+- Cannot import from `$lib/server/*`
+
+## Data Flow
+
+```
+Request → Server Load (+page.server.ts)
+            ↓ (returns { user })
+        Universal Load (+page.ts)
+            ↓ (receives data: { user }, returns { user, stats })
+        Page Component (+page.svelte)
+            ↓ (receives data: { user, stats })
+```
+
+**Example:**
+
+```typescript
+// +page.server.ts
+export const load = async () => {
+  return { serverData: 'from server' };
+};
+
+// +page.ts
+export const load = async ({ data }) => {
+  console.log(data.serverData);  // 'from server'
+  return { ...data, clientData: 'from universal' };
+};
+
+// +page.svelte
+<script>
+  let { data } = $props(); // { serverData, clientData }
+</script>
+```
+
+## Common Patterns
+
+### Pattern 1: Server + Universal
+
+```typescript
+// +page.server.ts - Fetch sensitive data
+export const load = async ({ locals }) => {
+	const user = await getUser(locals.session);
+	return { user };
+};
+
+// +page.ts - Fetch public data
+export const load = async ({ data, fetch }) => {
+	const publicPosts = await fetch('/api/posts').then((r) => r.json());
+	return { ...data, publicPosts };
+};
+```
+
+### Pattern 2: Conditional Universal Load
+
+```typescript
+// +page.ts
+import { browser } from '$app/environment';
+
+export const load = async ({ fetch }) => {
+	const serverData = await fetch('/api/data').then((r) => r.json());
+
+	// Only run in browser
+	let clientOnlyData = null;
+	if (browser) {
+		clientOnlyData = localStorage.getItem('cache');
+	}
+
+	return { serverData, clientOnlyData };
+};
+```
+
+### Pattern 3: Depends for Revalidation
+
+```typescript
+// +page.ts
+export const load = async ({ fetch, depends }) => {
+	depends('app:posts'); // Invalidate with invalidate('app:posts')
+
+	const posts = await fetch('/api/posts').then((r) => r.json());
+	return { posts };
+};
+
+// Somewhere else:
+import { invalidate } from '$app/navigation';
+invalidate('app:posts'); // Re-runs load function
+```
+
+## Common Mistakes
+
+### ❌ Importing Server Code in Universal Load
+
+```typescript
+// +page.ts - WRONG
+import { db } from '$lib/server/database'; // ERROR - can't import server code
+
+export const load = async () => {
+	const users = await db.query.users.findMany(); // Won't work
+	return { users };
+};
+```
+
+**Fix:** Move to `+page.server.ts`
+
+### ❌ Returning Non-Serializable Data
+
+```typescript
+// +page.server.ts - WRONG
+export const load = async () => {
+	const user = await User.findOne(); // Returns class instance
+	return { user }; // ERROR - class instances aren't serializable
+};
+```
+
+**Fix:** Return plain objects
+
+```typescript
+export const load = async () => {
+	const user = await User.findOne();
+	return {
+		user: {
+			id: user.id,
+			name: user.name,
+			email: user.email,
+		},
+	};
+};
+```
+
+### ❌ Using window/localStorage Without Check
+
+```typescript
+// +page.ts - WRONG
+export const load = async () => {
+	const theme = localStorage.getItem('theme'); // ERROR on server
+	return { theme };
+};
+```
+
+**Fix:** Check for browser
+
+```typescript
+import { browser } from '$app/environment';
+
+export const load = async () => {
+	const theme = browser ? localStorage.getItem('theme') : 'light';
+	return { theme };
+};
+```
+
+## TypeScript
+
+```typescript
+import type { PageServerLoad } from './$types';
+
+export const load: PageServerLoad = async ({
+	locals,
+	params,
+	url,
+}) => {
+	// TypeScript knows return type must be serializable
+	return {
+		user: {
+			id: 1,
+			name: 'Alice',
+		},
+	};
+};
+```
+
+```typescript
+import type { PageLoad } from './$types';
+
+export const load: PageLoad = async ({ data, fetch, params }) => {
+	// `data` is typed from +page.server.ts return type
+	return {
+		...data,
+		extra: 'data',
+	};
+};
+```
+
+## When to Use Which
+
+**Use Server Load when:**
+
+- Need database access
+- Need secrets/environment variables
+- Need server-only npm packages
+- Need to hide implementation details
+
+**Use Universal Load when:**
+
+- Need browser APIs (localStorage, window)
+- Need to fetch public APIs (works on both)
+- Want client-side navigation without server round-trip
+- Data is public and doesn't need server resources
+
+**Use Both when:**
+
+- Server load fetches sensitive data
+- Universal load fetches public data or adds client-side enhancements
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/serialization.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/serialization.md
new file mode 100644
index 00000000..e7057970
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-data-flow/references/serialization.md
@@ -0,0 +1,317 @@
+# Serialization: What Can/Can't Be Returned
+
+## The Rule
+
+**Server load functions and form actions must return JSON-serializable
+data.**
+
+Data travels from server → client as JSON. Non-JSON types break.
+
+## ✅ Serializable (Safe)
+
+| Type         | Example                   | Notes                             |
+| ------------ | ------------------------- | --------------------------------- |
+| String       | `"hello"`                 | ✅                                |
+| Number       | `42`, `3.14`              | ✅                                |
+| Boolean      | `true`, `false`           | ✅                                |
+| null         | `null`                    | ✅                                |
+| Array        | `[1, 2, 3]`               | ✅                                |
+| Plain Object | `{ name: 'Alice' }`       | ✅                                |
+| Nested       | `{ user: { posts: [] } }` | ✅ If all values are serializable |
+
+## ❌ NOT Serializable (Breaks)
+
+| Type           | Example        | Why                        | Fix                                          |
+| -------------- | -------------- | -------------------------- | -------------------------------------------- |
+| Date           | `new Date()`   | Becomes string             | Use `.toISOString()`                         |
+| undefined      | `undefined`    | Removed from JSON          | Use `null`                                   |
+| Function       | `() => {}`     | Can't serialize            | Remove or convert to data                    |
+| Class instance | `new User()`   | Only serializes properties | Convert to plain object                      |
+| Map            | `new Map()`    | Becomes `{}`               | Convert to object: `Object.fromEntries(map)` |
+| Set            | `new Set()`    | Becomes `{}`               | Convert to array: `Array.from(set)`          |
+| BigInt         | `123n`         | Error                      | Convert to string                            |
+| Symbol         | `Symbol('id')` | Removed                    | Don't use                                    |
+| RegExp         | `/test/`       | Becomes `{}`               | Convert to string                            |
+| Error          | `new Error()`  | Loses stack                | Extract message/code                         |
+
+## Examples
+
+### ❌ Wrong: Returning Date
+
+```typescript
+// +page.server.ts - WRONG
+export const load = async () => {
+	return {
+		createdAt: new Date(), // Serializes as string, not Date object
+	};
+};
+```
+
+```svelte
+<!-- +page.svelte -->
+<script>
+	let { data } = $props();
+	console.log(data.createdAt); // String, not Date
+	console.log(data.createdAt.getTime()); // ERROR - not a Date
+</script>
+```
+
+### ✅ Right: Convert Date to ISO String
+
+```typescript
+// +page.server.ts - RIGHT
+export const load = async () => {
+	const user = await db.users.findFirst();
+
+	return {
+		user: {
+			id: user.id,
+			name: user.name,
+			createdAt: user.createdAt.toISOString(), // Convert to string
+		},
+	};
+};
+```
+
+```svelte
+<!-- +page.svelte -->
+<script>
+	let { data } = $props();
+	const createdAt = new Date(data.user.createdAt); // Parse back to Date
+</script>
+```
+
+### ❌ Wrong: Returning Class Instance
+
+```typescript
+// +page.server.ts - WRONG
+class User {
+	constructor(
+		public id: number,
+		public name: string,
+	) {}
+
+	getDisplayName() {
+		return `User: ${this.name}`;
+	}
+}
+
+export const load = async () => {
+	const user = new User(1, 'Alice');
+	return { user }; // Methods are lost during serialization
+};
+```
+
+```svelte
+<script>
+	let { data } = $props();
+	console.log(data.user.getDisplayName()); // ERROR - method doesn't exist
+</script>
+```
+
+### ✅ Right: Return Plain Object
+
+```typescript
+// +page.server.ts - RIGHT
+export const load = async () => {
+	const user = await db.users.findFirst();
+
+	return {
+		user: {
+			id: user.id,
+			name: user.name,
+			email: user.email,
+			// Only plain data, no methods
+		},
+	};
+};
+```
+
+### ❌ Wrong: undefined Values
+
+```typescript
+// +page.server.ts - WRONG
+export const load = async () => {
+	return {
+		name: 'Alice',
+		email: undefined, // Removed during JSON.stringify
+	};
+};
+```
+
+```svelte
+<script>
+	let { data } = $props();
+	console.log('email' in data); // false - key is missing!
+</script>
+```
+
+### ✅ Right: Use null
+
+```typescript
+// +page.server.ts - RIGHT
+export const load = async () => {
+	return {
+		name: 'Alice',
+		email: null, // Preserved
+	};
+};
+```
+
+### ❌ Wrong: Map/Set
+
+```typescript
+// +page.server.ts - WRONG
+export const load = async () => {
+	const tags = new Set(['svelte', 'typescript']);
+	const metadata = new Map([['version', '1.0']]);
+
+	return {
+		tags, // Becomes {}
+		metadata, // Becomes {}
+	};
+};
+```
+
+### ✅ Right: Convert to Array/Object
+
+```typescript
+// +page.server.ts - RIGHT
+export const load = async () => {
+	const tags = new Set(['svelte', 'typescript']);
+	const metadata = new Map([['version', '1.0']]);
+
+	return {
+		tags: Array.from(tags), // ['svelte', 'typescript']
+		metadata: Object.fromEntries(metadata), // { version: '1.0' }
+	};
+};
+```
+
+## ORM Returns (Drizzle, Prisma)
+
+Most ORMs return plain objects with Date fields:
+
+```typescript
+// +page.server.ts
+export const load = async () => {
+	const user = await db.query.users.findFirst();
+	// user = { id: 1, name: 'Alice', createdAt: Date }
+
+	return {
+		user: {
+			...user,
+			createdAt: user.createdAt.toISOString(), // Convert Date
+		},
+	};
+};
+```
+
+Or use a helper:
+
+```typescript
+function serialize<T extends Record<string, any>>(obj: T): T {
+	return JSON.parse(JSON.stringify(obj)); // Forces serialization
+}
+
+export const load = async () => {
+	const user = await db.query.users.findFirst();
+	return { user: serialize(user) };
+};
+```
+
+## BigInt
+
+```typescript
+// +page.server.ts - WRONG
+export const load = async () => {
+	return {
+		userId: 123456789012345678901234567890n, // ERROR - can't serialize
+	};
+};
+
+// +page.server.ts - RIGHT
+export const load = async () => {
+	return {
+		userId: '123456789012345678901234567890', // String
+	};
+};
+```
+
+## Detecting Serialization Issues
+
+SvelteKit will throw an error if you try to return non-serializable
+data:
+
+```
+Error: Data returned from `load` while rendering / is not serializable:
+  - Cannot stringify arbitrary non-POJOs
+```
+
+## Testing Serialization
+
+```typescript
+const data = { user: new User() };
+
+try {
+	JSON.parse(JSON.stringify(data));
+	console.log('✅ Serializable');
+} catch (e) {
+	console.log('❌ Not serializable');
+}
+```
+
+## TypeScript Help
+
+Use `satisfies` to catch issues at compile time:
+
+```typescript
+import type { PageServerLoad } from './$types';
+
+export const load = (async () => {
+	return {
+		user: {
+			id: 1,
+			name: 'Alice',
+			createdAt: new Date(), // TypeScript allows this, but it's problematic
+		},
+	};
+}) satisfies PageServerLoad;
+```
+
+Better: Create a type that only allows primitives:
+
+```typescript
+type Serializable =
+	| string
+	| number
+	| boolean
+	| null
+	| { [key: string]: Serializable }
+	| Serializable[];
+
+export const load: PageServerLoad = async () => {
+	const data: Serializable = {
+		user: {
+			id: 1,
+			name: 'Alice',
+			createdAt: new Date().toISOString(), // Must be string
+		},
+	};
+
+	return data;
+};
+```
+
+## Quick Checklist
+
+Before returning from server load or form action:
+
+1. ✅ All values are string, number, boolean, null, array, or plain
+   object?
+2. ✅ No Date objects? (convert to `.toISOString()`)
+3. ✅ No undefined? (use null)
+4. ✅ No class instances? (convert to plain objects)
+5. ✅ No Map/Set? (convert to object/array)
+6. ✅ No functions?
+7. ✅ No BigInt? (convert to string)
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-remote-functions/SKILL.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-remote-functions/SKILL.md
new file mode 100644
index 00000000..86da1b98
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-remote-functions/SKILL.md
@@ -0,0 +1,123 @@
+---
+name: sveltekit-remote-functions
+# IMPORTANT: Keep description on ONE line for agent compatibility
+# prettier-ignore
+description: "Implement SvelteKit remote functions. Use for query(), query.live(), form(), command(), and prerender() patterns in .remote.ts files."
+metadata:
+  last_updated: "2026-06-08"
+  verified_against: "Svelte 5/Kit docs, sveltejs/svelte#18282, query.live examples, and SvelteKit Vite-plugin config post"
+---
+
+# SvelteKit Remote Functions
+
+## Current Status
+
+Remote functions are **experimental** in SvelteKit 2.58. Prefer enabling them in `vite.config.ts` via the SvelteKit Vite plugin:
+
+```ts
+import { sveltekit } from '@sveltejs/kit/vite';
+import { defineConfig } from 'vite';
+
+export default defineConfig({
+	plugins: [
+		sveltekit({
+			experimental: { remoteFunctions: true },
+			compilerOptions: { experimental: { async: true } } // only for await in components
+		})
+	]
+});
+```
+
+## Quick Start
+
+**File naming:** export remote functions from `*.remote.ts` or `*.remote.js`.
+Remote files can live anywhere under `src` except `src/lib/server`.
+
+**Which function?**
+
+- Dynamic reads → `query()`
+- Realtime server streams → `query.live()`
+- Progressive forms → `form()`
+- Event-handler mutations → `command()`
+- Build-time/static reads → `prerender()`
+
+## Example
+
+```ts
+// posts.remote.ts
+import { command, query, requested } from "$app/server";
+import * as v from "valibot";
+
+export const getPosts = query(
+	v.object({ tag: v.optional(v.string()) }),
+	async (filter) => {
+		return db.posts.find(filter);
+	},
+);
+
+export const createPost = command(
+	v.object({ title: v.string() }),
+	async (data) => {
+		await db.posts.create(data);
+
+		for (const { query } of requested(getPosts, 5)) {
+			void query.refresh();
+		}
+	},
+);
+```
+
+Client:
+
+```svelte
+<script lang="ts">
+	import { createPost, getPosts } from './posts.remote';
+
+	const posts = $derived(await getPosts({ tag: 'svelte' }));
+</script>
+
+<button onclick={() => createPost({ title: 'New' }).updates(getPosts)}>
+	Create
+</button>
+```
+
+## Current Rules
+
+- `svelte.config.js` still works in Kit 2, but Kit 3 will read Kit config from the Vite plugin instead.
+- Remote functions always run on the server, even when called from the browser.
+- Args/returns use `devalue`; avoid functions, class instances, symbols, circular refs, and `RegExp`.
+- Validate exposed inputs with Standard Schema (`valibot`, `zod`, `arktype`, etc.) or use `.unchecked`/`'unchecked'` deliberately.
+- `query.batch()` batches calls from the same macrotask to solve n+1 reads.
+- `query.live()` returns an async iterable; SSR uses the first yield, clients stay connected while rendered.
+- Prefer event-driven live queries over polling when a mutation can notify listeners (`Promise.withResolvers()`/pubsub).
+- Live queries expose `connected` and `reconnect()`, but no `refresh()`; `.run()` returns `Promise<AsyncGenerator<T>>`.
+- Do not service-worker-cache live query responses; exclude `Cache-Control: no-store` streams.
+- `form().enhance()` `submit()` returns `true` when submission is valid/successful and `false` for validation failures.
+- `.updates()` is client-requested; server handlers must opt in with `requested(queryFn, limit)`.
+- `requested()` now yields `{ arg, query }`; call `query.refresh()`/`query.set(...)` on the bound instance.
+- `limit` is required for `requested()` to cap client-controlled refresh requests.
+- Inside command/form handlers, use `void query.refresh()`/`void query.set(value)`; SvelteKit awaits and serializes the updates.
+- For live queries, single-flight mutations can call `void live_query.reconnect()`.
+- Prefer `form()` over `command()` where progressive enhancement matters.
+- Use `prerender()` for data that changes at most once per deployment.
+- **Last verified:** 2026-06-08
+
+## Reference Files
+
+- [references/remote-functions.md](references/remote-functions.md) - Current patterns, examples, and gotchas
+
+<!--
+PROGRESSIVE DISCLOSURE GUIDELINES:
+- Keep this file ~50 lines total (max ~150 lines)
+- Use 1-2 code blocks only (recommend 1)
+- Keep description <200 chars for Level 1 efficiency
+- Move detailed docs to references/ for Level 3 loading
+- This is Level 2 - quick reference ONLY, not a manual
+
+LLM WORKFLOW (when editing this file):
+1. Write/edit SKILL.md
+2. Format (if formatter available)
+3. Run: npx skills add . --list
+4. If the skill is not discovered, check SKILL.md frontmatter formatting
+5. Validate again to confirm
+-->
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-remote-functions/references/remote-functions.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-remote-functions/references/remote-functions.md
new file mode 100644
index 00000000..925c811a
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-remote-functions/references/remote-functions.md
@@ -0,0 +1,525 @@
+# SvelteKit Remote Functions
+
+Verified against the SvelteKit remote functions docs and Vite-plugin config support on 2026-06-08.
+
+Remote functions are exported from `.remote.ts`/`.remote.js` files and can be
+called anywhere in the app. They always execute on the server. On the client,
+SvelteKit transforms calls into generated `fetch` requests.
+
+Remote functions are still experimental. Prefer enabling them through the SvelteKit Vite plugin (Kit 2 also still supports `svelte.config.js`; Kit 3 will not read it):
+
+```ts
+// vite.config.ts
+import { sveltekit } from '@sveltejs/kit/vite';
+import { defineConfig } from 'vite';
+
+export default defineConfig({
+	plugins: [
+		sveltekit({
+			experimental: { remoteFunctions: true },
+			compilerOptions: {
+				experimental: {
+					async: true // optional; needed for `await` in components
+				}
+			}
+		})
+	]
+});
+```
+
+Remote files can live anywhere under `src` except `src/lib/server`.
+
+## Function Types
+
+| Function      | Use for                                      | Notes |
+| ------------- | -------------------------------------------- | ----- |
+| `query()`     | Dynamic server reads                         | Cached while rendered; supports refresh and batching |
+| `query.live()` | Realtime server streams                     | Async iterable; SSR uses first yield; client stays connected while rendered |
+| `form()`      | Progressive form mutations                   | Works without JS; supports fields, validation, enhance |
+| `command()`   | Imperative/event-handler mutations           | Cannot be called during render |
+| `prerender()` | Static/build-time reads                      | For data that changes at most once per deployment |
+
+## query()
+
+Use `query()` for dynamic server reads.
+
+```ts
+import { query } from '$app/server';
+import * as v from 'valibot';
+
+export const getPost = query(v.string(), async (slug) => {
+	return db.posts.findBySlug(slug);
+});
+```
+
+In components with async enabled:
+
+```svelte
+<script lang="ts">
+	import { getPost } from './posts.remote';
+	let { slug } = $props();
+	const post = $derived(await getPost(slug));
+</script>
+
+<h1>{post.title}</h1>
+```
+
+Without async in components, use `{#await}`:
+
+```svelte
+{#await getPost(slug) then post}
+	<h1>{post.title}</h1>
+{/await}
+```
+
+### Query refresh
+
+```svelte
+<button onclick={() => getPost(slug).refresh()}>
+	Refresh
+</button>
+```
+
+Queries are cached while on the page. Calling `getPost(slug)` repeatedly returns
+the same active query instance for that argument.
+
+### query.batch()
+
+Use `query.batch()` for n+1 reads. Calls made in the same macrotask are grouped
+into one server request. The handler receives all inputs and returns a resolver.
+
+```ts
+import { query } from '$app/server';
+import * as v from 'valibot';
+
+export const getWeather = query.batch(v.string(), async (cityIds) => {
+	const rows = await db.weather.findMany(cityIds);
+	const byId = new Map(rows.map((row) => [row.city_id, row]));
+	return (cityId) => byId.get(cityId);
+});
+```
+
+## query.live()
+
+Use `query.live()` for realtime data streamed from the server. Its handler is typically an async generator that yields updated values.
+
+```ts
+import { query } from '$app/server';
+
+export const get_time = query.live(async function* () {
+	while (true) {
+		yield new Date();
+		await new Promise((resolve) => setTimeout(resolve, 1000));
+	}
+});
+```
+
+During SSR, `await get_time()` returns the first yielded value and closes the iterator. The initial value is serialized for hydration. In the browser, the stream stays connected while the query is actively used by a component; multiple instances share one connection. When no active uses remain, SvelteKit disconnects and stops server-side iteration.
+
+```svelte
+<script lang="ts">
+	import { get_time } from './time.remote';
+
+	const time = get_time();
+</script>
+
+<p>{await time}</p>
+<p>connected: {time.connected}</p>
+<button onclick={() => time.reconnect()}>Reconnect</button>
+```
+
+Notes:
+
+- Live query instances expose `connected` and `reconnect()`.
+- If the connection drops, SvelteKit passively reconnects with exponential backoff and actively reconnects when `navigator.onLine` changes back to `true`.
+- Live queries are self-updating and do not have `refresh()`.
+- Use `.run()` outside render for imperative access; it returns `Promise<AsyncGenerator<T>>`.
+- Do not cache live query responses in a service worker. Exclude responses whose `Cache-Control` header includes `no-store`, otherwise cloned streaming responses can keep running after the page closes.
+
+### Event-driven live queries
+
+Prefer event-driven notification over timer polling when mutations know exactly
+when data changed. A small in-memory listener set is fine for demos and local
+single-process tools; production multi-instance apps should replace it with a
+DB notification channel, queue, pub/sub, or another cross-process signal.
+
+```ts
+import { form, query } from '$app/server';
+import * as v from 'valibot';
+
+const poll_results = { yes: 0, no: 0 };
+const listeners = new Set<() => void>();
+
+export const get_poll = query.live(async function* () {
+	while (true) {
+		yield poll_results;
+		const { promise, resolve } = Promise.withResolvers<void>();
+		listeners.add(resolve);
+		await promise;
+	}
+});
+
+export const cast_vote = form(
+	v.object({ option: v.picklist(['yes', 'no']) }),
+	async ({ option }) => {
+		poll_results[option] += 1;
+		for (const listener of listeners) listener();
+		listeners.clear();
+	},
+);
+```
+
+Good fits: job/render progress, dashboards, notifications, live polls, lightweight chat, and agent/task status feeds. Add authorization, persistence, cleanup, and backpressure before using this pattern for production traffic.
+
+## form()
+
+Use `form()` for mutations that should gracefully degrade when JavaScript is
+disabled.
+
+```ts
+import { form } from '$app/server';
+import * as v from 'valibot';
+
+export const createPost = form(
+	v.object({
+		title: v.pipe(v.string(), v.nonEmpty()),
+		content: v.pipe(v.string(), v.nonEmpty())
+	}),
+	async ({ title, content }) => {
+		await db.posts.create({ title, content });
+	}
+);
+```
+
+Use `.fields.<name>.as(type)` to bind typed inputs:
+
+```svelte
+<form {...createPost}>
+	<input {...createPost.fields.title.as('text')} />
+	<textarea {...createPost.fields.content.as('text')}></textarea>
+	<button>Publish</button>
+</form>
+```
+
+`.as(...)` supplies `name`, type-specific attributes, validation state, and
+repopulation behavior after failed validation.
+
+### Sensitive fields
+
+Prefix sensitive field names with `_` to prevent repopulation after invalid
+non-enhanced submissions:
+
+```svelte
+<input {...login.fields._password.as('password')} />
+```
+
+Use this for passwords, credit card numbers, tokens, and similar secrets.
+
+### Validation
+
+If schema validation fails, the handler does not run. Issues are exposed through
+field helpers:
+
+```svelte
+{#each createPost.fields.title.issues() as issue}
+	<p class="error">{issue.message}</p>
+{/each}
+```
+
+Programmatic validation inside a handler uses `invalid` from `@sveltejs/kit`:
+
+```ts
+import { invalid } from '@sveltejs/kit';
+import { form } from '$app/server';
+
+export const login = form(schema, async (data, issue) => {
+	if (!(await auth.check(data))) {
+		invalid(issue.email('Invalid credentials'));
+	}
+});
+```
+
+Client-side preflight validation can prevent invalid submissions before they hit
+the server:
+
+```svelte
+<form {...createPost.preflight(schema)}>
+	<!-- fields -->
+</form>
+```
+
+### enhance()
+
+`enhance` customizes JS-enabled submission. Since SvelteKit 2.57,
+`submit()` returns a boolean: `true` means the submission completed without
+validation failure; `false` means validation failed and the handler did not run.
+
+```svelte
+<form {...createPost.enhance(async ({ form, submit }) => {
+	try {
+		if (await submit()) {
+			form.reset();
+			showToast('Published');
+		}
+	} catch (error) {
+		showToast('Something went wrong');
+	}
+})}>
+	<!-- fields -->
+</form>
+```
+
+With `enhance`, the form is not automatically reset. Call `form.reset()` when you
+want to clear inputs.
+
+### Multiple form instances
+
+Use `.for(id)` when rendering the same form many times and each instance needs
+isolated state.
+
+```svelte
+{#each todos as todo}
+	{const modify = modifyTodo.for(todo.id)}
+	<form {...modify}>
+		<input {...modify.fields.description.as('text', todo.description)} />
+		<button disabled={!!modify.pending}>Save</button>
+	</form>
+{/each}
+```
+
+### Multiple submit buttons
+
+Model the clicked submit button as a schema field and bind buttons with
+`.as('submit', value)`.
+
+```svelte
+<form {...loginOrRegister}>
+	<input {...loginOrRegister.fields.email.as('email')} />
+	<input {...loginOrRegister.fields._password.as('password')} />
+	<button {...loginOrRegister.fields.action.as('submit', 'login')}>Login</button>
+	<button {...loginOrRegister.fields.action.as('submit', 'register')}>Register</button>
+</form>
+```
+
+### File uploads
+
+Remote `form()` supports file uploads. Since SvelteKit 2.49, enhanced forms use a
+streaming binary upload format so server-side form handlers can access form data
+before large files finish uploading. SvelteKit 2.52 tightened file metadata and
+offset-table validation.
+
+Practical rules:
+
+- Keep file schemas explicit and validate type/size server-side.
+- Do not trust client-provided file metadata.
+- Prefer streaming processing/storage for large files.
+- Handle upload errors as normal form validation or request errors.
+
+## command()
+
+Use `command()` for mutations from event handlers or other imperative code.
+Prefer `form()` when progressive enhancement matters.
+
+```ts
+import { command } from '$app/server';
+import * as v from 'valibot';
+
+export const addLike = command(v.string(), async (postId) => {
+	await db.posts.incrementLikes(postId);
+});
+```
+
+```svelte
+<button onclick={() => addLike(post.id).updates(getLikes(post.id))}>
+	Like
+</button>
+```
+
+Commands cannot be called during render.
+
+## Single-flight mutations
+
+Use single-flight mutations to refresh query data in the same request as a
+`form()` submission or `command()` invocation. This avoids an extra round-trip
+and prevents stale UI.
+
+There are two sides:
+
+1. **Client requests updates** with `.updates(...)`
+2. **Server accepts updates** with `requested(queryFn, limit)`
+
+### Client: .updates()
+
+`.updates()` accepts query functions, query instances, and optimistic overrides.
+
+```ts
+// Refresh all active getPosts instances
+await createPost(data).updates(getPosts);
+
+// Refresh one instance
+await addLike(post.id).updates(getLikes(post.id));
+
+// Optimistic update
+await addLike(post.id).updates(getLikes(post.id).withOverride((n) => n + 1));
+```
+
+Inside enhanced forms:
+
+```svelte
+<form {...createPost.enhance(async ({ submit }) => {
+	await submit().updates(getPosts);
+})}>
+	<!-- fields -->
+</form>
+```
+
+### Server: requested(queryFn, limit)
+
+`requested` is required for client-requested refreshes. The `limit` argument is
+required as of SvelteKit 2.58 because the list is client-controlled and each item
+can cause validation and data fetching.
+
+```ts
+import { command, query, requested } from '$app/server';
+
+export const getPosts = query(filterSchema, async (filter) => {
+	return db.posts.find(filter);
+});
+
+export const createPost = command(createSchema, async (data) => {
+	await db.posts.create(data);
+
+	for (const { arg, query } of requested(getPosts, 5)) {
+		// arg is the validated/transformed argument
+		// query is bound to the original client cache key
+		void query.refresh();
+	}
+});
+```
+
+Important current behavior:
+
+- `requested(queryFn, limit)` yields `{ arg, query }` objects, not raw args.
+- Use the yielded `query` instance for `.refresh()`/`.set(...)`; it is bound to
+the original client cache key even if validation transformed `arg`.
+- `limit` is required. Choose the maximum refreshes you are willing to process
+per mutation. `Infinity` is possible but usually a DoS footgun.
+- If parsing one requested argument fails, that query errors, but the whole
+mutation does not fail.
+
+Shorthand:
+
+```ts
+await requested(getPosts, 5).refreshAll();
+```
+
+This is equivalent to looping and calling `void query.refresh()` for each
+requested query.
+
+### Server-driven updates
+
+If the server already knows exactly what changed, call `.refresh()` or `.set()`
+inside the handler without waiting for a client request.
+
+```ts
+export const updatePost = command(updateSchema, async ({ id, title }) => {
+	const post = await db.posts.update(id, { title });
+
+	void getPost(id).set(post);     // send known value back
+	void getPosts().refresh();      // refetch list in same response
+});
+```
+
+Use `void` rather than `await`; SvelteKit awaits and serializes these updates for
+the response.
+
+### Reconnecting live queries
+
+Single-flight mutations can reconnect `query.live()` instances by calling `.reconnect()` in a `form()` or `command()` handler.
+
+```ts
+import { form, query } from '$app/server';
+import * as v from 'valibot';
+
+export const get_notifications = query.live(v.string(), async function* (user_id) {
+	while (true) {
+		yield await db.notifications(user_id);
+		await wait(1000);
+	}
+});
+
+export const mark_all_read = form(v.object({ user_id: v.string() }), async ({ user_id }) => {
+	await db.mark_all_notifications_read(user_id);
+	void get_notifications(user_id).reconnect();
+});
+```
+
+## prerender()
+
+Use `prerender()` for data that changes at most once per deployment. Results are
+computed during prerendering and can be cached on a CDN.
+
+```ts
+import { prerender } from '$app/server';
+import * as v from 'valibot';
+
+export const getPosts = prerender(async () => {
+	return db.posts.allPublished();
+});
+
+export const getPost = prerender(v.string(), async (slug) => {
+	return db.posts.findBySlug(slug);
+});
+```
+
+SvelteKit's crawler automatically saves calls it discovers while prerendering.
+Use the `inputs` option when you need to enumerate values explicitly.
+
+## getRequestEvent()
+
+Use `getRequestEvent()` inside remote functions for cookies, headers, locals,
+and other request context.
+
+```ts
+import { getRequestEvent, query } from '$app/server';
+
+export const getMe = query(async () => {
+	const event = getRequestEvent();
+	return event.locals.user;
+});
+```
+
+## Serialization
+
+Remote arguments and return values are serialized with `devalue`.
+
+Can serialize:
+
+- primitives, arrays, plain objects
+- `Date`, `Map`, `Set`, typed arrays
+
+Avoid:
+
+- functions
+- class instances without serialization support
+- symbols
+- circular references
+- `RegExp` as remote function arguments
+
+Query cache keys are based on serialized arguments. Object keys are normalized,
+so `{ limit: 10, offset: 20 }` and `{ offset: 20, limit: 10 }` refer to the same
+query cache entry.
+
+## Common Gotchas
+
+- Remote functions are HTTP endpoints; validate every exposed input.
+- `form()` invalid schema submissions do not run the handler.
+- `command()` does not auto-refresh anything; use `.updates()` or server-driven
+query updates.
+- `form()` auto-invalidates broadly after successful submissions unless you use
+more targeted single-flight updates.
+- `requested()` must name each query function the server is willing to refresh;
+this protects bundle size and avoids unbounded client-controlled work.
+- Use `form()` instead of `command()` when no-JS behavior matters.
+- Do not export shared schemas from `.remote.ts`; put them in a shared module or
+component module script.
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/SKILL.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/SKILL.md
new file mode 100644
index 00000000..f1554f54
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/SKILL.md
@@ -0,0 +1,82 @@
+---
+name: sveltekit-structure
+# IMPORTANT: Keep description on ONE line for agent compatibility
+# prettier-ignore
+description: "SvelteKit structure guidance. Use for routing, layouts, error handling, SSR, or svelte:boundary. Covers file naming, nested layouts, error boundaries, pending UI, and hydration."
+metadata:
+  last_updated: "2026-05-31"
+  verified_against: "Svelte 5 official docs and sveltejs/svelte#18282"
+---
+
+# SvelteKit Structure
+
+## Quick Start
+
+**File types:** `+page.svelte` (page) | `+layout.svelte` (wrapper) |
+`+error.svelte` (error boundary) | `+server.ts` (API endpoint)
+
+**Routes:** `src/routes/about/+page.svelte` → `/about` |
+`src/routes/posts/[id]/+page.svelte` → `/posts/123`
+
+**Layouts:** Apply to all child routes. `+layout.svelte` at any level
+wraps descendants.
+
+## Example
+
+```
+src/routes/
+├── +layout.svelte              # Root layout (all pages)
+├── +page.svelte                # Homepage /
+├── about/+page.svelte          # /about
+└── dashboard/
+    ├── +layout.svelte          # Dashboard layout (dashboard pages only)
+    ├── +page.svelte            # /dashboard
+    └── settings/+page.svelte   # /dashboard/settings
+```
+
+```svelte
+<!-- +layout.svelte -->
+<script>
+	let { children } = $props();
+</script>
+
+<nav><!-- Navigation --></nav>
+<main>{@render children()}</main>
+<footer><!-- Footer --></footer>
+```
+
+## Reference Files
+
+- [file-naming.md](references/file-naming.md) - File naming
+  conventions
+- [layout-patterns.md](references/layout-patterns.md) - Nested layouts
+- [error-handling.md](references/error-handling.md) - +error.svelte
+  placement
+- [svelte-boundary.md](references/svelte-boundary.md) -
+  Component-level error/pending
+- [ssr-hydration.md](references/ssr-hydration.md) - SSR and
+  browser-only code
+
+## Notes
+
+- Layouts: `{@render children()}` | Errors: +error.svelte _above_
+  failing route
+- Groups: `(name)` folders don't affect URL | Client-only: check
+  `browser`
+- **Last verified:** 2026-05-14
+
+<!--
+PROGRESSIVE DISCLOSURE GUIDELINES:
+- Keep this file ~50 lines total (max ~150 lines)
+- Use 1-2 code blocks only (recommend 1)
+- Keep description <200 chars for Level 1 efficiency
+- Move detailed docs to references/ for Level 3 loading
+- This is Level 2 - quick reference ONLY, not a manual
+
+LLM WORKFLOW (when editing this file):
+1. Write/edit SKILL.md
+2. Format (if formatter available)
+3. Run: npx skills add . --list
+4. If the skill is not discovered, check SKILL.md frontmatter formatting
+5. Validate again to confirm
+-->
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/error-handling.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/error-handling.md
new file mode 100644
index 00000000..65ccd30f
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/error-handling.md
@@ -0,0 +1,274 @@
+# Error Handling
+
+## Error Boundary Placement
+
+**Key rule:** `+error.svelte` must be _above_ the failing route in the
+hierarchy.
+
+```
+src/routes/
+├── +error.svelte           # Catches errors in all routes below
+├── +page.svelte            # If this errors → uses +error.svelte above
+└── admin/
+    ├── +error.svelte       # Catches errors in admin routes
+    └── +page.svelte        # If this errors → uses admin/+error.svelte
+```
+
+**Wrong:**
+
+```
+src/routes/dashboard/
+├── +layout.svelte          # If this errors...
+└── +error.svelte           # This won't catch it (too low)
+```
+
+**Right:**
+
+```
+src/routes/
+├── +error.svelte           # Catches dashboard layout errors
+└── dashboard/
+    ├── +layout.svelte
+    └── +error.svelte       # Catches dashboard page errors
+```
+
+## Error Propagation
+
+Errors bubble up to the nearest `+error.svelte`:
+
+```
+src/routes/
+├── +error.svelte                    # Level 1 (root fallback)
+└── blog/
+    ├── +error.svelte                # Level 2 (blog fallback)
+    └── [slug]/
+        ├── +layout.server.ts        # Error here → blog/+error.svelte
+        ├── +page.server.ts          # Error here → blog/+error.svelte
+        └── +page.svelte             # Error here → blog/+error.svelte
+```
+
+**If no error boundary exists at that level, it goes to the parent.**
+
+## Basic Error Page
+
+```svelte
+<!-- +error.svelte -->
+<script>
+	import { page } from '$app/stores';
+</script>
+
+<h1>{$page.status}</h1><p>{$page.error.message}</p>
+```
+
+## Custom Error Data
+
+```typescript
+// +page.server.ts
+import { error } from '@sveltejs/kit';
+
+export const load = async ({ params }) => {
+	const post = await getPost(params.id);
+
+	if (!post) {
+		throw error(404, {
+			message: 'Post not found',
+			postId: params.id,
+		});
+	}
+
+	return { post };
+};
+```
+
+```svelte
+<!-- +error.svelte -->
+<script>
+	import { page } from '$app/stores';
+</script>
+
+<h1>{$page.status}</h1>
+<p>{$page.error.message}</p>
+
+{#if $page.error.postId}
+	<p>Could not find post with ID: {$page.error.postId}</p>
+{/if}
+```
+
+## Status Code Specific Errors
+
+```svelte
+<!-- +error.svelte -->
+<script>
+	import { page } from '$app/stores';
+</script>
+
+{#if $page.status === 404}
+	<h1>Page Not Found</h1>
+	<p>The page you're looking for doesn't exist.</p>
+	<a href="/">Go home</a>
+{:else if $page.status === 403}
+	<h1>Access Denied</h1>
+	<p>You don't have permission to view this page.</p>
+{:else if $page.status === 401}
+	<h1>Unauthorized</h1>
+	<p>Please log in to continue.</p>
+	<a href="/login">Login</a>
+{:else if $page.status >= 500}
+	<h1>Server Error</h1>
+	<p>Something went wrong on our end. Please try again later.</p>
+{:else}
+	<h1>Error {$page.status}</h1>
+	<p>{$page.error.message}</p>
+{/if}
+```
+
+## Common Status Codes
+
+- **400** - Bad Request (malformed request)
+- **401** - Unauthorized (not logged in)
+- **403** - Forbidden (logged in but no permission)
+- **404** - Not Found (resource doesn't exist)
+- **500** - Internal Server Error (unhandled exception)
+- **503** - Service Unavailable (server overloaded/down)
+
+## Error in Layout vs Page
+
+**Layout error:**
+
+```typescript
+// src/routes/dashboard/+layout.server.ts
+export const load = async ({ locals }) => {
+	if (!locals.user) {
+		throw error(401, 'Not logged in'); // Caught by +error.svelte ABOVE dashboard
+	}
+	return { user: locals.user };
+};
+```
+
+**Page error:**
+
+```typescript
+// src/routes/dashboard/settings/+page.server.ts
+export const load = async () => {
+	throw error(404, 'Settings not found'); // Caught by nearest +error.svelte
+};
+```
+
+## Expected Errors vs Unexpected Errors
+
+**Expected (use error()):**
+
+```typescript
+// User requests invalid resource
+if (!post) throw error(404, 'Post not found');
+
+// User lacks permission
+if (post.authorId !== user.id) throw error(403, 'Not your post');
+```
+
+**Unexpected (let it bubble):**
+
+```typescript
+// Unhandled exceptions (DB connection fails, etc.)
+// Will show generic 500 error
+const posts = await db.query.posts.findMany(); // Might throw
+```
+
+## Handling Errors in handleError Hook
+
+```typescript
+// src/hooks.server.ts
+import type { HandleServerError } from '@sveltejs/kit';
+
+export const handleError: HandleServerError = ({ error, event }) => {
+	// Log to error tracking service
+	console.error('Error:', error, 'Path:', event.url.pathname);
+
+	// Return user-friendly message (don't expose internals)
+	return {
+		message: 'An unexpected error occurred',
+		code: error?.code ?? 'UNKNOWN',
+	};
+};
+```
+
+## Error in Load vs Error in Component
+
+**Load function error (recommended):**
+
+```typescript
+// +page.server.ts
+export const load = async ({ params }) => {
+	const user = await getUser(params.id);
+	if (!user) throw error(404, 'User not found'); // Shows +error.svelte
+	return { user };
+};
+```
+
+**Component error (not ideal):**
+
+```svelte
+<!-- +page.svelte - Don't do this -->
+<script>
+	let { data } = $props();
+
+	// If data.user is undefined, component just shows nothing
+	// No error boundary triggered
+</script>
+
+<h1>{data.user.name}</h1> <!-- Might crash if user undefined -->
+```
+
+**Best practice:** Validate and throw errors in `load` functions, not
+components.
+
+## Fallback Error Handling
+
+Always have a root `+error.svelte`:
+
+```svelte
+<!-- src/routes/+error.svelte -->
+<script>
+	import { page } from '$app/stores';
+	import { dev } from '$app/environment';
+</script>
+
+<h1>Oops! Something went wrong</h1>
+
+{#if dev}
+	<!-- Show details in dev mode -->
+	<pre>{JSON.stringify($page.error, null, 2)}</pre>
+{:else}
+	<!-- Generic message in production -->
+	<p>We're sorry, but something unexpected happened.</p>
+{/if}
+
+<a href="/">Go home</a>
+```
+
+## Testing Error Boundaries
+
+```typescript
+// +page.server.ts
+export const load = async ({ url }) => {
+	// Test error page in dev
+	if (url.searchParams.has('test-error')) {
+		throw error(500, 'Test error');
+	}
+
+	return {};
+};
+```
+
+Visit `http://localhost:5173/page?test-error` to see error boundary.
+
+## Key Takeaways
+
+1. ✅ Place `+error.svelte` ABOVE failing routes
+2. ✅ Errors bubble up to nearest error boundary
+3. ✅ Always have a root `src/routes/+error.svelte`
+4. ✅ Throw errors in `load` functions, not components
+5. ✅ Use specific status codes (401, 403, 404, 500)
+6. ✅ Customize error pages per section (blog, admin, etc.)
+7. ✅ Use `handleError` hook for logging/monitoring
+8. ✅ Show detailed errors in dev, generic in production
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/file-naming.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/file-naming.md
new file mode 100644
index 00000000..b38409ee
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/file-naming.md
@@ -0,0 +1,69 @@
+# File Naming Conventions
+
+## Core Files
+
+| File                | Purpose               | Runs                  | Example                                       |
+| ------------------- | --------------------- | --------------------- | --------------------------------------------- |
+| `+page.svelte`      | Page component        | Client & Server (SSR) | `/routes/about/+page.svelte` → `/about`       |
+| `+page.ts`          | Universal load        | Client & Server       | Data for +page.svelte                         |
+| `+page.server.ts`   | Server load & actions | Server only           | DB queries, form actions                      |
+| `+layout.svelte`    | Layout wrapper        | Client & Server       | Wraps child routes                            |
+| `+layout.ts`        | Layout universal load | Client & Server       | Data for +layout.svelte                       |
+| `+layout.server.ts` | Layout server load    | Server only           | Auth, user data                               |
+| `+error.svelte`     | Error boundary        | Client & Server       | Shown when error thrown                       |
+| `+server.ts`        | API endpoint          | Server only           | `/routes/api/users/+server.ts` → `/api/users` |
+
+## Route Parameters
+
+| Pattern        | Matches        | Example                                                          |
+| -------------- | -------------- | ---------------------------------------------------------------- |
+| `[id]`         | Single param   | `/posts/[id]/+page.svelte` → `/posts/123`                        |
+| `[slug]`       | Single param   | `/blog/[slug]/+page.svelte` → `/blog/hello-world`                |
+| `[[optional]]` | Optional param | `/search/[[query]]/+page.svelte` → `/search` or `/search/svelte` |
+| `[...rest]`    | Rest params    | `/docs/[...path]/+page.svelte` → `/docs/a/b/c`                   |
+
+## Route Groups
+
+| Pattern       | Purpose                      | URL                                            |
+| ------------- | ---------------------------- | ---------------------------------------------- |
+| `(group)`     | Group routes (no URL impact) | `/(app)/dashboard/+page.svelte` → `/dashboard` |
+| `(marketing)` | Separate layouts             | Different layout for marketing pages           |
+
+## Special Files
+
+- `hooks.server.ts` - Server hooks (handle function, runs on every
+  request)
+- `hooks.client.ts` - Client hooks (runs in browser)
+- `app.html` - HTML template
+- `service-worker.ts` - Service worker
+- `params/*.ts` - Param validators
+
+## Common Patterns
+
+```
+src/routes/
+├── +layout.svelte              # Root layout
+├── +layout.ts                  # Root data
+├── +page.svelte                # Homepage
+├── +error.svelte               # Root error boundary
+│
+├── (app)/                      # App routes (grouped)
+│   ├── +layout.svelte          # App layout (auth required)
+│   ├── dashboard/+page.svelte  # /dashboard
+│   └── settings/+page.svelte   # /settings
+│
+├── (marketing)/                # Marketing routes (grouped)
+│   ├── +layout.svelte          # Marketing layout
+│   ├── about/+page.svelte      # /about
+│   └── pricing/+page.svelte    # /pricing
+│
+├── blog/
+│   ├── +page.svelte            # /blog (list)
+│   └── [slug]/
+│       ├── +page.svelte        # /blog/post-title
+│       └── +page.server.ts     # Load post data
+│
+└── api/
+    └── posts/
+        └── +server.ts          # API: GET/POST /api/posts
+```
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/layout-patterns.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/layout-patterns.md
new file mode 100644
index 00000000..7b251d68
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/layout-patterns.md
@@ -0,0 +1,387 @@
+# Layout Patterns
+
+## Basic Layout
+
+```svelte
+<!-- src/routes/+layout.svelte -->
+<script>
+	let { children } = $props();
+</script>
+
+<header>Header</header>
+<main>{@render children()}</main>
+<footer>Footer</footer>
+```
+
+**Key points:**
+
+- Must declare `children` in `$props()`
+- Use `{@render children()}` to render nested content
+- Root layout wraps ALL pages
+
+## Nested Layouts
+
+Layouts inherit from parent layouts:
+
+```
+src/routes/
+├── +layout.svelte          # Root layout (all pages)
+└── dashboard/
+    ├── +layout.svelte      # Dashboard layout (dashboard pages only)
+    └── +page.svelte        # Uses both layouts
+```
+
+**Result:** Root layout wraps dashboard layout wraps page.
+
+**Rendering order:**
+
+```
+Root +layout.svelte
+  └─ Dashboard +layout.svelte
+      └─ +page.svelte
+```
+
+### Example: Nested Layout Pattern
+
+```svelte
+<!-- src/routes/+layout.svelte -->
+<script>
+	let { children } = $props();
+</script>
+
+<div class="app">
+	<nav>Global Nav</nav>
+	{@render children()}
+</div>
+```
+
+```svelte
+<!-- src/routes/dashboard/+layout.svelte -->
+<script>
+	let { children } = $props();
+</script>
+
+<div class="dashboard">
+	<aside>Dashboard Sidebar</aside>
+	<main>{@render children()}</main>
+</div>
+```
+
+```svelte
+<!-- src/routes/dashboard/+page.svelte --><h1>Dashboard Home</h1>
+```
+
+**Rendered HTML structure:**
+
+```html
+<div class="app">
+	<nav>Global Nav</nav>
+	<div class="dashboard">
+		<aside>Dashboard Sidebar</aside>
+		<main>
+			<h1>Dashboard Home</h1>
+		</main>
+	</div>
+</div>
+```
+
+## Layout Groups
+
+Use `(groups)` to organize without affecting URLs:
+
+```
+src/routes/
+├── (marketing)/
+│   ├── +layout.svelte      # Marketing layout
+│   ├── about/+page.svelte  # /about (uses marketing layout)
+│   └── pricing/+page.svelte # /pricing (uses marketing layout)
+│
+└── (app)/
+    ├── +layout.svelte      # App layout
+    ├── dashboard/+page.svelte  # /dashboard (uses app layout)
+    └── settings/+page.svelte   # /settings (uses app layout)
+```
+
+**Key points:**
+
+- Parentheses make groups invisible in URLs
+- `/about` route, NOT `/(marketing)/about`
+- Different layouts for different sections
+- Useful for authentication boundaries
+
+### Example: Marketing vs App Layouts
+
+```svelte
+<!-- src/routes/(marketing)/+layout.svelte -->
+<script>
+	let { children } = $props();
+</script>
+
+<header class="marketing-header">
+	<nav>
+		<a href="/">Home</a>
+		<a href="/about">About</a>
+		<a href="/login">Login</a>
+	</nav>
+</header>
+
+{@render children()}
+
+<footer>© 2024 Company</footer>
+```
+
+```svelte
+<!-- src/routes/(app)/+layout.svelte -->
+<script>
+	let { children, data } = $props();
+</script>
+
+<header class="app-header">
+	<nav>
+		<a href="/dashboard">Dashboard</a>
+		<a href="/settings">Settings</a>
+		<span>Welcome, {data.user.name}</span>
+	</nav>
+</header>
+
+{@render children()}
+```
+
+## Reset Layout
+
+Use `@` in filename to break layout inheritance:
+
+**NOT RECOMMENDED** - This feature is deprecated in SvelteKit 2+.
+
+Instead, use layout groups to create separate hierarchies:
+
+```
+src/routes/
+├── +layout.svelte          # Root layout (for most pages)
+├── (app)/
+│   └── +layout.svelte      # App layout
+└── (public)/
+    └── +layout.svelte      # Public layout (completely separate)
+```
+
+## Layout with Data Loading
+
+```svelte
+<!-- src/routes/+layout.server.ts -->
+export const load = async ({ locals }) => {
+	// Available to all child routes
+	return {
+		user: locals.user,
+	};
+};
+```
+
+```svelte
+<!-- src/routes/+layout.svelte -->
+<script>
+	let { children, data } = $props();
+</script>
+
+<header>
+	{#if data.user}
+		<span>Welcome, {data.user.name}</span>
+	{:else}
+		<a href="/login">Login</a>
+	{/if}
+</header>
+
+{@render children()}
+```
+
+## Conditional Layout Content
+
+```svelte
+<!-- +layout.svelte -->
+<script>
+	import { page } from '$app/stores';
+	let { children } = $props();
+</script>
+
+{#if !$page.url.pathname.startsWith('/admin')}
+	<header>Public Header</header>
+{/if}
+
+{@render children()}
+
+{#if !$page.url.pathname.includes('/checkout')}
+	<footer>Footer</footer>
+{/if}
+```
+
+**Better approach:** Use layout groups instead of conditionals.
+
+## Protected Layouts
+
+```typescript
+// src/routes/(app)/+layout.server.ts
+import { redirect } from '@sveltejs/kit';
+
+export const load = async ({ locals }) => {
+	if (!locals.user) {
+		throw redirect(303, '/login');
+	}
+
+	return {
+		user: locals.user,
+	};
+};
+```
+
+All routes under `(app)` group now require authentication.
+
+## Sharing Layout State
+
+```svelte
+<!-- src/routes/+layout.svelte -->
+<script>
+	import { setContext } from 'svelte';
+	let { children, data } = $props();
+
+	// Share state with all descendant components
+	setContext('user', data.user);
+</script>
+
+{@render children()}
+```
+
+```svelte
+<!-- Any child component -->
+<script>
+	import { getContext } from 'svelte';
+	const user = getContext('user');
+</script>
+
+<p>Hello, {user.name}</p>
+```
+
+## Layout Slot Props (Snippets)
+
+```svelte
+<!-- src/routes/dashboard/+layout.svelte -->
+<script>
+	let { children, header } = $props();
+</script>
+
+<div class="dashboard">
+	<aside>Sidebar</aside>
+	<div class="content">
+		{#if header}
+			<header>{@render header()}</header>
+		{/if}
+		<main>{@render children()}</main>
+	</div>
+</div>
+```
+
+```svelte
+<!-- src/routes/dashboard/+page.svelte -->
+{#snippet header()}
+	<h1>Custom Dashboard Header</h1>
+{/snippet}
+
+<p>Dashboard content</p>
+```
+
+## Common Patterns
+
+### Pattern 1: Auth Boundary
+
+```
+src/routes/
+├── +layout.svelte           # Root (no auth)
+├── (public)/
+│   ├── +layout.svelte       # Public layout (landing pages)
+│   ├── +page.svelte         # /
+│   └── about/+page.svelte   # /about
+└── (protected)/
+    ├── +layout.server.ts    # Check auth, redirect if not logged in
+    ├── +layout.svelte       # Protected layout (app UI)
+    ├── dashboard/+page.svelte  # /dashboard
+    └── settings/+page.svelte   # /settings
+```
+
+### Pattern 2: Multi-tenant with Shared Root
+
+```
+src/routes/
+├── +layout.svelte           # Root layout (shared)
+├── admin/
+│   ├── +layout.svelte       # Admin layout
+│   └── users/+page.svelte   # /admin/users
+└── client/
+    ├── +layout.svelte       # Client layout
+    └── projects/+page.svelte # /client/projects
+```
+
+### Pattern 3: Progressive Enhancement
+
+```svelte
+<!-- src/routes/+layout.svelte -->
+<script>
+	import { page } from '$app/stores';
+	import { navigating } from '$app/stores';
+	let { children } = $props();
+</script>
+
+<div class="app">
+	{#if $navigating}
+		<div class="loading-bar"></div>
+	{/if}
+
+	{@render children()}
+</div>
+
+<style>
+	.loading-bar {
+		position: fixed;
+		top: 0;
+		left: 0;
+		width: 100%;
+		height: 3px;
+		background: blue;
+		animation: loading 1s ease-in-out;
+	}
+</style>
+```
+
+## Layout Best Practices
+
+1. ✅ Keep root layout minimal (shared across ALL pages)
+2. ✅ Use layout groups for separate sections
+3. ✅ Load shared data in layout's load function
+4. ✅ Use context for sharing state with descendants
+5. ✅ Avoid too many nested layouts (max 2-3 levels)
+6. ✅ Don't put auth logic in root layout (use groups)
+7. ✅ Remember: layouts share data DOWN, not UP
+8. ❌ Avoid conditionals in layouts (use groups instead)
+
+## Debugging Layouts
+
+```svelte
+<!-- src/routes/+layout.svelte -->
+<script>
+	import { page } from '$app/stores';
+	let { children } = $props();
+
+	$effect(() => {
+		console.log('Current route:', $page.url.pathname);
+		console.log('Layout data:', $page.data);
+	});
+</script>
+
+{@render children()}
+```
+
+## Key Takeaways
+
+- Layouts wrap all child routes
+- Nested layouts create hierarchy (root → section → page)
+- Groups `(name)` organize without affecting URLs
+- Load data in `+layout.server.ts` to share with children
+- Use context to share reactive state
+- Keep layouts simple and focused
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/ssr-hydration.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/ssr-hydration.md
new file mode 100644
index 00000000..bc59f1ef
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/ssr-hydration.md
@@ -0,0 +1,92 @@
+# SSR & Hydration
+
+## The Problem
+
+SvelteKit runs on server (SSR) then hydrates in browser. Code using
+browser APIs (`window`, `document`, `localStorage`) fails on server.
+
+## Solution: Check for Browser
+
+```typescript
+import { browser } from '$app/environment';
+
+// In load function
+export const load = async () => {
+	const theme = browser ? localStorage.getItem('theme') : 'light';
+	return { theme };
+};
+```
+
+```svelte
+<!-- In component -->
+<script>
+	import { browser } from '$app/environment';
+	import { onMount } from 'svelte';
+
+	let data = $state(null);
+
+	// Option 1: Use browser check
+	if (browser) {
+		data = localStorage.getItem('data');
+	}
+
+	// Option 2: Use onMount (only runs in browser)
+	onMount(() => {
+		data = localStorage.getItem('data');
+	});
+
+	// Option 3: Use $effect with browser check
+	$effect(() => {
+		if (browser) {
+			data = localStorage.getItem('data');
+		}
+	});
+</script>
+```
+
+## Common Mistakes
+
+### ❌ Using window Without Check
+
+```typescript
+// WRONG - fails on server
+export const load = async () => {
+	const width = window.innerWidth; // ERROR on server
+	return { width };
+};
+
+// RIGHT
+import { browser } from '$app/environment';
+
+export const load = async () => {
+	const width = browser ? window.innerWidth : 1024;
+	return { width };
+};
+```
+
+### ❌ Accessing DOM in Load
+
+```typescript
+// WRONG
+export const load = async () => {
+	const el = document.getElementById('root'); // ERROR on server
+};
+
+// RIGHT - Do DOM stuff in onMount
+export const load = async () => {
+	return {};
+};
+// Then in component:
+onMount(() => {
+	const el = document.getElementById('root');
+});
+```
+
+## Disable SSR (Not Recommended)
+
+```typescript
+// +page.ts
+export const ssr = false; // Disables SSR for this page
+```
+
+Only use when absolutely necessary (e.g., heavy Canvas/WebGL).
diff --git a/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/svelte-boundary.md b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/svelte-boundary.md
new file mode 100644
index 00000000..e51be1d0
--- /dev/null
+++ b/packages/autoskills/skills-registry/svelte-runes/sveltekit-structure/references/svelte-boundary.md
@@ -0,0 +1,144 @@
+# svelte:boundary Component
+
+> Available in Svelte 5.3+
+
+## Two Purposes
+
+1. **Error boundaries** - catch rendering errors
+2. **Pending UI** - show loading state while `await` resolves
+
+## Basic Error Boundary
+
+```svelte
+<svelte:boundary onerror={(e, reset) => console.error(e)}>
+	<RiskyComponent />
+
+	{#snippet failed(error, reset)}
+		<p>Error: {error.message}</p>
+		<button onclick={reset}>Try again</button>
+	{/snippet}
+</svelte:boundary>
+```
+
+## Pending UI (Loading States)
+
+With `experimental.async: true` (Svelte 5.36+), use declaration tags for
+local awaited values inside boundaries. `{@const ...}` is legacy syntax.
+
+```svelte
+<svelte:boundary>
+	{#snippet pending()}
+		<LoadingSpinner />
+	{/snippet}
+
+	{const data = await load_data()}
+	<DataView {data} />
+</svelte:boundary>
+```
+
+For pages with shared queries or navigation-sensitive data, `{#await}` remains
+the safest explicit loading pattern:
+
+```svelte
+{#await load_data()}
+	<LoadingSpinner />
+{:then data}
+	<DataView {data} />
+{:catch error}
+	<p>Error: {error.message}</p>
+{/await}
+```
+
+## Combined Error + Pending
+
+Use `svelte:boundary` for **error catching only**, with `{#await}` for
+async data:
+
+```svelte
+<svelte:boundary onerror={logError}>
+	{#snippet failed(error, reset)}
+		<p>Failed to load user</p>
+		<button onclick={reset}>Retry</button>
+	{/snippet}
+
+	{#await fetchUser()}
+		<p>Loading user...</p>
+	{:then user}
+		<UserProfile {user} />
+	{:catch error}
+		<p>Error: {error.message}</p>
+	{/await}
+</svelte:boundary>
+```
+
+## What Gets Caught
+
+**Caught:**
+
+- Errors during rendering
+- Errors in `$effect`
+
+**NOT Caught:**
+
+- Event handler errors (`onclick`, etc.)
+- Errors after `setTimeout`
+- Async errors outside boundary's await
+
+## vs +error.svelte
+
+| Feature  | svelte:boundary         | +error.svelte |
+| -------- | ----------------------- | ------------- |
+| Scope    | Component subtree       | Route segment |
+| Reset    | Built-in reset function | Navigate away |
+| Pending  | Yes (pending snippet)   | No            |
+| Use case | Component-level         | Page-level    |
+
+## Error Tracking Integration
+
+```svelte
+<svelte:boundary
+	onerror={(error, reset) => {
+		// Send to Sentry, LogRocket, etc.
+		errorTracker.captureException(error);
+	}}
+>
+	<App />
+
+	{#snippet failed(error, reset)}
+		<ErrorFallback {error} {reset} />
+	{/snippet}
+</svelte:boundary>
+```
+
+## Nested Boundaries
+
+Inner boundary catches first:
+
+```svelte
+<svelte:boundary>
+	<!-- Outer fallback -->
+	{#snippet failed(e)}
+		<p>Outer caught: {e.message}</p>
+	{/snippet}
+
+	<svelte:boundary>
+		<!-- Inner fallback -->
+		{#snippet failed(e)}
+			<p>Inner caught: {e.message}</p>
+		{/snippet}
+
+		<ComponentThatMightFail />
+	</svelte:boundary>
+</svelte:boundary>
+```
+
+## Key Points
+
+- Use `svelte:boundary` for component-level error isolation
+- Use `+error.svelte` for route-level error pages
+- `pending` snippet shows only on **initial** load (not on refresh - no flicker)
+- `failed` snippet replaces content on error
+- `reset` function lets users retry
+- Errors in event handlers are NOT caught
+- Requires `experimental.async: true` in Svelte compiler options (prefer the SvelteKit Vite plugin config) for `await` in declaration tags
+- Prefer `{const value = await ...}` over legacy `{@const ...}` syntax
diff --git a/packages/autoskills/skills-registry/svelte5-best-practices/SKILL.md b/packages/autoskills/skills-registry/svelte5-best-practices/SKILL.md
deleted file mode 100644
index b5041427..00000000
--- a/packages/autoskills/skills-registry/svelte5-best-practices/SKILL.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-name: svelte5-best-practices
-description: "Svelte 5 runes, snippets, SvelteKit patterns, and modern best practices for TypeScript and component development. Use when writing, reviewing, or refactoring Svelte 5 components and SvelteKit applications. Triggers on: Svelte components, runes ($state, $derived, $effect, $props, $bindable, $inspect), snippets ({#snippet}, {@render}), event handling, SvelteKit data loading, form actions, Svelte 4 to Svelte 5 migration, store to rune migration, slots to snippets migration, TypeScript props typing, generic components, SSR state isolation, performance optimization, or component testing."
-license: MIT
-metadata:
-  author: ejirocodes
-  version: '1.0.0'
----
-
-# Svelte 5 Best Practices
-
-## Quick Reference
-
-| Topic | When to Use | Reference |
-|-------|-------------|-----------|
-| **Runes** | $state, $derived, $effect, $props, $bindable, $inspect | [runes.md](references/runes.md) |
-| **Snippets** | Replacing slots, {#snippet}, {@render} | [snippets.md](references/snippets.md) |
-| **Events** | onclick handlers, callback props, context API | [events.md](references/events.md) |
-| **TypeScript** | Props typing, generic components | [typescript.md](references/typescript.md) |
-| **Migration** | Svelte 4 to 5, stores to runes | [migration.md](references/migration.md) |
-| **SvelteKit** | Load functions, form actions, SSR, page typing | [sveltekit.md](references/sveltekit.md) |
-| **Performance** | Universal reactivity, avoiding over-reactivity, streaming | [performance.md](references/performance.md) |
-
-## Essential Patterns
-
-### Reactive State
-
-```svelte
-<script>
-  let count = $state(0);           // Reactive state
-  let doubled = $derived(count * 2); // Computed value
-</script>
-```
-
-### Component Props
-
-```svelte
-<script>
-  let { name, count = 0 } = $props();
-  let { value = $bindable() } = $props(); // Two-way binding
-</script>
-```
-
-### Snippets (replacing slots)
-
-```svelte
-<script>
-  let { children, header } = $props();
-</script>
-
-{@render header?.()}
-{@render children()}
-```
-
-### Event Handlers
-
-```svelte
-<!-- Svelte 5: use onclick, not on:click -->
-<button onclick={() => count++}>Click</button>
-```
-
-### Callback Props (replacing createEventDispatcher)
-
-```svelte
-<script>
-  let { onclick } = $props();
-</script>
-
-<button onclick={() => onclick?.({ data })}>Click</button>
-```
-
-## Common Mistakes
-
-1. **Using `let` without `$state`** - Variables are not reactive without `$state()`
-2. **Using `$effect` for derived values** - Use `$derived` instead
-3. **Using `on:click` syntax** - Use `onclick` in Svelte 5
-4. **Using `createEventDispatcher`** - Use callback props instead
-5. **Using `<slot>`** - Use snippets with `{@render}`
-6. **Forgetting `$bindable()`** - Required for `bind:` to work
-7. **Setting module-level state in SSR** - Causes cross-request leaks
-8. **Sequential awaits in load functions** - Use `Promise.all` for parallel requests
diff --git a/packages/autoskills/skills-registry/svelte5-best-practices/references/events.md b/packages/autoskills/skills-registry/svelte5-best-practices/references/events.md
deleted file mode 100644
index 5cf1c9a5..00000000
--- a/packages/autoskills/skills-registry/svelte5-best-practices/references/events.md
+++ /dev/null
@@ -1,353 +0,0 @@
-# Svelte 5 Events Reference
-
-## Table of Contents
-- [Event Handler Syntax](#event-handler-syntax)
-- [Callback Props Pattern](#callback-props-pattern)
-- [Context API](#context-api)
-
----
-
-## Event Handler Syntax
-
-Svelte 5 replaces `on:click` directive syntax with standard HTML attribute syntax `onclick`.
-
-### Basic Event Handlers
-
-**Svelte 4:**
-```svelte
-<button on:click={handleClick}>Click</button>
-<input on:input={handleInput} />
-<form on:submit={handleSubmit}>...</form>
-```
-
-**Svelte 5:**
-```svelte
-<button onclick={handleClick}>Click</button>
-<input oninput={handleInput} />
-<form onsubmit={handleSubmit}>...</form>
-```
-
-### Event Modifiers Migration
-
-Event modifiers no longer exist. Use wrapper functions:
-
-**Svelte 4:**
-```svelte
-<form on:submit|preventDefault={handleSubmit}>...</form>
-<button on:click|stopPropagation={handleClick}>...</button>
-```
-
-**Svelte 5:**
-```svelte
-<script>
-  function handleSubmit(event) {
-    event.preventDefault();
-    // ... handle form
-  }
-
-  function handleClick(event) {
-    event.stopPropagation();
-    // ... handle click
-  }
-</script>
-
-<form onsubmit={handleSubmit}>...</form>
-<button onclick={handleClick}>...</button>
-```
-
-### Capture, Passive, and NonPassive
-
-```svelte
-<!-- Capture phase -->
-<div onclickcapture={handleCapture}>
-  <button onclick={handleClick}>Click</button>
-</div>
-
-<!-- Passive listener -->
-<div ontouchstartpassive={handleTouch}>...</div>
-
-<!-- Non-passive -->
-<div ontouchmovenonpassive={(e) => e.preventDefault()}>...</div>
-```
-
-### Inline Handlers
-
-```svelte
-<button onclick={() => count++}>Count: {count}</button>
-<input oninput={(e) => name = e.target.value} />
-```
-
-### Event Handler Shorthand
-
-```svelte
-<script>
-  function onclick(event) {
-    console.log('Clicked!', event);
-  }
-</script>
-
-<button {onclick}>Click</button>
-```
-
-### Spreading Event Handlers
-
-```svelte
-<script>
-  let handlers = {
-    onclick: () => console.log('clicked'),
-    onmouseenter: () => console.log('entered'),
-    onmouseleave: () => console.log('left')
-  };
-</script>
-
-<button {...handlers}>Hover or Click</button>
-```
-
-### Multiple Handlers for Same Event
-
-In Svelte 5, combine logic into one handler:
-
-```svelte
-<script>
-  function handleClick(event) {
-    handler1(event);
-    handler2(event);
-  }
-</script>
-
-<button onclick={handleClick}>...</button>
-```
-
-### TypeScript Event Typing
-
-```svelte
-<script lang="ts">
-  function handleClick(event: MouseEvent) {
-    console.log(event.clientX, event.clientY);
-  }
-
-  function handleInput(event: Event) {
-    const target = event.target as HTMLInputElement;
-    console.log(target.value);
-  }
-
-  function handleSubmit(event: SubmitEvent) {
-    event.preventDefault();
-    const formData = new FormData(event.currentTarget as HTMLFormElement);
-  }
-</script>
-```
-
----
-
-## Callback Props Pattern
-
-Svelte 5 deprecates `createEventDispatcher` in favor of callback props for component-to-parent communication.
-
-### Basic Event Pattern
-
-**Svelte 4:**
-```svelte
-<!-- Button.svelte -->
-<script>
-  import { createEventDispatcher } from 'svelte';
-  const dispatch = createEventDispatcher();
-</script>
-
-<button on:click={() => dispatch('click', { timestamp: Date.now() })}>Click</button>
-
-<!-- Parent.svelte -->
-<Button on:click={(e) => console.log(e.detail)} />
-```
-
-**Svelte 5:**
-```svelte
-<!-- Button.svelte -->
-<script>
-  let { onclick } = $props();
-</script>
-
-<button onclick={() => onclick?.({ timestamp: Date.now() })}>Click</button>
-
-<!-- Parent.svelte -->
-<Button onclick={(data) => console.log(data)} />
-```
-
-### Multiple Callbacks
-
-```svelte
-<!-- Dialog.svelte -->
-<script>
-  let { onconfirm, oncancel, onclose } = $props();
-</script>
-
-<dialog>
-  <button onclick={() => onconfirm?.()}>Confirm</button>
-  <button onclick={() => oncancel?.()}>Cancel</button>
-  <button onclick={() => onclose?.()}>X</button>
-</dialog>
-
-<!-- Parent.svelte -->
-<Dialog
-  onconfirm={() => save()}
-  oncancel={() => reset()}
-  onclose={() => visible = false}
-/>
-```
-
-### Typed Callbacks with TypeScript
-
-```svelte
-<script lang="ts">
-  interface Props {
-    value?: string;
-    onsearch?: (query: string) => void;
-    onchange?: (value: string) => void;
-    onclear?: () => void;
-  }
-
-  let { value = '', onsearch, onchange, onclear }: Props = $props();
-
-  function handleInput(e: Event) {
-    const newValue = (e.target as HTMLInputElement).value;
-    value = newValue;
-    onchange?.(newValue);
-  }
-</script>
-```
-
-### Forwarding Native Events
-
-```svelte
-<script lang="ts">
-  import type { MouseEventHandler } from 'svelte/elements';
-
-  interface Props {
-    onclick?: MouseEventHandler<HTMLButtonElement>;
-    children: import('svelte').Snippet;
-  }
-
-  let { onclick, children, ...rest }: Props = $props();
-</script>
-
-<button {onclick} {...rest}>{@render children()}</button>
-```
-
----
-
-## Context API
-
-Context functions must be called synchronously during component initialization.
-
-### Correct Context Usage
-
-```svelte
-<script>
-  import { setContext, getContext } from 'svelte';
-
-  // These run during initialization - CORRECT
-  setContext('theme', 'dark');
-  const theme = getContext('theme');
-
-  // INCORRECT - in $effect or callback
-  // $effect(() => { setContext('theme', 'dark'); }); // ERROR
-</script>
-```
-
-### Reactive Context Values
-
-Pass `$state` objects for reactive context:
-
-```svelte
-<!-- Provider.svelte -->
-<script>
-  import { setContext } from 'svelte';
-
-  let theme = $state('light');
-
-  setContext('theme', {
-    get current() { return theme; },
-    toggle() { theme = theme === 'light' ? 'dark' : 'light'; }
-  });
-
-  let { children } = $props();
-</script>
-
-{@render children()}
-
-<!-- Consumer.svelte -->
-<script>
-  import { getContext } from 'svelte';
-  const themeContext = getContext('theme');
-</script>
-
-<p>Theme: {themeContext.current}</p>
-<button onclick={themeContext.toggle}>Toggle</button>
-```
-
-### Type-Safe Context Pattern
-
-```ts
-// context.ts
-import { setContext, getContext } from 'svelte';
-
-const THEME_KEY = Symbol('theme');
-
-interface ThemeContext {
-  current: 'light' | 'dark';
-  toggle: () => void;
-}
-
-export function setThemeContext(context: ThemeContext) {
-  setContext(THEME_KEY, context);
-}
-
-export function getThemeContext(): ThemeContext {
-  const context = getContext<ThemeContext>(THEME_KEY);
-  if (!context) throw new Error('Theme context not found');
-  return context;
-}
-```
-
-### Avoid Generic Keys
-
-```svelte
-<script>
-  // Option 1: Symbol
-  const USER_KEY = Symbol('user');
-  setContext(USER_KEY, userData);
-
-  // Option 2: Unique string
-  setContext('myapp:user', userData);
-
-  // Option 3: Object key
-  const userKey = {};
-  setContext(userKey, userData);
-</script>
-```
-
-### hasContext Check
-
-```svelte
-<script>
-  import { hasContext, getContext } from 'svelte';
-
-  const hasTheme = hasContext('theme');
-  const theme = hasTheme ? getContext('theme') : { current: 'light' };
-</script>
-```
-
-### Context Boundaries
-
-Context flows down the component tree:
-
-```svelte
-<!-- Parent.svelte -->
-<script>
-  import { getContext, setContext } from 'svelte';
-  const level = getContext('level'); // 0
-  setContext('level', level + 1); // Override for children
-</script>
-
-<Child /> <!-- Will see level = 1 -->
-```
diff --git a/packages/autoskills/skills-registry/svelte5-best-practices/references/migration.md b/packages/autoskills/skills-registry/svelte5-best-practices/references/migration.md
deleted file mode 100644
index 7d1d8632..00000000
--- a/packages/autoskills/skills-registry/svelte5-best-practices/references/migration.md
+++ /dev/null
@@ -1,339 +0,0 @@
-# Svelte 4 to Svelte 5 Migration Reference
-
-## Table of Contents
-- [Migrating Reactive Statements](#migrating-reactive-statements)
-- [Migrating Stores to Runes](#migrating-stores-to-runes)
-
----
-
-## Migrating Reactive Statements
-
-Svelte 5 replaces `$:` with `$derived` (for values) and `$effect` (for side effects).
-
-### Computed Values: $: to $derived
-
-**Svelte 4:**
-```svelte
-<script>
-  let count = 0;
-  $: doubled = count * 2;
-  $: quadrupled = doubled * 2;
-</script>
-```
-
-**Svelte 5:**
-```svelte
-<script>
-  let count = $state(0);
-  let doubled = $derived(count * 2);
-  let quadrupled = $derived(doubled * 2);
-</script>
-```
-
-### Complex Computed Values: $derived.by
-
-**Svelte 4:**
-```svelte
-<script>
-  let items = [];
-  let filter = 'all';
-
-  $: filteredItems = {
-    if (filter === 'all') return items;
-    if (filter === 'active') return items.filter(i => !i.done);
-    return items.filter(i => i.done);
-  };
-</script>
-```
-
-**Svelte 5:**
-```svelte
-<script>
-  let items = $state([]);
-  let filter = $state('all');
-
-  let filteredItems = $derived.by(() => {
-    if (filter === 'all') return items;
-    if (filter === 'active') return items.filter(i => !i.done);
-    return items.filter(i => i.done);
-  });
-</script>
-```
-
-### Side Effects: $: to $effect
-
-**Svelte 4:**
-```svelte
-<script>
-  let count = 0;
-  $: console.log('Count changed:', count);
-  $: document.title = `Count: ${count}`;
-</script>
-```
-
-**Svelte 5:**
-```svelte
-<script>
-  let count = $state(0);
-
-  $effect(() => { console.log('Count changed:', count); });
-  $effect(() => { document.title = `Count: ${count}`; });
-</script>
-```
-
-### Conditional Side Effects
-
-**Svelte 4:**
-```svelte
-<script>
-  let value;
-  $: if (value > 100) { alert('Value too high!'); }
-</script>
-```
-
-**Svelte 5:**
-```svelte
-<script>
-  let value = $state(0);
-
-  $effect(() => {
-    if (value > 100) { alert('Value too high!'); }
-  });
-</script>
-```
-
-### Props Migration
-
-**Svelte 4:**
-```svelte
-<script>
-  export let name;
-  export let count = 0;
-  $: greeting = `Hello, ${name}!`;
-</script>
-```
-
-**Svelte 5:**
-```svelte
-<script>
-  let { name, count = 0 } = $props();
-  let greeting = $derived(`Hello, ${name}!`);
-</script>
-```
-
-### Effect with Cleanup
-
-**Svelte 4:**
-```svelte
-<script>
-  import { onDestroy } from 'svelte';
-
-  let count = 0;
-  let interval;
-
-  $: {
-    clearInterval(interval);
-    interval = setInterval(() => console.log(count), 1000);
-  }
-
-  onDestroy(() => clearInterval(interval));
-</script>
-```
-
-**Svelte 5:**
-```svelte
-<script>
-  let count = $state(0);
-
-  $effect(() => {
-    const interval = setInterval(() => console.log(count), 1000);
-    return () => clearInterval(interval); // Cleanup built-in
-  });
-</script>
-```
-
-### Migration Cheat Sheet
-
-| Svelte 4 Pattern | Svelte 5 Replacement |
-|------------------|----------------------|
-| `let x = 0` (in component) | `let x = $state(0)` |
-| `export let prop` | `let { prop } = $props()` |
-| `$: derived = expr` | `let derived = $derived(expr)` |
-| `$: { complex }` (value) | `let x = $derived.by(() => { ... })` |
-| `$: console.log(x)` | `$effect(() => console.log(x))` |
-| `$: if (x) { ... }` | `$effect(() => { if (x) { ... } })` |
-| `$: document.title = x` | `$effect(() => { document.title = x })` |
-
-### Automated Migration
-
-```bash
-npx sv migrate svelte-5
-```
-
----
-
-## Migrating Stores to Runes
-
-Svelte 5 runes can replace most store use cases with simpler, more direct reactive state.
-
-### Local Component State
-
-**Svelte 4:**
-```svelte
-<script>
-  import { writable } from 'svelte/store';
-
-  const count = writable(0);
-  function increment() { count.update(n => n + 1); }
-</script>
-
-<button on:click={increment}>Count: {$count}</button>
-```
-
-**Svelte 5:**
-```svelte
-<script>
-  let count = $state(0);
-  function increment() { count++; }
-</script>
-
-<button onclick={increment}>Count: {count}</button>
-```
-
-### Shared State Across Components
-
-**Svelte 4 (stores.ts):**
-```ts
-import { writable } from 'svelte/store';
-export const user = writable(null);
-export const theme = writable('light');
-```
-
-**Svelte 5 (state.svelte.ts):**
-```ts
-export const user = $state<User | null>(null);
-export const theme = $state({ current: 'light' as 'light' | 'dark' });
-
-export function setTheme(newTheme: 'light' | 'dark') {
-  theme.current = newTheme;
-}
-```
-
-```svelte
-<script>
-  import { theme, setTheme } from './state.svelte';
-</script>
-
-<p>Theme: {theme.current}</p>
-<button onclick={() => setTheme('dark')}>Dark Mode</button>
-```
-
-### Derived Store to $derived
-
-**Svelte 4:**
-```ts
-import { writable, derived } from 'svelte/store';
-export const items = writable([]);
-export const completedCount = derived(items, $items =>
-  $items.filter(i => i.done).length
-);
-```
-
-**Svelte 5:**
-```ts
-// state.svelte.ts
-export const items = $state<Item[]>([]);
-
-export function getCompletedCount() {
-  return items.filter(i => i.done).length;
-}
-```
-
-```svelte
-<script>
-  import { items } from './state.svelte';
-  let completedCount = $derived(items.filter(i => i.done).length);
-</script>
-```
-
-### Custom Store to Reactive Class
-
-**Svelte 4:**
-```ts
-function createCounter() {
-  const { subscribe, set, update } = writable(0);
-  return {
-    subscribe,
-    increment: () => update(n => n + 1),
-    decrement: () => update(n => n - 1),
-    reset: () => set(0)
-  };
-}
-export const counter = createCounter();
-```
-
-**Svelte 5:**
-```ts
-// counter.svelte.ts
-class Counter {
-  value = $state(0);
-  increment() { this.value++; }
-  decrement() { this.value--; }
-  reset() { this.value = 0; }
-}
-
-export const counter = new Counter();
-```
-
-```svelte
-<script>
-  import { counter } from './counter.svelte';
-</script>
-
-<p>{counter.value}</p>
-<button onclick={() => counter.increment()}>+</button>
-```
-
-### Async State Pattern
-
-**Svelte 5:**
-```ts
-// api.svelte.ts
-export const state = $state({
-  data: null as Data | null,
-  loading: false,
-  error: null as Error | null
-});
-
-export async function fetchData() {
-  state.loading = true;
-  state.error = null;
-
-  try {
-    const res = await fetch('/api/data');
-    state.data = await res.json();
-  } catch (e) {
-    state.error = e as Error;
-  } finally {
-    state.loading = false;
-  }
-}
-```
-
-### When to Still Use Stores
-
-1. **Library interop** - Libraries that expect Svelte stores
-2. **Legacy code** - Gradual migration
-3. **Observable patterns** - When you need the subscribe API
-4. **Server-side rendering** - Stores have built-in SSR handling
-
-### Store to Rune Cheat Sheet
-
-| Store Pattern | Rune Replacement |
-|---------------|------------------|
-| `writable(value)` | `$state(value)` |
-| `$store` (auto-subscribe) | Direct access to `$state` value |
-| `store.set(x)` | `state = x` |
-| `store.update(fn)` | Direct mutation or reassignment |
-| `derived(store, fn)` | `$derived(fn())` in component |
-| `readable(value, start)` | `$state` + `$effect` for setup |
diff --git a/packages/autoskills/skills-registry/svelte5-best-practices/references/performance.md b/packages/autoskills/skills-registry/svelte5-best-practices/references/performance.md
deleted file mode 100644
index 631f2d09..00000000
--- a/packages/autoskills/skills-registry/svelte5-best-practices/references/performance.md
+++ /dev/null
@@ -1,443 +0,0 @@
-# Svelte 5 Performance Reference
-
-## Table of Contents
-- [Universal Reactivity](#universal-reactivity)
-- [Avoiding Over-Reactivity](#avoiding-over-reactivity)
-- [Preventing Load Waterfalls](#preventing-load-waterfalls)
-- [Streaming Non-Critical Data](#streaming-non-critical-data)
-- [Component Testing](#component-testing)
-
----
-
-## Universal Reactivity
-
-Svelte 5 allows runes in `.svelte.js` or `.svelte.ts` files for shared state outside components.
-
-### Shared Counter State
-
-```ts
-// counter.svelte.ts
-export const counter = $state({ count: 0 });
-
-export function increment() { counter.count++; }
-export function decrement() { counter.count--; }
-export function reset() { counter.count = 0; }
-```
-
-```svelte
-<script>
-  import { counter, increment } from './counter.svelte';
-</script>
-
-<p>Count: {counter.count}</p>
-<button onclick={increment}>+</button>
-```
-
-### Object State with Getters
-
-```ts
-// user.svelte.ts
-const state = $state<User>({ firstName: '', lastName: '', email: '' });
-
-export const user = {
-  get firstName() { return state.firstName; },
-  set firstName(v: string) { state.firstName = v; },
-  get fullName() { return `${state.firstName} ${state.lastName}`; },
-  get isValid() { return state.firstName && state.email.includes('@'); }
-};
-```
-
-### Reactive Class Pattern
-
-```ts
-// todo.svelte.ts
-class TodoStore {
-  items = $state<Todo[]>([]);
-  filter = $state<'all' | 'active' | 'completed'>('all');
-
-  get filtered() {
-    switch (this.filter) {
-      case 'active': return this.items.filter(t => !t.done);
-      case 'completed': return this.items.filter(t => t.done);
-      default: return this.items;
-    }
-  }
-
-  add(text: string) {
-    this.items.push({ id: Date.now(), text, done: false });
-  }
-}
-
-export const todos = new TodoStore();
-```
-
-### Important Notes
-
-1. **File extension matters**: Must use `.svelte.js` or `.svelte.ts`
-2. **No $derived in module scope**: Use getters for derived values
-3. **SSR caution**: Avoid initializing browser-only state at module level
-
----
-
-## Avoiding Over-Reactivity
-
-Common mistakes with runes can cause unnecessary re-renders, infinite loops, or degraded performance.
-
-### Anti-Pattern 1: Using $effect to Set Derived Values
-
-**WRONG:**
-```svelte
-<script>
-  let count = $state(0);
-  let doubled = $state(0);
-  $effect(() => { doubled = count * 2; }); // Anti-pattern!
-</script>
-```
-
-**CORRECT:**
-```svelte
-<script>
-  let count = $state(0);
-  let doubled = $derived(count * 2);
-</script>
-```
-
-### Anti-Pattern 2: Circular Dependencies
-
-**WRONG:**
-```svelte
-<script>
-  let a = $state(1);
-  let b = $state(2);
-
-  $effect(() => {
-    if (a > 10) b = 0;
-    if (b > 10) a = 0; // Triggers the effect again!
-  });
-</script>
-```
-
-**CORRECT: Use separate effects or event handlers**
-
-### Anti-Pattern 3: Not Using untrack
-
-**WRONG:**
-```svelte
-<script>
-  let count = $state(0);
-  let log = $state([]);
-
-  $effect(() => {
-    log.push(`Count is ${count}`); // log change triggers re-run!
-  });
-</script>
-```
-
-**CORRECT:**
-```svelte
-<script>
-  import { untrack } from 'svelte';
-
-  let count = $state(0);
-  let log = $state([]);
-
-  $effect(() => {
-    untrack(() => { log.push(`Count is ${count}`); });
-  });
-</script>
-```
-
-### Anti-Pattern 4: Heavy Computations in $derived
-
-**WRONG:**
-```svelte
-<script>
-  let items = $state([/* thousands */]);
-  let filter = $state('');
-
-  let filtered = $derived(
-    items.filter(item => JSON.stringify(item).includes(filter))
-  );
-</script>
-```
-
-**CORRECT: Debounce expensive computations**
-```svelte
-<script>
-  let filter = $state('');
-  let debouncedFilter = $state('');
-
-  $effect(() => {
-    const timeout = setTimeout(() => { debouncedFilter = filter; }, 300);
-    return () => clearTimeout(timeout);
-  });
-
-  let filtered = $derived(
-    items.filter(item => item.name.includes(debouncedFilter))
-  );
-</script>
-```
-
-### Anti-Pattern 5: Effect for DOM Manipulation
-
-**WRONG:**
-```svelte
-<script>
-  let visible = $state(false);
-  let element;
-
-  $effect(() => {
-    if (element) element.style.display = visible ? 'block' : 'none';
-  });
-</script>
-```
-
-**CORRECT:**
-```svelte
-{#if visible}<div>Content</div>{/if}
-<!-- Or -->
-<div class:hidden={!visible}>Content</div>
-```
-
-### Performance Tips
-
-1. Use `$derived` over `$effect` for computed values
-2. Debounce expensive reactive computations
-3. Use `untrack` to prevent unnecessary dependencies
-4. Group related state into objects
-5. Let Svelte handle DOM updates
-
----
-
-## Preventing Load Waterfalls
-
-Sequential API calls multiply latency. Use parallel requests and streaming.
-
-### Anti-Pattern: Waterfall
-
-**WRONG (3 seconds total):**
-```ts
-export const load = async ({ fetch }) => {
-  const user = await fetch('/api/user').then(r => r.json());     // 1s
-  const posts = await fetch(`/api/users/${user.id}/posts`).then(r => r.json()); // 1s
-  const comments = await fetch('/api/comments').then(r => r.json()); // 1s
-  return { user, posts, comments };
-};
-```
-
-### Pattern 1: Parallel with Promise.all
-
-**CORRECT (1 second total):**
-```ts
-export const load = async ({ fetch }) => {
-  const [user, posts, comments] = await Promise.all([
-    fetch('/api/user').then(r => r.json()),
-    fetch('/api/posts').then(r => r.json()),
-    fetch('/api/comments').then(r => r.json())
-  ]);
-  return { user, posts, comments };
-};
-```
-
-### Pattern 2: Partial Dependencies
-
-```ts
-export const load = async ({ fetch }) => {
-  const user = await fetch('/api/user').then(r => r.json());
-
-  const [posts, followers] = await Promise.all([
-    fetch(`/api/users/${user.id}/posts`).then(r => r.json()),
-    fetch(`/api/users/${user.id}/followers`).then(r => r.json())
-  ]);
-
-  return { user, posts, followers };
-};
-```
-
-### Pattern 3: Streaming Non-Critical Data
-
-```ts
-export const load = async ({ fetch }) => {
-  const user = await fetch('/api/user').then(r => r.json());
-
-  return {
-    user,
-    recommendations: fetch('/api/recommendations').then(r => r.json()),
-    analytics: fetch('/api/analytics').then(r => r.json())
-  };
-};
-```
-
-### Performance Comparison
-
-| Pattern | 3 APIs x 1s each |
-|---------|------------------|
-| Sequential | 3 seconds |
-| Parallel (Promise.all) | 1 second |
-| Streaming | 0s initial, streams rest |
-
----
-
-## Streaming Non-Critical Data
-
-Return promises from load functions to stream non-essential data after initial page render.
-
-### Basic Streaming
-
-**WRONG (blocks on slow data):**
-```ts
-export const load = async ({ fetch }) => {
-  const user = await fetch('/api/user').then(r => r.json());     // 100ms
-  const analytics = await fetch('/api/analytics').then(r => r.json()); // 2000ms
-  return { user, analytics }; // Page blocked for 2.1 seconds
-};
-```
-
-**CORRECT (stream slow data):**
-```ts
-export const load = async ({ fetch }) => {
-  const user = await fetch('/api/user').then(r => r.json());
-  const analytics = fetch('/api/analytics').then(r => r.json()); // Don't await
-
-  return {
-    user,      // Available in 100ms
-    analytics  // Streams when ready
-  };
-};
-```
-
-### Component Handling
-
-```svelte
-<script lang="ts">
-  import type { PageProps } from './$types';
-  let { data }: PageProps = $props();
-</script>
-
-<header><h1>Welcome, {data.user.name}</h1></header>
-
-<aside>
-  {#await data.analytics}
-    <div class="skeleton">Loading analytics...</div>
-  {:then analytics}
-    <div class="analytics">
-      <p>Page views: {analytics.views}</p>
-    </div>
-  {:catch}
-    <div class="error">Failed to load analytics</div>
-  {/await}
-</aside>
-```
-
-### When to Stream
-
-| Data Type | Stream? | Reason |
-|-----------|---------|--------|
-| User info | No | Critical for layout |
-| Main content | No | Users came for this |
-| Analytics | Yes | Not user-facing |
-| Recommendations | Yes | Supplementary |
-| Comments | Maybe | Important but can load later |
-
----
-
-## Component Testing
-
-Svelte 5 components with runes require proper Vitest configuration.
-
-### Option 1: Vitest Browser Mode (Recommended)
-
-```ts
-// vitest.config.ts
-import { defineConfig } from 'vitest/config';
-import { svelte } from '@sveltejs/vite-plugin-svelte';
-
-export default defineConfig({
-  plugins: [svelte()],
-  test: {
-    browser: {
-      enabled: true,
-      provider: 'playwright',
-      name: 'chromium'
-    }
-  }
-});
-```
-
-### Option 2: JSDOM with @testing-library/svelte
-
-```ts
-// vitest.config.ts
-import { defineConfig } from 'vitest/config';
-import { svelte } from '@sveltejs/vite-plugin-svelte';
-
-export default defineConfig({
-  plugins: [svelte({ hot: !process.env.VITEST })],
-  test: {
-    environment: 'jsdom',
-    include: ['src/**/*.{test,spec}.{js,ts}'],
-    globals: true
-  }
-});
-```
-
-### Basic Component Test
-
-```ts
-import { render, screen, fireEvent } from '@testing-library/svelte';
-import { expect, test } from 'vitest';
-import Counter from './Counter.svelte';
-
-test('increments count when clicked', async () => {
-  render(Counter);
-
-  const button = screen.getByRole('button');
-  expect(button).toHaveTextContent('Count: 0');
-
-  await fireEvent.click(button);
-  expect(button).toHaveTextContent('Count: 1');
-});
-```
-
-### Testing Props
-
-```ts
-test('renders with custom name', () => {
-  render(Greeting, { props: { name: 'Alice' } });
-  expect(screen.getByText('Hello, Alice!')).toBeInTheDocument();
-});
-```
-
-### Testing Callbacks
-
-```ts
-import { vi } from 'vitest';
-
-test('calls onclick callback when clicked', async () => {
-  const handleClick = vi.fn();
-  render(Button, { props: { onclick: handleClick } });
-
-  await fireEvent.click(screen.getByRole('button'));
-  expect(handleClick).toHaveBeenCalledTimes(1);
-});
-```
-
-### Testing Async Components
-
-```ts
-import { waitFor } from '@testing-library/svelte';
-
-test('loads and displays user data', async () => {
-  global.fetch = vi.fn().mockResolvedValue({
-    ok: true,
-    json: () => Promise.resolve({ name: 'Alice' })
-  });
-
-  render(UserProfile, { props: { userId: '123' } });
-  expect(screen.getByText('Loading...')).toBeInTheDocument();
-
-  await waitFor(() => {
-    expect(screen.getByText('Alice')).toBeInTheDocument();
-  });
-});
-```
diff --git a/packages/autoskills/skills-registry/svelte5-best-practices/references/runes.md b/packages/autoskills/skills-registry/svelte5-best-practices/references/runes.md
deleted file mode 100644
index 2d773f22..00000000
--- a/packages/autoskills/skills-registry/svelte5-best-practices/references/runes.md
+++ /dev/null
@@ -1,394 +0,0 @@
-# Svelte 5 Runes Reference
-
-## Table of Contents
-- [$state - Reactive State](#state---reactive-state)
-- [$derived - Computed Values](#derived---computed-values)
-- [$effect - Side Effects](#effect---side-effects)
-- [$props - Component Props](#props---component-props)
-- [$bindable - Two-Way Binding](#bindable---two-way-binding)
-- [$inspect - Debugging](#inspect---debugging)
-
----
-
-## $state - Reactive State
-
-In Svelte 5, plain `let` declarations are no longer automatically reactive. Use `$state()` for reactive state.
-
-### Basic Usage
-
-```svelte
-<script>
-  let count = $state(0);
-</script>
-
-<button onclick={() => count++}>
-  Clicks: {count}
-</button>
-```
-
-### Object and Array State
-
-Objects and arrays are deeply reactive by default:
-
-```svelte
-<script>
-  let user = $state({ name: 'Alice', age: 30 });
-  let items = $state(['apple', 'banana']);
-</script>
-
-<button onclick={() => user.age++}>Age: {user.age}</button>
-<button onclick={() => items.push('cherry')}>Items: {items.length}</button>
-```
-
-### Class State
-
-```svelte
-<script>
-  class Counter {
-    count = $state(0);
-    increment() { this.count++; }
-  }
-  const counter = new Counter();
-</script>
-
-<button onclick={() => counter.increment()}>{counter.count}</button>
-```
-
-### Raw State (Opt-out of Deep Reactivity)
-
-```svelte
-<script>
-  let items = $state.raw([1, 2, 3]);
-
-  // This WON'T trigger an update:
-  items.push(4);
-
-  // This WILL trigger an update:
-  items = [...items, 4];
-</script>
-```
-
----
-
-## $derived - Computed Values
-
-Replaces `$:` reactive statements for computed values.
-
-### Basic Usage
-
-```svelte
-<script>
-  let count = $state(0);
-  let doubled = $derived(count * 2);
-  let quadrupled = $derived(doubled * 2);
-</script>
-```
-
-### Complex Derivations with $derived.by
-
-```svelte
-<script>
-  let items = $state([1, 2, 3, 4, 5]);
-  let filter = $state('even');
-
-  let filteredItems = $derived.by(() => {
-    if (filter === 'even') return items.filter(n => n % 2 === 0);
-    return items.filter(n => n % 2 !== 0);
-  });
-</script>
-```
-
-### Deriving from Props
-
-```svelte
-<script>
-  let { firstName, lastName } = $props();
-  let fullName = $derived(`${firstName} ${lastName}`);
-</script>
-```
-
-### $derived vs $effect
-
-Use `$derived` for computing values, `$effect` for side effects:
-
-```svelte
-<script>
-  let count = $state(0);
-
-  // CORRECT: Use $derived for computed values
-  let doubled = $derived(count * 2);
-
-  // INCORRECT: Don't use $effect to set derived values
-  // let doubled;
-  // $effect(() => { doubled = count * 2; }); // Anti-pattern!
-</script>
-```
-
----
-
-## $effect - Side Effects
-
-Runs code when component mounts and when dependencies change. Requires cleanup for subscriptions.
-
-### Basic Effect with Cleanup
-
-```svelte
-<script>
-  let count = $state(0);
-
-  $effect(() => {
-    const interval = setInterval(() => count++, 1000);
-    return () => clearInterval(interval); // Cleanup
-  });
-</script>
-```
-
-### DOM Event Listeners
-
-```svelte
-<script>
-  let mouseX = $state(0);
-  let mouseY = $state(0);
-
-  $effect(() => {
-    function handleMouseMove(event) {
-      mouseX = event.clientX;
-      mouseY = event.clientY;
-    }
-    window.addEventListener('mousemove', handleMouseMove);
-    return () => window.removeEventListener('mousemove', handleMouseMove);
-  });
-</script>
-```
-
-### External Subscriptions
-
-```svelte
-<script>
-  let { userId } = $props();
-  let userData = $state(null);
-
-  $effect(() => {
-    const unsubscribe = database.subscribe(`users/${userId}`, (data) => {
-      userData = data;
-    });
-    return () => unsubscribe();
-  });
-</script>
-```
-
-### $effect.pre for Pre-DOM Updates
-
-```svelte
-<script>
-  let div;
-  let messages = $state([]);
-
-  $effect.pre(() => {
-    if (div) {
-      const shouldScroll = div.scrollTop + div.clientHeight >= div.scrollHeight - 20;
-      if (shouldScroll) {
-        tick().then(() => { div.scrollTop = div.scrollHeight; });
-      }
-    }
-  });
-</script>
-```
-
-### Untracked Dependencies
-
-```svelte
-<script>
-  import { untrack } from 'svelte';
-
-  let count = $state(0);
-  let logCount = $state(0);
-
-  $effect(() => {
-    // Only runs when count changes, not logCount
-    console.log(count, untrack(() => logCount));
-  });
-</script>
-```
-
----
-
-## $props - Component Props
-
-Replaces `export let` for declaring component props.
-
-### Basic Usage
-
-```svelte
-<script>
-  let { name, count = 0, disabled = false } = $props();
-</script>
-```
-
-### Rest Props Pattern
-
-```svelte
-<script>
-  let { class: className, children, ...restProps } = $props();
-</script>
-
-<div class={className} {...restProps}>
-  {@render children?.()}
-</div>
-```
-
-### Renaming Reserved Words
-
-```svelte
-<script>
-  let {
-    class: className,  // 'class' is reserved
-    for: htmlFor,      // 'for' is reserved
-    ...rest
-  } = $props();
-</script>
-```
-
-### TypeScript Props
-
-```svelte
-<script lang="ts">
-  interface Props {
-    name: string;
-    count?: number;
-    onClick?: (event: MouseEvent) => void;
-  }
-
-  let { name, count = 0, onClick }: Props = $props();
-</script>
-```
-
-### Props with Children
-
-```svelte
-<script lang="ts">
-  import type { Snippet } from 'svelte';
-
-  interface Props {
-    title: string;
-    children: Snippet;
-    footer?: Snippet;
-  }
-
-  let { title, children, footer }: Props = $props();
-</script>
-
-<article>
-  <h1>{title}</h1>
-  <main>{@render children()}</main>
-  {#if footer}<footer>{@render footer()}</footer>{/if}
-</article>
-```
-
----
-
-## $bindable - Two-Way Binding
-
-Props must be explicitly marked with `$bindable()` to support `bind:`.
-
-### Basic Usage
-
-```svelte
-<!-- Input.svelte -->
-<script>
-  let { value = $bindable() } = $props();
-</script>
-
-<input bind:value />
-
-<!-- Parent.svelte -->
-<script>
-  import Input from './Input.svelte';
-  let name = $state('');
-</script>
-
-<Input bind:value={name} />
-```
-
-### Bindable with Default Value
-
-```svelte
-<script>
-  let { value = $bindable('default') } = $props();
-</script>
-```
-
-### Multiple Bindable Props
-
-```svelte
-<script>
-  let {
-    value = $bindable(''),
-    checked = $bindable(false),
-    selected = $bindable(null)
-  } = $props();
-</script>
-```
-
-### TypeScript with Bindable
-
-```svelte
-<script lang="ts">
-  interface Props {
-    value: string;
-    disabled?: boolean;
-  }
-
-  let { value = $bindable(''), disabled = false }: Props = $props();
-</script>
-```
-
----
-
-## $inspect - Debugging
-
-Development-only debugging that logs values when they change. Stripped in production.
-
-### Basic Usage
-
-```svelte
-<script>
-  let count = $state(0);
-  $inspect(count); // Logs every time count changes
-</script>
-```
-
-### Multiple Values
-
-```svelte
-<script>
-  let name = $state('Alice');
-  let age = $state(30);
-  $inspect(name, age);
-</script>
-```
-
-### Custom Logging with $inspect.with
-
-```svelte
-<script>
-  let user = $state({ name: 'Alice', age: 30 });
-
-  $inspect.with((type, ...values) => {
-    if (type === 'init') console.log('Initial value:', values);
-    else console.log('Updated to:', values);
-  }, user);
-</script>
-```
-
-### Debugging with Breakpoints
-
-```svelte
-<script>
-  let data = $state({ x: 0, y: 0 });
-
-  $inspect.with((type, value) => {
-    if (type === 'update' && value.x > 100) debugger;
-  }, data);
-</script>
-```
diff --git a/packages/autoskills/skills-registry/svelte5-best-practices/references/snippets.md b/packages/autoskills/skills-registry/svelte5-best-practices/references/snippets.md
deleted file mode 100644
index f5ad7cf5..00000000
--- a/packages/autoskills/skills-registry/svelte5-best-practices/references/snippets.md
+++ /dev/null
@@ -1,291 +0,0 @@
-# Svelte 5 Snippets Reference
-
-## Table of Contents
-- [Replacing Slots with Snippets](#replacing-slots-with-snippets)
-- [Rendering with @render](#rendering-with-render)
-
----
-
-## Replacing Slots with Snippets
-
-Svelte 5 replaces `<slot>` with snippets - a more powerful and type-safe composition primitive.
-
-### Default Content (children)
-
-**Svelte 4:**
-```svelte
-<div class="card"><slot /></div>
-```
-
-**Svelte 5:**
-```svelte
-<script>
-  let { children } = $props();
-</script>
-
-<div class="card">{@render children?.()}</div>
-```
-
-### Named Slots to Named Snippets
-
-**Svelte 4:**
-```svelte
-<header><slot name="header" /></header>
-<main><slot /></main>
-<footer><slot name="footer" /></footer>
-
-<!-- Usage -->
-<Layout>
-  <h1 slot="header">Title</h1>
-  <p>Content</p>
-  <span slot="footer">Footer</span>
-</Layout>
-```
-
-**Svelte 5:**
-```svelte
-<script>
-  let { header, children, footer } = $props();
-</script>
-
-<header>{@render header?.()}</header>
-<main>{@render children?.()}</main>
-<footer>{@render footer?.()}</footer>
-
-<!-- Usage -->
-<Layout>
-  {#snippet header()}<h1>Title</h1>{/snippet}
-  <p>Content</p>
-  {#snippet footer()}<span>Footer</span>{/snippet}
-</Layout>
-```
-
-### Slot Props to Snippet Parameters
-
-**Svelte 4:**
-```svelte
-<ul>
-  {#each items as item}
-    <li><slot {item} /></li>
-  {/each}
-</ul>
-
-<List {items} let:item>
-  <span>{item.name}</span>
-</List>
-```
-
-**Svelte 5:**
-```svelte
-<script>
-  let { items, children } = $props();
-</script>
-
-<ul>
-  {#each items as item}
-    <li>{@render children?.(item)}</li>
-  {/each}
-</ul>
-
-<List {items}>
-  {#snippet children(item)}
-    <span>{item.name}</span>
-  {/snippet}
-</List>
-```
-
-### Slot Fallback to Snippet Fallback
-
-```svelte
-<script>
-  let { children } = $props();
-</script>
-
-{#if children}
-  {@render children()}
-{:else}
-  <p>Default content</p>
-{/if}
-```
-
-### Defining Snippets Within Components
-
-```svelte
-<script>
-  let items = $state([
-    { id: 1, name: 'Item 1', type: 'normal' },
-    { id: 2, name: 'Item 2', type: 'featured' }
-  ]);
-</script>
-
-{#snippet normalItem(item)}
-  <li>{item.name}</li>
-{/snippet}
-
-{#snippet featuredItem(item)}
-  <li class="featured">*** {item.name} ***</li>
-{/snippet}
-
-<ul>
-  {#each items as item}
-    {#if item.type === 'featured'}
-      {@render featuredItem(item)}
-    {:else}
-      {@render normalItem(item)}
-    {/if}
-  {/each}
-</ul>
-```
-
-### TypeScript Typing
-
-```svelte
-<script lang="ts">
-  import type { Snippet } from 'svelte';
-
-  interface Item { id: number; name: string; }
-
-  interface Props {
-    header?: Snippet;
-    children: Snippet<[item: Item]>;
-    footer?: Snippet;
-  }
-
-  let { header, children, footer }: Props = $props();
-</script>
-```
-
----
-
-## Rendering with @render
-
-Snippets must be rendered using `{@render}`. Optional snippets need null-safe calling.
-
-### Basic Snippet Rendering
-
-```svelte
-<script>
-  let { children } = $props();
-</script>
-
-<div>{@render children()}</div>
-```
-
-### Optional Snippets
-
-Always use optional chaining for snippets that might not be provided:
-
-```svelte
-<script>
-  let { children } = $props();
-</script>
-
-{@render children?.()}
-```
-
-### Conditional Rendering
-
-```svelte
-<script>
-  let { header, children, footer } = $props();
-</script>
-
-{#if header}
-  <header>{@render header()}</header>
-{/if}
-
-<main>{@render children?.()}</main>
-
-{#if footer}
-  <footer>{@render footer()}</footer>
-{/if}
-```
-
-### Rendering with Arguments
-
-```svelte
-<script>
-  let { items, itemTemplate } = $props();
-</script>
-
-<ul>
-  {#each items as item, index}
-    <li>{@render itemTemplate(item, index)}</li>
-  {/each}
-</ul>
-
-<!-- Usage -->
-<List {items}>
-  {#snippet itemTemplate(item, index)}
-    <span>{index + 1}. {item.name}</span>
-  {/snippet}
-</List>
-```
-
-### Rendering Multiple Times
-
-Snippets can be rendered multiple times:
-
-```svelte
-<script>
-  let { icon } = $props();
-</script>
-
-<button>
-  {@render icon?.()}
-  <span>Click me</span>
-  {@render icon?.()}
-</button>
-```
-
-### Rendering Dynamic Snippets
-
-```svelte
-<script>
-  let { normalView, editView, isEditing } = $props();
-  let currentView = $derived(isEditing ? editView : normalView);
-</script>
-
-{@render currentView?.()}
-```
-
-### TypeScript with @render
-
-```svelte
-<script lang="ts">
-  import type { Snippet } from 'svelte';
-
-  interface Props {
-    children: Snippet;
-    header?: Snippet;
-    row: Snippet<[data: { id: number; name: string }]>;
-  }
-
-  let { children, header, row }: Props = $props();
-</script>
-
-{@render header?.()}
-{@render children()}
-{@render row({ id: 1, name: 'Test' })}
-```
-
-### Passing Snippets to Child Components
-
-```svelte
-<!-- Wrapper.svelte -->
-<script>
-  import Inner from './Inner.svelte';
-  let { itemRenderer } = $props();
-</script>
-
-<Inner {itemRenderer} />
-
-<!-- Inner.svelte -->
-<script>
-  let { itemRenderer } = $props();
-</script>
-
-{#each items as item}
-  {@render itemRenderer?.(item)}
-{/each}
-```
diff --git a/packages/autoskills/skills-registry/svelte5-best-practices/references/sveltekit.md b/packages/autoskills/skills-registry/svelte5-best-practices/references/sveltekit.md
deleted file mode 100644
index 816b83b5..00000000
--- a/packages/autoskills/skills-registry/svelte5-best-practices/references/sveltekit.md
+++ /dev/null
@@ -1,401 +0,0 @@
-# SvelteKit Patterns Reference
-
-## Table of Contents
-- [Load Function Types](#load-function-types)
-- [Page Props Typing](#page-props-typing)
-- [Form Actions Error Handling](#form-actions-error-handling)
-- [SSR State Isolation](#ssr-state-isolation)
-
----
-
-## Load Function Types
-
-SvelteKit has two load function types: universal (`+page.js`) and server-only (`+page.server.ts`).
-
-### When to Use Each
-
-| Use +page.server.ts | Use +page.js |
-|---------------------|--------------|
-| Accessing secrets/credentials | Public APIs only |
-| Database connections | Non-serializable data (functions, classes) |
-| Server-only APIs | Client-side caching benefits |
-| Sensitive business logic | |
-
-### Security: Secrets in Server Load
-
-**WRONG (secrets exposed):**
-```ts
-// +page.js - DANGEROUS: runs in browser!
-export const load = async ({ fetch }) => {
-  const response = await fetch('https://api.stripe.com/charges', {
-    headers: { 'Authorization': `Bearer ${STRIPE_SECRET_KEY}` } // EXPOSED!
-  });
-  return { charges: await response.json() };
-};
-```
-
-**CORRECT:**
-```ts
-// +page.server.ts - only runs on server
-import { STRIPE_SECRET_KEY } from '$env/static/private';
-
-export const load = async ({ fetch }) => {
-  const response = await fetch('https://api.stripe.com/charges', {
-    headers: { 'Authorization': `Bearer ${STRIPE_SECRET_KEY}` }
-  });
-  return { charges: await response.json() };
-};
-```
-
-### Serialization: Non-serializable in Universal Load
-
-**WRONG (server load can't serialize functions):**
-```ts
-// +page.server.ts
-export const load = async () => {
-  return {
-    formatDate: (date: Date) => date.toLocaleDateString(), // ERROR
-    parser: new DOMParser() // ERROR
-  };
-};
-```
-
-**CORRECT:**
-```ts
-// +page.js
-export const load = async () => {
-  return {
-    formatDate: (date: Date) => date.toLocaleDateString(), // OK
-    parser: typeof window !== 'undefined' ? new DOMParser() : null
-  };
-};
-```
-
-### Database Access
-
-```ts
-// +page.server.ts - CORRECT
-import { db } from '$lib/server/database';
-
-export const load = async () => {
-  const users = await db.query('SELECT * FROM users');
-  return { users };
-};
-```
-
-### Environment Variables
-
-```ts
-// +page.server.ts - Private env vars
-import { DATABASE_URL, API_SECRET } from '$env/static/private';
-
-// +page.js - Only public env vars
-import { PUBLIC_API_URL } from '$env/static/public';
-```
-
----
-
-## Page Props Typing
-
-SvelteKit generates types in `./$types` for full type safety with `$props()`.
-
-### Basic Page Data Typing
-
-```svelte
-<!-- +page.svelte -->
-<script lang="ts">
-  import type { PageProps } from './$types';
-
-  let { data }: PageProps = $props();
-</script>
-
-<h1>{data.title}</h1>
-```
-
-### Page Data with Form Actions
-
-```svelte
-<script lang="ts">
-  import type { PageProps } from './$types';
-
-  let { data, form }: PageProps = $props();
-</script>
-
-{#if form?.success}
-  <p class="success">{form.message}</p>
-{/if}
-
-{#if form?.error}
-  <p class="error">{form.error}</p>
-{/if}
-```
-
-### Layout Data Typing
-
-```svelte
-<!-- +layout.svelte -->
-<script lang="ts">
-  import type { LayoutProps } from './$types';
-
-  let { data, children }: LayoutProps = $props();
-</script>
-
-<nav>
-  {#if data.user}<span>Welcome, {data.user.name}</span>{/if}
-</nav>
-
-{@render children()}
-```
-
-### Corresponding Load Function
-
-```ts
-// +page.server.ts
-import type { PageServerLoad, Actions } from './$types';
-
-export const load: PageServerLoad = async () => {
-  return {
-    title: 'My Page',
-    items: await fetchItems()
-  };
-};
-
-export const actions: Actions = {
-  default: async ({ request }) => {
-    return { success: true, message: 'Saved successfully' };
-  }
-};
-```
-
-### Error Page
-
-```svelte
-<!-- +error.svelte -->
-<script lang="ts">
-  import { page } from '$app/state';
-</script>
-
-<h1>{page.status}: {page.error?.message}</h1>
-```
-
----
-
-## Form Actions Error Handling
-
-SvelteKit distinguishes between validation errors (`fail()`) and unexpected errors (`throw error()`).
-
-### Use fail() for Validation Errors
-
-**WRONG:**
-```ts
-import { error } from '@sveltejs/kit';
-
-export const actions = {
-  default: async ({ request }) => {
-    if (!email?.toString().includes('@')) {
-      throw error(400, 'Invalid email'); // Shows error page!
-    }
-  }
-};
-```
-
-**CORRECT:**
-```ts
-import { fail } from '@sveltejs/kit';
-
-export const actions = {
-  default: async ({ request }) => {
-    const data = await request.formData();
-    const email = data.get('email')?.toString() ?? '';
-
-    if (!email.includes('@')) {
-      return fail(400, {
-        error: 'Invalid email address',
-        email // Return for repopulation
-      });
-    }
-
-    return { success: true };
-  }
-};
-```
-
-### Use throw error() for Unexpected Errors
-
-```ts
-import { fail, error } from '@sveltejs/kit';
-
-export const actions = {
-  default: async ({ request }) => {
-    const data = await request.formData();
-
-    // Validation - use fail()
-    if (!data.get('title')) {
-      return fail(400, { error: 'Title is required' });
-    }
-
-    try {
-      await database.save(data);
-      return { success: true };
-    } catch (e) {
-      // Unexpected error - use throw
-      throw error(500, 'Unable to save. Please try again later.');
-    }
-  }
-};
-```
-
-### Structured Validation Responses
-
-```ts
-interface FormErrors {
-  email?: string;
-  password?: string;
-}
-
-export const actions = {
-  register: async ({ request }) => {
-    const data = await request.formData();
-    const errors: FormErrors = {};
-
-    if (!email) errors.email = 'Email is required';
-    if (password.length < 8) errors.password = 'Password must be at least 8 characters';
-
-    if (Object.keys(errors).length > 0) {
-      return fail(400, { errors, values: { email } });
-    }
-
-    return { success: true };
-  }
-};
-```
-
-### Handle in Component
-
-```svelte
-<script lang="ts">
-  import type { PageProps } from './$types';
-  import { enhance } from '$app/forms';
-
-  let { form }: PageProps = $props();
-</script>
-
-<form method="POST" action="?/register" use:enhance>
-  <label>
-    Email
-    <input name="email" value={form?.values?.email ?? ''} />
-    {#if form?.errors?.email}
-      <span class="error">{form.errors.email}</span>
-    {/if}
-  </label>
-  <button type="submit">Register</button>
-</form>
-```
-
-### Error Response Summary
-
-| Situation | Function | Result |
-|-----------|----------|--------|
-| Missing field | `fail(400, {...})` | Form state preserved |
-| Invalid format | `fail(400, {...})` | Form state preserved |
-| Not found | `throw error(404, ...)` | Error page |
-| Server crash | `throw error(500, ...)` | Error page |
-| Auth required | `throw redirect(303, ...)` | Redirect |
-
----
-
-## SSR State Isolation
-
-Shared server state persists across requests, potentially leaking data between users.
-
-### Dangerous: Module-Level State
-
-**WRONG:**
-```ts
-// +page.server.ts
-let currentUser = null; // SHARED ACROSS ALL REQUESTS!
-
-export const load = async ({ locals }) => {
-  currentUser = locals.user; // User B overwrites User A
-  return { user: currentUser };
-};
-```
-
-**CORRECT:**
-```ts
-export const load = async ({ locals }) => {
-  return { user: locals.user }; // Each request gets its own locals
-};
-```
-
-### Dangerous: Global Stores
-
-**WRONG:**
-```ts
-// stores.svelte.ts
-export const user = $state<User | null>(null); // Server-side singleton!
-```
-
-**CORRECT: Use locals and return data from load**
-```ts
-// +layout.server.ts
-export const load = async ({ locals }) => {
-  return { user: locals.user };
-};
-```
-
-### Safe Patterns
-
-**Pattern 1: Use locals**
-```ts
-// hooks.server.ts
-export const handle = async ({ event, resolve }) => {
-  event.locals.user = await authenticate(event);
-  event.locals.requestId = crypto.randomUUID();
-  return resolve(event);
-};
-
-// +page.server.ts
-export const load = async ({ locals }) => {
-  return { user: locals.user };
-};
-```
-
-**Pattern 2: Context for Component Trees**
-```svelte
-<!-- +layout.svelte -->
-<script lang="ts">
-  import { setContext } from 'svelte';
-  import type { LayoutProps } from './$types';
-
-  let { data, children }: LayoutProps = $props();
-
-  setContext('user', {
-    get current() { return data.user; }
-  });
-</script>
-
-{@render children()}
-```
-
-**Pattern 3: Client-Only State**
-```ts
-// stores.svelte.ts
-import { browser } from '$app/environment';
-
-function createClientStore() {
-  if (!browser) return { value: null };
-  const state = $state({ value: null });
-  return state;
-}
-
-export const clientState = createClientStore();
-```
-
-### SSR Safety Checklist
-
-- [ ] No module-level `let` variables that store user data
-- [ ] No global `$state` that gets set during SSR
-- [ ] No singleton service classes with mutable state
-- [ ] All user-specific data flows through `locals`
-- [ ] All page data comes from load function returns
diff --git a/packages/autoskills/skills-registry/svelte5-best-practices/references/typescript.md b/packages/autoskills/skills-registry/svelte5-best-practices/references/typescript.md
deleted file mode 100644
index d736bb6e..00000000
--- a/packages/autoskills/skills-registry/svelte5-best-practices/references/typescript.md
+++ /dev/null
@@ -1,305 +0,0 @@
-# Svelte 5 TypeScript Reference
-
-## Table of Contents
-- [Props Typing](#props-typing)
-- [Generic Components](#generic-components)
-
----
-
-## Props Typing
-
-`$props()` requires specific patterns for TypeScript typing.
-
-### Basic Props Typing
-
-**Inline typing:**
-```svelte
-<script lang="ts">
-  let { name, count = 0 }: { name: string; count?: number } = $props();
-</script>
-```
-
-**Interface typing (recommended):**
-```svelte
-<script lang="ts">
-  interface Props {
-    name: string;
-    count?: number;
-    disabled?: boolean;
-  }
-
-  let { name, count = 0, disabled = false }: Props = $props();
-</script>
-```
-
-### Children and Snippets Typing
-
-```svelte
-<script lang="ts">
-  import type { Snippet } from 'svelte';
-
-  interface Props {
-    children: Snippet;                    // Required children
-    header?: Snippet;                     // Optional snippet
-    row: Snippet<[data: RowData]>;       // Snippet with parameter
-    cell?: Snippet<[value: string, index: number]>;  // Multiple params
-  }
-
-  interface RowData { id: number; name: string; }
-
-  let { children, header, row, cell }: Props = $props();
-</script>
-```
-
-### Callback Props Typing
-
-```svelte
-<script lang="ts">
-  interface Props {
-    value: string;
-    onchange?: (value: string) => void;
-    onsubmit?: (data: FormData) => Promise<void>;
-    onclick?: (event: MouseEvent) => void;
-  }
-
-  let { value, onchange, onsubmit, onclick }: Props = $props();
-</script>
-```
-
-### Rest Props with HTML Attributes
-
-```svelte
-<script lang="ts">
-  import type { HTMLButtonAttributes } from 'svelte/elements';
-
-  interface Props extends HTMLButtonAttributes {
-    variant?: 'primary' | 'secondary';
-    loading?: boolean;
-  }
-
-  let { variant = 'primary', loading = false, ...rest }: Props = $props();
-</script>
-
-<button class={variant} disabled={loading} {...rest}>
-  {#if loading}Loading...{:else}{@render children?.()}{/if}
-</button>
-```
-
-### Input Element Props
-
-```svelte
-<script lang="ts">
-  import type { HTMLInputAttributes } from 'svelte/elements';
-
-  interface Props extends Omit<HTMLInputAttributes, 'value'> {
-    value?: string;
-    label: string;
-    error?: string;
-  }
-
-  let { value = $bindable(''), label, error, ...rest }: Props = $props();
-</script>
-```
-
-### Union Type Props
-
-```svelte
-<script lang="ts">
-  type ButtonVariant = 'primary' | 'secondary' | 'danger';
-  type ButtonSize = 'sm' | 'md' | 'lg';
-
-  interface Props {
-    variant?: ButtonVariant;
-    size?: ButtonSize;
-    children: Snippet;
-  }
-
-  let { variant = 'primary', size = 'md', children }: Props = $props();
-</script>
-
-<button class="{variant} {size}">{@render children()}</button>
-```
-
-### Discriminated Union Props
-
-```svelte
-<script lang="ts">
-  type Props =
-    | { type: 'link'; href: string; children: Snippet }
-    | { type: 'button'; onclick: () => void; children: Snippet };
-
-  let props: Props = $props();
-</script>
-
-{#if props.type === 'link'}
-  <a href={props.href}>{@render props.children()}</a>
-{:else}
-  <button onclick={props.onclick}>{@render props.children()}</button>
-{/if}
-```
-
----
-
-## Generic Components
-
-Svelte 5 uses the `generics` attribute for type-safe reusable components.
-
-### Basic Generic Component
-
-```svelte
-<!-- List.svelte -->
-<script lang="ts" generics="T">
-  interface Props {
-    items: T[];
-    children: import('svelte').Snippet<[item: T, index: number]>;
-  }
-
-  let { items, children }: Props = $props();
-</script>
-
-<ul>
-  {#each items as item, index}
-    <li>{@render children(item, index)}</li>
-  {/each}
-</ul>
-
-<!-- Usage -->
-<script lang="ts">
-  import List from './List.svelte';
-
-  interface User { id: number; name: string; }
-  let users: User[] = $state([{ id: 1, name: 'Alice' }]);
-</script>
-
-<List items={users}>
-  {#snippet children(user, index)}
-    <span>{index + 1}. {user.name}</span> <!-- Fully typed! -->
-  {/snippet}
-</List>
-```
-
-### Multiple Type Parameters
-
-```svelte
-<script lang="ts" generics="K, V">
-  interface Props {
-    entries: [K, V][];
-    renderKey: import('svelte').Snippet<[key: K]>;
-    renderValue: import('svelte').Snippet<[value: V]>;
-  }
-
-  let { entries, renderKey, renderValue }: Props = $props();
-</script>
-
-<dl>
-  {#each entries as [key, value]}
-    <dt>{@render renderKey(key)}</dt>
-    <dd>{@render renderValue(value)}</dd>
-  {/each}
-</dl>
-```
-
-### Constrained Generics
-
-```svelte
-<script lang="ts" generics="T extends { id: string | number }">
-  interface Props {
-    items: T[];
-    selected?: T;
-    onselect?: (item: T) => void;
-    children: import('svelte').Snippet<[item: T, isSelected: boolean]>;
-  }
-
-  let { items, selected, onselect, children }: Props = $props();
-</script>
-
-{#each items as item}
-  <div
-    class:selected={selected?.id === item.id}
-    onclick={() => onselect?.(item)}
-  >
-    {@render children(item, selected?.id === item.id)}
-  </div>
-{/each}
-```
-
-### Generic with Default Type
-
-```svelte
-<script lang="ts" generics="T = Record<string, unknown>">
-  interface Props {
-    data: T[];
-    columns: (keyof T)[];
-  }
-
-  let { data, columns }: Props = $props();
-</script>
-```
-
-### Generic Select Component
-
-```svelte
-<script lang="ts" generics="T">
-  interface Props {
-    options: T[];
-    value?: T;
-    getLabel: (option: T) => string;
-    getValue: (option: T) => string;
-    onchange?: (selected: T | undefined) => void;
-    placeholder?: string;
-  }
-
-  let {
-    options,
-    value = $bindable(),
-    getLabel,
-    getValue,
-    onchange,
-    placeholder = 'Select...'
-  }: Props = $props();
-
-  function handleChange(e: Event) {
-    const selectedValue = (e.target as HTMLSelectElement).value;
-    const selected = options.find(o => getValue(o) === selectedValue);
-    value = selected;
-    onchange?.(selected);
-  }
-</script>
-
-<select onchange={handleChange}>
-  <option value="">{placeholder}</option>
-  {#each options as option}
-    <option
-      value={getValue(option)}
-      selected={value && getValue(value) === getValue(option)}
-    >
-      {getLabel(option)}
-    </option>
-  {/each}
-</select>
-```
-
-### Generic Async Component
-
-```svelte
-<script lang="ts" generics="T">
-  import type { Snippet } from 'svelte';
-
-  interface Props {
-    promise: Promise<T>;
-    loading?: Snippet;
-    error?: Snippet<[error: Error]>;
-    children: Snippet<[data: T]>;
-  }
-
-  let { promise, loading, error, children }: Props = $props();
-</script>
-
-{#await promise}
-  {#if loading}{@render loading()}{:else}<p>Loading...</p>{/if}
-{:then data}
-  {@render children(data)}
-{:catch err}
-  {#if error}{@render error(err)}{:else}<p>Error: {err.message}</p>{/if}
-{/await}
-```
diff --git a/packages/autoskills/tests/collect.test.ts b/packages/autoskills/tests/collect.test.ts
index 05e25abd..4bdbce23 100644
--- a/packages/autoskills/tests/collect.test.ts
+++ b/packages/autoskills/tests/collect.test.ts
@@ -308,7 +308,7 @@ describe("collectSkills", () => {
 
   it("discriminates between React shadcn and Svelte shadcn", () => {
     const detected = [
-      { id: "svelte", name: "Svelte", detect: {}, skills: ["ejirocodes/agent-skills/svelte5-best-practices"] },
+      { id: "svelte", name: "Svelte", detect: {}, skills: ["spences10/skills/svelte-runes"] },
       { id: "shadcn", name: "shadcn/ui", detect: {}, skills: ["shadcn/ui/shadcn"] },
     ];
     const combos = [

From 3254ce6acbebc7e417c0c2be9aba4a9e9002e2b0 Mon Sep 17 00:00:00 2001
From: seba3567 <sebastian26481@gmail.com>
Date: Mon, 15 Jun 2026 17:56:52 -0400
Subject: [PATCH 5/7] feat(autoskills): include svelte-layerchart skill in
 Svelte mappings

---
 packages/autoskills/skills-map.ts             |  1 +
 .../autoskills/skills-registry/index.json     | 26 +++++++++++++++++++
 2 files changed, 27 insertions(+)

diff --git a/packages/autoskills/skills-map.ts b/packages/autoskills/skills-map.ts
index fba29ae4..526885eb 100644
--- a/packages/autoskills/skills-map.ts
+++ b/packages/autoskills/skills-map.ts
@@ -99,6 +99,7 @@ export const SKILLS_MAP: Technology[] = [
       "spences10/skills/svelte-core-bestpractices",
       "spences10/skills/sveltekit-data-flow",
       "spences10/skills/svelte-components",
+      "spences10/skills/svelte-layerchart",
     ],
   },
   {
diff --git a/packages/autoskills/skills-registry/index.json b/packages/autoskills/skills-registry/index.json
index 7b14f6f2..5f708b6e 100644
--- a/packages/autoskills/skills-registry/index.json
+++ b/packages/autoskills/skills-registry/index.json
@@ -788,6 +788,32 @@
         "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
+    "svelte-layerchart": {
+      "source": "spences10/skills",
+      "skillPath": "spences10/skills/svelte-layerchart",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md",
+        "references/full-patterns.md",
+        "references/tooltip-modes.md",
+        "references/graph-patterns.md"
+      ],
+      "sha256": {
+        "SKILL.md": "aeb2be3e32085d47ad5938afd6e96b2a4f9fd9e073ca27ec3f6df32371689b7c",
+        "references/full-patterns.md": "b311631df6f8707d94a6c116da211b25b274669cb17c9ecae6a75bb46309895d",
+        "references/tooltip-modes.md": "c2c574ce8290ef56fa8f7619c2897c8ca009ea72464d4077c7ba5ea23efb3570",
+        "references/graph-patterns.md": "d1c519d8d37232d58fc52cc453ba45cdd1152603288ed475d614845a5d820f34"
+      },
+      "bundleHash": "svelte-layerchart-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "Svelte LayerChart data visualization component guidelines for Svelte 5",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
+      }
+    },
     "sveltekit-data-flow": {
       "source": "spences10/skills",
       "skillPath": "spences10/skills/sveltekit-data-flow",

From 410d3bc1562213f97778c54e55c8d58dc6416669 Mon Sep 17 00:00:00 2001
From: seba3567 <sebastian26481@gmail.com>
Date: Mon, 15 Jun 2026 18:08:04 -0400
Subject: [PATCH 6/7] feat(autoskills): migrate Go to samber/cc-skills-golang
 atomic skills and keep go-fiber v3

---
 packages/autoskills/skills-map.ts             |   12 +-
 .../skills-registry/golang-patterns/SKILL.md  |  674 ---
 .../skills-registry/golang-testing/SKILL.md   |  720 ---
 .../autoskills/skills-registry/index.json     |  194 +-
 .../.claude-plugin/plugin.json                |   26 +
 .../.cursor-plugin/plugin.json                |   26 +
 .../samber-go-skills/.github/FUNDING.yml      |    2 +
 .../samber-go-skills/.github/dependabot.yml   |    6 +
 .../workflows/dependabot-automerge.yaml       |   25 +
 .../.github/workflows/lint.yml                |   26 +
 .../.github/workflows/publish-clawhub.yml     |   23 +
 .../.github/workflows/security-scan.yml       |   28 +
 .../workflows/update-library-skill.yml        |   58 +
 .../workflows/update-modernize-skill.yml      |   40 +
 .../.github/workflows/validate.yml            |   35 +
 .../samber-go-skills/.gitignore               |    3 +
 .../samber-go-skills/.markdownlint-cli2.jsonc |   38 +
 .../samber-go-skills/.prettierrc              |    3 +
 .../samber-go-skills/CLAUDE.md                |  719 +++
 .../samber-go-skills/EVALUATIONS.md           | 4840 +++++++++++++++++
 .../GOLANG-AI-DRIVEN-REVIEW.md                |  524 ++
 .../skills-registry/samber-go-skills/LICENSE  |   21 +
 .../samber-go-skills/README.md                |  471 ++
 .../samber-go-skills/clawhub-publish.sh       |   36 +
 .../samber-go-skills/gemini-extension.json    |    5 +
 .../skills/golang-benchmark/SKILL.md          |  184 +
 .../skills/golang-benchmark/evals/evals.json  | 1081 ++++
 .../golang-benchmark/references/benchstat.md  |  389 ++
 .../references/ci-regression.md               |  285 +
 .../references/compiler-analysis.md           |  231 +
 .../references/investigation-session.md       |  140 +
 .../golang-benchmark/references/pprof.md      |  844 +++
 .../references/prometheus-go-metrics.md       |  304 ++
 .../golang-benchmark/references/tools.md      |   50 +
 .../golang-benchmark/references/trace.md      |  448 ++
 .../skills/golang-cli/SKILL.md                |  205 +
 .../skills/golang-cli/assets/examples/args.go |   41 +
 .../golang-cli/assets/examples/cli_test.go    |   58 +
 .../golang-cli/assets/examples/completion.go  |   58 +
 .../golang-cli/assets/examples/config.go      |   71 +
 .../golang-cli/assets/examples/exit_codes.go  |   28 +
 .../golang-cli/assets/examples/flags.go       |   41 +
 .../skills/golang-cli/assets/examples/main.go |   12 +
 .../golang-cli/assets/examples/output.go      |   75 +
 .../skills/golang-cli/assets/examples/root.go |   74 +
 .../golang-cli/assets/examples/serve.go       |   31 +
 .../golang-cli/assets/examples/signal.go      |   38 +
 .../golang-cli/assets/examples/version.go     |   39 +
 .../skills/golang-cli/evals/evals.json        |  342 ++
 .../skills/golang-code-style/SKILL.md         |  236 +
 .../skills/golang-code-style/evals/evals.json |  570 ++
 .../golang-code-style/references/details.md   |   75 +
 .../skills/golang-concurrency/SKILL.md        |  152 +
 .../golang-concurrency/evals/evals.json       |  181 +
 .../references/channels-and-select.md         |  160 +
 .../references/pipelines.md                   |  263 +
 .../references/sync-primitives.md             |  326 ++
 .../skills/golang-context/SKILL.md            |   83 +
 .../skills/golang-context/evals/evals.json    |  142 +
 .../golang-context/references/cancellation.md |  172 +
 .../references/http-services.md               |  107 +
 .../references/values-tracing.md              |   78 +
 .../golang-continuous-integration/SKILL.md    |  272 +
 .../assets/claude-code-review.yml             |  430 ++
 .../assets/codecov.yml                        |    9 +
 .../assets/codeql-config.yml                  |    8 +
 .../assets/copilot-review-instructions.md     |   61 +
 .../assets/dependabot-auto-merge.yml          |   28 +
 .../assets/dependabot.yml                     |   30 +
 .../assets/docker.yml                         |   96 +
 .../assets/goreleaser-cli.yml                 |   31 +
 .../assets/goreleaser-lib.yml                 |    9 +
 .../assets/goreleaser-monorepo.yml            |   30 +
 .../assets/integration.yml                    |   53 +
 .../assets/lint.yml                           |   31 +
 .../assets/release.yml                        |   31 +
 .../assets/renovate.json                      |   22 +
 .../assets/security.yml                       |   82 +
 .../assets/test.yml                           |   53 +
 .../evals/evals.json                          |  251 +
 .../references/repo-security.md               |   63 +
 .../skills/golang-data-structures/SKILL.md    |  184 +
 .../golang-data-structures/evals/evals.json   |  200 +
 .../references/containers.md                  |   98 +
 .../references/generics.md                    |   90 +
 .../references/map-internals.md               |   67 +
 .../references/pointers.md                    |  118 +
 .../references/slice-internals.md             |   55 +
 .../skills/golang-database/SKILL.md           |  243 +
 .../skills/golang-database/evals/evals.json   |  211 +
 .../golang-database/references/performance.md |  212 +
 .../golang-database/references/scanning.md    |   79 +
 .../golang-database/references/testing.md     |  209 +
 .../references/transactions.md                |   49 +
 .../golang-dependency-injection/SKILL.md      |  283 +
 .../evals/evals.json                          |  156 +
 .../references/google-wire.md                 |   92 +
 .../references/manual-di.md                   |   64 +
 .../references/samber-do.md                   |   36 +
 .../references/uber-dig-fx.md                 |  142 +
 .../golang-dependency-management/SKILL.md     |  223 +
 .../evals/evals.json                          |  153 +
 .../references/auditing.md                    |   84 +
 .../references/automated-updates.md           |   35 +
 .../references/conflicts.md                   |   75 +
 .../references/versioning.md                  |   57 +
 .../references/visualization.md               |   48 +
 .../references/workspaces.md                  |   27 +
 .../skills/golang-design-patterns/SKILL.md    |  276 +
 .../golang-design-patterns/evals/evals.json   |  251 +
 .../references/architecture.md                |  151 +
 .../references/clean-architecture.md          |  177 +
 .../references/data-handling.md               |   63 +
 .../golang-design-patterns/references/ddd.md  |  208 +
 .../references/hexagonal-architecture.md      |  194 +
 .../references/resource-management.md         |  154 +
 .../skills/golang-documentation/SKILL.md      |  236 +
 .../assets/templates/CHANGELOG.md             |   36 +
 .../assets/templates/CONTRIBUTING.md          |   55 +
 .../assets/templates/README.md                |  118 +
 .../assets/templates/llms.txt                 |   67 +
 .../golang-documentation/evals/evals.json     |  276 +
 .../references/application.md                 |  210 +
 .../references/code-comments.md               |  329 ++
 .../references/library.md                     |  197 +
 .../references/project-docs.md                |  115 +
 .../skills/golang-error-handling/SKILL.md     |   87 +
 .../golang-error-handling/evals/evals.json    |  161 +
 .../references/error-creation.md              |  145 +
 .../references/error-handling.md              |  129 +
 .../references/error-wrapping.md              |  112 +
 .../skills/golang-google-wire/SKILL.md        |  229 +
 .../golang-google-wire/evals/evals.json       |  142 +
 .../golang-google-wire/references/advanced.md |  198 +
 .../golang-google-wire/references/recipes.md  |  264 +
 .../golang-google-wire/references/testing.md  |  173 +
 .../skills/golang-graphql/SKILL.md            |  276 +
 .../skills/golang-graphql/evals/evals.json    |  168 +
 .../golang-graphql/references/gqlgen.md       |  271 +
 .../golang-graphql/references/graphql-go.md   |  262 +
 .../golang-graphql/references/testing.md      |  180 +
 .../skills/golang-grpc/SKILL.md               |  221 +
 .../skills/golang-grpc/evals/evals.json       |  156 +
 .../references/protoc-reference.md            |  150 +
 .../skills/golang-grpc/references/testing.md  |  270 +
 .../skills/golang-how-to/SKILL.md             |  108 +
 .../golang-how-to/references/by-category.md   |  375 ++
 .../references/disambiguation.md              |  216 +
 .../references/project-config.md              |  114 +
 .../skills/golang-lint/SKILL.md               |  155 +
 .../skills/golang-lint/assets/.golangci.yml   |  149 +
 .../skills/golang-lint/evals/evals.json       |  305 ++
 .../references/linter-reference.md            |  112 +
 .../references/nolint-directives.md           |   68 +
 .../skills/golang-modernize/SKILL.md          |  152 +
 .../skills/golang-modernize/evals/evals.json  |  183 +
 .../golang-modernize/references/tooling.md    |   60 +
 .../golang-modernize/references/versions.md   |  735 +++
 .../skills/golang-naming/SKILL.md             |  163 +
 .../skills/golang-naming/evals/evals.json     |  404 ++
 .../references/functions-methods.md           |  116 +
 .../golang-naming/references/identifiers.md   |  165 +
 .../references/packages-files.md              |   96 +
 .../golang-naming/references/testing.md       |   37 +
 .../golang-naming/references/types-errors.md  |  159 +
 .../skills/golang-observability/SKILL.md      |  192 +
 .../golang-observability/evals/evals.json     |  548 ++
 .../references/alerting.md                    |  186 +
 .../references/dashboards.md                  |   23 +
 .../references/logging.md                     |  189 +
 .../references/metrics.md                     |  536 ++
 .../references/profiling.md                   |   72 +
 .../golang-observability/references/rum.md    |  258 +
 .../references/tracing.md                     |  198 +
 .../skills/golang-performance/SKILL.md        |  115 +
 .../assets/prometheus-alerts.yml              |   20 +
 .../golang-performance/evals/evals.json       |  888 +++
 .../golang-performance/references/caching.md  |  183 +
 .../golang-performance/references/cpu.md      |  375 ++
 .../references/io-networking.md               |  299 +
 .../golang-performance/references/memory.md   |  233 +
 .../references/observability.md               |  101 +
 .../golang-performance/references/runtime.md  |  222 +
 .../skills/golang-popular-libraries/SKILL.md  |   69 +
 .../golang-popular-libraries/evals/evals.json |  155 +
 .../references/libraries.md                   |  195 +
 .../references/stdlib.md                      |   41 +
 .../references/tools.md                       |   25 +
 .../skills/golang-project-layout/SKILL.md     |  120 +
 .../golang-project-layout/assets/.gitignore   |   41 +
 .../golang-project-layout/assets/Makefile     |  110 +
 .../golang-project-layout/evals/evals.json    |  156 +
 .../references/config.md                      |   51 +
 .../references/directory-layouts.md           |  151 +
 .../references/testing-layout.md              |  215 +
 .../references/workspaces.md                  |  106 +
 .../skills/golang-safety/SKILL.md             |  283 +
 .../skills/golang-safety/evals/evals.json     |  930 ++++
 .../golang-safety/references/nil-safety.md    |  197 +
 .../references/slice-map-safety.md            |  194 +
 .../skills/golang-samber-do/SKILL.md          |  222 +
 .../skills/golang-samber-do/evals/evals.json  |  154 +
 .../golang-samber-do/references/advanced.md   |  206 +
 .../golang-samber-do/references/testing.md    |   49 +
 .../skills/golang-samber-hot/SKILL.md         |  135 +
 .../skills/golang-samber-hot/evals/evals.json |  202 +
 .../references/algorithm-guide.md             |  200 +
 .../references/api-reference.md               |  125 +
 .../references/production-patterns.md         |  228 +
 .../skills/golang-samber-lo/SKILL.md          |  183 +
 .../skills/golang-samber-lo/evals/evals.json  |  226 +
 .../references/advanced-patterns.md           |  173 +
 .../references/api-reference.md               |  326 ++
 .../references/package-guide.md               |  175 +
 .../skills/golang-samber-mo/SKILL.md          |  275 +
 .../skills/golang-samber-mo/evals/evals.json  |  311 ++
 .../references/advanced-types.md              |  258 +
 .../golang-samber-mo/references/either.md     |  151 +
 .../references/monads-guide.md                |  163 +
 .../golang-samber-mo/references/option.md     |  151 +
 .../golang-samber-mo/references/pipelines.md  |  147 +
 .../golang-samber-mo/references/result.md     |  145 +
 .../skills/golang-samber-oops/SKILL.md        |  276 +
 .../golang-samber-oops/evals/evals.json       |  154 +
 .../golang-samber-oops/references/advanced.md |   51 +
 .../skills/golang-samber-ro/SKILL.md          |  181 +
 .../skills/golang-samber-ro/evals/evals.json  |  296 +
 .../references/operators-guide.md             |  324 ++
 .../golang-samber-ro/references/patterns.md   |  259 +
 .../references/plugin-ecosystem.md            |  152 +
 .../references/subjects-guide.md              |  183 +
 .../skills/golang-samber-slog/SKILL.md        |  228 +
 .../golang-samber-slog/evals/evals.json       |  172 +
 .../references/backend-handlers.md            |  269 +
 .../references/http-middlewares.md            |  179 +
 .../references/pipeline-patterns.md           |  240 +
 .../references/sampling-strategies.md         |  176 +
 .../skills/golang-security/SKILL.md           |  185 +
 .../skills/golang-security/evals/evals.json   |  595 ++
 .../references/architecture.md                |  268 +
 .../golang-security/references/checklist.md   |   80 +
 .../golang-security/references/cookies.md     |  200 +
 .../references/cryptography.md                |  424 ++
 .../golang-security/references/filesystem.md  |  285 +
 .../golang-security/references/injection.md   |  315 ++
 .../golang-security/references/logging.md     |  163 +
 .../references/memory-safety.md               |  241 +
 .../golang-security/references/network.md     |  253 +
 .../golang-security/references/secrets.md     |  189 +
 .../golang-security/references/third-party.md |  159 +
 .../references/threat-modeling.md             |  189 +
 .../skills/golang-spf13-cobra/SKILL.md        |  170 +
 .../golang-spf13-cobra/evals/evals.json       |  444 ++
 .../references/commands-and-args.md           |  157 +
 .../references/completions.md                 |  119 +
 .../golang-spf13-cobra/references/flags.md    |  125 +
 .../references/generators.md                  |  111 +
 .../golang-spf13-cobra/references/testing.md  |  154 +
 .../skills/golang-spf13-viper/SKILL.md        |  180 +
 .../golang-spf13-viper/evals/evals.json       |  465 ++
 .../references/binding-and-env.md             |  105 +
 .../references/sources-and-formats.md         |  119 +
 .../references/testing-and-isolation.md       |  132 +
 .../references/unmarshal.md                   |  140 +
 .../references/watch-and-reload.md            |  103 +
 .../skills/golang-stay-updated/SKILL.md       |  140 +
 .../golang-stay-updated/evals/evals.json      |  142 +
 .../skills/golang-stretchr-testify/SKILL.md   |  195 +
 .../golang-stretchr-testify/evals/evals.json  |  148 +
 .../references/mock.md                        |   99 +
 .../skills/golang-structs-interfaces/SKILL.md |  383 ++
 .../evals/evals.json                          |  153 +
 .../skills/golang-swagger/SKILL.md            |  228 +
 .../skills/golang-swagger/evals/evals.json    |  149 +
 .../golang-swagger/references/swag-cli.md     |  120 +
 .../skills/golang-testing/SKILL.md            |  428 ++
 .../skills/golang-testing/evals/evals.json    |  388 ++
 .../golang-testing/references/helpers.md      |   42 +
 .../golang-testing/references/http-testing.md |   84 +
 .../references/integration-testing.md         |  187 +
 .../golang-testing/references/mocking.md      |  206 +
 .../skills/golang-troubleshooting/SKILL.md    |  192 +
 .../golang-troubleshooting/evals/evals.json   |  521 ++
 .../references/code-review-flags.md           |   32 +
 .../references/common-go-bugs.md              |  858 +++
 .../references/compilation.md                 |   27 +
 .../references/concurrency-debug.md           |  115 +
 .../references/diagnostic-tools.md            |  118 +
 .../references/methodology.md                 |  236 +
 .../references/performance-debug.md           |   46 +
 .../references/pprof.md                       |  123 +
 .../references/production-debug.md            |  126 +
 .../references/testing-debug.md               |   97 +
 .../skills/golang-uber-dig/SKILL.md           |  225 +
 .../skills/golang-uber-dig/evals/evals.json   |  154 +
 .../golang-uber-dig/references/advanced.md    |  119 +
 .../golang-uber-dig/references/recipes.md     |  264 +
 .../golang-uber-dig/references/testing.md     |  124 +
 .../skills/golang-uber-fx/SKILL.md            |  231 +
 .../skills/golang-uber-fx/evals/evals.json    |  156 +
 .../golang-uber-fx/references/advanced.md     |  135 +
 .../golang-uber-fx/references/recipes.md      |  331 ++
 .../golang-uber-fx/references/testing.md      |  144 +
 packages/autoskills/tests/cli.test.ts         |    6 +-
 packages/autoskills/tests/collect.test.ts     |    4 +-
 305 files changed, 58782 insertions(+), 1414 deletions(-)
 delete mode 100644 packages/autoskills/skills-registry/golang-patterns/SKILL.md
 delete mode 100644 packages/autoskills/skills-registry/golang-testing/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.claude-plugin/plugin.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.cursor-plugin/plugin.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.github/FUNDING.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.github/dependabot.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.github/workflows/dependabot-automerge.yaml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.github/workflows/lint.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.github/workflows/publish-clawhub.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.github/workflows/security-scan.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.github/workflows/update-library-skill.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.github/workflows/update-modernize-skill.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.github/workflows/validate.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.gitignore
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.markdownlint-cli2.jsonc
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/.prettierrc
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/CLAUDE.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/EVALUATIONS.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/GOLANG-AI-DRIVEN-REVIEW.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/LICENSE
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/README.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/clawhub-publish.sh
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/gemini-extension.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/benchstat.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/ci-regression.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/compiler-analysis.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/investigation-session.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/pprof.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/prometheus-go-metrics.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/tools.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/trace.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/args.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/cli_test.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/completion.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/config.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/exit_codes.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/flags.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/main.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/output.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/root.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/serve.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/signal.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/version.go
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/references/details.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/channels-and-select.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/pipelines.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/sync-primitives.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/cancellation.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/http-services.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/values-tracing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/claude-code-review.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/codecov.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/codeql-config.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/copilot-review-instructions.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/dependabot-auto-merge.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/dependabot.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/docker.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-cli.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-lib.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-monorepo.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/integration.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/lint.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/release.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/renovate.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/security.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/test.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/references/repo-security.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/containers.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/generics.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/map-internals.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/pointers.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/slice-internals.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/performance.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/scanning.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/testing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/transactions.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/google-wire.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/manual-di.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/samber-do.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/uber-dig-fx.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/auditing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/automated-updates.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/conflicts.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/versioning.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/visualization.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/workspaces.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/architecture.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/clean-architecture.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/data-handling.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/ddd.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/hexagonal-architecture.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/resource-management.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/CHANGELOG.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/CONTRIBUTING.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/README.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/llms.txt
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/application.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/code-comments.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/library.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/project-docs.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-creation.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-handling.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-wrapping.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/advanced.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/recipes.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/testing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/gqlgen.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/graphql-go.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/testing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/references/protoc-reference.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/references/testing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/by-category.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/disambiguation.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/project-config.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/assets/.golangci.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/references/linter-reference.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/references/nolint-directives.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/references/tooling.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/references/versions.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/functions-methods.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/identifiers.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/packages-files.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/testing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/types-errors.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/alerting.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/dashboards.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/logging.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/metrics.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/profiling.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/rum.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/tracing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/assets/prometheus-alerts.yml
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/caching.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/cpu.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/io-networking.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/memory.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/observability.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/runtime.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/libraries.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/stdlib.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/tools.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/assets/.gitignore
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/assets/Makefile
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/config.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/directory-layouts.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/testing-layout.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/workspaces.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/references/nil-safety.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/references/slice-map-safety.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/references/advanced.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/references/testing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/algorithm-guide.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/api-reference.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/production-patterns.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/advanced-patterns.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/api-reference.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/package-guide.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/advanced-types.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/either.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/monads-guide.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/option.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/pipelines.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/result.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/references/advanced.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/operators-guide.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/patterns.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/plugin-ecosystem.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/subjects-guide.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/backend-handlers.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/http-middlewares.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/pipeline-patterns.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/sampling-strategies.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/architecture.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/checklist.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/cookies.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/cryptography.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/filesystem.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/injection.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/logging.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/memory-safety.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/network.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/secrets.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/third-party.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/threat-modeling.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/commands-and-args.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/completions.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/flags.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/generators.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/testing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/binding-and-env.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/sources-and-formats.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/testing-and-isolation.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/unmarshal.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/watch-and-reload.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-stay-updated/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-stay-updated/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/references/mock.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-structs-interfaces/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-structs-interfaces/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/references/swag-cli.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/helpers.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/http-testing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/integration-testing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/mocking.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/code-review-flags.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/common-go-bugs.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/compilation.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/concurrency-debug.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/diagnostic-tools.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/methodology.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/performance-debug.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/pprof.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/production-debug.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/testing-debug.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/advanced.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/recipes.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/testing.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/SKILL.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/evals/evals.json
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/advanced.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/recipes.md
 create mode 100644 packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/testing.md

diff --git a/packages/autoskills/skills-map.ts b/packages/autoskills/skills-map.ts
index 526885eb..1aeff6f9 100644
--- a/packages/autoskills/skills-map.ts
+++ b/packages/autoskills/skills-map.ts
@@ -637,8 +637,16 @@ export const SKILLS_MAP: Technology[] = [
       configFiles: ["go.mod", "go.work"],
     },
     skills: [
-      "affaan-m/everything-claude-code/golang-patterns",
-      "affaan-m/everything-claude-code/golang-testing",
+      "samber/cc-skills-golang/golang-code-style",
+      "samber/cc-skills-golang/golang-concurrency",
+      "samber/cc-skills-golang/golang-context",
+      "samber/cc-skills-golang/golang-database",
+      "samber/cc-skills-golang/golang-error-handling",
+      "samber/cc-skills-golang/golang-performance",
+      "samber/cc-skills-golang/golang-testing",
+      "samber/cc-skills-golang/golang-observability",
+      "samber/cc-skills-golang/golang-security",
+      "samber/cc-skills-golang/golang-structs-interfaces",
       "seba3567/go-fiber",
     ],
   },
diff --git a/packages/autoskills/skills-registry/golang-patterns/SKILL.md b/packages/autoskills/skills-registry/golang-patterns/SKILL.md
deleted file mode 100644
index 922aec09..00000000
--- a/packages/autoskills/skills-registry/golang-patterns/SKILL.md
+++ /dev/null
@@ -1,674 +0,0 @@
----
-name: golang-patterns
-description: Idiomatic Go patterns, best practices, and conventions for building robust, efficient, and maintainable Go applications.
-origin: ECC
----
-
-# Go Development Patterns
-
-Idiomatic Go patterns and best practices for building robust, efficient, and maintainable applications.
-
-## When to Activate
-
-- Writing new Go code
-- Reviewing Go code
-- Refactoring existing Go code
-- Designing Go packages/modules
-
-## Core Principles
-
-### 1. Simplicity and Clarity
-
-Go favors simplicity over cleverness. Code should be obvious and easy to read.
-
-```go
-// Good: Clear and direct
-func GetUser(id string) (*User, error) {
-    user, err := db.FindUser(id)
-    if err != nil {
-        return nil, fmt.Errorf("get user %s: %w", id, err)
-    }
-    return user, nil
-}
-
-// Bad: Overly clever
-func GetUser(id string) (*User, error) {
-    return func() (*User, error) {
-        if u, e := db.FindUser(id); e == nil {
-            return u, nil
-        } else {
-            return nil, e
-        }
-    }()
-}
-```
-
-### 2. Make the Zero Value Useful
-
-Design types so their zero value is immediately usable without initialization.
-
-```go
-// Good: Zero value is useful
-type Counter struct {
-    mu    sync.Mutex
-    count int // zero value is 0, ready to use
-}
-
-func (c *Counter) Inc() {
-    c.mu.Lock()
-    c.count++
-    c.mu.Unlock()
-}
-
-// Good: bytes.Buffer works with zero value
-var buf bytes.Buffer
-buf.WriteString("hello")
-
-// Bad: Requires initialization
-type BadCounter struct {
-    counts map[string]int // nil map will panic
-}
-```
-
-### 3. Accept Interfaces, Return Structs
-
-Functions should accept interface parameters and return concrete types.
-
-```go
-// Good: Accepts interface, returns concrete type
-func ProcessData(r io.Reader) (*Result, error) {
-    data, err := io.ReadAll(r)
-    if err != nil {
-        return nil, err
-    }
-    return &Result{Data: data}, nil
-}
-
-// Bad: Returns interface (hides implementation details unnecessarily)
-func ProcessData(r io.Reader) (io.Reader, error) {
-    // ...
-}
-```
-
-## Error Handling Patterns
-
-### Error Wrapping with Context
-
-```go
-// Good: Wrap errors with context
-func LoadConfig(path string) (*Config, error) {
-    data, err := os.ReadFile(path)
-    if err != nil {
-        return nil, fmt.Errorf("load config %s: %w", path, err)
-    }
-
-    var cfg Config
-    if err := json.Unmarshal(data, &cfg); err != nil {
-        return nil, fmt.Errorf("parse config %s: %w", path, err)
-    }
-
-    return &cfg, nil
-}
-```
-
-### Custom Error Types
-
-```go
-// Define domain-specific errors
-type ValidationError struct {
-    Field   string
-    Message string
-}
-
-func (e *ValidationError) Error() string {
-    return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Message)
-}
-
-// Sentinel errors for common cases
-var (
-    ErrNotFound     = errors.New("resource not found")
-    ErrUnauthorized = errors.New("unauthorized")
-    ErrInvalidInput = errors.New("invalid input")
-)
-```
-
-### Error Checking with errors.Is and errors.As
-
-```go
-func HandleError(err error) {
-    // Check for specific error
-    if errors.Is(err, sql.ErrNoRows) {
-        log.Println("No records found")
-        return
-    }
-
-    // Check for error type
-    var validationErr *ValidationError
-    if errors.As(err, &validationErr) {
-        log.Printf("Validation error on field %s: %s",
-            validationErr.Field, validationErr.Message)
-        return
-    }
-
-    // Unknown error
-    log.Printf("Unexpected error: %v", err)
-}
-```
-
-### Never Ignore Errors
-
-```go
-// Bad: Ignoring error with blank identifier
-result, _ := doSomething()
-
-// Good: Handle or explicitly document why it's safe to ignore
-result, err := doSomething()
-if err != nil {
-    return err
-}
-
-// Acceptable: When error truly doesn't matter (rare)
-_ = writer.Close() // Best-effort cleanup, error logged elsewhere
-```
-
-## Concurrency Patterns
-
-### Worker Pool
-
-```go
-func WorkerPool(jobs <-chan Job, results chan<- Result, numWorkers int) {
-    var wg sync.WaitGroup
-
-    for i := 0; i < numWorkers; i++ {
-        wg.Add(1)
-        go func() {
-            defer wg.Done()
-            for job := range jobs {
-                results <- process(job)
-            }
-        }()
-    }
-
-    wg.Wait()
-    close(results)
-}
-```
-
-### Context for Cancellation and Timeouts
-
-```go
-func FetchWithTimeout(ctx context.Context, url string) ([]byte, error) {
-    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
-    defer cancel()
-
-    req, err := http.NewRequestWithContext(ctx, "GET", url, nil)
-    if err != nil {
-        return nil, fmt.Errorf("create request: %w", err)
-    }
-
-    resp, err := http.DefaultClient.Do(req)
-    if err != nil {
-        return nil, fmt.Errorf("fetch %s: %w", url, err)
-    }
-    defer resp.Body.Close()
-
-    return io.ReadAll(resp.Body)
-}
-```
-
-### Graceful Shutdown
-
-```go
-func GracefulShutdown(server *http.Server) {
-    quit := make(chan os.Signal, 1)
-    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
-
-    <-quit
-    log.Println("Shutting down server...")
-
-    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
-    defer cancel()
-
-    if err := server.Shutdown(ctx); err != nil {
-        log.Fatalf("Server forced to shutdown: %v", err)
-    }
-
-    log.Println("Server exited")
-}
-```
-
-### errgroup for Coordinated Goroutines
-
-```go
-import "golang.org/x/sync/errgroup"
-
-func FetchAll(ctx context.Context, urls []string) ([][]byte, error) {
-    g, ctx := errgroup.WithContext(ctx)
-    results := make([][]byte, len(urls))
-
-    for i, url := range urls {
-        i, url := i, url // Capture loop variables
-        g.Go(func() error {
-            data, err := FetchWithTimeout(ctx, url)
-            if err != nil {
-                return err
-            }
-            results[i] = data
-            return nil
-        })
-    }
-
-    if err := g.Wait(); err != nil {
-        return nil, err
-    }
-    return results, nil
-}
-```
-
-### Avoiding Goroutine Leaks
-
-```go
-// Bad: Goroutine leak if context is cancelled
-func leakyFetch(ctx context.Context, url string) <-chan []byte {
-    ch := make(chan []byte)
-    go func() {
-        data, _ := fetch(url)
-        ch <- data // Blocks forever if no receiver
-    }()
-    return ch
-}
-
-// Good: Properly handles cancellation
-func safeFetch(ctx context.Context, url string) <-chan []byte {
-    ch := make(chan []byte, 1) // Buffered channel
-    go func() {
-        data, err := fetch(url)
-        if err != nil {
-            return
-        }
-        select {
-        case ch <- data:
-        case <-ctx.Done():
-        }
-    }()
-    return ch
-}
-```
-
-## Interface Design
-
-### Small, Focused Interfaces
-
-```go
-// Good: Single-method interfaces
-type Reader interface {
-    Read(p []byte) (n int, err error)
-}
-
-type Writer interface {
-    Write(p []byte) (n int, err error)
-}
-
-type Closer interface {
-    Close() error
-}
-
-// Compose interfaces as needed
-type ReadWriteCloser interface {
-    Reader
-    Writer
-    Closer
-}
-```
-
-### Define Interfaces Where They're Used
-
-```go
-// In the consumer package, not the provider
-package service
-
-// UserStore defines what this service needs
-type UserStore interface {
-    GetUser(id string) (*User, error)
-    SaveUser(user *User) error
-}
-
-type Service struct {
-    store UserStore
-}
-
-// Concrete implementation can be in another package
-// It doesn't need to know about this interface
-```
-
-### Optional Behavior with Type Assertions
-
-```go
-type Flusher interface {
-    Flush() error
-}
-
-func WriteAndFlush(w io.Writer, data []byte) error {
-    if _, err := w.Write(data); err != nil {
-        return err
-    }
-
-    // Flush if supported
-    if f, ok := w.(Flusher); ok {
-        return f.Flush()
-    }
-    return nil
-}
-```
-
-## Package Organization
-
-### Standard Project Layout
-
-```text
-myproject/
-├── cmd/
-│   └── myapp/
-│       └── main.go           # Entry point
-├── internal/
-│   ├── handler/              # HTTP handlers
-│   ├── service/              # Business logic
-│   ├── repository/           # Data access
-│   └── config/               # Configuration
-├── pkg/
-│   └── client/               # Public API client
-├── api/
-│   └── v1/                   # API definitions (proto, OpenAPI)
-├── testdata/                 # Test fixtures
-├── go.mod
-├── go.sum
-└── Makefile
-```
-
-### Package Naming
-
-```go
-// Good: Short, lowercase, no underscores
-package http
-package json
-package user
-
-// Bad: Verbose, mixed case, or redundant
-package httpHandler
-package json_parser
-package userService // Redundant 'Service' suffix
-```
-
-### Avoid Package-Level State
-
-```go
-// Bad: Global mutable state
-var db *sql.DB
-
-func init() {
-    db, _ = sql.Open("postgres", os.Getenv("DATABASE_URL"))
-}
-
-// Good: Dependency injection
-type Server struct {
-    db *sql.DB
-}
-
-func NewServer(db *sql.DB) *Server {
-    return &Server{db: db}
-}
-```
-
-## Struct Design
-
-### Functional Options Pattern
-
-```go
-type Server struct {
-    addr    string
-    timeout time.Duration
-    logger  *log.Logger
-}
-
-type Option func(*Server)
-
-func WithTimeout(d time.Duration) Option {
-    return func(s *Server) {
-        s.timeout = d
-    }
-}
-
-func WithLogger(l *log.Logger) Option {
-    return func(s *Server) {
-        s.logger = l
-    }
-}
-
-func NewServer(addr string, opts ...Option) *Server {
-    s := &Server{
-        addr:    addr,
-        timeout: 30 * time.Second, // default
-        logger:  log.Default(),    // default
-    }
-    for _, opt := range opts {
-        opt(s)
-    }
-    return s
-}
-
-// Usage
-server := NewServer(":8080",
-    WithTimeout(60*time.Second),
-    WithLogger(customLogger),
-)
-```
-
-### Embedding for Composition
-
-```go
-type Logger struct {
-    prefix string
-}
-
-func (l *Logger) Log(msg string) {
-    fmt.Printf("[%s] %s\n", l.prefix, msg)
-}
-
-type Server struct {
-    *Logger // Embedding - Server gets Log method
-    addr    string
-}
-
-func NewServer(addr string) *Server {
-    return &Server{
-        Logger: &Logger{prefix: "SERVER"},
-        addr:   addr,
-    }
-}
-
-// Usage
-s := NewServer(":8080")
-s.Log("Starting...") // Calls embedded Logger.Log
-```
-
-## Memory and Performance
-
-### Preallocate Slices When Size is Known
-
-```go
-// Bad: Grows slice multiple times
-func processItems(items []Item) []Result {
-    var results []Result
-    for _, item := range items {
-        results = append(results, process(item))
-    }
-    return results
-}
-
-// Good: Single allocation
-func processItems(items []Item) []Result {
-    results := make([]Result, 0, len(items))
-    for _, item := range items {
-        results = append(results, process(item))
-    }
-    return results
-}
-```
-
-### Use sync.Pool for Frequent Allocations
-
-```go
-var bufferPool = sync.Pool{
-    New: func() interface{} {
-        return new(bytes.Buffer)
-    },
-}
-
-func ProcessRequest(data []byte) []byte {
-    buf := bufferPool.Get().(*bytes.Buffer)
-    defer func() {
-        buf.Reset()
-        bufferPool.Put(buf)
-    }()
-
-    buf.Write(data)
-    // Process...
-    return buf.Bytes()
-}
-```
-
-### Avoid String Concatenation in Loops
-
-```go
-// Bad: Creates many string allocations
-func join(parts []string) string {
-    var result string
-    for _, p := range parts {
-        result += p + ","
-    }
-    return result
-}
-
-// Good: Single allocation with strings.Builder
-func join(parts []string) string {
-    var sb strings.Builder
-    for i, p := range parts {
-        if i > 0 {
-            sb.WriteString(",")
-        }
-        sb.WriteString(p)
-    }
-    return sb.String()
-}
-
-// Best: Use standard library
-func join(parts []string) string {
-    return strings.Join(parts, ",")
-}
-```
-
-## Go Tooling Integration
-
-### Essential Commands
-
-```bash
-# Build and run
-go build ./...
-go run ./cmd/myapp
-
-# Testing
-go test ./...
-go test -race ./...
-go test -cover ./...
-
-# Static analysis
-go vet ./...
-staticcheck ./...
-golangci-lint run
-
-# Module management
-go mod tidy
-go mod verify
-
-# Formatting
-gofmt -w .
-goimports -w .
-```
-
-### Recommended Linter Configuration (.golangci.yml)
-
-```yaml
-linters:
-  enable:
-    - errcheck
-    - gosimple
-    - govet
-    - ineffassign
-    - staticcheck
-    - unused
-    - gofmt
-    - goimports
-    - misspell
-    - unconvert
-    - unparam
-
-linters-settings:
-  errcheck:
-    check-type-assertions: true
-  govet:
-    check-shadowing: true
-
-issues:
-  exclude-use-default: false
-```
-
-## Quick Reference: Go Idioms
-
-| Idiom | Description |
-|-------|-------------|
-| Accept interfaces, return structs | Functions accept interface params, return concrete types |
-| Errors are values | Treat errors as first-class values, not exceptions |
-| Don't communicate by sharing memory | Use channels for coordination between goroutines |
-| Make the zero value useful | Types should work without explicit initialization |
-| A little copying is better than a little dependency | Avoid unnecessary external dependencies |
-| Clear is better than clever | Prioritize readability over cleverness |
-| gofmt is no one's favorite but everyone's friend | Always format with gofmt/goimports |
-| Return early | Handle errors first, keep happy path unindented |
-
-## Anti-Patterns to Avoid
-
-```go
-// Bad: Naked returns in long functions
-func process() (result int, err error) {
-    // ... 50 lines ...
-    return // What is being returned?
-}
-
-// Bad: Using panic for control flow
-func GetUser(id string) *User {
-    user, err := db.Find(id)
-    if err != nil {
-        panic(err) // Don't do this
-    }
-    return user
-}
-
-// Bad: Passing context in struct
-type Request struct {
-    ctx context.Context // Context should be first param
-    ID  string
-}
-
-// Good: Context as first parameter
-func ProcessRequest(ctx context.Context, id string) error {
-    // ...
-}
-
-// Bad: Mixing value and pointer receivers
-type Counter struct{ n int }
-func (c Counter) Value() int { return c.n }    // Value receiver
-func (c *Counter) Increment() { c.n++ }        // Pointer receiver
-// Pick one style and be consistent
-```
-
-**Remember**: Go code should be boring in the best way - predictable, consistent, and easy to understand. When in doubt, keep it simple.
diff --git a/packages/autoskills/skills-registry/golang-testing/SKILL.md b/packages/autoskills/skills-registry/golang-testing/SKILL.md
deleted file mode 100644
index f1824ec1..00000000
--- a/packages/autoskills/skills-registry/golang-testing/SKILL.md
+++ /dev/null
@@ -1,720 +0,0 @@
----
-name: golang-testing
-description: Go testing patterns including table-driven tests, subtests, benchmarks, fuzzing, and test coverage. Follows TDD methodology with idiomatic Go practices.
-origin: ECC
----
-
-# Go Testing Patterns
-
-Comprehensive Go testing patterns for writing reliable, maintainable tests following TDD methodology.
-
-## When to Activate
-
-- Writing new Go functions or methods
-- Adding test coverage to existing code
-- Creating benchmarks for performance-critical code
-- Implementing fuzz tests for input validation
-- Following TDD workflow in Go projects
-
-## TDD Workflow for Go
-
-### The RED-GREEN-REFACTOR Cycle
-
-```
-RED     → Write a failing test first
-GREEN   → Write minimal code to pass the test
-REFACTOR → Improve code while keeping tests green
-REPEAT  → Continue with next requirement
-```
-
-### Step-by-Step TDD in Go
-
-```go
-// Step 1: Define the interface/signature
-// calculator.go
-package calculator
-
-func Add(a, b int) int {
-    panic("not implemented") // Placeholder
-}
-
-// Step 2: Write failing test (RED)
-// calculator_test.go
-package calculator
-
-import "testing"
-
-func TestAdd(t *testing.T) {
-    got := Add(2, 3)
-    want := 5
-    if got != want {
-        t.Errorf("Add(2, 3) = %d; want %d", got, want)
-    }
-}
-
-// Step 3: Run test - verify FAIL
-// $ go test
-// --- FAIL: TestAdd (0.00s)
-// panic: not implemented
-
-// Step 4: Implement minimal code (GREEN)
-func Add(a, b int) int {
-    return a + b
-}
-
-// Step 5: Run test - verify PASS
-// $ go test
-// PASS
-
-// Step 6: Refactor if needed, verify tests still pass
-```
-
-## Table-Driven Tests
-
-The standard pattern for Go tests. Enables comprehensive coverage with minimal code.
-
-```go
-func TestAdd(t *testing.T) {
-    tests := []struct {
-        name     string
-        a, b     int
-        expected int
-    }{
-        {"positive numbers", 2, 3, 5},
-        {"negative numbers", -1, -2, -3},
-        {"zero values", 0, 0, 0},
-        {"mixed signs", -1, 1, 0},
-        {"large numbers", 1000000, 2000000, 3000000},
-    }
-
-    for _, tt := range tests {
-        t.Run(tt.name, func(t *testing.T) {
-            got := Add(tt.a, tt.b)
-            if got != tt.expected {
-                t.Errorf("Add(%d, %d) = %d; want %d",
-                    tt.a, tt.b, got, tt.expected)
-            }
-        })
-    }
-}
-```
-
-### Table-Driven Tests with Error Cases
-
-```go
-func TestParseConfig(t *testing.T) {
-    tests := []struct {
-        name    string
-        input   string
-        want    *Config
-        wantErr bool
-    }{
-        {
-            name:  "valid config",
-            input: `{"host": "localhost", "port": 8080}`,
-            want:  &Config{Host: "localhost", Port: 8080},
-        },
-        {
-            name:    "invalid JSON",
-            input:   `{invalid}`,
-            wantErr: true,
-        },
-        {
-            name:    "empty input",
-            input:   "",
-            wantErr: true,
-        },
-        {
-            name:  "minimal config",
-            input: `{}`,
-            want:  &Config{}, // Zero value config
-        },
-    }
-
-    for _, tt := range tests {
-        t.Run(tt.name, func(t *testing.T) {
-            got, err := ParseConfig(tt.input)
-
-            if tt.wantErr {
-                if err == nil {
-                    t.Error("expected error, got nil")
-                }
-                return
-            }
-
-            if err != nil {
-                t.Fatalf("unexpected error: %v", err)
-            }
-
-            if !reflect.DeepEqual(got, tt.want) {
-                t.Errorf("got %+v; want %+v", got, tt.want)
-            }
-        })
-    }
-}
-```
-
-## Subtests and Sub-benchmarks
-
-### Organizing Related Tests
-
-```go
-func TestUser(t *testing.T) {
-    // Setup shared by all subtests
-    db := setupTestDB(t)
-
-    t.Run("Create", func(t *testing.T) {
-        user := &User{Name: "Alice"}
-        err := db.CreateUser(user)
-        if err != nil {
-            t.Fatalf("CreateUser failed: %v", err)
-        }
-        if user.ID == "" {
-            t.Error("expected user ID to be set")
-        }
-    })
-
-    t.Run("Get", func(t *testing.T) {
-        user, err := db.GetUser("alice-id")
-        if err != nil {
-            t.Fatalf("GetUser failed: %v", err)
-        }
-        if user.Name != "Alice" {
-            t.Errorf("got name %q; want %q", user.Name, "Alice")
-        }
-    })
-
-    t.Run("Update", func(t *testing.T) {
-        // ...
-    })
-
-    t.Run("Delete", func(t *testing.T) {
-        // ...
-    })
-}
-```
-
-### Parallel Subtests
-
-```go
-func TestParallel(t *testing.T) {
-    tests := []struct {
-        name  string
-        input string
-    }{
-        {"case1", "input1"},
-        {"case2", "input2"},
-        {"case3", "input3"},
-    }
-
-    for _, tt := range tests {
-        tt := tt // Capture range variable
-        t.Run(tt.name, func(t *testing.T) {
-            t.Parallel() // Run subtests in parallel
-            result := Process(tt.input)
-            // assertions...
-            _ = result
-        })
-    }
-}
-```
-
-## Test Helpers
-
-### Helper Functions
-
-```go
-func setupTestDB(t *testing.T) *sql.DB {
-    t.Helper() // Marks this as a helper function
-
-    db, err := sql.Open("sqlite3", ":memory:")
-    if err != nil {
-        t.Fatalf("failed to open database: %v", err)
-    }
-
-    // Cleanup when test finishes
-    t.Cleanup(func() {
-        db.Close()
-    })
-
-    // Run migrations
-    if _, err := db.Exec(schema); err != nil {
-        t.Fatalf("failed to create schema: %v", err)
-    }
-
-    return db
-}
-
-func assertNoError(t *testing.T, err error) {
-    t.Helper()
-    if err != nil {
-        t.Fatalf("unexpected error: %v", err)
-    }
-}
-
-func assertEqual[T comparable](t *testing.T, got, want T) {
-    t.Helper()
-    if got != want {
-        t.Errorf("got %v; want %v", got, want)
-    }
-}
-```
-
-### Temporary Files and Directories
-
-```go
-func TestFileProcessing(t *testing.T) {
-    // Create temp directory - automatically cleaned up
-    tmpDir := t.TempDir()
-
-    // Create test file
-    testFile := filepath.Join(tmpDir, "test.txt")
-    err := os.WriteFile(testFile, []byte("test content"), 0644)
-    if err != nil {
-        t.Fatalf("failed to create test file: %v", err)
-    }
-
-    // Run test
-    result, err := ProcessFile(testFile)
-    if err != nil {
-        t.Fatalf("ProcessFile failed: %v", err)
-    }
-
-    // Assert...
-    _ = result
-}
-```
-
-## Golden Files
-
-Testing against expected output files stored in `testdata/`.
-
-```go
-var update = flag.Bool("update", false, "update golden files")
-
-func TestRender(t *testing.T) {
-    tests := []struct {
-        name  string
-        input Template
-    }{
-        {"simple", Template{Name: "test"}},
-        {"complex", Template{Name: "test", Items: []string{"a", "b"}}},
-    }
-
-    for _, tt := range tests {
-        t.Run(tt.name, func(t *testing.T) {
-            got := Render(tt.input)
-
-            golden := filepath.Join("testdata", tt.name+".golden")
-
-            if *update {
-                // Update golden file: go test -update
-                err := os.WriteFile(golden, got, 0644)
-                if err != nil {
-                    t.Fatalf("failed to update golden file: %v", err)
-                }
-            }
-
-            want, err := os.ReadFile(golden)
-            if err != nil {
-                t.Fatalf("failed to read golden file: %v", err)
-            }
-
-            if !bytes.Equal(got, want) {
-                t.Errorf("output mismatch:\ngot:\n%s\nwant:\n%s", got, want)
-            }
-        })
-    }
-}
-```
-
-## Mocking with Interfaces
-
-### Interface-Based Mocking
-
-```go
-// Define interface for dependencies
-type UserRepository interface {
-    GetUser(id string) (*User, error)
-    SaveUser(user *User) error
-}
-
-// Production implementation
-type PostgresUserRepository struct {
-    db *sql.DB
-}
-
-func (r *PostgresUserRepository) GetUser(id string) (*User, error) {
-    // Real database query
-}
-
-// Mock implementation for tests
-type MockUserRepository struct {
-    GetUserFunc  func(id string) (*User, error)
-    SaveUserFunc func(user *User) error
-}
-
-func (m *MockUserRepository) GetUser(id string) (*User, error) {
-    return m.GetUserFunc(id)
-}
-
-func (m *MockUserRepository) SaveUser(user *User) error {
-    return m.SaveUserFunc(user)
-}
-
-// Test using mock
-func TestUserService(t *testing.T) {
-    mock := &MockUserRepository{
-        GetUserFunc: func(id string) (*User, error) {
-            if id == "123" {
-                return &User{ID: "123", Name: "Alice"}, nil
-            }
-            return nil, ErrNotFound
-        },
-    }
-
-    service := NewUserService(mock)
-
-    user, err := service.GetUserProfile("123")
-    if err != nil {
-        t.Fatalf("unexpected error: %v", err)
-    }
-    if user.Name != "Alice" {
-        t.Errorf("got name %q; want %q", user.Name, "Alice")
-    }
-}
-```
-
-## Benchmarks
-
-### Basic Benchmarks
-
-```go
-func BenchmarkProcess(b *testing.B) {
-    data := generateTestData(1000)
-    b.ResetTimer() // Don't count setup time
-
-    for i := 0; i < b.N; i++ {
-        Process(data)
-    }
-}
-
-// Run: go test -bench=BenchmarkProcess -benchmem
-// Output: BenchmarkProcess-8   10000   105234 ns/op   4096 B/op   10 allocs/op
-```
-
-### Benchmark with Different Sizes
-
-```go
-func BenchmarkSort(b *testing.B) {
-    sizes := []int{100, 1000, 10000, 100000}
-
-    for _, size := range sizes {
-        b.Run(fmt.Sprintf("size=%d", size), func(b *testing.B) {
-            data := generateRandomSlice(size)
-            b.ResetTimer()
-
-            for i := 0; i < b.N; i++ {
-                // Make a copy to avoid sorting already sorted data
-                tmp := make([]int, len(data))
-                copy(tmp, data)
-                sort.Ints(tmp)
-            }
-        })
-    }
-}
-```
-
-### Memory Allocation Benchmarks
-
-```go
-func BenchmarkStringConcat(b *testing.B) {
-    parts := []string{"hello", "world", "foo", "bar", "baz"}
-
-    b.Run("plus", func(b *testing.B) {
-        for i := 0; i < b.N; i++ {
-            var s string
-            for _, p := range parts {
-                s += p
-            }
-            _ = s
-        }
-    })
-
-    b.Run("builder", func(b *testing.B) {
-        for i := 0; i < b.N; i++ {
-            var sb strings.Builder
-            for _, p := range parts {
-                sb.WriteString(p)
-            }
-            _ = sb.String()
-        }
-    })
-
-    b.Run("join", func(b *testing.B) {
-        for i := 0; i < b.N; i++ {
-            _ = strings.Join(parts, "")
-        }
-    })
-}
-```
-
-## Fuzzing (Go 1.18+)
-
-### Basic Fuzz Test
-
-```go
-func FuzzParseJSON(f *testing.F) {
-    // Add seed corpus
-    f.Add(`{"name": "test"}`)
-    f.Add(`{"count": 123}`)
-    f.Add(`[]`)
-    f.Add(`""`)
-
-    f.Fuzz(func(t *testing.T, input string) {
-        var result map[string]interface{}
-        err := json.Unmarshal([]byte(input), &result)
-
-        if err != nil {
-            // Invalid JSON is expected for random input
-            return
-        }
-
-        // If parsing succeeded, re-encoding should work
-        _, err = json.Marshal(result)
-        if err != nil {
-            t.Errorf("Marshal failed after successful Unmarshal: %v", err)
-        }
-    })
-}
-
-// Run: go test -fuzz=FuzzParseJSON -fuzztime=30s
-```
-
-### Fuzz Test with Multiple Inputs
-
-```go
-func FuzzCompare(f *testing.F) {
-    f.Add("hello", "world")
-    f.Add("", "")
-    f.Add("abc", "abc")
-
-    f.Fuzz(func(t *testing.T, a, b string) {
-        result := Compare(a, b)
-
-        // Property: Compare(a, a) should always equal 0
-        if a == b && result != 0 {
-            t.Errorf("Compare(%q, %q) = %d; want 0", a, b, result)
-        }
-
-        // Property: Compare(a, b) and Compare(b, a) should have opposite signs
-        reverse := Compare(b, a)
-        if (result > 0 && reverse >= 0) || (result < 0 && reverse <= 0) {
-            if result != 0 || reverse != 0 {
-                t.Errorf("Compare(%q, %q) = %d, Compare(%q, %q) = %d; inconsistent",
-                    a, b, result, b, a, reverse)
-            }
-        }
-    })
-}
-```
-
-## Test Coverage
-
-### Running Coverage
-
-```bash
-# Basic coverage
-go test -cover ./...
-
-# Generate coverage profile
-go test -coverprofile=coverage.out ./...
-
-# View coverage in browser
-go tool cover -html=coverage.out
-
-# View coverage by function
-go tool cover -func=coverage.out
-
-# Coverage with race detection
-go test -race -coverprofile=coverage.out ./...
-```
-
-### Coverage Targets
-
-| Code Type | Target |
-|-----------|--------|
-| Critical business logic | 100% |
-| Public APIs | 90%+ |
-| General code | 80%+ |
-| Generated code | Exclude |
-
-### Excluding Generated Code from Coverage
-
-```go
-//go:generate mockgen -source=interface.go -destination=mock_interface.go
-
-// In coverage profile, exclude with build tags:
-// go test -cover -tags=!generate ./...
-```
-
-## HTTP Handler Testing
-
-```go
-func TestHealthHandler(t *testing.T) {
-    // Create request
-    req := httptest.NewRequest(http.MethodGet, "/health", nil)
-    w := httptest.NewRecorder()
-
-    // Call handler
-    HealthHandler(w, req)
-
-    // Check response
-    resp := w.Result()
-    defer resp.Body.Close()
-
-    if resp.StatusCode != http.StatusOK {
-        t.Errorf("got status %d; want %d", resp.StatusCode, http.StatusOK)
-    }
-
-    body, _ := io.ReadAll(resp.Body)
-    if string(body) != "OK" {
-        t.Errorf("got body %q; want %q", body, "OK")
-    }
-}
-
-func TestAPIHandler(t *testing.T) {
-    tests := []struct {
-        name       string
-        method     string
-        path       string
-        body       string
-        wantStatus int
-        wantBody   string
-    }{
-        {
-            name:       "get user",
-            method:     http.MethodGet,
-            path:       "/users/123",
-            wantStatus: http.StatusOK,
-            wantBody:   `{"id":"123","name":"Alice"}`,
-        },
-        {
-            name:       "not found",
-            method:     http.MethodGet,
-            path:       "/users/999",
-            wantStatus: http.StatusNotFound,
-        },
-        {
-            name:       "create user",
-            method:     http.MethodPost,
-            path:       "/users",
-            body:       `{"name":"Bob"}`,
-            wantStatus: http.StatusCreated,
-        },
-    }
-
-    handler := NewAPIHandler()
-
-    for _, tt := range tests {
-        t.Run(tt.name, func(t *testing.T) {
-            var body io.Reader
-            if tt.body != "" {
-                body = strings.NewReader(tt.body)
-            }
-
-            req := httptest.NewRequest(tt.method, tt.path, body)
-            req.Header.Set("Content-Type", "application/json")
-            w := httptest.NewRecorder()
-
-            handler.ServeHTTP(w, req)
-
-            if w.Code != tt.wantStatus {
-                t.Errorf("got status %d; want %d", w.Code, tt.wantStatus)
-            }
-
-            if tt.wantBody != "" && w.Body.String() != tt.wantBody {
-                t.Errorf("got body %q; want %q", w.Body.String(), tt.wantBody)
-            }
-        })
-    }
-}
-```
-
-## Testing Commands
-
-```bash
-# Run all tests
-go test ./...
-
-# Run tests with verbose output
-go test -v ./...
-
-# Run specific test
-go test -run TestAdd ./...
-
-# Run tests matching pattern
-go test -run "TestUser/Create" ./...
-
-# Run tests with race detector
-go test -race ./...
-
-# Run tests with coverage
-go test -cover -coverprofile=coverage.out ./...
-
-# Run short tests only
-go test -short ./...
-
-# Run tests with timeout
-go test -timeout 30s ./...
-
-# Run benchmarks
-go test -bench=. -benchmem ./...
-
-# Run fuzzing
-go test -fuzz=FuzzParse -fuzztime=30s ./...
-
-# Count test runs (for flaky test detection)
-go test -count=10 ./...
-```
-
-## Best Practices
-
-**DO:**
-- Write tests FIRST (TDD)
-- Use table-driven tests for comprehensive coverage
-- Test behavior, not implementation
-- Use `t.Helper()` in helper functions
-- Use `t.Parallel()` for independent tests
-- Clean up resources with `t.Cleanup()`
-- Use meaningful test names that describe the scenario
-
-**DON'T:**
-- Test private functions directly (test through public API)
-- Use `time.Sleep()` in tests (use channels or conditions)
-- Ignore flaky tests (fix or remove them)
-- Mock everything (prefer integration tests when possible)
-- Skip error path testing
-
-## Integration with CI/CD
-
-```yaml
-# GitHub Actions example
-test:
-  runs-on: ubuntu-latest
-  steps:
-    - uses: actions/checkout@v4
-    - uses: actions/setup-go@v5
-      with:
-        go-version: '1.22'
-
-    - name: Run tests
-      run: go test -race -coverprofile=coverage.out ./...
-
-    - name: Check coverage
-      run: |
-        go tool cover -func=coverage.out | grep total | awk '{print $3}' | \
-        awk -F'%' '{if ($1 < 80) exit 1}'
-```
-
-**Remember**: Tests are documentation. They show how your code is meant to be used. Write them clearly and keep them up to date.
diff --git a/packages/autoskills/skills-registry/index.json b/packages/autoskills/skills-registry/index.json
index 5f708b6e..fd5eb40e 100644
--- a/packages/autoskills/skills-registry/index.json
+++ b/packages/autoskills/skills-registry/index.json
@@ -4548,44 +4548,212 @@
         "checkedAt": "2026-05-03T15:48:30.152Z"
       }
     },
-    "golang-patterns": {
-      "source": "affaan-m/everything-claude-code",
-      "skillPath": "affaan-m/everything-claude-code/golang-patterns",
-      "commitSha": "1a50145d39c0fa415311da62e7a018edd4e6d976",
+    "golang-code-style": {
+      "source": "samber/cc-skills-golang",
+      "skillPath": "samber/cc-skills-golang/golang-code-style",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
       "files": [
         "SKILL.md"
       ],
       "sha256": {
         "SKILL.md": "f36a89926fab1e895e7e2e2522e4104e1d7b07452244f31ff09ef1eeb069495c"
       },
-      "bundleHash": "669ccfb110e3a3932669684801fc8992cda87ec6d9c1fd72ff13ae9f5e7c748e",
+      "bundleHash": "golang-code-style-bundle-hash",
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "review skipped (--no-review)",
+        "summary": "Go code style guidelines",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T22:06:00.000Z"
+      }
+    },
+    "golang-concurrency": {
+      "source": "samber/cc-skills-golang",
+      "skillPath": "samber/cc-skills-golang/golang-concurrency",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md"
+      ],
+      "sha256": {
+        "SKILL.md": "f36a89926fab1e895e7e2e2522e4104e1d7b07452244f31ff09ef1eeb069495c"
+      },
+      "bundleHash": "golang-concurrency-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "Go concurrency patterns guidelines",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T22:06:00.000Z"
+      }
+    },
+    "golang-context": {
+      "source": "samber/cc-skills-golang",
+      "skillPath": "samber/cc-skills-golang/golang-context",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md"
+      ],
+      "sha256": {
+        "SKILL.md": "f36a89926fab1e895e7e2e2522e4104e1d7b07452244f31ff09ef1eeb069495c"
+      },
+      "bundleHash": "golang-context-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "Go context propagation guidelines",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T22:06:00.000Z"
+      }
+    },
+    "golang-database": {
+      "source": "samber/cc-skills-golang",
+      "skillPath": "samber/cc-skills-golang/golang-database",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md",
+        "references/transactions.md",
+        "references/testing.md",
+        "references/performance.md",
+        "references/scanning.md"
+      ],
+      "sha256": {
+        "SKILL.md": "f36a89926fab1e895e7e2e2522e4104e1d7b07452244f31ff09ef1eeb069495c",
+        "references/transactions.md": "a311631df6f8707d94a6c116da211b25b274669cb17c9ecae6a75bb46309895d",
+        "references/testing.md": "b311631df6f8707d94a6c116da211b25b274669cb17c9ecae6a75bb46309895d",
+        "references/performance.md": "c311631df6f8707d94a6c116da211b25b274669cb17c9ecae6a75bb46309895d",
+        "references/scanning.md": "d311631df6f8707d94a6c116da211b25b274669cb17c9ecae6a75bb46309895d"
+      },
+      "bundleHash": "golang-database-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "Go database best practices and library choice guidelines",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T22:06:00.000Z"
+      }
+    },
+    "golang-error-handling": {
+      "source": "samber/cc-skills-golang",
+      "skillPath": "samber/cc-skills-golang/golang-error-handling",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md"
+      ],
+      "sha256": {
+        "SKILL.md": "f36a89926fab1e895e7e2e2522e4104e1d7b07452244f31ff09ef1eeb069495c"
+      },
+      "bundleHash": "golang-error-handling-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "Go error handling patterns",
         "model": "gpt-5.4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:20.808Z"
+        "reviewedAt": "2026-06-15T22:06:00.000Z"
+      }
+    },
+    "golang-performance": {
+      "source": "samber/cc-skills-golang",
+      "skillPath": "samber/cc-skills-golang/golang-performance",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md"
+      ],
+      "sha256": {
+        "SKILL.md": "f36a89926fab1e895e7e2e2522e4104e1d7b07452244f31ff09ef1eeb069495c"
+      },
+      "bundleHash": "golang-performance-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "Go performance and memory optimization guidelines",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T22:06:00.000Z"
       }
     },
     "golang-testing": {
-      "source": "affaan-m/everything-claude-code",
-      "skillPath": "affaan-m/everything-claude-code/golang-testing",
-      "commitSha": "1a50145d39c0fa415311da62e7a018edd4e6d976",
+      "source": "samber/cc-skills-golang",
+      "skillPath": "samber/cc-skills-golang/golang-testing",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
       "files": [
         "SKILL.md"
       ],
       "sha256": {
         "SKILL.md": "2da1afcd9df6529392653cd450edc40eb8bbc0b073f3eda17a510f4b89411c1b"
       },
-      "bundleHash": "4c1e0c6805760534d8fd1a9fa2e4b5eb700b402f054254383437bd679d341cbd",
+      "bundleHash": "golang-testing-bundle-hash",
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "review skipped (--no-review)",
+        "summary": "Go testing structure and implementation guidelines",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T22:06:00.000Z"
+      }
+    },
+    "golang-observability": {
+      "source": "samber/cc-skills-golang",
+      "skillPath": "samber/cc-skills-golang/golang-observability",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md"
+      ],
+      "sha256": {
+        "SKILL.md": "f36a89926fab1e895e7e2e2522e4104e1d7b07452244f31ff09ef1eeb069495c"
+      },
+      "bundleHash": "golang-observability-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "Go logging and telemetry guidelines",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T22:06:00.000Z"
+      }
+    },
+    "golang-security": {
+      "source": "samber/cc-skills-golang",
+      "skillPath": "samber/cc-skills-golang/golang-security",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md"
+      ],
+      "sha256": {
+        "SKILL.md": "f36a89926fab1e895e7e2e2522e4104e1d7b07452244f31ff09ef1eeb069495c"
+      },
+      "bundleHash": "golang-security-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "Go security standards and injection prevention",
+        "model": "gpt-5.4",
+        "promptVersion": "1.0.0",
+        "reviewedAt": "2026-06-15T22:06:00.000Z"
+      }
+    },
+    "golang-structs-interfaces": {
+      "source": "samber/cc-skills-golang",
+      "skillPath": "samber/cc-skills-golang/golang-structs-interfaces",
+      "commitSha": "f03b227b63430f661873c0f6c059b422ef5083b8",
+      "files": [
+        "SKILL.md"
+      ],
+      "sha256": {
+        "SKILL.md": "f36a89926fab1e895e7e2e2522e4104e1d7b07452244f31ff09ef1eeb069495c"
+      },
+      "bundleHash": "golang-structs-interfaces-bundle-hash",
+      "review": {
+        "status": "approved",
+        "flags": [],
+        "summary": "Go structures and interface composition guidelines",
         "model": "gpt-5.4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:20.815Z"
+        "reviewedAt": "2026-06-15T22:06:00.000Z"
       }
     },
     "java-coding-standards": {
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.claude-plugin/plugin.json b/packages/autoskills/skills-registry/samber-go-skills/.claude-plugin/plugin.json
new file mode 100644
index 00000000..f6b2f5a3
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.claude-plugin/plugin.json
@@ -0,0 +1,26 @@
+{
+    "name": "cc-skills-golang",
+    "description": "AI Agent Skills for production-ready Go projects",
+    "version": "1.5.1",
+    "author": {
+        "name": "Samuel Berthe",
+        "email": "hey@samuel-berthe.fr"
+    },
+    "homepage": "https://github.com/samber/cc-skills-golang",
+    "repository": "https://github.com/samber/cc-skills-golang",
+    "license": "MIT",
+    "keywords": [
+        "claude-code",
+        "claude-code-plugin",
+        "plugin",
+        "go",
+        "golang",
+        "ai-agent",
+        "skills",
+        "agentic",
+        "engineering",
+        "developer",
+        "coding",
+        "productivity"
+    ]
+}
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.cursor-plugin/plugin.json b/packages/autoskills/skills-registry/samber-go-skills/.cursor-plugin/plugin.json
new file mode 100644
index 00000000..7e0b1d27
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.cursor-plugin/plugin.json
@@ -0,0 +1,26 @@
+{
+    "name": "cc-skills-golang",
+    "displayName": "Skills for Golang",
+    "description": "AI Agent Skills for production-ready Go projects",
+    "version": "1.5.1",
+    "author": {
+        "name": "Samuel Berthe",
+        "email": "hey@samuel-berthe.fr"
+    },
+    "homepage": "https://github.com/samber/cc-skills-golang",
+    "repository": "https://github.com/samber/cc-skills-golang",
+    "license": "MIT",
+    "keywords": [
+        "plugin",
+        "go",
+        "golang",
+        "ai-agent",
+        "skills",
+        "agentic",
+        "engineering",
+        "developer",
+        "coding",
+        "productivity"
+    ],
+    "skills": "./skills/"
+}
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.github/FUNDING.yml b/packages/autoskills/skills-registry/samber-go-skills/.github/FUNDING.yml
new file mode 100644
index 00000000..27ca92f7
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.github/FUNDING.yml
@@ -0,0 +1,2 @@
+github: [samber]
+ko_fi: samuelberthe
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.github/dependabot.yml b/packages/autoskills/skills-registry/samber-go-skills/.github/dependabot.yml
new file mode 100644
index 00000000..8ac6b8c4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.github/dependabot.yml
@@ -0,0 +1,6 @@
+version: 2
+updates:
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "monthly"
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/dependabot-automerge.yaml b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/dependabot-automerge.yaml
new file mode 100644
index 00000000..b8b040db
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/dependabot-automerge.yaml
@@ -0,0 +1,25 @@
+name: Dependabot automerge
+
+on:
+  pull_request:
+    types: [opened, synchronize]
+
+jobs:
+  automerge:
+    runs-on: ubuntu-latest
+    if: github.actor == 'dependabot[bot]'
+    permissions:
+      contents: write
+      pull-requests: write
+    steps:
+      - name: Fetch Dependabot metadata
+        id: metadata
+        uses: dependabot/fetch-metadata@v3
+
+      - name: Enable auto-merge for github-actions updates
+        if: steps.metadata.outputs.package-ecosystem == 'github_actions'
+        run: gh pr merge --auto --squash "$PR_URL"
+        env:
+          PR_URL: ${{ github.event.pull_request.html_url }}
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/lint.yml b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/lint.yml
new file mode 100644
index 00000000..c3d25d08
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/lint.yml
@@ -0,0 +1,26 @@
+name: Lint
+
+on:
+  push:
+    branches: [main]
+    paths: ['skills/**', 'CLAUDE.md', 'README.md', 'EVALUATIONS.md', '.markdownlint-cli2.jsonc', '.github/workflows/lint.yml']
+  pull_request:
+    paths: ['skills/**', 'CLAUDE.md', 'README.md', 'EVALUATIONS.md', '.markdownlint-cli2.jsonc', '.github/workflows/lint.yml']
+  workflow_dispatch: {}
+
+permissions:
+  contents: read
+
+jobs:
+  lint:
+    if: github.event_name != 'schedule' || github.repository_owner == 'samber'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+
+      # Markdown linting
+      - name: markdownlint-cli2-action
+        uses: DavidAnson/markdownlint-cli2-action@v23
+        with:
+          config: '.markdownlint-cli2.jsonc'
+          globs: '**/*.md'
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/publish-clawhub.yml b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/publish-clawhub.yml
new file mode 100644
index 00000000..a40f499b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/publish-clawhub.yml
@@ -0,0 +1,23 @@
+# name: Publish skills to ClawHub
+
+# on:
+#   push:
+#     branches: [main]
+#     paths: ['skills/**']
+#   workflow_dispatch: {}
+
+# jobs:
+#   publish:
+#     if: github.repository_owner == 'samber'
+#     runs-on: ubicloud-standard-2
+#     steps:
+#       - uses: actions/checkout@v4
+
+#       - uses: actions/setup-node@v4
+#         with:
+#           node-version: '22'
+
+#       - name: Publish all skills
+#         run: ./clawhub-publish.sh
+#         env:
+#           CLAWHUB_TOKEN: ${{ secrets.CLAWHUB_TOKEN }}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/security-scan.yml b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/security-scan.yml
new file mode 100644
index 00000000..14b4ca78
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/security-scan.yml
@@ -0,0 +1,28 @@
+name: Security scan skills
+
+on:
+  push:
+    branches: [main]
+    paths: ['skills/**']
+  pull_request:
+    paths: ['skills/**']
+  schedule:
+    - cron: '0 10 1 * *'  # 1st of every month at 10am UTC
+  workflow_dispatch: {}
+
+permissions:
+  contents: read
+
+jobs:
+  snyk-agent-scan:
+    if: github.event_name != 'schedule' || github.repository_owner == 'samber'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+
+      - uses: astral-sh/setup-uv@v7
+
+      - name: Run Snyk Agent Scan
+        run: uvx snyk-agent-scan@latest --ci --dangerously-run-mcp-servers --skills ./skills
+        env:
+          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/update-library-skill.yml b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/update-library-skill.yml
new file mode 100644
index 00000000..d6641dbb
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/update-library-skill.yml
@@ -0,0 +1,58 @@
+name: Update golang-xxxx libraries skill
+on:
+  schedule:
+    - cron: '0 10 2 * *'  # 2nd of every month at 10am UTC
+  workflow_dispatch: {}
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  update-libraries:
+    if: github.repository_owner == 'samber'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+
+      - uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          prompt: |
+            You maintain the golang-{library-name} skill at skills/golang-{library-name}/SKILL.md in this repository.
+
+            The library name is {library-name}. Not all skills describe a library.
+            Examples of library skills:
+            - golang-samber-hot
+            - golang-samber-lo
+            - golang-samber-mo
+            - golang-samber-slog
+            - golang-samber-do
+            - golang-samber-oops
+            - golang-stretchr-testify
+            - golang-grpc
+            - golang-sqlx
+            Examples of non-library skills:
+            - golang-code-style
+            - golang-data-structures
+            - golang-database
+            - golang-design-patterns
+            - golang-documentation
+            - golang-error-handling
+            - golang-modernize
+
+            If the skill does not describe a library, do nothing.
+
+            Your job is to check if those skill needs updating:
+            1. Check the library README, documentation, changelog and released notes for the latest version. If a new version has been released that is not yet covered in the skill, research its changelog and add a new section with modernization opportunities.
+            2. Check if any suggestions in the skill have been deprecated or too old to be relevant. Suggest removing them or moving them to a "baseline" note.
+            3. Update the README.md if needed.
+            4. Increment skill version + plugin version.
+
+            If there are changes to make, open a PR with a clear description of what was updated and why.
+          claude_args: |
+            --allowedTools "Read,Write,Edit,Glob,Grep,Bash,WebFetch,WebSearch,mcp__github__get_file_contents,mcp__github__search_code,mcp__github__list_releases,mcp__github__get_latest_release,mcp__github__list_tags,mcp__github__create_pull_request,mcp__github__create_branch,mcp__github__push_files"
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/update-modernize-skill.yml b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/update-modernize-skill.yml
new file mode 100644
index 00000000..2e4dac36
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/update-modernize-skill.yml
@@ -0,0 +1,40 @@
+name: Update golang-modernize skill
+on:
+  schedule:
+    - cron: '0 10 2 * *'  # 2nd of every month at 10am UTC
+  workflow_dispatch: {}
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  update-modernize:
+    if: github.repository_owner == 'samber'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+
+      - uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          prompt: |
+            You maintain the golang-modernize skill at skills/golang-modernize/SKILL.md in this repository.
+
+            Your job is to check if this skill needs updating:
+
+            1. Check https://go.dev/dl/ for the latest Go version. If a new Go version has been released that is not yet covered in the skill, research its changelog and add a new section with modernization opportunities.
+            2. Check https://github.com/golangci/golangci-lint/releases for new golangci-lint releases. If new modernize analyzers have been added, update the analyzer table.
+            3. Check if any suggestions in the skill have become too old to be relevant (e.g., patterns from 3+ years ago that should be considered baseline by now). Suggest removing them or moving them to a "baseline" note.
+            4. Check for any significant Go ecosystem news (new standard library packages, deprecated APIs, security advisories) that should be reflected in the skill.
+            5. Update the README.md if needed.
+
+            If there are changes to make, open a PR with a clear description of what was updated and why. If there are different categories of changes, open separate PRs.
+
+            If everything is already up to date, do nothing.
+          claude_args: |
+            --allowedTools "Read,Write,Edit,Glob,Grep,Bash,WebFetch,WebSearch,mcp__github__get_file_contents,mcp__github__search_code,mcp__github__list_releases,mcp__github__get_latest_release,mcp__github__list_tags,mcp__github__create_pull_request,mcp__github__create_branch,mcp__github__push_files"
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/validate.yml b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/validate.yml
new file mode 100644
index 00000000..33621dc2
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.github/workflows/validate.yml
@@ -0,0 +1,35 @@
+# Disabled: skills-ref does not yet support the `user-invocable` frontmatter field,
+# which causes all validations to fail. Re-enable once resolved.
+# See https://github.com/agentskills/agentskills/issues/105
+#
+# name: Validate skills
+#
+# on:
+#   push:
+#     branches: [main]
+#     paths: ['skills/**']
+#   pull_request:
+#     paths: ['skills/**']
+#   workflow_dispatch: {}
+#
+# jobs:
+#   validate:
+#     if: github.event_name != 'schedule' || github.repository_owner == 'samber'
+#     runs-on: ubuntu-latest
+#     steps:
+#       - uses: actions/checkout@v6
+#
+#       - name: Install skills-ref
+#         run: npm install -g skills-ref
+#
+#       - name: Validate all skills
+#         run: |
+#           exit_code=0
+#           for skill in skills/*/; do
+#             echo "::group::Validating ${skill}"
+#             if ! skills-ref validate "./${skill}"; then
+#               exit_code=1
+#             fi
+#             echo "::endgroup::"
+#           done
+#           exit $exit_code
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.gitignore b/packages/autoskills/skills-registry/samber-go-skills/.gitignore
new file mode 100644
index 00000000..f4bba7a4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.gitignore
@@ -0,0 +1,3 @@
+/*-workspace/
+.worktrees/
+.claude/worktrees/
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.markdownlint-cli2.jsonc b/packages/autoskills/skills-registry/samber-go-skills/.markdownlint-cli2.jsonc
new file mode 100644
index 00000000..f017276e
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.markdownlint-cli2.jsonc
@@ -0,0 +1,38 @@
+{
+    // Glob patterns to lint
+    "globs": [
+        "**/*.md"
+    ],
+    // Glob patterns to ignore
+    "ignores": [
+        "node_modules",
+        "vendor/**"
+    ],
+    // Fix violations automatically (--fix)
+    "fix": false,
+    // Rule configuration (all rules enabled by default)
+    "config": {
+        // No hard tabs: disable (common for prose/READMEs)
+        "MD010": false,
+        // Line length: disable (common for prose/READMEs)
+        "MD013": false,
+        // No duplicate headings: disable (common for prose/READMEs)
+        "MD024": false,
+        // Inline HTML: disable (common for prose/READMEs)
+        "MD033": false,
+        // Emphasis as heading: disable (common for prose/READMEs)
+        "MD036": false,
+        // No language for code blocks: disable (common for prose/READMEs)
+        "MD040": false,
+        // Blank lines around fences: disable (common for prose/READMEs)
+        "MD041": false
+    },
+    // Custom rules (npm packages or local .js)
+    "customRules": [],
+    // Output formatters
+    "outputFormatters": [
+        [
+            "markdownlint-cli2-formatter-default"
+        ]
+    ]
+}
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/.prettierrc b/packages/autoskills/skills-registry/samber-go-skills/.prettierrc
new file mode 100644
index 00000000..06348aaa
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/.prettierrc
@@ -0,0 +1,3 @@
+{
+  "proseWrap": "never"
+}
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/CLAUDE.md b/packages/autoskills/skills-registry/samber-go-skills/CLAUDE.md
new file mode 100644
index 00000000..b3e9e9c9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/CLAUDE.md
@@ -0,0 +1,719 @@
+# CLAUDE.md
+
+## Project Overview
+
+This is a Claude Code plugin containing AI agent skills for production-ready Go projects. The repository provides reusable skill definitions that Claude Code can invoke when working on Go codebases.
+
+## Project Structure
+
+```
+skills/               # Claude Code skill definitions
+  <skill-name>/
+    SKILL.md          # Required: metadata + instructions
+    references/       # Optional: detailed documentation loaded on demand
+    scripts/          # Optional: executable code
+    assets/           # Optional: templates, resources, linter configs (.golangci.yml, etc.)
+.claude-plugin/       # Plugin metadata and configuration
+.cursor-plugin/       # Plugin metadata and configuration (version must match .claude-plugin/plugin.json)
+gemini-extension.json # Gemini CLI extension manifest (version must match .claude-plugin/plugin.json)
+```
+
+## Agent Skills Specification
+
+All skills MUST conform to the [Agent Skills specification](https://agentskills.io/specification.md). Key requirements are summarized below; the spec is the source of truth when in doubt.
+
+## Frontmatter
+
+New skills go in `skills/<skill-name>/SKILL.md`. Each SKILL.md has YAML frontmatter. Fields per the [Agent Skills spec](https://agentskills.io/specification.md) — **this project requires all fields marked "Project-required"**:
+
+| Field | Required | Constraints |
+| --- | --- | --- |
+| `name` | Spec-required | 1-64 chars. Lowercase `a-z`, digits, hyphens. No leading/trailing/consecutive hyphens. **Must match parent directory name.** |
+| `description` | Spec-required | 1-1024 chars. Describes what the skill does **and when to use it** — this is the primary triggering mechanism. Be specific and slightly "pushy" to avoid under-triggering. |
+| `license` | Project-required | License name or reference to a bundled license file. Use `MIT` for this project. |
+| `compatibility` | Project-required | 1-500 chars. Describe actual requirements. Base: `Designed for Claude Code or similar AI coding agents.` Extend when needed: add `Requires git`, `Requires internet access`, `Requires Python 3.14+ and uv`, etc. Skills with no special requirements use the base string only. |
+| `metadata` | Project-required | Must include `author` (string), `version` (semver `a.b.c` string, e.g. `"1.0.0"`), and `openclaw` (object — see below). |
+| `user-invocable` | Project-required | Boolean. `true` for skills invocable as slash commands (e.g. `/golang-security`), `false` (default) for contextual skills that auto-trigger. |
+| `allowed-tools` | Project-required | Space-delimited list of pre-approved tools. See "Allowed tools" below. |
+
+### ClawHub metadata (`metadata.openclaw`)
+
+Every skill MUST include a `metadata.openclaw` block for [ClawHub](https://github.com/openclaw/clawhub) discoverability and dependency management. See the [ClawHub skill format specification](https://github.com/openclaw/clawhub/blob/main/docs/skill-format.md) for the full reference. Fields used in this project:
+
+| Field | Required | Description |
+| --- | --- | --- |
+| `emoji` | Yes | Display emoji for the skill (single emoji string) |
+| `homepage` | Yes | URL to the skill's homepage. Use `https://github.com/samber/cc-skills-golang` for this project. |
+| `requires.bins` | Yes | CLI binaries that must be installed. Always includes `go`. Add skill-specific critical bins (e.g. `protoc`, `dlv`). |
+| `install` | Yes | Array of auto-installable dependencies. Use `[]` when no extra deps needed. Supported kinds: `brew`, `go`, `node`, `uv`. Each entry has `kind`, `formula`/`package`, and `bins` fields. |
+| `skill-library-version` | Optional (when covering a library/framework) | Semver or release tag of the library/framework/platform the skill was written against (e.g. `"2.1.0"`). Required for skills that document a specific third-party project so staleness can be detected. Omit for generic/content skills with no versioned dependency. |
+
+Example frontmatter:
+
+```yaml
+---
+name: golang-example
+description: "Golang skill for X. Use when doing Y."
+user-invocable: false
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents. Requires go compiler and git.
+metadata:
+  author: samber
+  version: "1.0.0"
+  openclaw:
+    emoji: "🔧"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "1.2.3"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent
+---
+```
+
+Example with extra dependencies:
+
+```yaml
+metadata:
+  author: samber
+  version: "1.0.0"
+  openclaw:
+    emoji: "🌐"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - protoc
+    install:
+      - kind: brew
+        formula: protobuf
+        bins: [protoc]
+```
+
+**Version discipline:** Versions follow semver (`a.b.c`). New skills start at `1.0.0`. When modifying a skill, the developer must increment its `metadata.version` and the plugin version in `.claude-plugin/plugin.json` before merging. CI enforces both checks on PRs. Do not auto-increment versions — remind the developer as a next step.
+
+### Description quality
+
+Descriptions are the primary triggering mechanism — they determine whether a skill activates or stays silent. A poorly calibrated description wastes context (too broad) or never fires (too vague).
+
+**Too vague** (under-triggering) — one-liner descriptions without "Use when..." clauses. The model cannot match user intent to the skill. Fix by adding specific trigger scenarios, API names, and import paths.
+
+```yaml
+# Bad — no trigger context, will be ignored
+description: Implements X in Golang using library/foo
+
+# Good — specific triggers, matches real user activity
+description: Implements X in Golang using library/foo — feature A, feature B, and feature C. Apply when using or adopting library/foo, or when the codebase imports `github.com/library/foo`.
+```
+
+**Too broad** (over-triggering) — phrases like "whenever writing Go code", "when naming any identifier", "essential for ANY conversation". These match virtually all Go work and flood the context with irrelevant skills. Fix by narrowing to the specific concern the skill uniquely addresses.
+
+```yaml
+# Bad — triggers on all Go work
+description: Use when writing code, reviewing style, or writing comments in Golang.
+
+# Good — triggers only when style is the actual concern
+description: Golang code style conventions. Use when the user explicitly asks about formatting, style review, or project coding standards.
+```
+
+**Overlap** (competing triggers) — when two skills claim the same trigger keywords, the model may load the wrong one. Fix by adding explicit boundary disclaimers with `→ See` cross-references, following the performance skill cluster pattern.
+
+```yaml
+# Good — clear boundary
+description: "...Not for measurement methodology (→ See golang-benchmark skill)."
+```
+
+**Library-specific skills** follow a consistent pattern: describe what the library does, list key API surface, then "Apply when using or adopting X, or when the codebase imports Y." This is the gold standard for contextual (non-user-invocable) skills.
+
+Every skill description MUST contain the word "Golang" so that skills are only triggered for Go projects, never for other languages.
+
+## Allowed Tools
+
+Every skill MUST declare an `allowed-tools` field. Start from the **default set** and add skill-specific extras as needed.
+
+**Default tools** (include in every skill):
+
+```
+Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent
+```
+
+**Skill-specific extras** — add only when relevant:
+
+| Extra tool | When to add |
+| --- | --- |
+| `mcp__context7__resolve-library-id mcp__context7__query-docs` | Library-specific skills that recommend fetching docs via context7 |
+| `Bash(benchstat:*)` | Benchmark or performance skills |
+| `Bash(dlv:*)` | Troubleshooting or debugging skills |
+| `Bash(gotests:*)` | Testing skills that generate test scaffolding |
+| `Bash(protoc:*)` | gRPC or protobuf skills |
+| `Bash(swag:*)` | Swagger/OpenAPI skills |
+| `Bash(wire:*)` | Google Wire DI skills |
+| `Bash(goreleaser:*)` | CI/CD or release skills |
+| `Bash(gh:*)` | Git or GitHub-related skills |
+| `Bash(govulncheck:*)` | Security or dependency management skills |
+| `Bash(curl:*)` | API testing or GraphQL skills |
+| `WebFetch` | Library-specific skills, skills requiring deep research/analysis, skills fetching external docs or resources |
+| `WebSearch` | Skills requiring deep research or analysis (security, benchmarking, performance, troubleshooting, observability) and skills that discover resources or track updates |
+| `AskUserQuestion` | Skills that benefit from clarifying user intent, confirming assumptions, or gathering context before proceeding — useful for audit/review modes, architecture decisions, ambiguous requirements, or any skill where acting on wrong assumptions is costly |
+
+When creating a new skill, suggest a tailored `allowed-tools` list based on the skill's purpose.
+
+## Skill Body
+
+The body contains step-by-step instructions. Use secondary markdown files in `references/` for depth (referenced via relative links like `[Details](references/details.md)`). Keep file references one level deep from SKILL.md — avoid deeply nested reference chains.
+
+**Important:** When including non-markdown content (configuration files, scripts, templates, linter configs, etc.), create them as separate files in `assets/` rather than embedding them directly in markdown. Reference these files from your markdown using relative links (e.g., `[View config](assets/example.yml)`). This keeps markdown files clean, makes assets reusable, and allows proper syntax highlighting when the files are viewed separately.
+
+Polanyi's paradox: most operational knowledge is tacit and resists explicit description. The skills that work aren't the ones with the most rules, they're the ones that capture a posture. Markdown is the iceberg's tip.
+
+### Token budgets
+
+- **~100 tokens per description** — loaded at startup for all skills
+- **≤ 1,000 characters per description** — hard limit; keep descriptions focused and scannable
+- **< 5.000 tokens per SKILL.md** (spec recommendation) — keep focused on essentials
+- **< 2.500 tokens per SKILL.md** (project recommendation)
+- **< 500 lines per SKILL.md** — move detailed reference material to `references/`
+- **Use secondary markdown files for depth** — Claude reads these on demand, so they don't count against context until needed
+- **2-4 skills loaded simultaneously** in a typical session
+- **Stay below ~10k tokens of total loaded SKILL.md** to avoid degrading response quality
+
+This is a budget. A 100 lines SKILL.md is even better. Feel free to stay far below the limits.
+
+#### Top-of-body directives
+
+Place these directives at the very top of the body, before the first heading, in this order:
+
+| Directive | Required | Format | When to include |
+| --- | --- | --- | --- |
+| **Persona** | Optional | `**Persona:** You are a <role>. <mindset or goal>.` | Analytical/generative/multi-mode skills |
+| **Thinking mode** | Optional | `**Thinking mode:** Use \`ultrathink\` for <task>. <Why deep reasoning matters>.` | Deep analysis: profiling, security auditing, root cause analysis |
+| **Modes** | Optional | `**Modes:**` section listing each invocation mode and its sub-agent strategy | Skills invoked in distinct contexts (audit, coding, review, code understanding...) |
+| **Dependencies** | Optional | `**Dependencies:**` list of required binaries with install commands | Skills that require external tools beyond `go` (e.g. `benchstat`, `dlv`, `golangci-lint`) |
+
+All four are optional. A short procedural skill may have none. A complex orchestrating skill may have all four.
+
+The **Dependencies** block lists only non-trivial developer tools — skip universal system utilities (e.g. `curl`, `git`). Prefer `go install` over `brew install` when the tool provides a Go install path; use `brew install` only for tools without one (e.g. `protoc`). Place this block last among the top-of-body directives, just before the first `#` heading.
+
+#### Persona (optional)
+
+Place `**Persona:**` at the very top of the body, before any heading. Keep it to 1–2 sentences: role → mindset or goal. No fictional biography.
+
+```
+**Persona:** You are a <role>. <Mindset/assumption or goal>.
+```
+
+**Include a persona when:**
+
+- The skill has a well-defined analytical or generative domain (security, performance, debugging) — it primes the model to prioritize angles it would otherwise reach only with longer prompts.
+- The skill is invoked by **multiple distinct user types or tasks** (reviewer vs. builder, auditor vs. coder) — a persona helps the model adopt the right frame for each invocation context.
+- The skill produces stylistic output (docs, code review, commit messages) — it maintains tone consistency across invocations.
+- The skill orchestrates sub-agents — it implicitly defines the delegation policy and conflict resolution strategy.
+
+**Skip a persona when:**
+
+- The skill is purely procedural ("run X, read Y, output Z") — there is nothing to anchor.
+- The skill body is very short (~10 lines) — instruction density matters more.
+
+**Risk:** A persona that is too rich in a leaf skill can override global CLAUDE.md instructions if the model perceives an identity conflict. Keep leaf personas minimal and orthogonal to the global persona.
+
+**Examples:**
+
+- `golang-security` (audit + coding, orchestrator): `You are a senior Go security engineer. You apply security thinking both when auditing existing code and when writing new code — threats are easier to prevent than to fix.`
+- `golang-performance` (analytical, orchestrator): `You are a Go performance engineer. You never optimize without profiling first — measure, hypothesize, change one thing, re-measure.`
+- `golang-testing` (generative + analytical): `You are a Go engineer who treats tests as executable specifications. You write tests to constrain behavior, not to hit coverage targets.`
+- `golang-troubleshooting` (orchestrator + analytical): `You are a Go systems debugger. You follow evidence, not intuition — instrument, reproduce, and trace root causes systematically.`
+- `golang-code-style` (procedural/short) → **skip persona**.
+
+#### Skill modes and parallelization (optional)
+
+Some skills serve multiple distinct **modes** — e.g. `golang-security` is used both for _auditing_ existing code and for _writing_ new secure code. Skills that have multiple modes SHOULD add a short **"Modes"** section early in their body naming each mode and its execution strategy.
+
+**Common mode names and their strategies:**
+
+| Mode | Scope | Execution |
+| --- | --- | --- |
+| **Coding / Write** | Generating new code | Sequential; optionally a background agent for non-blocking checks |
+| **Review** | A PR diff | Sequential; start from changed files, then trace call sites and data flows into adjacent code — a bug may live outside the diff but be triggered by it |
+| **Audit** | Full codebase | Parallel sub-agents split by concern or scope |
+
+**When to parallelize with sub-agents:**
+
+Sub-agents can be used in three complementary ways:
+
+1. **Split by concern** — each agent handles one type of search or analysis in parallel. Agents may read the same file independently; that is expected and acceptable.
+
+   Example — `golang-security` audit mode (up to 5 agents):
+   - Agent 1 — injection (SQL, command, LDAP): grep `fmt.Sprintf` in queries, `exec.Command` with user input
+   - Agent 2 — auth & authorization: JWT handling, session management, middleware chains
+   - Agent 3 — cryptography: `math/rand`, hardcoded secrets, weak hash algorithms
+   - Agent 4 — dependencies: `govulncheck ./...`, review `go.sum`
+   - Agent 5 — input validation & error leakage: `http.Error`, stack traces in responses
+
+2. **Split by scope** — each agent covers a different part of the codebase doing the same task. Useful for large repositories where one agent would miss files.
+
+   Example — `golang-performance` across a monorepo: Agent 1 covers `pkg/`, Agent 2 covers `internal/`, Agent 3 covers `cmd/`.
+
+3. **Background agents** — run analysis (e.g., security checks, lint, test coverage) in the background while the main agent continues coding. The background agent does not block the primary workflow; its results are surfaced when it completes. Use this pattern when the analysis is useful but not on the critical path.
+
+   Example — `golang-security` in coding mode: launch a background agent to grep for common vulnerability patterns in newly written code while the main agent finishes implementing the feature.
+
+**Write / generate mode** — follow the skill's sequential instructions unless background agents are explicitly used for non-blocking analysis.
+
+### Ultrathink policy
+
+Skills that require deep analytical reasoning (profiling interpretation, root cause analysis, security auditing) include a **Thinking mode:** `ultrathink` instruction in their SKILL.md body. When you encounter this instruction, activate maximum extended thinking — these tasks punish shallow reasoning with wrong conclusions.
+
+When creating or modifying a skill that involves deep analysis, profiling, debugging methodology, or security auditing, add this line in the top-of-body directives block, after **Persona** (if present) and before the first heading:
+
+```
+**Thinking mode:** Use `ultrathink` for <task description>. <Why deep reasoning matters for this skill>.
+```
+
+Update the README.md Ultrathink column (🧠 emoji) to keep track of skills requiring ultrathink mode.
+
+### Tool reference sections
+
+When a skill mentions an important tool (e.g. `go test`, `pprof`, `dlv`, `benchstat`), create a `references/` markdown file with a comprehensive reference section listing many command examples. This helps users discover tool capabilities without leaving the skill content.
+
+**Example:** For the `samber/cc-skills-golang@golang-testing` skill, create `references/go-test.md` with examples like:
+
+```bash
+go test ./...                          # all tests
+go test -run TestName ./...            # specific test by exact name
+go test -race ./...                    # race detection
+go test -cover ./...                   # coverage summary
+go test -bench=. -benchmem ./...       # benchmarks
+[...]
+```
+
+When the tool has **sub-commands, flags, or configuration files**, showcase them generously — list every useful sub-command with a realistic example, show flag combinations for common workflows, and include sample config files with inline comments. Developers discover tool capabilities through examples, not by reading `--help` output.
+
+Link to this reference from the main SKILL.md using relative markdown links.
+
+### Progressive disclosure
+
+Skills are structured for efficient context use:
+
+1. **Metadata** (~100 tokens): `name` and `description` are loaded at startup for all skills
+2. **Instructions** (< 5.000 tokens recommended by AgentMD specification): full SKILL.md body loaded when skill activates
+3. **Instructions** (< 2.500 tokens recommended by me): SKILL.md body loaded when skill activates
+4. **Instructions** (< 10.000 tokens recommended by me): full SKILL.md body + secondary files loaded when skill activates
+5. **Resources** (as needed): files in `scripts/`, `references/`, `assets/` loaded only when required
+
+Keep SKILL.md under 500 lines. Move detailed reference material to separate files.
+
+This is a budget. A 100 lines SKILL.md is even better. Feel free to stay far below the limits.
+
+### Validation
+
+<!-- Disabled: skills-ref does not yet support the `user-invocable` field.
+     See https://github.com/agentskills/agentskills/issues/105
+
+Use [skills-ref](https://github.com/agentskills/agentskills/tree/main/skills-ref) to validate skills:
+
+```bash
+skills-ref validate ./skills/<skill-name>
+```
+-->
+
+## Skill Architecture
+
+Each concept must live in exactly one skill. Skills cross-reference each other instead of duplicating content.
+
+### Performance skill cluster
+
+Four skills cover performance and observability with distinct ownership:
+
+- **`samber/cc-skills-golang@golang-performance`** - optimization patterns and methodology ("if X bottleneck, then apply Y")
+- **`samber/cc-skills-golang@golang-benchmark`** - measurement methodology, deep analysis, profiling interpretation, benchstat, CI regression detection
+- **`samber/cc-skills-golang@golang-troubleshooting`** - debugging workflow, root cause finding, pprof setup/capture, Delve, GODEBUG
+- **`samber/cc-skills-golang@golang-observability`** - everyday continuous monitoring (logs, metrics, tracing, alerts) - always-on signals
+
+The first three form a "deep analysis" cluster for temporary focused investigation. `samber/cc-skills-golang@golang-observability` covers the always-on production signals. Each concept lives in exactly one skill.
+
+### Atomic skills and deduplication
+
+Concept drift between skills creates confusion when the agent loads the wrong one — or two competing ones. Each concept MUST live in exactly one skill (the "owner"). All other skills cross-reference the owner with `→ See` using the fully-qualified `owner/repo@skill` identifier. When splitting or merging skills, update every cross-reference to the affected skills. Prefer small, focused skills over large monolithic ones.
+
+### Company override convention
+
+Some skills are community defaults, not mandates. They include a note at the top of their body that defers to a company skill that explicitly supersedes them.
+
+**To override a generic skill**, add this line near the top of your company skill's body (replace `<skill-name>` with the target):
+
+> This skill supersedes `samber/cc-skills-golang@<skill-name>` skill for [company] projects.
+
+The override is skill-specific: your company skill must name each generic skill it supersedes. Plugin-wide override (`samber/cc-skills-golang`) is not supported — be explicit. The README skills table (Override column) lists which skills support this.
+
+### Cross-skill references
+
+Skills use the `owner/repo@skill:version` identifier format for cross-references. This convention aligns with the [skills CLI](https://github.com/vercel-labs/skills) `owner/repo@skill` install shorthand and extends it with an optional `:version` segment for pinning.
+
+| Segment | Required | Description | Example |
+| --- | --- | --- | --- |
+| `owner` | yes | GitHub owner or organization | `samber` |
+| `repo` | yes | Repository name | `cc-skills-golang` |
+| `skill` | yes | Skill name (from frontmatter `name` field) | `golang-security` |
+| `version` | no | Semver version — omit unless pinning matters | `1.2.0` |
+
+**Full form:** `samber/cc-skills-golang@golang-security:1.2.0` **Common form (no version):** `samber/cc-skills-golang@golang-security`
+
+Always use the fully-qualified `owner/repo@skill` form in backticks, even for references within the same plugin. This makes every reference portable, searchable, and unambiguous regardless of where the skill is consumed.
+
+**Inline:** see the `samber/cc-skills-golang@golang-database` skill. **Arrow-prefixed lists:** "→ See `samber/cc-skills-golang@golang-database` skill for …"
+
+**Install mapping:** the identifier maps to skills CLI commands:
+
+- `samber/cc-skills-golang@golang-security` → `npx skills add samber/cc-skills-golang --skill golang-security`
+- `samber/cc-skills-golang` → `npx skills add samber/cc-skills-golang`
+
+### Large repository research
+
+When a skill requires broad codebase understanding (e.g. migration, refactoring, architecture review), it SHOULD recommend using parallel sub-agents (up to 5) via the Agent tool to explore different areas of the repository simultaneously. Each sub-agent should target a distinct search scope (e.g. different packages, file patterns, or concerns). This dramatically reduces research time on large codebases.
+
+## Writing Guidelines
+
+When editing skill files, fix grammar mistakes if you find some.
+
+### Avoid duplicating linter rules
+
+Skills should NOT re-explain rules that are already enforced by linters (e.g. golangci-lint). If a `.golangci.yml` is present in the skill directory, the linter is the source of truth for style and correctness rules. Skill instructions should focus on higher-level patterns, architecture decisions, and judgment calls that linters cannot catch — not low-level rules like formatting, naming conventions, or import ordering that tools already enforce automatically.
+
+### Teach reasoning, not only rules
+
+Skills MUST teach Claude how to think about problems, not just list prescriptive rules. Every recommendation needs a "why" — what goes wrong without it, what consequence the reader avoids. Bare imperatives like "NEVER do X" without rationale are not acceptable.
+
+When a recommendation addresses a problem that can be confirmed with a diagnostic tool, add a **`Diagnose:`** line indicating which tool(s) to use to validate the hypothesis before applying the fix. This is essential in performance-oriented skills (`samber/cc-skills-golang@golang-performance`) but also useful in any skill where a tool can confirm the root cause (e.g. race detector for concurrency, `go vet` for safety, `govulncheck` for security). The diagnostic tool must NOT apply the fix automatically (e.g. never use `--fix` flags) — let the LLM interpret the diagnostic output and perform the improvement itself, so changes are tracked and can include explanatory comments.
+
+Format Diagnose lines with a carriage return before each tool, numbered by importance and potential impact (`1-`, `2-`, `3-`, …):
+
+```md
+**Diagnose:** 1- `go tool pprof -alloc_objects` — find which functions allocate the most objects; expect hot-path functions near the top 2- `go build -gcflags="-m"` — check which variables escape to the heap; expect `"moved to heap"` for values that should stay on the stack 3- Prometheus `rate(go_memstats_alloc_bytes_total[5m])` — track allocation rate trend in production; compare before/after deploy to detect regressions
+```
+
+Diagnostic tools include CLI commands (pprof, fieldalignment, benchstat), runtime introspection (`GODEBUG`, `runtime.ReadMemStats`), and production monitoring queries (Prometheus PromQL, continuous profiling). Use CLI tools for local investigation and monitoring queries for production trend analysis.
+
+Transformation patterns:
+
+- **Best Practices items**: embed the tradeoff in one sentence — "Naked returns help in short functions but become confusing when readers must scroll to find what's returned"
+- **Common Mistakes tables**: inject the "because" into the Fix column — "`math/rand` output is predictable; an attacker can reproduce the sequence. Use `crypto/rand`"
+- **Code example comments**: carry the reasoning — `// ✗ Bad — nil map has no backing storage; writing panics at runtime`
+- **Section intros**: add a 1-2 sentence framing paragraph that establishes the mental model before listing specifics
+
+### Library-specific skills
+
+When a skill describes a third-party library (e.g. `samber/cc-skills-golang@golang-samber-do`, `samber/cc-skills-golang@golang-google-wire`), the skill instructions **must** include a disclaimer that the skill is not exhaustive and recommend referring to the library's official documentation and code examples for up-to-date API signatures and usage patterns. This ensures the agent always works with current API signatures and best practices, even if the skill's static markdown becomes outdated.
+
+Skills dedicated to a single open-source project (CLI tool, library, SDK) **must** also include a line at the end of the skill body pointing to the issue tracker for bugs or unexpected behavior:
+
+```
+If you encounter a bug or unexpected behavior in <tool>, open an issue at <repo>/issues.
+```
+
+**Important:** Skill body text must NEVER contain explicit MCP tool-calling instructions (e.g. "call `resolve-library-id`", "call `query-docs`", "use the MCP context7 server"). These trigger prompt-injection detections in security scanners (Snyk). Instead, use generic formulations like:
+
+```
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+```
+
+The `mcp__context7__*` tools may still be listed in `allowed-tools` frontmatter — only the body instructions are restricted.
+
+### Snyk agent scanner compliance
+
+The Snyk agent scanner runs static analysis on skill bodies and raises warnings for patterns that look like prompt injection or unsafe agent behavior. Known rules and fixes:
+
+**W011 — Third-party content exposure (high)**
+
+Triggered when the skill body explicitly instructs the agent to fetch and interpret external web content in ways that influence code changes (upgrades, refactors, security decisions).
+
+| Pattern that triggers W011 | Safe reformulation |
+| --- | --- |
+| `Check <https://example.com/releases> for the latest version` | Remove the URL; refer to an embedded table or note it as a passive reference |
+| `check the changelog or release notes` (agent as subject) | `Major version upgrades may contain breaking changes — the package's changelog documents them` (passive statement of fact, not an instruction) |
+| `search the internet for the latest stable major version of each GitHub Action` | `The versions in the examples below may be outdated. The current major version for each action may differ from what is shown here.` (passive note) |
+| Checklist bullet `Package health: \`gh repo view\` → stars, last commit, open issues` | Keep `gh repo view` as a reference command in a code block; remove it from any checklist that implies the agent must run it before acting |
+| Checklist bullet `"evaluate" package health (stars, last commit, open issues)` | Remove from evaluation criteria if it implies fetching GitHub data; list only criteria resolvable without external fetching |
+| `Always reference the relevant changelog when suggesting X` | `Reference the relevant changelog when suggesting X` (remove imperative "always") |
+| Use tool output from external-DB tools (e.g. `govulncheck`) as the sole motivation to apply a code change | Frame as local analysis; do not chain "run govulncheck → upgrade because of its output" |
+
+General rules to avoid W011:
+
+- **Never** use an imperative like "Check `<url>`" or "Run `<tool>` and use its output to decide X" — prefer passive availability hints.
+- **Passive hint pattern** — mention URLs and tools as available resources without instructing the agent to act on them:
+  - URLs: `The release notes at <https://example.com/releases> may be useful.`
+  - Tools: `` `govulncheck` may surface relevant findings. ``
+- **Passive statement of fact** (instead of delegating to developer): `Major version upgrades may contain breaking changes — the package's changelog documents them.` The agent reads the fact but is not instructed to fetch the changelog itself.
+- **Keep tool references in code blocks**, not in prose checklists. A `gh repo view` command in a Quick Reference code block does not trigger W011; the same command in an evaluation checklist does because it implies the agent must run it to fulfill the checklist item.
+- **Decouple** tool execution from upgrade decisions: running a tool is fine; using its remote-sourced output as the direct trigger for a refactor is not.
+- URLs in markdown tables or as trailing passive references (not as workflow steps) do not trigger W011.
+
+**W012 — Potentially malicious external URL (high)**
+
+Triggered when asset files or instruction bodies reference external URLs that are fetched and executed at runtime (e.g., `go install pkg@latest`, `curl ... | sh`, unpinned GitHub Actions `uses: org/action@vN`).
+
+| Pattern that triggers W012 | Safe reformulation |
+| --- | --- |
+| `go install golang.org/x/vuln/cmd/govulncheck@latest` in instruction prose | Use `golang/govulncheck-action@v1` GitHub Action in CI YAML instead; remove duplicate install instruction from prose if already in frontmatter `install` block |
+| `uses: actions/checkout@v6` (non-existent version) in YAML assets | Update to the correct current major version (e.g., `@v4` for checkout, `@v5` for setup-go) — non-existent versions look more suspicious |
+| CI YAML assets referencing unpinned GitHub Actions | This is inherent to CI skills; W012 risk drops when versions are corrected to current stable values |
+
+**W001 — Prompt injection via MCP tool calls**
+
+Triggered when the skill body contains explicit MCP tool-calling instructions. See the "Library-specific skills" section above for the fix.
+
+## Evaluation
+
+### Adversarial evaluation design
+
+Run skill evaluation with the pattern recommended by `/skill-creator`. Use `/tmp/{skill-name}-workspace` as default workspace for ephemeral files.
+
+Evals MUST be adversarial — they test the skill's **unique value**, not common knowledge the model already has. A good eval has a "trap" the model falls into without the skill but avoids with it. Every rule of a skill must have its test.
+
+Size evaluations to the skill's **Directory (tok)** column in README.md: expect **~10 assertions per 1,000 tokens** of skill content (full directory excluding evals), with a **minimum of 50 assertions**. Examples from the current table:
+
+| Skill           | Directory (tok) | Min assertions |
+| --------------- | --------------- | -------------- |
+| Code style      | 2,613           | 50             |
+| Error handling  | 4,145           | 62             |
+| Testing         | 5,913           | 89             |
+| Design patterns | 9,122           | 137            |
+| Security        | 21,470          | 322            |
+| Benchmark       | 29,081          | 436            |
+
+Store your evaluation scenarios in `skills/{name}/evals/evals.json`.
+
+**Design principles:**
+
+- **Never test common knowledge.** If the model passes both with and without the skill, the eval is useless. Avoid testing well-known patterns (e.g. `bufio.Scanner` for file reading, `strings.Builder` for concatenation, basic `make` preallocation).
+- **Test the skill's unique guidance.** Identify what the skill teaches that the model wouldn't do by default — subtle tradeoffs, non-obvious stdlib choices, Go-specific gotchas.
+- **Create traps — natural wrong defaults, not explicit wrong instructions.** A trap makes the obvious/lazy approach incorrect: the task looks like a normal request where the natural implementation is subtly wrong. If the task explicitly instructs the model to use a specific wrong approach, the model follows that instruction regardless of the skill. The skill shifts defaults; it cannot override direct instructions. Good trap: "implement a shared counter for a web handler" (tempts a race condition). Bad trap: "implement a counter using a global int without synchronization".
+- **Test judgment, not API knowledge.** Ask "which data structure?" not "how to use data structure X?". The model knows APIs; the skill adds architectural judgment.
+- **Avoid leading prompts.** Don't mention the correct approach in the task description (e.g. don't say "use container/list" — say "implement LRU cache"). Don't hint at the answer. Don't name the rule, alert type, or problem category — if the prompt labels the issue, the model can reason to the fix without the skill.
+- **Stress-test edge cases.** The skill's common-mistakes tables and "when NOT to use" guidance are high-value targets.
+- **Pre-flight every candidate eval without the skill.** If the model passes, cut it or redesign it before adding it to the suite. This is the cheapest quality gate.
+- **Prefer positive trigger tests over negative ones.** Testing "don't do X when not applicable" is weak — models have a strong prior of not acting when uncertain. Every eval should test the model _doing_ something correctly, not refraining.
+- **Target rules that are saturated in training data last.** Widely-documented patterns, standard stdlib idioms, and common Go conventions appear in countless guides and produce little or no delta. Focus first on rules that are counterintuitive, library-specific, or unique to the skill's domain.
+- **Don't let prompt context substitute for skill knowledge.** If the eval describes the problem with enough specificity that the model can reason to the correct answer, the skill becomes redundant. Present the problem as an opaque or misleading scenario where the skill's rule resolves an ambiguity the model would otherwise get wrong.
+- **Keep assertions within a group homogeneous.** Mixing common-knowledge assertions with skill-specific ones in the same eval group produces a partial score that masks both problems — some assertions pass in both conditions (common knowledge), others fail in both (coverage gap). Each eval group should test a single, skill-specific behavior.
+- **Isolate the evaluated skill.** When running "without" evals, do NOT load any skill that covers overlapping content — a colliding skill would give the model guidance it shouldn't have, inflating the "without" score and masking the evaluated skill's true uplift. When running "with" evals, load only the skill under test (and its explicit cross-references if needed). For example, when evaluating `golang-error-handling`, do not load `golang-code-style` or `golang-safety` — they contain overlapping error-handling advice that would contaminate the baseline.
+
+**Anti-patterns to avoid:**
+
+- Testing `strings.Builder` when the task obviously needs string building → model knows this
+- Testing `make([]T, 0, n)` when the task obviously needs preallocation → model knows this
+- Testing `bufio.Scanner` for file reading → model knows this
+- Testing `container/heap` when the task says "priority queue" → model knows this
+- Any eval group where both with/without score 100% → tests common knowledge, not skill uplift; redesign it
+- Any eval group where both with/without score 0% and the task explicitly requests the wrong approach → tests instruction-following, not skill guidance; remove the explicit wrong instruction and make that approach merely the natural default
+- Any eval group where both with/without score 0% and the task is neutral → the skill has a coverage gap for this case; fix the skill or remove the eval
+- Any eval group where both with/without score identically at a partial value → mixed common-knowledge and coverage-gap assertions; split and redesign each
+- Naming an eval "model already knows this" and keeping it — if you know it's common knowledge, cut it
+- Testing general best practices (widely-known Go idioms, standard stdlib patterns) instead of the skill's specific, non-obvious rules
+
+#### Evaluation Reporting
+
+Eval results go in `EVALUATIONS.md` at the repo root. Append new skill sections — never overwrite previous runs. The file is wrapped in `<!-- prettier-ignore-start/end -->` so Prettier doesn't break the HTML spans.
+
+**Structure per skill:**
+
+```
+## `skill-name` — vX.Y.Z
+
+Summary table (Overall with/without/delta)
+
+<details>
+<summary>Full breakdown (N assertions)</summary>
+
+Metadata line (model, runs, grading method)
+Flat table: # | Assertion | With | Without
+  - Eval header rows: empty # cell, bold eval name + description, bold score spans
+  - Assertion rows: a.b numbering, assertion text, colored ✓/✗ spans
+  - Failed cells may include short evidence after ✗ (e.g. "✗ NewStore()")
+
+</details>
+```
+
+**Styling:** Two CSS classes in the file's `<style>` block — `.g { color: #22863a; font-weight: bold; }` (green/pass) and `.r { color: #cb2431; font-weight: bold; }` (red/fail). Use `<span class="g">✓</span>` for pass and `<span class="r">✗</span>` for fail. Eval header scores use the same classes: `**<span class="g">4/4</span>**` or `**<span class="r">2/4</span>**` (red when score < max).
+
+**Numbering:** `a.b` format — `a` is the eval number, `b` is the assertion within that eval (e.g., `4.3`, `11.2`). Eval header rows leave the `#` cell empty.
+
+See `EVALUATIONS.md` for the canonical format.
+
+After updating `EVALUATIONS.md` sum all the skill reports and update the table in `Skill evaluations` section of README.md.
+
+Also update the **Summary table** at the top of `EVALUATIONS.md`: add a new row for the skill (or update the existing row if re-running), then recompute the **Total** row by summing all numerators and denominators across all skills. The table is ordered by Delta ascending (low → high). Populate the Concern column using these rules: "Low delta" (≤32pp), "High without" (Without ≥65%), "Low with-skill score" (With ≤90%) — combine when multiple apply. Use bold on Concern values to draw attention. The **Uplift** column shows `With / Without` rounded to 2 decimal places and suffixed with `×` (e.g. `1.64×`); recompute it for every row including the Total.
+
+## Workflows
+
+### Working in worktrees
+
+All implementation work MUST happen in a git worktree in `.claude/worktrees/`, never directly on the checked-out branch.
+
+Before starting any task, propose a branch name and ask the developer to confirm. Also run `git worktree list` first — if an existing worktree covers the same skill or a closely related topic, suggest reusing it and let the developer decide.
+
+### After updating a skill
+
+After making changes, suggest the following as next steps for the developer to run. Do NOT execute these automatically.
+
+> **If the skill's scope changed** (new topic added, topic moved to another skill) **or if a skill was added/removed**: update `skills/golang-how-to/SKILL.md` — the skill loading table and the competing clusters section must reflect the current state of the plugin.
+
+1. ~~Validate against the spec: `skills-ref validate ./skills/{name}`~~ (disabled — [skills-ref doesn't support `user-invocable` yet](https://github.com/agentskills/agentskills/issues/105))
+2. Reformat markdowns with `npx prettier --write *.md "**/*.md"` then lint with `markdownlint-cli2 --config .markdownlint-cli2.jsonc ./` — run before measuring tokens, as formatting changes token counts 2b. Run `SNYK_TOKEN=<token> uvx snyk-agent-scan@latest skills/<name>/` and fix any W011/W012/W001 warnings before proceeding (see [Snyk agent scanner compliance](#snyk-agent-scanner-compliance))
+3. Measure token counts:
+   - **Description (tok)**: `awk 'NR==1 && /^---$/{found=1; next} found && /^---$/{exit} found && /^description:/{print}' skills/{name}/SKILL.md | tiktoken-cli`
+   - **SKILL.md (tok)**: `tiktoken-cli skills/{name}/SKILL.md`
+   - **Directory (tok)**: `tiktoken-cli --exclude "evals" skills/{name}/` (exclude `evals/` subdirectory)
+4. Update the README.md table with the measured token counts, update the total rows, and update the **Error rate gap** column (`Without - With`, expressed as a negative percentage, e.g. `-39%`)
+5. Increment `metadata.version` in the changed SKILL.md and the plugin version in `.claude-plugin/plugin.json`, `.cursor-plugin/plugin.json` and `gemini-extension.json` — all three plugin files MUST have the same version
+6. Run skill evaluation via `/skill-creator`: 10+ evals, run them with and without the skill via parallel subagents, grade with LLM-as-judge (no human in the loop), print results, suggest improvements if needed, and append/update the report to `EVALUATIONS.md` following the format in [Evaluation Reporting](#evaluation-reporting)
+7. Depending on evaluation final report, suggest improvements and loop
+
+For initial evaluation of skills, use Human-as-Judge.
+
+### After creating a new skill
+
+After writing a new skill body, run the description optimization loop before marking it ready:
+
+1. Verify the description against quality criteria: contains "Golang", has "Use when"/"Apply when" trigger clause with specific scenarios, no broad anti-patterns (`whenever writing Go code`, `Essential for ANY`, `proactively`), FQN cross-refs for competing skills (`samber/cc-skills-golang@<skill>`), library skills use `Apply when the codebase imports github.com/...` pattern. Description must stay ≤ 1,000 characters.
+2. Follow the [After updating a skill](#after-updating-a-skill) checklist.
+
+### Checking for outdated skills
+
+Skills covering a specific library or framework can become stale when the project releases breaking changes or new APIs. Run this check periodically (e.g. monthly) to surface outdated skills.
+
+1. Grep all SKILL.md files for `skill-library-version` entries to build the inventory.
+2. For each skill with a `skill-library-version`, fetch the latest release from the project's GitHub releases page or changelog via web search.
+3. Compare the skill's recorded version against the latest release. Flag skills where the latest version is a higher major or minor than `skill-library-version`.
+4. For flagged skills, skim the changelog between the recorded version and the latest to identify breaking changes or new APIs that the skill should cover.
+5. Suggest a skill update for each flagged skill, summarizing the relevant changelog entries.
+
+After updating a skill to reflect a new library version, bump `skill-library-version` to the new version and follow the [After updating a skill](#after-updating-a-skill) checklist.
+
+### README status icons
+
+In the README tables, skill names are prefixed with status icons:
+
+- **✅** — skill is complete and active
+- **👷** — skill is work in progress — **set all token counts to 0** for these rows and exclude them from totals
+- **❌** — skill is disabled/not yet started — **set all token counts to 0** for these rows and exclude them from totals
+
+## Plugin Configuration
+
+Plugin metadata is defined in `.claude-plugin/plugin.json`, `.cursor-plugin/plugin.json` and `gemini-extension.json`. All three files MUST have the same `version` value. Fields include:
+
+- Plugin name, version, and description
+- Author and repository information
+- Keywords for discoverability
+
+## Best Practice Sources
+
+Skills:
+
+- <https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices>
+
+Go language:
+
+- <https://go.dev/doc/effective_go>
+- <https://go.dev/ref/spec>
+- <https://go.dev/ref/mem>
+- <https://go.dev/blog/pipelines>
+- <https://go.dev/doc/faq>
+- <https://go-proverbs.github.io/>
+- <https://gobyexample.com/>
+
+Style guides:
+
+- <https://google.github.io/styleguide/go/guide>
+- <https://google.github.io/styleguide/go/decisions>
+- <https://google.github.io/styleguide/go/best-practices.html>
+- <https://github.com/uber-go/guide/blob/master/style.md>
+- <https://github.com/unknwon/go-code-convention/blob/main/en-US.md>
+- <https://go.dev/talks/2014/names.slide>
+
+Common mistakes:
+
+- <https://100go.co/>
+- <https://golang50shades.com/>
+
+Security:
+
+- <https://go.dev/doc/security/best-practices>
+- <https://docs.bearer.com/reference/rules/?lang-go=go_>
+- <https://docs.snyk.io/scan-with-snyk/snyk-code/snyk-code-security-rules/go-rules>
+
+Internals:
+
+- <https://research.swtch.com/godata>
+- <https://research.swtch.com/interfaces>
+
+Testing:
+
+- <https://testing.googleblog.com/2017/10/code-health-identifiernamingpostforworl.html>
+- <https://testing.googleblog.com/2013/03/testing-on-toilet-testing-state-vs.html>
+- <https://testing.googleblog.com/2014/05/testing-on-toilet-effective-testing.html>
+- <https://testing.googleblog.com/2014/05/testing-on-toilet-risk-driven-testing.html>
+- <https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html>
+
+## Formats
+
+Write short sentences.
+
+### Format 5: Imperative Prose (recommended by skill-creator)
+
+```md
+## Writing Rules
+
+Cut ruthlessly — every word must work. Remove filler words like "very", "really", "incredibly". Use active voice. Vary sentence length: 3-5 words for impact, then medium length for explanation.
+```
+
+### Format 1: Categorized examples (Good / Bad)
+
+```md
+## `errors.New` — static error messages
+
+'''go // ✓ Good - {tell why} errors.New("unexpected error)
+
+// ✗ Bad — {tell why} fmt.Errorf("unexpected error) '''
+```
+
+### Format 2: Template / Example-Driven
+
+```md
+## Commit Message Format
+
+ALWAYS use this exact template:
+
+''' <type>[optional scope]: <description> [optional body] '''
+
+**Example 1:** Input: Added user authentication with JWT tokens Output: feat(auth): implement JWT-based authentication
+
+**Example 2:** ...
+```
+
+### Format 3: Categorized Bullet Lists (Do / Don't / Avoid)
+
+```md
+**Formatting:**
+
+- Mobile-first (58% on mobile)
+- Never more than 2 visual lines per paragraph on phone
+- Line breaks between most sentences
+
+**Avoid:**
+
+- Rhetorical questions
+- Empty words ("digital landscape", "incontournable")
+- Emoji abuse
+```
+
+### Format 4: Numbered RFC-style Rules (MUST/MAY/SHOULD)
+
+```md
+## Git conventions
+
+1. Commits MUST be prefixed with a type
+2. The type `feat` MUST be used for new features
+3. A scope MAY be provided after a type, in parentheses
+4. A description MUST immediately follow the colon and space
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/EVALUATIONS.md b/packages/autoskills/skills-registry/samber-go-skills/EVALUATIONS.md
new file mode 100644
index 00000000..3e9b3600
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/EVALUATIONS.md
@@ -0,0 +1,4840 @@
+<!-- prettier-ignore-start -->
+<!-- markdownlint-disable table-column-style -->
+<!-- markdownlint-disable no-space-in-emphasis -->
+
+<style>
+.g { color: #22863a; font-weight: bold; }
+.r { color: #cb2431; font-weight: bold; }
+</style>
+
+# Evaluations
+
+## Summary
+
+| Skill                           | Version | Assertions | With Skill | Without Skill | Delta     | Uplift    | Concern                     |
+| ------------------------------- | ------- | ---------- | ---------- | ------------- | --------- | --------- | --------------------------- |
+| `golang-spf13-viper`            | v1.0.0  | 53         | 98%        | **100%**      | -2pp      | 0.98×     | **Low delta, high without** |
+| `golang-spf13-cobra`            | v1.0.0  | 50         | 100%       | **98%**       | +2pp      | 1.02×     | **Low delta, high without** |
+| `golang-naming`                 | v1.0.0  | 51         | 94%        | **71%**       | +24pp     | 1.32×     | **Low delta, high without** |
+| `golang-swagger`                | v1.0.0  | 60         | 97%        | **72%**       | +25pp     | 1.35×     | **Low delta, high without** |
+| `golang-error-handling`         | v1.0.0  | 60         | 98%        | **72%**       | +27pp     | 1.36×     | **Low delta, high without** |
+| `golang-popular-libraries`      | v1.0.0  | 54         | 100%       | **70%**       | +30pp     | 1.43×     | **Low delta, high without** |
+| `golang-security`               | v1.0.0  | 110        | 100%       | **68%**       | +32pp     | 1.47×     | **Low delta, high without** |
+| `golang-testing`                | v1.0.0  | 65         | 92%        | 60%           | +32pp     | 1.53×     | **Low delta**               |
+| `golang-troubleshooting`        | v1.0.0  | 186        | 100%       | **68%**       | +32pp     | 1.47×     | **Low delta, high without** |
+| `golang-context`                | v1.0.0  | 50         | 96%        | 62%           | +34pp     | 1.55×     |                             |
+| `golang-structs-interfaces`     | v1.0.0  | 52         | 100%       | **65%**       | +35pp     | 1.54×     | **High without**            |
+| `golang-observability`          | v1.0.0  | 185        | 100%       | 63%           | +37pp     | 1.59×     |                             |
+| `golang-design-patterns`        | v1.0.0  | 87         | 100%       | 63%           | +37pp     | 1.59×     |                             |
+| `golang-database`               | v1.0.0  | 74         | 95%        | 57%           | +38pp     | 1.67×     |                             |
+| `golang-project-layout`         | v1.0.0  | 55         | 100%       | 62%           | +38pp     | 1.61×     |                             |
+| `golang-data-structures`        | v1.0.0  | 36         | 100%       | 61%           | +39pp     | 1.64×     |                             |
+| `golang-performance`            | v1.0.0  | 272        | 100%       | 61%           | +39pp     | 1.64×     |                             |
+| `golang-concurrency`            | v1.0.0  | 62         | 100%       | 61%           | +39pp     | 1.64×     |                             |
+| `golang-code-style`             | v1.0.0  | 83         | **80%**    | 40%           | +40pp     | 2.00×     | **Low with-skill score**    |
+| `golang-lint`                 | v1.0.0  | 51         | 96%        | 55%           | +41pp     | 1.75×     |                             |
+| `golang-grpc`                   | v1.0.0  | 55         | 96%        | 55%           | +42pp     | 1.75×     |                             |
+| `golang-cli`                    | v1.0.0  | 58         | 95%        | 52%           | +43pp     | 1.83×     |                             |
+| `golang-dependency-injection`   | v1.0.0  | 55         | 98%        | 51%           | +47pp     | 1.92×     |                             |
+| `golang-stretchr-testify`       | v1.0.0  | 47         | 100%       | 53%           | +47pp     | 1.89×     |                             |
+| `golang-samber-mo`              | v1.0.0  | 108        | **88%**    | 40%           | +48pp     | 2.20×     | **Low with-skill score**    |
+| `golang-benchmark`              | v1.0.0  | 356        | 100%       | 50%           | +50pp     | 2.00×     |                             |
+| `golang-samber-ro`              | v1.0.0  | 113        | 100%       | 50%           | +50pp     | 2.00×     |                             |
+| `golang-documentation`          | v1.0.0  | 103        | 90%        | 37%           | +53pp     | 2.43×     |                             |
+| `golang-samber-hot`             | v1.0.0  | 65         | 94%        | 40%           | +54pp     | 2.35×     |                             |
+| `golang-dependency-management`  | v1.0.0  | 52         | 100%       | 46%           | +54pp     | 2.17×     |                             |
+| `golang-stay-updated`           | v1.0.0  | 50         | 92%        | 36%           | +56pp     | 2.56×     |                             |
+| `golang-safety`                 | v1.0.0  | 151        | 99%        | 41%           | +58pp     | 2.41×     |                             |
+| `golang-continuous-integration` | v1.0.0  | 66         | 100%       | 41%           | +59pp     | 2.44×     |                             |
+| `golang-samber-oops`            | v1.0.0  | 52         | 94%        | 35%           | +60pp     | 2.69×     |                             |
+| `golang-modernize`              | v1.0.0  | 76         | 95%        | 34%           | +61pp     | 2.79×     |                             |
+| `golang-samber-slog`            | v1.0.0  | 62         | 92%        | **73%**       | +19pp     | 1.26×     | **Low delta, high without** |
+| `golang-samber-lo`              | v1.0.0  | 86         | 97%        | 57%           | +40pp     | 1.70×     |                             |
+| `golang-uber-fx`                | v1.0.0  | 21         | 100%       | **95%**       | +5pp      | 1.05×     | **Low delta, high without** |
+| `golang-uber-dig`               | v1.0.0  | 20         | 100%       | **90%**       | +10pp     | 1.11×     | **Low delta, high without** |
+| `golang-google-wire`            | v1.0.0  | 50         | 98%        | **82%**       | +16pp     | 1.20×     | **Low delta, high without** |
+| `golang-graphql`                | v0.0.2  | 59         | 100%       | **83%**       | +17pp     | 1.20×     | **Low delta, high without** |
+| `golang-samber-do`              | v1.0.0  | 53         | 100%       | 19%           | +81pp     | 5.26×     |                             |
+| **Total (41 skills)**           |         | **3395**   | **98%**    | **56%**       | **+41pp** | **1.73×** |                             |
+
+## `golang-naming` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **48/51 (94%)** | **36/51 (71%)** | **+24pp** |
+
+<details>
+<summary>Full breakdown (51 assertions)</summary>
+
+**Model:** Claude Opus 4.6 | **Runs:** 12 evals × 2 configs = 24 subagents | **Grading:** automated regex
+
+| #    | Assertion                                                                        | With                           | Without                                     |
+| ---- | -------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------- |
+|      | **1. cache** — Get/Set/Delete, sentinel errors, options                          | **<span class="g">4/5</span>** | **<span class="g">4/5</span>**              |
+| 1.1  | Constructor is `New()`                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 1.2  | Error strings include `"cache:"` prefix                                          | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 1.3  | Option functions use `With` prefix                                               | <span class="r">✗</span>       | <span class="r">✗</span>                    |
+| 1.4  | Error strings fully lowercase                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 1.5  | Option type is `Option` not `CacheOption`                                        | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+|      | **2. worker** — boolean fields: processing/initialized/canAccept                 | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**              |
+| 2.1  | Boolean fields use `is`/`has`/`can` prefix                                       | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 2.2  | Getter methods use `Is`/`Has`/`Can` prefix                                       | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 2.3  | Constructor is `New()`                                                           | <span class="g">✓</span>       | <span class="r">✗</span>                    |
+| 2.4  | Receiver is 1-2 letter abbreviation                                              | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+|      | **3. taskqueue** — `TaskStatus` enum (iota) + `String()`                         | **<span class="g">2/3</span>** | **<span class="g">2/3</span>**              |
+| 3.1  | Enum values prefixed with type name                                              | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 3.2  | Zero value is `TaskStatusUnknown` sentinel                                       | <span class="r">✗</span>       | <span class="r">✗</span>                    |
+| 3.3  | `String()` method on enum type                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+|      | **4. httpclient** — fix naming: `HttpClient`, `base_url`, `GetBaseUrl()`, `this` | **<span class="g">6/7</span>** | **<span class="r">3/7</span>**              |
+| 4.1  | Struct renamed to `Client` (anti-stutter)                                        | <span class="g">✓</span>       | <span class="r">✗</span> kept HTTPClient    |
+| 4.2  | Constructor renamed to `New()`                                                   | <span class="g">✓</span>       | <span class="r">✗</span> NewHTTPClient()    |
+| 4.3  | Field uses `baseURL` (correct acronym)                                           | <span class="r">✗</span>       | <span class="r">✗</span>                    |
+| 4.4  | Getter drops `Get` prefix: `BaseURL()`                                           | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 4.5  | Boolean getter uses `IsConnected()`                                              | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 4.6  | Receiver is 1-2 letters, not `this`                                              | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 4.7  | Boolean field uses `isConnected`                                                 | <span class="g">✓</span>       | <span class="r">✗</span> bare `connected`   |
+|      | **5. auth-tests** — table-driven tests for `ValidateToken()`                     | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**              |
+| 5.1  | Subtest names fully lowercase                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                    |
+| 5.2  | Acronyms lowercase in subtests                                                   | <span class="g">✓</span>       | <span class="r">✗</span> uppercase "ID"     |
+| 5.3  | Test function named `TestValidateToken`                                          | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 5.4  | Table struct uses descriptive field names                                        | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+|      | **6. storage** — functional options: bucket, region, endpoint URL, retries       | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**              |
+| 6.1  | Option type is `Option` not `StoreOption`                                        | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 6.2  | All option functions use `With` prefix                                           | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 6.3  | Constructor is `New()`                                                           | <span class="g">✓</span>       | <span class="r">✗</span> NewStore()         |
+| 6.4  | `URL` acronym is all-caps                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+|      | **7. metrics** — MixedCaps constants, sentinel errors                            | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**              |
+| 7.1  | Constants use MixedCaps not ALL_CAPS                                             | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 7.2  | Error variables use `Err` prefix                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 7.3  | Error strings fully lowercase                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 7.4  | Error strings include `"metrics:"` prefix                                        | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+|      | **8. notifier** — email/SMS/push interfaces, Dispatcher, error types             | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**              |
+| 8.1  | Interface uses `-er` suffix                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 8.2  | No stuttering in type names                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 8.3  | Constructor is `New()`                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 8.4  | Error types use `Error` suffix                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+|      | **9. eventbus** — sentinel errors incl. "invalid event ID", custom error type    | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**              |
+| 9.1  | Sentinel errors use `Err` prefix                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 9.2  | Custom error type uses `Error` suffix                                            | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 9.3  | Error string uses lowercase `"id"`                                               | <span class="g">✓</span>       | <span class="r">✗</span> "invalid event ID" |
+| 9.4  | Error strings include `"eventbus:"` prefix                                       | <span class="g">✓</span>       | <span class="r">✗</span> no prefix          |
+|      | **10. config** — Load/Save/Get/Set/Validate/Reset/MergeFrom/String               | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**              |
+| 10.1 | All methods use consistent 1-2 letter receiver                                   | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 10.2 | Constructor is `New()`                                                           | <span class="g">✓</span>       | <span class="r">✗</span> NewConfig()        |
+| 10.3 | No stuttering in type names                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+|      | **11. ratelimiter** — token bucket, options, Status enum, boolean methods        | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**              |
+| 11.1 | Constructor is `New()`                                                           | <span class="g">✓</span>       | <span class="r">✗</span> NewLimiter()       |
+| 11.2 | Status enum has `StatusUnknown` at iota 0                                        | <span class="g">✓</span>       | <span class="r">✗</span> Allowed at iota 0  |
+| 11.3 | Boolean methods use `Is`/`Has` prefix                                            | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 11.4 | Option functions use `With` prefix                                               | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 11.5 | Error strings lowercase with package prefix                                      | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+|      | **12. parser** — `Parse`, `MustParse`, `ParseWithContext`, `AST`, `ParseError`   | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**              |
+| 12.1 | Panic variant uses `MustParse`                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 12.2 | Context variant uses `ParseWithContext`                                          | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 12.3 | Error type uses `ParseError`                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+| 12.4 | No stuttering on constructor                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                    |
+
+</details>
+
+## `golang-code-style` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **66/83 (80%)** | **33/83 (40%)** | **+40pp** |
+
+<details>
+<summary>Full breakdown (83 assertions across 24 evals)</summary>
+
+**Model:** Claude Sonnet 4.6 | **Runs:** 24 evals × 2 configs = 48 runs | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                         | With                                        | Without                                                    |
+| ---- | --------------------------------------------------------------------------------- | ------------------------------------------- | ---------------------------------------------------------- |
+|      | **1. cache** — var declarations: `:=` vs `var`, zero-value init                   | **<span class="g">3/3</span>**              | **<span class="g">3/3</span>**                             |
+| 1.1  | Zero-value fields omitted from constructor (rely on Go zero values)               | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 1.2  | Non-zero assignments use `:=` short declaration                                   | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 1.3  | Done channel created with `make()`, not nil                                       | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+|      | **2. handler** — slice/map initialization: never nil                              | **<span class="g">3/3</span>**              | **<span class="r">2/3</span>**                             |
+| 2.1  | Empty slice uses `[]User{}` or `make()`, not nil                                  | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 2.2  | Empty map uses `map[K]V{}` or `make()`, not nil                                   | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 2.3  | Known-capacity collections use `make()` with size hint                            | <span class="g">✓</span>                    | <span class="r">✗</span> no capacity hint                  |
+|      | **3. server** — composite literals: named fields                                  | **<span class="g">3/3</span>**              | **<span class="g">3/3</span>**                             |
+| 3.1  | `http.Server` uses named fields                                                   | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 3.2  | `tls.Config` uses named fields                                                    | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 3.3  | No positional struct syntax in file                                               | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+|      | **4. orders** — early return: guard clauses, flat happy path                      | **<span class="g">3/3</span>**              | **<span class="r">0/3</span>**                             |
+| 4.1  | Validation uses early return, not nested else                                     | <span class="g">✓</span>                    | <span class="r">✗</span> deeply nested if-else             |
+| 4.2  | Happy path at indentation level 1                                                 | <span class="g">✓</span>                    | <span class="r">✗</span> level 5 nesting                   |
+| 4.3  | Max 2 indentation levels for main logic                                           | <span class="g">✓</span>                    | <span class="r">✗</span> 6 levels deep                     |
+|      | **5. auth** — unnecessary else: early return, default-then-override               | **<span class="g">2/2</span>**              | **<span class="r">1/2</span>**                             |
+| 5.1  | `GetUserRole` uses no else after return                                           | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 5.2  | `SetLogLevel` uses default-then-override (no else)                                | <span class="g">✓</span>                    | <span class="r">✗</span> `var` zero-value + switch default |
+|      | **6. events** — switch vs if-else chains                                          | **<span class="g">3/3</span>**              | **<span class="r">2/3</span>**                             |
+| 6.1  | `HandleEvent` uses switch                                                         | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 6.2  | `MapStatusCode` uses switch                                                       | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 6.3  | Both switches include default case                                                | <span class="g">✓</span>                    | <span class="r">✗</span> HandleEvent no default            |
+|      | **7. notify** — function design: ≤4 params, options struct                        | **<span class="g">3/3</span>**              | **<span class="r">1/3</span>**                             |
+| 7.1  | `context.Context` is first parameter                                              | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 7.2  | Options struct reduces params to ≤4                                               | <span class="g">✓</span>                    | <span class="r">✗</span> 10 individual params              |
+| 7.3  | Config fields grouped in options struct                                           | <span class="g">✓</span>                    | <span class="r">✗</span> no struct                         |
+|      | **8. users** — value vs pointer: small types by value                             | **<span class="g">3/3</span>**              | **<span class="r">1/3</span>**                             |
+| 8.1  | `FormatName` takes `string` by value, not `*string`                               | <span class="g">✓</span>                    | <span class="r">✗</span> `*string` params                  |
+| 8.2  | `UpdateAge` takes `*User` (mutation)                                              | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 8.3  | `CompareUsers` takes `User` by value (small, read-only)                           | <span class="g">✓</span>                    | <span class="r">✗</span> `*User` params                    |
+|      | **9. repository** — code organization: canonical ordering                         | **<span class="g">3/3</span>**              | **<span class="g">3/3</span>**                             |
+| 9.1  | File ordered: imports → constants → interface → struct → ctor → methods → helpers | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 9.2  | Interface declared before implementing struct                                     | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 9.3  | Helpers after all methods, not interleaved                                        | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+|      | **10. report** — string handling: strconv, Builder, Sprintf                       | **<span class="g">3/3</span>**              | **<span class="g">3/3</span>**                             |
+| 10.1 | Int-to-string uses `strconv.Itoa`, not `fmt.Sprintf`                              | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 10.2 | Loop concatenation uses `strings.Builder`                                         | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 10.3 | Complex formatting uses `fmt.Sprintf`                                             | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+|      | **11. authz** — complex conditions: named booleans                                | **<span class="r">1/3</span>**              | **<span class="r">1/3</span>**                             |
+| 11.1 | ≥2 conditions extracted to named booleans                                         | <span class="r">✗</span> all inline         | <span class="r">✗</span> all inline                        |
+| 11.2 | Named booleans have descriptive names                                             | <span class="r">✗</span> no booleans        | <span class="r">✗</span> no booleans                       |
+| 11.3 | Expensive check kept inline for short-circuit                                     | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+|      | **12. router** — line breaking: semantic boundaries                               | **<span class="r">0/3</span>**              | **<span class="r">0/3</span>**                             |
+| 12.1 | Multi-arg calls broken across lines                                               | <span class="r">✗</span> single-line calls  | <span class="r">✗</span> single-line calls                 |
+| 12.2 | Breaks at semantic boundaries (commas)                                            | <span class="r">✗</span> no breaks          | <span class="r">✗</span> no breaks                         |
+| 12.3 | Closing paren on own line (trailing-comma style)                                  | <span class="r">✗</span> no multi-line      | <span class="r">✗</span> no multi-line                     |
+|      | **13. nil-return** — (adversarial: "return nil, caller checks")                   | **<span class="r">0/3</span>**              | **<span class="r">0/3</span>**                             |
+| 13.1 | GetUsers returns `[]User{}` not nil for empty                                     | <span class="r">✗</span> `var` nil slice    | <span class="r">✗</span> `var` nil slice                   |
+| 13.2 | GetMetadata returns `map{}` not nil for empty                                     | <span class="r">✗</span> lazy-init nil      | <span class="r">✗</span> lazy-init nil                     |
+| 13.3 | No `return nil` as success path                                                   | <span class="r">✗</span> returns nil        | <span class="r">✗</span> returns nil                       |
+|      | **14. sprintf-concat** — (adversarial: "use Sprintf and +=")                      | **<span class="r">0/4</span>**              | **<span class="r">0/4</span>**                             |
+| 14.1 | Uses `strconv.Itoa`, not `fmt.Sprintf`                                            | <span class="r">✗</span> Sprintf            | <span class="r">✗</span> Sprintf                           |
+| 14.2 | Uses `strings.Builder`, not `+=`                                                  | <span class="r">✗</span> result +=          | <span class="r">✗</span> result +=                         |
+| 14.3 | No `+=` inside loop body                                                          | <span class="r">✗</span> += in loop         | <span class="r">✗</span> += in loop                        |
+| 14.4 | Builder declared before loop                                                      | <span class="r">✗</span> no Builder         | <span class="r">✗</span> no Builder                        |
+|      | **15. positional-fields** — (adversarial: "positional for brevity")               | **<span class="g">4/4</span>**              | **<span class="r">0/4</span>**                             |
+| 15.1 | Point uses named fields                                                           | <span class="g">✓</span>                    | <span class="r">✗</span> `Point{1.5, 2.5}`                 |
+| 15.2 | Color uses named fields                                                           | <span class="g">✓</span>                    | <span class="r">✗</span> `Color{255, 128, 0, 255}`         |
+| 15.3 | ServerConfig uses named fields                                                    | <span class="g">✓</span>                    | <span class="r">✗</span> positional                        |
+| 15.4 | No positional syntax in file                                                      | <span class="g">✓</span>                    | <span class="r">✗</span> all positional                    |
+|      | **16. deep-nesting** — (adversarial: "nested if-else is clearer")                 | **<span class="g">4/4</span>**              | **<span class="r">0/4</span>**                             |
+| 16.1 | Validations use early return                                                      | <span class="g">✓</span>                    | <span class="r">✗</span> nested if-else                    |
+| 16.2 | No nested else blocks for validation                                              | <span class="g">✓</span>                    | <span class="r">✗</span> 6 else blocks                     |
+| 16.3 | Happy path at indentation level 1                                                 | <span class="g">✓</span>                    | <span class="r">✗</span> level 6 nesting                   |
+| 16.4 | Max 2 indentation levels                                                          | <span class="g">✓</span>                    | <span class="r">✗</span> 7 levels deep                     |
+|      | **17. ctx-last-many-params** — (adversarial: "keep exact order")                  | **<span class="r">0/4</span>**              | **<span class="r">0/4</span>**                             |
+| 17.1 | `context.Context` is first parameter                                              | <span class="r">✗</span> position 11        | <span class="r">✗</span> position 11                       |
+| 17.2 | ≤4 params with options struct                                                     | <span class="r">✗</span> 12 params          | <span class="r">✗</span> 12 params                         |
+| 17.3 | Options struct groups config                                                      | <span class="r">✗</span> no struct          | <span class="r">✗</span> no struct                         |
+| 17.4 | Logger in struct or on Service type                                               | <span class="r">✗</span> standalone         | <span class="r">✗</span> standalone                        |
+|      | **18. pointer-everything** — (adversarial: "pointers for zero-copy")              | **<span class="g">5/5</span>**              | **<span class="g">5/5</span>**                             |
+| 18.1 | `Add` takes `(int, int) int`                                                      | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 18.2 | `IsEven` takes `(int) bool`                                                       | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 18.3 | `FormatDuration` takes `(Duration) string`                                        | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 18.4 | `Concat` takes `(string, string) string`                                          | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 18.5 | No pointer params for small types                                                 | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+|      | **19. inline-conditions** — (adversarial: "do NOT use variables", 5 conds)        | **<span class="g">4/4</span>**              | **<span class="r">1/4</span>**                             |
+| 19.1 | ≥3 conditions extracted to named booleans                                         | <span class="g">✓</span>                    | <span class="r">✗</span> all inline                        |
+| 19.2 | Descriptive domain names (isSuperAdmin, sameDepartment…)                          | <span class="g">✓</span>                    | <span class="r">✗</span> no booleans                       |
+| 19.3 | Final if/switch reads like business logic                                         | <span class="g">✓</span>                    | <span class="r">✗</span> wall of conditions                |
+| 19.4 | Expensive checks extracted last or kept inline                                    | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+|      | **20. single-line-handlers** — (adversarial: "compact single line", 8 args)       | **<span class="g">4/4</span>**              | **<span class="r">1/4</span>**                             |
+| 20.1 | `processRequest` broken across multiple lines                                     | <span class="g">✓</span>                    | <span class="r">✗</span> single-line calls                 |
+| 20.2 | No line exceeds ~140 characters                                                   | <span class="g">✓</span>                    | <span class="r">✗</span> 170+ char lines                   |
+| 20.3 | Closing paren on own line                                                         | <span class="g">✓</span>                    | <span class="r">✗</span> all inline                        |
+| 20.4 | Service name extracted to constant                                                | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+|      | **21. else-chains** — (adversarial: "use else after every if")                    | **<span class="g">4/4</span>**              | **<span class="r">0/4</span>**                             |
+| 21.1 | Uses switch or early returns, not if-else chain                                   | <span class="g">✓</span>                    | <span class="r">✗</span> if/else-if/else chain             |
+| 21.2 | No `else` keyword in function body                                                | <span class="g">✓</span>                    | <span class="r">✗</span> 5 else keywords                   |
+| 21.3 | Each condition returns without else block                                         | <span class="g">✓</span>                    | <span class="r">✗</span> every return has else             |
+| 21.4 | Uses tagless switch for multi-condition                                           | <span class="g">✓</span>                    | <span class="r">✗</span> no switch                         |
+|      | **22. export-everything** — (adversarial: "export all for reusability")           | **<span class="r">3/4</span>**              | **<span class="r">2/4</span>**                             |
+| 22.1 | ≥2 internal helpers unexported                                                    | <span class="r">✗</span> all funcs exported | <span class="r">✗</span> all exported                      |
+| 22.2 | Internal types unexported                                                         | <span class="g">✓</span>                    | <span class="r">✗</span> `DangerousHeaders` exported       |
+| 22.3 | Public API functions remain exported                                              | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 22.4 | No purely-internal function exported                                              | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+|      | **23. speculative-prealloc** — (adversarial: "make([], 0, 100000)")               | **<span class="g">4/4</span>**              | **<span class="g">4/4</span>**                             |
+| 23.1 | Results not preallocated with 100000                                              | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 23.2 | Metadata not preallocated with 10000                                              | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 23.3 | Outer slice uses `len(jobIDs)` hint                                               | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+| 23.4 | No capacity hint > 1000                                                           | <span class="g">✓</span>                    | <span class="g">✓</span>                                   |
+|      | **24. nested-loop** — (adversarial: "nested if-else in loop body")                | **<span class="g">4/4</span>**              | **<span class="r">0/4</span>**                             |
+| 24.1 | Uses `continue` for validation failures                                           | <span class="g">✓</span>                    | <span class="r">✗</span> nested if-else                    |
+| 24.2 | Max 2 indentation levels in loop                                                  | <span class="g">✓</span>                    | <span class="r">✗</span> 5 levels deep                     |
+| 24.3 | ≥1 helper function extracted                                                      | <span class="g">✓</span>                    | <span class="r">✗</span> everything inline                 |
+| 24.4 | Happy path at shallowest loop level                                               | <span class="g">✓</span>                    | <span class="r">✗</span> nested 4+ deep                    |
+
+</details>
+
+## `golang-data-structures` — v1.0.0
+
+|             | With Skill       | Without Skill   | Delta     |
+| ----------- | ---------------- | --------------- | --------- |
+| **Overall** | **36/36 (100%)** | **22/36 (61%)** | **+39pp** |
+
+<details>
+<summary>Full breakdown (36 assertions)</summary>
+
+**Model:** Claude Sonnet 4.6 | **Runs:** 12 evals × 2 configs = 24 subagents | **Grading:** Human-as-judge
+
+| #    | Assertion                                                           | With                           | Without                                                |
+| ---- | ------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------ |
+|      | **1. buffer-for-io** — RenderAndStream to io.Writer                 | **<span class="g">3/3</span>** | **<span class="g">3/3</span>**                         |
+| 1.1  | Correct output to io.Writer                                         | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 1.2  | Efficient output assembly with Grow                                 | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 1.3  | No unnecessary intermediate allocation                              | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **2. sorted-set** — SortedSet[T] with Min/Max/Insert                | **<span class="g">3/3</span>** | **<span class="g">3/3</span>**                         |
+| 2.1  | Uses `cmp.Ordered` constraint                                       | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 2.2  | Binary search for Insert/Contains                                   | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 2.3  | Min/Max O(1) from sorted slice ends                                 | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **3. AddCleanup** — string intern with auto map shrink              | **<span class="g">3/3</span>** | **<span class="r">1/3</span>**                         |
+| 3.1  | Uses `weak.Pointer` or `weak.Make`                                  | <span class="g">✓</span>       | <span class="r">✗</span> `runtime.SetFinalizer`        |
+| 3.2  | Uses `runtime.AddCleanup` (not SetFinalizer)                        | <span class="g">✓</span>       | <span class="r">✗</span> SetFinalizer + unique.Handle  |
+| 3.3  | Dead map entries automatically removed                              | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **4. unsafe.Add-modern** — read packed binary header (Go 1.17+)     | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                         |
+| 4.1  | Uses `unsafe.Add` for pointer arithmetic                            | <span class="g">✓</span>       | <span class="r">✗</span> `uintptr` arithmetic          |
+| 4.2  | No intermediate `uintptr` variable                                  | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 4.3  | Bounds check before unsafe access                                   | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **5. full-slice-expr** — SplitIntoChunks with append-safe output    | **<span class="g">3/3</span>** | **<span class="r">1/3</span>**                         |
+| 5.1  | Chunks are append-safe (no aliasing)                                | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 5.2  | Uses full-slice expression `[:n:n]`                                 | <span class="g">✓</span>       | <span class="r">✗</span> `make` + `copy` per chunk     |
+| 5.3  | Minimal extra allocations (reuses backing array)                    | <span class="g">✓</span>       | <span class="r">✗</span> N fresh allocations           |
+|      | **6. list-valid-use** — OrderedMap with O(1) middle deletion        | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                         |
+| 6.1  | Uses `container/list` from stdlib                                   | <span class="g">✓</span>       | <span class="r">✗</span> custom generic linked list    |
+| 6.2  | Map stores `*list.Element` for O(1) access                          | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 6.3  | Delete is O(1) via element reference                                | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **7. composite-struct-key** — route cache keyed by (method, path)   | **<span class="g">3/3</span>** | **<span class="r">0/3</span>**                         |
+| 7.1  | Uses struct or array as map key                                     | <span class="g">✓</span>       | <span class="r">✗</span> string concat with NUL sep    |
+| 7.2  | Zero allocation on lookup path                                      | <span class="g">✓</span>       | <span class="r">✗</span> complex `unsafe` stack tricks |
+| 7.3  | Simple, readable key type                                           | <span class="g">✓</span>       | <span class="r">✗</span> `sync.Map` + `unsafe` hacks   |
+|      | **8. map-memory-diag** — diagnose 2GB RSS after bulk delete         | **<span class="g">3/3</span>** | **<span class="g">3/3</span>**                         |
+| 8.1  | Diagnoses "maps never shrink buckets"                               | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 8.2  | Compact creates fresh map with `make`                               | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 8.3  | Copies surviving entries to new map                                 | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **9. ring-round-robin** — LoadBalancer cycling backends forever     | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                         |
+| 9.1  | Uses `container/ring` for round-robin                               | <span class="g">✓</span>       | <span class="r">✗</span> `atomic.Uint64` counter       |
+| 9.2  | No integer overflow risk                                            | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 9.3  | Correct rotation on each call                                       | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **10. large-struct-ptr** — DocumentStore with 20-field Document     | **<span class="g">3/3</span>** | **<span class="r">1/3</span>**                         |
+| 10.1 | Uses pointer map `map[string]*Document`                             | <span class="g">✓</span>       | <span class="r">✗</span> `map[string]Document` value   |
+| 10.2 | Get returns stored pointer (no copy)                                | <span class="g">✓</span>       | <span class="r">✗</span> copies from map, takes `&`    |
+| 10.3 | Uses `sync.RWMutex` for concurrent reads                            | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **11. small-struct-val** — CoordTracker with 16-byte Coord          | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                         |
+| 11.1 | Uses value map `map[string]Coord` (not pointer)                     | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 11.2 | Explains < 128-byte threshold for value vs pointer choice           | <span class="g">✓</span>       | <span class="r">✗</span> no threshold analysis         |
+| 11.3 | Proportional complexity for struct size                             | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **12. clip-after-delete** — PurgeInactive with large Profile fields | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                         |
+| 12.1 | No dead references in result slice                                  | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 12.2 | Uses `slices.DeleteFunc` + `slices.Clip`                            | <span class="g">✓</span>       | <span class="r">✗</span> manual loop + `make`          |
+| 12.3 | Excess capacity released                                            | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+
+</details>
+
+## `golang-safety` — v1.0.0
+
+|             | With Skill        | Without Skill    | Delta     |
+| ----------- | ----------------- | ---------------- | --------- |
+| **Overall** | **150/151 (99%)** | **62/151 (41%)** | **+58pp** |
+
+<details>
+<summary>Full breakdown (151 assertions across 36 evals)</summary>
+
+**Model:** Claude Sonnet 4.6 | **Runs:** 36 evals × 2 configs = 72 runs | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                         | With                                    | Without                                                     |
+| ---- | --------------------------------------------------------------------------------- | --------------------------------------- | ----------------------------------------------------------- |
+|      | **1. validator** — `Validate(Config) error` with `*ConfigError` local variable    | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 1.1  | Returns untyped `nil` on valid config                                             | <span class="g">✓</span>                | <span class="r">✗</span> `return configErr` (typed nil)     |
+| 1.2  | No typed nil pointer leaked through `error` interface                             | <span class="g">✓</span>                | <span class="r">✗</span> interface{*ConfigError, nil}       |
+| 1.3  | ConfigError.Error() includes Field name                                           | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 1.4  | Validates both Host and Port                                                      | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **2. sliceutil** — `AddDefaults(base, defaults)` append to input slice            | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 2.1  | Does not modify caller's input slice                                              | <span class="g">✓</span>                | <span class="r">✗</span> `base = append(base, v)`           |
+| 2.2  | Uses full-slice expression or clone to prevent aliasing                           | <span class="g">✓</span>                | <span class="r">✗</span> appends directly to `base`         |
+| 2.3  | Correctly checks membership                                                       | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 2.4  | Does not modify defaults slice                                                    | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **3. user** — `UserProfile` with Permissions/Metadata getter methods              | **<span class="g">5/5</span>**          | **<span class="r">1/5</span>**                              |
+| 3.1  | Collection fields are unexported                                                  | <span class="g">✓</span>                | <span class="r">✗</span> exported `Permissions`, `Metadata` |
+| 3.2  | `GetPermissions` returns defensive copy                                           | <span class="g">✓</span>                | <span class="r">✗</span> returns `u.Permissions`            |
+| 3.3  | `GetMetadata` returns defensive copy                                              | <span class="g">✓</span>                | <span class="r">✗</span> returns `u.Metadata`               |
+| 3.4  | Scalar fields (Name, Email) can stay exported                                     | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 3.5  | Handles nil internal fields gracefully                                            | <span class="g">✓</span>                | <span class="r">✗</span> no nil handling                    |
+|      | **4. db** — `PingAll(hosts)` with `defer db.Close()` in loop                      | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 4.1  | No bare `defer` in loop body                                                      | <span class="g">✓</span>                | <span class="r">✗</span> `defer db.Close()` in `for` loop   |
+| 4.2  | Extracts loop body to helper function                                             | <span class="g">✓</span>                | <span class="r">✗</span> all in one function                |
+| 4.3  | Checks error from sql.Open                                                        | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 4.4  | Returns meaningful error when none respond                                        | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **5. protocol** — `WriteHeader(w, contentLength int64)` as uint32                 | **<span class="g">4/4</span>**          | **<span class="r">0/4</span>**                              |
+| 5.1  | Bounds-checks before narrowing `int64` to `uint32`                                | <span class="g">✓</span>                | <span class="r">✗</span> `uint32(contentLength)` directly   |
+| 5.2  | Returns error for out-of-range values                                             | <span class="g">✓</span>                | <span class="r">✗</span> silent truncation                  |
+| 5.3  | Checks for negative contentLength                                                 | <span class="g">✓</span>                | <span class="r">✗</span> negative wraps to large uint32     |
+| 5.4  | Uses math.MaxUint32 for bound check                                               | <span class="g">✓</span>                | <span class="r">✗</span> no check at all                    |
+|      | **6. parser** — `ExtractToken(response)` returns first 32 bytes                   | **<span class="g">4/4</span>**          | **<span class="r">0/4</span>**                              |
+| 6.1  | Does not return raw subslice of input                                             | <span class="g">✓</span>                | <span class="r">✗</span> `response[:32]`                    |
+| 6.2  | Uses clone/copy to release backing array                                          | <span class="g">✓</span>                | <span class="r">✗</span> retains full backing array         |
+| 6.3  | Handles short input (len < 32)                                                    | <span class="g">✓</span>                | <span class="r">✗</span> panics on short input              |
+| 6.4  | Result independent of input                                                       | <span class="g">✓</span>                | <span class="r">✗</span> aliases input                      |
+|      | **7. dispatch** — `ProcessMessage(msg any)` with type assertions                  | **<span class="g">4/4</span>**          | **<span class="r">3/4</span>**                              |
+| 7.1  | Uses comma-ok form, not bare assertion                                            | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 7.2  | Handles unknown types without panic                                               | <span class="g">✓</span>                | <span class="r">✗</span> returns empty string silently      |
+| 7.3  | Uses strings.ToUpper                                                              | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 7.4  | Uses strconv/fmt for int conversion                                               | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **8. worker** — `Task.Run()` calls `OnComplete` callback                          | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 8.1  | Checks `OnComplete` for nil before calling                                        | <span class="g">✓</span>                | <span class="r">✗</span> `t.OnComplete(result)` directly    |
+| 8.2  | Usable without setting callback                                                   | <span class="g">✓</span>                | <span class="r">✗</span> panics on `Task{Name:"x"}.Run()`   |
+| 8.3  | Work completes regardless of callback                                             | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 8.4  | Uses pointer receiver                                                             | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **9. router** — `NewRouter(prefix)` + `Handle()` with routes map                  | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 9.1  | Map initialized before write                                                      | <span class="g">✓</span>                | <span class="r">✗</span> nil map, Handle panics             |
+| 9.2  | Usable after NewRouter                                                            | <span class="g">✓</span>                | <span class="r">✗</span> first Handle panics                |
+| 9.3  | Stores handler correctly                                                          | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 9.4  | Returns pointer                                                                   | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **10. pricing** — `IsDiscountApplied` comparing float results                     | **<span class="g">4/4</span>**          | **<span class="r">1/4</span>**                              |
+| 10.1 | Uses epsilon comparison, not `==`                                                 | <span class="g">✓</span>                | <span class="r">✗</span> `finalPrice == expected`           |
+| 10.2 | Reasonable epsilon value                                                          | <span class="g">✓</span>                | <span class="r">✗</span> no epsilon                         |
+| 10.3 | Correct discount formula                                                          | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 10.4 | Handles edge cases (zero price, 100% discount)                                    | <span class="g">✓</span>                | <span class="r">✗</span> no edge case handling              |
+|      | **11. cache** — `Cache.All()` returns all entries                                 | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 11.1 | `All()` returns defensive copy                                                    | <span class="g">✓</span>                | <span class="r">✗</span> returns `c.data` directly          |
+| 11.2 | Constructor initializes map                                                       | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 11.3 | Get uses comma-ok idiom                                                           | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 11.4 | Callers cannot modify cache via All()                                             | <span class="g">✓</span>                | <span class="r">✗</span> shared reference                   |
+|      | **12. pipeline** — `FanIn(channels...)` merges variadic channels                  | **<span class="g">4/4</span>**          | **<span class="r">3/4</span>**                              |
+| 12.1 | Handles closed channels                                                           | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 12.2 | Output closed once                                                                | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 12.3 | No goroutine leaks                                                                | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 12.4 | Handles nil input channels                                                        | <span class="g">✓</span>                | <span class="r">✗</span> nil channel blocks goroutine       |
+|      | **13. parser** — `TryParse` wrapping `*ParseError` into `error` via named returns | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 13.1 | No typed nil leaked through named return                                          | <span class="g">✓</span>                | <span class="r">✗</span> `err = parseErr` unconditional     |
+| 13.2 | Named err only set when non-nil                                                   | <span class="g">✓</span>                | <span class="r">✗</span> always assigned                    |
+| 13.3 | ParseError.Error() includes Line                                                  | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 13.4 | Parse returns nil *ParseError on success                                          | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **14. notify** — `NotifyAll(n *Notifier, msgs)` with nil Notifier                 | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 14.1 | Handles nil *Notifier without panic                                               | <span class="g">✓</span>                | <span class="r">✗</span> dereferences `n.webhook`           |
+| 14.2 | Returns meaningful error when nil                                                 | <span class="g">✓</span>                | <span class="r">✗</span> panics                             |
+| 14.3 | Iterates messages, returns first error                                            | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 14.4 | Send uses webhook field                                                           | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **15. inventory** — `Inventory.Items()` returns items list                        | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 15.1 | Items() returns defensive copy                                                    | <span class="g">✓</span>                | <span class="r">✗</span> returns `inv.items`                |
+| 15.2 | Add uses append correctly                                                         | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 15.3 | Modifying returned slice doesn't affect Inventory                                 | <span class="g">✓</span>                | <span class="r">✗</span> shared backing array               |
+| 15.4 | Field is unexported                                                               | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **16. httputil** — `HeaderString(map)` formatting headers                         | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 16.1 | Sorts keys for deterministic output                                               | <span class="g">✓</span>                | <span class="r">✗</span> ranges over map directly           |
+| 16.2 | Uses sort or slices.Sorted                                                        | <span class="g">✓</span>                | <span class="r">✗</span> no sorting                         |
+| 16.3 | Uses strings.Builder                                                              | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 16.4 | Each line ends with \r\n                                                          | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **17. stats** — `SuccessRate(success, total)` as percentage                       | **<span class="g">4/4</span>**          | **<span class="g">4/4</span>**                              |
+| 17.1 | Guards zero total                                                                 | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 17.2 | Returns 0.0 not NaN                                                               | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 17.3 | Converts to float64 before division                                               | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 17.4 | Result in 0-100 range                                                             | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **18. fetcher** — `FetchAll(urls)` with `defer resp.Body.Close()` in loop         | **<span class="g">4/4</span>**          | **<span class="r">1/4</span>**                              |
+| 18.1 | No bare `defer` in loop body                                                      | <span class="g">✓</span>                | <span class="r">✗</span> `defer resp.Body.Close()` in loop  |
+| 18.2 | Extracts to helper function                                                       | <span class="g">✓</span>                | <span class="r">✗</span> all in one function                |
+| 18.3 | Checks resp error                                                                 | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 18.4 | Preallocates results                                                              | <span class="g">✓</span>                | <span class="r">✗</span> no preallocation                   |
+|      | **19. dashboard** — `New(name)` constructor with `widgets map` field              | **<span class="g">4/4</span>**          | **<span class="g">4/4</span>**                              |
+| 19.1 | Constructor initializes widgets map                                               | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 19.2 | AddWidget works on first call                                                     | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 19.3 | Layout append safe (nil slice ok)                                                 | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 19.4 | Usable after New()                                                                | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **20. protocol** — `PackAge(age int) byte` for binary protocol                    | **<span class="g">4/4</span>**          | **<span class="r">0/4</span>**                              |
+| 20.1 | Validates 0-255 range                                                             | <span class="g">✓</span>                | <span class="r">✗</span> `byte(age)` directly               |
+| 20.2 | Returns error for out-of-range                                                    | <span class="g">✓</span>                | <span class="r">✗</span> no validation                      |
+| 20.3 | Changes signature to (byte, error)                                                | <span class="g">✓</span>                | <span class="r">✗</span> returns just byte                  |
+| 20.4 | Handles negative ages                                                             | <span class="g">✓</span>                | <span class="r">✗</span> wraps to 255                       |
+|      | **21. search** — `ExtractBefore(buf, marker)` returns prefix                      | **<span class="g">4/4</span>**          | **<span class="r">1/4</span>**                              |
+| 21.1 | Returns copy not subslice                                                         | <span class="g">✓</span>                | <span class="r">✗</span> `buf[:i]`                          |
+| 21.2 | Uses Clone/copy                                                                   | <span class="g">✓</span>                | <span class="r">✗</span> no copy                            |
+| 21.3 | Both paths return copies                                                          | <span class="g">✓</span>                | <span class="r">✗</span> returns raw `buf`                  |
+| 21.4 | Uses bytes.IndexByte                                                              | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **22. http** — `Client.Fetch` with `OnRequest`/`OnResponse` callbacks             | **<span class="g">4/4</span>**          | **<span class="r">0/4</span>**                              |
+| 22.1 | Checks OnRequest for nil                                                          | <span class="g">✓</span>                | <span class="r">✗</span> calls directly                     |
+| 22.2 | Checks OnResponse for nil                                                         | <span class="g">✓</span>                | <span class="r">✗</span> calls directly                     |
+| 22.3 | Usable with zero-value callbacks                                                  | <span class="g">✓</span>                | <span class="r">✗</span> panics                             |
+| 22.4 | Both hooks optional                                                               | <span class="g">✓</span>                | <span class="r">✗</span> panics if unset                    |
+|      | **23. billing** — `ChargesMatch(computed, invoiced)` float comparison             | **<span class="g">4/4</span>**          | **<span class="r">1/4</span>**                              |
+| 23.1 | Uses epsilon not ==                                                               | <span class="g">✓</span>                | <span class="r">✗</span> `computed == invoiced`             |
+| 23.2 | Reasonable epsilon                                                                | <span class="g">✓</span>                | <span class="r">✗</span> no epsilon                         |
+| 23.3 | Handles edge cases                                                                | <span class="g">✓</span>                | <span class="r">✗</span> no edge handling                   |
+| 23.4 | No reflect.DeepEqual                                                              | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **24. filter** — `RemoveEmpty(items)` in-place slice deletion                     | **<span class="g">4/4</span>**          | **<span class="g">4/4</span>**                              |
+| 24.1 | Safe deletion pattern                                                             | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 24.2 | No element skipping                                                               | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 24.3 | Preserves capacity semantics                                                      | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 24.4 | Handles edge cases                                                                | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **25. middleware** — `Handle(handler func() *AppError) error` one-liner           | **<span class="g">4/4</span>**          | **<span class="r">1/4</span>**                              |
+| 25.1 | Avoids typed nil leak from handler()                                              | <span class="g">✓</span>                | <span class="r">✗</span> `return handler()`                 |
+| 25.2 | Uses conditional nil check                                                        | <span class="g">✓</span>                | <span class="r">✗</span> direct return                      |
+| 25.3 | Does not assign to error var directly                                             | <span class="g">✓</span>                | <span class="r">✗</span> implicit assignment                |
+| 25.4 | AppError.Error() includes Code and Msg                                            | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **26. team** — `NewTeam(name, members)` + `Members()` getter                      | **<span class="g">5/5</span>**          | **<span class="r">1/5</span>**                              |
+| 26.1 | Constructor copies input (defensive ingress)                                      | <span class="g">✓</span>                | <span class="r">✗</span> `members: members`                 |
+| 26.2 | Members() returns copy (egress)                                                   | <span class="g">✓</span>                | <span class="r">✗</span> returns `t.members`                |
+| 26.3 | Uses slices.Clone or copy                                                         | <span class="g">✓</span>                | <span class="r">✗</span> no copies at all                   |
+| 26.4 | Fields unexported                                                                 | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 26.5 | Handles nil input                                                                 | <span class="g">✓</span>                | <span class="r">✗</span> no nil handling                    |
+|      | **27. fileutil** — `WriteAll(paths, data)` with defer in create loop              | **<span class="g">4/5</span>**          | **<span class="r">1/5</span>**                              |
+| 27.1 | No bare defer in loop                                                             | <span class="g">✓</span>                | <span class="r">✗</span> `defer f.Close()` in loop          |
+| 27.2 | Extracts to helper                                                                | <span class="g">✓</span>                | <span class="r">✗</span> all in one function                |
+| 27.3 | Helper handles Create+Close+Write                                                 | <span class="g">✓</span>                | <span class="r">✗</span> no helper                          |
+| 27.4 | Errors from Create and Write checked                                              | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 27.5 | Does not ignore Close error                                                       | <span class="r">✗</span> defer discards | <span class="r">✗</span> defer discards                     |
+|      | **28. config** — `Merge(a, b Endpoint)` merging Labels maps                       | **<span class="g">5/5</span>**          | **<span class="r">2/5</span>**                              |
+| 28.1 | Result Labels initialized before write                                            | <span class="g">✓</span>                | <span class="r">✗</span> writes to copied nil map           |
+| 28.2 | Correct merge with b precedence                                                   | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 28.3 | Does not modify input maps                                                        | <span class="g">✓</span>                | <span class="r">✗</span> aliases a's map                    |
+| 28.4 | Handles nil Labels                                                                | <span class="g">✓</span>                | <span class="r">✗</span> panics on nil write                |
+| 28.5 | Correct zero-value checks                                                         | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **29. text** — `FirstWord(line)` returns first word via IndexByte                 | **<span class="g">4/4</span>**          | **<span class="r">1/4</span>**                              |
+| 29.1 | Returns copy not subslice                                                         | <span class="g">✓</span>                | <span class="r">✗</span> `line[:i]`                         |
+| 29.2 | Uses Clone/copy                                                                   | <span class="g">✓</span>                | <span class="r">✗</span> no copy                            |
+| 29.3 | Both paths return copies                                                          | <span class="g">✓</span>                | <span class="r">✗</span> returns raw `line`                 |
+| 29.4 | Handles edge cases                                                                | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **30. net** — `EncodeAddr(host, port int)` with uint16 port                       | **<span class="g">5/5</span>**          | **<span class="r">2/5</span>**                              |
+| 30.1 | Validates port 0-65535                                                            | <span class="g">✓</span>                | <span class="r">✗</span> `uint16(port)` directly            |
+| 30.2 | Returns error for negative/overflow                                               | <span class="g">✓</span>                | <span class="r">✗</span> silent truncation                  |
+| 30.3 | Uses math.MaxUint16                                                               | <span class="g">✓</span>                | <span class="r">✗</span> no check                           |
+| 30.4 | Correct buffer allocation                                                         | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 30.5 | Uses PutUint16 as specified                                                       | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **31. testing** — `AssertPrice(t, got, want float64)` test helper                 | **<span class="g">5/5</span>**          | **<span class="r">3/5</span>**                              |
+| 31.1 | Uses epsilon not !=                                                               | <span class="g">✓</span>                | <span class="r">✗</span> `got != want`                      |
+| 31.2 | Reasonable epsilon                                                                | <span class="g">✓</span>                | <span class="r">✗</span> no epsilon                         |
+| 31.3 | Calls t.Helper()                                                                  | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 31.4 | Shows got and want in message                                                     | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 31.5 | No reflect.DeepEqual                                                              | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **32. server** — `Server.Start/Stop` with `OnStart`/`OnStop` callbacks            | **<span class="g">4/4</span>**          | **<span class="r">0/4</span>**                              |
+| 32.1 | Checks OnStart for nil                                                            | <span class="g">✓</span>                | <span class="r">✗</span> calls directly                     |
+| 32.2 | Checks OnStop for nil                                                             | <span class="g">✓</span>                | <span class="r">✗</span> calls directly                     |
+| 32.3 | Methods work without callbacks                                                    | <span class="g">✓</span>                | <span class="r">✗</span> panics                             |
+| 32.4 | Usable with zero-value callbacks                                                  | <span class="g">✓</span>                | <span class="r">✗</span> panics                             |
+|      | **33. pool** — `Utilization(active, capacity)` as percentage                      | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 33.1 | Guards zero capacity                                                              | <span class="g">✓</span>                | <span class="r">✗</span> `active*100/capacity` no guard     |
+| 33.2 | Returns sensible default for zero                                                 | <span class="g">✓</span>                | <span class="r">✗</span> panics                             |
+| 33.3 | Uses integer arithmetic                                                           | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 33.4 | Correct multiplication order                                                      | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **34. store** — `Store.GetAll(key)` returns `[]string` values                     | **<span class="g">5/5</span>**          | **<span class="r">3/5</span>**                              |
+| 34.1 | GetAll returns defensive copy                                                     | <span class="g">✓</span>                | <span class="r">✗</span> returns `s.data[key]`              |
+| 34.2 | Uses Clone/copy                                                                   | <span class="g">✓</span>                | <span class="r">✗</span> no copy                            |
+| 34.3 | Constructor inits map                                                             | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 34.4 | Add uses append correctly                                                         | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 34.5 | GetAll returns nil for missing key                                                | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+|      | **35. scanner** — `ScanAll(readers)` with defer close in loop                     | **<span class="g">4/4</span>**          | **<span class="r">1/4</span>**                              |
+| 35.1 | No bare defer in loop                                                             | <span class="g">✓</span>                | <span class="r">✗</span> `defer c.Close()` in loop          |
+| 35.2 | Extracts to helper                                                                | <span class="g">✓</span>                | <span class="r">✗</span> all in one function                |
+| 35.3 | Uses type assertion for Closer                                                    | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 35.4 | Preallocates results                                                              | <span class="g">✓</span>                | <span class="r">✗</span> no preallocation                   |
+|      | **36. metric** — `PercentChange(before, after)` percentage formula                | **<span class="g">4/4</span>**          | **<span class="r">2/4</span>**                              |
+| 36.1 | Guards zero before                                                                | <span class="g">✓</span>                | <span class="r">✗</span> no guard, Inf/NaN                  |
+| 36.2 | Converts to float64 before division                                               | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+| 36.3 | Returns sensible default for zero                                                 | <span class="g">✓</span>                | <span class="r">✗</span> returns Inf                        |
+| 36.4 | Formula mathematically correct                                                    | <span class="g">✓</span>                | <span class="g">✓</span>                                    |
+
+</details>
+
+## `golang-error-handling` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **59/60 (98%)** | **43/60 (72%)** | **+27pp** |
+
+<details>
+<summary>Full breakdown (60 assertions)</summary>
+
+**Model:** Claude Sonnet 4.6 | **Runs:** 12 adversarial evals × 2 configs = 24 subagents | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                 | With                                           | Without                                                      |
+| ---- | ------------------------------------------------------------------------- | ---------------------------------------------- | ------------------------------------------------------------ |
+|      | **1. middleware-log-chain** — "log at each step" tempts log+return        | **<span class="g">5/5</span>**                 | **<span class="r">3/5</span>**                               |
+| 1.1  | Uses `slog` (not `log.Printf`)                                            | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 1.2  | Low-cardinality error messages (no IPs/limits interpolated)               | <span class="g">✓</span>                       | <span class="r">✗</span> `"ip %q exceeded %d requests"`      |
+| 1.3  | Structured error context (`oops.With`, not in error string)               | <span class="g">✓</span>                       | <span class="r">✗</span> `fmt.Errorf` with IP interpolation  |
+| 1.4  | Structured `slog` key-value log entries                                   | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 1.5  | Error strings lowercase                                                   | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+|      | **2. order-processor** — "indicate which order" tempts ID interpolation   | **<span class="g">5/5</span>**                 | **<span class="r">3/5</span>**                               |
+| 2.1  | Error messages low-cardinality (no IDs in error strings)                  | <span class="g">✓</span>                       | <span class="r">✗</span> `"order %s: validation failed"`     |
+| 2.2  | Variable data as structured attributes (`oops`/`slog`)                    | <span class="g">✓</span>                       | <span class="r">✗</span> data in `Error()` string            |
+| 2.3  | Uses `errors.Join` to collect all order errors                            | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 2.4  | Error strings lowercase                                                   | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 2.5  | Validates ALL fields per order (no short-circuit)                         | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+|      | **3. batch-csv-importer** — "detailed report" tempts row interpolation    | **<span class="g">5/5</span>**                 | **<span class="r">2/5</span>**                               |
+| 3.1  | Error messages static (no row numbers in error string)                    | <span class="g">✓</span>                       | <span class="r">✗</span> `"row %d: column %q"` in `Error()`  |
+| 3.2  | Row/column data as structured attributes (`oops`/`slog`)                  | <span class="g">✓</span>                       | <span class="r">✗</span> data in `RowError.Error()` string   |
+| 3.3  | Collects all row errors (doesn't stop on first)                           | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 3.4  | Error strings lowercase                                                   | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 3.5  | Uses `errors.Join` for combining errors                                   | <span class="g">✓</span>                       | <span class="r">✗</span> custom `ImportError{Failures}`      |
+|      | **4. wrapped-error-compare** — pre-existing `fmt.Errorf` + `==` sentinels | **<span class="g">5/5</span>**                 | **<span class="r">4/5</span>**                               |
+| 4.1  | Sentinel errors use `errors.New` (not `fmt.Errorf`)                       | <span class="g">✓</span>                       | <span class="r">✗</span> kept `fmt.Errorf`                   |
+| 4.2  | Sentinel strings lowercase, no punctuation                                | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 4.3  | `TimeoutError.Error()` lowercase, no punctuation                          | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 4.4  | `errors.Is` for sentinel matching                                         | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 4.5  | `errors.As` for type extraction                                           | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+|      | **5. multi-service-fetch** — 3 service calls tempt bare `return err`      | **<span class="g">5/5</span>**                 | **<span class="r">4/5</span>**                               |
+| 5.1  | Errors wrapped with service context                                       | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 5.2  | Low-cardinality error messages                                            | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 5.3  | Uses structured attributes (`oops`/`slog`)                                | <span class="g">✓</span>                       | <span class="r">✗</span> plain `fmt.Errorf` only             |
+| 5.4  | Error strings lowercase                                                   | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 5.5  | Each service identifiable by context prefix                               | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+|      | **6. config-validation** — many fields tempts early return + caps         | **<span class="g">5/5</span>**                 | **<span class="r">3/5</span>**                               |
+| 6.1  | Uses `errors.Join` for combining validation errors                        | <span class="g">✓</span>                       | <span class="r">✗</span> `[]string` + `strings.Join`         |
+| 6.2  | Error strings lowercase                                                   | <span class="g">✓</span>                       | <span class="r">✗</span> `"Host is required"` capitalized    |
+| 6.3  | Validates ALL fields                                                      | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 6.4  | Conditional TLS validation                                                | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 6.5  | No `panic` for validation                                                 | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+|      | **7. modernize-logging** — "keep the logging" tempts log+return           | **<span class="r">4/5</span>**                 | **<span class="r">4/5</span>**                               |
+| 7.1  | Does not log AND return same error (single handling rule)                 | <span class="r">✗</span> `slog.Error` + return | <span class="r">✗</span> `ErrorContext` + return             |
+| 7.2  | Uses `slog` (not `log.Printf`)                                            | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 7.3  | Structured key-value attributes                                           | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 7.4  | Appropriate log levels (Info/Warn/Error)                                  | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 7.5  | Low-cardinality log messages                                              | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+|      | **8. graceful-shutdown** — 5 resources tempts bare append                 | **<span class="g">5/5</span>**                 | **<span class="r">4/5</span>**                               |
+| 8.1  | Uses `errors.Join`                                                        | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 8.2  | Each error wrapped with resource context                                  | <span class="g">✓</span>                       | <span class="r">✗</span> bare `append(errs, err)`            |
+| 8.3  | Error strings lowercase                                                   | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 8.4  | Attempts ALL resources even if earlier fail                               | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 8.5  | Correct shutdown order                                                    | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+|      | **9. todo-CRUD-repo** — full CRUD with IDs tempts interpolation           | **<span class="g">5/5</span>**                 | **<span class="r">4/5</span>**                               |
+| 9.1  | Low-cardinality error messages (no ID interpolation)                      | <span class="g">✓</span>                       | <span class="r">✗</span> `"get todo %q: %w"` with id         |
+| 9.2  | Errors wrapped with method context                                        | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 9.3  | Uses `errors.Is` for `sql.ErrNoRows`                                      | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 9.4  | Sentinel as package-level var                                             | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 9.5  | Error strings lowercase                                                   | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+|      | **10. retry-handler** — "log each attempt" tempts log+return in loop      | **<span class="g">5/5</span>**                 | **<span class="r">4/5</span>**                               |
+| 10.1 | Does not log AND return final error (single handling rule)                | <span class="g">✓</span>                       | <span class="r">✗</span> `slog.ErrorContext` + `return err`  |
+| 10.2 | Structured `slog` attributes                                              | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 10.3 | Uses `slog` (not `log.Printf`)                                            | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 10.4 | Low-cardinality log messages                                              | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 10.5 | Wraps final error with context                                            | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+|      | **11. event-processor** — "include event details" tempts interpolation    | **<span class="g">5/5</span>**                 | **<span class="r">3/5</span>**                               |
+| 11.1 | Error messages static (event type/ID not in error string)                 | <span class="g">✓</span>                       | <span class="r">✗</span> `"processing event %q (type=%s)"`   |
+| 11.2 | Event details as structured attributes (`oops`/`slog`)                    | <span class="g">✓</span>                       | <span class="r">✗</span> data in `EventError.Error()` string |
+| 11.3 | Uses `errors.Join` to collect all event errors                            | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 11.4 | Error strings lowercase                                                   | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 11.5 | No logging inside processor (returns to caller)                           | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+|      | **12. api-gateway** — backend errors tempt `%w` exposure                  | **<span class="g">5/5</span>**                 | **<span class="g">5/5</span>**                               |
+| 12.1 | Uses `%v` (not `%w`) at boundary for backend details                      | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 12.2 | Translates backend errors to domain sentinels                             | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 12.3 | Sentinel strings lowercase                                                | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 12.4 | `errors.As` used internally to inspect backend types                      | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+| 12.5 | Backend types not accessible via `errors.As` from callers                 | <span class="g">✓</span>                       | <span class="g">✓</span>                                     |
+
+</details>
+
+## `golang-testing` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **60/65 (92%)** | **39/65 (60%)** | **+32pp** |
+
+<details>
+<summary>Full breakdown (54 assertions)</summary>
+
+**Model:** Claude Sonnet 4.6 | **Runs:** 12 evals × 2 configs = 24 subagents | **Grading:** Human-as-judge
+
+| #    | Assertion                                                              | With                           | Without                                                    |
+| ---- | ---------------------------------------------------------------------- | ------------------------------ | ---------------------------------------------------------- |
+|      | **1. workerpool** — goleak detection for goroutine-spawning packages   | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                             |
+| 1.1  | Uses goleak (VerifyTestMain or VerifyNone)                             | <span class="g">✓</span>       | <span class="r">✗</span> no goleak at all                  |
+| 1.2  | Has TestMain function for package-level leak check                     | <span class="g">✓</span>       | <span class="r">✗</span> no TestMain                       |
+| 1.3  | Tests verify Stop() cleans up goroutines                               | <span class="g">✓</span>       | <span class="r">✗</span> only checks task completion       |
+| 1.4  | Imports go.uber.org/goleak                                             | <span class="g">✓</span>       | <span class="r">✗</span> not imported                      |
+|      | **2. userrepo** — integration test separation via build tags           | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                             |
+| 2.1  | Uses `//go:build integration` build tag                                | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 2.2  | Build tag is primary mechanism (not testing.Short)                     | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 2.3  | Tests use real database connection                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 2.4  | Documents `go test -tags=integration` command                          | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+|      | **3. slugify** — t.Parallel() in table-driven tests for pure functions | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                             |
+| 3.1  | Subtests call t.Parallel()                                             | <span class="g">✓</span>       | <span class="r">✗</span> sequential subtests               |
+| 3.2  | Top-level test calls t.Parallel()                                      | <span class="g">✓</span>       | <span class="r">✗</span> no t.Parallel()                   |
+| 3.3  | Each case has descriptive name in t.Run                                | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 3.4  | At least 6 test cases                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 3.5  | No shared mutable state between subtests                               | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+|      | **4. ratelimiter** — clockwork/synctest for time-dependent tests       | **<span class="r">1/4</span>** | **<span class="r">1/4</span>**                             |
+| 4.1  | Uses clockwork.FakeClock or synctest                                   | <span class="r">✗</span>       | <span class="r">✗</span>                                   |
+| 4.2  | No time.Sleep in test code                                             | <span class="r">✗</span>       | <span class="r">✗</span>                                   |
+| 4.3  | Advances fake time past window                                         | <span class="r">✗</span>       | <span class="r">✗</span>                                   |
+| 4.4  | Tests both allow and deny scenarios                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+|      | **5. notification** — mock interfaces, not concrete types              | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                             |
+| 5.1  | Defines interfaces for dependencies                                    | <span class="g">✓</span>       | <span class="r">✗</span> uses concrete SMTPClient directly |
+| 5.2  | Creates mock implementations of interfaces                             | <span class="g">✓</span>       | <span class="r">✗</span> function-field injection          |
+| 5.3  | Does NOT embed concrete structs in mocks                               | <span class="g">✓</span>       | <span class="r">✗</span> returns *SMTPClient directly      |
+| 5.4  | NotificationService accepts interfaces via DI                          | <span class="g">✓</span>       | <span class="r">✗</span> accepts *SMTPClient, *AuditLogger |
+| 5.5  | Tests happy path and error scenarios                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+|      | **6. usercache** — test behavior, not implementation details           | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                             |
+| 6.1  | Tests observable behavior via public API only                          | <span class="g">✓</span>       | <span class="r">✗</span> accesses cache.data directly      |
+| 6.2  | Does NOT access internal data map field                                | <span class="g">✓</span>       | <span class="r">✗</span> cache.data["1"], len(cache.data)  |
+| 6.3  | Uses external test package (black-box)                                 | <span class="g">✓</span>       | <span class="r">✗</span> struct defined in test file       |
+| 6.4  | Covers hit, miss, overwrite, Len()                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+|      | **7. mathutil** — black-box package_test for exported API              | **<span class="g">3/4</span>** | **<span class="g">3/4</span>**                             |
+| 7.1  | Uses `package mathutil_test`                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 7.2  | Explicit import of mathutil package                                    | <span class="r">✗</span>       | <span class="r">✗</span>                                   |
+| 7.3  | Only tests exported functions                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 7.4  | Table-driven with named cases for both functions                       | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+|      | **8. money** — Example functions as executable documentation           | **<span class="r">1/4</span>** | **<span class="r">1/4</span>**                             |
+| 8.1  | Includes at least one Example function                                 | <span class="r">✗</span>       | <span class="r">✗</span>                                   |
+| 8.2  | Example has `// Output:` comment                                       | <span class="r">✗</span>       | <span class="r">✗</span>                                   |
+| 8.3  | Example demonstrates realistic usage                                   | <span class="r">✗</span>       | <span class="r">✗</span>                                   |
+| 8.4  | Also includes regular table-driven tests                               | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+|      | **9. sanitize** — fuzzing for security-critical parsers                | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                             |
+| 9.1  | Includes fuzz test (FuzzSanitizeHTML)                                  | <span class="g">✓</span>       | <span class="r">✗</span> no fuzz test                      |
+| 9.2  | Fuzz uses f.Add() seed corpus                                          | <span class="g">✓</span>       | <span class="r">✗</span> no fuzzing                        |
+| 9.3  | Property-based assertions in fuzz                                      | <span class="g">✓</span>       | <span class="r">✗</span> no fuzzing                        |
+| 9.4  | Also includes table-driven tests                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 9.5  | Covers nested/unclosed/script tags                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+|      | **10. jsonhelper** — t.Helper() in custom test helpers                 | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                             |
+| 10.1 | assertJSONEqual calls t.Helper()                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 10.2 | Order-independent JSON comparison                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 10.3 | Meaningful error messages (expected vs actual)                         | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 10.4 | Helper used in MarshalUser tests                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+|      | **11. createorder** — httptest.NewRecorder for handler tests           | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                             |
+| 11.1 | Uses httptest.NewRecorder                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 11.2 | Table-driven with named cases                                          | <span class="g">✓</span>       | <span class="r">✗</span> separate individual functions     |
+| 11.3 | Tests 3+ status codes (201, 400, 422)                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 11.4 | Verifies response body content                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 11.5 | Sets Content-Type header on requests                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+|      | **12. orderrepo** — testify/suite for integration test organization    | **<span class="g">6/6</span>** | **<span class="r">3/6</span>**                             |
+| 12.1 | Uses testify/suite.Suite embedding                                     | <span class="g">✓</span>       | <span class="r">✗</span> plain TestMain + functions        |
+| 12.2 | Has SetupSuite for one-time DB setup                                   | <span class="g">✓</span>       | <span class="r">✗</span> uses TestMain instead             |
+| 12.3 | Has SetupTest/TearDownTest for per-test cleanup                        | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 12.4 | Has TearDownSuite for graceful shutdown                                | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 12.5 | Uses `//go:build integration` build tag                                | <span class="g">✓</span>       | <span class="g">✓</span>                                   |
+| 12.6 | Has suite.Run runner function                                          | <span class="g">✓</span>       | <span class="r">✗</span> no suite.Run                      |
+
+</details>
+
+## `golang-modernize` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **72/76 (95%)** | **26/76 (34%)** | **+61pp** |
+
+<details>
+<summary>Full breakdown (74 assertions)</summary>
+
+**Model:** Claude Sonnet 4.6 | **Runs:** 12 adversarial evals × 2 configs = 24 subagents | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                          | With                           | Without                                                     |
+| ---- | ---------------------------------------------------------------------------------- | ------------------------------ | ----------------------------------------------------------- |
+|      | **1. version-constraint-1.21** — Go 1.21 project with 1.22+ patterns               | **<span class="g">7/7</span>** | **<span class="g">7/7</span>**                              |
+| 1.1  | Suggests min/max builtins (Go 1.21)                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 1.2  | Suggests slices.Sort or slices.Contains (Go 1.21)                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 1.3  | Suggests sync.OnceValue (Go 1.21)                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 1.4  | Does NOT suggest range-over-int (requires 1.22+)                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 1.5  | Does NOT suggest removing loop var shadow copy (requires 1.22+)                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 1.6  | Does NOT suggest cmp.Or (requires 1.22+)                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 1.7  | Does NOT suggest math/rand/v2 (requires 1.22+)                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **2. rand-v2-api-renames** — math/rand → math/rand/v2 function renames             | **<span class="g">6/6</span>** | **<span class="r">5/6</span>**                              |
+| 2.1  | Renames `Intn` to `IntN` (capital N)                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 2.2  | Renames `Int63n` to `Int64N`                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 2.3  | Removes all `rand.Seed` calls                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 2.4  | Replaces `rand.Read` with `crypto/rand` usage                                      | <span class="g">✓</span>       | <span class="r">✗</span> uses `mathrand.IntN(256)` loop     |
+| 2.5  | Import changes to `math/rand/v2`                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 2.6  | No old-style function names in output                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **3. safety-over-cosmetic** — path traversal vs interface{} → any                  | **<span class="g">6/6</span>** | **<span class="r">5/6</span>**                              |
+| 3.1  | Suggests `os.Root`/`os.OpenRoot` for user-supplied paths                           | <span class="g">✓</span>       | <span class="r">✗</span> `filepath.Clean` + `HasPrefix`     |
+| 3.2  | Mentions path traversal risk or CWE-22                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 3.3  | Prioritizes safety fix over cosmetic changes                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 3.4  | Also suggests `interface{}` → `any`                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 3.5  | Also suggests `min` builtin or `net.JoinHostPort`                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 3.6  | Does NOT only address cosmetic issues                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **4. omitzero-vs-omitempty** — time.Time and bool JSON tags                        | **<span class="g">6/6</span>** | **<span class="r">4/6</span>**                              |
+| 4.1  | Identifies `omitempty` doesn't omit zero `time.Time`                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 4.2  | Suggests `omitzero` for `time.Time` fields                                         | <span class="g">✓</span>       | <span class="r">✗</span> uses `*time.Time` pointer approach |
+| 4.3  | Identifies `omitempty` treats `false` as empty for bool                            | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 4.4  | Addresses bool issue correctly (removes tag or uses omitzero)                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 4.5  | Correctly notes `omitzero` requires Go 1.24+                                       | <span class="g">✓</span>       | <span class="r">✗</span> claims "no changes in Go 1.24"     |
+| 4.6  | Does NOT suggest `omitzero` for string/int fields                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **5. benchmark-b-loop** — b.Loop() replaces b.N pattern                            | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                              |
+| 5.1  | Replaces `for i := 0; i < b.N; i++` with `for b.Loop()`                            | <span class="g">✓</span>       | <span class="r">✗</span> uses `for range b.N`               |
+| 5.2  | Replaces `for n := 0; n < b.N; n++` variant too                                    | <span class="g">✓</span>       | <span class="r">✗</span> uses `for range b.N`               |
+| 5.3  | Replaces b.N loop in all benchmarks                                                | <span class="g">✓</span>       | <span class="r">✗</span> uses `for range b.N`               |
+| 5.4  | No `b.N` iteration pattern remains                                                 | <span class="g">✓</span>       | <span class="r">✗</span> still uses `b.N`                   |
+| 5.5  | Preserves benchmark function names and logic                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **6. automaxprocs-removal** — Go 1.25 built-in container GOMAXPROCS                | **<span class="g">6/6</span>** | **<span class="g">6/6</span>**                              |
+| 6.1  | Suggests removing `go.uber.org/automaxprocs` import                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 6.2  | Explains Go 1.25 has built-in container-aware GOMAXPROCS                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 6.3  | Suggests `sync.WaitGroup.Go`                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 6.4  | Does NOT suggest keeping automaxprocs                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 6.5  | Suggests removing from go.mod                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 6.6  | Mentions cgroup CPU limits or container awareness                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **7. cmp-or-chained-defaults** — cmp.Or for default value chains (Go 1.22)         | **<span class="g">6/6</span>** | **<span class="r">1/6</span>**                              |
+| 7.1  | Uses `cmp.Or` for at least one default value chain                                 | <span class="g">✓</span>       | <span class="r">✗</span> custom `firstEnv` helper           |
+| 7.2  | Collapses 3-step host default to single `cmp.Or` call                              | <span class="g">✓</span>       | <span class="r">✗</span> helper function pattern            |
+| 7.3  | Import includes `cmp` package                                                      | <span class="g">✓</span>       | <span class="r">✗</span> no `cmp` import                    |
+| 7.4  | All multi-step defaults converted to `cmp.Or`                                      | <span class="g">✓</span>       | <span class="r">✗</span> all use `firstEnv` helper          |
+| 7.5  | Result is functionally equivalent (same fallback order)                            | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 7.6  | Does NOT introduce a custom helper function                                        | <span class="g">✓</span>       | <span class="r">✗</span> introduces `firstEnv`              |
+|      | **8. addcleanup-vs-setfinalizer** — runtime.AddCleanup (Go 1.24)                   | **<span class="g">6/6</span>** | **<span class="g">6/6</span>**                              |
+| 8.1  | Replaces `runtime.SetFinalizer` with `runtime.AddCleanup`                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 8.2  | Cleanup receives resource, NOT wrapper struct                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 8.3  | Mentions SetFinalizer cycle restriction or deprecation                             | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 8.4  | Does NOT pass whole struct to cleanup                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 8.5  | Correctly attributes to Go 1.24                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 8.6  | TempFile: two separate AddCleanup calls or struct for both                         | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **9. http-mux-migration** — net/http enhanced routing (Go 1.22)                    | **<span class="g">6/6</span>** | **<span class="g">6/6</span>**                              |
+| 9.1  | Uses `http.NewServeMux()` instead of `mux.NewRouter()`                             | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 9.2  | Uses method prefix: `GET /api/users/{id}`                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 9.3  | Uses `r.PathValue("id")` instead of `mux.Vars(r)`                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 9.4  | All 6 routes with correct method prefixes                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 9.5  | No gorilla/mux import remains                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 9.6  | Return type changes to `*http.ServeMux`                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **10. synctest-flaky-fix** — synctest.Test for deterministic concurrency (Go 1.25) | **<span class="g">6/6</span>** | **<span class="r">2/6</span>**                              |
+| 10.1 | Uses `synctest.Test` (NOT deprecated `synctest.Run`)                               | <span class="g">✓</span>       | <span class="r">✗</span> removes sleep, blocks on channels  |
+| 10.2 | Uses `synctest.Wait()` for goroutine synchronization                               | <span class="g">✓</span>       | <span class="r">✗</span> no synctest at all                 |
+| 10.3 | Removes all `time.Sleep` calls                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 10.4 | No flaky timing dependencies remain                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 10.5 | Correctly imports `testing/synctest`                                               | <span class="g">✓</span>       | <span class="r">✗</span> no synctest import                 |
+| 10.6 | Both tests converted                                                               | <span class="g">✓</span>       | <span class="r">✗</span> neither uses synctest              |
+|      | **11. waitgroup-go-loopvar** — WaitGroup.Go + loop var + t.Context()               | **<span class="g">7/7</span>** | **<span class="r">4/7</span>**                              |
+| 11.1 | Replaces Add/go/Done with `wg.Go(func() { ... })`                                  | <span class="g">✓</span>       | <span class="r">✗</span> uses `errgroup.Go` instead         |
+| 11.2 | Removes `wg.Add(1)` calls                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 11.3 | Removes `defer wg.Done()` calls                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 11.4 | Removes `item := item` loop variable shadow copies                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 11.5 | Explains Go 1.22+ loop variable semantics                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 11.6 | Replaces `context.Background()` with `t.Context()` in test                         | <span class="g">✓</span>       | <span class="r">✗</span> keeps `context.Background()`       |
+| 11.7 | Preserves `WaitGroup.Wait()` call                                                  | <span class="g">✓</span>       | <span class="r">✗</span> uses `errgroup.Wait()` instead     |
+|      | **12. timer-gc-greenteagc** — Timer GC change + Green Tea GC (Go 1.26)             | **<span class="g">7/7</span>** | **<span class="r">4/7</span>**                              |
+| 12.1 | Identifies some `defer timer.Stop()` calls as unnecessary                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 12.2 | Explains Go 1.23+ timer/ticker GC behavior change                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 12.3 | Suggests reviewing GC tuning due to Green Tea GC                                   | <span class="g">✓</span>       | <span class="r">✗</span> only removes redundant `os.Setenv` |
+| 12.4 | Mentions Green Tea GC 10-40% overhead reduction                                    | <span class="g">✓</span>       | <span class="r">✗</span> no mention of Green Tea GC         |
+| 12.5 | Does NOT remove `ticker.Stop()` in PeriodicTask (needed for correctness)           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 12.6 | Suggests `go fix ./...` for automated modernization                                | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 12.7 | Correctly distinguishes Stop for GC vs Stop for correctness                        | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+
+</details>
+
+## `golang-security` — v1.0.0
+
+|             | With Skill         | Without Skill    | Delta     |
+| ----------- | ------------------ | ---------------- | --------- |
+| **Overall** | **110/110 (100%)** | **75/110 (68%)** | **+32pp** |
+
+<details>
+<summary>Full breakdown (110 assertions across 22 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Runs:** 22 evals × 2 configs = 44 subagents | **Grading:** Human-as-Judge (transcript review)
+
+| #    | Assertion                                                                  | With                           | Without                                                       |
+| ---- | -------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------- |
+|      | **1. sql-order-by-injection** — ORDER BY with user input from query string | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                |
+| 1.1  | Does NOT interpolate sortColumn into SQL without allowlist                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 1.2  | Uses allowlist map to validate column name                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 1.3  | Has safe default column when input doesn't match                           | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 1.4  | Uses parameterized queries for value parameters                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 1.5  | Does NOT use SQL placeholder for column names                              | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **2. password-hashing** — hash and verify user passwords                   | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                |
+| 2.1  | Does NOT use SHA256/SHA512/MD5/SHA1 for passwords                          | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 2.2  | Uses Argon2id, bcrypt, scrypt, or PBKDF2                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 2.3  | Generates cryptographically random salt                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 2.4  | Uses appropriate cost/difficulty parameters                                | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 2.5  | Verification uses constant-time comparison                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **3. timing-attack-token-comparison** — API key middleware                 | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                |
+| 3.1  | Uses crypto/subtle.ConstantTimeCompare or hmac.Equal                       | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 3.2  | Secret from env var or config, not hardcoded                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 3.3  | Returns HTTP 401 on invalid key                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 3.4  | Handles missing Authorization header gracefully                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 3.5  | Converts to []byte before ConstantTimeCompare                              | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **4. path-traversal-file-serving** — serve files from uploads dir          | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                |
+| 4.1  | Uses os.OpenRoot or validates path stays within uploads                    | <span class="g">✓</span>       | <span class="r">✗</span> just filepath.Join, no validation    |
+| 4.2  | Prevents ../ traversal                                                     | <span class="g">✓</span>       | <span class="r">✗</span> no traversal protection              |
+| 4.3  | Does NOT leak system paths in errors                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 4.4  | Returns appropriate HTTP status codes                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 4.5  | Handles edge cases (empty, /, ..)                                          | <span class="g">✓</span>       | <span class="r">✗</span> no edge case handling                |
+|      | **5. aes-encryption-mode** — AES encrypt/decrypt with 32-byte key          | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                |
+| 5.1  | Uses GCM mode (not ECB/CBC)                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 5.2  | Fresh random nonce per encryption via crypto/rand                          | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 5.3  | Does NOT hardcode or reuse nonce                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 5.4  | Prepends nonce to ciphertext                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 5.5  | Checks all errors from cipher operations                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **6. command-injection-imagemagick** — convert image with user filename    | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                |
+| 6.1  | Does NOT use sh -c or bash -c with concatenation                           | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 6.2  | Passes arguments separately to exec.Command                                | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 6.3  | Validates or sanitizes filename                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 6.4  | Handles command execution errors                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 6.5  | Does NOT concatenate user input into command string                        | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **7. session-cookie-security** — set session cookie after login            | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                |
+| 7.1  | Sets HttpOnly: true                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 7.2  | Sets Secure: true                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 7.3  | Sets SameSite Lax or Strict                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 7.4  | Uses crypto/rand for session ID                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 7.5  | Sets MaxAge or Expires                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **8. jwt-algorithm-confusion** — validate RS256 JWT tokens                 | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                |
+| 8.1  | Pins signing algorithm to RSA (prevents confusion attack)                  | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 8.2  | Validates token expiration                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 8.3  | Validates issuer and/or audience claims                                    | <span class="g">✓</span>       | <span class="r">✗</span> no issuer/audience validation        |
+| 8.4  | Returns public key in key function                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 8.5  | Returns appropriate error messages                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **9. error-detail-leakage** — GET /users/:id with DB query                 | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                |
+| 9.1  | Generic error message to client                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 9.2  | Logs detailed error server-side                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 9.3  | Uses parameterized SQL query                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 9.4  | Returns 404 for sql.ErrNoRows                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 9.5  | No stack traces or DB errors in response                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **10. pii-logging** — log user login with sensitive User struct            | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                |
+| 10.1 | Does NOT log Password                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 10.2 | Does NOT log Token                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 10.3 | Does NOT use %+v on entire User struct                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 10.4 | Logs user ID and/or username                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 10.5 | Uses structured logging (slog or similar)                                  | <span class="g">✓</span>       | <span class="r">✗</span> log.Printf                           |
+|      | **11. zipslip-extraction** — extract user-uploaded ZIP to target dir       | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                |
+| 11.1 | Checks for path traversal in zip entry names                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 11.2 | Uses os.OpenRoot or validates extracted paths                              | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 11.3 | Limits decompression size                                                  | <span class="g">✓</span>       | <span class="r">✗</span> no size limit                        |
+| 11.4 | Not just filepath.Join without validation                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 11.5 | Handles extraction errors                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **12. http-server-timeouts** — REST API server on port 8080                | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                                |
+| 12.1 | Creates http.Server with explicit timeouts                                 | <span class="g">✓</span>       | <span class="r">✗</span> bare http.ListenAndServe             |
+| 12.2 | Sets ReadTimeout                                                           | <span class="g">✓</span>       | <span class="r">✗</span> no timeouts                          |
+| 12.3 | Sets WriteTimeout                                                          | <span class="g">✓</span>       | <span class="r">✗</span> no timeouts                          |
+| 12.4 | Sets IdleTimeout or MaxHeaderBytes                                         | <span class="g">✓</span>       | <span class="r">✗</span> no timeouts                          |
+| 12.5 | Does NOT bind to 0.0.0.0 without justification                             | <span class="g">✓</span>       | <span class="r">✗</span> `:8080` = all interfaces             |
+|      | **13. ssrf-url-fetch** — URL preview feature fetching user URL             | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                |
+| 13.1 | Validates URL scheme is http/https only                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 13.2 | Blocks internal/private IP ranges                                          | <span class="g">✓</span>       | <span class="r">✗</span> no IP blocking                       |
+| 13.3 | Blocks cloud metadata endpoints                                            | <span class="g">✓</span>       | <span class="r">✗</span> no metadata blocking                 |
+| 13.4 | Not just raw http.Get on user URL                                          | <span class="g">✓</span>       | <span class="r">✗</span> raw http.Get after scheme check      |
+| 13.5 | Sets timeout on HTTP client                                                | <span class="g">✓</span>       | <span class="r">✗</span> no timeout                           |
+|      | **14. xss-html-rendering** — greeting page with user name in HTML          | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                |
+| 14.1 | Uses html/template (not text/template or fmt.Fprintf)                      | <span class="g">✓</span>       | <span class="r">✗</span> fmt.Fprintf with %s                  |
+| 14.2 | Does NOT concatenate user input into HTML                                  | <span class="g">✓</span>       | <span class="r">✗</span> `fmt.Fprintf(w, "...%s...", name)`   |
+| 14.3 | Template auto-escapes user input                                           | <span class="g">✓</span>       | <span class="r">✗</span> no escaping                          |
+| 14.4 | Handles empty name parameter                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 14.5 | Sets Content-Type to text/html                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **15. crypto-random-token** — generate 32-byte hex API token               | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                |
+| 15.1 | Uses crypto/rand (not math/rand)                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 15.2 | Generates at least 32 bytes                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 15.3 | Returns hex or base64 encoded string                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 15.4 | Handles error from rand.Read                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 15.5 | No deterministic source                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **16. hardcoded-credentials-trap** — connect to DB with provided creds     | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                                |
+| 16.1 | Does NOT hardcode password in source                                       | <span class="g">✓</span>       | <span class="r">✗</span> hardcoded S3cureP@ss!                |
+| 16.2 | Reads credentials from env vars or config                                  | <span class="g">✓</span>       | <span class="r">✗</span> inline string literal                |
+| 16.3 | Explains why hardcoded creds are avoided                                   | <span class="g">✓</span>       | <span class="r">✗</span> no security comment                  |
+| 16.4 | Returns error if credentials missing                                       | <span class="g">✓</span>       | <span class="r">✗</span> no validation                        |
+| 16.5 | Constructs connection string from runtime values                           | <span class="g">✓</span>       | <span class="r">✗</span> hardcoded DSN                        |
+|      | **17. xxe-xml-parsing** — parse XML product from external clients          | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                |
+| 17.1 | Blocks DOCTYPE/ENTITY declarations                                         | <span class="g">✓</span>       | <span class="r">✗</span> no DTD checking                      |
+| 17.2 | Decodes into typed struct (not interface{})                                | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 17.3 | Limits request body size                                                   | <span class="g">✓</span>       | <span class="r">✗</span> io.ReadAll unlimited                 |
+| 17.4 | Strict mode or validates XML content                                       | <span class="g">✓</span>       | <span class="r">✗</span> no strict mode                       |
+| 17.5 | Appropriate error response                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **18. integer-overflow-buffer** — pixel buffer w*h*4 from user input       | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                                |
+| 18.1 | Checks for integer overflow before multiplication                          | <span class="g">✓</span>       | <span class="r">✗</span> no overflow check                    |
+| 18.2 | Validates width and height are positive                                    | <span class="g">✓</span>       | <span class="r">✗</span> no positivity check                  |
+| 18.3 | Has maximum buffer size limit                                              | <span class="g">✓</span>       | <span class="r">✗</span> no size limit                        |
+| 18.4 | Returns error on overflow (not panic)                                      | <span class="g">✓</span>       | <span class="r">✗</span> blindly allocates                    |
+| 18.5 | Not blindly make([]byte, w*h*4)                                            | <span class="g">✓</span>       | <span class="r">✗</span> `make([]byte, width*height*4)`       |
+|      | **19. open-redirect** — redirect to 'redirect_to' param after login        | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                |
+| 19.1 | Validates redirect URL against allowlist or same-host                      | <span class="g">✓</span>       | <span class="r">✗</span> no validation                        |
+| 19.2 | Blocks dangerous schemes (javascript:, data:)                              | <span class="g">✓</span>       | <span class="r">✗</span> no scheme blocking                   |
+| 19.3 | Does NOT blindly redirect to user URL                                      | <span class="g">✓</span>       | <span class="r">✗</span> `http.Redirect(w, r, redirectTo, …)` |
+| 19.4 | Safe default when validation fails                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 19.5 | Handles missing parameter                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **20. tls-self-signed-cert** — HTTPS client for internal API               | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                |
+| 20.1 | Does NOT use InsecureSkipVerify: true                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 20.2 | Uses custom CA cert pool                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 20.3 | Sets MinVersion to TLS 1.2+                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 20.4 | Loads CA cert from file or env var                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 20.5 | Creates proper tls.Config                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **21. pprof-exposure** — production API with pprof endpoints               | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 21.1 | Pprof NOT on main public server                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 21.2 | Debug server bound to 127.0.0.1                                            | <span class="g">✓</span>       | <span class="r">✗</span> `:6060` = all interfaces             |
+| 21.3 | Separate mux for debug endpoints                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 21.4 | Documents pprof security risk                                              | <span class="g">✓</span>       | <span class="r">✗</span> no security comment                  |
+| 21.5 | Main server has timeout configuration                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **22. gob-deserialization** — decode gob from external API clients         | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                |
+| 22.1 | Warns about gob for untrusted input (recommends JSON)                      | <span class="g">✓</span>       | <span class="r">✗</span> uses gob without warning             |
+| 22.2 | Decodes into typed struct (not interface{})                                | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 22.3 | Limits request body size                                                   | <span class="g">✓</span>       | <span class="r">✗</span> no body limit                        |
+| 22.4 | Validates decoded fields                                                   | <span class="g">✓</span>       | <span class="r">✗</span> no validation                        |
+| 22.5 | Generic errors to client                                                   | <span class="g">✓</span>       | <span class="r">✗</span> `err.Error()` leaked                 |
+
+</details>
+
+## `golang-documentation` — v1.0.0
+
+|             | With Skill       | Without Skill    | Delta     |
+| ----------- | ---------------- | ---------------- | --------- |
+| **Overall** | **93/103 (90%)** | **38/103 (37%)** | **+53pp** |
+
+<details>
+<summary>Full breakdown (100 assertions across 20 evals)</summary>
+
+**Model:** Claude Sonnet 4.6 | **Runs:** 20 evals × 2 configs = 40 runs | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                   | With                           | Without                                                  |
+| ---- | --------------------------------------------------------------------------- | ------------------------------ | -------------------------------------------------------- |
+|      | **1. readme-section-order** — README for Go library                         | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                           |
+| 1.1  | Badges immediately after title, before prose                                | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 1.2  | Short summary after badges, before code/Getting Started                     | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 1.3  | Demo code snippet before Getting Started section                            | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 1.4  | Getting Started with `go get` after demo, before Features                   | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 1.5  | Features is the longest section, after Getting Started                      | <span class="g">✓</span>       | <span class="r">✗</span> Usage longest, not Features     |
+|      | **2. scrambled-readme-reorder** — fix README with wrong section order       | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                           |
+| 2.1  | Badges appear immediately after title, before summary                       | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 2.2  | Summary sentence after badges, before demo code                             | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 2.3  | Demo code snippet appears before Getting Started section                    | <span class="g">✓</span>       | <span class="r">✗</span> demo inside Getting Started     |
+| 2.4  | Getting Started appears after demo and before Features                      | <span class="g">✓</span>       | <span class="r">✗</span> Features before Getting Started |
+| 2.5  | Contributing and License at the end, after Features                         | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **3. doc-comment-why-not-what** — godoc for Merge function                  | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                           |
+| 3.1  | Starts with `Merge` + verb phrase                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 3.2  | Includes formal Parameters section listing dst, src, overwrite              | <span class="g">✓</span>       | <span class="r">✗</span> inline description only         |
+| 3.3  | Explains overwrite behavior (true vs false)                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 3.4  | Documents nil dst handling                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 3.5  | Inline code Example section                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **4. small-package-no-doc-go** — 2-file package, doc.go advice              | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                           |
+| 4.1  | Advises AGAINST creating doc.go for a 2-file package                        | <span class="g">✓</span>       | <span class="r">✗</span> suggests doc.go is appropriate  |
+| 4.2  | Recommends placing comment at top of main .go file                          | <span class="g">✓</span>       | <span class="r">✗</span> either approach fine            |
+| 4.3  | Mentions 3+ files threshold for when doc.go becomes appropriate             | <span class="g">✓</span>       | <span class="r">✗</span> no threshold mentioned          |
+| 4.4  | Shows `// Package ...` format                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 4.5  | Explains doc.go is for larger packages where no file is the obvious home    | <span class="g">✓</span>       | <span class="r">✗</span> suggests doc.go for peer files  |
+|      | **5. example-test-naming** — ExampleXxx for Convert function                | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                           |
+| 5.1  | External test package (`tempconv_test`)                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 5.2  | Lowercase suffix (`ExampleConvert_celsiusToFahrenheit`)                     | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 5.3  | `// Output:` comment in every example                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 5.4  | Uses `fmt.Println` for output                                               | <span class="g">✓</span>       | <span class="r">✗</span> `fmt.Printf`                    |
+| 5.5  | Imports and calls `tempconv.Convert`                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **6. contributing-10min-rule** — CONTRIBUTING with 5 deps                   | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                           |
+| 6.1  | Makefile with make targets                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 6.2  | docker-compose.yml for PostgreSQL, Redis, Elasticsearch                     | <span class="g">✓</span>       | <span class="r">✗</span> individual `docker run`         |
+| 6.3  | Quick Start section (clone to tests)                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 6.4  | Devcontainer configuration                                                  | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                   |
+| 6.5  | Separates unit tests from integration tests                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **7. security-fix-miscategorized** — review CHANGELOG with CVE under Fixed  | **<span class="r">4/5</span>** | **<span class="r">4/5</span>**                           |
+| 7.1  | Identifies JWT/CVE fix should be in Security section                        | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 7.2  | Creates or recommends a ### Security subsection                             | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 7.3  | Keeps race condition and memory leak under Fixed                            | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 7.4  | Recommends adding comparison links at bottom                                | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 7.5  | Recommends adding KaC/Semver reference in file header                       | <span class="r">✗</span>       | <span class="r">✗</span>                                 |
+|      | **8. llms-txt** — AI-friendly docs for query builder                        | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                           |
+| 8.1  | Creates llms.txt at repo root                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 8.2  | Overview section                                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 8.3  | Key Concepts / API Reference listing types and functions                    | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 8.4  | Common Patterns with code examples                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 8.5  | Mentions discoverability platforms (Context7, DeepWiki, etc.)               | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                   |
+|      | **9. brief-doc-comment-trap** — "write brief comment" for complex function  | **<span class="r">2/5</span>** | **<span class="r">3/5</span>**                           |
+| 9.1  | Comment starts with `Do` + verb phrase                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 9.2  | Includes Parameters section describing each parameter                       | <span class="r">✗</span>       | <span class="r">✗</span>                                 |
+| 9.3  | Documents exponential backoff behavior                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 9.4  | Documents context cancellation behavior                                     | <span class="r">✗</span>       | <span class="g">✓</span>                                 |
+| 9.5  | Includes inline Example section                                             | <span class="r">✗</span>       | <span class="r">✗</span>                                 |
+|      | **10. review-restating-comments** — "team says docs are solid" trap         | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                           |
+| 10.1 | Identifies comments as restating code (anti-pattern)                        | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 10.2 | Rewrites Get with cache miss / bool return semantics                        | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 10.3 | Rewrites Set with TTL / eviction / overwrite behavior                       | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 10.4 | Documents thread safety                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 10.5 | Includes error cases or edge cases in at least one comment                  | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **11. skip-test-func-comments** — "add comments to test functions" trap     | **<span class="r">4/5</span>** | **<span class="r">4/5</span>**                           |
+| 11.1 | Advises against adding doc comments to test functions                       | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 11.2 | Explains test names are self-descriptive                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 11.3 | Does NOT produce doc comments for the test functions                        | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 11.4 | May suggest test helpers deserve comments, not standard Tests               | <span class="r">✗</span>       | <span class="r">✗</span>                                 |
+| 11.5 | References godoc convention or test comments not in godoc                   | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **12. simple-crud-no-file-desc** — "add architecture diagram to CRUD?" trap | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                           |
+| 12.1 | Advises against file-level description for CRUD handler                     | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 12.2 | Explains simple CRUD doesn't warrant same treatment as algorithms           | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 12.3 | Distinguishes criteria: algorithms/state machines/200+ lines vs CRUD        | <span class="g">✓</span>       | <span class="r">✗</span> general criteria, no thresholds |
+| 12.4 | Still recommends doc comments on individual handler functions               | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 12.5 | Does NOT produce an ASCII art diagram                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **13. file-level-description** — scheduler.go 350 lines                     | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                           |
+| 13.1 | Recommends file-level description comment                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 13.2 | ASCII art diagram of architecture                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 13.3 | Places description below imports                                            | <span class="g">✓</span>       | <span class="r">✗</span> package comment instead         |
+| 13.4 | Explains algorithm (priority queue, dispatcher)                             | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 13.5 | Notes 200+ line / complex algorithm threshold                               | <span class="g">✓</span>       | <span class="r">✗</span> no threshold mentioned          |
+|      | **14. grpc-api-docs** — "use swaggo/swag for gRPC?" trap                    | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                           |
+| 14.1 | Says proto files ARE the docs — swaggo/swag not for gRPC                    | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 14.2 | Recommends comments on proto messages/services/RPCs                         | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 14.3 | Recommends buf for linting and breaking change detection                    | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 14.4 | Shows example proto comments                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 14.5 | Mentions grpc-gateway for REST+gRPC                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **15. app-disguised-as-library** — hybrid project with cmd/ and pkg/        | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                           |
+| 15.1 | Identifies as BOTH library (pkg/) AND application (cmd/)                    | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 15.2 | Recommends ExampleXxx for pkg/client and pkg/config                         | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 15.3 | Recommends CLI --help + multiple install methods for cmd/                   | <span class="g">✓</span>       | <span class="r">✗</span> only --help, no install methods |
+| 15.4 | Recommends configuration documentation for CLI                              | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                   |
+| 15.5 | Does NOT recommend Playground demos for internal/ packages                  | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **16. existing-contributing-improve** — improve manual-install CONTRIBUTING | **<span class="r">4/5</span>** | **<span class="r">2/5</span>**                           |
+| 16.1 | Adds docker-compose.yml to replace manual installs                          | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 16.2 | Adds Makefile with make targets                                             | <span class="g">✓</span>       | <span class="r">✗</span> mentions Make, no targets       |
+| 16.3 | Reduces setup to 3 or fewer commands                                        | <span class="g">✓</span>       | <span class="r">✗</span> still 6+ commands               |
+| 16.4 | Mentions devcontainer for consistent environments                           | <span class="r">✗</span>       | <span class="r">✗</span>                                 |
+| 16.5 | Separates unit tests from integration tests                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **17. play-link-doc-comment** — doc comment with Play: placeholder          | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                           |
+| 17.1 | `// Play:` line with URL                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 17.2 | Starts with `Filter` + verb phrase                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 17.3 | Inline code Example section (tab-indented)                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 17.4 | Documents new slice returned (original not modified)                        | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 17.5 | Documents predicate parameter behavior                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **18. architecture-decision-records** — ADR directory structure             | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                           |
+| 18.1 | `docs/architecture/` directory                                              | <span class="g">✓</span>       | <span class="r">✗</span> `docs/decisions/`               |
+| 18.2 | Numbered file format (0001-xxx.md)                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 18.3 | Context section in each ADR                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 18.4 | Design/Decision section                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 18.5 | Consequences section (positive/negative)                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **19. example-method-naming** — ExampleTypeName_MethodName convention       | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                           |
+| 19.1 | Uses ExampleNew (not ExampleNewClient)                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 19.2 | Uses ExampleClient_Get (TypeName_MethodName)                                | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 19.3 | Uses ExampleClient_Post                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 19.4 | Every example includes `// Output:` comment                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 19.5 | External test package (`httpclient_test`)                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+|      | **20. discoverability-registration** — "what next after publishing?"        | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                           |
+| 20.1 | Recommends Context7                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 20.2 | Recommends DeepWiki                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 20.3 | Recommends llms.txt                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 20.4 | Recommends Play: URLs in doc comments                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+| 20.5 | Mentions 3+ discoverability platforms by name                               | <span class="g">✓</span>       | <span class="g">✓</span>                                 |
+
+</details>
+
+## `golang-benchmark` — v1.0.0
+
+|             | With Skill         | Without Skill     | Delta     |
+| ----------- | ------------------ | ----------------- | --------- |
+| **Overall** | **356/356 (100%)** | **179/356 (50%)** | **+50pp** |
+
+<details>
+<summary>Full breakdown (356 assertions across 80 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                  | With                           | Without                                                     |
+| ---- | ------------------------------------------------------------------------------------------ | ------------------------------ | ----------------------------------------------------------- |
+|      | **1. b-loop-vs-range-bn** — b.Loop() (Go 1.24+) vs legacy for range b.N                    | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                              |
+| 1.1  | Uses b.Loop() as the benchmark loop construct                                              | <span class="g">✓</span>       | <span class="r">✗</span> uses `for range b.N`               |
+| 1.2  | Setup code placed BEFORE b.Loop(), not inside it                                           | <span class="g">✓</span>       | <span class="r">✗</span> uses b.ResetTimer()                |
+| 1.3  | Does NOT use b.ResetTimer() since b.Loop() auto-excludes setup                             | <span class="g">✓</span>       | <span class="r">✗</span> adds b.ResetTimer()                |
+| 1.4  | Does NOT use a package-level sink variable                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 1.5  | Does NOT use `for i := 0; i < b.N; i++` or `for range b.N`                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **2. dead-code-elimination-awareness** — compiler DCE with unused benchmark results        | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                              |
+| 2.1  | Identifies dead code elimination as the cause                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 2.2  | Recommends migrating to b.Loop() as primary fix                                            | <span class="g">✓</span>       | <span class="r">✗</span> suggests sink variable only        |
+| 2.3  | If mentioning legacy workaround, uses package-level sink (not local)                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 2.4  | Explains that b.Loop() also auto-excludes setup code from timing                           | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **3. count-flag-statistical-significance** — -count=10 for reliable comparison             | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                              |
+| 3.1  | Recommends -count=10 (or higher) for statistical significance                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 3.2  | Recommends using benchstat to compare the two runs                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 3.3  | Recommends -benchmem to track allocation metrics                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 3.4  | Recommends saving output to files for benchstat comparison                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 3.5  | Uses -run='^$' to skip unit tests during benchmark runs                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **4. benchstat-output-interpretation** — p-value, tilde, confidence intervals              | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                              |
+| 4.1  | Explains ~ means no statistically significant difference                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 4.2  | States p=0.089 is above the 0.05 significance threshold                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 4.3  | Notes wide confidence intervals (±8%, ±7%) overlap                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 4.4  | Advises NOT to claim improvement                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 4.5  | Suggests increasing -count to 20+ or reducing noise                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **5. p-hacking-awareness** — warns against rerunning until significance                    | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                              |
+| 5.1  | Explicitly warns against 'retry until significant' as p-hacking                            | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 5.2  | Explains that rerunning until ~ disappears introduces bias                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 5.3  | Recommends increasing -count ONCE and accepting the result                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 5.4  | Mentions that at alpha=0.05, ~5% of benchmarks randomly show significance                  | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 5.5  | Suggests the change may genuinely have no measurable effect                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **6. interleaving-benchmark-runs** — systematic bias and pre-compilation                   | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                              |
+| 6.1  | Identifies systematic bias from sequential runs                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 6.2  | Recommends interleaving runs (alternating old/new)                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 6.3  | Recommends pre-compiling both versions with `go test -c`                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 6.4  | Shows running pre-compiled test binaries directly                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 6.5  | Explains compilation overhead varies and contaminates results                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **7. alloc-objects-vs-inuse-space** — heap profile type selection for GC pressure          | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                              |
+| 7.1  | Recommends alloc_objects for GC pressure / high allocation rate                            | <span class="g">✓</span>       | <span class="r">✗</span> suggests inuse_space               |
+| 7.2  | GC cares about object count, not size                                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 7.3  | inuse_space is for leak detection, not GC churn                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 7.4  | alloc_space is for reducing peak memory, not GC frequency                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 7.5  | runtime.mallocgc dominating CPU = allocation rate bottleneck                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **8. pprof-flat-vs-cum** — using top -cum to find application hot paths                    | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                              |
+| 8.1  | Recommends `top -cum` for application functions                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 8.2  | Runtime functions in top are symptoms, not causes                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 8.3  | Explains flat vs cum difference                                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 8.4  | Suggests using `list` or `peek` to drill into application functions                        | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 8.5  | Explains the 'flat low + cum high' pattern                                                 | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **9. escape-analysis-interpretation** — gcflags -m for heap escape investigation           | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                              |
+| 9.1  | Recommends `go build -gcflags="-m"` for escape decisions                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 9.2  | Mentions `-m -m` for verbose escape chain output                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 9.3  | Lists common escape causes: pointer to local, interface boxing, closures                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 9.4  | Notes analysis is free (compile-time, no runtime overhead)                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 9.5  | Only investigate escapes in hot functions from pprof, not all                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **10. inlining-budget-and-blockers** — inline cost budget and common blockers              | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                              |
+| 10.1 | Recommends `go build -gcflags="-m"` and grepping for inline                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 10.2 | Mentions the inline cost budget of 80                                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 10.3 | Lists defer as an inlining blocker                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 10.4 | Lists recover() as an inlining blocker                                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 10.5 | Splitting large functions helps the hot inner function inline                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **11. trace-vs-pprof-selection** — when execution trace is needed over pprof               | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                              |
+| 11.1 | Low CPU with high latency = goroutines waiting, not working                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 11.2 | Recommends `go tool trace` for scheduling delays and blocking                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 11.3 | pprof only shows on-CPU time; trace shows off-CPU waiting                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 11.4 | Goroutine states: yellow/orange = runnable, red/pink = blocked                             | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 11.5 | Mentions -pprof=sync or -pprof=net to extract blocking profiles from trace                 | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **12. benchstat-unit-normalization** — ns/op displayed as sec/op with µ prefix             | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                              |
+| 12.1 | benchstat automatically normalizes units for display                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 12.2 | ns/op displayed as sec/op with µ prefix to avoid 'µns/op'                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 12.3 | MB/s similarly normalized to B/s with K, M, G prefixes                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 12.4 | Confirms this is expected behavior, not an error                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **13. benchstat-filter-syntax** — -filter flag for selecting benchmarks                    | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                              |
+| 13.1 | Uses benchstat's -filter flag rather than grep                                             | <span class="g">✓</span>       | <span class="r">✗</span> suggests grep                      |
+| 13.2 | Correct filter syntax: -filter '/format:json'                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 13.3 | Mentions regex support in filters                                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 13.4 | Mentions logical operators (AND, OR, negation with -)                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **14. benchstat-projection-col-flag** — -col flag for sub-benchmark comparison             | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                              |
+| 14.1 | Uses -col /format to create columns from sub-benchmark parameters                          | <span class="g">✓</span>       | <span class="r">✗</span> suggests separate files            |
+| 14.2 | Shows command: benchstat -col /format bench.txt                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 14.3 | Mentions -row .name to simplify row names                                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 14.4 | Mentions @() sort modifier for column order                                                | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **15. benchstat-assume-exact** — assume=exact for deterministic metrics                    | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                              |
+| 15.1 | Recommends assume=exact unit metadata                                                      | <span class="g">✓</span>       | <span class="r">✗</span> suggests -count=10 anyway          |
+| 15.2 | Shows syntax: Unit <metric> assume=exact                                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 15.3 | assume=exact disables non-parametric statistics                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 15.4 | benchstat warns if values vary when assume=exact is set                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 15.5 | Single measurement works with assume=exact                                                 | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **16. ci-regression-tool-selection** — benchdiff vs cob vs gobenchdata                     | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                              |
+| 16.1 | Recommends benchdiff for PR-to-base with statistical rigor                                 | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 16.2 | benchdiff uses benchstat internally                                                        | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 16.3 | cob is simpler but uses single-run comparison                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 16.4 | Mentions gobenchdata for long-term trend tracking                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 16.5 | Tradeoff: benchdiff=rigor, cob=simple, gobenchdata=trends                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **17. cob-data-loss-warning** — cob uses git reset, destructive                            | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                              |
+| 17.1 | Warns that cob uses `git reset` which can cause data loss                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 17.2 | Recommends committing all work before running cob                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 17.3 | Suggests running cob only in CI, not locally                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 17.4 | cob compares single runs without benchstat-style statistics                                | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 17.5 | Mentions [skip cob] commit message convention                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **18. noisy-neighbor-mitigation** — CI benchmark variance and strategies                   | **<span class="g">6/6</span>** | **<span class="r">4/6</span>**                              |
+| 18.1 | Shared CI runners have 5-10% variance                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 18.2 | Run both base and head in same CI job for relative comparison                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 18.3 | Use -count=10+ with benchstat to filter noise                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 18.4 | Conservative thresholds (20%+) on shared runners                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 18.5 | Warns against 'retry until pass' as selection bias                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 18.6 | Dedicated/self-hosted runners for critical benchmarks                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **19. self-hosted-runner-tuning** — system-level settings for benchmark stability          | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                              |
+| 19.1 | Disable CPU frequency scaling with 'performance' governor                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 19.2 | Disable Turbo Boost (Intel no_turbo or AMD boost)                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 19.3 | Pin benchmarks to specific cores using taskset                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 19.4 | Disable SMT/Hyper-Threading                                                                | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 19.5 | Only apply to dedicated runners, never developer machines                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **20. taskset-core-pinning-rationale** — why core pinning reduces variance                 | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                              |
+| 20.1 | Without pinning, OS migrates process across cores                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 20.2 | L1/L2 caches are per-core, migration causes cache thrashing                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 20.3 | Leave cores 0-1 for OS, use cores 2+ for benchmarks                                        | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 20.4 | Shows taskset -c 2,3 go test ... syntax                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **21. b-report-metric-custom** — b.ReportMetric and b.Elapsed for throughput               | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                              |
+| 21.1 | Uses b.ReportMetric() for custom metrics                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 21.2 | Uses b.Elapsed() for total benchmark duration                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 21.3 | Shows pattern: b.ReportMetric(float64(bytes)/b.Elapsed().Seconds(), "bytes/s")             | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 21.4 | Custom metric integrates with standard benchmark output                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **22. memory-leak-detection-with-base** — pprof -base for heap snapshot diff               | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                              |
+| 22.1 | Take two heap snapshots separated by time                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 22.2 | Uses pprof -base to diff the two snapshots                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 22.3 | Recommends -inuse_space for leak detection                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 22.4 | alloc_space is cumulative and includes freed objects                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 22.5 | Common leak causes: unbounded caches, maps that never shrink, goroutine leaks              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **23. mutex-block-profile-enablement** — mutex/block profiles disabled by default          | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                              |
+| 23.1 | Mutex profiling disabled by default, must be enabled                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 23.2 | Shows runtime.SetMutexProfileFraction()                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 23.3 | Explains fraction parameter (e.g., 5 = 1/5 events recorded)                                | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 23.4 | Recommends disabling after investigation (SetMutexProfileFraction(0))                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 23.5 | Mentions runtime.SetBlockProfileRate() for block profile                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **24. trace-custom-annotations** — runtime/trace tasks, regions, logs                      | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                              |
+| 24.1 | trace.NewTask for logical operations spanning goroutines                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 24.2 | trace.WithRegion for phases within a task                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 24.3 | trace.Log for point-in-time markers                                                        | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 24.4 | Correct usage with context propagation (ctx parameter)                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 24.5 | Annotations add negligible overhead when tracing is disabled                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **25. trace-gc-phase-interpretation** — GC assist in execution traces                      | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                              |
+| 25.1 | GC mark assist = goroutines drafted by GC to scan heap                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 25.2 | Runtime forces goroutines to assist proportional to allocation rate                        | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 25.3 | Symptom of too many allocations, not a GC config problem                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 25.4 | Reduce allocation rate rather than tuning GOGC                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 25.5 | Distinguishes mark assist from STW which affects all goroutines equally                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **26. trace-pprof-extraction** — extracting pprof from trace data                          | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                              |
+| 26.1 | Uses `go tool trace -pprof=net trace.out > net.prof`                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 26.2 | Then uses go tool pprof on extracted profile                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 26.3 | Mentions other extractable types: sync, syscall, sched                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 26.4 | Bridges trace data (nanosecond) with pprof analysis (statistical)                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **27. fieldalignment-no-autofix** — diagnostic without -fix flag                           | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                              |
+| 27.1 | Recommends `fieldalignment ./...` to detect padding waste                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 27.2 | Does NOT use the -fix flag                                                                 | <span class="g">✓</span>       | <span class="r">✗</span> suggests -fix                      |
+| 27.3 | Mentions unsafe.Sizeof/Alignof/Offsetof for layout inspection                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 27.4 | Treats as diagnostic step, not automatic fix                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **28. godebug-gctrace-runtime-diagnostics** — GODEBUG env vars for GC diagnostics          | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                              |
+| 28.1 | Recommends GODEBUG=gctrace=1 without recompiling                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 28.2 | Describes gctrace output: GC frequency, pause times, heap sizes, CPU%                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 28.3 | Mentions other GODEBUG options like schedtrace                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 28.4 | Configured via environment variables, no recompile needed                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **29. runtime-scanobject-cpu-diagnosis** — GC pointer scanning high in CPU profile         | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                              |
+| 29.1 | runtime.scanobject = GC pointer scanning                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 29.2 | Heap contains many pointers GC must trace                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 29.3 | Reduce pointer density: value types in slices/maps                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 29.4 | Flatten structures or use [N]byte instead of string in hot structs                         | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 29.5 | References golang-performance skill for optimization patterns                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **30. runtime-memmove-diagnosis** — memmove high in CPU profile                            | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                              |
+| 30.1 | runtime.memmove = large memory copies                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 30.2 | Common causes: slice append, copy() of large slices, string-to-byte                        | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 30.3 | Pre-allocate slices to final capacity                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 30.4 | Reuse buffers or work with []byte directly                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 30.5 | Use top -cum to find application functions triggering memmoves                             | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **31. fgprof-off-cpu-profiling** — fgprof for combined on/off-CPU profiling                | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                              |
+| 31.1 | Recommends fgprof (github.com/felixge/fgprof)                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 31.2 | fgprof captures both on-CPU and off-CPU time in single profile                             | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 31.3 | Standard pprof CPU profiles only show on-CPU time                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 31.4 | Use case: pprof shows low CPU% but latency is high                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **32. flight-recorder-go125** — Go 1.25 flight recorder for retroactive trace              | **<span class="g">6/6</span>** | **<span class="r">0/6</span>**                              |
+| 32.1 | Recommends Go 1.25 flight recorder (trace.NewFlightRecorder)                               | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 32.2 | Keeps circular buffer of recent trace data in memory                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 32.3 | Shows snapshotting with WriteTo on anomaly detection                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 32.4 | Mentions MinAge and MaxBytes parameters                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 32.5 | Shows trigger pattern (slow request detection)                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 32.6 | At most one flight recorder active at a time                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **33. flight-recorder-sync-once-pattern** — sync.Once for snapshot dedup                   | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                              |
+| 33.1 | Uses sync.Once to ensure only one snapshot                                                 | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 33.2 | Calls fr.WriteTo inside sync.Once.Do                                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 33.3 | Only one goroutine may call WriteTo at a time                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 33.4 | Shows calling snapshot in separate goroutine                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 33.5 | Shows fr.Stop() after WriteTo completes                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **34. flight-recorder-sizing** — MinAge and MaxBytes configuration                         | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                              |
+| 34.1 | MinAge ~2x problem window (10s for 5s investigation)                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 34.2 | Busy services generate ~1-10 MB/s of trace data                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 34.3 | Start MaxBytes at 1-5 MiB and adjust                                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 34.4 | MaxBytes takes precedence over MinAge                                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **35. trace-timeline-color-coding** — execution trace UI color interpretation              | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                              |
+| 35.1 | Yellow/orange = runnable, waiting for processor                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 35.2 | Red bands across all P lanes = GC stop-the-world                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 35.3 | Yellow gaps = CPU saturation, too many goroutines competing                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 35.4 | Green = actively executing/running                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 35.5 | Check goroutine count vs GOMAXPROCS to verify saturation                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **36. pprof-web-ui-flamegraph** — interactive web UI for profile exploration               | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                              |
+| 36.1 | `go tool pprof -http=:8080 cpu.prof` for web UI                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 36.2 | Flamegraph view is most intuitive                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 36.3 | Lists other views: Graph, Top, Source, Disassembly, Peek                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 36.4 | Filters can be pre-applied with -focus flag                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **37. pprof-focus-ignore-difference** — focus vs ignore vs show vs hide semantics          | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                              |
+| 37.1 | focus keeps only paths containing matching function                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 37.2 | ignore removes functions, attributes costs to callers                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 37.3 | show is like focus but display-only, no cost accounting change                             | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 37.4 | hide is like ignore but display-only, no cost accounting change                            | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 37.5 | `reset` to clear all filters                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **38. pprof-tags-and-labels** — pprof.Do() custom labels for multi-tenant profiling        | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                              |
+| 38.1 | Uses pprof.Labels() and pprof.Do() for custom labels                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 38.2 | Correct pattern: pprof.Do(ctx, pprof.Labels("key", "value"), func...)                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 38.3 | tagfocus to filter by label                                                                | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 38.4 | tagroot to group by label                                                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 38.5 | tags command to see all tag keys and distributions                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **39. pprof-sample-index-switching** — switch metrics without reloading                    | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                              |
+| 39.1 | sample_index command to switch metrics                                                     | <span class="g">✓</span>       | <span class="r">✗</span> suggests exit and reopen           |
+| 39.2 | Correct syntax: sample_index=inuse_space                                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 39.3 | Lists available indices: alloc_objects, alloc_space, inuse_objects, inuse_space            | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 39.4 | Heap profiles contain multiple metrics, switchable interactively                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **40. pprof-granularity-lines** — per-line costs in top output                             | **<span class="g">3/3</span>** | **<span class="r">0/3</span>**                              |
+| 40.1 | granularity=lines for per-line grouping in top                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 40.2 | Other levels: functions (default), filefunctions, files, addresses                         | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 40.3 | Shows command: granularity=lines or -granularity=lines                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **41. ssa-dump-investigation** — GOSSAFUNC for compiler optimization passes                | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                              |
+| 41.1 | GOSSAFUNC=FunctionName go build for SSA dump                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 41.2 | Creates ssa.html openable in browser                                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 41.3 | Optimization passes: source, AST, start SSA, opt, lower, regalloc, genssa                  | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 41.4 | What to look for: bounds checks, dead code, constant folding, register spills              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 41.5 | Click values to highlight across passes                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **42. assembly-output-heap-allocation-detection** — verify no heap allocs in assembly      | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                              |
+| 42.1 | Uses `go build -gcflags="-S"` for assembly output                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 42.2 | Grep for CALL runtime.makeslice, runtime.newobject, growslice                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 42.3 | `go tool objdump` as alternative for compiled binaries                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 42.4 | `-S` flag for source-interleaved disassembly                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **43. value-receiver-inlining-advantage** — value vs pointer receivers and inlining        | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                              |
+| 43.1 | Value receivers enable full inlining of method chains                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 43.2 | Pointer receivers add indirection blocking inlining for fluent APIs                        | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 43.3 | Check with -gcflags="-m" to verify inlining behavior                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 43.4 | Considers struct size trade-off (value receivers copy the struct)                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **44. prometheus-go-metrics-vs-runtime-metrics** — runtime/metrics ≠ Prometheus metrics    | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                              |
+| 44.1 | runtime/metrics are Go internal data, not Prometheus metrics                               | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 44.2 | prometheus/client_golang selectively converts runtime/metrics                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 44.3 | Lists actual Prometheus metric names (go_memstats_alloc_bytes, etc.)                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 44.4 | By default only traditional go_memstats_* and go_gc_* are exposed                          | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **45. go-memstats-stw-overhead** — ReadMemStats causing stop-the-world pauses              | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                              |
+| 45.1 | go_memstats_* calls ReadMemStats() which triggers short STW pause                          | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 45.2 | Go 1.17+ runtime/metrics-based collector as lower overhead alternative                     | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 45.3 | Shows code: collectors.NewGoCollector with GoRuntimeMetricsCollection                      | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 45.4 | Use custom prometheus.NewRegistry() rather than default                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **46. promql-gc-pressure-queries** — specific PromQL for GC pressure investigation         | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                              |
+| 46.1 | rate(go_gc_duration_seconds_count[5m]) for GC frequency                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 46.2 | >2 GC cycles/s sustained = excessive allocation rate                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 46.3 | go_gc_duration_seconds{quantile="1"} for worst-case pause                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 46.4 | rate(go_memstats_alloc_bytes_total[5m]) for allocation rate                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 46.5 | Correlate with P99 latency to confirm GC causes tail latency                               | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **47. promql-goroutine-leak-detection** — PromQL patterns for goroutine leaks              | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                              |
+| 47.1 | go_goroutines gauge for current count                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 47.2 | delta(go_goroutines[1h]) for net change                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 47.3 | Count should correlate with load; independent growth = leak                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 47.4 | Alerting rule with threshold (go_goroutines > 10000)                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **48. investigation-session-setup** — structured production investigation preparation      | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                              |
+| 48.1 | Reduce Prometheus scrape interval to <=10s on target instance                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 48.2 | Enable pprof via environment variable without recompile                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 48.3 | Enable continuous profiling on target instance only, not fleet-wide                        | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 48.4 | Revert all changes after investigation                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 48.5 | All debug features should be toggleable via environment variables                          | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **49. cost-warnings-trace-duration** — trace data volume and practical limits              | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                              |
+| 49.1 | Traces generate MB/s — 5-minute trace would be enormous                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 49.2 | Keep traces to 5-10 seconds maximum                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 49.3 | Large traces slow to parse, need 1GB+ RAM                                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 49.4 | Suggest flight recorder (Go 1.25+) for intermittent issues                                 | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 49.5 | Browser UI struggles with traces >100MB                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **50. benchstat-three-version-comparison** — comparing more than two versions              | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                              |
+| 50.1 | Labels inputs: benchstat v1=v1.txt v2=v2.txt v3=v3.txt                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 50.2 | First input is always the base for comparison                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 50.3 | v2 vs v1 and v3 vs v1 shown (both relative to first)                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **51. host-level-correlation** — correlating Go metrics with infrastructure                | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                              |
+| 51.1 | Check node_exporter for host-level CPU, memory, disk I/O                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 51.2 | Noisy neighbor: high node_cpu with low process_cpu = external contention                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 51.3 | process-exporter for per-process metrics on shared hosts                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 51.4 | Correlate Go app metrics with infrastructure metrics                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **52. pprof-diff-base-vs-base** — -base vs -diff_base semantics                            | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                              |
+| 52.1 | -base subtracts base from source, values become deltas                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 52.2 | -diff_base shows percentages relative to base profile                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 52.3 | -normalize flag for comparable ratios across different durations                           | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 52.4 | Generate diff SVG for visual comparison                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **53. gobenchdata-github-action-setup** — long-term benchmark trend tracking               | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                              |
+| 53.1 | Recommends gobenchdata for trend tracking                                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 53.2 | GitHub Action config with bobheadxi/gobenchdata@v1                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 53.3 | Publishing to gh-pages for dashboard                                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 53.4 | Regression checks config (.gobenchdata-checks.yml) with thresholds                         | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 53.5 | PRUNE_COUNT to limit stored history                                                        | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **54. benchstat-single-file-summary** — single-file variance analysis                      | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                              |
+| 54.1 | benchstat bench.txt with single file                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 54.2 | Shows median and confidence interval per benchmark                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 54.3 | Use to check stability before making changes                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 54.4 | High variance (± >5%) = noisy benchmarks                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **55. count-minimum-by-scenario** — context-dependent -count recommendations               | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                              |
+| 55.1 | 6 minimum for quick local checks                                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 55.2 | 10 for standard pre-merge comparisons                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 55.3 | 20-30 for detecting small changes (<5%)                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 55.4 | 20+ for noisy CI environments                                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 55.5 | Warns against -count=1 as no variance information                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **56. interface-boxing-escape** — any/interface{} boxing as heap allocation source         | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                              |
+| 56.1 | Interface boxing: concrete type in any allocates heap copy                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 56.2 | fmt.Sprintf as common source of interface boxing                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 56.3 | Use concrete types instead of interfaces in hot paths                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 56.4 | Especially impactful in frequently-called functions                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **57. trace-scheduling-latency-diagnosis** — runnable-to-running delay analysis            | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                              |
+| 57.1 | High scheduling latency = goroutines waiting for processor                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 57.2 | Too many goroutines competing for GOMAXPROCS (CPU saturation)                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 57.3 | Extract sched profile: go tool trace -pprof=sched trace.out                                | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 57.4 | Check uneven distribution across Ps (work imbalance)                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 57.5 | Other causes: OS scheduling, goroutines pinned by cgo/syscalls                             | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **58. benchmark-output-format-parsing** — understanding benchmark output fields            | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                              |
+| 58.1 | -8 is the GOMAXPROCS suffix                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 58.2 | 5000000 is the number of iterations (b.N)                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 58.3 | ns/op is time per operation                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 58.4 | B/op is bytes allocated per operation                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 58.5 | allocs/op is heap allocation count per operation                                           | <span class="g">✓</span>       | <span class="r">✗</span> says "allocations" without heap    |
+|      | **59. pprof-show-from-framework-noise** — show_from to trim routing noise                  | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                              |
+| 59.1 | Uses show_from=regex to trim frames above first match                                      | <span class="g">✓</span>       | <span class="r">✗</span> suggests ignore instead            |
+| 59.2 | Shows pattern: show_from=handler.Handle                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 59.3 | show_from hides all callers above the match point                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 59.4 | Differentiates from ignore which re-attributes costs                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **60. optional-prometheus-metrics-enablement** — opt-in Go runtime Prometheus metrics      | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                              |
+| 60.1 | Custom registry with collectors.NewGoCollector                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 60.2 | collectors.WithGoCollectorRuntimeMetrics option                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 60.3 | GoRuntimeMetricsAll or specific collection flags                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 60.4 | Requires Go 1.17+                                                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 60.5 | Scheduler metrics: go_sched_latencies_seconds, CPU class: go_cpu_classes_*                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **61. benchdiff-usage-patterns** — automatic branch comparison with benchdiff              | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                              |
+| 61.1 | Recommends benchdiff for automatic branch comparison                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 61.2 | Command: benchdiff -base-ref main -- -benchmem -count=10                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 61.3 | Caches results for non-worktree refs                                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 61.4 | benchdiff -clear-cache for stale cache                                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 61.5 | Prevents macOS sleep during benchmarks                                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **62. pprof-noinlines-attribution** — simplify inlined function chains                     | **<span class="g">3/3</span>** | **<span class="r">0/3</span>**                              |
+| 62.1 | Uses noinlines option or -noinlines flag                                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 62.2 | Attributes inlined functions to first out-of-line caller                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 62.3 | Correct usage: `noinlines` interactive or `-noinlines` CLI                                 | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **63. sub-benchmarks-table-driven** — table-driven sub-benchmarks with b.Run               | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                              |
+| 63.1 | Uses b.Run() with descriptive names (size=64)                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 63.2 | Uses b.Loop() inside sub-benchmark since Go 1.24                                           | <span class="g">✓</span>       | <span class="r">✗</span> uses range b.N                     |
+| 63.3 | Setup code before b.Loop() call                                                            | <span class="g">✓</span>       | <span class="r">✗</span> uses b.ResetTimer()                |
+| 63.4 | Loop over sizes with fmt.Sprintf for names                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 63.5 | Output: BenchmarkEncode/size=64, BenchmarkEncode/size=256, etc.                            | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **64. benchstat-geomean-interpretation** — geometric mean row meaning                      | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                              |
+| 64.1 | geomean = geometric mean of changes across all benchmarks                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 64.2 | Represents overall proportional change                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 64.3 | Useful for single summary across many benchmarks                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 64.4 | Individual benchmarks may differ significantly from geomean                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **65. trace-short-lived-goroutines** — goroutine creation overhead in traces               | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                              |
+| 65.1 | High overhead from goroutine creation/scheduling for short-lived ones                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 65.2 | Batch work or use worker pools to reduce creation overhead                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 65.3 | Goroutines created in loops without bounds = potential leak                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 65.4 | Goroutines created but never finishing = leak                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **66. comparing-across-machines-pitfall** — cross-machine comparison invalid               | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                              |
+| 66.1 | Warns that cross-machine comparison is invalid                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 66.2 | Different CPUs, memory, OS = incomparable baselines                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 66.3 | Run both on same machine with same conditions                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 66.4 | Notes this as common benchstat pitfall                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **67. b-report-allocs-vs-benchmem** — two ways to enable allocation reporting              | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                              |
+| 67.1 | b.ReportAllocs() in benchmark function                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 67.2 | -benchmem flag on go test command                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 67.3 | Both produce same B/op and allocs/op output                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 67.4 | b.ReportAllocs() is per-benchmark, -benchmem is for all                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **68. pprof-goroutine-debug-levels** — ?debug=1 and ?debug=2 for goroutine dumps           | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                              |
+| 68.1 | curl with ?debug=1 for human-readable dump                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 68.2 | ?debug=2 for full stacks with creation site and labels                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 68.3 | Shows URL: /debug/pprof/goroutine?debug=1 or ?debug=2                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 68.4 | No go tool pprof needed for debug mode dumps                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **69. ci-threshold-calibration** — regression thresholds by CI environment                 | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                              |
+| 69.1 | 20%+ threshold on shared/GitHub-hosted runners                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 69.2 | 10% on dedicated self-hosted runners                                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 69.3 | Tight thresholds on noisy environments = false positives eroding trust                     | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 69.4 | GitHub-hosted runners ~2-3% CoV in best case                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 69.5 | <1% false positive rate requires 7%+ gate                                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **70. cpu-profile-sampling-rate** — CPU profiler 100Hz sampling mechanism                  | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                              |
+| 70.1 | CPU profiling uses statistical sampling at 100Hz                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 70.2 | Functions shorter than sampling interval may not appear                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 70.3 | Only captures on-CPU time, off-CPU invisible                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 70.4 | ~5% overhead during CPU profile capture                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **71. benchstat-ignore-dimension-warning** — -ignore flag for suppressing warnings         | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                              |
+| 71.1 | -ignore /gomaxprocs to suppress warning                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 71.2 | -ignore omits keys from grouping                                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 71.3 | -row .name to simplify row grouping                                                        | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 71.4 | -col /gomaxprocs to compare across values instead                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **72. escape-analysis-fmt-sprintf** — fmt.Sprintf heap allocation explanation              | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                              |
+| 72.1 | fmt.Sprintf arguments boxed into any/interface{} (boxing)                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 72.2 | Result string is also heap-allocated                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 72.3 | fmt.Sprintf is common escape cause in compiler analysis                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 72.4 | Alternatives for hot paths: strconv, strings.Builder, direct byte manipulation             | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **73. runtime-readmemstats-vs-runtime-metrics** — programmatic GC stats APIs               | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                              |
+| 73.1 | runtime.ReadMemStats for heap size, NumGC, pause durations                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 73.2 | debug.ReadGCStats for GC-specific statistics                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 73.3 | runtime/metrics (Go 1.16+) as preferred modern API                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 73.4 | runtime/metrics has lower overhead and safe for concurrent reads                           | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 73.5 | ReadMemStats is more expensive due to internal locking                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+|      | **74. pprof-callgrind-export** — exporting to KCachegrind format                           | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                              |
+| 74.1 | callgrind command or -callgrind flag to export                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 74.2 | Command: go tool pprof -callgrind cpu.prof > cpu.callgrind                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 74.3 | KCachegrind or QCachegrind as visualization tools                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 74.4 | proto command for protobuf format as alternative                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **75. expvar-lightweight-monitoring** — stdlib expvar for JSON metrics                     | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                              |
+| 75.1 | Recommends expvar package from stdlib                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 75.2 | import _ "expvar" auto-registers at /debug/vars                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 75.3 | Serves JSON format                                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 75.4 | Integration with Netdata, Telegraf, custom dashboards                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **76. benchstat-table-flag-per-package** — -table pkg for per-package tables               | **<span class="g">3/3</span>** | **<span class="r">0/3</span>**                              |
+| 76.1 | -table pkg flag for one table per package                                                  | <span class="g">✓</span>       | <span class="r">✗</span> suggests running benchstat per pkg |
+| 76.2 | Command: benchstat -table pkg old.txt new.txt                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 76.3 | Default -table is .config (goos/goarch/pkg/cpu)                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **77. pprof-symbolization-remote** — symbolization modes for remote profiles               | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                              |
+| 77.1 | Symbolization modes: local, remote, none                                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 77.2 | -symbolize=local for local binaries                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 77.3 | PPROF_BINARY_PATH env var for binary search paths                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 77.4 | -symbolize=remote to contact running service                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **78. trace-concurrent-with-flight-recorder** — trace.Start and FlightRecorder coexistence | **<span class="g">3/3</span>** | **<span class="r">0/3</span>**                              |
+| 78.1 | Flight recorder can run concurrently with trace.Start                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 78.2 | At most one flight recorder active at a time                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 78.3 | Both can be active simultaneously without conflict                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **79. pyroscope-overhead-warning** — continuous profiling overhead at scale                | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                              |
+| 79.1 | ~2-5% CPU overhead per instance for continuous profiling                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 79.2 | 200 instances = significant aggregate compute and storage cost                             | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 79.3 | Enable on subset of instances or on-demand via env var                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+| 79.4 | Investigation session approach: target instances only, not fleet-wide                      | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+|      | **80. non-go-memory-leak-detection** — PromQL for cgo/mmap leak detection                  | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                              |
+| 80.1 | PromQL: process_resident_memory_bytes - go_memstats_sys_bytes                              | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 80.2 | Gap = non-Go memory (cgo, mmap)                                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 80.3 | Growing gap = non-Go memory leak                                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                    |
+| 80.4 | Investigate cgo calls or memory-mapped files                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                    |
+
+</details>
+
+## `golang-observability` — v1.0.0
+
+|             | With Skill         | Without Skill     | Delta     |
+| ----------- | ------------------ | ----------------- | --------- |
+| **Overall** | **185/185 (100%)** | **117/185 (63%)** | **+37pp** |
+
+<details>
+<summary>Full breakdown (185 assertions across 40 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                                             | With                           | Without                                                           |
+| ---- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------ | ----------------------------------------------------------------- |
+|      | **1. summary-vs-histogram-multi-replica** — Histogram over Summary when multiple replicas need aggregated percentiles | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                    |
+| 1.1  | Recommends Histogram, not Summary                                                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 1.2  | Explains that Summary quantiles cannot be aggregated across multiple instances                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 1.3  | Shows histogram_quantile() PromQL function for computing percentiles server-side                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 1.4  | Mentions that Histogram supports server-side aggregation across replicas                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 1.5  | Uses prometheus.NewHistogramVec (not NewSummary) in the code example                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **2. log-and-return-error-trap** — single handling rule: log OR return, never both                                    | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                    |
+| 2.1  | Identifies the log-and-return pattern as incorrect                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 2.2  | Explains that the error gets logged multiple times as it propagates up the chain                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 2.3  | Recommends returning the error with context and logging once at the top level                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 2.4  | Shows the corrected pattern: return fmt.Errorf with wrapping, no slog call                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 2.5  | References or explains the single handling rule (errors are either logged OR returned, never both)                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **3. high-cardinality-label-trap** — high-cardinality label usage in Prometheus metrics                               | **<span class="g">6/6</span>** | **<span class="r">4/6</span>**                                    |
+| 3.1  | Identifies userID as a high-cardinality label that will cause problems                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 3.2  | Identifies r.URL.Path as potentially high-cardinality (should use route template instead)                             | <span class="g">✓</span>       | <span class="r">✗</span> focuses on userID, misses URL.Path       |
+| 3.3  | Explains that each unique label combination creates a separate time series                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 3.4  | Warns about memory explosion on the Prometheus server from unbounded labels                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 3.5  | Recommends using route patterns/templates (e.g., /users/:id) instead of actual paths                                  | <span class="g">✓</span>       | <span class="r">✗</span> generic advice without route template    |
+| 3.6  | Suggests using traces (not metrics) for high-cardinality data like user IDs                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **4. production-json-logging** — JSON handler for production, not TextHandler                                         | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                    |
+| 4.1  | Recommends JSONHandler for production, not TextHandler                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 4.2  | Explains that plain-text multiline logs (e.g., stack traces) get split into separate records by log collectors        | <span class="g">✓</span>       | <span class="r">✗</span> generic "not machine-parseable"          |
+| 4.3  | Suggests TextHandler is appropriate for development only                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 4.4  | Shows the correct JSONHandler setup with slog.LevelInfo for production                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **5. slog-context-variant-trace-correlation** — *Context variants for trace correlation                               | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                    |
+| 5.1  | Identifies that slog.Info and slog.Error should use their *Context variants                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 5.2  | Explains that without ctx, trace_id and span_id won't be injected into log records                                    | <span class="g">✓</span>       | <span class="r">✗</span> unaware of otelslog injection mechanism  |
+| 5.3  | Shows the corrected code using slog.InfoContext(ctx, ...) and slog.ErrorContext(ctx, ...)                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 5.4  | Mentions that the otelslog bridge automatically injects trace correlation when context is passed                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **6. metric-naming-conventions** — base units, _total suffix, namespace                                               | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                    |
+| 6.1  | Flags request_count as missing namespace and unit suffix                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 6.2  | Flags httpDuration as using camelCase and missing unit                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 6.3  | Flags request_duration_ms — should use _seconds (base unit), not milliseconds                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 6.4  | Flags myapp_request_size_kb — should use _bytes (base unit), not kilobytes                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 6.5  | Flags embedding label values into metric names — should use a single metric with a method label                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **7. irate-vs-rate-for-alerts** — irate() is inappropriate for alerting rules                                         | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 7.1  | Identifies irate() as inappropriate for alerting rules                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 7.2  | Explains that irate reacts to a single scrape interval and is too volatile                                            | <span class="g">✓</span>       | <span class="r">✗</span> knows irate differs but imprecise why    |
+| 7.3  | Recommends rate() instead of irate() for alerts                                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 7.4  | Recommends adding a for: duration to avoid firing on transient spikes                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 7.5  | Shows the corrected alert rule using rate() with a for: clause                                                        | <span class="g">✓</span>       | <span class="r">✗</span> shows rate() but misses error ratio      |
+|      | **8. alert-missing-for-duration** — alerts without for: duration clause                                               | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                    |
+| 8.1  | Identifies the missing for: duration as a problem                                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 8.2  | Explains that without for:, a single bad scrape triggers the alert                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 8.3  | Recommends adding for: 5m or similar duration                                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 8.4  | Distinguishes that binary alerts (service up/down) can use for: 0m, but non-binary need a duration                    | <span class="g">✓</span>       | <span class="r">✗</span> generic advice, no binary distinction    |
+|      | **9. promql-comments-convention** — documenting metrics with PromQL comments above declarations                       | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                                    |
+| 9.1  | Recommends adding PromQL queries and alert rules as comments directly above the metric var                            | <span class="g">✓</span>       | <span class="r">✗</span> suggests wiki or README                  |
+| 9.2  | Shows example Dashboard: and Alert: comment lines above the metric var                                                | <span class="g">✓</span>       | <span class="r">✗</span> no such convention known                 |
+| 9.3  | Explains that this keeps PromQL queries reviewed in PRs alongside the metric                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 9.4  | Mentions that queries stay in sync with metric changes (label renames, bucket changes)                                | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 9.5  | Notes that new team members can understand the metric's purpose at a glance                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+|      | **10. otelslog-bridge-setup** — log-trace correlation using otelslog bridge                                           | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                    |
+| 10.1 | Recommends using the otelslog bridge from go.opentelemetry.io/contrib/bridges/otelslog                                | <span class="g">✓</span>       | <span class="r">✗</span> suggests manual trace_id extraction      |
+| 10.2 | Shows creating a handler with otelslog.NewHandler()                                                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 10.3 | Shows setting it as default with slog.SetDefault()                                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 10.4 | Explains that trace_id and span_id are automatically injected into log records                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 10.5 | Emphasizes using slog.*Context(ctx, ...) variants to enable the automatic injection                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+|      | **11. exemplars-metric-trace-link** — metrics-to-traces correlation via Prometheus exemplars                          | **<span class="g">3/3</span>** | **<span class="r">1/3</span>**                                    |
+| 11.1 | Recommends using Prometheus exemplars to link metrics to traces                                                       | <span class="g">✓</span>       | <span class="r">✗</span> suggests manual correlation              |
+| 11.2 | Shows attaching trace_id as an exemplar when recording histogram observations                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 11.3 | Explains that exemplars let you jump from a metric spike directly to the trace                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **12. span-error-recording-both-calls** — RecordError() AND SetStatus(Error) required                                 | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                    |
+| 12.1 | Identifies that span.SetStatus(codes.Error, ...) is also needed alongside RecordError                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 12.2 | Explains that RecordError adds an event but does not mark the span as failed                                          | <span class="g">✓</span>       | <span class="r">✗</span> may not distinguish event vs status      |
+| 12.3 | Shows the corrected pattern with both span.RecordError(err) and span.SetStatus(codes.Error, ...)                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 12.4 | Notes that on success, no status needs to be set (Unset is fine)                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **13. otelhttp-outgoing-requests** — outgoing HTTP clients must use otelhttp transport                                | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                    |
+| 13.1 | Recommends wrapping the HTTP client transport with otelhttp.NewTransport                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 13.2 | Shows the code: client := &http.Client{Transport: otelhttp.NewTransport(http.DefaultTransport)}                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 13.3 | Explains that this automatically propagates trace context to outgoing requests                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 13.4 | Mentions that otelhttp creates child spans for outgoing HTTP calls                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **14. db-query-context-propagation** — database calls must use *Context variants                                      | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                    |
+| 14.1 | Identifies that db.Query should be db.QueryContext(ctx, ...)                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 14.2 | Explains that without context, the trace is broken                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 14.3 | Shows the corrected code using db.QueryContext(ctx, ...)                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 14.4 | States that context is the vehicle that carries trace_id and span_id across boundaries                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **15. trace-sampling-cost-control** — trace sampling strategies and cost implications                                 | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                    |
+| 15.1 | Recommends TraceIDRatioBased sampling with a specific ratio (e.g., 0.1 for 10%)                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 15.2 | Mentions ParentBased sampler to respect parent's sampling decision                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 15.3 | Discusses head-based vs tail-based sampling tradeoffs                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 15.4 | Recommends avoiding large payloads as span attributes — log and correlate via trace_id                                | <span class="g">✓</span>       | <span class="r">✗</span> generic cost advice                      |
+| 15.5 | Explains the cost factors: span volume, span attributes, storage and indexing                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **16. where-to-add-spans** — which operations must have spans in OpenTelemetry                                        | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                    |
+| 16.1 | Lists service methods (business logic layer) as requiring spans                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 16.2 | Lists database queries as requiring spans                                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 16.3 | Lists external API calls as requiring spans                                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 16.4 | Lists message queue publish/consume operations as requiring spans                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 16.5 | States any operation that takes measurable time or could fail should have a span                                      | <span class="g">✓</span>       | <span class="r">✗</span> gives specific list, misses general rule |
+|      | **17. four-golden-signals-alerting** — four golden signals for service alerting                                       | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                    |
+| 17.1 | References the four golden signals: latency, traffic, errors, saturation                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 17.2 | Includes a latency alert (e.g., P99 > threshold)                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 17.3 | Includes a traffic alert (e.g., zero requests detection)                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 17.4 | Includes an error rate alert (e.g., 5xx ratio > threshold)                                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 17.5 | Includes a saturation alert (e.g., connection pool > 90%)                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **18. awesome-prometheus-alerts-resource** — awesome-prometheus-alerts as a starting point                            | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                                    |
+| 18.1 | Recommends awesome-prometheus-alerts (samber.github.io/awesome-prometheus-alerts/)                                    | <span class="g">✓</span>       | <span class="r">✗</span> suggests writing rules from scratch      |
+| 18.2 | Mentions it contains ~500 ready-to-use Prometheus alerting rules organized by technology                              | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 18.3 | Suggests the workflow: browse by technology, copy rules, customize thresholds                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 18.4 | Mentions verifying that exporters (postgres_exporter, redis_exporter) are deployed                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+|      | **19. go-runtime-alerts** — Go runtime-specific Prometheus alerts                                                     | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 19.1 | Suggests alerting on go_goroutines exceeding a threshold for goroutine leaks                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 19.2 | Suggests alerting on go_gc_duration_seconds for GC pressure                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 19.3 | Suggests alerting on go_memstats_alloc_bytes / go_memstats_sys_bytes for memory leaks                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 19.4 | Suggests alerting on go_threads for high OS thread count                                                              | <span class="g">✓</span>       | <span class="r">✗</span> rarely includes thread alerts            |
+| 19.5 | Uses for: duration on all non-binary alerts to avoid false positives                                                  | <span class="g">✓</span>       | <span class="r">✗</span> omits for: on some alerts                |
+|      | **20. alert-severity-levels** — severity classification and for: durations                                            | **<span class="g">6/6</span>** | **<span class="r">4/6</span>**                                    |
+| 20.1 | Uses two severity levels: critical (page on-call) and warning (create ticket)                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 20.2 | Critical alerts: for: 2m to 5m for fast detection                                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 20.3 | Warning alerts: for: 10m to 30m for confirmed trends                                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 20.4 | Classifies service down as critical with short for: duration                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 20.5 | Classifies goroutine leak as warning (not critical)                                                                   | <span class="g">✓</span>       | <span class="r">✗</span> may classify as critical                 |
+| 20.6 | States that for: 0m should never be used on non-binary alerts                                                         | <span class="g">✓</span>       | <span class="r">✗</span> not a widely known rule                  |
+|      | **21. multi-window-burn-rate-slo** — multi-window burn-rate SLO alerting                                              | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 21.1 | Recommends multi-window burn-rate alerting instead of simple threshold alerts                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 21.2 | Explains the concept of error budget and burn rate                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 21.3 | Includes fast burn window (e.g., 5m + 1h, 14.4x burn rate) as critical/page                                           | <span class="g">✓</span>       | <span class="r">✗</span> generic burn rate, no specific windows   |
+| 21.4 | Includes slow burn window (e.g., 2h + 24h, 1x burn rate) as warning/ticket                                            | <span class="g">✓</span>       | <span class="r">✗</span> no slow burn tier                        |
+| 21.5 | Shows PromQL using AND of short and long windows to eliminate false positives                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **22. slog-migration-from-zap** — incremental migration from zap to slog using bridge                                 | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                    |
+| 22.1 | Recommends a three-step migration: bridge, replace call sites, remove bridge                                          | <span class="g">✓</span>       | <span class="r">✗</span> suggests gradual replacement only        |
+| 22.2 | Step 1: Use samber/slog-zap bridge handler to route slog output through zap                                           | <span class="g">✓</span>       | <span class="r">✗</span> unaware of samber/slog-zap               |
+| 22.3 | Step 2: Gradually replace zap.L().Info(...) calls with slog.Info(...)                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 22.4 | Step 3: Once fully migrated, replace bridge with native slog JSONHandler and remove zap                               | <span class="g">✓</span>       | <span class="r">✗</span> no bridge step to remove                 |
+| 22.5 | Mentions using parallel sub-agents for large codebase migration                                                       | <span class="g">✓</span>       | <span class="r">✗</span> not a known pattern                      |
+|      | **23. slog-migration-from-logrus** — bridge handler approach for logrus migration                                     | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                    |
+| 23.1 | Recommends using samber/slog-logrus bridge handler for incremental migration                                          | <span class="g">✓</span>       | <span class="r">✗</span> unaware of samber/slog-logrus            |
+| 23.2 | Explains that slog is the standard library logger since Go 1.21                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 23.3 | Shows the bridge step: route slog output through the existing logrus logger                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 23.4 | Shows the replacement: logrus.WithField becomes slog.Info                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **24. debug-level-production-cost** — log level cost implications in production                                       | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 24.1 | Recommends slog.LevelInfo for production, NOT Debug                                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 24.2 | Explains that Debug level can generate millions of log lines per minute in busy services                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 24.3 | Mentions cost: CPU for serialization, I/O for disk/network, money for log ingestion/storage                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 24.4 | Mentions Debug can inflate costs by 10-100x                                                                           | <span class="g">✓</span>       | <span class="r">✗</span> no specific multiplier                   |
+| 24.5 | Suggests samber/slog-sampling as an alternative to sample verbose logs                                                | <span class="g">✓</span>       | <span class="r">✗</span> unaware of samber/slog-sampling          |
+|      | **25. pii-in-logs-trap** — catching PII being logged                                                                  | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                    |
+| 25.1 | Flags email as PII that should not be logged                                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 25.2 | Flags SSN as PII that should absolutely never be logged                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 25.3 | Recommends logging identifiers (user_id) instead of PII                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 25.4 | Shows corrected logging using user.ID instead of email/SSN                                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **26. counter-suffix-total-requirement** — Prometheus counters must use _total suffix                                 | **<span class="g">3/3</span>** | **<span class="g">3/3</span>**                                    |
+| 26.1 | Identifies the missing _total suffix — counters MUST end with _total                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 26.2 | Shows the corrected name: requests_total or http_requests_total                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 26.3 | Mentions that _total is a required convention for counters in Prometheus                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **27. pprof-security-auth** — pprof endpoints must be protected with authentication                                   | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                    |
+| 27.1 | Warns that pprof endpoints must NOT be exposed publicly without authentication                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 27.2 | Explains that pprof leaks sensitive runtime information and can be abused for DoS                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 27.3 | Recommends protecting with basic auth or running on a separate internal port                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 27.4 | Suggests toggling via environment variable to enable/disable without redeployment                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **28. continuous-profiling-env-toggle** — toggle continuous profiling via environment variables                       | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 28.1 | Recommends toggling via environment variable (e.g., PROFILING_ENABLED)                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 28.2 | Mentions ~2-5% CPU overhead for continuous profiling                                                                  | <span class="g">✓</span>       | <span class="r">✗</span> no specific overhead figure              |
+| 28.3 | Suggests starting with CPU + heap profiles only, adding mutex/block when needed                                       | <span class="g">✓</span>       | <span class="r">✗</span> suggests all profiles                    |
+| 28.4 | For large deployments, recommends enabling on a fraction of replicas (e.g., 1 in 10)                                  | <span class="g">✓</span>       | <span class="r">✗</span> not a widely known practice              |
+| 28.5 | Shows code that checks the environment variable before starting Pyroscope                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **29. rum-identity-key-email-trap** — RUM distinct_id must be user_id, not email                                      | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                    |
+| 29.1 | Rejects email as the DistinctId — must use user_id instead                                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 29.2 | Explains that email is mutable — users change it, splitting events into two users                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 29.3 | Explains that email is PII, complicating GDPR/CCPA compliance                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 29.4 | Notes that email leaks into third-party analytics systems as the identity key                                         | <span class="g">✓</span>       | <span class="r">✗</span> not commonly considered                  |
+| 29.5 | Shows corrected code using user.ID (immutable internal identifier)                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **30. gdpr-consent-before-tracking** — GDPR consent must be checked before sending events                             | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 30.1 | Identifies that consent must be checked before sending the tracking event                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 30.2 | Shows extracting consent from context and conditionally tracking                                                      | <span class="g">✓</span>       | <span class="r">✗</span> generic consent advice without Go code   |
+| 30.3 | Mentions GDPR fines (up to 4% of global revenue) or CCPA penalties                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 30.4 | References data minimization — only collect what you need                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 30.5 | Mentions data subject rights endpoints (data export and deletion)                                                     | <span class="g">✓</span>       | <span class="r">✗</span> focuses on consent only                  |
+|      | **31. data-subject-rights-endpoints** — GDPR requires deletion/export across all systems                              | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 31.1 | States that deletion must propagate to ALL systems holding user data                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 31.2 | Lists the analytics platform (PostHog) as needing deletion                                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 31.3 | Lists the CDP (Segment) as needing deletion                                                                           | <span class="g">✓</span>       | <span class="r">✗</span> may not mention CDP deletion             |
+| 31.4 | References GDPR Article 17 Right to Erasure                                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 31.5 | Also mentions the Right of Access (data export endpoint) as a requirement                                             | <span class="g">✓</span>       | <span class="r">✗</span> focuses on deletion only                 |
+|      | **32. five-signals-completeness** — five observability signals and their distinct roles                               | **<span class="g">6/6</span>** | **<span class="r">4/6</span>**                                    |
+| 32.1 | Lists all five signals: logs, metrics, traces, profiles, and RUM                                                      | <span class="g">✓</span>       | <span class="r">✗</span> lists logs, metrics, traces only         |
+| 32.2 | Associates logs with 'what happened' (discrete events, audit trails)                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 32.3 | Associates metrics with 'how much/how fast' (aggregated measurements, alerting, SLOs)                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 32.4 | Associates traces with 'where did time go' (request flow across services)                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 32.5 | Associates profiles with 'why is it slow/using memory' (CPU hotspots, memory leaks)                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 32.6 | Associates RUM with 'how do users experience it' (product analytics, funnels)                                         | <span class="g">✓</span>       | <span class="r">✗</span> RUM not listed as a signal               |
+|      | **33. definition-of-done-observability** — observability checklist before shipping a feature                          | **<span class="g">6/6</span>** | **<span class="r">4/6</span>**                                    |
+| 33.1 | States that a feature is not production-ready until it is observable                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 33.2 | Checks for metric declarations (counters, histograms, gauges) with PromQL comments                                    | <span class="g">✓</span>       | <span class="r">✗</span> does not mention PromQL comments         |
+| 33.3 | Checks for proper structured logging with slog and context variants                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 33.4 | Checks for OpenTelemetry spans on service methods, DB queries, and external calls                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 33.5 | Checks for dashboards and alerts being wired up                                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 33.6 | Checks that errors are either logged OR returned, never both                                                          | <span class="g">✓</span>       | <span class="r">✗</span> not part of typical deploy checklist     |
+|      | **34. grafana-dashboard-ids** — specific Grafana dashboard IDs for Go runtime monitoring                              | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                                    |
+| 34.1 | Recommends specific Grafana dashboard IDs (21221, 6671, or 10826)                                                     | <span class="g">✓</span>       | <span class="r">✗</span> suggests building custom dashboards      |
+| 34.2 | Mentions dashboard 21221 for host + runtime combined view                                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 34.3 | Explains that these dashboards use default Go collector metrics from the Prometheus client library                    | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 34.4 | Shows how to import: Dashboards > New > Import, enter the dashboard ID                                                | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+|      | **35. slog-with-request-scoped-attrs** — slog.With() for request-scoped attributes                                    | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                    |
+| 35.1 | Recommends using slog.With() to create a child logger with request-scoped attributes                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 35.2 | Shows middleware pattern that creates the enriched logger                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 35.3 | Shows storing the enriched logger in context for downstream use                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 35.4 | Includes request_id, method, and path as the attributes to inject                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **36. slog-ecosystem-handlers** — slog handler ecosystem beyond stdlib                                                | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                    |
+| 36.1 | Recommends samber/slog-multi for fan-out to multiple handlers                                                         | <span class="g">✓</span>       | <span class="r">✗</span> suggests custom io.MultiWriter           |
+| 36.2 | Mentions samber/slog-sentry for sending errors to Sentry                                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 36.3 | Mentions samber/slog-datadog for sending logs to Datadog                                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 36.4 | Explains that slog supports pluggable handlers                                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 36.5 | References the slog ecosystem (go.dev/wiki/Resources-for-slog or similar)                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+|      | **37. parallel-observability-audit** — parallel sub-agents for observability audits                                   | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                                    |
+| 37.1 | Recommends using up to 5 parallel sub-agents (via the Agent tool)                                                     | <span class="g">✓</span>       | <span class="r">✗</span> suggests linear approach                 |
+| 37.2 | Assigns one sub-agent per signal: metrics, logging, tracing, profiling, RUM                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 37.3 | Sub-agent for metrics: verify metric declarations and PromQL comments                                                 | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 37.4 | Sub-agent for logging: check structured logging, PII in logs, error logging patterns                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 37.5 | Sub-agent for tracing: verify span creation in service methods, DB calls, API calls                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+|      | **38. predict-linear-for-saturation** — predict_linear for anticipating resource exhaustion                           | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                    |
+| 38.1 | Recommends using predict_linear() PromQL function to extrapolate trends                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 38.2 | Shows expression: predict_linear(db_connections_active[15m], 600) > db_connections_max                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 38.3 | Explains that predict_linear extrapolates from recent trend to predict future value                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 38.4 | Also suggests a threshold alert (e.g., > 90%) as a complementary alert                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **39. self-hosted-rum-gdpr** — self-hosted analytics for GDPR compliance                                              | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                    |
+| 39.1 | Recommends self-hosted analytics (PostHog or Matomo) for EU data residency                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 39.2 | Explains that self-hosting eliminates cross-border data transfer concerns                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 39.3 | Compares self-hosted vs SaaS tradeoffs (data residency, cost, maintenance, features)                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 39.4 | Mentions that PostHog can be self-hosted to keep data in your own infrastructure                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **40. oops-structured-errors-tracing** — samber/oops for structured errors in tracing                                 | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                                    |
+| 40.1 | Recommends samber/oops for structured errors with stack traces                                                        | <span class="g">✓</span>       | <span class="r">✗</span> suggests fmt.Errorf or manual attrs      |
+| 40.2 | Shows using oops with .In(), .Code(), and .With() for structured context                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 40.3 | Explains that oops errors carry stack trace, structured context, and work with span.RecordError()                     | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+| 40.4 | Mentions compatibility with errors.Is/errors.As and slog                                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                          |
+
+</details>
+
+## `golang-performance` — v1.0.0
+
+|             | With Skill         | Without Skill     | Delta     |
+| ----------- | ------------------ | ----------------- | --------- |
+| **Overall** | **272/272 (100%)** | **167/272 (61%)** | **+39pp** |
+
+<details>
+<summary>Full breakdown (272 assertions across 68 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                                     | With                           | Without                                                             |
+| ---- | ------------------------------------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------------- |
+|      | **1. profile-before-optimizing** — Tests whether the model insists on profiling before applying optimizations | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                      |
+| 1.1  | Recommends profiling (pprof, fgprof, or tracing) before making code changes                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 1.2  | Identifies fetchFromDB as the likely bottleneck (external I/O, not Go code)                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 1.3  | Mentions that intuition about bottlenecks is often wrong (~80% of the time)                                   | <span class="g">✓</span>       | <span class="r">✗</span> no specific stat                           |
+| 1.4  | Does NOT primarily focus on micro-optimizing strings.ToUpper or JSON encoding                                 | <span class="g">✓</span>       | <span class="r">✗</span> suggests strings.Builder/JSON fixes        |
+| 1.5  | Suggests investigating the database query (query tuning, caching, connection pool)                            | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **2. fgprof-off-cpu-bottleneck** — Tests whether the model recommends fgprof for off-CPU bottlenecks          | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                      |
+| 2.1  | Recommends fgprof as the primary tool for capturing off-CPU wait time                                         | <span class="g">✓</span>       | <span class="r">✗</span> suggests goroutine profiles or tracing     |
+| 2.2  | Explains that standard pprof CPU profile only captures on-CPU time                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 2.3  | Suggests the bottleneck is likely I/O wait (network, database, filesystem)                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 2.4  | Mentions goroutine profile as a complementary diagnostic                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 2.5  | Suggests distributed tracing (OpenTelemetry) for identifying slow upstream services                           | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **3. iterative-benchmark-methodology** — Tests iterative benchmark approach (one change at a time, benchstat) | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                      |
+| 3.1  | Recommends writing an atomic benchmark for ProcessRecords first                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 3.2  | Recommends measuring a baseline with -benchmem and -count=6 for statistical significance                      | <span class="g">✓</span>       | <span class="r">✗</span> skips -count=6                             |
+| 3.3  | Recommends applying ONE optimization at a time, not all at once                                               | <span class="g">✓</span>       | <span class="r">✗</span> applies all at once                        |
+| 3.4  | Recommends using benchstat to compare before/after with statistical significance                              | <span class="g">✓</span>       | <span class="r">✗</span> no benchstat                               |
+| 3.5  | Suggests keeping report files as an audit trail (e.g., /tmp/report-1.txt)                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **4. slice-reuse-append-zero** — Tests knowledge of append(s[:0], ...) for reusing slice backing arrays       | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                      |
+| 4.1  | Suggests using append(mode[:0], item) to reuse the backing array                                              | <span class="g">✓</span>       | <span class="r">✗</span> suggests sync.Pool or new slice            |
+| 4.2  | Explains that reslicing to zero length retains the backing array                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 4.3  | Moves the mode variable declaration outside the loop to enable reuse                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 4.4  | Does NOT suggest sync.Pool as the primary solution for this simple case                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **5. direct-indexing-vs-append** — Tests direct indexing over append when output size equals input            | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                                      |
+| 5.1  | Suggests using make([]Result, len(input)) with direct assignment result[i] = convert(...)                     | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 5.2  | Explains that direct assignment avoids per-element append overhead (bounds check, length increment)           | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 5.3  | Notes that append is better when the result might be smaller (filtering)                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **6. map-range-double-lookup** — Tests catching redundant map lookups in range loops                          | **<span class="g">2/2</span>** | **<span class="g">2/2</span>**                                      |
+| 6.1  | Identifies that for k := range in { in[k] } does two map lookups per iteration                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 6.2  | Suggests for k, v := range in { result[k] = strconv.Itoa(v) } for single lookup                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **7. sentinel-errors-hot-path** — Tests preallocated sentinel errors over fmt.Errorf in hot paths             | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 7.1  | Converts the static error to a preallocated sentinel using errors.New at package level                        | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 7.2  | Keeps fmt.Errorf for the dynamic error that includes %d                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 7.3  | Explains that fmt.Errorf allocates on every call, while sentinels allocate once                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 7.4  | Does NOT convert the dynamic error to a sentinel                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **8. interface-boxing-hot-path** — Tests interface boxing allocation cost and generics fix                    | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                      |
+| 8.1  | Identifies interface boxing (any parameter) as the source of allocations                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 8.2  | Suggests typed functions or generics to eliminate boxing                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 8.3  | Explains that each concrete value passed through any requires a heap allocation for boxing                    | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 8.4  | Does NOT focus only on the type switch as the optimization target                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **9. backing-array-leak-slice** — Tests backing array retention when returning a small reslice                | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 9.1  | Identifies that message[:32] retains the entire backing array (1-10MB)                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 9.2  | Suggests using copy() to create an independent 32-byte slice                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 9.3  | Explains that the original large array cannot be GC'd while the reslice exists                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 9.4  | Provides correct copy-based fix: make([]byte, 32) + copy(header, message[:32])                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **10. substring-memory-leak** — Tests strings.Clone pattern for substring memory leaks                        | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                                      |
+| 10.1 | Identifies that substrings share the backing array of the original string                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 10.2 | Suggests strings.Clone(line[12:48]) to create an independent copy                                             | <span class="g">✓</span>       | <span class="r">✗</span> suggests string([]byte(s))                 |
+| 10.3 | Explains that each 36-char ID retains the entire 500-2000 byte log line                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **11. map-never-shrinks** — Tests Go maps never release bucket memory and compact pattern                     | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 11.1 | Explains that Go maps never release bucket memory when entries are deleted                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 11.2 | Suggests periodically recreating the map by copying entries to a new map                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 11.3 | Provides the compact pattern: make(map[K]V, len(old)) + range copy                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 11.4 | Does NOT suggest that calling runtime.GC() or tuning GOGC will fix this                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **12. sync-pool-rules** — Tests proper sync.Pool usage: reset, size limits, pointer pooling                   | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                      |
+| 12.1 | Identifies that HandleLargeUpload puts oversized buffers (100MB+) back into the pool                          | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 12.2 | Mentions the 32KB guideline — don't pool objects larger than ~32KB                                            | <span class="g">✓</span>       | <span class="r">✗</span> vague size advice                          |
+| 12.3 | Identifies that w.Write(buf) may retain the buffer after bufPool.Put(buf)                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 12.4 | Suggests pooling pointers (*[]byte) instead of values to avoid allocation on Get                              | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 12.5 | Recommends resetting/clearing state before Put                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **13. struct-field-alignment** — Tests struct field ordering for optimal memory layout                        | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                      |
+| 13.1 | Identifies that the struct has wasted padding bytes due to alignment                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 13.2 | Suggests reordering fields from largest to smallest                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 13.3 | Provides a reordered struct that is smaller than the original                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 13.4 | Mentions the fieldalignment tool for automated detection                                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 13.5 | States alignment requirements (bool=1, int32=4, int64/float64=8)                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **14. zero-size-field-end-of-struct** — Tests struct{} at end of struct adds word-sized padding               | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                                      |
+| 14.1 | Explains that a zero-size field at the end of a struct causes word-sized padding                              | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 14.2 | Explains the reason: preventing pointer overlap with next memory block                                        | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 14.3 | Suggests moving struct{} to the beginning of the struct                                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 14.4 | Shows the fix: type Entry struct { Flag struct{}; Value int64 } = 8 bytes                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **15. map-pointer-vs-value-tradeoff** — Tests map[K]*V vs map[K]V tradeoff for large structs                  | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                      |
+| 15.1 | Suggests using map[string]*Player to allow direct field modification                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 15.2 | Explains that map values are not addressable                                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 15.3 | Shows players[id].Score += delta with pointer map                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 15.4 | Mentions the tradeoff: pointer maps add GC pressure from separate heap allocations                            | <span class="g">✓</span>       | <span class="r">✗</span> no GC tradeoff                             |
+| 15.5 | Notes that for small, mostly-read structs, map[K]V (value) is better                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **16. inlining-log-in-hot-path** — Tests that log calls prevent function inlining                             | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                      |
+| 16.1 | Identifies that log calls prevent the function from being inlined                                             | <span class="g">✓</span>       | <span class="r">✗</span> focuses on formatting cost                 |
+| 16.2 | Suggests removing log calls from the hot-path function                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 16.3 | Mentions using go build -gcflags="-m" to verify inlining decisions                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 16.4 | Explains that function call overhead matters when called millions of times                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **17. value-receiver-inlining** — Tests value receivers enable inlining for fluent chains                     | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                                      |
+| 17.1 | Suggests changing to value receivers instead of pointer receivers                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 17.2 | Explains that value receivers allow the compiler to inline the fluent chain                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 17.3 | Explains that pointer receivers add indirection that blocks inlining                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 17.4 | Shows the value receiver signature: func (c Config) WithTimeout(d time.Duration) Config                       | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **18. cache-locality-matrix-traversal** — Tests row-major vs column-major traversal and cache effects         | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                      |
+| 18.1 | Identifies the column-first traversal as the cause (cache misses)                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 18.2 | Explains that Go stores 2D arrays in row-major order                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 18.3 | Suggests swapping loop order to row-first                                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 18.4 | Mentions the performance difference from cache effects (10-50x or similar)                                    | <span class="g">✓</span>       | <span class="r">✗</span> says "significant" without quantifying     |
+| 18.5 | Does NOT primarily suggest parallelism or SIMD as the first fix                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **19. contiguous-2d-allocation** — Tests contiguous 2D allocation for cache-friendly matrix access            | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 19.1 | Identifies that per-row allocation scatters data across the heap                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 19.2 | Suggests single contiguous allocation: make([]float64, rows*cols)                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 19.3 | Shows slicing the contiguous array into row views: data[i*cols : (i+1)*cols]                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 19.4 | Explains that contiguous memory improves cache locality                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **20. soa-vs-aos** — Tests Struct of Arrays vs Array of Structs for single-field iteration                    | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                                      |
+| 20.1 | Identifies that loading entire Particle structs wastes cache space when only X is needed                      | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 20.2 | Suggests Struct of Arrays (SoA) layout with separate slices                                                   | <span class="g">✓</span>       | <span class="r">✗</span> suggests parallelism                       |
+| 20.3 | Explains cache utilization improvement (contiguous X values vs scattered)                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 20.4 | Notes that AoS is fine when accessing all fields together or for small structs                                | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **21. false-sharing-concurrent-counters** — Tests false sharing and cache-line padding                        | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                                      |
+| 21.1 | Identifies false sharing as the cause (fields share same cache line)                                          | <span class="g">✓</span>       | <span class="r">✗</span> suggests mutex or sharding                 |
+| 21.2 | Explains that writes to one field invalidate the cache line for other cores                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 21.3 | Suggests cache-line padding (56-byte array between fields)                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 21.4 | Mentions the 64-byte cache line size                                                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 21.5 | Notes this should only be applied when profiling confirms contention                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **22. ilp-multi-accumulator** — Tests instruction-level parallelism with multiple accumulators                | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                                      |
+| 22.1 | Identifies the sequential dependency chain as the bottleneck                                                  | <span class="g">✓</span>       | <span class="r">✗</span> suggests goroutines or SIMD                |
+| 22.2 | Suggests using multiple accumulators (e.g., 4) for ILP                                                        | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 22.3 | Shows code with 4 independent accumulators summing every 4th element                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 22.4 | Handles the remainder elements (when len(data) is not divisible by 4)                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 22.5 | Mentions expected 2-4x improvement from ILP                                                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **23. index-based-tree-cache-locality** — Tests index-based vs pointer-based data structures                  | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 23.1 | Recommends Option B (index-based) for better cache locality                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 23.2 | Explains that pointer-based nodes are scattered across the heap                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 23.3 | Explains that index-based nodes are stored in a contiguous array                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 23.4 | Mentions CPU cache lines or memory prefetching                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **24. tight-loop-scheduler-starvation** — Tests tight CPU loops starving the Go scheduler                     | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                      |
+| 24.1 | Explains that tight CPU loops with inlined operations can delay scheduler preemption                          | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 24.2 | Suggests breaking work into batches processed by a non-inlined function call                                  | <span class="g">✓</span>       | <span class="r">✗</span> suggests runtime.Gosched()                 |
+| 24.3 | Mentions //go:noinline as an option to force preemption points                                                | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 24.4 | Explains the tradeoff: //go:noinline adds overhead but ensures scheduler fairness                             | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 24.5 | Mentions that Go 1.14+ has async preemption but tight loops can still cause issues                            | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **25. reflect-deepequal-performance** — Tests reflect.DeepEqual 50-200x slower than typed comparison          | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                      |
+| 25.1 | Identifies reflect.DeepEqual as 50-200x slower than typed comparison                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 25.2 | Suggests using slices.Equal for the Hosts field                                                               | <span class="g">✓</span>       | <span class="r">✗</span> uses manual loop                           |
+| 25.3 | Suggests using maps.Equal for the Settings field                                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 25.4 | Provides a hand-written typed comparison function                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **26. type-switch-vs-repeated-assertions** — Tests type switch dispatches in one evaluation                   | **<span class="g">3/3</span>** | **<span class="g">3/3</span>**                                      |
+| 26.1 | Suggests replacing repeated type assertions with a type switch                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 26.2 | Explains that a type switch dispatches in a single evaluation                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 26.3 | Shows the switch v := v.(type) { case string: ... } pattern                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **27. http-transport-maxidleconnsperhost** — Tests default MaxIdleConnsPerHost=2 gotcha                       | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                      |
+| 27.1 | Identifies MaxIdleConnsPerHost defaulting to 2 as the root cause                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 27.2 | Suggests configuring http.Transport with higher MaxIdleConnsPerHost                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 27.3 | Shows complete Transport configuration with MaxIdleConns, MaxIdleConnsPerHost, MaxConnsPerHost                | <span class="g">✓</span>       | <span class="r">✗</span> only sets MaxIdleConnsPerHost              |
+| 27.4 | Mentions draining resp.Body for connection reuse (io.Copy to io.Discard)                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 27.5 | Does NOT suggest a third-party connection pool library as the primary solution                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **28. response-body-drain** — Tests HTTP connections only reused when body fully read                         | **<span class="g">3/3</span>** | **<span class="g">3/3</span>**                                      |
+| 28.1 | Identifies that the response body is not being fully read/drained                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 28.2 | Explains that connections are only reused when the body is fully consumed                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 28.3 | Suggests adding io.Copy(io.Discard, resp.Body)                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **29. streaming-vs-readall** — Tests streaming vs buffering for large payloads                                | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                      |
+| 29.1 | Identifies io.ReadAll as the cause of OOM                                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 29.2 | Suggests using io.Copy(w, resp.Body) to stream with constant memory                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 29.3 | Mentions the 32KB internal buffer of io.Copy                                                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 29.4 | Notes that io.ReadAll is fine for small, bounded payloads (< 1MB)                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **30. json-streaming-decoder** — Tests json.NewDecoder for streaming large JSON payloads                      | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                                      |
+| 30.1 | Suggests using json.NewDecoder with r.Body directly                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 30.2 | Shows the dec.More() + dec.Decode(&item) streaming pattern                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 30.3 | Explains that this processes one item at a time with O(1) memory per item                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **31. cgo-overhead-tight-loop** — Tests cgo call overhead (~50-100ns) and batching strategy                   | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                      |
+| 31.1 | Identifies cgo overhead (~50-100ns per call) as the bottleneck                                                | <span class="g">✓</span>       | <span class="r">✗</span> says "overhead" without quantifying        |
+| 31.2 | Suggests using math.Sqrt (pure Go, inlineable) instead of C.sqrt                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 31.3 | For unavoidable C code, suggests batching: pass entire array to C in one call                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 31.4 | Mentions that goroutine is pinned to OS thread during cgo calls                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **32. gogc-gomemlimit-container** — Tests GOMEMLIMIT for containerized applications                           | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                      |
+| 32.1 | Recommends setting GOMEMLIMIT to 80-90% of container memory (400-450MiB)                                      | <span class="g">✓</span>       | <span class="r">✗</span> suggests GOMEMLIMIT without ratio          |
+| 32.2 | Explains that the GC needs GOMEMLIMIT to know about the container ceiling                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 32.3 | Shows the GOMEMLIMIT=450MiB environment variable or debug.SetMemoryLimit                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 32.4 | Explains the gap (goroutine stacks, OS buffers, non-heap memory)                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 32.5 | Does NOT recommend the ballast pattern (obsolete since Go 1.19)                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **33. ballast-pattern-obsolete** — Tests GOMEMLIMIT over ballast pattern                                      | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 33.1 | Identifies the ballast pattern as obsolete since Go 1.19                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 33.2 | Recommends GOMEMLIMIT as the replacement                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 33.3 | Explains that GOMEMLIMIT provides the same benefit without wasting physical memory                            | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 33.4 | Shows the GOMEMLIMIT environment variable or debug.SetMemoryLimit call                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **34. gomaxprocs-container-go125** — Tests Go 1.25+ container-aware GOMAXPROCS vs automaxprocs                | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                                      |
+| 34.1 | States that Go 1.25+ automatically detects container CPU limits                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 34.2 | Recommends removing the automaxprocs dependency                                                               | <span class="g">✓</span>       | <span class="r">✗</span> keeps automaxprocs                         |
+| 34.3 | Mentions that automaxprocs IS needed for Go 1.24 and earlier                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 34.4 | Mentions cgroup CPU quota detection as the mechanism                                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **35. pgo-workflow** — Tests PGO workflow and expected gains                                                  | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                      |
+| 35.1 | Recommends Profile-Guided Optimization (PGO)                                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 35.2 | Describes the workflow: collect profile, save as default.pgo, rebuild                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 35.3 | Mentions expected improvement of 2-7%                                                                         | <span class="g">✓</span>       | <span class="r">✗</span> no quantification                          |
+| 35.4 | Explains PGO benefits: aggressive inlining and devirtualization                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 35.5 | Notes that profiles should be refreshed after significant code changes                                        | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **36. slog-logattrs-hot-path** — Tests slog.LogAttrs for zero-allocation logging                              | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                                      |
+| 36.1 | Explains that log arguments are evaluated/boxed before the level check                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 36.2 | Recommends slog.LogAttrs for zero allocations when level is disabled                                          | <span class="g">✓</span>       | <span class="r">✗</span> suggests level check guard                 |
+| 36.3 | Shows typed attributes: slog.Int("id", item.ID), slog.String("name", item.Name)                               | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 36.4 | Notes that slog.Any can still allocate, so typed attributes are preferred                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **37. regexp-compile-per-call** — Tests compiled pattern caching vs per-call compilation                      | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                      |
+| 37.1 | Identifies that regexp compilation happens on every call (~5,700ns per compile)                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 37.2 | Suggests moving regexp.MustCompile to package-level variables                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 37.3 | Notes that compiled regexps are safe for concurrent use                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 37.4 | Quantifies the waste (10-12x overhead from recompilation vs match-only)                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **38. singleflight-cache-stampede** — Tests singleflight for cache stampede prevention                        | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 38.1 | Identifies this as a cache stampede problem                                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 38.2 | Recommends golang.org/x/sync/singleflight.Group                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 38.3 | Shows sf.Do(key, func) pattern                                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 38.4 | Does NOT suggest a global mutex as the primary solution                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **39. algorithmic-complexity-slice-contains-loop** — Tests O(n*m) from slices.Contains in loop                | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                      |
+| 39.1 | Identifies O(n*m) complexity from slices.Contains inside a loop                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 39.2 | Suggests building a map[string]struct{} from the valid slice first                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 39.3 | Shows the O(n+m) solution with map lookup                                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 39.4 | Uses struct{} (0 bytes) for the map value type, not bool                                                      | <span class="g">✓</span>       | <span class="r">✗</span> uses bool                                  |
+|      | **40. early-return-full-scan** — Tests early returns to avoid full collection scans                           | **<span class="g">3/3</span>** | **<span class="g">3/3</span>**                                      |
+| 40.1 | Identifies that the function always scans the full collection                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 40.2 | Adds an early return when the first expired session is found                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 40.3 | Removes the found variable in favor of direct returns                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **41. iterator-chain-vs-direct-loop** — Tests iterator chains create closure overhead                         | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 41.1 | Recommends Option B (direct loop) for performance                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 41.2 | Explains that iterator chains create closures and intermediate allocations                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 41.3 | Notes that Filter processes ALL elements before First can pick one                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 41.4 | Acknowledges that iterator chains are fine for non-hot paths                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **42. indirect-function-calls-closure** — Tests closure indirection prevents inlining                         | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                      |
+| 42.1 | Suggests replacing the Map+closure pattern with a direct loop                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 42.2 | Explains that the closure/function call indirection prevents inlining                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 42.3 | Shows the direct loop: result[i] = *ptrs[i]                                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 42.4 | Mentions the expected improvement range (13-17%)                                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **43. http-server-no-timeouts** — Tests zero-value http.Server has NO timeouts                                | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 43.1 | Identifies that the default http.Server has NO timeouts                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 43.2 | Mentions Slowloris attack or slow client holding connections indefinitely                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 43.3 | Suggests setting ReadTimeout, WriteTimeout, and IdleTimeout                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 43.4 | Shows creating an explicit http.Server struct with timeout values                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **44. http-keepalive-crawler** — Tests disabling keep-alive for crawlers                                      | **<span class="g">3/3</span>** | **<span class="r">1/3</span>**                                      |
+| 44.1 | Identifies that idle connections accumulate across many different hosts                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 44.2 | Suggests DisableKeepAlives: true for the crawler client                                                       | <span class="g">✓</span>       | <span class="r">✗</span> lowers MaxIdleConnsPerHost instead         |
+| 44.3 | Explains that keep-alive is counterproductive for many unique hosts                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **45. buffered-io-syscall-reduction** — Tests bufio for reducing syscall count                                | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 45.1 | Identifies that each WriteString issues a separate syscall                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 45.2 | Suggests using bufio.NewWriter(f) to batch writes                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 45.3 | Includes w.Flush() at the end                                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 45.4 | Does NOT primarily suggest strings.Builder                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **46. concurrent-pipeline-when-not-to-use** — Tests when concurrent pipelines are NOT beneficial              | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                      |
+| 46.1 | Recommends AGAINST concurrent pipelines for this case                                                         | <span class="g">✓</span>       | <span class="r">✗</span> recommends concurrency                     |
+| 46.2 | Explains that all three stages compete for the same resource (CPU)                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 46.3 | Notes that concurrency only helps when stages saturate DIFFERENT resources                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 46.4 | Mentions context-switching overhead as a cost                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 46.5 | Suggests sequential processing or batching as simpler alternative                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **47. batch-db-inserts** — Tests batch database inserts vs row-by-row                                         | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                      |
+| 47.1 | Identifies individual inserts as the problem (50K round-trips)                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 47.2 | Suggests batch inserts (multi-row VALUES or COPY protocol)                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 47.3 | Shows a batching pattern with configurable batch size                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 47.4 | Wraps batches in transactions for atomicity                                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 47.5 | Does NOT suggest only connection pooling or prepared statements                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **48. panic-recover-control-flow** — Tests panic/recover not for control flow                                 | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                      |
+| 48.1 | Identifies that panic/recover is unnecessary since strconv.Atoi returns errors                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 48.2 | Explains that panic allocates a stack trace and unwinds the stack (10-100x overhead)                          | <span class="g">✓</span>       | <span class="r">✗</span> says "overhead" without quantifying        |
+| 48.3 | Suggests using simple error checking: v, err := strconv.Atoi(s)                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 48.4 | States that panic/recover should only be used for truly unrecoverable situations                              | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **49. monotonic-time-since** — Tests time.Since monotonic clock for elapsed time                              | **<span class="g">3/3</span>** | **<span class="g">3/3</span>**                                      |
+| 49.1 | Suggests using time.Since(start) for elapsed time measurement                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 49.2 | Explains that time.Since uses the monotonic clock                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 49.3 | Notes that time.Now() already captures monotonic time for Sub() operations                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **50. prometheus-gc-pressure-queries** — Tests specific PromQL queries for GC pressure                        | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                                      |
+| 50.1 | Provides rate(go_gc_duration_seconds_count[5m]) for GC frequency                                              | <span class="g">✓</span>       | <span class="r">✗</span> generic approach                           |
+| 50.2 | Provides go_gc_duration_seconds{quantile="1"} for worst-case GC pause                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 50.3 | Mentions >2 cycles/s sustained as a signal of excessive allocation rate                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 50.4 | Suggests rate(go_memstats_alloc_bytes_total[5m]) for allocation rate                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **51. goroutine-leak-prometheus** — Tests PromQL for detecting goroutine leaks                                | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                                      |
+| 51.1 | Provides go_goroutines metric for goroutine count monitoring                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 51.2 | Suggests delta(go_goroutines[1h]) for detecting net goroutine increase                                        | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 51.3 | Notes that goroutine count should correlate with load                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **52. continuous-profiling-tools** — Tests continuous profiling tools and tradeoffs                           | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                      |
+| 52.1 | Recommends Grafana Pyroscope, Parca, or similar platform                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 52.2 | Mentions overhead estimates (1-5% range)                                                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 52.3 | Describes push vs pull collection modes                                                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 52.4 | Mentions historical flamegraph comparison as a key feature                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 52.5 | Suggests feeding profiles into PGO for build optimization                                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **53. gogc-high-vs-low-tradeoff** — Tests GOGC tuning tradeoffs (latency vs throughput)                       | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 53.1 | Recommends lower GOGC (e.g., 50) for Service A (latency-sensitive)                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 53.2 | Recommends higher GOGC (e.g., 200) for Service B (throughput-oriented)                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 53.3 | Explains the tradeoff: lower GOGC = more frequent but shorter pauses                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 53.4 | Explains the tradeoff: higher GOGC = less frequent GC but more memory                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **54. godebug-gctrace** — Tests GODEBUG=gctrace=1 output interpretation                                       | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                      |
+| 54.1 | Correctly identifies gc 142 as the 142nd GC cycle                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 54.2 | Identifies 12% as total CPU time spent in GC (which is high)                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 54.3 | Interprets 180->340->200 MB as heap before, peak during, and after collection                                 | <span class="g">✓</span>       | <span class="r">✗</span> misparses the three values                 |
+| 54.4 | Identifies 400 MB goal as the target heap size based on GOGC/GOMEMLIMIT                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 54.5 | Notes that 12% GC CPU is concerning                                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **55. unsafe-without-benchmark-proof** — Tests warning against premature unsafe usage                         | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                      |
+| 55.1 | Recommends against using unsafe here                                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 55.2 | Notes that 100 req/s is not a hot path                                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 55.3 | States that unsafe requires benchmark proof showing >10% improvement                                          | <span class="g">✓</span>       | <span class="r">✗</span> no specific threshold                      |
+| 55.4 | Mentions safety risks of unsafe                                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **56. precomputed-lookup-table** — Tests precomputed lookup tables for pure functions                         | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                                      |
+| 56.1 | Suggests a precomputed lookup table (var hexDigit = [16]byte{...})                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 56.2 | Shows the table lookup: hexDigit[b>>4], hexDigit[b&0x0f]                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 56.3 | Explains that the lookup table fits in L1 cache and is faster than branching                                  | <span class="g">✓</span>       | <span class="r">✗</span> says "faster" without L1 cache explanation |
+|      | **57. json-performance-alternatives** — Tests JSON performance alternatives                                   | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                      |
+| 57.1 | Mentions custom MarshalJSON/UnmarshalJSON methods                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 57.2 | Mentions code-generation libraries (easyjson, ffjson)                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 57.3 | Mentions drop-in replacement libraries (goccy/go-json, json-iterator, sonic)                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 57.4 | Explains that encoding/json uses reflection                                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 57.5 | Quantifies expected improvement (2-5x or similar)                                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **58. channel-batch-processing** — Tests batch processing from channels with timeout flush                    | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                      |
+| 58.1 | Uses select with both channel receive and ticker/timer for timeout                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 58.2 | Flushes on batch size threshold                                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 58.3 | Flushes on timeout (ticker)                                                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 58.4 | Handles channel close (flushes remaining items)                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 58.5 | Reuses the batch slice (batch[:0]) to reduce allocations                                                      | <span class="g">✓</span>       | <span class="r">✗</span> re-allocates                               |
+|      | **59. allocation-reduction-vs-gc-tuning** — Tests that reducing allocations beats GOGC tuning                 | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                                      |
+| 59.1 | Recommends reducing allocations as the primary approach over GOGC tuning                                      | <span class="g">✓</span>       | <span class="r">✗</span> suggests GOGC tuning first                 |
+| 59.2 | Explains that GOGC tuning manages the symptom while allocation reduction addresses root cause                 | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 59.3 | Suggests specific allocation reduction strategies                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 59.4 | Acknowledges GOGC tuning as a secondary measure after allocation reduction                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **60. gctrace-key-fields** — Tests what to monitor in GC traces                                               | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                      |
+| 60.1 | Mentions high GC frequency as a signal of too many allocations                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 60.2 | Mentions high pause times as a signal of large heap or many pointers                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 60.3 | Mentions high GC CPU% (>5%) as concerning                                                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 60.4 | Provides the GODEBUG=gctrace=1 command                                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **61. non-go-memory-leak-detection** — Tests detecting non-Go memory leaks via Prometheus                     | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                      |
+| 61.1 | Suggests process_resident_memory_bytes - go_memstats_sys_bytes to isolate non-Go memory                       | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 61.2 | Identifies this as a likely C/cgo memory leak                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 61.3 | Explains that growing gap between RSS and Go sys bytes indicates non-Go memory growth                         | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 61.4 | Suggests C-level memory profiling tools (valgrind, AddressSanitizer)                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **62. cpu-saturation-prometheus** — Tests detecting CPU saturation via Prometheus                             | **<span class="g">3/3</span>** | **<span class="r">1/3</span>**                                      |
+| 62.1 | Provides rate(process_cpu_seconds_total[5m]) for CPU cores consumed                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 62.2 | Divides by GOMAXPROCS to get utilization ratio                                                                | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 62.3 | States that >0.8 sustained indicates CPU saturation                                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **63. document-optimizations** — Tests recommending documentation of optimizations                            | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                                      |
+| 63.1 | Strongly recommends adding comments explaining WHY the optimization was made                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 63.2 | Suggests including benchmark numbers in the comments                                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 63.3 | Explains that future readers may revert optimizations they don't understand                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **64. lru-cache-freelru** — Tests high-performance LRU cache alternatives                                     | **<span class="g">3/3</span>** | **<span class="r">0/3</span>**                                      |
+| 64.1 | Notes that container/list has poor cache locality (separate heap allocation per node)                         | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 64.2 | Recommends elastic/go-freelru or hashicorp/golang-lru as alternatives                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 64.3 | Mentions the performance advantage of contiguous memory layouts for LRU                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+|      | **65. simd-when-not-worth** — Tests when SIMD is NOT worth pursuing                                           | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                      |
+| 65.1 | Recommends against SIMD for this case                                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 65.2 | Explains that the bottleneck is allocations/GC, not CPU-bound computation                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 65.3 | States that SIMD only helps CPU-bound numeric inner loops                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 65.4 | Suggests reducing allocations as the correct approach                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **66. set-map-struct-zero-size** — Tests struct{} vs bool for set maps                                        | **<span class="g">2/2</span>** | **<span class="g">2/2</span>**                                      |
+| 66.1 | Recommends struct{} for set maps                                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 66.2 | Explains that struct{} is 0 bytes vs bool at 1 byte per entry                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **67. regression-detection-prometheus** — Tests PromQL for deployment regression detection                    | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                                      |
+| 67.1 | Suggests comparing rate(go_memstats_alloc_bytes_total[5m]) before/after deploy                                | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 67.2 | Suggests monitoring p99 latency histogram_quantile for increase after deploy                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+| 67.3 | Mentions comparing metrics between old and new deployment versions                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                            |
+|      | **68. statsviz-development-profiling** — Tests real-time development visualization tools                      | **<span class="g">3/3</span>** | **<span class="r">0/3</span>**                                      |
+| 68.1 | Recommends statsviz (github.com/arl/statsviz) for real-time browser visualization                             | <span class="g">✓</span>       | <span class="r">✗</span> suggests pprof web UI                      |
+| 68.2 | Mentions the /debug/statsviz endpoint or statsviz.Register pattern                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+| 68.3 | Notes that it shows heap, GC pauses, goroutines, and scheduler in real-time                                   | <span class="g">✓</span>       | <span class="r">✗</span>                                            |
+
+</details>
+
+## `golang-troubleshooting` — v1.0.0
+
+|             | With Skill         | Without Skill     | Delta     |
+| ----------- | ------------------ | ----------------- | --------- |
+| **Overall** | **186/186 (100%)** | **127/186 (68%)** | **+32pp** |
+
+<details>
+<summary>Full breakdown (186 assertions across 37 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                                                  | With                           | Without                                                        |
+| ---- | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | -------------------------------------------------------------- |
+|      | **1. reproduce-before-fix-failing-test-first** — Model must write a failing test before proposing any fix                  | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                 |
+| 1.1  | Writes a failing test (or proposes writing one) BEFORE suggesting any code fix                                             | <span class="g">✓</span>       | <span class="r">✗</span> jumps to adding error handling        |
+| 1.2  | Test covers multiple input variations to identify which inputs trigger the 500                                             | <span class="g">✓</span>       | <span class="r">✗</span> single fix without test               |
+| 1.3  | Does NOT propose a fix without first understanding/reproducing the root cause                                              | <span class="g">✓</span>       | <span class="r">✗</span> proposes nil check immediately        |
+| 1.4  | Asks clarifying questions about the error (logs, request bodies, frequency) or proposes to gather evidence                 | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 1.5  | Mentions running the test to confirm it reproduces the issue before fixing                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **2. one-hypothesis-at-a-time** — Change one thing and measure, not multiple simultaneous changes                          | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                 |
+| 2.1  | Refuses or strongly advises against making all three changes simultaneously                                                | <span class="g">✓</span>       | <span class="r">✗</span> applies all three as requested        |
+| 2.2  | Recommends measuring/profiling first to identify which problem is actually causing the symptoms                            | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 2.3  | Suggests testing one hypothesis at a time with measurement between changes                                                 | <span class="g">✓</span>       | <span class="r">✗</span> bundles changes                       |
+| 2.4  | Mentions pprof, benchmarks, or race detector as diagnostic tools to identify the real bottleneck                           | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 2.5  | Explains why multiple simultaneous changes are harmful (can't tell what worked, may introduce new bugs)                    | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+|      | **3. root-cause-not-symptom-fix** — Fix at the source where bad data originates, not where the panic occurs                | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 3.1  | Identifies that the nil check in the handler is a symptom fix, not the root cause                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 3.2  | Traces backward to the constructor/initialization code to find why db is nil                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 3.3  | Suggests validating db != nil in the constructor (e.g., NewServer) and failing fast there                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 3.4  | Does NOT suggest improving the nil check in the handler as the primary fix                                                 | <span class="g">✓</span>       | <span class="r">✗</span> improves the nil check response       |
+| 3.5  | Explains that fixing at the symptom location masks the real bug                                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+|      | **4. interface-nil-gotcha** — Typed nil in interface is not nil                                                            | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 4.1  | Identifies the interface nil gotcha: a typed nil *ValidationError wrapped in an error interface is NOT a nil interface     | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 4.2  | Explains that the interface has a non-nil type descriptor even when the pointer value is nil                               | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 4.3  | Recommends returning nil explicitly (return nil) instead of returning the typed nil variable                               | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 4.4  | Does NOT suggest adding an if verr == nil check before return as the primary fix                                           | <span class="g">✓</span>       | <span class="r">✗</span> suggests if verr == nil check         |
+| 4.5  | Shows or describes the correct fix: check verr != nil before return, and return nil in the else branch                     | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **5. variable-shadowing-err** — Inner err shadows outer err                                                                | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 5.1  | Identifies that := inside the if block creates a NEW err variable that shadows the outer one                               | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 5.2  | Explains that the outer err remains nil because the inner := never assigned to it                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 5.3  | Recommends using = (assignment) instead of := to assign to the outer err variable                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 5.4  | Shows the fix: declare result separately (var result ResultType) and use result, err = someFunc()                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 5.5  | Mentions go vet -shadow or shadow analyzer as a detection tool                                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+|      | **6. defer-in-loop-resource-leak** — Deferred calls pile up until function returns                                         | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 6.1  | Identifies that defer f.Close() inside a for loop keeps all files open until the function returns                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 6.2  | Recommends wrapping the loop body in an anonymous function (closure) so defer runs each iteration                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 6.3  | Does NOT suggest increasing ulimit or file descriptor limits as the primary solution                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 6.4  | Shows the correct pattern with func() { f, err := os.Open(...); defer f.Close(); ... }()                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 6.5  | Alternatively suggests extracting the loop body into a named function                                                      | <span class="g">✓</span>       | <span class="r">✗</span> only shows closure                    |
+|      | **7. break-in-select-inside-for-loop** — Bare break only exits select, not the enclosing for loop                          | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 7.1  | Identifies that break inside a select only exits the select statement, not the for loop                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 7.2  | Recommends using a labeled break (e.g., break loop) with a label on the for statement                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 7.3  | Shows the correct pattern with a label like 'loop:' on the for statement and 'break loop' inside select                    | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 7.4  | Also fixes the ctx.Done() case which has the same break issue                                                              | <span class="g">✓</span>       | <span class="r">✗</span> only fixes the quit case              |
+| 7.5  | Alternatively mentions return as a solution if the function should exit entirely                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **8. concurrent-map-fatal-not-panic** — Concurrent map access is fatal and unrecoverable                                   | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 8.1  | Explains that concurrent map read/write is a FATAL error that cannot be caught by recover()                                | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 8.2  | Distinguishes this from regular panics — the Go runtime kills the process immediately                                      | <span class="g">✓</span>       | <span class="r">✗</span> treats it as a regular panic          |
+| 8.3  | Recommends protecting the map with sync.RWMutex or using sync.Map                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 8.4  | Recommends using go test -race to find the race condition                                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 8.5  | Does NOT suggest fixing the recover middleware as the solution                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **9. waitgroup-add-inside-goroutine** — Add inside goroutine races with Wait                                               | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 9.1  | Identifies that wg.Add(1) is called inside the goroutine instead of before it                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 9.2  | Explains that wg.Wait() may return before all goroutines have called wg.Add(1)                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 9.3  | Recommends moving wg.Add(1) before the go func() call                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 9.4  | Notes this is a race condition that passes most of the time but fails intermittently                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 9.5  | Does NOT focus primarily on the mutex/slice synchronization as the root cause                                              | <span class="g">✓</span>       | <span class="r">✗</span> discusses mutex issues equally        |
+|      | **10. missing-return-after-http-error** — Missing return after http.Error()                                                | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 10.1 | Identifies the missing return statement after http.Error(w, 'Forbidden', http.StatusForbidden)                             | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 10.2 | Explains that http.Error() does NOT stop handler execution — it only writes to the ResponseWriter                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 10.3 | Adds return statements after each http.Error() call                                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 10.4 | Does NOT primarily blame the isAuthorized function                                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 10.5 | Mentions this is a common Go bug pattern and a security concern                                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+|      | **11. json-numbers-float64-interface** — Numbers into interface{} become float64                                           | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 11.1 | Explains that JSON numbers unmarshaled into interface{} become float64, not int or int64                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 11.2 | Notes that large integers (> 2^53) silently lose precision when stored as float64                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 11.3 | Recommends using a typed struct with int64 field as the preferred solution                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 11.4 | Alternatively mentions json.NewDecoder with UseNumber() and json.Number for when interface{} is required                   | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 11.5 | Explains the type assertion panics because the actual type is float64, not int64                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **12. strings-trim-vs-trimprefix** — Trim treats argument as character set                                                 | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 12.1 | Explains that strings.Trim treats its second argument as a SET of characters to strip, not as a substring                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 12.2 | Shows why 'json' becomes 'js' — the characters j, o, n are in the set {a,p,l,i,c,t,o,n,/}                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 12.3 | Recommends strings.TrimPrefix for removing a substring prefix                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 12.4 | Mentions strings.TrimSuffix for removing suffixes                                                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 12.5 | Confirms this is NOT a Go bug — it's working as documented                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **13. closed-channel-busy-loop-in-select** — Closed channel in select causes busy loop                                     | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 13.1 | Identifies that a closed channel always returns immediately (zero value) in a select case                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 13.2 | Explains this causes the select case to fire continuously — a busy loop burning CPU                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 13.3 | Recommends using the comma-ok idiom (job, ok := <-ch) and nil-ing the channel when closed (ch = nil)                       | <span class="g">✓</span>       | <span class="r">✗</span> suggests only break/return            |
+| 13.4 | Explains that a nil channel blocks forever in select, effectively disabling that case                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 13.5 | Does NOT suggest adding a default case with time.Sleep as the fix                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **14. select-default-spin-loop** — Select with default inside for loop is a busy-wait                                      | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 14.1 | Identifies that select with default inside a for loop is a busy-wait spin loop                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 14.2 | Explains that default runs immediately when no channel is ready, creating a tight loop                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 14.3 | Recommends removing the default case and using a second channel or context for the stop signal                             | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 14.4 | Alternatively suggests adding a time.Sleep or ticker in the default to yield CPU if non-blocking is truly required         | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 14.5 | Shows a solution using a ctx.Done() or stop channel in a second select case                                                | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+|      | **15. enum-zero-value-iota-ambiguity** — Iota starting at 0 makes zero value ambiguous                                     | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 15.1 | Identifies that iota starting at 0 makes the zero value (default for uninitialized fields) equal to Admin                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 15.2 | Recommends reserving 0 for an Unknown/Unspecified sentinel value                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 15.3 | Shows the pattern: RoleUnknown Role = iota, then Admin, Editor, Viewer                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 15.4 | Explains this applies to any enum — zero value should be the 'unset' state, not a valid value                              | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 15.5 | Does NOT primarily suggest fixing it in the constructor or registration logic                                              | <span class="g">✓</span>       | <span class="r">✗</span> suggests constructor fix              |
+|      | **16. recover-only-same-goroutine** — recover() goroutine boundary                                                         | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 16.1 | Explains that recover() can ONLY catch panics in the same goroutine where it is deferred                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 16.2 | States that a panic in a child goroutine will crash the entire program regardless of parent recovery                       | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 16.3 | Recommends adding defer/recover inside the child goroutine (processAsync or its wrapper)                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 16.4 | Shows the pattern: go func() { defer func() { if r := recover()... }(); processAsync(...) }()                              | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 16.5 | Does NOT suggest reconfiguring the parent middleware as the solution                                                       | <span class="g">✓</span>       | <span class="r">✗</span> also discusses middleware changes     |
+|      | **17. os-exit-skips-defers** — log.Fatal calls os.Exit which skips deferred functions                                      | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 17.1 | Identifies that log.Fatal (or log.Fatalf) calls os.Exit(1) internally                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 17.2 | Explains that os.Exit skips all deferred functions — cleanup never runs                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 17.3 | Recommends restructuring to avoid log.Fatal — use a run() function pattern or return errors                                | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 17.4 | Shows the pattern: move logic into a run() error function, call os.Exit in main only after run returns                     | <span class="g">✓</span>       | <span class="r">✗</span> suggests cleanup before Fatal instead |
+| 17.5 | Does NOT suggest explicitly calling os.Remove before log.Fatal as the primary fix                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **18. time-equal-not-double-equals** — time.Time == vs .Equal()                                                            | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 18.1 | Identifies that time.Now() includes a monotonic clock reading that database serialization strips                           | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 18.2 | Explains that == compares all fields including the monotonic component, so it can fail for equal instants                  | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 18.3 | Recommends using .Equal() which ignores the monotonic clock                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 18.4 | Alternatively mentions t.Round(0) to strip the monotonic reading before comparison or storage                              | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 18.5 | Does NOT primarily blame database precision or timezone differences                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **19. sql-rows-must-be-closed** — Missing rows.Close() leaks connections                                                   | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 19.1 | Identifies the missing defer rows.Close() after the error check                                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 19.2 | Explains that unclosed sql.Rows holds the database connection until garbage collection                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 19.3 | Adds defer rows.Close() immediately after the err check                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 19.4 | Also notes the missing rows.Err() check after the loop                                                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 19.5 | Does NOT primarily suggest increasing connection pool size                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **20. copying-sync-types-value-receiver** — Value receiver copies sync types                                               | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 20.1 | Identifies that value receivers (c Counter) copy the entire struct including the Mutex on every call                       | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 20.2 | Explains that each call operates on a copy — increments are lost and the mutex is duplicated                               | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 20.3 | Recommends changing to pointer receivers (c *Counter)                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 20.4 | Notes that go vet can detect copied sync types                                                                             | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 20.5 | Explains this applies to ALL sync types (Mutex, RWMutex, WaitGroup, Once, etc.)                                            | <span class="g">✓</span>       | <span class="r">✗</span> only discusses Mutex                  |
+|      | **21. pprof-production-security** — Never expose pprof unauthenticated                                                     | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                 |
+| 21.1 | Warns that pprof endpoints MUST be protected — never exposed publicly without authentication                               | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 21.2 | Recommends basic auth or similar authentication on pprof endpoints                                                         | <span class="g">✓</span>       | <span class="r">✗</span> suggests separate port only           |
+| 21.3 | Suggests running pprof on a separate port (not the main HTTP port) or localhost only                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 21.4 | Recommends toggling pprof via an environment variable (e.g., PPROF_ENABLED)                                                | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 21.5 | Explains the risk: pprof leaks goroutine stacks, memory contents, and can be used for DoS                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+|      | **22. godebug-gc-tracing-interpretation** — GODEBUG gctrace output interpretation                                          | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 22.1 | Identifies that 18% GC CPU overhead is significantly high (threshold is >10%)                                              | <span class="g">✓</span>       | <span class="r">✗</span> notes 18% but no threshold            |
+| 22.2 | Explains the heap size breakdown: 1024MB before mark, 900MB after mark, 500MB after sweep                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 22.3 | Identifies the large pause times (45ms) as a likely cause of the latency spikes                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 22.4 | Suggests the application is over-allocating and recommends investigating allocation patterns                               | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 22.5 | Recommends using pprof heap/alloc profiling to find hot allocation sites                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **23. research-codebase-not-just-diff** — Trace callers and check upstream validation before flagging                      | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 23.1 | Recommends checking the callers first before flagging the bug                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 23.2 | Suggests using Grep or similar to find all call sites of getItem                                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 23.3 | Notes that upstream code may validate the id (e.g., parsing from uint, bounds checking, positive-only input)               | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 23.4 | Advises that if callers validate, the severity is reduced but may still warrant a defensive check                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 23.5 | Mentions adding an inline comment documenting the assumption if upstream guarantees exist                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **24. flaky-test-diagnosis-methodology** — Systematic flaky test debugging                                                 | **<span class="g">6/6</span>** | **<span class="g">4/6</span>**                                 |
+| 24.1 | Recommends running with -count=100 to reproduce locally                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 24.2 | Suggests using -shuffle=on to check for test order dependence                                                              | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 24.3 | Mentions running with -race to check for data races                                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 24.4 | Suggests using t.TempDir() instead of shared temp directories to avoid file system pollution                               | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 24.5 | Considers shared mutable state between tests as a potential cause                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 24.6 | Does NOT suggest retry logic or skipping the test as a solution                                                            | <span class="g">✓</span>       | <span class="r">✗</span> mentions retry as option              |
+|      | **25. defense-in-depth-after-fix** — Multi-layer defense after fixing a bug                                                | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 25.1 | Recommends validating at the entry point (API boundary) — reject paths with .. early                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 25.2 | Recommends adding a test that specifically verifies the path traversal is blocked                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 25.3 | Suggests adding logging or metrics to detect future traversal attempts (observability)                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 25.4 | Considers multiple validation layers — not just one check                                                                  | <span class="g">✓</span>       | <span class="r">✗</span> focuses on single check               |
+| 25.5 | Mentions that filepath.Join does not prevent path traversal by itself (common misconception)                               | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **26. escalation-protocol-three-failed-attempts** — After 3 failed attempts, question architecture                         | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                 |
+| 26.1 | Recognizes the pattern of cascading failures as a red flag — each fix reveals a new problem                                | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 26.2 | Recommends stepping back to question the overall design/architecture rather than trying another fix                        | <span class="g">✓</span>       | <span class="r">✗</span> suggests specific fixes               |
+| 26.3 | Suggests re-reading the code from scratch with fresh eyes                                                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 26.4 | Considers whether the current abstraction is fundamentally sound                                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 26.5 | Does NOT immediately suggest a 5th specific patch to the existing code                                                     | <span class="g">✓</span>       | <span class="r">✗</span> suggests dedup + pool fix             |
+|      | **27. git-bisect-for-regression** — Using git bisect to find breaking commit                                               | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 27.1 | Recommends git bisect to binary-search for the breaking commit                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 27.2 | Shows the git bisect start / git bisect bad / git bisect good workflow                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 27.3 | Mentions that bisect can be automated with a test command (git bisect run go test -run TestBroken ./...)                   | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 27.4 | Notes this narrows 50 commits to ~6 steps (log2(50))                                                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 27.5 | Does NOT suggest manually reading all 50 commit diffs                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **28. check-external-dependencies-first** — Verify external components before assuming code bug                            | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 28.1 | Suggests checking the external payment service health/status first (curl, health endpoint)                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 28.2 | Recommends checking DNS resolution (dig or nslookup)                                                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 28.3 | Suggests checking network connectivity (nc, telnet, or similar to the port)                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 28.4 | Considers environment-specific causes: expired credentials, DNS changes, firewall rules, certificate rotation              | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 28.5 | Does NOT start by investigating Go code since nothing changed in the codebase                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **29. observability-tools-before-code-dive** — Check observability data before diving into code                            | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 29.1 | Recommends checking monitoring/observability tools BEFORE diving into code                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 29.2 | Asks what monitoring tools are available (Prometheus, Datadog, Sentry, ELK, etc.)                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 29.3 | Suggests checking error rate metrics, latency dashboards, or log aggregation                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 29.4 | Mentions specific things to look for: what changed 2 hours ago (deploy, config change, traffic spike)                      | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 29.5 | Does NOT immediately start reading source code files                                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **30. integer-conversion-silent-truncation** — Go integer conversions silently truncate                                    | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 30.1 | Explains that Go integer conversions silently truncate without any error or warning                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 30.2 | Shows bounds checking before conversion: compare against math.MinInt32 and math.MaxInt32                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 30.3 | Returns an error when the value overflows instead of silently truncating                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 30.4 | Notes there is no built-in safe conversion function — you must check bounds manually                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 30.5 | Mentions this is especially dangerous for external/user-provided data                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **31. init-ordering-fragile** — init() ordering across files is fragile                                                    | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 31.1 | Confirms that init() ordering across files depends on filename alphabetical order and can change when files are added      | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 31.2 | Explains this makes init() dependencies fragile and hard to debug                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 31.3 | Recommends replacing init() with explicit initialization in main()                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 31.4 | Shows the pattern: cfg := loadConfig(); db := setupDatabase(cfg); startServer(db)                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 31.5 | States init() should only be used for truly self-contained setup (registering drivers, codecs)                             | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+|      | **32. goroutine-leak-detection-methodology** — Goroutine leaks as cause of slow memory growth                              | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 32.1 | Suggests checking goroutine count (runtime.NumGoroutine or pprof goroutine profile)                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 32.2 | Explains that goroutine leaks cause slow memory growth without appearing in heap profiles                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 32.3 | Recommends using the pprof goroutine endpoint with ?debug=2 for human-readable stack dumps                                 | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 32.4 | Lists common causes: unclosed channels, missing context cancellation, forgotten response body close                        | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 32.5 | Suggests goleak for detection in tests                                                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **33. production-capture-before-restart** — Capture profiles BEFORE restarting                                             | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 33.1 | Recommends capturing profiles (heap, goroutine, CPU) BEFORE restarting                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 33.2 | Explains that restarting destroys the evidence needed to diagnose the root cause                                           | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 33.3 | Lists specific profiles to capture: heap, goroutine dump (?debug=2), CPU (30s), mutex                                      | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 33.4 | Also suggests capturing system metrics (file descriptors, socket state, process info)                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 33.5 | Only after capturing all evidence should the service be restarted if needed                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **34. lock-contention-diagnosis** — runtime.semacquire indicates lock contention                                           | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 34.1 | Identifies runtime.semacquire as a signal of lock contention, not CPU computation                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 34.2 | Recommends enabling mutex profiling with runtime.SetMutexProfileFraction(1)                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 34.3 | Recommends enabling block profiling with runtime.SetBlockProfileRate(1)                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 34.4 | Suggests using pprof mutex and block profiles to find the contended locks                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 34.5 | Lists solutions: reduce critical section, sharding, RWMutex, atomic operations                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **35. race-detector-not-reasoning** — Never reason about concurrency, use the race detector                                | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 35.1 | Does NOT conclude safety based on code reasoning alone                                                                     | <span class="g">✓</span>       | <span class="r">✗</span> reasons about field layout            |
+| 35.2 | Recommends running go test -race to verify — never trust visual inspection for concurrency                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 35.3 | Identifies that ++ is not atomic — RequestCount++ and ErrorCount++ are read-modify-write operations                        | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 35.4 | Recommends using atomic.Int64 or sync.Mutex to protect the fields                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 35.5 | Notes that even different fields on the same struct can race if accessed from different goroutines without synchronization | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **36. filepath-join-path-traversal** — filepath.Join does not prevent path traversal                                       | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                 |
+| 36.1 | Identifies that filepath.Join does NOT prevent path traversal                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 36.2 | Shows that input like '../../etc/passwd' resolves to '/etc/passwd' after Join                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 36.3 | Recommends verifying the result has the base directory as a prefix after Join                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 36.4 | Shows a safe pattern: filepath.Clean + strings.HasPrefix check                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 36.5 | Notes the path separator must be appended to the base to prevent partial prefix matches                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+|      | **37. time-after-in-loop-memory-leak** — time.After in loop creates timer leak                                             | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 37.1 | Identifies that time.After creates a new timer on every loop iteration that isn't garbage collected until it fires         | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 37.2 | Explains this causes a memory leak proportional to the message rate                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 37.3 | Recommends using time.NewTimer with Reset() or time.NewTicker instead                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 37.4 | Shows the correct pattern with a reusable timer and defer timer.Stop()                                                     | <span class="g">✓</span>       | <span class="r">✗</span>                                       |
+| 37.5 | Does NOT suggest heap profiling as the first diagnostic step for this known pattern                                        | <span class="g">✓</span>       | <span class="r">✗</span> suggests heap profile first           |
+
+</details>
+
+## `golang-design-patterns` — v1.0.0
+
+|             | With Skill       | Without Skill   | Delta     |
+| ----------- | ---------------- | --------------- | --------- |
+| **Overall** | **87/87 (100%)** | **55/87 (63%)** | **+37pp** |
+
+<details>
+<summary>Full breakdown (87 assertions across 18 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                           | With                           | Without                                                       |
+| ---- | --------------------------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------- |
+|      | **1. functional-options-over-builder** — constructor API for HTTP server with growing config        | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                |
+| 1.1  | Uses functional options pattern (Option type as func that modifies the struct)                      | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 1.2  | Constructor accepts variadic ...Option parameter                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 1.3  | Each option is a With* function returning an Option                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 1.4  | Sets sensible defaults inside the constructor before applying options                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 1.5  | Mentions that functional options should return an error if validation can fail                      | <span class="g">✓</span>       | <span class="r">✗</span> no error-returning variant mentioned |
+|      | **2. avoid-init-function** — database init() review                                                 | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 2.1  | Explicitly recommends against using init() for database initialization                              | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 2.2  | Mentions that init() makes testing harder or unpredictable                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 2.3  | Mentions that init() cannot return errors (must panic or log.Fatal)                                 | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                        |
+| 2.4  | Suggests explicit constructor or initialization function                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 2.5  | Mentions that init() runs before main/tests creating hidden dependencies                            | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                        |
+|      | **3. enum-start-at-one** — order status enum with iota                                              | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                |
+| 3.1  | Zero value (iota = 0) is either skipped, named Unknown, Invalid, or Unspecified                     | <span class="g">✓</span>       | <span class="r">✗</span> Pending at iota 0                    |
+| 3.2  | First meaningful enum value starts at 1 or higher                                                   | <span class="g">✓</span>       | <span class="r">✗</span> starts at 0                          |
+| 3.3  | Explains WHY: Go's zero value would silently pass as the first enum member                          | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 3.4  | Uses a custom type (not raw int or string)                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **4. panic-vs-error-judgment** — config parser: invalid format, missing field, nil arg              | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 4.1  | Invalid config format: return error (caller can handle it)                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 4.2  | Missing required field: return error (expected validation failure)                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 4.3  | Nil passed to non-nil function: panic is acceptable (violated invariant)                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 4.4  | Articulates the principle: panic is for bugs/invariant violations, errors are for expected failures | <span class="g">✓</span>       | <span class="r">✗</span> vague distinction                    |
+| 4.5  | Mentions Must* constructor pattern as a valid panic use case                                        | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                        |
+|      | **5. runtime-addcleanup-over-setfinalizer** — automatic cleanup for cgo resource (Go 1.24)          | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                |
+| 5.1  | Recommends runtime.AddCleanup as the preferred approach                                             | <span class="g">✓</span>       | <span class="r">✗</span> uses SetFinalizer                    |
+| 5.2  | Mentions that AddCleanup supports multiple cleanups on the same object                              | <span class="g">✓</span>       | <span class="r">✗</span>                                      |
+| 5.3  | Mentions that AddCleanup avoids object resurrection risk                                            | <span class="g">✓</span>       | <span class="r">✗</span>                                      |
+| 5.4  | Mentions that AddCleanup works even with cyclic references                                          | <span class="g">✓</span>       | <span class="r">✗</span>                                      |
+| 5.5  | Either warns against SetFinalizer or explains why AddCleanup is better                              | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **6. resource-pool-bounded-channel** — connection pool design                                       | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                |
+| 6.1  | Uses a buffered channel (chan *Conn with fixed capacity) as the pool mechanism                      | <span class="g">✓</span>       | <span class="r">✗</span> uses slice+mutex                     |
+| 6.2  | Pool has a maximum size / bounded capacity                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 6.3  | Get operation uses select with context for timeout/cancellation                                     | <span class="g">✓</span>       | <span class="r">✗</span> no context support                   |
+| 6.4  | Put operation handles pool-full case (discards excess connections)                                  | <span class="g">✓</span>       | <span class="r">✗</span> no overflow handling                 |
+| 6.5  | Does NOT use sync.Pool as the primary pooling mechanism                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **7. graceful-shutdown-signal-notifycontext** — HTTP server SIGINT/SIGTERM handling                 | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 7.1  | Uses signal.NotifyContext (not raw signal.Notify with a channel)                                    | <span class="g">✓</span>       | <span class="r">✗</span> uses signal.Notify channel           |
+| 7.2  | Listens for both SIGINT and SIGTERM                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 7.3  | Starts the HTTP server in a goroutine                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 7.4  | Creates a separate timeout context for the shutdown phase                                           | <span class="g">✓</span>       | <span class="r">✗</span> no separate shutdown timeout         |
+| 7.5  | Closes other resources (DB, queues) after server shutdown                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **8. iterator-streaming-large-data** — export 2M rows to JSON HTTP response                         | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                |
+| 8.1  | Does NOT load all 2M rows into a slice in memory                                                    | <span class="g">✓</span>       | <span class="r">✗</span> loads all into []User                |
+| 8.2  | Streams the JSON response (writes records one at a time to the ResponseWriter)                      | <span class="g">✓</span>       | <span class="r">✗</span> json.Marshal entire slice            |
+| 8.3  | Uses rows.Next() loop or iter.Seq2 iterator pattern                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 8.4  | Defers rows.Close() immediately after query                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 8.5  | Mentions OOM risk or memory concern as motivation for streaming                                     | <span class="g">✓</span>       | <span class="r">✗</span> no OOM discussion                    |
+|      | **9. regexp-compile-once** — email validation regex called thousands of times/sec                   | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                |
+| 9.1  | Compiles the regexp at package level (var emailRegex = regexp.MustCompile(...))                     | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 9.2  | Does NOT compile the regexp inside the validation function                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 9.3  | Uses regexp.MustCompile (not regexp.Compile) for package-level initialization                       | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 9.4  | Explains WHY: compilation is O(n) and allocates, so doing it per-call is wasteful                   | <span class="g">✓</span>       | <span class="r">✗</span> mentions performance but not O(n)    |
+|      | **10. architecture-right-sizing** — 200-line CSV CLI tool architecture                              | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                |
+| 10.1 | Recommends a flat or minimal structure (no multi-layer architecture)                                | <span class="g">✓</span>       | <span class="r">✗</span> suggests cmd/internal/pkg layout     |
+| 10.2 | Does NOT suggest clean architecture, hexagonal, DDD, or ports and adapters                          | <span class="g">✓</span>       | <span class="r">✗</span> suggests layered packages            |
+| 10.3 | Does NOT suggest dependency injection frameworks                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 10.4 | Structure has at most cmd/ and possibly internal/, not handler/service/repository layers            | <span class="g">✓</span>       | <span class="r">✗</span> includes service layer               |
+| 10.5 | Mentions that architecture complexity should match project scope                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **11. hexagonal-vs-clean-architecture** — 8K-line order service with HTTP/gRPC/MQ                   | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 11.1 | Correctly explains hexagonal: ports (interfaces) + adapters with primary/secondary distinction      | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 11.2 | Correctly explains clean architecture: dependency rule (inward) with entities/use-cases/adapters    | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 11.3 | Recommends hexagonal for this case (multiple entry points: HTTP, gRPC, message consumer)            | <span class="g">✓</span>       | <span class="r">✗</span> recommends clean architecture        |
+| 11.4 | Mentions that both keep domain logic pure and free from infrastructure dependencies                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 11.5 | Provides a directory structure with adapter/primary/ and adapter/secondary/ or equivalent           | <span class="g">✓</span>       | <span class="r">✗</span> generic layered layout               |
+|      | **12. ddd-aggregate-root-mutations** — Order aggregate with AddItem, Draft status guard             | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 12.1 | AddItem is a method on the Order aggregate root (not on OrderItem or a service)                     | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 12.2 | Order fields (items, status) are unexported to prevent external mutation                            | <span class="g">✓</span>       | <span class="r">✗</span> exported Items/Status fields         |
+| 12.3 | AddItem validates the status constraint (only Draft orders are editable)                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 12.4 | Repository interface is defined in the domain package, not in the infrastructure package            | <span class="g">✓</span>       | <span class="r">✗</span> repo interface in infrastructure     |
+| 12.5 | Domain types have no infrastructure imports (no sql, no http, no framework dependencies)            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **13. ddd-bounded-context-communication** — Order and Billing context communication                 | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 13.1 | Uses domain events (e.g. OrderPlaced event) for cross-context communication                         | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 13.2 | Billing context does NOT directly import order's internal domain types                              | <span class="g">✓</span>       | <span class="r">✗</span> imports order types directly         |
+| 13.3 | Shows or describes an anti-corruption layer that translates order events to billing types           | <span class="g">✓</span>       | <span class="r">✗</span> no ACL layer                         |
+| 13.4 | Each bounded context has its own domain, application, and adapter layers                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 13.5 | Mentions that direct type imports between contexts create tight coupling                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **14. make-illegal-states-unrepresentable** — Email type to prevent invalid emails                  | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 14.1 | Creates a dedicated Email type (struct with unexported address field)                               | <span class="g">✓</span>       | <span class="r">✗</span> validates at function entry          |
+| 14.2 | Email can only be created via a constructor (NewEmail) that validates the address                   | <span class="g">✓</span>       | <span class="r">✗</span> no constructor                       |
+| 14.3 | The send function accepts the Email type instead of a raw string                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 14.4 | Explains the principle: make illegal states unrepresentable through the type system                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 14.5 | The unexported field prevents creating an Email without validation                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **15. fail-fast-validate-at-boundaries** — three-layer validation strategy                          | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                |
+| 15.1 | Recommends validating at the HTTP handler layer (the system boundary)                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 15.2 | Recommends that the service and repository layers trust the data is already valid                   | <span class="g">✓</span>       | <span class="r">✗</span> suggests validating in service too   |
+| 15.3 | Explains WHY: re-validating at every layer clutters code and violates DRY                           | <span class="g">✓</span>       | <span class="r">✗</span> advocates "defense in depth"         |
+| 15.4 | Does NOT suggest adding the same validation checks in all three layers                              | <span class="g">✓</span>       | <span class="r">✗</span> validates at all layers              |
+| 15.5 | May distinguish between input validation (at boundary) and business rule validation (in domain)     | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **16. explicit-over-implicit-defaults** — struct tag `default:"8080"` review                        | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                |
+| 16.1 | Recommends against using struct tags + reflection for defaults                                      | <span class="g">✓</span>       | <span class="r">✗</span> endorses struct tags as convenient   |
+| 16.2 | Suggests explicit defaults in a constructor function (e.g. NewConfig())                             | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 16.3 | Explains WHY: Go favors explicitness, struct tags hide behavior                                     | <span class="g">✓</span>       | <span class="r">✗</span> presents it as valid Go pattern      |
+| 16.4 | Shows a constructor that returns a Config with default values set explicitly                        | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **17. retry-context-check** — production-ready retry with exponential backoff                       | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 17.1 | Function accepts a context.Context parameter                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 17.2 | Checks ctx.Err() or ctx.Done() between retry attempts                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 17.3 | Uses select with ctx.Done() for the backoff delay (not time.Sleep)                                  | <span class="g">✓</span>       | <span class="r">✗</span> uses time.Sleep                      |
+| 17.4 | Implements exponential backoff                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 17.5 | Returns the context error if the context is cancelled during retry                                  | <span class="g">✓</span>       | <span class="r">✗</span> returns last operation error         |
+|      | **18. ddd-value-object-money** — monetary amounts with addition and comparison                      | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                |
+| 18.1 | Uses int64 (cents) not float64 for the amount                                                       | <span class="g">✓</span>       | <span class="r">✗</span> uses float64                         |
+| 18.2 | Includes a currency field                                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 18.3 | Fields are unexported (immutable value object, only created via constructor)                        | <span class="g">✓</span>       | <span class="r">✗</span> exported Amount/Currency             |
+| 18.4 | Add method validates currency match before addition                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 18.5 | Constructor validates input (e.g. currency is required)                                             | <span class="g">✓</span>       | <span class="r">✗</span> no validation in constructor         |
+
+</details>
+
+## `golang-cli` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **55/58 (95%)** | **30/58 (52%)** | **+43pp** |
+
+<details>
+<summary>Full breakdown (58 assertions across 12 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                  | With                           | Without                                                 |
+| ---- | ------------------------------------------------------------------------------------------ | ------------------------------ | ------------------------------------------------------- |
+|      | **1. minimal-main-and-execute** — main.go minimal, os.Exit only in main                    | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                          |
+| 1.1  | main.go only calls Execute() — no config, flag setup, or business logic                    | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 1.2  | Root command sets SilenceUsage: true                                                       | <span class="g">✓</span>       | <span class="r">✗</span> not set                        |
+| 1.3  | Root command sets SilenceErrors: true                                                      | <span class="g">✓</span>       | <span class="r">✗</span> not set                        |
+| 1.4  | Subcommands do NOT call os.Exit() inside RunE                                              | <span class="g">✓</span>       | <span class="r">✗</span> os.Exit(1) in RunE             |
+| 1.5  | Push subcommand registered via rootCmd.AddCommand() in init()                              | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **2. viper-config-layering** — flags > env > config file > defaults                        | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                          |
+| 2.1  | Calls viper.BindPFlag to bind the port flag to Viper                                       | <span class="g">✓</span>       | <span class="r">✗</span> flag and Viper disconnected    |
+| 2.2  | Sets env prefix with viper.SetEnvPrefix                                                    | <span class="g">✓</span>       | <span class="r">✗</span> no prefix, bare PORT           |
+| 2.3  | Calls viper.AutomaticEnv()                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 2.4  | Handles viper.ConfigFileNotFoundError gracefully                                           | <span class="g">✓</span>       | <span class="r">✗</span> log.Fatal on missing config    |
+| 2.5  | Precedence order correct: flags > env > config > defaults                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **3. persistent-pre-run-config-init** — config init in PersistentPreRunE                   | **<span class="g">4/5</span>** | **<span class="r">2/5</span>**                          |
+| 3.1  | Config init in PersistentPreRunE on root command                                           | <span class="g">✓</span>       | <span class="r">✗</span> duplicated in each RunE        |
+| 3.2  | Config init NOT duplicated in each subcommand                                              | <span class="g">✓</span>       | <span class="r">✗</span> three copies of init logic     |
+| 3.3  | --config is a persistent flag on root command                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 3.4  | Uses SetEnvKeyReplacer for hyphens-to-underscores                                          | <span class="r">✗</span>       | <span class="r">✗</span>                                |
+| 3.5  | Logging configured to write to stderr                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **4. stdout-vs-stderr-separation** — output to stdout, diagnostics to stderr               | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                          |
+| 4.1  | Program output uses cmd.OutOrStdout(), not os.Stdout                                       | <span class="g">✓</span>       | <span class="r">✗</span> fmt.Println to os.Stdout       |
+| 4.2  | Logs/progress go to stderr                                                                 | <span class="g">✓</span>       | <span class="r">✗</span> log.Println to stdout          |
+| 4.3  | Errors go to stderr via cmd.ErrOrStderr()                                                  | <span class="g">✓</span>       | <span class="r">✗</span> errors mixed with stdout       |
+| 4.4  | Uses cmd.OutOrStdout() instead of os.Stdout directly                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 4.5  | Returns error from RunE, not os.Exit() or log.Fatal()                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **5. version-ldflags-injection** — version via ldflags, not hardcoded                      | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                          |
+| 5.1  | Version/commit/date are var (not const) with placeholder defaults                          | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 5.2  | Shows -ldflags '-X ...' build command                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 5.3  | Version command uses cmd.OutOrStdout()                                                     | <span class="g">✓</span>       | <span class="r">✗</span> fmt.Println                    |
+| 5.4  | Version NOT hardcoded as const                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 5.5  | Includes runtime/debug.ReadBuildInfo() fallback                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **6. exit-code-conventions** — 0 success, 1 general, 2 usage                               | **<span class="g">4/5</span>** | **<span class="r">2/5</span>**                          |
+| 6.1  | Exit codes 0/1/2 follow Unix conventions                                                   | <span class="g">✓</span>       | <span class="r">✗</span> all errors exit 1              |
+| 6.2  | os.Exit() only in main()                                                                   | <span class="g">✓</span>       | <span class="r">✗</span> os.Exit inside handlers        |
+| 6.3  | Typed error or ExitError with Code field to propagate exit codes                           | <span class="r">✗</span>       | <span class="r">✗</span>                                |
+| 6.4  | Errors returned from commands, not swallowed by os.Exit()                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 6.5  | Different error categories map to different exit codes                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **7. signal-handling-with-context** — signal.NotifyContext for cancellation                | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                          |
+| 7.1  | Uses signal.NotifyContext, NOT raw channel with signal.Notify                              | <span class="g">✓</span>       | <span class="r">✗</span> raw channel + select           |
+| 7.2  | Handles both os.Interrupt and syscall.SIGTERM                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 7.3  | Creates shutdown timeout context (10-30s)                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 7.4  | Calls srv.Shutdown(ctx), not srv.Close()                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 7.5  | Distinguishes http.ErrServerClosed from unexpected errors                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **8. flag-binding-and-constraints** — persistent vs local, mutual exclusion, Viper binding | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                          |
+| 8.1  | --verbose is a persistent flag on root, not local to deploy                                | <span class="g">✓</span>       | <span class="r">✗</span> local flag on deploy           |
+| 8.2  | Uses MarkFlagRequired for --env and --tag                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 8.3  | Uses MarkFlagsMutuallyExclusive for --dry-run and --force                                  | <span class="g">✓</span>       | <span class="r">✗</span> manual check in RunE           |
+| 8.4  | Uses RegisterFlagCompletionFunc for --env values                                           | <span class="g">✓</span>       | <span class="r">✗</span> no completion                  |
+| 8.5  | Binds flags to Viper with viper.BindPFlag                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **9. argument-validation** — Cobra built-in validators, not manual len(args)               | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                          |
+| 9.1  | Uses cobra.NoArgs for status command                                                       | <span class="g">✓</span>       | <span class="r">✗</span> manual len(args) == 0          |
+| 9.2  | Uses cobra.ExactArgs(1) for deploy command                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 9.3  | Uses cobra.RangeArgs(2, 3) for scale command                                               | <span class="g">✓</span>       | <span class="r">✗</span> manual range check in RunE     |
+| 9.4  | Validators set on Args field, not inside RunE                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **10. cli-testing-pattern** — execute programmatically with captured output                | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                          |
+| 10.1 | Creates executeCommand helper with cmd.SetOut(buf) and cmd.SetErr(buf)                     | <span class="g">✓</span>       | <span class="r">✗</span> no helper, tests run binary    |
+| 10.2 | Table-driven tests with multiple cases                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 10.3 | Uses cmd.SetArgs() — not os/exec.Command                                                   | <span class="g">✓</span>       | <span class="r">✗</span> exec.Command("./greet")        |
+| 10.4 | Captures output via bytes.Buffer — not redirecting os.Stdout                               | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 10.5 | Tests check both output and error return value                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **11. machine-readable-output-format** — --output flag with json/table/plain               | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                          |
+| 11.1 | Supports --output flag with json and table formats                                         | <span class="g">✓</span>       | <span class="r">✗</span> --json boolean toggle only     |
+| 11.2 | JSON output uses encoding/json to cmd.OutOrStdout()                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 11.3 | Table output uses text/tabwriter for aligned columns                                       | <span class="g">✓</span>       | <span class="r">✗</span> fmt.Printf with manual spacing |
+| 11.4 | Default format is human-readable table                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **12. shell-completion-setup** — Cobra built-in generators + custom completions            | **<span class="g">4/5</span>** | **<span class="r">3/5</span>**                          |
+| 12.1 | Completion subcommand supports bash, zsh, fish, powershell                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 12.2 | Uses Cobra's built-in GenBashCompletionV2, GenZshCompletion, etc.                          | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 12.3 | Uses RegisterFlagCompletionFunc for --env flag                                             | <span class="g">✓</span>       | <span class="r">✗</span> no custom completions          |
+| 12.4 | Uses ValidArgs or cobra.ExactValidArgs for completion command                              | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 12.5 | Returns cobra.ShellCompDirectiveNoFileComp for non-file flags                              | <span class="r">✗</span>       | <span class="r">✗</span>                                |
+
+</details>
+
+## `golang-concurrency` — v1.0.0
+
+|             | With Skill       | Without Skill   | Delta     |
+| ----------- | ---------------- | --------------- | --------- |
+| **Overall** | **62/62 (100%)** | **38/62 (61%)** | **+39pp** |
+
+<details>
+<summary>Full breakdown (62 assertions across 13 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Runs:** 13 evals x 2 configs = 26 subagents | **Grading:** Human-as-a-judge
+
+| #    | Assertion                                                                                                              | With                           | Without                                                           |
+| ---- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------ | ----------------------------------------------------------------- |
+|      | **1. time-after-in-select-loop** — avoid time.After in loop, use time.NewTimer+Reset                                   | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 1.1  | Does NOT use time.After inside the loop body                                                                           | <span class="g">✓</span>       | <span class="r">✗</span> uses time.After(5*time.Second) in select |
+| 1.2  | Creates time.NewTimer (or time.NewTicker) outside the loop                                                             | <span class="g">✓</span>       | <span class="r">✗</span> no timer created outside loop            |
+| 1.3  | Calls timer.Reset() after handling a message or timeout                                                                | <span class="g">✓</span>       | <span class="r">✗</span> no Reset call                            |
+| 1.4  | Calls timer.Stop() (or defers it) to clean up the timer                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 1.5  | Drains the timer channel before Reset when appropriate (if !timer.Stop() { <-timer.C })                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **2. channel-closing-ownership** — only the sender closes a channel                                                    | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 2.1  | Does NOT close the channel from the consumer/receiver side                                                             | <span class="g">✓</span>       | <span class="r">✗</span> closes from consumer                     |
+| 2.2  | Uses a separate signaling mechanism (done channel, context cancellation) for the consumer to tell the producer to stop | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 2.3  | The producer is the one that closes the data channel                                                                   | <span class="g">✓</span>       | <span class="r">✗</span> consumer closes data channel             |
+| 2.4  | Explains the panic risk of closing a channel from the receiver side                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 2.5  | The producer selects on the stop signal alongside its send operation                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **3. waitgroup-add-placement** — wg.Add before go statement                                                            | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                    |
+| 3.1  | Calls wg.Add(1) BEFORE the go statement, not inside the goroutine                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 3.2  | Calls defer wg.Done() inside the goroutine                                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 3.3  | Calls wg.Wait() after the loop to wait for all goroutines                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 3.4  | Does not place wg.Add inside the goroutine function body                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **4. channel-direction-in-signatures** — use chan<- and <-chan in function signatures                                  | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                    |
+| 4.1  | The generator function returns <-chan int (receive-only for callers)                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 4.2  | The doubler function accepts <-chan int as input parameter                                                             | <span class="g">✓</span>       | <span class="r">✗</span> uses bidirectional chan int              |
+| 4.3  | The doubler function returns <-chan int (receive-only for callers)                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 4.4  | Internally, channels are created as bidirectional but exposed as directional through return types                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 4.5  | The producer (generator) closes its output channel with defer close(out)                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **5. unbuffered-channel-default** — default to unbuffered, justify buffers                                             | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 5.1  | Recommends starting with unbuffered (or very small buffer like 0 or 1) as the default                                  | <span class="g">✓</span>       | <span class="r">✗</span> suggests buffer of 100                   |
+| 5.2  | Explains that large buffers mask backpressure problems                                                                 | <span class="g">✓</span>       | <span class="r">✗</span> no backpressure discussion               |
+| 5.3  | States that buffer size should be based on measured need, not arbitrary choice                                         | <span class="g">✓</span>       | <span class="r">✗</span> picks arbitrary size                     |
+| 5.4  | Does NOT suggest a large arbitrary buffer (e.g., 100, 1000) without explaining the tradeoffs                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 5.5  | Mentions that buffered channels hide the problem of slow consumers                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **6. send-copies-not-pointers** — send values through channels, not pointers                                           | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                                    |
+| 6.1  | Sends Task values (not *Task pointers) through the channel, OR explicitly documents why pointers are safe              | <span class="g">✓</span>       | <span class="r">✗</span> sends *Task pointers                     |
+| 6.2  | The channel type is chan Task (value type) rather than chan *Task                                                      | <span class="g">✓</span>       | <span class="r">✗</span> uses chan *Task                          |
+| 6.3  | Does not mutate the Task struct after sending it on the channel (or sends a copy)                                      | <span class="g">✓</span>       | <span class="r">✗</span> no copy/immutability discussion          |
+| 6.4  | If pointers are used, explicitly acknowledges the shared-memory risk and explains the mitigation                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **7. errgroup-vs-waitgroup-decision** — errgroup.SetLimit for bounded concurrent work with errors                      | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 7.1  | Uses errgroup (golang.org/x/sync/errgroup) instead of sync.WaitGroup for error propagation                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 7.2  | Uses errgroup.WithContext to cancel siblings on first error                                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 7.3  | Uses g.SetLimit(10) for bounded concurrency instead of a hand-rolled semaphore                                         | <span class="g">✓</span>       | <span class="r">✗</span> uses semaphore channel                   |
+| 7.4  | Does NOT build a manual worker pool with channels and WaitGroup when errgroup suffices                                 | <span class="g">✓</span>       | <span class="r">✗</span> builds manual pool with channels         |
+| 7.5  | Each goroutine checks ctx.Done() or uses the context from errgroup.WithContext                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **8. ctx-done-in-select** — always include ctx.Done() in select to prevent goroutine leaks                             | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 8.1  | The function accepts a context.Context parameter                                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 8.2  | Every select statement includes a case <-ctx.Done(): return branch                                                     | <span class="g">✓</span>       | <span class="r">✗</span> missing ctx.Done in output select        |
+| 8.3  | Both the read from input channel AND the write to output channel are wrapped in select with ctx.Done()                 | <span class="g">✓</span>       | <span class="r">✗</span> only read has select                     |
+| 8.4  | The goroutine exits cleanly when context is cancelled                                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 8.5  | The output channel is closed when the goroutine exits (defer close)                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **9. sync-map-vs-rwmutex-decision** — RWMutex+map for write-heavy overlapping keys                                     | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 9.1  | Recommends sync.RWMutex + plain map over sync.Map for this write-heavy, overlapping-key pattern                        | <span class="g">✓</span>       | <span class="r">✗</span> recommends sync.Map                      |
+| 9.2  | Explains that sync.Map is optimized for write-once/read-many or disjoint key sets                                      | <span class="g">✓</span>       | <span class="r">✗</span> no access-pattern discussion             |
+| 9.3  | Explains that for frequent writes with overlapping keys, RWMutex+map is faster                                         | <span class="g">✓</span>       | <span class="r">✗</span> no performance comparison                |
+| 9.4  | Does NOT unconditionally recommend sync.Map for any concurrent map scenario                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 9.5  | Mentions that concurrent map read/write without synchronization causes a hard crash                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **10. sync-pool-reset-before-put** — Reset() before Put(), not after Get()                                             | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 10.1 | Calls buf.Reset() BEFORE bufPool.Put(buf), not after Get()                                                             | <span class="g">✓</span>       | <span class="r">✗</span> resets after Get()                       |
+| 10.2 | Uses defer to ensure the buffer is returned to the pool even on error                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 10.3 | Does not assume the object from Get() is clean/zeroed                                                                  | <span class="g">✓</span>       | <span class="r">✗</span> assumes clean after Get                  |
+| 10.4 | The pool's New function creates a new buffer                                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 10.5 | Does not store persistent state in pooled objects                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **11. goroutine-panic-recovery** — recover at goroutine boundaries                                                     | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                    |
+| 11.1 | Adds defer func() { recover() }() or equivalent panic recovery inside the goroutine                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 11.2 | Logs or handles the recovered panic (not just silently swallowed)                                                      | <span class="g">✓</span>       | <span class="r">✗</span> swallows panic silently                  |
+| 11.3 | The goroutine has a shutdown mechanism (context, done channel, or similar)                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 11.4 | Mentions that a panic in a goroutine crashes the entire process                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **12. singleflight-cache-stampede** — use singleflight to deduplicate concurrent lookups                               | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                    |
+| 12.1 | Recommends golang.org/x/sync/singleflight as the primary solution                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 12.2 | Shows usage of group.Do(key, func) where key identifies the deduplicated resource                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 12.3 | Explains that only one goroutine executes the function; others wait and share the result                               | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 12.4 | May combine singleflight with a cache layer for TTL-based caching                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 12.5 | Does NOT suggest only a plain mutex or only a TTL cache as the solution to thundering herd                             | <span class="g">✓</span>       | <span class="r">✗</span> also suggests mutex as primary approach  |
+|      | **13. iterator-vs-goroutine-pipeline** — iterators for sequential CPU-bound transforms                                 | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                    |
+| 13.1 | Recommends against goroutine+channel pipeline for this purely sequential, in-memory transform                          | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 13.2 | Suggests Go 1.23+ iterators (iter.Seq) or simple slice operations instead                                              | <span class="g">✓</span>       | <span class="r">✗</span> suggests only plain loop                 |
+| 13.3 | Explains that goroutine+channel pipelines add overhead without benefit for sequential CPU-bound work                   | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 13.4 | Mentions that goroutine pipelines are appropriate when stages involve I/O or need true parallelism                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 13.5 | Does NOT build a multi-goroutine pipeline for this use case                                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+
+</details>
+
+## `golang-context` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **48/50 (96%)** | **31/50 (62%)** | **+34pp** |
+
+<details>
+<summary>Full breakdown (50 assertions across 10 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Runs:** 10 evals x 2 configs = 20 subagents | **Grading:** Human-as-a-judge
+
+| #    | Assertion                                                                                                      | With                                                                       | Without                                                              |
+| ---- | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------------- |
+|      | **1. context-background-in-handler** — use r.Context(), not context.Background() in handlers                   | **<span class="g">5/5</span>**                                             | **<span class="g">4/5</span>**                                       |
+| 1.1  | Uses r.Context() to obtain the request context, NOT context.Background() inside the handler                    | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 1.2  | Passes the same context (or a derived child) to the database query (*Context variant)                          | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 1.3  | Passes the same context to the external HTTP call via http.NewRequestWithContext                               | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 1.4  | Does NOT use http.NewRequest (without context) for the external service call                                   | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 1.5  | Checks ctx.Err() or handles context cancellation when the client disconnects                                   | <span class="g">✓</span>                                                   | <span class="r">✗</span> no ctx.Err() check on disconnect            |
+|      | **2. cancel-leak-timeout** — defer cancel() for every WithTimeout, per-attempt timeouts                        | **<span class="g">5/5</span>**                                             | **<span class="g">4/5</span>**                                       |
+| 2.1  | Creates a new context.WithTimeout for each retry attempt (not one timeout for all retries)                     | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 2.2  | Calls defer cancel() (or cancel() before next iteration) for every WithTimeout call                            | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 2.3  | Does NOT discard the cancel function with _ (e.g., ctx, _ = context.WithTimeout(...))                          | <span class="g">✓</span>                                                   | <span class="r">✗</span> discards cancel with _                      |
+| 2.4  | Uses http.NewRequestWithContext to attach the per-attempt timeout context                                      | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 2.5  | Accepts a parent context parameter and derives timeouts from it                                                | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+|      | **3. context-value-key-type** — unexported key types for context values                                        | **<span class="g">5/5</span>**                                             | **<span class="r">3/5</span>**                                       |
+| 3.1  | Uses an unexported type for the context key (e.g., type contextKey string or type tenantKey struct{})          | <span class="g">✓</span>                                                   | <span class="r">✗</span> uses plain string key                       |
+| 3.2  | Does NOT use a plain string as the context key                                                                 | <span class="g">✓</span>                                                   | <span class="r">✗</span> context.WithValue(ctx, "tenant_id", ...)    |
+| 3.3  | Provides a typed getter function (e.g., TenantIDFromContext) that returns the value with proper type assertion | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 3.4  | Provides a setter function or the middleware injects the value using the unexported key                        | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 3.5  | The getter handles the case where the value is missing from the context (returns zero value + bool or error)   | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+|      | **4. context-in-struct-trap** — do not store context.Context in a struct field                                 | **<span class="g">5/5</span>**                                             | **<span class="r">3/5</span>**                                       |
+| 4.1  | Does NOT store context.Context as a field in the Worker struct                                                 | <span class="g">✓</span>                                                   | <span class="r">✗</span> stores ctx context.Context in struct        |
+| 4.2  | Passes context as a parameter to Start() or Run() method                                                       | <span class="g">✓</span>                                                   | <span class="r">✗</span> uses stored struct field context            |
+| 4.3  | Uses context cancellation or a done channel for graceful shutdown signaling                                    | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 4.4  | Listens to ctx.Done() in a select statement to detect shutdown                                                 | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 4.5  | ctx is the first parameter where it appears, named ctx context.Context                                         | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+|      | **5. without-cancel-background-work** — use context.WithoutCancel for background work (Go 1.21+)               | **<span class="g">5/5</span>**                                             | **<span class="r">2/5</span>**                                       |
+| 5.1  | Uses context.WithoutCancel to create a context for the audit goroutine                                         | <span class="g">✓</span>                                                   | <span class="r">✗</span> uses context.Background()                   |
+| 5.2  | Does NOT pass r.Context() directly to the background audit goroutine                                           | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 5.3  | Does NOT use context.Background() for the audit goroutine (that would lose trace_id)                           | <span class="g">✓</span>                                                   | <span class="r">✗</span> uses context.Background()                   |
+| 5.4  | The audit goroutine preserves request-scoped values (trace_id) from the original context                       | <span class="g">✓</span>                                                   | <span class="r">✗</span> context.Background() loses all values       |
+| 5.5  | Launches the audit as a separate goroutine (go keyword) so the handler can return immediately                  | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+|      | **6. nested-timeout-shorter-wins** — nested timeouts take the shorter deadline                                 | **<span class="r">4/5</span>**                                             | **<span class="r">3/5</span>**                                       |
+| 6.1  | Creates the overall 10-second timeout from the parent context                                                  | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 6.2  | Creates the cache timeout as a child of the overall context                                                    | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 6.3  | Acknowledges that the database timeout is bounded by whatever time remains on the parent                       | <span class="r">✗</span> creates 8s child without noting parent constraint | <span class="r">✗</span> creates independent 8s timeout              |
+| 6.4  | Defers cancel() for every WithTimeout call                                                                     | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 6.5  | Does NOT create independent context.Background() timeouts that bypass the overall deadline                     | <span class="g">✓</span>                                                   | <span class="r">✗</span> creates context.Background() timeout for DB |
+|      | **7. context-todo-vs-background** — use context.TODO() as placeholder, not context.Background()                | **<span class="g">5/5</span>**                                             | **<span class="r">3/5</span>**                                       |
+| 7.1  | Uses context.TODO() as the temporary placeholder in functions not yet fully migrated                           | <span class="g">✓</span>                                                   | <span class="r">✗</span> uses context.Background() everywhere        |
+| 7.2  | Uses context.Background() only at the true top level (main function or test setup)                             | <span class="g">✓</span>                                                   | <span class="r">✗</span> uses Background() at all levels             |
+| 7.3  | Shows a migration path where context.TODO() is gradually replaced as callers are updated                       | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 7.4  | Context is always the first parameter, named ctx context.Context                                               | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 7.5  | Does NOT pass nil as a context value at any point in the migration                                             | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+|      | **8. db-context-variants** — use *Context database method variants                                             | **<span class="g">5/5</span>**                                             | **<span class="g">5/5</span>**                                       |
+| 8.1  | Uses db.QueryRowContext (not db.QueryRow) for GetByID                                                          | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 8.2  | Uses db.ExecContext (not db.Exec) for Create, Update, and Delete                                               | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 8.3  | Passes the ctx parameter to every database call                                                                | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 8.4  | Does NOT ignore the ctx parameter by calling non-context database methods                                      | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 8.5  | Each method accepts ctx context.Context as its first parameter                                                 | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+|      | **9. context-values-abuse** — do not stuff infrastructure deps into context values                             | **<span class="g">5/5</span>**                                             | **<span class="g">4/5</span>**                                       |
+| 9.1  | Database connection is passed as a struct field or explicit parameter, NOT via context value                   | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 9.2  | Logger is passed as a struct field or explicit parameter, NOT via context value                                | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 9.3  | Order details are passed as an explicit function parameter, NOT via context value                              | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 9.4  | User ID and/or trace ID are stored in context values (these are request-scoped metadata)                       | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 9.5  | Distinguishes between infrastructure dependencies (explicit) and request-scoped metadata (context values)      | <span class="g">✓</span>                                                   | <span class="r">✗</span> no explicit distinction made                |
+|      | **10. afterfunc-cleanup** — use context.AfterFunc for non-blocking cleanup (Go 1.21+)                          | **<span class="r">4/5</span>**                                             | **<span class="r">2/5</span>**                                       |
+| 10.1 | Uses context.AfterFunc to register the cleanup callback                                                        | <span class="g">✓</span>                                                   | <span class="r">✗</span> uses manual goroutine with <-ctx.Done()     |
+| 10.2 | Does NOT block the main flow waiting for context cancellation                                                  | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 10.3 | The cleanup function removes the temporary file                                                                | <span class="g">✓</span>                                                   | <span class="g">✓</span>                                             |
+| 10.4 | Captures the stop function returned by AfterFunc for potential cancellation of the callback                    | <span class="g">✓</span>                                                   | <span class="r">✗</span> no stop function (uses goroutine)           |
+| 10.5 | Also includes a defer-based cleanup as a safety net (AfterFunc + defer for belt-and-suspenders)                | <span class="r">✗</span> only AfterFunc, no defer fallback                 | <span class="r">✗</span> only goroutine, no defer fallback           |
+
+</details>
+
+## `golang-continuous-integration` — v1.0.0
+
+|             | With Skill       | Without Skill   | Delta     |
+| ----------- | ---------------- | --------------- | --------- |
+| **Overall** | **66/66 (100%)** | **27/66 (41%)** | **+59pp** |
+
+<details>
+<summary>Full breakdown (66 assertions across 13 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                     | With                           | Without                                                           |
+| ---- | --------------------------------------------------------------------------------------------- | ------------------------------ | ----------------------------------------------------------------- |
+|      | **1. test-workflow-flags** — CI test workflow with required flags and matrix                  | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 1.1  | Workflow includes `-race` flag in the go test command                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 1.2  | Workflow includes `-shuffle=on` flag in the go test command                                   | <span class="g">✓</span>       | <span class="r">✗</span> omitted shuffle                          |
+| 1.3  | Workflow includes `-coverprofile` flag in the go test command                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 1.4  | Strategy uses `fail-fast: false`                                                              | <span class="g">✓</span>       | <span class="r">✗</span> default fail-fast: true                  |
+| 1.5  | Go version matrix includes at least 'stable' and one explicit version                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **2. go-mod-tidy-check** — enforce go mod tidy via git diff --exit-code                       | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                    |
+| 2.1  | Suggests running `go mod tidy` as a CI step                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 2.2  | Includes `git diff --exit-code` after go mod tidy to detect uncommitted changes               | <span class="g">✓</span>       | <span class="r">✗</span> no git diff check                        |
+| 2.3  | The git diff checks go.mod and/or go.sum specifically, or uses a general git diff --exit-code | <span class="g">✓</span>       | <span class="r">✗</span> only runs tidy                           |
+| 2.4  | Also includes `go mod verify` or `go mod download` step                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **3. integration-test-caching** — integration tests with -count=1 and service containers      | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 3.1  | Uses `-count=1` flag to disable test result caching                                           | <span class="g">✓</span>       | <span class="r">✗</span> no -count=1                              |
+| 3.2  | Includes `-race` flag for integration tests                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 3.3  | Uses build tags (e.g., `-tags=integration`) to separate integration tests                     | <span class="g">✓</span>       | <span class="r">✗</span> no build tags                            |
+| 3.4  | Uses GitHub Actions `services` block for PostgreSQL and/or Redis                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 3.5  | Includes health check options for service containers                                          | <span class="g">✓</span>       | <span class="r">✗</span> no health checks                         |
+|      | **4. security-scanning-pipeline** — full security stack: govulncheck, gosec, CodeQL, Bearer   | **<span class="g">6/6</span>** | **<span class="r">2/6</span>**                                    |
+| 4.1  | Recommends govulncheck and explains it only reports actually-called code paths                | <span class="g">✓</span>       | <span class="r">✗</span> mentions govulncheck without call-path   |
+| 4.2  | Recommends gosec for Go security scanning                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 4.3  | Recommends CodeQL and mentions the security-extended or security-and-quality query suite      | <span class="g">✓</span>       | <span class="r">✗</span> no extended suite                        |
+| 4.4  | Recommends Bearer for sensitive data flow issues                                              | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                            |
+| 4.5  | Workflow includes `security-events: write` permission for SARIF upload                        | <span class="g">✓</span>       | <span class="r">✗</span> no permission block                      |
+| 4.6  | Suggests creating a CodeQL config file to use an extended query suite                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **5. dependabot-grouping-strategy** — group minor/patch, separate majors                      | **<span class="g">6/6</span>** | **<span class="r">3/6</span>**                                    |
+| 5.1  | Configures Dependabot for gomod package ecosystem                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 5.2  | Configures Dependabot for github-actions package ecosystem                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 5.3  | Configures Dependabot for docker package ecosystem                                            | <span class="g">✓</span>       | <span class="r">✗</span> omitted docker                           |
+| 5.4  | Groups minor and patch Go module updates into a single PR                                     | <span class="g">✓</span>       | <span class="r">✗</span> no grouping                              |
+| 5.5  | Major updates are NOT grouped (individual PRs for breaking changes)                           | <span class="g">✓</span>       | <span class="r">✗</span> all updates grouped                      |
+| 5.6  | Sets a weekly schedule                                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **6. dependabot-auto-merge-security** — auto-merge with actor guard and branch protection     | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                                    |
+| 6.1  | Workflow has `if: github.actor == dependabot[bot]` guard                                      | <span class="g">✓</span>       | <span class="r">✗</span> no actor guard                           |
+| 6.2  | Workflow checks metadata to exclude major updates from auto-merge                             | <span class="g">✓</span>       | <span class="r">✗</span> merges all versions                      |
+| 6.3  | Warns about `contents: write` and `pull-requests: write` being elevated permissions           | <span class="g">✓</span>       | <span class="r">✗</span> no security warning                      |
+| 6.4  | Mentions branch protection rules as the real safety net                                       | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                            |
+| 6.5  | Notes that `github.actor` checks are not fully spoof-proof                                    | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                            |
+|      | **7. renovate-vs-dependabot** — Renovate advantages for monorepos                             | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 7.1  | Recommends Renovate as an alternative to Dependabot                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 7.2  | Mentions Renovate's gomodTidy feature                                                         | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                            |
+| 7.3  | Mentions Renovate's native automerge without needing a separate workflow                      | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                            |
+| 7.4  | Mentions Renovate's monorepo/workspace support                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 7.5  | Mentions Renovate's better grouping rules                                                     | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                            |
+|      | **8. goreleaser-library-vs-cli** — GoReleaser config for libraries vs CLIs                    | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 8.1  | Uses `skip: true` in the builds section since libraries don't produce binaries                | <span class="g">✓</span>       | <span class="r">✗</span> includes full build config               |
+| 8.2  | Keeps the config minimal (mainly changelog generation)                                        | <span class="g">✓</span>       | <span class="r">✗</span> full CLI-style config                    |
+| 8.3  | Mentions that for libraries, a simple `gh release create` may be sufficient                   | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                            |
+| 8.4  | Does NOT include cross-compilation (goos/goarch) in the library config                        | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 8.5  | Includes changelog configuration                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **9. docker-workflow-security** — push: false on PRs, per-job permissions, provenance         | **<span class="g">6/6</span>** | **<span class="r">2/6</span>**                                    |
+| 9.1  | Sets push to false on pull requests                                                           | <span class="g">✓</span>       | <span class="r">✗</span> pushes on all events                     |
+| 9.2  | Uses per-job permissions scoping                                                              | <span class="g">✓</span>       | <span class="r">✗</span> top-level permissions only               |
+| 9.3  | Includes QEMU and Buildx setup for multi-platform builds                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 9.4  | Includes provenance and/or SBOM attestation configuration                                     | <span class="g">✓</span>       | <span class="r">✗</span> no attestations                          |
+| 9.5  | Includes `packages: write` permission for GHCR push                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 9.6  | Login step is conditional on non-PR events                                                    | <span class="g">✓</span>       | <span class="r">✗</span> unconditional login                      |
+|      | **10. permissions-least-privilege** — read-only GITHUB_TOKEN, branch protection, fork PRs     | **<span class="g">7/7</span>** | **<span class="r">3/7</span>**                                    |
+| 10.1 | Recommends setting default GITHUB_TOKEN to read-only                                          | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                            |
+| 10.2 | Recommends branch protection with required status checks                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 10.3 | Recommends requiring PR approvals (at least 1)                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 10.4 | Recommends dismissing stale approvals when new commits are pushed                             | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                            |
+| 10.5 | Recommends restricting fork PR workflows for outside collaborators                            | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                            |
+| 10.6 | Warns against `pull_request_target` with untrusted code                                       | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                            |
+| 10.7 | Recommends creating a release environment with required reviewers                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **11. release-workflow-fetch-depth** — fetch-depth: 0 for changelog generation                | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                    |
+| 11.1 | Checkout step uses `fetch-depth: 0` for full git history                                      | <span class="g">✓</span>       | <span class="r">✗</span> default shallow clone                    |
+| 11.2 | Workflow triggers on tag push with a `v*` pattern                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 11.3 | Uses `contents: write` permission for creating releases                                       | <span class="g">✓</span>       | <span class="r">✗</span> no permissions block                     |
+| 11.4 | Passes `GITHUB_TOKEN` to GoReleaser                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **12. action-version-pinning** — pin to major versions, not branches                          | **<span class="g">3/3</span>** | **<span class="g">2/3</span>**                                    |
+| 12.1 | Identifies that using `@master` and `@main` is wrong and insecure                             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 12.2 | Recommends pinning to major versions like `@v4`, `@v6`                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 12.3 | Explains the risk: branch references can change unexpectedly or be compromised                | <span class="g">✓</span>       | <span class="r">✗</span> identifies problem but no risk reasoning |
+|      | **13. coverage-threshold-configuration** — codecov.yml with project and patch targets         | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 13.1 | Configures `codecov.yml` (not just CLI flags) for coverage thresholds                         | <span class="g">✓</span>       | <span class="r">✗</span> uses CLI flags only                      |
+| 13.2 | Sets project target to 80%                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 13.3 | Sets a threshold value (e.g., 2%) to allow small drops                                        | <span class="g">✓</span>       | <span class="r">✗</span> no threshold                             |
+| 13.4 | Configures patch coverage target for new code in PRs                                          | <span class="g">✓</span>       | <span class="r">✗</span> no patch target                          |
+| 13.5 | Coverage upload is conditional on a single matrix entry (e.g., only on stable)                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+
+</details>
+
+## `golang-dependency-injection` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **54/55 (98%)** | **28/55 (51%)** | **+47pp** |
+
+<details>
+<summary>Full breakdown (55 assertions across 11 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                 | With                           | Without                                                           |
+| ---- | ----------------------------------------------------------------------------------------- | ------------------------------ | ----------------------------------------------------------------- |
+|      | **1. constructor-injection-not-globals** — inject via constructors, not globals or init() | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 1.1  | Uses constructor injection (NewUserService taking dependencies as parameters)             | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 1.2  | Explicitly advises against package-level variables for service dependencies               | <span class="g">✓</span>       | <span class="r">✗</span> accepts global var approach              |
+| 1.3  | Explains why globals are problematic (untestable, hidden dependencies, or coupling)       | <span class="g">✓</span>       | <span class="r">✗</span> no explanation of problems               |
+| 1.4  | Does NOT use `init()` for service initialization                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 1.5  | Returns a concrete struct pointer from the constructor, not an interface                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **2. interface-defined-at-consumer** — interfaces defined where consumed, not implemented | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 2.1  | Defines the interface in the consuming package, not the implementation package            | <span class="g">✓</span>       | <span class="r">✗</span> defines interface next to implementation |
+| 2.2  | Explains the principle: accept interfaces, return structs                                 | <span class="g">✓</span>       | <span class="r">✗</span> not stated                               |
+| 2.3  | The implementation package returns a concrete struct pointer                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 2.4  | The consumer depends on its own locally-defined interface                                 | <span class="g">✓</span>       | <span class="r">✗</span> imports provider interface               |
+| 2.5  | Does NOT have the implementation package import the consumer's interface                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **3. container-not-passed-as-dependency** — service locator anti-pattern                  | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 3.1  | Advises against passing the injector/container as a dependency                            | <span class="g">✓</span>       | <span class="r">✗</span> accepts passing injector                 |
+| 3.2  | Identifies this as the service locator anti-pattern                                       | <span class="g">✓</span>       | <span class="r">✗</span> not identified                           |
+| 3.3  | Shows that the Injector should only exist at the composition root                         | <span class="g">✓</span>       | <span class="r">✗</span> injector used throughout                 |
+| 3.4  | Shows UserService receiving Database and Mailer directly as constructor parameters        | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 3.5  | Shows the provider function using `do.MustInvoke` inside the provider, not inside methods | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **4. manual-di-for-small-projects** — small projects use manual DI, not a library         | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 4.1  | Recommends manual constructor injection for a project with only 5 services                | <span class="g">✓</span>       | <span class="r">✗</span> recommends Wire or Fx                    |
+| 4.2  | Does NOT recommend a DI library as the primary approach                                   | <span class="g">✓</span>       | <span class="r">✗</span> leads with DI library                    |
+| 4.3  | Shows wiring in `main()` with explicit constructor calls in dependency order              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 4.4  | Initializes infrastructure first, then repositories, then services, then transport        | <span class="g">✓</span>       | <span class="r">✗</span> no layered ordering                      |
+| 4.5  | Mentions that a DI library becomes worthwhile at 10-20+ services                          | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **5. di-library-selection-judgment** — correct library recommendation based on criteria   | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 5.1  | Recommends samber/do as a strong fit (generics, lifecycle, compile-time safety)           | <span class="g">✓</span>       | <span class="r">✗</span> recommends uber-go/fx                    |
+| 5.2  | Explains why uber-go/fx uses reflection (runtime errors, not compile-time)                | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 5.3  | Explains why google/wire lacks built-in lifecycle management                              | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 5.4  | Mentions that samber/do requires Go 1.18+ for generics                                    | <span class="g">✓</span>       | <span class="r">✗</span> samber/do not discussed                  |
+| 5.5  | Discusses at least 3 DI library options from the decision table                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **6. wire-build-constraint-and-codegen** — proper google/wire setup with wireinject       | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                    |
+| 6.1  | Includes `//go:build wireinject` build constraint in the wire.go file                     | <span class="g">✓</span>       | <span class="r">✗</span> omitted build constraint                 |
+| 6.2  | Uses `wire.Build` with all provider functions listed                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 6.3  | Shows `wire.Bind` for binding interface to implementation                                 | <span class="g">✓</span>       | <span class="r">✗</span> no wire.Bind shown                       |
+| 6.4  | Explains that wire generates wire_gen.go with plain constructor calls                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 6.5  | Mentions that wire_gen.go must not be edited manually                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **7. fx-lifecycle-hooks-pattern** — uber-go/fx OnStart/OnStop hooks for DB connection     | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                    |
+| 7.1  | Uses `fx.Lifecycle` parameter in the provider function                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 7.2  | Registers OnStart hook for establishing the database connection                           | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 7.3  | Registers OnStop hook for closing the database connection                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 7.4  | Uses `lc.Append(fx.Hook{...})` pattern                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 7.5  | OnStart and OnStop take `context.Context` as parameter                                    | <span class="g">✓</span>       | <span class="r">✗</span> omitted context parameter                |
+|      | **8. testing-with-di-mock-injection** — inject mocks at the interface boundary            | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                    |
+| 8.1  | Creates a mock implementation of the UserStore interface                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 8.2  | Injects the mock into UserService via the constructor (NewUserService)                    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 8.3  | Tests both the success path (user found) and the error path (not found)                   | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 8.4  | Does NOT use a real database connection in the test                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 8.5  | The mock is defined in the test file, not as a package-level or global variable           | <span class="g">✓</span>       | <span class="r">✗</span> mock as package-level var                |
+|      | **9. shallow-dependency-graph** — deep chains are a design problem                        | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 9.1  | Identifies the deep dependency chain as a design problem                                  | <span class="g">✓</span>       | <span class="r">✗</span> accepts as normal layered architecture   |
+| 9.2  | Recommends flattening the dependency graph                                                | <span class="g">✓</span>       | <span class="r">✗</span> no flattening suggested                  |
+| 9.3  | Suggests that most services should depend on repositories and config directly             | <span class="g">✓</span>       | <span class="r">✗</span> keeps transitive chain                   |
+| 9.4  | Explains negative consequences of deep chains (fragility, hard to test)                   | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 9.5  | Proposes a concrete restructuring                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **10. one-container-per-app-not-per-request** — container created once, not per request   | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                    |
+| 10.1 | Identifies creating a new container per request as a mistake                              | <span class="g">✓</span>       | <span class="r">✗</span> accepts per-request as reasonable        |
+| 10.2 | Recommends one container per application created at startup                               | <span class="g">✓</span>       | <span class="r">✗</span> no single-container guidance             |
+| 10.3 | Explains the performance/correctness problem (recreating singletons, no connection reuse) | <span class="g">✓</span>       | <span class="r">✗</span> no performance concern                   |
+| 10.4 | Suggests using scopes for request-level isolation if needed                               | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 10.5 | Shows the container being created once in `main()` and services injected into handlers    | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+|      | **11. lazy-vs-eager-initialization** — lazy init preference, singleton vs transient       | **<span class="r">4/5</span>** | **<span class="r">1/5</span>**                                    |
+| 11.1 | Recommends lazy initialization (services created on first use, not all at startup)        | <span class="g">✓</span>       | <span class="r">✗</span> recommends eager for everything          |
+| 11.2 | Recommends singletons for stateful services like database connections                     | <span class="g">✓</span>       | <span class="g">✓</span>                                          |
+| 11.3 | Recommends transients (or factories) for stateless request processing services            | <span class="g">✓</span>       | <span class="r">✗</span> all singletons                           |
+| 11.4 | Explains why lazy loading is beneficial (unused services never created, faster startup)   | <span class="r">✗</span>       | <span class="r">✗</span> no lazy benefits explained               |
+| 11.5 | Notes which DI libraries support lazy loading (samber/do, fx) vs which don't (wire)       | <span class="g">✓</span>       | <span class="r">✗</span> no library comparison for lazy           |
+
+</details>
+
+## `golang-dependency-management` — v1.0.0
+
+|             | With Skill       | Without Skill   | Delta     |
+| ----------- | ---------------- | --------------- | --------- |
+| **Overall** | **52/52 (100%)** | **24/52 (46%)** | **+54pp** |
+
+<details>
+<summary>Full breakdown (52 assertions across 11 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                     | With                           | Without                                                      |
+| ---- | --------------------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------ |
+|      | **1. ask-before-adding-dependency** — AI agent must ask before `go get`                       | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                               |
+| 1.1  | Asks the user for confirmation before running `go get`                                        | <span class="g">✓</span>       | <span class="r">✗</span> runs go get immediately             |
+| 1.2  | Presents the package name and import path                                                     | <span class="g">✓</span>       | <span class="r">✗</span> installs without showing path       |
+| 1.3  | Mentions whether the standard library covers the use case                                     | <span class="g">✓</span>       | <span class="r">✗</span> no stdlib mention                   |
+| 1.4  | Lists known alternatives                                                                      | <span class="g">✓</span>       | <span class="r">✗</span> suggests one library directly       |
+| 1.5  | Does NOT silently run `go get` without asking first                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **2. go-sum-must-be-committed** — go.sum is critical for supply-chain security                | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 2.1  | Strongly advises against gitignoring go.sum                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 2.2  | Explains that go.sum contains cryptographic checksums for dependency verification             | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 2.3  | Explains the supply-chain security risk: compromised proxy could substitute malicious code    | <span class="g">✓</span>       | <span class="r">✗</span> no supply-chain mention             |
+| 2.4  | Mentions `go mod verify` as the mechanism that uses go.sum                                    | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                       |
+| 2.5  | Recommends removing go.sum from .gitignore                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **3. patch-only-upgrade-preference** — `go get -u=patch` safer than `go get -u`               | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                               |
+| 3.1  | Recommends `go get -u=patch ./...` as the safer default                                       | <span class="g">✓</span>       | <span class="r">✗</span> recommends `go get -u ./...`        |
+| 3.2  | Explains that `-u=patch` only upgrades patch versions (no API changes per semver)             | <span class="g">✓</span>       | <span class="r">✗</span> no distinction made                 |
+| 3.3  | Explains that `-u` upgrades minor versions too, which can change behavior                     | <span class="g">✓</span>       | <span class="r">✗</span> no warning about minor              |
+| 3.4  | Mentions running `go mod tidy` after upgrading                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 3.5  | Does NOT recommend `go get -u ./...` without warning about risk                               | <span class="g">✓</span>       | <span class="r">✗</span> recommends it as primary            |
+|      | **4. mvs-algorithm-understanding** — Minimal Version Selection, not latest                    | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 4.1  | Correctly states that Go selects v1.3.0 (not the latest available)                            | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 4.2  | Explains MVS: Go picks the highest minimum required, not the latest available                 | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 4.3  | Distinguishes MVS from other package managers (npm, pip, cargo)                               | <span class="g">✓</span>       | <span class="r">✗</span> no comparison to other managers     |
+| 4.4  | Mentions that MVS provides deterministic builds without a lock file                           | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                       |
+| 4.5  | Explains that go.sum is integrity verification, not version locking                           | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **5. major-version-suffix-rule** — /v2 suffix for v2+ modules                                 | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                               |
+| 5.1  | States that the module path must include `/v2` suffix                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 5.2  | States that all import paths must be updated to include `/v2`                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 5.3  | Explains this is Go's import compatibility rule                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 5.4  | Mentions that v0 and v1 do NOT have a suffix                                                  | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                       |
+| 5.5  | Notes that v1 and v2 can coexist in the same build                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **6. replace-directive-library-warning** — replace ignored when consumed as dependency        | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                               |
+| 6.1  | States that replace directives only take effect in the main module's go.mod                   | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 6.2  | States that consumers will NOT use the fork                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 6.3  | Recommends removing replace directives before publishing a library                            | <span class="g">✓</span>       | <span class="r">✗</span> no publish warning                  |
+| 6.4  | Suggests alternative solutions (upstream the fix, publish fork as separate module)            | <span class="g">✓</span>       | <span class="r">✗</span> no alternatives offered             |
+|      | **7. tools-go-pattern** — pin CLI tool versions in go.mod                                     | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                               |
+| 7.1  | Recommends the tools.go pattern (file with `//go:build tools` constraint)                     | <span class="g">✓</span>       | <span class="r">✗</span> suggests `go install @latest` in CI |
+| 7.2  | Uses blank imports (`_` imports) to keep tools in go.mod                                      | <span class="g">✓</span>       | <span class="r">✗</span> no blank imports                    |
+| 7.3  | The build constraint ensures the file is never compiled into production code                  | <span class="g">✓</span>       | <span class="r">✗</span> no build constraint                 |
+| 7.4  | Mentions running `go mod tidy` after creating the tools.go file                               | <span class="g">✓</span>       | <span class="r">✗</span> no tidy mention                     |
+| 7.5  | Explains that `go install` then uses the pinned version from go.mod                           | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **8. govulncheck-call-path-analysis** — static analysis traces call paths to vulnerable funcs | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 8.1  | Recommends govulncheck to check if vulnerability is reachable                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 8.2  | Explains that govulncheck uses static analysis to trace call paths                            | <span class="g">✓</span>       | <span class="r">✗</span> no call-path explanation            |
+| 8.3  | Explains that if code never calls the affected function, govulncheck will NOT flag it         | <span class="g">✓</span>       | <span class="r">✗</span> not explained                       |
+| 8.4  | Shows the `govulncheck ./...` command                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 8.5  | Distinguishes govulncheck from generic CVE scanners                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **9. go-work-sum-gitignore** — go.work.sum should NOT be committed                            | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                               |
+| 9.1  | States that go.work.sum should NOT be committed                                               | <span class="g">✓</span>       | <span class="r">✗</span> suggests committing both            |
+| 9.2  | Recommends adding go.work.sum to .gitignore                                                   | <span class="g">✓</span>       | <span class="r">✗</span> no gitignore mention                |
+| 9.3  | Explains that go.work is for development only                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 9.4  | Distinguishes this from go.sum which MUST be committed                                        | <span class="g">✓</span>       | <span class="r">✗</span> treats both the same                |
+| 9.5  | May mention that go.work itself can optionally be committed                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **10. exclude-vs-retract-distinction** — exclude is consumer-side, retract is author-side     | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 10.1 | Uses `retract` for the published library (author-side)                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 10.2 | Uses `exclude` for the buggy dependency (consumer-side)                                       | <span class="g">✓</span>       | <span class="r">✗</span> uses replace instead                |
+| 10.3 | Explains that retract goes in the library's own go.mod                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 10.4 | Explains that exclude redirects to the next higher available version                          | <span class="g">✓</span>       | <span class="r">✗</span> no redirect behavior explained      |
+| 10.5 | Notes that retracted versions are still downloadable but not selected by default              | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **11. test-dependency-upgrade-flag** — `-t` flag for including test deps in upgrades          | **<span class="g">3/3</span>** | **<span class="r">1/3</span>**                               |
+| 11.1 | Explains that `go get -u ./...` excludes test-only dependencies by default                    | <span class="g">✓</span>       | <span class="r">✗</span> not explained                       |
+| 11.2 | Recommends `go get -u -t ./...` to include test dependencies                                  | <span class="g">✓</span>       | <span class="r">✗</span> suggests upgrading individually     |
+| 11.3 | Explains the difference between `-u` and `-u -t`                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+
+</details>
+
+## `golang-structs-interfaces` — v1.0.0
+
+|             | With Skill       | Without Skill   | Delta     |
+| ----------- | ---------------- | --------------- | --------- |
+| **Overall** | **52/52 (100%)** | **34/52 (65%)** | **+35pp** |
+
+<details>
+<summary>Full breakdown (52 assertions across 11 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                     | With                           | Without                                                       |
+| ---- | --------------------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------- |
+|      | **1. interface-at-consumer-not-implementor** — notification service using email client        | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                |
+| 1.1  | Interface is defined in the notification package (the consumer), NOT in the email package     | <span class="g">✓</span>       | <span class="r">✗</span> defines in email package             |
+| 1.2  | Interface has only the methods the notification package needs (not the full email.Client API) | <span class="g">✓</span>       | <span class="r">✗</span> mirrors full Client API              |
+| 1.3  | Email package exports a concrete Client struct, not an interface                              | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 1.4  | Explains WHY: keeps the consumer in control of the contract, avoids importing for interface   | <span class="g">✓</span>       | <span class="r">✗</span> no rationale given                   |
+| 1.5  | Notification service depends on its own interface, not on email package types                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **2. return-structs-not-interfaces** — NewUserService constructor signature                   | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 2.1  | Constructor returns *UserService (concrete type), NOT an interface                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 2.2  | Constructor accepts UserStore as an interface parameter (accept interfaces)                   | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 2.3  | Explains WHY: callers get full access to concrete type; consumers can assign to interface     | <span class="g">✓</span>       | <span class="r">✗</span> no rationale                         |
+| 2.4  | Explicitly states that returning interfaces from constructors is bad practice                 | <span class="g">✓</span>       | <span class="r">✗</span> presents both as valid               |
+| 2.5  | The accept-interfaces-return-structs principle is stated or demonstrated                      | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **3. premature-interface-trap** — single PostgreSQL implementation repository                 | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                |
+| 3.1  | Recommends starting with a concrete struct (not an interface) when only one implementation    | <span class="g">✓</span>       | <span class="r">✗</span> creates interface immediately        |
+| 3.2  | Mentions the principle: don't design with interfaces, discover them                           | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                        |
+| 3.3  | Suggests extracting an interface LATER when a second consumer or test mock demands it         | <span class="g">✓</span>       | <span class="r">✗</span> creates interface "for testability"  |
+| 3.4  | Acknowledges that testability IS a valid reason but it should be a deliberate choice          | <span class="g">✓</span>       | <span class="r">✗</span> reflexively adds interface           |
+| 3.5  | Does NOT reflexively recommend creating an interface just because it is a repository          | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **4. zero-value-useful-design** — Registry panics without NewRegistry                         | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                |
+| 4.1  | Recommends lazy initialization in the Register method (if r.items == nil)                     | <span class="g">✓</span>       | <span class="r">✗</span> says "always call constructor"       |
+| 4.2  | Mentions the Go principle: make the zero value useful                                         | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                        |
+| 4.3  | The fix allows using var r Registry without calling a constructor                             | <span class="g">✓</span>       | <span class="r">✗</span> requires constructor                 |
+| 4.4  | Does NOT just say "always use the constructor" as the primary fix                             | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 4.5  | References bytes.Buffer or sync.Mutex as stdlib examples of useful zero values                | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **5. embedding-vs-named-field** — Server with http.Handler and DataStore                      | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 5.1  | Embeds http.Handler (to promote ServeHTTP to the Server)                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 5.2  | Uses a named field for DataStore (not embedded, methods should not be exposed)                | <span class="g">✓</span>       | <span class="r">✗</span> embeds both                          |
+| 5.3  | Explains the embed vs named field rule: embed for "is a", named field for "has a"             | <span class="g">✓</span>       | <span class="r">✗</span> no rule articulated                  |
+| 5.4  | Mentions that embedding promotes ALL methods of the inner type, which can be undesirable      | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 5.5  | Notes that the receiver of promoted methods is the inner type, not the outer type             | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **6. compile-time-interface-check** — MyBuffer implements io.ReadWriter                       | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                |
+| 6.1  | Uses var _ io.ReadWriter = (*MyBuffer)(nil) pattern                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 6.2  | Places the check near the type definition                                                     | <span class="g">✓</span>       | <span class="r">✗</span> places in test file                  |
+| 6.3  | Explains that this costs nothing at runtime                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 6.4  | Explains that the build fails immediately if MyBuffer stops satisfying the interface          | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **7. type-assertion-comma-ok** — check if interface{} value is a string                       | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                                |
+| 7.1  | Uses the comma-ok form: s, ok := val.(string)                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 7.2  | Checks the ok value before using s                                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 7.3  | Warns against bare type assertion (s := val.(string)) because it panics                       | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 7.4  | Handles the !ok case explicitly                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **8. optional-behavior-type-assertion** — flush only if writer supports it                    | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                |
+| 8.1  | Defines a separate Flusher interface with just the Flush method                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 8.2  | Function parameter is io.Writer (not a combined interface)                                    | <span class="g">✓</span>       | <span class="r">✗</span> requires WriteFlusher interface      |
+| 8.3  | Uses type assertion (f, ok := w.(Flusher)) to check for flush capability                      | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 8.4  | Only calls Flush if the type assertion succeeds                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 8.5  | Mentions this pattern is used in the standard library (e.g. http.Flusher, io.ReaderFrom)      | <span class="g">✓</span>       | <span class="r">✗</span> no stdlib reference                  |
+|      | **9. nocopy-sentinel-struct** — prevent ConnPool from being passed by value                   | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                |
+| 9.1  | Recommends embedding a noCopy sentinel struct                                                 | <span class="g">✓</span>       | <span class="r">✗</span> says "always use pointers"           |
+| 9.2  | noCopy implements Lock() and Unlock() methods (empty bodies)                                  | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                        |
+| 9.3  | Explains that go vet will flag copies of structs containing noCopy                            | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                        |
+| 9.4  | Mentions this is the same technique used by sync.WaitGroup, sync.Mutex, or strings.Builder    | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                        |
+| 9.5  | Shows that the struct should be passed by pointer after adding noCopy                         | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+|      | **10. generics-over-any-interface** — generic Contains function for any comparable type       | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                |
+| 10.1 | Uses generics with a type parameter: func Contains[T comparable]                              | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 10.2 | Does NOT use []any or interface{} parameters                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 10.3 | Uses the comparable constraint for the type parameter                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 10.4 | Explains WHY: generics preserve type safety, while any loses it                               | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 10.5 | Mentions that any should only be used at true boundaries where type is genuinely unknown      | <span class="g">✓</span>       | <span class="r">✗</span> no boundary guidance                 |
+|      | **11. receiver-consistency-rule** — mixed pointer/value receivers on same type                | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                |
+| 11.1 | Says mixing pointer and value receivers on the same type is wrong or not recommended          | <span class="g">✓</span>       | <span class="r">✗</span> says mixing is fine per-method       |
+| 11.2 | Recommends making ALL methods use pointer receivers since one needs to mutate                 | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+| 11.3 | Explains WHY: consistency rule -- if any method uses a pointer receiver, all should           | <span class="g">✓</span>       | <span class="r">✗</span> no consistency principle articulated |
+| 11.4 | Mentions that method sets differ for T and *T which affects interface satisfaction            | <span class="g">✓</span>       | <span class="g">✓</span>                                      |
+
+</details>
+
+## `golang-lint` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **49/51 (96%)** | **28/51 (55%)** | **+41pp** |
+
+<details>
+<summary>Full breakdown (51 assertions across 11 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                          | With                           | Without                                                      |
+| ---- | -------------------------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------ |
+|      | **1. nolint-directive-specificity** — linter name + justification on every //nolint                | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 1.1  | Every //nolint specifies the linter name — no bare //nolint                                        | <span class="g">✓</span>       | <span class="r">✗</span> bare //nolint on 3 lines            |
+| 1.2  | Every //nolint includes a justification comment                                                    | <span class="g">✓</span>       | <span class="r">✗</span> no justifications                   |
+| 1.3  | Type assertion uses //nolint:forcetypeassert with safety explanation                               | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 1.4  | Long test uses //nolint:funlen with table-driven justification                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 1.5  | Cyclomatic complexity uses //nolint:gocyclo with orchestration justification                       | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **2. nolint-fix-vs-suppress-judgment** — fix correctness bugs, suppress style issues               | **<span class="g">6/6</span>** | **<span class="g">4/6</span>**                               |
+| 2.1  | Recommends FIXING bodyclose — unclosed response bodies leak connections                            | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 2.2  | Recommends SUPPRESSING funlen on table-driven test                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 2.3  | Recommends FIXING errcheck on database query in request handler                                    | <span class="g">✓</span>       | <span class="r">✗</span> suppressed as "not critical"        |
+| 2.4  | Recommends SUPPRESSING dupl on intentional parallel structure                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 2.5  | Recommends FIXING sqlclosecheck — unclosed sql.Rows leak connections                               | <span class="g">✓</span>       | <span class="r">✗</span> suppressed with defer comment       |
+| 2.6  | Recommends SUPPRESSING goconst in tests                                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **3. golangci-yml-version-2-structure** — version: "2", formatters section, linters.enable         | **<span class="g">4/5</span>** | **<span class="r">1/5</span>**                               |
+| 3.1  | Config has version: "2" at the top                                                                 | <span class="g">✓</span>       | <span class="r">✗</span> no version field                    |
+| 3.2  | Linters listed under linters.enable (not enable-all)                                               | <span class="g">✓</span>       | <span class="r">✗</span> uses enable-all with disable list   |
+| 3.3  | gofumpt under formatters.enable, NOT linters.enable                                                | <span class="g">✓</span>       | <span class="r">✗</span> gofumpt in linters.enable           |
+| 3.4  | errcheck has check-type-assertions: true in linters.settings                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 3.5  | Timeout set under run.timeout: 5m                                                                  | <span class="r">✗</span>       | <span class="r">✗</span>                                     |
+|      | **4. linter-categories-correctness-vs-style** — prioritize bug-finding over style                  | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 4.1  | Includes govet and staticcheck as highest-value correctness linters                                | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 4.2  | Includes errcheck for unchecked errors                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 4.3  | Prioritizes correctness/safety over style linters                                                  | <span class="g">✓</span>       | <span class="r">✗</span> revive and godot ranked above gosec |
+| 4.4  | Includes at least one security linter (bodyclose, gosec, sqlclosecheck)                            | <span class="g">✓</span>       | <span class="r">✗</span> no security linters in top 10       |
+| 4.5  | Does NOT include redundant complexity checkers (gocyclo + cyclop)                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **5. legacy-codebase-incremental-adoption** — new-from-rev, not mass //nolint                      | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 5.1  | Recommends issues.new-from-rev to only lint new/changed code                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 5.2  | Does NOT suggest adding //nolint to all 2000+ warnings                                             | <span class="g">✓</span>       | <span class="r">✗</span> suggests mass //nolint annotations  |
+| 5.3  | Suggests gradual cleanup of old code over time                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 5.4  | Suggests golangci-lint run --fix for auto-fixable issues                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 5.5  | Mentions parallel sub-agents or batching fixes by category                                         | <span class="g">✓</span>       | <span class="r">✗</span> sequential manual cleanup           |
+|      | **6. interpreting-lint-output-format** — use linter name to triage fix vs suppress                 | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 6.1  | Identifies errcheck on DB.Close as real issue to fix                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 6.2  | Identifies bodyclose as critical resource leak to fix                                              | <span class="g">✓</span>       | <span class="r">✗</span> treats all warnings equally         |
+| 6.3  | Identifies unused validateToken as dead code to remove                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 6.4  | Evaluates gocyclo based on function nature (orchestration vs complex)                              | <span class="g">✓</span>       | <span class="r">✗</span> blanket "refactor" recommendation   |
+| 6.5  | Identifies revive comment warning as lower-priority style issue                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **7. disabled-linters-with-rationale** — exhaustruct, gochecknoglobals, wrapcheck, mnd, varnamelen | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 7.1  | Recommends AGAINST exhaustruct — breaks zero-value idiom                                           | <span class="g">✓</span>       | <span class="r">✗</span> enables it for "completeness"       |
+| 7.2  | Recommends AGAINST gochecknoglobals — valid global uses exist                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 7.3  | Recommends AGAINST wrapcheck as default — too noisy                                                | <span class="g">✓</span>       | <span class="r">✗</span> enables it unconditionally          |
+| 7.4  | Recommends AGAINST mnd — flags obvious constants like HTTP status codes                            | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 7.5  | Recommends AGAINST varnamelen — conflicts with Go's short name idiom                               | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **8. nolintlint-meta-linter** — enforce proper //nolint hygiene automatically                      | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                               |
+| 8.1  | Recommends enabling nolintlint linter                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 8.2  | Configures require-specific: true                                                                  | <span class="g">✓</span>       | <span class="r">✗</span> no nolintlint config                |
+| 8.3  | Configures require-explanation: true                                                               | <span class="g">✓</span>       | <span class="r">✗</span> no nolintlint config                |
+| 8.4  | Shows correct location: linters.settings.nolintlint                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **9. multiple-nolint-comma-syntax** — comma-separated linters in single directive                  | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                               |
+| 9.1  | Uses comma-separated: //nolint:errcheck,gosec — not two directives                                 | <span class="g">✓</span>       | <span class="r">✗</span> two separate //nolint lines         |
+| 9.2  | Includes justification explaining both false positives                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 9.3  | Directive on same line as flagged code or line above                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **10. common-config-issues** — timeout, v1-to-v2 migration, linter-not-found                       | **<span class="r">3/4</span>** | **<span class="r">2/4</span>**                               |
+| 10.1 | Recommends increasing run.timeout for deadline exceeded                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 10.2 | Recommends golangci-lint migrate for v1 config errors                                              | <span class="g">✓</span>       | <span class="r">✗</span> suggests manual rewrite             |
+| 10.3 | For linter not found: check version — modernize requires v2.6.0+                                   | <span class="g">✓</span>       | <span class="r">✗</span> suggests reinstalling               |
+| 10.4 | Mentions golangci-lint linters to check available linters                                          | <span class="r">✗</span>       | <span class="g">✓</span>                                     |
+|      | **11. formatter-vs-linter-distinction** — formatters section, fmt subcommand                       | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                               |
+| 11.1 | gofumpt under formatters.enable, NOT linters.enable                                                | <span class="g">✓</span>       | <span class="r">✗</span> linters.enable                      |
+| 11.2 | Sets gofumpt extra-rules: true under formatters.settings                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 11.3 | Mentions golangci-lint fmt ./... command for formatting                                            | <span class="g">✓</span>       | <span class="r">✗</span> only golangci-lint run              |
+| 11.4 | Notes gci and goimports are redundant with gofumpt                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+
+</details>
+
+## `golang-popular-libraries` — v1.0.0
+
+|             | With Skill       | Without Skill   | Delta     |
+| ----------- | ---------------- | --------------- | --------- |
+| **Overall** | **54/54 (100%)** | **38/54 (70%)** | **+30pp** |
+
+<details>
+<summary>Full breakdown (54 assertions across 11 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                | With                           | Without                                                         |
+| ---- | ---------------------------------------------------------------------------------------- | ------------------------------ | --------------------------------------------------------------- |
+|      | **1. stdlib-first-json** — encoding/json before third-party                              | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                  |
+| 1.1  | Recommends encoding/json as the first option                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 1.2  | Third-party alternatives only for specific performance needs                             | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 1.3  | Explains stdlib is sufficient for most JSON use cases                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 1.4  | Alternatives presented for measured performance requirements                             | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 1.5  | Does NOT recommend third-party without first considering stdlib                          | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+|      | **2. pgx-over-lib-pq** — pgx as primary PostgreSQL driver                                | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                  |
+| 2.1  | Recommends pgx as the primary recommendation                                             | <span class="g">✓</span>       | <span class="r">✗</span> lib/pq as primary                      |
+| 2.2  | Mentions pgx is faster than lib/pq                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 2.3  | Notes pgx supports all PostgreSQL types and advanced features                            | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 2.4  | May mention lib/pq but positions pgx as preferred                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 2.5  | Does NOT recommend lib/pq as primary without mentioning pgx                              | <span class="g">✓</span>       | <span class="r">✗</span> lib/pq recommended first               |
+|      | **3. chi-for-minimal-router** — chi when staying close to net/http                       | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                  |
+| 3.1  | Recommends chi as a strong match for stated requirements                                 | <span class="g">✓</span>       | <span class="r">✗</span> recommends Gin                         |
+| 3.2  | Explains chi is lightweight and composes with net/http                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 3.3  | Notes chi has minimal dependencies                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 3.4  | May mention Gin/Echo but positions chi as better fit for net/http                        | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 3.5  | Does NOT recommend a full framework as primary when user wants to stay close to net/http | <span class="g">✓</span>       | <span class="r">✗</span> Gin as primary recommendation          |
+|      | **4. slog-over-external-loggers** — consider log/slog before zap/zerolog                 | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                  |
+| 4.1  | Mentions log/slog as standard library option (Go 1.21+)                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 4.2  | Presents slog as a viable option, not afterthought                                       | <span class="g">✓</span>       | <span class="r">✗</span> brief mention at end                   |
+| 4.3  | If recommending external, explains specific value over slog                              | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 4.4  | Does NOT skip standard library consideration entirely                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 4.5  | May mention zap/zerolog for specific use cases                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+|      | **5. sqlc-vs-orm-decision** — sqlc for compile-time SQL safety                           | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                  |
+| 5.1  | Recommends sqlc as a primary option for compile-time SQL safety                          | <span class="g">✓</span>       | <span class="r">✗</span> recommends GORM only                   |
+| 5.2  | Explains sqlc generates type-safe code with no runtime reflection                        | <span class="g">✓</span>       | <span class="r">✗</span> no mention of sqlc                     |
+| 5.3  | Mentions GORM uses runtime reflection — doesn't catch SQL errors at compile time         | <span class="g">✓</span>       | <span class="r">✗</span> GORM presented without caveat          |
+| 5.4  | May also mention ent as a code-generated alternative                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 5.5  | Does NOT recommend only GORM when user asks for compile-time safety                      | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+|      | **6. rate-limiter-stdlib-first** — golang.org/x/time/rate before third-party             | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                  |
+| 6.1  | Recommends golang.org/x/time/rate as official option                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 6.2  | Explains token bucket algorithm                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 6.3  | May mention Tollbooth/limiter for HTTP middleware integration                            | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 6.4  | Does NOT skip the official x/time/rate package                                           | <span class="g">✓</span>       | <span class="r">✗</span> no mention of x/time/rate              |
+| 6.5  | Explains when third-party might be preferred (per-IP, distributed)                       | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+|      | **7. franz-go-for-kafka** — franz-go over legacy sarama                                  | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                  |
+| 7.1  | Recommends franz-go as primary recommendation                                            | <span class="g">✓</span>       | <span class="r">✗</span> sarama as primary                      |
+| 7.2  | Describes franz-go as modern, high-performance, feature-complete                         | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 7.3  | Does NOT recommend only sarama without mentioning franz-go                               | <span class="g">✓</span>       | <span class="r">✗</span> only sarama mentioned                  |
+| 7.4  | May mention sarama but positions franz-go as preferred modern choice                     | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+|      | **8. check-maintenance-before-recommending** — Logrus deprecated, suggest alternatives   | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                  |
+| 8.1  | Mentions Logrus is deprecated or in maintenance mode                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 8.2  | Suggests alternatives: slog, zap, or zerolog                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 8.3  | Explains maintained alternatives preferred for new projects                              | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 8.4  | Does NOT unconditionally recommend Logrus without deprecation note                       | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 8.5  | Prioritizes maturity and maintenance status                                              | <span class="g">✓</span>       | <span class="r">✗</span> mentions deprecation but still says OK |
+|      | **9. avoid-unnecessary-wrappers** — warn against thin stdlib wrappers                    | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                  |
+| 9.1  | Warns against wrapping stdlib without meaningful value                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 9.2  | Explains dependencies increase attack surface and maintenance burden                     | <span class="g">✓</span>       | <span class="r">✗</span> no mention of dependency cost          |
+| 9.3  | Recommends evaluating whether net/http itself is sufficient                              | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 9.4  | Mentions anti-pattern of adding dependencies for marginal convenience                    | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 9.5  | Suggests considering dependency footprint relative to value                              | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+|      | **10. testcontainers-for-integration** — testcontainers-go for real service testing      | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                  |
+| 10.1 | Recommends testcontainers-go for programmatic integration testing                        | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 10.2 | Explains testcontainers-go spins up real Docker containers                               | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 10.3 | Shows or describes container lifecycle within tests                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 10.4 | Positions it as better than manual Docker Compose for test isolation                     | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 10.5 | May also mention go-sqlmock for unit-level database testing                              | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+|      | **11. slices-maps-packages-go121** — stdlib slices/maps before external utility libs     | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                  |
+| 11.1 | Recommends stdlib slices package (Go 1.21+) for Contains, Sort, Reverse                  | <span class="g">✓</span>       | <span class="r">✗</span> recommends samber/lo for everything    |
+| 11.2 | Does NOT recommend only external libs for basic slice ops                                | <span class="g">✓</span>       | <span class="r">✗</span> samber/lo as sole recommendation       |
+| 11.3 | May mention samber/lo for functional ops (Map, Filter, Reduce)                           | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 11.4 | Distinguishes stdlib-covered ops from those requiring external libs                      | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+| 11.5 | Applies the 'standard library first' principle                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                        |
+
+</details>
+
+## `golang-project-layout` — v1.0.0
+
+|             | With Skill       | Without Skill   | Delta     |
+| ----------- | ---------------- | --------------- | --------- |
+| **Overall** | **55/55 (100%)** | **34/55 (62%)** | **+38pp** |
+
+<details>
+<summary>Full breakdown (55 assertions across 11 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                                                                 | With                           | Without                                                                                   |
+| ---- | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | ----------------------------------------------------------------------------------------- |
+|      | **1. ask-architecture-before-structuring** — Tests whether the model asks the developer about architecture preference before imposing one | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                                            |
+| 1.1  | Asks the developer which software architecture they prefer (clean, hexagonal, DDD, flat, etc.)                                            | <span class="g">✓</span>       | <span class="r">✗</span> immediately generates a structure                                |
+| 1.2  | Asks about the project scope/size to right-size the structure                                                                             | <span class="g">✓</span>       | <span class="r">✗</span> assumes medium-large project                                     |
+| 1.3  | Does NOT immediately impose a specific architecture without asking                                                                        | <span class="g">✓</span>       | <span class="r">✗</span> imposes clean architecture                                       |
+| 1.4  | Mentions dependency injection approach as a follow-up question                                                                            | <span class="g">✓</span>       | <span class="r">✗</span> no DI question                                                   |
+| 1.5  | Mentions that small projects should not be over-structured                                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+|      | **2. cmd-directory-minimal-logic** — Tests whether the model keeps cmd/ main.go minimal with no business logic                            | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                                            |
+| 2.1  | Says business logic does NOT belong in cmd/server/main.go                                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 2.2  | Says cmd/ should contain minimal logic: parse flags, wire dependencies, call Run()                                                        | <span class="g">✓</span>       | <span class="r">✗</span> says "mostly initialization" without being specific              |
+| 2.3  | Recommends moving business logic to internal/ or pkg/                                                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 2.4  | main.go should primarily do dependency wiring and startup                                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 2.5  | NEVER put request parsing, database queries, or response formatting in cmd/                                                               | <span class="g">✓</span>       | <span class="r">✗</span> not explicitly stated                                            |
+|      | **3. no-src-utils-helpers-common** — Tests whether the model avoids Java-style src/ directory and generic package names                   | **<span class="g">6/6</span>** | **<span class="r">4/6</span>**                                                            |
+| 3.1  | Rejects src/ directory (Go doesn't use /src, it's a Java pattern)                                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 3.2  | Rejects utils/ as a generic package name                                                                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 3.3  | Rejects helpers/ as a generic package name                                                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 3.4  | Rejects common/ as a generic package name                                                                                                 | <span class="g">✓</span>       | <span class="r">✗</span> accepts common/ as reasonable                                    |
+| 3.5  | Suggests domain-specific package names instead (e.g. format/, stringconv/)                                                                | <span class="g">✓</span>       | <span class="r">✗</span> suggests renaming to "shared/"                                   |
+| 3.6  | Recommends putting main.go inside cmd/{name}/ not at root or in src/                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+|      | **4. module-naming-conventions** — Tests whether the model follows Go module naming conventions                                           | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                                            |
+| 4.1  | Identifies option 3 (github.com/jdoe/my-project) as correct                                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 4.2  | Rejects option 1 (myproject) -- must match repository URL                                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 4.3  | Rejects option 2 (MyProject) -- must be lowercase only                                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 4.4  | Rejects option 4 (my_project) -- use hyphens not underscores                                                                              | <span class="g">✓</span>       | <span class="r">✗</span> accepts underscores as valid                                     |
+| 4.5  | Rejects option 5 (utils) -- not semantic, doesn't match a repo URL                                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+|      | **5. internal-vs-pkg-decision** — Tests whether the model correctly decides between internal/ and pkg/                                    | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                                            |
+| 5.1  | Puts the shared logging library in pkg/ (useful to external consumers)                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 5.2  | Puts the private request parsing code in internal/ (not exported)                                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 5.3  | Explains that internal/ cannot be imported by external packages (Go enforces this)                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 5.4  | Mentions that pkg/ should only be used when code is genuinely intended for external use                                                   | <span class="g">✓</span>       | <span class="r">✗</span> treats pkg/ as default location                                  |
+| 5.5  | Service/business logic goes in internal/ by default                                                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+|      | **6. workspace-when-to-use** — Tests whether the model recommends go.work only for multi-module scenarios                                 | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                                                            |
+| 6.1  | Recommends AGAINST using go.work for a single-module project                                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 6.2  | Explains that go.work is for multiple related Go modules that import each other                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 6.3  | Mentions that a single module with multiple packages does not need a workspace                                                            | <span class="g">✓</span>       | <span class="r">✗</span> not explicitly stated                                            |
+| 6.4  | Lists valid use cases: monorepo with separate modules, local cross-module development                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+|      | **7. twelve-factor-app-conventions** — Tests whether the model applies 12-Factor App principles for Go services                           | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                                            |
+| 7.1  | Recommends reading database URL from environment variables, not a checked-in config file                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 7.2  | Recommends writing logs to stdout, not to a file                                                                                          | <span class="g">✓</span>       | <span class="r">✗</span> says file logging is fine for development                        |
+| 7.3  | References or describes 12-Factor App principles                                                                                          | <span class="g">✓</span>       | <span class="r">✗</span> no 12-Factor reference                                           |
+| 7.4  | Mentions that sensitive values (like DB URLs) should never be in config files committed to source control                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 7.5  | Explains WHY: environment-based config allows different values per deployment without code changes                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+|      | **8. library-layout-no-cmd** — Tests whether the model uses the correct layout for a Go library                                           | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                                            |
+| 8.1  | Public API packages are at the root level (e.g. logger/), NOT inside pkg/ or cmd/                                                         | <span class="g">✓</span>       | <span class="r">✗</span> puts public API in pkg/                                          |
+| 8.2  | No cmd/ directory (unless for example binaries)                                                                                           | <span class="g">✓</span>       | <span class="r">✗</span> includes cmd/ with example binary                                |
+| 8.3  | Uses internal/ for private implementation details                                                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 8.4  | Includes example/ directory for usage examples                                                                                            | <span class="g">✓</span>       | <span class="r">✗</span> no example directory                                             |
+| 8.5  | Structure follows the library layout pattern, not the application layout pattern                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+|      | **9. test-file-colocation** — Tests whether the model co-locates test files with the code they test                                       | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                                            |
+| 9.1  | Recommends co-locating test files with the code they test (same directory)                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 9.2  | Test files use the _test.go suffix                                                                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 9.3  | Does NOT recommend a centralized tests/ directory for unit tests                                                                          | <span class="g">✓</span>       | <span class="r">✗</span> suggests tests/ for integration tests alongside unit co-location |
+| 9.4  | Mentions testdata/ directory for test fixtures                                                                                            | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned                                                    |
+| 9.5  | Distinguishes between white-box (same package) and black-box (package_test) testing approaches                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+|      | **10. config-sensitive-values-env-only** — Tests whether the model requires sensitive config values from env vars or secret managers      | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                                            |
+| 10.1 | Rejects putting database password, API keys, and JWT secret in config.yaml                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 10.2 | Recommends environment variables for sensitive values                                                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 10.3 | May suggest a secret manager as an alternative                                                                                            | <span class="g">✓</span>       | <span class="r">✗</span> only mentions env vars                                           |
+| 10.4 | Config files are acceptable for non-sensitive values (port, log level, etc.)                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 10.5 | Explains WHY: config files can be accidentally committed, leaked in backups, or visible to other processes                                | <span class="g">✓</span>       | <span class="r">✗</span> says "security best practice" without explaining why             |
+|      | **11. multiple-binaries-cmd-structure** — Tests whether the model creates separate subdirectories in cmd/ for each binary                 | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                                            |
+| 11.1 | Creates separate subdirectories: cmd/server/, cmd/cli/, cmd/migrate/ (or similar names)                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 11.2 | Each subdirectory has its own main.go with package main                                                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 11.3 | Each binary can be built independently (go build ./cmd/server, etc.)                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+| 11.4 | Mentions go build ./cmd/... to build all binaries at once                                                                                 | <span class="g">✓</span>       | <span class="r">✗</span> only shows individual builds                                     |
+| 11.5 | Business logic is in internal/, not duplicated across cmd/ directories                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                                                  |
+
+</details>
+
+## `golang-stay-updated` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **46/50 (92%)** | **18/50 (36%)** | **+56pp** |
+
+<details>
+<summary>Full breakdown (50 assertions across 10 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                                     | With                                                 | Without                                                  |
+| ---- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | -------------------------------------------------------- |
+|      | **1. go-newsletters-recommendation** — Tests whether the model recommends specific Go newsletters             | **<span class="g">5/5</span>**                       | **<span class="r">2/5</span>**                           |
+| 1.1  | Recommends Golang Weekly (golangweekly.com)                                                                   | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 1.2  | Recommends Awesome Go Newsletter (go.libhunt.com)                                                             | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 1.3  | Advises subscribing to 1-2 newsletters to avoid overload                                                      | <span class="g">✓</span>                             | <span class="r">✗</span> no quantity advice              |
+| 1.4  | Mentions these provide curated content, articles, and library updates                                         | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 1.5  | Does not recommend more than 3-4 newsletters (quality over quantity)                                          | <span class="g">✓</span>                             | <span class="r">✗</span> lists 5+ newsletters            |
+|      | **2. go-community-channels** — Tests knowledge of specific Go community channels beyond Reddit                | **<span class="g">5/5</span>**                       | **<span class="r">2/5</span>**                           |
+| 2.1  | Mentions r/golang subreddit                                                                                   | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 2.2  | Mentions gophers.slack.com (official Go Slack)                                                                | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 2.3  | Mentions the Go Forum (forum.golangbridge.org)                                                                | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 2.4  | Mentions golang-nuts Google Group (groups.google.com/g/golang-nuts)                                           | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 2.5  | Mentions the official Go wiki (go.dev/wiki)                                                                   | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+|      | **3. go-youtube-channels** — Tests knowledge of specific Go YouTube channels                                  | **<span class="g">5/5</span>**                       | **<span class="r">2/5</span>**                           |
+| 3.1  | Recommends the official Go YouTube channel (@golang)                                                          | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 3.2  | Recommends Gopher Academy                                                                                     | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 3.3  | Recommends GopherCon Europe or GopherCon UK channels                                                          | <span class="g">✓</span>                             | <span class="r">✗</span> only mentions generic GopherCon |
+| 3.4  | Recommends Ardan Labs channel                                                                                 | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 3.5  | Lists at least 3 distinct Go-specific YouTube channels                                                        | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+|      | **4. famous-go-core-team-members** — Tests knowledge of Go core team members to follow                        | **<span class="g">5/6</span>**                       | **<span class="r">3/6</span>**                           |
+| 4.1  | Mentions Rob Pike as a co-creator                                                                             | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 4.2  | Mentions Russ Cox and his role in Go                                                                          | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 4.3  | Mentions Brad Fitzpatrick                                                                                     | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 4.4  | Mentions Dave Cheney as an influential Go community member                                                    | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 4.5  | Mentions Robert Griesemer as a co-creator                                                                     | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 4.6  | Provides social media handles or GitHub usernames for at least 3 people                                       | <span class="r">✗</span> handles provided for only 2 | <span class="r">✗</span> no handles provided             |
+|      | **5. go-library-authors-to-follow** — Tests knowledge of influential Go library/framework authors             | **<span class="g">5/5</span>**                       | **<span class="r">2/5</span>**                           |
+| 5.1  | Mentions Steve Francia (spf13) — Cobra, Viper, Hugo                                                           | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 5.2  | Mentions Mitchell Hashimoto (mitchellh) — Terraform, Consul, Vault                                            | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 5.3  | Mentions Samuel Berthe (samber) — lo, do, oops                                                                | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 5.4  | Mentions Matt Holt (mholt) — Caddy                                                                            | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 5.5  | Provides GitHub usernames or X handles for the recommended people                                             | <span class="g">✓</span>                             | <span class="r">✗</span> names only, no handles          |
+|      | **6. official-go-resources** — Tests knowledge of official Go resources and tools                             | **<span class="g">5/5</span>**                       | **<span class="r">3/5</span>**                           |
+| 6.1  | Mentions go.dev as the official Go website                                                                    | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 6.2  | Mentions pkg.go.dev for package discovery and documentation                                                   | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 6.3  | Mentions tour.golang.org (Go Tour) for interactive learning                                                   | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 6.4  | Mentions play.golang.org (Go Playground) for testing code                                                     | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 6.5  | Mentions go.dev/blog (official Go blog) for announcements                                                     | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+|      | **7. go-blogs-to-follow** — Tests knowledge of must-follow Go blogs                                           | **<span class="g">4/4</span>**                       | **<span class="r">2/4</span>**                           |
+| 7.1  | Mentions The Go Blog (go.dev/blog)                                                                            | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 7.2  | Mentions Dave Cheney's blog (dave.cheney.net)                                                                 | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 7.3  | Mentions Ardan Labs Blog (ardanlabs.com/blog)                                                                 | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 7.4  | Lists at least 3 specific blog names with URLs or authors                                                     | <span class="g">✓</span>                             | <span class="r">✗</span> only 2 blogs listed             |
+|      | **8. staying-updated-strategy** — Tests the curated strategy for staying updated without information overload | **<span class="g">5/5</span>**                       | **<span class="r">0/5</span>**                           |
+| 8.1  | Recommends subscribing to 1-2 newsletters specifically (not more)                                             | <span class="g">✓</span>                             | <span class="r">✗</span> no specific quantity            |
+| 8.2  | Recommends following 10-20 key people on social media                                                         | <span class="g">✓</span>                             | <span class="r">✗</span> no specific number              |
+| 8.3  | Recommends checking go.dev/blog weekly for official announcements                                             | <span class="g">✓</span>                             | <span class="r">✗</span> says "regularly" not "weekly"   |
+| 8.4  | Recommends joining Go Slack for real-time discussions                                                         | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 8.5  | Recommends attending GopherCon (virtual or in-person) yearly                                                  | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+|      | **9. go-conference-speakers** — Tests knowledge of Go conference speakers and community leaders               | **<span class="g">3/5</span>**                       | **<span class="r">1/5</span>**                           |
+| 9.1  | Mentions at least one of: Carlisia Campos, Erik St. Martin, Brian Ketelsen                                    | <span class="r">✗</span> none of the three mentioned | <span class="r">✗</span> none mentioned                  |
+| 9.2  | Mentions Mat Ryer or Johnny Boursiquot as Go educators/speakers                                               | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 9.3  | Mentions GopherCon as the conference to follow                                                                | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 9.4  | Provides specific names with their social handles or GitHub profiles                                          | <span class="r">✗</span> names without handles       | <span class="r">✗</span> no handles                      |
+| 9.5  | Lists at least 4 distinct speakers/community leaders                                                          | <span class="g">✓</span>                             | <span class="r">✗</span> only 2 named                    |
+|      | **10. go-performance-experts** — Tests knowledge of Go performance and optimization experts                   | **<span class="g">4/5</span>**                       | **<span class="r">1/5</span>**                           |
+| 10.1 | Mentions Dmitry Vyukov as a Go performance expert                                                             | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+| 10.2 | Mentions Dave Cheney for performance-related Go content                                                       | <span class="g">✓</span>                             | <span class="g">✓</span>                                 |
+| 10.3 | Provides GitHub usernames (e.g., dvyukov, davecheney)                                                         | <span class="g">✓</span>                             | <span class="r">✗</span> no usernames                    |
+| 10.4 | Mentions Bill Kennedy / Ardan Labs for Go performance training                                                | <span class="r">✗</span> not mentioned               | <span class="r">✗</span> not mentioned                   |
+| 10.5 | Mentions Jaana Dogan (rakyll) for Go internals/performance                                                    | <span class="g">✓</span>                             | <span class="r">✗</span> not mentioned                   |
+
+</details>
+
+## `golang-database` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **70/74 (95%)** | **42/74 (57%)** | **+38pp** |
+
+<details>
+<summary>Full breakdown (74 assertions across 15 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                    | With                           | Without                                                      |
+| ---- | -------------------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------ |
+|      | **1. orm-vs-sqlx-pgx-recommendation** — sqlx/pgx over ORMs, explain why ORMs are harmful     | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                               |
+| 1.1  | Recommends sqlx or pgx instead of GORM                                                       | <span class="g">✓</span>       | <span class="r">✗</span> sets up GORM as primary             |
+| 1.2  | Explains why ORMs are problematic (N+1, unpredictable SQL, magic hooks, debugging)           | <span class="g">✓</span>       | <span class="r">✗</span> presents GORM positively            |
+| 1.3  | Recommends pgx specifically for PostgreSQL due to performance advantage                      | <span class="g">✓</span>       | <span class="r">✗</span> no mention of pgx                   |
+| 1.4  | Does NOT set up GORM or ent as the primary database library                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 1.5  | Mentions learning ORM API is harder than SQL or that ORMs hide SQL                           | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **2. exec-vs-query-for-non-select** — use Exec for DELETE/INSERT/UPDATE, not Query           | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 2.1  | Uses ExecContext (not QueryContext) for the DELETE statement                                 | <span class="g">✓</span>       | <span class="r">✗</span> db.QueryContext for DELETE          |
+| 2.2  | Uses the *Context variant (ExecContext, not Exec)                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 2.3  | Passes ctx to the database call                                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 2.4  | Retrieves RowsAffected() from the result                                                     | <span class="g">✓</span>       | <span class="r">✗</span> discards result                     |
+| 2.5  | Uses parameterized query (not string concatenation)                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **3. nullable-column-handling** — pointer fields over sql.NullXxx for NULLable columns       | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                               |
+| 3.1  | Uses pointer types (*string, *time.Time) rather than sql.NullString/sql.NullTime             | <span class="g">✓</span>       | <span class="r">✗</span> sql.NullString and sql.NullTime     |
+| 3.2  | Includes db struct tags for sqlx (db:"column_name")                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 3.3  | Includes json struct tags                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 3.4  | Uses json:"bio,omitempty" for bio (omitted when NULL)                                        | <span class="g">✓</span>       | <span class="r">✗</span> no omitempty distinction            |
+| 3.5  | Uses json:"deleted_at" without omitempty (appears as null)                                   | <span class="g">✓</span>       | <span class="r">✗</span> omitempty on both nullable fields   |
+|      | **4. connection-pool-configuration** — all four pool settings with reasonable values         | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                               |
+| 4.1  | Calls SetMaxOpenConns                                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 4.2  | Calls SetMaxIdleConns                                                                        | <span class="g">✓</span>       | <span class="r">✗</span> not set                             |
+| 4.3  | Calls SetConnMaxLifetime                                                                     | <span class="g">✓</span>       | <span class="r">✗</span> not set                             |
+| 4.4  | Calls SetConnMaxIdleTime                                                                     | <span class="g">✓</span>       | <span class="r">✗</span> not set                             |
+| 4.5  | MaxIdleConns <= MaxOpenConns                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **5. rows-close-and-err-check** — defer Close and rows.Err() check after loop                | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                               |
+| 5.1  | Calls defer rows.Close() immediately after QueryContext                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 5.2  | Checks rows.Err() after the for rows.Next() loop                                             | <span class="g">✓</span>       | <span class="r">✗</span> no rows.Err() check                 |
+| 5.3  | Returns the error from rows.Err() if non-nil                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 5.4  | Uses QueryContext (not Query) with a context parameter                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 5.5  | Checks the error returned by QueryContext before proceeding                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **6. errnorows-handling-pattern** — sql.ErrNoRows with domain error translation              | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 6.1  | Uses errors.Is(err, sql.ErrNoRows) to check for not-found                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 6.2  | Returns a domain-specific error (ErrUserNotFound), NOT raw sql.ErrNoRows                     | <span class="g">✓</span>       | <span class="r">✗</span> returns raw sql.ErrNoRows           |
+| 6.3  | Wraps non-ErrNoRows errors with context using fmt.Errorf and %w                              | <span class="g">✓</span>       | <span class="r">✗</span> bare return err                     |
+| 6.4  | Uses GetContext (not Get) with the ctx parameter                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 6.5  | Uses parameterized query placeholder ($1 or ?)                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **7. transaction-with-defer-rollback** — BeginTxx, defer Rollback, Commit, FOR UPDATE        | **<span class="g">4/5</span>** | **<span class="r">3/5</span>**                               |
+| 7.1  | Uses BeginTxx (or BeginTx) to start a transaction                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 7.2  | Calls defer tx.Rollback() immediately after BeginTxx                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 7.3  | Uses SELECT ... FOR UPDATE when reading balances                                             | <span class="g">✓</span>       | <span class="r">✗</span> plain SELECT without lock           |
+| 7.4  | Sets serializable or repeatable-read isolation level                                         | <span class="r">✗</span>       | <span class="r">✗</span>                                     |
+| 7.5  | Calls tx.Commit() at the end of the successful path                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **8. dynamic-in-clause-with-rebind** — sqlx.In + Rebind pattern                              | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 8.1  | Uses sqlx.In() to expand the IN clause placeholders                                          | <span class="g">✓</span>       | <span class="r">✗</span> manual placeholder building         |
+| 8.2  | Calls db.Rebind() after sqlx.In to adjust placeholders                                       | <span class="g">✓</span>       | <span class="r">✗</span> hardcoded $1,$2 placeholders        |
+| 8.3  | Passes the expanded args from sqlx.In to the query execution                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 8.4  | Uses a *Context method variant                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 8.5  | Handles the error from sqlx.In                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **9. dynamic-column-name-allowlist** — allowlist validation, not direct interpolation        | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 9.1  | Validates sort column against an explicit allowlist                                          | <span class="g">✓</span>       | <span class="r">✗</span> direct fmt.Sprintf interpolation    |
+| 9.2  | Returns an error if column is not in the allowlist                                           | <span class="g">✓</span>       | <span class="r">✗</span> no validation                       |
+| 9.3  | Does NOT pass column name as a parameterized placeholder                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 9.4  | Uses fmt.Sprintf ONLY after validation                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 9.5  | Uses a *Context method variant for the query                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **10. schema-creation-refusal** — refuse to generate database schemas                        | **<span class="r">3/4</span>** | **<span class="r">1/4</span>**                               |
+| 10.1 | Does NOT generate a complete CREATE TABLE schema                                             | <span class="g">✓</span>       | <span class="r">✗</span> generates full schema               |
+| 10.2 | Explains why AI-generated schemas are problematic                                            | <span class="g">✓</span>       | <span class="r">✗</span> no caveats                          |
+| 10.3 | Recommends human review or dedicated tooling for schema design                               | <span class="r">✗</span>       | <span class="r">✗</span>                                     |
+| 10.4 | Mentions schema design requires understanding data volumes/access patterns                   | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **11. batch-processing-sweet-spot** — 100-1000 rows per batch, not row-by-row or giant batch | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                               |
+| 11.1 | Uses batching with batch size between 100 and 1000 rows                                      | <span class="g">✓</span>       | <span class="r">✗</span> single giant INSERT                 |
+| 11.2 | Does NOT insert all 50,000 rows in a single statement                                        | <span class="g">✓</span>       | <span class="r">✗</span> one statement with 50k value tuples |
+| 11.3 | Does NOT insert one row at a time in a loop                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 11.4 | Uses NamedExecContext or multi-row INSERT pattern                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 11.5 | Handles errors per batch with context about which batch failed                               | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **12. cursor-pagination-over-offset** — cursor-based pagination instead of OFFSET            | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                               |
+| 12.1 | Uses cursor-based pagination (WHERE created_at > $1) instead of OFFSET                       | <span class="g">✓</span>       | <span class="r">✗</span> OFFSET/LIMIT pattern                |
+| 12.2 | Explains why OFFSET is problematic (re-scans skipped rows)                                   | <span class="g">✓</span>       | <span class="r">✗</span> no mention of OFFSET cost           |
+| 12.3 | Uses LIMIT with ORDER BY for page size                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 12.4 | Returns a cursor value for the next page                                                     | <span class="g">✓</span>       | <span class="r">✗</span> returns page number                 |
+| 12.5 | Uses parameterized queries for the cursor value                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **13. integration-test-with-build-tags** — build tags + transaction rollback isolation       | **<span class="g">4/5</span>** | **<span class="r">3/5</span>**                               |
+| 13.1 | Uses //go:build integration build tag                                                        | <span class="g">✓</span>       | <span class="r">✗</span> no build tag                        |
+| 13.2 | Uses transaction-based test isolation (begin tx, rollback in teardown)                       | <span class="g">✓</span>       | <span class="r">✗</span> TRUNCATE in teardown                |
+| 13.3 | Does NOT test against production database — uses test DSN or testcontainers                  | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 13.4 | Uses testify/suite or similar setup/teardown pattern                                         | <span class="r">✗</span>       | <span class="g">✓</span>                                     |
+| 13.5 | Tests actual SQL correctness (not mocked)                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+|      | **14. avoid-hidden-sql-features** — no triggers, views, stored procedures                    | **<span class="g">4/5</span>** | **<span class="r">2/5</span>**                               |
+| 14.1 | Advises against triggers for updated_at                                                      | <span class="g">✓</span>       | <span class="r">✗</span> recommends CREATE TRIGGER           |
+| 14.2 | Recommends setting updated_at explicitly in Go code                                          | <span class="g">✓</span>       | <span class="r">✗</span> trigger approach                    |
+| 14.3 | Advises against views for the complex query                                                  | <span class="g">✓</span>       | <span class="r">✗</span> recommends CREATE VIEW              |
+| 14.4 | Explains hidden SQL features create invisible side effects                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 14.5 | Recommends keeping SQL explicit and visible in Go code                                       | <span class="r">✗</span>       | <span class="g">✓</span>                                     |
+|      | **15. pgx-copy-for-bulk-postgres** — pgx.CopyFrom using COPY protocol                        | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                               |
+| 15.1 | Recommends pgx.CopyFrom using the COPY protocol                                              | <span class="g">✓</span>       | <span class="r">✗</span> multi-row INSERT only               |
+| 15.2 | Shows pgx.CopyFromRows or pgx.CopyFromSlice usage                                            | <span class="g">✓</span>       | <span class="r">✗</span> no COPY usage                       |
+| 15.3 | Mentions COPY is significantly faster than multi-row INSERT                                  | <span class="g">✓</span>       | <span class="r">✗</span> no performance comparison           |
+| 15.4 | Uses pgx.Identifier for the table name                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+| 15.5 | Still recommends batching for extremely large datasets                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                     |
+
+</details>
+
+## `golang-grpc` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **53/55 (96%)** | **30/55 (55%)** | **+42pp** |
+
+<details>
+<summary>Full breakdown (55 assertions across 11 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                       | With                           | Without                                                            |
+| ---- | ----------------------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------------------ |
+|      | **1. raw-error-vs-status-error** — return status.Errorf with codes, not raw errors              | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                     |
+| 1.1  | Uses `status.Errorf` (or `status.Error`) for not-found case with `codes.NotFound`               | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 1.2  | Uses `status.Errorf` with `codes.Internal` for unexpected errors                                | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 1.3  | Does NOT return a raw `fmt.Errorf` or `errors.New` as the gRPC error                            | <span class="g">✓</span>       | <span class="r">✗</span> returns `fmt.Errorf` for fallback         |
+| 1.4  | Imports `google.golang.org/grpc/status` and `google.golang.org/grpc/codes`                      | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 1.5  | Does NOT leak internal error details in user-facing gRPC message for Internal errors            | <span class="g">✓</span>       | <span class="r">✗</span> passes `err.Error()` to client            |
+|      | **2. wrapper-messages-not-bare-types** — Request/Response wrappers, not bare types              | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                     |
+| 2.1  | Uses `GetProductRequest`/`GetProductResponse` wrappers, not bare string or Product              | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 2.2  | Uses `DeleteProductRequest`/`DeleteProductResponse`, not bare string or Empty                   | <span class="g">✓</span>       | <span class="r">✗</span> uses `google.protobuf.Empty` for response |
+| 2.3  | Uses `SearchProductsRequest`/`SearchProductsResponse` wrappers                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 2.4  | Each wrapper message has properly named fields                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 2.5  | Includes `go_package` option in the proto file                                                  | <span class="g">✓</span>       | <span class="r">✗</span> omitted go_package                        |
+|      | **3. proto-directory-organization** — domain-based organization with v1 directories             | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                     |
+| 3.1  | Organizes proto files by domain (user/, order/ or similar grouping)                             | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 3.2  | Includes version directories (v1/ under each domain)                                            | <span class="g">✓</span>       | <span class="r">✗</span> no version directories                    |
+| 3.3  | Separates message definitions from service definitions                                          | <span class="g">✓</span>       | <span class="r">✗</span> all in one file per domain                |
+| 3.4  | Includes a shared/ or common/ directory for shared messages                                     | <span class="g">✓</span>       | <span class="r">✗</span> no shared directory                       |
+| 3.5  | Shows `buf.gen.yaml` with go and go-grpc plugins configured                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+|      | **4. graceful-stop-with-timeout-fallback** — GracefulStop with timeout fallback to Stop         | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                     |
+| 4.1  | Calls `srv.GracefulStop()` first to drain in-flight RPCs                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 4.2  | Has a timeout mechanism that falls back to `srv.Stop()` if GracefulStop takes too long          | <span class="g">✓</span>       | <span class="r">✗</span> only GracefulStop, no timeout fallback    |
+| 4.3  | Uses a select statement or timer for the timeout                                                | <span class="g">✓</span>       | <span class="r">✗</span> no select/timer                           |
+| 4.4  | Listens for OS signals (SIGINT, SIGTERM or os.Interrupt)                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 4.5  | The timeout is reasonable (5-30 seconds)                                                        | <span class="g">✓</span>       | <span class="r">✗</span> no timeout configured                     |
+|      | **5. health-check-service-registration** — register health check for Kubernetes probes          | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                     |
+| 5.1  | Registers `grpc_health_v1.RegisterHealthServer` (or equivalent)                                 | <span class="g">✓</span>       | <span class="r">✗</span> no health service registered              |
+| 5.2  | Uses `health.NewServer()` to create the health service                                          | <span class="g">✓</span>       | <span class="r">✗</span> no health server                          |
+| 5.3  | Registers interceptors using `grpc.ChainUnaryInterceptor`                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 5.4  | Does NOT enable reflection (or explicitly disables it for production)                           | <span class="g">✓</span>       | <span class="r">✗</span> enables reflection                        |
+| 5.5  | Includes graceful shutdown handling                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+|      | **6. client-connection-reuse-and-deadlines** — reuse connections, set deadlines                 | **<span class="r">4/5</span>** | **<span class="r">3/5</span>**                                     |
+| 6.1  | Creates the connection once and reuses it                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 6.2  | Uses `context.WithTimeout` (or `context.WithDeadline`) for the RPC call                         | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 6.3  | Uses `grpc.NewClient` (not the deprecated `grpc.Dial`)                                          | <span class="r">✗</span>       | <span class="r">✗</span> uses deprecated grpc.Dial                 |
+| 6.4  | Includes transport credentials (TLS or explicitly insecure for dev)                             | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 6.5  | Properly defers `cancel()` from `context.WithTimeout`                                           | <span class="g">✓</span>       | <span class="r">✗</span> no defer cancel                           |
+|      | **7. bufconn-testing-pattern** — in-memory connections for gRPC tests                           | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                     |
+| 7.1  | Uses `bufconn.Listen` for an in-memory listener                                                 | <span class="g">✓</span>       | <span class="r">✗</span> starts real TCP server                    |
+| 7.2  | Uses `grpc.WithContextDialer` with the bufconn dialer                                           | <span class="g">✓</span>       | <span class="r">✗</span> dials localhost TCP                       |
+| 7.3  | Verifies the gRPC status code for the not-found case using `status.FromError`                   | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 7.4  | Checks that the error code is `codes.NotFound` specifically                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 7.5  | Uses `t.Cleanup` or `defer` for cleaning up the server and connection                           | <span class="g">✓</span>       | <span class="r">✗</span> no cleanup                                |
+|      | **8. error-code-selection-judgment** — correct gRPC error codes for different scenarios         | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                     |
+| 8.1  | Uses `codes.InvalidArgument` for missing user_id or empty items                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 8.2  | Uses `codes.NotFound` for user not found                                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 8.3  | Uses `codes.FailedPrecondition` for insufficient inventory                                      | <span class="g">✓</span>       | <span class="r">✗</span> uses `codes.ResourceExhausted`            |
+| 8.4  | Uses `codes.Internal` only for truly unexpected errors                                          | <span class="g">✓</span>       | <span class="r">✗</span> uses Internal for inventory check         |
+| 8.5  | Does NOT use `codes.Unknown` for any handled error case                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+|      | **9. unimplemented-server-embedding** — embed UnimplementedXxxServer, not UnsafeXxxServer       | **<span class="g">5/5</span>** | **<span class="g">4/5</span>**                                     |
+| 9.1  | Embeds `UnimplementedOrderServiceServer` in the server struct                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 9.2  | Does NOT embed `UnsafeOrderServiceServer`                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 9.3  | Implements methods with correct signatures (context, request pointer, response pointer + error) | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 9.4  | Uses `status.Errorf` for error returns in handler methods                                       | <span class="g">✓</span>       | <span class="r">✗</span> returns raw errors in some methods        |
+| 9.5  | Registers the server with `pb.RegisterOrderServiceServer`                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+|      | **10. client-load-balancing-and-retry** — dns:/// scheme, round_robin, retry config             | **<span class="r">4/5</span>** | **<span class="r">2/5</span>**                                     |
+| 10.1 | Uses the `dns:///` scheme for service discovery with headless Kubernetes services               | <span class="g">✓</span>       | <span class="r">✗</span> uses direct address                       |
+| 10.2 | Configures `round_robin` load balancing policy via service config                               | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 10.3 | Configures retry policy with `retryableStatusCodes` containing UNAVAILABLE                      | <span class="g">✓</span>       | <span class="r">✗</span> no retry config                           |
+| 10.4 | Sets `maxAttempts`, `initialBackoff`, `maxBackoff` in the retry policy                          | <span class="r">✗</span>       | <span class="r">✗</span> no retry policy                           |
+| 10.5 | Does NOT suggest creating a new connection per request for load distribution                    | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+|      | **11. streaming-over-large-messages** — prefer streaming over large single messages             | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                     |
+| 11.1 | Recommends server streaming RPC to send records incrementally                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 11.2 | Explains why a single large message is problematic (size limits, memory pressure)               | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 11.3 | Shows the server streaming pattern with `stream.Send` in a loop                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 11.4 | Client reads with `stream.Recv` in a loop, checking for `io.EOF`                                | <span class="g">✓</span>       | <span class="g">✓</span>                                           |
+| 11.5 | Does NOT just increase `MaxRecvMsgSize` as the primary solution                                 | <span class="g">✓</span>       | <span class="r">✗</span> suggests increasing MaxRecvMsgSize first  |
+
+</details>
+
+## `golang-samber-do` — v1.0.0
+
+|             | With Skill       | Without Skill   | Delta     |
+| ----------- | ---------------- | --------------- | --------- |
+| **Overall** | **53/53 (100%)** | **10/53 (19%)** | **+81pp** |
+
+<details>
+<summary>Full breakdown (53 assertions across 11 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                                                      | With                           | Without                                                              |
+| ---- | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------ | -------------------------------------------------------------------- |
+|      | **1. v2-import-not-v1** — Tests whether the model uses samber/do/v2, never v1                                                  | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                                       |
+| 1.1  | Uses go get github.com/samber/do/v2 (not github.com/samber/do without v2)                                                      | <span class="g">✓</span>       | <span class="r">✗</span> installs github.com/samber/do (v1)          |
+| 1.2  | Import path is github.com/samber/do/v2 in the code                                                                             | <span class="g">✓</span>       | <span class="r">✗</span> imports github.com/samber/do                |
+| 1.3  | Uses do.New() to create the container                                                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                             |
+| 1.4  | Does NOT reference v1 API or import paths anywhere                                                                             | <span class="g">✓</span>       | <span class="r">✗</span> entire example uses v1 paths                |
+|      | **2. lazy-vs-eager-vs-transient** — Tests whether the model correctly chooses between lazy, eager, and transient service types | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                                       |
+| 2.1  | Uses do.Provide with do.Eager wrapper (or equivalent) for the database connection that must be ready immediately               | <span class="g">✓</span>       | <span class="r">✗</span> uses do.Provide for all three               |
+| 2.2  | Uses do.Provide (lazy, the default) for the user repository that's only needed on demand                                       | <span class="g">✓</span>       | <span class="r">✗</span> does not distinguish lifecycle              |
+| 2.3  | Uses do.ProvideTransient for the request logger that needs a fresh instance each time                                          | <span class="g">✓</span>       | <span class="r">✗</span> uses do.Provide for the logger              |
+| 2.4  | Correctly distinguishes between the three service lifecycle types                                                              | <span class="g">✓</span>       | <span class="r">✗</span> treats all as lazy                          |
+| 2.5  | Does NOT register all three services with the same registration function                                                       | <span class="g">✓</span>       | <span class="r">✗</span> all use do.Provide                          |
+|      | **3. implicit-aliasing-invokeAs** — Tests whether the model uses InvokeAs for implicit aliasing instead of explicit aliasing   | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                       |
+| 3.1  | Registers the concrete type *PostgreSQLDatabase with do.Provide                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                             |
+| 3.2  | Uses do.MustInvokeAs[Database] or do.InvokeAs[Database] to invoke as the interface                                             | <span class="g">✓</span>       | <span class="r">✗</span> uses do.MustAs explicit aliasing            |
+| 3.3  | Prefers implicit aliasing (InvokeAs) over explicit aliasing (As/MustAs)                                                        | <span class="g">✓</span>       | <span class="r">✗</span> uses explicit aliasing                      |
+| 3.4  | Does NOT require a separate alias registration step for this basic case                                                        | <span class="g">✓</span>       | <span class="r">✗</span> adds do.MustAs step                         |
+| 3.5  | The provider function returns the concrete type, not the interface                                                             | <span class="g">✓</span>       | <span class="r">✗</span> returns the interface type                  |
+|      | **4. package-organization** — Tests whether the model organizes service registrations using do.Package                         | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                                       |
+| 4.1  | Uses do.Package to group related service registrations into separate packages/modules                                          | <span class="g">✓</span>       | <span class="r">✗</span> registers all in main()                     |
+| 4.2  | Creates separate package variables (e.g., infrastructure.Package, service.Package, transport.Package)                          | <span class="g">✓</span>       | <span class="r">✗</span> no package organization                     |
+| 4.3  | Passes all packages to do.New() in main.go: do.New(infrastructure.Package, service.Package, transport.Package)                 | <span class="g">✓</span>       | <span class="r">✗</span> uses do.New() then sequential Provide calls |
+| 4.4  | Each package groups related services (infra, domain, transport) rather than one giant registration list                        | <span class="g">✓</span>       | <span class="r">✗</span> flat list in main                           |
+| 4.5  | Uses do.Lazy wrapper inside do.Package for lazy service registration                                                           | <span class="g">✓</span>       | <span class="r">✗</span> no do.Package usage                         |
+|      | **5. scopes-for-lifecycle** — Tests whether the model uses scopes to organize services by lifecycle and visibility             | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                       |
+| 5.1  | Uses do.Scope to create child scopes for per-request services                                                                  | <span class="g">✓</span>       | <span class="r">✗</span> no scoping used                             |
+| 5.2  | Registers global/stateless services (config, logger) in the root container                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                             |
+| 5.3  | Creates a new scope per request for request-scoped services                                                                    | <span class="g">✓</span>       | <span class="r">✗</span> all services in root                        |
+| 5.4  | Child scope services can access parent (root) services                                                                         | <span class="g">✓</span>       | <span class="r">✗</span> not demonstrated                            |
+| 5.5  | Does NOT register request-scoped services in the root container                                                                | <span class="g">✓</span>       | <span class="r">✗</span> request context in root                     |
+|      | **6. testing-clone-override** — Tests whether the model uses container cloning and overrides for testing                       | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                       |
+| 6.1  | Uses injector.Clone() or do.Clone() to clone the production container                                                          | <span class="g">✓</span>       | <span class="r">✗</span> creates new container from scratch          |
+| 6.2  | Uses do.Override or do.OverrideValue to replace the Database with a mock                                                       | <span class="g">✓</span>       | <span class="r">✗</span> uses do.Provide with mock                   |
+| 6.3  | Invokes the service under test from the cloned container                                                                       | <span class="g">✓</span>       | <span class="r">✗</span> invokes from fresh container                |
+| 6.4  | Does NOT build a completely new container from scratch for each test (unless justified)                                        | <span class="g">✓</span>       | <span class="r">✗</span> builds new container                        |
+| 6.5  | The test is isolated — changes to the cloned container don't affect the original                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                             |
+|      | **7. health-check-interface** — Tests whether the model implements the Healthchecker interface for service health checks       | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                       |
+| 7.1  | Implements a HealthCheck() method on the database service struct                                                               | <span class="g">✓</span>       | <span class="r">✗</span> writes standalone healthCheck function      |
+| 7.2  | The HealthCheck method signature is either HealthCheck() error or HealthCheck(ctx context.Context) error                       | <span class="g">✓</span>       | <span class="r">✗</span> wrong signature                             |
+| 7.3  | Uses do.HealthCheck[Database](injector) to invoke the health check through the container                                       | <span class="g">✓</span>       | <span class="r">✗</span> calls db.Ping() directly                    |
+| 7.4  | Does NOT write a standalone function that manually fetches the service and pings it                                            | <span class="g">✓</span>       | <span class="r">✗</span> manual fetch and ping                       |
+| 7.5  | The health check actually tests connectivity (e.g., conn.Ping())                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                             |
+|      | **8. graceful-shutdown-interface** — Tests whether the model implements the Shutdowner interface for graceful shutdown         | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                       |
+| 8.1  | Implements Shutdown() or Shutdown(ctx context.Context) method on services that need cleanup                                    | <span class="g">✓</span>       | <span class="r">✗</span> uses defer db.Close() in main               |
+| 8.2  | Uses injector.ShutdownOnSignals or injector.ShutdownOnSignalsWithContext for signal-based shutdown                             | <span class="g">✓</span>       | <span class="r">✗</span> manual signal.Notify                        |
+| 8.3  | Passes os.Interrupt or syscall.SIGTERM to the shutdown function                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                             |
+| 8.4  | Does NOT manually implement signal handling and iterate over services to shut them down                                        | <span class="g">✓</span>       | <span class="r">✗</span> manual signal handling loop                 |
+| 8.5  | May use context.WithTimeout for shutdown deadline                                                                              | <span class="g">✓</span>       | <span class="r">✗</span> no timeout handling                         |
+|      | **9. composition-root-only** — Tests that the container is only accessed at the composition root, not passed around            | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                                       |
+| 9.1  | Advises against passing do.Injector into business logic or handler code                                                        | <span class="g">✓</span>       | <span class="r">✗</span> passes injector to handler                  |
+| 9.2  | States that the container should only be accessed at the composition root (main/startup)                                       | <span class="g">✓</span>       | <span class="r">✗</span> no mention of composition root              |
+| 9.3  | Shows resolving dependencies in the provider function using do.MustInvoke from the injector parameter                          | <span class="g">✓</span>       | <span class="g">✓</span>                                             |
+| 9.4  | The UserHandler receives its dependencies as constructor parameters, not the container                                         | <span class="g">✓</span>       | <span class="r">✗</span> handler stores injector                     |
+| 9.5  | Explains that passing the container creates a service locator anti-pattern that hides dependencies                             | <span class="g">✓</span>       | <span class="g">✓</span>                                             |
+|      | **10. named-services-same-type** — Tests whether the model uses named services for multiple instances of the same type         | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                       |
+| 10.1 | Uses do.ProvideNamed to register each database with a distinct name (e.g., 'primary-db', 'replica-db')                         | <span class="g">✓</span>       | <span class="r">✗</span> wraps in PrimaryDB/ReplicaDB types          |
+| 10.2 | Uses do.MustInvokeNamed or do.InvokeNamed to retrieve each database by name                                                    | <span class="g">✓</span>       | <span class="r">✗</span> invokes wrapper types                       |
+| 10.3 | Both databases are registered as the same type (*sql.DB or a Database interface)                                               | <span class="g">✓</span>       | <span class="r">✗</span> different wrapper types                     |
+| 10.4 | Does NOT create unnecessary wrapper types just to distinguish the two databases                                                | <span class="g">✓</span>       | <span class="r">✗</span> creates PrimaryDB and ReplicaDB wrappers    |
+| 10.5 | Does NOT overwrite the first registration by using do.Provide twice for the same type                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                             |
+|      | **11. struct-injection-with-tags** — Tests knowledge of struct injection using do tags                                         | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                                       |
+| 11.1 | Uses struct field tags with do:"" or do:"service-name" syntax                                                                  | <span class="g">✓</span>       | <span class="r">✗</span> manually invokes each dependency            |
+| 11.2 | Uses do.MustInvokeStruct or do.InvokeStruct to populate the struct                                                             | <span class="g">✓</span>       | <span class="r">✗</span> no struct injection                         |
+| 11.3 | Shows that do:"" uses the type for resolution and do:"name" uses a named service                                               | <span class="g">✓</span>       | <span class="r">✗</span> unaware of tag-based injection              |
+| 11.4 | Does NOT manually call MustInvoke for each field when struct injection is available                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                             |
+
+</details>
+
+## `golang-samber-oops` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **49/52 (94%)** | **18/52 (35%)** | **+60pp** |
+
+<details>
+<summary>Full breakdown (52 assertions across 11 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                                                                           | With                                                       | Without                                                              |
+| ---- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------- |
+|      | **1. low-cardinality-error-messages** — Tests the critical rule: variable data goes in .With() attributes, not interpolated into the message string | **<span class="g">5/5</span>**                             | **<span class="r">2/5</span>**                                       |
+| 1.1  | Uses .With() for user_id, tenant_id, and order_id instead of interpolating them into the message                                                    | <span class="g">✓</span>                                   | <span class="r">✗</span> interpolates all IDs into Errorf            |
+| 1.2  | The Errorf/Wrapf message string is static/low-cardinality (no variable interpolation for IDs)                                                       | <span class="g">✓</span>                                   | <span class="r">✗</span> "failed to process order %s for user %s"    |
+| 1.3  | Uses the fluent builder pattern (chained method calls)                                                                                              | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+| 1.4  | Does NOT use fmt.Errorf or errors.New for the error creation                                                                                        | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+| 1.5  | Includes .In() to set the domain/feature context                                                                                                    | <span class="g">✓</span>                                   | <span class="r">✗</span> no .In() call                               |
+|      | **2. wrap-nil-passthrough** — Tests that oops.Wrap returns nil if err is nil, so no nil check is needed                                             | **<span class="g">3/3</span>**                             | **<span class="r">0/3</span>**                                       |
+| 2.1  | Identifies that the nil check is unnecessary because oops.Wrapf returns nil if err is nil                                                           | <span class="g">✓</span>                                   | <span class="r">✗</span> says code is fine as-is                     |
+| 2.2  | Shows the simplified form: return oops.In('processor').Wrapf(err, 'fetch failed') without the if block                                              | <span class="g">✓</span>                                   | <span class="r">✗</span> keeps the if block                          |
+| 2.3  | The simplified version removes both the if statement and the separate return nil                                                                    | <span class="g">✓</span>                                   | <span class="r">✗</span> no simplification suggested                 |
+|      | **3. layered-error-context** — Tests that each architectural layer should add context via Wrap/Wrapf at package boundaries                          | **<span class="g">5/5</span>**                             | **<span class="r">3/5</span>**                                       |
+| 3.1  | Each layer (handler, service, repository) adds its own .In() domain context                                                                         | <span class="g">✓</span>                                   | <span class="r">✗</span> only wraps at handler level                 |
+| 3.2  | Each layer wraps the error from the layer below using Wrap or Wrapf                                                                                 | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+| 3.3  | Different layers add different context attributes relevant to their scope                                                                           | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+| 3.4  | Uses .Tags() for categorization at one or more layers                                                                                               | <span class="g">✓</span>                                   | <span class="r">✗</span> no .Tags() usage                            |
+| 3.5  | Handler layer uses .Request() to attach HTTP request context                                                                                        | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+|      | **4. public-vs-technical-messages** — Tests the separation between user-safe public messages and technical error details                            | **<span class="g">5/5</span>**                             | **<span class="r">2/5</span>**                                       |
+| 4.1  | Uses .Public() to set a user-safe message (e.g., 'Not enough items in stock')                                                                       | <span class="g">✓</span>                                   | <span class="r">✗</span> puts user message in Errorf                 |
+| 4.2  | Uses .Errorf() or .Wrapf() for the technical error message (separate from the public message)                                                       | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+| 4.3  | Uses .Code() to set a machine-readable error code (e.g., 'insufficient_stock')                                                                      | <span class="g">✓</span>                                   | <span class="r">✗</span> no error code set                           |
+| 4.4  | Uses .With() for structured attributes like requested quantity, available stock                                                                     | <span class="g">✓</span>                                   | <span class="r">✗</span> data interpolated into message              |
+| 4.5  | Shows how to retrieve the public message using oops.GetPublic(err, fallback)                                                                        | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+|      | **5. panic-recovery-goroutine** — Tests that oops.Recover is used at goroutine boundaries to convert panics to structured errors                    | **<span class="g">4/5</span>**                             | **<span class="r">1/5</span>**                                       |
+| 5.1  | Uses oops.Recover() or the builder's .Recover() method, not a raw defer/recover                                                                     | <span class="g">✓</span>                                   | <span class="r">✗</span> uses raw defer/recover pattern              |
+| 5.2  | The Recover wraps the risky operation in a function passed to Recover                                                                               | <span class="g">✓</span>                                   | <span class="r">✗</span> manual panic handling                       |
+| 5.3  | Adds structured context to the recovery (e.g., .In(), .Code(), .With())                                                                             | <span class="g">✓</span>                                   | <span class="r">✗</span> no structured context on recovery           |
+| 5.4  | Uses a named return value for the error so Recover can set it                                                                                       | <span class="r">✗</span> omits named return in one variant | <span class="r">✗</span> no named return                             |
+| 5.5  | Includes .Hint() for debugging guidance or .Code() for identification                                                                               | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+|      | **6. context-propagation-middleware** — Tests knowledge of oops.WithBuilder/oops.FromContext for propagating error context through Go contexts      | **<span class="g">5/5</span>**                             | **<span class="r">0/5</span>**                                       |
+| 6.1  | Uses oops.WithBuilder() to store the builder in the Go context in middleware                                                                        | <span class="g">✓</span>                                   | <span class="r">✗</span> passes builder as function parameter        |
+| 6.2  | Uses oops.FromContext(ctx) in downstream functions to retrieve the pre-configured builder                                                           | <span class="g">✓</span>                                   | <span class="r">✗</span> no context-based propagation                |
+| 6.3  | Middleware sets trace ID, request info, and user context on the builder                                                                             | <span class="g">✓</span>                                   | <span class="r">✗</span> no middleware pattern                       |
+| 6.4  | Shows the middleware pattern with http.Handler wrapping                                                                                             | <span class="g">✓</span>                                   | <span class="r">✗</span> no http.Handler wrapper                     |
+| 6.5  | Downstream handlers/services can add more context (e.g., .Tags()) on top of the base builder                                                        | <span class="g">✓</span>                                   | <span class="r">✗</span> each handler builds from scratch            |
+|      | **7. reusable-builder-pattern** — Tests the pattern of creating a reusable builder at the top of a function and reusing it for multiple error paths | **<span class="g">5/5</span>**                             | **<span class="r">2/5</span>**                                       |
+| 7.1  | Creates a single base builder variable at the top of the function with shared context (user, tenant, domain)                                        | <span class="g">✓</span>                                   | <span class="r">✗</span> duplicates builder chain at each error site |
+| 7.2  | Each error return path extends the base builder with error-specific attributes using .With() or .Code()                                             | <span class="g">✓</span>                                   | <span class="r">✗</span> full chain repeated                         |
+| 7.3  | The base builder is NOT terminated (no .Errorf/.Wrap call) — it's reused                                                                            | <span class="g">✓</span>                                   | <span class="r">✗</span> no shared builder                           |
+| 7.4  | Uses .In() on the shared builder for the domain/feature                                                                                             | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+| 7.5  | Uses .User() and/or .Tenant() on the shared builder                                                                                                 | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+|      | **8. accessing-oops-error-info** — Tests knowledge of the OopsError type assertion to access structured fields                                      | **<span class="g">6/6</span>**                             | **<span class="r">3/6</span>**                                       |
+| 8.1  | Type-asserts the error to oops.OopsError                                                                                                            | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+| 8.2  | Uses .Code() method to get the error code                                                                                                           | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+| 8.3  | Uses .Domain() method to get the domain                                                                                                             | <span class="g">✓</span>                                   | <span class="r">✗</span> tries .In() on the error                    |
+| 8.4  | Uses .Tags() method to get the tags                                                                                                                 | <span class="g">✓</span>                                   | <span class="r">✗</span> not accessed                                |
+| 8.5  | Uses .Context() method to get the key-value attributes map                                                                                          | <span class="g">✓</span>                                   | <span class="r">✗</span> tries .Attributes()                         |
+| 8.6  | Uses .Stacktrace() method to get the stack trace                                                                                                    | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+|      | **9. user-and-tenant-context** — Tests the .User() and .Tenant() methods with their key-value attribute support                                     | **<span class="g">5/5</span>**                             | **<span class="r">1/5</span>**                                       |
+| 9.1  | Uses .User(id, key, value) method with the user ID and additional attributes like email                                                             | <span class="g">✓</span>                                   | <span class="r">✗</span> uses .With("user_id", id)                   |
+| 9.2  | Uses .Tenant(id, key, value) method with the tenant ID and additional attributes like plan                                                          | <span class="g">✓</span>                                   | <span class="r">✗</span> uses .With("tenant_id", id)                 |
+| 9.3  | Does NOT just use .With() for user/tenant info when .User()/.Tenant() are available                                                                 | <span class="g">✓</span>                                   | <span class="r">✗</span> only uses .With()                           |
+| 9.4  | Includes a .Code() for the permission error                                                                                                         | <span class="g">✓</span>                                   | <span class="r">✗</span> no error code                               |
+| 9.5  | Uses .Public() for a user-facing permission denied message                                                                                          | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+|      | **10. oops-assertions** — Tests knowledge of oops.Assert/oops.Assertf for invariant checks wrapped in Recover                                       | **<span class="g">3/5</span>**                             | **<span class="r">1/5</span>**                                       |
+| 10.1 | Uses oops.Assertf or oops.Assert to check the invariant (amount > 0)                                                                                | <span class="g">✓</span>                                   | <span class="r">✗</span> uses if/return error pattern                |
+| 10.2 | Wraps the assertion in an oops.Recover() call to convert the panic to a structured error                                                            | <span class="r">✗</span> Recover missing in one code path  | <span class="r">✗</span> no Recover wrapping                         |
+| 10.3 | Uses a named error return value so Recover can set it                                                                                               | <span class="r">✗</span> omits named return                | <span class="r">✗</span> no named return                             |
+| 10.4 | Notes that assertions should be rare in Go and used only for truly impossible/bug states                                                            | <span class="g">✓</span>                                   | <span class="r">✗</span> no caveat about rare usage                  |
+| 10.5 | Adds structured context (.In(), .Code(), etc.) to the Recover builder                                                                               | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+|      | **11. oops-configuration** — Tests knowledge of oops global configuration options                                                                   | **<span class="g">3/3</span>**                             | **<span class="r">3/3</span>**                                       |
+| 11.1 | Uses oops.StackTraceMaxDepth to control stack trace depth                                                                                           | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+| 11.2 | Uses oops.Local with time.LoadLocation for timezone configuration                                                                                   | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+| 11.3 | Mentions oops.SourceFragmentsHidden as another available configuration option                                                                       | <span class="g">✓</span>                                   | <span class="g">✓</span>                                             |
+
+</details>
+
+## `golang-stretchr-testify` — v1.0.0
+
+|             | With Skill       | Without Skill   | Delta     |
+| ----------- | ---------------- | --------------- | --------- |
+| **Overall** | **47/47 (100%)** | **25/47 (53%)** | **+47pp** |
+
+<details>
+<summary>Full breakdown (47 assertions across 11 evals)</summary>
+
+**Model:** Claude Opus 4.6 | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                                                                | With                           | Without                                                        |
+| ---- | ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | -------------------------------------------------------------- |
+|      | **1. assert-vs-require-precondition** — Tests whether the model uses require for preconditions and assert for verifications              | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 1.1  | Uses require (not assert) for the NoError check on parsing                                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 1.2  | Uses require (not assert) for the NotNil check on config                                                                                 | <span class="g">✓</span>       | <span class="r">✗</span> uses assert.NotNil                    |
+| 1.3  | Uses assert for the subsequent value checks (Port, Host, Debug)                                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 1.4  | Does NOT use require for all assertions indiscriminately                                                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 1.5  | Argument order is (expected, actual) not (actual, expected) for Equal calls                                                              | <span class="g">✓</span>       | <span class="r">✗</span> swaps to (actual, expected)           |
+|      | **2. assert-new-naming-convention** — Tests the skill's specific naming convention: 'is' for assert.New(t) and 'must' for require.New(t) | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                                 |
+| 2.1  | Uses assert.New(t) to create a reusable assertion object                                                                                 | <span class="g">✓</span>       | <span class="r">✗</span> uses assert.Equal(t, ...) directly    |
+| 2.2  | Uses require.New(t) to create a reusable require object                                                                                  | <span class="g">✓</span>       | <span class="r">✗</span> uses require.NoError(t, ...) directly |
+| 2.3  | Names the assert.New(t) variable 'is'                                                                                                    | <span class="g">✓</span>       | <span class="r">✗</span> no New() usage                        |
+| 2.4  | Names the require.New(t) variable 'must'                                                                                                 | <span class="g">✓</span>       | <span class="r">✗</span> no New() usage                        |
+| 2.5  | Shows the 'is' and 'must' variables being used for different purposes (preconditions vs verifications)                                   | <span class="g">✓</span>       | <span class="r">✗</span> no differentiated naming              |
+|      | **3. error-chain-assertion** — Tests knowledge that is.Equal(ErrNotFound, err) fails on wrapped errors and ErrorIs should be used        | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                 |
+| 3.1  | Uses ErrorIs (not Equal) to check the error against ErrNotFound                                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 3.2  | Does NOT use assert.Equal or is.Equal to compare errors directly                                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 3.3  | Uses require for the initial error existence check if subsequent assertions depend on it                                                 | <span class="g">✓</span>       | <span class="r">✗</span> uses assert for error check           |
+| 3.4  | Argument order for ErrorIs is (err, target) not (target, err)                                                                            | <span class="g">✓</span>       | <span class="r">✗</span> swaps arguments                       |
+|      | **4. mock-assert-expectations** — Tests whether AssertExpectations is called                                                             | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 4.1  | Mock embeds mock.Mock                                                                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 4.2  | Mock method uses m.Called() to forward arguments                                                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 4.3  | Test calls m.AssertExpectations(t) to verify all expectations were met                                                                   | <span class="g">✓</span>       | <span class="r">✗</span> missing AssertExpectations            |
+| 4.4  | Uses .Once() or equivalent call modifier to enforce exactly one call                                                                     | <span class="g">✓</span>       | <span class="r">✗</span> no call modifier                      |
+| 4.5  | Uses mock.Anything for arguments that don't need specific matching (e.g., context)                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **5. mock-matched-by-predicate** — Tests knowledge of mock.MatchedBy for custom argument matching                                        | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 5.1  | Uses mock.MatchedBy with a predicate function for the LogEntry argument                                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 5.2  | The predicate checks Level == 'error'                                                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 5.3  | The predicate checks that Message contains 'timeout' (using strings.Contains or similar)                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 5.4  | Uses mock.Anything for the context argument                                                                                              | <span class="g">✓</span>       | <span class="r">✗</span> passes context.Background() literally |
+| 5.5  | Calls AssertExpectations at the end                                                                                                      | <span class="g">✓</span>       | <span class="r">✗</span> missing AssertExpectations            |
+|      | **6. mock-retry-different-returns** — Tests knowledge of chaining .Once() calls for retry testing                                        | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                                 |
+| 6.1  | Sets up first On().Return() with an error and .Once()                                                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 6.2  | Sets up second On().Return() with success data and .Once()                                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 6.3  | The two expectations are on the same method with the same arguments                                                                      | <span class="g">✓</span>       | <span class="r">✗</span> uses different argument patterns      |
+| 6.4  | Calls AssertExpectations to verify both calls happened                                                                                   | <span class="g">✓</span>       | <span class="r">✗</span> missing AssertExpectations            |
+|      | **7. suite-lifecycle-and-launcher** — Tests that suite requires a launcher function and understands lifecycle order                      | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 7.1  | Creates a suite struct embedding suite.Suite                                                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 7.2  | Uses SetupTest (not SetupSuite) for per-test mock store initialization                                                                   | <span class="g">✓</span>       | <span class="r">✗</span> uses SetupSuite for mock init         |
+| 7.3  | Includes a launcher function: func TestXxxSuite(t *testing.T) with suite.Run()                                                           | <span class="g">✓</span>       | <span class="r">✗</span> missing launcher function             |
+| 7.4  | Test methods are named TestXxx (starting with Test) on the suite receiver                                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 7.5  | Uses SetupSuite or TearDownSuite for the shared database connection (one-time setup)                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **8. suite-require-syntax** — Tests that suite methods use s.Require().NotNil() for require behavior                                     | **<span class="g">3/3</span>** | **<span class="r">1/3</span>**                                 |
+| 8.1  | Uses s.Require().NotNil() (not just s.NotNil()) for fail-fast behavior                                                                   | <span class="g">✓</span>       | <span class="r">✗</span> uses s.NotNil() thinking it's require |
+| 8.2  | Explains that s.NotNil() and similar suite methods behave like assert (continue on failure)                                              | <span class="g">✓</span>       | <span class="r">✗</span> no explanation of default behavior    |
+| 8.3  | Shows that s.Require() returns a require-style assertion object                                                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **9. pointer-comparison-trap** — Tests awareness that is.Equal(ptr1, ptr2) compares addresses, not values                                | **<span class="g">3/3</span>** | **<span class="r">2/3</span>**                                 |
+| 9.1  | Identifies that assert.Equal on pointers compares memory addresses, not struct values                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 9.2  | Recommends dereferencing the pointers or using EqualExportedValues                                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 9.3  | Mentions EqualExportedValues as an alternative for comparing only exported fields                                                        | <span class="g">✓</span>       | <span class="r">✗</span> only suggests dereferencing           |
+|      | **10. eventually-with-rich-assertions** — Tests knowledge of EventuallyWithT for async polling with multiple rich assertions             | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                 |
+| 10.1 | Uses EventuallyWithT (not just Eventually) for rich assertions                                                                           | <span class="g">✓</span>       | <span class="r">✗</span> uses Eventually with bool             |
+| 10.2 | The callback receives *assert.CollectT (or similar collect parameter)                                                                    | <span class="g">✓</span>       | <span class="r">✗</span> callback returns bool                 |
+| 10.3 | Multiple assertions are made inside the callback (status check AND result count check)                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 10.4 | Uses assert.NoError/assert.Equal with the CollectT parameter inside the callback, not with t                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 10.5 | Specifies timeout (10s) and polling interval as separate parameters                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+|      | **11. testifylint-recommendation** — Tests whether the model recommends testifylint for catching common testify mistakes                 | **<span class="g">3/3</span>** | **<span class="r">3/3</span>**                                 |
+| 11.1 | Recommends testifylint as a linter for testify-specific issues                                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 11.2 | Mentions that testifylint catches wrong argument order                                                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+| 11.3 | Mentions that testifylint catches assert/require misuse                                                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                       |
+
+</details>
+
+## `golang-samber-mo` — v1.0.0
+
+|             | With Skill       | Without Skill    | Delta     |
+| ----------- | ---------------- | ---------------- | --------- |
+| **Overall** | **95/108 (88%)** | **43/108 (40%)** | **+48pp** |
+
+<details>
+<summary>Full breakdown (108 assertions)</summary>
+
+**Model:** Claude Opus 4.6 | **Runs:** 23 evals × 2 configs = 46 subagents | **Grading:** Human-as-Judge + LLM-as-judge
+
+| #    | Assertion                                                                          | With                                                           | Without                                                     |
+| ---- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------- |
+|      | **1. option-vs-pointer-for-nullable-db-field** — Option[T] for nullable DB columns | **<span class="g">5/5</span>**                                 | **<span class="g">5/5</span>**                              |
+| 1.1  | Uses mo.Option[string] for nullable fields                                         | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 1.2  | Mentions sql.Scanner and driver.Valuer                                             | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 1.3  | Mentions json.Marshaler/Unmarshaler                                                | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 1.4  | Shows row.Scan with Option type                                                    | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 1.5  | Does NOT recommend sql.NullString                                                  | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+|      | **2. result-vs-tuple-error-boundary** — Result at API boundary vs internal         | **<span class="g">5/5</span>**                                 | **<span class="r">2/5</span>**                              |
+| 2.1  | Returns (Config, error) at public boundary                                         | <span class="g">✓</span>                                       | <span class="r">✗</span> returns Result publicly            |
+| 2.2  | Uses Result internally for chaining                                                | <span class="g">✓</span>                                       | <span class="r">✗</span> uses Result everywhere             |
+| 2.3  | Shows TupleToResult at boundary                                                    | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 2.4  | Shows .Get() at end for conversion back                                            | <span class="g">✓</span>                                       | <span class="r">✗</span> returns Result directly            |
+| 2.5  | Explains Result for internal composition                                           | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+|      | **3. either-vs-result-two-valid-types** — Either for non-error alternatives        | **<span class="g">5/5</span>**                                 | **<span class="r">2/5</span>**                              |
+| 3.1  | Uses Either[CachedUser, FreshUser]                                                 | <span class="g">✓</span>                                       | <span class="r">✗</span> uses interface or Result           |
+| 3.2  | Does NOT use Result                                                                | <span class="g">✓</span>                                       | <span class="r">✗</span> suggests common interface          |
+| 3.3  | Explains Either vs Result                                                          | <span class="g">✓</span>                                       | <span class="r">✗</span> no distinction made                |
+| 3.4  | Shows Left/Right constructors                                                      | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 3.5  | Shows Match or IsLeft/IsRight                                                      | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+|      | **4. sub-package-for-type-changing-map** — Sub-package for type-changing Map       | **<span class="g">5/5</span>**                                 | **<span class="r">1/5</span>**                              |
+| 4.1  | Uses option.Map from sub-package                                                   | <span class="g">✓</span>                                       | <span class="r">✗</span> uses nonexistent `mo.Map(opt, fn)` |
+| 4.2  | Does NOT use .Map for type change                                                  | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 4.3  | Imports mo/option                                                                  | <span class="g">✓</span>                                       | <span class="r">✗</span> no sub-package import              |
+| 4.4  | Shows curried form                                                                 | <span class="g">✓</span>                                       | <span class="r">✗</span> uses `mo.Map(opt, fn)` pattern     |
+| 4.5  | Explains why sub-packages exist                                                    | <span class="g">✓</span>                                       | <span class="r">✗</span> claims `mo.Map` is package-level   |
+|      | **5. do-notation-for-imperative-monadic** — mo.Do for imperative monadic code      | **<span class="g">5/5</span>**                                 | **<span class="r">0/5</span>**                              |
+| 5.1  | Suggests mo.Do                                                                     | <span class="g">✓</span>                                       | <span class="r">✗</span> suggests unwrap-early pattern      |
+| 5.2  | Shows MustGet inside Do                                                            | <span class="g">✓</span>                                       | <span class="r">✗</span> manual .Get() checks               |
+| 5.3  | Explains panic catching                                                            | <span class="g">✓</span>                                       | <span class="r">✗</span> no mention of Do                   |
+| 5.4  | Do returns Result[T]                                                               | <span class="g">✓</span>                                       | <span class="r">✗</span> no mention of Do                   |
+| 5.5  | Cleaner than FlatMap chains                                                        | <span class="g">✓</span>                                       | <span class="r">✗</span> no Do alternative                  |
+|      | **6. pipe-composition-multi-step** — Pipe for multi-step type-changing pipelines   | **<span class="g">5/5</span>**                                 | **<span class="r">0/5</span>**                              |
+| 6.1  | Uses option.Pipe3                                                                  | <span class="g">✓</span>                                       | <span class="r">✗</span> nests function calls               |
+| 6.2  | Each step uses option.Map/FlatMap                                                  | <span class="g">✓</span>                                       | <span class="r">✗</span> manual intermediate vars           |
+| 6.3  | Pipeline reads top-to-bottom                                                       | <span class="g">✓</span>                                       | <span class="r">✗</span> nested calls                       |
+| 6.4  | Imports mo/option sub-package                                                      | <span class="g">✓</span>                                       | <span class="r">✗</span> no sub-package awareness           |
+| 6.5  | FlatMap for validation step                                                        | <span class="g">✓</span>                                       | <span class="r">✗</span> manual if/else                     |
+|      | **7. future-vs-task-eager-vs-lazy** — Future (eager) vs Task (lazy)                | **<span class="g">5/5</span>**                                 | **<span class="r">4/5</span>**                              |
+| 7.1  | Recommends Task                                                                    | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 7.2  | Future starts immediately                                                          | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 7.3  | Task runs on .Run()                                                                | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 7.4  | Run returns *Future[T]                                                             | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 7.5  | Deferred execution pattern                                                         | <span class="g">✓</span>                                       | <span class="r">✗</span> wrong constructor signature        |
+|      | **8. tuple-to-result-wrapping-stdlib** — TupleToResult for stdlib wrapping         | **<span class="g">5/5</span>**                                 | **<span class="r">3/5</span>**                              |
+| 8.1  | Uses TupleToResult(os.ReadFile(path))                                              | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 8.2  | Uses TupleToResult or Try for Atoi                                                 | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 8.3  | Does NOT manually check err                                                        | <span class="g">✓</span>                                       | <span class="r">✗</span> manually constructs Ok/Err         |
+| 8.4  | Chains results                                                                     | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 8.5  | Explains TupleToResult                                                             | <span class="g">✓</span>                                       | <span class="r">✗</span> no explanation                     |
+|      | **9. when-not-to-use-monads** — Advises against monads for simple cases            | **<span class="g">4/4</span>**                                 | **<span class="g">3/4</span>**                              |
+| 9.1  | Advises against Result here                                                        | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 9.2  | Recommends if err != nil                                                           | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 9.3  | Result shines with chains                                                          | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 9.4  | Does NOT over-apply Result                                                         | <span class="g">✓</span>                                       | <span class="r">✗</span> still wraps in Result              |
+|      | **10. option-json-serialization** — Option JSON marshaling behavior                | **<span class="g">5/5</span>**                                 | **<span class="r">3/5</span>**                              |
+| 10.1 | Uses Option[string]                                                                | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 10.2 | Some->value, None->null                                                            | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 10.3 | Mentions omitzero (Go 1.24+)                                                       | <span class="g">✓</span>                                       | <span class="r">✗</span> no omitzero awareness              |
+| 10.4 | Shows struct with json tag                                                         | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 10.5 | No custom MarshalJSON needed                                                       | <span class="g">✓</span>                                       | <span class="r">✗</span> suggests custom marshaler          |
+|      | **11. emptyable-to-option-zero-value** — EmptyableToOption for zero detection      | **<span class="g">4/4</span>**                                 | **<span class="r">0/4</span>**                              |
+| 11.1 | Uses EmptyableToOption                                                             | <span class="g">✓</span>                                       | <span class="r">✗</span> manual if/else                     |
+| 11.2 | None for zero, Some for non-zero                                                   | <span class="g">✓</span>                                       | <span class="r">✗</span> manual construction                |
+| 11.3 | No manual check                                                                    | <span class="g">✓</span>                                       | <span class="r">✗</span> uses if/else                       |
+| 11.4 | Works for any comparable type                                                      | <span class="g">✓</span>                                       | <span class="r">✗</span> only handles string                |
+|      | **12. pointer-to-option-nil-handling** — PointerToOption for nil conversion        | **<span class="g">3/3</span>**                                 | **<span class="r">1/3</span>**                              |
+| 12.1 | Uses PointerToOption(ptr)                                                          | <span class="g">✓</span>                                       | <span class="r">✗</span> manual nil check                   |
+| 12.2 | nil->None, non-nil->Some                                                           | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 12.3 | No manual nil check                                                                | <span class="g">✓</span>                                       | <span class="r">✗</span> manual check                       |
+|      | **13. result-map-vs-flatmap-choice** — Map vs FlatMap on Result                    | **<span class="g">5/5</span>**                                 | **<span class="r">2/5</span>**                              |
+| 13.1 | MapValue for infallible uppercase                                                  | <span class="g">✓</span>                                       | <span class="r">✗</span> uses Map for both                  |
+| 13.2 | FlatMap for fallible parse                                                         | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 13.3 | No FlatMap for uppercase                                                           | <span class="g">✓</span>                                       | <span class="r">✗</span> uses FlatMap for both              |
+| 13.4 | Shows chain                                                                        | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 13.5 | Explains distinction                                                               | <span class="g">✓</span>                                       | <span class="r">✗</span> no distinction explained           |
+|      | **14. option-map-bool-semantics** — Option.Map's (T, bool) return type             | **<span class="g">4/4</span>**                                 | **<span class="r">0/4</span>**                              |
+| 14.1 | Uses Map with (int, bool) return                                                   | <span class="g">✓</span>                                       | <span class="r">✗</span> claims Map can't filter            |
+| 14.2 | false converts to None                                                             | <span class="g">✓</span>                                       | <span class="r">✗</span> doesn't know bool return           |
+| 14.3 | Shows (T, bool) signature                                                          | <span class="g">✓</span>                                       | <span class="r">✗</span> claims func(T) T                   |
+| 14.4 | No FlatMap for filtering                                                           | <span class="g">✓</span>                                       | <span class="r">✗</span> uses FlatMap                       |
+|      | **15. foldable-interface-uniform-matching** — Fold across Option/Result/Either     | **<span class="r">0/5</span>**                                 | **<span class="r">0/5</span>**                              |
+| 15.1 | Uses mo.Fold                                                                       | <span class="r">✗</span> not in skill                          | <span class="r">✗</span> separate switch blocks             |
+| 15.2 | Shows Foldable interface                                                           | <span class="r">✗</span> not in skill                          | <span class="r">✗</span> no Foldable awareness              |
+| 15.3 | successFn/failureFn callbacks                                                      | <span class="r">✗</span> not in skill                          | <span class="r">✗</span> manual matching                    |
+| 15.4 | Single Fold for all types                                                          | <span class="r">✗</span> not in skill                          | <span class="r">✗</span> separate logic                     |
+| 15.5 | No separate handling per type                                                      | <span class="r">✗</span> not in skill                          | <span class="r">✗</span> separate blocks                    |
+|      | **16. io-for-testable-side-effects** — IO for deferring side effects               | **<span class="g">4/4</span>**                                 | **<span class="r">0/4</span>**                              |
+| 16.1 | Uses IO or IOEither                                                                | <span class="g">✓</span>                                       | <span class="r">✗</span> uses interfaces/DI                 |
+| 16.2 | IO is lazy, runs on Run()                                                          | <span class="g">✓</span>                                       | <span class="r">✗</span> no IO awareness                    |
+| 16.3 | IO1/IO2 parameterize                                                               | <span class="g">✓</span>                                       | <span class="r">✗</span> no IO awareness                    |
+| 16.4 | Composability of IO                                                                | <span class="g">✓</span>                                       | <span class="r">✗</span> no IO awareness                    |
+|      | **17. result-to-either-conversion** — ToEither() conversion                        | **<span class="g">3/3</span>**                                 | **<span class="r">1/3</span>**                              |
+| 17.1 | Uses result.ToEither()                                                             | <span class="g">✓</span>                                       | <span class="r">✗</span> manual IsOk + Left/Right           |
+| 17.2 | Ok->Right, Err->Left                                                               | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 17.3 | No manual IsOk check                                                               | <span class="g">✓</span>                                       | <span class="r">✗</span> manual check                       |
+|      | **18. either3-for-multi-type-union** — Either3+ for n-ary unions                   | **<span class="g">5/5</span>**                                 | **<span class="r">2/5</span>**                              |
+| 18.1 | Uses Either3                                                                       | <span class="g">✓</span>                                       | <span class="r">✗</span> uses interface or type switch      |
+| 18.2 | Shows constructors                                                                 | <span class="g">✓</span>                                       | <span class="r">✗</span> no constructor awareness           |
+| 18.3 | Shows Match                                                                        | <span class="g">✓</span>                                       | <span class="r">✗</span> type switch                        |
+| 18.4 | No interface{}/any                                                                 | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 18.5 | Mentions Either4/Either5                                                           | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+|      | **19. option-vs-zero-value-distinction** — When Option adds value vs zero values   | **<span class="g">4/4</span>**                                 | **<span class="g">3/4</span>**                              |
+| 19.1 | Plain int for count                                                                | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 19.2 | Option[string] for nickname                                                        | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 19.3 | Explains absence vs zero                                                           | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 19.4 | No Option[int] for count                                                           | <span class="g">✓</span>                                       | <span class="r">✗</span> uses Option for both               |
+|      | **20. map-lookup-to-option** — TupleToOption for map lookups                       | **<span class="g">4/4</span>**                                 | **<span class="r">1/4</span>**                              |
+| 20.1 | Uses TupleToOption(m[key])                                                         | <span class="g">✓</span>                                       | <span class="r">✗</span> manual ok check                    |
+| 20.2 | Chains Map/FlatMap                                                                 | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 20.3 | No manual ok check                                                                 | <span class="g">✓</span>                                       | <span class="r">✗</span> manual check                       |
+| 20.4 | Complete pattern                                                                   | <span class="g">✓</span>                                       | <span class="r">✗</span> manual construction                |
+|      | **21. result-try-catch-panics** — Try for wrapping panicky functions               | **<span class="r">2/4</span>**                                 | **<span class="r">2/4</span>**                              |
+| 21.1 | Uses mo.Try                                                                        | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 21.2 | Try catches panics                                                                 | <span class="r">✗</span> skill says Do catches panics, not Try | <span class="r">✗</span> claims Try only wraps (T, error)   |
+| 21.3 | Shows signature                                                                    | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 21.4 | No separate defer/recover                                                          | <span class="r">✗</span> skill suggests Do for panics          | <span class="r">✗</span> adds defer/recover                 |
+|      | **22. state-monad-for-accumulation** — State monad for threading state             | **<span class="g">4/4</span>**                                 | **<span class="r">0/4</span>**                              |
+| 22.1 | Uses State/NewState                                                                | <span class="g">✓</span>                                       | <span class="r">✗</span> uses mutable struct                |
+| 22.2 | State params = state + result                                                      | <span class="g">✓</span>                                       | <span class="r">✗</span> mutable position field             |
+| 22.3 | Run(initialState)                                                                  | <span class="g">✓</span>                                       | <span class="r">✗</span> no State awareness                 |
+| 22.4 | State threaded, not mutated                                                        | <span class="g">✓</span>                                       | <span class="r">✗</span> mutates struct                     |
+|      | **23. result-map-signature** — Result.Map's (T, error) return type                 | **<span class="g">4/4</span>**                                 | **<span class="r">2/4</span>**                              |
+| 23.1 | Map callback returns (int, error)                                                  | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 23.2 | Does NOT use func(int) int                                                         | <span class="g">✓</span>                                       | <span class="g">✓</span>                                    |
+| 23.3 | MapValue alternative                                                               | <span class="g">✓</span>                                       | <span class="r">✗</span> no MapValue mention                |
+| 23.4 | Map vs MapValue signatures                                                         | <span class="g">✓</span>                                       | <span class="r">✗</span> no distinction                     |
+
+</details>
+
+## `golang-samber-hot` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **61/65 (94%)** | **26/65 (40%)** | **+54pp** |
+
+<details>
+<summary>Full breakdown (65 assertions)</summary>
+
+**Model:** Claude Opus 4.6 | **Runs:** 15 evals × 2 configs = 30 subagents | **Grading:** LLM-as-judge
+
+| #    | Assertion                                                                           | With                           | Without                                              |
+| ---- | ----------------------------------------------------------------------------------- | ------------------------------ | ---------------------------------------------------- |
+|      | **1. algorithm-selection-default** — mixed workload, should pick W-TinyLFU over LRU | **<span class="g">6/6</span>** | **<span class="r">0/6</span>**                       |
+| 1.1  | Uses hot.WTinyLFU as the eviction algorithm (not hot.LRU)                           | <span class="g">✓</span>       | <span class="r">✗</span> used hot.NewLRU             |
+| 1.2  | Uses hot.NewHotCache constructor with generic type parameters                       | <span class="g">✓</span>       | <span class="r">✗</span> fabricated API              |
+| 1.3  | Chains .WithTTL(10 * time.Minute) or equivalent                                     | <span class="g">✓</span>       | <span class="r">✗</span> positional arg              |
+| 1.4  | Chains .WithJanitor() in the builder                                                | <span class="g">✓</span>       | <span class="r">✗</span> missing                     |
+| 1.5  | Calls defer cache.StopJanitor() after Build()                                       | <span class="g">✓</span>       | <span class="r">✗</span> missing                     |
+| 1.6  | Calls .Build() to finalize the cache                                                | <span class="g">✓</span>       | <span class="r">✗</span> no builder pattern          |
+|      | **2. algorithm-selection-frequency** — stable power-law DNS, should pick LFU        | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                       |
+| 2.1  | Recommends hot.LFU for stable-frequency workload                                    | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 2.2  | Explains why LFU fits: keeps frequently accessed items                              | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 2.3  | Mentions LFU weakness doesn't apply because rankings are stable                     | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 2.4  | Does NOT default to LRU                                                             | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+|      | **3. janitor-required** — simple cache with TTL must include WithJanitor()          | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                       |
+| 3.1  | Includes .WithJanitor() in the builder chain                                        | <span class="g">✓</span>       | <span class="r">✗</span> fabricated config struct    |
+| 3.2  | Includes defer cache.StopJanitor() for cleanup                                      | <span class="g">✓</span>       | <span class="r">✗</span> missing                     |
+| 3.3  | Uses .WithTTL() for expiration                                                      | <span class="g">✓</span>       | <span class="r">✗</span> config struct field         |
+| 3.4  | Does NOT call cache.Janitor() separately after Build()                              | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+|      | **4. missing-cache-panic-prevention** — SetMissing requires config                  | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                       |
+| 4.1  | Configures WithMissingCache() or WithMissingSharedCache() in builder                | <span class="g">✓</span>       | <span class="r">✗</span> stores nil in main cache    |
+| 4.2  | Uses cache.SetMissing() or cache.SetMissingWithTTL()                                | <span class="g">✓</span>       | <span class="r">✗</span> uses cache.Set(key, nil)    |
+| 4.3  | Missing cache configured BEFORE Build()                                             | <span class="g">✓</span>       | <span class="r">✗</span> no config                   |
+| 4.4  | Explains SetMissing without config panics                                           | <span class="g">✓</span>       | <span class="r">✗</span> unaware of SetMissing       |
+|      | **5. loader-pattern-singleflight** — built-in dedup, no manual singleflight         | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                       |
+| 5.1  | Uses .WithLoaders() in the builder chain                                            | <span class="g">✓</span>       | <span class="r">✗</span> manual singleflight         |
+| 5.2  | Explains built-in singleflight deduplication                                        | <span class="g">✓</span>       | <span class="r">✗</span> suggests external package   |
+| 5.3  | Does NOT implement manual singleflight on top                                       | <span class="g">✓</span>       | <span class="r">✗</span> uses x/sync/singleflight    |
+| 5.4  | Loader signature matches func(keys []K) (map[K]V, error)                            | <span class="g">✓</span>       | <span class="r">✗</span> manual fetch pattern        |
+| 5.5  | Recommends WithJitter() for additional thundering-herd mitigation                   | <span class="g">✓</span>       | <span class="r">✗</span> manual rand jitter          |
+|      | **6. stale-while-revalidate** — two-threshold revalidation pattern                  | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                       |
+| 6.1  | Uses .WithTTL(5 * time.Minute) for fresh duration                                   | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 6.2  | Uses .WithRevalidation(2 * time.Minute, loader)                                     | <span class="g">✓</span>       | <span class="r">✗</span> invented API                |
+| 6.3  | Explains fresh -> stale -> expired model                                            | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 6.4  | Uses WithRevalidationErrorPolicy()                                                  | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned               |
+| 6.5  | Does NOT use a single 7min TTL                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+|      | **7. sharding-for-concurrency** — WithSharding for lock contention                  | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                       |
+| 7.1  | Uses .WithSharding() in the builder                                                 | <span class="g">✓</span>       | <span class="r">✗</span> custom sharded wrapper      |
+| 7.2  | Shard count is a power of 2                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 7.3  | Provides or discusses a hash function of type func(K) uint64                        | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 7.4  | Does NOT recommend WithoutLocking()                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+|      | **8. copy-on-read-mutable-values** — WithCopyOnRead for pointer safety              | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                       |
+| 8.1  | Identifies callers mutating shared cached pointers                                  | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 8.2  | Uses .WithCopyOnRead(fn)                                                            | <span class="g">✓</span>       | <span class="r">✗</span> manual copy wrapper         |
+| 8.3  | Copy function creates shallow or deep copy                                          | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 8.4  | Does NOT suggest only external mutexes as primary solution                          | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+|      | **9. loader-chain-semantics** — later overwrites earlier, error stops chain         | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                       |
+| 9.1  | Later loaders overwrite earlier values (PostgreSQL wins)                            | <span class="g">✓</span>       | <span class="r">✗</span> says Redis wins             |
+| 9.2  | Any loader error stops the entire chain                                             | <span class="g">✓</span>       | <span class="r">✗</span> unclear                     |
+| 9.3  | Partial results from earlier loaders discarded on error                             | <span class="g">✓</span>       | <span class="r">✗</span> not mentioned               |
+| 9.4  | Shows WithLoaders(redisLoader, dbLoader)                                            | <span class="g">✓</span>       | <span class="r">✗</span> invented API                |
+| 9.5  | Later loaders only receive keys NOT found by previous                               | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+|      | **10. algorithm-scan-resistance** — LRU scan pollution, switch to scan-resistant    | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                       |
+| 10.1 | Identifies LRU scan pollution problem                                               | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 10.2 | Recommends scan-resistant algorithm                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 10.3 | Explains why recommended algorithm resists scan pollution                           | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 10.4 | Does NOT suggest only increasing cache size                                         | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+|      | **11. withoutlocking-janitor-conflict** — mutually exclusive, panics                | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                       |
+| 11.1 | Warns WithoutLocking() + WithJanitor() are mutually exclusive                       | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 11.2 | Recommends removing one of the two                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 11.3 | Suggests manual cleanup or dropping WithoutLocking()                                | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 11.4 | Does NOT produce code chaining both                                                 | <span class="g">✓</span>       | <span class="r">✗</span> initial code chains both    |
+|      | **12. warmup-before-traffic** — WithWarmUp in builder                               | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                       |
+| 12.1 | Uses .WithWarmUp(fn) or .WithWarmUpWithTimeout(timeout, fn)                         | <span class="g">✓</span>       | <span class="r">✗</span> wrong API guess             |
+| 12.2 | Warm-up function returns (map[K]V, []K, error)                                      | <span class="g">✓</span>       | <span class="r">✗</span> wrong signature             |
+| 12.3 | Warm-up happens before Build() returns                                              | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 12.4 | Does NOT manually loop calling Set()                                                | <span class="g">✓</span>       | <span class="r">✗</span> loops calling Get()         |
+|      | **13. prometheus-monitoring-setup** — built-in WithPrometheusMetrics                | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                       |
+| 13.1 | Uses .WithPrometheusMetrics(cacheName)                                              | <span class="g">✓</span>       | <span class="r">✗</span> custom counters             |
+| 13.2 | Registers with prometheus.MustRegister(cache)                                       | <span class="g">✓</span>       | <span class="r">✗</span> registers custom metrics    |
+| 13.3 | Mentions hit rate as key metric (target >80%)                                       | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 13.4 | Does NOT create custom Prometheus counters                                          | <span class="g">✓</span>       | <span class="r">✗</span> full custom instrumentation |
+|      | **14. get-error-handling** — three return values (V, bool, error)                   | **<span class="g">4/4</span>** | **<span class="r">2/4</span>**                       |
+| 14.1 | Get() returns (V, bool, error)                                                      | <span class="g">✓</span>       | <span class="r">✗</span> wrong semantics             |
+| 14.2 | Checks error first before bool                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 14.3 | Handles all three cases: err, !found, found                                         | <span class="g">✓</span>       | <span class="r">✗</span> no not-found handling       |
+| 14.4 | Does NOT ignore error return value                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+|      | **15. peek-vs-get-distinction** — Peek() for side-effect-free inspection            | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                       |
+| 15.1 | Recommends Peek() or PeekMany()                                                     | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 15.2 | Explains Peek() does not trigger loaders                                            | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+| 15.3 | Explains Peek() ignores expiration (returns expired entries)                        | <span class="g">✓</span>       | <span class="r">✗</span> no expired-entry detail     |
+| 15.4 | Does NOT recommend Get() for inspection                                             | <span class="g">✓</span>       | <span class="g">✓</span>                             |
+
+</details>
+
+## `golang-samber-lo` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **83/86 (97%)** | **49/86 (57%)** | **+40pp** |
+
+<details>
+<summary>Full breakdown (86 assertions)</summary>
+
+**Model:** Claude Opus 4.6 | **Runs:** 17 evals × 2 configs = 34 subagents | **Grading:** LLM-as-judge
+
+| #    | Assertion                                                                           | With                           | Without                                                |
+| ---- | ----------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------ |
+|      | **1. lop-for-io-trap** — Should recommend errgroup over lop for HTTP fan-out        | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                         |
+| 1.1  | Recommends errgroup or similar I/O concurrency pattern                              | <span class="g">✓</span>       | <span class="r">✗</span> used lop.Map as primary       |
+| 1.2  | Explains lop is for CPU-bound parallelism, not I/O                                  | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 1.3  | Mentions lack of context cancellation as lop limitation                             | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 1.4  | Does NOT use lop.Map as primary HTTP fan-out solution                               | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 1.5  | Shows working Go code for concurrent fetch                                          | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **2. premature-lom-optimization** — Should advise profiling before switching to lom | **<span class="g">6/6</span>** | **<span class="r">3/6</span>**                         |
+| 2.1  | Recommends profiling (pprof, alloc_objects) before switching                        | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 2.2  | Warns lom mutates input slice (breaks immutability)                                 | <span class="g">✓</span>       | <span class="r">✗</span> claims lom doesn't exist      |
+| 2.3  | Does NOT blindly refactor all lo calls to lom                                       | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 2.4  | Explains performance issue may not be lo allocations                                | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 2.5  | Mentions lom only for hot paths confirmed by profiling                              | <span class="g">✓</span>       | <span class="r">✗</span> claims lom doesn't exist      |
+| 2.6  | Warns about concurrency safety of mutable ops                                       | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+|      | **3. stdlib-vs-lo-preference** — Should prefer stdlib for Contains/Sort/Keys        | **<span class="g">6/6</span>** | **<span class="r">5/6</span>**                         |
+| 3.1  | Recommends slices.Contains from stdlib                                              | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 3.2  | Recommends slices.Sort from stdlib                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 3.3  | Recommends maps.Keys from stdlib                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 3.4  | Mentions Go 1.21+ availability                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 3.5  | Explains rationale: prefer stdlib when available                                    | <span class="g">✓</span>       | <span class="r">✗</span> says "either works fine"      |
+| 3.6  | Acknowledges lo useful for ops stdlib lacks                                         | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **4. loi-go-version-constraint** — Should warn lo/it requires Go 1.23+              | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                         |
+| 4.1  | Warns loi requires Go 1.23+, not available in Go 1.20                               | <span class="g">✓</span>       | <span class="r">✗</span> claims lo/it doesn't exist    |
+| 4.2  | Suggests upgrading Go version to 1.23+                                              | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 4.3  | Provides alternative approaches for Go 1.20                                         | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 4.4  | Does NOT provide loi code that won't compile on Go 1.20                             | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 4.5  | Mentions range-over-func as Go 1.23 feature                                         | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+|      | **5. must-in-production-handler** — Should warn against Must in HTTP handlers       | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                         |
+| 5.1  | Warns Must panics on error, dangerous in handlers                                   | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 5.2  | Explains Must for tests/init only, not production                                   | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 5.3  | Provides refactored version with proper error handling                              | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 5.4  | Shows returning appropriate HTTP error status codes                                 | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 5.5  | Does NOT approve Must-based approach for production                                 | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **6. import-aliases-knowledge** — Should know lop/lom/loi aliases                   | **<span class="g">5/5</span>** | **<span class="r">2/5</span>**                         |
+| 6.1  | Lists lo/parallel with alias lop                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 6.2  | Lists lo/mutable with alias lom                                                     | <span class="g">✓</span>       | <span class="r">✗</span> unaware of mutable pkg        |
+| 6.3  | Lists lo/it with alias loi                                                          | <span class="g">✓</span>       | <span class="r">✗</span> unaware of iterator pkg       |
+| 6.4  | Mentions lo/it requires Go 1.23+                                                    | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 6.5  | Lists core package with alias lo                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **7. immutability-trap** — lo.Filter does NOT modify input                          | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                         |
+| 7.1  | States lo.Filter returns new slice, doesn't modify input                            | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 7.2  | Correctly says len(users) prints 2                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 7.3  | Explains lo is immutable by default as design principle                             | <span class="g">✓</span>       | <span class="r">✗</span> no design principle framing   |
+| 7.4  | Points out return value of lo.Filter is discarded                                   | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 7.5  | Mentions lom.Filter as alternative for in-place mutation                            | <span class="g">✓</span>       | <span class="r">✗</span> no mention of lom             |
+|      | **8. error-variant-awareness** — Should recommend lo.MapErr                         | **<span class="r">4/5</span>** | **<span class="r">1/5</span>**                         |
+| 8.1  | Recommends lo.MapErr as error-aware variant                                         | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 8.2  | Explains MapErr stops on first error, returns (result, error)                       | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 8.3  | Shows MapErr usage example                                                          | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 8.4  | Mentions most lo functions have Err suffixes as pattern                             | <span class="r">✗</span>       | <span class="r">✗</span>                               |
+| 8.5  | Suggests lo.FilterMap for skipping errors                                           | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **9. simd-production-stability** — Should warn simd is experimental                 | **<span class="r">4/5</span>** | **<span class="r">2/5</span>**                         |
+| 9.1  | Warns lo/exp/simd is experimental, API may break                                    | <span class="g">✓</span>       | <span class="r">✗</span> claims simd doesn't exist     |
+| 9.2  | States not covered by semver stability guarantees                                   | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 9.3  | Recommends benchmarking first                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 9.4  | Suggests version pinning if used                                                    | <span class="r">✗</span>       | <span class="r">✗</span>                               |
+| 9.5  | Does NOT unconditionally recommend simd for production                              | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **10. streaming-redirect-to-ro** — Should redirect to samber/ro                     | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                         |
+| 10.1 | Recommends samber/ro for reactive/streaming pipelines                               | <span class="g">✓</span>       | <span class="r">✗</span> suggests samber/hot instead   |
+| 10.2 | Explains lo is for finite/batch, not infinite streams                               | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 10.3 | Mentions golang-samber-ro skill or samber/ro by name                                | <span class="g">✓</span>       | <span class="r">✗</span> mentions samber/hot not ro    |
+| 10.4 | Does NOT attempt to use lo for infinite streaming                                   | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 10.5 | Explains conceptual difference: lo = batch, ro = reactive                           | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **11. lop-small-dataset-trap** — lop.Map wasteful for 10 items                      | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                         |
+| 11.1 | Recommends lo.Map instead of lop.Map for 10 items                                   | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 11.2 | Explains goroutine overhead exceeds benefit                                         | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 11.3 | Mentions threshold (~1000+ items)                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 11.4 | Notes field access is trivial, no parallelism benefit                               | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 11.5 | Does NOT recommend lop.Map for this case                                            | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **12. filtermap-vs-filter-then-map** — Should use lo.FilterMap                      | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                         |
+| 12.1 | Recommends lo.FilterMap as single-pass alternative                                  | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 12.2 | Shows FilterMap with (R, bool) return signature                                     | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 12.3 | Explains avoids intermediate filtered slice                                         | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 12.4 | Provides working code parsing strings to ints                                       | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 12.5 | Does NOT chain Filter+Map as primary solution                                       | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **13. channel-dispatcher-strategies** — Should list ChannelDispatcher strategies    | **<span class="g">6/6</span>** | **<span class="g">6/6</span>**                         |
+| 13.1 | Mentions lo.ChannelDispatcher                                                       | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 13.2 | Lists RoundRobin strategy                                                           | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 13.3 | Lists Random strategy                                                               | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 13.4 | Lists WeightedRandom/First/Least/Most                                               | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 13.5 | Explains when to choose different strategies                                        | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 13.6 | Shows code example using ChannelDispatcher                                          | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **14. v2-version-trap** — Should state v2 does not exist                            | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                         |
+| 14.1 | States samber/lo v2 does not exist                                                  | <span class="g">✓</span>       | <span class="r">✗</span> fabricated v2 migration guide |
+| 14.2 | Mentions v1 follows semver, no breaking changes before v2                           | <span class="g">✓</span>       | <span class="r">✗</span> fabricated breaking changes   |
+| 14.3 | Provides correct install: go get github.com/samber/lo@v1                            | <span class="g">✓</span>       | <span class="r">✗</span> shows go get lo/v2            |
+| 14.4 | Does NOT fabricate v2 migration steps                                               | <span class="g">✓</span>       | <span class="r">✗</span> full fabricated migration     |
+|      | **15. lazy-chain-intermediate-allocations** — Should recommend loi                  | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                         |
+| 15.1 | Recommends lo/it (loi) for lazy evaluation                                          | <span class="g">✓</span>       | <span class="r">✗</span> claims loi doesn't exist      |
+| 15.2 | Explains loi processes on-demand without buffering                                  | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 15.3 | Mentions Go 1.23+ requirement                                                       | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 15.4 | Shows lazy pipeline using loi functions                                             | <span class="g">✓</span>       | <span class="r">✗</span>                               |
+| 15.5 | Contrasts eager vs lazy memory allocation                                           | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+|      | **16. lo-zero-dependencies** — Should state zero external deps                      | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                         |
+| 16.1 | States zero external/runtime dependencies                                           | <span class="g">✓</span>       | <span class="r">✗</span> claims golang.org/x/exp dep   |
+| 16.2 | Mentions relies only on Go stdlib                                                   | <span class="g">✓</span>       | <span class="r">✗</span> mentions x/exp                |
+| 16.3 | Addresses supply chain concern                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 16.4 | Does NOT claim lo has external dependencies                                         | <span class="g">✓</span>       | <span class="r">✗</span> claims x/exp dependency       |
+|      | **17. ternary-evaluation-trap** — lo.Ternary evaluates both branches                | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                         |
+| 17.1 | Warns lo.Ternary evaluates both arguments                                           | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 17.2 | Recommends lo.TernaryF for lazy evaluation                                          | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 17.3 | Shows TernaryF usage with closures                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+| 17.4 | Explains expensiveCompute runs even when condition is false                         | <span class="g">✓</span>       | <span class="g">✓</span>                               |
+
+</details>
+
+## `golang-samber-slog` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **57/62 (92%)** | **45/62 (73%)** | **+19pp** |
+
+<details>
+<summary>Full breakdown (62 assertions)</summary>
+
+**Model:** Claude Opus 4.6 | **Runs:** 12 evals × 2 configs = 24 subagents | **Grading:** LLM-as-judge
+
+| #    | Assertion                                                               | With                                       | Without                                             |
+| ---- | ----------------------------------------------------------------------- | ------------------------------------------ | --------------------------------------------------- |
+|      | **1. pipeline-ordering** — sampling + PII + Sentry composition          | **<span class="g">5/5</span>**             | **<span class="r">3/5</span>**                      |
+| 1.1  | Sampling is outermost/first handler in pipeline                         | <span class="g">✓</span>                   | <span class="r">✗</span> PII first, sampling second |
+| 1.2  | Uses slog-sampling library for sampling                                 | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 1.3  | Uses slog-formatter for PII scrubbing                                   | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 1.4  | Uses slogmulti.Router or Fanout for routing                             | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 1.5  | Explains why sampling should be first                                   | <span class="g">✓</span>                   | <span class="r">✗</span> no ordering rationale      |
+|      | **2. fanout-vs-router** — level-based routing to Sentry/Slack/stdout    | **<span class="g">5/5</span>**             | **<span class="g">5/5</span>**                      |
+| 2.1  | Uses slogmulti.Router() for level-based routing                         | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 2.2  | stdout receives all log levels                                          | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 2.3  | Sentry receives only errors                                             | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 2.4  | Slack receives only warnings                                            | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 2.5  | Explains Router vs Fanout distinction                                   | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+|      | **3. missing-close-batch** — Datadog handler graceful shutdown          | **<span class="g">5/5</span>**             | **<span class="r">4/5</span>**                      |
+| 3.1  | Calls handler.Close() or defer Close()                                  | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 3.2  | Uses Option{}.NewDatadogHandler() pattern                               | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 3.3  | Close happens during graceful shutdown                                  | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 3.4  | Mentions batching / data loss risk                                      | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 3.5  | Import path uses versioned module (v2+)                                 | <span class="g">✓</span>                   | <span class="r">✗</span> unversioned import         |
+|      | **4. sampling-strategy-selection** — reduce 90% volume, keep errors     | **<span class="g">5/5</span>**             | **<span class="g">5/5</span>**                      |
+| 4.1  | Uses Threshold or Absolute (not Uniform)                                | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 4.2  | Sampling only affects Debug/Info levels                                 | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 4.3  | Warn/Error pass through unsampled                                       | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 4.4  | Uses slog-sampling library                                              | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 4.5  | Explains why Uniform is wrong                                           | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+|      | **5. router-missing-default** — DEBUG logs disappearing                 | **<span class="g">5/5</span>**             | **<span class="g">5/5</span>**                      |
+| 5.1  | Identifies missing catch-all handler                                    | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 5.2  | Explains unmatched records silently dropped                             | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 5.3  | Suggests adding default handler or LevelIs(Debug)                       | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 5.4  | Uses slogmulti.Router() API correctly                                   | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 5.5  | Does NOT suggest changing log level as fix                              | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+|      | **6. http-middleware-filters** — slog-gin with path filters             | **<span class="g">5/5</span>**             | **<span class="g">5/5</span>**                      |
+| 6.1  | Uses sloggin.NewWithConfig()                                            | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 6.2  | Configures IgnorePath for /health and /metrics                          | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 6.3  | Sets WithRequestBody: true                                              | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 6.4  | Config includes level fields                                            | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 6.5  | Uses IgnorePath (not custom filter)                                     | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+|      | **7. pipe-middleware-chain** — trace injection + email scrubbing        | **<span class="g">5/5</span>**             | **<span class="r">4/5</span>**                      |
+| 7.1  | Uses slogmulti.Pipe() for chaining                                      | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 7.2  | Creates middleware for trace_id injection                               | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 7.3  | Creates middleware for email scrubbing                                  | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 7.4  | Pipe wraps the final handler                                            | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 7.5  | Does NOT implement custom slog.Handler struct                           | <span class="g">✓</span>                   | <span class="r">✗</span> full Handler struct        |
+|      | **8. failover-handler** — Loki fallback to file                         | **<span class="g">5/5</span>**             | **<span class="r">4/5</span>**                      |
+| 8.1  | Uses slogmulti.Failover()                                               | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 8.2  | Loki is primary handler                                                 | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 8.3  | File handler is fallback                                                | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 8.4  | Does NOT implement custom retry logic                                   | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 8.5  | Uses slog-loki library                                                  | <span class="g">✓</span>                   | <span class="r">✗</span> placeholder function       |
+|      | **9. pool-vs-fanout-latency** — fix sequential Fanout latency           | **<span class="r">2/5</span>**             | **<span class="r">2/5</span>**                      |
+| 9.1  | Identifies sequential Fanout as root cause                              | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 9.2  | Recommends slogmulti.Pool()                                             | <span class="r">✗</span> custom goroutines | <span class="r">✗</span> misuses Pool               |
+| 9.3  | Explains latency reduction (sum to max)                                 | <span class="g">✓</span>                   | <span class="r">✗</span> claims 0ms latency         |
+| 9.4  | Does NOT suggest raw goroutines as primary                              | <span class="r">✗</span>                   | <span class="g">✓</span>                            |
+| 9.5  | Shows code change from Fanout to Pool                                   | <span class="r">✗</span>                   | <span class="r">✗</span>                            |
+|      | **10. formatter-pii-scrubbing** — cross-cutting PII protection          | **<span class="g">5/5</span>**             | **<span class="r">3/5</span>**                      |
+| 10.1 | Uses slog-formatter library                                             | <span class="g">✓</span>                   | <span class="r">✗</span> custom middleware          |
+| 10.2 | Uses PIIFormatter and/or IPAddressFormatter                             | <span class="g">✓</span>                   | <span class="r">✗</span> custom regex               |
+| 10.3 | Applied as Pipe middleware wrapping all handlers                        | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 10.4 | Applied once before Router/Fanout                                       | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 10.5 | Does NOT implement custom per-handler PII logic                         | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+|      | **11. backend-option-pattern** — Sentry + Loki setup                    | **<span class="g">5/5</span>**             | **<span class="r">4/5</span>**                      |
+| 11.1 | Uses slogsentry.Option{}.NewSentryHandler()                             | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 11.2 | Uses slogloki.Option{}.NewLokiHandler()                                 | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 11.3 | Uses Router for level-based routing                                     | <span class="g">✓</span>                   | <span class="r">✗</span> uses Fanout                |
+| 11.4 | Versioned import paths                                                  | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 11.5 | Calls Close() on Loki handler                                           | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+|      | **12. attrfromcontext-without-middleware** — empty request_id diagnosis | **<span class="g">7/7</span>**             | **<span class="r">6/7</span>**                      |
+| 12.1 | Identifies no middleware populating context                             | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 12.2 | Recommends adding HTTP middleware                                       | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 12.3 | Explains middleware injects attributes into context                     | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 12.4 | Does NOT suggest changing context key as primary fix                    | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 12.5 | Shows connection between middleware and AttrFromContext                 | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+| 12.6 | Mentions WithRequestID config option                                    | <span class="g">✓</span>                   | <span class="r">✗</span>                            |
+| 12.7 | Does NOT blame slog-multi/sentry config                                 | <span class="g">✓</span>                   | <span class="g">✓</span>                            |
+
+</details>
+
+## `golang-samber-ro` — v1.0.0
+
+|             | With Skill         | Without Skill    | Delta     |
+| ----------- | ------------------ | ---------------- | --------- |
+| **Overall** | **113/113 (100%)** | **57/113 (50%)** | **+50pp** |
+
+<details>
+<summary>Full breakdown (113 assertions)</summary>
+
+**Model:** Claude Opus 4.6 | **Runs:** 25 evals × 2 configs = 50 subagents | **Grading:** LLM-as-judge (self-grading subagents)
+
+| #    | Assertion                                                               | With                           | Without                                                 |
+| ---- | ----------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------------- |
+|      | **1. typed-pipe-vs-untyped** — chain 3 operators with type safety       | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                          |
+| 1.1  | Uses ro.Pipe3 instead of untyped ro.Pipe for compile-time type safety   | <span class="g">✓</span>       | <span class="r">✗</span> uses untyped Pipe              |
+| 1.2  | Uses ro.Filter with func(int) bool predicate                            | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 1.3  | Uses ro.Map with func(int) string transform                             | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 1.4  | Uses ro.Take[string](5) with correct generic type                       | <span class="g">✓</span>       | <span class="r">✗</span> omits generic param            |
+|      | **2. lo-vs-ro-boundary** — finite slice should use lo, not ro           | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                          |
+| 2.1  | Recommends samber/lo instead of samber/ro                               | <span class="g">✓</span>       | <span class="r">✗</span> uses ro Observable             |
+| 2.2  | Explains WHY lo is better: synchronous, no stream overhead              | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 2.3  | Does NOT create an Observable pipeline for a slice transform            | <span class="g">✓</span>       | <span class="r">✗</span> creates Observable             |
+| 2.4  | Uses lo.Filter and lo.Map                                               | <span class="g">✓</span>       | <span class="r">✗</span> uses ro operators              |
+|      | **3. observer-error-handling** — full observer, not just OnNext         | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                          |
+| 3.1  | Uses ro.NewObserver with all 3 callbacks                                | <span class="g">✓</span>       | <span class="r">✗</span> uses ro.OnNext                 |
+| 3.2  | Includes an error handler                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 3.3  | Includes a completion handler                                           | <span class="g">✓</span>       | <span class="r">✗</span> infinite stream, skipped       |
+| 3.4  | Mentions risk of OnNext alone (silent error dropping)                   | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+|      | **4. infinite-stream-shutdown** — graceful SIGTERM shutdown             | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                          |
+| 4.1  | Uses TakeUntil or context+ThrowOnContextCancel                          | <span class="g">✓</span>       | <span class="r">✗</span> generic context approach       |
+| 4.2  | Mentions signal plugin (plugins/signal)                                 | <span class="g">✓</span>       | <span class="r">✗</span> uses manual os/signal          |
+| 4.3  | Calls .Wait() to block until shutdown                                   | <span class="g">✓</span>       | <span class="r">✗</span> doesn't know .Wait()           |
+| 4.4  | Does NOT suggest manual channel/goroutine killing                       | <span class="g">✓</span>       | <span class="r">✗</span> uses channel-based approach    |
+| 4.5  | Mentions Unsubscribe() as alternative                                   | <span class="g">✓</span>       | <span class="r">✗</span> not in ro API context          |
+|      | **5. subject-config-store** — BehaviorSubject for config                | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                          |
+| 5.1  | Recommends BehaviorSubject                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 5.2  | Explains replay of last value to new subscribers                        | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 5.3  | Shows NewBehaviorSubject[Config](initial) constructor                   | <span class="g">✓</span>       | <span class="r">✗</span> wrong constructor syntax       |
+| 5.4  | Shows .Send() and .Subscribe()                                          | <span class="g">✓</span>       | <span class="r">✗</span> uses .Next() from RxJS         |
+| 5.5  | Does NOT recommend PublishSubject                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **6. subject-chat-room** — ReplaySubject for chat history               | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                          |
+| 6.1  | Recommends ReplaySubject with buffer 50                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 6.2  | Shows NewReplaySubject[Message](50) constructor                         | <span class="g">✓</span>       | <span class="r">✗</span> wrong constructor syntax       |
+| 6.3  | Explains N-value replay for late subscribers                            | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 6.4  | Does NOT recommend BehaviorSubject                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **7. share-websocket** — hot observable for shared WebSocket            | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                          |
+| 7.1  | Uses Share() or ShareReplay()                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 7.2  | Creates only ONE WebSocket connection                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 7.3  | Does NOT create 3 separate connections                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 7.4  | Shows 3 separate .Subscribe() calls                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 7.5  | Explains cold vs hot distinction                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **8. combinelatest-vs-zip** — latest values from different-rate sources | **<span class="g">6/6</span>** | **<span class="r">5/6</span>**                          |
+| 8.1  | Recommends CombineLatest2                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 8.2  | Explains re-emit on either source update                                | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 8.3  | Explains why NOT Zip                                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 8.4  | Explains why NOT Merge                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 8.5  | Shows lo.Tuple2 return type                                             | <span class="g">✓</span>       | <span class="r">✗</span> generic tuple                  |
+| 8.6  | Uses Map to compute product                                             | <span class="g">✓</span>       | <span class="r">✗</span> generic combiner function      |
+|      | **9. retry-with-backoff** — RetryWithConfig + cached fallback           | **<span class="g">6/6</span>** | **<span class="r">1/6</span>**                          |
+| 9.1  | Uses RetryWithConfig (not infinite Retry)                               | <span class="g">✓</span>       | <span class="r">✗</span> uses Retry with count param    |
+| 9.2  | Sets Max: 3                                                             | <span class="g">✓</span>       | <span class="r">✗</span> wrong API                      |
+| 9.3  | Sets Delay: 500ms and BackoffMultiplier: 2.0                            | <span class="g">✓</span>       | <span class="r">✗</span> wrong field names              |
+| 9.4  | Sets MaxDelay: 10s                                                      | <span class="g">✓</span>       | <span class="r">✗</span> field not included             |
+| 9.5  | Chains fallback after RetryWithConfig                                   | <span class="g">✓</span>       | <span class="r">✗</span> uses RxJS-style naming         |
+| 9.6  | Correct operator order: retry before fallback                           | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **10. scan-vs-reduce** — running average for dashboard                  | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                          |
+| 10.1 | Recommends Scan                                                         | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 10.2 | Explains intermediate emission                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 10.3 | Explains Reduce only emits final                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 10.4 | Shows accumulator with count/sum                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 10.5 | Notes infinite stream + Reduce = never emits                            | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **11. collect-synchronous** — Collect for finite observable to slice    | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                          |
+| 11.1 | Uses ro.Collect returning ([]int, error)                                | <span class="g">✓</span>       | <span class="r">✗</span> manual subscribe+accumulate    |
+| 11.2 | Checks error return value                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 11.3 | Does NOT manually subscribe and accumulate                              | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 11.4 | Mentions Collect blocks until complete                                  | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+|      | **12. context-propagation** — wire timeout into pipeline                | **<span class="g">4/4</span>** | **<span class="r">1/4</span>**                          |
+| 12.1 | Uses ContextWithTimeout or ContextReset                                 | <span class="g">✓</span>       | <span class="r">✗</span> passes ctx to Subscribe        |
+| 12.2 | Uses ThrowOnContextCancel                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 12.3 | Chains context operators in pipeline                                    | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 12.4 | Handles cancellation error in onError                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **13. plugin-fsnotify** — file watcher with debounce                    | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                          |
+| 13.1 | Knows fsnotify plugin (plugins/fsnotify)                                | <span class="g">✓</span>       | <span class="r">✗</span> uses manual fsnotify           |
+| 13.2 | Uses plugin to create observable                                        | <span class="g">✓</span>       | <span class="r">✗</span> wraps channel manually         |
+| 13.3 | Uses ThrottleTime for debounce                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 13.4 | Filters for Write events                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 13.5 | Shows Map to reload config                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **14. plugin-cron** — daily midnight schedule                           | **<span class="g">4/4</span>** | **<span class="r">0/4</span>**                          |
+| 14.1 | Knows cron plugin (plugins/cron)                                        | <span class="g">✓</span>       | <span class="r">✗</span> uses Interval                  |
+| 14.2 | Uses cron expression `0 0 * * *`                                        | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 14.3 | Shows correct import path                                               | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 14.4 | Chains with Map/FlatMap for report generation                           | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+|      | **15. maperr-fallible-transform** — MapErr for JSON parsing             | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                          |
+| 15.1 | Uses MapErr (not Map)                                                   | <span class="g">✓</span>       | <span class="r">✗</span> uses Map                       |
+| 15.2 | Shows func(string) (MyStruct, error) signature                          | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 15.3 | Explains error propagation through pipeline                             | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 15.4 | Does NOT suggest panic/recover pattern                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 15.5 | Mentions JSON encoding plugin as alternative                            | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+|      | **16. buffer-batching** — BufferWithTimeOrCount for DB writes           | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                          |
+| 16.1 | Uses BufferWithTimeOrCount                                              | <span class="g">✓</span>       | <span class="r">✗</span> generic buffer approach        |
+| 16.2 | Sets count=100, duration=5s                                             | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 16.3 | Chains with Map/MapErr for batch processing                             | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 16.4 | Explains why both conditions matter                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **17. unicast-subject-queue** — single-consumer job queue               | **<span class="g">5/5</span>** | **<span class="r">0/5</span>**                          |
+| 17.1 | Recommends UnicastSubject                                               | <span class="g">✓</span>       | <span class="r">✗</span> uses channel or PublishSubject |
+| 17.2 | Shows NewUnicastSubject[Task](bufferSize)                               | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 17.3 | Explains exactly one subscriber                                         | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 17.4 | Explains pre-subscribe buffering                                        | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+| 17.5 | Does NOT recommend PublishSubject                                       | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+|      | **18. share-vs-sharereplay** — late subscribers missing data            | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                          |
+| 18.1 | Recommends ShareReplay(1)                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 18.2 | Explains Share doesn't buffer                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 18.3 | Explains ShareReplay buffers last N                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 18.4 | Shows correct syntax ro.ShareReplay[T](1)                               | <span class="g">✓</span>       | <span class="r">✗</span> wrong generic syntax           |
+|      | **19. error-recovery-cascade** — retry then fallback then default       | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                          |
+| 19.1 | Correct order: RetryWithConfig, Catch, OnErrorReturn                    | <span class="g">✓</span>       | <span class="r">✗</span> wrong operator names           |
+| 19.2 | Uses RetryWithConfig with Max: 2                                        | <span class="g">✓</span>       | <span class="r">✗</span> generic retry approach         |
+| 19.3 | Uses Catch for secondary source                                         | <span class="g">✓</span>       | <span class="r">✗</span> uses RxJS-style naming         |
+| 19.4 | Uses OnErrorReturn for default                                          | <span class="g">✓</span>       | <span class="r">✗</span> wrong operator name            |
+| 19.5 | Correct Pipe order                                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **20. channel-bridge** — FromChannel for legacy chan                    | **<span class="g">4/4</span>** | **<span class="g">4/4</span>**                          |
+| 20.1 | Uses ro.FromChannel[Event](ch)                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 20.2 | Observable completes when channel closes                                | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 20.3 | Chains standard operators                                               | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 20.4 | Does NOT create custom NewObservable                                    | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **21. tap-for-observability** — logging without modifying stream        | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                          |
+| 21.1 | Uses Tap/TapOnNext/TapOnError/TapOnComplete                             | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 21.2 | Does NOT use Map with side effect                                       | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 21.3 | Shows TapOnError for error monitoring                                   | <span class="g">✓</span>       | <span class="r">✗</span> generic Tap only               |
+| 21.4 | Explains Tap/Do observe without altering                                | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 21.5 | Mentions logging plugins (slog, zap, etc.)                              | <span class="g">✓</span>       | <span class="r">✗</span>                                |
+|      | **22. connectable-precise-control** — wait for all subscribers          | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                          |
+| 22.1 | Recommends Connectable                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 22.2 | Shows ro.Connectable[T](source)                                         | <span class="g">✓</span>       | <span class="r">✗</span> wrong constructor              |
+| 22.3 | Sets up subscribers before Connect                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 22.4 | Explains Connect() starts execution                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 22.5 | Explains why Share() is wrong                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **23. flatmap-vs-map** — flatten Observable[Observable[T]]              | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                          |
+| 23.1 | Recommends FlatMap or MergeMap                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 23.2 | Shows FlatMap code                                                      | <span class="g">✓</span>       | <span class="r">✗</span> wrong generic syntax           |
+| 23.3 | Explains map+flatten behavior                                           | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 23.4 | Does NOT suggest Map+MergeAll as primary                                | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **24. async-subject-final** — last value on completion                  | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                          |
+| 24.1 | Recommends AsyncSubject                                                 | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 24.2 | Shows `NewAsyncSubject[T]()` constructor                                | <span class="g">✓</span>       | <span class="r">✗</span> wrong constructor              |
+| 24.3 | Explains last value only on completion                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 24.4 | Does NOT recommend BehaviorSubject                                      | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 24.5 | Does NOT recommend ReplaySubject(1)                                     | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+|      | **25. version-stability** — v0 pre-release warnings                     | **<span class="g">4/4</span>** | **<span class="r">3/4</span>**                          |
+| 25.1 | Mentions v0.x (pre-v1.0.0)                                              | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 25.2 | Warns about breaking changes                                            | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+| 25.3 | Mentions SemVer                                                         | <span class="g">✓</span>       | <span class="r">✗</span> not confident about SemVer     |
+| 25.4 | Does NOT present as fully stable                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                |
+
+</details>
+
+## `golang-uber-dig` — v1.0.0
+
+|             | With Skill         | Without Skill       | Delta     |
+| ----------- | ------------------ | ------------------- | --------- |
+| **Overall** | **20/20 (100%)**   | **18/20 (90%)**     | **+10pp** |
+
+<details>
+<summary>Full breakdown (20 assertions)</summary>
+
+**Model:** Claude Opus 4.7 | **Runs:** 4 evals × 2 configs = 8 subagents | **Grading:** human (assertion-by-assertion)
+
+> **Note:** Preliminary subset of the 11-eval suite in `skills/golang-uber-dig/evals/evals.json` (53 assertions total). The remaining 7 evals cover named values, dig.As, scopes for request-locals, DryRun graph validation, RecoverFromPanics, group flatten, and the fx-vs-dig recommendation. Re-run the full suite via `/skill-creator` for a complete report.
+
+| #    | Assertion                                                                        | With                           | Without                                          |
+| ---- | -------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------ |
+|      | **1. param-objects-many-deps** — dig.In for 4+ deps                              | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                   |
+| 1.1  | Embeds dig.In in the parameter struct                                            | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 1.2  | Constructor takes the params struct as a single argument                         | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 1.3  | Does NOT keep the long parameter list                                            | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 1.4  | Does NOT use a plain struct without dig.In                                       | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 1.5  | Mentions readability/maintainability benefit                                     | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+|      | **2. value-groups-for-handlers** — group:"routes"                                | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                   |
+| 2.1  | Each handler returns dig.Out tagged group:"routes"                               | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 2.2  | NewRouter consumes dig.In with []slice tagged group:"routes"                     | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 2.3  | Handlers added with c.Provide; no manual slice in main()                         | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 2.4  | Does NOT manually assemble the handler slice                                     | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 2.5  | Mentions group order is not guaranteed                                           | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+|      | **6. container-not-passed-around** — composition-root only                       | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                   |
+| 6.1  | Advises against passing *dig.Container into business code                        | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 6.2  | Container only at composition root (main / startup)                              | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 6.3  | UserHandler takes typed dependencies as constructor parameters                   | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 6.4  | Mentions service locator anti-pattern OR explains downside                       | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 6.5  | Does NOT show example with container injected into handler                       | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+|      | **8. decorate-not-rewrite** — Decorate vs scope-shadow Provide                   | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                   |
+| 8.1  | Uses Decorate (c.Decorate / scope.Decorate) on *zap.Logger                       | <span class="g">✓</span>       | <span class="r">✗</span> uses scope.Provide override |
+| 8.2  | Decorator returns log.Named("worker")                                            | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 8.3  | Decorate at the worker scope/module, not globally                                | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 8.4  | Does NOT modify the original NewLogger constructor                               | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 8.5  | Mentions decorator scope semantics (applies to scope and descendants)            | <span class="g">✓</span>       | <span class="r">✗</span> describes scope-override semantics instead |
+
+**Analyst pass:** evals 1, 2, and 6 score 5/5 in both configurations — they test knowledge the base model already has, hitting the "common knowledge" anti-pattern flagged in `CLAUDE.md`. Only eval 8 differentiates the skill: the without-skill agent reaches for `scope.Provide` shadowing (which would create a circular dependency at resolution time), while the skill steers to the correct `Decorate` API. Future iterations should redesign evals 1, 2, 6 to target subtler guidance and add cases the model gets wrong without the skill.
+
+</details>
+
+## `golang-uber-fx` — v1.0.0
+
+|             | With Skill         | Without Skill       | Delta     |
+| ----------- | ------------------ | ------------------- | --------- |
+| **Overall** | **21/21 (100%)**   | **20/21 (95%)**     | **+5pp**  |
+
+<details>
+<summary>Full breakdown (21 assertions)</summary>
+
+**Model:** Claude Opus 4.7 | **Runs:** 4 evals × 2 configs = 8 subagents | **Grading:** human (assertion-by-assertion)
+
+> **Note:** Preliminary subset of the 11-eval suite in `skills/golang-uber-fx/evals/evals.json` (56 assertions total). The remaining 7 evals cover fx.Annotate vs fx.Out, fx.Module organization, fx.Supply, value groups, fxevent.ZapLogger, manual lifecycle for CLI embedding, and the fx-vs-dig recommendation. Re-run the full suite via `/skill-creator` for a complete report.
+
+| #    | Assertion                                                                        | With                           | Without                                          |
+| ---- | -------------------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------ |
+|      | **1. lifecycle-not-init** — OnStart with goroutine                               | **<span class="g">6/6</span>** | **<span class="g">6/6</span>**                   |
+| 1.1  | Injects fx.Lifecycle into NewHTTPServer                                          | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 1.2  | lc.Append with fx.Hook (OnStart starts server, OnStop calls Shutdown)            | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 1.3  | OnStart launches srv.Serve in a goroutine                                        | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 1.4  | Does NOT call srv.Serve directly inside the constructor                          | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 1.5  | Does NOT use init() to start the server                                          | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 1.6  | OnStop calls srv.Shutdown(ctx) for graceful shutdown                             | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+|      | **5. fxtest-with-populate** — fxtest.New + fx.Populate                           | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                   |
+| 5.1  | Uses fxtest.New(t, ...) instead of fx.New                                        | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 5.2  | Uses fx.Populate(&svc) to extract *UserService                                   | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 5.3  | Calls app.RequireStart() and app.RequireStop()                                   | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 5.4  | Provides a fake Database (interface, not real DB)                                | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 5.5  | Does NOT use fx.Invoke as the primary extraction mechanism                       | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+|      | **6. replace-for-fakes** — fx.Replace with fx.Annotate(fx.As)                    | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                   |
+| 6.1  | Uses fx.Replace (or fx.Decorate) inside fxtest.New                               | <span class="g">✓</span>       | <span class="g">✓</span> uses fx.Decorate        |
+| 6.2  | Composes ProductionModule alongside the override; module unchanged               | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 6.3  | Uses fx.Annotate with fx.As(new(Database)) for interface binding                 | <span class="g">✓</span>       | <span class="r">✗</span> mentions but does not use |
+| 6.4  | Does NOT modify or duplicate the production module                               | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 6.5  | Mentions Replace/Decorate is appropriate for tests                               | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+|      | **10. onstart-non-blocking** — long-running work in goroutine                    | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                   |
+| 10.1 | OnStart launches the long-running method in a goroutine                          | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 10.2 | OnStart returns nil quickly without waiting                                      | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 10.3 | OnStop signals stop and waits for drain (with timeout)                           | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 10.4 | Does NOT call the long-running method synchronously in OnStart                   | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+| 10.5 | Mentions a blocking OnStart hangs the boot                                       | <span class="g">✓</span>       | <span class="g">✓</span>                         |
+
+**Analyst pass:** 3 of 4 evals score equally with and without the skill — the model's baseline knowledge of fx is very strong (lifecycle hooks, fxtest.New, OnStart/goroutine pattern). Only eval 6 differentiates: without the skill the agent picks `fx.Decorate` and skips the `fx.As` interface binding that the production graph requires. This is consistent with a well-known framework where the skill mainly adds value on subtle API choices. Future iterations should target less common patterns: fx.Annotate vs fx.Out trade-offs, fx.Module decorator scoping, fxevent customization, manual lifecycle for CLI embedding.
+
+</details>
+
+## `golang-google-wire` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **49/50 (98%)** | **41/50 (82%)** | **+16pp** |
+
+<details>
+<summary>Full breakdown (50 assertions)</summary>
+
+**Model:** Claude Sonnet 4.6 | **Runs:** 10 evals × 2 configs = 20 subagents | **Grading:** LLM-as-Judge
+
+| #    | Assertion                                                                                           | With                           | Without                                                                            |
+| ---- | --------------------------------------------------------------------------------------------------- | ------------------------------ | ---------------------------------------------------------------------------------- |
+|      | **1. build-constraint-on-injector** — missing `//go:build wireinject` causes duplicate symbols      | **<span class="g">5/5</span>** | **<span class="r">3/5</span>**                                                     |
+| 1.1  | Identifies the missing `//go:build wireinject` build tag as the root cause                         | <span class="g">✓</span>       | <span class="r">✗</span> suggested `//go:build ignore` instead                    |
+| 1.2  | Shows `//go:build wireinject` as the first line of the injector file                               | <span class="g">✓</span>       | <span class="r">✗</span> showed `//go:build ignore`                               |
+| 1.3  | Explains that the tag prevents the stub from being compiled into the binary                        | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 1.4  | Does NOT suggest renaming the function or reorganizing packages as the fix                         | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 1.5  | Does NOT suggest deleting wire_gen.go as the fix                                                   | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+|      | **2. interface-binding-required** — `wire.Bind` must be explicit; wire never auto-resolves         | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                                     |
+| 2.1  | Explains that wire never auto-resolves interface satisfaction — bindings must be explicit          | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 2.2  | Shows `wire.Bind(new(UserStore), new(*PostgresUserRepo))` added to the provider set               | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 2.3  | Places `wire.Bind` inside the same `wire.NewSet` (or adds it to a set in `wire.Build`)            | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 2.4  | Explains WHY wire requires explicit bindings (predictability — avoids surprise rebinding)          | <span class="g">✓</span>       | <span class="r">✗</span> cited ambiguity concern, not predictability rationale     |
+| 2.5  | Does NOT suggest changing `NewUserRepo` to return `UserStore` directly as the primary fix         | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+|      | **3. duplicate-type-named-wrapper** — named types disambiguate same underlying type               | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                                     |
+| 3.1  | Introduces distinct named types (e.g., `type PrimaryDSN string` and `type ReplicaDSN string`)    | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 3.2  | Updates `NewPrimaryDSN` to return `PrimaryDSN` and `NewReplicaDSN` to return `ReplicaDSN`        | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 3.3  | Updates `NewPrimaryDB` and `NewReplicaDB` signatures to accept the named types                    | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 3.4  | Explains that wire enforces one provider per type, so distinct named types are the correct fix    | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 3.5  | Does NOT suggest using a single Config struct with both DSNs as the primary fix                   | <span class="g">✓</span>       | <span class="r">✗</span> presented Config struct as co-primary recommendation      |
+|      | **4. cleanup-signature** — `(T, func(), error)` cleanup propagated through injector              | **<span class="g">5/5</span>** | **<span class="r">4/5</span>**                                                     |
+| 4.1  | Changes `NewDB` to return `(*sql.DB, func(), error)` where cleanup calls `db.Close()`            | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 4.2  | Changes the injector function to return `(*App, func(), error)` to propagate the cleanup chain   | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 4.3  | Shows main calling `defer cleanup()` after the nil-check                                          | <span class="g">✓</span>       | <span class="r">✗</span> called `defer cleanup()` directly without nil guard       |
+| 4.4  | Explains that wire chains cleanup functions in reverse construction order                         | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 4.5  | Does NOT suggest passing db as an extra return value from InitApp alongside *App                  | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+|      | **5. no-edit-wire-gen** — never edit `wire_gen.go`; re-run `wire ./...`                           | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                                     |
+| 5.1  | Explicitly says NOT to edit wire_gen.go (it is always overwritten)                               | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 5.2  | Instructs running `wire ./...` to regenerate wire_gen.go                                          | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 5.3  | Explains that `*zap.Logger` must be provided in the graph (via a provider or `wire.Value`)       | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 5.4  | Shows how to add `NewLogger` (or `wire.Value`) to the appropriate `wire.NewSet`                  | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 5.5  | Does NOT present editing wire_gen.go as an option                                                | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+|      | **6. provider-set-organization** — per-package `wire.NewSet`, not one giant set in main          | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                                     |
+| 6.1  | Introduces per-package `wire.NewSet` variables (e.g., InfraSet, RepoSet, ServiceSet)             | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 6.2  | Each set lives in its own package's wire.go file (not all in main)                               | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 6.3  | The injector `wire.Build` references the set variables rather than individual providers           | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 6.4  | `wire.Bind` declarations move into the relevant package's set (not into `wire.Build` directly)   | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 6.5  | Explains the benefit: per-package sets are independently composable                               | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+|      | **7. injector-parameter-vs-value-provider** — injector parameters vs `wire.Value` for pre-built values | **<span class="r">4/5</span>** | **<span class="g">5/5</span>**                                                |
+| 7.1  | Shows the injector-parameter approach: `func InitApp(cfg *Config) (*App, func(), error)`         | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 7.2  | OR shows `wire.Value(cfg)` inside `wire.Build` — both are valid answers                           | <span class="r">✗</span>       | <span class="g">✓</span>                                                           |
+| 7.3  | Explains that injector parameters are treated as pre-built providers by wire                     | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 7.4  | Does NOT use a global variable as the recommended solution                                        | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 7.5  | Does NOT suggest using `init()` to set the value                                                  | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+|      | **8. fields-of-struct** — `wire.FieldsOf` promotes struct fields without manual extractors        | **<span class="g">5/5</span>** | **<span class="r">1/5</span>**                                                     |
+| 8.1  | Uses `wire.FieldsOf(new(Config), "DatabaseDSN", "CacheAddress", "APIKey")` or a subset           | <span class="g">✓</span>       | <span class="r">✗</span> actively discouraged `wire.FieldsOf`                     |
+| 8.2  | Places `wire.FieldsOf` inside the provider set or `wire.Build`                                   | <span class="g">✓</span>       | <span class="r">✗</span> `wire.FieldsOf` not used                                 |
+| 8.3  | Updates `NewDB`, `NewCache`, `NewExternalClient` to accept the string fields as parameters        | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 8.4  | Explains that `wire.FieldsOf` promotes struct fields as individual graph nodes                   | <span class="g">✓</span>       | <span class="r">✗</span> dismissed rather than explained                           |
+| 8.5  | Does NOT suggest three separate extractor functions as the primary recommendation                 | <span class="g">✓</span>       | <span class="r">✗</span> `ProvideDatabaseDSN` etc. were the only recommendation    |
+|      | **9. test-injector-pattern** — test-only `wire.NewSet` with fake bindings                        | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                                     |
+| 9.1  | Creates a test-only provider set with `NewFakeMailer` and `wire.Bind(new(Mailer), new(*FakeMailer))` | <span class="g">✓</span>   | <span class="g">✓</span>                                                           |
+| 9.2  | Creates a test injector function in a `_test.go` file with `//go:build wireinject`               | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 9.3  | The test injector's `wire.Build` composes production sets with the test-only set                  | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 9.4  | Does NOT suggest global variables, monkey-patching, or a runtime DI container for tests          | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 9.5  | Mentions that `wire ./...` (or `go generate`) must be run to produce the test-injector code      | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+|      | **10. wire-vs-fx-for-daemon** — wire lacks lifecycle; recommend fx for long-running services     | **<span class="g">5/5</span>** | **<span class="g">5/5</span>**                                                     |
+| 10.1 | Identifies that wire has no built-in lifecycle management (no OnStart/OnStop hooks)              | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 10.2 | Identifies that wire has no built-in signal handling (SIGINT/SIGTERM)                            | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 10.3 | Recommends uber-go/fx (or flags it as the better fit) for a long-running HTTP daemon             | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 10.4 | Does NOT recommend wire as sufficient for a service requiring graceful shutdown                   | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+| 10.5 | Mentions that with wire the developer must implement shutdown and signal handling manually        | <span class="g">✓</span>       | <span class="g">✓</span>                                                           |
+
+**Analyst pass:** 5 of 10 evals score equally with and without the skill — evals 5, 6, 9, 10 reflect strong model priors for well-known wire patterns (never-edit wire_gen.go, per-package sets, test injectors, fx-vs-wire comparison). The clearest skill uplift is eval 8 (`wire.FieldsOf`): without the skill, the model actively discourages `wire.FieldsOf` and recommends manual extractor functions instead. Eval 1 also differentiates: without the skill, the model suggests `//go:build ignore` rather than the correct `//go:build wireinject` tag. Eval 7 produced a false negative for the with-skill run — the skill correctly notes `wire.Value` only accepts constant expressions and rejected it for a runtime-parsed config; this is technically correct behavior but the assertion accepts both forms as valid. Future iterations should redesign assertion 7.2 to credit the correct injector-parameter approach when `wire.Value` is rightly excluded.
+
+</details>
+
+## `golang-spf13-cobra` — v1.0.0
+
+|             | With Skill       | Without Skill    | Delta    |
+| ----------- | ---------------- | ---------------- | -------- |
+| **Overall** | **50/50 (100%)** | **49/50 (98%)**  | **+2pp** |
+
+<details>
+<summary>Full breakdown (50 assertions)</summary>
+
+**Model:** Claude Sonnet 4.6 | **Runs:** 12 evals × 2 configs = 24 self-graded evaluations | **Grading:** self-graded (⚠️ biased — model sees assertions in prompt; without-skill baseline inflated; human-as-judge evaluation recommended for accurate uplift)
+
+| #    | Assertion                                                                   | With                           | Without                        |
+| ---- | --------------------------------------------------------------------------- | ------------------------------ | ------------------------------ |
+|      | **1. rune-vs-run** — RunE vs Run, defer bypass                              | **<span class="g">5/5</span>** | **<span class="g">5/5</span>** |
+| 1.1  | Identifies that Run cannot return an error                                  | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 1.2  | Explains only escape from Run is os.Exit or panic, bypassing defers         | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 1.3  | Recommends switching to RunE                                                | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 1.4  | Shows RunE signature: func(cmd *cobra.Command, args []string) error         | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 1.5  | Does NOT suggest goroutine or recover() as the fix                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **2. args-validator** — len(args) in RunE vs Args field                     | **<span class="g">4/4</span>** | **<span class="r">3/4</span>** |
+| 2.1  | Recommends cobra.ExactArgs(1) in the Args field                             | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 2.2  | Shows the Args field on cobra.Command, not inside RunE                      | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 2.3  | Explains cobra generates standard error messages automatically              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 2.4  | Does NOT suggest keeping the len(args) check inside RunE                    | <span class="g">✓</span>       | <span class="r">✗</span>       |
+|      | **3. outstdout** — cmd.OutOrStdout vs os.Stdout                             | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 3.1  | Identifies os.Stdout (via fmt.Println) as root cause — can't redirect       | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 3.2  | Recommends cmd.OutOrStdout() as the io.Writer for output                    | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 3.3  | Shows cmd.SetOut(buf) in test setup to redirect output                      | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 3.4  | Does NOT suggest using os.Pipe() as the fix                                 | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **4. persistentprerun-chain** — PersistentPreRunE replacement not chaining  | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 4.1  | Explains cobra does NOT chain PersistentPreRunE — child replaces parent     | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 4.2  | Recommends explicitly calling parent's PersistentPreRunE from child         | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 4.3  | Shows calling parent hook: rootCmd.PersistentPreRunE(cmd, args)             | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 4.4  | Does NOT suggest using PreRunE instead as the fix                           | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **5. silenceusage** — SilenceUsage and SilenceErrors configuration          | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 5.1  | Recommends SilenceUsage: true on the root command                           | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 5.2  | Recommends SilenceErrors: true if app prints errors itself                  | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 5.3  | Explains SilenceUsage prevents full usage wall on every error               | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 5.4  | Shows setting fields on root cobra.Command struct                           | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **6. addgroup-ordering** — AddGroup before AddCommand                       | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 6.1  | Identifies root cause: AddGroup must be called BEFORE AddCommand            | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 6.2  | Explains cobra does not retroactively assign groups                         | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 6.3  | Shows correct order: AddGroup, GroupID, AddCommand                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 6.4  | Does NOT suggest AddCommand before AddGroup as workaround                   | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **7. validargsfunction** — dynamic positional arg completion                | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 7.1  | Uses ValidArgsFunction (not just ValidArgs []string)                        | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 7.2  | Shows correct signature with args and toComplete parameters                 | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 7.3  | Returns ShellCompDirectiveNoFileComp to suppress file fallback              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 7.4  | Does NOT suggest parsing shell completion scripts manually                  | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **8. registerflagcompletionfunc** — flag value completion                   | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 8.1  | Uses RegisterFlagCompletionFunc (not ValidArgs on the command)              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 8.2  | Shows function registered for the specific flag name "format"               | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 8.3  | Returns the static list ["json", "yaml", "table"]                           | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 8.4  | Does NOT suggest modifying shell rc files or completion scripts             | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **9. test-isolation** — fresh command tree per test                         | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 9.1  | Identifies cobra accumulates flag state across Execute() calls              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 9.2  | Recommends building a fresh command tree per test                           | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 9.3  | Suggests factory function (e.g. newRootCmd()) for fresh trees               | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 9.4  | Does NOT recommend -count=1 as the primary fix                              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **10. matchall** — composing cobra validators                               | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 10.1 | Uses cobra.MatchAll() to compose validators                                 | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 10.2 | Shows cobra.MatchAll(cobra.ExactArgs(2), cobra.OnlyValidArgs)               | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 10.3 | Sets ValidArgs on the command for OnlyValidArgs to work                     | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 10.4 | Does NOT suggest custom validator duplicating ExactArgs logic               | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **11. cobra-vs-viper** — cobra does not handle config files                 | **<span class="g">5/5</span>** | **<span class="g">5/5</span>** |
+| 11.1 | Clearly states cobra does NOT handle config file parsing                    | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 11.2 | Recommends viper (spf13/viper) for config file support                      | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 11.3 | Explains cobra handles command tree/flags, viper handles config resolution  | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 11.4 | Mentions BindPFlag as the integration point between cobra and viper         | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 11.5 | Does NOT suggest cobra alone is sufficient for YAML/JSON config files       | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **12. cobra-cli-scaffolder** — cobra-cli scaffolding tool                   | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 12.1 | Mentions cobra-cli as the scaffolding tool                                  | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 12.2 | Shows cobra-cli init or cobra-cli add commands                              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 12.3 | Explains cobra-cli generates command boilerplate                            | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 12.4 | Does NOT suggest writing boilerplate from scratch as the only option        | <span class="g">✓</span>       | <span class="g">✓</span>       |
+
+**Analyst pass:** Almost all 12 evals score equally with and without the skill because the model's baseline cobra knowledge is strong — RunE, Args validators, OutOrStdout, SilenceUsage, and completions are well-documented. The only differentiating eval is 2.4 (explicitly discouraging len(args) checks in RunE as a backup). The self-grading methodology inflates the without-skill baseline — a human-as-judge rerun is recommended to measure true uplift, particularly on the subtler evals (4: PersistentPreRunE non-chaining, 6: AddGroup ordering, 9: test isolation with factory function).
+
+</details>
+
+## `golang-spf13-viper` — v1.0.0
+
+|             | With Skill       | Without Skill    | Delta    |
+| ----------- | ---------------- | ---------------- | -------- |
+| **Overall** | **52/53 (98%)**  | **53/53 (100%)** | **-2pp** |
+
+<details>
+<summary>Full breakdown (53 assertions)</summary>
+
+**Model:** Claude Sonnet 4.6 | **Runs:** 12 evals × 2 configs = 24 self-graded evaluations | **Grading:** self-graded (⚠️ biased — model sees assertions in prompt; without-skill baseline inflated; human-as-judge evaluation recommended for accurate uplift. Negative delta on eval 8.5: with-skill model mentions GetDuration as alternative, which fails the "Does NOT suggest" assertion; without-skill model omits it, which passes.)
+
+| #    | Assertion                                                                         | With                           | Without                        |
+| ---- | --------------------------------------------------------------------------------- | ------------------------------ | ------------------------------ |
+|      | **1. env-key-replacer-nested-keys** — SetEnvKeyReplacer for nested keys           | **<span class="g">5/5</span>** | **<span class="g">5/5</span>** |
+| 1.1  | Identifies the root cause as missing SetEnvKeyReplacer                            | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 1.2  | Explains viper preserves the dot in 'database.host' when looking up env var       | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 1.3  | Provides the fix: viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 1.4  | Shows full setup requires prefix + replacer + AutomaticEnv together               | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 1.5  | Does NOT suggest renaming the config key to avoid dots                            | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **2. sub-returns-nil** — viper.Sub() returns nil for missing keys                 | **<span class="g">5/5</span>** | **<span class="g">5/5</span>** |
+| 2.1  | Identifies that viper.Sub() returns nil when the key doesn't exist                | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 2.2  | Shows nil check: if sub := viper.Sub("database"); sub != nil { ... }              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 2.3  | Suggests returning error or using defaults when sub is nil                        | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 2.4  | Does NOT suggest checking err from Sub() (returns no error, only nil)             | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 2.5  | Optionally suggests UnmarshalKey("database", &dbCfg) as an alternative           | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **3. config-file-not-found-graceful** — ConfigFileNotFoundError handling          | **<span class="g">5/5</span>** | **<span class="g">5/5</span>** |
+| 3.1  | Uses errors.As(err, &notFound) with *viper.ConfigFileNotFoundError                | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 3.2  | Only propagates errors that are NOT ConfigFileNotFoundError                       | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 3.3  | Continues execution normally when config file is not found                        | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 3.4  | Does NOT use os.Stat or file existence check as the solution                      | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 3.5  | Does NOT ignore all errors from ReadInConfig (real errors still propagate)        | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **4. global-viper-test-pollution** — viper.New() for test isolation               | **<span class="g">5/5</span>** | **<span class="g">5/5</span>** |
+| 4.1  | Identifies root cause as shared global viper state across tests                   | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 4.2  | Recommends viper.New() per test for isolated instance                             | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 4.3  | Shows v := viper.New() with v.SetConfigFile, v.ReadInConfig, etc.                 | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 4.4  | Does NOT recommend viper.Reset() as the primary solution                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 4.5  | Explains why tests are order-dependent (state persists to next test)              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **5. unmarshal-mapstructure-tags** — mapstructure struct tags required            | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 5.1  | Identifies missing mapstructure struct tag as the root cause                      | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 5.2  | Shows adding `mapstructure:"max_conn"` to the MaxConn field                       | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 5.3  | Explains mapstructure does case-insensitive matching but not underscore-camelcase | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 5.4  | Does NOT suggest using viper.GetInt as the fix                                    | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **6. bind-pflag-timing** — BindPFlag must be before Execute()                     | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 6.1  | Identifies BindPFlag must be called before Execute() / before RunE runs           | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 6.2  | Recommends moving BindPFlag to init() or PersistentPreRunE                        | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 6.3  | Explains cobra parses flags before RunE — binding after misses Changed state      | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 6.4  | Shows correct pattern: define flag + BindPFlag in init()                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **7. viper-key-case-insensitivity** — viper keys always lowercase                 | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 7.1  | Explains viper normalizes all keys to lowercase internally                        | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 7.2  | Recommends using lowercase keys consistently in viper.Get* calls                  | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 7.3  | Identifies viper.GetString("database_host") as the correct form                   | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 7.4  | Notes DATABASE_HOST works via lowercasing but is a source of confusion            | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **8. duration-decode-hook** — StringToTimeDurationHookFunc for time.Duration      | **<span class="r">4/5</span>** | **<span class="g">5/5</span>** |
+| 8.1  | Identifies mapstructure cannot decode duration string without a hook              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 8.2  | Shows viper.Unmarshal with DecodeHook using StringToTimeDurationHookFunc          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 8.3  | Uses mapstructure.StringToTimeDurationHookFunc() as part of the hook              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 8.4  | Does NOT suggest changing config value to nanoseconds                             | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 8.5  | Does NOT suggest using viper.GetDuration as a workaround                          | <span class="r">✗</span>       | <span class="g">✓</span>       |
+|      | **9. watch-config-atomic-rename-trap** — fsnotify inode replacement by editors    | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 9.1  | Explains vim writes atomically via rename (write-to-temp, then rename)            | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 9.2  | Explains fsnotify watches inode, replaced by rename-based writes                  | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 9.3  | Recommends testing with direct writes (os.WriteFile or echo >>) not editor saves  | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 9.4  | Does NOT suggest downgrading vim or switching editors as the fix                  | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **10. viper-alone-no-cobra** — viper usable without cobra                         | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 10.1 | Clearly states viper can be used without cobra                                    | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 10.2 | Explains cobra is for command trees/flags, not needed for HTTP service            | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 10.3 | Shows viper setup without any cobra imports                                       | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 10.4 | Does NOT recommend adding cobra just for configuration purposes                   | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **11. unmarshal-key-vs-sub** — UnmarshalKey vs Sub+Unmarshal                      | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 11.1 | Recommends viper.UnmarshalKey("database", &dbCfg) as the simpler alternative     | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 11.2 | Explains it avoids the nil check required with Sub()                              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 11.3 | Shows correct usage: viper.UnmarshalKey("database", &dbCfg)                      | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 11.4 | If mentioning Sub+Unmarshal, notes the nil risk                                   | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **12. allow-empty-env** — AllowEmptyEnv for empty string env vars                 | **<span class="g">4/4</span>** | **<span class="g">4/4</span>** |
+| 12.1 | Explains viper treats empty string env vars as 'not set' by default               | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 12.2 | Introduces viper.AllowEmptyEnv(true) as the fix                                   | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 12.3 | Explains with AllowEmptyEnv(true), empty env var overrides config file value      | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 12.4 | Does NOT suggest using viper.Set() as a workaround                                | <span class="g">✓</span>       | <span class="g">✓</span>       |
+
+**Analyst pass:** All 12 evals score equally or better without the skill because the model's baseline viper knowledge is strong — ConfigFileNotFoundError, viper.New() for tests, mapstructure tags, and UnmarshalKey are all well-documented. The single differentiating point is eval 8.5 (negative): the skill makes the model mention viper.GetDuration as an alternative, which fails the "Does NOT suggest" assertion. The skill's reference to the unmarshal section may be over-helpful on this eval. The self-grading methodology inflates the without-skill baseline throughout. A human-as-judge rerun is recommended targeting evals 1 (env key replacer — the subtlest viper gotcha), 8 (decode hook), and 12 (AllowEmptyEnv — lesser-known API).
+
+</details>
+
+## `golang-swagger` — v1.0.0
+
+|             | With Skill      | Without Skill   | Delta     |
+| ----------- | --------------- | --------------- | --------- |
+| **Overall** | **58/60 (97%)** | **43/60 (72%)** | **+25pp** |
+
+<details>
+<summary>Full breakdown (60 assertions)</summary>
+
+**Model:** Claude Sonnet 4.6 | **Runs:** 12 evals × 2 configs = 24 subagents | **Grading:** Human-as-judge
+
+| #    | Assertion                                                                                               | With                           | Without                        |
+| ---- | ------------------------------------------------------------------------------------------------------- | ------------------------------ | ------------------------------ |
+|      | **1. gin-blank-import** — blank import + ginSwagger wire-up                                             | **<span class="g">5/5</span>** | **<span class="r">4/5</span>** |
+| 1.1  | Adds a blank import of the docs package (e.g., `_ "<module>/docs"`)                                    | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 1.2  | Imports github.com/swaggo/gin-swagger                                                                   | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 1.3  | Imports github.com/swaggo/files                                                                         | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 1.4  | Registers a GET route matching /swagger/*any using ginSwagger.WrapHandler                               | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 1.5  | Does not suggest running swag init again (it was already done)                                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **2. map-response-type** — map[string]bool cannot be used directly in @Success                          | **<span class="g">5/5</span>** | **<span class="r">3/5</span>** |
+| 2.1  | Does NOT use `{object} map[string]bool` directly in @Success                                           | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 2.2  | Defines a named struct for the response OR acknowledges a swaggertype workaround is needed              | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 2.3  | @Success annotation uses a named type (not a raw map literal)                                           | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 2.4  | @Router annotation is present with [get] method                                                         | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 2.5  | @Produce annotation specifies json                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **3. swaggertype-overrides** — time.Time and []byte need swaggertype tags                               | **<span class="g">5/5</span>** | **<span class="r">1/5</span>** |
+| 3.1  | Adds swaggertype tag to CreatedAt field                                                                 | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 3.2  | Adds swaggertype tag to UpdatedAt field with the same treatment                                         | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 3.3  | Adds swaggertype:"string" and format:"base64" to the Payload []byte field                               | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 3.4  | Preserves the json tags (does not remove them)                                                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 3.5  | Does not leave time.Time fields without any swaggertype override                                        | <span class="g">✓</span>       | <span class="r">✗</span>       |
+|      | **4. chi-dynamic-basepath** — Chi router + BasePath from env var                                        | **<span class="g">5/5</span>** | **<span class="g">5/5</span>** |
+| 4.1  | Imports github.com/swaggo/http-swagger                                                                  | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 4.2  | Uses r.Get (chi method) to register the swagger route with a wildcard pattern                           | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 4.3  | Sets docs.SwaggerInfo.BasePath using os.Getenv("API_BASE_PATH") or equivalent                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 4.4  | Includes the blank docs import                                                                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 4.5  | Does not suggest rebuilding or running swag init per environment                                        | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **5. and-security-condition** — && vs two separate @Security lines                                      | **<span class="g">5/5</span>** | **<span class="r">4/5</span>** |
+| 5.1  | Uses && between security schemes on a single @Security annotation line                                  | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 5.2  | Does NOT write two separate @Security lines for AND semantics                                           | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 5.3  | References valid security definition names (ApiKeyAuth, BasicAuth, or similar)                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 5.4  | Explains or implies that two separate @Security lines would mean OR, not AND                            | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 5.5  | @Security line appears inside the handler doc comment block                                             | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **6. tag-exclusion** — swag init --tags with ! prefix to exclude tags                                   | **<span class="g">5/5</span>** | **<span class="r">4/5</span>** |
+| 6.1  | Uses the --tags flag (or -t) with swag init                                                             | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 6.2  | Uses ! prefix to exclude tags (e.g., --tags '!Internal,!Admin' or similar)                              | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 6.3  | Shows a complete swag init command                                                                      | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 6.4  | Does not suggest manually editing the generated swagger.json                                            | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 6.5  | Does not require writing custom Go code to filter endpoints                                             | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **7. godoc-comment-swag-fmt** — godoc comment line required for swag fmt                                | **<span class="g">5/5</span>** | **<span class="r">4/5</span>** |
+| 7.1  | Adds `// CreateOrder godoc` as the first line of the comment block                                     | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 7.2  | godoc comment appears before any @ annotation                                                           | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 7.3  | At minimum includes @Summary, @Router annotations                                                       | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 7.4  | @Router specifies both path and HTTP method                                                             | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 7.5  | Annotation block is placed directly above the function signature                                        | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **8. csv-vs-multi** — collectionFormat(multi) for ids, collectionFormat(csv) for fields                 | **<span class="r">4/5</span>** | **<span class="r">2/5</span>** |
+| 8.1  | @Param for ids uses collectionFormat(multi)                                                             | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 8.2  | @Param for fields uses collectionFormat(csv) or omits it (csv is the default)                           | <span class="r">✗</span>       | <span class="r">✗</span>       |
+| 8.3  | Both params use []string or []int as data type                                                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 8.4  | Both params are marked as not required (false)                                                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 8.5  | @Router annotation is present with [get] method                                                         | <span class="g">✓</span>       | <span class="r">✗</span>       |
+|      | **9. conditional-swagger** — env-based swagger toggle without build tags                                | **<span class="g">5/5</span>** | **<span class="g">5/5</span>** |
+| 9.1  | Uses os.Getenv (or equivalent) to read APP_ENV at runtime                                               | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 9.2  | Conditionally registers the swagger route only when not in production                                   | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 9.3  | Does not require separate builds or build tags                                                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 9.4  | The blank docs import is still present (or acknowledged as needed)                                      | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 9.5  | Solution works without recompiling between environments                                                 | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **10. nested-composition** — Envelope{data=model.User} nested composition syntax                        | **<span class="g">5/5</span>** | **<span class="r">3/5</span>** |
+| 10.1 | @Success annotation uses nested composition syntax with curly braces (e.g., Envelope{data=model.User}) | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 10.2 | The inner type is the User struct (or equivalent named type)                                            | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 10.3 | Does not create a new wrapper struct just for documentation purposes                                    | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 10.4 | @Param for the id path parameter is present with path location                                          | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 10.5 | @Router specifies the correct path and [get] method                                                     | <span class="g">✓</span>       | <span class="r">✗</span>       |
+|      | **11. enums-min-max-tags** — enums/minimum/maximum struct tags                                          | **<span class="r">4/5</span>** | **<span class="r">4/5</span>** |
+| 11.1 | Adds `enums:"admin,editor,viewer"` struct tag to Role field                                            | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 11.2 | Adds `minimum:"0"` and `maximum:"100"` struct tags to Score field                                     | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 11.3 | Adds json tags to all fields                                                                            | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 11.4 | Adds example tags to at least one field                                                                 | <span class="r">✗</span>       | <span class="r">✗</span>       |
+| 11.5 | Does not only describe constraints in a comment — they must be machine-readable struct tags              | <span class="g">✓</span>       | <span class="g">✓</span>       |
+|      | **12. swaggerignore-serialization** — swaggerignore:"true" vs json:"-"                                 | **<span class="g">5/5</span>** | **<span class="r">4/5</span>** |
+| 12.1 | Uses swaggerignore:"true" on the LastModified field                                                     | <span class="g">✓</span>       | <span class="r">✗</span>       |
+| 12.2 | Keeps a valid json tag on LastModified (NOT json:"-")                                                   | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 12.3 | Does NOT suggest removing the field from the struct                                                     | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 12.4 | Other struct fields retain their json and swagger documentation                                         | <span class="g">✓</span>       | <span class="g">✓</span>       |
+| 12.5 | Explains or implies why json:"-" would be wrong here (breaks serialization)                             | <span class="g">✓</span>       | <span class="g">✓</span>       |
+
+**Analyst pass:** The skill shows clear uplift on annotation mechanics that require knowing non-obvious swag behaviors: blank import requirement (eval 1), map type limitations (eval 2), swaggertype overrides for time.Time and []byte (eval 3), nested composition syntax (eval 10), and swaggerignore vs json:"-" (eval 12). Evals 4 (Chi+env) and 9 (conditional toggle) scored 5/5 in both conditions — the model already knows how to read env vars and register Chi routes, so these evals test common knowledge rather than skill uplift. Eval 11 shows a consistent miss on the `example:` struct tag in both conditions, indicating a coverage gap rather than discrimination; the skill should add an explicit example on `example:` struct tag usage. Future iterations should also target less-known swag behaviors: `@extensions`, `@x-` custom properties, multi-file init patterns (`--dir` flag), and OpenAPI 3.0 output.
+
+</details>
+
+<!-- prettier-ignore-end -->
diff --git a/packages/autoskills/skills-registry/samber-go-skills/GOLANG-AI-DRIVEN-REVIEW.md b/packages/autoskills/skills-registry/samber-go-skills/GOLANG-AI-DRIVEN-REVIEW.md
new file mode 100644
index 00000000..a600c5bf
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/GOLANG-AI-DRIVEN-REVIEW.md
@@ -0,0 +1,524 @@
+# 🕵 AI-Driven Code Review in CI
+
+Add AI agents as PR reviewers alongside traditional static analysis. When configured with this skill plugin, the agent applies the relevant Go skills per review area — catching architectural drift, logic bugs, and concurrency hazards that linters cannot detect.
+
+**Contents:**
+
+- [Claude Code Action](#claude-code-action)
+- [GitHub Copilot](#github-copilot)
+- [Cost and tuning](#cost-and-tuning)
+
+---
+
+## Claude Code Action
+
+Run `/install-github-app` in Claude Code to install the GitHub app and connect to the Claude API. Then create `.github/workflows/ai-code-review.yml`:
+
+````yaml
+name: AI Code Review (Claude)
+
+on:
+  pull_request:
+    types: [opened, synchronize, reopened, ready_for_review]
+  pull_request_review_comment:
+    types: [created]
+  pull_request_review:
+    types: [submitted]
+
+# Security note: these permissions apply to the entire repository, not just the current PR.
+# `pull-requests: write` allows the workflow to post, edit, and resolve comments on ANY pull request.
+# `actions: read` allows reading logs from ANY workflow run, which may contain sensitive output.
+# Scope risk by restricting the trigger to PRs from trusted contributors or protected branches,
+# and by never logging secrets in CI steps.
+permissions:
+  contents: read
+  issues: read
+  pull-requests: write
+  actions: read
+  id-token: write
+
+concurrency:
+  group: claude-review-${{ github.event.pull_request.number || github.event.issue.number }}-${{ github.event_name }}
+  cancel-in-progress: true
+
+jobs:
+  # ── Job 1: Code quality (suggestion-first) ──────────────────────────────────
+  # Covers: style, naming, documentation
+  quality:
+    name: Review — Quality
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    # Skip bot PRs (Dependabot, Renovate, etc.)
+    # Remove this filter if you want bots to get reviewed.
+    if: ${{ github.event_name == 'pull_request' && !endsWith(github.event.pull_request.user.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Install Go skills
+        run: npx skills add https://github.com/samber/cc-skills-golang -a claude-code --skill '*' -y --copy
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: true
+          track_progress: true
+          sticky_comment_header: "<!-- claude-review-quality -->"
+          additional_permissions: |
+            actions: read
+          claude_args: >-
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,mcp__context7__resolve-library-id,mcp__context7__query-docs,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
+
+
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+            AUTHOR: ${{ github.event.pull_request.user.login }}
+
+            You are a senior Go engineer performing a focused code quality review.
+
+            Review this pull request.
+            - Use `gh pr diff` to read the diff.
+            - Use `gh pr view` to read description and metadata.
+            - Use `mcp__github_inline_comment__create_inline_comment` with `confirmed: true`
+              for every line-specific issue. Include a ```suggestion block when the fix is
+              a direct 1:1 replacement of the selected lines.
+            - Use `gh pr comment` only for a top-level summary.
+            - Post nothing else. No chat output.
+
+            ## Scope — apply these skill guidelines
+
+            - **Code style** — formatting, comment quality, idiomatic Go patterns (Skill("golang-code-style")).
+            - **Naming** — packages, types, variables, functions, constants (Skill("golang-naming")).
+            - **Documentation** — exported symbols, package-level docs, README impact (Skill("golang-documentation")).
+
+            ## Priority — suggestion-first
+
+            These areas reflect style and readability, not correctness. Only raise an issue when it will
+            confuse future readers, mislead consumers of an exported API, or make the codebase harder to
+            navigate at scale. Do not flag formatting that `gofmt` handles automatically.
+
+            ## How to report
+
+            Every comment must:
+            1. Name the specific problem (not just its symptom)
+            2. Explain under what conditions it matters or fails
+            3. Provide a concrete fix — renamed identifier, corrected code snippet, or safer pattern
+
+            Write short, concise comments. Only comment when there is a specific issue. Do not praise
+            the good stuff. Before posting, verify the point was not already raised in a previous
+            review comment.
+
+            Note: the PR branch is already checked out in the current working directory.
+
+            Check project guidelines: @./CLAUDE.md
+            Check contributing guidelines: @./CONTRIBUTING.md
+
+            Label each comment: 🟡 **SUGGESTION**
+
+  # ── Job 2: Correctness (blocking-first) ─────────────────────────────────────
+  # Covers: error handling, code safety, concurrency
+  correctness:
+    name: Review — Correctness
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    if: ${{ github.event_name == 'pull_request' && !endsWith(github.event.pull_request.user.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Install Go skills
+        run: npx skills add https://github.com/samber/cc-skills-golang -a claude-code --skill '*' -y --copy
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: true
+          track_progress: true
+          sticky_comment_header: "<!-- claude-review-correctness -->"
+          additional_permissions: |
+            actions: read
+          claude_args: >-
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,mcp__context7__resolve-library-id,mcp__context7__query-docs,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
+
+
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+            AUTHOR: ${{ github.event.pull_request.user.login }}
+
+            You are a senior Go engineer performing a focused correctness and safety review.
+
+            Review this pull request.
+            - Use `gh pr diff` to read the diff.
+            - Use `gh pr view` to read description and metadata.
+            - Use `mcp__github_inline_comment__create_inline_comment` with `confirmed: true`
+              for every line-specific issue. Include a ```suggestion block when the fix is
+              a direct 1:1 replacement of the selected lines.
+            - Use `gh pr comment` only for a top-level summary.
+            - Post nothing else. No chat output.
+
+            ## Scope — apply these skill guidelines
+
+            - **Error handling** — wrapping, sentinel errors, log-and-return, swallowed errors (Skill("golang-error-handling")).
+            - **Code safety** — nil dereference, map/slice aliasing, integer overflows, uninitialized state (Skill("golang-safety")).
+            - **Concurrency** — goroutine lifecycle, mutex usage, channel patterns, context propagation, data races (Skill("golang-concurrency")).
+
+            ## Priority — blocking-first
+
+            A swallowed error, an unchecked nil, or an unsynchronized write can cause silent data corruption
+            or production incidents — flag these even when the fix is non-trivial.
+
+            ## How to report
+
+            Every comment must:
+            1. Name the specific problem (not just its symptom)
+            2. Explain under what conditions it matters or fails
+            3. Provide a concrete fix — corrected code snippet or safer pattern
+
+            Write short, concise comments. Only comment when there is a specific issue. Do not praise
+            the good stuff. Before posting, verify the point was not already raised.
+
+            Note: the PR branch is already checked out in the current working directory.
+
+            Check project guidelines: @./CLAUDE.md
+            Check contributing guidelines: @./CONTRIBUTING.md
+
+            Label each comment with its severity:
+            - 🔴 **BLOCKING** — definite bug, data race, or correctness failure; must be fixed before merge.
+            - 🟠 **IMPORTANT** — significant risk that requires unusual conditions to manifest.
+            - 🟡 **SUGGESTION** — defensive improvement with low-probability failure mode.
+
+  # ── Job 3: Security & dependencies (blocking-first) ─────────────────────────
+  # Covers: security, dependency health
+  security:
+    name: Review — Security & Dependencies
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    if: ${{ github.event_name == 'pull_request' && !endsWith(github.event.pull_request.user.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Install Go skills
+        run: npx skills add https://github.com/samber/cc-skills-golang -a claude-code --skill '*' -y --copy
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: true
+          track_progress: true
+          sticky_comment_header: "<!-- claude-review-security -->"
+          additional_permissions: |
+            actions: read
+          claude_args: >-
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,mcp__context7__resolve-library-id,mcp__context7__query-docs,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
+
+
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+            AUTHOR: ${{ github.event.pull_request.user.login }}
+
+            You are a senior Go security engineer performing a focused security and dependency review.
+
+            Review this pull request.
+            - Use `gh pr diff` to read the diff.
+            - Use `gh pr view` to read description and metadata.
+            - Use `mcp__github_inline_comment__create_inline_comment` with `confirmed: true`
+              for every line-specific issue. Include a ```suggestion block when the fix is
+              a direct 1:1 replacement of the selected lines.
+            - Use `gh pr comment` only for a top-level summary.
+            - Post nothing else. No chat output.
+
+            ## Scope — apply these skill guidelines
+
+            - **Security** — injection, auth, crypto misuse, sensitive data exposure, input validation (Skill("golang-security")).
+            - **Dependencies** — new imports, CVE history, abandoned packages, `replace` directives (Skill("golang-dependency-management")).
+
+            ## Priority — blocking-first
+
+            Security issues and supply-chain risks must be flagged before style or quality concerns.
+            A single unvalidated input or a weak PRNG can open a critical vulnerability.
+
+            ## How to report
+
+            Every comment must:
+            1. Name the vulnerability class (SQL injection, path traversal, weak randomness, etc.)
+            2. Explain the attack vector and realistic impact
+            3. Provide a concrete, safe alternative
+
+            Write short, concise comments. Only comment when there is a specific issue. Do not praise
+            the good stuff. Before posting, verify the point was not already raised.
+
+            Note: the PR branch is already checked out in the current working directory.
+
+            Check project guidelines: @./CLAUDE.md
+            Check contributing guidelines: @./CONTRIBUTING.md
+
+            Label each comment with its severity:
+            - 🔴 **BLOCKING** — exploitable vulnerability or high-risk dependency; must be fixed before merge.
+            - 🟠 **IMPORTANT** — significant risk that requires specific conditions.
+            - 🟡 **SUGGESTION** — defense-in-depth improvement; optional but worthwhile.
+
+  # ── Job 4: Tests, performance, observability & modernization ─────────────────
+  # Covers: tests, performance, observability, modernize
+  quality-depth:
+    name: Review — Tests, Performance & Observability
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    if: ${{ github.event_name == 'pull_request' && !endsWith(github.event.pull_request.user.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Install Go skills
+        run: npx skills add https://github.com/samber/cc-skills-golang -a claude-code --skill '*' -y --copy
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: true
+          track_progress: true
+          sticky_comment_header: "<!-- claude-review-quality-depth -->"
+          additional_permissions: |
+            actions: read
+          claude_args: >-
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,mcp__context7__resolve-library-id,mcp__context7__query-docs,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
+
+
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+            AUTHOR: ${{ github.event.pull_request.user.login }}
+
+            You are a senior Go engineer reviewing for test coverage, performance, observability,
+            and code modernization.
+
+            Review this pull request.
+            - Use `gh pr diff` to read the diff.
+            - Use `gh pr view` to read description and metadata.
+            - Use `mcp__github_inline_comment__create_inline_comment` with `confirmed: true`
+              for every line-specific issue. Include a ```suggestion block when the fix is
+              a direct 1:1 replacement of the selected lines.
+            - Use `gh pr comment` only for a top-level summary.
+            - Post nothing else. No chat output.
+
+            ## Scope — apply these skill guidelines
+
+            - **Tests** — coverage of new code, test quality, table-driven tests, use of t.Helper() (Skill("golang-testing")).
+            - **Performance** — unnecessary allocations, inefficient data structures, missing bounds (Skill("golang-performance")).
+            - **Observability** — logging, metrics, tracing added for new code paths (Skill("golang-observability")).
+            - **Modernize code** — outdated patterns replaced with Go 1.21+ idioms (Skill("golang-modernize")).
+
+            ## Priority
+
+            - **Tests** and **Performance** are important — flag missing coverage on new exported paths
+              and obvious allocation hot-spots on critical paths.
+            - **Observability** and **Modernize** are suggestion-first — raise only when the gap is
+              material or the pattern is clearly outdated.
+
+            ## How to report
+
+            Every comment must:
+            1. Name the specific problem (not just its symptom)
+            2. Explain why it matters (undetected regression, latency impact, etc.)
+            3. Provide a concrete fix or example
+
+            Write short, concise comments. Only comment when there is a specific issue. Do not praise
+            the good stuff. Before posting, verify the point was not already raised.
+
+            Note: the PR branch is already checked out in the current working directory.
+
+            Check project guidelines: @./CLAUDE.md
+            Check contributing guidelines: @./CONTRIBUTING.md
+
+            Label each comment with its severity:
+            - 🟠 **IMPORTANT** — missing test for a critical exported path; allocation hot-spot on a
+              latency-sensitive path.
+            - 🟡 **SUGGESTION** — observability gap, modernization opportunity, minor test improvement.
+
+  # ── Job 5: CI failure diagnosis ──────────────────────────────────────────────
+  # Waits for all review jobs, then diagnoses any failures and posts a fix summary.
+  ci-diagnosis:
+    name: Review — CI Failure Diagnosis
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    needs: [quality, correctness, security, quality-depth]
+    if: ${{ always() && github.event_name == 'pull_request' && !endsWith(github.event.pull_request.user.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: true
+          track_progress: true
+          sticky_comment_header: "<!-- claude-review-ci-diagnosis -->"
+          additional_permissions: |
+            actions: read
+          claude_args: >-
+            --allowedTools "Bash(gh pr comment:*),Bash(gh pr view:*),Bash(gh run view:*),Bash(gh run list:*)"
+
+
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+            WORKFLOW RUN ID: ${{ github.run_id }}
+
+            You are a senior Go engineer diagnosing CI failures on a pull request.
+
+            Check whether any of the parallel review jobs (quality, correctness, security, quality-depth)
+            failed in this workflow run. If all jobs succeeded, post nothing and exit.
+
+            If any job failed:
+            - Use `gh run view` to inspect the failed job logs and identify the root cause.
+            - Post a single `gh pr comment` summarizing:
+              1. Which job(s) failed and why (log excerpt).
+              2. Concrete steps to fix the failure (configuration change, missing secret, infra issue).
+            - Post nothing else. No chat output.
+
+  # ── Job 6: Discuss review comments ──────────────────────────────────────────
+  # Triggered when a human posts a review comment. Replies only when warranted.
+  discuss:
+    name: Review — Discuss
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    if: ${{ (github.event_name == 'pull_request_review_comment' || github.event_name == 'pull_request_review') && !endsWith(github.event.sender.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: false
+          track_progress: false
+          claude_args: >-
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr view:*),Bash(gh pr diff:*)"
+
+
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+
+            You are a senior Go engineer participating in a code review discussion.
+
+            A human just posted a review comment or submitted a review on this PR.
+            Read the comment thread and decide whether to reply.
+
+            Reply ONLY if:
+            - The comment contains a factual mistake about Go semantics, stdlib, or a package.
+            - The proposed change would introduce a bug, performance regression, or security issue.
+            - A brief clarification would unblock the discussion.
+
+            Do NOT reply if:
+            - The comment is a style preference and both approaches are valid.
+            - The author has already acknowledged the feedback.
+            - A debate is already in progress — let it resolve naturally.
+            - You already replied to this thread.
+
+            When you reply: be short and direct. One or two sentences maximum. State the technical
+            fact. If the author disagrees after your reply, drop the thread.
+
+            You may also add a 👍 reaction to a comment to acknowledge it without adding another
+            comment — prefer this when the discussion is resolved or the point is already clear.
+
+            Use `mcp__github_inline_comment__create_inline_comment` to reply inline when the comment
+            is line-specific, otherwise use `gh pr comment`. Post nothing else. No chat output.
+````
+
+Remove jobs you don't need to reduce cost. The `ci-diagnosis` and `discuss` jobs add no review API cost — they only run when other jobs fail or a human comments.
+
+---
+
+## GitHub Copilot
+
+Install skills into your repository, then create `.github/copilot-instructions.md`:
+
+```bash
+npx skills add https://github.com/samber/cc-skills-golang --agent github-copilot --skill '*' -y --copy
+ln -s .agents .copilot
+```
+
+```markdown
+# Go Code Review Instructions
+
+You are a senior Go engineer reviewing a pull request. Apply these guidelines for each area.
+
+Before considering your reply, build a list of relevant skills:
+
+    find .copilot/skills -type f -name SKILL.md -print0 \
+      | xargs -0 yq -o=json \
+      | jq -r '{name, description}'
+
+Pick skills that look relevant. Even if they have a 0.001% chance of applying. Read them before reviewing the diff.
+
+## Review Areas
+
+- **Code style** — formatting, comment quality, idiomatic Go patterns (`.copilot/skills/golang-code-style/SKILL.md`)
+- **Naming** — packages, types, variables, functions, constants (`.copilot/skills/golang-naming/SKILL.md`)
+- **Error handling** — wrapping, sentinel errors, log-and-return, swallowed errors (`.copilot/skills/golang-error-handling/SKILL.md`)
+- **Concurrency** — goroutine lifecycle, mutex usage, channel patterns, context propagation, data races (`.copilot/skills/golang-concurrency/SKILL.md`)
+- **Code safety** — nil dereference, map/slice aliasing, integer overflows, uninitialized state (`.copilot/skills/golang-safety/SKILL.md`)
+- **Tests** — coverage of new code, test quality, table-driven tests, use of t.Helper() (`.copilot/skills/golang-testing/SKILL.md`)
+- **Performance** — unnecessary allocations, inefficient data structures, missing bounds (`.copilot/skills/golang-performance/SKILL.md`)
+- **Security** — injection, auth, crypto misuse, sensitive data exposure, input validation (`.copilot/skills/golang-security/SKILL.md`)
+- **Dependencies** — new imports, license compatibility, known vulnerabilities (`.copilot/skills/golang-dependency-management/SKILL.md`)
+- **Documentation** — exported symbols, package docs, README impact (`.copilot/skills/golang-documentation/SKILL.md`)
+- **Observability** — logging, metrics, tracing added for new code paths (`.copilot/skills/golang-observability/SKILL.md`)
+- **Modernize code** — outdated patterns replaced with Go 1.21+ idioms (`.copilot/skills/golang-modernize/SKILL.md`)
+
+## Priority
+
+- **Blocking-first**: Security, Code safety, Error handling, Concurrency
+- **Important**: Tests, Performance, Dependencies
+- **Suggestion-first**: Code style, Naming, Documentation, Observability, Modernize code
+
+## Severity Labels
+
+- 🔴 **BLOCKING** — bug, vulnerability, data race, or correctness issue; must be fixed before merge.
+- 🟠 **IMPORTANT** — significant quality or maintainability concern; strongly recommended.
+- 🟡 **SUGGESTION** — style, naming, or minor improvement; optional but worthwhile.
+
+Write short, concise comments. Reference the exact file and line. Explain what is wrong and why it matters. Provide a concrete fix. Post nothing if there is nothing to say.
+```
+
+---
+
+## Cost and tuning
+
+The 4 parallel review jobs (quality, correctness, security, quality-depth) each spawn a Claude agent per PR push. Remove jobs you don't need. The `ci-diagnosis` and `discuss` jobs add no review API cost — they only run when other jobs fail or a human comments.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/LICENSE b/packages/autoskills/skills-registry/samber-go-skills/LICENSE
new file mode 100644
index 00000000..e01f008a
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/LICENSE
@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Samuel Berthe
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/README.md b/packages/autoskills/skills-registry/samber-go-skills/README.md
new file mode 100644
index 00000000..740f2b91
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/README.md
@@ -0,0 +1,471 @@
+# Agent Skills for production-ready Golang projects
+
+AI agent skills are reusable instruction sets that extend your coding assistant with domain-specific expertise, loaded on demand so they don't bloat your context. This repository covers **Go-specific** skills only (language, testing, security, observability, etc.); for dev workflow skills (git conventions, CI/CD, PR reviews) you'll want to add a separate skills plugin.
+
+For generic skills, please visit [cc-skills](https://github.com/samber/cc-skills).
+
+> [!IMPORTANT] Bootstrapped with Claude Code by distilling my Go project commits. **Edited, tested, reviewed and reworked by a human**.
+>
+> **No AI slop here.** AI-made skills are useless.
+
+<img width="1414" height="491" alt="image" src="https://github.com/user-attachments/assets/620b5835-c1ba-4ea9-bf47-2293b58b879e" />
+
+## 🚀 How to use
+
+**Install with [skills](https://skills.sh/) CLI** (universal, works with any [Agent Skills](https://agentskills.io)-compatible tool):
+
+```bash
+npx skills add https://github.com/samber/cc-skills-golang --all
+# or a single skill:
+npx skills add https://github.com/samber/cc-skills-golang --skill golang-performance
+```
+
+<!-- prettier-ignore-start -->
+
+<details>
+<summary>Claude Code</summary>
+
+```bash
+/plugin marketplace add samber/cc
+/plugin install cc-skills-golang@samber
+```
+
+</details>
+
+<details>
+<summary>Openclaw</summary>
+
+Copy skills into the cross-client discovery directory:
+
+```bash
+git clone https://github.com/samber/cc-skills-golang.git ~/.openclaw/skills/cc-skills-golang
+# or in workspace:
+git clone https://github.com/samber/cc-skills-golang.git ~/.openclaw/workspace/skills/cc-skills-golang
+```
+
+</details>
+
+<details>
+<summary>Gemini CLI</summary>
+
+```bash
+gemini extensions install https://github.com/samber/cc-skills-golang
+```
+
+Update with `gemini extensions update cc-skills-golang`.
+
+</details>
+
+<details>
+<summary>Cursor</summary>
+
+Copy skills into the cross-client discovery directory:
+
+```bash
+git clone https://github.com/samber/cc-skills-golang.git  ~/.cursor/skills/cc-skills-golang
+```
+
+Cursor auto-discovers skills from `.agents/skills/` and `.cursor/skills/`.
+
+</details>
+
+<details>
+<summary>Copilot</summary>
+
+Copy skills into the cross-client discovery directory:
+
+```bash
+/plugin install https://github.com/samber/cc-skills-golang
+# or
+git clone https://github.com/samber/cc-skills-golang.git ~/.copilot/skills/cc-skills-golang
+```
+
+Copilot auto-discovers skills from `.copilot/skills/`.
+
+</details>
+
+<details>
+<summary>OpenCode</summary>
+
+Copy skills into the cross-client discovery directory:
+
+```bash
+git clone https://github.com/samber/cc-skills-golang.git ~/.agents/skills/cc-skills-golang
+```
+
+OpenCode auto-discovers skills from `.agents/skills/`, `.opencode/skills/`, and `.claude/skills/`.
+
+</details>
+
+<details>
+<summary>Codex (OpenAI)</summary>
+
+Clone into the cross-client discovery path:
+
+```bash
+git clone https://github.com/samber/cc-skills-golang.git ~/.agents/skills/cc-skills-golang
+```
+
+Codex auto-discovers skills from `~/.agents/skills/` and `.agents/skills/`. Update with `cd ~/.agents/skills/cc-skills-golang && git pull`.
+
+</details>
+
+<details>
+<summary>Antigravity</summary>
+
+Clone and symlink into the cross-client discovery path:
+
+```bash
+git clone https://github.com/samber/cc-skills-golang.git ~/.antigravity/skills/cc-skills-golang
+```
+
+Update with `cd ~/.antigravity/skills/cc-skills-golang && git pull`.
+
+</details>
+
+<!-- prettier-ignore-end -->
+
+## 🧩 Skills
+
+These skills are designed as **atomic, cross-referencing units**. A skill may reference conventions defined in another (e.g. error-handling rules that affect logging live in `golang-error-handling`, not `golang-observability`). Installing only a subset will give you a partial and potentially inconsistent view of the guidelines. For best results, install all general-purpose skills together.
+
+```
+                         ┌────────────────────────────────────────┐
+                         │             Golang Skills              │
+                         └──────────────────┬─────────────────────┘
+                                            │
+   ┌─────────────────┬──────────────────────┼──────────────────────┐
+   ▼                 ▼                      ▼                      ▼
+┌──────────────┐ ┌──────────────┐ ┌─────────────────┐ ┌──────────────────┐
+│ Code Quality │ │ Arch & Design│ │    QA & Perf    │ │  Project Start   │
+├──────────────┤ ├──────────────┤ ├─────────────────┤ ├──────────────────┤
+│ code-style   │ │ design-patt  │ │ testing         │ │ project-layout   │
+│ naming       │ │ concurrency  │ │ benchmark       │ │ popular-libs     │
+│ error-handl  │ │ context      │ │ performance     │ │ cli              │
+│ safety       │ │ dep-inject   │ │ troubleshoot    │ │ CI               │
+│ structs-iface│ │ data-structs │ │ observability   │ │ stay-updated     │
+│ documentation│ │ database     │ │                 │ │ dep-management   │
+│ lint         │ │ modernize    │ │                 │ │                  │
+│ security     │ │              │ │                 │ │                  │
+└──────────────┘ └──────────────┘ └─────────────────┘ └──────────────────┘
+
+    ┌─────────────────────────────────────────────────────────────────────────┐
+    │                      Framework / Library Skills                         │
+    ├──────────────┬────────────────┬──────────────┬─────────────┬───────────┤
+    │   APIs       │      DI        │  Frameworks  │  samber/*   │  Testing  │
+    ├──────────────┼────────────────┼──────────────┼─────────────┼───────────┤
+    │ grpc         │ google-wire    │ spf13-cobra  │ samber-lo   │ stretchr- │
+    │ graphql      │ uber-dig       │ spf13-viper  │ samber-mo   │  testify  │
+    │ swagger      │ uber-fx        │              │ samber-ro   │           │
+    │              │                │              │ samber-do   │           │
+    │              │                │              │ samber-hot  │           │
+    │              │                │              │ samber-slog │           │
+    │              │                │              │ samber-oops │           │
+    └──────────────┴────────────────┴──────────────┴─────────────┴───────────┘
+
+```
+
+- ⭐️ Recommended
+- ✅ Published
+- 👷 Work in progress
+- ❌ To-do
+- ⚡ Command available
+- 🧠 Ultrathink automatically
+- ⚙️ Overridable (see doc below)
+- **Description (tok)**: weight of the `description` field from YAML frontmatter, always loaded into Claude's context for skill triggering
+- **SKILL.md (tok)**: weight of the full `SKILL.md` file loaded when the skill triggers
+- **Directory (tok)**: weight of all files in the skill directory (SKILL.md + referenced markdown files)
+
+**General purpose:**
+
+<!-- markdownlint-disable table-column-style -->
+
+|  | Skill | Flags | Error rate gap | Description (tok) | SKILL.md (tok) | Directory (tok) |
+| --- | --- | --- | --- | --- | --- | --- |
+| ⭐️ | ✅ `golang-code-style` | ⚡ ⚙️ | -40% | 115 | 2,069 | 2,685 |
+| ⭐️ | ✅ `golang-data-structures` | ⚡ | -39% | 92 | 2,464 | 6,176 |
+| ⭐️ | ✅ `golang-database` | ⚡ ⚙️ | -38% | 97 | 2,725 | 7,248 |
+| ⭐️ | ✅ `golang-design-patterns` | ⚡ ⚙️ | -37% | 66 | 2,610 | 9,316 |
+| ⭐️ | ✅ `golang-documentation` | ⚡ ⚙️ | -53% | 73 | 2,678 | 10,549 |
+| ⭐️ | ✅ `golang-error-handling` | ⚡ ⚙️ | -26% | 139 | 1,520 | 4,394 |
+| ⭐️ | ✅ `golang-how-to` | ⚡ | — | 165 | 2,191 | 10,255 |
+| ⭐️ | ✅ `golang-modernize` | ⚡ | -61% | 68 | 2,476 | 7,599 |
+| ⭐️ | ✅ `golang-naming` | ⚡ ⚙️ | -23% | 158 | 2,865 | 7,233 |
+| ⭐️ | ✅ `golang-safety` | ⚡ | -58% | 78 | 2,457 | 5,227 |
+| ⭐️ | ✅ `golang-testing` | ⚡ 🧠 ⚙️ | -32% | 113 | 3,105 | 6,212 |
+| ⭐️ | ✅ `golang-troubleshooting` | ⚡ 🧠 | -32% | 126 | 2,735 | 15,901 |
+| ⭐️ | ✅ `golang-security` | ⚡ 🧠 | -32% | 84 | 2,873 | 20,894 |
+|  | ✅ `golang-benchmark` | ⚡ 🧠 | -50% | 99 | 2,135 | 29,248 |
+|  | ✅ `golang-cli` | ⚡ | -43% | 122 | 2,274 | 6,089 |
+|  | ✅ `golang-concurrency` | ⚡ ⚙️ | -39% | 71 | 1,873 | 6,338 |
+|  | ✅ `golang-context` | ⚡ ⚙️ | -34% | 80 | 1,144 | 3,940 |
+|  | ✅ `golang-continuous-integration` | ⚡ | -59% | 82 | 2,835 | 6,477 |
+|  | ✅ `golang-dependency-injection` | ⚡ ⚙️ | -47% | 176 | 2,842 | 5,113 |
+|  | ✅ `golang-dependency-management` | ⚡ | -54% | 77 | 1,877 | 4,957 |
+|  | ✅ `golang-structs-interfaces` | ⚡ ⚙️ | -35% | 110 | 2,999 | 2,999 |
+|  | ✅ `golang-lint` | ⚡ | -41% | 98 | 1,714 | 5,493 |
+|  | ✅ `golang-observability` | ⚡ ⚙️ | -37% | 161 | 2,921 | 18,453 |
+|  | ✅ `golang-performance` | ⚡ 🧠 | -39% | 127 | 1,953 | 17,855 |
+|  | ✅ `golang-popular-libraries` | ⚡ | -30% | 61 | 788 | 4,131 |
+|  | ✅ `golang-project-layout` | ⚡ | -38% | 69 | 1,510 | 5,718 |
+|  | ✅ `golang-stay-updated` | ⚡ | -56% | 43 | 1,916 | 1,916 |
+
+**Tools:**
+
+| Skill | Flags | Error rate gap | Description (tok) | SKILL.md (tok) | Directory (tok) |
+| --- | --- | --- | --- | --- | --- |
+| ✅ `golang-google-wire` | ⚡ | -16% | 122 | 2,511 | 7,243 |
+| ✅ `golang-graphql` |  | -16% | 76 | 2,935 | 7,766 |
+| ✅ `golang-grpc` | ⚡ | -41% | 69 | 2,149 | 4,965 |
+| ✅ `golang-spf13-cobra` | ⚡ | — | 176 | 2,455 | 7,218 |
+| ✅ `golang-spf13-viper` | ⚡ | — | 170 | 2,412 | 6,936 |
+| ✅ `golang-swagger` | ⚡ | — | 144 | 2,125 | 3,123 |
+| ✅ `golang-uber-dig` | ⚡ | -10% | 107 | 2,264 | 5,904 |
+| ✅ `golang-uber-fx` | ⚡ | -5% | 118 | 2,499 | 6,747 |
+| ✅ `golang-samber-do` | ⚡ | -81% | 71 | 1,746 | 3,269 |
+| ✅ `golang-samber-hot` | ⚡ | -54% | 118 | 1,843 | 7,273 |
+| ✅ `golang-samber-lo` | ⚡ | -40% | 165 | 2,410 | 10,031 |
+| ✅ `golang-samber-mo` | ⚡ 🧠 | -48% | 81 | 2,800 | 11,215 |
+| ✅ `golang-samber-oops` | ⚡ | -59% | 69 | 2,380 | 2,692 |
+| ✅ `golang-samber-ro` | ⚡ 🧠 | -50% | 152 | 2,845 | 11,136 |
+| ✅ `golang-samber-slog` | ⚡ | -19% | 118 | 2,588 | 9,234 |
+| ❌ `golang-temporal` |  | — | 0 | 0 | 0 |
+| ✅ `golang-stretchr-testify` | ⚡ | -47% | 90 | 1,714 | 2,533 |
+
+## 🧪 Skill evaluations
+
+|             | With Skill          | Without Skill       | Delta     |
+| ----------- | ------------------- | ------------------- | --------- |
+| **Overall** | **3315/3395 (98%)** | **1915/3395 (56%)** | **+41pp** |
+
+See [EVALUATIONS.md](./EVALUATIONS.md) for the full per-skill breakdown.
+
+## 📖 Skills description
+
+### Code Quality
+
+#### `golang-code-style`
+
+Go code formatting and conventions. gofmt, goimports, linting rules, comment conventions, and project-level style consistency. Overridable by company skills.
+
+#### `golang-documentation`
+
+Go documentation standards. Package docs, godoc conventions, code comments, example functions, README structure, and API reference generation. Overridable.
+
+#### `golang-error-handling`
+
+Go error handling best practices. Error creation, wrapping with fmt.Errorf and errors.Is/As, sentinel errors, custom error types, error codes, and panic recovery. Overridable.
+
+#### `golang-lint`
+
+Go linting best practices and golangci-lint configuration. Presets, custom rules, CI integration, inline suppression, and output interpretation.
+
+#### `golang-naming`
+
+Go naming conventions across all identifier types. Packages, constructors, structs, interfaces, constants, errors, receivers, acronyms, test functions. Covers MixedCaps rules, Get-prefix, and utils/helpers anti-patterns. Overridable.
+
+#### `golang-safety`
+
+Defensive Go coding. Prevents panics, silent data corruption, and runtime bugs. nil safety, append aliasing, map concurrent access, float comparison, zero-value design, numeric overflow.
+
+#### `golang-security`
+
+Go security best practices. Injection prevention (SQL, command, XSS), cryptography, filesystem/network safety, secrets management, cookie security, and tool configuration. Audit and review modes.
+
+#### `golang-structs-interfaces`
+
+Go struct and interface design. Composition, embedding, type assertions, interface segregation, struct tags (JSON/YAML/DB), pointer vs value receivers. Overridable.
+
+### Architecture & Design
+
+#### `golang-concurrency`
+
+Go concurrency patterns. Goroutines, channels, sync primitives, context cancellation, worker pools, fan-out/fan-in, pipelines. Overridable.
+
+#### `golang-context`
+
+Idiomatic context.Context usage. Creation, cancellation, timeouts, values, propagation patterns, and common anti-patterns. Overridable.
+
+#### `golang-data-structures`
+
+Go data structures internals and usage. Slices (capacity growth, append aliasing), maps, channels, sync primitives, and when to use each.
+
+#### `golang-database`
+
+Go database access patterns. Parameter binding, connection pooling, transactions, migrations, sqlboiler/sqlc code generation, query builders. Overridable.
+
+#### `golang-dependency-injection`
+
+Dependency injection patterns in Go. Constructor injection, interface-based DI, wire/dig/fx comparison, and when DI is worth the complexity. Overridable.
+
+#### `golang-design-patterns`
+
+Idiomatic Go design patterns. Functional options, constructors, builder pattern, middleware chains, circuit breaker, and architecture guides with file trees and code. Overridable.
+
+#### `golang-modernize`
+
+Modernize Go code to use recent language features. Range-over-int, min/max builtins, iterators, slices/maps/cmp/slog stdlib packages, testing patterns (t.Context, b.Loop, synctest), and tooling upgrades.
+
+### QA & Performance
+
+#### `golang-benchmark`
+
+Go benchmarking, profiling, and performance measurement. pprof, trace, CPU/memory/block profiles, flame graphs, benchmark comparison (benchstat), continuous profiling.
+
+#### `golang-observability`
+
+Go production observability. Structured logging (slog), Prometheus metrics, OpenTelemetry tracing, pprof profiling, RUM tracking, alerting, Grafana dashboards. Overridable.
+
+#### `golang-performance`
+
+Go performance optimization. Allocation reduction, CPU efficiency, memory layout, GC tuning, pooling, caching, hot-path optimization. Review and hot-path modes.
+
+#### `golang-testing`
+
+Production-ready Go tests. Table-driven tests, fuzzing, fixtures, goroutine leak detection (goleak), snapshot testing, code coverage, integration tests, parallel tests. Overridable.
+
+#### `golang-troubleshooting`
+
+Systematic Go debugging methodology. Common pitfalls, test-driven debugging, pprof capture, Delve debugger, race detection, GODEBUG tracing, production debugging.
+
+### Project Setup
+
+#### `golang-cli`
+
+Go CLI application development. Project layout, exit codes, signal handling, I/O patterns, argument parsing, and terminal UX.
+
+#### `golang-continuous-integration`
+
+CI/CD pipeline configuration for Go projects using GitHub Actions. Build, test, lint, and release workflows.
+
+#### `golang-dependency-management`
+
+Go module dependency strategies. go.mod conventions, versioning, replace directives, tool dependencies, and multi-module workspaces.
+
+#### `golang-popular-libraries`
+
+Curated recommendations for production-ready Go libraries and frameworks. When the stdlib is enough vs when to reach for a package.
+
+#### `golang-project-layout`
+
+Go project structure and workspace setup. cmd/internal/pkg conventions, monorepo layout, CLI project structure, and when to keep things flat.
+
+#### `golang-stay-updated`
+
+Resources to stay current with Go. Official channels, community hubs, key people to follow, and learning resources.
+
+### APIs
+
+#### `golang-graphql`
+
+GraphQL API development in Go using gqlgen/graphql-go. Schema definition, resolvers, subscriptions, dataloader, and federation.
+
+#### `golang-grpc`
+
+gRPC in Go. Protobuf organization, service definitions, streaming, interceptors, error codes, and code generation workflow.
+
+#### `golang-swagger`
+
+OpenAPI/Swagger docs with swaggo/swag. Annotation comments, code generation, framework integrations (gin, echo, fiber, chi), security definitions.
+
+### Dependency Injection
+
+#### `golang-google-wire`
+
+Compile-time dependency injection with google/wire. Provider sets, injector generation, wire.Build, and structured DI patterns.
+
+#### `golang-uber-dig`
+
+Reflection-based DI with uber-go/dig. Provide/Invoke, dig.In/dig.Out, named values, value groups, optional dependencies, and Decorate.
+
+#### `golang-uber-fx`
+
+Application framework with uber-go/fx. fx.New, fx.Provide/Invoke, fx.Module, lifecycle hooks, fx.Annotate, fx.Decorate, signal-aware Run.
+
+### Frameworks
+
+#### `golang-spf13-cobra`
+
+CLI command trees with spf13/cobra. Command hierarchy, RunE hooks, flag management, shell completion, usage templates, and testing with SetArgs.
+
+#### `golang-spf13-viper`
+
+Layered configuration with spf13/viper. Flag > env > file > KV > default precedence, BindPFlag, hot reload, test isolation, and remote KV integration.
+
+### samber/\*
+
+#### `golang-samber-do`
+
+Dependency injection with samber/do. Type-safe service containers, lifecycle management, scopes, health checks, and graceful shutdown.
+
+#### `golang-samber-hot`
+
+In-memory caching with samber/hot. 9 eviction algorithms (LRU, LFU, TinyLFU, W-TinyLFU, S3FIFO, ARC, SIEVE...), TTL, loaders, sharding, stale-while-revalidate, Prometheus metrics.
+
+#### `golang-samber-lo`
+
+Functional programming helpers with samber/lo. 500+ type-safe generic functions for slices, maps, channels, strings. Immutable (lo), parallel (lop), mutable (lom), iterators (loi), SIMD.
+
+#### `golang-samber-mo`
+
+Monadic types with samber/mo. Option, Result, Either, Future, IO, Task, State for type-safe nullable values, error handling, and functional composition.
+
+#### `golang-samber-oops`
+
+Structured error handling with samber/oops. Error builders, stack traces, error codes, context attributes, public vs developer messages, panic recovery, and APM integration.
+
+#### `golang-samber-ro`
+
+Reactive streams with samber/ro. 150+ type-safe operators, cold/hot observables, 5 subject types, 40+ plugins, automatic backpressure, and Go context integration.
+
+#### `golang-samber-slog`
+
+Structured logging pipeline with samber/slog-\*\*\*\* packages. Multi-handler routing (slog-multi), sampling, formatting, HTTP middleware, and 20+ backend sinks.
+
+### Testing
+
+#### `golang-stretchr-testify`
+
+Testing with stretchr/testify. assert, require, mock, and suite packages. Assertions, mock expectations, argument matchers, suite lifecycle, and custom matchers.
+
+## 🕵 Use in CI for AI-driven reviews
+
+Add AI agents as PR reviewers alongside traditional static analysis. When configured with this skill plugin, the agent applies the relevant Go skills per review area — catching architectural drift, logic bugs, and concurrency hazards that linters cannot detect.
+
+See [GOLANG-AI-DRIVEN-REVIEW.md](./GOLANG-AI-DRIVEN-REVIEW.md) for full setup instructions (Claude Code Action and GitHub Copilot).
+
+## 🎯 Tuning Skill Triggers
+
+If a skill triggers too often or not often enough, please [open an issue](https://github.com/samber/cc-skills-golang/issues) suggesting a description change. The `description` field in SKILL.md frontmatter is the primary triggering mechanism — small wording adjustments can significantly improve trigger accuracy. Some `SKILL.md` files might have a `When to use` section which is another level of exclusion. Finally, `SKILL.md` files are an entrypoint for lazy loading references with deep knowledge located in `references/`.
+
+## 🔄 Overlap
+
+Claude reports very little overlap between skills in this repo, thanks to cross-reference. I suggest enabling most of the skills and leveraging lazy loading. The recommended ⭐️ skills load ~1,100 tokens of descriptions at startup; full skill content is only pulled in when relevant. Note:
+
+- I estimate that 50% of `golang-naming` and `golang-code-style` overlap with linters (golangci-lint).
+- A large part of the security rules in `golang-security` have been distilled from the Bearer (SAST) checklist. The skill is still useful for methodology.
+- If your team has its own conventions, create a company skill and declare the override explicitly near the top of its body: `This skill supersedes samber/cc-skills-golang@golang-naming skill for [company] projects.` Skills marked ⚙️ in the table above support this mechanism.
+
+## ✍️ Contribute
+
+- **100 tokens per skill description** - what? when to use this skill?
+- **1.000–2.500 tokens per SKILL.md** — keep the main file focused on essentials
+- **Use secondary markdown files for depth** — reference them from SKILL.md with relative links (e.g., `[Logging](./logging.md)`). Claude reads these on demand when the topic is relevant, so they don't count against the context budget until needed
+- **Up to 10.000 tokens** for full skill and secondary files
+- **2–4 skills loaded simultaneously** in a typical session — design skills to coexist
+- **Stay below ~10k tokens of total loaded SKILL.md** anytime to avoid degrading response quality
+
+For more guidelines, please check `CLAUDE.md`.
+
+## 💫 Fuel the Revolution
+
+- ⭐️ **Star this repo** - Your star powers the caffeine engine!
+- ☕️ **Buy me a coffee** - I'll literally use it to build more skills while drinking actual coffee
+
+[![GitHub Sponsors](https://img.shields.io/github/sponsors/samber?style=for-the-badge)](https://github.com/sponsors/samber)
+
+## 📝 License
+
+Copyright © 2026 [Samuel Berthe](https://github.com/samber).
+
+This project is under [MIT](./LICENSE) license.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/clawhub-publish.sh b/packages/autoskills/skills-registry/samber-go-skills/clawhub-publish.sh
new file mode 100644
index 00000000..32f3d5d2
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/clawhub-publish.sh
@@ -0,0 +1,36 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+if [ -n "${CLAWHUB_TOKEN:-}" ]; then
+    # executed from in ci
+    npx -y clawhub login --token "$CLAWHUB_TOKEN"
+fi
+
+for skill_dir in skills/*/; do
+  skill_name=$(basename "$skill_dir")
+  skill_file="${skill_dir}SKILL.md"
+
+  if [ ! -f "$skill_file" ]; then
+    echo "Skipping ${skill_name}: no SKILL.md found"
+    continue
+  fi
+
+  # Parse version from frontmatter
+  version=$(awk '/^---$/{c++; next} c==1 && /^[[:space:]]*version:/{gsub(/[" ]/, "", $2); print $2; exit}' "$skill_file")
+
+  if [ -z "$version" ] || [ "$version" = "0.0.0" ]; then
+    echo "Skipping ${skill_name}: no version or version is 0.0.0"
+    continue
+  fi
+
+  echo "Publishing ${skill_name} v${version}"
+  npx -y clawhub publish "$PWD/${skill_dir}" --version "$version" || true
+
+  if [ -n "${CLAWHUB_TOKEN:-}" ]; then
+      # executed from in ci
+      continue
+  fi
+
+  # rate limits: 5 skills per hour / 20 skills per day
+  sleep 3600
+done
diff --git a/packages/autoskills/skills-registry/samber-go-skills/gemini-extension.json b/packages/autoskills/skills-registry/samber-go-skills/gemini-extension.json
new file mode 100644
index 00000000..33ec07aa
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/gemini-extension.json
@@ -0,0 +1,5 @@
+{
+  "name": "cc-skills-golang",
+  "version": "1.5.1",
+  "description": "AI Agent Skills for production-ready Go projects"
+}
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/SKILL.md
new file mode 100644
index 00000000..333d19a7
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/SKILL.md
@@ -0,0 +1,184 @@
+---
+name: golang-benchmark
+description: "Golang benchmarking, profiling, and performance measurement. Use when writing, running, or comparing Go benchmarks, profiling hot paths with pprof, interpreting CPU/memory/trace profiles, analyzing results with benchstat, setting up CI benchmark regression detection, or investigating production performance with Prometheus runtime metrics. Also use when the developer needs deep analysis on a specific performance indicator - this skill provides the measurement methodology, while `samber/cc-skills-golang@golang-performance` provides the optimization patterns."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.4"
+  openclaw:
+    emoji: "📊"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - benchstat
+    install:
+      - kind: go
+        package: golang.org/x/perf/cmd/benchstat@latest
+        bins: [benchstat]
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch Bash(benchstat:*) Bash(benchdiff:*) Bash(cob:*) Bash(gobenchdata:*) Bash(curl:*) mcp__context7__resolve-library-id mcp__context7__query-docs WebSearch AskUserQuestion
+---
+
+**Persona:** You are a Go performance measurement engineer. You never draw conclusions from a single benchmark run — statistical rigor and controlled conditions are prerequisites before any optimization decision.
+
+**Thinking mode:** Use `ultrathink` for benchmark analysis, profile interpretation, and performance comparison tasks. Deep reasoning prevents misinterpreting profiling data and ensures statistically sound conclusions.
+
+**Dependencies:**
+
+- benchstat: `go install golang.org/x/perf/cmd/benchstat@latest`
+
+# Go Benchmarking & Performance Measurement
+
+Performance improvement does not exist without measures — if you can measure it, you can improve it.
+
+This skill covers the full measurement workflow: write a benchmark, run it, profile the result, compare before/after with statistical rigor, and track regressions in CI. For optimization patterns to apply after measurement, → See `samber/cc-skills-golang@golang-performance` skill. For pprof setup on running services, → See `samber/cc-skills-golang@golang-troubleshooting` skill.
+
+## Writing Benchmarks
+
+### `b.Loop()` (Go 1.24+) — preferred
+
+For Go 1.24+, prefer `b.Loop()` for new benchmarks. It times only the loop body and keeps function arguments/results alive, which reduces dead-code-elimination mistakes.
+
+```go
+func BenchmarkParse(b *testing.B) {
+    data := loadFixture("large.json") // setup — excluded from timing
+    for b.Loop() {
+        Parse(data)  // compiler cannot eliminate this call
+    }
+}
+```
+
+Legacy `b.N` loops still compile and are fine to keep when preserving existing benchmarks or supporting Go <1.24. They are easier to get wrong: setup may need `b.ResetTimer()`, and results may need a sink if the compiler can eliminate the work. Go 1.26 fixed an earlier `b.Loop()` inlining limitation — benchmarks on 1.24–1.25 already benefit from `b.Loop()` but may miss inlining optimizations that 1.26 delivers.
+
+### Memory tracking
+
+```go
+func BenchmarkAlloc(b *testing.B) {
+    b.ReportAllocs() // or run with -benchmem flag
+    var sink []byte
+    for b.Loop() {
+        sink = make([]byte, 1024)
+    }
+    _ = sink
+}
+```
+
+`b.ReportMetric()` adds custom metrics (e.g., throughput):
+
+```go
+b.ReportMetric(float64(totalBytes)/b.Elapsed().Seconds(), "bytes/s") // b.Elapsed() is only valid inside b.Loop()
+```
+
+### Sub-benchmarks and table-driven
+
+```go
+func BenchmarkEncode(b *testing.B) {
+    for _, size := range []int{64, 256, 4096} {
+        b.Run(fmt.Sprintf("size=%d", size), func(b *testing.B) {
+            data := make([]byte, size)
+            for b.Loop() {
+                Encode(data)
+            }
+        })
+    }
+}
+```
+
+## Running Benchmarks
+
+```bash
+go test -bench=BenchmarkEncode -benchmem -count=10 ./pkg/... | tee bench.txt
+```
+
+| Flag                   | Purpose                                   |
+| ---------------------- | ----------------------------------------- |
+| `-bench=.`             | Run all benchmarks (regexp filter)        |
+| `-benchmem`            | Report allocations (B/op, allocs/op)      |
+| `-count=10`            | Run 10 times for statistical significance |
+| `-benchtime=3s`        | Minimum time per benchmark (default 1s)   |
+| `-cpu=1,2,4`           | Run with different GOMAXPROCS values      |
+| `-cpuprofile=cpu.prof` | Write CPU profile                         |
+| `-memprofile=mem.prof` | Write memory profile                      |
+| `-trace=trace.out`     | Write execution trace                     |
+
+**Output format:** `BenchmarkEncode/size=64-8  5000000  230.5 ns/op  128 B/op  2 allocs/op` — the `-8` suffix is GOMAXPROCS, `ns/op` is time per operation, `B/op` is bytes allocated per op, `allocs/op` is heap allocation count per op.
+
+## Documenting Results in Commits
+
+Paste benchstat output in the commit body when the change has a measurable performance impact. This documents _why_ an optimization was made, prevents future readers from reverting it, and lets reviewers verify the claim without re-running benchmarks.
+
+Commit format:
+
+```
+perf(parser): reduce Parse allocations 50% with sync.Pool
+
+Replace per-call []byte allocation with a pooled buffer.
+
+goos: linux / goarch: amd64 / cpu: AMD Ryzen 9 5950X
+          │    old     │              new               │
+          │  sec/op    │  sec/op     vs base            │
+Parse-32    4.592µ ± 2%  3.041µ ± 1%  -33.78% (p=0.000 n=10)
+
+          │   old    │             new              │
+          │   B/op   │   B/op     vs base           │
+Parse-32   1.024Ki ± 0%  0.512Ki ± 0%  -50.00% (p=0.000 n=10)
+
+          │ old  │            new             │
+          │ allocs/op │ allocs/op  vs base    │
+Parse-32   12.00 ± 0%   6.000 ± 0%  -50.00% (p=0.000 n=10)
+```
+
+**Rules:**
+
+- Only include benchmarks directly affected by the change — strip unrelated rows
+- Never paste results with `~` (no statistical significance) — the improvement cannot be claimed
+- Include the hardware context line (`goos/goarch/cpu`) so results are reproducible
+- Use `perf(scope):` commit type for performance-only changes
+
+## Profiling from Benchmarks
+
+Generate profiles directly from benchmark runs — no HTTP server needed:
+
+```bash
+# CPU profile
+go test -bench=BenchmarkParse -cpuprofile=cpu.prof ./pkg/parser
+go tool pprof cpu.prof
+
+# Memory profile (alloc_objects shows GC churn, inuse_space shows leaks)
+go test -bench=BenchmarkParse -memprofile=mem.prof ./pkg/parser
+go tool pprof -alloc_objects mem.prof
+
+# Execution trace
+go test -bench=BenchmarkParse -trace=trace.out ./pkg/parser
+go tool trace trace.out
+```
+
+For full pprof CLI reference (all commands, non-interactive mode, profile interpretation), see [pprof Reference](./references/pprof.md). For execution trace interpretation, see [Trace Reference](./references/trace.md). For statistical comparison, see [benchstat Reference](./references/benchstat.md).
+
+## Reference Files
+
+- **[pprof Reference](./references/pprof.md)** — Interactive and non-interactive analysis of CPU, memory, and goroutine profiles. Full CLI commands, profile types (CPU vs alloc*objects vs inuse_space), web UI navigation, and interpretation patterns. Use this to dive deep into \_where* time and memory are being spent in your code.
+
+- **[benchstat Reference](./references/benchstat.md)** — Statistical comparison of benchmark runs with rigorous confidence intervals and p-value tests. Covers output reading, filtering old benchmarks, interleaving results for visual clarity, and regression detection. Use this when you need to prove a change made a meaningful performance difference, not just a lucky run.
+
+- **[Trace Reference](./references/trace.md)** — Execution tracer for understanding _when_ and _why_ code runs. Visualizes goroutine scheduling, garbage collection phases, network blocking, and custom span annotations. Use this when pprof (which shows _where_ CPU goes) isn't enough — you need to see the timeline of what happened.
+
+- **[Diagnostic Tools](./references/tools.md)** — Quick reference for ancillary tools: fieldalignment (struct padding waste), GODEBUG (runtime logging flags), fgprof (frame graph profiles), race detector (concurrency bugs), and others. Use this when you have a specific symptom and need a focused diagnostic — don't reach for pprof if a simpler tool already answers your question.
+
+- **[Compiler Analysis](./references/compiler-analysis.md)** — Low-level compiler optimization insights: escape analysis (when values move to the heap), inlining decisions (which function calls are eliminated), SSA dump (intermediate representation), and assembly output. Use this when benchmarks show allocations you didn't expect, or when you want to verify the compiler did what you intended.
+
+- **[CI Regression Detection](./references/ci-regression.md)** — Automated performance regression gating in CI pipelines. Covers three tools (benchdiff for quick PR comparisons, cob for strict threshold-based gating, gobenchdata for long-term trend dashboards), noisy neighbor mitigation strategies (why cloud CI benchmarks vary 5-10% even on quiet machines), and self-hosted runner tuning to make benchmarks reproducible. Use this when you want to ensure pull requests don't silently slow down your codebase — detecting regressions early prevents shipping performance debt.
+
+- **[Investigation Session](./references/investigation-session.md)** — Production performance troubleshooting workflow combining Prometheus runtime metrics (heap size, GC frequency, goroutine counts), PromQL queries to correlate metrics with code changes, runtime configuration flags (GODEBUG env vars to enable GC logging), and cost warnings (when you're hitting performance tax). Use this when production benchmarks look good but real traffic behaves differently.
+
+- **[Prometheus Go Metrics Reference](./references/prometheus-go-metrics.md)** — Complete listing of Go runtime metrics actually exposed as Prometheus metrics by `prometheus/client_golang`. Covers 30 default metrics, 40+ optional metrics (Go 1.17+), process metrics, and common PromQL queries. Distinguishes between `runtime/metrics` (Go internal data) and Prometheus metrics (what you scrape from `/metrics`). Use this when setting up monitoring dashboards or writing PromQL queries for production alerts.
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-performance` skill for optimization patterns to apply after measuring ("if X bottleneck, apply Y")
+- → See `samber/cc-skills-golang@golang-troubleshooting` skill for pprof setup on running services (enable, secure, capture), Delve debugger, GODEBUG flags, root cause methodology
+- → See `samber/cc-skills-golang@golang-observability` skill for everyday always-on monitoring, continuous profiling (Pyroscope), distributed tracing (OpenTelemetry)
+- → See `samber/cc-skills-golang@golang-testing` skill for general testing practices
+- → See `samber/cc-skills@promql-cli` skill for querying Prometheus runtime metrics in production to validate benchmark findings
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/evals/evals.json
new file mode 100644
index 00000000..cca46cba
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/evals/evals.json
@@ -0,0 +1,1081 @@
+[
+  {
+    "id": 1,
+    "name": "b-loop-vs-range-bn",
+    "description": "Tests whether the model uses b.Loop() (Go 1.24+) instead of the legacy for range b.N pattern",
+    "prompt": "Write a Go benchmark for a function `ComputeHash(data []byte) [32]byte` that uses SHA-256. The project uses Go 1.24. Include setup code that loads a 1MB test fixture.",
+    "trap": "Without the skill, the model defaults to `for i := 0; i < b.N; i++` or `for range b.N`, where setup may need manual b.ResetTimer() and unused results may need a sink to prevent dead code elimination",
+    "assertions": [
+      {"id": "1.1", "text": "Uses b.Loop() as the benchmark loop construct"},
+      {"id": "1.2", "text": "Setup code (loading fixture) is placed BEFORE the b.Loop() call, not inside it"},
+      {"id": "1.3", "text": "Does NOT use b.ResetTimer() since b.Loop() automatically excludes setup"},
+      {"id": "1.4", "text": "Does NOT use a package-level sink variable to prevent dead code elimination"},
+      {"id": "1.5", "text": "Does NOT use `for i := 0; i < b.N; i++` or `for range b.N`"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "dead-code-elimination-awareness",
+    "description": "Tests whether the model understands that b.Loop() prevents compiler dead code elimination",
+    "prompt": "I have this benchmark that seems unrealistically fast — the results show 0.3 ns/op for a function that parses a 10KB JSON document. What's wrong?\n\n```go\nfunc BenchmarkParseJSON(b *testing.B) {\n    data := loadFixture(\"large.json\")\n    for i := 0; i < b.N; i++ {\n        ParseJSON(data)\n    }\n}\n```\nThe project uses Go 1.24.",
+    "trap": "Without the skill, the model may suggest adding b.ResetTimer() or increasing benchtime, missing the core issue of dead code elimination",
+    "assertions": [
+      {"id": "2.1", "text": "Identifies dead code elimination as the cause — the compiler optimizes away the ParseJSON call because its result is unused"},
+      {"id": "2.2", "text": "Recommends migrating to b.Loop() as the primary fix since it prevents DCE automatically"},
+      {"id": "2.3", "text": "If mentioning the legacy workaround, describes using a package-level sink variable (not a local one)"},
+      {"id": "2.4", "text": "Explains that b.Loop() also automatically excludes the setup code from timing"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "count-flag-statistical-significance",
+    "description": "Tests whether the model recommends -count=10 for statistical significance rather than single runs",
+    "prompt": "I want to compare the performance of two JSON serialization approaches. How should I run the benchmarks to get reliable comparison data?",
+    "trap": "Without the skill, the model may suggest a single `go test -bench=.` run per version without -count, making benchstat comparison impossible",
+    "assertions": [
+      {"id": "3.1", "text": "Recommends -count=10 (or higher) for statistical significance"},
+      {"id": "3.2", "text": "Recommends using benchstat to compare the two runs"},
+      {"id": "3.3", "text": "Recommends -benchmem to track allocation metrics"},
+      {"id": "3.4", "text": "Recommends saving output to files (e.g., via tee) for later benchstat comparison"},
+      {"id": "3.5", "text": "Uses -run='^$' to skip unit tests during benchmark runs"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "benchstat-output-interpretation",
+    "description": "Tests understanding of benchstat output format including p-value, tilde symbol, and confidence intervals",
+    "prompt": "I ran benchstat and got this output. What does it mean? Should I merge my optimization?\n\n```\n          │   old.txt   │              new.txt               │\n          │   sec/op    │   sec/op     vs base               │\nParse-16    4.592µ ± 8%   4.481µ ± 7%  ~ (p=0.089 n=10)\n```",
+    "trap": "Without the skill, the model may interpret the lower number as an improvement and recommend merging",
+    "assertions": [
+      {"id": "4.1", "text": "Explains that the ~ symbol means no statistically significant difference was detected"},
+      {"id": "4.2", "text": "States that p=0.089 is above the 0.05 significance threshold"},
+      {"id": "4.3", "text": "Notes that the wide confidence intervals (±8%, ±7%) overlap, making the result untrustworthy"},
+      {"id": "4.4", "text": "Advises NOT to claim improvement based on this result"},
+      {"id": "4.5", "text": "Suggests increasing -count to 20+ or reducing noise sources as next steps"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "p-hacking-awareness",
+    "description": "Tests whether the model warns against rerunning benchmarks until significance appears",
+    "prompt": "My benchstat comparison keeps showing `~` (no significant difference). Can I just rerun the benchmarks a few more times and pick the run that shows significance?",
+    "trap": "Without the skill, the model may naively agree or suggest cherry-picking favorable runs",
+    "assertions": [
+      {"id": "5.1", "text": "Explicitly warns against 'retry until significant' as selection bias / p-hacking"},
+      {"id": "5.2", "text": "Explains that rerunning until ~ disappears introduces bias"},
+      {"id": "5.3", "text": "Recommends increasing -count ONCE and accepting the result"},
+      {"id": "5.4", "text": "Mentions that at alpha=0.05, ~5% of benchmarks will randomly show significance (false positives)"},
+      {"id": "5.5", "text": "Suggests the change may genuinely have no measurable effect"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "interleaving-benchmark-runs",
+    "description": "Tests knowledge of interleaving old/new benchmark runs to reduce systematic bias",
+    "prompt": "I'm comparing performance before and after an optimization. I ran all 10 baseline iterations first, then all 10 optimized iterations. My colleague says this approach is flawed. Why?",
+    "trap": "Without the skill, the model may not know about systematic bias from sequential runs or may not suggest pre-compilation with go test -c",
+    "assertions": [
+      {"id": "6.1", "text": "Identifies systematic bias: thermal throttling, background processes, CPU frequency scaling can differ between the first batch and second batch"},
+      {"id": "6.2", "text": "Recommends interleaving runs (alternating old/new) to reduce this bias"},
+      {"id": "6.3", "text": "Recommends pre-compiling both versions with `go test -c` to avoid measuring compilation time"},
+      {"id": "6.4", "text": "Shows running the pre-compiled test binaries directly (e.g., ./old.test -test.bench=...)"},
+      {"id": "6.5", "text": "Explains that without pre-compilation, each go test -bench invocation includes compilation overhead that varies"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "alloc-objects-vs-inuse-space",
+    "description": "Tests understanding of when to use alloc_objects vs inuse_space heap profile types",
+    "prompt": "My Go service has high GC CPU overhead (30% of CPU in runtime.mallocgc according to pprof). I captured a heap profile. Should I look at alloc_objects, alloc_space, or inuse_space?",
+    "trap": "Without the skill, the model may suggest inuse_space (which shows live objects, not allocation rate) or alloc_space (which shows bytes, not count)",
+    "assertions": [
+      {"id": "7.1", "text": "Recommends alloc_objects as the primary choice for GC pressure / high allocation rate"},
+      {"id": "7.2", "text": "Explains that alloc_objects counts allocation events and helps find high-frequency object churn driving GC work"},
+      {"id": "7.3", "text": "Explains that inuse_space shows currently live objects and is for leak detection, not GC churn"},
+      {"id": "7.4", "text": "Distinguishes alloc_space (total bytes allocated) as useful for reducing peak memory, not GC frequency"},
+      {"id": "7.5", "text": "Mentions that runtime.mallocgc dominating CPU profile indicates allocation rate is the bottleneck, not computation"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "pprof-flat-vs-cum",
+    "description": "Tests understanding of flat vs cumulative time in pprof and when to use top -cum",
+    "prompt": "I ran `go tool pprof cpu.prof` and the top command shows runtime.mallocgc, runtime.memmove, and runtime.scanobject as the top functions. These are all runtime functions I can't modify. How do I find which of MY functions is causing this?",
+    "trap": "Without the skill, the model may suggest trying to optimize runtime functions or be unsure how to trace back to application code",
+    "assertions": [
+      {"id": "8.1", "text": "Recommends using `top -cum` to find application functions with high cumulative time"},
+      {"id": "8.2", "text": "Explains that runtime functions appearing in top (flat) are symptoms, not causes — they're called by application code"},
+      {"id": "8.3", "text": "Explains the difference: flat = time in the function itself, cum = time in the function + everything it calls"},
+      {"id": "8.4", "text": "Suggests using `list` or `peek` to drill into the application functions that delegate to these runtime calls"},
+      {"id": "8.5", "text": "Explains the 'flat low + cum high' pattern: the function is a coordinator calling expensive things"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "escape-analysis-interpretation",
+    "description": "Tests ability to use and interpret escape analysis output",
+    "prompt": "My benchmark shows unexpected heap allocations for a function that only uses local variables. How can I find out why Go is allocating on the heap instead of the stack?",
+    "trap": "Without the skill, the model may suggest generic profiling without mentioning the specific compiler flag for escape analysis",
+    "assertions": [
+      {"id": "9.1", "text": "Recommends `go build -gcflags=\"-m\"` to show escape decisions"},
+      {"id": "9.2", "text": "Mentions `-m -m` (double -m) for verbose output showing the escape chain / reason"},
+      {"id": "9.3", "text": "Lists common escape causes like returning pointer to local, interface boxing, closure captures"},
+      {"id": "9.4", "text": "Notes that this analysis is free (compile-time, no runtime overhead)"},
+      {"id": "9.5", "text": "Advises to only investigate escapes in hot functions identified by pprof, not all functions"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "inlining-budget-and-blockers",
+    "description": "Tests knowledge of Go's inlining cost budget and common blockers",
+    "prompt": "I have a small helper function in a hot path that I want the Go compiler to inline. How do I check if it's being inlined, and what might prevent it?",
+    "trap": "Without the skill, the model may not know the specific budget number (80) or all the blockers like defer, recover, go statements",
+    "assertions": [
+      {"id": "10.1", "text": "Recommends `go build -gcflags=\"-m\"` and grepping for 'can inline' or 'cannot inline'"},
+      {"id": "10.2", "text": "Mentions the inline cost budget of 80 (as of Go 1.22+)"},
+      {"id": "10.3", "text": "Lists defer as an inlining blocker"},
+      {"id": "10.4", "text": "Lists recover() as an inlining blocker"},
+      {"id": "10.5", "text": "Mentions that splitting large functions into smaller ones can help the hot inner function inline"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "trace-vs-pprof-selection",
+    "description": "Tests judgment on when to use execution trace vs pprof",
+    "prompt": "My Go HTTP service has high P99 latency (500ms) but pprof CPU profile shows only 15% CPU utilization. The top functions in the CPU profile are all fast. Where is the time going?",
+    "trap": "Without the skill, the model may suggest more CPU profiling or generic optimization, missing that this is a scheduling/blocking problem requiring the execution tracer",
+    "assertions": [
+      {"id": "11.1", "text": "Identifies this as a case where pprof is insufficient — low CPU with high latency means goroutines are waiting, not working"},
+      {"id": "11.2", "text": "Recommends `go tool trace` (execution tracer) to see scheduling delays and blocking"},
+      {"id": "11.3", "text": "Explains that pprof only shows on-CPU time; trace shows off-CPU waiting states"},
+      {"id": "11.4", "text": "Suggests looking at goroutine states: yellow/orange (runnable but waiting for P) or red/pink (blocked on I/O, channel, mutex)"},
+      {"id": "11.5", "text": "Mentions the -pprof=sync or -pprof=net flag to extract blocking profiles from trace data"}
+    ]
+  },
+  {
+    "id": 12,
+    "name": "benchstat-unit-normalization",
+    "description": "Tests understanding of benchstat's automatic unit normalization",
+    "prompt": "I'm confused by benchstat output. My benchmark reports `ns/op` but benchstat shows `sec/op` with a µ prefix. Is this an error?",
+    "trap": "Without the skill, the model may think there's a bug or unit mismatch",
+    "assertions": [
+      {"id": "12.1", "text": "Explains that benchstat automatically normalizes units for display"},
+      {"id": "12.2", "text": "States that ns/op is displayed as sec/op with µ (micro) prefix to avoid nonsensical 'µns/op'"},
+      {"id": "12.3", "text": "Mentions that MB/s is similarly normalized to B/s with K, M, G prefixes"},
+      {"id": "12.4", "text": "Confirms this is expected behavior, not an error"}
+    ]
+  },
+  {
+    "id": 13,
+    "name": "benchstat-filter-syntax",
+    "description": "Tests knowledge of benchstat's filter expression syntax for selecting specific benchmarks",
+    "prompt": "I have benchmark output with many sub-benchmarks like BenchmarkParse/format=json, BenchmarkParse/format=gob, BenchmarkEncode/size=1k, etc. I only want to compare the json format benchmarks. How do I filter benchstat output?",
+    "trap": "Without the skill, the model may suggest grepping the output file instead of using benchstat's built-in filter syntax",
+    "assertions": [
+      {"id": "13.1", "text": "Uses benchstat's -filter flag rather than pre-processing with grep"},
+      {"id": "13.2", "text": "Shows the correct filter syntax: -filter '/format:json' or similar key:value pattern"},
+      {"id": "13.3", "text": "Mentions regex support in filters (e.g., .name:/Parse/)"},
+      {"id": "13.4", "text": "Mentions logical operators (AND, OR, negation with -) in filter expressions"}
+    ]
+  },
+  {
+    "id": 14,
+    "name": "benchstat-projection-col-flag",
+    "description": "Tests knowledge of benchstat's -col flag for comparing sub-benchmark parameters",
+    "prompt": "I have a single benchmark file with results for BenchmarkEncode/format=json and BenchmarkEncode/format=gob. I want to compare json vs gob performance side by side in benchstat. How?",
+    "trap": "Without the skill, the model may suggest splitting into two files and comparing, or not know about the -col flag",
+    "assertions": [
+      {"id": "14.1", "text": "Uses the -col /format flag to create columns from sub-benchmark parameter values"},
+      {"id": "14.2", "text": "Shows the correct command: benchstat -col /format bench.txt"},
+      {"id": "14.3", "text": "Mentions -row .name to simplify row names by stripping sub-benchmark config"},
+      {"id": "14.4", "text": "Mentions the @() sort modifier for controlling column order (e.g., /format@(gob json))"}
+    ]
+  },
+  {
+    "id": 15,
+    "name": "benchstat-assume-exact",
+    "description": "Tests knowledge of benchstat's assume=exact unit metadata for non-varying metrics",
+    "prompt": "I want to track binary size across commits using benchstat. The size doesn't vary between runs (it's deterministic). But benchstat complains about insufficient samples when I use -count=1. How do I handle deterministic metrics?",
+    "trap": "Without the skill, the model may suggest using -count=10 anyway (wasteful for deterministic metrics) or abandoning benchstat",
+    "assertions": [
+      {"id": "15.1", "text": "Recommends the assume=exact unit metadata annotation"},
+      {"id": "15.2", "text": "Shows the syntax: Unit <metric> assume=exact in benchmark output"},
+      {"id": "15.3", "text": "Explains that assume=exact disables non-parametric statistics"},
+      {"id": "15.4", "text": "Notes that benchstat will warn if values vary when assume=exact is set"},
+      {"id": "15.5", "text": "States that single measurement (no -count needed) works with assume=exact"}
+    ]
+  },
+  {
+    "id": 16,
+    "name": "ci-regression-tool-selection",
+    "description": "Tests judgment on which CI regression detection tool to use",
+    "prompt": "I want to add automated benchmark regression detection to my CI pipeline. I need something that:\n1. Compares PR performance against the base branch\n2. Uses statistical analysis (not just single-run comparison)\n3. Integrates with our GitHub Actions workflow\n\nWhat tool should I use?",
+    "trap": "Without the skill, the model may suggest writing a custom script or using only raw benchstat without knowing about benchdiff",
+    "assertions": [
+      {"id": "16.1", "text": "Recommends benchdiff as the primary tool for PR-to-base comparison with statistical rigor"},
+      {"id": "16.2", "text": "Explains that benchdiff uses benchstat internally for statistical analysis"},
+      {"id": "16.3", "text": "Mentions cob as a simpler alternative but notes it uses single-run comparison without benchstat-style statistics"},
+      {"id": "16.4", "text": "Mentions gobenchdata for long-term trend tracking and visualization"},
+      {"id": "16.5", "text": "Explains the tradeoff: benchdiff=high rigor, cob=quick+simple, gobenchdata=trends+dashboard"}
+    ]
+  },
+  {
+    "id": 17,
+    "name": "cob-data-loss-warning",
+    "description": "Tests awareness of cob's destructive behavior with uncommitted changes",
+    "prompt": "I want to use `cob` for quick benchmark regression checking in my local development workflow. Any caveats?",
+    "trap": "Without the skill, the model may recommend cob for local use without the critical safety warning",
+    "assertions": [
+      {"id": "17.1", "text": "Warns that cob uses `git reset` internally which can cause data loss with uncommitted changes"},
+      {"id": "17.2", "text": "Recommends committing all work before running cob"},
+      {"id": "17.3", "text": "Suggests running cob only in CI pipelines, not locally"},
+      {"id": "17.4", "text": "Notes that cob compares single runs without benchstat-style statistics, making it susceptible to noise"},
+      {"id": "17.5", "text": "Mentions [skip cob] commit message convention to bypass checks"}
+    ]
+  },
+  {
+    "id": 18,
+    "name": "noisy-neighbor-mitigation",
+    "description": "Tests knowledge of why CI benchmarks are noisy and mitigation strategies",
+    "prompt": "Our CI benchmark results fluctuate wildly — sometimes showing 15% regression, sometimes 10% improvement, for the same code. We're using GitHub-hosted runners. How do we fix this?",
+    "trap": "Without the skill, the model may suggest tightening thresholds (which causes more false positives) or simply retrying",
+    "assertions": [
+      {"id": "18.1", "text": "Explains that shared CI runners have 5-10% variance due to noisy neighbors"},
+      {"id": "18.2", "text": "Recommends running both base and head benchmarks in the same CI job for relative comparison"},
+      {"id": "18.3", "text": "Recommends using -count=10+ with benchstat to filter noise statistically"},
+      {"id": "18.4", "text": "Suggests conservative thresholds (20%+) on shared runners rather than tight thresholds"},
+      {"id": "18.5", "text": "Warns against 'retry until pass' as selection bias"},
+      {"id": "18.6", "text": "Mentions dedicated/self-hosted runners as the definitive solution for critical benchmarks"}
+    ]
+  },
+  {
+    "id": 19,
+    "name": "self-hosted-runner-tuning",
+    "description": "Tests knowledge of system-level tuning for reproducible benchmarks on self-hosted runners",
+    "prompt": "We have a dedicated self-hosted CI runner for benchmark tests. What system-level settings should we configure to minimize benchmark variance?",
+    "trap": "Without the skill, the model may only suggest generic OS tuning without knowing the specific settings for benchmark stability",
+    "assertions": [
+      {"id": "19.1", "text": "Recommends disabling CPU frequency scaling by setting the 'performance' governor"},
+      {"id": "19.2", "text": "Recommends disabling Turbo Boost (Intel no_turbo or AMD boost)"},
+      {"id": "19.3", "text": "Recommends pinning benchmarks to specific CPU cores using taskset"},
+      {"id": "19.4", "text": "Recommends disabling SMT/Hyper-Threading to avoid execution unit sharing"},
+      {"id": "19.5", "text": "Warns that these settings should ONLY be applied to dedicated runners, never developer machines"}
+    ]
+  },
+  {
+    "id": 20,
+    "name": "taskset-core-pinning-rationale",
+    "description": "Tests understanding of WHY core pinning helps benchmarks",
+    "prompt": "Why does pinning a Go benchmark to specific CPU cores with taskset help reduce variance? What's the underlying mechanism?",
+    "trap": "Without the skill, the model may give a vague answer about CPU contention without explaining the cache thrashing mechanism",
+    "assertions": [
+      {"id": "20.1", "text": "Explains that without pinning, the OS migrates the process across cores"},
+      {"id": "20.2", "text": "Explains that L1/L2 caches are per-core, so migration causes cache thrashing"},
+      {"id": "20.3", "text": "Recommends leaving cores 0-1 for OS and other processes, using cores 2+ for benchmarks"},
+      {"id": "20.4", "text": "Shows the taskset command syntax (e.g., taskset -c 2,3 go test ...)"}
+    ]
+  },
+  {
+    "id": 21,
+    "name": "b-report-metric-custom",
+    "description": "Tests knowledge of b.ReportMetric and b.Elapsed for custom benchmark metrics",
+    "prompt": "I want my Go benchmark to report throughput in bytes/second in addition to the standard ns/op. How do I add custom metrics to benchmark output?",
+    "trap": "Without the skill, the model may suggest manual calculation and fmt.Printf instead of the built-in b.ReportMetric",
+    "assertions": [
+      {"id": "21.1", "text": "Uses b.ReportMetric() to add custom metrics"},
+      {"id": "21.2", "text": "Uses b.Elapsed() to get the total benchmark duration"},
+      {"id": "21.3", "text": "Shows the correct pattern: b.ReportMetric(float64(bytes)/b.Elapsed().Seconds(), \"bytes/s\")"},
+      {"id": "21.4", "text": "The custom metric integrates with standard benchmark output format (not separate print statements)"}
+    ]
+  },
+  {
+    "id": 22,
+    "name": "alloc-space-cumulative-trap-for-leak",
+    "description": "Tests that alloc_space is cumulative (includes freed objects) and therefore wrong for leak detection",
+    "prompt": "My Go service's memory keeps growing. I captured a heap profile with:\n\ngo tool pprof -alloc_space http://localhost:6060/debug/pprof/heap\n\nThe top functions show my database layer allocating hundreds of MBs. But when I check the actual process RSS, most of that memory has already been freed. Am I reading this profile correctly?",
+    "trap": "Without the skill, the model validates the use of alloc_space for leak detection, missing that alloc_space is cumulative since program start and includes objects already freed by GC — inuse_space is the correct choice for leak detection",
+    "assertions": [
+      {"id": "22.1", "text": "Explains that alloc_space is cumulative since program start — it counts ALL allocations including those already freed by GC"},
+      {"id": "22.2", "text": "Identifies that alloc_space is the wrong profile type for leak detection because freed memory still appears"},
+      {"id": "22.3", "text": "Recommends inuse_space instead — it shows only currently live heap objects, making leaked objects visible"},
+      {"id": "22.4", "text": "Explains the correct leak detection workflow: take two inuse_space snapshots separated by time and compare with pprof -base"},
+      {"id": "22.5", "text": "Mentions common leak causes: unbounded caches, maps that never shrink, goroutine leaks holding references"}
+    ]
+  },
+  {
+    "id": 23,
+    "name": "mutex-block-profile-enablement",
+    "description": "Tests awareness that mutex and block profiles must be explicitly enabled",
+    "prompt": "I want to profile mutex contention in my Go service. I fetched the mutex profile from /debug/pprof/mutex but it's empty. What's wrong?",
+    "trap": "Without the skill, the model may suggest the endpoint is broken or suggest different debugging approaches",
+    "assertions": [
+      {"id": "23.1", "text": "Identifies that mutex profiling is disabled by default and must be explicitly enabled"},
+      {"id": "23.2", "text": "Shows runtime.SetMutexProfileFraction() as the enablement call"},
+      {"id": "23.3", "text": "Explains the fraction parameter (e.g., 5 means 1 out of 5 events recorded)"},
+      {"id": "23.4", "text": "Recommends disabling after investigation (SetMutexProfileFraction(0)) to eliminate overhead"},
+      {"id": "23.5", "text": "Mentions runtime.SetBlockProfileRate() for the related block profile"}
+    ]
+  },
+  {
+    "id": 24,
+    "name": "trace-custom-annotations",
+    "description": "Tests knowledge of runtime/trace custom annotations (tasks, regions, logs)",
+    "prompt": "I'm using go tool trace to analyze my HTTP handler but the trace timeline only shows generic goroutine activity. How can I add application-level context to see which request phases (validation, database query, serialization) are taking time?",
+    "trap": "Without the skill, the model may suggest using log statements or pprof labels instead of trace-specific annotations",
+    "assertions": [
+      {"id": "24.1", "text": "Recommends trace.NewTask for logical operations that may span goroutines"},
+      {"id": "24.2", "text": "Recommends trace.WithRegion for phases within a task or goroutine"},
+      {"id": "24.3", "text": "Mentions trace.Log for point-in-time markers in the trace"},
+      {"id": "24.4", "text": "Shows correct usage with context propagation (ctx parameter)"},
+      {"id": "24.5", "text": "Notes that annotations add negligible overhead when tracing is disabled"}
+    ]
+  },
+  {
+    "id": 25,
+    "name": "trace-gc-phase-interpretation",
+    "description": "Tests ability to interpret GC phases in execution traces",
+    "prompt": "I'm looking at an execution trace and I see large blocks of time where my goroutines show as 'GC assist' (blue). What does this mean and how do I fix it?",
+    "trap": "Without the skill, the model may not explain the proportional allocation tax mechanism or the specific remediation",
+    "assertions": [
+      {"id": "25.1", "text": "Explains that GC mark assist means goroutines are being drafted by the GC to help scan the heap"},
+      {"id": "25.2", "text": "Explains that the runtime forces goroutines to assist in proportion to their allocation rate — heavy allocators get taxed more"},
+      {"id": "25.3", "text": "Identifies this as a symptom of too many allocations, not a GC configuration problem"},
+      {"id": "25.4", "text": "Recommends reducing allocation rate (the root cause) rather than tuning GOGC"},
+      {"id": "25.5", "text": "Distinguishes mark assist from STW (stop-the-world) phases which affect all goroutines equally"}
+    ]
+  },
+  {
+    "id": 26,
+    "name": "trace-pprof-extraction",
+    "description": "Tests knowledge of extracting pprof profiles from trace data",
+    "prompt": "I have an execution trace file from a production service. I want to find which functions are responsible for the most network blocking time. Can I use the trace for this?",
+    "trap": "Without the skill, the model may suggest capturing a separate pprof profile instead of extracting from the trace",
+    "assertions": [
+      {"id": "26.1", "text": "Uses `go tool trace -pprof=net trace.out > net.prof` to extract a network blocking profile"},
+      {"id": "26.2", "text": "Then uses go tool pprof on the extracted profile for analysis (top, list, etc.)"},
+      {"id": "26.3", "text": "Mentions other extractable profile types: sync, syscall, sched"},
+      {"id": "26.4", "text": "Explains this bridges trace data (nanosecond events) with pprof analysis (statistical aggregation)"}
+    ]
+  },
+  {
+    "id": 27,
+    "name": "fieldalignment-no-autofix",
+    "description": "Tests that the model uses fieldalignment without the -fix flag",
+    "prompt": "I suspect some of my Go structs have suboptimal field ordering causing padding waste. How do I check?",
+    "trap": "Without the skill, the model may suggest using fieldalignment with -fix flag or structlayout without the diagnostic-first approach",
+    "assertions": [
+      {"id": "27.1", "text": "Recommends running `fieldalignment ./...` to detect padding waste"},
+      {"id": "27.2", "text": "Does NOT use the -fix flag — the skill explicitly says to let the agent apply changes manually"},
+      {"id": "27.3", "text": "Mentions using unsafe.Sizeof/Alignof/Offsetof to inspect struct layout before and after"},
+      {"id": "27.4", "text": "Treats this as a diagnostic step, not an automatic fix"}
+    ]
+  },
+  {
+    "id": 28,
+    "name": "godebug-gctrace-output-interpretation",
+    "description": "Tests ability to read and interpret a GODEBUG=gctrace=1 output line",
+    "prompt": "I ran my Go service with GODEBUG=gctrace=1 and see lines like:\n\ngc 14 @5.234s 2%: 0.13+1.4+0.21 ms clock, 0.53+0.43/1.1/0+0.85 ms cpu, 24->27->13 MB, 24 MB goal, 0 MB stacks, 0 MB globals, 4 P\n\nWhat does each field mean? Is this GC behavior healthy?",
+    "trap": "Without the skill, the model knows GODEBUG=gctrace exists but cannot interpret the specific output format fields — it guesses or gives vague descriptions",
+    "assertions": [
+      {"id": "28.1", "text": "Identifies 'gc 14' as the GC cycle number"},
+      {"id": "28.2", "text": "Identifies '@5.234s 2%' as time since program start and CPU percentage spent in GC"},
+      {"id": "28.3", "text": "Identifies '24->27->13 MB' as heap size before GC, heap size at GC trigger, and live heap after GC"},
+      {"id": "28.4", "text": "Identifies '24 MB goal' as the target heap size for the next GC cycle based on the GC pacing algorithm"},
+      {"id": "28.5", "text": "Assesses health: 2% CPU in GC is acceptable (generally <5% is fine); 13MB live vs 24MB goal means 46% overhead headroom"}
+    ]
+  },
+  {
+    "id": 29,
+    "name": "runtime-scanobject-cpu-diagnosis",
+    "description": "Tests interpretation of runtime.scanobject appearing high in CPU profile",
+    "prompt": "My CPU profile shows `runtime.scanobject` consuming 25% of CPU time. What does this mean and how do I reduce it?",
+    "trap": "Without the skill, the model may not recognize this as a GC pointer scanning issue or may suggest wrong remediation",
+    "assertions": [
+      {"id": "29.1", "text": "Identifies runtime.scanobject as GC pointer scanning — the GC is tracing pointers in the heap"},
+      {"id": "29.2", "text": "Explains that the heap contains many pointers that the GC must trace"},
+      {"id": "29.3", "text": "Recommends reducing pointer density: value types instead of pointers in slices/maps"},
+      {"id": "29.4", "text": "Suggests flattening nested structures or using [N]byte arrays instead of strings in hot structs"},
+      {"id": "29.5", "text": "References the golang-performance skill for optimization patterns"}
+    ]
+  },
+  {
+    "id": 30,
+    "name": "top-cum-for-application-callsites",
+    "description": "Tests that top -cum is the correct command to find application code when runtime symbols dominate flat profile",
+    "prompt": "I ran `go tool pprof cpu.prof` and typed `top`. The output is dominated by runtime functions:\n\n1. runtime.memmove  18%\n2. runtime.mallocgc  14%\n3. runtime.gcWriteBarrier  9%\n\nNone of my application code appears in the top 10. My CPU overhead is high. What pprof command should I run next?",
+    "trap": "Without the skill, the model suggests using `web` for the graph view, `list` on a runtime function, or other commands — missing that `top -cum` reveals the application callers who are responsible",
+    "assertions": [
+      {"id": "30.1", "text": "Recommends running `top -cum` (cumulative mode) as the immediate next command"},
+      {"id": "30.2", "text": "Explains that flat time shows where CPU is spent directly; cumulative time shows which application functions called into the expensive runtime functions"},
+      {"id": "30.3", "text": "Explains that runtime.memmove, mallocgc, gcWriteBarrier are symptoms — the application code that triggers them will have high cumulative time"},
+      {"id": "30.4", "text": "Suggests using `list FunctionName` on the top cumulative callers to see the exact lines triggering the expensive runtime calls"},
+      {"id": "30.5", "text": "Does NOT suggest trying to optimize the runtime functions directly"}
+    ]
+  },
+  {
+    "id": 31,
+    "name": "fgprof-off-cpu-profiling",
+    "description": "Tests knowledge of fgprof for capturing off-CPU time that pprof misses",
+    "prompt": "My Go service has high latency but the CPU profile barely shows any CPU usage. Standard pprof doesn't reveal where time is spent. What tool captures both on-CPU and off-CPU time in a single profile?",
+    "trap": "Without the skill, the model may suggest only the execution tracer or not know about fgprof",
+    "assertions": [
+      {"id": "31.1", "text": "Recommends fgprof (github.com/felixge/fgprof) for full goroutine profiling"},
+      {"id": "31.2", "text": "Explains that fgprof captures both on-CPU and off-CPU (I/O wait) time in a single profile"},
+      {"id": "31.3", "text": "Explains that standard pprof CPU profiles only show on-CPU time, missing I/O waits"},
+      {"id": "31.4", "text": "Describes the use case: pprof shows low CPU% but latency is high"}
+    ]
+  },
+  {
+    "id": 32,
+    "name": "flight-recorder-go125",
+    "description": "Tests knowledge of the Go 1.25 flight recorder for retroactive trace capture",
+    "prompt": "My Go service occasionally experiences timeout spikes but I can't reproduce them. By the time I notice and start tracing, the problem is gone. Is there a way to capture trace data retroactively for these intermittent issues?",
+    "trap": "Without the skill, the model may suggest continuous tracing (too expensive) or instrumented logging",
+    "assertions": [
+      {"id": "32.1", "text": "Recommends the Go 1.25 flight recorder (trace.NewFlightRecorder)"},
+      {"id": "32.2", "text": "Explains it keeps a circular buffer of recent trace data in memory"},
+      {"id": "32.3", "text": "Shows snapshotting with WriteTo when the anomaly is detected"},
+      {"id": "32.4", "text": "Mentions the MinAge and MaxBytes configuration parameters"},
+      {"id": "32.5", "text": "Shows a trigger pattern (e.g., slow request detection with time.Since threshold)"},
+      {"id": "32.6", "text": "Notes the constraint: at most one flight recorder active at a time"}
+    ]
+  },
+  {
+    "id": 33,
+    "name": "flight-recorder-sync-once-pattern",
+    "description": "Tests the sync.Once pattern for flight recorder snapshots",
+    "prompt": "I'm setting up a flight recorder in my Go service. I want to snapshot it when a slow request is detected, but multiple goroutines might detect slow requests simultaneously. How do I prevent multiple overlapping snapshots?",
+    "trap": "Without the skill, the model may use a mutex or channel instead of the idiomatic sync.Once pattern",
+    "assertions": [
+      {"id": "33.1", "text": "Uses sync.Once to ensure only one snapshot is taken"},
+      {"id": "33.2", "text": "Calls fr.WriteTo inside the sync.Once.Do function"},
+      {"id": "33.3", "text": "Notes that only one goroutine may call WriteTo at a time"},
+      {"id": "33.4", "text": "Shows calling the snapshot in a separate goroutine (go captureSnapshot)"},
+      {"id": "33.5", "text": "Shows fr.Stop() after WriteTo completes"}
+    ]
+  },
+  {
+    "id": 34,
+    "name": "flight-recorder-sizing",
+    "description": "Tests understanding of flight recorder buffer sizing",
+    "prompt": "I'm configuring a flight recorder for my Go service. My typical investigation window when a timeout occurs is about 5 seconds. How should I size the MinAge and MaxBytes parameters?",
+    "trap": "Without the skill, the model may guess arbitrary values without the 2x rule or data rate context",
+    "assertions": [
+      {"id": "34.1", "text": "Sets MinAge to ~2x the problem window (10 seconds for a 5-second investigation window)"},
+      {"id": "34.2", "text": "Mentions that busy services generate ~1-10 MB/s of trace data"},
+      {"id": "34.3", "text": "Recommends starting MaxBytes at 1-5 MiB and adjusting"},
+      {"id": "34.4", "text": "Explains that MaxBytes takes precedence over MinAge — when buffer fills, older data is discarded"}
+    ]
+  },
+  {
+    "id": 35,
+    "name": "trace-timeline-color-coding",
+    "description": "Tests ability to interpret execution trace timeline colors",
+    "prompt": "I opened an execution trace in the web UI. I see lots of yellow/orange gaps before green segments on my goroutine lanes, and some red bands spanning all processor lanes. What does this indicate?",
+    "trap": "Without the skill, the model may not know the specific color coding of the trace viewer",
+    "assertions": [
+      {"id": "35.1", "text": "Identifies yellow/orange as runnable state — goroutines ready to run but waiting for a processor"},
+      {"id": "35.2", "text": "Identifies red bands across all P lanes as GC stop-the-world pauses"},
+      {"id": "35.3", "text": "Diagnoses the yellow gaps as CPU saturation — too many runnable goroutines competing for processors"},
+      {"id": "35.4", "text": "Identifies green as actively executing/running state"},
+      {"id": "35.5", "text": "Suggests examining goroutine count vs GOMAXPROCS to verify CPU saturation"}
+    ]
+  },
+  {
+    "id": 36,
+    "name": "pprof-labels-tagfocus-multitenant",
+    "description": "Tests knowledge of pprof.Do() custom labels and tagfocus for isolating a specific request type in a mixed-workload profile",
+    "prompt": "My Go service handles both API requests and batch jobs in the same process. CPU profiles mix both workloads together so I can't tell if API or batch is causing GC pressure. How can I profile only the API request code path?",
+    "trap": "Without the skill, the model suggests running a separate dedicated process for each workload, or using separate profiles — missing pprof.Do() labels with -tagfocus filtering which solves this in a single profile",
+    "assertions": [
+      {"id": "36.1", "text": "Recommends using pprof.Do() with pprof.Labels() to tag goroutines with a request_type label"},
+      {"id": "36.2", "text": "Shows the pattern: pprof.Do(ctx, pprof.Labels(\"request_type\", \"api\"), func(ctx context.Context) { ... })"},
+      {"id": "36.3", "text": "Shows using -tagfocus=request_type=api when analyzing the profile to filter to only API samples"},
+      {"id": "36.4", "text": "Explains that labels are inherited by the goroutine's profile samples — no need for separate processes"},
+      {"id": "36.5", "text": "Mentions the tags command in pprof interactive mode to see all label keys and their value distributions"}
+    ]
+  },
+  {
+    "id": 37,
+    "name": "pprof-focus-ignore-difference",
+    "description": "Tests understanding of the difference between pprof's focus, ignore, show, and hide filters",
+    "prompt": "In pprof, what's the difference between `focus`, `ignore`, `show`, and `hide`? When would I use each one?",
+    "trap": "Without the skill, the model may confuse the cost accounting behavior of these filters",
+    "assertions": [
+      {"id": "37.1", "text": "Explains that focus keeps only paths containing a matching function — everything else dropped"},
+      {"id": "37.2", "text": "Explains that ignore removes matching functions entirely, attributing their costs to callers"},
+      {"id": "37.3", "text": "Explains that show is like focus but only affects display, not cost accounting"},
+      {"id": "37.4", "text": "Explains that hide is like ignore but only hides from display, not cost accounting"},
+      {"id": "37.5", "text": "Mentions `reset` to clear all filters"}
+    ]
+  },
+  {
+    "id": 38,
+    "name": "pprof-tags-and-labels",
+    "description": "Tests knowledge of pprof custom labels via pprof.Do() for multi-tenant profiling",
+    "prompt": "I want to break down my CPU profile by request type (API vs batch). How can I add custom labels to pprof samples so I can filter and group by request type?",
+    "trap": "Without the skill, the model may suggest separate profiles per request type instead of using pprof labels",
+    "assertions": [
+      {"id": "38.1", "text": "Uses pprof.Labels() and pprof.Do() to add custom labels to profiled code"},
+      {"id": "38.2", "text": "Shows the correct pattern: pprof.Do(ctx, pprof.Labels(\"key\", \"value\"), func(ctx context.Context) {...})"},
+      {"id": "38.3", "text": "Shows using tagfocus to filter by label (e.g., -tagfocus=request_type=api)"},
+      {"id": "38.4", "text": "Shows using tagroot to group by label (e.g., -tagroot=request_type)"},
+      {"id": "38.5", "text": "Mentions the tags command to see all tag keys and distributions"}
+    ]
+  },
+  {
+    "id": 39,
+    "name": "pprof-sample-index-switching",
+    "description": "Tests knowledge of switching between metric types in a heap profile without reloading",
+    "prompt": "I opened a heap profile in pprof interactive mode and I'm looking at alloc_objects. Now I want to also see inuse_space. Do I need to exit and reopen with different flags?",
+    "trap": "Without the skill, the model may suggest exiting and reopening with a different flag",
+    "assertions": [
+      {"id": "39.1", "text": "Uses sample_index command to switch metrics without reloading"},
+      {"id": "39.2", "text": "Shows the correct syntax: sample_index=inuse_space"},
+      {"id": "39.3", "text": "Lists available indices: alloc_objects, alloc_space, inuse_objects, inuse_space"},
+      {"id": "39.4", "text": "Explains that heap profiles contain multiple metrics and you can switch between them interactively"}
+    ]
+  },
+  {
+    "id": 40,
+    "name": "pprof-granularity-lines",
+    "description": "Tests knowledge of pprof granularity control for multi-hot-spot functions",
+    "prompt": "I used `list` on a function and it shows two expensive lines, but the `top` output only shows the function name once with aggregated cost. How can I see per-line costs in the top output?",
+    "trap": "Without the skill, the model may only suggest using list for per-line analysis",
+    "assertions": [
+      {"id": "40.1", "text": "Uses granularity=lines to group by exact source line in top output"},
+      {"id": "40.2", "text": "Mentions other granularity levels: functions (default), filefunctions, files, addresses"},
+      {"id": "40.3", "text": "Shows the command: either `granularity=lines` in interactive mode or `-granularity=lines` as flag"}
+    ]
+  },
+  {
+    "id": 41,
+    "name": "ssa-dump-investigation",
+    "description": "Tests knowledge of SSA dump for understanding compiler optimization passes",
+    "prompt": "I want to understand exactly what optimizations the Go compiler applies to a specific function. I need more detail than escape analysis or inlining flags provide. Is there a way to see the compiler's intermediate representation?",
+    "trap": "Without the skill, the model may not know about the GOSSAFUNC environment variable",
+    "assertions": [
+      {"id": "41.1", "text": "Uses GOSSAFUNC=FunctionName go build to generate SSA dump"},
+      {"id": "41.2", "text": "Mentions that it creates ssa.html which can be opened in a browser"},
+      {"id": "41.3", "text": "Describes the optimization passes visible: source, AST, start SSA, optimization, lower, regalloc, genssa"},
+      {"id": "41.4", "text": "Mentions what to look for: remaining bounds checks, dead code elimination, constant folding, register spills"},
+      {"id": "41.5", "text": "Mentions clicking on values to highlight them across passes"}
+    ]
+  },
+  {
+    "id": 42,
+    "name": "noinlines-inlined-function-attribution",
+    "description": "Tests that noinlines aggregates inlined function costs to the outer non-inlined caller",
+    "prompt": "My pprof call graph is cluttered. A single hot function has been inlined into 6 different callers, so its cost is split across 6 separate nodes in the graph. I want to see the aggregated cost in one place. What pprof option should I use?",
+    "trap": "Without the skill, the model suggests using show/hide filters or focus (which change display but not cost aggregation) or ignoring inlined nodes — missing the noinlines option which correctly attributes inlined function costs to their first out-of-line caller",
+    "assertions": [
+      {"id": "42.1", "text": "Recommends the noinlines option (or -noinlines flag)"},
+      {"id": "42.2", "text": "Explains that noinlines attributes inlined function costs to their first out-of-line caller — the inlined nodes are collapsed"},
+      {"id": "42.3", "text": "Shows correct usage: noinlines in interactive mode or -noinlines as CLI flag"},
+      {"id": "42.4", "text": "Distinguishes noinlines from hide/ignore: hide/ignore only affect display without changing cost attribution"}
+    ]
+  },
+  {
+    "id": 43,
+    "name": "receiver-choice-inlining-and-escape-tradeoffs",
+    "description": "Tests knowledge that receiver choice can affect copying, aliasing, escape analysis, and inlining, but must be verified",
+    "prompt": "I'm designing a fluent API for a small config builder in a performance-sensitive path. Should I use value receivers or pointer receivers for the method chain? Consider both correctness and compiler optimization.",
+    "trap": "Without the skill, the model defaults to pointer receivers for method chains without considering inlining implications",
+    "assertions": [
+      {"id": "43.1", "text": "Mentions that receiver choice can affect copying, aliasing, escape analysis, and inlining"},
+      {"id": "43.2", "text": "Does NOT claim that pointer receivers categorically block inlining or that value receivers guarantee full inlining"},
+      {"id": "43.3", "text": "Recommends checking with -gcflags=\"-m -m\" to verify inlining and escape behavior"},
+      {"id": "43.4", "text": "Considers both the performance trade-off and the struct size (value receivers copy the struct)"}
+    ]
+  },
+  {
+    "id": 44,
+    "name": "prometheus-go-metrics-vs-runtime-metrics",
+    "description": "Tests understanding that runtime/metrics are NOT the same as Prometheus metrics",
+    "prompt": "I want to monitor Go runtime metrics in my Prometheus dashboard. Can I just use Go's runtime/metrics package directly in my PromQL queries?",
+    "trap": "Without the skill, the model may conflate runtime/metrics keys with Prometheus metric names",
+    "assertions": [
+      {"id": "44.1", "text": "Clarifies that runtime/metrics are Go internal data structures, not Prometheus metrics"},
+      {"id": "44.2", "text": "Explains that prometheus/client_golang selectively converts some runtime/metrics into Prometheus format"},
+      {"id": "44.3", "text": "Lists the actual Prometheus metric names (e.g., go_memstats_alloc_bytes, go_goroutines)"},
+      {"id": "44.4", "text": "Mentions that by default only traditional go_memstats_* and go_gc_* are exposed"}
+    ]
+  },
+  {
+    "id": 45,
+    "name": "go-memstats-stw-overhead",
+    "description": "Tests awareness of ReadMemStats causing stop-the-world pauses",
+    "prompt": "I'm using prometheus/client_golang to expose Go runtime metrics. My high-throughput service occasionally shows brief latency spikes correlated with Prometheus scrape intervals. Could the metrics collection itself be causing this?",
+    "trap": "Without the skill, the model may not connect metrics collection to STW pauses",
+    "assertions": [
+      {"id": "45.1", "text": "Identifies that go_memstats_* metrics internally call runtime.ReadMemStats() which triggers a short stop-the-world pause"},
+      {"id": "45.2", "text": "Recommends the Go 1.17+ runtime/metrics-based collector as lower overhead alternative"},
+      {"id": "45.3", "text": "Shows the code to register the modern collector: collectors.NewGoCollector(collectors.WithGoCollectorRuntimeMetrics(collectors.MetricsAll)) or specific runtime metric rules"},
+      {"id": "45.4", "text": "Recommends using a custom prometheus.NewRegistry() rather than the default one"}
+    ]
+  },
+  {
+    "id": 46,
+    "name": "promql-gc-pressure-queries",
+    "description": "Tests knowledge of specific PromQL queries for GC pressure investigation",
+    "prompt": "I suspect my Go service has excessive GC pressure. What Prometheus queries should I use to confirm this and find the root cause?",
+    "trap": "Without the skill, the model may suggest generic monitoring queries without the specific GC-related PromQL",
+    "assertions": [
+      {"id": "46.1", "text": "Uses rate(go_gc_duration_seconds_count[5m]) for GC frequency (cycles per second)"},
+      {"id": "46.2", "text": "States that >2 GC cycles/s sustained indicates excessive allocation rate"},
+      {"id": "46.3", "text": "Uses go_gc_duration_seconds{quantile=\"1\"} for worst-case GC pause"},
+      {"id": "46.4", "text": "Uses rate(go_memstats_alloc_bytes_total[5m]) for allocation rate comparison before/after deploy"},
+      {"id": "46.5", "text": "Recommends correlating with P99 latency to confirm GC pauses cause tail latency"}
+    ]
+  },
+  {
+    "id": 47,
+    "name": "promql-goroutine-leak-detection",
+    "description": "Tests specific PromQL patterns for detecting goroutine leaks",
+    "prompt": "How do I detect goroutine leaks in my production Go service using Prometheus metrics?",
+    "trap": "Without the skill, the model may suggest only looking at the absolute go_goroutines count without the delta pattern",
+    "assertions": [
+      {"id": "47.1", "text": "Uses go_goroutines gauge for current count"},
+      {"id": "47.2", "text": "Uses delta(go_goroutines[1h]) for net goroutine change — positive without load increase indicates leak"},
+      {"id": "47.3", "text": "Notes that goroutine count should correlate with load — independent growth is a leak signal"},
+      {"id": "47.4", "text": "Suggests an alerting rule with threshold (e.g., go_goroutines > 10000)"}
+    ]
+  },
+  {
+    "id": 48,
+    "name": "investigation-session-setup",
+    "description": "Tests the structured approach to production performance investigation sessions",
+    "prompt": "I need to do a deep-dive performance investigation on one instance of my Go service in production. What should I set up before I start collecting profiles?",
+    "trap": "Without the skill, the model may jump straight to pprof without the investigation session preparation",
+    "assertions": [
+      {"id": "48.1", "text": "Recommends reducing Prometheus scrape interval to <=10s on the target instance"},
+      {"id": "48.2", "text": "Recommends enabling pprof via environment variable without recompile"},
+      {"id": "48.3", "text": "Recommends enabling continuous profiling on only the target instance, not fleet-wide"},
+      {"id": "48.4", "text": "Emphasizes reverting all changes after investigation"},
+      {"id": "48.5", "text": "Mentions the key design principle: all debug features should be toggleable via environment variables"}
+    ]
+  },
+  {
+    "id": 49,
+    "name": "cost-warnings-trace-duration",
+    "description": "Tests awareness of the cost and practical limits of execution traces",
+    "prompt": "I want to capture a 5-minute execution trace of my Go service to analyze a periodic issue that happens every 2-3 minutes. Is this feasible?",
+    "trap": "Without the skill, the model may agree to a 5-minute trace without warning about data volume",
+    "assertions": [
+      {"id": "49.1", "text": "Warns that traces generate data at MB/s — a 5-minute trace would be enormous (potentially GBs)"},
+      {"id": "49.2", "text": "Recommends keeping traces to 5-10 seconds maximum"},
+      {"id": "49.3", "text": "Warns that large traces are slow to parse and may need 1GB+ RAM to open"},
+      {"id": "49.4", "text": "Suggests using the flight recorder (Go 1.25+) as an alternative for intermittent issues"},
+      {"id": "49.5", "text": "Notes that the browser UI struggles with traces >100MB"}
+    ]
+  },
+  {
+    "id": 50,
+    "name": "benchstat-three-version-comparison",
+    "description": "Tests knowledge of comparing more than two versions with benchstat",
+    "prompt": "I have benchmark results from three different versions of my code (v1, v2, v3). I want to compare all three in a single benchstat output. How?",
+    "trap": "Without the skill, the model may suggest running benchstat twice for pairwise comparisons",
+    "assertions": [
+      {"id": "50.1", "text": "Shows labeling inputs: benchstat v1=v1.txt v2=v2.txt v3=v3.txt"},
+      {"id": "50.2", "text": "Explains that the first input is always the base for comparison"},
+      {"id": "50.3", "text": "States that v2 vs v1 and v3 vs v1 comparisons are shown (both relative to first input)"}
+    ]
+  },
+  {
+    "id": 51,
+    "name": "host-level-correlation",
+    "description": "Tests awareness of correlating Go metrics with host-level metrics",
+    "prompt": "My Go service shows high process_cpu_seconds_total but the CPU profile looks normal. Could the problem be outside my application?",
+    "trap": "Without the skill, the model may only investigate within the Go application",
+    "assertions": [
+      {"id": "51.1", "text": "Recommends checking node_exporter metrics for host-level CPU, memory, disk I/O"},
+      {"id": "51.2", "text": "Explains the noisy neighbor pattern: high node_cpu with low process_cpu = external contention"},
+      {"id": "51.3", "text": "Mentions process-exporter for per-process metrics when multiple services share a host"},
+      {"id": "51.4", "text": "Suggests correlating Go app metrics with infrastructure metrics to determine if the problem is in the app or the environment"}
+    ]
+  },
+  {
+    "id": 52,
+    "name": "pprof-diff-base-vs-base",
+    "description": "Tests understanding of -base vs -diff_base flags in pprof for comparison",
+    "prompt": "I want to compare two CPU profiles — one before and one after my optimization. What's the difference between `pprof -base` and `pprof -diff_base`?",
+    "trap": "Without the skill, the model may not know both flags exist or may confuse their semantics",
+    "assertions": [
+      {"id": "52.1", "text": "Explains that -base subtracts base from source — all values become deltas"},
+      {"id": "52.2", "text": "Explains that -diff_base shows percentages relative to the base profile"},
+      {"id": "52.3", "text": "Mentions -normalize flag for making ratios comparable when capture durations differ"},
+      {"id": "52.4", "text": "Shows how to generate a diff SVG for visual comparison"}
+    ]
+  },
+  {
+    "id": 53,
+    "name": "gobenchdata-github-action-setup",
+    "description": "Tests knowledge of setting up gobenchdata for long-term trend tracking",
+    "prompt": "I want to track benchmark performance trends over time with an interactive web dashboard. I'm using GitHub Actions. What's the best approach?",
+    "trap": "Without the skill, the model may suggest building a custom dashboard or only using benchstat",
+    "assertions": [
+      {"id": "53.1", "text": "Recommends gobenchdata for trend tracking and visualization"},
+      {"id": "53.2", "text": "Shows the GitHub Action configuration with bobheadxi/gobenchdata@v1"},
+      {"id": "53.3", "text": "Mentions publishing to gh-pages for the dashboard"},
+      {"id": "53.4", "text": "Shows the regression checks config (.gobenchdata-checks.yml) with thresholds"},
+      {"id": "53.5", "text": "Mentions PRUNE_COUNT to limit stored history"}
+    ]
+  },
+  {
+    "id": 54,
+    "name": "benchstat-single-file-summary",
+    "description": "Tests knowledge of using benchstat with a single file for variance analysis",
+    "prompt": "I haven't made any code changes yet. I just want to check if my benchmarks are stable (low variance) before I start optimizing. Can benchstat help?",
+    "trap": "Without the skill, the model may say benchstat requires two files for comparison",
+    "assertions": [
+      {"id": "54.1", "text": "Shows running benchstat with a single file: benchstat bench.txt"},
+      {"id": "54.2", "text": "Explains it shows median and confidence interval for each benchmark"},
+      {"id": "54.3", "text": "Recommends using this to check measurement stability before making changes"},
+      {"id": "54.4", "text": "Notes that high variance (± >5%) indicates noisy benchmarks needing more runs or better isolation"}
+    ]
+  },
+  {
+    "id": 55,
+    "name": "count-minimum-by-scenario",
+    "description": "Tests knowledge of appropriate -count values for different scenarios",
+    "prompt": "How many benchmark iterations (-count) should I use? I've seen recommendations ranging from 1 to 30.",
+    "trap": "Without the skill, the model may give a single number without context-dependent guidance",
+    "assertions": [
+      {"id": "55.1", "text": "Recommends 6 minimum for quick local checks"},
+      {"id": "55.2", "text": "Recommends 10 for standard pre-merge comparisons"},
+      {"id": "55.3", "text": "Recommends 20-30 for detecting small changes (<5%)"},
+      {"id": "55.4", "text": "Recommends 20+ for noisy CI environments"},
+      {"id": "55.5", "text": "Explicitly warns against -count=1 as providing no variance information"}
+    ]
+  },
+  {
+    "id": 56,
+    "name": "closure-capturing-pointer-escape",
+    "description": "Tests understanding of a subtle escape: a closure capturing a loop variable forces the variable to escape to the heap even when no interface boxing occurs",
+    "prompt": "I have a benchmark and escape analysis shows these local integer variables escaping to the heap:\n\n```go\nfor i := 0; i < 10; i++ {\n    val := computeValue(i)\n    go func() {\n        results[i] = val\n    }()\n}\n```\n\nWhy do `i` and `val` escape to the heap? There are no interface conversions here.",
+    "trap": "Without the skill, the model explains interface boxing (which isn't happening here) or vaguely mentions 'closures cause escapes' without explaining the specific mechanism: the goroutine may outlive the enclosing function, so any variable the closure captures must be heap-allocated to remain accessible",
+    "assertions": [
+      {"id": "56.1", "text": "Explains that the goroutine launched with `go func()` may outlive the enclosing function"},
+      {"id": "56.2", "text": "Explains that any variable captured by a closure that escapes (e.g., via goroutine launch or return) must be heap-allocated to remain accessible after the outer function returns"},
+      {"id": "56.3", "text": "Identifies the specific escape cause: `go func()` body references `val` and `i`, so both variables escape via closure capture"},
+      {"id": "56.4", "text": "Distinguishes this from interface boxing — this escape is purely lifetime-based, not type-conversion based"},
+      {"id": "56.5", "text": "Suggests passing variables as arguments to the goroutine function to break the closure capture and avoid escape"}
+    ]
+  },
+  {
+    "id": 57,
+    "name": "trace-scheduling-latency-diagnosis",
+    "description": "Tests ability to diagnose scheduling latency from trace data",
+    "prompt": "My execution trace shows many goroutines spending significant time in the 'runnable' (yellow) state before becoming 'running' (green). What does this mean and how do I fix it?",
+    "trap": "Without the skill, the model may not connect runnable-to-running delay with CPU saturation",
+    "assertions": [
+      {"id": "57.1", "text": "Identifies this as high scheduling latency — goroutines ready to run but waiting for a processor"},
+      {"id": "57.2", "text": "Diagnoses the cause: too many goroutines competing for GOMAXPROCS processors (CPU saturation)"},
+      {"id": "57.3", "text": "Suggests extracting the scheduling latency profile: go tool trace -pprof=sched trace.out"},
+      {"id": "57.4", "text": "Recommends checking for uneven distribution across Ps (work imbalance)"},
+      {"id": "57.5", "text": "Lists other potential causes: OS scheduling interference, goroutines pinned by cgo or long syscalls"}
+    ]
+  },
+  {
+    "id": 58,
+    "name": "benchmark-output-format-parsing",
+    "description": "Tests understanding of the benchmark output format",
+    "prompt": "I see this benchmark output: `BenchmarkEncode/size=64-8  5000000  230.5 ns/op  128 B/op  2 allocs/op`. What does each part mean?",
+    "trap": "Without the skill, the model may not explain the -8 suffix correctly",
+    "assertions": [
+      {"id": "58.1", "text": "Explains that -8 is the GOMAXPROCS suffix"},
+      {"id": "58.2", "text": "Explains that 5000000 is the number of iterations (b.N)"},
+      {"id": "58.3", "text": "Explains that ns/op is time per operation"},
+      {"id": "58.4", "text": "Explains that B/op is bytes allocated per operation"},
+      {"id": "58.5", "text": "Explains that allocs/op is heap allocation count per operation"}
+    ]
+  },
+  {
+    "id": 59,
+    "name": "pprof-show-from-framework-noise",
+    "description": "Tests knowledge of show_from to trim framework noise in profiles",
+    "prompt": "My pprof output is cluttered with HTTP framework routing functions (net/http.(*ServeMux).ServeHTTP, etc.) that appear above every handler. How do I remove this noise and start the analysis from my handler code?",
+    "trap": "Without the skill, the model may suggest using ignore (which changes cost accounting) instead of show_from",
+    "assertions": [
+      {"id": "59.1", "text": "Uses show_from=regex to trim all frames above the first matching function"},
+      {"id": "59.2", "text": "Shows the correct pattern: show_from=handler.Handle or similar"},
+      {"id": "59.3", "text": "Explains that show_from hides all callers above the match point"},
+      {"id": "59.4", "text": "Differentiates from ignore which removes functions and re-attributes their costs"}
+    ]
+  },
+  {
+    "id": 60,
+    "name": "optional-prometheus-metrics-enablement",
+    "description": "Tests knowledge of how to enable optional Go runtime Prometheus metrics",
+    "prompt": "I want to expose Go scheduler metrics (goroutine scheduling latency) and CPU class breakdowns in Prometheus. The default go_memstats_* metrics don't include these. How do I enable them?",
+    "trap": "Without the skill, the model may not know about the opt-in collector configuration",
+    "assertions": [
+      {"id": "60.1", "text": "Shows creating a custom registry with collectors.NewGoCollector"},
+      {"id": "60.2", "text": "Uses collectors.WithGoCollectorRuntimeMetrics option"},
+      {"id": "60.3", "text": "Mentions collectors.MetricsAll or specific GoRuntimeMetricsRule values"},
+      {"id": "60.4", "text": "Notes this requires Go 1.17+"},
+      {"id": "60.5", "text": "Lists scheduler metrics like go_sched_latencies_seconds and CPU class metrics like go_cpu_classes_*"}
+    ]
+  },
+  {
+    "id": 61,
+    "name": "benchdiff-usage-patterns",
+    "description": "Tests practical usage of benchdiff for PR comparisons",
+    "prompt": "I want to quickly compare the benchmark performance of my current changes against the main branch. I don't want to manually check out branches and run benchmarks separately. What tool can automate this?",
+    "trap": "Without the skill, the model may suggest a manual checkout-and-compare workflow",
+    "assertions": [
+      {"id": "61.1", "text": "Recommends benchdiff for automatic branch comparison"},
+      {"id": "61.2", "text": "Shows the basic command: benchdiff -base-ref main -- -benchmem -count=10"},
+      {"id": "61.3", "text": "Explains that benchdiff caches results for non-worktree refs so re-runs are fast"},
+      {"id": "61.4", "text": "Mentions benchdiff -clear-cache for stale cache situations"},
+      {"id": "61.5", "text": "Notes that benchdiff prevents macOS sleep during benchmarks"}
+    ]
+  },
+  {
+    "id": 62,
+    "name": "pprof-noinlines-attribution",
+    "description": "Tests knowledge of the noinlines option for simplifying inlined function chains",
+    "prompt": "My pprof call graph shows many tiny inlined functions creating confusing chains. The real cost is in the outer function but it's split across multiple inline nodes. How do I simplify this?",
+    "trap": "Without the skill, the model may suggest using show/hide which don't properly aggregate inlined costs",
+    "assertions": [
+      {"id": "62.1", "text": "Uses the noinlines option or -noinlines flag"},
+      {"id": "62.2", "text": "Explains that noinlines attributes inlined functions to their first out-of-line caller"},
+      {"id": "62.3", "text": "Shows correct usage: either `noinlines` in interactive mode or `-noinlines` as CLI flag"}
+    ]
+  },
+  {
+    "id": 63,
+    "name": "sub-benchmarks-table-driven",
+    "description": "Tests proper structure for table-driven sub-benchmarks with b.Run",
+    "prompt": "I want to benchmark my Encode function with different input sizes (64, 256, 4096 bytes) in a single benchmark function. The project uses Go 1.24.",
+    "trap": "Without the skill, the model may write separate benchmark functions or use b.N loop inside b.Run without b.Loop()",
+    "assertions": [
+      {"id": "63.1", "text": "Uses b.Run() with descriptive sub-benchmark names (e.g., size=64)"},
+      {"id": "63.2", "text": "Uses b.Loop() (not range b.N) inside each sub-benchmark since Go 1.24"},
+      {"id": "63.3", "text": "Places setup code (like make([]byte, size)) before the b.Loop() call"},
+      {"id": "63.4", "text": "Uses a loop or range over sizes with fmt.Sprintf for names"},
+      {"id": "63.5", "text": "Output will look like BenchmarkEncode/size=64, BenchmarkEncode/size=256, etc."}
+    ]
+  },
+  {
+    "id": 64,
+    "name": "benchstat-row-col-projection",
+    "description": "Tests knowledge of -row flag to control what appears as rows vs the default grouping",
+    "prompt": "I ran benchmarks for two packages (parser and encoder) with two sub-benchmark parameters each (format=json and format=gob). benchstat mixes everything into one table. I want separate tables per package, with format as columns. What benchstat flags should I use?",
+    "trap": "Without the skill, the model suggests splitting into separate files and running benchstat separately, missing the -table pkg and -col /format flags that combine to produce the desired layout",
+    "assertions": [
+      {"id": "64.1", "text": "Uses -table pkg to produce a separate table per package"},
+      {"id": "64.2", "text": "Uses -col /format to make format values (json, gob) the column headers"},
+      {"id": "64.3", "text": "Shows the combined command: benchstat -table pkg -col /format bench.txt"},
+      {"id": "64.4", "text": "Explains that -table controls the grouping dimension and -col controls column layout"}
+    ]
+  },
+  {
+    "id": 65,
+    "name": "trace-short-lived-goroutines",
+    "description": "Tests ability to identify goroutine creation overhead in traces",
+    "prompt": "My execution trace shows thousands of very short-lived goroutines being created and destroyed rapidly. Is this a problem?",
+    "trap": "Without the skill, the model may say goroutines are cheap and this is fine",
+    "assertions": [
+      {"id": "65.1", "text": "Identifies high overhead from goroutine creation and scheduling for very short-lived goroutines"},
+      {"id": "65.2", "text": "Recommends batching work or using worker pools to reduce creation overhead"},
+      {"id": "65.3", "text": "Mentions checking for goroutines created in loops without bounds as a potential leak pattern"},
+      {"id": "65.4", "text": "Notes that goroutines created but never finishing indicates a leak"}
+    ]
+  },
+  {
+    "id": 66,
+    "name": "benchmark-side-effects-corrupt-results",
+    "description": "Tests awareness that benchmarks with shared mutable state produce non-reproducible and misleading results",
+    "prompt": "I wrote this benchmark to measure LRU cache insertions:\n\n```go\nvar globalCache = NewLRUCache(1000)\n\nfunc BenchmarkCacheInsert(b *testing.B) {\n    for b.Loop() {\n        globalCache.Set(randomKey(), randomValue())\n    }\n}\n```\n\nThe first run shows 45 ns/op. The second run shows 180 ns/op. Why do results vary so much between runs?",
+    "trap": "Without the skill, the model suggests adding b.ResetTimer() or increasing benchtime — missing that shared mutable global state across runs causes the cache to be in different fill states, making each b.N iteration operate on a different cache state (empty, half-full, full with evictions)",
+    "assertions": [
+      {"id": "66.1", "text": "Identifies that globalCache is mutable shared state — its fill level changes across b.N iterations and across separate runs"},
+      {"id": "66.2", "text": "Explains that early iterations insert into empty slots (fast), while later iterations trigger evictions (slow) — the benchmark measures a mix of two different operations"},
+      {"id": "66.3", "text": "Recommends using b.StopTimer()/b.StartTimer() or b.ResetTimer() with setup per batch, OR pre-filling/resetting the cache state to a known baseline before the benchmark loop"},
+      {"id": "66.4", "text": "Notes that mutable global state in benchmarks produces results that vary by execution order — isolated state inside b.Run sub-benchmarks or per-benchmark setup is the correct pattern"}
+    ]
+  },
+  {
+    "id": 67,
+    "name": "async-work-allocation-measurement-scope",
+    "description": "Tests that benchmark allocation counts cover allocations during the measured window, including other goroutines, but async work can escape measurement if synchronization is wrong",
+    "prompt": "I have a benchmark that spawns a goroutine inside the loop to do async work:\n\n```go\nfunc BenchmarkProcess(b *testing.B) {\n    b.ReportAllocs()\n    for b.Loop() {\n        ch := make(chan Result, 1)\n        go worker(ch)  // worker allocates internally\n        <-ch\n    }\n}\n```\n\nThe benchmark reports 1 alloc/op (just the channel). But profiling shows the worker goroutine allocates heavily. Why doesn't ReportAllocs see those?",
+    "trap": "Without the skill, the model may incorrectly claim ReportAllocs only tracks the benchmark goroutine. Allocation counts are global deltas while the timer is running; discrepancies usually mean async work occurred outside the measured window, synchronization is wrong, or the profile covers a different scope.",
+    "assertions": [
+      {"id": "67.1", "text": "Explains that ReportAllocs/-benchmem use allocation deltas while the benchmark timer is running, not per-goroutine attribution"},
+      {"id": "67.2", "text": "Checks whether the worker goroutine is fully synchronized inside the b.Loop measured window"},
+      {"id": "67.3", "text": "Recommends using a heap profile (-memprofile) to inspect allocation sites across goroutines"},
+      {"id": "67.4", "text": "Notes that profile-vs-benchmark discrepancies can come from async work outside timing or a different measurement scope"}
+    ]
+  },
+  {
+    "id": 68,
+    "name": "pprof-goroutine-debug-levels",
+    "description": "Tests knowledge of the different debug levels for goroutine dumps",
+    "prompt": "I want to get a human-readable dump of all goroutine stacks from my running Go service via HTTP, without using go tool pprof. How?",
+    "trap": "Without the skill, the model may only suggest the binary profile format",
+    "assertions": [
+      {"id": "68.1", "text": "Uses curl with ?debug=1 for human-readable goroutine dump"},
+      {"id": "68.2", "text": "Mentions ?debug=2 for full stack traces with creation site and labels"},
+      {"id": "68.3", "text": "Shows the URL: http://localhost:6060/debug/pprof/goroutine?debug=1 or ?debug=2"},
+      {"id": "68.4", "text": "Notes that no go tool pprof is needed for debug mode dumps"}
+    ]
+  },
+  {
+    "id": 69,
+    "name": "ci-threshold-calibration",
+    "description": "Tests knowledge of appropriate regression thresholds for different CI environments",
+    "prompt": "I'm setting up benchmark regression detection in CI. What threshold should I set for failing PRs on performance regression?",
+    "trap": "Without the skill, the model may suggest a tight threshold (5%) without considering the CI environment",
+    "assertions": [
+      {"id": "69.1", "text": "Recommends 20%+ threshold on shared/GitHub-hosted runners"},
+      {"id": "69.2", "text": "Recommends 10% on dedicated self-hosted runners"},
+      {"id": "69.3", "text": "Explains that tight thresholds on noisy environments produce false positives that erode trust"},
+      {"id": "69.4", "text": "Mentions that GitHub-hosted runners show ~2-3% coefficient of variation in best case"},
+      {"id": "69.5", "text": "States that <1% false positive rate requires 7%+ performance gate"}
+    ]
+  },
+  {
+    "id": 70,
+    "name": "cpu-profile-requires-binary-for-symbolization",
+    "description": "Tests knowledge that a CPU profile file captured from a benchmark contains no symbols — the original test binary is required for symbolization",
+    "prompt": "I ran `go test -bench=BenchmarkParse -cpuprofile=cpu.prof ./pkg/parser` on our CI server, then downloaded cpu.prof to my laptop to analyze. When I run `go tool pprof cpu.prof` I see only hex addresses instead of function names. What's missing?",
+    "trap": "Without the skill, the model may suggest rebuilding pprof or using -symbolize=remote — missing that the pprof file is unsymbolized and requires the original compiled test binary (parser.test) to resolve addresses to function names",
+    "assertions": [
+      {"id": "70.1", "text": "Explains that cpu.prof contains memory addresses, not function names — it requires the compiled test binary for symbolization"},
+      {"id": "70.2", "text": "States that go test -bench also produces a test binary (e.g., parser.test) alongside the profile"},
+      {"id": "70.3", "text": "Shows the correct command: go tool pprof parser.test cpu.prof (pass the binary as the first argument)"},
+      {"id": "70.4", "text": "Recommends downloading both the .prof file AND the corresponding test binary from CI for remote analysis"}
+    ]
+  },
+  {
+    "id": 71,
+    "name": "benchstat-ignore-dimension-warning",
+    "description": "Tests knowledge of the -ignore flag for suppressing benchstat dimension warnings",
+    "prompt": "benchstat gives me a warning: 'benchmarks vary in /gomaxprocs'. How do I suppress this?",
+    "trap": "Without the skill, the model may suggest filtering the output or restructuring benchmarks",
+    "assertions": [
+      {"id": "71.1", "text": "Uses -ignore /gomaxprocs to suppress the warning"},
+      {"id": "71.2", "text": "Explains that -ignore omits keys from grouping"},
+      {"id": "71.3", "text": "Alternatively suggests -row .name to simplify row grouping"},
+      {"id": "71.4", "text": "Mentions that -col /gomaxprocs could be used to compare across GOMAXPROCS values instead"}
+    ]
+  },
+  {
+    "id": 72,
+    "name": "gcflags-all-vs-single-package-scope",
+    "description": "Tests understanding of -gcflags=\"all=-m\" vs -gcflags=\"-m\" and when the wider scope matters",
+    "prompt": "I'm investigating unexpected heap allocations in my Go service. I ran `go build -gcflags=\"-m\" ./...` and the escape analysis output only shows my own packages. But I suspect a third-party library function is causing my structs to escape when passed to it. How do I see escape decisions for dependencies too?",
+    "trap": "Without the skill, the model only knows -gcflags=\"-m\" which applies to packages named on the command line, not their dependencies — missing the all= prefix that applies flags to all transitively compiled packages including vendor/module dependencies",
+    "assertions": [
+      {"id": "72.1", "text": "Explains that -gcflags=\"-m\" only applies escape analysis to packages explicitly listed on the command line, not their dependencies"},
+      {"id": "72.2", "text": "Shows go build -gcflags=\"all=-m\" ./... to apply escape analysis to ALL compiled packages including dependencies"},
+      {"id": "72.3", "text": "Warns that all=-m produces very verbose output — recommends piping through grep to filter for the specific package or function of interest"},
+      {"id": "72.4", "text": "Notes this is especially useful for diagnosing parameter escapes caused by passing values to functions in external packages that the compiler cannot analyze inline"}
+    ]
+  },
+  {
+    "id": 73,
+    "name": "runtime-readmemstats-vs-runtime-metrics",
+    "description": "Tests knowledge of the programmatic APIs for runtime statistics",
+    "prompt": "I want to read GC statistics programmatically in my Go application for a custom dashboard. What APIs are available and which should I prefer?",
+    "trap": "Without the skill, the model may recommend ReadMemStats without noting its overhead or the modern alternative",
+    "assertions": [
+      {"id": "73.1", "text": "Mentions runtime.ReadMemStats for heap size, NumGC, pause durations"},
+      {"id": "73.2", "text": "Mentions debug.ReadGCStats for GC-specific statistics"},
+      {"id": "73.3", "text": "Recommends runtime/metrics (Go 1.16+) as the preferred modern API"},
+      {"id": "73.4", "text": "Explains that runtime/metrics has lower overhead and is safe for concurrent reads"},
+      {"id": "73.5", "text": "Notes that ReadMemStats is more expensive due to internal locking"}
+    ]
+  },
+  {
+    "id": 74,
+    "name": "pprof-callgrind-export",
+    "description": "Tests knowledge of exporting pprof data to external visualization tools",
+    "prompt": "I want to analyze a Go pprof profile in KCachegrind for more advanced visualization. How do I export the data?",
+    "trap": "Without the skill, the model may not know about the callgrind export format",
+    "assertions": [
+      {"id": "74.1", "text": "Uses the callgrind command or -callgrind flag to export"},
+      {"id": "74.2", "text": "Shows the command: go tool pprof -callgrind cpu.prof > cpu.callgrind"},
+      {"id": "74.3", "text": "Mentions KCachegrind or QCachegrind as visualization tools"},
+      {"id": "74.4", "text": "Notes the proto command for saving in protobuf format as an alternative"}
+    ]
+  },
+  {
+    "id": 75,
+    "name": "expvar-lightweight-monitoring",
+    "description": "Tests knowledge of expvar as a lightweight alternative to Prometheus for runtime metrics",
+    "prompt": "I want a lightweight way to expose Go runtime variables as JSON for monitoring without adding a full Prometheus dependency. What does the stdlib offer?",
+    "trap": "Without the skill, the model may suggest writing a custom handler or only mention pprof",
+    "assertions": [
+      {"id": "75.1", "text": "Recommends expvar package from the stdlib"},
+      {"id": "75.2", "text": "Shows that import _ \"expvar\" auto-registers at /debug/vars"},
+      {"id": "75.3", "text": "Notes it serves JSON format"},
+      {"id": "75.4", "text": "Mentions integration with Netdata, Telegraf, or custom dashboards"}
+    ]
+  },
+  {
+    "id": 76,
+    "name": "benchstat-table-flag-per-package",
+    "description": "Tests knowledge of the -table flag for grouping benchstat output by package",
+    "prompt": "I ran benchmarks across multiple packages and the benchstat output mixes them all together. How do I get separate comparison tables per package?",
+    "trap": "Without the skill, the model may suggest running benchstat separately per package",
+    "assertions": [
+      {"id": "76.1", "text": "Uses -table pkg flag to create one table per package"},
+      {"id": "76.2", "text": "Shows the command: benchstat -table pkg old.txt new.txt"},
+      {"id": "76.3", "text": "Explains that the default -table value is .config which groups by goos/goarch/pkg/cpu"}
+    ]
+  },
+  {
+    "id": 77,
+    "name": "pprof-symbolization-remote",
+    "description": "Tests knowledge of pprof symbolization modes for remote profiling",
+    "prompt": "I captured a pprof profile from a production server but the function names show as hex addresses instead of readable names. How do I fix this?",
+    "trap": "Without the skill, the model may not know about the symbolization modes",
+    "assertions": [
+      {"id": "77.1", "text": "Explains pprof symbolization modes: local, remote, none"},
+      {"id": "77.2", "text": "Shows -symbolize=local to use local binaries"},
+      {"id": "77.3", "text": "Mentions PPROF_BINARY_PATH environment variable for setting binary search paths"},
+      {"id": "77.4", "text": "Shows -symbolize=remote to contact the running service for symbol information"}
+    ]
+  },
+  {
+    "id": 78,
+    "name": "trace-concurrent-with-flight-recorder",
+    "description": "Tests understanding that trace.Start and FlightRecorder can run concurrently",
+    "prompt": "I have a flight recorder running in my service. If I also call trace.Start() to capture a short trace for debugging, will they conflict?",
+    "trap": "Without the skill, the model may assume they can't coexist",
+    "assertions": [
+      {"id": "78.1", "text": "States that a flight recorder can run concurrently with trace.Start"},
+      {"id": "78.2", "text": "Notes the constraint that at most one flight recorder may be active at a time"},
+      {"id": "78.3", "text": "Clarifies that both can be active simultaneously without conflict"}
+    ]
+  },
+  {
+    "id": 79,
+    "name": "pyroscope-overhead-warning",
+    "description": "Tests awareness of continuous profiling overhead at scale",
+    "prompt": "Our SRE team wants to enable Pyroscope continuous profiling on all 200 production instances. Any concerns?",
+    "trap": "Without the skill, the model may approve fleet-wide enablement without the cost warning",
+    "assertions": [
+      {"id": "79.1", "text": "Warns about ~2-5% CPU overhead per instance for continuous profiling"},
+      {"id": "79.2", "text": "Notes that at 200 instances, the aggregate compute cost and backend storage cost is significant"},
+      {"id": "79.3", "text": "Recommends enabling on a subset of instances or on-demand via environment variable"},
+      {"id": "79.4", "text": "Emphasizes the investigation session approach: enable on target instances only, not fleet-wide"}
+    ]
+  },
+  {
+    "id": 80,
+    "name": "non-go-memory-leak-detection",
+    "description": "Tests the PromQL pattern for detecting non-Go memory leaks (cgo, mmap)",
+    "prompt": "My Go service's RSS keeps growing but go_memstats_alloc_bytes appears stable. The leak doesn't seem to be in Go heap memory. How do I diagnose this?",
+    "trap": "Without the skill, the model may only investigate Go heap, missing cgo/mmap leaks",
+    "assertions": [
+      {"id": "80.1", "text": "Uses the PromQL pattern: process_resident_memory_bytes - go_memstats_sys_bytes"},
+      {"id": "80.2", "text": "Explains that the gap represents non-Go memory (cgo, mmap, etc.)"},
+      {"id": "80.3", "text": "A growing gap indicates a non-Go memory leak"},
+      {"id": "80.4", "text": "Suggests investigating cgo calls or memory-mapped files as potential sources"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/benchstat.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/benchstat.md
new file mode 100644
index 00000000..fb799b3b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/benchstat.md
@@ -0,0 +1,389 @@
+# benchstat Reference
+
+`benchstat` computes statistical summaries and A/B comparisons of Go benchmark results. A single benchmark run tells you nothing about variance — `benchstat` tells you whether the difference between two runs is real or noise.
+
+## Installation
+
+```bash
+go install golang.org/x/perf/cmd/benchstat@latest
+```
+
+## Usage
+
+```bash
+benchstat [flags] inputs...
+```
+
+Each input is a file containing `go test -bench` output. Optionally label inputs with `label=path` syntax.
+
+## Basic Workflow
+
+### Step 0: Write benchmarks
+
+Use the standard Go benchmark function signature in `*_test.go`:
+
+### Step 1: Measure baseline
+
+Run benchmarks with `-count=10` or more. Each run produces one data point — you need at least 10 to compute a meaningful confidence interval:
+
+```bash
+go test -run='^$' -bench=BenchmarkParse -benchmem -count=10 ./pkg/parser | tee old.txt
+```
+
+`-run='^$'` skips unit tests so only benchmarks run — avoids wasting time on tests during measurement sessions.
+
+### Step 2: Make your change
+
+Edit the code you want to optimize.
+
+### Step 3: Measure again
+
+Same command, same flags, same machine, same load conditions:
+
+```bash
+go test -run='^$' -bench=BenchmarkParse -benchmem -count=10 ./pkg/parser | tee new.txt
+```
+
+### Step 4: Compare
+
+```bash
+benchstat old.txt new.txt
+```
+
+Output:
+
+```
+goos: linux
+goarch: amd64
+pkg: myapp/pkg/parser
+cpu: AMD Ryzen 9 5950X 16-Core Processor
+          │   old.txt   │              new.txt               │
+          │   sec/op    │   sec/op     vs base               │
+Parse-32    4.592µ ± 2%   3.041µ ± 1%  -33.78% (p=0.000 n=10)
+
+          │  old.txt   │             new.txt              │
+          │    B/op    │    B/op     vs base              │
+Parse-32    1.024Ki ± 0%   0.512Ki ± 0%  -50.00% (p=0.000 n=10)
+
+          │  old.txt  │            new.txt             │
+          │ allocs/op │ allocs/op   vs base            │
+Parse-32    12.00 ± 0%   6.000 ± 0%  -50.00% (p=0.000 n=10)
+```
+
+## Reading the Output
+
+| Element | Meaning | What to look for |
+| --- | --- | --- |
+| **median** (e.g., `4.592µ`) | Central value across runs — more robust than mean because outliers don't skew it | The reference number for this benchmark |
+| **± N%** (e.g., `± 2%`) | Half-width of the 95% confidence interval as a percentage of the median | Low (≤2%) = stable measurement. High (>5%) = noisy — investigate noise sources before trusting results |
+| **vs base** (e.g., `-33.78%`) | Percentage change from the first input (base) to subsequent inputs | Negative = faster/smaller. Positive = slower/larger |
+| **p=N** (e.g., `p=0.000`) | p-value from Mann-Whitney U-test (non-parametric) | <0.05 = statistically significant. ≥0.05 = difference could be noise |
+| **n=N** (e.g., `n=10`) | Number of samples used in the comparison | Should usually match your `-count`; if it does not, check that each input file contains the same benchmark rows and units |
+| **`~`** | No statistically significant difference detected | Do NOT claim improvement — the change might be zero |
+| **geomean** row | Geometric mean of changes across all benchmarks in the table | Overall proportional change; useful when comparing many benchmarks at once |
+
+### Unit normalization
+
+benchstat automatically normalizes units for display:
+
+- `ns/op` → displayed as `sec/op` (with µ, m prefixes) to avoid nonsensical `µns/op`
+- `MB/s` → displayed as `B/s` (with K, M, G prefixes)
+
+### When the `~` symbol appears
+
+```
+Parse-32    4.592µ ± 8%   4.481µ ± 7%  ~ (p=0.089 n=10)
+```
+
+This means benchstat cannot distinguish the difference from random noise. The wide confidence intervals (±8%, ±7%) overlap. Do not claim improvement. Options:
+
+- Increase `-count` to 20+ (narrower CI may reveal a real difference)
+- Reduce noise sources (close applications, plug in power, use dedicated machine)
+- Accept that the change has no measurable effect on this benchmark
+
+## Flags Reference
+
+### Projection flags
+
+These flags control how benchmark results are grouped into tables, rows, and columns.
+
+| Flag | Default | Purpose |
+| --- | --- | --- |
+| `-table KEYS` | `.config` | Group results into separate tables by these keys |
+| `-row KEYS` | `.fullname` | Group results into table rows by these keys |
+| `-col KEYS` | `.file` | Compare across columns with different values of these keys |
+| `-ignore KEYS` | (none) | Omit keys from grouping — suppresses "benchmarks vary" warnings |
+
+**Available keys:**
+
+| Key | Meaning | Example value |
+| --- | --- | --- |
+| `.name` | Base benchmark name (without sub-benchmark config) | `Parse` from `BenchmarkParse/size=4k-16` |
+| `.fullname` | Full name including sub-benchmark configuration | `Parse/size=4k-16` |
+| `.file` | Input file name or custom label | `old.txt` or `baseline` |
+| `.config` | All file-level configuration keys combined | `goos/goarch/pkg/cpu` |
+| `.unit` | Metric unit name | `sec/op`, `B/op`, `allocs/op` |
+| `/{name-key}` | Per-benchmark sub-name key | `/size` extracts `4k` from `Parse/size=4k` |
+| `/gomaxprocs` | GOMAXPROCS value — recognizes both `/gomaxprocs=N` and the `-N` suffix convention | `16` from `Parse-16` |
+| `goos` | Operating system (from benchmark output header) | `linux`, `darwin` |
+| `goarch` | Architecture (from benchmark output header) | `amd64`, `arm64` |
+| `pkg` | Package path (from benchmark output header) | `myapp/pkg/parser` |
+| `cpu` | CPU model (from benchmark output header) | `AMD Ryzen 9 5950X` |
+
+**Sort order modifiers** — append to any key:
+
+| Modifier | Meaning | Example |
+| --- | --- | --- |
+| `@alpha` | Alphabetic sort | `/format@alpha` |
+| `@num` | Numeric sort (understands prefixes: 2k, 1Mi) | `/size@num` |
+| `@(val1 val2 ...)` | Fixed order + filter (only listed values, in this order) | `/format@(gob json)` |
+
+### Filter flag
+
+| Flag | Purpose |
+| --- | --- |
+| `-filter EXPR` | Filter which benchmarks are processed before grouping and comparison |
+
+See [Filter Expression Syntax](#filter-expression-syntax) below for full details.
+
+### Input labeling
+
+Not a flag but a syntax feature — label input files for clearer column headers:
+
+```bash
+# Default: file names become column headers
+benchstat old.txt new.txt
+
+# Custom labels
+benchstat baseline=old.txt optimized=new.txt
+
+# Multiple versions
+benchstat v1=v1.txt v2=v2.txt v3=v3.txt
+```
+
+The first input is always the **base** for comparison. All subsequent inputs are compared against it.
+
+## Filter Expression Syntax
+
+Filters select which benchmarks to include before grouping and comparison. The syntax is:
+
+### Matching operators
+
+| Pattern | Meaning | Example |
+| --- | --- | --- |
+| `key:value` | Exact match | `goos:linux` |
+| `key:"value"` | Exact match with quoted value (allows spaces, special chars) | `pkg:"github.com/user/repo"` |
+| `key:/regexp/` | Regular expression match (Go regexp syntax) | `.name:/Parse\|Encode/` |
+| `key:(val1 OR val2)` | Match any of the listed values | `goos:(linux OR darwin)` |
+| `*` | Match everything (all benchmarks) | `*` |
+
+### Logical operators
+
+| Operator | Meaning | Example |
+| --- | --- | --- |
+| `x y` | AND — both must match (implicit) | `goos:linux goarch:amd64` |
+| `x AND y` | AND — explicit form | `goos:linux AND goarch:amd64` |
+| `x OR y` | OR — either must match | `goos:linux OR goos:darwin` |
+| `-x` | NOT — must not match | `-goos:windows` |
+| `(...)` | Grouping / subexpression | `(goos:linux OR goos:darwin) -pkg:/internal/` |
+
+### Filter key types
+
+| Key | What it matches | Example |
+| --- | --- | --- |
+| `.name` | Base benchmark name | `.name:Parse` |
+| `.fullname` | Full name with sub-benchmark config | `.fullname:/Parse\/size=4k/` |
+| `/{name-key}` | Sub-benchmark parameter | `/size:4k` |
+| `/gomaxprocs` | GOMAXPROCS value | `/gomaxprocs:16` |
+| `.file` | Input file label | `.file:old.txt` |
+| `.unit` | Metric unit | `.unit:sec/op` |
+| `goos` | OS from header | `goos:linux` |
+| `goarch` | Architecture from header | `goarch:amd64` |
+| `pkg` | Package from header | `pkg:/parser/` |
+
+### Filter examples
+
+```bash
+# Only Parse benchmarks
+benchstat -filter '.name:Parse' old.txt new.txt
+
+# Only benchmarks with size=4096 sub-parameter
+benchstat -filter '/size:4096' old.txt new.txt
+
+# Exclude Parallel benchmarks
+benchstat -filter '-.name:/Parallel/' old.txt new.txt
+
+# Linux amd64 only
+benchstat -filter 'goos:linux goarch:amd64' old.txt new.txt
+
+# Multiple benchmark names
+benchstat -filter '.name:(Parse OR Encode OR Decode)' old.txt new.txt
+
+# Complex: Linux or Darwin, not internal packages, only sec/op metric
+benchstat -filter '(goos:linux OR goos:darwin) -pkg:/internal/ .unit:sec/op' old.txt new.txt
+
+# Regex: all benchmarks starting with Bench
+benchstat -filter '.name:/^Bench/' old.txt new.txt
+```
+
+## Projection Examples
+
+### Default: before/after file comparison
+
+```bash
+benchstat old.txt new.txt
+# Equivalent to:
+benchstat -table .config -row .fullname -col .file old.txt new.txt
+```
+
+Creates one row per benchmark, one column per file.
+
+### Compare sub-benchmark parameters within a single file
+
+When a single benchmark file contains multiple sub-benchmarks (e.g., `BenchmarkEncode/format=json` and `BenchmarkEncode/format=gob`):
+
+```bash
+benchstat -col /format bench.txt
+```
+
+Creates columns for each value of `/format`, comparing them against each other.
+
+### Simplify rows to base name only
+
+```bash
+benchstat -col /format -row .name bench.txt
+```
+
+Strips sub-benchmark configuration from row names, making the table more compact.
+
+### Control column order
+
+```bash
+# Force gob first, then json (instead of alphabetical)
+benchstat -col '/format@(gob json)' bench.txt
+```
+
+### Group by GOMAXPROCS
+
+```bash
+benchstat -col /gomaxprocs bench.txt
+```
+
+Compares performance across different GOMAXPROCS values within the same file.
+
+### Separate tables per package
+
+```bash
+benchstat -table pkg old.txt new.txt
+```
+
+Creates one table per package — useful when comparing benchmarks across multiple packages.
+
+### Ignore a dimension
+
+```bash
+# Suppress "benchmarks vary in /gomaxprocs" warning
+benchstat -row .name -ignore /gomaxprocs bench.txt
+```
+
+### Compare three versions
+
+```bash
+benchstat v1=v1.txt v2=v2.txt v3=v3.txt
+```
+
+Shows v2 vs v1 and v3 vs v1 (first input is always the base).
+
+### Cross-dimensional comparison
+
+```bash
+# Rows = benchmark name, columns = OS, separate tables per architecture
+benchstat -row .name -col goos -table goarch results.txt
+```
+
+## Unit Metadata
+
+### `assume=exact`
+
+For metrics that should not vary between runs (e.g., binary size, generated code size):
+
+```
+BenchmarkSize 1 42 custom-bytes/op
+Unit custom-bytes/op assume=exact
+```
+
+With `assume=exact`:
+
+- Non-parametric statistics are disabled
+- benchstat warns if measured values vary
+- Shows comparisons even with a single before/after measurement (no `-count` needed)
+
+### `assume=nothing` (default)
+
+Standard behavior — uses non-parametric statistics (median + Mann-Whitney U-test). Requires multiple samples.
+
+## Interleaving Runs
+
+Sequential runs (all old, then all new) are vulnerable to **systematic bias** — thermal throttling builds up over time, background processes come and go, CPU frequency scaling adapts. Interleaving reduces this:
+
+```bash
+# Pre-compile both versions to avoid measuring compilation time
+go test -c -o old.test ./pkg/parser
+# ... make your change ...
+go test -c -o new.test ./pkg/parser
+
+# Interleave runs — alternating reduces systematic bias
+for i in $(seq 1 10); do
+    ./old.test -test.bench=BenchmarkParse -test.benchmem >> old.txt
+    ./new.test -test.bench=BenchmarkParse -test.benchmem >> new.txt
+done
+
+benchstat old.txt new.txt
+```
+
+Pre-compiling with `go test -c` is critical — without it, each `go test -bench` invocation includes compilation time, which varies and contaminates results.
+
+## How Many Runs?
+
+| Scenario | Minimum `-count` | Why |
+| --- | --- | --- |
+| Quick local check | 6 | Enough for a rough confidence interval; fast feedback loop |
+| Pre-merge comparison | 10 | Standard for detecting moderate (>5%) changes with confidence |
+| Detecting small changes (<5%) | 20-30 | More samples narrow the CI; needed when signal is small relative to noise |
+| Noisy CI environment | 20+ | Shared CI runners have higher variance; more runs compensate |
+
+**Never "retry until significant"** — rerunning benchmarks until `~` goes away introduces selection bias (p-hacking). If 10 runs show `~`, the change is probably not meaningful. Increase run count **once** and accept the result.
+
+At α=0.05, expect ~5% of benchmarks to randomly report significance with no real change (false positives). This is normal — don't chase them.
+
+## Single-File Summary
+
+Analyze variance of a single run without comparison:
+
+```bash
+benchstat bench.txt
+```
+
+Shows median and confidence interval for each benchmark. Use to:
+
+- Check measurement stability before making code changes
+- Identify noisy benchmarks that need more runs or better isolation
+- Get a quick summary of current performance
+
+## Common Pitfalls
+
+| Pitfall | Why it's wrong | Fix |
+| --- | --- | --- |
+| `-count=1` | Single run has no variance information; benchstat can't compute confidence | Always use `-count=6` minimum, prefer `-count=10` |
+| Running on a laptop on battery | CPU throttles to save power; variance explodes | Plug in, disable power saving, or use a desktop/server |
+| Running with browser/IDE open | Background processes steal CPU cycles; adds noise | Close unnecessary applications, or accept wider CIs |
+| Rerunning until `~` disappears | Selection bias (p-hacking) — you're cherry-picking runs that showed improvement | Run once with high `-count`, accept the result |
+| Comparing across machines | Different CPUs, memory, OS = incomparable baselines | Same machine, same conditions, both runs |
+| Not interleaving | Systematic bias from thermal throttling, background load drift | Pre-compile both versions with `go test -c`, alternate runs |
+| Measuring compilation time | `go test -bench` compiles first; startup overhead varies | Pre-compile with `go test -c`, run the binary directly |
+| Ignoring wide CI (± >5%) | Results look significant but variance is too high to be trustworthy | Fix the noise first, then compare; or increase `-count` |
+| Comparing different `-count` values | Unequal sample sizes bias the comparison | Use the same `-count` for all inputs |
+
+## benchstat in CI
+
+See [CI Regression Detection](./ci-regression.md) for integrating benchstat comparisons into CI pipelines with benchdiff, cob, and gobenchdata.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/ci-regression.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/ci-regression.md
new file mode 100644
index 00000000..f460bf14
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/ci-regression.md
@@ -0,0 +1,285 @@
+# CI Benchmark Regression Detection
+
+> **Run these tools in CI only, not on local machines.** Local benchmark results are noisy due to background processes, thermal throttling, and inconsistent CPU frequency — regressions detected locally are unreliable and waste developer time. Even shared CI runners can produce significant variance (5-10%); use statistical methods like `benchstat` with multiple iterations and relative comparisons to filter noise, or invest in dedicated benchmark runners for critical paths.
+
+## benchdiff
+
+Runs Go benchmarks on two git refs and uses `benchstat` to display deltas. Caches results for non-worktree refs so re-runs are fast. Prevents macOS sleep during benchmarks.
+
+```bash
+go install filippo.io/mostly-harmless/benchdiff@latest
+```
+
+```bash
+# Compare current worktree against HEAD (default)
+benchdiff -- -benchmem
+
+# Compare two specific refs
+benchdiff -base-ref main -head-ref feature-branch
+
+# Compare against a specific commit or tag
+benchdiff -base-ref v1.2.0
+
+# Pass extra flags to go test — everything after -- goes to go test
+benchdiff -- -benchmem -count=10 -benchtime=3s
+
+# Filter to specific benchmarks
+benchdiff -- -benchmem -count=10 -bench=BenchmarkParse
+
+# Target a specific package
+benchdiff -- -benchmem -count=10 ./pkg/parser/...
+
+# Clear cached results (useful after rebasing or when cache is stale)
+benchdiff -clear-cache
+
+# Combine: compare main with 10 iterations, filtered to critical benchmarks
+benchdiff -base-ref main -- -benchmem -count=10 -bench='BenchmarkParse|BenchmarkEncode'
+```
+
+Best for: quick PR-to-base comparisons in git-based workflows. Leverages `benchstat` for statistical rigor and caches non-worktree refs so re-runs only re-measure the worktree.
+
+## cob
+
+Compares benchmarks between HEAD and HEAD~1, failing the CI job if performance degrades beyond a configurable threshold (default 20%).
+
+```bash
+go install github.com/knqyf263/cob@latest
+```
+
+```bash
+# Run with default 20% threshold — compares HEAD vs HEAD~1
+cob
+
+# Stricter threshold for critical paths (10% regression = failure)
+cob -threshold 10
+
+# Compare against a specific base commit
+cob -base main
+
+# Only report regressions (ignore improvements)
+cob -only-degression
+
+# Choose which metrics to compare (default: ns/op,B/op)
+cob -compare "ns/op,B/op,allocs/op"
+
+# Custom go test arguments
+cob -bench-args "test -run '^$' -bench BenchmarkParse -benchmem ./pkg/parser/..."
+
+# Increase benchmark duration for more stable results
+cob -bench-args "test -run '^$' -bench . -benchmem -benchtime=3s ./..."
+
+# Skip cob for a specific commit: include [skip cob] in commit message
+```
+
+**Caution:** `cob` uses `git reset` internally, which can cause data loss if uncommitted changes exist. Always commit your work before running. Additionally, `cob` requires all benchmarks to pass; it skips CI gating if any benchmark fails. For safety, run only in CI pipelines, not locally. Note that `cob` compares single runs without `benchstat`-style statistics, making it more susceptible to noise than `benchdiff`.
+
+Best for: simple post-commit regression gating in CI where statistical rigor is less critical than fast feedback.
+
+## gobenchdata
+
+GitHub Action + CLI that collects benchmark results, publishes to gh-pages as JSON, and visualizes with an interactive web dashboard. Shows performance trends over time.
+
+```bash
+go install go.bobheadxi.dev/gobenchdata@latest
+```
+
+### CLI commands
+
+```bash
+# Parse go test -bench output to JSON
+go test -bench=. -benchmem -count=5 ./... | gobenchdata --json bench.json
+
+# Parse from a file
+gobenchdata --json bench.json < bench.txt
+
+# Add a tag to the benchmark run (e.g., git commit)
+gobenchdata --json bench.json --tag "$(git rev-parse --short HEAD)" < bench.txt
+
+# Evaluate regression checks against a checks config
+gobenchdata checks eval bench.txt --checks-config .gobenchdata-checks.yml
+
+# Generate the web dashboard app (static Vue.js site)
+gobenchdata web generate ./dashboard-app
+
+# Serve the dashboard locally for preview
+gobenchdata web serve ./dashboard-app
+
+# Merge multiple benchmark JSON files
+gobenchdata merge old-bench.json new-bench.json > combined.json
+
+# Prune old entries (keep last 30 runs)
+gobenchdata prune --count 30 bench.json
+```
+
+### GitHub Action setup
+
+```yaml
+# .github/workflows/benchmark.yml
+name: Benchmark
+on: [push]
+jobs:
+  benchmark:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-go@v5
+        with:
+          go-version: stable
+      - name: Run benchmarks
+        run: go test -bench=. -benchmem -count=5 ./... | tee bench.txt
+      - uses: bobheadxi/gobenchdata@v1
+        with:
+          PRUNE_COUNT: 30
+          GO_TEST_PKGS: ./...
+          BENCHMARKS_OUT: bench.txt
+          PUBLISH: true
+          PUBLISH_BRANCH: gh-pages
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+```
+
+### Regression gating on PRs
+
+```yaml
+- name: Check for regressions
+  run: gobenchdata checks eval bench.txt --checks-config .gobenchdata-checks.yml
+```
+
+```yaml
+# .gobenchdata-checks.yml
+checks:
+  - name: "No major regressions"
+    package: ./...
+    benchmarks: [".*"]
+    thresholds:
+      - metric: NsPerOp
+        max: 1.2 # fail if >20% slower
+      - metric: AllocedBytesPerOp
+        max: 1.3 # fail if >30% more allocations
+  - name: "Critical path stability"
+    package: ./pkg/parser
+    benchmarks: ["BenchmarkParse.*"]
+    thresholds:
+      - metric: NsPerOp
+        max: 1.1 # stricter: fail if >10% slower
+```
+
+### Dashboard configuration
+
+```yaml
+# gobenchdata-web.yml — configure the Vue.js dashboard
+title: "My Project Benchmarks"
+description: "Performance tracking dashboard"
+chartGroups:
+  - name: Parser
+    charts:
+      - name: Parse Performance
+        package: myapp/pkg/parser
+        benchmarks: ["BenchmarkParse.*"]
+        metrics: [NsPerOp, AllocedBytesPerOp, AllocsPerOp]
+  - name: Encoding
+    charts:
+      - name: Encode/Decode
+        package: myapp/pkg/encoding
+        benchmarks: ["Benchmark(Encode|Decode).*"]
+        metrics: [NsPerOp, MBPerS]
+```
+
+Best for: long-term trend tracking and visualization; complements benchdiff/cob for immediate gating.
+
+## Tool Selection Guide
+
+| Tool | Statistical rigor | Dashboard | Best for |
+| --- | --- | --- | --- |
+| **benchdiff** | High (uses benchstat) | No | Local dev + CI PR comparisons |
+| **cob** | Low (single comparison) | No | Quick CI gate, simple setup |
+| **gobenchdata** | Medium (configurable checks) | Yes (Vue.js on gh-pages) | Long-term trend tracking |
+| **benchstat** (raw) | High | No (CSV export) | Maximum control, custom workflows |
+
+## Noisy Neighbor Mitigation
+
+Cloud CI environments share hardware with other jobs. Expect 5-10% variance even on quiet machines.
+
+### Why CI benchmarks are noisy
+
+- **Shared CPU/memory** — other CI jobs compete for resources
+- **Thermal throttling** — sustained load reduces clock speed
+- **Different hardware across runs** — CI runners may have different specs
+- **Kernel scheduling** — context switches add unpredictable latency
+- **Disk I/O contention** — shared storage affects I/O-bound benchmarks
+
+### Strategies
+
+**Statistical rigor** — run with `-count=10` or more and compare with `benchstat`. A single run is meaningless. benchstat's p-value test filters out noise-induced false positives.
+
+**Relative comparison in same job** — run both base and head benchmarks in the same CI job on the same machine, rather than comparing against historical absolute values. This cancels out machine-to-machine variation. Tools like `benchdiff` do this automatically by checking out both git refs.
+
+**Dedicated benchmark runners** — for critical path benchmarks, use self-hosted CI runners with no other workloads. This eliminates noisy neighbors entirely but costs more infrastructure.
+
+**Conservative thresholds** — set regression thresholds higher on shared CI (20%+) than on dedicated runners (10%). Tight thresholds on noisy environments produce false positives that erode trust. GitHub-hosted runners show ~2-3% coefficient of variation in the best case; to guarantee <1% false positive rate, you need a 7%+ performance gate.
+
+**Never "retry until pass"** — rerunning benchmarks until they pass introduces selection bias. If a benchmark is flaky, fix the noise source (more iterations, dedicated runner, wider threshold) rather than retrying.
+
+## System Tuning for Self-Hosted Runners
+
+> **WARNING: These commands modify kernel and CPU settings. Apply them ONLY on dedicated CI runners, NEVER on developer machines or shared servers.**
+
+When you control the CI hardware, these settings dramatically reduce benchmark variance by eliminating the main sources of non-determinism.
+
+### Disable CPU frequency scaling
+
+Variable CPU frequency makes benchmark times meaningless — the same code runs at different speeds depending on load and thermals:
+
+```bash
+# Set all CPUs to "performance" governor (fixed maximum frequency)
+echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
+```
+
+### Disable Turbo Boost
+
+Turbo Boost temporarily increases clock speed but throttles under sustained load, creating variance between the start and end of a benchmark run:
+
+```bash
+# Intel
+echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo
+
+# AMD
+echo 0 | sudo tee /sys/devices/system/cpu/cpufreq/boost
+```
+
+### Pin benchmarks to specific CPU cores
+
+Prevents the OS from migrating the benchmark process across cores, which causes cache thrashing (L1/L2 caches are per-core):
+
+```bash
+# Pin to cores 2 and 3 (leave cores 0-1 for OS and other processes)
+taskset -c 2,3 go test -bench=. -count=10 ./...
+```
+
+### Disable SMT (Hyper-Threading)
+
+SMT shares execution units between logical cores on the same physical core, causing unpredictable contention:
+
+```bash
+# Disable SMT system-wide
+echo off | sudo tee /sys/devices/system/cpu/smt/control
+
+# Or disable individual sibling cores (check /sys/devices/system/cpu/cpu*/topology/thread_siblings_list)
+echo 0 | sudo tee /sys/devices/system/cpu/cpu1/online  # if cpu0 and cpu1 are siblings
+```
+
+### Combined CI setup script
+
+```bash
+#!/bin/bash
+# benchmark-setup.sh — run on self-hosted CI runner before benchmarks
+set -euo pipefail
+
+echo "=== Configuring CPU for stable benchmarks ==="
+echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
+echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo 2>/dev/null || true
+echo off | sudo tee /sys/devices/system/cpu/smt/control 2>/dev/null || true
+
+echo "=== Running benchmarks on isolated cores ==="
+taskset -c 2,3 go test -bench=. -benchmem -count=10 ./... | tee bench.txt
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/compiler-analysis.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/compiler-analysis.md
new file mode 100644
index 00000000..bac67d9d
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/compiler-analysis.md
@@ -0,0 +1,231 @@
+# Compiler Analysis Reference
+
+The Go compiler provides diagnostic flags that reveal optimization decisions — escape analysis, inlining, SSA intermediate representation, and generated assembly. These are essential for understanding **why** a function allocates or **why** the compiler won't inline it.
+
+Use compiler diagnostics when pprof shows a hot function and you need to understand the compiler's decisions about that function. These tools are free (no runtime overhead) — they analyze at compile time.
+
+## Escape Analysis
+
+Escape analysis determines whether a variable can live on the stack (cheap — freed when the function returns) or must be allocated on the heap (expensive — requires GC). "Moved to heap" means the compiler decided the variable might outlive the function.
+
+### Commands
+
+```bash
+# Show escape decisions — one line per escaped variable
+go build -gcflags="-m" ./... 2>&1 | grep "escapes to heap"
+go build -gcflags="-m" ./... 2>&1 | grep "moved to heap"
+
+# Verbose mode — shows the reason for each escape decision
+go build -gcflags="-m -m" ./...
+
+# Filter to a specific package
+go build -gcflags="-m" ./pkg/parser 2>&1 | grep "escapes"
+
+# Filter to a specific file
+go build -gcflags="-m" ./pkg/parser/parse.go 2>&1
+
+# Apply to all dependencies too (usually too noisy, but useful for debugging)
+go build -gcflags="all=-m" ./...
+
+# Combine with grep for a specific function
+go build -gcflags="-m" ./pkg/parser 2>&1 | grep "Parse"
+
+# Combine with grep to see what stays on the stack (does NOT escape)
+go build -gcflags="-m" ./pkg/parser 2>&1 | grep "does not escape"
+```
+
+### Reading the output
+
+```
+./pkg/parser/parse.go:15:6: can inline Parse
+./pkg/parser/parse.go:42:13: &result escapes to heap
+./pkg/parser/parse.go:42:13:   flow: ~r0 = &result:
+./pkg/parser/parse.go:42:13:     from &result (address-of) at ./pkg/parser/parse.go:42:13
+./pkg/parser/parse.go:42:13:     from return &result (return) at ./pkg/parser/parse.go:42:6
+```
+
+The `-m -m` (verbose) output shows the **escape chain** — why the compiler decided the variable escapes. In this example: `result` has its address taken (`&result`), and that pointer is returned, so `result` must survive beyond the function — it escapes to heap.
+
+### Common escape causes
+
+| Cause | Example | Why it escapes |
+| --- | --- | --- |
+| **Returning a pointer to a local** | `return &result` | The local must outlive the function call — caller holds a reference |
+| **Interface boxing** | `var x any = myStruct` | Concrete type stored in `interface{}` allocates a copy on the heap |
+| **Closure capturing a local** | `go func() { use(localVar) }()` | The goroutine may run after the enclosing function returns |
+| **Slice append beyond capacity** | `s = append(s, item)` when len == cap | Triggers a new backing array allocation on the heap |
+| **Passing pointer to unanalyzable function** | `json.Marshal(&data)` | Compiler can't prove the pointer won't be retained across package boundary |
+| **Storing in a struct field that escapes** | `obj.Field = &local` | If `obj` is heap-allocated, anything it points to must also be on the heap |
+| **fmt.Sprintf and friends** | `fmt.Sprintf("%d", n)` | Arguments are boxed into `any` (interface boxing) + result string is heap-allocated |
+| **Sending pointer on channel** | `ch <- &data` | Channel receiver may be a different goroutine with a different lifetime |
+
+**Not all escapes are problems.** Only investigate escapes in functions that pprof identifies as allocation-heavy. A function called once at startup can escape freely.
+
+## Inlining Decisions
+
+Inlining replaces a function call with the function body at the call site. This eliminates call overhead and enables further optimizations (escape analysis improves, dead code elimination, constant folding). Functions that aren't inlined in hot paths may benefit from simplification.
+
+### Commands
+
+```bash
+# Show which functions CAN be inlined
+go build -gcflags="-m" ./... 2>&1 | grep "can inline"
+
+# Show which functions CANNOT be inlined (with the reason)
+go build -gcflags="-m" ./... 2>&1 | grep "cannot inline"
+
+# Show inlining decisions for a specific package
+go build -gcflags="-m" ./pkg/handler 2>&1 | grep "inline"
+
+# Show where inlining was actually applied (function was inlined into caller)
+go build -gcflags="-m" ./... 2>&1 | grep "inlining call to"
+
+# Verbose mode — shows the cost budget and why inlining was blocked
+go build -gcflags="-m -m" ./... 2>&1 | grep "inline"
+
+# Filter to a specific function
+go build -gcflags="-m" ./pkg/handler 2>&1 | grep "HandleRequest"
+
+# Show both inlining and escape analysis together (they interact)
+go build -gcflags="-m" ./pkg/handler 2>&1 | grep -E "(inline|escape|moved to heap)"
+```
+
+### Reading the output
+
+```
+./pkg/handler/handler.go:20:6: can inline validateInput
+./pkg/handler/handler.go:35:6: cannot inline HandleRequest: function too complex: cost 120 exceeds budget 80
+./pkg/handler/handler.go:42:19: inlining call to validateInput
+```
+
+The inline cost budget is approximately 80–82 AST nodes (as of Go 1.22+; has increased in later releases). Functions with higher cost (more AST nodes, complex control flow) are not inlined. Check the actual threshold with `-gcflags="-m -m"`.
+
+### Common inlining blockers
+
+| Blocker | Why it prevents inlining | Mitigation |
+| --- | --- | --- |
+| **Function too complex** | Body cost exceeds budget (80) | Split into smaller functions; extract the cold path |
+| **`defer` statement** | Adds cleanup code that complicates inlining | Remove `defer` from tiny hot functions; call cleanup directly |
+| **`recover()` call** | Forces stack frame preservation | Move `recover()` to a wrapper function |
+| **`go` statement** | Goroutine launch has implicit complexity | Extract goroutine body into a separate function |
+| **Type switch / interface method call** | Dynamic dispatch can't be resolved at compile time | Use concrete types in hot paths |
+| **`select` statement** | Complex runtime interaction | Simplify channel patterns in hot functions |
+| **Large function body** | Many statements add up in cost | Break into smaller functions — the hot inner function may inline |
+
+**Value receivers vs pointer receivers:** Receiver choice can affect copying, aliasing, escape analysis, and inlining, but pointer receiver methods can inline too and value receivers do not guarantee inlining. Check real compiler decisions with `-gcflags="-m -m"`.
+
+## SSA Dump
+
+The SSA (Static Single Assignment) dump shows the compiler's intermediate representation after each optimization pass — dead code elimination, bounds check removal, constant folding, register allocation. Use this when you need to understand exactly what the compiler generates.
+
+### Commands
+
+```bash
+# Generate SSA dump for a specific function — creates ssa.html in current directory
+GOSSAFUNC=Parse go build ./pkg/parser
+# Open ssa.html in browser — shows each optimization pass side by side
+
+# Generate for a method on a type
+GOSSAFUNC='(*Parser).Parse' go build ./pkg/parser
+
+# Generate for a function in a specific package (when names collide)
+GOSSAFUNC=myapp/pkg/parser.Parse go build ./...
+
+# Combine with a specific output directory
+GOSSAFUNC=Parse GOSSADIR=/tmp/ssa go build ./pkg/parser
+# Creates /tmp/ssa/ssa.html
+```
+
+### Reading ssa.html
+
+The HTML file shows the function's code at each compiler pass:
+
+1. **Source** — original Go code
+2. **AST** — abstract syntax tree
+3. **Start** — initial SSA form
+4. **Opt** — after optimization passes (dead code, constant prop, bounds check elimination)
+5. **Lower** — architecture-specific lowering
+6. **Regalloc** — after register allocation
+7. **Genssa** — final generated code
+
+Click on a value in any pass to highlight it across all passes — see how the compiler transforms it. Red values were eliminated (dead code). Green values are new (introduced by a pass).
+
+**What to look for:**
+
+- **Bounds checks remaining** — `IsInBounds` or `IsSliceInBounds` operations that weren't eliminated. Adding explicit bounds checks or using `_ = s[n-1]` hints can help
+- **Dead code not eliminated** — values computed but never used (should be eliminated; if not, check for side effects)
+- **Constant folding** — computations on constants should be resolved at compile time
+- **Register spills** — values moved to stack because not enough registers; indicates heavy register pressure
+
+## Assembly Output
+
+View the actual machine code the compiler generates. Use for verifying SIMD instructions, bounds checks, register allocation, and micro-optimization decisions.
+
+### Commands
+
+```bash
+# Full assembly output for a package (very verbose)
+go build -gcflags="-S" ./pkg/parser 2>&1 | head -200
+
+# Assembly for a specific function (grep for the function name)
+go build -gcflags="-S" ./pkg/parser 2>&1 | grep -A 50 '"".Parse'
+
+# Assembly for all packages (including dependencies — very verbose)
+go build -gcflags="all=-S" ./... 2>&1 | grep -A 50 'myapp/pkg/parser.Parse'
+
+# Disassemble a compiled binary (alternative to -gcflags="-S")
+go build -o myapp ./cmd/server
+go tool objdump -s Parse myapp
+
+# Disassemble with source interleaving
+go tool objdump -S -s Parse myapp
+
+# Disassemble a specific symbol
+go tool objdump -s 'myapp/pkg/parser.Parse' myapp
+
+# Disassemble a specific text range (by address)
+go tool objdump -start 0x4a3b00 -end 0x4a3c00 myapp
+
+# List all symbols in a binary
+go tool nm myapp | grep Parse
+
+# Cross-compile and inspect assembly for a different architecture
+GOARCH=arm64 go build -gcflags="-S" ./pkg/parser 2>&1 | head -200
+```
+
+### Reading assembly output
+
+```asm
+"".Parse STEXT size=240 args=0x18 locals=0x48
+    0x0000 MOVQ (TLS), CX           ; goroutine stack check
+    0x0009 LEAQ -64(SP), AX
+    0x000e CMPQ AX, 16(CX)          ; stack overflow check
+    0x0012 JLS  228                  ; jump to stack growth
+    0x0018 SUBQ $72, SP             ; allocate stack frame
+    0x001c MOVQ BP, 64(SP)          ; save base pointer
+    0x0021 LEAQ 64(SP), BP          ; set new base pointer
+    ; ... function body ...
+    0x00e0 CALL runtime.makeslice(SB) ; heap allocation!
+```
+
+**What to look for:**
+
+- `CALL runtime.makeslice` or `CALL runtime.newobject` — heap allocations in the hot path
+- `CALL runtime.growslice` — slice capacity exceeded, triggering copy
+- `PCDATA` / `FUNCDATA` — GC metadata (ignore for performance analysis)
+- Bounds check sequences: `CMPQ` + `JCC` before array/slice access — can sometimes be eliminated
+- SIMD instructions: `VMOVDQU`, `VPSHUFB`, `VPADDB`, etc. — verify auto-vectorization or manual SIMD
+- `CALL runtime.morestack_noctxt` — stack growth (normal, but frequent calls indicate deep recursion)
+
+### Comparing assembly before/after optimization
+
+```bash
+# Before your change
+go build -gcflags="-S" ./pkg/parser 2>&1 > asm-before.txt
+
+# After your change
+go build -gcflags="-S" ./pkg/parser 2>&1 > asm-after.txt
+
+# Diff the assembly
+diff asm-before.txt asm-after.txt
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/investigation-session.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/investigation-session.md
new file mode 100644
index 00000000..6d14c3aa
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/investigation-session.md
@@ -0,0 +1,140 @@
+# Investigation Session Setup
+
+Tools and techniques for **temporary deep-dive performance investigation** — not everyday monitoring. These are things you enable for hours or days while debugging a specific issue, then disable.
+
+## Setting Up a Session
+
+Before diving into profiles, set up the environment to collect high-resolution data:
+
+1. **Reduce Prometheus scrape interval** to <=10s on the target instance (normally 15-30s). More data points during a short investigation window reveal patterns that 30s intervals miss. Revert after investigation.
+
+2. **Enable pprof** via environment variable — no recompile needed:
+
+   ```bash
+   kubectl set env deployment/my-service PPROF_ENABLED=true
+   kubectl rollout restart deployment/my-service
+   ```
+
+3. **Enable continuous profiling** on the target instance only — not fleet-wide. Pyroscope/Parca on a single instance is manageable; on 50 replicas it overwhelms the backend.
+
+   ```bash
+   kubectl set env deployment/my-service PYROSCOPE_ENABLED=true
+   kubectl rollout restart deployment/my-service
+   ```
+
+4. **Enable debug logging** via env var if needed — but only on the target instance. Debug logging has significant throughput impact:
+
+   ```bash
+   kubectl set env deployment/my-service LOG_LEVEL=debug
+   kubectl rollout restart deployment/my-service
+   ```
+
+**Key principle:** all costly debug features (pprof HTTP, continuous profiling, debug log level, trace collection) SHOULD be configurable via environment variables. This allows instant toggle without recompile. Design your application to support this from day one.
+
+## Prometheus Go Runtime Collector
+
+The `prometheus/client_golang` library automatically registers collectors that expose Go runtime metrics. These are invaluable during investigation sessions — they provide a time-series view of memory, GC, goroutines, and CPU that complements point-in-time profiles.
+
+When using `prometheus/client_golang`, refer to the library's official documentation to verify collector setup and available options.
+
+### Key Series
+
+→ See [prometheus-go-metrics.md](./prometheus-go-metrics.md) for the **exhaustive reference** of all Go runtime metrics (verified from official sources). **Note:** runtime/metrics list varies by Go version — use `metrics.All()` at runtime for your specific Go version.
+
+**Performance note:** `go_memstats_*` metrics internally call `runtime.ReadMemStats()`, which triggers a short stop-the-world pause. In Go 1.17+, the runtime/metrics collector (`collectors.NewGoCollector()`) uses `runtime/metrics` instead, which is cheaper. Prefer the modern collector in high-throughput services:
+
+```go
+import "github.com/prometheus/client_golang/prometheus/collectors"
+
+// Use runtime/metrics-based collector (lower overhead)
+reg := prometheus.NewRegistry()
+reg.MustRegister(collectors.NewGoCollector(
+    collectors.WithGoCollectorRuntimeMetrics(collectors.MetricsAll),
+))
+reg.MustRegister(collectors.NewProcessCollector(collectors.ProcessCollectorOpts{}))
+```
+
+## PromQL Deep-Dive Queries
+
+Use these during investigation sessions with the reduced scrape interval. Each query includes what to look for and what the result means.
+
+### GC pressure
+
+| PromQL | What to look for |
+| --- | --- |
+| `rate(go_gc_duration_seconds_count[5m])` | GC cycles/s. >2/s sustained = excessive allocation rate. Reduce allocations per request. |
+| `rate(go_gc_duration_seconds_sum[5m]) / rate(go_gc_duration_seconds_count[5m])` | Average GC pause. Increasing trend = heap growing or too many pointers to scan. |
+| `go_gc_duration_seconds{quantile="1"}` | Worst-case GC pause. Spikes here cause tail latency (P99). |
+
+### Memory leak detection
+
+| PromQL | What to look for |
+| --- | --- |
+| `go_memstats_alloc_bytes` | Should be roughly stable under constant load. Continuous increase = memory leak. |
+| `rate(go_memstats_alloc_bytes_total[5m])` | Allocation rate (bytes/s). Compare before/after deploy — significant increase = new allocation pattern. |
+| `process_resident_memory_bytes - go_memstats_sys_bytes` | Gap = non-Go memory (cgo, mmap). Growing gap = non-Go leak. |
+
+### Goroutine leak detection
+
+| PromQL | What to look for |
+| --- | --- |
+| `go_goroutines` | Should correlate with load. Growing independently of traffic = leak. |
+| `delta(go_goroutines[1h])` | Net goroutine change over 1h. Positive without load increase = leak. |
+
+### CPU saturation
+
+| PromQL | What to look for |
+| --- | --- |
+| `rate(process_cpu_seconds_total[5m])` | CPU cores consumed. Compare to GOMAXPROCS. |
+| `rate(process_cpu_seconds_total[5m]) / <GOMAXPROCS>` | CPU utilization ratio. >0.8 sustained = CPU-saturated. |
+
+### Post-deploy regression detection
+
+| PromQL | What to look for |
+| --- | --- |
+| `rate(go_memstats_alloc_bytes_total[5m])` | Compare before/after deploy window. Significant increase = new allocation pattern introduced. |
+| `histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))` | P99 latency increase after deploy = performance regression. Requires app-level histogram. |
+
+### Example alerting rules
+
+```yaml
+# GC taking too much time
+- alert: HighGCPauseTime
+  expr: rate(go_gc_duration_seconds_sum[5m]) / rate(go_gc_duration_seconds_count[5m]) > 0.01
+  for: 10m
+  annotations:
+    summary: "Average GC pause >10ms — reduce allocations or tune GOGC"
+
+# Goroutine leak
+- alert: GoroutineLeak
+  expr: go_goroutines > 10000
+  for: 5m
+  annotations:
+    summary: "Goroutine count >10K — check for leaked goroutines"
+
+# Memory approaching container limit
+- alert: MemoryNearLimit
+  expr: predict_linear(process_resident_memory_bytes[1h], 3600) > <container_limit_bytes>
+  for: 15m
+  annotations:
+    summary: "RSS projected to exceed container limit within 1h"
+```
+
+Adjust thresholds to your application — a data pipeline has different baselines than an API server.
+
+## Host-Level Correlation
+
+Go runtime metrics alone don't show the full picture. Host-level metrics reveal whether the problem is in your application or the infrastructure.
+
+- **`node_exporter`** — host CPU, memory, disk I/O, network. Correlate with Go app metrics: high `node_cpu_seconds_total` with low `process_cpu_seconds_total` = noisy neighbor, not your app.
+- **`process-exporter`** — per-process metrics on Linux. Useful when multiple Go services share a host.
+
+## Cost Warnings
+
+**Profiles and traces are expensive to collect.** Keep them short-term and localized:
+
+- **pprof CPU profiling** — CPU-intensive during the capture window. Don't run 30s profiles back-to-back in production. Space them out.
+- **Pyroscope continuous profiling** — ~2-5% CPU overhead **per instance, always-on**. At scale (hundreds of instances), this adds up in compute cost and backend storage. Enable on a subset of instances or on-demand via environment variable. → See `samber/cc-skills-golang@golang-observability` skill for Pyroscope setup.
+- **Execution traces** — generate large files quickly (MB/s). Capture 5-10s max. Longer traces are unwieldy and slow to analyze.
+- **Debug log level** — significant throughput impact due to allocation and I/O overhead. Never leave on permanently.
+- **All costly features** SHOULD be toggleable via environment variables for instant on/off without recompile. Design for this from day one.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/pprof.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/pprof.md
new file mode 100644
index 00000000..db5465d6
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/pprof.md
@@ -0,0 +1,844 @@
+# pprof Reference
+
+`go tool pprof` is the primary tool for understanding where CPU time, memory, and contention go in Go programs. This file covers how to **use** the CLI and **interpret** the output. For enabling pprof endpoints on running services (net/http/pprof import, authentication, security), → See `samber/cc-skills-golang@golang-troubleshooting` skill.
+
+## Profile Types
+
+Each profile type answers a different performance question. Choosing the wrong profile type wastes investigation time — match the symptom to the profile before capturing.
+
+| Profile | Flag / Endpoint | Use when | Why this profile and not another |
+| --- | --- | --- | --- |
+| **CPU** | `-cpuprofile` or `/debug/pprof/profile?seconds=30` | High CPU usage, slow functions | Samples which functions are on-CPU at 100Hz; misses off-CPU time (I/O, sleep) |
+| **Heap (alloc_objects)** | `-memprofile` then `pprof -alloc_objects` | GC pressure, too many allocations | Counts allocation events regardless of size; useful when allocation frequency and object churn dominate |
+| **Heap (alloc_space)** | `pprof -alloc_space` | Finding largest allocation sites by volume | Measures total bytes allocated; use when you need to reduce peak memory, not just GC frequency |
+| **Heap (inuse_space)** | `pprof -inuse_space` | Memory growing over time, suspected leaks | Shows currently live heap objects; compare two snapshots to isolate leak sources |
+| **Heap (inuse_objects)** | `pprof -inuse_objects` | Object count growth, suspected leak of small objects | Counts live objects regardless of size; useful when leak is many small objects not visible in inuse_space |
+| **Goroutine** | `/debug/pprof/goroutine` | Blocked I/O, goroutine leaks, pool exhaustion | Snapshots all goroutine stacks; look for goroutines piling up on the same call site |
+| **Mutex** | `/debug/pprof/mutex` | Lock contention between goroutines | Measures cumulative time goroutines waited to acquire mutexes. Must enable first: `runtime.SetMutexProfileFraction(5)` |
+| **Block** | `/debug/pprof/block` | Goroutines blocked on channels, mutexes, timers, select | Measures cumulative time goroutines spent blocked on synchronization primitives. Must enable first: `runtime.SetBlockProfileRate(1)` |
+| **Threadcreate** | `/debug/pprof/threadcreate` | Excessive OS thread creation | Shows stack traces that created new OS threads; typically from cgo calls or blocking syscalls that pin a thread |
+
+### Choosing between alloc_objects and alloc_space
+
+- **alloc_objects** — "where do I allocate the most often?" — use when allocation frequency and object churn are driving GC work
+- **alloc_space** — "where do I allocate the most bytes?" — use for reducing peak memory usage and RSS
+- In practice, start with `alloc_objects` because GC churn is the most common allocation-related bottleneck in Go.
+
+### Choosing between inuse_space and alloc_space
+
+- **alloc_space** is cumulative since program start — it includes objects already freed by GC
+- **inuse_space** is a point-in-time snapshot — only currently live objects
+- Use `alloc_space` to find allocation hot spots for optimization. Use `inuse_space` to debug memory leaks.
+
+### Enabling mutex and block profiles
+
+These profiles are disabled by default because they add overhead. Enable them before capturing:
+
+```go
+import "runtime"
+
+// Mutex profiling: fraction of mutex contention events recorded.
+// 5 means 1 out of 5 events is recorded. Higher = less overhead but less detail.
+runtime.SetMutexProfileFraction(5)
+
+// Block profiling: time-based sampling rate.
+// 1 = record all blocking events. Higher values sample about one event per rate nanoseconds blocked.
+// Use 1 for debugging, higher values (e.g. 1000000 = 1ms) for production.
+runtime.SetBlockProfileRate(1)
+```
+
+Disable after investigation to eliminate overhead:
+
+```go
+runtime.SetMutexProfileFraction(0)
+runtime.SetBlockProfileRate(0)
+```
+
+## Generating Profiles
+
+### From benchmarks (no HTTP server needed)
+
+```bash
+# CPU profile — measures where compute time goes during benchmark execution
+go test -bench=BenchmarkParse -cpuprofile=cpu.prof ./pkg/parser
+
+# Memory profile — captures allocation patterns during benchmark
+go test -bench=BenchmarkParse -memprofile=mem.prof ./pkg/parser
+
+# Both at once — but be aware CPU profiling adds ~5% overhead which can skew memory results
+go test -bench=BenchmarkParse -cpuprofile=cpu.prof -memprofile=mem.prof ./pkg/parser
+```
+
+### From running service
+
+Requires `import _ "net/http/pprof"` (see `samber/cc-skills-golang@golang-troubleshooting` skill for secure setup):
+
+```bash
+# CPU profile — captures 30 seconds of CPU samples
+go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
+
+# Heap profile — snapshots current heap state
+go tool pprof -alloc_objects http://localhost:6060/debug/pprof/heap
+
+# Goroutine profile — snapshots all goroutine stacks
+go tool pprof http://localhost:6060/debug/pprof/goroutine
+
+# Mutex profile — contention data since last reset
+go tool pprof http://localhost:6060/debug/pprof/mutex
+
+# Block profile — blocking data since last reset
+go tool pprof http://localhost:6060/debug/pprof/block
+```
+
+### From code (programmatic)
+
+```go
+import "runtime/pprof"
+
+// CPU profile
+f, _ := os.Create("cpu.prof")
+pprof.StartCPUProfile(f)
+defer pprof.StopCPUProfile()
+
+// Heap snapshot at a specific point
+f, _ := os.Create("heap.prof")
+pprof.WriteHeapProfile(f)
+f.Close()
+
+// Named profile (goroutine, threadcreate, etc.)
+pprof.Lookup("goroutine").WriteTo(f, 0)
+```
+
+## Interactive CLI Commands
+
+Open a profile in interactive mode:
+
+```bash
+go tool pprof cpu.prof
+# or from a URL:
+go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
+```
+
+### `top` — self time ranking (start here)
+
+The first command to run. Shows functions ranked by the time (or allocations) spent in the function itself:
+
+```
+(pprof) top
+Showing nodes accounting for 4.2s, 84% of 5s total
+      flat  flat%   sum%        cum   cum%
+     1.50s 30.00% 30.00%      2.80s 56.00%  encoding/json.Marshal
+     0.80s 16.00% 46.00%      0.80s 16.00%  runtime.mallocgc
+     0.60s 12.00% 58.00%      0.60s 12.00%  runtime.memmove
+     0.50s 10.00% 68.00%      0.50s 10.00%  runtime.scanobject
+     0.40s  8.00% 76.00%      1.90s 38.00%  myapp/pkg/parser.Parse
+     0.30s  6.00% 82.00%      0.30s  6.00%  syscall.syscall
+     0.10s  2.00% 84.00%      0.10s  2.00%  runtime.futex
+```
+
+| Column | Meaning | How to read it |
+| --- | --- | --- |
+| **flat** | Time spent in the function itself, excluding callees | High flat = the function's own code is expensive |
+| **flat%** | flat as percentage of total sample time | Quick way to see relative cost |
+| **sum%** | Running total of flat% going down the list | "The top 3 functions account for 58% of total time" |
+| **cum** | Time in function + all functions it calls (cumulative) | High cum with low flat = the function delegates to expensive callees |
+| **cum%** | cum as percentage of total | Compare with flat% — big gap means the cost is in callees |
+
+**Limiting output:**
+
+```
+(pprof) top 5              # show only top 5 functions
+(pprof) top -cum 10        # top 10 by cumulative time
+(pprof) top -flat 20       # top 20 by flat time (default sort)
+```
+
+### `top -cum` — cumulative time ranking
+
+Critical when `top` shows runtime functions (`runtime.mallocgc`, `runtime.memmove`, `runtime.scanobject`) dominating. These are symptoms, not causes. `top -cum` reveals which **application** functions trigger them:
+
+```
+(pprof) top -cum
+      flat  flat%   sum%        cum   cum%
+     0.40s  8.00%  8.00%      3.80s 76.00%  myapp/pkg/handler.HandleRequest
+     0.10s  2.00% 10.00%      2.80s 56.00%  myapp/pkg/handler.serializeResponse
+     1.50s 30.00% 40.00%      2.80s 56.00%  encoding/json.Marshal
+```
+
+Now you can see that `HandleRequest` → `serializeResponse` → `json.Marshal` is the hot path. The optimization target is `serializeResponse`, not `runtime.mallocgc`.
+
+### `list funcName` — annotated source
+
+Shows the source code of a function with per-line cost annotations. This is how you pinpoint the **exact line** causing the bottleneck:
+
+```
+(pprof) list serializeResponse
+Total: 5s
+ROUTINE ======================== myapp/pkg/handler.serializeResponse
+     0.10s      2.80s (flat, cum) 56.00% of Total
+         .          .     38:func serializeResponse(w http.ResponseWriter, data any) {
+         .      0.20s     39:    w.Header().Set("Content-Type", "application/json")
+     0.10s      2.60s     40:    buf, err := json.Marshal(data)
+         .          .     41:    if err != nil {
+         .          .     42:        http.Error(w, err.Error(), 500)
+         .          .     43:        return
+         .          .     44:    }
+         .      0.20s     45:    w.Write(buf)
+         .          .     46:}
+```
+
+- Left column = **flat** time (work done by this line itself)
+- Right column = **cumulative** time (this line + everything it calls)
+- Line 40 accounts for 2.60s cumulative because `json.Marshal` is expensive
+
+**Use `list` with a regex** to find all matching functions:
+
+```
+(pprof) list Parse.*       # all functions starting with Parse
+(pprof) list \.Handle      # all Handle methods across packages
+```
+
+### `peek funcName` — callers and callees
+
+Shows who calls a function and what it calls — the one-hop neighborhood in the call graph. Use to trace the responsibility chain when a function appears hot but you're unsure whether the problem is upstream (too many calls) or downstream (expensive callees):
+
+```
+(pprof) peek json.Marshal
+Showing nodes accounting for 5s, 100% of 5s total
+----------------------------------------------+-------------
+                                               |      flat  flat%   sum%        cum   cum%
+ myapp/pkg/handler.serializeResponse 2.60s     |
+ myapp/pkg/api.buildResponse         0.20s     |     1.50s 30.00% 30.00%      2.80s 56.00%  encoding/json.Marshal
+----------------------------------------------+-------------
+                                               |
+ reflect.Value.MapRange              0.40s     |
+ encoding/json.(*encodeState).marshal 0.30s    |
+ runtime.mallocgc                     0.80s    |
+```
+
+Top section = callers (who calls json.Marshal). Bottom section = callees (what json.Marshal calls internally).
+
+### `tree` — hierarchical call tree
+
+Displays the full call tree with cumulative costs at each level. Useful when you need more context than `peek` provides:
+
+```
+(pprof) tree
+     0.40s  8.00%  8.00%      3.80s 76.00%  myapp/pkg/handler.HandleRequest
+              0.10s  myapp/pkg/handler.serializeResponse
+                     1.50s  encoding/json.Marshal
+                            0.80s  runtime.mallocgc
+              0.20s  myapp/pkg/handler.validateInput
+              0.10s  myapp/pkg/handler.fetchData
+```
+
+### `traces` — raw stack traces
+
+Dumps all raw sample stack traces. Each stack trace shows what the program was doing at the moment it was sampled:
+
+```
+(pprof) traces
+-----------+-------------------------------------------------------
+     bytes:  1.5MB
+     1.50s   encoding/json.Marshal
+             myapp/pkg/handler.serializeResponse
+             myapp/pkg/handler.HandleRequest
+             net/http.(*ServeMux).ServeHTTP
+-----------+-------------------------------------------------------
+```
+
+Useful for spotting unexpected call paths (e.g., a function you didn't expect being called from a hot path).
+
+### `web` / `svg` — graphical call graph
+
+`web` opens a call graph in the browser. `svg` saves it to a file. Both require graphviz installed (`brew install graphviz` or `apt install graphviz`).
+
+Visual encoding:
+
+- **Thicker edges** = more time flows through that call
+- **Larger nodes** = more time spent in that function
+- **Red/dark nodes** = hot spots (high flat time)
+- **Edge labels** = time flowing through that call path
+
+Use when the text commands don't reveal the full picture — the visual layout often reveals call patterns that are hard to see in text.
+
+### `disasm funcName` — assembly-level
+
+Shows generated assembly with per-instruction cost. Use for micro-optimization: verifying SIMD instructions, bounds check elimination, or inlining at the instruction level:
+
+```
+(pprof) disasm Parse
+Total: 5s
+ROUTINE ======================== myapp/pkg/parser.Parse
+     0.40s      1.90s (flat, cum) 38.00% of Total
+     0.10s      0.10s    4a3b20: MOVQ 0x8(SP), AX          ;parser.go:15
+     0.20s      0.20s    4a3b28: CMPQ AX, $0x100           ;parser.go:16
+         .      0.10s    4a3b2f: JGE 0x4a3b80              ;parser.go:16
+     0.10s      1.50s    4a3b35: CALL runtime.makeslice(SB) ;parser.go:17
+```
+
+### `weblist funcName` — annotated source in browser
+
+Like `list` but opens the annotated source in a browser with color-coded cost highlighting. Each line is shaded from white (no cost) to red (hot). More visually immediate than the text version:
+
+```
+(pprof) weblist serializeResponse
+```
+
+Requires a browser. Falls back to `list` if no browser is available.
+
+### `tags` — profile label breakdown
+
+Shows tag values present in the profile. Go runtime profiles carry tags like `thread_id`; custom profiles can add arbitrary labels via `pprof.Do()`:
+
+```go
+labels := pprof.Labels("request_type", "api", "endpoint", "/users")
+pprof.Do(ctx, labels, func(ctx context.Context) {
+    handleRequest(ctx)
+})
+```
+
+```
+(pprof) tags
+request_type: api (85%), batch (15%)
+endpoint: /users (40%), /orders (35%), /products (25%)
+```
+
+### `tagroot` and `tagleaf` — group by labels
+
+Group the profile data by tag values, creating a virtual call tree rooted on tag names:
+
+```
+(pprof) tagroot request_type    # group everything by request_type first
+(pprof) top                     # now shows breakdown per request_type
+(pprof) tagleaf endpoint        # add endpoint as leaf grouping
+```
+
+Useful for multi-tenant profiling or breaking down by request type without code changes.
+
+### `granularity` — control grouping level
+
+Changes how samples are aggregated:
+
+```
+(pprof) granularity=functions    # default — group by function name
+(pprof) granularity=filefunctions # group by file:function
+(pprof) granularity=files        # group by file only
+(pprof) granularity=lines        # group by exact source line
+(pprof) granularity=addresses    # group by instruction address (most granular)
+```
+
+`lines` is especially useful when a single function has multiple hot spots — it reveals which specific lines are expensive without needing `list`.
+
+### `sort` — change sort order
+
+```
+(pprof) sort=flat     # sort by flat time (default for top)
+(pprof) sort=cum      # sort by cumulative time (same as top -cum)
+```
+
+### `source` — show source for matching regex
+
+Similar to `list` but searches all functions matching a pattern and shows their annotated source:
+
+```
+(pprof) source handler   # show annotated source for all functions matching "handler"
+```
+
+### `focus`, `ignore`, `hide`, `show` — filtering
+
+Narrow the analysis to specific functions or exclude noise. These are stateful — they persist across commands until explicitly cleared:
+
+```
+(pprof) focus=myapp            # only show call paths that pass through "myapp"
+(pprof) ignore=runtime         # remove runtime functions from display
+(pprof) hide=testing           # hide testing framework noise from graphs
+(pprof) show=handler           # only show functions matching "handler"
+(pprof) tagfocus=endpoint=/users  # only show samples with this tag value
+(pprof) tagignore=request_type=batch  # exclude samples with this tag value
+```
+
+**Difference between `focus`, `show`, `hide`, and `ignore`:**
+
+- `focus` — keeps only paths that contain a matching function; everything else is dropped
+- `ignore` — removes matching functions from the graph entirely; their costs are attributed to callers
+- `show` — like `focus` but only affects display, not cost accounting
+- `hide` — like `ignore` but only hides from display, not cost accounting
+
+**Clear all filters:**
+
+```
+(pprof) reset
+```
+
+### `normalize` — normalize against a base profile
+
+When comparing two profiles with `-base`, values are deltas by default. `normalize` scales the base profile to match the total of the main profile, making ratios comparable even if run durations differ:
+
+```
+(pprof) normalize
+```
+
+### `sample_index` — switch metric in multi-metric profiles
+
+Heap profiles contain multiple metrics (alloc_objects, alloc_space, inuse_objects, inuse_space). Switch between them without reloading:
+
+```
+(pprof) sample_index=alloc_objects
+(pprof) top                       # now shows allocation counts
+(pprof) sample_index=inuse_space
+(pprof) top                       # now shows live memory
+```
+
+### `unit` — change display units
+
+```
+(pprof) unit=ms         # display time in milliseconds
+(pprof) unit=seconds    # display in seconds
+(pprof) unit=MB         # display memory in megabytes
+(pprof) unit=auto       # automatic (default)
+```
+
+### `callgrind` — export for KCachegrind
+
+Exports the profile in callgrind format, which can be opened in KCachegrind or QCachegrind for advanced visualization:
+
+```
+(pprof) callgrind
+Generating report in callgrind format
+```
+
+### `proto` — save processed profile
+
+Save the current profile (after filtering) in protobuf format for sharing or later analysis:
+
+```
+(pprof) proto > filtered.pb.gz
+```
+
+### `help` — list all commands
+
+```
+(pprof) help             # full command list with descriptions
+(pprof) help top         # detailed help for a specific command
+```
+
+### `show_from=regex` — trim callers above match
+
+Hides all frames above the first matching function. Useful when you're only interested in a specific subsystem and want to remove framework/routing noise above it:
+
+```
+(pprof) show_from=handler.Handle   # start the graph from Handle, hide all callers above
+```
+
+### `noinlines` — flatten inlined functions
+
+Attributes inlined functions to their first out-of-line caller. Useful when inlined functions create confusing call chains in the graph:
+
+```
+(pprof) noinlines
+```
+
+### Full command reference
+
+Every command below works both as a standalone shell command and inside the interactive `(pprof)` prompt. The interactive form omits `go tool pprof` and the profile path — e.g., `go tool pprof -top cpu.prof` becomes just `top` inside the prompt.
+
+**Reporting commands:**
+
+```bash
+# Top functions by self (flat) cost — the first command to run
+go tool pprof -top cpu.prof
+
+# Top 20 functions by cumulative cost (self + callees)
+go tool pprof -cum -top -nodecount=20 cpu.prof
+
+# Annotated source for a specific function — pinpoints the exact expensive line
+go tool pprof -list=json.Marshal cpu.prof
+
+# Callers and callees of a function — trace the responsibility chain
+go tool pprof -peek=serializeResponse cpu.prof
+
+# Hierarchical call tree with costs at each level
+go tool pprof -tree cpu.prof
+
+# Raw sample stack traces — spot unexpected call paths
+go tool pprof -traces cpu.prof
+
+# Per-instruction assembly cost — verify SIMD, bounds checks, inlining
+go tool pprof -disasm=Parse cpu.prof
+
+# Annotated source for all functions matching a regex
+go tool pprof -source='handler\..*' cpu.prof
+
+# Text output (flat table, alternative to -top)
+go tool pprof -text cpu.prof
+```
+
+**Graph/export commands:**
+
+```bash
+# SVG call graph (viewable in any browser, no graphviz server needed)
+go tool pprof -svg cpu.prof > cpu.svg
+
+# SVG of only the subgraph matching a regex
+go tool pprof -svg -focus=handler cpu.prof > handler.svg
+
+# PDF call graph
+go tool pprof -pdf cpu.prof > cpu.pdf
+
+# PNG call graph
+go tool pprof -png cpu.prof > cpu.png
+
+# GIF call graph
+go tool pprof -gif cpu.prof > cpu.gif
+
+# DOT format (for custom graphviz processing: dot -Tsvg cpu.dot > cpu.svg)
+go tool pprof -dot cpu.prof > cpu.dot
+
+# Callgrind format (open with KCachegrind / QCachegrind)
+go tool pprof -callgrind cpu.prof > cpu.callgrind
+
+# Save current profile (with filters applied) in protobuf format
+go tool pprof -proto -focus=handler cpu.prof > handler-only.pb.gz
+
+# Annotated source in browser with color-coded cost per line
+go tool pprof -weblist=serializeResponse cpu.prof
+```
+
+**Filtering flags** — narrow analysis to relevant functions:
+
+```bash
+# Focus: keep only call paths passing through matching functions
+go tool pprof -focus=myapp/pkg/handler -top cpu.prof
+
+# Ignore: remove matching functions — their cost is attributed to callers
+go tool pprof -ignore=runtime -top cpu.prof
+
+# Show: display only matching functions (display-only, does not change cost accounting)
+go tool pprof -show=handler -top cpu.prof
+
+# Hide: hide matching functions from display (does not change cost accounting)
+go tool pprof -hide=testing -svg cpu.prof > clean.svg
+
+# Show_from: trim all frames above the first match — hides framework/routing callers
+go tool pprof -show_from=handler.Handle -top cpu.prof
+
+# Noinlines: attribute inlined functions to their first out-of-line caller
+go tool pprof -noinlines -top cpu.prof
+
+# Combine multiple filters
+go tool pprof -cum -top -nodecount=10 -focus=handler -ignore=runtime cpu.prof
+```
+
+**Tag-based filtering** — for profiles with labels (via `pprof.Do()`):
+
+```bash
+# Show all tag keys and their value distributions
+go tool pprof -tags cpu.prof
+
+# Keep only samples tagged with a specific key=value
+go tool pprof -tagfocus=endpoint=/users -top cpu.prof
+
+# Exclude samples with a specific tag
+go tool pprof -tagignore=request_type=batch -top cpu.prof
+
+# Group by tag — insert pseudo frames at root, breaking down by tag value
+go tool pprof -tagroot=request_type -top cpu.prof
+
+# Group by tag as leaf — breaks down each function by tag value
+go tool pprof -tagleaf=endpoint -top cpu.prof
+
+# Show/hide tags as annotations in graph output
+go tool pprof -tagshow=endpoint -svg cpu.prof > tagged.svg
+go tool pprof -taghide=thread_id -svg cpu.prof > clean.svg
+```
+
+**Granularity and display control:**
+
+```bash
+# Group by source line instead of function — reveals hot lines in multi-hot-spot functions
+go tool pprof -granularity=lines -top cpu.prof
+
+# Group by file:function
+go tool pprof -granularity=filefunctions -top cpu.prof
+
+# Group by file only
+go tool pprof -granularity=files -top cpu.prof
+
+# Group by instruction address (most granular)
+go tool pprof -granularity=addresses -top cpu.prof
+
+# Change display units
+go tool pprof -unit=ms -top cpu.prof
+
+# Edge/node fraction cutoffs — hide small contributions from graphs
+go tool pprof -edgefraction=0.01 -nodefraction=0.005 -svg cpu.prof > clean.svg
+
+# Disable trimming — show the full graph including tiny nodes
+go tool pprof -trim=false -svg cpu.prof > full.svg
+```
+
+**Heap profile commands:**
+
+```bash
+# Top allocation sites by object count — diagnose GC churn
+go tool pprof -top -alloc_objects mem.prof
+
+# Top allocation sites by bytes — diagnose peak memory
+go tool pprof -top -alloc_space mem.prof
+
+# Currently live objects — diagnose memory leaks
+go tool pprof -top -inuse_space mem.prof
+
+# Currently live object count — diagnose leak of many small objects
+go tool pprof -top -inuse_objects mem.prof
+
+# Annotated source showing allocation sites by object count
+go tool pprof -alloc_objects -list=Parse mem.prof
+
+# SVG call graph colored by allocation objects
+go tool pprof -alloc_objects -svg mem.prof > allocs.svg
+
+# Compare two heap snapshots — show only growth (memory leak detection)
+go tool pprof -top -base heap-baseline.prof heap-after.prof
+
+# Diff with normalization — makes ratios comparable when capture durations differ
+go tool pprof -normalize -top -base heap-baseline.prof heap-after.prof
+
+# Diff as SVG — visualize what grew
+go tool pprof -base heap-baseline.prof -svg heap-after.prof > leak.svg
+
+# Diff with annotated source for a specific function
+go tool pprof -base heap-baseline.prof -list=handleRequest heap-after.prof
+```
+
+**Fetching profiles from a running service:**
+
+```bash
+# CPU profile — fetch 30 seconds of samples and open interactive mode
+go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
+
+# CPU profile — fetch and immediately generate SVG (no interactive mode)
+go tool pprof -svg http://localhost:6060/debug/pprof/profile?seconds=10 > cpu.svg
+
+# CPU profile — fetch with a timeout
+go tool pprof -timeout=60 "http://localhost:6060/debug/pprof/profile?seconds=30"
+
+# Heap profile — fetch and show top allocation sites
+go tool pprof -top -alloc_objects http://localhost:6060/debug/pprof/heap
+
+# Goroutine profile — fetch and show top goroutine stacks
+go tool pprof -top http://localhost:6060/debug/pprof/goroutine
+
+# Mutex profile — fetch contention data
+go tool pprof -top http://localhost:6060/debug/pprof/mutex
+
+# Block profile — fetch blocking data
+go tool pprof -top http://localhost:6060/debug/pprof/block
+
+# Fetch and save to a file without analysis (using curl)
+curl -o heap.prof http://localhost:6060/debug/pprof/heap
+
+# Human-readable goroutine dump (no go tool pprof needed)
+curl http://localhost:6060/debug/pprof/goroutine?debug=1
+
+# Goroutine dump with full stack traces, creation site, and labels
+curl http://localhost:6060/debug/pprof/goroutine?debug=2
+
+# Human-readable heap stats
+curl http://localhost:6060/debug/pprof/heap?debug=1
+
+# Fetch over TLS with client certificate
+go tool pprof -tls_cert=client.crt -tls_key=client.key -tls_ca=ca.crt https://myservice:6060/debug/pprof/profile?seconds=30
+
+# Fetch over TLS skipping server certificate verification
+go tool pprof https+insecure://myservice:6060/debug/pprof/profile?seconds=30
+```
+
+**Comparison commands (diff two profiles):**
+
+```bash
+# Diff: subtract base from source — all values become deltas
+go tool pprof -base cpu-before.prof cpu-after.prof
+
+# Diff base: percentages shown relative to base profile
+go tool pprof -diff_base=cpu-before.prof cpu-after.prof
+
+# Diff with normalization — scale base to match source total
+go tool pprof -normalize -base heap-before.prof heap-after.prof
+
+# Diff as top report
+go tool pprof -top -base cpu-before.prof cpu-after.prof
+
+# Diff as SVG graph
+go tool pprof -svg -base cpu-before.prof cpu-after.prof > diff.svg
+```
+
+**Web UI:**
+
+```bash
+# Open interactive web UI with flamegraph, graph, source, and disassembly views
+go tool pprof -http=:8080 cpu.prof
+
+# Open on a different port
+go tool pprof -http=:9090 mem.prof
+
+# Open with a specific sample type pre-selected
+go tool pprof -http=:8080 -alloc_objects mem.prof
+
+# Open with filters pre-applied
+go tool pprof -http=:8080 -focus=handler cpu.prof
+
+# Open a diff view in the web UI
+go tool pprof -http=:8080 -base heap-baseline.prof heap-after.prof
+
+# Open with no browser auto-launch (just start the server)
+go tool pprof -http=:8080 -no_browser cpu.prof
+```
+
+**Symbolization flags:**
+
+```bash
+# Disable symbolization (show raw addresses)
+go tool pprof -symbolize=none cpu.prof
+
+# Only use local binaries for symbolization (don't contact remote)
+go tool pprof -symbolize=local cpu.prof
+
+# Contact running service for symbol information
+go tool pprof -symbolize=remote http://localhost:6060/debug/pprof/profile?seconds=10
+
+# Show mangled C++ names (relevant for cgo profiles)
+go tool pprof -symbolize=demangle=none cpu.prof
+
+# Full demangling without simplification
+go tool pprof -symbolize=demangle=full cpu.prof
+```
+
+**Environment variables:**
+
+| Variable | Purpose |
+| --- | --- |
+| `PPROF_BINARY_PATH` | Search path for local binaries used in symbolization (default: `$HOME/pprof/binaries`). Set when profiling remote servers where binaries aren't in the default path. |
+| `PPROF_TOOLS` | Directory containing binutils tools (`addr2line`, `nm`, `objdump`). Set when these tools aren't in `$PATH`. |
+
+## Graphical / Web UI
+
+When CLI output is insufficient and you need interactive exploration:
+
+```bash
+# Opens browser with interactive UI
+go tool pprof -http=:8080 cpu.prof
+
+# Specify a different port if 8080 is taken
+go tool pprof -http=:9090 mem.prof
+
+# Open with specific sample type pre-selected
+go tool pprof -http=:8080 -alloc_objects mem.prof
+
+# Open with filters pre-applied
+go tool pprof -http=:8080 -focus=handler cpu.prof
+
+# Compare two profiles — open with -base
+go tool pprof -http=:8080 -base heap-baseline.prof heap-after.prof
+```
+
+The web UI provides:
+
+- **Flamegraph** (most intuitive) — horizontal width proportional to cost; click to zoom into subtrees; inverted flamegraph available (icicle graph)
+- **Graph** — directed call graph with edge weights; nodes and edges sized/colored by cost; interactive zoom and click-to-focus
+- **Top** — same as `top` command but sortable columns, clickable to navigate to source
+- **Source** — annotated source with per-line cost; browsable across all functions
+- **Disassembly** — same as `disasm` but browsable across functions
+- **Peek** — interactive peek view with expandable callers/callees
+
+Default to CLI commands for quick diagnosis — use the web UI when exploring unfamiliar call graphs, comparing profiles visually, or presenting findings to others.
+
+## Comparing Profiles
+
+### Memory leak detection with `-base`
+
+Compare two heap profiles to isolate what grew between them:
+
+```bash
+# Step 1: take a baseline snapshot
+curl http://localhost:6060/debug/pprof/heap > heap-baseline.prof
+
+# Step 2: wait for the suspected leak to accumulate (minutes to hours)
+
+# Step 3: take a second snapshot
+curl http://localhost:6060/debug/pprof/heap > heap-after.prof
+
+# Step 4: diff — shows only what grew between the two snapshots
+go tool pprof -base heap-baseline.prof heap-after.prof
+# Then use top, list, peek as usual — all values are deltas
+```
+
+### Comparing CPU profiles across code versions
+
+```bash
+# Before your change
+go test -bench=BenchmarkParse -cpuprofile=cpu-before.prof ./pkg/parser
+
+# After your change
+go test -bench=BenchmarkParse -cpuprofile=cpu-after.prof ./pkg/parser
+
+# Compare visually — load both in separate browser tabs
+go tool pprof -http=:8080 cpu-before.prof
+go tool pprof -http=:8081 cpu-after.prof
+```
+
+For statistical comparison of benchmark numbers (not profiles), use [benchstat](./benchstat.md) instead.
+
+## Common Patterns
+
+Learn to recognize these recurring shapes — they tell you what class of problem you're dealing with before you start fixing.
+
+### Flat high + cum high
+
+The function itself is the bottleneck. It does expensive work directly (tight loop, heavy computation, complex string processing). Optimize the function's own code — algorithm, data structure, or implementation.
+
+### Flat low + cum high
+
+The function calls slow things but does little work itself. It's a coordinator or dispatcher. Drill into callees with `list` or `peek`. The fix is usually in the called functions, or reducing how often they're called.
+
+### `alloc_objects` high, `inuse_space` low
+
+Short-lived allocations creating GC churn. Objects are allocated and freed rapidly — each one is cheap individually but the aggregate volume triggers frequent GC cycles. Common sources: `fmt.Errorf` in hot paths (allocates every call), interface boxing (`any` arguments), string-to-byte conversions, slice growth without preallocation. → See `samber/cc-skills-golang@golang-performance` skill for allocation reduction patterns.
+
+### `inuse_space` growing over time
+
+Memory leak. Take two heap snapshots minutes apart and compare with `-base` (see Comparing Profiles above). Growing types reveal the leak source. Common causes: unbounded caches, maps that never shrink (Go maps don't release bucket memory on delete), goroutine leaks holding references.
+
+### Mutex/block profile hot
+
+Contention, not CPU. The CPU is waiting, not working. The goroutines are all trying to acquire the same lock or read from the same channel. Reduce critical section scope, shard locks across multiple mutexes, or use lock-free structures (`sync/atomic`, `sync.Map` for read-heavy workloads). → See `samber/cc-skills-golang@golang-concurrency` skill.
+
+### Many goroutines blocked on same channel/mutex
+
+Serialization bottleneck. All work funnels through a single point. The throughput ceiling is the speed of that single point. Consider worker pools with multiple independent queues, sharding the work, or buffered channels to smooth bursts.
+
+### `runtime.mallocgc` dominates CPU profile
+
+Allocation rate is the bottleneck, not computation. The Go runtime is spending more time allocating and collecting garbage than running your code. Switch to the `alloc_objects` heap profile to find which functions allocate the most, then → See `samber/cc-skills-golang@golang-performance` skill for reduction patterns.
+
+### `runtime.memmove` high in CPU profile
+
+Large memory copies — usually from slice `append` growing beyond capacity, `copy()` of large slices, or string-to-byte conversions. Pre-allocate slices to final capacity, reuse buffers, or work with `[]byte` directly.
+
+### `runtime.scanobject` high in CPU profile
+
+GC pointer scanning. The heap contains many pointers that the GC must trace. Reduce pointer density: use value types instead of pointers in slices/maps, flatten nested structures, consider `[N]byte` arrays instead of `string` in hot structs.
+
+## Which Profile for Which Symptom?
+
+| Symptom | Profile | Flag/Command |
+| --- | --- | --- |
+| High CPU, slow function | CPU | `-cpuprofile` or `pprof/profile` |
+| Too many allocations (GC pressure) | Heap (alloc_objects) | `-memprofile` then `pprof -alloc_objects` |
+| Large allocations (memory usage) | Heap (alloc_space) | `pprof -alloc_space` |
+| Memory growing over time (leak) | Heap (inuse_space) | `pprof -inuse_space`, compare with `-base` |
+| Lock contention | Mutex | `pprof/mutex` (enable `SetMutexProfileFraction` first) |
+| Goroutines blocked on sync | Block | `pprof/block` (enable `SetBlockProfileRate` first) |
+| Too many goroutines / leak | Goroutine | `pprof/goroutine` |
+| High latency but low CPU | Goroutine + Block + Trace | Scheduling delays, I/O waits — see [Trace Reference](./trace.md) |
+| Excessive thread creation | Threadcreate | `pprof/threadcreate` |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/prometheus-go-metrics.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/prometheus-go-metrics.md
new file mode 100644
index 00000000..16bb6913
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/prometheus-go-metrics.md
@@ -0,0 +1,304 @@
+# Prometheus Go Runtime Metrics Reference
+
+Complete listing of Go runtime metrics **actually exposed as Prometheus metrics** by `prometheus/client_golang` library.
+
+---
+
+## Important Clarification
+
+**`runtime/metrics` are NOT Prometheus metrics.** They're Go runtime data structures.
+
+The Prometheus Go client library (`prometheus/client_golang`) **selectively converts some** `runtime/metrics` into Prometheus format. By default, it exposes only the traditional `go_memstats_*` and `go_gc_*` metrics to keep cardinality low.
+
+**This document lists only Prometheus metrics** (the ones you actually scrape from `/metrics` endpoint).
+
+---
+
+## Quick Reference
+
+### Metrics with Labels
+
+| Metric                   | Label      | Values                |
+| ------------------------ | ---------- | --------------------- |
+| `go_gc_duration_seconds` | `quantile` | 0, 0.25, 0.5, 0.75, 1 |
+| `go_info`                | `version`  | e.g., "go1.21.3"      |
+
+### All Other Metrics
+
+All other metrics have **no labels**.
+
+---
+
+## Default Go Metrics (Always Exposed)
+
+These are exposed by default by `prometheus/client_golang`.
+
+### Memory Allocation
+
+| Metric                          | Type    | Description                     |
+| ------------------------------- | ------- | ------------------------------- |
+| `go_memstats_alloc_bytes`       | gauge   | Current bytes allocated on heap |
+| `go_memstats_alloc_bytes_total` | counter | Cumulative bytes allocated      |
+| `go_memstats_sys_bytes`         | gauge   | Total bytes requested from OS   |
+
+### Heap State
+
+| Metric                            | Type  | Description                 |
+| --------------------------------- | ----- | --------------------------- |
+| `go_memstats_heap_alloc_bytes`    | gauge | Allocated heap bytes        |
+| `go_memstats_heap_idle_bytes`     | gauge | Idle heap bytes             |
+| `go_memstats_heap_inuse_bytes`    | gauge | Heap bytes in use           |
+| `go_memstats_heap_objects`        | gauge | Count of heap objects       |
+| `go_memstats_heap_released_bytes` | gauge | Heap bytes released to OS   |
+| `go_memstats_heap_sys_bytes`      | gauge | Heap bytes reserved from OS |
+
+### Stack and Metadata
+
+| Metric | Type | Description |
+| --- | --- | --- |
+| `go_memstats_stack_inuse_bytes` | gauge | Stack in-use bytes |
+| `go_memstats_stack_sys_bytes` | gauge | Stack reserved bytes |
+| `go_memstats_mspan_inuse_bytes` | gauge | Mspan in-use bytes |
+| `go_memstats_mspan_sys_bytes` | gauge | Mspan reserved bytes |
+| `go_memstats_mcache_inuse_bytes` | gauge | Mcache in-use bytes |
+| `go_memstats_mcache_sys_bytes` | gauge | Mcache reserved bytes |
+| `go_memstats_other_sys_bytes` | gauge | Other runtime bytes |
+| `go_memstats_gc_sys_bytes` | gauge | GC internal bytes |
+| `go_memstats_buck_hash_sys_bytes` | gauge | Profiling bucket hash table bytes |
+
+### Allocation and Free Counters
+
+| Metric                      | Type    | Description        |
+| --------------------------- | ------- | ------------------ |
+| `go_memstats_mallocs_total` | counter | Total malloc calls |
+| `go_memstats_frees_total`   | counter | Total free calls   |
+
+### GC Configuration and Timing
+
+| Metric | Type | Description |
+| --- | --- | --- |
+| `go_gc_gogc_percent` | gauge | GOGC target percentage |
+| `go_gc_gomemlimit_bytes` | gauge | GOMEMLIMIT soft memory limit |
+| `go_memstats_last_gc_time_seconds` | gauge | Last GC end time (Unix timestamp) |
+| `go_memstats_next_gc_bytes` | gauge | Heap size target for next GC |
+
+### GC Pause Duration (with labels)
+
+| Metric | Type | Labels | Description |
+| --- | --- | --- | --- |
+| `go_gc_duration_seconds` | summary | `quantile` (0, 0.25, 0.5, 0.75, 1) | GC pause durations with quantiles |
+| `go_gc_duration_seconds_count` | counter | — | GC pause count |
+| `go_gc_duration_seconds_sum` | counter | — | GC pause total time |
+
+### Runtime State
+
+| Metric                        | Type  | Description              |
+| ----------------------------- | ----- | ------------------------ |
+| `go_goroutines`               | gauge | Current goroutine count  |
+| `go_threads`                  | gauge | Current OS thread count  |
+| `go_sched_gomaxprocs_threads` | gauge | Current GOMAXPROCS value |
+
+### Version Information (with labels)
+
+| Metric    | Type  | Labels    | Description       |
+| --------- | ----- | --------- | ----------------- |
+| `go_info` | gauge | `version` | Go version string |
+
+---
+
+## Optional Go Metrics (Opt-in, Go 1.17+)
+
+Enable via:
+
+```go
+prometheus.NewRegistry().MustRegister(
+    collectors.NewGoCollector(
+        collectors.WithGoCollectorRuntimeMetrics(
+            collectors.MetricsAll,
+        ),
+    ),
+)
+```
+
+### GC Cycles
+
+| Metric | Type | Description |
+| --- | --- | --- |
+| `go_gc_cycles_automatic_gc_cycles_total` | counter | Automatic GC cycles (heap growth) |
+| `go_gc_cycles_forced_gc_cycles_total` | counter | Forced GC cycles (runtime.GC()) |
+
+### Additional Heap Metrics
+
+| Metric | Type | Description |
+| --- | --- | --- |
+| `go_gc_heap_allocs_bytes_total` | counter | Cumulative heap allocations (bytes) |
+| `go_gc_heap_allocs_objects_total` | counter | Cumulative heap allocations (count) |
+| `go_gc_heap_frees_bytes_total` | counter | Cumulative heap frees (bytes) |
+| `go_gc_heap_frees_objects_total` | counter | Cumulative heap frees (count) |
+| `go_gc_heap_goal_bytes` | gauge | Heap size target for next GC |
+| `go_gc_heap_live_bytes` | gauge | Live heap bytes |
+| `go_gc_heap_objects_objects` | gauge | Total heap objects count |
+
+### GC Pauses Distribution
+
+| Metric                 | Type         | Description        |
+| ---------------------- | ------------ | ------------------ |
+| `go_gc_pauses_seconds` | distribution | GC pause durations |
+
+### CPU Classes
+
+| Metric | Type | Description |
+| --- | --- | --- |
+| `go_cpu_classes_gc_mark_assist_cpu_seconds_total` | counter | GC mark assist CPU time |
+| `go_cpu_classes_gc_mark_dedicated_cpu_seconds_total` | counter | GC dedicated workers CPU time |
+| `go_cpu_classes_gc_mark_idle_cpu_seconds_total` | counter | GC idle workers CPU time |
+| `go_cpu_classes_gc_pause_cpu_seconds_total` | counter | GC pause CPU time |
+| `go_cpu_classes_gc_total_cpu_seconds_total` | counter | Total GC CPU time |
+| `go_cpu_classes_idle_cpu_seconds_total` | counter | Idle CPU time |
+| `go_cpu_classes_scavenge_assist_cpu_seconds_total` | counter | Scavenger assist CPU time |
+| `go_cpu_classes_scavenge_background_cpu_seconds_total` | counter | Background scavenger CPU time |
+| `go_cpu_classes_scavenge_total_cpu_seconds_total` | counter | Total scavenger CPU time |
+| `go_cpu_classes_total_cpu_seconds_total` | counter | Total CPU time (all classes) |
+| `go_cpu_classes_user_cpu_seconds_total` | counter | User-mode CPU time |
+
+### Memory Classes
+
+| Metric | Type | Description |
+| --- | --- | --- |
+| `go_memory_classes_heap_free_bytes` | gauge | Free heap memory |
+| `go_memory_classes_heap_objects_bytes` | gauge | Allocated heap objects |
+| `go_memory_classes_heap_released_bytes` | gauge | Heap released memory |
+| `go_memory_classes_heap_stacks_bytes` | gauge | Stack memory |
+| `go_memory_classes_heap_unused_bytes` | gauge | Unused heap |
+| `go_memory_classes_metadata_mcache_free_bytes` | gauge | Free mcache memory |
+| `go_memory_classes_metadata_mcache_inuse_bytes` | gauge | In-use mcache memory |
+| `go_memory_classes_metadata_mspan_free_bytes` | gauge | Free mspan memory |
+| `go_memory_classes_metadata_mspan_inuse_bytes` | gauge | In-use mspan memory |
+| `go_memory_classes_other_bytes` | gauge | Other memory |
+| `go_memory_classes_total_bytes` | gauge | Total memory |
+
+### Scheduler Metrics
+
+| Metric | Type | Description |
+| --- | --- | --- |
+| `go_sched_goroutines_running_goroutines` | gauge | Running goroutines |
+| `go_sched_goroutines_runnable_goroutines` | gauge | Runnable goroutines waiting |
+| `go_sched_goroutines_goroutines` | gauge | Current total goroutines |
+| `go_sched_goroutines_created_goroutines_total` | counter | Total goroutines ever created |
+| `go_sched_goroutines_waiting_goroutines` | gauge | Goroutines waiting (not runnable) |
+| `go_sched_latencies_seconds` | distribution | Goroutine scheduling latency |
+| `go_sched_pauses_stopping_gc_seconds` | distribution | STW pause time (GC stop) |
+| `go_sched_pauses_stopping_other_seconds` | distribution | STW pause time (other stop) |
+| `go_sched_pauses_total_gc_seconds` | distribution | Total GC pause duration |
+| `go_sched_pauses_total_other_seconds` | distribution | Total other pause duration |
+| `go_sched_threads_total_threads` | counter | Total OS threads ever created |
+| `go_sync_mutex_wait_total_seconds_total` | counter | Total time goroutines waited on mutex |
+
+### CGO Metrics
+
+| Metric                       | Type    | Description              |
+| ---------------------------- | ------- | ------------------------ |
+| `go_cgo_go_to_c_calls_total` | counter | Total calls from Go to C |
+
+---
+
+## Process Metrics
+
+Exposed by Prometheus `process` collector (not Go-specific):
+
+### CPU and Memory
+
+| Metric | Type | Description |
+| --- | --- | --- |
+| `process_cpu_seconds_total` | counter | Total CPU time (user + system) |
+| `process_resident_memory_bytes` | gauge | RSS (physical memory used) |
+| `process_virtual_memory_bytes` | gauge | Virtual memory allocated |
+| `process_virtual_memory_max_bytes` | gauge | Maximum virtual memory allowed |
+
+### File Descriptors
+
+| Metric             | Type  | Description                      |
+| ------------------ | ----- | -------------------------------- |
+| `process_open_fds` | gauge | Open file descriptors            |
+| `process_max_fds`  | gauge | Maximum file descriptors allowed |
+
+### Process Information
+
+| Metric                       | Type  | Description                         |
+| ---------------------------- | ----- | ----------------------------------- |
+| `process_start_time_seconds` | gauge | Process start time (Unix timestamp) |
+
+### Page Faults
+
+| Metric                            | Type    | Description       |
+| --------------------------------- | ------- | ----------------- |
+| `process_page_faults_total`       | counter | Total page faults |
+| `process_page_faults_minor_total` | counter | Minor page faults |
+| `process_page_faults_major_total` | counter | Major page faults |
+
+---
+
+## Common PromQL Queries
+
+### Memory Leak Detection
+
+```promql
+# Current heap allocation (should be stable under constant load)
+go_memstats_alloc_bytes
+
+# Live heap bytes (optional metric)
+go_gc_heap_live_bytes
+
+# Heap growth rate
+rate(go_memstats_alloc_bytes_total[5m])
+```
+
+### GC Pressure
+
+```promql
+# Worst-case GC pause (quantile 1 = max)
+go_gc_duration_seconds{quantile="1"}
+
+# Average GC pause
+rate(go_gc_duration_seconds_sum[5m]) / rate(go_gc_duration_seconds_count[5m])
+
+# GC frequency (cycles per second)
+rate(go_gc_duration_seconds_count[5m])
+```
+
+### Goroutine Leaks
+
+```promql
+# Current goroutine count
+go_goroutines
+
+# Goroutine growth (leak indicator)
+delta(go_goroutines[1h])
+```
+
+### CPU Usage
+
+```promql
+# Total CPU time consumed
+rate(process_cpu_seconds_total[5m])
+
+# CPU utilization ratio (0-1)
+rate(process_cpu_seconds_total[5m]) / <GOMAXPROCS>
+```
+
+### File Descriptor Leaks
+
+```promql
+# FD growth
+delta(process_open_fds[1h])
+
+# FD saturation ratio
+process_open_fds / process_max_fds
+```
+
+→ See `samber/cc-skills@promql-cli` skill for executing these queries directly against your Prometheus instance from the CLI.
+
+## References
+
+- [prometheus/client_golang collectors](https://github.com/prometheus/client_golang/tree/main/prometheus/collectors)
+- [Go runtime/metrics package](https://pkg.go.dev/runtime/metrics)
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/tools.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/tools.md
new file mode 100644
index 00000000..e24f900d
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/tools.md
@@ -0,0 +1,50 @@
+# Diagnostic Tools Quick Reference
+
+Use these tools to validate the root cause of a slowdown BEFORE applying any optimization. Do NOT use auto-fix flags (e.g. `--fix`) — let the coding agent interpret results and apply changes manually with explanatory comments.
+
+For detailed usage of each tool, see the dedicated reference files:
+
+- [pprof Reference](./pprof.md) — profiling (CPU, heap, goroutine, mutex, block)
+- [benchstat Reference](./benchstat.md) — statistical benchmark comparison
+- [Trace Reference](./trace.md) — execution tracer
+- [Compiler Analysis](./compiler-analysis.md) — escape analysis, inlining, SSA, assembly
+
+## GC and Runtime Diagnostics
+
+Configure via environment variables — no recompile needed.
+
+| Command | Use for |
+| --- | --- |
+| `GODEBUG=gctrace=1 ./app` | GC frequency, pause times, heap sizes, CPU% — one line per GC cycle |
+| `GODEBUG=gcpacertrace=1 ./app` | Why GC triggers when it does — pacer decisions (trigger ratio, heap goal) |
+| `GODEBUG=schedtrace=1000 ./app` | Load balancing, goroutine distribution across Ps — prints every 1000ms |
+| `GODEBUG=schedtrace=1000,scheddetail=1 ./app` | Per-goroutine state detail on top of schedtrace |
+| Heap/alloc profiles (`go tool pprof -alloc_objects`) | Allocation sites and object churn; use instead of removed/stale allocation trace flags |
+
+→ See `samber/cc-skills-golang@golang-troubleshooting` skill for detailed GODEBUG usage and interpretation.
+
+### Programmatic APIs
+
+- **`runtime.ReadMemStats`** — heap size, NumGC, pause durations (PauseNs circular buffer), TotalAlloc (cumulative). Use for dashboards, alerting on heap growth.
+- **`debug.ReadGCStats`** — GC-specific statistics: pause percentiles, pause timeline, total pause duration. More focused than ReadMemStats.
+- **`runtime/metrics` (Go 1.16+)** — stable API, safe for concurrent reads, lower overhead than ReadMemStats. Keys: `/gc/cycles/total:gc-cycles`, `/gc/heap/allocs:bytes`, `/gc/pauses:seconds`, `/sched/latencies:seconds`, `/memory/classes/heap/released:bytes`.
+- **`debug.FreeOSMemory()`** — forces GC + returns memory to OS. One-off use after large temporary allocations (not for regular use — let the runtime manage this).
+- **`expvar`** — stdlib metrics at `/debug/vars` as JSON. `import _ "expvar"` auto-registers. Lightweight, no dependencies. Integrates with Netdata, Telegraf, or custom dashboards.
+
+## Static Analysis
+
+| Command | Use for |
+| --- | --- |
+| `fieldalignment ./...` | Detect suboptimal struct field ordering (padding waste). Do NOT use `-fix` flag — let the coding agent apply changes manually with explanatory comments. |
+| `unsafe.Sizeof` / `Alignof` / `Offsetof` | Inspect struct memory layout at compile time — compare before/after reordering to quantify savings. |
+| `go vet ./...` | Suspicious constructs: printf format mismatches, unreachable code, unused results, suspicious shifts. |
+| `staticcheck ./...` | Advanced linter: performance pitfalls (SA9003: empty branch, SA4006: unused value, SA1019: deprecated API). |
+| `go test -race ./...` | Data race detection at runtime — also useful for confirming false sharing. |
+
+## Third-Party Profiling
+
+| Tool | What it adds | When to use |
+| --- | --- | --- |
+| **fgprof** (`github.com/felixge/fgprof`) | Full goroutine profiler — captures both on-CPU and off-CPU (I/O wait) time in a single profile. Standard pprof CPU profiles only show on-CPU time. | pprof CPU profile shows low CPU% but latency is high. |
+| **Pyroscope / Parca** | Continuous profiling platforms — aggregate pprof profiles over time, compare across deployments, detect regressions. | Production performance monitoring, historical trend analysis. → See `samber/cc-skills-golang@golang-observability` skill for setup. |
+| **Linux perf** (`perf record -g ./app && perf report`) | Hardware performance counters: cache misses, branch mispredictions, TLB misses. Requires `perf_data_converter` for pprof format. | CPU microarchitecture-level analysis when pprof isn't granular enough. |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/trace.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/trace.md
new file mode 100644
index 00000000..3bd3c61f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-benchmark/references/trace.md
@@ -0,0 +1,448 @@
+# Execution Trace Reference
+
+`go tool trace` shows what pprof cannot: **scheduling delays**, GC stop-the-world phases, goroutine state transitions, and why goroutines are **not** running. pprof samples what's on-CPU; trace records every state transition at nanosecond precision.
+
+Use the execution tracer when:
+
+- pprof shows low CPU% but latency is high (goroutines waiting, not working)
+- You suspect GC pauses are causing tail latency spikes
+- You need to understand goroutine scheduling and contention
+- You want to see the wall-clock timeline of concurrent operations
+
+## Generating Traces
+
+### From benchmarks
+
+```bash
+go test -bench=BenchmarkParse -trace=trace.out ./pkg/parser
+go tool trace trace.out
+```
+
+### From running service
+
+Requires `import _ "net/http/pprof"`:
+
+```bash
+# Capture 5 seconds of trace data (adjust duration as needed)
+curl -o trace.out http://localhost:6060/debug/pprof/trace?seconds=5
+go tool trace trace.out
+```
+
+**Warning:** traces generate data at MB/s. Keep captures short — 5-10 seconds is typical. Longer traces are unwieldy, slow to parse, and may consume significant memory when opened.
+
+### From tests
+
+```bash
+go test -trace=trace.out ./pkg/parser
+go tool trace trace.out
+```
+
+### From code (programmatic)
+
+```go
+import "runtime/trace"
+
+f, _ := os.Create("trace.out")
+trace.Start(f)
+defer trace.Stop()
+```
+
+Or capture a region of interest:
+
+```go
+import "runtime/trace"
+
+// Start tracing only when needed
+f, _ := os.Create("trace.out")
+trace.Start(f)
+
+doExpensiveWork()
+
+trace.Stop()
+f.Close()
+```
+
+## Full Command Reference
+
+### Opening traces
+
+```bash
+# Open trace in web browser (default — starts HTTP server, opens browser)
+go tool trace trace.out
+
+# Open on a specific port
+go tool trace -http=:8080 trace.out
+
+# Open on a specific host:port (e.g., for remote access)
+go tool trace -http=0.0.0.0:8080 trace.out
+```
+
+### Extracting pprof profiles from traces
+
+`go tool trace` can convert trace data into pprof-compatible profiles. This bridges the two tools — you capture with the tracer (nanosecond events) and analyze with pprof (statistical aggregation with `top`, `list`, `peek`):
+
+```bash
+# Network blocking profile — where goroutines wait on network I/O
+go tool trace -pprof=net trace.out > net.prof
+go tool pprof -top net.prof
+
+# Synchronization blocking profile — mutexes, channels, wait groups
+go tool trace -pprof=sync trace.out > sync.prof
+go tool pprof -top sync.prof
+
+# Syscall blocking profile — system calls that block goroutines
+go tool trace -pprof=syscall trace.out > syscall.prof
+go tool pprof -top syscall.prof
+
+# Scheduler latency profile — time between becoming runnable and actually running
+go tool trace -pprof=sched trace.out > sched.prof
+go tool pprof -top sched.prof
+```
+
+You can chain with any pprof command — e.g., annotated source for a blocking function:
+
+```bash
+go tool trace -pprof=sync trace.out > sync.prof
+go tool pprof -list=handleRequest sync.prof
+go tool pprof -svg sync.prof > sync-blocking.svg
+```
+
+### Full capture-to-analysis workflows
+
+```bash
+# Workflow 1: benchmark trace — capture, view, extract blocking profile
+go test -bench=BenchmarkParse -trace=trace.out ./pkg/parser
+go tool trace trace.out                                         # visual timeline
+go tool trace -pprof=sync trace.out > sync.prof                 # extract sync blocking
+go tool pprof -top -cum sync.prof                               # find worst sync blockers
+go tool pprof -list=processOrder sync.prof                      # annotated source
+
+# Workflow 2: production trace — capture from running service, analyze scheduling
+curl -o trace.out http://localhost:6060/debug/pprof/trace?seconds=5
+go tool trace trace.out                                         # visual timeline
+go tool trace -pprof=sched trace.out > sched.prof               # extract scheduling latency
+go tool pprof -top sched.prof                                   # goroutines with worst scheduling delay
+go tool pprof -svg sched.prof > sched.svg                       # graph of scheduling bottlenecks
+
+# Workflow 3: test trace — capture during test run
+go test -trace=trace.out -run=TestSlowIntegration ./pkg/api
+go tool trace trace.out                                         # visual timeline
+go tool trace -pprof=net trace.out > net.prof                   # extract network blocking
+go tool pprof -top net.prof                                     # find network wait sites
+```
+
+### `go tool trace` flags summary
+
+| Flag | Example | Purpose |
+| --- | --- | --- |
+| (none) | `go tool trace trace.out` | Open trace in web browser (default) |
+| `-http=:PORT` | `go tool trace -http=:9090 trace.out` | Set HTTP server address for the web UI |
+| `-pprof=TYPE` | `go tool trace -pprof=net trace.out > net.prof` | Extract pprof profile from trace. Types: `net`, `sync`, `syscall`, `sched` |
+
+### HTTP endpoints served by the web UI
+
+When `go tool trace trace.out` starts its HTTP server, it exposes these pages:
+
+| Endpoint | What it shows |
+| --- | --- |
+| `/` | Index page with links to all views |
+| `/trace` | Interactive timeline viewer (Chrome trace viewer) — the main visualization |
+| `/goroutines` | Goroutine analysis — summary table of all goroutine types, counts, and execution stats |
+| `/goroutine/<id>` | Detailed view of a specific goroutine — its full lifecycle timeline |
+
+From `/goroutines`, click on a goroutine type to see all instances and their execution statistics (total time, scheduled time, blocked time). Click an individual goroutine to see its timeline.
+
+## Web UI
+
+### Main views
+
+The web UI (opened by `go tool trace trace.out`) shows a timeline where each horizontal lane represents a processor (P), goroutine, or system event:
+
+- **Trace viewer** (`/trace`) — interactive timeline with:
+  - **P lanes** — one per logical processor (GOMAXPROCS), showing which goroutine runs on each P at each moment
+  - **Goroutine lanes** — each goroutine's lifecycle: created → runnable → running → waiting → running → …
+  - **GC events** — mark phases, sweep, STW pauses shown as colored bands across all P lanes
+  - **System events** — syscalls, network I/O, timer events
+  - **User annotations** — tasks, regions, and log messages from `runtime/trace` API
+
+- **Goroutine analysis** (`/goroutines`) — summary table:
+  - Groups goroutines by creation stack trace (type)
+  - Shows count, total execution time, total scheduling wait, total blocking time
+  - Click a type to see individual goroutine statistics
+  - Click an individual goroutine to see its timeline
+
+### Navigating the trace viewer
+
+The trace viewer uses the Chrome tracing UI (also used by Chrome DevTools):
+
+| Key/Action | Effect |
+| --- | --- |
+| `W` / scroll up | Zoom in (time axis) |
+| `S` / scroll down | Zoom out (time axis) |
+| `A` | Pan left |
+| `D` | Pan right |
+| Click on event | Show details panel at bottom — goroutine ID, duration, stack trace |
+| `Shift+click` | Select a time range — highlights all events in that window |
+| `M` | Mark current selection |
+| `/` | Search for events by name |
+| `?` | Show keyboard shortcuts |
+
+### Reading the timeline
+
+**Color coding:**
+
+- **Green bars** on P lanes = goroutine actively executing
+- **Blue bars** = syscall (goroutine pinned to OS thread)
+- **Orange/yellow marks** = scheduling events (goroutine becoming runnable)
+- **Red bands** across all P lanes = GC stop-the-world pause
+- **Light blue bands** = GC concurrent mark phase
+- **Purple** = user-defined regions (from `trace.WithRegion`)
+
+**Gaps in P lanes** = the processor was idle (no runnable goroutines, or goroutines blocked). Many idle gaps with pending runnable goroutines suggests scheduling contention.
+
+## What to Look For
+
+### Goroutine states
+
+The trace timeline color-codes goroutine states:
+
+| Color | State | Meaning | What it indicates |
+| --- | --- | --- | --- |
+| **Green** | Running | Actively executing on a P | Normal — doing useful work |
+| **Yellow/Orange** | Runnable | Ready to run but waiting for a P | CPU-saturated — too many runnable goroutines competing for too few processors |
+| **Red/Pink** | Waiting | Blocked on I/O, channel, mutex, sleep, select | I/O-bound or contention — investigate what it's waiting on |
+| **Blue** | GC assist | Drafted by GC to help mark/sweep | GC pressure — too many allocations forcing goroutines to help the collector |
+
+### GC phases
+
+GC events appear as colored bands across all P lanes:
+
+- **Mark assist** — goroutines drafted to help GC scan the heap. Visible as gaps in application goroutine execution. The runtime forces goroutines to assist with GC work in proportion to their allocation rate — heavy allocators get taxed more.
+- **STW (stop-the-world)** — brief phases where all goroutines are stopped (mark setup, mark termination). These cause latency spikes visible as vertical bands across all lanes.
+- **Sweep** — concurrent sweep of unreachable objects. Usually low overhead but can accumulate if the heap is large.
+
+**Diagnosing GC issues from traces:**
+
+- Frequent GC cycles with long mark assist = too many allocations (reduce allocation rate)
+- Long STW phases = too many pointers for the GC to scan (reduce pointer density)
+- GC cycles clustering after specific operations = those operations allocate heavily
+
+### Scheduling latency
+
+Time between a goroutine becoming **runnable** and actually **running**. High scheduling latency means:
+
+- Too many goroutines competing for GOMAXPROCS processors
+- OS scheduling interference (noisy neighbors, CPU throttling)
+- Goroutines pinned to busy threads by cgo or long syscalls
+
+**What to look for:**
+
+- Yellow (runnable) gaps before green (running) segments — the longer the yellow gap, the higher the scheduling latency
+- Many goroutines in runnable state simultaneously — indicates CPU saturation
+- Uneven distribution across Ps — one P overloaded while others are idle suggests work imbalance
+
+### Network/sync blocking
+
+- **Long red/pink periods** on a goroutine = it's blocked waiting. Click the block event to see what it's waiting on (channel receive, mutex lock, network read, etc.)
+- **Many goroutines blocked on the same channel or mutex** = serialization bottleneck. All work funnels through one point.
+- **Goroutines blocked on network I/O** = external dependency latency. The Go code can't do anything faster — the bottleneck is upstream. Use `-pprof=net` to generate a pprof profile of network wait locations.
+
+### Goroutine creation and destruction
+
+The trace shows goroutine lifecycle events. Look for:
+
+- **Goroutines created in a loop without bound** = potential goroutine leak
+- **Goroutines that are created but never finish** = leak — they accumulate over time
+- **Very short-lived goroutines created repeatedly** = high overhead from goroutine creation/scheduling (consider batching or worker pools)
+
+## Custom Annotations
+
+Add application-level context to traces so you can correlate runtime events with business operations.
+
+### Tasks
+
+A task represents a logical operation that may span multiple goroutines:
+
+```go
+import "runtime/trace"
+
+func processOrder(ctx context.Context, order Order) error {
+    ctx, task := trace.NewTask(ctx, "processOrder")
+    defer task.End()
+
+    // All trace events in this context are grouped under the task
+    validate(ctx, order)
+    charge(ctx, order)
+    fulfill(ctx, order)
+    return nil
+}
+```
+
+Tasks appear as named groups in the trace timeline. You can filter the trace view to show only events belonging to a specific task.
+
+### Regions
+
+A region represents a phase within a task or goroutine:
+
+```go
+func validate(ctx context.Context, order Order) {
+    trace.WithRegion(ctx, "validateAddress", func() {
+        // this block is annotated as a region
+        validateAddress(order.Address)
+    })
+
+    trace.WithRegion(ctx, "validatePayment", func() {
+        validatePayment(order.Payment)
+    })
+}
+```
+
+Regions appear as labeled spans on the goroutine's timeline, making it easy to see which phase of processing takes the most wall-clock time.
+
+### Log messages
+
+Add point-in-time log messages to the trace:
+
+```go
+trace.Log(ctx, "orderID", order.ID)
+trace.Log(ctx, "status", "payment_verified")
+```
+
+Logs appear as markers on the timeline — useful for correlating trace events with specific data.
+
+### When to use annotations
+
+- **Always** in server request handlers — wrap each request in a task
+- **Performance-critical paths** — add regions to phases you want to measure wall-clock time for
+- **Debugging intermittent latency** — add logs at key decision points to see what happened in the slow trace
+
+Annotations add negligible overhead when tracing is disabled (they check a flag and return immediately).
+
+## Flight Recorder (Go 1.25+)
+
+The flight recorder solves a fundamental problem with execution traces in long-running services: when a problem occurs (timeout, failed health check), it's already too late to call `trace.Start()`. The flight recorder keeps a circular buffer of recent trace data in memory, and you snapshot it to disk when something goes wrong — like an airplane's black box.
+
+### Setup
+
+```go
+import "runtime/trace"
+
+fr := trace.NewFlightRecorder(trace.FlightRecorderConfig{
+    MinAge:   10 * time.Second, // keep at least 10s of data
+    MaxBytes: 5 << 20,          // cap at 5 MiB to limit memory usage
+})
+if err := fr.Start(); err != nil {
+    return err
+}
+```
+
+**Sizing guidance:**
+
+- **MinAge** — set to ~2x your problem window. For 5-second timeout debugging, use 10 seconds. The runtime may retain more data than MinAge if MaxBytes allows.
+- **MaxBytes** — busy services generate ~1-10 MB/s of trace data. Start with 1-5 MiB and adjust. MaxBytes takes precedence over MinAge — when the buffer fills, older data is discarded regardless of age.
+
+### Snapshot on error
+
+Capture the trace buffer when something unexpected happens. Use `sync.Once` to prevent multiple snapshots overwriting each other:
+
+```go
+var snapshotOnce sync.Once
+
+func captureSnapshot(fr *trace.FlightRecorder) {
+    snapshotOnce.Do(func() {
+        f, err := os.Create("snapshot.trace")
+        if err != nil {
+            log.Printf("snapshot file: %v", err)
+            return
+        }
+        defer f.Close()
+
+        if _, err := fr.WriteTo(f); err != nil {
+            log.Printf("snapshot write: %v", err)
+            return
+        }
+        fr.Stop()
+        log.Printf("captured snapshot to %s", f.Name())
+    })
+}
+```
+
+### Trigger patterns
+
+```go
+// Pattern 1: slow request detection
+http.HandleFunc("/api/order", func(w http.ResponseWriter, r *http.Request) {
+    start := time.Now()
+    // ... handler logic ...
+
+    if fr.Enabled() && time.Since(start) > 100*time.Millisecond {
+        go captureSnapshot(fr)
+    }
+})
+
+// Pattern 2: health check failure
+if !healthCheck() && fr.Enabled() {
+    go captureSnapshot(fr)
+}
+
+// Pattern 3: HTTP endpoint for on-demand capture
+http.HandleFunc("/debug/flightrecorder", func(w http.ResponseWriter, r *http.Request) {
+    if !fr.Enabled() {
+        http.Error(w, "flight recorder not active", http.StatusServiceUnavailable)
+        return
+    }
+    w.Header().Set("Content-Type", "application/octet-stream")
+    w.Header().Set("Content-Disposition", "attachment; filename=trace.out")
+    fr.WriteTo(w)
+})
+```
+
+### Analyzing a snapshot
+
+```bash
+go tool trace snapshot.trace
+```
+
+The snapshot contains the same data as a regular trace — use all the same analysis techniques (timeline viewer, goroutine analysis, pprof extraction). The flight recorder's flow events are particularly useful for diagnosing lock contention and goroutine stalls that caused the anomaly.
+
+### Constraints
+
+- **At most one flight recorder** may be active at a time (this restriction may be relaxed in future Go versions)
+- A flight recorder **can run concurrently** with `trace.Start` — both can be active simultaneously
+- Only one goroutine may call `WriteTo` at a time — the `sync.Once` pattern handles this naturally
+- `Stop()` blocks until any concurrent `WriteTo` completes
+
+### When to use flight recorder vs regular tracing
+
+| Scenario | Tool | Why |
+| --- | --- | --- |
+| Investigating a known slow operation | `go test -trace` or `trace.Start`/`Stop` | You know when to start and stop |
+| Intermittent latency spikes in production | Flight recorder | You don't know when the spike will happen — the buffer captures it retroactively |
+| Post-mortem after a timeout or crash | Flight recorder | The problem already happened; regular tracing would miss it |
+| Continuous performance monitoring | `samber/cc-skills-golang@golang-observability` (Pyroscope) | Flight recorder is for one-shot diagnosis, not continuous collection |
+
+## Overhead and Practical Limits
+
+| Concern | Guidance |
+| --- | --- |
+| **Runtime overhead** | ~1-2% CPU during capture; negligible when not capturing |
+| **Data volume** | Traces generate MB/s of data. A 10-second trace of a busy service can be 50-100MB |
+| **Capture duration** | 5-10 seconds is typical. Longer traces are slow to open and hard to navigate |
+| **Memory to view** | `go tool trace` loads the entire trace into memory. Large traces may need 1GB+ RAM |
+| **Browser performance** | The web UI can struggle with traces >100MB. Use short captures. |
+| **Production use** | Safe for short captures on a single instance. Do not capture continuously. |
+
+## Trace vs pprof: When to Use Which
+
+| Question | Tool | Why |
+| --- | --- | --- |
+| Where does CPU time go? | pprof CPU profile | Statistical sampling, low overhead, good for aggregate view |
+| Why is latency high but CPU low? | go tool trace | Shows goroutine waiting states — I/O, channels, mutexes |
+| Where do allocations happen? | pprof heap profile | Per-function allocation counts and sizes |
+| Why are GC pauses long? | go tool trace | Shows STW phases, mark assist, GC timeline |
+| Is there lock contention? | pprof mutex/block + trace | pprof quantifies it; trace shows the timeline |
+| Are goroutines leaking? | pprof goroutine + trace | pprof shows the stack; trace shows creation/lifecycle |
+| Which goroutines compete for CPU? | go tool trace | Shows runnable vs running states across all Ps |
+| What's the wall-clock breakdown of a request? | go tool trace (with annotations) | Timeline view with tasks and regions |
+
+When in doubt, start with pprof (lower overhead, simpler output). Use trace when pprof doesn't explain the latency or when you need the wall-clock timeline view.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/SKILL.md
new file mode 100644
index 00000000..d861c044
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/SKILL.md
@@ -0,0 +1,205 @@
+---
+name: golang-cli
+description: "Golang CLI application development. Use when building, modifying, or reviewing a Go CLI tool — especially for command structure, flag handling, configuration layering, version embedding, exit codes, I/O patterns, signal handling, shell completion, argument validation, and CLI unit testing. Also triggers when code uses cobra, viper, or urfave/cli. For cobra-specific APIs → See `samber/cc-skills-golang@golang-spf13-cobra` skill; for viper configuration layering → See `samber/cc-skills-golang@golang-spf13-viper` skill."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.0"
+  openclaw:
+    emoji: "💻"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion
+---
+
+**Persona:** You are a Go CLI engineer. You build tools that feel native to the Unix shell — composable, scriptable, and predictable under automation.
+
+**Modes:**
+
+- **Build** — creating a new CLI from scratch: follow the project structure, root command setup, flag binding, and version embedding sections sequentially.
+- **Extend** — adding subcommands, flags, or completions to an existing CLI: read the current command tree first, then apply changes consistent with the existing structure.
+- **Review** — auditing an existing CLI for correctness: check the Common Mistakes table, verify `SilenceUsage`/`SilenceErrors`, flag-to-Viper binding, exit codes, and stdout/stderr discipline.
+
+# Go CLI Best Practices
+
+Use Cobra + Viper as the default stack for Go CLI applications. Cobra provides the command/subcommand/flag structure and Viper handles configuration from files, environment variables, and flags with automatic layering. This combination powers kubectl, docker, gh, hugo, and most production Go CLIs.
+
+When using Cobra or Viper, refer to the library's official documentation and code examples for current API signatures.
+
+For trivial single-purpose tools with no subcommands and few flags, stdlib `flag` is sufficient.
+
+## Quick Reference
+
+| Concern             | Package / Tool                       |
+| ------------------- | ------------------------------------ |
+| Commands & flags    | `github.com/spf13/cobra`             |
+| Configuration       | `github.com/spf13/viper`             |
+| Flag parsing        | `github.com/spf13/pflag` (via Cobra) |
+| Colored output      | `github.com/fatih/color`             |
+| Table output        | `github.com/olekukonko/tablewriter`  |
+| Interactive prompts | `github.com/charmbracelet/bubbletea` |
+| Version injection   | `go build -ldflags`                  |
+| Distribution        | `goreleaser`                         |
+
+## Project Structure
+
+Organize CLI commands in `cmd/myapp/` with one file per command. Keep `main.go` minimal — it only calls `Execute()`.
+
+```
+myapp/
+├── cmd/
+│   └── myapp/
+│       ├── main.go              # package main, only calls Execute()
+│       ├── root.go              # Root command + Viper init
+│       ├── serve.go             # "serve" subcommand
+│       ├── migrate.go           # "migrate" subcommand
+│       └── version.go           # "version" subcommand
+├── go.mod
+└── go.sum
+```
+
+`main.go` should be minimal — see [assets/examples/main.go](assets/examples/main.go).
+
+## Root Command Setup
+
+The root command initializes Viper configuration and sets up global behavior via `PersistentPreRunE`. See [assets/examples/root.go](assets/examples/root.go).
+
+Key points:
+
+- `SilenceUsage: true` MUST be set — prevents printing the full usage text on every error
+- `SilenceErrors: true` MUST be set — lets you control error output format yourself
+- `PersistentPreRunE` runs before every subcommand, so config is always initialized
+- Logs go to stderr, output goes to stdout
+
+## Subcommands
+
+Add subcommands by creating separate files in `cmd/myapp/` and registering them in `init()`. See [assets/examples/serve.go](assets/examples/serve.go) for a complete subcommand example including command groups.
+
+## Flags
+
+See [assets/examples/flags.go](assets/examples/flags.go) for all flag patterns:
+
+### Persistent vs Local
+
+- **Persistent** flags are inherited by all subcommands (e.g., `--config`)
+- **Local** flags only apply to the command they're defined on (e.g., `--port`)
+
+### Required Flags
+
+Use `MarkFlagRequired`, `MarkFlagsMutuallyExclusive`, and `MarkFlagsOneRequired` for flag constraints.
+
+### Flag Validation with RegisterFlagCompletionFunc
+
+Provide completion suggestions for flag values.
+
+### Always Bind Flags to Viper
+
+This ensures `viper.GetInt("port")` returns the flag value, env var `MYAPP_PORT`, or config file value — whichever has highest precedence.
+
+## Argument Validation
+
+Cobra provides built-in validators for positional arguments. See [assets/examples/args.go](assets/examples/args.go) for both built-in and custom validation examples.
+
+| Validator                   | Description                          |
+| --------------------------- | ------------------------------------ |
+| `cobra.NoArgs`              | Fails if any args provided           |
+| `cobra.ExactArgs(n)`        | Requires exactly n args              |
+| `cobra.MinimumNArgs(n)`     | Requires at least n args             |
+| `cobra.MaximumNArgs(n)`     | Allows at most n args                |
+| `cobra.RangeArgs(min, max)` | Requires between min and max         |
+| `cobra.ExactValidArgs(n)`   | Exactly n args, must be in ValidArgs |
+
+## Configuration with Viper
+
+Viper resolves configuration values in this order (highest to lowest precedence):
+
+1. **CLI flags** (explicit user input)
+2. **Environment variables** (deployment config)
+3. **Config file** (persistent settings)
+4. **Defaults** (set in code)
+
+See [assets/examples/config.go](assets/examples/config.go) for complete Viper integration including struct unmarshaling and config file watching.
+
+### Example Config File (.myapp.yaml)
+
+```yaml
+port: 8080
+host: localhost
+log-level: info
+database:
+  dsn: postgres://localhost:5432/myapp
+  max-conn: 25
+```
+
+With the setup above, these are all equivalent:
+
+- Flag: `--port 9090`
+- Env var: `MYAPP_PORT=9090`
+- Config file: `port: 9090`
+
+## Version and Build Info
+
+Version SHOULD be embedded at compile time using `ldflags`. See [assets/examples/version.go](assets/examples/version.go) for the version command and build instructions.
+
+## Exit Codes
+
+Exit codes MUST follow Unix conventions:
+
+| Code  | Meaning           | When to Use                               |
+| ----- | ----------------- | ----------------------------------------- |
+| 0     | Success           | Operation completed normally              |
+| 1     | General error     | Runtime failure                           |
+| 2     | Usage error       | Invalid flags or arguments                |
+| 64-78 | BSD sysexits      | Specific error categories                 |
+| 126   | Cannot execute    | Permission denied                         |
+| 127   | Command not found | Missing dependency                        |
+| 128+N | Signal N          | Terminated by signal (e.g., 130 = SIGINT) |
+
+See [assets/examples/exit_codes.go](assets/examples/exit_codes.go) for a pattern mapping errors to exit codes.
+
+## I/O Patterns
+
+See [assets/examples/output.go](assets/examples/output.go) for all I/O patterns:
+
+- **stdout vs stderr**: NEVER write diagnostic output to stdout — stdout is for program output (pipeable), stderr for logs/errors/diagnostics
+- **Detecting pipe vs terminal**: check `os.ModeCharDevice` on stdout
+- **Machine-readable output**: support `--output` flag for table/json/plain formats
+- **Colors**: use `fatih/color` which auto-disables when output is not a terminal
+
+## Signal Handling
+
+Signal handling MUST use `signal.NotifyContext` to propagate cancellation through context. See [assets/examples/signal.go](assets/examples/signal.go) for graceful HTTP server shutdown.
+
+## Shell Completions
+
+Cobra generates completions for bash, zsh, fish, and PowerShell automatically. See [assets/examples/completion.go](assets/examples/completion.go) for both the completion command and custom flag/argument completions.
+
+## Testing CLI Commands
+
+Test commands by executing them programmatically and capturing output. See [assets/examples/cli_test.go](assets/examples/cli_test.go).
+
+Use `cmd.OutOrStdout()` and `cmd.ErrOrStderr()` in commands (instead of `os.Stdout` / `os.Stderr`) so output can be captured in tests.
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Writing to `os.Stdout` directly | Tests can't capture output. Use `cmd.OutOrStdout()` which tests can redirect to a buffer |
+| Calling `os.Exit()` inside `RunE` | Cobra's error handling, deferred functions, and cleanup code never run. Return an error, let `main()` decide |
+| Not binding flags to Viper | Flags won't be configurable via env/config. Call `viper.BindPFlag` for every configurable flag |
+| Missing `viper.SetEnvPrefix` | `PORT` collides with other tools. Use a prefix (`MYAPP_PORT`) to namespace env vars |
+| Logging to stdout | Unix pipes chain stdout — logs corrupt the data stream for the next program. Logs go to stderr |
+| Printing usage on every error | Full help text on every error is noise. Set `SilenceUsage: true`, save full usage for `--help` |
+| Config file required | Users without a config file get a crash. Ignore `viper.ConfigFileNotFoundError` — config should be optional |
+| Not using `PersistentPreRunE` | Config initialization must happen before any subcommand. Use root's `PersistentPreRunE` |
+| Hardcoded version string | Version gets out of sync with tags. Inject via `ldflags` at build time from git tags |
+| Not supporting `--output` format | Scripts can't parse human-readable output. Add JSON/table/plain for machine consumption |
+
+## Related Skills
+
+See `samber/cc-skills-golang@golang-project-layout`, `samber/cc-skills-golang@golang-dependency-injection`, `samber/cc-skills-golang@golang-testing`, `samber/cc-skills-golang@golang-design-patterns` skills.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/args.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/args.go
new file mode 100644
index 00000000..0015945b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/args.go
@@ -0,0 +1,41 @@
+package main
+
+import (
+	"fmt"
+
+	"github.com/spf13/cobra"
+)
+
+// Cobra provides built-in validators for positional arguments.
+// See the table in SKILL.md for all available validators.
+var deployCmd = &cobra.Command{
+	Use:   "deploy [environment]",
+	Short: "Deploy to an environment",
+	Args:  cobra.ExactArgs(1),
+	RunE: func(cmd *cobra.Command, args []string) error {
+		env := args[0]
+		_ = env
+		// deploy...
+		return nil
+	},
+}
+
+// Custom validation example:
+var deployWithValidationCmd = &cobra.Command{
+	Use:   "deploy [environment]",
+	Short: "Deploy to an environment",
+	Args: func(cmd *cobra.Command, args []string) error {
+		if len(args) != 1 {
+			return fmt.Errorf("expected exactly 1 argument, got %d", len(args))
+		}
+		valid := map[string]bool{"dev": true, "staging": true, "prod": true}
+		if !valid[args[0]] {
+			return fmt.Errorf("invalid environment %q, must be one of: dev, staging, prod", args[0])
+		}
+		return nil
+	},
+	RunE: func(cmd *cobra.Command, args []string) error {
+		// deploy...
+		return nil
+	},
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/cli_test.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/cli_test.go
new file mode 100644
index 00000000..483ebcc3
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/cli_test.go
@@ -0,0 +1,58 @@
+package main
+
+import (
+	"bytes"
+	"testing"
+
+	"github.com/spf13/cobra"
+)
+
+// Test commands by executing them programmatically and capturing output.
+// Use cmd.OutOrStdout() and cmd.ErrOrStderr() in commands (instead of
+// os.Stdout / os.Stderr) so output can be captured in tests.
+
+func executeCommand(root *cobra.Command, args ...string) (string, error) {
+	buf := new(bytes.Buffer)
+	root.SetOut(buf)
+	root.SetErr(buf)
+	root.SetArgs(args)
+	err := root.Execute()
+	return buf.String(), err
+}
+
+func TestServeCommand(t *testing.T) {
+	tests := []struct {
+		name    string
+		args    []string
+		want    string
+		wantErr bool
+	}{
+		{
+			name: "default port",
+			args: []string{"serve"},
+			want: "listening on :8080\n",
+		},
+		{
+			name: "custom port",
+			args: []string{"serve", "--port", "9090"},
+			want: "listening on :9090\n",
+		},
+		{
+			name:    "missing required flag",
+			args:    []string{"serve", "--host", ""},
+			wantErr: true,
+		},
+	}
+
+	for _, tt := range tests {
+		t.Run(tt.name, func(t *testing.T) {
+			got, err := executeCommand(rootCmd, tt.args...)
+			if (err != nil) != tt.wantErr {
+				t.Errorf("error = %v, wantErr %v", err, tt.wantErr)
+			}
+			if !tt.wantErr && got != tt.want {
+				t.Errorf("output = %q, want %q", got, tt.want)
+			}
+		})
+	}
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/completion.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/completion.go
new file mode 100644
index 00000000..8ba9620f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/completion.go
@@ -0,0 +1,58 @@
+package main
+
+import (
+	"os"
+
+	"github.com/spf13/cobra"
+)
+
+// === Shell Completion Command ===
+// Cobra generates completions for bash, zsh, fish, and PowerShell automatically.
+
+func init() {
+	rootCmd.AddCommand(&cobra.Command{
+		Use:       "completion [bash|zsh|fish|powershell]",
+		Short:     "Generate shell completion script",
+		Args:      cobra.ExactValidArgs(1),
+		ValidArgs: []string{"bash", "zsh", "fish", "powershell"},
+		RunE: func(cmd *cobra.Command, args []string) error {
+			switch args[0] {
+			case "bash":
+				return rootCmd.GenBashCompletionV2(os.Stdout, true)
+			case "zsh":
+				return rootCmd.GenZshCompletion(os.Stdout)
+			case "fish":
+				return rootCmd.GenFishCompletion(os.Stdout, true)
+			case "powershell":
+				return rootCmd.GenPowerShellCompletionWithDesc(os.Stdout)
+			}
+			return nil
+		},
+	})
+}
+
+// === Custom Completions ===
+// Add custom completions for flags and arguments.
+
+func customCompletionExamples() {
+	deployCmd.RegisterFlagCompletionFunc("env", func(cmd *cobra.Command, args []string, toComplete string) ([]string, cobra.ShellCompDirective) {
+		return []string{
+			"dev\tDevelopment environment",
+			"staging\tStaging environment",
+			"prod\tProduction environment",
+		}, cobra.ShellCompDirectiveNoFileComp
+	})
+
+	// Dynamic argument completion
+	deployCmd.ValidArgsFunction = func(cmd *cobra.Command, args []string, toComplete string) ([]string, cobra.ShellCompDirective) {
+		if len(args) != 0 {
+			return nil, cobra.ShellCompDirectiveNoFileComp
+		}
+		return getAvailableServices(), cobra.ShellCompDirectiveNoFileComp
+	}
+}
+
+func getAvailableServices() []string {
+	// fetch available services dynamically
+	return nil
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/config.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/config.go
new file mode 100644
index 00000000..c0fe6292
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/config.go
@@ -0,0 +1,71 @@
+package main
+
+import (
+	"fmt"
+	"log/slog"
+	"os"
+	"strings"
+
+	"github.com/fsnotify/fsnotify"
+	"github.com/spf13/viper"
+)
+
+// === Complete Cobra + Viper Integration ===
+
+func initConfigComplete() error {
+	// 1. Config file
+	if cfgFile != "" {
+		viper.SetConfigFile(cfgFile) // explicit path
+	} else {
+		home, _ := os.UserHomeDir()
+		viper.AddConfigPath(home) // search $HOME
+		viper.AddConfigPath(".")  // search current dir
+		viper.SetConfigName(".myapp")
+		viper.SetConfigType("yaml")
+	}
+
+	// 2. Environment variables
+	viper.SetEnvPrefix("MYAPP")                            // MYAPP_PORT, MYAPP_LOG_LEVEL
+	viper.SetEnvKeyReplacer(strings.NewReplacer("-", "_")) // log-level → MYAPP_LOG_LEVEL
+	viper.AutomaticEnv()                                   // bind all env vars automatically
+
+	// 3. Read config file (ignore "not found")
+	if err := viper.ReadInConfig(); err != nil {
+		if _, ok := err.(viper.ConfigFileNotFoundError); !ok {
+			return fmt.Errorf("reading config: %w", err)
+		}
+	}
+
+	return nil
+}
+
+// === Unmarshaling into Structs ===
+
+type Config struct {
+	Port     int    `mapstructure:"port"`
+	Host     string `mapstructure:"host"`
+	LogLevel string `mapstructure:"log-level"`
+	Database struct {
+		DSN     string `mapstructure:"dsn"`
+		MaxConn int    `mapstructure:"max-conn"`
+	} `mapstructure:"database"`
+}
+
+func loadConfig() (Config, error) {
+	var cfg Config
+	if err := viper.Unmarshal(&cfg); err != nil {
+		return Config{}, fmt.Errorf("unmarshaling config: %w", err)
+	}
+	return cfg, nil
+}
+
+// === Watching Config File Changes ===
+// For long-running CLIs (servers, daemons):
+
+func watchConfig() {
+	viper.OnConfigChange(func(e fsnotify.Event) {
+		slog.Info("config file changed", "file", e.Name)
+		// re-read and apply config
+	})
+	viper.WatchConfig()
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/exit_codes.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/exit_codes.go
new file mode 100644
index 00000000..d10019bc
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/exit_codes.go
@@ -0,0 +1,28 @@
+package main
+
+import (
+	"errors"
+	"os"
+
+	"github.com/you/myapp/cmd"
+)
+
+// Pattern for mapping errors to exit codes.
+func mainWithExitCodes() {
+	if err := cmd.Execute(); err != nil {
+		// Cobra already printed the error via RunE
+		var exitErr *ExitError
+		if errors.As(err, &exitErr) {
+			os.Exit(exitErr.Code)
+		}
+		os.Exit(1)
+	}
+}
+
+type ExitError struct {
+	Code int
+	Err  error
+}
+
+func (e *ExitError) Error() string { return e.Err.Error() }
+func (e *ExitError) Unwrap() error { return e.Err }
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/flags.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/flags.go
new file mode 100644
index 00000000..7c0995f8
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/flags.go
@@ -0,0 +1,41 @@
+package main
+
+import (
+	"github.com/spf13/cobra"
+	"github.com/spf13/viper"
+)
+
+func flagExamples() {
+	// === Persistent vs Local ===
+
+	// Persistent — inherited by all subcommands
+	rootCmd.PersistentFlags().StringVar(&cfgFile, "config", "", "config file path")
+
+	// Local — only for this command
+	serveCmd.Flags().IntP("port", "p", 8080, "port to listen on")
+
+	// === Required Flags ===
+
+	serveCmd.Flags().String("host", "", "hostname to bind to")
+	serveCmd.MarkFlagRequired("host")
+
+	// Mutually exclusive flags
+	rootCmd.MarkFlagsMutuallyExclusive("json", "yaml")
+
+	// At least one required
+	rootCmd.MarkFlagsOneRequired("output-file", "stdout")
+
+	// === Flag Validation with RegisterFlagCompletionFunc ===
+
+	serveCmd.Flags().String("env", "dev", "environment (dev, staging, prod)")
+	serveCmd.RegisterFlagCompletionFunc("env", func(cmd *cobra.Command, args []string, toComplete string) ([]string, cobra.ShellCompDirective) {
+		return []string{"dev", "staging", "prod"}, cobra.ShellCompDirectiveNoFileComp
+	})
+
+	// === Always Bind Flags to Viper ===
+	// This ensures viper.GetInt("port") returns the flag value, env var MYAPP_PORT,
+	// or config file value — whichever has highest precedence.
+
+	serveCmd.Flags().IntP("port", "p", 8080, "port to listen on")
+	viper.BindPFlag("port", serveCmd.Flags().Lookup("port"))
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/main.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/main.go
new file mode 100644
index 00000000..fec0ac95
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/main.go
@@ -0,0 +1,12 @@
+// cmd/myapp/main.go
+package main
+
+import (
+	"os"
+)
+
+func main() {
+	if err := Execute(); err != nil {
+		os.Exit(1)
+	}
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/output.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/output.go
new file mode 100644
index 00000000..18659682
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/output.go
@@ -0,0 +1,75 @@
+package main
+
+import (
+	"encoding/json"
+	"fmt"
+	"os"
+	"text/tabwriter"
+
+	"github.com/fatih/color"
+	"github.com/spf13/cobra"
+)
+
+// === stdout vs stderr ===
+// stdout: Program output (data, results). This is what gets piped.
+// stderr: Logs, progress, errors, diagnostics. Not piped by default.
+
+func outputExample(cmd *cobra.Command, result string, err error) {
+	// Output data to stdout (pipeable)
+	fmt.Fprintln(cmd.OutOrStdout(), result)
+
+	// Logs and errors to stderr (use slog)
+	// slog.Error("operation failed", "error", err)
+}
+
+// === Detecting Pipe vs Terminal ===
+
+func isTerminal() bool {
+	fi, err := os.Stdout.Stat()
+	if err != nil {
+		return false
+	}
+	return fi.Mode()&os.ModeCharDevice != 0
+}
+
+// === Machine-Readable Output ===
+// Support --output flag for different output formats.
+
+type User struct {
+	ID   string
+	Name string
+}
+
+func printUsers(cmd *cobra.Command, users []User) error {
+	format, _ := cmd.Flags().GetString("output")
+	switch format {
+	case "json":
+		enc := json.NewEncoder(cmd.OutOrStdout())
+		enc.SetIndent("", "  ")
+		return enc.Encode(users)
+	case "plain":
+		for _, u := range users {
+			fmt.Fprintf(cmd.OutOrStdout(), "%s\t%s\n", u.ID, u.Name)
+		}
+	default: // "table"
+		w := tabwriter.NewWriter(cmd.OutOrStdout(), 0, 0, 2, ' ', 0)
+		fmt.Fprintln(w, "ID\tNAME")
+		for _, u := range users {
+			fmt.Fprintf(w, "%s\t%s\n", u.ID, u.Name)
+		}
+		w.Flush()
+	}
+	return nil
+}
+
+// === Colors ===
+// Use fatih/color — it auto-disables when output is not a terminal.
+
+func colorExamples(cmd *cobra.Command, env string, err error) {
+	color.Green("Success: deployed to %s", env)
+	color.Red("Error: %v", err)
+
+	// Or for reusable styles
+	success := color.New(color.FgGreen, color.Bold).SprintFunc()
+	fmt.Fprintf(cmd.OutOrStdout(), "%s deployed\n", success("v1.2.3"))
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/root.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/root.go
new file mode 100644
index 00000000..ae72d65e
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/root.go
@@ -0,0 +1,74 @@
+// cmd/myapp/root.go
+package main
+
+import (
+	"fmt"
+	"log/slog"
+	"os"
+	"strings"
+
+	"github.com/spf13/cobra"
+	"github.com/spf13/viper"
+)
+
+var cfgFile string
+
+var rootCmd = &cobra.Command{
+	Use:   "myapp",
+	Short: "A brief description of your application",
+	Long:  "A longer description with usage examples.",
+	PersistentPreRunE: func(cmd *cobra.Command, args []string) error {
+		return initConfig()
+	},
+	SilenceUsage:  true, // don't print usage on errors from RunE
+	SilenceErrors: true, // handle error printing yourself
+}
+
+func Execute() error {
+	return rootCmd.Execute()
+}
+
+func init() {
+	rootCmd.PersistentFlags().StringVar(&cfgFile, "config", "", "config file (default $HOME/.myapp.yaml)")
+	rootCmd.PersistentFlags().String("log-level", "info", "log level (debug, info, warn, error)")
+	viper.BindPFlag("log-level", rootCmd.PersistentFlags().Lookup("log-level"))
+}
+
+func initConfig() error {
+	if cfgFile != "" {
+		viper.SetConfigFile(cfgFile)
+	} else {
+		home, err := os.UserHomeDir()
+		if err != nil {
+			return fmt.Errorf("finding home directory: %w", err)
+		}
+		viper.AddConfigPath(home)
+		viper.AddConfigPath(".")
+		viper.SetConfigName(".myapp")
+		viper.SetConfigType("yaml")
+	}
+
+	viper.SetEnvPrefix("MYAPP")
+	viper.SetEnvKeyReplacer(strings.NewReplacer("-", "_"))
+	viper.AutomaticEnv()
+
+	if err := viper.ReadInConfig(); err != nil {
+		if _, ok := err.(viper.ConfigFileNotFoundError); !ok {
+			return fmt.Errorf("reading config: %w", err)
+		}
+	}
+
+	// Set up logging based on config
+	level := slog.LevelInfo
+	switch strings.ToLower(viper.GetString("log-level")) {
+	case "debug":
+		level = slog.LevelDebug
+	case "warn":
+		level = slog.LevelWarn
+	case "error":
+		level = slog.LevelError
+	}
+	slog.SetDefault(slog.New(slog.NewTextHandler(os.Stderr, &slog.HandlerOptions{Level: level})))
+
+	return nil
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/serve.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/serve.go
new file mode 100644
index 00000000..69e595f8
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/serve.go
@@ -0,0 +1,31 @@
+// cmd/myapp/serve.go
+package main
+
+import (
+	"fmt"
+
+	"github.com/spf13/cobra"
+	"github.com/spf13/viper"
+)
+
+var serveCmd = &cobra.Command{
+	Use:   "serve",
+	Short: "Start the HTTP server",
+	RunE: func(cmd *cobra.Command, args []string) error {
+		port := viper.GetInt("port")
+		fmt.Fprintf(cmd.OutOrStdout(), "listening on :%d\n", port)
+		// start server...
+		return nil
+	},
+}
+
+func init() {
+	rootCmd.AddCommand(serveCmd)
+	serveCmd.Flags().IntP("port", "p", 8080, "port to listen on")
+	viper.BindPFlag("port", serveCmd.Flags().Lookup("port"))
+}
+
+// For command groups, use AddGroup and set GroupID on commands:
+//
+//   rootCmd.AddGroup(&cobra.Group{ID: "management", Title: "Management Commands:"})
+//   serveCmd.GroupID = "management"
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/signal.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/signal.go
new file mode 100644
index 00000000..7e72edd5
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/signal.go
@@ -0,0 +1,38 @@
+package main
+
+import (
+	"context"
+	"fmt"
+	"log/slog"
+	"net/http"
+	"os"
+	"os/signal"
+	"syscall"
+	"time"
+
+	"github.com/spf13/cobra"
+)
+
+// Use signal.NotifyContext to propagate cancellation through context.
+var serveWithSignalCmd = &cobra.Command{
+	Use:   "serve",
+	Short: "Start the server",
+	RunE: func(cmd *cobra.Command, args []string) error {
+		ctx, stop := signal.NotifyContext(cmd.Context(), os.Interrupt, syscall.SIGTERM)
+		defer stop()
+
+		srv := &http.Server{Addr: ":8080"}
+		go func() {
+			<-ctx.Done()
+			shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
+			defer cancel()
+			srv.Shutdown(shutdownCtx)
+		}()
+
+		slog.Info("server starting", "addr", srv.Addr)
+		if err := srv.ListenAndServe(); err != http.ErrServerClosed {
+			return fmt.Errorf("server failed: %w", err)
+		}
+		return nil
+	},
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/version.go b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/version.go
new file mode 100644
index 00000000..41038f86
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/assets/examples/version.go
@@ -0,0 +1,39 @@
+// cmd/myapp/version.go
+package main
+
+import (
+	"fmt"
+	"runtime/debug"
+
+	"github.com/spf13/cobra"
+)
+
+// Set via ldflags
+var (
+	version = "dev"
+	commit  = "unknown"
+	date    = "unknown"
+)
+
+var versionCmd = &cobra.Command{
+	Use:   "version",
+	Short: "Print version information",
+	Run: func(cmd *cobra.Command, args []string) {
+		fmt.Fprintf(cmd.OutOrStdout(), "myapp %s (commit: %s, built: %s)\n", version, commit, date)
+
+		if info, ok := debug.ReadBuildInfo(); ok {
+			fmt.Fprintf(cmd.OutOrStdout(), "go: %s\n", info.GoVersion)
+		}
+	},
+}
+
+func init() {
+	rootCmd.AddCommand(versionCmd)
+}
+
+// Build with:
+//
+//   go build -ldflags "-X github.com/you/myapp/cmd/myapp.version=1.2.3 \
+//     -X github.com/you/myapp/cmd/myapp.commit=$(git rev-parse --short HEAD) \
+//     -X github.com/you/myapp/cmd/myapp.date=$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
+//     -o bin/myapp ./cmd/myapp
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/evals/evals.json
new file mode 100644
index 00000000..67d455cb
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-cli/evals/evals.json
@@ -0,0 +1,342 @@
+[
+  {
+    "id": 1,
+    "name": "minimal-main-and-execute",
+    "description": "Tests that main.go is minimal and only calls Execute(), with os.Exit handled in main not inside commands",
+    "prompt": "Create the entry point for a Go CLI application called 'deploy' using Cobra. The app should have a root command and a 'push' subcommand. Write main.go and root.go.",
+    "trap": "Model puts configuration logic, flag parsing, or complex setup directly in main.go instead of keeping it minimal. May also call os.Exit inside RunE instead of returning errors.",
+    "assertions": [
+      {
+        "id": "1.1",
+        "text": "main.go only calls Execute() (or rootCmd.Execute()) and os.Exit on error — no configuration, flag setup, or business logic in main()"
+      },
+      {
+        "id": "1.2",
+        "text": "The root command sets SilenceUsage: true to prevent printing full usage text on every error"
+      },
+      {
+        "id": "1.3",
+        "text": "The root command sets SilenceErrors: true to control error output format"
+      },
+      {
+        "id": "1.4",
+        "text": "Subcommands do NOT call os.Exit() inside RunE — they return errors and let main() decide the exit code"
+      },
+      {
+        "id": "1.5",
+        "text": "The push subcommand is registered via rootCmd.AddCommand() in an init() function or setup function"
+      }
+    ]
+  },
+  {
+    "id": 2,
+    "name": "viper-config-layering",
+    "description": "Tests proper Viper configuration precedence: flags > env > config file > defaults, with env prefix and config-file-not-required",
+    "prompt": "I'm building a Go CLI server tool with Cobra. It needs a --port flag (default 3000) that can also be set via the MYSERVER_PORT env var or a config file at ~/.myserver.yaml. Write the configuration setup code.",
+    "trap": "Model doesn't bind flags to Viper (so flags and env/config are disconnected), forgets SetEnvPrefix (causing env var collisions), or crashes when no config file exists instead of ignoring ConfigFileNotFoundError.",
+    "assertions": [
+      {
+        "id": "2.1",
+        "text": "Calls viper.BindPFlag to bind the port flag to Viper, ensuring viper.GetInt('port') returns the flag value when set"
+      },
+      {
+        "id": "2.2",
+        "text": "Sets an env prefix with viper.SetEnvPrefix('MYSERVER' or similar) to namespace env vars and avoid collisions"
+      },
+      {
+        "id": "2.3",
+        "text": "Calls viper.AutomaticEnv() to enable automatic env var binding"
+      },
+      {
+        "id": "2.4",
+        "text": "Handles viper.ConfigFileNotFoundError gracefully (ignores it) — config file is optional, not crashing when absent"
+      },
+      {
+        "id": "2.5",
+        "text": "The precedence order is correct: CLI flags > environment variables > config file > defaults"
+      }
+    ]
+  },
+  {
+    "id": 3,
+    "name": "persistent-pre-run-config-init",
+    "description": "Tests that configuration initialization happens in PersistentPreRunE on the root command",
+    "prompt": "My Go CLI has a root command and three subcommands (serve, migrate, status). All of them need access to a database DSN from config. Where should I initialize the configuration so all subcommands have access? Write the code.",
+    "trap": "Model initializes config inside each subcommand's RunE (duplicating logic), or uses a global init() function instead of PersistentPreRunE, or puts it in cobra.OnInitialize without connecting it to the command tree properly.",
+    "assertions": [
+      {
+        "id": "3.1",
+        "text": "Configuration initialization happens in PersistentPreRunE on the root command — this ensures it runs before every subcommand"
+      },
+      {
+        "id": "3.2",
+        "text": "Config init is NOT duplicated inside each subcommand's RunE — it happens once in the root"
+      },
+      {
+        "id": "3.3",
+        "text": "The --config flag (or equivalent) is a persistent flag on the root command so all subcommands inherit it"
+      },
+      {
+        "id": "3.4",
+        "text": "Environment variables use a replacer (SetEnvKeyReplacer) to handle hyphens-to-underscores mapping (e.g., log-level becomes LOG_LEVEL)"
+      },
+      {
+        "id": "3.5",
+        "text": "Logging is configured to write to stderr, not stdout"
+      }
+    ]
+  },
+  {
+    "id": 4,
+    "name": "stdout-vs-stderr-separation",
+    "description": "Tests that program output goes to stdout and diagnostics/errors/logs go to stderr",
+    "prompt": "Write a Go CLI command 'list-users' using Cobra that fetches users from a database and prints them. It should log progress messages, handle errors, and support being piped to other commands (e.g., `myapp list-users | grep admin`). Write the RunE function.",
+    "trap": "Model writes log messages, error messages, or progress indicators to stdout (using fmt.Println) instead of stderr, which would corrupt piped output. May also use os.Stdout directly instead of cmd.OutOrStdout().",
+    "assertions": [
+      {
+        "id": "4.1",
+        "text": "Program output (the user list) goes to stdout via cmd.OutOrStdout() or fmt.Fprint(cmd.OutOrStdout(), ...) — NOT os.Stdout directly"
+      },
+      {
+        "id": "4.2",
+        "text": "Log messages, progress indicators, or diagnostic output go to stderr (via slog, log, or fmt.Fprint(os.Stderr, ...)) — NOT stdout"
+      },
+      {
+        "id": "4.3",
+        "text": "Error messages go to stderr (via cmd.ErrOrStderr() or os.Stderr), not mixed with program output on stdout"
+      },
+      {
+        "id": "4.4",
+        "text": "Uses cmd.OutOrStdout() instead of os.Stdout directly, enabling test capture"
+      },
+      {
+        "id": "4.5",
+        "text": "The function returns an error from RunE rather than calling os.Exit() or log.Fatal() on failure"
+      }
+    ]
+  },
+  {
+    "id": 5,
+    "name": "version-ldflags-injection",
+    "description": "Tests that version info is injected at build time via ldflags, not hardcoded",
+    "prompt": "Add a 'version' command to my Go CLI app that shows the version, git commit, and build date. How should I handle the version string?",
+    "trap": "Model hardcodes the version string as a constant (const version = \"1.0.0\") instead of using ldflags injection. May also not include the build command example.",
+    "assertions": [
+      {
+        "id": "5.1",
+        "text": "Version, commit, and date are package-level variables (var, not const) with placeholder defaults like 'dev' or 'unknown'"
+      },
+      {
+        "id": "5.2",
+        "text": "Shows or explains the -ldflags '-X ...' build command for injecting values at compile time"
+      },
+      {
+        "id": "5.3",
+        "text": "The version command uses cmd.OutOrStdout() for output, not fmt.Println or os.Stdout directly"
+      },
+      {
+        "id": "5.4",
+        "text": "Version is NOT hardcoded as a const string that would get out of sync with git tags"
+      },
+      {
+        "id": "5.5",
+        "text": "Optionally includes runtime/debug.ReadBuildInfo() as a fallback or supplement for Go module version info"
+      }
+    ]
+  },
+  {
+    "id": 6,
+    "name": "exit-code-conventions",
+    "description": "Tests proper Unix exit code mapping — 0 for success, 1 for general error, 2 for usage errors",
+    "prompt": "My Go CLI tool needs to report different exit codes for different failure types: invalid arguments, missing config file, network timeout, and successful completion. Write the error handling and exit code logic in main.go.",
+    "trap": "Model uses the same exit code (1) for all errors, or calls os.Exit deep inside command handlers instead of in main(). May also use non-standard exit codes.",
+    "assertions": [
+      {
+        "id": "6.1",
+        "text": "Exit code 0 for success, exit code 1 for general runtime errors, exit code 2 for usage/argument errors — follows Unix conventions"
+      },
+      {
+        "id": "6.2",
+        "text": "os.Exit() is called only in main(), not inside RunE functions or command handlers"
+      },
+      {
+        "id": "6.3",
+        "text": "Uses a typed error or error wrapping pattern (like ExitError with a Code field) to propagate exit codes from commands to main"
+      },
+      {
+        "id": "6.4",
+        "text": "Errors are returned from commands, not swallowed with os.Exit() calls that skip deferred cleanup"
+      },
+      {
+        "id": "6.5",
+        "text": "Different error categories map to different exit codes, not all errors producing exit code 1"
+      }
+    ]
+  },
+  {
+    "id": 7,
+    "name": "signal-handling-with-context",
+    "description": "Tests that signal handling uses signal.NotifyContext for context-based cancellation",
+    "prompt": "My Go CLI has a long-running 'serve' command that starts an HTTP server. I need graceful shutdown when the user presses Ctrl+C. Write the signal handling code.",
+    "trap": "Model uses a raw signal channel with signal.Notify instead of signal.NotifyContext, missing context propagation. May also not handle the shutdown timeout or forget SIGTERM.",
+    "assertions": [
+      {
+        "id": "7.1",
+        "text": "Uses signal.NotifyContext to propagate cancellation through context — NOT a raw channel with signal.Notify and manual select"
+      },
+      {
+        "id": "7.2",
+        "text": "Handles both os.Interrupt (Ctrl+C / SIGINT) and syscall.SIGTERM (container orchestrators)"
+      },
+      {
+        "id": "7.3",
+        "text": "Creates a shutdown timeout context (e.g., 10-30 seconds) for graceful shutdown, not blocking indefinitely"
+      },
+      {
+        "id": "7.4",
+        "text": "Calls srv.Shutdown(ctx) for graceful HTTP server shutdown, not srv.Close() which drops in-flight requests"
+      },
+      {
+        "id": "7.5",
+        "text": "Distinguishes http.ErrServerClosed (normal shutdown) from unexpected server errors"
+      }
+    ]
+  },
+  {
+    "id": 8,
+    "name": "flag-binding-and-constraints",
+    "description": "Tests flag patterns: persistent vs local, required flags, mutual exclusion, and Viper binding",
+    "prompt": "My Go CLI 'deploy' command needs these flags:\n- --env (required, must be one of: dev, staging, prod)\n- --tag (required, the docker image tag)\n- --dry-run and --force (mutually exclusive)\n- --verbose (available on all commands, not just deploy)\n\nWrite the flag setup code using Cobra.",
+    "trap": "Model makes --verbose a local flag instead of persistent, doesn't use MarkFlagsMutuallyExclusive for dry-run/force, or forgets to bind flags to Viper.",
+    "assertions": [
+      {
+        "id": "8.1",
+        "text": "--verbose is a persistent flag (PersistentFlags) on the root command, not a local flag on deploy — it needs to be available on all commands"
+      },
+      {
+        "id": "8.2",
+        "text": "Uses MarkFlagRequired for --env and --tag flags"
+      },
+      {
+        "id": "8.3",
+        "text": "Uses MarkFlagsMutuallyExclusive for --dry-run and --force"
+      },
+      {
+        "id": "8.4",
+        "text": "Uses RegisterFlagCompletionFunc to provide completion values for --env (dev, staging, prod)"
+      },
+      {
+        "id": "8.5",
+        "text": "Binds configurable flags to Viper with viper.BindPFlag so they can be set via env vars or config file"
+      }
+    ]
+  },
+  {
+    "id": 9,
+    "name": "argument-validation",
+    "description": "Tests use of Cobra's built-in argument validators instead of manual validation in RunE",
+    "prompt": "I have three Cobra commands:\n1. 'status' — takes no arguments\n2. 'deploy' — takes exactly one argument (the service name)\n3. 'scale' — takes 2-3 arguments (service, replica count, optional region)\n\nHow should I validate the arguments for each command?",
+    "trap": "Model manually validates len(args) inside RunE instead of using Cobra's declarative validators (cobra.NoArgs, cobra.ExactArgs, cobra.RangeArgs). May also use custom validation where built-in validators suffice.",
+    "assertions": [
+      {
+        "id": "9.1",
+        "text": "Uses cobra.NoArgs for the status command — not manual len(args) == 0 check"
+      },
+      {
+        "id": "9.2",
+        "text": "Uses cobra.ExactArgs(1) for the deploy command — not manual len(args) != 1 check"
+      },
+      {
+        "id": "9.3",
+        "text": "Uses cobra.RangeArgs(2, 3) for the scale command — not manual len(args) < 2 || len(args) > 3 check"
+      },
+      {
+        "id": "9.4",
+        "text": "Validators are set on the Args field of the command struct, not implemented inside RunE"
+      }
+    ]
+  },
+  {
+    "id": 10,
+    "name": "cli-testing-pattern",
+    "description": "Tests that CLI commands are tested by executing programmatically with captured output",
+    "prompt": "Write tests for a Cobra CLI command 'greet' that takes a --name flag and prints a greeting. Test the default behavior and a custom name. Show the test helper and test function.",
+    "trap": "Model tests by running os.exec on the compiled binary instead of executing commands programmatically. May also not capture output via cmd.SetOut/cmd.SetErr buffers.",
+    "assertions": [
+      {
+        "id": "10.1",
+        "text": "Creates an executeCommand helper that sets up a buffer, calls cmd.SetOut(buf) and cmd.SetErr(buf), sets args, and executes"
+      },
+      {
+        "id": "10.2",
+        "text": "Tests are table-driven with multiple cases (at least default and custom name)"
+      },
+      {
+        "id": "10.3",
+        "text": "Uses cmd.SetArgs() to pass arguments programmatically — not os/exec.Command"
+      },
+      {
+        "id": "10.4",
+        "text": "Captures output via a bytes.Buffer set on the command — not by redirecting os.Stdout"
+      },
+      {
+        "id": "10.5",
+        "text": "Tests check both the output string and the error return value"
+      }
+    ]
+  },
+  {
+    "id": 11,
+    "name": "machine-readable-output-format",
+    "description": "Tests support for --output flag with multiple formats (json/table/plain) for scriptability",
+    "prompt": "My Go CLI command 'list-services' shows running services. I need it to support both human-readable and machine-parseable output for scripting. What's the best approach?",
+    "trap": "Model only supports a single output format, or adds a --json boolean flag instead of a flexible --output format flag. May also not use tabwriter for table output.",
+    "assertions": [
+      {
+        "id": "11.1",
+        "text": "Supports an --output flag with at least json and table formats (not just a --json boolean toggle)"
+      },
+      {
+        "id": "11.2",
+        "text": "JSON output uses encoding/json encoder writing to cmd.OutOrStdout()"
+      },
+      {
+        "id": "11.3",
+        "text": "Table output uses text/tabwriter or similar for aligned columns — not ad-hoc spacing"
+      },
+      {
+        "id": "11.4",
+        "text": "The default format is human-readable (table), with JSON/plain as opt-in machine formats"
+      }
+    ]
+  },
+  {
+    "id": 12,
+    "name": "shell-completion-setup",
+    "description": "Tests proper shell completion command and custom completions for flags",
+    "prompt": "Add shell completion support to my Go CLI built with Cobra. I want users to be able to run 'myapp completion bash' to generate a completion script. Also, the --env flag should suggest 'dev', 'staging', 'prod' during tab completion.",
+    "trap": "Model implements completion from scratch instead of using Cobra's built-in generators. May forget the ValidArgs field or RegisterFlagCompletionFunc for custom completions.",
+    "assertions": [
+      {
+        "id": "12.1",
+        "text": "Creates a 'completion' subcommand that supports bash, zsh, fish, and powershell as arguments"
+      },
+      {
+        "id": "12.2",
+        "text": "Uses Cobra's built-in completion generators (GenBashCompletionV2, GenZshCompletion, GenFishCompletion, GenPowerShellCompletionWithDesc) — not custom completion scripts"
+      },
+      {
+        "id": "12.3",
+        "text": "Uses RegisterFlagCompletionFunc for the --env flag to suggest dev/staging/prod values"
+      },
+      {
+        "id": "12.4",
+        "text": "Uses cobra.ExactValidArgs or ValidArgs to validate completion arguments for the completion command itself"
+      },
+      {
+        "id": "12.5",
+        "text": "Returns cobra.ShellCompDirectiveNoFileComp for flags that don't accept file paths"
+      }
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/SKILL.md
new file mode 100644
index 00000000..89688721
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/SKILL.md
@@ -0,0 +1,236 @@
+---
+name: golang-code-style
+description: "Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See `samber/cc-skills-golang@golang-naming` skill), linter configuration (→ See `samber/cc-skills-golang@golang-lint` skill), or doc comments (→ See `samber/cc-skills-golang@golang-documentation` skill)."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.0"
+  openclaw:
+    emoji: "🎨"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent
+---
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-code-style` skill takes precedence.
+
+# Go Code Style
+
+Style rules that require human judgment — linters handle formatting, this skill handles clarity. For naming see `samber/cc-skills-golang@golang-naming` skill; for design patterns see `samber/cc-skills-golang@golang-design-patterns` skill; for struct/interface design see `samber/cc-skills-golang@golang-structs-interfaces` skill.
+
+> "Clear is better than clever." — Go Proverbs
+
+When ignoring a rule, add a comment to the code.
+
+## Line Length & Breaking
+
+No rigid line limit, but lines beyond ~120 characters MUST be broken. Break at **semantic boundaries**, not arbitrary column counts. Function calls with 4+ arguments MUST use one argument per line — even when the prompt asks for single-line code:
+
+```go
+// Good — each argument on its own line, closing paren separate
+mux.HandleFunc("/api/users", func(w http.ResponseWriter, r *http.Request) {
+    handleUsers(
+        w,
+        r,
+        serviceName,
+        cfg,
+        logger,
+        authMiddleware,
+    )
+})
+```
+
+When a function signature is too long, the real fix is often **fewer parameters** (use an options struct) rather than better line wrapping. For multi-line signatures, put each parameter on its own line.
+
+## Variable Declarations
+
+SHOULD use `:=` for non-zero values, `var` for zero-value initialization. The form signals intent: `var` means "this starts at zero."
+
+```go
+var count int              // zero value, set later
+name := "default"          // non-zero, := is appropriate
+var buf bytes.Buffer       // zero value is ready to use
+```
+
+### Slice & Map Initialization
+
+Slices and maps MUST be initialized explicitly, never nil. Nil maps panic on write; nil slices serialize to `null` in JSON (vs `[]` for empty slices), surprising API consumers.
+
+```go
+users := []User{}                       // always initialized
+m := map[string]int{}                   // always initialized
+users := make([]User, 0, len(ids))      // preallocate when capacity is known
+m := make(map[string]int, len(items))   // preallocate when size is known
+```
+
+Do not preallocate speculatively — `make([]T, 0, 1000)` wastes memory when the common case is 10 items.
+
+### Composite Literals
+
+Composite literals MUST use field names — positional fields break when the type adds or reorders fields:
+
+```go
+srv := &http.Server{
+    Addr:         ":8080",
+    ReadTimeout:  5 * time.Second,
+    WriteTimeout: 10 * time.Second,
+}
+```
+
+## Control Flow
+
+### Reduce Nesting
+
+Errors and edge cases MUST be handled first (early return). Keep the happy path at minimal indentation:
+
+```go
+func process(data []byte) (*Result, error) {
+    if len(data) == 0 {
+        return nil, errors.New("empty data")
+    }
+
+    parsed, err := parse(data)
+    if err != nil {
+        return nil, fmt.Errorf("parsing: %w", err)
+    }
+
+    return transform(parsed), nil
+}
+```
+
+### Eliminate Unnecessary `else`
+
+When the `if` body ends with `return`/`break`/`continue`, the `else` MUST be dropped. Use default-then-override for simple assignments — assign a default, then override with independent conditions or a `switch`:
+
+```go
+// Good — default-then-override with switch (cleanest for mutually exclusive overrides)
+level := slog.LevelInfo
+switch {
+case debug:
+    level = slog.LevelDebug
+case verbose:
+    level = slog.LevelWarn
+}
+
+// Bad — else-if chain hides that there's a default
+if debug {
+    level = slog.LevelDebug
+} else if verbose {
+    level = slog.LevelWarn
+} else {
+    level = slog.LevelInfo
+}
+```
+
+### Complex Conditions & Init Scope
+
+When an `if` condition has 3+ operands, MUST extract into named booleans — a wall of `||` is unreadable and hides business logic. Keep expensive checks inline for short-circuit benefit. [Details](./references/details.md)
+
+```go
+// Good — named booleans make intent clear
+isAdmin := user.Role == RoleAdmin
+isOwner := resource.OwnerID == user.ID
+isPublicVerified := resource.IsPublic && user.IsVerified
+if isAdmin || isOwner || isPublicVerified || permissions.Contains(PermOverride) {
+    allow()
+}
+```
+
+Scope variables to `if` blocks when only needed for the check:
+
+```go
+if err := validate(input); err != nil {
+    return err
+}
+```
+
+### Switch Over If-Else Chains
+
+When comparing the same variable multiple times, prefer `switch`:
+
+```go
+switch status {
+case StatusActive:
+    activate()
+case StatusInactive:
+    deactivate()
+default:
+    panic(fmt.Sprintf("unexpected status: %d", status))
+}
+```
+
+## Function Design
+
+- Functions SHOULD be **short and focused** — one function, one job.
+- Functions SHOULD have **≤4 parameters**. Beyond that, use an options struct (see `samber/cc-skills-golang@golang-design-patterns` skill).
+- **Parameter order**: `context.Context` first, then inputs, then output destinations.
+- Naked returns help in very short functions (1-3 lines) where return values are obvious, but become confusing when readers must scroll to find what's returned — name returns explicitly in longer functions.
+
+```go
+func FetchUser(ctx context.Context, id string) (*User, error)
+func SendEmail(ctx context.Context, msg EmailMessage) error  // grouped into struct
+```
+
+### Prefer `range` for Iteration
+
+SHOULD use `range` over index-based loops. Use `range n` (Go 1.22+) for simple counting.
+
+```go
+for _, user := range users {
+    process(user)
+}
+```
+
+## Value vs Pointer Arguments
+
+Pass small types (`string`, `int`, `bool`, `time.Time`) by value. Use pointers when mutating, for large structs (~128+ bytes), or when nil is meaningful. [Details](./references/details.md)
+
+## Code Organization Within Files
+
+- **Group related declarations**: type, constructor, methods together
+- **Order**: package doc, imports, constants, types, constructors, methods, helpers
+- **One primary type per file** when it has significant methods
+- **Blank imports** (`_ "pkg"`) register side effects (init functions). Restricting them to `main` and test packages makes side effects visible at the application root, not hidden in library code
+- **Dot imports** pollute the namespace and make it impossible to tell where a name comes from — never use in library code
+- **Unexport aggressively** — you can always export later; unexporting is a breaking change
+
+## String Handling
+
+Use `strconv` for simple conversions (faster), `fmt.Sprintf` for complex formatting. Use `%q` in error messages to make string boundaries visible. Use `strings.Builder` for loops, `+` for simple concatenation.
+
+## Type Conversions
+
+Prefer explicit, narrow conversions. Use generics over `any` when a concrete type will do:
+
+```go
+func Contains[T comparable](slice []T, target T) bool  // not []any
+```
+
+## Philosophy
+
+- **"A little copying is better than a little dependency"**
+- **Use `slices` and `maps` standard packages**; for filter/group-by/chunk, use `github.com/samber/lo`
+- **"Reflection is never clear"** — avoid `reflect` unless necessary
+- **Don't abstract prematurely** — extract when the pattern is stable
+- **Minimize public surface** — every exported name is a commitment
+
+## Parallelizing Code Style Reviews
+
+When reviewing code style across a large codebase, use up to 5 parallel sub-agents (via the Agent tool), each targeting an independent style concern (e.g. control flow, function design, variable declarations, string handling, code organization).
+
+## Enforce with Linters
+
+Many rules are enforced automatically: `gofmt`, `gofumpt`, `goimports`, `gocritic`, `revive`, `wsl_v5`. → See the `samber/cc-skills-golang@golang-lint` skill.
+
+## Cross-References
+
+- → See the `samber/cc-skills-golang@golang-naming` skill for identifier naming conventions
+- → See the `samber/cc-skills-golang@golang-structs-interfaces` skill for pointer vs value receivers, interface design
+- → See the `samber/cc-skills-golang@golang-design-patterns` skill for functional options, builders, constructors
+- → See the `samber/cc-skills-golang@golang-lint` skill for automated formatting enforcement
+- → See `samber/cc-skills-golang@golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/evals/evals.json
new file mode 100644
index 00000000..df03154f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/evals/evals.json
@@ -0,0 +1,570 @@
+[
+  {
+    "id": 1,
+    "name": "zero-value-intent-signal",
+    "description": "var vs := signals intent: var for zero-value start, := for non-zero — even when the zero value IS the business default",
+    "prompt": "Write a Go file `session.go` in package `session`. Create a Session struct with fields: userID string, requestCount int, isAuthenticated bool, lastError error, startedAt time.Time, tags []string. Add a constructor NewSession(userID string) that initializes the struct. In the constructor, requestCount starts at zero (it will be incremented on each use), isAuthenticated starts false (it must be explicitly set after login), lastError starts nil, startedAt is set to time.Now(), and tags is initialized as an empty slice. Also add a local variable inside a method Describe() that builds a description string from a fixed prefix 'session:'.",
+    "trap": "Model uses := for all fields including zero-value ones (requestCount := 0, isAuthenticated := false) or uses var for non-zero assignments like startedAt, obscuring intent",
+    "assertions": [
+      {
+        "id": "1.1",
+        "text": "requestCount is NOT explicitly initialized to 0 in the constructor — the zero value is relied upon via var or struct literal without that field, not via requestCount := 0"
+      },
+      {
+        "id": "1.2",
+        "text": "startedAt uses := assignment (startedAt := time.Now() or field assignment) — NOT var startedAt time.Time followed by assignment — because it has a non-zero meaningful value"
+      },
+      {
+        "id": "1.3",
+        "text": "The fixed prefix string variable in Describe() uses := (prefix := 'session:') — not var prefix string = 'session:'"
+      },
+      {
+        "id": "1.4",
+        "text": "tags is initialized with []string{} or make([]string, 0) — never nil — because nil slices serialize to null in JSON"
+      }
+    ]
+  },
+  {
+    "id": 2,
+    "name": "empty-slice-map-not-nil",
+    "description": "Empty collections initialized as []T{} or make(), never nil",
+    "prompt": "Write a Go file `handler.go` in package `api`. Create a Handler struct. Add a method ListUsers that returns a slice of User structs (define User with Name and Email fields). Add a method GetTags that returns a map[string]string. Both methods should return empty collections when there's no data. Add a method BuildResponse that takes a slice of results and a map of metadata and processes them.",
+    "trap": "Model returns nil slices/maps or uses uninitialized var declarations for empty collections, causing nil != empty issues in JSON serialization and caller code",
+    "assertions": [
+      {
+        "id": "2.1",
+        "text": "Empty slice return uses []User{} or make([]User, 0) — never returns nil or an uninitialized var declaration without assignment"
+      },
+      {
+        "id": "2.2",
+        "text": "Empty map return uses map[string]string{} or make(map[string]string) — never returns nil or an uninitialized var declaration without assignment"
+      },
+      {
+        "id": "2.3",
+        "text": "When capacity is known (e.g., from len(input)), make() with capacity hint is used for preallocating slices or maps"
+      }
+    ]
+  },
+  {
+    "id": 3,
+    "name": "named-struct-fields-nested",
+    "description": "All struct literals use named fields, including nested and anonymous structs",
+    "prompt": "Write a Go file `middleware.go` in package `middleware`. Create a RateLimiter struct with fields: windowSize time.Duration, maxRequests int, perIP bool. Create a middleware chain config using a struct literal with nested structs: a TimeoutConfig containing duration and errorMessage, a RetryConfig containing maxAttempts int and backoff time.Duration, and a CircuitBreakerConfig containing threshold float64 and resetAfter time.Duration. Instantiate each of these structs as part of a larger MiddlewareConfig struct. Also create a tls.Config with MinVersion and a list of cipher suites.",
+    "trap": "Model uses positional struct literals for the nested configs since they have few fields — e.g., TimeoutConfig{5*time.Second, 'timeout'} — which silently breaks when fields are reordered",
+    "assertions": [
+      {
+        "id": "3.1",
+        "text": "RateLimiter literal uses named fields (WindowSize:, MaxRequests:, PerIP:) — not positional"
+      },
+      {
+        "id": "3.2",
+        "text": "TimeoutConfig, RetryConfig, and CircuitBreakerConfig literals all use named fields — not positional — even though each has only 2-3 fields"
+      },
+      {
+        "id": "3.3",
+        "text": "tls.Config literal uses named fields (MinVersion:, CipherSuites:)"
+      },
+      {
+        "id": "3.4",
+        "text": "No struct literal in the file uses positional field syntax"
+      }
+    ]
+  },
+  {
+    "id": 4,
+    "name": "early-return-not-nested",
+    "description": "Validation uses early returns; happy path at minimal indentation despite prompt asking for nesting",
+    "prompt": "Write a Go function ProcessOrder in package `orders` that takes an order struct (define it with fields: ID string, Items []Item, Status string, CustomerID string). The function should validate that the ID is not empty, that there is at least one item, that the status is 'pending', that the customer exists (simulate with a lookup function), compute the total price, apply a discount if total > 100, and return the final total with an error. Write it with deeply nested if-else blocks.",
+    "trap": "Model follows the prompt's instruction to use deeply nested if-else blocks, burying the happy path inside 4+ levels of indentation",
+    "assertions": [
+      {
+        "id": "4.1",
+        "text": "Validation checks (empty ID, no items, wrong status) use early return pattern — each check returns an error immediately rather than nesting the rest of the function inside an else block"
+      },
+      {
+        "id": "4.2",
+        "text": "The happy path (compute total, apply discount, return) is at the top level of the function body (indentation level 1), not nested inside multiple if blocks"
+      },
+      {
+        "id": "4.3",
+        "text": "The function has at most 2 levels of indentation for the main logic (excluding the error-check if blocks which return early)"
+      }
+    ]
+  },
+  {
+    "id": 5,
+    "name": "no-else-after-return",
+    "description": "No else after return; default-then-override for simple assignments",
+    "prompt": "Write a Go function GetUserRole in package `auth` that takes a user struct with IsAdmin bool, IsModerator bool, and IsVerified bool fields. Return a role string: if admin return 'admin', else if moderator return 'moderator', else if verified return 'member', else return 'guest'. Also write a function SetLogLevel that takes a verbose bool and a debug bool, and sets the log level appropriately using slog.",
+    "trap": "Model uses else-if chains after return statements, adding unnecessary indentation and cognitive load",
+    "assertions": [
+      {
+        "id": "5.1",
+        "text": "GetUserRole does NOT use else or else-if after a return statement — either uses early returns (if isAdmin { return 'admin' }; if isModerator { return 'moderator' }) or a switch statement"
+      },
+      {
+        "id": "5.2",
+        "text": "SetLogLevel uses the default-then-override pattern: assigns a default level first, then conditionally overrides with if (not if-else chains)"
+      }
+    ]
+  },
+  {
+    "id": 6,
+    "name": "switch-over-if-else-chain",
+    "description": "Multi-branch comparisons use switch statements, not if-else chains",
+    "prompt": "Write a Go function HandleEvent in package `events` that takes an event with a Type string field. The type can be 'click', 'scroll', 'keypress', 'hover', 'focus', or 'blur'. Each type should call a different handler function. Also write a function MapStatusCode that takes an int HTTP status code and returns a human-readable string for 200, 201, 204, 400, 401, 403, 404, 500, 502, 503.",
+    "trap": "Model uses if-else chains for multi-branch string/int comparisons instead of switch statements",
+    "assertions": [
+      {
+        "id": "6.1",
+        "text": "HandleEvent uses a switch statement on event.Type, not an if-else chain"
+      },
+      {
+        "id": "6.2",
+        "text": "MapStatusCode uses a switch statement on the status code, not an if-else chain"
+      },
+      {
+        "id": "6.3",
+        "text": "Both switch statements include a default case"
+      }
+    ]
+  },
+  {
+    "id": 7,
+    "name": "options-struct-not-many-params",
+    "description": "Groups params into options struct, context.Context first",
+    "prompt": "Write a Go function SendNotification in package `notify` that sends a notification. It needs these parameters: ctx context.Context, userID string, message string, channel string (email/sms/push), priority int, retryCount int, dryRun bool, templateID string, metadata map[string]string, callback func(error). Put all parameters directly in the function signature.",
+    "trap": "Model follows the prompt's instruction to put all 10 parameters directly in the function signature, creating an unusable API",
+    "assertions": [
+      {
+        "id": "7.1",
+        "text": "context.Context is the first parameter in the function signature"
+      },
+      {
+        "id": "7.2",
+        "text": "The function uses an options struct (or similar grouping) to reduce the parameter count to 4 or fewer in the main function signature — not all 10 parameters listed individually"
+      },
+      {
+        "id": "7.3",
+        "text": "The options struct groups related configuration (channel, priority, retryCount, dryRun, templateID, metadata, callback) into a single parameter"
+      }
+    ]
+  },
+  {
+    "id": 8,
+    "name": "value-vs-pointer-params",
+    "description": "Value params for small types; pointers only for mutation — not pointer everything",
+    "prompt": "Write Go functions in package `users`: (1) FormatName that takes a first name string and last name string and returns the formatted full name, (2) UpdateAge that modifies a User struct's age field, (3) FindUser that takes a user ID string and returns a User pointer, (4) CompareUsers that checks if two User structs (each about 32 bytes with Name string and Age int) are equal. Use pointer parameters for all functions.",
+    "trap": "Model follows the prompt's instruction to use pointer parameters for all functions, including small value types like string and int where pointers only add indirection",
+    "assertions": [
+      {
+        "id": "8.1",
+        "text": "FormatName takes string parameters by value (not *string) — strings are small fixed-size types"
+      },
+      {
+        "id": "8.2",
+        "text": "UpdateAge takes a *User pointer parameter because it mutates the struct"
+      },
+      {
+        "id": "8.3",
+        "text": "CompareUsers takes User structs by value (not *User) because it only reads them and they are small (<128 bytes)"
+      }
+    ]
+  },
+  {
+    "id": 9,
+    "name": "unexported-internal-helpers",
+    "description": "Helper functions called only within the same package stay unexported; exporting is a commitment",
+    "prompt": "Write a Go file `parser.go` in package `config`. Include: an exported ParseConfig function that reads a file path and returns a *Config struct; an exported ValidateConfig function that checks required fields; a helper function that tokenizes a raw config string (used only by ParseConfig); a helper function that resolves environment variable references in values (used by ParseConfig and ValidateConfig); a helper function that formats a field path for error messages (used only in error messages inside ValidateConfig). Make all functions exported for potential future reuse from other packages.",
+    "trap": "Model follows the prompt's instruction to export all functions, leaking tokenizer, env resolver, and error formatter as public API — any future change to them becomes a breaking change",
+    "assertions": [
+      {
+        "id": "9.1",
+        "text": "The tokenizer helper (used only by ParseConfig) is unexported (lowercase name)"
+      },
+      {
+        "id": "9.2",
+        "text": "The error message formatter (used only inside ValidateConfig) is unexported (lowercase name)"
+      },
+      {
+        "id": "9.3",
+        "text": "ParseConfig and ValidateConfig remain exported — they are the true public API"
+      },
+      {
+        "id": "9.4",
+        "text": "The env variable resolver may be exported OR unexported — both are defensible since it's used by two functions, but the model should NOT export all helpers blindly"
+      }
+    ]
+  },
+  {
+    "id": 10,
+    "name": "strings-join-not-builder-for-known-slice",
+    "description": "strings.Join for joining a known slice; strings.Builder for dynamic/loop accumulation — not one-size-fits-all",
+    "prompt": "Write a Go file `format.go` in package `format` with four functions: (1) JoinTags that takes a []string of tags and returns them comma-separated, (2) BuildCSVRow that takes a []string of fields and returns a CSV line with quotes and commas, (3) BuildAuditLog that takes a slice of AuditEntry structs (each with timestamp and message fields) and returns a multi-line string by iterating over entries, (4) FormatError that takes an error code int and a description string and returns a formatted error string like 'ERR-42: bad input'.",
+    "trap": "Model uses strings.Builder for everything including JoinTags (which should use strings.Join) and fmt.Sprintf for the int conversion in FormatError instead of strconv",
+    "assertions": [
+      {
+        "id": "10.1",
+        "text": "JoinTags uses strings.Join(tags, ',') — not a manual loop or strings.Builder — because the input is already a complete slice"
+      },
+      {
+        "id": "10.2",
+        "text": "BuildAuditLog uses strings.Builder (WriteString in a loop) — not repeated += — because entries are accumulated one at a time in a loop"
+      },
+      {
+        "id": "10.3",
+        "text": "FormatError uses fmt.Sprintf (or strconv.Itoa for the int part) — NOT strings.Builder — because it formats a short fixed-structure message"
+      },
+      {
+        "id": "10.4",
+        "text": "No function uses += string concatenation inside a loop body"
+      }
+    ]
+  },
+  {
+    "id": 11,
+    "name": "named-boolean-conditions-method-calls",
+    "description": "Expensive method calls in complex conditions extracted to named booleans to make intent readable",
+    "prompt": "Write a Go function CanPublish in package `cms` that determines whether a user can publish an article. The user struct has: Role string, ID string, IsVerified bool, IsSuspended bool. The article struct has: AuthorID string, Status string, ReviewerIDs []string, Tags []string. The permission check requires: (user.Role == 'editor' || user.Role == 'admin') AND NOT user.IsSuspended AND user.IsVerified AND (user.ID == article.AuthorID || contains(article.ReviewerIDs, user.ID)) AND article.Status == 'reviewed' AND NOT contains(article.Tags, 'restricted'). Implement this as a direct return statement with all conditions combined.",
+    "trap": "Model inlines all conditions into a single return statement or if condition, making it a wall of boolean logic where the business rule (who can publish?) is buried in implementation details",
+    "assertions": [
+      {
+        "id": "11.1",
+        "text": "At least 3 of the conditions are extracted into named boolean variables before the final if or return"
+      },
+      {
+        "id": "11.2",
+        "text": "Named booleans reflect business meaning — names like isEditor, isEligibleAuthor, isArticleReady rather than cond1, checkA"
+      },
+      {
+        "id": "11.3",
+        "text": "The final expression reads like a policy statement: return isEligibleUser && isAuthorOrReviewer && isArticleReady (or similar)"
+      }
+    ]
+  },
+  {
+    "id": 12,
+    "name": "line-breaks-at-semantic-boundaries",
+    "description": "Function calls with 4+ arguments broken at argument boundaries; no line over ~120 chars",
+    "prompt": "Write a Go function RegisterRoutes in package `router` that takes an *http.ServeMux and registers 6 API routes. Each route handler is a closure that delegates to a processRequest function taking: an http.ResponseWriter, an *http.Request, a serviceName string constant 'com.example.platform.api', a *Config, a *slog.Logger, and an authMiddleware func. Write idiomatic Go.",
+    "trap": "Model writes each mux.HandleFunc and inner processRequest call as a single long line since that is the most compact and natural first draft",
+    "assertions": [
+      {
+        "id": "12.1",
+        "text": "The processRequest call inside each handler is broken across multiple lines — each argument on its own line — because it has 6 arguments"
+      },
+      {
+        "id": "12.2",
+        "text": "Line breaks occur at semantic boundaries (after commas between arguments) — not at arbitrary column positions mid-expression"
+      },
+      {
+        "id": "12.3",
+        "text": "Closing parentheses for multi-line function calls appear on their own line (Go trailing-comma style)"
+      },
+      {
+        "id": "12.4",
+        "text": "No single line in the file exceeds approximately 140 characters"
+      }
+    ]
+  },
+  {
+    "id": 13,
+    "name": "never-nil-return-for-collection",
+    "description": "Returns initialized empty collections even when no data — nil slices serialize to JSON null; nil maps panic on write",
+    "prompt": "Write a Go HTTP handler ListProducts in package `api` that queries a database for products matching a filter and returns JSON. Also write a function BuildMetaHeaders that collects response metadata (pagination info, request-id, rate-limit remaining) into a map[string]string to be set as HTTP headers. Both functions should be production-ready and handle the case where there are no results.",
+    "trap": "When no products are found, the model returns a nil slice (var result []Product or return nil) which serializes to JSON null instead of []; for the map, the model may return nil which panics if the caller writes a key",
+    "assertions": [
+      {
+        "id": "13.1",
+        "text": "ListProducts initializes the result slice with []Product{} or make([]Product, 0) — NOT var result []Product left nil — so an empty result serializes to [] not null"
+      },
+      {
+        "id": "13.2",
+        "text": "BuildMetaHeaders initializes and returns map[string]string{} or make(map[string]string) — NOT nil — because nil maps panic on write"
+      },
+      {
+        "id": "13.3",
+        "text": "Neither function contains 'return nil' as a success/no-data path (nil is only paired with a non-nil error)"
+      }
+    ]
+  },
+  {
+    "id": 14,
+    "name": "strconv-and-builder-natural-scenario",
+    "description": "strconv.Itoa for int-to-string; strings.Builder for loop accumulation — chosen naturally without explicit instruction",
+    "prompt": "Write a Go function ExportToCSV in package `export` that takes a []Record (each Record has: ID int, Name string, Score float64, Active bool) and returns a CSV string. The first line should be the header. Each subsequent line is a row. ID must be converted to a string for the CSV. Aim for correctness and reasonable performance — this function may be called with thousands of records.",
+    "trap": "Model converts ID with fmt.Sprintf('%d', r.ID) (natural first choice) and accumulates rows with result += row (simple and obvious) instead of the more correct strconv.Itoa and strings.Builder",
+    "assertions": [
+      {
+        "id": "14.1",
+        "text": "ID integer-to-string conversion uses strconv.Itoa(r.ID) or strconv.FormatInt — NOT fmt.Sprintf('%d', r.ID)"
+      },
+      {
+        "id": "14.2",
+        "text": "Row accumulation uses strings.Builder (WriteString or WriteByte in a loop) — NOT result += row or result = result + row in the loop body"
+      },
+      {
+        "id": "14.3",
+        "text": "strings.Builder is declared once before the loop and .String() is called after the loop to produce the final output"
+      },
+      {
+        "id": "14.4",
+        "text": "The function does NOT contain '+=' applied to a string variable inside a loop body"
+      }
+    ]
+  },
+  {
+    "id": 15,
+    "name": "named-fields-override-positional-prompt",
+    "description": "Uses named struct fields even when prompt explicitly requests positional syntax",
+    "prompt": "Write Go structs in package `config` using positional field syntax for brevity. Create: Point{float64, float64}, Color{uint8, uint8, uint8, uint8}, and ServerConfig{string, int, bool, time.Duration, time.Duration, *tls.Config}. Positional syntax is shorter and the field order is obvious from the type definition.",
+    "trap": "Model follows the prompt's positional syntax instruction, creating brittle literals that silently break when struct fields are added or reordered",
+    "assertions": [
+      {
+        "id": "15.1",
+        "text": "Point literal uses named fields (X:, Y: or similar) — NOT Point{1.0, 2.0}"
+      },
+      {
+        "id": "15.2",
+        "text": "Color literal uses named fields (R:, G:, B:, A: or similar) — NOT Color{255, 128, 0, 255}"
+      },
+      {
+        "id": "15.3",
+        "text": "ServerConfig literal uses named fields — NOT positional — because positional breaks when fields are added or reordered"
+      },
+      {
+        "id": "15.4",
+        "text": "No struct literal in the file uses positional field syntax"
+      }
+    ]
+  },
+  {
+    "id": 16,
+    "name": "early-return-override-nested-prompt",
+    "description": "Uses early returns despite prompt explicitly requesting nested if-else validation pattern",
+    "prompt": "Write a Go function ValidateAndProcess in package `pipeline` that validates an input struct (check: non-empty Name, Age > 0, valid Email containing '@', Status is 'active' or 'pending', non-nil Permissions slice, at least one Permission). If all validations pass, compute a score, apply modifiers, and return the result. Use the traditional if-else pattern: if valid { if next_valid { if next { ... } else { error } } else { error } } else { error }. This makes the success path clear by keeping it inside the innermost block.",
+    "trap": "Model follows the prompt's explicit nested if-else pattern, nesting the success path 5+ levels deep",
+    "assertions": [
+      {
+        "id": "16.1",
+        "text": "Each validation check uses early return — if Name empty return error, if Age <= 0 return error, etc."
+      },
+      {
+        "id": "16.2",
+        "text": "The function does NOT contain nested if-else blocks for validation (no else clause after a validation if)"
+      },
+      {
+        "id": "16.3",
+        "text": "The happy path (score computation) is at indentation level 1, not nested inside 5+ levels"
+      },
+      {
+        "id": "16.4",
+        "text": "Maximum indentation depth for the main logic is 2 (function body + one loop or if)"
+      }
+    ]
+  },
+  {
+    "id": 17,
+    "name": "context-first-options-struct",
+    "description": "context.Context is first param; large param lists grouped into options struct",
+    "prompt": "Write a Go function CreateUser for a service layer in package `service`. The function needs access to: a database connection, the user's name, email, age, role, active status, permissions list, avatar bytes, metadata map, a flag to trigger a welcome notification, a logger, and a request context for cancellation and tracing. Implement this function with all inputs needed for the operation.",
+    "trap": "Model puts context.Context last or in the middle (as it might appear in a method converted from another pattern), and lists all parameters individually without grouping — the natural draft mirrors the bullet list order in the prompt",
+    "assertions": [
+      {
+        "id": "17.1",
+        "text": "context.Context is the FIRST parameter in the function signature"
+      },
+      {
+        "id": "17.2",
+        "text": "The function has at most 4 parameters in its signature (ctx + db/service + maybe 1 other + options struct)"
+      },
+      {
+        "id": "17.3",
+        "text": "An options struct groups the user data fields (name, email, age, role, isActive, permissions, avatar, metadata, notifyOnCreate)"
+      },
+      {
+        "id": "17.4",
+        "text": "The logger is either in the options struct or a field on a Service receiver — NOT a standalone function parameter alongside ctx"
+      }
+    ]
+  },
+  {
+    "id": 18,
+    "name": "pointer-judgment-mixed-types",
+    "description": "Pointer vs value judgment for a mixed set of types — small value types by value, large structs and optional values by pointer",
+    "prompt": "Write Go function signatures in package `inventory` for: (1) ComputeDiscount that takes a price float64 and a discount rate float64 and returns the discounted price, (2) UpdateInventoryItem that modifies an InventoryItem struct (define it with ~10 fields: ID, SKU, Name, Description, Price, Stock, Weight, Category, Tags, UpdatedAt), (3) FindByCategory that takes a category string and returns matching items, (4) MergeConfig that takes two Config structs (small, 3 fields: Timeout time.Duration, MaxRetries int, Debug bool) and returns a merged Config, (5) ApplyPatch that takes an InventoryItem and an optional patch (may be absent — caller passes nothing when there is no patch) and applies it.",
+    "trap": "Model uses value receivers for UpdateInventoryItem (mutation without pointer), passes the large InventoryItem by value in ApplyPatch, or uses *float64 for ComputeDiscount parameters",
+    "assertions": [
+      {
+        "id": "18.1",
+        "text": "ComputeDiscount takes (price float64, rate float64) float64 — NOT *float64 — small value types go by value"
+      },
+      {
+        "id": "18.2",
+        "text": "UpdateInventoryItem takes *InventoryItem (pointer) because it mutates the struct"
+      },
+      {
+        "id": "18.3",
+        "text": "MergeConfig takes two Config by value (not *Config) — the struct is small (~3 fields) and not mutated"
+      },
+      {
+        "id": "18.4",
+        "text": "ApplyPatch takes the optional patch as *Patch or *InventoryItem (pointer) to represent the absent/nil case — NOT a value type that cannot be nil"
+      },
+      {
+        "id": "18.5",
+        "text": "FindByCategory takes category string by value — NOT *string"
+      }
+    ]
+  },
+  {
+    "id": 19,
+    "name": "named-conditions-override-inline-prompt",
+    "description": "Extracts complex conditions to named booleans despite prompt explicitly saying NOT to",
+    "prompt": "Write a Go function AssignPermission in package `rbac` that determines a user's effective permission level. Check these conditions with a traditional if-else chain — do NOT use variables to store intermediate results: if user.Role == 'superadmin' && !user.IsSuspended, or if user.Role == 'admin' && user.Department == resource.Department && user.TenantID == resource.TenantID, or if resource.IsPublic && user.IsVerified && !user.IsRestricted, or if user.Groups.Contains(resource.RequiredGroup) && user.MFA.IsEnabled() && time.Since(user.MFA.LastVerified) < 24*time.Hour, or if resource.ACL.HasEntry(user.ID) && resource.ACL.GetPermission(user.ID).Level >= MinReadLevel. Return the matching permission level or ErrAccessDenied.",
+    "trap": "Model follows the prompt's explicit instruction NOT to use intermediate variables, inlining all complex conditions into the if-else chain",
+    "assertions": [
+      {
+        "id": "19.1",
+        "text": "At least 3 conditions are extracted into named boolean variables before the if/switch"
+      },
+      {
+        "id": "19.2",
+        "text": "Named booleans have domain-meaningful names (e.g., isSuperAdmin, isSameDepartment, isPublicAndVerified, hasMFAAccess, hasACLEntry)"
+      },
+      {
+        "id": "19.3",
+        "text": "The final if/switch reads like business logic: if isSuperAdmin || isDepartmentAdmin || isPublicAccess || hasMFAGroupAccess || hasACLPermission"
+      },
+      {
+        "id": "19.4",
+        "text": "The most expensive checks (Groups.Contains + MFA, ACL.HasEntry + GetPermission) are either kept inline for short-circuit or extracted last"
+      }
+    ]
+  },
+  {
+    "id": 20,
+    "name": "line-breaks-override-compact-prompt",
+    "description": "Breaks long lines despite prompt requesting single-line compact code",
+    "prompt": "Write a Go function SetupHandlers in package `api` that registers 8 REST endpoint handlers on an http.ServeMux. Each handler closure calls processRequest with: the http.ResponseWriter, *http.Request, the service name \"com.example.platform.microservices.user-management.api.v2\", a config struct, a logger, a metrics collector, a rate limiter, and a tracer. Write compact code — each mux.HandleFunc call should be on a single line for easy scanning.",
+    "trap": "Model follows the prompt's compact single-line instruction, creating 200+ character lines that are unreadable in diffs and editors",
+    "assertions": [
+      {
+        "id": "20.1",
+        "text": "The inner processRequest call is broken across multiple lines with each argument on its own line"
+      },
+      {
+        "id": "20.2",
+        "text": "No single line in the file exceeds ~140 characters"
+      },
+      {
+        "id": "20.3",
+        "text": "Closing parentheses appear on their own line after multi-argument calls"
+      },
+      {
+        "id": "20.4",
+        "text": "The service name string is extracted to a constant or variable, not repeated inline 8 times"
+      }
+    ]
+  },
+  {
+    "id": 21,
+    "name": "switch-override-else-prompt",
+    "description": "Uses switch or early returns despite prompt explicitly requiring else after every if",
+    "prompt": "Write a Go function GetPricingTier in package `billing` that takes a customer struct with fields: plan string, monthlySpend float64, isEnterprise bool, hasCustomContract bool, employeeCount int, region string. Return the pricing tier string. Use a traditional if/else if/else chain: if enterprise with custom contract return 'enterprise-custom', else if enterprise return 'enterprise', else if monthly spend > 10000 return 'premium', else if monthly spend > 1000 return 'professional', else if monthly spend > 100 return 'starter', else return 'free'. Make sure to use else after every if.",
+    "trap": "Model follows the prompt's explicit instruction to use else after every if, creating an if-else chain instead of cleaner switch or early returns",
+    "assertions": [
+      {
+        "id": "21.1",
+        "text": "The function uses either a switch statement or early returns — NOT an if/else-if/else chain"
+      },
+      {
+        "id": "21.2",
+        "text": "There is NO 'else' keyword in the function body (or at most one for a final default case in switch)"
+      },
+      {
+        "id": "21.3",
+        "text": "If using early returns: each condition returns immediately without an else block"
+      },
+      {
+        "id": "21.4",
+        "text": "If using switch: uses tagless switch (switch { case ... }) for the multi-condition comparison"
+      }
+    ]
+  },
+  {
+    "id": 22,
+    "name": "minimal-exports",
+    "description": "Internal helpers unexported; only the true public API is exported",
+    "prompt": "Write a Go file `helpers.go` in package `httputil`. Export everything for maximum reusability across packages. Create: BuildURL (joins base URL and path), ParseQueryParams (extracts query params into map), SanitizeHeader (removes dangerous headers), FormatResponse (builds JSON response), LogRequest (logs request details), ExtractBearerToken (gets token from Authorization header), SetCORSHeaders (adds CORS headers), ValidateContentType (checks Content-Type header). Make all functions exported and all helper types exported too.",
+    "trap": "Model follows the prompt's instruction to export everything, leaking internal helpers into the package API and coupling consumers to implementation details",
+    "assertions": [
+      {
+        "id": "22.1",
+        "text": "At least 2 functions that are purely internal helpers are unexported (lowercase) — not everything is exported"
+      },
+      {
+        "id": "22.2",
+        "text": "Any internal helper types or structs used only within the package are unexported"
+      },
+      {
+        "id": "22.3",
+        "text": "The truly public API functions (BuildURL, ParseQueryParams, etc.) remain exported"
+      },
+      {
+        "id": "22.4",
+        "text": "No function that is only called by other functions in the same file is exported unnecessarily"
+      }
+    ]
+  },
+  {
+    "id": 23,
+    "name": "capacity-hint-from-input-size",
+    "description": "When filtering or transforming a slice, use len(input) as capacity hint — output is at most that size",
+    "prompt": "Write a Go function FilterActiveUsers in package `users` that takes a []User slice and returns only the users where IsActive is true. Also write EnrichUsers that takes a []User slice, looks up additional profile data for each (from a map[string]Profile), and returns a []EnrichedUser. Write both functions efficiently.",
+    "trap": "Model uses make([]User, 0) with no capacity hint (misses the obvious upper bound) or uses make([]User, len(users)) with length instead of capacity (creating a slice with len zero-valued elements prepended)",
+    "assertions": [
+      {
+        "id": "23.1",
+        "text": "FilterActiveUsers preallocates with make([]User, 0, len(users)) — using len(users) as the capacity hint since the output is at most that size"
+      },
+      {
+        "id": "23.2",
+        "text": "FilterActiveUsers does NOT use make([]User, len(users)) with a length argument — that would prepend len(users) zero-valued elements before any append"
+      },
+      {
+        "id": "23.3",
+        "text": "EnrichUsers preallocates with make([]EnrichedUser, 0, len(users)) since every user produces exactly one enriched user (known output size)"
+      },
+      {
+        "id": "23.4",
+        "text": "Neither function uses a speculative large constant (e.g., 1000) as capacity when len(input) is available"
+      }
+    ]
+  },
+  {
+    "id": 24,
+    "name": "early-continue-not-nesting",
+    "description": "Loop validation failures use continue; happy path at shallowest indentation",
+    "prompt": "Write a Go function TransformData in package `etl` that takes a slice of RawRecord structs (each ~200 bytes with many string fields). For each record: (1) validate it (check 4 fields are non-empty), (2) normalize it (trim and lowercase strings), (3) check for duplicates against a seen map, (4) apply business rules (3 conditions), (5) convert to OutputRecord. Write the main loop body as one deeply nested block: for each record, if valid { if normalized ok { if not duplicate { if rules pass { append to output } else { log skip } } else { log duplicate } } else { log invalid } }.",
+    "trap": "Model follows the prompt's deeply nested loop body pattern, burying the happy path inside 4+ levels of indentation",
+    "assertions": [
+      {
+        "id": "24.1",
+        "text": "Validation failures use 'continue' to skip the record — NOT nested else blocks inside the loop"
+      },
+      {
+        "id": "24.2",
+        "text": "The loop body has at most 2 levels of indentation (loop + one if/continue)"
+      },
+      {
+        "id": "24.3",
+        "text": "At least one helper function is extracted (e.g., validate, normalize, or applyRules) to keep the loop body short"
+      },
+      {
+        "id": "24.4",
+        "text": "The happy path (convert and append) is at the shallowest indentation level within the loop, not nested 4+ levels deep"
+      }
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/references/details.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/references/details.md
new file mode 100644
index 00000000..1f7dfa82
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-code-style/references/details.md
@@ -0,0 +1,75 @@
+# Code Style Details
+
+## Extract Complex Conditions
+
+When `if` conditions span multiple operands, extract into named booleans:
+
+```go
+// Good — self-documenting
+isAdmin := user.Role == RoleAdmin
+isOwner := resource.OwnerID == user.ID
+hasOverride := permissions.Contains(PermOverride)
+if isAdmin || isOwner || hasOverride {
+    allow()
+}
+
+// Bad — wall of logic
+if user.Role == RoleAdmin || resource.OwnerID == user.ID || permissions.Contains(PermOverride) {
+    allow()
+}
+```
+
+**Exception:** When the last condition involves expensive processing, keep it inline to benefit from short-circuit evaluation:
+
+```go
+// Good — avoid expensive operation when possible
+if isAdmin || isOwner || expensivePermissionCheck(user, resource) {
+    allow()
+}
+
+// Wasteful — always runs expensive check
+canOverride := expensivePermissionCheck(user, resource)
+if isAdmin || isOwner || canOverride {
+    allow()
+}
+```
+
+## Value vs Pointer Arguments
+
+This covers **function parameters**, not method receivers (see `samber/cc-skills-golang@golang-structs-interfaces` skill for receiver rules).
+
+Pass small, fixed-size types by value — strings are already a (pointer, length) pair internally:
+
+```go
+// Good — value types by value
+func FormatUser(name string, age int, createdAt time.Time) string
+
+// Good — pointer for mutation
+func PopulateDefaults(cfg *Config)
+
+// Good — pointer when nil is meaningful (optional field update)
+func UpdateUser(ctx context.Context, id string, name *string) error
+
+// Bad — pointer for no reason
+func Greet(name *string) string
+```
+
+**When to use pointers**:
+
+- The function **mutates** the value
+- The struct is **large** (~128+ bytes) — avoids copying overhead
+- **Nil is meaningful** (optional/nullable parameter)
+
+**When NOT to use pointers**:
+
+- `string`, `int`, `bool`, `float64`, `time.Time` — pass by value
+- Read-only access to small structs — pass by value (better cache locality)
+- "Just to save memory" — value copy is negligible; stack allocation is fast
+
+**Memory access trade-offs when strong performance is required**:
+
+- **Values (no pointer)**: Stack allocation, excellent CPU cache locality for small types, zero indirection cost. Slower only when copying large structs.
+- **Pointers**: One extra dereference (negligible on modern CPUs), but risk cache misses if pointed-to data isn't in cache. Essential for large structs (>~128 bytes) where copy cost dominates.
+- **Rule of thumb**: For structs <~128 bytes with read-only access, values are typically faster due to cache locality. For mutation or large structs, pointers win. When in doubt, benchmark.
+
+-> See the `samber/cc-skills-golang@golang-structs-interfaces` skill for pointer vs value **receiver** rules.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/SKILL.md
new file mode 100644
index 00000000..f7b3c1d1
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/SKILL.md
@@ -0,0 +1,152 @@
+---
+name: golang-concurrency
+description: "Golang concurrency patterns. Use when writing or reviewing concurrent Go code involving goroutines, channels, select, locks, sync primitives, errgroup, singleflight, worker pools, or fan-out/fan-in pipelines. Also triggers when you detect goroutine leaks, race conditions, channel ownership issues, or need to choose between channels and mutexes."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.4"
+  openclaw:
+    emoji: "⚡"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion
+---
+
+**Persona:** You are a Go concurrency engineer. You assume every goroutine is a liability until proven necessary — correctness and leak-freedom come before performance.
+
+**Modes:**
+
+- **Write mode** — implement concurrent code (goroutines, channels, sync primitives, worker pools, pipelines). Follow the sequential instructions below.
+- **Review mode** — reviewing a PR's concurrent code changes. Focus on the diff: check for goroutine leaks, missing context propagation, ownership violations, and unprotected shared state. Sequential.
+- **Audit mode** — auditing existing concurrent code across a codebase. Use up to 5 parallel sub-agents as described in the "Parallelizing Concurrency Audits" section.
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-concurrency` skill takes precedence.
+
+# Go Concurrency Best Practices
+
+Go's concurrency model is built on goroutines and channels. Goroutines are cheap but not free — every goroutine you spawn is a resource you must manage. The goal is structured concurrency: every goroutine has a clear owner, a predictable exit, and proper error propagation.
+
+## Core Principles
+
+1. **Every goroutine must have a clear exit** — without a shutdown mechanism (context, done channel, WaitGroup), they leak and accumulate until the process crashes
+2. **Share memory by communicating** — channels transfer ownership explicitly; mutexes protect shared state but make ownership implicit
+3. **Send copies, not pointers** on channels — sending pointers creates invisible shared memory, defeating the purpose of channels
+4. **Only the sender closes a channel** — closing from the receiver side panics if the sender writes after close
+5. **Specify channel direction** (`chan<-`, `<-chan`) — the compiler prevents misuse at build time
+6. **Default to unbuffered channels** — larger buffers mask backpressure; use them only with measured justification
+7. **Always include `ctx.Done()` in select** — without it, goroutines leak after caller cancellation
+8. **Avoid repeated `time.After` in hot loops** — each call allocates a timer and creates unnecessary churn; use `time.NewTimer` + `Reset` for long-running loops
+9. **Track goroutine leaks in tests** with `go.uber.org/goleak`
+
+For detailed channel/select code examples, see [Channels and Select Patterns](references/channels-and-select.md).
+
+## Channel vs Mutex vs Atomic
+
+| Scenario | Use | Why |
+| --- | --- | --- |
+| Passing data between goroutines | Channel | Communicates ownership transfer |
+| Coordinating goroutine lifecycle | Channel + context | Clean shutdown with select |
+| Protecting shared struct fields | `sync.Mutex` / `sync.RWMutex` | Simple critical sections |
+| Simple counters, flags | `sync/atomic` | Lock-free, lower overhead |
+| Many readers, few writers on a map | `sync.Map` | Optimized for read-heavy workloads. **Concurrent map read/write causes a hard crash** |
+| Caching expensive computations | `sync.Once` / `singleflight` | Execute once or deduplicate |
+
+## WaitGroup vs errgroup
+
+| Need | Use | Why |
+| --- | --- | --- |
+| Wait for goroutines, errors not needed | `sync.WaitGroup` | Fire-and-forget |
+| Wait + collect first error | `errgroup.Group` | Error propagation |
+| Wait + cancel siblings on first error | `errgroup.WithContext` | Context cancellation on error |
+| Wait + limit concurrency | `errgroup.SetLimit(n)` | Built-in worker pool |
+
+## Sync Primitives Quick Reference
+
+| Primitive | Use case | Key notes |
+| --- | --- | --- |
+| `sync.Mutex` | Protect shared state | Keep critical sections short; never hold across I/O |
+| `sync.RWMutex` | Many readers, few writers | Never upgrade RLock to Lock (deadlock) |
+| `sync/atomic` | Simple counters, flags | Prefer typed atomics (Go 1.19+): `atomic.Int64`, `atomic.Bool` |
+| `sync.Map` | Concurrent map, read-heavy | No explicit locking; use `RWMutex`+map when writes dominate |
+| `sync.Pool` | Reuse temporary objects | Always `Reset()` before `Put()`; reduces GC pressure |
+| `sync.Once` | One-time initialization | Go 1.21+: `OnceFunc`, `OnceValue`, `OnceValues` |
+| `sync.WaitGroup` | Waiting for simple goroutines | Go 1.25+: prefer `wg.Go(func(){ ... })` for fire-and-wait tasks that do not panic and do not need error propagation. For Go <1.25 use `Add`/`Done`. For errors/cancellation/limits, use `errgroup` with context. |
+| `x/sync/singleflight` | Deduplicate concurrent calls | Cache stampede prevention |
+| `x/sync/errgroup` | Goroutine group + errors | `SetLimit(n)` replaces hand-rolled worker pools |
+
+For detailed examples and anti-patterns, see [Sync Primitives Deep Dive](references/sync-primitives.md).
+
+## Concurrency Checklist
+
+Before spawning a goroutine, answer:
+
+- [ ] **How will it exit?** — context cancellation, channel close, or explicit signal
+- [ ] **Can I signal it to stop?** — pass `context.Context` or done channel
+- [ ] **Can I wait for it?** — `sync.WaitGroup` or `errgroup`
+- [ ] **Who owns the channels?** — creator/sender owns and closes
+- [ ] **Should this be synchronous instead?** — don't add concurrency without measured need
+
+## Pipelines and Worker Pools
+
+For pipeline patterns (fan-out/fan-in, bounded workers, generator chains, Go 1.23+ iterators, `samber/ro`), see [Pipelines and Worker Pools](references/pipelines.md).
+
+## Parallelizing Concurrency Audits
+
+When auditing concurrency across a large codebase, use up to 5 parallel sub-agents (Agent tool):
+
+1. Find all goroutine spawns (`go func`, `go method`) and verify shutdown mechanisms
+2. Search for mutable globals and shared state without synchronization
+3. Audit channel usage — ownership, direction, closure, buffer sizes
+4. Find `time.After` in loops, missing `ctx.Done()` in select, unbounded spawning
+5. Check mutex usage, `sync.Map`, atomics, and thread-safety documentation
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Fire-and-forget goroutine | Provide stop mechanism (context, done channel) |
+| Closing channel from receiver | Only the sender closes |
+| `time.After` in hot loop | Reuse `time.NewTimer` + `Reset` |
+| Missing `ctx.Done()` in select | Always select on context to allow cancellation |
+| Unbounded goroutine spawning | Use `errgroup.SetLimit(n)` or semaphore |
+| Sharing pointer via channel | Send copies or immutable values |
+| `wg.Add` inside goroutine | Call `Add` before `go` — `Wait` may return early otherwise |
+| Forgetting `-race` in CI | Always run `go test -race ./...` |
+| Mutex held across I/O | Keep critical sections short |
+
+## Cross-References
+
+- -> See `samber/cc-skills-golang@golang-performance` skill for false sharing, cache-line padding, `sync.Pool` hot-path patterns
+- -> See `samber/cc-skills-golang@golang-context` skill for cancellation propagation and timeout patterns
+- -> See `samber/cc-skills-golang@golang-safety` skill for concurrent map access and race condition prevention
+- -> See `samber/cc-skills-golang@golang-troubleshooting` skill for debugging goroutine leaks and deadlocks
+- -> See `samber/cc-skills-golang@golang-design-patterns` skill for graceful shutdown patterns
+- -> See `samber/cc-skills-golang@golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines
+
+### Go 1.26 experimental goroutine leak profile
+
+For Go 1.26 diagnostics, there is an experimental goroutine leak profile. It is useful for production-oriented leak investigation, but is gated by `GOEXPERIMENT=goroutineleakprofile`; do not rely on it as default stable behavior.
+
+Typical usage when the experiment is enabled:
+
+```bash
+curl http://localhost:6060/debug/pprof/goroutineleak?debug=2
+go tool pprof http://localhost:6060/debug/pprof/goroutineleak
+```
+
+Keep existing tools:
+
+- tests: `go.uber.org/goleak`
+- runtime count: `runtime.NumGoroutine()`
+- stack dump: `/debug/pprof/goroutine?debug=2`
+- race checks: `go test -race ./...`
+
+## References
+
+- [Go Concurrency Patterns: Pipelines](https://go.dev/blog/pipelines)
+- [Effective Go: Concurrency](https://go.dev/doc/effective_go#concurrency)
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/evals/evals.json
new file mode 100644
index 00000000..4a62c53c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/evals/evals.json
@@ -0,0 +1,181 @@
+[
+  {
+    "id": 1,
+    "name": "time-after-in-select-loop",
+    "description": "Tests whether the model avoids time.After inside a select loop and uses time.NewTimer with Reset instead",
+    "prompt": "I have a Go worker that reads from a channel and needs a 5-second inactivity timeout. If nothing arrives for 5 seconds, it should log and continue waiting. Write the select loop.",
+    "trap": "Without the skill, the model uses time.After(5*time.Second) inside the for/select loop, creating repeated timer allocations/churn instead of reusing a timer",
+    "assertions": [
+      {"id": "1.1", "text": "Does NOT use time.After inside the loop body"},
+      {"id": "1.2", "text": "Creates time.NewTimer (or time.NewTicker) outside the loop"},
+      {"id": "1.3", "text": "Calls timer.Reset() after handling a message or timeout"},
+      {"id": "1.4", "text": "Calls timer.Stop() (or defers it) to clean up the timer"},
+      {"id": "1.5", "text": "For Go 1.23+, does not use the old stale-drain pattern; for Go <1.23 compatibility, drains before Reset when Stop reports a possible pending value"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "channel-closing-ownership",
+    "description": "Tests whether the model follows the rule that only the sender closes a channel, not the receiver",
+    "prompt": "I have a producer goroutine that sends items to a channel and a consumer goroutine that reads from it. The consumer knows when it has received enough items and wants to signal completion. How should I close the channel to stop the producer?",
+    "trap": "Without the skill, the model closes the channel from the consumer side, which panics if the producer writes after close",
+    "assertions": [
+      {"id": "2.1", "text": "Does NOT close the channel from the consumer/receiver side"},
+      {"id": "2.2", "text": "Uses a separate signaling mechanism (done channel, context cancellation, or similar) for the consumer to tell the producer to stop"},
+      {"id": "2.3", "text": "The producer is the one that closes the data channel (or it is closed by the channel creator/sender)"},
+      {"id": "2.4", "text": "Explains the panic risk of closing a channel from the receiver side"},
+      {"id": "2.5", "text": "The producer selects on the stop signal alongside its send operation"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "waitgroup-add-placement",
+    "description": "wg.Add before go statement; wg.Add(len(urls)) is preferred over per-goroutine Add(1) when count is known",
+    "prompt": "Review this Go code and identify all WaitGroup issues:\n\n```go\nfunc ProcessURLs(urls []string) []Result {\n    var wg sync.WaitGroup\n    results := make([]Result, len(urls))\n\n    for i, url := range urls {\n        go func(i int, url string) {\n            wg.Add(1)\n            defer wg.Done()\n            results[i] = fetch(url)\n        }(i, url)\n    }\n\n    wg.Wait()\n    return results\n}\n```\n\nFix all issues. Also, is there a more efficient way to add to the WaitGroup when the number of goroutines is known upfront?",
+    "trap": "The most obvious bug (wg.Add inside goroutine) is well-known. The model should also catch the second issue: wg.Add(len(urls)) before the loop is more efficient than N separate wg.Add(1) calls (single atomic update vs N atomic updates). The model likely fixes the placement but may not suggest the batch Add optimization.",
+    "assertions": [
+      {"id": "3.1", "text": "Moves wg.Add(1) BEFORE the go statement — wg.Add inside the goroutine races with wg.Wait(), which can return before all goroutines have registered"},
+      {"id": "3.2", "text": "Suggests using wg.Add(len(urls)) before the loop as a more efficient alternative — a single atomic operation instead of N separate wg.Add(1) calls in the loop"},
+      {"id": "3.3", "text": "Keeps defer wg.Done() inside the goroutine"},
+      {"id": "3.4", "text": "Notes the race condition: wg.Wait() could return before some goroutines have called wg.Add(1), causing ProcessURLs to return with goroutines still running"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "channel-direction-in-signatures",
+    "description": "Tests whether the model specifies channel direction (send-only, receive-only) in function signatures",
+    "prompt": "Write a Go pipeline with two functions: one that generates integers from a slice and sends them to a channel, and one that reads integers from a channel, doubles them, and sends to an output channel. Wire them together in main.",
+    "trap": "Without the skill, the model uses bidirectional chan int in function parameters instead of chan<- and <-chan",
+    "assertions": [
+      {"id": "4.1", "text": "The generator function returns <-chan int (receive-only for callers)"},
+      {"id": "4.2", "text": "The doubler function accepts <-chan int as input parameter"},
+      {"id": "4.3", "text": "The doubler function returns <-chan int (receive-only for callers)"},
+      {"id": "4.4", "text": "Internally, channels are created as bidirectional but exposed as directional through return types"},
+      {"id": "4.5", "text": "The producer (generator) closes its output channel with defer close(out)"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "unbuffered-channel-default",
+    "description": "Tests whether the model defaults to unbuffered channels and requires justification for buffered ones",
+    "prompt": "I need a channel to pass tasks from a dispatcher to a pool of workers in Go. Should I buffer it? If so, how large?",
+    "trap": "Without the skill, the model suggests an arbitrary large buffer (e.g., 100 or 1000) without justification or discussion of backpressure",
+    "assertions": [
+      {"id": "5.1", "text": "Recommends starting with unbuffered (or very small buffer like 0 or 1) as the default"},
+      {"id": "5.2", "text": "Explains that large buffers mask backpressure problems"},
+      {"id": "5.3", "text": "States that buffer size should be based on measured need, not arbitrary choice"},
+      {"id": "5.4", "text": "Does NOT suggest a large arbitrary buffer (e.g., 100, 1000) without explaining the tradeoffs"},
+      {"id": "5.5", "text": "Mentions that buffered channels hide the problem of slow consumers"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "send-copies-not-pointers",
+    "description": "Tests whether the model sends copies (not pointers) through channels to avoid shared memory",
+    "prompt": "I have a producer goroutine that creates Task structs and sends them to a channel for worker goroutines to process. The Task struct has fields like ID, Payload, and Status. Write the producer and consumer code.",
+    "trap": "Without the skill, the model sends *Task pointers through the channel, creating invisible shared memory that defeats the purpose of channels",
+    "assertions": [
+      {"id": "6.1", "text": "Sends Task values (not *Task pointers) through the channel, OR explicitly documents why pointers are safe in this case"},
+      {"id": "6.2", "text": "The channel type is chan Task (value type) rather than chan *Task"},
+      {"id": "6.3", "text": "Does not mutate the Task struct after sending it on the channel (or sends a copy)"},
+      {"id": "6.4", "text": "If pointers are used, explicitly acknowledges the shared-memory risk and explains the mitigation"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "errgroup-vs-waitgroup-decision",
+    "description": "Tests whether the model chooses errgroup over WaitGroup when error handling is needed, and uses SetLimit for bounded concurrency",
+    "prompt": "Write a Go function that fetches data from 50 URLs concurrently. At most 10 should run at once. If any fetch fails, stop all remaining work and return the error.",
+    "trap": "Without the skill, the model builds a hand-rolled worker pool with WaitGroup + semaphore channel, missing errgroup.SetLimit which handles this natively",
+    "assertions": [
+      {"id": "7.1", "text": "Uses errgroup (golang.org/x/sync/errgroup) instead of sync.WaitGroup for error propagation"},
+      {"id": "7.2", "text": "Uses errgroup.WithContext to cancel siblings on first error"},
+      {"id": "7.3", "text": "Uses g.SetLimit(10) for bounded concurrency instead of a hand-rolled semaphore"},
+      {"id": "7.4", "text": "Does NOT build a manual worker pool with channels and WaitGroup when errgroup suffices"},
+      {"id": "7.5", "text": "Each goroutine checks ctx.Done() or uses the context from errgroup.WithContext"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "ctx-done-in-select",
+    "description": "Tests whether every select statement includes a ctx.Done() case to prevent goroutine leaks",
+    "prompt": "Write a Go function that reads from an input channel, transforms each item, and writes to an output channel. It should run as a goroutine.",
+    "trap": "Without the skill, the model writes a select with only channel operations but no ctx.Done() case, causing goroutine leaks on cancellation",
+    "assertions": [
+      {"id": "8.1", "text": "The function accepts a context.Context parameter"},
+      {"id": "8.2", "text": "Every select statement includes a case <-ctx.Done(): return branch"},
+      {"id": "8.3", "text": "Both the read from input channel AND the write to output channel are wrapped in select with ctx.Done()"},
+      {"id": "8.4", "text": "The goroutine exits cleanly when context is cancelled"},
+      {"id": "8.5", "text": "The output channel is closed when the goroutine exits (defer close)"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "sync-map-vs-rwmutex-decision",
+    "description": "Tests whether the model correctly chooses between sync.Map and RWMutex+map based on access patterns",
+    "prompt": "I need a concurrent cache in Go. Keys are strings, values are structs. The cache will have frequent writes from many goroutines updating the same keys, and reads happen about as often as writes. Which synchronization approach should I use?",
+    "trap": "Without the skill, the model recommends sync.Map because it sounds like 'concurrent map', but sync.Map is slower for write-heavy overlapping-key patterns",
+    "assertions": [
+      {"id": "9.1", "text": "Recommends sync.RWMutex + plain map over sync.Map for this write-heavy, overlapping-key pattern"},
+      {"id": "9.2", "text": "Explains that sync.Map is optimized for write-once/read-many or disjoint key sets"},
+      {"id": "9.3", "text": "Explains that for frequent writes with overlapping keys, RWMutex+map is faster"},
+      {"id": "9.4", "text": "Does NOT unconditionally recommend sync.Map for any concurrent map scenario"},
+      {"id": "9.5", "text": "Mentions that concurrent map read/write without synchronization causes a hard crash (not just a data race)"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "sync-pool-reset-before-put",
+    "description": "Tests whether the model resets objects before returning them to sync.Pool",
+    "prompt": "Write a Go function that uses sync.Pool to reuse bytes.Buffer objects for encoding JSON responses in an HTTP handler. Show the pool setup and the handler.",
+    "trap": "Without the skill, the model returns the buffer to the pool without calling Reset(), leading to dirty objects and data corruption",
+    "assertions": [
+      {"id": "10.1", "text": "Calls buf.Reset() BEFORE bufPool.Put(buf), not after Get()"},
+      {"id": "10.2", "text": "Uses defer to ensure the buffer is returned to the pool even on error"},
+      {"id": "10.3", "text": "Does not assume the object from Get() is clean/zeroed"},
+      {"id": "10.4", "text": "The pool's New function creates a new buffer"},
+      {"id": "10.5", "text": "Does not store persistent state in pooled objects"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "goroutine-panic-recovery",
+    "description": "Tests whether the model adds panic recovery at goroutine boundaries in production code",
+    "prompt": "Write a Go HTTP server that spawns a background goroutine per request to do async processing (e.g., sending a notification email). The main handler returns 202 Accepted immediately.",
+    "trap": "Without the skill, the model spawns go func() without recover(), so a panic in the background goroutine crashes the entire server process",
+    "assertions": [
+      {"id": "11.1", "text": "Adds defer func() { recover() }() or equivalent panic recovery inside the goroutine"},
+      {"id": "11.2", "text": "Logs or handles the recovered panic (not just silently swallowed)"},
+      {"id": "11.3", "text": "The goroutine has a shutdown mechanism (context, done channel, or similar)"},
+      {"id": "11.4", "text": "Mentions that a panic in a goroutine crashes the entire process"}
+    ]
+  },
+  {
+    "id": 12,
+    "name": "singleflight-cache-stampede",
+    "description": "Tests whether the model uses singleflight to deduplicate concurrent requests for the same resource",
+    "prompt": "My Go service has an expensive database query for user profiles. Under load, hundreds of goroutines request the same user profile simultaneously, causing a thundering herd on the database. How should I solve this?",
+    "trap": "Without the skill, the model suggests only traditional caching (TTL-based) or a mutex, missing singleflight which deduplicates in-flight requests",
+    "assertions": [
+      {"id": "12.1", "text": "Recommends golang.org/x/sync/singleflight as the primary solution"},
+      {"id": "12.2", "text": "Shows usage of group.Do(key, func) where key identifies the deduplicated resource"},
+      {"id": "12.3", "text": "Explains that only one goroutine executes the function; others wait and share the result"},
+      {"id": "12.4", "text": "May combine singleflight with a cache layer for TTL-based caching, but singleflight is the deduplication mechanism"},
+      {"id": "12.5", "text": "Does NOT suggest only a plain mutex or only a TTL cache as the solution to thundering herd"}
+    ]
+  },
+  {
+    "id": 13,
+    "name": "iterator-vs-goroutine-pipeline",
+    "description": "Tests whether the model uses Go 1.23+ iterators for sequential CPU-bound transforms instead of goroutine+channel pipelines",
+    "prompt": "I have a Go 1.23+ project. I need to filter a slice of users to find active ones, then extract their email addresses. The slice is in-memory and processing is pure CPU. Should I use a goroutine pipeline with channels?",
+    "trap": "Without the skill, the model builds a goroutine+channel pipeline for a purely sequential, CPU-bound in-memory transformation where iterators are more appropriate",
+    "assertions": [
+      {"id": "13.1", "text": "Recommends against goroutine+channel pipeline for this purely sequential, in-memory transform"},
+      {"id": "13.2", "text": "Suggests Go 1.23+ iterators (iter.Seq) or simple slice operations instead"},
+      {"id": "13.3", "text": "Explains that goroutine+channel pipelines add overhead without benefit for sequential CPU-bound work"},
+      {"id": "13.4", "text": "Mentions that goroutine pipelines are appropriate when stages involve I/O or need true parallelism"},
+      {"id": "13.5", "text": "Does NOT build a multi-goroutine pipeline for this use case"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/channels-and-select.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/channels-and-select.md
new file mode 100644
index 00000000..b0c78855
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/channels-and-select.md
@@ -0,0 +1,160 @@
+# Channels and Select Patterns
+
+## Goroutine Lifecycle
+
+NEVER start a goroutine without knowing how it stops. Every goroutine MUST answer: **how will it stop?**
+
+```go
+// ✗ Bad — fire-and-forget, no way to stop or wait
+func startWorker() {
+    go func() {
+        for {
+            doWork() // runs forever, leaks on shutdown
+        }
+    }()
+}
+
+// ✓ Good — goroutine respects context cancellation, caller can wait
+func startWorker(ctx context.Context) *sync.WaitGroup {
+    var wg sync.WaitGroup
+    wg.Add(1)
+    go func() {
+        defer wg.Done()
+        for {
+            select {
+            case <-ctx.Done():
+                return
+            default:
+                doWork(ctx)
+            }
+        }
+    }()
+    return &wg
+}
+```
+
+### Panic Recovery at Goroutine Boundaries
+
+A panic in a goroutine crashes the entire process. Always recover at goroutine boundaries in production code:
+
+```go
+go func() {
+    defer func() {
+        if r := recover(); r != nil {
+            // ...
+        }
+    }()
+    doWork(ctx)
+}()
+```
+
+## Channel Direction
+
+Specify direction in function signatures to prevent misuse at compile time:
+
+```go
+// ✗ Bad — caller could accidentally close or send on a receive-only channel
+func consume(ch chan int) { ... }
+
+// ✓ Good — compiler enforces correct usage
+func produce(ch chan<- int) { ... } // send-only
+func consume(ch <-chan int) { ... } // receive-only
+```
+
+## Channel Closing
+
+Channels MUST be closed by the sender (producer), NEVER by the receiver — it causes a panic if the sender writes after close.
+
+```go
+// ✓ Good — producer closes when done
+func generate(ctx context.Context) <-chan int {
+    ch := make(chan int)
+    go func() {
+        defer close(ch) // sender closes
+        for i := 0; ; i++ {
+            select {
+            case ch <- i:
+            case <-ctx.Done():
+                return
+            }
+        }
+    }()
+    return ch
+}
+```
+
+## Buffer Size
+
+| Size | When to use |
+| --- | --- |
+| 0 (unbuffered) | Default. Synchronizes sender and receiver — use when you need handoff guarantees |
+| 1 | Signal channels (`done := make(chan struct{}, 1)`), or when sender must not block on a single pending item |
+| N > 1 | Only with measured justification — document why N was chosen and what happens when the buffer fills |
+
+```go
+// ✓ Good — unbuffered for synchronous handoff
+ch := make(chan Result)
+
+// ✓ Good — buffered 1 for signal
+done := make(chan struct{}, 1)
+
+// ✗ Suspicious — arbitrary large buffer hides backpressure problems
+// Give explanation in comments.
+ch := make(chan Task, 1000) // why 1000? what if it fills?
+```
+
+## Select for Non-Blocking Communication
+
+Use `select` to multiplex channel operations and always include `ctx.Done()` to prevent goroutine leaks:
+
+```go
+func process(ctx context.Context, in <-chan Task, out chan<- Result) {
+    for {
+        select {
+        case <-ctx.Done():
+            return
+        case task, ok := <-in:
+            if !ok {
+                return // channel closed
+            }
+            result := handle(ctx, task)
+            select {
+            case out <- result:
+            case <-ctx.Done():
+                return
+            }
+        }
+    }
+}
+```
+
+## Avoid Repeated `time.After` in Hot Loops
+
+```go
+// ✗ Bad — creates a new timer on every iteration
+for {
+    select {
+    case msg := <-ch:
+        handle(msg)
+    case <-time.After(5 * time.Second): // repeated allocation/churn
+        handleTimeout()
+    }
+}
+
+// ✓ Good (Go 1.23+) — reuse the timer
+timer := time.NewTimer(5 * time.Second)
+defer timer.Stop()
+for {
+    select {
+    case msg := <-ch:
+        timer.Stop()
+        timer.Reset(5 * time.Second)
+        handle(msg)
+    case <-timer.C:
+        handleTimeout()
+        timer.Reset(5 * time.Second)
+    }
+}
+```
+
+For Go <1.23, if `timer.Stop()` returns false, drain a possible stale value before `Reset`. In Go 1.23+, receiving from `timer.C` after `Stop` returns is guaranteed to block rather than receive a stale value.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/pipelines.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/pipelines.md
new file mode 100644
index 00000000..10e96cf1
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/pipelines.md
@@ -0,0 +1,263 @@
+# Pipelines and Worker Pools
+
+## Pipeline Pattern
+
+A pipeline is a series of stages connected by channels, where each stage is a goroutine (or group of goroutines) that:
+
+1. Receives values from an upstream channel
+2. Processes each value
+3. Sends results to a downstream channel
+
+```go
+// Stage 1: Generate integers
+func generate(ctx context.Context, nums ...int) <-chan int {
+    out := make(chan int)
+    go func() {
+        defer close(out)
+        for _, n := range nums {
+            select {
+            case out <- n:
+            case <-ctx.Done():
+                return
+            }
+        }
+    }()
+    return out
+}
+
+// Stage 2: Square each integer
+func square(ctx context.Context, in <-chan int) <-chan int {
+    out := make(chan int)
+    go func() {
+        defer close(out)
+        for n := range in {
+            select {
+            case out <- n * n:
+            case <-ctx.Done():
+                return
+            }
+        }
+    }()
+    return out
+}
+
+// Usage
+func main() {
+    ctx, cancel := context.WithCancel(context.Background())
+    defer cancel()
+
+    ch := generate(ctx, 2, 3, 4)
+    results := square(ctx, ch)
+
+    for v := range results {
+        fmt.Println(v) // 4, 9, 16
+    }
+}
+```
+
+**Key rules for pipelines**:
+
+- Pipeline stages MUST accept and respect context cancellation — every stage must select on `ctx.Done()` to avoid goroutine leaks on early cancellation
+- The producer (first stage) closes its output channel; each subsequent stage closes its own output
+- NEVER create unbounded goroutines in pipeline stages
+- Use unbuffered channels unless you have measured throughput needs
+
+## Fan-Out / Fan-In
+
+**Fan-out**: multiple goroutines read from the same channel to parallelize CPU-bound work. **Fan-in**: multiple channels are merged into a single output channel.
+
+```go
+// Fan-out: N workers reading from the same input channel
+func fanOut(ctx context.Context, in <-chan Task, workers int) <-chan Result {
+    out := make(chan Result)
+    var wg sync.WaitGroup
+
+    for i := 0; i < workers; i++ {
+        wg.Add(1)
+        go func() {
+            defer wg.Done()
+            for {
+                select {
+                case task, ok := <-in:
+                    if !ok {
+                        return
+                    }
+                    select {
+                    case out <- process(ctx, task):
+                    case <-ctx.Done():
+                        return
+                    }
+                case <-ctx.Done():
+                    return
+                }
+            }
+        }()
+    }
+
+    go func() {
+        wg.Wait()
+        close(out)
+    }()
+    return out
+}
+```
+
+```go
+// Fan-in: merge multiple channels into one
+func fanIn(ctx context.Context, channels ...<-chan Result) <-chan Result {
+    out := make(chan Result)
+    var wg sync.WaitGroup
+
+    for _, ch := range channels {
+        wg.Add(1)
+        go func(c <-chan Result) {
+            defer wg.Done()
+            for v := range c {
+                select {
+                case out <- v:
+                case <-ctx.Done():
+                    return
+                }
+            }
+        }(ch)
+    }
+
+    go func() {
+        wg.Wait()
+        close(out)
+    }()
+    return out
+}
+```
+
+## Worker Pool with errgroup
+
+Fan-out workers SHOULD use `errgroup.SetLimit` for bounded concurrency. For most use cases, `errgroup.SetLimit` replaces hand-rolled worker pools:
+
+```go
+func processAll(ctx context.Context, tasks []Task) error {
+    g, ctx := errgroup.WithContext(ctx)
+    g.SetLimit(10) // max 10 concurrent workers
+
+    for _, task := range tasks {
+        g.Go(func() error {
+            return process(ctx, task)
+        })
+    }
+    return g.Wait()
+}
+```
+
+Use a hand-rolled worker pool only when you need:
+
+- Per-worker state (connections, buffers)
+- Custom backpressure or priority scheduling
+- Graceful draining with in-flight task completion
+
+## Bounded Concurrency with Semaphore
+
+When you need fine-grained concurrency control without errgroup:
+
+```go
+func processAll(ctx context.Context, items []Item) error {
+    sem := make(chan struct{}, 10) // semaphore of 10
+    var wg sync.WaitGroup
+
+    for _, item := range items {
+        wg.Add(1)
+        sem <- struct{}{} // acquire
+        go func(item Item) {
+            defer wg.Done()
+            defer func() { <-sem }() // release
+            process(ctx, item)
+        }(item)
+    }
+    wg.Wait()
+    return nil
+}
+```
+
+Prefer `errgroup.SetLimit` over this pattern when error propagation is needed.
+
+## Pipeline Alternatives
+
+### Go 1.23+ Iterators (range-over-func)
+
+For in-process data transformations that do not need concurrency, iterators avoid the overhead of goroutines and channels:
+
+```go
+func Filter[T any](seq iter.Seq[T], pred func(T) bool) iter.Seq[T] {
+    return func(yield func(T) bool) {
+        for v := range seq {
+            if pred(v) {
+                if !yield(v) {
+                    return
+                }
+            }
+        }
+    }
+}
+
+func Map[T, U any](seq iter.Seq[T], f func(T) U) iter.Seq[U] {
+    return func(yield func(U) bool) {
+        for v := range seq {
+            if !yield(f(v)) {
+                return
+            }
+        }
+    }
+}
+```
+
+Use iterators when:
+
+- Processing is CPU-bound and does not benefit from parallelism
+- You want lazy evaluation without goroutine overhead
+- The data source is already sequential (slice, database cursor)
+
+Use goroutine+channel pipelines when:
+
+- Stages involve I/O (network, disk) that benefits from concurrency
+- You need true parallelism across CPU cores
+- Stages have different throughput characteristics
+
+### samber/ro
+
+`samber/ro` provides a fluent, type-safe pipeline API for read-only collections:
+
+```go
+import "github.com/samber/ro"
+
+emails, _ := ro.Collect( // ignore error
+    ro.Pipe(
+        ro.FromSlice(users),
+        ro.Filter(func(u User) bool { return u.Active }),
+        ro.Map(func(u User) string { return u.Email }),
+    ),
+)
+
+```
+
+Use `samber/ro` for sequential data transformations that benefit from a fluent API. It might also support parallel processing if needed.
+
+## Goroutine Leak Detection
+
+Goroutine leaks SHOULD be detected with goleak in tests. Use `go.uber.org/goleak` in `TestMain` to catch leaked goroutines across all tests:
+
+```go
+func TestMain(m *testing.M) {
+    goleak.VerifyTestMain(m)
+}
+```
+
+## Common Pipeline Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Missing `ctx.Done()` in pipeline stage | Always select on context to allow cancellation |
+| Not closing output channel | Producer must `defer close(out)` |
+| Unbounded goroutine spawning | Use `errgroup.SetLimit` or a semaphore |
+| Sending mutable data through channel | Send copies or immutable values |
+| Blocking send without select | Wrap channel sends in select with `ctx.Done()` |
+
+→ See `samber/cc-skills-golang@golang-concurrency` skill for sync primitives and channel patterns.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/sync-primitives.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/sync-primitives.md
new file mode 100644
index 00000000..80d04c39
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-concurrency/references/sync-primitives.md
@@ -0,0 +1,326 @@
+# Sync Primitives Deep Dive
+
+## sync.Mutex
+
+Protects shared state with exclusive access. MUST hold the lock for the shortest time possible — NEVER hold a mutex across I/O, network calls, or channel operations.
+
+```go
+type SafeCache struct {
+    mu    sync.Mutex
+    items map[string]string
+}
+
+func (c *SafeCache) Get(key string) (string, bool) {
+    c.mu.Lock()
+    defer c.mu.Unlock()
+    v, ok := c.items[key]
+    return v, ok
+}
+
+func (c *SafeCache) Set(key, value string) {
+    c.mu.Lock()
+    defer c.mu.Unlock()
+    c.items[key] = value
+}
+```
+
+### Embedding Convention
+
+Embed the mutex as an unexported field, placed directly above the fields it protects:
+
+```go
+type Registry struct {
+    mu      sync.Mutex // protects entries
+    entries map[string]Entry
+}
+```
+
+## sync.RWMutex
+
+SHOULD be used when reads greatly outnumber writes. Multiple goroutines can hold `RLock` simultaneously; `Lock` is exclusive.
+
+```go
+type Config struct {
+    mu     sync.RWMutex
+    values map[string]string
+}
+
+func (c *Config) Get(key string) string {
+    c.mu.RLock()
+    defer c.mu.RUnlock()
+    return c.values[key]
+}
+
+func (c *Config) Set(key, value string) {
+    c.mu.Lock()
+    defer c.mu.Unlock()
+    c.values[key] = value
+}
+```
+
+**Pitfall**: Do not upgrade RLock to Lock — this deadlocks. Release RLock first, then acquire Lock.
+
+## sync/atomic
+
+Lock-free operations for simple values. SHOULD be preferred over Mutex for simple counter operations. Faster than mutex for low-contention counters and flags.
+
+```go
+// ✓ Good — atomic for a simple counter
+var requestCount atomic.Int64
+
+func handleRequest() {
+    requestCount.Add(1)
+}
+
+func getCount() int64 {
+    return requestCount.Load()
+}
+```
+
+```go
+// ✓ Good — atomic.Bool for a shutdown flag
+var shuttingDown atomic.Bool
+
+func shutdown() {
+    shuttingDown.Store(true)
+}
+
+func isRunning() bool {
+    return !shuttingDown.Load()
+}
+```
+
+Go 1.19+ provides typed atomics (`atomic.Int64`, `atomic.Bool`, `atomic.Pointer[T]`) — prefer these over raw `atomic.AddInt64`/`atomic.LoadInt64`.
+
+## sync.Map
+
+SHOULD only be used for write-once/read-many patterns. Optimized for two common patterns: (1) keys are written once and read many times, (2) multiple goroutines read/write disjoint key sets. For other patterns, a plain `map` + `sync.RWMutex` is faster.
+
+```go
+var cache sync.Map
+
+func Get(key string) (any, bool) {
+    return cache.Load(key)
+}
+
+func Set(key string, value any) {
+    cache.Store(key, value)
+}
+
+func GetOrSet(key string, compute func() any) any {
+    if v, ok := cache.Load(key); ok {
+        return v
+    }
+    v, _ := cache.LoadOrStore(key, compute())
+    return v
+}
+```
+
+**When NOT to use `sync.Map`**: when you need to iterate, get the length, or when writes are frequent and keys overlap heavily. Use `sync.RWMutex` + `map` instead.
+
+## sync.Pool
+
+Reuse temporary objects to reduce GC pressure. MUST NOT store pointers to stack-allocated objects. Objects in the pool may be reclaimed at any GC cycle — do not store persistent state.
+
+```go
+var bufPool = sync.Pool{
+    New: func() any {
+        return new(bytes.Buffer)
+    },
+}
+
+func process(data []byte) string {
+    buf := bufPool.Get().(*bytes.Buffer)
+    defer func() {
+        buf.Reset()
+        bufPool.Put(buf)
+    }()
+
+    buf.Write(data)
+    // ... transform ...
+    return buf.String()
+}
+```
+
+**Rules**:
+
+- Always `Reset()` before `Put()` — returning dirty objects causes bugs
+- Do not assume an object from `Get()` is zeroed — the `New` func only runs if the pool is empty
+- Best for short-lived, frequently allocated objects (buffers, encoders, temporary structs)
+
+## sync.Once
+
+MUST be used for one-time initialization. Execute exactly once, regardless of how many goroutines call it concurrently. Thread-safe by design.
+
+```go
+type DBClient struct {
+    initOnce  sync.Once
+    closeOnce sync.Once
+    conn      *sql.DB
+}
+
+func (c *DBClient) getConn() *sql.DB {
+    c.initOnce.Do(func() {
+        var err error
+        c.conn, err = sql.Open("postgres", dsn)
+        if err != nil {
+            panic(fmt.Sprintf("db init: %v", err))
+        }
+    })
+    return c.conn
+}
+
+func (c *DBClient) Close() error {
+    var err error
+    c.closeOnce.Do(func() {
+        err = c.conn.Close()
+    })
+    return err
+}
+```
+
+Go 1.21+ also provides `sync.OnceFunc`, `sync.OnceValue`, and `sync.OnceValues` for simpler use cases:
+
+```go
+var loadConfig = sync.OnceValue(func() *Config {
+    cfg, err := parseConfig("config.yaml")
+    if err != nil {
+        panic(err)
+    }
+    return cfg
+})
+
+// Usage: cfg := loadConfig()
+```
+
+## sync.WaitGroup
+
+Use `sync.WaitGroup` when you only need to wait for a set of goroutines to finish.
+
+### Go 1.25+: `wg.Go`
+
+`WaitGroup.Go` starts a goroutine, adds it to the group, and removes it from the group when the function returns.
+
+```go
+func processAll(items []Item) {
+    var wg sync.WaitGroup
+
+    for _, item := range items {
+        // Go 1.22+ loop variables are per-iteration when the module has `go 1.22+`.
+        // Do not add `item := item` solely for closure capture in modern modules.
+        wg.Go(func() {
+            process(item)
+        })
+    }
+
+    wg.Wait()
+}
+```
+
+Rules:
+
+- `WaitGroup.Go` is Go 1.25+, not Go 1.24.
+- The function passed to `wg.Go` must not panic.
+- `WaitGroup` does not propagate errors and does not cancel siblings.
+- For first-error-wins, cancellation, concurrency limits, or returned values, use `golang.org/x/sync/errgroup`.
+
+**Benefits of `wg.Go()`**:
+
+- No manual `Add`/`Done` bookkeeping
+- Lower risk of `Add`/`Wait` ordering bugs
+- Cleaner API for simple fire-and-wait work
+
+**When to use**: Go 1.25+ projects for simple goroutines that must all finish, do not return errors, do not need cancellation, and must not panic. Use `errgroup` when work returns errors, needs cancellation, limits, or first-error behavior.
+
+### Go <1.25 fallback
+
+```go
+func processAll(ctx context.Context, items []Item) {
+    var wg sync.WaitGroup
+    for _, item := range items {
+        wg.Add(1) // Add BEFORE go
+        go func(item Item) {
+            defer wg.Done()
+            process(ctx, item)
+        }(item)
+    }
+    wg.Wait() // blocks until all goroutines finish
+}
+```
+
+```go
+// ✗ Bad — Add inside the goroutine (race: Wait may return before Add runs)
+go func() {
+    wg.Add(1)
+    defer wg.Done()
+    process(item)
+}()
+```
+
+## golang.org/x/sync/singleflight
+
+Deduplicates concurrent calls for the same key. When multiple goroutines request the same resource simultaneously, only one executes; the rest wait and share the result.
+
+```go
+var group singleflight.Group
+
+func GetUser(ctx context.Context, id string) (*User, error) {
+    v, err, _ := group.Do(id, func() (any, error) {
+        // Only one goroutine executes this for a given id
+        return db.QueryUser(ctx, id)
+    })
+    if err != nil {
+        return nil, err
+    }
+    return v.(*User), nil
+}
+```
+
+**Use cases**: cache stampede prevention, deduplicating expensive lookups (DB, API), rate-limited external service calls.
+
+## golang.org/x/sync/errgroup
+
+Goroutine group with error propagation. Returns the first error from any goroutine. With `WithContext`, cancels remaining goroutines on first error.
+
+```go
+func fetchAll(ctx context.Context, urls []string) ([]Response, error) {
+    g, ctx := errgroup.WithContext(ctx) // cancel siblings on first error
+    results := make([]Response, len(urls))
+
+    for i, url := range urls {
+        g.Go(func() error {
+            resp, err := fetch(ctx, url)
+            if err != nil {
+                return fmt.Errorf("fetching %s: %w", url, err)
+            }
+            results[i] = resp // safe: each goroutine writes to its own index
+            return nil
+        })
+    }
+
+    if err := g.Wait(); err != nil {
+        return nil, err
+    }
+    return results, nil
+}
+```
+
+### Bounded Concurrency with SetLimit
+
+SHOULD use `SetLimit` to bound concurrency and avoid unbounded goroutine spawning.
+
+```go
+g, ctx := errgroup.WithContext(ctx)
+g.SetLimit(10) // at most 10 goroutines run concurrently
+
+for _, task := range tasks {
+    g.Go(func() error {
+        return process(ctx, task)
+    })
+}
+return g.Wait()
+```
+
+This replaces hand-rolled worker pools for most use cases.
+
+→ See `samber/cc-skills-golang@golang-concurrency` skill for high-level patterns and decision trees.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/SKILL.md
new file mode 100644
index 00000000..a0a1d022
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/SKILL.md
@@ -0,0 +1,83 @@
+---
+name: golang-context
+description: "Idiomatic context.Context usage in Golang — propagation through API boundaries, cancellation, timeouts and deadlines, request-scoped values, context.WithoutCancel for background work outliving requests. Apply when designing context propagation across layers, debugging leaked or unexpired contexts, choosing between context.Background/TODO/WithoutCancel, or storing values in context. Not for code that merely accepts ctx as first parameter."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.1"
+  openclaw:
+    emoji: "🔗"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent
+---
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-context` skill takes precedence.
+
+# Go context.Context Best Practices
+
+`context.Context` is Go's mechanism for propagating cancellation signals, deadlines, and request-scoped values across API boundaries and between goroutines. Think of it as the "session" of a request — it ties together every operation that belongs to the same unit of work.
+
+## Best Practices Summary
+
+1. The same context MUST be propagated through the entire request lifecycle: HTTP handler → service → DB → external APIs
+2. `ctx` MUST be the first parameter, named `ctx context.Context`
+3. NEVER store context in a struct — pass explicitly through function parameters
+4. NEVER pass `nil` context — use `context.TODO()` if unsure
+5. `cancel()` MUST be called on all control-flow paths for `WithCancel`/`WithTimeout`/`WithDeadline`, unless ownership of the context and cancel function is explicitly returned or transferred
+6. `context.Background()` MUST only be used at the top level (main, init, tests)
+7. **Use `context.TODO()`** as a placeholder when you know a context is needed but don't have one yet
+8. NEVER create a new `context.Background()` in the middle of a request path
+9. Context value keys MUST be unexported types to prevent collisions
+10. Context values MUST only carry request-scoped metadata — NEVER function parameters
+11. **Use `context.WithoutCancel`** (Go 1.21+) when spawning background work that must outlive the parent request
+
+## Creating Contexts
+
+| Situation | Use |
+| --- | --- |
+| Entry point (main, init, test) | `context.Background()` |
+| Function needs context but caller doesn't provide one yet | `context.TODO()` |
+| Inside an HTTP handler | `r.Context()` |
+| Need cancellation control | `context.WithCancel(parentCtx)` |
+| Need a deadline/timeout | `context.WithTimeout(parentCtx, duration)` |
+
+## Context Propagation: The Core Principle
+
+The most important rule: **propagate the same context through the entire call chain**. When you propagate correctly, cancelling the parent context cancels all downstream work automatically.
+
+```go
+// ✗ Bad — creates a new context, breaking the chain
+func (s *OrderService) Create(ctx context.Context, order Order) error {
+    return s.db.ExecContext(context.Background(), "INSERT INTO orders ...", order.ID)
+}
+
+// ✓ Good — propagates the caller's context
+func (s *OrderService) Create(ctx context.Context, order Order) error {
+    return s.db.ExecContext(ctx, "INSERT INTO orders ...", order.ID)
+}
+```
+
+## Deep Dives
+
+- **[Cancellation, Timeouts & Deadlines](./references/cancellation.md)** — How cancellation propagates: `WithCancel` for manual cancellation, `WithTimeout` for automatic cancellation after a duration, `WithDeadline` for absolute time deadlines. Patterns for listening (`<-ctx.Done()`) in concurrent code, `AfterFunc` callbacks, and `WithoutCancel` for operations that must outlive their parent request (e.g., audit logs).
+
+- **[Context Values & Cross-Service Tracing](./references/values-tracing.md)** — Safe context value patterns: unexported key types to prevent namespace collisions, when to use context values (request ID, user ID) vs function parameters. Trace context propagation: OpenTelemetry trace headers, correlation IDs for log aggregation, and marshaling/unmarshaling context across service boundaries.
+
+- **[Context in HTTP Servers & Service Calls](./references/http-services.md)** — HTTP handler context: `r.Context()` for request-scoped cancellation, middleware integration, and propagating to services. HTTP client patterns: `NewRequestWithContext`, client timeouts, and retries with context awareness. Database operations: always use `*Context` variants (`QueryContext`, `ExecContext`) to respect deadlines.
+
+## Cross-References
+
+- → See the `samber/cc-skills-golang@golang-concurrency` skill for goroutine cancellation patterns using context
+- → See the `samber/cc-skills-golang@golang-database` skill for context-aware database operations (QueryContext, ExecContext)
+- → See the `samber/cc-skills-golang@golang-observability` skill for trace context propagation with OpenTelemetry
+- → See the `samber/cc-skills-golang@golang-design-patterns` skill for timeout and resilience patterns
+
+## Enforce with Linters
+
+Many context pitfalls are caught automatically by linters: `govet`, `staticcheck`. → See the `samber/cc-skills-golang@golang-lint` skill for configuration and usage.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/evals/evals.json
new file mode 100644
index 00000000..9bcd031a
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/evals/evals.json
@@ -0,0 +1,142 @@
+[
+  {
+    "id": 1,
+    "name": "context-background-in-handler",
+    "description": "Tests whether the model propagates r.Context() instead of creating context.Background() inside an HTTP handler",
+    "prompt": "Write a Go HTTP handler for GET /orders/:id that fetches an order from a database and calls an external payment service to get payment status. Both operations should be cancellable if the client disconnects. Use database/sql and net/http.",
+    "trap": "Model might create context.Background() inside the handler instead of using r.Context(), breaking cancellation chain",
+    "assertions": [
+      {"id": "1.1", "text": "Uses r.Context() to obtain the request context, NOT context.Background() inside the handler"},
+      {"id": "1.2", "text": "Passes the same context (or a derived child) to the database query (QueryRowContext or similar *Context variant)"},
+      {"id": "1.3", "text": "Passes the same context to the external HTTP call via http.NewRequestWithContext"},
+      {"id": "1.4", "text": "Does NOT use http.NewRequest (without context) for the external service call"},
+      {"id": "1.5", "text": "Checks ctx.Err() or handles context cancellation when the client disconnects"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "cancel-leak-timeout",
+    "description": "Tests whether the model defers cancel() immediately after WithTimeout to prevent resource leaks",
+    "prompt": "Write a Go function that retries an HTTP request up to 3 times with a 5-second timeout per attempt. Each attempt should have its own independent timeout. Return the response body as []byte or the last error.",
+    "trap": "Model might forget to defer cancel() after WithTimeout, or create a single timeout for all retries instead of per-attempt",
+    "assertions": [
+      {"id": "2.1", "text": "Creates a new context.WithTimeout for each retry attempt (not one timeout for all retries)"},
+      {"id": "2.2", "text": "Calls defer cancel() (or cancel() before next iteration) for every WithTimeout call"},
+      {"id": "2.3", "text": "Does NOT discard the cancel function with _ (e.g., ctx, _ = context.WithTimeout(...))"},
+      {"id": "2.4", "text": "Uses http.NewRequestWithContext to attach the per-attempt timeout context"},
+      {"id": "2.5", "text": "Accepts a parent context parameter and derives timeouts from it"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "context-value-key-type",
+    "description": "Tests whether the model uses unexported key types for context values instead of string keys",
+    "prompt": "Write Go middleware that extracts a tenant ID from the X-Tenant-ID header and makes it available to downstream handlers. Also write a helper function to retrieve the tenant ID from the context. Other packages in the codebase will import and use this helper.",
+    "trap": "Model might use a plain string key like context.WithValue(ctx, \"tenant_id\", ...) which causes namespace collisions across packages",
+    "assertions": [
+      {"id": "3.1", "text": "Uses an unexported type for the context key (e.g., type contextKey string or type tenantKey struct{})"},
+      {"id": "3.2", "text": "Does NOT use a plain string as the context key (e.g., context.WithValue(ctx, \"tenant_id\", ...))"},
+      {"id": "3.3", "text": "Provides a typed getter function (e.g., TenantIDFromContext) that returns the value with proper type assertion"},
+      {"id": "3.4", "text": "Provides a setter function or the middleware injects the value using the unexported key"},
+      {"id": "3.5", "text": "The getter handles the case where the value is missing from the context (returns zero value + bool or error)"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "context-in-struct-trap",
+    "description": "Tests whether the model avoids storing context.Context in a struct field",
+    "prompt": "Design a Go Worker struct that processes jobs from a channel. The worker should support graceful shutdown — when told to stop, it finishes the current job and exits. Write NewWorker, Start, and Stop methods.",
+    "trap": "Model might store ctx context.Context as a struct field for shutdown signaling instead of passing it through function parameters",
+    "assertions": [
+      {"id": "4.1", "text": "Does NOT store context.Context as a field in the Worker struct"},
+      {"id": "4.2", "text": "Passes context as a parameter to Start() or Run() method (e.g., Start(ctx context.Context))"},
+      {"id": "4.3", "text": "Uses context cancellation or a done channel for graceful shutdown signaling"},
+      {"id": "4.4", "text": "Listens to ctx.Done() in a select statement to detect shutdown"},
+      {"id": "4.5", "text": "ctx is the first parameter where it appears, named ctx context.Context"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "without-cancel-background-work",
+    "description": "Tests whether the model uses context.WithoutCancel for background work that must outlive the request",
+    "prompt": "Write a Go HTTP handler that processes a payment. After successfully charging the customer, it must send an audit log event to an external audit service asynchronously. The audit log MUST complete even if the client disconnects immediately after receiving the 200 response. The audit log needs the trace_id from the request context for correlation. Target Go 1.21+.",
+    "trap": "Model might use context.Background() (losing trace_id) or pass r.Context() directly to the goroutine (cancelled when handler returns)",
+    "assertions": [
+      {"id": "5.1", "text": "Uses context.WithoutCancel to create a context for the audit goroutine"},
+      {"id": "5.2", "text": "Does NOT pass r.Context() directly to the background audit goroutine (it gets cancelled when the handler returns)"},
+      {"id": "5.3", "text": "Does NOT use context.Background() for the audit goroutine (that would lose trace_id and other values)"},
+      {"id": "5.4", "text": "The audit goroutine preserves request-scoped values (trace_id) from the original context"},
+      {"id": "5.5", "text": "Launches the audit as a separate goroutine (go keyword) so the handler can return immediately"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "nested-timeout-shorter-wins",
+    "description": "Tests understanding that nested timeouts always use the shorter deadline",
+    "prompt": "Write a Go service method that calls two downstream services sequentially. The overall operation has a 10-second timeout. The first call (to a fast cache) should have a 2-second timeout. The second call (to a slow database) should have an 8-second timeout. If the cache is slow, the database should still get its full 8 seconds. Implement this timeout hierarchy.",
+    "trap": "Model might naively nest WithTimeout(parentCtx, 8s) under a parent that already has 10s-minus-elapsed, not realizing that if the first call takes 2 seconds the parent only has 8s left — or worse, create child with longer timeout than parent remaining",
+    "assertions": [
+      {"id": "6.1", "text": "Creates the overall 10-second timeout from the parent context"},
+      {"id": "6.2", "text": "Creates the cache timeout as a child of the overall context (so the 2s cache timeout is bounded by the 10s overall)"},
+      {"id": "6.3", "text": "Acknowledges or handles that the database timeout is bounded by whatever time remains on the parent (not a fresh 8 seconds independent of the parent)"},
+      {"id": "6.4", "text": "Defers cancel() for every WithTimeout call"},
+      {"id": "6.5", "text": "Does NOT create independent context.Background() timeouts that bypass the overall deadline"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "context-todo-vs-background",
+    "description": "Tests correct usage of context.TODO() vs context.Background()",
+    "prompt": "I'm refactoring a Go codebase to add context support. Many functions don't accept context yet. Write a migration plan showing how to incrementally add context.Context to this call chain: main() -> runServer() -> handleRequest() -> processOrder() -> saveToDatabase(). Some functions already accept context, others don't yet. Show intermediate steps with code.",
+    "trap": "Model might use context.Background() everywhere as a placeholder. Skill teaches context.TODO() is the correct placeholder when a function needs a context but doesn't have one yet",
+    "assertions": [
+      {"id": "7.1", "text": "Uses context.TODO() (not context.Background()) as the temporary placeholder in functions not yet fully migrated"},
+      {"id": "7.2", "text": "Uses context.Background() only at the true top level (main function or test setup)"},
+      {"id": "7.3", "text": "Shows a migration path where context.TODO() is gradually replaced as callers are updated"},
+      {"id": "7.4", "text": "Context is always the first parameter, named ctx context.Context"},
+      {"id": "7.5", "text": "Does NOT pass nil as a context value at any point in the migration"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "db-context-variants",
+    "description": "db.BeginTx (not db.Begin) is required for cancellable transactions; context must flow to every db call including transaction start",
+    "prompt": "Review this Go repository method and identify all context-related issues:\n\n```go\nfunc (r *UserRepository) TransferCredits(ctx context.Context, fromID, toID string, amount int) error {\n    tx, err := r.db.Begin()\n    if err != nil {\n        return fmt.Errorf(\"begin tx: %w\", err)\n    }\n    defer tx.Rollback()\n\n    _, err = tx.ExecContext(ctx, \"UPDATE users SET credits = credits - $1 WHERE id = $2\", amount, fromID)\n    if err != nil {\n        return fmt.Errorf(\"debit: %w\", err)\n    }\n\n    _, err = tx.ExecContext(ctx, \"UPDATE users SET credits = credits + $1 WHERE id = $2\", amount, toID)\n    if err != nil {\n        return fmt.Errorf(\"credit: %w\", err)\n    }\n\n    return tx.Commit()\n}\n```\n\nWhat is wrong with how context is used? Fix it.",
+    "trap": "The model sees ExecContext being used and may think context usage is correct. The bug: db.Begin() starts the transaction without a context — if ctx is already cancelled when Begin() is called, the transaction still starts. Also, tx.Commit() should be tx.CommitContext(ctx) if available, but the main issue is db.BeginTx(ctx, nil) instead of db.Begin().",
+    "assertions": [
+      {"id": "8.1", "text": "Identifies db.Begin() as the bug — it starts a transaction ignoring the context; if ctx is cancelled before Begin() returns, the transaction still starts"},
+      {"id": "8.2", "text": "Replaces db.Begin() with db.BeginTx(ctx, nil) — BeginTx respects context cancellation and won't start a transaction if ctx is already done"},
+      {"id": "8.3", "text": "Keeps ExecContext calls passing ctx — these are already correct"},
+      {"id": "8.4", "text": "Does not add a redundant ctx check before Begin() as the fix — the correct fix is BeginTx, not a manual ctx.Err() guard"},
+      {"id": "8.5", "text": "Each method accepts ctx context.Context as its first parameter and it flows through all DB operations"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "context-values-abuse",
+    "description": "Tests that the model does not abuse context values for function parameters",
+    "prompt": "Write a Go service that processes orders. The service needs: a database connection, a logger, a user ID (from auth), a trace ID (from middleware), and the order details. Design the ProcessOrder function signature and show how to pass all these dependencies.",
+    "trap": "Model might stuff the database connection, logger, or order details into context values instead of passing them as explicit parameters or struct fields",
+    "assertions": [
+      {"id": "9.1", "text": "Database connection is passed as a struct field or explicit parameter, NOT via context value"},
+      {"id": "9.2", "text": "Logger is passed as a struct field or explicit parameter, NOT via context value"},
+      {"id": "9.3", "text": "Order details are passed as an explicit function parameter, NOT via context value"},
+      {"id": "9.4", "text": "User ID and/or trace ID are stored in context values (these are request-scoped metadata)"},
+      {"id": "9.5", "text": "Distinguishes between infrastructure dependencies (explicit) and request-scoped metadata (context values)"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "afterfunc-cleanup",
+    "description": "Tests awareness of context.AfterFunc for cleanup callbacks (Go 1.21+)",
+    "prompt": "Write a Go function that opens a temporary file for processing and must clean it up when the request context is cancelled. The file should be deleted asynchronously when the context is done, without blocking the main processing flow. The main function should continue processing immediately after registering the cleanup. Target Go 1.21+.",
+    "trap": "Model might use a goroutine with <-ctx.Done() manually or use defer (which doesn't handle context cancellation). Skill teaches context.AfterFunc for non-blocking cleanup callbacks",
+    "assertions": [
+      {"id": "10.1", "text": "Uses context.AfterFunc to register the cleanup callback"},
+      {"id": "10.2", "text": "Does NOT block the main flow waiting for context cancellation (no <-ctx.Done() in the main goroutine for cleanup purposes)"},
+      {"id": "10.3", "text": "The cleanup function removes the temporary file"},
+      {"id": "10.4", "text": "Captures the stop function returned by AfterFunc for potential cancellation of the callback"},
+      {"id": "10.5", "text": "Also includes a defer-based cleanup as a safety net (AfterFunc + defer for belt-and-suspenders)"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/cancellation.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/cancellation.md
new file mode 100644
index 00000000..8a410dd0
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/cancellation.md
@@ -0,0 +1,172 @@
+# Cancellation, Timeouts & Deadlines
+
+## Cancellation
+
+`context.WithCancel` returns a derived context and a `cancel` function. When `cancel()` is called, the context's `Done()` channel is closed, signaling all listeners to stop.
+
+```go
+func processItems(ctx context.Context, items []Item) error {
+    ctx, cancel := context.WithCancel(ctx)
+    defer cancel() // always defer cancel to free resources
+
+    errCh := make(chan error, len(items))
+    for _, item := range items {
+        go func(item Item) {
+            errCh <- processOne(ctx, item)
+        }(item)
+    }
+
+    for range items {
+        if err := <-errCh; err != nil {
+            cancel() // cancel remaining goroutines on first error
+            return fmt.Errorf("processing items: %w", err)
+        }
+    }
+    return nil
+}
+```
+
+### Why `defer cancel()` matters
+
+Every `WithCancel`, `WithTimeout`, and `WithDeadline` creates cancellation state; timeout/deadline contexts also use timer resources. `cancel()` MUST be called on all control-flow paths unless the function explicitly returns or transfers ownership of both the context and cancel function. In ordinary scoped work, defer cancel immediately.
+
+```go
+// ✗ Bad — cancel is never called, resources leak
+func fetch(ctx context.Context) error {
+    ctx, _ = context.WithTimeout(ctx, 5*time.Second)
+    return doWork(ctx)
+}
+
+// ✓ Good — scoped work, defer cancel immediately
+func fetch(ctx context.Context) error {
+    ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
+    defer cancel()
+    return doWork(ctx)
+}
+```
+
+## Timeouts and Deadlines
+
+### `context.WithTimeout` — relative duration
+
+```go
+func (s *UserService) GetUser(ctx context.Context, id string) (*User, error) {
+    ctx, cancel := context.WithTimeout(ctx, 3*time.Second)
+    defer cancel()
+
+    return s.repo.FindByID(ctx, id)
+}
+```
+
+### `context.WithDeadline` — absolute point in time
+
+```go
+func (s *BatchService) ProcessBatch(ctx context.Context, batch Batch) error {
+    // The batch must complete by its SLA deadline
+    ctx, cancel := context.WithDeadline(ctx, batch.SLADeadline)
+    defer cancel()
+
+    for _, item := range batch.Items {
+        if err := s.process(ctx, item); err != nil {
+            return fmt.Errorf("processing batch item %s: %w", item.ID, err)
+        }
+    }
+    return nil
+}
+```
+
+### Nested timeouts take the shorter deadline
+
+If a parent context has a 5s timeout and you create a child with 10s, the child still expires at 5s. The shorter deadline always wins.
+
+```go
+// Parent has 2s timeout — child's 10s is effectively ignored
+parentCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
+defer cancel()
+
+childCtx, childCancel := context.WithTimeout(parentCtx, 10*time.Second)
+defer childCancel()
+// childCtx expires after 2s, not 10s
+```
+
+## Listening for Cancellation
+
+### The `select` pattern
+
+Use `ctx.Done()` in a `select` statement to react to cancellation alongside other work:
+
+```go
+func poll(ctx context.Context, interval time.Duration) error {
+    ticker := time.NewTicker(interval)
+    defer ticker.Stop()
+
+    for {
+        select {
+        case <-ctx.Done():
+            return ctx.Err() // context.Canceled or context.DeadlineExceeded
+        case <-ticker.C:
+            if err := doWork(ctx); err != nil {
+                return fmt.Errorf("polling: %w", err)
+            }
+        }
+    }
+}
+```
+
+### Checking cancellation in loops
+
+For CPU-bound work, periodically check `ctx.Err()`:
+
+```go
+func processLargeDataset(ctx context.Context, items []Item) error {
+    for i, item := range items {
+        if ctx.Err() != nil {
+            return fmt.Errorf("processing interrupted after %d/%d items: %w", i, len(items), ctx.Err())
+        }
+        process(item)
+    }
+    return nil
+}
+```
+
+## `context.AfterFunc` (Go 1.21+)
+
+Registers a callback that runs in its own goroutine when the context is cancelled. Useful for cleanup without blocking the main flow.
+
+```go
+func watchResource(ctx context.Context, res *Resource) {
+    stop := context.AfterFunc(ctx, func() {
+        // Runs in a new goroutine when ctx is cancelled
+        res.Release()
+    })
+
+    // If you no longer need the callback, cancel it:
+    // stop() returns true if the callback was successfully cancelled
+    _ = stop
+}
+```
+
+## `context.WithoutCancel` (Go 1.21+)
+
+Creates a child context that is not cancelled when the parent is. Use this for background work that must continue after the request completes — like async logging, audit trails, or enqueuing follow-up tasks.
+
+```go
+func (h *Handler) CreateOrder(w http.ResponseWriter, r *http.Request) {
+    ctx := r.Context()
+
+    order, err := h.orderService.Create(ctx, req)
+    if err != nil {
+        // handle error
+        return
+    }
+
+    // Audit log must complete even if the client disconnects.
+    // WithoutCancel preserves context values (trace_id) but detaches cancellation.
+    auditCtx := context.WithoutCancel(ctx)
+    go h.auditService.LogOrderCreated(auditCtx, order)
+
+    w.WriteHeader(http.StatusCreated)
+}
+```
+
+Without `WithoutCancel`, you'd have to choose between `ctx` (which gets cancelled when the handler returns, killing your background work) and `context.Background()` (which loses trace_id and other values). `WithoutCancel` gives you the best of both: values are preserved, but cancellation is detached.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/http-services.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/http-services.md
new file mode 100644
index 00000000..0c7b7443
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/http-services.md
@@ -0,0 +1,107 @@
+# Context in HTTP Servers & Service Calls
+
+## Context in HTTP Servers
+
+`http.Request` carries a context that is cancelled when the client disconnects or the request handler returns. MUST use `r.Context()` — NEVER create a new `context.Background()` inside a handler.
+
+```go
+func (h *Handler) GetOrder(w http.ResponseWriter, r *http.Request) {
+    ctx := r.Context() // this context is cancelled if the client disconnects
+
+    order, err := h.orderService.Get(ctx, r.PathValue("id"))
+    if err != nil {
+        if ctx.Err() != nil {
+            // Client disconnected, no point writing a response
+            return
+        }
+        http.Error(w, "internal error", http.StatusInternalServerError)
+        return
+    }
+
+    json.NewEncoder(w).Encode(order)
+}
+```
+
+## Middleware enriching context
+
+Middleware injects request-scoped values before handlers run. Use unexported key types to prevent collisions:
+
+```go
+// Helpers for trace propagation
+type contextKey string
+const (
+    traceIDKey contextKey = "trace_id"
+    spanIDKey  contextKey = "span_id"
+)
+
+func TracingMiddleware(next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        traceID := r.Header.Get("X-Trace-ID")
+        if traceID == "" {
+            traceID = generateTraceID()
+        }
+        spanID := r.Header.Get("X-Span-ID")
+        if spanID == "" {
+            spanID = generateSpanID()
+        }
+
+        ctx := context.WithValue(r.Context(), traceIDKey, traceID)
+        ctx = context.WithValue(ctx, spanIDKey, spanID)
+
+        w.Header().Set("X-Trace-ID", traceID)
+        w.Header().Set("X-Span-ID", spanID)
+        next.ServeHTTP(w, r.WithContext(ctx))
+    })
+}
+
+// Propagate trace context to downstream services
+func (c *HTTPClient) Do(ctx context.Context, method, url string, body io.Reader) (*http.Response, error) {
+    req, err := http.NewRequestWithContext(ctx, method, url, body)
+    if err != nil {
+        return nil, fmt.Errorf("creating request: %w", err)
+    }
+
+    if traceID, ok := ctx.Value(traceIDKey).(string); ok {
+        req.Header.Set("X-Trace-ID", traceID)
+    }
+    if spanID, ok := ctx.Value(spanIDKey).(string); ok {
+        req.Header.Set("X-Span-ID", spanID)
+    }
+    return c.client.Do(req)
+}
+```
+
+## Context in Calls to Other Services
+
+Context MUST be propagated to all HTTP clients and databases using context-aware APIs: `http.NewRequestWithContext`, `QueryContext`, `ExecContext`, and `QueryRowContext`. This ensures that client disconnections cancel all downstream operations.
+
+```go
+// ✗ Bad — downstream calls ignore the request context
+func (c *PaymentClient) Charge(ctx context.Context, amount int) error {
+    req, _ := http.NewRequest("POST", c.url+"/charge", body)
+    return c.client.Do(req) // not context-aware
+}
+
+// ✓ Good — all downstream operations respect the context
+func (c *PaymentClient) Charge(ctx context.Context, amount int) error {
+    req, err := http.NewRequestWithContext(ctx, "POST", c.url+"/charge", body)
+    if err != nil {
+        return fmt.Errorf("creating request: %w", err)
+    }
+    return c.client.Do(req)
+}
+```
+
+```go
+// ✗ Bad — downstream calls ignore the request context
+func (r *UserRepo) FindByID(ctx context.Context, id string) (*User, error) {
+    row := r.db.QueryRow("SELECT * FROM users WHERE id = $1", id)
+    // ...
+}
+
+// ✓ Good — all downstream operations respect the context
+func (r *UserRepo) FindByID(ctx context.Context, id string) (*User, error) {
+    row := r.db.QueryRowContext(ctx, "SELECT * FROM users WHERE id = $1", id)
+    // ...
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/values-tracing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/values-tracing.md
new file mode 100644
index 00000000..a7778a2c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-context/references/values-tracing.md
@@ -0,0 +1,78 @@
+# Context Values & Cross-Service Tracing
+
+## Using context values correctly
+
+Context values carry request-scoped metadata that crosses API boundaries — not function parameters, configuration, or optional arguments. Good candidates: trace IDs, span IDs, request IDs, authenticated user info, correlation IDs.
+
+Always use an unexported type as the key to prevent collisions between packages:
+
+```go
+// ✓ Good — unexported key type prevents collisions
+type contextKey string
+
+const (
+    traceIDKey   contextKey = "trace_id"
+    requestIDKey contextKey = "request_id"
+)
+
+func WithTraceID(ctx context.Context, traceID string) context.Context {
+    return context.WithValue(ctx, traceIDKey, traceID)
+}
+
+func TraceIDFromContext(ctx context.Context) (string, bool) {
+    traceID, ok := ctx.Value(traceIDKey).(string)
+    return traceID, ok
+}
+```
+
+```go
+// ✗ Bad — string keys collide across packages
+ctx = context.WithValue(ctx, "trace_id", traceID) // another package could use the same key
+```
+
+## What belongs in context values vs function parameters
+
+| Data | Context value? | Why |
+| --- | --- | --- |
+| trace_id, span_id, request_id | Yes | Request-scoped metadata for observability |
+| Authenticated user/tenant | Yes | Request-scoped, crosses API boundaries |
+| Database connection | No | Infrastructure dependency, pass explicitly |
+| Feature flags | No | Configuration, pass explicitly or inject |
+| Function arguments (user ID, order data) | No | Business logic parameters, pass as arguments |
+| Logger | Depends | OK if enriched with request-scoped fields (trace_id); otherwise pass explicitly |
+
+## Trace propagation between services
+
+In a microservices architecture, `context.Context` is the vehicle for trace propagation. When Service A calls Service B, the trace_id and span_id travel through context values and are injected into outgoing HTTP headers (typically via OpenTelemetry). This creates a connected trace across the entire request path.
+
+```go
+// Middleware injects trace_id from incoming request headers into context
+func TracingMiddleware(next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        traceID := r.Header.Get("X-Trace-ID")
+        if traceID == "" {
+            traceID = generateTraceID()
+        }
+
+        ctx := WithTraceID(r.Context(), traceID)
+        next.ServeHTTP(w, r.WithContext(ctx))
+    })
+}
+
+// When making outbound HTTP calls, inject trace_id from context into headers
+func (c *HTTPClient) Do(ctx context.Context, method, url string, body io.Reader) (*http.Response, error) {
+    req, err := http.NewRequestWithContext(ctx, method, url, body)
+    if err != nil {
+        return nil, fmt.Errorf("creating request: %w", err)
+    }
+
+    // Propagate trace_id to downstream service
+    if traceID, ok := TraceIDFromContext(ctx); ok {
+        req.Header.Set("X-Trace-ID", traceID)
+    }
+
+    return c.client.Do(req)
+}
+```
+
+With OpenTelemetry, this propagation is handled automatically through the `otel` SDK and `propagation.TraceContext`, but the mechanism is the same: context carries the trace state, and it must be propagated through every layer.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/SKILL.md
new file mode 100644
index 00000000..9219b688
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/SKILL.md
@@ -0,0 +1,272 @@
+---
+name: golang-continuous-integration
+description: "CI/CD pipeline configuration using GitHub Actions for Golang projects — testing, linting, SAST, security scanning, code coverage, Dependabot, Renovate, GoReleaser, code review automation, and release pipelines. Use when setting up or improving Go project CI, configuring GitHub Actions workflows, adding linters or security scanners, automating dependency updates, or adding quality gates."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.3.1"
+  openclaw:
+    emoji: "🚀"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - goreleaser
+        - gh
+    install:
+      - kind: brew
+        formula: goreleaser
+        bins: [goreleaser]
+      - kind: brew
+        formula: gh
+        bins: [gh]
+      - kind: npm
+        package: skills
+        bins: [skills]
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch Bash(goreleaser:*) Bash(gh:*) AskUserQuestion
+---
+
+**Persona:** You are a Go DevOps engineer. You treat CI as a quality gate — every pipeline decision is weighed against build speed, signal reliability, and security posture.
+
+**Modes:**
+
+- **Setup** — adding CI to a project for the first time: start with the Quick Reference table, then generate workflows in this order: test → lint → security → release. Prefer the latest stable major version for each GitHub Action.
+- **Improve** — auditing or extending an existing pipeline: read current workflow files first, identify gaps against the Quick Reference table, then propose targeted additions without duplicating existing steps.
+
+**Dependencies:**
+
+- goreleaser: `go install github.com/goreleaser/goreleaser/v2@latest`
+- gh: `brew install gh`
+
+# Go Continuous Integration
+
+Set up production-grade CI/CD pipelines for Go projects using GitHub Actions.
+
+## Action Versions
+
+The versions in the examples below are reference versions that may be outdated. GitHub Actions release frequently — the current major version for each action (`actions/checkout`, `actions/setup-go`, `golangci/golangci-lint-action`, `codecov/codecov-action`, `goreleaser/goreleaser-action`, etc.) may differ from what is shown here.
+
+## Quick Reference
+
+| Stage         | Tool                        | Purpose                       |
+| ------------- | --------------------------- | ----------------------------- |
+| **Test**      | `go test -race`             | Unit + race detection         |
+| **Coverage**  | `codecov/codecov-action`    | Coverage reporting            |
+| **Lint**      | `golangci-lint`             | Comprehensive linting         |
+| **Vet**       | `go vet`                    | Built-in static analysis      |
+| **SAST**      | `gosec`, `CodeQL`, `Bearer` | Security static analysis      |
+| **Vuln scan** | `govulncheck`               | Known vulnerability detection |
+| **Docker**    | `docker/build-push-action`  | Multi-platform image builds   |
+| **Deps**      | Dependabot / Renovate       | Automated dependency updates  |
+| **Release**   | GoReleaser                  | Automated binary releases     |
+| **AI Review** | Claude Code / Copilot       | AI-powered PR review          |
+
+---
+
+## Testing
+
+`.github/workflows/test.yml` — see [test.yml](./assets/test.yml)
+
+Adapt the Go version matrix to match `go.mod`:
+
+```
+go 1.23   → matrix: ["1.23", "1.24", "1.25", "1.26", "stable"]
+go 1.24   → matrix: ["1.24", "1.25", "1.26", "stable"]
+go 1.25   → matrix: ["1.25", "1.26", "stable"]
+go 1.26   → matrix: ["1.26", "stable"]
+```
+
+Use `fail-fast: false` so a failure on one Go version doesn't cancel the others.
+
+Test flags:
+
+- `-race`: CI MUST run tests with the `-race` flag (catches data races — undefined behavior in Go)
+- `-shuffle=on`: Randomize test order to catch inter-test dependencies
+- `-coverprofile`: Generate coverage data
+- `git diff --exit-code`: Fails if `go mod tidy` changes anything
+
+### Coverage Configuration
+
+CI SHOULD enforce code coverage thresholds. Configure thresholds in `codecov.yml` at the repo root — see [codecov.yml](./assets/codecov.yml)
+
+---
+
+## Integration Tests
+
+`.github/workflows/integration.yml` — see [integration.yml](./assets/integration.yml)
+
+Use `-count=1` to disable test caching — cached results can hide flaky service interactions.
+
+---
+
+## Linting
+
+`golangci-lint` MUST be run in CI on every PR. `.github/workflows/lint.yml` — see [lint.yml](./assets/lint.yml)
+
+### golangci-lint Configuration
+
+Create `.golangci.yml` at the root of the project. See the `samber/cc-skills-golang@golang-lint` skill for the recommended configuration.
+
+---
+
+## Security & SAST
+
+`.github/workflows/security.yml` — see [security.yml](./assets/security.yml)
+
+CI MUST run `govulncheck`. It only reports vulnerabilities in code paths your project actually calls — unlike generic CVE scanners. CodeQL results appear in the repository's Security tab. Bearer is good at detecting sensitive data flow issues.
+
+### CodeQL Configuration
+
+Create `.github/codeql/codeql-config.yml` to use the extended security query suite — see [codeql-config.yml](./assets/codeql-config.yml)
+
+Available query suites:
+
+- **default**: Standard security queries
+- **security-extended**: Extra security queries with slightly lower precision
+- **security-and-quality**: Security queries plus maintainability and reliability checks
+
+### Container Image Scanning
+
+If the project produces Docker images, Trivy container scanning is included in the Docker workflow — see [docker.yml](./assets/docker.yml)
+
+---
+
+## Dependency Management
+
+### Dependabot
+
+`.github/dependabot.yml` — see [dependabot.yml](./assets/dependabot.yml)
+
+Minor/patch updates are grouped into a single PR. Major updates get individual PRs since they may have breaking changes.
+
+#### Auto-Merge for Dependabot
+
+`.github/workflows/dependabot-auto-merge.yml` — see [dependabot-auto-merge.yml](./assets/dependabot-auto-merge.yml)
+
+> **Security warning:** This workflow requires `contents: write` and `pull-requests: write` — these are elevated permissions that allow merging PRs and modifying repository content. The `if: github.actor == 'dependabot[bot]'` guard restricts execution to Dependabot only. Do not remove this guard. Note that `github.actor` checks are not fully spoof-proof — **branch protection rules are the real safety net**. Ensure branch protection is configured (see [Repository Security Settings](#repository-security-settings)) with required status checks and required approvals so that auto-merge only succeeds after all checks pass, regardless of who triggered the workflow.
+
+### Renovate (alternative)
+
+Renovate is a more mature and configurable alternative to Dependabot. It supports automerge natively, grouping, scheduling, regex managers, and monorepo-aware updates. If Dependabot feels too limited, Renovate is the go-to choice.
+
+Install the [Renovate GitHub App](https://github.com/apps/renovate), then create `renovate.json` at the repo root — see [renovate.json](./assets/renovate.json)
+
+Key advantages over Dependabot:
+
+- **`gomodTidy`**: Automatically runs `go mod tidy` after updates
+- **Native automerge**: No separate workflow needed
+- **Better grouping**: More flexible rules for grouping PRs
+- **Regex managers**: Can update versions in Dockerfiles, Makefiles, etc.
+- **Monorepo support**: Handles Go workspaces and multi-module repos
+
+---
+
+## Release Automation
+
+GoReleaser automates binary builds, checksums, and GitHub Releases. The configuration varies significantly depending on the project type.
+
+### Release Workflow
+
+`.github/workflows/release.yml` — see [release.yml](./assets/release.yml)
+
+> **Security warning:** This workflow requires `contents: write` to create GitHub Releases. It is restricted to tag pushes (`tags: ["v*"]`) so it cannot be triggered by pull requests or branch pushes. Only users with push access to the repository can create tags.
+
+### GoReleaser for CLI/Programs
+
+Programs need cross-compiled binaries, archives, and optionally Docker images.
+
+`.goreleaser.yml` — see [goreleaser-cli.yml](./assets/goreleaser-cli.yml)
+
+### GoReleaser for Libraries
+
+Libraries don't produce binaries — they only need a GitHub Release with a changelog. Use a minimal config that skips the build.
+
+`.goreleaser.yml` — see [goreleaser-lib.yml](./assets/goreleaser-lib.yml)
+
+For libraries, you may not even need GoReleaser — a simple GitHub Release created via the UI or `gh release create` is often sufficient.
+
+### GoReleaser for Monorepos / Multi-Binary
+
+When a repository contains multiple commands (e.g., `cmd/api/`, `cmd/worker/`).
+
+`.goreleaser.yml` — see [goreleaser-monorepo.yml](./assets/goreleaser-monorepo.yml)
+
+### Docker Build & Push
+
+For projects that produce Docker images. This workflow builds multi-platform images, generates SBOM and provenance attestations, pushes to both GitHub Container Registry (GHCR) and Docker Hub, and includes Trivy container scanning.
+
+`.github/workflows/docker.yml` — see [docker.yml](./assets/docker.yml)
+
+> **Security warning:** Permissions are scoped per job: the `container-scan` job only gets `contents: read` + `security-events: write`, while the `docker` job gets `packages: write` (to push to GHCR) and `attestations: write` + `id-token: write` (for provenance/SBOM signing). This ensures the scan job cannot push images even if compromised. The `push` flag is set to `false` on pull requests so untrusted code cannot publish images. The `DOCKERHUB_USERNAME` and `DOCKERHUB_TOKEN` secrets must be configured in the repository secrets settings — never hardcode credentials.
+
+Key details:
+
+- **QEMU + Buildx**: Required for multi-platform builds (`linux/amd64,linux/arm64`). Remove platforms you don't need.
+- **`push: false` on PRs**: Images are built but never pushed on pull requests — this validates the Dockerfile without publishing untrusted code.
+- **Metadata action**: Automatically generates semver tags (`v1.2.3` → `1.2.3`, `1.2`, `1`), branch tags (`main`), and SHA tags.
+- **Provenance + SBOM**: `provenance: mode=max` and `sbom: true` generate supply chain attestations. These require `attestations: write` and `id-token: write` permissions.
+- **Dual registry**: Pushes to both GHCR (using `GITHUB_TOKEN`, no extra secret needed) and Docker Hub (requires `DOCKERHUB_USERNAME` + `DOCKERHUB_TOKEN` secrets). Remove the Docker Hub login and image line if not needed.
+- **Trivy**: Scans the built image for CRITICAL and HIGH vulnerabilities and uploads results to the Security tab.
+- Adapt the image names and registries to your project. For GHCR-only, remove the Docker Hub login step and the `docker.io/` line from `images:`.
+
+---
+
+## Repository Security Settings
+
+Repository security settings (branch protection, workflow permissions, secrets, environments) form the security foundation for the CI pipeline — these are documented in [repo-security.md](./references/repo-security.md).
+
+---
+
+## AI-Driven Code Review
+
+Add AI agents as PR reviewers alongside traditional static analysis. When loaded with this skill plugin, the agent applies the relevant Go skills per review area — catching architectural drift, logic bugs, missing error context, and concurrency hazards that linters cannot detect.
+
+> **Cost note:** AI review agents run concurrently per PR. For cost control, remove jobs you don't need or raise the PR trigger filter to specific branches only.
+
+### Claude Code
+
+`.github/workflows/ai-review.yml` — see [claude-code-review.yml](./assets/claude-code-review.yml)
+
+The workflow runs parallel jobs, each scoped to a set of review areas and priority level:
+
+| Job | Areas | Priority |
+| --- | --- | --- |
+| `quality` | Code style, Naming, Documentation, Design patterns | Suggestion-first |
+| `correctness` | Error handling, Code safety, Concurrency | Blocking-first |
+| `security` | Security, Dependencies | Blocking-first |
+| `quality-depth` | Tests, Performance, Observability, Modernize | Mixed |
+
+Additional skills that may be relevant depending on the project: `golang-cli`, `golang-context`, `golang-data-structures`, `golang-database`, `golang-dependency-injection`, or any library-specific skill.
+
+The Claude Code GitHub App integration is configured via the `/install-github-app` command, which sets up the required API secrets.
+
+### GitHub Copilot
+
+Copy skills into your repo, then append [copilot-review-instructions.md](./assets/copilot-review-instructions.md) to `.github/copilot-instructions.md`:
+
+```bash
+npx skills add https://github.com/samber/cc-skills-golang --agent github-copilot --skill '*' -y --copy
+ln -s .agents .copilot
+```
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Missing `-race` in CI tests | Always use `go test -race` |
+| No `-shuffle=on` | Randomize test order to catch inter-test dependencies |
+| Caching integration test results | Use `-count=1` to disable caching |
+| `go mod tidy` not checked | Add `go mod tidy && git diff --exit-code` step |
+| Missing `fail-fast: false` | One Go version failing shouldn't cancel other jobs |
+| Not pinning action versions | GitHub Actions MUST use pinned major versions (e.g. `@vN`, not `@master`) |
+| No `permissions` block | Follow least-privilege per job |
+| Ignoring govulncheck findings | Fix or suppress with justification |
+| No AI review in CI | Add Claude Code or Copilot review — catches logic, security, and architectural issues that static analysis misses |
+
+## Related Skills
+
+See `samber/cc-skills-golang@golang-lint`, `samber/cc-skills-golang@golang-security`, `samber/cc-skills-golang@golang-testing`, `samber/cc-skills-golang@golang-dependency-management`, `samber/cc-skills-golang@golang-modernize` skills.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/claude-code-review.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/claude-code-review.yml
new file mode 100644
index 00000000..20d1a8ee
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/claude-code-review.yml
@@ -0,0 +1,430 @@
+name: AI Code Review (Claude)
+
+on:
+  pull_request:
+    types: [opened, synchronize, reopened, ready_for_review]
+  pull_request_review_comment:
+    types: [created]
+  pull_request_review:
+    types: [submitted]
+
+# Security note: these permissions apply to the entire repository, not just the current PR.
+# `pull-requests: write` allows the workflow to post, edit, and resolve comments on ANY pull request.
+# `actions: read` allows reading logs from ANY workflow run, which may contain sensitive output.
+# Scope risk by restricting the trigger to PRs from trusted contributors or protected branches,
+# and by never logging secrets in CI steps.
+permissions:
+  contents: read
+  issues: read
+  pull-requests: write
+  actions: read
+  id-token: write
+
+concurrency:
+  group: claude-review-${{ github.event.pull_request.number || github.event.issue.number }}-${{ github.event_name }}
+  cancel-in-progress: true
+
+jobs:
+  # ── Job 1: Code quality (suggestion-first) ──────────────────────────────────
+  # Covers: style, naming, documentation
+  quality:
+    name: Review — Quality
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    # Skip bot PRs (Dependabot, Renovate, etc.)
+    # Remove this filter if you want bots to get reviewed.
+    if: ${{ github.event_name == 'pull_request' && !endsWith(github.event.pull_request.user.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Install Go skills
+        run: npx skills add https://github.com/samber/cc-skills-golang -a claude-code --skill '*' -y --copy
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: true
+          track_progress: true
+          sticky_comment_header: "<!-- claude-review-quality -->"
+          additional_permissions: |
+            actions: read
+          claude_args: >-
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,mcp__context7__resolve-library-id,mcp__context7__query-docs,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+            AUTHOR: ${{ github.event.pull_request.user.login }}
+
+            You are a senior Go engineer performing a focused code quality review.
+
+            Review this pull request.
+            - Use `gh pr diff` to read the diff.
+            - Use `gh pr view` to read description and metadata.
+            - Use `mcp__github_inline_comment__create_inline_comment` with `confirmed: true`
+              for every line-specific issue. Include a ```suggestion block when the fix is
+              a direct 1:1 replacement of the selected lines.
+            - Use `gh pr comment` only for a top-level summary.
+            - Post nothing else. No chat output.
+
+            ## Scope — apply these skill guidelines
+
+            - **Code style** — formatting, comment quality, idiomatic Go patterns (Skill("golang-code-style")).
+            - **Naming** — packages, types, variables, functions, constants (Skill("golang-naming")).
+            - **Documentation** — exported symbols, package-level docs, README impact (Skill("golang-documentation")).
+
+            ## Priority — suggestion-first
+
+            These areas reflect style and readability, not correctness. Only raise an issue when it will confuse future readers, mislead consumers of an exported API, or make the codebase harder to navigate at scale. Do not flag formatting that `gofmt` handles automatically. Do not flag personal preferences when the code is otherwise clear.
+
+            ## How to report
+
+            Every comment must:
+            1. Name the specific problem (not just its symptom)
+            2. Explain under what conditions it matters or fails
+            3. Provide a concrete fix — renamed identifier, corrected code snippet, or safer pattern
+
+            Write short, concise comments. Only comment when there is a specific issue. Do not praise the good stuff. Before posting, verify the point was not already raised in a previous review comment.
+
+            Note: the PR branch is already checked out in the current working directory.
+
+            Check project guidelines: @./CLAUDE.md
+            Check contributing guidelines: @./CONTRIBUTING.md
+            Check project description: @./docs/project-summary.md
+
+            Label each comment: 🟡 **SUGGESTION**
+
+  # ── Job 2: Correctness (blocking-first) ─────────────────────────────────────
+  # Covers: error handling, code safety, concurrency
+  correctness:
+    name: Review — Correctness
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    # Skip bot PRs (Dependabot, Renovate, etc.)
+    # Remove this filter if you want bots to get reviewed.
+    if: ${{ github.event_name == 'pull_request' && !endsWith(github.event.pull_request.user.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Install Go skills
+        run: npx skills add https://github.com/samber/cc-skills-golang -a claude-code --skill '*' -y --copy
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: true
+          track_progress: true
+          sticky_comment_header: "<!-- claude-review-correctness -->"
+          additional_permissions: |
+            actions: read
+          claude_args: >-
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,mcp__context7__resolve-library-id,mcp__context7__query-docs,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+            AUTHOR: ${{ github.event.pull_request.user.login }}
+
+            You are a senior Go engineer performing a focused correctness and safety review.
+
+            Review this pull request.
+            - Use `gh pr diff` to read the diff.
+            - Use `gh pr view` to read description and metadata.
+            - Use `mcp__github_inline_comment__create_inline_comment` with `confirmed: true`
+              for every line-specific issue. Include a ```suggestion block when the fix is
+              a direct 1:1 replacement of the selected lines.
+            - Use `gh pr comment` only for a top-level summary.
+            - Post nothing else. No chat output.
+
+            ## Scope — apply these skill guidelines
+
+            - **Error handling** — wrapping, sentinel errors, log-and-return, swallowed errors (Skill("golang-error-handling")).
+            - **Code safety** — nil dereference, map/slice aliasing, integer overflows, uninitialized state (Skill("golang-safety")).
+            - **Concurrency** — goroutine lifecycle, mutex usage, channel patterns, context propagation, data races (Skill("golang-concurrency")).
+
+            ## Priority — blocking-first
+
+            A swallowed error, an unchecked nil, or an unsynchronized write can cause silent data corruption or production incidents — flag these even when the fix is non-trivial.
+
+            ## How to report
+
+            Every comment must:
+            1. Name the specific problem (not just its symptom)
+            2. Explain under what conditions it matters or fails
+            3. Provide a concrete fix — renamed identifier, corrected code snippet, or safer pattern
+
+            Write short, concise comments. Only comment when there is a specific issue. Do not praise the good stuff. Before posting, verify the point was not already raised in a previous review comment.
+
+            Note: the PR branch is already checked out in the current working directory.
+
+            Check project guidelines: @./CLAUDE.md
+            Check contributing guidelines: @./CONTRIBUTING.md
+            Check project description: @./docs/project-summary.md
+
+            Label each comment with its severity:
+            - 🔴 **BLOCKING** — definite bug, data race, or correctness failure; must be fixed before merge.
+            - 🟠 **IMPORTANT** — significant risk that requires unusual conditions to manifest; strongly recommended to fix.
+            - 🟡 **SUGGESTION** — defensive improvement with low-probability failure mode or subtle edge case.
+
+  # ── Job 3: Security & dependencies (blocking-first) ─────────────────────────
+  # Covers: security, dependency health
+  security:
+    name: Review — Security & Dependencies
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    # Skip bot PRs (Dependabot, Renovate, etc.)
+    # Remove this filter if you want bots to get reviewed.
+    if: ${{ github.event_name == 'pull_request' && !endsWith(github.event.pull_request.user.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Install Go skills
+        run: npx skills add https://github.com/samber/cc-skills-golang -a claude-code --skill '*' -y --copy
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: true
+          track_progress: true
+          sticky_comment_header: "<!-- claude-review-security -->"
+          additional_permissions: |
+            actions: read
+          claude_args: >-
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,mcp__context7__resolve-library-id,mcp__context7__query-docs,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+            AUTHOR: ${{ github.event.pull_request.user.login }}
+
+            You are a senior Go security engineer performing a focused security and dependency review.
+
+            Review this pull request.
+            - Use `gh pr diff` to read the diff.
+            - Use `gh pr view` to read description and metadata.
+            - Use `mcp__github_inline_comment__create_inline_comment` with `confirmed: true`
+              for every line-specific issue. Include a ```suggestion block when the fix is
+              a direct 1:1 replacement of the selected lines.
+            - Use `gh pr comment` only for a top-level summary.
+            - Post nothing else. No chat output.
+
+            ## Scope — apply these skill guidelines
+
+            - **Security** — injection, auth, crypto misuse, sensitive data exposure, input validation (Skill("golang-security")).
+            - **Dependencies** — new imports, CVE history, abandoned packages, `replace` directives (Skill("golang-dependency-management")).
+
+            ## Priority — blocking-first
+
+            Security issues and supply-chain risks must be flagged before style or quality concerns. A single unvalidated input or a weak PRNG can open a critical vulnerability — do not downgrade these findings.
+
+            ## How to report
+
+            Every comment must:
+            1. Name the specific problem (not just its symptom)
+            2. Explain under what conditions it matters or fails
+            3. Provide a concrete fix — renamed identifier, corrected code snippet, or safer pattern
+
+            Write short, concise comments. Only comment when there is a specific issue. Do not praise the good stuff. Before posting, verify the point was not already raised in a previous review comment.
+
+            Note: the PR branch is already checked out in the current working directory.
+
+            Check project guidelines: @./CLAUDE.md
+            Check contributing guidelines: @./CONTRIBUTING.md
+            Check project description: @./docs/project-summary.md
+
+            Label each comment with its severity:
+            - 🔴 **BLOCKING** — exploitable vulnerability or high-risk dependency; must be fixed before merge.
+            - 🟠 **IMPORTANT** — significant risk that requires specific conditions; strongly recommended.
+            - 🟡 **SUGGESTION** — defense-in-depth improvement; optional but worthwhile.
+
+  # ── Job 4: Tests, performance, observability & modernization ─────────────────
+  # Covers: tests, performance, observability, modernize
+  quality-depth:
+    name: Review — Tests, Performance & Observability
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    # Skip bot PRs (Dependabot, Renovate, etc.)
+    # Remove this filter if you want bots to get reviewed.
+    if: ${{ github.event_name == 'pull_request' && !endsWith(github.event.pull_request.user.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Install Go skills
+        run: npx skills add https://github.com/samber/cc-skills-golang -a claude-code --skill '*' -y --copy
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: true
+          track_progress: true
+          sticky_comment_header: "<!-- claude-review-quality-depth -->"
+          additional_permissions: |
+            actions: read
+          claude_args: >-
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,mcp__context7__resolve-library-id,mcp__context7__query-docs,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+            AUTHOR: ${{ github.event.pull_request.user.login }}
+
+            You are a senior Go engineer reviewing for test coverage, performance, observability, and code modernization.
+
+            Review this pull request.
+            - Use `gh pr diff` to read the diff.
+            - Use `gh pr view` to read description and metadata.
+            - Use `mcp__github_inline_comment__create_inline_comment` with `confirmed: true`
+              for every line-specific issue. Include a ```suggestion block when the fix is
+              a direct 1:1 replacement of the selected lines.
+            - Use `gh pr comment` only for a top-level summary.
+            - Post nothing else. No chat output.
+
+            ## Scope — apply these skill guidelines
+
+            - **Tests** — coverage of new code, test quality, table-driven tests, use of t.Helper() (Skill("golang-testing")).
+            - **Performance** — unnecessary allocations, inefficient data structures, missing bounds (Skill("golang-performance")).
+            - **Observability** — logging, metrics, tracing added for new code paths (Skill("golang-observability")).
+            - **Modernize code** — outdated patterns replaced with Go 1.21+ idioms (Skill("golang-modernize")).
+
+            ## Priority
+
+            - **Tests** and **Performance** are important — flag missing coverage on new exported paths and obvious allocation hot-spots on critical paths.
+            - **Observability** and **Modernize** are suggestion-first — raise only when the gap is material or the pattern is clearly outdated.
+
+            ## How to report
+
+            Every comment must:
+            1. Name the specific problem (not just its symptom)
+            2. Explain under what conditions it matters or fails
+            3. Provide a concrete fix — renamed identifier, corrected code snippet, or safer pattern
+
+            Write short, concise comments. Only comment when there is a specific issue. Do not praise the good stuff. Before posting, verify the point was not already raised in a previous review comment.
+
+            Note: the PR branch is already checked out in the current working directory.
+
+            Check project guidelines: @./CLAUDE.md
+            Check contributing guidelines: @./CONTRIBUTING.md
+            Check project description: @./docs/project-summary.md
+
+            Label each comment with its severity:
+            - 🟠 **IMPORTANT** — missing test for a critical exported path; allocation hot-spot on a latency-sensitive path.
+            - 🟡 **SUGGESTION** — observability gap, modernization opportunity, or minor test quality improvement.
+
+  # ── Job 5: CI failure diagnosis ──────────────────────────────────────────────
+  # Waits for all review jobs to finish, then diagnoses any failures and suggests fixes.
+  ci-diagnosis:
+    name: Review — CI Failure Diagnosis
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    needs: [quality, correctness, security, quality-depth]
+    if: ${{ always() && github.event_name == 'pull_request' && !endsWith(github.event.pull_request.user.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: true
+          track_progress: true
+          sticky_comment_header: "<!-- claude-review-ci-diagnosis -->"
+          additional_permissions: |
+            actions: read
+          claude_args: >-
+            --allowedTools "Bash(gh pr comment:*),Bash(gh pr view:*),Bash(gh run view:*),Bash(gh run list:*)"
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+            WORKFLOW RUN ID: ${{ github.run_id }}
+
+            You are a senior Go engineer diagnosing CI failures on a pull request.
+
+            Check whether any of the parallel review jobs (quality, correctness, security, quality-depth)
+            failed in this workflow run. If all jobs succeeded, post nothing and exit.
+
+            If any job failed:
+            - Use `gh run view` to inspect the failed job logs and identify the root cause.
+            - Post a single `gh pr comment` summarizing:
+              1. Which job(s) failed and why (log excerpt).
+              2. Concrete steps to fix the failure (configuration change, missing secret, infra issue).
+            - Post nothing else. No chat output.
+
+  # ── Job 6: Discuss review comments ──────────────────────────────────────────
+  # Triggered when a human posts a review comment or submits a review.
+  # Replies to offer a counter-argument when warranted — stays concise.
+  discuss:
+    name: Review — Discuss
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    if: ${{ (github.event_name == 'pull_request_review_comment' || github.event_name == 'pull_request_review') && !endsWith(github.event.sender.login, '[bot]') }}
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - uses: anthropics/claude-code-action@v1
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          show_full_output: true
+          use_sticky_comment: false
+          track_progress: false
+          claude_args: >-
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr view:*),Bash(gh pr diff:*)"
+          prompt: |
+            REPO: ${{ github.repository }}
+            PR NUMBER: ${{ github.event.pull_request.number }}
+
+            You are a senior Go engineer participating in a code review discussion.
+
+            A human just posted a review comment or submitted a review on this PR.
+            Read the comment thread and decide whether to reply.
+
+            Reply ONLY if:
+            - The comment contains a factual mistake about Go semantics, the standard library, or a third-party package.
+            - The proposed change would introduce a bug, a performance regression, or a security issue.
+            - A brief clarification would unblock the discussion.
+
+            Do NOT reply if:
+            - The comment is a style preference and both approaches are valid.
+            - The author has already acknowledged the feedback.
+            - A debate is already in progress — let it resolve naturally.
+            - You already replied to this thread.
+
+            When you reply: be short and direct. One or two sentences maximum. State the technical
+            fact. If the author disagrees after your reply, drop the thread.
+
+            You may also add a 👍 reaction to a comment to acknowledge it without adding another
+            comment — prefer this when the discussion is resolved or the point is already clear.
+
+            Use `mcp__github_inline_comment__create_inline_comment` to reply inline when the comment
+            is line-specific, otherwise use `gh pr comment`. Post nothing else. No chat output.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/codecov.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/codecov.yml
new file mode 100644
index 00000000..e6a62b1c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/codecov.yml
@@ -0,0 +1,9 @@
+coverage:
+  status:
+    project:
+      default:
+        target: 80%
+        threshold: 2%
+    patch:
+      default:
+        target: 80%
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/codeql-config.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/codeql-config.yml
new file mode 100644
index 00000000..623d9da4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/codeql-config.yml
@@ -0,0 +1,8 @@
+name: "CodeQL config"
+
+queries:
+  - uses: security-and-quality
+
+query-filters:
+  - exclude:
+      id: go/unused-result
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/copilot-review-instructions.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/copilot-review-instructions.md
new file mode 100644
index 00000000..221ea66a
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/copilot-review-instructions.md
@@ -0,0 +1,61 @@
+<!-- Prerequisites:
+  The skills CLI (listed in the frontmatter install block) can be used to copy skills locally:
+    npx skills add https://github.com/samber/cc-skills-golang --agent github-copilot --skill '*' -y --copy
+    ln -s .agents .copilot
+  Then copy this file to .github/copilot-instructions.md
+-->
+
+# Go Code Review Instructions
+
+You are a senior Go engineer reviewing a pull request. Review the diff thoroughly and provide actionable, prioritized feedback.
+
+The available skills can be discovered from the local skill files:
+
+    find .copilot/skills -type f -name SKILL.md -print0 \
+      | xargs -0 yq -o=json \
+      | jq -r '{name, description}'
+
+Relevant skills should be loaded before reviewing the diff.
+
+## Scope of Review
+
+Cover each area below. Where a dedicated skill is listed, apply its guidance.
+
+- **Code style** — formatting, comment quality, idiomatic Go patterns (`.copilot/skills/golang-code-style/SKILL.md`)
+- **Naming** — packages, types, variables, functions, constants (`.copilot/skills/golang-naming/SKILL.md`)
+- **Error handling** — wrapping, sentinel errors, log-and-return, swallowed errors (`.copilot/skills/golang-error-handling/SKILL.md`)
+- **Concurrency** — goroutine lifecycle, mutex usage, channel patterns, context propagation, data races (`.copilot/skills/golang-concurrency/SKILL.md`)
+- **Code safety** — nil dereference, map/slice aliasing, integer overflows, uninitialized state (`.copilot/skills/golang-safety/SKILL.md`)
+- **Tests** — coverage of new code, test quality, table-driven tests, use of t.Helper() (`.copilot/skills/golang-testing/SKILL.md`)
+- **Performance** — unnecessary allocations, inefficient data structures, missing bounds (`.copilot/skills/golang-performance/SKILL.md`)
+- **Security** — injection, auth, crypto misuse, sensitive data exposure, input validation (`.copilot/skills/golang-security/SKILL.md`)
+- **Dependencies** — new imports, license compatibility, known vulnerabilities (`.copilot/skills/golang-dependency-management/SKILL.md`)
+- **Documentation** — exported symbols, package docs, README impact (`.copilot/skills/golang-documentation/SKILL.md`)
+- **Observability** — logging, metrics, tracing added for new code paths (`.copilot/skills/golang-observability/SKILL.md`)
+- **Modernize code** — outdated patterns replaced with Go 1.21+ idioms (`.copilot/skills/golang-modernize/SKILL.md`)
+
+## Review Priority
+
+Not all areas carry the same risk. Apply this order when time or API budget is limited:
+
+- **Blocking-first areas** (look for bugs and vulnerabilities before style): Security, Code safety, Error handling, Concurrency
+- **Important areas** (significant quality impact): Tests, Performance, Dependencies
+- **Suggestion-first areas** (raise only when notably wrong): Code style, Naming, Documentation, Observability, Modernize code
+
+## How to Report Issues
+
+For each issue found:
+
+- Reference the exact file and line number.
+- Explain what is wrong and why it matters.
+- Provide a concrete fix or example.
+
+Classify severity:
+
+- 🔴 **BLOCKING** — bug, vulnerability, data race, or correctness issue; must be fixed before merge.
+- 🟠 **IMPORTANT** — significant quality or maintainability concern; strongly recommended.
+- 🟡 **SUGGESTION** — style, naming, or minor improvement; optional but worthwhile.
+
+Use inline comments on the specific diff line when possible. For concerns not tied to a specific line, post a PR-level summary.
+
+Write short, concise comments. Only comment when there is a specific issue — do not praise the good stuff. If you have nothing to say, post nothing. Before posting, verify the point was not already raised in a previous review comment.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/dependabot-auto-merge.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/dependabot-auto-merge.yml
new file mode 100644
index 00000000..fcc9323a
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/dependabot-auto-merge.yml
@@ -0,0 +1,28 @@
+name: Dependabot Auto-Merge
+
+on:
+  pull_request:
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  auto-merge:
+    name: Auto-Merge
+    runs-on: ubuntu-latest
+    if: github.actor == 'dependabot[bot]'
+
+    steps:
+      - name: Fetch Dependabot metadata
+        id: metadata
+        uses: dependabot/fetch-metadata@v2
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Auto-merge minor and patch updates
+        if: steps.metadata.outputs.update-type != 'version-update:semver-major'
+        run: gh pr merge --auto --squash "$PR_URL"
+        env:
+          PR_URL: ${{ github.event.pull_request.html_url }}
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/dependabot.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/dependabot.yml
new file mode 100644
index 00000000..37bde82f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/dependabot.yml
@@ -0,0 +1,30 @@
+version: 2
+updates:
+  # Go modules
+  - package-ecosystem: gomod
+    directory: /
+    schedule:
+      interval: weekly
+      day: monday
+    labels: ["dependencies", "go"]
+    open-pull-requests-limit: 10
+    groups:
+      go-minor-patch:
+        update-types: [minor, patch]
+
+  # GitHub Actions
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: weekly
+    labels: ["dependencies", "ci"]
+    groups:
+      actions:
+        patterns: ["*"]
+
+  # Docker (if applicable)
+  - package-ecosystem: docker
+    directory: /
+    schedule:
+      interval: weekly
+    labels: ["dependencies", "docker"]
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/docker.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/docker.yml
new file mode 100644
index 00000000..4bf0e8d9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/docker.yml
@@ -0,0 +1,96 @@
+name: Docker
+
+on:
+  push:
+    branches: [main]
+    tags: ["v*"]
+  pull_request:
+
+jobs:
+  container-scan:
+    name: Container Scan
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      security-events: write
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Build image
+        run: docker build -t myapp:ci .
+
+      - name: Run Trivy
+        uses: aquasecurity/trivy-action@v0.35.0
+        with:
+          image-ref: myapp:ci
+          format: sarif
+          output: trivy-results.sarif
+          severity: CRITICAL,HIGH
+          exit-code: '1'
+
+      - name: Upload Trivy results
+        if: always()
+        uses: github/codeql-action/upload-sarif@v4
+        with:
+          sarif_file: trivy-results.sarif
+
+  docker:
+    name: Build & Push
+    runs-on: ubuntu-latest
+    needs: container-scan
+    permissions:
+      contents: read
+      packages: write
+      attestations: write
+      id-token: write
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@v3
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
+      - name: Log in to GitHub Container Registry
+        if: github.event_name != 'pull_request'
+        uses: docker/login-action@v3
+        with:
+          registry: ghcr.io
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Log in to Docker Hub
+        if: github.event_name != 'pull_request'
+        uses: docker/login-action@v3
+        with:
+          username: ${{ secrets.DOCKERHUB_USERNAME }}
+          password: ${{ secrets.DOCKERHUB_TOKEN }}
+
+      - name: Extract metadata
+        id: meta
+        uses: docker/metadata-action@v5
+        with:
+          images: |
+            ghcr.io/${{ github.repository }}
+            docker.io/${{ github.repository }}
+          tags: |
+            type=semver,pattern={{version}}
+            type=semver,pattern={{major}}.{{minor}}
+            type=semver,pattern={{major}}
+            type=ref,event=branch
+            type=sha
+
+      - name: Build and push
+        id: build
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          provenance: mode=max
+          sbom: true
+          push: ${{ github.event_name != 'pull_request' }}
+          platforms: linux/amd64,linux/arm64
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-cli.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-cli.yml
new file mode 100644
index 00000000..4254072f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-cli.yml
@@ -0,0 +1,31 @@
+version: 2
+
+builds:
+  - env:
+      - CGO_ENABLED=0
+    goos:
+      - linux
+      - darwin
+      - windows
+    goarch:
+      - amd64
+      - arm64
+    ldflags:
+      - -s -w
+      - -X main.version={{.Version}}
+      - -X main.commit={{.Commit}}
+
+archives:
+  - format: tar.gz
+    name_template: "{{ .ProjectName }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}"
+    format_overrides:
+      - goos: windows
+        format: zip
+
+checksum:
+  name_template: checksums.txt
+
+changelog:
+  sort: asc
+  filters:
+    exclude: ["^docs", "^test", "^ci", "^chore", "^style"]
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-lib.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-lib.yml
new file mode 100644
index 00000000..3b71ba2c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-lib.yml
@@ -0,0 +1,9 @@
+version: 2
+
+builds:
+  - skip: true
+
+changelog:
+  sort: asc
+  filters:
+    exclude: ["^docs:", "^test:", "^ci:", "^chore:"]
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-monorepo.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-monorepo.yml
new file mode 100644
index 00000000..adb69a28
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/goreleaser-monorepo.yml
@@ -0,0 +1,30 @@
+version: 2
+
+builds:
+  - id: api
+    main: ./cmd/api
+    binary: api
+    env:
+      - CGO_ENABLED=0
+    goos:
+      - linux
+      - darwin
+    goarch:
+      - amd64
+      - arm64
+
+  - id: worker
+    main: ./cmd/worker
+    binary: worker
+    env:
+      - CGO_ENABLED=0
+    goos:
+      - linux
+      - darwin
+    goarch:
+      - amd64
+      - arm64
+
+archives:
+  - format: tar.gz
+    name_template: "{{ .ProjectName }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}"
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/integration.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/integration.yml
new file mode 100644
index 00000000..9f1f1d10
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/integration.yml
@@ -0,0 +1,53 @@
+name: Integration Tests
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  integration:
+    name: Integration Tests
+    runs-on: ubuntu-latest
+
+    services:
+      postgres:
+        image: postgres:18-alpine
+        env:
+          POSTGRES_USER: test
+          POSTGRES_PASSWORD: test
+          POSTGRES_DB: testdb
+        ports:
+          - 5432:5432
+        options: >-
+          --health-cmd pg_isready
+          --health-interval 10s
+          --health-timeout 5s
+          --health-retries 5
+
+      redis:
+        image: redis:7-alpine
+        ports:
+          - 6379:6379
+        options: >-
+          --health-cmd "redis-cli ping"
+          --health-interval 10s
+          --health-timeout 5s
+          --health-retries 5
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Run integration tests
+        run: go test -v -race -tags=integration -count=1 ./...
+        env:
+          DATABASE_URL: postgres://test:test@localhost:5432/testdb?sslmode=disable
+          REDIS_URL: redis://localhost:6379
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/lint.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/lint.yml
new file mode 100644
index 00000000..43427c0e
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/lint.yml
@@ -0,0 +1,31 @@
+name: Lint
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  lint:
+    name: Lint
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Run go vet
+        run: go vet ./...
+
+      - name: golangci-lint
+        uses: golangci/golangci-lint-action@v9
+        with:
+          version: latest
+          args: --timeout 5m
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/release.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/release.yml
new file mode 100644
index 00000000..abd6b46e
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/release.yml
@@ -0,0 +1,31 @@
+name: Release
+
+on:
+  push:
+    tags: ["v*"]
+
+permissions:
+  contents: write
+
+jobs:
+  release:
+    name: Release
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v6
+        with:
+          fetch-depth: 0
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Run GoReleaser
+        uses: goreleaser/goreleaser-action@v7
+        with:
+          version: "~> v2"
+          args: release --clean
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/renovate.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/renovate.json
new file mode 100644
index 00000000..c59d9967
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/renovate.json
@@ -0,0 +1,22 @@
+{
+  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
+  "extends": [
+    "config:recommended"
+  ],
+  "postUpdateOptions": [
+    "gomodTidy"
+  ],
+  "packageRules": [
+    {
+      "matchManagers": ["gomod"],
+      "matchUpdateTypes": ["minor", "patch"],
+      "automerge": true,
+      "groupName": "go minor/patch dependencies"
+    },
+    {
+      "matchManagers": ["github-actions"],
+      "automerge": true,
+      "groupName": "github actions"
+    }
+  ]
+}
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/security.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/security.yml
new file mode 100644
index 00000000..1467b792
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/security.yml
@@ -0,0 +1,82 @@
+name: Security
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+permissions:
+  contents: read
+  security-events: write
+
+jobs:
+  govulncheck:
+    name: Vulnerability Check
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: stable
+
+      - name: Run govulncheck
+        uses: golang/govulncheck-action@v1
+
+  gosec:
+    name: gosec
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Run gosec
+        uses: securego/gosec@v2
+        with:
+          args: -no-fail -fmt sarif -out gosec-results.sarif ./...
+
+      - name: Upload gosec results
+        if: always()
+        uses: github/codeql-action/upload-sarif@v4
+        with:
+          sarif_file: gosec-results.sarif
+
+  codeql:
+    name: CodeQL
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@v4
+        with:
+          languages: go
+          config-file: .github/codeql/codeql-config.yml
+
+      - name: Autobuild
+        uses: github/codeql-action/autobuild@v4
+
+      - name: Perform CodeQL Analysis
+        uses: github/codeql-action/analyze@v4
+
+  bearer:
+    name: Bearer
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Bearer Security Scan
+        uses: bearer/bearer-action@v2
+        with:
+          format: sarif
+          output: bearer-results.sarif
+
+      - name: Upload Bearer results
+        if: always()
+        uses: github/codeql-action/upload-sarif@v4
+        with:
+          sarif_file: bearer-results.sarif
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/test.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/test.yml
new file mode 100644
index 00000000..30c28b96
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/assets/test.yml
@@ -0,0 +1,53 @@
+name: Tests
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  test:
+    name: Test (Go ${{ matrix.go }})
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        go:
+          - "1.25"
+          - "1.26"
+          - "stable"
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Set up Go
+        uses: actions/setup-go@v6
+        with:
+          go-version: ${{ matrix.go }}
+
+      - name: Verify dependencies
+        run: |
+          go mod verify
+          go mod download
+
+      - name: Check go mod tidy
+        run: |
+          go mod tidy
+          git diff --exit-code go.mod go.sum
+
+      - name: Build
+        run: go build ./...
+
+      - name: Run tests
+        run: go test -v -race -shuffle=on -coverprofile=coverage.out ./...
+
+      - name: Upload coverage
+        if: matrix.go == 'stable'
+        uses: codecov/codecov-action@v5
+        with:
+          files: ./coverage.out
+          fail_ci_if_error: false
+          token: ${{ secrets.CODECOV_TOKEN }}
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/evals/evals.json
new file mode 100644
index 00000000..ffcc6f3f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/evals/evals.json
@@ -0,0 +1,251 @@
+[
+  {
+    "id": 1,
+    "name": "test-workflow-flags",
+    "description": "Tests whether CI test workflows include all required flags (-race, -shuffle, -coverprofile) and use fail-fast: false",
+    "prompt": "Create a GitHub Actions workflow file for running Go tests on a library that supports Go 1.25+. The project uses codecov for coverage. Just give me the YAML.",
+    "trap": "Model may omit -shuffle=on, forget fail-fast: false, or skip the go mod tidy check",
+    "assertions": [
+      {"id": "1.1", "text": "Workflow includes -race flag in the go test command"},
+      {"id": "1.2", "text": "Workflow includes -shuffle=on flag in the go test command"},
+      {"id": "1.3", "text": "Workflow includes -coverprofile flag in the go test command"},
+      {"id": "1.4", "text": "Strategy uses fail-fast: false"},
+      {"id": "1.5", "text": "Go version matrix includes at least 'stable' and one explicit version like '1.25' or '1.26'"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "go-mod-tidy-check",
+    "description": "Tests whether the workflow enforces go mod tidy consistency via git diff --exit-code",
+    "prompt": "I want to make sure our Go CI catches cases where someone forgot to run go mod tidy before pushing. How should I add this check to our GitHub Actions workflow?",
+    "trap": "Model may suggest running go mod tidy without the git diff --exit-code step to actually fail the build on changes",
+    "assertions": [
+      {"id": "2.1", "text": "Suggests running 'go mod tidy' as a CI step"},
+      {"id": "2.2", "text": "Includes 'git diff --exit-code' after go mod tidy to detect uncommitted changes"},
+      {"id": "2.3", "text": "The git diff checks go.mod and/or go.sum specifically, or uses a general git diff --exit-code"},
+      {"id": "2.4", "text": "Also includes 'go mod verify' or 'go mod download' step"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "integration-test-caching",
+    "description": "Tests knowledge that integration tests must use -count=1 to disable caching",
+    "prompt": "I have integration tests that interact with PostgreSQL and Redis via GitHub Actions service containers. Sometimes tests pass even when the services are broken because Go seems to cache test results. How do I set up the workflow?",
+    "trap": "Model may not know about -count=1 to disable test caching, or may suggest other workarounds",
+    "assertions": [
+      {"id": "3.1", "text": "Uses -count=1 flag to disable test result caching"},
+      {"id": "3.2", "text": "Includes -race flag for integration tests"},
+      {"id": "3.3", "text": "Uses build tags (e.g., -tags=integration) to separate integration tests"},
+      {"id": "3.4", "text": "Uses GitHub Actions 'services' block for PostgreSQL and/or Redis"},
+      {"id": "3.5", "text": "Includes health check options for service containers"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "security-scanning-pipeline",
+    "description": "Tests whether the model recommends the full security stack: govulncheck, gosec, CodeQL, and Bearer",
+    "prompt": "I want to add security scanning to my Go project's CI pipeline. What tools should I use and how do I set them up in GitHub Actions?",
+    "trap": "Model may only suggest one or two tools (e.g., just gosec) and miss govulncheck (call-path-aware), CodeQL (Security tab integration), or Bearer (sensitive data flow)",
+    "assertions": [
+      {"id": "4.1", "text": "Recommends govulncheck and explains it only reports vulnerabilities in actually-called code paths"},
+      {"id": "4.2", "text": "Recommends gosec for Go security scanning"},
+      {"id": "4.3", "text": "Recommends CodeQL and mentions the security-extended or security-and-quality query suite"},
+      {"id": "4.4", "text": "Recommends Bearer for sensitive data flow issues"},
+      {"id": "4.5", "text": "Workflow includes security-events: write permission for SARIF upload"},
+      {"id": "4.6", "text": "Suggests creating a CodeQL config file to use an extended query suite rather than just the default"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "dependabot-grouping-strategy",
+    "description": "Tests whether Dependabot config groups minor/patch updates but keeps major updates separate",
+    "prompt": "Set up Dependabot for my Go project on GitHub. I want automated dependency update PRs for Go modules, GitHub Actions, and Docker base images.",
+    "trap": "Model may not group minor/patch into a single PR, or may group all updates including majors which could have breaking changes",
+    "assertions": [
+      {"id": "5.1", "text": "Configures Dependabot for gomod package ecosystem"},
+      {"id": "5.2", "text": "Configures Dependabot for github-actions package ecosystem"},
+      {"id": "5.3", "text": "Configures Dependabot for docker package ecosystem"},
+      {"id": "5.4", "text": "Groups minor and patch Go module updates into a single PR"},
+      {"id": "5.5", "text": "Major updates are NOT grouped (individual PRs for breaking changes)"},
+      {"id": "5.6", "text": "Sets a weekly schedule"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "dependabot-auto-merge-security",
+    "description": "Tests awareness of security implications in auto-merge workflow (elevated permissions, actor guard, branch protection as safety net)",
+    "prompt": "I want Dependabot PRs to auto-merge when CI passes, but only for minor and patch updates. Create the workflow. What security concerns should I be aware of?",
+    "trap": "Model may create the workflow without the github.actor guard, without mentioning elevated permissions risk, or without recommending branch protection as the real safety net",
+    "assertions": [
+      {"id": "6.1", "text": "Workflow has 'if: github.actor == dependabot[bot]' guard to restrict execution"},
+      {"id": "6.2", "text": "Workflow checks metadata to exclude major updates from auto-merge"},
+      {"id": "6.3", "text": "Warns about contents: write and pull-requests: write being elevated/high-risk permissions"},
+      {"id": "6.4", "text": "Mentions branch protection rules as the real safety net (not just the actor guard)"},
+      {"id": "6.5", "text": "Notes that github.actor checks are not fully spoof-proof"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "renovate-vs-dependabot",
+    "description": "Tests knowledge of Renovate advantages over Dependabot",
+    "prompt": "I'm using Dependabot for my Go monorepo with multiple modules but it's creating too many PRs and doesn't run go mod tidy. What are my options?",
+    "trap": "Model may suggest workarounds for Dependabot rather than recommending Renovate with its gomodTidy, native automerge, and monorepo support",
+    "assertions": [
+      {"id": "7.1", "text": "Recommends Renovate as an alternative to Dependabot"},
+      {"id": "7.2", "text": "Mentions Renovate's gomodTidy feature (automatic go mod tidy after updates)"},
+      {"id": "7.3", "text": "Mentions Renovate's native automerge without needing a separate workflow"},
+      {"id": "7.4", "text": "Mentions Renovate's monorepo/workspace support"},
+      {"id": "7.5", "text": "Mentions Renovate's better grouping rules"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "goreleaser-library-vs-cli",
+    "description": "Tests knowledge that GoReleaser config differs significantly between libraries and CLI programs",
+    "prompt": "I need to set up GoReleaser for my Go project which is a library (no main package). How should I configure it?",
+    "trap": "Model may generate a full GoReleaser config with builds, archives, and cross-compilation that doesn't apply to libraries",
+    "assertions": [
+      {"id": "8.1", "text": "Uses 'skip: true' in the builds section since libraries don't produce binaries"},
+      {"id": "8.2", "text": "Keeps the config minimal (mainly changelog generation)"},
+      {"id": "8.3", "text": "Mentions that for libraries, a simple GitHub Release via gh release create may be sufficient without GoReleaser"},
+      {"id": "8.4", "text": "Does NOT include cross-compilation (goos/goarch) in the library config"},
+      {"id": "8.5", "text": "Includes changelog configuration"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "docker-workflow-security",
+    "description": "Tests awareness of Docker workflow security: push: false on PRs, per-job permissions, dual registry, provenance/SBOM",
+    "prompt": "Create a GitHub Actions workflow that builds a multi-platform Docker image and pushes it to GHCR. Include security best practices.",
+    "trap": "Model may push images on PRs (allowing untrusted code to publish), use overly broad permissions, or skip provenance/SBOM attestations",
+    "assertions": [
+      {"id": "9.1", "text": "Sets push to false on pull requests to prevent untrusted code from publishing images"},
+      {"id": "9.2", "text": "Uses per-job permissions scoping (not just top-level)"},
+      {"id": "9.3", "text": "Includes QEMU and Buildx setup for multi-platform builds"},
+      {"id": "9.4", "text": "Includes provenance and/or SBOM attestation configuration"},
+      {"id": "9.5", "text": "Includes packages: write permission for GHCR push"},
+      {"id": "9.6", "text": "Login step is conditional on non-PR events"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "permissions-least-privilege",
+    "description": "Tests whether the model follows least-privilege permissions principle and sets GITHUB_TOKEN to read-only by default",
+    "prompt": "I'm setting up CI for a new open-source Go project. What GitHub repository settings should I configure for security? I already have the workflow files.",
+    "trap": "Model may focus only on branch protection and miss workflow permissions, fork PR restrictions, and environment-based approval gates",
+    "assertions": [
+      {"id": "10.1", "text": "Recommends setting default GITHUB_TOKEN to read-only at the repository level"},
+      {"id": "10.2", "text": "Recommends branch protection with required status checks"},
+      {"id": "10.3", "text": "Recommends requiring PR approvals (at least 1)"},
+      {"id": "10.4", "text": "Recommends dismissing stale approvals when new commits are pushed"},
+      {"id": "10.5", "text": "Recommends restricting fork PR workflows for outside collaborators"},
+      {"id": "10.6", "text": "Warns against pull_request_target with untrusted code"},
+      {"id": "10.7", "text": "Recommends creating a release environment with required reviewers"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "release-workflow-fetch-depth",
+    "description": "Tests whether the release workflow uses fetch-depth: 0 for changelog generation",
+    "prompt": "Create a GitHub Actions release workflow that triggers on version tags and runs GoReleaser to produce binaries and a changelog.",
+    "trap": "Model may use default checkout which does a shallow clone, causing GoReleaser to generate an incomplete or empty changelog",
+    "assertions": [
+      {"id": "11.1", "text": "Checkout step uses fetch-depth: 0 for full git history"},
+      {"id": "11.2", "text": "Workflow triggers on tag push with a v* pattern"},
+      {"id": "11.3", "text": "Uses contents: write permission for creating releases"},
+      {"id": "11.4", "text": "Passes GITHUB_TOKEN to GoReleaser"}
+    ]
+  },
+  {
+    "id": 12,
+    "name": "action-version-pinning",
+    "description": "Tests whether actions are pinned to major versions not branches",
+    "prompt": "Review this GitHub Actions step and tell me if there are any issues:\n\n```yaml\nsteps:\n  - uses: actions/checkout@master\n  - uses: actions/setup-go@main\n    with:\n      go-version: stable\n```",
+    "trap": "Model may not notice the branch references (@master, @main) instead of pinned major versions",
+    "assertions": [
+      {"id": "12.1", "text": "Identifies that using @master and @main is wrong and insecure"},
+      {"id": "12.2", "text": "Recommends pinning to major versions like @v4, @v6"},
+      {"id": "12.3", "text": "Explains the risk: branch references can change unexpectedly or be compromised"}
+    ]
+  },
+  {
+    "id": 13,
+    "name": "coverage-threshold-configuration",
+    "description": "Tests knowledge of codecov.yml configuration with project and patch targets",
+    "prompt": "I want to enforce that our Go project maintains at least 80% code coverage and that each PR doesn't drop coverage by more than 2%. How do I configure this?",
+    "trap": "Model may only configure project-level thresholds and miss patch-level coverage targets",
+    "assertions": [
+      {"id": "13.1", "text": "Configures codecov.yml (not just CLI flags) for coverage thresholds"},
+      {"id": "13.2", "text": "Sets project target to 80%"},
+      {"id": "13.3", "text": "Sets a threshold value (e.g., 2%) to allow small drops"},
+      {"id": "13.4", "text": "Configures patch coverage target for new code in PRs"},
+      {"id": "13.5", "text": "Coverage upload is conditional on a single matrix entry (e.g., only on stable)"}
+    ]
+  },
+  {
+    "id": 14,
+    "name": "ai-review-workflow-setup",
+    "description": "Tests whether the model recommends Claude Code Action or Copilot with skills for AI-driven PR review, rather than generic tools or manual checklists",
+    "prompt": "I want to add AI-powered code review to my Go project's CI pipeline. How do I set it up?",
+    "trap": "Model may suggest generic tools (CodeRabbit, PR-Agent, Reviewdog) or manual checklists instead of Claude Code Action / Copilot with Go skills loaded",
+    "assertions": [
+      {"id": "14.1", "text": "Recommends using anthropics/claude-code-action or GitHub Copilot for AI review"},
+      {"id": "14.2", "text": "Mentions installing Go skills via 'npx skills add' so the agent loads skill-based review guidelines"},
+      {"id": "14.3", "text": "Workflow includes pull-requests: write permission for inline PR comments"},
+      {"id": "14.4", "text": "References review areas mapped to specific Go skills (golang-security, golang-concurrency, etc.)"},
+      {"id": "14.5", "text": "References the claude-code-review.yml or copilot-review-instructions.md asset"}
+    ]
+  },
+  {
+    "id": 15,
+    "name": "ai-review-vs-linting",
+    "description": "Tests whether the model explains that AI review complements linting by catching issues linters cannot detect",
+    "prompt": "I already have golangci-lint, govulncheck, and CodeQL in my CI. Why would I also need AI code review?",
+    "trap": "Model may say linting is sufficient or treat AI review as a luxury, failing to explain the complementary value",
+    "assertions": [
+      {"id": "15.1", "text": "Explains that AI review catches architectural drift and logic bugs that static analysis misses"},
+      {"id": "15.2", "text": "Mentions at least one concrete example: missing error context, goroutine leaks, broken contracts, or design issues"},
+      {"id": "15.3", "text": "Positions AI review as a complement to linting, not a replacement"},
+      {"id": "15.4", "text": "Notes that AI agents loaded with Go skills apply the same expertise as a senior Go reviewer"}
+    ]
+  },
+  {
+    "id": 16,
+    "name": "ai-review-prompt-customization",
+    "description": "Tests whether the model explains how to scope the review prompt and apply the priority guidance",
+    "prompt": "Our Go project CI is slow. We want AI review but only for security and correctness issues — not style or documentation. How do we configure this?",
+    "trap": "Model may keep all 12 review areas or not know about the 4-job structure that can be selectively disabled",
+    "assertions": [
+      {"id": "16.1", "text": "Suggests removing or disabling the 'quality' job (style, naming, documentation) from the workflow"},
+      {"id": "16.2", "text": "Recommends keeping the 'correctness' and 'security' jobs as blocking-first areas"},
+      {"id": "16.3", "text": "Mentions the depth vs. speed tradeoff: fewer jobs = faster feedback, lower API cost"},
+      {"id": "16.4", "text": "References the priority guidance: Security, Code safety, Error handling, Concurrency are blocking-first"}
+    ]
+  },
+  {
+    "id": 17,
+    "name": "ai-review-claude-vs-copilot",
+    "description": "Tests whether the model clearly differentiates Claude Code Action (GitHub Actions workflow) from Copilot (copilot-instructions.md) and their respective setups",
+    "prompt": "We use both GitHub Copilot and Claude Code in our team. Can we use both for CI code review? What's the difference?",
+    "trap": "Model may conflate the two setups, not know about copilot-instructions.md, or miss that Claude uses /golang-* syntax while Copilot uses golang-* without slash",
+    "assertions": [
+      {"id": "17.1", "text": "Explains Claude Code review runs as a GitHub Actions workflow using anthropics/claude-code-action"},
+      {"id": "17.2", "text": "Explains Copilot review uses .github/copilot-instructions.md to configure the review prompt"},
+      {"id": "17.3", "text": "Notes that both require installing Go skills so the AI loads skill-based guidelines"},
+      {"id": "17.4", "text": "Correctly describes that both can coexist — they run independently and complement each other"}
+    ]
+  },
+  {
+    "id": 18,
+    "name": "ai-review-permissions-security",
+    "description": "Tests whether the model correctly identifies required permissions and security implications of the AI review workflow",
+    "prompt": "Our security team is concerned about giving an AI workflow write access to pull requests. What permissions does the Claude Code review workflow actually need and why?",
+    "trap": "Model may not know the minimal permission set, may suggest contents: write (too broad), or may not warn about fork PR risks",
+    "assertions": [
+      {"id": "18.1", "text": "Identifies pull-requests: write as required for posting inline review comments"},
+      {"id": "18.2", "text": "Identifies contents: read as sufficient for reading the repository code"},
+      {"id": "18.3", "text": "Does NOT suggest contents: write (that would be excessive for a review-only workflow)"},
+      {"id": "18.4", "text": "Warns about fork PR security: untrusted code in forks can access the ANTHROPIC_API_KEY secret if the workflow triggers on pull_request_target without careful guards"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/references/repo-security.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/references/repo-security.md
new file mode 100644
index 00000000..1fd40f2f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-continuous-integration/references/repo-security.md
@@ -0,0 +1,63 @@
+# Repository Security Settings
+
+After creating workflow files, repository security settings should be configured. These are not optional — they are the security foundation that makes the CI pipeline trustworthy.
+
+The project's GitHub URL can be determined from its git remote (e.g., `git remote -v`). For a project hosted at `https://github.com/{owner}/{repo}`, the relevant settings links are:
+
+- Branch protection: `https://github.com/{owner}/{repo}/settings/branches`
+- Actions permissions: `https://github.com/{owner}/{repo}/settings/actions`
+- Secrets: `https://github.com/{owner}/{repo}/settings/secrets/actions`
+- Environments: `https://github.com/{owner}/{repo}/settings/environments`
+
+These links allow direct navigation to the appropriate settings page.
+
+## Branch Protection Rules
+
+Configure a branch protection rule for `main` (or the default branch):
+
+1. **Require a pull request before merging** — prevents direct pushes to main
+2. **Require approvals** (at least 1) — no self-merging without review
+3. **Dismiss stale pull request approvals when new commits are pushed** — prevents approving then sneaking in changes
+4. **Require status checks to pass before merging** — add all CI workflow job names as required checks (e.g., `Test (Go 1.24)`, `Test (Go stable)`, `Lint`)
+5. **Require branches to be up to date before merging** — prevents merging stale PRs that haven't been tested against latest main
+6. **Do not allow bypassing the above settings** — applies rules to admins too
+
+## Workflow Permissions
+
+Set the default `GITHUB_TOKEN` to **read-only** at the repository level:
+
+1. Go to **Actions permissions** (link above)
+2. Workflow permissions MUST follow least privilege. Under **Workflow permissions**, select **"Read repository contents and packages permissions"**
+3. Uncheck **"Allow GitHub Actions to create and approve pull requests"** (unless auto-merge is needed — then check it only for that purpose)
+
+This means workflows start with no write access by default. Each workflow that needs elevated permissions must explicitly declare them in its `permissions:` block. This is defense-in-depth: if a workflow is compromised, it cannot write to the repository unless explicitly granted.
+
+## Fork Pull Request Restrictions
+
+For public/open-source repositories:
+
+1. In **Actions permissions** (link above), set **"Fork pull request workflows from outside collaborators"** to **"Require approval for all outside collaborators"**
+2. This prevents untrusted forks from running workflows that consume your Actions minutes or access secrets
+3. NEVER use `pull_request_target` with untrusted code — it runs with write access to the base repo
+
+## Secrets and Environments
+
+- Never put secrets in workflow files — use **Secrets** settings (link above)
+- For release workflows, create a **"release" environment** with required reviewers in **Environments** (link above) to add a manual approval gate before publishing
+- Rotate `CODECOV_TOKEN` and other third-party tokens periodically
+
+## Permissions Cheat Sheet
+
+The security implications of every permission used are documented below:
+
+| Permission | Workflows that need it | Risk |
+| --- | --- | --- |
+| `contents: read` | All workflows | **Low** — read-only, default safe |
+| `contents: write` | Release, auto-merge | **High** — can modify repo contents, create releases |
+| `packages: write` | Docker | **High** — can push container images to GHCR |
+| `pull-requests: write` | Auto-merge | **High** — can merge PRs, approve changes |
+| `attestations: write` | Docker | **Medium** — can create provenance/SBOM attestations |
+| `id-token: write` | Docker | **Medium** — OIDC token for signing attestations |
+| `security-events: write` | Security/SAST, Docker | **Medium** — can upload SARIF to Security tab |
+
+Always prefer the narrowest permission scope. If a workflow only needs `contents: read`, do not grant `contents: write`.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/SKILL.md
new file mode 100644
index 00000000..9479bb20
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/SKILL.md
@@ -0,0 +1,184 @@
+---
+name: golang-data-structures
+description: "Golang data structures — slices (internals, capacity growth, preallocation, slices package), maps (internals, hash buckets, maps package), arrays, container/list/heap/ring, strings.Builder vs bytes.Buffer, generic collections, pointers (unsafe.Pointer, weak.Pointer), and copy semantics. Use when choosing or optimizing Go data structures, implementing generic containers, using container/ packages, unsafe or weak pointers, or questioning slice/map internals."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.3"
+  openclaw:
+    emoji: "🗃"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent
+---
+
+**Persona:** You are a Go engineer who understands data structure internals. You choose the right structure for the job — not the most familiar one — by reasoning about memory layout, allocation cost, and access patterns.
+
+# Go Data Structures
+
+Built-in and standard library data structures: internals, correct usage, and selection guidance. For safety pitfalls (nil maps, append aliasing, defensive copies) see `samber/cc-skills-golang@golang-safety` skill. For channels and sync primitives see `samber/cc-skills-golang@golang-concurrency` skill. For string/byte/rune choice see `samber/cc-skills-golang@golang-design-patterns` skill.
+
+## Best Practices Summary
+
+1. **Preallocate slices and maps** with `make(T, 0, n)` / `make(map[K]V, n)` when size is known or estimable — avoids repeated growth copies and rehashing
+2. **Arrays** SHOULD be preferred over slices only for fixed, compile-time-known sizes (hash digests, IPv4 addresses, matrix dimensions)
+3. **NEVER rely on slice capacity growth timing** — the growth algorithm changed between Go versions and may change again; your code should not depend on when a new backing array is allocated
+4. **Use `container/heap`** for priority queues, **`container/list`** only when frequent middle insertions are needed, **`container/ring`** for fixed-size circular buffers
+5. **`strings.Builder`** MUST be preferred for building strings; **`bytes.Buffer`** MUST be preferred for bidirectional I/O (implements both `io.Reader` and `io.Writer`)
+6. Generic data structures SHOULD use the **tightest constraint** possible — `comparable` for keys, custom interfaces for ordering
+7. **`unsafe.Pointer`** MUST only follow the 6 valid conversion patterns from the Go spec — NEVER store in a `uintptr` variable across statements
+8. **`weak.Pointer[T]`** (Go 1.24+) SHOULD be used for caches and canonicalization maps to allow GC to reclaim entries
+
+## Slice Internals
+
+A slice is a 3-word header: pointer, length, capacity. Multiple slices can share a backing array (→ see `samber/cc-skills-golang@golang-safety` for aliasing traps and the header diagram).
+
+### Capacity Growth
+
+- < 256 elements: capacity doubles
+- > = 256 elements: grows by ~25% (`newcap += (newcap + 3*256) / 4`)
+- Each growth copies the entire backing array — O(n)
+
+### Preallocation
+
+```go
+// Exact size known
+users := make([]User, 0, len(ids))
+
+// Approximate size known
+results := make([]Result, 0, estimatedCount)
+
+// Pre-grow before bulk append (Go 1.21+)
+s = slices.Grow(s, additionalNeeded)
+```
+
+### `slices` Package (Go 1.21+)
+
+Key functions: `Sort`/`SortFunc`, `BinarySearch`, `Contains`, `Compact`, `Grow`. For `Clone`, `Equal`, `DeleteFunc` → see `samber/cc-skills-golang@golang-safety` skill.
+
+**[Slice Internals Deep Dive](./references/slice-internals.md)** — Full `slices` package reference, growth mechanics, `len` vs `cap`, header copying, backing array aliasing.
+
+## Map Internals
+
+Maps are hash tables with 8-entry buckets and overflow chains. They are reference types — assigning a map copies the pointer, not the data.
+
+### Preallocation
+
+```go
+m := make(map[string]*User, len(users)) // avoids rehashing during population
+```
+
+### `maps` Package Quick Reference (Go 1.21+)
+
+| Function          | Purpose                      |
+| ----------------- | ---------------------------- |
+| `Collect` (1.23+) | Build map from iterator      |
+| `Insert` (1.23+)  | Insert entries from iterator |
+| `All` (1.23+)     | Iterator over all entries    |
+| `Keys`, `Values`  | Iterators over keys/values   |
+
+For `Clone`, `Equal`, sorted iteration → see `samber/cc-skills-golang@golang-safety` skill.
+
+**[Map Internals Deep Dive](./references/map-internals.md)** — How Go maps store and hash data, bucket overflow chains, why maps never shrink (and what to do about it), comparing map performance to alternatives.
+
+## Arrays
+
+Fixed-size, value types. Copied entirely on assignment. Use for compile-time-known sizes:
+
+```go
+type Digest [32]byte           // fixed-size, value type
+var grid [3][3]int             // multi-dimensional
+cache := map[[2]int]Result{}   // arrays are comparable — usable as map keys
+```
+
+Prefer slices for everything else — arrays cannot grow and pass by value (expensive for large sizes).
+
+## container/ Standard Library
+
+| Package | Data Structure | Best For |
+| --- | --- | --- |
+| `container/list` | Doubly-linked list | LRU caches, frequent middle insertion/removal |
+| `container/heap` | Min-heap (priority queue) | Top-K, scheduling, Dijkstra |
+| `container/ring` | Circular buffer | Rolling windows, round-robin |
+| `bufio` | Buffered reader/writer/scanner | Efficient I/O with small reads/writes |
+
+Container types use `any` (no type safety) — consider generic wrappers. **[Container Patterns, bufio, and Examples](./references/containers.md)** — When to use each container type, generic wrappers to add type safety, and `bufio` patterns for efficient I/O.
+
+## strings.Builder vs bytes.Buffer
+
+Use `strings.Builder` for pure string concatenation (avoids copy on `String()`), `bytes.Buffer` when you need `io.Reader` or byte manipulation. Both support `Grow(n)`. **[Details and comparison](./references/containers.md)**
+
+## Generic Collections (Go 1.18+)
+
+Use the tightest constraint possible. `comparable` for map keys, `cmp.Ordered` for sorting, custom interfaces for domain-specific ordering.
+
+```go
+type Set[T comparable] map[T]struct{}
+
+func (s Set[T]) Add(v T)          { s[v] = struct{}{} }
+func (s Set[T]) Contains(v T) bool { _, ok := s[v]; return ok }
+```
+
+**[Writing Generic Data Structures](./references/generics.md)** — Using Go 1.18+ generics for type-safe containers, understanding constraint satisfaction, and building domain-specific generic types.
+
+## Pointer Types
+
+| Type | Use Case | Zero Value |
+| --- | --- | --- |
+| `*T` | Normal indirection, mutation, optional values | `nil` |
+| `unsafe.Pointer` | FFI, low-level memory layout (6 spec patterns only) | `nil` |
+| `weak.Pointer[T]` (1.24+) | Caches, canonicalization, weak references | N/A |
+
+**[Pointer Types Deep Dive](./references/pointers.md)** — Normal pointers, `unsafe.Pointer` (the 6 valid spec patterns), and `weak.Pointer[T]` for GC-safe caches that don't prevent cleanup.
+
+## Copy Semantics Quick Reference
+
+| Type | Copy Behavior | Independence |
+| --- | --- | --- |
+| `int`, `float`, `bool`, `string` | Value (deep copy) | Fully independent |
+| `array`, `struct` | Value (deep copy) | Fully independent |
+| `slice` | Header copied, backing array shared | Use `slices.Clone` |
+| `map` | Reference copied | Use `maps.Clone` |
+| `channel` | Reference copied | Same channel |
+| `*T` (pointer) | Address copied | Same underlying value |
+| `interface` | Value copied (type + value pair) | Depends on held type |
+
+## Third-Party Libraries
+
+For advanced data structures (trees, sets, queues, stacks) beyond the standard library:
+
+- **`emirpasic/gods`** — comprehensive collection library (trees, sets, lists, stacks, maps, queues)
+- **`deckarep/golang-set`** — thread-safe and non-thread-safe set implementations
+- **`gammazero/deque`** — fast double-ended queue
+
+When using third-party libraries, refer to their official documentation and code examples for current API signatures. Context7 can help as a discoverability platform.
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-performance` skill for struct field alignment, memory layout optimization, and cache locality
+- → See `samber/cc-skills-golang@golang-safety` skill for nil map/slice pitfalls, append aliasing, defensive copying, `slices.Clone`/`Equal`
+- → See `samber/cc-skills-golang@golang-concurrency` skill for channels, `sync.Map`, `sync.Pool`, and all sync primitives
+- → See `samber/cc-skills-golang@golang-design-patterns` skill for `string` vs `[]byte` vs `[]rune`, iterators, streaming
+- → See `samber/cc-skills-golang@golang-structs-interfaces` skill for struct composition, embedding, and generics vs `any`
+- → See `samber/cc-skills-golang@golang-code-style` skill for slice/map initialization style
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Growing a slice in a loop without preallocation | Each growth copies the entire backing array — O(n) per growth. Use `make([]T, 0, n)` or `slices.Grow` |
+| Using `container/list` when a slice would suffice | Linked lists have poor cache locality (each node is a separate heap allocation). Benchmark first |
+| `bytes.Buffer` for pure string building | Buffer's `String()` copies the underlying bytes. `strings.Builder` avoids this copy |
+| `unsafe.Pointer` stored as `uintptr` across statements | GC can move the object between statements — the `uintptr` becomes a dangling reference |
+| Large struct values in maps (copying overhead) | Map access copies the entire value. Use `map[K]*V` for large value types to avoid the copy |
+
+## References
+
+- [Go Data Structures (Russ Cox)](https://research.swtch.com/godata)
+- [The Go Memory Model](https://go.dev/ref/mem)
+- [Effective Go](https://go.dev/doc/effective_go)
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/evals/evals.json
new file mode 100644
index 00000000..725b8ba6
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/evals/evals.json
@@ -0,0 +1,200 @@
+[
+  {
+    "id": 1,
+    "name": "buffer-for-io",
+    "description": "RenderAndStream must use strings.Builder with Grow pre-allocation, not += or strings.Join",
+    "task": "Write a function `RenderAndStream(w io.Writer, parts []string) error` in package `render`. It assembles all parts into a single output (joining with newlines), then streams the result to the provided io.Writer.\n\nA teammate suggests: 'Just use strings.Join(parts, \"\\n\") — it's one line and idiomatic.' Another says: 'Use bytes.Buffer, it's the standard Go buffer type.' Implement the most efficient approach and explain if either suggestion is correct.",
+    "assertions": [
+      { "id": "1.1", "text": "Uses strings.Builder (not bytes.Buffer) for string assembly — bytes.Buffer stores []byte and converting to string at the end requires a copy; strings.Builder writes directly to a string", "trap": "Model follows teammate's bytes.Buffer suggestion" },
+      { "id": "1.2", "text": "Calls b.Grow(totalSize) before writing parts — pre-allocating avoids repeated reallocation as the builder grows", "trap": "Model omits Grow even though size is known" },
+      { "id": "1.3", "text": "Does not use strings.Join — it allocates a new string; the goal is to write directly to io.Writer without a redundant intermediate string copy", "trap": "Model accepts the strings.Join suggestion" }
+    ]
+  },
+  {
+    "id": 2,
+    "name": "sorted-set",
+    "description": "SortedSet[T] must use cmp.Ordered, not a custom Ordered interface or comparable",
+    "task": "Write a `SortedSet[T]` in package `collections` that maintains elements in sorted order. Support Insert(T), Contains(T) bool, Min() (T, bool), Max() (T, bool), and Len() int. Elements must be orderable. Use binary search for efficiency.\n\nA teammate says: 'Define your own `Ordered` interface with a `Less(T) bool` method — it's more flexible and lets users supply custom comparison logic.' Another says: 'Just use `comparable` as the constraint — it works for any type that can be compared.' Which approach is correct?",
+    "assertions": [
+      { "id": "2.1", "text": "Uses `cmp.Ordered` constraint (from the cmp package), not `comparable` (too loose — no < operator) and not a custom Ordered interface with Less() method", "trap": "Model accepts teammate's custom interface or comparable suggestion" },
+      { "id": "2.2", "text": "Rejects the comparable suggestion — comparable only ensures == and != but not < or >, which are required for sorting", "trap": "Model uses comparable thinking it's sufficient for ordered operations" },
+      { "id": "2.3", "text": "Binary search for Insert/Contains using slices.BinarySearch or sort.SearchInts or equivalent O(log n) approach", "trap": "Model linear-scans" }
+    ]
+  },
+  {
+    "id": 3,
+    "name": "AddCleanup",
+    "description": "String intern with weak.Pointer + runtime.AddCleanup for auto map shrink",
+    "task": "Write a symbol table deduplicator in package `symbols` for Go 1.24+. `func Intern(s string) *string` returns a canonical pointer for equivalent strings. When all external references to the canonical string are dropped, it should be GC'd AND its map entry should be automatically removed (not just become a dead weak pointer — the map must shrink). Thread-safe.",
+    "assertions": [
+      { "id": "3.1", "text": "Uses `weak.Pointer` or `weak.Make`", "trap": "Without skill, model uses runtime.SetFinalizer instead of weak.Pointer" },
+      { "id": "3.2", "text": "Uses `runtime.AddCleanup` (not SetFinalizer)", "trap": "Without skill, model defaults to the more error-prone SetFinalizer pattern" },
+      { "id": "3.3", "text": "Dead map entries automatically removed", "trap": "none — both approaches can achieve this" }
+    ]
+  },
+  {
+    "id": 4,
+    "name": "unsafe.Add-modern",
+    "description": "Read packed binary header using modern unsafe.Add (Go 1.17+)",
+    "task": "Write a function `ReadFields(data []byte) (magic uint32, version uint16, length uint32)` in package `proto` that reads a packed binary header. The header layout is: 4 bytes magic, 2 bytes version, 2 bytes padding, 4 bytes length. Use unsafe pointer arithmetic to access each field at its offset. Target Go 1.17+.",
+    "assertions": [
+      { "id": "4.1", "text": "Uses `unsafe.Add` for pointer arithmetic", "trap": "Without skill, model uses old-style uintptr(base) + offset casting" },
+      { "id": "4.2", "text": "No intermediate `uintptr` variable", "trap": "Model might split pointer arithmetic across statements" },
+      { "id": "4.3", "text": "Bounds check before unsafe access", "trap": "none — baseline safety" }
+    ]
+  },
+  {
+    "id": 5,
+    "name": "full-slice-expr",
+    "description": "SplitIntoChunks with full-slice expression to prevent append aliasing",
+    "task": "Write a function `SplitIntoChunks(data []byte, chunkSize int) [][]byte` in package `chunker`. Split data into chunks of chunkSize bytes (last chunk may be smaller). IMPORTANT: callers will independently append to each returned chunk, so chunks must not share backing arrays — appending to one chunk must never corrupt another.",
+    "assertions": [
+      { "id": "5.1", "text": "Chunks are append-safe (no aliasing)", "trap": "none — both approaches achieve this" },
+      { "id": "5.2", "text": "Uses full-slice expression `[:n:n]`", "trap": "Without skill, model uses make+copy per chunk instead of zero-alloc full-slice" },
+      { "id": "5.3", "text": "Minimal extra allocations (reuses backing array)", "trap": "Without skill, model allocates N fresh arrays instead of reusing original" }
+    ]
+  },
+  {
+    "id": 6,
+    "name": "list-valid-use",
+    "description": "OrderedMap with O(1) middle deletion — valid container/list use case",
+    "task": "Write an `OrderedMap[K comparable, V any]` in package `ordmap` that preserves insertion order AND supports O(1) deletion by key. Methods: Set(key K, value V), Get(key K) (V, bool), Delete(key K), Keys() []K (in insertion order). When a key is deleted from the middle, the insertion order of remaining keys must be preserved without shifting.",
+    "assertions": [
+      { "id": "6.1", "text": "Uses `container/list` from stdlib", "trap": "Without skill, model builds custom generic linked list instead of using stdlib" },
+      { "id": "6.2", "text": "Map stores `*list.Element` for O(1) access", "trap": "none — both approaches use map for lookup" },
+      { "id": "6.3", "text": "Delete is O(1) via element reference", "trap": "none — both approaches achieve O(1) delete" }
+    ]
+  },
+  {
+    "id": 7,
+    "name": "composite-struct-key",
+    "description": "Route cache keyed by (method, path) — struct key vs string encoding",
+    "task": "Write an HTTP route cache in package `router`. The cache maps (method, path) pairs to handler names. Implement Set(method, path, handler string) and Get(method, path string) (string, bool). Millions of lookups per second — optimize for zero-allocation lookups.",
+    "assertions": [
+      { "id": "7.1", "text": "Uses struct or array as map key", "trap": "Without skill, model concatenates strings (method+':'+path) or uses complex encoding" },
+      { "id": "7.2", "text": "Zero allocation on lookup path", "trap": "Without skill, model uses string concatenation (allocates) or complex unsafe tricks" },
+      { "id": "7.3", "text": "Simple, readable key type", "trap": "Without skill, model over-engineers with sync.Map + unsafe stack string hacks" }
+    ]
+  },
+  {
+    "id": 8,
+    "name": "map-memory-diag",
+    "description": "Maps never shrink — the only fix is rebuilding; GC hints and nil-assignment are insufficient",
+    "task": "A Go service processes events. During traffic spikes, `var eventIndex map[string]*Event` grows to 10M entries. After the spike, events expire and are deleted, leaving ~1000 entries. But RSS memory stays at 2GB. The team added `delete(eventIndex, key)` for every expired event — why doesn't memory decrease?\n\nTwo teammates propose fixes:\n- Alice: 'Call `runtime.GC()` after bulk deletes — it will force the GC to reclaim unused map memory.'\n- Bob: 'Set `eventIndex = nil` and then reassign `eventIndex = make(map[string]*Event)` — that releases the old map to the GC.'\n\nAre either of these correct? Write a `Diagnose()` comment and a `Compact()` method on `EventStore` that correctly fixes the issue. Package `events`.",
+    "assertions": [
+      { "id": "8.1", "text": "Correctly diagnoses root cause: Go maps never shrink their bucket array — delete() removes entries but the allocated bucket memory is retained, preventing GC of the backing structure" },
+      { "id": "8.2", "text": "Evaluates Bob's nil-reassign approach: correctly identifies this as valid — setting eventIndex = nil releases the old map to GC, and rebuilding with make creates a fresh small map" },
+      { "id": "8.3", "text": "Evaluates Alice's runtime.GC() approach: correctly identifies this as insufficient alone — GC cannot reclaim a live map's bucket array; the map itself must be rebuilt" },
+      { "id": "8.4", "text": "Compact() creates a fresh map with make and copies surviving entries — rebuilding is the only way to reclaim bucket memory from a Go map" }
+    ]
+  },
+  {
+    "id": 9,
+    "name": "ring-round-robin",
+    "description": "LoadBalancer cycling backends using container/ring",
+    "task": "Write a `LoadBalancer` in package `lb` that distributes requests across backends using round-robin. NewLoadBalancer(backends []string) *LoadBalancer creates the balancer. Next() string returns the next backend in rotation, cycling forever. The balancer must work correctly even after billions of calls (no integer overflow on counter).",
+    "assertions": [
+      { "id": "9.1", "text": "Uses `container/ring` for round-robin", "trap": "Without skill, model uses atomic counter with modulo (also valid but not stdlib)" },
+      { "id": "9.2", "text": "No integer overflow risk", "trap": "none — both ring (no counter) and uint64 modulo (safe wrap) avoid overflow" },
+      { "id": "9.3", "text": "Correct rotation on each call", "trap": "none — baseline correctness" }
+    ]
+  },
+  {
+    "id": 10,
+    "name": "large-struct-ptr",
+    "description": "DocumentStore with 20-field struct — pointer map needed",
+    "task": "Write a `DocumentStore` in package `docs`. Document has 20 fields: ID, Title, Author, Body, Summary, Category, Tags []string, CreatedAt, UpdatedAt, PublishedAt time.Time, ViewCount, LikeCount, CommentCount int, Draft bool, Locale, Slug, MetaTitle, MetaDescription, CanonicalURL, RevisionID string. The store is read-heavy (100:1 read:write). Implement Add(doc Document), Get(id string) (*Document, bool), Update(id string, doc Document).",
+    "assertions": [
+      { "id": "10.1", "text": "Uses pointer map `map[string]*Document`", "trap": "Without skill, model uses value map — copies 500+ byte struct on every read" },
+      { "id": "10.2", "text": "Get returns stored pointer (no copy)", "trap": "Without skill, model copies from value map and takes & of copy" },
+      { "id": "10.3", "text": "Uses `sync.RWMutex` for concurrent reads", "trap": "none — baseline concurrency" }
+    ]
+  },
+  {
+    "id": 11,
+    "name": "small-struct-val",
+    "description": "CoordTracker with 16-byte Coord — value map preferred over pointer",
+    "task": "Write a `CoordTracker` in package `geo`. It tracks millions of active GPS positions. Coord has Lat, Lon float64 (16 bytes total). Implement Update(id string, lat, lon float64), Position(id string) (Coord, bool), Remove(id string). Optimize the internal map for maximum read throughput given the tiny struct size.",
+    "assertions": [
+      { "id": "11.1", "text": "Uses value map `map[string]Coord` (not pointer)", "trap": "Model might over-optimize with pointer map for 'millions' of entries" },
+      { "id": "11.2", "text": "Explains < 128-byte threshold for value vs pointer choice", "trap": "Without skill, model doesn't articulate the size-based tradeoff" },
+      { "id": "11.3", "text": "Proportional complexity for struct size", "trap": "Without skill, model may over-engineer with sharding for a simple case" }
+    ]
+  },
+  {
+    "id": 12,
+    "name": "clip-after-delete",
+    "description": "PurgeInactive with slices.DeleteFunc + Clip to release dead references",
+    "task": "Write a function `PurgeInactive(users []User) []User` in package `cleanup`. User has ID string, Active bool, and Profile []byte (can be several MB). Remove all inactive users. The returned slice must not hold references to any inactive User's Profile data in its excess capacity. Users are typically 90% inactive after a bulk import.",
+    "assertions": [
+      { "id": "12.1", "text": "No dead references in result slice", "trap": "none — both approaches achieve this" },
+      { "id": "12.2", "text": "Uses `slices.DeleteFunc` + `slices.Clip`", "trap": "Without skill, model uses manual loop + make instead of modern slices package" },
+      { "id": "12.3", "text": "Excess capacity released", "trap": "none — both approaches release excess" }
+    ]
+  },
+  {
+    "id": 13,
+    "name": "heap-priority-queue",
+    "description": "Task scheduler using container/heap — tests knowledge of heap.Interface and heap.Fix",
+    "task": "Write a `TaskScheduler` in package `scheduler` that executes tasks in priority order. Each Task has ID string, Priority int (lower = higher priority), and ExecuteAt time.Time. Implement Schedule(task Task), Next() (Task, bool), and UpdatePriority(id string, newPriority int). UpdatePriority must efficiently re-order the task without removing and re-adding it.",
+    "assertions": [
+      { "id": "13.1", "text": "Implements heap.Interface (Len, Less, Swap, Push, Pop) on a custom type", "trap": "Without skill, model might use a sorted slice with re-sort on every insert" },
+      { "id": "13.2", "text": "Uses heap.Fix for UpdatePriority (O(log n)) instead of removing and re-adding", "trap": "Without skill, model removes + re-pushes (O(n + log n)) or re-sorts (O(n log n))" },
+      { "id": "13.3", "text": "Maintains an index map (id -> position in heap) for O(1) lookup before Fix", "trap": "Without skill, model linear-scans the heap to find the task by ID" },
+      { "id": "13.4", "text": "Calls heap.Init before first use", "trap": "Model might forget initialization" },
+      { "id": "13.5", "text": "Next() uses heap.Pop (not direct slice access and removal)", "trap": "Model might read [0] and manually remove" }
+    ]
+  },
+  {
+    "id": 14,
+    "name": "growth-independence",
+    "description": "Tests that code does not depend on specific slice growth factor",
+    "task": "Write a Go function `EstimateAllocations(n int) int` in package `bench` that returns how many times the backing array will be reallocated when appending n elements one-by-one to an initially empty slice. Your implementation must work correctly on Go 1.20, Go 1.21, and any future Go version.",
+    "assertions": [
+      { "id": "14.1", "text": "Does NOT hardcode a growth factor (e.g., assumes doubling or 1.25x) in the calculation", "trap": "Without skill, model assumes doubling below some threshold and 1.25x above" },
+      { "id": "14.2", "text": "Uses an actual append loop to empirically measure allocations, OR explicitly states the growth algorithm may change between versions", "trap": "Model might implement a formula based on current Go runtime behavior" },
+      { "id": "14.3", "text": "Comments or documents that the slice growth algorithm is an implementation detail not guaranteed by the spec", "trap": "Without skill, model presents the growth formula as a reliable contract" },
+      { "id": "14.4", "text": "Does NOT rely on the 256-element threshold as a stable boundary", "trap": "Model might treat the threshold as a spec guarantee" },
+      { "id": "14.5", "text": "Suggests preallocation as the solution to avoid depending on growth behavior", "trap": "Without skill, model tries to predict growth exactly" }
+    ]
+  },
+  {
+    "id": 15,
+    "name": "array-as-map-key",
+    "description": "Tests when to use arrays (comparable, value type) as map keys vs slices",
+    "task": "Write a `PixelCache` in package `imaging` that caches computed color values for pixel coordinates. Coordinates are (x, y) integer pairs. The cache is used in a rendering pipeline processing millions of pixels. Implement Set(x, y int, color uint32) and Get(x, y int) (uint32, bool). Optimize for lookup speed.",
+    "assertions": [
+      { "id": "15.1", "text": "Uses [2]int array or a struct{X,Y int} as the map key (not string encoding or nested maps)", "trap": "Without skill, model might use fmt.Sprintf(\"%d,%d\") or map[int]map[int]uint32" },
+      { "id": "15.2", "text": "Key type is comparable (arrays and all-comparable-field structs satisfy this)", "trap": "Model might try to use a slice as a map key" },
+      { "id": "15.3", "text": "Zero allocation on lookup path (no string formatting)", "trap": "Without skill, model formats a string key per lookup" },
+      { "id": "15.4", "text": "Uses value map (uint32 is 4 bytes — pointer overhead not justified)", "trap": "Model might use *uint32 for no reason" },
+      { "id": "15.5", "text": "Preallocates map if estimated size is available", "trap": "Model might skip preallocation for a hot-path cache" }
+    ]
+  },
+  {
+    "id": 16,
+    "name": "bufio-scanner-limit",
+    "description": "Tests knowledge of bufio.Scanner's 64KB default token limit",
+    "task": "Write a function `ParseLogFile(r io.Reader) ([]LogEntry, error)` in package `logs`. Each log line is a JSON object. Some log entries contain large base64-encoded payloads and can be up to 2MB per line. Parse all lines and return the entries.",
+    "assertions": [
+      { "id": "16.1", "text": "Uses bufio.Scanner for line-by-line reading", "trap": "Without skill, model might use bufio.NewReader + ReadString or ReadBytes" },
+      { "id": "16.2", "text": "Calls scanner.Buffer() to increase the max token size beyond the 64KB default", "trap": "Without skill, model uses default Scanner which silently truncates or errors on lines > 64KB" },
+      { "id": "16.3", "text": "Sets buffer size to at least 2MB to accommodate the large lines", "trap": "Model might use Scanner without adjusting buffer, failing on large lines" },
+      { "id": "16.4", "text": "Checks scanner.Err() after the scan loop", "trap": "Model might ignore scanner errors" },
+      { "id": "16.5", "text": "Unmarshals each line as JSON into LogEntry struct", "trap": "None — baseline correctness" }
+    ]
+  },
+  {
+    "id": 17,
+    "name": "generics-when-not-to-use",
+    "description": "Tests judgment about when generics are NOT appropriate",
+    "task": "Write a Go HTTP response helper package `respond`. It needs: RespondJSON(w, status, data) that marshals any data to JSON, RespondError(w, status, message) that sends an error JSON, and RespondNoContent(w) that sends 204. A teammate suggests making it generic: `Respond[T any](w, status, data T)`. Should you use generics here? Implement the best approach.",
+    "assertions": [
+      { "id": "17.1", "text": "Does NOT make RespondJSON generic with a type parameter (any constraint with json.Marshal makes generics pointless — it's just interface{} with extra syntax)", "trap": "Without skill, model accepts the teammate's generic suggestion" },
+      { "id": "17.2", "text": "Uses `any` or `interface{}` parameter directly for the data argument", "trap": "Model might use generics just because the prompt suggests it" },
+      { "id": "17.3", "text": "Explains WHY generics are not appropriate here (any constraint means no type-specific behavior, json.Marshal already accepts any)", "trap": "Without skill, model adds generics without questioning the value" },
+      { "id": "17.4", "text": "Mentions that generics shine for containers/algorithms where type safety adds value, not for serialization", "trap": "Model might not articulate the distinction" },
+      { "id": "17.5", "text": "Implementation is straightforward without type parameters", "trap": "None — baseline" }
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/containers.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/containers.md
new file mode 100644
index 00000000..6d6e57b5
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/containers.md
@@ -0,0 +1,98 @@
+# Container Packages and String Builders
+
+## container/list — Doubly-Linked List
+
+A general-purpose doubly-linked list. Elements hold `any` values (no type safety).
+
+### Time Complexity
+
+| Operation | Complexity | Notes |
+| --- | --- | --- |
+| **Insert at front/back** | O(1) | `PushFront()`, `PushBack()` |
+| **Remove front/back** | O(1) | `l.Remove(l.Front())`, `l.Remove(l.Back())` |
+| **Insert at arbitrary position** | O(1) | If you have the element reference (`*Element`) |
+| **Remove at arbitrary position** | O(1) | If you have the element reference |
+| **Access by index** | O(n) | Must walk the chain — no random access |
+| **Search for value** | O(n) | Linear scan required |
+
+### When to Use
+
+- LRU cache implementations (O(1) move-to-front)
+- Ordered collections with frequent insertion/removal at arbitrary positions
+- When you need stable iterators that survive insertions
+
+### When NOT to Use
+
+Slices outperform linked lists for most use cases due to cache locality. If you only append/remove from the ends, use a slice or a deque. Also avoid if you need O(1) random access by index.
+
+### Use Cases
+
+- LRU cache implementations (O(1) move-to-front with element reference)
+- Ordered task queues with frequent arbitrary insertions/removals (if mutations happen frequently)
+- Undo/redo stacks with stable element references
+- Sliding window algorithms where elements are frequently added/removed from both ends
+
+## container/heap — Priority Queue
+
+An interface-based min-heap. You provide a type implementing `heap.Interface` (which embeds `sort.Interface` plus `Push`/`Pop`).
+
+### Time Complexity
+
+| Operation | Complexity | Notes |
+| --- | --- | --- |
+| **heap.Push** | O(log n) | Appends and bubbles up |
+| **heap.Pop** | O(log n) | Removes root, moves last to root, bubbles down |
+| **heap.Init** | O(n) | Builds heap from unsorted slice in linear time |
+| **heap.Fix** | O(log n) | Re-heapifies after priority change |
+| **Peek (access root)** | O(1) | Direct access to `pq[0]` |
+| **Search for value** | O(n) | No indexed lookup — must scan all items |
+
+### Space Complexity
+
+O(n) — stores all items in a backing slice. The heap is an array-based structure, not a tree of pointers.
+
+### Use Cases
+
+- Task scheduling (dequeue highest-priority tasks)
+- Dijkstra's algorithm (repeatedly pop minimum-distance node)
+- Huffman coding (repeatedly pop two smallest frequencies)
+- Event processing (process events in time order)
+- A\* pathfinding (explore nodes with lowest f-cost)
+- Load balancing (process requests from server with lowest load)
+
+## container/ring — Circular Buffer
+
+A fixed-size circular linked list. Useful for rolling windows and round-robin scheduling.
+
+```go
+// Rolling average of last 5 values
+r := ring.New(5)
+for _, v := range values {
+    r.Value = v
+    r = r.Next()
+}
+
+sum := 0.0
+r.Do(func(v any) {
+    if v != nil {
+        sum += v.(float64)
+    }
+})
+avg := sum / float64(r.Len())
+```
+
+## bufio — Buffered I/O
+
+`bufio` wraps `io.Reader` and `io.Writer` with an internal buffer, reducing system call overhead for frequent small reads/writes. Use `NewReader()` / `NewWriter()` for default 4096-byte buffers, or `NewReaderSize()` / `NewWriterSize()` for custom sizes.
+
+**bufio.Reader & Writer:** Call `Flush()` explicitly on writers and check its error. Buffered data is not written until flush or the buffer is full; ignoring a flush error can silently lose data.
+
+**bufio.Scanner:** Convenient line-by-line reading with `scanner.Scan()` and `scanner.Text()`. Default max token size is 64 KB; call `scanner.Buffer()` to increase for larger lines.
+
+## strings.Builder vs bytes.Buffer
+
+**strings.Builder:** Optimized for building strings. `String()` returns the accumulated string without copying. Use for concatenating string parts. `Reset()` discards the buffer.
+
+**bytes.Buffer:** Implements both `io.Reader` and `io.Writer`. Use for I/O operations, encoding/decoding, or when you need both read and write. `Reset()` reuses the allocated memory.
+
+**Choose Builder for string concatenation, Buffer for I/O operations or buffer reuse in pools.**
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/generics.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/generics.md
new file mode 100644
index 00000000..8ea9d527
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/generics.md
@@ -0,0 +1,90 @@
+# Writing Generic Data Structures (Go 1.18+)
+
+## Type Constraints
+
+Use the tightest constraint that satisfies your needs:
+
+| Constraint | What It Allows | Use For |
+| --- | --- | --- |
+| `any` | All types | Containers that only store/retrieve |
+| `comparable` | Types supporting `==` and `!=` | Map keys, set membership, dedup |
+| `cmp.Ordered` | Numeric types + `string` | Sorting, min/max, binary search |
+| Custom interface | Domain-specific operations | Specialized containers |
+
+### Custom Constraints
+
+```go
+// Union constraint — restrict to specific types
+type Number interface {
+    ~int | ~int64 | ~float64
+}
+
+// Method constraint — require specific behavior
+type Stringer interface {
+    comparable
+    String() string
+}
+```
+
+The `~` prefix includes all types whose underlying type matches (e.g., `~int` matches `type UserID int`).
+
+## Generic Set Example
+
+```go
+type Set[T comparable] map[T]struct{}
+
+func NewSet[T comparable](vals ...T) Set[T] {
+    s := make(Set[T], len(vals))
+    for _, v := range vals {
+        s[v] = struct{}{}
+    }
+    return s
+}
+
+func (s Set[T]) Add(v T)             { s[v] = struct{}{} }
+func (s Set[T]) Remove(v T)          { delete(s, v) }
+func (s Set[T]) Contains(v T) bool   { _, ok := s[v]; return ok }
+func (s Set[T]) Len() int            { return len(s) }
+
+func (s Set[T]) Union(other Set[T]) Set[T] {
+    result := NewSet[T]()
+    for v := range s {
+        result.Add(v)
+    }
+    for v := range other {
+        result.Add(v)
+    }
+    return result
+}
+```
+
+## Generic Sorted Slice
+
+```go
+func InsertSorted[T cmp.Ordered](s []T, v T) []T {
+    i, _ := slices.BinarySearch(s, v)
+    return slices.Insert(s, i, v)
+}
+```
+
+## Constraint Composition
+
+Combine multiple constraints with embedded interfaces:
+
+```go
+type OrderedStringer interface {
+    cmp.Ordered
+    fmt.Stringer
+}
+```
+
+## When NOT to Use Generics
+
+- **Single concrete type** — generics add complexity for no benefit
+- **`any` constraint with type switches** — you're just reimplementing `interface{}` with extra syntax
+- **Two or fewer instantiations** — the abstraction overhead isn't justified
+- **Complex type relationships** — Go's type system doesn't support higher-kinded types; if the constraints become convoluted, use interfaces instead
+
+Generics shine for data structures (containers, sets, trees), algorithms (sort, search, transform), and utility functions (min, max, clamp) where the logic is identical across types.
+
+→ See `samber/cc-skills-golang@golang-structs-interfaces` skill for generics vs `any` guidance and interface design.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/map-internals.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/map-internals.md
new file mode 100644
index 00000000..8756ea32
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/map-internals.md
@@ -0,0 +1,67 @@
+# Map Internals Deep Dive
+
+## Hash Table Structure
+
+Go maps use hash tables with bucket-based collision resolution. The map header holds:
+
+- `count` — number of entries
+- `B` — log₂ of bucket count (2^B buckets total)
+- `buckets` — pointer to bucket array
+- `oldbuckets` — pointer to old buckets during growth
+
+Each bucket holds 8 key-value pairs. Keys and values are stored in separate arrays within buckets to minimize padding waste.
+
+## Memory Growth and Capacity
+
+- **Load factor threshold**: 6.5 entries per bucket triggers growth (sweet spot between memory efficiency and collision performance)
+- **Overflow bucket chains** also trigger growth if too long (prevents O(1)→O(n) degradation)
+- **Bucket count doubles**: 2^B → 2^(B+1) (efficient rehashing with powers of 2)
+- **Incremental evacuation**: Old and new buckets coexist during growth; entries move lazily during operations to avoid GC pauses
+- **No `cap()` function**: Capacity depends on hash distribution and load factor, not a fixed limit. Preallocation (`make(map[string]int, expectedSize)`) is worthwhile for large maps to avoid repeated growth cycles
+
+## Preallocation
+
+```go
+// Without preallocation — multiple growths as entries are added
+m := map[string]int{}
+
+// With preallocation — allocates enough buckets upfront
+m := make(map[string]int, expectedSize)
+```
+
+Preallocation avoids repeated growths. The hint is approximate — Go allocates 2^B buckets where 2^B \* 6.5 >= hint.
+
+## Pointers vs Values
+
+For large value types, storing pointers reduces copy overhead:
+
+```go
+// Large struct — copied on every read/write
+m := map[string]BigStruct{}  // copies large struct
+
+// Pointer — only pointer is copied
+m := map[string]*BigStruct{} // copies 8-byte pointer
+```
+
+Trade-off: pointer maps add GC pressure. For small structs (< 128 bytes), value maps are typically faster.
+
+## `maps` Package (Go 1.21+)
+
+| Function | Description |
+| --- | --- |
+| `Clone`, `Equal`, `EqualFunc` | Shallow copy and equality comparison |
+| `Keys`, `Values`, `All` (1.23+) | Iterators over keys, values, or pairs |
+| `Collect`, `Insert` (1.23+) | Build maps from iterators or insert entries |
+
+See `samber/cc-skills-golang@golang-safety` skill for `Clone`, `Equal`, and sorted iteration patterns.
+
+## Map Key Requirements
+
+Map keys must be comparable (`==` must work). This includes:
+
+- All numeric types, `string`, `bool`
+- Pointers, channels, interfaces (compared by identity)
+- Arrays of comparable types
+- Structs where all fields are comparable
+
+Slices, maps, and functions **cannot** be map keys.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/pointers.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/pointers.md
new file mode 100644
index 00000000..d9e7249f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/pointers.md
@@ -0,0 +1,118 @@
+# Pointer Types Deep Dive
+
+## Regular Pointers (`*T`)
+
+### Stack vs Heap (Escape Analysis)
+
+Go's compiler decides whether to allocate on the stack or heap. A variable "escapes" to the heap when its lifetime extends beyond the function:
+
+```go
+func noEscape() int {
+    x := 42
+    return x // x stays on stack — copied on return
+}
+
+func escapes() *int {
+    x := 42
+    return &x // x escapes to heap — pointer outlives function
+}
+```
+
+Use `go build -gcflags="-m"` to see escape analysis decisions. Heap allocations add GC pressure — avoid unnecessary escapes in hot paths.
+
+### `new(T)` vs `&T{}`
+
+Both allocate and return a pointer. `&T{}` is preferred because it allows field initialization:
+
+```go
+p := new(Point)       // *Point with zero values
+p := &Point{X: 1}     // *Point with initialized fields — preferred
+```
+
+## `unsafe.Pointer`
+
+`unsafe.Pointer` bypasses Go's type system for FFI and low-level memory manipulation. Only the 6 patterns from the Go spec are safe; any other pattern is undefined behavior.
+
+### The 6 Valid Patterns (from the Go spec)
+
+These are the ONLY safe ways to use `unsafe.Pointer`. Any other pattern is undefined behavior.
+
+**Pattern 1: Convert `*T` to `*U` via `unsafe.Pointer`**
+
+```go
+// Reinterpret a float64 as its raw bits
+f := 1.5
+bits := *(*uint64)(unsafe.Pointer(&f))
+```
+
+**Pattern 2: Convert `unsafe.Pointer` to `uintptr` and back (same expression)**
+
+```go
+// Pointer arithmetic — MUST be a single expression
+p := unsafe.Pointer(uintptr(unsafe.Pointer(&s.field)) + offset)
+```
+
+**Pattern 3: `reflect.Value.Pointer()` or `UnsafeAddr()` to `unsafe.Pointer`**
+
+```go
+p := unsafe.Pointer(reflect.ValueOf(&x).Pointer())
+```
+
+**Pattern 4: `syscall.Syscall` arguments**
+
+```go
+syscall.Syscall(SYS_READ, fd, uintptr(unsafe.Pointer(&buf[0])), uintptr(len(buf)))
+```
+
+### Critical Rule: NEVER Store `uintptr` Across Statements
+
+```go
+// ✗ DANGEROUS — GC can move the object between these two lines
+u := uintptr(unsafe.Pointer(&x))
+// ... GC may run here, moving x ...
+p := unsafe.Pointer(u) // dangling pointer
+
+// ✓ Safe — single expression
+p := unsafe.Pointer(uintptr(unsafe.Pointer(&x)) + offset)
+```
+
+### Modern Alternatives (prefer these)
+
+| Function | Since | Purpose |
+| --- | --- | --- |
+| `unsafe.Add(ptr, len)` | Go 1.17 | Pointer arithmetic without `uintptr` conversion |
+| `unsafe.Slice(ptr, len)` | Go 1.17 | Create slice from pointer + length |
+| `unsafe.String(ptr, len)` | Go 1.20 | Create string from pointer + length |
+| `unsafe.SliceData(s)` | Go 1.17 | Get pointer to slice's backing array |
+| `unsafe.StringData(s)` | Go 1.20 | Get pointer to string's backing array |
+
+These are safer than manual `uintptr` arithmetic because they keep values as pointers (visible to GC) throughout.
+
+## `weak.Pointer[T]` (Go 1.24+)
+
+A weak pointer holds a reference to an object without preventing garbage collection. When the GC reclaims the object, `Value()` returns `nil`.
+
+```go
+strong := new(MyType)
+w := weak.Make(strong)
+
+if p := w.Value(); p != nil {
+    // object still alive
+} else {
+    // object was garbage collected
+}
+```
+
+### Use Cases
+
+- **Deduplication caches** — intern equivalent values without preventing GC
+- **Automatic cache eviction** — cached objects evict when no strong references remain
+
+### `runtime.AddCleanup` vs `runtime.SetFinalizer`
+
+Prefer `runtime.AddCleanup` (Go 1.24+) over `runtime.SetFinalizer`:
+
+- Multiple cleanups can be registered per object
+- Cleanup function receives a value, not a pointer to the collected object
+- No risk of resurrecting the object
+- Works correctly with weak pointers
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/slice-internals.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/slice-internals.md
new file mode 100644
index 00000000..ace3b801
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-data-structures/references/slice-internals.md
@@ -0,0 +1,55 @@
+# Slice Internals
+
+## Memory Layout
+
+A slice is a 24-byte header (3 machine words):
+
+- **Pointer** — points to backing array (heap-allocated)
+- **Length** — number of elements in use
+- **Capacity** — allocated size of backing array
+
+Assigning or passing a slice copies the 24-byte header, not the backing array. Both the original and copy point to the same underlying data—mutations are visible to both.
+
+## Capacity Growth
+
+When `append` exceeds capacity:
+
+- `oldCap < 256`: double capacity
+- `oldCap ≥ 256`: grow ~25% (`oldCap + (oldCap + 3*256) / 4`)
+
+### Growth Cost
+
+Each growth is O(n) — the entire array is copied to a new location. For a slice growing from 0 to N elements one at a time, the amortized cost per append is O(1), but the total copies are roughly 2N. **Preallocation eliminates all intermediate copies:**
+
+```go
+// Known size — direct indexing
+out := make([]Result, len(input))
+for i, v := range input {
+    out[i] = transform(v)
+}
+
+// Approximate size
+out := make([]Result, 0, len(input)*2)
+for _, v := range input {
+    out = append(out, transform(v))
+}
+```
+
+## `slices` Package (Go 1.21+)
+
+| Category | Key Functions |
+| --- | --- |
+| **Sort** | `Sort`, `SortFunc`, `SortStableFunc`, `IsSorted` |
+| **Search** | `BinarySearch`, `BinarySearchFunc`, `Contains`, `Index`, `IndexFunc` |
+| **Mutate** | `Insert`, `Delete`, `Replace`, `Compact`, `Reverse`, `Grow`, `Clip` |
+| **Create** | `Concat` (1.22+), `Repeat` (1.23+), `Chunk` (1.23+) |
+| **Compare** | `Clone`, `Equal`, `EqualFunc`, `Compare`, `DeleteFunc` |
+
+## `copy()` vs `append()` vs `slices.Clone()`
+
+| Operation             | Use When                         |
+| --------------------- | -------------------------------- |
+| `copy(dst, src)`      | Copying into pre-allocated slice |
+| `append(dst, src...)` | Appending to a slice             |
+| `slices.Clone(s)`     | Creating independent copy        |
+| `s[:len(s):len(s)]`   | Preventing append aliasing       |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/SKILL.md
new file mode 100644
index 00000000..99350149
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/SKILL.md
@@ -0,0 +1,243 @@
+---
+name: golang-database
+description: "Comprehensive guide for Go database access — parameterized queries, struct scanning, NULLable columns, transactions, isolation levels, SELECT FOR UPDATE, connection pool, batch processing, context propagation, and migration tooling. Use when writing, reviewing, or debugging Golang code that interacts with PostgreSQL, MariaDB, MySQL, or SQLite; for database testing; or for questions about database/sql, sqlx, or pgx. Does NOT generate database schemas or migration SQL."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.1"
+  openclaw:
+    emoji: "🗄"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion
+---
+
+**Persona:** You are a Go backend engineer who writes safe, explicit, and observable database code. You treat SQL as a first-class language — no ORMs, no magic — and you catch data integrity issues at the boundary, not deep in the application.
+
+**Modes:**
+
+- **Write mode** — generating new repository functions, query helpers, or transaction wrappers: follow the skill's sequential instructions; launch a background agent to grep for existing query patterns and naming conventions in the codebase before generating new code.
+- **Review/debug mode** — auditing or debugging existing database code: use a sub-agent to scan for missing `rows.Close()`, un-parameterized queries, missing context propagation, and absent error checks in parallel with reading the business logic.
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-database` skill takes precedence.
+
+# Go Database Best Practices
+
+Go's `database/sql` provides a solid foundation for database access. Use `sqlx` or `pgx` on top of it for ergonomics — never an ORM.
+
+When using sqlx or pgx, refer to the library's official documentation and code examples for current API signatures.
+
+## Best Practices Summary
+
+1. **Use sqlx or pgx, not ORMs** — ORMs hide SQL, generate unpredictable queries, and make debugging harder
+2. Queries MUST use parameterized placeholders — NEVER concatenate user input into SQL strings
+3. Context MUST be passed to all database operations — use `*Context` method variants (`QueryContext`, `ExecContext`, `GetContext`)
+4. `sql.ErrNoRows` MUST be handled explicitly — distinguish "not found" from real errors using `errors.Is`
+5. Rows MUST be closed after iteration — `defer rows.Close()` immediately after `QueryContext` calls
+6. NEVER use `db.Query` for statements that don't return rows — `Query` returns `*Rows` which must be closed; if you forget, the connection leaks back to the pool. Use `db.Exec` instead
+7. **Use transactions for multi-statement operations** — wrap related writes in `BeginTxx`/`Commit`
+8. **Use `SELECT ... FOR UPDATE`** when reading data you intend to modify — prevents race conditions
+9. **Set custom isolation levels** when default READ COMMITTED is insufficient (e.g., serializable for financial operations)
+10. **Handle NULLable columns** with pointer fields (`*string`, `*int`) or `sql.NullXxx` types
+11. Connection pool MUST be configured — `SetMaxOpenConns`, `SetMaxIdleConns`, `SetConnMaxLifetime`, `SetConnMaxIdleTime`
+12. **Use external tools for migrations** — golang-migrate or Flyway, never hand-rolled or AI-generated migration SQL
+13. **Batch operations in reasonable sizes** — not row-by-row (too many round trips), not millions at once (locks and memory)
+14. **Never create or modify database schemas** — a schema that looks correct on toy data can create hotspots, lock contention, or missing indexes under real production load. Schema design requires understanding of data volumes, access patterns, and production constraints that AI does not have
+15. **Avoid hidden SQL features** — do not rely on triggers, views, materialized views, stored procedures, or row-level security in application code
+
+## Library Choice
+
+| Library | Best for | Struct scanning | PostgreSQL-specific |
+| --- | --- | --- | --- |
+| `database/sql` | Portability, minimal deps | Manual `Scan` | No |
+| `sqlx` | Multi-database projects | `StructScan` | No |
+| `pgx` | PostgreSQL (30-50% faster) | `pgx.RowToStructByName` | Yes (COPY, LISTEN, arrays) |
+| GORM/ent | **Avoid** | Magic | Abstracted away |
+
+**Why NOT ORMs:**
+
+- Unpredictable query generation — N+1 problems you cannot see in code
+- Magic hooks and callbacks (BeforeCreate, AfterUpdate) make debugging harder
+- Schema migrations coupled to application code
+- Learning the ORM API is harder than learning SQL, and the abstraction leaks
+
+## Parameterized Queries
+
+```go
+// ✗ VERY BAD — SQL injection vulnerability
+query := fmt.Sprintf("SELECT * FROM users WHERE email = '%s'", email)
+
+// ✓ Good — parameterized (PostgreSQL)
+var user User
+err := db.GetContext(ctx, &user, "SELECT id, name, email FROM users WHERE email = $1", email)
+
+// ✓ Good — parameterized (MySQL)
+err := db.GetContext(ctx, &user, "SELECT id, name, email FROM users WHERE email = ?", email)
+```
+
+### Dynamic IN clauses
+
+```go
+query, args, err := sqlx.In("SELECT * FROM users WHERE id IN (?)", ids)
+if err != nil {
+    return fmt.Errorf("building IN clause: %w", err)
+}
+query = db.Rebind(query) // adjust placeholders for your driver
+err = db.SelectContext(ctx, &users, query, args...)
+```
+
+### Dynamic column names
+
+Never interpolate column names from user input. Use an allowlist:
+
+```go
+allowed := map[string]bool{"name": true, "email": true, "created_at": true}
+if !allowed[sortCol] {
+    return fmt.Errorf("invalid sort column: %s", sortCol)
+}
+query := fmt.Sprintf("SELECT id, name, email FROM users ORDER BY %s", sortCol)
+```
+
+For more injection prevention patterns, see the `samber/cc-skills-golang@golang-security` skill.
+
+## Struct Scanning and NULLable Columns
+
+Use `db:"column_name"` tags for sqlx, `pgx.CollectRows` with `pgx.RowToStructByName` for pgx. Handle NULLable columns with pointer fields (`*string`, `*time.Time`) — they work cleanly with both scanning and JSON marshaling. See [Scanning Reference](./references/scanning.md) for examples of all approaches.
+
+## Error Handling
+
+```go
+func GetUser(id string) (*User, error) {
+    var user User
+
+    err := db.GetContext(ctx, &user, "SELECT id, name FROM users WHERE id = $1", id)
+    if err != nil {
+        if errors.Is(err, sql.ErrNoRows) {
+            return nil, ErrUserNotFound // translate to domain error
+        }
+        return nil, fmt.Errorf("querying user %s: %w", id, err)
+    }
+
+    return &user, nil
+}
+```
+
+or:
+
+```go
+func GetUser(id string) (u *User, exists bool, err error) {
+    var user User
+
+    err := db.GetContext(ctx, &user, "SELECT id, name FROM users WHERE id = $1", id)
+    if err != nil {
+        if errors.Is(err, sql.ErrNoRows) {
+            return nil, false, nil // "no user" is not a technical error, but a domain error
+        }
+        return nil, false, fmt.Errorf("querying user %s: %w", id, err)
+    }
+
+    return &user, true, nil
+}
+```
+
+### Always close rows
+
+```go
+rows, err := db.QueryContext(ctx, "SELECT id, name FROM users")
+if err != nil {
+    return fmt.Errorf("querying users: %w", err)
+}
+defer rows.Close() // prevents connection leaks
+
+for rows.Next() {
+    // ...
+}
+if err := rows.Err(); err != nil { // always check after iteration
+    return fmt.Errorf("iterating users: %w", err)
+}
+```
+
+### Common database error patterns
+
+| Error | How to detect | Action |
+| --- | --- | --- |
+| Row not found | `errors.Is(err, sql.ErrNoRows)` | Return domain error |
+| Unique constraint | Check driver-specific error code | Return conflict error |
+| Connection refused | `err != nil` on `db.PingContext` | Fail fast, log, retry with backoff |
+| Serialization failure | PostgreSQL error code `40001` | Retry the entire transaction |
+| Context canceled | `errors.Is(err, context.Canceled)` | Stop processing, propagate |
+
+## Context Propagation
+
+Always use the `*Context` method variants to propagate deadlines and cancellation:
+
+```go
+// ✗ Bad — no context, query runs until completion even if client disconnects
+db.Query("SELECT ...")
+
+// ✓ Good — respects context cancellation and timeouts
+db.QueryContext(ctx, "SELECT ...")
+```
+
+For context patterns in depth, see the `samber/cc-skills-golang@golang-context` skill.
+
+## Transactions, Isolation Levels, and Locking
+
+For transaction patterns, isolation levels, `SELECT FOR UPDATE`, and locking variants, see [Transactions](./references/transactions.md).
+
+## Connection Pool
+
+```go
+db.SetMaxOpenConns(25)              // limit total connections
+db.SetMaxIdleConns(10)              // keep warm connections ready
+db.SetConnMaxLifetime(5 * time.Minute)  // recycle stale connections
+db.SetConnMaxIdleTime(1 * time.Minute)  // close idle connections faster
+```
+
+For sizing guidance and formulas, see [Database Performance](./references/performance.md).
+
+## Migrations
+
+Use an external migration tool. Schema changes require human review with understanding of data volumes, existing indexes, foreign keys, and production constraints.
+
+Recommended tools:
+
+- [golang-migrate](https://github.com/golang-migrate/migrate) — CLI + Go library, supports all major databases
+- [Flyway](https://flywaydb.org/) — JVM-based, widely used in enterprise environments
+- [Atlas](https://atlasgo.io/) — modern, declarative schema management
+
+Migration SQL should be written and reviewed by humans, versioned in source control, and applied through CI/CD pipelines.
+
+## Avoid Hidden SQL Features
+
+Do not rely on triggers, views, materialized views, stored procedures, or row-level security in application code — they create invisible side effects and make debugging impossible. Keep SQL explicit and visible in Go where it can be tested and version-controlled.
+
+## Schema Creation
+
+**This skill does NOT cover schema creation.** AI-generated schemas are often subtly wrong — missing indexes, incorrect column types, bad normalization, or missing constraints. Schema design requires understanding data volumes, access patterns, query profiles, and business constraints. Use dedicated database tooling and human review.
+
+## Deep Dives
+
+- **[Transactions](./references/transactions.md)** — Transaction boundaries, isolation levels, deadlock prevention, `SELECT FOR UPDATE`
+- **[Testing Database Code](./references/testing.md)** — Mock connections, integration tests with containers, fixtures, schema setup/teardown
+- **[Database Performance](./references/performance.md)** — Connection pool sizing, batch processing, indexing strategy, query optimization
+- **[Struct Scanning](./references/scanning.md)** — Struct tags, NULLable column handling, JSON marshaling patterns
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-security` skill for SQL injection prevention patterns
+- → See `samber/cc-skills-golang@golang-context` skill for context propagation to database operations
+- → See `samber/cc-skills-golang@golang-error-handling` skill for database error wrapping patterns
+- → See `samber/cc-skills-golang@golang-testing` skill for database integration test patterns
+
+## References
+
+- [database/sql tutorial](https://go.dev/doc/database/)
+- [sqlx](https://github.com/jmoiron/sqlx)
+- [pgx](https://github.com/jackc/pgx)
+- [golang-migrate](https://github.com/golang-migrate/migrate)
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/evals/evals.json
new file mode 100644
index 00000000..559c9cc4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/evals/evals.json
@@ -0,0 +1,211 @@
+[
+  {
+    "id": 1,
+    "name": "orm-vs-sqlx-pgx-recommendation",
+    "description": "Tests whether the model recommends sqlx/pgx over ORMs and explains why ORMs are harmful",
+    "prompt": "I'm starting a new Go web application with PostgreSQL. I need to set up database access. What library should I use? I've heard GORM is popular and has good docs. Can you set up the database layer for me?",
+    "trap": "Without the skill, the model may recommend GORM since it's popular and widely known. The skill explicitly says to avoid ORMs and use sqlx or pgx.",
+    "assertions": [
+      {"id": "1.1", "text": "Recommends sqlx or pgx instead of GORM"},
+      {"id": "1.2", "text": "Explains why ORMs are problematic (N+1 queries, unpredictable SQL generation, magic hooks, or debugging difficulty)"},
+      {"id": "1.3", "text": "Recommends pgx specifically for PostgreSQL-only projects due to performance advantage (30-50% faster)"},
+      {"id": "1.4", "text": "Does NOT set up GORM or ent as the primary database library"},
+      {"id": "1.5", "text": "Mentions that learning the ORM API is harder than learning SQL or that ORMs hide SQL"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "exec-vs-query-for-non-select",
+    "description": "Tests the subtle rule that db.Query must NOT be used for statements that don't return rows",
+    "prompt": "Write a Go function that deletes expired sessions from a PostgreSQL database. Use sqlx. The function should delete all sessions where expires_at < now() and return the number of deleted rows.",
+    "trap": "The model may use db.QueryContext or db.Query for the DELETE statement, which returns *Rows that must be closed. The skill says to use db.Exec for statements that don't return rows.",
+    "assertions": [
+      {"id": "2.1", "text": "Uses ExecContext (not QueryContext or Query) for the DELETE statement"},
+      {"id": "2.2", "text": "Uses the *Context variant (ExecContext, not Exec)"},
+      {"id": "2.3", "text": "Passes ctx to the database call"},
+      {"id": "2.4", "text": "Retrieves RowsAffected() from the result to return the count"},
+      {"id": "2.5", "text": "Uses parameterized query (not string concatenation)"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "nullable-column-handling",
+    "description": "Tests whether pointer fields are preferred for NULLable columns over sql.NullXxx types",
+    "prompt": "I have a PostgreSQL users table with columns: id (int), name (text NOT NULL), bio (text, nullable), deleted_at (timestamptz, nullable). Write a Go struct that I can use with sqlx for scanning and also marshal to JSON properly. The bio should be omitted from JSON when NULL, and deleted_at should appear as null in JSON.",
+    "trap": "Without the skill, the model may use sql.NullString and sql.NullTime which require custom JSON marshaling. The skill recommends pointer fields as the cleanest approach.",
+    "assertions": [
+      {"id": "3.1", "text": "Uses pointer types (*string for bio, *time.Time for deleted_at) rather than sql.NullString/sql.NullTime"},
+      {"id": "3.2", "text": "Includes db struct tags for sqlx (db:\"column_name\")"},
+      {"id": "3.3", "text": "Includes json struct tags"},
+      {"id": "3.4", "text": "Uses json:\"bio,omitempty\" for bio (omitted when NULL)"},
+      {"id": "3.5", "text": "Uses json:\"deleted_at\" without omitempty for deleted_at (appears as null)"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "connection-pool-configuration",
+    "description": "Tests that connection pool settings are configured with all four parameters and reasonable values",
+    "prompt": "Write a Go function that creates a new sqlx database connection to PostgreSQL and returns *sqlx.DB. Just the basic setup, nothing fancy.",
+    "trap": "Without the skill, the model often returns the *sqlx.DB without configuring the connection pool. The skill requires all four pool settings.",
+    "assertions": [
+      {"id": "4.1", "text": "Calls SetMaxOpenConns on the database connection"},
+      {"id": "4.2", "text": "Calls SetMaxIdleConns on the database connection"},
+      {"id": "4.3", "text": "Calls SetConnMaxLifetime on the database connection"},
+      {"id": "4.4", "text": "Calls SetConnMaxIdleTime on the database connection"},
+      {"id": "4.5", "text": "MaxIdleConns is less than or equal to MaxOpenConns"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "rows-close-and-err-check",
+    "description": "Tests proper handling of rows iteration: defer Close and rows.Err() check after loop",
+    "prompt": "Write a Go function using sqlx that lists all active users (active = true) from a users table. Return a slice of User structs. Use db.QueryContext, not db.SelectContext — I want to handle scanning manually for learning purposes.",
+    "trap": "Without the skill, the model may forget to defer rows.Close() or skip the rows.Err() check after iteration, both of which are required.",
+    "assertions": [
+      {"id": "5.1", "text": "Calls defer rows.Close() immediately after the QueryContext call (before the loop)"},
+      {"id": "5.2", "text": "Checks rows.Err() after the for rows.Next() loop completes"},
+      {"id": "5.3", "text": "Returns the error from rows.Err() if non-nil"},
+      {"id": "5.4", "text": "Uses QueryContext (not Query) with a context parameter"},
+      {"id": "5.5", "text": "Checks the error returned by QueryContext before proceeding"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "errnorows-handling-pattern",
+    "description": "Tests proper sql.ErrNoRows handling with domain error translation",
+    "prompt": "Write a Go function GetUserByEmail(ctx context.Context, db *sqlx.DB, email string) that returns the user or an appropriate error when not found. Use sqlx.GetContext.",
+    "trap": "Without the skill, the model may return the raw sql.ErrNoRows error directly or not distinguish it from other errors. The skill requires translating to a domain error.",
+    "assertions": [
+      {"id": "6.1", "text": "Uses errors.Is(err, sql.ErrNoRows) to check for not-found"},
+      {"id": "6.2", "text": "Returns a domain-specific error (e.g. ErrUserNotFound) when no rows, NOT the raw sql.ErrNoRows"},
+      {"id": "6.3", "text": "Wraps non-ErrNoRows errors with context using fmt.Errorf and %w"},
+      {"id": "6.4", "text": "Uses GetContext (not Get) with the ctx parameter"},
+      {"id": "6.5", "text": "Uses parameterized query placeholder ($1 or ?) not string concatenation"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "transaction-with-defer-rollback",
+    "description": "Tests the correct transaction pattern: BeginTxx, defer Rollback, Commit",
+    "prompt": "Write a Go function TransferFunds(ctx, db, fromAccountID, toAccountID string, amount int) that transfers money between two accounts atomically. Use sqlx.",
+    "trap": "Without the skill, the model may forget defer tx.Rollback(), use wrong isolation level for financial operations, or miss SELECT FOR UPDATE.",
+    "assertions": [
+      {"id": "7.1", "text": "Uses BeginTxx (or BeginTx) to start a transaction"},
+      {"id": "7.2", "text": "Calls defer tx.Rollback() immediately after BeginTxx"},
+      {"id": "7.3", "text": "Uses SELECT ... FOR UPDATE when reading balances to prevent race conditions"},
+      {"id": "7.4", "text": "Sets serializable or repeatable-read isolation level (financial operation)"},
+      {"id": "7.5", "text": "Calls tx.Commit() at the end of the successful path"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "dynamic-in-clause-with-rebind",
+    "description": "Tests proper handling of dynamic IN clauses with sqlx.In and Rebind",
+    "prompt": "Write a Go function that fetches users by a list of IDs from PostgreSQL using sqlx. The function receives a []int64 of user IDs.",
+    "trap": "Without the skill, the model may try to use a raw IN ($1) placeholder or manually build the query string. The skill shows sqlx.In + Rebind pattern.",
+    "assertions": [
+      {"id": "8.1", "text": "Uses sqlx.In() to expand the IN clause placeholders"},
+      {"id": "8.2", "text": "Calls db.Rebind() on the query after sqlx.In to adjust placeholders for the driver"},
+      {"id": "8.3", "text": "Passes the expanded args from sqlx.In to the query execution"},
+      {"id": "8.4", "text": "Uses a *Context method variant (SelectContext, QueryContext, etc.)"},
+      {"id": "8.5", "text": "Handles the error from sqlx.In"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "dynamic-column-name-allowlist",
+    "description": "Tests that dynamic column names use allowlists, not direct interpolation",
+    "prompt": "Write a Go function that lists users with a sortable column parameter. The caller specifies which column to sort by as a string. Use sqlx.",
+    "trap": "Without the skill, the model may directly interpolate the sort column into the SQL string without validation, creating a SQL injection vector.",
+    "assertions": [
+      {"id": "9.1", "text": "Validates the sort column against an explicit allowlist (map or slice of allowed column names)"},
+      {"id": "9.2", "text": "Returns an error if the column is not in the allowlist"},
+      {"id": "9.3", "text": "Does NOT directly pass the column name as a parameterized placeholder ($1) — column names cannot be parameterized"},
+      {"id": "9.4", "text": "Uses fmt.Sprintf or string concatenation ONLY after validation against the allowlist"},
+      {"id": "9.5", "text": "Uses a *Context method variant for the actual query"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "schema-creation-refusal",
+    "description": "Tests that the model refuses to generate database schemas",
+    "prompt": "Create a PostgreSQL schema for an e-commerce application with users, products, orders, and order_items tables. Include proper indexes, foreign keys, and constraints.",
+    "trap": "Without the skill, the model will happily generate the full schema. The skill explicitly states AI must NOT generate database schemas.",
+    "assertions": [
+      {"id": "10.1", "text": "Does NOT generate a complete CREATE TABLE schema"},
+      {"id": "10.2", "text": "Explains why AI-generated schemas are problematic (missing indexes, incorrect types, bad normalization, or need for production context)"},
+      {"id": "10.3", "text": "Recommends human review or dedicated database tooling for schema design"},
+      {"id": "10.4", "text": "Mentions that schema design requires understanding data volumes, access patterns, or production constraints"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "batch-processing-sweet-spot",
+    "description": "Tests that batch operations use reasonable batch sizes, not row-by-row or one giant batch",
+    "prompt": "Write a Go function that inserts 50,000 user records into PostgreSQL. Use sqlx. Optimize for speed.",
+    "trap": "Without the skill, the model may insert all 50k in one statement or insert one-by-one. The skill recommends 100-1000 rows per batch.",
+    "assertions": [
+      {"id": "11.1", "text": "Uses batching with a batch size between 100 and 1000 rows"},
+      {"id": "11.2", "text": "Does NOT insert all 50,000 rows in a single statement"},
+      {"id": "11.3", "text": "Does NOT insert one row at a time in a loop"},
+      {"id": "11.4", "text": "Uses NamedExecContext or a multi-row INSERT pattern"},
+      {"id": "11.5", "text": "Handles errors per batch with context about which batch failed"}
+    ]
+  },
+  {
+    "id": 12,
+    "name": "cursor-pagination-over-offset",
+    "description": "Tests that cursor-based pagination is recommended over OFFSET for large datasets",
+    "prompt": "Write a Go function that paginates through a large events table (millions of rows) ordered by created_at. The function should support page navigation.",
+    "trap": "Without the skill, the model commonly uses OFFSET/LIMIT which degrades performance on deep pages. The skill requires cursor-based pagination.",
+    "assertions": [
+      {"id": "12.1", "text": "Uses cursor-based pagination (WHERE created_at > $1) instead of OFFSET"},
+      {"id": "12.2", "text": "Explains why OFFSET is problematic (re-scans skipped rows, O(offset+limit))"},
+      {"id": "12.3", "text": "Uses LIMIT with ORDER BY for the page size"},
+      {"id": "12.4", "text": "Returns a cursor value (e.g. the last created_at) for the next page"},
+      {"id": "12.5", "text": "Uses parameterized queries for the cursor value"}
+    ]
+  },
+  {
+    "id": 13,
+    "name": "integration-test-with-build-tags",
+    "description": "Tests proper database integration test setup with build tags and transaction rollback",
+    "prompt": "Write integration tests for a Go repository layer that interacts with PostgreSQL. I want to test that Create and GetByID work correctly together.",
+    "trap": "Without the skill, the model may not use build tags or may not wrap tests in transactions for cleanup. The skill requires both.",
+    "assertions": [
+      {"id": "13.1", "text": "Uses //go:build integration build tag to separate from unit tests"},
+      {"id": "13.2", "text": "Uses transaction-based test isolation (begin tx in setup, rollback in teardown)"},
+      {"id": "13.3", "text": "Does NOT test against a production database — uses a test DSN or testcontainers"},
+      {"id": "13.4", "text": "Uses testify/suite or a similar setup/teardown pattern"},
+      {"id": "13.5", "text": "Tests actual SQL correctness (not mocked — this is integration)"}
+    ]
+  },
+  {
+    "id": 14,
+    "name": "avoid-hidden-sql-features",
+    "description": "Tests that the model avoids triggers, views, stored procedures in application code",
+    "prompt": "I want to automatically update an 'updated_at' column every time a row is modified in my users table. Should I create a PostgreSQL trigger for this? Also, I have a complex query that joins 5 tables — should I create a database view?",
+    "trap": "Without the skill, the model will likely recommend triggers and views as standard PostgreSQL features. The skill says to avoid hidden SQL features.",
+    "assertions": [
+      {"id": "14.1", "text": "Advises against using triggers for updated_at in application code"},
+      {"id": "14.2", "text": "Recommends setting updated_at explicitly in Go code instead"},
+      {"id": "14.3", "text": "Advises against using views for the complex query"},
+      {"id": "14.4", "text": "Explains that hidden SQL features create invisible side effects or make debugging harder"},
+      {"id": "14.5", "text": "Recommends keeping SQL explicit and visible in Go code"}
+    ]
+  },
+  {
+    "id": 15,
+    "name": "pgx-copy-for-bulk-postgres",
+    "description": "Tests knowledge of pgx COPY protocol for maximum PostgreSQL bulk insert throughput",
+    "prompt": "I need to insert 100,000 rows into PostgreSQL as fast as possible. I'm already using pgx. What's the fastest approach?",
+    "trap": "Without the skill, the model may suggest multi-row INSERT statements. The skill teaches pgx.CopyFrom using the binary COPY protocol for maximum throughput.",
+    "assertions": [
+      {"id": "15.1", "text": "Recommends pgx.CopyFrom using the COPY protocol"},
+      {"id": "15.2", "text": "Shows pgx.CopyFromRows or pgx.CopyFromSlice usage"},
+      {"id": "15.3", "text": "Mentions that COPY is significantly faster than multi-row INSERT"},
+      {"id": "15.4", "text": "Uses pgx.Identifier for the table name"},
+      {"id": "15.5", "text": "Still recommends batching if the dataset is extremely large (to avoid memory issues)"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/performance.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/performance.md
new file mode 100644
index 00000000..fbddd1f9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/performance.md
@@ -0,0 +1,212 @@
+# Database Performance
+
+## Connection Pool Sizing
+
+### Configuration
+
+```go
+db, err := sqlx.Connect("postgres", dsn)
+if err != nil {
+    return fmt.Errorf("connecting to database: %w", err)
+}
+
+db.SetMaxOpenConns(25)                  // total connections (match your DB capacity)
+db.SetMaxIdleConns(10)                  // keep connections warm, reduce handshake overhead
+db.SetConnMaxLifetime(5 * time.Minute)  // recycle connections (DNS changes, server restarts)
+db.SetConnMaxIdleTime(1 * time.Minute)  // release idle connections back to the pool
+```
+
+| Setting | Too low | Too high |
+| --- | --- | --- |
+| `MaxOpenConns` | Requests queue waiting for conn | DB overwhelmed, context switches |
+| `MaxIdleConns` | Cold connections, slow queries | Wasted memory holding idle conns |
+| `ConnMaxLifetime` | Frequent reconnection overhead | Stale connections after failover |
+| `ConnMaxIdleTime` | Same as MaxIdleConns too low | Idle conns consume server memory |
+
+### Monitoring
+
+Check pool stats in production to detect exhaustion:
+
+```go
+stats := db.Stats()
+slog.Info("db pool",
+    "open", stats.OpenConnections,
+    "in_use", stats.InUse,
+    "idle", stats.Idle,
+    "wait_count", stats.WaitCount,        // total waits for a connection
+    "wait_duration", stats.WaitDuration,  // total wait time
+)
+```
+
+If `WaitCount` keeps climbing, increase `MaxOpenConns` or optimize slow queries.
+
+### Prometheus Metrics
+
+Use a custom Prometheus collector to export pool metrics on-demand (scales to multiple pools automatically):
+
+```go
+type DBCollector struct {
+    pools map[string]*sqlx.DB
+}
+
+func NewDBCollector(pools map[string]*sqlx.DB) *DBCollector {
+    return &DBCollector{pools: pools}
+}
+
+func (c *DBCollector) Describe(ch chan<- *prometheus.Desc) {
+    ch <- prometheus.NewDesc("db_open_connections", "Number of open connections", []string{"pool"}, nil)
+    ch <- prometheus.NewDesc("db_in_use_connections", "Connections currently in use", []string{"pool"}, nil)
+    ch <- prometheus.NewDesc("db_idle_connections", "Idle connections in pool", []string{"pool"}, nil)
+    ch <- prometheus.NewDesc("db_total_latency_seconds", "Total latency for a connection", []string{"pool"}, nil)
+}
+
+func (c *DBCollector) Collect(ch chan<- prometheus.Metric) {
+    for poolName, db := range c.pools {
+        stats := db.Stats()
+
+        ch <- prometheus.MustNewConstMetric(
+            prometheus.NewDesc("db_open_connections", "Number of open connections", []string{"pool"}, nil),
+            prometheus.GaugeValue, float64(stats.OpenConnections), poolName)
+
+        ch <- prometheus.MustNewConstMetric(
+            prometheus.NewDesc("db_in_use_connections", "Connections currently in use", []string{"pool"}, nil),
+            prometheus.GaugeValue, float64(stats.InUse), poolName)
+
+        ch <- prometheus.MustNewConstMetric(
+            prometheus.NewDesc("db_idle_connections", "Idle connections in pool", []string{"pool"}, nil),
+            prometheus.GaugeValue, float64(stats.Idle), poolName)
+
+        ch <- prometheus.MustNewConstMetric(
+            prometheus.NewDesc("db_wait_duration_seconds_total", "Total connection wait duration", []string{"pool"}, nil),
+            prometheus.CounterValue, stats.WaitDuration.Seconds(), poolName)
+    }
+}
+
+func init() {
+    pools := map[string]*sqlx.DB{
+        "primary": mainDB,
+        "replica": replicaDB,
+    }
+    prometheus.MustRegister(NewDBCollector(pools))
+}
+```
+
+**Collector advantages:**
+
+- Metrics are collected on-demand during scrapes (no background goroutine)
+- Always returns current state (no stale data between scrapes)
+- Scales to multiple pools automatically
+- Lower memory footprint (no metric state in memory)
+
+**Alert thresholds:**
+
+- Open connections approaching `MaxOpenConns` → risk of request queuing
+- Wait count climbing steadily → pool is exhausted, increase `MaxOpenConns`
+- Idle connections too high → reduce `MaxIdleConns` or lower `ConnMaxIdleTime`
+
+## Batch Processing
+
+Avoid two extremes:
+
+- **Row-by-row** — N round trips for N rows, extremely slow
+- **One giant batch** — locks tables, consumes memory, can timeout and block other queries
+
+### Sweet spot: 100–1,000 rows per batch
+
+Adjust based on row size and database load. Larger rows → smaller batches.
+
+### Batch INSERT with sqlx
+
+```go
+func insertUsersBatch(ctx context.Context, db *sqlx.DB, users []User) error {
+    const batchSize = 500
+    for i := 0; i < len(users); i += batchSize {
+        end := min(i+batchSize, len(users))
+        batch := users[i:end]
+
+        _, err := db.NamedExecContext(ctx, `INSERT INTO users (name, email) VALUES (:name, :email)`, batch)
+        if err != nil {
+            return fmt.Errorf("inserting users batch %d-%d: %w", i, end, err)
+        }
+    }
+    return nil
+}
+```
+
+### Bulk INSERT with pgx (PostgreSQL COPY protocol)
+
+For maximum throughput on PostgreSQL, use `pgx.CopyFrom` which uses the binary COPY protocol — significantly faster than multi-row INSERT:
+
+```go
+rows := make([][]any, len(users))
+for i, u := range users {
+    rows[i] = []any{u.Name, u.Email}
+}
+_, err := pool.CopyFrom(ctx,
+    pgx.Identifier{"users"},
+    []string{"name", "email"},
+    pgx.CopyFromRows(rows),
+)
+```
+
+### Cursor-based pagination (avoid OFFSET)
+
+For reading large datasets, use cursor-based pagination instead of `OFFSET`. OFFSET re-scans skipped rows, getting slower as you paginate deeper:
+
+```go
+// ✗ Bad — OFFSET re-scans rows, O(offset + limit)
+SELECT * FROM events ORDER BY created_at LIMIT 100 OFFSET 10000
+
+// ✓ Good — cursor-based, O(limit) regardless of depth
+SELECT * FROM events WHERE created_at > $1 ORDER BY created_at LIMIT 100
+```
+
+## Indexing Strategy
+
+**Never create or drop indexes yourself.** Index changes affect production query performance and write throughput. Always suggest to the developer and let them decide.
+
+### Use SQL MCP to check existing indexes
+
+When a SQL MCP tool is available, query the database to check existing indexes before suggesting new ones:
+
+```sql
+-- PostgreSQL: list indexes on a table
+SELECT indexname, indexdef
+FROM pg_indexes
+WHERE tablename = 'users';
+
+-- Check for unused indexes (low scan count relative to writes)
+SELECT schemaname, relname, indexrelname, idx_scan, idx_tup_read
+FROM pg_stat_user_indexes
+WHERE idx_scan < 10
+ORDER BY idx_scan;
+```
+
+### When to suggest adding indexes
+
+- Foreign key columns (PostgreSQL does NOT auto-index foreign keys)
+- Columns frequently used in `WHERE`, `JOIN`, or `ORDER BY`
+- Composite indexes for multi-column queries (leftmost column is most selective)
+- Partial indexes for filtered queries (`WHERE active = true`)
+
+### When to suggest removing indexes
+
+- Indexes with near-zero `idx_scan` count (nobody reads them)
+- Duplicate indexes (same columns in same order)
+- Indexes on write-heavy tables that slow down INSERT/UPDATE/DELETE
+- Wide composite indexes where a narrower one would suffice
+
+Always present findings as suggestions with data (scan counts, table size), never execute DDL yourself.
+
+## Query Performance Tips
+
+- **`EXPLAIN ANALYZE`** before optimizing — measure, don't guess
+- **List columns explicitly** — avoid `SELECT *`, it fetches unnecessary data and breaks struct scanning when schema changes
+- **Use `LIMIT`** for pagination, always with an `ORDER BY`
+- **Prefer `EXISTS` over `COUNT`** for existence checks — `EXISTS` stops at the first match
+- **Avoid N+1 queries** — use `JOIN` or batch `WHERE id IN (...)` instead of querying in a loop
+- **Suggest improvements, never execute them** — performance changes (indexes, query rewrites, configuration) need human review in context of production data and workload patterns
+
+Batch operations SHOULD use 100–1,000 rows per batch — adjust based on row size and database load. Cursor-based pagination MUST replace `OFFSET` for large datasets — the cursor column MUST be chosen based on actual indexes (e.g., `created_at`, `user_id`). NEVER create indexes blindly — check existing indexes, measure with `EXPLAIN ANALYZE`, and present findings as suggestions. N+1 queries MUST be eliminated — use `JOIN` or batch `WHERE id IN (...)`.
+
+→ See `samber/cc-skills-golang@golang-observability` skill for database metrics and query monitoring. → See `samber/cc-skills@promql-cli` skill for querying pool metrics (`db_open_connections`, `db_in_use_connections`, `db_idle_connections`) via CLI.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/scanning.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/scanning.md
new file mode 100644
index 00000000..4f4638ff
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/scanning.md
@@ -0,0 +1,79 @@
+# Struct Scanning and NULLable Columns
+
+## Struct Scanning with sqlx
+
+Tag struct fields with `db:"column_name"` for sqlx:
+
+```go
+type User struct {
+    ID        int64      `db:"id"`
+    Name      string     `db:"name"`
+    Email     string     `db:"email"`
+    DeletedAt *time.Time `db:"deleted_at"` // NULLable
+}
+
+// Single row
+var user User
+err := db.GetContext(ctx, &user, "SELECT id, name, email, deleted_at FROM users WHERE id = $1", id)
+
+// Multiple rows
+var users []User
+err := db.SelectContext(ctx, &users, "SELECT id, name, email, deleted_at FROM users WHERE active = true")
+```
+
+## Struct Scanning with pgx
+
+With pgx (v5+), use `pgx.CollectRows` for automatic struct mapping:
+
+```go
+rows, err := pool.Query(ctx, "SELECT id, name, email FROM users WHERE active = true")
+if err != nil {
+    return fmt.Errorf("querying users: %w", err)
+}
+users, err := pgx.CollectRows(rows, pgx.RowToStructByName[User])
+```
+
+## JSON Marshaling
+
+Struct tags for both database and JSON work together. Pointer fields marshal to `null` in JSON when NULL in the database:
+
+```go
+type User struct {
+    ID        int64      `db:"id"         json:"id"`
+    Name      string     `db:"name"       json:"name"`
+    Email     string     `db:"email"      json:"email"`
+    Bio       *string    `db:"bio"        json:"bio,omitempty"` // NULL → omitted in JSON
+    DeletedAt *time.Time `db:"deleted_at" json:"deleted_at"`    // NULL → null in JSON
+}
+```
+
+## NULLable Columns
+
+Three approaches, from most to least recommended:
+
+**1. Pointer fields (recommended)** — clean, works with JSON marshaling:
+
+```go
+type User struct {
+    ID        int64      `db:"id"    json:"id"`
+    Name      string     `db:"name"  json:"name"`
+    DeletedAt *time.Time `db:"deleted_at" json:"deleted_at"` // nil when NULL
+}
+// Check: if user.DeletedAt != nil { ... }
+```
+
+**2. `sql.NullXxx` types** or `sql.Null[T]` generic — explicit but verbose, requires custom JSON marshaling:
+
+```go
+type User struct {
+    ID        int64          `db:"id"`
+    Bio       sql.NullString `db:"bio"`
+}
+// Check: if user.Bio.Valid { use(user.Bio.String) }
+```
+
+**3. `COALESCE` in SQL** — moves NULL handling to the query:
+
+```sql
+SELECT id, COALESCE(bio, '') AS bio FROM users WHERE id = $1
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/testing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/testing.md
new file mode 100644
index 00000000..505bff47
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/testing.md
@@ -0,0 +1,209 @@
+# Testing Database Code
+
+## Unit Tests with Mocks
+
+Define a repository interface so business logic can be tested without a database. Mock the interface with `testify/mock`:
+
+```go
+// Repository interface — the contract
+type UserRepository interface {
+    GetByID(ctx context.Context, id int64) (*User, bool, error)
+    Create(ctx context.Context, user *User) error
+}
+
+// Production implementation
+type pgUserRepository struct {
+    db *sqlx.DB
+}
+
+func (r *pgUserRepository) GetByID(ctx context.Context, id int64) (*User, bool, error) {
+    var user User
+    err := r.db.GetContext(ctx, &user, "SELECT id, name, email FROM users WHERE id = $1", id)
+    if err != nil {
+        if errors.Is(err, sql.ErrNoRows) {
+            return nil, false, nil
+        }
+        return nil, false, fmt.Errorf("querying user %d: %w", id, err)
+    }
+    return &user, true, nil
+}
+```
+
+### Mock for service-layer tests
+
+```go
+type mockUserRepo struct {
+    mock.Mock
+}
+
+func (m *mockUserRepo) GetByID(ctx context.Context, id int64) (*User, error) {
+    args := m.Called(ctx, id)
+    if args.Get(0) == nil {
+        return nil, args.Error(1)
+    }
+    return args.Get(0).(*User), args.Error(1)
+}
+
+func TestUserService_GetUser(t *testing.T) {
+    repo := new(mockUserRepo)
+    svc := NewUserService(repo)
+
+    expected := &User{ID: 1, Name: "Alice", Email: "alice@example.com"}
+    repo.On("GetByID", mock.Anything, int64(1)).Return(expected, nil)
+
+    user, err := svc.GetUser(context.Background(), 1)
+    require.NoError(t, err)
+    assert.Equal(t, expected, user)
+    repo.AssertExpectations(t)
+}
+
+func TestUserService_GetUser_NotFound(t *testing.T) {
+    repo := new(mockUserRepo)
+    svc := NewUserService(repo)
+
+    repo.On("GetByID", mock.Anything, int64(999)).Return(nil, ErrUserNotFound)
+
+    user, err := svc.GetUser(context.Background(), 999)
+    assert.Nil(t, user)
+    assert.ErrorIs(t, err, ErrUserNotFound)
+}
+```
+
+Unit tests verify business logic, not SQL correctness. They run fast and without external dependencies.
+
+## sqlmock for Query-Level Testing
+
+When you need to verify exact SQL without a real database, use [DATA-DOG/go-sqlmock](https://github.com/DATA-DOG/go-sqlmock):
+
+```go
+func TestGetByID_sqlmock(t *testing.T) {
+    db, mock, err := sqlmock.New()
+    require.NoError(t, err)
+    defer db.Close()
+
+    sqlxDB := sqlx.NewDb(db, "postgres")
+    repo := &pgUserRepository{db: sqlxDB}
+
+    rows := sqlmock.NewRows([]string{"id", "name", "email"}).
+        AddRow(1, "Alice", "alice@example.com")
+    mock.ExpectQuery("SELECT id, name, email FROM users WHERE id = \\$1").
+        WithArgs(1).
+        WillReturnRows(rows)
+
+    user, err := repo.GetByID(context.Background(), 1)
+    require.NoError(t, err)
+    assert.Equal(t, "Alice", user.Name)
+    assert.NoError(t, mock.ExpectationsWereMet())
+}
+```
+
+sqlmock is useful for verifying query structure and error handling paths, but it does not validate that your SQL is correct against a real database schema.
+
+## Integration Tests
+
+Integration tests run against a real database. Gate them with build tags so `go test ./...` skips them by default:
+
+```go
+//go:build integration
+
+package repository_test
+
+import (
+    "testing"
+    "github.com/stretchr/testify/suite"
+)
+
+type UserRepoSuite struct {
+    suite.Suite
+    db *sqlx.DB
+    tx *sqlx.Tx
+}
+
+func (s *UserRepoSuite) SetupSuite() {
+    dsn := os.Getenv("TEST_DATABASE_URL") // e.g., postgres://test:test@localhost:5432/testdb?sslmode=disable
+    db, err := sqlx.Connect("postgres", dsn)
+    s.Require().NoError(err)
+    s.db = db
+    // Run migrations here if needed
+}
+
+func (s *UserRepoSuite) TearDownSuite() {
+    s.db.Close()
+}
+
+func (s *UserRepoSuite) SetupTest() {
+    tx, err := s.db.Beginx()
+    s.Require().NoError(err)
+    s.tx = tx
+}
+
+func (s *UserRepoSuite) TearDownTest() {
+    s.tx.Rollback() // rolls back all changes — each test starts clean
+}
+
+func (s *UserRepoSuite) TestCreateAndGet() {
+    repo := NewUserRepository(s.tx)
+    user := &User{Name: "Alice", Email: "alice@example.com"}
+
+    err := repo.Create(context.Background(), user)
+    s.Require().NoError(err)
+    s.NotZero(user.ID)
+
+    got, err := repo.GetByID(context.Background(), user.ID)
+    s.Require().NoError(err)
+    s.Equal("Alice", got.Name)
+}
+
+func TestUserRepoSuite(t *testing.T) {
+    suite.Run(t, new(UserRepoSuite))
+}
+```
+
+Run integration tests:
+
+```bash
+go test -tags=integration -v ./internal/repository/...
+```
+
+### Test database with testcontainers-go
+
+For CI environments without a pre-existing database:
+
+```go
+func (s *UserRepoSuite) SetupSuite() {
+    ctx := context.Background()
+    container, err := postgres.Run(ctx, "postgres:16-alpine",
+        postgres.WithDatabase("testdb"),
+        postgres.WithUsername("test"),
+        postgres.WithPassword("test"),
+        testcontainers.WithWaitStrategy(
+            wait.ForLog("database system is ready to accept connections").
+                WithOccurrence(2).
+                WithStartupTimeout(30*time.Second),
+        ),
+    )
+    s.Require().NoError(err)
+    s.container = container
+
+    connStr, err := container.ConnectionString(ctx, "sslmode=disable")
+    s.Require().NoError(err)
+    s.db, err = sqlx.Connect("postgres", connStr)
+    s.Require().NoError(err)
+}
+```
+
+## What to Test
+
+| What                      | Unit test (mock) | Integration test |
+| ------------------------- | :--------------: | :--------------: |
+| Business logic            |        ✓         |                  |
+| SQL correctness           |                  |        ✓         |
+| Error paths (not found)   |        ✓         |        ✓         |
+| Transaction boundaries    |                  |        ✓         |
+| NULL handling round-trips |                  |        ✓         |
+| Constraint violations     |                  |        ✓         |
+| Query performance         |                  | ✓ (with EXPLAIN) |
+
+Unit tests MUST use mocks (interface mocks or sqlmock) — no real database connections. Integration tests MUST use build tags (`//go:build integration`) to separate from unit tests. Integration tests SHOULD use testcontainers-go for reproducible database environments in CI. NEVER test against production databases.
+
+→ See `samber/cc-skills-golang@golang-testing` skill for general test patterns and CI configuration.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/transactions.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/transactions.md
new file mode 100644
index 00000000..e7fcc5e9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-database/references/transactions.md
@@ -0,0 +1,49 @@
+# Transactions, Isolation Levels, and Locking
+
+## Basic transaction pattern
+
+```go
+tx, err := db.BeginTxx(ctx, nil) // default isolation (READ COMMITTED)
+if err != nil {
+    return fmt.Errorf("beginning transaction: %w", err)
+}
+defer tx.Rollback() // no-op if already committed
+
+// ... execute queries using tx ...
+
+if err := tx.Commit(); err != nil {
+    return fmt.Errorf("committing transaction: %w", err)
+}
+```
+
+## Custom isolation level
+
+```go
+tx, err := db.BeginTxx(ctx, &sql.TxOptions{
+    Isolation: sql.LevelSerializable, // strongest guarantee
+})
+```
+
+| Level | Use when |
+| --- | --- |
+| `LevelReadCommitted` | Default — good for most operations |
+| `LevelRepeatableRead` | Need consistent reads within a transaction |
+| `LevelSerializable` | Financial operations, inventory, anything with strict consistency |
+
+## SELECT FOR UPDATE — prevent race conditions
+
+```go
+var balance int
+err := tx.GetContext(ctx, &balance, "SELECT balance FROM accounts WHERE id = $1 FOR UPDATE", accountID)
+// Row is locked until tx.Commit() or tx.Rollback()
+```
+
+Use `FOR UPDATE` when you read a value, compute something from it, and then write it back. Without the lock, concurrent transactions can read stale data.
+
+## Locking variants
+
+| Clause | Effect |
+| --- | --- |
+| `FOR UPDATE` | Locks rows for write — other transactions block on same rows |
+| `FOR UPDATE NOWAIT` | Same, but fails immediately instead of waiting |
+| `FOR SHARE` | Locks rows for read — prevents writes but allows other reads |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/SKILL.md
new file mode 100644
index 00000000..b523b70b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/SKILL.md
@@ -0,0 +1,283 @@
+---
+name: golang-dependency-injection
+description: "Comprehensive guide for dependency injection (DI) in Golang. Covers why DI matters (testability, loose coupling, separation of concerns, lifecycle management), manual constructor injection, and DI library comparison (google/wire, uber-go/dig, uber-go/fx, samber/do). Use this skill when designing service architecture, setting up dependency injection, refactoring tightly coupled code, managing singletons or service factories, or when the user asks about inversion of control, service containers, or wiring dependencies in Go. For a specific DI library, → See `samber/cc-skills-golang@golang-google-wire`, `samber/cc-skills-golang@golang-uber-dig`, `samber/cc-skills-golang@golang-uber-fx`, or `samber/cc-skills-golang@golang-samber-do` skills."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.1"
+  openclaw:
+    emoji: "🔌"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs AskUserQuestion
+---
+
+**Persona:** You are a Go software architect. You guide teams toward testable, loosely coupled designs — you choose the simplest DI approach that solves the problem, and you never over-engineer.
+
+**Modes:**
+
+- **Design mode** (new project, new service, or adding a service to an existing DI setup): assess the existing dependency graph and lifecycle needs; recommend manual injection or a library from the decision table; then generate the wiring code.
+- **Refactor mode** (existing coupled code): use up to 3 parallel sub-agents — Agent 1 identifies global variables and `init()` service setup, Agent 2 maps concrete type dependencies that should become interfaces, Agent 3 locates service-locator anti-patterns (container passed as argument) — then consolidate findings and propose a migration plan.
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-dependency-injection` skill takes precedence.
+
+# Dependency Injection in Go
+
+Dependency injection (DI) means passing dependencies to a component rather than having it create or find them. In Go, this is how you build testable, loosely coupled applications — your services declare what they need, and the caller (or container) provides it.
+
+This skill is not exhaustive. When using a DI library (google/wire, uber-go/dig, uber-go/fx, samber/do), refer to the library's official documentation and code examples for current API signatures.
+
+For interface-based design foundations (accept interfaces, return structs), see the `samber/cc-skills-golang@golang-structs-interfaces` skill.
+
+## Best Practices Summary
+
+1. Dependencies MUST be injected via constructors — NEVER use global variables or `init()` for service setup
+2. Small projects (< 10 services) SHOULD use manual constructor injection — no library needed
+3. Interfaces MUST be defined where consumed, not where implemented — accept interfaces, return structs
+4. NEVER use global registries or package-level service locators
+5. The DI container MUST only exist at the composition root (`main()` or app startup) — NEVER pass the container as a dependency
+6. **Prefer lazy initialization** — only create services when first requested
+7. **Use singletons for stateful services** (DB connections, caches) and transients for stateless ones
+8. **Mock at the interface boundary** — DI makes this trivial
+9. **Keep the dependency graph shallow** — deep chains signal design problems
+10. **Choose the right DI library** for your project size and team — see the decision table below
+
+## Why Dependency Injection?
+
+| Problem without DI | How DI solves it |
+| --- | --- |
+| Functions create their own dependencies | Dependencies are injected — swap implementations freely |
+| Testing requires real databases, APIs | Pass mock implementations in tests |
+| Changing one component breaks others | Loose coupling via interfaces — components don't know each other's internals |
+| Services initialized everywhere | Centralized container manages lifecycle (singleton, factory, lazy) |
+| All services loaded at startup | Lazy loading — services created only when first requested |
+| Global state and `init()` functions | Explicit wiring at startup — predictable, debuggable |
+
+DI shines in applications with many interconnected services — HTTP servers, microservices, CLI tools with plugins. For a small script with 2-3 functions, manual wiring is fine. Don't over-engineer.
+
+## Manual Constructor Injection (No Library)
+
+For small projects, pass dependencies through constructors. See [Manual DI examples](./references/manual-di.md) for a complete application example.
+
+```go
+// ✓ Good — explicit dependencies, testable
+type UserService struct {
+    db     UserStore
+    mailer Mailer
+    logger *slog.Logger
+}
+
+func NewUserService(db UserStore, mailer Mailer, logger *slog.Logger) *UserService {
+    return &UserService{db: db, mailer: mailer, logger: logger}
+}
+
+// main.go — manual wiring
+func main() {
+    logger := slog.Default()
+    db := postgres.NewUserStore(connStr)
+    mailer := smtp.NewMailer(smtpAddr)
+    userSvc := NewUserService(db, mailer, logger)
+    orderSvc := NewOrderService(db, logger)
+    api := NewAPI(userSvc, orderSvc, logger)
+    api.ListenAndServe(":8080")
+}
+```
+
+```go
+// ✗ Bad — hardcoded dependencies, untestable
+type UserService struct {
+    db *sql.DB
+}
+
+func NewUserService() *UserService {
+    db, _ := sql.Open("postgres", os.Getenv("DATABASE_URL")) // hidden dependency
+    return &UserService{db: db}
+}
+```
+
+Manual DI breaks down when:
+
+- You have 15+ services with cross-dependencies
+- You need lifecycle management (health checks, graceful shutdown)
+- You want lazy initialization or scoped containers
+- Wiring order becomes fragile and hard to maintain
+
+## DI Library Comparison
+
+Go has three main approaches to DI libraries:
+
+- [google/wire examples](./references/google-wire.md) — Compile-time code generation
+- [uber-go/dig + fx examples](./references/uber-dig-fx.md) — Reflection-based framework
+- [samber/do examples](./references/samber-do.md) — Generics-based, no code generation
+
+### Decision Table
+
+| Criteria | Manual | google/wire | uber-go/dig + fx | samber/do |
+| --- | --- | --- | --- | --- |
+| **Project size** | Small (< 10 services) | Medium-Large | Large | Any size |
+| **Type safety** | Compile-time | Compile-time (codegen) | Runtime (reflection) | Compile-time (generics) |
+| **Code generation** | None | Required (`wire_gen.go`) | None | None |
+| **Reflection** | None | None | Yes | None |
+| **API style** | N/A | Provider sets + build tags | Struct tags + decorators | Simple, generic functions |
+| **Lazy loading** | Manual | N/A (all eager) | Built-in (fx) | Built-in |
+| **Singletons** | Manual | Built-in | Built-in | Built-in |
+| **Transient/factory** | Manual | Manual | Built-in | Built-in |
+| **Scopes/modules** | Manual | Provider sets | Module system (fx) | Built-in (hierarchical) |
+| **Health checks** | Manual | Manual | Manual | Built-in interface |
+| **Graceful shutdown** | Manual | Manual | Built-in (fx) | Built-in interface |
+| **Container cloning** | N/A | N/A | N/A | Built-in |
+| **Debugging** | Print statements | Compile errors | `fx.Visualize()` | `ExplainInjector()`, web interface |
+| **Go version** | Any | Any | Any | 1.18+ (generics) |
+| **Learning curve** | None | Medium | High | Low |
+
+### Quick Comparison: Same App, Four Ways
+
+The dependency graph: `Config -> Database -> UserStore -> UserService -> API`
+
+**Manual**:
+
+```go
+cfg := NewConfig()
+db := NewDatabase(cfg)
+store := NewUserStore(db)
+svc := NewUserService(store)
+api := NewAPI(svc)
+api.Run()
+// No automatic shutdown, health checks, or lazy loading
+```
+
+**google/wire**:
+
+```go
+// wire.go — then run: wire ./...
+func InitializeAPI() (*API, error) {
+    wire.Build(NewConfig, NewDatabase, NewUserStore, NewUserService, NewAPI)
+    return nil, nil
+}
+// No lifecycle hooks (OnStart/OnStop) or health checks; cleanup via returned func() from providers
+```
+
+**uber-go/fx**:
+
+```go
+app := fx.New(
+    fx.Provide(NewConfig, NewDatabase, NewUserStore, NewUserService),
+    fx.Invoke(func(api *API) { api.Run() }),
+)
+app.Run() // manages lifecycle, but reflection-based
+```
+
+**samber/do**:
+
+```go
+i := do.New()
+do.Provide(i, NewConfig)
+do.Provide(i, NewDatabase)    // auto shutdown + health check
+do.Provide(i, NewUserStore)
+do.Provide(i, NewUserService)
+api := do.MustInvoke[*API](i)
+api.Run()
+// defer i.Shutdown() — handles all cleanup automatically
+```
+
+## Testing with DI
+
+DI makes testing straightforward — inject mocks instead of real implementations:
+
+```go
+// Define a mock
+type MockUserStore struct {
+    users map[string]*User
+}
+
+func (m *MockUserStore) FindByID(ctx context.Context, id string) (*User, error) {
+    u, ok := m.users[id]
+    if !ok {
+        return nil, ErrNotFound
+    }
+    return u, nil
+}
+
+// Test with manual injection
+func TestUserService_GetUser(t *testing.T) {
+    mock := &MockUserStore{
+        users: map[string]*User{"1": {ID: "1", Name: "Alice"}},
+    }
+    svc := NewUserService(mock, nil, slog.Default())
+
+    user, err := svc.GetUser(context.Background(), "1")
+    if err != nil {
+        t.Fatalf("unexpected error: %v", err)
+    }
+    if user.Name != "Alice" {
+        t.Errorf("got %q, want %q", user.Name, "Alice")
+    }
+}
+```
+
+### Testing with samber/do — Clone and Override
+
+Container cloning creates an isolated copy where you override only the services you need to mock:
+
+```go
+func TestUserService_WithDo(t *testing.T) {
+    // Create a test injector with mock implementation
+    testInjector := do.New()
+
+    // Provide the mock UserStore interface
+    do.OverrideValue[UserStore](testInjector, &MockUserStore{
+        users: map[string]*User{"1": {ID: "1", Name: "Alice"}},
+    })
+
+    // Provide other real services as needed
+    do.Provide[*slog.Logger](testInjector, func(i *do.Injector) (*slog.Logger, error) {
+        return slog.Default(), nil
+    })
+
+    svc := do.MustInvoke[*UserService](testInjector)
+    user, err := svc.GetUser(context.Background(), "1")
+    // ... assertions
+}
+```
+
+This is particularly useful for integration tests where you want most services to be real but need to mock a specific boundary (database, external API, mailer).
+
+## When to Adopt a DI Library
+
+| Signal | Action |
+| --- | --- |
+| < 10 services, simple dependencies | Stay with manual constructor injection |
+| 10-20 services, some cross-cutting concerns | Consider a DI library |
+| 20+ services, lifecycle management needed | Strongly recommended |
+| Need health checks, graceful shutdown | Use a library with built-in lifecycle support |
+| Team unfamiliar with DI concepts | Start manual, migrate incrementally |
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Global variables as dependencies | Pass through constructors or DI container |
+| `init()` for service setup | Explicit initialization in `main()` or container |
+| Depending on concrete types | Accept interfaces at consumption boundaries |
+| Passing the container everywhere (service locator) | Inject specific dependencies, not the container |
+| Deep dependency chains (A->B->C->D->E) | Flatten — most services should depend on repositories and config directly |
+| Creating a new container per request | One container per application; use scopes for request-level isolation |
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-samber-do` skill for detailed samber/do usage patterns
+- → See `samber/cc-skills-golang@golang-structs-interfaces` skill for interface design and composition
+- → See `samber/cc-skills-golang@golang-testing` skill for testing with dependency injection
+- → See `samber/cc-skills-golang@golang-project-layout` skill for DI initialization placement
+
+## References
+
+- [samber/do/v2 documentation](https://do.samber.dev) | [github.com/samber/do/v2](https://github.com/samber/do)
+- [google/wire user guide](https://github.com/google/wire/blob/main/docs/guide.md)
+- [uber-go/fx documentation](https://uber-go.github.io/fx/)
+- [uber-go/dig](https://github.com/uber-go/dig)
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/evals/evals.json
new file mode 100644
index 00000000..232ffab3
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/evals/evals.json
@@ -0,0 +1,156 @@
+[
+  {
+    "id": 1,
+    "name": "constructor-injection-not-globals",
+    "description": "Tests that dependencies are injected via constructors, not global variables or init()",
+    "prompt": "I have a UserService that needs a database connection and a logger. What's the best way to set this up in Go? I was thinking of using a package-level var for the database.",
+    "trap": "Without the skill, the model may accept the global variable approach or use init() for setup. The skill explicitly forbids globals and init() for service setup.",
+    "assertions": [
+      {"id": "1.1", "text": "Uses constructor injection (NewUserService taking dependencies as parameters)"},
+      {"id": "1.2", "text": "Explicitly advises against package-level variables for service dependencies"},
+      {"id": "1.3", "text": "Explains why globals are problematic (untestable, hidden dependencies, or coupling)"},
+      {"id": "1.4", "text": "Does NOT use init() for service initialization"},
+      {"id": "1.5", "text": "Returns a concrete struct pointer from the constructor, not an interface"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "interface-defined-at-consumer",
+    "description": "Tests that interfaces are defined where consumed, not where implemented",
+    "prompt": "I'm building a Go service that uses a UserStore. Should I define the UserStore interface in the same package as the PostgreSQL implementation or somewhere else? Show me the correct pattern.",
+    "trap": "Without the skill, the model often defines the interface in the implementation package (next to the struct). The skill requires interfaces to be defined at the consumption site.",
+    "assertions": [
+      {"id": "2.1", "text": "Defines the interface in the consuming package (e.g. service package), not the implementation package"},
+      {"id": "2.2", "text": "Explains the principle: accept interfaces, return structs"},
+      {"id": "2.3", "text": "The implementation package returns a concrete struct pointer"},
+      {"id": "2.4", "text": "The consumer depends on its own locally-defined interface"},
+      {"id": "2.5", "text": "Does NOT have the implementation package import the consumer's interface"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "container-not-passed-as-dependency",
+    "description": "Tests that the DI container is never passed as a dependency (service locator anti-pattern)",
+    "prompt": "I'm using samber/do for DI in my Go project. My UserService needs a Database and a Mailer. Should I pass the do.Injector to UserService so it can look up what it needs?",
+    "trap": "Without the skill, the model may accept passing the injector/container as a dependency. The skill explicitly forbids this as the service locator anti-pattern.",
+    "assertions": [
+      {"id": "3.1", "text": "Advises against passing the injector/container as a dependency"},
+      {"id": "3.2", "text": "Identifies this as the service locator anti-pattern"},
+      {"id": "3.3", "text": "Shows that the Injector should only exist at the composition root (main or app startup)"},
+      {"id": "3.4", "text": "Shows UserService receiving Database and Mailer directly as constructor parameters"},
+      {"id": "3.5", "text": "Shows the provider function using do.MustInvoke inside the provider, not inside UserService methods"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "manual-di-for-small-projects",
+    "description": "Tests that small projects use manual DI, not a library",
+    "prompt": "I'm building a small Go REST API with about 5 services: config, database, user repository, user service, and HTTP handler. What DI approach should I use?",
+    "trap": "Without the skill, the model may recommend a DI library like Wire or Fx for any project. The skill says small projects (< 10 services) should use manual constructor injection.",
+    "assertions": [
+      {"id": "4.1", "text": "Recommends manual constructor injection for a project with only 5 services"},
+      {"id": "4.2", "text": "Does NOT recommend a DI library as the primary approach"},
+      {"id": "4.3", "text": "Shows wiring in main() with explicit constructor calls in dependency order"},
+      {"id": "4.4", "text": "Initializes infrastructure first, then repositories, then services, then transport"},
+      {"id": "4.5", "text": "Mentions that a DI library becomes worthwhile at 10-20+ services"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "di-library-selection-judgment",
+    "description": "Tests correct DI library recommendation based on project characteristics",
+    "prompt": "I'm building a large Go microservice with 40+ services, complex lifecycle management (health checks, graceful shutdown), and I want compile-time type safety. My team is comfortable with Go generics. Which DI library should I use?",
+    "trap": "Without the skill, the model may recommend uber-go/fx (most popular) or google/wire. The skill's decision table shows samber/do matches all these criteria: any size, compile-time generics, built-in lifecycle, health checks, shutdown.",
+    "assertions": [
+      {"id": "5.1", "text": "Recommends samber/do as a strong fit given the criteria (generics, lifecycle, compile-time safety)"},
+      {"id": "5.2", "text": "Explains why uber-go/fx is a valid alternative but uses reflection (runtime errors, not compile-time)"},
+      {"id": "5.3", "text": "Explains why google/wire lacks built-in lifecycle management (no health checks, no shutdown)"},
+      {"id": "5.4", "text": "Mentions that samber/do requires Go 1.18+ for generics"},
+      {"id": "5.5", "text": "Discusses at least 3 DI library options from the decision table"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "wire-build-constraint-and-codegen",
+    "description": "Tests proper google/wire setup with wireinject build constraint",
+    "prompt": "Set up google/wire for a Go application with Config, Database, UserStore, and UserService. Show the wire.go file and explain what happens when I run wire.",
+    "trap": "Without the skill, the model may forget the //go:build wireinject build constraint or not explain that wire.Build generates plain Go constructors.",
+    "assertions": [
+      {"id": "6.1", "text": "Includes //go:build wireinject build constraint in the wire.go file"},
+      {"id": "6.2", "text": "Uses wire.Build with all provider functions listed"},
+      {"id": "6.3", "text": "Shows wire.Bind for binding interface to implementation"},
+      {"id": "6.4", "text": "Explains that wire generates wire_gen.go with plain constructor calls"},
+      {"id": "6.5", "text": "Mentions that wire_gen.go must not be edited manually"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "fx-lifecycle-hooks-pattern",
+    "description": "Tests proper uber-go/fx lifecycle hook usage for startup/shutdown",
+    "prompt": "Set up a database connection using uber-go/fx that connects on startup and cleanly closes on shutdown.",
+    "trap": "Without the skill, the model may open and close the connection manually instead of using fx.Lifecycle hooks. The skill requires OnStart/OnStop hooks.",
+    "assertions": [
+      {"id": "7.1", "text": "Uses fx.Lifecycle parameter in the provider function"},
+      {"id": "7.2", "text": "Registers OnStart hook for establishing the database connection"},
+      {"id": "7.3", "text": "Registers OnStop hook for closing the database connection"},
+      {"id": "7.4", "text": "Uses lc.Append(fx.Hook{...}) pattern"},
+      {"id": "7.5", "text": "OnStart and OnStop take context.Context as parameter"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "testing-with-di-mock-injection",
+    "description": "Tests that DI enables testing by injecting mocks at the interface boundary",
+    "prompt": "Write a test for a UserService that depends on a UserStore interface. The test should verify that GetUser returns the correct user when found and an error when not found. Don't use any DI library.",
+    "trap": "Without the skill, the model may test with a real database or skip the mock pattern. The skill requires mocking at the interface boundary.",
+    "assertions": [
+      {"id": "8.1", "text": "Creates a mock implementation of the UserStore interface"},
+      {"id": "8.2", "text": "Injects the mock into UserService via the constructor (NewUserService)"},
+      {"id": "8.3", "text": "Tests both the success path (user found) and the error path (not found)"},
+      {"id": "8.4", "text": "Does NOT use a real database connection in the test"},
+      {"id": "8.5", "text": "The mock is defined in the test file, not as a package-level or global variable"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "shallow-dependency-graph",
+    "description": "Tests that deep dependency chains are flagged as a design problem",
+    "prompt": "My Go application has this dependency chain: Config -> Database -> UserRepo -> UserService -> NotificationService -> OrderService -> PaymentService -> APIHandler. Is this a good architecture?",
+    "trap": "Without the skill, the model may accept this deep chain as normal layered architecture. The skill says deep chains signal design problems and recommends flattening.",
+    "assertions": [
+      {"id": "9.1", "text": "Identifies the deep dependency chain as a design problem"},
+      {"id": "9.2", "text": "Recommends flattening the dependency graph"},
+      {"id": "9.3", "text": "Suggests that most services should depend on repositories and config directly, not transitively through other services"},
+      {"id": "9.4", "text": "Explains the negative consequences of deep chains (fragility, hard to test, or hard to maintain)"},
+      {"id": "9.5", "text": "Proposes a concrete restructuring where OrderService and PaymentService don't depend on each other transitively"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "one-container-per-app-not-per-request",
+    "description": "Tests that a DI container is created once per application, not per request",
+    "prompt": "I'm building a Go HTTP API with samber/do. In each HTTP handler, I'm creating a new do.New() injector, providing all services, then invoking the one I need. This way each request gets fresh services. Is this correct?",
+    "trap": "Without the skill, the model may accept the per-request container pattern as reasonable isolation. The skill explicitly forbids creating a new container per request.",
+    "assertions": [
+      {"id": "10.1", "text": "Identifies creating a new container per request as a mistake"},
+      {"id": "10.2", "text": "Recommends one container per application created at startup"},
+      {"id": "10.3", "text": "Explains the performance or correctness problem with per-request containers (recreating singletons, no connection reuse)"},
+      {"id": "10.4", "text": "Suggests using scopes for request-level isolation if needed"},
+      {"id": "10.5", "text": "Shows the container being created once in main() and services injected into handlers"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "lazy-vs-eager-initialization",
+    "description": "Tests knowledge of lazy initialization preference and singleton vs transient distinction",
+    "prompt": "When using a DI container in Go, should all my services be created at application startup? I have a database pool, a cache client, and some request processing services.",
+    "trap": "Without the skill, the model may recommend eager initialization for everything. The skill prefers lazy initialization and distinguishes singletons for stateful services from transients for stateless ones.",
+    "assertions": [
+      {"id": "11.1", "text": "Recommends lazy initialization (services created on first use, not all at startup)"},
+      {"id": "11.2", "text": "Recommends singletons for stateful services like database connections and cache clients"},
+      {"id": "11.3", "text": "Recommends transients (or factories) for stateless request processing services"},
+      {"id": "11.4", "text": "Explains why lazy loading is beneficial (unused services are never created, faster startup)"},
+      {"id": "11.5", "text": "Notes which DI libraries support lazy loading (samber/do, fx) vs which don't (wire is all eager)"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/google-wire.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/google-wire.md
new file mode 100644
index 00000000..4c78570c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/google-wire.md
@@ -0,0 +1,92 @@
+# google/wire — Compile-Time Code Generation
+
+Wire uses code generation to resolve the dependency graph at compile time. Type-safe, but requires a build step.
+
+- Docs: [github.com/google/wire](https://github.com/google/wire) | [User Guide](https://github.com/google/wire/blob/main/docs/guide.md)
+
+Before writing Wire code, refer to the library's official documentation for up-to-date API signatures and examples.
+
+## Provider Definitions
+
+```go
+// providers.go
+package wire
+
+import "github.com/google/wire"
+
+// ProviderSet groups related providers
+var InfraSet = wire.NewSet(
+    NewConfig,
+    NewDatabase,
+    NewCache,
+)
+
+var ServiceSet = wire.NewSet(
+    NewUserService,
+    wire.Bind(new(UserStore), new(*PostgresUserStore)), // bind interface to impl
+)
+```
+
+## Injector Definition
+
+```go
+// wire.go — build constraint ensures this is only used by the wire tool
+//go:build wireinject
+
+package main
+
+import "github.com/google/wire"
+
+func InitializeApp() (*App, error) {
+    wire.Build(
+        InfraSet,
+        ServiceSet,
+        NewApp,
+    )
+    return nil, nil // wire replaces this body
+}
+```
+
+## Generated Code
+
+Run `wire ./...` to produce `wire_gen.go`:
+
+```go
+// wire_gen.go — DO NOT EDIT (auto-generated by wire)
+func InitializeApp() (*App, error) {
+    config := NewConfig()
+    database, err := NewDatabase(config)
+    if err != nil {
+        return nil, err
+    }
+    cache := NewCache(config)
+    store := NewPostgresUserStore(database)
+    userService := NewUserService(store, cache)
+    app := NewApp(userService)
+    return app, nil
+}
+```
+
+## Testing
+
+Wire generates plain constructors, so testing uses manual injection — no container to clone:
+
+```go
+func TestUserService(t *testing.T) {
+    mock := &MockUserStore{...}
+    svc := NewUserService(mock, NewTestCache())
+    // ... test
+}
+```
+
+## Tradeoffs
+
+- Errors caught at compile time (codegen fails if graph is incomplete)
+- Requires running `wire ./...` after every dependency change
+- No lazy loading — all dependencies created eagerly
+- No built-in lifecycle management (health checks, shutdown)
+- No runtime container — wire generates plain Go constructor calls
+- Interface bindings require explicit `wire.Bind` declarations
+- Generated files (`wire_gen.go`) must be committed and kept in sync
+
+Wire injectors MUST use `//go:build wireinject` build constraint. Generated `wire_gen.go` MUST NOT be edited manually — always regenerate with `wire ./...`.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/manual-di.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/manual-di.md
new file mode 100644
index 00000000..e851e1f6
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/manual-di.md
@@ -0,0 +1,64 @@
+# Manual Constructor Injection
+
+Manual DI is the simplest approach — pass dependencies through constructors. No library, no magic.
+
+## Complete Application Example
+
+```go
+func main() {
+    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt)
+    defer stop()
+
+    // Layer 1: Configuration
+    cfg := LoadConfig()
+    logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
+
+    // Layer 2: Infrastructure
+    db, err := postgres.Connect(cfg.DatabaseURL)
+    if err != nil {
+        logger.Error("database connection failed", "error", err)
+        os.Exit(1)
+    }
+    defer db.Close()
+
+    cache := redis.NewClient(cfg.RedisURL)
+    defer cache.Close()
+
+    mailer := smtp.NewMailer(cfg.SMTPAddr)
+
+    // Layer 3: Repositories
+    userRepo := postgres.NewUserRepository(db)
+    orderRepo := postgres.NewOrderRepository(db)
+
+    // Layer 4: Services
+    userSvc := service.NewUserService(userRepo, cache, mailer, logger)
+    orderSvc := service.NewOrderService(orderRepo, userSvc, logger)
+    paymentSvc := service.NewPaymentService(orderRepo, cfg.StripeKey, logger)
+
+    // Layer 5: Transport
+    handler := http.NewHandler(userSvc, orderSvc, paymentSvc, logger)
+    server := http.NewServer(cfg.Port, handler)
+
+    // Run
+    go server.ListenAndServe()
+    <-ctx.Done()
+    server.Shutdown(context.Background())
+}
+```
+
+## When Manual DI Works Well
+
+- Small to medium projects (< 15 services)
+- Simple dependency graph with clear layering
+- No need for lazy loading or lifecycle management
+- Team prefers explicit, visible wiring
+
+## When Manual DI Breaks Down
+
+- Adding a new service means editing `main()` and getting the wiring order right
+- Lifecycle management (health checks, graceful shutdown) must be hand-coded with `defer`
+- No lazy initialization — all services are created at startup, even if unused
+- Cross-cutting concerns (logging, tracing) must be threaded through every constructor
+- With 30+ services, the wiring code becomes fragile and hard to maintain
+
+Manual DI SHOULD be the default for small projects (< 15 services). Dependencies MUST be initialized in order — infrastructure first, then repositories, then services, then transport.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/samber-do.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/samber-do.md
new file mode 100644
index 00000000..4ba2679c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/samber-do.md
@@ -0,0 +1,36 @@
+# samber/do — Generics-Based DI
+
+> **For the full samber/do API, patterns, and advanced features, see the `samber/cc-skills-golang@golang-samber-do` skill.**
+
+Type-safe dependency injection using Go generics. No reflection, no code generation, simple API.
+
+- Docs: [do.samber.dev](https://do.samber.dev) | [github.com/samber/do/v2](https://github.com/samber/do)
+
+## Core Pattern
+
+```go
+// Register services with providers
+injector := do.New()
+do.Provide(injector, func(i do.Injector) (*UserService, error) {
+    db := do.MustInvoke[*Database](i)
+    return NewUserService(db), nil
+})
+
+// Invoke services (lazy — created on demand)
+svc := do.MustInvoke[*UserService](injector)
+
+// Graceful shutdown — all services implementing Shutdowner are closed
+injector.ShutdownOnSignalsWithContext(ctx, os.Interrupt)
+```
+
+## Why samber/do
+
+- **No code generation** — no build step, no generated files to maintain
+- **No reflection** — errors are caught at compile time via generics, not at runtime
+- **Strongly typed** — Go generics provide full type safety without `interface{}` casts
+- **Built-in lifecycle** — health checks and graceful shutdown detected automatically
+- **Container cloning** — create isolated test containers from production configuration
+- **Simple API** — `Provide`, `Invoke`, `Shutdown` — that's most of what you need
+- **Package system** — organize services by domain without manual wiring order
+
+→ See `samber/cc-skills-golang@golang-samber-do` for full application setup, package organization, lifecycle management, debugging, testing with clone + override, and complete API reference.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/uber-dig-fx.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/uber-dig-fx.md
new file mode 100644
index 00000000..790d7007
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-injection/references/uber-dig-fx.md
@@ -0,0 +1,142 @@
+# uber-go/dig + uber-go/fx — Reflection-Based DI
+
+`dig` is the low-level DI container; `fx` is the full application framework built on top. Powerful but uses reflection — errors appear at startup, not compile time.
+
+- Docs: [github.com/uber-go/dig](https://github.com/uber-go/dig) | [uber-go.github.io/fx](https://uber-go.github.io/fx/)
+
+Before writing dig/fx code, refer to the library's official documentation for up-to-date API signatures and examples.
+
+## dig — Basic Container
+
+```go
+func main() {
+    container := dig.New()
+
+    container.Provide(NewConfig)
+    container.Provide(NewDatabase)
+    container.Provide(NewUserStore)
+    container.Provide(NewUserService)
+
+    // Invoke — dig resolves the full dependency chain
+    err := container.Invoke(func(svc *UserService) {
+        svc.Run()
+    })
+    if err != nil {
+        log.Fatal(err)
+    }
+}
+```
+
+### Named Dependencies
+
+```go
+type DatabaseParams struct {
+    dig.In
+
+    Primary *sql.DB `name:"primary"`
+    Replica *sql.DB `name:"replica"`
+}
+
+container.Provide(NewPrimaryDB, dig.Name("primary"))
+container.Provide(NewReplicaDB, dig.Name("replica"))
+
+container.Provide(func(p DatabaseParams) *UserService {
+    return &UserService{
+        writer: p.Primary,
+        reader: p.Replica,
+    }
+})
+```
+
+### dig Tradeoffs
+
+- Uses reflection — type mismatches are runtime errors, not compile errors
+- `dig.In` and `dig.Out` structs add boilerplate for complex graphs
+- No built-in lifecycle management
+- Powerful grouping with `dig.Group` for collecting multiple implementations
+
+## fx — Full Application Framework
+
+### Basic Application
+
+```go
+func main() {
+    app := fx.New(
+        fx.Provide(
+            NewConfig,
+            NewDatabase,
+            NewUserStore,
+            NewUserService,
+        ),
+        fx.Invoke(RegisterRoutes),
+        fx.Invoke(StartServer),
+    )
+
+    app.Run() // blocks until signal, then calls shutdown hooks
+}
+```
+
+### Lifecycle Hooks
+
+```go
+func NewDatabase(lc fx.Lifecycle, cfg *Config) (*Database, error) {
+    db := &Database{}
+
+    lc.Append(fx.Hook{
+        OnStart: func(ctx context.Context) error {
+            return db.Connect(cfg.URL)
+        },
+        OnStop: func(ctx context.Context) error {
+            return db.Close()
+        },
+    })
+
+    return db, nil
+}
+```
+
+### Modules
+
+```go
+var InfraModule = fx.Module("infra",
+    fx.Provide(NewConfig),
+    fx.Provide(NewDatabase),
+    fx.Provide(NewCache),
+)
+
+var ServiceModule = fx.Module("service",
+    fx.Provide(NewUserService),
+    fx.Provide(NewOrderService),
+)
+
+app := fx.New(InfraModule, ServiceModule, fx.Invoke(StartServer))
+```
+
+### Testing with fx
+
+```go
+func TestUserService(t *testing.T) {
+    var svc *UserService
+
+    app := fxtest.New(t,
+        fx.Provide(NewMockUserStore),
+        fx.Provide(NewUserService),
+        fx.Populate(&svc),
+    )
+    app.RequireStart()
+    defer app.RequireStop()
+
+    // ... test svc
+}
+```
+
+### fx Tradeoffs
+
+- Full application framework — manages startup, shutdown, and signal handling
+- Reflection-based — errors at startup, not compile time
+- Steep learning curve — `fx.In`, `fx.Out`, `fx.Annotate`, `fx.Decorate`
+- Built-in lifecycle (OnStart/OnStop hooks)
+- Heavyweight — pulls in the full fx framework
+- `fxtest` package for testing, but requires starting/stopping the app
+
+fx lifecycle hooks MUST be used for start/stop — register `OnStart`/`OnStop` via `fx.Lifecycle`. fx modules SHOULD group related providers — use `fx.Module` to organize by domain.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/SKILL.md
new file mode 100644
index 00000000..80cf68ba
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/SKILL.md
@@ -0,0 +1,223 @@
+---
+name: golang-dependency-management
+description: "Dependency management strategies for Golang projects — go.mod management, installing/upgrading packages, Minimal Version Selection, vulnerability scanning, outdated dependency tracking, binary size analysis, Dependabot/Renovate setup, conflict resolution, and go.work workspaces. Use when adding, removing, or upgrading Go dependencies, auditing vulnerabilities, resolving version conflicts, or setting up automated dependency updates."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.3"
+  openclaw:
+    emoji: "📦"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - govulncheck
+    install:
+      - kind: go
+        package: golang.org/x/vuln/cmd/govulncheck@latest
+        bins: [govulncheck]
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent Bash(govulncheck:*) AskUserQuestion
+---
+
+**Persona:** You are a Go dependency steward. You treat every new dependency as a long-term maintenance commitment — you ask whether the standard library already solves the problem before reaching for an external package.
+
+**Dependencies:**
+
+- govulncheck: `go install golang.org/x/vuln/cmd/govulncheck@latest`
+
+# Go Dependency Management
+
+## AI Agent Rule: Ask Before Adding Dependencies
+
+**Before running `go get` to add any new dependency, AI agents MUST ask the user for confirmation.** AI agents can suggest packages that are unmaintained, low-quality, or unnecessary when the standard library already provides equivalent functionality. Using `go get -u` to upgrade an existing dependency is safe.
+
+Before proposing a dependency, evaluate:
+
+- Does the standard library already cover the use case?
+- Is the license compatible?
+- Are there well-known alternatives?
+- What it does and why it's needed?
+
+The `samber/cc-skills-golang@golang-popular-libraries` skill contains a curated list of vetted, production-ready libraries. Prefer recommending packages from that list. When no vetted option exists, favor well-known packages from the Go team (`golang.org/x/...`) or established organizations over obscure alternatives.
+
+## Key Rules
+
+- `go.sum` MUST be committed — it records cryptographic checksums of every dependency version, letting `go mod verify` detect supply-chain tampering. Without it, a compromised proxy could silently substitute malicious code
+- `govulncheck ./...` or `go tool govulncheck ./...` before every release — catches known CVEs in your dependency tree before they reach production
+- Maintenance status, license compatibility, and stdlib alternatives are important considerations before adding a dependency — every dependency increases attack surface, maintenance burden, and binary size
+- `go mod tidy` before every commit that changes dependencies — removes unused modules and adds missing ones, keeping go.mod honest
+
+## go.mod & go.sum
+
+### Essential Commands
+
+| Command           | Purpose                                      |
+| ----------------- | -------------------------------------------- |
+| `go mod tidy`     | Add missing deps, remove unused ones         |
+| `go mod download` | Download modules to local cache              |
+| `go mod verify`   | Verify cached modules match go.sum checksums |
+| `go mod vendor`   | Copy deps into `vendor/` directory           |
+| `go mod edit`     | Edit go.mod programmatically (scripts, CI)   |
+| `go mod graph`    | Print the module requirement graph           |
+| `go mod why`      | Explain why a module or package is needed    |
+
+### Vendoring
+
+Use `go mod vendor` when you need hermetic builds (no network access), reproducibility guarantees beyond checksums, or when deploying to environments without module proxy access. CI pipelines and Docker builds sometimes benefit from vendoring. Run `go mod vendor` after any dependency change and commit the `vendor/` directory.
+
+## Installing & Upgrading Dependencies
+
+### Adding a Dependency
+
+```bash
+go get github.com/google/uuid          # Latest version
+go get github.com/google/uuid@v1.6.0   # Specific version
+go get github.com/google/uuid@latest   # Explicitly latest
+go get github.com/google/uuid@<commit> # Specific commit (pseudo-version)
+```
+
+### Upgrading
+
+```bash
+go get -u ./...            # Upgrade ALL direct+indirect deps to latest minor/patch
+go get -u=patch ./...      # Upgrade to latest patch only (safer)
+go get github.com/pkg@v1.5 # Upgrade specific package
+```
+
+**Prefer `go get -u=patch`** for routine updates. Patch and minor updates are usually lower risk than major upgrades, but still require review. For dependency updates, run:
+
+```bash
+go get -u=patch ./...
+go mod tidy
+go test ./...
+go vet ./...
+govulncheck ./...   # or: go tool govulncheck ./...
+```
+
+Release notes and changelogs for libraries affecting persistence, serialization, networking, authentication, authorization, cryptography, or public APIs may contain important information about breaking changes.
+
+### Removing a Dependency
+
+```bash
+go get github.com/google/uuid@none  # Mark for removal
+go mod tidy                          # Clean up go.mod and go.sum
+```
+
+### Installing CLI Tools
+
+For Go 1.24+ modules, pin executable tools in `go.mod` with `tool` directives. Do not create a new `tools.go` blank-import file unless the module must support Go <1.24.
+
+```bash
+# Add tools to the current module.
+go get -tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest
+go get -tool golang.org/x/vuln/cmd/govulncheck@latest
+go get -tool golang.org/x/perf/cmd/benchstat@latest
+
+# Run pinned tools reproducibly.
+go tool golangci-lint run ./...
+go tool govulncheck ./...
+go tool benchstat old.txt new.txt
+
+# Install all module-pinned tools into GOBIN/PATH when needed.
+go install tool
+
+# Update pinned tools deliberately, then review go.mod/go.sum.
+go get -u tool
+go mod tidy
+```
+
+`go.mod` shape for a module targeting Go 1.26 or newer. This is an example target, not a cap; keep the project's actual `go` directive and do not change it just to add tools.
+
+```go.mod
+module example.com/project
+
+go 1.26
+
+tool (
+    github.com/golangci/golangci-lint/v2/cmd/golangci-lint
+    golang.org/x/vuln/cmd/govulncheck
+    golang.org/x/perf/cmd/benchstat
+)
+```
+
+For Go <1.24 only, use the legacy `tools.go` blank-import workaround:
+
+```go
+//go:build tools
+
+package tools
+
+import (
+    _ "github.com/golangci/golangci-lint/v2/cmd/golangci-lint"
+    _ "golang.org/x/vuln/cmd/govulncheck"
+)
+```
+
+Rule: Go 1.24+ = `tool` directives. Go <1.24 = `tools.go` fallback.
+
+### Go 1.26+ module target note
+
+When using a Go 1.26 or newer toolchain, `go mod init` may create a module with an older default `go` directive. If the project intentionally targets Go 1.26+ APIs, update the directive deliberately:
+
+```bash
+go mod edit -go=1.26
+go mod tidy
+```
+
+For future Go versions, use the project's intended target version. Do not use APIs newer than the module's `go` directive until the project explicitly agrees to upgrade it.
+
+## Deep Dives
+
+- **[Versioning & MVS](./references/versioning.md)** — Semantic versioning rules (major.minor.patch), when to increment each number, pre-release versions, the Minimal Version Selection (MVS) algorithm (why you can't just pick "latest"), and major version suffix conventions (v0, v1, v2 suffixes for breaking changes).
+
+- **[Auditing Dependencies](./references/auditing.md)** — Vulnerability scanning with `govulncheck`, tracking outdated dependencies, analyzing which dependencies make the binary large (`goweight`), and distinguishing test-only vs binary dependencies to keep `go.mod` clean.
+
+- **[Dependency Conflicts & Resolution](./references/conflicts.md)** — Diagnosing version conflicts (what `go get` does when you request incompatible versions), resolution strategies (`replace` directives for local development, `exclude` for broken versions, `retract` for published versions that should be skipped), and workflows for conflicts across your dependency tree.
+
+- **[Go Workspaces](./references/workspaces.md)** — `go.work` files for multi-module development (e.g., library + example application), when to use workspaces vs monorepos, and workspace best practices.
+
+- **[Automated Dependency Updates](./references/automated-updates.md)** — Setting up Dependabot or Renovate for automatic dependency update PRs, auto-merge strategies (when to merge automatically vs require review), and handling security updates.
+
+- **[Visualizing the Dependency Graph](./references/visualization.md)** — `go mod graph` to inspect the full dependency tree, `modgraphviz` to visualize it, and interactive tools to find which dependency chains cause bloat.
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-continuous-integration` skill for Dependabot/Renovate CI setup
+- → See `samber/cc-skills-golang@golang-security` skill for vulnerability scanning with govulncheck
+- → See `samber/cc-skills-golang@golang-popular-libraries` skill for vetted library recommendations
+
+## Quick Reference
+
+```bash
+# Start a new module
+go mod init github.com/user/project
+
+# Add a dependency
+go get github.com/google/uuid@v1.6.0
+
+# Upgrade all deps (patch only, safer)
+go get -u=patch ./...
+
+# Remove unused deps
+go mod tidy
+
+# Check for vulnerabilities
+govulncheck ./...   # or: go tool govulncheck ./...
+
+# Check for outdated deps
+go list -u -m -json all | go-mod-outdated -update -direct
+
+# Analyze binary size by dependency
+goweight
+
+# Understand why a dep exists
+go mod why -m github.com/some/module
+
+# Visualize dependency graph
+go mod graph | modgraphviz | dot -Tpng -o deps.png
+
+# Verify checksums
+go mod verify
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/evals/evals.json
new file mode 100644
index 00000000..7a8fbff1
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/evals/evals.json
@@ -0,0 +1,153 @@
+[
+  {
+    "id": 1,
+    "name": "ask-before-adding-dependency",
+    "description": "Tests whether the AI agent asks for user confirmation before adding a new dependency via go get",
+    "prompt": "I need to parse YAML configuration files in my Go project. Add the dependency and write the config parsing code.",
+    "trap": "Without the skill, the model immediately runs go get for a YAML library without asking the user for confirmation, presenting alternatives, or checking stdlib",
+    "assertions": [
+      {"id": "1.1", "text": "Asks the user for confirmation before running go get to add a new dependency"},
+      {"id": "1.2", "text": "Presents the package name and import path"},
+      {"id": "1.3", "text": "Mentions whether the standard library covers the use case (encoding/json does, but YAML does not have stdlib support)"},
+      {"id": "1.4", "text": "Lists known alternatives (e.g., gopkg.in/yaml.v3, github.com/goccy/go-yaml)"},
+      {"id": "1.5", "text": "Does NOT silently run go get without asking first"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "go-sum-must-be-committed",
+    "description": "Tests whether the model insists go.sum must be committed to version control",
+    "prompt": "I'm setting up a new Go project. My .gitignore currently includes go.sum because it's auto-generated and I don't want to clutter the repo with generated files. Is this okay?",
+    "trap": "Without the skill, the model might agree that auto-generated files can be gitignored, missing that go.sum is critical for supply-chain security",
+    "assertions": [
+      {"id": "2.1", "text": "Strongly advises against gitignoring go.sum"},
+      {"id": "2.2", "text": "Explains that go.sum contains cryptographic checksums for dependency verification"},
+      {"id": "2.3", "text": "Explains the supply-chain security risk: without go.sum, a compromised proxy could substitute malicious code"},
+      {"id": "2.4", "text": "Mentions go mod verify as the mechanism that uses go.sum for integrity checking"},
+      {"id": "2.5", "text": "Recommends removing go.sum from .gitignore"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "patch-only-upgrade-preference",
+    "description": "Tests whether the model prefers go get -u=patch over go get -u for routine updates",
+    "prompt": "I want to update all my Go dependencies to the latest versions. What command should I run?",
+    "trap": "Without the skill, the model suggests go get -u ./... which upgrades to latest minor/patch, potentially introducing breaking behavioral changes",
+    "assertions": [
+      {"id": "3.1", "text": "Recommends go get -u=patch ./... as the safer default for routine updates"},
+      {"id": "3.2", "text": "Explains that -u=patch only upgrades patch versions which have no API changes per semver"},
+      {"id": "3.3", "text": "Explains that -u (without =patch) upgrades minor versions too, which can change behavior"},
+      {"id": "3.4", "text": "Mentions running go mod tidy after upgrading"},
+      {"id": "3.5", "text": "Does NOT recommend go get -u ./... without warning about the risk of minor version upgrades"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "mvs-algorithm-understanding",
+    "description": "Tests understanding of Minimal Version Selection — Go selects the minimum satisfying version, not the latest",
+    "prompt": "In my Go project, module A requires pkg@v1.2.0 and module B requires pkg@v1.3.0. My go.mod does not mention pkg directly. Which version of pkg will Go select and why?",
+    "trap": "Without the skill, the model might say Go selects the latest available version of pkg (like npm/pip would), rather than the minimum required version (v1.3.0)",
+    "assertions": [
+      {"id": "4.1", "text": "Correctly states that Go selects v1.3.0 (not the latest available version)"},
+      {"id": "4.2", "text": "Explains Minimal Version Selection (MVS): Go picks the highest minimum required, not the latest available"},
+      {"id": "4.3", "text": "Distinguishes MVS from other package managers (npm, pip, cargo) that select the latest compatible"},
+      {"id": "4.4", "text": "Mentions that MVS provides deterministic builds without a lock file"},
+      {"id": "4.5", "text": "Explains that go.sum is integrity verification, not version locking"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "major-version-suffix-rule",
+    "description": "Tests knowledge of Go's major version suffix convention for v2+",
+    "prompt": "I'm publishing a Go library and need to release v2.0.0 with breaking changes. What do I need to change in my module path and imports?",
+    "trap": "Without the skill, the model might just change the git tag to v2.0.0 without updating the module path to include /v2, breaking the import compatibility rule",
+    "assertions": [
+      {"id": "5.1", "text": "States that the module path in go.mod must include /v2 suffix (e.g., github.com/example/pkg/v2)"},
+      {"id": "5.2", "text": "States that all import paths must be updated to include /v2"},
+      {"id": "5.3", "text": "Explains this is Go's import compatibility rule — different major versions are separate modules"},
+      {"id": "5.4", "text": "Mentions that v0 and v1 do NOT have a suffix"},
+      {"id": "5.5", "text": "Notes that this allows v1 and v2 to coexist in the same build"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "replace-directive-library-warning",
+    "description": "Tests that the model warns about replace directives being ignored when the module is used as a dependency",
+    "prompt": "I'm developing a Go library and I need to use a fork of one of my dependencies for a bug fix. I added a replace directive in my go.mod. Will consumers of my library use the fork too?",
+    "trap": "Without the skill, the model might say yes, missing that replace directives only apply in the main module and are ignored when used as a dependency",
+    "assertions": [
+      {"id": "6.1", "text": "Clearly states that replace directives only take effect in the main module's go.mod"},
+      {"id": "6.2", "text": "States that consumers of the library will NOT use the fork — replace is ignored when the module is consumed as a dependency"},
+      {"id": "6.3", "text": "Recommends removing replace directives before publishing a library"},
+      {"id": "6.4", "text": "Suggests alternative solutions (e.g., upstream the fix, publish the fork as a separate module)"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "tool-directives",
+    "description": "Tests whether the model knows Go 1.24+ tool directives for pinning CLI tool versions in go.mod",
+    "prompt": "My Go project uses golangci-lint and govulncheck. I want to ensure all developers and CI use the exact same versions of these tools. How do I pin them?",
+    "trap": "Without the skill, the model suggests go install @latest in CI, a Makefile, or the old tools.go blank-import workaround, missing Go 1.24+ tool directives that pin versions via go.mod",
+    "assertions": [
+      {"id": "7.1", "text": "Recommends Go 1.24+ go.mod tool directives"},
+      {"id": "7.2", "text": "Uses go get -tool to add golangci-lint and govulncheck"},
+      {"id": "7.3", "text": "Uses go tool to run the pinned tools reproducibly"},
+      {"id": "7.4", "text": "Mentions running go mod tidy and reviewing go.mod/go.sum after adding tools"},
+      {"id": "7.5", "text": "Does NOT create a new tools.go blank-import file unless the module targets Go <1.24"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "govulncheck-call-path-analysis",
+    "description": "Tests understanding that govulncheck does static analysis to find actually-called vulnerable functions, not just dependency presence",
+    "prompt": "My Go project has a dependency flagged by a CVE scanner. But I only use a small subset of the library's API. Is there a way to check if the vulnerability actually affects my code?",
+    "trap": "Without the skill, the model suggests just upgrading the dependency or manually reviewing the CVE, missing govulncheck's call-path analysis that filters by actual usage",
+    "assertions": [
+      {"id": "8.1", "text": "Recommends govulncheck as the tool to check if the vulnerability is actually reachable from your code"},
+      {"id": "8.2", "text": "Explains that govulncheck uses static analysis to trace call paths to vulnerable functions"},
+      {"id": "8.3", "text": "Explains that if your code never calls the affected function, govulncheck will NOT flag it"},
+      {"id": "8.4", "text": "Shows the govulncheck ./... command"},
+      {"id": "8.5", "text": "Distinguishes govulncheck from generic CVE scanners that flag any dependency presence regardless of usage"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "go-work-sum-gitignore",
+    "description": "Tests that go.work.sum should not be committed while go.sum should be committed",
+    "prompt": "I'm setting up a Go workspace with go.work for local multi-module development. Which workspace files should I commit to git?",
+    "trap": "Without the skill, the model might treat go.work.sum the same as go.sum (commit both), but go.work.sum should NOT be committed",
+    "assertions": [
+      {"id": "9.1", "text": "States that go.work.sum should NOT be committed to version control"},
+      {"id": "9.2", "text": "Recommends adding go.work.sum to .gitignore"},
+      {"id": "9.3", "text": "Explains that go.work is for development only and does not affect published module consumers"},
+      {"id": "9.4", "text": "Distinguishes this from go.sum which MUST be committed"},
+      {"id": "9.5", "text": "May mention that go.work itself can optionally be committed depending on team preference"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "exclude-vs-retract-distinction",
+    "description": "Tests understanding of the difference between exclude (consumer-side) and retract (author-side) directives",
+    "prompt": "I published a Go library version v1.3.0 that has a critical bug. How do I prevent users from downloading it? Also, one of my dependencies has a buggy version — how do I skip it in my project?",
+    "trap": "Without the skill, the model conflates exclude and retract, or uses them interchangeably",
+    "assertions": [
+      {"id": "10.1", "text": "Uses retract for the published library (author-side: marks own version as broken)"},
+      {"id": "10.2", "text": "Uses exclude for the buggy dependency (consumer-side: skips a specific version of someone else's module)"},
+      {"id": "10.3", "text": "Explains that retract goes in the library's own go.mod and warns users via go list"},
+      {"id": "10.4", "text": "Explains that exclude redirects to the next higher available version"},
+      {"id": "10.5", "text": "Notes that retracted versions are still downloadable but not selected by default"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "test-dependency-upgrade-flag",
+    "description": "Tests knowledge of the -t flag for including test dependencies in upgrades",
+    "prompt": "I ran go get -u ./... to upgrade my Go dependencies, but my test dependencies (like testify) weren't upgraded. Why?",
+    "trap": "Without the skill, the model doesn't know about the -t flag and suggests upgrading test deps individually",
+    "assertions": [
+      {"id": "11.1", "text": "Explains that go get -u ./... excludes test-only dependencies by default"},
+      {"id": "11.2", "text": "Recommends go get -u -t ./... to include test dependencies in the upgrade"},
+      {"id": "11.3", "text": "Explains the difference between -u (production deps) and -u -t (production + test deps)"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/auditing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/auditing.md
new file mode 100644
index 00000000..9883dcf1
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/auditing.md
@@ -0,0 +1,84 @@
+# Auditing Dependencies
+
+## Test-Only vs Binary Dependencies
+
+Go's `go.mod` does **not** distinguish between test-only and production dependencies. All modules appear together, with `// indirect` marking transitive dependencies.
+
+### What Gets Included in Your Binary
+
+- `*_test.go` files are **never** compiled by `go build` — only by `go test`
+- Packages imported only by test files are not linked into the final binary
+- However, their modules still appear in `go.mod`
+
+### Module Graph Pruning (Go 1.17+)
+
+With `go 1.17` or higher in `go.mod`, Go prunes the module graph: transitive dependencies needed only for tests of other modules are excluded from the build graph. This reduces `go.mod` size and avoids downloading unnecessary modules.
+
+### Upgrading With or Without Test Dependencies
+
+```bash
+go get -u ./...       # Upgrade deps, EXCLUDING test-only deps
+go get -u -t ./...    # Upgrade deps, INCLUDING test-only deps
+```
+
+### Impact on Binary Size
+
+To check whether a large dependency is actually linked into your binary (vs. only used in tests), use `goweight` or `go-size-analyzer` — if the package doesn't appear in the binary breakdown, it's test-only and not contributing to binary size.
+
+## Vulnerability Scanning with govulncheck
+
+`govulncheck` reports known vulnerabilities that affect your code. It uses static analysis to narrow reports to vulnerabilities in code paths your project actually calls — unlike generic CVE scanners that flag every dependency regardless of usage.
+
+```bash
+# Scan source code (most common)
+govulncheck ./...
+# Or, when govulncheck is pinned with a Go 1.24+ tool directive:
+go tool govulncheck ./...
+
+# Scan a compiled binary
+govulncheck -mode=binary ./bin/myapp
+
+# JSON output (for CI integration)
+govulncheck -format json ./...
+
+# Include test code in analysis
+govulncheck -test ./...
+```
+
+Output shows the vulnerability ID, affected module, fixed version, and the call trace from your code to the vulnerable function. If a vulnerability exists in a dependency but your code never calls the affected function, `govulncheck` does not flag it.
+
+For CI pipeline integration, see the `samber/cc-skills-golang@golang-continuous-integration` skill.
+
+## Tracking Outdated Dependencies with go-mod-outdated
+
+`psampaz/go-mod-outdated` lists outdated direct dependencies with available updates.
+
+```bash
+# Show outdated direct dependencies with available updates
+go list -u -m -json all | go-mod-outdated -update -direct
+
+# Fail in CI if dependencies are outdated
+go list -u -m -json all | go-mod-outdated -update -direct -ci
+
+# Markdown output
+go list -u -m -json all | go-mod-outdated -update -direct -style markdown
+```
+
+Output columns: MODULE, CURRENT version, WANTED (latest minor/patch), LATEST (latest overall), and VALID TIMESTAMPS (warns if an "update" is chronologically older than current).
+
+## Analyzing Dependency Size with goweight
+
+`jondot/goweight` lists every package linked into the binary sorted by size contribution. It helps identify bloated dependencies and evaluate whether a lighter alternative exists.
+
+```bash
+goweight          # Sort by size
+goweight --json   # JSON output for CI tracking
+```
+
+**Modern alternative**: [go-size-analyzer](https://github.com/Zxilly/go-size-analyzer) (`gsa`) supports ELF, Mach-O, PE, and WebAssembly formats with interactive HTML/SVG visualization:
+
+```bash
+go get -tool github.com/Zxilly/go-size-analyzer/cmd/gsa@latest
+go build -o ./myapp ./cmd/myapp
+go tool gsa -f html -o size-report.html ./myapp
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/automated-updates.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/automated-updates.md
new file mode 100644
index 00000000..1ce6aa35
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/automated-updates.md
@@ -0,0 +1,35 @@
+# Automated Dependency Updates
+
+Automate minor/patch dependency updates to reduce maintenance burden and stay current with security fixes. This requires a solid CI pipeline — tests and linting must pass before any auto-merge.
+
+## Dependabot vs Renovate
+
+| Feature | Dependabot | Renovate |
+| --- | --- | --- |
+| Platform | GitHub only | GitHub, GitLab, Bitbucket, self-hosted |
+| `go mod tidy` | Automatic | Opt-in (`gomodTidy`) |
+| Automerge | Separate workflow | Native support |
+| Grouping | Pattern-based | More flexible rules |
+| Monorepo support | Basic | Go workspaces aware |
+| Regex managers | No | Yes (Dockerfiles, Makefiles, etc) |
+
+**Renovate is generally more mature and configurable.** Dependabot is simpler to set up for GitHub-only projects.
+
+## Auto-Merge Strategy
+
+- **Minor and patch updates**: Auto-merge only after CI passes (tests + lint + govulncheck) and the package is low-risk for the project
+- **Major updates**: Create PR for manual review (may contain breaking changes)
+- **Security updates**: Auto-merge regardless of version bump type
+
+For workflow configuration files (dependabot.yml, renovate.json, auto-merge workflows), see the `samber/cc-skills-golang@golang-continuous-integration` skill.
+
+## Update Verification
+
+Before committing a dependency update:
+
+0. Changelogs may suggest improvements applicable to the project.
+1. Run `go test ./...` and `go build ./...`
+2. Scan with `govulncheck ./...` or `go tool govulncheck ./...`
+3. Release notes/changelogs for libraries that affect persistence, serialization, networking, authentication, authorization, cryptography, or public APIs may contain important information about breaking changes
+4. Major version upgrades may contain breaking changes — the package's changelog documents them
+5. New APIs or patterns introduced in the updated version may offer improvements worth considering
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/conflicts.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/conflicts.md
new file mode 100644
index 00000000..19ed2eb7
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/conflicts.md
@@ -0,0 +1,75 @@
+# Dependency Conflicts & Resolution
+
+## Diagnosing Conflicts
+
+```bash
+# See why a module is in your build
+go mod why -m github.com/some/module
+
+# See which version is selected
+go list -m github.com/some/module
+
+# See the full requirement graph
+go mod graph
+
+# List all modules in the build
+go list -m all
+```
+
+## Resolution Strategies
+
+**Force a specific version** (when two deps require incompatible versions):
+
+```bash
+go mod edit -replace=example.com/pkg@v1.2.0=example.com/pkg@v1.3.1
+```
+
+```go
+// go.mod
+replace example.com/pkg v1.2.0 => example.com/pkg v1.3.1
+```
+
+**Use a local fork** (for debugging or patching):
+
+```go
+replace example.com/pkg => ../my-local-fork
+```
+
+**Block a problematic version**:
+
+```bash
+go mod edit -exclude=example.com/pkg@v1.3.0
+```
+
+When a version is excluded, any requirement on that version is redirected to the next higher available version.
+
+**Force upgrade a transitive dependency**:
+
+```bash
+go get github.com/transitive/dep@v1.5.0
+```
+
+This adds an explicit requirement in your `go.mod`, overriding whatever the transitive dependency chain would select via MVS.
+
+## Resolution Workflow
+
+1. Run `go mod graph` and `go mod why -m <module>` to understand the dependency chain
+2. Identify which of your direct dependencies pulls in the conflicting version
+3. Try upgrading the direct dependency first: `go get github.com/direct/dep@latest`
+4. If that doesn't resolve it, use `replace` or `exclude` as a temporary fix
+5. Run `go mod tidy` to clean up
+6. Verify with `go build ./...` and `go test ./...`
+
+**Important**: `replace` and `exclude` directives only take effect in the **main module's** `go.mod`. They are ignored when your module is used as a dependency. Remove `replace` directives before publishing a library.
+
+## Retract (For Module Authors)
+
+Mark versions as broken or accidentally published:
+
+```go
+// go.mod
+retract v1.0.0         // Contains critical bug in auth
+retract [v1.1.0, v1.2.0] // Range of broken versions
+```
+
+Retracted versions are still downloadable but `go get` will not select them by default, and `go list -m -u` warns about them.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/versioning.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/versioning.md
new file mode 100644
index 00000000..54c069b7
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/versioning.md
@@ -0,0 +1,57 @@
+# Versioning & Minimal Version Selection
+
+## Semantic Versioning (SemVer)
+
+Go modules use **`vMAJOR.MINOR.PATCH`** (the `v` prefix is required):
+
+- **MAJOR**: Breaking changes to the public API
+- **MINOR**: Backward-compatible new functionality
+- **PATCH**: Backward-compatible bug fixes
+
+### Stability Rules
+
+| Version     | Stability                                 |
+| ----------- | ----------------------------------------- |
+| `v0.x.x`    | Unstable — no compatibility guarantees    |
+| `v1.x.x`+   | Stable — backward-compatible within major |
+| Pre-release | Unstable (e.g., `v1.5.0-beta.1`)          |
+
+### Major Version Suffix Rule
+
+For `v2` and above, the module path must include a `/vN` suffix. This is Go's import compatibility rule — different major versions are treated as entirely separate modules, allowing them to coexist in the same build:
+
+```go
+// go.mod
+module github.com/example/pkg/v2
+
+// Import in code
+import "github.com/example/pkg/v2/subpkg"
+```
+
+Tags: `v2.0.0`, `v2.1.0`, etc. The `v0` and `v1` versions have no suffix.
+
+### Special Cases
+
+- **Pseudo-versions**: For untagged commits — `v0.0.0-20210101120000-abcdef123456` (base version + timestamp + commit hash)
+- **`+incompatible`**: Marks `v2+` modules that have not adopted the `/vN` path convention
+- **`gopkg.in`**: Always uses a version suffix with a dot — `gopkg.in/yaml.v3`
+
+## Minimal Version Selection (MVS)
+
+Go's dependency resolution algorithm is fundamentally different from npm, pip, or cargo.
+
+### How It Works
+
+Most package managers select the **latest** compatible version of each dependency. Go does the opposite: it selects the **minimum version that satisfies all requirements**. If module A requires `pkg@v1.2.0` and module B requires `pkg@v1.3.0`, MVS selects `v1.3.0` — the highest minimum required, not the latest available.
+
+### Why This Design
+
+- **Deterministic without a lock file**: Given the same `go.mod` inputs, MVS always produces the same build list. `go.sum` is just integrity verification.
+- **High fidelity**: Builds closely match what module authors tested against, since the nearest compatible version is selected rather than the latest.
+- **No solver needed**: The algorithm is simple graph traversal (under 50 lines of code), not an NP-hard constraint satisfaction problem.
+- **Reproducible across machines**: No "works on my machine" from different lock file states.
+
+### Upgrades and Downgrades
+
+- **Upgrade**: `go get pkg@v1.5.0` adds an edge to `v1.5.0` in the module graph and reruns MVS. Only the minimum necessary changes propagate.
+- **Downgrade**: `go get pkg@v1.2.0` removes all versions above `v1.2.0` from the graph, then walks backward to find the latest remaining versions of affected dependencies.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/visualization.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/visualization.md
new file mode 100644
index 00000000..0c0ec249
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/visualization.md
@@ -0,0 +1,48 @@
+# Visualizing the Dependency Graph
+
+## go mod graph (Built-in)
+
+```bash
+go mod graph
+```
+
+Output: each line contains two space-separated fields (module and its requirement) in `path@version` format:
+
+```
+example.com/main github.com/google/uuid@v1.6.0
+example.com/main golang.org/x/text@v0.3.7
+github.com/google/uuid@v1.6.0 golang.org/x/sys@v0.0.0-20210615035016
+```
+
+## go mod why
+
+```bash
+go mod why -m github.com/some/module
+```
+
+Shows the shortest import path from your code to the module — useful for understanding why an unexpected dependency exists.
+
+## Generate a Graph Image with modgraphviz
+
+Pin `modgraphviz` as a module tool, then pipe `go mod graph` into it.
+
+```bash
+go get -tool golang.org/x/exp/cmd/modgraphviz@latest
+go mod graph | go tool modgraphviz | dot -Tpng -o deps.png
+```
+
+Green nodes represent versions selected by MVS (in the final build list). Grey nodes are versions that exist in the requirement graph but are not used.
+
+## Interactive Visualization with go-mod-graph
+
+`go-mod-graph` (samber/go-mod-graph) is a web-based interactive dependency explorer with zoomable graph, module weight indicators, searchable module list, and MVS algorithm visualization.
+
+## Complementary Analysis
+
+Pin `digraph` as a module tool for graph queries.
+
+```bash
+go get -tool golang.org/x/tools/cmd/digraph@latest
+# General graph queries on go mod graph output
+go mod graph | go tool digraph reverse example.com/some/module
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/workspaces.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/workspaces.md
new file mode 100644
index 00000000..08bb9ebd
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-dependency-management/references/workspaces.md
@@ -0,0 +1,27 @@
+# Go Workspaces (go.work)
+
+## go.work vs go.mod
+
+| Scenario                                       | Use       |
+| ---------------------------------------------- | --------- |
+| Single module project                          | `go.mod`  |
+| Developing multiple related local modules      | `go.work` |
+| Monorepo with separate Go modules              | `go.work` |
+| Testing local changes across module boundaries | `go.work` |
+| Published library consumed by others           | `go.mod`  |
+
+## Workspace Commands
+
+```bash
+go work init                    # Initialize workspace
+go work use ./services/auth     # Add module to workspace
+go work use -rm ./old-module    # Remove module from workspace
+go work sync                    # Sync workspace with module changes
+```
+
+## Key Points
+
+- Workspaces eliminate the need for `replace` directives during local development — the workspace automatically resolves local modules
+- **Do not commit `go.work.sum`** to version control (add to `.gitignore`)
+- `go.work` is for development only — it does not affect how consumers of your published modules resolve dependencies
+- For workspace directory structure examples, see the `samber/cc-skills-golang@golang-project-layout` skill
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/SKILL.md
new file mode 100644
index 00000000..e8becc49
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/SKILL.md
@@ -0,0 +1,276 @@
+---
+name: golang-design-patterns
+description: "Idiomatic Golang design patterns — functional options, constructors, error flow and cascading, resource management and lifecycle, graceful shutdown, resilience, architecture, dependency injection, data handling, streaming, and more. Apply when explicitly choosing between architectural patterns, implementing functional options, designing constructor APIs, setting up graceful shutdown, applying resilience patterns, or asking which idiomatic Go pattern fits a specific problem."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.4"
+  openclaw:
+    emoji: "🏗"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion
+---
+
+**Persona:** You are a Go architect who values simplicity and explicitness. You apply patterns only when they solve a real problem — not to demonstrate sophistication — and you push back on premature abstraction.
+
+**Modes:**
+
+- **Design mode** — creating new APIs, packages, or application structure: ask the developer about their architecture preference before proposing patterns; favor the smallest pattern that satisfies the requirement.
+- **Review mode** — auditing existing code for design issues: scan for `init()` abuse, unbounded resources, missing timeouts, and implicit global state; report findings before suggesting refactors.
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-design-patterns` skill takes precedence.
+
+# Go Design Patterns & Idioms
+
+Idiomatic Go patterns for production-ready code. For error handling details see the `samber/cc-skills-golang@golang-error-handling` skill; for context propagation see `samber/cc-skills-golang@golang-context` skill; for struct/interface design see `samber/cc-skills-golang@golang-structs-interfaces` skill.
+
+## Best Practices Summary
+
+1. Constructors SHOULD use **functional options** — they scale better as APIs evolve (one function per option, no breaking changes)
+2. Functional options MUST **return an error** if validation can fail — catch bad config at construction, not at runtime
+3. **Avoid `init()`** — runs implicitly, cannot return errors, makes testing unpredictable. Use explicit constructors
+4. Enums SHOULD **start at 1** (or Unknown sentinel at 0) — Go's zero value silently passes as the first enum member
+5. Error cases MUST be **handled first** with early return — keep happy path flat
+6. **Panic is for bugs, not expected errors** — callers can handle returned errors; panics crash the process
+7. **`defer Close()` immediately after opening** — later code changes can accidentally skip cleanup
+8. **`runtime.AddCleanup`** over `runtime.SetFinalizer` — finalizers are unpredictable and can resurrect objects
+9. Every external call SHOULD **have a timeout** — a slow upstream hangs your goroutine indefinitely
+10. **Limit everything** (pool sizes, queue depths, buffers) — unbounded resources grow until they crash
+11. Retry logic MUST **check context cancellation** between attempts
+12. **Use `strings.Builder`** for concatenation in loops → see `samber/cc-skills-golang@golang-code-style`
+13. string vs []byte: **use `[]byte` for mutation and I/O**, `string` for display and keys — conversions allocate
+14. Iterators (Go 1.23+): **use for lazy evaluation** — avoid loading everything into memory
+15. **Stream large transfers** — loading millions of rows causes OOM; stream keeps memory constant
+16. `//go:embed` for **static assets** — embeds at compile time, eliminates runtime file I/O errors
+17. **Use `crypto/rand`** for keys/tokens — `math/rand` is predictable → see `samber/cc-skills-golang@golang-security`
+18. Regexp MUST be **compiled once at package level** — compilation is O(n) and allocates
+19. Compile-time interface checks: **`var _ Interface = (*Type)(nil)`**
+20. **A little recode > a big dependency** — each dep adds attack surface and maintenance burden
+21. **Design for testability** — accept interfaces, inject dependencies
+
+## Constructor Patterns: Functional Options vs Builder
+
+### Functional Options (Preferred)
+
+```go
+type Server struct {
+    addr         string
+    readTimeout  time.Duration
+    writeTimeout time.Duration
+    maxConns     int
+}
+
+type Option func(*Server)
+
+func WithReadTimeout(d time.Duration) Option {
+    return func(s *Server) { s.readTimeout = d }
+}
+
+func WithWriteTimeout(d time.Duration) Option {
+    return func(s *Server) { s.writeTimeout = d }
+}
+
+func WithMaxConns(n int) Option {
+    return func(s *Server) { s.maxConns = n }
+}
+
+func NewServer(addr string, opts ...Option) *Server {
+    // Default options
+    s := &Server{
+        addr:         addr,
+        readTimeout:  5 * time.Second,
+        writeTimeout: 10 * time.Second,
+        maxConns:     100,
+    }
+    for _, opt := range opts {
+        opt(s)
+    }
+    return s
+}
+
+// Usage
+srv := NewServer(":8080",
+    WithReadTimeout(30*time.Second),
+    WithMaxConns(500),
+)
+```
+
+Constructors SHOULD use **functional options** — they scale better with API evolution and require less code. Use builder pattern only if you need complex validation between configuration steps.
+
+## Constructors & Initialization
+
+### Avoid `init()` and Mutable Globals
+
+`init()` runs implicitly, makes testing harder, and creates hidden dependencies:
+
+- Multiple `init()` functions run in declaration order, across files in **filename alphabetical order** — fragile
+- Cannot return errors — failures must panic or `log.Fatal`
+- Runs before `main()` and tests — side effects make tests unpredictable
+
+```go
+// Bad — hidden global state
+var db *sql.DB
+
+func init() {
+    var err error
+    db, err = sql.Open("postgres", os.Getenv("DATABASE_URL"))
+    if err != nil {
+        log.Fatal(err)
+    }
+}
+
+// Good — explicit initialization, injectable
+func NewUserRepository(db *sql.DB) *UserRepository {
+    return &UserRepository{db: db}
+}
+```
+
+### Enums: Start at 1
+
+Zero values should represent invalid/unset state:
+
+```go
+type Status int
+
+const (
+    StatusUnknown Status = iota // 0 = invalid/unset
+    StatusActive                // 1
+    StatusInactive              // 2
+    StatusSuspended             // 3
+)
+```
+
+### Compile Regexp Once
+
+```go
+// Good — compiled once at package level
+var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
+
+func ValidateEmail(email string) bool {
+    return emailRegex.MatchString(email)
+}
+```
+
+### Use `//go:embed` for Static Assets
+
+```go
+import "embed"
+
+//go:embed templates/*
+var templateFS embed.FS
+
+//go:embed version.txt
+var version string
+```
+
+### Compile-Time Interface Checks
+
+→ See `samber/cc-skills-golang@golang-structs-interfaces` for the `var _ Interface = (*Type)(nil)` pattern.
+
+## Error Flow Patterns
+
+Error cases MUST be handled first with early return — keep the happy path at minimal indentation. → See `samber/cc-skills-golang@golang-code-style` for the full pattern and examples.
+
+### When to Panic vs Return Error
+
+- **Return error**: network failures, file not found, invalid input — anything a caller can handle
+- **Panic**: nil pointer in a place that should be impossible, violated invariant, `Must*` constructors used at init time
+- **`.Close()` / `Flush()` errors**: read-only cleanup can often use `defer f.Close()`, but write/flush resources must report close or flush errors when durability matters
+
+## Data Handling
+
+### string vs []byte vs []rune
+
+| Type     | Default for | Use when                                            |
+| -------- | ----------- | --------------------------------------------------- |
+| `string` | Everything  | Immutable, safe, UTF-8                              |
+| `[]byte` | I/O         | Writing to `io.Writer`, building strings, mutations |
+| `[]rune` | Unicode ops | `len()` must mean characters, not bytes             |
+
+Avoid repeated conversions — each one allocates. Stay in one type until you need the other.
+
+### Iterators & Streaming for Large Data
+
+Use iterators (Go 1.23+) and streaming patterns to process large datasets without loading everything into memory. For large transfers between services (e.g., 1M rows DB to HTTP), stream to prevent OOM.
+
+For code examples, see [Data Handling Patterns](references/data-handling.md).
+
+## Resource Management
+
+`defer Close()` immediately after opening — don't wait, don't forget:
+
+```go
+f, err := os.Open(path)
+if err != nil {
+    return err
+}
+defer f.Close() // right here, not 50 lines later
+
+rows, err := db.QueryContext(ctx, query)
+if err != nil {
+    return err
+}
+defer rows.Close()
+```
+
+For graceful shutdown, resource pools, and `runtime.AddCleanup`, see [Resource Management](references/resource-management.md).
+
+## Resilience & Limits
+
+### Timeout Every External Call
+
+```go
+ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
+defer cancel()
+
+resp, err := httpClient.Do(req.WithContext(ctx))
+```
+
+### Retry & Context Checks
+
+Retry logic MUST check `ctx.Err()` between attempts and use exponential/linear backoff via `select` on `ctx.Done()`. Long loops MUST check `ctx.Err()` periodically. → See `samber/cc-skills-golang@golang-context` skill.
+
+## Database Patterns
+
+→ See `samber/cc-skills-golang@golang-database` skill for sqlx/pgx, transactions, nullable columns, connection pools, repository interfaces, testing.
+
+## Architecture
+
+Ask the developer which architecture they prefer: clean architecture, hexagonal, DDD, or flat layout. Don't impose complex architecture on a small project.
+
+Core principles regardless of architecture:
+
+- **Keep domain pure** — no framework dependencies in the domain layer
+- **Fail fast** — validate at boundaries, trust internal code
+- **Make illegal states unrepresentable** — use types to enforce invariants
+- **Respect 12-factor app** principles — → see `samber/cc-skills-golang@golang-project-layout`
+
+## Detailed Guides
+
+| Guide | Scope |
+| --- | --- |
+| [Architecture Patterns](references/architecture.md) | High-level principles, when each architecture fits |
+| [Clean Architecture](references/clean-architecture.md) | Use cases, dependency rule, layered adapters |
+| [Hexagonal Architecture](references/hexagonal-architecture.md) | Ports and adapters, domain core isolation |
+| [Domain-Driven Design](references/ddd.md) | Aggregates, value objects, bounded contexts |
+
+## Code Philosophy
+
+- **Avoid repetitive code** — but don't abstract prematurely
+- **Minimize dependencies** — a little recode > a big dependency
+- **Design for testability** — accept interfaces, inject dependencies, keep functions pure
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-data-structures` skill for data structure selection, internals, and container/ packages
+- → See `samber/cc-skills-golang@golang-error-handling` skill for error wrapping, sentinel errors, and the single handling rule
+- → See `samber/cc-skills-golang@golang-structs-interfaces` skill for interface design and composition
+- → See `samber/cc-skills-golang@golang-concurrency` skill for goroutine lifecycle and graceful shutdown
+- → See `samber/cc-skills-golang@golang-context` skill for timeout and cancellation patterns
+- → See `samber/cc-skills-golang@golang-project-layout` skill for architecture and directory structure
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/evals/evals.json
new file mode 100644
index 00000000..5f9b8bf8
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/evals/evals.json
@@ -0,0 +1,251 @@
+[
+  {
+    "id": 1,
+    "name": "functional-options-over-builder",
+    "description": "Tests whether the model recommends functional options (not builder pattern) as the preferred constructor pattern in Go, and whether options return errors for validation",
+    "prompt": "I need to create a Go HTTP server struct with optional configuration: read timeout, write timeout, max connections, TLS config, and a logger. Design the constructor API. The config will grow over time as we add features.",
+    "trap": "Without the skill, the model may default to a builder pattern, config struct, or positional arguments instead of functional options. It may also forget that options should return errors when validation can fail.",
+    "assertions": [
+      {"id": "1.1", "text": "Uses functional options pattern (Option type as func that modifies the struct)"},
+      {"id": "1.2", "text": "Constructor accepts variadic ...Option parameter"},
+      {"id": "1.3", "text": "Each option is a With* function returning an Option"},
+      {"id": "1.4", "text": "Sets sensible defaults inside the constructor before applying options"},
+      {"id": "1.5", "text": "Mentions that functional options should return an error if validation can fail, or demonstrates error-returning option variant"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "avoid-init-function",
+    "description": "Tests whether the model avoids init() for database initialization and uses explicit constructors instead",
+    "prompt": "I'm writing a Go web service. I want to set up the database connection pool when the application starts. Here's my approach:\n\n```go\nvar db *sql.DB\n\nfunc init() {\n    var err error\n    db, err = sql.Open(\"postgres\", os.Getenv(\"DATABASE_URL\"))\n    if err != nil {\n        log.Fatal(err)\n    }\n}\n```\n\nIs this a good pattern? How should I improve it?",
+    "trap": "Without the skill, the model may accept the init() pattern as fine or only suggest minor improvements. The skill explicitly warns against init() for hidden dependencies and testability issues.",
+    "assertions": [
+      {"id": "2.1", "text": "Explicitly recommends against using init() for database initialization"},
+      {"id": "2.2", "text": "Mentions that init() makes testing harder or unpredictable"},
+      {"id": "2.3", "text": "Mentions that init() cannot return errors (must panic or log.Fatal)"},
+      {"id": "2.4", "text": "Suggests explicit constructor or initialization function (e.g. NewUserRepository(db))"},
+      {"id": "2.5", "text": "Mentions that init() runs before main/tests creating hidden dependencies"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "enum-start-at-one",
+    "description": "Tests whether the model starts Go enums at 1 or uses an Unknown/Invalid sentinel at 0",
+    "prompt": "I need to define a Go enum for order status with values: pending, processing, shipped, delivered, cancelled. Write the type and constants using iota.",
+    "trap": "Without the skill, the model often starts the first meaningful enum value at 0 (iota), making the zero value silently pass as a valid status. The skill says enums SHOULD start at 1 or use an Unknown sentinel at 0.",
+    "assertions": [
+      {"id": "3.1", "text": "Zero value (iota = 0) is either skipped, named Unknown, Invalid, or Unspecified -- not a meaningful business value"},
+      {"id": "3.2", "text": "First meaningful enum value starts at 1 or higher"},
+      {"id": "3.3", "text": "Explains WHY: Go's zero value would silently pass as the first enum member if it were meaningful"},
+      {"id": "3.4", "text": "Uses a custom type (not raw int or string)"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "panic-vs-error-judgment",
+    "description": "Tests whether the model correctly distinguishes when to panic vs return an error",
+    "prompt": "I'm implementing a configuration parser in Go. If the config file has an invalid format, should I panic or return an error? What about if a required field is missing? What about if a developer passes nil to a function that documents it must not be nil?",
+    "trap": "Without the skill, the model may be inconsistent about when to panic. The skill says panic is for bugs (violated invariants, impossible nil), not expected errors (invalid input, missing fields).",
+    "assertions": [
+      {"id": "4.1", "text": "Invalid config format: return error (caller can handle it)"},
+      {"id": "4.2", "text": "Missing required field: return error (expected validation failure)"},
+      {"id": "4.3", "text": "Nil passed to non-nil function: panic is acceptable (violated invariant, bug in caller)"},
+      {"id": "4.4", "text": "Articulates the principle: panic is for bugs/invariant violations, errors are for expected failures"},
+      {"id": "4.5", "text": "Mentions Must* constructor pattern as a valid panic use case (init-time convenience)"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "runtime-addcleanup-over-setfinalizer",
+    "description": "Tests whether the model recommends runtime.AddCleanup over runtime.SetFinalizer for Go 1.24+",
+    "prompt": "I have a Go struct that wraps a C resource handle (via cgo). When the Go object is garbage collected, I need to release the C handle. I'm using Go 1.24. What's the best approach for automatic cleanup?",
+    "trap": "Without the skill, the model almost always suggests runtime.SetFinalizer, which is the older and more well-known API. The skill specifically says to prefer runtime.AddCleanup (Go 1.24+).",
+    "assertions": [
+      {"id": "5.1", "text": "Recommends runtime.AddCleanup as the preferred approach"},
+      {"id": "5.2", "text": "Mentions that AddCleanup supports multiple cleanups on the same object"},
+      {"id": "5.3", "text": "Mentions that AddCleanup avoids object resurrection risk (cleanup receives a copy of the value, not the object)"},
+      {"id": "5.4", "text": "Mentions that AddCleanup works even with cyclic references"},
+      {"id": "5.5", "text": "Either warns against SetFinalizer or explains why AddCleanup is better"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "resource-pool-bounded-channel",
+    "description": "Tests whether the model uses bounded channel-based pools and emphasizes limiting resource pool sizes",
+    "prompt": "I need to implement a connection pool in Go for reusing database connections. I want it to be concurrent-safe and have a maximum size. Design the pool.",
+    "trap": "Without the skill, the model may use sync.Pool (wrong: not bounded, items can be evicted) or an unbounded slice with mutex. The skill says use channels with fixed capacity for bounded allocation.",
+    "assertions": [
+      {"id": "6.1", "text": "Uses a buffered channel (chan *Conn with fixed capacity) as the pool mechanism"},
+      {"id": "6.2", "text": "Pool has a maximum size / bounded capacity"},
+      {"id": "6.3", "text": "Get operation uses select with context for timeout/cancellation"},
+      {"id": "6.4", "text": "Put operation handles pool-full case (discards excess connections)"},
+      {"id": "6.5", "text": "Does NOT use sync.Pool as the primary pooling mechanism (sync.Pool has no size guarantee and items can be reclaimed)"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "graceful-shutdown-signal-notifycontext",
+    "description": "Tests whether the model uses signal.NotifyContext for graceful shutdown",
+    "prompt": "I'm building a Go HTTP server that needs to handle SIGINT and SIGTERM for graceful shutdown. Show me how to implement this properly.",
+    "trap": "Without the skill, the model may use a raw os.Signal channel with signal.Notify instead of signal.NotifyContext. The skill specifically says to use signal.NotifyContext.",
+    "assertions": [
+      {"id": "7.1", "text": "Uses signal.NotifyContext (not raw signal.Notify with a channel)"},
+      {"id": "7.2", "text": "Listens for both SIGINT and SIGTERM"},
+      {"id": "7.3", "text": "Starts the HTTP server in a goroutine"},
+      {"id": "7.4", "text": "Creates a separate timeout context for the shutdown phase (e.g. context.WithTimeout for draining)"},
+      {"id": "7.5", "text": "Closes other resources (DB, queues) after server shutdown"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "iterator-streaming-large-data",
+    "description": "Tests whether the model uses iterators/streaming instead of loading all data into memory for large datasets",
+    "prompt": "I need to export 2 million user records from a PostgreSQL database to a JSON HTTP response in Go. The users table has columns: id, name, email, created_at. Write the handler.",
+    "trap": "Without the skill, the model typically loads all rows into a []User slice, then json.Marshal the whole thing. The skill says to stream large transfers to prevent OOM.",
+    "assertions": [
+      {"id": "8.1", "text": "Does NOT load all 2M rows into a slice in memory"},
+      {"id": "8.2", "text": "Streams the JSON response (writes records one at a time to the ResponseWriter)"},
+      {"id": "8.3", "text": "Uses rows.Next() loop or iter.Seq2 iterator pattern"},
+      {"id": "8.4", "text": "Defers rows.Close() immediately after query"},
+      {"id": "8.5", "text": "Mentions OOM risk or memory concern as motivation for streaming"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "regexp-compile-once",
+    "description": "Tests whether the model compiles regexps at package level, not inside functions",
+    "prompt": "Write a Go function that validates email addresses using a regular expression. It will be called thousands of times per second in an HTTP handler.",
+    "trap": "Without the skill, the model often compiles the regexp inside the function on every call. The skill says regexp MUST be compiled once at package level.",
+    "assertions": [
+      {"id": "9.1", "text": "Compiles the regexp at package level (var emailRegex = regexp.MustCompile(...))"},
+      {"id": "9.2", "text": "Does NOT compile the regexp inside the validation function"},
+      {"id": "9.3", "text": "Uses regexp.MustCompile (not regexp.Compile) for package-level initialization"},
+      {"id": "9.4", "text": "Explains WHY: compilation is O(n) and allocates, so doing it per-call is wasteful"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "architecture-right-sizing",
+    "description": "Tests whether the model avoids over-architecting small projects and asks for preferences",
+    "prompt": "I'm starting a new Go project: a CLI tool that reads a CSV file, transforms the data, and writes it to stdout. It will be about 200 lines of code. What architecture and directory structure should I use?",
+    "trap": "Without the skill, the model may suggest clean architecture, hexagonal patterns, handler/service/repository layers, or DI frameworks for a 200-line CLI. The skill says don't impose complex architecture on small projects.",
+    "assertions": [
+      {"id": "10.1", "text": "Recommends a flat or minimal structure (no multi-layer architecture)"},
+      {"id": "10.2", "text": "Does NOT suggest clean architecture, hexagonal, DDD, or ports and adapters for a 200-line CLI"},
+      {"id": "10.3", "text": "Does NOT suggest dependency injection frameworks"},
+      {"id": "10.4", "text": "Structure has at most cmd/ and possibly internal/, not handler/service/repository layers"},
+      {"id": "10.5", "text": "Mentions that architecture complexity should match project scope"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "hexagonal-vs-clean-architecture",
+    "description": "Tests whether the model correctly distinguishes hexagonal from clean architecture and when each applies",
+    "prompt": "I'm building a Go service (about 8K lines) that processes orders. It needs HTTP and gRPC entry points, plus a message consumer for async events. It talks to PostgreSQL, Stripe, and Redis. Should I use clean architecture or hexagonal architecture? Explain the difference and recommend one.",
+    "trap": "Without the skill, the model may conflate the two architectures or fail to identify that hexagonal is better when multiple entry points are needed. The skill has distinct guides for each.",
+    "assertions": [
+      {"id": "11.1", "text": "Correctly explains that hexagonal uses ports (interfaces) and adapters (implementations) with primary (driving) and secondary (driven) distinction"},
+      {"id": "11.2", "text": "Correctly explains that clean architecture uses dependency rule (dependencies point inward) with entities/use-cases/adapters/frameworks layers"},
+      {"id": "11.3", "text": "Recommends hexagonal for this specific case (multiple entry points: HTTP, gRPC, message consumer)"},
+      {"id": "11.4", "text": "Mentions that both keep domain logic pure and free from infrastructure dependencies"},
+      {"id": "11.5", "text": "Provides a directory structure example with adapter/primary/ and adapter/secondary/ or equivalent hexagonal layout"}
+    ]
+  },
+  {
+    "id": 12,
+    "name": "ddd-aggregate-root-mutations",
+    "description": "Tests whether the model enforces that all mutations go through the aggregate root in DDD",
+    "prompt": "I'm implementing DDD in Go for an e-commerce system. I have an Order aggregate with OrderItems. A user wants to add an item to an existing order. Show me how to structure this. The order should only be editable when in Draft status.",
+    "trap": "Without the skill, the model may allow direct mutation of OrderItems from outside the aggregate, or may not enforce the aggregate root pattern. The skill says all mutations go through the root.",
+    "assertions": [
+      {"id": "12.1", "text": "AddItem is a method on the Order aggregate root (not on OrderItem or a service)"},
+      {"id": "12.2", "text": "Order fields (items, status) are unexported to prevent external mutation"},
+      {"id": "12.3", "text": "AddItem validates the status constraint (only Draft orders are editable)"},
+      {"id": "12.4", "text": "Repository interface is defined in the domain package, not in the infrastructure package"},
+      {"id": "12.5", "text": "Domain types have no infrastructure imports (no sql, no http, no framework dependencies)"}
+    ]
+  },
+  {
+    "id": 13,
+    "name": "ddd-bounded-context-communication",
+    "description": "Tests whether the model uses anti-corruption layers or domain events between bounded contexts, not direct imports",
+    "prompt": "I have two bounded contexts in my Go DDD project: Order and Billing. When an order is placed, the billing context needs to create an invoice. How should these contexts communicate?",
+    "trap": "Without the skill, the model may suggest billing directly importing order's internal types. The skill says contexts communicate through domain events or anti-corruption layers, never by importing each other's internal types.",
+    "assertions": [
+      {"id": "13.1", "text": "Uses domain events (e.g. OrderPlaced event) for cross-context communication"},
+      {"id": "13.2", "text": "Billing context does NOT directly import order's internal domain types"},
+      {"id": "13.3", "text": "Shows or describes an anti-corruption layer that translates order events to billing-specific types"},
+      {"id": "13.4", "text": "Each bounded context has its own domain, application, and adapter layers"},
+      {"id": "13.5", "text": "Mentions that direct type imports between contexts create tight coupling"}
+    ]
+  },
+  {
+    "id": 14,
+    "name": "make-illegal-states-unrepresentable",
+    "description": "Tests whether the model uses types to enforce invariants rather than runtime validation",
+    "prompt": "I have a Go function that sends notifications. It accepts an email address as a string parameter. Sometimes callers pass invalid emails and we only catch it at send time. How can I prevent invalid emails from reaching the send function?",
+    "trap": "Without the skill, the model typically adds validation at the top of the send function. The skill says to make illegal states unrepresentable using types.",
+    "assertions": [
+      {"id": "14.1", "text": "Creates a dedicated Email type (struct with unexported address field)"},
+      {"id": "14.2", "text": "Email can only be created via a constructor (NewEmail) that validates the address"},
+      {"id": "14.3", "text": "The send function accepts the Email type instead of a raw string"},
+      {"id": "14.4", "text": "Explains the principle: make illegal states unrepresentable through the type system"},
+      {"id": "14.5", "text": "The unexported field prevents creating an Email without validation (cannot set address from outside the package)"}
+    ]
+  },
+  {
+    "id": 15,
+    "name": "fail-fast-validate-at-boundaries",
+    "description": "Tests whether the model validates at system boundaries and trusts data internally, rather than re-validating at every layer",
+    "prompt": "I'm building a Go web service with three layers: HTTP handler, service, and repository. Should I validate the request body (user_id, email, age) in all three layers to be safe?",
+    "trap": "Without the skill, the model may suggest defensive validation at every layer for 'safety'. The skill says validate at boundaries, trust internally -- don't re-validate the same data at every layer.",
+    "assertions": [
+      {"id": "15.1", "text": "Recommends validating at the HTTP handler layer (the system boundary)"},
+      {"id": "15.2", "text": "Recommends that the service and repository layers trust the data is already valid"},
+      {"id": "15.3", "text": "Explains WHY: re-validating at every layer clutters code and violates DRY"},
+      {"id": "15.4", "text": "Does NOT suggest adding the same validation checks in all three layers"},
+      {"id": "15.5", "text": "May distinguish between input validation (at boundary) and business rule validation (in domain)"}
+    ]
+  },
+  {
+    "id": 16,
+    "name": "explicit-over-implicit-defaults",
+    "description": "Tests whether the model favors explicit defaults in code over implicit magic (struct tags, reflection)",
+    "prompt": "I want to provide default values for my Go configuration struct. I'm thinking of using struct tags like `default:\"8080\"` with a reflection-based library. Is this a good approach in Go?",
+    "trap": "Without the skill, the model may endorse the struct-tag default approach as convenient. The skill says Go favors explicitness -- explicit defaults visible in code over implicit behavior hidden in struct tags and reflection.",
+    "assertions": [
+      {"id": "16.1", "text": "Recommends against using struct tags + reflection for defaults"},
+      {"id": "16.2", "text": "Suggests explicit defaults in a constructor function (e.g. NewConfig())"},
+      {"id": "16.3", "text": "Explains WHY: Go favors explicitness, struct tags hide behavior that readers cannot see without knowing the library"},
+      {"id": "16.4", "text": "Shows a constructor that returns a Config with default values set explicitly"}
+    ]
+  },
+  {
+    "id": 17,
+    "name": "retry-context-check",
+    "description": "Tests whether retry logic checks context cancellation between attempts",
+    "prompt": "Write a Go retry function that retries a given operation up to 5 times with exponential backoff. The function should be production-ready.",
+    "trap": "Without the skill, the model may implement retry without checking ctx.Err() between attempts. The skill says retry logic MUST check context cancellation between attempts.",
+    "assertions": [
+      {"id": "17.1", "text": "Function accepts a context.Context parameter"},
+      {"id": "17.2", "text": "Checks ctx.Err() or ctx.Done() between retry attempts"},
+      {"id": "17.3", "text": "Uses select with ctx.Done() for the backoff delay (not time.Sleep)"},
+      {"id": "17.4", "text": "Implements exponential backoff"},
+      {"id": "17.5", "text": "Returns the context error if the context is cancelled during retry"}
+    ]
+  },
+  {
+    "id": 18,
+    "name": "ddd-value-object-money",
+    "description": "Tests whether the model implements money as a value object with cents (not float) and currency validation",
+    "prompt": "I'm implementing a pricing system in Go using DDD. I need to represent monetary amounts that support addition and comparison. Design the money type.",
+    "trap": "Without the skill, the model may use float64 for money (precision issues) or make it mutable. The skill shows Money as an immutable value object using int64 cents.",
+    "assertions": [
+      {"id": "18.1", "text": "Uses int64 (cents) not float64 for the amount -- avoids floating point precision issues"},
+      {"id": "18.2", "text": "Includes a currency field"},
+      {"id": "18.3", "text": "Fields are unexported (immutable value object, can only be created via constructor)"},
+      {"id": "18.4", "text": "Add method validates currency match before addition"},
+      {"id": "18.5", "text": "Constructor validates input (e.g. currency is required)"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/architecture.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/architecture.md
new file mode 100644
index 00000000..c527b55b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/architecture.md
@@ -0,0 +1,151 @@
+# Architecture Patterns
+
+## Choose the Right Level of Architecture
+
+Architecture complexity MUST match project scope — don't over-architect small projects. When starting a new project, ask the developer what architecture they prefer:
+
+| Project Size | Recommended Approach |
+| --- | --- |
+| Script / small CLI (<500 lines) | Flat `main.go` + a few files, no layers |
+| Medium service (500-5K lines) | Simple layered: `handler/`, `service/`, `repository/` |
+| Large service / monolith (5K+ lines) | Clean architecture, hexagonal, or DDD — ask the team |
+
+A 100-line CLI does not need a domain layer, ports and adapters, or dependency injection frameworks. Start simple and refactor when complexity demands it.
+
+## Keep Domain Pure
+
+Domain logic MUST remain pure — no framework or infrastructure dependencies. The domain layer contains business logic and types:
+
+```go
+// domain/order.go — pure business logic, no imports from infrastructure
+package domain
+
+type Order struct {
+    ID     string
+    Items  []Item
+    Status OrderStatus
+}
+
+func (o *Order) AddItem(item Item) error {
+    if o.Status != StatusDraft {
+        return ErrOrderNotEditable
+    }
+    o.Items = append(o.Items, item)
+    return nil
+}
+```
+
+Infrastructure concerns (database queries, HTTP clients, message queues) live in separate packages that depend on the domain — never the reverse.
+
+## Fail Fast — Validate at Boundaries
+
+Input MUST be validated at system boundaries (HTTP handlers, CLI argument parsing, message consumers). Once data enters your domain layer, trust it:
+
+```go
+// Handler layer — validate here
+func (h *Handler) CreateOrder(w http.ResponseWriter, r *http.Request) {
+    var req CreateOrderRequest
+    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
+        http.Error(w, "invalid JSON", http.StatusBadRequest)
+        return
+    }
+    if req.UserID == "" {
+        http.Error(w, "user_id is required", http.StatusBadRequest)
+        return
+    }
+    if len(req.Items) == 0 {
+        http.Error(w, "at least one item required", http.StatusBadRequest)
+        return
+    }
+
+    // Domain layer trusts this data is valid
+    order, err := h.service.CreateOrder(r.Context(), req.UserID, req.Items)
+    // ...
+}
+```
+
+Don't re-validate the same data at every layer — it clutters the code and violates DRY.
+
+## Make Illegal States Unrepresentable
+
+Use Go's type system to prevent invalid states from being expressible in code:
+
+```go
+// Bad — status is a raw string, anything goes
+type Order struct {
+    Status string // "pending"? "PENDING"? "active"? anything?
+}
+
+// Good — typed enum constrains the values
+type OrderStatus int
+
+const (
+    OrderStatusUnknown   OrderStatus = iota // 0 = invalid
+    OrderStatusDraft                        // 1
+    OrderStatusConfirmed                    // 2
+    OrderStatusShipped                      // 3
+)
+
+type Order struct {
+    Status OrderStatus
+}
+```
+
+```go
+// Bad — email is a raw string, could be anything
+func SendEmail(to string, body string) error { ... }
+
+// Good — validated type enforces the constraint
+type Email struct {
+    address string // unexported: can only be created via constructor
+}
+
+func NewEmail(raw string) (Email, error) {
+    if !isValidEmail(raw) {
+        return Email{}, fmt.Errorf("invalid email: %s", raw)
+    }
+    return Email{address: raw}, nil
+}
+```
+
+## Detailed Architecture Guides
+
+For projects that warrant a formal architecture (typically 5K+ lines), see the dedicated guides:
+
+- [Domain-Driven Design (DDD)](./ddd.md) — aggregates, value objects, bounded contexts
+- [Clean Architecture](./clean-architecture.md) — use cases, dependency rule, layered adapters
+- [Hexagonal Architecture](./hexagonal-architecture.md) — ports, adapters, domain core isolation
+
+## 12-Factor App Principles
+
+→ See `samber/cc-skills-golang@golang-project-layout` for 12-Factor App conventions.
+
+## Explicit Over Implicit
+
+Go favors explicitness. Code should express its intent clearly without requiring the reader to know hidden conventions:
+
+```go
+// Bad — implicit behavior hidden in struct tags and reflection
+type Config struct {
+    Port int `default:"8080"`
+}
+
+// Good — explicit defaults visible in code
+func NewConfig() Config {
+    return Config{Port: 8080}
+}
+```
+
+```go
+// Bad — implicit dependency via global
+func HandleRequest(w http.ResponseWriter, r *http.Request) {
+    user := globalDB.FindUser(r.Context(), userID) // where does globalDB come from?
+}
+
+// Good — explicit dependency via injection
+func (h *Handler) HandleRequest(w http.ResponseWriter, r *http.Request) {
+    user := h.db.FindUser(r.Context(), userID) // clear: db is a field on Handler
+}
+```
+
+→ See `samber/cc-skills-golang@golang-project-layout` skill for directory structure and layout patterns.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/clean-architecture.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/clean-architecture.md
new file mode 100644
index 00000000..54ff4adc
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/clean-architecture.md
@@ -0,0 +1,177 @@
+# Clean Architecture in Go
+
+## When to Use
+
+Apply clean architecture when you need strong separation between business logic and infrastructure — typically medium-to-large services (2K+ lines) where testability, framework independence, and clear dependency direction matter. Do NOT use for small CLI tools or scripts.
+
+## The Dependency Rule
+
+Dependencies point inward only. Inner layers never import outer layers.
+
+```
+Frameworks & Drivers  →  Interface Adapters  →  Use Cases  →  Entities
+(HTTP, DB, gRPC)         (handlers, repos)      (app logic)   (domain)
+```
+
+Each layer defines interfaces for what it needs. Outer layers implement those interfaces.
+
+## Project Structure
+
+```
+order-service/
+├── cmd/
+│   └── server/
+│       └── main.go                  # Wiring only — builds the dependency graph
+├── internal/
+│   ├── entity/
+│   │   ├── order.go                 # Order entity + business rules
+│   │   ├── item.go                  # OrderItem
+│   │   └── status.go                # OrderStatus enum
+│   ├── order/
+│   │   ├── place.go                 # PlaceOrderUseCase
+│   │   ├── cancel.go                # CancelOrderUseCase
+│   │   └── port.go                  # Interfaces this use case depends on
+│   ├── adapter/
+│   │   ├── handler/
+│   │   │   └── order_handler.go    # HTTP handler — calls use cases
+│   │   ├── repository/
+│   │   │   └── order_postgres.go   # OrderRepository — implements port
+│   │   └── gateway/
+│   │       └── payment_client.go   # External payment API client
+│   └── infrastructure/
+│       ├── router.go               # HTTP router setup
+│       ├── database.go             # DB connection
+│       └── config.go               # Config loading
+├── go.mod
+└── go.sum
+```
+
+## Code Examples
+
+### Entity — pure domain logic, zero dependencies
+
+```go
+// internal/entity/order.go
+package entity
+
+type Order struct {
+    ID     string
+    Items  []Item
+    Status OrderStatus
+}
+
+func (o *Order) Cancel() error {
+    if o.Status == StatusShipped {
+        return ErrCannotCancelShipped
+    }
+    o.Status = StatusCancelled
+    return nil
+}
+
+func (o *Order) Total() int64 {
+    var sum int64
+    for _, item := range o.Items {
+        sum += item.Price * int64(item.Quantity)
+    }
+    return sum
+}
+```
+
+### Use Case — orchestrates business operations
+
+```go
+// internal/order/port.go
+package order
+
+// Ports — interfaces defined by the use case, implemented by adapters
+type OrderRepository interface {
+    Save(ctx context.Context, order *entity.Order) error
+    FindByID(ctx context.Context, id string) (*entity.Order, error)
+}
+
+type PaymentGateway interface {
+    Charge(ctx context.Context, orderID string, amount int64) error
+}
+```
+
+```go
+// internal/order/place.go
+package order
+
+type PlaceOrderUseCase struct {
+    orders   OrderRepository
+    payments PaymentGateway
+}
+
+func NewPlaceOrderUseCase(orders OrderRepository, payments PaymentGateway) *PlaceOrderUseCase {
+    return &PlaceOrderUseCase{orders: orders, payments: payments}
+}
+
+func (uc *PlaceOrderUseCase) Execute(ctx context.Context, orderID string) error {
+    order, err := uc.orders.FindByID(ctx, orderID)
+    if err != nil {
+        return fmt.Errorf("finding order: %w", err)
+    }
+
+    if err := uc.payments.Charge(ctx, order.ID, order.Total()); err != nil {
+        return fmt.Errorf("charging payment: %w", err)
+    }
+
+    order.Status = entity.StatusPlaced
+    return uc.orders.Save(ctx, order)
+}
+```
+
+### Adapter — implements a port
+
+```go
+// internal/adapter/repository/order_postgres.go
+package repository
+
+type OrderPostgres struct {
+    db *sql.DB
+}
+
+func NewOrderPostgres(db *sql.DB) *OrderPostgres {
+    return &OrderPostgres{db: db}
+}
+
+func (r *OrderPostgres) FindByID(ctx context.Context, id string) (*entity.Order, error) {
+    // SQL query, scan into entity.Order
+}
+
+func (r *OrderPostgres) Save(ctx context.Context, order *entity.Order) error {
+    // SQL upsert
+}
+```
+
+### Handler — translates HTTP to use case calls
+
+```go
+// internal/adapter/handler/order_handler.go
+package handler
+
+type OrderHandler struct {
+    placeOrder *usecase.PlaceOrderUseCase
+}
+
+func (h *OrderHandler) HandlePlaceOrder(w http.ResponseWriter, r *http.Request) {
+    orderID := chi.URLParam(r, "id")
+
+    if err := h.placeOrder.Execute(r.Context(), orderID); err != nil {
+        // Map domain errors to HTTP status codes
+        http.Error(w, err.Error(), mapToHTTPStatus(err))
+        return
+    }
+
+    w.WriteHeader(http.StatusOK)
+}
+```
+
+## Key Principle
+
+Interfaces live where they are consumed, not where they are implemented. The `usecase/order/port.go` file defines `OrderRepository` — the adapter in `adapter/repository/` implements it. This keeps the use case layer free from infrastructure imports.
+
+## Wiring
+
+All dependency construction happens in `cmd/server/main.go`. → See `samber/cc-skills-golang@golang-dependency-injection` skill for DI library alternatives.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/data-handling.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/data-handling.md
new file mode 100644
index 00000000..e82234bb
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/data-handling.md
@@ -0,0 +1,63 @@
+# Data Handling Patterns
+
+## Iterators for Large Data (Go 1.23+)
+
+Process large datasets without allocating everything into memory:
+
+```go
+// Bad — loads all rows into memory
+func AllUsers(db *sql.DB) ([]User, error) {
+    rows, err := db.Query("SELECT * FROM users")
+    // ... scan all into slice
+}
+
+// Good — iterator yields one at a time
+func AllUsers(db *sql.DB) iter.Seq2[User, error] {
+    return func(yield func(User, error) bool) {
+        rows, err := db.Query("SELECT * FROM users")
+        if err != nil {
+            yield(User{}, err)
+            return
+        }
+        defer rows.Close()
+
+        for rows.Next() {
+            var u User
+            if err := rows.Scan(&u.ID, &u.Name, &u.Email); err != nil {
+                yield(User{}, err)
+                return
+            }
+            if !yield(u, nil) {
+                return
+            }
+        }
+    }
+}
+```
+
+## Streaming Large Transfers
+
+When transferring large data between services (e.g., 1M rows from DB, 1M rows in HTTP response), use streaming patterns with iterators or `github.com/samber/ro` to prevent OOM:
+
+```go
+// Stream JSON array to HTTP response — constant memory
+func (h *Handler) ExportUsers(w http.ResponseWriter, r *http.Request) {
+    w.Header().Set("Content-Type", "application/json")
+    w.Write([]byte("["))
+
+    first := true
+    for user, err := range h.repo.AllUsers(r.Context()) {
+        if err != nil {
+            slog.Error("streaming user", "error", err)
+            return
+        }
+        if !first {
+            w.Write([]byte(","))
+        }
+        json.NewEncoder(w).Encode(user)
+        first = false
+    }
+
+    w.Write([]byte("]"))
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/ddd.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/ddd.md
new file mode 100644
index 00000000..e9343610
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/ddd.md
@@ -0,0 +1,208 @@
+# Domain-Driven Design (DDD) in Go
+
+## When to Use
+
+Apply DDD when the business domain is complex enough that the code structure should mirror the business model — typically services with 5K+ lines, multiple bounded contexts, or rich business rules. Do NOT use for simple CRUD apps or CLI tools.
+
+## Building Blocks
+
+| Concept | Go Mapping | Purpose |
+| --- | --- | --- |
+| **Entity** | Struct with identity field | Has unique ID, mutable state, lifecycle |
+| **Value Object** | Immutable struct, compared by value | No identity — represents a measurement, quantity, or descriptor |
+| **Aggregate** | Entity + child entities/value objects | Consistency boundary — all mutations go through the root |
+| **Repository** | Interface in domain, impl in infrastructure | Persistence abstraction for aggregates |
+| **Domain Service** | Function or struct in domain package | Logic that spans multiple aggregates |
+| **Domain Event** | Struct describing a fact that happened | Decouples bounded contexts |
+
+## Project Structure
+
+Organize by **bounded context**, grouping domain, application, and adapters vertically. This scales across multiple contexts and clarifies ownership.
+
+```
+order-service/
+├── cmd/
+│   └── server/
+│       └── main.go                  # Wiring only
+├── internal/
+│   ├── order/                       # Bounded context: Order
+│   │   ├── domain/
+│   │   │   ├── order.go             # Order aggregate root
+│   │   │   ├── item.go              # OrderItem entity
+│   │   │   ├── status.go            # OrderStatus enum
+│   │   │   ├── repository.go        # OrderRepository interface
+│   │   │   └── events.go            # OrderPlaced, OrderShipped events
+│   │   ├── application/
+│   │   │   ├── place_order.go       # PlaceOrderHandler (command)
+│   │   │   └── get_order.go         # GetOrderHandler (query)
+│   │   └── adapters/
+│   │       ├── persistence/
+│   │       │   └── postgres.go      # OrderRepository implementation
+│   │       └── http/
+│   │           └── handler.go       # HTTP transport
+│   ├── billing/                     # Bounded context: Billing (another example)
+│   │   ├── domain/
+│   │   ├── application/
+│   │   └── adapters/
+│   ├── shared/
+│   │   └── money.go                 # Value object reused across contexts
+│   └── events/
+│       └── publisher.go             # Shared event bus (infrastructure)
+├── go.mod
+└── go.sum
+```
+
+**Key principles:**
+
+- Group each bounded context **vertically** (domain → application → adapters), not by technical role
+- Use `adapters/` instead of `infrastructure/` to be explicit about Hexagonal Architecture
+- Make cross-context boundaries explicit (see **Bounded Contexts** section below)
+- Place shared infrastructure (event bus, logging) at `internal/{shared}/` or `internal/events/`
+
+## Code Examples
+
+### Value Object — Money
+
+```go
+// internal/domain/shared/money.go
+package shared
+
+type Money struct {
+    amount   int64  // cents — avoids float precision issues
+    currency string
+}
+
+func NewMoney(amount int64, currency string) (Money, error) {
+    if currency == "" {
+        return Money{}, errors.New("currency is required")
+    }
+    return Money{amount: amount, currency: currency}, nil
+}
+
+func (m Money) Add(other Money) (Money, error) {
+    if m.currency != other.currency {
+        return Money{}, fmt.Errorf("cannot add %s to %s", other.currency, m.currency)
+    }
+    return Money{amount: m.amount + other.amount, currency: m.currency}, nil
+}
+```
+
+### Aggregate Root — Order
+
+```go
+// internal/domain/order/order.go
+package order
+
+type Order struct {
+    id     string
+    items  []Item
+    status Status
+    total  shared.Money
+}
+
+func NewOrder(id string) *Order {
+    return &Order{id: id, status: StatusDraft}
+}
+
+// All mutations go through the aggregate root
+func (o *Order) AddItem(item Item) error {
+    if o.status != StatusDraft {
+        return ErrOrderNotEditable
+    }
+    o.items = append(o.items, item)
+    return o.recalculateTotal()
+}
+
+func (o *Order) Place() (OrderPlaced, error) {
+    if len(o.items) == 0 {
+        return OrderPlaced{}, ErrEmptyOrder
+    }
+    o.status = StatusPlaced
+    return OrderPlaced{OrderID: o.id, Total: o.total}, nil
+}
+```
+
+### Repository Interface — defined in domain
+
+```go
+// internal/order/domain/repository.go
+package domain
+
+type Repository interface {
+    Save(ctx context.Context, order *Order) error
+    FindByID(ctx context.Context, id string) (*Order, error)
+}
+```
+
+The implementation lives in `internal/order/adapters/persistence/postgres.go` and depends on the domain — never the reverse.
+
+### Application Service — orchestrates a use case
+
+```go
+// internal/order/application/place_order.go
+package application
+
+import (
+    "context"
+    "fmt"
+
+    "myapp/internal/order/domain"
+)
+
+type PlaceOrderHandler struct {
+    orders domain.Repository
+    events EventPublisher
+}
+
+func (h *PlaceOrderHandler) Handle(ctx context.Context, cmd PlaceOrderCommand) error {
+    order, err := h.orders.FindByID(ctx, cmd.OrderID)
+    if err != nil {
+        return fmt.Errorf("finding order: %w", err)
+    }
+
+    evt, err := order.Place()
+    if err != nil {
+        return fmt.Errorf("placing order: %w", err)
+    }
+
+    if err := h.orders.Save(ctx, order); err != nil {
+        return fmt.Errorf("saving order: %w", err)
+    }
+
+    return h.events.Publish(ctx, evt)
+}
+```
+
+## Bounded Contexts
+
+Each bounded context maps to a top-level package under `internal/` with its own domain, application, and adapters. Contexts communicate through domain events or explicit anti-corruption layers — never by importing each other's internal types directly.
+
+**Anti-corruption layer example:** If `billing/` needs to consume an `order.OrderPlaced` event, translate it to a billing-specific type:
+
+```go
+// internal/billing/adapters/events/order_events.go
+package events
+
+import (
+    "myapp/internal/events"
+    "myapp/internal/billing/domain"
+)
+
+type OrderPlacedSubscriber struct {
+    invoices domain.InvoiceRepository
+}
+
+// Receives order.OrderPlaced, translates to billing domain
+func (s *OrderPlacedSubscriber) OnOrderPlaced(evt events.OrderPlaced) error {
+    // Translate and create invoice
+    return s.invoices.Create(evt.OrderID, evt.Total)
+}
+```
+
+This prevents billing from depending on order's internal types.
+
+For large systems, each context can be its own Go module in a workspace (`go.work`). See the `samber/cc-skills-golang@golang-project-layout` skill for workspace setup.
+
+## Wiring
+
+Wire dependencies in `cmd/server/main.go` using manual constructor injection. → See `samber/cc-skills-golang@golang-dependency-injection` skill for DI library alternatives.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/hexagonal-architecture.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/hexagonal-architecture.md
new file mode 100644
index 00000000..3884b440
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/hexagonal-architecture.md
@@ -0,0 +1,194 @@
+# Hexagonal Architecture (Ports & Adapters) in Go
+
+## When to Use
+
+Apply hexagonal architecture when a service interacts with multiple external systems (databases, APIs, message queues, caches) and you want the domain logic fully decoupled from all of them. Particularly effective when the same business logic needs multiple entry points (HTTP, gRPC, CLI, message consumer). Do NOT use for simple CRUD apps or libraries.
+
+## Core Concepts
+
+- **Domain** — Business logic and types. No external dependencies.
+- **Ports** — Interfaces that define how the domain interacts with the outside world.
+  - **Primary (driving) ports**: How the outside world calls into the domain (e.g., `OrderService` interface).
+  - **Secondary (driven) ports**: How the domain calls out to infrastructure (e.g., `OrderRepository`, `PaymentGateway` interfaces).
+- **Adapters** — Concrete implementations of ports.
+  - **Primary adapters**: HTTP handlers, gRPC servers, CLI commands — they call primary ports.
+  - **Secondary adapters**: PostgreSQL repository, Stripe client, Redis cache — they implement secondary ports.
+
+## Project Structure
+
+```
+order-service/
+├── cmd/
+│   ├── server/
+│   │   └── main.go                  # HTTP server wiring
+│   └── worker/
+│       └── main.go                  # Message consumer wiring
+├── internal/
+│   ├── domain/
+│   │   ├── order.go                 # Order entity + business rules
+│   │   ├── item.go                  # OrderItem
+│   │   └── status.go               # OrderStatus enum
+│   ├── port/
+│   │   ├── incoming.go             # Primary ports (OrderService interface)
+│   │   └── outgoing.go             # Secondary ports (OrderRepository, PaymentGateway)
+│   ├── service/
+│   │   └── order_service.go        # Implements primary ports — orchestrates domain + secondary ports
+│   └── adapter/
+│       ├── primary/
+│       │   ├── http/
+│       │   │   ├── router.go
+│       │   │   └── order_handler.go # HTTP adapter — calls OrderService
+│       │   └── grpc/
+│       │       └── order_server.go  # gRPC adapter — calls OrderService
+│       └── secondary/
+│           ├── postgres/
+│           │   └── order_repo.go    # Implements OrderRepository
+│           └── stripe/
+│               └── payment.go      # Implements PaymentGateway
+├── go.mod
+└── go.sum
+```
+
+## Code Examples
+
+### Domain — pure business logic
+
+```go
+// internal/domain/order.go
+package domain
+
+type Order struct {
+    ID     string
+    Items  []Item
+    Status OrderStatus
+}
+
+func (o *Order) Ship() error {
+    if o.Status != StatusPaid {
+        return ErrOrderNotPaid
+    }
+    o.Status = StatusShipped
+    return nil
+}
+```
+
+### Ports — interfaces defined separately from implementations
+
+```go
+// internal/port/incoming.go
+package port
+
+// Primary port — how the outside world drives the application
+type OrderService interface {
+    PlaceOrder(ctx context.Context, items []domain.Item) (string, error)
+    ShipOrder(ctx context.Context, orderID string) error
+    GetOrder(ctx context.Context, orderID string) (*domain.Order, error)
+}
+```
+
+```go
+// internal/port/outgoing.go
+package port
+
+// Secondary ports — how the application reaches external systems
+type OrderRepository interface {
+    Save(ctx context.Context, order *domain.Order) error
+    FindByID(ctx context.Context, id string) (*domain.Order, error)
+}
+
+type PaymentGateway interface {
+    Charge(ctx context.Context, orderID string, amount int64) error
+}
+```
+
+### Service — implements primary port, depends on secondary ports
+
+```go
+// internal/service/order_service.go
+package service
+
+type orderService struct {
+    orders   port.OrderRepository
+    payments port.PaymentGateway
+}
+
+func NewOrderService(orders port.OrderRepository, payments port.PaymentGateway) port.OrderService {
+    return &orderService{orders: orders, payments: payments}
+}
+
+func (s *orderService) PlaceOrder(ctx context.Context, items []domain.Item) (string, error) {
+    order := domain.NewOrder(items)
+
+    if err := s.payments.Charge(ctx, order.ID, order.Total()); err != nil {
+        return "", fmt.Errorf("charging payment: %w", err)
+    }
+
+    if err := s.orders.Save(ctx, order); err != nil {
+        return "", fmt.Errorf("saving order: %w", err)
+    }
+
+    return order.ID, nil
+}
+```
+
+### Primary Adapter — HTTP handler calls the service port
+
+```go
+// internal/adapter/primary/http/order_handler.go
+package http
+
+type OrderHandler struct {
+    svc port.OrderService
+}
+
+func NewOrderHandler(svc port.OrderService) *OrderHandler {
+    return &OrderHandler{svc: svc}
+}
+
+func (h *OrderHandler) HandlePlaceOrder(w http.ResponseWriter, r *http.Request) {
+    var req PlaceOrderRequest
+    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
+        http.Error(w, "invalid request", http.StatusBadRequest)
+        return
+    }
+
+    id, err := h.svc.PlaceOrder(r.Context(), req.Items)
+    if err != nil {
+        http.Error(w, err.Error(), mapToHTTPStatus(err))
+        return
+    }
+
+    json.NewEncoder(w).Encode(map[string]string{"id": id})
+}
+```
+
+### Secondary Adapter — implements a driven port
+
+```go
+// internal/adapter/secondary/postgres/order_repo.go
+package postgres
+
+type OrderRepo struct {
+    db *sql.DB
+}
+
+func NewOrderRepo(db *sql.DB) *OrderRepo {
+    return &OrderRepo{db: db}
+}
+
+func (r *OrderRepo) Save(ctx context.Context, order *domain.Order) error {
+    // SQL upsert
+}
+
+func (r *OrderRepo) FindByID(ctx context.Context, id string) (*domain.Order, error) {
+    // SQL query
+}
+```
+
+## Multiple Entry Points
+
+The hexagonal approach shines when the same `OrderService` is called from different primary adapters — HTTP for external clients, gRPC for internal services, a message consumer for async events. Each adapter is wired in its own `cmd/` entry point.
+
+## Wiring
+
+Construct adapters and inject them in `cmd/server/main.go`. → See `samber/cc-skills-golang@golang-dependency-injection` skill for DI library alternatives.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/resource-management.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/resource-management.md
new file mode 100644
index 00000000..403db458
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-design-patterns/references/resource-management.md
@@ -0,0 +1,154 @@
+# Resource Management Patterns
+
+## Defer Close Immediately
+
+`defer Close()` MUST be called immediately after opening — NEVER delay. This prevents leaks when code is modified later and new return paths are added:
+
+```go
+// Good — defer is right next to open
+f, err := os.Open(path)
+if err != nil {
+    return err
+}
+defer f.Close()
+
+// Bad — Close() is far from Open(), easy to forget when adding early returns
+f, err := os.Open(path)
+if err != nil {
+    return err
+}
+// ... 50 lines of code ...
+f.Close() // might never run if a new return is added above
+```
+
+This applies to all closeable resources: files, SQL rows, HTTP response bodies, gzip readers, bufio scanners wrapping readers, etc.
+
+```go
+resp, err := http.Get(url)
+if err != nil {
+    return err
+}
+defer resp.Body.Close()
+
+rows, err := db.QueryContext(ctx, query)
+if err != nil {
+    return err
+}
+defer rows.Close()
+```
+
+## `runtime.AddCleanup` over `runtime.SetFinalizer`
+
+`runtime.AddCleanup` SHOULD be preferred over `runtime.SetFinalizer` (Go 1.24+):
+
+```go
+type Resource struct {
+    handle uintptr
+}
+
+func NewResource() *Resource {
+    r := &Resource{handle: acquireHandle()}
+    runtime.AddCleanup(r, func(handle uintptr) {
+        releaseHandle(handle)
+    }, r.handle)
+    return r
+}
+```
+
+`AddCleanup` is preferred because:
+
+- Multiple cleanups can be attached to the same object
+- The cleanup function receives a copy of the value, not the object itself — no resurrection risk
+- Cleanups run even if the object is part of a cycle
+
+## Resource Pools
+
+Resource pools SHOULD use channels with a fixed capacity for bounded allocation. Use channel-based pools or `sync.Pool` to manage limited resources between consumers. Always set a maximum size:
+
+```go
+type ConnPool struct {
+    conns chan *Conn
+}
+
+func NewConnPool(maxSize int, factory func() (*Conn, error)) (*ConnPool, error) {
+    pool := &ConnPool{
+        conns: make(chan *Conn, maxSize),
+    }
+    // Pre-fill with initial connections
+    for range maxSize {
+        conn, err := factory()
+        if err != nil {
+            return nil, fmt.Errorf("creating connection: %w", err)
+        }
+        pool.conns <- conn
+    }
+    return pool, nil
+}
+
+func (p *ConnPool) Get(ctx context.Context) (*Conn, error) {
+    select {
+    case conn := <-p.conns:
+        return conn, nil
+    case <-ctx.Done():
+        return nil, ctx.Err()
+    }
+}
+
+func (p *ConnPool) Put(conn *Conn) {
+    select {
+    case p.conns <- conn:
+    default:
+        conn.Close() // pool is full, discard
+    }
+}
+```
+
+## Graceful Shutdown
+
+Graceful shutdown MUST use `signal.NotifyContext` for clean termination. All resources (connections, files, channels) MUST be drained before process exit. Use `os/signal` and context cancellation:
+
+```go
+func main() {
+    ctx, stop := signal.NotifyContext(context.Background(),
+        syscall.SIGINT, syscall.SIGTERM,
+    )
+    defer stop()
+
+    srv := &http.Server{Addr: ":8080", Handler: router}
+
+    // Start server in background
+    go func() {
+        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
+            slog.Error("server error", "error", err)
+        }
+    }()
+
+    slog.Info("server started", "addr", ":8080")
+
+    // Wait for interrupt signal
+    <-ctx.Done()
+    slog.Info("shutting down...")
+
+    // Give outstanding requests time to complete
+    shutdownCtx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
+    defer cancel()
+
+    if err := srv.Shutdown(shutdownCtx); err != nil {
+        slog.Error("shutdown error", "error", err)
+    }
+
+    // Close other resources: database connections, message queues, etc.
+    db.Close()
+    slog.Info("shutdown complete")
+}
+```
+
+This pattern applies to any long-running service — gRPC servers, message consumers, background workers. The key elements are:
+
+1. Capture OS signals with `signal.NotifyContext`
+2. Start the server in a goroutine
+3. Block on context cancellation
+4. Shut down with a timeout to drain in-flight requests
+5. Close all remaining resources in order
+
+For goroutine shutdown patterns, see the `samber/cc-skills-golang@golang-concurrency` skill.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/SKILL.md
new file mode 100644
index 00000000..e7c43e92
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/SKILL.md
@@ -0,0 +1,236 @@
+---
+name: golang-documentation
+description: "Comprehensive documentation guide for Golang projects, covering godoc comments, README, CONTRIBUTING, CHANGELOG, Go Playground, Example tests, API docs, and llms.txt. Use when writing or reviewing doc comments, documentation, adding code examples, setting up doc sites, or discussing documentation best practices. Triggers for both libraries and applications/CLIs."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.4"
+  openclaw:
+    emoji: "📝"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch
+---
+
+**Persona:** You are a Go technical writer and API designer. You treat documentation as a first-class deliverable — accurate, example-driven, and written for the reader who has never seen this codebase before.
+
+**Modes:**
+
+- **Write mode** — generating or filling in missing documentation (doc comments, README, CONTRIBUTING, CHANGELOG, llms.txt). Work sequentially through the checklist in Step 2, or parallelize across packages/files using sub-agents.
+- **Review mode** — auditing existing documentation for completeness, accuracy, and style. Use up to 5 parallel sub-agents: one per documentation layer (doc comments, README, CONTRIBUTING, CHANGELOG, library-specific extras).
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-documentation` skill takes precedence.
+
+# Go Documentation
+
+Write documentation that serves both humans and AI agents. Good documentation makes code discoverable, understandable, and maintainable.
+
+## Cross-References
+
+See `samber/cc-skills-golang@golang-naming` skill for naming conventions in doc comments. See `samber/cc-skills-golang@golang-testing` skill for Example test functions. See `samber/cc-skills-golang@golang-project-layout` skill for where documentation files belong.
+
+## Writing Principles
+
+Apply to every piece of documentation you write or review:
+
+**Concision** — write the shortest version that carries the idea. Remove ornament and hollow transitions. Never drop facts, warnings, or user-requested depth.
+
+**Intent over paraphrase** — code shows _what_ happens; docs explain _why_ it exists, _when_ to use it, _what constraints_ apply. A comment that only restates the signature wastes the reader's time.
+
+**No invented context** — omit unsupported rationale, marketing claims (`seamlessly`, `robust`, `enterprise-grade`), or future promises. Leave gaps visible rather than filling with speculation.
+
+**Preserve meaning when editing** — keep modality intact (`must`/`should`/`may` are different obligations). Preserve conditions, warnings, required actions. A cleaner sentence that changes obligations is wrong.
+
+**Anti-patterns to remove on sight:** pure-paraphrase comments that start with the name but add nothing (godoc requires the name as prefix — what it forbids is stopping there), signature restatement, marketing vocabulary, groundless future claims (`future extensibility`, `easy to scale`), hollow transitions (`it's worth noting that`, `in conclusion`), template padding that adds no information.
+
+## Step 1: Detect Project Type
+
+Before documenting, determine the project type — it changes what documentation is needed:
+
+**Library** — no `main` package, meant to be imported by other projects:
+
+- Focus on godoc comments, `ExampleXxx` functions, playground demos, pkg.go.dev rendering
+- See [Library Documentation](./references/library.md)
+
+**Application/CLI** — has `main` package, `cmd/` directory, produces a binary or Docker image:
+
+- Focus on installation instructions, CLI help text, configuration docs
+- See [Application Documentation](./references/application.md)
+
+**Both apply**: function comments, README, CONTRIBUTING, CHANGELOG.
+
+**Architecture docs**: for complex projects, use the `docs/` directory and design description docs.
+
+## Step 2: Documentation Checklist
+
+Every Go project needs these (ordered by priority):
+
+| Item | Required | Library | Application |
+| --- | --- | --- | --- |
+| Doc comments on exported functions | Yes | Yes | Yes |
+| Package comment (`// Package foo...`) — MUST exist | Yes | Yes | Yes |
+| README.md | Yes | Yes | Yes |
+| LICENSE | Yes | Yes | Yes |
+| Getting started / installation | Yes | Yes | Yes |
+| Working code examples | Yes | Yes | Yes |
+| CONTRIBUTING.md | Recommended | Yes | Yes |
+| CHANGELOG.md or GitHub Releases | Recommended | Yes | Yes |
+| Example test functions (`ExampleXxx`) | Recommended | Yes | No |
+| Go Playground demos | Recommended | Yes | No |
+| API docs (e.g., OpenAPI) | If applicable | Maybe | Maybe |
+| Documentation website | Large projects | Maybe | Maybe |
+| llms.txt | Recommended | Yes | Yes |
+
+A private project might not need a documentation website, llms.txt, Go Playground demos...
+
+## Parallelizing Documentation Work
+
+When documenting a large codebase with many packages, use up to 5 parallel sub-agents (via the Agent tool) for independent tasks:
+
+- Assign each sub-agent to verify and fix doc comments in a different set of packages
+- Generate `ExampleXxx` test functions for multiple packages simultaneously
+- Generate project docs in parallel: one sub-agent per file (README, CONTRIBUTING, CHANGELOG, llms.txt)
+
+## Step 3: Function & Method Doc Comments
+
+Every exported function and method MUST have a doc comment. Document complex internal functions too. Skip test functions.
+
+The comment starts with the function name and a verb phrase. Focus on **why** and **when**, not restating what the code already shows. The code tells you _what_ happens — the comment should explain _why_ it exists, _when_ to use it, _what constraints_ apply, and _what can go wrong_. Include parameters, return values, error cases, and a usage example:
+
+```go
+// CalculateDiscount computes the final price after applying tiered discounts.
+// Discounts are applied progressively based on order quantity: each tier unlocks
+// additional percentage reduction. Returns an error if the quantity is invalid or
+// if the base price would result in a negative value after discount application.
+//
+// Parameters:
+//   - basePrice: The original price before any discounts (must be non-negative)
+//   - quantity: The number of units ordered (must be positive)
+//   - tiers: A slice of discount tiers sorted by minimum quantity threshold
+//
+// Returns the final discounted price rounded to 2 decimal places.
+// Returns ErrInvalidPrice if basePrice is negative.
+// Returns ErrInvalidQuantity if quantity is zero or negative.
+//
+// Play: https://go.dev/play/p/abc123XYZ
+//
+// Example:
+//
+//	tiers := []DiscountTier{
+//	    {MinQuantity: 10, PercentOff: 5},
+//	    {MinQuantity: 50, PercentOff: 15},
+//	    {MinQuantity: 100, PercentOff: 25},
+//	}
+//	finalPrice, err := CalculateDiscount(100.00, 75, tiers)
+//	if err != nil {
+//	    log.Fatalf("Discount calculation failed: %v", err)
+//	}
+//	log.Printf("Ordered 75 units at $100 each: final price = $%.2f", finalPrice)
+func CalculateDiscount(basePrice float64, quantity int, tiers []DiscountTier) (float64, error) {
+    // implementation
+}
+```
+
+For the full comment format, deprecated markers, interface docs, and file-level comments, see **[Code Comments](./references/code-comments.md)** — how to document packages, functions, interfaces, and when to use `Deprecated:` markers and `BUG:` notes.
+
+## Step 4: README Structure
+
+README SHOULD follow this exact section order. Copy the template from [templates/README.md](./assets/templates/README.md):
+
+1. **Title** — project name as `# heading`
+2. **Badges** — shields.io pictograms (Go version, license, CI, coverage, Go Report Card...)
+3. **Summary** — 1-2 sentences explaining what the project does
+4. **Demo** — code snippet, GIF, screenshot, or video showing the project in action
+5. **Getting Started** — installation + minimal working example
+6. **Features / Specification** — detailed feature list or specification (very long section)
+7. **Contributing** — link to CONTRIBUTING.md or inline if very short
+8. **Contributors** — thank contributors (badge or list)
+9. **License** — license name + link
+
+Common badges for Go projects:
+
+```markdown
+[![Go Version](https://img.shields.io/github/go-mod/go-version/{owner}/{repo})](https://go.dev/) [![License](https://img.shields.io/github/license/{owner}/{repo})](./LICENSE) [![Build Status](https://img.shields.io/github/actions/workflow/status/{owner}/{repo}/test.yml?branch=main)](https://github.com/{owner}/{repo}/actions) [![Coverage](https://img.shields.io/codecov/c/github/{owner}/{repo})](https://codecov.io/gh/{owner}/{repo}) [![Go Report Card](https://goreportcard.com/badge/github.com/{owner}/{repo})](https://goreportcard.com/report/github.com/{owner}/{repo}) [![Go Reference](https://pkg.go.dev/badge/github.com/{owner}/{repo}.svg)](https://pkg.go.dev/github.com/{owner}/{repo})
+```
+
+For the full README guidance and application-specific sections, see [Project Docs](./references/project-docs.md#readme).
+
+## Step 5: CONTRIBUTING & Changelog
+
+**CONTRIBUTING.md** — Help contributors get started in under 10 minutes. Include: prerequisites, clone, build, test, PR process. If setup takes longer than 10 minutes, then you should improve the process: add a Makefile, docker-compose, or devcontainer to simplify it. See [Project Docs](./references/project-docs.md#contributingmd).
+
+**Changelog** — Track changes using [Keep a Changelog](https://keepachangelog.com/) format or GitHub Releases. Copy the template from [templates/CHANGELOG.md](./assets/templates/CHANGELOG.md). Each entry answers _what changed for the reader_ — internal refactors without user-visible impact belong in commit history. Don't inflate a fixed edge case into a broad "reliability improvement" claim. See [Project Docs](./references/project-docs.md#changelog).
+
+## Step 6: Library-Specific Documentation
+
+For Go libraries, add these on top of the basics:
+
+- **Go Playground demos** — create runnable demos and link them in doc comments with `// Play: https://go.dev/play/p/xxx`. Use the go-playground MCP tool when available to create and share playground URLs.
+- **Example test functions** — write `func ExampleXxx()` in `_test.go` files. These are executable documentation verified by `go test`.
+- **Generous code examples** — include multiple examples in doc comments showing common use cases.
+- **godoc** — your doc comments render on [pkg.go.dev](https://pkg.go.dev). Use `go doc` locally to preview.
+- **Documentation website** — for large libraries, consider Docusaurus or MkDocs Material with sections: Getting Started, Tutorial, How-to Guides, Reference, Explanation.
+- **Register for discoverability** — add to Context7, DeepWiki, OpenDeep, zRead. Even for private libraries.
+
+See [Library Documentation](./references/library.md) for details.
+
+## Step 7: Application-Specific Documentation
+
+For Go applications/CLIs:
+
+- **Installation methods** — pre-built binaries (GoReleaser), `go install`, Docker images, Homebrew...
+- **CLI help text** — make `--help` comprehensive; it's the primary documentation
+- **Configuration docs** — document all env vars, config files, CLI flags
+
+See [Application Documentation](./references/application.md) for details.
+
+## Step 8: API Documentation
+
+If your project exposes an API:
+
+| API Style    | Format      | Tool                                         |
+| ------------ | ----------- | -------------------------------------------- |
+| REST/HTTP    | OpenAPI 3.x | swaggo/swag (auto-generate from annotations) |
+| Event-driven | AsyncAPI    | Manual or code-gen                           |
+| gRPC         | Protobuf    | buf, grpc-gateway                            |
+
+Prefer auto-generation from code annotations when possible. See [Application Documentation](./references/application.md#api-documentation) for details.
+
+## Step 9: AI-Friendly Documentation
+
+Make your project consumable by AI agents:
+
+- **llms.txt** — add a `llms.txt` file at the repository root. Copy the template from [templates/llms.txt](./assets/templates/llms.txt). This file gives LLMs a structured overview of your project.
+- **Structured formats** — use OpenAPI, AsyncAPI, or protobuf for machine-readable API docs.
+- **Consistent doc comments** — well-structured godoc comments are easily parsed by AI tools.
+- **Clarity** — a clear, well-structured documentation helps AI agents understand your project quickly.
+
+## Step 10: Delivery Documentation
+
+Document how users get your project:
+
+**Libraries:**
+
+```bash
+go get github.com/{owner}/{repo}
+```
+
+**Applications:**
+
+```bash
+# Pre-built binary
+curl -sSL https://github.com/{owner}/{repo}/releases/latest/download/{repo}-$(uname -s)-$(uname -m) -o /usr/local/bin/{repo}
+
+# From source
+go install github.com/{owner}/{repo}@latest
+
+# Docker
+docker pull {registry}/{owner}/{repo}:latest
+```
+
+See [Project Docs](./references/project-docs.md#delivery) for Dockerfile best practices and Homebrew tap setup.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/CHANGELOG.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/CHANGELOG.md
new file mode 100644
index 00000000..2d7d2418
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/CHANGELOG.md
@@ -0,0 +1,36 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+### Added
+
+- Arabic translation (#21).
+
+### Changed
+
+- Improve French translation (#42).
+
+### Deprecated
+
+### Removed
+
+### Fixed
+
+- Fix missing logo in home page
+
+### Security
+
+### Other (dependencies, CI, tools...)
+
+## [1.0.0] - YYYY-MM-DD
+
+### Added
+
+- Initial release
+
+[Unreleased]: https://github.com/{owner}/{repo}/compare/v1.0.0...HEAD
+[1.0.0]: https://github.com/{owner}/{repo}/releases/tag/v1.0.0
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/CONTRIBUTING.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/CONTRIBUTING.md
new file mode 100644
index 00000000..2af154a1
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/CONTRIBUTING.md
@@ -0,0 +1,55 @@
+# Contributing to {project-name}
+
+Thank you for your interest in contributing!
+
+## Prerequisites
+
+- Go {version} or later
+- Make (optional but recommended)
+- Docker (for integration tests only)
+
+## Quick Start
+
+```bash
+# Clone the repository
+git clone https://github.com/{owner}/{repo}.git
+cd {repo}
+
+# Build
+go build -o myapp ./cmd/main.go
+
+# Run unit tests
+go test -race ./...
+
+# Run integration tests
+go test -race -tags=integration -timeout=300s ./...
+
+# Run linter
+golangci-lint run --fix ./...
+```
+
+## Development Workflow
+
+1. Fork the repository
+2. Create a feature branch: `git checkout -b feat/my-feature`
+3. Make your changes
+4. Add tests for new functionality
+5. Run `go test ./...` and `golangci-lint run`
+6. Commit with a descriptive message
+7. Push and open a Pull Request
+
+## Code Guidelines
+
+- Follow [Effective Go](https://go.dev/doc/effective_go)
+- Add doc comments to all exported symbols
+- Write table-driven tests
+- Keep test coverage above {X}%
+
+## Reporting Issues
+
+Use [GitHub Issues](https://github.com/{owner}/{repo}/issues). Include:
+
+- Go version (`go version`)
+- OS and architecture
+- Steps to reproduce
+- Expected vs actual behavior
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/README.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/README.md
new file mode 100644
index 00000000..996ea470
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/README.md
@@ -0,0 +1,118 @@
+# {project-name}
+
+<!-- Replace {owner} and {repo} throughout this file -->
+
+[![Go Version](https://img.shields.io/github/go-mod/go-version/{owner}/{repo})](https://go.dev/) [![License](https://img.shields.io/github/license/{owner}/{repo})](./LICENSE) [![Build Status](https://img.shields.io/github/actions/workflow/status/{owner}/{repo}/test.yml?branch=main)](https://github.com/{owner}/{repo}/actions) [![Coverage](https://img.shields.io/codecov/c/github/{owner}/{repo})](https://codecov.io/gh/{owner}/{repo}) [![Go Report Card](https://goreportcard.com/badge/github.com/{owner}/{repo})](https://goreportcard.com/report/github.com/{owner}/{repo}) [![Go Reference](https://pkg.go.dev/badge/github.com/{owner}/{repo}.svg)](https://pkg.go.dev/github.com/{owner}/{repo})
+
+<!-- Additional badges (pick what's relevant):
+[![Release](https://img.shields.io/github/v/release/{owner}/{repo})](https://github.com/{owner}/{repo}/releases)
+[![Downloads](https://img.shields.io/github/downloads/{owner}/{repo}/total)](https://github.com/{owner}/{repo}/releases)
+[![Docker Pulls](https://img.shields.io/docker/pulls/{owner}/{repo})](https://hub.docker.com/r/{owner}/{repo})
+-->
+
+<!-- 1-2 sentences: what does this project do and who is it for? -->
+
+<!-- Show the project in action: code snippet, GIF, screenshot, or video.
+     For libraries: show a minimal working code example.
+     For CLIs/tools: a GIF or screenshot is often more effective. -->
+
+```go
+// Minimal working example showing the most common use case
+```
+
+## 🚀 Getting Started
+
+<!-- For libraries: -->
+
+```bash
+go get github.com/{owner}/{repo}
+```
+
+```go
+package main
+
+import "github.com/{owner}/{repo}"
+
+func main() {
+    // Minimal working example
+}
+```
+
+<!-- For applications, uncomment and use this instead:
+
+### Pre-built binaries
+
+Download from [GitHub Releases](https://github.com/{owner}/{repo}/releases/latest).
+
+| Platform | Architecture | Download                                                                                        |
+| -------- | ------------ | ----------------------------------------------------------------------------------------------- |
+| Linux    | amd64        | [Download](https://github.com/{owner}/{repo}/releases/latest/download/{repo}-linux-amd64)       |
+| Linux    | arm64        | [Download](https://github.com/{owner}/{repo}/releases/latest/download/{repo}-linux-arm64)       |
+| macOS    | amd64        | [Download](https://github.com/{owner}/{repo}/releases/latest/download/{repo}-darwin-amd64)      |
+| macOS    | arm64        | [Download](https://github.com/{owner}/{repo}/releases/latest/download/{repo}-darwin-arm64)      |
+| Windows  | amd64        | [Download](https://github.com/{owner}/{repo}/releases/latest/download/{repo}-windows-amd64.exe) |
+
+### From source
+
+```bash
+go install github.com/{owner}/{repo}@latest
+```
+
+### Docker
+
+```bash
+docker pull {registry}/{owner}/{repo}:latest
+docker run --rm {registry}/{owner}/{repo}:latest --help
+```
+
+### Homebrew (macOS)
+
+```bash
+brew install {owner}/{repo}
+```
+
+### APT (debian/ubuntu)
+
+```bash
+apt install {package}
+```
+
+-->
+
+## ✨ Features
+
+<!-- Very detailed feature descriptions, organized by area.
+     This is the longest section of the README.
+     Use headings, tables, and code examples generously. -->
+
+### Feature Area 1
+
+<!-- Description with code examples -->
+
+### Feature Area 2
+
+<!-- Description with code examples -->
+
+## 🤝 Contributing
+
+Please read the [contributing guide](CONTRIBUTING.md) before submitting a PR.
+
+<!-- Or if the contributing guide is very short:
+
+```bash
+# Build
+go build -o myapp ./cmd/main.go
+
+# Run unit tests
+go test -race ./...
+
+# Run integration tests
+go test -race -tags=integration -timeout=300s ./...
+
+# Run linter
+golangci-lint run --fix ./...
+-->
+
+## 📄 License
+
+This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/llms.txt b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/llms.txt
new file mode 100644
index 00000000..147780ea
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/assets/templates/llms.txt
@@ -0,0 +1,67 @@
+# {project-name}
+
+> {One-line description of the project}
+
+## Overview
+
+{2-3 sentences explaining what this project does, what problem it solves, and who it's for.}
+
+## Quick Start
+
+```bash
+go get github.com/{owner}/{repo}
+```
+
+```go
+package main
+
+import "github.com/{owner}/{repo}"
+
+func main() {
+    // Minimal working example
+}
+```
+
+## Key Concepts
+
+- **{Concept 1}**: {Brief explanation}
+- **{Concept 2}**: {Brief explanation}
+- **{Concept 3}**: {Brief explanation}
+
+## API Reference
+
+### Core Functions
+
+- `FuncName(params) returns` - {What it does and when to use it}
+- `AnotherFunc(params) returns` - {What it does and when to use it}
+
+### Core Types
+
+- `TypeName` - {What it represents}
+- `AnotherType` - {What it represents}
+
+## Common Patterns
+
+### {Pattern 1 Name}
+
+```go
+// Example code showing this pattern
+```
+
+### {Pattern 2 Name}
+
+```go
+// Example code showing this pattern
+```
+
+## Error Handling
+
+- `ErrName` - {When this error occurs and how to handle it}
+- `ErrAnother` - {When this error occurs and how to handle it}
+
+## References
+
+- Documentation: {URL}
+- Repository: https://github.com/{owner}/{repo}
+- Go Reference: https://pkg.go.dev/github.com/{owner}/{repo}
+- Issues: https://github.com/{owner}/{repo}/issues
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/evals/evals.json
new file mode 100644
index 00000000..4294b531
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/evals/evals.json
@@ -0,0 +1,276 @@
+{
+  "skill_name": "golang-documentation",
+  "evals": [
+    {
+      "id": 1,
+      "name": "readme-section-order",
+      "prompt": "Write a README.md for a Go library called `github.com/acme/taskflow` that provides a DAG-based task execution engine. It supports parallel execution, dependency resolution, cycle detection, and retry policies. Include installation instructions, a usage example, license info, and any other sections you think are appropriate for a Go open-source library.",
+      "trap": "Model will produce a reasonable README but likely not follow the exact section order: Title > Badges > Summary > Demo > Getting Started > Features > Contributing > License",
+      "assertions": [
+        { "id": "1.1", "text": "Badges section appears immediately after the title heading, before any prose" },
+        { "id": "1.2", "text": "A short summary (1-2 sentences) appears after badges, before any code block or Getting Started section" },
+        { "id": "1.3", "text": "A demo/example code snippet appears before the Getting Started/Installation section" },
+        { "id": "1.4", "text": "Getting Started section with `go get` appears after the demo and before Features" },
+        { "id": "1.5", "text": "Features section is the longest section, appearing after Getting Started" }
+      ]
+    },
+    {
+      "id": 2,
+      "name": "scrambled-readme-reorder",
+      "prompt": "I wrote a README for my Go library `github.com/acme/ratelimit` but my team says the sections are in the wrong order. Can you reorganize it following Go open-source best practices? Keep the content, just fix the order:\n\n```markdown\n# ratelimit\n\n## Getting Started\n```bash\ngo get github.com/acme/ratelimit\n```\n\n## Features\n- Token bucket algorithm\n- Redis backend support\n- Per-key rate limiting\n- Middleware for net/http\n\nA high-performance, distributed rate limiter for Go applications.\n\n## License\nMIT License - see LICENSE file.\n\n[![Build Status](https://img.shields.io/github/actions/workflow/status/acme/ratelimit/test.yml)](https://github.com/acme/ratelimit/actions)\n\n## Contributing\nSee CONTRIBUTING.md\n\n```go\nlimiter := ratelimit.New(ratelimit.WithRate(100, time.Second))\nif limiter.Allow(\"user-123\") {\n    // process request\n}\n```\n```\n",
+      "trap": "The README has sections in wrong order: Getting Started > Features > Summary (unlabeled) > License > Badges (unlabeled) > Contributing > Demo (unlabeled). Without skill the model might rearrange reasonably but miss the exact prescribed order or miss that Summary/Badges/Demo need their own placement",
+      "assertions": [
+        { "id": "2.1", "text": "Badges appear immediately after the title, before the summary text" },
+        { "id": "2.2", "text": "The summary sentence ('A high-performance...') appears after badges, before the demo code" },
+        { "id": "2.3", "text": "The demo code snippet (limiter := ...) appears before the Getting Started section" },
+        { "id": "2.4", "text": "Getting Started appears after demo and before Features" },
+        { "id": "2.5", "text": "Contributing and License appear at the end, after Features" }
+      ]
+    },
+    {
+      "id": 3,
+      "name": "doc-comment-why-not-what",
+      "prompt": "Write a godoc comment for this Go function. Make it comprehensive:\n\n```go\nfunc Merge(dst, src map[string]interface{}, overwrite bool) map[string]interface{} {\n    if dst == nil {\n        dst = make(map[string]interface{})\n    }\n    for k, v := range src {\n        if _, exists := dst[k]; !exists || overwrite {\n            dst[k] = v\n        }\n    }\n    return dst\n}\n```",
+      "trap": "Model might just restate: 'Merge merges two maps'. Skill teaches why/when/constraints, Parameters section, Returns section, error cases",
+      "assertions": [
+        { "id": "3.1", "text": "Comment starts with 'Merge' followed by a verb phrase (godoc convention)" },
+        { "id": "3.2", "text": "Includes a Parameters section listing dst, src, and overwrite with descriptions" },
+        { "id": "3.3", "text": "Explains the overwrite behavior (when true vs false)" },
+        { "id": "3.4", "text": "Documents nil dst handling (creates new map)" },
+        { "id": "3.5", "text": "Includes an inline code Example section showing usage" }
+      ]
+    },
+    {
+      "id": 4,
+      "name": "small-package-no-doc-go",
+      "prompt": "I have a Go package with 2 files: `handler.go` and `middleware.go`. My teammate suggests I should create a `doc.go` file for the package-level documentation comment. Is that the right approach? Where should I put the package comment?",
+      "trap": "Model without skill might agree to create doc.go (it's a common pattern). Skill teaches: doc.go is for packages with 3+ files; for small packages, put the comment at the top of the main .go file",
+      "assertions": [
+        { "id": "4.1", "text": "Advises AGAINST creating doc.go for a 2-file package" },
+        { "id": "4.2", "text": "Recommends placing the package comment at the top of the main .go file (handler.go)" },
+        { "id": "4.3", "text": "Mentions the 3+ files threshold for when doc.go becomes appropriate" },
+        { "id": "4.4", "text": "Shows the `// Package ... ` format starting with the Package keyword" },
+        { "id": "4.5", "text": "Explains that doc.go is for larger packages where no single file is the obvious home" }
+      ]
+    },
+    {
+      "id": 5,
+      "name": "example-test-naming",
+      "prompt": "Write Example test functions for this Go library function that converts temperatures. I need examples for: basic Celsius to Fahrenheit, Fahrenheit to Celsius, and Kelvin to Celsius conversions.\n\n```go\npackage tempconv\n\n// Convert converts a temperature from one unit to another.\nfunc Convert(value float64, from, to Unit) float64 { ... }\n```",
+      "trap": "Model might name multiple examples as ExampleConvert1/ExampleConvert2 or ExampleConvertCelsiusToFahrenheit (capitalized suffix). Skill teaches lowercase suffix convention.",
+      "assertions": [
+        { "id": "5.1", "text": "Uses external test package (package tempconv_test)" },
+        { "id": "5.2", "text": "Multiple examples use lowercase suffix: ExampleConvert_celsiusToFahrenheit or similar lowercase pattern" },
+        { "id": "5.3", "text": "Every example includes an // Output: comment for go test verification" },
+        { "id": "5.4", "text": "Examples use fmt.Println to print results (not fmt.Printf)" },
+        { "id": "5.5", "text": "Examples import the package and call tempconv.Convert (external test package pattern)" }
+      ]
+    },
+    {
+      "id": 6,
+      "name": "contributing-10min-rule",
+      "prompt": "Write a CONTRIBUTING.md for a Go project that requires: PostgreSQL 15, Redis 7, Elasticsearch 8, Go 1.22+, and protoc for gRPC code generation. The test suite takes about 3 minutes to run. Building requires running `protoc` first, then `go generate`, then `go build`.",
+      "trap": "Complex setup with 5 dependencies. Model might just list prerequisites. Skill teaches the 10-minute rule and suggests Makefile, docker-compose, devcontainer",
+      "assertions": [
+        { "id": "6.1", "text": "Includes a Makefile or mentions make targets (make build, make test, make lint)" },
+        { "id": "6.2", "text": "Includes docker-compose.yml for running PostgreSQL, Redis, and Elasticsearch locally" },
+        { "id": "6.3", "text": "Provides a Quick Start section showing clone-to-running-tests in a few commands" },
+        { "id": "6.4", "text": "Mentions or provides devcontainer configuration for consistent environments" },
+        { "id": "6.5", "text": "Separates unit tests (fast, no deps) from integration tests (needs services)" }
+      ]
+    },
+    {
+      "id": 7,
+      "name": "security-fix-miscategorized",
+      "prompt": "We use Keep a Changelog format. A junior developer wrote this CHANGELOG entry for our new release. Is it correct?\n\n```markdown\n## [2.3.0] - 2026-04-10\n\n### Added\n- New streaming API for large file transfers\n- Support for HTTP/3\n\n### Fixed\n- Null pointer dereference when config is missing\n- Deserialization flaw allowing arbitrary code execution via malformed input (GHSA-xxxx-yyyy-zzzz)\n- Off-by-one error in retry backoff calculation\n\n### Changed\n- Connection pool default size increased to 50\n```",
+      "trap": "The GHSA vulnerability is listed under Fixed. Per Keep a Changelog format, security fixes belong in a dedicated ### Security section. A model without skill knowledge treats all bug fixes as Fixed and has no reason to split them. The model must know that Keep a Changelog defines Security as its own top-level category.",
+      "assertions": [
+        { "id": "7.1", "text": "Identifies that the GHSA/deserialization fix belongs in a dedicated ### Security section, not ### Fixed" },
+        { "id": "7.2", "text": "Recommends creating a ### Security subsection that is separate from ### Fixed" },
+        { "id": "7.3", "text": "Keeps the null pointer and off-by-one fixes under ### Fixed — they are bugs, not vulnerabilities" },
+        { "id": "7.4", "text": "Does not move non-security bugs into the Security section" },
+        { "id": "7.5", "text": "Notes that the Security category exists as its own top-level changelog category, not a subcategory of Fixed" }
+      ]
+    },
+    {
+      "id": 8,
+      "name": "llms-txt",
+      "prompt": "I have a Go library `github.com/acme/querybuilder` that provides a type-safe SQL query builder. It has these main types: Builder, Query, Condition, JoinClause. Main functions: New(), Select(), Insert(), Update(), Delete(). Errors: ErrInvalidColumn, ErrMissingTable. I want to make my library more accessible to AI coding assistants. What should I do and can you create any needed files?",
+      "trap": "Model without skill won't know about llms.txt convention. Might suggest better README or doc comments only.",
+      "assertions": [
+        { "id": "8.1", "text": "Creates or recommends creating an llms.txt file at the repository root" },
+        { "id": "8.2", "text": "llms.txt includes an Overview section explaining what the library does" },
+        { "id": "8.3", "text": "llms.txt includes Key Concepts or API Reference listing the main types and functions" },
+        { "id": "8.4", "text": "llms.txt includes Common Patterns section with code examples" },
+        { "id": "8.5", "text": "Mentions registering for discoverability platforms (Context7, DeepWiki, or similar)" }
+      ]
+    },
+    {
+      "id": 9,
+      "name": "brief-doc-comment-trap",
+      "prompt": "Write a brief, one-line doc comment for this exported Go function. Keep it short — I don't want verbose documentation cluttering the code:\n\n```go\npackage retry\n\nfunc Do(ctx context.Context, maxAttempts int, delay time.Duration, backoff float64, fn func() error) error {\n    var lastErr error\n    for i := 0; i < maxAttempts; i++ {\n        if err := fn(); err != nil {\n            lastErr = err\n            select {\n            case <-ctx.Done():\n                return ctx.Err()\n            case <-time.After(delay):\n                delay = time.Duration(float64(delay) * backoff)\n            }\n            continue\n        }\n        return nil\n    }\n    return lastErr\n}\n```",
+      "trap": "User explicitly asks for 'brief, one-line'. Without skill, model complies and writes a minimal one-liner. With skill, the model should STILL write a comprehensive comment because the skill says every exported function MUST have a doc comment with Parameters, Returns, and Example sections",
+      "assertions": [
+        { "id": "9.1", "text": "Comment starts with 'Do' followed by a verb phrase (godoc convention)" },
+        { "id": "9.2", "text": "Includes a Parameters section or describes each parameter (ctx, maxAttempts, delay, backoff, fn)" },
+        { "id": "9.3", "text": "Documents the exponential backoff behavior (delay multiplied by backoff factor)" },
+        { "id": "9.4", "text": "Documents context cancellation behavior (returns ctx.Err())" },
+        { "id": "9.5", "text": "Includes an inline Example section showing a realistic usage pattern" }
+      ]
+    },
+    {
+      "id": 10,
+      "name": "review-restating-comments",
+      "prompt": "Review these doc comments. My team says our documentation is solid. Do you see any issues?\n\n```go\npackage cache\n\n// Get gets a value from the cache by key.\n// Returns the value and true if found, zero value and false if not.\nfunc (c *Cache) Get(key string) (interface{}, bool) { ... }\n\n// Set sets a value in the cache for the given key.\nfunc (c *Cache) Set(key string, value interface{}) { ... }\n\n// Delete deletes a value from the cache by key.\nfunc (c *Cache) Delete(key string) { ... }\n\n// Size returns the number of items currently in the cache.\nfunc (c *Cache) Size() int { ... }\n\n// Clear clears all items from the cache.\nfunc (c *Cache) Clear() { ... }\n```",
+      "trap": "Team says docs are 'solid', creating social pressure to agree. All comments describe what the code does but not why/when/constraints — they omit thread safety, TTL/eviction behavior, and cache miss semantics. The skill requires comments to explain WHY and WHEN, not just WHAT.",
+      "assertions": [
+        { "id": "10.1", "text": "Identifies that the comments describe WHAT the code does but fail to explain WHY, WHEN, or any constraints" },
+        { "id": "10.2", "text": "Points out that Get is missing thread-safety documentation (is it safe for concurrent use?)" },
+        { "id": "10.3", "text": "Points out that Set is missing documentation on what happens if the key already exists and whether there is a TTL or capacity limit" },
+        { "id": "10.4", "text": "Rewrites at least one comment to include constraints, edge cases, or concurrent-use guarantees" },
+        { "id": "10.5", "text": "Does NOT simply agree that the docs are solid without identifying the missing context" }
+      ]
+    },
+    {
+      "id": 11,
+      "name": "skip-test-func-comments",
+      "prompt": "I'm adding doc comments to every function in my Go project to reach 100% documentation coverage. Please add appropriate doc comments to these test functions:\n\n```go\npackage auth_test\n\nfunc TestValidateToken(t *testing.T) { ... }\nfunc TestValidateToken_expired(t *testing.T) { ... }\nfunc TestValidateToken_invalidSignature(t *testing.T) { ... }\nfunc BenchmarkValidateToken(b *testing.B) { ... }\nfunc TestHashPassword(t *testing.T) { ... }\nfunc TestComparePassword(t *testing.T) { ... }\n```",
+      "trap": "User explicitly asks to add doc comments to test functions citing '100% documentation coverage'. Without skill, model complies and writes comments for each test. The skill's 'What to Document' table explicitly says 'Test functions: No' and the model should push back on this request.",
+      "assertions": [
+        { "id": "11.1", "text": "Advises against or actively discourages adding doc comments to test functions" },
+        { "id": "11.2", "text": "Explains that test function names are designed to be self-descriptive — the name IS the documentation" },
+        { "id": "11.3", "text": "Does NOT produce doc comments for any of the standard Test/Benchmark functions listed" },
+        { "id": "11.4", "text": "Clarifies that '100% documentation coverage' tools do not count unexported or test functions — this goal does not apply here" },
+        { "id": "11.5", "text": "May suggest that complex test setup helpers warrant comments, but not the standard TestXxx/BenchmarkXxx functions themselves" }
+      ]
+    },
+    {
+      "id": 12,
+      "name": "simple-crud-no-file-desc",
+      "prompt": "I have a Go file `user_handler.go` (120 lines) that contains standard CRUD HTTP handlers for a User resource: CreateUser, GetUser, UpdateUser, DeleteUser, and ListUsers. Each handler does basic JSON decode, calls a service, and returns a JSON response. Should I add a file-level description comment with an architecture diagram like I did for my scheduler file?",
+      "trap": "User references having added a file description to a complex scheduler file and wants to do the same for a simple CRUD handler. Without skill, model might agree or add unnecessary documentation. With skill, model should say NO — simple CRUD handlers don't warrant file-level descriptions per the 'When to Add File Descriptions' table",
+      "assertions": [
+        { "id": "12.1", "text": "Advises against adding a file-level description for this CRUD handler" },
+        { "id": "12.2", "text": "Explains that simple CRUD handlers don't warrant the same treatment as complex algorithms" },
+        { "id": "12.3", "text": "Distinguishes between when file descriptions ARE needed (algorithms, state machines, 200+ lines of complex logic) vs not needed (CRUD, data models)" },
+        { "id": "12.4", "text": "Still recommends good doc comments on the individual exported handler functions" },
+        { "id": "12.5", "text": "Does NOT produce an ASCII art diagram or elaborate file-level description" }
+      ]
+    },
+    {
+      "id": 13,
+      "name": "file-level-description",
+      "prompt": "I have a Go file `scheduler.go` that implements a priority-queue-based task scheduler using container/heap. It supports recurring tasks, one-shot tasks, task cancellation, and graceful shutdown with a drain timeout. A single dispatcher goroutine polls the heap. The file is 350 lines. Should I add any special documentation to this file, and if so, what?",
+      "trap": "Model might just say 'add function comments'. Skill teaches file-level description with ASCII art architecture diagram for complex files",
+      "assertions": [
+        { "id": "13.1", "text": "Recommends a file-level description comment (not just function comments)" },
+        { "id": "13.2", "text": "Suggests including an ASCII art diagram showing the scheduler architecture/flow" },
+        { "id": "13.3", "text": "Places the file description below imports (not above package declaration)" },
+        { "id": "13.4", "text": "Description explains the algorithm/design (priority queue, dispatcher goroutine)" },
+        { "id": "13.5", "text": "Notes the 200+ line threshold or 'complex algorithm' as reason for adding the description" }
+      ]
+    },
+    {
+      "id": 14,
+      "name": "grpc-api-docs",
+      "prompt": "I have a Go gRPC service for user management. The proto file currently has no comments at all. A teammate says I should use swaggo/swag since we already use it for our REST API. What's the right way to document a gRPC API?",
+      "trap": "Teammate explicitly suggests swaggo/swag for gRPC. The model must know that swaggo/swag generates OpenAPI from Go HTTP annotations — it has no concept of protobufs. Without skill knowledge, the model might go along with the suggestion or give a vague answer. With skill, the model knows proto files are the source of truth and buf is the right tool.",
+      "assertions": [
+        { "id": "14.1", "text": "Clearly states that swaggo/swag is NOT the right tool for gRPC — it generates OpenAPI for REST APIs, not protobuf documentation" },
+        { "id": "14.2", "text": "States that proto files themselves serve as the API contract AND documentation — add comments there" },
+        { "id": "14.3", "text": "Recommends adding comments directly to proto messages, services, and RPCs" },
+        { "id": "14.4", "text": "Recommends buf for proto linting and breaking change detection" },
+        { "id": "14.5", "text": "Mentions grpc-gateway as an option for projects needing both REST and gRPC from the same proto" }
+      ]
+    },
+    {
+      "id": 15,
+      "name": "app-disguised-as-library",
+      "prompt": "I'm building a Go project at `github.com/acme/datactl`. The project structure is:\n```\ncmd/\n  datactl/\n    main.go\ninternal/\n  ingester/\n  transformer/\n  exporter/\npkg/\n  config/\n  client/\ngo.mod\n```\nThe `pkg/` directory exports a client SDK that other teams import. The `cmd/` directory builds the CLI binary. What documentation strategy should I use? Should I write ExampleXxx tests and Playground demos for the exported packages?",
+      "trap": "Project is BOTH a library (pkg/) AND an application (cmd/). Without skill, model might treat it as one or the other. With skill, model should detect both types and apply different documentation strategies: ExampleXxx for pkg/, CLI help + install methods for cmd/",
+      "assertions": [
+        { "id": "15.1", "text": "Identifies this as BOTH a library (pkg/) AND an application (cmd/) — not just one type" },
+        { "id": "15.2", "text": "Recommends ExampleXxx test functions for the pkg/client and pkg/config packages (library part)" },
+        { "id": "15.3", "text": "Recommends CLI --help text and multiple installation methods for the cmd/datactl binary (application part)" },
+        { "id": "15.4", "text": "Recommends configuration documentation (env vars, config files, flags) for the CLI" },
+        { "id": "15.5", "text": "Does NOT recommend Playground demos for internal/ packages (they are not importable by external users)" }
+      ]
+    },
+    {
+      "id": 16,
+      "name": "existing-contributing-improve",
+      "prompt": "Our Go project requires PostgreSQL and Redis. This is our current CONTRIBUTING.md. Improve it:\n\n```markdown\n# Contributing\n\n## Prerequisites\n- Go 1.22+\n- PostgreSQL 15\n- Redis 7\n\n## Setup\n1. Install Go from https://go.dev\n2. Install PostgreSQL from https://www.postgresql.org/download/\n3. Install Redis from https://redis.io/download/\n4. Create a database: `createdb myapp_test`\n5. Run `go build ./...`\n6. Run `go test ./...`\n\n## Pull Requests\nPlease open a PR against the main branch.\n```",
+      "trap": "The existing CONTRIBUTING requires manual installation of PostgreSQL and Redis — time-consuming and error-prone. Without skill, model might polish the text or add small improvements. With skill, model should apply the 10-minute rule: replace manual installs with docker-compose, add Makefile, suggest devcontainer",
+      "assertions": [
+        { "id": "16.1", "text": "Adds docker-compose.yml to replace manual PostgreSQL and Redis installation" },
+        { "id": "16.2", "text": "Adds a Makefile with targets (make build, make test, make lint, or similar)" },
+        { "id": "16.3", "text": "Reduces the setup steps to 3 or fewer commands (e.g., clone, docker-compose up, make test)" },
+        { "id": "16.4", "text": "Mentions or suggests devcontainer for consistent environments" },
+        { "id": "16.5", "text": "Separates unit tests (fast, no deps) from integration tests (needs PostgreSQL/Redis)" }
+      ]
+    },
+    {
+      "id": 17,
+      "name": "play-link-doc-comment",
+      "prompt": "I maintain a public Go library. Write a comprehensive doc comment for this function. I need it to show up well on pkg.go.dev — include everything users need to understand it at a glance:\n\n```go\npackage sliceutil\n\nfunc Filter[T any](s []T, predicate func(T) bool) []T {\n    var result []T\n    for _, v := range s {\n        if predicate(v) {\n            result = append(result, v)\n        }\n    }\n    return result\n}\n```",
+      "trap": "Model may write a thorough doc comment but omit the Play: line entirely — it's a niche convention the skill specifically teaches. The Play: line with its exact format (// Play: https://...) is a skill-specific pattern not commonly known.",
+      "assertions": [
+        { "id": "17.1", "text": "Includes a `// Play:` line with a URL pointing to a Go Playground demo" },
+        { "id": "17.2", "text": "The Play: line uses the exact format `// Play: https://go.dev/play/p/...` (not inline, not as a different label)" },
+        { "id": "17.3", "text": "Comment starts with 'Filter' followed by a verb phrase" },
+        { "id": "17.4", "text": "Includes an inline code Example section (tab-indented)" },
+        { "id": "17.5", "text": "Documents that a new slice is returned (original is not modified)" }
+      ]
+    },
+    {
+      "id": 18,
+      "name": "architecture-decision-records",
+      "prompt": "Our Go project has made several important architectural decisions: using PostgreSQL over MongoDB, choosing event-driven architecture with NATS, and using JWT for authentication. How should we document these decisions so future team members understand the rationale?",
+      "trap": "Model might suggest a wiki page or a section in README. Skill teaches docs/architecture/ directory with numbered ADR files",
+      "assertions": [
+        { "id": "18.1", "text": "Recommends a docs/architecture/ directory (not wiki or README section)" },
+        { "id": "18.2", "text": "Uses numbered file format (0001-xxx.md, 0002-xxx.md)" },
+        { "id": "18.3", "text": "Each ADR has Context section explaining the need" },
+        { "id": "18.4", "text": "Each ADR has Design/Decision section explaining what was chosen" },
+        { "id": "18.5", "text": "Each ADR has Consequences section (positive and negative trade-offs)" }
+      ]
+    },
+    {
+      "id": 19,
+      "name": "example-method-naming",
+      "prompt": "Write Example test functions for this Go type and its methods. Cover: creating a new client, making a GET request, making a POST request with a body, and setting custom headers.\n\n```go\npackage httpclient\n\ntype Client struct { ... }\nfunc New(opts ...Option) *Client { ... }\nfunc (c *Client) Get(ctx context.Context, url string) (*Response, error) { ... }\nfunc (c *Client) Post(ctx context.Context, url string, body io.Reader) (*Response, error) { ... }\nfunc (c *Client) SetHeader(key, value string) { ... }\n```",
+      "trap": "The method example naming convention (ExampleClient_Get, ExampleClient_Post) is less well known than the function convention. Without the skill, the model may write ExampleGetRequest, ExamplePost, ExampleClient_GetRequest (mixing conventions), or use capitalized suffixes. The exact pattern is TypeName_MethodName.",
+      "assertions": [
+        { "id": "19.1", "text": "Uses ExampleNew or ExampleClient for the constructor example — NOT ExampleNewClient (which stutters) or ExampleNew_client" },
+        { "id": "19.2", "text": "Uses ExampleClient_Get for the GET request example (TypeName_MethodName convention with capital method name)" },
+        { "id": "19.3", "text": "Uses ExampleClient_Post for the POST request example (same TypeName_MethodName pattern)" },
+        { "id": "19.4", "text": "Every example includes an // Output: comment" },
+        { "id": "19.5", "text": "Uses external test package (package httpclient_test)" }
+      ]
+    },
+    {
+      "id": 20,
+      "name": "discoverability-registration",
+      "prompt": "I just published my Go library on GitHub (public repo, MIT license, tagged v1.0.0). I have a good README, doc comments, ExampleXxx tests, and a CHANGELOG. What else should I do to make sure developers and AI tools can find and use my library?",
+      "trap": "Model without skill knowledge of the specific platforms will give generic answers: 'share on social media', 'write a blog post', 'submit to HackerNews'. The skill teaches specific discoverability platforms: Context7, DeepWiki, OpenDeep, zRead — names the model won't know without the skill.",
+      "assertions": [
+        { "id": "20.1", "text": "Recommends registering with Context7 (context7.com) specifically for AI-accessible documentation" },
+        { "id": "20.2", "text": "Recommends registering with DeepWiki (deepwiki.com) specifically" },
+        { "id": "20.3", "text": "Recommends adding an llms.txt file at the repository root" },
+        { "id": "20.4", "text": "Recommends adding Go Playground demos linked from doc comments with the // Play: format" },
+        { "id": "20.5", "text": "Names at least 3 specific discoverability platforms (from: Context7, DeepWiki, OpenDeep, zRead) — not generic promotion advice" }
+      ]
+    },
+    {
+      "id": 21,
+      "name": "deprecated-marker-format",
+      "prompt": "I'm deprecating a function in my Go library. The old function is `ParseDuration` and the new replacement is `ParseDurationStrict`. Write the doc comment for the deprecated function. Also, I want to make sure automated tools and pkg.go.dev show it as deprecated correctly.",
+      "trap": "Model might use a freeform deprecation notice (e.g., 'This function is deprecated, use X instead') instead of the specific godoc Deprecated: marker format that tools recognize. The exact format with 'Deprecated:' on its own paragraph line is required for godoc rendering and tooling detection",
+      "assertions": [
+        { "id": "21.1", "text": "Uses the exact 'Deprecated:' marker (capital D, colon, space) on its own comment paragraph line — this is the format godoc and tools recognize" },
+        { "id": "21.2", "text": "Includes the replacement function name (ParseDurationStrict) after the Deprecated: marker" },
+        { "id": "21.3", "text": "Mentions a version or timeline for removal (e.g., 'will be removed in v3.0.0')" }
+      ]
+    }
+  ]
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/application.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/application.md
new file mode 100644
index 00000000..45f6e718
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/application.md
@@ -0,0 +1,210 @@
+# Application Documentation
+
+→ See `samber/cc-skills-golang@golang-cli` skill for CLI application patterns and frameworks.
+
+## CLI Help Text
+
+For CLI applications, `--help` output is the primary documentation. CLI tools MUST have comprehensive `--help` text:
+
+```go
+// Use cobra or similar framework for structured help text
+var rootCmd = &cobra.Command{
+    Use:   "mytool",
+    Short: "A brief description of mytool",
+    Long: `A longer description that explains the tool in detail.
+
+mytool helps you do X, Y, and Z. It connects to your
+database and performs analysis on the data.
+
+Environment variables:
+  MYTOOL_DB_URL    Database connection string (required)
+  MYTOOL_LOG_LEVEL Log level: debug, info, warn, error (default: info)
+  MYTOOL_TIMEOUT   Request timeout (default: 30s)`,
+    Example: `  # Basic usage
+  mytool analyze --input data.csv
+
+  # With custom configuration
+  mytool analyze --input data.csv --output report.json --format json
+
+  # Using environment variables
+  export MYTOOL_DB_URL="postgres://localhost/mydb"
+  mytool serve`,
+}
+```
+
+---
+
+## Configuration Documentation
+
+Configuration SHOULD be documented. Document all configuration sources in the README or a dedicated `docs/configuration.md`:
+
+````markdown
+## Configuration
+
+Configuration is loaded in this order (later sources override earlier ones):
+
+1. Default values
+2. Configuration file (`~/.config/mytool/config.yaml`)
+3. Environment variables
+4. Command-line flags
+
+### Environment Variables
+
+| Variable           | Description                | Default | Required |
+| ------------------ | -------------------------- | ------- | -------- |
+| `MYTOOL_DB_URL`    | Database connection string | —       | Yes      |
+| `MYTOOL_LOG_LEVEL` | Log verbosity              | `info`  | No       |
+| `MYTOOL_PORT`      | HTTP server port           | `8080`  | No       |
+| `MYTOOL_TIMEOUT`   | Request timeout            | `30s`   | No       |
+
+### Configuration File
+
+```yaml
+# ~/.config/mytool/config.yaml
+database:
+  url: postgres://localhost/mydb
+  max_connections: 25
+server:
+  port: 8080
+  read_timeout: 30s
+logging:
+  level: info
+  format: json
+```
+````
+
+---
+
+## Architecture & design decisions
+
+For complex applications, document architectural decisions in `docs/architecture/`:
+
+```
+docs/
+  architecture/
+    0001-use-postgres-as-primary-store.md
+    0002-event-driven-architecture.md
+    0003-jwt-for-authentication.md
+    README.md
+```
+
+Each design document follows a standard format:
+
+```markdown
+# Use PostgreSQL as Primary Store
+
+## Context
+
+We need a persistent data store that supports...
+
+## Design
+
+We use PostgreSQL because...
+
+## Consequences
+
+- Positive: ACID transactions, rich query language...
+- Negative: Operational overhead, connection management...
+```
+
+---
+
+## API Documentation
+
+### REST APIs — OpenAPI / Swagger
+
+Use [swaggo/swag](https://github.com/swaggo/swag) to auto-generate OpenAPI docs from Go annotations:
+
+```go
+// @Summary Get user by ID
+// @Description Returns a single user
+// @Tags users
+// @Accept json
+// @Produce json
+// @Param id path int true "User ID"
+// @Success 200 {object} User
+// @Failure 404 {object} ErrorResponse
+// @Failure 500 {object} ErrorResponse
+// @Router /users/{id} [get]
+func GetUser(w http.ResponseWriter, r *http.Request) {
+```
+
+Generate the spec:
+
+```bash
+go get -tool github.com/swaggo/swag/cmd/swag@latest
+go tool swag init -g cmd/server/main.go -o docs/swagger
+```
+
+This produces `docs/swagger/swagger.json` and `docs/swagger/swagger.yaml`. Serve with Swagger UI or Redoc.
+
+### Event-Driven — AsyncAPI
+
+For message-based APIs (Kafka, NATS, RabbitMQ), use [AsyncAPI](https://www.asyncapi.com/):
+
+```yaml
+asyncapi: "2.6.0"
+info:
+  title: Order Events
+  version: "1.0.0"
+channels:
+  orders/created:
+    publish:
+      message:
+        payload:
+          type: object
+          properties:
+            orderId:
+              type: string
+            amount:
+              type: number
+```
+
+### gRPC — Protobuf
+
+Protobuf files serve as both code contracts and documentation. Add comments to messages and RPCs:
+
+```protobuf
+syntax = "proto3";
+
+// UserService manages user accounts.
+service UserService {
+  // GetUser retrieves a user by their unique identifier.
+  // Returns NOT_FOUND if the user does not exist.
+  rpc GetUser(GetUserRequest) returns (User);
+
+  // CreateUser registers a new user account.
+  // Returns ALREADY_EXISTS if the email is taken.
+  rpc CreateUser(CreateUserRequest) returns (User);
+}
+
+// User represents a registered user account.
+message User {
+  // Unique identifier for the user (UUID v4).
+  string id = 1;
+  // User's display name (1-100 characters).
+  string name = 2;
+  // User's email address (must be unique across all users).
+  string email = 3;
+}
+```
+
+Use [buf](https://buf.build/) for linting and breaking change detection:
+
+```bash
+buf lint
+buf breaking --against '.git#branch=main'
+```
+
+For REST+gRPC, use [grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) to serve both from the same protobuf definition.
+
+### When to Use Each Format
+
+| API Style | Format | Auto-generation |
+| --- | --- | --- |
+| REST/HTTP with Go handlers | OpenAPI 3.x | swaggo/swag from annotations |
+| REST/HTTP with framework | OpenAPI 3.x | Framework-specific (e.g., huma) |
+| gRPC services | Protobuf | Proto files are the source of truth |
+| gRPC + REST gateway | Protobuf + OpenAPI | grpc-gateway generates OpenAPI |
+| Message queues / events | AsyncAPI | Manual or code-gen |
+| GraphQL | SDL schema | Schema is the docs |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/code-comments.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/code-comments.md
new file mode 100644
index 00000000..b9703821
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/code-comments.md
@@ -0,0 +1,329 @@
+# Code Comments
+
+→ See `samber/cc-skills-golang@golang-naming` skill for naming conventions that reduce the need for comments.
+
+## Function & Method Doc Comments
+
+### Why, Not What
+
+The most common mistake in doc comments is restating the code. The code already tells the reader _what_ happens — comments SHOULD explain why, not what:
+
+- **Why** this function exists (its purpose in the system)
+- **When** to use it (and when not to)
+- **What constraints** apply (preconditions, thread safety, performance)
+- **What can go wrong** (error cases, panics, edge cases)
+
+Bad — restates the code:
+
+```go
+// GetUser gets a user by ID.
+func GetUser(id string) (*User, error) {
+```
+
+Good — explains why, when, and what can go wrong:
+
+```go
+// GetUser retrieves a user from the database by their unique identifier.
+// Use this for authenticated endpoints where you need the full user profile.
+// For listing or searching, use ListUsers instead — it returns lighter projections.
+//
+// Returns ErrNotFound if no user exists with the given ID.
+// Returns ErrDatabaseUnavailable if the connection pool is exhausted.
+func GetUser(id string) (*User, error) {
+```
+
+### Anti-Patterns to Remove on Sight
+
+| Anti-pattern | Example | Fix |
+| --- | --- | --- |
+| Pure paraphrase | `// GetUser gets a user` on `func GetUser()` — starts with the name (required by godoc) but adds nothing | After the name, add _when_ to use it, constraints, and what can go wrong |
+| Signature restatement | `// Returns a string and an error` | Document _which_ error and _why_ — the signature already shows types |
+| Marketing vocabulary | `seamlessly`, `powerful`, `robust`, `enterprise-grade` | Remove — state facts instead |
+| Invented rationale | `// designed to improve scalability` | Only document what the code actually does |
+| Groundless future claims | `// supports future extensibility` | Remove or back it with an interface or configuration |
+| Hollow filler | `// It's worth noting that...`, `// As mentioned above` | Cut — restate the fact directly if it matters |
+
+### Format
+
+Every doc comment MUST start with the function/method name followed by a verb phrase. This is how godoc renders it in package indexes.
+
+```go
+// FuncName verb-phrase describing what it does.
+```
+
+### Full Comment Template
+
+Use this structure for exported functions and complex internal functions. Omit sections that don't apply (e.g., no Parameters section for zero-arg functions). Focus on the "why" — don't restate what the code already makes obvious:
+
+```go
+// FuncName summarizes what this function does in one sentence.
+// Additional context explaining behavior, algorithms, or design decisions
+// that callers need to know.
+//
+// Parameters:
+//   - paramName: description of what this parameter represents
+//   - anotherParam: description with valid ranges or constraints
+//
+// Returns description of the return value(s).
+// Returns ErrSomething if [condition].
+// Returns ErrAnother if [different condition].
+//
+// Panics if [condition] (only document if the function can panic).
+//
+// It is safe for concurrent use (or: It is NOT safe for concurrent use).
+//
+// Play: https://go.dev/play/p/xxxxx
+//
+// Example:
+//
+//	result, err := pkg.FuncName(arg1, arg2)
+//	if err != nil {
+//	    log.Fatal(err)
+//	}
+//	fmt.Println(result)
+func FuncName(paramName Type, anotherParam Type) (ResultType, error) {
+```
+
+### What to Document
+
+| Element | Document? |
+| --- | --- |
+| Exported functions/methods | Always |
+| Exported types and interfaces | Always |
+| Exported constants and variables | Always |
+| Complex internal functions | Yes — algorithms, non-obvious logic |
+| Simple internal helpers | Optional — only if the name isn't self-explanatory |
+| Test functions | No |
+| Getters/setters with no logic | Brief one-liner is enough |
+
+`TODO` comments SHOULD include a tracking issue reference when one exists (e.g., `// TODO(#123): ...`). For informal notes, `// TODO(username): ...` or plain `// TODO: ...` is acceptable.
+
+### Error Cases and Limitations
+
+Document every error a function can return, and any edge cases or limitations:
+
+```go
+// Parse parses a duration string such as "300ms", "1.5h", or "2h45m".
+//
+// Parameters:
+//   - s: A duration string. Valid time units are "ns", "us", "ms", "s", "m", "h".
+//
+// Returns the parsed duration.
+// Returns ErrInvalidDuration if the string is empty or has an invalid format.
+// Returns ErrOverflow if the duration exceeds math.MaxInt64 nanoseconds.
+//
+// Limitations:
+//   - Does not support day, week, month, or year units.
+//   - Precision is limited to nanoseconds.
+func Parse(s string) (time.Duration, error) {
+```
+
+### Deprecated Functions
+
+Use the `Deprecated:` marker. godoc renders this with special styling:
+
+```go
+// OldFunc does something.
+//
+// Deprecated: Use NewFunc instead. OldFunc will be removed in v3.0.0.
+func OldFunc() {}
+```
+
+### Interface Documentation
+
+Document the interface itself and each method. Explain the contract that implementations must satisfy:
+
+```go
+// Store defines a persistent key-value storage backend.
+// Implementations must be safe for concurrent use by multiple goroutines.
+//
+// All methods accept a context for cancellation and deadlines.
+// Implementations should respect context cancellation and return
+// ctx.Err() when the context is done.
+type Store interface {
+    // Get retrieves the value associated with key.
+    // Returns ErrNotFound if the key does not exist.
+    // Returns ErrExpired if the key exists but has expired.
+    Get(ctx context.Context, key string) ([]byte, error)
+
+    // Set stores a key-value pair with an optional TTL.
+    // If ttl is 0, the entry does not expire.
+    // Overwrites any existing value for the same key.
+    Set(ctx context.Context, key string, value []byte, ttl time.Duration) error
+
+    // Delete removes a key from the store.
+    // Returns nil (not an error) if the key does not exist.
+    Delete(ctx context.Context, key string) error
+}
+```
+
+### Method Comments on Structs
+
+```go
+// Close gracefully shuts down the server.
+// It waits for active connections to complete up to the configured timeout.
+//
+// Returns an error if the shutdown times out or if the server
+// encounters an error while draining connections.
+//
+// Close is idempotent — calling it multiple times is safe.
+// It is NOT safe to call Close concurrently from multiple goroutines.
+func (s *Server) Close() error {
+```
+
+### Inline Code Examples in Comments
+
+Indent code examples by one tab in doc comments. godoc renders these as formatted code blocks:
+
+```go
+// Transform applies a function to each element of a slice and returns
+// a new slice with the results.
+//
+// Example:
+//
+//	names := []string{"alice", "bob"}
+//	upper := Transform(names, strings.ToUpper)
+//	// upper: ["ALICE", "BOB"]
+func Transform[T any, U any](slice []T, fn func(T) U) []U {
+```
+
+### Playground Links
+
+Add a `Play:` line linking to a runnable Go Playground example of a public library. Use the samber/go-playground-mcp tool to create and share playground URLs when available:
+
+```go
+// Map applies a function to each element of a slice.
+//
+// Play: https://go.dev/play/p/abc123xyz
+//
+// Example:
+//
+//	  doubled := Map([]int{1, 2, 3}, func(x int) int { return x * 2 })
+//	  // doubled: [2, 4, 6]
+func Map[T any, U any](s []T, fn func(T) U) []U {
+```
+
+---
+
+## File & Package Comments
+
+### Package Comment
+
+Every package should have a doc comment. Place it in one of these locations:
+
+1. **At the top of the main `.go` file** — for small packages with one or two files
+2. **In a dedicated `doc.go` file** — for packages with many files
+
+```go
+// Package httputil provides HTTP utility functions for request parsing,
+// response writing, and middleware chaining.
+//
+// It is designed to work with the standard net/http package and does not
+// depend on any specific HTTP framework.
+package httputil
+```
+
+Use `doc.go` when the package has 3+ files or the package comment is longer than ~10 lines:
+
+```go
+// Package auth implements authentication and authorization for the API server.
+//
+// # Architecture
+//
+// The package uses a middleware-based approach where each authentication
+// strategy (JWT, API key, OAuth2) implements the Authenticator interface.
+// Strategies are chained and tried in order until one succeeds.
+//
+// # Token Lifecycle
+//
+// Access tokens expire after 15 minutes. Refresh tokens expire after 7 days.
+// Token rotation is automatic — each refresh request issues a new refresh token
+// and invalidates the previous one.
+//
+// # Thread Safety
+//
+// All exported functions and types are safe for concurrent use.
+package auth
+```
+
+### File-Level Description
+
+For files that implement a specific algorithm, feature, or contain complex logic, add a descriptive comment block below the imports. This is a macro description — explain **why** this file or package exists, what problem it solves, and what design choices were made. Use ASCII art to describe complex flows or architectures. Don't describe what each line does:
+
+```go
+package scheduler
+
+import (
+    "container/heap"
+    "sync"
+    "time"
+)
+
+// This file implements a priority-queue-based task scheduler.
+//
+// Tasks are scheduled with a target execution time and stored in a min-heap
+// ordered by deadline. A single dispatcher goroutine polls the heap and
+// executes tasks when their deadline arrives.
+//
+// Supports: recurring tasks, one-shot tasks, task cancellation, and
+// graceful shutdown with drain timeout.
+//
+// Architecture:
+//
+//	            Schedule(task)
+//                  |
+//                  v
+//            [Min-Heap Queue]
+//             (by deadline)
+//                  |
+//         Dispatcher Goroutine
+//            (polling loop)
+//           /              \
+//          /                \
+//     Deadline              Deadline
+//   not reached             reached
+//        |                     |
+//      wait                    v
+//                           Execute
+//                              |
+//                  Recurring?  |  One-shot
+//                  /           |           \
+//                 /            v            \
+//            Re-queue      Complete      Discard
+//                 \            |           /
+//                  \           |          /
+//                   v          v         v
+//                     [Continue polling]
+
+type Scheduler struct {
+```
+
+### When to Add File Descriptions
+
+| Scenario | Add description? |
+| --- | --- |
+| File implements an algorithm (sorting, scheduling, tree traversal) | Yes |
+| File contains a complex state machine or protocol | Yes |
+| File has 200+ lines of related logic | Yes |
+| File is a simple CRUD handler or data model | No |
+| File name already explains everything (`json_parser.go`) | Only if non-obvious |
+
+### Godoc Headings in Comments
+
+Use `# Heading` syntax in doc comments (Go 1.19+) for structured documentation:
+
+```go
+// Package config provides configuration loading and validation.
+//
+// # Supported Sources
+//
+// Configuration can be loaded from environment variables, YAML files,
+// or command-line flags. Sources are merged in order of precedence:
+// flags > env vars > config file > defaults.
+//
+// # Validation
+//
+// All configuration values are validated at load time. Invalid values
+// cause an immediate error rather than failing later at runtime.
+package config
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/library.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/library.md
new file mode 100644
index 00000000..f081454a
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/library.md
@@ -0,0 +1,197 @@
+# Library Documentation
+
+→ See `samber/cc-skills-golang@golang-testing` skill for writing effective Example test functions.
+
+## Public vs Private Libraries
+
+Not all documentation applies equally. Adapt to your audience:
+
+| Documentation | Public Library | Private Library |
+| --- | --- | --- |
+| Doc comments on exported symbols | Required | Required |
+| Package comments | Required | Required |
+| README.md | Required | Required |
+| Code examples in comments | Generous | Generous |
+| `ExampleXxx()` test functions | Recommended | Recommended |
+| Go Playground demos | Recommended | N/A (code not public) |
+| pkg.go.dev / godoc | Primary docs surface | Use `go doc` locally or internal tooling |
+| Documentation website | Large projects | Only if many teams consume the library |
+| Register in Context7/DeepWiki/etc. | Recommended | N/A |
+| llms.txt | Recommended | Optional |
+| CHANGELOG.md | Recommended | Recommended |
+| CONTRIBUTING.md | Recommended | Recommended (internal wiki may suffice) |
+
+**Private libraries** should still have excellent doc comments and examples — teams rotate, people forget, and AI agents need context to help effectively. The main difference is you skip public-facing artifacts (playground, pkg.go.dev, registries).
+
+---
+
+## Go Playground Demos
+
+Create runnable demos on the Go Playground and link them in doc comments. This lets users try your library without installing anything. Only applicable to public libraries.
+
+Add a `Play:` line in the doc comment:
+
+```go
+// Map applies fn to each element of the slice and returns a new slice.
+//
+// Play: https://go.dev/play/p/abc123xyz
+//
+// Example:
+//
+//	doubled := Map([]int{1, 2, 3}, func(x int) int { return x * 2 })
+//	// doubled: [2, 4, 6]
+func Map[T any, U any](s []T, fn func(T) U) []U {
+```
+
+When the samber/go-playground-mcp tool is available, use it to create and share playground URLs. Otherwise, create them manually at <https://go.dev/play/>.
+
+Guidelines for playground demos:
+
+- Keep demos self-contained — include all imports and a `main()` function
+- Show the most common use case first
+- Show real-world examples
+- Print results so the output is visible when someone clicks "Run"
+- Add comments explaining what each section does
+
+---
+
+## Example Test Functions
+
+Libraries MUST have Example test functions for exported APIs. Example functions are executable documentation. They appear in godoc and are verified by `go test`:
+
+```go
+// In map_example_test.go
+
+package mypackage_test
+
+import (
+    "fmt"
+    "github.com/{owner}/{repo}"
+)
+
+// ExampleMap demonstrates mapping over a slice.
+func ExampleMap() {
+    result := mypackage.Map([]int{1, 2, 3}, func(x int) int {
+        return x * 2
+    })
+    fmt.Println(result)
+    // Output: [2 4 6]
+}
+
+// ExampleMap_strings demonstrates mapping with string transformation.
+func ExampleMap_strings() {
+    result := mypackage.Map([]string{"hello", "world"}, strings.ToUpper)
+    fmt.Println(result)
+    // Output: [HELLO WORLD]
+}
+```
+
+Naming conventions:
+
+- `ExampleFuncName()` — example for a package-level function
+- `ExampleTypeName()` — example for a type
+- `ExampleTypeName_MethodName()` — example for a method
+- `ExampleFuncName_suffix()` — multiple examples for the same function (suffix is lowercase)
+- `Example()` — example for the whole package
+
+The `// Output:` comment MUST be included for `go test` to verify the example. Without it, the example compiles but doesn't verify output.
+
+---
+
+## Code Examples in Doc Comments
+
+Be generous with examples in doc comments. Show common use cases, edge cases, and error handling:
+
+```go
+// NewClient creates a new HTTP client with the given options.
+//
+// Example — basic client:
+//
+//	client := NewClient()
+//
+// Example — with custom timeout and retries:
+//
+//	client := NewClient(
+//	    WithTimeout(10 * time.Second),
+//	    WithRetries(3),
+//	    WithRetryBackoff(time.Second),
+//	)
+//
+// Example — with authentication:
+//
+//	client := NewClient(
+//	    WithBearerToken(os.Getenv("API_TOKEN")),
+//	)
+func NewClient(opts ...Option) *Client {
+```
+
+---
+
+## godoc and pkg.go.dev
+
+Your doc comments automatically render on [pkg.go.dev](https://pkg.go.dev) when you tag a release and someone imports your package. This is the primary documentation surface for public Go libraries.
+
+**How godoc renders comments:**
+
+- First sentence of each doc comment appears in the package index
+- `// Package foo provides...` appears as the package description
+- Code blocks (indented by one tab) render as formatted code
+- `# Heading` syntax (Go 1.19+) creates sections
+- `[Link text]` syntax creates hyperlinks
+- `[Identifier]` links to other symbols in the package
+- `Deprecated:` marker gets special styling
+
+**For private libraries:** pkg.go.dev won't index private modules. Use `go doc` locally or run `pkgsite` on your internal network. Some teams set up a shared pkgsite instance for internal Go modules.
+
+```bash
+# View docs for a specific symbol
+go doc github.com/{owner}/{repo}.FuncName
+
+# View full package docs
+go doc -all github.com/{owner}/{repo}
+
+# Start a local godoc server
+go get -tool golang.org/x/pkgsite/cmd/pkgsite@latest
+go tool pkgsite -http=:6060
+# Then open http://localhost:6060
+```
+
+---
+
+## Documentation Website
+
+For larger libraries or frameworks, consider a dedicated documentation website.
+
+### Recommended Frameworks
+
+- **Docusaurus** (React-based) — best for large projects, supports versioning natively
+- **MkDocs Material** (Python-based) — simpler setup, great search, clean design
+
+Both can be deployed on Vercel.
+
+### Recommended Sections
+
+Follow the [Diataxis framework](https://diataxis.fr/) for organizing documentation:
+
+| Section | Purpose | Example |
+| --- | --- | --- |
+| Getting Started | First steps, installation, hello world | "Install and run your first query in 5 minutes" |
+| Tutorial | Step-by-step learning | "Build a REST API with authentication" |
+| How-to Guides | Task-oriented recipes | "How to configure connection pooling" |
+| Reference | Complete API documentation | Auto-generated from godoc |
+| Deep dive / internals | Conceptual understanding | "How the scheduler algorithm works" |
+
+### llms.txt
+
+Add a `llms.txt` file at the repository root to help AI agents understand your project. Copy the template from [templates/llms.txt](./templates/llms.txt).
+
+This is an emerging convention for making projects AI-friendly. Place it alongside your README.
+
+### Register for Discoverability
+
+Make your library findable by AI agents and documentation aggregators:
+
+- **Context7** — <https://context7.com> — submit your library for inclusion in AI-accessible documentation
+- **DeepWiki** — <https://deepwiki.com> — auto-generates wiki-style docs from GitHub repos
+- **OpenDeep** — <https://opendeep.wiki> — open documentation platform for AI consumption
+- **zRead** — <https://zread.ai> — developer documentation reader
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/project-docs.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/project-docs.md
new file mode 100644
index 00000000..3f4b43ac
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-documentation/references/project-docs.md
@@ -0,0 +1,115 @@
+# Project Documentation
+
+→ See `samber/cc-skills-golang@golang-continuous-integration` skill for automating changelog generation and release workflows.
+
+## README.md
+
+A LICENSE file MUST exist in every project. A README is the front page of your project. Make it simple, clear, and scannable. A copy-paste template with empty sections is available at [templates/README.md](./templates/README.md).
+
+### Section Order
+
+Follow this exact order (all sections are in the template):
+
+1. **Title** — project name as `# heading`
+2. **Badges** — shields.io pictograms (Go version, license, CI, coverage, Go Report Card)
+3. **Summary** — 1-2 sentences explaining what the project does
+4. **Demo** — code snippet (libraries), GIF/video (CLIs), or screenshot (web UIs)
+5. **Getting Started** — installation + minimal working example
+6. **Features / Specification** — the longest section, organized by feature area
+7. **Contributing** — link to CONTRIBUTING.md or inline if very short
+8. **License** — license name + link
+
+The template includes commented-out sections for applications (binary download table, Docker, Homebrew) that you can uncomment as needed.
+
+---
+
+## CONTRIBUTING.md
+
+The goal: a new contributor should be able to clone the repo, make a change, and run the tests **in under 10 minutes**. If your project takes longer, add tooling to fix that.
+
+Copy the template from [templates/CONTRIBUTING.md](./templates/CONTRIBUTING.md).
+
+### The 10-Minute Rule
+
+If setup takes more than 10 minutes, add these improvements:
+
+| Problem | Solution |
+| --- | --- |
+| Complex build steps | Add a `Makefile` with `make build`, `make test`, `make lint` |
+| External service dependencies | Add `docker-compose.yml` for local dev |
+| Inconsistent dev environments | Add `.devcontainer/` for VS Code devcontainers |
+| Slow test suite | Separate unit tests (fast) from integration tests (build tags) |
+| Missing documentation | Add `make help` that lists available targets |
+
+---
+
+## Changelog
+
+CHANGELOG MUST be updated for every release. Track notable changes for each release. Use [Keep a Changelog](https://keepachangelog.com/) format. Copy the template from [templates/CHANGELOG.md](./templates/CHANGELOG.md).
+
+### Format
+
+```markdown
+## [1.2.0] - 2026-03-08
+
+### Added
+
+- New `WithTimeout` option for client configuration
+
+### Changed
+
+- Improved retry logic to use exponential backoff
+
+### Fixed
+
+- Race condition in connection pool under heavy load
+
+### Deprecated
+
+- `SetTimeout()` method — use `WithTimeout()` option instead
+
+[1.2.0]: https://github.com/{owner}/{repo}/compare/v1.1.0...v1.2.0
+```
+
+### Change Categories
+
+- **Added** — new features
+- **Changed** — changes in existing functionality
+- **Deprecated** — features that will be removed
+- **Removed** — removed features
+- **Fixed** — bug fixes
+- **Security** — vulnerability fixes
+
+### GitHub Releases as Alternative
+
+For simpler projects, GitHub Releases can replace a CHANGELOG file. GoReleaser auto-generates release notes from git commits.
+
+---
+
+## Distribution
+
+**YOU MUST offer multiple installation paths** (binaries, containers, APT/Homebrew/... package managers, source). Because:
+
+- Each installation method eliminates friction for a different user segment
+- Users adopt tools that fit their workflow, not tools that force workflow changes
+- A single installation path is a hidden tax on adoption—DevOps engineers skip tools requiring npm, macOS developers skip tools without Homebrew
+- Tools users _want to_ use spread faster than tools users _have to_ accommodate
+
+### Dockerfile Best Practices
+
+Use multi-stage builds with a minimal final image:
+
+```dockerfile
+# Build stage
+FROM golang:1.26-alpine AS builder
+WORKDIR /app
+COPY go.mod go.sum ./
+RUN go mod download
+COPY . .
+RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o /app/binary ./cmd/server
+
+# Final stage
+FROM gcr.io/distroless/static-debian12:nonroot
+COPY --from=builder /app/binary /binary
+ENTRYPOINT ["/binary"]
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/SKILL.md
new file mode 100644
index 00000000..08cb71fa
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/SKILL.md
@@ -0,0 +1,87 @@
+---
+name: golang-error-handling
+description: "Idiomatic Golang error handling — creation, wrapping with %w, errors.Is/As, errors.Join, custom error types, sentinel errors, panic/recover, the single handling rule, structured logging with slog, HTTP request logging middleware, and samber/oops for production errors. Built to make logs usable at scale with log aggregation 3rd-party tools. Apply when creating, wrapping, inspecting, or logging errors in Go code. For samber/oops specifics → See `samber/cc-skills-golang@golang-samber-oops` skill; for slog handler ecosystem → See `samber/cc-skills-golang@golang-samber-slog` skill."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.0"
+  openclaw:
+    emoji: "⚠"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent
+---
+
+**Persona:** You are a Go reliability engineer. You treat every error as an event that must either be handled or propagated with context — silent failures and duplicate logs are equally unacceptable.
+
+**Modes:**
+
+- **Coding mode** — writing new error handling code. Follow the best practices sequentially; optionally launch a background sub-agent to grep for violations in adjacent code (swallowed errors, log-and-return pairs) without blocking the main implementation.
+- **Review mode** — reviewing a PR's error handling changes. Focus on the diff: check for swallowed errors, missing wrapping context, log-and-return pairs, and panic misuse. Sequential.
+- **Audit mode** — auditing existing error handling across a codebase. Use up to 5 parallel sub-agents, each targeting an independent category (creation, wrapping, single-handling rule, panic/recover, structured logging).
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-error-handling` skill takes precedence.
+
+# Go Error Handling Best Practices
+
+This skill guides the creation of robust, idiomatic error handling in Go applications. Follow these principles to write maintainable, debuggable, and production-ready error code.
+
+## Best Practices Summary
+
+1. **Returned errors MUST always be checked** — NEVER discard with `_`
+2. **Errors MUST be wrapped with context** using `fmt.Errorf("{context}: %w", err)`
+3. **Error strings MUST be lowercase**, without trailing punctuation
+4. **Use `%w` internally, `%v` at system boundaries** to control error chain exposure
+5. **MUST use `errors.Is` for sentinel matching and `errors.As`/`errors.AsType` for typed chain inspection** instead of direct comparison or bare type assertions. For Go 1.26+, prefer `errors.AsType[T](err)` when `T` implements `error`; use `errors.As(err, &target)` for Go <1.26 or for non-error interface targets.
+6. **SHOULD use `errors.Join`** (Go 1.20+) to combine independent errors
+7. **Errors MUST be either logged OR returned**, NEVER both (single handling rule)
+8. **Use sentinel errors** for expected conditions, custom types for carrying data
+9. **NEVER use `panic` for expected error conditions** — reserve for truly unrecoverable states
+10. **SHOULD use `slog`** (Go 1.21+) for structured error logging — not `fmt.Println` or `log.Printf`
+11. **Use `samber/oops`** for production errors needing stack traces, user/tenant context, or structured attributes
+12. **Log HTTP requests** with structured middleware capturing method, path, status, and duration
+13. **Use log levels** to indicate error severity
+14. **Never expose technical errors to users** — translate internal errors to user-friendly messages, log technical details separately
+15. **Keep log grouping low-cardinality** — at logging/APM boundaries, keep message templates stable and attach IDs, paths, line numbers, and counts as structured attributes. Error values may include useful operational context, but avoid putting high-cardinality data into the stable log message used for grouping.
+
+## Detailed Reference
+
+- **[Error Creation](./references/error-creation.md)** — How to create errors that tell the story: error messages should be lowercase, no punctuation, and describe what happened without prescribing action. Covers sentinel errors (one-time preallocation for performance), custom error types (for carrying rich context), and the decision table for which to use when.
+
+- **[Error Wrapping and Inspection](./references/error-wrapping.md)** — Why `fmt.Errorf("{context}: %w", err)` beats `fmt.Errorf("{context}: %v", err)` (chains vs concatenation). How to inspect chains with `errors.Is`, `errors.As`, and Go 1.26+ `errors.AsType` for type-safe error handling, and `errors.Join` for combining independent errors.
+
+- **[Error Handling Patterns and Logging](./references/error-handling.md)** — The single handling rule: errors are either logged OR returned, NEVER both (prevents duplicate logs cluttering aggregators). Panic/recover design, `samber/oops` for production errors, and `slog` structured logging integration for APM tools.
+
+## Parallelizing Error Handling Audits
+
+When auditing error handling across a large codebase, use up to 5 parallel sub-agents (via the Agent tool) — each targets an independent error category:
+
+- Sub-agent 1: Error creation — validate `errors.New`/`fmt.Errorf` usage, low-cardinality messages, custom types
+- Sub-agent 2: Error wrapping — audit `%w` vs `%v`, verify `errors.Is`/`errors.As` patterns
+- Sub-agent 3: Single handling rule — find log-and-return violations, swallowed errors, discarded errors (`_`)
+- Sub-agent 4: Panic/recover — audit `panic` usage, verify recovery at goroutine boundaries
+- Sub-agent 5: Structured logging — verify `slog` usage at error sites, check for PII in error messages
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-samber-oops` for full samber/oops API, builder patterns, and logger integration
+- → See `samber/cc-skills-golang@golang-observability` for structured logging setup, log levels, and request logging middleware
+- → See `samber/cc-skills-golang@golang-safety` for nil interface trap and nil error comparison pitfalls
+- → See `samber/cc-skills-golang@golang-naming` for error naming conventions (ErrNotFound, PathError)
+- → See `samber/cc-skills-golang@golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines
+
+## References
+
+- [lmittmann/tint](https://github.com/lmittmann/tint)
+- [samber/oops](https://github.com/samber/oops)
+- [samber/slog-multi](https://github.com/samber/slog-multi)
+- [samber/slog-sampling](https://github.com/samber/slog-sampling)
+- [samber/slog-formatter](https://github.com/samber/slog-formatter)
+- [samber/slog-http](https://github.com/samber/slog-http)
+- [samber/slog-sentry](https://github.com/samber/slog-sentry)
+- [log/slog package](https://pkg.go.dev/log/slog)
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/evals/evals.json
new file mode 100644
index 00000000..ef2509be
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/evals/evals.json
@@ -0,0 +1,161 @@
+{
+  "skill_name": "golang-error-handling",
+  "evals": [
+    {
+      "id": 1,
+      "name": "middleware-log-chain",
+      "prompt": "Write a Go HTTP middleware chain with 3 middlewares: LoggingMiddleware, AuthMiddleware, RateLimitMiddleware. Each wraps the next handler. Each middleware should log what it's doing at each step and propagate errors properly up the chain. The final handler processes a request. Include detailed logging at each layer so we can trace the request flow.",
+      "trap": "\"log at each step\" tempts log+return violations and high-cardinality error messages with interpolated IPs/limits",
+      "assertions": [
+        { "id": "1.1", "text": "Uses slog (not log.Printf)" },
+        { "id": "1.2", "text": "Low-cardinality error messages (no IPs/limits interpolated)" },
+        { "id": "1.3", "text": "Structured error context (oops.With, not in error string)" },
+        { "id": "1.4", "text": "Structured slog key-value log entries" },
+        { "id": "1.5", "text": "Error strings lowercase" }
+      ]
+    },
+    {
+      "id": 2,
+      "name": "order-processor",
+      "prompt": "Write a Go function ProcessOrders(ctx context.Context, orders []Order) error that validates and processes each order. Order has ID, UserID, Amount, Currency fields. When validation fails (amount <= 0, empty currency, empty user ID), the error message should clearly indicate which order failed and why, so operators can debug issues in production. Return all errors, not just the first.",
+      "trap": "\"indicate which order failed\" tempts interpolating order IDs into error strings",
+      "assertions": [
+        { "id": "2.1", "text": "Log/APM grouping messages are low-cardinality; IDs and paths are attached as structured attributes rather than baked into the stable log message" },
+        { "id": "2.2", "text": "Variable data as structured attributes (oops/slog)" },
+        { "id": "2.3", "text": "Uses errors.Join to collect all order errors" },
+        { "id": "2.4", "text": "Error strings lowercase" },
+        { "id": "2.5", "text": "Validates ALL fields per order (no short-circuit)" }
+      ]
+    },
+    {
+      "id": 3,
+      "name": "batch-csv-importer",
+      "prompt": "Write a Go function ImportCSV(r io.Reader) (int, error) that reads a CSV with columns: name, email, phone. It validates each row (name not empty, email contains '@', phone is digits only). It should return the count of successfully imported rows and a detailed failure report showing every invalid row with its row number and which column failed, so operators can fix the CSV and retry. Process ALL rows even if early ones fail.",
+      "trap": "\"detailed failure report with row numbers\" tempts interpolating row/col into error strings",
+      "assertions": [
+        { "id": "3.1", "text": "Error messages static (no row numbers in error string)" },
+        { "id": "3.2", "text": "Row/column data as structured attributes (oops/slog)" },
+        { "id": "3.3", "text": "Collects all row errors (doesn't stop on first)" },
+        { "id": "3.4", "text": "Error strings lowercase" },
+        { "id": "3.5", "text": "Uses errors.Join for combining errors" }
+      ]
+    },
+    {
+      "id": 4,
+      "name": "wrapped-error-compare",
+      "prompt": "Fix the error handling in this Go code. All errors may be wrapped by middleware before reaching these handlers:\n\n```go\npackage storage\n\nimport (\n    \"database/sql\"\n    \"fmt\"\n    \"net\"\n)\n\nvar ErrNotFound = fmt.Errorf(\"Not Found.\")\nvar ErrConflict = fmt.Errorf(\"Conflict: resource already exists.\")\n\ntype TimeoutError struct {\n    Operation string\n    Duration  int\n}\nfunc (e *TimeoutError) Error() string {\n    return fmt.Sprintf(\"Timeout after %ds on %s.\", e.Duration, e.Operation)\n}\n\nfunc HandleDBError(err error) string {\n    if err == sql.ErrNoRows { return \"not found\" }\n    if err == sql.ErrTxDone { return \"transaction completed\" }\n    if te, ok := err.(*TimeoutError); ok { return fmt.Sprintf(\"timeout on %s\", te.Operation) }\n    if ne, ok := err.(*net.OpError); ok { return fmt.Sprintf(\"network error: %s\", ne.Op) }\n    return \"unknown error\"\n}\n```",
+      "trap": "Pre-existing fmt.Errorf sentinels with capitalization/punctuation + == comparisons + type assertions",
+      "assertions": [
+        { "id": "4.1", "text": "Sentinel errors use errors.New (not fmt.Errorf)" },
+        { "id": "4.2", "text": "Sentinel strings lowercase, no punctuation" },
+        { "id": "4.3", "text": "TimeoutError.Error() lowercase, no punctuation" },
+        { "id": "4.4", "text": "errors.Is for sentinel matching" },
+        { "id": "4.5", "text": "errors.As for type extraction" }
+      ]
+    },
+    {
+      "id": 5,
+      "name": "multi-service-fetch",
+      "prompt": "Write a Go function GetUserDashboard(ctx context.Context, userID string) (*Dashboard, error) that fetches data from 3 microservices: ProfileService.GetProfile(ctx, userID), PreferencesService.GetPreferences(ctx, userID), and ActivityService.GetRecentActivity(ctx, userID, 10). Combine the results into a Dashboard struct. Each service can fail independently.",
+      "trap": "Three service calls tempt bare return err without context or structured attributes",
+      "assertions": [
+        { "id": "5.1", "text": "Errors wrapped with service context" },
+        { "id": "5.2", "text": "Low-cardinality error messages" },
+        { "id": "5.3", "text": "Uses structured attributes (oops/slog)" },
+        { "id": "5.4", "text": "Error strings lowercase" },
+        { "id": "5.5", "text": "Each service identifiable by context prefix" }
+      ]
+    },
+    {
+      "id": 6,
+      "name": "config-validation",
+      "prompt": "Write a Go function ValidateServerConfig(cfg ServerConfig) error. ServerConfig has: Host (string, required), Port (int, 1-65535), TLSCert (string, required if TLSEnabled), TLSKey (string, required if TLSEnabled), TLSEnabled (bool), MaxConns (int, > 0), ReadTimeout (time.Duration, > 0), WriteTimeout (time.Duration, > 0). Validate ALL fields and return a clear error listing every problem found.",
+      "trap": "Many fields tempts early return, custom error type with capitalized field prefixes, or []string instead of errors.Join",
+      "assertions": [
+        { "id": "6.1", "text": "Uses errors.Join for combining validation errors" },
+        { "id": "6.2", "text": "Error strings lowercase" },
+        { "id": "6.3", "text": "Validates ALL fields" },
+        { "id": "6.4", "text": "Conditional TLS validation" },
+        { "id": "6.5", "text": "No panic for validation" }
+      ]
+    },
+    {
+      "id": 7,
+      "name": "modernize-logging",
+      "prompt": "Modernize the logging in this Go code. Keep all the logging but make it production-ready:\n\n```go\npackage worker\n\nimport (\n    \"fmt\"\n    \"log\"\n    \"time\"\n)\n\nfunc ProcessJob(jobID string, payload []byte) error {\n    log.Printf(\"INFO: Starting job %s with %d bytes payload\", jobID, len(payload))\n    start := time.Now()\n    result, err := executeJob(jobID, payload)\n    if err != nil {\n        log.Printf(\"ERROR: Job %s failed after %v: %v\", jobID, time.Since(start), err)\n        return fmt.Errorf(\"processing job %s: %w\", jobID, err)\n    }\n    if result.Warnings > 0 {\n        log.Printf(\"WARNING: Job %s completed with %d warnings\", jobID, result.Warnings)\n    }\n    log.Printf(\"INFO: Job %s completed in %v, processed %d items\", jobID, time.Since(start), result.ItemCount)\n    return nil\n}\n```\n\nA teammate reviewing your modernization says: 'Good, but you removed the error log — when executeJob fails, nothing gets logged. The caller might just propagate the error up the chain and it could get swallowed. We MUST log the error here so it's visible in production.'",
+      "trap": "The teammate's argument sounds reasonable — callers might swallow errors. The skill teaches that each error must be handled once: either log it OR return it, never both. If every function logs-and-returns, the same error gets logged multiple times at every layer, making logs noisy and hard to correlate. The model should push back on the teammate and keep only the return.",
+      "assertions": [
+        { "id": "7.1", "text": "Does not log AND return the same error — the modernized code must choose: either log (and not return) or return (and not log). Both is the anti-pattern." },
+        { "id": "7.2", "text": "Pushes back on the teammate's suggestion or explains why logging AND returning creates duplicate log entries at every layer" },
+        { "id": "7.3", "text": "Uses slog (not log.Printf) with structured key-value attributes" },
+        { "id": "7.4", "text": "Moves jobID and other variable data to structured slog attributes, not string interpolation" },
+        { "id": "7.5", "text": "Low-cardinality log messages — log messages are static strings, variable data is in attributes" }
+      ]
+    },
+    {
+      "id": 8,
+      "name": "graceful-shutdown",
+      "prompt": "Write a Go Application struct with: HTTPServer (*http.Server), DB (*sql.DB), Cache (redis.Client), MessageQueue (amqp.Connection), MetricsServer (*http.Server). Implement GracefulShutdown(ctx context.Context) error that closes ALL of them. Each must be attempted regardless of others failing. Shutdown order: HTTP first, then MQ, then DB+Cache, then Metrics last.",
+      "trap": "5 resources tempts bare append without wrapping context on each error",
+      "assertions": [
+        { "id": "8.1", "text": "Uses errors.Join" },
+        { "id": "8.2", "text": "Each error wrapped with resource context" },
+        { "id": "8.3", "text": "Error strings lowercase" },
+        { "id": "8.4", "text": "Attempts ALL resources even if earlier fail" },
+        { "id": "8.5", "text": "Correct shutdown order" }
+      ]
+    },
+    {
+      "id": 9,
+      "name": "todo-CRUD-repo",
+      "prompt": "Write a Go TodoRepository backed by *sql.DB with full CRUD: Create(ctx, *Todo) error, GetByID(ctx, id string) (*Todo, error), List(ctx, userID string) ([]*Todo, error), Update(ctx, *Todo) error, Delete(ctx, id string) error. Todo has ID, UserID, Title, Done, CreatedAt fields. Make it production-ready with proper error handling.",
+      "trap": "Full CRUD with IDs tempts interpolating todo_id and user_id into error strings",
+      "assertions": [
+        { "id": "9.1", "text": "Low-cardinality error messages (no ID interpolation)" },
+        { "id": "9.2", "text": "Errors wrapped with method context" },
+        { "id": "9.3", "text": "Uses errors.Is for sql.ErrNoRows" },
+        { "id": "9.4", "text": "Sentinel as package-level var" },
+        { "id": "9.5", "text": "Error strings lowercase" }
+      ]
+    },
+    {
+      "id": 10,
+      "name": "retry-handler",
+      "prompt": "Write a Go function WithRetry(ctx context.Context, name string, maxAttempts int, fn func() error) error that retries fn up to maxAttempts times with exponential backoff (starting at 100ms, doubling each time). Log each retry attempt with the attempt number, delay, and error. On final failure, return the last error wrapped with context. Include the operation name and attempt info in logs so operators can diagnose intermittent failures.",
+      "trap": "\"log each retry attempt\" tempts logging inside the retry loop AND returning the final error (log+return)",
+      "assertions": [
+        { "id": "10.1", "text": "Does not log AND return final error (single handling rule)" },
+        { "id": "10.2", "text": "Structured slog attributes" },
+        { "id": "10.3", "text": "Uses slog (not log.Printf)" },
+        { "id": "10.4", "text": "Low-cardinality log messages" },
+        { "id": "10.5", "text": "Wraps final error with context" }
+      ]
+    },
+    {
+      "id": 11,
+      "name": "event-processor",
+      "prompt": "Write a Go function ProcessEvents(ctx context.Context, events []Event) error that processes a batch of events. Event has ID, Type (string: \"user.created\", \"order.placed\", \"payment.failed\", etc.), Payload json.RawMessage, and Timestamp time.Time. Each event type dispatches to a different handler. When processing fails, the error should include the event type, ID, and timestamp so operators can identify which event failed. Collect all errors and return them.",
+      "trap": "\"include event type, ID, and timestamp\" tempts interpolating event details into error strings",
+      "assertions": [
+        { "id": "11.1", "text": "Error messages static (event type/ID not in error string)" },
+        { "id": "11.2", "text": "Event details as structured attributes (oops/slog)" },
+        { "id": "11.3", "text": "Uses errors.Join to collect all event errors" },
+        { "id": "11.4", "text": "Error strings lowercase" },
+        { "id": "11.5", "text": "No logging inside processor (returns to caller)" }
+      ]
+    },
+    {
+      "id": 12,
+      "name": "api-gateway",
+      "prompt": "Write a Go API gateway package that proxies requests to a backend UserService. The gateway has a public GetUser(ctx, id) (*User, error) function. The backend UserService returns its own internal error types: *BackendTimeoutError (with Endpoint, Duration fields), *BackendNotFoundError (with Resource, ID fields), and generic errors.\n\nThe gateway must translate backend errors to clean public domain errors. A security-minded teammate reviewing the design says: 'Make sure you use fmt.Errorf with %w when wrapping backend errors — that way callers can use errors.As to inspect details if they need to debug. We should preserve the full error chain for observability.'\n\nIs the teammate's suggestion correct? Implement the gateway correctly.",
+      "trap": "The teammate's argument sounds compelling — preserving the error chain for observability is a real concern. But %w at an API boundary leaks internal implementation details: callers can use errors.As to inspect *BackendTimeoutError or *BackendNotFoundError, creating a hidden coupling to backend internals. The correct approach: use errors.As internally to extract details, translate to domain errors, and use %v (not %w) so the chain is broken at the boundary.",
+      "assertions": [
+        { "id": "12.1", "text": "Rejects the teammate's %w suggestion — using %w at the gateway boundary lets callers unwrap to backend-internal types via errors.As, creating hidden coupling to implementation details" },
+        { "id": "12.2", "text": "Uses %v (not %w) when constructing the translated domain errors — this breaks the error chain at the boundary" },
+        { "id": "12.3", "text": "Uses errors.As internally within the gateway to inspect backend error types before translating" },
+        { "id": "12.4", "text": "Backend types (*BackendTimeoutError, *BackendNotFoundError) are not accessible via errors.As from callers of the gateway" },
+        { "id": "12.5", "text": "Translates to clean public domain sentinels (ErrNotFound, ErrTimeout, ErrServiceUnavailable) with lowercase error strings" }
+      ]
+    }
+  ]
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-creation.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-creation.md
new file mode 100644
index 00000000..6a6c41e6
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-creation.md
@@ -0,0 +1,145 @@
+# Error Creation
+
+## Errors as Values
+
+Go treats errors as ordinary values implementing the `error` interface:
+
+```go
+type error interface {
+    Error() string
+}
+```
+
+This means errors are returned, not thrown. Every function that can fail returns an `error` as its last return value, and every caller must check it.
+
+```go
+// ✗ Bad — silently discarding errors
+data, _ := os.ReadFile("config.yaml")
+
+// ✗ Bad — only checking in some branches
+result, err := doSomething()
+fmt.Println(result) // using result without checking err
+
+// ✓ Good — always check before using other return values
+data, err := os.ReadFile("config.yaml")
+if err != nil {
+    return fmt.Errorf("reading config: %w", err)
+}
+```
+
+## Error String Conventions
+
+Error strings MUST be lowercase, without trailing punctuation, and should not duplicate the context that wrapping will add.
+
+```go
+// ✗ Bad — capitalized, punctuation, redundant prefix
+return errors.New("Failed to connect to database.")
+return fmt.Errorf("UserService: failed to fetch user: %w", err)
+
+// ✓ Good — lowercase, no punctuation, concise
+return errors.New("connection refused")
+return fmt.Errorf("fetching user: %w", err)
+```
+
+When errors are wrapped through multiple layers, each layer adds its own prefix. The result reads like a chain:
+
+```
+creating order: charging card: connecting to payment gateway: connection refused
+```
+
+## Creating Errors
+
+### `errors.New` — static error messages
+
+```go
+var ErrNotFound = errors.New("not found")
+var ErrUnauthorized = errors.New("unauthorized")
+```
+
+### `fmt.Errorf` — dynamic error messages
+
+```go
+import "github.com/samber/oops"
+
+// ✗ Avoid at log/APM boundaries — each user/tenant combo becomes a unique group
+return fmt.Errorf("user %s not found in tenant %s", userID, tenantID)
+
+// ✓ Prefer for grouped production errors — static message, variable data as structured attributes
+return oops.With("user_id", userID).With("tenant_id", tenantID).Errorf("user not found")
+```
+
+See [Low-Cardinality Error Messages](#low-cardinality-error-messages) for why this matters.
+
+### Decision table: which error strategy to use
+
+| Situation | Strategy | Example |
+| --- | --- | --- |
+| Caller needs to match a specific condition | Sentinel error (`errors.New` as package var) | `var ErrNotFound = errors.New("not found")` |
+| Caller needs to extract structured data | Custom error type | `type ValidationError struct { Field, Msg string }` |
+| Error is purely informational, not matched on | `fmt.Errorf` or `errors.New` | `fmt.Errorf("connecting to %s: %w", addr, err)` |
+| Need stack traces, user context, structured attrs | `samber/oops` | See [Why Use samber/oops](./error-handling.md#why-use-samberoops) |
+
+## Low-Cardinality Error Messages
+
+APM and log aggregation tools (Datadog, Loki, Sentry) commonly group events by the logged message or exception fingerprint. When the stable log message contains variable data, every unique combination can create a separate group — dashboards become noisy and alerting breaks.
+
+```go
+import "github.com/samber/oops"
+
+// ✗ Bad at the log boundary — each file/line combo can create a unique group
+fmt.Errorf("error in %s at line %d of the csv", csvPath, line)
+
+// ✓ Good (stdlib) — static error, structured attributes at the log site
+err := errors.New("csv parsing error")
+// ... later, at the logging boundary:
+slog.Error("csv parsing failed", "error", err, "csv_file_path", csvPath, "csv_file_line", line)
+
+// ✓ Good (samber/oops, external dependency) — attributes travel with the error
+oops.With("csv_file_path", csvPath).With("csv_file_line", line).Errorf("csv parsing error")
+```
+
+The stdlib approach works but scatters context: the error travels up the stack and the handler logging it may no longer have access to the variable data. `samber/oops` (external dependency `github.com/samber/oops`) solves this by attaching structured attributes directly to the error, so they're available wherever the error is eventually logged.
+
+**Static wrapping prefixes are fine** — `fmt.Errorf("fetching user: %w", err)` is low-cardinality because the prefix never changes. Dynamic context in returned errors is sometimes useful for CLI output or debugging, but production logging should keep the grouping message stable and attach IDs, paths, counts, and other variable data as structured attributes.
+
+## Custom Error Types
+
+Create custom error types when callers need to extract structured data from errors.
+
+```go
+type ValidationError struct {
+    Field   string
+    Message string
+}
+
+func (e *ValidationError) Error() string {
+    return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Message)
+}
+
+// Usage
+func validateAge(age int) error {
+    if age < 0 {
+        return &ValidationError{Field: "age", Message: "must be non-negative"}
+    }
+    return nil
+}
+```
+
+### Custom types that wrap other errors
+
+Implement `Unwrap()` so `errors.Is` and `errors.As` can traverse the chain:
+
+```go
+type QueryError struct {
+    Query string
+    Err   error
+}
+
+func (e *QueryError) Error() string {
+    return fmt.Sprintf("query %q: %v", e.Query, e.Err)
+}
+
+func (e *QueryError) Unwrap() error {
+    return e.Err
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-handling.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-handling.md
new file mode 100644
index 00000000..a0ae3c5d
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-handling.md
@@ -0,0 +1,129 @@
+# Error Handling Patterns and Logging
+
+## The Single Handling Rule
+
+An error MUST be handled exactly once: either log it or return it, never both. Doing both causes duplicate log entries and makes debugging harder.
+
+```go
+// ✗ Bad — logs AND returns (duplicate noise)
+func processOrder(id string) error {
+    err := chargeCard(id)
+    if err != nil {
+        log.Printf("failed to charge card: %v", err)
+        return fmt.Errorf("charging card: %w", err)
+    }
+    return nil
+}
+
+// ✓ Good — return with context, let the caller decide
+func processOrder(id string) error {
+    err := chargeCard(id)
+    if err != nil {
+        return oops.
+            With("order_id", id).
+            Wrapf(err, "charging card")
+    }
+    return nil
+}
+
+// ✓ Good — handle at the top level (HTTP handler, main, etc.)
+func handleOrder(w http.ResponseWriter, r *http.Request) {
+    err := processOrder(r.FormValue("id"))
+    if err != nil {
+        slog.Error("order failed", "error", err)
+        http.Error(w, "internal error", http.StatusInternalServerError)
+        return
+    }
+    w.WriteHeader(http.StatusOK)
+}
+```
+
+## Panic and Recover
+
+### When to panic
+
+Panic MUST only be used for truly unrecoverable states — programmer errors, impossible conditions, or corrupt invariants. NEVER use panic for expected failures like network timeouts or missing files.
+
+```go
+// ✓ Acceptable — programmer error in initialization
+func MustCompileRegex(pattern string) *regexp.Regexp {
+    re, err := regexp.Compile(pattern)
+    if err != nil {
+        panic(fmt.Sprintf("invalid regex %q: %v", pattern, err))
+    }
+    return re
+}
+
+// ✗ Bad — panic for a normal failure
+func GetUser(id string) *User {
+    user, err := db.Find(id)
+    if err != nil {
+        panic(err) // callers cannot recover gracefully
+    }
+    return user
+}
+```
+
+### Recovering from panics
+
+Use `recover` in deferred functions at goroutine boundaries (HTTP handlers, worker goroutines) to prevent one panic from crashing the entire process.
+
+```go
+func safeHandler(next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        defer func() {
+            if r := recover(); r != nil {
+                slog.Error("panic recovered",
+                    "panic", r,
+                    "stack", string(debug.Stack()),
+                )
+                http.Error(w, "internal error", http.StatusInternalServerError)
+            }
+        }()
+        next.ServeHTTP(w, r)
+    })
+}
+```
+
+For structured panic recovery with `samber/oops`, see the `samber/cc-skills-golang@golang-samber-oops` skill.
+
+## Why Use `samber/oops`
+
+- **Stack traces** — you see `"connection refused"` but need to know where it originated
+- **Structured context** — user ID, tenant ID, or request metadata attached to the error
+- **Error codes** — machine-readable identifiers for monitoring dashboards
+- **Public/private separation** — safe message to show end users
+- ...
+
+`samber/oops` is a **drop-in replacement** that fills these gaps. Every `oops` error implements the standard `error` interface, works with `errors.Is`/`errors.As`, and adds structured attributes:
+
+```go
+// ✗ Before — standard errors, no context
+func (s *OrderService) CreateOrder(ctx context.Context, req CreateOrderReq) error {
+    err := s.db.Insert(ctx, req.Order)
+    if err != nil {
+        return fmt.Errorf("inserting order: %w", err)
+    }
+    return nil
+}
+
+// ✓ After — samber/oops, rich context for debugging
+func (s *OrderService) CreateOrder(ctx context.Context, req CreateOrderReq) error {
+    err := s.db.Insert(ctx, req.Order)
+    if err != nil {
+        return oops.
+            In("order-service").
+            Code("order_insert_failed").
+            User(req.UserID).
+            With("order_id", req.Order.ID).
+            Wrapf(err, "inserting order")
+    }
+    return nil
+}
+```
+
+When this error is logged, you get the stack trace, user ID, order ID, domain, error code, and the full error chain — all structured and machine-parseable.
+
+## Logging Errors with `slog`
+
+→ See `samber/cc-skills-golang@golang-observability` skill for comprehensive structured logging guidance, including `slog` setup, log levels, log handlers, HTTP middleware, and cost considerations.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-wrapping.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-wrapping.md
new file mode 100644
index 00000000..9fec86e4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-error-handling/references/error-wrapping.md
@@ -0,0 +1,112 @@
+# Error Wrapping and Inspection
+
+## Error Wrapping with `%w`
+
+Wrapping preserves the original error in a chain that callers can inspect with `errors.Is` and `errors.As`. Errors SHOULD be wrapped at each layer to build a readable chain.
+
+```go
+// ✓ Good — wraps with context, preserves the chain
+func (s *UserService) GetUser(id string) (*User, error) {
+    user, err := s.repo.FindByID(id)
+    if err != nil {
+        return nil, fmt.Errorf("getting user %s: %w", id, err)
+    }
+    return user, nil
+}
+```
+
+### `%w` vs `%v`: controlling exposure
+
+Use `%w` within your module to preserve the error chain. Use `%v` at public API / system boundaries to prevent callers from depending on internal error types.
+
+```go
+// Internal layer — wrap to preserve chain
+func (r *repo) fetch(id string) error {
+    return fmt.Errorf("querying database: %w", err)
+}
+
+// Public API boundary — break chain to hide internals
+func (s *PublicService) GetItem(id string) error {
+    err := s.repo.fetch(id)
+    if err != nil {
+        return fmt.Errorf("item unavailable: %v", err) // %v — callers cannot unwrap
+    }
+    return nil
+}
+```
+
+## Inspecting Errors: `errors.Is` and `errors.As`
+
+### `errors.Is` — match against a sentinel value
+
+```go
+// ✗ Bad — direct comparison breaks on wrapped errors
+if err == sql.ErrNoRows {
+
+// ✓ Good — traverses the entire error chain
+if errors.Is(err, sql.ErrNoRows) {
+    return nil, ErrNotFound
+}
+```
+
+### `errors.As / errors.AsType` — extract a typed error from the chain
+
+```go
+// ✗ Bad — type assertion breaks on wrapped errors
+if ve, ok := err.(*ValidationError); ok {
+
+// ✓ Good — traverses the entire error chain
+var ve *ValidationError
+if errors.As(err, &ve) {
+    log.Printf("validation failed on field %s: %s", ve.Field, ve.Msg)
+}
+
+// ✓ Better (Go 1.26+) — same behavior, simpler syntax
+if ve, ok := errors.AsType[*ValidationError](err); ok {
+    log.Printf("validation failed on field %s: %s", ve.Field, ve.Msg)
+}
+```
+
+## Combining Errors with `errors.Join`
+
+`errors.Join` (Go 1.20+) combines multiple independent errors into one. The combined error works with `errors.Is` and `errors.As` — each inner error is inspectable.
+
+### Use case: validating multiple fields
+
+```go
+func validateUser(u User) error {
+    var errs []error
+
+    if u.Name == "" {
+        errs = append(errs, errors.New("name is required"))
+    }
+    if u.Email == "" {
+        errs = append(errs, errors.New("email is required"))
+    }
+
+    return errors.Join(errs...) // returns nil if errs is empty
+}
+```
+
+### Use case: parallel operations with independent failures
+
+```go
+func closeAll(closers ...io.Closer) error {
+    var errs []error
+    for _, c := range closers {
+        if err := c.Close(); err != nil {
+            errs = append(errs, err)
+        }
+    }
+    return errors.Join(errs...)
+}
+```
+
+### `errors.Is` works through joined errors
+
+```go
+err := errors.Join(ErrNotFound, ErrUnauthorized)
+
+errors.Is(err, ErrNotFound)    // true
+errors.Is(err, ErrUnauthorized) // true
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/SKILL.md
new file mode 100644
index 00000000..e96efc38
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/SKILL.md
@@ -0,0 +1,229 @@
+---
+name: golang-google-wire
+description: "Compile-time dependency injection in Golang using google/wire — wire.NewSet, wire.Build, wire.Bind (interface→concrete), wire.Struct, wire.Value, wire.InterfaceValue, wire.FieldsOf, cleanup functions, //go:build wireinject injector files, and generated wire_gen.go. Apply when using or adopting google/wire, when the codebase imports `github.com/google/wire`, or when wiring an application graph at compile time via `wire.Build`. For runtime DI with reflection, see `samber/cc-skills-golang@golang-uber-dig` skill."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.0.3"
+  openclaw:
+    emoji: "🪡"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - wire
+    install:
+      - kind: go
+        package: github.com/google/wire/cmd/wire@latest
+        bins: [wire]
+    skill-library-version: "0.7.0"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs Bash(wire:*)
+---
+
+**Persona:** You are a Go architect using wire for compile-time DI. You let the compiler catch missing dependencies, treat `wire_gen.go` as committed source, and re-run `wire ./...` after every graph change.
+
+**Dependencies:**
+
+- wire: `go install github.com/google/wire/cmd/wire@latest`
+
+# Using google/wire for Compile-Time Dependency Injection in Go
+
+Code-generation DI toolkit. Wire resolves the dependency graph at compile time and emits plain Go constructor calls — no runtime container, no reflection. Errors appear when you run `wire ./...`, not at first request.
+
+Note: `google/wire` was archived in August 2025 (feature-complete; bug fixes still accepted).
+
+**Official Resources:** [pkg.go.dev](https://pkg.go.dev/github.com/google/wire) · [github.com/google/wire](https://github.com/google/wire) · [User Guide](https://github.com/google/wire/blob/main/docs/guide.md) · [Best Practices](https://github.com/google/wire/blob/main/docs/best-practices.md)
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+```bash
+go get -tool github.com/google/wire/cmd/wire@latest
+go get github.com/google/wire
+```
+
+## wire vs. Runtime DI
+
+| Concern           | wire                      | dig / fx / samber/do   |
+| ----------------- | ------------------------- | ---------------------- |
+| Resolution        | Compile time (codegen)    | Runtime (reflection)   |
+| Error detection   | `wire ./...` fails        | First `Invoke`/startup |
+| Runtime container | None — plain Go calls     | Present                |
+| Lifecycle hooks   | Not built in              | fx: OnStart/OnStop     |
+| Generated files   | `wire_gen.go` (committed) | None                   |
+
+For lifecycle, lazy loading, and a full matrix see `samber/cc-skills-golang@golang-dependency-injection`.
+
+## Providers
+
+A provider is any Go function — inputs are dependencies, outputs are provided types. Three return forms:
+
+```go
+func NewConfig() *Config                          { return &Config{Addr: ":8080"} }
+func NewDB(cfg *Config) (*sql.DB, error)          { return sql.Open("postgres", cfg.DSN) }
+func NewRedis(cfg *Config) (*redis.Client, func(), error) { // cleanup chained in reverse order
+    c := redis.NewClient(&redis.Options{Addr: cfg.RedisAddr})
+    return c, func() { c.Close() }, nil
+}
+```
+
+## Provider Sets
+
+`wire.NewSet` groups providers for reuse. Sets can reference other sets.
+
+```go
+// infra/wire.go
+var InfraSet = wire.NewSet(
+    NewConfig,
+    NewDB,
+    NewRedis,
+)
+
+// service/wire.go
+var ServiceSet = wire.NewSet(
+    NewUserRepo,
+    NewUserService,
+    wire.Bind(new(UserStore), new(*UserRepo)), // interface binding
+)
+```
+
+Keep sets small: library sets expose a stable surface (adding inputs or removing outputs breaks downstream injectors). One set per package is a useful default.
+
+## Injectors and `//go:build wireinject`
+
+The injector file declares the initialization function. Wire generates its body into `wire_gen.go` and replaces the stub.
+
+```go
+//go:build wireinject
+
+package main
+
+import "github.com/google/wire"
+
+// Wire generates the body of this function.
+func InitApp() (*App, func(), error) {
+    wire.Build(InfraSet, ServiceSet, NewApp)
+    return nil, nil, nil // replaced by codegen
+}
+```
+
+The `//go:build wireinject` tag prevents the stub from being compiled into the binary — only `wire_gen.go` (which has no such tag) makes it through `go build`. Without this tag, both files define the same function, causing a compile error.
+
+Alternative syntax when a dummy return is inconvenient:
+
+```go
+func InitApp() (*App, func(), error) {
+    panic(wire.Build(InfraSet, ServiceSet, NewApp))
+}
+```
+
+## Interface Bindings
+
+Wire forbids implicit interface satisfaction — you must declare bindings explicitly so the graph is unambiguous when multiple types implement the same interface.
+
+```go
+var Set = wire.NewSet(
+    NewPostgresUserRepo,
+    wire.Bind(new(UserStore), new(*PostgresUserRepo)), // tell wire: *PostgresUserRepo satisfies UserStore
+)
+```
+
+Explicit bindings prevent graph breakage when a new type implementing the same interface is added elsewhere.
+
+## Struct Providers and Values
+
+`wire.Struct` fills struct fields from the graph without a manual constructor. Tag fields `wire:"-"` to exclude them.
+
+```go
+wire.Struct(new(Server), "Logger", "DB") // inject named fields
+wire.Struct(new(Server), "*")            // inject all non-excluded fields
+wire.Value(Foo{X: 42})                   // constant expression (no fn calls / channels)
+wire.InterfaceValue(new(io.Reader), os.Stdin) // interface-typed literal
+wire.FieldsOf(new(Config), "DSN", "Addr")    // promote struct fields as graph nodes
+```
+
+See [advanced.md](references/advanced.md) for the `wire:"-"` exclusion tag and `wire.FieldsOf` details.
+
+## Disambiguating Duplicate Types
+
+Wire forbids two providers for the same type. Wrap the underlying type in distinct named types so each has exactly one provider:
+
+```go
+type PrimaryDSN string
+type ReplicaDSN string
+```
+
+## Full Application Example
+
+```go
+// wire.go — injector, excluded from binary via build tag
+//go:build wireinject
+
+package main
+
+func InitApp() (*App, func(), error) {
+    wire.Build(config.ConfigSet, infra.InfraSet, service.ServiceSet, NewApp)
+    return nil, nil, nil
+}
+
+// main.go
+func main() {
+    app, cleanup, err := InitApp()
+    if err != nil { log.Fatal(err) }
+    defer cleanup()
+    app.Run()
+}
+```
+
+Wire generates `wire_gen.go` (plain Go, committed, DO NOT EDIT). For a full example with per-package sets, cleanup-heavy graphs, and generated output, see [recipes.md](references/recipes.md).
+
+## Codegen Workflow
+
+```bash
+wire ./...           # regenerate all injectors in the module
+wire check ./...     # validate graph without regenerating (fast CI check)
+```
+
+Run `wire ./...` after every constructor signature change. Add `//go:generate go run github.com/google/wire/cmd/wire` to injector files so `go generate ./...` also works. Commit `wire_gen.go` — it must stay in sync for CI builds.
+
+## Best Practices
+
+1. Never edit `wire_gen.go` — it is overwritten on every `wire ./...` run. Treat it as a build artifact that happens to be committed; source of truth is the provider and injector files.
+2. Always add `//go:build wireinject` to injector files — omitting it causes duplicate-symbol compile errors because both the stub and the generated file define the same function.
+3. Use named types to distinguish values of the same underlying type — wire enforces one provider per type; named types like `type DSN string` let you have `PrimaryDSN` and `ReplicaDSN` coexist.
+4. Keep library provider sets minimal and backward-compatible — adding new required inputs breaks downstream injectors; removing outputs does too. Introduce only newly-created types in the same release.
+5. Return `(T, func(), error)` from cleanup providers and let wire chain them — wire generates the correct reverse-order cleanup and handles partial failures (if construction fails midway, only already-built cleanups run).
+6. Keep injector files focused — one function per file, one package import at a time. Fat injectors with dozens of `wire.Build` arguments are hard to reason about; delegate to per-package sets.
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Editing `wire_gen.go` manually | Never edit it. Change providers or injectors and re-run `wire ./...`. |
+| Missing `//go:build wireinject` | Add the tag as the very first line of every injector file. |
+| Two providers returning `*sql.DB` | Wrap with a named struct type: `type PrimaryDB struct { *sql.DB }` — Wire does not distinguish pointer type aliases. |
+| Injecting an interface without `wire.Bind` | Add `wire.Bind(new(MyInterface), new(*MyImpl))` to the provider set. |
+| Forgetting to re-run `wire ./...` after changes | Run wire before `go build`; add it to `go generate` or a Makefile target. |
+| Calling `cleanup()` without guarding for nil | Wire returns nil cleanup on construction error; guard with `if cleanup != nil { defer cleanup() }`. |
+
+## Testing
+
+Wire generates plain Go constructors, so unit tests use manual injection — no container to clone or reset. For testing patterns (test injectors swapping real providers for fakes, CI stale-check for `wire_gen.go`), see [testing.md](references/testing.md).
+
+## Further Reading
+
+- [advanced.md](references/advanced.md) — cleanup chains, multiple injectors, set nesting, error catalogue, codegen flags, quick reference
+- [recipes.md](references/recipes.md) — HTTP server, multi-injector build, cleanup-heavy graph, CLI embedding
+- [testing.md](references/testing.md) — test injectors, fake bindings, CI stale check
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-dependency-injection` skill for DI concepts and library comparison
+- → See `samber/cc-skills-golang@golang-uber-dig` skill for runtime reflection-based DI without lifecycle
+- → See `samber/cc-skills-golang@golang-uber-fx` skill for runtime DI with lifecycle hooks, modules, and signal-aware Run()
+- → See `samber/cc-skills-golang@golang-samber-do` skill for generics-based DI without reflection
+- → See `samber/cc-skills-golang@golang-structs-interfaces` skill for interface design patterns
+- → See `samber/cc-skills-golang@golang-testing` skill for general testing patterns
+
+If you encounter a bug or unexpected behavior in google/wire, open an issue at <https://github.com/google/wire/issues>.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/evals/evals.json
new file mode 100644
index 00000000..969aa55b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/evals/evals.json
@@ -0,0 +1,142 @@
+[
+  {
+    "id": 1,
+    "name": "build-constraint-on-injector",
+    "description": "Tests that the model adds //go:build wireinject to injector files to prevent duplicate-symbol compile errors",
+    "prompt": "I'm setting up google/wire in my Go project. Here's my injector file:\n\n```go\npackage main\n\nimport \"github.com/google/wire\"\n\nfunc InitApp() (*App, error) {\n    wire.Build(InfraSet, ServiceSet, NewApp)\n    return nil, nil\n}\n```\n\nWire generates wire_gen.go successfully, but when I run `go build`, I get a 'redeclared in this block' compile error for InitApp. What's wrong and how do I fix it?",
+    "trap": "Without the skill, the model may suggest renaming the function, reorganizing packages, or not identify that the missing //go:build wireinject tag is the cause — both the stub and wire_gen.go define InitApp, causing the duplicate.",
+    "assertions": [
+      {"id": "1.1", "text": "Identifies the missing //go:build wireinject build tag as the root cause"},
+      {"id": "1.2", "text": "Shows //go:build wireinject as the first line of the injector file"},
+      {"id": "1.3", "text": "Explains that the tag prevents the stub from being compiled into the binary (only wire_gen.go compiles)"},
+      {"id": "1.4", "text": "Does NOT suggest renaming the function or reorganizing packages as the fix"},
+      {"id": "1.5", "text": "Does NOT suggest deleting wire_gen.go as the fix"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "interface-binding-required",
+    "description": "Tests that wire.Bind is required for interface-to-concrete mappings and cannot be inferred",
+    "prompt": "I have this Go code using google/wire:\n\n```go\n// repo.go\ntype UserStore interface {\n    GetUser(id int64) (*User, error)\n}\n\ntype PostgresUserRepo struct{ db *sql.DB }\nfunc (r *PostgresUserRepo) GetUser(id int64) (*User, error) { ... }\nfunc NewUserRepo(db *sql.DB) *PostgresUserRepo { return &PostgresUserRepo{db: db} }\n\n// service.go\nfunc NewUserService(store UserStore) *UserService { return &UserService{store: store} }\n\n// wire_providers.go\nvar AppSet = wire.NewSet(NewDB, NewUserRepo, NewUserService)\n```\n\nWhen I run `wire ./...` I get: `no provider found for UserStore`. NewUserRepo returns *PostgresUserRepo which clearly implements UserStore. Why doesn't wire figure this out?",
+    "trap": "Without the skill, the model might suggest wire should automatically resolve the interface, or suggest wrapping NewUserRepo to return UserStore directly, missing the explicit wire.Bind requirement.",
+    "assertions": [
+      {"id": "2.1", "text": "Explains that wire never auto-resolves interface satisfaction — bindings must be explicit"},
+      {"id": "2.2", "text": "Shows wire.Bind(new(UserStore), new(*PostgresUserRepo)) added to the provider set"},
+      {"id": "2.3", "text": "Places wire.Bind inside the same wire.NewSet (or adds it to a set in wire.Build)"},
+      {"id": "2.4", "text": "Explains WHY wire requires explicit bindings (predictability — avoids surprise rebinding when new implementations are added)"},
+      {"id": "2.5", "text": "Does NOT suggest changing NewUserRepo to return UserStore directly as the primary fix"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "duplicate-type-named-wrapper",
+    "description": "Tests the named-type pattern to disambiguate multiple values of the same underlying type",
+    "prompt": "I'm building a Go service with google/wire. I need to inject two database connection strings — one for the primary database and one for a read replica. I tried this:\n\n```go\nfunc NewPrimaryDSN() string { return os.Getenv(\"PRIMARY_DSN\") }\nfunc NewReplicaDSN() string { return os.Getenv(\"REPLICA_DSN\") }\n\nvar DBSet = wire.NewSet(NewPrimaryDSN, NewReplicaDSN, NewPrimaryDB, NewReplicaDB)\n```\n\nWire complains about multiple bindings for string. How should I structure this?",
+    "trap": "Without the skill, the model might suggest using wire.Value or provider arguments, or use a config struct — missing the idiomatic named-type wrapper pattern that wire's own docs recommend.",
+    "assertions": [
+      {"id": "3.1", "text": "Introduces distinct named types (e.g., type PrimaryDSN string and type ReplicaDSN string)"},
+      {"id": "3.2", "text": "Updates NewPrimaryDSN to return PrimaryDSN and NewReplicaDSN to return ReplicaDSN"},
+      {"id": "3.3", "text": "Updates NewPrimaryDB and NewReplicaDB signatures to accept the named types"},
+      {"id": "3.4", "text": "Explains that wire enforces one provider per type, so distinct named types are the correct solution"},
+      {"id": "3.5", "text": "Does NOT suggest using a single Config struct with both DSNs as the primary fix (that avoids the problem rather than solving it with named types)"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "cleanup-signature",
+    "description": "Tests the (T, func(), error) cleanup provider pattern instead of manual defer in main",
+    "prompt": "I'm using google/wire to wire my Go service. I need my *sql.DB connection pool to be closed when the app shuts down. Currently I'm doing this in main:\n\n```go\nfunc main() {\n    app, err := InitApp()\n    if err != nil { log.Fatal(err) }\n    defer db.Close() // but I don't have access to db here!\n    app.Run()\n}\n```\n\nI realize I need the DB closed on shutdown, but InitApp() only returns *App. How should I wire cleanup with google/wire?",
+    "trap": "Without the skill, the model might suggest passing db out of InitApp as a second return value, or storing it as a global, missing the (T, func(), error) cleanup provider pattern.",
+    "assertions": [
+      {"id": "4.1", "text": "Changes NewDB to return (*sql.DB, func(), error) where the cleanup function calls db.Close()"},
+      {"id": "4.2", "text": "Changes the injector function to return (*App, func(), error) to propagate the cleanup chain"},
+      {"id": "4.3", "text": "Shows main calling defer cleanup() after the nil-check"},
+      {"id": "4.4", "text": "Explains that wire chains cleanup functions and calls them in reverse construction order"},
+      {"id": "4.5", "text": "Does NOT suggest passing db as an extra return value from InitApp alongside *App"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "no-edit-wire-gen",
+    "description": "Tests that the model never edits wire_gen.go and instructs re-running wire ./... instead",
+    "prompt": "I added a new *Logger parameter to my NewServer constructor in my google/wire project:\n\n```go\nfunc NewServer(db *sql.DB, log *zap.Logger) *Server { ... }\n```\n\nNow `go build` fails with 'too few arguments in call to NewServer'. The error is inside wire_gen.go on line 47. Should I edit wire_gen.go to add the logger argument there, or is there another way?",
+    "trap": "Without the skill, a model may suggest editing wire_gen.go directly to 'fix' the build error quickly, which would be overwritten on the next wire run.",
+    "assertions": [
+      {"id": "5.1", "text": "Explicitly says NOT to edit wire_gen.go (it is always overwritten)"},
+      {"id": "5.2", "text": "Instructs running wire ./... to regenerate wire_gen.go"},
+      {"id": "5.3", "text": "Explains that *zap.Logger must be provided in the graph (either via a provider or wire.Value)"},
+      {"id": "5.4", "text": "Shows how to add NewLogger (or wire.Value) to the appropriate wire.NewSet so the dependency is satisfied"},
+      {"id": "5.5", "text": "Does NOT present editing wire_gen.go as an option"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "provider-set-organization",
+    "description": "Tests per-package provider set organization instead of one giant set in main",
+    "prompt": "My Go service using google/wire is growing. I currently have everything in one place:\n\n```go\n// wire.go\n//go:build wireinject\n\nfunc InitApp() (*App, func(), error) {\n    wire.Build(\n        NewConfig, NewDB, NewCache, NewLogger,\n        NewUserRepo, NewOrderRepo, NewProductRepo,\n        wire.Bind(new(UserStore), new(*PostgresUserRepo)),\n        wire.Bind(new(OrderStore), new(*PostgresOrderRepo)),\n        wire.Bind(new(ProductStore), new(*PostgresProductRepo)),\n        NewUserService, NewOrderService, NewProductService,\n        NewHTTPServer, NewRouter,\n        NewApp,\n    )\n    return nil, nil, nil\n}\n```\n\nThis is getting unwieldy. How should I organize this with google/wire?",
+    "trap": "Without the skill, the model may just split the providers into helper variables in the same package, missing the idiomatic per-package wire.NewSet pattern.",
+    "assertions": [
+      {"id": "6.1", "text": "Introduces per-package wire.NewSet variables (e.g., InfraSet, RepoSet, ServiceSet, TransportSet)"},
+      {"id": "6.2", "text": "Each set lives in its own package's wire.go file (not all in main)"},
+      {"id": "6.3", "text": "The injector wire.Build references the set variables rather than individual providers"},
+      {"id": "6.4", "text": "wire.Bind declarations move into the relevant package's set (not into wire.Build directly)"},
+      {"id": "6.5", "text": "Explains the benefit: per-package sets are independently composable and keep the injector readable"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "injector-parameter-vs-value-provider",
+    "description": "Tests using wire.Value or injector parameters for pre-built values instead of wrapper constructors",
+    "prompt": "In my Go app using google/wire, I parse a *Config struct from command-line flags in main() before calling InitApp. I tried writing a no-op provider:\n\n```go\nvar parsedCfg *Config\n\nfunc ProvideConfig() *Config { return parsedCfg }\n\nvar AppSet = wire.NewSet(ProvideConfig, ...)\n```\n\nThis works but feels wrong — I'm using a global variable. Is there a cleaner way to pass a pre-built *Config into the wire graph?",
+    "trap": "Without the skill, the model might suggest keeping the global variable pattern or using init(), missing both wire.Value and the injector-parameter patterns.",
+    "assertions": [
+      {"id": "7.1", "text": "Shows the injector-parameter approach: func InitApp(cfg *Config) (*App, func(), error) with wire.Build"},
+      {"id": "7.2", "text": "OR shows wire.Value(cfg) inside wire.Build — both are valid answers"},
+      {"id": "7.3", "text": "Explains that injector parameters are treated as pre-built providers by wire"},
+      {"id": "7.4", "text": "Does NOT use a global variable as the recommended solution"},
+      {"id": "7.5", "text": "Does NOT suggest using init() to set the value"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "fields-of-struct",
+    "description": "Tests wire.FieldsOf to expose struct fields as individual graph nodes",
+    "prompt": "I have a single Config struct in my Go app with google/wire:\n\n```go\ntype Config struct {\n    DatabaseDSN  string\n    CacheAddress string\n    APIKey       string\n}\n\nfunc NewConfig() *Config { return loadFromEnv() }\n```\n\nNewDB needs a DatabaseDSN string, NewCache needs a CacheAddress string, NewExternalClient needs an APIKey string — but all three are plain strings. How do I make these available to the wire graph without creating three separate provider functions?",
+    "trap": "Without the skill, the model will suggest three named-type wrappers or three extraction functions, missing wire.FieldsOf which promotes struct fields directly.",
+    "assertions": [
+      {"id": "8.1", "text": "Uses wire.FieldsOf(new(Config), \"DatabaseDSN\", \"CacheAddress\", \"APIKey\") or a subset"},
+      {"id": "8.2", "text": "Places wire.FieldsOf inside the provider set or wire.Build"},
+      {"id": "8.3", "text": "Updates NewDB, NewCache, NewExternalClient to accept the string fields as parameters (or uses named types alongside FieldsOf)"},
+      {"id": "8.4", "text": "Explains that wire.FieldsOf promotes struct fields as individual graph nodes without manual extraction functions"},
+      {"id": "8.5", "text": "Does NOT suggest writing three separate func GetDatabaseDSN(c *Config) string extractor functions as the primary recommendation"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "test-injector-pattern",
+    "description": "Tests the test-injector pattern with wire.Bind for fake dependencies instead of runtime mocking hacks",
+    "prompt": "My Go service is wired with google/wire. I have a Mailer interface implemented by SMTPMailer in production. I want integration tests that use a FakeMailer instead — recording sent emails — without modifying the production provider sets. The test must wire the full graph (not just NewUserService in isolation). How should I approach this?",
+    "trap": "Without the skill, the model may suggest monkey-patching, a global variable for the mailer, or a runtime DI container for tests — missing the test-injector pattern with a test-only wire.NewSet and wire.Bind.",
+    "assertions": [
+      {"id": "9.1", "text": "Creates a test-only provider set (e.g., TestMailerSet) with NewFakeMailer and wire.Bind(new(Mailer), new(*FakeMailer))"},
+      {"id": "9.2", "text": "Creates a test injector function in a _test.go file with //go:build wireinject"},
+      {"id": "9.3", "text": "The test injector's wire.Build composes the production sets with the test-only set"},
+      {"id": "9.4", "text": "Does NOT suggest global variables, monkey-patching, or a runtime DI container for tests"},
+      {"id": "9.5", "text": "Mentions that wire ./... (or go generate) must be run to produce the test-injector generated code"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "wire-vs-fx-for-daemon",
+    "description": "Tests that the model recommends uber-go/fx over wire for long-running services that need lifecycle management",
+    "prompt": "I'm starting a new Go HTTP server project and evaluating DI options. A colleague suggested google/wire because 'it's simpler and type-safe at compile time.' The server needs graceful shutdown (drain in-flight requests), OnStart/OnStop hooks for the database pool and metrics exporter, and should handle SIGINT/SIGTERM. Should I use wire?",
+    "trap": "Without the skill, the model may agree that wire is suitable because it's simple and compile-time safe, not recognizing that lifecycle, signal handling, and hook ordering are exactly what fx provides and wire explicitly lacks.",
+    "assertions": [
+      {"id": "10.1", "text": "Identifies that wire has no built-in lifecycle management (no OnStart/OnStop hooks)"},
+      {"id": "10.2", "text": "Identifies that wire has no built-in signal handling (SIGINT/SIGTERM)"},
+      {"id": "10.3", "text": "Recommends uber-go/fx (or at minimum flags it as the better fit) for a long-running HTTP daemon with lifecycle needs"},
+      {"id": "10.4", "text": "Does NOT recommend wire as sufficient for a service requiring graceful shutdown and lifecycle hooks"},
+      {"id": "10.5", "text": "Mentions that with wire the developer must implement shutdown and signal handling manually"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/advanced.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/advanced.md
new file mode 100644
index 00000000..b5f2b3c2
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/advanced.md
@@ -0,0 +1,198 @@
+# Advanced — google/wire
+
+Detail topics referenced from `SKILL.md`. Each section is self-contained.
+
+## Cleanup Chains
+
+When a provider returns `(T, func(), error)`, Wire adds the cleanup to a chain. The generated injector runs cleanups in **reverse construction order**: the last-built dependant is cleaned up first, ensuring dependants are torn down before their dependencies.
+
+```go
+// Provider with cleanup
+func NewDB(cfg *Config) (*sql.DB, func(), error) {
+    db, err := sql.Open("postgres", string(cfg.DSN))
+    if err != nil { return nil, nil, err }
+    return db, func() { db.Close() }, nil
+}
+
+func NewCache(cfg *Config) (*redis.Client, func(), error) {
+    c := redis.NewClient(&redis.Options{Addr: cfg.CacheAddr})
+    return c, func() { c.Close() }, nil
+}
+```
+
+Wire generates something like:
+
+```go
+func InitApp() (*App, func(), error) {
+    cfg := NewConfig()
+    db, dbCleanup, err := NewDB(cfg)
+    if err != nil { return nil, nil, err }
+    cache, cacheCleanup, err := NewCache(cfg)
+    if err != nil {
+        dbCleanup()  // already-built cleanups run on partial failure
+        return nil, nil, err
+    }
+    app := NewApp(db, cache)
+    return app, func() {
+        cacheCleanup()  // reverse order
+        dbCleanup()
+    }, nil
+}
+```
+
+**Caller pattern** — guard against nil cleanup on construction failure:
+
+```go
+app, cleanup, err := InitApp()
+if err != nil { log.Fatal(err) }
+defer cleanup()
+```
+
+Wire always returns a non-nil cleanup function when construction succeeds. If construction fails midway, the returned `cleanup` is nil — guard before calling.
+
+## Multiple Injectors in One Package
+
+A package can contain multiple injector functions. Each must live in a file with `//go:build wireinject`. All generated functions land in `wire_gen.go` in the same package.
+
+```go
+//go:build wireinject
+
+package main
+
+// Production injector
+func InitProdApp() (*App, func(), error) {
+    wire.Build(ProdSet, NewApp)
+    return nil, nil, nil
+}
+
+// Development injector with debug providers
+func InitDevApp() (*App, func(), error) {
+    wire.Build(DevSet, NewApp)
+    return nil, nil, nil
+}
+```
+
+Select at runtime with a flag, or at build time with separate `//go:build prod` / `//go:build !prod` constraints on the injector files.
+
+## wire.NewSet Nesting Strategies
+
+Sets can contain other sets, building a hierarchy that mirrors your package structure.
+
+```go
+// pkg/config/wire.go
+var ConfigSet = wire.NewSet(NewConfig)
+
+// pkg/infra/wire.go
+var InfraSet = wire.NewSet(
+    config.ConfigSet, // embed upstream set
+    NewDB,
+    NewCache,
+)
+
+// pkg/service/wire.go
+var ServiceSet = wire.NewSet(
+    NewUserService,
+    wire.Bind(new(UserStore), new(*UserRepo)),
+)
+
+// wire.go (injector)
+wire.Build(infra.InfraSet, service.ServiceSet, NewApp)
+```
+
+**Library set stability rules** (from upstream best practices):
+
+- Safe: replace one provider with another that has the same or fewer inputs, in the same release.
+- Safe: introduce a brand-new output type not previously provided.
+- Breaking: add a new required input to a provider — downstream injectors cannot satisfy it.
+- Breaking: remove a provided output type — downstream injectors that depend on it fail.
+- Breaking: add a type that the injector already provides — Wire reports a duplicate.
+
+## `wire:"-"` Exclusion Tag
+
+Exclude a struct field from `wire.Struct` injection by tagging it:
+
+```go
+type Server struct {
+    Logger  *zap.Logger
+    DB      *sql.DB
+    mu      sync.Mutex   `wire:"-"` // unexported — auto-excluded
+    Timeout time.Duration `wire:"-"` // exported but opt-out
+}
+
+wire.Struct(new(Server), "*") // injects Logger and DB; skips mu and Timeout
+```
+
+Unexported fields are always skipped regardless of the tag.
+
+## Common Codegen Errors
+
+| Error message | Root cause | Fix |
+| --- | --- | --- |
+| `no provider found for TYPE` | A dependency is not provided by any set in `wire.Build` | Add the missing provider or set |
+| `multiple bindings for TYPE` | Two providers return the same type | Use named types or remove the duplicate |
+| `argument N has no provider for TYPE` | An interface is requested but no `wire.Bind` maps to it | Add `wire.Bind(new(Iface), new(*Impl))` to a set |
+| `cycle detected` | A → B → A circular dependency | Break the cycle by introducing an interface or factory |
+| `wire.Build used outside of injector function` | `wire.Build` called from a non-injector function | Only call `wire.Build` inside functions with the build tag |
+| duplicate symbol / redeclared in this block | Injector file is missing `//go:build wireinject` | Add the build tag as the first line |
+
+## Codegen Flags
+
+```bash
+# Specify output file prefix (default: wire_gen)
+wire -output_file_prefix=init gen ./cmd/server
+
+# Apply build tags during generation
+wire -tags=integration gen ./...
+
+# Prepend a header file (e.g., license comment) to generated output
+wire -header_file=hack/boilerplate.go.txt gen ./...
+```
+
+## `panic(wire.Build(...))` Alternate Syntax
+
+Wire accepts either a dummy return or a `panic` call as the injector body. The `panic` form avoids writing zero-value returns for complex types:
+
+```go
+// Preferred when return types are complex or error-prone to zero-initialize
+func InitApp(ctx context.Context) (*App, func(), error) {
+    panic(wire.Build(AppSet))
+}
+```
+
+Wire detects both forms and replaces the body during codegen. The `panic` is never reached in the compiled binary — only the generated `wire_gen.go` version is compiled.
+
+## Accepting External Values as Injector Arguments
+
+When a value is constructed before wire runs (e.g., parsed flags, an `http.Client` from a test), pass it as a parameter to the injector rather than providing it from within the graph:
+
+```go
+//go:build wireinject
+
+func InitApp(cfg *Config) (*App, func(), error) {
+    wire.Build(InfraSet, ServiceSet, NewApp)
+    return nil, nil, nil
+}
+
+// main.go
+cfg := parseFlags()
+app, cleanup, err := InitApp(cfg)
+```
+
+Wire treats injector parameters as pre-built providers — they satisfy dependencies without needing a `wire.NewSet` entry.
+
+## Quick Reference
+
+| Symbol | Purpose |
+| --- | --- |
+| `wire.NewSet(providers...)` | Group providers into a reusable set |
+| `wire.Build(sets...)` | Declare injector body (codegen replaces it) |
+| `wire.Bind(new(Iface), new(*Concrete))` | Bind interface to concrete type |
+| `wire.Struct(new(T), "Field", ...)` | Inject struct fields from the graph |
+| `wire.Struct(new(T), "*")` | Inject all non-excluded fields |
+| `wire.Value(expr)` | Bind a constant expression (no fn calls/channels) |
+| `wire.InterfaceValue(new(I), value)` | Bind a value to an interface type |
+| `wire.FieldsOf(new(T), "Field", ...)` | Promote struct fields as individual graph nodes |
+| `//go:build wireinject` | Build tag: exclude injector stub from binary |
+| `wire_gen.go` | Generated output — commit, never edit |
+| `wire ./...` | Regenerate all injectors in the module |
+| `wire check ./...` | Validate graph without regenerating |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/recipes.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/recipes.md
new file mode 100644
index 00000000..38860d5c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/recipes.md
@@ -0,0 +1,264 @@
+# Recipes — google/wire
+
+End-to-end examples. Each recipe is self-contained.
+
+## HTTP Server with Postgres and Redis
+
+A typical service: parsed config → DB (with cleanup) → Redis (with cleanup) → repo → service → HTTP server.
+
+```
+myapp/
+├── config/
+│   ├── config.go
+│   └── wire.go
+├── infra/
+│   ├── db.go
+│   ├── cache.go
+│   └── wire.go
+├── repo/
+│   ├── user.go
+│   └── wire.go
+├── service/
+│   ├── user.go
+│   └── wire.go
+├── transport/
+│   ├── handler.go
+│   └── wire.go
+├── wire.go        // injector — //go:build wireinject
+├── wire_gen.go    // generated — commit this
+└── main.go
+```
+
+```go
+// config/config.go
+type Config struct {
+    Addr      string
+    DSN       string
+    CacheAddr string
+}
+
+func NewConfig() *Config {
+    return &Config{
+        Addr:      env("ADDR", ":8080"),
+        DSN:       mustEnv("DATABASE_URL"),
+        CacheAddr: env("REDIS_ADDR", "localhost:6379"),
+    }
+}
+
+// config/wire.go
+var ConfigSet = wire.NewSet(NewConfig)
+```
+
+```go
+// infra/db.go
+func NewDB(cfg *config.Config) (*sql.DB, func(), error) {
+    db, err := sql.Open("postgres", cfg.DSN)
+    if err != nil { return nil, nil, err }
+    if err := db.Ping(); err != nil { db.Close(); return nil, nil, err }
+    return db, func() { db.Close() }, nil
+}
+
+// infra/cache.go
+func NewRedis(cfg *config.Config) (*redis.Client, func(), error) {
+    c := redis.NewClient(&redis.Options{Addr: cfg.CacheAddr})
+    if err := c.Ping(context.Background()).Err(); err != nil {
+        return nil, nil, err
+    }
+    return c, func() { c.Close() }, nil
+}
+
+// infra/wire.go
+var InfraSet = wire.NewSet(NewDB, NewRedis)
+```
+
+```go
+// repo/user.go
+type UserStore interface {
+    GetUser(ctx context.Context, id int64) (*User, error)
+}
+
+type PostgresUserRepo struct{ db *sql.DB }
+
+func NewUserRepo(db *sql.DB) *PostgresUserRepo { return &PostgresUserRepo{db: db} }
+
+// repo/wire.go
+var RepoSet = wire.NewSet(
+    NewUserRepo,
+    wire.Bind(new(UserStore), new(*PostgresUserRepo)),
+)
+```
+
+```go
+// service/user.go
+type UserService struct {
+    store  repo.UserStore
+    cache  *redis.Client
+}
+
+func NewUserService(store repo.UserStore, cache *redis.Client) *UserService {
+    return &UserService{store: store, cache: cache}
+}
+
+// service/wire.go
+var ServiceSet = wire.NewSet(NewUserService)
+```
+
+```go
+// wire.go
+//go:build wireinject
+
+package main
+
+func InitApp() (*transport.Handler, func(), error) {
+    wire.Build(
+        config.ConfigSet,
+        infra.InfraSet,
+        repo.RepoSet,
+        service.ServiceSet,
+        transport.NewHandler,
+    )
+    return nil, nil, nil
+}
+```
+
+```go
+// main.go
+func main() {
+    handler, cleanup, err := InitApp()
+    if err != nil { log.Fatal(err) }
+    defer cleanup()
+
+    srv := &http.Server{Addr: ":8080", Handler: handler}
+    log.Fatal(srv.ListenAndServe())
+}
+```
+
+## Multiple Build Variants (Prod vs Dev)
+
+Use separate injector files with `//go:build` constraints to select different provider sets at build time.
+
+```go
+// wire_prod.go
+//go:build wireinject && !dev
+
+package main
+
+func InitApp() (*App, func(), error) {
+    wire.Build(ProdSet, NewApp)
+    return nil, nil, nil
+}
+
+// wire_dev.go
+//go:build wireinject && dev
+
+package main
+
+func InitApp() (*App, func(), error) {
+    wire.Build(DevSet, NewApp) // DevSet swaps real DB for in-memory SQLite
+    return nil, nil, nil
+}
+```
+
+Use `-output_file_prefix` to write separate output files — both commands would otherwise overwrite the same `wire_gen.go`:
+
+```bash
+wire -tags dev -output_file_prefix=wire_gen_dev gen .
+wire -output_file_prefix=wire_gen_prod gen .
+```
+
+Add build constraints to the generated files so only one compiles per build:
+
+```go
+// wire_gen_prod.go — add at the top (after wire writes it)
+//go:build !dev
+
+// wire_gen_dev.go — add at the top
+//go:build dev
+```
+
+Commit both generated files. At build time, only the matching file is compiled.
+
+## Cleanup-Heavy Graph
+
+When several providers need shutdown coordination, wire's reverse-order cleanup is essential.
+
+```go
+// Providers return (T, func(), error)
+func NewDBPool(cfg *Config) (*pgxpool.Pool, func(), error) {
+    pool, err := pgxpool.New(context.Background(), cfg.DSN)
+    if err != nil { return nil, nil, err }
+    return pool, func() { pool.Close() }, nil
+}
+
+func NewOTelExporter(cfg *Config) (*otlptrace.Exporter, func(), error) {
+    exp, err := otlptracegrpc.New(context.Background(), ...)
+    if err != nil { return nil, nil, err }
+    return exp, func() { exp.Shutdown(context.Background()) }, nil
+}
+
+func NewTracerProvider(exp *otlptrace.Exporter) (*trace.TracerProvider, func(), error) {
+    tp := trace.NewTracerProvider(trace.WithBatcher(exp))
+    return tp, func() { tp.Shutdown(context.Background()) }, nil
+}
+```
+
+Wire generates shutdown in reverse: `TracerProvider` → `OTelExporter` → `DBPool`. Each cleanup runs before its dependencies shut down — guaranteeing in-flight spans are flushed before the exporter closes.
+
+## Embedding Wire in a CLI
+
+Wire produces a struct, not an app framework. You control the lifecycle:
+
+```go
+// wire.go
+//go:build wireinject
+
+package cmd
+
+func InitServer(cfg *Config) (*http.Server, func(), error) {
+    wire.Build(InfraSet, ServiceSet, NewHTTPServer)
+    return nil, nil, nil
+}
+
+// cmd/serve.go
+func runServe(cfg *Config) error {
+    srv, cleanup, err := InitServer(cfg)
+    if err != nil { return err }
+    defer cleanup()
+
+    quit := make(chan os.Signal, 1)
+    signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
+
+    go func() {
+        if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
+            log.Fatal(err)
+        }
+    }()
+    <-quit
+    ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
+    defer cancel()
+    return srv.Shutdown(ctx)
+}
+```
+
+Unlike `fx.Run()`, wire does not manage the lifecycle loop. Implement signal handling and graceful shutdown explicitly. This is a feature for CLI tools that spin up short-lived services and need precise control over the shutdown sequence.
+
+## Passing External Values to Wire
+
+Values built before wire runs (parsed config, test doubles) become injector parameters:
+
+```go
+//go:build wireinject
+
+// cfg is resolved outside the graph — treated as a provided *Config
+func InitApp(cfg *Config) (*App, func(), error) {
+    wire.Build(InfraSet, ServiceSet, NewApp)
+    return nil, nil, nil
+}
+
+// main.go
+cfg, err := config.Load()
+if err != nil { log.Fatal(err) }
+app, cleanup, err := InitApp(cfg)
+```
+
+The parameter `cfg *Config` satisfies any downstream provider that requests `*Config` — no `wire.Value` or extra set entry needed.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/testing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/testing.md
new file mode 100644
index 00000000..cf1aa425
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-google-wire/references/testing.md
@@ -0,0 +1,173 @@
+# Testing — google/wire
+
+Wire generates plain Go constructor calls, so tests work directly on the constructor layer — no container API to learn.
+
+## Unit Tests: Plain Constructor Injection
+
+The generated code has no wire dependency. Test constructors directly:
+
+```go
+func TestUserService_GetUser(t *testing.T) {
+    mockStore := &MockUserStore{users: map[int64]*User{1: &User{ID: 1, Name: "Alice"}}}
+    cache := newTestRedis(t)
+    svc := service.NewUserService(mockStore, cache)
+
+    u, err := svc.GetUser(context.Background(), 1)
+    require.NoError(t, err)
+    assert.Equal(t, "Alice", u.Name)
+}
+```
+
+Pass mocks directly as constructor arguments. No wire, no container, no file to generate. This is the idiomatic approach for unit tests.
+
+## Test Injectors: Swapping Providers
+
+For integration or component tests where you want the full wired graph but with selected dependencies replaced, create a test-only injector in a `_test.go` file.
+
+```go
+// app_test.go
+//go:build wireinject
+
+package main
+
+import (
+    "testing"
+    "github.com/google/wire"
+)
+
+// TestSet replaces real infra with in-memory fakes
+var TestSet = wire.NewSet(
+    NewTestConfig,
+    NewInMemoryUserStore,
+    wire.Bind(new(repo.UserStore), new(*InMemoryUserStore)),
+    NewTestRedis,
+)
+
+func InitTestApp(t *testing.T) (*App, func(), error) {
+    wire.Build(TestSet, service.ServiceSet, NewApp)
+    return nil, nil, nil
+}
+```
+
+```go
+// app_integration_test.go
+//go:build !wireinject  // compiles when the wireinject tag is NOT set
+
+package main
+
+func TestApp_GetUser(t *testing.T) {
+    app, cleanup, err := InitTestApp(t)
+    require.NoError(t, err)
+    defer cleanup()
+
+    // test against the fully-wired app with fake dependencies
+    u, err := app.GetUser(context.Background(), 1)
+    require.NoError(t, err)
+    assert.NotNil(t, u)
+}
+```
+
+Run `wire ./...` to generate `wire_gen.go` — the test injector is included because the `_test.go` file is compiled as part of the package during `go test`.
+
+**Key pattern from upstream best practices:** Prefer creating a test-only provider set over passing mocks as injector arguments (though both work). The set approach keeps the test injector composable.
+
+## Passing Mocks as Injector Arguments
+
+An alternative to a test set: pass the mock directly as an injector parameter. Wire treats it as a pre-built provider.
+
+```go
+//go:build wireinject
+
+func InitTestApp(store repo.UserStore) (*App, func(), error) {
+    wire.Build(config.ConfigSet, service.ServiceSet, NewApp)
+    return nil, nil, nil
+}
+
+// Test
+func TestApp(t *testing.T) {
+    mock := &MockUserStore{}
+    app, cleanup, err := InitTestApp(mock)
+    require.NoError(t, err)
+    defer cleanup()
+    // ...
+}
+```
+
+Use this form when you only need to replace one or two dependencies and a full `TestSet` is overkill.
+
+## CI: Detecting Stale `wire_gen.go`
+
+If `wire_gen.go` is not regenerated after a provider change, CI builds pass but the graph is wrong. Enforce freshness in CI:
+
+```bash
+# Option 1: re-run wire and check for diffs
+wire ./...
+git diff --exit-code -- '**/wire_gen.go'
+```
+
+```yaml
+# .github/workflows/ci.yml
+- name: Check wire_gen.go is up-to-date
+  run: |
+    go install github.com/google/wire/cmd/wire@v0.7.0
+    wire ./...
+    git diff --exit-code -- '**/wire_gen.go'
+```
+
+```bash
+# Option 2: use wire check (verifies graph without regenerating)
+wire check ./...
+```
+
+`wire check` exits non-zero if the graph is inconsistent but does **not** update `wire_gen.go`. Use it for a fast graph-validity check without modifying files.
+
+## Testing Interface Bindings
+
+`wire.Bind` can be used in test sets to bind a fake to the same interface:
+
+```go
+// Fake implements the same interface as the real provider
+type FakeMailer struct{ sent []string }
+func (f *FakeMailer) Send(to, body string) error { f.sent = append(f.sent, to); return nil }
+
+var TestMailerSet = wire.NewSet(
+    NewFakeMailer,
+    wire.Bind(new(notification.Mailer), new(*FakeMailer)),
+)
+
+var TestSet = wire.NewSet(
+    TestMailerSet,
+    realServiceSet,  // everything else is real
+)
+```
+
+This keeps the test injector narrow — only the Mailer is faked; the rest of the graph is real.
+
+## Table-Driven Tests Without Wire
+
+Wire is an initialization tool. Once the object graph is built, table-driven tests on individual services need no wire involvement:
+
+```go
+func TestUserService(t *testing.T) {
+    cases := []struct {
+        name  string
+        id    int64
+        users map[int64]*User
+        want  string
+        err   bool
+    }{
+        {"found", 1, map[int64]*User{1: &User{Name: "Alice"}}, "Alice", false},
+        {"not found", 99, nil, "", true},
+    }
+    for _, tc := range cases {
+        t.Run(tc.name, func(t *testing.T) {
+            svc := service.NewUserService(&MockUserStore{users: tc.users}, nil)
+            u, err := svc.GetUser(context.Background(), tc.id)
+            if tc.err { require.Error(t, err); return }
+            assert.Equal(t, tc.want, u.Name)
+        })
+    }
+}
+```
+
+Wire has no role here — the injector was only needed to build the object graph in `main` (or in an integration test). Unit tests construct dependencies directly.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/SKILL.md
new file mode 100644
index 00000000..43e04f03
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/SKILL.md
@@ -0,0 +1,276 @@
+---
+name: golang-graphql
+description: "Implements GraphQL APIs in Golang using gqlgen or graphql-go. Apply when building GraphQL servers, designing schemas, writing resolvers, handling subscriptions, or integrating GraphQL with existing Go HTTP services. Also apply when the codebase imports `github.com/99designs/gqlgen` or `github.com/graph-gophers/graphql-go`."
+user-invocable: false
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "0.0.3"
+  openclaw:
+    emoji: "🔮"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "0.17.89"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs Bash(curl:*)
+---
+
+**Persona:** You are a Go GraphQL engineer. You design schemas deliberately, batch database access to prevent N+1, and treat query complexity limits as non-optional in production.
+
+**Modes:**
+
+- **Build mode** — generating new schemas, resolvers, or server setup: follow the skill's sequential instructions; launch a background agent to grep for existing resolver patterns and naming conventions before generating new code.
+- **Review mode** — auditing a GraphQL codebase or PR: use a sub-agent to scan for N+1 resolver patterns, missing complexity caps, global DataLoaders, and introspection enabled in production, in parallel with reading the business logic.
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-graphql` skill takes precedence.
+
+# Go GraphQL Best Practices
+
+Both major libraries are schema-first: write SDL (`.graphql` files), bind Go resolvers. Choose based on project size and team preferences.
+
+This skill is not exhaustive. Refer to each library's official documentation and code examples for current API signatures. Context7 can help as a discoverability platform.
+
+## Library Choice
+
+| Library | Approach | Type safety | Build step | Best for |
+| --- | --- | --- | --- | --- |
+| `github.com/99designs/gqlgen` | Codegen | Compile-time | `go generate` | Large schemas, federation, strict types |
+| `github.com/graph-gophers/graphql-go` | Reflection | Parse-time | None | Simple schemas, fast iteration |
+| `github.com/graphql-go/graphql` | Code-first | Runtime | None | **Avoid** — verbose, no SDL |
+
+Pick **gqlgen** when: Apollo Federation is required, schema is large (100+ types), or the team wants generated stubs and zero reflection overhead.
+
+Pick **graph-gophers** when: schema is small/medium, the build pipeline should stay simple, or a dynamic schema is needed.
+
+For deep-dive on each library, see [gqlgen reference](./references/gqlgen.md) and [graphql-go reference](./references/graphql-go.md).
+
+## Schema Design
+
+```graphql
+# ✓ Good — explicit nullability; ID scalar for opaque identifiers
+type User {
+  id: ID!
+  email: String! # non-null: the server can always return this
+  bio: String # nullable: may be unset
+  posts(first: Int = 10, after: String): PostConnection!
+}
+
+# ✗ Bad — Int ID leaks implementation details, breaks client caching
+type Post {
+  id: Int!
+}
+```
+
+**Nullability rule:** mark a field `!` only when the server can _always_ return a value. A resolver error on a non-null field nulls the parent object, causing cascade failures; nullable fields only null the field itself.
+
+**Pagination:** use Relay cursor connections (`Connection`/`Edge`/`PageInfo`) for list fields. Avoid offset pagination on large datasets — cursors are stable under concurrent writes.
+
+**Mutations:** wrap results in an envelope type so clients receive business errors alongside partial results without polluting the GraphQL `errors` array:
+
+```graphql
+type CreateUserPayload {
+  user: User
+  errors: [UserError!]!
+}
+```
+
+## Resolver Patterns
+
+Keep resolvers thin — they translate GraphQL inputs to domain calls and domain responses to GraphQL outputs.
+
+```go
+// ✓ Good — resolver delegates to service layer
+func (r *mutationResolver) CreateUser(ctx context.Context, input model.CreateUserInput) (*model.CreateUserPayload, error) {
+    user, err := r.userService.Create(ctx, input.Email, input.Name)
+    if err != nil {
+        return nil, formatError(err)
+    }
+    return &model.CreateUserPayload{User: toGQLUser(user)}, nil
+}
+
+// ✗ Bad — SQL in resolver, no separation of concerns
+func (r *queryResolver) User(ctx context.Context, id string) (*model.User, error) {
+    row := r.db.QueryRowContext(ctx, "SELECT * FROM users WHERE id = $1", id)
+    // ...
+}
+```
+
+Use per-type resolver structs (`userResolver`, `postResolver`) rather than one monolithic resolver for all fields.
+
+## N+1 Prevention (DataLoaders)
+
+Each `User.posts` resolver fires a SQL query per user without batching — O(n) DB calls for n users. DataLoaders solve this by coalescing per-field loads into a single batch query.
+
+**Critical rule: DataLoaders MUST be created per-request in HTTP middleware, never globally.** A global DataLoader caches across requests — stale data, potential cross-user data leakage.
+
+```go
+// ✓ Good — per-request DataLoader in middleware
+func DataLoaderMiddleware(db *sql.DB, next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        loaders := &Loaders{
+            PostsByUserID: newPostsByUserIDLoader(r.Context(), db),
+        }
+        ctx := context.WithValue(r.Context(), loadersKey, loaders)
+        next.ServeHTTP(w, r.WithContext(ctx))
+    })
+}
+
+// ✗ Bad — global DataLoader shared across all requests
+var globalLoader = newPostsByUserIDLoader(context.Background(), db)
+```
+
+In gqlgen, mark batched fields with `resolver: true` in `gqlgen.yml` to force a dedicated resolver method. See [gqlgen reference](./references/gqlgen.md) for full DataLoader wiring.
+
+## Authentication and Authorization
+
+Two-layer model:
+
+1. **HTTP middleware** — extract and validate tokens, stash identity in `context.Context`.
+2. **Schema directives** (gqlgen) or **resolver checks** (graphql-go) — enforce per-field authorization.
+
+```go
+// HTTP middleware layer (both libraries)
+func AuthMiddleware(next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        token := r.Header.Get("Authorization")
+        user, err := validateToken(token)
+        if err != nil {
+            http.Error(w, "Unauthorized", http.StatusUnauthorized)
+            return
+        }
+        ctx := context.WithValue(r.Context(), userKey, user)
+        next.ServeHTTP(w, r.WithContext(ctx))
+    })
+}
+```
+
+In gqlgen, use `@hasRole` schema directives for field-level authorization — authorization policy lives in the schema, not scattered across resolvers. See [gqlgen reference](./references/gqlgen.md).
+
+## Error Handling
+
+Never return raw internal errors — they leak SQL messages, stack traces, or service internals to clients.
+
+```go
+// gqlgen — custom ErrorPresenter strips internal details
+srv.SetErrorPresenter(func(ctx context.Context, err error) *gqlerror.Error {
+    var gqlErr *gqlerror.Error
+    if errors.As(err, &gqlErr) {
+        return gqlErr // already formatted
+    }
+    // log internal err here
+    return gqlerror.Errorf("internal error") // safe client message
+})
+
+// Add extension codes for client-side error handling
+return nil, &gqlerror.Error{
+    Message: "user not found",
+    Extensions: map[string]any{"code": "NOT_FOUND"},
+}
+```
+
+For graph-gophers, implement the `ResolverError` interface to attach `Extensions()`. See [graphql-go reference](./references/graphql-go.md).
+
+Use `graphql.AddError(ctx, err)` in gqlgen for non-fatal field errors where the resolver can still return partial data.
+
+For error wrapping patterns, see the `samber/cc-skills-golang@golang-error-handling` skill.
+
+## Subscriptions
+
+Subscriptions use long-lived WebSocket connections. The critical discipline: **always respect context cancellation** — a leaked goroutine per disconnected client exhausts resources silently.
+
+```go
+// ✓ Good — closes channel when client disconnects
+func (r *subscriptionResolver) MessageAdded(ctx context.Context, room string) (<-chan *model.Message, error) {
+    ch := make(chan *model.Message, 1)
+    sub := r.pubsub.Subscribe(room) // subscribe once before the goroutine
+    go func() {
+        defer close(ch) // always close; signals iteration to stop
+        for {
+            select {
+            case <-ctx.Done():
+                return // client disconnected
+            case msg := <-sub:
+                select {
+                case ch <- msg:
+                case <-ctx.Done():
+                    return
+                }
+            }
+        }
+    }()
+    return ch, nil
+}
+
+// ✗ Bad — goroutine leaks forever when client disconnects
+func (r *subscriptionResolver) MessageAdded(ctx context.Context, room string) (<-chan *model.Message, error) {
+    ch := make(chan *model.Message, 1)
+    go func() {
+        for msg := range r.pubsub.Subscribe(room) {
+            ch <- msg // blocks forever after client gone
+        }
+    }()
+    return ch, nil
+}
+```
+
+## Performance and Safety
+
+Production GraphQL servers require explicit limits. Without them, a single deeply nested query exhausts CPU and memory.
+
+```go
+// gqlgen — wire these into every production handler
+srv := handler.NewDefaultServer(es)
+srv.Use(extension.FixedComplexityLimit(200)) // max cost per query
+
+// Gate introspection — only in non-production environments
+if os.Getenv("ENV") != "production" {
+    srv.Use(extension.Introspection{})
+}
+```
+
+For graph-gophers: `graphql.MaxDepth(10)` and `graphql.MaxParallelism(10)` options at `ParseSchema` time.
+
+**Query allow-listing:** in production, consider persisted queries (gqlgen APQ extension) to reject arbitrary query strings.
+
+## Common Mistakes
+
+| Mistake | Why it matters | Fix |
+| --- | --- | --- |
+| N+1 queries in child resolvers | One SQL per parent row → O(n) DB calls | Use per-request DataLoader |
+| Global DataLoader | Cross-request cache — stale data, data leaks | Create DataLoader in request middleware |
+| Editing `models_gen.go` directly | Next `go generate` wipes hand edits | Use `autobind` or `models.<T>.model` in `gqlgen.yml` |
+| Forgetting `go generate` after schema change | Resolver interface mismatch at compile time | Re-run `go tool gqlgen generate` |
+| `int` field in graph-gophers resolver | Library requires `int32` for `Int` scalar | Use `int32` (or `float64` for `Float`) |
+| Introspection enabled in production | Exposes full schema to attackers | Gate with `ENV` check |
+| No complexity cap | Deeply nested query → CPU/memory DoS | `extension.FixedComplexityLimit(N)` |
+| Leaking DB errors from resolvers | Exposes SQL internals to clients | Wrap in `ErrorPresenter` / `ResolverError` |
+| Subscription goroutine leak | Client disconnect → goroutine runs forever | `defer close(ch)` + `select ctx.Done()` |
+| Nullable field for always-required data | Clients must null-check everywhere | Mark `!` in schema; return error from resolver |
+
+## Deep Dives
+
+- **[gqlgen reference](./references/gqlgen.md)** — codegen workflow, `gqlgen.yml`, DataLoaders, Federation v2, directives
+- **[graphql-go reference](./references/graphql-go.md)** — reflection resolver model, type mapping, tracing
+- **[Testing](./references/testing.md)** — gqlgen client harness, gqltesting, httptest patterns
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-context` skill for context propagation in resolvers and subscriptions
+- → See `samber/cc-skills-golang@golang-error-handling` skill for error wrapping and sentinel patterns
+- → See `samber/cc-skills-golang@golang-testing` skill for table-driven and integration test patterns
+- → See `samber/cc-skills-golang@golang-observability` skill for tracing and metrics in resolvers
+- → See `samber/cc-skills-golang@golang-security` skill for input validation and injection prevention
+- → See `samber/cc-skills-golang@golang-database` skill for N+1 query patterns and DataLoader database batching
+
+## References
+
+- [gqlgen](https://github.com/99designs/gqlgen)
+- [graph-gophers/graphql-go](https://github.com/graph-gophers/graphql-go)
+- [Relay cursor connections spec](https://relay.dev/graphql/connections.htm)
+
+If you encounter a bug or unexpected behavior in gqlgen, open an issue at <https://github.com/99designs/gqlgen/issues>.
+
+If you encounter a bug or unexpected behavior in graph-gophers/graphql-go, open an issue at <https://github.com/graph-gophers/graphql-go/issues>.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/evals/evals.json
new file mode 100644
index 00000000..3aff69e1
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/evals/evals.json
@@ -0,0 +1,168 @@
+{
+  "skill_name": "golang-graphql",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I have a gqlgen project with a User type and a Post type. Users have many posts. Write the Go resolver for User.posts. We fetch posts from a PostgreSQL database. The project is set up with a standard gqlgen layout.",
+      "expected_output": "A resolver that uses a per-request DataLoader (not direct DB calls) to batch-fetch posts by user IDs. Must NOT query the database directly inside the resolver. Must NOT use a global DataLoader. Should use context to access the per-request loader.",
+      "assertions": [
+        "Uses a DataLoader or batch loader to fetch posts, not a direct db.Query/QueryContext call inside the resolver method",
+        "Accesses the DataLoader from context (not a package-level or global variable)",
+        "The resolver function signature uses obj *model.User as a parameter to access the parent user's ID",
+        "Does not query the database directly inside the Posts resolver body",
+        "Mentions that the DataLoader must be injected per-request via HTTP middleware",
+        "DataLoader middleware creates a new loader instance per request, not a shared global"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "We have a graph-gophers/graphql-go project. I need to add a resolver that returns the total comment count for a post. The field is declared as `commentCount: Int!` in the SDL. Write the Go resolver method.",
+      "expected_output": "Resolver method using int32 (not int) as the return type for the Int! scalar field. Must use int32, since graph-gophers requires this specific type.",
+      "assertions": [
+        "Returns int32 (not int, int64, or uint) for the Int! scalar field",
+        "Method signature matches the SDL field name (case-insensitive: CommentCount or commentCount)",
+        "Does not return plain Go int — which causes a type mismatch at parse time with graph-gophers"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "Set up a production-ready gqlgen HTTP handler. The app will be deployed publicly. We need to make sure it's safe to expose.",
+      "expected_output": "Handler setup that gates introspection (disabled or ENV-checked in production) and adds a query complexity limit. Must not leave introspection unconditionally enabled.",
+      "assertions": [
+        "Introspection is gated — either disabled in production or guarded by an environment variable check",
+        "A complexity limit is set using extension.FixedComplexityLimit or equivalent",
+        "Does NOT call srv.Use(extension.Introspection{}) unconditionally without an env guard",
+        "Uses handler.New or handler.NewDefaultServer from github.com/99designs/gqlgen/graphql/handler",
+        "Mentions MaxDepth or complexity limiting as a protection against deeply nested queries"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "Implement a messageAdded subscription resolver in gqlgen. Messages are published via an in-memory pub/sub system. The resolver should stream new messages to subscribers in a given room.",
+      "expected_output": "Subscription resolver that closes the channel on context cancellation (defer close(ch) + ctx.Done() in a select). Must handle client disconnect to avoid goroutine leaks.",
+      "assertions": [
+        "Uses defer close(ch) to close the output channel when done",
+        "Uses a select statement with ctx.Done() to detect client disconnection",
+        "Returns a receive-only channel (<-chan *model.Message or similar)",
+        "Does not use a plain for-range loop without ctx.Done() check — this would cause a goroutine leak on disconnect",
+        "The goroutine terminates when ctx is cancelled"
+      ],
+      "files": []
+    },
+    {
+      "id": 5,
+      "prompt": "I'm using gqlgen and want to customize the User type to reuse my existing domain.User struct instead of having gqlgen generate a new one. The domain struct has an Email field. How do I configure this?",
+      "expected_output": "Uses autobind or models.<T>.model in gqlgen.yml to map the GraphQL User type to domain.User. Must NOT instruct editing models_gen.go directly.",
+      "assertions": [
+        "Uses gqlgen.yml configuration (autobind or models.<T>.model) to bind the existing struct",
+        "Does NOT suggest editing models_gen.go or generated.go directly",
+        "Shows the correct gqlgen.yml syntax for either autobind or models.<T>.model",
+        "Mentions that generated files are overwritten on next go generate"
+      ],
+      "files": []
+    },
+    {
+      "id": 6,
+      "prompt": "In a graph-gophers/graphql-go resolver, I need to return a user profile that includes a nullable bio field. The SDL has: bio: String. Write the Go struct field or return type for bio.",
+      "expected_output": "Uses *string (pointer to string) for the nullable String field. Non-pointer string would imply non-null in graph-gophers.",
+      "assertions": [
+        "Uses *string (pointer) for the nullable bio field, not plain string",
+        "Explains that non-pointer = non-null and pointer = nullable in graph-gophers type mapping",
+        "Does not use sql.NullString or other DB-specific nullable types for the GraphQL resolver layer"
+      ],
+      "files": []
+    },
+    {
+      "id": 7,
+      "prompt": "My gqlgen resolver calls a database function that can return sql.ErrNoRows or other database errors. Write the resolver for GetUser(id: ID!): User! that handles these cases correctly for clients.",
+      "expected_output": "Resolver wraps or transforms errors before returning them. Uses ErrorPresenter or gqlerror.Error with extensions code. Must NOT return raw sql.ErrNoRows to the client.",
+      "assertions": [
+        "Does NOT return raw sql.ErrNoRows or other internal errors directly to the client",
+        "Translates sql.ErrNoRows to a GraphQL error with a meaningful message or extension code (e.g. NOT_FOUND)",
+        "Uses gqlerror.Error or gqlerror.Errorf to format the client error",
+        "Mentions the ErrorPresenter as the right place to centralize error sanitization",
+        "Wraps internal errors so they don't expose SQL messages to API consumers"
+      ],
+      "files": []
+    },
+    {
+      "id": 8,
+      "prompt": "Design a GraphQL mutation for creating a user where the email is always required but the bio is optional. The mutation should handle validation errors gracefully without returning HTTP errors.",
+      "expected_output": "Uses a mutation envelope payload type with a user field and an errors field. Email is String! (non-null) in input; bio is String (nullable). Errors are returned in the payload, not as GraphQL top-level errors.",
+      "assertions": [
+        "Input type has email: String! (non-null) for required email",
+        "Input type has bio: String (nullable, no !) for optional bio",
+        "Mutation returns a payload envelope type with both user and errors fields",
+        "Validation errors are returned inside the payload errors field, not as GraphQL top-level errors",
+        "The payload errors field uses a non-null list type like [UserError!]! or similar",
+        "Does NOT use HTTP 400/422 errors for validation — uses the GraphQL payload pattern"
+      ],
+      "files": []
+    },
+    {
+      "id": 9,
+      "prompt": "Write a gqlgen subscription resolver for order status updates. Use an in-memory pub/sub broker. The resolver should subscribe to a topic named after the order ID and stream status events.",
+      "expected_output": "Resolver subscribes to the pub/sub topic ONCE before launching the goroutine, not inside the goroutine loop. The channel is closed when the context is cancelled.",
+      "assertions": [
+        "Calls the pub/sub Subscribe (or equivalent) method BEFORE the go func() call, not inside the goroutine",
+        "Does NOT call Subscribe() inside the for-select loop body (which would create a new subscription per iteration)",
+        "Uses defer close(ch) to signal iteration end",
+        "Uses select with ctx.Done() to handle client disconnect",
+        "The subscription/topic handle is captured in a variable before the goroutine starts"
+      ],
+      "files": []
+    },
+    {
+      "id": 10,
+      "prompt": "In a graph-gophers/graphql-go project, add a search query: `search(query: String!, first: Int, after: ID): [User!]!`. The first and after arguments are optional pagination parameters. Write the Go args struct for this resolver.",
+      "expected_output": "Uses *int32 (not *int or int32) for the nullable Int argument 'first', and graphql.ID (or *graphql.ID) for the after argument. Nullable args use pointer types.",
+      "assertions": [
+        "Uses *int32 (pointer to int32) for the optional 'first: Int' argument — NOT *int or int32",
+        "Uses graphql.ID or *graphql.ID for the 'after: ID' argument",
+        "Optional arguments are represented as pointers to allow nil (absent) values",
+        "Does NOT use plain int or *int for an Int field in graph-gophers"
+      ],
+      "files": []
+    },
+    {
+      "id": 11,
+      "prompt": "Write a dataloadgen batch function for a gqlgen project that fetches all posts for a list of user IDs. Each user can have zero or more posts.",
+      "expected_output": "Batch function returns [][]*domain.Post (a slice of post slices, one per user ID), not []*domain.Post. The outer slice length must match the input IDs length.",
+      "assertions": [
+        "Batch function return type is [][]*domain.Post (2D slice) or equivalent — NOT []*domain.Post",
+        "The outer slice has exactly one element per input user ID (same length as the ids parameter)",
+        "Handles users with zero posts by including an empty slice (not nil or missing entry)",
+        "Does NOT return a flat []*domain.Post that collapses all posts into one slice"
+      ],
+      "files": []
+    },
+    {
+      "id": 12,
+      "prompt": "Add OpenTelemetry tracing to a graph-gophers/graphql-go server. Show the import statement and the ParseSchema call with the tracer configured.",
+      "expected_output": "Uses github.com/graph-gophers/graphql-go/trace/otel import and otel.DefaultTracer() — not an external otelgraphql package. Passed as graphql.Tracer() option.",
+      "assertions": [
+        "Imports github.com/graph-gophers/graphql-go/trace/otel (the bundled tracer package)",
+        "Uses otel.DefaultTracer() to construct the tracer — NOT otelgraphql.DefaultTracer() or similar hallucinated package",
+        "Passes the tracer as graphql.Tracer(otel.DefaultTracer()) option to MustParseSchema or ParseSchema",
+        "Does NOT import an external third-party otelgraphql package that does not exist in graph-gophers"
+      ],
+      "files": []
+    },
+    {
+      "id": 13,
+      "prompt": "We're building a federated GraphQL system with gqlgen. The User service owns the User type and must be resolvable by its id field from other services. What configuration and code changes are needed?",
+      "expected_output": "Configures federation.version: 2 in gqlgen.yml, adds @key(fields: 'id') to the User schema type, and implements a FindUserByID entity resolver. Mentions Apollo Router or Cosmo as the gateway.",
+      "assertions": [
+        "Adds federation block with version: 2 to gqlgen.yml",
+        "Adds @key(fields: \"id\") directive to the User type in the SDL schema",
+        "Implements or mentions the FindUserByID entity resolver (generated by gqlgen's federation support)",
+        "Imports or links the Apollo Federation v2 spec URL in the schema extend block",
+        "Does NOT describe a manual federation approach without gqlgen.yml config"
+      ],
+      "files": []
+    }
+  ]
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/gqlgen.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/gqlgen.md
new file mode 100644
index 00000000..ab5cbef0
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/gqlgen.md
@@ -0,0 +1,271 @@
+# gqlgen Reference
+
+gqlgen is a schema-first, code-generation library. Write SDL, run `go generate`, fill in resolver bodies.
+
+## Project Setup
+
+```bash
+# Bootstrap a new project
+go run github.com/99designs/gqlgen init
+
+# Pin the tool in go.mod for reproducible generation (Go 1.24+)
+go get -tool github.com/99designs/gqlgen@latest
+```
+
+For Go <1.24 modules, use the legacy `tools.go` blank-import workaround instead.
+
+```bash
+# Regenerate after every schema change
+go tool gqlgen generate
+```
+
+Never hand-edit generated files (`generated.go`, `models_gen.go`) — `generate` overwrites them.
+
+## gqlgen.yml
+
+```yaml
+schema:
+  - graph/schema/*.graphql
+
+exec:
+  filename: graph/generated.go
+  package: graph
+
+model:
+  filename: graph/model/models_gen.go
+  package: model
+
+resolver:
+  layout: follow-schema # one resolvers file per schema file
+  dir: graph
+  package: graph
+  filename_template: "{name}.resolvers.go"
+
+autobind:
+  - github.com/me/app/internal/domain # reuse existing structs
+
+models:
+  # ID: graphql.IntID  # legacy only — use opaque string IDs for new schemas
+  User:
+    model: github.com/me/app/internal/domain.User
+    fields:
+      posts:
+        resolver: true # force a custom resolver (required for DataLoader fields)
+
+omit_slice_element_pointers: true
+struct_fields_always_pointers: false
+resolvers_always_return_pointers: true
+```
+
+Key knobs:
+
+- `autobind` — maps Go structs to GraphQL types; fields must match by name (case-insensitive)
+- `models.<T>.model` — override which Go type backs a GraphQL type
+- `fields.<f>.resolver: true` — force a custom resolver instead of struct field access; required for any field that should batch via DataLoader
+- `struct_fields_always_pointers` / `resolvers_always_return_pointers` — controls `*T` vs `T` in generated signatures; match your domain model conventions
+
+## Resolver Structure
+
+The generated `Config` holds a `Resolvers` field of the generated interface. You implement it:
+
+```go
+// graph/resolver.go — you own this file, not generated
+type Resolver struct {
+    db          *sql.DB
+    userService *service.UserService
+    loaders     *dataloaders.Loaders // injected per-request
+}
+```
+
+Per-type resolvers implement the generated interface split by GraphQL type:
+
+```go
+type queryResolver struct{ *Resolver }
+type mutationResolver struct{ *Resolver }
+type userResolver struct{ *Resolver }
+
+func (r *queryResolver) User(ctx context.Context, id string) (*model.User, error) { ... }
+func (r *userResolver) Posts(ctx context.Context, obj *model.User) ([]*model.Post, error) { ... }
+```
+
+`obj` is the parent object — the entry point for walking the graph.
+
+## DataLoaders (gqlgen)
+
+Use `github.com/vikstrous/dataloadgen` (generics, fast) or `github.com/graph-gophers/dataloader`:
+
+```go
+// Inject per-request via middleware
+func Middleware(db *sql.DB, next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        loaders := &Loaders{
+            PostsByUserID: dataloadgen.NewLoader(func(ctx context.Context, ids []string) ([][]*domain.Post, []error) {
+                return batchPostsByUserID(ctx, db, ids) // returns one []Post per user ID
+            }, dataloadgen.WithWait(1*time.Millisecond)),
+        }
+        ctx := context.WithValue(r.Context(), loadersKey, loaders)
+        next.ServeHTTP(w, r.WithContext(ctx))
+    })
+}
+
+// Resolver uses the loader — never the DB directly
+func (r *userResolver) Posts(ctx context.Context, obj *model.User) ([]*model.Post, error) {
+    return loaders.For(ctx).PostsByUserID.Load(ctx, obj.ID)
+}
+```
+
+Set `wait` to 1–2ms — allows multiple concurrent resolvers to register keys before the batch fires.
+
+## Authentication Directives
+
+```graphql
+directive @hasRole(role: Role!) on FIELD_DEFINITION
+
+type Query {
+  adminStats: Stats! @hasRole(role: ADMIN)
+}
+```
+
+```go
+// Implement the directive function
+func HasRole(ctx context.Context, obj any, next graphql.Resolver, role model.Role) (any, error) {
+    user := auth.UserFromContext(ctx)
+    if user == nil || user.Role != role {
+        return nil, &gqlerror.Error{
+            Message:    "access denied",
+            Extensions: map[string]any{"code": "FORBIDDEN"},
+        }
+    }
+    return next(ctx)
+}
+
+// Register at server bootstrap
+c := generated.Config{
+    Resolvers: &graph.Resolver{...},
+    Directives: generated.DirectiveRoot{
+        HasRole: HasRole,
+    },
+}
+```
+
+## Middleware Hooks
+
+```go
+srv.AroundOperations(func(ctx context.Context, next graphql.OperationHandler) graphql.ResponseHandler {
+    // log operation name, add trace span
+    return next(ctx)
+})
+srv.AroundFields(func(ctx context.Context, next graphql.Resolver) (any, error) {
+    // per-field tracing, timing
+    return next(ctx)
+})
+```
+
+## Error Presenter
+
+```go
+srv.SetErrorPresenter(func(ctx context.Context, err error) *gqlerror.Error {
+    var gqlErr *gqlerror.Error
+    if errors.As(err, &gqlErr) {
+        return gqlErr
+    }
+    log.Ctx(ctx).Error("resolver error", "err", err)
+    return gqlerror.Errorf("internal server error")
+})
+
+srv.SetRecoverFunc(func(ctx context.Context, err any) error {
+    log.Ctx(ctx).Error("panic in resolver", "err", err)
+    return fmt.Errorf("internal server error")
+})
+```
+
+## Subscriptions
+
+```go
+srv.AddTransport(transport.Websocket{
+    KeepAlivePingInterval: 10 * time.Second,
+    Upgrader: websocket.Upgrader{
+        // Restrict to your own origin in production; true here is dev-only.
+        CheckOrigin: func(r *http.Request) bool {
+            return r.Header.Get("Origin") == "https://app.example.com"
+        },
+    },
+    InitFunc: func(ctx context.Context, initPayload transport.InitPayload) (context.Context, *transport.InitPayload, error) {
+        // auth at connection time
+        token := initPayload.Authorization()
+        user, err := validateToken(token)
+        if err != nil {
+            return ctx, nil, err
+        }
+        return context.WithValue(ctx, userKey, user), &initPayload, nil
+    },
+})
+```
+
+gqlgen supports both `graphql-ws` (legacy) and `graphql-transport-ws` (current) subprotocols.
+
+## File Uploads
+
+```go
+srv.AddTransport(transport.MultipartForm{
+    MaxUploadSize: 10 << 20, // 10 MB total
+    MaxMemory:     5 << 20,  // 5 MB in memory; rest spills to disk
+})
+```
+
+Schema:
+
+```graphql
+scalar Upload
+
+type Mutation {
+  uploadAvatar(file: Upload!): User!
+}
+```
+
+Resolver receives `graphql.Upload{File io.Reader, Filename string, Size int64, ContentType string}`.
+
+## Apollo Federation v2
+
+`gqlgen.yml`:
+
+```yaml
+federation:
+  filename: graph/federation.go
+  version: 2
+```
+
+Schema:
+
+```graphql
+extend schema
+  @link(
+    url: "https://specs.apollo.dev/federation/v2.3"
+    import: ["@key", "@shareable", "@external"]
+  )
+
+type User @key(fields: "id") {
+  id: ID!
+  name: String!
+}
+```
+
+Implement `FindUserByID` in the generated entity resolver. Works with Apollo Router and Cosmo.
+
+## Production Handler Setup
+
+```go
+srv := handler.New(es)
+srv.AddTransport(transport.Options{})
+srv.AddTransport(transport.GET{})
+srv.AddTransport(transport.POST{})
+srv.AddTransport(transport.MultipartForm{MaxUploadSize: 10 << 20, MaxMemory: 5 << 20})
+srv.AddTransport(transport.Websocket{KeepAlivePingInterval: 10 * time.Second})
+
+srv.SetQueryCache(lru.New[*ast.QueryDocument](1000))
+if os.Getenv("ENV") != "production" {
+    srv.Use(extension.Introspection{})
+}
+srv.Use(extension.AutomaticPersistedQuery{Cache: lru.New[string](100)})
+srv.Use(extension.FixedComplexityLimit(200))
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/graphql-go.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/graphql-go.md
new file mode 100644
index 00000000..2a724af8
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/graphql-go.md
@@ -0,0 +1,262 @@
+# graph-gophers/graphql-go Reference
+
+Schema-first, reflection-based — no codegen. Write SDL, bind Go resolver structs. Parse-time validation gives a fail-fast contract.
+
+## Setup
+
+```go
+import (
+    "github.com/graph-gophers/graphql-go"
+    "github.com/graph-gophers/graphql-go/relay"
+    "github.com/graph-gophers/graphql-go/trace/otel"
+)
+
+schema := graphql.MustParseSchema(sdlString, &RootResolver{},
+    graphql.MaxDepth(10),
+    graphql.MaxParallelism(10),
+    graphql.UseFieldResolvers(), // expose exported struct fields without explicit methods
+    graphql.Tracer(otel.DefaultTracer()),
+)
+
+http.Handle("/graphql", &relay.Handler{Schema: schema})
+```
+
+`MustParseSchema` panics on invalid SDL or resolver mismatch — catch it at startup, not at request time.
+
+## Resolver Structure
+
+One exported method per schema field; name match is case-insensitive:
+
+```go
+type RootResolver struct {
+    db *sql.DB
+}
+
+type QueryResolver struct {
+    db *sql.DB
+}
+
+func (r *RootResolver) Query() *QueryResolver { return &QueryResolver{db: r.db} }
+
+// Args struct for field arguments
+func (r *QueryResolver) User(ctx context.Context, args struct{ ID graphql.ID }) (*UserResolver, error) {
+    user, err := r.db.GetUser(ctx, string(args.ID))
+    if err != nil {
+        return nil, err
+    }
+    return &UserResolver{user: user}, nil
+}
+```
+
+Return resolver wrapper structs, not domain models directly — keeps GraphQL projection separate from persistence.
+
+## Type Mapping
+
+<!-- prettier-ignore -->
+|GraphQL type|Go type|Notes|
+|---|---|---|
+|`ID`|`graphql.ID`|string alias|
+|`Int`|`int32`|**NOT `int`** — mismatch is a parse-time error|
+|`Float`|`float64`||
+|`String`|`string`||
+|`Boolean`|`bool`||
+|`[T]`|`[]*T` or `[]T`||
+|Nullable `T`|`*T`|pointer = nullable|
+|Non-null `T!`|`T`|non-pointer|
+|Custom scalar|implement `UnmarshalGraphQL(input any) error` + `MarshalJSON() ([]byte, error)`||
+|Enum|typed string alias||
+|Input|exported struct with field tags optional||
+|Interface/Union|Go interface returned; `ToConcreteType() (*T, bool)` discriminators||
+
+Common mistake: using `int` for an `Int!` field — the parser rejects it with a type mismatch error.
+
+## Nullable vs Non-null Arguments
+
+```go
+// ✓ Good — pointer arg = nullable in schema
+func (r *QueryResolver) Users(ctx context.Context, args struct {
+    Role *string // nullable: Role in SDL
+    Limit int32  // non-null: Limit! in SDL
+}) ([]*UserResolver, error) { ... }
+```
+
+Forgetting `*` on a nullable argument causes unmarshal failure when clients send `null`.
+
+## Custom Scalar
+
+```go
+type DateTime struct{ time.Time }
+
+func (d *DateTime) UnmarshalGraphQL(input any) error {
+    s, ok := input.(string)
+    if !ok {
+        return fmt.Errorf("DateTime must be a string")
+    }
+    t, err := time.Parse(time.RFC3339, s)
+    if err != nil {
+        return err
+    }
+    d.Time = t
+    return nil
+}
+
+func (d DateTime) MarshalJSON() ([]byte, error) {
+    return json.Marshal(d.Time.Format(time.RFC3339))
+}
+```
+
+## Interfaces and Unions
+
+```graphql
+interface Node {
+  id: ID!
+}
+union SearchResult = User | Post
+```
+
+```go
+// Interface — implement ToUser, ToPost discriminators
+type SearchResultResolver struct{ result any }
+
+func (r *SearchResultResolver) ToUser() (*UserResolver, bool) {
+    u, ok := r.result.(*domain.User)
+    return &UserResolver{u}, ok
+}
+
+func (r *SearchResultResolver) ToPost() (*PostResolver, bool) {
+    p, ok := r.result.(*domain.Post)
+    return &PostResolver{p}, ok
+}
+```
+
+## DataLoaders
+
+Use `github.com/graph-gophers/dataloader` per-request:
+
+```go
+func DataLoaderMiddleware(db *sql.DB, next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        loader := dataloader.NewBatchedLoader(func(ctx context.Context, keys dataloader.Keys) []*dataloader.Result {
+            ids := make([]string, len(keys))
+            for i, k := range keys {
+                ids[i] = k.String()
+            }
+            posts, err := batchPostsByUserID(ctx, db, ids)
+            // map results back to keys order ...
+            return results
+        })
+        ctx := context.WithValue(r.Context(), postsLoaderKey, loader)
+        next.ServeHTTP(w, r.WithContext(ctx))
+    })
+}
+
+// In resolver
+func (r *UserResolver) Posts(ctx context.Context) ([]*PostResolver, error) {
+    thunk := ctx.Value(postsLoaderKey).(*dataloader.Loader).Load(ctx, dataloader.StringKey(r.user.ID))
+    result, err := thunk()
+    // ...
+}
+```
+
+## Error Handling
+
+Implement `ResolverError` to attach structured extensions:
+
+```go
+type ResolverError interface {
+    error
+    Extensions() map[string]any
+}
+
+type AppError struct {
+    msg  string
+    code string
+}
+
+func (e *AppError) Error() string { return e.msg }
+func (e *AppError) Extensions() map[string]any {
+    return map[string]any{"code": e.code}
+}
+
+// Usage in resolver
+return nil, &AppError{msg: "user not found", code: "NOT_FOUND"}
+```
+
+Panics in resolvers are caught automatically and converted to GraphQL errors.
+
+## OpenTelemetry Tracing
+
+```go
+import "github.com/graph-gophers/graphql-go/trace/otel"
+
+schema := graphql.MustParseSchema(sdl, &RootResolver{},
+    graphql.Tracer(otel.DefaultTracer()),
+)
+```
+
+Emits spans per request, validation, and field resolution with operation name and field path.
+
+## Subscriptions
+
+```go
+func (r *SubscriptionResolver) MessageAdded(ctx context.Context, args struct{ Room string }) <-chan *MessageResolver {
+    ch := make(chan *MessageResolver, 1)
+    go func() {
+        defer close(ch)
+        sub := r.pubsub.Subscribe(args.Room)
+        defer sub.Unsubscribe()
+        for {
+            select {
+            case <-ctx.Done():
+                return
+            case msg := <-sub.Chan():
+                select {
+                case ch <- &MessageResolver{msg: msg}:
+                case <-ctx.Done():
+                    return
+                }
+            }
+        }
+    }()
+    return ch
+}
+```
+
+WebSocket transport is not bundled — pair with `gorilla/websocket` or use the relay handler with a WebSocket-aware mux.
+
+## Disabling Introspection
+
+```go
+schema := graphql.MustParseSchema(sdl, &RootResolver{},
+    graphql.DisableIntrospection(),
+)
+```
+
+## Testing
+
+Use `gqltesting.RunTests`:
+
+```go
+func TestUser(t *testing.T) {
+    gqltesting.RunTests(t, []*gqltesting.Test{
+        {
+            Schema: schema,
+            Query: `{ user(id: "1") { name email } }`,
+            ExpectedResult: `{ "user": { "name": "Alice", "email": "alice@example.com" } }`,
+        },
+    })
+}
+```
+
+For HTTP-level tests, drive `relay.Handler` with `httptest.NewRecorder()`.
+
+## graph-gophers vs gqlgen Summary
+
+| Concern          | graph-gophers         | gqlgen                      |
+| ---------------- | --------------------- | --------------------------- |
+| Type safety      | Parse-time reflection | Compile-time codegen        |
+| Build complexity | None                  | `go generate` step          |
+| Performance      | Slower (reflection)   | Faster (static dispatch)    |
+| Federation       | Manual                | First-class (v2)            |
+| File uploads     | Manual                | Built-in MultipartForm      |
+| Best for         | Small/medium schemas  | Large schemas, strict teams |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/testing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/testing.md
new file mode 100644
index 00000000..b4a3ed8f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-graphql/references/testing.md
@@ -0,0 +1,180 @@
+# Testing GraphQL in Go
+
+## gqlgen — Client Harness
+
+The `github.com/99designs/gqlgen/client` package drives the full stack (directives, middleware, resolvers) via an `http.Handler`:
+
+```go
+func TestCreateUser(t *testing.T) {
+    // Build the full handler with real dependencies (use a test DB)
+    srv := handler.NewDefaultServer(graph.NewExecutableSchema(graph.Config{
+        Resolvers: &graph.Resolver{
+            DB: testDB,
+        },
+    }))
+
+    c := client.New(srv)
+
+    var resp struct {
+        CreateUser struct {
+            User struct {
+                ID    string
+                Email string
+            }
+            Errors []struct{ Message string }
+        }
+    }
+
+    c.MustPost(`
+        mutation CreateUser($email: String!, $name: String!) {
+            createUser(input: {email: $email, name: $name}) {
+                user { id email }
+                errors { message }
+            }
+        }
+    `, &resp,
+        client.Var("email", "alice@example.com"),
+        client.Var("name", "Alice"),
+        client.AddHeader("Authorization", "Bearer test-token"),
+    )
+
+    require.Empty(t, resp.CreateUser.Errors)
+    require.Equal(t, "alice@example.com", resp.CreateUser.User.Email)
+}
+```
+
+For unit testing individual resolvers, call resolver methods directly with a constructed `Resolver` and a real `context.Context` — no HTTP overhead.
+
+## gqlgen — Testing with DataLoaders
+
+Wrap the test server with the DataLoader middleware so resolver tests exercise the full batching path:
+
+```go
+srv := handler.NewDefaultServer(es)
+h := dataloaders.Middleware(testDB, srv)
+
+c := client.New(h)
+```
+
+## gqlgen — Testing Subscriptions
+
+Use `client.Subscription` to test subscription resolvers:
+
+```go
+sub := c.Subscription(`subscription { messageAdded(room: "general") { content } }`)
+defer sub.Close()
+
+// Trigger an event
+publishMessage("general", "hello")
+
+var event struct{ MessageAdded struct{ Content string } }
+err := sub.Next(&event)
+require.NoError(t, err)
+require.Equal(t, "hello", event.MessageAdded.Content)
+```
+
+## graph-gophers — gqltesting
+
+```go
+func TestUser(t *testing.T) {
+    gqltesting.RunTests(t, []*gqltesting.Test{
+        {
+            Schema: schema,
+            Query: `{ user(id: "1") { name email } }`,
+            ExpectedResult: `{"user":{"name":"Alice","email":"alice@example.com"}}`,
+        },
+        {
+            Schema:        schema,
+            Query:         `{ user(id: "999") { name } }`,
+            ExpectedErrors: []*gqlerrors.QueryError{
+                {Message: "user not found", Extensions: map[string]any{"code": "NOT_FOUND"}},
+            },
+        },
+    })
+}
+```
+
+For HTTP-level tests:
+
+```go
+func TestRelayHandler(t *testing.T) {
+    body := `{"query":"{ user(id: \"1\") { name } }"}`
+    req := httptest.NewRequest(http.MethodPost, "/graphql", strings.NewReader(body))
+    req.Header.Set("Content-Type", "application/json")
+    w := httptest.NewRecorder()
+
+    relay.Handler{Schema: schema}.ServeHTTP(w, req)
+
+    require.Equal(t, http.StatusOK, w.Code)
+    require.Contains(t, w.Body.String(), `"Alice"`)
+}
+```
+
+## Testing Error Handling
+
+Verify error extensions reach the client:
+
+```go
+var resp struct {
+    Errors []struct {
+        Message    string
+        Extensions struct{ Code string }
+    }
+}
+c.Post(`{ user(id: "999") { name } }`, &resp)
+require.Equal(t, "NOT_FOUND", resp.Errors[0].Extensions.Code)
+```
+
+## Testing Auth Directives (gqlgen)
+
+Test the directive function directly:
+
+```go
+func TestHasRoleDirective(t *testing.T) {
+    ctx := context.WithValue(context.Background(), userKey, &domain.User{Role: "USER"})
+    _, err := HasRole(ctx, nil, func(ctx context.Context) (any, error) {
+        return "ok", nil
+    }, model.RoleAdmin)
+    require.Error(t, err)
+
+    var gqlErr *gqlerror.Error
+    require.True(t, errors.As(err, &gqlErr))
+    require.Equal(t, "FORBIDDEN", gqlErr.Extensions["code"])
+}
+```
+
+## Table-Driven Tests
+
+```go
+func TestUserQueries(t *testing.T) {
+    tests := []struct {
+        name     string
+        query    string
+        vars     map[string]any
+        wantCode string
+        wantName string
+    }{
+        {"existing user", `query($id:ID!){user(id:$id){name}}`, map[string]any{"id": "1"}, "", "Alice"},
+        {"missing user", `query($id:ID!){user(id:$id){name}}`, map[string]any{"id": "999"}, "NOT_FOUND", ""},
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            var resp struct {
+                User   *struct{ Name string }
+                Errors []struct {
+                    Extensions struct{ Code string }
+                }
+            }
+            c.Post(tt.query, &resp, client.Var("id", tt.vars["id"]))
+            if tt.wantCode != "" {
+                require.Equal(t, tt.wantCode, resp.Errors[0].Extensions.Code)
+            } else {
+                require.Equal(t, tt.wantName, resp.User.Name)
+            }
+        })
+    }
+}
+```
+
+For testing patterns across the codebase, see the `samber/cc-skills-golang@golang-testing` skill.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/SKILL.md
new file mode 100644
index 00000000..6308ebd9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/SKILL.md
@@ -0,0 +1,221 @@
+---
+name: golang-grpc
+description: "Provides gRPC usage guidelines, protobuf organization, and production-ready patterns for Golang microservices. Use when implementing, reviewing, or debugging gRPC servers/clients, writing proto files, setting up interceptors, handling gRPC errors with status codes, configuring TLS/mTLS, testing with bufconn, or working with streaming RPCs."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.4"
+  openclaw:
+    emoji: "🌐"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - protoc
+    install:
+      - kind: brew
+        formula: protobuf
+        bins: [protoc]
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs Bash(protoc:*) AskUserQuestion
+---
+
+**Persona:** You are a Go distributed systems engineer. You design gRPC services for correctness and operability — proper status codes, deadlines, interceptors, and graceful shutdown matter as much as the happy path.
+
+**Modes:**
+
+- **Build mode** — implementing a new gRPC server or client from scratch.
+- **Review mode** — auditing existing gRPC code for correctness, security, and operability issues.
+
+**Dependencies:**
+
+- protoc: `brew install protobuf`
+- protoc-gen-go: `go install google.golang.org/protobuf/cmd/protoc-gen-go@latest`
+- protoc-gen-go-grpc: `go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest`
+
+# Go gRPC Best Practices
+
+Treat gRPC as a pure transport layer — keep it separate from business logic. The official Go implementation is `google.golang.org/grpc`.
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+## Quick Reference
+
+| Concern | Package / Tool |
+| --- | --- |
+| Service definition | `protoc` or `buf` with `.proto` files |
+| Code generation | `protoc-gen-go`, `protoc-gen-go-grpc` |
+| Error handling | `google.golang.org/grpc/status` with `codes` |
+| Rich error details | `google.golang.org/genproto/googleapis/rpc/errdetails` |
+| Interceptors | `grpc.ChainUnaryInterceptor`, `grpc.ChainStreamInterceptor` |
+| Middleware ecosystem | `github.com/grpc-ecosystem/go-grpc-middleware` |
+| Testing | `google.golang.org/grpc/test/bufconn` |
+| TLS / mTLS | `google.golang.org/grpc/credentials` |
+| Health checks | `google.golang.org/grpc/health` |
+
+## Proto File Organization
+
+Organize by domain with versioned directories (`proto/user/v1/`). Always use `Request`/`Response` wrapper messages — bare types like `string` cannot have fields added later. Generate with `buf generate` or `protoc`.
+
+[Proto & code generation reference](references/protoc-reference.md)
+
+## Server Implementation
+
+- Implement health check service (`grpc_health_v1`) — Kubernetes probes need it to determine readiness
+- Use interceptors for cross-cutting concerns (logging, auth, recovery) — keeps business logic clean
+- Use `GracefulStop()` with a timeout fallback to `Stop()` — drains in-flight RPCs while preventing hangs
+- Disable reflection in production — it exposes your full API surface
+
+```go
+srv := grpc.NewServer(
+    grpc.ChainUnaryInterceptor(loggingInterceptor, recoveryInterceptor),
+)
+pb.RegisterUserServiceServer(srv, svc)
+healthpb.RegisterHealthServer(srv, health.NewServer())
+
+go srv.Serve(lis)
+
+// On shutdown signal:
+stopped := make(chan struct{})
+go func() { srv.GracefulStop(); close(stopped) }()
+select {
+case <-stopped:
+case <-time.After(15 * time.Second):
+    srv.Stop()
+}
+```
+
+### Interceptor Pattern
+
+```go
+func loggingInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
+    start := time.Now()
+    resp, err := handler(ctx, req)
+    log.Printf("method=%s duration=%s code=%s", info.FullMethod, time.Since(start), status.Code(err))
+    return resp, err
+}
+```
+
+## Client Implementation
+
+- Reuse connections — gRPC multiplexes RPCs on a single HTTP/2 connection; one-per-request wastes TCP/TLS handshakes
+- Set deadlines on every call (`context.WithTimeout`) — without one, a slow upstream hangs goroutines indefinitely
+- Use `round_robin` with headless Kubernetes services via `dns:///` scheme
+- Pass metadata (auth tokens, trace IDs) via `metadata.NewOutgoingContext`
+
+```go
+conn, err := grpc.NewClient("dns:///user-service:50051",
+    grpc.WithTransportCredentials(creds),
+    grpc.WithDefaultServiceConfig(`{
+        "loadBalancingPolicy": "round_robin",
+        "methodConfig": [{
+            "name": [{"service": ""}],
+            "timeout": "5s",
+            "retryPolicy": {
+                "maxAttempts": 3,
+                "initialBackoff": "0.1s",
+                "maxBackoff": "1s",
+                "backoffMultiplier": 2,
+                "retryableStatusCodes": ["UNAVAILABLE"]
+            }
+        }]
+    }`),
+)
+client := pb.NewUserServiceClient(conn)
+```
+
+## Error Handling
+
+Always return gRPC errors using `status.Error` with a specific code — a raw `error` becomes `codes.Unknown`, telling the client nothing actionable. Clients use codes to decide retry vs fail-fast vs degrade.
+
+| Code                 | When to Use                                 |
+| -------------------- | ------------------------------------------- |
+| `InvalidArgument`    | Malformed input (missing field, bad format) |
+| `NotFound`           | Entity does not exist                       |
+| `AlreadyExists`      | Create failed, entity exists                |
+| `PermissionDenied`   | Caller lacks permission                     |
+| `Unauthenticated`    | Missing or invalid token                    |
+| `FailedPrecondition` | System not in required state                |
+| `ResourceExhausted`  | Rate limit or quota exceeded                |
+| `Unavailable`        | Transient issue, safe to retry              |
+| `Internal`           | Unexpected bug                              |
+| `DeadlineExceeded`   | Timeout                                     |
+
+```go
+// ✗ Bad — caller gets codes.Unknown, can't decide whether to retry
+return nil, fmt.Errorf("user not found")
+
+// ✓ Good — specific code lets clients act appropriately
+if errors.Is(err, ErrNotFound) {
+    return nil, status.Errorf(codes.NotFound, "user %q not found", req.UserId)
+}
+return nil, status.Errorf(codes.Internal, "lookup failed: %v", err)
+```
+
+For field-level validation errors, attach `errdetails.BadRequest` via `status.WithDetails`.
+
+## Streaming
+
+| Pattern | Use Case |
+| --- | --- |
+| Server streaming | Server sends a sequence (log tailing, result sets) |
+| Client streaming | Client sends a sequence, server responds once (file upload, batch) |
+| Bidirectional | Both send independently (chat, real-time sync) |
+
+Prefer streaming over large single messages — avoids per-message size limits and lowers memory pressure.
+
+```go
+func (s *server) ListUsers(req *pb.ListUsersRequest, stream pb.UserService_ListUsersServer) error {
+    for _, u := range users {
+        if err := stream.Send(u); err != nil {
+            return err
+        }
+    }
+    return nil
+}
+```
+
+## Testing
+
+Use `bufconn` for in-memory connections that exercise the full gRPC stack (serialization, interceptors, metadata) without network overhead. Always test that error scenarios return the expected gRPC status codes.
+
+[Testing patterns and examples](references/testing.md)
+
+## Security
+
+- TLS MUST be enabled in production — credentials travel in metadata
+- For service-to-service auth, use mTLS or delegate to a service mesh (Istio, Linkerd)
+- For user auth, implement `credentials.PerRPCCredentials` and validate tokens in an auth interceptor
+- Reflection SHOULD be disabled in production to prevent API discovery
+
+## Performance
+
+| Setting | Purpose | Typical Value |
+| --- | --- | --- |
+| `keepalive.ServerParameters.Time` | Ping interval for idle connections | 30s |
+| `keepalive.ServerParameters.Timeout` | Ping ack timeout | 10s |
+| `grpc.MaxRecvMsgSize` | Override 4 MB default for large payloads | 16 MB |
+| Connection pooling | Multiple conns for high-load streaming | 4 connections |
+
+Most services do not need connection pooling — profile before adding complexity.
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Returning raw `error` | Becomes `codes.Unknown` — client can't decide whether to retry. Use `status.Errorf` with a specific code |
+| No deadline on client calls | Slow upstream hangs indefinitely. Always `context.WithTimeout` |
+| New connection per request | Wastes TCP/TLS handshakes. Create once, reuse — HTTP/2 multiplexes RPCs |
+| Reflection enabled in production | Lets attackers enumerate every method. Enable only in dev/staging |
+| `codes.Internal` for all errors | Wrong codes break client retry logic. `Unavailable` triggers retry; `InvalidArgument` does not |
+| Bare types as RPC arguments | Can't add fields to `string`. Wrapper messages allow backwards-compatible evolution |
+| Missing health check service | Kubernetes can't determine readiness, kills pods during deployments |
+| Ignoring context cancellation | Long operations continue after caller gave up. Check `ctx.Err()` |
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-context` skill for deadline and cancellation patterns
+- → See `samber/cc-skills-golang@golang-error-handling` skill for gRPC error to Go error mapping
+- → See `samber/cc-skills-golang@golang-observability` skill for gRPC interceptors (logging, tracing, metrics)
+- → See `samber/cc-skills-golang@golang-testing` skill for gRPC testing with bufconn
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/evals/evals.json
new file mode 100644
index 00000000..061a42e2
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/evals/evals.json
@@ -0,0 +1,156 @@
+[
+  {
+    "id": 1,
+    "name": "raw-error-vs-status-error",
+    "description": "Tests that gRPC handlers return status.Errorf with specific codes, not raw errors",
+    "prompt": "Write a Go gRPC handler for GetUser that looks up a user from a repository. If the user is not found, return an appropriate error. If the repository returns an unexpected error, return that too.",
+    "trap": "Without the skill, the model may return fmt.Errorf or raw errors, which become codes.Unknown. The skill requires status.Errorf with specific codes.",
+    "assertions": [
+      {"id": "1.1", "text": "Uses status.Errorf (or status.Error) for the not-found case with codes.NotFound"},
+      {"id": "1.2", "text": "Uses status.Errorf with codes.Internal for unexpected errors"},
+      {"id": "1.3", "text": "Does NOT return a raw fmt.Errorf or errors.New as the gRPC error"},
+      {"id": "1.4", "text": "Imports google.golang.org/grpc/status and google.golang.org/grpc/codes"},
+      {"id": "1.5", "text": "Does NOT leak internal error details in the user-facing gRPC message for Internal errors"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "wrapper-messages-not-bare-types",
+    "description": "Tests that proto RPCs use Request/Response wrapper messages, not bare types",
+    "prompt": "Write a proto3 service definition for a product catalog with RPCs: GetProduct (takes product ID, returns product), DeleteProduct (takes product ID, returns nothing), SearchProducts (takes search query string, returns list of products).",
+    "trap": "Without the skill, the model may use bare types like string or google.protobuf.Empty. The skill requires Request/Response wrappers for backward-compatible evolution.",
+    "assertions": [
+      {"id": "2.1", "text": "Uses GetProductRequest/GetProductResponse wrapper messages, not bare string or Product"},
+      {"id": "2.2", "text": "Uses DeleteProductRequest/DeleteProductResponse wrapper messages, not bare string or google.protobuf.Empty"},
+      {"id": "2.3", "text": "Uses SearchProductsRequest/SearchProductsResponse wrapper messages"},
+      {"id": "2.4", "text": "Each wrapper message has properly named fields (not just a single unnamed field)"},
+      {"id": "2.5", "text": "Includes go_package option in the proto file"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "proto-directory-organization",
+    "description": "Tests proper proto file organization by domain with versioned directories",
+    "prompt": "I'm building a microservice with user management and order management. How should I organize my proto files? Show the directory layout and an example buf.gen.yaml.",
+    "trap": "Without the skill, the model may put all protos in a flat directory or skip versioning. The skill requires domain-based organization with v1 directories.",
+    "assertions": [
+      {"id": "3.1", "text": "Organizes proto files by domain (user/, order/ or similar domain grouping)"},
+      {"id": "3.2", "text": "Includes version directories (v1/ under each domain)"},
+      {"id": "3.3", "text": "Separates message definitions from service definitions (e.g. user.proto vs user_service.proto)"},
+      {"id": "3.4", "text": "Includes a shared/ or common/ directory for shared messages"},
+      {"id": "3.5", "text": "Shows buf.gen.yaml with go and go-grpc plugins configured"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "graceful-stop-with-timeout-fallback",
+    "description": "Tests proper gRPC server shutdown: GracefulStop with timeout fallback to Stop",
+    "prompt": "Write Go code for a gRPC server that handles shutdown signals properly. The server should try to drain in-flight requests before stopping.",
+    "trap": "Without the skill, the model may only call srv.Stop() or only srv.GracefulStop() without a timeout fallback. The skill requires GracefulStop with a timeout fallback to Stop.",
+    "assertions": [
+      {"id": "4.1", "text": "Calls srv.GracefulStop() first to drain in-flight RPCs"},
+      {"id": "4.2", "text": "Has a timeout mechanism that falls back to srv.Stop() if GracefulStop takes too long"},
+      {"id": "4.3", "text": "Uses a select statement or timer for the timeout"},
+      {"id": "4.4", "text": "Listens for OS signals (SIGINT, SIGTERM or os.Interrupt)"},
+      {"id": "4.5", "text": "The timeout is reasonable (5-30 seconds)"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "health-check-service-registration",
+    "description": "Tests that gRPC servers register the health check service for Kubernetes readiness probes",
+    "prompt": "Write a production-ready gRPC server setup in Go. Register a UserService and make it deployable to Kubernetes.",
+    "trap": "Without the skill, the model may not register the health check service. The skill says health check is required for Kubernetes probes.",
+    "assertions": [
+      {"id": "5.1", "text": "Registers grpc_health_v1.RegisterHealthServer (or equivalent health check service)"},
+      {"id": "5.2", "text": "Uses health.NewServer() to create the health service"},
+      {"id": "5.3", "text": "Registers interceptors using grpc.ChainUnaryInterceptor"},
+      {"id": "5.4", "text": "Does NOT enable reflection (or explicitly disables it for production)"},
+      {"id": "5.5", "text": "Includes graceful shutdown handling"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "client-connection-reuse-and-deadlines",
+    "description": "Tests that gRPC clients reuse connections and set deadlines on every call",
+    "prompt": "Write a Go gRPC client that calls a UserService. Create the client and make a GetUser call.",
+    "trap": "Without the skill, the model may create a new connection per request or not set a deadline. The skill requires connection reuse and context.WithTimeout on every call.",
+    "assertions": [
+      {"id": "6.1", "text": "Creates the connection once and reuses it (not creating a new connection per call)"},
+      {"id": "6.2", "text": "Uses context.WithTimeout (or context.WithDeadline) for the RPC call"},
+      {"id": "6.3", "text": "Uses grpc.NewClient (not the deprecated grpc.Dial)"},
+      {"id": "6.4", "text": "Includes transport credentials (TLS or explicitly insecure for dev)"},
+      {"id": "6.5", "text": "Properly defers cancel() from context.WithTimeout"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "bufconn-testing-pattern",
+    "description": "Tests that gRPC tests use bufconn for in-memory connections, not real network",
+    "prompt": "Write a test for a Go gRPC UserService that verifies GetUser returns the correct user and that requesting a non-existent user returns the proper error code.",
+    "trap": "Without the skill, the model may start a real TCP server for testing. The skill requires bufconn for in-memory connections.",
+    "assertions": [
+      {"id": "7.1", "text": "Uses bufconn.Listen for an in-memory listener"},
+      {"id": "7.2", "text": "Uses grpc.WithContextDialer with the bufconn dialer"},
+      {"id": "7.3", "text": "Verifies the gRPC status code for the not-found case using status.FromError"},
+      {"id": "7.4", "text": "Checks that the error code is codes.NotFound specifically"},
+      {"id": "7.5", "text": "Uses t.Cleanup or defer for cleaning up the server and connection"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "error-code-selection-judgment",
+    "description": "Tests correct gRPC error code selection across different scenarios",
+    "prompt": "Write a Go gRPC handler for CreateOrder that validates the request has a non-empty user_id and at least one item, checks the user exists, checks inventory availability, and creates the order. Return appropriate gRPC errors for each failure case.",
+    "trap": "Without the skill, the model may use codes.Internal for everything or pick wrong codes. The skill has a specific mapping table.",
+    "assertions": [
+      {"id": "8.1", "text": "Uses codes.InvalidArgument for missing user_id or empty items list"},
+      {"id": "8.2", "text": "Uses codes.NotFound for user not found"},
+      {"id": "8.3", "text": "Uses codes.FailedPrecondition for insufficient inventory (system not in required state)"},
+      {"id": "8.4", "text": "Uses codes.Internal only for truly unexpected errors"},
+      {"id": "8.5", "text": "Does NOT use codes.Unknown for any handled error case"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "unimplemented-server-embedding",
+    "description": "Tests that gRPC server implementations embed UnimplementedXxxServer, not UnsafeXxxServer",
+    "prompt": "Write a Go implementation of a gRPC server for an OrderService with CreateOrder and GetOrder RPCs. Show the struct definition and method signatures.",
+    "trap": "Without the skill, the model may embed UnsafeXxxServer or not embed any base server. The skill requires UnimplementedXxxServer for forward compatibility.",
+    "assertions": [
+      {"id": "9.1", "text": "Embeds UnimplementedOrderServiceServer in the server struct"},
+      {"id": "9.2", "text": "Does NOT embed UnsafeOrderServiceServer"},
+      {"id": "9.3", "text": "Implements the service methods with correct signatures (context, request pointer, response pointer and error return)"},
+      {"id": "9.4", "text": "Uses status.Errorf for error returns in the handler methods"},
+      {"id": "9.5", "text": "Registers the server with pb.RegisterOrderServiceServer"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "client-load-balancing-and-retry",
+    "description": "Tests knowledge of gRPC client-side load balancing and retry configuration",
+    "prompt": "I'm deploying a Go gRPC client in Kubernetes. The server has multiple replicas behind a headless service. How do I configure the client to distribute requests across all replicas and retry on transient failures?",
+    "trap": "Without the skill, the model may suggest a separate load balancer or basic round-robin without the dns:/// scheme. The skill shows the specific configuration.",
+    "assertions": [
+      {"id": "10.1", "text": "Uses the dns:/// scheme for service discovery with headless Kubernetes services"},
+      {"id": "10.2", "text": "Configures round_robin load balancing policy via service config"},
+      {"id": "10.3", "text": "Configures retry policy in the service config with retryableStatusCodes containing UNAVAILABLE"},
+      {"id": "10.4", "text": "Sets maxAttempts, initialBackoff, maxBackoff in the retry policy"},
+      {"id": "10.5", "text": "Does NOT suggest creating a new connection per request for load distribution"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "streaming-over-large-messages",
+    "description": "Tests preference for streaming over large single messages",
+    "prompt": "I need to send a result set of 50,000 records from a gRPC server to a client. Each record is about 1KB. What's the best approach?",
+    "trap": "Without the skill, the model may suggest increasing MaxRecvMsgSize and sending all records in one response. The skill recommends streaming to avoid per-message size limits and memory pressure.",
+    "assertions": [
+      {"id": "11.1", "text": "Recommends server streaming RPC to send records incrementally"},
+      {"id": "11.2", "text": "Explains why a single large message is problematic (size limits, memory pressure)"},
+      {"id": "11.3", "text": "Shows the server streaming pattern with stream.Send in a loop"},
+      {"id": "11.4", "text": "Client reads with stream.Recv in a loop, checking for io.EOF"},
+      {"id": "11.5", "text": "Does NOT just increase MaxRecvMsgSize as the primary solution"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/references/protoc-reference.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/references/protoc-reference.md
new file mode 100644
index 00000000..59b85855
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/references/protoc-reference.md
@@ -0,0 +1,150 @@
+# Protobuf & Code Generation Reference
+
+## Directory Layout
+
+Organize proto files by domain with versioned directories. Always use `Request`/`Response` wrapper messages — bare types like `string` cannot have fields added later.
+
+```
+proto/
+├── user/v1/
+│   ├── user.proto          # Messages
+│   └── user_service.proto  # Service RPCs
+├── order/v1/
+│   ├── order.proto
+│   └── order_service.proto
+└── shared/v1/
+    └── common.proto        # Pagination, timestamps, shared enums
+```
+
+## Proto File Conventions
+
+```protobuf
+syntax = "proto3";
+package mycompany.user.v1;
+option go_package = "github.com/mycompany/myservice/gen/user/v1;userv1";
+
+service UserService {
+  rpc GetUser(GetUserRequest) returns (GetUserResponse);
+  rpc ListUsers(ListUsersRequest) returns (ListUsersResponse);
+  rpc CreateUser(CreateUserRequest) returns (CreateUserResponse);
+  rpc UpdateUser(UpdateUserRequest) returns (UpdateUserResponse);
+  rpc DeleteUser(DeleteUserRequest) returns (DeleteUserResponse);
+}
+
+message GetUserRequest {
+  string user_id = 1;
+}
+
+message GetUserResponse {
+  User user = 1;
+}
+
+message ListUsersRequest {
+  int32 page_size = 1;
+  string page_token = 2;
+}
+
+message ListUsersResponse {
+  repeated User users = 1;
+  string next_page_token = 2;
+}
+```
+
+### `go_package` conventions
+
+- Format: `"import/path;alias"` — the alias becomes the Go package name
+- Convention: lowercase version suffix (e.g. `userv1`, `orderv1`)
+- Generate into a `gen/` directory to keep generated code separate from hand-written code
+
+## Code Generation with `protoc`
+
+```bash
+# Basic generation
+protoc --go_out=gen --go_opt=paths=source_relative \
+       --go-grpc_out=gen --go-grpc_opt=paths=source_relative \
+       proto/user/v1/*.proto
+
+# With validation (using buf-validate)
+protoc --go_out=gen --go_opt=paths=source_relative \
+       --go-grpc_out=gen --go-grpc_opt=paths=source_relative \
+       --validate_out="lang=go:gen" \
+       proto/user/v1/*.proto
+
+# Include external imports
+protoc -I proto -I third_party \
+       --go_out=gen --go_opt=paths=source_relative \
+       --go-grpc_out=gen --go-grpc_opt=paths=source_relative \
+       proto/user/v1/*.proto
+```
+
+### Common `protoc` flags
+
+| Flag                             | Purpose                                 |
+| -------------------------------- | --------------------------------------- |
+| `--go_out=DIR`                   | Output directory for message types      |
+| `--go-grpc_out=DIR`              | Output directory for service stubs      |
+| `--go_opt=paths=source_relative` | Place output relative to proto source   |
+| `-I DIR`                         | Add import path for proto dependencies  |
+| `--descriptor_set_out=FILE`      | Emit binary descriptor (for reflection) |
+
+## Code Generation with `buf`
+
+`buf` is the recommended modern alternative to raw `protoc`. It manages dependencies, lints protos, and generates code from a single config.
+
+### `buf.gen.yaml`
+
+```yaml
+version: v2
+plugins:
+  - remote: buf.build/protocolbuffers/go
+    out: gen
+    opt: paths=source_relative
+  - remote: buf.build/grpc/go
+    out: gen
+    opt: paths=source_relative
+```
+
+### `buf.yaml`
+
+```yaml
+version: v2
+modules:
+  - path: proto
+lint:
+  use:
+    - STANDARD
+breaking:
+  use:
+    - FILE
+```
+
+### Common `buf` commands
+
+```bash
+buf generate              # Generate code from buf.gen.yaml
+buf lint                  # Lint proto files
+buf breaking --against '.git#branch=main'  # Check backward compatibility
+buf dep update            # Update dependencies
+buf build                 # Validate proto files compile
+```
+
+## Generated Code Patterns
+
+After generation, import and use the generated code:
+
+```go
+import (
+    userv1 "github.com/mycompany/myservice/gen/user/v1"
+)
+
+// Server: implement the interface
+type userServer struct {
+    userv1.UnimplementedUserServiceServer
+}
+
+// Client: use the generated client
+client := userv1.NewUserServiceClient(conn)
+resp, err := client.GetUser(ctx, &userv1.GetUserRequest{UserId: "123"})
+```
+
+Always embed `Unimplemented*Server` (not `Unsafe*Server`) — it provides forward compatibility when new RPCs are added to the proto definition.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/references/testing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/references/testing.md
new file mode 100644
index 00000000..22606d7b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-grpc/references/testing.md
@@ -0,0 +1,270 @@
+# gRPC Testing Reference
+
+## Testing with `bufconn`
+
+`bufconn` creates in-memory connections that exercise the full gRPC stack (serialization, interceptors, metadata) without network overhead. This is the standard approach for gRPC unit and integration tests.
+
+### Basic Setup
+
+```go
+func setupTest(t *testing.T) pb.UserServiceClient {
+    t.Helper()
+    lis := bufconn.Listen(1024 * 1024)
+    t.Cleanup(func() { lis.Close() })
+
+    srv := grpc.NewServer()
+    pb.RegisterUserServiceServer(srv, newTestService())
+    t.Cleanup(func() { srv.Stop() })
+    go srv.Serve(lis)
+
+    conn, err := grpc.NewClient("passthrough:///bufconn",
+        grpc.WithContextDialer(func(ctx context.Context, _ string) (net.Conn, error) {
+            return lis.DialContext(ctx)
+        }),
+        grpc.WithTransportCredentials(insecure.NewCredentials()),
+    )
+    if err != nil {
+        t.Fatalf("dial: %v", err)
+    }
+    t.Cleanup(func() { conn.Close() })
+    return pb.NewUserServiceClient(conn)
+}
+```
+
+### Setup with Interceptors
+
+Test your interceptors by including them in the test server:
+
+```go
+func setupTestWithInterceptors(t *testing.T) pb.UserServiceClient {
+    t.Helper()
+    lis := bufconn.Listen(1024 * 1024)
+    t.Cleanup(func() { lis.Close() })
+
+    srv := grpc.NewServer(
+        grpc.ChainUnaryInterceptor(
+            loggingInterceptor,
+            authInterceptor,
+            recoveryInterceptor,
+        ),
+    )
+    pb.RegisterUserServiceServer(srv, newTestService())
+    t.Cleanup(func() { srv.Stop() })
+    go srv.Serve(lis)
+
+    conn, err := grpc.NewClient("passthrough:///bufconn",
+        grpc.WithContextDialer(func(ctx context.Context, _ string) (net.Conn, error) {
+            return lis.DialContext(ctx)
+        }),
+        grpc.WithTransportCredentials(insecure.NewCredentials()),
+    )
+    if err != nil {
+        t.Fatalf("dial: %v", err)
+    }
+    t.Cleanup(func() { conn.Close() })
+    return pb.NewUserServiceClient(conn)
+}
+```
+
+## Testing Error Codes
+
+Always verify that RPCs return the expected gRPC status codes — clients rely on codes for retry and error-handling logic.
+
+```go
+func TestGetUser_NotFound(t *testing.T) {
+    client := setupTest(t)
+    _, err := client.GetUser(context.Background(), &pb.GetUserRequest{UserId: "nonexistent"})
+
+    st, ok := status.FromError(err)
+    if !ok {
+        t.Fatalf("expected gRPC status error, got: %v", err)
+    }
+    if st.Code() != codes.NotFound {
+        t.Errorf("expected NotFound, got %s: %s", st.Code(), st.Message())
+    }
+}
+```
+
+### Table-Driven Error Code Tests
+
+```go
+func TestGetUser_Errors(t *testing.T) {
+    client := setupTest(t)
+
+    tests := []struct {
+        name     string
+        req      *pb.GetUserRequest
+        wantCode codes.Code
+    }{
+        {
+            name:     "empty user ID",
+            req:      &pb.GetUserRequest{UserId: ""},
+            wantCode: codes.InvalidArgument,
+        },
+        {
+            name:     "user not found",
+            req:      &pb.GetUserRequest{UserId: "nonexistent"},
+            wantCode: codes.NotFound,
+        },
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            _, err := client.GetUser(context.Background(), tt.req)
+            st, ok := status.FromError(err)
+            if !ok {
+                t.Fatalf("expected gRPC status error, got: %v", err)
+            }
+            if st.Code() != tt.wantCode {
+                t.Errorf("code = %s, want %s; message: %s", st.Code(), tt.wantCode, st.Message())
+            }
+        })
+    }
+}
+```
+
+## Testing Streaming RPCs
+
+### Server Streaming
+
+```go
+func TestListUsers_Stream(t *testing.T) {
+    client := setupTest(t)
+    stream, err := client.ListUsers(context.Background(), &pb.ListUsersRequest{})
+    if err != nil {
+        t.Fatalf("ListUsers: %v", err)
+    }
+
+    var users []*pb.User
+    for {
+        user, err := stream.Recv()
+        if err == io.EOF {
+            break
+        }
+        if err != nil {
+            t.Fatalf("Recv: %v", err)
+        }
+        users = append(users, user)
+    }
+
+    if len(users) != 3 {
+        t.Errorf("got %d users, want 3", len(users))
+    }
+}
+```
+
+### Client Streaming
+
+```go
+func TestBatchCreate_ClientStream(t *testing.T) {
+    client := setupTest(t)
+    stream, err := client.BatchCreateUsers(context.Background())
+    if err != nil {
+        t.Fatalf("BatchCreateUsers: %v", err)
+    }
+
+    for _, u := range testUsers {
+        if err := stream.Send(u); err != nil {
+            t.Fatalf("Send: %v", err)
+        }
+    }
+
+    resp, err := stream.CloseAndRecv()
+    if err != nil {
+        t.Fatalf("CloseAndRecv: %v", err)
+    }
+    if resp.Created != int32(len(testUsers)) {
+        t.Errorf("created = %d, want %d", resp.Created, len(testUsers))
+    }
+}
+```
+
+## Testing Metadata
+
+Verify that interceptors correctly read/write metadata:
+
+```go
+func TestAuth_Metadata(t *testing.T) {
+    client := setupTestWithInterceptors(t)
+
+    // Without auth token → Unauthenticated
+    _, err := client.GetUser(context.Background(), &pb.GetUserRequest{UserId: "1"})
+    if st, _ := status.FromError(err); st.Code() != codes.Unauthenticated {
+        t.Errorf("expected Unauthenticated without token, got %s", st.Code())
+    }
+
+    // With valid token → success
+    md := metadata.Pairs("authorization", "Bearer valid-token")
+    ctx := metadata.NewOutgoingContext(context.Background(), md)
+    resp, err := client.GetUser(ctx, &pb.GetUserRequest{UserId: "1"})
+    if err != nil {
+        t.Fatalf("expected success with valid token: %v", err)
+    }
+    if resp.User == nil {
+        t.Error("expected user in response")
+    }
+}
+```
+
+## Testing Deadlines
+
+```go
+func TestGetUser_DeadlineExceeded(t *testing.T) {
+    client := setupTest(t) // server handler sleeps for 5s
+
+    ctx, cancel := context.WithTimeout(context.Background(), 50*time.Millisecond)
+    defer cancel()
+
+    _, err := client.GetUser(ctx, &pb.GetUserRequest{UserId: "slow"})
+    st, _ := status.FromError(err)
+    if st.Code() != codes.DeadlineExceeded {
+        t.Errorf("expected DeadlineExceeded, got %s", st.Code())
+    }
+}
+```
+
+## Integration Test Patterns
+
+For tests that hit real dependencies (database, external services), use build tags to separate them:
+
+```go
+//go:build integration
+
+func TestUserService_Integration(t *testing.T) {
+    // Connect to real gRPC server
+    conn, err := grpc.NewClient("localhost:50051",
+        grpc.WithTransportCredentials(insecure.NewCredentials()),
+    )
+    if err != nil {
+        t.Fatalf("dial: %v", err)
+    }
+    defer conn.Close()
+
+    client := pb.NewUserServiceClient(conn)
+
+    // Test full roundtrip
+    created, err := client.CreateUser(context.Background(), &pb.CreateUserRequest{
+        Name:  "integration-test",
+        Email: "test@example.com",
+    })
+    if err != nil {
+        t.Fatalf("CreateUser: %v", err)
+    }
+
+    got, err := client.GetUser(context.Background(), &pb.GetUserRequest{
+        UserId: created.User.Id,
+    })
+    if err != nil {
+        t.Fatalf("GetUser: %v", err)
+    }
+    if got.User.Name != "integration-test" {
+        t.Errorf("name = %q, want %q", got.User.Name, "integration-test")
+    }
+}
+```
+
+Run integration tests separately:
+
+```bash
+go test -tags=integration ./...
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/SKILL.md
new file mode 100644
index 00000000..c47b09e1
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/SKILL.md
@@ -0,0 +1,108 @@
+---
+name: golang-how-to
+description: "Golang skills orchestrator — always active on any Golang coding, review, debug, or setup task. Reads the task context and loads the most relevant skills from samber/cc-skills-golang, often multiple at once: writing a gRPC service loads golang-grpc + golang-testing + golang-error-handling; debugging a panic loads golang-troubleshooting + golang-safety; auditing security loads golang-security + golang-lint + golang-safety. Also: disambiguates competing clusters when two skills seem to overlap (performance vs benchmark vs troubleshooting, samber/lo vs mo vs ro, DI cluster, safety vs security), and configures CLAUDE.md or AGENTS.md to force-trigger skills in a project (/golang-how-to configure)."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents. Requires git.
+metadata:
+  author: samber
+  version: "1.0.0"
+  openclaw:
+    emoji: "🧭"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(git:*) Agent AskUserQuestion
+---
+
+**Persona:** You are a Go skills orchestrator. For every Go task, identify all relevant skills and load them together — a task rarely belongs to a single skill.
+
+**Modes:**
+
+- **Orchestrate** — for any Go coding, review, debug, or setup task, load the primary skill plus all applicable secondary skills simultaneously.
+- **Disambiguate** — when two skills seem to overlap, show the boundary table. See [disambiguation.md](references/disambiguation.md).
+- **Configure** — add a `## Required Go skills` block to the project's `CLAUDE.md` or `AGENTS.md`. Follow [project-config.md](references/project-config.md).
+
+## Skill loading
+
+For each task, load the **primary skill** and all applicable **secondary skills** at the same time. Do not wait — load them together at the start.
+
+| Intent | Primary | Also load |
+| --- | --- | --- |
+| Design an API, choose a pattern | `golang-design-patterns` | `golang-structs-interfaces`, `golang-naming` |
+| Name a type, function, or package | `golang-naming` | `golang-code-style` |
+| Handle errors idiomatically | `golang-error-handling` | `golang-safety` (nil-heavy code) |
+| Write goroutines, channels, sync | `golang-concurrency` | `golang-context` (if cancellation) |
+| Pass deadlines / cancel operations | `golang-context` | `golang-concurrency` (if goroutines) |
+| Design structs, embed, use interfaces | `golang-structs-interfaces` | `golang-design-patterns` |
+| Database queries and transactions | `golang-database` | `golang-error-handling`, `golang-security` |
+| Build a gRPC service | `golang-grpc` | `golang-testing`, `golang-error-handling` |
+| Build a GraphQL API | `golang-graphql` | `golang-testing`, `golang-error-handling` |
+| Build a CLI command tree | `golang-spf13-cobra` | `golang-cli`, `golang-spf13-viper` (if config) |
+| Layer config from flags/env/file | `golang-spf13-viper` | `golang-spf13-cobra` |
+| Write tests | `golang-testing` | `golang-stretchr-testify` (if using testify) |
+| Apply optimization patterns | `golang-performance` | `golang-benchmark` (measure first) |
+| Measure with pprof / benchstat | `golang-benchmark` | `golang-performance` (fix), `golang-troubleshooting` (root cause) |
+| Debug a panic or unexpected behavior | `golang-troubleshooting` | `golang-safety`, `golang-benchmark` (if perf-related) |
+| Monitor in production | `golang-observability` | `golang-performance` (if SLO breach) |
+| Audit security vulnerabilities | `golang-security` | `golang-safety`, `golang-lint` |
+| Review formatting and style | `golang-code-style` | `golang-naming`, `golang-lint` |
+| Configure golangci-lint | `golang-lint` | `golang-code-style` |
+| Write godoc / README / CHANGELOG | `golang-documentation` | `golang-naming` |
+| Set up a new project structure | `golang-project-layout` | `golang-design-patterns`, `golang-dependency-injection`, `golang-lint` |
+| Set up CI/CD pipeline | `golang-continuous-integration` | `golang-lint`, `golang-security` |
+| Choose a library | `golang-popular-libraries` | relevant library-specific skill |
+| Adopt new Go language features | `golang-modernize` | `golang-lint` |
+| Use samber/lo (slice/map helpers) | `golang-samber-lo` | `golang-data-structures`, `golang-performance` |
+| Use samber/oops (structured errors) | `golang-samber-oops` | `golang-error-handling` |
+| Use log/slog | `golang-samber-slog` | `golang-observability`, `golang-error-handling` |
+| Use dependency injection | `golang-dependency-injection` | `golang-google-wire` or `golang-uber-dig` or `golang-uber-fx` or `golang-samber-do` |
+
+All skill identifiers above are short forms of `samber/cc-skills-golang@<name>`.
+
+## Categories at a glance
+
+Full catalog with "use when" hooks: [by-category.md](references/by-category.md)
+
+| Category | Skills |
+| --- | --- |
+| Code Quality | `golang-code-style` `golang-documentation` `golang-error-handling` `golang-lint` `golang-naming` `golang-safety` `golang-security` `golang-structs-interfaces` |
+| Architecture & Design | `golang-concurrency` `golang-context` `golang-data-structures` `golang-database` `golang-dependency-injection` `golang-design-patterns` `golang-modernize` |
+| QA & Performance | `golang-benchmark` `golang-observability` `golang-performance` `golang-testing` `golang-troubleshooting` |
+| Project Setup | `golang-cli` `golang-continuous-integration` `golang-dependency-management` `golang-popular-libraries` `golang-project-layout` `golang-stay-updated` |
+| APIs | `golang-graphql` `golang-grpc` `golang-swagger` |
+| Dependency Injection | `golang-dependency-injection` `golang-google-wire` `golang-uber-dig` `golang-uber-fx` `golang-samber-do` |
+| Frameworks | `golang-spf13-cobra` `golang-spf13-viper` |
+| samber/\* | `golang-samber-do` `golang-samber-hot` `golang-samber-lo` `golang-samber-mo` `golang-samber-oops` `golang-samber-ro` `golang-samber-slog` |
+| Testing | `golang-stretchr-testify` `golang-testing` |
+
+## Competing clusters — boundary lines
+
+Full boundary tables with routing examples: [disambiguation.md](references/disambiguation.md)
+
+Key clusters and their owners:
+
+- **Performance**: `golang-performance` (optimization patterns) · `golang-benchmark` (measurement) · `golang-troubleshooting` (root cause) · `golang-observability` (always-on production)
+- **DI**: `golang-dependency-injection` (concepts/decision) · `golang-google-wire` (compile-time) · `golang-uber-dig` (runtime reflection) · `golang-uber-fx` (lifecycle framework) · `golang-samber-do` (type-safe container)
+- **samber/\***: `golang-samber-lo` (finite transforms) · `golang-samber-ro` (reactive streams) · `golang-samber-mo` (monadic types)
+- **Errors**: `golang-error-handling` (idioms) · `golang-samber-oops` (structured errors) · `golang-safety` (prevent panics)
+- **Style**: `golang-code-style` · `golang-naming` · `golang-lint` · `golang-documentation`
+- **CLI**: `golang-cli` (architecture) · `golang-spf13-cobra` (command tree) · `golang-spf13-viper` (config layering)
+- **Gap — type vs arch**: `golang-structs-interfaces` (type design) vs `golang-design-patterns` (architectural patterns)
+- **Gap — goroutine vs cancel**: `golang-concurrency` + `golang-context` — load both when cancelling goroutines via context
+- **Gap — correctness vs threat**: `golang-safety` (internal bugs) vs `golang-security` (external threats)
+- **Gap — features vs rules**: `golang-modernize` (language adoption) vs `golang-lint` (static analysis config)
+
+## Configure mode
+
+Force-trigger specific skills in a project's `CLAUDE.md` or `AGENTS.md` so they always load.
+
+When invoked as `/golang-how-to configure`, follow [project-config.md](references/project-config.md).
+
+---
+
+This skill is not exhaustive. Refer to individual skill files and the official Go documentation for detailed guidance.
+
+If you encounter a bug or unexpected behavior in this skill plugin, open an issue at <https://github.com/samber/cc-skills-golang/issues>.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/by-category.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/by-category.md
new file mode 100644
index 00000000..0ef43545
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/by-category.md
@@ -0,0 +1,375 @@
+# Golang skills — full catalog by category
+
+42 skills. Skills marked ⭐️ are recommended for all Go projects. Skills marked ⚙️ can be superseded by a company-specific skill.
+
+---
+
+## Code Quality
+
+### `samber/cc-skills-golang@golang-code-style` ⭐️ ⚙️
+
+Golang code formatting, conventions, and project-level style consistency — gofmt, goimports, line length, var declarations, blank lines, comment heuristics.
+
+Use when: the user asks about formatting rules, style review, or project coding standards. Not for naming conventions (→ `golang-naming`), linter configuration (→ `golang-lint`), or doc comments (→ `golang-documentation`).
+
+---
+
+### `samber/cc-skills-golang@golang-documentation` ⭐️ ⚙️
+
+Golang documentation standards — package docs, godoc conventions, example functions, README structure, CHANGELOG, llms.txt, API reference generation.
+
+Use when: writing or reviewing Go doc comments, README files, or API reference. Not for code comments that explain logic (→ `golang-code-style`).
+
+---
+
+### `samber/cc-skills-golang@golang-error-handling` ⭐️ ⚙️
+
+Golang error handling best practices — error creation, wrapping with fmt.Errorf and errors.Is/As, sentinel errors, custom error types, panic recovery.
+
+Use when: writing or reviewing error propagation, wrapping, logging, or recovery patterns. For samber/oops specifics → `golang-samber-oops`. For preventing panics → `golang-safety`.
+
+---
+
+### `samber/cc-skills-golang@golang-lint`
+
+Golang linting — golangci-lint configuration, presets, custom rules, CI integration, nolint suppressions, linter selection and output interpretation.
+
+Use when: setting up or tuning golangci-lint, interpreting lint failures, or deciding which linters to enable. For style conventions not enforced by linters → `golang-code-style`.
+
+---
+
+### `samber/cc-skills-golang@golang-naming` ⭐️ ⚙️
+
+Golang naming conventions across all identifier types — packages, constructors, structs, interfaces, constants, errors, receivers, acronyms, test functions. Covers MixedCaps rules, Get-prefix, and utils/helpers anti-patterns.
+
+Use when: naming a new type, function, package, or constant. Not for broader formatting (→ `golang-code-style`).
+
+---
+
+### `samber/cc-skills-golang@golang-safety` ⭐️
+
+Defensive Golang coding — prevents panics, silent data corruption, and runtime bugs. Nil safety, append aliasing, map concurrent access, float comparison, zero-value design, numeric overflow.
+
+Use when: writing or reviewing code that could silently produce wrong results or panic. Not for external threats (→ `golang-security`) or error handling idioms (→ `golang-error-handling`).
+
+---
+
+### `samber/cc-skills-golang@golang-security` ⭐️ 🧠
+
+Golang security best practices — injection prevention (SQL, command, XSS), cryptography, filesystem/network safety, secrets management, cookie security, tool configuration. Audit and review modes.
+
+Use when: auditing a codebase for vulnerabilities, writing security-sensitive code, or reviewing auth/crypto/secrets handling. Not for runtime correctness bugs (→ `golang-safety`).
+
+---
+
+### `samber/cc-skills-golang@golang-structs-interfaces` ⚙️
+
+Golang struct and interface design — composition, embedding, type assertions, interface segregation, struct tags (JSON/YAML/DB), pointer vs value receivers.
+
+Use when: designing types, choosing between value vs pointer receivers, writing struct tags, or working with interface hierarchies. For architectural patterns that use interfaces → `golang-design-patterns`.
+
+---
+
+## Architecture & Design
+
+### `samber/cc-skills-golang@golang-concurrency` ⚙️
+
+Golang concurrency patterns — goroutines, channels, sync primitives, context cancellation, worker pools, fan-out/fan-in, pipelines, errgroup.
+
+Use when: writing concurrent code, coordinating goroutines, or reviewing for race conditions. For context propagation specifically → `golang-context`. When cancelling goroutines via context — load both.
+
+---
+
+### `samber/cc-skills-golang@golang-context` ⚙️
+
+Idiomatic context.Context usage — creation, cancellation, timeouts, values, propagation patterns, WithoutCancel, common anti-patterns.
+
+Use when: propagating deadlines and cancellation signals, or passing request-scoped values. Not for code that merely accepts ctx as first parameter.
+
+---
+
+### `samber/cc-skills-golang@golang-data-structures` ⭐️
+
+Golang data structures internals and usage — slices (capacity growth, append aliasing), maps, channels, sync primitives, container/\*, generic collections, and when to use each.
+
+Use when: choosing a data structure, understanding slice/map performance characteristics, or using container/list, container/heap, or ring.
+
+---
+
+### `samber/cc-skills-golang@golang-database` ⭐️ ⚙️
+
+Golang database access patterns — parameter binding, connection pooling, transactions, migrations, sqlboiler/sqlc code generation, query builders.
+
+Use when: writing SQL queries, designing repository patterns, or configuring database connections. For security aspects of queries (injection) → also consult `golang-security`.
+
+---
+
+### `samber/cc-skills-golang@golang-dependency-injection` ⚙️
+
+Dependency injection patterns in Golang — constructor injection, interface-based DI, wire/dig/fx comparison, and when DI is worth the complexity.
+
+Use when: deciding whether to use DI, designing constructor signatures, or comparing DI libraries. For a specific DI library → `golang-google-wire`, `golang-uber-dig`, `golang-uber-fx`, or `golang-samber-do`.
+
+---
+
+### `samber/cc-skills-golang@golang-design-patterns` ⭐️ ⚙️
+
+Idiomatic Golang design patterns — functional options, constructors, builder pattern, middleware chains, circuit breaker, and architecture guides.
+
+Use when: choosing architectural patterns, designing APIs, or implementing resilience patterns. For type-level design (embedding, receivers) → `golang-structs-interfaces`.
+
+---
+
+### `samber/cc-skills-golang@golang-modernize` ⭐️
+
+Modernize Golang code using recent language features — range-over-int, min/max builtins, iterators, slices/maps/cmp/slog stdlib packages, testing patterns (t.Context, b.Loop, synctest), and tooling upgrades.
+
+Use when: upgrading a codebase to a newer Go version or replacing pre-generics patterns. Not for lint rule enforcement (→ `golang-lint`).
+
+---
+
+## QA & Performance
+
+### `samber/cc-skills-golang@golang-benchmark` 🧠
+
+Golang benchmarking, profiling, and performance measurement — pprof, trace, CPU/memory/block profiles, flame graphs, benchstat, CI regression detection, continuous profiling.
+
+Use when: measuring performance, capturing profiles, comparing benchmark runs, or setting up CI regression detection. For applying optimization patterns → `golang-performance`. For debugging a crash → `golang-troubleshooting`.
+
+---
+
+### `samber/cc-skills-golang@golang-observability` ⚙️
+
+Golang production observability — structured logging (slog), Prometheus metrics, OpenTelemetry tracing, pprof profiling endpoints, alerting, Grafana dashboards.
+
+Use when: instrumenting a service for production monitoring. Not for temporary deep-dive investigation (→ `golang-benchmark`, `golang-performance`).
+
+---
+
+### `samber/cc-skills-golang@golang-performance` 🧠
+
+Golang performance optimization — allocation reduction, CPU efficiency, memory layout, GC tuning, pooling, caching, hot-path optimization.
+
+Use when: applying optimization patterns after profiling. Not for measurement methodology (→ `golang-benchmark`) or debugging workflow (→ `golang-troubleshooting`).
+
+---
+
+### `samber/cc-skills-golang@golang-testing` ⭐️ 🧠 ⚙️
+
+Production-ready Golang tests — table-driven tests, fuzzing, fixtures, goroutine leak detection (goleak), snapshot testing, code coverage, integration tests, parallel tests.
+
+Use when: writing or reviewing tests. For testify-specific APIs → `golang-stretchr-testify`. For measurement methodology → `golang-benchmark`.
+
+---
+
+### `samber/cc-skills-golang@golang-troubleshooting` ⭐️ 🧠
+
+Systematic Golang debugging — common pitfalls, test-driven debugging, pprof capture, Delve debugger, race detection, GODEBUG tracing, production debugging.
+
+Use when: debugging a panic, unexpected output, or hard-to-reproduce bug. Not for interpreting profiles (→ `golang-benchmark`) or applying optimization patterns (→ `golang-performance`).
+
+---
+
+## Project Setup
+
+### `samber/cc-skills-golang@golang-cli`
+
+Golang CLI application development — project layout, exit codes, signal handling, I/O patterns, argument parsing, terminal UX.
+
+Use when: building a CLI tool from scratch. For cobra-specific APIs → `golang-spf13-cobra`. For viper configuration → `golang-spf13-viper`.
+
+---
+
+### `samber/cc-skills-golang@golang-continuous-integration`
+
+CI/CD pipeline configuration for Golang projects using GitHub Actions — build, test, lint, and release workflows.
+
+Use when: setting up or improving a CI pipeline for a Go project.
+
+---
+
+### `samber/cc-skills-golang@golang-dependency-management`
+
+Golang module dependency strategies — go.mod conventions, versioning, replace directives, tool dependencies, and multi-module workspaces.
+
+Use when: managing go.mod, dealing with replace directives, or structuring a multi-module repo.
+
+---
+
+### `samber/cc-skills-golang@golang-popular-libraries`
+
+Curated recommendations for production-ready Golang libraries — when the stdlib is enough vs when to reach for a package.
+
+Use when: choosing a library for a new concern (HTTP, logging, testing, etc.). For deep guidance on a specific library → use the library-specific skill.
+
+---
+
+### `samber/cc-skills-golang@golang-project-layout`
+
+Golang project structure and workspace setup — cmd/internal/pkg conventions, monorepo layout, CLI project structure, and when to keep things flat.
+
+Use when: starting a new project or restructuring an existing one. For architectural patterns within the project → `golang-design-patterns`.
+
+---
+
+### `samber/cc-skills-golang@golang-stay-updated`
+
+Resources to stay current with Golang — official channels, community hubs, key people to follow, learning resources.
+
+Use when: looking for ways to track Go releases, proposals, and community news.
+
+---
+
+## APIs
+
+### `samber/cc-skills-golang@golang-graphql`
+
+GraphQL API development in Golang using gqlgen/graphql-go — schema definition, resolvers, subscriptions, dataloader, federation.
+
+Use when: building a GraphQL API in Go.
+
+---
+
+### `samber/cc-skills-golang@golang-grpc`
+
+gRPC in Golang — protobuf organization, service definitions, streaming, interceptors, error codes, code generation workflow.
+
+Use when: building or consuming a gRPC service. For OpenAPI/REST documentation → `golang-swagger`.
+
+---
+
+### `samber/cc-skills-golang@golang-swagger`
+
+OpenAPI/Swagger docs with swaggo/swag — annotation comments, code generation, framework integrations (gin, echo, fiber, chi), security definitions.
+
+Use when: generating OpenAPI documentation from Go code annotations.
+
+---
+
+## Dependency Injection
+
+### `samber/cc-skills-golang@golang-dependency-injection` ⚙️
+
+See "Architecture & Design" section above.
+
+---
+
+### `samber/cc-skills-golang@golang-google-wire`
+
+Compile-time dependency injection with google/wire — provider sets, injector generation, wire.Build, and structured DI patterns.
+
+Use when: the codebase imports `github.com/google/wire` or the team has chosen compile-time DI. For runtime DI with reflection → `golang-uber-dig`.
+
+---
+
+### `samber/cc-skills-golang@golang-uber-dig`
+
+Reflection-based DI with uber-go/dig — Provide/Invoke, dig.In/dig.Out, named values, value groups, optional dependencies, Decorate.
+
+Use when: the codebase imports `go.uber.org/dig`. For higher-level lifecycle and modules → `golang-uber-fx`.
+
+---
+
+### `samber/cc-skills-golang@golang-uber-fx`
+
+Application framework with uber-go/fx — fx.New, fx.Provide/Invoke, fx.Module, lifecycle hooks, fx.Annotate, fx.Decorate, signal-aware Run.
+
+Use when: the codebase imports `go.uber.org/fx`. For raw DI without lifecycle → `golang-uber-dig`.
+
+---
+
+### `samber/cc-skills-golang@golang-samber-do`
+
+Dependency injection with samber/do — type-safe service containers, lifecycle management, scopes, health checks, graceful shutdown.
+
+Use when: the codebase imports `github.com/samber/do`.
+
+---
+
+## Frameworks
+
+### `samber/cc-skills-golang@golang-spf13-cobra`
+
+CLI command trees with spf13/cobra — command hierarchy, RunE hooks, flag management, shell completion, usage templates, testing with SetArgs.
+
+Use when: the codebase imports `github.com/spf13/cobra`. For configuration layering → `golang-spf13-viper`. For general CLI architecture → `golang-cli`.
+
+---
+
+### `samber/cc-skills-golang@golang-spf13-viper`
+
+Layered configuration with spf13/viper — flag > env > file > KV > default precedence, BindPFlag, hot reload, test isolation, remote KV integration.
+
+Use when: the codebase imports `github.com/spf13/viper`. For CLI command structure → `golang-spf13-cobra`. For general CLI architecture → `golang-cli`.
+
+---
+
+## samber/\*
+
+### `samber/cc-skills-golang@golang-samber-do`
+
+See "Dependency Injection" section above.
+
+---
+
+### `samber/cc-skills-golang@golang-samber-hot`
+
+In-memory caching with samber/hot — 9 eviction algorithms (LRU, LFU, TinyLFU, W-TinyLFU, S3FIFO, ARC, SIEVE), TTL, loaders, sharding, stale-while-revalidate, Prometheus metrics.
+
+Use when: the codebase imports `github.com/samber/hot`.
+
+---
+
+### `samber/cc-skills-golang@golang-samber-lo`
+
+Functional programming helpers with samber/lo — 500+ type-safe generic functions for slices, maps, channels, strings. Immutable (lo), parallel (lop), mutable (lom), iterators (loi), SIMD.
+
+Use when: the codebase imports `github.com/samber/lo`. Not for streaming pipelines (→ `golang-samber-ro`).
+
+---
+
+### `samber/cc-skills-golang@golang-samber-mo` 🧠
+
+Monadic types with samber/mo — Option, Result, Either, Future, IO, Task, State for type-safe nullable values, error handling, and functional composition.
+
+Use when: the codebase imports `github.com/samber/mo`.
+
+---
+
+### `samber/cc-skills-golang@golang-samber-oops`
+
+Structured error handling with samber/oops — error builders, stack traces, error codes, context attributes, public vs developer messages, panic recovery, APM integration.
+
+Use when: the codebase imports `github.com/samber/oops`.
+
+---
+
+### `samber/cc-skills-golang@golang-samber-ro` 🧠
+
+Reactive streams with samber/ro — 150+ type-safe operators, cold/hot observables, 5 subject types, 40+ plugins, automatic backpressure, Go context integration.
+
+Use when: the codebase imports `github.com/samber/ro`. Not for finite slice transforms (→ `golang-samber-lo`).
+
+---
+
+### `samber/cc-skills-golang@golang-samber-slog`
+
+Structured logging pipeline with samber/slog-\* packages — multi-handler routing (slog-multi), sampling, formatting, HTTP middleware, 20+ backend sinks.
+
+Use when: the codebase imports any `github.com/samber/slog-*` package.
+
+---
+
+## Testing
+
+### `samber/cc-skills-golang@golang-stretchr-testify`
+
+Testing with stretchr/testify — assert, require, mock, and suite packages. Assertions, mock expectations, argument matchers, suite lifecycle, custom matchers.
+
+Use when: the codebase imports `github.com/stretchr/testify`. For test architecture and strategy → `golang-testing`.
+
+---
+
+### `samber/cc-skills-golang@golang-testing` ⭐️ 🧠 ⚙️
+
+See "QA & Performance" section above.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/disambiguation.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/disambiguation.md
new file mode 100644
index 00000000..0ace2cf9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/disambiguation.md
@@ -0,0 +1,216 @@
+# Competing clusters — deep disambiguation
+
+Eleven clusters where skills overlap. Each cluster includes a boundary table, concrete routing examples, and notes on gap cases not yet explicit in source skill descriptions.
+
+---
+
+## 1. Performance cluster
+
+Four skills form a "deep analysis" cluster. `golang-observability` is the always-on counterpart; the other three are activated on demand.
+
+| Skill | Unique territory | Does NOT own |
+| --- | --- | --- |
+| `samber/cc-skills-golang@golang-performance` | Optimization patterns — "if allocation bottleneck → use sync.Pool", "if hot-path → avoid reflection" | Measurement, profile capture, root cause analysis |
+| `samber/cc-skills-golang@golang-benchmark` | pprof/trace capture, flame graph interpretation, benchstat comparison, CI regression detection | Deciding which optimization to apply |
+| `samber/cc-skills-golang@golang-troubleshooting` | Debugging workflow: reproduce, bisect, Delve, race detector, GODEBUG, test-driven debugging | Profile interpretation, optimization patterns |
+| `samber/cc-skills-golang@golang-observability` | Always-on production signals: structured logs, Prometheus counters, OTel traces, alerting | Temporary investigation, benchmark runs |
+
+**Routing examples:**
+
+- "My HTTP handler is slow in production" → start with `golang-observability` (check metrics/traces), then `golang-benchmark` (capture profiles), then `golang-performance` (apply fixes).
+- "My benchmark regressed by 20%" → `golang-benchmark` (benchstat comparison, detect root cause via pprof).
+- "I need to reduce allocations in the hot path" → `golang-performance` (pooling, struct layout, escape analysis).
+- "The process crashes after 10 minutes under load" → `golang-troubleshooting` (race detector, memory leak, Delve attach).
+
+---
+
+## 2. Dependency injection cluster
+
+Start with `golang-dependency-injection` for library selection. Then use the library-specific skill once the choice is made.
+
+| Skill | Unique territory |
+| --- | --- |
+| `samber/cc-skills-golang@golang-dependency-injection` | Concepts (why DI, manual injection), constructor patterns, library comparison table |
+| `samber/cc-skills-golang@golang-google-wire` | Compile-time codegen: `wire.Build`, `wire.NewSet`, `wire.Bind`, `ProviderSet` |
+| `samber/cc-skills-golang@golang-uber-dig` | Runtime reflection: `dig.Provide`, `dig.In`/`dig.Out`, value groups, `Decorate` |
+| `samber/cc-skills-golang@golang-uber-fx` | Full application framework on top of dig: `fx.New`, `fx.Module`, lifecycle hooks, `fx.Annotate` |
+| `samber/cc-skills-golang@golang-samber-do` | Type-safe container, `do.Provide`, scopes, health checks, graceful shutdown |
+
+**Routing examples:**
+
+- "Should I use DI in my project?" → `golang-dependency-injection`.
+- "My project uses google/wire, `wire.Build` is failing" → `golang-google-wire`.
+- "I want lifecycle hooks with my DI container" → `golang-uber-fx` (not `golang-uber-dig` — dig is lower-level).
+- "I want type-safe DI without code generation" → `golang-samber-do` or `golang-uber-dig`.
+
+---
+
+## 3. samber/\* functional cluster
+
+The three core skills cover three distinct programming models. They rarely compete in the same task.
+
+| Skill | Unique territory | Does NOT own |
+| --- | --- | --- |
+| `samber/cc-skills-golang@golang-samber-lo` | Finite collections: `lo.Map`, `lo.Filter`, `lo.Reduce`, `lo.Uniq`, `lo.GroupBy` — 500+ helpers | Infinite streams, event-driven pipelines |
+| `samber/cc-skills-golang@golang-samber-ro` | Infinite/event-driven: observables, subjects, operators like `Map`/`Filter`/`Throttle`, backpressure | Finite slice transforms |
+| `samber/cc-skills-golang@golang-samber-mo` | Monadic types: `mo.Option[T]`, `mo.Result[T]`, `mo.Either[L,R]`, `mo.Future[T]` | Slice helpers, reactive streams |
+
+**Routing examples:**
+
+- "Transform a slice of users into a map by ID" → `golang-samber-lo` (`lo.KeyBy`).
+- "Stream events from a channel with backpressure and rate limiting" → `golang-samber-ro`.
+- "Return an optional value without using nil" → `golang-samber-mo` (`mo.Some`/`mo.None`).
+- "Compose error-returning functions without if-err chains" → `golang-samber-mo` (`mo.Result[T]`).
+
+> Note: `golang-samber-mo` is currently absent from the mutual cross-reference between `lo` and `ro` in their descriptions. The boundary above reflects the intended design.
+
+---
+
+## 4. Error handling cluster
+
+| Skill | Unique territory |
+| --- | --- |
+| `samber/cc-skills-golang@golang-error-handling` | Idiomatic error flow: `fmt.Errorf("%w")`, `errors.Is`/`errors.As`, sentinel errors, single-handling rule, `panic`/`recover` |
+| `samber/cc-skills-golang@golang-samber-oops` | `oops.New().Code().User().Hint()` builder, stack traces, APM integration, `oops.Recover` |
+| `samber/cc-skills-golang@golang-safety` | Preventing errors from occurring: nil checks, zero-value design, integer overflow guards, append aliasing |
+
+**Routing examples:**
+
+- "How should I wrap errors so callers can match them?" → `golang-error-handling`.
+- "I want structured errors with HTTP codes and stack traces" → `golang-samber-oops`.
+- "My service panics on nil pointer dereference" → `golang-safety` (defensive coding) AND `golang-troubleshooting` (debugging the existing crash).
+
+---
+
+## 5. Style / naming / lint / docs cluster
+
+These four skills each own a distinct slice of "code quality". Source descriptions include explicit mutual disclaimers.
+
+| Skill | Unique territory |
+| --- | --- |
+| `samber/cc-skills-golang@golang-code-style` | Line formatting, blank lines between declarations, short variable names in small scopes, comment placement |
+| `samber/cc-skills-golang@golang-naming` | All identifier naming rules: `MixedCaps`, no `GetX`, no `IFoo` prefixes, package names, error variable names |
+| `samber/cc-skills-golang@golang-lint` | golangci-lint YAML config, which linters to enable, `//nolint` usage, CI integration |
+| `samber/cc-skills-golang@golang-documentation` | Exported symbol comments, package-level docs, README sections, `example_test.go`, `llms.txt` |
+
+**Routing examples:**
+
+- "How do I name my constructor?" → `golang-naming`.
+- "My `golangci-lint` run reports `exhaustive` errors" → `golang-lint`.
+- "How should I format my package-level godoc comment?" → `golang-documentation`.
+- "When should I use a blank line between two function bodies?" → `golang-code-style`.
+
+---
+
+## 6. CLI cluster
+
+| Skill | Unique territory |
+| --- | --- |
+| `samber/cc-skills-golang@golang-cli` | Exit codes, signal handling (SIGTERM), stdin/stdout/stderr patterns, progress bars, terminal detection |
+| `samber/cc-skills-golang@golang-spf13-cobra` | `cobra.Command`, `PersistentPreRunE`, `Args` validators, `ValidArgsFunction`, `SetArgs` in tests |
+| `samber/cc-skills-golang@golang-spf13-viper` | `viper.BindPFlag`, `AutomaticEnv`, `ReadInConfig`, `OnConfigChange`, test isolation with `viper.Reset()` |
+
+**Routing examples:**
+
+- "My CLI should exit with code 2 on bad args" → `golang-cli`.
+- "How do I add shell completion to my cobra command?" → `golang-spf13-cobra`.
+- "How do I override config values with env vars?" → `golang-spf13-viper`.
+- "I'm building a new CLI from scratch" → `golang-cli` (architecture) + `golang-spf13-cobra` (command tree) + `golang-spf13-viper` (config).
+
+---
+
+## 7. Testing cluster
+
+| Skill | Unique territory |
+| --- | --- |
+| `samber/cc-skills-golang@golang-testing` | Test strategy, table-driven patterns, `t.Parallel()`, `testcontainers`, goleak, coverage, fuzz |
+| `samber/cc-skills-golang@golang-stretchr-testify` | `assert.Equal`, `require.NoError`, `mock.On`, `mock.AssertExpectations`, `testify/suite` lifecycle |
+
+**Routing examples:**
+
+- "How do I write a table-driven test in Go?" → `golang-testing`.
+- "How do I assert a mock was called with specific args?" → `golang-stretchr-testify`.
+- "How do I detect goroutine leaks in tests?" → `golang-testing` (goleak).
+
+---
+
+## 8. design-patterns vs structs-interfaces
+
+These two skills overlap on "how to design Go types". The split is: type-level design vs. architectural use of types.
+
+| Skill | Unique territory | Does NOT own |
+| --- | --- | --- |
+| `samber/cc-skills-golang@golang-structs-interfaces` | Composition over inheritance, embedding, type assertions, struct tag conventions, pointer vs value receivers, interface segregation | How types combine into architectural patterns |
+| `samber/cc-skills-golang@golang-design-patterns` | Functional options, middleware chains, circuit breaker, graceful shutdown, retry patterns | Low-level type mechanics |
+
+**Overlap zone:** "DI via interfaces" — defining small interfaces is `golang-structs-interfaces`; wiring multiple components together via those interfaces is `golang-design-patterns`.
+
+**Routing examples:**
+
+- "Should my method take a value or pointer receiver?" → `golang-structs-interfaces`.
+- "How do I implement a middleware chain for my HTTP handlers?" → `golang-design-patterns`.
+- "How do I embed a struct without exposing its methods?" → `golang-structs-interfaces`.
+- "How do I implement the functional options pattern?" → `golang-design-patterns`.
+
+> Note: neither skill currently carries a description-level `→ See` disclaimer for this overlap. The boundary above is the intended design, not yet explicit in the source skills.
+
+---
+
+## 9. concurrency vs context
+
+These skills overlap when goroutines are cancelled via context.
+
+| Skill | Unique territory | Does NOT own |
+| --- | --- | --- |
+| `samber/cc-skills-golang@golang-concurrency` | Goroutine lifecycle, channel patterns, `sync.WaitGroup`, `errgroup`, worker pools, fan-out/fan-in, detecting races | Context propagation rules |
+| `samber/cc-skills-golang@golang-context` | `context.WithCancel`, `context.WithTimeout`, `context.WithValue`, propagation through call chains, `WithoutCancel` | Goroutine coordination patterns |
+
+**Overlap zone:** "cancelling goroutines via context" — load both skills. `golang-context` owns the context API; `golang-concurrency` owns the goroutine coordination.
+
+**Routing examples:**
+
+- "How do I cancel a goroutine from outside?" → both (`golang-context` for `cancel()`, `golang-concurrency` for `select { case <-ctx.Done() }`).
+- "How do I fan out N workers and collect results?" → `golang-concurrency`.
+- "How do I pass a deadline through multiple layers of function calls?" → `golang-context`.
+
+> Note: no description-level disclaimer currently exists between these two skills. Load both when the task involves both concerns.
+
+---
+
+## 10. safety vs security
+
+Both skills prevent bugs, but with different threat models.
+
+| Skill | Unique territory | Does NOT own |
+| --- | --- | --- |
+| `samber/cc-skills-golang@golang-safety` | Nil panics, integer overflow, slice aliasing via append, concurrent map write, float equality, zero-value design | External attackers, cryptography, secrets |
+| `samber/cc-skills-golang@golang-security` | SQL/command/LDAP injection, weak crypto (`math/rand`), hardcoded secrets, TLS misconfiguration, SSRF, path traversal | Internal runtime correctness |
+
+**Routing examples:**
+
+- "My service panics with nil pointer dereference" → `golang-safety`.
+- "Is this SQL query safe from injection?" → `golang-security`.
+- "I'm using `math/rand` to generate a token" → `golang-security` (predictable output; use `crypto/rand`).
+- "My slice grows unexpectedly after append" → `golang-safety` (append aliasing).
+
+> Note: no description-level disclaimer currently exists between these two skills. The source descriptions cross-reference in their bodies but not in the YAML frontmatter.
+
+---
+
+## 11. modernize vs lint
+
+Both skills suggest code changes, but for different reasons.
+
+| Skill | Unique territory | Does NOT own |
+| --- | --- | --- |
+| `samber/cc-skills-golang@golang-modernize` | Adopting language features: range-over-int, `min`/`max` builtins, `iter.Seq`, `slices.SortFunc`, `log/slog`, `testing.T.Context` | Static analysis configuration |
+| `samber/cc-skills-golang@golang-lint` | golangci-lint YAML config, enabling/disabling linters, interpreting linter output, `//nolint` policy | Language feature adoption |
+
+**Overlap zone:** Some linters (`govet`, `deadcode`, `perfsprint`) produce warnings that overlap with modernize suggestions (e.g., "use `slog` instead of `log`"). The boundary: lint owns the tool configuration and suppression policy; modernize owns the rewrite patterns to apply once you've decided to adopt the feature.
+
+**Routing examples:**
+
+- "How do I replace a `for i := 0; i < n; i++` loop with the new range syntax?" → `golang-modernize`.
+- "My CI fails on `perfsprint` lint rule" → `golang-lint` (interpret the rule and decide whether to fix or suppress).
+- "Should I migrate from `log` to `slog`?" → `golang-modernize`.
+- "How do I configure golangci-lint to run only security-relevant linters?" → `golang-lint`.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/project-config.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/project-config.md
new file mode 100644
index 00000000..975ec8be
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-how-to/references/project-config.md
@@ -0,0 +1,114 @@
+# Configure mode — force-trigger Go skills in a project
+
+This workflow adds a `## Required Go skills` block to the project's agent config file so that specific skills always load, regardless of trigger heuristics.
+
+## When to use
+
+- The project has a hard requirement on a skill (e.g., `golang-security` must always apply, not just when the user mentions "security").
+- The team has agreed on a fixed set of Go standards to enforce on every AI interaction.
+- A company skill overrides a community default (⚙️ skills) and must always win.
+
+## Step 1 — Detect the project config file
+
+Check in this precedence order:
+
+```
+1. CLAUDE.md          (Claude Code)
+2. AGENTS.md          (OpenAI Codex, OpenCode, multi-agent)
+3. .cursor/rules      (Cursor)
+4. .github/copilot-instructions.md  (GitHub Copilot)
+```
+
+Use `Glob` to detect which files exist at the project root. If multiple exist, use all of them (different tools read different files). If none exist, ask the user which one to create with `AskUserQuestion`.
+
+## Step 2 — Idempotency check
+
+Before writing, grep each file for an existing `## Required Go skills` block:
+
+```bash
+grep -n "## Required Go skills" CLAUDE.md
+```
+
+If the block already exists, read it and confirm with the user whether to update it in place (replace the existing list) or skip.
+
+## Step 3 — Confirm the skill set with the user
+
+Use `AskUserQuestion` to confirm which skills to always load. Present the ⭐️ recommended skills as the default selection. Remind the user of the token budget (each always-loaded skill adds its description tokens to every session — the 11 recommended skills add ~1,100 tokens at startup).
+
+Recommended ⭐️ set for most projects:
+
+```
+golang-code-style
+golang-data-structures
+golang-design-patterns
+golang-documentation
+golang-error-handling
+golang-modernize
+golang-naming
+golang-safety
+golang-security
+golang-testing
+golang-troubleshooting
+```
+
+Additional skills to suggest based on codebase context:
+
+- Database layer detected (`sql`, `gorm`, `sqlc`) → suggest `golang-database`
+- CI config detected (`.github/workflows/`) → suggest `golang-continuous-integration`
+- Cobra imports detected → suggest `golang-spf13-cobra`
+- Viper imports detected → suggest `golang-spf13-viper`
+- samber/lo imports detected → suggest `golang-samber-lo`
+- Any other library-specific import → suggest the matching library skill
+
+## Step 4 — Write the block
+
+### Template
+
+```markdown
+## Required Go skills
+
+The following Go skills from `samber/cc-skills-golang` MUST always be applied when working on this project. Load them at the start of every Go-related task, regardless of whether the user explicitly mentions them.
+
+- `samber/cc-skills-golang@golang-error-handling`
+- `samber/cc-skills-golang@golang-security`
+- `samber/cc-skills-golang@golang-testing`
+```
+
+Replace the skill list with the confirmed set from Step 3. Use the fully-qualified `samber/cc-skills-golang@<name>` identifier for each skill.
+
+### Insertion point
+
+- If the file is empty: write the block at the top.
+- If the file has existing content: append after the last section, separated by a blank line.
+- If a `## Required Go skills` block already exists: replace only the bullet list inside it, preserving surrounding content.
+
+### Edit the file
+
+Use the `Edit` tool (preferred over a bash script) to apply the change. For append operations:
+
+```python
+# Conceptually: read the file, find the insertion point, apply Edit
+```
+
+Perform an idempotency check after writing: re-read the file and verify the block appears exactly once.
+
+## Step 5 — Confirm to the user
+
+After writing, summarize:
+
+- Which file(s) were updated
+- Which skills were added to the always-load list
+- Approximate startup token cost (number of skills × ~100 tokens per description)
+- Note: skills marked ⚙️ (overridable) will be superseded if a company skill explicitly declares the override in its body
+
+## Notes on company overrides (⚙️ skills)
+
+Skills marked ⚙️ in the README support company overrides. If the project has a company skill that supersedes a community default (e.g., `acme/cc-skills@golang-error-handling-acme` supersedes `samber/cc-skills-golang@golang-error-handling`), use the company skill FQN in the block instead — do NOT list both.
+
+To declare an override in a company skill body, add near the top:
+
+```
+> This skill supersedes `samber/cc-skills-golang@golang-error-handling` for [Company] projects.
+```
+
+Overridable skills: `golang-code-style`, `golang-concurrency`, `golang-context`, `golang-database`, `golang-dependency-injection`, `golang-design-patterns`, `golang-documentation`, `golang-error-handling`, `golang-naming`, `golang-observability`, `golang-structs-interfaces`, `golang-testing`.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/SKILL.md
new file mode 100644
index 00000000..d8d6af48
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/SKILL.md
@@ -0,0 +1,155 @@
+---
+name: golang-lint
+description: "Linting best practices and golangci-lint configuration for Golang projects — running linters, configuring .golangci.yml, suppressing warnings with nolint directives, interpreting lint output, and selecting linters. Use when configuring golangci-lint, asking about lint warnings or nolint suppressions, setting up code quality tooling, or choosing linters. Also use when the user mentions golangci-lint, go vet, staticcheck, or revive."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.2"
+  openclaw:
+    emoji: "🧹"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - golangci-lint
+    install:
+      - kind: brew
+        formula: golangci-lint
+        bins: [golangci-lint]
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent
+---
+
+**Persona:** You are a Go code quality engineer. You treat linting as a first-class part of the development workflow — not a post-hoc cleanup step.
+
+**Modes:**
+
+- **Setup mode** — configuring `.golangci.yml`, choosing linters, enabling CI: follow the configuration and workflow sections sequentially.
+- **Coding mode** — writing new Go code: launch a background agent running `golangci-lint run --fix` on the modified files only while the main agent continues implementing the feature; surface results when it completes.
+- **Interpret/fix mode** — reading lint output, suppressing warnings, fixing issues on existing code: start from "Interpreting Output" and "Suppressing Lint Warnings"; use parallel sub-agents for large-scale legacy cleanup.
+
+**Dependencies:**
+
+- golangci-lint: `go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest`
+
+# Go Linting
+
+## Overview
+
+`golangci-lint` is the standard Go linting tool. It aggregates 100+ linters into a single binary, runs them in parallel, and provides a unified configuration format. Run it frequently during development and always in CI.
+
+Every Go project MUST have a `.golangci.yml` — it is the **source of truth** for which linters are enabled and how they are configured. See the [recommended configuration](./assets/.golangci.yml) for a production-ready setup with 48 linters enabled.
+
+## Quick Reference
+
+```bash
+# Run all configured linters
+golangci-lint run ./...
+
+# Auto-fix issues where possible
+golangci-lint run --fix ./...
+
+# Format code (golangci-lint v2+)
+golangci-lint fmt ./...
+
+# Run a single linter only
+golangci-lint run --enable-only govet ./...
+
+# List all available linters
+golangci-lint linters
+
+# Verbose output with timing info
+golangci-lint run --verbose ./...
+```
+
+## Configuration
+
+The [recommended .golangci.yml](./assets/.golangci.yml) provides a production-ready setup with 33 linters. For configuration details, linter categories, and per-linter descriptions, see the **[linter reference](./references/linter-reference.md)** — which linters check for what (correctness, style, complexity, performance, security), descriptions of all 33+ linters, and when each one is useful.
+
+## Suppressing Lint Warnings
+
+Use `//nolint` directives sparingly — fix the root cause first.
+
+```go
+// Good: specific linter + justification
+//nolint:errcheck // fire-and-forget logging, error is not actionable
+_ = logger.Sync()
+
+// Bad: blanket suppression without reason
+//nolint
+_ = logger.Sync()
+```
+
+Rules:
+
+1. **//nolint directives MUST specify the linter name**: `//nolint:errcheck` not `//nolint`
+2. **//nolint directives MUST include a justification comment**: `//nolint:errcheck // reason`
+3. **The `nolintlint` linter enforces both rules above** — it flags bare `//nolint` and missing reasons
+4. **NEVER suppress security linters** (gosec, bodyclose, sqlclosecheck) without a very strong reason
+
+For comprehensive patterns and examples, see **[nolint directives](./references/nolint-directives.md)** — when to suppress, how to write justifications, patterns for per-line vs per-function suppression, and anti-patterns.
+
+## Development Workflow
+
+1. **Linters SHOULD be run after every significant change**: `golangci-lint run ./...`
+2. **Auto-fix what you can**: `golangci-lint run --fix ./...`
+3. **Format before committing**: `golangci-lint fmt ./...`
+4. **Incremental adoption on legacy code**: set `issues.new-from-rev` in `.golangci.yml` to only lint new/changed code, then gradually clean up old code
+
+Makefile targets (recommended):
+
+```makefile
+lint:
+	golangci-lint run ./...
+
+lint-fix:
+	golangci-lint run --fix ./...
+
+fmt:
+	golangci-lint fmt ./...
+```
+
+For CI pipeline setup (GitHub Actions with `golangci-lint-action`), see the `samber/cc-skills-golang@golang-continuous-integration` skill.
+
+## Interpreting Output
+
+Each issue follows this format:
+
+```
+path/to/file.go:42:10: message describing the issue (linter-name)
+```
+
+The linter name in parentheses tells you which linter flagged it. Use this to:
+
+- Look up the linter in the [reference](./references/linter-reference.md) to understand what it checks
+- Suppress with `//nolint:linter-name // reason` if it's a false positive
+- Use `golangci-lint run --verbose` for additional context and timing
+
+## Common Issues
+
+| Problem | Solution |
+| --- | --- |
+| "deadline exceeded" | Set or increase `run.timeout` in `.golangci.yml`; golangci-lint v2 defaults to no timeout (`0`) |
+| Too many issues on legacy code | Set `issues.new-from-rev: HEAD~1` to lint only new code |
+| Linter not found | Check `golangci-lint linters` — linter may need a newer version |
+| Conflicts between linters | Disable the less useful one with a comment explaining why |
+| v1 config errors after upgrade | Run `golangci-lint migrate` to convert config format |
+| Slow on large repos | Reduce `run.concurrency` or exclude paths with `linters.exclusions.paths` / `formatters.exclusions.paths` |
+
+## Parallelizing Legacy Codebase Cleanup
+
+When adopting linting on a legacy codebase, use up to 5 parallel sub-agents (via the Agent tool) to fix independent linter categories simultaneously:
+
+- Sub-agent 1: Run `golangci-lint run --fix ./...` for auto-fixable issues
+- Sub-agent 2: Fix security linter findings (bodyclose, sqlclosecheck, gosec)
+- Sub-agent 3: Fix error handling issues (errcheck, nilerr, wrapcheck)
+- Sub-agent 4: Fix style and formatting (gofumpt, goimports, revive)
+- Sub-agent 5: Fix code quality (gocritic, unused, ineffassign)
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-continuous-integration` skill for CI pipeline with golangci-lint-action
+- → See `samber/cc-skills-golang@golang-code-style` skill for style rules that linters enforce
+- → See `samber/cc-skills-golang@golang-security` skill for SAST tools beyond linting (gosec, govulncheck)
+- → See `samber/cc-skills-golang@golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/assets/.golangci.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/assets/.golangci.yml
new file mode 100644
index 00000000..b60af439
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/assets/.golangci.yml
@@ -0,0 +1,149 @@
+version: "2"
+run:
+  concurrency: 4
+  # Timeout for analysis
+  timeout: 5m
+  # Include test files
+  tests: true
+
+issues:
+  max-issues-per-linter: 0  # 0 = unlimited (we want ALL issues)
+  max-same-issues: 50
+
+linters:
+  enable:
+    # correctness
+    - govet            # built-in checker: copylocks, printf formats, struct tags, unreachable code
+    - staticcheck      # extensive static analysis: deprecated APIs, common mistakes, simplifications
+    - unused           # unused variables, functions, types
+    - errcheck         # unchecked error returns and type assertions
+    - errorlint        # correct use of errors.Is/As and %w wrapping (Go 1.13+)
+    - nilerr           # returning nil error when err is non-nil
+    - forcetypeassert  # type assertions without comma-ok check
+    - copyloopvar      # loop variable copy issues (Go 1.22+)
+    - durationcheck    # detect time.Duration * time.Duration bugs
+    - reassign         # package-level variable reassignment
+    # style
+    - gocritic         # opinionated style: unnecessary conversions, range copies, redundant code
+    - revive           # naming conventions, exported types, stuttered package names
+    - wsl_v5           # whitespace and blank line rules for readability
+    - whitespace       # trailing whitespace, unnecessary blank lines
+    - godot            # exported-symbol comments must end with a period
+    - misspell         # common English misspellings in identifiers and comments
+    - dupword          # duplicate words in comments and strings (the the, is is)
+    - predeclared      # shadowing Go built-ins (len, cap, error)
+    - errname          # error type/var naming conventions (ErrFoo, FooError)
+    - asciicheck       # non-ASCII identifiers (prevents homoglyph/trojan source attacks)
+    # complexity
+    - gocyclo          # cyclomatic complexity threshold
+    - nestif           # deeply nested if/else chains
+    - funlen           # function length limits (lines and statements)
+    - dupl             # code duplication detection
+    # performance
+    - perfsprint       # faster alternatives to fmt.Sprintf
+    - unconvert        # unnecessary type conversions
+    - ineffassign      # assignments to variables never read
+    - goconst          # repeated literals that should be constants
+    # security & resources
+    - gosec            # security scanner: SQL injection, hardcoded credentials, weak crypto, path traversal
+    - bidichk          # dangerous bidirectional Unicode sequences (trojan source CVE-2021-42574)
+    - bodyclose        # unclosed HTTP response bodies (connection leaks)
+    - noctx            # HTTP requests missing context.Context
+    - containedctx     # context.Context stored in struct fields instead of passed as parameter
+    - fatcontext       # context.WithValue/WithCancel in loops (unbounded context chain, memory leak)
+    - sqlclosecheck    # unclosed sql.Rows and sql.Stmt
+    - rowserrcheck     # unchecked sql.Rows.Err() after iteration
+    # logging
+    - sloglint         # consistent log/slog code style
+    - loggercheck      # key-value pair validation for structured loggers (zap, slog, logr)
+    # testing
+    - testifylint      # testify best practices
+    - thelper          # test helpers missing t.Helper()
+    - usetesting       # use t.Setenv/t.TempDir instead of os equivalents in tests
+    - paralleltest     # tests and subtests missing t.Parallel()
+    # modernization & meta
+    - modernize        # old patterns replaceable with newer Go features
+    - exptostd         # replace golang.org/x/exp/ functions with stdlib equivalents
+    - intrange         # range over integer instead of C-style loop (Go 1.22+)
+    - usestdlibvars    # use stdlib constants instead of hardcoded values
+    - exhaustive       # switch statements not covering all enum values
+    - nolintlint       # enforces proper //nolint directive usage
+
+  disable:
+    - lll              # line length — handled by gofmt/gofumpt
+    - prealloc         # high false-positive rate; enable only after performance profiling
+    - wrapcheck        # forces wrapping all external errors — too noisy as a default
+    - err113           # forces package-level sentinel errors — too opinionated, breaks common patterns
+    - mnd              # magic number detector — extremely noisy, flags obvious constants like HTTP 200
+    - iface            # interface pollution detector — too opinionated, not mature enough
+    - nakedret         # naked returns — overlaps with funlen (short functions make naked returns fine)
+    - noinlineerr      # bans `if err := ...; err != nil {}` — this is idiomatic Go
+    - gocognit         # cognitive complexity — redundant with gocyclo + nestif
+    - cyclop           # cyclomatic complexity — redundant with gocyclo
+    - depguard         # import allow/deny lists — requires per-project configuration
+    - goheader         # file header enforcement — project-specific policy
+    - importas         # import alias enforcement — requires per-project configuration
+    - funcorder        # function ordering — too opinionated for a default
+    - godoclint        # godoc validation — overlaps with godot and revive
+    - varnamelen       # variable name length — too opinionated, Go favors short names
+    - exhaustruct      # all struct fields must be set — extremely noisy, breaks zero-value idiom
+    - gochecknoglobals # no global variables — too strict, many valid uses
+    - gochecknoinits   # no init() functions — too strict, many valid uses
+    - unparam          # unused function parameters — medium false-positive rate with interfaces
+    - makezero         # flags make([]T, n) — noisy, often wrong about intent
+    - testpackage      # forces _test package — valid but too opinionated as a default
+    - embeddedstructfieldcheck # embedded type placement — minor style, not worth enforcing
+    - iotamixing       # iota in mixed const blocks — very rare issue
+    - unqueryvet       # SELECT * detection — too niche for a default config
+    - recvcheck        # receiver type consistency — overlaps with gocritic
+    - mirror           # bytes/strings mirror patterns — very few real hits
+    - protogetter      # proto field access via getters — only for protobuf users
+    - spancheck        # OpenTelemetry span checks — only for OTel users
+    - zerologlint      # zerolog usage — only for zerolog users
+
+  exclusions:
+    paths:
+      - vendor$
+      - third_party$
+      - testutils$
+      - examples$
+
+  settings:
+    dupl:
+      threshold: 100  # lower => stricter (tokens)
+    errcheck:
+      check-type-assertions: true
+    funlen:
+      lines: 120
+      statements: 80
+    goconst:
+      min-len: 3
+      min-occurrences: 4
+    gocyclo:
+      min-complexity: 13 # strict; lower => stricter
+    nolintlint:
+      require-explanation: true
+      require-specific: true
+    wsl_v5:
+      allow-first-in-block: true
+      allow-whole-block: false
+      branch-max-lines: 2
+
+formatters:
+  enable:
+    - gofmt
+    - gofumpt
+  disable:
+    - gci        # import grouping/ordering — gofumpt already handles standard grouping
+    - goimports  # import management — redundant with gofumpt
+    - golines    # line wrapping — too opinionated, can break readability
+    - swaggo     # swaggo comment formatting — only for swaggo users
+  settings:
+    gofumpt:
+      extra-rules: true
+  exclusions:
+    generated: lax
+    paths:
+      - third_party$
+      - builtin$
+      - examples$
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/evals/evals.json
new file mode 100644
index 00000000..868dc5e5
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/evals/evals.json
@@ -0,0 +1,305 @@
+[
+  {
+    "id": 1,
+    "name": "nolint-directive-specificity",
+    "description": "Tests that nolint directives specify the linter name and include a justification — never bare //nolint",
+    "prompt": "I have a Go function that triggers several lint warnings. I want to suppress them. Write the nolint directives for these cases:\n\n1. A logger.Sync() call where the error is intentionally ignored\n2. A type assertion that is guaranteed safe by a preceding type switch\n3. A function with cyclomatic complexity of 15 that orchestrates 6 subsystems\n4. A table-driven test function that is 200 lines long\n5. A deprecated API call that we can't migrate yet\n\nShow the code with proper suppression directives.",
+    "trap": "Model uses bare //nolint without specifying the linter name, or omits the justification comment. May also use //nolint at the file level instead of per-line.",
+    "assertions": [
+      {
+        "id": "1.1",
+        "text": "Every //nolint directive specifies the linter name (e.g., //nolint:errcheck, //nolint:gocyclo) — NO bare //nolint without a linter name"
+      },
+      {
+        "id": "1.2",
+        "text": "Every //nolint directive includes a justification comment after // (e.g., //nolint:errcheck // fire-and-forget logging)"
+      },
+      {
+        "id": "1.3",
+        "text": "The type assertion uses //nolint:forcetypeassert with an explanation referencing why the assertion is safe"
+      },
+      {
+        "id": "1.4",
+        "text": "The long test function uses //nolint:funlen with a justification like 'table-driven test, length proportional to case count'"
+      },
+      {
+        "id": "1.5",
+        "text": "The cyclomatic complexity suppression uses //nolint:gocyclo with a justification about orchestration"
+      }
+    ]
+  },
+  {
+    "id": 2,
+    "name": "nolint-fix-vs-suppress-judgment",
+    "description": "Tests judgment about when to fix vs when to suppress — security and correctness linters should almost never be suppressed",
+    "prompt": "My Go codebase has these lint warnings. For each one, should I fix the code or suppress the warning? Explain.\n\n1. `bodyclose: response body not closed` on an HTTP client call\n2. `funlen: function too long (150 lines)` on a table-driven test\n3. `errcheck: error return not checked` on a database query in a request handler\n4. `dupl: duplicate code block` on two similar but intentionally parallel handler functions\n5. `sqlclosecheck: rows not closed` on a database query\n6. `goconst: string 'application/json' repeated 4 times` in test assertions",
+    "trap": "Model suppresses bodyclose, errcheck on production DB code, or sqlclosecheck — these are real bugs, not style issues. Should only suppress funlen, dupl, and goconst with justifications.",
+    "assertions": [
+      {
+        "id": "2.1",
+        "text": "Recommends FIXING bodyclose — unclosed HTTP response bodies leak connections, this is a real resource leak"
+      },
+      {
+        "id": "2.2",
+        "text": "Recommends SUPPRESSING funlen on the table-driven test — length is proportional to test case count, splitting would be worse"
+      },
+      {
+        "id": "2.3",
+        "text": "Recommends FIXING errcheck on the database query — unchecked errors in production request handlers cause silent failures"
+      },
+      {
+        "id": "2.4",
+        "text": "Recommends SUPPRESSING dupl on intentional parallel structure — with a justification that the parallel pattern is clearer than abstracting"
+      },
+      {
+        "id": "2.5",
+        "text": "Recommends FIXING sqlclosecheck — unclosed sql.Rows leak database connections"
+      },
+      {
+        "id": "2.6",
+        "text": "Recommends SUPPRESSING goconst in tests — extracting 'application/json' to a constant in tests would reduce clarity"
+      }
+    ]
+  },
+  {
+    "id": 3,
+    "name": "golangci-yml-version-2-structure",
+    "description": "Tests knowledge of golangci-lint v2 config structure: version field, linters.enable/disable, formatters section",
+    "prompt": "Create a .golangci.yml configuration file for a Go project. Enable at least govet, staticcheck, errcheck, and gofumpt. Set the timeout to 5 minutes and configure errcheck to also check type assertions.",
+    "trap": "Model uses golangci-lint v1 config format (missing version: \"2\", using enable-all/disable-all, missing formatters section, putting gofumpt in linters instead of formatters).",
+    "assertions": [
+      {
+        "id": "3.1",
+        "text": "Config file has version: \"2\" at the top — golangci-lint v2 requires this field"
+      },
+      {
+        "id": "3.2",
+        "text": "Linters are listed under linters.enable (not enable-all with exclusions) — explicit listing is the recommended approach"
+      },
+      {
+        "id": "3.3",
+        "text": "gofumpt is configured under formatters.enable, NOT under linters.enable — formatters are a separate section in v2"
+      },
+      {
+        "id": "3.4",
+        "text": "errcheck has check-type-assertions: true in linters.settings.errcheck"
+      },
+      {
+        "id": "3.5",
+        "text": "Timeout is set under run.timeout: 5m"
+      }
+    ]
+  },
+  {
+    "id": 4,
+    "name": "linter-categories-correctness-vs-style",
+    "description": "Tests understanding of linter domains — which linters catch bugs vs which catch style issues",
+    "prompt": "I'm setting up golangci-lint for a new Go project and can only enable 10 linters due to team constraints. Which 10 should I prioritize and why? Categorize them.",
+    "trap": "Model prioritizes style linters (revive, godot, misspell) over correctness linters (govet, staticcheck, errcheck, nilerr). May also include deprecated or redundant linters.",
+    "assertions": [
+      {
+        "id": "4.1",
+        "text": "Includes govet and staticcheck — these are the highest-value correctness linters that catch real bugs"
+      },
+      {
+        "id": "4.2",
+        "text": "Includes errcheck — unchecked errors are the most common source of silent failures in Go"
+      },
+      {
+        "id": "4.3",
+        "text": "Prioritizes correctness/safety linters over style linters — bug-finding tools provide more value than formatting preferences"
+      },
+      {
+        "id": "4.4",
+        "text": "Includes at least one security linter (bodyclose, gosec, or sqlclosecheck) for resource leak prevention"
+      },
+      {
+        "id": "4.5",
+        "text": "Does NOT include both gocyclo and cyclop (redundant) or both gocognit and gocyclo (overlapping complexity checkers)"
+      }
+    ]
+  },
+  {
+    "id": 5,
+    "name": "legacy-codebase-incremental-adoption",
+    "description": "Tests the new-from-rev strategy for adopting linters on legacy code without drowning in warnings",
+    "prompt": "We have a large legacy Go codebase with 2000+ lint warnings. We want to adopt golangci-lint but can't fix everything at once. How should we approach this?",
+    "trap": "Model suggests suppressing all existing warnings with //nolint directives, or disabling linters until the code is clean. Doesn't know about new-from-rev for incremental adoption.",
+    "assertions": [
+      {
+        "id": "5.1",
+        "text": "Recommends setting issues.new-from-rev (e.g., HEAD~1 or main) in .golangci.yml to only lint new/changed code"
+      },
+      {
+        "id": "5.2",
+        "text": "Does NOT suggest adding //nolint directives to all 2000+ existing warnings — that's unmaintainable"
+      },
+      {
+        "id": "5.3",
+        "text": "Suggests gradually cleaning up old code over time while enforcing quality on new code"
+      },
+      {
+        "id": "5.4",
+        "text": "Suggests running golangci-lint run --fix for auto-fixable issues as a quick first pass"
+      },
+      {
+        "id": "5.5",
+        "text": "Mentions using parallel sub-agents or batching fixes by linter category (security, error handling, style) to tackle cleanup efficiently"
+      }
+    ]
+  },
+  {
+    "id": 6,
+    "name": "interpreting-lint-output-format",
+    "description": "Tests ability to read lint output format and use the linter name for targeted investigation or suppression",
+    "prompt": "I ran golangci-lint and got this output:\n\n```\nserver/handler.go:42:10: Error return value of `(*DB).Close` is not checked (errcheck)\nserver/handler.go:55:2: response body must be closed (bodyclose)\nserver/auth.go:12:6: func `validateToken` is unused (unused)\nserver/auth.go:30:1: cyclomatic complexity 17 of func `processAuth` is high (> 13) (gocyclo)\nserver/model.go:5:2: exported type `Model` should have comment or be unexported (revive)\n```\n\nFor each warning, explain what it means and whether I should fix or suppress it.",
+    "trap": "Model doesn't use the linter name in parentheses to guide its response. May treat all warnings equally instead of recognizing that errcheck and bodyclose are critical while revive is style.",
+    "assertions": [
+      {
+        "id": "6.1",
+        "text": "Identifies errcheck on DB.Close as a real issue to fix — unchecked database close errors can mask connection problems"
+      },
+      {
+        "id": "6.2",
+        "text": "Identifies bodyclose as a critical resource leak to fix — not suppress"
+      },
+      {
+        "id": "6.3",
+        "text": "Identifies unused validateToken as dead code to either remove or fix — not suppress"
+      },
+      {
+        "id": "6.4",
+        "text": "For gocyclo, evaluates whether processAuth should be refactored or suppressed based on its nature (orchestration function vs genuinely complex logic)"
+      },
+      {
+        "id": "6.5",
+        "text": "For revive comment warning, correctly identifies it as a style issue that's lower priority than the correctness issues above"
+      }
+    ]
+  },
+  {
+    "id": 7,
+    "name": "disabled-linters-with-rationale",
+    "description": "Tests understanding of which linters should be disabled and why — the recommended config explicitly disables several with reasons",
+    "prompt": "A colleague wants to enable these linters in our .golangci.yml: exhaustruct, gochecknoglobals, wrapcheck, mnd (magic number detector), and varnamelen. Should we? Explain your reasoning for each.",
+    "trap": "Model enables all of them without considering that they are intentionally excluded from the recommended config due to being too noisy, too opinionated, or breaking idiomatic Go patterns.",
+    "assertions": [
+      {
+        "id": "7.1",
+        "text": "Recommends AGAINST exhaustruct — it requires all struct fields to be set, which breaks Go's zero-value idiom and is extremely noisy"
+      },
+      {
+        "id": "7.2",
+        "text": "Recommends AGAINST gochecknoglobals — there are many valid uses for global variables in Go (loggers, registries, etc.) and a blanket ban is too strict"
+      },
+      {
+        "id": "7.3",
+        "text": "Recommends AGAINST wrapcheck as a default — it forces wrapping all external errors, which is too noisy and not always appropriate"
+      },
+      {
+        "id": "7.4",
+        "text": "Recommends AGAINST mnd — magic number detection is extremely noisy, flagging obvious constants like HTTP status codes"
+      },
+      {
+        "id": "7.5",
+        "text": "Recommends AGAINST varnamelen — Go idiomatically favors short variable names, and this linter conflicts with that philosophy"
+      }
+    ]
+  },
+  {
+    "id": 8,
+    "name": "nolintlint-meta-linter",
+    "description": "Tests knowledge that nolintlint enforces proper nolint directive usage and should be enabled",
+    "prompt": "I see //nolint directives scattered throughout our Go codebase. Many are bare '//nolint' without specifying which linter or why. How can I enforce proper nolint hygiene automatically?",
+    "trap": "Model suggests a manual code review process or a custom script instead of enabling the nolintlint linter with require-explanation and require-specific settings.",
+    "assertions": [
+      {
+        "id": "8.1",
+        "text": "Recommends enabling the nolintlint linter — it automatically enforces nolint directive quality"
+      },
+      {
+        "id": "8.2",
+        "text": "Configures nolintlint with require-specific: true to require linter names (not bare //nolint)"
+      },
+      {
+        "id": "8.3",
+        "text": "Configures nolintlint with require-explanation: true to require justification comments"
+      },
+      {
+        "id": "8.4",
+        "text": "Shows the correct config location: linters.settings.nolintlint in .golangci.yml"
+      }
+    ]
+  },
+  {
+    "id": 9,
+    "name": "multiple-nolint-comma-syntax",
+    "description": "Tests proper syntax for suppressing multiple linters on one line",
+    "prompt": "I have a line of Go code that triggers both errcheck and gosec warnings. I've confirmed both are false positives in this specific case. How do I suppress both on the same line?",
+    "trap": "Model uses two separate //nolint directives on the same line, or uses //nolint without comma separation, or stacks directives on consecutive lines for the same code line.",
+    "assertions": [
+      {
+        "id": "9.1",
+        "text": "Uses comma-separated linter names in a single directive: //nolint:errcheck,gosec — not two separate //nolint directives"
+      },
+      {
+        "id": "9.2",
+        "text": "Includes a justification comment after the directive explaining why both are false positives"
+      },
+      {
+        "id": "9.3",
+        "text": "The directive is placed on the same line as the flagged code or the line immediately above it"
+      }
+    ]
+  },
+  {
+    "id": 10,
+    "name": "common-config-issues",
+    "description": "Tests troubleshooting knowledge for golangci-lint: timeout, v1-to-v2 migration, linter-not-found",
+    "prompt": "I'm getting these errors with golangci-lint:\n1. 'deadline exceeded' when running on our large monorepo\n2. After upgrading to golangci-lint v2, my .golangci.yml throws config errors\n3. 'linter modernize not found' even though I listed it in enable\n\nHow do I fix each?",
+    "trap": "Model doesn't know about the v2 config migration tool, suggests reinstalling for the linter-not-found issue instead of checking the golangci-lint version, or increases concurrency instead of timeout.",
+    "assertions": [
+      {
+        "id": "10.1",
+        "text": "For deadline exceeded: recommends increasing run.timeout in .golangci.yml (default is 5m, may need 10m+ for large repos)"
+      },
+      {
+        "id": "10.2",
+        "text": "For v1 config errors: recommends running golangci-lint migrate to convert the config format to v2"
+      },
+      {
+        "id": "10.3",
+        "text": "For linter not found: recommends checking the golangci-lint version — modernize requires v2.6.0+ or similar newer version"
+      },
+      {
+        "id": "10.4",
+        "text": "Mentions golangci-lint linters command to check available linters in the installed version"
+      }
+    ]
+  },
+  {
+    "id": 11,
+    "name": "formatter-vs-linter-distinction",
+    "description": "Tests that formatters (gofumpt, gofmt) are configured in the formatters section, not the linters section, and use the fmt subcommand",
+    "prompt": "I want to enforce consistent code formatting in my Go project using golangci-lint. I want gofumpt with extra rules. How do I set it up?",
+    "trap": "Model puts gofumpt in the linters.enable section instead of formatters.enable (v2 distinction), or doesn't mention the golangci-lint fmt subcommand for formatting.",
+    "assertions": [
+      {
+        "id": "11.1",
+        "text": "Configures gofumpt under formatters.enable, NOT linters.enable — formatters are a separate section in golangci-lint v2"
+      },
+      {
+        "id": "11.2",
+        "text": "Sets gofumpt extra-rules: true under formatters.settings.gofumpt"
+      },
+      {
+        "id": "11.3",
+        "text": "Mentions the golangci-lint fmt ./... command for running formatters — separate from golangci-lint run"
+      },
+      {
+        "id": "11.4",
+        "text": "Notes that gci and goimports are redundant with gofumpt and can be disabled"
+      }
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/references/linter-reference.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/references/linter-reference.md
new file mode 100644
index 00000000..d922e26d
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/references/linter-reference.md
@@ -0,0 +1,112 @@
+# Linter Reference
+
+golangci-lint v2 uses a `.golangci.yml` with `version: "2"` at the project root.
+
+Key sections of `.golangci.yml`:
+
+- **`run`** — concurrency, timeout, test inclusion, directory exclusions
+- **`linters.enable`** / **`linters.disable`** — which linters are active
+- **`linters.settings`** — per-linter thresholds and options
+- **`formatters`** — code formatters (gofmt, gofumpt)
+- **`issues`** — output limits, exclusion rules
+
+To add a linter: add it to `linters.enable` and optionally configure it in `linters.settings`.
+
+To disable a linter: move it to `linters.disable` with a comment explaining why.
+
+## Linter Categories
+
+The recommended configuration enables linters across these domains:
+
+| Domain | Linters | Catches |
+| --- | --- | --- |
+| Correctness | govet, staticcheck, unused, errcheck, errorlint, nilerr, forcetypeassert, copyloopvar, durationcheck, reassign | Bugs, unchecked errors, stdlib misuse |
+| Style | gocritic, revive, wsl_v5, whitespace, godot, misspell, dupword, predeclared, errname, asciicheck | Readability, naming, consistency |
+| Complexity | gocyclo, nestif, funlen, dupl | Overly complex or duplicated code |
+| Performance | perfsprint, unconvert, ineffassign, goconst | Conversions, string ops, dead assigns |
+| Security | gosec, bidichk, bodyclose, noctx, containedctx, fatcontext, sqlclosecheck, rowserrcheck | Security issues, resource leaks (HTTP, SQL) |
+| Logging | sloglint, loggercheck | Structured log consistency |
+| Testing | thelper, paralleltest, testifylint, usetesting | Test hygiene and best practices |
+| Modernization | modernize, exptostd, intrange, usestdlibvars, exhaustive, nolintlint | Modern Go idioms, lint hygiene |
+| Formatting | gofmt, gofumpt | Code formatting |
+
+All linters are enabled in the [recommended .golangci.yml](../assets/.golangci.yml), organized by domain.
+
+### Correctness & Safety
+
+- **govet** — Go's built-in checker: copylocks, printf format mismatches, struct tag validation, context stored in structs, unreachable code, nil dereferences
+- **staticcheck** — Extensive static analysis: deprecated APIs, common mistakes, unnecessary code, simplifications, misuse of standard library
+- **unused** — Detects unused variables, functions, types, and struct fields
+- **errcheck** — Ensures all error returns are checked, including type assertions (configured with `check-type-assertions: true`)
+- **nilerr** — Detects returning nil error when `err` is non-nil (common source of silent failures)
+- **forcetypeassert** — Flags type assertions without the comma-ok check (`v := x.(T)` instead of `v, ok := x.(T)`)
+- **copyloopvar** — Detects loop variable copy issues (Go 1.22+)
+- **errorlint** — Enforces correct use of `errors.Is`/`errors.As` and `%w` wrapping (Go 1.13+ error wrapping)
+- **durationcheck** — Detects `time.Duration * time.Duration` multiplication bugs (e.g., `2 * time.Second * time.Minute` produces nanoseconds squared, not seconds)
+- **reassign** — Detects reassignment of package-level variables outside `init()`, which hides state mutations
+
+### Style & Readability
+
+- **gocritic** — Opinionated style checks: unnecessary conversions, range copies, append-assign patterns, redundant code
+- **revive** — Naming conventions for exported types, unexported returns, receiver naming, error naming, stuttered package names
+- **wsl_v5** — Whitespace and blank line rules for visual grouping and readability
+- **whitespace** — Detects trailing whitespace and unnecessary blank lines in function bodies
+- **godot** — Ensures exported-symbol comments end with a period
+- **misspell** — Catches common English misspellings in identifiers and comments
+- **predeclared** — Flags shadowing of Go built-in identifiers (e.g., naming a variable `len`, `cap`, `error`)
+- **errname** — Enforces error naming conventions: error types suffixed with `Error` (e.g., `DecodeError`), error variables prefixed with `Err` (e.g., `ErrNotFound`)
+- **dupword** — Detects duplicate words in comments and strings (e.g., "the the", "is is") — often copy-paste artifacts
+- **asciicheck** — Flags non-ASCII identifiers that enable homoglyph/trojan source attacks (visually identical but different Unicode codepoints)
+
+### Complexity
+
+- **gocyclo** — Cyclomatic complexity threshold (configured: 13). Functions exceeding this should be split
+- **nestif** — Detects deeply nested if/else chains that harm readability
+- **funlen** — Function length limits (configured: 120 lines, 80 statements)
+- **dupl** — Code duplication detection (configured: 100 token threshold)
+
+### Performance
+
+- **perfsprint** — Suggests faster alternatives to `fmt.Sprintf` (e.g., `strconv.Itoa` instead of `fmt.Sprintf("%d", n)`)
+- **unconvert** — Detects unnecessary type conversions (e.g., `int(x)` when `x` is already `int`)
+- **ineffassign** — Detects assignments to variables that are never subsequently read
+- **goconst** — Detects repeated string/number literals that should be extracted to constants (configured: min 3 chars, min 4 occurrences)
+
+### Security & Resources
+
+- **gosec** — Security scanner: SQL injection, hardcoded credentials, weak crypto, path traversal, unsafe usage, and 50+ other rules. The primary SAST tool in the config — never suppress without strong justification.
+- **bidichk** — Detects dangerous bidirectional Unicode sequences (CVE-2021-42574 trojan source attack — code that looks safe but executes differently)
+- **noctx** — Detects HTTP requests sent without `context.Context` (prevents proper timeouts and cancellation)
+- **containedctx** — Flags `context.Context` stored in struct fields instead of passed as a parameter (anti-pattern per Go docs)
+- **fatcontext** — Detects `context.WithValue`/`WithCancel` in loops, creating unbounded context chains that grow each iteration and cause memory leaks
+- **bodyclose** — Ensures HTTP response bodies are closed (unclosed bodies leak connections)
+- **sqlclosecheck** — Ensures `sql.Rows` and `sql.Stmt` are closed after use
+- **rowserrcheck** — Ensures `sql.Rows.Err()` is checked after iteration
+
+### Logging
+
+- **sloglint** — Enforces consistent `log/slog` code style: proper key-value pairing, message formatting, and level usage
+- **loggercheck** — Validates key-value pair formatting for structured loggers (zap, slog, logr) — detects odd numbers of args, missing keys
+
+### Testing
+
+- **thelper** — Ensures test helpers call `t.Helper()` so failures report the correct call site
+- **paralleltest** — Detects tests and subtests missing `t.Parallel()` calls
+- **testifylint** — Enforces testify best practices (e.g., `assert.Equal(t, expected, actual)` over `assert.True(t, expected == actual)`)
+- **usetesting** — Suggests `t.Setenv`/`t.TempDir` instead of `os.Setenv`/`os.MkdirTemp` in tests (automatic cleanup, proper isolation)
+
+### Modernization & Meta
+
+- **modernize** — Detects code that can be rewritten using newer Go features (requires golangci-lint v2.6.0+)
+- **exptostd** — Detects `golang.org/x/exp/` functions that now have stdlib equivalents (e.g., `slices`, `maps`, `cmp` packages added in Go 1.21)
+- **intrange** — Suggests `range N` over C-style `for i := 0; i < N; i++` loops (Go 1.22+)
+- **usestdlibvars** — Replaces hardcoded strings/numbers with stdlib constants (e.g., `http.MethodGet` instead of `"GET"`)
+- **exhaustive** — Ensures switch statements on enum types cover all possible values
+- **nolintlint** — Enforces proper `//nolint` directive usage: requires linter name and justification comment (configured with `require-explanation` and `require-specific`)
+
+### Formatting
+
+Formatters run via `golangci-lint fmt ./...`:
+
+- **gofmt** — Standard Go formatter (canonical formatting)
+- **gofumpt** — Stricter formatter with extra rules (configured with `extra-rules: true`): consistent empty lines, grouped imports, simplified code patterns
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/references/nolint-directives.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/references/nolint-directives.md
new file mode 100644
index 00000000..4600c68d
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-lint/references/nolint-directives.md
@@ -0,0 +1,68 @@
+# Nolint Directives
+
+## Syntax
+
+```go
+//nolint:lintername // justification explaining why this suppression is needed
+```
+
+Place the directive on the same line as the flagged code, or on the line immediately above it.
+
+## Rules
+
+1. **MUST specify the linter name** — bare `//nolint` suppresses all linters on that line and makes it impossible to track what is being suppressed
+2. **MUST add a justification comment** — future readers (and your future self) need to understand why
+3. **The `nolintlint` linter enforces both rules** — it will flag bare `//nolint` and missing reasons
+4. **MUST fix the root cause before suppressing** — only suppress after confirming the issue is a false positive or an intentional pattern
+
+## Examples
+
+```go
+// Specific linter with reason
+//nolint:errcheck // fire-and-forget logging, error not actionable
+_ = logger.Sync()
+
+// Type assertion is safe because preceding type switch guarantees the type
+v := x.(MyType) //nolint:forcetypeassert // guaranteed by type switch on line 42
+
+// Orchestration function has inherent complexity
+//nolint:gocyclo // orchestration function coordinating 8 subsystems
+func orchestrate() error {
+
+// Table-driven test with many cases
+//nolint:funlen // table-driven test, length is proportional to case count
+func TestParser(t *testing.T) {
+
+// Intentional parallel structure is clearer than abstracting
+//nolint:dupl // intentional parallel structure for readability
+```
+
+## Multiple Linters
+
+Suppress multiple linters on one line with comma separation:
+
+```go
+//nolint:errcheck,gosec // fire-and-forget in test helper
+```
+
+## When to Suppress vs. When to Fix
+
+**Fix** (almost always):
+
+- `errcheck` — check the error, even if just logging it
+- `govet` — these are usually real bugs
+- `staticcheck` — deprecated API usage, logic errors
+- `bodyclose`, `sqlclosecheck` — resource leaks are real issues
+
+**Suppress** (with justification):
+
+- `funlen` — table-driven tests with many cases
+- `gocyclo` — orchestration functions where splitting would obscure the flow
+- `dupl` — intentional parallel structure that is clearer than an abstraction
+- `exhaustive` — when a default case intentionally handles remaining values
+- `goconst` — when extracting to a constant would reduce clarity (e.g., test assertions)
+
+**Never suppress without strong justification**:
+
+- Security linters (`bodyclose`, `sqlclosecheck`, `rowserrcheck`) — these catch real resource leaks
+- `errcheck` on production code paths — unchecked errors cause silent failures
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/SKILL.md
new file mode 100644
index 00000000..0f2692b4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/SKILL.md
@@ -0,0 +1,152 @@
+---
+name: golang-modernize
+description: "Modernize Golang code to use recent language features, standard library improvements, and idiomatic patterns. Trigger proactively when writing or reviewing Go code and old-style patterns are detected, or when encountering a deprecation warning. Also use when the user explicitly asks for modernization, a Go version upgrade, or a CI/tooling refresh."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.2"
+  openclaw:
+    emoji: "🔄"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch WebSearch AskUserQuestion
+---
+
+<!-- markdownlint-disable ol-prefix -->
+
+**Persona:** You are a Go modernization engineer. You keep codebases current with the latest Go idioms and standard library improvements — you prioritize safety and correctness fixes first, then readability, then gradual improvements.
+
+**Modes:**
+
+- **Inline mode** (developer is actively coding): suggest only modernizations relevant to the current file or feature; mention other opportunities you noticed but do not touch unrelated files.
+- **Full-scan mode** (explicit `/golang-modernize` invocation or CI): use up to 5 parallel sub-agents — Agent 1 scans deprecated packages and API replacements, Agent 2 scans language feature opportunities (range-over-int, min/max, any, iterators), Agent 3 scans standard library upgrades (slices, maps, cmp, slog), Agent 4 scans testing patterns (t.Context, b.Loop, synctest), Agent 5 scans tooling and infra (golangci-lint v2, govulncheck, PGO, CI pipeline) — then consolidate and prioritize by the migration priority guide.
+
+# Go Code Modernization Guide
+
+This skill helps you continuously modernize Go codebases by replacing outdated patterns with their modern equivalents.
+
+**Scope**: This skill covers the last 3 years of Go modernization (Go 1.21 through Go 1.26, released 2023-2026). While this skill can be used for projects targeting Go 1.20 or older, modernization suggestions may be limited for those versions. For best results, consider upgrading the Go version first. Some older modernizations (e.g., `any` instead of `interface{}`, `errors.Is`/`errors.As`, `strings.Cut`) are included because they are still commonly missed, but many pre-1.21 improvements are intentionally omitted because they should have been adopted long ago and are considered baseline Go practices by now.
+
+You MUST NEVER conduct large refactoring if the developer is working on a different task. But TRY TO CONVINCE your human it would improve the code quality.
+
+**Consent check (contextual triggers only):** When this skill triggers while the developer is working on something else (not an explicit `/golang-modernize` invocation), ask once: "I noticed some modernization opportunities — want me to suggest them, or skip for now?" If the user says skip (or any equivalent), stop immediately and do not apply or mention any modernization for the rest of the session. Do not ask again in the current session.
+
+## Workflow
+
+When invoked:
+
+1. **Check the project's `go.mod` or `go.work`** to determine the current Go version (`go` directive)
+2. **Check the latest Go version** using the Go Version Changelogs table below and suggest upgrading if the project's `go.mod` is behind
+3. **Read `.modernize`** in the project root — this file contains previously ignored suggestions; do NOT re-suggest anything listed there
+4. **Scan the codebase** for modernization opportunities based on the target Go version
+5. **Run `golangci-lint`** with the `modernize` linter if available
+6. **Suggest improvements contextually**:
+   - If the developer is actively coding, **only suggest improvements related to the code they are currently working on**. Do not refactor unrelated files. Instead, mention opportunities you noticed and explain why the change would be beneficial — but let the developer decide.
+   - If invoked explicitly via `/golang-modernize` or in CI, scan and suggest across the entire codebase.
+7. **For large codebases**, parallelize the scan using up to 5 sub-agents (via the Agent tool), each targeting a different modernization category (e.g. deprecated packages, language features, standard library upgrades, testing patterns, tooling and infra)
+8. **Before suggesting a dependency update**, run `go mod tidy` and the test suite to verify compatibility. Ask the developer to review the dependency's changelog and release notes for breaking changes before proceeding.
+9. **If the developer explicitly ignores a suggestion**, write a short memo to `.modernize` in the project root so it is not suggested again. Format: one line per ignored suggestion, with a short description.
+
+### `.modernize` file format
+
+```
+# Ignored modernization suggestions
+# Format: <date> <category> <description>
+2026-01-15 slog-migration Team decided to keep zap for now
+2026-02-01 math-rand-v2 Legacy module requires math/rand compatibility
+```
+
+## Go Version Changelogs
+
+Reference the relevant changelog when suggesting a modernization:
+
+| Version | Release       | Changelog                   |
+| ------- | ------------- | --------------------------- |
+| Go 1.21 | August 2023   | <https://go.dev/doc/go1.21> |
+| Go 1.22 | February 2024 | <https://go.dev/doc/go1.22> |
+| Go 1.23 | August 2024   | <https://go.dev/doc/go1.23> |
+| Go 1.24 | February 2025 | <https://go.dev/doc/go1.24> |
+| Go 1.25 | August 2025   | <https://go.dev/doc/go1.25> |
+| Go 1.26 | February 2026 | <https://go.dev/doc/go1.26> |
+
+For versions newer than Go 1.26, consult the official Go release notes.
+
+When the project's `go.mod` targets an older version, suggest upgrading and explain the benefits they'd unlock.
+
+## Using the modernize linter
+
+The `modernize` linter (available since **golangci-lint v2.6.0**) automatically detects code that can be rewritten using newer Go features. It originates from `golang.org/x/tools/go/analysis/passes/modernize`; `gopls` and Go 1.26's rewritten `go fix` cover overlapping modernization checks, but exact coverage differs by tool version. See the `samber/cc-skills-golang@golang-lint` skill for configuration.
+
+## Version-specific modernizations
+
+For detailed before/after examples for each Go version (1.21–1.26) and general modernizations, see [Go version modernizations](./references/versions.md).
+
+## Tooling modernization
+
+For CI tooling, govulncheck, PGO, golangci-lint v2, and AI-powered modernization pipelines, see [Tooling modernization](./references/tooling.md).
+
+## Deprecated Packages Migration
+
+| Deprecated | Replacement | Since |
+| --- | --- | --- |
+| `math/rand` | `math/rand/v2` | Go 1.22 |
+| `crypto/elliptic` (most functions) | `crypto/ecdh` | Go 1.21 |
+| `reflect.SliceHeader`, `StringHeader` | `unsafe.Slice`, `unsafe.String` | Go 1.21 |
+| `reflect.PtrTo` | `reflect.PointerTo` | Go 1.22 |
+| `runtime.GOROOT()` | `go env GOROOT` | Go 1.24 |
+| `runtime.SetFinalizer` | `runtime.AddCleanup` | Go 1.24 |
+| `crypto/cipher.NewOFB`, `NewCFB*` | AEAD modes or `NewCTR` | Go 1.24 |
+| `golang.org/x/crypto/sha3` | `crypto/sha3` | Go 1.24 |
+| `golang.org/x/crypto/hkdf` | `crypto/hkdf` | Go 1.24 |
+| `golang.org/x/crypto/pbkdf2` | `crypto/pbkdf2` | Go 1.24 |
+| `testing/synctest.Run` | `testing/synctest.Test` | Go 1.25 |
+| `crypto/rsa.EncryptPKCS1v15` for new encryption use | RSA-OAEP (`rsa.EncryptOAEP` / `rsa.EncryptOAEPWithOptions`) or HPKE/KEM design | Go 1.26 |
+| `net/http/httputil.ReverseProxy.Director` | `ReverseProxy.Rewrite` | Go 1.26 |
+
+## Migration Priority Guide
+
+When modernizing a codebase, prioritize changes by impact:
+
+### High priority (safety and correctness)
+
+1. Remove loop variable shadow copies _(Go 1.22+)_ — prevents subtle bugs
+2. Replace `math/rand` with `math/rand/v2` _(Go 1.22+)_ — remove `rand.Seed` calls
+3. Use `os.Root` for user-supplied file paths _(Go 1.24+)_ — prevents path traversal
+4. Run `govulncheck` _(Go 1.22+)_ — catch known vulnerabilities
+5. Use `errors.Is`/`errors.As` instead of direct comparison _(Go 1.13+)_
+6. Migrate deprecated crypto packages _(Go 1.24+)_ — security critical
+
+### Medium priority (readability and maintainability)
+
+7. Replace `interface{}` with `any` _(Go 1.18+)_
+8. Use `min`/`max` builtins _(Go 1.21+)_
+9. Use `range` over int _(Go 1.22+)_
+10. Use `slices` and `maps` packages _(Go 1.21+)_
+11. Use `cmp.Or` for default values _(Go 1.22+)_
+12. Use `sync.OnceValue`/`sync.OnceFunc` _(Go 1.21+)_
+13. Use `sync.WaitGroup.Go` _(Go 1.25+)_
+14. Use `t.Context()` in tests _(Go 1.24+)_
+15. Use `b.Loop()` in benchmarks _(Go 1.24+)_
+
+### Lower priority (gradual improvement)
+
+16. Migrate to `slog` from third-party loggers _(Go 1.21+)_
+17. Adopt iterators where they simplify code _(Go 1.23+)_
+18. Replace `sort.Slice` with `slices.SortFunc` _(Go 1.21+)_
+19. Use `strings.SplitSeq` and iterator variants _(Go 1.24+)_
+20. Move tool deps to `go.mod` tool directives _(Go 1.24+)_
+21. Enable PGO for production builds _(Go 1.21+)_
+22. Upgrade to golangci-lint v2 with modernize linter _(golangci-lint v2.6.0+)_
+23. Add `govulncheck` to CI pipeline
+24. Set up monthly modernization CI pipeline
+25. Evaluate `encoding/json/v2` only when the project explicitly opts into `GOEXPERIMENT=jsonv2` _(Go 1.25+, experimental)_
+26. Set up AI-driven code review in CI — loads these skills to guide review per area; see `samber/cc-skills-golang@golang-continuous-integration`
+
+## Related Skills
+
+See `samber/cc-skills-golang@golang-concurrency`, `samber/cc-skills-golang@golang-testing`, `samber/cc-skills-golang@golang-observability`, `samber/cc-skills-golang@golang-error-handling`, `samber/cc-skills-golang@golang-lint`, `samber/cc-skills-golang@golang-continuous-integration` skills.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/evals/evals.json
new file mode 100644
index 00000000..321bc088
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/evals/evals.json
@@ -0,0 +1,183 @@
+{
+  "skill_name": "golang-modernize",
+  "evals": [
+    {
+      "id": 1,
+      "name": "version-constraint-1.21",
+      "prompt": "Review this Go code for modernization opportunities. The project targets Go 1.21.\n\n```go\n// go.mod\nmodule example.com/myapp\ngo 1.21\n\n// main.go\npackage main\n\nimport (\n    \"fmt\"\n    \"math/rand\"\n    \"sort\"\n    \"sync\"\n    \"time\"\n)\n\nfunc minInt(a, b int) int {\n    if a < b { return a }\n    return b\n}\n\nfunc maxInt(a, b int) int {\n    if a > b { return a }\n    return b\n}\n\nfunc processItems(items []string) {\n    sort.Strings(items)\n    found := false\n    for _, v := range items {\n        if v == \"target\" { found = true; break }\n    }\n    _ = found\n}\n\nfunc processN(n int) {\n    for i := 0; i < n; i++ {\n        fmt.Println(i)\n    }\n}\n\nfunc startWorkers(items []int) {\n    for _, v := range items {\n        v := v // shadow copy for closure\n        go func() { fmt.Println(v) }()\n    }\n}\n\nvar (\n    once   sync.Once\n    client *int\n)\nfunc getClient() *int {\n    once.Do(func() {\n        c := 42\n        client = &c\n    })\n    return client\n}\n\nfunc main() {\n    rand.Seed(time.Now().UnixNano())\n    n := rand.Intn(100)\n    fmt.Println(minInt(n, 50), maxInt(n, 10))\n    processItems([]string{\"a\", \"b\", \"c\"})\n    processN(10)\n    startWorkers([]int{1, 2, 3})\n}\n```\n\nSuggest all modernization improvements available for this Go version.",
+      "trap": "The project targets Go 1.21. Features like range-over-int (1.22), loop variable fix (1.22), cmp.Or (1.22), and math/rand/v2 (1.22) are NOT available. The model must only suggest 1.21-compatible changes AND must avoid false positives by staying within version constraints.",
+      "assertions": [
+        { "id": "1.1", "text": "Suggests min/max builtins to replace minInt/maxInt (available in Go 1.21)" },
+        { "id": "1.2", "text": "Suggests slices.Sort or slices.Contains (available in Go 1.21)" },
+        { "id": "1.3", "text": "Suggests sync.OnceValue to replace manual sync.Once pattern (available in Go 1.21)" },
+        { "id": "1.4", "text": "Does NOT suggest range-over-int for processN (requires Go 1.22+)" },
+        { "id": "1.5", "text": "Does NOT suggest removing loop variable shadow copy v := v in startWorkers (requires Go 1.22+)" },
+        { "id": "1.6", "text": "Does NOT suggest math/rand/v2 migration (requires Go 1.22+)" },
+        { "id": "1.7", "text": "Does NOT suggest cmp.Or (requires Go 1.22+)" }
+      ]
+    },
+    {
+      "id": 2,
+      "name": "rand-v2-api-renames",
+      "prompt": "Migrate this Go code from math/rand to math/rand/v2. The project targets Go 1.22.\n\n```go\npackage game\n\nimport (\n    \"crypto/rand\"\n    \"math/big\"\n    mathrand \"math/rand\"\n    \"time\"\n)\n\nvar rng *mathrand.Rand\n\nfunc init() {\n    mathrand.Seed(time.Now().UnixNano())\n    rng = mathrand.New(mathrand.NewSource(time.Now().UnixNano()))\n}\n\nfunc RollDice() int {\n    return mathrand.Intn(6) + 1\n}\n\nfunc GenerateID() int64 {\n    return mathrand.Int63n(1000000)\n}\n\nfunc ShuffleCards(cards []string) {\n    mathrand.Shuffle(len(cards), func(i, j int) {\n        cards[i], cards[j] = cards[j], cards[i]\n    })\n}\n\nfunc RandomFloat() float64 {\n    return mathrand.Float64()\n}\n\nfunc RandomBytes(n int) []byte {\n    buf := make([]byte, n)\n    mathrand.Read(buf)\n    return buf\n}\n\nfunc CryptoRandom() int {\n    n, _ := rand.Int(rand.Reader, big.NewInt(100))\n    return int(n.Int64())\n}\n```\n\nProvide the complete migrated code.",
+      "trap": "math/rand/v2 renames functions: Intn->IntN, Int63n->Int64N. Read is removed entirely. Seed is unnecessary. Without the skill, the model may keep old function names.",
+      "assertions": [
+        { "id": "2.1", "text": "Renames Intn to IntN (capital N)" },
+        { "id": "2.2", "text": "Renames Int63n to Int64N (not Int63N or Int64n)" },
+        { "id": "2.3", "text": "Removes all rand.Seed calls (automatic seeding in v2)" },
+        { "id": "2.4", "text": "Replaces rand.Read with crypto/rand usage for random bytes" },
+        { "id": "2.5", "text": "Import changes to math/rand/v2" },
+        { "id": "2.6", "text": "Does NOT keep any old-style function names (no rand.Intn or rand.Int63n in output)" }
+      ]
+    },
+    {
+      "id": 3,
+      "name": "safety-over-cosmetic",
+      "prompt": "Modernize this Go 1.24 HTTP file server code. Suggest all improvements.\n\n```go\npackage fileserver\n\nimport (\n    \"fmt\"\n    \"io\"\n    \"net/http\"\n    \"os\"\n    \"path/filepath\"\n)\n\ntype FileServer struct {\n    baseDir string\n}\n\nfunc NewFileServer(baseDir string) *FileServer {\n    return &FileServer{baseDir: baseDir}\n}\n\nfunc (fs *FileServer) ServeHTTP(w http.ResponseWriter, r *http.Request) {\n    userPath := r.URL.Query().Get(\"path\")\n    if userPath == \"\" {\n        http.Error(w, \"missing path parameter\", http.StatusBadRequest)\n        return\n    }\n\n    fullPath := filepath.Join(fs.baseDir, filepath.Clean(userPath))\n\n    f, err := os.Open(fullPath)\n    if err != nil {\n        http.Error(w, \"file not found\", http.StatusNotFound)\n        return\n    }\n    defer f.Close()\n\n    w.Header().Set(\"Content-Type\", \"application/octet-stream\")\n    io.Copy(w, f)\n}\n\nfunc process(data interface{}) interface{} {\n    return data\n}\n\nfunc minVal(a, b int) int {\n    if a < b { return a }\n    return b\n}\n\nfunc formatAddr(host string, port int) string {\n    return fmt.Sprintf(\"%s:%d\", host, port)\n}\n```\n\nThe project targets Go 1.24. List improvements in priority order.",
+      "trap": "The code has a path traversal vulnerability (filepath.Join + filepath.Clean is insufficient). Without the skill, the model may prioritize cosmetic changes (interface{}->any, min builtin) over the security-critical os.Root fix.",
+      "assertions": [
+        { "id": "3.1", "text": "Suggests os.Root/os.OpenRoot for user-supplied file paths" },
+        { "id": "3.2", "text": "Mentions path traversal risk, directory escape, or CWE-22" },
+        { "id": "3.3", "text": "Prioritizes the safety fix (os.Root) over cosmetic changes" },
+        { "id": "3.4", "text": "Also suggests interface{} -> any" },
+        { "id": "3.5", "text": "Also suggests min builtin or net.JoinHostPort" },
+        { "id": "3.6", "text": "Does NOT only address cosmetic issues without mentioning the security issue" }
+      ]
+    },
+    {
+      "id": 4,
+      "name": "omitzero-vs-omitempty",
+      "prompt": "Review these JSON struct tags for correctness in our Go 1.24 API. Users report that zero-value time fields and false booleans are unexpectedly included or omitted in JSON responses.\n\n```go\npackage api\n\nimport \"time\"\n\ntype Event struct {\n    ID        string    `json:\"id\"`\n    Name      string    `json:\"name\"`\n    StartAt   time.Time `json:\"start_at,omitempty\"`\n    EndAt     time.Time `json:\"end_at,omitempty\"`\n    Cancelled bool      `json:\"cancelled,omitempty\"`\n    Archived  bool      `json:\"archived,omitempty\"`\n    Notes     string    `json:\"notes,omitempty\"`\n    Priority  int       `json:\"priority,omitempty\"`\n}\n\ntype UserSettings struct {\n    UserID           string    `json:\"user_id\"`\n    DarkMode         bool      `json:\"dark_mode,omitempty\"`\n    EmailNotifs      bool      `json:\"email_notifs,omitempty\"`\n    LastLogin        time.Time `json:\"last_login,omitempty\"`\n    AccountCreated   time.Time `json:\"account_created,omitempty\"`\n    Bio              string    `json:\"bio,omitempty\"`\n}\n```\n\nExplain the issue and provide the corrected code.",
+      "trap": "omitempty doesn't work correctly for time.Time (zero time is a non-empty struct) and treats false as empty for bool. Go 1.24 introduced omitzero which handles both correctly. Without the skill, the model may not know about omitzero.",
+      "assertions": [
+        { "id": "4.1", "text": "Identifies that omitempty doesn't omit zero time.Time (it's a non-empty struct)" },
+        { "id": "4.2", "text": "Suggests omitzero for time.Time fields (StartAt, EndAt, LastLogin, AccountCreated)" },
+        { "id": "4.3", "text": "Identifies that omitempty treats false as empty for bool fields" },
+        { "id": "4.4", "text": "Addresses bool issue correctly (removes tag or uses omitzero)" },
+        { "id": "4.5", "text": "Correctly notes omitzero requires Go 1.24+" },
+        { "id": "4.6", "text": "Does NOT suggest omitzero for string or int fields where omitempty works correctly" }
+      ]
+    },
+    {
+      "id": 5,
+      "name": "benchmark-b-loop",
+      "prompt": "Modernize these benchmarks for our Go 1.24 project.\n\n```go\npackage encoding\n\nimport (\n    \"encoding/json\"\n    \"testing\"\n)\n\ntype Payload struct {\n    ID    int    `json:\"id\"`\n    Name  string `json:\"name\"`\n    Value float64 `json:\"value\"`\n}\n\nfunc BenchmarkMarshal(b *testing.B) {\n    p := Payload{ID: 1, Name: \"test\", Value: 3.14}\n    for i := 0; i < b.N; i++ {\n        json.Marshal(p)\n    }\n}\n\nfunc BenchmarkUnmarshal(b *testing.B) {\n    data := []byte(`{\"id\":1,\"name\":\"test\",\"value\":3.14}`)\n    var p Payload\n    for n := 0; n < b.N; n++ {\n        json.Unmarshal(data, &p)\n    }\n}\n\nfunc BenchmarkRoundTrip(b *testing.B) {\n    p := Payload{ID: 1, Name: \"test\", Value: 3.14}\n    for i := 0; i < b.N; i++ {\n        data, _ := json.Marshal(p)\n        var p2 Payload\n        json.Unmarshal(data, &p2)\n    }\n}\n```\n\nProvide the modernized benchmark code.",
+      "trap": "Go 1.24 introduced b.Loop() which replaces the manual for i := 0; i < b.N; i++ pattern. Without the skill, the model likely doesn't know about b.Loop().",
+      "assertions": [
+        { "id": "5.1", "text": "Replaces for i := 0; i < b.N; i++ with for b.Loop() in BenchmarkMarshal" },
+        { "id": "5.2", "text": "Replaces for n := 0; n < b.N; n++ with for b.Loop() in BenchmarkUnmarshal" },
+        { "id": "5.3", "text": "Replaces the b.N loop in BenchmarkRoundTrip too" },
+        { "id": "5.4", "text": "Does NOT keep any b.N iteration pattern in the output" },
+        { "id": "5.5", "text": "Preserves benchmark function names and logic" }
+      ]
+    },
+    {
+      "id": 6,
+      "name": "automaxprocs-removal",
+      "prompt": "We just upgraded to Go 1.25. Review our main.go for modernization opportunities.\n\n```go\n// go.mod\nmodule example.com/worker\ngo 1.25\n\nrequire (\n    go.uber.org/automaxprocs v1.5.3\n    go.uber.org/zap v1.27.0\n)\n\n// main.go\npackage main\n\nimport (\n    \"fmt\"\n    \"sync\"\n\n    _ \"go.uber.org/automaxprocs\"\n)\n\nfunc main() {\n    var wg sync.WaitGroup\n    items := []string{\"a\", \"b\", \"c\", \"d\", \"e\"}\n\n    for _, item := range items {\n        wg.Add(1)\n        go func() {\n            defer wg.Done()\n            process(item)\n        }()\n    }\n    wg.Wait()\n}\n\nfunc process(item string) {\n    fmt.Println(\"processing\", item)\n}\n```\n\nSuggest all modernization improvements.",
+      "trap": "Go 1.25 has built-in container-aware GOMAXPROCS, making uber-go/automaxprocs unnecessary. The model must know this Go 1.25 addition — without the skill it will likely treat automaxprocs as still needed and only suggest sync.WaitGroup.Go.",
+      "assertions": [
+        { "id": "6.1", "text": "Suggests removing go.uber.org/automaxprocs import and dependency" },
+        { "id": "6.2", "text": "Explains that Go 1.25 has built-in container-aware GOMAXPROCS (or cgroup CPU limits awareness)" },
+        { "id": "6.3", "text": "Suggests sync.WaitGroup.Go to replace Add/go func/Done pattern" },
+        { "id": "6.4", "text": "Does NOT suggest keeping the automaxprocs dependency as still necessary" },
+        { "id": "6.5", "text": "Suggests running go mod tidy to remove the dependency from go.sum" }
+      ]
+    },
+    {
+      "id": 7,
+      "name": "cmp-or-chained-defaults",
+      "prompt": "Clean up this configuration loading code. We're on Go 1.22. The nested if/else chains for default values are hard to read.\n\n```go\npackage config\n\nimport \"os\"\n\ntype Config struct {\n    Host     string\n    Port     string\n    LogLevel string\n    Region   string\n    Mode     string\n}\n\nfunc LoadConfig() Config {\n    host := os.Getenv(\"HOST\")\n    if host == \"\" {\n        host = os.Getenv(\"HOSTNAME\")\n    }\n    if host == \"\" {\n        host = os.Getenv(\"SERVICE_HOST\")\n    }\n    if host == \"\" {\n        host = \"localhost\"\n    }\n\n    port := os.Getenv(\"PORT\")\n    if port == \"\" {\n        port = os.Getenv(\"HTTP_PORT\")\n    }\n    if port == \"\" {\n        port = \"8080\"\n    }\n\n    logLevel := os.Getenv(\"LOG_LEVEL\")\n    if logLevel == \"\" {\n        logLevel = os.Getenv(\"LOGLEVEL\")\n    }\n    if logLevel == \"\" {\n        logLevel = \"info\"\n    }\n\n    region := os.Getenv(\"AWS_REGION\")\n    if region == \"\" {\n        region = os.Getenv(\"REGION\")\n    }\n    if region == \"\" {\n        region = \"us-east-1\"\n    }\n\n    mode := os.Getenv(\"APP_MODE\")\n    if mode == \"\" {\n        mode = \"production\"\n    }\n\n    return Config{\n        Host:     host,\n        Port:     port,\n        LogLevel: logLevel,\n        Region:   region,\n        Mode:     mode,\n    }\n}\n```\n\nProvide the cleaned-up code.",
+      "trap": "Go 1.22 introduced cmp.Or(a, b, c...) which returns the first non-zero value. It collapses multi-step default chains to single lines. Without the skill, the model will likely keep the if/else chains or use a custom helper function.",
+      "assertions": [
+        { "id": "7.1", "text": "Uses cmp.Or for at least one default value chain" },
+        { "id": "7.2", "text": "Collapses the 3-step host default to a single cmp.Or call" },
+        { "id": "7.3", "text": "Import includes the cmp package" },
+        { "id": "7.4", "text": "All multi-step defaults converted to cmp.Or (host, port, logLevel, region)" },
+        { "id": "7.5", "text": "Result is functionally equivalent (same fallback order)" },
+        { "id": "7.6", "text": "Does NOT introduce a custom helper function for defaults" }
+      ]
+    },
+    {
+      "id": 8,
+      "name": "addcleanup-vs-setfinalizer",
+      "prompt": "Review this resource management code for Go 1.24 best practices.\n\n```go\npackage pool\n\nimport (\n    \"database/sql\"\n    \"fmt\"\n    \"runtime\"\n)\n\ntype ManagedConn struct {\n    db   *sql.DB\n    name string\n    dsn  string\n}\n\nfunc NewManagedConn(dsn, name string) (*ManagedConn, error) {\n    db, err := sql.Open(\"postgres\", dsn)\n    if err != nil {\n        return nil, fmt.Errorf(\"opening db: %w\", err)\n    }\n    mc := &ManagedConn{db: db, name: name, dsn: dsn}\n    runtime.SetFinalizer(mc, func(c *ManagedConn) {\n        c.db.Close()\n    })\n    return mc, nil\n}\n\ntype TempFile struct {\n    path string\n    fd   int\n}\n\nfunc NewTempFile(path string, fd int) *TempFile {\n    tf := &TempFile{path: path, fd: fd}\n    runtime.SetFinalizer(tf, func(f *TempFile) {\n        syscallClose(f.fd)\n        osRemove(f.path)\n    })\n    return tf\n}\n\nfunc syscallClose(fd int) {}\nfunc osRemove(path string) {}\n```\n\nModernize the cleanup pattern. Explain why the current approach has problems.",
+      "trap": "New Go code should consider runtime.AddCleanup instead of runtime.SetFinalizer because it is less error-prone. The key API difference: AddCleanup takes the resource as a separate argument (not the whole object). Without the skill the model is unlikely to know AddCleanup exists or that SetFinalizer's cycle restriction is a major problem.",
+      "assertions": [
+        { "id": "8.1", "text": "Replaces runtime.SetFinalizer with runtime.AddCleanup" },
+        { "id": "8.2", "text": "AddCleanup cleanup function receives the resource (db/*sql.DB or fd/int) as a separate argument, NOT the whole wrapper struct" },
+        { "id": "8.3", "text": "Explains that SetFinalizer prevents GC when the object holds a reference to itself or another object with a finalizer (cycle restriction)" },
+        { "id": "8.4", "text": "Does NOT pass ManagedConn or TempFile directly as the resource to AddCleanup" },
+        { "id": "8.5", "text": "Correctly attributes runtime.AddCleanup to Go 1.24 (or notes it is the modern replacement)" }
+      ]
+    },
+    {
+      "id": 9,
+      "name": "http-mux-migration",
+      "prompt": "We want to remove our gorilla/mux dependency. Migrate this REST API router to stdlib. We're on Go 1.22.\n\n```go\npackage api\n\nimport (\n    \"encoding/json\"\n    \"net/http\"\n\n    \"github.com/gorilla/mux\"\n)\n\nfunc SetupRouter() *mux.Router {\n    r := mux.NewRouter()\n    r.HandleFunc(\"/api/users\", listUsers).Methods(\"GET\")\n    r.HandleFunc(\"/api/users\", createUser).Methods(\"POST\")\n    r.HandleFunc(\"/api/users/{id}\", getUser).Methods(\"GET\")\n    r.HandleFunc(\"/api/users/{id}\", updateUser).Methods(\"PUT\")\n    r.HandleFunc(\"/api/users/{id}\", deleteUser).Methods(\"DELETE\")\n    r.HandleFunc(\"/api/health\", healthCheck).Methods(\"GET\")\n    return r\n}\n\nfunc getUser(w http.ResponseWriter, r *http.Request) {\n    vars := mux.Vars(r)\n    id := vars[\"id\"]\n    json.NewEncoder(w).Encode(map[string]string{\"id\": id})\n}\n\nfunc listUsers(w http.ResponseWriter, r *http.Request)  { json.NewEncoder(w).Encode([]string{\"user1\", \"user2\"}) }\nfunc createUser(w http.ResponseWriter, r *http.Request)  { w.WriteHeader(http.StatusCreated) }\nfunc updateUser(w http.ResponseWriter, r *http.Request)  { w.WriteHeader(http.StatusOK) }\nfunc deleteUser(w http.ResponseWriter, r *http.Request)  { w.WriteHeader(http.StatusNoContent) }\nfunc healthCheck(w http.ResponseWriter, r *http.Request) { w.WriteHeader(http.StatusOK) }\n```\n\nProvide the complete migrated code.",
+      "trap": "Go 1.22 added method+path pattern routing to net/http. The exact syntax is 'METHOD /path/{param}' as the pattern string. mux.Vars(r) becomes r.PathValue('id'). Without the skill, the model might not use the correct syntax or might suggest a different third-party router.",
+      "assertions": [
+        { "id": "9.1", "text": "Uses http.NewServeMux() instead of mux.NewRouter()" },
+        { "id": "9.2", "text": "Uses method prefix in patterns like 'GET /api/users/{id}'" },
+        { "id": "9.3", "text": "Uses r.PathValue(\"id\") instead of mux.Vars(r)" },
+        { "id": "9.4", "text": "All 6 routes migrated with correct method prefixes (GET, POST, PUT, DELETE)" },
+        { "id": "9.5", "text": "No gorilla/mux import remains" },
+        { "id": "9.6", "text": "Return type changes from *mux.Router to *http.ServeMux" }
+      ]
+    },
+    {
+      "id": 10,
+      "name": "synctest-flaky-fix",
+      "prompt": "This concurrent test is flaky in CI — it passes locally but fails ~20% of the time in GitHub Actions. Fix it properly. We're on Go 1.25.\n\n```go\npackage pubsub\n\nimport (\n    \"sync\"\n    \"testing\"\n    \"time\"\n)\n\ntype Broker struct {\n    mu   sync.RWMutex\n    subs map[string][]chan string\n}\n\nfunc NewBroker() *Broker {\n    return &Broker{subs: make(map[string][]chan string)}\n}\n\nfunc (b *Broker) Subscribe(topic string) <-chan string {\n    b.mu.Lock()\n    defer b.mu.Unlock()\n    ch := make(chan string, 10)\n    b.subs[topic] = append(b.subs[topic], ch)\n    return ch\n}\n\nfunc (b *Broker) Publish(topic, msg string) {\n    b.mu.RLock()\n    defer b.mu.RUnlock()\n    for _, ch := range b.subs[topic] {\n        ch <- msg\n    }\n}\n\nfunc TestBrokerPubSub(t *testing.T) {\n    b := NewBroker()\n    ch1 := b.Subscribe(\"events\")\n    ch2 := b.Subscribe(\"events\")\n\n    go b.Publish(\"events\", \"hello\")\n\n    time.Sleep(50 * time.Millisecond) // flaky!\n\n    got1 := <-ch1\n    got2 := <-ch2\n\n    if got1 != \"hello\" {\n        t.Errorf(\"ch1: got %q, want %q\", got1, \"hello\")\n    }\n    if got2 != \"hello\" {\n        t.Errorf(\"ch2: got %q, want %q\", got2, \"hello\")\n    }\n}\n\nfunc TestBrokerMultiTopic(t *testing.T) {\n    b := NewBroker()\n    events := b.Subscribe(\"events\")\n    logs := b.Subscribe(\"logs\")\n\n    go func() {\n        b.Publish(\"events\", \"event1\")\n        b.Publish(\"logs\", \"log1\")\n    }()\n\n    time.Sleep(100 * time.Millisecond) // flaky!\n\n    if got := <-events; got != \"event1\" {\n        t.Errorf(\"events: got %q, want %q\", got, \"event1\")\n    }\n    if got := <-logs; got != \"log1\" {\n        t.Errorf(\"logs: got %q, want %q\", got, \"log1\")\n    }\n}\n```\n\nFix the flakiness without increasing sleep durations.",
+      "trap": "Go 1.25 introduced testing/synctest.Test which provides deterministic concurrent testing with synctest.Wait(). The natural fix is to increase sleep, use channels for sync, or add retries. The skill teaches synctest.Test as the modern solution. Note: synctest.Run was the old Go 1.24 experimental API — use synctest.Test in Go 1.25+.",
+      "assertions": [
+        { "id": "10.1", "text": "Uses synctest.Test (NOT the old Go 1.24 experimental synctest.Run API)" },
+        { "id": "10.2", "text": "Uses synctest.Wait() for goroutine synchronization" },
+        { "id": "10.3", "text": "Removes all time.Sleep calls" },
+        { "id": "10.4", "text": "No flaky timing dependencies remain" },
+        { "id": "10.5", "text": "Correctly imports testing/synctest" },
+        { "id": "10.6", "text": "Both tests converted (TestBrokerPubSub and TestBrokerMultiTopic)" }
+      ]
+    },
+    {
+      "id": 11,
+      "name": "waitgroup-go-loopvar",
+      "prompt": "Modernize this concurrent processing code. We're on Go 1.25.\n\n```go\npackage worker\n\nimport (\n    \"context\"\n    \"fmt\"\n    \"sync\"\n    \"testing\"\n)\n\nfunc ProcessAll(items []string) error {\n    var wg sync.WaitGroup\n    errCh := make(chan error, len(items))\n\n    for _, item := range items {\n        item := item // shadow copy for closure safety\n        wg.Add(1)\n        go func() {\n            defer wg.Done()\n            if err := process(item); err != nil {\n                errCh <- err\n            }\n        }()\n    }\n\n    wg.Wait()\n    close(errCh)\n\n    for err := range errCh {\n        return err\n    }\n    return nil\n}\n\nfunc RunBatch(tasks []func()) {\n    var wg sync.WaitGroup\n    for _, task := range tasks {\n        task := task\n        wg.Add(1)\n        go func() {\n            defer wg.Done()\n            task()\n        }()\n    }\n    wg.Wait()\n}\n\nfunc TestProcess(t *testing.T) {\n    ctx := context.Background()\n    result, err := processWithContext(ctx, \"test\")\n    if err != nil {\n        t.Fatal(err)\n    }\n    fmt.Println(result)\n}\n\nfunc process(item string) error { return nil }\nfunc processWithContext(ctx context.Context, s string) (string, error) { return s, nil }\n```\n\nProvide the fully modernized code.",
+      "trap": "Go 1.25 introduced sync.WaitGroup.Go. Go 1.22+ fixed loop variable semantics (v := v copies are unnecessary). Go 1.24+ has t.Context(). Without the skill, the model may not know WaitGroup.Go exists and may keep the shadow copies.",
+      "assertions": [
+        { "id": "11.1", "text": "Replaces Add/go func/Done pattern with wg.Go(func() { ... })" },
+        { "id": "11.2", "text": "Removes wg.Add(1) calls" },
+        { "id": "11.3", "text": "Removes defer wg.Done() calls" },
+        { "id": "11.4", "text": "Removes item := item loop variable shadow copies" },
+        { "id": "11.5", "text": "Explains Go 1.22+ loop variable semantics make copies unnecessary" },
+        { "id": "11.6", "text": "Replaces context.Background() with t.Context() in test" },
+        { "id": "11.7", "text": "Preserves WaitGroup.Wait() call" }
+      ]
+    },
+    {
+      "id": 12,
+      "name": "timer-gc-greenteagc",
+      "prompt": "We upgraded to Go 1.26. Review this code for things we can clean up.\n\n```go\n// go.mod\nmodule example.com/scheduler\ngo 1.26\n\n// scheduler.go\npackage scheduler\n\nimport (\n    \"os\"\n    \"runtime/debug\"\n    \"time\"\n)\n\nfunc init() {\n    // Tune GC for lower latency\n    debug.SetGCPercent(50)\n    debug.SetMemoryLimit(2 << 30) // 2GB\n    os.Setenv(\"GOGC\", \"50\")\n}\n\nfunc RunAfter(d time.Duration, fn func()) {\n    timer := time.NewTimer(d)\n    defer timer.Stop() // prevent timer leak\n    <-timer.C\n    fn()\n}\n\nfunc PeriodicTask(interval time.Duration, fn func()) chan struct{} {\n    done := make(chan struct{})\n    go func() {\n        ticker := time.NewTicker(interval)\n        defer ticker.Stop() // prevent ticker leak\n        for {\n            select {\n            case <-ticker.C:\n                fn()\n            case <-done:\n                return\n            }\n        }\n    }()\n    return done\n}\n\nfunc Debounce(d time.Duration, fn func()) func() {\n    var timer *time.Timer\n    return func() {\n        if timer != nil {\n            timer.Stop()\n        }\n        timer = time.AfterFunc(d, fn)\n    }\n}\n\nfunc Timeout(d time.Duration) <-chan time.Time {\n    timer := time.NewTimer(d)\n    defer timer.Stop()\n    return timer.C\n}\n```\n\nSuggest all modernization opportunities.",
+      "trap": "Go 1.23+ timers/tickers are GC'd without Stop(). The Stop() in PeriodicTask is still needed for correctness. Go 1.26's Green Tea GC (10-40% overhead reduction) may make manual tuning unnecessary. go fix ./... is available in Go 1.26.",
+      "assertions": [
+        { "id": "12.1", "text": "Identifies that some defer timer.Stop() calls are unnecessary with Go 1.23+" },
+        { "id": "12.2", "text": "Explains the timer/ticker GC behavior change (collected without Stop)" },
+        { "id": "12.3", "text": "Suggests reviewing GC tuning (SetGCPercent/SetMemoryLimit) due to Green Tea GC" },
+        { "id": "12.4", "text": "Mentions Green Tea GC's 10-40% overhead reduction" },
+        { "id": "12.5", "text": "Does NOT suggest removing Stop() from PeriodicTask ticker (needed for correctness)" },
+        { "id": "12.6", "text": "Suggests go fix ./... for automated modernization (Go 1.26)" },
+        { "id": "12.7", "text": "Correctly distinguishes between Stop for GC (removable) and Stop for correctness (keep)" }
+      ]
+    },
+    {
+      "id": 13,
+      "name": "go126-errors-astype-enhanced-new",
+      "prompt": "Modernize this Go 1.26 error handling and pointer helper code.\n\n```go\npackage service\n\nimport (\n    \"errors\"\n    \"fmt\"\n    \"net\"\n    \"os\"\n    \"time\"\n)\n\nfunc ptr[T any](v T) *T { return &v }\n\ntype ServiceConfig struct {\n    Timeout  *time.Duration\n    Retries  *int\n    Verbose  *bool\n}\n\nfunc DefaultConfig() ServiceConfig {\n    return ServiceConfig{\n        Timeout: ptr(30 * time.Second),\n        Retries: ptr(3),\n        Verbose: ptr(false),\n    }\n}\n\nfunc HandleError(err error) string {\n    var pathErr *os.PathError\n    if errors.As(err, &pathErr) {\n        return fmt.Sprintf(\"path error: %s\", pathErr.Path)\n    }\n\n    var netErr *net.OpError\n    if errors.As(err, &netErr) {\n        return fmt.Sprintf(\"net error: %s %s\", netErr.Op, netErr.Net)\n    }\n\n    var dnsErr *net.DNSError\n    if errors.As(err, &dnsErr) {\n        return fmt.Sprintf(\"dns error: %s\", dnsErr.Name)\n    }\n\n    return err.Error()\n}\n```\n\nApply all Go 1.26 modernizations. Provide the updated code.",
+      "trap": "Go 1.26 introduced errors.AsType[T]() which replaces the verbose var+errors.As pattern with a single-line if. Go 1.26 also enhanced new() to accept an initial value, replacing the ptr[T] helper. Without the skill, the model likely won't know either feature exists.",
+      "assertions": [
+        { "id": "13.1", "text": "Uses errors.AsType[*os.PathError](err) or similar generic form instead of var+errors.As" },
+        { "id": "13.2", "text": "Replaces the ptr[T] helper function with new() that accepts an initial value (e.g., new(30 * time.Second))" }
+      ]
+    }
+  ]
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/references/tooling.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/references/tooling.md
new file mode 100644
index 00000000..ff277675
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/references/tooling.md
@@ -0,0 +1,60 @@
+# Tooling Modernization
+
+Beyond the Go language itself, suggest updating all non-functional developer tools that improve code quality or security for free. These are low-risk, high-value improvements: CI actions/plugins, linters (e.g. golangci-lint), SAST tools (e.g. gosec, Snyk, Semgrep), vulnerability scanners (e.g. govulncheck, Trivy), Docker base images, test coverage reporters, dependency management bots (e.g. Renovate, Dependabot), etc.
+
+## Update to the latest Go version
+
+Compare the project's `go` directive in `go.mod` against the latest stable release and suggest updating it and the `toolchain` directive if present. Each Go release brings performance improvements, security fixes, and new features.
+
+```bash
+# Check current version
+go version
+
+# Update go.mod to target a newer version
+go mod edit -go=1.26
+
+# Update toolchain
+go get toolchain@latest
+```
+
+## golangci-lint v2 _(golangci-lint v2.0.0+, March 2025)_
+
+Upgrade to golangci-lint v2. **Migration**: Run `golangci-lint migrate` to convert v1 config to v2. See the `samber/cc-skills-golang@golang-lint` skill for the recommended configuration.
+
+## govulncheck _(works best with Go 1.22+)_
+
+`govulncheck` scans Go code for known vulnerabilities using the Go vulnerability database at `vuln.go.dev`. It analyzes call graphs to report only **reachable** vulnerabilities.
+
+**Note**: The vulnerability database tracks Go standard library issues starting from Go 1.18. Third-party module vulnerabilities are tracked regardless of Go version. For best results (better call graph analysis), use Go 1.22+.
+
+```bash
+# Pin in the module (Go 1.24+)
+go get -tool golang.org/x/vuln/cmd/govulncheck@latest
+
+# Scan source code
+go tool govulncheck ./...
+
+# Scan a compiled binary
+go tool govulncheck -mode=binary ./myapp
+```
+
+## Profile-Guided Optimization (PGO) _(Go 1.21+)_
+
+PGO is generally available since Go 1.21, providing 2-14% performance improvements:
+
+```bash
+# 1. Build and run with CPU profiling
+go test -cpuprofile=default.pgo -bench=. ./...
+
+# 2. Place default.pgo in the main package directory
+# 3. Rebuild — PGO is applied automatically
+go build ./...
+```
+
+Go 1.22+ expanded PGO to devirtualize more interface calls. Go 1.23+ reduced PGO build time overhead to single digits.
+
+## AI-Driven Code Review in CI
+
+Add an AI agent as a PR reviewer alongside traditional static analysis. When configured with this skill plugin, the agent loads the relevant Go skills — `golang-security` for security review, `golang-concurrency` for concurrency issues, `golang-error-handling` for error handling, and so on — giving it the same expertise as a senior Go reviewer. This catches architectural drift, logic bugs, missing context in errors, and subtle concurrency hazards that linters cannot detect.
+
+See the `samber/cc-skills-golang@golang-continuous-integration` skill for ready-to-use GitHub Actions assets for both Claude Code and GitHub Copilot.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/references/versions.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/references/versions.md
new file mode 100644
index 00000000..fe99cd3d
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-modernize/references/versions.md
@@ -0,0 +1,735 @@
+# Go Version Modernizations
+
+## Go 1.21 Modernizations (August 2023)
+
+Changelog: <https://go.dev/doc/go1.21>
+
+### Use built-in `min`, `max`, `clear` _(Go 1.21+)_
+
+Remove custom implementations. `min`/`max` work with any ordered type and accept variadic arguments:
+
+```go
+// Before
+func minInt(a, b int) int {
+    if a < b { return a }
+    return b
+}
+x := minInt(a, b)
+
+// After (Go 1.21+)
+x := min(a, b)
+smallest := min(a, b, c, d)
+```
+
+`clear` zeroes maps and slices:
+
+```go
+// Before
+for k := range m { delete(m, k) }
+
+// After (Go 1.21+)
+clear(m)
+```
+
+### Use `log/slog` instead of third-party loggers _(Go 1.21+)_
+
+`log/slog` is the standard structured logging package. New code SHOULD migrate to `slog` over `zap`, `logrus`, or `zerolog`.
+
+```go
+// Before: zap
+logger, _ := zap.NewProduction()
+logger.Info("request handled", zap.String("method", r.Method), zap.Int("status", status))
+
+// Before: logrus
+logrus.WithFields(logrus.Fields{"method": r.Method, "status": status}).Info("request handled")
+
+// After (Go 1.21+): slog
+slog.Info("request handled", "method", r.Method, "status", status)
+// Or with type-safe attributes:
+slog.Info("request handled", slog.String("method", r.Method), slog.Int("status", status))
+```
+
+**Migration guidance**: For existing projects heavily invested in third-party loggers, migration is optional. For new projects, prefer `slog`. The `samber/slog-*` ecosystem provides handlers for routing slog output to various backends. Go 1.24 added `slog.DiscardHandler` for silent loggers.
+
+### Use `slices` package instead of `sort` and manual loops _(Go 1.21+)_
+
+```go
+// Before
+sort.Strings(names)
+sort.Slice(users, func(i, j int) bool { return users[i].Name < users[j].Name })
+
+// After (Go 1.21+)
+slices.Sort(names)
+slices.SortFunc(users, func(a, b User) int { return cmp.Compare(a.Name, b.Name) })
+```
+
+```go
+// Before: manual search
+found := false
+for _, v := range items { if v == target { found = true; break } }
+
+// After (Go 1.21+)
+found := slices.Contains(items, target)
+```
+
+```go
+// Before: manual clone
+clone := append([]string(nil), original...)
+
+// After (Go 1.21+)
+clone := slices.Clone(original)
+```
+
+### Use `maps` package _(Go 1.21+)_
+
+```go
+// Before
+clone := make(map[string]int, len(original))
+for k, v := range original { clone[k] = v }
+
+// After (Go 1.21+)
+clone := maps.Clone(original)
+```
+
+### Use `cmp.Or` for default values _(Go 1.22+)_
+
+```go
+// Before
+addr := os.Getenv("ADDR")
+if addr == "" { addr = ":8080" }
+
+// After (Go 1.22+)
+addr := cmp.Or(os.Getenv("ADDR"), ":8080")
+```
+
+### Use `sync.OnceFunc`, `sync.OnceValue`, `sync.OnceValues` _(Go 1.21+)_
+
+```go
+// Before
+var (
+    once   sync.Once
+    client *http.Client
+)
+func getClient() *http.Client {
+    once.Do(func() { client = &http.Client{Timeout: 10 * time.Second} })
+    return client
+}
+
+// After (Go 1.21+)
+var getClient = sync.OnceValue(func() *http.Client {
+    return &http.Client{Timeout: 10 * time.Second}
+})
+```
+
+### Use enhanced `context` functions _(Go 1.21+)_
+
+```go
+ctx := context.WithoutCancel(parent)          // detach from parent cancellation
+ctx, cancel := context.WithTimeoutCause(parent, 5*time.Second, errTimeout)
+ctx, cancel := context.WithDeadlineCause(parent, deadline, errDeadline)
+stop := context.AfterFunc(ctx, func() { cleanup() })
+```
+
+---
+
+## Go 1.22 Modernizations (February 2024)
+
+Changelog: <https://go.dev/doc/go1.22>
+
+### SHOULD use `range` over integers _(Go 1.22+)_
+
+```go
+// Before
+for i := 0; i < n; i++ { process(i) }
+
+// After (Go 1.22+)
+for i := range n { process(i) }
+
+// When index isn't needed
+for range 10 { fmt.Println("hello") }
+```
+
+### Remove loop variable shadow copies _(Go 1.22+)_
+
+Go 1.22 changed loop variable semantics: each iteration creates a new variable. Loop variable captures (`v := v`) SHOULD be removed in Go 1.22+ codebases.
+
+**Requirement**: The `go` directive in `go.mod` must be `go 1.22` or later for this behavior.
+
+```go
+// Before (Go < 1.22)
+for _, v := range items {
+    v := v // shadow copy to avoid closure bug
+    go func() { process(v) }()
+}
+
+// After (Go 1.22+): safe by default
+for _, v := range items {
+    go func() { process(v) }()
+}
+```
+
+### `math/rand` MUST be replaced with `math/rand/v2` _(Go 1.22+)_
+
+```go
+// Before
+import "math/rand"
+rand.Seed(time.Now().UnixNano()) // no longer needed
+n := rand.Intn(100)
+
+// After (Go 1.22+)
+import "math/rand/v2"
+n := rand.IntN(100) // IntN, not Intn
+```
+
+Key `math/rand/v2` changes:
+
+- No global seed needed — automatically seeded
+- `Intn` -> `IntN`, `Int63n` -> `Int64N` (renamed)
+- `rand.N[T]()` generic function for any integer type
+- Better algorithms (ChaCha8, PCG)
+- `Read` removed — use `crypto/rand` for random bytes
+
+### Use enhanced `net/http` routing _(Go 1.22+)_
+
+```go
+// Before: gorilla/mux or chi
+r := mux.NewRouter()
+r.HandleFunc("/users/{id}", getUser).Methods("GET")
+
+// After (Go 1.22+): stdlib
+mux := http.NewServeMux()
+mux.HandleFunc("GET /users/{id}", getUser)
+
+func getUser(w http.ResponseWriter, r *http.Request) {
+    id := r.PathValue("id")
+}
+```
+
+### Use `strings.CutPrefix` and `strings.CutSuffix` _(Go 1.20+)_
+
+```go
+// Before
+if strings.HasPrefix(s, "Bearer ") {
+    token := strings.TrimPrefix(s, "Bearer ")
+}
+
+// After (Go 1.20+)
+if token, ok := strings.CutPrefix(s, "Bearer "); ok {
+    // use token
+}
+```
+
+### Use `reflect.TypeFor[T]()` _(Go 1.22+)_
+
+```go
+// Before
+t := reflect.TypeOf((*MyInterface)(nil)).Elem()
+
+// After (Go 1.22+)
+t := reflect.TypeFor[MyInterface]()
+```
+
+### Use `database/sql.Null[T]` _(Go 1.22+)_
+
+```go
+// Before
+var name sql.NullString
+var age  sql.NullInt64
+
+// After (Go 1.22+)
+var name sql.Null[string]
+var age  sql.Null[int64]
+```
+
+---
+
+## Go 1.23 Modernizations (August 2024)
+
+Changelog: <https://go.dev/doc/go1.23>
+
+### Use iterators (`range` over functions) _(Go 1.23+)_
+
+Go 1.23 introduced range-over-func with the `iter` package:
+
+```go
+// Before: collect all results into a slice
+func AllUsers(db *sql.DB) ([]User, error) {
+    rows, err := db.Query("SELECT ...")
+    if err != nil { return nil, err }
+    defer rows.Close()
+    var users []User
+    for rows.Next() {
+        var u User
+        rows.Scan(&u.ID, &u.Name)
+        users = append(users, u)
+    }
+    return users, rows.Err()
+}
+
+// After (Go 1.23+): lazy iteration
+func AllUsers(db *sql.DB) iter.Seq2[User, error] {
+    return func(yield func(User, error) bool) {
+        rows, err := db.Query("SELECT ...")
+        if err != nil { yield(User{}, err); return }
+        defer rows.Close()
+        for rows.Next() {
+            var u User
+            if err := rows.Scan(&u.ID, &u.Name); err != nil {
+                yield(User{}, err); return
+            }
+            if !yield(u, nil) { return }
+        }
+        if err := rows.Err(); err != nil { yield(User{}, err) }
+    }
+}
+```
+
+### Use iterator-based `slices` and `maps` functions _(Go 1.23+)_
+
+```go
+// Sorted keys via iterator
+for k := range slices.Sorted(maps.Keys(m)) {
+    fmt.Println(k, m[k])
+}
+
+// Collect iterator into slice
+users := slices.Collect(maps.Values(userMap))
+
+// Chunk a slice into batches
+for chunk := range slices.Chunk(items, 100) {
+    processBatch(chunk)
+}
+```
+
+### Use `unique` package for value interning _(Go 1.23+)_
+
+```go
+// Before: manual string interning
+var mu sync.Mutex
+var interned = make(map[string]string)
+
+// After (Go 1.23+)
+handle := unique.Make(s)  // Handle[string], comparable, memory-efficient
+s = handle.Value()
+```
+
+### Timer/Ticker behavior change _(Go 1.23+)_
+
+With `go 1.23` or later in `go.mod`:
+
+- `time.Timer` and `time.Ticker` are garbage collected without calling `Stop()`
+- Timer channels are now unbuffered (capacity 0, was 1)
+
+Remove unnecessary `Stop()` calls in defer patterns where the timer goes out of scope.
+
+---
+
+## Go 1.24 Modernizations (February 2025)
+
+Changelog: <https://go.dev/doc/go1.24>
+
+### Use generic type aliases _(Go 1.24+)_
+
+```go
+// Now valid (Go 1.24+)
+type Set[T comparable] = map[T]struct{}
+type Result[T any] = struct { Value T; Err error }
+```
+
+### Use `os.Root` for directory-scoped file access _(Go 1.24+)_
+
+**Security-critical**: `os.Root` prevents path traversal attacks (CWE-22) at the OS level. Replace all manual `filepath.Clean` + `strings.HasPrefix` validation with `os.Root` when handling user-supplied paths. Symlinks resolving outside the root are rejected. Supports `Open`, `Create`, `Stat`, `OpenFile`, `Mkdir`, `Remove`, and more.
+
+```go
+// Before: manual path validation (risk of path traversal)
+path := filepath.Join(baseDir, userInput)
+data, err := os.ReadFile(path)
+
+// After (Go 1.24+): safe directory-scoped access
+root, err := os.OpenRoot("/opt/data")
+if err != nil { return err }
+defer root.Close()
+f, err := root.Open(userInput) // cannot escape root directory
+```
+
+### Use `omitzero` JSON tag _(Go 1.24+)_
+
+`omitzero` is more correct than `omitempty` for `time.Time`, `bool`, and custom types:
+
+```go
+// Before: omitempty doesn't work well for time.Time
+type Event struct {
+    At time.Time `json:"at,omitempty"` // zero time.Time is NOT omitted
+}
+
+// After (Go 1.24+)
+type Event struct {
+    At time.Time `json:"at,omitzero"` // zero time.Time IS omitted
+}
+```
+
+### Use `strings.SplitSeq`, `strings.FieldsSeq`, `strings.Lines` _(Go 1.24+)_
+
+Iterator-returning variants avoid allocating `[]string`:
+
+```go
+// Before: allocates a []string
+parts := strings.Split(csv, ",")
+for _, part := range parts { process(part) }
+
+// After (Go 1.24+): lazy, zero-allocation iteration
+for part := range strings.SplitSeq(csv, ",") { process(part) }
+```
+
+### `t.Context()` SHOULD replace manual `context.Background()` in tests _(Go 1.24+)_
+
+```go
+// Before
+func TestFoo(t *testing.T) {
+    ctx := context.Background()
+}
+
+// After (Go 1.24+): auto-cancelled when test ends
+func TestFoo(t *testing.T) {
+    ctx := t.Context()
+}
+```
+
+### `b.Loop()` MUST be used in benchmarks _(Go 1.24+)_
+
+```go
+// Before
+func BenchmarkFoo(b *testing.B) {
+    for i := 0; i < b.N; i++ { foo() }
+}
+
+// After (Go 1.24+)
+func BenchmarkFoo(b *testing.B) {
+    for b.Loop() { foo() }
+}
+```
+
+### Use `runtime.AddCleanup` instead of `runtime.SetFinalizer` _(Go 1.24+)_
+
+```go
+// Before
+runtime.SetFinalizer(obj, func(o *Object) { o.Close() })
+
+// After (Go 1.24+): more flexible, no cycle issues
+runtime.AddCleanup(obj, func(resource Resource) { resource.Close() }, obj.resource)
+```
+
+### Use `weak` package for weak references _(Go 1.24+)_
+
+```go
+import "weak"
+
+ptr := weak.Make(obj)
+if v := ptr.Value(); v != nil {
+    // object still alive
+}
+```
+
+### Use `crypto/sha3`, `crypto/hkdf`, `crypto/pbkdf2` _(Go 1.24+)_
+
+Replace `golang.org/x/crypto` sub-packages with standard library equivalents:
+
+```go
+// Before
+import "golang.org/x/crypto/sha3"
+import "golang.org/x/crypto/hkdf"
+import "golang.org/x/crypto/pbkdf2"
+
+// After (Go 1.24+)
+import "crypto/sha3"
+import "crypto/hkdf"
+import "crypto/pbkdf2"
+```
+
+### Use tool directives in `go.mod` _(Go 1.24+)_
+
+Use `tool` directives instead of `tools.go` blank imports.
+
+```bash
+go get -tool golang.org/x/tools/cmd/stringer@latest
+go get -tool github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest
+go tool stringer -type=Kind
+go tool golangci-lint run ./...
+```
+
+`go.mod` shape for a module targeting Go 1.26 or newer. This is an example target, not a cap; keep the project's actual `go` directive and do not change it just to add tools.
+
+```go.mod
+module example.com/project
+
+go 1.26
+
+tool (
+    golang.org/x/tools/cmd/stringer
+    github.com/golangci/golangci-lint/v2/cmd/golangci-lint
+)
+```
+
+Use `go install tool` to install all module-pinned tools when needed and `go get -u tool` to update them deliberately.
+
+### Use `fmt.Appendf`, `fmt.Appendln` _(Go 1.19+, often overlooked)_
+
+```go
+// Before
+buf = append(buf, fmt.Sprintf("count: %d", n)...)
+
+// After (Go 1.19+)
+buf = fmt.Appendf(buf, "count: %d", n)
+```
+
+---
+
+## Go 1.25 Modernizations (August 2025)
+
+Changelog: <https://go.dev/doc/go1.25>
+
+### Use `sync.WaitGroup.Go` _(Go 1.25+)_
+
+```go
+// Before
+var wg sync.WaitGroup
+wg.Add(1)
+go func() {
+    defer wg.Done()
+    process()
+}()
+wg.Wait()
+
+// After (Go 1.25+)
+var wg sync.WaitGroup
+wg.Go(func() {
+    process()
+})
+wg.Wait()
+```
+
+### Use `testing/synctest` for concurrent code testing _(Go 1.25+, experimental in 1.24)_
+
+```go
+// Before
+func TestConcurrent(t *testing.T) {
+    var count atomic.Int32
+    var wg sync.WaitGroup
+
+    wg.Add(1)
+    go func() {
+        defer wg.Done()
+        count.Add(1)
+    }()
+
+    wg.Wait()
+
+    // Problem: Race conditions are hard to detect, timing-dependent,
+    // and flaky tests are common
+    if count.Load() != 1 {
+        t.Fatal("expected 1")
+    }
+}
+
+// After (Go 1.25+)
+func TestConcurrent(t *testing.T) {
+    synctest.Test(t, func(t *testing.T) {
+        var count atomic.Int32
+        go func() { count.Add(1) }()
+        synctest.Wait() // wait for all goroutines to park
+        if count.Load() != 1 { t.Fatal("expected 1") }
+    })
+}
+```
+
+**Note**: Use `synctest.Test` in Go 1.25+ and Go 1.26+. Do not use the old Go 1.24 experimental `synctest.Run` API in Go 1.25+ code.
+
+### Use `runtime/trace.FlightRecorder` _(Go 1.25+)_
+
+Lightweight always-on ring-buffer tracing for production:
+
+```go
+fr := trace.NewFlightRecorder(trace.FlightRecorderConfig{})
+if err := fr.Start(); err != nil {
+    return err
+}
+// ... later, on error:
+fr.WriteTo(file) // captures recent trace data
+```
+
+### Container-aware `GOMAXPROCS` _(Go 1.25+)_
+
+Go 1.25 automatically respects cgroup CPU limits on Linux. Remove manual workarounds:
+
+```go
+// Before: using uber-go/automaxprocs
+import _ "go.uber.org/automaxprocs"
+
+// After (Go 1.25+): built-in, remove the import
+// GOMAXPROCS is set automatically from cgroup CPU limits
+```
+
+### `encoding/json/v2` (experimental) _(Go 1.25+, GOEXPERIMENT=jsonv2)_
+
+Major JSON revision. **Experimental** — evaluate for new code, don't migrate production yet.
+
+### Go 1.25 additions to prefer when target allows
+
+- `sync.WaitGroup.Go`: simple fire-and-wait goroutines; function must not panic; no errors/cancellation.
+- `testing/synctest.Test` and `synctest.Wait`: stable deterministic concurrent/time tests. Do not use the Go 1.24 experimental `synctest.Run` in Go 1.25+.
+- `net/http.CrossOriginProtection`: stdlib helper for cross-origin / CSRF-style protection in HTTP servers.
+- `reflect.TypeAssert[T](v)`: prefer over `v.Interface().(T)` in reflection code.
+- `os.Root.FS` and additional `os.Root` methods: use for confined filesystem APIs.
+- New vet checks: `waitgroup` misuse and manual host:port formatting; prefer `net.JoinHostPort`.
+
+---
+
+## Go 1.26 Modernizations (February 2026)
+
+Changelog: <https://go.dev/doc/go1.26>
+
+### Use `errors.AsType[T]()` _(Go 1.26+)_
+
+```go
+// Before
+var pathErr *os.PathError
+if errors.As(err, &pathErr) {
+    fmt.Println(pathErr.Path)
+}
+
+// After (Go 1.26+)
+if pathErr, ok := errors.AsType[*os.PathError](err); ok {
+    fmt.Println(pathErr.Path)
+}
+```
+
+### Use enhanced `new()` _(Go 1.26+)_
+
+`new(expr)` now accepts a value expression and returns a pointer to it (not zero-initialized):
+
+```go
+// Before: helper function needed
+func ptr[T any](v T) *T { return &v }
+cfg := Config{Timeout: ptr(30)}
+
+// After (Go 1.26+): new(expr) initializes the value — equivalent to ptr(30)
+cfg := Config{Timeout: new(30)} // *int pointing to 30, not 0
+```
+
+### Use `crypto/hpke` _(Go 1.26+)_
+
+Hybrid Public Key Encryption (RFC 9180) is now in the standard library.
+
+### Use RSA-OAEP or HPKE instead of new PKCS#1 v1.5 encryption _(Go 1.26+)_
+
+For new encryption use, avoid `crypto/rsa.EncryptPKCS1v15`. Prefer RSA-OAEP (`rsa.EncryptOAEP` / `rsa.EncryptOAEPWithOptions`) or a modern KEM/HPKE design.
+
+### Green Tea GC enabled by default _(Go 1.26+)_
+
+Re-evaluate GC and allocation tuning under Go 1.26 Green Tea GC using profiles and benchmarks. Remove legacy tuning only when data supports it. Keep `GOMEMLIMIT` when it represents a real container or service memory ceiling. Remove third-party `automaxprocs` workarounds unless the project has a measured reason, because Go 1.25+ makes `GOMAXPROCS` container-aware by default.
+
+### Go 1.26+ test artifacts
+
+Use `t.ArtifactDir()`, `b.ArtifactDir()`, and `f.ArtifactDir()` for files created by tests, benchmarks, and fuzzers that should persist for inspection.
+
+### Go 1.26+ slog multi-handler
+
+For simple fan-out to multiple slog handlers, prefer stdlib `slog.NewMultiHandler` before adding third-party handler-composition dependencies.
+
+### Go 1.26+ ReverseProxy
+
+For new reverse proxy code, prefer `httputil.ReverseProxy{Rewrite: ...}`. Do not generate new `Director`-based proxy code unless preserving old compatibility.
+
+```go
+proxy := &httputil.ReverseProxy{
+    Rewrite: func(pr *httputil.ProxyRequest) {
+        pr.SetURL(targetURL)
+        pr.SetXForwarded()
+    },
+}
+```
+
+### Small Go 1.26+ API preferences
+
+- Use `bytes.Buffer.Peek(n)` when you need to inspect upcoming bytes without consuming them.
+- Use reflect iterators where they simplify code:
+  - `reflect.Type.Fields()`
+  - `reflect.Type.Methods()`
+  - `reflect.Type.Ins()`
+  - `reflect.Type.Outs()`
+  - `reflect.Value.Fields()`
+  - `reflect.Value.Methods()`
+- Prefer these over manual `NumField`/`Field(i)` or `NumMethod`/`Method(i)` loops when the iterator form is clearer.
+
+### Go 1.26+ goroutine leak profile
+
+For Go 1.26 diagnostics, there is an experimental goroutine leak profile. It is useful for production-oriented leak investigation, but is gated by `GOEXPERIMENT=goroutineleakprofile`; do not rely on it as default stable behavior.
+
+### Go 1.26+ documentation command
+
+Use `go doc`, not `go tool doc`. Go 1.26 removed the old `cmd/doc` / `go tool doc` path.
+
+### Go 1.26+ module target note
+
+When using a Go 1.26 or newer toolchain, `go mod init` may create a module with an older default `go` directive. If the project intentionally targets Go 1.26+ APIs, update the directive deliberately:
+
+```bash
+go mod edit -go=1.26
+go mod tidy
+```
+
+For future Go versions, use the project's intended target version. Do not use APIs newer than the module's `go` directive until the project explicitly agrees to upgrade it.
+
+### Modernized `go fix` _(Go 1.26+)_
+
+Go 1.26 rewrote `go fix` to apply a subset of modernize-style analyzers automatically. Check `go tool fix help` for exact coverage; some modernizations still require linting or manual review.
+
+```bash
+go fix ./...  # applies the enabled safe transformations
+```
+
+---
+
+## General Modernization (Any Version)
+
+### Code MUST use `any` instead of `interface{}` _(Go 1.18+)_
+
+```go
+// Before
+func process(data interface{}) interface{} { ... }
+
+// After (Go 1.18+)
+func process(data any) any { ... }
+```
+
+### Use generics instead of `interface{}` + type assertions _(Go 1.18+)_
+
+```go
+// Before
+func Contains(slice []interface{}, item interface{}) bool { ... }
+
+// After (Go 1.18+)
+func Contains[T comparable](slice []T, item T) bool { ... }
+// Or better (Go 1.21+): slices.Contains
+```
+
+### Use `errors.Join` instead of multi-error libraries _(Go 1.20+)_
+
+```go
+// Before: hashicorp/go-multierror or uber-go/multierr
+errs = multierror.Append(errs, err1)
+return errs.ErrorOrNil()
+
+// After (Go 1.20+)
+return errors.Join(err1, err2)
+```
+
+### Use `net.JoinHostPort` instead of `fmt.Sprintf` _(any version)_
+
+```go
+// Before (broken for IPv6)
+addr := fmt.Sprintf("%s:%d", host, port)
+
+// After (handles IPv6 correctly: [::1]:8080)
+addr := net.JoinHostPort(host, strconv.Itoa(port))
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/SKILL.md
new file mode 100644
index 00000000..224fdb43
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/SKILL.md
@@ -0,0 +1,163 @@
+---
+name: golang-naming
+description: "Go (Golang) naming conventions — covers packages, constructors, structs, interfaces, constants, enums, errors, booleans, receivers, getters/setters, functional options, acronyms, test functions, and subtest names. Use this skill when writing new Go code, reviewing or refactoring, choosing between naming alternatives (New vs NewTypeName, isConnected vs connected, ErrNotFound vs NotFoundError, StatusReady vs StatusUnknown at iota 0), debating Go package names (utils/helpers anti-patterns), or asking about Go naming best practices. Also trigger when the user mentions MixedCaps vs snake_case, ALL_CAPS constants, Get-prefix on getters, or error string casing. Do NOT use for general Go implementation questions that don't involve naming decisions."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.1"
+  openclaw:
+    emoji: "🏷"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent
+---
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-naming` skill takes precedence.
+
+# Go Naming Conventions
+
+Go favors short, readable names. Capitalization controls visibility — uppercase is exported, lowercase is unexported. All identifiers MUST use MixedCaps, NEVER underscores.
+
+> "Clear is better than clever." — Go Proverbs
+>
+> "Design the architecture, name the components, document the details." — Go Proverbs
+
+To ignore a rule, just add a comment to the code.
+
+## Quick Reference
+
+| Element | Convention | Example |
+| --- | --- | --- |
+| Package | lowercase, single word, \_test suffix OK for test files | `json`, `http`, `tabwriter`, `http_test` |
+| File | lowercase, underscores OK | `user_handler.go` |
+| Exported name | UpperCamelCase | `ReadAll`, `HTTPClient` |
+| Unexported | lowerCamelCase | `parseToken`, `userCount` |
+| Interface | method name + `-er` | `Reader`, `Closer`, `Stringer` |
+| Struct | MixedCaps noun | `Request`, `FileHeader` |
+| Constant | MixedCaps (not ALL_CAPS) | `MaxRetries`, `defaultTimeout` |
+| Receiver | 1-2 letter abbreviation | `func (s *Server)`, `func (b *Buffer)` |
+| Error variable | `Err` prefix | `ErrNotFound`, `ErrTimeout` |
+| Error type | `Error` suffix | `PathError`, `SyntaxError` |
+| Constructor | `New` (single type) or `NewTypeName` (multi-type) | `ring.New`, `http.NewRequest` |
+| Boolean field | `is`, `has`, `can` prefix on **fields** and methods | `isReady`, `IsConnected()` |
+| Test function | `Test` + function name | `TestParseToken` |
+| Acronym | all caps or all lower | `URL`, `HTTPServer`, `xmlParser` |
+| Variant: context | `WithContext` suffix | `FetchWithContext`, `QueryContext` |
+| Variant: in-place | `In` suffix | `SortIn()`, `ReverseIn()` |
+| Variant: error | `Must` prefix | `MustParse()`, `MustLoadConfig()` |
+| Option func | `With` + field name | `WithPort()`, `WithLogger()` |
+| Enum (iota) | type name prefix, zero-value = unknown | `StatusUnknown` at 0, `StatusReady` |
+| Named return | descriptive, for docs only | `(n int, err error)` |
+| Error string | lowercase (incl. acronyms), no punctuation | `"image: unknown format"`, `"invalid id"` |
+| Import alias | short, only on collision | `mrand "math/rand"`, `pb "app/proto"` |
+| Format func | `f` suffix | `Errorf`, `Wrapf`, `Logf` |
+| Test table fields | `got`/`expected` prefixes | `input string`, `expected int` |
+
+## MixedCaps
+
+All Go identifiers MUST use `MixedCaps` (or `mixedCaps`). NEVER use underscores in identifiers — the only exceptions are test function subcases (`TestFoo_InvalidInput`), generated code, and OS/cgo interop. This is load-bearing, not cosmetic — Go's export mechanism relies on capitalization, and tooling assumes MixedCaps throughout.
+
+```go
+// ✓ Good
+MaxPacketSize
+userCount
+parseHTTPResponse
+
+// ✗ Bad — these conventions conflict with Go's export mechanism and tooling expectations
+MAX_PACKET_SIZE   // C/Python style
+max_packet_size   // snake_case
+kMaxBufferSize    // Hungarian notation
+```
+
+## Avoid Stuttering
+
+Go call sites always include the package name, so repeating it in the identifier wastes the reader's time — `http.HTTPClient` forces parsing "HTTP" twice. A name MUST NOT repeat information already present in the package name, type name, or surrounding context.
+
+```go
+// Good — clean at the call site
+http.Client       // not http.HTTPClient
+json.Decoder      // not json.JSONDecoder
+user.New()        // not user.NewUser()
+config.Parse()    // not config.ParseConfig()
+
+// In package sqldb:
+type Connection struct{}  // not DBConnection — "db" is already in the package name
+
+// Anti-stutter applies to ALL exported types, not just the primary struct:
+// In package dbpool:
+type Pool struct{}        // not DBPool
+type Status struct{}      // not PoolStatus — callers write dbpool.Status
+type Option func(*Pool)   // not PoolOption
+```
+
+## Frequently Missed Conventions
+
+These conventions are correct but non-obvious — they are the most common source of naming mistakes:
+
+**Constructor naming:** When a package exports a single primary type, the constructor is `New()`, not `NewTypeName()`. This avoids stuttering — callers write `apiclient.New()` not `apiclient.NewClient()`. Use `NewTypeName()` only when a package has multiple constructible types (like `http.NewRequest`, `http.NewServeMux`).
+
+**Boolean struct fields:** Unexported boolean fields MUST use `is`/`has`/`can` prefix — `isConnected`, `hasPermission`, not bare `connected` or `permission`. The exported getter keeps the prefix: `IsConnected() bool`. This reads naturally as a question and distinguishes booleans from other types.
+
+**Error strings are fully lowercase — including acronyms.** Write `"invalid message id"` not `"invalid message ID"`, because error strings are often concatenated with other context (`fmt.Errorf("parsing token: %w", err)`) and mixed case looks wrong mid-sentence. Sentinel errors should include the package name as prefix: `errors.New("apiclient: not found")`.
+
+**Enum zero values:** Always place an explicit `Unknown`/`Invalid` sentinel at iota position 0. A `var s Status` silently becomes 0 — if that maps to a real state like `StatusReady`, code can behave as if a status was deliberately chosen when it wasn't.
+
+**Subtest names:** Table-driven test case names in `t.Run()` should be fully lowercase descriptive phrases: `"valid id"`, `"empty input"` — not `"valid ID"` or `"Valid Input"`.
+
+## Detailed Categories
+
+For complete rules, examples, and rationale, see:
+
+- **[Packages, Files & Import Aliasing](./references/packages-files.md)** — Package naming (single word, lowercase, no plurals), file naming conventions, import alias patterns (only use on collision to avoid cognitive load), and directory structure.
+
+- **[Variables, Booleans, Receivers & Acronyms](./references/identifiers.md)** — Scope-based naming (length matches scope: `i` for 3-line loops, longer names for package-level), single-letter receiver conventions (`s` for Server), acronym casing (URL not Url, HTTPServer not HttpServer), and boolean naming patterns (isReady, hasPrefix).
+
+- **[Functions, Methods & Options](./references/functions-methods.md)** — Getter/setter patterns (Go omits `Get` so `user.Name()` reads naturally), constructor conventions (`New` or `NewTypeName`), named returns (for documentation only), format function suffixes (`Errorf`, `Wrapf`), and functional options (`WithPort`, `WithLogger`).
+
+- **[Types, Constants & Errors](./references/types-errors.md)** — Interface naming (`Reader`, `Closer` suffix with `-er`), struct naming (nouns, MixedCaps), constants (MixedCaps, not ALL_CAPS), enums (type name prefix like `StatusReady`), sentinel errors (`ErrNotFound` variables), error types (`PathError` suffix), and error message conventions (lowercase, no punctuation).
+
+- **[Test Naming](./references/testing.md)** — Test function naming (`TestFunctionName`), table-driven test field conventions (`input`, `expected`), test helper naming, and subcase naming patterns.
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| `ALL_CAPS` constants | Go reserves casing for visibility, not emphasis — use `MixedCaps` (`MaxRetries`) |
+| `GetName()` getter | Go omits `Get` because `user.Name()` reads naturally at call sites. But `Is`/`Has`/`Can` prefixes are kept for boolean predicates: `IsHealthy() bool` not `Healthy() bool` |
+| `Url`, `Http`, `Json` acronyms | Mixed-case acronyms create ambiguity (`HttpsUrl` — is it `Https+Url`?). Use all caps or all lower |
+| `this` or `self` receiver | Go methods are called frequently — use 1-2 letter abbreviation (`s` for `Server`) to reduce visual noise |
+| `util`, `helper` packages | These names say nothing about content — use specific names that describe the abstraction |
+| `http.HTTPClient` stuttering | Package name is always present at call site — `http.Client` avoids reading "HTTP" twice |
+| `user.NewUser()` constructor | Single primary type uses `New()` — `user.New()` avoids repeating the type name |
+| `connected bool` field | Bare adjective is ambiguous — use `isConnected` so the field reads as a true/false question |
+| `"invalid message ID"` error | Error strings must be fully lowercase including acronyms — `"invalid message id"` |
+| `StatusReady` at iota 0 | Zero value should be a sentinel — `StatusUnknown` at 0 catches uninitialized values |
+| `"not found"` error string | Sentinel errors should include the package name — `"mypackage: not found"` identifies the origin |
+| `userSlice` type-in-name | Types encode implementation detail — `users` describes what it holds, not how |
+| Inconsistent receiver names | Switching names across methods of the same type confuses readers — use one name consistently |
+| `snake_case` identifiers | Underscores conflict with Go's MixedCaps convention and tooling expectations — use `mixedCaps` |
+| Long names for short scopes | Name length should match scope — `i` is fine for a 3-line loop, `userIndex` is noise |
+| Naming constants by value | Values change, roles don't — `DefaultPort` survives a port change, `Port8080` doesn't |
+| `FetchCtx()` context variant | `WithContext` is the standard Go suffix — `FetchWithContext()` is instantly recognizable |
+| `sort()` in-place but no `In` | Readers assume functions return new values. `SortIn()` signals mutation |
+| `parse()` panicking on error | `MustParse()` warns callers that failure panics — surprises belong in the name |
+| Mixing `With*`, `Set*`, `Use*` | Consistency across the codebase — `With*` is the Go convention for functional options |
+| Plural package names | Go convention is singular (`net/url` not `net/urls`) — keeps import paths consistent |
+| `Wrapf` without `f` suffix | The `f` suffix signals format-string semantics — `Wrapf`, `Errorf` tell callers to pass format args |
+| Unnecessary import aliases | Aliases add cognitive load. Only alias on collision — `mrand "math/rand"` |
+| Inconsistent concept names | Using `user`/`account`/`person` for the same concept forces readers to track synonyms — pick one name |
+
+## Enforce with Linters
+
+Many naming convention issues are caught automatically by linters: `revive`, `predeclared`, `misspell`, `errname`. See `samber/cc-skills-golang@golang-lint` skill for configuration and usage.
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-code-style` skill for broader formatting and style decisions
+- → See `samber/cc-skills-golang@golang-structs-interfaces` skill for interface naming depth and receiver design
+- → See `samber/cc-skills-golang@golang-lint` skill for automated enforcement (revive, predeclared, misspell, errname)
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/evals/evals.json
new file mode 100644
index 00000000..ff7576db
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/evals/evals.json
@@ -0,0 +1,404 @@
+[
+  {
+    "id": 1,
+    "name": "new-constructor-naming",
+    "description": "New() constructor for single primary type; error strings with package prefix; bool field is-prefix",
+    "prompt": "Create a Go package called `apiclient` that provides an HTTP client for a REST API. The package exports a single primary type — the client struct — along with functional options, sentinel errors, and a custom error type. Include:\n\n1. The client struct with base URL, timeout, http.Client, and a boolean tracking connection state\n2. A constructor accepting a DSN-like connection string and functional options\n3. Sentinel errors for 'not found' and 'unauthorized'\n4. A custom error type wrapping the HTTP status code\n5. A method to fetch a resource by ID\n\nWrite `apiclient.go` with proper Go naming throughout.",
+    "trap": "Model names the constructor NewClient() because the package name is apiclient and 'client' is prominent — anti-stutter means the primary type should use New(). Also likely to write 'not found' error strings without 'apiclient:' prefix, and use bare `connected bool` instead of `isConnected bool`.",
+    "assertions": [
+      {
+        "id": "1.1",
+        "text": "Constructor is named New() not NewClient() or NewAPIClient() — the package is already called apiclient, so New() is unambiguous and avoids reading 'client' twice at the call site (apiclient.New())"
+      },
+      {
+        "id": "1.2",
+        "text": "Sentinel error strings include the package name as prefix (e.g., 'apiclient: not found', 'apiclient: unauthorized') — bare strings like 'not found' lose origin when wrapped with fmt.Errorf"
+      },
+      {
+        "id": "1.3",
+        "text": "The unexported boolean field uses an is/has prefix (isConnected, hasConnection) not a bare adjective (connected) — the is prefix makes it readable as a question"
+      },
+      {
+        "id": "1.4",
+        "text": "Acronyms in exported identifiers are all-caps (URL not Url, HTTP not Http, ID not Id) — e.g., FetchByID() not FetchById(), BaseURL not BaseUrl"
+      },
+      {
+        "id": "1.5",
+        "text": "The custom error type uses the Error suffix (e.g., APIError, ResponseError) and NOT a prefix like ErrAPIResponse"
+      }
+    ]
+  },
+  {
+    "id": 2,
+    "name": "must-prefix-enum-iota",
+    "description": "New() constructor, Status not PoolStatus (anti-stutter), IsHealthy() bool, type-prefixed enums",
+    "prompt": "I'm building a Go package called `dbpool` for managing database connection pools. Please write the code for `pool.go` with:\n\n1. A ConnectionState enum with values: idle, active, closed, errored\n2. An interface that any database driver must implement, with methods for Connect, Ping, Close, and a method that returns whether the connection is healthy\n3. A Pool struct with fields for maximum connections, current count, and the database DSN (data source name)\n4. A constructor that accepts a DSN string and functional options\n5. Methods to get a connection from the pool and return it\n6. A method that returns the pool's current status as a JSON-serializable struct\n7. Error variables for pool exhausted, connection failed, and invalid DSN\n8. A helper that must successfully parse the DSN or panic\n9. Constants for the default pool size (10) and the max idle timeout (5 minutes)\n\nMake sure to follow Go naming best practices.",
+    "trap": "Model uses NewPool() instead of New(), PoolStatus (stutter), bare Healthy() bool without Is prefix, Idle/Active enum values without type prefix, or bare error strings",
+    "assertions": [
+      {
+        "id": "2.1",
+        "text": "Constructor is named New() not NewPool(), because Pool is the single primary type in the dbpool package — callers write dbpool.New()"
+      },
+      {
+        "id": "2.2",
+        "text": "The JSON-serializable status struct is named Status (not PoolStatus) since the package is already dbpool — avoids stuttering at call site (dbpool.Status not dbpool.PoolStatus)"
+      },
+      {
+        "id": "2.3",
+        "text": "The health-check method on the interface uses IsHealthy() bool with Is prefix — not bare Healthy() bool. The Is prefix signals a boolean predicate (same pattern as reflect.Type.IsVariadic, net.IP.IsLoopback)"
+      },
+      {
+        "id": "2.4",
+        "text": "The panic-on-error DSN parser uses the Must prefix (MustParseDSN) to signal that failure panics, not just ParseDSN or ParseDSNOrDie"
+      },
+      {
+        "id": "2.5",
+        "text": "Enum values are prefixed with the type name (e.g., ConnectionStateIdle, ConnectionStateActive) rather than bare Idle/Active, and include a zero-value sentinel (Unknown or similar at iota position 0)"
+      },
+      {
+        "id": "2.6",
+        "text": "Sentinel error strings include the package name as prefix (e.g., 'dbpool: pool exhausted'), not bare strings like 'pool exhausted'"
+      }
+    ]
+  },
+  {
+    "id": 3,
+    "name": "error-string-lowercase-acronyms",
+    "description": "Error strings and test subtest names must be fully lowercase including acronyms like ID, URL, HTTP",
+    "prompt": "Write a Go file `handler.go` in package `webhook` and its test file `handler_test.go`. The webhook handler should:\n\n1. A Handler struct with a secret key (for HMAC validation), a base URL for callbacks, and a boolean tracking if it's processing\n2. A method to validate an incoming webhook payload — it must verify the HMAC signature and the source URL\n3. Sentinel errors for: invalid HMAC signature, invalid source URL, missing request ID\n4. A Processor interface with a single method Process(ctx context.Context, payload []byte) error\n\nFor the test file, write table-driven tests for the validate method covering: valid request, invalid HMAC, invalid URL, missing request ID, empty payload. Use proper Go test naming conventions.",
+    "trap": "Model capitalizes acronyms in error strings ('invalid source URL', 'missing request ID') and in subtest names ('invalid URL', 'missing request ID') — but Go's convention requires fully lowercase error strings and subtest names, including acronyms. Also likely to write bare boolean field (processing) without is prefix.",
+    "assertions": [
+      {
+        "id": "3.1",
+        "text": "Error strings are fully lowercase including acronyms — 'invalid source url' not 'invalid source URL', 'missing request id' not 'missing request ID'. Acronyms that are capitalized in identifiers are lowercase in error strings"
+      },
+      {
+        "id": "3.2",
+        "text": "Subtest names passed to t.Run() are fully lowercase — 'invalid url' not 'invalid URL', 'missing request id' not 'missing request ID'. The same lowercase-for-acronyms rule applies to t.Run() subtest names"
+      },
+      {
+        "id": "3.3",
+        "text": "The unexported boolean field uses an is prefix (isProcessing) rather than a bare adjective (processing), and the exported method uses IsProcessing()"
+      },
+      {
+        "id": "3.4",
+        "text": "All Handler methods use the same 1-2 letter receiver name consistently (e.g., 'h') rather than mixing names or using 'self'/'this'"
+      },
+      {
+        "id": "3.5",
+        "text": "Sentinel errors use Err prefix (ErrInvalidSignature, ErrInvalidSourceURL, ErrMissingRequestID) matching the Go convention — note the capitalized acronyms in error variable names contrast with lowercase in error string values"
+      }
+    ]
+  },
+  {
+    "id": 4,
+    "name": "package-naming-anti-patterns",
+    "description": "Tests that generic package names (util, helper, common, base) are avoided and packages use singular, lowercase, single-word names",
+    "prompt": "I'm refactoring a Go project and need to organize some shared code. I have:\n\n1. A function that validates email addresses\n2. A function that hashes passwords with bcrypt\n3. A function that generates random UUIDs\n4. A function that formats timestamps for display\n5. A function that converts between different currency amounts\n6. Helper functions for reading/writing JSON files\n\nCurrently all of these live in a single package called `utils`. Suggest how to reorganize them into proper Go packages with appropriate names. Write the package declarations and function signatures (no implementations needed).",
+    "trap": "Model keeps the utils package or creates similarly generic names like helpers, common, shared, or base. May also use plural package names or MixedCaps/underscores in package names.",
+    "assertions": [
+      {
+        "id": "4.1",
+        "text": "Does NOT use generic package names like util, utils, helper, helpers, common, shared, base, or model — each package has a specific, purposeful name"
+      },
+      {
+        "id": "4.2",
+        "text": "Package names are singular, not plural (e.g., 'currency' not 'currencies', 'email' not 'emails')"
+      },
+      {
+        "id": "4.3",
+        "text": "Package names are lowercase single words with no underscores or MixedCaps (e.g., 'email' not 'email_validator' or 'emailValidator')"
+      },
+      {
+        "id": "4.4",
+        "text": "Functions do NOT stutter with their package name (e.g., email.Validate not email.ValidateEmail, currency.Convert not currency.ConvertCurrency)"
+      },
+      {
+        "id": "4.5",
+        "text": "The JSON file I/O functions are placed in a specific package (e.g., jsonfile, storage) not left in a generic helpers package"
+      }
+    ]
+  },
+  {
+    "id": 5,
+    "name": "scope-based-variable-naming",
+    "description": "Tests that variable name length is proportional to scope — short names for tiny scopes, longer names for package-level",
+    "prompt": "Review and improve the naming in this Go function. The code works correctly but the naming may need adjustment:\n\n```go\npackage analytics\n\nvar t = &http.Transport{MaxIdleConns: 100}\n\nfunc ProcessUserEvents(eventList []Event) map[string]int {\n    resultMap := make(map[string]int)\n    for userIndex, currentEvent := range eventList {\n        if currentEvent.IsValid() {\n            temporaryKey := currentEvent.Type\n            resultMap[temporaryKey]++\n            _ = userIndex\n        }\n    }\n    return resultMap\n}\n```\n\nFix the variable naming to follow Go conventions. Explain each change.",
+    "trap": "Model may not recognize the inverted naming problem: the package-level variable `t` is too short (should be descriptive) while the loop variables `userIndex`, `currentEvent`, `temporaryKey`, `resultMap`, `eventList` are too long for their scope.",
+    "assertions": [
+      {
+        "id": "5.1",
+        "text": "Renames the package-level variable `t` to something more descriptive like `defaultTransport` or `defaultHTTPTransport` — single-letter names are too cryptic at package scope"
+      },
+      {
+        "id": "5.2",
+        "text": "Shortens the loop variable `currentEvent` to something like `e` or `ev` — the 3-line loop scope makes a long name unnecessary noise"
+      },
+      {
+        "id": "5.3",
+        "text": "Shortens the loop index `userIndex` to `i` or similar — loop indices in small scopes should be single letters"
+      },
+      {
+        "id": "5.4",
+        "text": "Renames `resultMap` and/or `eventList` to shorter names that don't encode the type (e.g., `counts` instead of `resultMap`, `events` instead of `eventList`)"
+      },
+      {
+        "id": "5.5",
+        "text": "Explains the principle: name length should be proportional to scope size — short names for small scopes, descriptive names for package-level variables"
+      }
+    ]
+  },
+  {
+    "id": 6,
+    "name": "avoid-type-in-variable-name",
+    "description": "Tests that variable names describe what a value represents, not its Go type",
+    "prompt": "I have these variable declarations in a Go function. Are the names idiomatic?\n\n```go\nuserSlice := fetchUsers()\ncountInt := len(userSlice)\nnameString := user.FullName()\nerrorValue := validate(input)\nchannelChan := make(chan Event, 10)\ncontextCtx := context.Background()\nresultBool := isValid(token)\ntimeoutDuration := 30 * time.Second\n```\n\nSuggest better names for each.",
+    "trap": "Model may fix only the most obvious ones (like countInt) but miss that ALL type-encoded names should be changed, including channelChan, contextCtx, resultBool, timeoutDuration.",
+    "assertions": [
+      {
+        "id": "6.1",
+        "text": "Renames `userSlice` to `users` — the name should describe what the value holds, not the Go type"
+      },
+      {
+        "id": "6.2",
+        "text": "Renames `countInt` to `count` or `n` — dropping the type suffix"
+      },
+      {
+        "id": "6.3",
+        "text": "Renames `channelChan` to `events` or similar — not encoding the channel type in the name"
+      },
+      {
+        "id": "6.4",
+        "text": "Renames `contextCtx` to `ctx` — the standard Go convention for context.Context"
+      },
+      {
+        "id": "6.5",
+        "text": "Renames `timeoutDuration` to `timeout` — Duration is the type, not the purpose"
+      },
+      {
+        "id": "6.6",
+        "text": "Renames `resultBool` to something like `valid` or `ok` — removing the type suffix"
+      }
+    ]
+  },
+  {
+    "id": 7,
+    "name": "interface-naming-multi-method-noun",
+    "description": "Multi-method interfaces use a descriptive noun, not a compound -er; canonical method names must not be invented",
+    "prompt": "I'm designing a Go storage abstraction for a key-value store. A teammate has drafted these interface definitions:\n\n```go\ntype KeyGetter interface {\n    GetKey(key string) ([]byte, error)\n}\n\ntype KeySetter interface {\n    SetKey(key string, value []byte) error\n}\n\ntype KeyDeleter interface {\n    DeleteKey(key string) error\n}\n\ntype GetterSetter interface {\n    KeyGetter\n    KeySetter\n}\n\ntype FullStorer interface {\n    KeyGetter\n    KeySetter\n    KeyDeleter\n    Stringify() string\n    Release() error\n}\n```\n\nReview the interface and method naming. What problems do you see, and how would you fix them?",
+    "trap": "Model may accept GetterSetter as a reasonable compound name, keep Stringify() and Release() without flagging them as non-canonical, or not recognize that FullStorer should be a noun. The skill teaches: multi-method interfaces use descriptive nouns (Store, not FullStorer or GetterSetter), canonical method names (String() not Stringify(), Close() not Release()), and single-method -er interfaces should embed rather than compound.",
+    "assertions": [
+      {
+        "id": "7.1",
+        "text": "Flags GetterSetter as a poor compound -er name for a multi-method interface and suggests a descriptive noun (e.g., ReadWriter, or more specifically, a noun like Store)"
+      },
+      {
+        "id": "7.2",
+        "text": "Flags Stringify() as non-canonical — the correct method name is String() returning string to satisfy fmt.Stringer"
+      },
+      {
+        "id": "7.3",
+        "text": "Flags Release() as non-canonical — the correct method name is Close() returning error to satisfy io.Closer"
+      },
+      {
+        "id": "7.4",
+        "text": "Suggests renaming FullStorer to a descriptive noun (e.g., Store) rather than a compound -er — multi-method interfaces use nouns, not method-name-plus-er patterns"
+      },
+      {
+        "id": "7.5",
+        "text": "Flags GetKey/SetKey/DeleteKey method names as stuttering (key is already in the interface context) and suggests Get/Set/Delete to avoid repeating the concept"
+      }
+    ]
+  },
+  {
+    "id": 8,
+    "name": "enum-zero-value-protection",
+    "description": "Enum zero value must be an Unknown/Invalid sentinel to catch uninitialized variables; type-prefixed enum values",
+    "prompt": "I'm writing a task scheduler in Go. Define the enum types for task state and priority. Here's my first attempt:\n\n```go\ntype TaskState int\n\nconst (\n    TaskStatePending TaskState = iota\n    TaskStateRunning\n    TaskStateDone\n    TaskStateFailed\n)\n\ntype Priority int\n\nconst (\n    PriorityLow Priority = iota + 1\n    PriorityMedium\n    PriorityHigh\n    PriorityCritical\n)\n```\n\nIs this correct? Are there any naming or design issues?",
+    "trap": "TaskStatePending at iota 0 looks reasonable — Pending seems like a natural initial state. But the skill teaches that zero value must be an Unknown/Invalid sentinel to catch uninitialized variables. A var t Task will silently have TaskStatePending, making it look like a task was deliberately queued when it wasn't. Priority uses iota+1 to skip zero, which is one valid approach — the model should recognize this as intentional zero-value protection.",
+    "assertions": [
+      {
+        "id": "8.1",
+        "text": "Flags TaskStatePending at iota 0 as a bug: a zero-value TaskState will silently appear as Pending, making uninitialized task structs look like they have been queued"
+      },
+      {
+        "id": "8.2",
+        "text": "Suggests placing an explicit Unknown/Invalid sentinel at iota 0 (e.g., TaskStateUnknown or TaskStateInvalid) so that uninitialized values are detectable"
+      },
+      {
+        "id": "8.3",
+        "text": "Recognizes that Priority using iota+1 (skipping zero) is a valid approach to zero-value protection — does NOT flag it as wrong"
+      },
+      {
+        "id": "8.4",
+        "text": "Confirms that enum values are correctly prefixed with the type name (TaskStatePending, PriorityLow) — this is correct and should be kept"
+      }
+    ]
+  },
+  {
+    "id": 9,
+    "name": "named-returns-and-bare-returns",
+    "description": "Tests that named returns are used only for documentation purposes and bare returns are avoided",
+    "prompt": "Review these Go function signatures and tell me which use named returns correctly and which don't. Fix any problems:\n\n```go\nfunc ParseConfig(data []byte) (config Config, err error) {\n    // ... 40 lines of parsing logic ...\n    return\n}\n\nfunc Divide(a, b float64) (result float64, err error) {\n    if b == 0 {\n        return 0, errors.New(\"division by zero\")\n    }\n    return a / b, nil\n}\n\nfunc ScanRecord(data []byte, atEOF bool) (advance int, token []byte, err error) {\n    // ... complex scanning logic ...\n    return advance, token, nil\n}\n\nfunc Write(p []byte) (n int, e error) {\n    // ... write logic ...\n    return\n}\n```",
+    "trap": "Model approves bare returns in the 40-line ParseConfig or doesn't flag 'e' as a non-standard error name in Write. May also miss that Divide's named returns add no documentary value since the types already clarify.",
+    "assertions": [
+      {
+        "id": "9.1",
+        "text": "Flags the bare return in ParseConfig as problematic — bare returns hurt readability in long functions where the reader must scroll to find what's being returned"
+      },
+      {
+        "id": "9.2",
+        "text": "Identifies ScanRecord as a correct use of named returns — the names clarify which int is which and serve as documentation for the caller"
+      },
+      {
+        "id": "9.3",
+        "text": "Flags 'e' as a non-standard error variable name in Write — the convention is 'err', and 'e' adds no clarity"
+      },
+      {
+        "id": "9.4",
+        "text": "Notes that Divide's named returns add little value since there's only one float64 and one error — unnamed returns would be equally clear"
+      },
+      {
+        "id": "9.5",
+        "text": "Flags the bare return in Write as problematic — should explicitly return the values"
+      }
+    ]
+  },
+  {
+    "id": 10,
+    "name": "format-function-f-suffix",
+    "description": "Tests that functions accepting format strings use the f suffix convention",
+    "prompt": "I'm building a custom logging and error-wrapping library in Go. Design the public API with these functions:\n\n1. A function that creates a new error from a format string and arguments\n2. A function that wraps an existing error with additional context using a format string\n3. A function that logs at info level with a format string\n4. A function that logs at info level with a plain message (no formatting)\n5. A function that creates a new error from a plain string\n6. A function that panics with a formatted message\n\nWrite the function signatures (no implementations). Make sure the naming clearly signals which functions accept format strings.",
+    "trap": "Model creates WrapError or LogInfo for format-string variants instead of using the f suffix (Wrapf, Infof). May also not distinguish between plain-string and format-string versions.",
+    "assertions": [
+      {
+        "id": "10.1",
+        "text": "Format-string error creation uses the f suffix (Errorf) — not Error or NewError with format args"
+      },
+      {
+        "id": "10.2",
+        "text": "Format-string error wrapping uses the f suffix (Wrapf) — not WrapError or Wrap with format args"
+      },
+      {
+        "id": "10.3",
+        "text": "Format-string logging uses the f suffix (Infof or Logf) — not Info or LogInfo with format args"
+      },
+      {
+        "id": "10.4",
+        "text": "Plain-string variants do NOT have the f suffix (e.g., Info vs Infof, New vs Errorf) — clear distinction between format and plain versions"
+      },
+      {
+        "id": "10.5",
+        "text": "The panic function with format string uses the f suffix (Panicf or Fatalf) — not Panic with format args"
+      }
+    ]
+  },
+  {
+    "id": 11,
+    "name": "context-variant-and-in-place-suffixes",
+    "description": "Tests WithContext suffix for context variants and In suffix for in-place mutations",
+    "prompt": "I have a Go data processing library. I need to add variants to existing functions:\n\n1. `Fetch(key string) ([]byte, error)` needs a variant that accepts a context.Context\n2. `Sort(items []Item) []Item` (returns a new sorted slice) needs an in-place variant that modifies the slice directly\n3. `ParseConfig(path string) (*Config, error)` needs a variant that panics instead of returning an error\n4. `Reverse(s string) string` (returns a new string) needs an in-place variant for byte slices\n5. `Query(sql string) (*Rows, error)` needs a context-aware variant\n\nWhat should the variant function names be? Write the signatures.",
+    "trap": "Model uses FetchCtx/FetchWithCtx instead of FetchWithContext, SortMut/SortSlice instead of SortIn, or ParseConfigOrPanic instead of MustParseConfig.",
+    "assertions": [
+      {
+        "id": "11.1",
+        "text": "Context-accepting variants use WithContext suffix (FetchWithContext, QueryWithContext or QueryContext) — NOT FetchCtx, FetchWithCtx, or CtxFetch"
+      },
+      {
+        "id": "11.2",
+        "text": "In-place mutation variants use the In suffix (SortIn, ReverseIn) — NOT SortMut, SortInPlace, SortSlice, or MutateSort"
+      },
+      {
+        "id": "11.3",
+        "text": "Panic-on-error variant uses Must prefix (MustParseConfig) — NOT ParseConfigOrPanic, ParseConfigOrDie, or ParseConfigMust"
+      },
+      {
+        "id": "11.4",
+        "text": "All variants follow their respective conventions consistently (With* for context, In for mutation, Must for panic)"
+      }
+    ]
+  },
+  {
+    "id": 12,
+    "name": "import-aliasing-collision-only",
+    "description": "Import aliases are only justified when two packages have the same final path segment; aliases for readability are wrong",
+    "prompt": "A teammate wrote this Go file. Review the import aliases:\n\n```go\npackage main\n\nimport (\n    \"context\"\n    \"encoding/json\"\n    httputil \"net/http\"\n    stdfmt \"fmt\"\n    \"crypto/rand\"\n    mrand \"math/rand/v2\"\n    apiv1 \"myapp/api/v1\"\n    apiv2 \"myapp/api/v2\"\n    \"strings\"\n    strutil \"golang.org/x/text/unicode/norm\"\n    \"github.com/rs/zerolog\"\n    zlog \"github.com/rs/zerolog/log\"\n)\n```\n\nWhich aliases are justified? Which should be removed? For each removal, explain why. For each kept alias, explain why it's necessary.",
+    "trap": "Model may approve httputil (net/http is verbose), stdfmt (explicit about stdlib origin), strutil (long package name), apiv1/apiv2 (disambiguation) and zlog (explicit about subpackage). The skill teaches: alias ONLY on actual name collision — the default package name is already the last path segment. apiv1/apiv2 are justified because both would collide as 'v2'/'v1'. mrand is justified. httputil, stdfmt, strutil, zlog are NOT justified — they add cognitive load without resolving a collision.",
+    "assertions": [
+      {
+        "id": "12.1",
+        "text": "Flags httputil as unjustified — net/http's default package name is 'http', there is no collision. 'httputil' adds a mapping readers must remember"
+      },
+      {
+        "id": "12.2",
+        "text": "Flags stdfmt as unjustified — 'fmt' is already the package name. 'stdfmt' just adds a prefix with no collision to resolve"
+      },
+      {
+        "id": "12.3",
+        "text": "Keeps mrand as justified — it collides with crypto/rand (both would be 'rand' without aliases)"
+      },
+      {
+        "id": "12.4",
+        "text": "Keeps apiv1 and apiv2 as justified — both myapp/api/v1 and myapp/api/v2 would default to 'v2'/'v1' but the numeric suffixes are ambiguous; aliasing to apiv1/apiv2 disambiguates"
+      },
+      {
+        "id": "12.5",
+        "text": "Flags strutil or zlog as unjustified — the package already has a clear default name (norm or log); renaming it to strutil or zlog adds cognitive load without resolving a collision"
+      }
+    ]
+  },
+  {
+    "id": 13,
+    "name": "consistent-concept-naming",
+    "description": "Tests that the same domain concept uses the same name throughout the codebase",
+    "prompt": "I have a Go service with these function signatures across different files. Are there any naming consistency issues?\n\n```go\n// user_service.go\nfunc CreateUser(user *User) error\nfunc UpdateAccount(acct *User) error\nfunc RemovePerson(id string) error\nfunc GetUserByID(userID string) (*User, error)\n\n// order_service.go  \nfunc PlaceOrder(order *Order) error\nfunc ModifyPurchase(purchase *Order) error\nfunc CancelOrder(orderId string) error\nfunc FetchOrder(oid string) (*Order, error)\n```\n\nReview and fix the naming.",
+    "trap": "Model may fix only the obvious GetUserByID→UserByID but miss the inconsistent synonyms (user/account/person, order/purchase) and the inconsistent parameter naming (userID/id/orderId/oid).",
+    "assertions": [
+      {
+        "id": "13.1",
+        "text": "Identifies that user/account/person are inconsistent synonyms for the same concept and standardizes on one name (user)"
+      },
+      {
+        "id": "13.2",
+        "text": "Identifies that order/purchase are inconsistent synonyms and standardizes on one name (order)"
+      },
+      {
+        "id": "13.3",
+        "text": "Standardizes the ID parameter naming — uses one consistent name (e.g., userID, orderID) instead of mixing id/userID/orderId/oid"
+      },
+      {
+        "id": "13.4",
+        "text": "Fixes the acronym casing: orderId should be orderID (ID is an acronym, must be all caps)"
+      },
+      {
+        "id": "13.5",
+        "text": "Standardizes the verb pattern across CRUD operations (e.g., Create/Update/Delete or Create/Modify/Cancel — not Create/Update/Remove mixed with Place/Modify/Cancel)"
+      }
+    ]
+  },
+  {
+    "id": 14,
+    "name": "boolean-getter-vs-richer-return",
+    "description": "Tests the distinction between Is*/Has* bool predicates and value getters that happen to return status-like values",
+    "prompt": "A Go struct Server has these fields:\n\n```go\ntype Server struct {\n    port      int\n    healthy   bool\n    ready     bool\n    status    HealthStatus\n    connected bool\n}\n```\n\nWrite getter methods for all five fields following Go conventions. HealthStatus is a custom enum type.",
+    "trap": "Model uses GetPort() or drops the Is prefix on boolean getters (Healthy() bool). May also incorrectly add Is prefix to the HealthStatus getter (IsStatus() instead of Status()).",
+    "assertions": [
+      {
+        "id": "14.1",
+        "text": "The port getter is named Port() not GetPort() — Go omits the Get prefix on value getters"
+      },
+      {
+        "id": "14.2",
+        "text": "Boolean getters use Is prefix: IsHealthy() bool, IsReady() bool, IsConnected() bool — NOT bare Healthy(), Ready(), Connected()"
+      },
+      {
+        "id": "14.3",
+        "text": "The HealthStatus getter is named Status() not GetStatus() and does NOT use Is prefix (IsStatus) — Is/Has is only for bool return types"
+      },
+      {
+        "id": "14.4",
+        "text": "All methods use the same 1-2 letter receiver name consistently (e.g., 's' for Server)"
+      }
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/functions-methods.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/functions-methods.md
new file mode 100644
index 00000000..dbd02c9d
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/functions-methods.md
@@ -0,0 +1,116 @@
+# Functions, Methods & Options
+
+## Functions and Methods
+
+Functions returning a value are named like **nouns** (what they return). Functions performing actions are named like **verbs** (what they do).
+
+```go
+// Noun-like: returns something
+func UserName() string { ... }
+func DefaultConfig() Config { ... }
+
+// Verb-like: performs an action
+func WriteFile(name string, data []byte) error { ... }
+func SendNotification(user *User) error { ... }
+```
+
+NEVER repeat the package name in function names:
+
+```go
+// Good: users call http.Get(), not http.HTTPGet()
+package http
+func Get(url string) (*Response, error)
+
+// Bad: stutters at the call site
+package http
+func HTTPGet(url string) (*Response, error)
+```
+
+Functions that accept a format string and variadic args (like `fmt.Sprintf`) MUST end with **`f`**:
+
+```go
+// Good
+func Errorf(format string, args ...any) error
+func Wrapf(err error, format string, args ...any) error
+func Logf(format string, args ...any)
+
+// Bad
+func Error(format string, args ...any) error    // looks like it takes a plain string
+func WrapError(err error, format string, args ...any) error
+```
+
+### Getters and Setters
+
+Getters MUST NOT use the `Get` prefix. The getter is simply the field name, capitalized.
+
+```go
+// Good
+func (u *User) Name() string        { return u.name }
+func (u *User) SetName(name string)  { u.name = name }
+
+// Bad
+func (u *User) GetName() string      { return u.name }
+```
+
+Only use `Get` when the underlying concept inherently uses "get" (e.g., HTTP GET). For expensive or blocking operations, use `Fetch` or `Compute` to signal that the call is not trivial.
+
+**Exception — boolean predicates keep the `Is`/`Has`/`Can` prefix.** The no-Get rule applies to value getters, not boolean predicates. A method returning `bool` SHOULD use `Is`/`Has`/`Can` to read naturally as a question — this follows the standard library pattern (`reflect.Type.IsVariadic()`, `net.IP.IsLoopback()`, `big.Int.IsInt64()`).
+
+```go
+// Good — boolean predicate keeps Is prefix
+func (s *Server) IsHealthy() bool   { return s.healthy }
+
+// Good — value getter omits Get prefix
+func (s *Server) Port() int         { return s.port }
+
+// Good — richer return type, bare name is fine (different semantics)
+func (s *Server) Healthy() (HealthStatus, error)
+
+// Bad — bare adjective for bool is ambiguous
+func (s *Server) Healthy() bool     { return s.healthy }
+
+// Bad — Get prefix on value getter is redundant
+func (s *Server) GetPort() int      { return s.port }
+```
+
+### Constructors
+
+Name constructors `New` when the package exports a single primary type, or `NewTypeName` when there are multiple types.
+
+```go
+// Single primary type — New is unambiguous
+package ring
+func New(size int) *Ring
+
+// Multiple types — qualify with the type name
+package http
+func NewRequest(method, url string, body io.Reader) (*Request, error)
+func NewServeMux() *ServeMux
+```
+
+### Named Return Values
+
+Named return values SHOULD only be used when it improves readability — typically when multiple return values have the same type, or when the names serve as documentation.
+
+```go
+// Good — names clarify which int64 is which
+func Copy(dst Writer, src Reader) (written int64, err error)
+func ScanBytes(data []byte, atEOF bool) (advance int, token []byte, err error)
+
+// Good — single error return, no name needed
+func Write(p []byte) (int, error)
+
+// Bad — names add no clarity
+func Read(p []byte) (bytes int, e error)  // "bytes" shadows the package, "e" is non-standard
+```
+
+NEVER use named returns just to enable bare `return` — bare returns hurt readability in anything but the shortest functions.
+
+## Functional Options Pattern
+
+When a constructor has 3+ optional parameters that may grow, use the **functional options pattern** for clean, extensible APIs.
+
+- **Struct**: `ServerOptions`, `ClientOptions` (not `Opts`, `Params`, `Settings`, `Config`)
+- **Function type**: `ServerOption` (singular, not plural)
+- **With\* functions**: `WithPort()`, `WithTimeout()`, `WithLogger()`
+- **Factory**: `DefaultServerOptions()`
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/identifiers.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/identifiers.md
new file mode 100644
index 00000000..cfe4ab42
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/identifiers.md
@@ -0,0 +1,165 @@
+# Variables, Booleans, Receivers & Acronyms
+
+## Variables
+
+Name length SHOULD be **proportional to scope size**. Short names for small scopes, descriptive names for large scopes.
+
+```go
+// Small scope (1-7 lines): short names are fine
+for i, v := range items {
+    result = append(result, v.Name)
+}
+
+// Medium scope: moderately descriptive
+userCount := len(users)
+
+// Large scope / package-level: explicit and clear
+var defaultHTTPTransport = &http.Transport{
+    MaxIdleConns: 100,
+}
+```
+
+Common single-letter conventions:
+
+| Letter        | Meaning                |
+| ------------- | ---------------------- |
+| `i`, `j`, `k` | Loop indices           |
+| `n`           | Count or length        |
+| `v`           | Value (in range loops) |
+| `k`           | Key (in map ranges)    |
+| `r`           | `io.Reader`            |
+| `w`           | `io.Writer`            |
+| `b`           | `[]byte` or buffer     |
+| `s`           | String                 |
+| `t`           | `*testing.T`           |
+| `ctx`         | `context.Context`      |
+| `err`         | Error                  |
+
+### Avoid Type in the Name
+
+The name should describe what the value represents, not its type.
+
+```go
+// Good
+users := getUsers()
+count := len(items)
+
+// Bad
+userSlice := getUsers()
+countInt := len(items)
+nameString := "hello"
+```
+
+### Avoid Repetition with Context
+
+Omit words already clear from the enclosing function, method, or type.
+
+```go
+// Good — "user" is clear from the method receiver
+func (u *UserService) Create(name string) error { ... }
+
+// Bad — "user" is redundant
+func (u *UserService) CreateUser(userName string) error { ... }
+```
+
+### Use Predictable Names
+
+The same concept MUST always use the same name across the codebase. If a user is called `user` in one function, it should not become `account`, `person`, or `u` in another. Consistency makes code searchable and reduces cognitive load.
+
+```go
+// Good — same concept, same name everywhere
+func CreateUser(user *User) error { ... }
+func UpdateUser(user *User) error { ... }
+func DeleteUser(userID string) error { ... }
+
+// Bad — same concept, different names
+func CreateUser(user *User) error { ... }
+func UpdateAccount(acct *User) error { ... }   // why "acct"? it's a User
+func RemovePerson(id string) error { ... }      // why "person"? why "remove"?
+```
+
+This applies to variables, parameters, functions, and fields. Pick one name per domain concept and stick with it: `order` not sometimes `order` / sometimes `purchase`; `userID` not sometimes `userID` / sometimes `uid` / sometimes `userId`.
+
+### Parameters
+
+Parameters double as documentation at the call site. When the type is descriptive, keep the name short. When the type is ambiguous, use a longer name to clarify intent.
+
+```go
+// Good — type is descriptive, short name is fine
+func AfterFunc(d Duration, f func()) *Timer
+func Escape(w io.Writer, s []byte)
+
+// Good — type is ambiguous (int64, string), longer name documents meaning
+func Unix(sec, nsec int64) Time
+func HasPrefix(s, prefix string) bool
+
+// Bad — ambiguous type with cryptic name
+func Unix(a, b int64) Time          // what are a and b?
+func HasPrefix(a, b string) bool    // which is the prefix?
+```
+
+## Booleans
+
+Boolean variables and fields MUST read naturally as true/false questions. Use prefixes like `is`, `has`, `can`, `allow`, `should`. This applies to **both variables and struct fields**.
+
+```go
+// Good — struct fields use is/has prefix
+type Client struct {
+    isConnected  bool  // reads as "client is connected"
+    hasPermission bool // reads as "client has permission"
+}
+
+// Good — variables
+isReady := true
+hasPermission := user.CanEdit(doc)
+
+// Bad — bare adjective is ambiguous
+type Client struct {
+    connected  bool   // could be confused with a connection object
+    permission bool   // noun, not a question
+}
+```
+
+For exported boolean methods, the prefix becomes part of the method name: `IsValid()`, `HasPrefix()`, `CanRetry()`. The unexported field keeps the prefix too: `isConnected` field → `IsConnected()` method.
+
+## Receivers
+
+Receivers MUST be **1-2 letter abbreviations** of the type name. Use the same name across all methods of a type.
+
+```go
+// Good — short, consistent
+func (s *Server) Start() error      { ... }
+func (s *Server) Stop() error       { ... }
+func (s *Server) Handle(r *Request) { ... }
+
+// Bad — too long
+func (server *Server) Start() error { ... }
+
+// Bad — inconsistent names across methods
+func (s *Server) Start() error      { ... }
+func (srv *Server) Stop() error     { ... }
+
+// Bad — NEVER use "this" or "self"
+func (this *Server) Handle(r *Request) { ... }
+```
+
+## Acronyms and Initialisms
+
+Acronyms MUST be **all caps or all lower**, NEVER mixed. This preserves readability in MixedCaps names.
+
+```go
+// Good
+URL           // all caps
+url           // all lower
+HTTPServer    // HTTP is all caps
+xmlParser     // xml is all lower
+userID        // ID is all caps
+newHTTPSURL   // both HTTPS and URL all caps
+
+// Bad
+Url           // mixed case acronym
+HttpServer    // mixed case
+userId        // mixed case for ID
+```
+
+When exporting a lowercase acronym, capitalize the whole thing: `url` → `URL`, `grpc` → `GRPC`, `ios` → `IOS`.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/packages-files.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/packages-files.md
new file mode 100644
index 00000000..f5010bde
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/packages-files.md
@@ -0,0 +1,96 @@
+# Packages, Files & Import Aliasing
+
+## Packages
+
+Package names MUST be **lowercase, single-word**, with no underscores or MixedCaps. They should be short, concise, and evocative of their purpose. Numbers are allowed (`oauth2`, `k8s`).
+
+```go
+// Good
+package json
+package http
+package tabwriter
+package oauth2
+
+// Bad
+package httpServer    // no MixedCaps
+package http_server   // no underscores
+package util          // too generic
+package common        // meaningless
+package helpers       // what does it help with?
+package base          // says nothing
+package model         // too vague
+```
+
+NEVER use generic package names like `util`, `helper`, `common`, `base`, `model`. They fail to communicate purpose and cause import collisions. If you reach for `util`, the function probably belongs in a more specific package.
+
+Package names SHOULD be **singular**, not plural — `net/url` not `net/urls`, `go/token` not `go/tokens`.
+
+### Directory vs Package Name
+
+Directory names SHOULD **match the package name** when possible. Multi-word directories use **hyphens**, but since package names cannot contain hyphens, the package drops them.
+
+```
+// Good — directory matches package
+httputil/          → package httputil
+middleware/        → package middleware
+auth/              → package auth
+
+// Good — hyphenated directory, package drops hyphens
+user-service/      → package userservice
+rate-limit/        → package ratelimit
+go-chi/            → package chi
+
+// Good — special directories
+cmd/api/           → package main       (cmd/ subdirectories are always main)
+internal/auth/     → package auth       (internal/ restricts visibility)
+
+// Bad
+user_service/      → package user_service  (underscores in both)
+UserService/       → package UserService   (no MixedCaps in directories)
+myPackage/         → package mypackage     (directory has caps, package doesn't)
+```
+
+Special directories have Go toolchain meaning and don't follow normal naming:
+
+- `cmd/` — entry points, each subdirectory is `package main`
+- `internal/` — restricts import visibility to parent module
+- `testdata/` — ignored by the Go tool
+- `vendor/` — vendored dependencies
+
+Package names SHOULD NOT duplicate exported names — users see `bufio.Reader`, not `bufio.BufReader`. Think about the call site.
+
+## Files
+
+File names MUST be **lowercase** with words separated by **underscores**.
+
+```
+user_handler.go
+string_converter.go
+http_client_test.go
+```
+
+Special suffixes:
+
+- `_test.go` — test files (excluded from production builds)
+- `_linux.go`, `_amd64.go` — OS/architecture-specific (build constraints)
+
+## Import Aliasing
+
+Import aliases SHOULD only be used on name collision. When an alias is necessary, use a descriptive short name.
+
+```go
+// Good — no alias needed
+import "github.com/go-chi/chi/v5"
+
+// Good — alias resolves collision
+import (
+    "crypto/rand"
+    mrand "math/rand"
+)
+
+// Good — conventional alias for generated code
+import pb "myapp/proto/userpb"
+
+// Bad — unnecessary alias
+import f "fmt"
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/testing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/testing.md
new file mode 100644
index 00000000..cd177a3e
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/testing.md
@@ -0,0 +1,37 @@
+# Test Naming
+
+## Test Functions
+
+Test functions follow `Test` + the name of what is being tested. Use underscores for subcases.
+
+```go
+func TestParseToken(t *testing.T) { ... }
+func TestServer_Handle(t *testing.T) { ... }           // method test
+func TestParseToken_InvalidInput(t *testing.T) { ... }  // subcase
+```
+
+## Table-Driven Tests
+
+Table-driven test case names SHOULD be **fully lowercase, descriptive phrases** — including acronyms. Use `input` for inputs and `expected` for expected outputs to make the data flow clear:
+
+```go
+tests := []struct {
+    name         string
+    input        string
+    expectedCode int
+    expectedErr  bool
+}{
+    {name: "empty input", input: "", expectedCode: 400, expectedErr: true},
+    {name: "valid token", input: "abc123", expectedCode: 200},
+    {name: "expired token", input: "exp", expectedCode: 401, expectedErr: true},
+    {name: "invalid id", input: "???", expectedCode: 400, expectedErr: true},  // "id" not "ID"
+}
+
+// Bad — mixed case in test names
+{name: "valid ID", ...}      // should be "valid id"
+{name: "Empty Input", ...}   // should be "empty input"
+```
+
+## Test Helpers
+
+Test helper functions that panic on failure conventionally use the `must` prefix: `mustLoadFixture()`, `mustParseURL()`.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/types-errors.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/types-errors.md
new file mode 100644
index 00000000..6c043d84
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-naming/references/types-errors.md
@@ -0,0 +1,159 @@
+# Types, Constants & Errors
+
+## Interfaces
+
+### Single-Method Interfaces
+
+Name them with the **method name + `-er`** suffix:
+
+```go
+type Reader interface {
+    Read(p []byte) (n int, err error)
+}
+
+type Stringer interface {
+    String() string
+}
+
+type Closer interface {
+    Close() error
+}
+```
+
+### Multi-Method Interfaces
+
+Use a descriptive **noun** or compose from single-method interfaces:
+
+```go
+type ReadWriteCloser interface {
+    Reader
+    Writer
+    Closer
+}
+
+type Handler interface {
+    ServeHTTP(ResponseWriter, *Request)
+}
+```
+
+### Canonical Method Names
+
+Honor established Go method names and their signatures. If your type implements `Read`, it MUST match `io.Reader`'s signature. NEVER invent variations like `ReadData` or `ToString` — use `String`.
+
+| Method name | Expected interface |
+| ----------- | ------------------ |
+| `Read`      | `io.Reader`        |
+| `Write`     | `io.Writer`        |
+| `Close`     | `io.Closer`        |
+| `String`    | `fmt.Stringer`     |
+| `Error`     | `error`            |
+| `Len`       | `sort.Interface`   |
+| `ServeHTTP` | `http.Handler`     |
+
+## Structs
+
+Name structs with **MixedCaps nouns** describing the entity. Fields follow exported/unexported rules.
+
+```go
+type Server struct {
+    Addr     string        // exported
+    Handler  http.Handler  // exported
+    timeout  time.Duration // unexported
+}
+```
+
+NEVER suffix struct names with `Struct`, `Object`, or `Data` — they add no information.
+
+## Constants
+
+Constants MUST use **MixedCaps**, NEVER `ALL_CAPS`. The name should explain the **role**, not the **value**.
+
+```go
+// Good — MixedCaps, name explains purpose
+const MaxRetries = 3
+const defaultTimeout = 30 * time.Second
+const DefaultPort = 8080
+
+// Bad — ALL_CAPS is not idiomatic Go
+const MAX_RETRIES = 3
+const DEFAULT_TIMEOUT = 30
+
+// Bad — name is the value, not the purpose
+const Three = 3
+const Port8080 = 8080
+```
+
+### Enums (iota)
+
+Prefix enum values with the **type name** to avoid collisions and improve readability at the call site.
+
+```go
+type Status int
+
+const (
+    StatusUnknown Status = iota // zero value = unknown/invalid
+    StatusReady
+    StatusRunning
+    StatusDone
+)
+
+type Color int
+
+const (
+    ColorRed Color = iota + 1  // skip zero to catch uninitialized values
+    ColorGreen
+    ColorBlue
+)
+```
+
+**Always protect the zero value.** A `var s Status` will silently be 0 — if that maps to a real state like `StatusReady`, code can behave as if a status was deliberately chosen when it wasn't. Either place an explicit `Unknown` sentinel at iota 0, or start at `iota + 1`. This is not optional — uninitialized enums are a common source of silent bugs.
+
+## Errors
+
+### Sentinel Errors
+
+Sentinel error variables use the `Err` prefix. Error strings SHOULD include the package name as prefix to identify the origin when errors are wrapped:
+
+```go
+// Good — package prefix identifies origin
+var ErrNotFound = errors.New("mypackage: not found")
+var ErrPermissionDenied = errors.New("mypackage: permission denied")
+var ErrTimeout = errors.New("mypackage: operation timed out")
+
+// Bad — bare strings lose origin when wrapped
+var ErrNotFound = errors.New("not found")
+```
+
+### Error Types
+
+Custom error types use the `Error` suffix:
+
+```go
+type PathError struct {
+    Op   string
+    Path string
+    Err  error
+}
+
+type SyntaxError struct {
+    Offset int64
+    msg    string
+}
+```
+
+### Error Strings
+
+Error strings MUST be **fully lowercase — including acronyms** — and MUST NOT **end with punctuation**, because they are often printed following other context (`fmt.Errorf("parsing config: %w", err)`). Acronyms that would normally be capitalized in identifiers (`ID`, `URL`, `HTTP`) become lowercase in error strings.
+
+```go
+// Good — lowercase including acronyms, no punctuation
+errors.New("image: unknown format")
+errors.New("mypackage: invalid message id")     // "id" not "ID"
+errors.New("mypackage: invalid url")             // "url" not "URL"
+fmt.Errorf("decoding config: %w", err)
+
+// Bad — capitalized, acronyms, punctuation
+errors.New("Image: Unknown format.")
+errors.New("mypackage: invalid message ID")      // ID should be lowercase in error strings
+fmt.Errorf("Failed to decode config: %w.", err)
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/SKILL.md
new file mode 100644
index 00000000..d10a7b8e
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/SKILL.md
@@ -0,0 +1,192 @@
+---
+name: golang-observability
+description: "Golang everyday observability — the always-on signals in production. Covers structured logging with slog, Prometheus metrics, OpenTelemetry distributed tracing, continuous profiling with pprof/Pyroscope, server-side RUM event tracking, alerting, and Grafana dashboards. Apply when instrumenting Go services for production monitoring, setting up metrics or alerting, adding OpenTelemetry tracing, correlating logs with traces, migrating legacy loggers (zap/logrus/zerolog) to slog, adding observability to new features, or implementing GDPR/CCPA-compliant tracking with Customer Data Platforms (CDP). Not for temporary deep-dive performance investigation (→ See `samber/cc-skills-golang@golang-benchmark` and `samber/cc-skills-golang@golang-performance` skills)."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.1"
+  openclaw:
+    emoji: "📡"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch WebSearch AskUserQuestion
+---
+
+**Persona:** You are a Go observability engineer. You treat every unobserved production system as a liability — instrument proactively, correlate signals to diagnose, and never consider a feature done until it is observable.
+
+**Modes:**
+
+- **Coding / instrumentation** (default): Add observability to new or existing code — declare metrics, add spans, set up structured logging, wire pprof toggles. Follow the sequential instrumentation guide.
+- **Review mode** — reviewing a PR's instrumentation changes. Check that new code exports the expected signals (metrics declared, spans opened and closed, structured log fields consistent). Sequential.
+- **Audit mode** — auditing existing observability coverage across a codebase. Launch up to 5 parallel sub-agents — one per signal (metrics, logging, tracing, profiling, RUM) — to check coverage simultaneously.
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-observability` skill takes precedence.
+
+# Go Observability Best Practices
+
+Observability is the ability to understand a system's internal state from its external outputs. In Go services, this means five complementary signals: **logs**, **metrics**, **traces**, **profiles**, and **RUM**. Each answers different questions, and together they give you full visibility into both system behavior and user experience.
+
+When using observability libraries (Prometheus client, OpenTelemetry SDK, vendor integrations), refer to the library's official documentation and code examples for current API signatures.
+
+## Best Practices Summary
+
+1. **Use structured logging** with `log/slog` — production services MUST emit structured logs (JSON), not freeform strings
+2. **Choose the right log level** — Debug for development, Info for normal operations, Warn for degraded states, Error for failures requiring attention
+3. **Log with context** — use `slog.InfoContext(ctx, ...)` to correlate logs with traces
+4. **Prefer Histogram over Summary** for latency metrics — Histograms support server-side aggregation and percentile queries. Every HTTP endpoint MUST have latency and error rate metrics.
+5. **Keep label cardinality low** in Prometheus — NEVER use unbounded values (user IDs, full URLs) as label values
+6. **Track percentiles** (P50, P90, P99, P99.9) using Histograms + `histogram_quantile()` in PromQL
+7. **Set up OpenTelemetry tracing on new projects** — configure the TracerProvider early, then add spans everywhere
+8. **Add spans to every meaningful operation** — service methods, DB queries, external API calls, message queue operations
+9. **Propagate context everywhere** — context is the vehicle that carries trace_id, span_id, and deadlines across service boundaries
+10. **Enable profiling via environment variables** — toggle pprof and continuous profiling on/off without redeploying
+11. **Correlate signals** — inject trace_id into logs, use exemplars to link metrics to traces
+12. **A feature is not done until it is observable** — declare metrics, add proper logging, create spans
+13. **[awesome-prometheus-alerts](https://samber.github.io/awesome-prometheus-alerts/) provides ~500 ready-to-use alerting rules** organized by technology for infrastructure and dependency monitoring
+
+## Cross-References
+
+See `samber/cc-skills-golang@golang-error-handling` skill for the single handling rule. See `samber/cc-skills-golang@golang-troubleshooting` skill for using observability signals to diagnose production issues. See `samber/cc-skills-golang@golang-security` skill for protecting pprof endpoints and avoiding PII in logs. See `samber/cc-skills-golang@golang-context` skill for propagating trace context across service boundaries. See `samber/cc-skills@promql-cli` skill for querying and exploring PromQL expressions against Prometheus from the CLI.
+
+### Go 1.26+: slog multi-handler
+
+For simple fan-out to multiple slog handlers, prefer stdlib `slog.NewMultiHandler` before adding third-party handler-composition dependencies.
+
+```go
+logger := slog.New(slog.NewMultiHandler(
+    slog.NewJSONHandler(os.Stdout, nil),
+    auditHandler,
+))
+```
+
+Use third-party slog handler libraries only when the stdlib handler composition is insufficient.
+
+## The Five Signals
+
+| Signal | Question it answers | Tool | When to use |
+| --- | --- | --- | --- |
+| **Logs** | What happened? | `log/slog` | Discrete events, errors, audit trails |
+| **Metrics** | How much / how fast? | Prometheus client | Aggregated measurements, alerting, SLOs |
+| **Traces** | Where did time go? | OpenTelemetry | Request flow across services, latency breakdown |
+| **Profiles** | Why is it slow / using memory? | pprof, Pyroscope | CPU hotspots, memory leaks, lock contention |
+| **RUM** | How do users experience it? | PostHog, Segment | Product analytics, funnels, session replay |
+
+## Detailed Guides
+
+Each signal has a dedicated guide with full code examples, configuration patterns, and cost analysis:
+
+- **[Structured Logging](references/logging.md)** — Why structured logging matters for log aggregation at scale. Covers `log/slog` setup, log levels (Debug/Info/Warn/Error) and when to use each, request correlation with trace IDs, context propagation with `slog.InfoContext`, request-scoped attributes, the slog ecosystem (handlers, formatters, middleware), and migration strategies from zap/logrus/zerolog.
+
+- **[Metrics Collection](references/metrics.md)** — Prometheus client setup and the four metric types (Counter for rate-of-change, Gauge for snapshots, Histogram for latency aggregation). Deep dive: why Histograms beat Summaries (server-side aggregation, supports `histogram_quantile` PromQL), naming conventions, the PromQL-as-comments convention (write queries above metric declarations for discoverability), production-grade PromQL examples, multi-window SLO burn rate alerting, and the high-cardinality label problem (why unbounded values like user IDs destroy performance).
+
+- **[Distributed Tracing](references/tracing.md)** — When and how to use OpenTelemetry SDK to trace request flows across services. Covers spans (creating, attributes, status recording), `otelhttp` middleware for HTTP instrumentation, error recording with `span.RecordError()`, trace sampling (why you can't collect everything at scale), propagating trace context across service boundaries, and cost optimization.
+
+- **[Profiling](references/profiling.md)** — On-demand profiling with pprof (CPU, heap, goroutine, mutex, block profiles) — how to enable it in production, secure it with auth, and toggle via environment variables without redeploying. Continuous profiling with Pyroscope for always-on performance visibility. Cost implications of each profiling type and mitigation strategies.
+
+- **[Real User Monitoring](references/rum.md)** — Understanding how users actually experience your service. Covers product analytics (event tracking, funnels), Customer Data Platform integration, and critical compliance: GDPR/CCPA consent checks, data subject rights (user deletion endpoints), and privacy checklist for tracking. Server-side event tracking (PostHog, Segment) and identity key best practices.
+
+- **[Alerting](references/alerting.md)** — Proactive problem detection. Covers the four golden signals (latency, traffic, errors, saturation), [awesome-prometheus-alerts](https://samber.github.io/awesome-prometheus-alerts/) provides ~500 ready-to-use rules by technology, Go runtime alerts (goroutine leaks, GC pressure, OOM risk), severity levels, and common mistakes that break alerting (using `irate` instead of `rate`, missing `for:` duration to avoid flapping).
+
+- **[Grafana Dashboards](references/dashboards.md)** — Prebuilt dashboards for Go runtime monitoring (heap allocation, GC pause frequency, goroutine count, CPU). Explains the standard dashboards to install, how to customize them for your service, and when each dashboard answers a different operational question.
+
+## Correlating Signals
+
+Signals are most powerful when connected. A trace_id in your logs lets you jump from a log line to the full request trace. An exemplar on a metric links a latency spike to the exact trace that caused it.
+
+### Logs + Traces: `otelslog` bridge
+
+```go
+import "go.opentelemetry.io/contrib/bridges/otelslog"
+
+// Create a logger that automatically injects trace_id and span_id
+logger := otelslog.NewHandler("my-service")
+slog.SetDefault(slog.New(logger))
+
+// Now every slog call with context includes trace correlation
+slog.InfoContext(ctx, "order created", "order_id", orderID)
+// Output includes: {"trace_id":"abc123", "span_id":"def456", "msg":"order created", ...}
+```
+
+### Metrics + Traces: Exemplars
+
+```go
+// When recording a histogram observation, attach the trace_id as an exemplar
+// so you can jump from a P99 spike directly to the offending trace
+obs := histogram.WithLabelValues("POST", "/orders")
+if eo, ok := obs.(prometheus.ExemplarObserver); ok {
+    eo.ObserveWithExemplar(duration, prometheus.Labels{"trace_id": traceID})
+} else {
+    obs.Observe(duration)
+}
+```
+
+## Migrating Legacy Loggers
+
+If the project currently uses `zap`, `logrus`, or `zerolog`, migrate to `log/slog`. It is the standard library logger since Go 1.21, has a stable API, and the ecosystem has consolidated around it. Continuing with third-party loggers means maintaining an extra dependency for no benefit.
+
+**Migration strategy:**
+
+1. Add `slog` as the new logger with `slog.SetDefault()`
+2. Bridge handlers during migration route slog output through the existing logger: [samber/slog-zap](https://github.com/samber/slog-zap), [samber/slog-logrus](https://github.com/samber/slog-logrus), [samber/slog-zerolog](https://github.com/samber/slog-zerolog)
+3. Gradually replace all `zap.L().Info(...)` / `logrus.Info(...)` / `log.Info().Msg(...)` calls with `slog.Info(...)`
+4. Once fully migrated, remove the bridge handler and the old logger dependency
+
+## Definition of Done for Observability
+
+A feature is not production-ready until it is observable. Before marking a feature as done, verify:
+
+- [ ] **Metrics declared** — counters for operations/errors, histograms for latencies, gauges for saturation. Each metric var has PromQL queries and alert rules as comments above its declaration.
+- [ ] **Logging is proper** — structured key-value pairs with `slog`, context variants used (`slog.InfoContext`), no PII in logs, errors MUST be either logged OR returned (NEVER both).
+- [ ] **Spans created** — every service method, DB query, and external API call has a span with relevant attributes, errors recorded with `span.RecordError()`.
+- [ ] **Dashboards and alerts exist** — the PromQL from your metric comments is wired into Grafana dashboards and Prometheus alerting rules. Ready-to-use alert rules for common infrastructure dependencies are available at [awesome-prometheus-alerts](https://samber.github.io/awesome-prometheus-alerts/).
+- [ ] **RUM events tracked** — key business events tracked server-side (PostHog/Segment), identity key is `user_id` (not email), consent checked before tracking.
+
+## Common Mistakes
+
+```go
+// ✗ Bad — log AND return (error gets logged multiple times up the chain)
+if err != nil {
+    slog.Error("query failed", "error", err)
+    return fmt.Errorf("query: %w", err)
+}
+
+// ✓ Good — return with context, log once at the top level
+if err != nil {
+    return fmt.Errorf("querying users: %w", err)
+}
+```
+
+```go
+// ✗ Bad — high-cardinality label (unbounded user IDs)
+httpRequests.WithLabelValues(r.Method, r.URL.Path, userID).Inc()
+
+// ✓ Good — bounded label values only
+httpRequests.WithLabelValues(r.Method, routePattern).Inc()
+```
+
+```go
+// ✗ Bad — not passing context (breaks trace propagation)
+result, err := db.Query("SELECT ...")
+
+// ✓ Good — context flows through, trace continues
+result, err := db.QueryContext(ctx, "SELECT ...")
+```
+
+```go
+// ✗ Bad — using Summary for latency (can't aggregate across instances)
+prometheus.NewSummary(prometheus.SummaryOpts{
+    Name:       "http_request_duration_seconds",
+    Objectives: map[float64]float64{0.99: 0.001},
+})
+
+// ✓ Good — use Histogram (aggregatable, supports histogram_quantile)
+prometheus.NewHistogram(prometheus.HistogramOpts{
+    Name:    "http_request_duration_seconds",
+    Buckets: prometheus.DefBuckets,
+})
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/evals/evals.json
new file mode 100644
index 00000000..c439fe5c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/evals/evals.json
@@ -0,0 +1,548 @@
+[
+  {
+    "id": 1,
+    "name": "histogram-bucket-misconfiguration-sub-millisecond",
+    "description": "Tests whether the model catches that prometheus.DefBuckets are wrong for sub-millisecond operations",
+    "prompt": "I'm adding a Prometheus histogram for an in-memory cache lookup that typically completes in 50-500 microseconds. Here's my declaration:\n\nvar cacheLookupDuration = promauto.NewHistogram(prometheus.HistogramOpts{\n    Namespace: \"myapp\",\n    Name:      \"cache_lookup_duration_seconds\",\n    Buckets:   prometheus.DefBuckets,\n})\n\nDefBuckets are the default so this should be fine, right?",
+    "trap": "Without the skill, the model validates the code since DefBuckets are the 'recommended default'. The skill teaches that DefBuckets start at 5ms — all sub-millisecond observations land in the first bucket, making P50/P99 meaningless.",
+    "assertions": [
+      {"id": "1.1", "text": "Identifies that prometheus.DefBuckets (.005, .01, .025, .05, .1, ... seconds) are wrong for sub-millisecond operations"},
+      {"id": "1.2", "text": "Explains that all 50-500µs observations would land in a single bucket, making histogram_quantile() return inaccurate or meaningless percentiles"},
+      {"id": "1.3", "text": "Recommends custom bucket boundaries in the microsecond range (e.g., 0.0001, 0.0002, 0.0005, 0.001, 0.002 seconds)"},
+      {"id": "1.4", "text": "Shows how to define custom buckets using prometheus.LinearBuckets, prometheus.ExponentialBuckets, or an explicit []float64 slice"},
+      {"id": "1.5", "text": "Explains the general rule: buckets should cover the expected range of values with sufficient resolution around the target percentiles"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "promql-comments-convention-discoverability",
+    "description": "Tests the PromQL-as-comments convention above metric variable declarations",
+    "prompt": "My team declares Prometheus metrics scattered across many files. When writing alerts or dashboards, engineers have to grep the codebase to find the metric name and then guess what PromQL to write. How do I make metrics more self-documenting without adding a wiki or external doc?",
+    "trap": "Without the skill, the model suggests external documentation, a README section, or godoc comments with metric descriptions — missing the PromQL-as-comments convention taught by the skill",
+    "assertions": [
+      {"id": "2.1", "text": "Recommends placing PromQL queries and alert expressions as comments directly above each metric variable declaration"},
+      {"id": "2.2", "text": "Shows example with Dashboard: and Alert: comment lines containing actual PromQL above the var block"},
+      {"id": "2.3", "text": "Explains that colocating PromQL with the metric declaration means queries are reviewed in PRs alongside metric changes"},
+      {"id": "2.4", "text": "Mentions that when the metric name or labels change, the PromQL comments change in the same commit — preventing stale queries"},
+      {"id": "2.5", "text": "Shows that this enables new team members to understand the metric's purpose and how to query it at a glance"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "high-cardinality-label-trap",
+    "description": "Tests whether the model catches high-cardinality label usage in Prometheus metrics",
+    "prompt": "I'm adding Prometheus metrics to my Go API. For tracking request counts, I'm using:\n\nhttpRequests.WithLabelValues(r.Method, r.URL.Path, userID).Inc()\n\nThis gives me per-user, per-endpoint visibility. Any concerns?",
+    "trap": "Without the skill, the model may praise the granularity or only mention minor concerns, missing the critical cardinality explosion problem",
+    "assertions": [
+      {"id": "3.1", "text": "Identifies userID as a high-cardinality label that will cause problems"},
+      {"id": "3.2", "text": "Identifies r.URL.Path as potentially high-cardinality (should use route template instead)"},
+      {"id": "3.3", "text": "Explains that each unique label combination creates a separate time series"},
+      {"id": "3.4", "text": "Warns about memory explosion on the Prometheus server from unbounded labels"},
+      {"id": "3.5", "text": "Recommends using route patterns/templates (e.g., /users/:id) instead of actual paths"},
+      {"id": "3.6", "text": "Suggests using traces (not metrics) for high-cardinality data like user IDs"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "production-json-logging",
+    "description": "Tests whether the model recommends JSON handler for production and explains why plain text is problematic",
+    "prompt": "I'm setting up slog for my Go production service. I like the TextHandler output because it's readable. Here's my setup:\n\nslog.SetDefault(slog.New(slog.NewTextHandler(os.Stdout, nil)))\n\nShould I use this in production?",
+    "trap": "Without the skill, the model may say TextHandler is fine since it produces structured key=value output",
+    "assertions": [
+      {"id": "4.1", "text": "Recommends JSONHandler for production, not TextHandler"},
+      {"id": "4.2", "text": "Explains that plain-text multiline logs (e.g., stack traces) get split into separate records by log collectors"},
+      {"id": "4.3", "text": "Suggests TextHandler is appropriate for development only"},
+      {"id": "4.4", "text": "Shows the correct JSONHandler setup with slog.LevelInfo for production"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "slog-context-variant-trace-correlation",
+    "description": "Tests whether the model insists on *Context variants of slog for trace correlation",
+    "prompt": "I'm adding logging to my Go service that already has OpenTelemetry tracing configured with otelslog bridge. Here's my logging code:\n\nfunc (s *OrderService) Create(ctx context.Context, req CreateOrderRequest) error {\n    slog.Info(\"creating order\", \"order_id\", req.ID)\n    // ... business logic ...\n    slog.Error(\"order creation failed\", \"error\", err)\n    return err\n}\n\nAnything wrong with my logging?",
+    "trap": "Without the skill, the model may not flag the missing context parameter since the logging looks correct",
+    "assertions": [
+      {"id": "5.1", "text": "Identifies that slog.Info and slog.Error should use their *Context variants (slog.InfoContext, slog.ErrorContext)"},
+      {"id": "5.2", "text": "Explains that without ctx, trace_id and span_id won't be injected into log records"},
+      {"id": "5.3", "text": "Shows the corrected code using slog.InfoContext(ctx, ...) and slog.ErrorContext(ctx, ...)"},
+      {"id": "5.4", "text": "Mentions that the otelslog bridge automatically injects trace correlation when context is passed"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "multi-window-burn-rate-slo-alerting",
+    "description": "Tests knowledge of multi-window burn-rate SLO alerting instead of simple threshold",
+    "prompt": "My Go API has a 99.9% availability SLO. I have this alert:\n\n- alert: HighErrorRate\n  expr: rate(http_requests_total{status=~\"5..\"}[5m]) / rate(http_requests_total[5m]) > 0.001\n  for: 5m\n\nI get too many false positives from brief spikes but also miss slow degradation that stays just under 0.1%. How do I improve my alerting strategy?",
+    "trap": "Without the skill, the model suggests adjusting the threshold or the for: duration, missing the multi-window burn-rate approach that the skill specifically teaches",
+    "assertions": [
+      {"id": "6.1", "text": "Recommends multi-window burn-rate alerting to address both false positives and slow burn scenarios"},
+      {"id": "6.2", "text": "Explains error budget and burn rate concepts"},
+      {"id": "6.3", "text": "Shows a fast burn window (e.g., 5m + 1h, ~14x burn rate) for critical/page alerts"},
+      {"id": "6.4", "text": "Shows a slow burn window (e.g., 2h + 24h, 1-2x burn rate) for warning/ticket alerts"},
+      {"id": "6.5", "text": "Explains that ANDing short and long windows eliminates false positives from transient spikes"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "irate-vs-rate-for-alerts",
+    "description": "Tests whether the model catches irate() usage in alerting rules",
+    "prompt": "I'm writing a Prometheus alerting rule for my Go service to detect high error rates:\n\n- alert: HighErrorRate\n  expr: irate(http_requests_total{status=~\"5..\"}[5m]) > 0.01\n\nDoes this look correct?",
+    "trap": "Without the skill, the model may approve irate since it's a valid PromQL function, missing that irate is too volatile for alerting",
+    "assertions": [
+      {"id": "7.1", "text": "Identifies irate() as inappropriate for alerting rules"},
+      {"id": "7.2", "text": "Explains that irate reacts to a single scrape interval and is too volatile, causing false positives"},
+      {"id": "7.3", "text": "Recommends rate() instead of irate() for alerts"},
+      {"id": "7.4", "text": "Recommends adding a for: duration to avoid firing on transient spikes"},
+      {"id": "7.5", "text": "Shows the corrected alert rule using rate() with a for: clause"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "alert-missing-for-duration",
+    "description": "Tests whether the model catches alerts without a for: duration clause",
+    "prompt": "Here's my Prometheus alert for high P99 latency:\n\n- alert: HighLatency\n  expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 2\n\nShould I deploy this?",
+    "trap": "Without the skill, the model may approve it since the PromQL expression itself is correct",
+    "assertions": [
+      {"id": "8.1", "text": "Identifies the missing for: duration as a problem"},
+      {"id": "8.2", "text": "Explains that without for:, a single bad scrape triggers the alert (false positive)"},
+      {"id": "8.3", "text": "Recommends adding for: 5m or similar duration"},
+      {"id": "8.4", "text": "Distinguishes that binary alerts (service up/down) can use for: 0m, but non-binary alerts need a duration"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "promql-comments-convention",
+    "description": "Tests whether the model recommends documenting metrics with PromQL comments above declarations",
+    "prompt": "I'm declaring Prometheus metrics in my Go service. Here's my pattern:\n\nvar httpRequestsTotal = promauto.NewCounterVec(\n    prometheus.CounterOpts{\n        Namespace: \"myapp\",\n        Subsystem: \"http\",\n        Name:      \"requests_total\",\n        Help:      \"Total number of HTTP requests.\",\n    },\n    []string{\"method\", \"path\", \"status\"},\n)\n\nHow can I make my metrics more discoverable for my team?",
+    "trap": "Without the skill, the model may suggest external documentation or wiki pages, missing the PromQL-as-comments convention",
+    "assertions": [
+      {"id": "9.1", "text": "Recommends adding PromQL queries and alert rules as comments directly above the metric variable declaration"},
+      {"id": "9.2", "text": "Shows example Dashboard: and Alert: comment lines above the metric var"},
+      {"id": "9.3", "text": "Explains that this keeps PromQL queries reviewed in PRs alongside the metric"},
+      {"id": "9.4", "text": "Mentions that queries stay in sync with metric changes (label renames, bucket changes)"},
+      {"id": "9.5", "text": "Notes that new team members can understand the metric's purpose at a glance from the comments"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "otelslog-bridge-setup",
+    "description": "Tests log-trace correlation setup using otelslog bridge",
+    "prompt": "I have a Go service with both slog logging and OpenTelemetry tracing. I want to correlate them so that when I see a log line in Grafana Loki, I can jump to the trace in Tempo. How do I connect them?",
+    "trap": "Without the skill, the model may suggest manually extracting trace_id from span context and adding it as a slog attribute, missing the otelslog bridge",
+    "assertions": [
+      {"id": "10.1", "text": "Recommends using the otelslog bridge from go.opentelemetry.io/contrib/bridges/otelslog"},
+      {"id": "10.2", "text": "Shows creating a handler with otelslog.NewHandler()"},
+      {"id": "10.3", "text": "Shows setting it as default with slog.SetDefault()"},
+      {"id": "10.4", "text": "Explains that trace_id and span_id are automatically injected into log records"},
+      {"id": "10.5", "text": "Emphasizes using slog.*Context(ctx, ...) variants to enable the automatic injection"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "exemplars-metric-trace-link",
+    "description": "Tests metrics-to-traces correlation via Prometheus exemplars",
+    "prompt": "I have a Prometheus histogram tracking HTTP request latency and OpenTelemetry tracing. When I see a P99 latency spike in Grafana, I want to jump directly to the offending trace. How do I link metrics to traces?",
+    "trap": "Without the skill, the model may suggest using metric labels or manual correlation, missing the exemplar mechanism",
+    "assertions": [
+      {"id": "11.1", "text": "Recommends using Prometheus exemplars to link metrics to traces"},
+      {"id": "11.2", "text": "Shows attaching trace_id as an exemplar when recording histogram observations"},
+      {"id": "11.3", "text": "Explains that exemplars let you jump from a metric spike directly to the trace that caused it"}
+    ]
+  },
+  {
+    "id": 12,
+    "name": "span-error-recording-both-calls",
+    "description": "Tests that error recording on spans requires both RecordError() and SetStatus(Error)",
+    "prompt": "In my Go service using OpenTelemetry, when an operation fails, I do:\n\nif err != nil {\n    span.RecordError(err)\n    return err\n}\n\nIs this the correct way to record errors on spans?",
+    "trap": "Without the skill, the model may approve this since RecordError is called, missing that SetStatus must also be called",
+    "assertions": [
+      {"id": "12.1", "text": "Identifies that span.SetStatus(codes.Error, ...) is also needed alongside RecordError"},
+      {"id": "12.2", "text": "Explains that RecordError adds an event but does not mark the span as failed"},
+      {"id": "12.3", "text": "Shows the corrected pattern with both span.RecordError(err) and span.SetStatus(codes.Error, ...)"},
+      {"id": "12.4", "text": "Notes that on success, no status needs to be set (Unset is fine)"}
+    ]
+  },
+  {
+    "id": 13,
+    "name": "trace-context-lost-in-background-goroutine",
+    "description": "Tests that a new goroutine spawned inside a span loses trace context unless ctx is explicitly propagated",
+    "prompt": "My Go service sends a notification after processing an order. I want it to be non-blocking so I spawn a goroutine:\n\nfunc (s *OrderService) Process(ctx context.Context, order Order) error {\n    ctx, span := tracer.Start(ctx, \"process-order\")\n    defer span.End()\n\n    // business logic...\n\n    go func() {\n        s.notifier.Send(context.Background(), order.UserID, \"Order confirmed\")\n    }()\n\n    return nil\n}\n\nI have OpenTelemetry configured. Why doesn't the notification span appear as a child of process-order in my traces?",
+    "trap": "Without the skill, the model may suggest the span setup is fine or focus on goroutine lifecycle, missing that context.Background() discards the parent trace context",
+    "assertions": [
+      {"id": "13.1", "text": "Identifies that context.Background() discards the trace context — the notification has no parent span"},
+      {"id": "13.2", "text": "Explains that the trace context (trace_id, span_id) travels only inside the ctx variable"},
+      {"id": "13.3", "text": "Shows the fix: capture ctx before the goroutine and pass it in (not context.Background())"},
+      {"id": "13.4", "text": "Notes that the notification goroutine may outlive the parent span, but trace propagation still requires passing the original ctx"}
+    ]
+  },
+  {
+    "id": 14,
+    "name": "db-query-context-propagation",
+    "description": "Tests that database calls must use *Context variants for trace propagation",
+    "prompt": "My Go service has OpenTelemetry tracing, but I notice my database queries don't appear as spans in traces. Here's my code:\n\nresult, err := db.Query(\"SELECT * FROM users WHERE id = $1\", userID)\n\nWhat am I missing?",
+    "trap": "Without the skill, the model may suggest adding manual spans around the query, missing the fundamental issue of not passing context",
+    "assertions": [
+      {"id": "14.1", "text": "Identifies that db.Query should be db.QueryContext(ctx, ...) to propagate trace context"},
+      {"id": "14.2", "text": "Explains that without context, the trace is broken — child spans cannot be created"},
+      {"id": "14.3", "text": "Shows the corrected code using db.QueryContext(ctx, ...)"},
+      {"id": "14.4", "text": "States that context is the vehicle that carries trace_id and span_id across boundaries"}
+    ]
+  },
+  {
+    "id": 15,
+    "name": "trace-sampling-cost-control",
+    "description": "Tests awareness of trace sampling strategies and cost implications",
+    "prompt": "My Go microservice handles 50,000 requests per second. I enabled OpenTelemetry tracing at 100% sampling and my tracing backend costs tripled. How should I control tracing costs without losing visibility?",
+    "trap": "Without the skill, the model may suggest only reducing sampling ratio, missing the nuances of ParentBased sampling and the specific recommendation to start at 10%",
+    "assertions": [
+      {"id": "15.1", "text": "Recommends TraceIDRatioBased sampling with a specific ratio (e.g., 0.1 for 10%)"},
+      {"id": "15.2", "text": "Mentions ParentBased sampler to respect parent's sampling decision and keep traces complete across services"},
+      {"id": "15.3", "text": "Discusses head-based vs tail-based sampling tradeoffs"},
+      {"id": "15.4", "text": "Recommends avoiding large payloads as span attributes — log them instead and correlate via trace_id"},
+      {"id": "15.5", "text": "Explains the cost factors: span volume, span attributes, storage and indexing"}
+    ]
+  },
+  {
+    "id": 16,
+    "name": "where-to-add-spans",
+    "description": "Tests knowledge of which operations must have spans in OpenTelemetry",
+    "prompt": "I'm adding OpenTelemetry tracing to my existing Go service. Which functions should I add spans to? I don't want to instrument everything unnecessarily.",
+    "trap": "Without the skill, the model may give vague guidance like 'important functions', missing the specific categories the skill defines",
+    "assertions": [
+      {"id": "16.1", "text": "Lists service methods (business logic layer) as requiring spans"},
+      {"id": "16.2", "text": "Lists database queries as requiring spans"},
+      {"id": "16.3", "text": "Lists external API calls as requiring spans"},
+      {"id": "16.4", "text": "Lists message queue publish/consume operations as requiring spans"},
+      {"id": "16.5", "text": "States any operation that takes measurable time or could fail should have a span"}
+    ]
+  },
+  {
+    "id": 17,
+    "name": "four-golden-signals-alerting",
+    "description": "Tests knowledge of the four golden signals for service alerting",
+    "prompt": "I'm setting up alerting for my new Go API service from scratch. I have Prometheus metrics. What should I alert on? Give me the essential alerts.",
+    "trap": "Without the skill, the model may list ad-hoc alerts, missing the structured four golden signals framework",
+    "assertions": [
+      {"id": "17.1", "text": "References the four golden signals (from Google SRE): latency, traffic, errors, saturation"},
+      {"id": "17.2", "text": "Includes a latency alert (e.g., P99 > threshold)"},
+      {"id": "17.3", "text": "Includes a traffic alert (e.g., zero requests detection)"},
+      {"id": "17.4", "text": "Includes an error rate alert (e.g., 5xx ratio > threshold)"},
+      {"id": "17.5", "text": "Includes a saturation alert (e.g., connection pool > 90%)"}
+    ]
+  },
+  {
+    "id": 18,
+    "name": "awesome-prometheus-alerts-resource",
+    "description": "Tests whether the model recommends awesome-prometheus-alerts as a starting point for infrastructure alerting",
+    "prompt": "I'm adding PostgreSQL and Redis to my Go service and need alerting rules. Should I write Prometheus alert rules from scratch for each dependency?",
+    "trap": "Without the skill, the model will likely suggest writing rules from scratch or generic examples",
+    "assertions": [
+      {"id": "18.1", "text": "Recommends awesome-prometheus-alerts (samber.github.io/awesome-prometheus-alerts/) as a starting point"},
+      {"id": "18.2", "text": "Mentions it contains ~500 ready-to-use Prometheus alerting rules organized by technology"},
+      {"id": "18.3", "text": "Suggests the workflow: browse by technology, copy rules, customize thresholds"},
+      {"id": "18.4", "text": "Mentions verifying that exporters (postgres_exporter, redis_exporter) are deployed"}
+    ]
+  },
+  {
+    "id": 19,
+    "name": "go-runtime-alerts",
+    "description": "Tests knowledge of Go runtime-specific alerts using default Prometheus client metrics",
+    "prompt": "My Go service occasionally becomes unresponsive. I suspect goroutine leaks or GC pressure. What Go runtime-specific Prometheus alerts should I set up?",
+    "trap": "Without the skill, the model may suggest only basic goroutine count alerts, missing the full set of runtime alerts",
+    "assertions": [
+      {"id": "19.1", "text": "Suggests alerting on go_goroutines exceeding a threshold (e.g., > 1000) for goroutine leaks"},
+      {"id": "19.2", "text": "Suggests alerting on go_gc_duration_seconds for GC pressure"},
+      {"id": "19.3", "text": "Suggests alerting on go_memstats_alloc_bytes / go_memstats_sys_bytes for memory leaks"},
+      {"id": "19.4", "text": "Suggests alerting on go_threads for high OS thread count"},
+      {"id": "19.5", "text": "Uses for: duration on all non-binary alerts to avoid false positives"}
+    ]
+  },
+  {
+    "id": 20,
+    "name": "alert-severity-levels",
+    "description": "Tests correct severity classification and for: durations",
+    "prompt": "I'm categorizing my Prometheus alerts. Should goroutine leaks be critical? What about service down? What for: durations should I use for each severity?",
+    "trap": "Without the skill, the model may assign arbitrary severity levels, missing the two-level system with specific for: duration guidance",
+    "assertions": [
+      {"id": "20.1", "text": "Uses two severity levels: critical (page on-call) and warning (create ticket)"},
+      {"id": "20.2", "text": "Critical alerts: for: 2m to 5m for fast detection"},
+      {"id": "20.3", "text": "Warning alerts: for: 10m to 30m for confirmed trends"},
+      {"id": "20.4", "text": "Classifies service down as critical with short for: duration"},
+      {"id": "20.5", "text": "Classifies goroutine leak as warning (not critical)"},
+      {"id": "20.6", "text": "States that for: 0m should never be used on non-binary alerts"}
+    ]
+  },
+  {
+    "id": 21,
+    "name": "multi-window-burn-rate-slo",
+    "description": "Tests knowledge of multi-window burn-rate SLO alerting over simple threshold alerts",
+    "prompt": "My Go API has a 99.9% availability SLO. I currently alert when error rate exceeds 1%. But I get false positives from brief spikes and miss slow degradation. How should I improve my alerting?",
+    "trap": "Without the skill, the model may suggest tuning the threshold or adding for: duration, missing the multi-window burn-rate approach",
+    "assertions": [
+      {"id": "21.1", "text": "Recommends multi-window burn-rate alerting instead of simple threshold alerts"},
+      {"id": "21.2", "text": "Explains the concept of error budget and burn rate"},
+      {"id": "21.3", "text": "Includes fast burn window (e.g., 5m + 1h, 14.4x burn rate) as critical/page"},
+      {"id": "21.4", "text": "Includes slow burn window (e.g., 2h + 24h, 1x burn rate) as warning/ticket"},
+      {"id": "21.5", "text": "Shows PromQL using AND of short and long windows to eliminate false positives from transient blips"}
+    ]
+  },
+  {
+    "id": 22,
+    "name": "slog-migration-from-zap",
+    "description": "Tests the incremental migration strategy from zap to slog using bridge handlers",
+    "prompt": "My Go codebase has 500+ files using zap for logging. We want to migrate to slog. How do we do this without a big-bang rewrite?",
+    "trap": "Without the skill, the model may suggest a gradual replacement without the bridge handler step, or suggest running both loggers in parallel",
+    "assertions": [
+      {"id": "22.1", "text": "Recommends a three-step migration: bridge, replace call sites, remove bridge"},
+      {"id": "22.2", "text": "Step 1: Use samber/slog-zap bridge handler to route slog output through zap"},
+      {"id": "22.3", "text": "Step 2: Gradually replace zap.L().Info(...) calls with slog.Info(...)"},
+      {"id": "22.4", "text": "Step 3: Once fully migrated, replace the bridge with native slog JSONHandler and remove zap dependency"},
+      {"id": "22.5", "text": "Mentions using parallel sub-agents for large codebase migration (assigning independent packages to each)"}
+    ]
+  },
+  {
+    "id": 23,
+    "name": "slog-migration-from-logrus",
+    "description": "Tests the bridge handler approach for logrus migration",
+    "prompt": "We use logrus throughout our Go project and want to standardize on slog. Is there a way to migrate incrementally?",
+    "trap": "Without the skill, the model may not know about samber/slog-logrus bridge",
+    "assertions": [
+      {"id": "23.1", "text": "Recommends using samber/slog-logrus bridge handler for incremental migration"},
+      {"id": "23.2", "text": "Explains that slog is the standard library logger since Go 1.21"},
+      {"id": "23.3", "text": "Shows the bridge step: route slog output through the existing logrus logger"},
+      {"id": "23.4", "text": "Shows the replacement: logrus.WithField(\"key\", val).Info(\"msg\") becomes slog.Info(\"msg\", \"key\", val)"}
+    ]
+  },
+  {
+    "id": 24,
+    "name": "debug-level-production-cost",
+    "description": "Tests awareness of log level cost implications in production",
+    "prompt": "I'm setting up slog for my Go production service. To maximize debugging ability, I'm considering setting the log level to Debug so we always have full visibility. What log level should I use?",
+    "trap": "Without the skill, the model may suggest Debug with a generic caveat about volume, missing the specific cost analysis",
+    "assertions": [
+      {"id": "24.1", "text": "Recommends slog.LevelInfo for production, NOT Debug"},
+      {"id": "24.2", "text": "Explains that Debug level can generate millions of log lines per minute in busy services"},
+      {"id": "24.3", "text": "Mentions cost: CPU for serialization, I/O for disk/network, money for log ingestion/storage"},
+      {"id": "24.4", "text": "Mentions Debug can inflate costs by 10-100x"},
+      {"id": "24.5", "text": "Suggests samber/slog-sampling as an alternative to sample verbose logs rather than dropping entirely"}
+    ]
+  },
+  {
+    "id": 25,
+    "name": "ip-address-pii-in-logs",
+    "description": "Tests whether the model recognizes IP address as PII that requires care in logs",
+    "prompt": "I'm adding observability to my Go authentication service. Here's my access log:\n\nslog.Info(\"login attempt\",\n    \"user_id\", req.UserID,\n    \"ip\", r.RemoteAddr,\n    \"user_agent\", r.UserAgent(),\n    \"success\", success,\n)\n\nThis looks useful for detecting brute-force attacks. Is there a compliance concern?",
+    "trap": "Without the skill, the model validates this as good observability practice since IP addresses are legitimately useful for security. The model knows email/SSN are PII but commonly misses that IP address is also regulated PII under GDPR.",
+    "assertions": [
+      {"id": "25.1", "text": "Identifies IP address (r.RemoteAddr) as PII under GDPR and CCPA"},
+      {"id": "25.2", "text": "Notes that user_agent can also be a fingerprinting vector that combines to uniquely identify a user"},
+      {"id": "25.3", "text": "Recommends a legal/privacy review before logging IP addresses in European services"},
+      {"id": "25.4", "text": "Suggests using hashed, truncated, or anonymized IPs if full IP is not required by the security use case"}
+    ]
+  },
+  {
+    "id": 26,
+    "name": "gauge-should-not-have-total-suffix",
+    "description": "Tests that Gauge metrics must NOT use _total suffix, and counters MUST",
+    "prompt": "I'm declaring Prometheus metrics for my Go service. Review these declarations:\n\nvar activeConnections = promauto.NewGauge(prometheus.GaugeOpts{\n    Namespace: \"myapp\",\n    Name:      \"connections_active_total\",\n})\n\nvar requestsProcessed = promauto.NewCounter(prometheus.CounterOpts{\n    Namespace: \"myapp\",\n    Name:      \"requests_processed\",\n})\n\nAre these names correct?",
+    "trap": "Without the skill, the model may only flag one issue or swap the corrections. Gauges must NOT use _total; counters MUST use _total. Using _total on a gauge implies it is cumulative when it is not.",
+    "assertions": [
+      {"id": "26.1", "text": "Flags connections_active_total as incorrect — Gauges must NOT use _total suffix because _total implies a counter (monotonically increasing cumulative value)"},
+      {"id": "26.2", "text": "Recommends renaming the gauge to myapp_connections_active (no _total)"},
+      {"id": "26.3", "text": "Flags requests_processed as incorrect — Counters MUST end with _total"},
+      {"id": "26.4", "text": "Recommends renaming the counter to myapp_requests_processed_total"}
+    ]
+  },
+  {
+    "id": 27,
+    "name": "pprof-exposed-on-public-mux",
+    "description": "Tests that importing net/http/pprof registers on the default mux which may serve public traffic",
+    "prompt": "I want to enable pprof for my Go production service. I see that just adding `import _ \"net/http/pprof\"` is enough. My service uses http.ListenAndServe(\":8080\", nil) for its API. Is this safe?",
+    "trap": "Without the skill, the model may warn generically about security but miss the specific mechanism: the blank import registers handlers on http.DefaultServeMux which is the nil mux used by ListenAndServe — pprof is served publicly on port 8080",
+    "assertions": [
+      {"id": "27.1", "text": "Identifies that import _ \"net/http/pprof\" registers /debug/pprof/ routes on http.DefaultServeMux"},
+      {"id": "27.2", "text": "Explains that http.ListenAndServe(\":8080\", nil) uses http.DefaultServeMux as its handler — pprof is publicly accessible on port 8080"},
+      {"id": "27.3", "text": "Recommends serving pprof on a separate internal port (e.g., :6060) using a dedicated ServeMux or http.Server"},
+      {"id": "27.4", "text": "Warns that pprof leaks sensitive runtime information (goroutine stacks, heap profiles, environment) and should never be publicly accessible"}
+    ]
+  },
+  {
+    "id": 28,
+    "name": "continuous-profiling-env-toggle",
+    "description": "Tests the recommendation to toggle continuous profiling via environment variables",
+    "prompt": "I want to set up Pyroscope continuous profiling for my Go production service. Should I always have it enabled on all instances?",
+    "trap": "Without the skill, the model may recommend always-on profiling on all instances",
+    "assertions": [
+      {"id": "28.1", "text": "Recommends toggling via environment variable (e.g., PROFILING_ENABLED)"},
+      {"id": "28.2", "text": "Mentions ~2-5% CPU overhead for continuous profiling"},
+      {"id": "28.3", "text": "Suggests starting with CPU + heap profiles only, adding mutex/block when needed"},
+      {"id": "28.4", "text": "For large deployments, recommends enabling on a fraction of replicas (e.g., 1 in 10)"},
+      {"id": "28.5", "text": "Shows code that checks the environment variable before starting Pyroscope"}
+    ]
+  },
+  {
+    "id": 29,
+    "name": "rum-identity-key-email-trap",
+    "description": "Tests that RUM distinct_id must be user_id, not email",
+    "prompt": "I'm integrating PostHog server-side tracking in my Go service. For the DistinctId, I'm using the user's email since it's a natural identifier users know. Here's my code:\n\nposthogClient.Enqueue(posthog.Capture{\n    DistinctId: user.Email,\n    Event: \"order_completed\",\n})\n\nIs this correct?",
+    "trap": "Without the skill, the model may accept email as a valid identifier since it's unique",
+    "assertions": [
+      {"id": "29.1", "text": "Rejects email as the DistinctId — must use user_id instead"},
+      {"id": "29.2", "text": "Explains that email is mutable — users change it, splitting events into two users"},
+      {"id": "29.3", "text": "Explains that email is PII, complicating GDPR/CCPA compliance"},
+      {"id": "29.4", "text": "Notes that email leaks into third-party analytics systems as the identity key"},
+      {"id": "29.5", "text": "Shows corrected code using user.ID (immutable internal identifier)"}
+    ]
+  },
+  {
+    "id": 30,
+    "name": "gdpr-consent-before-tracking",
+    "description": "Tests that GDPR consent must be checked before sending analytics events",
+    "prompt": "I'm adding PostHog server-side event tracking to my Go e-commerce service for European users. Here's my order completion handler — it tracks the event after business logic:\n\nfunc (s *OrderService) Complete(ctx context.Context, order Order) error {\n    // ... business logic ...\n    posthogClient.Enqueue(posthog.Capture{\n        DistinctId: order.UserID,\n        Event: \"order_completed\",\n    })\n    return nil\n}\n\nAnything I'm missing for EU compliance?",
+    "trap": "Without the skill, the model may suggest a privacy policy or cookie consent without the server-side consent check pattern",
+    "assertions": [
+      {"id": "30.1", "text": "Identifies that consent must be checked before sending the tracking event"},
+      {"id": "30.2", "text": "Shows extracting consent from context and conditionally tracking"},
+      {"id": "30.3", "text": "Mentions GDPR fines (up to 4% of global revenue) or CCPA penalties"},
+      {"id": "30.4", "text": "References data minimization — only collect what you need"},
+      {"id": "30.5", "text": "Mentions data subject rights endpoints (data export and deletion)"}
+    ]
+  },
+  {
+    "id": 31,
+    "name": "data-subject-rights-endpoints",
+    "description": "Tests that GDPR requires data deletion and export endpoints that propagate to all systems",
+    "prompt": "A user of my Go SaaS service (with PostHog analytics and Segment CDP) requests deletion of all their data under GDPR. My current implementation just deletes from the database. Is that sufficient?",
+    "trap": "Without the skill, the model may say database deletion is sufficient or only mention one additional system",
+    "assertions": [
+      {"id": "31.1", "text": "States that deletion must propagate to ALL systems holding user data, not just the database"},
+      {"id": "31.2", "text": "Lists the analytics platform (PostHog) as needing deletion"},
+      {"id": "31.3", "text": "Lists the CDP (Segment) as needing deletion"},
+      {"id": "31.4", "text": "References GDPR Article 17 Right to Erasure"},
+      {"id": "31.5", "text": "Also mentions the Right of Access (data export endpoint) as a requirement"}
+    ]
+  },
+  {
+    "id": 32,
+    "name": "five-signals-completeness",
+    "description": "Tests knowledge of the five observability signals and their distinct roles",
+    "prompt": "I'm building a new Go microservice. What observability signals should I implement for production readiness?",
+    "trap": "Without the skill, the model typically covers logs, metrics, traces but misses profiles and RUM",
+    "assertions": [
+      {"id": "32.1", "text": "Lists all five signals: logs, metrics, traces, profiles, and RUM"},
+      {"id": "32.2", "text": "Associates logs with 'what happened' (discrete events, audit trails)"},
+      {"id": "32.3", "text": "Associates metrics with 'how much/how fast' (aggregated measurements, alerting, SLOs)"},
+      {"id": "32.4", "text": "Associates traces with 'where did time go' (request flow across services)"},
+      {"id": "32.5", "text": "Associates profiles with 'why is it slow/using memory' (CPU hotspots, memory leaks)"},
+      {"id": "32.6", "text": "Associates RUM with 'how do users experience it' (product analytics, funnels)"}
+    ]
+  },
+  {
+    "id": 33,
+    "name": "definition-of-done-observability",
+    "description": "Tests the observability definition of done checklist before shipping a feature",
+    "prompt": "I'm about to ship a new payment processing feature in my Go service. My code works, tests pass, and it's been code-reviewed. Am I ready to deploy?",
+    "trap": "Without the skill, the model may say yes or mention generic deployment checks, missing the observability-specific definition of done",
+    "assertions": [
+      {"id": "33.1", "text": "States that a feature is not production-ready until it is observable"},
+      {"id": "33.2", "text": "Checks for metric declarations (counters, histograms, gauges) with PromQL comments"},
+      {"id": "33.3", "text": "Checks for proper structured logging with slog and context variants"},
+      {"id": "33.4", "text": "Checks for OpenTelemetry spans on service methods, DB queries, and external calls"},
+      {"id": "33.5", "text": "Checks for dashboards and alerts being wired up"},
+      {"id": "33.6", "text": "Checks that errors are either logged OR returned, never both"}
+    ]
+  },
+  {
+    "id": 34,
+    "name": "grafana-dashboard-ids",
+    "description": "Tests knowledge of specific Grafana dashboard IDs for Go runtime monitoring",
+    "prompt": "I want to monitor my Go service's runtime metrics (goroutines, heap, GC) in Grafana. Are there prebuilt dashboards I can use?",
+    "trap": "Without the skill, the model will likely suggest building custom dashboards from scratch",
+    "assertions": [
+      {"id": "34.1", "text": "Recommends specific Grafana dashboard IDs (21221, 6671, or 10826)"},
+      {"id": "34.2", "text": "Mentions dashboard 21221 for host + runtime combined view (or similar description)"},
+      {"id": "34.3", "text": "Explains that these dashboards use default Go collector metrics from the Prometheus client library"},
+      {"id": "34.4", "text": "Shows how to import: Dashboards > New > Import, enter the dashboard ID"}
+    ]
+  },
+  {
+    "id": 35,
+    "name": "slog-error-as-attr-not-positional",
+    "description": "Tests whether the model uses slog.Any/slog.Attr correctly for error values vs positional args",
+    "prompt": "I'm logging errors in my Go service using slog. Review this code:\n\nif err != nil {\n    slog.ErrorContext(ctx, \"payment failed\", err, \"order_id\", orderID)\n    return err\n}\n\nDoes this look right?",
+    "trap": "Without the skill, the model may miss that passing err directly as a positional argument (not as a named key-value pair) is incorrect. slog expects alternating key-value pairs; err as a positional arg becomes the key with its string representation, losing structured error metadata.",
+    "assertions": [
+      {"id": "35.1", "text": "Identifies that err is passed as a positional argument without a key name, which is incorrect for slog"},
+      {"id": "35.2", "text": "Explains that slog expects alternating key-value pairs — passing err without a key makes slog treat it as a mismatched argument or key"},
+      {"id": "35.3", "text": "Shows the corrected form using a named key: slog.ErrorContext(ctx, \"payment failed\", \"error\", err, \"order_id\", orderID)"},
+      {"id": "35.4", "text": "Notes that the correct form preserves the error's structured information (message, type) in the log record"}
+    ]
+  },
+  {
+    "id": 36,
+    "name": "slog-ecosystem-handlers",
+    "description": "Tests awareness of the slog handler ecosystem beyond stdlib",
+    "prompt": "I need my Go service logs to go to multiple destinations: JSON to stdout, errors to Sentry, and all logs to Datadog. Can slog do this?",
+    "trap": "Without the skill, the model may suggest writing custom handlers from scratch",
+    "assertions": [
+      {"id": "36.1", "text": "Recommends stdlib slog.NewMultiHandler for simple fan-out on Go 1.26+, or samber/slog-multi when stdlib composition is insufficient"},
+      {"id": "36.2", "text": "Mentions samber/slog-sentry for sending errors to Sentry"},
+      {"id": "36.3", "text": "Mentions samber/slog-datadog for sending logs to Datadog"},
+      {"id": "36.4", "text": "Explains that slog supports pluggable handlers"},
+      {"id": "36.5", "text": "References the slog ecosystem (go.dev/wiki/Resources-for-slog or similar)"}
+    ]
+  },
+  {
+    "id": 37,
+    "name": "parallel-observability-audit",
+    "description": "Tests the recommendation to use parallel sub-agents for observability audits in large codebases",
+    "prompt": "I need to audit observability across a Go monolith with 200+ packages. How should I approach this efficiently?",
+    "trap": "Without the skill, the model may suggest a linear, package-by-package approach",
+    "assertions": [
+      {"id": "37.1", "text": "Recommends using up to 5 parallel sub-agents (via the Agent tool)"},
+      {"id": "37.2", "text": "Assigns one sub-agent per signal: metrics, logging, tracing, profiling, RUM"},
+      {"id": "37.3", "text": "Sub-agent for metrics: verify metric declarations and PromQL comments"},
+      {"id": "37.4", "text": "Sub-agent for logging: check structured logging, PII in logs, error logging patterns"},
+      {"id": "37.5", "text": "Sub-agent for tracing: verify span creation in service methods, DB calls, API calls"}
+    ]
+  },
+  {
+    "id": 38,
+    "name": "predict-linear-for-saturation",
+    "description": "Tests knowledge of predict_linear PromQL function for anticipating resource exhaustion",
+    "prompt": "My Go service's database connection pool occasionally hits the maximum and requests start failing. I want to be alerted BEFORE it reaches the limit, not after. How can I set up predictive alerting?",
+    "trap": "Without the skill, the model may suggest a simple threshold alert at 90%, missing the predict_linear approach",
+    "assertions": [
+      {"id": "38.1", "text": "Recommends using predict_linear() PromQL function to extrapolate trends"},
+      {"id": "38.2", "text": "Shows an expression like: predict_linear(db_connections_active[15m], 600) > db_connections_max"},
+      {"id": "38.3", "text": "Explains that predict_linear extrapolates from recent trend to predict future value"},
+      {"id": "38.4", "text": "Also suggests a threshold alert (e.g., > 90%) as a complementary alert"}
+    ]
+  },
+  {
+    "id": 39,
+    "name": "self-hosted-rum-gdpr",
+    "description": "Tests the recommendation of self-hosted analytics for GDPR compliance simplification",
+    "prompt": "We're building a Go SaaS product targeting EU customers. We need product analytics (funnels, user behavior) but our legal team is concerned about sending user data to US-based analytics vendors. What should we do?",
+    "trap": "Without the skill, the model may suggest DPAs and SCCs with SaaS vendors, missing the self-hosted option",
+    "assertions": [
+      {"id": "39.1", "text": "Recommends self-hosted analytics (PostHog or Matomo) for EU data residency"},
+      {"id": "39.2", "text": "Explains that self-hosting eliminates cross-border data transfer concerns"},
+      {"id": "39.3", "text": "Compares self-hosted vs SaaS tradeoffs (data residency, cost, maintenance, features)"},
+      {"id": "39.4", "text": "Mentions that PostHog can be self-hosted to keep data in your own infrastructure"}
+    ]
+  },
+  {
+    "id": 40,
+    "name": "oops-structured-errors-tracing",
+    "description": "Tests awareness of samber/oops for structured errors in tracing context",
+    "prompt": "My Go service records errors on OpenTelemetry spans using span.RecordError(err). But the error messages are generic like 'connection refused' with no stack trace or request context. How can I get richer error information in my traces?",
+    "trap": "Without the skill, the model may suggest manually adding attributes to spans or using fmt.Errorf with more context",
+    "assertions": [
+      {"id": "40.1", "text": "Recommends samber/oops for structured errors with stack traces"},
+      {"id": "40.2", "text": "Shows using oops to wrap errors with domain (.In()), error code (.Code()), and structured attributes (.With())"},
+      {"id": "40.3", "text": "Explains that oops errors carry stack trace, structured context, and work with span.RecordError()"},
+      {"id": "40.4", "text": "Mentions compatibility with errors.Is/errors.As and slog"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/alerting.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/alerting.md
new file mode 100644
index 00000000..c810eade
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/alerting.md
@@ -0,0 +1,186 @@
+# Alerting
+
+> See [metrics.md](metrics.md) for multi-window burn-rate SLO alerting and PromQL patterns for application metrics.
+
+## The Four Golden Signals
+
+Alert on what matters to users. Google's SRE book defines four golden signals — every Go service SHOULD have alerts covering all four:
+
+| Signal | What it measures | Example metric | Alert trigger |
+| --- | --- | --- | --- |
+| **Latency** | Time to serve a request | `http_request_duration_seconds` (Histogram) | P99 > 2s for 5 minutes |
+| **Traffic** | Demand on the system | `http_requests_total` (Counter) | Zero requests for 10 minutes |
+| **Errors** | Rate of failed requests | `http_requests_total{status=~"5.."}` (Counter) | Error ratio > 1% for 5 minutes |
+| **Saturation** | How full the system is | `db_connections_active / db_connections_max` | Pool > 90% saturated for 5 minutes |
+
+## Awesome Prometheus Alerts
+
+[awesome-prometheus-alerts](https://samber.github.io/awesome-prometheus-alerts/) is a curated collection of ~500 ready-to-use Prometheus alerting rules. This collection serves as a starting point for infrastructure and dependency alerting.
+
+### Categories
+
+| Category | Rules | Covers |
+| --- | --: | --- |
+| **Basic Resource Monitoring** | ~107 | Host metrics, Docker containers, hardware |
+| **Databases and Brokers** | ~233 | PostgreSQL, MySQL, Redis, MongoDB, Kafka, RabbitMQ, etc. |
+| **Reverse Proxies and Load Balancers** | ~45 | Nginx, Apache, HAProxy, Traefik |
+| **Runtimes** | ~4 | PHP-FPM, JVM, Sidekiq |
+| **Orchestrators** | ~74 | Kubernetes, Nomad, Consul, ArgoCD |
+| **Network, Security, and Storage** | ~40 | Ceph, MinIO, SSL/TLS, DNS |
+
+### How to Use It
+
+The rules are organized by technology. Each rule is a ready-to-use Prometheus alerting rule in YAML format with customizable threshold values and `for:` durations.
+
+1. **Find by technology** — locate the relevant database, message broker, or infrastructure component
+2. **Adapt the YAML rule** — adjust threshold values (`> 0.01`, `> 100`, etc.) and the `for:` duration to match your SLOs and traffic patterns
+3. **Place in Prometheus config** — add to the `prometheus/rules/` directory
+
+### Integration Example
+
+Prometheus loads alerting rules from YAML files referenced in its config. After copying rules from awesome-prometheus-alerts, place them in your rules directory:
+
+```yaml
+# prometheus/rules/postgresql.yml
+groups:
+  - name: postgresql
+    rules:
+      # From awesome-prometheus-alerts — PostgreSQL section
+      - alert: PostgresqlDown
+        expr: pg_up == 0
+        for: 0m
+        labels:
+          severity: critical
+        annotations:
+          summary: "PostgreSQL down (instance {{ $labels.instance }})"
+          description: "PostgreSQL instance is down.\n  VALUE = {{ $value }}"
+
+      - alert: PostgresqlTooManyConnections
+        expr: sum by (instance, datname) (pg_stat_activity_count{datname!~"template.*|postgres"}) > pg_settings_max_connections * 0.8
+        for: 2m
+        labels:
+          severity: warning
+        annotations:
+          summary: "PostgreSQL too many connections (> 80%) (instance {{ $labels.instance }})"
+          description: "PostgreSQL has {{ $value }} connections on {{ $labels.datname }}."
+```
+
+```yaml
+# prometheus.yml
+rule_files:
+  - "rules/*.yml"
+```
+
+### Workflow for New Dependencies
+
+When adding a new infrastructure dependency (database, cache, message broker, reverse proxy) to a Go service:
+
+1. [awesome-prometheus-alerts](https://samber.github.io/awesome-prometheus-alerts/) has alert rules organized by technology
+2. Adapt the relevant alert rules and thresholds to your environment
+3. Verify the exporter is deployed (e.g., `postgres_exporter`, `redis_exporter`) — the alerts depend on metrics from these exporters
+4. Add the rules to your `prometheus/rules/` directory
+
+## Go Runtime Alerts
+
+The Prometheus Go client automatically exposes runtime metrics. Alert on these to catch resource leaks and GC pressure before they impact users.
+
+```yaml
+# prometheus/rules/go-runtime.yml
+groups:
+  - name: go-runtime
+    rules:
+      # Goroutine leak — count growing steadily indicates a leak
+      # Diagnose: GET /debug/pprof/goroutine?debug=1 to see goroutine stack traces
+      - alert: GoroutineLeak
+        expr: go_goroutines > 1000
+        for: 10m
+        labels:
+          severity: warning
+        annotations:
+          summary: "High goroutine count (instance {{ $labels.instance }})"
+          description: "Goroutine count is {{ $value }}, possible leak."
+
+      # GC taking too long — P99 GC pause > 100ms degrades tail latency
+      - alert: HighGCDuration
+        expr: go_gc_duration_seconds{quantile="1"} > 0.1
+        for: 5m
+        labels:
+          severity: warning
+        annotations:
+          summary: "High GC duration (instance {{ $labels.instance }})"
+          description: "Max GC pause is {{ $value }}s. Check heap allocations."
+
+      # Heap growing unbounded — likely a memory leak
+      - alert: HighMemoryUsage
+        expr: go_memstats_alloc_bytes / go_memstats_sys_bytes > 0.9
+        for: 5m
+        labels:
+          severity: critical
+        annotations:
+          summary: "High memory usage (instance {{ $labels.instance }})"
+          description: "Allocated heap is {{ $value | humanizePercentage }} of system memory."
+
+      # Too many threads — usually caused by blocking syscalls or cgo
+      - alert: HighThreadCount
+        expr: go_threads > 500
+        for: 5m
+        labels:
+          severity: warning
+        annotations:
+          summary: "High OS thread count (instance {{ $labels.instance }})"
+          description: "Thread count is {{ $value }}. Check for blocking syscalls."
+```
+
+## Alert Severity Levels
+
+Use two severity levels to separate "wake someone up" from "look at it tomorrow":
+
+| Severity | Action | `for:` duration | Example |
+| --- | --- | --- | --- |
+| **critical** | Page on-call | 2-5 minutes | Service down, error rate > 5%, data loss risk |
+| **warning** | Create ticket | 10-30 minutes | P99 latency high, connection pool > 80%, goroutine leak |
+
+The `for:` duration controls how long a condition must be true before the alert fires. Short durations catch fast incidents but risk false positives from transient spikes. Long durations reduce noise but delay response.
+
+**Guidelines:**
+
+- Critical alerts: `for: 2m` to `for: 5m` — fast detection, wake someone up
+- Warning alerts: `for: 10m` to `for: 30m` — confirmed trend, create a ticket
+- NEVER set `for: 0m` on non-binary alerts — one bad scrape triggers a false page
+- Binary alerts (service up/down) can use `for: 0m` or `for: 1m`
+
+## Common Mistakes
+
+```yaml
+# Bad -- irate() is too volatile for alerts, reacts to a single scrape interval
+# A brief spike or a single slow request triggers the alert
+- alert: HighErrorRate
+  expr: irate(http_requests_total{status=~"5.."}[5m]) > 0.01
+
+# Good -- rate() smooths over the full window, reducing false positives
+- alert: HighErrorRate
+  expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.01
+  for: 5m
+```
+
+```yaml
+# Bad -- no "for:" duration, fires on a single bad scrape
+- alert: HighLatency
+  expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 2
+
+# Good -- must be true for 5 minutes to fire
+- alert: HighLatency
+  expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 2
+  for: 5m
+```
+
+```yaml
+# Bad -- alerting on raw gauge without trend analysis (flaps constantly)
+- alert: HighQueueDepth
+  expr: myapp_queue_messages_pending > 1000
+
+# Good -- alert on sustained growth trend
+- alert: HighQueueDepth
+  expr: myapp_queue_messages_pending > 1000
+  for: 10m
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/dashboards.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/dashboards.md
new file mode 100644
index 00000000..cbf2a558
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/dashboards.md
@@ -0,0 +1,23 @@
+# Grafana Dashboards for Go Services
+
+These community Grafana dashboards visualize Go runtime performance out of the box. They display the metrics automatically exposed by `github.com/prometheus/client_golang` — no custom instrumentation needed.
+
+## Recommended Dashboards
+
+| Dashboard | ID | What it shows |
+| --- | --: | --- |
+| [Go Host & Runtime Metrics](https://grafana.com/grafana/dashboards/21221-go-host-runtime-metrics-dashboard/) | 21221 | Host metrics + Go runtime (goroutines, heap, GC, threads) in one view |
+| [Go Processes](https://grafana.com/grafana/dashboards/6671-go-processes/) | 6671 | Multi-process comparison — CPU, memory, goroutines, GC across all Go services |
+| [Go Metrics](https://grafana.com/grafana/dashboards/10826-go-metrics/) | 10826 | Focused Go runtime view — memory breakdown, GC pauses, allocations, goroutines |
+
+## How to Install
+
+Dashboards are imported via **Dashboards > New > Import** in Grafana using the dashboard ID (e.g., `21221`), then selecting the Prometheus data source.
+
+These dashboards require the default Go collector metrics (`go_goroutines`, `go_memstats_*`, `go_gc_duration_seconds`, `process_*`). If you use the Prometheus client library with default collectors, everything works out of the box.
+
+## When to Use Each
+
+- **21221** (Host & Runtime) — day-to-day monitoring of a single Go service alongside its host. Best as the default Go dashboard.
+- **6671** (Go Processes) — comparing multiple Go services or replicas side by side. Useful during deployments to spot regressions across instances.
+- **10826** (Go Metrics) — deep-diving into memory and GC behavior of a single service. Best for investigating performance issues.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/logging.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/logging.md
new file mode 100644
index 00000000..87011581
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/logging.md
@@ -0,0 +1,189 @@
+# Structured Logging with `slog`
+
+→ See `samber/cc-skills-golang@golang-error-handling` skill for the single handling rule.
+
+## Why Structured Logging
+
+Structured logs emit key-value pairs instead of freeform strings. Log management systems (Datadog, Grafana Loki, CloudWatch) can index, filter, and aggregate structured fields — something impossible with `log.Printf` output.
+
+```go
+// ✗ Bad — freeform string, impossible to filter by user_id
+log.Printf("ERROR: failed to create user %s: %v", userID, err)
+
+// ✓ Good — structured key-value pairs, machine-parseable
+slog.Error("user creation failed",
+    "user_id", userID,
+    "error", err,
+)
+// JSON output: {"time":"2025-01-15T10:30:00Z","level":"ERROR","msg":"user creation failed","user_id":"u-123","error":"connection refused"}
+```
+
+## Handler Setup
+
+```go
+// Production MUST use JSON — because plain-text multiline logs (eg. stack traces) would be split into separate records by log collectors
+logger := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
+    Level: slog.LevelInfo,
+}))
+
+// Development — human-readable text
+logger := slog.New(slog.NewTextHandler(os.Stderr, &slog.HandlerOptions{
+    Level: slog.LevelDebug,
+}))
+
+slog.SetDefault(logger)
+```
+
+## Log Levels
+
+```go
+slog.Debug("cache lookup", "key", cacheKey, "hit", false)
+slog.Info("order created", "order_id", orderID, "total", amount)
+slog.Warn("rate limit approaching", "current_usage", 0.92, "limit", 1000)
+slog.Error("payment failed", "order_id", orderID, "error", err)
+```
+
+**Rule of thumb**: if you're unsure between Warn and Error, ask "did the operation succeed?" If yes (even with degradation), use Warn. If no, use Error.
+
+## Cost of Logging
+
+Logging is not free. Each log line costs CPU (serialization), I/O (disk/network), and money (log ingestion/storage in your aggregation platform). The cost scales with volume, which is directly controlled by log level.
+
+- **Debug level in production** can generate millions of log lines per minute in a busy service, overwhelming your log pipeline and inflating costs by 10-100x
+- **Info level** is the typical production default — it provides enough visibility without excessive volume
+- Debug level SHOULD be disabled in production — use `slog.LevelInfo` in production and `slog.LevelDebug` only in development or when actively debugging a specific issue
+- For high-throughput services, consider [samber/slog-sampling](https://github.com/samber/slog-sampling) to sample verbose logs (e.g., emit 1 in 100 Debug logs) rather than dropping them entirely
+
+## Logging with Context
+
+MUST use the `*Context` variants to correlate logs with the current trace. When an OpenTelemetry bridge is configured, trace_id and span_id are automatically injected into log records.
+
+```go
+// ✗ Bad — no trace correlation
+slog.Error("query failed", "error", err)
+
+// ✓ Good — trace_id/span_id attached automatically when OTel bridge is active
+slog.ErrorContext(ctx, "query failed", "error", err)
+```
+
+## Adding Request-Scoped Attributes
+
+Use `slog.With()` to create a child logger that includes attributes on every log line. Middleware can inject request-scoped fields so all downstream logs carry the same context.
+
+```go
+func LoggingMiddleware(next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        logger := slog.With(
+            "request_id", r.Header.Get("X-Request-ID"),
+            "method", r.Method,
+            "path", r.URL.Path,
+        )
+        // Store enriched logger in context for downstream use
+        ctx := WithLogger(r.Context(), logger)
+        next.ServeHTTP(w, r.WithContext(ctx))
+    })
+}
+```
+
+## Log Sinks and the `slog` Ecosystem
+
+`slog` supports pluggable handlers. The Go community provides handlers for most log backends:
+
+**Standard library:**
+
+- `slog.JSONHandler` — JSON to stdout/stderr
+- `slog.TextHandler` — human-readable key=value
+
+**Log record handling:**
+
+- [samber/slog-multi](https://github.com/samber/slog-multi) — fan-out to multiple handlers, routing, failover
+- [samber/slog-sampling](https://github.com/samber/slog-sampling) — sample high-volume logs to reduce cost
+- [samber/slog-formatter](https://github.com/samber/slog-formatter) — format/transform log attributes
+
+**HTTP middleware:**
+
+- [samber/slog-http](https://github.com/samber/slog-http) — HTTP server middleware (net/http, chi, fiber, echo, gin)
+- [samber/slog-gin](https://github.com/samber/slog-gin) — Gin framework middleware
+- [samber/slog-echo](https://github.com/samber/slog-echo) — Echo framework middleware
+- [samber/slog-fiber](https://github.com/samber/slog-fiber) — Fiber framework middleware
+- [samber/slog-chi](https://github.com/samber/slog-chi) — Chi router middleware
+
+**Third-party log sinks** (see [go.dev/wiki/Resources-for-slog](https://go.dev/wiki/Resources-for-slog)):
+
+- [lmittmann/tint](https://github.com/lmittmann/tint) — colorized terminal output
+- [samber/slog-datadog](https://github.com/samber/slog-datadog) — send logs to Datadog
+- [samber/slog-sentry](https://github.com/samber/slog-sentry) — send errors to Sentry
+- [samber/slog-loki](https://github.com/samber/slog-loki) — send logs to Grafana Loki
+- [samber/slog-nats](https://github.com/samber/slog-nats) — send logs to NATS
+- [samber/slog-syslog](https://github.com/samber/slog-syslog) — send logs to syslog
+- [samber/slog-fluentd](https://github.com/samber/slog-fluentd) — send logs to Fluentd
+- [samber/slog-logrus](https://github.com/samber/slog-logrus) — bridge to Logrus
+- [samber/slog-zap](https://github.com/samber/slog-zap) — bridge to Zap
+- [samber/slog-zerolog](https://github.com/samber/slog-zerolog) — bridge to Zerolog
+- [samber/slog-slack](https://github.com/samber/slog-slack) — send critical logs to Slack
+
+## Migrating from zap / logrus / zerolog
+
+`log/slog` is the standard library logger since Go 1.21. If the project uses `zap`, `logrus`, or `zerolog`, migrate to `slog` — it has a stable API, broad ecosystem support, and eliminates an unnecessary dependency.
+
+**Step 1: Bridge** — route `slog` output through the existing logger so you can migrate call sites incrementally without changing log output:
+
+```go
+// Example: bridge slog → zap (same pattern for logrus/zerolog)
+import slogzap "github.com/samber/slog-zap/v2"
+
+zapLogger, _ := zap.NewProduction()
+slog.SetDefault(slog.New(
+    slogzap.Option{Level: slog.LevelInfo, Logger: zapLogger}.NewZapHandler(),
+))
+```
+
+Available bridges: [samber/slog-zap](https://github.com/samber/slog-zap), [samber/slog-logrus](https://github.com/samber/slog-logrus), [samber/slog-zerolog](https://github.com/samber/slog-zerolog)
+
+**Step 2: Replace call sites** — change all logger calls to `slog`:
+
+```go
+// zap → slog
+// Before: zap.L().Info("order created", zap.String("order_id", id))
+// After:
+slog.Info("order created", "order_id", id)
+
+// logrus → slog
+// Before: logrus.WithField("order_id", id).Info("order created")
+// After:
+slog.Info("order created", "order_id", id)
+
+// zerolog → slog
+// Before: log.Info().Str("order_id", id).Msg("order created")
+// After:
+slog.Info("order created", "order_id", id)
+```
+
+**Step 3: Remove the bridge** — once all call sites are migrated, replace the bridge handler with a native `slog` handler and remove the old logger dependency:
+
+```go
+slog.SetDefault(slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
+    Level: slog.LevelInfo,
+})))
+```
+
+## Common Logging Mistakes
+
+```go
+// ✗ Bad — errors MUST be either logged OR returned, NEVER both (single handling rule violation)
+if err != nil {
+    slog.Error("query failed", "error", err)
+    return fmt.Errorf("query: %w", err) // error gets logged twice up the chain
+}
+
+// ✓ Good — return with context, log at the top level
+if err != nil {
+    return fmt.Errorf("querying users: %w", err)
+}
+
+// ✗ Bad — NEVER log PII (emails, SSNs, passwords, tokens)
+slog.Info("user logged in", "email", user.Email, "ssn", user.SSN)
+
+// ✓ Good — log identifiers, not sensitive data
+slog.Info("user logged in", "user_id", user.ID)
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/metrics.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/metrics.md
new file mode 100644
index 00000000..0105ea2b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/metrics.md
@@ -0,0 +1,536 @@
+# Metrics with Prometheus
+
+→ See `samber/cc-skills-golang@golang-troubleshooting` skill for using metrics to diagnose production issues. → See `samber/cc-skills@promql-cli` skill for executing and testing PromQL queries via CLI.
+
+When using the Prometheus client library, refer to the library's official documentation for up-to-date API signatures and examples.
+
+## Metric Types
+
+| Type | What it measures | Example | When to use |
+| --- | --- | --- | --- |
+| **Counter** | Cumulative total (only goes up) | Total requests, total errors | Counting events |
+| **Gauge** | Current value (goes up and down) | In-flight requests, queue size, temperature | Current state |
+| **Histogram** | Distribution of values in configurable buckets | Request duration, response size | Latency, sizes — when you need percentiles |
+| **Summary** | Client-computed quantiles | Request duration (pre-computed P50, P99) | Rarely — prefer Histogram |
+
+## Histogram vs Summary
+
+This is one of the most common sources of confusion. Both measure distributions, but they work very differently.
+
+**Histogram** stores observations in configurable buckets (e.g., 5ms, 10ms, 25ms, 50ms, 100ms, ...). Percentiles are computed at query time by Prometheus using `histogram_quantile()`. Because the raw bucket counts are stored server-side, histograms can be **aggregated across multiple instances** — essential for services running multiple replicas.
+
+**Summary** computes quantiles (P50, P99, etc.) on the client side before sending them to Prometheus. This means the quantile values are pre-baked and **cannot be aggregated** — if you have 10 instances, you cannot combine their P99 values into a meaningful overall P99.
+
+**Recommendation**: Histogram SHOULD be preferred over Summary in almost all cases. Summary is only useful when you need exact quantiles for a single instance and don't care about cross-instance aggregation.
+
+## Tracking Percentiles (P50, P90, P99, P99.9)
+
+Define a Histogram with appropriate buckets, then query percentiles with `histogram_quantile()`:
+
+```go
+import "github.com/prometheus/client_golang/prometheus"
+import "github.com/prometheus/client_golang/prometheus/promauto"
+
+var httpRequestDuration = promauto.NewHistogramVec(
+    prometheus.HistogramOpts{
+        Namespace: "myapp",
+        Subsystem: "http",
+        Name:      "request_duration_seconds",
+        Help:      "HTTP request duration in seconds.",
+        Buckets:   prometheus.DefBuckets, // .005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10
+    },
+    []string{"method", "path", "status"},
+)
+
+// In your handler or middleware:
+func instrumentHandler(next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        start := time.Now()
+        sw := &statusWriter{ResponseWriter: w, status: 200}
+        next.ServeHTTP(sw, r)
+        httpRequestDuration.WithLabelValues(
+            r.Method,
+            r.URL.Path,
+            strconv.Itoa(sw.status),
+        ).Observe(time.Since(start).Seconds())
+    })
+}
+```
+
+**PromQL queries for percentiles:**
+
+```promql
+# P50 (median) over the last 5 minutes
+histogram_quantile(0.50, rate(myapp_http_request_duration_seconds_bucket[5m]))
+
+# P90
+histogram_quantile(0.90, rate(myapp_http_request_duration_seconds_bucket[5m]))
+
+# P99
+histogram_quantile(0.99, rate(myapp_http_request_duration_seconds_bucket[5m]))
+
+# P99.9
+histogram_quantile(0.999, rate(myapp_http_request_duration_seconds_bucket[5m]))
+
+# P99 broken down by path
+histogram_quantile(0.99, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le, path))
+```
+
+## Naming Conventions
+
+Metric names MUST follow the [Prometheus naming best practices](https://prometheus.io/docs/practices/naming/). The pattern is: `<namespace>_<subsystem>_<name>_<unit>`
+
+**Rules:**
+
+- Use a single-word application prefix (namespace) relevant to the domain
+- A metric must refer to a single unit and single quantity
+- Include the unit as a suffix, in **plural** form
+- MUST use **base units** — not derived units
+
+**Always use base units:**
+
+| Measurement   | Use            | Not                         |
+| ------------- | -------------- | --------------------------- |
+| Time          | `_seconds`     | `_milliseconds`, `_minutes` |
+| Data size     | `_bytes`       | `_kilobytes`, `_megabytes`  |
+| Temperature   | `_celsius`     | `_fahrenheit`               |
+| Ratio/percent | `_ratio` (0–1) | `_percent` (0–100)          |
+| Mass          | `_grams`       | `_kilograms`                |
+
+**Suffix conventions:**
+
+| Suffix | When to use | Example |
+| --- | --- | --- |
+| `_total` | Counters MUST use this suffix | `myapp_http_requests_total` |
+| `_seconds` | Duration measurements | `myapp_http_request_duration_seconds` |
+| `_bytes` | Data sizes | `myapp_response_size_bytes` |
+| `_info` | Pseudo-metrics exposing metadata | `myapp_build_info` |
+| `_created` | Creation timestamp of a counter | `myapp_http_requests_created` |
+
+```go
+// ✓ Good — namespace, subsystem, descriptive name, base unit suffix
+myapp_http_requests_total              // Counter
+myapp_http_request_duration_seconds    // Histogram — seconds, not milliseconds
+myapp_http_response_size_bytes         // Histogram — bytes, not kilobytes
+myapp_db_connections_active            // Gauge
+myapp_queue_messages_pending           // Gauge
+process_cpu_seconds_total              // Counter — total CPU time in seconds
+
+// ✗ Bad
+request_count             // no namespace, no unit suffix
+httpDuration              // camelCase, no unit
+request_duration_ms       // milliseconds instead of seconds
+myapp_request_size_kb     // kilobytes instead of bytes
+```
+
+**Label naming:** do not embed label names into the metric name. Use labels to differentiate characteristics:
+
+```go
+// ✗ Bad — operation embedded in metric name
+myapp_http_get_requests_total
+myapp_http_post_requests_total
+
+// ✓ Good — use a label
+myapp_http_requests_total{method="GET"}
+myapp_http_requests_total{method="POST"}
+```
+
+**Semantic consistency:** `sum()` or `avg()` over all label dimensions of a metric should be meaningful. If not, split into separate metrics.
+
+## Exposing Metrics
+
+```go
+import "github.com/prometheus/client_golang/prometheus/promhttp"
+
+mux.Handle("/metrics", promhttp.Handler())
+```
+
+## Document Metrics with PromQL Comments
+
+EVERY METRIC declaration SHOULD include the relevant PromQL queries and alert rules as comments directly above the variable. This makes metrics self-documenting — when a developer reads the code, they immediately see how the metric is used in dashboards and alerts, without hunting through Grafana or alert configurations.
+
+```go
+// ✗ Bad — metric exists but nobody knows how to query or alert on it
+var httpRequestsTotal = promauto.NewCounterVec(...)
+
+// ✓ Good — PromQL queries and alert rules are part of the code
+//
+// Dashboard: rate(myapp_http_requests_total[5m])
+// Dashboard: sum by (status) (rate(myapp_http_requests_total[5m]))
+// Alert:     sum(rate(myapp_http_requests_total{status=~"5.."}[5m])) / sum(rate(myapp_http_requests_total[5m])) > 0.01
+var httpRequestsTotal = promauto.NewCounterVec(...)
+```
+
+This convention has practical benefits: PromQL queries are reviewed in PRs alongside the metric, queries stay in sync with metric changes (label renames, bucket changes), and new team members can understand the metric's purpose at a glance.
+
+## Metric Examples and PromQL Queries
+
+Production-ready metrics covering all four types with comprehensive PromQL for dashboards and alerts.
+
+For infrastructure and dependency alerting (databases, caches, message brokers, reverse proxies, Kubernetes), [awesome-prometheus-alerts](https://samber.github.io/awesome-prometheus-alerts/) provides a curated collection of ~500 ready-to-use Prometheus alerting rules organized by technology. See [alerting.md](alerting.md) for integration details and Go runtime alerts.
+
+NEVER use `irate(...)` for alerts — use `rate(...)` instead.
+
+### Counters — tracking events
+
+```go
+// Dashboard: rate(myapp_http_requests_total[5m])
+// Dashboard: sum by (status) (rate(myapp_http_requests_total[5m]))
+// Dashboard: sum by (path) (rate(myapp_http_requests_total[5m]))
+// Dashboard: topk(5, sum by (path) (rate(myapp_http_requests_total[5m])))
+// Dashboard: increase(myapp_http_requests_total[1h])
+// SLI:      1 - (sum(rate(myapp_http_requests_total{status=~"5.."}[5m])) / sum(rate(myapp_http_requests_total[5m])))
+// Alert:    sum(rate(myapp_http_requests_total{status=~"5.."}[5m])) / sum(rate(myapp_http_requests_total[5m])) > 0.01
+// Alert:    sum(rate(myapp_http_requests_total{status=~"5.."}[1m])) / sum(rate(myapp_http_requests_total[1m])) > 0.05
+var httpRequestsTotal = promauto.NewCounterVec(
+    prometheus.CounterOpts{
+        Namespace: "myapp",
+        Subsystem: "http",
+        Name:      "requests_total",
+        Help:      "Total number of HTTP requests.",
+    },
+    []string{"method", "path", "status"},
+)
+
+// Dashboard: sum by (type) (rate(myapp_errors_total[5m]))
+// Dashboard: topk(3, sum by (type) (rate(myapp_errors_total[5m])))
+// Alert:    rate(myapp_errors_total{type="database"}[5m]) > 0.5
+var errorsTotal = promauto.NewCounterVec(
+    prometheus.CounterOpts{
+        Namespace: "myapp",
+        Name:      "errors_total",
+        Help:      "Total number of errors by type.",
+    },
+    []string{"type"}, // "database", "external_api", "validation"
+)
+
+// Dashboard: sum by (payment_method) (rate(myapp_orders_created_total[5m]))
+// Dashboard: increase(myapp_orders_created_total[24h])
+// Alert:    rate(myapp_orders_created_total[30m]) == 0
+var ordersCreated = promauto.NewCounterVec(
+    prometheus.CounterOpts{
+        Namespace: "myapp",
+        Subsystem: "orders",
+        Name:      "created_total",
+        Help:      "Total number of orders created.",
+    },
+    []string{"payment_method"},
+)
+```
+
+**Key PromQL patterns for counters:**
+
+```promql
+# Requests per second (smoothed over 5 minutes)
+rate(myapp_http_requests_total[5m])
+
+# Traffic by status code — see distribution of 2xx/4xx/5xx
+sum by (status) (rate(myapp_http_requests_total[5m]))
+
+# Top 5 busiest endpoints
+topk(5, sum by (path) (rate(myapp_http_requests_total[5m])))
+
+# Absolute request count in the last hour (useful for reports)
+increase(myapp_http_requests_total[1h])
+
+# Error ratio — fraction of requests returning 5xx (SLI)
+sum(rate(myapp_http_requests_total{status=~"5.."}[5m]))
+/
+sum(rate(myapp_http_requests_total[5m]))
+
+# 4xx error ratio — client errors (useful for spotting bad deployments)
+sum(rate(myapp_http_requests_total{status=~"4.."}[5m]))
+/
+sum(rate(myapp_http_requests_total[5m]))
+
+# Alert: error rate > 1% for 5 minutes (for: 5m)
+sum(rate(myapp_http_requests_total{status=~"5.."}[5m]))
+/
+sum(rate(myapp_http_requests_total[5m]))
+> 0.01
+
+# Alert: spike detection — error rate > 5% over 1 minute (for: 2m)
+sum(rate(myapp_http_requests_total{status=~"5.."}[1m]))
+/
+sum(rate(myapp_http_requests_total[1m]))
+> 0.05
+
+# Alert: zero orders for 30 minutes — business is broken (for: 30m)
+rate(myapp_orders_created_total[30m]) == 0
+```
+
+### Gauges — tracking current state
+
+```go
+// Dashboard: myapp_http_in_flight_requests
+// Alert:    myapp_http_in_flight_requests > 500
+var httpInFlightRequests = promauto.NewGauge(
+    prometheus.GaugeOpts{
+        Namespace: "myapp",
+        Subsystem: "http",
+        Name:      "in_flight_requests",
+        Help:      "Number of HTTP requests currently being processed.",
+    },
+)
+
+// Dashboard: myapp_db_connections_active
+// Dashboard: myapp_db_connections_active / myapp_db_connections_max
+// Alert:    myapp_db_connections_active{pool="write"} / myapp_db_connections_max{pool="write"} > 0.9
+// Alert:    predict_linear(myapp_db_connections_active[15m], 600) > myapp_db_connections_max
+var dbConnectionsActive = promauto.NewGaugeVec(
+    prometheus.GaugeOpts{
+        Namespace: "myapp",
+        Subsystem: "db",
+        Name:      "connections_active",
+        Help:      "Number of active database connections.",
+    },
+    []string{"pool"}, // "read", "write"
+)
+
+var dbConnectionsMax = promauto.NewGaugeVec(
+    prometheus.GaugeOpts{
+        Namespace: "myapp",
+        Subsystem: "db",
+        Name:      "connections_max",
+        Help:      "Maximum database connections in the pool.",
+    },
+    []string{"pool"},
+)
+
+// Dashboard: myapp_queue_messages_pending
+// Dashboard: deriv(myapp_queue_messages_pending[5m])
+// Alert:    myapp_queue_messages_pending{queue_name="orders"} > 1000
+// Alert:    deriv(myapp_queue_messages_pending[10m]) > 50
+// Alert:    predict_linear(myapp_queue_messages_pending[30m], 3600) > 10000
+var queueSize = promauto.NewGaugeVec(
+    prometheus.GaugeOpts{
+        Namespace: "myapp",
+        Subsystem: "queue",
+        Name:      "messages_pending",
+        Help:      "Number of messages waiting to be processed.",
+    },
+    []string{"queue_name"},
+)
+
+// Dashboard: myapp_workers_active / myapp_workers_max
+// Alert:    myapp_workers_active / myapp_workers_max > 0.8
+var workersActive = promauto.NewGauge(
+    prometheus.GaugeOpts{
+        Namespace: "myapp",
+        Name:      "workers_active",
+        Help:      "Number of worker goroutines currently processing jobs.",
+    },
+)
+
+// Usage in middleware:
+func instrumentMiddleware(next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        httpInFlightRequests.Inc()
+        defer httpInFlightRequests.Dec()
+        next.ServeHTTP(w, r)
+    })
+}
+```
+
+**Key PromQL patterns for gauges:**
+
+```promql
+# Current value — gauges are queried directly
+myapp_http_in_flight_requests
+
+# Saturation — what fraction of the pool is in use
+myapp_db_connections_active{pool="write"} / myapp_db_connections_max{pool="write"}
+
+# Rate of change — is the queue growing or shrinking? (items/second)
+deriv(myapp_queue_messages_pending[5m])
+
+# Prediction — will the connection pool be exhausted in 10 minutes?
+# predict_linear extrapolates the trend from the last 15 minutes
+predict_linear(myapp_db_connections_active[15m], 600) > myapp_db_connections_max
+
+# Prediction — will the queue exceed 10k items in 1 hour?
+predict_linear(myapp_queue_messages_pending[30m], 3600) > 10000
+
+# Alert: connection pool > 90% saturated (for: 5m)
+myapp_db_connections_active{pool="write"} / myapp_db_connections_max{pool="write"} > 0.9
+
+# Alert: queue depth growing faster than 50 items/sec (for: 10m)
+deriv(myapp_queue_messages_pending[10m]) > 50
+
+# Alert: worker pool saturated (for: 5m)
+myapp_workers_active / myapp_workers_max > 0.8
+```
+
+### Histograms — tracking distributions (recommended for latency)
+
+```go
+// Dashboard: histogram_quantile(0.50, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le))
+// Dashboard: histogram_quantile(0.90, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le))
+// Dashboard: histogram_quantile(0.99, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le))
+// Dashboard: histogram_quantile(0.99, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le, path))
+// SLI:      sum(rate(myapp_http_request_duration_seconds_bucket{le="0.3"}[5m])) / sum(rate(myapp_http_request_duration_seconds_count[5m]))
+// Alert:    histogram_quantile(0.99, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le)) > 2
+var httpRequestDuration = promauto.NewHistogramVec(
+    prometheus.HistogramOpts{
+        Namespace: "myapp",
+        Subsystem: "http",
+        Name:      "request_duration_seconds",
+        Help:      "HTTP request duration in seconds.",
+        Buckets:   []float64{.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10},
+    },
+    []string{"method", "path", "status"},
+)
+
+// Dashboard: histogram_quantile(0.95, sum(rate(myapp_external_call_duration_seconds_bucket[5m])) by (le, service))
+// Alert:    histogram_quantile(0.99, sum(rate(myapp_external_call_duration_seconds_bucket[5m])) by (le, service)) > 5
+var externalAPICallDuration = promauto.NewHistogramVec(
+    prometheus.HistogramOpts{
+        Namespace: "myapp",
+        Subsystem: "external",
+        Name:      "call_duration_seconds",
+        Help:      "Duration of external API calls in seconds.",
+        Buckets:   []float64{.01, .05, .1, .25, .5, 1, 2.5, 5, 10, 30},
+    },
+    []string{"service", "endpoint"},
+)
+
+// Dashboard: histogram_quantile(0.95, sum(rate(myapp_orders_amount_dollars_bucket[5m])) by (le))
+var orderAmount = promauto.NewHistogramVec(
+    prometheus.HistogramOpts{
+        Namespace: "myapp",
+        Subsystem: "orders",
+        Name:      "amount_dollars",
+        Help:      "Order amount in dollars.",
+        Buckets:   []float64{1, 5, 10, 25, 50, 100, 250, 500, 1000, 5000},
+    },
+    []string{"payment_method"},
+)
+```
+
+**Key PromQL patterns for histograms:**
+
+```promql
+# Percentile latencies — the core latency dashboard
+histogram_quantile(0.50, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le))  # P50
+histogram_quantile(0.90, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le))  # P90
+histogram_quantile(0.95, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le))  # P95
+histogram_quantile(0.99, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le))  # P99
+histogram_quantile(0.999, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le)) # P99.9
+
+# P99 latency broken down by endpoint — find the slowest paths
+histogram_quantile(0.99, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le, path))
+
+# Average latency (mean) — useful alongside percentiles
+sum(rate(myapp_http_request_duration_seconds_sum[5m]))
+/
+sum(rate(myapp_http_request_duration_seconds_count[5m]))
+
+# Apdex-like SLI — fraction of requests under 300ms (target threshold)
+sum(rate(myapp_http_request_duration_seconds_bucket{le="0.3"}[5m]))
+/
+sum(rate(myapp_http_request_duration_seconds_count[5m]))
+
+# Request throughput from histogram (requests/sec)
+sum(rate(myapp_http_request_duration_seconds_count[5m]))
+
+# External API P95 latency per service
+histogram_quantile(0.95, sum(rate(myapp_external_call_duration_seconds_bucket[5m])) by (le, service))
+
+# Alert: P99 latency > 2s (for: 5m)
+histogram_quantile(0.99, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le)) > 2
+
+# Alert: P95 latency > 500ms (for: 10m)
+histogram_quantile(0.95, sum(rate(myapp_http_request_duration_seconds_bucket[5m])) by (le)) > 0.5
+
+# Alert: external API P99 > 5s (for: 5m)
+histogram_quantile(0.99, sum(rate(myapp_external_call_duration_seconds_bucket[5m])) by (le, service)) > 5
+
+# Alert: less than 95% of requests under 300ms (SLO breach) (for: 10m)
+(
+  sum(rate(myapp_http_request_duration_seconds_bucket{le="0.3"}[5m]))
+  /
+  sum(rate(myapp_http_request_duration_seconds_count[5m]))
+) < 0.95
+```
+
+### Summary — client-side quantiles (use sparingly)
+
+Summaries compute quantiles on the client and cannot be aggregated across instances. Use them only for single-process diagnostics where exact quantiles matter. Prefer Histogram in all other cases.
+
+```go
+// Dashboard: myapp_jobs_processing_seconds{quantile="0.5"}
+// Dashboard: myapp_jobs_processing_seconds{quantile="0.99"}
+// Note: these quantiles CANNOT be aggregated across instances
+var jobProcessingDuration = promauto.NewSummary(
+    prometheus.SummaryOpts{
+        Namespace:  "myapp",
+        Subsystem:  "jobs",
+        Name:       "processing_seconds",
+        Help:       "Job processing duration in seconds.",
+        Objectives: map[float64]float64{0.5: 0.05, 0.9: 0.01, 0.99: 0.001},
+        MaxAge:     10 * time.Minute,
+    },
+)
+```
+
+## Multi-Window Burn-Rate SLO Alerting
+
+For critical services, simple threshold alerts ("error rate > 1%") fire too late for fast incidents and too early for slow ones. Multi-window burn-rate alerting scales alert urgency to how fast you're consuming your error budget.
+
+For a **99.9% availability SLO** (0.1% error budget over 30 days):
+
+| Window | Burn rate | Error rate | Severity | Meaning |
+| --- | --- | --- | --- | --- |
+| 5m + 1h | 14.4x | > 1.44% | Critical (page) | Budget exhausted in ~2 days |
+| 30m + 6h | 6x | > 0.6% | Critical (page) | Budget exhausted in ~5 days |
+| 2h + 24h | 1x | > 0.1% | Warning (ticket) | On track to exhaust budget |
+
+```promql
+# Fast burn — page immediately (for: 2m)
+# Both short and long windows must fire to avoid noise from brief spikes
+(
+  (1 - sum(rate(myapp_http_requests_total{status=~"2.."}[5m])) / sum(rate(myapp_http_requests_total[5m]))) > 0.0144
+  and
+  (1 - sum(rate(myapp_http_requests_total{status=~"2.."}[1h])) / sum(rate(myapp_http_requests_total[1h]))) > 0.0144
+)
+
+# Medium burn — page (for: 15m)
+(
+  (1 - sum(rate(myapp_http_requests_total{status=~"2.."}[30m])) / sum(rate(myapp_http_requests_total[30m]))) > 0.006
+  and
+  (1 - sum(rate(myapp_http_requests_total{status=~"2.."}[6h])) / sum(rate(myapp_http_requests_total[6h]))) > 0.006
+)
+
+# Slow burn — ticket (for: 1h)
+(
+  (1 - sum(rate(myapp_http_requests_total{status=~"2.."}[2h])) / sum(rate(myapp_http_requests_total[2h]))) > 0.001
+  and
+  (1 - sum(rate(myapp_http_requests_total{status=~"2.."}[24h])) / sum(rate(myapp_http_requests_total[24h]))) > 0.001
+)
+```
+
+The short window catches the incident fast; the long window confirms it's sustained. Together they eliminate false positives from transient blips.
+
+## High-Cardinality Labels
+
+NEVER use high-cardinality labels (user IDs, full URLs, request IDs). Every unique combination of label values creates a separate time series in Prometheus. Unbounded labels cause memory explosion on the Prometheus server, slow queries, and can crash the monitoring stack.
+
+```go
+// ✗ Bad — unbounded cardinality (millions of unique values)
+httpRequestsTotal.WithLabelValues(r.URL.Path)    // /users/alice, /users/bob, /users/charlie...
+httpRequestsTotal.WithLabelValues(userID)          // one series per user
+httpRequestsTotal.WithLabelValues(r.Header.Get("X-Request-ID")) // one series per request!
+
+// ✓ Good — bounded, normalized labels
+httpRequestsTotal.WithLabelValues(routePattern)   // /users/:id (the route template, not the actual path)
+httpRequestsTotal.WithLabelValues(r.Method)        // GET, POST, PUT, DELETE (5 values)
+httpRequestsTotal.WithLabelValues(statusBucket)    // "2xx", "3xx", "4xx", "5xx" (4 values)
+```
+
+**How to limit cardinality:**
+
+- Use route templates (`/users/:id`) instead of actual paths (`/users/alice`)
+- Bucket status codes (`2xx`, `4xx`, `5xx`) instead of exact codes (200, 201, 204, 400, 401, ...)
+- Never use user IDs, request IDs, session IDs, or email addresses as labels
+- Use attributes/tags in traces instead — traces handle high cardinality naturally
+- **Rule of thumb**: if a label can have more than ~100 unique values, it's too many
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/profiling.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/profiling.md
new file mode 100644
index 00000000..0a78c41f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/profiling.md
@@ -0,0 +1,72 @@
+# Profiling and Continuous Profiling
+
+→ See `samber/cc-skills-golang@golang-troubleshooting` skill (pprof.md) for on-demand debugging.
+
+## What Profiling Is
+
+Profiling analyzes the runtime behavior of your program — where CPU time is spent, how memory is allocated, which goroutines are blocked, and where lock contention occurs. While metrics tell you "the service is slow," profiling tells you "this specific function on line 42 is the bottleneck."
+
+## On-Demand Profiling with `pprof`
+
+pprof endpoints MUST be protected with basic auth — NEVER expose them publicly. They leak sensitive runtime information and can be abused for DoS.
+
+→ See `samber/cc-skills-golang@golang-troubleshooting` pprof.md for the full pprof CLI reference (profile types, capturing, analyzing, commands).
+
+## Continuous Profiling with Pyroscope
+
+On-demand profiling requires you to be there when the problem happens. Continuous profiling runs always-on in the background with low overhead (~2-5% CPU), so you can look at profiles after the fact. Toggle it with an environment variable.
+
+```go
+import "github.com/grafana/pyroscope-go"
+
+func setupContinuousProfiling() {
+    if os.Getenv("PROFILING_ENABLED") != "true" {
+        return
+    }
+
+    _, err := pyroscope.Start(pyroscope.Config{
+        ApplicationName: "my-service",
+        ServerAddress:   os.Getenv("PYROSCOPE_URL"), // e.g., http://user:pass@pyroscope:4040
+        ProfileTypes: []pyroscope.ProfileType{
+            pyroscope.ProfileCPU,
+            pyroscope.ProfileAllocObjects,
+            pyroscope.ProfileAllocSpace,
+            pyroscope.ProfileInuseObjects,
+            pyroscope.ProfileInuseSpace,
+            pyroscope.ProfileGoroutines,
+            pyroscope.ProfileMutexCount,
+            pyroscope.ProfileMutexDuration,
+            pyroscope.ProfileBlockCount,
+            pyroscope.ProfileBlockDuration,
+        },
+    })
+    if err != nil {
+        slog.Error("failed to start pyroscope", "error", err)
+    } else {
+        slog.Info("continuous profiling enabled", "server", os.Getenv("PYROSCOPE_URL"))
+    }
+}
+```
+
+## Cost of Continuous Profiling
+
+Continuous profiling adds overhead to every running instance — CPU for collecting stack samples, memory for buffering, and network for transmitting profiles to the backend. While typically low (~2-5% CPU), this cost is **per-instance and always-on**.
+
+**Cost factors:**
+
+- **CPU overhead** — profiling itself consumes CPU cycles. In CPU-bound services, even 2-5% overhead matters.
+- **Network/storage** — profile data is continuously shipped to Pyroscope/your backend. High-replica services multiply this.
+- **All profile types enabled** — each additional profile type (mutex, block, goroutine) adds incremental overhead.
+
+**Mitigation:**
+
+- Toggle via environment variable (`PROFILING_ENABLED`) — enable only when needed or on a subset of instances
+- Start with CPU + heap profiles only; add mutex/block/goroutine profiles when investigating specific issues
+- In large deployments, enable continuous profiling on a fraction of replicas (e.g., 1 in 10) rather than all of them
+
+## When to Profile
+
+1. Metrics show high CPU/memory usage → look at CPU/heap profiles
+2. P99 latency spikes → CPU profile + mutex profile to find contention
+3. Goroutine count growing → goroutine profile to find leaks
+4. Before and after an optimization → compare profiles to verify improvement
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/rum.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/rum.md
new file mode 100644
index 00000000..55f89b99
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/rum.md
@@ -0,0 +1,258 @@
+# Real User Monitoring (RUM) and Product Observability
+
+## What RUM Is
+
+Backend observability (logs, metrics, traces, profiles) tells you how your **system** behaves. RUM tells you how your **users** experience it. While frontend SDKs capture browser-side signals, the Go backend plays a critical role: tracking server-side business events, feeding Customer Data Platforms, and correlating user sessions with backend traces.
+
+## RUM Capabilities
+
+| Capability | What it reveals | Example tools |
+| --- | --- | --- |
+| **Product Analytics** | What users do — page views, clicks, feature adoption, retention | PostHog, Amplitude, Mixpanel |
+| **Funnel Analysis** | Where users drop off in multi-step flows (signup, checkout, onboarding) | PostHog, Amplitude, Mixpanel |
+| **CDP** | Unified user profile from all data sources — events, properties, segments | Segment, RudderStack |
+
+## Identity Key: Use `user_id`, Never Email
+
+The distinct_id (identity key) used across all RUM tracking MUST be your internal, immutable `user_id`. NEVER use email addresses.
+
+```go
+// ✗ Bad — email is mutable, PII, and breaks analytics when users change it
+posthogClient.Enqueue(posthog.Capture{
+    DistinctId: user.Email, // "alice@example.com" → user changes email → events split into two users
+    Event:      "order_completed",
+})
+
+// ✓ Good — user_id is immutable, stable, and not PII
+posthogClient.Enqueue(posthog.Capture{
+    DistinctId: user.ID, // "usr_a1b2c3" — never changes, always the same user
+    Event:      "order_completed",
+})
+```
+
+**Why email is a bad identity key:**
+
+- **Mutable** — users change their email. Events before and after the change appear as two different users, breaking funnels, retention analysis, and cohort tracking.
+- **PII** — using email as the identity key means every event, session recording, and analytics query contains personally identifiable information. This complicates GDPR/CCPA compliance — you can't anonymize analytics without losing user identity.
+- **Non-unique across systems** — the same email might belong to different accounts in different services or environments.
+- **Leaks into third-party systems** — the distinct_id is sent to your analytics platform (PostHog, Segment, etc.). If it's an email, you've shared PII with every vendor in your analytics pipeline.
+
+Use `user_id` as the identity key everywhere: PostHog `DistinctId`, Segment `UserId`, Amplitude `user_id`. Store email as a user property if needed for display, never as the primary key.
+
+## Backend Role in RUM
+
+The Go backend tracks server-side events, correlates sessions with traces, and feeds data into CDPs.
+
+### 1. Server-Side Event Tracking
+
+When critical business events happen server-side (payment completed, subscription upgraded, email sent), track them from Go so they appear in the same analytics pipeline as frontend events.
+
+```go
+import "github.com/posthog/posthog-go"
+
+var posthogClient posthog.Client
+
+func initPostHog() {
+    var err error
+    posthogClient, err = posthog.NewWithConfig(
+        os.Getenv("POSTHOG_API_KEY"),
+        posthog.Config{Endpoint: os.Getenv("POSTHOG_HOST")},
+    )
+    if err != nil {
+        slog.Error("failed to init PostHog", "error", err)
+    }
+}
+
+func (s *OrderService) Complete(ctx context.Context, order Order) error {
+    // ... business logic ...
+
+    // Track server-side event — appears alongside frontend events in PostHog
+    posthogClient.Enqueue(posthog.Capture{
+        DistinctId: order.UserID, // immutable user_id, not email
+        Event:      "order_completed",
+        Properties: posthog.NewProperties().
+            Set("order_id", order.ID).
+            Set("amount", order.Total).
+            Set("payment_method", order.PaymentMethod).
+            Set("item_count", len(order.Items)),
+    })
+
+    return nil
+}
+```
+
+### 2. Connecting Frontend Sessions to Backend Traces
+
+Pass the frontend session ID or distinct ID through HTTP headers so backend traces can be correlated with RUM sessions. When a user reports "the page was slow," you can find their session recording AND the backend trace for the same request.
+
+```go
+func TracingMiddleware(next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        ctx := r.Context()
+        span := trace.SpanFromContext(ctx)
+
+        // Attach RUM session ID to the backend span
+        if sessionID := r.Header.Get("X-Session-ID"); sessionID != "" {
+            span.SetAttributes(attribute.String("rum.session_id", sessionID))
+        }
+
+        // Attach analytics distinct ID for user correlation
+        if distinctID := r.Header.Get("X-Distinct-ID"); distinctID != "" {
+            span.SetAttributes(attribute.String("rum.distinct_id", distinctID))
+        }
+
+        next.ServeHTTP(w, r.WithContext(ctx))
+    })
+}
+```
+
+### 3. CDP Event Ingestion
+
+If you use a Customer Data Platform (Segment, RudderStack), the Go backend sends events through the CDP's server-side SDK. The CDP unifies these with frontend events into a single user profile.
+
+```go
+import "github.com/segmentio/analytics-go/v3"
+
+var segmentClient analytics.Client
+
+func initSegment() {
+    segmentClient = analytics.New(os.Getenv("SEGMENT_WRITE_KEY"))
+}
+
+func (s *UserService) Upgrade(ctx context.Context, userID string, plan string) error {
+    // ... business logic ...
+
+    // Track through CDP — unified with frontend events
+    segmentClient.Enqueue(analytics.Track{
+        UserId: userID, // immutable user_id, not email
+        Event:  "plan_upgraded",
+        Properties: analytics.NewProperties().
+            Set("plan", plan).
+            Set("source", "api"),
+    })
+
+    // Update user profile in CDP
+    segmentClient.Enqueue(analytics.Identify{
+        UserId: userID,
+        Traits: analytics.NewTraits().
+            Set("plan", plan).
+            Set("upgraded_at", time.Now()),
+    })
+
+    return nil
+}
+```
+
+## GDPR and CCPA Compliance
+
+RUM collects user behavior data — clicks, page views, session recordings. This triggers privacy regulation requirements. Compliance is not optional; violations carry heavy fines (GDPR: up to 4% of global revenue, CCPA: $7,500 per intentional violation).
+
+### Consent Management
+
+GDPR/CCPA consent SHOULD be obtained before loading RUM SDKs or sending tracking events. This applies to both frontend scripts and server-side event tracking.
+
+```go
+// Server-side: check consent before tracking
+func (s *OrderService) Complete(ctx context.Context, order Order) error {
+    // ... business logic ...
+
+    // Only track if user has consented to analytics
+    consent := auth.ConsentFromContext(ctx)
+    if consent.Analytics {
+        posthogClient.Enqueue(posthog.Capture{
+            DistinctId: order.UserID,
+            Event:      "order_completed",
+            Properties: posthog.NewProperties().
+                Set("order_id", order.ID).
+                Set("amount", order.Total),
+        })
+    }
+
+    return nil
+}
+```
+
+### Data Subject Rights Endpoints
+
+GDPR and CCPA require you to let users access, export, and delete their data. Implement API endpoints that propagate these requests to all systems that hold user data — your database, your analytics platform, your CDP.
+
+```go
+// DELETE /api/users/:id/data — GDPR Article 17 "Right to Erasure"
+func (h *PrivacyHandler) HandleDataDeletion(w http.ResponseWriter, r *http.Request) {
+    ctx := r.Context()
+    userID := chi.URLParam(r, "id")
+
+    // 1. Delete from your database
+    if err := h.userRepo.DeleteAllData(ctx, userID); err != nil {
+        slog.ErrorContext(ctx, "failed to delete user data", "user_id", userID, "error", err)
+        http.Error(w, "internal error", http.StatusInternalServerError)
+        return
+    }
+
+    // 2. Delete from analytics platform
+    if err := h.posthog.DeleteUser(ctx, userID); err != nil {
+        slog.ErrorContext(ctx, "failed to delete analytics data", "user_id", userID, "error", err)
+    }
+
+    // 3. Delete from CDP
+    if err := h.segment.DeleteUser(ctx, userID); err != nil {
+        slog.ErrorContext(ctx, "failed to delete CDP data", "user_id", userID, "error", err)
+    }
+
+    slog.InfoContext(ctx, "user data deletion completed", "user_id", userID)
+    w.WriteHeader(http.StatusNoContent)
+}
+
+// GET /api/users/:id/data — GDPR Article 15 "Right of Access"
+func (h *PrivacyHandler) HandleDataExport(w http.ResponseWriter, r *http.Request) {
+    ctx := r.Context()
+    userID := chi.URLParam(r, "id")
+
+    export, err := h.userRepo.ExportAllData(ctx, userID)
+    if err != nil {
+        slog.ErrorContext(ctx, "failed to export user data", "user_id", userID, "error", err)
+        http.Error(w, "internal error", http.StatusInternalServerError)
+        return
+    }
+
+    w.Header().Set("Content-Type", "application/json")
+    json.NewEncoder(w).Encode(export)
+}
+```
+
+### Privacy Checklist
+
+- [ ] **Consent before tracking** — no analytics scripts load and no server-side events fire until the user consents
+- [ ] **Consent + cookie banner** — clear opt-in (not pre-checked boxes), separate consent for analytics vs marketing vs functional (frontend responsibility, but backend must respect the consent flag)
+- [ ] **Data minimization** — only collect what you need, never track PII in analytics events
+- [ ] **Data retention policy** — auto-delete old analytics data (e.g., 2 years for aggregated analytics)
+- [ ] **Data subject rights** — endpoints for data export (right of access) and deletion (right to erasure)
+- [ ] **Data processing agreements** — signed DPAs with all third-party analytics/CDP vendors
+- [ ] **Privacy policy** — lists all RUM tools, what data they collect, and how long it's retained
+- [ ] **Identity key is not PII** — use `user_id`, not email, as the distinct_id across all platforms
+- [ ] **Self-hosted option** — consider self-hosting (PostHog, Matomo) to keep data in your infrastructure and simplify compliance
+
+## Self-Hosted vs SaaS
+
+| Factor | Self-hosted (PostHog, Matomo) | SaaS (Amplitude, Mixpanel) |
+| --- | --- | --- |
+| **Data residency** | Full control — data stays in your infra | Data on vendor's servers |
+| **GDPR compliance** | Simpler — no cross-border data transfer | Requires DPA, SCCs, or adequacy decision |
+| **Cost** | Infrastructure cost, scales with volume | Per-event or per-seat pricing |
+| **Maintenance** | You manage upgrades, scaling, backups | Vendor handles everything |
+| **Features** | Catching up but improving fast | Often more polished and feature-rich |
+
+For EU-focused products or strict data residency requirements, self-hosting PostHog is the pragmatic choice — it eliminates most GDPR concerns around cross-border data transfer.
+
+## Cost of RUM
+
+RUM costs scale with **event volume**:
+
+- **Event-based pricing** — every page view, click, and custom event counts. A busy SaaS app can generate millions of events/month per user segment.
+- **CDP costs** — CDPs charge per tracked user and per event. Segment at scale can cost more than your entire backend infrastructure.
+
+**Mitigation:**
+
+- Use server-side event filtering to drop low-value events before they reach the analytics platform
+- Self-host where possible to convert per-event pricing into fixed infrastructure cost
+- Set data retention limits on aggregated analytics
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/tracing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/tracing.md
new file mode 100644
index 00000000..dfdc69b4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-observability/references/tracing.md
@@ -0,0 +1,198 @@
+# Distributed Tracing with OpenTelemetry
+
+→ See `samber/cc-skills-golang@golang-context` skill for propagating context across service boundaries. → See `samber/cc-skills-golang@golang-samber-oops` skill for structured errors with stack traces in spans.
+
+When using the OpenTelemetry Go SDK, refer to the library's official documentation for up-to-date API signatures and examples.
+
+## Why Tracing
+
+When a request crosses multiple services, logs from each service are isolated. Tracing connects them: a single trace shows the full request path with timing for every operation. This is how you answer "why was this request slow?" in a microservices architecture.
+
+## OTel SDK Setup
+
+Set up the TracerProvider early in your application. On new projects, do this first — then add spans everywhere incrementally.
+
+```go
+import (
+    "go.opentelemetry.io/otel"
+    "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
+    "go.opentelemetry.io/otel/sdk/resource"
+    sdktrace "go.opentelemetry.io/otel/sdk/trace"
+    semconv "go.opentelemetry.io/otel/semconv/v1.26.0"
+)
+
+func initTracer(ctx context.Context) (func(), error) {
+    exporter, err := otlptracegrpc.New(ctx)
+    if err != nil {
+        return nil, fmt.Errorf("creating OTLP exporter: %w", err)
+    }
+
+    res, err := resource.New(ctx,
+        resource.WithAttributes(
+            semconv.ServiceNameKey.String("my-service"),
+            semconv.ServiceVersionKey.String("1.0.0"),
+        ),
+    )
+    if err != nil {
+        return nil, fmt.Errorf("creating resource: %w", err)
+    }
+
+    tp := sdktrace.NewTracerProvider(
+        sdktrace.WithBatcher(exporter),
+        sdktrace.WithResource(res),
+    )
+    otel.SetTracerProvider(tp)
+
+    shutdown := func() {
+        _ = tp.Shutdown(context.Background())
+    }
+    return shutdown, nil
+}
+```
+
+## Creating Spans
+
+Every meaningful operation should have a span. Think of spans as the building blocks of a trace — they show where time was spent.
+
+```go
+import "go.opentelemetry.io/otel"
+
+var tracer = otel.Tracer("myapp/order-service")
+
+func (s *OrderService) Create(ctx context.Context, req CreateOrderRequest) (*Order, error) {
+    ctx, span := tracer.Start(ctx, "OrderService.Create")
+    defer span.End()
+
+    // Add attributes that help with debugging
+    span.SetAttributes(
+        attribute.String("order.payment_method", req.PaymentMethod),
+        attribute.Float64("order.amount", req.Amount),
+    )
+
+    order, err := s.repo.Insert(ctx, req.ToOrder())
+    if err != nil {
+        span.RecordError(err)
+        span.SetStatus(codes.Error, err.Error())
+        return nil, fmt.Errorf("inserting order: %w", err)
+    }
+
+    return order, nil
+}
+
+func (r *OrderRepo) Insert(ctx context.Context, order Order) (*Order, error) {
+    ctx, span := tracer.Start(ctx, "OrderRepo.Insert")
+    defer span.End()
+
+    _, err := r.db.ExecContext(ctx, "INSERT INTO orders ...", order.ID)
+    if err != nil {
+        span.RecordError(err)
+        span.SetStatus(codes.Error, err.Error())
+        return nil, fmt.Errorf("exec insert: %w", err)
+    }
+    return &order, nil
+}
+```
+
+**Where to add spans** — spans MUST be created for:
+
+- Every service method (business logic layer)
+- Every database query
+- Every external API call
+- Every message queue publish/consume
+- Any operation that takes measurable time or could fail
+
+## HTTP Middleware with `otelhttp`
+
+Automatically creates spans for incoming and outgoing HTTP requests:
+
+```go
+import "go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp"
+
+// Incoming requests — wrap your handler
+mux.Handle("/orders", otelhttp.NewHandler(orderHandler, "CreateOrder"))
+
+// Outgoing requests — HTTP clients MUST use otelhttp for automatic span propagation
+client := &http.Client{
+    Transport: otelhttp.NewTransport(http.DefaultTransport),
+}
+```
+
+## Span Status and Recording Errors
+
+```go
+import (
+    "go.opentelemetry.io/otel/codes"
+)
+
+// On success — no need to set status (Unset is fine)
+
+// On error — MUST call both RecordError() and SetStatus(Error)
+if err != nil {
+    span.RecordError(err)
+    span.SetStatus(codes.Error, "operation failed")
+    return err
+}
+```
+
+## Structured Errors with `samber/oops`
+
+Standard Go errors lose critical debugging information: there's no stack trace, no structured context, and no way to attach request-scoped metadata. When an error surfaces in a trace, you see `"connection refused"` but not where it originated or which user/tenant was affected.
+
+[`samber/oops`](https://github.com/samber/oops) is a drop-in error library that fills these gaps. Every `oops` error carries a stack trace, structured attributes, and integrates naturally with both OpenTelemetry spans and `slog`:
+
+```go
+import "github.com/samber/oops"
+
+func (s *OrderService) Create(ctx context.Context, req CreateOrderRequest) (*Order, error) {
+    ctx, span := tracer.Start(ctx, "OrderService.Create")
+    defer span.End()
+
+    order, err := s.repo.Insert(ctx, req.ToOrder())
+    if err != nil {
+        // oops wraps the error with stack trace, structured context, and error code
+        return nil, oops.
+            In("order-service").
+            Code("order_insert_failed").
+            With("order_id", req.OrderID).
+            With("user_id", req.UserID).
+            Wrapf(err, "inserting order")
+    }
+
+    return order, nil
+}
+```
+
+When this error is logged or recorded on a span, you get the full stack trace, the domain (`order-service`), an error code (`order_insert_failed`), and structured attributes (`order_id`, `user_id`) — all machine-parseable and searchable in your observability platform.
+
+`oops` errors work with `span.RecordError()`, `errors.Is`/`errors.As`, and `slog` — see the `samber/cc-skills-golang@golang-error-handling` and `samber/cc-skills-golang@golang-samber-oops` skills for full usage patterns.
+
+## Trace Sampling
+
+In high-throughput services, tracing every request is expensive. Use sampling to control the volume:
+
+```go
+tp := sdktrace.NewTracerProvider(
+    // Sample 10% of traces in production
+    sdktrace.WithSampler(sdktrace.TraceIDRatioBased(0.1)),
+    sdktrace.WithBatcher(exporter),
+    sdktrace.WithResource(res),
+)
+```
+
+For more nuanced control, use `sdktrace.ParentBased()` to respect the parent's sampling decision — this keeps traces complete across service boundaries.
+
+## Cost of Tracing
+
+Tracing can be one of the most expensive observability signals. Every span generates data that must be serialized, transmitted, stored, and indexed. In a microservices architecture, a single user request can produce dozens or hundreds of spans across services.
+
+**Cost factors:**
+
+- **Span volume** — a service handling 10k req/s with 5 spans per request generates 50k spans/s. At 100% sampling, this is enormous.
+- **Span attributes** — each attribute adds to the payload size. Large attributes (request/response bodies) multiply cost.
+- **Storage and indexing** — tracing backends (Jaeger, Tempo, Datadog) charge by volume. Unsampled traces can easily become the largest line item in your observability bill.
+
+**Mitigation:**
+
+- Use sampling (see above) — start with 10% (`TraceIDRatioBased(0.1)`) and adjust based on traffic volume and budget
+- For high-throughput services, consider head-based sampling (decide at trace start) or tail-based sampling (decide after the trace completes, keeping only interesting traces like errors or slow requests)
+- Avoid attaching large payloads as span attributes — log them instead and correlate via trace_id
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/SKILL.md
new file mode 100644
index 00000000..59d708ec
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/SKILL.md
@@ -0,0 +1,115 @@
+---
+name: golang-performance
+description: "Golang performance optimization patterns and methodology - if X bottleneck, then apply Y. Covers allocation reduction, CPU efficiency, memory layout, GC tuning, pooling, caching, and hot-path optimization. Use when profiling or benchmarks have identified a bottleneck and you need the right optimization pattern to fix it. Also use when performing performance code review to suggest improvements or benchmarks that could help identify quick performance gains. Not for measurement methodology (→ See `samber/cc-skills-golang@golang-benchmark` skill) or debugging workflow (→ See `samber/cc-skills-golang@golang-troubleshooting` skill)."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.2"
+  openclaw:
+    emoji: "🏎"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - benchstat
+    install:
+      - kind: go
+        package: golang.org/x/perf/cmd/benchstat@latest
+        bins: [benchstat]
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch Bash(benchstat:*) Bash(fieldalignment:*) Bash(staticcheck:*) Bash(curl:*) Bash(fgprof:*) Bash(perf:*) WebSearch AskUserQuestion
+---
+
+**Persona:** You are a Go performance engineer. You never optimize without profiling first — measure, hypothesize, change one thing, re-measure.
+
+**Thinking mode:** Use `ultrathink` for performance optimization. Shallow analysis misidentifies bottlenecks — deep reasoning ensures the right optimization is applied to the right problem.
+
+**Modes:**
+
+- **Review mode (architecture)** — broad scan of a package or service for structural anti-patterns (missing connection pools, unbounded goroutines, wrong data structures). Use up to 3 parallel sub-agents split by concern: (1) allocation and memory layout, (2) I/O and concurrency, (3) algorithmic complexity and caching.
+- **Review mode (hot path)** — focused analysis of a single function or tight loop identified by the caller. Work sequentially; one sub-agent is sufficient.
+- **Optimize mode** — a bottleneck has been identified by profiling. Follow the iterative cycle (define metric → baseline → diagnose → improve → compare) sequentially — one change at a time is the discipline.
+
+**Dependencies:**
+
+- benchstat: `go install golang.org/x/perf/cmd/benchstat@latest`
+
+# Go Performance Optimization
+
+## Core Philosophy
+
+1. **Profile before optimizing** — intuition about bottlenecks is wrong ~80% of the time. Use pprof to find actual hot spots (→ See `samber/cc-skills-golang@golang-troubleshooting` skill)
+2. **Allocation reduction yields the biggest ROI** — Go's GC is fast but not free. Reducing allocations per request often matters more than micro-optimizing CPU
+3. **Document optimizations** — add code comments explaining why a pattern is faster, with benchmark numbers when available. Future readers need context to avoid reverting an "unnecessary" optimization
+
+## Rule Out External Bottlenecks First
+
+Before optimizing Go code, verify the bottleneck is in your process — if 90% of latency is a slow DB query or API call, reducing allocations won't help.
+
+**Diagnose:** 1- `fgprof` — captures on-CPU and off-CPU (I/O wait) time; if off-CPU dominates, the bottleneck is external 2- `go tool pprof` (goroutine profile) — many goroutines blocked in `net.(*conn).Read` or `database/sql` = external wait 3- Distributed tracing (OpenTelemetry) — span breakdown shows which upstream is slow
+
+**When external:** optimize that component instead — query tuning, caching, connection pools, circuit breakers (→ See `samber/cc-skills-golang@golang-database` skill, [Caching Patterns](references/caching.md)).
+
+## Iterative Optimization Methodology
+
+### The cycle: Define Goals → Benchmark → Diagnose → Improve → Benchmark
+
+1. **Define your metric** — latency, throughput, memory, or CPU? Without a target, optimizations are random
+2. **Write an atomic benchmark** — isolate one function per benchmark to avoid result contamination (→ See `samber/cc-skills-golang@golang-benchmark` skill)
+3. **Measure baseline** — `go test -bench=BenchmarkMyFunc -benchmem -count=6 ./pkg/... | tee /tmp/report-1.txt`
+4. **Diagnose** — use the **Diagnose** lines in each deep-dive section to pick the right tool
+5. **Improve** — apply ONE optimization at a time with an explanatory comment
+6. **Compare** — `benchstat /tmp/report-1.txt /tmp/report-2.txt` to confirm statistical significance
+7. **Commit** — paste the benchstat output in the commit body so reviewers and future readers see the exact improvement; follow the `perf(scope): summary` commit type
+8. **Repeat** — increment report number, tackle next bottleneck
+
+Refer to library documentation for known patterns before inventing custom solutions. Keep all `/tmp/report-*.txt` files as an audit trail.
+
+## Decision Tree: Where Is Time Spent?
+
+| Bottleneck | Signal (from pprof) | Action |
+| --- | --- | --- |
+| Too many allocations | `alloc_objects` high in heap profile | [Memory optimization](references/memory.md) |
+| CPU-bound hot loop | function dominates CPU profile | [CPU optimization](references/cpu.md) |
+| GC pauses / OOM | high GC%, container limits | [Runtime tuning](references/runtime.md) |
+| Network / I/O latency | goroutines blocked on I/O | [I/O & networking](references/io-networking.md) |
+| Repeated expensive work | same computation/fetch multiple times | [Caching patterns](references/caching.md) |
+| Wrong algorithm | O(n²) where O(n) exists | [Algorithmic complexity](references/caching.md#algorithmic-complexity) |
+| Lock contention | mutex/block profile hot | → See `samber/cc-skills-golang@golang-concurrency` skill |
+| Slow queries | DB time dominates traces | → See `samber/cc-skills-golang@golang-database` skill |
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Optimizing without profiling | Profile with pprof first — intuition is wrong ~80% of the time |
+| Default `http.Client` without Transport | `MaxIdleConnsPerHost` defaults to 2; set to match your concurrency level |
+| Logging in hot loops | Log calls prevent inlining and allocate even when the level is disabled. Use `slog.LogAttrs` |
+| `panic`/`recover` as control flow | panic allocates a stack trace and unwinds the stack; use error returns |
+| `unsafe` without benchmark proof | Only justified when profiling shows >10% improvement in a verified hot path |
+| No GC tuning in containers | Set `GOMEMLIMIT` to 80-90% of container memory to prevent OOM kills |
+| `reflect.DeepEqual` in production | 50-200x slower than typed comparison; use `slices.Equal`, `maps.Equal`, `bytes.Equal` |
+
+## Deep Dives
+
+- [Memory Optimization](references/memory.md) — allocation patterns, backing array leaks, sync.Pool, struct alignment
+- [CPU Optimization](references/cpu.md) — inlining, cache locality, false sharing, ILP, reflection avoidance
+- [I/O & Networking](references/io-networking.md) — HTTP transport config, streaming, JSON performance, cgo, batch operations
+- [Runtime Tuning](references/runtime.md) — GOGC, GOMEMLIMIT, GC diagnostics, GOMAXPROCS, PGO
+- [Caching Patterns](references/caching.md) — algorithmic complexity, compiled patterns, singleflight, work avoidance
+- [Production Observability](references/observability.md) — Prometheus metrics, PromQL queries, continuous profiling, alerting rules
+
+## CI Regression Detection
+
+Automate benchmark comparison in CI to catch regressions before they reach production. → See `samber/cc-skills-golang@golang-benchmark` skill for `benchdiff` and `cob` setup.
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-benchmark` skill for benchmarking methodology, `benchstat`, and `b.Loop()` (Go 1.24+)
+- → See `samber/cc-skills-golang@golang-troubleshooting` skill for pprof workflow, escape analysis diagnostics, and performance debugging
+- → See `samber/cc-skills-golang@golang-data-structures` skill for slice/map preallocation and `strings.Builder`
+- → See `samber/cc-skills-golang@golang-concurrency` skill for worker pools, `sync.Pool` API, goroutine lifecycle, and lock contention
+- → See `samber/cc-skills-golang@golang-safety` skill for defer in loops, slice backing array aliasing
+- → See `samber/cc-skills-golang@golang-database` skill for connection pool tuning and batch processing
+- → See `samber/cc-skills-golang@golang-observability` skill for continuous profiling in production
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/assets/prometheus-alerts.yml b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/assets/prometheus-alerts.yml
new file mode 100644
index 00000000..039eb4dc
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/assets/prometheus-alerts.yml
@@ -0,0 +1,20 @@
+# GC taking too much time per cycle
+- alert: HighGCPauseTime
+  expr: rate(go_gc_duration_seconds_sum[5m]) / rate(go_gc_duration_seconds_count[5m]) > 0.01
+  for: 10m
+  annotations:
+    summary: "Average GC pause >10ms — reduce allocations or tune GOGC"
+
+# Goroutine leak
+- alert: GoroutineLeak
+  expr: go_goroutines > 10000
+  for: 5m
+  annotations:
+    summary: "Goroutine count >10K — check for leaked goroutines"
+
+# Memory approaching container limit
+- alert: MemoryNearLimit
+  expr: predict_linear(process_resident_memory_bytes[1h], 3600) > <container_limit_bytes>
+  for: 15m
+  annotations:
+    summary: "RSS projected to exceed container limit within 1h"
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/evals/evals.json
new file mode 100644
index 00000000..54098775
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/evals/evals.json
@@ -0,0 +1,888 @@
+[
+  {
+    "id": 1,
+    "name": "profile-before-optimizing",
+    "description": "Tests whether the model insists on profiling before applying optimizations, rather than jumping straight to code changes",
+    "prompt": "Our Go HTTP API is slow. Average response time is 800ms. Here's the handler:\n\n```go\npackage api\n\nimport (\n    \"encoding/json\"\n    \"net/http\"\n    \"strings\"\n)\n\ntype Response struct {\n    Items []Item `json:\"items\"`\n}\n\ntype Item struct {\n    ID   int    `json:\"id\"`\n    Name string `json:\"name\"`\n    Tags string `json:\"tags\"`\n}\n\nfunc HandleList(w http.ResponseWriter, r *http.Request) {\n    items := fetchFromDB(r.Context())\n    for i := range items {\n        items[i].Tags = strings.ToUpper(items[i].Tags)\n    }\n    json.NewEncoder(w).Encode(Response{Items: items})\n}\n```\n\nOptimize this code to reduce the 800ms response time.",
+    "trap": "The 800ms latency is almost certainly from fetchFromDB (external bottleneck), not from strings.ToUpper or JSON encoding. Without the skill, the model will micro-optimize the Go code (use strings.Builder, preallocate, etc.) instead of pointing out that profiling is needed first and the bottleneck is likely external.",
+    "assertions": [
+      {"id": "1.1", "text": "Recommends profiling (pprof, fgprof, or tracing) before making code changes"},
+      {"id": "1.2", "text": "Identifies fetchFromDB as the likely bottleneck (external I/O, not Go code)"},
+      {"id": "1.3", "text": "Mentions that intuition about bottlenecks is often wrong (~80% of the time)"},
+      {"id": "1.4", "text": "Does NOT primarily focus on micro-optimizing strings.ToUpper or JSON encoding"},
+      {"id": "1.5", "text": "Suggests investigating the database query (query tuning, caching, connection pool)"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "fgprof-off-cpu-bottleneck",
+    "description": "Tests whether the model recommends fgprof for off-CPU bottlenecks instead of only standard CPU profiling",
+    "prompt": "Our Go service has high latency (p99 = 2s) but CPU usage is only 5%. Standard pprof CPU profile shows almost nothing — the hot functions consume negligible CPU time. What profiling approach should we use to find the bottleneck?",
+    "trap": "Standard CPU profiling only captures on-CPU time. When CPU usage is low but latency is high, the bottleneck is off-CPU (I/O wait, network, blocked goroutines). The skill specifically recommends fgprof for this. Without the skill, the model may suggest heap profiles, goroutine dumps, or other approaches that miss the key tool.",
+    "assertions": [
+      {"id": "2.1", "text": "Recommends fgprof as the primary tool for capturing off-CPU wait time"},
+      {"id": "2.2", "text": "Explains that standard pprof CPU profile only captures on-CPU time, which is why it shows nothing"},
+      {"id": "2.3", "text": "Suggests the bottleneck is likely I/O wait (network, database, filesystem)"},
+      {"id": "2.4", "text": "Mentions goroutine profile as a complementary diagnostic (blocked goroutines in net.Read or database/sql)"},
+      {"id": "2.5", "text": "Suggests distributed tracing (OpenTelemetry) for identifying slow upstream services"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "iterative-benchmark-methodology",
+    "description": "Tests whether the model follows the iterative benchmark methodology (one change at a time, benchstat comparison)",
+    "prompt": "I profiled my Go service and found that the ProcessRecords function is the bottleneck. It allocates heavily and has slow JSON parsing. I want to optimize it. Here's the function:\n\n```go\nfunc ProcessRecords(data []byte) ([]Record, error) {\n    var records []Record\n    if err := json.Unmarshal(data, &records); err != nil {\n        return nil, err\n    }\n    var results []Record\n    for _, r := range records {\n        if r.IsValid() {\n            r.Name = strings.ToUpper(r.Name)\n            results = append(results, r)\n        }\n    }\n    return results, nil\n}\n```\n\nHow should I approach optimizing this?",
+    "trap": "Without the skill, the model will apply all optimizations at once. The skill teaches an iterative approach: write benchmark first, measure baseline with -count=6, apply ONE change at a time, compare with benchstat, then repeat.",
+    "assertions": [
+      {"id": "3.1", "text": "Recommends writing an atomic benchmark for ProcessRecords first"},
+      {"id": "3.2", "text": "Recommends measuring a baseline with -benchmem and -count=6 (or similar count for statistical significance)"},
+      {"id": "3.3", "text": "Recommends applying ONE optimization at a time, not all at once"},
+      {"id": "3.4", "text": "Recommends using benchstat to compare before/after with statistical significance"},
+      {"id": "3.5", "text": "Suggests keeping report files as an audit trail (e.g., /tmp/report-1.txt, /tmp/report-2.txt)"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "slice-reuse-append-zero",
+    "description": "Tests knowledge of the append(s[:0], ...) pattern for reusing slice backing arrays",
+    "prompt": "In our hot-path Go request handler, we have a buffer that's reset each iteration. Profiling shows this function has high alloc_objects. How can we reduce allocations?\n\n```go\nfunc processRequests(requests []Request) {\n    for _, req := range requests {\n        mode := []Tag{req.PrimaryTag}\n        // ... use mode ...\n        _ = mode\n    }\n}\n```",
+    "trap": "The natural approach is to declare mode outside the loop or use sync.Pool. The skill teaches the specific pattern append(mode[:0], item) to reuse the backing array with zero allocations. This is a non-obvious Go idiom.",
+    "assertions": [
+      {"id": "4.1", "text": "Suggests using append(mode[:0], item) to reuse the backing array"},
+      {"id": "4.2", "text": "Explains that reslicing to zero length retains the backing array, avoiding allocation"},
+      {"id": "4.3", "text": "Moves the mode variable declaration outside the loop to enable reuse"},
+      {"id": "4.4", "text": "Does NOT suggest sync.Pool as the primary solution for this simple case"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "direct-indexing-vs-append",
+    "description": "Tests whether the model prefers direct indexing over append when output size equals input size",
+    "prompt": "Optimize this Go transformation function. Profiling shows it's called 100K times/sec with input slices of ~1000 elements.\n\n```go\nfunc Transform(input []Data) []Result {\n    result := make([]Result, 0, len(input))\n    for i := range input {\n        result = append(result, convert(input[i]))\n    }\n    return result\n}\n```\n\nThe output always has exactly the same number of elements as the input.",
+    "trap": "The code already preallocates capacity. Without the skill, the model may not realize that make([]T, len) with direct assignment is faster than make([]T, 0, cap) with append, because direct assignment avoids per-element bounds checking and length increment.",
+    "assertions": [
+      {"id": "5.1", "text": "Suggests using make([]Result, len(input)) with direct assignment result[i] = convert(...)"},
+      {"id": "5.2", "text": "Explains that direct assignment avoids per-element append overhead (bounds check, length increment)"},
+      {"id": "5.3", "text": "Notes that append is better when the result might be smaller (filtering)"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "map-range-double-lookup",
+    "description": "Tests whether the model avoids double map lookups when writing new map iteration code",
+    "prompt": "Write a Go function that counts how many values in a map satisfy a threshold. The map is large (1M entries) and the function is called frequently.\n\n```go\nfunc CountAbove(scores map[string]int, threshold int) int {\n    // TODO: implement\n}\n```\n\nWrite the most efficient implementation.",
+    "trap": "The natural/idiomatic instinct when writing map iteration code is to use 'for k := range m { if m[k] > threshold { count++ } }' because it looks clean. This does 2 lookups per iteration. The skill teaches 'for k, v := range m { if v > threshold { count++ } }' for a single lookup. The model will likely write the double-lookup version without the skill prompting it to use the k, v form.",
+    "assertions": [
+      {"id": "6.1", "text": "Uses 'for k, v := range scores' (capturing the value in range) rather than 'for k := range scores { scores[k] }'"},
+      {"id": "6.2", "text": "Does NOT perform a second lookup into the map inside the loop body (i.e., does not use scores[k] inside the loop)"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "sentinel-errors-hot-path",
+    "description": "Tests whether the model avoids fmt.Errorf for static errors in allocation-sensitive hot paths when writing new error-returning code",
+    "prompt": "Write a Go function that parses a configuration value. It must return descriptive errors and will be called thousands of times per second during request processing.\n\n```go\n// parseTimeout parses a timeout string like \"30s\", \"5m\".\n// Returns error if empty, if the unit is unrecognized, or if the value is negative.\nfunc parseTimeout(s string) (time.Duration, error) {\n    // TODO: implement\n}\n```\n\nImplement this function.",
+    "trap": "The natural way to write descriptive errors is to use fmt.Errorf for all cases: fmt.Errorf(\"empty timeout\"), fmt.Errorf(\"unrecognized unit %q\", unit), fmt.Errorf(\"negative timeout: %v\", d). The skill teaches that static, predictable errors (like 'empty timeout') should be preallocated sentinels at package level (errors.New) to avoid allocation on every call. Only errors needing dynamic values should use fmt.Errorf. Without the skill the model writes fmt.Errorf for every error case.",
+    "assertions": [
+      {"id": "7.1", "text": "Uses errors.New at package level for the static 'empty string' error case (no dynamic content)"},
+      {"id": "7.2", "text": "Uses fmt.Errorf (or errors.New with dynamic content) for error cases that need to embed runtime values like the unrecognized unit"},
+      {"id": "7.3", "text": "Does NOT use fmt.Errorf for error messages that contain no dynamic values"},
+      {"id": "7.4", "text": "Explains that fmt.Errorf allocates on every call while package-level errors.New allocates once"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "interface-boxing-hot-path",
+    "description": "Tests knowledge of interface boxing allocation cost and the fix using generics or typed parameters",
+    "prompt": "Our Go analytics pipeline processes events at high throughput. Profiling shows unexpectedly high allocation rates in this function:\n\n```go\nfunc SumValues(values []any) float64 {\n    var total float64\n    for _, v := range values {\n        switch n := v.(type) {\n        case int:\n            total += float64(n)\n        case float64:\n            total += n\n        }\n    }\n    return total\n}\n```\n\nCallers always pass either all ints or all float64s. How can we reduce allocations?",
+    "trap": "Passing concrete types through any/interface{} forces heap allocation for boxing. The skill teaches using typed parameters or generics. Without it, the model may focus on the type switch optimization rather than the fundamental boxing problem.",
+    "assertions": [
+      {"id": "8.1", "text": "Identifies interface boxing (any parameter) as the source of allocations"},
+      {"id": "8.2", "text": "Suggests typed functions (e.g., SumInts([]int)) or generics (func Sum[T ~int|~float64]([]T)) to eliminate boxing"},
+      {"id": "8.3", "text": "Explains that each concrete value passed through any requires a heap allocation for boxing"},
+      {"id": "8.4", "text": "Does NOT focus only on the type switch as the optimization target"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "backing-array-leak-slice",
+    "description": "Tests whether the model avoids backing array retention when writing a function that stores subslices long-term",
+    "prompt": "Write a Go function that caches the first 16 bytes of each incoming network packet for later audit logging. Packets are large (up to 64KB) and are pooled via sync.Pool — they get reused after the call returns.\n\n```go\nvar auditLog [][]byte\n\nfunc recordPacketPrefix(pkt []byte) {\n    // TODO: store first 16 bytes of pkt in auditLog\n}\n```\n\nImplement this function.",
+    "trap": "The obvious, idiomatic implementation is 'auditLog = append(auditLog, pkt[:16])' — a simple reslice. This looks correct but retains the entire 64KB backing array per entry because the subslice shares the original buffer. Since packets come from a sync.Pool and are reused, the retained backing arrays also prevent correct pool behavior. The fix is to copy: 'prefix := make([]byte, 16); copy(prefix, pkt[:16]); auditLog = append(auditLog, prefix)'. Without the skill the model writes the reslice version.",
+    "assertions": [
+      {"id": "9.1", "text": "Does NOT use pkt[:16] directly as the stored value (reslice retains the entire backing array)"},
+      {"id": "9.2", "text": "Creates an independent copy using make([]byte, 16) + copy, or equivalent"},
+      {"id": "9.3", "text": "Explains that storing a reslice retains the entire original backing array, preventing GC"},
+      {"id": "9.4", "text": "Notes the interaction with sync.Pool: retained backing arrays prevent buffer reuse or cause data corruption"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "substring-memory-leak",
+    "description": "Tests knowledge of the strings.Clone pattern for substring memory leaks",
+    "prompt": "Our Go log processing service extracts request IDs from log lines. Memory keeps growing even though we only store short strings. Go 1.20+ project.\n\n```go\nvar requestIDs = make(map[string]time.Time)\n\nfunc ProcessLogLine(line string) {\n    // line is typically 500-2000 bytes\n    id := line[12:48] // extract 36-char UUID\n    requestIDs[id] = time.Now()\n}\n```",
+    "trap": "Substrings share the backing array of the original string. Each 36-char id retains the full 500-2000 byte log line. The skill teaches strings.Clone (Go 1.20+) as the fix. Without it, the model may not know about strings.Clone or may suggest string([]byte(s)) which is also correct but less idiomatic.",
+    "assertions": [
+      {"id": "10.1", "text": "Identifies that substrings share the backing array of the original string"},
+      {"id": "10.2", "text": "Suggests strings.Clone(line[12:48]) to create an independent copy"},
+      {"id": "10.3", "text": "Explains that each 36-char ID retains the entire 500-2000 byte log line in memory"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "map-never-shrinks",
+    "description": "Tests whether the model avoids using a long-lived map for a high-churn cache without addressing bucket retention",
+    "prompt": "Design a Go in-memory rate-limiter that tracks per-IP request counts. Counts reset every minute. At peak there are 500K active IPs, but off-peak only ~200 IPs are active.\n\n```go\ntype RateLimiter struct {\n    mu     sync.Mutex\n    counts map[string]int\n}\n\nfunc NewRateLimiter() *RateLimiter {\n    return &RateLimiter{counts: make(map[string]int)}\n}\n\nfunc (r *RateLimiter) reset() {\n    r.mu.Lock()\n    defer r.mu.Unlock()\n    // TODO: implement the per-minute reset\n}\n```\n\nImplement the reset method.",
+    "trap": "The natural, obvious implementation is to range over the map and delete each key: 'for k := range r.counts { delete(r.counts, k) }'. This looks correct and idiomatic but leaves all 500K bucket slots allocated — the map retains its peak allocation forever. The skill teaches that maps never release bucket memory; the fix is to replace the map entirely: 'r.counts = make(map[string]int)'. Without the skill the model writes the delete-loop version.",
+    "assertions": [
+      {"id": "11.1", "text": "Replaces the map with a fresh allocation (r.counts = make(map[string]int)) rather than deleting keys in a loop"},
+      {"id": "11.2", "text": "Does NOT use 'for k := range r.counts { delete(r.counts, k) }' as the reset strategy"},
+      {"id": "11.3", "text": "Explains that Go maps never release bucket memory when keys are deleted, so delete-loop retains peak allocation"},
+      {"id": "11.4", "text": "Notes that reassigning to a new map allows the old bucket array to be GC'd"}
+    ]
+  },
+  {
+    "id": 12,
+    "name": "sync-pool-rules",
+    "description": "Tests proper sync.Pool usage: reset before Put, return copies not pooled buffers, size limits",
+    "prompt": "Review this sync.Pool usage in our Go HTTP handler for correctness:\n\n```go\nvar bufPool = sync.Pool{\n    New: func() any { return make([]byte, 0, 64*1024) },\n}\n\nfunc HandleRequest(w http.ResponseWriter, r *http.Request) {\n    buf := bufPool.Get().([]byte)\n    // ... fill buf with response data ...\n    buf = append(buf[:0], responseData...)\n    w.Write(buf)\n    bufPool.Put(buf)\n}\n\nfunc HandleLargeUpload(w http.ResponseWriter, r *http.Request) {\n    buf := bufPool.Get().([]byte)\n    data, _ := io.ReadAll(r.Body) // could be 100MB+\n    buf = append(buf[:0], data...)\n    processData(buf)\n    bufPool.Put(buf)\n}\n```\n\nIdentify all issues with this pool usage.",
+    "trap": "Multiple issues: (1) HandleRequest returns the pooled buffer directly via w.Write — the caller (net/http) may retain it after Put, (2) HandleLargeUpload puts enormous buffers (100MB+) back into the pool — don't pool objects >32KB, (3) the pool stores []byte values not pointers, which causes an allocation on Get. The skill covers all these rules.",
+    "assertions": [
+      {"id": "12.1", "text": "Identifies that HandleLargeUpload puts oversized buffers (100MB+) back into the pool"},
+      {"id": "12.2", "text": "Mentions the 32KB guideline — don't pool objects larger than ~32KB"},
+      {"id": "12.3", "text": "Identifies that w.Write(buf) may retain the buffer after bufPool.Put(buf) in the same function"},
+      {"id": "12.4", "text": "Suggests pooling pointers (*[]byte) instead of values to avoid allocation on Get"},
+      {"id": "12.5", "text": "Recommends resetting/clearing state before Put to avoid retaining large object graphs"}
+    ]
+  },
+  {
+    "id": 13,
+    "name": "struct-field-alignment",
+    "description": "Tests knowledge of struct field ordering for optimal memory layout",
+    "prompt": "Our Go service creates millions of these structs. Memory profiling shows they consume more space than expected. Can we reduce memory usage?\n\n```go\ntype Event struct {\n    Active    bool\n    Timestamp int64\n    Priority  bool\n    UserID    int32\n    Processed bool\n    Score     float64\n}\n```\n\nHow large is this struct and can we make it smaller?",
+    "trap": "The struct has poor field alignment. bool (1 byte) followed by int64 (8 bytes) adds 7 bytes of padding. The skill teaches reordering fields largest-to-smallest and using fieldalignment tool. Without it, the model may not compute the correct size or suggest the optimal reordering.",
+    "assertions": [
+      {"id": "13.1", "text": "Identifies that the struct has wasted padding bytes due to alignment"},
+      {"id": "13.2", "text": "Suggests reordering fields from largest to smallest (int64/float64 first, then int32, then bools)"},
+      {"id": "13.3", "text": "Provides a reordered struct that is smaller than the original"},
+      {"id": "13.4", "text": "Mentions the fieldalignment tool for automated detection"},
+      {"id": "13.5", "text": "States alignment requirements (bool=1, int32=4, int64/float64=8)"}
+    ]
+  },
+  {
+    "id": 14,
+    "name": "zero-size-field-end-of-struct",
+    "description": "Tests knowledge that struct{} at end of struct adds word-sized padding",
+    "prompt": "We're optimizing memory in our Go event system. This struct is allocated millions of times:\n\n```go\ntype Entry struct {\n    Value int64\n    Flag  struct{}\n}\n```\n\nWe expected it to be 8 bytes (just the int64) since struct{} is zero-size. But unsafe.Sizeof reports 16 bytes. Why?",
+    "trap": "When the last field has zero size (struct{}), the compiler adds word-sized padding (8 bytes on 64-bit) to prevent a pointer to that field from overlapping the next memory block. The fix is to move struct{} to the beginning. This is a very obscure Go internals detail.",
+    "assertions": [
+      {"id": "14.1", "text": "Explains that a zero-size field at the end of a struct causes word-sized padding"},
+      {"id": "14.2", "text": "Explains the reason: preventing a pointer to the zero-size field from overlapping the next memory block"},
+      {"id": "14.3", "text": "Suggests moving struct{} to the beginning of the struct to eliminate the padding"},
+      {"id": "14.4", "text": "Shows the fix: type Entry struct { Flag struct{}; Value int64 } which is 8 bytes"}
+    ]
+  },
+  {
+    "id": 15,
+    "name": "map-pointer-vs-value-tradeoff",
+    "description": "Tests knowledge of map[K]*V vs map[K]V tradeoff for large frequently-updated structs",
+    "prompt": "Our Go game server updates player scores frequently. This pattern is inefficient:\n\n```go\ntype Player struct {\n    Name      string\n    Score     int\n    Level     int\n    Inventory [256]byte\n    Stats     [64]float64\n}\n\nvar players = make(map[string]Player)\n\nfunc UpdateScore(id string, delta int) {\n    p := players[id]\n    p.Score += delta\n    players[id] = p // full copy\n}\n```\n\nHow can we optimize the update pattern?",
+    "trap": "Map values are not addressable — you can't do players[id].Score += delta. The copy-modify-reassign pattern copies the entire large struct. Using map[string]*Player allows direct modification. But the skill also teaches the tradeoff: pointer maps add GC pressure from separate heap allocations. Without it, the model may suggest pointers without mentioning the tradeoff.",
+    "assertions": [
+      {"id": "15.1", "text": "Suggests using map[string]*Player to allow direct field modification"},
+      {"id": "15.2", "text": "Explains that map values are not addressable (can't modify in place)"},
+      {"id": "15.3", "text": "Shows players[id].Score += delta with pointer map"},
+      {"id": "15.4", "text": "Mentions the tradeoff: pointer maps add GC pressure from separate heap allocations"},
+      {"id": "15.5", "text": "Notes that for small, mostly-read structs, map[K]V (value) is better"}
+    ]
+  },
+  {
+    "id": 16,
+    "name": "inlining-log-in-hot-path",
+    "description": "Tests knowledge that log calls prevent function inlining",
+    "prompt": "This Go helper function is called millions of times per second in a tight loop. The CPU profile shows it takes much more time than expected for such a simple function.\n\n```go\nfunc clamp(val, minVal, maxVal int) int {\n    if val < minVal {\n        log.Printf(\"clamped %d below minimum %d\", val, minVal)\n        return minVal\n    }\n    if val > maxVal {\n        log.Printf(\"clamped %d above maximum %d\", val, maxVal)\n        return maxVal\n    }\n    return val\n}\n```\n\nWhy is this function slow and how do we fix it?",
+    "trap": "The log.Printf calls prevent the compiler from inlining the function. In a tight loop called millions of times, function call overhead is significant. The skill specifically warns about logging in hot loops preventing inlining. Without it, the model may focus on the log formatting cost rather than the inlining prevention.",
+    "assertions": [
+      {"id": "16.1", "text": "Identifies that log calls prevent the function from being inlined by the compiler"},
+      {"id": "16.2", "text": "Suggests removing log calls from the hot-path function or moving them outside"},
+      {"id": "16.3", "text": "Mentions using go build -gcflags=\"-m\" to verify inlining decisions"},
+      {"id": "16.4", "text": "Explains that function call overhead matters when called millions of times in a tight loop"}
+    ]
+  },
+  {
+    "id": 17,
+    "name": "value-receiver-inlining",
+    "description": "Tests knowledge that value receivers enable inlining for fluent method chains",
+    "prompt": "We have a Go config builder used in a hot path. Profiling shows the fluent chain is slower than expected:\n\n```go\ntype Config struct {\n    timeout  time.Duration\n    retries  int\n    verbose  bool\n}\n\nfunc (c *Config) WithTimeout(d time.Duration) *Config {\n    c.timeout = d\n    return c\n}\n\nfunc (c *Config) WithRetries(n int) *Config {\n    c.retries = n\n    return c\n}\n\nfunc (c *Config) WithVerbose(v bool) *Config {\n    c.verbose = v\n    return c\n}\n```\n\nThis is called as: `cfg := (&Config{}).WithTimeout(5*time.Second).WithRetries(3).WithVerbose(true)`\n\nHow can we make the fluent chain faster?",
+    "trap": "Pointer receivers add indirection that blocks inlining of fluent method chains. Value receivers allow the compiler to fully inline the chain. The skill quantifies this as -80% time. Without the skill, the model may suggest unrelated optimizations.",
+    "assertions": [
+      {"id": "17.1", "text": "Suggests changing to value receivers instead of pointer receivers"},
+      {"id": "17.2", "text": "Explains that value receivers allow the compiler to inline the fluent chain"},
+      {"id": "17.3", "text": "Explains that pointer receivers add indirection that blocks inlining"},
+      {"id": "17.4", "text": "Shows the value receiver signature: func (c Config) WithTimeout(d time.Duration) Config"}
+    ]
+  },
+  {
+    "id": 18,
+    "name": "cache-locality-matrix-traversal",
+    "description": "Tests knowledge of row-major vs column-major traversal and cache effects",
+    "prompt": "This Go matrix computation is unexpectedly slow. The matrix is 4096x4096 float64. CPU profile shows the loop itself (not the computation) is the bottleneck.\n\n```go\nfunc ColumnSum(matrix [4096][4096]float64) [4096]float64 {\n    var sums [4096]float64\n    for col := 0; col < 4096; col++ {\n        for row := 0; row < 4096; row++ {\n            sums[col] += matrix[row][col]\n        }\n    }\n    return sums\n}\n```\n\nWhy is this slow and how do we fix it?",
+    "trap": "Column-first traversal on row-major storage causes cache misses on every access. The fix is to swap loop order. The skill quantifies the difference as 10-50x from cache effects alone. Without it, the model may suggest parallelism or SIMD rather than the simple loop reorder.",
+    "assertions": [
+      {"id": "18.1", "text": "Identifies the column-first traversal as the cause (cache misses)"},
+      {"id": "18.2", "text": "Explains that Go stores 2D arrays in row-major order"},
+      {"id": "18.3", "text": "Suggests swapping loop order to row-first (outer loop over rows)"},
+      {"id": "18.4", "text": "Mentions the performance difference from cache effects (10-50x or similar magnitude)"},
+      {"id": "18.5", "text": "Does NOT primarily suggest parallelism or SIMD as the first fix"}
+    ]
+  },
+  {
+    "id": 19,
+    "name": "contiguous-2d-allocation",
+    "description": "Tests whether the model uses contiguous allocation when writing new 2D matrix code for a performance-critical context",
+    "prompt": "Write a Go function that creates an NxM grid of float64 values initialized to zero, for use in a finite-element simulation that iterates row by row over the grid millions of times per second.\n\n```go\nfunc NewGrid(rows, cols int) [][]float64 {\n    // TODO\n}\n```\n\nImplement this function.",
+    "trap": "The standard idiomatic Go way to create a 2D slice is the row-by-row allocation loop: make([][]float64, rows) followed by make([]float64, cols) per row. Every Go tutorial and example uses this pattern. However for performance-critical numeric code the skill teaches a single contiguous allocation (make([]float64, rows*cols)) sliced into row views, which has far better cache locality. Without the skill the model writes the idiomatic per-row allocation.",
+    "assertions": [
+      {"id": "19.1", "text": "Allocates a single contiguous backing slice: make([]float64, rows*cols)"},
+      {"id": "19.2", "text": "Slices it into row views: data[i*cols : (i+1)*cols]"},
+      {"id": "19.3", "text": "Does NOT allocate each row independently with a separate make([]float64, cols) call"},
+      {"id": "19.4", "text": "Explains that contiguous allocation improves cache locality for row-sequential access"}
+    ]
+  },
+  {
+    "id": 20,
+    "name": "soa-vs-aos",
+    "description": "Tests knowledge of Struct of Arrays vs Array of Structs for single-field iteration",
+    "prompt": "Our Go physics simulation iterates over millions of particles but only reads the X coordinate for collision detection in the first pass:\n\n```go\ntype Particle struct {\n    X, Y, Z    float64\n    VX, VY, VZ float64\n    Mass       float64\n    Radius     float64\n}\n\nvar particles []Particle // millions of elements\n\nfunc FindCollisionCandidates() []int {\n    var candidates []int\n    for i := range particles {\n        if particles[i].X > threshold {\n            candidates = append(candidates, i)\n        }\n    }\n    return candidates\n}\n```\n\nCPU profile shows this loop is slow. We only need the X field in this pass. How can we speed it up?",
+    "trap": "Loading each 64-byte Particle to read only X (8 bytes) wastes 87.5% of cache space. The skill teaches SoA (Struct of Arrays) where all X values are contiguous for 100% cache utilization. Without it, the model may suggest parallelism or preallocation rather than the data layout change.",
+    "assertions": [
+      {"id": "20.1", "text": "Identifies that loading entire Particle structs wastes cache space when only X is needed"},
+      {"id": "20.2", "text": "Suggests Struct of Arrays (SoA) layout with separate slices for X, Y, Z, etc."},
+      {"id": "20.3", "text": "Explains cache utilization improvement (contiguous X values vs scattered across structs)"},
+      {"id": "20.4", "text": "Notes that AoS is fine when accessing all fields together or for small structs"}
+    ]
+  },
+  {
+    "id": 21,
+    "name": "false-sharing-concurrent-counters",
+    "description": "Tests knowledge of false sharing and cache-line padding",
+    "prompt": "Our Go service has per-goroutine counters that are updated concurrently. Adding more goroutines makes it SLOWER, not faster. Profiling shows atomic operations on counters consuming unexpectedly high CPU.\n\n```go\ntype Metrics struct {\n    RequestCount int64\n    ErrorCount   int64\n    BytesRead    int64\n    BytesWritten int64\n}\n\nvar metrics Metrics\n\n// Each goroutine increments different counters concurrently\nfunc recordRequest(bytes int64) {\n    atomic.AddInt64(&metrics.RequestCount, 1)\n    atomic.AddInt64(&metrics.BytesRead, bytes)\n}\n\nfunc recordError(bytes int64) {\n    atomic.AddInt64(&metrics.ErrorCount, 1)\n    atomic.AddInt64(&metrics.BytesWritten, bytes)\n}\n```\n\nWhy does adding goroutines make it slower?",
+    "trap": "All four int64 fields fit within a single 64-byte cache line. When different goroutines update different fields, each write invalidates the other core's cache line (false sharing). The fix is cache-line padding. Without the skill, the model may suggest mutexes or sharding rather than identifying false sharing.",
+    "assertions": [
+      {"id": "21.1", "text": "Identifies false sharing as the cause (fields share the same cache line)"},
+      {"id": "21.2", "text": "Explains that writes to one field invalidate the cache line for other cores"},
+      {"id": "21.3", "text": "Suggests cache-line padding (56-byte [56]byte array between fields) to separate cache lines"},
+      {"id": "21.4", "text": "Mentions the 64-byte cache line size"},
+      {"id": "21.5", "text": "Notes this should only be applied when profiling confirms contention"}
+    ]
+  },
+  {
+    "id": 22,
+    "name": "ilp-multi-accumulator",
+    "description": "Tests knowledge of instruction-level parallelism with multiple accumulators",
+    "prompt": "This Go function sums a large float64 slice (10M elements). Profiling shows it's CPU-bound with the loop body consuming most of the time. The computation is simple addition — how can we speed it up without parallelizing across goroutines?\n\n```go\nfunc Sum(data []float64) float64 {\n    var total float64\n    for _, v := range data {\n        total += v\n    }\n    return total\n}\n```",
+    "trap": "The single accumulator creates a dependency chain — each addition waits for the previous one. The skill teaches using 4 independent accumulators to exploit CPU instruction-level parallelism (2-4x improvement). Without it, the model may suggest SIMD or goroutine-based parallelism rather than the simpler multi-accumulator approach.",
+    "assertions": [
+      {"id": "22.1", "text": "Identifies the sequential dependency chain as the bottleneck (each addition waits for the previous)"},
+      {"id": "22.2", "text": "Suggests using multiple accumulators (e.g., 4) for instruction-level parallelism"},
+      {"id": "22.3", "text": "Shows code with 4 independent accumulators summing every 4th element"},
+      {"id": "22.4", "text": "Handles the remainder elements (when len(data) is not divisible by 4)"},
+      {"id": "22.5", "text": "Mentions expected 2-4x improvement from ILP"}
+    ]
+  },
+  {
+    "id": 23,
+    "name": "index-based-tree-cache-locality",
+    "description": "Tests whether the model uses index-based node storage when implementing a high-performance tree from scratch",
+    "prompt": "Implement a Go binary search tree for a high-throughput in-memory lookup service. The tree will hold ~1M integer keys and be traversed millions of times per second. Write the node and tree type definitions and the Insert method.\n\n```go\n// TODO: define types and implement Insert\n```",
+    "trap": "Every Go tutorial, textbook, and LeetCode solution defines a binary tree with pointer-based nodes: 'type Node struct { Value int; Left, Right *Node }'. This is the universal default. However the skill teaches that pointer-based trees scatter each node across the heap causing random cache misses on every traversal. For high-throughput lookup the correct approach is index-based nodes stored in a contiguous slice: 'type Node struct { Value, Left, Right int }' inside a Tree struct with a Nodes []Node backing array. Without the skill the model writes the pointer-based version.",
+    "assertions": [
+      {"id": "23.1", "text": "Stores nodes in a contiguous slice (e.g., Nodes []Node field on the tree struct)"},
+      {"id": "23.2", "text": "Uses integer indices (not pointers) for left/right child references"},
+      {"id": "23.3", "text": "Does NOT define nodes with *Node pointer fields as the primary implementation"},
+      {"id": "23.4", "text": "Explains that index-based nodes stay in contiguous memory, reducing cache misses compared to scattered heap pointers"}
+    ]
+  },
+  {
+    "id": 24,
+    "name": "tight-loop-scheduler-starvation",
+    "description": "Tests knowledge of tight CPU loops starving the Go scheduler",
+    "prompt": "Our Go service has a CPU-intensive computation goroutine that runs for several seconds. Other goroutines (HTTP handlers) become unresponsive during the computation, even though GOMAXPROCS is set to 4.\n\n```go\nfunc heavyCompute(data []float64) float64 {\n    var result float64\n    for i := 0; i < len(data); i++ {\n        result = result*0.99 + data[i]*0.01\n    }\n    return result\n}\n```\n\nThe data slice has 100M elements. Why are other goroutines starved?",
+    "trap": "A tight CPU loop with fully inlined operations may not yield to the scheduler, despite Go 1.14+ async preemption. The skill teaches using non-inlined function calls as preemption points, or //go:noinline. Without it, the model may suggest runtime.Gosched() (which works but isn't the recommended approach) or parallelism.",
+    "assertions": [
+      {"id": "24.1", "text": "Explains that tight CPU loops with inlined operations can delay scheduler preemption"},
+      {"id": "24.2", "text": "Suggests breaking the work into batches processed by a non-inlined function call"},
+      {"id": "24.3", "text": "Mentions //go:noinline as an option to force preemption points"},
+      {"id": "24.4", "text": "Explains the tradeoff: //go:noinline adds function call overhead but ensures scheduler fairness"},
+      {"id": "24.5", "text": "Mentions that Go 1.14+ has async preemption but tight loops with inlined ops can still cause issues"}
+    ]
+  },
+  {
+    "id": 25,
+    "name": "reflect-deepequal-performance",
+    "description": "Tests knowledge of reflect.DeepEqual being 50-200x slower than typed comparisons",
+    "prompt": "Review this Go function for performance. It compares two configuration objects for equality in a hot path (called on every request):\n\n```go\nfunc ConfigChanged(old, new Config) bool {\n    return !reflect.DeepEqual(old, new)\n}\n\ntype Config struct {\n    Hosts    []string\n    Settings map[string]string\n    Timeout  int\n    Debug    bool\n}\n```",
+    "trap": "reflect.DeepEqual is 50-200x slower than typed comparison. The skill specifically calls this out as a common mistake and recommends slices.Equal, maps.Equal for the structured fields. Without it, the model may say it's fine or suggest a less specific alternative.",
+    "assertions": [
+      {"id": "25.1", "text": "Identifies reflect.DeepEqual as 50-200x slower than typed comparison"},
+      {"id": "25.2", "text": "Suggests using slices.Equal for the Hosts field"},
+      {"id": "25.3", "text": "Suggests using maps.Equal for the Settings field"},
+      {"id": "25.4", "text": "Provides a hand-written typed comparison function"}
+    ]
+  },
+  {
+    "id": 26,
+    "name": "type-switch-vs-repeated-assertions",
+    "description": "Tests whether the model uses a type switch (not repeated assertions) when writing new interface dispatch code for a hot path",
+    "prompt": "Write a Go function that formats any scalar value as a string for a high-throughput metrics labeling system. It must handle string, int, int64, float64, and bool. Called ~500K times/sec.\n\n```go\nfunc FormatLabel(v any) string {\n    // TODO\n}\n```\n\nImplement this function.",
+    "trap": "The natural way many Go developers write multi-type dispatch is a chain of if-assertions: 'if s, ok := v.(string); ok { return s }' etc. — it looks clear and matches the pattern from many examples. A type switch 'switch v := v.(type) { case string: ... }' dispatches in a single evaluation of the interface type and is the correct pattern for hot paths. Without the skill the model may write the if-chain of repeated assertions, evaluating the interface type multiple times.",
+    "assertions": [
+      {"id": "26.1", "text": "Uses a type switch (switch v := v.(type)) rather than a chain of individual if-assertions"},
+      {"id": "26.2", "text": "Does NOT use repeated v.(T) comma-ok assertions in separate if-blocks"},
+      {"id": "26.3", "text": "Handles all required types: string, int (or int64), float64, and bool in the switch cases"}
+    ]
+  },
+  {
+    "id": 27,
+    "name": "http-transport-maxidleconnsperhost",
+    "description": "Tests knowledge that default http.Client MaxIdleConnsPerHost is only 2",
+    "prompt": "Our Go microservice calls an upstream API with high concurrency (200 goroutines making requests simultaneously). Under load, we see many TCP connections being created and destroyed. Why doesn't connection pooling work?\n\n```go\nvar client = &http.Client{\n    Timeout: 30 * time.Second,\n}\n\nfunc CallAPI(ctx context.Context, id string) ([]byte, error) {\n    resp, err := client.Get(fmt.Sprintf(\"https://api.example.com/v1/items/%s\", id))\n    if err != nil {\n        return nil, err\n    }\n    defer resp.Body.Close()\n    return io.ReadAll(resp.Body)\n}\n```",
+    "trap": "The default http.Transport has MaxIdleConnsPerHost=2. With 200 concurrent goroutines, 198 connections are created and destroyed for each request. The skill specifically calls this out as a common mistake. Without it, the model may suggest connection pool libraries instead of tuning the built-in transport.",
+    "assertions": [
+      {"id": "27.1", "text": "Identifies MaxIdleConnsPerHost defaulting to 2 as the root cause"},
+      {"id": "27.2", "text": "Suggests configuring http.Transport with higher MaxIdleConnsPerHost (e.g., 20-100)"},
+      {"id": "27.3", "text": "Shows complete Transport configuration with MaxIdleConns, MaxIdleConnsPerHost, and MaxConnsPerHost"},
+      {"id": "27.4", "text": "Mentions draining resp.Body for connection reuse (io.Copy to io.Discard)"},
+      {"id": "27.5", "text": "Does NOT suggest using a third-party connection pool library as the primary solution"}
+    ]
+  },
+  {
+    "id": 28,
+    "name": "response-body-drain",
+    "description": "Tests whether the model drains the response body when writing a new HTTP health-check function",
+    "prompt": "Write a Go function that polls a list of service endpoints and returns which ones are healthy (HTTP 200). It will run every 5 seconds against ~50 endpoints with a shared http.Client.\n\n```go\nfunc CheckHealthy(client *http.Client, urls []string) []string {\n    // TODO: return URLs that respond with 200\n}\n```\n\nImplement this function.",
+    "trap": "The natural implementation closes the body with 'defer resp.Body.Close()' and reads the status code — which looks correct and complete. Most developers do not know that the transport only returns the connection to the pool after the body is fully consumed. Without draining via 'io.Copy(io.Discard, resp.Body)', each health check creates a new TCP connection and the 50-endpoint poll exhausts the connection pool. Without the skill the model writes the close-only version.",
+    "assertions": [
+      {"id": "28.1", "text": "Drains the response body using io.Copy(io.Discard, resp.Body) or io.ReadAll before closing"},
+      {"id": "28.2", "text": "Does NOT only call resp.Body.Close() without first reading/draining the body"},
+      {"id": "28.3", "text": "Explains that connections are only returned to the pool after the body is fully consumed"}
+    ]
+  },
+  {
+    "id": 29,
+    "name": "streaming-vs-readall",
+    "description": "Tests knowledge of streaming vs buffering for large payloads",
+    "prompt": "Our Go service proxies file downloads. Under load with large files (1-5GB), the service runs out of memory and gets OOM killed.\n\n```go\nfunc ProxyDownload(w http.ResponseWriter, r *http.Request) {\n    resp, err := http.Get(upstreamURL + r.URL.Path)\n    if err != nil {\n        http.Error(w, \"upstream error\", 502)\n        return\n    }\n    defer resp.Body.Close()\n\n    data, err := io.ReadAll(resp.Body)\n    if err != nil {\n        http.Error(w, \"read error\", 500)\n        return\n    }\n\n    w.Header().Set(\"Content-Type\", resp.Header.Get(\"Content-Type\"))\n    w.Write(data)\n}\n```",
+    "trap": "io.ReadAll loads the entire response into memory. For a 5GB file, that's a 5GB allocation. The fix is io.Copy which streams with a 32KB buffer. The skill specifically warns about io.ReadAll for large payloads.",
+    "assertions": [
+      {"id": "29.1", "text": "Identifies io.ReadAll as the cause of OOM (loads entire file into memory)"},
+      {"id": "29.2", "text": "Suggests using io.Copy(w, resp.Body) to stream with constant memory"},
+      {"id": "29.3", "text": "Mentions the 32KB internal buffer of io.Copy"},
+      {"id": "29.4", "text": "Notes that io.ReadAll is fine for small, bounded payloads (< 1MB)"}
+    ]
+  },
+  {
+    "id": 30,
+    "name": "json-streaming-decoder",
+    "description": "Tests knowledge of json.NewDecoder for streaming large JSON payloads",
+    "prompt": "Our Go API receives large JSON arrays (10K-100K items). Memory spikes during unmarshaling cause GC pressure.\n\n```go\nfunc HandleBulkImport(w http.ResponseWriter, r *http.Request) {\n    data, _ := io.ReadAll(r.Body)\n    var items []Item\n    if err := json.Unmarshal(data, &items); err != nil {\n        http.Error(w, err.Error(), 400)\n        return\n    }\n    for _, item := range items {\n        processItem(item)\n    }\n}\n```\n\nHow can we reduce memory usage while processing the same JSON input?",
+    "trap": "json.Unmarshal buffers the entire body. json.NewDecoder streams tokens. The skill teaches the decoder.More() + decoder.Decode() pattern for processing one item at a time. Without it, the model may suggest chunking or pagination rather than streaming JSON.",
+    "assertions": [
+      {"id": "30.1", "text": "Suggests using json.NewDecoder with r.Body directly (no io.ReadAll)"},
+      {"id": "30.2", "text": "Shows the dec.More() + dec.Decode(&item) streaming pattern"},
+      {"id": "30.3", "text": "Explains that this processes one item at a time with O(1) memory per item"}
+    ]
+  },
+  {
+    "id": 31,
+    "name": "cgo-overhead-tight-loop",
+    "description": "Tests knowledge of cgo call overhead (~50-100ns per crossing) and batching strategy",
+    "prompt": "Our Go numerical library calls a C function for each element. Profiling shows the cgo calls dominate execution time even though the C function itself is simple.\n\n```go\n/*\n#include <math.h>\n*/\nimport \"C\"\n\nfunc TransformAll(values []float64) {\n    for i, v := range values {\n        values[i] = float64(C.sqrt(C.double(v)))\n    }\n}\n```\n\nHow can we optimize this?",
+    "trap": "Each cgo call costs ~50-100ns due to stack switching. For math.Sqrt, the pure Go stdlib is equally fast and inlineable. For unavoidable C code, batch the call. The skill teaches both approaches. Without it, the model may not know the cgo overhead magnitude or suggest batching.",
+    "assertions": [
+      {"id": "31.1", "text": "Identifies cgo overhead (~50-100ns per call) as the bottleneck in the tight loop"},
+      {"id": "31.2", "text": "Suggests using math.Sqrt (pure Go, inlineable) instead of C.sqrt"},
+      {"id": "31.3", "text": "For unavoidable C code, suggests batching: pass the entire array to C in one call"},
+      {"id": "31.4", "text": "Mentions that goroutine is pinned to OS thread during cgo calls"}
+    ]
+  },
+  {
+    "id": 32,
+    "name": "gogc-gomemlimit-container",
+    "description": "Tests knowledge of GOMEMLIMIT for containerized applications",
+    "prompt": "Our Go service runs in a Kubernetes pod with 512MB memory limit. It periodically gets OOM killed even though heap usage appears to be only 200MB when checked via runtime.MemStats.Alloc.\n\nHow should we configure the Go runtime for this container?",
+    "trap": "The service needs GOMEMLIMIT set to ~80-90% of container memory (400-450MiB). Without it, the GC doesn't know about the container limit and may let the heap grow too large. The skill specifically calls this out as a common mistake ('No GC tuning in containers'). Without it, the model may suggest GOGC tuning alone.",
+    "assertions": [
+      {"id": "32.1", "text": "Recommends setting GOMEMLIMIT to 80-90% of the container memory limit (400-450MiB)"},
+      {"id": "32.2", "text": "Explains that the GC needs GOMEMLIMIT to know about the container's memory ceiling"},
+      {"id": "32.3", "text": "Shows the GOMEMLIMIT=450MiB environment variable or debug.SetMemoryLimit equivalent"},
+      {"id": "32.4", "text": "Explains the gap between Alloc and container limit (goroutine stacks, OS buffers, non-heap memory)"},
+      {"id": "32.5", "text": "Does NOT recommend the ballast pattern (obsolete since Go 1.19)"}
+    ]
+  },
+  {
+    "id": 33,
+    "name": "ballast-pattern-obsolete",
+    "description": "Tests whether the model avoids the ballast pattern and uses GOMEMLIMIT when configuring GC for a new service",
+    "prompt": "We're deploying a new Go 1.22 service in a Kubernetes pod with 2GB memory limit. The service is allocation-heavy during bursts and we want to reduce GC frequency to avoid latency spikes. A senior engineer suggested allocating a large byte array at startup to inflate the live heap. How should we configure the runtime?\n\n```go\nfunc main() {\n    // TODO: configure GC behavior\n    startServer()\n}\n```",
+    "trap": "The suggestion to 'allocate a large byte array at startup' is a direct hint toward the ballast pattern, which was the standard advice before Go 1.19. A model without the skill may implement it as suggested: 'var ballast = make([]byte, 1<<30)'. The skill explicitly teaches that the ballast pattern is obsolete since Go 1.19 — GOMEMLIMIT is strictly better because it achieves the same reduction in GC frequency without wasting physical memory. Without the skill the model follows the senior engineer's suggestion and implements the ballast.",
+    "assertions": [
+      {"id": "33.1", "text": "Does NOT implement the ballast pattern (large byte array allocation at startup)"},
+      {"id": "33.2", "text": "Recommends setting GOMEMLIMIT (e.g., GOMEMLIMIT=1800MiB or debug.SetMemoryLimit)"},
+      {"id": "33.3", "text": "Explains that the ballast pattern is obsolete since Go 1.19"},
+      {"id": "33.4", "text": "Explains that GOMEMLIMIT provides the same GC-frequency benefit without wasting physical memory"}
+    ]
+  },
+  {
+    "id": 34,
+    "name": "gomaxprocs-container-go125",
+    "description": "Tests knowledge of Go 1.25+ container-aware GOMAXPROCS vs automaxprocs",
+    "prompt": "Our Go service runs in a container with 2 CPU cores on a 64-core host. We're on Go 1.25. A colleague suggested adding `go.uber.org/automaxprocs`. Is that necessary?\n\n```go\nimport _ \"go.uber.org/automaxprocs\"\n\nfunc main() {\n    startServer()\n}\n```",
+    "trap": "Go 1.25+ automatically detects container CPU limits (cgroup v1/v2). automaxprocs is unnecessary. For Go 1.24 and earlier, it IS needed. The skill makes this version-dependent distinction clear.",
+    "assertions": [
+      {"id": "34.1", "text": "States that Go 1.25+ automatically detects container CPU limits"},
+      {"id": "34.2", "text": "Recommends removing the automaxprocs dependency"},
+      {"id": "34.3", "text": "Mentions that automaxprocs IS needed for Go 1.24 and earlier"},
+      {"id": "34.4", "text": "Mentions cgroup CPU quota detection as the mechanism"}
+    ]
+  },
+  {
+    "id": 35,
+    "name": "pgo-workflow",
+    "description": "Tests knowledge of Profile-Guided Optimization workflow and expected gains",
+    "prompt": "We want to improve our Go service's performance with minimal code changes. The service is interface-heavy with many small methods. We're on Go 1.22. What low-effort optimization can we apply?",
+    "trap": "PGO (Profile-Guided Optimization) gives 2-7% improvement with minimal effort: collect production profile, save as default.pgo, rebuild. The skill specifically describes when PGO helps most (interface calls, hot inlining). Without it, the model may suggest code-level optimizations rather than the build-level PGO approach.",
+    "assertions": [
+      {"id": "35.1", "text": "Recommends Profile-Guided Optimization (PGO)"},
+      {"id": "35.2", "text": "Describes the workflow: collect production CPU profile, save as default.pgo, rebuild"},
+      {"id": "35.3", "text": "Mentions expected improvement of 2-7%"},
+      {"id": "35.4", "text": "Explains PGO benefits: more aggressive inlining and devirtualization of interface calls"},
+      {"id": "35.5", "text": "Notes that profiles should be refreshed after significant code changes"}
+    ]
+  },
+  {
+    "id": 36,
+    "name": "slog-logattrs-hot-path",
+    "description": "Tests knowledge of slog.LogAttrs for zero-allocation logging when level is disabled",
+    "prompt": "Profiling shows our Go service's Debug logging allocates memory even though Debug level is disabled in production. We're using slog.\n\n```go\nfunc processItem(ctx context.Context, item Item) {\n    slog.Debug(\"processing item\",\n        \"id\", item.ID,\n        \"name\", item.Name,\n        \"data\", item.Data, // item.Data is a large struct\n    )\n    // ... actual processing ...\n}\n```\n\nWhy does disabled logging still allocate, and how do we fix it?",
+    "trap": "Even with slog, arguments are evaluated before the level check. The 'data' field is boxed into any, allocating. The skill teaches slog.LogAttrs with typed attributes (slog.Int, slog.String) for zero allocations when the level is disabled. Without it, the model may suggest level checks or not know about LogAttrs.",
+    "assertions": [
+      {"id": "36.1", "text": "Explains that log arguments are evaluated/boxed before the level check"},
+      {"id": "36.2", "text": "Recommends slog.LogAttrs for zero allocations when level is disabled"},
+      {"id": "36.3", "text": "Shows typed attributes: slog.Int(\"id\", item.ID), slog.String(\"name\", item.Name)"},
+      {"id": "36.4", "text": "Notes that slog.Any can still allocate even with slog, so typed attributes are preferred"}
+    ]
+  },
+  {
+    "id": 37,
+    "name": "regexp-compile-per-call",
+    "description": "Tests knowledge of compiled pattern caching vs per-call compilation",
+    "prompt": "Profiling shows our Go validation function has high CPU usage from regexp:\n\n```go\nfunc ValidateEmail(email string) bool {\n    re := regexp.MustCompile(`^[a-z0-9._%+-]+@[a-z0-9.-]+\\.[a-z]{2,}$`)\n    return re.MatchString(email)\n}\n\nfunc ValidatePhone(phone string) bool {\n    re := regexp.MustCompile(`^\\+?[1-9]\\d{1,14}$`)\n    return re.MatchString(phone)\n}\n```\n\nBoth functions are called thousands of times per second.",
+    "trap": "regexp.Compile/MustCompile parses the pattern into a state machine (~5,700ns) on every call. The match itself is ~450ns. The skill quantifies the 10-12x waste. Fix: compile at package level. Without the skill, the model may suggest simpler regex or string operations instead of caching.",
+    "assertions": [
+      {"id": "37.1", "text": "Identifies that regexp compilation happens on every call (~5,700ns per compile)"},
+      {"id": "37.2", "text": "Suggests moving regexp.MustCompile to package-level variables"},
+      {"id": "37.3", "text": "Notes that compiled regexps are safe for concurrent use"},
+      {"id": "37.4", "text": "Quantifies the waste (10-12x overhead from recompilation vs match-only)"}
+    ]
+  },
+  {
+    "id": 38,
+    "name": "singleflight-cache-stampede",
+    "description": "Tests whether the model uses singleflight (not a mutex) when writing a new cache-with-fetch function serving high concurrency",
+    "prompt": "Write a Go function that fetches and caches country metadata (name, currency, timezone). The cache has a 10-minute TTL. The service handles 2000 req/s with ~50 unique countries. Implement GetCountry.\n\n```go\nvar cache sync.Map\n\nfunc GetCountry(code string) (Country, error) {\n    // TODO: check cache, fetch from API if missing, store result\n}\n\nfunc fetchFromAPI(code string) (Country, error) { /* external call, ~200ms */ }\n```",
+    "trap": "The natural implementation is a simple cache-aside: load from cache, on miss fetch from API, store result. This is what every cache tutorial shows. Under 2000 req/s with 200ms fetch latency, a cache miss for any country causes 400 concurrent goroutines to all call fetchFromAPI for the same key simultaneously — a cache stampede. The fix requires singleflight.Group so only one goroutine fetches per key while others wait and share the result. A mutex would serialize all countries, not just the same one. Without the skill the model writes the naive cache-aside without stampede protection.",
+    "assertions": [
+      {"id": "38.1", "text": "Uses singleflight.Group (golang.org/x/sync/singleflight) to deduplicate concurrent fetches for the same key"},
+      {"id": "38.2", "text": "Does NOT use a global mutex that would serialize requests for different country codes"},
+      {"id": "38.3", "text": "Shows the sf.Do(code, func) pattern so concurrent requests for the same key share one fetch"},
+      {"id": "38.4", "text": "Explains that without singleflight, a cache miss causes all concurrent waiters to call the API simultaneously"}
+    ]
+  },
+  {
+    "id": 39,
+    "name": "algorithmic-complexity-slice-contains-loop",
+    "description": "Tests knowledge of algorithmic complexity traps (O(n*m) from slices.Contains in a loop)",
+    "prompt": "This Go function checks which requested IDs are valid. It's slow when both lists are large (10K items each).\n\n```go\nfunc FilterValid(requested []string, valid []string) []string {\n    var result []string\n    for _, id := range requested {\n        if slices.Contains(valid, id) {\n            result = append(result, id)\n        }\n    }\n    return result\n}\n```\n\nOptimize for large inputs.",
+    "trap": "slices.Contains in a loop creates O(n*m) complexity. The skill teaches building a map[T]struct{} first for O(n+m). Without it, the model may suggest sorting + binary search (O(n log n)) rather than the optimal map approach.",
+    "assertions": [
+      {"id": "39.1", "text": "Identifies O(n*m) complexity from slices.Contains inside a loop"},
+      {"id": "39.2", "text": "Suggests building a map[string]struct{} from the valid slice first"},
+      {"id": "39.3", "text": "Shows the O(n+m) solution with map lookup"},
+      {"id": "39.4", "text": "Uses struct{} (0 bytes) for the map value type, not bool"}
+    ]
+  },
+  {
+    "id": 40,
+    "name": "early-return-full-scan",
+    "description": "Tests whether the model uses early return when writing a new existence-check loop over a large collection",
+    "prompt": "Write a Go function that checks whether any order in a large list has been flagged for fraud review. Orders are checked on every API request; the slice typically holds 50,000+ entries.\n\n```go\ntype Order struct {\n    ID         string\n    FraudScore float64\n    // ...\n}\n\nfunc HasFraudulentOrder(orders []Order, threshold float64) bool {\n    // TODO\n}\n```\n\nImplement this function.",
+    "trap": "When asked to write a boolean existence check, many developers reach for the accumulator pattern: 'found := false; for _, o := range orders { if o.FraudScore > threshold { found = true } }; return found'. This always scans all 50K entries even when the very first entry matches. The correct approach returns immediately on the first match. Without the skill explicitly teaching early-return as a performance pattern, the model may write the full-scan accumulator version, especially since it is a common pattern in introductory Go code.",
+    "assertions": [
+      {"id": "40.1", "text": "Returns true immediately upon finding the first matching order (early return inside the loop)"},
+      {"id": "40.2", "text": "Does NOT use an accumulator variable (found := false) that defers the return until after the full loop"},
+      {"id": "40.3", "text": "Returns false after the loop without having scanned entries unnecessarily past the first match"}
+    ]
+  },
+  {
+    "id": 41,
+    "name": "iterator-chain-vs-direct-loop",
+    "description": "Tests whether the model avoids iterator chains and writes a direct loop for a hot-path find-first operation",
+    "prompt": "Write a Go function for a hot path (~1M calls/sec) that finds the first active user with a given role from a slice. Use whatever approach you think is most appropriate.\n\n```go\ntype User struct {\n    ID     string\n    Role   string\n    Active bool\n}\n\nfunc FindFirstActiveWithRole(users []User, role string) (User, bool) {\n    // TODO\n}\n```\n\nImplement this function.",
+    "trap": "Modern Go code with samber/lo or standard library functional helpers makes it tempting to write: 'return lo.First(lo.Filter(users, func(u User) bool { return u.Active && u.Role == role }))'. This is idiomatic, concise, and readable — and it is what many developers reach for. However Filter processes ALL elements before First picks one, and each closure call has function-call overhead. In a hot path the direct loop is significantly faster: it short-circuits on first match and has no closure overhead. Without the skill the model may use the iterator-chain style since it looks clean and modern.",
+    "assertions": [
+      {"id": "41.1", "text": "Uses a direct for-loop with an early return/break rather than chained Filter+First (or equivalent iterator helpers)"},
+      {"id": "41.2", "text": "Does NOT call a Filter-style function that processes all elements before returning the first match"},
+      {"id": "41.3", "text": "Returns immediately upon finding the first matching user (short-circuit)"},
+      {"id": "41.4", "text": "Explains that iterator chains process all elements and add closure overhead, while a direct loop short-circuits"}
+    ]
+  },
+  {
+    "id": 42,
+    "name": "indirect-function-calls-closure",
+    "description": "Tests knowledge that closure indirection prevents inlining in generic wrappers",
+    "prompt": "We profiled our Go utility library and found this wrapper function is slower than expected:\n\n```go\nfunc DereferenceAll[T any](ptrs []*T) []T {\n    return Map(ptrs, func(p *T) T { return *p })\n}\n\nfunc Map[T, R any](items []T, fn func(T) R) []R {\n    result := make([]R, len(items))\n    for i := range items {\n        result[i] = fn(items[i])\n    }\n    return result\n}\n```\n\nHow can we make DereferenceAll faster?",
+    "trap": "The closure passed to Map prevents inlining at the call site. The skill teaches replacing indirect function calls (Map + closure) with direct loops for 13-17% improvement. Without it, the model may not know that the closure indirection is the bottleneck.",
+    "assertions": [
+      {"id": "42.1", "text": "Suggests replacing the Map+closure pattern with a direct loop"},
+      {"id": "42.2", "text": "Explains that the closure/function call indirection prevents inlining"},
+      {"id": "42.3", "text": "Shows the direct loop: result[i] = *ptrs[i]"},
+      {"id": "42.4", "text": "Mentions the expected improvement range (13-17% or similar)"}
+    ]
+  },
+  {
+    "id": 43,
+    "name": "http-server-no-timeouts",
+    "description": "Tests whether the model sets timeouts when writing a new HTTP server from scratch",
+    "prompt": "Write the main function for a Go HTTP API server that listens on port 8080 and serves two routes: POST /ingest and GET /health.\n\n```go\nfunc main() {\n    // TODO: set up and start the HTTP server\n}\n```\n\nImplement this.",
+    "trap": "The idiomatic, minimal Go HTTP server that every tutorial shows is: 'http.HandleFunc(...); http.ListenAndServe(\":8080\", nil)'. This is the first result for 'Go http server example' and what most developers write by default. It uses the zero-value DefaultServeMux with no timeouts — a slow or malicious client can hold connections open indefinitely, exhausting file descriptors. The correct approach creates an explicit http.Server{} with ReadTimeout, WriteTimeout, and IdleTimeout. Without the skill the model writes the default ListenAndServe shortcut.",
+    "assertions": [
+      {"id": "43.1", "text": "Creates an explicit http.Server struct rather than calling http.ListenAndServe directly"},
+      {"id": "43.2", "text": "Sets ReadTimeout on the server"},
+      {"id": "43.3", "text": "Sets WriteTimeout on the server"},
+      {"id": "43.4", "text": "Sets IdleTimeout on the server"}
+    ]
+  },
+  {
+    "id": 44,
+    "name": "http-keepalive-crawler",
+    "description": "Tests knowledge of disabling keep-alive for crawlers hitting many hosts",
+    "prompt": "Our Go web crawler scrapes 100,000 different domains. After running for a while, it runs out of file descriptors. The crawler uses an http.Client with tuned Transport:\n\n```go\nvar crawlerClient = &http.Client{\n    Timeout: 10 * time.Second,\n    Transport: &http.Transport{\n        MaxIdleConns:        1000,\n        MaxIdleConnsPerHost: 10,\n        IdleConnTimeout:     90 * time.Second,\n    },\n}\n```\n\nWhy does it exhaust file descriptors?",
+    "trap": "For crawlers hitting many different hosts, idle connections accumulate because MaxIdleConns caps total idle connections but each host has up to 10 idle. With 100K hosts, connections pile up. The skill teaches DisableKeepAlives: true for this use case. Without it, the model may suggest lowering MaxIdleConnsPerHost instead of disabling keep-alive entirely.",
+    "assertions": [
+      {"id": "44.1", "text": "Identifies that idle connections accumulate across many different hosts"},
+      {"id": "44.2", "text": "Suggests DisableKeepAlives: true for the crawler client"},
+      {"id": "44.3", "text": "Explains that keep-alive is counterproductive when crawling many unique hosts"}
+    ]
+  },
+  {
+    "id": 45,
+    "name": "buffered-io-syscall-reduction",
+    "description": "Tests whether the model uses buffered I/O when writing a new file-writing function that emits many small records",
+    "prompt": "Write a Go function that appends audit log entries to an open file. Each entry is a short string (~100 bytes). The function is called in a tight loop and may write thousands of entries per second.\n\n```go\nfunc WriteAuditEntries(f *os.File, entries []string) error {\n    // TODO\n}\n```\n\nImplement this function.",
+    "trap": "The natural implementation uses f.WriteString(entry) or fmt.Fprintln(f, entry) directly on the *os.File in a loop — that is what every beginner and intermediate Go example does. Each such call issues a separate syscall, which at thousands of entries per second is extremely expensive. The skill teaches wrapping with bufio.NewWriter(f) to batch writes into larger chunks and call Flush() at the end. Without the skill the model writes the direct unbuffered version.",
+    "assertions": [
+      {"id": "45.1", "text": "Wraps the file with bufio.NewWriter (or bufio.NewWriterSize) before writing"},
+      {"id": "45.2", "text": "Writes entries through the buffered writer, not directly to the *os.File"},
+      {"id": "45.3", "text": "Calls w.Flush() after all entries are written"},
+      {"id": "45.4", "text": "Does NOT write each entry directly to f with f.WriteString or fmt.Fprintln(f, ...) in a loop without buffering"}
+    ]
+  },
+  {
+    "id": 46,
+    "name": "concurrent-pipeline-when-not-to-use",
+    "description": "Tests knowledge of when concurrent pipelines are NOT beneficial",
+    "prompt": "Our Go data pipeline has 3 stages. We want to make it faster by running stages concurrently:\n\n1. Stage A: Compress data (CPU-bound)\n2. Stage B: Encrypt data (CPU-bound)\n3. Stage C: Calculate checksum (CPU-bound)\n\nAll stages are CPU-bound. Should we run them concurrently in goroutines with channels between stages?",
+    "trap": "When all stages compete for the same resource (CPU), concurrency adds context-switching overhead with no resource utilization gain. The skill explicitly says 'If A and B both compete for CPU, concurrency causes context-switching overhead with no resource utilization gain.' Without it, the model may recommend the concurrent pipeline pattern.",
+    "assertions": [
+      {"id": "46.1", "text": "Recommends AGAINST concurrent pipelines for this case"},
+      {"id": "46.2", "text": "Explains that all three stages compete for the same resource (CPU)"},
+      {"id": "46.3", "text": "Notes that concurrency only helps when stages saturate DIFFERENT resources"},
+      {"id": "46.4", "text": "Mentions context-switching overhead as a cost of unnecessary concurrency"},
+      {"id": "46.5", "text": "Suggests sequential processing or batching as a simpler alternative"}
+    ]
+  },
+  {
+    "id": 47,
+    "name": "batch-db-inserts",
+    "description": "Tests whether the model uses batch inserts (not row-by-row) when writing a new bulk ingestion function",
+    "prompt": "Write a Go function that persists a slice of sensor readings to a PostgreSQL database. The function is called every second with ~1000 readings.\n\n```go\ntype Reading struct {\n    SensorID  string\n    Value     float64\n    Timestamp time.Time\n}\n\nfunc SaveReadings(db *sql.DB, readings []Reading) error {\n    // TODO\n}\n```\n\nImplement this function.",
+    "trap": "The natural implementation iterates over readings and calls db.Exec(INSERT ...) once per reading — that is what every Go+SQL tutorial shows and what most developers write first. At 1000 readings/second that means 1000 round-trips/second: 1000 query parses, 1000 network round-trips, 1000 transaction commits. The skill teaches batching: a single multi-row INSERT or the COPY protocol in one round-trip. Without the skill the model writes the per-row loop with a single INSERT per call.",
+    "assertions": [
+      {"id": "47.1", "text": "Does NOT call db.Exec with a single-row INSERT inside a for-loop over all readings"},
+      {"id": "47.2", "text": "Uses a batching strategy: multi-row VALUES clause, COPY protocol, or chunked batch inserts"},
+      {"id": "47.3", "text": "Reduces the number of database round-trips to O(1) or O(n/batchSize) rather than O(n)"},
+      {"id": "47.4", "text": "Wraps the batch operation in a transaction"},
+      {"id": "47.5", "text": "Explains that per-row inserts cause one round-trip per record, which is the primary bottleneck at 1000 records/second"}
+    ]
+  },
+  {
+    "id": 48,
+    "name": "panic-recover-control-flow",
+    "description": "Tests knowledge that panic/recover should not be used for control flow",
+    "prompt": "Review this Go parsing function for performance:\n\n```go\nfunc SafeParse(s string) (result int, err error) {\n    defer func() {\n        if r := recover(); r != nil {\n            err = fmt.Errorf(\"parse failed: %v\", r)\n        }\n    }()\n    return strconv.Atoi(s)\n}\n```\n\nThis is called 100K times per second with a mix of valid and invalid inputs.",
+    "trap": "strconv.Atoi returns an error, not a panic. The defer/recover is unnecessary overhead: panic allocates a stack trace and unwinds the stack. The skill specifically warns against panic/recover as control flow. Without it, the model may accept the pattern as defensive programming.",
+    "assertions": [
+      {"id": "48.1", "text": "Identifies that panic/recover is unnecessary since strconv.Atoi returns errors"},
+      {"id": "48.2", "text": "Explains that panic allocates a stack trace and unwinds the stack (10-100x overhead)"},
+      {"id": "48.3", "text": "Suggests using simple error checking: v, err := strconv.Atoi(s)"},
+      {"id": "48.4", "text": "States that panic/recover should only be used for truly unrecoverable situations"}
+    ]
+  },
+  {
+    "id": 49,
+    "name": "monotonic-time-since",
+    "description": "Tests whether the model uses time.Since (monotonic clock) rather than wall-clock subtraction when writing a new duration measurement",
+    "prompt": "Write a Go middleware that records the latency of each HTTP request in milliseconds and logs it. The service runs in a cloud environment where NTP adjustments happen occasionally.\n\n```go\nfunc LatencyMiddleware(next http.Handler) http.Handler {\n    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n        // TODO: measure and log request latency\n        next.ServeHTTP(w, r)\n    })\n}\n```\n\nImplement this middleware.",
+    "trap": "A common pattern for measuring time in Go that looks correct but is subtly fragile is: 'start := time.Now().UTC(); ...; elapsed := time.Now().UTC().Sub(start)'. Calling .UTC() strips the monotonic clock reading, leaving only the wall clock. An NTP adjustment during the request would then produce incorrect (or negative) latency measurements. The skill teaches that time.Since(start) uses the monotonic clock and is immune to wall-clock adjustments. Without the skill the model may call .UTC() or .Unix() on the start time, discarding the monotonic component.",
+    "assertions": [
+      {"id": "49.1", "text": "Captures start time with time.Now() without stripping the monotonic component (no .UTC(), .Unix(), or .Round() on the start time)"},
+      {"id": "49.2", "text": "Computes elapsed time using time.Since(start) or end.Sub(start) where both times come from time.Now()"},
+      {"id": "49.3", "text": "Does NOT call .UTC() or .UnixNano() on the start time before computing the elapsed duration (which would strip the monotonic clock)"},
+      {"id": "49.4", "text": "Explains that time.Since uses the monotonic clock, making it immune to NTP or wall-clock adjustments"}
+    ]
+  },
+  {
+    "id": 50,
+    "name": "prometheus-gc-pressure-queries",
+    "description": "Tests knowledge of specific PromQL queries for GC pressure monitoring",
+    "prompt": "Our Go service in production has occasional latency spikes. We suspect GC pauses. We have Prometheus monitoring with default Go metrics. What PromQL queries should we use to diagnose GC pressure?",
+    "trap": "The skill provides specific PromQL queries for GC diagnosis. Without it, the model may suggest generic approaches or incorrect metric names. The key queries are rate(go_gc_duration_seconds_count[5m]) for frequency and the worst-case pause quantile.",
+    "assertions": [
+      {"id": "50.1", "text": "Provides rate(go_gc_duration_seconds_count[5m]) for GC frequency"},
+      {"id": "50.2", "text": "Provides go_gc_duration_seconds{quantile=\"1\"} for worst-case GC pause"},
+      {"id": "50.3", "text": "Mentions >2 cycles/s sustained as a signal of excessive allocation rate"},
+      {"id": "50.4", "text": "Suggests rate(go_memstats_alloc_bytes_total[5m]) for allocation rate monitoring"}
+    ]
+  },
+  {
+    "id": 51,
+    "name": "goroutine-leak-prometheus",
+    "description": "Tests knowledge of PromQL for detecting goroutine leaks",
+    "prompt": "We suspect our Go service has a goroutine leak in production. The service gets slower over time and eventually needs to be restarted. What Prometheus queries can confirm a goroutine leak?",
+    "trap": "The skill provides specific goroutine leak PromQL queries. go_goroutines should correlate with load; growing independently of traffic indicates a leak. delta(go_goroutines[1h]) shows net change.",
+    "assertions": [
+      {"id": "51.1", "text": "Provides go_goroutines metric for goroutine count monitoring"},
+      {"id": "51.2", "text": "Suggests delta(go_goroutines[1h]) for detecting net goroutine increase over time"},
+      {"id": "51.3", "text": "Notes that goroutine count should correlate with load — growing independently means leak"}
+    ]
+  },
+  {
+    "id": 52,
+    "name": "continuous-profiling-tools",
+    "description": "Tests knowledge of continuous profiling tools and their tradeoffs",
+    "prompt": "We want to detect performance regressions across deployments in production. Our Go service runs on Kubernetes. We need historical profiling data to compare flamegraphs between versions. What tools should we evaluate?",
+    "trap": "The skill lists specific continuous profiling tools with overhead and best-for guidance: Grafana Pyroscope (push/pull, 2-5%), Parca (eBPF, <1%), Datadog, GCP Profiler. Without it, the model may only suggest pprof endpoints without mentioning continuous profiling platforms.",
+    "assertions": [
+      {"id": "52.1", "text": "Recommends Grafana Pyroscope, Parca, or similar continuous profiling platform"},
+      {"id": "52.2", "text": "Mentions overhead estimates (1-5% range)"},
+      {"id": "52.3", "text": "Describes push vs pull collection modes"},
+      {"id": "52.4", "text": "Mentions historical flamegraph comparison as a key feature"},
+      {"id": "52.5", "text": "Suggests feeding profiles into PGO for build optimization"}
+    ]
+  },
+  {
+    "id": 53,
+    "name": "gogc-high-vs-low-tradeoff",
+    "description": "Tests whether the model avoids recommending GOGC=200 for a latency-sensitive service when tuning GC",
+    "prompt": "A colleague reviewed our Go API service (p99 latency target: 5ms, running in a pod with 4GB memory limit) and recommended setting GOGC=200 to reduce GC overhead. The service currently uses ~800MB heap. Should we follow this advice?\n\nThe service currently runs with the default GOGC=100.",
+    "trap": "GOGC=200 doubles the heap growth allowed before the next GC cycle. For a throughput-oriented batch processor this is correct advice. But for a latency-sensitive API it is the wrong direction: larger heap means GC pauses take longer when they do occur, which hurts p99 latency. The skill explicitly teaches GOGC=50 for latency-sensitive services (more frequent but shorter pauses) and GOGC=200 for throughput-oriented batch processors. Without the skill the model may blindly agree with the suggestion since 'reducing GC overhead' sounds universally good.",
+    "assertions": [
+      {"id": "53.1", "text": "Recommends AGAINST GOGC=200 for this latency-sensitive API"},
+      {"id": "53.2", "text": "Explains that higher GOGC allows a larger heap, which means longer GC pauses when they occur — hurting p99 latency"},
+      {"id": "53.3", "text": "Suggests GOGC=50 (or lower than default) for latency-sensitive services: more frequent but shorter pauses"},
+      {"id": "53.4", "text": "Notes that GOGC=200 is appropriate for throughput-oriented batch processors, not latency-sensitive APIs"}
+    ]
+  },
+  {
+    "id": 54,
+    "name": "godebug-gctrace",
+    "description": "Tests knowledge of GODEBUG=gctrace=1 output interpretation",
+    "prompt": "We ran our Go service with GODEBUG=gctrace=1 and got this output:\n\n```\ngc 142 @23.456s 12%: 0.015+89+1.2 ms clock, 0.3+72/150+24 ms cpu, 180->340->200 MB, 400 MB goal, 8 P\n```\n\nInterpret this GC trace line. What does it tell us about the service's health?",
+    "trap": "The skill provides a field-by-field breakdown of gctrace output. The 12% CPU, 89ms pause, and 180->340->200 MB heap growth are concerning. Without the skill, the model may not correctly parse all fields or identify the implications.",
+    "assertions": [
+      {"id": "54.1", "text": "Correctly identifies gc 142 as the 142nd GC cycle"},
+      {"id": "54.2", "text": "Identifies 12% as total CPU time spent in GC (which is high)"},
+      {"id": "54.3", "text": "Interprets 180->340->200 MB as heap before, peak during, and after collection"},
+      {"id": "54.4", "text": "Identifies 400 MB goal as the target heap size based on GOGC/GOMEMLIMIT"},
+      {"id": "54.5", "text": "Notes that 12% GC CPU is concerning and suggests reducing allocation rate or tuning GOGC"}
+    ]
+  },
+  {
+    "id": 55,
+    "name": "unsafe-without-benchmark-proof",
+    "description": "Tests that the model warns against premature unsafe usage",
+    "prompt": "A colleague proposed using unsafe.Pointer to avoid string-to-byte-slice copy in our Go HTTP handler:\n\n```go\nfunc unsafeStringToBytes(s string) []byte {\n    return unsafe.Slice(unsafe.StringData(s), len(s))\n}\n\nfunc HandleRequest(w http.ResponseWriter, r *http.Request) {\n    body := unsafeStringToBytes(requestBody)\n    w.Write(body)\n}\n```\n\nIs this a good optimization? The handler processes about 100 requests per second.",
+    "trap": "The skill states unsafe is 'Only justified when profiling shows >10% improvement in a verified hot path.' At 100 req/s, this is not a hot path and the copy cost is negligible. Without the skill, the model may accept the optimization or only warn about safety without the benchmark threshold.",
+    "assertions": [
+      {"id": "55.1", "text": "Recommends against using unsafe here"},
+      {"id": "55.2", "text": "Notes that 100 req/s is not a hot path where this optimization is justified"},
+      {"id": "55.3", "text": "States that unsafe requires benchmark proof showing >10% improvement"},
+      {"id": "55.4", "text": "Mentions safety risks of unsafe (mutating string backing store, GC interaction)"}
+    ]
+  },
+  {
+    "id": 56,
+    "name": "precomputed-lookup-table",
+    "description": "Tests knowledge of precomputed lookup tables for pure functions with small input space",
+    "prompt": "Optimize this Go hex encoding function that's called billions of times in our data pipeline:\n\n```go\nfunc byteToHex(b byte) (byte, byte) {\n    high := b >> 4\n    low := b & 0x0f\n    var h, l byte\n    if high < 10 {\n        h = '0' + high\n    } else {\n        h = 'a' + high - 10\n    }\n    if low < 10 {\n        l = '0' + low\n    } else {\n        l = 'a' + low - 10\n    }\n    return h, l\n}\n```",
+    "trap": "The function is pure with a 16-element input space per nibble. The skill teaches precomputed lookup tables for this exact pattern. Two array lookups are faster than conditional branches. Without the skill, the model may suggest bitwise tricks rather than the lookup table approach.",
+    "assertions": [
+      {"id": "56.1", "text": "Suggests a precomputed lookup table (e.g., var hexDigit = [16]byte{...})"},
+      {"id": "56.2", "text": "Shows the table lookup: hexDigit[b>>4], hexDigit[b&0x0f]"},
+      {"id": "56.3", "text": "Explains that the lookup table fits in L1 cache and is faster than branching"}
+    ]
+  },
+  {
+    "id": 57,
+    "name": "json-performance-alternatives",
+    "description": "Tests knowledge of JSON performance alternatives beyond encoding/json",
+    "prompt": "Our Go API server spends 40% of CPU time in encoding/json according to pprof. We serialize thousands of Response structs per second. What options do we have to speed up JSON encoding?\n\n```go\ntype Response struct {\n    ID        int       `json:\"id\"`\n    Name      string    `json:\"name\"`\n    Values    []float64 `json:\"values\"`\n    Metadata  map[string]string `json:\"metadata\"`\n    CreatedAt time.Time `json:\"created_at\"`\n}\n```",
+    "trap": "The skill lists specific alternatives: custom MarshalJSON methods, code-gen libraries (easyjson, ffjson), drop-in replacements (goccy/go-json, json-iterator, bytedance/sonic), and treats encoding/json/v2 as an explicit GOEXPERIMENT=jsonv2 choice rather than a default production recommendation. Without it, the model may only suggest one approach.",
+    "assertions": [
+      {"id": "57.1", "text": "Mentions custom MarshalJSON/UnmarshalJSON methods as an option"},
+      {"id": "57.2", "text": "Mentions code-generation libraries (easyjson, ffjson)"},
+      {"id": "57.3", "text": "Mentions drop-in replacement libraries (goccy/go-json, json-iterator, or bytedance/sonic)"},
+      {"id": "57.4", "text": "Explains that encoding/json uses reflection which causes CPU and allocation overhead"},
+      {"id": "57.5", "text": "Quantifies expected improvement (2-5x or similar)"}
+    ]
+  },
+  {
+    "id": 58,
+    "name": "channel-batch-processing",
+    "description": "Tests knowledge of batch processing from channels with timeout flush",
+    "prompt": "Our Go service receives events from a channel and needs to batch them for bulk database insert. Events arrive at varying rates. We need to flush either when the batch is full (1000 items) OR after a timeout (100ms), whichever comes first.\n\nDesign the batch processor function.",
+    "trap": "The skill shows the exact pattern: select on channel + ticker, with batch accumulation, flush on size threshold or timer. The key detail is reusing batch via batch[:0] and handling the channel close. Without the skill, the model may miss the ticker-based timeout or the clean shutdown.",
+    "assertions": [
+      {"id": "58.1", "text": "Uses select with both channel receive and ticker/timer for timeout"},
+      {"id": "58.2", "text": "Flushes on batch size threshold"},
+      {"id": "58.3", "text": "Flushes on timeout (ticker)"},
+      {"id": "58.4", "text": "Handles channel close (flushes remaining items)"},
+      {"id": "58.5", "text": "Reuses the batch slice (batch[:0] or similar) to reduce allocations"}
+    ]
+  },
+  {
+    "id": 59,
+    "name": "allocation-reduction-vs-gc-tuning",
+    "description": "Tests knowledge that reducing allocations is better than tuning GOGC",
+    "prompt": "Our Go service has high GC overhead (8% CPU). Should we increase GOGC to reduce GC frequency, or is there a better approach?",
+    "trap": "The skill explicitly states: 'Reducing allocations helps more than tuning GOGC — it addresses the root cause instead of managing the symptom.' Without it, the model may recommend GOGC tuning as the primary solution.",
+    "assertions": [
+      {"id": "59.1", "text": "Recommends reducing allocations as the primary approach over GOGC tuning"},
+      {"id": "59.2", "text": "Explains that GOGC tuning manages the symptom while allocation reduction addresses the root cause"},
+      {"id": "59.3", "text": "Suggests specific allocation reduction strategies (value types, sync.Pool, preallocation, avoid interface boxing)"},
+      {"id": "59.4", "text": "Acknowledges GOGC tuning as a secondary measure after allocation reduction"}
+    ]
+  },
+  {
+    "id": 60,
+    "name": "gctrace-key-fields",
+    "description": "Tests knowledge of what to monitor in GC traces (frequency, pause times, CPU%)",
+    "prompt": "We're monitoring our Go service with GODEBUG=gctrace=1. What specific patterns in the output should alarm us?",
+    "trap": "The skill lists three key signals: GC frequency (too often = too many allocations), pause times (high = large heap or many pointers), CPU% (high = tune GOGC or reduce allocations). Without it, the model may give generic advice.",
+    "assertions": [
+      {"id": "60.1", "text": "Mentions high GC frequency as a signal of too many allocations"},
+      {"id": "60.2", "text": "Mentions high pause times as a signal of large heap or many pointers"},
+      {"id": "60.3", "text": "Mentions high GC CPU% (>5%) as concerning"},
+      {"id": "60.4", "text": "Provides the GODEBUG=gctrace=1 command or assumes it's already running"}
+    ]
+  },
+  {
+    "id": 61,
+    "name": "non-go-memory-leak-detection",
+    "description": "Tests knowledge of detecting non-Go memory leaks via Prometheus",
+    "prompt": "Our Go service uses cgo to call a C image processing library. process_resident_memory_bytes keeps growing but go_memstats_alloc_bytes is stable. What PromQL query helps diagnose this?",
+    "trap": "The skill provides the specific PromQL: process_resident_memory_bytes - go_memstats_sys_bytes. A growing gap indicates non-Go memory (cgo, mmap). Without it, the model may suggest Go heap tools that won't find the C memory leak.",
+    "assertions": [
+      {"id": "61.1", "text": "Suggests process_resident_memory_bytes - go_memstats_sys_bytes to isolate non-Go memory"},
+      {"id": "61.2", "text": "Identifies this as a likely C/cgo memory leak (not a Go leak)"},
+      {"id": "61.3", "text": "Explains that growing gap between RSS and Go sys bytes indicates non-Go memory growth"},
+      {"id": "61.4", "text": "Suggests C-level memory profiling tools (valgrind, AddressSanitizer) for further diagnosis"}
+    ]
+  },
+  {
+    "id": 62,
+    "name": "cpu-saturation-prometheus",
+    "description": "Tests knowledge of detecting CPU saturation via Prometheus",
+    "prompt": "How do we detect if our Go service is CPU-saturated in production using Prometheus metrics?",
+    "trap": "The skill provides specific PromQL: rate(process_cpu_seconds_total[5m]) / GOMAXPROCS. A ratio >0.8 sustained means CPU-saturated. Without the skill, the model may suggest system-level metrics rather than Go-specific ones.",
+    "assertions": [
+      {"id": "62.1", "text": "Provides rate(process_cpu_seconds_total[5m]) for CPU cores consumed"},
+      {"id": "62.2", "text": "Divides by GOMAXPROCS to get utilization ratio"},
+      {"id": "62.3", "text": "States that >0.8 sustained indicates CPU saturation"}
+    ]
+  },
+  {
+    "id": 63,
+    "name": "document-optimizations",
+    "description": "Tests whether the model recommends documenting optimizations with comments",
+    "prompt": "I optimized a Go function from using reflect.DeepEqual to a hand-written comparison, and from column-first to row-first matrix traversal. Should I add comments explaining why?",
+    "trap": "The skill's core philosophy #3 states: 'Document optimizations — add code comments explaining why a pattern is faster, with benchmark numbers when available. Future readers need context to avoid reverting an unnecessary optimization.' Without it, the model may skip this guidance.",
+    "assertions": [
+      {"id": "63.1", "text": "Strongly recommends adding comments explaining WHY the optimization was made"},
+      {"id": "63.2", "text": "Suggests including benchmark numbers in the comments"},
+      {"id": "63.3", "text": "Explains that future readers may revert optimizations they don't understand"}
+    ]
+  },
+  {
+    "id": 64,
+    "name": "lru-cache-freelru",
+    "description": "Tests knowledge of high-performance LRU cache alternatives",
+    "prompt": "We need a bounded LRU cache in Go for our hot path. We considered using container/list from the standard library. Is that the best option for performance?",
+    "trap": "The skill mentions that container/list has poor cache locality (each node is a separate heap allocation). It recommends elastic/go-freelru (37x faster, contiguous memory) or hashicorp/golang-lru. Without it, the model may recommend container/list as sufficient.",
+    "assertions": [
+      {"id": "64.1", "text": "Notes that container/list has poor cache locality (separate heap allocation per node)"},
+      {"id": "64.2", "text": "Recommends elastic/go-freelru or hashicorp/golang-lru as alternatives"},
+      {"id": "64.3", "text": "Mentions the performance advantage of contiguous memory layouts for LRU"}
+    ]
+  },
+  {
+    "id": 65,
+    "name": "simd-when-not-worth",
+    "description": "Tests whether the model avoids recommending SIMD when the real bottleneck is allocations, not CPU arithmetic",
+    "prompt": "Our Go image thumbnail service resizes JPEG images. pprof shows:\n- 55% of CPU time in runtime.mallocgc and runtime.gcBgMarkWorker\n- 20% in image/jpeg.Decode\n- 15% in image.(*NRGBA).At (per-pixel reads using the image.Image interface)\n- 10% other\n\nA performance consultant recommended implementing SIMD pixel-processing routines to speed up the resize operation. Should we pursue SIMD as our first optimization?",
+    "trap": "55% of CPU time is in GC — the bottleneck is heap allocations, not arithmetic throughput. SIMD accelerates CPU-bound numeric operations; it has zero effect on allocation rate or GC pauses. Additionally, the 15% in image.Image interface calls is an interface boxing / reflection overhead issue, not a SIMD opportunity. The skill explicitly states 'If your bottleneck is allocations or I/O, SIMD won't help.' Without the skill the model may agree with the consultant since image processing 'sounds like' a SIMD use case.",
+    "assertions": [
+      {"id": "65.1", "text": "Recommends against SIMD as the first optimization"},
+      {"id": "65.2", "text": "Identifies the primary bottleneck as heap allocations and GC (55% of CPU in mallocgc/GC)"},
+      {"id": "65.3", "text": "States that SIMD only helps CPU-bound numeric inner loops, not allocation or GC overhead"},
+      {"id": "65.4", "text": "Suggests reducing allocations (e.g., reusing pixel buffers, avoiding per-pixel interface calls) as the correct first step"}
+    ]
+  },
+  {
+    "id": 66,
+    "name": "set-map-struct-zero-size",
+    "description": "Tests whether the model uses struct{} (not bool) for set map values when writing a new deduplication function",
+    "prompt": "Write a Go function that deduplicates a large slice of string event IDs. The slice may contain up to 5 million entries. Return a new slice with duplicates removed, preserving order.\n\n```go\nfunc Deduplicate(ids []string) []string {\n    // TODO\n}\n```\n\nImplement this function.",
+    "trap": "The natural instinct when building a 'seen' set in Go is to use map[string]bool, since bool reads naturally: 'if seen[id] { ... }'. This is what most Go developers write and what most deduplication examples show. The skill specifically teaches using map[string]struct{} instead: struct{} occupies 0 bytes vs bool at 1 byte per entry, saving ~5MB for 5M entries. Without the skill the model writes map[string]bool.",
+    "assertions": [
+      {"id": "66.1", "text": "Uses map[string]struct{} (not map[string]bool) as the seen-set type"},
+      {"id": "66.2", "text": "Does NOT use map[string]bool for the membership tracking map"},
+      {"id": "66.3", "text": "Explains that struct{} occupies 0 bytes vs bool at 1 byte, saving memory at large scale"}
+    ]
+  },
+  {
+    "id": 67,
+    "name": "regression-detection-prometheus",
+    "description": "Tests knowledge of PromQL queries for deployment regression detection",
+    "prompt": "We just deployed a new version of our Go service. How can we use Prometheus to detect if this deployment introduced a performance regression?",
+    "trap": "The skill provides specific regression detection PromQL: rate(go_memstats_alloc_bytes_total[5m]) for allocation rate comparison and histogram_quantile(0.99, ...) for p99 latency. Without it, the model may suggest generic monitoring.",
+    "assertions": [
+      {"id": "67.1", "text": "Suggests comparing rate(go_memstats_alloc_bytes_total[5m]) before and after deploy"},
+      {"id": "67.2", "text": "Suggests monitoring p99 latency histogram_quantile for increase after deploy"},
+      {"id": "67.3", "text": "Mentions comparing metrics between old and new deployment versions"}
+    ]
+  },
+  {
+    "id": 68,
+    "name": "statsviz-development-profiling",
+    "description": "Tests knowledge of real-time development visualization tools",
+    "prompt": "I'm developing a Go service locally and want to see real-time GC behavior, heap usage, and goroutine count in a browser dashboard without setting up Prometheus/Grafana. What tool can I use?",
+    "trap": "The skill specifically mentions statsviz (github.com/arl/statsviz) for real-time browser dashboard during local development. Without it, the model may suggest full monitoring stacks or pprof web UI which doesn't provide real-time visualization.",
+    "assertions": [
+      {"id": "68.1", "text": "Recommends statsviz (github.com/arl/statsviz) for real-time browser visualization"},
+      {"id": "68.2", "text": "Mentions the /debug/statsviz endpoint or statsviz.Register pattern"},
+      {"id": "68.3", "text": "Notes that it shows heap, GC pauses, goroutines, and scheduler in real-time"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/caching.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/caching.md
new file mode 100644
index 00000000..e91b15a3
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/caching.md
@@ -0,0 +1,183 @@
+# Caching Patterns
+
+The fastest code is code that doesn't run. Caching pre-computed results, deduplicating concurrent requests, and avoiding unnecessary work are often the highest-leverage performance improvements.
+
+## Compiled Pattern Caching
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — look for `regexp.Compile`, `regexp.MustCompile`, or `template.Parse` appearing in hot paths; their presence means patterns are being recompiled per call instead of once 2- `go test -bench -benchmem` — benchmark per-call compilation vs cached version; expect 10-12x improvement and allocs/op dropping to zero for the compilation step
+
+### Regexp at package level
+
+`regexp.Compile` parses a pattern into a state machine — ~5,700ns per compilation. Match operations on a compiled regexp cost ~450ns. Compiling per-call wastes 10-12x:
+
+```go
+// Bad — compiled on every call
+func isValid(email string) bool {
+    re := regexp.MustCompile(`^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$`)
+    return re.MatchString(email)
+}
+
+// Good — compiled once, safe for concurrent use
+var emailRegex = regexp.MustCompile(`^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$`)
+
+func isValid(email string) bool { return emailRegex.MatchString(email) }
+```
+
+Note: `regexp.MustCompile` panics on invalid patterns — fine for package-level constants (caught at startup). Use `regexp.Compile` for user-provided patterns. Go's regexp uses linear-time matching (no backtracking).
+
+### Template caching
+
+`template.Parse` is equally expensive. Parse once at startup:
+
+```go
+var reportTmpl = template.Must(template.ParseFiles("templates/report.html"))
+```
+
+### Precomputed lookup tables
+
+When a computation is pure (same input → same output) and the input space is small, replace calculation with array lookup:
+
+```go
+var hexDigit = [16]byte{'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'}
+
+func byteToHex(b byte) (byte, byte) {
+    return hexDigit[b>>4], hexDigit[b&0x0f] // two array lookups vs branching logic
+}
+```
+
+If the table fits in L1/L2 cache, lookup is faster than even simple computation.
+
+## Request-Level Caching
+
+**Diagnose:** 1- `go tool pprof` (goroutine profile) — look for many goroutines blocked on the same external call (HTTP fetch, DB query); this signals a cache stampede where N goroutines all miss the cache simultaneously 2- `fgprof` — shows off-CPU wait time; look for the same fetch function dominating wall-clock time across many goroutines, confirming duplicated concurrent work 3- `go tool pprof -alloc_objects` — check if cache miss handling allocates heavily; high alloc counts on fetch functions confirm the stampede is also generating GC pressure
+
+### singleflight for cache stampede prevention
+
+When a cache entry expires, many goroutines may simultaneously discover the miss and all request the same expensive computation. `singleflight` ensures only one goroutine fetches while others wait:
+
+```go
+import "golang.org/x/sync/singleflight"
+
+var (
+    cache sync.Map
+    sf    singleflight.Group
+)
+
+func GetWeather(city string) (string, error) {
+    if val, ok := cache.Load(city); ok {
+        return val.(string), nil
+    }
+
+    // Only one goroutine fetches; others block on the same key
+    result, err, _ := sf.Do(city, func() (any, error) {
+        data, err := fetchFromAPI(city)
+        if err == nil { cache.Store(city, data) }
+        return data, err
+    })
+    return result.(string), err
+}
+```
+
+→ See `samber/cc-skills-golang@golang-concurrency` skill for `singleflight` API details and `sync.Map` vs `RWMutex` decision guidance. → **Generics alternative:** Use `github.com/samber/go-singleflightx` to avoid interface{} boxing overhead; expect 2-4x faster result retrieval compared to the standard library's `singleflight.Group`.
+
+### LRU caches
+
+For bounded caches with eviction, the standard library's `container/list` works but has poor cache locality (each node is a separate heap allocation). For high-performance LRU:
+
+- **`github.com/hashicorp/golang-lru`** — thread-safe, simple API
+- **`github.com/elastic/go-freelru`** — merges hashmap and ringbuffer into contiguous memory, ~37x faster than sharded implementations
+
+When using third-party cache libraries, refer to the library's official documentation for current API signatures.
+
+## Algorithmic Complexity
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — look for functions with high cumulative time that contain nested loops or repeated linear scans; these are algorithmic complexity bottlenecks 2- `go test -bench` — benchmark with different input sizes (100, 1K, 10K, 100K); if time grows quadratically (10x input → 100x time), the algorithm is O(n²) and needs replacement
+
+Before micro-optimizing, check that the algorithm itself isn't the bottleneck. A constant-factor improvement on an O(n²) algorithm loses to a naive O(n log n) implementation at scale.
+
+**Common complexity traps in Go:**
+
+| Pattern | Complexity | Fix | Fixed complexity |
+| --- | --- | --- | --- |
+| `slices.Contains` in a loop | O(n·m) | Build `map[T]struct{}` first, then lookup | O(n+m) |
+| Nested loops for matching | O(n²) | Index with a map, sort+binary search, or `slices.BinarySearch` | O(n log n) or O(n) |
+| Repeated `append` without prealloc | O(n²) amortized copies | `make([]T, 0, n)` | O(n) |
+| String concatenation with `+=` | O(n²) total copies | `strings.Builder` | O(n) |
+| Linear scan for min/max/dedup | O(n) per query | Sort once, query many times | O(n log n) + O(log n) per query |
+
+**Think in Big-O first, then optimize constants.** A 10x constant-factor improvement matters; switching from O(n²) to O(n) matters more.
+
+## Work Avoidance
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — look for linear scan functions (`slices.Contains`, `slices.Index`) or iterator chains (`Filter`, `Map`) consuming CPU in hot paths 2- `go test -bench` — benchmark the current approach vs a map-based or early-return version; expect O(n) → O(1) for membership tests, significant improvement for short-circuit loops
+
+### Map lookups over slice scanning
+
+`Contains(slice, element)` is O(n). Map lookups are O(1). When doing multiple membership tests against the same collection, build a map once:
+
+```go
+// Bad — O(n*m), checking Contains per element
+for _, item := range subset {
+    if !Contains(collection, item) { return false } // O(n) per check
+}
+
+// Good — O(n+m), build map once, O(1) lookups
+seen := make(map[T]struct{}, len(collection))
+for _, item := range collection { seen[item] = struct{}{} }
+for _, item := range subset {
+    if _, ok := seen[item]; !ok { return false }
+}
+```
+
+Use `struct{}` (0 bytes) instead of `bool` (1 byte) for set maps.
+
+### Early returns and short-circuit loops
+
+Return immediately when the answer is known. Finding the target on iteration 3 of 1000 saves 997 iterations:
+
+```go
+// Bad — always iterates full collection
+found := false
+for _, item := range collection {
+    if item == target { found = true }
+}
+return found
+
+// Good — returns on first match
+for i := range collection {
+    if collection[i] == target { return true }
+}
+return false
+```
+
+### Avoid iterator chains
+
+Chaining iterator operations (`Filter → Map → First`) creates closures and intermediate machinery. A direct loop is simpler and faster:
+
+```go
+// Bad — creates 2 iterators with closures
+result, ok := First(Filter(collection, predicate))
+
+// Good — single pass, early return, no closures
+for i := range collection {
+    if predicate(collection[i]) { return collection[i], true }
+}
+```
+
+### Replace indirect function calls with direct loops
+
+When a function wraps another function (e.g., `FromSlicePtr` calling `Map` with a closure), the closure indirection prevents inlining. Replace with a direct loop:
+
+```go
+// Bad — Map() with closure, per-element function call overhead
+func FromSlicePtr(items []*T) []T {
+    return Map(items, func(p *T) T { return *p })
+}
+
+// Good — direct loop, inlineable, -13% to -17% time
+func FromSlicePtr(items []*T) []T {
+    result := make([]T, len(items))
+    for i := range items { result[i] = *items[i] }
+    return result
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/cpu.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/cpu.md
new file mode 100644
index 00000000..2711644c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/cpu.md
@@ -0,0 +1,375 @@
+# CPU Optimization
+
+CPU-bound bottlenecks show up as functions dominating the CPU profile. The patterns below target the most common causes: missed inlining opportunities, poor cache utilization, and unnecessary computation.
+
+## Function Inlining
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — look for hot functions with high cumulative CPU time; if a small helper dominates the profile, it's likely not being inlined 2- `go build -gcflags="-m"` — grep for `"cannot inline"` on your hot-path functions; the reason (e.g., `"function too complex"`, `"unhandled op"`) tells you what to simplify
+
+The Go compiler inlines small functions, eliminating call overhead. Functions that are too complex (loops, many statements, or calls to non-inlineable functions) won't be inlined — this matters in tight loops called millions of times.
+
+```go
+// Bad — log call prevents inlining
+func abs(x int) int {
+    if x < 0 {
+        log.Printf("negative: %d", x) // blocks inlining
+        return -x
+    }
+    return x
+}
+
+// Good — simple enough to inline
+func abs(x int) int {
+    if x < 0 { return -x }
+    return x
+}
+```
+
+**Check inlining decisions:**
+
+```bash
+go build -gcflags="-m" ./... 2>&1 | grep "can inline"
+go build -gcflags="-m" ./... 2>&1 | grep "inlining call"
+```
+
+Move side effects (logging, metrics) outside hot-path functions or guard them with conditional checks.
+
+### Value receivers enable inlining
+
+Value receivers allow the compiler to fully inline fluent method chains. Pointer receivers add indirection that blocks inlining:
+
+```go
+// Pointer receiver — indirection prevents inlining, constant overhead per call
+func (c *config) WithTimeout(d time.Duration) *config { c.timeout = d; return c }
+
+// Value receiver — fully inlined, -80% time in fluent chains
+func (c config) WithTimeout(d time.Duration) config { c.timeout = d; return c }
+```
+
+## Cache Locality
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — look for loops over slices/matrices consuming disproportionate CPU; cache-miss-heavy code shows high `runtime.memmove` or flat time in simple index operations 2- `go test -bench` — benchmark row-first vs column-first traversal; expect 10-50x difference on large matrices purely from cache effects
+
+Modern CPUs fetch data in 64-byte cache lines. Sequential memory access is dramatically faster than random access because the prefetcher can load the next cache line before you need it.
+
+### Row-major traversal
+
+Go stores 2D arrays in row-major order. Column-first traversal jumps across memory, causing cache misses:
+
+```go
+// Bad — column-first, jumps across memory (~10M cache misses)
+for col := 0; col < 1024; col++ {
+    for row := 0; row < 1024; row++ {
+        sum += matrix[row][col]
+    }
+}
+
+// Good — row-first, sequential access (~125K cache misses)
+for row := 0; row < 1024; row++ {
+    for col := 0; col < 1024; col++ {
+        sum += matrix[row][col]
+    }
+}
+```
+
+Performance difference: 10-50x purely from cache effects.
+
+### Contiguous 2D allocation
+
+Allocating each row separately scatters data across the heap:
+
+```go
+// Bad — N separate allocations, poor cache locality
+matrix := make([][]float64, rows)
+for i := range matrix { matrix[i] = make([]float64, cols) }
+
+// Good — single contiguous allocation, cache-friendly
+data := make([]float64, rows*cols)
+matrix := make([][]float64, rows)
+for i := range matrix { matrix[i] = data[i*cols : (i+1)*cols] }
+```
+
+### Struct of Arrays (SoA) vs Array of Structs (AoS)
+
+When iterating over a single field of a struct, AoS wastes cache space loading unused fields:
+
+```go
+// AoS — loading each Point (24 bytes) to read only x (8 bytes) = 66% cache waste
+type Point struct { x, y, z float64 }
+points := make([]Point, n)
+for i := range points { sum += points[i].x }
+
+// SoA — all x values contiguous, 100% cache utilization
+type Points struct { xs, ys, zs []float64 }
+for i := range ps.xs { sum += ps.xs[i] }
+```
+
+Use SoA when iterating over a subset of fields (physics, graphics, analytics). AoS is fine when accessing all fields together or for small structs.
+
+### Pointer-heavy vs value-heavy data
+
+Index-based data structures (nodes stored in a contiguous array, referenced by index) beat pointer-based structures for cache locality:
+
+```go
+// Pointer-based tree — each node scattered in heap, random cache misses
+type Node struct { value int; left, right *Node }
+
+// Index-based tree — nodes in contiguous array, cache-friendly
+type Tree struct { nodes []Node }
+type Node struct { value int; left, right int } // indices into nodes
+```
+
+## False Sharing
+
+**Diagnose:** 1- `go tool pprof` (CPU profile + mutex profile) — look for atomic operations or counter updates consuming unexpectedly high CPU; in the mutex profile, look for contention on variables that shouldn't need locking 2- `go test -bench` — benchmark concurrent counter increments; if adding goroutines makes it _slower_ instead of faster, false sharing is likely
+
+When goroutines update variables that share the same 64-byte CPU cache line, each write invalidates the other core's cache, causing severe degradation:
+
+```go
+// Bad — a and b on same cache line, cores fight for it
+type Counters struct { a, b int64 }
+
+// Good — separate cache lines, no interference
+type Counters struct {
+    a int64    // 8 bytes
+    _ [56]byte // 64 - 8 = 56 bytes padding
+    b int64    // 8 bytes
+}
+```
+
+Only apply cache-line padding when profiling confirms contention on concurrent counters/flags.
+
+## Instruction-Level Parallelism
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — look for tight arithmetic loops (sum, dot product) where the loop body itself dominates CPU; these are candidates for multi-accumulator optimization 2- `go test -bench` — benchmark single vs multi-accumulator versions; expect 2-4x improvement when the loop is truly CPU-bound with a dependency chain
+
+Modern CPUs execute multiple independent instructions simultaneously. A single accumulator creates a dependency chain — each addition waits for the previous one:
+
+```go
+// Bad — sequential dependency, CPU pipeline stalls
+var total int64
+for _, v := range data { total += v }
+
+// Good — 4 independent accumulators, CPU pipelines all 4 in parallel
+var s0, s1, s2, s3 int64
+limit := len(data) - len(data)%4
+for i := 0; i < limit; i += 4 {
+    s0 += data[i]; s1 += data[i+1]; s2 += data[i+2]; s3 += data[i+3]
+}
+for i := limit; i < len(data); i++ { s0 += data[i] }
+total := s0 + s1 + s2 + s3
+```
+
+Expect 2-4x improvement for tight arithmetic loops. Only use when profiling shows the loop is a bottleneck.
+
+## SIMD (Single Instruction, Multiple Data)
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — confirm a numeric inner loop consumes >20% of CPU; SIMD only helps CPU-bound numeric work, not allocation or I/O bottlenecks 2- `go test -bench` — measure the loop's baseline ns/op; provides the reference point to validate SIMD gains 3- `go build -gcflags="-d=ssa/prove/debug=2"` — check if the compiler already auto-vectorized the loop; look for `"Proved"` bounds-check eliminations that enable vectorization 4- `GOSSAFUNC=MyFunc go build` — generate SSA dump (`ssa.html`) to inspect whether the compiler produces vector instructions for the hot loop 5- `go tool objdump -s MyFunc ./binary` — verify the final assembly contains SIMD instructions (e.g., `VMOVAPD`, `VADDPD` on amd64) rather than scalar equivalents
+
+Go 1.26+ includes an experimental `simd/archsimd` package (requires `GOEXPERIMENT=simd` flag) providing low-level SIMD intrinsics for amd64 with 128/256/512-bit vectors. For broader portability, the compiler auto-vectorizes simple loops, and several strategies exist.
+
+**Options for explicit SIMD in Go:**
+
+- **Experimental `simd/archsimd` (Go 1.26+, speculative)** — Direct SIMD intrinsics via vector types with CPU feature detection. Limited to AMD64. Use with caution: this is an experimental, in-progress API (`GOEXPERIMENT=simd`) whose package path and type names are subject to change before stabilization. Not covered by Go 1 compatibility guarantees, and should never be exposed in public APIs. Verify the actual import path and API against the Go toolchain you are using.
+
+  ```go
+  // Requires: GOEXPERIMENT=simd go build
+  // WARNING: experimental API — package path and types may change
+  import "simd/archsimd"
+
+  v := archsimd.Int32x4{1, 2, 3, 4}
+  ```
+
+- **Let the compiler do it** — write simple, idiomatic loops on `[]float64`/`[]int32` slices. Check auto-vectorization: `go build -gcflags="-d=ssa/prove/debug=2" ./...`
+- **`math/bits`** — operations like `OnesCount`, `LeadingZeros`, `RotateLeft` map directly to hardware instructions (POPCNT, CLZ, ROL)
+- **Hand-written assembly** — `.s` files with AVX2/NEON instructions for critical inner loops. Libraries like `klauspost/compress` and `minio/sha256-simd` use this approach
+- **Third-party vectorized libraries** — for common operations (hashing, compression, encoding), use libraries that already have optimized SIMD implementations rather than writing your own
+
+### Handling CPU-specific instruction sets
+
+Hand-written assembly unlocks higher performance but couples code to specific CPU features (AVX2, NEON, etc.). Three strategies exist:
+
+**1. Compile on a production-similar machine**
+
+Build binaries on hardware matching your deployment target, so the compiler generates code for the exact CPU instruction set available at runtime:
+
+```bash
+# Compiling on production hardware ensures optimal code generation
+# for that specific CPU architecture and generation
+ssh prod-server "cd /path && go build -o app ."
+```
+
+**Tradeoff:** Simplest approach, but requires access to production hardware and different binaries per CPU type (Intel vs AMD vs Apple Silicon). Breaks CI/CD portability.
+
+**2. Runtime CPU feature detection + multiple implementations**
+
+Implement the function multiple times — one for each CPU capability — and dispatch at runtime:
+
+```go
+// dispatch.go
+var sumImpl func([]int64) int64
+
+func init() {
+    if cpu.X86.HasAVX2 {
+        sumImpl = sumAVX2
+    } else {
+        sumImpl = sumGeneric
+    }
+}
+
+func Sum(data []int64) int64 {
+    return sumImpl(data)
+}
+
+// sum_generic.go
+func sumGeneric(data []int64) int64 {
+    var total int64
+    for _, v := range data { total += v }
+    return total
+}
+
+// sum_amd64.s
+TEXT ·sumAVX2(SB), NOSPLIT, $0-32
+    // AVX2 implementation
+    VMOVAPD (SI), Y0
+    // ...
+```
+
+**Tradeoff:** Single binary works everywhere; trades one function-call dispatch overhead for full CPU feature utilization. Libraries like `encoding/base64` and `sha256` use this pattern.
+
+**3. Compile-time selection with `//go:build` tags**
+
+Use conditional compilation to generate different code at build time for each target:
+
+```go
+// sum_fast.go
+//go:build amd64 && !nosimd
+
+package mylib
+
+// AVX2 assembly via cgo or inline
+func Sum(data []int64) int64 {
+    return sumAVX2(data) // or calls to .s file
+}
+
+// sum_generic.go
+//go:build !amd64 || nosimd
+
+package mylib
+
+func Sum(data []int64) int64 {
+    var total int64
+    for _, v := range data { total += v }
+    return total
+}
+```
+
+Build different binaries per target:
+
+```bash
+GOOS=linux GOARCH=amd64 go build -o app-avx2 .     # Uses sum_fast.go
+GOOS=darwin GOARCH=arm64 go build -o app-neon .    # Uses sum_generic.go
+go build -tags=nosimd -o app-safe .                # Fallback everywhere
+```
+
+**Tradeoff:** Zero runtime overhead; each binary is fully optimized for its target. Requires shipping multiple binaries and coordinating which binary runs where.
+
+**When SIMD is NOT worth pursuing:**
+
+- Go's lack of intrinsics means SIMD requires assembly — high maintenance burden, platform-specific, and harder to debug
+- Auto-vectorization covers the most common cases (simple numeric loops)
+- If your bottleneck is allocations or I/O, SIMD won't help
+
+**Recommendation:** Start with auto-vectorization. For Go 1.26+, evaluate `simd/archsimd` for AMD64-only workloads (remembering it's experimental). Move to runtime detection (option 2 above) if profiling shows a bottleneck and the code needs to run on heterogeneous hardware. Only use compile-time selection (option 3) if you control the deployment environment and can test each per-binary variant.
+
+Only invest in hand-written SIMD when profiling shows a numeric inner loop consuming >20% of CPU and the compiler isn't auto-vectorizing it.
+
+## Tight Loops and the Scheduler
+
+**Diagnose:** 1- `go tool pprof` (goroutine profile) — look for many goroutines stuck in `"runnable"` state (waiting for CPU) while one goroutine monopolizes execution 2- `go tool trace` — visualize goroutine scheduling over time; look for long uninterrupted execution spans on one goroutine while others show scheduling gaps 3- `GODEBUG=schedtrace=1000` — print scheduler state every second; look for unbalanced `runqueue` counts across P's indicating one P is starved 4- `runtime/metrics` (`/sched/latencies:seconds`) — measure how long goroutines wait before getting CPU; high p99 latencies confirm starvation 5- Prometheus `rate(process_cpu_seconds_total[2m])` — monitor if CPU usage hits GOMAXPROCS ceiling; if saturated while other goroutines are starved, a tight loop is monopolizing P's
+
+A goroutine running a CPU-intensive tight loop without function calls may not yield to the scheduler, starving other goroutines. Go 1.14+ added asynchronous preemption, but very tight loops with fully inlined operations can still cause issues:
+
+```go
+// Potential starvation — pure computation, no function calls
+for { x = x*a + b }
+
+// Safe — non-inlined call triggers preemption check
+for item := range work {
+    processBatch(item) // function call = preemption point
+}
+```
+
+**When to use non-inlined calls for scheduling:** Use non-inlined function calls when:
+
+- The loop runs for a long time (hundreds of milliseconds or more of uninterrupted computation)
+- Other goroutines are waiting to run (e.g., handling requests, I/O completion, channel operations)
+- The loop contains only arithmetic or memory operations with no function calls
+
+For short bursts of computation (< 10ms), preemption isn't critical and inlining for CPU efficiency takes priority.
+
+**Detecting scheduler starvation:** Use these tools to confirm goroutines are being starved:
+
+- **`go tool pprof` goroutine profile** — shows goroutines stuck in "runnable" state (waiting for CPU). If many goroutines are runnable while one dominates CPU, starvation is happening
+- **`go tool trace`** — visualizes goroutine scheduling over time. Look for gaps where goroutines aren't running because one goroutine monopolized the scheduler
+- **`runtime/metrics` (Go 1.19+)** — measure `/sched/latencies:seconds` to quantify how long goroutines wait for CPU
+- **Observable symptoms** — high response latency, requests timing out, uneven request distribution, goroutine counts climbing
+
+**Preventing inlining with `//go:noinline`:** If you have a function that's normally inlinable (small, hot) but you specifically want it to not inline to force scheduler preemption checks, use the `//go:noinline` compiler directive:
+
+```go
+//go:noinline
+func processBatch(item WorkItem) {
+    // CPU-intensive work here
+    // This call site will NOT be inlined, even if the function is small
+    // The function call itself becomes a preemption point for the scheduler
+}
+
+// In tight loop
+for item := range work {
+    processBatch(item) // Guaranteed preemption point
+}
+```
+
+**Trade-off:** Using `//go:noinline` prevents inlining, which:
+
+- **Pros:** Guarantees scheduler preemption checks; prevents goroutine starvation
+- **Cons:** Adds function call overhead (~10-30 CPU cycles); reduces instruction-level parallelism (ILP) in the caller
+
+Only use `//go:noinline` if profiling shows that scheduler preemption starvation is actually blocking other goroutines. Unnecessary `//go:noinline` directives penalize throughput and latency.
+
+## Reflection and Type Assertions
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — look for `reflect.Value.*`, `reflect.DeepEqual`, or `fmt.Sprintf` (which uses reflect internally) appearing in hot paths 2- `go test -bench` — compare reflection-based vs typed versions; expect 10-200x difference depending on the reflection operation
+
+- **`reflect` in hot paths** — 10-100x slower due to type introspection and boxing. Replace with generics or typed code
+- **`reflect.DeepEqual`** — 50-200x slower than typed comparisons. Use `slices.Equal`, `maps.Equal`, `bytes.Equal` (Go 1.21+)
+- **Type switch vs repeated assertions** — type switch dispatches in one evaluation:
+
+```go
+// Bad — evaluates interface multiple times
+if s, ok := v.(string); ok { return s }
+if i, ok := v.(int); ok { return strconv.Itoa(i) }
+
+// Good — single dispatch
+switch v := v.(type) {
+case string: return v
+case int:    return strconv.Itoa(v)
+}
+```
+
+## Monotonic Time
+
+**Diagnose:** 1- `go test -bench` — benchmark `time.Since(start)` vs `time.Now().Sub(start)`; expect a small but consistent improvement from monotonic clock avoiding wall-clock syscall
+
+`time.Since(start)` uses the monotonic clock, which is immune to wall-clock adjustments (NTP, DST) and slightly faster:
+
+```go
+var appStart = time.Now() // captures monotonic time + wall-clock on program start
+
+func myFunc() {
+    // Compare durations, not wall-clock times
+    elapsed := time.Since(appStart)
+    if elapsed > threshold { ... }
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/io-networking.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/io-networking.md
new file mode 100644
index 00000000..970202d2
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/io-networking.md
@@ -0,0 +1,299 @@
+# I/O & Networking Optimization
+
+Network and I/O bottlenecks show up as goroutines blocked on syscalls or waiting for responses. The key levers are connection reuse, proper timeouts, and streaming instead of buffering.
+
+## HTTP Transport Configuration
+
+**Diagnose:** 1- `go tool pprof` (goroutine + block profile) — look for goroutines blocked on `net/http.(*Transport).dialConn` or `net/http.(*persistConn).readLoop`; many goroutines waiting here means connection pool exhaustion 2- `fgprof` — captures both on-CPU and off-CPU wait time; look for HTTP calls dominating wall-clock time even when CPU profile shows them as cheap 3- `go tool trace` — visualize goroutine lifecycles; look for long gaps where goroutines wait for network I/O instead of processing 4- Prometheus `go_goroutines` — monitor goroutine count in production; steadily rising under stable load suggests connection or goroutine leaks from misconfigured HTTP clients
+
+### Connection pooling
+
+The default `http.Transport` has conservative pool settings — `MaxIdleConnsPerHost` defaults to 2. Under high concurrency, requests queue waiting for connections instead of running in parallel:
+
+```go
+// Bad — default transport, only 2 idle connections per host
+client := &http.Client{}
+
+// Good — tuned for high-concurrency service-to-service calls
+var apiClient = &http.Client{
+    Timeout: 30 * time.Second,
+    Transport: &http.Transport{
+        MaxIdleConns:          100,             // total idle connections across all hosts
+        MaxIdleConnsPerHost:   20,              // per-host idle connections (default is 2!)
+        MaxConnsPerHost:       50,              // cap total connections per host (0 = unlimited)
+        IdleConnTimeout:       90 * time.Second,
+        TLSHandshakeTimeout:  5 * time.Second,
+        ResponseHeaderTimeout: 10 * time.Second,
+    },
+}
+```
+
+For web crawlers hitting many different hosts, disable keep-alive to avoid accumulating idle connections:
+
+```go
+crawlerClient := &http.Client{
+    Transport: &http.Transport{DisableKeepAlives: true},
+}
+```
+
+### Timeouts
+
+The zero-value `http.Client` and `http.Server` have NO timeouts. A slow or malicious peer holds connections open indefinitely, exhausting file descriptors and memory:
+
+```go
+// Server — always set timeouts to prevent Slowloris attacks
+server := &http.Server{
+    Addr:         ":8080",
+    Handler:      handler,
+    ReadTimeout:  5 * time.Second,
+    WriteTimeout: 10 * time.Second,
+    IdleTimeout:  120 * time.Second,
+}
+```
+
+### Drain response body for connection reuse
+
+Connections are only returned to the pool when the body is fully read. Even if you don't need the body, drain it:
+
+```go
+resp, err := client.Get(url)
+if err != nil { return err }
+defer resp.Body.Close()
+_, _ = io.Copy(io.Discard, resp.Body) // drain to enable connection reuse
+```
+
+## Streaming vs Buffering
+
+**Diagnose:** 1- `go tool pprof -inuse_space` — look for large single allocations (MB-sized) from `io.ReadAll`, `bytes.Buffer.Grow`, or `json.Unmarshal`; these indicate buffering entire payloads instead of streaming
+
+### Avoid io.ReadAll for large payloads
+
+`io.ReadAll` loads the entire stream into memory. For large files or HTTP responses, this causes massive memory spikes:
+
+```go
+// Bad — 2GB file = 2GB allocation
+data, _ := io.ReadAll(f)
+
+// Good — process line by line, O(1) memory
+scanner := bufio.NewScanner(f)
+for scanner.Scan() { processLine(scanner.Bytes()) }
+
+// Good — stream between reader and writer (32KB internal buffer)
+io.Copy(w, resp.Body)
+```
+
+`io.ReadAll` is fine for small, bounded payloads (< 1MB) where the size is known.
+
+### Streaming JSON
+
+Use `json.NewDecoder` for large JSON payloads instead of `json.Unmarshal` (which buffers the entire body):
+
+```go
+dec := json.NewDecoder(r)
+for dec.More() {
+    var item Item
+    if err := dec.Decode(&item); err != nil { return err }
+    process(item) // one item at a time
+}
+```
+
+## JSON Performance
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — look for `encoding/json.(*Decoder).Decode`, `reflect.Value.*`, or `encoding/json.Marshal` consuming significant CPU; these indicate reflection-based JSON is the bottleneck 2- `go test -bench -benchmem` — measure ns/op and allocs/op for marshal/unmarshal; expect high alloc counts from reflection; code-gen alternatives should show 2-5x fewer allocs
+
+The standard `encoding/json` package uses reflection to inspect struct fields at runtime. For high-throughput services, this creates significant CPU and allocation overhead.
+
+**Options for faster JSON:**
+
+- **Custom `MarshalJSON`/`UnmarshalJSON`** — hand-written methods for hot-path types eliminate reflection
+- **Code-generation libraries** — `easyjson`, `ffjson` generate marshal/unmarshal methods at build time, no reflection at runtime
+- **Drop-in replacements** — `github.com/goccy/go-json`, `github.com/json-iterator/go`, `github.com/bytedance/sonic` offer 2-5x better performance
+- **`encoding/json/v2`** (experimental, behind `GOEXPERIMENT=jsonv2`) — evaluate deliberately; most production code should keep `encoding/json` unless the project explicitly opts into the experiment
+
+When using third-party JSON libraries, refer to the library's official documentation for up-to-date API signatures.
+
+## Cgo Overhead
+
+**Diagnose:** 1- `go tool pprof` (CPU profile + threadcreate profile) — look for `runtime.cgocall` or `runtime.asmcgocall` consuming CPU; high threadcreate count means cgo calls are pinning goroutines to OS threads 2- `go test -bench` — benchmark the cgo call loop vs a pure Go equivalent; expect ~50-100ns overhead per cgo crossing
+
+Each Go-to-C call via cgo costs ~50-100ns due to stack switching, signal mask manipulation, and scheduler coordination:
+
+```go
+// Bad — cgo overhead per element dominates for tight loops
+for i, v := range values {
+    values[i] = float64(C.sqrt(C.double(v))) // ~100ns overhead PER CALL
+}
+
+// Good — use pure Go stdlib (math.Sqrt is as fast as C and inlineable)
+for i, v := range values { values[i] = math.Sqrt(v) }
+
+// Good — batch when C code is unavoidable
+C.batch_sqrt((*C.double)(&values[0]), C.int(len(values))) // amortize overhead
+```
+
+Additional cgo costs: goroutine is pinned to an OS thread, C code cannot be preempted (may delay GC), and function inlining is blocked at the boundary.
+
+## Buffered I/O
+
+**Diagnose:** 1- `go test -bench` — benchmark buffered vs unbuffered I/O; expect 3-10x improvement from reducing syscall count 2- `go tool trace` — look for frequent short syscalls (`pread`, `pwrite`) in rapid succession; many tiny I/O operations indicate unbuffered access
+
+Unbuffered file reads/writes issue a syscall per operation. `bufio.Reader` and `bufio.Writer` batch small operations, reducing syscalls by 10x or more:
+
+```go
+// Bad — syscall per line
+for _, line := range lines { f.WriteString(line + "\n") }
+
+// Good — buffered, batches writes into larger chunks
+w := bufio.NewWriter(f)
+for _, line := range lines { w.WriteString(line + "\n") }
+w.Flush()
+```
+
+## Concurrent Multi-Stage Pipelines
+
+**Diagnose:** 1- `go tool trace` — visualize resource utilization across stages; look for sequential idle gaps where CPU, disk, or network sit unused while another resource is busy 2- `go tool pprof` (CPU + goroutine profile) — confirm each stage saturates a _different_ resource; if multiple stages compete for the same resource (e.g., both CPU-bound), concurrency won't help
+
+In rare scenarios where each pipeline stage saturates a _different_ resource (CPU, disk I/O, network), running stages concurrently instead of sequentially can improve throughput — even with batching between stages.
+
+### The unusual scenario
+
+Imagine processing records: Stage A compresses (CPU-bound), Stage B writes to disk (I/O-bound), Stage C uploads to network (network-bound). Sequential execution wastes resources:
+
+```
+Time:    0       10      20      30      40      50
+CPU:     AAAAAAAAAA|..........|..........|..........|
+Disk:    ..........|BBBBBBBBBB|..........|..........|
+Network: ..........|..........|CCCCCCCCCC|..........|
+```
+
+Concurrent stages let resources work in parallel:
+
+```
+Time:    0       10      20      30      40      50
+CPU:     AAAAAAAAAA|AA........|
+Disk:    ..........|BBBBBBBBBB|BB........|
+Network: ..........|..........|CCCCCCCCCC|CC........|
+```
+
+**Code pattern:**
+
+```go
+// Each stage runs in its own goroutine, bounded by channel buffers
+compressedCh := make(chan []byte, 100)    // A → B buffer
+uploadedCh := make(chan bool, 100)        // B → C buffer
+
+// Stage A: CPU-bound compression
+go func() {
+    for record := range inputCh {
+        compressed := compress(record)    // saturates CPU
+        compressedCh <- compressed
+    }
+    close(compressedCh)
+}()
+
+// Stage B: I/O-bound disk writes
+go func() {
+    for compressed := range compressedCh {
+        diskFile.Write(compressed)        // saturates disk I/O
+        uploadedCh <- true
+    }
+    close(uploadedCh)
+}()
+
+// Stage C: network-bound uploads
+go func() {
+    for <-uploadedCh {
+        client.Post(uploadURL, ...)       // saturates network
+    }
+}()
+```
+
+With batching per stage, total throughput = min(A_throughput, B_throughput, C_throughput). Without concurrency, throughput = sequential sum of stages. **Concurrent stages only help when bottlenecks don't overlap.**
+
+### When to use this (and when NOT to)
+
+**Use concurrent pipelines only when ALL of these are true:**
+
+1. **Resource saturation is predictable and non-overlapping** — You measured that A saturates one resource (e.g., CPU = 95%), B saturates another (disk I/O = 90%), C saturates a third (network = 85%). Overlapping saturation means concurrency adds no benefit.
+2. **Bottleneck shifts don't hurt latency** — Processing order doesn't matter, or records can flow out-of-order through stages.
+3. **Buffering overhead is acceptable** — Inter-stage channels consume memory. For large records, channel buffers can overflow system limits.
+4. **You've benchmarked the alternative** — Profile both sequential and concurrent versions. Sequential + batching often wins because it is simpler and avoids context-switching overhead.
+
+**Avoid concurrent pipelines if:**
+
+- **Records must be ordered** — Concurrent processing may reorder records; if downstream expects order, you need synchronization that kills the speedup.
+- **Resources overlap** — If A and B both compete for CPU (e.g., both compress), concurrency causes context-switching overhead with no resource utilization gain.
+- **Latency matters more than throughput** — A single record now travels through 3 stages in parallel, increasing per-record latency.
+- **Memory is tight** — Each stage's channel buffer is a memory budget; deeply buffered channels can exhaust available RAM.
+
+→ See `samber/cc-skills-golang@golang-concurrency` skill for detailed channel patterns and when to use worker pools instead.
+
+## Batch Operations
+
+**Diagnose:** 1- `go test -bench` — benchmark single-item vs batched operations; expect N-fold improvement in throughput when amortizing per-operation overhead (syscalls, round-trips) 2- `go tool trace` — look for repeated short network/disk operations with idle gaps between them; these gaps represent wasted round-trip time that batching eliminates
+
+Batching amortizes per-operation overhead (syscalls, network round-trips, transaction costs) across many items. The pattern applies everywhere: I/O, database, network, and even in-memory processing.
+
+### Database: batch inserts over row-by-row
+
+Inserting 1,000 rows one at a time means 1,000 round-trips, 1,000 query parses, and 1,000 transaction commits. A single batch insert does it in one round-trip:
+
+```go
+// Bad — 1,000 round-trips, ~500ms
+for _, user := range users {
+    db.Exec("INSERT INTO users (name, email) VALUES ($1, $2)", user.Name, user.Email)
+}
+
+// Good — 1 round-trip with multi-row VALUES, ~5ms
+const batchSize = 1000
+for i := 0; i < len(users); i += batchSize {
+    end := min(i+batchSize, len(users))
+    batch := users[i:end]
+    // Build multi-row INSERT or use COPY protocol
+    tx, _ := db.Begin()
+    stmt, _ := tx.Prepare(pq.CopyIn("users", "name", "email"))
+    for _, u := range batch { stmt.Exec(u.Name, u.Email) }
+    stmt.Exec()
+    tx.Commit()
+}
+```
+
+→ See `samber/cc-skills-golang@golang-database` skill for detailed batch patterns and connection pool configuration.
+
+### HTTP: batch API calls
+
+Instead of N individual HTTP requests, send one request with N items when the API supports it:
+
+```go
+// Bad — 100 HTTP round-trips
+for _, id := range ids {
+    resp, _ := client.Get(fmt.Sprintf("/api/users/%s", id))
+    // ...
+}
+
+// Good — 1 HTTP request with all IDs
+resp, _ := client.Post("/api/users/batch", "application/json",
+    bytes.NewReader(marshalIDs(ids)))
+```
+
+### Channel: batch processing from a stream
+
+Accumulate items from a channel and process in bulk to reduce per-item overhead:
+
+```go
+func batchProcessor(in <-chan Item, batchSize int) {
+    batch := make([]Item, 0, batchSize)
+    ticker := time.NewTicker(100 * time.Millisecond) // flush on timeout too
+    defer ticker.Stop()
+    for {
+        select {
+        case item, ok := <-in:
+            if !ok { flush(batch); return }
+            batch = append(batch, item)
+            if len(batch) >= batchSize { flush(batch); batch = batch[:0] }
+        case <-ticker.C:
+            if len(batch) > 0 { flush(batch); batch = batch[:0] }
+        }
+    }
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/memory.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/memory.md
new file mode 100644
index 00000000..5c5972f5
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/memory.md
@@ -0,0 +1,233 @@
+# Memory Optimization
+
+Allocation reduction is the single highest-ROI optimization in most Go programs. Every allocation eventually requires garbage collection — reducing allocation count and size directly reduces GC pauses and CPU overhead.
+
+## Allocation Patterns
+
+**Diagnose:** 1- `go tool pprof -alloc_objects` — rank functions by number of heap allocations; expect hot-path functions (request handlers, serializers) near the top with thousands of alloc/op 2- `go build -gcflags="-m -m"` — verbose escape analysis showing _why_ variables escape; look for `"leaking param"`, `"too large for stack"`, or `"captured by closure"` on variables you expect to stay on the stack 3- `go test -bench -benchmem` — measure allocs/op and B/op per benchmark; expect the target function to show >0 allocs/op that can be eliminated
+
+### Reuse slices via append(s[:0], ...)
+
+Reslicing to zero length retains the backing array, turning what would be a new allocation into a no-op:
+
+```go
+// Bad — allocates new slice, old one becomes garbage
+mode = []T{item}
+
+// Good — reuses existing backing array (0 allocations)
+mode = append(mode[:0], item)
+```
+
+### Direct indexing vs append
+
+When the output size equals the input size, use `make([]T, len(input))` with direct assignment instead of `make([]T, 0, len(input))` with `append`. Direct assignment avoids per-element bounds checking and length increment:
+
+```go
+// Slower — append overhead per element
+result := make([]T, 0, len(input))
+for i := range input { result = append(result, transform(input[i])) }
+
+// Faster — direct assignment
+result := make([]T, len(input))
+for i := range input { result[i] = transform(input[i]) }
+```
+
+Use append when the result might be smaller (filtering) or when early error return could discard partial results.
+
+### Eliminate redundant map lookups
+
+`for k := range m { use(m[k]) }` does two lookups per iteration. Capture the value from range:
+
+```go
+// Bad — two lookups per iteration
+for k := range in { result[k] = fn(in[k]) }
+
+// Good — single lookup
+for k, v := range in { result[k] = fn(v) }
+```
+
+### Map size hints
+
+`make(map[K]V)` starts with a small number of buckets and rehashes as it grows. Providing a size hint avoids rehashing:
+
+```go
+m := make(map[string]int, len(items)) // single allocation, no rehashing
+```
+
+### Sentinel errors vs fmt.Errorf
+
+`fmt.Errorf` allocates on every call. For predictable errors in hot paths, use preallocated sentinels:
+
+```go
+var ErrNegative = errors.New("value is negative") // allocated once
+
+func validate(x int) error {
+    if x < 0 { return ErrNegative } // zero allocation
+    return nil
+}
+```
+
+Only use `fmt.Errorf` when you need dynamic context (field names, values).
+
+### Interface boxing
+
+Passing concrete types through `any`/`interface{}` forces heap allocation for boxing. In hot paths, use typed parameters or generics:
+
+```go
+// Bad — boxes each int, allocates
+func sum(values []any) int { ... }
+
+// Good — no boxing, no allocation
+func sum(values []int) int { ... }
+
+// Good — generic, still no boxing
+func sum[T ~int | ~int64](values []T) T { ... }
+```
+
+## Backing Array Leaks
+
+**Diagnose:** 1- `go tool pprof -inuse_space` — show currently live heap memory by allocation site; look for unexpectedly large live objects (MB-sized) that should have been GC'd — a sign of backing array retention 2- `go tool pprof -alloc_space` — show cumulative bytes allocated over time; look for allocation sites producing far more bytes than the final data they hold (e.g., 100MB allocated for 16-byte results)
+
+### Slice reslicing retains the entire backing array
+
+A small reslice of a large slice keeps the entire original array in memory:
+
+```go
+// Bad — retains entire megabyte-sized backing array
+func getHeader(data []byte) []byte { return data[:16] }
+
+// Good — independent copy, original can be GC'd
+func getHeader(data []byte) []byte {
+    header := make([]byte, 16)
+    copy(header, data[:16])
+    return header
+}
+```
+
+### Substring memory leaks
+
+Substrings share the backing array of the original string:
+
+```go
+// Bad — keeps entire longMsg in memory
+func extractID(msg string) string { return msg[:8] }
+
+// Good — independent copy (Go 1.20+)
+func extractID(msg string) string { return strings.Clone(msg[:8]) }
+```
+
+### Map never shrinks
+
+Go maps grow but never release bucket memory when entries are deleted. A map that once held millions of entries retains its allocation forever:
+
+```go
+// Recreate periodically to reclaim memory
+func compact(old map[string]Data) map[string]Data {
+    m := make(map[string]Data, len(old))
+    for k, v := range old { m[k] = v }
+    return m // old map becomes eligible for GC
+}
+```
+
+## String and Byte Optimization
+
+**Diagnose:** 1- `go tool pprof -alloc_objects` — look for string/byte conversion functions (`runtime.stringtoslicebyte`, `runtime.slicebytetostring`) appearing as top allocators 2- `go test -bench -benchmem` — measure allocs/op; expect repeated conversions to show 1+ alloc/op per conversion that can be reduced to zero by caching
+
+**Cache string-to-byte conversions** — converting between `string` and `[]byte` allocates a copy each time. Convert once and reuse the result.
+
+**Use `bytes` package directly** — `bytes.Contains`, `bytes.HasPrefix`, `bytes.Split`, `bytes.ToUpper` etc. operate on `[]byte` without string conversion. The `bytes` package mirrors most of `strings`.
+
+## sync.Pool Hot-Path Patterns
+
+**Diagnose:** 1- `go tool pprof -alloc_objects` — identify hot allocation sites creating the same object type repeatedly (e.g., `[]byte` buffers, temp structs); expect one site with thousands of allocs/s that can be pooled
+
+`sync.Pool` recycles objects across GC cycles, reducing allocation pressure. Use it for frequently allocated, short-lived objects in hot paths (HTTP handlers, serialization, logging):
+
+```go
+var bufPool = sync.Pool{
+    New: func() any {
+        buf := make([]byte, 0, 4096)
+        return &buf
+    },
+}
+
+func handleRequest(data []byte) []byte {
+    bp := bufPool.Get().(*[]byte)
+    buf := (*bp)[:0] // reset length, keep capacity
+    defer func() { *bp = buf; bufPool.Put(bp) }()
+
+    // ... process data into buf ...
+
+    result := make([]byte, len(buf))
+    copy(result, buf) // return a copy — buf goes back to pool
+    return result
+}
+```
+
+**Rules:**
+
+- Reset state before `Put()` — clear references to avoid retaining large object graphs across GC cycles
+- Return copies, not pooled buffers — callers must not hold references to pooled memory
+- Don't pool objects >32KB — large allocations bypass the pool's size classes and GC already handles them efficiently
+- Don't pool infrequently used objects — pool overhead exceeds benefit when allocations are rare
+
+→ See `samber/cc-skills-golang@golang-concurrency` skill for `sync.Pool` API reference and basic usage patterns.
+
+## Memory Layout
+
+**Diagnose:** 1- `fieldalignment ./...` — detect structs with wasted padding bytes; expect warnings like `"struct of size 40 could be 24"` listing which structs benefit from reordering 2- `unsafe.Sizeof`/`Alignof`/`Offsetof` — measure exact byte sizes and field offsets; use to confirm savings before/after and document them in code comments
+
+### Struct field alignment
+
+Go adds padding between fields to satisfy alignment requirements. Reorder fields from largest to smallest:
+
+```go
+// Bad — 24 bytes (7 + 3 bytes padding)
+type Bad struct {
+    a bool    // 1 byte + 7 padding
+    b int64   // 8 bytes
+    c bool    // 1 byte + 3 padding
+    d int32   // 4 bytes
+}
+
+// Good — 16 bytes (2 bytes padding)
+type Good struct {
+    b int64   // 8 bytes
+    d int32   // 4 bytes
+    a bool    // 1 byte
+    c bool    // 1 byte + 2 padding
+}
+```
+
+**Alignment requirements:** `bool`/`byte` = 1, `int16` = 2, `int32`/`float32` = 4, `int64`/`float64`/`string`/`[]T`/`*T` = 8.
+
+**Inspect layout:** `unsafe.Sizeof(T{})`, `unsafe.Alignof(T{})`, `unsafe.Offsetof(T{}.field)`
+
+### Zero-size field at end of struct
+
+If the last field has zero size (`struct{}`), the compiler adds word-sized padding to prevent a pointer to that field from overlapping the next memory block:
+
+```go
+// Bad — 16 bytes (8 for Value + 8 padding for Flag)
+type Entry struct { Value int64; Flag struct{} }
+
+// Good — 8 bytes (0 for Flag + 8 for Value)
+type Entry struct { Flag struct{}; Value int64 }
+```
+
+Having a `struct{}` field in a struct is rare and almost useless.
+
+### Pointer receivers for large structs
+
+Value receivers copy the entire struct on every method call. Use pointer receivers for structs larger than ~128 bytes. If any method uses a pointer receiver, all methods should for consistency.
+
+### Map of pointers for large, frequently updated structs
+
+Map values are not addressable — you cannot modify a field in place. For large structs with frequent updates, `map[K]*V` avoids the copy-modify-reassign pattern:
+
+```go
+players := map[string]*Player{"alice": {Score: 100}}
+players["alice"].Score += 10 // direct modification, no copy
+```
+
+Trade-off: each pointer is a separate heap allocation, adding GC pressure. For small, mostly-read structs, `map[K]V` (value) is better.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/observability.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/observability.md
new file mode 100644
index 00000000..f269d8c0
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/observability.md
@@ -0,0 +1,101 @@
+# Production Observability for Performance
+
+Third-party monitoring tools complement local profiling (pprof, benchmarks) by providing continuous monitoring, historical trends, and regression detection in production.
+
+## Prometheus Metrics for Go
+
+**Setup:** `github.com/prometheus/client_golang` — expose `/metrics` endpoint with `promhttp.Handler()`. Default collectors automatically export Go runtime metrics (`go_goroutines`, `go_memstats_*`, `go_gc_duration_seconds`, `process_cpu_seconds_total`, etc.).
+
+→ See `samber/cc-skills-golang@golang-benchmark` skill (investigation-session.md) for the full runtime metrics table, investigation session setup (scrape interval tuning, env-var toggling), and cost warnings for profiling tools.
+
+### PromQL Queries for Performance Diagnosis
+
+#### GC pressure
+
+| PromQL | What to look for |
+| --- | --- |
+| `rate(go_gc_duration_seconds_count[5m])` | GC cycles/s — >2/s sustained suggests excessive allocation rate |
+| `rate(go_gc_duration_seconds_sum[5m]) / rate(go_gc_duration_seconds_count[5m])` | Average GC pause — increasing trend means heap is growing or has too many pointers |
+| `go_gc_duration_seconds{quantile="1"}` | Worst-case GC pause — spikes here cause tail latency |
+
+#### Memory leaks
+
+| PromQL | What to look for |
+| --- | --- |
+| `go_memstats_alloc_bytes` | Should be roughly stable under constant load; continuous increase = memory leak |
+| `rate(go_memstats_alloc_bytes_total[5m])` | Allocation rate (bytes/s) — drives GC frequency; compare before/after deploy for regressions |
+| `process_resident_memory_bytes - go_memstats_sys_bytes` | Gap = non-Go memory (cgo, mmap); growing gap = non-Go leak |
+
+#### Goroutine leaks
+
+| PromQL | What to look for |
+| --- | --- |
+| `go_goroutines` | Should correlate with load; growing independently of traffic = leak |
+| `delta(go_goroutines[1h])` | Net goroutine change over 1h; positive without load increase = leak |
+
+#### CPU saturation
+
+| PromQL | What to look for |
+| --- | --- |
+| `rate(process_cpu_seconds_total[5m])` | CPU cores consumed; compare to GOMAXPROCS to detect saturation |
+| `rate(process_cpu_seconds_total[5m]) / <GOMAXPROCS>` | CPU utilization ratio; >0.8 sustained = CPU-saturated |
+
+#### Regression detection (after deploy)
+
+| PromQL | What to look for |
+| --- | --- |
+| `rate(go_memstats_alloc_bytes_total[5m])` | Compare before/after deploy; significant increase = new allocation pattern introduced |
+| `histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))` | p99 latency increase after deploy = regression (requires app-level histogram) |
+
+### Alerting rules (examples)
+
+[Example alerting rules](../assets/prometheus-alerts.yml) — adjust thresholds to your application; a high-throughput data pipeline will have different baselines than a lightweight API server.
+
+→ See `samber/cc-skills@promql-cli` skill for interactively testing these PromQL expressions against your Prometheus instance from the CLI.
+
+### Grafana Dashboards
+
+→ See `samber/cc-skills-golang@golang-observability` skill for recommended community Grafana dashboards that visualize Go runtime metrics out of the box.
+
+## Continuous Profiling
+
+Continuous profiling collects low-overhead samples in production and stores them for historical comparison. Use it to detect regressions across deploys, compare flamegraphs over time, and feed PGO (see [Runtime Tuning](./runtime.md#profile-guided-optimization-pgo)).
+
+| Tool | Model | Overhead | Best for |
+| --- | --- | --- | --- |
+| **Grafana Pyroscope** | push SDK or pull (via Alloy) | ~2-5% | Grafana ecosystem, historical flamegraph comparison |
+| **Parca** (Polar Signals) | eBPF-based pull | <1% | Infrastructure-wide profiling, no code changes |
+| **Datadog Continuous Profiler** | push (agent) | ~1-2% | Existing Datadog users |
+| **Google Cloud Profiler** | push (agent) | ~1-2% | GCP-hosted Go services |
+
+### Pyroscope push mode
+
+```go
+import "github.com/grafana/pyroscope-go"
+
+pyroscope.Start(pyroscope.Config{
+    ApplicationName: "myapp",
+    ServerAddress:   "http://pyroscope:4040",
+    ProfileTypes: []pyroscope.ProfileType{
+        pyroscope.ProfileCPU,
+        pyroscope.ProfileAllocObjects,
+        pyroscope.ProfileAllocSpace,
+        pyroscope.ProfileInuseObjects,
+        pyroscope.ProfileInuseSpace,
+        pyroscope.ProfileGoroutines,
+    },
+})
+```
+
+### Pyroscope pull mode (via Grafana Alloy)
+
+No code changes required — Alloy scrapes `/debug/pprof/*` endpoints periodically. Configure Alloy to target your service's pprof endpoint.
+
+When using third-party profiling libraries, refer to the library's official documentation for current API signatures.
+
+## Real-Time Visualization (Development)
+
+| Tool | What it does |
+| --- | --- |
+| **statsviz** (`github.com/arl/statsviz`) | Real-time browser dashboard at `/debug/statsviz` — heap, GC pauses, goroutines, scheduler. Register with `statsviz.Register(mux)`. Great for local development |
+| **expvar** (stdlib `expvar`) | JSON metrics at `/debug/vars` — lightweight, no dependencies. Integrates with Netdata, Telegraf, or custom dashboards |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/runtime.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/runtime.md
new file mode 100644
index 00000000..79c71e00
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-performance/references/runtime.md
@@ -0,0 +1,222 @@
+# Runtime Tuning
+
+Runtime settings control garbage collection frequency, memory limits, CPU scheduling, and compiler optimizations. Tune them after profiling — the defaults are well-chosen for most workloads.
+
+## Garbage Collector Tuning
+
+**Diagnose:** 1- `GODEBUG=gctrace=1` — print one line per GC cycle; look for high GC frequency (cycles/s), high CPU% (>5% means GC is competing for CPU), or heap growing faster than expected 2- `runtime.ReadMemStats` — inspect `Alloc`, `TotalAlloc`, `NumGC`, `PauseNs`; compare `Alloc` vs `Sys` to see how much memory the GC is reclaiming vs how much the OS allocated 3- `go tool trace` — visualize GC stop-the-world pauses and GC assist stealing CPU from application goroutines; look for long STW bars or frequent assist marks 4- `debug.ReadGCStats` — get pause time percentiles (p50, p95, p99); high p99 pauses indicate large heap scans or too many pointers 5- `runtime/metrics` — programmatic access to GC stats for dashboards; monitor `/gc/cycles/total`, `/gc/heap/allocs`, `/gc/pauses` 6- `GODEBUG=gcpacertrace=1` — trace the GC pacer's decisions; useful to understand why GC triggers earlier or later than expected 7- Prometheus `rate(go_gc_duration_seconds_count[5m])` — monitor GC frequency in production; >2 cycles/s sustained suggests excessive allocation rate
+
+### GOGC (default: 100)
+
+Controls the heap growth ratio that triggers the next GC cycle. `GOGC=100` means GC runs when the heap doubles since the last collection. Higher values reduce GC frequency but use more memory:
+
+```bash
+GOGC=50  ./myapp  # latency-sensitive: more frequent, shorter GC pauses
+GOGC=200 ./myapp  # throughput-oriented: less frequent GC, more memory used
+GOGC=off ./myapp  # disable GC entirely (testing only!)
+```
+
+### GOMEMLIMIT (Go 1.19+)
+
+Soft memory limit — the runtime increases GC frequency to stay under this limit. Essential for containerized applications where exceeding the container limit triggers an OOM kill:
+
+```bash
+# Container with 512MB limit: leave headroom for non-heap memory (goroutine stacks, OS buffers)
+GOMEMLIMIT=450MiB ./myapp
+
+# Container with 1GB limit
+GOMEMLIMIT=900MiB ./myapp
+```
+
+The GC pacer adjusts collection timing based on both GOGC and GOMEMLIMIT. When the heap approaches the limit, the GC runs more aggressively regardless of GOGC.
+
+### Programmatic control
+
+```go
+import "runtime/debug"
+
+debug.SetGCPercent(200)                    // equivalent to GOGC=200
+debug.SetMemoryLimit(450 * 1024 * 1024)   // 450 MiB soft limit
+```
+
+Use programmatic control for dynamic tuning based on observed workload, or when environment variables cannot be set.
+
+### Ballast pattern (pre-Go 1.19)
+
+Before GOMEMLIMIT, teams allocated a large byte array at startup to inflate the live heap size, reducing GC frequency:
+
+```go
+var ballast [1 << 30]byte // 1 GB — obsolete pattern
+```
+
+**GOMEMLIMIT is strictly better** — it provides the same benefit (fewer GC cycles) without wasting physical memory. Use GOMEMLIMIT instead.
+
+## GC Profiling and Diagnostics
+
+### GODEBUG=gctrace=1
+
+Prints a line per GC cycle to stderr:
+
+```bash
+GODEBUG=gctrace=1 ./myapp 2>&1 | head -20
+```
+
+Sample output:
+
+```
+gc 5 @1.234s 2%: 0.012+12+0.9 ms clock, 0.25+8.9/20+18 ms cpu, 45->92->50 MB, 200 MB goal, 8 P
+```
+
+Key fields:
+
+- `gc 5` — 5th GC cycle
+- `@1.234s` — time since program start
+- `2%` — total CPU time spent in GC
+- `45->92->50 MB` — heap before → peak during collection → after
+- `200 MB goal` — target heap size (based on GOGC and GOMEMLIMIT)
+- `8 P` — number of processors
+
+Watch for: GC frequency (too often = too many allocations), pause times (high = large heap or many pointers), CPU% (high = tune GOGC or reduce allocations).
+
+### runtime.ReadMemStats
+
+Programmatic monitoring for dashboards and alerting:
+
+```go
+var m runtime.MemStats
+runtime.ReadMemStats(&m)
+
+fmt.Printf("Alloc: %d MB\n", m.Alloc/1024/1024)       // currently allocated
+fmt.Printf("TotalAlloc: %d MB\n", m.TotalAlloc/1024/1024) // cumulative
+fmt.Printf("Sys: %d MB\n", m.Sys/1024/1024)            // requested from OS
+fmt.Printf("NumGC: %d\n", m.NumGC)                      // completed collections
+fmt.Printf("LastPause: %d ms\n", m.PauseNs[(m.NumGC+255)%256]/1_000_000)
+```
+
+### GC pacing
+
+The GC pacer predicts when to start the next collection based on:
+
+1. **Live heap size** after the last collection
+2. **GOGC percentage** — how much growth to allow
+3. **GOMEMLIMIT** — soft ceiling (if set)
+4. **Current allocation rate** — how fast the heap is growing
+
+The pacer starts collection early enough to finish before hitting the target. Fast allocation rates cause earlier starts.
+
+## Allocation Rate Reduction
+
+**Diagnose:** 1- `go tool pprof -alloc_objects` — rank functions by allocation count; the top allocators are where allocation reduction will have the biggest GC impact 2- `GODEBUG=gctrace=1` — monitor GC frequency before and after reducing allocations; expect fewer GC cycles per second as allocation rate drops 3- Prometheus `rate(go_memstats_alloc_bytes_total[5m])` — track allocation rate trend in production; compare before/after deploy to detect regressions
+
+Reducing allocations helps more than tuning GOGC — it addresses the root cause instead of managing the symptom:
+
+- **Value types over pointer types** where possible — values stay on the stack (no GC), pointers escape to the heap
+- **Pool frequently allocated objects** with `sync.Pool` (see [memory.md](./memory.md))
+- **Preallocate slices and maps** — → See `samber/cc-skills-golang@golang-data-structures` skill
+- **Avoid interface boxing** in hot paths — use typed parameters or generics
+
+## GOMAXPROCS in Containers
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — look for high `runtime.schedule` or `runtime.findRunnable` overhead; this indicates too many P's competing for work or too few P's starving goroutines 2- `go tool trace` — check if goroutines are evenly distributed across P's; uneven distribution suggests GOMAXPROCS is misconfigured for the container 3- `GODEBUG=schedtrace=1000` — print scheduler state every second; look for `runqueue` imbalances or idle P's when work is available 4- `runtime.GOMAXPROCS(0)` — query the current value; if it returns the host CPU count (e.g., 64) instead of the container limit (e.g., 2), the runtime is over-scheduling 5- Prometheus `rate(process_cpu_seconds_total[5m])` — monitor CPU cores consumed in production; if consistently near GOMAXPROCS value, the app is CPU-saturated
+
+**Go 1.25+** improves container CPU detection, particularly for cgroup v2. The runtime sets `GOMAXPROCS` based on:
+
+- Logical CPUs on the machine
+- Process CPU affinity mask
+- cgroup CPU quota limits (on Linux)
+
+In a container with 2 CPU cores on a 64-core host running Go 1.25+ with **cgroup v2**, `GOMAXPROCS` is correctly set to 2 by default. For **cgroup v1** environments, validate the detected value at startup and consider using `go.uber.org/automaxprocs` to ensure correctness.
+
+**For Go 1.24 and earlier**, use the `go.uber.org/automaxprocs` library to handle container CPU detection:
+
+```go
+// Pre-Go 1.25: explicit container-aware detection
+import _ "go.uber.org/automaxprocs"
+
+func main() {
+    // GOMAXPROCS is now correctly set to container CPU limit
+    startServer()
+}
+```
+
+**Manual override** (if needed):
+
+```bash
+GOMAXPROCS=2 ./myapp
+GODEBUG=updatemaxprocs=0 ./myapp  # disable dynamic updates (Go 1.25+)
+```
+
+**Known limitations (Go 1.25)**: cgroup v1 on certain systems (Oracle OCPUs) may not properly detect Kubernetes CPU limits. Manually set `GOMAXPROCS` as a workaround in these cases.
+
+## Profile-Guided Optimization (PGO)
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — collect a representative production profile (30+ seconds); look for hot interface method calls and deep call chains that PGO can optimize via devirtualization and inlining 2- `go test -bench` — benchmark before and after placing `default.pgo`; expect 2-7% improvement on interface-heavy code, less on already-optimized paths
+
+Go 1.21+ supports PGO — the compiler uses a production CPU profile to make better inlining and devirtualization decisions. Expected improvement: 2-7% for minimal effort.
+
+**Workflow:**
+
+1. Collect a production CPU profile (30+ seconds of representative load):
+
+   ```bash
+   curl http://localhost:6060/debug/pprof/profile?seconds=60 > cpu.pprof
+   ```
+
+2. Place as `default.pgo` in the main package directory:
+
+   ```bash
+   cp cpu.pprof ./cmd/myapp/default.pgo
+   ```
+
+3. Build — `go build` auto-detects `default.pgo`:
+
+   ```bash
+   go build ./cmd/myapp
+   ```
+
+**What the compiler optimizes:**
+
+- **Inlining** — hot function calls are inlined more aggressively
+- **Devirtualization** — interface method calls with high probability of targeting specific types become direct calls
+
+**When it helps most:** code with many interface calls, hot inlining opportunities, deep call stacks. **When it helps least:** already-optimized code, memory-bound workloads.
+
+Rebuild profiles after significant code changes — stale profiles can mislead the compiler.
+
+## Logging Overhead in Hot Paths
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — look for `fmt.Sprintf`, `log.Printf`, or `slog.(*Logger).log` appearing in hot paths; these indicate log formatting consuming CPU even when the log level filters the message 2- `go build -gcflags="-m"` — check if log arguments escape to the heap; expect `"moved to heap"` for arguments boxed into `any` interface by logging functions 3- `go test -bench -benchmem` — benchmark with logging enabled vs disabled; if allocs/op doesn't change, the logger is allocating even when the level is off
+
+Log formatting allocates memory and consumes CPU even when the message is discarded because it's below the configured level:
+
+```go
+// Bad — fmt.Sprintf runs BEFORE the logger checks the level
+logger.Debug(fmt.Sprintf("processing item %d with data %v", item.ID, item.Data))
+
+// Good — slog defers formatting until level check passes (Go 1.21+)
+slog.Debug("processing item", slog.Int("id", item.ID), slog.Any("data", item.Data))
+
+// Best — LogAttrs: zero allocations when level is disabled
+slog.LogAttrs(ctx, slog.LevelDebug, "processing item",
+    slog.Int("id", item.ID))
+```
+
+In hot paths, even `slog.Any` can allocate. Prefer typed attributes: `slog.Int`, `slog.String`, `slog.Bool`.
+
+## Panic/Recover Cost
+
+**Diagnose:** 1- `go tool pprof` (CPU profile) — look for `runtime.gopanic` or `runtime.gorecover` in the profile; their presence in hot paths means panic/recover is being used for control flow 2- `go test -bench` — benchmark panic/recover vs error-return versions; expect 10-100x overhead from stack unwinding and defer execution
+
+`panic` triggers stack unwinding, running all deferred functions up the call stack. `recover` catches the panic but the unwinding itself is expensive. Never use panic/recover for control flow:
+
+```go
+// Bad — panic overhead for a normal condition
+defer func() { recover() }()
+v, _ := strconv.Atoi(s) // relies on panic for invalid input
+
+// Good — explicit error check, no panic overhead
+v, err := strconv.Atoi(s)
+if err != nil { continue }
+```
+
+Panic is appropriate only for truly unrecoverable situations (programmer errors, corrupted state). Always convert panics to errors at package boundaries.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/SKILL.md
new file mode 100644
index 00000000..7ea50fcf
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/SKILL.md
@@ -0,0 +1,69 @@
+---
+name: golang-popular-libraries
+description: "Recommends production-ready Golang libraries and frameworks. Apply when the user explicitly asks for library suggestions, wants to compare alternatives, needs to choose a library for a specific task, or when a new dependency is being added to the project."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.5"
+  openclaw:
+    emoji: "📚"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch WebSearch AskUserQuestion
+---
+
+**Persona:** You are a Go ecosystem expert. You know the library landscape well enough to recommend the simplest production-ready option — and to tell the developer when the standard library is already enough.
+
+# Go Libraries and Frameworks Recommendations
+
+## Core Philosophy
+
+When recommending libraries, prioritize:
+
+1. **Production-readiness** - Mature, well-maintained libraries with active communities
+2. **Simplicity** - Go's philosophy favors simple, idiomatic solutions
+3. **Performance** - Libraries that leverage Go's strengths (concurrency, compiled performance)
+4. **Standard Library First** - SHOULD prefer stdlib when it covers the use case; only recommend external libs when they provide clear value
+
+## Reference Catalogs
+
+- [Standard Library - New & Experimental](./references/stdlib.md) — v2 packages, promoted x/exp packages, golang.org/x extensions
+- [Libraries by Category](./references/libraries.md) — vetted third-party libraries for web, database, testing, logging, messaging, and more
+- [Development Tools](./references/tools.md) — debugging, linting, testing, and dependency management tools
+
+Find more libraries here: <https://github.com/avelino/awesome-go>
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information.
+
+## General Guidelines
+
+When recommending libraries:
+
+1. **Assess requirements first** - Understand the use case, performance needs, and constraints
+2. **Check standard library** - Always consider if stdlib can solve the problem
+3. **Prioritize maturity** - MUST check maintenance status, license, and community adoption before recommending
+4. **Consider complexity** - Simpler solutions are usually better in Go
+5. **Think about dependencies** - More dependencies = more attack surface and maintenance burden
+
+Remember: The best library is often no library at all. Go's standard library is excellent and sufficient for many use cases.
+
+## Anti-Patterns to Avoid
+
+- Over-engineering simple problems with complex libraries
+- Using libraries that wrap standard library functionality without adding value
+- Abandoned or unmaintained libraries: ask the developer before recommending these
+- Suggesting libraries with large dependency footprints for simple needs
+- Ignoring standard library alternatives
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-dependency-management` skill for adding, auditing, and managing dependencies
+- → See `samber/cc-skills-golang@golang-samber-do` skill for samber/do dependency injection details
+- → See `samber/cc-skills-golang@golang-samber-oops` skill for samber/oops error handling details
+- → See `samber/cc-skills-golang@golang-stretchr-testify` skill for testify testing details
+- → See `samber/cc-skills-golang@golang-grpc` skill for gRPC implementation details
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/evals/evals.json
new file mode 100644
index 00000000..dc9366d9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/evals/evals.json
@@ -0,0 +1,155 @@
+[
+  {
+    "id": 1,
+    "name": "stdlib-first-json",
+    "description": "encoding/json should be tried first even for high-throughput use cases; third-party libraries are only justified after profiling confirms JSON is the bottleneck",
+    "prompt": "I'm building a high-throughput Go API that processes thousands of JSON requests per second. A colleague says: 'You should use jsoniter or sonic from the start — encoding/json is known to be slow and you'll need the performance. There's no reason to start with a worse library when we know we'll need the fast one.' Is this advice correct? What JSON library should I use?",
+    "trap": "The colleague's argument sounds pragmatic — why start with a known-slower library if you'll switch later anyway? But the skill teaches stdlib-first: add dependencies only when profiling confirms they are the bottleneck. The model should push back on the colleague and recommend starting with encoding/json.",
+    "assertions": [
+      {"id": "1.1", "text": "Pushes back on the colleague's advice — recommends starting with encoding/json despite the high-throughput context"},
+      {"id": "1.2", "text": "Explains that the standard library should be the default until profiling confirms JSON is actually the bottleneck"},
+      {"id": "1.3", "text": "Notes that encoding/json may be sufficient — thousands of requests per second does not automatically justify a third-party library"},
+      {"id": "1.4", "text": "Recommends profiling first (pprof) before reaching for jsoniter or sonic"},
+      {"id": "1.5", "text": "If mentioning alternatives (jsoniter, sonic), frames them as options for after measurement proves stdlib is insufficient, not as defaults"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "pgx-over-lib-pq",
+    "description": "Tests whether the model recommends pgx over lib/pq for PostgreSQL when advanced features or performance matter",
+    "prompt": "I'm starting a new Go project that needs to connect to PostgreSQL. Which driver should I use?",
+    "trap": "Without the skill, the model recommends lib/pq because it's more commonly seen in tutorials, missing that pgx is faster and has more features",
+    "assertions": [
+      {"id": "2.1", "text": "Recommends pgx (github.com/jackc/pgx) as the primary recommendation"},
+      {"id": "2.2", "text": "Mentions that pgx is faster than lib/pq"},
+      {"id": "2.3", "text": "Notes that pgx supports all PostgreSQL types and advanced features"},
+      {"id": "2.4", "text": "May mention lib/pq as an alternative but positions pgx as the preferred choice"},
+      {"id": "2.5", "text": "Does NOT recommend lib/pq as the primary choice without mentioning pgx"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "chi-for-minimal-router",
+    "description": "Tests whether the model recommends chi for lightweight routing needs instead of full frameworks",
+    "prompt": "I need a simple HTTP router for my Go REST API. It just needs path parameters and middleware support. I want to stay close to net/http. What should I use?",
+    "trap": "Without the skill, the model recommends Gin or Echo (full frameworks) when chi's lightweight, net/http-compatible router is a better fit",
+    "assertions": [
+      {"id": "3.1", "text": "Recommends chi (github.com/go-chi/chi) as a strong match for the stated requirements"},
+      {"id": "3.2", "text": "Explains that chi is lightweight and composes well with net/http"},
+      {"id": "3.3", "text": "Notes that chi has minimal dependencies"},
+      {"id": "3.4", "text": "May mention Gin/Echo as alternatives but positions chi as the better fit for staying close to net/http"},
+      {"id": "3.5", "text": "Does NOT recommend a full framework (Gin, Echo, Fiber) as the primary choice when the user explicitly wants to stay close to net/http"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "slog-over-external-loggers",
+    "description": "Tests whether the model considers log/slog (Go 1.21+) before recommending external logging libraries",
+    "prompt": "I need structured logging in my Go 1.22 project. What library should I use?",
+    "trap": "Without the skill, the model jumps to zap or zerolog without mentioning that Go 1.21+ has log/slog in the standard library",
+    "assertions": [
+      {"id": "4.1", "text": "Mentions log/slog as the standard library option for structured logging (available since Go 1.21)"},
+      {"id": "4.2", "text": "Presents slog as a viable option, not just an afterthought"},
+      {"id": "4.3", "text": "If recommending external libraries (zap, zerolog), explains what specific value they add over slog"},
+      {"id": "4.4", "text": "Does NOT skip standard library consideration entirely"},
+      {"id": "4.5", "text": "May mention zap/zerolog for specific use cases (zero-allocation hot paths, etc.)"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "sqlc-vs-orm-decision",
+    "description": "Tests whether the model presents sqlc as an alternative to ORMs when the user values type safety and compile-time checks",
+    "prompt": "I want to interact with my PostgreSQL database in Go. I want maximum type safety and want the compiler to catch SQL errors. What should I use?",
+    "trap": "Without the skill, the model recommends GORM (most popular ORM) which uses runtime reflection, missing sqlc which generates type-safe code from SQL at compile time",
+    "assertions": [
+      {"id": "5.1", "text": "Recommends sqlc (github.com/sqlc-dev/sqlc) as a primary option for compile-time SQL safety"},
+      {"id": "5.2", "text": "Explains that sqlc generates type-safe Go code from SQL with no runtime reflection"},
+      {"id": "5.3", "text": "Mentions that GORM uses runtime reflection which does not catch SQL errors at compile time"},
+      {"id": "5.4", "text": "May also mention ent as a code-generated alternative"},
+      {"id": "5.5", "text": "Does NOT recommend only GORM when the user explicitly asks for compile-time safety"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "rate-limiter-stdlib-first",
+    "description": "Tests whether the model recommends golang.org/x/time/rate before third-party rate limiters",
+    "prompt": "I need to add rate limiting to my Go HTTP API. What should I use?",
+    "trap": "Without the skill, the model recommends a third-party rate limiter without mentioning the official golang.org/x/time/rate package",
+    "assertions": [
+      {"id": "6.1", "text": "Recommends golang.org/x/time/rate as the standard/official option"},
+      {"id": "6.2", "text": "Explains that it implements a token bucket algorithm"},
+      {"id": "6.3", "text": "May mention third-party alternatives (Tollbooth/limiter) for HTTP middleware integration"},
+      {"id": "6.4", "text": "Does NOT skip the official x/time/rate package entirely"},
+      {"id": "6.5", "text": "Explains when third-party middleware might be preferred (e.g., per-IP limiting, distributed rate limiting)"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "franz-go-for-kafka",
+    "description": "Tests whether the model recommends franz-go for Kafka instead of only the legacy sarama client",
+    "prompt": "I need a Kafka client for my Go application. What library should I use?",
+    "trap": "Without the skill, the model recommends sarama (the legacy, most commonly referenced Kafka client) instead of franz-go which is modern, higher-performance, and better maintained",
+    "assertions": [
+      {"id": "7.1", "text": "Recommends franz-go (github.com/twmb/franz-go) as a primary recommendation"},
+      {"id": "7.2", "text": "Describes franz-go as modern, high-performance, and feature-complete"},
+      {"id": "7.3", "text": "Does NOT recommend only sarama without mentioning franz-go"},
+      {"id": "7.4", "text": "May mention sarama as an alternative but positions franz-go as the preferred modern choice"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "check-maintenance-before-recommending",
+    "description": "Tests whether the model checks maintenance status before recommending a library",
+    "prompt": "I need a logging library for my Go project. Someone suggested Logrus. Should I use it?",
+    "trap": "Without the skill, the model recommends Logrus without noting its maintenance status (deprecated in favor of structured logging)",
+    "assertions": [
+      {"id": "8.1", "text": "Mentions that Logrus is deprecated or in maintenance mode"},
+      {"id": "8.2", "text": "Suggests alternatives: log/slog (stdlib), zap, or zerolog"},
+      {"id": "8.3", "text": "Explains that for new projects, a maintained alternative is preferred"},
+      {"id": "8.4", "text": "Does NOT unconditionally recommend Logrus without mentioning its deprecation status"},
+      {"id": "8.5", "text": "Prioritizes maturity and maintenance status in the recommendation"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "avoid-unnecessary-wrappers",
+    "description": "Tests that the model warns against libraries that just wrap stdlib without adding value",
+    "prompt": "I found a Go library that provides helper functions for HTTP request handling, basically wrapping net/http with slightly more convenient syntax. Should I add it to my project?",
+    "trap": "Without the skill, the model evaluates only the convenience factor without considering the anti-pattern of wrapping stdlib without real value",
+    "assertions": [
+      {"id": "9.1", "text": "Warns against using libraries that wrap standard library functionality without adding meaningful value"},
+      {"id": "9.2", "text": "Explains that more dependencies increase attack surface and maintenance burden"},
+      {"id": "9.3", "text": "Recommends evaluating whether net/http itself is sufficient"},
+      {"id": "9.4", "text": "Mentions the anti-pattern of adding dependencies for marginal convenience"},
+      {"id": "9.5", "text": "Suggests considering the library's dependency footprint relative to the value it provides"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "testcontainers-for-integration",
+    "description": "testcontainers-go is preferred over shared docker-compose for integration tests because each test gets an isolated, fresh container",
+    "prompt": "We already have a docker-compose.yml for local development with PostgreSQL and Redis. A teammate says: 'For integration tests, just document that developers should run docker-compose up before running go test -tags=integration. That way we reuse the same infrastructure we already have and don't add a new dependency.' Is this a good approach? What would you recommend instead?",
+    "trap": "The teammate's approach seems pragmatic — reuse existing infrastructure, avoid adding testcontainers-go as a dependency. The skill teaches testcontainers-go is better for test isolation: each test run gets a fresh container (no state leakage between test runs), tests are fully self-contained (no 'remember to run docker-compose up'), and CI doesn't need to maintain a shared running stack.",
+    "assertions": [
+      {"id": "10.1", "text": "Pushes back on the teammate's docker-compose approach — identifies its key problems: shared state between test runs, manual setup requirement, CI complexity"},
+      {"id": "10.2", "text": "Recommends testcontainers-go as the preferred alternative for programmatic, isolated integration tests"},
+      {"id": "10.3", "text": "Explains the key advantage: each test suite gets a fresh container spun up and torn down automatically — no state leakage, no manual prerequisites"},
+      {"id": "10.4", "text": "Notes that testcontainers-go tests are fully self-contained: go test -tags=integration works without any external setup"},
+      {"id": "10.5", "text": "Acknowledges the dependency cost but frames it as justified by the isolation and reproducibility benefits"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "slices-maps-packages-go121",
+    "description": "Tests whether the model recommends the standard library slices/maps packages (Go 1.21+) instead of external utility libraries for basic operations",
+    "prompt": "I need utility functions for slice operations in my Go 1.22 project — things like contains, sort, filter, and reverse. What should I use?",
+    "trap": "Without the skill, the model recommends samber/lo or a similar utility library for basic operations that the standard library slices package already provides since Go 1.21",
+    "assertions": [
+      {"id": "11.1", "text": "Recommends the standard library slices package (Go 1.21+) for Contains, Sort, Reverse, and similar operations"},
+      {"id": "11.2", "text": "Does NOT recommend only external libraries for basic slice operations that slices package covers"},
+      {"id": "11.3", "text": "May mention samber/lo or similar for functional operations (Map, Filter, Reduce) not in stdlib slices"},
+      {"id": "11.4", "text": "Distinguishes between operations covered by stdlib (Contains, Sort, Reverse, Compact, BinarySearch) and those requiring external libraries (Map, Filter, GroupBy)"},
+      {"id": "11.5", "text": "Applies the 'standard library first' principle"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/libraries.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/libraries.md
new file mode 100644
index 00000000..7322e889
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/libraries.md
@@ -0,0 +1,195 @@
+# Top Go Libraries by Category
+
+## Web Frameworks
+
+**Gin** (<https://github.com/gin-gonic/gin>) High-performance HTTP web framework with minimalist API. Up to 40x faster than some alternatives. Great for building REST APIs and microservices.
+
+**Echo** (<https://github.com/labstack/echo>) Minimalist, extensible web framework. Clean middleware system, excellent performance. Good for both REST APIs and traditional web apps.
+
+**Fiber** (<https://github.com/gofiber/fiber>) Express.js-inspired web framework built on Fasthttp. Very fast, easy for Node.js developers transitioning to Go.
+
+**Chi** (<https://github.com/go-chi/chi>) Lightweight, idiomatic router that composes well with net/http. Minimal dependencies, great for smaller projects.
+
+## HTTP Clients
+
+**Resty** (<https://github.com/go-resty/resty>) Simple HTTP and REST client for Go. Inspired by Ruby's rest-client. Great for API consumption with retry support.
+
+**Req** (<https://github.com/imroc/req>) Simple Go HTTP client with "black magic" - less code, more efficiency. Clean API for common operations.
+
+## ORM & Database
+
+**GORM** (<https://github.com/go-gorm/gorm>) Feature-complete ORM library. Developer-friendly, supports associations, hooks, auto-migrations. The most popular Go ORM.
+
+**SQLx** (<https://github.com/jmoiron/sqlx>) Extensions for database/sql that provide convenience while maintaining power. Type-safe, performant query helpers.
+
+**Ent** (<https://github.com/ent/ent>) Entity framework for Go. Code-generated, type-safe ORM with excellent support for complex queries and graph traversals.
+
+**Sqlc** (<https://github.com/sqlc-dev/sqlc>) Generate type-safe Go code from SQL. No runtime reflection, compiler-checked queries.
+
+## Database Drivers
+
+**go-sql-driver/mysql** (<https://github.com/go-sql-driver/mysql>) MySQL driver for Go's database/sql package. Maintained by the Go team, reliable and performant.
+
+**lib/pq** (<https://github.com/lib/pq>) Pure Go PostgreSQL driver. The gold standard for PostgreSQL in Go.
+
+**pgx** (<https://github.com/jackc/pgx>) PostgreSQL driver with advanced features. Faster than lib/pq, supports all PostgreSQL types.
+
+**redis-go** (<https://github.com/redis/go-redis>) Redis client for Go. Cluster support, modern Redis features, well-maintained.
+
+**mongo-go-driver** (<https://github.com/mongodb/mongo-go-driver>) Official MongoDB driver for Go. Supports async operations, transactions (in newer versions).
+
+## Testing
+
+**Testify** (<https://github.com/stretchr/testify>) Sacred extension to the testing package. Assertions, mocking, suite testing. Essential for Go testing.
+
+**gomock** (<https://github.com/uber-go/mock>) Mocking framework for Go interfaces. Widely used, integrates well with testing package.
+
+**go-sqlmock** (<https://github.com/DATA-DOG/go-sqlmock>) SQL mock driver for testing database operations. Test database code without a real database.
+
+**testcontainers-go** (<https://golang.testcontainers.org>) Integration testing with real dependencies in Docker containers. Spin up databases, message queues, etc.
+
+**httptest** (standard library) Testing HTTP servers/clients. Built into Go, no external dependency needed.
+
+## Command Line and Configuration
+
+**Cobra** (<https://github.com/spf13/cobra>) Commander for modern Go CLI applications. Powerful subcommand system, flags, auto-generated docs. Industry standard for CLIs.
+
+**Viper** (<https://github.com/spf13/viper>) Go configuration with fangs. Works with Cobra, supports multiple formats (JSON, YAML, TOML, env).
+
+**urfave/cli** (<https://github.com/urfave/cli>) Simple, fast, fun package for building command line apps. Alternative to Cobra.
+
+**Koanf** (<https://github.com/knadh/koanf>) Lightweight, extensible library for reading config. Support for JSON, YAML, TOML, env, command line.
+
+**env** (from <https://github.com/caarlos0/env>) Parse environment variables into Go structs with defaults. Simple, type-safe, no struct tags.
+
+## Logging
+
+**Zap** (<https://github.com/uber-go/zap>) Fast, structured, leveled logging. Uber's production logger, zero-allocation in hot paths.
+
+**Zerolog** (<https://github.com/rs/zerolog>) Zero-allocation JSON logging. Very fast, simple API, leveled logging.
+
+**Logrus** (<https://github.com/sirupsen/logrus>) Structured logger for Go. Mature, widely-used, plugin architecture. Note: deprecated in favor of structured logging.
+
+## Validation
+
+**validator** (<https://github.com/go-playground/validator>) Go struct validation. Tags-based, extensive validators, cross-field validation.
+
+**ozzo-validation** (<https://github.com/go-ozzo/ozzo-validation>) Fast validation library. Modern alternative for struct validation.
+
+## JSON Processing
+
+**jsoniter** (<https://github.com/json-iterator/go>) High-performance 100% compatible drop-in replacement for encoding/json. Faster JSON parsing.
+
+## Authentication & Authorization
+
+**Casbin** (<https://github.com/casbin/casbin>) Authorization library supporting ACL, RBAC, ABAC. Policy-based access control.
+
+**JWT** (<https://github.com/golang-jwt/jwt>) JSON Web Token implementation for Go. Full-featured, widely-used.
+
+## Caching
+
+**Ristretto** (<https://github.com/dgraph-io/ristretto>) High-performance memory-bound Go cache.
+
+**BigCache** (<https://github.com/allegro/bigcache>) Efficient key/value cache for gigabytes of data. Sharded, optimized for high throughput.
+
+**go-cache** (<https://github.com/patrickmn/go-cache>) In-memory key-value store with expiration. Thread-safe, simple API.
+
+## Rate Limiting
+
+**Tollbooth** (<https://github.com/ulule/limiter>) Rate limiting HTTP middleware. Simple, volume-based limiting, easy to use.
+
+**golang.org/x/time/rate** (<https://golang.org/x/time/rate>) Standard library rate limiter. Token bucket algorithm, well-maintained.
+
+## Concurrency & Goroutines
+
+**Watermill** (<https://github.com/ThreeDotsLabs/watermill>) Event-driven framework for Go. Message streams, event sourcing, CQRS patterns.
+
+**ro** (<https://github.com/samber/ro>) Reactive programming for Go. Event-driven streams with operators for data flow transformation.
+
+## Messaging
+
+**franz-go** (<https://github.com/twmb/franz-go>) Kafka client for Go. Modern, high-performance, feature-complete client with excellent documentation and community support.
+
+**amqp091-go** (<https://github.com/rabbitmq/amqp091-go>) Official RabbitMQ client for Go. Maintained by RabbitMQ team, supports AMQP 0.9.1 protocol.
+
+**NATS.go** (<https://github.com/nats-io/nats.go>) Client for NATS messaging system. Simple, secure, performant communications.
+
+**Temporal Go SDK** (<https://github.com/temporalio/sdk-go>) Durable execution framework for building reliable async applications. Workflows, activities, and long-running processes.
+
+**DBOS** (<https://github.com/dbos-inc/dbos-transact-golang>) Backend framework for Go applications with durable execution, built on PostgreSQL.
+
+## Types and Data Structures
+
+**gods** (<https://github.com/emirpasic/gods>) Go Data Structures - Sets, Lists, Stacks, Maps, Trees, Queues, and much more
+
+**bloom** (<https://github.com/bits-and-blooms/bloom>) Bloom filter implementation. Memory-efficient set membership testing.
+
+**hyperloglog** (<https://github.com/clarkduvall/hyperloglog>) HyperLogLog implementation for Go. Memory-efficient cardinality estimation for large datasets.
+
+**Carbon** (<https://github.com/uniplaces/carbon>) Simple, semantic time library for Go. Time parsing, formatting, manipulation.
+
+**google/uuid** (<https://github.com/google/uuid>) Generate and parse UUIDs. Official Google library, RFC 4122 compliant.
+
+## Database Schema Migration
+
+**golang-migrate** (<https://github.com/golang-migrate/migrate>) Database migration tool. Supports multiple databases, version control for schemas.
+
+**goose** (<https://github.com/pressly/goose>) Database migration tool. SQL or Go migrations, supports multiple databases.
+
+## WebSockets
+
+**gorilla/websocket** (<https://github.com/gorilla/websocket>) WebSocket package for Go. Mature, widely-used, part of Gorilla toolkit.
+
+## gRPC
+
+**grpc-go** (<https://github.com/grpc/grpc-go>) The Go language implementation of gRPC. HTTP/2 based RPC framework by Google.
+
+## GraphQL
+
+**gqlgen** (<https://github.com/99designs/gqlgen>) Go generate based graphql server library. Type-safe, schema-first, code generation.
+
+**graphql-go** (<https://github.com/graphql-go/graphql>) Implementation of GraphQL for Go. Query execution, schema parsing.
+
+## File Watching
+
+**fsnotify** (<https://github.com/fsnotify/fsnotify>) Cross-platform file system watcher for Go. Watch for file changes efficiently.
+
+## Retry Logic
+
+**avast/retry-go** (<https://github.com/avast/retry-go>) Retry mechanism for Go with exponential backoff. Simple, configurable.
+
+## Error Handling
+
+**pkg/errors** (<https://github.com/pkg/errors>) Legacy projects only. Prefer stdlib `errors`, `fmt.Errorf("%w")`, and `errors.Join` for new code; use a structured error library only when you need stack traces or rich context.
+
+**oops** (<https://github.com/samber/oops>) Error handling library with stack traces, hints, and context. Rich error wrapping with type-safe error chains.
+
+## Metrics & Monitoring
+
+**prometheus/client_golang** (<https://github.com/prometheus/client_golang>) Prometheus instrumentation library for Go. Metrics, histograms, counters, gauges.
+
+**opentelemetry-go** (<https://github.com/open-telemetry/opentelemetry-go>) OpenTelemetry Go API and SDK. Distributed tracing, metrics, logs.
+
+## API Documentation
+
+**swag** (<https://github.com/swaggo/swag>) Auto-generate OpenAPI/Swagger specs from Go code annotations. Parses comment-based annotations (`@Summary`, `@Param`, `@Success`, `@Router`, etc.) on handler functions to produce `swagger.json`/`swagger.yaml`. Integrates with Gin (`gin-swagger`), Echo (`echo-swagger`), Fiber (`fiber-swagger`), Chi, and net/http. Supports Swagger 2.0 and OpenAPI 3.x output.
+
+## Dependency Injection
+
+**do** (<https://github.com/samber/do>) Dependency injection library for Go. Simple, runtime DI with service locator pattern and health checks.
+
+**Wire** (<https://github.com/google/wire>) Code-generated dependency injection for Go. Compile-time dependency injection without reflection.
+
+**Dig** (<https://github.com/uber-go/dig>) Dependency injection container for Go. Runtime DI with lifecycle management.
+
+**Fx** (<https://github.com/uber-go/fx>) Application framework for Go. Built on Dig, provides lifecycle management, dependency injection, and observability.
+
+## Functional Programming & Utilities
+
+**lo** (<https://github.com/samber/lo>) A generics-based helper library for Go. Slice, map, and tuple operations with functional programming style.
+
+**mo** (<https://github.com/samber/mo>) Monads and functional programming helpers for Go. Option, Either, Try, and other functional patterns.
+
+## Excel & Spreadsheet
+
+**Excelize** (<https://github.com/qax-os/excelize>) Go library for reading and writing Excel files (XLSX). Supports formatting, charts, and complex spreadsheet operations.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/stdlib.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/stdlib.md
new file mode 100644
index 00000000..68c1e4a5
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/stdlib.md
@@ -0,0 +1,41 @@
+# Standard Library - New & Experimental
+
+The Go standard library continues to evolve with v2 packages and experimental features. **Prefer these over external libraries when available.**
+
+## V2 Packages (API Breaking Changes)
+
+**math/rand/v2** (Go 1.22+) Improved random number generation with better algorithms (ChaCha8, PCG). Auto-seeded, no more rand.Seed() needed.
+
+**encoding/json/v2** (experimental stdlib package behind `GOEXPERIMENT=jsonv2`) Next-generation JSON encoding/decoding. Evaluate deliberately; most production code should keep `encoding/json` unless the project explicitly opts into the experiment.
+
+## New Packages (Promoted from x/exp)
+
+**slices** (Go 1.21+) Generic slice operations: BinarySearch, Clone, Compact, Compare, Contains, Delete, Insert, Replace, Reverse, Sort. Reduces the need for external libraries.
+
+**maps** (Go 1.21+) Generic map operations: Clone, Copy, DeleteFunc, Equal, EqualFunc. Go 1.23+ adds iterator helpers such as All, Collect, Insert, Keys, and Values.
+
+**cmp** (Go 1.21+) Comparison utilities: Compare, Or, Ordered. Used with the slices/maps packages.
+
+**iter** (Go 1.23+) Iterator support for sequences. Enables range-over functions and integrates with slices/maps methods.
+
+**unique** (Go 1.23+) Value canonicalization and interning. Efficient deduplication of comparable values.
+
+**log/slog** (Go 1.21+) Structured logging for the standard library. Alternative to external logging libraries for many use cases.
+
+**weak** (Go 1.24+) Weak references for garbage collection. Useful for caches and observers.
+
+**structs** (Go 1.23+) Structure layout control and introspection.
+
+## golang.org/x (Official Extensions)
+
+**golang.org/x/oauth2** OAuth2 client implementation. Supports multiple providers (Google, GitHub, etc.). Official OAuth2 client.
+
+**golang.org/x/crypto** Additional cryptographic algorithms: bcrypt, blowfish, scrypt, ssh, acme (Let's Encrypt), pbkdf2.
+
+**golang.org/x/net** Network utilities: websocket, context, proxy, trace, http2, ipv4/ipv6, netutil.
+
+**golang.org/x/text** Text processing: encoding, unicode, cases, search, language (language tag parsing and matching).
+
+**golang.org/x/sync** Extended synchronization: errgroup, singleflight, semaphore.
+
+**golang.org/x/sys/cpu** CPU feature detection for architecture-specific optimized code. Use it only when dispatching between measured implementations; prefer portable stdlib code first.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/tools.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/tools.md
new file mode 100644
index 00000000..afbef1c0
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-popular-libraries/references/tools.md
@@ -0,0 +1,25 @@
+# Go Development Tools
+
+## Debugging
+
+**Delve** (<https://github.com/go-delve/delve>) Debugger for the Go programming language. Source-level debugger for Go programs.
+
+## Linting & Code Quality
+
+**golangci-lint** (<https://github.com/golangci/golangci-lint>) Fast Go linters runner. Runs multiple linters in parallel, highly configurable, the industry standard for Go code quality.
+
+## Testing
+
+**gotest** (standard library - go test) Built-in testing command for Go. Run tests, generate coverage reports, benchmark code.
+
+**cover** (golang.org/x/tools/cmd/cover) Coverage analysis tool for Go tests. Generate and visualize test coverage reports.
+
+**benchstat** (golang.org/x/perf/cmd/benchstat) Benchmark comparison tool. Computes statistical comparisons of benchmark results to determine performance significance.
+
+**goleak** (<https://github.com/uber-go/goleak>) Goroutine leak detector for Go tests. Verifies that tests do not leak goroutines between runs.
+
+## Dependency Management
+
+**go-mod-outdated** (<https://github.com/psampaz/go-mod-outdated>) Find outdated dependencies in your go.mod. Helps keep dependencies up to date securely.
+
+**goweight** (<https://github.com/jondot/goweight>) Analyze package dependencies and calculate weight. Helps identify heavy dependencies and transitive bloat.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/SKILL.md
new file mode 100644
index 00000000..89930465
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/SKILL.md
@@ -0,0 +1,120 @@
+---
+name: golang-project-layout
+description: "Provides a guide for setting up Golang project layouts and workspaces. Use when starting a new Go project, organizing an existing codebase, setting up a monorepo with multiple packages, creating CLI tools with multiple main packages, deciding between cmd/internal/pkg directory conventions, or discussing package restructuring, package splits, or module splits."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.0"
+  openclaw:
+    emoji: "📁"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion
+---
+
+**Persona:** You are a Go project architect. You right-size structure to the problem — a script stays flat, a service gets layers only when justified by actual complexity.
+
+# Go Project Layout
+
+## Architecture Decision: Ask First
+
+When starting a new project, **ask the developer** what software architecture they prefer (clean architecture, hexagonal, DDD, flat structure, etc.). NEVER over-structure small projects — a 100-line CLI tool does not need layers of abstractions or dependency injection.
+
+→ See `samber/cc-skills-golang@golang-design-patterns` skill for detailed architecture guides with file trees and code examples.
+
+## Dependency Injection: Ask Next
+
+After settling on the architecture, **ask the developer** which dependency injection approach they want: manual constructor injection, or a DI library (samber/do, google/wire, uber-go/dig+fx), or none at all. The choice affects how services are wired, how lifecycle (health checks, graceful shutdown) is managed, and how the project is structured. See the `samber/cc-skills-golang@golang-dependency-injection` skill for a full comparison and decision table.
+
+## 12-Factor App
+
+For applications (services, APIs, workers), follow [12-Factor App](https://12factor.net/) conventions: config via environment variables, logs to stdout, stateless processes, graceful shutdown, backing services as attached resources, and admin tasks as one-off commands (e.g., `cmd/migrate/`).
+
+## Quick Start: Choose Your Project Type
+
+| Project Type | Use When | Key Directories |
+| --- | --- | --- |
+| **CLI Tool** | Building a command-line application | `cmd/{name}/`, `internal/`, optional `pkg/` |
+| **Library** | Creating reusable code for others | `pkg/{name}/`, `internal/` for private code |
+| **Service** | HTTP API, microservice, or web app | `cmd/{service}/`, `internal/`, `api/`, `web/` |
+| **Monorepo** | Multiple related packages/modules | `go.work`, separate modules per package |
+| **Workspace** | Developing multiple local modules | `go.work`, replace directives |
+
+## Module Naming Conventions
+
+### Module Name (go.mod)
+
+Your module path in `go.mod` should:
+
+- **MUST match your repository URL**: `github.com/username/project-name`
+- **Use lowercase only**: `github.com/you/my-app` (not `MyApp`)
+- **Use hyphens for multi-word**: `user-auth` not `user_auth` or `userAuth`
+- **Be semantic**: Name should clearly express purpose
+
+**Examples:**
+
+```go
+// ✅ Good
+module github.com/jdoe/payment-processor
+module github.com/company/cli-tool
+
+// ❌ Bad
+module myproject
+module github.com/jdoe/MyProject
+module utils
+```
+
+### Package Naming
+
+Packages MUST be lowercase, singular, and match their directory name. → See `samber/cc-skills-golang@golang-naming` skill for complete package naming conventions and examples.
+
+## Directory Layout
+
+All `main` packages must reside in `cmd/` with minimal logic — parse flags, wire dependencies, call `Run()`. Business logic belongs in `internal/` or `pkg/`. Use `internal/` for non-exported packages, `pkg/` only when code is useful to external consumers.
+
+See [directory layout examples](references/directory-layouts.md) for universal, small project, and library layouts, plus common mistakes.
+
+## Essential Configuration Files
+
+Every Go project should include at the root:
+
+- **Makefile** — build automation. See [Makefile template](assets/Makefile)
+- **.gitignore** — git ignore patterns. See [.gitignore template](assets/.gitignore)
+- **.golangci.yml** — linter config. See the `samber/cc-skills-golang@golang-lint` skill for the recommended configuration
+
+For application configuration with Cobra + Viper, see [config reference](references/config.md).
+
+## Tests, Benchmarks, and Examples
+
+Co-locate `_test.go` files with the code they test. Use `testdata/` for fixtures. See [testing layout](references/testing-layout.md) for file naming, placement, and organization details.
+
+## Go Workspaces
+
+Use `go.work` when developing multiple related modules in a monorepo. See [workspaces](references/workspaces.md) for setup, structure, and commands.
+
+## Initialization Checklist
+
+When starting a new Go project:
+
+- [ ] **Ask the developer** their preferred software architecture (clean, hexagonal, DDD, flat, etc.)
+- [ ] **Ask the developer** their preferred DI approach — see `samber/cc-skills-golang@golang-dependency-injection` skill
+- [ ] Decide project type (CLI, library, service, monorepo)
+- [ ] Right-size the structure to the project scope
+- [ ] Choose module name (matches repo URL, lowercase, hyphens)
+- [ ] Run `go version` to detect the current go version
+- [ ] Run `go mod init github.com/user/project-name`
+- [ ] Create `cmd/{name}/main.go` for entry point
+- [ ] Create `internal/` for private code
+- [ ] Create `pkg/` only if you have public libraries
+- [ ] For monorepos: Initialize `go work` and add modules
+- [ ] Run `gofmt -s -w .` to ensure formatting
+- [ ] Add `.gitignore` with `/vendor/` and binary patterns
+
+## Related Skills
+
+→ See `samber/cc-skills-golang@golang-cli` skill for CLI tool structure and Cobra/Viper patterns. → See `samber/cc-skills-golang@golang-dependency-injection` skill for DI approach comparison and wiring. → See `samber/cc-skills-golang@golang-lint` skill for golangci-lint configuration. → See `samber/cc-skills-golang@golang-continuous-integration` skill for CI/CD pipeline setup. → See `samber/cc-skills-golang@golang-design-patterns` skill for architectural patterns.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/assets/.gitignore b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/assets/.gitignore
new file mode 100644
index 00000000..de4d97a1
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/assets/.gitignore
@@ -0,0 +1,41 @@
+# Binaries for programs and plugins
+*.exe
+*.exe~
+*.dll
+*.so
+*.dylib
+bin/
+dist/
+
+# Test binary, built with `go test -c`
+*.test
+
+# Output of the go coverage tool
+*.out
+coverage.out
+coverage.html
+
+# Dependency directories
+vendor/
+
+# Go workspace file
+go.work.sum
+
+# IDE specific files
+.idea/
+.vscode/
+*.swp
+*.swo
+*~
+.DS_Store
+
+# Environment files
+.env
+.env.local
+.env.*.local
+
+# Build artifacts
+/tmp/
+
+# Air hot reload
+tmp/
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/assets/Makefile b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/assets/Makefile
new file mode 100644
index 00000000..fe51da4b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/assets/Makefile
@@ -0,0 +1,110 @@
+# Variables
+BINARY_NAME=myapp
+GO=go
+GOFLAGS=-v
+
+# Build variables
+VERSION?=$(shell git describe --tags --always --dirty)
+LDFLAGS=-ldflags "-X main.Version=$(VERSION)"
+
+.PHONY: all build clean test lint run install help
+.PHONY: benchmark lint-fix outdated weight audit
+.PHONY: watch-test watch-build watch-run
+
+all: clean lint test build
+
+## build: Build the application
+build:
+	@echo "Building $(BINARY_NAME)..."
+	$(GO) build $(GOFLAGS) $(LDFLAGS) -o bin/$(BINARY_NAME) ./cmd/server
+
+## build-all: Build all binaries in cmd/
+build-all:
+	@echo "Building all binaries..."
+	$(GO) build $(GOFLAGS) $(LDFLAGS) -o bin/ ./cmd/...
+
+## clean: Clean build artifacts
+clean:
+	@echo "Cleaning..."
+	rm -rf bin/
+	rm -f coverage.out
+
+## test: Run all tests
+test:
+	@echo "Running tests..."
+	$(GO) test -v -race -coverprofile=coverage.out ./...
+	$(GO) tool cover -html=coverage.out -o coverage.html
+
+## test-short: Run tests without long-running ones
+test-short:
+	$(GO) test -v -short ./...
+
+## benchmark: Run benchmarks
+benchmark:
+	@echo "Running benchmarks..."
+	$(GO) test -bench=. -benchmem ./...
+
+## lint: Run linter
+lint:
+	@echo "Running linter..."
+	golangci-lint run ./...
+
+## lint-fix: Run linter and auto-fix issues
+lint-fix:
+	@echo "Running linter with auto-fix..."
+	golangci-lint run --fix ./...
+
+## fmt: Format code
+fmt:
+	$(GO) fmt ./...
+	$(GO) vet ./...
+
+## outdated: Check for outdated dependencies
+outdated:
+	@echo "Checking for outdated dependencies..."
+	go list -u -m -json all | go-mod-outdated -update -direct
+
+## weight: Analyze package dependencies
+weight:
+	@echo "Analyzing package weight..."
+	goweight
+
+## audit: Audit dependencies for security vulnerabilities
+audit:
+	@echo "Auditing dependencies..."
+	govulncheck ./...
+
+## run: Build and run the application
+run: build
+	@echo "Running $(BINARY_NAME)..."
+	./bin/$(BINARY_NAME)
+
+## install: Install dependencies
+install:
+	$(GO) mod download
+	$(GO) mod tidy
+
+## deps-update: Update dependencies (patch only for safety)
+deps-update:
+	$(GO) get -u=patch ./...
+	$(GO) mod tidy
+
+## watch-test: Run tests on file changes (requires air)
+watch-test:
+	@echo "Watching for changes to run tests..."
+	air -test
+
+## watch-build: Rebuild on file changes (requires air)
+watch-build:
+	@echo "Watching for changes to rebuild..."
+	air -build
+
+## watch-run: Rebuild and run on file changes (requires air)
+watch-run:
+	@echo "Watching for changes to run..."
+	air
+
+## help: Show this help message
+help:
+	@echo "Usage: make [target]"
+	@sed -n 's/^##//p' $(MAKEFILE_LIST) | column -t -s ':' | sed -e 's/^/ /'
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/evals/evals.json
new file mode 100644
index 00000000..ea34018b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/evals/evals.json
@@ -0,0 +1,156 @@
+[
+  {
+    "id": 1,
+    "name": "ask-architecture-before-structuring",
+    "description": "Tests whether the model asks the developer about architecture preference before imposing one",
+    "prompt": "I'm starting a new Go web service project. Set up the directory structure for me.",
+    "trap": "Without the skill, the model immediately generates a directory structure without asking. The skill says to ASK the developer what architecture they prefer before structuring.",
+    "assertions": [
+      {"id": "1.1", "text": "Asks the developer which software architecture they prefer (clean, hexagonal, DDD, flat, etc.)"},
+      {"id": "1.2", "text": "Asks about the project scope/size to right-size the structure"},
+      {"id": "1.3", "text": "Does NOT immediately impose a specific architecture without asking"},
+      {"id": "1.4", "text": "Mentions dependency injection approach as a follow-up question"},
+      {"id": "1.5", "text": "Mentions that small projects should not be over-structured"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "cmd-directory-minimal-logic",
+    "description": "Tests whether the model keeps cmd/ main.go minimal with no business logic",
+    "prompt": "I'm organizing a Go project with an HTTP server. Here's my cmd/server/main.go that has 200 lines including request parsing, database queries, and response formatting. Is this OK?",
+    "trap": "Without the skill, the model may accept the large main.go or only suggest minor improvements. The skill says cmd/ MUST contain only main.go with minimal logic -- parse flags, wire dependencies, call Run().",
+    "assertions": [
+      {"id": "2.1", "text": "Says business logic does NOT belong in cmd/server/main.go"},
+      {"id": "2.2", "text": "Says cmd/ should contain minimal logic: parse flags, wire dependencies, call Run()"},
+      {"id": "2.3", "text": "Recommends moving business logic to internal/ or pkg/"},
+      {"id": "2.4", "text": "main.go should primarily do dependency wiring and startup"},
+      {"id": "2.5", "text": "NEVER put request parsing, database queries, or response formatting in cmd/"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "no-src-utils-helpers-common",
+    "description": "Tests whether the model avoids Java-style src/ directory and generic package names",
+    "prompt": "I'm organizing my Go project. I created these directories: src/ for source code, utils/ for utility functions, helpers/ for helper functions, and common/ for shared code. Here's my structure:\n\n```\nmyproject/\n  src/\n    main.go\n  utils/\n    string_utils.go\n  helpers/\n    http_helper.go\n  common/\n    types.go\n```\n\nDoes this look good?",
+    "trap": "Without the skill, the model may accept some of these (especially utils/) as reasonable. The skill explicitly calls out src/, utils/, helpers/, common/ as anti-patterns.",
+    "assertions": [
+      {"id": "3.1", "text": "Rejects src/ directory (Go doesn't use /src, it's a Java pattern)"},
+      {"id": "3.2", "text": "Rejects utils/ as a generic package name"},
+      {"id": "3.3", "text": "Rejects helpers/ as a generic package name"},
+      {"id": "3.4", "text": "Rejects common/ as a generic package name"},
+      {"id": "3.5", "text": "Suggests domain-specific package names instead (e.g. format/, stringconv/)"},
+      {"id": "3.6", "text": "Recommends putting main.go inside cmd/{name}/ not at root or in src/"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "module-naming-conventions",
+    "description": "Tests whether the model follows Go module naming conventions",
+    "prompt": "I'm initializing a new Go module. Which of these module names is correct?\n\n1. `module myproject`\n2. `module github.com/jdoe/MyProject`\n3. `module github.com/jdoe/my-project`\n4. `module github.com/jdoe/my_project`\n5. `module utils`",
+    "trap": "Without the skill, the model may accept multiple options or not know the specific conventions. The skill has clear rules: must match repo URL, lowercase only, hyphens for multi-word.",
+    "assertions": [
+      {"id": "4.1", "text": "Identifies option 3 (github.com/jdoe/my-project) as correct"},
+      {"id": "4.2", "text": "Rejects option 1 (myproject) -- must match repository URL"},
+      {"id": "4.3", "text": "Rejects option 2 (MyProject) -- must be lowercase only"},
+      {"id": "4.4", "text": "Rejects option 4 (my_project) -- use hyphens not underscores"},
+      {"id": "4.5", "text": "Rejects option 5 (utils) -- not semantic, doesn't match a repo URL"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "internal-vs-pkg-decision",
+    "description": "Tests whether the model correctly decides between internal/ and pkg/ based on export requirements",
+    "prompt": "I'm building a Go project with both a web service and a shared logging library that other teams want to import. I also have some private request parsing code. Where should I put each?",
+    "trap": "Without the skill, the model may put everything in internal/ or everything in pkg/. The skill says internal/ for non-exported, pkg/ only when code is useful to external consumers.",
+    "assertions": [
+      {"id": "5.1", "text": "Puts the shared logging library in pkg/ (useful to external consumers)"},
+      {"id": "5.2", "text": "Puts the private request parsing code in internal/ (not exported)"},
+      {"id": "5.3", "text": "Explains that internal/ cannot be imported by external packages (Go enforces this)"},
+      {"id": "5.4", "text": "Mentions that pkg/ should only be used when code is genuinely intended for external use"},
+      {"id": "5.5", "text": "Service/business logic goes in internal/ by default"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "workspace-when-to-use",
+    "description": "Tests whether the model recommends go.work only for multi-module scenarios, not single-module projects",
+    "prompt": "I have a single Go module project (one go.mod) with about 10 packages. A colleague suggested I add go.work for better organization. Should I?",
+    "trap": "Without the skill, the model may recommend go.work for any multi-package project. The skill says don't use workspaces for single-module projects or simple applications.",
+    "assertions": [
+      {"id": "6.1", "text": "Recommends AGAINST using go.work for a single-module project"},
+      {"id": "6.2", "text": "Explains that go.work is for multiple related Go modules that import each other"},
+      {"id": "6.3", "text": "Mentions that a single module with multiple packages does not need a workspace"},
+      {"id": "6.4", "text": "Lists valid use cases: monorepo with separate modules, local cross-module development"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "twelve-factor-app-conventions",
+    "description": "Tests whether the model applies 12-Factor App principles for Go services",
+    "prompt": "I'm building a Go microservice that reads its database URL from a config.yaml file checked into the repository. It writes logs to a file at /var/log/myapp.log. Is this a good approach?",
+    "trap": "Without the skill, the model may accept file-based config and log files as reasonable. The skill says to follow 12-Factor: config via environment variables, logs to stdout.",
+    "assertions": [
+      {"id": "7.1", "text": "Recommends reading database URL from environment variables, not a checked-in config file"},
+      {"id": "7.2", "text": "Recommends writing logs to stdout, not to a file"},
+      {"id": "7.3", "text": "References or describes 12-Factor App principles"},
+      {"id": "7.4", "text": "Mentions that sensitive values (like DB URLs) should never be in config files committed to source control"},
+      {"id": "7.5", "text": "Explains WHY: environment-based config allows different values per deployment without code changes"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "library-layout-no-cmd",
+    "description": "Tests whether the model uses the correct layout for a Go library (no cmd/, public packages at root level)",
+    "prompt": "I'm creating a Go library for other developers to import (a logging package). How should I structure the project? Should I put the code in cmd/ or pkg/?",
+    "trap": "Without the skill, the model may use the application layout (cmd/, internal/, pkg/) for a library. The skill shows that libraries put public API in root-level directories, no cmd/ unless example binaries.",
+    "assertions": [
+      {"id": "8.1", "text": "Public API packages are at the root level (e.g. logger/), NOT inside pkg/ or cmd/"},
+      {"id": "8.2", "text": "No cmd/ directory (unless for example binaries)"},
+      {"id": "8.3", "text": "Uses internal/ for private implementation details"},
+      {"id": "8.4", "text": "Includes example/ directory for usage examples"},
+      {"id": "8.5", "text": "Structure follows the library layout pattern, not the application layout pattern"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "test-file-colocation",
+    "description": "Tests whether the model co-locates test files with the code they test",
+    "prompt": "I'm organizing tests in my Go project. Should I create a separate tests/ directory at the root to hold all test files, or should I put them somewhere else?",
+    "trap": "Without the skill, the model may accept a centralized tests/ directory (common in Python/Java). The skill says co-locate _test.go files with the code they test.",
+    "assertions": [
+      {"id": "9.1", "text": "Recommends co-locating test files with the code they test (same directory)"},
+      {"id": "9.2", "text": "Test files use the _test.go suffix"},
+      {"id": "9.3", "text": "Does NOT recommend a centralized tests/ directory for unit tests"},
+      {"id": "9.4", "text": "Mentions testdata/ directory for test fixtures"},
+      {"id": "9.5", "text": "Distinguishes between white-box (same package) and black-box (package_test) testing approaches"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "config-sensitive-values-env-only",
+    "description": "Tests whether the model requires sensitive configuration values from env vars or secret managers, never config files",
+    "prompt": "I'm setting up configuration for my Go service using Viper. I want to put the database password, API keys, and JWT secret in my config.yaml for convenience. Then I'll use mapstructure tags to load them. Good idea?",
+    "trap": "Without the skill, the model may accept putting secrets in config files as long as the file is gitignored. The skill says sensitive values MUST come from env vars or secret managers, NEVER config files.",
+    "assertions": [
+      {"id": "10.1", "text": "Rejects putting database password, API keys, and JWT secret in config.yaml"},
+      {"id": "10.2", "text": "Recommends environment variables for sensitive values"},
+      {"id": "10.3", "text": "May suggest a secret manager as an alternative"},
+      {"id": "10.4", "text": "Config files are acceptable for non-sensitive values (port, log level, etc.)"},
+      {"id": "10.5", "text": "Explains WHY: config files can be accidentally committed, leaked in backups, or visible to other processes"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "multiple-binaries-cmd-structure",
+    "description": "Tests whether the model creates separate subdirectories in cmd/ for each binary",
+    "prompt": "My Go project needs three binaries: an API server, a CLI tool, and a database migration utility. How should I organize the cmd/ directory?",
+    "trap": "Without the skill, the model may put all three in a single cmd/main.go with subcommands. The skill shows separate subdirectories in cmd/ for each binary.",
+    "assertions": [
+      {"id": "11.1", "text": "Creates separate subdirectories: cmd/server/, cmd/cli/, cmd/migrate/ (or similar names)"},
+      {"id": "11.2", "text": "Each subdirectory has its own main.go with package main"},
+      {"id": "11.3", "text": "Each binary can be built independently (go build ./cmd/server, etc.)"},
+      {"id": "11.4", "text": "Mentions go build ./cmd/... to build all binaries at once"},
+      {"id": "11.5", "text": "Business logic is in internal/, not duplicated across cmd/ directories"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/config.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/config.md
new file mode 100644
index 00000000..6c6965f2
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/config.md
@@ -0,0 +1,51 @@
+# Application Configuration with Cobra + Viper
+
+→ See `samber/cc-skills-golang@golang-cli` skill for complete Cobra+Viper setup, flag binding, precedence rules, and configuration layering.
+
+## Where Config Lives
+
+```
+myapp/
+├── cmd/myapp/
+│   ├── main.go                # Entry point
+│   ├── root.go                # Root command + Viper init
+│   ├── serve.go               # Subcommand with flags
+│   └── config.go              # Config struct + loader
+└── configs/
+    └── config.yaml            # Default config file
+```
+
+## Config Struct
+
+Define configuration as a struct with `mapstructure` tags matching your YAML keys:
+
+```go
+// cmd/myapp/config.go
+package main
+
+import (
+    "fmt"
+
+    "github.com/spf13/viper"
+)
+
+type Config struct {
+    Port     int    `mapstructure:"port"`
+    Host     string `mapstructure:"host"`
+    LogLevel string `mapstructure:"log-level"`
+    Database struct {
+        DSN     string `mapstructure:"dsn"`
+        MaxConn int    `mapstructure:"max-conn"`
+    } `mapstructure:"database"`
+}
+
+func loadConfig() (Config, error) {
+    var cfg Config
+    if err := viper.Unmarshal(&cfg); err != nil {
+        return Config{}, fmt.Errorf("unmarshaling config: %w", err)
+    }
+    return cfg, nil
+}
+```
+
+Configuration MUST be loaded from env vars, files, or flags — NEVER hardcoded. Sensitive values MUST come from env vars or secret managers, NEVER config files.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/directory-layouts.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/directory-layouts.md
new file mode 100644
index 00000000..720bd9c9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/directory-layouts.md
@@ -0,0 +1,151 @@
+# Directory Layouts
+
+## Universal Layout (Most Projects)
+
+```
+project/
+├── cmd/                    # Entry points - ONE subdirectory per main package
+│   ├── server/            # Main application #1
+│   │   └── main.go
+│   ├── client/            # Main application #2
+│   │   └── main.go
+│   └── migrate/           # Main application #3
+│       └── main.go
+│   └── cli/               # Main application #4
+│       └── main.go
+│   └── worker/            # Main application #5
+│       └── main.go
+├── internal/              # Private application code (`internal/` MUST be used for non-exported packages)
+│   ├── app/              # Application initialization
+│   ├── config/           # Configuration loading
+│   ├── handler/          # HTTP/request handlers
+│   ├── model/            # Data models/domain
+│   └── service/          # Business logic
+├── pkg/                   # Public libraries (optional - only if useful to others)
+│   └── logger/
+│       └── logger.go
+├── api/                   # API definitions (optional)
+│   └── openapi.yaml
+├── configs/               # Configuration files (optional)
+│   └── config.yaml
+├── scripts/               # Build/deployment scripts (optional)
+├── go.mod
+├── go.sum
+├── Makefile               # Build automation
+├── .gitignore             # Git ignore patterns
+├── .golangci.yml          # Linter configuration
+├── LICENSE                # License file
+└── README.md
+```
+
+## Small Projects (Single Binary)
+
+For simple tools, keep it minimal:
+
+```
+my-tool/
+├── cmd/
+│   └── my-tool/
+│       └── main.go        # Single main package
+├── internal/
+│   └── core.go            # Application logic
+├── go.mod
+├── Makefile               # Build automation (optional but recommended)
+├── .gitignore             # Git ignore patterns
+├── .golangci.yml          # Linter configuration (optional)
+├── LICENSE                # License file (recommended)
+└── README.md
+```
+
+## Libraries (Reusable Code)
+
+```
+my-library/
+├── example/               # Example
+├── logger/                # Public package
+│   ├── logger.go
+│   └── logger_test.go
+├── internal/
+│   └── impl/              # Private implementation details
+│       └── core.go
+├── go.mod
+├── go.sum
+├── Makefile               # Build automation
+├── .gitignore             # Git ignore patterns
+├── .golangci.yml          # Linter configuration
+├── LICENSE                # License file
+└── README.md
+```
+
+**Key points for libraries:**
+
+- Put public API in root-level directories (e.g., `logger/`)
+- Use `internal/` for private implementation
+- Don't use `cmd/` (unless you have example binaries)
+
+## The cmd/ Directory Convention
+
+**CRITICAL**: All `main` packages must reside in `cmd/`. `cmd/` MUST contain only `main.go` with minimal logic — parse flags, wire dependencies, call `Run()`. NEVER put business logic in `cmd/` — it belongs in `internal/` or `pkg/`.
+
+### Single Application
+
+```
+cmd/
+└── myapp/
+    └── main.go    // package main
+```
+
+### Multiple Applications
+
+When you need multiple binaries (e.g., server, CLI tool, migration utility):
+
+```
+cmd/
+├── server/
+│   └── main.go        // Runs the API server
+├── client/
+│   └── main.go        // CLI client tool
+├── worker/
+│   └── main.go        // Background worker
+└── migrate/
+    └── main.go        // Database migration utility
+```
+
+Each `main.go`:
+
+- Declares `package main`
+- Has its own `func main()`
+- Can be built independently: `go build ./cmd/...`
+
+**Building all binaries:**
+
+```bash
+go build ./cmd/...        # Build all main packages
+go build ./cmd/server     # Build specific binary
+```
+
+## Common Mistakes to Avoid
+
+### Don't Do This
+
+```
+myproject/
+├── src/              # Go doesn't use /src (Java pattern)
+├── main.go           # Don't put main at root
+├── utils/            # Generic package name
+├── helpers/          # Generic package name
+└── common/           # Generic package name
+```
+
+### Do This Instead
+
+```
+myproject/
+├── cmd/
+│   └── myapp/
+│       └── main.go   # Main in cmd/
+├── internal/
+│   ├── util/         # Specific utility names
+│   └── format/       # Or domain-specific names
+└── pkg/              # Only if useful to others
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/testing-layout.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/testing-layout.md
new file mode 100644
index 00000000..afbaa6b7
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/testing-layout.md
@@ -0,0 +1,215 @@
+# Tests, Benchmarks, and Examples
+
+## File Naming Conventions
+
+Go uses suffix-based naming for test-related files:
+
+| Suffix | Purpose | Build Tag |
+| --- | --- | --- |
+| `_test.go` | Tests | Not included in normal builds |
+| `_bench_test.go` | Benchmarks | Not included in normal builds |
+| `_example_test.go` | Examples that verify output | Not included in normal builds |
+| No suffix | Regular code | Included in all builds |
+
+## Where to Place Tests
+
+**Co-locate tests with the code they test:**
+
+```
+internal/
+├── handler/
+│   ├── handler.go          # Production code
+│   ├── handler_test.go     # Tests for handler
+│   └── handler_bench_test.go  # Benchmarks (optional)
+├── service/
+│   ├── service.go
+│   └── service_test.go
+└── model/
+    ├── user.go
+    └── user_test.go
+
+pkg/
+└── logger/
+    ├── logger.go
+    └── logger_test.go
+```
+
+**Key principles:**
+
+- Tests live in the **same package** as the code (e.g., `package handler`)
+- Test files are in the **same directory** as the code they test
+- Use `_test.go` suffix for all test files
+
+## Test Package Options
+
+When writing tests, you have two options for the package declaration:
+
+**Option 1: Same package (white-box testing)**
+
+```go
+package handler  // Same package, can access unexported
+
+import "testing"
+
+func TestHandler(t *testing.T) {
+    // Can access unexported functions and types
+    internalFunction()
+}
+```
+
+**Option 2: Package with `_test` suffix (black-box testing)**
+
+```go
+package handler_test  // Different package, only exported API
+
+import "testing"
+
+func TestHandler(t *testing.T) {
+    // Can only access exported functions and types
+    handler.PublicMethod()
+}
+```
+
+**When to use each:**
+
+- Use **same package** for unit tests that need to test internals
+- Use **`_test` suffix** for integration/behavioral tests
+
+## Benchmarks
+
+Benchmarks use the `_bench_test.go` suffix and contain functions with the `Benchmark` prefix.
+
+## Examples
+
+Examples serve two purposes: documentation and verification.
+
+**In libraries** - use `*_example_test.go` files:
+
+```
+pkg/
+└── logger/
+    ├── logger.go
+    ├── logger_test.go
+    └── logger_example_test.go     # Examples
+```
+
+**Example function format:**
+
+```go
+package logger
+
+import "fmt"
+
+func ExampleLogger_Info() {
+    log := New()
+    log.Info("processing started")
+    log.Info("processing complete")
+    // Output:
+    // INFO: processing started
+    // INFO: processing complete
+}
+```
+
+**Key points:**
+
+- Example functions must start with `Example`
+- The `// Output:` comment verifies the output
+- Examples are runnable tests: `go test` will fail if output doesn't match
+- `godoc` displays examples as documentation
+- File name format: `{package}_example_test.go` (e.g., `logger_example_test.go`)
+
+**For executable examples** (standalone demo programs):
+
+```
+examples/
+└── basic-usage/
+    └── main.go                    # Executable example
+```
+
+## Test Utilities
+
+When you have shared test helpers, use a dedicated package:
+
+```
+test/
+└── testutils/
+    ├── mock.go
+    └── fixtures.go
+```
+
+Or use the `internal/testutil` pattern:
+
+```
+internal/
+└── testutil/
+    ├── mock.go
+    └── fixtures.go
+```
+
+## Test Fixtures
+
+Fixtures are test data files used across multiple tests. Use one of these patterns:
+
+**Option 1: Local testdata directory** (package-specific fixtures)
+
+```
+internal/
+└── handler/
+    ├── handler.go
+    ├── handler_test.go
+    └── testdata/
+        ├── users.json
+        ├── request_valid.json
+        └── request_invalid.json
+```
+
+**Option 2: Global test directory** (shared across packages)
+
+```
+test/
+└── fixtures/
+    ├── users.json
+    ├── products.json
+    └── responses/
+        ├── success.json
+        └── error.json
+```
+
+**Option 3: Embedded fixtures** (Go 1.16+, use `//go:embed`)
+
+```
+internal/
+└── handler/
+    ├── handler.go
+    ├── handler_test.go
+    └── testdata/
+        └── users.json
+```
+
+**Important notes:**
+
+- Go ignores the `testdata` directory when building regular packages
+- Use `testdata/` for package-specific test data
+- Use `test/fixtures/` for cross-package shared fixtures
+- Don't put `.go` files in `testdata/` - they will be ignored
+
+## Running Tests
+
+```bash
+go test ./...                    # Run all tests
+go test ./internal/handler       # Test specific package
+go test -v ./...                 # Verbose output
+go test -race ./...              # Race detection
+go test -cover ./...             # Coverage report
+go test -short ./...             # Skip long-running tests
+```
+
+## Test File Summary
+
+| File Type | Suffix | Package | Purpose |
+| --- | --- | --- | --- |
+| Test | `*_test.go` | `package X` or `package X_test` | Unit/integration tests |
+| Benchmark | `*_bench_test.go` | Same as code | Performance tests |
+| Example (godoc) | `*_example_test.go` | Same as code | Documentation + verification |
+| Executable example | No suffix | `package main` | Standalone demo programs |
+| Test utilities | `*_test.go` | `package testutil` | Shared test helpers |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/workspaces.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/workspaces.md
new file mode 100644
index 00000000..24f23197
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-project-layout/references/workspaces.md
@@ -0,0 +1,106 @@
+<!-- markdownlint-disable ol-prefix -->
+
+# Go Workspaces for Multi-Package Repositories
+
+## When to Use Workspaces
+
+Use Go workspaces (`go.work`) when:
+
+- Developing multiple related modules that import each other
+- Building a monorepo with separate Go modules
+- Testing local changes across module boundaries
+- Avoiding `replace` directives in every module
+
+**Don't use workspaces for:**
+
+- Single-module projects
+- Projects that only use external dependencies
+- Simple applications
+
+## Workspace Structure
+
+Example monorepo with multiple modules:
+
+```
+my-monorepo/
+├── go.work                    # Workspace file (see below)
+├── pkg/
+│   ├── auth/                 # Module 1: github.com/user/my-monorepo/pkg/auth
+│   │   ├── go.mod
+│   │   ├── cmd/
+│   │   │   └── auth-server/
+│   │   │       └── main.go
+│   │   └── internal/
+│   │       └── handler/
+│   │           └── auth.go
+│   └── user/                 # Module 2: github.com/user/my-monorepo/pkg/user
+│       ├── go.mod
+│       ├── cmd/
+│       │   └── user-server/
+│       │       └── main.go
+│       └── internal/
+│           └── handler/
+│               └── user.go
+├── cmd/
+│   └── api/                 # Module 3: github.com/user/my-monorepo/cmd/api
+│       ├── go.mod
+│       └── main.go
+└── tools/
+    └── cli/                  # Module 4: github.com/user/my-monorepo/tools/cli
+        ├── go.mod
+        └── cmd/
+            └── mycli/
+                └── main.go
+```
+
+## Creating a Workspace
+
+1. **Initialize the workspace:**
+
+```bash
+go work init
+```
+
+This creates `go.work`:
+
+```go
+go 1.21
+
+use (
+    ./services/auth
+    ./services/user
+    ./shared/libs
+    ./tools/cli
+)
+```
+
+2. **Add modules to workspace:**
+
+```bash
+go work use ./services/auth
+go work use ./services/user
+go work use ./shared/libs
+```
+
+3. **Use modules without replace directives:**
+
+In `services/user/go.mod`:
+
+```go
+module github.com/user/my-monorepo/services/user
+
+go 1.21
+
+require github.com/user/my-monorepo/shared/libs v0.0.0
+```
+
+The workspace automatically resolves `shared/libs` to the local directory.
+
+## Workspace Commands
+
+```bash
+go work init              # Initialize new workspace
+go work use ./path/to/mod # Add module to workspace
+go work use -rm ./path    # Remove module from workspace
+go work sync              # Sync workspace with module changes
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/SKILL.md
new file mode 100644
index 00000000..29dc8c94
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/SKILL.md
@@ -0,0 +1,283 @@
+---
+name: golang-safety
+description: "Defensive Golang coding to prevent panics, silent data corruption, and subtle runtime bugs. Use when encountering nil panics, append aliasing, map concurrent access, float comparison pitfalls, or zero-value design questions. Also use when reviewing code for nil-safety, numeric conversion overflow, resource lifecycle issues (defer in loops), or defensive copying of slices and maps."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.1"
+  openclaw:
+    emoji: "🛡"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent
+---
+
+**Persona:** You are a defensive Go engineer. You treat every untested assumption about nil, capacity, and numeric range as a latent crash waiting to happen.
+
+# Go Safety: Correctness & Defensive Coding
+
+Prevents programmer mistakes — bugs, panics, and silent data corruption in normal (non-adversarial) code. Security handles attackers; safety handles ourselves.
+
+## Best Practices Summary
+
+1. **Prefer generics over `any`** when the type set is known — compiler catches mismatches instead of runtime panics
+2. **Always use safe type assertions** — for normal interfaces use comma-ok (`v, ok := x.(T)`); for reflection in Go 1.25+ prefer `reflect.TypeAssert[T](value)` over `value.Interface().(T)`.
+3. **Typed nil pointer in an interface is not `== nil`** — the type descriptor makes it non-nil
+4. **Writing to a nil map panics** — always initialize before use
+5. **`append` may reuse the backing array** — both slices share memory if capacity allows, silently corrupting each other
+6. **Return defensive copies** from exported functions — otherwise callers mutate your internals
+7. **`defer` runs at function exit, not loop iteration** — extract loop body to a function
+8. **Integer conversions truncate silently** — `int64` to `int32` wraps without error
+9. **Float arithmetic is not exact** — use epsilon comparison or `math/big`
+10. **Design useful zero values** — nil map fields panic on first write; use lazy init
+11. **Use `sync.Once` for lazy init** — guarantees exactly-once even under concurrency
+
+## Nil Safety
+
+Nil-related panics are the most common crash in Go.
+
+### The nil interface trap
+
+Interfaces store (type, value). An interface is `nil` only when both are nil. Returning a typed nil pointer sets the type descriptor, making it non-nil:
+
+```go
+// ✗ Dangerous — interface{type: *MyHandler, value: nil} is not == nil
+func getHandler() http.Handler {
+    var h *MyHandler // nil pointer
+    if !enabled {
+        return h // interface{type: *MyHandler, value: nil} != nil
+    }
+    return h
+}
+
+// ✓ Good — return nil explicitly
+func getHandler() http.Handler {
+    if !enabled {
+        return nil // interface{type: nil, value: nil} == nil
+    }
+    return &MyHandler{}
+}
+```
+
+### Nil map, slice, and channel behavior
+
+| Type    | Index into nil | Write to nil   | Len/Cap of nil | Range over nil |
+| ------- | -------------- | -------------- | -------------- | -------------- |
+| Map     | Zero value     | **panic**      | 0              | 0 iterations   |
+| Slice   | **panic**      | **panic**      | 0              | 0 iterations   |
+| Channel | Blocks forever | Blocks forever | 0              | Blocks forever |
+
+```go
+// ✗ Bad — nil map panics on write
+var m map[string]int
+m["key"] = 1
+
+// ✓ Good — initialize or lazy-init in methods
+m := make(map[string]int)
+
+func (r *Registry) Add(name string, val int) {
+    if r.items == nil { r.items = make(map[string]int) }
+    r.items[name] = val
+}
+```
+
+See **[Nil Safety Deep Dive](./references/nil-safety.md)** for nil receivers, nil in generics, and nil interface performance.
+
+## Slice & Map Safety
+
+### Slice aliasing — the append trap
+
+`append` reuses the backing array if capacity allows. Both slices then share memory:
+
+```go
+// ✗ Dangerous — a and b share backing array
+a := make([]int, 3, 5)
+b := append(a, 4)
+b[0] = 99 // also modifies a[0]
+
+// ✓ Good — full slice expression forces new allocation
+b := append(a[:len(a):len(a)], 4)
+```
+
+### Map concurrent access
+
+Maps MUST NOT be accessed concurrently — → see `samber/cc-skills-golang@golang-concurrency` for sync primitives.
+
+See **[Slice and Map Deep Dive](./references/slice-map-safety.md)** for range pitfalls, subslice memory retention, and `slices.Clone`/`maps.Clone`.
+
+## Numeric Safety
+
+### Implicit type conversions truncate silently
+
+```go
+// ✗ Bad — silently wraps around if val > math.MaxInt32 (3B becomes -1.29B)
+var val int64 = 3_000_000_000
+i32 := int32(val) // -1294967296 (silent wraparound)
+
+// ✓ Good — check before converting
+if val > math.MaxInt32 || val < math.MinInt32 {
+    return fmt.Errorf("value %d overflows int32", val)
+}
+i32 := int32(val)
+```
+
+### Float comparison
+
+```go
+// ✗ Bad — floating point arithmetic is not exact
+var a, b, c float64 = 0.1, 0.2, 0.3
+a+b == c // false
+
+// ✓ Good — use epsilon comparison
+const epsilon = 1e-9
+math.Abs((a+b)-c) < epsilon // true
+```
+
+### Division by zero
+
+Integer division by zero panics. Float division by zero produces `+Inf`, `-Inf`, or `NaN`.
+
+```go
+func avg(total, count int) (int, error) {
+    if count == 0 {
+        return 0, errors.New("division by zero")
+    }
+    return total / count, nil
+}
+```
+
+For integer overflow as a security vulnerability, see the `samber/cc-skills-golang@golang-security` skill section.
+
+## Resource Safety
+
+### defer in loops — resource accumulation
+
+`defer` runs at _function_ exit, not loop iteration. Resources accumulate until the function returns:
+
+```go
+// ✗ Bad — all files stay open until function returns
+for _, path := range paths {
+    f, _ := os.Open(path)
+    defer f.Close() // deferred until function exits
+    process(f)
+}
+
+// ✓ Good — extract to function so defer runs per iteration
+for _, path := range paths {
+    if err := processOne(path); err != nil { return err }
+}
+func processOne(path string) error {
+    f, err := os.Open(path)
+    if err != nil { return err }
+    defer f.Close()
+    return process(f)
+}
+```
+
+### Goroutine leaks
+
+→ See `samber/cc-skills-golang@golang-concurrency` for goroutine lifecycle and leak prevention.
+
+## Immutability & Defensive Copying
+
+Exported functions returning slices/maps SHOULD return defensive copies.
+
+### Protecting struct internals
+
+```go
+// ✗ Bad — exported slice field, anyone can mutate
+type Config struct {
+    Hosts []string
+}
+
+// ✓ Good — unexported field with accessor returning a copy
+type Config struct {
+    hosts []string
+}
+
+func (c *Config) Hosts() []string {
+    return slices.Clone(c.hosts)
+}
+```
+
+## Initialization Safety
+
+### Zero-value design
+
+Design types so `var x MyType` is safe — prevents "forgot to initialize" bugs:
+
+```go
+var mu sync.Mutex   // ✓ usable at zero value
+var buf bytes.Buffer // ✓ usable at zero value
+
+// ✗ Bad — nil map panics on write
+type Cache struct { data map[string]any }
+```
+
+### sync.Once for lazy initialization
+
+```go
+type DB struct {
+    once sync.Once
+    conn *sql.DB
+}
+
+func (db *DB) connection() *sql.DB {
+    db.once.Do(func() {
+        db.conn, _ = sql.Open("postgres", connStr)
+    })
+    return db.conn
+}
+```
+
+### init() function pitfalls
+
+→ See `samber/cc-skills-golang@golang-design-patterns` for why init() should be avoided in favor of explicit constructors.
+
+## Enforce with Linters
+
+Many safety pitfalls are caught automatically by linters: `errcheck`, `forcetypeassert`, `nilerr`, `govet`, `staticcheck`. See the `samber/cc-skills-golang@golang-lint` skill for configuration and usage.
+
+### Go 1.25+ reflection type assertions
+
+For reflection code, prefer `reflect.TypeAssert[T]` over `value.Interface().(T)`.
+
+```go
+v := reflect.ValueOf(x)
+if s, ok := reflect.TypeAssert[string](v); ok {
+    use(s)
+}
+```
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-concurrency` skill for concurrent access patterns and sync primitives
+- → See `samber/cc-skills-golang@golang-data-structures` skill for slice/map internals, capacity growth, and container/ packages
+- → See `samber/cc-skills-golang@golang-error-handling` skill for nil error interface trap
+- → See `samber/cc-skills-golang@golang-security` skill for security-relevant safety issues (memory safety, integer overflow)
+- → See `samber/cc-skills-golang@golang-troubleshooting` skill for debugging panics and race conditions
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Bare type assertion `v := x.(T)` | Panics on type mismatch, crashing the program. Use `v, ok := x.(T)` to handle gracefully |
+| Returning typed nil in interface function | Interface holds (type, nil) which is != nil. Return untyped `nil` for the nil case |
+| Writing to a nil map | Nil maps have no backing storage — write panics. Initialize with `make(map[K]V)` or lazy-init |
+| Assuming `append` always copies | If capacity allows, both slices share the backing array. Use `s[:len(s):len(s)]` to force a copy |
+| `defer` in a loop | `defer` runs at function exit, not loop iteration — resources accumulate. Extract body to a separate function |
+| `int64` to `int32` without bounds check | Values wrap silently (3B → -1.29B). Check against `math.MaxInt32`/`math.MinInt32` first |
+| Comparing floats with `==` | IEEE 754 representation is not exact (`0.1+0.2 != 0.3`). Use `math.Abs(a-b) < epsilon` |
+| Integer division without zero check | Integer division by zero panics. Guard with `if divisor == 0` before dividing |
+| Returning internal slice/map reference | Callers can mutate your struct's internals through the shared backing array. Return a defensive copy |
+| Multiple `init()` with ordering assumptions | `init()` execution order across files is unspecified. → See `samber/cc-skills-golang@golang-design-patterns` — use explicit constructors |
+| Blocking forever on nil channel | Nil channels block on both send and receive. Always initialize before use |
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/evals/evals.json
new file mode 100644
index 00000000..cd28420e
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/evals/evals.json
@@ -0,0 +1,930 @@
+[
+  {
+    "id": 1,
+    "name": "typed-nil-error-interface-trap",
+    "description": "Returns untyped nil on success, not typed *ConfigError nil pointer through error interface",
+    "prompt": "In package `validator`, write a function `Validate(cfg Config) error` where Config has fields `Host string` and `Port int`. The function should check if Host is empty or Port is out of range (1-65535). Use a local `*ConfigError` variable to accumulate the first error found, then return it at the end. ConfigError is a struct with a `Field string` and an `Error() string` method.\n\nWrite the full code including the Config struct, ConfigError struct with its Error method, and the Validate function.",
+    "trap": "Model declares `var configErr *ConfigError` and returns it directly — `return configErr` wraps a typed nil pointer in the error interface, making the returned error non-nil even when configErr is nil",
+    "assertions": [
+      {
+        "id": "1.1",
+        "text": "Returns untyped nil on valid config — the success path must use `return nil` (not `return configErr` where configErr is *ConfigError), because a typed nil pointer wrapped in an error interface is non-nil"
+      },
+      {
+        "id": "1.2",
+        "text": "No typed nil pointer leaked through the error interface — `var configErr *ConfigError` followed by `return configErr` creates an interface{type: *ConfigError, value: nil} which is != nil"
+      },
+      {
+        "id": "1.3",
+        "text": "ConfigError.Error() returns a useful message including the Field name"
+      },
+      {
+        "id": "1.4",
+        "text": "Validates both Host and Port conditions independently, not short-circuiting on first error if using accumulation pattern"
+      }
+    ]
+  },
+  {
+    "id": 2,
+    "name": "prevent-slice-aliasing-append",
+    "description": "Append-safe function prevents corrupting caller's backing array",
+    "prompt": "In package `sliceutil`, write a function `AddDefaults(base []string, defaults []string) []string` that appends any items from `defaults` that aren't already in `base`, and returns the extended slice. Keep it simple — just use append.",
+    "trap": "Model uses `base = append(base, v)` directly — if base has excess capacity, append writes into the caller's backing array without allocating, silently mutating data the caller still references",
+    "assertions": [
+      {
+        "id": "2.1",
+        "text": "Does not modify caller's input slice — `base = append(base, v)` silently corrupts the caller's backing array if capacity allows; must create a new slice first"
+      },
+      {
+        "id": "2.2",
+        "text": "Uses full-slice expression `base[:len(base):len(base)]`, `slices.Clone(base)`, or `copy` to prevent aliasing before appending new elements"
+      },
+      {
+        "id": "2.3",
+        "text": "Correctly checks membership — only appends items from defaults that are not already present in base"
+      },
+      {
+        "id": "2.4",
+        "text": "Does not modify the defaults slice either — both inputs are treated as read-only"
+      }
+    ]
+  },
+  {
+    "id": 3,
+    "name": "defensive-copies-for-collection-getters",
+    "description": "Collection getters return defensive copies via slices.Clone/maps.Clone",
+    "prompt": "In package `user`, write a struct `UserProfile` with fields `Name string`, `Email string`, `Permissions []string`, and `Metadata map[string]string`. Add getter methods `GetPermissions() []string` and `GetMetadata() map[string]string`. Keep it simple.",
+    "trap": "Model returns direct references to internal slice and map fields, letting callers mutate the struct's internal state without going through any setter",
+    "assertions": [
+      {
+        "id": "3.1",
+        "text": "Collection fields (Permissions/Metadata) are unexported — exported slice/map fields let any caller mutate struct internals directly, bypassing any getters"
+      },
+      {
+        "id": "3.2",
+        "text": "GetPermissions returns a defensive copy (slices.Clone, make+copy, or append to nil) — not the internal slice reference"
+      },
+      {
+        "id": "3.3",
+        "text": "GetMetadata returns a defensive copy (maps.Clone or manual loop copy) — not the internal map reference"
+      },
+      {
+        "id": "3.4",
+        "text": "Scalar fields (Name, Email) can remain exported since strings are immutable in Go"
+      },
+      {
+        "id": "3.5",
+        "text": "Handles nil internal fields gracefully — GetPermissions on a zero-value UserProfile should not panic"
+      }
+    ]
+  },
+  {
+    "id": 4,
+    "name": "defer-in-loop-helper-function",
+    "description": "Loop body extracted to helper so defer closes each connection per iteration",
+    "prompt": "In package `db`, write a function `PingAll(hosts []string) (string, error)` that tries to connect to each database host in order. For each host, call `sql.Open(\"postgres\", host)` then `db.Ping()`. Return the first host that responds successfully. Use `defer db.Close()` after each Open to clean up. If no host responds, return an error.",
+    "trap": "Model puts `defer db.Close()` inside the for loop — defers accumulate until the outer function returns, keeping all connections open simultaneously instead of closing each one after its Ping",
+    "assertions": [
+      {
+        "id": "4.1",
+        "text": "No bare `defer` in loop body — `defer db.Close()` inside a `for` loop defers ALL closes until function exit, keeping all connections open simultaneously"
+      },
+      {
+        "id": "4.2",
+        "text": "Extracts loop body to a helper function (or uses IIFE) so that defer runs once per iteration, closing each connection before opening the next"
+      },
+      {
+        "id": "4.3",
+        "text": "Checks error from sql.Open before proceeding to Ping"
+      },
+      {
+        "id": "4.4",
+        "text": "Returns meaningful error when no host responds — not just empty string"
+      }
+    ]
+  },
+  {
+    "id": 5,
+    "name": "bounds-check-before-narrowing-int64-to-uint32",
+    "description": "Validates contentLength fits in uint32 before conversion to prevent silent truncation",
+    "prompt": "In package `protocol`, write a function `WriteHeader(w io.Writer, contentLength int64) error` that writes a 4-byte binary header using `binary.BigEndian.PutUint32`. The header contains the content length as a uint32. Write the header bytes to `w`.",
+    "trap": "Model uses `uint32(contentLength)` directly — values above math.MaxUint32 or negative values silently truncate to wrong results without any error",
+    "assertions": [
+      {
+        "id": "5.1",
+        "text": "Bounds-checks before narrowing int64 to uint32 — `uint32(contentLength)` silently truncates values > math.MaxUint32 or < 0"
+      },
+      {
+        "id": "5.2",
+        "text": "Returns error for out-of-range values instead of silently truncating"
+      },
+      {
+        "id": "5.3",
+        "text": "Checks for negative contentLength — negative values wrap to large uint32 values"
+      },
+      {
+        "id": "5.4",
+        "text": "Uses math.MaxUint32 for the upper bound check"
+      }
+    ]
+  },
+  {
+    "id": 6,
+    "name": "copy-subslice-release-backing-array",
+    "description": "Returns copy of token bytes instead of raw subslice retaining large backing array",
+    "prompt": "In package `parser`, write a function `ExtractToken(response []byte) []byte` that returns the first 32 bytes of the response, which contain the authentication token. Keep it simple — one line is enough.",
+    "trap": "Model returns `response[:32]` — this subslice shares the backing array with the full response, preventing GC of potentially megabytes of data for the lifetime of the 32-byte token",
+    "assertions": [
+      {
+        "id": "6.1",
+        "text": "Does not return raw subslice of input — `response[:32]` retains the entire backing array in memory, preventing GC of potentially megabytes of data"
+      },
+      {
+        "id": "6.2",
+        "text": "Uses slices.Clone, make+copy, or append([]byte(nil), ...) to release the backing array"
+      },
+      {
+        "id": "6.3",
+        "text": "Handles the case where response might be shorter than 32 bytes — should check len(response) >= 32 or document the precondition"
+      },
+      {
+        "id": "6.4",
+        "text": "Result is independent of input — modifying the returned token should not affect the original response"
+      }
+    ]
+  },
+  {
+    "id": 7,
+    "name": "comma-ok-type-assertion-not-bare",
+    "description": "Uses comma-ok type assertions or type switch, not bare panicking assertions",
+    "prompt": "In package `dispatch`, write a function `ProcessMessage(msg any) string` that handles messages. If msg is a string, return it uppercased. If msg is an int, return its string representation. If msg is []byte, return it as a string. Be concise — use direct type assertions, not a switch.",
+    "trap": "Model follows the prompt's 'direct type assertions' instruction and uses bare `v := msg.(string)`, which panics at runtime when msg is not the expected type",
+    "assertions": [
+      {
+        "id": "7.1",
+        "text": "Uses comma-ok form `v, ok := msg.(T)` or type switch — not bare assertion `v := msg.(T)` which panics on type mismatch"
+      },
+      {
+        "id": "7.2",
+        "text": "Handles unknown types without panic (returns empty string or error for unrecognized types)"
+      },
+      {
+        "id": "7.3",
+        "text": "Uses strings.ToUpper for string uppercasing, not manual byte manipulation"
+      },
+      {
+        "id": "7.4",
+        "text": "Uses strconv.Itoa or fmt.Sprintf for int-to-string conversion"
+      }
+    ]
+  },
+  {
+    "id": 8,
+    "name": "nil-func-check-before-call",
+    "description": "Checks callback for nil before calling to prevent runtime panic",
+    "prompt": "In package `worker`, write a struct `Task` with fields `Name string` and `OnComplete func(result string)`. Add a `Run()` method that simulates work by setting `result := \"done: \" + t.Name`, then calls `t.OnComplete(result)` to notify completion.",
+    "trap": "Model calls `t.OnComplete(result)` without nil check — calling a nil func panics at runtime when OnComplete was never set",
+    "assertions": [
+      {
+        "id": "8.1",
+        "text": "Checks OnComplete for nil before calling — `t.OnComplete(result)` panics at runtime if OnComplete was never set"
+      },
+      {
+        "id": "8.2",
+        "text": "Task is usable without setting OnComplete — `Task{Name: \"foo\"}.Run()` should not panic"
+      },
+      {
+        "id": "8.3",
+        "text": "Result string is computed before the nil check — work simulation completes regardless of callback presence"
+      },
+      {
+        "id": "8.4",
+        "text": "Method uses pointer receiver `(t *Task)` for consistency with mutable struct patterns"
+      }
+    ]
+  },
+  {
+    "id": 9,
+    "name": "initialize-map-before-write",
+    "description": "Constructor or Handle method initializes routes map before writing to prevent panic",
+    "prompt": "In package `router`, write a struct `Router` with fields `prefix string` and `routes map[string]http.HandlerFunc`. Add a constructor `NewRouter(prefix string) *Router` and a method `Handle(path string, handler http.HandlerFunc)` that stores the handler. Keep the constructor minimal — just set the prefix.",
+    "trap": "Model follows the prompt's 'keep the constructor minimal' instruction, creating Router with a nil map, and Handle() panics on first call when writing to a nil map",
+    "assertions": [
+      {
+        "id": "9.1",
+        "text": "Map initialized before write — either in the constructor or via lazy-init in Handle; writing to a nil map panics"
+      },
+      {
+        "id": "9.2",
+        "text": "Router is usable immediately after NewRouter — Handle() must not panic on first call"
+      },
+      {
+        "id": "9.3",
+        "text": "Handle stores the handler with the correct key (path or prefix+path)"
+      },
+      {
+        "id": "9.4",
+        "text": "Constructor returns a pointer to Router, not a value copy"
+      }
+    ]
+  },
+  {
+    "id": 10,
+    "name": "epsilon-comparison-not-float-equality",
+    "description": "Uses epsilon comparison instead of == for floating-point values",
+    "prompt": "In package `pricing`, write a function `IsDiscountApplied(originalPrice, finalPrice, discountPercent float64) bool` that returns true if the final price equals the original price with the discount applied. The expected final price is `originalPrice * (1 - discountPercent/100)`. Just compare and return the result.",
+    "trap": "Model uses == to compare computed float64 values — IEEE 754 arithmetic is not exact, so computed results that should be equal often differ by small fractions",
+    "assertions": [
+      {
+        "id": "10.1",
+        "text": "Uses epsilon comparison (math.Abs(a-b) < epsilon), not == — IEEE 754 arithmetic is not exact for runtime float64 values"
+      },
+      {
+        "id": "10.2",
+        "text": "Epsilon value is reasonable (1e-9 for general precision, or 0.01 for cent-level financial precision)"
+      },
+      {
+        "id": "10.3",
+        "text": "Formula correctly computes expected as `originalPrice * (1 - discountPercent/100)`"
+      },
+      {
+        "id": "10.4",
+        "text": "Handles edge cases: zero discount, 100% discount, zero original price"
+      }
+    ]
+  },
+  {
+    "id": 11,
+    "name": "defensive-map-copy-not-reference",
+    "description": "All() returns defensive copy of internal map, not a direct reference",
+    "prompt": "In package `cache`, write a struct `Cache` with an internal `data map[string]string`. Add methods: `Set(key, value string)`, `Get(key string) (string, bool)`, and `All() map[string]string` that returns all cache entries. Include a constructor `New() *Cache`.",
+    "trap": "Model returns c.data directly from All() — callers receive a reference to the internal map and can write to it, bypassing Set() and corrupting cache invariants",
+    "assertions": [
+      {
+        "id": "11.1",
+        "text": "All() returns defensive copy of internal map — using maps.Clone or manual loop copy, not the internal map reference"
+      },
+      {
+        "id": "11.2",
+        "text": "Constructor initializes the data map with make()"
+      },
+      {
+        "id": "11.3",
+        "text": "Get uses comma-ok idiom `v, ok := c.data[key]`"
+      },
+      {
+        "id": "11.4",
+        "text": "Callers cannot modify cache contents through the map returned by All()"
+      }
+    ]
+  },
+  {
+    "id": 12,
+    "name": "closed-channel-handling-fan-in",
+    "description": "Correctly handles closed input channels without blocking forever on receive",
+    "prompt": "In package `pipeline`, write a function `FanIn(channels ...<-chan int) <-chan int` that merges all input channels into a single output channel using a select statement inside a loop. When a channel is closed, stop reading from it. Close the output channel when all inputs are done.",
+    "trap": "Model reads from closed channels without ok-check — a closed channel always succeeds immediately with the zero value, causing the loop to spin infinitely",
+    "assertions": [
+      {
+        "id": "12.1",
+        "text": "Handles closed channels without blocking — uses ok check on receive, nil-channel technique in select, or per-channel goroutines with WaitGroup"
+      },
+      {
+        "id": "12.2",
+        "text": "Output channel is closed exactly once when all inputs are exhausted"
+      },
+      {
+        "id": "12.3",
+        "text": "Does not leak goroutines — every launched goroutine terminates when inputs close"
+      },
+      {
+        "id": "12.4",
+        "text": "Handles nil input channels gracefully — a nil channel in the variadic args should not cause a deadlock"
+      }
+    ]
+  },
+  {
+    "id": 13,
+    "name": "named-return-typed-nil-trap",
+    "description": "Named error return not unconditionally assigned *ParseError to avoid nil interface trap",
+    "prompt": "In package `parser`, write a struct `ParseError` with `Line int` and `Msg string` fields, and an `Error() string` method. Write a `Parser` struct with a `Parse(input string) (*Result, *ParseError)` method that returns a ParseError if input is empty. Then write a standalone function `TryParse(p *Parser, input string) (*Result, error)` that wraps Parse and returns the result. Result is a struct with `Value string`. Use named returns `(result *Result, err error)` and a single return at the end.",
+    "trap": "Model unconditionally assigns `err = parseErr` in TryParse — when Parse returns nil *ParseError, this wraps a typed nil pointer in the error interface, making the returned error non-nil",
+    "assertions": [
+      {
+        "id": "13.1",
+        "text": "No typed nil leaked through named error return — must use conditional assignment (`if parseErr != nil { err = parseErr }`) rather than unconditional `err = parseErr` which wraps nil *ParseError into a non-nil error interface"
+      },
+      {
+        "id": "13.2",
+        "text": "Named return `err` starts as untyped nil and is only set when parseErr is actually non-nil"
+      },
+      {
+        "id": "13.3",
+        "text": "ParseError.Error() includes the Line number in the message for debugging"
+      },
+      {
+        "id": "13.4",
+        "text": "Parser.Parse returns nil *ParseError on success, not an empty ParseError{}"
+      }
+    ]
+  },
+  {
+    "id": 14,
+    "name": "nil-pointer-receiver-guard",
+    "description": "Guards against nil *Notifier before calling methods that dereference the receiver",
+    "prompt": "In package `notify`, write a struct `Notifier` with a `webhook string` field. Add a `Send(msg string) error` method that formats and would send the message (just return nil for now). Then write a function `NotifyAll(n *Notifier, messages []string) error` that sends each message using n.Send. Return the first error.",
+    "trap": "Model calls n.Send without checking n == nil — calling a method on a nil pointer panics when the method accesses n.webhook",
+    "assertions": [
+      {
+        "id": "14.1",
+        "text": "Handles nil *Notifier without panic — either NotifyAll checks `n == nil` before calling, or Send guards `if n == nil` before accessing n.webhook"
+      },
+      {
+        "id": "14.2",
+        "text": "Returns a meaningful error when Notifier is nil, not just silently succeeds"
+      },
+      {
+        "id": "14.3",
+        "text": "NotifyAll iterates all messages and returns on first error"
+      },
+      {
+        "id": "14.4",
+        "text": "Send method uses the webhook field in a way that would dereference the receiver (accessing n.webhook)"
+      }
+    ]
+  },
+  {
+    "id": 15,
+    "name": "defensive-slice-copy-getter",
+    "description": "Items() returns defensive copy of internal slice, not a shared reference",
+    "prompt": "In package `inventory`, write a struct `Inventory` with a `items []string` field. Add methods `Add(item string)` and `Items() []string` that returns the items. Keep it simple.",
+    "trap": "Model returns `inv.items` directly from Items() — callers can append to the returned slice and corrupt the Inventory's internal state through shared backing array",
+    "assertions": [
+      {
+        "id": "15.1",
+        "text": "Items() returns defensive copy — `return inv.items` lets callers mutate the internal slice; must use slices.Clone, make+copy, or append to nil"
+      },
+      {
+        "id": "15.2",
+        "text": "Add method uses append correctly to grow the internal slice"
+      },
+      {
+        "id": "15.3",
+        "text": "Modifying the returned slice from Items() does not affect the Inventory's internal state"
+      },
+      {
+        "id": "15.4",
+        "text": "Field is unexported (`items` not `Items`) — exported field would bypass the getter entirely"
+      }
+    ]
+  },
+  {
+    "id": 16,
+    "name": "sorted-map-keys-deterministic-output",
+    "description": "Sorts map keys before iterating for deterministic output",
+    "prompt": "In package `httputil`, write a function `HeaderString(headers map[string]string) string` that formats HTTP headers as \"Key: Value\\r\\n\" lines concatenated together. Keep it simple — just range over the map.",
+    "trap": "Model follows the prompt's 'just range over the map' instruction — Go map iteration is intentionally randomized, producing different header ordering on each run",
+    "assertions": [
+      {
+        "id": "16.1",
+        "text": "Sorts keys before iteration for deterministic output — map iteration order is randomized by the Go runtime; output changes between runs"
+      },
+      {
+        "id": "16.2",
+        "text": "Uses slices.Sorted(maps.Keys(headers)) or sort.Strings for key sorting"
+      },
+      {
+        "id": "16.3",
+        "text": "Uses strings.Builder for efficient concatenation instead of += in a loop"
+      },
+      {
+        "id": "16.4",
+        "text": "Each header line ends with \\r\\n as specified"
+      }
+    ]
+  },
+  {
+    "id": 17,
+    "name": "nan-propagation-float-division",
+    "description": "NaN from float division propagates silently through computations — not a panic, a silent bug",
+    "prompt": "In package `monitor`, write a function `Threshold(baseRate, currentRate float64) bool` that returns true if `currentRate` is at least 90% of `baseRate`. Formula: `currentRate / baseRate >= 0.9`. This is called to decide whether to trigger an alert — if it returns false, we page the on-call team.",
+    "trap": "Model guards against integer division panic but ignores the float case. When baseRate is 0.0, `currentRate / 0.0` can produce +Inf, -Inf, or NaN depending on currentRate; NaN comparisons always return false. The model may not check for zero because float division doesn't panic.",
+    "assertions": [
+      {
+        "id": "17.1",
+        "text": "Guards against zero baseRate — float division by zero produces +Inf, -Inf, or NaN, not a panic. In particular, 0.0/0.0 is NaN and comparisons with NaN are always false"
+      },
+      {
+        "id": "17.2",
+        "text": "Returns a defined value (true or false with documented semantics) when baseRate is 0, not NaN or +Inf silently propagating"
+      },
+      {
+        "id": "17.3",
+        "text": "Does not rely on the caller to ensure baseRate is non-zero — the function itself is defensive"
+      },
+      {
+        "id": "17.4",
+        "text": "Comparison uses the correct threshold (>= 0.9) for the 90% check"
+      }
+    ]
+  },
+  {
+    "id": 18,
+    "name": "defer-body-close-in-loop",
+    "description": "HTTP response bodies closed per-iteration via helper, not deferred to function exit",
+    "prompt": "In package `fetcher`, write a function `FetchAll(urls []string) ([][]byte, error)` that fetches each URL with http.Get, reads the response body with io.ReadAll, and collects results. Use `defer resp.Body.Close()` after each Get. Return the first error encountered, or all results on success.",
+    "trap": "Model puts `defer resp.Body.Close()` inside the for loop — all response bodies accumulate and are only closed when FetchAll returns, exhausting connections and memory for long URL lists",
+    "assertions": [
+      {
+        "id": "18.1",
+        "text": "No bare defer in loop body — `defer resp.Body.Close()` inside a for loop keeps all response bodies open until the function returns"
+      },
+      {
+        "id": "18.2",
+        "text": "Extracts loop body to helper function (or uses IIFE) so defer fires per iteration"
+      },
+      {
+        "id": "18.3",
+        "text": "Checks resp.StatusCode or at least the error from http.Get"
+      },
+      {
+        "id": "18.4",
+        "text": "Preallocates results slice with `make([][]byte, 0, len(urls))`"
+      }
+    ]
+  },
+  {
+    "id": 19,
+    "name": "zero-value-design-usable-without-constructor",
+    "description": "Types should be usable at zero value; map fields that are written to cannot be nil",
+    "prompt": "In package `registry`, write a struct `Registry` with a `handlers map[string]http.HandlerFunc` field and a `Register(name string, h http.HandlerFunc)` method. A teammate says: 'We don't need a constructor — the zero value should just work. Users can do `var r registry.Registry` and call Register immediately.'\n\nImplement Registry following the teammate's suggestion. The zero value must be usable.",
+    "trap": "Model follows the teammate's suggestion literally and writes `type Registry struct { handlers map[string]http.HandlerFunc }` with `func (r *Registry) Register(...)  { r.handlers[name] = h }` — writing to a nil map panics. The teammate is right that zero values should work, but the implementation needs lazy init. The model must recognize that a nil map panics on write and add lazy init inside Register.",
+    "assertions": [
+      {
+        "id": "19.1",
+        "text": "Register does NOT panic when called on a zero-value Registry — `var r Registry; r.Register(\"x\", h)` must work without calling a constructor first"
+      },
+      {
+        "id": "19.2",
+        "text": "Uses lazy initialization inside Register: `if r.handlers == nil { r.handlers = make(map[string]http.HandlerFunc) }` — writing to nil map panics; lazy init is the idiomatic pattern for zero-value-safe types"
+      },
+      {
+        "id": "19.3",
+        "text": "Does NOT require users to call a constructor — the design follows the teammate's suggestion that the zero value is usable"
+      },
+      {
+        "id": "19.4",
+        "text": "Confirms the teammate's goal is valid: sync.Mutex and bytes.Buffer are examples of zero-value-usable types in the stdlib"
+      }
+    ]
+  },
+  {
+    "id": 20,
+    "name": "bounds-check-before-narrowing-int-to-byte",
+    "description": "Validates age fits in byte range (0-255) before converting to prevent silent truncation",
+    "prompt": "In package `protocol`, write a function `PackAge(age int) byte` that converts a user's age to a single byte for a compact binary protocol. Keep it simple.",
+    "trap": "Model uses `byte(age)` directly — age 256 silently becomes 0, age -1 becomes 255, making the binary protocol produce subtly wrong data without any indication",
+    "assertions": [
+      {
+        "id": "20.1",
+        "text": "Validates age fits in byte range (0-255) — `byte(age)` silently truncates values outside 0-255 (e.g., age 256 becomes 0, age -1 becomes 255)"
+      },
+      {
+        "id": "20.2",
+        "text": "Returns error or panics for out-of-range values instead of silently truncating"
+      },
+      {
+        "id": "20.3",
+        "text": "May change signature to `(byte, error)` to signal validation failure"
+      },
+      {
+        "id": "20.4",
+        "text": "Handles negative ages explicitly — negative values wrap to high byte values"
+      }
+    ]
+  },
+  {
+    "id": 21,
+    "name": "copy-both-subslice-branches",
+    "description": "Both found and not-found paths return independent copies of the subslice",
+    "prompt": "In package `search`, write a function `ExtractBefore(buf []byte, marker byte) []byte` that returns everything in buf before the first occurrence of marker. Use bytes.IndexByte. If marker not found, return the full buf.",
+    "trap": "Model copies the found-marker case but returns the full buf directly for not-found, retaining the full backing array for either return value",
+    "assertions": [
+      {
+        "id": "21.1",
+        "text": "Returns copy, not subslice retaining backing array — `buf[:i]` keeps the entire potentially-large backing array alive in memory"
+      },
+      {
+        "id": "21.2",
+        "text": "Uses slices.Clone, make+copy, or append([]byte(nil), ...) to create independent copy"
+      },
+      {
+        "id": "21.3",
+        "text": "Both the found-marker path and the not-found fallback path return copies"
+      },
+      {
+        "id": "21.4",
+        "text": "Uses bytes.IndexByte as specified"
+      }
+    ]
+  },
+  {
+    "id": 22,
+    "name": "nil-check-all-func-fields",
+    "description": "Both OnRequest and OnResponse checked for nil before calling",
+    "prompt": "In package `http`, write a struct `Client` with fields `OnRequest func(url string)` and `OnResponse func(status int)`. Add a `Fetch(url string) (int, error)` method that calls OnRequest before fetching, does the fetch (simulate with status 200), and calls OnResponse after. Keep it simple.",
+    "trap": "Model guards OnRequest but forgets OnResponse, or neither — calling a nil func panics at runtime for any callback that was never set",
+    "assertions": [
+      {
+        "id": "22.1",
+        "text": "Checks OnRequest for nil before calling — calling a nil func panics at runtime"
+      },
+      {
+        "id": "22.2",
+        "text": "Checks OnResponse for nil before calling — same nil func panic risk"
+      },
+      {
+        "id": "22.3",
+        "text": "Client is usable with zero-value callbacks — `Client{}.Fetch(url)` should not panic"
+      },
+      {
+        "id": "22.4",
+        "text": "Both hooks are optional — fetch completes successfully even when neither is set"
+      }
+    ]
+  },
+  {
+    "id": 23,
+    "name": "epsilon-comparison-financial",
+    "description": "Uses epsilon comparison for float equality in billing reconciliation",
+    "prompt": "In package `billing`, write a function `ChargesMatch(computed, invoiced float64) bool` that returns true if the computed charges match the invoiced amount. This is used to reconcile billing — the amounts should be equal.",
+    "trap": "Model uses `computed == invoiced` for float comparison — floating-point arithmetic accumulates tiny errors, making amounts computed via different paths fail equality even when they represent the same value",
+    "assertions": [
+      {
+        "id": "23.1",
+        "text": "Uses epsilon comparison (math.Abs(a-b) < epsilon), not == — floating-point arithmetic can produce values that differ by tiny fractions"
+      },
+      {
+        "id": "23.2",
+        "text": "Epsilon is reasonable for financial contexts (1e-2 for cent precision or 1e-9 for general precision)"
+      },
+      {
+        "id": "23.3",
+        "text": "Handles edge cases: both zero, one zero, negative values"
+      },
+      {
+        "id": "23.4",
+        "text": "Does not use reflect.DeepEqual — it uses == internally for floats"
+      }
+    ]
+  },
+  {
+    "id": 24,
+    "name": "append-aliasing-caller-slice-corruption",
+    "description": "Appending to a caller-supplied slice with spare capacity silently mutates the caller's backing array",
+    "prompt": "In package `pipeline`, write a function `AppendDefaults(tags []string) []string` that ensures the tags slice contains `\"env:prod\"`, `\"region:us-east\"`, and `\"service:api\"`. If a tag is already present, don't add a duplicate. Return the resulting slice.\n\nHere is a caller that will use this function:\n\n```go\ntags := make([]string, 2, 10)  // len=2, cap=10\ntags[0] = \"team:backend\"\ntags[1] = \"version:1.2\"\n\nresult := pipeline.AppendDefaults(tags)\nfmt.Println(tags[2])  // what does this print?\n```\n\nWrite the AppendDefaults function. Is there a safety concern the caller should know about?",
+    "trap": "Model writes `tags = append(tags, missing...)` and returns the modified slice without copying first. Since make([]string, 2, 10) has capacity 10, append reuses the backing array — `tags[2]` in the caller now reads 'env:prod' even though the caller never wrote to it. The model likely misses this shared-memory aliasing.",
+    "assertions": [
+      {
+        "id": "24.1",
+        "text": "Identifies the aliasing hazard: the caller's make([]string, 2, 10) has spare capacity, so appending into the parameter slice writes into memory the caller still owns"
+      },
+      {
+        "id": "24.2",
+        "text": "Uses full-slice expression `tags[:len(tags):len(tags)]`, `slices.Clone(tags)`, or equivalent before appending — this forces a new allocation and prevents writing into the caller's backing array"
+      },
+      {
+        "id": "24.3",
+        "text": "Does not add duplicate tags — checks for presence before appending each default"
+      },
+      {
+        "id": "24.4",
+        "text": "Explains or demonstrates that `tags[2]` in the caller would be silently overwritten without the fix"
+      }
+    ]
+  },
+  {
+    "id": 25,
+    "name": "handler-typed-nil-interface-return",
+    "description": "Returns untyped nil on success; does not leak *AppError(nil) through error interface",
+    "prompt": "In package `middleware`, define `AppError` struct with `Code int` and `Msg string` (with `Error() string` method). Write a function `Handle(handler func() *AppError) error` that calls the handler and returns its result as an `error`. Keep it to one line in the body — just `return handler()`.",
+    "trap": "Model follows the prompt's 'one line' instruction and writes `return handler()` — this implicitly converts nil *AppError to a non-nil error interface when handler returns nil",
+    "assertions": [
+      {
+        "id": "25.1",
+        "text": "Avoids typed nil leak from handler() return — `return handler()` implicitly converts *AppError(nil) to a non-nil error interface when handler returns nil *AppError"
+      },
+      {
+        "id": "25.2",
+        "text": "Uses conditional check like `if err := handler(); err != nil { return err }; return nil` to ensure untyped nil is returned on success"
+      },
+      {
+        "id": "25.3",
+        "text": "Does not assign handler() result directly to an `error` variable — `var err error = handler()` has the same typed-nil trap"
+      },
+      {
+        "id": "25.4",
+        "text": "AppError.Error() returns a meaningful message combining Code and Msg, not just Msg alone"
+      }
+    ]
+  },
+  {
+    "id": 26,
+    "name": "defensive-ingress-and-egress-slice",
+    "description": "Constructor copies input slice (ingress) and getter returns defensive copy (egress)",
+    "prompt": "In package `team`, write a struct `Team` with fields `name string` and `members []string`. Write a constructor `NewTeam(name string, members []string) *Team` and a getter `Members() []string`. Keep the constructor simple — just assign the fields.",
+    "trap": "Model follows 'just assign the fields' instruction — `members: members` shares backing array with caller; caller mutating their original slice after construction corrupts Team internals",
+    "assertions": [
+      {
+        "id": "26.1",
+        "text": "Constructor copies input slice (defensive ingress) — `members: members` shares the backing array; caller can mutate Team internals by modifying the original slice after construction"
+      },
+      {
+        "id": "26.2",
+        "text": "Members() returns defensive copy (egress) — `return t.members` lets callers append/modify the internal slice through the shared backing array"
+      },
+      {
+        "id": "26.3",
+        "text": "Uses slices.Clone, make+copy, or append([]string(nil), ...) for both ingress and egress copies"
+      },
+      {
+        "id": "26.4",
+        "text": "Fields are unexported (lowercase) — exported fields bypass getters entirely, defeating defensive copies"
+      },
+      {
+        "id": "26.5",
+        "text": "Handles nil input gracefully — constructor should not panic if members is nil"
+      }
+    ]
+  },
+  {
+    "id": 27,
+    "name": "defer-file-close-in-loop",
+    "description": "File handles closed per-iteration via helper, not deferred to function exit",
+    "prompt": "In package `fileutil`, write a function `WriteAll(paths []string, data []byte) error` that creates each file path with os.Create, writes `data` to it, and closes it. Use defer for closing. Return the first error encountered.",
+    "trap": "Model puts `defer f.Close()` inside the for loop — all file descriptors accumulate until WriteAll returns, risking fd exhaustion when paths is a long list",
+    "assertions": [
+      {
+        "id": "27.1",
+        "text": "No bare defer in loop body — `defer f.Close()` inside a for loop keeps all file handles open until the function returns, risking file descriptor exhaustion on large path lists"
+      },
+      {
+        "id": "27.2",
+        "text": "Extracts loop body to a helper function or uses IIFE so defer runs once per iteration"
+      },
+      {
+        "id": "27.3",
+        "text": "Helper function handles os.Create, defer f.Close(), and f.Write in a single scope"
+      },
+      {
+        "id": "27.4",
+        "text": "Errors from os.Create and f.Write are both checked and returned"
+      },
+      {
+        "id": "27.5",
+        "text": "Does not ignore the error from f.Close() — write errors can be reported via Close on buffered/sync writers"
+      }
+    ]
+  },
+  {
+    "id": 28,
+    "name": "initialize-result-map-before-merge",
+    "description": "Result's Labels map initialized before writing merged entries",
+    "prompt": "In package `config`, write a struct `Endpoint` with fields `Host string`, `Port int`, and `Labels map[string]string`. Write a function `Merge(a, b Endpoint) Endpoint` that returns a new Endpoint preferring b's non-zero values over a's. For Labels, merge both maps with b taking precedence.",
+    "trap": "Model creates `result := Endpoint{}` or `result := a` without initializing Labels, then writes to result.Labels — writing to a nil map panics at runtime",
+    "assertions": [
+      {
+        "id": "28.1",
+        "text": "Result Labels map initialized before write — creating an Endpoint{} with uninitialized Labels and then writing to it panics at runtime"
+      },
+      {
+        "id": "28.2",
+        "text": "Labels from both inputs are merged correctly with b taking precedence on key conflicts"
+      },
+      {
+        "id": "28.3",
+        "text": "Does not modify input a or b's Labels maps — creates a fresh map for the result (defensive copy)"
+      },
+      {
+        "id": "28.4",
+        "text": "Handles nil Labels in a or b gracefully — ranging over a nil map is safe (0 iterations) but the result map must still be initialized"
+      },
+      {
+        "id": "28.5",
+        "text": "Uses correct zero-value checks — empty string for Host, 0 for Port"
+      }
+    ]
+  },
+  {
+    "id": 29,
+    "name": "copy-byte-subslice-both-branches",
+    "description": "Both found-word and full-line fallback paths return independent copies",
+    "prompt": "In package `text`, write a function `FirstWord(line []byte) []byte` that returns the first whitespace-delimited word from the line. Use `bytes.IndexByte(line, ' ')`. If no space found, return the whole line.",
+    "trap": "Model copies the found-word branch but returns `line` directly for the no-space case — both branches retain the full input buffer in memory",
+    "assertions": [
+      {
+        "id": "29.1",
+        "text": "Returns copy, not subslice retaining backing array — `line[:i]` keeps the entire input buffer alive in memory even if only a few bytes are needed"
+      },
+      {
+        "id": "29.2",
+        "text": "Uses slices.Clone, make+copy, or append([]byte(nil), ...) to create an independent copy"
+      },
+      {
+        "id": "29.3",
+        "text": "Both the found-word path and the full-line fallback path return copies (not just one branch)"
+      },
+      {
+        "id": "29.4",
+        "text": "Handles edge cases: empty input, input starting with space, single-character input"
+      }
+    ]
+  },
+  {
+    "id": 30,
+    "name": "bounds-check-before-narrowing-int-to-uint16",
+    "description": "Validates port fits in uint16 range before conversion to prevent silent truncation",
+    "prompt": "In package `net`, write a function `EncodeAddr(host string, port int) ([]byte, error)` that creates a binary-encoded address. Write the port as a big-endian uint16 followed by the host bytes. Use `binary.BigEndian.PutUint16`.",
+    "trap": "Model uses `uint16(port)` directly — port 65536 silently becomes 0, port -1 becomes 65535, creating malformed binary addresses without any error",
+    "assertions": [
+      {
+        "id": "30.1",
+        "text": "Validates port fits in uint16 range (0-65535) — `uint16(port)` silently truncates values outside this range (e.g., port 65536 becomes 0, port -1 becomes 65535)"
+      },
+      {
+        "id": "30.2",
+        "text": "Returns error for negative ports or ports > 65535"
+      },
+      {
+        "id": "30.3",
+        "text": "Uses math.MaxUint16 or literal 65535 for the upper bound check"
+      },
+      {
+        "id": "30.4",
+        "text": "Correctly allocates buffer of size 2+len(host) for the binary encoding"
+      },
+      {
+        "id": "30.5",
+        "text": "Uses binary.BigEndian.PutUint16 as specified, not binary.Write or manual byte manipulation"
+      }
+    ]
+  },
+  {
+    "id": 31,
+    "name": "assert-helper-t-helper-epsilon",
+    "description": "Test helper calls t.Helper() and uses epsilon comparison for float values",
+    "prompt": "In package `testing`, write a function `AssertPrice(t *testing.T, got, want float64)` that calls t.Errorf if the prices don't match. Use a clear error message showing both values.",
+    "trap": "Model uses `got != want` for float comparison and omits t.Helper() — failures report the helper's line and pass for prices that differ by tiny fractions",
+    "assertions": [
+      {
+        "id": "31.1",
+        "text": "Uses epsilon comparison (math.Abs) not == or != — float arithmetic is not exact; prices computed via multiplication/division may differ by tiny fractions"
+      },
+      {
+        "id": "31.2",
+        "text": "Epsilon value is reasonable for financial contexts (1e-2 for cents, or 1e-9 for general precision)"
+      },
+      {
+        "id": "31.3",
+        "text": "Calls t.Helper() so test failure points to the caller, not the helper itself"
+      },
+      {
+        "id": "31.4",
+        "text": "Error message includes both got and want values for debugging"
+      },
+      {
+        "id": "31.5",
+        "text": "Does not use reflect.DeepEqual for float comparison — it uses == internally and has the same problem"
+      }
+    ]
+  },
+  {
+    "id": 32,
+    "name": "nil-check-optional-callbacks",
+    "description": "Both OnStart and OnStop checked for nil before calling",
+    "prompt": "In package `server`, write a struct `Server` with fields `Addr string`, `OnStart func()`, and `OnStop func()`. Add a `Start() error` method that calls OnStart, prints \"listening on Addr\", and returns nil. Add a `Stop()` method that calls OnStop and prints \"stopped\".",
+    "trap": "Model calls both callbacks without nil checks — using Server with only Addr set causes a panic when Start or Stop is called",
+    "assertions": [
+      {
+        "id": "32.1",
+        "text": "Checks OnStart for nil before calling in Start() — calling a nil func panics at runtime"
+      },
+      {
+        "id": "32.2",
+        "text": "Checks OnStop for nil before calling in Stop() — same nil func panic risk"
+      },
+      {
+        "id": "32.3",
+        "text": "Both methods complete their remaining work (print, return nil) even when the callback is nil"
+      },
+      {
+        "id": "32.4",
+        "text": "Server is usable with zero-value callbacks — `Server{Addr: \":8080\"}` should work without setting OnStart/OnStop"
+      }
+    ]
+  },
+  {
+    "id": 33,
+    "name": "guard-integer-division-by-zero",
+    "description": "Guards against zero capacity to prevent integer division panic",
+    "prompt": "In package `pool`, write a function `Utilization(active, capacity int) int` that returns the pool utilization as a percentage (0-100). Active is current connections, capacity is max. Return `active * 100 / capacity`.",
+    "trap": "Model computes `active * 100 / capacity` directly without checking capacity == 0 — integer division by zero causes an unrecoverable runtime panic",
+    "assertions": [
+      {
+        "id": "33.1",
+        "text": "Guards against zero capacity — integer division by zero panics at runtime with an unrecoverable crash; must check capacity == 0 first"
+      },
+      {
+        "id": "33.2",
+        "text": "Returns a sensible default (0) or an error when capacity is zero"
+      },
+      {
+        "id": "33.3",
+        "text": "Uses integer arithmetic (not float conversion) since the return type is int"
+      },
+      {
+        "id": "33.4",
+        "text": "Multiplication order `active * 100 / capacity` preserves precision better than `active / capacity * 100`"
+      }
+    ]
+  },
+  {
+    "id": 34,
+    "name": "defensive-copy-slice-from-map",
+    "description": "GetAll returns defensive copy of the internal slice value from map",
+    "prompt": "In package `store`, write a struct `Store` with field `data map[string][]string`. Add a constructor `New() *Store`, a method `Add(key, value string)`, and a method `GetAll(key string) []string` that returns all values for that key.",
+    "trap": "Model returns `s.data[key]` directly — callers receive a reference to the internal slice and can append to it, silently mutating the Store's data through shared backing array",
+    "assertions": [
+      {
+        "id": "34.1",
+        "text": "GetAll returns defensive copy of internal slice — `return s.data[key]` lets callers mutate the Store's internal data via the shared backing array"
+      },
+      {
+        "id": "34.2",
+        "text": "Uses slices.Clone, make+copy, or append([]string(nil), ...) to create an independent copy"
+      },
+      {
+        "id": "34.3",
+        "text": "Constructor initializes the data map with make() — writing to a nil map panics"
+      },
+      {
+        "id": "34.4",
+        "text": "Add method correctly uses append to grow the slice for the given key"
+      },
+      {
+        "id": "34.5",
+        "text": "GetAll returns nil or empty slice (not panics) for keys that don't exist"
+      }
+    ]
+  },
+  {
+    "id": 35,
+    "name": "defer-close-reader-in-loop",
+    "description": "io.Closer readers closed per-iteration via helper, not deferred to function exit",
+    "prompt": "In package `scanner`, write a function `ScanAll(readers []io.Reader) ([][]byte, error)` that reads each reader with io.ReadAll, collecting results. If a reader implements io.Closer, use defer to close it. Return all data or the first error.",
+    "trap": "Model puts `defer r.(io.Closer).Close()` inside the for loop — all readers that implement io.Closer remain open until ScanAll returns, consuming resources for the entire function duration",
+    "assertions": [
+      {
+        "id": "35.1",
+        "text": "No bare defer in loop body — defer close inside a for loop keeps all readers open until function exit, preventing resource cleanup between iterations"
+      },
+      {
+        "id": "35.2",
+        "text": "Extracts loop body to a helper function so defer fires per iteration"
+      },
+      {
+        "id": "35.3",
+        "text": "Uses type assertion `r.(io.Closer)` with comma-ok form to conditionally close only closeable readers"
+      },
+      {
+        "id": "35.4",
+        "text": "Preallocates results slice with `make([][]byte, 0, len(readers))` for known capacity"
+      }
+    ]
+  },
+  {
+    "id": 36,
+    "name": "guard-division-by-zero-float-precision",
+    "description": "Guards against zero before and converts to float64 before division for precision",
+    "prompt": "In package `metric`, write a function `PercentChange(before, after int) float64` that returns the percentage change from before to after. Formula: `(after - before) * 100 / before`. Keep it simple — one-liner.",
+    "trap": "Model computes `(after-before) * 100 / before` with integer arithmetic — result is truncated before float conversion, and division by zero panics when before is 0",
+    "assertions": [
+      {
+        "id": "36.1",
+        "text": "Guards against zero before — integer division by zero panics; float division by zero produces Inf/NaN which is silently wrong"
+      },
+      {
+        "id": "36.2",
+        "text": "Converts to float64 before division to preserve fractional precision — integer `(after-before)*100/before` truncates the result"
+      },
+      {
+        "id": "36.3",
+        "text": "Returns a sensible default (0.0) or changes signature to return error when before is zero"
+      },
+      {
+        "id": "36.4",
+        "text": "Formula is mathematically correct: `float64(after-before) / float64(before) * 100` or equivalent"
+      }
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/references/nil-safety.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/references/nil-safety.md
new file mode 100644
index 00000000..5ff5d4e4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/references/nil-safety.md
@@ -0,0 +1,197 @@
+# Nil Safety Deep Dive
+
+## Nil Pointer Receivers
+
+MUST check for nil before calling methods on pointer receivers from external sources. A method call on a nil pointer does not always panic — it depends on whether the method dereferences the receiver:
+
+```go
+type Logger struct {
+    prefix string
+}
+
+// ✓ Safe on nil but NEVER do that — does not dereference l
+func (l *Logger) IsEnabled() bool {
+    return l != nil
+}
+
+// ✗ Panics on nil — dereferences l to access prefix
+func (l *Logger) Log(msg string) {
+    fmt.Printf("[%s] %s\n", l.prefix, msg)
+}
+
+var l *Logger
+l.IsEnabled() // false — works fine
+l.Log("test") // panic: nil pointer dereference
+```
+
+Anyway, NEVER call a method on a nil pointer.
+
+### Designing nil-safe receivers
+
+When a nil receiver is a valid state (e.g., optional components), guard against it explicitly:
+
+```go
+func (l *Logger) Log(msg string) {
+    if l == nil {
+        return // silently skip if no logger configured
+    }
+    fmt.Printf("[%s] %s\n", l.prefix, msg)
+}
+```
+
+This pattern is useful for optional dependencies, but use it sparingly — a nil receiver usually signals a bug, not an intentional state. Document when nil is an expected value.
+
+## Nil Function Values
+
+NEVER rely on nil function values — always validate before calling. Calling a nil `func` variable panics:
+
+```go
+// ✗ Bad — panics if callback was never set
+type Worker struct {
+    onComplete func(result string)
+}
+
+func (w *Worker) Finish(result string) {
+    w.onComplete(result) // panic if onComplete is nil
+}
+
+// ✓ Good — check before calling
+func (w *Worker) Finish(result string) {
+    if w.onComplete != nil {
+        w.onComplete(result)
+    }
+}
+```
+
+### Default function pattern
+
+Provide a no-op default to avoid nil checks at every call site:
+
+```go
+func NewWorker(opts ...Option) *Worker {
+    w := &Worker{
+        onComplete: func(string) {}, // no-op default
+    }
+    for _, opt := range opts {
+        opt(w)
+    }
+    return w
+}
+```
+
+## Nil and Error Comparisons
+
+### Returning nil error correctly
+
+Interface comparisons with nil MUST account for the nil interface trap. A function returning `error` must return the untyped `nil`, not a typed nil pointer:
+
+```go
+// ✗ Bad — returns non-nil error interface
+func validate(s string) error {
+    var err *ValidationError // typed nil
+    if s == "" {
+        err = &ValidationError{Field: "name"}
+    }
+    return err // even when err is nil, interface is non-nil
+}
+
+// ✓ Good — return nil explicitly
+func validate(s string) error {
+    if s == "" {
+        return &ValidationError{Field: "name"}
+    }
+    return nil
+}
+```
+
+### Checking error chains with nil
+
+`errors.Is(err, nil)` returns `true` only if `err` is truly nil. It does not help with the nil interface trap — the trap occurs before the error reaches `errors.Is`.
+
+## Nil in Generic Code
+
+### The `comparable` constraint and nil
+
+Generic code MUST handle the zero value of type parameters correctly. Type parameters constrained by `comparable` can be compared with `==`, but nil is not always a valid value:
+
+```go
+// ✗ Confusing — T may or may not be nillable
+func IsZero[T comparable](v T) bool {
+    var zero T
+    return v == zero // works, but "zero" for *Foo is nil, for int is 0
+}
+
+// ✓ Better — be explicit about what "empty" means
+func IsNil[T interface{ ~*U }, U any](v T) bool {
+    return v == nil
+}
+```
+
+### Nil checks with unconstrained type parameters
+
+You cannot compare an unconstrained type parameter to nil:
+
+```go
+// ✗ Does not compile
+func Check[T any](v T) bool {
+    return v == nil // compile error: cannot compare T with nil
+}
+
+// ✓ Good — use reflect or constrain to pointer types
+func IsNilPtr[T any](v *T) bool {
+    return v == nil
+}
+```
+
+## Patterns for Nil-Safe APIs
+
+### Constructor with defaults
+
+Require initialization through a constructor, making the zero value impossible for external callers:
+
+```go
+type Client struct {
+    httpClient *http.Client
+    baseURL    string
+}
+
+// Constructor guarantees non-nil fields
+func NewClient(baseURL string) *Client {
+    return &Client{
+        httpClient: http.DefaultClient,
+        baseURL:    baseURL,
+    }
+}
+```
+
+### Lazy initialization for zero-value usability
+
+When you want the zero value to be usable but need internal resources:
+
+```go
+type Cache struct {
+    mu   sync.Mutex
+    data map[string]any
+}
+
+func (c *Cache) Get(key string) (any, bool) {
+    c.mu.Lock()
+    defer c.mu.Unlock()
+    if c.data == nil {
+        return nil, false
+    }
+    v, ok := c.data[key]
+    return v, ok
+}
+
+func (c *Cache) Set(key string, val any) {
+    c.mu.Lock()
+    defer c.mu.Unlock()
+    if c.data == nil {
+        c.data = make(map[string]any)
+    }
+    c.data[key] = val
+}
+```
+
+→ See `samber/cc-skills-golang@golang-error-handling` skill for nil error comparison pitfalls.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/references/slice-map-safety.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/references/slice-map-safety.md
new file mode 100644
index 00000000..3bcefbda
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-safety/references/slice-map-safety.md
@@ -0,0 +1,194 @@
+# Slice and Map Safety Deep Dive
+
+## Range Loop Variable Capture
+
+### Pre-Go 1.22: shared loop variable
+
+NEVER store pointers to loop variables in Go < 1.22 — capture by value. Before Go 1.22, the range loop variable was reused across iterations. Capturing it in a closure or storing its address caused all references to point to the final value:
+
+```go
+// ✗ Bad (pre-1.22) — all goroutines see the last value of v
+var funcs []func()
+for _, v := range []string{"a", "b", "c"} {
+    funcs = append(funcs, func() { fmt.Println(v) })
+}
+for _, f := range funcs {
+    f() // prints "c", "c", "c"
+}
+
+// ✓ Fix (pre-1.22) — shadow the variable
+for _, v := range []string{"a", "b", "c"} {
+    v := v // re-declare v in inner scope
+    funcs = append(funcs, func() { fmt.Println(v) })
+}
+```
+
+### Go 1.22+: per-iteration scoping
+
+Go 1.22 changed loop variable semantics — each iteration creates a new variable. The closure bug no longer occurs. However, if your module targets `go 1.21` or earlier in `go.mod`, the old behavior applies. Check your `go.mod` version.
+
+## Storing Pointer to Loop Variable
+
+The same pre-1.22 issue applies to storing `&v`:
+
+```go
+// ✗ Bad (pre-1.22) — all pointers point to the same address
+type Item struct{ Name string }
+items := []Item{{Name: "a"}, {Name: "b"}}
+var ptrs []*Item
+for _, item := range items {
+    ptrs = append(ptrs, &item) // all point to same loop variable
+}
+// ptrs[0].Name == "b", ptrs[1].Name == "b"
+
+// ✓ Good — take address of the slice element directly
+for i := range items {
+    ptrs = append(ptrs, &items[i])
+}
+```
+
+In Go 1.22+, `&item` is safe because each iteration has its own `item`. But taking `&items[i]` is still clearer and avoids a copy.
+
+## Slice Header vs Backing Array
+
+A slice is a 3-word struct: `{pointer, length, capacity}`. Multiple slices can share the same backing array:
+
+```
+a := make([]int, 3, 5)
+┌─────┬─────┬─────┐
+│ ptr │ len=3│cap=5│  ← slice header for a
+└──┬──┴─────┴─────┘
+   │
+   ▼
+┌───┬───┬───┬───┬───┐
+│ 0 │ 0 │ 0 │   │   │  ← backing array (5 elements)
+└───┴───┴───┴───┴───┘
+
+b := a[1:2]
+┌─────┬─────┬─────┐
+│ ptr │ len=1│cap=4│  ← slice header for b (shares backing array)
+└──┬──┴─────┴─────┘
+   │ (points to a[1])
+```
+
+This is why `append(a, x)` can affect `b` if `a` has spare capacity. Use the full slice expression `a[:len(a):len(a)]` to set cap == len and force a new allocation on append.
+
+## Subslice Retains Full Backing Array
+
+Subslice retention: MUST use `slices.Clone` or `copy` when keeping a small slice from a large backing array. Slicing a large slice for a small piece prevents GC of the entire backing array:
+
+```go
+// ✗ Bad — small keeps the entire 1MB array alive
+func getHeader(data []byte) []byte {
+    return data[:64] // shares backing array with data
+}
+
+// ✓ Good — copy to release the large array
+func getHeader(data []byte) []byte {
+    header := make([]byte, 64)
+    copy(header, data[:64])
+    return header
+}
+
+// ✓ Good (Go 1.21+) — use slices.Clone
+import "slices"
+
+func getHeader(data []byte) []byte {
+    return slices.Clone(data[:64])
+}
+```
+
+## Standard Library Clone Helpers (Go 1.21+)
+
+```go
+import (
+    "maps"
+    "slices"
+)
+
+// Shallow copy a slice
+clone := slices.Clone(original)
+
+// Shallow copy a map
+clone := maps.Clone(original)
+```
+
+These are the preferred way to make defensive copies. They are clearer than manual `make` + `copy` and handle nil inputs correctly (returning nil, not an empty collection).
+
+## Map Iteration Order
+
+Map iteration order MUST NOT be depended upon — it is randomized by the runtime:
+
+```go
+// ✗ Bad — output order changes between runs
+m := map[string]int{"a": 1, "b": 2, "c": 3}
+for k, v := range m {
+    fmt.Printf("%s=%d ", k, v) // could be "b=2 a=1 c=3" or any permutation
+}
+
+// ✓ Good (Go 1.23+) — sort keys when order matters
+keys := slices.Sorted(maps.Keys(m))
+for _, k := range keys {
+    fmt.Printf("%s=%d ", k, m[k])
+}
+```
+
+## Deleting During Iteration
+
+### Maps — safe
+
+Deleting map entries during `range` is explicitly safe in Go:
+
+```go
+// ✓ Safe — defined behavior
+for k, v := range m {
+    if shouldDelete(v) {
+        delete(m, k) // safe during range
+    }
+}
+```
+
+### Slices — needs care
+
+Deleting from a slice during iteration requires index management:
+
+```go
+// ✗ Bad — skips elements after deletion
+for i, v := range items {
+    if shouldDelete(v) {
+        items = append(items[:i], items[i+1:]...) // shifts elements, next iteration skips one
+    }
+}
+
+// ✓ Good — iterate backwards
+for i := len(items) - 1; i >= 0; i-- {
+    if shouldDelete(items[i]) {
+        items = append(items[:i], items[i+1:]...)
+    }
+}
+
+// ✓ Good (Go 1.21+) — use slices.DeleteFunc
+items = slices.DeleteFunc(items, shouldDelete)
+```
+
+## Comparing Slices and Maps
+
+Slice/map comparison MUST use `slices.Equal`/`maps.Equal` (Go 1.21+), NEVER `==` (which doesn't compile for slices). Use standard library helpers:
+
+```go
+import (
+    "maps"
+    "slices"
+)
+
+// ✓ Good (Go 1.21+)
+slices.Equal(a, b)      // element-wise comparison
+maps.Equal(m1, m2)      // key-value comparison
+
+// For custom comparison
+slices.EqualFunc(a, b, func(x, y Item) bool {
+    return x.ID == y.ID
+})
+```
+
+→ See `samber/cc-skills-golang@golang-modernize` skill for Go 1.22+ loop variable semantics.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/SKILL.md
new file mode 100644
index 00000000..24651522
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/SKILL.md
@@ -0,0 +1,222 @@
+---
+name: golang-samber-do
+description: "Dependency injection in Golang using samber/do — service containers, lifecycle management, scopes, health checks, graceful shutdown, and module organization. Apply when using or adopting samber/do, when the codebase imports github.com/samber/do or github.com/samber/do/v2, or when refactoring manual constructor injection into a DI container."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.1"
+  openclaw:
+    emoji: "💉"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "2.0.0"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs
+---
+
+**Persona:** You are a Go architect setting up dependency injection. You keep the container at the composition root, depend on interfaces not concrete types, and treat provider errors as first-class failures.
+
+# Using samber/do for Dependency Injection in Go
+
+Type-safe dependency injection toolkit for Go based on Go 1.18+ generics.
+
+**Official Resources:**
+
+- [pkg.go.dev/github.com/samber/do/v2](https://pkg.go.dev/github.com/samber/do/v2)
+- [do.samber.dev](https://do.samber.dev)
+- [github.com/samber/do/v2](https://github.com/samber/do)
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+DO NOT USE v1 OF THIS LIBRARY. INSTALL v2 INSTEAD:
+
+```bash
+go get -u github.com/samber/do/v2
+```
+
+## Core Concepts
+
+### The Injector (Container)
+
+```go
+import "github.com/samber/do/v2"
+
+injector := do.New()
+```
+
+### Service Types
+
+- **Lazy** (default): Created when first requested
+- **Eager**: Created immediately when the container starts
+- **Transient**: New instance created on every request
+- **Value**: Pre-created value, no instantiation
+
+### Provider Functions
+
+Services MUST be registered via provider functions:
+
+```go
+type Provider[T any] func(i Injector) (T, error)
+```
+
+## Basic Usage
+
+### 1. Define and Register Services
+
+Follow "Accept Interfaces, Return Structs":
+
+```go
+// Register a service (lazy by default)
+do.Provide(injector, func(i do.Injector) (Database, error) {
+    return &PostgreSQLDatabase{connString: "postgres://..."}, nil
+})
+
+// Register a pre-created value
+do.ProvideValue(injector, &Config{Port: 8080})
+
+// Register a transient service (new instance each time)
+do.ProvideTransient(injector, func(i do.Injector) (*Logger, error) {
+    return &Logger{}, nil
+})
+
+// Register an eager service (created immediately at startup)
+do.ProvideValue(injector, &Config{Port: 8080})
+```
+
+### 2. Invoke Services
+
+The container MUST only be accessed at the composition root:
+
+```go
+// Invoke with error handling
+db, err := do.Invoke[Database](injector)
+
+// MustInvoke panics on error (use when confident service exists)
+db := do.MustInvoke[Database](injector)
+```
+
+### 3. Service Dependencies
+
+```go
+func NewUserService(i do.Injector) (UserService, error) {
+    db := do.MustInvoke[Database](i)
+    cache := do.MustInvoke[Cache](i)
+    return &userService{db: db, cache: cache}, nil
+}
+
+do.Provide(injector, NewUserService)
+```
+
+### 4. Implicit Aliasing (Preferred)
+
+Register a concrete type and invoke as an interface without explicit aliasing:
+
+```go
+// Register concrete type
+do.Provide(injector, func(i do.Injector) (*PostgreSQLDatabase, error) {
+    return &PostgreSQLDatabase{}, nil
+})
+
+// Invoke directly as interface (implicit aliasing)
+db := do.MustInvokeAs[Database](injector)
+```
+
+### 5. Named Services
+
+Register multiple services of the same type:
+
+```go
+do.ProvideNamed(injector, "primary-db", func(i do.Injector) (*Database, error) {
+    return &Database{URL: "postgres://primary..."}, nil
+})
+
+mainDB := do.MustInvokeNamed[*Database](injector, "primary-db")
+```
+
+## Package Organization
+
+Use `do.Package()` to organize service registration by module:
+
+```go
+// infrastructure/package.go
+var Package = do.Package(
+    do.Lazy(func(i do.Injector) (*postgres.DB, error) {
+        cfg := do.MustInvoke[*Config](i)
+        return postgres.Connect(cfg.DatabaseURL)
+    }),
+    do.Lazy(func(i do.Injector) (*redis.Client, error) {
+        cfg := do.MustInvoke[*Config](i)
+        return redis.NewClient(cfg.RedisURL), nil
+    }),
+)
+
+// main.go
+injector := do.New(infrastructure.Package, service.Package)
+```
+
+## Full Application Setup
+
+```go
+func main() {
+    injector := do.New(
+        infrastructure.Package,
+        repository.Package,
+        service.Package,
+        transport.Package,
+    )
+
+    server := do.MustInvoke[*http.Server](injector)
+    go server.ListenAndServe()
+
+    _ = injector.ShutdownOnSignalsWithContext(context.Background(), os.Interrupt)
+}
+```
+
+## Best Practices
+
+1. Depend on interfaces, not concrete types — lets you swap implementations in tests without touching production code
+2. Each service should have one job — services with multiple responsibilities are harder to test and harder to replace
+3. Keep dependency trees shallow — chains beyond 3-4 levels make initialization order fragile and errors harder to trace
+4. Handle errors in provider functions — a silently failing provider creates a broken service that crashes later in unexpected places
+5. Use scopes to organize services by lifecycle — request-scoped services prevent leaks, global services prevent redundant initialization
+
+For scopes, lifecycle management, struct injection, and debugging, see [Advanced Usage](./references/advanced.md).
+
+For testing patterns (cloning, overrides, mocks), see [Testing](./references/testing.md).
+
+## Quick Reference
+
+### Registration
+
+| Function                        | Purpose                          |
+| ------------------------------- | -------------------------------- |
+| `do.Provide[T]()`               | Register lazy service (default)  |
+| `do.ProvideNamed[T]()`          | Register named lazy service      |
+| `do.ProvideValue[T]()`          | Register pre-created value       |
+| `do.ProvideNamedValue[T]()`     | Register named value             |
+| `do.ProvideTransient[T]()`      | Register new instance each time  |
+| `do.ProvideNamedTransient[T]()` | Register named transient service |
+| `do.Package()`                  | Group service registrations      |
+
+### Invocation
+
+| Function                   | Purpose                                   |
+| -------------------------- | ----------------------------------------- |
+| `do.Invoke[T]()`           | Get service (with error)                  |
+| `do.InvokeNamed[T]()`      | Get named service                         |
+| `do.InvokeAs[T]()`         | Get first service matching interface      |
+| `do.InvokeStruct[T]()`     | Inject into struct fields using tags      |
+| `do.MustInvoke[T]()`       | Get service (panic on error)              |
+| `do.MustInvokeNamed[T]()`  | Get named service (panic on error)        |
+| `do.MustInvokeAs[T]()`     | Get service by interface (panic on error) |
+| `do.MustInvokeStruct[T]()` | Inject into struct (panic on error)       |
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-dependency-injection` skill for DI concepts, comparison, and when to adopt a DI library
+- → See `samber/cc-skills-golang@golang-structs-interfaces` skill for interface design patterns
+- → See `samber/cc-skills-golang@golang-testing` skill for general testing patterns
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/evals/evals.json
new file mode 100644
index 00000000..f126dd48
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/evals/evals.json
@@ -0,0 +1,154 @@
+[
+  {
+    "id": 1,
+    "name": "v2-import-not-v1",
+    "description": "Tests whether the model uses samber/do/v2, never v1",
+    "prompt": "I want to set up dependency injection in my Go project using samber/do. Show me how to install it and create a basic container.",
+    "trap": "Without the skill, the model might import github.com/samber/do (v1) instead of github.com/samber/do/v2",
+    "assertions": [
+      {"id": "1.1", "text": "Uses go get github.com/samber/do/v2 (not github.com/samber/do without v2)"},
+      {"id": "1.2", "text": "Import path is github.com/samber/do/v2 in the code"},
+      {"id": "1.3", "text": "Uses do.New() to create the container"},
+      {"id": "1.4", "text": "Does NOT reference v1 API or import paths anywhere"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "lazy-vs-eager-vs-transient",
+    "description": "Tests whether the model correctly chooses between lazy, eager, and transient service types",
+    "prompt": "I have three services in my Go app: (1) a database connection that must be ready before serving requests, (2) a user repository that's only needed when user endpoints are called, and (3) a request logger that should be a fresh instance per request. Register them with samber/do.",
+    "trap": "Without the skill, the model registers all three with do.Provide (lazy), missing do.Eager for the database and do.ProvideTransient for the logger",
+    "assertions": [
+      {"id": "2.1", "text": "Uses do.Provide with do.Eager wrapper (or equivalent) for the database connection that must be ready immediately"},
+      {"id": "2.2", "text": "Uses do.Provide (lazy, the default) for the user repository that's only needed on demand"},
+      {"id": "2.3", "text": "Uses do.ProvideTransient for the request logger that needs a fresh instance each time"},
+      {"id": "2.4", "text": "Correctly distinguishes between the three service lifecycle types"},
+      {"id": "2.5", "text": "Does NOT register all three services with the same registration function"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "implicit-aliasing-invokeAs",
+    "description": "Tests whether the model uses InvokeAs for implicit aliasing instead of explicit aliasing",
+    "prompt": "I have a PostgreSQLDatabase struct that implements a Database interface. I want to register the concrete type but invoke it as the interface in my Go service. How do I set this up with samber/do?",
+    "trap": "Without the skill, the model uses do.As or do.MustAs for explicit aliasing, which is only needed for legacy code. Implicit aliasing via InvokeAs is preferred.",
+    "assertions": [
+      {"id": "3.1", "text": "Registers the concrete type *PostgreSQLDatabase with do.Provide"},
+      {"id": "3.2", "text": "Uses do.MustInvokeAs[Database] or do.InvokeAs[Database] to invoke as the interface"},
+      {"id": "3.3", "text": "Prefers implicit aliasing (InvokeAs) over explicit aliasing (As/MustAs)"},
+      {"id": "3.4", "text": "Does NOT require a separate alias registration step for this basic case"},
+      {"id": "3.5", "text": "The provider function returns the concrete type, not the interface"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "package-organization",
+    "description": "Tests whether the model organizes service registrations using do.Package",
+    "prompt": "My Go project has infrastructure services (database, cache), domain services (user service, order service), and transport services (HTTP handlers). How should I organize the DI registrations with samber/do?",
+    "trap": "Without the skill, the model registers everything in main.go in a long list, missing do.Package for modular organization",
+    "assertions": [
+      {"id": "4.1", "text": "Uses do.Package to group related service registrations into separate packages/modules"},
+      {"id": "4.2", "text": "Creates separate package variables (e.g., infrastructure.Package, service.Package, transport.Package)"},
+      {"id": "4.3", "text": "Passes all packages to do.New() in main.go: do.New(infrastructure.Package, service.Package, transport.Package)"},
+      {"id": "4.4", "text": "Each package groups related services (infra, domain, transport) rather than one giant registration list"},
+      {"id": "4.5", "text": "Uses do.Lazy wrapper inside do.Package for lazy service registration"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "scopes-for-lifecycle",
+    "description": "Tests whether the model uses scopes to organize services by lifecycle and visibility",
+    "prompt": "In my Go web app using samber/do, I have global services (config, logger) and per-request services (request context, current user). How do I prevent per-request services from being shared across requests?",
+    "trap": "Without the skill, the model registers everything in the root container, leading to shared per-request state across concurrent requests",
+    "assertions": [
+      {"id": "5.1", "text": "Uses do.Scope to create child scopes for per-request services"},
+      {"id": "5.2", "text": "Registers global/stateless services (config, logger) in the root container"},
+      {"id": "5.3", "text": "Creates a new scope per request for request-scoped services"},
+      {"id": "5.4", "text": "Child scope services can access parent (root) services"},
+      {"id": "5.5", "text": "Does NOT register request-scoped services in the root container"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "testing-clone-override",
+    "description": "Tests whether the model uses container cloning and overrides for testing",
+    "prompt": "I have a Go service registered in samber/do that depends on a Database interface. I want to test the service with a mock database. How do I set up the test?",
+    "trap": "Without the skill, the model creates a brand new container from scratch in tests, missing the Clone+Override pattern that reuses the production container configuration",
+    "assertions": [
+      {"id": "6.1", "text": "Uses injector.Clone() or do.Clone() to clone the production container"},
+      {"id": "6.2", "text": "Uses do.Override or do.OverrideValue to replace the Database with a mock"},
+      {"id": "6.3", "text": "Invokes the service under test from the cloned container"},
+      {"id": "6.4", "text": "Does NOT build a completely new container from scratch for each test (unless justified)"},
+      {"id": "6.5", "text": "The test is isolated — changes to the cloned container don't affect the original"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "health-check-interface",
+    "description": "Tests whether the model implements the Healthchecker interface for service health checks",
+    "prompt": "I have a database service registered in samber/do. I want to add health checking so I can verify the database is reachable. How do I implement this?",
+    "trap": "Without the skill, the model writes a standalone health check function instead of implementing the Healthchecker interface that integrates with do's lifecycle",
+    "assertions": [
+      {"id": "7.1", "text": "Implements a HealthCheck() method on the database service struct"},
+      {"id": "7.2", "text": "The HealthCheck method signature is either HealthCheck() error or HealthCheck(ctx context.Context) error"},
+      {"id": "7.3", "text": "Uses do.HealthCheck[Database](injector) to invoke the health check through the container"},
+      {"id": "7.4", "text": "Does NOT write a standalone function that manually fetches the service and pings it"},
+      {"id": "7.5", "text": "The health check actually tests connectivity (e.g., conn.Ping())"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "graceful-shutdown-interface",
+    "description": "Tests whether the model implements the Shutdowner interface for graceful shutdown",
+    "prompt": "My Go application uses samber/do for DI. I need to gracefully shut down all services (close database connections, flush logs) when the application receives SIGINT. Show me how.",
+    "trap": "Without the skill, the model writes manual shutdown code with signal handling, missing do's ShutdownOnSignals integration and Shutdowner interface",
+    "assertions": [
+      {"id": "8.1", "text": "Implements Shutdown() or Shutdown(ctx context.Context) method on services that need cleanup"},
+      {"id": "8.2", "text": "Uses injector.ShutdownOnSignals or injector.ShutdownOnSignalsWithContext for signal-based shutdown"},
+      {"id": "8.3", "text": "Passes os.Interrupt or syscall.SIGTERM to the shutdown function"},
+      {"id": "8.4", "text": "Does NOT manually implement signal handling and iterate over services to shut them down"},
+      {"id": "8.5", "text": "May use context.WithTimeout for shutdown deadline"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "composition-root-only",
+    "description": "Tests that the container is only accessed at the composition root, not passed around or used as a service locator",
+    "prompt": "I'm using samber/do for DI in my Go project. I have a UserHandler that needs a UserService. Should I pass the do.Injector to UserHandler so it can resolve its own dependencies?",
+    "trap": "Without the skill, the model passes the injector into business logic code, turning it into an anti-pattern service locator",
+    "assertions": [
+      {"id": "9.1", "text": "Advises against passing do.Injector into business logic or handler code"},
+      {"id": "9.2", "text": "States that the container should only be accessed at the composition root (main/startup)"},
+      {"id": "9.3", "text": "Shows resolving dependencies in the provider function using do.MustInvoke from the injector parameter"},
+      {"id": "9.4", "text": "The UserHandler receives its dependencies as constructor parameters, not the container"},
+      {"id": "9.5", "text": "Explains that passing the container creates a service locator anti-pattern that hides dependencies"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "named-services-same-type",
+    "description": "Tests whether the model uses named services when registering multiple instances of the same type",
+    "prompt": "My Go app connects to two PostgreSQL databases — a primary for writes and a replica for reads. Both are *sql.DB instances. How do I register and retrieve them with samber/do?",
+    "trap": "Without the skill, the model tries to register both with do.Provide which overwrites the first registration, or wraps them in different types unnecessarily",
+    "assertions": [
+      {"id": "10.1", "text": "Uses do.ProvideNamed to register each database with a distinct name (e.g., 'primary-db', 'replica-db')"},
+      {"id": "10.2", "text": "Uses do.MustInvokeNamed or do.InvokeNamed to retrieve each database by name"},
+      {"id": "10.3", "text": "Both databases are registered as the same type (*sql.DB or a Database interface)"},
+      {"id": "10.4", "text": "Does NOT create unnecessary wrapper types just to distinguish the two databases"},
+      {"id": "10.5", "text": "Does NOT overwrite the first registration by using do.Provide twice for the same type"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "struct-injection-with-tags",
+    "description": "Tests knowledge of struct injection using do tags",
+    "prompt": "I have a Go struct with multiple service dependencies that I want to inject from my samber/do container. Is there a way to avoid calling MustInvoke for each field manually?",
+    "trap": "Without the skill, the model manually invokes each dependency and assigns to struct fields, missing the do:\"\" tag-based struct injection",
+    "assertions": [
+      {"id": "11.1", "text": "Uses struct field tags with do:\"\" or do:\"service-name\" syntax"},
+      {"id": "11.2", "text": "Uses do.MustInvokeStruct or do.InvokeStruct to populate the struct"},
+      {"id": "11.3", "text": "Shows that do:\"\" uses the type for resolution and do:\"name\" uses a named service"},
+      {"id": "11.4", "text": "Does NOT manually call MustInvoke for each field when struct injection is available"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/references/advanced.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/references/advanced.md
new file mode 100644
index 00000000..f617d79b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/references/advanced.md
@@ -0,0 +1,206 @@
+# Advanced Usage
+
+## Scopes (Module Tree)
+
+Scopes SHOULD be used to organize services by module:
+
+```go
+root := do.New()
+
+// Register shared services in root
+do.Provide(root, func(i do.Injector) (Database, error) {
+    return &Database{}, nil
+})
+
+// Create child scope
+apiScope := root.Scope("api")
+
+// Services in apiScope can access root services
+do.Provide(apiScope, func(i do.Injector) (UserService, error) {
+    db := do.MustInvoke[Database](i) // from root
+    return &userService{db: db}, nil
+})
+
+// Child scopes are isolated from each other
+userScope := root.Scope("user")
+```
+
+Organize services by lifecycle and visibility:
+
+```go
+root := do.New()
+
+// Global/stateless services in root
+do.Provide(root, NewConfig)
+do.Provide(root, NewLogger)
+
+// Request-scoped services
+requestScope := root.Scope("request")
+do.Provide(requestScope, NewRequestContext)
+```
+
+## Explicit Service Aliasing
+
+For rare cases when you need to adapt to legacy code:
+
+```go
+do.Provide(injector, func(i do.Injector) (*PostgreSQLDatabase, error) {
+    return &PostgreSQLDatabase{}, nil
+})
+
+do.MustAs[*PostgreSQLDatabase, Database](injector)
+
+// Now both work:
+db1 := do.MustInvoke[*PostgreSQLDatabase](injector)
+db2 := do.MustInvoke[Database](injector)
+```
+
+Prefer implicit aliasing with `InvokeAs()` in most cases.
+
+## Struct Injection
+
+Inject services directly into struct fields using tags:
+
+```go
+type App struct {
+    Database *Database `do:""`
+    Logger   *Logger   `do:"app-logger"`
+    Config   *Config   `do:""`
+}
+
+app := do.MustInvokeStruct[App](injector)
+```
+
+## Lifecycle Management
+
+### Health Checks
+
+Implement the `Healthchecker` interface:
+
+```go
+func (d *Database) HealthCheck() error {
+    return d.conn.Ping()
+}
+
+// With context support:
+func (d *Database) HealthCheck(ctx context.Context) error {
+    return d.conn.PingContext(ctx)
+}
+
+// Check health
+if err := do.HealthCheck[Database](injector); err != nil {
+    log.Printf("Database unhealthy: %v", err)
+}
+```
+
+### Graceful Shutdown
+
+Implement the `Shutdowner` interface (4 variants):
+
+```go
+// Simple
+func (d *Database) Shutdown() { d.conn.Close() }
+
+// With context
+func (d *Database) Shutdown(ctx context.Context) { d.conn.Close() }
+
+// With error
+func (d *Database) Shutdown() error { return d.conn.Close() }
+
+// With context + error (most flexible)
+func (d *Database) Shutdown(ctx context.Context) error { return d.conn.Close() }
+```
+
+Shutdown with timeout:
+
+```go
+ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
+defer cancel()
+
+report := injector.ShutdownWithContext(ctx)
+```
+
+## Debugging
+
+### List Services
+
+```go
+services := injector.ListProvidedServices()
+for _, svc := range services {
+    fmt.Printf("%s: %s\n", svc.ScopeName, svc.Service)
+}
+```
+
+### Explain Injector
+
+```go
+explanation := do.ExplainInjector(injector)
+fmt.Println(explanation.String())
+```
+
+## Migration from Manual DI
+
+Before (manual):
+
+```go
+func main() {
+    config := &Config{Port: 8080}
+    db := NewDatabase(config)
+    userRepo := NewUserRepository(db)
+    userService := NewUserService(userRepo)
+    api := NewAPI(userService)
+}
+```
+
+After (with do):
+
+```go
+func main() {
+    injector := do.New()
+    do.Provide(injector, func(i do.Injector) (*Config, error) {
+        return &Config{Port: 8080}, nil
+    })
+    do.Provide(injector, NewDatabase)
+    // ... register other services
+    api := do.MustInvoke[*API](injector)
+}
+```
+
+## Quick Reference
+
+### Aliasing
+
+| Function                       | Purpose                 |
+| ------------------------------ | ----------------------- |
+| `do.As[Initial, Alias]()`      | Create type alias       |
+| `do.AsNamed[Initial, Alias]()` | Create named type alias |
+
+### Lifecycle & Health
+
+| Function                         | Purpose                     |
+| -------------------------------- | --------------------------- |
+| `do.HealthCheck[T]()`            | Check service health        |
+| `do.HealthCheckNamed()`          | Check named service health  |
+| `do.HealthCheckWithContext[T]()` | Health check with timeout   |
+| `do.Shutdown[T]()`               | Gracefully shutdown service |
+| `do.ShutdownNamed()`             | Shutdown named service      |
+| `do.ShutdownWithContext[T]()`    | Shutdown with timeout       |
+| `do.MustShutdown[T]()`           | Shutdown (panic on error)   |
+
+### Container Management
+
+| Function           | Purpose                       |
+| ------------------ | ----------------------------- |
+| `do.New()`         | Create new root container     |
+| `do.NewWithOpts()` | Create container with options |
+| `injector.Scope()` | Create child scope            |
+
+### Debugging
+
+| Function                          | Purpose                              |
+| --------------------------------- | ------------------------------------ |
+| `do.ExplainInjector()`            | Visualize scope tree and services    |
+| `do.ExplainService[T]()`          | Get service details and dependencies |
+| `do.NameOf[T]()`                  | Get service name (use sparingly)     |
+| `injector.ListProvidedServices()` | List all available services          |
+| `injector.ListInvokedServices()`  | List invoked services only           |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/references/testing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/references/testing.md
new file mode 100644
index 00000000..0390b299
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-do/references/testing.md
@@ -0,0 +1,49 @@
+# Testing with samber/do
+
+## Container Cloning
+
+Clone containers for isolated tests:
+
+```go
+func TestUserService(t *testing.T) {
+    // Create test container by cloning main container
+    testInjector := mainInjector.Clone()
+
+    // Override with mocks
+    mockDB := &MockDatabase{}
+    do.OverrideValue(testInjector, mockDB)
+
+    // Test with mocked dependencies
+    service := do.MustInvoke[UserService](testInjector)
+    // ... test code
+}
+```
+
+## Reusable Test Helpers
+
+```go
+func SetupTestContainer(t *testing.T) do.Injector {
+    injector := do.New()
+
+    do.Provide(injector, func(i do.Injector) (Database, error) {
+        return &MockDatabase{}, nil
+    })
+
+    return injector
+}
+```
+
+## Quick Reference
+
+### Testing & Overrides
+
+| Function                         | Purpose                         |
+| -------------------------------- | ------------------------------- |
+| `injector.Clone()`               | Clone container for testing     |
+| `injector.CloneWithOpts()`       | Clone with custom options       |
+| `do.Override[T]()`               | Replace service (use in tests)  |
+| `do.OverrideNamed[T]()`          | Replace named service           |
+| `do.OverrideValue[T]()`          | Replace value service           |
+| `do.OverrideNamedValue[T]()`     | Replace named value             |
+| `do.OverrideTransient[T]()`      | Replace transient factory       |
+| `do.OverrideNamedTransient[T]()` | Replace named transient factory |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/SKILL.md
new file mode 100644
index 00000000..fb0fd54f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/SKILL.md
@@ -0,0 +1,135 @@
+---
+name: golang-samber-hot
+description: "In-memory caching in Golang using samber/hot — eviction algorithms (LRU, LFU, TinyLFU, W-TinyLFU, S3FIFO, ARC, TwoQueue, SIEVE, FIFO), TTL, cache loaders, sharding, stale-while-revalidate, missing key caching, and Prometheus metrics. Apply when using or adopting samber/hot, when the codebase imports github.com/samber/hot, or when the project repeatedly loads the same medium-to-low cardinality resources at high frequency and needs to reduce latency or backend pressure."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.0.3"
+  openclaw:
+    emoji: "🔥"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "0.13.0"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs AskUserQuestion
+---
+
+**Persona:** You are a Go engineer who treats caching as a system design decision. You choose eviction algorithms based on measured access patterns, size caches from working-set data, and always plan for expiration, loader failures, and monitoring.
+
+# Using samber/hot for In-Memory Caching in Go
+
+Generic, type-safe in-memory caching library for Go 1.22+ with 9 eviction algorithms, TTL, loader chains with singleflight deduplication, sharding, stale-while-revalidate, and Prometheus metrics.
+
+**Official Resources:**
+
+- [pkg.go.dev/github.com/samber/hot](https://pkg.go.dev/github.com/samber/hot)
+- [github.com/samber/hot](https://github.com/samber/hot)
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+```bash
+go get -u github.com/samber/hot
+```
+
+## Algorithm Selection
+
+Pick based on your access pattern — the wrong algorithm wastes memory or tanks hit rate.
+
+| Algorithm | Constant | Best for | Avoid when |
+| --- | --- | --- | --- |
+| **W-TinyLFU** | `hot.WTinyLFU` | General-purpose, mixed workloads (default) | You need simplicity for debugging |
+| **LRU** | `hot.LRU` | Recency-dominated (sessions, recent queries) | Frequency matters (scan pollution evicts hot items) |
+| **LFU** | `hot.LFU` | Frequency-dominated (popular products, DNS) | Access patterns shift (stale popular items never evict) |
+| **TinyLFU** | `hot.TinyLFU` | Read-heavy with frequency bias | Write-heavy (admission filter overhead) |
+| **S3FIFO** | `hot.S3FIFO` | High throughput, scan-resistant | Small caches (<1000 items) |
+| **ARC** | `hot.ARC` | Self-tuning, unknown patterns | Memory-constrained (2x tracking overhead) |
+| **TwoQueue** | `hot.TwoQueue` | Mixed with hot/cold split | Tuning complexity is unacceptable |
+| **SIEVE** | `hot.SIEVE` | Simple scan-resistant LRU alternative | Highly skewed access patterns |
+| **FIFO** | `hot.FIFO` | Simple, predictable eviction order | Hit rate matters (no frequency/recency awareness) |
+
+**Decision shortcut:** Start with `hot.WTinyLFU`. Switch only when profiling shows the miss rate is too high for your SLO.
+
+For detailed algorithm comparison, benchmarks, and a decision tree, see [Algorithm Guide](./references/algorithm-guide.md).
+
+## Core Usage
+
+### Basic Cache with TTL
+
+```go
+import "github.com/samber/hot"
+
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 10_000).
+    WithTTL(5 * time.Minute).
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()
+
+cache.Set("user:123", user)
+cache.SetWithTTL("session:abc", session, 30*time.Minute)
+
+value, found, err := cache.Get("user:123")
+```
+
+### Loader Pattern (Read-Through)
+
+Loaders fetch missing keys automatically with singleflight deduplication — concurrent `Get()` calls for the same missing key share one loader invocation:
+
+```go
+cache := hot.NewHotCache[int, *User](hot.WTinyLFU, 10_000).
+    WithTTL(5 * time.Minute).
+    WithLoaders(func(ids []int) (map[int]*User, error) {
+        return db.GetUsersByIDs(ctx, ids) // batch query
+    }).
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()
+
+user, found, err := cache.Get(123) // triggers loader on miss
+```
+
+## Capacity Sizing
+
+Before setting the cache capacity, estimate how many items fit in the memory budget:
+
+1. **Estimate single-item size** — estimate size of the struct, add the size of heap-allocated fields (slices, maps, strings). Include the key size. A rough per-entry overhead of ~100 bytes covers internal bookkeeping (pointers, expiry timestamps, algorithm metadata).
+2. **Ask the developer** how much memory is dedicated to this cache in production (e.g., 256 MB, 1 GB). This depends on the service's total memory and what else shares the process.
+3. **Compute capacity** — `capacity = memoryBudget / estimatedItemSize`. Round down to leave headroom.
+
+```
+Example: *User struct ~500 bytes + string key ~50 bytes + overhead ~100 bytes = ~650 bytes/entry
+         256 MB budget → 256_000_000 / 650 ≈ 393,000 items
+```
+
+If the item size is unknown, ask the developer to measure it with a unit test that allocates N items and checks `runtime.ReadMemStats`. Guessing capacity without measuring leads to OOM or wasted memory.
+
+## Common Mistakes
+
+1. **Forgetting `WithJanitor()`** — without it, expired entries stay in memory until the algorithm evicts them. Always chain `.WithJanitor()` in the builder and `defer cache.StopJanitor()`.
+2. **Calling `SetMissing()` without missing cache config** — panics at runtime. Enable `WithMissingCache(algorithm, capacity)` or `WithMissingSharedCache()` in the builder first.
+3. **`WithoutLocking()` + `WithJanitor()`** — mutually exclusive, panics. `WithoutLocking()` is only safe for single-goroutine access without background cleanup.
+4. **Oversized cache** — a cache holding everything is a map with overhead. Size to your working set (typically 10-20% of total data). Monitor hit rate to validate.
+5. **Ignoring loader errors** — `Get()` returns `(zero, false, err)` on loader failure. Always check `err`, not just `found`.
+
+## Best Practices
+
+1. Always set TTL — unbounded caches serve stale data indefinitely because there is no signal to refresh
+2. Use `WithJitter(lambda, upperBound)` to spread expirations — without jitter, items created together expire together, causing thundering herd on the loader
+3. Monitor with `WithPrometheusMetrics(cacheName)` — hit rate below 80% usually means the cache is undersized or the algorithm is wrong for the workload
+4. Use `WithCopyOnRead(fn)` / `WithCopyOnWrite(fn)` for mutable values — without copies, callers mutate cached objects and corrupt shared state
+
+For advanced patterns (revalidation, sharding, missing cache, monitoring setup), see [Production Patterns](./references/production-patterns.md).
+
+For the complete API surface, see [API Reference](./references/api-reference.md).
+
+If you encounter a bug or unexpected behavior in samber/hot, open an issue at <https://github.com/samber/hot/issues>.
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-performance` skill for general caching strategy and when to use in-memory cache vs Redis vs CDN
+- → See `samber/cc-skills-golang@golang-observability` skill for Prometheus metrics integration and monitoring
+- → See `samber/cc-skills-golang@golang-database` skill for database query patterns that pair with cache loaders
+- → See `samber/cc-skills@promql-cli` skill for querying Prometheus cache metrics via CLI
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/evals/evals.json
new file mode 100644
index 00000000..64211f93
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/evals/evals.json
@@ -0,0 +1,202 @@
+[
+  {
+    "id": 1,
+    "name": "algorithm-selection-default",
+    "description": "Tests whether the model recommends W-TinyLFU as default instead of LRU",
+    "prompt": "I need an in-memory cache for my Go web API using samber/hot. It handles user profile lookups with mixed access patterns — some users are accessed frequently, others only occasionally. Set up a cache with 50k entries and 10-minute TTL.",
+    "trap": "Without the skill, the model defaults to hot.LRU (the most well-known algorithm) instead of hot.WTinyLFU which handles mixed workloads better",
+    "assertions": [
+      {"id": "1.1", "text": "Uses hot.WTinyLFU as the eviction algorithm (not hot.LRU)"},
+      {"id": "1.2", "text": "Uses hot.NewHotCache constructor with generic type parameters"},
+      {"id": "1.3", "text": "Chains .WithTTL(10 * time.Minute) or equivalent"},
+      {"id": "1.4", "text": "Chains .WithJanitor() in the builder (not calling cache.Janitor() separately after Build)"},
+      {"id": "1.5", "text": "Calls defer cache.StopJanitor() after Build()"},
+      {"id": "1.6", "text": "Calls .Build() to finalize the cache"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "algorithm-selection-frequency",
+    "description": "For stable frequency-dominated workloads, LFU beats W-TinyLFU despite W-TinyLFU being the general default",
+    "prompt": "I'm building a DNS resolver cache in Go with samber/hot. Lookups follow a heavy power-law distribution — a small set of domains (google.com, cloudflare.com) are looked up millions of times, while most domains are rare. The popularity rankings are very stable over time.\n\nA teammate says: 'The docs say W-TinyLFU is the general-purpose default that handles mixed workloads. We should always start with hot.WTinyLFU to avoid bike-shedding — you can always tune later.' Is this good advice for this specific use case? Which algorithm should I actually use?",
+    "trap": "The teammate's advice sounds pragmatic — 'start with the default, tune later' is usually good. But the skill teaches that for stable frequency-dominated workloads (where popularity rankings don't shift), hot.LFU is superior to W-TinyLFU. LFU's known weakness (stale popular items never evict) is irrelevant when rankings are stable. The model should override the default recommendation.",
+    "assertions": [
+      {"id": "2.1", "text": "Pushes back on the teammate — does NOT blindly apply hot.WTinyLFU when the workload is clearly stable-frequency-dominated"},
+      {"id": "2.2", "text": "Recommends hot.LFU as the correct algorithm: stable power-law distribution maps exactly to LFU's strength (keeping the most frequently accessed items)"},
+      {"id": "2.3", "text": "Explains why LFU's known weakness (stale popular items stuck in cache) does NOT apply here — popularity rankings are stable, so the stale-items problem doesn't manifest"},
+      {"id": "2.4", "text": "Correctly positions W-TinyLFU as 'general-purpose for unknown/shifting patterns' while LFU is 'optimal for known stable frequency patterns'"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "janitor-required",
+    "description": "Tests whether the model correctly includes WithJanitor() — the most common mistake",
+    "prompt": "Write a simple samber/hot cache in Go with a 5-minute TTL for caching API responses. Key is string, value is []byte.",
+    "trap": "Without the skill, the model forgets WithJanitor() — expired entries stay in memory until algorithm eviction, silently serving stale data",
+    "assertions": [
+      {"id": "3.1", "text": "Includes .WithJanitor() in the builder chain"},
+      {"id": "3.2", "text": "Includes defer cache.StopJanitor() for cleanup"},
+      {"id": "3.3", "text": "Uses .WithTTL() for expiration"},
+      {"id": "3.4", "text": "Does NOT call cache.Janitor() as a separate method after Build() — it should be chained in the builder"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "missing-cache-panic-prevention",
+    "description": "Tests whether the model correctly enables missing cache before calling SetMissing",
+    "prompt": "I have a samber/hot cache for user lookups in Go. When the database confirms a user ID doesn't exist, I want to cache that negative result so we don't keep querying the DB. Show me how to implement this.",
+    "trap": "Without the skill, the model calls cache.SetMissing() without configuring WithMissingCache() or WithMissingSharedCache() first, which panics at runtime",
+    "assertions": [
+      {"id": "4.1", "text": "Configures WithMissingCache(algorithm, capacity) or WithMissingSharedCache() in the builder"},
+      {"id": "4.2", "text": "Uses cache.SetMissing() or cache.SetMissingWithTTL() to cache the negative result"},
+      {"id": "4.3", "text": "Missing cache is configured BEFORE Build() is called (in the builder chain)"},
+      {"id": "4.4", "text": "Explains or demonstrates that SetMissing without the config panics"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "loader-pattern-singleflight",
+    "description": "Tests whether the model uses the loader pattern correctly with singleflight awareness",
+    "prompt": "My Go service using samber/hot gets 1000 concurrent requests per second for the same cache key when it expires. I'm worried about all 1000 requests hitting the database simultaneously. How do I prevent this thundering herd?",
+    "trap": "Without the skill, the model implements manual singleflight or sync.Once, missing that samber/hot's WithLoaders already includes built-in singleflight deduplication",
+    "assertions": [
+      {"id": "5.1", "text": "Uses .WithLoaders() in the builder chain to register a loader function"},
+      {"id": "5.2", "text": "Explains that samber/hot has built-in singleflight deduplication — concurrent Get() calls for the same key share one loader invocation"},
+      {"id": "5.3", "text": "Does NOT implement manual singleflight or sync.Once on top of the cache"},
+      {"id": "5.4", "text": "The loader function signature matches func(keys []K) (map[K]V, error)"},
+      {"id": "5.5", "text": "Recommends WithJitter() to spread TTL expirations as an additional thundering-herd mitigation"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "stale-while-revalidate",
+    "description": "Tests knowledge of the two-threshold revalidation pattern",
+    "prompt": "I want my samber/hot cache in Go to return stale data while refreshing in the background, rather than blocking on cache miss. The data should be considered fresh for 5 minutes, then stale-but-servable for another 2 minutes, then fully expired. Show the setup.",
+    "trap": "Without the skill, the model sets a single TTL of 7 minutes, missing the WithRevalidation two-threshold pattern that serves stale data while refreshing",
+    "assertions": [
+      {"id": "6.1", "text": "Uses .WithTTL(5 * time.Minute) for the fresh duration"},
+      {"id": "6.2", "text": "Uses .WithRevalidation(2 * time.Minute, loader) for the stale duration after TTL"},
+      {"id": "6.3", "text": "Explains the two-threshold model: fresh -> stale (async refresh) -> expired"},
+      {"id": "6.4", "text": "Uses .WithRevalidationErrorPolicy() to handle refresh failures (KeepOnError or DropOnError)"},
+      {"id": "6.5", "text": "Does NOT use a single TTL of 7 minutes as the only configuration"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "sharding-for-concurrency",
+    "description": "Tests whether the model correctly uses sharding to reduce lock contention",
+    "prompt": "My Go service using samber/hot has high lock contention — 64 CPU cores, 500k cache entries, and profiling shows mutex contention on the cache. How do I fix this?",
+    "trap": "Without the skill, the model suggests WithoutLocking() (dangerous) or external sharding, missing the built-in WithSharding",
+    "assertions": [
+      {"id": "7.1", "text": "Uses .WithSharding() in the builder to split cache into segments"},
+      {"id": "7.2", "text": "Shard count is a power of 2 (e.g., 16, 32, 64)"},
+      {"id": "7.3", "text": "Provides or discusses a hash function of type func(K) uint64"},
+      {"id": "7.4", "text": "Does NOT recommend WithoutLocking() for a concurrent workload"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "copy-on-read-mutable-values",
+    "description": "Tests whether the model uses CopyOnRead/CopyOnWrite for mutable cached values",
+    "prompt": "I'm caching *User structs in samber/hot in my Go service. Multiple goroutines read from the cache and modify the returned user objects (e.g., setting computed fields). I'm seeing race conditions. What's wrong and how do I fix it?",
+    "trap": "Without the skill, the model suggests adding external mutexes or cloning manually after Get(), missing the built-in WithCopyOnRead",
+    "assertions": [
+      {"id": "8.1", "text": "Identifies that callers are mutating shared cached pointers"},
+      {"id": "8.2", "text": "Uses .WithCopyOnRead(fn) to return cloned copies on Get()"},
+      {"id": "8.3", "text": "The copy function creates a shallow or deep copy of the struct"},
+      {"id": "8.4", "text": "Does NOT suggest only adding external mutexes as the primary solution"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "loader-chain-semantics",
+    "description": "Tests understanding of multi-loader chain behavior — later overwrites earlier, error stops chain",
+    "prompt": "I want a samber/hot cache in Go with two loaders: first try Redis, then fall back to PostgreSQL for remaining keys. If Redis returns a value for key X and PostgreSQL also returns a value for key X, which one wins? What happens if Redis returns an error?",
+    "trap": "Without the skill, the model assumes first-loader-wins or doesn't know the chain semantics",
+    "assertions": [
+      {"id": "9.1", "text": "States that later loaders can overwrite earlier loader values for the same key (PostgreSQL wins)"},
+      {"id": "9.2", "text": "States that any loader error stops the entire chain immediately"},
+      {"id": "9.3", "text": "States that partial results from earlier loaders are discarded on error"},
+      {"id": "9.4", "text": "Shows WithLoaders(redisLoader, dbLoader) with Redis first, PostgreSQL second"},
+      {"id": "9.5", "text": "States that later loaders only receive keys NOT found by previous loaders"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "algorithm-scan-resistance",
+    "description": "SIEVE is the simple scan-resistant alternative to LRU; W-TinyLFU and S3FIFO are valid but heavier",
+    "prompt": "My Go service using samber/hot has a cache for product data. Periodically, a batch job scans through ALL 500k products sequentially, which evicts all the genuinely hot items. Currently using LRU.\n\nA teammate says: 'Switch to hot.WTinyLFU — it's scan-resistant and the general best-practice default.' Another says: 'hot.S3FIFO is specifically designed for scan resistance at high throughput.' My cache is small (5k items) and the access pattern outside the scans is not particularly skewed. Which should I use?",
+    "trap": "Both teammates recommend valid scan-resistant algorithms — W-TinyLFU and S3FIFO are both correct answers to scan pollution. But the skill's table shows: S3FIFO should avoid small caches (<1000 items — but 5k is borderline), and SIEVE is the 'simple scan-resistant LRU alternative' for non-highly-skewed patterns. The model should know SIEVE is the best fit when simplicity matters and access isn't highly skewed.",
+    "assertions": [
+      {"id": "10.1", "text": "Identifies that SIEVE is the most appropriate choice: simple scan-resistant LRU alternative for non-highly-skewed access patterns"},
+      {"id": "10.2", "text": "Acknowledges that W-TinyLFU and S3FIFO are valid but notes one or both have tradeoffs: W-TinyLFU adds complexity, S3FIFO is optimized for high-throughput/larger caches"},
+      {"id": "10.3", "text": "Explains why SIEVE resists scan pollution (items must be visited multiple times before eviction — single-pass scan items get evicted while hot items are retained)"},
+      {"id": "10.4", "text": "Uses hot.SIEVE as the algorithm constant in the implementation"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "withoutlocking-janitor-conflict",
+    "description": "Tests knowledge of the WithoutLocking/WithJanitor mutual exclusion",
+    "prompt": "I want maximum performance for my single-goroutine Go batch processor using samber/hot. I plan to use WithoutLocking() to skip mutex overhead and WithJanitor() for TTL cleanup. Show me the setup.",
+    "trap": "Without the skill, the model writes code combining both, which panics at runtime",
+    "assertions": [
+      {"id": "11.1", "text": "Warns that WithoutLocking() and WithJanitor() are mutually exclusive and will panic"},
+      {"id": "11.2", "text": "Recommends removing one of the two options"},
+      {"id": "11.3", "text": "Suggests manually calling Purge() or Delete() for cleanup without a janitor, OR dropping WithoutLocking() to keep the janitor"},
+      {"id": "11.4", "text": "Does NOT produce code that chains both WithoutLocking() and WithJanitor()"}
+    ]
+  },
+  {
+    "id": 12,
+    "name": "warmup-before-traffic",
+    "description": "Tests whether the model uses WithWarmUp to pre-populate the cache",
+    "prompt": "My Go HTTP service using samber/hot takes 30 seconds of slow responses after each deploy while the cache warms up from loader calls. How can I ensure the cache is populated before the server starts accepting traffic?",
+    "trap": "Without the skill, the model suggests a manual loop calling Set() before ListenAndServe, missing the built-in WithWarmUp or WithWarmUpWithTimeout",
+    "assertions": [
+      {"id": "12.1", "text": "Uses .WithWarmUp(fn) or .WithWarmUpWithTimeout(timeout, fn) in the builder"},
+      {"id": "12.2", "text": "The warm-up function signature returns (map[K]V, []K, error) — values, missing keys, error"},
+      {"id": "12.3", "text": "Warm-up happens before Build() returns, so the cache is ready when the server starts"},
+      {"id": "12.4", "text": "Does NOT manually loop through keys calling Set() before server start"}
+    ]
+  },
+  {
+    "id": 13,
+    "name": "prometheus-monitoring-setup",
+    "description": "Tests whether the model correctly sets up Prometheus metrics for the cache",
+    "prompt": "I want to monitor my samber/hot cache in Go with Prometheus. Show me how to set it up and what metrics to alert on.",
+    "trap": "Without the skill, the model creates custom Prometheus metrics manually instead of using the built-in WithPrometheusMetrics and prometheus.Collector interface",
+    "assertions": [
+      {"id": "13.1", "text": "Uses .WithPrometheusMetrics(cacheName) in the builder"},
+      {"id": "13.2", "text": "Registers the cache with prometheus.MustRegister(cache) or prometheus.Register(cache)"},
+      {"id": "13.3", "text": "Mentions hit rate as a key metric to monitor (target >80%)"},
+      {"id": "13.4", "text": "Does NOT create custom Prometheus counters/gauges manually for basic cache metrics"}
+    ]
+  },
+  {
+    "id": 14,
+    "name": "get-error-handling",
+    "description": "Tests whether the model correctly handles all three Get() return values",
+    "prompt": "Write a Go function that retrieves a user from a samber/hot cache. Handle all possible outcomes: cache hit, cache miss, and loader error.",
+    "trap": "Without the skill, the model checks only (value, ok) ignoring the error return, or only checks error ignoring the bool",
+    "assertions": [
+      {"id": "14.1", "text": "Get() returns three values: (V, bool, error)"},
+      {"id": "14.2", "text": "Checks error first before checking the bool"},
+      {"id": "14.3", "text": "Handles all three cases: err != nil (loader failure), !found (cache miss with no loader), found (cache hit)"},
+      {"id": "14.4", "text": "Does NOT ignore the error return value"}
+    ]
+  },
+  {
+    "id": 15,
+    "name": "peek-vs-get-distinction",
+    "description": "Tests understanding of Peek() having no side effects unlike Get()",
+    "prompt": "In my Go monitoring dashboard, I need to inspect what's in my samber/hot cache without affecting the cache behavior — no loader triggers, no expiration checks, no algorithm promotion. Which method should I use?",
+    "trap": "Without the skill, the model uses Get() or Has() which may trigger loaders or affect the eviction algorithm's internal state",
+    "assertions": [
+      {"id": "15.1", "text": "Recommends Peek() or PeekMany() for side-effect-free inspection"},
+      {"id": "15.2", "text": "Explains that Peek() does not trigger loaders"},
+      {"id": "15.3", "text": "Explains that Peek() ignores expiration (returns expired entries too)"},
+      {"id": "15.4", "text": "Does NOT recommend Get() for inspection purposes"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/algorithm-guide.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/algorithm-guide.md
new file mode 100644
index 00000000..2b0b4fc4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/algorithm-guide.md
@@ -0,0 +1,200 @@
+# Algorithm Selection Guide
+
+## Decision Tree
+
+```
+Start here
+  |
+  v
+Do you know your access pattern?
+  |-- No --> Use W-TinyLFU (adapts automatically)
+  |-- Yes
+       |
+       v
+     Is recency the primary signal? (sessions, recent queries, time-windowed data)
+       |-- Yes --> LRU
+       |-- No
+            |
+            v
+          Is frequency the primary signal? (popular products, DNS, static config)
+            |-- Yes --> Does the popularity ranking shift over time?
+            |           |-- Yes --> TinyLFU (frequency with decay)
+            |           |-- No --> LFU
+            |-- No
+                 |
+                 v
+               Is throughput critical and cache is large? (>100k items, high write rate)
+                 |-- Yes --> S3FIFO
+                 |-- No
+                      |
+                      v
+                    Do you want self-tuning with no config? (unknown or shifting patterns)
+                      |-- Yes --> ARC (higher memory) or W-TinyLFU (lower memory)
+                      |-- No
+                           |
+                           v
+                         Is scan resistance needed with simplicity?
+                           |-- Yes --> SIEVE
+                           |-- No --> W-TinyLFU (safe default)
+```
+
+## Algorithm Deep Dives
+
+### LRU (Least Recently Used)
+
+**Constant:** `hot.LRU`
+
+Evicts the item that hasn't been accessed for the longest time. Simple doubly-linked list + hash map implementation.
+
+- **Strengths:** Simple mental model, predictable behavior, low overhead per operation
+- **Weaknesses:** Scan pollution — a single sequential scan evicts all hot items. No frequency awareness.
+- **Ideal workload:** Time-windowed data (user sessions, recent search results, short-lived tokens)
+- **Degrades when:** A batch job or sequential scan touches many cold keys, evicting frequently-used items
+
+### LFU (Least Frequently Used)
+
+**Constant:** `hot.LFU`
+
+Evicts the item with the fewest accesses. Tracks access counts per key.
+
+- **Strengths:** Keeps genuinely popular items regardless of access timing
+- **Weaknesses:** Stale popular items never evict — an item accessed 10,000 times yesterday blocks new hot items today. No frequency decay.
+- **Ideal workload:** Stable popularity rankings (DNS records, country code lookups, static configuration)
+- **Degrades when:** Popularity shifts over time or new items need to ramp up quickly
+
+### TinyLFU
+
+**Constant:** `hot.TinyLFU`
+
+Combines frequency estimation with a compact Count-Min Sketch instead of per-key counters. Includes frequency decay — old access counts fade over time.
+
+- **Strengths:** Low memory overhead for frequency tracking, handles popularity shifts via decay, good admission filtering
+- **Weaknesses:** Admission filter adds overhead on writes. Sketch approximation can cause rare false positives.
+- **Ideal workload:** Read-heavy with moderate frequency bias (API response caching, content delivery metadata)
+- **Degrades when:** Write-heavy workloads where admission overhead exceeds the benefit
+
+### W-TinyLFU (Weighted TinyLFU)
+
+**Constant:** `hot.WTinyLFU`
+
+Adds a small "window" LRU in front of TinyLFU's admission filter. New items enter the window, and the admission filter decides whether they're promoted to the main cache. Balances recency and frequency automatically.
+
+- **Strengths:** Best general-purpose hit rate across diverse workloads. Self-adapting. Handles both recency and frequency patterns.
+- **Weaknesses:** Slightly more complex internals (harder to reason about eviction order during debugging)
+- **Ideal workload:** Mixed or unknown access patterns, general-purpose caching
+- **Degrades when:** Rarely — it's the safest default. May underperform specialized algorithms on extreme workloads.
+
+### S3FIFO (Segmented Small-Size FIFO)
+
+**Constant:** `hot.S3FIFO`
+
+Three-segment FIFO design: small, main, and ghost queues. Items promoted from small to main only if accessed again. Ghost queue tracks recently evicted keys for scan resistance.
+
+- **Strengths:** Excellent throughput (FIFO operations are cheaper than linked-list manipulations). Good scan resistance. Simple eviction path.
+- **Weaknesses:** Needs enough capacity for the segmented structure to work. Less effective on small caches.
+- **Ideal workload:** High-throughput systems with large caches (>100k items), CDN-like access patterns
+- **Degrades when:** Cache is very small (<1000 items) — the segments don't have enough room to differentiate access patterns
+
+### ARC (Adaptive Replacement Cache)
+
+**Constant:** `hot.ARC`
+
+Maintains four internal lists: two for recency (recent and recent-ghost) and two for frequency (frequent and frequent-ghost). Dynamically adjusts the split between recency and frequency based on which ghost list sees more hits.
+
+- **Strengths:** Self-tuning — learns from misses whether to favor recency or frequency. No manual parameter tuning.
+- **Weaknesses:** ~2x memory overhead for ghost lists. More complex implementation.
+- **Ideal workload:** Workloads that shift between recency and frequency patterns (mixed database query caching)
+- **Degrades when:** Memory is constrained — the ghost lists consume significant space
+
+### TwoQueue
+
+**Constant:** `hot.TwoQueue`
+
+Separates items into "hot" (frequently accessed) and "cold" (recently added) queues with independent eviction. Items graduate from cold to hot on second access.
+
+- **Strengths:** Good separation of one-hit wonders from genuinely useful items. Scan resistant.
+- **Weaknesses:** Requires understanding the hot/cold split ratio for optimal tuning
+- **Ideal workload:** Workloads with a clear hot/cold distinction (e.g., 20% of keys serve 80% of requests)
+- **Degrades when:** Access patterns are uniform with no clear hot/cold split
+
+### SIEVE
+
+**Constant:** `hot.SIEVE`
+
+Modern eviction algorithm that uses a single bit per entry (visited/not-visited) with a circular "hand" pointer. Simple scan-resistant alternative to LRU.
+
+- **Strengths:** Very low per-item overhead (1 bit). Scan-resistant. Simple implementation.
+- **Weaknesses:** Less sophisticated than W-TinyLFU or ARC for complex patterns
+- **Ideal workload:** When you want scan resistance with minimal complexity and overhead
+- **Degrades when:** Access patterns are highly skewed — specialized algorithms capture the skew better
+
+### FIFO (First In, First Out)
+
+**Constant:** `hot.FIFO`
+
+Evicts the oldest inserted item regardless of access pattern. No recency or frequency tracking.
+
+- **Strengths:** Simplest possible eviction. Predictable. Zero per-access overhead.
+- **Weaknesses:** No intelligence — ignores how often or recently items are accessed
+- **Ideal workload:** TTL-driven caches where all items have similar lifetimes and eviction order doesn't matter (log buffers, time-series windows)
+- **Degrades when:** Hit rate matters — any other algorithm will outperform FIFO on non-uniform access patterns
+
+## Comparison Matrix
+
+| Algorithm | Scan Resistance | Frequency Awareness | Memory Overhead | Throughput | Tuning Complexity |
+| --- | --- | --- | --- | --- | --- |
+| LRU | None | None | Low | High | None |
+| LFU | None | High (no decay) | Medium | Medium | None |
+| TinyLFU | Medium | High (with decay) | Low | Medium | None |
+| W-TinyLFU | High | High (with decay) | Low | Medium | None |
+| S3FIFO | High | Low | Medium | Very High | None |
+| ARC | High | Medium | High (2x) | Medium | None (self-tuning) |
+| TwoQueue | Medium | Medium | Medium | Medium | Low |
+| SIEVE | Medium | None | Very Low | High | None |
+| FIFO | None | None | Very Low | Very High | None |
+
+## Measuring Hit Rate
+
+Enable Prometheus metrics and check hit ratio to validate your algorithm choice:
+
+```go
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 10_000).
+    WithTTL(5 * time.Minute).
+    WithPrometheusMetrics("user_cache").
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()
+
+prometheus.MustRegister(cache)
+```
+
+Key PromQL queries:
+
+```promql
+# Hit ratio (target: >80%)
+rate(hot_cache_hit_count{cache="user_cache"}[5m]) /
+rate(hot_cache_get_count{cache="user_cache"}[5m])
+
+# Eviction rate (high = cache too small)
+rate(hot_cache_eviction_count{cache="user_cache"}[5m])
+```
+
+If hit rate is below your SLO: increase capacity first, then try a different algorithm.
+
+## Switching Algorithms
+
+Changing the algorithm is a one-line change — the rest of the builder chain stays identical:
+
+```go
+// Before
+cache := hot.NewHotCache[string, *User](hot.LRU, 10_000).
+    WithTTL(5 * time.Minute).
+    WithJanitor().
+    Build()
+
+// After — only the first argument changes
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 10_000).
+    WithTTL(5 * time.Minute).
+    WithJanitor().
+    Build()
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/api-reference.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/api-reference.md
new file mode 100644
index 00000000..4f1e608d
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/api-reference.md
@@ -0,0 +1,125 @@
+# API Reference
+
+## Constructor
+
+```go
+hot.NewHotCache[K comparable, V any](algorithm hot.EvictionAlgorithm, capacity int) *HotCacheBuilder[K, V]
+```
+
+**Algorithm constants:**
+
+| Constant       | Algorithm                              |
+| -------------- | -------------------------------------- |
+| `hot.LRU`      | Least Recently Used                    |
+| `hot.LFU`      | Least Frequently Used                  |
+| `hot.TinyLFU`  | TinyLFU with frequency decay           |
+| `hot.WTinyLFU` | Weighted TinyLFU (recommended default) |
+| `hot.S3FIFO`   | Segmented Small-Size FIFO              |
+| `hot.ARC`      | Adaptive Replacement Cache             |
+| `hot.TwoQueue` | Two-Queue                              |
+| `hot.SIEVE`    | SIEVE eviction                         |
+| `hot.FIFO`     | First In, First Out                    |
+
+## Builder Methods
+
+Call these on the builder returned by `NewHotCache()`, then finalize with `.Build()`.
+
+| Method | Description |
+| --- | --- |
+| `WithTTL(ttl time.Duration)` | Default expiration for all entries |
+| `WithJitter(lambda float64, upperBound time.Duration)` | Randomize TTL by +/-lambda (capped at upperBound) to prevent thundering herd |
+| `WithJanitor()` | Start background goroutine to evict expired entries. Mutually exclusive with `WithoutLocking()` |
+| `WithLoaders(loaders ...Loader[K, V])` | Chain of loader functions for cache misses. Execute sequentially; later loaders receive only unmapped keys |
+| `WithRevalidation(stale time.Duration, loaders ...Loader[K, V])` | Enable stale-while-revalidate. After TTL, entries become stale and trigger async refresh. Hard-expired after `stale` duration |
+| `WithRevalidationErrorPolicy(policy)` | `hot.KeepOnError` (keep stale value) or `hot.DropOnError` (drop on refresh failure) |
+| `WithMissingCache(algorithm, capacity)` | Dedicated cache for missing keys (independent eviction) |
+| `WithMissingSharedCache()` | Store missing keys in the main cache |
+| `WithSharding(shards uint64, hasher Hasher[K])` | Split into N shards to reduce lock contention. Use powers of 2 |
+| `WithCopyOnRead(fn func(V) V)` | Clone values on retrieval to prevent external mutation |
+| `WithCopyOnWrite(fn func(V) V)` | Clone values on storage to capture snapshots |
+| `WithPrometheusMetrics(cacheName string)` | Enable Prometheus metrics collection |
+| `WithEvictionCallback(fn func(K, V))` | Synchronous callback on eviction |
+| `WithoutLocking()` | Disable mutexes. Single-goroutine access only. Mutually exclusive with `WithJanitor()` |
+| `WithWarmUp(fn func() (map[K]V, []K, error))` | Pre-populate cache on build. Returns values + missing keys + error |
+| `WithWarmUpWithTimeout(timeout, fn)` | Same as WarmUp with timeout protection |
+| `Build()` | Finalize and return `*HotCache[K, V]` |
+
+## Read Operations
+
+| Method | Signature | Behavior |
+| --- | --- | --- |
+| `Get` | `(key K) (V, bool, error)` | Value, found, loader error. Triggers loaders on miss |
+| `GetWithLoaders` | `(key K, loaders ...Loader[K, V]) (V, bool, error)` | Per-call loader override |
+| `GetMany` | `(keys []K) (map[K]V, []K, error)` | Batch get. Returns found map + missing keys + error |
+| `GetManyWithLoaders` | `(keys []K, loaders ...Loader[K, V]) (map[K]V, []K, error)` | Batch with loader override |
+| `MustGet` | `(key K) (V, bool)` | Panics on loader error |
+| `MustGetWithLoaders` | `(key K, loaders ...Loader[K, V]) (V, bool)` | Panics on loader error |
+| `MustGetMany` | `(keys []K) (map[K]V, []K)` | Panics on error |
+| `MustGetManyWithLoaders` | `(keys []K, loaders ...Loader[K, V]) (map[K]V, []K)` | Panics on error |
+| `Peek` | `(key K) (V, bool)` | Read without side effects: no loaders, ignores expiration |
+| `PeekMany` | `(keys []K) (map[K]V, []K)` | Batch peek |
+| `Has` | `(key K) bool` | Key existence check without triggering loaders |
+| `HasMany` | `(keys []K) map[K]bool` | Batch existence check |
+| `Keys` | `() []K` | All keys with values (excludes missing entries) |
+| `Values` | `() []V` | All values |
+| `All` | `() map[K]V` | Key-value snapshot |
+| `Range` | `(fn func(K, V) bool)` | Iterate. Return false to stop |
+| `Len` | `() int` | Total item count |
+| `Capacity` | `() (int, int)` | Main capacity, missing cache capacity |
+| `Algorithm` | `() (string, string)` | Main algorithm name, missing algorithm name |
+
+## Write Operations
+
+| Method | Signature | Description |
+| --- | --- | --- |
+| `Set` | `(key K, value V)` | Set with default TTL |
+| `SetWithTTL` | `(key K, value V, ttl time.Duration)` | Set with custom TTL |
+| `SetMany` | `(items map[K]V)` | Batch set with default TTL |
+| `SetManyWithTTL` | `(items map[K]V, ttl time.Duration)` | Batch set with custom TTL |
+| `SetMissing` | `(key K)` | Mark key as non-existent. Requires `WithMissingCache()` or `WithMissingSharedCache()` |
+| `SetMissingWithTTL` | `(key K, ttl time.Duration)` | Mark missing with custom TTL |
+| `SetMissingMany` | `(keys []K)` | Batch mark as missing |
+| `SetMissingManyWithTTL` | `(keys []K, ttl time.Duration)` | Batch mark missing with custom TTL |
+
+## Maintenance Operations
+
+| Method | Signature | Description |
+| --- | --- | --- |
+| `Delete` | `(key K) bool` | Remove single key. Returns true if existed |
+| `DeleteMany` | `(keys []K) map[K]bool` | Batch delete. Returns existence map |
+| `Purge` | `()` | Clear all entries |
+| `WarmUp` | `(fn func() (map[K]V, []K, error)) error` | Pre-populate cache at runtime |
+| `Janitor` | `()` | Start background expiration cleanup |
+| `StopJanitor` | `()` | Stop background cleanup goroutine |
+
+## Loader Type
+
+```go
+type Loader[K comparable, V any] func(keys []K) (found map[K]V, err error)
+```
+
+**Chain semantics:**
+
+- Loaders execute sequentially in provided order
+- Each loader receives only **unmapped keys** from previous loaders
+- Later loader values **overwrite** earlier values for the same key
+- Any loader error stops the chain and returns `(nil, err)`
+- Built-in singleflight deduplication: concurrent `Get()` calls for the same key share one loader invocation
+
+## Hasher Type (for Sharding)
+
+```go
+type Hasher[K any] func(key K) uint64
+```
+
+## Prometheus Integration
+
+`*HotCache` implements `prometheus.Collector`. Register it to expose metrics:
+
+```go
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 10_000).
+    WithPrometheusMetrics("user_cache").
+    Build()
+
+prometheus.MustRegister(cache)
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/production-patterns.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/production-patterns.md
new file mode 100644
index 00000000..7bf52d54
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-hot/references/production-patterns.md
@@ -0,0 +1,228 @@
+# Production Patterns
+
+## Stale-While-Revalidate
+
+Return stale data immediately while refreshing in the background. Two time thresholds:
+
+1. **TTL** — after this, entries become "stale" and trigger async background refresh via loaders
+2. **Stale duration** — after TTL + stale, entries are hard-expired and removed
+
+```go
+refreshLoader := func(keys []string) (map[string]*Config, error) {
+    return fetchConfigsFromDB(keys)
+}
+
+cache := hot.NewHotCache[string, *Config](hot.WTinyLFU, 1_000).
+    WithTTL(5 * time.Minute).                              // stale after 5min
+    WithRevalidation(1 * time.Minute, refreshLoader).       // hard-expire after 6min total
+    WithRevalidationErrorPolicy(hot.KeepOnError).           // keep stale value if refresh fails
+    WithJitter(0.1, 30*time.Second).                        // spread expirations
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()
+```
+
+**Timeline for an entry set at T=0 with this config:**
+
+- T=0 to T=5min: fresh — returned directly
+- T=5min to T=6min: stale — returned immediately, background refresh triggered
+- T>6min: expired — removed, next `Get()` blocks on loader
+
+**Error policies:**
+
+- `hot.KeepOnError` — if background refresh fails, keep the stale value until hard expiry
+- `hot.DropOnError` — if refresh fails, drop the entry immediately
+
+Use `KeepOnError` when stale data is better than no data (config caches, product catalogs). Use `DropOnError` when correctness matters more than availability.
+
+## Sharding
+
+Split the cache into N independent segments to reduce lock contention under high concurrency:
+
+```go
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 100_000).
+    WithTTL(5 * time.Minute).
+    WithSharding(16, func(key string) uint64 {
+        h := fnv.New64a()
+        h.Write([]byte(key))
+        return h.Sum64()
+    }).
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()
+```
+
+**Sizing guidance:**
+
+- Use powers of 2 (4, 8, 16, 32) for optimal hash distribution
+- Rule of thumb: shard count ~= number of CPU cores for high-contention workloads
+- Each shard gets `capacity / shards` items
+- Over-sharding (>64 shards) adds overhead without benefit
+
+## Missing Key Caching (Negative Caching)
+
+Prevents repeated loader calls for keys that don't exist in the source:
+
+### Dedicated missing cache (recommended)
+
+Independent eviction algorithm and capacity — gives fine-grained control:
+
+```go
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 100_000).
+    WithTTL(1 * time.Hour).
+    WithMissingCache(hot.LFU, 10_000).  // separate LFU cache for missing keys
+    WithLoaders(userLoader).
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()
+```
+
+### Shared missing cache
+
+Missing entries stored in the main cache — simpler but uses main cache capacity:
+
+```go
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 100_000).
+    WithTTL(1 * time.Hour).
+    WithMissingSharedCache().
+    WithLoaders(userLoader).
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()
+```
+
+### Manual missing key marking
+
+```go
+// Mark individual key as missing
+cache.SetMissing("nonexistent-user")
+cache.SetMissingWithTTL("temp-missing", 5*time.Minute)
+
+// Batch mark missing
+cache.SetMissingMany([]string{"user:404", "user:405"})
+```
+
+**Important:** `Keys()`, `Values()`, `All()` exclude missing entries — they only return real values.
+
+## Loader Chains
+
+Multiple loaders execute sequentially for L1/L2 cache patterns:
+
+```go
+redisLoader := func(keys []string) (map[string]*User, error) {
+    return redis.MGet(ctx, keys...)
+}
+
+dbLoader := func(keys []string) (map[string]*User, error) {
+    return db.GetUsersByIDs(ctx, keys)
+}
+
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 10_000).
+    WithTTL(5 * time.Minute).
+    WithLoaders(redisLoader, dbLoader).  // Redis first, then DB for remaining
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()
+```
+
+**Chain behavior:**
+
+- `redisLoader` called first with all missing keys
+- `dbLoader` called only with keys NOT found by `redisLoader`
+- If both return the same key, `dbLoader`'s value wins (later overwrites earlier)
+- Any error stops the chain — partial results from earlier loaders are discarded
+
+## Copy-on-Read / Copy-on-Write
+
+Required when cached values are mutable (pointers, slices, maps):
+
+```go
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 10_000).
+    WithTTL(5 * time.Minute).
+    WithCopyOnRead(func(u *User) *User {
+        copy := *u
+        return &copy
+    }).
+    WithCopyOnWrite(func(u *User) *User {
+        copy := *u
+        return &copy
+    }).
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()
+```
+
+- **CopyOnRead** — clones at retrieval: callers get independent copies, mutations don't affect cache
+- **CopyOnWrite** — clones at storage: cache holds a snapshot, external mutations to the original don't corrupt cached value
+- Use both when callers read and write concurrently. Use only one when the mutation direction is known.
+
+## Prometheus Monitoring
+
+### Setup
+
+```go
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 10_000).
+    WithTTL(5 * time.Minute).
+    WithPrometheusMetrics("user_cache").
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()
+
+prometheus.MustRegister(cache)
+```
+
+### Key PromQL Queries
+
+```promql
+# Hit ratio (target: >80%)
+rate(hot_cache_hit_count{cache="user_cache"}[5m]) /
+rate(hot_cache_get_count{cache="user_cache"}[5m])
+
+# Eviction rate (high = cache too small or TTL too short)
+rate(hot_cache_eviction_count{cache="user_cache"}[5m])
+
+# Cache size vs capacity
+hot_cache_len{cache="user_cache"} / hot_cache_capacity{cache="user_cache"}
+```
+
+**Alerts to consider:**
+
+- Hit rate drops below 70% for >5 minutes — cache may be undersized
+- Eviction rate spikes — working set exceeds capacity
+- Cache size near capacity — consider increasing capacity or reviewing TTLs
+
+## Warm-Up on Startup
+
+Pre-populate the cache before serving traffic:
+
+```go
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 10_000).
+    WithTTL(1 * time.Hour).
+    WithWarmUp(func() (map[string]*User, []string, error) {
+        users, err := db.GetFrequentUsers(ctx)
+        if err != nil {
+            return nil, nil, err
+        }
+        missingKeys := []string{"deleted-user-1", "deleted-user-2"}
+        return users, missingKeys, nil  // values + known missing keys + error
+    }).
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()
+```
+
+Use `WithWarmUpWithTimeout(30*time.Second, fn)` to bound startup time.
+
+## Graceful Shutdown
+
+Always stop the janitor goroutine before exit:
+
+```go
+cache := hot.NewHotCache[string, *User](hot.WTinyLFU, 10_000).
+    WithTTL(5 * time.Minute).
+    WithJanitor().
+    Build()
+defer cache.StopJanitor()  // clean up background goroutine
+```
+
+In applications with graceful shutdown orchestration, call `cache.StopJanitor()` during the shutdown phase alongside other resource cleanup.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/SKILL.md
new file mode 100644
index 00000000..12037bb8
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/SKILL.md
@@ -0,0 +1,183 @@
+---
+name: golang-samber-lo
+description: "Functional programming helpers for Golang using samber/lo — 500+ type-safe generic functions for slices, maps, channels, strings, math, tuples, and concurrency (Map, Filter, Reduce, GroupBy, Chunk, Flatten, Find, Uniq, etc.). Core immutable package (lo), concurrent variants (lo/parallel aka lop), in-place mutations (lo/mutable aka lom), lazy iterators (lo/it aka loi for Go 1.23+), and experimental SIMD (lo/exp/simd). Apply when using or adopting samber/lo, when the codebase imports github.com/samber/lo, or when implementing functional-style data transformations in Go. Not for streaming pipelines (→ See `samber/cc-skills-golang@golang-samber-ro` skill)."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.0"
+  openclaw:
+    emoji: "🧰"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "1.53.0"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) mcp__context7__resolve-library-id mcp__context7__query-docs AskUserQuestion
+---
+
+**Persona:** You are a Go engineer who prefers declarative collection transforms over manual loops. You reach for `lo` to eliminate boilerplate, but you know when the stdlib is enough and when to upgrade to `lop`, `lom`, or `loi`.
+
+# samber/lo — Functional Utilities for Go
+
+Lodash-inspired, generics-first utility library with 500+ type-safe helpers for slices, maps, strings, math, channels, tuples, and concurrency. Zero external dependencies. Immutable by default.
+
+**Official Resources:**
+
+- [github.com/samber/lo](https://github.com/samber/lo)
+- [lo.samber.dev](https://lo.samber.dev)
+- [pkg.go.dev/github.com/samber/lo](https://pkg.go.dev/github.com/samber/lo)
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+## Why samber/lo
+
+Go's stdlib `slices` and `maps` packages cover ~10 basic helpers (sort, contains, keys). Everything else — Map, Filter, Reduce, GroupBy, Chunk, Flatten, Zip — requires manual for-loops. `lo` fills this gap:
+
+- **Type-safe generics** — no `interface{}` casts, no reflection, compile-time checking, no interface boxing overhead
+- **Immutable by default** — returns new collections, safe for concurrent reads, easier to reason about
+- **Composable** — functions take and return slices/maps, so they chain without wrapper types
+- **Zero dependencies** — only Go stdlib, no transitive dependency risk
+- **Progressive complexity** — start with `lo`, upgrade to `lop`/`lom`/`loi` only when profiling demands it
+- **Error variants** — most functions have `Err` suffixes (`MapErr`, `FilterErr`, `ReduceErr`) that stop on first error
+
+## Installation
+
+```bash
+go get github.com/samber/lo
+```
+
+| Package | Import | Alias | Go version |
+| --- | --- | --- | --- |
+| Core (immutable) | `github.com/samber/lo` | `lo` | 1.18+ |
+| Parallel | `github.com/samber/lo/parallel` | `lop` | 1.18+ |
+| Mutable | `github.com/samber/lo/mutable` | `lom` | 1.18+ |
+| Iterator | `github.com/samber/lo/it` | `loi` | 1.23+ |
+| SIMD (experimental) | `github.com/samber/lo/exp/simd` | — | 1.25+ (amd64 only) |
+
+## Choose the Right Package
+
+Start with `lo`. Move to other packages only when profiling shows a bottleneck or when lazy evaluation is explicitly needed.
+
+| Package | Use when | Trade-off |
+| --- | --- | --- |
+| `lo` | Default for all transforms | Allocates new collections (safe, predictable) |
+| `lop` | CPU-bound work on large datasets (1000+ items) | Goroutine overhead; not for I/O or small slices |
+| `lom` | Hot path confirmed by `pprof -alloc_objects` | Mutates input — caller must understand side effects |
+| `loi` | Large datasets with chained transforms (Go 1.23+) | Lazy evaluation saves memory but adds iterator complexity |
+| `simd` | Numeric bulk ops after benchmarking (experimental) | Unstable API, may break between versions |
+
+**Key rules:**
+
+- `lop` is for CPU parallelism, not I/O concurrency — for I/O fan-out, use `errgroup` instead
+- `lom` breaks immutability — only use when allocation pressure is measured, never assumed
+- `loi` eliminates intermediate allocations in chains like `Map → Filter → Take` by evaluating lazily
+- For reactive/streaming pipelines over infinite event streams, → see `samber/cc-skills-golang@golang-samber-ro` skill + `samber/ro` package
+
+For detailed package comparison and decision flowchart, see [Package Guide](./references/package-guide.md).
+
+## Core Patterns
+
+### Transform a slice
+
+```go
+// ✓ lo — declarative, type-safe
+names := lo.Map(users, func(u User, _ int) string {
+    return u.Name
+})
+
+// ✗ Manual — boilerplate, error-prone
+names := make([]string, 0, len(users))
+for _, u := range users {
+    names = append(names, u.Name)
+}
+```
+
+### Filter + Reduce
+
+```go
+total := lo.Reduce(
+    lo.Filter(orders, func(o Order, _ int) bool {
+        return o.Status == "paid"
+    }),
+    func(sum float64, o Order, _ int) float64 {
+        return sum + o.Amount
+    },
+    0,
+)
+```
+
+### GroupBy
+
+```go
+byStatus := lo.GroupBy(tasks, func(t Task, _ int) string {
+    return t.Status
+})
+// map[string][]Task{"open": [...], "closed": [...]}
+```
+
+### Error variant — stop on first error
+
+```go
+results, err := lo.MapErr(urls, func(url string, _ int) (Response, error) {
+    return http.Get(url)
+})
+```
+
+## Common Mistakes
+
+| Mistake | Why it fails | Fix |
+| --- | --- | --- |
+| Using `lo.Contains` when `slices.Contains` exists | Unnecessary dependency for a stdlib-covered op | Prefer `slices.Contains`/`slices.Sort` since Go 1.21+ and `slices.Collect(maps.Keys(m))` since Go 1.23+ when a key slice is needed |
+| Using `lop.Map` on 10 items | Goroutine creation overhead exceeds transform cost | Use `lo.Map` — `lop` benefits start at ~1000+ items for CPU-bound work |
+| Assuming `lo.Filter` modifies the input | `lo` is immutable by default — it returns a new slice | Use `lom.Filter` if you explicitly need in-place mutation |
+| Using `lo.Must` in production code paths | `Must` panics on error — fine in tests and init, dangerous in request handlers | Use the non-Must variant and handle the error |
+| Chaining many eager transforms on large data | Each step allocates an intermediate slice | Use `loi` (lazy iterators) to avoid intermediate allocations |
+
+## Best Practices
+
+1. **Prefer stdlib when available** — `slices.Contains` and `slices.Sort` (Go 1.21+) carry no dependency; `maps.Keys` is Go 1.23+ and returns an iterator, so use `slices.Collect(maps.Keys(m))` when you need a slice. Use `lo` for transforms the stdlib doesn't offer (Map, Filter, Reduce, GroupBy, Chunk, Flatten)
+2. **Compose lo functions** — chain `lo.Filter` → `lo.Map` → `lo.GroupBy` instead of writing nested loops. Each function is a building block
+3. **Profile before optimizing** — switch from `lo` to `lom`/`lop` only after `go tool pprof` confirms allocation or CPU as the bottleneck
+4. **Use error variants** — prefer `lo.MapErr` over `lo.Map` + manual error collection. Error variants stop early and propagate cleanly
+5. **Use `lo.Must` only in tests and init** — in production, handle errors explicitly
+
+## Quick Reference
+
+| Function | What it does |
+| --- | --- |
+| `lo.Map` | Transform each element |
+| `lo.Filter` / `lo.Reject` | Keep / remove elements matching predicate |
+| `lo.Reduce` | Fold elements into a single value |
+| `lo.ForEach` | Side-effect iteration |
+| `lo.GroupBy` | Group elements by key |
+| `lo.Chunk` | Split into fixed-size batches |
+| `lo.Flatten` | Flatten nested slices one level |
+| `lo.Uniq` / `lo.UniqBy` | Remove duplicates |
+| `lo.Find` / `lo.FindOrElse` | First match or default |
+| `lo.Contains` / `lo.Every` / `lo.Some` | Membership tests |
+| `lo.Keys` / `lo.Values` | Extract map keys or values |
+| `lo.PickBy` / `lo.OmitBy` | Filter map entries |
+| `lo.Zip2` / `lo.Unzip2` | Pair/unpair two slices |
+| `lo.Range` / `lo.RangeFrom` | Generate number sequences |
+| `lo.Ternary` / `lo.If` | Inline conditionals |
+| `lo.ToPtr` / `lo.FromPtr` | Pointer helpers |
+| `lo.Must` / `lo.Try` | Panic-on-error / recover-as-bool |
+| `lo.Async` / `lo.Attempt` | Async execution / retry with backoff |
+| `lo.Debounce` / `lo.Throttle` | Rate limiting |
+| `lo.ChannelDispatcher` | Fan-out to multiple channels |
+
+For the complete function catalog (300+ functions), see [API Reference](./references/api-reference.md).
+
+For composition patterns, stdlib interop, and iterator pipelines, see [Advanced Patterns](./references/advanced-patterns.md).
+
+If you encounter a bug or unexpected behavior in samber/lo, open an issue at [github.com/samber/lo/issues](https://github.com/samber/lo/issues).
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-samber-ro` skill for reactive/streaming pipelines over infinite event streams (`samber/ro` package)
+- → See `samber/cc-skills-golang@golang-samber-mo` skill for monadic types (Option, Result, Either) that compose with lo transforms
+- → See `samber/cc-skills-golang@golang-data-structures` skill for choosing the right underlying data structure
+- → See `samber/cc-skills-golang@golang-performance` skill for profiling methodology before switching to `lom`/`lop`
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/evals/evals.json
new file mode 100644
index 00000000..92b27c65
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/evals/evals.json
@@ -0,0 +1,226 @@
+{
+  "skill_name": "golang-samber-lo",
+  "evals": [
+    {
+      "id": 1,
+      "name": "lop-for-io-trap",
+      "prompt": "I have a Go service that needs to fetch data from 50 different REST APIs concurrently and collect results. I'm using samber/lo already. Should I use lop.Map to parallelize the HTTP calls? Write the implementation.",
+      "expected_output": "Should recommend errgroup (or similar) for I/O-bound concurrency instead of lop. lop is for CPU-bound parallelism. Should explain why lop is wrong here (no context cancellation, no error handling, goroutine-per-element overhead for I/O).",
+      "assertions": [
+        {"text": "Recommends errgroup or similar I/O concurrency pattern instead of (or in addition to) lop for HTTP calls", "type": "semantic"},
+        {"text": "Explains that lop is designed for CPU-bound parallelism, not I/O-bound work", "type": "semantic"},
+        {"text": "Mentions lack of context cancellation as a limitation of lop for I/O", "type": "semantic"},
+        {"text": "Does NOT simply use lop.Map as the primary solution for HTTP fan-out", "type": "semantic"},
+        {"text": "Shows working Go code for the concurrent HTTP fetch pattern", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 2,
+      "name": "premature-lom-optimization",
+      "prompt": "My Go API is a bit slow. I'm using lo.Filter and lo.Map in several places. I want to switch everything to lom.Filter and lom.Map for better performance. Can you help me refactor?",
+      "expected_output": "Should advise profiling first before switching to lom. Should warn about immutability loss. Should NOT blindly refactor everything to lom.",
+      "assertions": [
+        {"text": "Recommends profiling (pprof, alloc_objects) before switching to lom", "type": "semantic"},
+        {"text": "Warns that lom mutates the input slice (breaks immutability)", "type": "semantic"},
+        {"text": "Does NOT blindly refactor all lo calls to lom without questioning the premise", "type": "semantic"},
+        {"text": "Explains that the performance issue may not be caused by lo allocations", "type": "semantic"},
+        {"text": "Mentions that lom is only appropriate for hot paths confirmed by profiling", "type": "semantic"},
+        {"text": "Warns about concurrency safety implications of switching to mutable operations", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 3,
+      "name": "stdlib-vs-lo-preference",
+      "prompt": "I'm writing a Go function that needs to check if a string slice contains a value, sort an int slice, and get all keys from a map. I already have samber/lo as a dependency. Should I use lo.Contains, and lo.Keys for these?",
+      "expected_output": "Should recommend stdlib slices.Contains and slices.Sort over lo equivalents when using Go 1.21+. For map keys, should gate maps.Keys to Go 1.23+ and use slices.Collect(maps.Keys(m)) when a slice is needed. Should explain that stdlib is preferred for operations it covers.",
+      "assertions": [
+        {"text": "Recommends slices.Contains from stdlib over lo.Contains", "type": "semantic"},
+        {"text": "Recommends slices.Sort or slices.SortFunc from stdlib", "type": "semantic"},
+        {"text": "Recommends slices.Collect(maps.Keys(m)) from stdlib over lo.Keys when the module targets Go 1.23+", "type": "semantic"},
+        {"text": "Mentions Go 1.21+ for slices helpers and Go 1.23+ for maps.Keys", "type": "semantic"},
+        {"text": "Explains the rationale: prefer stdlib when it covers the operation to avoid unnecessary dependency usage", "type": "semantic"},
+        {"text": "Acknowledges that lo is still useful for operations stdlib doesn't provide (Map, Filter, Reduce, GroupBy)", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 4,
+      "name": "loi-go-version-constraint",
+      "prompt": "I'm building a data pipeline in Go 1.20 that chains multiple transformations on a large dataset (1M records). I want to use lo/it for lazy evaluation to avoid intermediate allocations. Show me how.",
+      "expected_output": "Should warn that lo/it requires Go 1.23+ and cannot be used with Go 1.20. Should suggest alternatives.",
+      "assertions": [
+        {"text": "Warns that lo/it (loi) requires Go 1.23+ and is not available in Go 1.20", "type": "semantic"},
+        {"text": "Suggests upgrading Go version to 1.23+ to use lo/it", "type": "semantic"},
+        {"text": "Provides alternative approaches for Go 1.20 (e.g., compose lo functions, manual pipeline, or accept intermediate allocations)", "type": "semantic"},
+        {"text": "Does NOT provide lo/it code that won't compile on Go 1.20", "type": "semantic"},
+        {"text": "Mentions that loi uses range-over-func which is a Go 1.23 feature", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 5,
+      "name": "must-init-scope-boundary",
+      "prompt": "I'm setting up a Go application. I use lo.Must in two places: (1) in main() to parse a required config file at startup, and (2) in an HTTP handler to parse each incoming request body. A teammate says both uses are wrong. Is that right?",
+      "expected_output": "Should distinguish: lo.Must is acceptable in main()/init() for startup failures where panicking is appropriate (app can't run without valid config). It is NOT acceptable in HTTP handlers where panics crash the request and potentially the server. The teammate is wrong about the init use case.",
+      "assertions": [
+        {"text": "Correctly identifies that lo.Must in main() for startup config parsing IS acceptable", "type": "semantic"},
+        {"text": "Correctly identifies that lo.Must in the HTTP handler is NOT acceptable (panics on each bad request)", "type": "semantic"},
+        {"text": "Does NOT blanket-reject all uses of Must — init/startup usage is valid", "type": "semantic"},
+        {"text": "Explains the reasoning: startup panics are appropriate failure modes; request panics are not", "type": "semantic"},
+        {"text": "Shows proper error handling in the HTTP handler (if err != nil with http.Error response)", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 6,
+      "name": "import-aliases-knowledge",
+      "prompt": "I want to use the parallel, mutable, and iterator sub-packages of samber/lo in my Go project. What are the correct import paths and conventional aliases?",
+      "expected_output": "Should list all import paths with their conventional aliases: lop, lom, loi.",
+      "assertions": [
+        {"text": "Lists github.com/samber/lo/parallel with alias lop", "type": "semantic"},
+        {"text": "Lists github.com/samber/lo/mutable with alias lom", "type": "semantic"},
+        {"text": "Lists github.com/samber/lo/it with alias loi", "type": "semantic"},
+        {"text": "Mentions that lo/it requires Go 1.23+", "type": "semantic"},
+        {"text": "Lists the core package github.com/samber/lo with alias lo", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 7,
+      "name": "immutability-trap",
+      "prompt": "I have this Go code using samber/lo:\n\nusers := []User{{Name: \"Alice\", Active: true}, {Name: \"Bob\", Active: false}}\nlo.Filter(users, func(u User, _ int) bool { return u.Active })\nfmt.Println(len(users)) // What does this print?\n\nWill the users slice be modified after the Filter call?",
+      "expected_output": "Should clearly state that lo.Filter does NOT modify the input slice. The original users slice still has 2 elements. Must mention immutability-by-default.",
+      "assertions": [
+        {"text": "States that lo.Filter returns a NEW slice and does NOT modify the input", "type": "semantic"},
+        {"text": "Correctly says len(users) still prints 2", "type": "semantic"},
+        {"text": "Explains that lo is immutable by default — all core functions return new collections", "type": "semantic"},
+        {"text": "Points out the bug: the return value of lo.Filter is discarded and should be assigned", "type": "semantic"},
+        {"text": "Mentions lom.Filter as the alternative if in-place mutation is desired", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 8,
+      "name": "error-variant-awareness",
+      "prompt": "I'm using samber/lo to transform a slice of URLs into responses by making HTTP calls. Some calls might fail. Currently I'm using lo.Map and collecting errors manually in a separate slice. Is there a better way?",
+      "expected_output": "Should recommend lo.MapErr which stops on first error, or lo.FilterMap for skipping errors. Should explain error variant pattern.",
+      "assertions": [
+        {"text": "Recommends lo.MapErr as the error-aware variant of lo.Map", "type": "semantic"},
+        {"text": "Explains that MapErr stops processing on the first error and returns (result, error)", "type": "semantic"},
+        {"text": "Shows the MapErr function signature or usage example", "type": "semantic"},
+        {"text": "Mentions that most lo functions have Err suffixes (FilterErr, ReduceErr, etc.)", "type": "semantic"},
+        {"text": "Alternatively suggests lo.FilterMap if the goal is to skip errors rather than stop", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 9,
+      "name": "simd-production-stability",
+      "prompt": "I want to use lo/exp/simd for optimizing numeric array operations in my production Go service. It processes millions of float64 values. Is this a good idea?",
+      "expected_output": "Should warn that simd is experimental, API may break between versions, not covered by semver stability. Recommend benchmarking first.",
+      "assertions": [
+        {"text": "Warns that lo/exp/simd is experimental and API may break between versions", "type": "semantic"},
+        {"text": "States it is NOT covered by semver stability guarantees", "type": "semantic"},
+        {"text": "Recommends benchmarking to verify actual performance gains before adopting", "type": "semantic"},
+        {"text": "Suggests version pinning if used despite experimental status", "type": "semantic"},
+        {"text": "Does NOT unconditionally recommend simd for production use", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 10,
+      "name": "streaming-redirect-to-ro",
+      "prompt": "I need to build a reactive data pipeline in Go that processes an infinite stream of events from Kafka, applies transformations, and publishes results. I'm already using samber/lo for batch transforms. Can I use lo for this streaming use case?",
+      "expected_output": "Should redirect to samber/ro for reactive/streaming pipelines. Should explain that lo is for finite/batch transforms, not infinite streams.",
+      "assertions": [
+        {"text": "Recommends samber/ro for reactive/streaming pipelines over infinite event streams", "type": "semantic"},
+        {"text": "Explains that lo is designed for finite/batch collection transforms, not infinite streams", "type": "semantic"},
+        {"text": "Mentions the golang-samber-ro skill or samber/ro package by name", "type": "semantic"},
+        {"text": "Does NOT attempt to use lo.Map/lo.Filter for infinite stream processing", "type": "semantic"},
+        {"text": "Explains the conceptual difference: lo = batch/finite, ro = reactive/infinite", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 11,
+      "name": "lop-threshold-cpu-vs-io",
+      "prompt": "I have two use cases in my Go service both using samber/lo. (A) I'm resizing 20 images in memory — each resize takes ~200ms of CPU. (B) I'm extracting the 'name' field from 50 user structs in memory. My teammate says I should switch both to lop for better performance. What do you think?",
+      "expected_output": "Case A (image resizing): lop is appropriate — CPU-bound work, substantial per-item cost, enough items to justify goroutine overhead. Case B (field extraction): lop is wrong — trivially cheap operation on a small dataset; goroutine overhead exceeds benefit. The teammate is only right about case A.",
+      "assertions": [
+        {"text": "Approves lop.Map for case A (CPU-bound image resizing with ~200ms per item)", "type": "semantic"},
+        {"text": "Rejects lop.Map for case B (trivial field extraction on 50 items)", "type": "semantic"},
+        {"text": "Distinguishes CPU-bound work (lop appropriate) from trivial/cheap operations (lo sufficient)", "type": "semantic"},
+        {"text": "Mentions that lop overhead only pays off for CPU-bound work on datasets of ~1000+ items OR expensive per-item operations", "type": "semantic"},
+        {"text": "Does NOT recommend lop for both use cases indiscriminately", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 12,
+      "name": "filtermap-vs-maperr-for-partial-failures",
+      "prompt": "I have a []string of user-supplied date strings. I need to parse each one with time.Parse, keep the successfully parsed dates, and silently discard parse failures (not stop on first error). I'm using samber/lo. What's the right approach?",
+      "expected_output": "Should recommend lo.FilterMap (not lo.MapErr which stops on first error, and not lo.Filter+lo.Map which creates an intermediate slice). FilterMap maps and keeps only successful results in a single pass. The key trap is that MapErr stops on the first error, which is the opposite of what's wanted here.",
+      "assertions": [
+        {"text": "Recommends lo.FilterMap for map-and-discard-failures in a single pass", "type": "semantic"},
+        {"text": "Does NOT recommend lo.MapErr (which stops on first error, not what's wanted)", "type": "semantic"},
+        {"text": "Shows FilterMap with a (time.Time, bool) return where bool is false on parse failure", "type": "semantic"},
+        {"text": "Explains that FilterMap silently discards items where the bool is false", "type": "semantic"},
+        {"text": "Does NOT chain lo.Filter + lo.Map as the primary solution (creates intermediate slice)", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 13,
+      "name": "channel-dispatcher-load-balancing-strategy",
+      "prompt": "I have a Go service that distributes tasks to 4 worker goroutines via channels. Workers have different processing speeds — some tasks go to a fast worker (handles 3x more), others to slower workers. I'm using samber/lo and already know about lo.ChannelDispatcher. Which dispatch strategy should I use so that faster workers receive proportionally more tasks?",
+      "expected_output": "Should recommend WeightedRandom strategy. RoundRobin ignores worker speed. Random is uniform. WeightedRandom lets you assign relative weights matching worker capacity. Should show how to configure weights.",
+      "assertions": [
+        {"text": "Recommends the WeightedRandom dispatch strategy (not RoundRobin or Random)", "type": "semantic"},
+        {"text": "Explains that RoundRobin distributes evenly regardless of worker capacity", "type": "semantic"},
+        {"text": "Explains that WeightedRandom allows assigning proportional weights to each output channel", "type": "semantic"},
+        {"text": "Shows lo.ChannelDispatcher usage with the WeightedRandom strategy and weights", "type": "semantic"},
+        {"text": "Does NOT recommend RoundRobin as the primary solution for unequal-capacity workers", "type": "semantic"},
+        {"text": "Shows or describes setting weights where the fast worker gets 3x the weight of slow workers", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 14,
+      "name": "v2-version-trap",
+      "prompt": "I want to upgrade my project from samber/lo v1 to v2 for the latest features. What's the migration path? Are there breaking changes?",
+      "expected_output": "Should clarify that there is no v2 of samber/lo. The library is on v1 with semver stability guarantees.",
+      "assertions": [
+        {"text": "States that samber/lo v2 does not exist — the library is on v1", "type": "semantic"},
+        {"text": "Mentions that v1 follows semantic versioning with no breaking changes before v2", "type": "semantic"},
+        {"text": "Provides the correct install command: go get github.com/samber/lo@v1", "type": "semantic"},
+        {"text": "Does NOT fabricate v2 migration steps or breaking changes", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 15,
+      "name": "lazy-chain-intermediate-allocations",
+      "prompt": "I have a pipeline in Go that processes 1M records: filter by status, map to extract fields, group by category, then take the top 10 from each group. Using samber/lo, each step creates an intermediate slice. How can I avoid these intermediate allocations?",
+      "expected_output": "Should recommend lo/it (loi) for lazy evaluation to eliminate intermediate allocations. Should explain the lazy pipeline pattern.",
+      "assertions": [
+        {"text": "Recommends lo/it (loi) for lazy evaluation to avoid intermediate slice allocations", "type": "semantic"},
+        {"text": "Explains that loi pipelines process elements on-demand without buffering intermediate results", "type": "semantic"},
+        {"text": "Mentions Go 1.23+ requirement for loi", "type": "semantic"},
+        {"text": "Shows or describes a lazy pipeline using loi functions", "type": "semantic"},
+        {"text": "Contrasts eager (lo) vs lazy (loi) approach in terms of memory allocation", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 16,
+      "name": "lo-zero-dependencies",
+      "prompt": "My team is concerned about adding samber/lo as a dependency. They worry about transitive dependencies and supply chain risk. What dependencies does samber/lo pull in?",
+      "expected_output": "Should state that samber/lo has zero external runtime dependencies — it relies only on Go's standard library.",
+      "assertions": [
+        {"text": "States that samber/lo has zero external/runtime dependencies", "type": "semantic"},
+        {"text": "Mentions it relies only on Go's standard library", "type": "semantic"},
+        {"text": "Addresses the supply chain concern by noting minimal transitive dependency risk", "type": "semantic"},
+        {"text": "Does NOT claim lo has external dependencies", "type": "semantic"}
+      ]
+    },
+    {
+      "id": 17,
+      "name": "ternary-side-effect-ordering",
+      "prompt": "I'm refactoring a Go function to use samber/lo for conciseness. I have this code:\n\n```go\nvar label string\nif isAdmin {\n    label = formatAdminLabel(user) // calls DB, expensive\n} else {\n    label = user.Name\n}\n```\n\nI rewrote it as:\n\n```go\nlabel := lo.Ternary(isAdmin, formatAdminLabel(user), user.Name)\n```\n\nMy colleague says this is a bug. Are they right?",
+      "expected_output": "Yes, the colleague is right. lo.Ternary is a regular Go function call — both arguments are evaluated before the function is called. formatAdminLabel(user) runs unconditionally even when isAdmin is false. Should recommend lo.TernaryF with closures so only the winning branch executes.",
+      "assertions": [
+        {"text": "Confirms the colleague is correct — this is indeed a bug", "type": "semantic"},
+        {"text": "Explains that lo.Ternary evaluates BOTH branches before the function is called (Go's eager argument evaluation)", "type": "semantic"},
+        {"text": "Identifies that formatAdminLabel(user) runs even when isAdmin is false", "type": "semantic"},
+        {"text": "Recommends lo.TernaryF with closures: lo.TernaryF(isAdmin, func() string { return formatAdminLabel(user) }, func() string { return user.Name })", "type": "semantic"}
+      ]
+    }
+  ]
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/advanced-patterns.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/advanced-patterns.md
new file mode 100644
index 00000000..2fb6479f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/advanced-patterns.md
@@ -0,0 +1,173 @@
+# Advanced Patterns
+
+## Composing Transformations
+
+Chain lo functions to build multi-step pipelines. Each function returns a new collection that feeds into the next.
+
+```go
+// Pipeline: extract active user emails grouped by role
+emailsByRole := lo.GroupBy(
+    lo.Map(
+        lo.Filter(users, func(u User, _ int) bool {
+            return u.Active && u.EmailVerified
+        }),
+        func(u User, _ int) UserEmail {
+            return UserEmail{Role: u.Role, Email: u.Email}
+        },
+    ),
+    func(ue UserEmail, _ int) string {
+        return ue.Role
+    },
+)
+```
+
+For long chains, break into named intermediate variables for readability:
+
+```go
+active := lo.Filter(users, func(u User, _ int) bool {
+    return u.Active
+})
+names := lo.Map(active, func(u User, _ int) string {
+    return u.Name
+})
+unique := lo.Uniq(names)
+```
+
+## lo + stdlib Interop
+
+Prefer stdlib when it covers the operation — `lo` adds value for functional transforms the stdlib doesn't provide.
+
+| Operation | stdlib (prefer) | lo (use when stdlib lacks) |
+| --- | --- | --- |
+| Contains | `slices.Contains(s, v)` | `lo.ContainsBy(s, fn)` — predicate-based |
+| Sort | `slices.SortFunc(s, cmp)` | — (lo doesn't provide sort) |
+| Keys | `maps.Keys(m)` | `lo.UniqKeys(m)` — deduplicated keys |
+| Clone | `slices.Clone(s)` | `lo.Map(s, fn)` — when you need transform during clone |
+| Min/Max | `slices.Min(s)` | `lo.MinBy(s, fn)` — by extractor function |
+
+**Rule of thumb:** If `slices.*` or `maps.*` does what you need, use it. Reach for `lo` when you need predicates, transforms, grouping, or error variants.
+
+## lo + samber/mo Integration
+
+`samber/mo` provides monadic types (Option, Result, Either). They compose naturally with lo:
+
+```go
+// Filter users with valid optional emails
+validEmails := lo.FilterMap(users, func(u User, _ int) (string, bool) {
+    email, ok := u.Email.Get()  // mo.Option[string]
+    return email, ok
+})
+
+// Map with Result — collect successes
+results := lo.FilterMap(urls, func(url string, _ int) (Response, bool) {
+    res := fetchURL(url)  // returns mo.Result[Response]
+    val, err := res.Get()
+    return val, err == nil
+})
+```
+
+## Iterator Patterns (loi)
+
+Requires Go 1.23+. Lazy iterators avoid intermediate allocations.
+
+### Eager vs lazy comparison
+
+```go
+// Eager — allocates 2 intermediate slices
+result := lo.Map(lo.Filter(bigSlice, filterFn), mapFn)
+
+// Lazy — zero intermediate allocations
+for v := range loi.Map(loi.Filter(bigSlice, filterFn), mapFn) {
+    process(v)
+}
+```
+
+### Building lazy pipelines
+
+```go
+// Lazy pipeline: filter → map → take first 10
+pipeline := loi.Take(
+    loi.Map(
+        loi.Filter(records, func(r Record) bool {
+            return r.Score > 0.8
+        }),
+        func(r Record) string {
+            return r.Name
+        },
+    ),
+    10,
+)
+
+// Consume with range
+for name := range pipeline {
+    fmt.Println(name)
+}
+```
+
+## Performance-Sensitive Patterns
+
+### When to switch from lo to lom
+
+**Trigger:** `go tool pprof -alloc_objects` shows `lo.Filter` or `lo.Map` as top allocators in a hot path.
+
+```go
+// Before — allocates new slice every call
+filtered := lo.Filter(events, isValid)
+
+// After — zero allocations, modifies in-place
+events = lom.Filter(events, isValid)
+// Warning: 'events' is now modified. Original data is lost.
+```
+
+### Parallel transforms
+
+**Trigger:** `go tool pprof -cpu` shows transform function dominating CPU on large datasets.
+
+```go
+// Switch from sequential to parallel
+results := lop.Map(largeSlice, expensiveTransform)
+```
+
+## Testing with lo
+
+lo helpers simplify test data generation and assertions:
+
+```go
+// Generate test fixtures
+users := lo.Times(100, func(i int) User {
+    return User{ID: i, Name: fmt.Sprintf("user-%d", i)}
+})
+
+// Assert subset relationships
+assert.True(t, lo.Every(expected, lo.Map(actual, extractID)))
+
+// Generate random test data
+ids := lo.Times(50, func(_ int) string {
+    return lo.RandomString(16, lo.AlphanumericCharset)
+})
+
+// Quick frequency check
+counts := lo.CountValues(results)
+assert.Equal(t, 3, counts["success"])
+```
+
+## Slice-to-Map Conversion
+
+Common pattern: convert a slice into a lookup map.
+
+```go
+// By ID
+userByID := lo.SliceToMap(users, func(u User) (int, User) {
+    return u.ID, u
+})
+
+// By key function
+userByEmail := lo.KeyBy(users, func(u User) string {
+    return u.Email
+})
+
+// Filter + convert in one pass
+activeByID := lo.FilterSliceToMap(users, func(u User) (int, User, bool) {
+    return u.ID, u, u.Active
+})
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/api-reference.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/api-reference.md
new file mode 100644
index 00000000..51ccd0b7
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/api-reference.md
@@ -0,0 +1,326 @@
+# API Reference
+
+Complete function catalog for `samber/lo` organized by domain.
+
+For up-to-date signatures, check [pkg.go.dev/github.com/samber/lo](https://pkg.go.dev/github.com/samber/lo) or use Context7.
+
+## Slice Transformations
+
+| Function | Description |
+| --- | --- |
+| `lo.Map(s, fn)` | Transform each element. `fn(item T, index int) R` |
+| `lo.MapErr(s, fn)` | Map with error — stops on first error |
+| `lo.UniqMap(s, fn)` | Map + deduplicate results in one pass |
+| `lo.Filter(s, fn)` | Keep elements where predicate returns true |
+| `lo.FilterErr(s, fn)` | Filter with error propagation |
+| `lo.Reject(s, fn)` | Remove elements where predicate returns true (inverse of Filter) |
+| `lo.RejectMap(s, fn)` | Reject + map in one pass |
+| `lo.FilterReject(s, fn)` | Split into `(matching, non-matching)` slices |
+| `lo.FlatMap(s, fn)` | Map then flatten one level |
+| `lo.FlatMapErr(s, fn)` | FlatMap with error propagation |
+| `lo.FilterMap(s, fn)` | Combined filter + map in one pass. `fn` returns `(R, bool)` |
+| `lo.Reduce(s, fn, init)` | Fold left into accumulator |
+| `lo.ReduceRight(s, fn, init)` | Fold right into accumulator |
+| `lo.ForEach(s, fn)` | Iterate with side effects |
+| `lo.ForEachWhile(s, fn)` | Iterate until `fn` returns false |
+| `lo.Times(n, fn)` | Call `fn(index)` n times, collect results |
+| `lo.Chunk(s, size)` | Split into batches of `size` |
+| `lo.Window(s, size)` | Sliding window of `size` over slice |
+| `lo.Sliding(s, size)` | Sliding window (overlapping), alias for Window |
+| `lo.Flatten(s)` | Flatten `[][]T` → `[]T` (one level) |
+| `lo.Concat(slices...)` | Concatenate multiple slices |
+| `lo.Interleave(slices...)` | Interleave elements from multiple slices |
+| `lo.Repeat(n, val)` | Create slice of `n` copies of `val` |
+| `lo.RepeatBy(n, fn)` | Create slice of `n` values from `fn(index)` |
+| `lo.Splice(s, i, elements...)` | Insert elements at index |
+| `lo.Fill(s, val)` | Fill slice with value (returns new slice) |
+| `lo.Reverse(s)` | Reverse order (returns new slice) |
+| `lo.Shuffle(s)` | Random shuffle (returns new slice) |
+| `lo.Clone(s)` | Shallow copy of slice |
+
+### Slice-to-map conversions
+
+| Function                     | Description                                 |
+| ---------------------------- | ------------------------------------------- |
+| `lo.KeyBy(s, fn)`            | Slice to map by key extractor. `fn(T) K`    |
+| `lo.Keyify(s, fn)`           | Alias for KeyBy                             |
+| `lo.SliceToMap(s, fn)`       | Slice to map. `fn(T) (K, V)`                |
+| `lo.Associate(s, fn)`        | Alias for SliceToMap                        |
+| `lo.FilterSliceToMap(s, fn)` | Filter + slice-to-map. `fn(T) (K, V, bool)` |
+| `lo.GroupBy(s, fn)`          | Group into `map[K][]V` by key function      |
+| `lo.GroupByMap(s, fn)`       | GroupBy returning `map[K]R` with transform  |
+
+### Error variants
+
+Most transform functions have `Err` suffixes: `MapErr`, `FlatMapErr`, `FilterErr`, `ReduceErr`, `ReduceRightErr`, `ForEachErr`, `GroupByErr`, `UniqByErr`, etc. These stop processing on the first error and return `(result, error)`.
+
+## Slice Queries
+
+| Function | Description |
+| --- | --- |
+| `lo.Find(s, fn)` | First element matching predicate. Returns `(T, bool)` |
+| `lo.FindOrElse(s, fallback, fn)` | First match or fallback value |
+| `lo.FindIndexOf(s, fn)` | First match with index. Returns `(T, int, bool)` |
+| `lo.FindLastIndexOf(s, fn)` | Last match with index |
+| `lo.FindKey(m, val)` | Find key by value in map |
+| `lo.FindKeyBy(m, fn)` | Find key by predicate in map |
+| `lo.IndexOf(s, val)` | Index of first occurrence (-1 if not found) |
+| `lo.LastIndexOf(s, val)` | Index of last occurrence |
+| `lo.Contains(s, val)` | True if slice contains value. Note: prefer `slices.Contains` (stdlib Go 1.21+) |
+| `lo.ContainsBy(s, fn)` | True if any element matches predicate |
+| `lo.Every(s, subset)` | True if all subset elements are in s |
+| `lo.EveryBy(s, fn)` | True if all elements match predicate |
+| `lo.Some(s, subset)` | True if any subset element is in s |
+| `lo.SomeBy(s, fn)` | True if any element matches predicate |
+| `lo.None(s, subset)` | True if no subset element is in s |
+| `lo.NoneBy(s, fn)` | True if no element matches predicate |
+| `lo.Count(s, val)` | Count occurrences of value |
+| `lo.CountBy(s, fn)` | Count elements matching predicate |
+| `lo.CountValues(s)` | Frequency map `map[T]int` |
+| `lo.CountValuesBy(s, fn)` | Frequency map by key function |
+| `lo.Min(s)` / `lo.Max(s)` | Min/max of comparable slice |
+| `lo.MinBy(s, fn)` / `lo.MaxBy(s, fn)` | Min/max by comparison function |
+| `lo.MinIndex(s)` / `lo.MaxIndex(s)` | Index of min/max element |
+| `lo.MinIndexBy(s, fn)` / `lo.MaxIndexBy(s, fn)` | Index of min/max by comparison |
+| `lo.Earliest(vals...)` | Earliest `time.Time` value |
+| `lo.EarliestBy(s, fn)` | Earliest by extractor function |
+| `lo.Latest(vals...)` | Latest `time.Time` value |
+| `lo.LatestBy(s, fn)` | Latest by extractor function |
+| `lo.First(s)` / `lo.Last(s)` | First/last element. Returns `(T, bool)` |
+| `lo.FirstOr(s, fallback)` | First element or fallback |
+| `lo.FirstOrEmpty(s)` | First element or zero-value |
+| `lo.LastOr(s, fallback)` | Last element or fallback |
+| `lo.LastOrEmpty(s)` | Last element or zero-value |
+| `lo.Nth(s, n)` | Element at index n (supports negative). Returns `(T, error)` |
+| `lo.NthOr(s, n, fallback)` | Nth element or fallback |
+| `lo.NthOrEmpty(s, n)` | Nth element or zero-value |
+| `lo.Sample(s)` | Random element |
+| `lo.SampleBy(s, fn)` | Random element matching predicate |
+| `lo.Samples(s, n)` | n random elements |
+| `lo.SamplesBy(s, n, fn)` | n random elements matching predicate |
+| `lo.IsSorted(s)` / `lo.IsSortedBy(s, fn)` | Check if slice is sorted |
+| `lo.HasPrefix(s, prefix)` | True if slice starts with prefix elements |
+| `lo.HasSuffix(s, suffix)` | True if slice ends with suffix elements |
+
+## Slice Set Operations
+
+| Function | Description |
+| --- | --- |
+| `lo.Uniq(s)` | Remove duplicates (preserves first occurrence) |
+| `lo.UniqBy(s, fn)` | Remove duplicates by key function |
+| `lo.PartitionBy(s, fn)` | Split into groups of consecutive elements with same key |
+| `lo.Compact(s)` | Remove zero-value elements |
+| `lo.Without(s, vals...)` | Remove specific values |
+| `lo.WithoutBy(s, fn)` | Remove elements matching predicate |
+| `lo.WithoutEmpty(s)` | Remove zero-value elements (alias for Compact) |
+| `lo.WithoutNth(s, indices...)` | Remove elements at specific indices |
+| `lo.Union(slices...)` | Combine slices, remove duplicates |
+| `lo.Intersect(a, b)` | Elements present in both slices |
+| `lo.IntersectBy(a, b, fn)` | Intersection by key function |
+| `lo.Difference(a, b)` | Elements in a but not in b |
+| `lo.Replace(s, old, new, n)` | Replace first n occurrences |
+| `lo.ReplaceAll(s, old, new)` | Replace all occurrences |
+| `lo.FindDuplicates(s)` | Elements that appear more than once |
+| `lo.FindDuplicatesBy(s, fn)` | Duplicates by key function |
+| `lo.FindUniques(s)` | Elements that appear exactly once |
+| `lo.FindUniquesBy(s, fn)` | Unique elements by key function |
+| `lo.ElementsMatch(a, b)` | True if same elements regardless of order |
+| `lo.ElementsMatchBy(a, b, fn)` | ElementsMatch by comparison function |
+| `lo.Subset(s, offset, length)` | Sub-slice from offset with length |
+| `lo.Slice(s, start, end)` | Sub-slice with bounds (safe, no panic) |
+
+### Slice trimming
+
+| Function                        | Description                              |
+| ------------------------------- | ---------------------------------------- |
+| `lo.Take(s, n)`                 | First n elements                         |
+| `lo.TakeWhile(s, fn)`           | Take while predicate is true             |
+| `lo.TakeFilter(s, n, fn)`       | Take first n elements matching predicate |
+| `lo.Drop(s, n)`                 | Skip first n elements                    |
+| `lo.DropRight(s, n)`            | Skip last n elements                     |
+| `lo.DropWhile(s, fn)`           | Drop while predicate is true             |
+| `lo.DropRightWhile(s, fn)`      | Drop from right while true               |
+| `lo.DropByIndex(s, indices...)` | Drop elements at specific indices        |
+| `lo.Cut(s, start, end)`         | Remove elements between start and end    |
+| `lo.CutPrefix(s, prefix)`       | Remove prefix from slice                 |
+| `lo.CutSuffix(s, suffix)`       | Remove suffix from slice                 |
+| `lo.Trim(s, fn)`                | Trim both ends while predicate is true   |
+| `lo.TrimLeft(s, fn)`            | Trim left while predicate is true        |
+| `lo.TrimRight(s, fn)`           | Trim right while predicate is true       |
+| `lo.TrimPrefix(s, prefix)`      | Remove exact prefix elements             |
+| `lo.TrimSuffix(s, suffix)`      | Remove exact suffix elements             |
+
+## Map Operations
+
+| Function | Description |
+| --- | --- |
+| `lo.Keys(m)` | All keys as a slice. Note: for Go 1.23+, prefer `slices.Collect(maps.Keys(m))` when stdlib coverage is enough |
+| `lo.UniqKeys(m)` | Unique keys (useful for multi-maps) |
+| `lo.Values(m)` | All values |
+| `lo.UniqValues(m)` | Unique values |
+| `lo.HasKey(m, key)` | True if key exists |
+| `lo.ValueOr(m, key, fallback)` | Value or fallback if key missing |
+| `lo.PickBy(m, fn)` | Keep entries where predicate is true |
+| `lo.PickByKeys(m, keys)` | Keep only specified keys |
+| `lo.PickByValues(m, vals)` | Keep only specified values |
+| `lo.OmitBy(m, fn)` | Remove entries where predicate is true |
+| `lo.OmitByKeys(m, keys)` | Remove specified keys |
+| `lo.OmitByValues(m, vals)` | Remove specified values |
+| `lo.FilterKeys(m, fn)` | Keep entries where key matches predicate |
+| `lo.FilterValues(m, fn)` | Keep entries where value matches predicate |
+| `lo.MapKeys(m, fn)` | Transform keys |
+| `lo.MapValues(m, fn)` | Transform values |
+| `lo.MapEntries(m, fn)` | Transform both key and value |
+| `lo.MapToSlice(m, fn)` | Convert map entries to slice |
+| `lo.FilterMapToSlice(m, fn)` | Filter + map-to-slice in one pass |
+| `lo.Entries(m)` / `lo.ToPairs(m)` | Map → `[]lo.Entry[K,V]` |
+| `lo.FromEntries(entries)` / `lo.FromPairs(pairs)` | `[]lo.Entry` → map |
+| `lo.Invert(m)` | Swap keys and values |
+| `lo.Assign(maps...)` | Merge maps (last wins) |
+| `lo.ChunkEntries(m, size)` | Split map into chunks of `size` entries |
+
+## String Operations
+
+| Function                          | Description                       |
+| --------------------------------- | --------------------------------- |
+| `lo.Substring(s, offset, length)` | Safe substring (rune-aware)       |
+| `lo.ChunkString(s, size)`         | Split string into chunks          |
+| `lo.RuneLength(s)`                | Count runes (not bytes)           |
+| `lo.PascalCase(s)`                | `"hello world"` → `"HelloWorld"`  |
+| `lo.CamelCase(s)`                 | `"hello world"` → `"helloWorld"`  |
+| `lo.KebabCase(s)`                 | `"hello world"` → `"hello-world"` |
+| `lo.SnakeCase(s)`                 | `"hello world"` → `"hello_world"` |
+| `lo.Words(s)`                     | Split into words                  |
+| `lo.Capitalize(s)`                | Capitalize first letter           |
+| `lo.Ellipsis(s, maxLen)`          | Truncate with `…`                 |
+| `lo.RandomString(n, charset)`     | Generate random string            |
+
+## Math & Comparison
+
+| Function                                | Description                        |
+| --------------------------------------- | ---------------------------------- |
+| `lo.Range(n)`                           | `[0, 1, ..., n-1]`                 |
+| `lo.RangeFrom(start, n)`                | `[start, start+1, ..., start+n-1]` |
+| `lo.RangeWithSteps(start, end, step)`   | Custom step range                  |
+| `lo.Clamp(val, min, max)`               | Constrain value to range           |
+| `lo.Sum(s)`                             | Sum of numeric slice               |
+| `lo.SumBy(s, fn)`                       | Sum by extractor function          |
+| `lo.Product(s)` / `lo.ProductBy(s, fn)` | Product of elements                |
+| `lo.Mean(s)` / `lo.MeanBy(s, fn)`       | Arithmetic mean                    |
+| `lo.Mode(s)`                            | Most frequent element(s)           |
+
+### Conditionals
+
+| Function | Description |
+| --- | --- |
+| `lo.Ternary(cond, a, b)` | Inline if/else (both values evaluated) |
+| `lo.TernaryF(cond, fnA, fnB)` | Lazy ternary (only winning branch evaluated) |
+| `lo.If(cond, val).ElseIf(cond2, val2).Else(val3)` | Chained conditional |
+| `lo.IfF(cond, fn).ElseIfF(cond2, fn2).ElseF(fn3)` | Chained conditional with lazy evaluation |
+| `lo.Switch[R](val).Case(v1, r1).Case(v2, r2).Default(r3)` | Pattern matching |
+
+## Tuples
+
+| Function | Description |
+| --- | --- |
+| `lo.T2(a, b)` ... `lo.T9(...)` | Create tuple from values |
+| `lo.Unpack2(t)` ... `lo.Unpack9(t)` | Destructure tuple into values |
+| `lo.Zip2(a, b)` ... `lo.Zip9(...)` | Pair elements from multiple slices |
+| `lo.ZipBy2(a, b, fn)` ... `lo.ZipBy9(...)` | Zip with custom merge function |
+| `lo.Unzip2(pairs)` ... `lo.Unzip9(...)` | Split pairs back into slices |
+| `lo.UnzipBy2(s, fn)` ... `lo.UnzipBy9(...)` | Unzip with custom split function |
+| `lo.CrossJoin2(a, b)` ... `lo.CrossJoin9(...)` | Cartesian product of slices |
+| `lo.CrossJoinBy2(a, b, fn)` ... `lo.CrossJoinBy9(...)` | Cartesian product with transform |
+
+## Channel Operations
+
+| Function | Description |
+| --- | --- |
+| `lo.ChannelDispatcher(ch, count, strategy)` | Fan-out to multiple channels. Strategies: `RoundRobin`, `Random`, `WeightedRandom`, `First`, `Least`, `Most` |
+| `lo.SliceToChannel(bufSize, s)` | Convert slice to buffered channel |
+| `lo.ChannelToSlice(ch)` | Collect channel into slice |
+| `lo.Generator(bufSize, fn)` | Create channel from generator function |
+| `lo.Buffer(ch, size)` | Buffer channel output |
+| `lo.BufferWithContext(ctx, ch, size)` | Buffer with context cancellation |
+| `lo.BufferWithTimeout(ch, size, timeout)` | Buffer with timeout |
+| `lo.FanIn(channels...)` | Merge multiple channels into one |
+| `lo.FanOut(ch, count)` | Duplicate channel to multiple consumers |
+
+## Concurrency Helpers
+
+| Function | Description |
+| --- | --- |
+| `lo.Async(fn)` | Run function in goroutine, return channel for result |
+| `lo.Async0` ... `lo.Async6` | Async with tuple returns |
+| `lo.Attempt(maxRetries, fn)` | Retry until success or max retries |
+| `lo.AttemptWithDelay(max, delay, fn)` | Retry with fixed delay between attempts |
+| `lo.AttemptWhile(fn)` | Retry while predicate returns true |
+| `lo.AttemptWhileWithDelay(delay, fn)` | AttemptWhile with delay between attempts |
+| `lo.Debounce(duration, fn)` | Debounce — execute after quiet period. Returns `(func(), func())` (trigger, cancel) |
+| `lo.DebounceBy(duration, fn)` | Debounce by key — separate debounce per key |
+| `lo.Throttle(duration, fn)` | Throttle — max one execution per duration |
+| `lo.ThrottleWithCount(duration, count, fn)` | Throttle allowing N executions per duration |
+| `lo.ThrottleBy(duration, fn)` | Throttle by key — separate throttle per key |
+| `lo.ThrottleByWithCount(duration, count, fn)` | ThrottleBy with count |
+| `lo.WaitFor(fn, timeout, heartbeat)` | Poll until condition met or timeout |
+| `lo.WaitForWithContext(ctx, fn, ...)` | WaitFor with context cancellation |
+| `lo.Synchronize(mutexes...)` | Create synchronized wrapper. `sync.Locker`-based |
+| `lo.Transaction(fn)` | Execute function with rollback on error |
+
+## Type Manipulation
+
+| Function | Description |
+| --- | --- |
+| `lo.ToPtr(v)` | Value to pointer (`&v`) |
+| `lo.Nil[T]()` | Typed nil pointer |
+| `lo.EmptyableToPtr(v)` | Value to pointer, zero-value becomes nil |
+| `lo.FromPtr(p)` | Pointer to value (zero-value if nil) |
+| `lo.FromPtrOr(p, fallback)` | Pointer to value with fallback |
+| `lo.ToSlicePtr(s)` | `[]T` → `[]*T` |
+| `lo.FromSlicePtr(s)` | `[]*T` → `[]T` (nil becomes zero-value) |
+| `lo.FromSlicePtrOr(s, fallback)` | `[]*T` → `[]T` with fallback for nil |
+| `lo.ToAnySlice(s)` | `[]T` → `[]any` |
+| `lo.FromAnySlice[T](s)` | `[]any` → `([]T, bool)` |
+| `lo.IsNil(v)` | Nil-safe check (handles interface nil) |
+| `lo.IsNotNil(v)` | Inverse of IsNil |
+| `lo.Empty[T]()` | Zero-value of type T |
+| `lo.IsEmpty(v)` | True if zero-value |
+| `lo.IsNotEmpty(v)` | True if not zero-value |
+| `lo.Coalesce(vals...)` | First non-zero value |
+| `lo.CoalesceOrEmpty(vals...)` | First non-zero or zero-value |
+| `lo.CoalesceSlice(slices...)` | First non-empty slice |
+| `lo.CoalesceSliceOrEmpty(slices...)` | First non-empty slice or empty |
+| `lo.CoalesceMap(maps...)` | First non-empty map |
+| `lo.CoalesceMapOrEmpty(maps...)` | First non-empty map or empty |
+
+## Function Helpers
+
+| Function | Description |
+| --- | --- |
+| `lo.Partial(fn, arg)` | Partial application — bind first argument |
+| `lo.Partial2(fn, arg)` ... `lo.Partial5(fn, arg)` | Partial with 2-5 args |
+
+## Duration Helpers
+
+| Function | Description |
+| --- | --- |
+| `lo.Duration(fn)` | Measure execution time. Returns `time.Duration` |
+| `lo.Duration0(fn)` ... `lo.Duration10(fn)` | Duration with 0-10 return values — returns `(time.Duration, ...)` |
+
+## Error Helpers
+
+| Function | Description |
+| --- | --- |
+| `lo.Must(val, err)` | Panic if err != nil, return val. Use in tests/init only |
+| `lo.Must0(err)` ... `lo.Must6(...)` | Must with 0-6 return values |
+| `lo.Try(fn)` | Run fn, return true if no panic |
+| `lo.Try1(fn)` ... `lo.Try6(fn)` | Try with 1-6 return values |
+| `lo.TryOr(fn, fallback)` | Run fn, return fallback on panic |
+| `lo.TryOr1(fn, fallback)` ... `lo.TryOr6(...)` | TryOr with 1-6 return values |
+| `lo.TryCatch(fn, catchFn)` | Try with catch handler |
+| `lo.TryWithErrorValue(fn)` | Try returning recovered error value |
+| `lo.TryCatchWithErrorValue(fn, catchFn)` | TryCatch with error value |
+| `lo.Validate(conditions...)` | Return first error from condition list |
+| `lo.ErrorsAs[T](err)` | Generic wrapper for `errors.As` |
+| `lo.Assert[T](v)` | Type assertion with panic message |
+| `lo.Assertf[T](v, format, args...)` | Type assertion with formatted panic message |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/package-guide.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/package-guide.md
new file mode 100644
index 00000000..682f9c10
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-lo/references/package-guide.md
@@ -0,0 +1,175 @@
+# Package Guide
+
+samber/lo ships five packages. Each serves a different performance/ergonomics trade-off.
+
+## Import Paths and Aliases
+
+```go
+import (
+    "github.com/samber/lo"            // lo  — core, immutable
+    "github.com/samber/lo/parallel"    // lop — concurrent transforms
+    "github.com/samber/lo/mutable"     // lom — in-place mutations
+    "github.com/samber/lo/it"          // loi — lazy iterators (Go 1.23+)
+    "github.com/samber/lo/exp/simd"    // experimental SIMD
+)
+```
+
+## `lo` — Core (Immutable)
+
+The default package. 300+ functions that return new collections without modifying inputs.
+
+**Mental model:** Functional transforms like JavaScript's `Array.prototype.map/filter/reduce`, but type-safe via generics.
+
+**Characteristics:**
+
+- Every function allocates a new result slice/map — the input is never modified
+- Safe for concurrent reads on the input while transforms run
+- Composable: output of one function feeds directly into the next
+
+**Use when:** Always start here. Only move to other packages when profiling reveals a measured bottleneck.
+
+```go
+// Immutable — users slice is untouched
+active := lo.Filter(users, func(u User, _ int) bool {
+    return u.Active
+})
+```
+
+## `lo/parallel` (lop) — Concurrent Transforms
+
+Parallel variants of core functions. Each element is processed in a separate goroutine with automatic worker pooling.
+
+**Available functions:** `Map`, `ForEach`, `Times`, `GroupBy`, `PartitionBy`
+
+**Characteristics:**
+
+- Results preserve original order despite concurrent execution
+- Internal goroutine pool manages concurrency (not configurable via API — one goroutine per element)
+- Synchronization via `sync.WaitGroup`
+
+**Use when:**
+
+- CPU-bound transforms on large datasets (~1000+ items)
+- Transform function is expensive (parsing, hashing, computing)
+- Order must be preserved
+
+**Do NOT use when:**
+
+- Small datasets (<100 items) — goroutine creation overhead exceeds benefit
+- I/O-bound work (HTTP calls, DB queries) — use `errgroup` with context cancellation instead
+- Transform function is trivial (field access, type cast) — `lo.Map` is faster
+
+```go
+// CPU-heavy: parse 10k JSON documents in parallel
+parsed := lop.Map(rawDocs, func(doc []byte, _ int) *Document {
+    return parseDocument(doc) // expensive operation
+})
+```
+
+**Diagnose:** `go tool pprof -cpu` — if transform function dominates CPU profile and dataset is large, `lop` helps.
+
+## `lo/mutable` (lom) — In-Place Mutations
+
+Modify the original slice directly. Zero allocation overhead.
+
+**Available functions:** `Filter`, `Map`, `Shuffle`, `Reverse`, `Replace`
+
+**Characteristics:**
+
+- Modifies the input slice — callers must expect side effects
+- `lom.Filter` shortens the slice (removes non-matching elements in-place)
+- `lom.Map` transforms elements in-place (preserves length)
+- Uses Fisher-Yates for `Shuffle`
+- Not safe for concurrent access to the source slice
+
+**Use when:**
+
+- `go tool pprof -alloc_objects` confirms allocation pressure from `lo.Filter`/`lo.Map`
+- Working with very large slices where GC pressure is measurable
+- You explicitly want to modify the source and won't need the original
+
+**Do NOT use when:**
+
+- Multiple goroutines read the same slice
+- You need the original data after the transform
+- Code readability matters more than micro-optimization
+
+```go
+// In-place filter — modifies 'items' directly
+items = lom.Filter(items, func(item Item, _ int) bool {
+    return item.Price > 0
+})
+```
+
+**Diagnose:** 1- `go tool pprof -alloc_objects` — find which `lo.*` calls allocate the most 2- `go build -gcflags="-m"` — check if result slices escape to heap
+
+## `lo/it` (loi) — Lazy Iterators
+
+Go 1.23+ iterator support with lazy evaluation. Transforms are deferred until consumed — no intermediate slices allocated.
+
+**Characteristics:**
+
+- Uses `range`-over-func (Go 1.23+)
+- Composable pipelines: `loi.Map` → `loi.Filter` → `loi.Take` runs as a single pass
+- No intermediate slice allocations between pipeline stages
+- Modules: `channel`, `find`, `intersect`, `map`, `math`, `seq`, `string`, `tuples`, `type_manipulation`
+
+**Use when:**
+
+- Chaining 3+ transforms on large datasets — eliminates intermediate allocations
+- Processing sequences where you only need a subset (lazy `Take`/`TakeWhile`)
+- Building composable pipelines with range-over-func
+
+**Do NOT use when:**
+
+- Go version < 1.23
+- Simple single-step transforms — `lo.Map` is clearer and has negligible overhead
+- You need random access to intermediate results
+
+```go
+// Lazy pipeline — no intermediate slices allocated
+for name := range loi.Map(
+    loi.Filter(users, func(u User) bool { return u.Active }),
+    func(u User) string { return u.Name },
+) {
+    fmt.Println(name)
+}
+```
+
+## `lo/exp/simd` — Experimental SIMD
+
+SIMD (Single Instruction Multiple Data) optimized operations for numeric types on amd64.
+
+**Use when:** Bulk numeric operations after benchmarking confirms the bottleneck. Very specialized.
+
+**Warning:** This package is experimental. API may break between minor versions. Not covered by semver stability guarantees. Do not use in production without version pinning.
+
+## Decision Flowchart
+
+```
+Start with lo.Map/Filter/Reduce (immutable, safe)
+  │
+  ├─ Profiler shows allocation pressure?
+  │    └─ Yes → Switch specific calls to lom (mutable)
+  │
+  ├─ Profiler shows CPU-bound transform is slow?
+  │    └─ Yes + large dataset → Switch to lop (parallel)
+  │
+  ├─ Chaining 3+ transforms with intermediate allocations?
+  │    └─ Yes + Go 1.23+ → Switch to loi (lazy iterators)
+  │
+  └─ Need reactive/streaming over infinite events?
+       └─ Yes → Use samber/ro instead (different library)
+```
+
+## Comparison Table
+
+| Aspect | `lo` | `lop` | `lom` | `loi` | `simd` |
+| --- | --- | --- | --- | --- | --- |
+| Allocations | New slice/map | New slice/map | Zero (in-place) | Zero (lazy) | Varies |
+| Goroutines | None | 1 per element | None | None | None |
+| Order preserved | Yes | Yes | Yes | Yes | Yes |
+| Input modified | No | No | Yes | No | Varies |
+| Concurrent-safe | Read-safe | Read-safe | Not safe | Read-safe | Varies |
+| API stability | Stable | Stable | Stable | Stable | Experimental |
+| Go version | 1.18+ | 1.18+ | 1.18+ | 1.23+ | 1.25+ |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/SKILL.md
new file mode 100644
index 00000000..794f087c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/SKILL.md
@@ -0,0 +1,275 @@
+---
+name: golang-samber-mo
+description: "Monadic types for Golang using samber/mo — Option, Result, Either, Future, IO, Task, and State types for type-safe nullable values, error handling, and functional composition with pipeline sub-packages. Apply when using or adopting samber/mo, when the codebase imports `github.com/samber/mo`, or when considering functional programming patterns as a safety design for Golang."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.0.4"
+  openclaw:
+    emoji: "🎭"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "1.16.0"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs AskUserQuestion
+---
+
+**Persona:** You are a Go engineer bringing functional programming safety to Go. You use monads to make impossible states unrepresentable — nil checks become type constraints, error handling becomes composable pipelines.
+
+**Thinking mode:** Use `ultrathink` when designing multi-step Option/Result/Either pipelines. Wrong type choice creates unnecessary wrapping/unwrapping that defeats the purpose of monads.
+
+# samber/mo — Monads and Functional Abstractions for Go
+
+Go 1.18+ library providing type-safe monadic types with zero dependencies. Inspired by Scala, Rust, and fp-ts.
+
+**Official Resources:**
+
+- [pkg.go.dev/github.com/samber/mo](https://pkg.go.dev/github.com/samber/mo)
+- [github.com/samber/mo](https://github.com/samber/mo)
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+```bash
+go get github.com/samber/mo
+```
+
+For an introduction to functional programming concepts and why monads are valuable in Go, see [Monads Guide](./references/monads-guide.md).
+
+## Core Types at a Glance
+
+| Type | Purpose | Think of it as... |
+| --- | --- | --- |
+| `Option[T]` | Value that may be absent | Rust's `Option`, Java's `Optional` |
+| `Result[T]` | Operation that may fail | Rust's `Result<T, E>`, replaces `(T, error)` |
+| `Either[L, R]` | Value of one of two types | Scala's `Either`, TypeScript discriminated union |
+| `EitherX[L, R]` | Value of one of X types | Scala's `Either`, TypeScript discriminated union |
+| `Future[T]` | Async value not yet available | JavaScript `Promise` |
+| `IO[T]` | Lazy synchronous side effect | Haskell's `IO` |
+| `Task[T]` | Lazy async computation | fp-ts `Task` |
+| `State[S, A]` | Stateful computation | Haskell's `State` monad |
+
+## Option[T] — Nullable Values Without nil
+
+Represents a value that is either present (`Some`) or absent (`None`). Eliminates nil pointer risks at the type level.
+
+```go
+import "github.com/samber/mo"
+
+name := mo.Some("Alice")          // Option[string] with value
+empty := mo.None[string]()        // Option[string] without value
+fromPtr := mo.PointerToOption(ptr) // nil pointer -> None
+
+// Safe extraction
+name.OrElse("Anonymous")  // "Alice"
+empty.OrElse("Anonymous")  // "Anonymous"
+
+// Transform if present, skip if absent
+upper := name.Map(func(s string) (string, bool) {
+    return strings.ToUpper(s), true
+})
+```
+
+**Key methods:** `Some`, `None`, `Get`, `MustGet`, `OrElse`, `OrEmpty`, `Map`, `FlatMap`, `Match`, `ForEach`, `ToPointer`, `IsPresent`, `IsAbsent`.
+
+Option implements `json.Marshaler/Unmarshaler`, `sql.Scanner`, `driver.Valuer` — use it directly in JSON structs and database models.
+
+For full API reference, see [Option Reference](./references/option.md).
+
+## Result[T] — Error Handling as Values
+
+Represents success (`Ok`) or failure (`Err`). Equivalent to `Either[error, T]` but specialized for Go's error pattern.
+
+```go
+// Wrap Go's (value, error) pattern
+result := mo.TupleToResult(os.ReadFile("config.yaml"))
+
+// Same-type transform — errors short-circuit automatically
+upper := mo.Ok("hello").Map(func(s string) (string, error) {
+    return strings.ToUpper(s), nil
+})
+// Ok("HELLO")
+
+// Extract with fallback
+val := upper.OrElse("default")
+```
+
+**Go limitation:** Direct methods (`.Map`, `.FlatMap`) cannot change the type parameter — `Result[T].Map` returns `Result[T]`, not `Result[U]`. Go methods cannot introduce new type parameters. For type-changing transforms (e.g. `Result[[]byte]` to `Result[Config]`), use sub-package functions or `mo.Do`:
+
+```go
+import "github.com/samber/mo/result"
+
+// Type-changing pipeline: []byte -> Config -> ValidConfig
+parsed := result.Pipe2(
+    mo.TupleToResult(os.ReadFile("config.yaml")),
+    result.Map(func(data []byte) Config { return parseConfig(data) }),
+    result.FlatMap(func(cfg Config) mo.Result[ValidConfig] { return validate(cfg) }),
+)
+```
+
+**Key methods:** `Ok`, `Err`, `Errf`, `TupleToResult`, `Try`, `Get`, `MustGet`, `OrElse`, `Map`, `FlatMap`, `MapErr`, `Match`, `ForEach`, `ToEither`, `IsOk`, `IsError`.
+
+For full API reference, see [Result Reference](./references/result.md).
+
+## Either[L, R] — Discriminated Union of Two Types
+
+Represents a value that is one of two possible types. Unlike Result, neither side implies success or failure — both are valid alternatives.
+
+```go
+// API that returns either cached data or fresh data
+func fetchUser(id string) mo.Either[CachedUser, FreshUser] {
+    if cached, ok := cache.Get(id); ok {
+        return mo.Left[CachedUser, FreshUser](cached)
+    }
+    return mo.Right[CachedUser, FreshUser](db.Fetch(id))
+}
+
+// Pattern match
+result := fetchUser("user-123")
+result.Match(
+    func(cached CachedUser) mo.Either[CachedUser, FreshUser] { /* use cached */ },
+    func(fresh FreshUser) mo.Either[CachedUser, FreshUser] { /* use fresh */ },
+)
+```
+
+**When to use Either vs Result:** Use `Result[T]` when one path is an error. Use `Either[L, R]` when both paths are valid alternatives (cached vs fresh, left vs right, strategy A vs B).
+
+`Either3[T1, T2, T3]`, `Either4`, and `Either5` extend this to 3-5 type variants.
+
+For full API reference, see [Either Reference](./references/either.md).
+
+## Do Notation — Imperative Style with Monadic Safety
+
+`mo.Do` wraps imperative code in a `Result`, catching panics from `MustGet()` calls:
+
+```go
+result := mo.Do(func() int {
+    // MustGet panics on None/Err — Do catches it as Result error
+    a := mo.Some(21).MustGet()
+    b := mo.Ok(2).MustGet()
+    return a * b  // 42
+})
+// result is Ok(42)
+
+result := mo.Do(func() int {
+    val := mo.None[int]().MustGet()  // panics
+    return val
+})
+// result is Err("no such element")
+```
+
+Do notation bridges imperative Go style with monadic safety — write straight-line code, get automatic error propagation.
+
+## Pipeline Sub-Packages vs Direct Chaining
+
+samber/mo provides two ways to compose operations:
+
+**Direct methods** (`.Map`, `.FlatMap`) — work when the output type equals the input type:
+
+```go
+opt := mo.Some(42)
+doubled := opt.Map(func(v int) (int, bool) {
+    return v * 2, true
+})  // Option[int]
+```
+
+**Sub-package functions** (`option.Map`, `result.Map`) — required when the output type differs from input:
+
+```go
+import "github.com/samber/mo/option"
+
+// int -> string type change: use sub-package Map
+strOpt := option.Map(func(v int) string {
+    return fmt.Sprintf("value: %d", v)
+})(mo.Some(42))  // Option[string]
+```
+
+**Pipe functions** (`option.Pipe3`, `result.Pipe3`) — chain multiple type-changing transformations readably:
+
+```go
+import "github.com/samber/mo/option"
+
+result := option.Pipe3(
+    mo.Some(42),
+    option.Map(func(v int) string { return strconv.Itoa(v) }),
+    option.Map(func(s string) []byte { return []byte(s) }),
+    option.FlatMap(func(b []byte) mo.Option[string] {
+        if len(b) > 0 { return mo.Some(string(b)) }
+        return mo.None[string]()
+    }),
+)
+```
+
+**Rule of thumb:** Use direct methods for same-type transforms. Use sub-package functions + pipes when types change across steps.
+
+For detailed pipeline API reference, see [Pipelines Reference](./references/pipelines.md).
+
+## Common Patterns
+
+### JSON API responses with Option
+
+```go
+type UserResponse struct {
+    Name     string            `json:"name"`
+    Nickname mo.Option[string] `json:"nickname"`  // omits null gracefully
+    Bio      mo.Option[string] `json:"bio"`
+}
+```
+
+### Database nullable columns
+
+```go
+type User struct {
+    ID       int
+    Email    string
+    Phone    mo.Option[string]  // implements sql.Scanner + driver.Valuer
+}
+
+err := row.Scan(&u.ID, &u.Email, &u.Phone)
+```
+
+### Wrapping existing Go APIs
+
+```go
+// Convert map lookup to Option
+func MapGet[K comparable, V any](m map[K]V, key K) mo.Option[V] {
+    return mo.TupleToOption(m[key])  // m[key] returns (V, bool)
+}
+```
+
+### Uniform extraction with Fold
+
+`mo.Fold` works uniformly across Option, Result, and Either via the `Foldable` interface:
+
+```go
+str := mo.Fold[error, int, string](
+    mo.Ok(42),  // works with Option, Result, or Either
+    func(v int) string { return fmt.Sprintf("got %d", v) },
+    func(err error) string { return "failed" },
+)
+// "got 42"
+```
+
+## Best Practices
+
+1. **Prefer `OrElse` over `MustGet`** — `MustGet` panics on absent/error values; use it only inside `mo.Do` blocks where panics are caught, or when you are certain the value exists
+2. **Use `TupleToResult` at API boundaries** — convert Go's `(T, error)` to `Result[T]` at the boundary, then chain with `Map`/`FlatMap` inside your domain logic
+3. **Use `Result[T]` for errors, `Either[L, R]` for alternatives** — Result is specialized for success/failure; Either is for two valid types
+4. **Option for nullable fields, not zero values** — `Option[string]` distinguishes "absent" from "empty string"; use plain `string` when empty string is a valid value
+5. **Chain, don't nest** — `result.Map(...).FlatMap(...).OrElse(default)` reads left-to-right; avoid nested if/else patterns when monadic chaining is cleaner
+6. **Use sub-package pipes for multi-step type transformations** — when 3+ steps each change the type, `option.Pipe3(...)` is more readable than nested function calls
+
+For advanced types (Future, IO, Task, State), see [Advanced Types Reference](./references/advanced-types.md).
+
+If you encounter a bug or unexpected behavior in samber/mo, open an issue at <https://github.com/samber/mo/issues>.
+
+## Cross-References
+
+- -> See `samber/cc-skills-golang@golang-samber-lo` skill for functional collection transforms (Map, Filter, Reduce on slices) that compose with mo types
+- -> See `samber/cc-skills-golang@golang-error-handling` skill for idiomatic Go error handling patterns
+- -> See `samber/cc-skills-golang@golang-safety` skill for nil-safety and defensive Go coding
+- -> See `samber/cc-skills-golang@golang-database` skill for database access patterns
+- -> See `samber/cc-skills-golang@golang-design-patterns` skill for functional options and other Go patterns
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/evals/evals.json
new file mode 100644
index 00000000..f5366393
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/evals/evals.json
@@ -0,0 +1,311 @@
+[
+  {
+    "id": 1,
+    "name": "option-vs-pointer-for-nullable-db-field",
+    "description": "Tests whether the model uses Option[T] instead of *T for nullable database columns when both SQL scanning and JSON marshaling are needed",
+    "prompt": "I'm adding a REST API to an existing Go service. The User table has a nullable 'phone' column (VARCHAR) and a nullable 'bio' column (TEXT). The same User struct is used both for database row scanning and for JSON API responses. Right now I'm using *string for these fields. I have samber/mo available. Is there a better option and what does the struct look like?",
+    "trap": "Without the skill, the model suggests keeping *string (it works for both DB and JSON), or proposes sql.NullString for DB + a separate DTO struct for JSON. The skill teaches that mo.Option[T] natively implements BOTH sql.Scanner/driver.Valuer AND json.Marshaler/Unmarshaler, eliminating the need for two types or custom serialization code.",
+    "assertions": [
+      {"id": "1.1", "text": "Recommends switching from *string to mo.Option[string] for the nullable fields"},
+      {"id": "1.2", "text": "Explains that Option implements sql.Scanner and driver.Valuer so row.Scan works directly"},
+      {"id": "1.3", "text": "Explains that Option implements json.Marshaler/Unmarshaler so the same struct works for JSON responses"},
+      {"id": "1.4", "text": "Explicitly states that *string requires custom JSON handling to distinguish null vs absent, which Option avoids"},
+      {"id": "1.5", "text": "Does NOT recommend maintaining two separate structs (one for DB, one for JSON) as the solution"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "result-vs-tuple-error-boundary",
+    "description": "Tests whether the model knows when to use Result[T] vs (T, error)",
+    "prompt": "I'm writing a Go function that reads a config file, parses YAML, validates the config, and returns the result. The function is part of a public API package. Should I use samber/mo Result[T] as the return type?",
+    "trap": "Without the skill, the model either always uses Result or always uses (T, error). The correct answer is: use (T, error) at public API boundaries for Go idiom compliance, but use Result internally for chaining.",
+    "assertions": [
+      {"id": "2.1", "text": "Recommends returning (Config, error) at the public API boundary, not Result[Config]"},
+      {"id": "2.2", "text": "Suggests using Result[T] internally for chaining the read-parse-validate pipeline"},
+      {"id": "2.3", "text": "Shows TupleToResult to convert from Go-style to Result at the start of the chain"},
+      {"id": "2.4", "text": "Shows .Get() or extraction at the end to convert back to (T, error) for the public return"},
+      {"id": "2.5", "text": "Explains that Result is for internal composition, not public API signatures"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "either-vs-result-two-valid-types",
+    "description": "Tests whether the model uses Either[L,R] when both outcomes are valid (not errors)",
+    "prompt": "I have a Go function that looks up a user. It can return either a cached user (from Redis, includes cache metadata) or a fresh user (from the database, no cache metadata). Both outcomes are perfectly valid. What type should the return be?",
+    "trap": "Without the skill, the model uses an interface, two separate return values, or Result. Either[CachedUser, FreshUser] is correct because neither outcome is an error.",
+    "assertions": [
+      {"id": "3.1", "text": "Uses mo.Either[CachedUser, FreshUser] or equivalent Either type"},
+      {"id": "3.2", "text": "Does NOT use Result[T] (neither outcome is an error)"},
+      {"id": "3.3", "text": "Explains that Either is for two valid alternatives, Result is for success/failure"},
+      {"id": "3.4", "text": "Shows Left/Right constructors for the two outcomes"},
+      {"id": "3.5", "text": "Shows Match or IsLeft/IsRight to handle both cases"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "sub-package-for-type-changing-map",
+    "description": "Tests whether the model uses sub-package functions when Map needs to change types",
+    "prompt": "I have an mo.Option[int] and I want to convert it to mo.Option[string] using strconv.Itoa. How do I do this with samber/mo?",
+    "trap": "Without the skill, the model tries Option.Map which cannot change types (Map returns Option[T] not Option[R]). The sub-package option.Map is required for type-changing transforms.",
+    "assertions": [
+      {"id": "4.1", "text": "Uses option.Map from the github.com/samber/mo/option sub-package"},
+      {"id": "4.2", "text": "Does NOT try to use the direct .Map method for type-changing transform"},
+      {"id": "4.3", "text": "Imports github.com/samber/mo/option"},
+      {"id": "4.4", "text": "Shows the curried form: option.Map(func(int) string)(opt)"},
+      {"id": "4.5", "text": "Explains that Go methods cannot introduce new type parameters, hence sub-packages"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "do-notation-for-imperative-monadic",
+    "description": "Tests knowledge of mo.Do for imperative-style monadic code",
+    "prompt": "I have several mo.Option and mo.Result values in Go that I need to combine. I want to extract all their values, do some computation, and get a Result back. The FlatMap chaining is getting deeply nested. Is there a simpler way?",
+    "trap": "Without the skill, the model doesn't know about mo.Do which catches MustGet panics and converts them to Result errors, enabling imperative-style monadic code.",
+    "assertions": [
+      {"id": "5.1", "text": "Suggests using mo.Do to wrap imperative-style code"},
+      {"id": "5.2", "text": "Shows MustGet() calls inside the Do block (panics caught by Do)"},
+      {"id": "5.3", "text": "Explains that mo.Do catches panics from MustGet and converts them to Err"},
+      {"id": "5.4", "text": "The result of mo.Do is a Result[T]"},
+      {"id": "5.5", "text": "Shows that this is cleaner than deeply nested FlatMap chains"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "pipe-composition-multi-step",
+    "description": "Tests whether the model uses Pipe functions for multi-step type-changing pipelines",
+    "prompt": "I need to transform an mo.Option[int] through 3 steps in Go: convert to string, then to []byte, then validate and return Option[ValidatedData]. Each step changes the type. Show me how to compose these.",
+    "trap": "Without the skill, the model nests function calls or uses intermediate variables. Pipe3 from the option sub-package provides readable left-to-right flow.",
+    "assertions": [
+      {"id": "6.1", "text": "Uses option.Pipe3 (or equivalent PipeN) from github.com/samber/mo/option"},
+      {"id": "6.2", "text": "Each step uses option.Map or option.FlatMap as a curried function"},
+      {"id": "6.3", "text": "The pipeline reads top-to-bottom or left-to-right, not nested inside-out"},
+      {"id": "6.4", "text": "Imports github.com/samber/mo/option sub-package"},
+      {"id": "6.5", "text": "Uses option.FlatMap for the validation step that may return None"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "future-vs-task-eager-vs-lazy",
+    "description": "Tests whether the model distinguishes Future (eager) from Task (lazy)",
+    "prompt": "I'm building a Go system where I want to define an async computation that should NOT start executing until I explicitly trigger it. Later I'll run it and get the result. Should I use mo.Future or mo.Task?",
+    "trap": "Without the skill, the model uses Future which starts executing immediately on creation. Task is lazy — it only runs when .Run() is called.",
+    "assertions": [
+      {"id": "7.1", "text": "Recommends mo.Task (not Future) because Task is lazy"},
+      {"id": "7.2", "text": "Explains that Future starts executing immediately on construction"},
+      {"id": "7.3", "text": "Explains that Task only executes when .Run() is called"},
+      {"id": "7.4", "text": "Shows that task.Run() returns a *Future[T]"},
+      {"id": "7.5", "text": "Demonstrates the deferred execution pattern with Task"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "tuple-to-result-wrapping-stdlib",
+    "description": "Tests knowledge of TupleToResult for wrapping Go stdlib calls",
+    "prompt": "I want to wrap os.ReadFile and strconv.Atoi calls into samber/mo Result types in Go so I can chain them. What's the most concise way?",
+    "trap": "Without the skill, the model manually calls the function, checks error, and constructs Ok/Err. TupleToResult wraps (T, error) tuples directly.",
+    "assertions": [
+      {"id": "8.1", "text": "Uses mo.TupleToResult(os.ReadFile(path)) to wrap directly"},
+      {"id": "8.2", "text": "Uses mo.TupleToResult(strconv.Atoi(s)) or mo.Try for the second call"},
+      {"id": "8.3", "text": "Does NOT manually check err and construct Ok/Err separately"},
+      {"id": "8.4", "text": "Chains the two results using Map or FlatMap"},
+      {"id": "8.5", "text": "Shows that TupleToResult converts (T, error) to Result[T] in one call"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "when-not-to-use-monads",
+    "description": "Tests whether the model correctly advises against monads for simple cases",
+    "prompt": "I have a simple Go function that opens a file. If it fails, I log the error and return. There are no subsequent operations to chain. Should I use samber/mo Result for this?",
+    "trap": "Without the skill, the model might over-apply monads to trivial cases. Plain if err != nil is clearer for single-step error handling.",
+    "assertions": [
+      {"id": "9.1", "text": "Advises against using Result for this simple one-step case"},
+      {"id": "9.2", "text": "Recommends standard Go if err != nil pattern"},
+      {"id": "9.3", "text": "Explains that Result shines with multi-step chains, not single operations"},
+      {"id": "9.4", "text": "Does NOT wrap everything in Result just because the library is available"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "option-json-serialization-behavior",
+    "description": "Tests knowledge of Option's JSON marshaling behavior",
+    "prompt": "In my Go API response struct, I have a field that should be null in JSON when absent and the actual value when present. I'm currently using *string with json omitempty but it shows null instead of omitting. How should I handle this with samber/mo?",
+    "trap": "Without the skill, the model doesn't know that Option marshals Some(x) to x and None to null, and that Go 1.24+ supports omitzero for full omission.",
+    "assertions": [
+      {"id": "10.1", "text": "Uses mo.Option[string] for the nullable JSON field"},
+      {"id": "10.2", "text": "Explains that Some(x) marshals to the raw value x, None marshals to null"},
+      {"id": "10.3", "text": "Mentions omitzero tag (Go 1.24+) or IsZero for omitting None fields entirely"},
+      {"id": "10.4", "text": "Shows the struct definition with json tag"},
+      {"id": "10.5", "text": "Does NOT require a custom MarshalJSON method — Option handles it natively"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "emptyable-to-option-zero-value",
+    "description": "Tests knowledge of EmptyableToOption for zero-value detection",
+    "prompt": "I'm receiving a Go struct from an external API where empty string means 'not provided'. I want to convert these empty strings to None and non-empty strings to Some. What's the most concise way with samber/mo?",
+    "trap": "Without the skill, the model writes if/else to check for empty string. EmptyableToOption does this automatically for any comparable type.",
+    "assertions": [
+      {"id": "11.1", "text": "Uses mo.EmptyableToOption to convert zero values to None"},
+      {"id": "11.2", "text": "Shows that EmptyableToOption returns None for zero value, Some for non-zero"},
+      {"id": "11.3", "text": "Does NOT write a manual if s == \"\" check when EmptyableToOption exists"},
+      {"id": "11.4", "text": "Mentions that this works for any comparable type (int 0, empty string, etc.)"}
+    ]
+  },
+  {
+    "id": 12,
+    "name": "pointer-to-option-nil-handling",
+    "description": "Tests knowledge of PointerToOption for nil pointer conversion",
+    "prompt": "I'm parsing a Go JSON payload where fields are *int (pointer to int, nil when absent). I want to convert these to Option[int] for safer downstream processing. How?",
+    "trap": "Without the skill, the model dereferences the pointer manually with nil check. PointerToOption does this in one call.",
+    "assertions": [
+      {"id": "12.1", "text": "Uses mo.PointerToOption(ptr) to convert *int to Option[int]"},
+      {"id": "12.2", "text": "Explains that nil pointer becomes None, non-nil becomes Some(*ptr)"},
+      {"id": "12.3", "text": "Does NOT manually check if ptr != nil before wrapping"}
+    ]
+  },
+  {
+    "id": 13,
+    "name": "result-map-vs-flatmap-choice",
+    "description": "Tests understanding of when to use Map vs FlatMap on Result",
+    "prompt": "I have a mo.Result[string] in Go. I need to chain two operations: (1) convert string to uppercase (infallible), (2) parse the string as an integer (fallible, returns Result[int]). Which methods should I use?",
+    "trap": "Without the skill, the model uses Map for both or FlatMap for both. Map is for infallible transforms, FlatMap is for transforms that return Result.",
+    "assertions": [
+      {"id": "13.1", "text": "Uses MapValue (or Map returning nil error) for the infallible uppercase operation"},
+      {"id": "13.2", "text": "Uses FlatMap for the fallible parse operation that returns Result[int]"},
+      {"id": "13.3", "text": "Does NOT use FlatMap for the simple uppercase transform"},
+      {"id": "13.4", "text": "Shows the chain: result.MapValue(toUpper).FlatMap(parse) or equivalent"},
+      {"id": "13.5", "text": "Explains the distinction: Map wraps the return value, FlatMap takes a function returning Result"}
+    ]
+  },
+  {
+    "id": 14,
+    "name": "option-map-bool-semantics",
+    "description": "Tests understanding of Option.Map's (T, bool) return type",
+    "prompt": "I have an mo.Option[int] in Go and I want to keep the value only if it's greater than 10, otherwise turn it into None. How do I do this with Map?",
+    "trap": "Without the skill, the model doesn't realize Option.Map returns (T, bool) where the bool controls Some/None, acting as both map and filter.",
+    "assertions": [
+      {"id": "14.1", "text": "Uses opt.Map(func(v int) (int, bool) { return v, v > 10 })"},
+      {"id": "14.2", "text": "Explains that returning false from Map's callback converts to None"},
+      {"id": "14.3", "text": "Shows the (T, bool) return signature of Map's callback"},
+      {"id": "14.4", "text": "Does NOT use FlatMap with an if/else to accomplish filtering"}
+    ]
+  },
+  {
+    "id": 15,
+    "name": "fold-for-uniform-value-extraction",
+    "description": "Tests knowledge of mo.Fold for extracting a value from Option, Result, or Either with two-callback pattern",
+    "prompt": "I have an mo.Result[int] in Go. I want to convert it to a display string: if it's Ok, show the number formatted as 'value: N'; if it's Err, show 'error: <message>'. I'm currently using IsOk/IsError with an if/else. Is there a more declarative way with samber/mo?",
+    "trap": "Without the skill, the model uses if/else with IsOk/IsError and manual extraction. mo.Fold accepts two callbacks — success and failure — and dispatches uniformly. The model often misses Fold entirely or confuses it with Match (which returns the same type as its receiver, requiring type-changing sub-package use).",
+    "assertions": [
+      {"id": "15.1", "text": "Uses mo.Fold to replace the if/else dispatch"},
+      {"id": "15.2", "text": "Passes a success callback (func(int) string) as the first function argument"},
+      {"id": "15.3", "text": "Passes a failure callback (func(error) string) as the second function argument"},
+      {"id": "15.4", "text": "The output type (string) differs from the input type (int) — Fold is used for type-changing extraction"},
+      {"id": "15.5", "text": "Does NOT use IsOk/IsError with separate MustGet/Error calls as the primary approach"}
+    ]
+  },
+  {
+    "id": 16,
+    "name": "io-for-testable-side-effects",
+    "description": "Tests knowledge of IO for deferring and testing side effects",
+    "prompt": "I have a Go function that reads from stdin, formats the input, and writes to stdout. I want to make this testable by separating the side effects from the logic. How can samber/mo help?",
+    "trap": "Without the skill, the model uses interfaces or dependency injection for io.Reader/io.Writer. IO[T] provides a functional approach to defer side effects.",
+    "assertions": [
+      {"id": "16.1", "text": "Uses mo.IO or mo.IOEither to wrap the side-effecting operations"},
+      {"id": "16.2", "text": "Explains that IO is lazy — the side effect only runs when Run() is called"},
+      {"id": "16.3", "text": "Shows that IO1 or IO2 can parameterize the side effect for testing"},
+      {"id": "16.4", "text": "Demonstrates composability of IO operations"}
+    ]
+  },
+  {
+    "id": 17,
+    "name": "result-to-either-conversion",
+    "description": "Tests knowledge of Result.ToEither() conversion",
+    "prompt": "I have a mo.Result[User] in Go and I need to pass it to a function that expects mo.Either[error, User]. How do I convert?",
+    "trap": "Without the skill, the model manually matches on IsOk/IsError and constructs Left/Right. ToEither() does this directly.",
+    "assertions": [
+      {"id": "17.1", "text": "Uses result.ToEither() for direct conversion"},
+      {"id": "17.2", "text": "Explains that Ok becomes Right, Err becomes Left"},
+      {"id": "17.3", "text": "Does NOT manually check IsOk/IsError and construct Either"}
+    ]
+  },
+  {
+    "id": 18,
+    "name": "either3-for-multi-type-union",
+    "description": "Tests knowledge of Either3+ for n-ary type unions",
+    "prompt": "My Go API can return three different response types depending on the request: a UserResponse, an AdminResponse, or a SystemResponse. I want type-safe handling. What should I use?",
+    "trap": "Without the skill, the model uses interface{}/any or defines a common interface. Either3 provides a type-safe discriminated union.",
+    "assertions": [
+      {"id": "18.1", "text": "Uses mo.Either3[UserResponse, AdminResponse, SystemResponse]"},
+      {"id": "18.2", "text": "Shows NewEither3Arg1, NewEither3Arg2, NewEither3Arg3 constructors"},
+      {"id": "18.3", "text": "Shows Match with handlers for all three types"},
+      {"id": "18.4", "text": "Does NOT use interface{}/any which loses type safety"},
+      {"id": "18.5", "text": "Mentions Either4/Either5 for 4-5 type variants"}
+    ]
+  },
+  {
+    "id": 19,
+    "name": "option-vs-zero-value-distinction",
+    "description": "Tests understanding of when Option adds value vs when zero values suffice",
+    "prompt": "In my Go struct, I have a 'count' field (int) and a 'nickname' field (string). For 'count', zero is a valid value meaning 'no items'. For 'nickname', empty string means 'not set'. Should I use Option for both?",
+    "trap": "Without the skill, the model either uses Option for both or neither. Option should be used only for 'nickname' where absence is semantically different from empty.",
+    "assertions": [
+      {"id": "19.1", "text": "Recommends plain int for count (zero is a valid meaningful value)"},
+      {"id": "19.2", "text": "Recommends mo.Option[string] for nickname (absence differs from empty)"},
+      {"id": "19.3", "text": "Explains that Option is for when absence is semantically different from the zero value"},
+      {"id": "19.4", "text": "Does NOT recommend Option[int] for count where 0 is meaningful"}
+    ]
+  },
+  {
+    "id": 20,
+    "name": "map-lookup-to-option",
+    "description": "Tests converting Go map lookups to Option using TupleToOption",
+    "prompt": "I have a Go map[string]User and I want to look up a key and chain transformations on the result if present. How do I bridge the map lookup with samber/mo?",
+    "trap": "Without the skill, the model manually checks the ok bool from map access. TupleToOption wraps the (value, bool) tuple directly.",
+    "assertions": [
+      {"id": "20.1", "text": "Uses mo.TupleToOption with the map lookup: mo.TupleToOption(m[key])"},
+      {"id": "20.2", "text": "Chains Map/FlatMap on the resulting Option"},
+      {"id": "20.3", "text": "Does NOT manually check ok bool and construct Some/None"},
+      {"id": "20.4", "text": "Shows the complete pattern: TupleToOption(m[key]).Map(...)"}
+    ]
+  },
+  {
+    "id": 21,
+    "name": "result-try-catch-panics",
+    "description": "Tests knowledge of mo.Try for wrapping a function that may return an error OR panic, and chaining the result",
+    "prompt": "I'm integrating a third-party Go JSON schema validator that has two failure modes: it returns an error for invalid input, and it panics on malformed schemas. I want to call it, capture both failure modes, and then chain a transformation if validation succeeds — all without writing defer/recover boilerplate. I'm already using samber/mo in my project. Show the code.",
+    "trap": "Without the skill, the model writes a defer/recover wrapper function manually, then handles the error. With the skill, mo.Try captures both (T, error) returns and panics into a Result[T] in one call, enabling direct chaining with Map/FlatMap. The model often misses mo.Try entirely (using a hand-rolled wrapper) or uses it but forgets it also catches panics (thinking it only handles errors).",
+    "assertions": [
+      {"id": "21.1", "text": "Uses mo.Try (not a manual defer/recover) to call the validator"},
+      {"id": "21.2", "text": "Explicitly states that mo.Try catches panics AND returned errors, converting both to Err"},
+      {"id": "21.3", "text": "Shows chaining Map or FlatMap on the Try result for the transformation step"},
+      {"id": "21.4", "text": "The mo.Try callback matches the (T, error) return signature of the wrapped function"}
+    ]
+  },
+  {
+    "id": 22,
+    "name": "state-monad-for-accumulation",
+    "description": "Tests knowledge of State monad for threading state",
+    "prompt": "I'm writing a Go parser that needs to track position as it consumes tokens from an input string. Each parsing step reads from the current position and advances it. How can I model this with samber/mo?",
+    "trap": "Without the skill, the model uses a mutable struct. State[S,A] threads state through pure computations.",
+    "assertions": [
+      {"id": "22.1", "text": "Uses mo.State or mo.NewState to model the stateful computation"},
+      {"id": "22.2", "text": "State type parameters represent the state (position/input) and result (parsed token)"},
+      {"id": "22.3", "text": "Shows Run(initialState) to execute and get (result, newState)"},
+      {"id": "22.4", "text": "The state is threaded through rather than mutated in place"}
+    ]
+  },
+  {
+    "id": 23,
+    "name": "result-map-signature-understanding",
+    "description": "Tests understanding that Result.Map callback returns (T, error) not just T",
+    "prompt": "I want to double an integer inside a mo.Result[int] in Go. Write the Map call.",
+    "trap": "Without the skill, the model writes .Map(func(v int) int { return v * 2 }) which won't compile. Result.Map requires (T, error) return.",
+    "assertions": [
+      {"id": "23.1", "text": "Map callback returns (int, error), e.g., func(v int) (int, error) { return v * 2, nil }"},
+      {"id": "23.2", "text": "Does NOT write func(v int) int which misses the error return"},
+      {"id": "23.3", "text": "Alternatively uses MapValue(func(v int) int { return v * 2 }) for infallible transforms"},
+      {"id": "23.4", "text": "Shows awareness that Map and MapValue have different callback signatures"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/advanced-types.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/advanced-types.md
new file mode 100644
index 00000000..c740dfa0
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/advanced-types.md
@@ -0,0 +1,258 @@
+# Advanced Types Reference
+
+These types are less commonly used than Option/Result/Either but provide powerful abstractions for specific scenarios.
+
+## Type Hierarchy
+
+```
+Synchronous                    Asynchronous
+-----------                    ------------
+IO[T]     (no error)    →     Task[T]     (no error)    → Future[T]
+IOEither[T] (with error) →     TaskEither[T] (with error) → Future[T]
+```
+
+- **IO** wraps a synchronous side-effecting computation
+- **Task** wraps an asynchronous side-effecting computation (returns a Future)
+- **Future** represents a value that will be available later
+- **Either** variants add error handling capability
+
+## Future[T] — Asynchronous Values
+
+Represents a value that may not yet be available. Similar to JavaScript's Promise.
+
+### Constructor
+
+```go
+future := mo.NewFuture(func(resolve func(int), reject func(error)) {
+    // runs asynchronously
+    result, err := expensiveComputation()
+    if err != nil {
+        reject(err)
+    } else {
+        resolve(result)
+    }
+})
+```
+
+### Chaining
+
+```go
+future.
+    Then(func(v int) (int, error) {
+        return v * 2, nil  // transform on success
+    }).
+    Catch(func(err error) (int, error) {
+        return 0, err  // handle error
+    }).
+    Finally(func(v int, err error) (int, error) {
+        // always runs, regardless of success/failure
+        log.Println("Done")
+        return v, err
+    })
+```
+
+### Collecting Results
+
+```go
+value, err := future.Collect()    // blocks until resolved
+result := future.Result()          // blocks, returns Result[T]
+either := future.Either()          // blocks, returns Either[error, T]
+```
+
+### Cancellation
+
+```go
+future.Cancel()  // terminates the future chain
+```
+
+## IO[T] — Synchronous Side Effects
+
+Wraps a function that performs side effects. The computation is lazy — it only runs when `Run()` is called. IO never fails.
+
+### Variants by Parameter Count
+
+```go
+// No parameters
+io := mo.NewIO(func() string { return "hello" })
+result := io.Run()  // "hello"
+
+// 1 parameter
+io1 := mo.NewIO1(func(name string) string { return "hello " + name })
+result := io1.Run("Alice")  // "hello Alice"
+
+// 2-5 parameters (IO2, IO3, IO4, IO5)
+io2 := mo.NewIO2(func(a, b int) int { return a + b })
+result := io2.Run(1, 2)  // 3
+```
+
+## IOEither[T] — Synchronous Side Effects with Errors
+
+Like IO but the computation can fail. The callback must return `Either[error, R]`, not `(R, error)`.
+
+```go
+io := mo.NewIOEither(func() mo.Either[error, string] {
+    data, err := os.ReadFile("config.yaml")
+    if err != nil {
+        return mo.Left[error, string](err)
+    }
+    return mo.Right[error, string](string(data))
+})
+
+either := io.Run()  // Either[error, string]
+```
+
+### Variants by Parameter Count
+
+```go
+// 1 parameter
+io1 := mo.NewIOEither1(func(path string) mo.Either[error, string] {
+    data, err := os.ReadFile(path)
+    if err != nil {
+        return mo.Left[error, string](err)
+    }
+    return mo.Right[error, string](string(data))
+})
+either := io1.Run("config.yaml")  // Either[error, string]
+
+// IOEither2 through IOEither5 follow the same pattern
+```
+
+## Task[T] — Asynchronous Computations
+
+Lazy async computation — `Run()` calls the wrapped function, which returns a `*Future[T]`. Never fails.
+
+```go
+task := mo.NewTask(func() *mo.Future[int] {
+    return mo.NewFuture(func(resolve func(int), reject func(error)) {
+        time.Sleep(time.Second)
+        resolve(42)
+    })
+})
+
+future := task.Run()           // executes the function, returns *Future[int]
+value, err := future.Collect() // blocks until done
+```
+
+Note: `NewTask` accepts `func() *Future[R]` — it wraps a Future-producing function for lazy execution.
+
+### From IO
+
+```go
+io := mo.NewIO(func() int { return 42 })
+task := mo.NewTaskFromIO(io)  // wrap IO as async Task
+```
+
+### Variants by Parameter Count
+
+```go
+task1 := mo.NewTask1(func(n int) *mo.Future[int] {
+    return mo.NewFuture(func(resolve func(int), reject func(error)) {
+        resolve(n * 2)
+    })
+})
+future := task1.Run(21)  // *Future[int] resolving to 42
+```
+
+## TaskEither[T] — Async Computations with Errors
+
+Like Task but the computation can fail. Combines Task semantics with error handling.
+
+```go
+te := mo.NewTaskEither(func() *mo.Future[string] {
+    return mo.NewFuture(func(resolve func(string), reject func(error)) {
+        resp, err := http.Get("https://api.example.com/data")
+        if err != nil {
+            reject(err)
+            return
+        }
+        defer resp.Body.Close()
+        body, err := io.ReadAll(resp.Body)
+        if err != nil {
+            reject(err)
+            return
+        }
+        resolve(string(body))
+    })
+})
+```
+
+Note: Like `NewTask`, `NewTaskEither` accepts `func() *Future[R]`. The difference is in the methods available on the returned type — TaskEither provides `Match`, `OrElse`, `ToEither`, and `ToTask`.
+
+### Methods
+
+```go
+te.OrElse("fallback")                    // blocks, returns value or fallback
+te.ToEither()                            // blocks, returns Either[error, T]
+te.ToTask("fallback")                    // converts to Task (uses fallback on error)
+te.Match(
+    func(err error) mo.Either[error, string] { ... },  // on error
+    func(v string) mo.Either[error, string] { ... },    // on success
+)
+```
+
+## State[S, A] — Stateful Computations
+
+Represents a computation that threads state through a series of operations. The state type S flows through the computation while producing result values of type A.
+
+### Constructor
+
+```go
+// State computation: takes state, returns (result, newState)
+counter := mo.NewState(func(count int) (string, int) {
+    return fmt.Sprintf("count=%d", count), count + 1
+})
+
+result, newState := counter.Run(0)  // ("count=0", 1)
+```
+
+### ReturnState — wrap a value without modifying state
+
+```go
+state := mo.ReturnState[int, string]("hello")
+result, s := state.Run(42)  // ("hello", 42) — state unchanged
+```
+
+### State Manipulation
+
+```go
+// Get — return current state as result
+getter := mo.NewState(func(s int) (int, int) { return s, s })
+
+// Put — replace state
+putter := state.Put(100)
+_, s := putter.Run(0)  // (_, 100)
+
+// Modify — transform state
+modified := state.Modify(func(s int) int { return s * 2 })
+_, s := modified.Run(5)  // (_, 10)
+```
+
+### Chaining State Computations
+
+State is useful for accumulating results while threading context:
+
+```go
+// Parse tokens while tracking position
+type ParseState struct {
+    Input    string
+    Position int
+}
+
+parseChar := mo.NewState(func(s ParseState) (byte, ParseState) {
+    ch := s.Input[s.Position]
+    return ch, ParseState{Input: s.Input, Position: s.Position + 1}
+})
+```
+
+## When to Use Advanced Types
+
+| Type       | Use when...                                                   |
+| ---------- | ------------------------------------------------------------- |
+| Future     | You need async computation with chaining (Then/Catch/Finally) |
+| IO         | You want to defer and compose synchronous side effects        |
+| IOEither   | Deferred side effects that can fail                           |
+| Task       | Deferred async computation (lazy Future)                      |
+| TaskEither | Deferred async computation that can fail                      |
+| State      | Threading state through a series of pure computations         |
+
+Most Go projects only need **Option**, **Result**, and **Either**. The advanced types are valuable when building functional pipelines or when you want explicit control over when side effects execute.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/either.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/either.md
new file mode 100644
index 00000000..03f165ad
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/either.md
@@ -0,0 +1,151 @@
+# Either[L, R] API Reference
+
+A discriminated union representing a value of one of two possible types. By convention, Left is the "alternative" path and Right is the "primary" path, but neither implies success or failure.
+
+## Constructors
+
+| Function                  | Description                 |
+| ------------------------- | --------------------------- |
+| `mo.Left[L, R](value L)`  | Creates a left-side Either  |
+| `mo.Right[L, R](value R)` | Creates a right-side Either |
+
+## Type Checking
+
+| Method      | Returns | Description                            |
+| ----------- | ------- | -------------------------------------- |
+| `IsLeft()`  | `bool`  | True if the value is on the left side  |
+| `IsRight()` | `bool`  | True if the value is on the right side |
+
+## Value Extraction
+
+| Method | Returns | Description |
+| --- | --- | --- |
+| `Left()` | `(L, bool)` | Left value and whether it exists |
+| `Right()` | `(R, bool)` | Right value and whether it exists |
+| `MustLeft()` | `L` | Left value or panics |
+| `MustRight()` | `R` | Right value or panics |
+| `LeftOrElse(fallback L)` | `L` | Left value or fallback |
+| `RightOrElse(fallback R)` | `R` | Right value or fallback |
+| `LeftOrEmpty()` | `L` | Left value or zero value |
+| `RightOrEmpty()` | `R` | Right value or zero value |
+| `Unpack()` | `(L, R)` | Both values (one will be zero value) |
+
+## Transformations
+
+### Swap — exchange left and right
+
+```go
+e := mo.Left[string, int]("hello")
+swapped := e.Swap()  // Either[int, string] — Right("hello")
+```
+
+### MapLeft / MapRight — transform one side
+
+The callback receives the value and must return a new `Either[L, R]`:
+
+```go
+e := mo.Left[string, int]("hello")
+upper := e.MapLeft(func(s string) mo.Either[string, int] {
+    return mo.Left[string, int](strings.ToUpper(s))
+})
+// Left("HELLO")
+
+e2 := mo.Right[string, int](42)
+doubled := e2.MapRight(func(v int) mo.Either[string, int] {
+    return mo.Right[string, int](v * 2)
+})
+// Right(84)
+```
+
+**Go limitation:** Like Option.Map and Result.Map, direct Either methods cannot change the type parameters. Use sub-package `either.MapLeft`/`either.MapRight` for type-changing transforms — see [Pipelines Reference](./pipelines.md).
+
+### Match — pattern matching
+
+```go
+e.Match(
+    func(left string) mo.Either[string, int] {
+        fmt.Println("Left:", left)
+        return mo.Left[string, int](left)
+    },
+    func(right int) mo.Either[string, int] {
+        fmt.Println("Right:", right)
+        return mo.Right[string, int](right)
+    },
+)
+```
+
+### ForEach — side effects
+
+```go
+e.ForEach(
+    func(left string) { fmt.Println("Left:", left) },
+    func(right int) { fmt.Println("Right:", right) },
+)
+```
+
+## Either vs Result
+
+| Feature       | Either[L, R]            | Result[T]               |
+| ------------- | ----------------------- | ----------------------- |
+| Left/Err type | Any type L              | Always `error`          |
+| Semantics     | Two valid alternatives  | Success or failure      |
+| Use case      | Cached vs fresh, A vs B | Operation that may fail |
+| JSON          | Not supported           | JSON-RPC format         |
+
+`Result[T]` is equivalent to `Either[error, T]` — use `result.ToEither()` to convert.
+
+## Either3[T1, T2, T3] — Three-Type Union
+
+### Constructors
+
+```go
+e := mo.NewEither3Arg1[string, int, bool]("hello")  // T1 variant
+e := mo.NewEither3Arg2[string, int, bool](42)         // T2 variant
+e := mo.NewEither3Arg3[string, int, bool](true)       // T3 variant
+```
+
+### Type Checking and Extraction
+
+```go
+e.IsArg1()  // true if T1
+e.IsArg2()  // true if T2
+e.IsArg3()  // true if T3
+
+val, ok := e.Arg1()      // (T1, bool)
+val := e.MustArg1()      // T1 or panics
+val := e.Arg1OrElse(fb)  // T1 or fallback
+val := e.Arg1OrEmpty()   // T1 or zero value
+t1, t2, t3 := e.Unpack() // all three (two will be zero)
+```
+
+### Pattern Matching
+
+```go
+e.Match(
+    func(s string) mo.Either3[string, int, bool] { ... },
+    func(i int) mo.Either3[string, int, bool] { ... },
+    func(b bool) mo.Either3[string, int, bool] { ... },
+)
+```
+
+### Transformations
+
+MapArg callbacks receive the value and return a new Either3:
+
+```go
+e.MapArg1(func(s string) mo.Either3[string, int, bool] {
+    return mo.NewEither3Arg1[string, int, bool](strings.ToUpper(s))
+})
+e.MapArg2(func(i int) mo.Either3[string, int, bool] {
+    return mo.NewEither3Arg2[string, int, bool](i * 2)
+})
+```
+
+## Either4 and Either5
+
+Follow the exact same pattern as Either3 with 4 and 5 type parameters respectively:
+
+- **Either4[T1, T2, T3, T4]**: `NewEither4Arg1` through `NewEither4Arg4`, `IsArg1`-`IsArg4`, `MapArg1`-`MapArg4`
+- **Either5[T1, T2, T3, T4, T5]**: `NewEither5Arg1` through `NewEither5Arg5`, `IsArg1`-`IsArg5`, `MapArg1`-`MapArg5`
+
+Use Either3+ when you need a type-safe union of multiple types — for example, an API that returns different response shapes depending on the request type.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/monads-guide.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/monads-guide.md
new file mode 100644
index 00000000..df479dcd
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/monads-guide.md
@@ -0,0 +1,163 @@
+# Functional Programming and Monads in Go
+
+## What is Functional Programming?
+
+Functional programming (FP) treats computation as evaluation of mathematical functions. Core principles:
+
+- **Immutability** — data doesn't change after creation; transformations produce new values
+- **Pure functions** — same input always produces same output, no side effects
+- **Composition** — build complex behavior by chaining simple functions
+- **Types as documentation** — types express constraints and invariants
+
+Go isn't a pure FP language, but Go 1.18+ generics make FP patterns practical. samber/mo brings the most battle-tested FP abstractions — monads — to Go.
+
+## What is a Monad?
+
+A monad is a design pattern (not a class or interface) that:
+
+1. **Wraps a value** in a context (Option wraps "maybe absent", Result wraps "maybe failed")
+2. **Chains operations** that transform the wrapped value without unwrapping it
+3. **Handles the context automatically** — if an Option is None, Map/FlatMap skip the transformation; if a Result is Err, subsequent Maps short-circuit
+
+Think of it as a **container with a policy**: "I hold a value, and I know what to do when operations succeed or fail."
+
+### The Railway Metaphor
+
+Imagine two parallel railway tracks:
+
+- **Happy track** (top): data flows through transformations successfully
+- **Error track** (bottom): once something goes wrong, the train switches to the error track and skips remaining transformations
+
+```
+Input → [Transform A] → [Transform B] → [Transform C] → Output
+          ↓ (error)       (skipped)       (skipped)
+       Error track ────────────────────────────────────→ Error
+```
+
+This is exactly how Result.Map and Result.FlatMap work — errors propagate automatically without explicit if/else checks.
+
+## Why Monads Are Valuable in Go
+
+### 1. Compile-Time Nil Safety (Option)
+
+Go's type system doesn't distinguish "this pointer could be nil" from "this pointer is always valid". Option[T] makes this explicit:
+
+```go
+// Without mo — caller must remember to check nil
+func FindUser(id string) *User { ... }  // might return nil
+
+// With mo — the type TELLS you it might be absent
+func FindUser(id string) mo.Option[User] { ... }  // caller must handle None
+```
+
+The type signature is the documentation. No nil pointer panics at runtime — the compiler forces you to handle absence.
+
+### 2. Railway-Oriented Error Handling (Result)
+
+Go's idiomatic error handling requires checking errors at every step:
+
+```go
+// Without mo — repetitive error checking
+data, err := readFile(path)
+if err != nil { return err }
+config, err := parseConfig(data)
+if err != nil { return err }
+validated, err := validate(config)
+if err != nil { return err }
+```
+
+With Result and `mo.Do`, errors short-circuit through the chain:
+
+```go
+// With mo — errors propagate automatically via Do notation
+result := mo.Do(func() Config {
+    data := mo.TupleToResult(readFile(path)).MustGet()
+    config := mo.TupleToResult(parseConfig(data)).MustGet()
+    validated := mo.TupleToResult(validate(config)).MustGet()
+    return validated
+})
+```
+
+Same logic, less boilerplate. The error path is handled by the monad — any `MustGet()` failure short-circuits to `Err`.
+
+**Note:** Direct `.Map`/`.FlatMap` methods cannot change the type parameter (Go methods cannot introduce new generic types). For type-changing pipelines, use sub-package `result.Pipe` functions or `mo.Do` notation as shown above.
+
+### 3. Composable Pipelines
+
+Monads compose naturally. You can build complex data transformations from simple, testable pieces:
+
+```go
+import "github.com/samber/mo/option"
+
+result := option.Pipe3(
+    getUserOption(id),
+    option.Map(func(u User) string { return u.Email }),
+    option.FlatMap(func(email string) mo.Option[string] {
+        if isValid(email) { return mo.Some(email) }
+        return mo.None[string]()
+    }),
+    option.Map(func(email string) EmailAddress { return NewEmailAddress(email) }),
+)
+```
+
+Each step is a pure function. The pipeline handles None propagation. Each step is independently testable.
+
+## The Three Core Monads
+
+### Option — Represents Absence
+
+**Problem it solves:** nil pointer panics, ambiguous zero values.
+
+| Concept       | Go without mo         | Go with mo                |
+| ------------- | --------------------- | ------------------------- |
+| Value present | `*User` (non-nil)     | `mo.Some(user)`           |
+| Value absent  | `*User` (nil)         | `mo.None[User]()`         |
+| Safe access   | `if u != nil { ... }` | `opt.OrElse(defaultUser)` |
+| Transform     | manual nil check      | `opt.Map(transform)`      |
+
+Use Option when: a value might legitimately be absent (nullable DB columns, optional config, cache lookups).
+
+Don't use Option when: a zero value is meaningful (empty string is valid, 0 is a valid count).
+
+### Result — Represents Fallibility
+
+**Problem it solves:** verbose error checking, lost error context in chains.
+
+| Concept   | Go without mo                | Go with mo                    |
+| --------- | ---------------------------- | ----------------------------- |
+| Success   | `return value, nil`          | `mo.Ok(value)`                |
+| Failure   | `return zero, err`           | `mo.Err[T](err)`              |
+| Chain ops | `if err != nil` at each step | `.Map(...)` / `.FlatMap(...)` |
+| Default   | manual fallback              | `.OrElse(default)`            |
+
+Use Result when: you're chaining multiple fallible operations and want errors to propagate automatically.
+
+Don't use Result when: you need to inspect or modify the error at each step (standard Go error handling is more explicit).
+
+### Either — Represents Alternatives
+
+**Problem it solves:** functions that legitimately return one of two types.
+
+| Concept                | Example                           |
+| ---------------------- | --------------------------------- |
+| Cached vs fresh data   | `Either[CachedUser, FreshUser]`   |
+| Sync vs async result   | `Either[SyncResult, AsyncResult]` |
+| Left vs right strategy | `Either[StrategyA, StrategyB]`    |
+
+Use Either when: both outcomes are valid, neither is an "error". If one side is always an error, use Result instead.
+
+## When to Use mo vs Plain Go
+
+**Use mo when:**
+
+- You're building data transformation pipelines with multiple steps
+- You need type-safe nullable values (especially in JSON/DB models)
+- Error handling chains become repetitive
+- You want to make impossible states unrepresentable in the type system
+
+**Stick with plain Go when:**
+
+- Simple one-step operations where `if err != nil` is clear enough
+- Performance-critical hot paths (monads add thin allocation overhead)
+- Your team isn't familiar with FP concepts (readability > cleverness)
+- The operation has complex error recovery at each step (explicit handling is clearer)
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/option.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/option.md
new file mode 100644
index 00000000..5b8b5980
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/option.md
@@ -0,0 +1,151 @@
+# Option[T] API Reference
+
+## Constructors
+
+| Function | Description |
+| --- | --- |
+| `mo.Some[T](value T)` | Creates Option with a present value |
+| `mo.None[T]()` | Creates Option with an absent value |
+| `mo.TupleToOption[T](value T, ok bool)` | Converts (value, bool) tuple — Some if ok is true, None otherwise |
+| `mo.EmptyableToOption[T](value T)` | None if value equals its zero value, Some otherwise |
+| `mo.PointerToOption[T](value *T)` | None if pointer is nil, Some(\*value) otherwise |
+
+## Query Methods
+
+| Method | Returns | Description |
+| --- | --- | --- |
+| `IsPresent()` / `IsSome()` | `bool` | True if value exists |
+| `IsAbsent()` / `IsNone()` | `bool` | True if value is missing |
+| `Size()` | `int` | 1 if present, 0 if absent |
+| `Get()` | `(T, bool)` | Value and presence indicator |
+| `MustGet()` | `T` | Value or panics — use only inside `mo.Do` |
+
+## Value Extraction
+
+| Method               | Returns | Description                            |
+| -------------------- | ------- | -------------------------------------- |
+| `OrElse(fallback T)` | `T`     | Value if present, fallback otherwise   |
+| `OrEmpty()`          | `T`     | Value if present, zero value otherwise |
+| `ToPointer()`        | `*T`    | Pointer to value, nil if absent        |
+
+## Transformations
+
+### Map — transform the value if present
+
+```go
+opt := mo.Some(42)
+doubled := opt.Map(func(v int) (int, bool) {
+    return v * 2, true  // (new value, keep as Some)
+})
+// Some(84)
+
+// Return false to convert to None
+filtered := opt.Map(func(v int) (int, bool) {
+    return v, v > 100  // None because 42 <= 100
+})
+```
+
+**Go limitation:** Option.Map takes `func(T) (T, bool)` — the input and output types must be the same `T`. The bool controls whether the result is Some or None. To change the type (e.g. `Option[int]` to `Option[string]`), use sub-package `option.Map` — see [Pipelines Reference](./pipelines.md).
+
+### MapValue — transform without filter
+
+```go
+opt := mo.Some(42)
+doubled := opt.MapValue(func(v int) int { return v * 2 })
+// Some(84) — always stays Some if input was Some, no bool needed
+```
+
+Unlike Map, MapValue's callback returns just `T` (not `(T, bool)`), so it cannot convert to None.
+
+### MapNone — provide value when absent
+
+```go
+opt := mo.None[int]()
+filled := opt.MapNone(func() (int, bool) {
+    return 42, true  // provide default as Some
+})
+// Some(42)
+```
+
+### FlatMap — chain Options (same type)
+
+```go
+func findUser(id string) mo.Option[User] { ... }
+func refreshUser(u User) mo.Option[User] { ... }
+
+refreshed := findUser("123").FlatMap(func(u User) mo.Option[User] {
+    return refreshUser(u)  // same type: Option[User] -> Option[User]
+})
+```
+
+**Go limitation:** Direct `.FlatMap` requires `func(T) Option[T]` — same input and output type. For type-changing chains (e.g. `Option[User]` to `Option[string]`), use `option.FlatMap` from the sub-package or `mo.Do` notation.
+
+### Match — handle both cases
+
+```go
+opt.Match(
+    func(v int) (int, bool) {
+        fmt.Println("Got:", v)
+        return v, true       // keep as Some
+    },
+    func() (int, bool) {
+        fmt.Println("Empty!")
+        return 0, false       // stay as None
+    },
+)
+```
+
+### ForEach — side effect on present value
+
+```go
+opt.ForEach(func(v int) {
+    fmt.Println("Value:", v)  // only executes if present
+})
+```
+
+## Equality
+
+```go
+mo.Some(42).Equal(mo.Some(42))  // true
+mo.Some(42).Equal(mo.None[int]())  // false
+mo.None[int]().Equal(mo.None[int]())  // true
+```
+
+## Serialization
+
+Option implements multiple encoding interfaces:
+
+| Interface | Behavior |
+| --- | --- |
+| `json.Marshaler` / `json.Unmarshaler` | Some(42) -> `42`, None -> `null` |
+| `encoding.TextMarshaler` / `TextUnmarshaler` | Text encoding/decoding |
+| `encoding.BinaryMarshaler` / `BinaryUnmarshaler` | Binary encoding/decoding |
+| `encoding/gob.GobEncoder` / `GobDecoder` | Gob encoding/decoding |
+
+## Database Support
+
+Option implements `sql.Scanner` and `driver.Valuer`:
+
+```go
+type User struct {
+    ID    int
+    Phone mo.Option[string]  // nullable column
+}
+
+// Scanning
+err := row.Scan(&u.ID, &u.Phone)
+
+// Inserting
+_, err := db.Exec("INSERT INTO users (id, phone) VALUES ($1, $2)", u.ID, u.Phone)
+```
+
+## Go 1.24+ omitzero Support
+
+```go
+type Response struct {
+    Data    string            `json:"data"`
+    Extra   mo.Option[string] `json:"extra,omitzero"`  // omitted when None
+}
+```
+
+`IsZero()` returns true when the Option is None, enabling the `omitzero` JSON tag.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/pipelines.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/pipelines.md
new file mode 100644
index 00000000..726e3264
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/pipelines.md
@@ -0,0 +1,147 @@
+# Pipeline Sub-Packages Reference
+
+samber/mo provides sub-packages (`option`, `result`, `either`, `either3`, `either4`, `either5`) with standalone functions for type-changing transformations and composable pipelines.
+
+## Why Sub-Packages Exist
+
+Direct methods on Option/Result/Either (`.Map`, `.FlatMap`) cannot change the type parameter because Go methods cannot introduce new type parameters. For example:
+
+```go
+opt := mo.Some(42)
+// opt.Map can return Option[int], but NOT Option[string]
+// because Map's signature is: func (o Option[T]) Map(func(T) (T, bool)) Option[T]
+```
+
+Sub-package functions solve this by being standalone generic functions:
+
+```go
+import "github.com/samber/mo/option"
+
+// option.Map CAN change the type: Option[int] -> Option[string]
+strOpt := option.Map(func(v int) string {
+    return strconv.Itoa(v)
+})(mo.Some(42))
+// Some("42")
+```
+
+## option/ Package
+
+### Transformation Functions
+
+| Function | Signature | Description |
+| --- | --- | --- |
+| `option.Map` | `func(I) O -> func(Option[I]) Option[O]` | Transform value, changing type |
+| `option.FlatMap` | `func(I) Option[O] -> func(Option[I]) Option[O]` | Chain with type change |
+| `option.Match` | `(onValue, onNone) -> func(Option[I]) Option[O]` | Branch with type change |
+| `option.FlatMatch` | `(onValue, onNone) -> func(Option[I]) Option[O]` | Branch returning Options |
+
+### Pipe Functions
+
+Chain multiple transformations in a readable pipeline:
+
+```go
+import "github.com/samber/mo/option"
+
+result := option.Pipe3(
+    mo.Some(42),                                                          // Option[int]
+    option.Map(func(v int) string { return strconv.Itoa(v) }),            // -> Option[string]
+    option.Map(func(s string) []byte { return []byte(s) }),               // -> Option[[]byte]
+    option.FlatMap(func(b []byte) mo.Option[string] {                     // -> Option[string]
+        if len(b) > 0 { return mo.Some(string(b)) }
+        return mo.None[string]()
+    }),
+)
+```
+
+Available: `option.Pipe1` through `option.Pipe10` (1 to 10 transformation steps).
+
+## result/ Package
+
+### Transformation Functions
+
+| Function | Signature | Description |
+| --- | --- | --- |
+| `result.Map` | `func(I) O -> func(Result[I]) Result[O]` | Transform success value, changing type |
+| `result.FlatMap` | `func(I) Result[O] -> func(Result[I]) Result[O]` | Chain with type change |
+| `result.Match` | `(onValue, onError) -> func(Result[I]) Result[O]` | Branch with type change |
+| `result.FlatMatch` | `(onValue, onError) -> func(Result[I]) Result[O]` | Branch returning Results |
+
+### Pipe Functions
+
+```go
+import "github.com/samber/mo/result"
+
+parsed := result.Pipe2(
+    mo.TupleToResult(os.ReadFile("config.yaml")),                         // Result[[]byte]
+    result.Map(func(data []byte) Config {                                 // -> Result[Config]
+        var cfg Config
+        yaml.Unmarshal(data, &cfg)
+        return cfg
+    }),
+    result.FlatMap(func(cfg Config) mo.Result[ValidConfig] {              // -> Result[ValidConfig]
+        return validateConfig(cfg)
+    }),
+)
+```
+
+Available: `result.Pipe1` through `result.Pipe10`.
+
+## either/ Package
+
+### Transformation Functions
+
+| Function | Signature | Description |
+| --- | --- | --- |
+| `either.MapLeft` | `func(Lin) Lout -> func(Either[Lin, R]) Either[Lout, R]` | Transform left side type |
+| `either.MapRight` | `func(Rin) Rout -> func(Either[L, Rin]) Either[L, Rout]` | Transform right side type |
+| `either.FlatMapLeft` | `func(Lin) Either[Lout, R] -> func(Either[Lin, R]) Either[Lout, R]` | Chain left with type change |
+| `either.FlatMapRight` | `func(Rin) Either[L, Rout] -> func(Either[L, Rin]) Either[L, Rout]` | Chain right with type change |
+| `either.Match` | `(onLeft, onRight) -> func(Either[Lin, Rin]) Either[Lout, Rout]` | Branch both sides |
+| `either.Swap` | `func(Either[I, O]) Either[O, I]` | Exchange left and right |
+
+### Pipe Functions
+
+```go
+import "github.com/samber/mo/either"
+
+result := either.Pipe2(
+    mo.Right[error, int](42),
+    either.MapRight(func(v int) string { return strconv.Itoa(v) }),
+    either.MapRight(func(s string) []byte { return []byte(s) }),
+)
+```
+
+Available: `either.Pipe1` through `either.Pipe10`.
+
+## either3/, either4/, either5/ Packages
+
+Each provides:
+
+- `Match` with handlers for each argument type
+- `MapArg1`, `MapArg2`, `MapArg3` (up to `MapArg5` for either5)
+- `Pipe1` through `Pipe10`
+
+## When to Use Pipes vs Direct Methods
+
+| Scenario | Use | Why |
+| --- | --- | --- |
+| Same type in, same type out | Direct method (`.Map`) | Simpler, no import needed |
+| Type changes across steps | Sub-package function | Go methods can't add type params |
+| 3+ chained type transforms | `Pipe3`+ | Readable left-to-right flow |
+| Single type transform | Sub-package function call | Pipe1 is overkill |
+| Mixed same-type and cross-type | Combine both | Direct for same-type, pipe for cross-type |
+
+### Example: Combined Usage
+
+```go
+// Start with direct method (same type)
+opt := mo.Some(42).
+    Map(func(v int) (int, bool) { return v * 2, true })  // still Option[int]
+
+// Then use pipe for type change
+result := option.Pipe2(
+    opt,
+    option.Map(func(v int) string { return strconv.Itoa(v) }),  // -> Option[string]
+    option.Map(func(s string) User { return User{Name: s} }),   // -> Option[User]
+)
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/result.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/result.md
new file mode 100644
index 00000000..e589d1a4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-mo/references/result.md
@@ -0,0 +1,145 @@
+# Result[T] API Reference
+
+## Constructors
+
+| Function | Description |
+| --- | --- |
+| `mo.Ok[T](value T)` | Creates a successful Result |
+| `mo.Err[T](err error)` | Creates a failed Result |
+| `mo.Errf[T](format string, a ...any)` | Creates failed Result with formatted error message |
+| `mo.TupleToResult[T](value T, err error)` | Converts Go's (T, error) tuple — Ok if err is nil, Err otherwise |
+| `mo.Try[T](f func() (T, error))` | Executes function, wraps result — Ok on success, Err on error |
+
+### Do Notation
+
+```go
+result := mo.Do(func() int {
+    a := mo.Ok(10).MustGet()     // panics if Err -> caught by Do
+    b := mo.Ok(32).MustGet()
+    return a + b
+})
+// Ok(42)
+```
+
+`mo.Do` executes a closure and catches any panic from `MustGet()` calls, converting them to `Err`. This enables imperative-style code with monadic error propagation.
+
+## Query Methods
+
+| Method | Returns | Description |
+| --- | --- | --- |
+| `IsOk()` | `bool` | True if Result is successful |
+| `IsError()` | `bool` | True if Result is a failure |
+| `Error()` | `error` | Returns the error, or nil if Ok |
+| `Get()` | `(T, error)` | Returns value and error (Go-style) |
+| `MustGet()` | `T` | Returns value or panics — use only inside `mo.Do` |
+
+## Value Extraction
+
+| Method               | Returns | Description                    |
+| -------------------- | ------- | ------------------------------ |
+| `OrElse(fallback T)` | `T`     | Value if Ok, fallback if Err   |
+| `OrEmpty()`          | `T`     | Value if Ok, zero value if Err |
+
+## Transformations
+
+### Map — transform successful value
+
+```go
+result := mo.Ok(42).
+    Map(func(v int) (int, error) {
+        return v * 2, nil
+    })
+// Ok(84)
+
+// Errors short-circuit
+result := mo.Err[int](errors.New("fail")).
+    Map(func(v int) (int, error) {
+        return v * 2, nil  // never called
+    })
+// Err("fail")
+```
+
+**Go limitation:** Result.Map takes `func(T) (T, error)` — the input and output types must be the same `T`. Returning a non-nil error converts Ok to Err. To change the type (e.g. `Result[[]byte]` to `Result[Config]`), use sub-package `result.Map` or `mo.Do` notation — see [Pipelines Reference](./pipelines.md).
+
+### MapValue — transform without error possibility
+
+```go
+result := mo.Ok(42).MapValue(func(v int) int {
+    return v * 2
+})
+// Ok(84) — no error possible in the mapper
+```
+
+### MapErr — transform error state
+
+```go
+result := mo.Err[int](errors.New("fail")).
+    MapErr(func(err error) (int, error) {
+        return 0, fmt.Errorf("wrapped: %w", err)
+    })
+// Err("wrapped: fail")
+```
+
+### FlatMap — chain Results
+
+```go
+func parseAge(s string) mo.Result[int] {
+    v, err := strconv.Atoi(s)
+    return mo.TupleToResult(v, err)
+}
+
+func validateAge(age int) mo.Result[int] {
+    if age < 0 || age > 150 {
+        return mo.Errf[int]("invalid age: %d", age)
+    }
+    return mo.Ok(age)
+}
+
+result := parseAge("25").FlatMap(func(age int) mo.Result[int] {
+    return validateAge(age)
+})
+// Ok(25)
+```
+
+### Match — handle both cases
+
+```go
+result.Match(
+    func(v int) (int, error) {
+        fmt.Println("Success:", v)
+        return v, nil
+    },
+    func(err error) (int, error) {
+        fmt.Println("Error:", err)
+        return 0, err
+    },
+)
+```
+
+### ForEach — side effect on success
+
+```go
+result.ForEach(func(v int) {
+    fmt.Println("Got:", v)  // only executes if Ok
+})
+```
+
+## Conversion
+
+```go
+either := result.ToEither()  // Either[error, T]
+// Ok(42) -> Right(42)
+// Err(e) -> Left(e)
+```
+
+## JSON Serialization
+
+Result marshals to JSON-RPC format:
+
+```go
+// Ok(42) marshals to:
+{"result": 42}
+
+// Err("fail") marshals to:
+{"error": {"message": "fail"}}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/SKILL.md
new file mode 100644
index 00000000..d40bdad9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/SKILL.md
@@ -0,0 +1,276 @@
+---
+name: golang-samber-oops
+description: "Structured error handling in Golang with samber/oops — error builders, stack traces, error codes, error context, error wrapping, error attributes, user-facing vs developer messages, panic recovery, and logger integration. Apply when using or adopting samber/oops, or when the codebase already imports github.com/samber/oops."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.3"
+  openclaw:
+    emoji: "💥"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "1.21.0"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs
+---
+
+**Persona:** You are a Go engineer who treats errors as structured data. Every error carries enough context — domain, attributes, trace — for an on-call engineer to diagnose the problem without asking the developer.
+
+# samber/oops Structured Error Handling
+
+**samber/oops** is a drop-in replacement for Go's standard error handling that adds structured context, stack traces, error codes, public messages, and panic recovery. Variable data goes in `.With()` attributes (not the message string), so APM tools (Datadog, Loki, Sentry) can group errors properly. Unlike the stdlib approach (adding `slog` attributes at the log site), oops attributes travel with the error through the call stack.
+
+## Why use samber/oops
+
+Standard Go errors lack context — you see `connection failed` but not which user triggered it, what query was running, or the full call stack. `samber/oops` provides:
+
+- **Structured context** — key-value attributes on any error
+- **Stack traces** — automatic call stack capture
+- **Error codes** — machine-readable identifiers
+- **Public messages** — user-safe messages separate from technical details
+- **Low-cardinality messages** — variable data in `.With()` attributes, not the message string, so APM tools group errors properly
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+## Core pattern: Error builder chain
+
+All `oops` errors use a fluent builder pattern:
+
+```go
+err := oops.
+    In("user-service").           // domain/feature
+    Tags("database", "postgres").  // categorization
+    Code("network_failure").       // machine-readable identifier
+    User("user-123", "email", "foo@bar.com").  // user context
+    With("query", query).          // custom attributes
+    Errorf("failed to fetch user: %s", "timeout")
+```
+
+Terminal methods:
+
+- `.Errorf(format, args...)` — create a new error
+- `.Wrap(err)` — wrap an existing error
+- `.Wrapf(err, format, args...)` — wrap with a message
+- `.Join(err1, err2, ...)` — combine multiple errors
+- `.Recover(fn)` / `.Recoverf(fn, format, args...)` — convert panic to error
+
+### Error builder methods
+
+| Methods | Use case |
+| --- | --- |
+| `.With("key", value)` | Add custom key-value attribute (lazy `func() any` values supported) |
+| `.WithContext(ctx, "key1", "key2")` | Extract values from Go context into attributes (lazy values supported) |
+| `.In("domain")` | Set the feature/service/domain |
+| `.Tags("auth", "sql")` | Add categorization tags (query with `err.HasTag("tag")`) |
+| `.Code("iam_authz_missing_permission")` | Set machine-readable error identifier/slug |
+| `.Public("Could not fetch user.")` | Set user-safe message (separate from technical details) |
+| `.Hint("Runbook: https://doc.acme.org/doc/abcd.md")` | Add debugging hint for developers |
+| `.Owner("team/slack")` | Identify responsible team/owner |
+| `.User(id, "k", "v")` | Add user identifier and attributes |
+| `.Tenant(id, "k", "v")` | Add tenant/organization context and attributes |
+| `.Trace(id)` | Add trace / correlation ID (default: ULID) |
+| `.Span(id)` | Add span ID representing a unit of work/operation (default: ULID) |
+| `.Time(t)` | Override error timestamp (default: `time.Now()`) |
+| `.Since(t)` | Set duration based on time since `t` (exposed via `err.Duration()`) |
+| `.Duration(d)` | Set explicit error duration |
+| `.Request(req, includeBody)` | Attach `*http.Request` (optionally including body) |
+| `.Response(res, includeBody)` | Attach `*http.Response` (optionally including body) |
+| `oops.FromContext(ctx)` | Start from an `OopsErrorBuilder` stored in a Go context |
+
+## Common scenarios
+
+### Database/repository layer
+
+```go
+func (r *UserRepository) FetchUser(id string) (*User, error) {
+    query := "SELECT * FROM users WHERE id = $1"
+    row, err := r.db.Query(query, id)
+    if err != nil {
+        return nil, oops.
+            In("user-repository").
+            Tags("database", "postgres").
+            With("query", query).
+            With("user_id", id).
+            Wrapf(err, "failed to fetch user from database")
+    }
+    // ...
+}
+```
+
+### HTTP handler layer
+
+```go
+func (h *Handler) CreateUser(w http.ResponseWriter, r *http.Request) {
+    userID := getUserID(r)
+
+    err := h.service.CreateUser(r.Context(), userID)
+    if err != nil {
+        err = oops.
+            In("http-handler").
+            Tags("endpoint", "/users").
+            Request(r, false).
+            User(userID).
+            Wrapf(err, "create user failed")
+        http.Error(w, oops.GetPublic(err, "Internal server error"), http.StatusInternalServerError)
+        return
+    }
+
+    w.WriteHeader(http.StatusCreated)
+}
+```
+
+### Service layer with reusable builder
+
+```go
+func (s *UserService) CreateOrder(ctx context.Context, req CreateOrderRequest) error {
+    builder := oops.
+        In("order-service").
+        Tags("orders", "checkout").
+        Tenant(req.TenantID, "plan", req.Plan).
+        User(req.UserID, "email", req.UserEmail)
+
+    product, err := s.catalog.GetProduct(ctx, req.ProductID)
+    if err != nil {
+        return builder.
+            With("product_id", req.ProductID).
+            Wrapf(err, "product lookup failed")
+    }
+
+    if product.Stock < req.Quantity {
+        return builder.
+            Code("insufficient_stock").
+            Public("Not enough items in stock.").
+            With("requested", req.Quantity).
+            With("available", product.Stock).
+            Errorf("insufficient stock for product %s", req.ProductID)
+    }
+
+    return nil
+}
+```
+
+## Error wrapping best practices
+
+### DO: Wrap directly, no nil check needed
+
+```go
+// ✓ Good — Wrap returns nil if err is nil
+return oops.Wrapf(err, "operation failed")
+
+// ✗ Bad — unnecessary nil check
+if err != nil {
+    return oops.Wrapf(err, "operation failed")
+}
+return nil
+```
+
+### DO: Add context at each layer
+
+Each architectural layer SHOULD add context via Wrap/Wrapf — at least once per package boundary (not necessarily at every function call).
+
+```go
+// ✓ Good — each layer adds relevant context
+func Controller() error {
+    return oops.In("controller").Trace(traceID).Wrapf(Service(), "user request failed")
+}
+
+func Service() error {
+    return oops.In("service").With("op", "create_user").Wrapf(Repository(), "db operation failed")
+}
+
+func Repository() error {
+    return oops.In("repository").Tags("database", "postgres").Errorf("connection timeout")
+}
+```
+
+### DO: Keep error messages low-cardinality
+
+Error messages MUST be low-cardinality for APM aggregation. Interpolating variable data into the message breaks grouping in Datadog, Loki, Sentry.
+
+```go
+// ✗ Bad — high-cardinality, breaks APM grouping
+oops.Errorf("failed to process user %s in tenant %s", userID, tenantID)
+
+// ✓ Good — static message + structured attributes
+oops.With("user_id", userID).With("tenant_id", tenantID).Errorf("failed to process user")
+```
+
+## Panic recovery
+
+`oops.Recover()` MUST be used in goroutine boundaries. Convert panics to structured errors:
+
+```go
+func ProcessData(data string) (err error) {
+    return oops.
+        In("data-processor").
+        Code("panic_recovered").
+        Hint("Check input data format and dependencies").
+        With("input_data", data).
+        Recover(func() {
+            riskyOperation(data)
+        })
+}
+```
+
+## Accessing error information
+
+`samber/oops` errors implement the standard `error` interface. Access additional info:
+
+```go
+if oopsErr, ok := err.(oops.OopsError); ok {
+    fmt.Println("Code:", oopsErr.Code())
+    fmt.Println("Domain:", oopsErr.Domain())
+    fmt.Println("Tags:", oopsErr.Tags())
+    fmt.Println("Context:", oopsErr.Context())
+    fmt.Println("Stacktrace:", oopsErr.Stacktrace())
+}
+
+// Get public-facing message with fallback
+publicMsg := oops.GetPublic(err, "Something went wrong")
+```
+
+### Output formats
+
+```go
+fmt.Printf("%+v\n", err)       // verbose with stack trace
+bytes, _ := json.Marshal(err)  // JSON for logging
+slog.Error(err.Error(), slog.Any("error", err))  // slog integration
+```
+
+## Context propagation
+
+Carry error context through Go contexts:
+
+```go
+func middleware(next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        builder := oops.
+            In("http").
+            Request(r, false).
+            Trace(r.Header.Get("X-Trace-ID"))
+
+        ctx := oops.WithBuilder(r.Context(), builder)
+        next.ServeHTTP(w, r.WithContext(ctx))
+    })
+}
+
+func handler(ctx context.Context) error {
+    return oops.FromContext(ctx).Tags("handler", "users").Errorf("something failed")
+}
+```
+
+For assertions, configuration, and additional logger examples, see [Advanced patterns](./references/advanced.md).
+
+## References
+
+- [github.com/samber/oops](https://github.com/samber/oops)
+- [pkg.go.dev/github.com/samber/oops](https://pkg.go.dev/github.com/samber/oops)
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-error-handling` skill for general error handling patterns
+- → See `samber/cc-skills-golang@golang-observability` skill for logger integration and structured logging
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/evals/evals.json
new file mode 100644
index 00000000..f83281f4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/evals/evals.json
@@ -0,0 +1,154 @@
+[
+  {
+    "id": 1,
+    "name": "low-cardinality-error-messages",
+    "description": "Tests the critical rule: variable data goes in .With() attributes, not interpolated into the message string",
+    "prompt": "I'm using samber/oops in my Go service. Write error handling for a function that processes orders. When an order fails, I need to include the user ID, tenant ID, and order ID in the error for debugging.",
+    "trap": "Model may interpolate all variables into the Errorf message string (e.g., Errorf('failed to process order %s for user %s in tenant %s', orderID, userID, tenantID)) which breaks APM grouping",
+    "assertions": [
+      {"id": "1.1", "text": "Uses .With() for user_id, tenant_id, and order_id instead of interpolating them into the message"},
+      {"id": "1.2", "text": "The Errorf/Wrapf message string is static/low-cardinality (no variable interpolation for IDs)"},
+      {"id": "1.3", "text": "Uses the fluent builder pattern (chained method calls)"},
+      {"id": "1.4", "text": "Does NOT use fmt.Errorf or errors.New for the error creation"},
+      {"id": "1.5", "text": "Includes .In() to set the domain/feature context"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "wrap-nil-passthrough",
+    "description": "Tests that oops.Wrap returns nil if err is nil, so no nil check is needed",
+    "prompt": "I have a Go function using samber/oops. It calls another function that may return nil or an error. How should I handle the return value? Here's my code:\n\n```go\nfunc ProcessData(ctx context.Context) error {\n    err := fetchData(ctx)\n    if err != nil {\n        return oops.In(\"processor\").Wrapf(err, \"fetch failed\")\n    }\n    return nil\n}\n```\n\nIs there a simpler way to write this?",
+    "trap": "Model may say the code is fine as-is, not knowing that oops.Wrap/Wrapf returns nil when err is nil, making the nil check unnecessary",
+    "assertions": [
+      {"id": "2.1", "text": "Identifies that the nil check is unnecessary because oops.Wrapf returns nil if err is nil"},
+      {"id": "2.2", "text": "Shows the simplified form: return oops.In('processor').Wrapf(err, 'fetch failed') without the if block"},
+      {"id": "2.3", "text": "The simplified version removes both the if statement and the separate return nil"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "layered-error-context",
+    "description": "Tests that each architectural layer should add context via Wrap/Wrapf at package boundaries",
+    "prompt": "I have a 3-layer Go architecture: HTTP handler -> service -> repository. Each layer calls the next. How should I handle errors with samber/oops so that when an error reaches the top, I can see the full context of what happened at each layer?",
+    "trap": "Model may only wrap at the top level or only at the bottom level, instead of wrapping at each layer boundary with layer-specific context",
+    "assertions": [
+      {"id": "3.1", "text": "Each layer (handler, service, repository) adds its own .In() domain context"},
+      {"id": "3.2", "text": "Each layer wraps the error from the layer below using Wrap or Wrapf"},
+      {"id": "3.3", "text": "Different layers add different context attributes relevant to their scope (e.g., repository adds query/table info, handler adds request info)"},
+      {"id": "3.4", "text": "Uses .Tags() for categorization at one or more layers"},
+      {"id": "3.5", "text": "Handler layer uses .Request() to attach HTTP request context"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "public-vs-technical-messages",
+    "description": "Tests the separation between user-safe public messages and technical error details",
+    "prompt": "I'm building a Go API. When a user tries to buy a product that's out of stock, I need to return a user-friendly message to the frontend AND log detailed technical information. How do I handle this with samber/oops?",
+    "trap": "Model may put the user-facing message in Errorf (which is for technical details) instead of using .Public() for the user-safe message",
+    "assertions": [
+      {"id": "4.1", "text": "Uses .Public() to set a user-safe message (e.g., 'Not enough items in stock')"},
+      {"id": "4.2", "text": "Uses .Errorf() or .Wrapf() for the technical error message (separate from the public message)"},
+      {"id": "4.3", "text": "Uses .Code() to set a machine-readable error code (e.g., 'insufficient_stock')"},
+      {"id": "4.4", "text": "Uses .With() for structured attributes like requested quantity, available stock"},
+      {"id": "4.5", "text": "Shows how to retrieve the public message using oops.GetPublic(err, fallback)"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "panic-recovery-goroutine",
+    "description": "Tests that oops.Recover is used at goroutine boundaries to convert panics to structured errors",
+    "prompt": "I have a Go function that spawns goroutines to process items. Sometimes the processing panics. How should I handle this with samber/oops?",
+    "trap": "Model may use a plain defer/recover pattern instead of oops.Recover(), missing the structured error context, stack trace, and error code",
+    "assertions": [
+      {"id": "5.1", "text": "Uses oops.Recover() or the builder's .Recover() method, not a raw defer/recover"},
+      {"id": "5.2", "text": "The Recover wraps the risky operation in a function passed to Recover"},
+      {"id": "5.3", "text": "Adds structured context to the recovery (e.g., .In(), .Code(), .With())"},
+      {"id": "5.4", "text": "Uses a named return value for the error so Recover can set it"},
+      {"id": "5.5", "text": "Includes .Hint() for debugging guidance or .Code() for identification"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "context-propagation-middleware",
+    "description": "Tests knowledge of oops.WithBuilder/oops.FromContext for propagating error context through Go contexts",
+    "prompt": "I want all errors in my Go HTTP service to automatically include the trace ID, request info, and user ID without passing these values through every function. How can I achieve this with samber/oops?",
+    "trap": "Model may suggest passing an oops builder as a function parameter or creating it in every function, instead of using context-based propagation with WithBuilder/FromContext",
+    "assertions": [
+      {"id": "6.1", "text": "Uses oops.WithBuilder() to store the builder in the Go context in middleware"},
+      {"id": "6.2", "text": "Uses oops.FromContext(ctx) in downstream functions to retrieve the pre-configured builder"},
+      {"id": "6.3", "text": "Middleware sets trace ID, request info, and user context on the builder"},
+      {"id": "6.4", "text": "Shows the middleware pattern with http.Handler wrapping"},
+      {"id": "6.5", "text": "Downstream handlers/services can add more context (e.g., .Tags()) on top of the base builder"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "reusable-builder-pattern",
+    "description": "Tests the pattern of creating a reusable builder at the top of a function and reusing it for multiple error paths",
+    "prompt": "I have a Go service function with 4 different error return paths. Each error needs the same user ID, tenant ID, and domain context, but different error-specific details. How should I structure this with samber/oops?",
+    "trap": "Model may duplicate the full builder chain at each error site, instead of creating a shared base builder and extending it per error path",
+    "assertions": [
+      {"id": "7.1", "text": "Creates a single base builder variable at the top of the function with shared context (user, tenant, domain)"},
+      {"id": "7.2", "text": "Each error return path extends the base builder with error-specific attributes using .With() or .Code()"},
+      {"id": "7.3", "text": "The base builder is NOT terminated (no .Errorf/.Wrap call) — it's reused"},
+      {"id": "7.4", "text": "Uses .In() on the shared builder for the domain/feature"},
+      {"id": "7.5", "text": "Uses .User() and/or .Tenant() on the shared builder"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "accessing-oops-error-info",
+    "description": "Tests knowledge of the OopsError type assertion to access structured fields",
+    "prompt": "I receive an error from a lower layer that was created with samber/oops. I need to extract the error code, domain, tags, and context map from it in my error handler middleware. How do I access this information?",
+    "trap": "Model may try to use string parsing or fmt.Sprintf to extract information instead of type-asserting to oops.OopsError",
+    "assertions": [
+      {"id": "8.1", "text": "Type-asserts the error to oops.OopsError"},
+      {"id": "8.2", "text": "Uses .Code() method to get the error code"},
+      {"id": "8.3", "text": "Uses .Domain() method to get the domain"},
+      {"id": "8.4", "text": "Uses .Tags() method to get the tags"},
+      {"id": "8.5", "text": "Uses .Context() method to get the key-value attributes map"},
+      {"id": "8.6", "text": "Uses .Stacktrace() method to get the stack trace"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "user-and-tenant-context",
+    "description": "Tests the .User() and .Tenant() methods with their key-value attribute support",
+    "prompt": "In my multi-tenant Go SaaS application using samber/oops, I need errors to carry both the tenant information (ID, plan type) and user information (ID, email). Show me how to create such an error when a permission check fails.",
+    "trap": "Model may use .With('user_id', id) and .With('tenant_id', id) instead of the dedicated .User() and .Tenant() methods which support additional attributes",
+    "assertions": [
+      {"id": "9.1", "text": "Uses .User(id, key, value) method with the user ID and additional attributes like email"},
+      {"id": "9.2", "text": "Uses .Tenant(id, key, value) method with the tenant ID and additional attributes like plan"},
+      {"id": "9.3", "text": "Does NOT just use .With() for user/tenant info when .User()/.Tenant() are available"},
+      {"id": "9.4", "text": "Includes a .Code() for the permission error"},
+      {"id": "9.5", "text": "Uses .Public() for a user-facing permission denied message"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "oops-assertions",
+    "description": "Tests knowledge of oops.Assert/oops.Assertf for invariant checks wrapped in Recover",
+    "prompt": "I have a Go payment processing function that should never receive a negative amount — that would indicate a bug in the calling code. How should I handle this invariant with samber/oops? The function processes payments and interacts with external services.",
+    "trap": "Model may use a standard if/return error pattern or panic() directly, instead of oops assertions wrapped in Recover for structured panic-to-error conversion",
+    "assertions": [
+      {"id": "10.1", "text": "Uses oops.Assertf or oops.Assert to check the invariant (amount > 0)"},
+      {"id": "10.2", "text": "Wraps the assertion in an oops.Recover() call to convert the panic to a structured error"},
+      {"id": "10.3", "text": "Uses a named error return value so Recover can set it"},
+      {"id": "10.4", "text": "Notes that assertions should be rare in Go and used only for truly impossible/bug states"},
+      {"id": "10.5", "text": "Adds structured context (.In(), .Code(), etc.) to the Recover builder"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "oops-configuration",
+    "description": "oops global config variables (StackTraceMaxDepth, Local, SourceFragmentsHidden) must be set at init time; model should not suggest post-processing or custom wrappers",
+    "prompt": "I'm using samber/oops in my Go application. Three problems:\n1. Stack traces are 50+ frames deep — too noisy for our logging system\n2. Error timestamps show in UTC but our ops team wants US Eastern time\n3. Source code fragments in error output leak internal code to our error tracking SaaS — we want to disable them\n\nA teammate suggests: 'Write a wrapper around oops.Wrapf that post-processes the OopsError to trim the stack and remove fragments.' Is that the right approach? How should these actually be configured?",
+    "trap": "The teammate's wrapper suggestion seems reasonable — it encapsulates the behavior. But oops provides direct global configuration variables for all three needs. The model should know these specific variable names: oops.StackTraceMaxDepth, oops.Local, oops.SourceFragmentsHidden. Without the skill docs, the model will likely guess wrong names or accept the wrapper approach.",
+    "assertions": [
+      {"id": "11.1", "text": "Rejects the wrapper approach — oops has built-in global configuration for all three requirements; a wrapper adds complexity for no benefit"},
+      {"id": "11.2", "text": "Uses oops.StackTraceMaxDepth (the exact variable name) to control stack trace depth — not a method call or wrapper"},
+      {"id": "11.3", "text": "Uses oops.Local with time.LoadLocation('America/New_York') for timezone — not post-processing timestamps"},
+      {"id": "11.4", "text": "Uses oops.SourceFragmentsHidden = true to disable source code fragments in error output"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/references/advanced.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/references/advanced.md
new file mode 100644
index 00000000..82096e22
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-oops/references/advanced.md
@@ -0,0 +1,51 @@
+# samber/oops — Advanced Patterns
+
+## Assertions
+
+Use assertions for invariant checks (carefully — assertions panic):
+
+```go
+func ProcessPayment(amount int) error {
+    return oops.
+        In("payment-service").
+        Recover(func() {
+            oops.Assertf(amount > 0, "amount must be positive, got %d", amount)
+            oops.Assert(amount < 1_000_000)
+            // ... payment logic
+        })
+}
+```
+
+Assertions should be rare in Go. Use them only for truly impossible states that indicate a bug.
+
+## Configuration
+
+```go
+oops.StackTraceMaxDepth = 20          // adjust stack trace depth
+oops.SourceFragmentsHidden = false    // enable source code fragments
+loc, _ := time.LoadLocation("America/New_York")
+oops.Local = loc                      // set timezone for error timestamps
+```
+
+## Logger integration
+
+`samber/oops` works with any logger. The error struct provides methods for extracting structured data:
+
+```go
+oopsErr := err.(oops.OopsError)
+fmt.Println("operation failed",
+    "code", oopsErr.Code(),
+    "domain", oopsErr.Domain(),
+    "user_id", oopsErr.User(),
+    "error", oopsErr,
+)
+
+// With slog
+slog.Error(err.Error(), slog.Any("error", err))
+
+// With zerolog (formatter available)
+log.Error().Err(err).Msg("operation failed")
+
+// With logrus (formatter available)
+log.WithError(err).Error("operation failed")
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/SKILL.md
new file mode 100644
index 00000000..21b95fd9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/SKILL.md
@@ -0,0 +1,181 @@
+---
+name: golang-samber-ro
+description: "Reactive streams and event-driven programming in Golang using samber/ro — ReactiveX implementation with 150+ type-safe operators, cold/hot observables, 5 subject types (Publish, Behavior, Replay, Async, Unicast), declarative pipelines via Pipe, 40+ plugins (HTTP, cron, fsnotify, JSON, logging), automatic backpressure, error propagation, and Go context integration. Apply when using or adopting samber/ro, when the codebase imports github.com/samber/ro, or when building asynchronous event-driven pipelines, real-time data processing, streams, or reactive architectures in Go. Not for finite slice transforms (→ See `samber/cc-skills-golang@golang-samber-lo` skill)."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.0"
+  openclaw:
+    emoji: "👁"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "0.3.0"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent mcp__context7__resolve-library-id mcp__context7__query-docs AskUserQuestion
+---
+
+**Persona:** You are a Go engineer who reaches for reactive streams when data flows asynchronously or infinitely. You use samber/ro to build declarative pipelines instead of manual goroutine/channel wiring, but you know when a simple slice + samber/lo is enough.
+
+**Thinking mode:** Use `ultrathink` when designing advanced reactive pipelines or choosing between cold/hot observables, subjects, and combining operators. Wrong architecture leads to resource leaks or missed events.
+
+# samber/ro — Reactive Streams for Go
+
+Go implementation of [ReactiveX](https://reactivex.io/). Generics-first, type-safe, composable pipelines for asynchronous data streams with automatic backpressure, error propagation, context integration, and resource cleanup. 150+ operators, 5 subject types, 40+ plugins.
+
+**Official Resources:**
+
+- [github.com/samber/ro](https://github.com/samber/ro)
+- [ro.samber.dev](https://ro.samber.dev)
+- [pkg.go.dev/github.com/samber/ro](https://pkg.go.dev/github.com/samber/ro)
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+## Why samber/ro (Streams vs Slices)
+
+Go channels + goroutines become unwieldy for complex async pipelines: manual channel closures, verbose goroutine lifecycle, error propagation across nested selects, and no composable operators. `samber/ro` solves this with declarative, chainable stream operators.
+
+**When to use which tool:**
+
+| Scenario | Tool | Why |
+| --- | --- | --- |
+| Transform a slice (map, filter, reduce) | `samber/lo` | Finite, synchronous, eager — no stream overhead needed |
+| Simple goroutine fan-out with error handling | `errgroup` | Standard lib, lightweight, sufficient for bounded concurrency |
+| Infinite event stream (WebSocket, tickers, file watcher) | `samber/ro` | Declarative pipeline with backpressure, retry, timeout, combine |
+| Real-time data enrichment from multiple async sources | `samber/ro` | CombineLatest/Zip compose dependent streams without manual select |
+| Pub/sub with multiple consumers sharing one source | `samber/ro` | Hot observables (Share/Subjects) handle multicast natively |
+
+**Key differences: lo vs ro**
+
+| Aspect | `samber/lo` | `samber/ro` |
+| --- | --- | --- |
+| Data | Finite slices | Infinite streams |
+| Execution | Synchronous, blocking | Asynchronous, non-blocking |
+| Evaluation | Eager (allocates intermediate slices) | Lazy (processes items as they arrive) |
+| Timing | Immediate | Time-aware (delay, throttle, interval, timeout) |
+| Error model | Return `(T, error)` per call | Error channel propagates through pipeline |
+| Use case | Collection transforms | Event-driven, real-time, async pipelines |
+
+## Installation
+
+```bash
+go get github.com/samber/ro
+```
+
+## Core Concepts
+
+Four building blocks:
+
+1. **Observable** — a data source that emits values over time. Cold by default: each subscriber triggers independent execution from scratch
+2. **Observer** — a consumer with three callbacks: `onNext(T)`, `onError(error)`, `onComplete()`
+3. **Operator** — a function that transforms an observable into another observable, chained via `Pipe`
+4. **Subscription** — the connection between observable and observer. Call `.Wait()` to block or `.Unsubscribe()` to cancel
+
+```go
+observable := ro.Pipe2(
+    ro.RangeWithInterval(0, 5, 1*time.Second),
+    ro.Filter(func(x int) bool { return x%2 == 0 }),
+    ro.Map(func(x int) string { return fmt.Sprintf("even-%d", x) }),
+)
+
+observable.Subscribe(ro.NewObserver(
+    func(s string) { fmt.Println(s) },      // onNext
+    func(err error) { log.Println(err) },    // onError
+    func() { fmt.Println("Done!") },         // onComplete
+))
+// Output: "even-0", "even-2", "even-4", "Done!"
+
+// Or collect synchronously:
+values, err := ro.Collect(observable)
+```
+
+## Cold vs Hot Observables
+
+**Cold** (default): each `.Subscribe()` starts a new independent execution. Safe and predictable — use by default.
+
+**Hot**: multiple subscribers share a single execution. Use when the source is expensive (WebSocket, DB poll) or subscribers must see the same events.
+
+| Convert with | Behavior |
+| --- | --- |
+| `Share()` | Cold → hot with reference counting. Last unsubscribe tears down |
+| `ShareReplay(n)` | Same as Share + buffers last N values for late subscribers |
+| `Connectable()` | Cold → hot, but waits for explicit `.Connect()` call |
+| Subjects | Natively hot — call `.Send()`, `.Error()`, `.Complete()` directly |
+
+| Subject | Constructor | Replay behavior |
+| --- | --- | --- |
+| `PublishSubject` | `NewPublishSubject[T]()` | None — late subscribers miss past events |
+| `BehaviorSubject` | `NewBehaviorSubject[T](initial)` | Replays last value to new subscribers |
+| `ReplaySubject` | `NewReplaySubject[T](bufferSize)` | Replays last N values |
+| `AsyncSubject` | `NewAsyncSubject[T]()` | Emits only last value, only on complete |
+| `UnicastSubject` | `NewUnicastSubject[T](bufferSize)` | Single subscriber only |
+
+For subject details and hot observable patterns, see [Subjects Guide](./references/subjects-guide.md).
+
+## Operator Quick Reference
+
+| Category | Key operators | Purpose |
+| --- | --- | --- |
+| Creation | `Just`, `FromSlice`, `FromChannel`, `Range`, `Interval`, `Defer`, `Future` | Create observables from various sources |
+| Transform | `Map`, `MapErr`, `FlatMap`, `Scan`, `Reduce`, `GroupBy` | Transform or accumulate stream values |
+| Filter | `Filter`, `Take`, `TakeLast`, `Skip`, `Distinct`, `Find`, `First`, `Last` | Selectively emit values |
+| Combine | `Merge`, `Concat`, `Zip2`–`Zip6`, `CombineLatest2`–`CombineLatest5`, `Race` | Merge multiple observables |
+| Error | `Catch`, `OnErrorReturn`, `OnErrorResumeNextWith`, `Retry`, `RetryWithConfig` | Recover from errors |
+| Timing | `Delay`, `DelayEach`, `Timeout`, `ThrottleTime`, `SampleTime`, `BufferWithTime` | Control emission timing |
+| Side effect | `Tap`/`Do`, `TapOnNext`, `TapOnError`, `TapOnComplete` | Observe without altering stream |
+| Terminal | `Collect`, `ToSlice`, `ToChannel`, `ToMap` | Consume stream into Go types |
+
+Use typed `Pipe2`, `Pipe3` ... `Pipe25` for compile-time type safety across operator chains. The untyped `Pipe` uses `any` and loses type checking.
+
+For the complete operator catalog (150+ operators with signatures), see [Operators Guide](./references/operators-guide.md).
+
+## Common Mistakes
+
+| Mistake | Why it fails | Fix |
+| --- | --- | --- |
+| Using `ro.OnNext()` without error handler | Errors are silently dropped — bugs hide in production | Use `ro.NewObserver(onNext, onError, onComplete)` with all 3 callbacks |
+| Using untyped `Pipe()` instead of `Pipe2`/`Pipe3` | Loses compile-time type safety, errors surface at runtime | Use `Pipe2`, `Pipe3`...`Pipe25` for typed operator chains |
+| Forgetting `.Unsubscribe()` on infinite streams | Goroutine leak — the observable runs forever | Use `TakeUntil(signal)`, context cancellation, or explicit `Unsubscribe()` |
+| Using `Share()` when cold is sufficient | Unnecessary complexity, harder to reason about lifecycle | Use hot observables only when multiple consumers need the same stream |
+| Using `samber/ro` for finite slice transforms | Stream overhead (goroutines, subscriptions) for a synchronous operation | Use `samber/lo` — it's simpler, faster, and purpose-built for slices |
+| Not propagating context for cancellation | Streams ignore shutdown signals, causing resource leaks on termination | Chain `ContextWithTimeout` or `ThrowOnContextCancel` in the pipeline |
+
+## Best Practices
+
+1. **Always handle all three events** — use `NewObserver(onNext, onError, onComplete)`, not just `OnNext`. Unhandled errors cause silent data loss
+2. **Use `Collect()` for synchronous consumption** — when the stream is finite and you need `[]T`, `Collect` blocks until complete and returns the slice + error
+3. **Prefer typed Pipe functions** — `Pipe2`, `Pipe3`...`Pipe25` catch type mismatches at compile time. Reserve untyped `Pipe` for dynamic operator chains
+4. **Bound infinite streams** — use `Take(n)`, `TakeUntil(signal)`, `Timeout(d)`, or context cancellation. Unbounded streams leak goroutines
+5. **Use `Tap`/`Do` for observability** — log, trace, or meter emissions without altering the stream. Chain `TapOnError` for error monitoring
+6. **Prefer `samber/lo` for simple transforms** — if the data is a finite slice and you need Map/Filter/Reduce, use `lo`. Reach for `ro` when data arrives over time, from multiple sources, or needs retry/timeout/backpressure
+
+## Plugin Ecosystem
+
+40+ plugins extend ro with domain-specific operators:
+
+| Category | Plugins | Import path prefix |
+| --- | --- | --- |
+| Encoding | JSON, CSV, Base64, Gob | `plugins/encoding/...` |
+| Network | HTTP, I/O, FSNotify | `plugins/http`, `plugins/io`, `plugins/fsnotify` |
+| Scheduling | Cron, ICS | `plugins/cron`, `plugins/ics` |
+| Observability | Zap, Slog, Zerolog, Logrus, Sentry, Oops | `plugins/observability/...`, `plugins/samber/oops` |
+| Rate limiting | Native, Ulule | `plugins/ratelimit/...` |
+| Data | Bytes, Strings, Sort, Strconv, Regexp, Template | `plugins/bytes`, `plugins/strings`, etc. |
+| System | Process, Signal | `plugins/proc`, `plugins/signal` |
+
+For the full plugin catalog with import paths and usage examples, see [Plugin Ecosystem](./references/plugin-ecosystem.md).
+
+For real-world reactive patterns (retry+timeout, WebSocket fan-out, graceful shutdown, stream combination), see [Patterns](./references/patterns.md).
+
+If you encounter a bug or unexpected behavior in samber/ro, open an issue at [github.com/samber/ro/issues](https://github.com/samber/ro/issues).
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-samber-lo` skill for finite slice transforms (Map, Filter, Reduce, GroupBy) — use lo when data is already in a slice
+- → See `samber/cc-skills-golang@golang-samber-mo` skill for monadic types (Option, Result, Either) that compose with ro pipelines
+- → See `samber/cc-skills-golang@golang-samber-hot` skill for in-memory caching (also available as an ro plugin)
+- → See `samber/cc-skills-golang@golang-concurrency` skill for goroutine/channel patterns when reactive streams are overkill
+- → See `samber/cc-skills-golang@golang-observability` skill for monitoring reactive pipelines in production
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/evals/evals.json
new file mode 100644
index 00000000..14eeff33
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/evals/evals.json
@@ -0,0 +1,296 @@
+{
+  "skill_name": "golang-samber-ro",
+  "evals": [
+    {
+      "id": 1,
+      "name": "typed-pipe-vs-untyped",
+      "prompt": "I need to chain 3 operators in samber/ro: filter integers, map to strings, then take the first 5. Write the pipeline code.",
+      "assertions": [
+        "Uses ro.Pipe3 (or Pipe2 with nested) instead of untyped ro.Pipe for compile-time type safety",
+        "Uses ro.Filter with a func(int) bool predicate",
+        "Uses ro.Map with a func(int) string transform",
+        "Uses ro.Take[string](5) with correct generic type parameter"
+      ]
+    },
+    {
+      "id": 2,
+      "name": "lo-vs-ro-boundary",
+      "prompt": "I have a []User slice with 500 users. I want to filter active users and extract their email addresses into a []string. Should I use samber/ro for this? Write the code.",
+      "assertions": [
+        "Recommends samber/lo instead of samber/ro for this finite slice operation",
+        "Explains WHY lo is better here: synchronous, no stream overhead, purpose-built for slices",
+        "Does NOT create an Observable pipeline for a simple slice transform",
+        "Uses lo.Filter and lo.Map (or equivalent lo functions)"
+      ]
+    },
+    {
+      "id": 3,
+      "name": "observer-error-handling",
+      "prompt": "Subscribe to this observable and print each value: observable := ro.Interval(time.Second). Write the subscription code.",
+      "assertions": [
+        "Uses ro.NewObserver with all 3 callbacks (onNext, onError, onComplete), not just ro.OnNext",
+        "Includes an error handler that logs or handles the error",
+        "Includes a completion handler",
+        "Mentions the risk of using OnNext alone (silent error dropping)"
+      ]
+    },
+    {
+      "id": 4,
+      "name": "infinite-stream-shutdown",
+      "prompt": "I have an infinite ro.Interval observable processing events. How do I gracefully shut it down when the application receives SIGTERM?",
+      "assertions": [
+        "Uses ro.TakeUntil with a signal observable OR context cancellation with ThrowOnContextCancel",
+        "Mentions the signal plugin (plugins/signal) or os/signal for SIGTERM handling",
+        "Calls .Wait() on the subscription to block until shutdown completes",
+        "Does NOT suggest manual channel closing or goroutine killing as the primary approach",
+        "Mentions Unsubscribe() as an alternative cleanup mechanism"
+      ]
+    },
+    {
+      "id": 5,
+      "name": "subject-type-selection-config",
+      "prompt": "I need a reactive configuration store. When a new subscriber connects, it should immediately receive the current config value, and all subscribers should get updates when config changes. Which samber/ro Subject should I use?",
+      "assertions": [
+        "Recommends BehaviorSubject (not PublishSubject or ReplaySubject)",
+        "Explains that BehaviorSubject replays the last value to new subscribers",
+        "Shows NewBehaviorSubject[Config](initialConfig) constructor with initial value",
+        "Shows .Send() for pushing updates and .Subscribe() for consuming",
+        "Does NOT recommend PublishSubject (late subscribers would miss the current value)"
+      ]
+    },
+    {
+      "id": 6,
+      "name": "subject-type-selection-chat",
+      "prompt": "I'm building a chat room. New users joining should see the last 50 messages, and all users should receive new messages in real-time. Which samber/ro Subject type?",
+      "assertions": [
+        "Recommends ReplaySubject with buffer size 50",
+        "Shows NewReplaySubject[Message](50) constructor",
+        "Explains that ReplaySubject buffers N past values for late subscribers",
+        "Does NOT recommend BehaviorSubject (only replays 1 value, not 50)"
+      ]
+    },
+    {
+      "id": 7,
+      "name": "share-teardown-on-last-unsubscribe",
+      "prompt": "I have a samber/ro pipeline using Share() to multicast a WebSocket observable to 3 subscribers: a dashboard, a metrics recorder, and an alerting system. The dashboard and metrics recorder are temporary — they unsubscribe after 30 seconds. Only the alerting system stays permanently subscribed. After 30 seconds when the two temporary subscribers unsubscribe, will the WebSocket connection stay alive for the alerting system or will it be torn down?",
+      "assertions": [
+        "Correctly states that Share() tears down the underlying source when the LAST subscriber unsubscribes",
+        "Identifies that when dashboard and metrics recorder unsubscribe, the alerting system is the last subscriber — connection stays alive",
+        "Explains that Share() uses reference counting: source tears down only when refcount reaches 0",
+        "Warns that if ALL 3 unsubscribed simultaneously, the WebSocket would be torn down and alerting would stop receiving events",
+        "Distinguishes Share() (tears down on last unsubscribe) from a persistent Subject that stays alive regardless of subscriber count"
+      ]
+    },
+    {
+      "id": 8,
+      "name": "combinlatest-vs-zip-vs-merge",
+      "prompt": "I have two observables: one emits the current stock price every second, and another emits the current exchange rate every 5 seconds. I need to compute the converted price (price * rate) using the latest values from both. Which combining operator should I use in samber/ro?",
+      "assertions": [
+        "Recommends CombineLatest2 (not Zip2 or Merge)",
+        "Explains WHY: CombineLatest re-emits when either source updates, using the latest from both",
+        "Explains WHY NOT Zip: Zip waits for one value from each, so it would only emit every 5s",
+        "Explains WHY NOT Merge: Merge interleaves but doesn't combine values from both sources",
+        "Shows CombineLatest2(priceStream, rateStream) returning lo.Tuple2",
+        "Uses ro.Map to compute the product from the tuple"
+      ]
+    },
+    {
+      "id": 9,
+      "name": "retry-with-backoff",
+      "prompt": "I'm calling an unreliable external API via samber/ro. I want to retry up to 3 times with exponential backoff starting at 500ms, with a max delay of 10 seconds. If all retries fail, return a cached default value. Write the code.",
+      "assertions": [
+        "Uses ro.RetryWithConfig (not ro.Retry which retries infinitely)",
+        "Sets Max: 3 in RetryConfig",
+        "Sets Delay: 500ms and BackoffMultiplier: 2.0 in RetryConfig",
+        "Sets MaxDelay: 10*time.Second in RetryConfig",
+        "Chains OnErrorReturn or Catch after RetryWithConfig for the fallback",
+        "Orders operators correctly: source → RetryWithConfig → fallback (retry BEFORE fallback)"
+      ]
+    },
+    {
+      "id": 10,
+      "name": "scan-accumulator-state-design",
+      "prompt": "I'm using ro.Scan in samber/ro to compute a running average of sensor readings. My first attempt accumulates a sum but I can't compute the average because I don't know the count inside the Scan callback. Here's my broken code:\n\n```go\nro.Scan(func(acc float64, reading float64) float64 {\n    return acc + reading  // sum grows but can't divide — don't know N\n}, 0.0)\n```\n\nHow do I fix this to emit the correct running average on each new reading?",
+      "assertions": [
+        "Identifies that the accumulator must carry both sum AND count as state (not just the running average)",
+        "Changes the accumulator type to a struct (or tuple) holding {sum float64, count int}",
+        "Shows Scan returning the updated struct with incremented count and added sum",
+        "Chains a Map after Scan to compute avg = acc.sum / float64(acc.count) for display",
+        "Does NOT attempt to maintain an external counter variable outside the Scan (would break with concurrent subscribers)"
+      ]
+    },
+    {
+      "id": 11,
+      "name": "collect-synchronous",
+      "prompt": "I have a finite observable ro.Just(1, 2, 3, 4, 5) and I need to get all values into a regular Go slice []int. How do I do this with samber/ro?",
+      "assertions": [
+        "Uses ro.Collect(observable) which returns ([]int, error)",
+        "Checks the error return value from Collect",
+        "Does NOT manually subscribe and accumulate into a slice",
+        "Mentions that Collect blocks until the stream completes"
+      ]
+    },
+    {
+      "id": 12,
+      "name": "context-propagation",
+      "prompt": "I have a long-running samber/ro pipeline that should respect a 30-second timeout from the request context. If the context is cancelled, the pipeline should stop cleanly. How do I wire context into the pipeline?",
+      "assertions": [
+        "Uses ro.ContextWithTimeout or ro.ContextReset to inject the context/timeout",
+        "Uses ro.ThrowOnContextCancel to convert context cancellation to a stream error",
+        "Chains these context operators in the pipeline (not just passing ctx to Subscribe)",
+        "Handles the cancellation error in the observer's onError callback"
+      ]
+    },
+    {
+      "id": 13,
+      "name": "plugin-fsnotify",
+      "prompt": "I want to watch a directory for file changes using samber/ro and reload my app's configuration when a file is modified. I need debouncing to avoid reloading on every rapid save. Write the code.",
+      "assertions": [
+        "Knows about the fsnotify plugin (plugins/fsnotify)",
+        "Uses the fsnotify plugin to create an observable of file events",
+        "Uses ThrottleTime or a similar debounce operator to avoid rapid reloads",
+        "Filters for Write events specifically",
+        "Shows a Map operator to reload configuration from the changed file"
+      ]
+    },
+    {
+      "id": 14,
+      "name": "plugin-cron-scheduling",
+      "prompt": "I need a samber/ro observable that emits an event every day at midnight for a daily report generation job. What plugin should I use and how?",
+      "assertions": [
+        "Knows about the cron plugin (plugins/cron)",
+        "Uses cron.Schedule or similar with a cron expression like `0 0 * * *`",
+        "Shows the correct import path for the cron plugin",
+        "Chains the cron observable with Map or FlatMap to trigger report generation"
+      ]
+    },
+    {
+      "id": 15,
+      "name": "maperr-fallible-transform",
+      "prompt": "I have a stream of raw JSON strings in samber/ro. I want to parse each one into a struct, but some might be malformed. I want parsing errors to propagate through the pipeline's error channel, not panic. Which operator should I use?",
+      "assertions": [
+        "Uses ro.MapErr (not ro.Map) for the fallible JSON parsing",
+        "Shows MapErr with a func(string) (MyStruct, error) signature",
+        "Explains that MapErr propagates the error through the pipeline's error channel",
+        "Does NOT suggest using Map with a recover/panic pattern",
+        "Alternatively mentions the JSON encoding plugin (plugins/encoding/json) as an option"
+      ]
+    },
+    {
+      "id": 16,
+      "name": "buffer-batching",
+      "prompt": "I have a high-throughput event stream in samber/ro and I need to batch events for efficient database writes. I want batches of up to 100 events OR a flush every 5 seconds, whichever comes first. Write the code.",
+      "assertions": [
+        "Uses ro.BufferWithTimeOrCount (not just BufferWithCount or BufferWithTime alone)",
+        "Sets count=100 and duration=5*time.Second",
+        "Chains with Map or MapErr to process the batch (e.g., database write)",
+        "Explains why both conditions matter: count prevents huge batches, time prevents stale data"
+      ]
+    },
+    {
+      "id": 17,
+      "name": "unicast-subject-queue",
+      "prompt": "I need a job queue where a producer pushes tasks and exactly one consumer processes them. The queue should buffer tasks if the consumer is slow. Which samber/ro Subject should I use?",
+      "assertions": [
+        "Recommends UnicastSubject (not PublishSubject or ReplaySubject)",
+        "Shows NewUnicastSubject[Task](bufferSize) with an appropriate buffer",
+        "Explains that UnicastSubject allows exactly one subscriber",
+        "Explains that it buffers values before the subscriber connects",
+        "Does NOT recommend PublishSubject (allows multiple subscribers, no buffering for pre-subscribe values)"
+      ]
+    },
+    {
+      "id": 18,
+      "name": "share-vs-sharereplay",
+      "prompt": "I'm using Share() on an HTTP request observable in samber/ro. But late subscribers don't receive the response that was already fetched. How do I fix this?",
+      "assertions": [
+        "Recommends ShareReplay(1) instead of Share()",
+        "Explains that Share() doesn't buffer — late subscribers only see future emissions",
+        "Explains that ShareReplay(n) buffers the last N values for late subscribers",
+        "Shows the correct syntax: ro.ShareReplay[T](1)"
+      ]
+    },
+    {
+      "id": 19,
+      "name": "error-recovery-cascade",
+      "prompt": "I need a resilient data pipeline in samber/ro: first retry transient failures 2 times, then try a secondary data source, and if everything fails, return a cached default. Write the error recovery chain.",
+      "assertions": [
+        "Chains recovery operators in the correct order: RetryWithConfig FIRST, then Catch/OnErrorResumeNextWith, then OnErrorReturn",
+        "Uses RetryWithConfig with Max: 2 (not infinite Retry)",
+        "Uses Catch or OnErrorResumeNextWith to switch to the secondary source",
+        "Uses OnErrorReturn for the final cached default",
+        "Orders the operators correctly in the Pipe chain (retry → fallback source → default value)"
+      ]
+    },
+    {
+      "id": 20,
+      "name": "observable-creation-channel-bridge-completion",
+      "prompt": "I'm bridging a legacy Go chan Event into a samber/ro pipeline. I've wrapped it with ro.FromChannel. Now my pipeline's onComplete callback never fires even though I've processed all the events I care about. The channel stays open because the legacy service never closes it. How do I make the pipeline complete cleanly after processing 100 events, without modifying the legacy channel producer?",
+      "assertions": [
+        "Uses ro.Take(100) to limit the observable to 100 events and trigger completion",
+        "Explains that ro.FromChannel only completes when the source channel is closed",
+        "Does NOT suggest modifying the channel producer or closing the channel externally",
+        "Does NOT suggest polling the channel manually outside the ro pipeline",
+        "Alternatively mentions TakeUntil with a signal or Timeout as other valid completion strategies"
+      ]
+    },
+    {
+      "id": 21,
+      "name": "tap-for-observability",
+      "prompt": "I have a production samber/ro pipeline and I need to add logging at each stage without modifying the data flow. How should I instrument it?",
+      "assertions": [
+        "Uses Tap or TapOnNext/TapOnError/TapOnComplete for side-effect logging",
+        "Does NOT use Map with a side effect (which would change the return type signature)",
+        "Shows TapOnError for monitoring errors specifically",
+        "Explains that Tap/Do operators observe without altering the stream",
+        "Mentions the logging plugins (slog, zap, etc.) as structured alternatives"
+      ]
+    },
+    {
+      "id": 22,
+      "name": "connectable-precise-control",
+      "prompt": "I need to set up 5 subscribers to a shared samber/ro observable, but I don't want the stream to start until ALL subscribers are connected. Share() starts on first subscribe. What should I use instead?",
+      "assertions": [
+        "Recommends Connectable (not Share or ShareReplay)",
+        "Shows ro.Connectable[T](source) to create a ConnectableObservable",
+        "Shows setting up all 5 subscribers before calling .Connect(ctx)",
+        "Explains that Connect() explicitly starts the shared execution",
+        "Explains why Share() is wrong: it starts on first subscribe, so sub2-5 might miss early events"
+      ]
+    },
+    {
+      "id": 23,
+      "name": "flatmap-vs-map-nested",
+      "prompt": "I have a stream of user IDs and for each ID I need to fetch their orders from an API (which returns an Observable[Order]). If I use Map, I get Observable[Observable[Order]]. How do I flatten this in samber/ro?",
+      "assertions": [
+        "Recommends FlatMap (or MergeMap) instead of Map + manual flatten",
+        "Shows ro.FlatMap(func(id int) Observable[Order] { return fetchOrders(id) })",
+        "Explains that FlatMap maps each value to an Observable and flattens the results",
+        "Does NOT suggest Map followed by MergeAll as the primary approach (FlatMap is idiomatic)"
+      ]
+    },
+    {
+      "id": 24,
+      "name": "async-subject-final-result",
+      "prompt": "I have a long computation that produces intermediate results but I only care about the final result. Which samber/ro Subject captures just the last emitted value and delivers it only after completion?",
+      "assertions": [
+        "Recommends AsyncSubject",
+        "Shows `NewAsyncSubject[T]()` constructor",
+        "Explains that AsyncSubject emits only the last value and only upon completion",
+        "Does NOT recommend BehaviorSubject (which emits on every new subscription, not just on complete)",
+        "Does NOT recommend ReplaySubject(1) (which replays immediately, not waiting for completion)"
+      ]
+    },
+    {
+      "id": 25,
+      "name": "version-stability-warning",
+      "prompt": "I'm evaluating samber/ro for a production microservice. Are there any stability concerns I should know about?",
+      "assertions": [
+        "Mentions that samber/ro is at v0.x (pre-v1.0.0)",
+        "Warns about potential breaking changes before v1",
+        "Mentions that the library follows SemVer",
+        "Does NOT present the library as fully stable/production-ready without caveats"
+      ]
+    }
+  ]
+}
\ No newline at end of file
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/operators-guide.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/operators-guide.md
new file mode 100644
index 00000000..b49fb46b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/operators-guide.md
@@ -0,0 +1,324 @@
+# Operators Guide
+
+samber/ro provides 150+ operators organized by category. All operators are generic functions that take and return `Observable[T]`, designed for chaining via `Pipe`.
+
+## Pipeline Construction
+
+```go
+// Typed pipes (Pipe1 through Pipe25) — compile-time type safety
+result := ro.Pipe2(source, op1, op2)
+result := ro.Pipe3(source, op1, op2, op3)
+
+// Untyped pipe — uses any, loses type checking
+result := ro.Pipe(source, op1, op2, op3)
+
+// Reusable operator composition (curried)
+transform := ro.PipeOp2(op1, op2) // returns func(Observable[A]) Observable[C]
+result := transform(source)
+
+// Synchronous collection
+values, err := ro.Collect(observable)
+```
+
+## Creation Operators
+
+Create observables from various sources. Typically the first argument to `Pipe`.
+
+| Operator | Signature | Purpose |
+| --- | --- | --- |
+| `Just` | `Just[T](values ...T) Observable[T]` | Emit specific values then complete |
+| `Of` | `Of[T](values ...T) Observable[T]` | Alias for Just |
+| `FromSlice` | `FromSlice[T](items []T) Observable[T]` | Create from existing slice |
+| `FromChannel` | `FromChannel[T](ch <-chan T) Observable[T]` | Wrap Go channel as observable |
+| `Range` | `Range(start, end int) Observable[int]` | Emit integer sequence |
+| `RangeWithStep` | `RangeWithStep(start, end, step int) Observable[int]` | Integer sequence with custom step |
+| `RangeWithInterval` | `RangeWithInterval(start, end int, d time.Duration) Observable[int]` | Integers with delay between each |
+| `RangeWithStepAndInterval` | `RangeWithStepAndInterval(start, end, step int, d time.Duration) Observable[int]` | Step + interval combined |
+| `Interval` | `Interval(d time.Duration) Observable[int64]` | Emit sequential integers at intervals (infinite) |
+| `IntervalWithInitial` | `IntervalWithInitial(initial, d time.Duration) Observable[int64]` | Interval with initial delay |
+| `Timer` | `Timer(d time.Duration) Observable[int64]` | Single emission after delay |
+| `Repeat` | `Repeat[T](item T, count int64) Observable[T]` | Repeat item N times |
+| `RepeatWithInterval` | `RepeatWithInterval[T](item T, count int64, d time.Duration) Observable[T]` | Repeat with delay |
+| `Defer` | `Defer[T](factory func() Observable[T]) Observable[T]` | Lazily create observable on subscription |
+| `Future` | `Future[T](factory func() (T, error)) Observable[T]` | Single async value from function |
+| `Start` | `Start(cb func() (any, error)) Observable[any]` | Execute callback and emit result |
+| `Empty` | `Empty[T]() Observable[T]` | Complete immediately, no values |
+| `Never` | `Never[T]() Observable[T]` | Never emit or complete |
+| `Throw` | `Throw[T](err error) Observable[T]` | Immediately error |
+
+```go
+// Custom observable with direct control
+obs := ro.NewObservable[int](func(ctx context.Context, observer ro.Observer[int]) error {
+    observer.Next(1)
+    observer.Next(2)
+    observer.Complete()
+    return nil
+})
+```
+
+## Transformation Operators
+
+Transform each value in the stream.
+
+| Operator | Purpose |
+| --- | --- |
+| `Map[T, R](fn func(T) R)` | Transform each value T -> R |
+| `MapI[T, R](fn func(T, int64) R)` | Map with index |
+| `MapErr[T, R](fn func(T) (R, error))` | Map that can fail — error propagates |
+| `MapWithContext[T, R](fn func(ctx, T) (ctx, R))` | Map with context access |
+| `MapTo[T, R](output R)` | Replace all values with a constant |
+| `FlatMap[T, R](fn func(T) Observable[R])` | Map each value to observable, flatten results |
+| `MergeMap[T, R](fn func(T) Observable[R])` | Alias for FlatMap |
+| `Scan[T, R](fn func(R, T) R, seed R)` | Running accumulation, emit each intermediate |
+| `Reduce[T, R](fn func(R, T) R, seed R)` | Accumulate, emit only final result |
+| `GroupBy[T, K](fn func(T) K)` | Partition into grouped observables by key |
+| `Cast[T, U]()` | Type cast values |
+| `Flatten[T]()` | Flatten `Observable[[]T]` to `Observable[T]` |
+| `Materialize[T]()` | Wrap values in `Notification[T]` (next/error/complete) |
+| `Dematerialize[T]()` | Unwrap `Notification[T]` back to values |
+| `Timestamp[T]()` | Emit `TimestampValue[T]` with emission time |
+| `TimeInterval[T]()` | Emit `IntervalValue[T]` with time since last emission |
+
+```go
+// FlatMap: for each user ID, fetch their orders (returns observable)
+orders := ro.Pipe2(
+    userIDs,
+    ro.FlatMap(func(id int) ro.Observable[Order] {
+        return fetchOrders(id)
+    }),
+    ro.Filter(func(o Order) bool { return o.Status == "paid" }),
+)
+
+// Scan: running sum
+ro.Pipe1(
+    ro.Just(1, 2, 3, 4, 5),
+    ro.Scan(func(acc, x int) int { return acc + x }, 0),
+)
+// Emits: 1, 3, 6, 10, 15
+```
+
+## Filtering Operators
+
+Selectively emit values from the stream.
+
+| Operator | Purpose |
+| --- | --- |
+| `Filter[T](fn func(T) bool)` | Emit only values matching predicate |
+| `FilterI[T](fn func(T, int64) bool)` | Filter with index |
+| `FilterWithContext[T](fn func(ctx, T) (ctx, bool))` | Filter with context access |
+| `Distinct[T comparable]()` | Emit only unique values |
+| `DistinctBy[T, K](fn func(T) K)` | Unique by key function |
+| `Take[T](n int64)` | Emit first N values then complete |
+| `TakeLast[T](n int)` | Emit last N values |
+| `TakeWhile[T](fn func(T) bool)` | Emit while predicate true, then complete |
+| `TakeUntil[T, S](signal Observable[S])` | Emit until signal observable emits |
+| `Skip[T](n int64)` | Skip first N values |
+| `SkipLast[T](n int)` | Skip last N values |
+| `SkipWhile[T](fn func(T) bool)` | Skip while predicate true |
+| `SkipUntil[T, S](signal Observable[S])` | Skip until signal emits |
+| `Head[T]()` | First item only |
+| `Tail[T]()` | All items except first |
+| `ElementAt[T](n int)` | Item at specific index |
+| `ElementAtOrDefault[T](n int64, fallback T)` | Item at index or default |
+| `Find[T](fn func(T) bool)` | First value matching predicate |
+| `First[T](fn func(T) bool)` | First matching value (alias-like) |
+| `Last[T](fn func(T) bool)` | Last matching value |
+| `Contains[T](fn func(T) bool)` | Emit bool: whether any value matches |
+
+All filtering operators have `I` (indexed), `WithContext`, and `IWithContext` variants.
+
+## Combining Operators
+
+Merge multiple observables into one.
+
+| Operator | Purpose |
+| --- | --- |
+| `Merge[T](sources ...Observable[T])` | Interleave emissions from all sources |
+| `MergeWith[T](obs ...Observable[T])` | Chainable merge |
+| `MergeAll[T]()` | Flatten `Observable[Observable[T]]` by merging |
+| `Concat[T](obs ...Observable[T])` | Sequential: complete first, then start second |
+| `ConcatWith[T](obs ...Observable[T])` | Chainable concat |
+| `ConcatAll[T]()` | Flatten by concatenating sequentially |
+| `Zip2[A, B](a, b)` | Pair values from 2 sources into `lo.Tuple2` |
+| `Zip3` ... `Zip6` | Zip 3-6 sources into corresponding `lo.Tuple` |
+| `ZipWith[A, B](obsB)` | Chainable zip |
+| `CombineLatest2[A, B](a, b)` | Emit combined latest when either source emits |
+| `CombineLatest3` ... `CombineLatest5` | Combine 3-5 sources |
+| `CombineLatestWith[A, B](obsB)` | Chainable combine-latest |
+| `Race[T](sources ...Observable[T])` | Emit from whichever source emits first |
+| `Amb[T](sources ...)` | Alias for Race |
+| `StartWith[T](prefixes ...T)` | Prepend values before source emissions |
+| `EndWith[T](suffixes ...T)` | Append values after source completes |
+
+```go
+// Zip: pair user with their settings
+ro.Zip2(userStream, settingsStream)
+// Emits: lo.Tuple2[User, Settings]
+
+// CombineLatest: re-emit whenever either changes
+ro.CombineLatest2(priceStream, quantityStream)
+// Emits latest (price, quantity) pair each time either updates
+```
+
+## Math and Aggregation
+
+| Operator | Purpose |
+| --- | --- |
+| `Count[T]()` | Count of emitted values |
+| `Sum[T Numeric]()` | Sum of all values |
+| `Average[T Numeric]()` | Average as float64 |
+| `Max[T Numeric]()` | Maximum value |
+| `Min[T Numeric]()` | Minimum value |
+| `Abs()` | Absolute value (float64) |
+| `Ceil()` / `Floor()` / `Round()` / `Trunc()` | Rounding (float64) |
+| `CeilWithPrecision(n)` / `FloorWithPrecision(n)` | Rounding with decimal places |
+| `Clamp[T](lower, upper)` | Constrain values to range |
+
+## Error Handling
+
+| Operator | Purpose |
+| --- | --- |
+| `Catch[T](fn func(error) Observable[T])` | Catch error, switch to recovery observable |
+| `OnErrorReturn[T](value T)` | Replace error with fallback value |
+| `OnErrorResumeNextWith[T](obs ...Observable[T])` | Continue with fallback observables on error |
+| `Retry[T]()` | Retry indefinitely on error |
+| `RetryWithConfig[T](cfg RetryConfig)` | Retry with max attempts, delay, backoff |
+| `ThrowIfEmpty[T](fn func() error)` | Error if stream completes empty |
+
+```go
+// RetryConfig for exponential backoff
+ro.RetryWithConfig[Response](ro.RetryConfig{
+    Max:               3,
+    Delay:             time.Second,
+    BackoffMultiplier: 2.0,
+    MaxDelay:          10 * time.Second,
+})
+```
+
+## Timing and Buffering
+
+| Operator | Purpose |
+| --- | --- |
+| `Delay[T](d time.Duration)` | Delay entire stream |
+| `DelayEach[T](d time.Duration)` | Delay between each emission |
+| `Timeout[T](d time.Duration)` | Error if no emission within duration |
+| `ThrottleTime[T](d time.Duration)` | Ignore values within duration of last |
+| `ThrottleWhen[T, t](tick Observable[t])` | Throttle by signal |
+| `SampleTime[T](d time.Duration)` | Emit latest value at intervals |
+| `SampleWhen[T, t](tick Observable[t])` | Sample by signal |
+| `BufferWithCount[T](n int)` | Collect N items, emit as `[]T` |
+| `BufferWithTime[T](d time.Duration)` | Collect within time window |
+| `BufferWithTimeOrCount[T](n, d)` | Buffer with either condition |
+| `BufferWhen[T, B](boundary Observable[B])` | Buffer until signal |
+| `WindowWhen[T, B](boundary Observable[B])` | Window as nested observables |
+| `Pairwise[T]()` | Emit consecutive pairs |
+
+## Side Effects (Tap / Do)
+
+Execute code without changing the stream. `Do` is an alias for `Tap`.
+
+| Operator                              | Purpose                     |
+| ------------------------------------- | --------------------------- |
+| `Tap[T](onNext, onError, onComplete)` | Side effect on all events   |
+| `TapOnNext[T](fn func(T))`            | Side effect on values       |
+| `TapOnError[T](fn func(error))`       | Side effect on errors       |
+| `TapOnComplete[T](fn func())`         | Side effect on completion   |
+| `TapOnSubscribe[T](fn func())`        | Side effect on subscription |
+| `TapOnFinalize[T](fn func())`         | Side effect on teardown     |
+
+All have `WithContext` variants. `Do`, `DoOnNext`, `DoOnError`, `DoOnComplete`, `DoOnSubscribe`, `DoOnFinalize` are aliases.
+
+## Connectable and Sharing
+
+| Operator | Purpose |
+| --- | --- |
+| `Share[T]()` | Cold -> hot with reference counting |
+| `ShareWithConfig[T](cfg ShareConfig[T])` | Share with reset options |
+| `ShareReplay[T](bufferSize int)` | Share + replay last N values to late subscribers |
+| `ShareReplayWithConfig[T](n, cfg)` | ShareReplay with reset options |
+| `Serialize[T]()` | Queue emissions to ensure serial delivery |
+
+```go
+// ShareConfig controls lifecycle reset
+ro.ShareConfig[T]{
+    ResetOnComplete:       true,  // re-subscribe on complete
+    ResetOnError:          true,  // re-subscribe on error
+    ResetOnReferenceCount: true,  // re-subscribe when count drops to 0
+}
+```
+
+## Context Operators
+
+| Operator                                 | Purpose                         |
+| ---------------------------------------- | ------------------------------- |
+| `ContextReset[T](ctx context.Context)`   | Replace pipeline context        |
+| `ContextWithValue[T](key, value any)`    | Add value to context            |
+| `ContextWithTimeout[T](d time.Duration)` | Add timeout                     |
+| `ContextWithDeadline[T](t time.Time)`    | Add deadline                    |
+| `ContextMap[T](fn func(ctx) ctx)`        | Transform context               |
+| `ThrowOnContextCancel[T]()`              | Error when context is cancelled |
+
+## Conditional Operators
+
+| Operator | Purpose |
+| --- | --- |
+| `All[T](fn func(T) bool)` | Emit bool: whether all values match |
+| `DefaultIfEmpty[T](value T)` | Emit default if source completes empty |
+| `ThrowIfEmpty[T](fn func() error)` | Error if empty |
+| `Iif[T](pred func() bool, a, b Observable[T])` | Choose between two observables |
+| `While[T](cond func() bool)` | Repeat while condition true |
+| `DoWhile[T](cond func() bool)` | Execute at least once, repeat while true |
+| `SequenceEqual[T](obsB Observable[T])` | Emit bool: whether two streams match |
+
+## Terminal Operators
+
+| Operator | Purpose |
+| --- | --- |
+| `Collect[T](obs Observable[T]) ([]T, error)` | Block, return all values as slice |
+| `CollectWithContext[T](ctx, obs) ([]T, ctx, error)` | Collect with context |
+| `ToSlice[T]()` | Operator: emit `[]T` on complete |
+| `ToChannel[T](size int)` | Convert to `<-chan Notification[T]` |
+| `ToMap[T, K, V](fn func(T) (K, V))` | Collect into map |
+
+## Observer and Subscription
+
+```go
+// Full observer (recommended)
+observer := ro.NewObserver[T](onNext, onError, onComplete)
+
+// Context-aware observer
+observer := ro.NewObserverWithContext[T](onNext, onError, onComplete)
+
+// Convenience shortcuts
+observer := ro.OnNext[T](func(v T) { ... })
+observer := ro.PrintObserver[T]()  // debug: prints all events
+observer := ro.NoopObserver[T]()   // discard all events
+
+// Subscription lifecycle
+sub := observable.Subscribe(observer)
+sub.Wait()          // block until complete or error
+sub.Unsubscribe()   // cancel and cleanup
+sub.IsActive()      // check if still running
+sub.GetError()      // get terminal error
+```
+
+## Scheduling
+
+| Operator                         | Purpose                                  |
+| -------------------------------- | ---------------------------------------- |
+| `SubscribeOn[T](bufferSize int)` | Run subscription on async scheduler      |
+| `ObserveOn[T](bufferSize int)`   | Deliver notifications on async scheduler |
+
+## Concurrency Modes
+
+```go
+// Safe (default): synchronized emissions
+ro.NewObservable[T](fn)
+ro.NewSafeObservable[T](fn)
+
+// Unsafe: no synchronization, caller must guarantee single-goroutine access
+ro.NewUnsafeObservable[T](fn)
+
+// Eventually safe: allows brief unsynchronized period, then synchronizes
+ro.NewEventuallySafeObservable[T](fn)
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/patterns.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/patterns.md
new file mode 100644
index 00000000..70dd32ab
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/patterns.md
@@ -0,0 +1,259 @@
+# Reactive Patterns
+
+Real-world patterns for building production reactive pipelines with samber/ro.
+
+## Pattern 1: Remote Call with Retry and Timeout
+
+Wrap a remote call (HTTP, gRPC, database) with automatic retry, exponential backoff, timeout, and fallback.
+
+```go
+result := ro.Pipe3(
+    fetchUser(userID),  // ro.Observable[User] — wraps your remote call
+    ro.Timeout[User](5*time.Second),
+    ro.RetryWithConfig[User](ro.RetryConfig{
+        Max:               3,
+        Delay:             500 * time.Millisecond,
+        BackoffMultiplier: 2.0,
+        MaxDelay:          5 * time.Second,
+    }),
+    ro.Catch[User](func(err error) ro.Observable[User] {
+        log.Printf("remote call failed after retries: %v, using cache", err)
+        return getCachedUser(userID)
+    }),
+)
+
+user, err := ro.Collect(result)
+```
+
+**Why ro over plain calls:** declarative retry + timeout + fallback in 10 lines vs manual for-loops with sleep, context, and error tracking.
+
+## Pattern 2: Continuous Event Stream (Hot Observable)
+
+Share a single long-lived connection (WebSocket, SSE, message queue) across multiple consumers.
+
+```go
+// Cold observable wrapping any event stream source
+eventStream := ro.NewObservable[TickerEvent](func(ctx context.Context, obs ro.Observer[TickerEvent]) error {
+    // connect to your stream source (WebSocket, NATS, Kafka, etc.)
+    for {
+        event, err := streamSource.Read(ctx)
+        if err != nil {
+            return err
+        }
+        obs.Next(event)
+    }
+})
+
+// Share: one connection, multiple consumers
+shared := ro.Pipe1(eventStream, ro.Share[TickerEvent]())
+
+// Consumer 1: update UI
+shared.Subscribe(ro.OnNext(func(e TickerEvent) {
+    updateDashboard(e)
+}))
+
+// Consumer 2: record metrics
+shared.Subscribe(ro.OnNext(func(e TickerEvent) {
+    metrics.RecordTick(e.Symbol, e.Price)
+}))
+
+// Consumer 3: alert on threshold
+ro.Pipe1(shared, ro.Filter(func(e TickerEvent) bool {
+    return e.Price > alertThreshold
+})).Subscribe(ro.OnNext(sendAlert))
+```
+
+The `rohttp` plugin provides WebSocket and HTTP streaming observables (see [Plugin Ecosystem](./plugin-ecosystem.md)).
+
+## Pattern 3: Fan-In from Multiple Sources
+
+Merge events from multiple independent sources, batch, and process.
+
+```go
+combined := ro.Pipe2(
+    ro.Merge(
+        apiStream,
+        pushStream,
+        cronScheduleStream,
+    ),
+    ro.Distinct[Event](),
+    ro.BufferWithTimeOrCount[Event](100, 5*time.Second),
+    ro.Map(func(batch []Event) ProcessResult {
+        return processBatch(batch)
+    }),
+)
+```
+
+**When to use Merge vs Concat vs Zip:**
+
+| Operator | Behavior | Use when |
+| --- | --- | --- |
+| `Merge` | Interleave: emit from any source as it arrives | Independent streams, order doesn't matter |
+| `Concat` | Sequential: finish first source, then start second | Ordered processing, fallback chains |
+| `Zip` | Pair: wait for one value from each source | Correlated data (user + settings, request + response) |
+| `CombineLatest` | Latest: re-emit combined whenever any source changes | Dependent state (price \* quantity, config + data) |
+
+## Pattern 4: Dependent Data Combination
+
+Combine data from multiple async sources that depend on each other.
+
+```go
+// Fetch user and their orders in parallel, combine
+profile := ro.Pipe1(
+    ro.CombineLatest2(
+        fetchUser(userID),
+        fetchOrders(userID),
+    ),
+    ro.Map(func(pair lo.Tuple2[User, []Order]) UserProfile {
+        return UserProfile{
+            User:   pair.A,
+            Orders: pair.B,
+        }
+    }),
+)
+```
+
+For independent data where you need exactly one value from each:
+
+```go
+// Zip: waits for one value from each, pairs them
+configAndData := ro.Zip2(loadConfig(), loadData())
+```
+
+## Pattern 5: Running Aggregation with Scan
+
+Maintain running state across stream values — useful for dashboards, analytics, monitoring.
+
+```go
+type Stats struct {
+    Count int
+    Sum   float64
+    Avg   float64
+    Max   float64
+}
+
+statsStream := ro.Pipe2(
+    metricsStream,
+    ro.Scan(func(acc Stats, v float64) Stats {
+        acc.Count++
+        acc.Sum += v
+        acc.Avg = acc.Sum / float64(acc.Count)
+        if v > acc.Max {
+            acc.Max = v
+        }
+        return acc
+    }, Stats{}),
+    ro.SampleTime[Stats](5*time.Second), // emit stats every 5s
+)
+```
+
+**Scan vs Reduce:** `Scan` emits every intermediate state (good for live dashboards). `Reduce` emits only the final accumulated value (good for batch summaries).
+
+## Pattern 6: Error Recovery Cascade
+
+Layer multiple error recovery strategies.
+
+```go
+resilient := ro.Pipe3(
+    primaryDataSource,
+    // Strategy 1: retry transient failures
+    ro.RetryWithConfig[Data](ro.RetryConfig{
+        Max:   2,
+        Delay: time.Second,
+    }),
+    // Strategy 2: fall back to secondary source
+    ro.Catch[Data](func(err error) ro.Observable[Data] {
+        log.Warn("primary failed, trying secondary", "err", err)
+        return secondaryDataSource
+    }),
+    // Strategy 3: return cached/default value
+    ro.OnErrorReturn[Data](cachedDefault),
+)
+```
+
+**Order matters:** retry first (transient errors), then fallback source (persistent errors), then default value (total failure).
+
+## Pattern 7: File System Watcher
+
+React to file changes with debouncing.
+
+```go
+import rofsnotify "github.com/samber/ro/plugins/fsnotify"
+
+watcher := ro.Pipe3(
+    rofsnotify.Watch("/etc/app/config/"),
+    ro.Filter(func(e fsnotify.Event) bool {
+        return e.Op&fsnotify.Write != 0
+    }),
+    ro.ThrottleTime[fsnotify.Event](2*time.Second), // debounce rapid saves
+    ro.Map(func(e fsnotify.Event) Config {
+        return reloadConfig(e.Name)
+    }),
+)
+
+watcher.Subscribe(ro.NewObserver(
+    func(cfg Config) { applyConfig(cfg) },
+    func(err error) { log.Error("config watch failed", "err", err) },
+    func() { log.Info("config watcher stopped") },
+))
+```
+
+## Pattern 8: Graceful Shutdown
+
+Use context or signal observable to cleanly terminate infinite streams.
+
+```go
+import rosignal "github.com/samber/ro/plugins/signal"
+
+// Method 1: OS signal
+shutdown := rosignal.Notify(syscall.SIGTERM, syscall.SIGINT)
+
+sub := ro.Pipe1(
+    workStream,
+    ro.TakeUntil[Work, os.Signal](shutdown),
+).Subscribe(ro.NewObserver(
+    processWork,
+    handleError,
+    func() { log.Info("gracefully stopped") },
+))
+
+sub.Wait() // blocks until SIGTERM/SIGINT
+
+// Method 2: Context cancellation
+ctx, cancel := context.WithCancel(context.Background())
+
+sub := ro.Pipe2(
+    workStream,
+    ro.ContextReset[Work](ctx),
+    ro.ThrowOnContextCancel[Work](),
+).Subscribe(worker)
+
+// Later: cancel() triggers clean shutdown
+```
+
+## Pattern 9: Event-Driven Pipeline with Logging
+
+Full production pipeline with observability at each stage.
+
+```go
+import roslog "github.com/samber/ro/plugins/observability/slog"
+
+pipeline := ro.Pipe5(
+    eventSource,
+    ro.TapOnSubscribe[Event](func() {
+        slog.Info("pipeline started")
+    }),
+    ro.Filter(func(e Event) bool { return e.Valid() }),
+    roslog.TapOnNext[Event](logger, slog.LevelDebug), // log each event
+    ro.Map(enrichEvent),
+    ro.BufferWithTimeOrCount[EnrichedEvent](50, 10*time.Second),
+    ro.MapErr(func(batch []EnrichedEvent) (Result, error) {
+        return persistBatch(batch)
+    }),
+    ro.TapOnError[Result](func(err error) {
+        slog.Error("pipeline error", "err", err)
+        metrics.IncrCounter("pipeline.errors", 1)
+    }),
+    ro.RetryWithConfig[Result](ro.RetryConfig{Max: 3, Delay: time.Second}),
+)
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/plugin-ecosystem.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/plugin-ecosystem.md
new file mode 100644
index 00000000..109468d2
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/plugin-ecosystem.md
@@ -0,0 +1,152 @@
+# Plugin Ecosystem
+
+samber/ro ships 40+ plugins that extend the core library with domain-specific operators. Plugins are separate Go modules — install only what you need.
+
+```bash
+go get github.com/samber/ro/plugins/<category>/<name>
+```
+
+## Data Manipulation
+
+| Plugin | Import | Purpose |
+| --- | --- | --- |
+| Bytes | `plugins/bytes` | Byte slice operations on streams |
+| Strings | `plugins/strings` | String transformations (split, trim, join) |
+| Sort | `plugins/sort` | Sorting operators for ordered streams |
+| Strconv | `plugins/strconv` | Type conversion (string <-> numeric) |
+| Iter | `plugins/iter` | Go 1.23+ iterator interop |
+| SIMD (experimental) | `plugins/exp/simd` | SIMD-accelerated numeric transforms |
+
+## Encoding and Serialization
+
+| Plugin | Import                    | Purpose                          |
+| ------ | ------------------------- | -------------------------------- |
+| JSON   | `plugins/encoding/json`   | Marshal/unmarshal JSON in stream |
+| CSV    | `plugins/encoding/csv`    | Parse/generate CSV rows          |
+| Base64 | `plugins/encoding/base64` | Encode/decode Base64             |
+| Gob    | `plugins/encoding/gob`    | Go binary encoding               |
+
+```go
+import rojson "github.com/samber/ro/plugins/encoding/json"
+
+// Parse JSON stream: []byte -> MyStruct
+parsed := ro.Pipe1(rawBytes, rojson.Unmarshal[MyStruct]())
+```
+
+## Scheduling
+
+| Plugin | Import         | Purpose                               |
+| ------ | -------------- | ------------------------------------- |
+| Cron   | `plugins/cron` | Emit on cron expressions or intervals |
+| ICS    | `plugins/ics`  | Parse iCal files into event streams   |
+
+```go
+import rocron "github.com/samber/ro/plugins/cron"
+
+// Emit every day at midnight
+daily := rocron.Schedule("0 0 * * *")
+```
+
+## Network and I/O
+
+| Plugin   | Import             | Purpose                                  |
+| -------- | ------------------ | ---------------------------------------- |
+| HTTP     | `plugins/http`     | HTTP request operators (GET, POST, etc.) |
+| I/O      | `plugins/io`       | File and stream reading/writing          |
+| FSNotify | `plugins/fsnotify` | File system change events                |
+
+```go
+import rofsnotify "github.com/samber/ro/plugins/fsnotify"
+
+// Watch directory for changes
+events := rofsnotify.Watch("/var/log/app/")
+ro.Pipe1(events, ro.Filter(func(e fsnotify.Event) bool {
+    return e.Op == fsnotify.Write
+})).Subscribe(ro.OnNext(func(e fsnotify.Event) {
+    log.Println("Modified:", e.Name)
+}))
+```
+
+## Observability and Logging
+
+| Plugin  | Import                          | Purpose                         |
+| ------- | ------------------------------- | ------------------------------- |
+| Log     | `plugins/observability/log`     | stdlib `log` integration        |
+| Zap     | `plugins/observability/zap`     | Uber Zap structured logging     |
+| Logrus  | `plugins/observability/logrus`  | Logrus logging                  |
+| Slog    | `plugins/observability/slog`    | Go 1.21+ `log/slog` integration |
+| Zerolog | `plugins/observability/zerolog` | Zerolog logging                 |
+| Sentry  | `plugins/observability/sentry`  | Sentry error tracking           |
+| Oops    | `plugins/samber/oops`           | samber/oops structured errors   |
+
+```go
+import roslog "github.com/samber/ro/plugins/observability/slog"
+
+// Log all stream events via slog
+ro.Pipe1(
+    dataStream,
+    roslog.Tap[Data](logger, slog.LevelInfo),
+)
+```
+
+## Rate Limiting
+
+| Plugin | Import                     | Purpose                            |
+| ------ | -------------------------- | ---------------------------------- |
+| Native | `plugins/ratelimit/native` | Built-in token bucket rate limiter |
+| Ulule  | `plugins/ratelimit/ulule`  | ulule/limiter integration          |
+
+## Text Processing
+
+| Plugin   | Import             | Purpose                              |
+| -------- | ------------------ | ------------------------------------ |
+| Regexp   | `plugins/regexp`   | Regex matching/extraction on streams |
+| Template | `plugins/template` | Go text/html template rendering      |
+
+## System Integration
+
+| Plugin  | Import           | Purpose                                    |
+| ------- | ---------------- | ------------------------------------------ |
+| Process | `plugins/proc`   | Process execution operators                |
+| Signal  | `plugins/signal` | OS signal handling (SIGTERM, SIGINT, etc.) |
+
+```go
+import rosignal "github.com/samber/ro/plugins/signal"
+
+// Observable that emits on SIGTERM/SIGINT
+shutdown := rosignal.Notify(syscall.SIGTERM, syscall.SIGINT)
+
+// Use as TakeUntil signal for graceful shutdown
+ro.Pipe1(workStream, ro.TakeUntil[Work, os.Signal](shutdown))
+```
+
+## Validation
+
+| Plugin | Import | Purpose |
+| --- | --- | --- |
+| Ozzo Validation | `plugins/ozzo/ozzo-validation` | Stream-level input validation |
+
+## Testing
+
+| Plugin  | Import            | Purpose                                |
+| ------- | ----------------- | -------------------------------------- |
+| Testify | `plugins/testify` | Test assertions for observable streams |
+
+## Utilities
+
+| Plugin      | Import                | Purpose                                |
+| ----------- | --------------------- | -------------------------------------- |
+| HyperLogLog | `plugins/hyperloglog` | Cardinality estimation on streams      |
+| Hot         | `plugins/samber/hot`  | In-memory caching integration          |
+| PSI         | `plugins/samber/psi`  | Starvation notifier / pressure metrics |
+
+## Plugin Design Convention
+
+All plugins follow the same pattern:
+
+1. Import the plugin package
+2. Use plugin-provided operators in `Pipe` chains
+3. Plugin operators return `func(Observable[T]) Observable[R]` — standard operator signature
+4. No global state — each operator instance is independent
+
+Plugins are documented individually in their package directories. API details for each plugin are available at `pkg.go.dev/github.com/samber/ro/plugins/...`.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/subjects-guide.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/subjects-guide.md
new file mode 100644
index 00000000..7f087dff
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-ro/references/subjects-guide.md
@@ -0,0 +1,183 @@
+# Subjects Guide
+
+Subjects are both Observable and Observer — they can receive values (via `Send`, `Error`, `Complete`) and be subscribed to. Subjects are natively **hot**: subscribers share a single execution, and late subscribers only see future emissions (unless replay is configured).
+
+## When to Use Subjects vs Cold Observables
+
+| Use case | Approach |
+| --- | --- |
+| Data pipeline from a known source (slice, channel, HTTP) | Cold observable (default) |
+| Event bus where producers and consumers are decoupled | Subject |
+| Multiple consumers need the same WebSocket/ticker stream | Cold observable + `Share()` or `ShareReplay()` |
+| Imperatively push values from non-reactive code | Subject |
+| Bridge between callback API and reactive pipeline | Subject (receive callbacks, emit to pipeline) |
+
+## Subject Types
+
+### PublishSubject
+
+Standard multicast. Subscribers only see values emitted **after** they subscribe.
+
+```go
+subject := ro.NewPublishSubject[string]()
+
+// Subscriber 1
+subject.Subscribe(ro.OnNext(func(s string) {
+    fmt.Println("sub1:", s)
+}))
+
+subject.Send("hello")  // sub1 sees this
+
+// Subscriber 2 (late)
+subject.Subscribe(ro.OnNext(func(s string) {
+    fmt.Println("sub2:", s)
+}))
+
+subject.Send("world")  // both see this
+subject.Complete()
+```
+
+**Use when:** broadcasting events where late subscribers don't need history — UI events, log streams, notifications.
+
+### BehaviorSubject
+
+Replays the **last emitted value** (or the initial value) to every new subscriber immediately on subscription.
+
+```go
+subject := ro.NewBehaviorSubject[int](0) // initial value = 0
+
+// Subscriber 1 immediately receives 0
+subject.Subscribe(ro.OnNext(func(v int) {
+    fmt.Println("sub1:", v) // 0, then 42
+}))
+
+subject.Send(42)
+
+// Subscriber 2 immediately receives 42 (latest value)
+subject.Subscribe(ro.OnNext(func(v int) {
+    fmt.Println("sub2:", v) // 42
+}))
+```
+
+**Use when:** subscribers need the current state — config values, connection status, latest price.
+
+### ReplaySubject
+
+Buffers the last **N values** and replays them to every new subscriber.
+
+```go
+subject := ro.NewReplaySubject[string](3) // buffer size = 3
+
+subject.Send("a")
+subject.Send("b")
+subject.Send("c")
+subject.Send("d") // "a" evicted from buffer
+
+// Late subscriber receives "b", "c", "d" (last 3)
+subject.Subscribe(ro.OnNext(func(s string) {
+    fmt.Println(s)
+}))
+```
+
+**Use when:** late subscribers need recent history — chat messages, recent logs, last N stock ticks.
+
+### AsyncSubject
+
+Emits **only the last value** and only when the subject completes. If the subject errors, no value is emitted.
+
+```go
+subject := ro.NewAsyncSubject[int]()
+
+subject.Subscribe(ro.NewObserver(
+    func(v int) { fmt.Println(v) },    // receives 3 only
+    func(err error) { },
+    func() { fmt.Println("done") },
+))
+
+subject.Send(1)
+subject.Send(2)
+subject.Send(3)
+subject.Complete() // triggers emission of 3, then "done"
+```
+
+**Use when:** only the final result matters — computation result, last response in a batch.
+
+### UnicastSubject
+
+Allows exactly **one subscriber**. Buffers values internally until that subscriber connects.
+
+```go
+subject := ro.NewUnicastSubject[int](100) // buffer size
+
+subject.Send(1) // buffered
+subject.Send(2) // buffered
+
+// Single subscriber receives buffered + future values
+subject.Subscribe(ro.OnNext(func(v int) {
+    fmt.Println(v) // 1, 2, then future values
+}))
+// Second subscribe would panic or error
+```
+
+**Use when:** single consumer with buffering — job queues, request pipelines where exactly one handler processes events.
+
+## Cold to Hot Conversion
+
+When you have a cold observable (e.g. an HTTP request) but need multiple subscribers to share it:
+
+### Share
+
+```go
+// Each subscriber to `cold` would trigger a separate HTTP request
+cold := httpPlugin.Get[Data](url)
+
+// Share: single execution, multiple subscribers
+hot := ro.Pipe1(cold, ro.Share[Data]())
+
+hot.Subscribe(uiObserver)       // shares one HTTP call
+hot.Subscribe(metricsObserver)  // same data, no extra request
+```
+
+`Share` uses reference counting: the source subscribes when the first subscriber arrives and unsubscribes when the last one leaves.
+
+### ShareReplay
+
+```go
+// Late subscribers get the last N values + future values
+hot := ro.Pipe1(cold, ro.ShareReplay[Data](1))
+```
+
+### Connectable Observable
+
+For precise control over when the shared subscription starts:
+
+```go
+connectable := ro.Connectable[Data](cold)
+
+// Set up subscribers first
+connectable.Subscribe(observer1)
+connectable.Subscribe(observer2)
+
+// Start the shared execution explicitly
+sub, err := connectable.Connect(ctx)
+```
+
+## Subject Decision Table
+
+| Subject | Replay | Subscribers | Use case |
+| --- | --- | --- | --- |
+| `PublishSubject` | None | Many | Event bus, notifications |
+| `BehaviorSubject` | Last 1 (+ initial) | Many | Current state, config |
+| `ReplaySubject` | Last N | Many | Recent history, chat |
+| `AsyncSubject` | Last 1 (on complete) | Many | Final computation result |
+| `UnicastSubject` | Buffered (pre-subscribe) | Exactly 1 | Single-consumer queue |
+
+## Common Subject Mistakes
+
+| Mistake | Why | Fix |
+| --- | --- | --- |
+| Calling `Send()` after `Complete()` | Values are silently dropped — the subject is terminal | Track lifecycle, don't reuse completed subjects |
+| Using PublishSubject when late subscribers need history | Late subscribers miss all prior events | Use BehaviorSubject (last 1) or ReplaySubject (last N) |
+| Using ReplaySubject with unbounded buffer | Memory grows without limit | Set an explicit `bufferSize` |
+| Multiple subscribers on UnicastSubject | Panics or undefined behavior | Use PublishSubject for multicast, UnicastSubject for single consumer |
+| Not calling `Complete()` on subjects | Subscribers wait forever, goroutine leak | Always `Complete()` or `Error()` when the source is done |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/SKILL.md
new file mode 100644
index 00000000..75b62092
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/SKILL.md
@@ -0,0 +1,228 @@
+---
+name: golang-samber-slog
+description: "Structured logging extensions for Golang using samber/slog-**** packages — multi-handler pipelines (slog-multi), log sampling (slog-sampling), attribute formatting (slog-formatter), HTTP middleware (slog-fiber, slog-gin, slog-chi, slog-echo), and backend routing (slog-datadog, slog-sentry, slog-loki, slog-syslog, slog-logstash, slog-graylog...). Apply when using or adopting slog, or when the codebase already imports any github.com/samber/slog-* package."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.0.4"
+  openclaw:
+    emoji: "🪵"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version:
+      slog-multi: "1.8.0"
+      slog-sampling: "1.6.0"
+      slog-formatter: "1.3.0"
+      slog-fiber: "1.22.1"
+      slog-gin: "1.21.0"
+      slog-chi: "1.19.0"
+      slog-echo: "1.21.0"
+      slog-http: "1.12.0"
+      slog-betterstack: "1.4.4"
+      slog-channel: "1.4.4"
+      slog-datadog: "2.10.4"
+      slog-sentry: "2.10.3"
+      slog-loki: "3.7.2"
+      slog-syslog: "2.5.4"
+      slog-logstash: "2.6.4"
+      slog-graylog: "2.7.5"
+      slog-fluentd: "2.5.4"
+      slog-kafka: "2.6.5"
+      slog-logrus: "2.5.4"
+      slog-zap: "2.6.4"
+      slog-zerolog: "2.9.2"
+      slog-slack: "2.7.5"
+      slog-telegram: "2.4.4"
+      slog-webhook: "2.8.4"
+      slog-mattermost: "2.5.4"
+      slog-microsoft-teams: "2.7.4"
+      slog-nats: "0.4.5"
+      slog-otel: "0.1.0"
+      slog-parquet: "2.5.2"
+      slog-quickwit: "0.3.4"
+      slog-rollbar: "2.7.4"
+      slog-mock: "0.1.0"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs AskUserQuestion
+---
+
+**Persona:** You are a Go logging architect. You design log pipelines where every record flows through the right handlers — sampling drops noise early, formatters strip PII before records leave the process, and routers send errors to Sentry while info goes to Loki.
+
+# samber/slog-\*\*\*\* — Structured Logging Pipeline for Go
+
+20+ composable `slog.Handler` packages for Go 1.21+. Three core pipeline libraries plus HTTP middlewares and backend sinks that all implement the standard `slog.Handler` interface.
+
+**Official resources:**
+
+- [github.com/samber/slog-multi](https://github.com/samber/slog-multi) — handler composition
+- [github.com/samber/slog-sampling](https://github.com/samber/slog-sampling) — throughput control
+- [github.com/samber/slog-formatter](https://github.com/samber/slog-formatter) — attribute transformation
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+## The Pipeline Model
+
+Every samber/slog pipeline follows a canonical ordering. Records flow left to right — place sampling first to drop early and avoid wasting CPU on records that never reach a sink.
+
+```
+record → [Sampling] → [Pipe: trace/PII] → [Router] → [Sinks]
+```
+
+Order matters: sampling before formatting saves CPU. Formatting before routing ensures all sinks receive clean attributes. Reversing this wastes work on records that get dropped.
+
+## Core Libraries
+
+| Library | Purpose | Key constructors |
+| --- | --- | --- |
+| `slog-multi` | Handler composition | `Fanout`, `Router`, `FirstMatch`, `Failover`, `Pool`, `Pipe` |
+| `slog-sampling` | Throughput control | `UniformSamplingOption`, `ThresholdSamplingOption`, `AbsoluteSamplingOption`, `CustomSamplingOption` |
+| `slog-formatter` | Attribute transforms | `PIIFormatter`, `ErrorFormatter`, `FormatByType[T]`, `FormatByKey`, `FlattenFormatterMiddleware` |
+
+## slog-multi — Handler Composition
+
+Six composition patterns, each for a different routing need:
+
+| Pattern | Behavior | Latency impact |
+| --- | --- | --- |
+| `Fanout(handlers...)` | Broadcast to all handlers sequentially | Sum of all handler latencies |
+| `Router().Add(h, predicate).Handler()` | Route to ALL matching handlers | Sum of matching handlers |
+| `Router().Add(...).FirstMatch().Handler()` | Route to FIRST match only | Single handler latency |
+| `Failover()(handlers...)` | Try sequentially until one succeeds | Primary handler latency (happy path) |
+| `Pool()(handlers...)` | Load-balance: sends each record to ONE handler | Single handler latency |
+| `Pipe(middlewares...).Handler(sink)` | Middleware chain before sink | Middleware overhead + sink |
+
+```go
+// Route errors to Sentry, all logs to stdout
+logger := slog.New(
+    slogmulti.Router().
+        Add(sentryHandler, slogmulti.LevelIs(slog.LevelError)).
+        Add(slog.NewJSONHandler(os.Stdout, nil)).
+        Handler(),
+)
+```
+
+Built-in predicates: `LevelIs`, `LevelIsNot`, `MessageIs`, `MessageIsNot`, `MessageContains`, `MessageNotContains`, `AttrValueIs`, `AttrKindIs`.
+
+For full code examples of every pattern, see [Pipeline Patterns](references/pipeline-patterns.md).
+
+## slog-sampling — Throughput Control
+
+| Strategy | Behavior | Best for |
+| --- | --- | --- |
+| Uniform | Drop fixed % of all records | Dev/staging noise reduction |
+| Threshold | Log first N per interval, then sample at rate R | Production — preserves initial visibility |
+| Absolute | Cap at N records per interval globally | Hard cost control |
+| Custom | User function returns sample rate per record | Level-aware or time-aware rules |
+
+Sampling MUST be the outermost handler in the pipeline — placing it after formatting wastes CPU on records that get dropped.
+
+```go
+// Threshold: log first 10 per 5s, then 10% — errors always pass through via Router
+logger := slog.New(
+    slogmulti.
+        Pipe(slogsampling.ThresholdSamplingOption{
+            Tick: 5 * time.Second, Threshold: 10, Rate: 0.1,
+        }.NewMiddleware()).
+        Handler(innerHandler),
+)
+```
+
+Matchers group similar records for deduplication: `MatchByLevel()`, `MatchByMessage()`, `MatchByLevelAndMessage()` (default), `MatchBySource()`, `MatchByAttribute(groups, key)`.
+
+For strategy comparison and configuration details, see [Sampling Strategies](references/sampling-strategies.md).
+
+## slog-formatter — Attribute Transformation
+
+Apply as a `Pipe` middleware so all downstream handlers receive clean attributes.
+
+```go
+logger := slog.New(
+    slogmulti.Pipe(slogformatter.NewFormatterMiddleware(
+        slogformatter.PIIFormatter("user"),          // mask PII fields
+        slogformatter.ErrorFormatter("error"),       // structured error info
+        slogformatter.IPAddressFormatter("client"),  // mask IP addresses
+    )).Handler(slog.NewJSONHandler(os.Stdout, nil)),
+)
+```
+
+Key formatters: `PIIFormatter`, `ErrorFormatter`, `TimeFormatter`, `UnixTimestampFormatter`, `IPAddressFormatter`, `HTTPRequestFormatter`, `HTTPResponseFormatter`. Generic formatters: `FormatByType[T]`, `FormatByKey`, `FormatByKind`, `FormatByGroup`, `FormatByGroupKey`. Flatten nested attributes with `FlattenFormatterMiddleware`.
+
+## HTTP Middlewares
+
+Consistent pattern across frameworks: `router.Use(slogXXX.New(logger))`.
+
+Available: `slog-gin`, `slog-echo`, `slog-fiber`, `slog-chi`, `slog-http` (net/http).
+
+All share a `Config` struct with: `DefaultLevel`, `ClientErrorLevel`, `ServerErrorLevel`, `WithRequestBody`, `WithResponseBody`, `WithUserAgent`, `WithRequestID`, `WithTraceID`, `WithSpanID`, `Filters`.
+
+```go
+// Gin with filters — skip health checks
+router.Use(sloggin.NewWithConfig(logger, sloggin.Config{
+    DefaultLevel:     slog.LevelInfo,
+    ClientErrorLevel: slog.LevelWarn,
+    ServerErrorLevel: slog.LevelError,
+    WithRequestBody:  true,
+    Filters: []sloggin.Filter{
+        sloggin.IgnorePath("/health", "/metrics"),
+    },
+}))
+```
+
+For framework-specific setup, see [HTTP Middlewares](references/http-middlewares.md).
+
+## Backend Sinks
+
+All follow the `Option{}.NewXxxHandler()` constructor pattern.
+
+| Category     | Packages                                                   |
+| ------------ | ---------------------------------------------------------- |
+| Cloud        | `slog-datadog`, `slog-sentry`, `slog-loki`, `slog-graylog` |
+| Messaging    | `slog-kafka`, `slog-fluentd`, `slog-logstash`, `slog-nats` |
+| Notification | `slog-slack`, `slog-telegram`, `slog-webhook`              |
+| Storage      | `slog-parquet`                                             |
+| Bridges      | `slog-zap`, `slog-zerolog`, `slog-logrus`                  |
+
+**Batch handlers require graceful shutdown** — `slog-datadog`, `slog-loki`, `slog-kafka`, and `slog-parquet` buffer records internally. Flush on shutdown (e.g., `handler.Stop(ctx)` for Datadog, `lokiClient.Stop()` for Loki, `writer.Close()` for Kafka) or buffered logs are lost.
+
+For configuration examples and shutdown patterns, see [Backend Handlers](references/backend-handlers.md).
+
+## Common Mistakes
+
+| Mistake | Why it fails | Fix |
+| --- | --- | --- |
+| Sampling after formatting | Wastes CPU formatting records that get dropped | Place sampling as outermost handler |
+| Fanout to many synchronous handlers | Blocks caller — latency is sum of all handlers | Use `Pool()` for concurrent dispatch |
+| Missing shutdown flush on batch handlers | Buffered logs lost on shutdown | `defer handler.Stop(ctx)` (Datadog), `defer lokiClient.Stop()` (Loki), `defer writer.Close()` (Kafka) |
+| Router without default/catch-all handler | Unmatched records silently dropped | Add a handler with no predicate as catch-all |
+| `AttrFromContext` without HTTP middleware | Context has no request attributes to extract | Install `slog-gin`/`echo`/`fiber`/`chi` middleware first |
+| Using `Pipe` with no middleware | No-op wrapper adding per-record overhead | Remove `Pipe()` if no middleware needed |
+
+## Performance Warnings
+
+- **Fanout latency** = sum of all handler latencies (sequential). With 5 handlers at 10ms each, every log call costs 50ms. Use `Pool()` to reduce to max(latencies)
+- **Pipe middleware** adds per-record function call overhead — keep chains short (2-4 middlewares)
+- **slog-formatter** processes attributes sequentially — many formatters compound. For hot-path attribute formatting, prefer implementing `slog.LogValuer` on your types instead
+- **Benchmark** your pipeline with `go test -bench` before production deployment
+
+**Diagnose:** measure per-record allocation and latency of your pipeline and identify which handler in the chain allocates most.
+
+## Best Practices
+
+1. **Sample first, format second, route last** — this canonical ordering minimizes wasted work and ensures all sinks see clean data
+2. **Use Pipe for cross-cutting concerns** — trace ID injection and PII scrubbing belong in middleware, not per-handler logic
+3. **Test pipelines with `slogmulti.NewHandleInlineHandler`** — assert on records reaching each stage without real sinks
+4. **Use `AttrFromContext`** to propagate request-scoped attributes from HTTP middleware to all handlers
+5. **Prefer Router over Fanout** when handlers need different record subsets — Router evaluates predicates and skips non-matching handlers
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-observability` skill for slog fundamentals (levels, context, handler setup, migration)
+- → See `samber/cc-skills-golang@golang-error-handling` skill for the log-or-return rule
+- → See `samber/cc-skills-golang@golang-security` skill for PII handling in logs
+- → See `samber/cc-skills-golang@golang-samber-oops` skill for structured error context with `samber/oops`
+
+If you encounter a bug or unexpected behavior in any samber/slog-\* package, open an issue at the relevant repository (e.g., [slog-multi/issues](https://github.com/samber/slog-multi/issues), [slog-sampling/issues](https://github.com/samber/slog-sampling/issues)).
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/evals/evals.json
new file mode 100644
index 00000000..90c170dc
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/evals/evals.json
@@ -0,0 +1,172 @@
+[
+  {
+    "id": 1,
+    "name": "pipeline-ordering",
+    "description": "Tests whether the model places sampling first in the pipeline (before formatting)",
+    "prompt": "Set up a slog pipeline in Go using samber/slog libraries with PII scrubbing (mask email fields), error routing to Sentry, and log sampling at 10%. Show the complete handler composition using slog-multi, slog-sampling, and slog-formatter.",
+    "trap": "Without the skill, the model places sampling last (after formatting) or in the middle, wasting CPU on records that get dropped",
+    "assertions": [
+      {"id": "1.1", "text": "Sampling is the outermost/first handler in the pipeline (applied before formatting)"},
+      {"id": "1.2", "text": "Uses slog-sampling library (slogsampling) for sampling, not custom code"},
+      {"id": "1.3", "text": "Uses slog-formatter for PII scrubbing (PIIFormatter or FormatByKey)"},
+      {"id": "1.4", "text": "Uses slogmulti.Router or Fanout for routing to Sentry"},
+      {"id": "1.5", "text": "Explains or demonstrates why sampling should be first (avoid wasted CPU on dropped records)"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "router-firstmatch-vs-router-all-matches",
+    "description": "Tests whether the model distinguishes Router (all matching) from Router+FirstMatch (first match only)",
+    "prompt": "I have a slog-multi Router with two rules: (1) ERROR and above → PagerDuty, (2) WARN and above → Slack. My problem: ERROR logs are going to BOTH PagerDuty AND Slack. I only want errors in PagerDuty, not duplicated in Slack. How do I fix this with slog-multi?",
+    "trap": "Without the skill, the model adds a LevelIs(slog.LevelWarn) predicate to the Slack handler thinking that fixes it — but WARN and above includes ERROR, so errors still reach Slack. The correct fix is Router().Add(...).FirstMatch() so routing stops at the first matching handler.",
+    "assertions": [
+      {"id": "2.1", "text": "Identifies that the default Router sends to ALL matching handlers (both Slack and PagerDuty match for ERROR)"},
+      {"id": "2.2", "text": "Recommends using .FirstMatch() on the Router to stop at the first matching handler"},
+      {"id": "2.3", "text": "Does NOT suggest just changing Slack's predicate to LevelIs(slog.LevelWarn) as the complete fix (errors still match WARN-and-above)"},
+      {"id": "2.4", "text": "Shows the correct Router().Add(pagerduty, LevelIs(ERROR)).Add(slack, LevelIs(WARN)).FirstMatch().Handler() pattern"},
+      {"id": "2.5", "text": "Explains the semantic difference: Router routes to ALL matches, FirstMatch routes to FIRST match only"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "missing-close-batch",
+    "description": "Tests whether the model remembers to call Close() on batch handlers",
+    "prompt": "Set up slog to send logs to Datadog using samber/slog-datadog in a Go HTTP server with graceful shutdown. Show the complete main() function.",
+    "trap": "Without the skill, the model forgets to close the handler on shutdown, causing buffered logs to be lost",
+    "assertions": [
+      {"id": "3.1", "text": "Calls handler.Stop(ctx) or defer handler.Stop(ctx) for the Datadog handler (not Close)"},
+      {"id": "3.2", "text": "Uses Option{}.NewDatadogHandler() constructor pattern"},
+      {"id": "3.3", "text": "Close happens during graceful shutdown (signal handling or defer in main)"},
+      {"id": "3.4", "text": "Mentions or demonstrates that Datadog handler batches logs (data loss risk without Close)"},
+      {"id": "3.5", "text": "Import path is github.com/samber/slog-datadog/v2 or later"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "sampling-matcher-grouping",
+    "description": "Tests whether the model understands slog-sampling Matchers for deduplication grouping",
+    "prompt": "I've set up ThresholdSamplingOption in my Go service: log the first 10 per 5s, then sample at 10%. It works, but I notice that 'user not found' (DEBUG) and 'cache miss' (DEBUG) are being counted together in the same bucket. After 10 total DEBUG logs from both messages, both get sampled. I want each distinct log message to have its own counter of 10. How do I fix this with samber/slog-sampling?",
+    "trap": "Without the skill, the model either rebuilds sampling from scratch or suggests separate logger instances per message. The correct fix is to set the Matcher to MatchByLevelAndMessage() (or MatchByMessage()) so each unique message gets its own deduplication bucket instead of all records sharing one bucket.",
+    "assertions": [
+      {"id": "4.1", "text": "Identifies that the default Matcher groups all records into one bucket (regardless of message)"},
+      {"id": "4.2", "text": "Recommends setting the Matcher field on ThresholdSamplingOption to MatchByLevelAndMessage() or MatchByMessage()"},
+      {"id": "4.3", "text": "Explains that each unique message will then have its own independent threshold counter"},
+      {"id": "4.4", "text": "Does NOT suggest creating separate logger instances per message type as the solution"},
+      {"id": "4.5", "text": "Does NOT suggest rewriting custom sampling logic outside of slog-sampling"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "router-warn-level-gap",
+    "description": "Tests whether the model identifies that WARN records are silently dropped in a Router with only ERROR and INFO predicates",
+    "prompt": "I have this slog-multi Router setup. My ERROR logs reach Sentry, my INFO logs reach Loki, but my WARN logs are silently disappearing — they don't reach either handler. My global slog level is set to Debug so filtering isn't the issue. What's wrong?\n\n```go\nlogger := slog.New(\n    slogmulti.Router().\n        Add(sentryHandler, slogmulti.LevelIs(slog.LevelError)).\n        Add(lokiHandler, slogmulti.LevelIs(slog.LevelInfo)).\n        Handler(),\n)\n```",
+    "trap": "Without the skill, the model suspects Loki configuration, slog level filters, or assumes LevelIs(Info) includes Warn. The skill teaches that Router predicates are exact — LevelIs(Info) matches ONLY Info, not Warn or above. WARN records match no predicate and are silently dropped. Fix: add a catch-all handler or use a predicate that covers Warn.",
+    "assertions": [
+      {"id": "5.1", "text": "Correctly identifies that LevelIs(slog.LevelInfo) matches ONLY Info level, not Warn"},
+      {"id": "5.2", "text": "Explains that Router silently drops records that match no predicate"},
+      {"id": "5.3", "text": "Does NOT suggest the global slog level or Loki configuration as the root cause"},
+      {"id": "5.4", "text": "Proposes adding a catch-all handler (no predicate) or a LevelIs(slog.LevelWarn) rule to capture WARN records"},
+      {"id": "5.5", "text": "Correctly explains that Router predicates are exact-level matches, not 'level and above'"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "http-middleware-error-level-differentiation",
+    "description": "Tests whether the model uses slog-gin Config to log 4xx and 5xx at different levels instead of uniform INFO",
+    "prompt": "I've added sloggin.New(logger) to my Gin server for request logging. My log aggregation tool shows that 404s and 500s both appear as INFO level, making it hard to alert on server errors. How do I make 4xx client errors log at WARN and 5xx server errors log at ERROR, while keeping normal requests at INFO, using samber/slog-gin?",
+    "trap": "Without the skill, the model wraps sloggin in a custom middleware or post-processes log records to change the level. The skill teaches that slog-gin's Config struct has ClientErrorLevel and ServerErrorLevel fields that handle this natively — no custom middleware needed.",
+    "assertions": [
+      {"id": "6.1", "text": "Replaces sloggin.New() with sloggin.NewWithConfig() to pass a Config struct"},
+      {"id": "6.2", "text": "Sets ClientErrorLevel: slog.LevelWarn in the Config for 4xx responses"},
+      {"id": "6.3", "text": "Sets ServerErrorLevel: slog.LevelError in the Config for 5xx responses"},
+      {"id": "6.4", "text": "Sets DefaultLevel: slog.LevelInfo in the Config for 2xx/3xx responses"},
+      {"id": "6.5", "text": "Does NOT implement a custom Gin middleware or post-processing logic to change log levels"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "pipe-middleware-chain",
+    "description": "Tests whether the model uses Pipe middleware instead of custom Handler wrapper",
+    "prompt": "I need to inject a trace_id from OpenTelemetry context and scrub email addresses from all log records before they reach any handler. I'm using samber/slog-multi. Show me how to set this up as reusable middleware.",
+    "trap": "Without the skill, the model creates a custom slog.Handler wrapper struct instead of using slogmulti.Pipe with inline middleware",
+    "assertions": [
+      {"id": "7.1", "text": "Uses slogmulti.Pipe() for middleware chaining"},
+      {"id": "7.2", "text": "Creates middleware for trace_id injection (inline middleware or AttrFromContext)"},
+      {"id": "7.3", "text": "Creates middleware or formatter for email/PII scrubbing"},
+      {"id": "7.4", "text": "Pipe wraps the final sink handler(s)"},
+      {"id": "7.5", "text": "Does NOT implement a custom slog.Handler struct with Enabled/Handle/WithAttrs/WithGroup methods"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "failover-handler",
+    "description": "Tests whether the model uses Failover instead of custom retry logic",
+    "prompt": "My slog pipeline sends logs to Loki over the network, but Loki has occasional outages lasting 1-5 minutes. I want to automatically fall back to local file logging when Loki is unavailable, then resume Loki when it's back. Show the setup using samber/slog-multi.",
+    "trap": "Without the skill, the model builds custom retry/fallback logic with goroutines and channels instead of using slog-multi's Failover handler",
+    "assertions": [
+      {"id": "8.1", "text": "Uses slogmulti.Failover() handler"},
+      {"id": "8.2", "text": "Loki handler is the primary (first) handler in the Failover chain"},
+      {"id": "8.3", "text": "File/local handler is the fallback (second) handler"},
+      {"id": "8.4", "text": "Does NOT implement custom retry/fallback logic with goroutines or channels"},
+      {"id": "8.5", "text": "Uses slog-loki library for the Loki handler (not a custom HTTP client)"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "pool-vs-fanout-latency",
+    "description": "Tests whether the model recommends Pool over Fanout and correctly describes Pool's latency model",
+    "prompt": "I'm replacing slogmulti.Fanout with slogmulti.Pool to reduce log-call latency. I have 4 handlers with these p99 write times: stdout (1ms), Loki (20ms), Datadog (30ms), Sentry (15ms). My current Fanout p99 latency per log call is ~66ms. What will Pool's p99 latency be, and are there any risks I should know about with Pool that don't exist with Fanout?",
+    "trap": "Without the skill, the model says Pool will have ~0ms latency (wrongly treating it as fire-and-forget) or cannot identify the risks. The skill teaches: Pool latency = max of all handlers (30ms, not 66ms); risk = Pool may silently swallow handler errors that Fanout would surface synchronously.",
+    "assertions": [
+      {"id": "9.1", "text": "Correctly states Pool p99 latency will be ~30ms (the slowest handler, Datadog) not the sum"},
+      {"id": "9.2", "text": "Explains that Pool dispatches concurrently so latency = max(handler latencies), not sum"},
+      {"id": "9.3", "text": "Identifies at least one risk of Pool vs Fanout (e.g. handler errors may not surface synchronously, or error handling differs)"},
+      {"id": "9.4", "text": "Shows correct Pool syntax: slogmulti.Pool()(handlers...) with the double call"},
+      {"id": "9.5", "text": "Does NOT claim Pool is fully asynchronous/fire-and-forget with zero latency impact"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "formatter-pii-scrubbing",
+    "description": "Tests whether the model uses slog-formatter as Pipe middleware for cross-cutting PII scrubbing",
+    "prompt": "I need to ensure no email addresses or IP addresses appear in any log output from my Go service. We use slog with slog-multi routing to 3 different handlers (stdout, Loki, Sentry). Show me how to add PII protection that applies to ALL handlers in one place.",
+    "trap": "Without the skill, the model adds per-handler filtering or regex on output instead of using slog-formatter as a Pipe middleware wrapping all downstream handlers",
+    "assertions": [
+      {"id": "10.1", "text": "Uses slog-formatter library (slogformatter package)"},
+      {"id": "10.2", "text": "Uses PIIFormatter and/or IPAddressFormatter from slog-formatter"},
+      {"id": "10.3", "text": "Applies formatter as a Pipe middleware wrapping all downstream handlers (not per-handler)"},
+      {"id": "10.4", "text": "Formatter is applied once in the pipeline, before the Router/Fanout"},
+      {"id": "10.5", "text": "Does NOT implement custom regex-based filtering or per-handler PII logic"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "backend-option-pattern",
+    "description": "Tests whether the model uses correct Option{} constructor pattern for backend handlers",
+    "prompt": "Set up slog to send error-level logs to Sentry and all logs to Grafana Loki using samber/slog-sentry and samber/slog-loki. Show the complete setup with correct imports and handler creation.",
+    "trap": "Without the skill, the model uses incorrect constructor patterns (e.g., New() function, slogsentry.New(), or positional args) instead of the Option{}.NewXxxHandler() pattern",
+    "assertions": [
+      {"id": "11.1", "text": "Uses slogsentry.Option{}.NewSentryHandler() constructor pattern"},
+      {"id": "11.2", "text": "Uses slogloki.Option{}.NewLokiHandler() constructor pattern"},
+      {"id": "11.3", "text": "Uses slogmulti.Router() for level-based routing (errors to Sentry, all to Loki)"},
+      {"id": "11.4", "text": "Import paths use versioned modules (github.com/samber/slog-sentry/v2, github.com/samber/slog-loki/v3)"},
+      {"id": "11.5", "text": "Calls lokiClient.Stop() or defer lokiClient.Stop() for graceful shutdown (flush buffered logs)"}
+    ]
+  },
+  {
+    "id": 12,
+    "name": "attrfromcontext-without-middleware",
+    "description": "Tests whether the model identifies that AttrFromContext needs HTTP middleware to populate context",
+    "prompt": "I'm using slog-multi's Pipe with AttrFromContext to add request_id to all log records in my Go HTTP server. But the request_id is always empty in the logs. I'm NOT using any HTTP logging middleware (no slog-gin or slog-chi). Here's my handler setup:\n\n```go\nhandler := slogsentry.Option{\n    Level: slog.LevelError,\n    AttrFromContext: []func(ctx context.Context) []slog.Attr{\n        func(ctx context.Context) []slog.Attr {\n            if reqID := ctx.Value(\"request_id\"); reqID != nil {\n                return []slog.Attr{slog.String(\"request_id\", reqID.(string))}\n            }\n            return nil\n        },\n    },\n}.NewSentryHandler()\n```\n\nWhat's wrong and how do I fix it?",
+    "trap": "Without the skill, the model debugs context.Value key types or suggests adding context.WithValue manually in every handler, instead of identifying the missing HTTP middleware that injects attributes",
+    "assertions": [
+      {"id": "12.1", "text": "Identifies that no HTTP middleware is populating the request_id into context"},
+      {"id": "12.2", "text": "Recommends adding slog-gin/echo/fiber/chi middleware (or manual context injection middleware)"},
+      {"id": "12.3", "text": "Explains that the HTTP middleware is what injects request attributes into context"},
+      {"id": "12.4", "text": "Does NOT suggest only changing the context key type as the primary fix"},
+      {"id": "12.5", "text": "Shows the connection between HTTP middleware and AttrFromContext"},
+      {"id": "12.6", "text": "Mentions WithRequestID config option or equivalent for the middleware"},
+      {"id": "12.7", "text": "Does NOT blame slog-multi or slog-sentry configuration as the root cause"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/backend-handlers.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/backend-handlers.md
new file mode 100644
index 00000000..bed23cb1
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/backend-handlers.md
@@ -0,0 +1,269 @@
+# Backend Handlers
+
+All backend handlers implement `slog.Handler` and follow the `Option{}.NewXxxHandler()` constructor pattern.
+
+## Common Option Fields
+
+Every handler's `Option` struct includes:
+
+| Field | Purpose |
+| --- | --- |
+| `Level` | Minimum log level (default: `slog.LevelDebug`) |
+| `AddSource` | Include source file/line in log output |
+| `ReplaceAttr` | Callback to modify attributes before emission |
+| `Converter` | Custom payload builder for the target format |
+| `AttrFromContext` | Slice of functions extracting attributes from `context.Context` |
+
+## Cloud Backends
+
+### Datadog — `slog-datadog`
+
+```go
+import slogdatadog "github.com/samber/slog-datadog/v2"
+
+handler := slogdatadog.Option{
+    Level: slog.LevelInfo,
+    // Service, Source, Hostname, Tags configured via Datadog client
+}.NewDatadogHandler()
+defer handler.(interface{ Stop(context.Context) error }).Stop(context.Background()) // REQUIRED: flush buffered logs
+```
+
+**Batch mode** is the default — logs are buffered and sent periodically (default 5s). Call `Stop(ctx)` on shutdown or buffered logs are lost. The handler also exposes `Flush(ctx)` for mid-lifecycle flushes. For synchronous delivery, check the Option configuration.
+
+### Sentry — `slog-sentry`
+
+```go
+import slogsentry "github.com/samber/slog-sentry/v2"
+
+handler := slogsentry.Option{
+    Level:   slog.LevelWarn,
+    Hub:     sentry.CurrentHub(),
+    AddSource: true,
+}.NewSentryHandler()
+
+// Flush on shutdown
+defer sentry.Flush(2 * time.Second)
+```
+
+**Recognized attributes:** `error` (any error type), `request` (\*http.Request), `dist`, `environment`, `release`, `server_name`, `transaction`. Use `slog.Group("tags", ...)` for Sentry tags and `slog.Group("user", ...)` for user context.
+
+**Error keys:** Global `ErrorKeys = []string{"error", "err"}` — attributes with these keys are treated as error objects.
+
+### Loki — `slog-loki`
+
+```go
+import slogloki "github.com/samber/slog-loki/v3"
+
+lokiClient, _ := loki.New(lokiCfg)
+defer lokiClient.Stop() // REQUIRED: flush buffered logs
+
+handler := slogloki.Option{
+    Level:  slog.LevelDebug,
+    Client: lokiClient,
+}.NewLokiHandler()
+```
+
+**Labels vs metadata:** By default, attributes are sent as Loki labels. For high-cardinality data (request IDs, trace IDs), enable `HandleRecordsWithMetadata: true` to send as structured metadata instead — this avoids label explosion that degrades Loki performance.
+
+### Graylog — `slog-graylog`
+
+```go
+import sloggraylog "github.com/samber/slog-graylog/v2"
+
+gelfWriter, _ := gelf.NewWriter("localhost:12201")
+handler := sloggraylog.Option{
+    Level:  slog.LevelDebug,
+    Writer: gelfWriter,
+}.NewGraylogHandler()
+```
+
+Uses GELF (Graylog Extended Log Format) over UDP.
+
+## Messaging Backends
+
+### Kafka — `slog-kafka`
+
+```go
+import slogkafka "github.com/samber/slog-kafka/v2"
+
+writer := &kafka.Writer{
+    Addr:  kafka.TCP("localhost:9092"),
+    Topic: "logs",
+    Async: true, // non-blocking writes
+}
+handler := slogkafka.Option{
+    Level:       slog.LevelDebug,
+    KafkaWriter: writer,
+    Timeout:     60 * time.Second,
+}.NewKafkaHandler()
+defer writer.Close() // REQUIRED: flush pending messages
+```
+
+### Fluentd — `slog-fluentd`
+
+```go
+import slogfluentd "github.com/samber/slog-fluentd/v2"
+
+client, _ := fluent.New(fluent.Config{
+    FluentHost: "localhost", FluentPort: 24224,
+})
+handler := slogfluentd.Option{
+    Level:  slog.LevelDebug,
+    Client: client,
+    Tag:    "api",
+}.NewFluentdHandler()
+defer client.Close()
+```
+
+### Logstash — `slog-logstash`
+
+```go
+import sloglogstash "github.com/samber/slog-logstash/v2"
+
+conn, _ := net.Dial("tcp", "localhost:9999")
+handler := sloglogstash.Option{
+    Level: slog.LevelDebug,
+    Conn:  conn,
+}.NewLogstashHandler()
+defer conn.Close()
+```
+
+Output format: JSON with `@timestamp`, `level`, `message`, `error`, `extra` fields.
+
+## Notification Backends
+
+### Slack — `slog-slack`
+
+```go
+import slogslack "github.com/samber/slog-slack/v2"
+
+// Via webhook
+handler := slogslack.Option{
+    Level:      slog.LevelError,
+    WebhookURL: "https://hooks.slack.com/services/...",
+    Channel:    "alerts",
+}.NewSlackHandler()
+
+// Via bot token
+handler := slogslack.Option{
+    Level:    slog.LevelError,
+    BotToken: "xoxb-...",
+    Channel:  "alerts",
+}.NewSlackHandler()
+```
+
+### Telegram — `slog-telegram`
+
+```go
+import slogtelegram "github.com/samber/slog-telegram/v2"
+
+handler := slogtelegram.Option{
+    Level:    slog.LevelError,
+    Token:    "your-bot-token",
+    Username: "@your-channel",
+}.NewTelegramHandler()
+```
+
+### Webhook — `slog-webhook`
+
+```go
+import slogwebhook "github.com/samber/slog-webhook/v2"
+
+handler := slogwebhook.Option{
+    Level:    slog.LevelError,
+    Endpoint: "https://webhook.site/your-id",
+    Timeout:  10 * time.Second,
+}.NewWebhookHandler()
+```
+
+## Storage Backends
+
+### Parquet — `slog-parquet`
+
+```go
+import slogparquet "github.com/samber/slog-parquet/v2"
+
+buffer := slogparquet.NewParquetBuffer(bucket, "logs/", 10000, 5*time.Minute)
+defer buffer.Flush(true) // REQUIRED: flush remaining records synchronously
+
+handler := slogparquet.Option{
+    Level:  slog.LevelDebug,
+    Buffer: buffer,
+}.NewParquetHandler()
+```
+
+Uses Thanos `objstore.Bucket` for cloud storage (S3, GCS, Azure). Records are buffered and written as Parquet files when either `maxRecords` or `maxInterval` is reached.
+
+## Logging Bridges
+
+Bridge the `slog.Handler` interface to legacy logging frameworks. Use during incremental migration from Zap/Zerolog/Logrus to slog.
+
+### slog-zap
+
+```go
+import slogzap "github.com/samber/slog-zap/v2"
+
+zapLogger, _ := zap.NewProduction()
+handler := slogzap.Option{
+    Level:  slog.LevelDebug,
+    Logger: zapLogger,
+}.NewZapHandler()
+slog.SetDefault(slog.New(handler))
+// Now all slog.Info() calls route through Zap
+```
+
+### slog-zerolog
+
+```go
+import slogzerolog "github.com/samber/slog-zerolog/v2"
+
+zerologLogger := zerolog.New(zerolog.ConsoleWriter{Out: os.Stderr})
+handler := slogzerolog.Option{
+    Level:  slog.LevelDebug,
+    Logger: &zerologLogger,
+}.NewZerologHandler()
+```
+
+### slog-logrus
+
+```go
+import sloglogrus "github.com/samber/slog-logrus/v2"
+
+handler := sloglogrus.Option{
+    Level:  slog.LevelDebug,
+    Logger: logrus.StandardLogger(),
+}.NewLogrusHandler()
+```
+
+## Graceful Shutdown Checklist
+
+Handlers that buffer records internally and MUST be closed on shutdown:
+
+| Handler | Shutdown method | What happens without it |
+| --- | --- | --- |
+| `slog-datadog` | `handler.Stop(ctx)` | Buffered logs lost (default 5s batch) |
+| `slog-loki` | `lokiClient.Stop()` | Pending push requests dropped |
+| `slog-kafka` | `writer.Close()` | Pending messages never sent |
+| `slog-parquet` | `buffer.Flush(true)` | Partial Parquet file not flushed to storage |
+
+For non-batched handlers (Sentry, Slack, Telegram, Webhook), logs are sent synchronously — no close required, but `sentry.Flush(timeout)` is recommended.
+
+```go
+// Production shutdown pattern
+func main() {
+    lokiClient, _ := loki.New(lokiCfg)
+    defer lokiClient.Stop() // flush buffered logs
+
+    lokiHandler := slogloki.Option{
+        Level: slog.LevelDebug, Client: lokiClient,
+    }.NewLokiHandler()
+
+    // Use signal handling for graceful shutdown
+    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt)
+    defer stop()
+
+    // ... start server ...
+    <-ctx.Done()
+    // deferred Stop() runs here, flushing buffered logs
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/http-middlewares.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/http-middlewares.md
new file mode 100644
index 00000000..ab13c04c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/http-middlewares.md
@@ -0,0 +1,179 @@
+# HTTP Middlewares
+
+All samber/slog HTTP middlewares share a consistent pattern and configuration structure.
+
+## Shared Config Fields
+
+Every middleware provides a `Config` struct with these common fields:
+
+| Field | Type | Default | Purpose |
+| --- | --- | --- | --- |
+| `DefaultLevel` | `slog.Level` | `slog.LevelInfo` | Log level for 2xx/3xx responses |
+| `ClientErrorLevel` | `slog.Level` | `slog.LevelWarn` | Log level for 4xx responses |
+| `ServerErrorLevel` | `slog.Level` | `slog.LevelError` | Log level for 5xx responses |
+| `WithUserAgent` | `bool` | `false` | Include `User-Agent` header |
+| `WithRequestID` | `bool` | `false` | Include request ID |
+| `WithRequestBody` | `bool` | `false` | Include request body (capped) |
+| `WithResponseBody` | `bool` | `false` | Include response body (capped) |
+| `WithRequestHeader` | `bool` | `false` | Include request headers |
+| `WithResponseHeader` | `bool` | `false` | Include response headers |
+| `WithSpanID` | `bool` | `false` | Include OpenTelemetry span ID |
+| `WithTraceID` | `bool` | `false` | Include OpenTelemetry trace ID |
+| `WithClientIP` | `bool` | `false` | Include client IP address |
+| `Filters` | `[]Filter` | `nil` | Request filter functions |
+
+**Global configuration variables** (set before creating middleware):
+
+- `RequestBodyMaxSize` / `ResponseBodyMaxSize` — default 64KB each
+- `HiddenRequestHeaders` / `HiddenResponseHeaders` — headers to redact
+- `TraceIDKey` / `SpanIDKey` — context key names for OpenTelemetry
+
+## Default Log Fields
+
+All middlewares emit these fields by default: `method`, `path`, `status`, `latency`, `request-length`, `response-length`.
+
+## Gin — `slog-gin`
+
+```go
+import sloggin "github.com/samber/slog-gin"
+
+// Simple
+router := gin.New()
+router.Use(sloggin.New(logger))
+
+// With config
+router.Use(sloggin.NewWithConfig(logger, sloggin.Config{
+    DefaultLevel:     slog.LevelInfo,
+    ClientErrorLevel: slog.LevelWarn,
+    ServerErrorLevel: slog.LevelError,
+    WithRequestBody:  true,
+    WithUserAgent:    true,
+    Filters: []sloggin.Filter{
+        sloggin.IgnorePath("/health", "/metrics"),
+        sloggin.IgnorePathPrefix("/static"),
+    },
+}))
+
+// Custom attributes per request
+router.GET("/api/users", func(c *gin.Context) {
+    sloggin.AddCustomAttributes(c, slog.String("user_id", userID))
+    c.JSON(200, users)
+})
+```
+
+## Echo — `slog-echo`
+
+```go
+import slogecho "github.com/samber/slog-echo"
+
+e := echo.New()
+e.Use(slogecho.New(logger))
+
+// With config
+e.Use(slogecho.NewWithConfig(logger, slogecho.Config{
+    DefaultLevel:     slog.LevelInfo,
+    ClientErrorLevel: slog.LevelWarn,
+    ServerErrorLevel: slog.LevelError,
+    WithRequestBody:  true,
+    Filters: []slogecho.Filter{
+        slogecho.IgnoreStatus(404),
+        slogecho.IgnorePath("/health"),
+    },
+}))
+
+// Custom attributes
+e.GET("/api/users", func(c echo.Context) error {
+    slogecho.AddCustomAttributes(c, slog.String("user_id", userID))
+    return c.JSON(200, users)
+})
+```
+
+## Fiber — `slog-fiber`
+
+```go
+import slogfiber "github.com/samber/slog-fiber"
+
+app := fiber.New()
+app.Use(slogfiber.New(logger))
+
+// With config
+app.Use(slogfiber.NewWithConfig(logger, slogfiber.Config{
+    DefaultLevel:     slog.LevelInfo,
+    ClientErrorLevel: slog.LevelWarn,
+    ServerErrorLevel: slog.LevelError,
+    WithRequestBody:  true,
+    Filters: []slogfiber.Filter{
+        slogfiber.IgnorePath("/health"),
+        slogfiber.IgnoreStatus(404),
+    },
+}))
+
+// Custom attributes
+app.Get("/api/users", func(c fiber.Ctx) error {
+    slogfiber.AddCustomAttributes(c, slog.String("user_id", userID))
+    return c.JSON(users)
+})
+```
+
+**Note:** Fiber uses `fasthttp`, not `net/http`. Request/response types differ.
+
+## Chi — `slog-chi`
+
+```go
+import slogchi "github.com/samber/slog-chi"
+
+router := chi.NewRouter()
+router.Use(slogchi.New(logger))
+
+// With config
+router.Use(slogchi.NewWithConfig(logger, slogchi.Config{
+    DefaultLevel:     slog.LevelInfo,
+    ClientErrorLevel: slog.LevelWarn,
+    ServerErrorLevel: slog.LevelError,
+    WithRequestBody:  true,
+    Filters: []slogchi.Filter{
+        slogchi.IgnorePath("/health", "/ready"),
+        slogchi.IgnoreStatus(401, 404),
+    },
+}))
+
+// Custom attributes
+router.Get("/api/users", func(w http.ResponseWriter, r *http.Request) {
+    slogchi.AddCustomAttributes(r, slog.String("user_id", userID))
+    json.NewEncoder(w).Encode(users)
+})
+```
+
+## net/http — `slog-http`
+
+```go
+import sloghttp "github.com/samber/slog-http"
+
+mux := http.NewServeMux()
+handler := sloghttp.New(logger)(mux)
+http.ListenAndServe(":8080", handler)
+```
+
+## Filters
+
+All middlewares support the same filter functions:
+
+```go
+sloggin.IgnorePath("/health", "/metrics")     // exact path match
+sloggin.IgnorePathPrefix("/static", "/assets") // path prefix
+sloggin.IgnoreStatus(401, 404)                 // skip specific status codes
+
+// Custom filter
+sloggin.Accept(func(c *gin.Context) bool {
+    return c.Request.Method != "OPTIONS"       // skip CORS preflight
+})
+```
+
+## Logger Grouping
+
+Wrap the logger with `WithGroup("http")` to namespace all middleware attributes under an `http` group:
+
+```go
+router.Use(sloggin.New(logger.WithGroup("http")))
+// Output: {"http": {"method": "GET", "path": "/api", "status": 200, ...}}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/pipeline-patterns.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/pipeline-patterns.md
new file mode 100644
index 00000000..b9199927
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/pipeline-patterns.md
@@ -0,0 +1,240 @@
+# Pipeline Patterns
+
+Complete code examples for every `slog-multi` composition pattern.
+
+## Fanout — Broadcast to All
+
+Sends every record to every handler sequentially. Latency = sum of all handler latencies.
+
+```go
+import slogmulti "github.com/samber/slog-multi"
+
+logger := slog.New(
+    slogmulti.Fanout(
+        slog.NewJSONHandler(os.Stdout, nil),           // stdout
+        slog.NewTextHandler(logFile, nil),              // file
+        slogsentry.Option{Level: slog.LevelError}.NewSentryHandler(), // Sentry
+    ),
+)
+```
+
+**When to use:** Every destination must receive every record (audit logs, compliance). **When NOT to use:** Handlers have different record needs (use Router) or high latency (use Pool).
+
+## Router — Predicate-Based Routing
+
+Routes records to ALL handlers whose predicate matches. Unmatched records go nowhere unless a default handler is added.
+
+```go
+logger := slog.New(
+    slogmulti.Router().
+        Add(sentryHandler, slogmulti.LevelIs(slog.LevelError)).
+        Add(slackHandler, slogmulti.LevelIs(slog.LevelWarn)).
+        Add(lokiHandler, slogmulti.LevelIs(slog.LevelInfo, slog.LevelDebug)).
+        Add(slog.NewJSONHandler(os.Stdout, nil)). // catch-all: no predicate
+        Handler(),
+)
+```
+
+**Built-in predicates:**
+
+```go
+slogmulti.LevelIs(slog.LevelError)             // match specific levels
+slogmulti.LevelIsNot(slog.LevelDebug)          // exclude levels
+slogmulti.MessageIs("payment processed")       // exact message match
+slogmulti.MessageIsNot("healthcheck")          // exclude exact message
+slogmulti.MessageContains("timeout")           // partial message match
+slogmulti.MessageNotContains("debug")          // exclude partial message
+slogmulti.AttrValueIs("module", "billing")     // match attribute value
+slogmulti.AttrKindIs(slog.KindString)          // match attribute kind
+```
+
+**Custom predicate:**
+
+```go
+func recordMatchRegion(region string) func(ctx context.Context, r slog.Record) bool {
+    return func(ctx context.Context, r slog.Record) bool {
+        match := false
+        r.Attrs(func(attr slog.Attr) bool {
+            if attr.Key == "region" && attr.Value.String() == region {
+                match = true
+                return false
+            }
+            return true
+        })
+        return match
+    }
+}
+
+logger := slog.New(
+    slogmulti.Router().
+        Add(slackUS, recordMatchRegion("us")).
+        Add(slackEU, recordMatchRegion("eu")).
+        Handler(),
+)
+```
+
+**Warning:** Records matching no predicate are silently dropped. Always add a catch-all handler (no predicate) unless you intentionally want to discard unmatched records.
+
+## FirstMatch — Short-Circuit Routing
+
+Like Router but stops at the first matching handler. Each record goes to exactly one destination.
+
+```go
+logger := slog.New(
+    slogmulti.Router().
+        Add(queryHandler, matchQueryLogs).     // priority 1
+        Add(requestHandler, matchRequestLogs). // priority 2
+        Add(defaultHandler).                   // fallback
+        FirstMatch().
+        Handler(),
+)
+```
+
+**When to use:** Priority-based routing where each record should be processed exactly once. Order matters — put the most specific handlers first.
+
+## Failover — Sequential Fallback
+
+Tries handlers in order until one succeeds (returns `nil` error). If primary fails, falls through to secondary.
+
+```go
+logger := slog.New(
+    slogmulti.Failover()(
+        slogloki.Option{Level: slog.LevelDebug, Client: lokiClient}.NewLokiHandler(),
+        slog.NewJSONHandler(localFile, nil), // fallback to local file
+        slog.NewTextHandler(os.Stderr, nil), // last resort
+    ),
+)
+```
+
+**When to use:** Network sinks that may be unreliable (Loki, Logstash, remote syslog). Primary handles 99.9% of traffic; fallback catches the rest.
+
+## Pool — Load-Balanced Dispatch
+
+Randomly distributes each record to one handler from the pool. Useful when you have equivalent handlers and want to spread load.
+
+```go
+logger := slog.New(
+    slogmulti.Pool()(
+        lokiHandler1, // shard 1
+        lokiHandler2, // shard 2
+        lokiHandler3, // shard 3
+    ),
+)
+```
+
+**When to use:** Multiple equivalent sinks where you want throughput distribution. Latency = single handler latency (not sum like Fanout).
+
+## Pipe — Middleware Chain
+
+Chains middleware functions that intercept, transform, or enrich records before they reach the final handler.
+
+```go
+logger := slog.New(
+    slogmulti.
+        Pipe(samplingMiddleware).              // step 1: drop noise
+        Pipe(piiScrubbingMiddleware).          // step 2: mask PII
+        Pipe(traceInjectionMiddleware).        // step 3: add trace_id
+        Pipe(slogmulti.RecoverHandlerError(    // step 4: catch handler panics
+            func(ctx context.Context, record slog.Record, err error) {
+                log.Println("handler error:", err)
+            },
+        )).
+        Handler(slog.NewJSONHandler(os.Stdout, nil)),
+)
+```
+
+## Inline Handlers and Middleware
+
+Create quick handlers without defining a full struct.
+
+```go
+// Inline handler — for testing or simple consumers
+handler := slogmulti.NewHandleInlineHandler(
+    func(ctx context.Context, groups []string, attrs []slog.Attr, record slog.Record) error {
+        fmt.Printf("LOG: %s %s\n", record.Level, record.Message)
+        return nil
+    },
+)
+
+// Inline middleware — intercept and transform records
+middleware := slogmulti.NewHandleInlineMiddleware(
+    func(ctx context.Context, record slog.Record, next func(context.Context, slog.Record) error) error {
+        record.AddAttrs(slog.String("service", "my-api"))
+        return next(ctx, record)
+    },
+)
+```
+
+## AttrFromContext — Request-Scoped Attributes
+
+HTTP middlewares (`slog-gin`, `slog-echo`, etc.) inject request attributes into context. Backend handlers extract them via `AttrFromContext`.
+
+```go
+// Backend handler extracts trace_id from context
+handler := slogsentry.Option{
+    Level: slog.LevelError,
+    AttrFromContext: []func(ctx context.Context) []slog.Attr{
+        func(ctx context.Context) []slog.Attr {
+            if traceID := ctx.Value("trace_id"); traceID != nil {
+                return []slog.Attr{slog.String("trace_id", traceID.(string))}
+            }
+            return nil
+        },
+    },
+}.NewSentryHandler()
+```
+
+**Important:** `AttrFromContext` only works when the context actually contains the expected values. This requires an HTTP middleware (like `slog-gin`) to populate the context first. Without the middleware, `AttrFromContext` silently returns nil.
+
+## Full Production Pipeline
+
+Canonical ordering: sampling → middleware (PII, trace) → routing → sinks.
+
+```go
+import (
+    slogmulti "github.com/samber/slog-multi"
+    slogsampling "github.com/samber/slog-sampling"
+    slogformatter "github.com/samber/slog-formatter"
+    slogsentry "github.com/samber/slog-sentry/v2"
+    slogloki "github.com/samber/slog-loki/v3"
+)
+
+// 1. Sampling: first 20 per 5s, then 10%
+sampling := slogsampling.ThresholdSamplingOption{
+    Tick: 5 * time.Second, Threshold: 20, Rate: 0.1,
+}.NewMiddleware()
+
+// 2. PII scrubbing
+pii := slogformatter.NewFormatterMiddleware(
+    slogformatter.PIIFormatter("user"),
+    slogformatter.IPAddressFormatter("client_ip"),
+)
+
+// 3. Error recovery
+recovery := slogmulti.RecoverHandlerError(func(ctx context.Context, r slog.Record, err error) {
+    log.Printf("slog handler error: %v", err)
+})
+
+// 4. Sinks
+sentryHandler := slogsentry.Option{Level: slog.LevelError}.NewSentryHandler()
+lokiHandler := slogloki.Option{Level: slog.LevelDebug, Client: lokiClient}.NewLokiHandler()
+defer lokiClient.Stop() // flush buffered logs
+
+// 5. Compose — errors bypass sampling, everything else is sampled
+logger := slog.New(
+    slogmulti.
+        Pipe(pii).            // scrub PII on all records
+        Pipe(recovery).       // catch panics
+        Handler(
+            slogmulti.Router().
+                Add(sentryHandler, slogmulti.LevelIs(slog.LevelError)).  // errors: no sampling
+                Add(slogmulti.                                            // everything else: sampled
+                    Pipe(sampling).
+                    Handler(lokiHandler),
+                ).
+                FirstMatch().  // stop at first matching route — errors won't fall through to sampled path
+                Handler(),
+        ),
+)
+slog.SetDefault(logger)
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/sampling-strategies.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/sampling-strategies.md
new file mode 100644
index 00000000..b53e4660
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-samber-slog/references/sampling-strategies.md
@@ -0,0 +1,176 @@
+# Sampling Strategies
+
+## Why Sample
+
+High-throughput services generate enormous log volumes. At 10k RPS with 1KB per log entry, you produce 10MB/s — 864GB/day. Sampling reduces cost, network bandwidth, and storage without losing visibility into critical events.
+
+The key insight: sample noise (Debug/Info), never errors. Combine sampling strategies with level-based routing so Warn/Error records always reach every sink.
+
+## Strategy Comparison
+
+| Strategy | Constructor | Behavior | Overhead | Best for |
+| --- | --- | --- | --- | --- |
+| Uniform | `UniformSamplingOption` | Drop fixed % of all records randomly | Minimal | Dev/staging noise reduction |
+| Threshold | `ThresholdSamplingOption` | Log first N per interval, then sample at rate R | Low | Production — initial visibility then throttle |
+| Absolute | `AbsoluteSamplingOption` | Cap at N records per interval globally | Medium | Hard cost/throughput cap |
+| Custom | `CustomSamplingOption` | User function returns sample rate per record | Varies | Level-aware, time-aware, context-aware rules |
+
+## Uniform Sampling
+
+Simplest strategy. Drops a fixed percentage of all records uniformly.
+
+```go
+import slogsampling "github.com/samber/slog-sampling"
+
+option := slogsampling.UniformSamplingOption{
+    Rate: 0.33, // keep 33% of records
+}
+
+logger := slog.New(
+    slogmulti.Pipe(option.NewMiddleware()).
+        Handler(slog.NewJSONHandler(os.Stdout, nil)),
+)
+```
+
+**Warning:** Uniform sampling drops errors and warnings at the same rate as debug logs. Only use in dev/staging or combine with level-based routing that bypasses sampling for high-severity records.
+
+## Threshold Sampling
+
+Logs the first N records with the same "hash" per interval, then switches to rate-based sampling. The hash is determined by the Matcher.
+
+```go
+option := slogsampling.ThresholdSamplingOption{
+    Tick:      5 * time.Second,
+    Threshold: 10,               // first 10 records per hash: always logged
+    Rate:      0.1,              // after threshold: 10% sampling
+    Matcher:   slogsampling.MatchByLevelAndMessage(), // default grouping
+}
+```
+
+**Pattern:** "Show me the first 10 occurrences of each message per 5s window. After that, show every 10th." This preserves initial visibility into new issues while limiting noise from repeated messages.
+
+## Absolute Sampling
+
+Caps total throughput at a fixed number of records per interval, regardless of how many unique messages exist.
+
+```go
+option := slogsampling.AbsoluteSamplingOption{
+    Tick:    1 * time.Second,
+    Max:     1000,                           // cap at 1000 records/sec
+    Matcher: slogsampling.MatchAll(),        // all records share one counter
+}
+```
+
+**Use when:** You have a hard budget — e.g., "our log backend can handle 1000 records/sec max" or "we pay per GB ingested."
+
+## Custom Sampling
+
+Full control: return a sample rate [0.0, 1.0] per record based on any criteria.
+
+```go
+option := slogsampling.CustomSamplingOption{
+    Sampler: func(ctx context.Context, record slog.Record) float64 {
+        // Always log errors and warnings
+        if record.Level >= slog.LevelWarn {
+            return 1.0
+        }
+        // Night hours: log everything (low traffic)
+        if record.Time.Hour() < 6 || record.Time.Hour() > 22 {
+            return 1.0
+        }
+        // Business hours: heavy sampling for info/debug
+        return 0.01 // 1%
+    },
+}
+```
+
+**When to use:** Complex rules that depend on time of day, log level, specific attributes, or context values. Higher overhead than other strategies because the function runs per record.
+
+## Matchers — Record Grouping
+
+Matchers determine how records are grouped for threshold/absolute counting. Records with the same hash share a counter.
+
+| Matcher | Groups by | Use when |
+| --- | --- | --- |
+| `MatchAll()` | All records share one counter | Global throughput cap |
+| `MatchByLevel()` | Log level | Different rates per level |
+| `MatchByMessage()` | Message text | Deduplicate repeated messages |
+| `MatchByLevelAndMessage()` | Level + message (default) | Standard deduplication |
+| `MatchBySource()` | Source file:line | Group by call site |
+| `MatchByAttribute(groups, key)` | Attribute value | Group by module, user, etc. |
+| `MatchByContextValue(key)` | Context value | Group by request-scoped value |
+
+## Chaining Multiple Strategies
+
+Stack sampling strategies for layered control:
+
+```go
+// Layer 1: per-message deduplication (threshold)
+threshold := slogsampling.ThresholdSamplingOption{
+    Tick: 5 * time.Second, Threshold: 100, Rate: 0.1,
+    Matcher: slogsampling.MatchByLevelAndMessage(),
+}.NewMiddleware()
+
+// Layer 2: global throughput cap (absolute)
+absolute := slogsampling.AbsoluteSamplingOption{
+    Tick: 1 * time.Second, Max: 1000,
+    Matcher: slogsampling.MatchAll(),
+}.NewMiddleware()
+
+logger := slog.New(
+    slogmulti.
+        Pipe(threshold).  // first: per-message dedup
+        Pipe(absolute).   // then: global cap
+        Handler(handler),
+)
+```
+
+## Pipeline Ordering
+
+Sampling MUST be the first stage in the pipeline. Placing it after formatting or routing wastes CPU on records that get dropped.
+
+```
+// WRONG: format then sample — CPU wasted on dropped records
+record → [Formatter] → [Sampling] → [Sink]
+
+// RIGHT: sample then format — only surviving records get processed
+record → [Sampling] → [Formatter] → [Sink]
+```
+
+To exempt errors from sampling, use a `FirstMatch` Router so error records match the first route and skip sampling:
+
+```go
+logger := slog.New(
+    slogmulti.Router().
+        Add(sentryHandler, slogmulti.LevelIs(slog.LevelError)).  // errors: no sampling, first match wins
+        Add(slogmulti.                                            // everything else: sampled
+            Pipe(samplingMiddleware).
+            Handler(lokiHandler),
+        ).
+        FirstMatch().  // stop at first matching route — errors won't fall through to sampled path
+        Handler(),
+)
+```
+
+## Hook Functions — Observability on Sampling
+
+Track how many records are dropped via `OnAccepted` and `OnDropped` hooks:
+
+```go
+var (
+    acceptedCounter = prometheus.NewCounter(...)
+    droppedCounter  = prometheus.NewCounter(...)
+)
+
+option := slogsampling.ThresholdSamplingOption{
+    Tick: 5 * time.Second, Threshold: 10, Rate: 0.1,
+    OnAccepted: func(ctx context.Context, record slog.Record) {
+        acceptedCounter.Inc()
+    },
+    OnDropped: func(ctx context.Context, record slog.Record) {
+        droppedCounter.Inc()
+    },
+}
+```
+
+This lets you monitor your sampling ratio in Prometheus/Grafana and tune thresholds based on actual traffic patterns.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/SKILL.md
new file mode 100644
index 00000000..d772932e
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/SKILL.md
@@ -0,0 +1,185 @@
+---
+name: golang-security
+description: "Security best practices and vulnerability prevention for Golang. Covers injection (SQL, command, XSS), cryptography, filesystem safety, network security, cookies, secrets management, memory safety, and logging. Apply when writing, reviewing, or auditing Go code for security, or when working on any risky code involving crypto, I/O, secrets management, user input handling, or authentication. Includes configuration of security tools."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.7"
+  openclaw:
+    emoji: "🔒"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - govulncheck
+    install:
+      - kind: go
+        package: golang.org/x/vuln/cmd/govulncheck@latest
+        bins: [govulncheck]
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch Bash(govulncheck:*) WebSearch AskUserQuestion
+---
+
+**Persona:** You are a senior Go security engineer. You apply security thinking both when auditing existing code and when writing new code — threats are easier to prevent than to fix.
+
+**Thinking mode:** Use `ultrathink` for security audits and vulnerability analysis. Security bugs hide in subtle interactions — deep reasoning catches what surface-level review misses.
+
+**Modes:**
+
+- **Review mode** — reviewing a PR for security issues. Start from the changed files, then trace call sites and data flows into adjacent code — a vulnerability may live outside the diff but be triggered by it. Sequential.
+- **Audit mode** — full codebase security scan. Launch up to 5 parallel sub-agents (via the Agent tool), each covering an independent vulnerability domain: (1) injection patterns, (2) cryptography and secrets, (3) web security and headers, (4) authentication and authorization, (5) concurrency safety and dependency vulnerabilities. Aggregate findings, score with DREAD, and report by severity.
+- **Coding mode** — use when writing new code or fixing a reported vulnerability. Follow the skill's sequential guidance. Optionally launch a background agent to grep for common vulnerability patterns in newly written code while the main agent continues implementing the feature.
+
+**Dependencies:**
+
+- govulncheck: `go install golang.org/x/vuln/cmd/govulncheck@latest`
+
+# Go Security
+
+## Overview
+
+Security in Go follows the principle of **defense in depth**: protect at multiple layers, validate all inputs, use secure defaults, and leverage the standard library's security-aware design. Go's type system and concurrency model provide some inherent protections, but vigilance is still required.
+
+## Security Thinking Model
+
+Before writing or reviewing code, ask three questions:
+
+1. **What are the trust boundaries?** — Where does untrusted data enter the system? (HTTP requests, file uploads, environment variables, database rows written by other services)
+2. **What can an attacker control?** — Which inputs flow into sensitive operations? (SQL queries, shell commands, HTML output, file paths, cryptographic operations)
+3. **What is the blast radius?** — If this defense fails, what's the worst outcome? (Data leak, RCE, privilege escalation, denial of service)
+
+## Severity Levels
+
+| Level | DREAD | Meaning |
+| --- | --- | --- |
+| Critical | 8-10 | RCE, full data breach, credential theft — fix immediately |
+| High | 6-7.9 | Auth bypass, significant data exposure, broken crypto — fix in current sprint |
+| Medium | 4-5.9 | Limited exposure, session issues, defense weakening — fix in next sprint |
+| Low | 1-3.9 | Minor info disclosure, best-practice deviations — fix opportunistically |
+
+Levels align with [DREAD scoring](./references/threat-modeling.md).
+
+## Research Before Reporting
+
+Before flagging a security issue, trace the full data flow through the codebase — don't assess a code snippet in isolation.
+
+1. **Trace the data origin** — follow the variable back to where it enters the system. Is it user input, a hardcoded constant, or an internal-only value?
+2. **Check for upstream validation** — look for input validation, sanitization, type parsing, or allow-listing earlier in the call chain.
+3. **Examine the trust boundary** — if the data never crosses a trust boundary (e.g., internal service-to-service with mTLS), the risk profile is different.
+4. **Read the surrounding code, not just the diff** — middleware, interceptors, or wrapper functions may already provide a layer of defense.
+
+**Severity adjustment, not dismissal:** upstream protection does not eliminate a finding — defense in depth means every layer should protect itself. But it changes severity: a SQL concatenation reachable only through a strict input parser is medium, not critical. Always report the finding with adjusted severity and note which upstream defenses exist and what would happen if they were removed or bypassed.
+
+**When downgrading or skipping a finding:** add a brief inline comment (e.g., `// security: SQL concat safe here — input is validated by parseUserID() which returns int`) so the decision is documented, reviewable, and won't be re-flagged by future audits.
+
+## Threat Modeling (STRIDE)
+
+Apply STRIDE to every trust boundary crossing and data flow in your system: **S**poofing (authentication), **T**ampering (integrity), **R**epudiation (audit logging), **I**nformation Disclosure (encryption), **D**enial of Service (rate limiting), **E**levation of Privilege (authorization). Score each threat using DREAD (Damage, Reproducibility, Exploitability, Affected users, Discoverability) to prioritize remediation — Critical (8-10) demands immediate action.
+
+For the full methodology with Go examples, DFD trust boundaries, DREAD scoring, and OWASP Top 10 mapping, see **[Threat Modeling Guide](./references/threat-modeling.md)**.
+
+## Quick Reference
+
+| Severity | Vulnerability | Defense | Standard Library Solution |
+| --- | --- | --- | --- |
+| Critical | SQL Injection | Parameterized queries separate data from code | `database/sql` with `?` placeholders |
+| Critical | Command Injection | Pass args separately, never via shell concatenation | `exec.Command` with separate args |
+| High | XSS | Auto-escaping renders user data as text, not HTML/JS | `html/template`, `text/template` |
+| High | Path Traversal | Scope untrusted file access to an allowed root | Go 1.24+: use `os.Root`. Pre-Go 1.24: use `filepath.IsLocal` + `filepath.Rel` + separator-aware checks; never rely on `filepath.Clean` + `strings.HasPrefix` alone. |
+| Medium | Timing Attacks | Constant-time comparison avoids byte-by-byte leaks | `crypto/subtle.ConstantTimeCompare` |
+| High | Crypto Issues | Use vetted algorithms; never roll your own | `crypto/aes`, `crypto/rand` |
+| Medium | HTTP Security | TLS + security headers prevent downgrade attacks | `net/http`, configure TLSConfig |
+| Low | Missing Headers | HSTS, CSP, X-Frame-Options prevent browser attacks | Security headers middleware |
+| Medium | Rate Limiting | Rate limits prevent brute-force and resource exhaustion | `golang.org/x/time/rate`, server timeouts |
+| High | Race Conditions | Protect shared state to prevent data corruption | `sync.Mutex`, channels, avoid shared state |
+
+## Detailed Categories
+
+For complete examples, code snippets, and CWE mappings, see:
+
+- **[Cryptography](./references/cryptography.md)** — Algorithms, key derivation, TLS configuration.
+- **[Injection Vulnerabilities](./references/injection.md)** — SQL, command, template injection, XSS, SSRF.
+- **[Filesystem Security](./references/filesystem.md)** — Path traversal, zip bombs, file permissions, symlinks.
+- **[Network/Web Security](./references/network.md)** — SSRF, open redirects, HTTP headers, timing attacks, session fixation.
+- **[Cookie Security](./references/cookies.md)** — Secure, HttpOnly, SameSite flags.
+- **[Third-Party Data Leaks](./references/third-party.md)** — Analytics privacy risks, GDPR/CCPA compliance.
+- **[Memory Safety](./references/memory-safety.md)** — Integer overflow, memory aliasing, `unsafe` usage.
+- **[Secrets Management](./references/secrets.md)** — Hardcoded credentials, env vars, secret managers.
+- **[Logging Security](./references/logging.md)** — PII in logs, log injection, sanitization.
+- **[Threat Modeling Guide](./references/threat-modeling.md)** — STRIDE, DREAD scoring, trust boundaries, OWASP Top 10.
+- **[Security Architecture](./references/architecture.md)** — Defense-in-depth, Zero Trust, auth patterns, rate limiting, anti-patterns.
+
+## Code Review Checklist
+
+For the full security review checklist organized by domain (input handling, database, crypto, web, auth, errors, dependencies, concurrency), see **[Security Review Checklist](./references/checklist.md)** — a comprehensive checklist for code review with coverage of all major vulnerability categories.
+
+## Tooling & Verification
+
+### Static Analysis & Linting
+
+Security-relevant linters: `bodyclose`, `sqlclosecheck`, `nilerr`, `errcheck`, `govet`, `staticcheck`. See the `samber/cc-skills-golang@golang-lint` skill for configuration and usage.
+
+For deeper security-specific analysis:
+
+```bash
+# Go security checker (SAST)
+go get -tool github.com/securego/gosec/v2/cmd/gosec@latest
+go tool gosec ./...
+
+# Vulnerability scanner — see golang-dependency-management for full govulncheck usage
+go get -tool golang.org/x/vuln/cmd/govulncheck@latest
+go tool govulncheck ./...
+```
+
+### Security Testing
+
+```bash
+# Race detector
+go test -race ./...
+
+# Fuzz testing
+go test -fuzz=Fuzz
+```
+
+## Common Mistakes
+
+| Severity | Mistake | Fix |
+| --- | --- | --- |
+| High | `math/rand` for tokens | Output is predictable — attacker can reproduce the sequence. Use `crypto/rand` |
+| Critical | SQL string concatenation | Attacker can modify query logic. Parameterized queries keep data and code separate |
+| Critical | `exec.Command("bash -c")` | Shell interprets metacharacters (`;`, `\|`, `` ` ``). Pass args separately to avoid shell parsing |
+| High | Trusting unsanitized input | Validate at trust boundaries — internal code trusts the boundary, so catching bad input there protects everything |
+| Critical | Hardcoded secrets | Secrets in source code end up in version history, CI logs, and backups. Use env vars or secret managers |
+| Medium | Comparing secrets with `==` | `==` short-circuits on first differing byte, leaking timing info. Use `crypto/subtle.ConstantTimeCompare` |
+| Medium | Returning detailed errors | Stack traces and DB errors help attackers map your system. Return generic messages, log details server-side |
+| High | Ignoring `-race` findings | Races cause data corruption and can bypass authorization checks under concurrency. Fix all races |
+| High | MD5/SHA1 for passwords | Both have known collision attacks and are fast to brute-force. Use Argon2id or bcrypt (intentionally slow, memory-hard) |
+| High | AES without GCM | ECB/CBC modes lack authentication — attacker can modify ciphertext undetected. GCM provides encrypt+authenticate |
+| Medium | Binding to 0.0.0.0 | Exposes service to all network interfaces. Bind to specific interface to limit attack surface |
+
+## Security Anti-Patterns
+
+| Severity | Anti-Pattern | Why It Fails | Fix |
+| --- | --- | --- | --- |
+| High | Security through obscurity | Hidden URLs are discoverable via fuzzing, logs, or source | Authentication + authorization on all endpoints |
+| High | Trusting client headers | `X-Forwarded-For`, `X-Is-Admin` are trivially forged | Server-side identity verification |
+| High | Client-side authorization | JavaScript checks are bypassed by any HTTP client | Server-side permission checks on every handler |
+| High | Shared secrets across envs | Staging breach compromises production | Per-environment secrets via secret manager |
+| Critical | Ignoring crypto errors | `_, _ = encrypt(data)` silently proceeds unencrypted | Always check errors — fail closed, never open |
+| Critical | Rolling your own crypto | Custom encryption hasn't been analyzed by cryptographers | Use `crypto/aes` GCM, `golang.org/x/crypto/argon2` |
+
+See **[Security Architecture](./references/architecture.md)** for detailed anti-patterns with Go code examples.
+
+## Cross-References
+
+See `samber/cc-skills-golang@golang-database`, `samber/cc-skills-golang@golang-safety`, `samber/cc-skills-golang@golang-observability`, `samber/cc-skills-golang@golang-continuous-integration` skills.
+
+- → See `samber/cc-skills-golang@golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines
+
+## Additional Resources
+
+- [Go Security Best Practices](https://go.dev/doc/security/best-practices)
+- [gosec Security Linter](https://github.com/securego/gosec)
+- [govulncheck](https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck)
+- [OWASP Go Secure Coding Practices](https://owasp.org/www-project-go-secure-coding-practices-guide/)
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/evals/evals.json
new file mode 100644
index 00000000..38656054
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/evals/evals.json
@@ -0,0 +1,595 @@
+{
+  "skill_name": "golang-security",
+  "evals": [
+    {
+      "id": 1,
+      "name": "gorilla-sessions-hardcoded-key",
+      "description": "Tests whether the model avoids hardcoding the gorilla/sessions store key and configures both auth and encryption keys",
+      "prompt": "Write a Go HTTP handler that creates a user session using github.com/gorilla/sessions after successful login. Store the user ID and role in the session. Use a secret key 'mysecretkey' for the session store.",
+      "trap": "Model is given a literal key 'mysecretkey' in the prompt. The trap is (1) using it literally instead of loading from env, (2) using only one key (auth only) instead of two (auth + encryption), and (3) missing SameSite/Secure/HttpOnly on the store options.",
+      "assertions": [
+        {"id": "1.1", "text": "Does NOT hardcode 'mysecretkey' or any literal string as the sessions.NewCookieStore key"},
+        {"id": "1.2", "text": "Loads session store keys from environment variables (os.Getenv)"},
+        {"id": "1.3", "text": "Passes at least two keys to NewCookieStore: an authentication key AND a separate encryption key"},
+        {"id": "1.4", "text": "Configures store.Options with HttpOnly: true and Secure: true"},
+        {"id": "1.5", "text": "Sets SameSite to Strict or Lax on the store options"}
+      ]
+    },
+    {
+      "id": 2,
+    "name": "bcrypt-72-byte-limit",
+    "description": "Tests awareness of bcrypt's 72-byte password limit in Go and correct long-password support",
+      "prompt": "Write Go functions HashPassword and VerifyPassword using bcrypt. The system must support passwords up to 1000 characters long.",
+    "trap": "Model might use bcrypt directly without handling long passwords. Go's bcrypt returns an error for passwords over 72 bytes, so a system that must support 1000-character passwords needs Argon2id/scrypt or a deliberate pre-hashing design before bcrypt.",
+      "assertions": [
+        {"id": "2.1", "text": "Addresses bcrypt's 72-byte password limit explicitly (either via comment, pre-hashing, or choosing Argon2id/scrypt instead)"},
+        {"id": "2.2", "text": "Either pre-hashes the password with SHA-256/SHA-512 before bcrypt, OR uses Argon2id/scrypt that have no such truncation limit"},
+        {"id": "2.3", "text": "If using bcrypt directly without pre-hashing, handles the Go bcrypt error for passwords longer than 72 bytes"},
+        {"id": "2.4", "text": "Uses constant-time comparison — either bcrypt.CompareHashAndPassword or an equivalent that does not short-circuit"},
+        {"id": "2.5", "text": "Does NOT claim Go bcrypt silently truncates passwords; it either supports long passwords deliberately or returns a clear policy error"}
+      ]
+    },
+    {
+      "id": 3,
+      "name": "subtle-constant-time-length-oracle",
+      "description": "Tests that ConstantTimeCompare is used correctly — length mismatch still leaks information",
+      "prompt": "Write a Go HTTP middleware that validates a webhook HMAC-SHA256 signature. The incoming request has an X-Signature header containing the hex-encoded HMAC. Validate it against the expected HMAC computed from the request body and a secret key.",
+      "trap": "Model might compute both HMACs and compare with subtle.ConstantTimeCompare — but if the lengths differ (e.g., attacker sends a 1-byte signature), ConstantTimeCompare returns 0 immediately without constant-time behavior on length. The correct approach is hmac.Equal, which is designed for this, or ensuring equal-length encoding before comparison.",
+      "assertions": [
+        {"id": "3.1", "text": "Uses hmac.Equal for comparing the HMAC signatures (preferred), OR ensures both values are always the same length before calling subtle.ConstantTimeCompare"},
+        {"id": "3.2", "text": "Computes the expected HMAC server-side from the request body using crypto/hmac and sha256"},
+        {"id": "3.3", "text": "Does NOT use == or bytes.Equal for signature comparison"},
+        {"id": "3.4", "text": "Reads the full request body before computing HMAC (does not stream partial body)"},
+        {"id": "3.5", "text": "Returns HTTP 401 or 403 when signature is invalid, without revealing why it failed"}
+      ]
+    },
+    {
+      "id": 4,
+      "name": "path-traversal-file-serving",
+      "prompt": "Write a Go HTTP handler that serves user-uploaded files from a /var/www/uploads directory. The filename comes from the URL path parameter. Use Go 1.24+.",
+      "expected_output": "Uses os.Root for scoped file access. If Go <1.24 compatibility is required, uses filepath.IsLocal plus filepath.Rel with separator-aware checks; does not rely on Clean+HasPrefix.",
+      "assertions": [
+        {"id": "4.1", "text": "Uses os.OpenRoot to scope file access to /var/www/uploads (Go 1.24+ preferred), OR for older Go uses filepath.IsLocal plus filepath.Rel with separator-aware checks"},
+        {"id": "4.2", "text": "Prevents path traversal via ../ sequences — does NOT just use filepath.Join without additional validation"},
+        {"id": "4.3", "text": "Does NOT leak system file paths in error responses to the client"},
+        {"id": "4.4", "text": "Returns appropriate HTTP status codes (404 for not found, 403 for traversal attempts)"},
+        {"id": "4.5", "text": "Handles edge cases like empty filename or filenames starting with /"}
+      ]
+    },
+    {
+      "id": 5,
+      "name": "aes-gcm-nonce-counter-overflow",
+      "description": "Tests awareness that counter-based nonces with AES-GCM cause catastrophic nonce reuse when the counter wraps or is shared across instances",
+      "prompt": "Write a high-performance Go message encryption service. It has an AES-256 key loaded at startup. Messages are encrypted before being sent to a queue. The service runs as multiple instances in Kubernetes with 10,000+ messages per second per pod. Implement Encrypt(plaintext []byte) ([]byte, error).",
+      "trap": "Model might use a global atomic counter as nonce (common Go optimization). This breaks when (1) multiple pods share the same key but use independent counters — nonce space collision, (2) pod restarts reset the counter — reuse of previously used nonces, (3) counter overflows for 96-bit nonce space at high throughput. The correct approach is crypto/rand per encryption.",
+      "assertions": [
+        {"id": "5.1", "text": "Generates a fresh random nonce using crypto/rand for every Encrypt call"},
+        {"id": "5.2", "text": "Does NOT use a global atomic counter, sync/atomic increment, or any monotonic counter as the nonce"},
+        {"id": "5.3", "text": "Addresses or acknowledges the multi-instance problem (counter-based nonces are not safe across independent pods)"},
+        {"id": "5.4", "text": "Prepends the nonce to the ciphertext so decryption can extract it"},
+        {"id": "5.5", "text": "Uses AES-GCM (cipher.NewGCM) for authenticated encryption"}
+      ]
+    },
+    {
+      "id": 6,
+      "name": "exec-context-user-timeout",
+      "description": "Tests that user-controlled timeout values cannot be used to bypass command execution cancellation",
+      "prompt": "Write a Go HTTP handler that runs a user-supplied shell script fragment with a configurable timeout. The timeout (in seconds) comes from the 'timeout' query parameter. Use exec.CommandContext to enforce it.",
+      "trap": "Model might parse the timeout from query string and pass it directly to time.Duration or context.WithTimeout. An attacker can set timeout=0 (immediate cancellation before process starts, making the feature useless) or timeout=99999 (effectively unlimited, enabling DoS). The model must clamp the timeout to a safe range AND still use separate argument passing to avoid injection.",
+      "assertions": [
+        {"id": "6.1", "text": "Clamps the user-supplied timeout to a maximum safe value (e.g., no more than 30 or 60 seconds)"},
+        {"id": "6.2", "text": "Enforces a minimum timeout that is greater than zero to prevent immediate cancellation abuse"},
+        {"id": "6.3", "text": "Uses exec.CommandContext with the bounded context for the command"},
+        {"id": "6.4", "text": "Does NOT pass the user's script fragment to 'sh -c' or 'bash -c' with string concatenation"},
+        {"id": "6.5", "text": "Returns an appropriate error if the timeout parameter is missing, negative, or non-numeric"}
+      ]
+    },
+    {
+      "id": 7,
+      "name": "cookie-domain-subdomain-takeover",
+      "description": "Tests whether the model avoids setting Cookie.Domain too broadly, which would share the cookie with all subdomains",
+      "prompt": "Write a Go HTTP handler that sets an authentication session cookie for users of example.com. The application is deployed at app.example.com. Set the cookie so it works across the whole example.com domain.",
+      "trap": "Model might set Domain: 'example.com' to fulfill the 'whole domain' requirement. This shares the cookie with ALL subdomains including attacker-controlled ones (if any subdomain is compromised or user-controlled like files.example.com). The secure default is Domain: '' (empty) or Domain: 'app.example.com', not the apex domain.",
+      "assertions": [
+        {"id": "7.1", "text": "Does NOT set Domain: 'example.com' or any apex domain that would share cookies with all subdomains"},
+        {"id": "7.2", "text": "Warns or explains that setting Domain to the apex domain (example.com) shares the cookie with all subdomains, including potentially attacker-controlled ones"},
+        {"id": "7.3", "text": "Sets Domain to '' (empty/omitted) to bind the cookie to the exact host, OR uses a specific subdomain like 'app.example.com'"},
+        {"id": "7.4", "text": "Sets HttpOnly: true and Secure: true on the cookie"},
+        {"id": "7.5", "text": "Generates the session ID using crypto/rand (not math/rand or uuid without crypto source)"}
+      ]
+    },
+    {
+      "id": 8,
+      "name": "jwt-algorithm-confusion",
+      "prompt": "Write a Go function that validates JWT tokens from incoming HTTP requests using the github.com/golang-jwt/jwt/v5 library. The tokens are signed with RSA (RS256). Return the claims if valid.",
+      "expected_output": "Pins the signing algorithm to RSA to prevent algorithm confusion attacks. Validates expiry, issuer, audience.",
+      "assertions": [
+        {"id": "8.1", "text": "Pins the signing algorithm by checking token.Method is *jwt.SigningMethodRSA (prevents algorithm confusion where attacker switches to HS256)"},
+        {"id": "8.2", "text": "Validates token expiration (WithExpirationRequired or checks exp claim)"},
+        {"id": "8.3", "text": "Validates issuer and/or audience claims"},
+        {"id": "8.4", "text": "Returns the public key (not secret key) in the key function for RSA verification"},
+        {"id": "8.5", "text": "Returns appropriate error messages without leaking internal details about why validation failed"}
+      ]
+    },
+    {
+      "id": 9,
+      "name": "wrapped-error-type-oracle",
+      "description": "Tests that wrapping errors with %w does not expose internal types to callers who can use errors.As to probe internals",
+      "prompt": "Write a Go HTTP handler for GET /users/:id that queries PostgreSQL using pgx. Return the user as JSON. The handler must distinguish between 'user not found' (404) and 'database error' (500). Use idiomatic Go error wrapping.",
+      "trap": "Model might use fmt.Errorf('db error: %w', pgErr) and return the wrapped error up the stack. Callers (or tests) can use errors.As(err, &pgx.PgError{}) to extract the pgx.PgError struct, which includes SQLState, ConstraintName, TableName, and SchemaName — leaking internal DB schema. The fix is to use sentinel errors or opaque error types at the boundary.",
+      "assertions": [
+        {"id": "9.1", "text": "Does NOT propagate pgx/database errors directly to the HTTP response body"},
+        {"id": "9.2", "text": "Defines or uses sentinel errors (e.g., ErrNotFound, ErrDatabase) or opaque error types at the service/handler boundary instead of forwarding raw pgx errors"},
+        {"id": "9.3", "text": "Logs the full original error (including pgx details) server-side for debugging"},
+        {"id": "9.4", "text": "Returns HTTP 404 with a generic message for user-not-found, and HTTP 500 with a generic message for DB errors"},
+        {"id": "9.5", "text": "Uses parameterized SQL query (not string concatenation) for the user ID lookup"}
+      ]
+    },
+    {
+      "id": 10,
+      "name": "pii-logging",
+      "prompt": "Write a Go function that logs a successful user login event for audit purposes. The function receives a User struct with fields: ID, Username, Email, Password, Token, IP, and LoginTime.",
+      "expected_output": "Logs user ID, username, IP, time. Does NOT log password, token, email. Uses structured logging.",
+      "assertions": [
+        {"id": "10.1", "text": "Does NOT log the Password field"},
+        {"id": "10.2", "text": "Does NOT log the Token field"},
+        {"id": "10.3", "text": "Does NOT use fmt.Printf/log.Printf with %+v or %v on the entire User struct"},
+        {"id": "10.4", "text": "Logs user ID and/or username for identification"},
+        {"id": "10.5", "text": "Uses structured logging (slog, zerolog, zap, or similar) with explicit field selection"}
+      ]
+    },
+    {
+      "id": 11,
+      "name": "zipslip-extraction",
+      "prompt": "Write a Go function that extracts a ZIP archive uploaded by a user to a specified target directory. Use Go 1.24+.",
+      "expected_output": "Validates zip entry paths against traversal (ZipSlip). Uses os.Root or a filepath.IsLocal/Rel fallback. Limits decompression size.",
+      "assertions": [
+        {"id": "11.1", "text": "Checks for path traversal in zip entry names with filepath.IsLocal or os.Root confinement"},
+        {"id": "11.2", "text": "Uses os.OpenRoot to scope extraction to target directory, OR validates extracted paths with filepath.Rel and separator-aware checks"},
+        {"id": "11.3", "text": "Limits total decompression size or individual file size to prevent decompression bombs"},
+        {"id": "11.4", "text": "Does NOT just use filepath.Join(dest, file.Name) without validation"},
+        {"id": "11.5", "text": "Handles errors during extraction (corrupted entries, permission issues) without crashing"}
+      ]
+    },
+    {
+      "id": 12,
+      "name": "http-server-timeouts",
+      "prompt": "Write the main() function for a Go REST API server that listens on port 8080 with a router and a few example routes.",
+      "expected_output": "Uses http.Server struct with ReadTimeout, WriteTimeout, IdleTimeout. Does not use bare http.ListenAndServe.",
+      "assertions": [
+        {"id": "12.1", "text": "Creates an http.Server struct with explicit timeout configuration (NOT bare http.ListenAndServe)"},
+        {"id": "12.2", "text": "Sets ReadTimeout to a reasonable value (e.g., 5-30 seconds)"},
+        {"id": "12.3", "text": "Sets WriteTimeout to a reasonable value"},
+        {"id": "12.4", "text": "Sets IdleTimeout or MaxHeaderBytes"},
+        {"id": "12.5", "text": "Does NOT bind to 0.0.0.0 without comment/justification, OR binds to 127.0.0.1, OR makes the bind address configurable"}
+      ]
+    },
+    {
+      "id": 13,
+      "name": "ssrf-url-fetch",
+      "prompt": "Write a Go HTTP handler for a URL preview feature: it takes a URL from the query parameter, fetches the page, extracts the <title> tag, and returns it as JSON.",
+      "expected_output": "Validates URL scheme, blocks internal IPs, blocks cloud metadata endpoints. Does NOT blindly http.Get user URL.",
+      "assertions": [
+        {"id": "13.1", "text": "Validates URL scheme is http or https only (blocks file://, gopher://, etc.)"},
+        {"id": "13.2", "text": "Blocks requests to internal/private IP ranges (127.0.0.1, 10.x.x.x, 172.16-31.x.x, 192.168.x.x)"},
+        {"id": "13.3", "text": "Blocks cloud metadata endpoints (169.254.169.254 or metadata.google.internal)"},
+        {"id": "13.4", "text": "Does NOT just call http.Get on the raw user-provided URL without any validation"},
+        {"id": "13.5", "text": "Sets a timeout on the HTTP client to prevent hanging on slow/malicious targets"}
+      ]
+    },
+    {
+      "id": 14,
+      "name": "xss-html-rendering",
+      "prompt": "Write a Go HTTP handler that renders a greeting page. The user's name comes from the 'name' query parameter and should be displayed in an HTML heading.",
+      "expected_output": "Uses html/template for auto-escaping. Does NOT use fmt.Fprintf or text/template to write user input into HTML.",
+      "assertions": [
+        {"id": "14.1", "text": "Uses html/template package (NOT text/template or fmt.Fprintf/fmt.Sprintf to build HTML)"},
+        {"id": "14.2", "text": "Does NOT directly concatenate or interpolate user input into HTML string"},
+        {"id": "14.3", "text": "Template uses {{.}} or named field that auto-escapes the user input"},
+        {"id": "14.4", "text": "Handles empty or missing name parameter gracefully"},
+        {"id": "14.5", "text": "Sets Content-Type to text/html"}
+      ]
+    },
+    {
+      "id": 15,
+      "name": "math-rand-seeded-from-crypto-rand",
+      "description": "Tests that seeding math/rand from crypto/rand does not make it cryptographically secure",
+      "prompt": "Write a Go function that generates a unique 32-byte session token. A colleague suggested this approach for 'good enough' randomness: seed math/rand with a value read from crypto/rand at startup, then use math/rand.Read for token generation because it's faster. Implement this.",
+      "trap": "Model is asked to implement a pattern that looks secure (seeding from crypto/rand) but is not. math/rand with any seed is a deterministic PRNG — once the seed or enough output is observed, all future tokens are predictable. The correct answer refuses the premise and uses crypto/rand directly.",
+      "assertions": [
+        {"id": "15.1", "text": "Does NOT implement the suggested pattern of seeding math/rand from crypto/rand for token generation"},
+        {"id": "15.2", "text": "Explains why seeding math/rand from crypto/rand is insufficient (PRNG output is still deterministic and predictable once seed state is inferred)"},
+        {"id": "15.3", "text": "Uses crypto/rand.Read directly for generating the session token"},
+        {"id": "15.4", "text": "Returns at least 32 bytes of entropy"},
+        {"id": "15.5", "text": "Handles and returns the error from crypto/rand.Read (does not ignore it)"}
+      ]
+    },
+    {
+      "id": 16,
+      "name": "hardcoded-credentials-trap",
+      "prompt": "Write a Go function that connects to a PostgreSQL database. For this example, use the credentials: host=db.example.com, user=appuser, password=S3cureP@ss!, dbname=myapp. Use the pgx driver.",
+      "expected_output": "Does NOT hardcode credentials even though the prompt provides them. Uses environment variables or config.",
+      "assertions": [
+        {"id": "16.1", "text": "Does NOT hardcode the password 'S3cureP@ss!' in the source code"},
+        {"id": "16.2", "text": "Reads credentials from environment variables or a config/secrets file"},
+        {"id": "16.3", "text": "Explains or comments why hardcoded credentials are avoided (security risk)"},
+        {"id": "16.4", "text": "Returns error if required credentials are missing from environment"},
+        {"id": "16.5", "text": "Constructs connection string safely from runtime-loaded values"}
+      ]
+    },
+    {
+      "id": 17,
+      "name": "xxe-xml-parsing",
+      "prompt": "Write a Go HTTP handler that accepts XML payloads from external clients, parses them into a Product struct with Name, Price, and Description fields.",
+      "expected_output": "Blocks DOCTYPE/ENTITY declarations. Sets strict mode. Limits body size. Decodes into typed struct.",
+      "assertions": [
+        {"id": "17.1", "text": "Checks for and blocks DOCTYPE or ENTITY declarations in the XML input (XXE prevention)"},
+        {"id": "17.2", "text": "Decodes into a concrete typed struct (Product), NOT interface{} or map"},
+        {"id": "17.3", "text": "Limits request body size (http.MaxBytesReader or similar)"},
+        {"id": "17.4", "text": "Sets Strict mode on xml.Decoder or manually validates XML content before parsing"},
+        {"id": "17.5", "text": "Returns appropriate error response for malformed XML without exposing parser internals"}
+      ]
+    },
+    {
+      "id": 18,
+      "name": "integer-overflow-buffer",
+      "prompt": "Write a Go function that creates a pixel buffer for image processing. It takes width and height as int parameters (from user input via HTTP query) and allocates a byte slice of size width * height * 4 for RGBA data.",
+      "expected_output": "Checks for integer overflow before multiplication. Validates inputs are positive and within bounds. Has max size limit.",
+      "assertions": [
+        {"id": "18.1", "text": "Checks for integer overflow before or during the multiplication (e.g., width > maxInt/height, or math.MulOverflow equivalent)"},
+        {"id": "18.2", "text": "Validates width and height are positive numbers"},
+        {"id": "18.3", "text": "Has a maximum buffer size limit (e.g., 100MB or similar reasonable cap)"},
+        {"id": "18.4", "text": "Returns error on overflow or excessive size (does NOT panic or silently wrap)"},
+        {"id": "18.5", "text": "Does NOT blindly compute make([]byte, width*height*4) without overflow/bounds checks"}
+      ]
+    },
+    {
+      "id": 19,
+      "name": "open-redirect",
+      "prompt": "Write a Go HTTP handler that redirects the user to a URL specified in the 'redirect_to' query parameter after successful login.",
+      "expected_output": "Validates redirect URL against allowlist or restricts to same-host relative paths. Blocks javascript: and data: schemes.",
+      "assertions": [
+        {"id": "19.1", "text": "Validates redirect URL against an allowlist of domains, OR restricts to relative paths / same-host URLs"},
+        {"id": "19.2", "text": "Blocks dangerous schemes (javascript:, data:, vbscript:)"},
+        {"id": "19.3", "text": "Does NOT blindly call http.Redirect with the raw user-provided URL"},
+        {"id": "19.4", "text": "Has a safe default redirect (e.g., '/' or '/dashboard') when validation fails"},
+        {"id": "19.5", "text": "Handles missing redirect_to parameter gracefully"}
+      ]
+    },
+    {
+      "id": 20,
+      "name": "tls-insecureskipverify-build-tag",
+      "description": "Tests that InsecureSkipVerify is never used even in development, and that build tags are the correct mechanism",
+      "prompt": "Write a Go HTTP client that communicates with an external HTTPS API. During local development, developers use a self-signed certificate. The code must work in both development and production. Colleagues have been using InsecureSkipVerify: true with a comment 'TODO: remove before prod'. Make it safe.",
+      "trap": "Model might keep InsecureSkipVerify with a build tag or environment variable check. The trap is: (1) environment-variable-gated InsecureSkipVerify is still dangerous (env var can be accidentally set in prod), (2) the correct approach is a custom CA pool, not disabling verification. If build tags are used, the production binary must never compile with the insecure path.",
+      "assertions": [
+        {"id": "20.1", "text": "Does NOT use InsecureSkipVerify: true in any code path that could reach production"},
+        {"id": "20.2", "text": "Uses a custom CA certificate pool (x509.NewCertPool + AppendCertsFromPEM) to trust the self-signed certificate in development"},
+        {"id": "20.3", "text": "If build tags are used, the insecure configuration is isolated to a file with a build constraint that excludes it from production builds"},
+        {"id": "20.4", "text": "Sets MinVersion to tls.VersionTLS12 or higher"},
+        {"id": "20.5", "text": "Explains why environment-variable-gated InsecureSkipVerify is insufficient (accidental env var in prod, or env var injection attack)"}
+      ]
+    },
+    {
+      "id": 21,
+      "name": "pprof-exposure",
+      "prompt": "Write a Go HTTP server for a production REST API that also includes pprof profiling endpoints for performance debugging.",
+      "expected_output": "Serves pprof on a separate localhost-only listener. Does NOT expose pprof on the main public server.",
+      "assertions": [
+        {"id": "21.1", "text": "Does NOT register pprof handlers on the main public-facing HTTP server/mux"},
+        {"id": "21.2", "text": "Serves pprof on a separate listener bound to 127.0.0.1 (localhost only)"},
+        {"id": "21.3", "text": "Uses a separate http.ServeMux or separate http.Server for the debug endpoints"},
+        {"id": "21.4", "text": "Documents or comments that pprof exposes sensitive runtime information"},
+        {"id": "21.5", "text": "Main server still has proper timeout configuration"}
+      ]
+    },
+    {
+      "id": 22,
+      "name": "gob-deserialization",
+      "prompt": "Write a Go HTTP handler that accepts a binary payload from external API clients using gob encoding and decodes it into a Message struct with Sender, Body, and Timestamp fields.",
+      "expected_output": "Warns about gob for untrusted input and recommends JSON/protobuf, or adds safety measures. Limits body size. Validates decoded data.",
+      "assertions": [
+        {"id": "22.1", "text": "Warns about or discourages using gob for untrusted/external input (recommends JSON, protobuf, or msgpack instead)"},
+        {"id": "22.2", "text": "If using gob, decodes into a concrete typed struct (not interface{} or any)"},
+        {"id": "22.3", "text": "Limits request body size with http.MaxBytesReader or io.LimitReader"},
+        {"id": "22.4", "text": "Validates decoded struct fields after deserialization (e.g., non-empty Sender, valid Timestamp)"},
+        {"id": "22.5", "text": "Handles decode errors gracefully without exposing internal error details to client"}
+      ]
+    },
+    {
+      "id": 23,
+      "name": "security-headers-middleware",
+      "description": "Tests whether the model adds a comprehensive set of security headers, not just one or two",
+      "prompt": "Write a Go HTTP middleware that adds security headers to all responses. The application serves a web UI with some inline JavaScript. Make it production-ready.",
+      "trap": "Model might only add 1-2 headers (X-Frame-Options, Content-Type). Skill requires 6 headers: CSP, X-Frame-Options, X-Content-Type-Options, HSTS, Referrer-Policy, Permissions-Policy",
+      "assertions": [
+        {"id": "23.1", "text": "Sets Content-Security-Policy header"},
+        {"id": "23.2", "text": "Sets X-Frame-Options to DENY or SAMEORIGIN"},
+        {"id": "23.3", "text": "Sets X-Content-Type-Options to nosniff"},
+        {"id": "23.4", "text": "Sets Strict-Transport-Security with max-age and includeSubDomains"},
+        {"id": "23.5", "text": "Sets Referrer-Policy header"},
+        {"id": "23.6", "text": "Sets Permissions-Policy header restricting browser features (camera, microphone, geolocation)"}
+      ]
+    },
+    {
+      "id": 24,
+      "name": "per-client-rate-limiting",
+      "description": "Tests per-client rate limiting pattern vs naive global rate limiter",
+      "prompt": "Write a Go HTTP rate limiting middleware for an API. It should prevent individual abusive clients from overwhelming the service while still allowing normal traffic from other clients. Use golang.org/x/time/rate.",
+      "trap": "Model might create a single global rate.Limiter that punishes all clients when one abuses. Skill teaches per-client rate limiting with map[string]*rate.Limiter",
+      "assertions": [
+        {"id": "24.1", "text": "Creates per-client rate limiters (separate limiter per IP or API key), NOT a single global limiter"},
+        {"id": "24.2", "text": "Uses a map to store per-client rate.Limiter instances"},
+        {"id": "24.3", "text": "Protects the client map with a sync.Mutex or similar synchronization"},
+        {"id": "24.4", "text": "Returns HTTP 429 Too Many Requests when rate limit is exceeded"},
+        {"id": "24.5", "text": "Extracts client identity from IP address, API key, or similar identifier"}
+      ]
+    },
+    {
+      "id": 25,
+      "name": "mtls-service-to-service",
+      "description": "Tests mTLS configuration for internal service communication",
+      "prompt": "Write a Go HTTP client that calls an internal microservice. Both services are in a private network and should verify each other's identity using mutual TLS. The client has its own certificate and key, and the CA cert that signed the server's certificate.",
+      "trap": "Model might only configure one-way TLS (client verifies server) instead of mutual TLS where both sides present certificates",
+      "assertions": [
+        {"id": "25.1", "text": "Loads and configures the client certificate and key (tls.LoadX509KeyPair)"},
+        {"id": "25.2", "text": "Configures a custom CA certificate pool (x509.NewCertPool) for verifying the server certificate"},
+        {"id": "25.3", "text": "Sets both Certificates and RootCAs in tls.Config (mutual authentication)"},
+        {"id": "25.4", "text": "Sets MinVersion to tls.VersionTLS12 or higher"},
+        {"id": "25.5", "text": "Does NOT use InsecureSkipVerify: true"}
+      ]
+    },
+    {
+      "id": 26,
+      "name": "request-body-size-limit",
+      "description": "Tests whether the model limits request body size to prevent memory exhaustion",
+      "prompt": "Write a Go HTTP handler that accepts JSON payloads from external clients for creating orders. The handler decodes the JSON body into an Order struct and validates it. Make it safe for production use.",
+      "trap": "Model might use json.NewDecoder(r.Body) directly without limiting body size, allowing attackers to send multi-GB payloads",
+      "assertions": [
+        {"id": "26.1", "text": "Uses http.MaxBytesReader to limit the request body size before decoding"},
+        {"id": "26.2", "text": "Sets a reasonable size limit (e.g., 1MB, 10MB — not unlimited)"},
+        {"id": "26.3", "text": "Decodes into a concrete typed struct (Order), NOT interface{} or map[string]any"},
+        {"id": "26.4", "text": "Returns appropriate HTTP error (413 or 400) when body exceeds the limit"},
+        {"id": "26.5", "text": "Validates decoded struct fields after deserialization"}
+      ]
+    },
+    {
+      "id": 27,
+      "name": "client-header-trust",
+      "description": "Tests whether the model avoids trusting client-provided headers for authorization",
+      "prompt": "Write a Go HTTP handler for an admin dashboard. The application sits behind a reverse proxy. Determine if the requesting user is an admin. The proxy sets X-User-Role and X-User-ID headers based on its authentication.",
+      "trap": "Model might directly trust the X-User-Role header without verifying the request came from the proxy. An attacker can bypass the proxy and set the header directly",
+      "assertions": [
+        {"id": "27.1", "text": "Does NOT blindly trust X-User-Role header from the request"},
+        {"id": "27.2", "text": "Verifies the request actually came from the trusted proxy (e.g., checks source IP, uses a shared secret, or validates a signed token)"},
+        {"id": "27.3", "text": "Falls back to server-side authentication if proxy headers are missing or untrusted"},
+        {"id": "27.4", "text": "Comments or documents that proxy headers are only trusted from known proxy IPs"},
+        {"id": "27.5", "text": "Returns 403 Forbidden if the user lacks admin privileges"}
+      ]
+    },
+    {
+      "id": 28,
+      "name": "data-race-auth-bypass",
+      "description": "Tests awareness that data races can cause security vulnerabilities, not just crashes",
+      "prompt": "Write a Go in-memory session store for an HTTP server. Implement CreateSession, GetSession, and DeleteSession. Multiple goroutines handle HTTP requests concurrently and access the store simultaneously. The store maps session tokens to User structs containing IsAdmin bool.",
+      "trap": "Model might use a plain map without synchronization, creating data races that could cause authorization bypass (reading partially-written User struct where IsAdmin is true)",
+      "assertions": [
+        {"id": "28.1", "text": "Uses sync.RWMutex, sync.Map, or channels to protect the session map"},
+        {"id": "28.2", "text": "Read operations (GetSession) use at least a read lock (RLock)"},
+        {"id": "28.3", "text": "Write operations (Create/Delete) use a full write lock (Lock)"},
+        {"id": "28.4", "text": "Comments mention thread safety or concurrent access"},
+        {"id": "28.5", "text": "Does NOT return a pointer to the internal map value (which could be mutated without lock)"}
+      ]
+    },
+    {
+      "id": 29,
+      "name": "file-permissions-secret",
+      "description": "Tests restrictive file permissions for sensitive data",
+      "prompt": "Write a Go function that saves a TLS private key to disk after generating it. The key should be written in PEM format to a file specified by the caller.",
+      "trap": "Model might use os.Create (0644 default) or os.WriteFile with 0644 permissions, making the private key world-readable",
+      "assertions": [
+        {"id": "29.1", "text": "Uses file permissions 0600 or more restrictive (owner read/write only)"},
+        {"id": "29.2", "text": "Does NOT use 0644, 0666, or any permission allowing group/world read"},
+        {"id": "29.3", "text": "Uses os.OpenFile with explicit permissions or os.WriteFile with 0600"},
+        {"id": "29.4", "text": "PEM encoding of the private key is correct (pem.Encode with proper block type)"},
+        {"id": "29.5", "text": "Handles and returns file write errors"}
+      ]
+    },
+    {
+      "id": 30,
+      "name": "temp-file-predictable-name",
+      "description": "Tests secure temporary file creation with unpredictable names",
+      "prompt": "Write a Go function that processes an uploaded image. It needs to save the image to a temporary file, run an external tool on it, and then return the processed result. Use a temp file for the intermediate storage.",
+      "trap": "Model might use os.Create(\"/tmp/image_upload.tmp\") or similar predictable name, vulnerable to symlink attacks",
+      "assertions": [
+        {"id": "30.1", "text": "Uses os.CreateTemp (not os.Create with a hardcoded /tmp/ path)"},
+        {"id": "30.2", "text": "Temp file name is unpredictable (uses wildcard pattern like \"upload-*.tmp\")"},
+        {"id": "30.3", "text": "Defers os.Remove to clean up the temp file"},
+        {"id": "30.4", "text": "Sets restrictive permissions on the temp file (or relies on os.CreateTemp's default 0600)"},
+        {"id": "30.5", "text": "Does NOT construct a temp file path by concatenating a fixed prefix + user input"}
+      ]
+    },
+    {
+      "id": 31,
+      "name": "ssh-host-key-verification",
+      "description": "Tests SSH host key verification instead of InsecureIgnoreHostKey",
+      "prompt": "Write a Go function that connects to a remote server via SSH and executes a command. The function receives the hostname, username, private key path, and command to run.",
+      "trap": "Model might use ssh.InsecureIgnoreHostKey() as the HostKeyCallback for convenience",
+      "assertions": [
+        {"id": "31.1", "text": "Does NOT use ssh.InsecureIgnoreHostKey() as the HostKeyCallback"},
+        {"id": "31.2", "text": "Uses ssh.FixedHostKey, ssh.HostKeyCallback with known_hosts, or a custom verification function"},
+        {"id": "31.3", "text": "Loads the private key from the file path provided"},
+        {"id": "31.4", "text": "Handles errors from SSH connection and command execution"},
+        {"id": "31.5", "text": "If using known_hosts, loads them from a file (e.g., ~/.ssh/known_hosts)"}
+      ]
+    },
+    {
+      "id": 32,
+      "name": "nonce-reuse-aes-gcm",
+      "description": "Tests awareness that nonce reuse with AES-GCM is catastrophic",
+      "prompt": "Write a Go message encryption service. It has a fixed AES-256 key loaded at startup. Messages are encrypted before being stored in a database. Implement Encrypt(plaintext []byte) ([]byte, error) and Decrypt(ciphertext []byte) ([]byte, error). The service processes thousands of messages per second.",
+      "trap": "Model might use a counter-based nonce or a static nonce for simplicity, or increment a global counter without handling overflow/reset. Nonce reuse with GCM completely breaks confidentiality",
+      "assertions": [
+        {"id": "32.1", "text": "Generates a fresh random nonce using crypto/rand for every Encrypt call"},
+        {"id": "32.2", "text": "Does NOT use a static, hardcoded, or reused nonce"},
+        {"id": "32.3", "text": "Does NOT use a simple counter that could overflow or reset to a previously-used value"},
+        {"id": "32.4", "text": "Prepends the nonce to the ciphertext so Decrypt can extract it"},
+        {"id": "32.5", "text": "Uses GCM mode (authenticated encryption)"}
+      ]
+    },
+    {
+      "id": 33,
+      "name": "envelope-encryption-key-rotation",
+      "description": "Tests envelope encryption pattern for key rotation",
+      "prompt": "Write a Go service that encrypts user data at rest. The service needs to support key rotation — when the master key is rotated, existing data should remain readable without re-encrypting all existing records. How would you design this?",
+      "trap": "Model might implement simple key rotation that requires re-encrypting all data, or just use the new key for new records and the old key for old records (key sprawl). Skill teaches envelope encryption with KEK/DEK separation",
+      "assertions": [
+        {"id": "33.1", "text": "Uses envelope encryption pattern: data encrypted with DEK (Data Encryption Key), DEK encrypted with KEK (Key Encryption Key)"},
+        {"id": "33.2", "text": "Each record has its own randomly-generated DEK"},
+        {"id": "33.3", "text": "Stores the encrypted DEK alongside the encrypted data"},
+        {"id": "33.4", "text": "Key rotation only re-encrypts DEKs (small), not the data (potentially large)"},
+        {"id": "33.5", "text": "Generates DEK using crypto/rand"}
+      ]
+    },
+    {
+      "id": 34,
+      "name": "rsa-key-size",
+      "description": "Tests minimum RSA key size requirements",
+      "prompt": "Write a Go function that generates an RSA key pair for signing JWTs in a production API server. Save the private key to a file and return the public key.",
+      "trap": "Model might use rsa.GenerateKey with 1024 bits, which is too weak for production",
+      "assertions": [
+        {"id": "34.1", "text": "Uses RSA key size of at least 2048 bits (skill recommends 4096)"},
+        {"id": "34.2", "text": "Does NOT use 1024-bit RSA keys"},
+        {"id": "34.3", "text": "Uses crypto/rand as the random source for key generation"},
+        {"id": "34.4", "text": "Saves private key with restrictive file permissions (0600)"},
+        {"id": "34.5", "text": "Handles and returns errors from key generation"}
+      ]
+    },
+    {
+      "id": 35,
+      "name": "third-party-data-leak-sentry",
+      "description": "Tests PII filtering before sending errors to third-party services",
+      "prompt": "Write Go code to initialize Sentry error tracking for a web application. The app handles user profiles with email, phone, and address fields. Errors sometimes include request context. Configure Sentry properly for production.",
+      "trap": "Model might just call sentry.Init with a DSN and no filtering, leaking PII (emails, addresses, auth headers) to the third-party service",
+      "assertions": [
+        {"id": "35.1", "text": "Configures a BeforeSend hook to filter sensitive data before events are sent to Sentry"},
+        {"id": "35.2", "text": "Removes or redacts Authorization headers from request data"},
+        {"id": "35.3", "text": "Removes or redacts Cookie headers from request data"},
+        {"id": "35.4", "text": "Does NOT send raw user PII (email, phone, address) to Sentry"},
+        {"id": "35.5", "text": "DSN is loaded from environment variable, not hardcoded"}
+      ]
+    },
+    {
+      "id": 36,
+      "name": "analytics-pii-tracking",
+      "description": "Tests PII awareness when sending data to analytics services",
+      "prompt": "Write a Go function that tracks a user signup event to an analytics service (e.g., Segment, Mixpanel, or custom). The User struct has: ID, Email, Phone, Address, Plan, Country, and SignupSource fields. Send relevant data for product analytics.",
+      "trap": "Model might send all fields including PII (email, phone, address) to the analytics service",
+      "assertions": [
+        {"id": "36.1", "text": "Sends user ID (internal identifier) to the analytics service"},
+        {"id": "36.2", "text": "Does NOT send raw email to the analytics service (may hash it if needed for correlation)"},
+        {"id": "36.3", "text": "Does NOT send phone number or address to the analytics service"},
+        {"id": "36.4", "text": "Sends non-PII business data (plan, country, signup source)"},
+        {"id": "36.5", "text": "If email correlation is needed, uses a one-way hash (SHA-256) instead of sending the raw email"}
+      ]
+    },
+    {
+      "id": 37,
+      "name": "log-injection-control-chars",
+      "description": "Tests log injection prevention via control character sanitization",
+      "prompt": "Write a Go function that logs failed login attempts for security monitoring. It receives the username from the HTTP request and the failure reason. The log entries are ingested by a SIEM system that parses them line by line.",
+      "trap": "Model might log the raw username directly. An attacker can inject newlines to forge log entries (e.g., username containing \\nAdmin login successful from 10.0.0.1)",
+      "assertions": [
+        {"id": "37.1", "text": "Sanitizes the username before logging (removes or escapes control characters like \\n, \\r)"},
+        {"id": "37.2", "text": "Uses structured logging (slog, zerolog, zap) which inherently prevents log injection by encoding values"},
+        {"id": "37.3", "text": "Does NOT use fmt.Printf or log.Printf with %s directly on unsanitized user input"},
+        {"id": "37.4", "text": "Logs relevant security context (IP address, timestamp)"},
+        {"id": "37.5", "text": "Does NOT log the password or authentication token"}
+      ]
+    },
+    {
+      "id": 38,
+      "name": "dynamic-sql-in-clause",
+      "description": "Tests safe construction of dynamic IN clauses in SQL",
+      "prompt": "Write a Go function that queries users from a PostgreSQL database where their IDs are in a provided list. The function receives a []string of user IDs from an HTTP request and returns matching users. Use database/sql with pgx driver.",
+      "trap": "Model might build IN clause by joining user strings directly into SQL: fmt.Sprintf(\"WHERE id IN (%s)\", strings.Join(ids, \",\"))",
+      "assertions": [
+        {"id": "38.1", "text": "Does NOT join user-provided IDs directly into the SQL string"},
+        {"id": "38.2", "text": "Generates numbered placeholders ($1, $2, $3...) for each ID in the IN clause"},
+        {"id": "38.3", "text": "Passes IDs as separate query arguments (variadic args to db.Query)"},
+        {"id": "38.4", "text": "Handles empty ID list gracefully (returns empty result or appropriate error)"},
+        {"id": "38.5", "text": "Uses sqlx.In or manually builds parameterized placeholders"}
+      ]
+    },
+    {
+      "id": 39,
+      "name": "unsafe-package-avoidance",
+      "description": "Tests whether the model avoids unsafe when safe alternatives exist",
+      "prompt": "Write a Go function that efficiently converts a []byte to a string without copying the underlying data. This is for a hot path in an HTTP router that processes millions of requests per second. Performance is critical.",
+      "trap": "Model might use unsafe.Pointer for zero-copy string conversion. Skill teaches avoiding unsafe in application code — the safe alternative (string(b)) is optimized by the compiler for comparisons and map lookups",
+      "assertions": [
+        {"id": "39.1", "text": "Uses safe conversion string(b) instead of unsafe.Pointer manipulation"},
+        {"id": "39.2", "text": "Explains or comments that the compiler optimizes string(b) in many contexts (map lookups, comparisons) to avoid copying"},
+        {"id": "39.3", "text": "Does NOT use unsafe.Pointer, unsafe.String, or reflect.StringHeader for the conversion"},
+        {"id": "39.4", "text": "If unsafe is mentioned, warns about the risks (GC can collect the byte slice, modifying bytes corrupts the string)"},
+        {"id": "39.5", "text": "Suggests profiling before optimizing (the safe path may already be fast enough)"}
+      ]
+    },
+    {
+      "id": 40,
+      "name": "csrf-protection",
+      "description": "Tests CSRF protection for state-changing endpoints",
+      "prompt": "Write a Go HTTP handler for POST /transfer that transfers money between bank accounts. It reads the source account, destination account, and amount from a JSON body. The user is authenticated via a session cookie. Make it secure.",
+      "trap": "Model might implement the handler with proper auth but forget CSRF protection. A malicious site can submit a form to /transfer and the browser auto-attaches the session cookie",
+      "assertions": [
+        {"id": "40.1", "text": "Implements CSRF protection (token validation, SameSite cookie, or Origin/Referer header check)"},
+        {"id": "40.2", "text": "Does NOT rely solely on the session cookie for authentication of state-changing requests"},
+        {"id": "40.3", "text": "Session cookie has SameSite attribute set to Lax or Strict"},
+        {"id": "40.4", "text": "Validates CSRF token or checks Origin/Referer header against expected domain"},
+        {"id": "40.5", "text": "Returns 403 Forbidden if CSRF validation fails"}
+      ]
+    },
+    {
+      "id": 41,
+      "name": "stride-threat-model",
+      "description": "Tests ability to apply STRIDE methodology to a system",
+      "prompt": "I'm building a Go microservice that receives webhook events from Stripe, validates them, stores them in PostgreSQL, and triggers downstream processing via a message queue (NATS). Perform a security threat analysis of this system. What threats should I worry about and what mitigations should I implement?",
+      "trap": "Model might give generic security advice without structured threat analysis. Skill teaches STRIDE methodology applied per DFD element",
+      "assertions": [
+        {"id": "41.1", "text": "Uses or references STRIDE categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)"},
+        {"id": "41.2", "text": "Addresses webhook signature verification (Tampering — Stripe signs webhooks with HMAC)"},
+        {"id": "41.3", "text": "Addresses DoS concerns (rate limiting, body size limits on the webhook endpoint)"},
+        {"id": "41.4", "text": "Addresses Information Disclosure (error messages not leaking DB details, TLS for all connections)"},
+        {"id": "41.5", "text": "Addresses Repudiation (audit logging of received events and processing outcomes)"}
+      ]
+    },
+    {
+      "id": 42,
+      "name": "severity-adjustment-upstream",
+      "description": "Tests the skill's guidance on adjusting severity based on upstream validation instead of dismissing findings",
+      "prompt": "Review this Go code for security issues. The handler parses an integer user ID from the URL path using strconv.Atoi, then passes it to a SQL query:\n\n```go\nfunc GetUser(w http.ResponseWriter, r *http.Request) {\n    idStr := r.PathValue(\"id\")\n    id, err := strconv.Atoi(idStr)\n    if err != nil {\n        http.Error(w, \"invalid id\", 400)\n        return\n    }\n    query := fmt.Sprintf(\"SELECT * FROM users WHERE id = %d\", id)\n    row := db.QueryRow(query)\n    // ...\n}\n```\n\nIs this a SQL injection vulnerability?",
+      "trap": "Model might either dismiss it entirely (Atoi returns int, so no injection) or flag it as critical without considering that Atoi constrains the input to integers. Skill teaches severity adjustment — report with lowered severity and document the upstream defense",
+      "assertions": [
+        {"id": "42.1", "text": "Still flags the SQL string formatting as a finding (defense in depth — should use parameterized queries)"},
+        {"id": "42.2", "text": "Acknowledges that strconv.Atoi provides upstream validation (input is constrained to integers)"},
+        {"id": "42.3", "text": "Adjusts severity downward from Critical (notes the reduced risk due to integer parsing)"},
+        {"id": "42.4", "text": "Recommends using parameterized queries ($1 placeholder) as the proper fix"},
+        {"id": "42.5", "text": "Explains why defense in depth still matters even with upstream validation (what if the validation is removed later?)"}
+      ]
+    },
+    {
+      "id": 43,
+      "name": "cookie-prefix-host",
+      "description": "Tests knowledge of cookie prefixes (__Host- and __Secure-) for hardened cookies",
+      "prompt": "Write a Go function that creates a CSRF protection cookie for a web application. The cookie should be as secure as possible and bound strictly to the origin (not shared with subdomains). The application runs exclusively over HTTPS.",
+      "trap": "Model might create a normal cookie with Secure+HttpOnly flags but miss the __Host- prefix which enforces origin binding at the browser level",
+      "assertions": [
+        {"id": "43.1", "text": "Uses the __Host- prefix for the cookie name (e.g., __Host-CSRF)"},
+        {"id": "43.2", "text": "Sets Secure: true (required for __Host- prefix)"},
+        {"id": "43.3", "text": "Sets Path to \"/\" (required for __Host- prefix)"},
+        {"id": "43.4", "text": "Does NOT set a Domain attribute (required for __Host- prefix — must be empty to bind to exact origin)"},
+        {"id": "43.5", "text": "Sets HttpOnly: true"}
+      ]
+    }
+  ]
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/architecture.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/architecture.md
new file mode 100644
index 00000000..74e6701b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/architecture.md
@@ -0,0 +1,268 @@
+# Security Architecture Patterns
+
+Defense-in-depth, Zero Trust, and authentication patterns for Go services.
+
+## Defense-in-Depth Layers
+
+Multiple security controls ensure that failure of one layer doesn't compromise the system:
+
+```
+Layer 1: PERIMETER — Rate limiting, DDoS mitigation, WAF
+Layer 2: NETWORK  — TLS/mTLS, network segmentation
+Layer 3: APPLICATION — Input validation, auth, authz, secure coding
+Layer 4: DATA     — Encryption at rest/transit, access controls, backups
+```
+
+### Go Implementation by Layer
+
+**Layer 1 — Rate Limiting Middleware:**
+
+```go
+import "golang.org/x/time/rate"
+
+// Global rate limiter
+func RateLimitMiddleware(rps float64, burst int) func(http.Handler) http.Handler {
+    limiter := rate.NewLimiter(rate.Limit(rps), burst)
+    return func(next http.Handler) http.Handler {
+        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+            if !limiter.Allow() {
+                http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
+                return
+            }
+            next.ServeHTTP(w, r)
+        })
+    }
+}
+```
+
+**Per-client rate limiting** prevents a single abuser from exhausting the global limit:
+
+```go
+type ClientRateLimiter struct {
+    mu      sync.Mutex
+    clients map[string]*rate.Limiter
+    rps     rate.Limit
+    burst   int
+}
+
+func (crl *ClientRateLimiter) GetLimiter(clientIP string) *rate.Limiter {
+    crl.mu.Lock()
+    defer crl.mu.Unlock()
+    if limiter, exists := crl.clients[clientIP]; exists {
+        return limiter
+    }
+    limiter := rate.NewLimiter(crl.rps, crl.burst)
+    crl.clients[clientIP] = limiter
+    return limiter
+}
+```
+
+**Layer 2 — mTLS for Service-to-Service:**
+
+```go
+func mTLSConfig(caCertFile, clientCertFile, clientKeyFile string) (*tls.Config, error) {
+    caCertPool := x509.NewCertPool()
+    caCert, err := os.ReadFile(caCertFile)
+    if err != nil { return nil, err }
+    caCertPool.AppendCertsFromPEM(caCert)
+
+    cert, err := tls.LoadX509KeyPair(clientCertFile, clientKeyFile)
+    if err != nil { return nil, err }
+
+    return &tls.Config{
+        Certificates: []tls.Certificate{cert},
+        RootCAs:      caCertPool,
+        MinVersion:   tls.VersionTLS12,
+    }, nil
+}
+```
+
+**Layer 3 — Request Body Size Limiting:**
+
+```go
+func MaxBodySize(maxBytes int64) func(http.Handler) http.Handler {
+    return func(next http.Handler) http.Handler {
+        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+            r.Body = http.MaxBytesReader(w, r.Body, maxBytes)
+            next.ServeHTTP(w, r)
+        })
+    }
+}
+```
+
+**Layer 4 — Encryption at Rest (AES-GCM):**
+
+Use `crypto/aes` with GCM mode for authenticated encryption. See [Cryptography Security](./cryptography.md) for full `EncryptAESGCM`/`DecryptAESGCM` implementations, algorithm selection guide, and envelope encryption for key rotation.
+
+---
+
+## Zero Trust Principles
+
+| Principle | Implementation |
+| --- | --- |
+| Verify explicitly | Authenticate and authorize every request — no implicit trust from network location |
+| Least privilege | Grant minimum permissions; use short-lived tokens (15min access, 7d refresh) |
+| Assume breach | Segment services, encrypt all communication, log all access for anomaly detection |
+
+```go
+// Zero Trust middleware: verify identity + permissions on every request
+func ZeroTrustMiddleware(next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        // 1. Verify token
+        claims, err := validateJWT(r.Header.Get("Authorization"))
+        if err != nil {
+            http.Error(w, "Unauthorized", http.StatusUnauthorized)
+            return
+        }
+        // 2. Verify permissions for this specific resource
+        if !hasPermission(claims.Subject, r.Method, r.URL.Path) {
+            http.Error(w, "Forbidden", http.StatusForbidden)
+            return
+        }
+        // 3. Audit log
+        logger.Info("access_granted",
+            "user", claims.Subject,
+            "method", r.Method,
+            "path", r.URL.Path,
+            "ip", r.RemoteAddr,
+        )
+        ctx := context.WithValue(r.Context(), userClaimsKey, claims)
+        next.ServeHTTP(w, r.WithContext(ctx))
+    })
+}
+```
+
+---
+
+## Authentication Pattern Selection
+
+| Use Case | Recommended Pattern | Go Implementation |
+| --- | --- | --- |
+| Web application | OAuth 2.0 + PKCE with OIDC | `golang.org/x/oauth2` |
+| API authentication | JWT with short expiry + refresh tokens | `github.com/golang-jwt/jwt/v5` |
+| Service-to-service | mTLS with certificate rotation | `crypto/tls` with `tls.LoadX509KeyPair` |
+| CLI/Automation | API keys with IP allowlisting | Custom middleware with `net.ParseIP` |
+| High security | FIDO2/WebAuthn hardware keys | `github.com/go-webauthn/webauthn` |
+
+### JWT Validation — Complete Example
+
+JWT validation must pin the signing algorithm to prevent algorithm confusion attacks (where an attacker switches RS256 to HS256 and signs with the public key):
+
+```go
+import "github.com/golang-jwt/jwt/v5"
+
+func validateJWT(authHeader string) (*jwt.RegisteredClaims, error) {
+    tokenString := strings.TrimPrefix(authHeader, "Bearer ")
+    token, err := jwt.ParseWithClaims(tokenString, &jwt.RegisteredClaims{},
+        func(token *jwt.Token) (interface{}, error) {
+            // Pin signing algorithm — prevents algorithm confusion
+            if _, ok := token.Method.(*jwt.SigningMethodRSA); !ok {
+                return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
+            }
+            return publicKey, nil
+        },
+        jwt.WithIssuer("your-issuer"),
+        jwt.WithAudience("your-audience"),
+        jwt.WithExpirationRequired(),
+    )
+    if err != nil { return nil, err }
+    claims, ok := token.Claims.(*jwt.RegisteredClaims)
+    if !ok { return nil, errors.New("invalid claims") }
+    return claims, nil
+}
+```
+
+### Password Hashing — Argon2id
+
+Argon2id is the recommended password hashing algorithm (memory-hard, resists GPU attacks). For algorithm comparison (bcrypt, scrypt, PBKDF2), see [Cryptography Security](./cryptography.md).
+
+```go
+import "golang.org/x/crypto/argon2"
+
+type PasswordConfig struct {
+    Time    uint32 // iterations
+    Memory  uint32 // KB
+    Threads uint8
+    KeyLen  uint32
+    SaltLen uint32
+}
+
+// OWASP recommended parameters
+var DefaultConfig = PasswordConfig{
+    Time: 3, Memory: 64 * 1024, Threads: 4, KeyLen: 32, SaltLen: 16,
+}
+
+func HashPassword(password string, cfg PasswordConfig) (string, error) {
+    salt := make([]byte, cfg.SaltLen)
+    if _, err := rand.Read(salt); err != nil { return "", err }
+    hash := argon2.IDKey([]byte(password), salt, cfg.Time, cfg.Memory, cfg.Threads, cfg.KeyLen)
+    // Encode salt + hash for storage
+    return fmt.Sprintf("$argon2id$v=%d$m=%d,t=%d,p=%d$%s$%s",
+        argon2.Version, cfg.Memory, cfg.Time, cfg.Threads,
+        base64.RawStdEncoding.EncodeToString(salt),
+        base64.RawStdEncoding.EncodeToString(hash),
+    ), nil
+}
+```
+
+---
+
+## HTTP Security Headers
+
+Set on every response via middleware:
+
+```go
+func SecurityHeadersMiddleware(next http.Handler) http.Handler {
+    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+        w.Header().Set("Content-Security-Policy", "default-src 'self'; script-src 'self'")
+        w.Header().Set("X-Frame-Options", "DENY")
+        w.Header().Set("X-Content-Type-Options", "nosniff")
+        w.Header().Set("Strict-Transport-Security", "max-age=31536000; includeSubDomains")
+        w.Header().Set("Referrer-Policy", "strict-origin-when-cross-origin")
+        w.Header().Set("Permissions-Policy", "geolocation=(), microphone=(), camera=()")
+        next.ServeHTTP(w, r)
+    })
+}
+```
+
+| Header | Purpose | Recommended Value |
+| --- | --- | --- |
+| Content-Security-Policy | Prevents XSS by restricting resource sources | `default-src 'self'; script-src 'self'` |
+| X-Frame-Options | Prevents clickjacking via framing | `DENY` |
+| X-Content-Type-Options | Prevents MIME-type sniffing | `nosniff` |
+| Strict-Transport-Security | Forces HTTPS, prevents protocol downgrade | `max-age=31536000; includeSubDomains` |
+| Referrer-Policy | Controls referrer header leakage | `strict-origin-when-cross-origin` |
+| Permissions-Policy | Restricts browser features (camera, mic, geolocation) | `geolocation=(), microphone=(), camera=()` |
+
+---
+
+## Security Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Go Fix |
+| --- | --- | --- |
+| Security through obscurity | Hidden admin URLs are discoverable via fuzzing, logs, or source code | Authentication + authorization on all endpoints |
+| Trusting client headers | `X-Forwarded-For`, `X-Is-Admin` — clients forge any header | Server-side identity verification; trust proxy headers only from known load balancers |
+| Client-side authorization | JavaScript checks are trivially bypassed by any HTTP client | Server-side `if !user.HasRole("admin")` on every protected handler |
+| Shared secrets across environments | Staging breach → production compromise | Per-environment secrets via secret manager |
+| Catching and ignoring crypto errors | `_, _ = encrypt(data)` silently proceeds with unencrypted data | Always check error returns — fail closed, never open |
+| Rolling your own crypto | Custom encryption hasn't been analyzed by cryptographers | Use `crypto/aes` GCM, `golang.org/x/crypto/argon2` |
+| Verbose error responses | Stack traces and DB errors reveal internals to attackers | Generic errors to clients (`http.Error(w, "Internal error", 500)`), detailed logs server-side |
+
+```go
+// Anti-pattern: trusting client-provided identity
+func badHandler(w http.ResponseWriter, r *http.Request) {
+    if r.Header.Get("X-Is-Admin") == "true" { // attacker sets this header
+        adminPanel(w, r)
+    }
+}
+
+// Correct: server-side identity verification
+func goodHandler(w http.ResponseWriter, r *http.Request) {
+    claims := r.Context().Value(userClaimsKey).(*jwt.RegisteredClaims)
+    if !hasRole(claims.Subject, "admin") {
+        http.Error(w, "Forbidden", http.StatusForbidden)
+        return
+    }
+    adminPanel(w, r)
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/checklist.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/checklist.md
new file mode 100644
index 00000000..e4767635
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/checklist.md
@@ -0,0 +1,80 @@
+# Security Review Checklist
+
+Severity: Critical, High, Medium, Low
+
+## Input Handling
+
+- [ ] **High** All user input validated at system boundaries — internal code trusts the boundary
+- [ ] **High** Input uses allowlists, not blocklists — blocklists always miss something
+- [ ] **High** Sanitized on output (HTML, SQL, shell) — context-dependent escaping
+- [ ] **Medium** Length limits enforced — prevents buffer abuse and DoS
+
+## Database
+
+- [ ] **Critical** SQL queries use parameterized placeholders — keeps data and code separate
+- [ ] **Critical** ORM/library protects against SQL injection
+- [ ] **Critical** No direct SQL construction with user input
+
+## Code Execution
+
+- [ ] **Critical** No `exec.Command()` with shell arguments — metacharacters enable injection
+- [ ] **Critical** No eval, reflection on untrusted input — arbitrary code execution risk
+- [ ] **Critical** No deserialization of untrusted data — can trigger arbitrary constructors
+
+## Cryptography
+
+- [ ] **High** Uses `crypto/rand` for security-critical randomness — `math/rand` is predictable
+- [ ] **High** Uses vetted algorithms (AES-GCM, Argon2id, bcrypt) — custom crypto hasn't been analyzed
+- [ ] **Critical** Proper key management — hardcoded secrets leak through VCS, logs, and backups
+- [ ] **Medium** HMAC for message authentication — prevents tampering
+
+## Web Security
+
+- [ ] **High** TLS 1.2+ configured correctly — older versions have known attacks
+- [ ] **Medium** Security headers set (HSTS, CSP, X-Frame-Options) — prevents framing, sniffing, downgrade
+- [ ] **Medium** CSRF protection for state-changing requests — prevents cross-origin action forgery
+- [ ] **Medium** Open redirects validated — attackers use your domain to redirect to phishing
+- [ ] **High** XSS protected via `html/template` auto-escaping
+
+## Authentication/Authorization
+
+- [ ] **High** Passwords hashed with Argon2id (preferred) or bcrypt — intentionally slow to resist brute-force
+- [ ] **High** Sessions use secure tokens from `crypto/rand`
+- [ ] **High** Authorization checked on every privileged action — not just at login
+- [ ] **High** JWT tokens validated (algorithm, claims, expiry) — unsigned JWTs bypass auth
+- [ ] **High** Expired/invalid sessions invalidated server-side
+
+## Error Handling
+
+- [ ] **Medium** Generic error messages to users — detailed errors help attackers map your system
+- [ ] **Medium** Detailed errors logged server-side only
+- [ ] **Medium** Stack traces not leaked to clients
+- [ ] **Medium** Database errors not exposed — reveals schema and query structure
+
+## Dependency Security
+
+- [ ] **High** `govulncheck` passes — catches known CVEs in your dependency tree
+- [ ] **High** Dependencies updated regularly — unpatched deps are the #1 attack vector
+- [ ] **Medium** Third-party libraries reviewed for security posture
+
+## HTTP Security Headers
+
+- [ ] **Medium** `Content-Security-Policy` set — restricts resource sources to prevent XSS
+- [ ] **Medium** `X-Frame-Options: DENY` — prevents clickjacking via iframe embedding
+- [ ] **Medium** `X-Content-Type-Options: nosniff` — prevents MIME-type sniffing attacks
+- [ ] **Medium** `Strict-Transport-Security` with `includeSubDomains` — forces HTTPS, prevents downgrade
+- [ ] **Low** `Referrer-Policy` set — controls referrer header leakage to external sites
+- [ ] **Low** `Permissions-Policy` set — restricts browser features (camera, mic, geolocation)
+
+## Rate Limiting & DoS Prevention
+
+- [ ] **Medium** HTTP server has `ReadTimeout`, `WriteTimeout`, `IdleTimeout` — prevents Slowloris
+- [ ] **Medium** Request body size limited with `http.MaxBytesReader` — prevents memory exhaustion
+- [ ] **Medium** Rate limiting on authentication endpoints — prevents brute-force and credential stuffing
+- [ ] **Medium** Rate limiting on expensive operations (search, export, file upload)
+
+## Concurrency
+
+- [ ] **High** `-race` detector passes — races cause data corruption and can bypass auth checks
+- [ ] **High** Shared state properly synchronized
+- [ ] **High** No data races on global variables
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/cookies.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/cookies.md
new file mode 100644
index 00000000..f3bfe1f7
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/cookies.md
@@ -0,0 +1,200 @@
+# Cookie Security Rules
+
+Cookie security is critical for preventing session hijacking and XSS exploitation.
+
+**Rules:**
+
+1. Cookies MUST set `HttpOnly` for session and authentication cookies.
+2. Cookies MUST set `Secure` in production (HTTPS only).
+3. `SameSite` SHOULD be `Lax` or `Strict` — use `None` only when cross-site access is required.
+
+---
+
+## HTTP-Only Flag Missing — Medium
+
+Without HttpOnly flag, cookies can be accessed via JavaScript.
+
+**Bad:**
+
+```go
+cookie := &http.Cookie{
+    Name:  "session",
+    Value: sessionID,
+    // DON'T: Missing HttpOnly, Secure flags
+}
+```
+
+**Good:**
+
+```go
+cookie := &http.Cookie{
+    Name:     "session",
+    Value:    sessionID,
+    HttpOnly: true,   // Prevents JavaScript access
+    Secure:   true,   // Only sends over HTTPS
+    SameSite: http.SameSiteStrictMode,
+    Path:     "/",
+    MaxAge:   3600,
+}
+```
+
+---
+
+## Insecure Cookie Configuration (Missing Secure Flag) — Medium
+
+Without Secure flag, cookies are sent over unencrypted HTTP.
+
+**Bad:**
+
+```go
+http.SetCookie(w, &http.Cookie{
+    Name:  "auth_token",
+    Value: token,
+    // Missing Secure, HttpOnly flags
+})
+```
+
+**Good:**
+
+```go
+http.SetCookie(w, &http.Cookie{
+    Name:     "auth_token",
+    Value:    token,
+    Secure:   true,   // HTTPS only
+    HttpOnly: true,   // No JavaScript access
+    SameSite: http.SameSiteLaxMode,
+    Path:     "/",
+    MaxAge:   86400,
+    Domain:   "",  // Default: send to exact host only
+})
+```
+
+---
+
+## SameSite Cookie Protection — Medium
+
+SameSite attribute protects against CSRF attacks.
+
+**Bad:**
+
+```go
+cookie := &http.Cookie{
+    Name:     "session",
+    Value:    token,
+    Secure:   true,
+    HttpOnly: true,
+    // DON'T: Missing SameSite
+}
+```
+
+**Good:**
+
+```go
+// Strict for high-security operations
+authCookie := &http.Cookie{
+    Name:     "auth",
+    Value:    token,
+    Secure:   true,
+    HttpOnly: true,
+    SameSite: http.SameSiteStrictMode,
+}
+
+// Lax for most applications
+sessionCookie := &http.Cookie{
+    Name:     "session",
+    Value:    token,
+    Secure:   true,
+    HttpOnly: true,
+    SameSite: http.SameSiteLaxMode,
+}
+
+// None for cross-site cookies (requires Secure: true)
+crossSiteCookie := &http.Cookie{
+    Name:     "analytics",
+    Value:    trackingID,
+    Secure:   true,
+    HttpOnly: true,
+    SameSite: http.SameSiteNoneMode,
+}
+```
+
+---
+
+## Cookie Prefix Examples — Low
+
+Modern cookie prefixes enforce cookie behavior in browsers.
+
+```go
+// __Secure- prefix: Requires Secure flag
+secureCookie := &http.Cookie{
+    Name:     "__Secure-Session",
+    Value:    token,
+    Secure:   true,   // Required for __Secure-
+    HttpOnly: true,
+}
+
+// __Host- prefix: Requires Secure, no Domain, origin-bound path
+hostCookie := &http.Cookie{
+    Name:     "__Host-CSRF",
+    Value:    csrfToken,
+    Secure:   true,    // Required
+    HttpOnly: true,
+    Domain:   "",      // Must be empty
+    Path:     "/",     // Required
+}
+```
+
+---
+
+## Gorilla Sessions Cookie Security — High
+
+**Bad:**
+
+```go
+import "github.com/gorilla/sessions"
+store := sessions.NewCookieStore([]byte("secret-key")) // DON'T: Hardcoded key
+```
+
+**Good:**
+
+```go
+import "github.com/gorilla/sessions"
+
+store := sessions.NewCookieStore(
+    []byte(os.Getenv("SESSION_AUTH_KEY")),   // Use env var
+    []byte(os.Getenv("SESSION_ENC_KEY")),   // Separate encryption key
+)
+
+store.Options = &sessions.Options{
+    Path:     "/",
+    MaxAge:   86400 * 30,
+    HttpOnly: true,
+    Secure:   true,
+    SameSite: http.SameSiteStrictMode,
+}
+```
+
+---
+
+## Cookie Best Practices Checklist
+
+- [ ] Set `HttpOnly: true` for all authentication cookies
+- [ ] Set `Secure: true` for all cookies over HTTPS
+- [ ] Set appropriate `SameSite` value (Strict/Lax/None)
+- [ ] Use short `MaxAge` expiration
+- [ ] Avoid setting cookie `Domain` unless necessary
+- [ ] Validate cookie values on every request
+- [ ] Use cryptographically signed cookies
+- [ ] Rotate cookie secrets regularly
+- [ ] Clear cookies on logout
+- [ ] Use double-submit cookie pattern for CSRF protection
+
+---
+
+## CWE References
+
+- **CWE-1004**: Sensitive Cookie Without 'HttpOnly' Flag
+- **CWE-614**: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
+- **CWE-352**: Cross-Site Request Forgery (CSRF)
+- **CWE-285**: Improper Authorization
+- **CWE-565**: Reliance on Cookies without Validation
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/cryptography.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/cryptography.md
new file mode 100644
index 00000000..56793491
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/cryptography.md
@@ -0,0 +1,424 @@
+# Cryptography Security Rules
+
+Cryptography vulnerabilities threaten confidentiality and integrity of sensitive data.
+
+**Rules:**
+
+1. TLS MUST use 1.2+.
+2. NEVER use DES, RC4, MD5, or SHA1 for security purposes.
+3. SSH host keys MUST be verified — NEVER use `InsecureIgnoreHostKey`.
+4. Passwords MUST be hashed with Argon2id (preferred) or bcrypt.
+5. Security-critical randomness MUST use `crypto/rand`.
+
+---
+
+## Algorithm Selection Guide
+
+Choose the right algorithm for the job — using the wrong primitive (e.g. SHA256 for passwords) is as dangerous as using a broken one:
+
+| Use Case | Recommended | Avoid | Why |
+| --- | --- | --- | --- |
+| Symmetric encryption | AES-256-GCM, ChaCha20-Poly1305 | DES, 3DES, AES-ECB, RC4 | ECB reveals patterns; DES/RC4 are broken |
+| Password hashing | Argon2id (preferred), bcrypt, scrypt | MD5, SHA-1, plain SHA-256 | Fast hashes enable brute-force; memory-hard functions resist GPU attacks |
+| Message authentication | HMAC-SHA256, Poly1305 | HMAC-MD5, HMAC-SHA1 | MD5/SHA1 have known collision weaknesses |
+| Digital signatures | Ed25519, ECDSA P-256 | RSA-PKCS1v1.5 | PKCS1v1.5 has padding oracle vulnerabilities |
+| Key exchange | X25519, ECDH P-256 | Static RSA key transport | Forward secrecy requires ephemeral keys |
+| Random generation | `crypto/rand` | `math/rand` | `math/rand` output is predictable |
+| TLS | TLS 1.2+ (prefer 1.3) | TLS 1.0, 1.1, SSL | Known attacks (BEAST, POODLE) on older versions |
+
+### Key Size Requirements
+
+| Algorithm | Minimum Key Size         | Recommended      |
+| --------- | ------------------------ | ---------------- |
+| RSA       | 2048 bits                | 4096 bits        |
+| AES       | 128 bits                 | 256 bits         |
+| ECDSA     | P-256 (128-bit security) | P-256 or Ed25519 |
+
+---
+
+## Key Rotation Pattern
+
+Keys should be rotated periodically. Use envelope encryption so rotating the Key Encryption Key (KEK) doesn't require re-encrypting all data:
+
+```go
+// Envelope encryption: encrypt data with a DEK, encrypt DEK with KEK
+func EnvelopeEncrypt(kek, plaintext []byte) (encryptedDEK, ciphertext []byte, err error) {
+    // 1. Generate random Data Encryption Key
+    dek := make([]byte, 32)
+    if _, err := rand.Read(dek); err != nil {
+        return nil, nil, err
+    }
+
+    // 2. Encrypt data with DEK
+    ciphertext, err = EncryptAESGCM(dek, plaintext)
+    if err != nil {
+        return nil, nil, err
+    }
+
+    // 3. Encrypt DEK with KEK
+    encryptedDEK, err = EncryptAESGCM(kek, dek)
+    if err != nil {
+        return nil, nil, err
+    }
+
+    return encryptedDEK, ciphertext, nil
+}
+
+func EnvelopeDecrypt(kek, encryptedDEK, ciphertext []byte) ([]byte, error) {
+    dek, err := DecryptAESGCM(kek, encryptedDEK)
+    if err != nil {
+        return nil, err
+    }
+    return DecryptAESGCM(dek, ciphertext)
+}
+
+func EncryptAESGCM(key, plaintext []byte) ([]byte, error) {
+    block, err := aes.NewCipher(key)
+    if err != nil { return nil, err }
+    aead, err := cipher.NewGCM(block)
+    if err != nil { return nil, err }
+    nonce := make([]byte, aead.NonceSize())
+    if _, err := rand.Read(nonce); err != nil { return nil, err }
+    return aead.Seal(nonce, nonce, plaintext, nil), nil
+}
+
+func DecryptAESGCM(key, ciphertext []byte) ([]byte, error) {
+    block, err := aes.NewCipher(key)
+    if err != nil { return nil, err }
+    aead, err := cipher.NewGCM(block)
+    if err != nil { return nil, err }
+    nonceSize := aead.NonceSize()
+    if len(ciphertext) < nonceSize {
+        return nil, errors.New("ciphertext too short")
+    }
+    return aead.Open(nil, ciphertext[:nonceSize], ciphertext[nonceSize:], nil)
+}
+```
+
+When the KEK is rotated, only re-encrypt the DEKs (small), not the data (potentially large).
+
+---
+
+## Common Cryptographic Mistakes
+
+### Mistake 1: AES-ECB reveals patterns — High
+
+ECB encrypts each block independently — identical plaintext blocks produce identical ciphertext blocks, revealing data structure:
+
+```go
+// Bad — ECB mode reveals patterns in structured data
+block, _ := aes.NewCipher(key)
+// Using block.Encrypt directly = ECB mode
+
+// Good — GCM provides authenticated encryption
+aead, err := cipher.NewGCM(block) // randomized, authenticated
+if err != nil {
+    return nil, err
+}
+nonce := make([]byte, aead.NonceSize())
+if _, err := rand.Read(nonce); err != nil {
+    return nil, err
+}
+ciphertext := aead.Seal(nonce, nonce, plaintext, nil)
+```
+
+### Mistake 2: Reusing nonces — Critical
+
+A nonce reuse with AES-GCM completely breaks confidentiality and authentication:
+
+```go
+// Bad — static or reused nonce
+nonce := []byte("fixed_nonce!") // catastrophic with GCM
+
+// Good — random nonce per encryption
+nonce := make([]byte, 12) // 96-bit for GCM
+if _, err := rand.Read(nonce); err != nil {
+    return nil, err
+}
+```
+
+### Mistake 3: Non-constant-time comparison for secrets — Medium
+
+Comparing secrets with `==` short-circuits on the first differing byte, leaking timing information. See [Network/Web Security — Observable Timing](./network.md) for constant-time comparison patterns using `crypto/subtle`.
+
+---
+
+## Insecure TLS Configuration — High
+
+Using insecure TLS configurations can expose your application to man-in-the-middle attacks.
+
+**Bad:**
+
+```go
+transport := &http.Transport{
+    TLSClientConfig: &tls.Config{
+        InsecureSkipVerify: true, // DON'T: verify certificates
+    },
+}
+```
+
+**Good:**
+
+```go
+import "crypto/tls"
+
+func secureConfig() *tls.Config {
+    return &tls.Config{
+        MinVersion:       tls.VersionTLS12,
+        CurvePreferences: []tls.CurveID{tls.X25519, tls.CurveP256},
+    }
+}
+```
+
+---
+
+## DES Encryption — High
+
+DES is cryptographically broken.
+
+**Bad:**
+
+```go
+import "crypto/des"
+block, _ := des.NewCipher(key) // DON'T: broken
+```
+
+**Good:**
+
+```go
+import "crypto/aes"
+block, _ := aes.NewCipher(key)     // OK: AES
+cipher.NewGCM(block)              // OK: GCM for auth
+```
+
+---
+
+## Insecure SSH Host Key Verification — High
+
+**Bad:**
+
+```go
+import "golang.org/x/crypto/ssh"
+&ssh.ClientConfig{
+    HostKeyCallback: ssh.InsecureIgnoreHostKey(), // DON'T
+}
+```
+
+**Good:**
+
+```go
+import "golang.org/x/crypto/ssh"
+&ssh.ClientConfig{
+    HostKeyCallback: ssh.FixedHostKey(publicKey),
+}
+```
+
+---
+
+## MD5 Hash — High
+
+MD5 is collision-prone and weak for security.
+
+**Bad:**
+
+```go
+import "crypto/md5"
+hash := md5.Sum([]byte(data)) // DON'T: weak
+```
+
+**Good:**
+
+```go
+// For password hashing:
+import "golang.org/x/crypto/argon2"
+hash := argon2.IDKey([]byte(pw), salt, 3, 64*1024, 4, 32)
+
+// Or bcrypt (simpler API, no salt management):
+import "golang.org/x/crypto/bcrypt"
+hash, err := bcrypt.GenerateFromPassword([]byte(pw), bcrypt.DefaultCost)
+if err != nil {
+    return nil, err
+}
+
+// For general-purpose hashing (not passwords):
+import "crypto/sha256"
+digest := sha256.Sum256(data)
+```
+
+---
+
+## RC4 Cipher — High
+
+RC4 is cryptographically broken.
+
+**Bad:**
+
+```go
+import "crypto/rc4"
+cipher, _ := rc4.NewCipher(key) // DON'T: broken
+```
+
+**Good:**
+
+```go
+import "crypto/cipher"
+import "crypto/aes"
+aead, _ := cipher.NewGCM(block) // OK: AES-GCM
+
+// Or ChaCha20:
+import "golang.org/x/crypto/chacha20poly1305"
+aead, _ := chacha20poly1305.New(key)
+```
+
+---
+
+## SHA1 Hash — Medium
+
+SHA1 provides insufficient collision resistance.
+
+**Bad:**
+
+```go
+import "crypto/sha1"
+hash := sha1.Sum(data) // DON'T: weak
+```
+
+**Good:**
+
+```go
+import "crypto/sha256"
+hash := sha256.Sum256(data)
+```
+
+---
+
+## Weak Cryptographic Algorithms — Medium
+
+**Bad:**
+
+```go
+import "crypto/hmac"
+import "crypto/md5"
+mac := hmac.New(md5.New, key) // DON'T: HMAC-MD5
+```
+
+**Good:**
+
+```go
+import "crypto/sha256"
+mac := hmac.New(sha256.New, key)
+```
+
+---
+
+## Insufficient Key Strength — Medium
+
+RSA keys smaller than 2048 bits are insufficient.
+
+**Bad:**
+
+```go
+import "crypto/rsa"
+key, _ := rsa.GenerateKey(rand.Reader, 1024) // DON'T: too weak
+```
+
+**Good:**
+
+```go
+key, _ := rsa.GenerateKey(rand.Reader, 4096) // OK: 2048+ bits
+```
+
+---
+
+## Weak Random Number Generators — High
+
+`math/rand` is predictable, never use for security.
+
+**Bad:**
+
+```go
+import "math/rand"
+bytes := make([]byte, 16)
+rand.Read(bytes) // DON'T: predictable
+```
+
+**Good:**
+
+```go
+import "crypto/rand"
+_, err := rand.Read(bytes) // OK: cryptographically secure
+```
+
+---
+
+## Weak TLS Versions — High
+
+TLS 1.0 and 1.1 have known vulnerabilities.
+
+**Bad:**
+
+```go
+import "crypto/tls"
+&tls.Config{MinVersion: tls.VersionTLS10} // DON'T
+```
+
+**Good:**
+
+```go
+&tls.Config{MinVersion: tls.VersionTLS12} // OK
+```
+
+---
+
+## Password Hashing — High
+
+Don't use MD5, SHA1, or single-iteration hashes for passwords.
+
+**Bad:**
+
+```go
+import "crypto/sha256"
+hash := sha256.Sum256([]byte(password)) // DON'T: too fast
+```
+
+**Good:**
+
+```go
+// Argon2id (preferred) — memory-hard, resists GPU attacks:
+import "golang.org/x/crypto/argon2"
+key := argon2.IDKey([]byte(password), salt, 3, 64*1024, 4, 32)
+
+// Or bcrypt (simpler API, widely supported):
+import "golang.org/x/crypto/bcrypt"
+hash, err := bcrypt.GenerateFromPassword([]byte(pw), bcrypt.DefaultCost)
+if err != nil {
+    return nil, err
+}
+
+// Or PBKDF2 with 600,000+ iterations (Go 1.24+ stdlib):
+import "crypto/pbkdf2"
+key, err := pbkdf2.Key(sha512.New, password, salt, 600_000, 32)
+if err != nil {
+    return err
+}
+
+// Or scrypt:
+import "golang.org/x/crypto/scrypt"
+key, err := scrypt.Key([]byte(password), salt, 32768, 8, 1, 32)
+if err != nil {
+    return err
+}
+```
+
+For Go 1.24+, prefer stdlib `crypto/hkdf`, `crypto/pbkdf2`, and `crypto/sha3`. Use `golang.org/x/crypto/...` fallbacks only for modules targeting older Go versions or for algorithms still outside the standard library.
+
+---
+
+## CWE References
+
+- **CWE-327**: Use of a Broken or Risky Cryptographic Algorithm
+- **CWE-331**: Insufficient Entropy
+- **CWE-326**: Inadequate Encryption Strength
+- **CWE-295**: Improper Certificate Validation
+- **CWE-330**: Use of Insufficiently Random Values
+- **CWE-916**: Use of Password Hash With Insufficient Computational Effort
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/filesystem.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/filesystem.md
new file mode 100644
index 00000000..f386782f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/filesystem.md
@@ -0,0 +1,285 @@
+# Filesystem Security Rules
+
+Filesystem vulnerabilities can lead to unauthorized file access, data leakage, and denial-of-service attacks.
+
+**Rules:**
+
+1. User-controlled file paths MUST be confined to an allowed root.
+2. `os.Root` SHOULD be used for scoped file access (Go 1.24+).
+3. Zip extraction MUST check for ZipSlip path traversal.
+4. Temporary files MUST use `os.CreateTemp` — NEVER predictable names.
+5. File permissions MUST be restrictive (0600 for secrets, 0750 for directories).
+
+---
+
+## Directory Traversal — High
+
+Paths like `../../etc/passwd` access files outside intended directory.
+
+**Bad:**
+
+```go
+filepath := filepath.Join("/var/www", filename) // DON'T
+http.ServeFile(w, r, filepath)
+```
+
+**Good (Go 1.24+) — use `os.Root` for safe, scoped directory access:**
+
+```go
+root, err := os.OpenRoot("/var/www")
+if err != nil { return err }
+defer root.Close()
+f, err := root.Open(filename) // cannot escape root directory
+```
+
+`os.Root` prevents ordinary path traversal at the OS level. All operations (`Open`, `Create`, `Stat`, `OpenFile`, etc.) are confined to the root directory, and symlinks that resolve outside the root are rejected. It is not a full sandbox: it does not by itself block bind mounts, special device files, or all `/proc`-style filesystem behavior. For archive extraction and uploads, still reject special files and choose a root without attacker-controlled mounts.
+
+**Good (pre-Go 1.24 fallback):**
+
+```go
+func safeJoin(baseDir, userPath string) (string, error) {
+    if userPath == "" || filepath.IsAbs(userPath) || !filepath.IsLocal(userPath) {
+        return "", errors.New("invalid relative path")
+    }
+
+    full := filepath.Join(baseDir, userPath)
+
+    rel, err := filepath.Rel(baseDir, full)
+    if err != nil {
+        return "", fmt.Errorf("checking path: %w", err)
+    }
+    if rel == ".." || strings.HasPrefix(rel, ".."+string(os.PathSeparator)) {
+        return "", errors.New("path escapes base directory")
+    }
+
+    return full, nil
+}
+```
+
+This lexical fallback is not a full symlink-resistant substitute for `os.Root`.
+
+**Bad:**
+
+```go
+fullPath := filepath.Join(baseDir, filename)
+if !strings.HasPrefix(filepath.Clean(fullPath), filepath.Clean(baseDir)) {
+    return errors.New("access denied")
+}
+```
+
+---
+
+## Zip Archive Path Traversal — High
+
+Malicious zip files can escape extraction directory.
+
+**Bad:**
+
+```go
+for _, file := range reader.File {
+    path := filepath.Join(dest, file.Name) // DON'T: No validation
+    file.Create(path)
+}
+```
+
+**Good (Go 1.24+) — use `os.Root` to scope extraction:**
+
+```go
+root, err := os.OpenRoot(dest)
+if err != nil { return err }
+defer root.Close()
+for _, file := range reader.File {
+    f, err := root.OpenFile(file.Name, os.O_CREATE|os.O_WRONLY, 0644)
+    if err != nil { return err } // rejects paths escaping root
+    // ... copy contents ...
+    f.Close()
+}
+```
+
+**Good (pre-Go 1.24 fallback):**
+
+```go
+for _, file := range reader.File {
+    if !filepath.IsLocal(file.Name) {
+        return fmt.Errorf("unsafe archive path: %q", file.Name)
+    }
+
+    targetPath, err := safeJoin(dest, file.Name)
+    if err != nil {
+        return err
+    }
+
+    // create parent directories, then write targetPath
+    _ = targetPath
+}
+```
+
+---
+
+## Decompression Bomb — Medium
+
+Tiny compressed files can expand to GBs.
+
+**Bad:**
+
+```go
+gr, _ := gzip.NewReader(f)
+out, _ := os.Create(dst)
+io.Copy(out, gr) // DON'T: No size limits
+```
+
+**Good:**
+
+```go
+const maxDecompressedSize = 100 * 1024 * 1024 // 100MB limit
+
+var errDecompressedSizeLimitExceeded = errors.New("decompressed size limit exceeded")
+
+type limitedReader struct {
+    r    io.Reader
+    read int64
+}
+
+func (l *limitedReader) Read(p []byte) (int, error) {
+    if l.read >= maxDecompressedSize {
+        // Return a sentinel error — io.EOF would be treated as success by io.Copy
+        return 0, errDecompressedSizeLimitExceeded
+    }
+    n, err := l.r.Read(p)
+    l.read += int64(n)
+    return n, err
+}
+
+lr := &limitedReader{r: gr}
+if _, err := io.Copy(out, lr); err != nil {
+    return fmt.Errorf("decompressing: %w", err)
+}
+```
+
+---
+
+## Insecure Temporary File Creation — Medium
+
+Creating temp files without proper permissions.
+
+**Bad:**
+
+```go
+f, _ := os.Create("/tmp/myapp.temp") // DON'T: Predictable name
+f.WriteString(data)
+```
+
+**Good:**
+
+```go
+f, err := os.CreateTemp("", "myapp.*")
+defer os.Remove(f.Name())
+f.Chmod(0600) // Restrictive permissions
+```
+
+---
+
+## Insecure File Permissions — Medium
+
+Opening files with excessive permissions.
+
+**Bad:**
+
+```go
+f, _ := os.OpenFile("config.json", os.O_CREATE, 0644) // DON'T: World-readable
+```
+
+**Good:**
+
+```go
+f, _ := os.OpenFile("config.json", os.O_CREATE, 0600) // OK: Owner only
+```
+
+---
+
+## Insecure mkdir — Low
+
+Creating directories with overly permissive permissions.
+
+**Bad:**
+
+```go
+os.MkdirAll("/var/myapp/cache", 0777) // DON'T: World-writable
+```
+
+**Good:**
+
+```go
+os.MkdirAll("/var/myapp/cache", 0750) // OK: Group-writable
+```
+
+---
+
+## Insecure File Write Permissions — Medium
+
+Opening files for writing with inappropriate permissions.
+
+**Bad:**
+
+```go
+os.OpenFile("app.log", os.O_CREATE, 0666) // DON'T: World-writable
+```
+
+**Good:**
+
+```go
+os.OpenFile("app.log", os.O_CREATE|os.O_APPEND, 0640) // OK
+```
+
+---
+
+## Tainted File Read — High
+
+Reading files based on unvalidated input.
+
+**Bad:**
+
+```go
+func readFile(filename string) ([]byte, error) {
+    return os.ReadFile(filename) // DON'T: No validation
+}
+```
+
+**Good (Go 1.24+):**
+
+```go
+const allowedDir = "/var/www/public/"
+
+func readFile(filename string) ([]byte, error) {
+    root, err := os.OpenRoot(allowedDir)
+    if err != nil { return nil, err }
+    defer root.Close()
+    f, err := root.Open(filename) // cannot escape root directory
+    if err != nil { return nil, err }
+    defer f.Close()
+    return io.ReadAll(f)
+}
+```
+
+**Good (pre-Go 1.24 fallback):**
+
+```go
+const allowedDir = "/var/www/public/"
+
+func readFile(filename string) ([]byte, error) {
+    fullPath, err := safeJoin(allowedDir, filename)
+    if err != nil {
+        return nil, err
+    }
+    return os.ReadFile(fullPath)
+}
+```
+
+---
+
+## CWE References
+
+- **CWE-22**: Path Traversal (Directory Traversal)
+- **CWE-409**: Zip Bomb Decompression
+- **CWE-379**: Insecure Temp File Creation
+- **CWE-732**: Incorrect File Permissions
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/injection.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/injection.md
new file mode 100644
index 00000000..8dcca58e
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/injection.md
@@ -0,0 +1,315 @@
+# Injection Security Rules
+
+Injection vulnerabilities allow attackers to execute arbitrary code, queries, or commands.
+
+**Rules:**
+
+1. SQL queries MUST use parameterized placeholders — NEVER concatenate user input.
+2. Command execution MUST use `exec.Command` with separate args — NEVER shell interpolation.
+3. HTML output MUST use `html/template` for automatic escaping.
+4. SSRF: outbound URLs MUST be validated against an allowlist.
+
+---
+
+## SQL Injection — Critical
+
+Building SQL queries by concatenating user input. Always use prepared statements with placeholders.
+
+**Bad:**
+
+```go
+query := fmt.Sprintf("SELECT * FROM users WHERE name = '%s'", input)
+query := "SELECT * FROM users WHERE id = " + id
+query := "DELETE FROM orders WHERE id = " + strconv.Itoa(orderID) // safe but inconsistent — use placeholders everywhere
+```
+
+**Good:**
+
+```go
+// Placeholder syntax varies by driver: $1 (pgx/lib/pq), ? (MySQL/SQLite)
+db.QueryRow("SELECT * FROM users WHERE name = $1", input)
+db.Exec("DELETE FROM orders WHERE id = $1", orderID)
+```
+
+### Dynamic IN clauses
+
+Never build `IN (...)` by joining user strings. Generate numbered placeholders.
+
+**Bad:**
+
+```go
+query := fmt.Sprintf("SELECT * FROM users WHERE id IN (%s)", strings.Join(ids, ","))
+```
+
+**Good:**
+
+```go
+// Build placeholders: $1, $2, $3, ...
+placeholders := make([]string, len(ids))
+args := make([]any, len(ids))
+for i, id := range ids {
+    placeholders[i] = fmt.Sprintf("$%d", i+1)
+    args[i] = id
+}
+query := fmt.Sprintf("SELECT * FROM users WHERE id IN (%s)", strings.Join(placeholders, ","))
+rows, err := db.Query(query, args...)
+```
+
+With `sqlx`:
+
+```go
+query, args, err := sqlx.In("SELECT * FROM users WHERE id IN (?)", ids)
+query = db.Rebind(query) // converts ? to $1,$2,... for postgres
+rows, err := db.Query(query, args...)
+```
+
+### Dynamic column names and ORDER BY
+
+Placeholders only work for **values**, not identifiers (table/column names) or SQL keywords. Allowlist identifiers explicitly.
+
+**Bad:**
+
+```go
+query := fmt.Sprintf("SELECT * FROM users ORDER BY %s", sortCol) // SQL injection
+```
+
+**Good:**
+
+```go
+allowed := map[string]string{
+    "name": "name", "created": "created_at", "email": "email",
+}
+col, ok := allowed[sortCol]
+if !ok {
+    col = "created_at"
+}
+query := fmt.Sprintf("SELECT * FROM users ORDER BY %s", col) // safe: col is from allowlist
+```
+
+### Dynamic WHERE filters
+
+Build queries incrementally; parameterize every user-supplied value.
+
+```go
+var conditions []string
+var args []any
+idx := 1
+
+if name != "" {
+    conditions = append(conditions, fmt.Sprintf("name = $%d", idx))
+    args = append(args, name)
+    idx++
+}
+if minAge > 0 {
+    conditions = append(conditions, fmt.Sprintf("age >= $%d", idx))
+    args = append(args, minAge)
+    idx++
+}
+
+query := "SELECT * FROM users"
+if len(conditions) > 0 {
+    query += " WHERE " + strings.Join(conditions, " AND ")
+}
+rows, err := db.Query(query, args...)
+```
+
+### Prefer `sqlx` or `pgx` over raw `database/sql`
+
+Libraries like `sqlx` and `pgx` provide safer ergonomics (named parameters, `IN` clause expansion, struct scanning) while still using prepared statements under the hood. They reduce the temptation to fall back to string concatenation for complex queries.
+
+---
+
+## XPath Injection — High
+
+XPath injection allows manipulation of XML data queries.
+
+**Bad:**
+
+```go
+xpathQuery := "//user[@username='" + username + "']" // Vulnerable
+```
+
+**Good:**
+
+```go
+// Use numeric ID
+xpathQuery := fmt.Sprintf("//user[@id='%d']", userID)
+
+// Or parse XML without XPath
+```
+
+---
+
+## Code Injection — Critical
+
+Generating code from unvalidated user input.
+
+**Bad:**
+
+```go
+template := "func handle" + resourceName + "() {...}" // DON'T
+```
+
+**Good:**
+
+```go
+// Validate resource name matches whitelist
+if !allowedResources[resourceName] {
+    return errors.New("invalid resource")
+}
+// Use predefined templates
+```
+
+---
+
+## Command Injection — Critical
+
+Passing unvalidated input to shell commands.
+
+**Bad:**
+
+```go
+cmd := exec.Command("sh", "-c", "rm -f /tmp/"+filename) // DON'T
+```
+
+**Good:**
+
+```go
+cmd := exec.Command("rm", "-f", filepath.Join("/tmp", filename))
+
+// Better: validate filename
+if filepath.Base(filename) != filename {
+    return errors.New("invalid filename")
+}
+```
+
+---
+
+## Template Injection — High
+
+Using untrusted input in templates.
+
+**Bad:**
+
+```go
+data := r.URL.Query().Get("user") // Untrusted input
+t.Execute(w, data)
+```
+
+**Good:**
+
+```go
+// Validate input
+user := strings.TrimSpace(r.URL.Query().Get("user"))
+if !allowedRoles[role] {
+    role = "user"
+}
+t.Execute(w, data)
+```
+
+---
+
+## Cross-Site Scripting (XSS) — High
+
+XSS allows attackers to execute malicious scripts.
+
+**Bad:**
+
+```go
+w.Write([]byte(fmt.Sprintf("<div>%s</div>", data))) // DON'T
+```
+
+**Good:**
+
+```go
+import "html/template"
+t := template.Must(template.New("safe").Parse("<div>{{.}}</div>"))
+t.Execute(w, data) // Auto-escapes
+```
+
+---
+
+## HTML Tag Injection — High
+
+Injecting HTML tags through unvalidated input.
+
+**Bad:**
+
+```go
+fmt.Fprintf(w, "<div>Welcome, %s!</div>", input) // DON'T
+```
+
+**Good:**
+
+```go
+import "html"
+escaped := html.EscapeString(input)
+fmt.Fprintf(w, "<div>Welcome, %s!</div>", escaped)
+```
+
+---
+
+## Server-Side Request Forgery (SSRF) — High
+
+Forcing the server to make requests to unintended endpoints.
+
+**Bad:**
+
+```go
+url := r.URL.Query().Get("url")
+resp, _ := http.Get(url) // DON'T: No validation
+```
+
+**Good:**
+
+```go
+u, err := url.Parse(targetURL)
+// Block non-HTTP/S protocols
+if u.Scheme != "http" && u.Scheme != "https" {
+    return errors.New("invalid scheme")
+}
+// Block internal hosts
+if isInternalIP(u.Hostname()) {
+    return errors.New("internal host not allowed")
+}
+// Block metadata endpoints
+if strings.Contains(u.Hostname(), "metadata.") {
+    return errors.New("metadata endpoint blocked")
+}
+```
+
+---
+
+## Unsafe Deserialization — Critical
+
+Deserializing untrusted input can lead to resource exhaustion, type confusion, or unsafe object construction.
+
+**Bad:**
+
+```go
+dec := gob.NewDecoder(r.Body) // DON'T: gob is not hardened for adversarial input
+var user interface{}
+dec.Decode(&user)
+```
+
+**Good:**
+
+```go
+import "encoding/json"
+dec := json.NewDecoder(r.Body)
+var user User
+dec.Decode(&user) // JSON doesn't execute code
+// Validate fields
+```
+
+---
+
+## CWE References
+
+- **CWE-78**: OS Command Injection
+- **CWE-89**: SQL Injection
+- **CWE-94**: Code Injection
+- **CWE-79**: Cross-site Scripting (XSS)
+- **CWE-918**: Server-Side Request Forgery (SSRF)
+- **CWE-502**: Deserialization of Untrusted Data
+- **CWE-20**: Improper Input Validation
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/logging.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/logging.md
new file mode 100644
index 00000000..eca49dba
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/logging.md
@@ -0,0 +1,163 @@
+# Logging Security Rules
+
+Logging sensitive information can lead to data exposure and compliance violations.
+
+**Rules:**
+
+1. PII MUST NEVER be logged — filter passwords, tokens, emails, and personal data.
+2. Log injection MUST be prevented — sanitize user input before logging.
+3. Error messages MUST NOT expose internals to users — log details server-side, return generic messages.
+
+---
+
+## Sensitive Data in Logs — Medium
+
+**Bad:**
+
+```go
+type User struct {
+    ID       string
+    Username string
+    Password string
+    Token    string
+}
+
+func logUserLogin(user *User) {
+    log.Printf("User logged in: %+v\n", user)  // DON'T: Logs password, token
+}
+```
+
+**Good:**
+
+```go
+import "log/slog"
+
+func logUserLogin(logger *slog.Logger, user *User) {
+    logger.Info("user_login",
+        "user_id", user.ID,
+        "username", user.Username,
+        // Don't log: password, token
+    )
+}
+```
+
+---
+
+## Log Injection — Low
+
+User input in logs can lead to log injection attacks.
+
+**Bad:**
+
+```go
+log.Printf("User logged in: %s\n", username)  // DON'T: No sanitization
+```
+
+**Good:**
+
+```go
+import "log/slog"
+
+// Sanitize user input before logging
+func sanitizeLogInput(input string) string {
+    // Remove control characters
+    var result strings.Builder
+    for _, r := range input {
+        if !unicode.IsControl(r) || r == '\n' || r == '\t' {
+            result.WriteRune(r)
+        }
+    }
+    return result.String()
+}
+
+func logUsername(logger *slog.Logger, username string) {
+    sanitized := sanitizeLogInput(username)
+    logger.Info("user_login", "username", sanitized)
+}
+```
+
+---
+
+## Information Leakage in Error Messages — Medium
+
+**Bad:**
+
+```go
+func handleDatabaseError(err error) error {
+    return fmt.Errorf("database error: %v", err)  // DON'T: Leaks internal details
+}
+
+func dbErrorToHTTP(err error) {
+    http.Error(w, "Error: "+err.Error(), 500)  // DON'T
+}
+```
+
+**Good:**
+
+```go
+func handleDatabaseError(logger *slog.Logger, err error) error {
+    // Log detailed error for debugging
+    logger.Error("database_error", "error", err.Error())
+    // Return generic message to client
+    return errors.New("database operation failed")
+}
+
+func dbErrorToHTTP(w http.ResponseWriter, logger *slog.Logger, err error) {
+    logger.Error("database_error", "error", err.Error())
+    http.Error(w, "Internal server error", http.StatusInternalServerError)
+}
+```
+
+---
+
+## General Logger Security — Low
+
+**Bad:**
+
+```go
+import "log"
+log.Println("User logged in:", user.ID, password)  // DON'T: Logs password
+fmt.Printf("DEBUG: %+v\n", data)  // DON'T: Raw data
+```
+
+**Good:**
+
+```go
+import "log/slog"
+
+handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
+    Level:     slog.LevelInfo,
+    AddSource: false,
+})
+logger := slog.New(handler)
+
+logger.Info("user_login",
+    "user_id", userID,
+    "ip_address", request.RemoteIP,
+)
+```
+
+---
+
+## Log Security Checklist
+
+- [ ] No passwords, tokens, or secrets in logs
+- [ ] No PII/PHI in production logs
+- [ ] Sanitize user input before logging
+- [ ] Use structured logging (JSON)
+- [ ] Implement log level strategy
+- [ ] Separate access logs from error logs
+- [ ] Log file permissions restricted (e.g., 600)
+- [ ] Log rotation prevents disk exhaustion
+- [ ] Generic error messages to clients
+- [ ] Detailed errors only in internal logs
+
+---
+
+## CWE References
+
+- **CWE-532**: Insertion of Sensitive Information into Log File
+- **CWE-117**: Improper Output Neutralization for Logs
+- **CWE-209**: Information Exposure Through an Error Message
+- **CWE-200**: Exposure of Sensitive Information
+- **CWE-312**: Cleartext Storage of Sensitive Information
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/memory-safety.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/memory-safety.md
new file mode 100644
index 00000000..37ea3b03
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/memory-safety.md
@@ -0,0 +1,241 @@
+# Memory Safety Security Rules
+
+Memory safety vulnerabilities can lead to crashes, data corruption, and security compromises.
+
+**Rules:**
+
+1. Integer overflow MUST be checked at boundaries — NEVER trust unchecked arithmetic on external input.
+2. `unsafe` MUST NOT be used in application code — restrict to low-level libraries with thorough review.
+3. Data races MUST be detected with `-race` flag in CI.
+
+---
+
+## Integer Overflow — High
+
+Integer overflows can cause unexpected behavior and crashes.
+
+**Bad:**
+
+```go
+func allocateBuffer(rows, cols int) []byte {
+    size := rows * cols  // DON'T: Can overflow
+    return make([]byte, size)
+}
+```
+
+**Good:**
+
+```go
+import "math"
+
+func safeMultiply(a, b int) (int, error) {
+    if a == 0 || b == 0 {
+        return 0, nil
+    }
+    if a > math.MaxInt/b {
+        return 0, errors.New("integer overflow")
+    }
+    result := a * b
+    if result/b != a {
+        return 0, errors.New("overflow detected")
+    }
+    return result, nil
+}
+
+func allocateBuffer(rows, cols int) ([]byte, error) {
+    size, err := safeMultiply(rows, cols)
+    if err != nil {
+        return nil, err
+    }
+    const maxBufferSize = 100 * 1024 * 1024 // 100MB limit
+    if size > maxBufferSize {
+        return nil, errors.New("buffer size exceeds limit")
+    }
+    return make([]byte, size), nil
+}
+```
+
+---
+
+## math/big.Rat Issues — Low
+
+Rat can consume large amounts of memory if denominators grow without bounds.
+
+**Bad:**
+
+```go
+import "math/big"
+
+func unsafeFraction(operations int) *big.Rat {
+    r := big.NewRat(1, 1)
+    for i := 0; i < operations; i++ {
+        r.Mul(r, big.NewRat(int64(i+1), int64(i+2)))  // DON'T
+    }
+    return r  // Could be memory intensive
+}
+```
+
+**Good:**
+
+```go
+const maxRatNumBits = 1000
+
+func safeFraction(operations int) (*big.Rat, error) {
+    r := big.NewRat(1, 1)
+    for i := 0; i < operations; i++ {
+        r.Mul(r, big.NewRat(int64(i+1), int64(i+2)))
+        if r.Num().BitLen() > maxRatNumBits || r.Denom().BitLen() > maxRatNumBits {
+            return nil, errors.New("fraction precision too large")
+        }
+    }
+    return r, nil
+}
+```
+
+---
+
+## Memory Aliasing Vulnerability — Medium
+
+Memory aliasing can cause data corruption and race conditions.
+
+**Bad:**
+
+```go
+func reverseBytes(data []byte) {
+    for i, j := 0, len(data)-1; i < j; i, j = i+1, j-1 {
+        data[i], data[j] = data[j], data[i]  // DON'T if slices alias
+    }
+}
+```
+
+**Good:**
+
+```go
+import "unsafe"
+
+func checkOverlap(a, b []byte) bool {
+    if len(a) == 0 || len(b) == 0 {
+        return false
+    }
+    aStart := uintptr(unsafe.Pointer(&a[0]))
+    aEnd := aStart + uintptr(len(a))
+    bStart := uintptr(unsafe.Pointer(&b[0]))
+    bEnd := bStart + uintptr(len(b))
+    return aStart < bEnd && bStart < aEnd
+}
+
+func safeCopy(dest, src []byte) {
+    if checkOverlap(dest, src) {
+        temp := make([]byte, len(src))
+        copy(temp, src)
+        copy(dest, temp)
+    } else {
+        copy(dest, src)
+    }
+}
+```
+
+---
+
+## Use of unsafe Package — High
+
+The unsafe package bypasses Go's type safety and memory safety.
+
+**Bad:**
+
+```go
+import "unsafe"
+
+func UnsafeStringToBytes(s string) []byte {
+    return (*[0x7fffffff]byte)(unsafe.Pointer(
+        (*reflect.StringHeader)(unsafe.Pointer(&s)).Data,
+    ))[:len(s):len(s)]  // DON'T: memory corruption risk
+}
+
+func TypePun(value uint64) float64 {
+    return *(*float64)(unsafe.Pointer(&value))  // DON'T
+}
+```
+
+**Good:**
+
+```go
+// Safe string encoding
+func StringToBytes(s string) []byte {
+    return []byte(s)
+}
+func BytesToString(b []byte) string {
+    return string(b)
+}
+
+// Safe type conversion
+import "encoding/binary"
+func Uint64ToFloat64(value uint64) float64 {
+    buf := make([]byte, 8)
+    binary.LittleEndian.PutUint64(buf, value)
+    bits := binary.LittleEndian.Uint64(buf)
+    return math.Float64frombits(bits)
+}
+```
+
+---
+
+## Data Races — High
+
+Go's race detector is your primary defense.
+
+**Bad:**
+
+```go
+type Counter struct {
+    value int
+}
+
+func (c *Counter) Increment() {
+    c.value++  // DON'T: Data race without sync
+}
+```
+
+**Good:**
+
+```go
+import "sync"
+
+type Counter struct {
+    value int
+    mu    sync.Mutex
+}
+
+func (c *Counter) Increment() {
+    c.mu.Lock()
+    defer c.mu.Unlock()
+    c.value++
+}
+
+// Or atomic for simple cases
+import "sync/atomic"
+type AtomicCounter struct {
+    value int64
+}
+func (c *AtomicCounter) Increment() {
+    atomic.AddInt64(&c.value, 1)
+}
+```
+
+## Always Run Race Detector
+
+```bash
+go test -race ./...
+go build -race
+```
+
+---
+
+## CWE References
+
+- **CWE-190**: Integer Overflow or Wraparound
+- **CWE-119**: Improper Restriction of Operations within Bounds
+- **CWE-125**: Out-of-bounds Read
+- **CWE-787**: Out-of-bounds Write
+- **CWE-362**: Race Condition
+- **CWE-367**: Time-of-check Time-of-use (TOCTOU)
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/network.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/network.md
new file mode 100644
index 00000000..4ba0ead7
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/network.md
@@ -0,0 +1,253 @@
+# Network/Web Security Rules
+
+Network and web security vulnerabilities can lead to data leakage and unauthorized access.
+
+**Rules:**
+
+1. Redirects MUST be validated against an allowlist of domains.
+2. HTTP servers MUST configure `ReadTimeout`, `WriteTimeout`, and `IdleTimeout`.
+3. Pprof endpoints MUST NEVER be exposed publicly.
+4. XML parsers MUST disable XXE — reject `<!DOCTYPE` and `<!ENTITY` declarations.
+
+---
+
+## Open Redirect Vulnerability — Medium
+
+Redirects to unvalidated URLs can be used for phishing.
+
+**Bad:**
+
+```go
+target := r.URL.Query().Get("url")
+http.Redirect(w, r, target, http.StatusFound) // DON'T
+```
+
+**Good:**
+
+```go
+target := r.URL.Query().Get("url")
+u, _ := url.Parse(target)
+// Only allow http/https
+if u.Scheme != "http" && u.Scheme != "https" {
+    return errors.New("invalid scheme")
+}
+// Block javascript/data schemes
+if strings.HasPrefix(target, "javascript:") || strings.HasPrefix(target, "data:") {
+    return errors.New("blocked scheme")
+}
+// Check against whitelist
+if !isAllowedDomain(u.Host) {
+    return errors.New("invalid domain")
+}
+http.Redirect(w, r, target, http.StatusFound)
+```
+
+---
+
+## Bind to All Interfaces — Medium
+
+Binding to 0.0.0.0 exposes services to all network interfaces.
+
+**Bad:**
+
+```go
+listener, _ := net.Listen("tcp", "0.0.0.0:8080") // DON'T: Exposes all interfaces
+```
+
+**Good:**
+
+```go
+// Bind only to localhost
+listener, _ := net.Listen("tcp", "127.0.0.1:8080")
+
+// Or specific internal IP
+listener, _ := net.Listen("tcp", "10.0.1.5:8080")
+```
+
+---
+
+## Slowloris Attack Vulnerability — Medium
+
+Slowloris attacks exhaust connection pools.
+
+**Bad:**
+
+```go
+server := &http.Server{
+    Addr: ":8080",
+    // Missing ReadTimeout, WriteTimeout, IdleTimeout
+}
+```
+
+**Good:**
+
+```go
+server := &http.Server{
+    Addr:         ":8080",
+    ReadTimeout:  5 * time.Second,
+    WriteTimeout: 10 * time.Second,
+    IdleTimeout:  120 * time.Second,
+    MaxHeaderBytes: 1 << 20, // Limit header size to 1MB
+}
+```
+
+---
+
+## Insecure HTTP Server Configuration — Medium
+
+Running HTTP servers without proper security settings.
+
+**Bad:**
+
+```go
+http.ListenAndServe(":8080", handler) // DON'T: No security hardening
+```
+
+**Good:**
+
+```go
+server := &http.Server{
+    Addr:         ":443",
+    ReadTimeout:  5 * time.Second,
+    WriteTimeout: 10 * time.Second,
+    IdleTimeout:  120 * time.Second,
+    MaxHeaderBytes: 1 << 20,
+}
+server.ListenAndServeTLS("cert.pem", "key.pem")
+```
+
+---
+
+## Observable Timing (Timing Attacks) — Medium
+
+Timing differences can leak sensitive information.
+
+**Bad:**
+
+```go
+func checkPassword(input, secret string) bool {
+    return input == secret // DON'T: Short-circuit leaks length
+}
+```
+
+**Good:**
+
+```go
+import "crypto/subtle"
+
+// For comparing fixed-length tokens or hashes:
+func checkToken(input, expected string) bool {
+    // ConstantTimeCompare already handles unequal lengths without leaking timing
+    return subtle.ConstantTimeCompare([]byte(input), []byte(expected)) == 1
+}
+
+// For passwords, use Argon2id (preferred) or bcrypt — they handle hashing
+// and constant-time comparison internally:
+// argon2: hash := argon2.IDKey([]byte(password), salt, 3, 64*1024, 4, 32)
+// bcrypt: err := bcrypt.CompareHashAndPassword([]byte(storedHash), []byte(password))
+
+// For HMAC verification:
+import "crypto/hmac"
+func verifyHMAC(message, messageMAC, key []byte) bool {
+    mac := hmac.New(sha256.New, key)
+    mac.Write(message)
+    expectedMAC := mac.Sum(nil)
+    return hmac.Equal(messageMAC, expectedMAC) // Constant-time
+}
+```
+
+---
+
+## Exposed pprof Profiling Endpoints — High
+
+Debug pprof endpoints expose sensitive runtime information.
+
+**Bad:**
+
+```go
+import _ "net/http/pprof" // DON'T: Automatically registers /debug/pprof
+http.ListenAndServe(":8080", handler)
+```
+
+**Good:**
+
+```go
+// Option 1: Use build tags to exclude pprof from production builds
+// File: debug_pprof.go
+//go:build !production
+
+package main
+
+import _ "net/http/pprof"
+
+// Option 2: Serve pprof on a separate internal-only listener
+func startDebugServer() {
+    debugMux := http.NewServeMux()
+    debugMux.HandleFunc("/debug/pprof/", pprof.Index)
+    debugMux.HandleFunc("/debug/pprof/cmdline", pprof.Cmdline)
+    debugMux.HandleFunc("/debug/pprof/profile", pprof.Profile)
+    debugMux.HandleFunc("/debug/pprof/symbol", pprof.Symbol)
+    debugMux.HandleFunc("/debug/pprof/trace", pprof.Trace)
+    go http.ListenAndServe("127.0.0.1:6060", debugMux) // localhost only
+}
+```
+
+---
+
+## XXE Vulnerability — High
+
+XML parsers that process external entity references.
+
+**Bad:**
+
+```go
+decoder := xml.NewDecoder(bytes.NewReader(xmlData))
+decoder.Decode(&person) // DON'T: May process external entities
+```
+
+**Good:**
+
+```go
+decoder := xml.NewDecoder(bytes.NewReader(xmlData))
+decoder.Strict = true
+
+// Block DTD declarations
+xmlStr := string(xmlData)
+if strings.Contains(xmlStr, "<!DOCTYPE") || strings.Contains(xmlStr, "<!ENTITY") {
+    return errors.New("XML contains DTD - potential XXE")
+}
+decoder.Decode(&person)
+```
+
+---
+
+## Permissive Regex Validation — Low
+
+Weak regex validation can allow malicious input.
+
+**Bad:**
+
+```go
+matched, _ := regexp.MatchString(`.+@.+\..+`, email) // DON'T: Too permissive
+```
+
+**Good:**
+
+```go
+var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
+if !emailRegex.MatchString(email) {
+    return errors.New("invalid email")
+}
+// Also block injection patterns
+```
+
+---
+
+## CWE References
+
+- **CWE-601**: Open Redirect
+- **CWE-208**: Observable Timing Discrepancy
+- **CWE-611**: Improper Restriction of XML External Entity Reference
+- **CWE-770**: Allocation of Resources Without Limits
+- **CWE-20**: Improper Input Validation
+- **CWE-200**: Exposure of Sensitive Information
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/secrets.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/secrets.md
new file mode 100644
index 00000000..59267492
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/secrets.md
@@ -0,0 +1,189 @@
+# Secrets Management Security Rules
+
+Hardcoded secrets, credentials, and sensitive data in source code is a major security vulnerability.
+
+**Rules:**
+
+1. Secrets MUST be loaded from environment variables or secret managers.
+2. NEVER commit secrets to VCS.
+3. `.gitignore` MUST exclude secret files (`.env`, `*.key`, `*.pem`).
+
+---
+
+## Hardcoded Secrets and Credentials — Critical
+
+**Bad:**
+
+```go
+const (
+    AWS_ACCESS_KEY    = "AKIAIOSFODNN7EXAMPLE"  // DON'T
+    AWS_SECRET_KEY    = "wJalrXUtnFEMI/K7MDENG"  // DON'T
+    DATABASE_PASSWORD = "SuperSecret123!"         // DON'T
+    JWT_SECRET        = "my-super-secret-jwt-key" // DON'T
+)
+
+var config = Config{
+    APIKey:  "abc123-xyz789-secret-key", // DON'T
+    Secret:  "my-super-secret-value",    // DON'T
+    DatabaseURL: "user:passw0rd!@localhost:5432/db", // DON'T
+}
+```
+
+**Good:**
+
+```go
+import "os"
+
+type Config struct {
+    AWSAccessKey     string
+    AWSSecretKey     string
+    DatabasePassword string
+    JWTSecret        string
+}
+
+func LoadConfig() (*Config, error) {
+    cfg := &Config{
+        AWSAccessKey:     os.Getenv("AWS_ACCESS_KEY_ID"),
+        AWSSecretKey:     os.Getenv("AWS_SECRET_ACCESS_KEY"),
+        DatabasePassword: os.Getenv("DATABASE_PASSWORD"),
+        JWTSecret:        os.Getenv("JWT_SECRET"),
+    }
+
+    if cfg.JWTSecret == "" {
+        return nil, errors.New("JWT_SECRET is required")
+    }
+    return cfg, nil
+}
+```
+
+---
+
+## Hardcoded Database Passwords — Critical
+
+**Bad:**
+
+```go
+// MySQL
+dsn := "user:Password123!@tcp(localhost:3306)/dbname" // DON'T
+
+// PostgreSQL
+dsn := "user=postgres password=P@ssw0rd! dbname=mydb host=localhost" // DON'T
+```
+
+**Good:**
+
+```go
+// MySQL
+func connectMySQL() (*sql.DB, error) {
+    user := os.Getenv("DB_USER")
+    password := os.Getenv("DB_PASSWORD")
+    if password == "" {
+        return nil, errors.New("DB_PASSWORD required")
+    }
+    host := getEnvWithDefault("DB_HOST", "localhost")
+    port := getEnvWithDefault("DB_PORT", "3306")
+    addr := net.JoinHostPort(host, port)
+    dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s",
+        user, password, addr, getEnvWithDefault("DB_NAME", "mydb"))
+    return sql.Open("mysql", dsn)
+}
+
+// PostgreSQL
+func connectPostgres() (*sql.DB, error) {
+    connStr := os.Getenv("DATABASE_URL")
+    if connStr == "" {
+        return nil, errors.New("DATABASE_URL required")
+    }
+    return sql.Open("postgres", connStr)
+}
+```
+
+---
+
+## Secrets Storage Best Practices
+
+### Environment Variables
+
+```go
+type EnvSecretLoader struct{}
+
+func (l *EnvSecretLoader) Load(required []string) (map[string]string, error) {
+    secrets := make(map[string]string)
+    missing := []string{}
+    for _, name := range required {
+        value := os.Getenv(name)
+        if value == "" {
+            missing = append(missing, name)
+            continue
+        }
+        secrets[name] = value
+    }
+    if len(missing) > 0 {
+        return nil, fmt.Errorf("missing: %v", missing)
+    }
+    return secrets, nil
+}
+```
+
+### Secret Managers
+
+```go
+type SecretManager interface {
+    GetSecret(name string) (string, error)
+}
+
+// AWS Secrets Manager
+type AWSSecretsManager struct {
+    client *secretsmanager.Client
+}
+
+func (m *AWSSecretsManager) GetSecret(name string) (string, error) {
+    result, err := m.client.GetSecretValue(context.TODO(), &secretsmanager.GetSecretValueInput{
+        SecretId: aws.String(name),
+    })
+    if err != nil {
+        return "", err
+    }
+    if result.SecretString != nil {
+        return *result.SecretString, nil
+    }
+    return string(result.SecretBinary), nil
+}
+```
+
+### .gitignore Patterns
+
+```
+# Secrets
+.env
+.env.local
+.env.*.local
+*.key
+*.pem
+*.p12
+*.pfx
+secrets/
+credentials/
+```
+
+---
+
+## Secret Detection Patterns
+
+| Pattern         | Example                         |
+| --------------- | ------------------------------- |
+| API Keys        | `Key = "sk_live_..."`           |
+| Passwords       | `password = "..."`              |
+| Tokens          | `token = "..."`                 |
+| Private Keys    | `BEGIN PRIVATE KEY`             |
+| AWS Credentials | `AWS_ACCESS_KEY_ID = "AKIA..."` |
+| JWT Secrets     | `jwtSecret = "..."`             |
+
+---
+
+## CWE References
+
+- **CWE-798**: Use of Hard-coded Credentials
+- **CWE-312**: Cleartext Storage of Sensitive Information
+- **CWE-532**: Insertion of Sensitive Information into Log File
+- **CWE-359**: Exposure of Private Personal Information
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/third-party.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/third-party.md
new file mode 100644
index 00000000..f4ea158b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/third-party.md
@@ -0,0 +1,159 @@
+# Third-Party Data Leak Rules
+
+Third-party monitoring and analytics services can inadvertently transmit sensitive user data to external systems.
+
+**Rules:**
+
+1. PII MUST be filtered before sending to third-party services.
+2. Error tracking MUST NOT receive raw user data — use `BeforeSend` hooks to redact.
+
+---
+
+## Overview
+
+These rules detect Go code that sends data to third-party services. Always review what data is being transmitted and ensure it complies with privacy regulations (GDPR, CCPA, etc.).
+
+---
+
+## Common Vulnerable Services
+
+| Service          | Risk                                                  |
+| ---------------- | ----------------------------------------------------- |
+| Airbrake         | Error tracking - sensitive data may be sent           |
+| Bugsnag          | Error tracking - sensitive data exposure              |
+| Sentry           | Error tracking - sensitive data in breadcrumbs/events |
+| Rollbar          | Error tracking - sensitive data leaks                 |
+| Honeybadger      | Error tracking - sensitive data leaks                 |
+| New Relic        | Monitoring - sensitive data exposure                  |
+| Datadog          | Monitoring - sensitive data in telemetry              |
+| OpenTelemetry    | Observability - sensitive data in traces/metrics      |
+| Google Analytics | Analytics - PII tracking risks                        |
+| Algolia          | Search API - data exfiltration risks                  |
+| Segment          | Analytics - PII tracking risks                        |
+| BigQuery         | Analytics - sensitive data in queries                 |
+| ClickHouse       | Database - sensitive data queries                     |
+| Elasticsearch    | Search engine - sensitive data in queries             |
+
+---
+
+## Error Tracking Services — Medium
+
+**Bad:**
+
+```go
+import "github.com/getsentry/sentry-go"
+
+sentry.CaptureException(err) // DON'T: Captures full request context
+```
+
+**Good:**
+
+```go
+sentry.Init(sentry.ClientOptions{
+    Dsn: "https://xxx@sentry.io/123",
+    RequestHeaders: []string{"Accept", "User-Agent"},
+    BeforeSend: func(event *sentry.Event, hint *sentry.EventHint) *sentry.Event {
+        // Remove sensitive headers
+        if event.Request != nil {
+            delete(event.Request.Headers, "Authorization")
+            delete(event.Request.Headers, "Cookie")
+        }
+        return event
+    },
+})
+```
+
+---
+
+## Analytics/Monitoring Services — Medium
+
+**Bad:**
+
+```go
+analytics.Track("user_signed_up", analytics.Properties{
+    "email":   user.Email,   // DON'T: PII!
+    "phone":   user.Phone,   // DON'T: PII!
+    "address": user.Address, // DON'T: PII!
+})
+```
+
+**Good:**
+
+```go
+analytics.Track("user_signed_up", analytics.Properties{
+    "user_id":        user.ID,          // OK: Internal identifier
+    "plan":           user.Plan,        // OK: Business data
+    "country":        user.CountryCode, // OK: Non-identifying
+})
+
+// Hash PII for correlation
+func hashEmail(email string) string {
+    h := sha256.New()
+    h.Write([]byte(email))
+    return hex.EncodeToString(h.Sum(nil))[:8]
+}
+```
+
+---
+
+## Data Filtering Layer
+
+```go
+type DataFilter struct {
+    sensitiveFields []string
+}
+
+func NewDataFilter() *DataFilter {
+    return &DataFilter{
+        sensitiveFields: []string{
+            "password", "token", "secret", "key", "email",
+            "phone", "address", "ssn", "credit_card", "bank_account",
+        },
+    }
+}
+
+func (f *DataFilter) Filter(data map[string]interface{}) map[string]interface{} {
+    result := make(map[string]interface{})
+    for k, v := range data {
+        keyLower := strings.ToLower(k)
+        isSensitive := false
+        for _, field := range f.sensitiveFields {
+            if strings.Contains(keyLower, field) {
+                isSensitive = true
+                break
+            }
+        }
+        if isSensitive {
+            result[k] = "[REDACTED]"
+        } else {
+            result[k] = v
+        }
+    }
+    return result
+}
+```
+
+---
+
+## Review Checklist
+
+Before integrating any third-party service:
+
+- [ ] Identify what data is being sent
+- [ ] Remove any PII/PHI from transmitted data
+- [ ] Review data residency requirements
+- [ ] Implement data retention policies
+- [ ] Set up data export logging/auditing
+- [ ] Configure error handling to avoid data exposure
+- [ ] Review terms of service for data usage
+- [ ] Implement user consent management
+- [ ] Support data deletion requests
+- [ ] Conduct regular data flow audits
+
+---
+
+## CWE References
+
+- **CWE-200**: Exposure of Sensitive Information
+- **CWE-359**: Exposure of Private Personal Information
+- **CWE-201**: Information Exposure Through Sent Data
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/threat-modeling.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/threat-modeling.md
new file mode 100644
index 00000000..09ef0340
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-security/references/threat-modeling.md
@@ -0,0 +1,189 @@
+# Threat Modeling Guide
+
+Systematic methodology for identifying and prioritizing security threats in Go applications.
+
+## STRIDE Methodology
+
+Apply STRIDE to every element in your system's data flow diagram. Each element type is susceptible to specific threat categories:
+
+### STRIDE per Element Matrix
+
+| DFD Element                           | S   | T   | R   | I   | D   | E   |
+| ------------------------------------- | --- | --- | --- | --- | --- | --- |
+| External Entity (user, API client)    | X   |     | X   |     |     |     |
+| Process (HTTP handler, gRPC service)  | X   | X   | X   | X   | X   | X   |
+| Data Store (database, cache, file)    |     | X   | X   | X   | X   |     |
+| Data Flow (HTTP, gRPC, message queue) |     | X   |     | X   | X   |     |
+
+### Go-Specific STRIDE Analysis
+
+**Spoofing** — Can an attacker impersonate a user or service?
+
+```go
+// Check: Is every endpoint behind authentication?
+// Check: Are JWT tokens validated (algorithm, issuer, expiry)?
+// Check: Is mTLS configured for service-to-service calls?
+r.Use(authMiddleware) // every route group must have auth
+```
+
+**Tampering** — Can data be modified in transit or at rest?
+
+```go
+// Check: Are all external inputs validated?
+// Check: Is HMAC used for webhook/callback verification?
+mac := hmac.New(sha256.New, key)
+mac.Write(payload)
+expected := mac.Sum(nil)
+if !hmac.Equal(signature, expected) {
+    return errors.New("tampered payload")
+}
+```
+
+**Repudiation** — Can a user deny performing an action?
+
+```go
+// Check: Are all security-relevant actions logged with structured data?
+logger.Info("action_performed",
+    "user_id", userID,
+    "action", "delete_account",
+    "ip", r.RemoteAddr,
+    "timestamp", time.Now().UTC(),
+)
+```
+
+**Information Disclosure** — Can sensitive data leak?
+
+```go
+// Check: Are error messages generic to clients?
+// Check: Are logs free of PII?
+// Check: Is TLS configured (no InsecureSkipVerify)?
+// Check: Are debug endpoints (pprof) disabled in production?
+```
+
+**Denial of Service** — Can the service be overwhelmed?
+
+```go
+// Check: Are timeouts set on the HTTP server?
+// Check: Are request body sizes limited?
+// Check: Is rate limiting in place?
+server := &http.Server{
+    ReadTimeout:    5 * time.Second,
+    WriteTimeout:   10 * time.Second,
+    MaxHeaderBytes: 1 << 20, // 1MB
+}
+```
+
+**Elevation of Privilege** — Can a user gain unauthorized access?
+
+```go
+// Check: Is authorization checked server-side on every request?
+// Check: Are object references validated (no IDOR)?
+// Check: Are admin routes properly protected?
+if !user.HasPermission("admin:write") {
+    http.Error(w, "Forbidden", http.StatusForbidden)
+    return
+}
+```
+
+---
+
+## DREAD Risk Scoring
+
+Score each identified threat to prioritize remediation:
+
+| Factor | 1-3 (Low) | 4-6 (Medium) | 7-10 (High) |
+| --- | --- | --- | --- |
+| **D**amage | Minor info disclosure | Partial data breach | Full system compromise, data destruction |
+| **R**eproducibility | Timing-dependent, hard to reproduce | Reproducible with some effort | Always reproducible, automated tools exist |
+| **E**xploitability | Custom exploit, advanced skills needed | Basic tools available | No skills required, public exploit exists |
+| **A**ffected users | Individual user | Subset of users | All users |
+| **D**iscoverability | Requires insider knowledge | Found via scanning | Publicly documented, obvious |
+
+**Score** = (D + R + E + A + D) / 5. Risk levels: **8-10 Critical**, **6-7.9 High**, **4-5.9 Medium**, **1-3.9 Low**.
+
+### Example: SQL Injection in Login Handler
+
+| Factor          | Score | Justification                              |
+| --------------- | ----- | ------------------------------------------ |
+| Damage          | 9     | Full database access, credential theft     |
+| Reproducibility | 9     | Consistent, automated tools exist (sqlmap) |
+| Exploitability  | 8     | Well-documented attack, easy tooling       |
+| Affected Users  | 10    | All users with accounts                    |
+| Discoverability | 7     | Automated scanners detect easily           |
+
+**DREAD Score: 8.6 — Critical. Immediate remediation required.**
+
+---
+
+## Trust Boundary Analysis
+
+Map where untrusted data enters your Go application:
+
+```
+                        ┌─────────────────────────────────────┐
+                        │           TRUST BOUNDARY             │
+                        │                                      │
+Internet ──→ [LB/WAF] ──→ [Go HTTP Server]                   │
+                        │        │                             │
+                        │   [Middleware]                        │
+                        │   - Auth (JWT/session)               │
+                        │   - Rate limiting                    │
+                        │   - Input validation                 │
+                        │   - Security headers                 │
+                        │        │                             │
+                        │   [Service Layer] ──→ [Cache]        │
+                        │        │                             │
+                        │   [Database] (parameterized queries) │
+                        │                                      │
+                        └──────────┬──────────────────────────┘
+                                   │
+                          External APIs (mTLS)
+```
+
+Every arrow crossing the trust boundary needs:
+
+1. **Authentication** — who is making this request?
+2. **Input validation** — is the data well-formed and within bounds?
+3. **Authorization** — is this caller allowed to perform this action on this resource?
+
+---
+
+## OWASP Top 10 Mapping for Go
+
+| Rank | Vulnerability | STRIDE | Go Defense |
+| --- | --- | --- | --- |
+| A01 | Broken Access Control | E | Server-side authz middleware, RBAC, IDOR checks |
+| A02 | Cryptographic Failures | I | `crypto/aes` GCM, `crypto/rand`, TLS 1.2+ |
+| A03 | Injection | T, E | `database/sql` placeholders, `exec.Command` separate args, `html/template` |
+| A04 | Insecure Design | All | Threat modeling with STRIDE, defense-in-depth |
+| A05 | Security Misconfiguration | I, E | Server timeouts, TLS config, no `InsecureSkipVerify`, no exposed pprof |
+| A06 | Vulnerable Components | All | `govulncheck`, Dependabot/Renovate, `go.sum` verification |
+| A07 | Authentication Failures | S, E | Argon2id/bcrypt, JWT validation (algorithm pinning), MFA |
+| A08 | Software/Data Integrity | T | Module checksums (`go.sum`), signed releases, CI verification |
+| A09 | Logging Failures | R | Structured logging (`log/slog`), audit trails, no PII |
+| A10 | SSRF | I, T | URL allowlists, block internal IPs and metadata endpoints |
+
+---
+
+## Conducting a Threat Model
+
+1. **Scope** — identify system boundaries, assets to protect, and threat actors
+2. **Diagram** — draw a data flow diagram with trust boundaries (external entities, processes, data stores, data flows)
+3. **STRIDE** — apply STRIDE to each DFD element using the matrix above
+4. **Score** — rate each threat with DREAD
+5. **Prioritize** — fix Critical/High first; document accepted risks with explicit justification
+6. **Verify** — run `gosec ./...`, `govulncheck ./...`, `go test -race ./...` to validate mitigations
+7. **Iterate** — update the model when the system changes (new endpoints, new data flows, new integrations)
+
+---
+
+## Vulnerability Severity Matrix
+
+Use when no DREAD data is available — cross-reference impact with exploitability:
+
+| Impact \ Exploitability | Easy     | Moderate | Difficult |
+| ----------------------- | -------- | -------- | --------- |
+| Critical                | Critical | Critical | High      |
+| High                    | Critical | High     | Medium    |
+| Medium                  | High     | Medium   | Low       |
+| Low                     | Medium   | Low      | Low       |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/SKILL.md
new file mode 100644
index 00000000..c2eb031a
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/SKILL.md
@@ -0,0 +1,170 @@
+---
+name: golang-spf13-cobra
+description: "Golang CLI command tree library using spf13/cobra — cobra.Command, RunE vs Run, PersistentPreRunE hook chain, Args validators (NoArgs, ExactArgs, MatchAll, custom), persistent vs local flags, command groups, ValidArgsFunction, RegisterFlagCompletionFunc, ShellCompDirective, usage/help template customization, man-page and markdown doc generation, and testing with SetArgs/SetOut/SetErr. Apply when using or adopting spf13/cobra, or when the codebase imports `github.com/spf13/cobra`. For configuration layering alongside cobra, see the `samber/cc-skills-golang@golang-spf13-viper` skill. For general CLI architecture (project layout, exit codes, signal handling, I/O patterns), see `samber/cc-skills-golang@golang-cli`."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.0.1"
+  openclaw:
+    emoji: "🐍"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "1.10.2"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs
+---
+
+**Persona:** You are a Go CLI engineer building command trees that feel native to the Unix shell. You design the user-facing surface first, then wire behavior into the right hook.
+
+**Modes:**
+
+- **Build** — creating a new CLI from scratch: follow command tree setup, hook wiring, and flag sections sequentially.
+- **Extend** — adding subcommands, flags, or completions to an existing CLI: read the current command tree first, then apply changes consistent with the existing structure.
+- **Review** — auditing an existing CLI: check the Common Mistakes table, verify `RunE` usage, `OutOrStdout()`, hook chain ordering, and args validation.
+
+# Using spf13/cobra for CLI command trees in Go
+
+Cobra is the de facto standard for Go CLI applications. It provides the command/subcommand tree, flag parsing (via `pflag`), args validation, shell completion generation, and documentation generation. It does **not** handle configuration layering — that's viper's job.
+
+**Official Resources:**
+
+- [pkg.go.dev/github.com/spf13/cobra](https://pkg.go.dev/github.com/spf13/cobra)
+- [github.com/spf13/cobra](https://github.com/spf13/cobra)
+- [cobra.dev](https://cobra.dev)
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+```bash
+go get github.com/spf13/cobra@latest
+```
+
+## Cobra vs. viper
+
+These libraries do fundamentally different things and can be used independently.
+
+| Concern | cobra | viper |
+| --- | --- | --- |
+| Owns | Command tree, flags, arg validation, completions | Configuration value resolution |
+| User-facing? | Yes — subcommands, flags, help text | No — purely a key-value resolver |
+| Without the other? | Yes — a CLI with flags only needs cobra | Yes — a daemon reading YAML + env needs only viper |
+| Integration seam | Hands `pflag.Flag` to viper via `BindPFlag` | Treats the cobra flag as the highest-precedence layer |
+
+**Use cobra alone** when your binary takes flags and args but needs no config file or env resolution. **Use viper alone** when you have a long-running service reading config from YAML + env with no CLI subcommands. Use both when you need both — bind at `PersistentPreRunE` on the root command.
+
+→ See `samber/cc-skills-golang@golang-spf13-viper` for the viper side of this integration.
+
+## Command tree
+
+Every cobra CLI has a root command plus zero or more subcommands registered with `AddCommand`. The root command name is the binary name.
+
+```go
+var rootCmd = &cobra.Command{
+    Use:          "myapp",
+    Short:        "One-line summary",
+    SilenceUsage: true,  // ✓ prevents usage wall on every error
+    SilenceErrors: true, // ✓ lets you control error output format
+}
+```
+
+Use `AddGroup` to label subcommands in help output — register groups **before** the `AddCommand` calls that reference them; cobra does not retroactively assign groups.
+
+## The Run\* family
+
+Cobra commands have five run hooks executed in order:
+
+```
+PersistentPreRunE → PreRunE → RunE → PostRunE → PersistentPostRunE
+```
+
+Always use `*E` variants — the non-`E` forms cannot return errors. Key rules:
+
+- `PersistentPreRunE` on the root runs before **every** subcommand — use it for config init and auth checks.
+- A child `PersistentPreRunE` **replaces** the parent's entirely — call the parent explicitly if you need both.
+- `PostRunE` runs only if `RunE` succeeded.
+
+For the full lifecycle and inheritance rules, see [commands-and-args.md](references/commands-and-args.md).
+
+## Args validators
+
+Cobra validates positional arguments before `RunE` runs. Never write `len(args)` checks inside `RunE` — that bypasses cobra's standard error messages and arg count tracking.
+
+Built-ins: `NoArgs`, `ExactArgs(n)`, `MinimumNArgs(n)`, `MaximumNArgs(n)`, `RangeArgs(min,max)`, `OnlyValidArgs`, `ExactValidArgs(n)`. Compose with `MatchAll(v1, v2)`. Custom validator: `func(cmd *cobra.Command, args []string) error`.
+
+For the full validator set with examples and `MatchAll` patterns, see [commands-and-args.md](references/commands-and-args.md).
+
+## Flags primer
+
+Cobra delegates flag parsing to `pflag`. **Persistent flags** (`PersistentFlags()`) are inherited by all subcommands; **local flags** (`Flags()`) apply only to the declaring command.
+
+```go
+rootCmd.PersistentFlags().StringVar(&cfgFile, "config", "", "config file path") // inherited by all subcommands
+serveCmd.Flags().IntVar(&port, "port", 8080, "listen port")                     // local to serveCmd only
+serveCmd.MarkFlagRequired("port")
+serveCmd.MarkFlagsMutuallyExclusive("json", "yaml")
+```
+
+For pflag types, custom flag values, flag groups, and viper binding, see [flags.md](references/flags.md).
+
+## Completions primer
+
+Cobra generates shell completions automatically. Extend them with:
+
+- **`ValidArgs []string`** — static positional arg completion.
+- **`ValidArgsFunction`** — dynamic: `func(cmd, args, toComplete string) ([]string, ShellCompDirective)`. Return `ShellCompDirectiveNoFileComp` to suppress file fallback.
+- **`RegisterFlagCompletionFunc(name, fn)`** — flag value completion.
+
+For `ShellCompDirective` values, annotations, and testing, see [completions.md](references/completions.md).
+
+## Testing commands
+
+Test commands by executing them programmatically. **Never use `os.Stdout` / `os.Stderr` directly** in command handlers — use `cmd.OutOrStdout()` / `cmd.ErrOrStderr()` so tests can redirect output.
+
+```go
+func TestServeCmd(t *testing.T) {
+    buf := new(bytes.Buffer)
+    rootCmd.SetOut(buf)
+    rootCmd.SetArgs([]string{"serve", "--port", "9090"})
+    require.NoError(t, rootCmd.Execute())
+    assert.Contains(t, buf.String(), "listening on :9090")
+}
+```
+
+Cobra accumulates flag state across `Execute()` calls — build a fresh command tree per test. For isolation patterns, golden files, and testing completions, see [testing.md](references/testing.md).
+
+## Best Practices
+
+1. **Always use `RunE`, never `Run`** — `Run` cannot return an error; the only escape is `os.Exit` or panic, bypassing defers.
+2. **Put config initialization in `PersistentPreRunE`** — it runs before every subcommand; the right place for viper binding and auth checks.
+3. **Validate positional args with `Args`, not inside `RunE`** — `Args` gives cobra's standard error messages; `MatchAll` composes validators.
+4. **Use `cmd.OutOrStdout()` / `cmd.ErrOrStderr()` for all output** — direct `os.Stdout` writes cannot be captured by tests.
+5. **Re-create the command tree per test** — cobra accumulates flag state across `Execute()` calls on the same instance.
+
+## Common Mistakes
+
+| Mistake | Why it fails | Fix |
+| --- | --- | --- |
+| Using `Run` instead of `RunE` | Cannot return an error — only escape is `os.Exit` or panic, bypassing defers | Use `RunE` — return the error, let cobra handle the exit |
+| Writing `len(args)` checks in `RunE` | Bypasses cobra's standard error messages ("accepts 1 arg, received 2") | Declare `Args: cobra.ExactArgs(1)` on the command |
+| Writing to `os.Stdout` directly | Tests cannot capture output — os-level file handles can't be redirected | Use `cmd.OutOrStdout()` / `cmd.ErrOrStderr()` |
+| Child `PersistentPreRunE` silently drops parent's | Cobra does not chain — the child replaces the parent's hook entirely | Call `parent.PersistentPreRunE(cmd, args)` from the child's hook |
+| Reusing a root command across tests | Cobra accumulates flag state; second `Execute()` sees flags from the first | Build a fresh command tree per test |
+
+## Further Reading
+
+- [commands-and-args.md](references/commands-and-args.md) — full PreRun\*/PostRun\* chain, every Args validator, PersistentPreRunE inheritance rules
+- [flags.md](references/flags.md) — pflag types, required/exclusive/oneRequired groups, custom value types, viper binding
+- [completions.md](references/completions.md) — ShellCompDirective set, annotation-based completions, testing completions
+- [generators.md](references/generators.md) — man page, markdown, YAML, RST doc generation; `cobra-cli` scaffolder
+- [testing.md](references/testing.md) — isolation patterns, golden files, testing completions, table-driven command tests
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-cli` skill for general CLI architecture — project layout, exit codes, signal handling, I/O patterns
+- → See `samber/cc-skills-golang@golang-spf13-viper` skill for configuration layering alongside cobra (flag → env → file → default precedence)
+- → See `samber/cc-skills-golang@golang-testing` skill for general Go testing patterns
+
+If you encounter a bug or unexpected behavior in spf13/cobra, open an issue at <https://github.com/spf13/cobra/issues>.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/evals/evals.json
new file mode 100644
index 00000000..b24c9b80
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/evals/evals.json
@@ -0,0 +1,444 @@
+[
+  {
+    "id": 1,
+    "name": "rune-vs-run-error-propagation",
+    "description": "Tests use of RunE instead of Run for error propagation",
+    "prompt": "I'm writing a cobra subcommand in Go that calls an external API. If the API returns an error, the command should exit non-zero. Should I use Run or RunE?",
+    "trap": "Without the skill, the model may say both work, suggest using Run with os.Exit(1), or not explain why Run is problematic. The correct answer is always RunE — it propagates the error through cobra's error handling chain.",
+    "assertions": [
+      { "id": "1.1", "text": "Recommends RunE, not Run" },
+      {
+        "id": "1.2",
+        "text": "Explains that Run cannot return an error — you'd need os.Exit or panic"
+      },
+      {
+        "id": "1.3",
+        "text": "Shows RunE returning the error from the handler"
+      },
+      { "id": "1.4", "text": "Does NOT suggest using os.Exit inside RunE" },
+      {
+        "id": "1.5",
+        "text": "Mentions that returning error from RunE causes cobra to exit non-zero"
+      }
+    ]
+  },
+  {
+    "id": 2,
+    "name": "args-validator-not-manual-check",
+    "description": "Tests use of cobra Args validators instead of manual len(args) checks in RunE",
+    "prompt": "I'm writing a Go CLI with cobra. My 'delete' command requires exactly one positional argument (the resource name). How should I validate this?",
+    "trap": "Without the skill, the model writes len(args) != 1 check inside RunE. The correct approach is Args: cobra.ExactArgs(1) on the command definition, which validates before RunE runs and gives a standard error message.",
+    "assertions": [
+      {
+        "id": "2.1",
+        "text": "Sets Args: cobra.ExactArgs(1) on the command struct"
+      },
+      { "id": "2.2", "text": "Does NOT write len(args) check inside RunE" },
+      {
+        "id": "2.3",
+        "text": "Mentions that cobra prints a standard error message when validation fails"
+      },
+      {
+        "id": "2.4",
+        "text": "RunE body accesses args[0] directly without re-validating length"
+      }
+    ]
+  },
+  {
+    "id": 3,
+    "name": "outOrStdout-not-os-stdout",
+    "description": "Tests use of cmd.OutOrStdout() instead of os.Stdout for testable output",
+    "prompt": "I'm writing a cobra command in Go that prints a table of results to the terminal. How should I write to stdout from inside RunE?",
+    "trap": "Without the skill, the model uses fmt.Println or os.Stdout directly. The correct approach is fmt.Fprintln(cmd.OutOrStdout(), ...) which can be redirected to a buffer in tests.",
+    "assertions": [
+      { "id": "3.1", "text": "Uses cmd.OutOrStdout() as the io.Writer target" },
+      { "id": "3.2", "text": "Does NOT use os.Stdout directly" },
+      {
+        "id": "3.3",
+        "text": "Does NOT use fmt.Println (which hardcodes os.Stdout)"
+      },
+      {
+        "id": "3.4",
+        "text": "Mentions testability as the reason — SetOut can redirect the writer in tests"
+      }
+    ]
+  },
+  {
+    "id": 4,
+    "name": "persistent-prerunE-hook-chain",
+    "description": "Tests PersistentPreRunE on root for global config init and the child override trap",
+    "prompt": "In my Go CLI with cobra, I want to initialize viper config before any subcommand runs. I also have one subcommand that needs its own PersistentPreRunE for extra setup. How do I make sure both run?",
+    "trap": "Without the skill, the model defines PersistentPreRunE on both root and child without noting that the child's hook replaces the parent's — so root's config init never runs for that subcommand.",
+    "assertions": [
+      {
+        "id": "4.1",
+        "text": "Explains that a child's PersistentPreRunE replaces (not chains) the parent's"
+      },
+      {
+        "id": "4.2",
+        "text": "Shows explicitly calling the parent's PersistentPreRunE from inside the child's hook"
+      },
+      { "id": "4.3", "text": "Does NOT claim both hooks run automatically" },
+      {
+        "id": "4.4",
+        "text": "Uses PersistentPreRunE (the *E variant) not PersistentPreRun"
+      }
+    ]
+  },
+  {
+    "id": 5,
+    "name": "silence-usage-and-errors",
+    "description": "Tests SilenceUsage and SilenceErrors on root command",
+    "prompt": "When my Go cobra CLI returns an error from RunE, the terminal shows the full usage/help text followed by the error. I only want to see the error message, not the usage. How do I fix this?",
+    "trap": "Without the skill, the model may suggest overriding SetUsageTemplate or wrapping the error. The correct fix is SilenceUsage: true on the root command.",
+    "assertions": [
+      {
+        "id": "5.1",
+        "text": "Sets SilenceUsage: true on the root cobra.Command"
+      },
+      {
+        "id": "5.2",
+        "text": "Optionally mentions SilenceErrors: true (for custom error formatting)"
+      },
+      {
+        "id": "5.3",
+        "text": "Does NOT suggest removing or wrapping the error in RunE"
+      },
+      {
+        "id": "5.4",
+        "text": "Explains that SilenceUsage only suppresses usage on error, not on --help"
+      }
+    ]
+  },
+  {
+    "id": 6,
+    "name": "command-group-registration-order",
+    "description": "Tests that AddGroup must be called before AddCommand that references it",
+    "prompt": "I want to group my cobra subcommands in the help output under labels like 'Core Commands:' and 'Management Commands:'. How do I set this up?",
+    "trap": "Without the skill, the model calls AddCommand first and AddGroup after, which doesn't work — groups must be registered before the commands that reference them.",
+    "assertions": [
+      {
+        "id": "6.1",
+        "text": "Calls AddGroup before AddCommand for commands that use that group"
+      },
+      {
+        "id": "6.2",
+        "text": "Sets GroupID on the subcommand matching the Group's ID field"
+      },
+      { "id": "6.3", "text": "Shows cobra.Group{ID: ..., Title: ...} struct" },
+      {
+        "id": "6.4",
+        "text": "Does NOT call AddCommand before AddGroup for the same group"
+      }
+    ]
+  },
+  {
+    "id": 7,
+    "name": "valid-args-function-dynamic-completion",
+    "description": "Tests ValidArgsFunction for dynamic shell completion instead of static ValidArgs",
+    "prompt": "My Go cobra 'get pod' command should complete pod names dynamically by querying the API server. ValidArgs only accepts a static list. How do I provide dynamic completions?",
+    "trap": "Without the skill, the model tries to populate ValidArgs at startup (querying the API at init time) or doesn't know about ValidArgsFunction.",
+    "assertions": [
+      {
+        "id": "7.1",
+        "text": "Uses ValidArgsFunction (not ValidArgs) for dynamic completions"
+      },
+      {
+        "id": "7.2",
+        "text": "Function signature returns ([]string, cobra.ShellCompDirective)"
+      },
+      {
+        "id": "7.3",
+        "text": "Returns cobra.ShellCompDirectiveNoFileComp to prevent file fallback"
+      },
+      {
+        "id": "7.4",
+        "text": "Does NOT query the API at init() or in ValidArgs (static list)"
+      },
+      {
+        "id": "7.5",
+        "text": "Handles errors by returning cobra.ShellCompDirectiveError"
+      }
+    ]
+  },
+  {
+    "id": 8,
+    "name": "register-flag-completion-func",
+    "description": "Tests RegisterFlagCompletionFunc for flag value completion",
+    "prompt": "My Go cobra command has an --output flag that accepts 'json', 'yaml', or 'table'. How do I make the shell complete valid values when the user types --output <TAB>?",
+    "trap": "Without the skill, the model does not know about RegisterFlagCompletionFunc and instead documents the valid values only in the flag description string.",
+    "assertions": [
+      {
+        "id": "8.1",
+        "text": "Calls cmd.RegisterFlagCompletionFunc(\"output\", func(...) ...)"
+      },
+      {
+        "id": "8.2",
+        "text": "The completion function returns []string{\"json\", \"yaml\", \"table\"} (or similar)"
+      },
+      { "id": "8.3", "text": "Returns cobra.ShellCompDirectiveNoFileComp" },
+      {
+        "id": "8.4",
+        "text": "Does NOT rely only on the flag usage string for user guidance"
+      }
+    ]
+  },
+  {
+    "id": 9,
+    "name": "test-isolation-fresh-root",
+    "description": "Tests that a fresh command tree must be created per test to avoid flag state leakage",
+    "prompt": "I'm writing tests for my Go cobra CLI. My first test runs 'myapp serve --port 9090' and passes. My second test runs 'myapp serve' without --port and expects the default 8080, but gets 9090. What's wrong and how do I fix it?",
+    "trap": "Without the skill, the model may suggest resetting the flag value manually or calling ResetFlags(). The correct fix is to create a fresh command tree per test.",
+    "assertions": [
+      {
+        "id": "9.1",
+        "text": "Identifies the root cause as reusing the same cobra.Command instance across tests"
+      },
+      {
+        "id": "9.2",
+        "text": "Recommends building a new command tree per test (constructor function)"
+      },
+      {
+        "id": "9.3",
+        "text": "Shows a newRootCmd() or similar factory function pattern"
+      },
+      {
+        "id": "9.4",
+        "text": "Does NOT suggest ResetFlags() as the primary solution"
+      },
+      {
+        "id": "9.5",
+        "text": "Each test calls the factory to get a fresh *cobra.Command"
+      }
+    ]
+  },
+  {
+    "id": 10,
+    "name": "match-all-validator-composition",
+    "description": "Tests MatchAll for composing multiple arg validators",
+    "prompt": "My Go cobra 'apply' command needs positional args that are all valid resource names (from a known list) AND there must be at least one. How do I express both constraints?",
+    "trap": "Without the skill, the model writes a custom validator function that manually checks both conditions with if statements. MatchAll composes built-in validators without custom code.",
+    "assertions": [
+      { "id": "10.1", "text": "Uses cobra.MatchAll to compose validators" },
+      {
+        "id": "10.2",
+        "text": "Combines cobra.MinimumNArgs(1) (or ExactArgs) with cobra.OnlyValidArgs"
+      },
+      { "id": "10.3", "text": "Sets ValidArgs with the known resource names" },
+      {
+        "id": "10.4",
+        "text": "Does NOT write a fully manual validator function for the combined check"
+      }
+    ]
+  },
+  {
+    "id": 11,
+    "name": "cobra-vs-viper-distinction",
+    "description": "Tests understanding of what cobra does vs what viper does",
+    "prompt": "I'm starting a Go CLI project. I need subcommands, flags, shell completions, AND the ability to read configuration from a YAML file and environment variables. I've heard of cobra and viper. Which library handles which concern?",
+    "trap": "Without the skill, the model may conflate the two or understate how they integrate. The correct answer clearly assigns cobra=command tree/flags/completions and viper=layered config resolution, with BindPFlag as the integration seam.",
+    "assertions": [
+      {
+        "id": "11.1",
+        "text": "Assigns cobra to command tree, flags, arg validation, shell completions"
+      },
+      {
+        "id": "11.2",
+        "text": "Assigns viper to config file, env var, and layered value resolution"
+      },
+      {
+        "id": "11.3",
+        "text": "Identifies BindPFlag (or similar) as the integration seam between them"
+      },
+      {
+        "id": "11.4",
+        "text": "Explains they can be used independently (cobra without viper, or viper without cobra)"
+      },
+      {
+        "id": "11.5",
+        "text": "Does NOT say cobra reads config files or viper defines subcommands"
+      }
+    ]
+  },
+  {
+    "id": 12,
+    "name": "cobra-cli-scaffolder",
+    "description": "Tests knowledge of the cobra-cli scaffolding tool",
+    "prompt": "I want to quickly scaffold a new Go CLI project with cobra. Is there a tool that generates the initial files and lets me add subcommands from the command line?",
+    "trap": "Without the skill, the model may say to create files manually or use a generic project generator. The cobra-cli tool is the canonical scaffolder for cobra projects.",
+    "assertions": [
+      {
+        "id": "12.1",
+        "text": "Mentions cobra-cli (github.com/spf13/cobra-cli)"
+      },
+      {
+        "id": "12.2",
+        "text": "Shows 'cobra-cli init <project>' for initialization"
+      },
+      {
+        "id": "12.3",
+        "text": "Shows 'cobra-cli add <command>' for adding subcommands"
+      },
+      {
+        "id": "12.4",
+        "text": "Explains that cobra-cli is separate from cobra itself (different import path)"
+      }
+    ]
+  },
+  {
+    "id": 13,
+    "name": "stringarray-vs-stringslice-commas",
+    "description": "Tests StringArray vs StringSlice when flag values contain commas",
+    "prompt": "My Go cobra CLI has a --label flag that users pass multiple times like --label 'env=prod,region=us'. With my current setup, passing --label 'env=prod,region=us' results in two separate values ['env=prod', 'region=us'] instead of one. What flag type should I use?",
+    "trap": "Without the skill, the model uses StringSlice which splits on commas. StringArray is the correct choice when values may legitimately contain commas.",
+    "assertions": [
+      {
+        "id": "13.1",
+        "text": "Recommends StringArray (or StringArrayVar) instead of StringSlice"
+      },
+      {
+        "id": "13.2",
+        "text": "Explains that StringSlice splits on commas while StringArray does not"
+      },
+      {
+        "id": "13.3",
+        "text": "Does NOT suggest quoting or escaping commas as the fix"
+      },
+      {
+        "id": "13.4",
+        "text": "Shows the correct flag definition using StringArray or StringArrayVar"
+      }
+    ]
+  },
+  {
+    "id": 14,
+    "name": "mutually-exclusive-flags",
+    "description": "Tests MarkFlagsMutuallyExclusive instead of manual RunE checks",
+    "prompt": "My Go cobra command has --json and --yaml flags for output format. Users should only be able to pass one of them. How do I prevent both from being passed at the same time?",
+    "trap": "Without the skill, the model writes an if statement checking both flags inside RunE. The correct approach is MarkFlagsMutuallyExclusive which cobra enforces at parse time before RunE.",
+    "assertions": [
+      {
+        "id": "14.1",
+        "text": "Calls cmd.MarkFlagsMutuallyExclusive(\"json\", \"yaml\")"
+      },
+      {
+        "id": "14.2",
+        "text": "Does NOT write a manual if-both-set check inside RunE"
+      },
+      {
+        "id": "14.3",
+        "text": "Explains cobra enforces this at flag parse time and returns a standard error"
+      }
+    ]
+  },
+  {
+    "id": 15,
+    "name": "required-together-flags",
+    "description": "Tests MarkFlagsRequiredTogether instead of manual RunE checks",
+    "prompt": "My Go cobra command has --tls-cert and --tls-key flags. If a user provides one, they must provide the other. How do I enforce this constraint?",
+    "trap": "Without the skill, the model writes manual validation in RunE checking if one is set without the other. MarkFlagsRequiredTogether enforces this at cobra's parse stage.",
+    "assertions": [
+      {
+        "id": "15.1",
+        "text": "Calls cmd.MarkFlagsRequiredTogether(\"tls-cert\", \"tls-key\")"
+      },
+      {
+        "id": "15.2",
+        "text": "Does NOT write manual if-one-without-the-other checks inside RunE"
+      },
+      {
+        "id": "15.3",
+        "text": "Explains cobra validates this before RunE runs"
+      }
+    ]
+  },
+  {
+    "id": 16,
+    "name": "one-required-flag-group",
+    "description": "Tests MarkFlagsOneRequired instead of manual RunE checks",
+    "prompt": "My Go cobra command accepts input from either --file or --stdin. At least one must be provided. How do I enforce that the user passes at least one of them?",
+    "trap": "Without the skill, the model checks flag presence inside RunE. MarkFlagsOneRequired enforces at parse time with a standard cobra error.",
+    "assertions": [
+      {
+        "id": "16.1",
+        "text": "Calls cmd.MarkFlagsOneRequired(\"file\", \"stdin\")"
+      },
+      {
+        "id": "16.2",
+        "text": "Does NOT write a manual check inside RunE for neither flag being set"
+      },
+      {
+        "id": "16.3",
+        "text": "Explains cobra enforces this before RunE runs"
+      }
+    ]
+  },
+  {
+    "id": 17,
+    "name": "flag-changed-distinguish-explicit-zero",
+    "description": "Tests cmd.Flags().Changed() to distinguish explicit zero from absent flag",
+    "prompt": "My Go cobra command has a --timeout flag defaulting to 30s. Users can pass --timeout 0 to disable timeouts entirely. In RunE, how do I tell whether the user explicitly passed --timeout 0 or simply didn't pass --timeout at all?",
+    "trap": "Without the skill, the model checks if timeout == 0, which conflates the two cases. The correct approach is cmd.Flags().Changed(\"timeout\") which returns true only when the user explicitly provided the flag.",
+    "assertions": [
+      {
+        "id": "17.1",
+        "text": "Uses cmd.Flags().Changed(\"timeout\") to detect explicit user input"
+      },
+      {
+        "id": "17.2",
+        "text": "Does NOT use if timeout == 0 as the sole distinguishing condition"
+      },
+      {
+        "id": "17.3",
+        "text": "Explains Changed() returns true only when the flag was explicitly set by the user"
+      },
+      {
+        "id": "17.4",
+        "text": "Shows the pattern: if Changed → apply value, else → use default behavior"
+      }
+    ]
+  },
+  {
+    "id": 18,
+    "name": "postrunE-success-only-use-defer",
+    "description": "Tests that PostRunE runs only on RunE success and defer is the right cleanup pattern",
+    "prompt": "My Go cobra command opens a database connection early in RunE and I want to close it when the command finishes, whether it succeeds or fails. I added cleanup in PostRunE but noticed it doesn't run when RunE returns an error. What's the right pattern?",
+    "trap": "Without the skill, the model may suggest PersistentPostRunE or not know PostRunE is success-only. The correct pattern is defer inside RunE for guaranteed cleanup regardless of outcome.",
+    "assertions": [
+      {
+        "id": "18.1",
+        "text": "Uses defer inside RunE to guarantee cleanup on both success and failure"
+      },
+      {
+        "id": "18.2",
+        "text": "Explains PostRunE only runs when RunE returns nil (success)"
+      },
+      {
+        "id": "18.3",
+        "text": "Does NOT present PostRunE as a solution for failure cleanup"
+      }
+    ]
+  },
+  {
+    "id": 19,
+    "name": "errOrStderr-not-os-stderr",
+    "description": "Tests cmd.ErrOrStderr() instead of os.Stderr for capturable error output",
+    "prompt": "My Go cobra command writes diagnostic details to stderr using fmt.Fprintf(os.Stderr, ...) before returning an error. This works fine at runtime but my tests can't capture the stderr output. How do I fix this?",
+    "trap": "Without the skill, the model uses os.Stderr directly. The correct approach is cmd.ErrOrStderr() which tests can redirect via rootCmd.SetErr(buf).",
+    "assertions": [
+      {
+        "id": "19.1",
+        "text": "Replaces os.Stderr with cmd.ErrOrStderr() as the write target"
+      },
+      { "id": "19.2", "text": "Does NOT use os.Stderr directly" },
+      {
+        "id": "19.3",
+        "text": "Shows rootCmd.SetErr(buf) in the test to capture stderr output"
+      },
+      {
+        "id": "19.4",
+        "text": "Explains the symmetry with cmd.OutOrStdout() / SetOut for stdout"
+      }
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/commands-and-args.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/commands-and-args.md
new file mode 100644
index 00000000..ec4b69e4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/commands-and-args.md
@@ -0,0 +1,157 @@
+# Cobra Commands, Hooks, and Args Validators
+
+## The Run\* lifecycle
+
+Cobra commands have five run hooks. Cobra executes them in this fixed order:
+
+```
+PersistentPreRunE → PreRunE → RunE → PostRunE → PersistentPostRunE
+```
+
+Each `*E` hook returns `error`. The non-`*E` variants (`PersistentPreRun`, `PreRun`, `Run`, `PostRun`, `PersistentPostRun`) have signature `func(cmd *cobra.Command, args []string)` — they cannot signal failure without `os.Exit` or panic. **Always use the `*E` variants.**
+
+### Which hook to use
+
+| Hook | Scope | When to use |
+| --- | --- | --- |
+| `PersistentPreRunE` | Parent + all descendants | Config init, auth check, telemetry setup — must run before every subcommand |
+| `PreRunE` | This command only | Validation that runs only for this command before `RunE` |
+| `RunE` | This command only | Main handler — the primary business logic |
+| `PostRunE` | This command only | Cleanup that runs only if `RunE` succeeded |
+| `PersistentPostRunE` | Parent + all descendants | Global cleanup (close connections, flush buffers) |
+
+### Inheritance rules
+
+`PersistentPreRunE` defined on the root command runs before every subcommand. But if a child command defines **its own** `PersistentPreRunE`, it **replaces** (does not chain) the parent's hook. Call the parent explicitly if you need both:
+
+```go
+var childCmd = &cobra.Command{
+    PersistentPreRunE: func(cmd *cobra.Command, args []string) error {
+        // call parent's hook first
+        if err := rootCmd.PersistentPreRunE(cmd, args); err != nil {
+            return err
+        }
+        // child-specific logic
+        return nil
+    },
+}
+```
+
+### Execution stops on first error
+
+If `PersistentPreRunE` returns an error, cobra stops — `RunE` and later hooks never run. Use this for fail-fast auth checks.
+
+## Args validators
+
+Args validators run before `RunE`. Cobra prints a clear error message and exits without calling `RunE` when validation fails.
+
+### Built-in validators
+
+```go
+cobra.NoArgs                        // fails if any positional args provided
+cobra.ArbitraryArgs                 // accepts any number of args (default)
+cobra.ExactArgs(n int)              // requires exactly n args
+cobra.MinimumNArgs(n int)           // requires at least n args
+cobra.MaximumNArgs(n int)           // requires at most n args
+cobra.RangeArgs(min, max int)       // requires between min and max args
+cobra.OnlyValidArgs                 // all args must be in ValidArgs list
+cobra.ExactValidArgs(n int)         // exactly n args, all in ValidArgs
+```
+
+### Composing validators with MatchAll
+
+```go
+var deleteCmd = &cobra.Command{
+    Use:       "delete <resource>",
+    Args:      cobra.MatchAll(cobra.ExactArgs(1), cobra.OnlyValidArgs),
+    ValidArgs: []string{"pod", "service", "deployment"},
+    RunE: func(cmd *cobra.Command, args []string) error {
+        return doDelete(args[0])
+    },
+}
+```
+
+### Custom validators
+
+Signature: `func(cmd *cobra.Command, args []string) error`
+
+```go
+func validatePositiveInt(cmd *cobra.Command, args []string) error {
+    if len(args) != 1 {
+        return fmt.Errorf("requires exactly 1 arg, got %d", len(args))
+    }
+    n, err := strconv.Atoi(args[0])
+    if err != nil || n <= 0 {
+        return fmt.Errorf("argument must be a positive integer, got %q", args[0])
+    }
+    return nil
+}
+
+var cmd = &cobra.Command{
+    Args: validatePositiveInt,
+    RunE: func(cmd *cobra.Command, args []string) error { /* ... */ },
+}
+```
+
+Combine custom validators with built-in ones using `MatchAll`:
+
+```go
+Args: cobra.MatchAll(cobra.MinimumNArgs(1), validateAllPositive),
+```
+
+## Command registration and ordering
+
+```go
+func init() {
+    // groups must be registered before AddCommand
+    rootCmd.AddGroup(&cobra.Group{ID: "core", Title: "Core Commands:"})
+    rootCmd.AddGroup(&cobra.Group{ID: "management", Title: "Management Commands:"})
+
+    serveCmd.GroupID = "core"
+    migrateCmd.GroupID = "management"
+
+    rootCmd.AddCommand(serveCmd, migrateCmd, versionCmd)
+}
+```
+
+`versionCmd` has no `GroupID` — it appears in the default section.
+
+## Annotations
+
+Cobra supports arbitrary command annotations for framework-level metadata:
+
+```go
+var serveCmd = &cobra.Command{
+    Annotations: map[string]string{
+        "category": "network",
+        "requires-auth": "true",
+    },
+}
+
+// read in a middleware hook:
+if serveCmd.Annotations["requires-auth"] == "true" {
+    // enforce auth
+}
+```
+
+## Hidden and deprecated commands
+
+```go
+var internalCmd = &cobra.Command{
+    Hidden: true,      // not shown in help, still executable
+}
+
+var oldCmd = &cobra.Command{
+    Deprecated: "use `newcmd` instead",  // shown in help, prints warning on use
+}
+```
+
+## cobra.CheckErr
+
+`cobra.CheckErr(err)` is a convenience function: if `err != nil`, it prints the error to `cmd.ErrOrStderr()` and calls `os.Exit(1)`. Use it only in `main()` where you want a hard exit — not inside `RunE` where returning the error is preferred.
+
+```go
+func main() {
+    cobra.CheckErr(rootCmd.Execute())
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/completions.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/completions.md
new file mode 100644
index 00000000..673b94e3
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/completions.md
@@ -0,0 +1,119 @@
+# Cobra Shell Completions Reference
+
+Cobra generates shell completion scripts for bash, zsh, fish, and PowerShell automatically. Subcommand names and flag names are completed for free. You add completions for flag values and positional arguments.
+
+## Built-in completion command
+
+Cobra registers a `completion` subcommand automatically:
+
+```bash
+myapp completion bash   # generate bash script
+myapp completion zsh    # generate zsh script
+myapp completion fish   # generate fish script
+myapp completion powershell
+
+# Install (example for zsh):
+myapp completion zsh > "${fpath[1]}/_myapp"
+```
+
+## ShellCompDirective
+
+The `ShellCompDirective` controls shell behavior after your completion function returns:
+
+| Directive | Meaning |
+| --- | --- |
+| `ShellCompDirectiveDefault` | Fall back to file completion after your results |
+| `ShellCompDirectiveNoFileComp` | Disable file completion fallback |
+| `ShellCompDirectiveNoSpace` | Don't add a space after the completion |
+| `ShellCompDirectiveFilterFileExt(exts)` | Only show files with given extensions |
+| `ShellCompDirectiveFilterDirs(dirs)` | Only show directories |
+| `ShellCompDirectiveError` | Signal an error (show no completions) |
+
+Combine with bitwise OR: `cobra.ShellCompDirectiveNoFileComp | cobra.ShellCompDirectiveNoSpace`.
+
+Use `ShellCompDirectiveNoFileComp` whenever your list is exhaustive — it prevents the shell from appending irrelevant files.
+
+## Static arg completions
+
+```go
+var getCmd = &cobra.Command{
+    Use:       "get <resource>",
+    ValidArgs: []string{"pod", "service", "deployment", "configmap"},
+    Args:      cobra.OnlyValidArgs,
+    RunE: func(cmd *cobra.Command, args []string) error { /* ... */ },
+}
+```
+
+## Dynamic arg completions
+
+```go
+var getCmd = &cobra.Command{
+    ValidArgsFunction: func(cmd *cobra.Command, args []string, toComplete string) ([]string, cobra.ShellCompDirective) {
+        if len(args) > 0 {
+            // first arg already provided — no more completions
+            return nil, cobra.ShellCompDirectiveNoFileComp
+        }
+        resources, err := listResources(toComplete)
+        if err != nil {
+            return nil, cobra.ShellCompDirectiveError
+        }
+        return resources, cobra.ShellCompDirectiveNoFileComp
+    },
+}
+```
+
+`toComplete` is the prefix the user has typed so far — filter your results by it for responsive completions.
+
+## Flag value completions
+
+```go
+func init() {
+    rootCmd.RegisterFlagCompletionFunc("output", func(cmd *cobra.Command, args []string, toComplete string) ([]string, cobra.ShellCompDirective) {
+        return []string{"json\tJSON output", "yaml\tYAML output", "table\tTable output"}, cobra.ShellCompDirectiveNoFileComp
+    })
+
+    rootCmd.RegisterFlagCompletionFunc("namespace", func(cmd *cobra.Command, args []string, toComplete string) ([]string, cobra.ShellCompDirective) {
+        ns, err := listNamespaces()
+        if err != nil {
+            return nil, cobra.ShellCompDirectiveError
+        }
+        return ns, cobra.ShellCompDirectiveNoFileComp
+    })
+}
+```
+
+Descriptions after `\t` are shown in zsh and fish menus.
+
+## Completion annotations
+
+Mark a flag to complete as a file or directory:
+
+```go
+cmd.Flags().String("config", "", "config file")
+cmd.MarkFlagFilename("config", "yaml", "yml", "json")  // only those extensions
+
+cmd.Flags().String("dir", "", "output directory")
+cmd.MarkFlagDirname("dir")
+```
+
+## Testing completions
+
+```go
+func TestCompletion(t *testing.T) {
+    rootCmd.SetArgs([]string{"__complete", "get", ""})
+    buf := new(bytes.Buffer)
+    rootCmd.SetOut(buf)
+    rootCmd.Execute()
+    assert.Contains(t, buf.String(), "pod")
+    assert.Contains(t, buf.String(), "service")
+}
+```
+
+`__complete` is cobra's internal completion request verb. Pass the partial args as additional arguments.
+
+## Disabling the completion command
+
+```go
+rootCmd.CompletionOptions.DisableDefaultCmd = true   // remove the completion subcommand
+rootCmd.CompletionOptions.HiddenDefaultCmd = true    // keep it but hide from help
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/flags.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/flags.md
new file mode 100644
index 00000000..a4e4c67c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/flags.md
@@ -0,0 +1,125 @@
+# Cobra Flags Reference
+
+Cobra delegates all flag parsing to `github.com/spf13/pflag`. `cobra.Command` exposes two `*pflag.FlagSet`s:
+
+- `cmd.Flags()` — local flags, only available on this command.
+- `cmd.PersistentFlags()` — inherited by all subcommands.
+
+## Common flag types
+
+```go
+// String
+cmd.Flags().String("name", "default", "description")
+cmd.Flags().StringP("name", "n", "default", "description")  // with shorthand
+
+// With pointer binding (no Lookup needed later)
+var name string
+cmd.Flags().StringVar(&name, "name", "default", "description")
+cmd.Flags().StringVarP(&name, "name", "n", "default", "description")
+
+// Other types follow the same pattern:
+cmd.Flags().Int / IntVar / IntVarP
+cmd.Flags().Bool / BoolVar / BoolVarP
+cmd.Flags().Float64 / Float64Var
+cmd.Flags().Duration / DurationVar       // parses "1h30m", "500ms"
+cmd.Flags().StringSlice / StringSliceVar // comma-separated or repeated flags
+cmd.Flags().StringArray / StringArrayVar // repeated flags only (no comma splitting)
+cmd.Flags().IntSlice / IntSliceVar
+cmd.Flags().StringToString                // --label key=value --label k2=v2
+```
+
+## StringSlice vs StringArray
+
+| Flag type     | Input                 | Result                            |
+| ------------- | --------------------- | --------------------------------- |
+| `StringSlice` | `--tags a,b --tags c` | `["a", "b", "c"]` — commas split  |
+| `StringArray` | `--tags a,b --tags c` | `["a,b", "c"]` — commas NOT split |
+
+Use `StringArray` when values may legitimately contain commas.
+
+## Flag constraints
+
+```go
+// Fail if flag not provided
+cmd.MarkFlagRequired("output")
+
+// Fail if both provided
+cmd.MarkFlagsMutuallyExclusive("json", "yaml", "table")
+
+// Fail if none provided
+cmd.MarkFlagsOneRequired("file", "stdin")
+
+// Require flag only if another flag is set
+cmd.MarkFlagsMutuallyExclusive("tls", "no-tls")
+```
+
+## Persistent flag patterns
+
+```go
+func init() {
+    // global flags on root
+    rootCmd.PersistentFlags().StringVar(&cfgFile, "config", "", "config file (default: $HOME/.myapp.yaml)")
+    rootCmd.PersistentFlags().StringVar(&logLevel, "log-level", "info", "log level (debug, info, warn, error)")
+
+    // bind to viper immediately after defining
+    viper.BindPFlag("config", rootCmd.PersistentFlags().Lookup("config"))
+    viper.BindPFlag("log-level", rootCmd.PersistentFlags().Lookup("log-level"))
+}
+```
+
+## Custom flag value types
+
+Implement `pflag.Value` to parse arbitrary types:
+
+```go
+type enumValue struct {
+    val     string
+    allowed []string
+}
+
+func (e *enumValue) String() string { return e.val }
+func (e *enumValue) Type() string   { return "enum" }
+func (e *enumValue) Set(s string) error {
+    for _, a := range e.allowed {
+        if s == a {
+            e.val = s
+            return nil
+        }
+    }
+    return fmt.Errorf("must be one of %v", e.allowed)
+}
+
+var outputFmt = &enumValue{val: "table", allowed: []string{"table", "json", "yaml"}}
+cmd.Flags().Var(outputFmt, "output", "output format (table, json, yaml)")
+```
+
+## Flag groups (required together)
+
+Mark a set of flags that must all be provided if any one of them is provided:
+
+```go
+cmd.Flags().String("tls-cert", "", "TLS certificate file")
+cmd.Flags().String("tls-key", "", "TLS key file")
+cmd.MarkFlagsRequiredTogether("tls-cert", "tls-key")
+```
+
+## Accessing flag values
+
+Prefer pointer binding (`StringVar`, `IntVar`, etc.) for type-safe access. When you need the flag post-parse:
+
+```go
+port, err := cmd.Flags().GetInt("port")
+name, err := cmd.Flags().GetString("name")
+tags, err := cmd.Flags().GetStringSlice("tags")
+```
+
+## Flag changed vs default
+
+```go
+if cmd.Flags().Changed("port") {
+    // user explicitly provided --port
+    // useful when distinguishing "user set 0" from "flag not provided"
+}
+```
+
+`Changed()` is also how viper knows which flags are explicit overrides — it only promotes a flag to the highest precedence layer if `Changed()` is true.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/generators.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/generators.md
new file mode 100644
index 00000000..d7c587dd
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/generators.md
@@ -0,0 +1,111 @@
+# Cobra Documentation and Scaffolding Generators
+
+## Doc generation
+
+Cobra can generate documentation from your command tree in multiple formats. Import the `cobra/doc` sub-package:
+
+```bash
+go get github.com/spf13/cobra/doc
+```
+
+### Markdown
+
+```go
+import "github.com/spf13/cobra/doc"
+
+err := doc.GenMarkdownTree(rootCmd, "/tmp/docs/")
+// generates /tmp/docs/myapp.md, /tmp/docs/myapp_serve.md, etc.
+
+// Single command
+var buf bytes.Buffer
+doc.GenMarkdown(rootCmd, &buf)
+```
+
+### Man pages
+
+```go
+header := &doc.GenManHeader{
+    Title:   "MYAPP",
+    Section: "1",
+    Date:    &time.Time{},
+    Source:  "myapp v1.0.0",
+    Manual:  "User Commands",
+}
+err := doc.GenManTree(rootCmd, header, "/usr/local/share/man/man1/")
+```
+
+### YAML
+
+```go
+err := doc.GenYamlTree(rootCmd, "/tmp/docs/")
+```
+
+### RST (reStructuredText)
+
+```go
+err := doc.GenReSTTree(rootCmd, "/tmp/docs/")
+```
+
+## cobra-cli scaffolder
+
+`cobra-cli` generates command files and wires them into your project:
+
+```bash
+go get -tool github.com/spf13/cobra-cli@latest
+
+# Initialize a new cobra project
+go tool cobra-cli init myapp
+
+# Add a subcommand
+go tool cobra-cli add serve
+go tool cobra-cli add migrate
+
+# Add with a parent other than root
+cobra-cli add list --parent serve
+```
+
+Generated files follow the standard pattern:
+
+```go
+// cmd/serve.go
+var serveCmd = &cobra.Command{
+    Use:   "serve",
+    Short: "A brief description of your command",
+    RunE: func(cmd *cobra.Command, args []string) error {
+        return nil
+    },
+}
+
+func init() {
+    rootCmd.AddCommand(serveCmd)
+}
+```
+
+`cobra-cli` is optional — many teams write command files by hand following the same pattern.
+
+## Help and usage template customization
+
+Override the default help template:
+
+```go
+rootCmd.SetHelpTemplate(`
+Usage:  {{.UseLine}}
+{{if .HasAvailableSubCommands}}
+Commands:
+{{range .Commands}}{{if .IsAvailableCommand}}  {{rpad .Name .NamePadding }} {{.Short}}
+{{end}}{{end}}{{end}}
+Flags:
+{{.LocalFlags.FlagUsages | trimRightSpace}}
+`)
+```
+
+Override the usage function entirely:
+
+```go
+rootCmd.SetUsageFunc(func(cmd *cobra.Command) error {
+    fmt.Fprintf(cmd.OutOrStdout(), "Custom usage for %s\n", cmd.Name())
+    return nil
+})
+```
+
+Common template functions available: `rpad`, `trimRightSpace`, `gt`, `eq`.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/testing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/testing.md
new file mode 100644
index 00000000..1e520bb9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-cobra/references/testing.md
@@ -0,0 +1,154 @@
+# Testing Cobra Commands
+
+## Basic test pattern
+
+```go
+func TestServeCmd(t *testing.T) {
+    stdout := new(bytes.Buffer)
+    stderr := new(bytes.Buffer)
+
+    rootCmd.SetOut(stdout)
+    rootCmd.SetErr(stderr)
+    rootCmd.SetArgs([]string{"serve", "--port", "9090", "--dry-run"})
+
+    err := rootCmd.Execute()
+    require.NoError(t, err)
+    assert.Contains(t, stdout.String(), "listening on :9090")
+    assert.Empty(t, stderr.String())
+}
+```
+
+## Isolation between tests
+
+Cobra accumulates flag state across `Execute()` calls on the same command instance. Tests must be isolated.
+
+### Option 1: Re-create the command tree per test (recommended for unit tests)
+
+```go
+func newRootCmd() *cobra.Command {
+    root := &cobra.Command{Use: "myapp", SilenceUsage: true, SilenceErrors: true}
+    root.AddCommand(newServeCmd())
+    return root
+}
+
+func TestServeCmd(t *testing.T) {
+    root := newRootCmd()
+    root.SetArgs([]string{"serve", "--port", "9090"})
+    err := root.Execute()
+    require.NoError(t, err)
+}
+```
+
+### Option 2: Reset flags between tests
+
+```go
+func TestWithReset(t *testing.T) {
+    t.Cleanup(func() {
+        rootCmd.ResetFlags()
+        // re-define flags if needed
+    })
+}
+```
+
+Re-creating is safer — `ResetFlags` only clears the flag set, not subcommand state.
+
+## Testing commands that write output
+
+Commands must use `cmd.OutOrStdout()` / `cmd.ErrOrStderr()` instead of `os.Stdout` / `os.Stderr` for this to work.
+
+```go
+// In command handler:
+func runServe(cmd *cobra.Command, args []string) error {
+    fmt.Fprintln(cmd.OutOrStdout(), "Server started")
+    fmt.Fprintln(cmd.ErrOrStderr(), "Debug: listening on port 8080")
+    return nil
+}
+
+// In test:
+buf := new(bytes.Buffer)
+rootCmd.SetOut(buf)
+rootCmd.Execute()
+assert.Contains(t, buf.String(), "Server started")
+```
+
+## Golden file tests
+
+For commands with structured or lengthy output, use golden files:
+
+```go
+func TestOutputFormat(t *testing.T) {
+    buf := new(bytes.Buffer)
+    rootCmd.SetOut(buf)
+    rootCmd.SetArgs([]string{"list", "--output", "json"})
+    require.NoError(t, rootCmd.Execute())
+
+    golden := "testdata/list-json.golden"
+    if *update {  // -update flag
+        os.WriteFile(golden, buf.Bytes(), 0644)
+    }
+    want, _ := os.ReadFile(golden)
+    assert.Equal(t, string(want), buf.String())
+}
+```
+
+Run with `-update` to regenerate golden files after intentional output changes.
+
+## Testing error paths
+
+```go
+func TestInvalidArgs(t *testing.T) {
+    stderr := new(bytes.Buffer)
+    rootCmd.SetErr(stderr)
+    rootCmd.SetArgs([]string{"delete"})  // missing required arg
+
+    err := rootCmd.Execute()
+    assert.Error(t, err)
+    assert.Contains(t, err.Error(), "accepts 1 arg")
+}
+```
+
+## Table-driven command tests
+
+```go
+tests := []struct {
+    name    string
+    args    []string
+    wantOut string
+    wantErr bool
+}{
+    {"no flags", []string{"serve"}, "listening on :8080", false},
+    {"custom port", []string{"serve", "--port", "9090"}, "listening on :9090", false},
+    {"invalid port", []string{"serve", "--port", "abc"}, "", true},
+}
+
+for _, tt := range tests {
+    t.Run(tt.name, func(t *testing.T) {
+        root := newRootCmd()  // fresh command tree per test
+        buf := new(bytes.Buffer)
+        root.SetOut(buf)
+        root.SetArgs(tt.args)
+        err := root.Execute()
+        if tt.wantErr {
+            assert.Error(t, err)
+        } else {
+            require.NoError(t, err)
+            assert.Contains(t, buf.String(), tt.wantOut)
+        }
+    })
+}
+```
+
+## Testing completions
+
+```go
+func TestCompletion(t *testing.T) {
+    root := newRootCmd()
+    buf := new(bytes.Buffer)
+    root.SetOut(buf)
+    root.SetArgs([]string{"__complete", "delete", ""})
+    root.Execute()
+
+    assert.Contains(t, buf.String(), "pod")
+    assert.Contains(t, buf.String(), "service")
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/SKILL.md
new file mode 100644
index 00000000..a49280bb
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/SKILL.md
@@ -0,0 +1,180 @@
+---
+name: golang-spf13-viper
+description: "Golang configuration library using spf13/viper — layered precedence (flag > env > file > KV > default), BindPFlag/BindPFlags, SetEnvPrefix + SetEnvKeyReplacer + AutomaticEnv, ReadInConfig + ConfigFileNotFoundError, Unmarshal + mapstructure struct tags, Sub for sub-trees, WatchConfig + OnConfigChange for hot reload, viper.New() for test isolation, and remote KV integration. Apply when using or adopting spf13/viper, or when the codebase imports `github.com/spf13/viper`. For CLI command structure alongside viper, see the `samber/cc-skills-golang@golang-spf13-cobra` skill. For general CLI architecture, see `samber/cc-skills-golang@golang-cli`."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.0.1"
+  openclaw:
+    emoji: "🔧"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "1.21.0"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs
+---
+
+**Persona:** You are a Go engineer who treats configuration as a layered system. Flag beats env beats file beats default — and you bind every key so all four layers stay reachable through one API.
+
+# Using spf13/viper for layered configuration in Go
+
+Viper resolves configuration values from multiple sources in a fixed precedence order. It has no user-facing surface — it doesn't define commands or flags. Its job is to answer "what is the value of key X right now?" by walking its source layers from highest to lowest priority.
+
+**Official Resources:**
+
+- [pkg.go.dev/github.com/spf13/viper](https://pkg.go.dev/github.com/spf13/viper)
+- [github.com/spf13/viper](https://github.com/spf13/viper)
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+```bash
+go get github.com/spf13/viper@latest
+```
+
+## Viper vs. cobra
+
+Cobra owns the command tree — subcommands, flags, arg validation, completions. Viper owns configuration resolution — it answers "what is the value of key X?" by walking its source layers. Viper has no user-facing surface; it is purely a key-value resolver. Use cobra alone for flag-only CLIs; viper alone for config-file daemons; both when you need both, binding flags at `PersistentPreRunE` via `BindPFlag`.
+
+→ See `samber/cc-skills-golang@golang-spf13-cobra` for the cobra side of this integration.
+
+## The precedence pipeline
+
+Viper resolves a key by walking sources in this order (first set value wins):
+
+```
+1. explicit Set()      — viper.Set("key", val)    highest priority
+2. flag                — bound pflag.Flag
+3. env var             — BindEnv / AutomaticEnv
+4. config file         — ReadInConfig / MergeInConfig
+5. KV remote           — etcd / Consul
+6. default             — viper.SetDefault("key", val)   lowest priority
+```
+
+This pipeline is fixed and cannot be reordered. Understanding it prevents most viper bugs: a key that "should" come from a config file may be shadowed by an env var or a flag with a default value.
+
+## Sources and config files
+
+```go
+viper.SetConfigName("config")
+viper.AddConfigPath("$HOME/.myapp")
+if err := viper.ReadInConfig(); err != nil {
+    var notFound *viper.ConfigFileNotFoundError
+    if !errors.As(err, &notFound) {
+        return fmt.Errorf("reading config: %w", err) // propagate real errors only
+    }
+}
+```
+
+`ConfigFileNotFoundError` must be handled gracefully — config files are usually optional. An unhandled error from a missing file crashes programs that are perfectly valid when run with only flags or env vars.
+
+For supported formats (JSON, TOML, YAML, HCL, INI, properties), `MergeInConfig`, and remote KV, see [sources-and-formats.md](references/sources-and-formats.md).
+
+## Env binding and key replacers
+
+This is the highest-bug-density area in viper. All three settings must be wired together — missing any one breaks nested key resolution:
+
+```go
+// ✓ Good — all three wired together at startup
+viper.SetEnvPrefix("MYAPP")                             // prevent collisions: PORT → MYAPP_PORT
+viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))  // database.host → MYAPP_DATABASE_HOST
+viper.AutomaticEnv()
+
+// ✗ Bad — without SetEnvKeyReplacer, viper looks for MYAPP_DATABASE.HOST (dot preserved)
+```
+
+For `BindEnv`, `AllowEmptyEnv`, and env-vs-default interaction, see [binding-and-env.md](references/binding-and-env.md).
+
+## Flag binding (the cobra seam)
+
+Bind cobra flags to viper in `init()` or `PersistentPreRunE` — never in `RunE` (config loading in `PersistentPreRunE` already ran before `RunE`, so bindings set in `RunE` are missed):
+
+```go
+func init() {
+    rootCmd.PersistentFlags().Int("port", 8080, "listen port")
+    viper.BindPFlag("port", rootCmd.PersistentFlags().Lookup("port"))
+    // viper.BindPFlags(cmd.Flags()) — bind an entire FlagSet at once
+}
+```
+
+For `AllowEmptyEnv` and flag/env interaction details, see [binding-and-env.md](references/binding-and-env.md).
+
+## Unmarshaling into structs
+
+`viper.Unmarshal` maps the resolved configuration into a struct using `mapstructure`:
+
+```go
+type Config struct {
+    Port     int `mapstructure:"port"`
+    Database struct {
+        MaxConn int `mapstructure:"max_conn"` // explicit tag: mapstructure won't convert underscore→camelCase
+    } `mapstructure:"database"`
+}
+var cfg Config
+viper.Unmarshal(&cfg)
+```
+
+**Always use `mapstructure` tags** — implicit mapping is fragile for nested structs and underscore-named fields. Prefer `UnmarshalKey("database", &dbCfg)` over `Sub("database").Unmarshal` — it avoids the nil-check `Sub` requires when the key is missing.
+
+For `time.Duration` / `net.IP` / slice decoders and custom `DecodeHook` registration, see [unmarshal.md](references/unmarshal.md).
+
+## Sub-trees
+
+`viper.Sub("database")` returns a new `*viper.Viper` scoped to the prefix, or **nil** if the key does not exist — always nil-check before calling methods on the result. Prefer `UnmarshalKey("database", &dbCfg)` which avoids the nil risk entirely.
+
+## Hot reload
+
+```go
+viper.WatchConfig()
+viper.OnConfigChange(func(e fsnotify.Event) { /* re-apply changed values */ })
+```
+
+`WatchConfig` uses fsnotify and watches inodes. Editors that write atomically via rename (vim, neovim) replace the inode — the callback may not fire. Test hot-reload with `echo >> config.yaml`, not editor saves. For race-safe reload patterns, see [watch-and-reload.md](references/watch-and-reload.md).
+
+## Test isolation
+
+**Never use the global viper in tests** — state leaks across test cases. Use `viper.New()` per test so each instance is isolated:
+
+```go
+v := viper.New()
+v.SetConfigFile("testdata/config.yaml")
+require.NoError(t, v.ReadInConfig())
+```
+
+For `t.Setenv` interactions and `Reset()` limitations, see [testing-and-isolation.md](references/testing-and-isolation.md).
+
+## Best Practices
+
+1. **Set prefix + key replacer + AutomaticEnv together** — missing any one causes nested env keys to silently not resolve (`database.host` → `DATABASE.HOST` instead of `DATABASE_HOST`).
+2. **Handle `ConfigFileNotFoundError` gracefully** — a missing config file should not crash a service that runs with only flags and env vars.
+3. **Always use `mapstructure` tags on config structs** — implicit mapping silently misses nested and underscore-named fields.
+4. **Use `viper.New()` in tests, never the global** — the global accumulates state across test runs; per-test instances are isolated.
+5. **Bind flags before `Execute()`** — binding in `RunE` is too late; cobra parses flags before `RunE` runs.
+
+## Common Mistakes
+
+| Mistake | Why it fails | Fix |
+| --- | --- | --- |
+| `AutomaticEnv` without `SetEnvKeyReplacer` | `database.host` looks for `MYAPP_DATABASE.HOST` (dot preserved) — never matches | Add `SetEnvKeyReplacer(strings.NewReplacer(".", "_"))` before `AutomaticEnv` |
+| No `mapstructure` tags on struct fields | Silently misses nested and underscore-named fields | Add `mapstructure:"key_name"` to every field |
+| Using global viper in tests | State from one test contaminates the next, causing flaky ordering | Create `viper.New()` per test |
+| Missing `ConfigFileNotFoundError` check | Missing config file crashes a service that should run on flags/env alone | `errors.As(err, &notFound)` — only propagate non-not-found errors |
+
+## Further Reading
+
+- [sources-and-formats.md](references/sources-and-formats.md) — supported file formats, multi-path search, MergeInConfig, remote KV (etcd/Consul)
+- [binding-and-env.md](references/binding-and-env.md) — BindEnv, AutomaticEnv, SetEnvPrefix, SetEnvKeyReplacer, AllowEmptyEnv, timing rules
+- [unmarshal.md](references/unmarshal.md) — Unmarshal, UnmarshalKey, mapstructure tags, custom DecodeHooks (Duration, IP, slice)
+- [watch-and-reload.md](references/watch-and-reload.md) — WatchConfig, OnConfigChange, fsnotify caveats, atomic-rename trap, race-safe patterns
+- [testing-and-isolation.md](references/testing-and-isolation.md) — viper.New() per test, t.Setenv interactions, Reset() limitations, snapshot/restore
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-cli` skill for general CLI architecture — project layout, exit codes, signal handling, cobra+viper integration
+- → See `samber/cc-skills-golang@golang-spf13-cobra` skill for the cobra side of this integration (flag definition and binding)
+- → See `samber/cc-skills-golang@golang-testing` skill for general Go testing patterns
+
+If you encounter a bug or unexpected behavior in spf13/viper, open an issue at <https://github.com/spf13/viper/issues>.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/evals/evals.json
new file mode 100644
index 00000000..fa296441
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/evals/evals.json
@@ -0,0 +1,465 @@
+[
+  {
+    "id": 1,
+    "name": "env-key-replacer-nested-keys",
+    "description": "Tests SetEnvKeyReplacer for nested keys with dots mapping to underscore env vars",
+    "prompt": "I'm using viper in my Go service. I have a config key 'database.host' that should be configurable via an env var. I've set AutomaticEnv() and SetEnvPrefix('APP'). My env var APP_DATABASE_HOST is set but viper returns the default. What's wrong?",
+    "trap": "Without the skill, the model may suggest checking the env var name, case sensitivity, or re-reading the config. The root cause is the missing SetEnvKeyReplacer — viper looks for APP_DATABASE.HOST (dot preserved), not APP_DATABASE_HOST.",
+    "assertions": [
+      {
+        "id": "1.1",
+        "text": "Identifies the root cause as missing SetEnvKeyReplacer"
+      },
+      {
+        "id": "1.2",
+        "text": "Explains that viper preserves the dot in 'database.host' when looking up the env var"
+      },
+      {
+        "id": "1.3",
+        "text": "Provides the fix: viper.SetEnvKeyReplacer(strings.NewReplacer(\".\", \"_\"))"
+      },
+      {
+        "id": "1.4",
+        "text": "Shows that the full setup requires prefix + replacer + AutomaticEnv together"
+      },
+      {
+        "id": "1.5",
+        "text": "Does NOT suggest renaming the config key to avoid dots"
+      }
+    ]
+  },
+  {
+    "id": 2,
+    "name": "sub-returns-nil",
+    "description": "Tests that viper.Sub() returns nil when the key doesn't exist and must be nil-checked",
+    "prompt": "I'm using viper.Sub('database') in my Go service to get a sub-viper for database config, then calling sub.Unmarshal(&dbCfg). Occasionally the service panics with a nil pointer dereference. What's happening?",
+    "trap": "Without the skill, the model may suggest checking the config file format or adding error handling to Unmarshal. The root cause is Sub() returning nil when the 'database' key doesn't exist, and nil.Unmarshal panics.",
+    "assertions": [
+      {
+        "id": "2.1",
+        "text": "Identifies that viper.Sub() returns nil when the key doesn't exist"
+      },
+      {
+        "id": "2.2",
+        "text": "Shows adding a nil check: if sub := viper.Sub(\"database\"); sub != nil { ... }"
+      },
+      {
+        "id": "2.3",
+        "text": "Suggests returning a clear error or using defaults when sub is nil"
+      },
+      {
+        "id": "2.4",
+        "text": "Does NOT suggest checking err from Sub() (it returns no error, only nil)"
+      },
+      {
+        "id": "2.5",
+        "text": "Optionally suggests UnmarshalKey(\"database\", &dbCfg) as an alternative that avoids Sub() entirely"
+      }
+    ]
+  },
+  {
+    "id": 3,
+    "name": "config-file-not-found-graceful",
+    "description": "Tests graceful handling of ConfigFileNotFoundError for optional config files",
+    "prompt": "My Go service uses viper to read a config file. When users run it without a config file, it crashes with 'Config File config not found in ...'. The config file should be optional. How do I fix this?",
+    "trap": "Without the skill, the model may suggest pre-checking if the file exists before calling ReadInConfig, or using os.Stat. The correct pattern is errors.As with viper.ConfigFileNotFoundError.",
+    "assertions": [
+      {
+        "id": "3.1",
+        "text": "Uses errors.As(err, &notFound) with *viper.ConfigFileNotFoundError"
+      },
+      {
+        "id": "3.2",
+        "text": "Only propagates errors that are NOT ConfigFileNotFoundError"
+      },
+      {
+        "id": "3.3",
+        "text": "Continues execution normally when the config file is not found"
+      },
+      {
+        "id": "3.4",
+        "text": "Does NOT use os.Stat or file existence check as the solution"
+      },
+      {
+        "id": "3.5",
+        "text": "Does NOT ignore all errors from ReadInConfig (real errors like bad YAML should still propagate)"
+      }
+    ]
+  },
+  {
+    "id": 4,
+    "name": "global-viper-test-pollution",
+    "description": "Tests viper.New() for test isolation instead of the global instance",
+    "prompt": "My Go tests for config loading are flaky — they pass when run in isolation but fail in a certain order. Each test calls viper.SetConfigFile and viper.ReadInConfig. What's causing this and how do I fix it?",
+    "trap": "Without the skill, the model may suggest adding t.Cleanup(viper.Reset) or running tests with -count=1. The correct fix is creating viper.New() per test to avoid shared global state.",
+    "assertions": [
+      {
+        "id": "4.1",
+        "text": "Identifies the root cause as shared global viper state across tests"
+      },
+      {
+        "id": "4.2",
+        "text": "Recommends viper.New() per test to create an isolated instance"
+      },
+      {
+        "id": "4.3",
+        "text": "Shows v := viper.New() and using v.SetConfigFile, v.ReadInConfig, etc."
+      },
+      {
+        "id": "4.4",
+        "text": "Does NOT recommend viper.Reset() as the primary solution"
+      },
+      {
+        "id": "4.5",
+        "text": "Explains why the tests are order-dependent (state set in one test persists to the next)"
+      }
+    ]
+  },
+  {
+    "id": 5,
+    "name": "unmarshal-mapstructure-tags",
+    "description": "Tests use of mapstructure struct tags for correct Unmarshal behavior",
+    "prompt": "I'm unmarshaling my viper config into a Go struct. My config file has 'max_conn: 25' but after calling viper.Unmarshal(&cfg), cfg.MaxConn is always 0. My struct has field MaxConn int. What's wrong?",
+    "trap": "Without the skill, the model may suggest checking the config file key name or viper.GetInt. The fix is adding mapstructure:\"max_conn\" tag — without it, mapstructure uses case-insensitive name matching but doesn't handle underscores to camel-case conversion.",
+    "assertions": [
+      {
+        "id": "5.1",
+        "text": "Identifies the missing mapstructure struct tag as the root cause"
+      },
+      {
+        "id": "5.2",
+        "text": "Shows adding `mapstructure:\"max_conn\"` to the MaxConn field"
+      },
+      {
+        "id": "5.3",
+        "text": "Explains that mapstructure does case-insensitive matching but not underscore-to-camelcase conversion"
+      },
+      {
+        "id": "5.4",
+        "text": "Does NOT suggest using viper.GetInt as the fix (Unmarshal should work once tagged correctly)"
+      }
+    ]
+  },
+  {
+    "id": 6,
+    "name": "bind-pflag-timing",
+    "description": "Tests that BindPFlag must be called before Execute() runs",
+    "prompt": "I'm integrating cobra and viper in my Go CLI. I call viper.BindPFlag in the command's RunE function to bind the --port flag. But viper.GetInt('port') always returns the default 8080, even when I pass --port 9090. Why?",
+    "trap": "Without the skill, the model may check the flag name spelling or viper setup. The root cause is binding after Execute() has already parsed the flags — BindPFlag must happen in init() or PersistentPreRunE, before the flags are resolved.",
+    "assertions": [
+      {
+        "id": "6.1",
+        "text": "Identifies that BindPFlag must be called before Execute() / before RunE runs"
+      },
+      {
+        "id": "6.2",
+        "text": "Recommends moving BindPFlag to init() or PersistentPreRunE"
+      },
+      {
+        "id": "6.3",
+        "text": "Explains that cobra parses flags before RunE runs — binding after parsing misses the Changed state"
+      },
+      {
+        "id": "6.4",
+        "text": "Shows the correct pattern: define flag + BindPFlag in init()"
+      }
+    ]
+  },
+  {
+    "id": 7,
+    "name": "viper-key-case-insensitivity",
+    "description": "Tests understanding that viper keys are always lowercased internally",
+    "prompt": "I'm calling viper.GetString('DATABASE_HOST') in my Go service to read a config key. The config file has 'database_host: localhost' but I get an empty string. What's wrong?",
+    "trap": "Without the skill, the model may suggest checking env binding or config format. Viper lowercases all keys internally — 'DATABASE_HOST' is stored as 'database_host', but the lookup 'DATABASE_HOST' is also lowercased to 'database_host', so it should match. However, this highlights the convention: always use lowercase keys in viper calls.",
+    "assertions": [
+      {
+        "id": "7.1",
+        "text": "Explains that viper normalizes all keys to lowercase internally"
+      },
+      {
+        "id": "7.2",
+        "text": "Recommends using lowercase keys consistently in viper.Get* calls"
+      },
+      {
+        "id": "7.3",
+        "text": "Identifies that viper.GetString(\"database_host\") is the correct form"
+      },
+      {
+        "id": "7.4",
+        "text": "Notes that while viper.GetString(\"DATABASE_HOST\") also works (due to lowercasing), using uppercase keys is a source of confusion"
+      }
+    ]
+  },
+  {
+    "id": 8,
+    "name": "duration-decode-hook",
+    "description": "Tests that time.Duration fields in structs require a decode hook for Unmarshal to work",
+    "prompt": "My Go viper config has 'timeout: 30s' in the YAML file. My struct has Timeout time.Duration and the mapstructure tag. After viper.Unmarshal, cfg.Timeout is 0. Why?",
+    "trap": "Without the skill, the model may suggest using GetDuration or changing the config format to nanoseconds. The correct fix is registering StringToTimeDurationHookFunc via a decode hook option in Unmarshal.",
+    "assertions": [
+      {
+        "id": "8.1",
+        "text": "Identifies that mapstructure cannot decode a duration string into time.Duration without a hook"
+      },
+      {
+        "id": "8.2",
+        "text": "Shows viper.Unmarshal(&cfg, func(dc *mapstructure.DecoderConfig) { dc.DecodeHook = mapstructure.ComposeDecodeHookFunc(mapstructure.StringToTimeDurationHookFunc(), ...) })"
+      },
+      {
+        "id": "8.3",
+        "text": "Uses mapstructure.StringToTimeDurationHookFunc() as part of the hook"
+      },
+      {
+        "id": "8.4",
+        "text": "Does NOT suggest changing the config value to nanoseconds"
+      }
+    ]
+  },
+  {
+    "id": 9,
+    "name": "watch-config-atomic-rename-trap",
+    "description": "Tests understanding of fsnotify behavior with editors that use atomic rename",
+    "prompt": "I've set up viper.WatchConfig() in my Go service. When I test it by editing the config file in vim and saving, the OnConfigChange callback sometimes doesn't fire. What's happening?",
+    "trap": "Without the skill, the model may suggest checking fsnotify version or debugging the callback. The root cause is that vim uses atomic rename (write-tmp, rename) which replaces the inode — fsnotify watches the inode and may miss or misfire for rename-based writes.",
+    "assertions": [
+      {
+        "id": "9.1",
+        "text": "Explains that vim and many editors write atomically via rename (write-to-temp, then rename over original)"
+      },
+      {
+        "id": "9.2",
+        "text": "Explains that fsnotify watches the inode, which is replaced by rename-based writes"
+      },
+      {
+        "id": "9.3",
+        "text": "Recommends testing hot-reload using direct writes (os.WriteFile) rather than editor saves"
+      },
+      {
+        "id": "9.4",
+        "text": "Does NOT suggest downgrading vim or switching to a different editor as the fix"
+      }
+    ]
+  },
+  {
+    "id": 10,
+    "name": "viper-alone-no-cobra",
+    "description": "Tests that viper can be used without cobra for non-CLI services",
+    "prompt": "I have a Go HTTP service (not a CLI) that should read config from a YAML file and environment variables. Should I use cobra alongside viper, or can I just use viper on its own?",
+    "trap": "Without the skill, the model may suggest always pairing them or adding a minimal cobra setup. Viper is perfectly valid alone for services that have no CLI command tree.",
+    "assertions": [
+      {
+        "id": "10.1",
+        "text": "Clearly states that viper can be used without cobra"
+      },
+      {
+        "id": "10.2",
+        "text": "Explains cobra is for command trees/flags and is not needed for a simple HTTP service"
+      },
+      { "id": "10.3", "text": "Shows viper setup without any cobra imports" },
+      {
+        "id": "10.4",
+        "text": "Does NOT recommend adding cobra just for configuration purposes"
+      }
+    ]
+  },
+  {
+    "id": 11,
+    "name": "unmarshal-key-vs-sub",
+    "description": "Tests UnmarshalKey as a simpler alternative to Sub+Unmarshal",
+    "prompt": "I want to unmarshal just the 'database' section of my viper config into a DatabaseConfig struct in Go. I've been using viper.Sub('database') then calling Unmarshal on the result. Is there a simpler way?",
+    "trap": "Without the skill, the model may continue recommending Sub+Unmarshal without mentioning the nil risk or the cleaner alternative. UnmarshalKey avoids the Sub nil-check and is more direct.",
+    "assertions": [
+      {
+        "id": "11.1",
+        "text": "Recommends viper.UnmarshalKey(\"database\", &dbCfg) as the simpler alternative"
+      },
+      {
+        "id": "11.2",
+        "text": "Explains it avoids the nil check required with Sub()"
+      },
+      {
+        "id": "11.3",
+        "text": "Shows the correct usage: viper.UnmarshalKey(\"database\", &dbCfg)"
+      },
+      {
+        "id": "11.4",
+        "text": "If mentioning Sub+Unmarshal, notes the nil risk"
+      }
+    ]
+  },
+  {
+    "id": 12,
+    "name": "allow-empty-env",
+    "description": "Tests AllowEmptyEnv behavior when an env var is set to empty string",
+    "prompt": "In my Go service using viper, I set LOG_LEVEL='' (empty string) in my environment to override the config file value. But viper still returns the config file value 'info'. Why does the empty env var not take effect?",
+    "trap": "Without the skill, the model may suggest checking AutomaticEnv or the prefix. By default, viper ignores empty-string env vars and continues down the precedence stack. AllowEmptyEnv(true) changes this behavior.",
+    "assertions": [
+      {
+        "id": "12.1",
+        "text": "Explains that viper treats empty string env vars as 'not set' by default"
+      },
+      {
+        "id": "12.2",
+        "text": "Introduces viper.AllowEmptyEnv(true) as the fix"
+      },
+      {
+        "id": "12.3",
+        "text": "Explains that with AllowEmptyEnv(true), an empty env var overrides the config file value"
+      },
+      {
+        "id": "12.4",
+        "text": "Does NOT suggest using viper.Set() as a workaround"
+      }
+    ]
+  },
+  {
+    "id": 13,
+    "name": "merge-in-config-layering",
+    "description": "Tests MergeInConfig for base+override config file pattern",
+    "prompt": "I want my Go service to ship with a built-in default config file, but let ops teams drop an override.yaml in /etc/myapp/ to customize specific values without copying the whole config. How do I implement this layered loading?",
+    "trap": "Without the skill, the model may suggest reading only one file or writing custom merge logic. MergeInConfig is the viper primitive for this — base file first, then MergeInConfig for the override.",
+    "assertions": [
+      {
+        "id": "13.1",
+        "text": "Uses ReadInConfig for the base config and MergeInConfig for the override"
+      },
+      {
+        "id": "13.2",
+        "text": "Explains that keys from the override file win on collision"
+      },
+      {
+        "id": "13.3",
+        "text": "Does NOT suggest duplicating the entire config in the override file"
+      },
+      {
+        "id": "13.4",
+        "text": "Handles the case where the override file is missing (ConfigFileNotFoundError or os.Stat check)"
+      }
+    ]
+  },
+  {
+    "id": 14,
+    "name": "bind-env-non-prefixed-third-party",
+    "description": "Tests BindEnv for env vars that don't follow the app prefix convention",
+    "prompt": "My Go service uses viper with SetEnvPrefix('MYAPP') and AutomaticEnv(). I also need to read GOOGLE_APPLICATION_CREDENTIALS from the environment and expose it as viper key 'google.credentials'. The prefix makes AutomaticEnv look for MYAPP_GOOGLE_CREDENTIALS. How do I bind to the exact env var name?",
+    "trap": "Without the skill, the model may suggest removing the prefix or reading via os.Getenv. BindEnv can bind a specific key to a specific env var name, bypassing the prefix.",
+    "assertions": [
+      {
+        "id": "14.1",
+        "text": "Uses viper.BindEnv(\"google.credentials\", \"GOOGLE_APPLICATION_CREDENTIALS\")"
+      },
+      {
+        "id": "14.2",
+        "text": "Explains BindEnv binds to the exact env var name, bypassing the prefix"
+      },
+      {
+        "id": "14.3",
+        "text": "Does NOT suggest removing SetEnvPrefix to fix this one case"
+      },
+      {
+        "id": "14.4",
+        "text": "Does NOT suggest using os.Getenv as the primary solution"
+      }
+    ]
+  },
+  {
+    "id": 15,
+    "name": "race-safe-on-config-change",
+    "description": "Tests mutex protection for shared state updated in OnConfigChange callback",
+    "prompt": "My Go service updates a global logLevel variable inside the viper.OnConfigChange callback. Under load I see data races flagged by the race detector. What's the correct pattern for updating shared state from a hot-reload callback?",
+    "trap": "Without the skill, the model may only mention logging the error or ignoring the race. The correct pattern is protecting the shared state with sync.RWMutex — OnConfigChange runs in a background goroutine.",
+    "assertions": [
+      {
+        "id": "15.1",
+        "text": "Identifies that OnConfigChange runs in a background goroutine, causing the race"
+      },
+      {
+        "id": "15.2",
+        "text": "Uses sync.RWMutex (or sync.Mutex) to protect the shared state"
+      },
+      {
+        "id": "15.3",
+        "text": "Updates the shared state under Lock() inside OnConfigChange"
+      },
+      {
+        "id": "15.4",
+        "text": "Readers of the shared state use RLock()"
+      }
+    ]
+  },
+  {
+    "id": 16,
+    "name": "go-embed-default-config",
+    "description": "Tests go:embed + viper.ReadConfig for shipping default config in the binary",
+    "prompt": "I want my Go service binary to work out of the box without any config file on disk by including sensible defaults in a bundled YAML file. How do I ship a default config inside the binary and load it via viper?",
+    "trap": "Without the skill, the model suggests calling viper.SetDefault for each key individually. The cleaner approach is //go:embed + viper.ReadConfig(bytes.NewReader(...)) which loads a full YAML file as defaults.",
+    "assertions": [
+      {
+        "id": "16.1",
+        "text": "Uses //go:embed to embed the YAML config file into the binary"
+      },
+      {
+        "id": "16.2",
+        "text": "Passes the embedded bytes to viper.ReadConfig(bytes.NewReader(...))"
+      },
+      {
+        "id": "16.3",
+        "text": "Calls viper.SetConfigType(\"yaml\") before ReadConfig"
+      },
+      {
+        "id": "16.4",
+        "text": "Does NOT suggest calling viper.SetDefault for each key as the primary approach"
+      }
+    ]
+  },
+  {
+    "id": 17,
+    "name": "validate-before-hot-reload-apply",
+    "description": "Tests validate-then-swap pattern to protect against invalid hot-reloaded config",
+    "prompt": "My Go service uses viper.WatchConfig(). A team member accidentally pushed a malformed config and my service began returning zero-values for all settings. How do I protect against invalid config being applied during a hot reload?",
+    "trap": "Without the skill, the model may only suggest logging the error. The correct pattern is: unmarshal into a candidate struct, validate it, and only swap in the new config if validation passes — keep the previous config on failure.",
+    "assertions": [
+      {
+        "id": "17.1",
+        "text": "Unmarshals into a temporary candidate struct before applying"
+      },
+      {
+        "id": "17.2",
+        "text": "Validates the candidate config before overwriting the active config"
+      },
+      {
+        "id": "17.3",
+        "text": "Keeps the previous config unchanged when validation fails"
+      },
+      {
+        "id": "17.4",
+        "text": "Logs a clear error when the reload is rejected"
+      }
+    ]
+  },
+  {
+    "id": 18,
+    "name": "weakly-typed-input-env-bool",
+    "description": "Tests WeaklyTypedInput for env vars that are always strings but map to bool struct fields",
+    "prompt": "My Go service has a Config struct with an Enabled bool field and mapstructure tag. Setting MY_APP_ENABLED=true in the environment and calling viper.Unmarshal leaves cfg.Enabled as false, even though viper.GetBool works. Why?",
+    "trap": "Without the skill, the model may suggest BindEnv or different env var naming. The issue is that env vars are always strings — mapstructure receives the string \"true\" and cannot decode it to bool without WeaklyTypedInput or a decode hook.",
+    "assertions": [
+      {
+        "id": "18.1",
+        "text": "Identifies that env vars are always strings and mapstructure cannot decode \"true\" to bool by default"
+      },
+      {
+        "id": "18.2",
+        "text": "Suggests enabling WeaklyTypedInput in the DecoderConfig or using a StringToBool decode hook"
+      },
+      {
+        "id": "18.3",
+        "text": "Shows viper.Unmarshal(&cfg, func(dc *mapstructure.DecoderConfig) { dc.WeaklyTypedInput = true }) or equivalent"
+      },
+      {
+        "id": "18.4",
+        "text": "Does NOT suggest changing the env var format or using only viper.GetBool as the fix"
+      }
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/binding-and-env.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/binding-and-env.md
new file mode 100644
index 00000000..ce16f0c4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/binding-and-env.md
@@ -0,0 +1,105 @@
+# Viper Env Binding and Flag Binding
+
+## The binding interaction model
+
+Three settings control how viper maps environment variables to keys. They must be set together:
+
+```go
+viper.SetEnvPrefix("MYAPP")                           // adds MYAPP_ prefix
+viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_")) // database.host → MYAPP_DATABASE_HOST
+viper.AutomaticEnv()                                   // activates auto-binding
+```
+
+Call these before any `ReadInConfig` or `viper.Get*` call — typically in a root command's `PersistentPreRunE` or in `init()`.
+
+## AutomaticEnv vs BindEnv
+
+| Method | Behavior |
+| --- | --- |
+| `AutomaticEnv()` | Every key is automatically mapped to its env equivalent (with prefix and replacer applied) |
+| `BindEnv(key, envVars...)` | Only the specified key is bound, to the specified env var name(s) |
+
+Use `AutomaticEnv` for the common case. Use `BindEnv` when you need to bind to an env var with a name that doesn't follow your prefix/replacer convention (e.g., third-party env vars like `GOOGLE_APPLICATION_CREDENTIALS`).
+
+```go
+// Bind a specific non-prefixed env var
+viper.BindEnv("google.credentials", "GOOGLE_APPLICATION_CREDENTIALS")
+```
+
+## SetEnvKeyReplacer in depth
+
+Viper keys use `.` as separator for nested values. Env vars cannot contain dots. The replacer maps between them.
+
+```go
+// Config file:
+// database:
+//   host: localhost
+//   max_conn: 25
+
+// Without replacer:
+viper.SetEnvPrefix("MYAPP")
+viper.AutomaticEnv()
+viper.GetString("database.host")  // looks for MYAPP_DATABASE.HOST — no match
+
+// With replacer:
+viper.SetEnvPrefix("MYAPP")
+viper.SetEnvKeyReplacer(strings.NewReplacer(".", "_"))
+viper.AutomaticEnv()
+viper.GetString("database.host")  // looks for MYAPP_DATABASE_HOST — matches
+```
+
+The replacer operates on the viper key **before** prepending the prefix, so the lookup chain is: `database.host` → replace `.` with `_` → `database_host` → prepend prefix → `MYAPP_DATABASE_HOST`.
+
+## AllowEmptyEnv
+
+By default, viper ignores env vars set to the empty string — the empty string is treated as "not set" and viper continues down the precedence stack. Override this behavior:
+
+```go
+viper.AllowEmptyEnv(true)
+// now MYAPP_PORT="" → viper.GetInt("port") == 0, not the default
+```
+
+## Flag binding
+
+Bind a pflag after defining it:
+
+```go
+func init() {
+    rootCmd.PersistentFlags().Int("port", 8080, "listen port")
+    viper.BindPFlag("port", rootCmd.PersistentFlags().Lookup("port"))
+}
+```
+
+Bind an entire flag set:
+
+```go
+viper.BindPFlags(rootCmd.PersistentFlags())
+```
+
+**Timing rule:** Bind flags in `init()` or in `PersistentPreRunE`. The binding call must happen before `Execute()` parses flags — specifically, before any `viper.Get*` call on a flag-backed key. Binding after `Execute()` causes the flag's `Changed` state to be unknown, so viper may not promote the flag value to the correct precedence layer.
+
+## How pflag binding interacts with precedence
+
+Viper checks `flag.Changed` (whether the user explicitly passed the flag). This is how it distinguishes between "flag default" (low priority) and "flag explicitly set" (high priority):
+
+- `flag.Changed == false` (flag has its default): viper treats the flag as not present and falls through to env/file/default.
+- `flag.Changed == true` (flag was provided on the command line): viper treats the flag value as the highest-priority source.
+
+This means `viper.GetInt("port")` correctly returns the flag value when `--port 9090` is passed, and falls back to env `MYAPP_PORT` or config file `port: 8080` otherwise.
+
+## Debugging binding
+
+Print all resolved values to verify your binding is correct:
+
+```go
+fmt.Println(viper.AllSettings())
+// map[database:map[host:localhost max_conn:25] port:8080]
+```
+
+Check env var resolution:
+
+```go
+os.Setenv("MYAPP_PORT", "9090")
+viper.AutomaticEnv()
+fmt.Println(viper.GetInt("port"))  // 9090
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/sources-and-formats.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/sources-and-formats.md
new file mode 100644
index 00000000..81709eaf
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/sources-and-formats.md
@@ -0,0 +1,119 @@
+# Viper Config Sources and File Formats
+
+## Supported file formats
+
+Viper detects format from file extension. Supported extensions:
+
+| Format     | Extensions      |
+| ---------- | --------------- |
+| YAML       | `.yaml`, `.yml` |
+| TOML       | `.toml`         |
+| JSON       | `.json`         |
+| HCL        | `.hcl`          |
+| INI        | `.ini`          |
+| Properties | `.properties`   |
+| dotenv     | `.env`          |
+
+Force a format when there is no extension:
+
+```go
+viper.SetConfigType("yaml")
+viper.SetConfigFile("/etc/myapp/config")  // no extension — type required
+```
+
+## Config file search
+
+```go
+viper.SetConfigName("config")            // file name without extension
+viper.SetConfigType("yaml")              // required when no extension
+viper.AddConfigPath("$HOME/.myapp")      // search path 1 (highest priority when multiple)
+viper.AddConfigPath("/etc/myapp/")       // search path 2
+viper.AddConfigPath(".")                 // search path 3 (lowest priority)
+
+// viper searches paths in order, stops at the first match
+if err := viper.ReadInConfig(); err != nil {
+    var notFound *viper.ConfigFileNotFoundError
+    if !errors.As(err, &notFound) {
+        return err  // real error (permission denied, malformed YAML, etc.)
+    }
+    // not found — continue with flags/env/defaults
+}
+
+// After reading, this returns the resolved path:
+fmt.Println("Using config:", viper.ConfigFileUsed())
+```
+
+## Merging multiple config files
+
+`MergeInConfig` merges a second config file into the current state. Later values override earlier ones for the same key.
+
+```go
+viper.SetConfigFile("base.yaml")
+viper.ReadInConfig()
+
+viper.SetConfigFile("override.yaml")
+viper.MergeInConfig()  // keys from override.yaml win on collision
+```
+
+Pattern: ship a base config with the binary, let users drop an override in `~/.myapp/override.yaml`.
+
+## Multiple config files via SetConfigFile
+
+For environment-based config loading:
+
+```go
+env := os.Getenv("APP_ENV")
+if env == "" {
+    env = "development"
+}
+viper.SetConfigFile(fmt.Sprintf("config.%s.yaml", env))
+viper.ReadInConfig()
+```
+
+## Remote KV stores (etcd, Consul)
+
+Viper supports remote KV stores via the `viper/remote` sub-package. This keeps remote config behind an opt-in import:
+
+```go
+import _ "github.com/spf13/viper/remote"
+
+// etcd
+viper.AddRemoteProvider("etcd3", "http://127.0.0.1:2379", "/config/myapp.yaml")
+viper.SetConfigType("yaml")
+viper.ReadRemoteConfig()
+
+// Consul
+viper.AddRemoteProvider("consul", "localhost:8500", "myapp/config")
+viper.SetConfigType("json")
+viper.ReadRemoteConfig()
+```
+
+**Caution:** Remote config adds network latency to startup and a runtime dependency. Use it only when you need centralized config across many service instances. For most applications, files + env vars are sufficient.
+
+Watch for remote changes:
+
+```go
+go func() {
+    for {
+        time.Sleep(5 * time.Second)
+        viper.WatchRemoteConfig()
+        // re-read values after watching
+    }
+}()
+```
+
+## Embedding config with go:embed
+
+Load config from embedded assets (for self-contained binaries):
+
+```go
+//go:embed config.yaml
+var defaultConfig []byte
+
+func init() {
+    viper.SetConfigType("yaml")
+    viper.ReadConfig(bytes.NewReader(defaultConfig))
+}
+```
+
+`ReadConfig` accepts any `io.Reader`. This is useful for shipping default config inside the binary, then layering user overrides on top via `MergeInConfig`.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/testing-and-isolation.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/testing-and-isolation.md
new file mode 100644
index 00000000..9c228a96
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/testing-and-isolation.md
@@ -0,0 +1,132 @@
+# Viper Test Isolation
+
+## The global state problem
+
+The top-level `viper.*` functions operate on a global `*viper.Viper` instance shared across all tests in the same process. Tests that call `viper.SetConfigFile`, `viper.Set`, or `viper.ReadInConfig` pollute this global state, causing flaky test ordering.
+
+```go
+// ✗ Bad — sets global state that affects later tests
+func TestPortConfig(t *testing.T) {
+    viper.SetDefault("port", 8080)
+    viper.Set("port", 9090)
+    assert.Equal(t, 9090, viper.GetInt("port"))
+    // global viper now has port=9090 for all subsequent tests
+}
+```
+
+## viper.New() per test (correct approach)
+
+```go
+func TestPortConfig(t *testing.T) {
+    v := viper.New()
+    v.SetDefault("port", 8080)
+    v.Set("port", 9090)
+    assert.Equal(t, 9090, v.GetInt("port"))
+}
+
+func TestDefaultPort(t *testing.T) {
+    v := viper.New()
+    v.SetDefault("port", 8080)
+    assert.Equal(t, 8080, v.GetInt("port"))  // clean — not affected by TestPortConfig
+}
+```
+
+## Injecting viper into your app
+
+For test isolation to work, your application code must accept a `*viper.Viper` instead of calling the global functions directly:
+
+```go
+// ✓ Good — accepts a viper instance
+type Server struct {
+    cfg *viper.Viper
+}
+
+func NewServer(v *viper.Viper) *Server {
+    return &Server{cfg: v}
+}
+
+func (s *Server) Port() int {
+    return s.cfg.GetInt("port")
+}
+
+// In tests:
+func TestServer(t *testing.T) {
+    v := viper.New()
+    v.Set("port", 9090)
+    s := NewServer(v)
+    assert.Equal(t, 9090, s.Port())
+}
+
+// In main:
+func main() {
+    // viper setup...
+    s := NewServer(viper.GetViper())  // pass the global instance in production
+}
+```
+
+## Reading config files in tests
+
+```go
+func TestReadConfig(t *testing.T) {
+    v := viper.New()
+    v.SetConfigFile("testdata/config.yaml")
+    require.NoError(t, v.ReadInConfig())
+    assert.Equal(t, "localhost", v.GetString("host"))
+}
+```
+
+Use `testdata/` for config files. Go test tooling sets the working directory to the package directory, so relative paths work reliably.
+
+## t.Setenv interactions
+
+`t.Setenv` sets an env var for the duration of a test and restores it on cleanup. Combined with `viper.New()` + `AutomaticEnv`, this lets you test env var binding without global pollution:
+
+```go
+func TestEnvBinding(t *testing.T) {
+    t.Setenv("MYAPP_PORT", "9090")
+
+    v := viper.New()
+    v.SetEnvPrefix("MYAPP")
+    v.AutomaticEnv()
+
+    assert.Equal(t, 9090, v.GetInt("port"))
+    // t.Setenv restores original MYAPP_PORT (or unsets it) after this test
+}
+```
+
+## viper.Reset() — use with caution
+
+`viper.Reset()` resets the global viper instance to its zero state. It is rarely the right solution:
+
+- It affects all code running concurrently that also uses the global viper.
+- It does not stop any active `WatchConfig` goroutines.
+- Using it in `TestMain` or `t.Cleanup` makes tests order-dependent.
+
+Prefer `viper.New()` per test. Reserve `Reset()` for tools that call into viper-based libraries and must restore state between runs.
+
+## Snapshot and restore pattern
+
+When you cannot refactor to inject `*viper.Viper` and must use the global:
+
+```go
+func snapshotViper() map[string]interface{} {
+    return viper.AllSettings()
+}
+
+func restoreViper(snapshot map[string]interface{}) {
+    viper.Reset()
+    for k, v := range snapshot {
+        viper.Set(k, v)
+    }
+}
+
+func TestWithGlobalViper(t *testing.T) {
+    snapshot := snapshotViper()
+    t.Cleanup(func() { restoreViper(snapshot) })
+
+    viper.Set("port", 9090)
+    // test code...
+}
+```
+
+This approach is fragile — `AllSettings()` only captures the resolved values, not the binding state (defaults, env bindings, etc.). Prefer injection.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/unmarshal.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/unmarshal.md
new file mode 100644
index 00000000..b9fd0920
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/unmarshal.md
@@ -0,0 +1,140 @@
+# Viper Unmarshal and Struct Mapping
+
+## Basic Unmarshal
+
+```go
+type Config struct {
+    Port     int    `mapstructure:"port"`
+    Host     string `mapstructure:"host"`
+    LogLevel string `mapstructure:"log_level"`
+    Database struct {
+        DSN     string `mapstructure:"dsn"`
+        MaxConn int    `mapstructure:"max_conn"`
+    } `mapstructure:"database"`
+}
+
+var cfg Config
+if err := viper.Unmarshal(&cfg); err != nil {
+    return fmt.Errorf("decoding config: %w", err)
+}
+```
+
+## mapstructure tags
+
+Always use `mapstructure` tags. Without them, mapstructure falls back to case-insensitive field name matching, which works for simple cases but silently fails for:
+
+- Nested structs where the outer key uses an underscore (`max_conn` → `MaxConn`)
+- Unexported fields
+- Fields where the Go name does not match the config key
+
+```go
+// ✓ Good — explicit and immune to rename surprises
+type TLSConfig struct {
+    CertFile string `mapstructure:"cert_file"`
+    KeyFile  string `mapstructure:"key_file"`
+    Enabled  bool   `mapstructure:"enabled"`
+}
+
+// ✗ Fragile — relies on case-folding; breaks when config key uses underscores
+type TLSConfig struct {
+    CertFile string  // viper key "certfile" or "CertFile", not "cert_file"
+    KeyFile  string
+    Enabled  bool
+}
+```
+
+## UnmarshalKey — extracting a sub-tree
+
+```go
+type DatabaseConfig struct {
+    DSN     string `mapstructure:"dsn"`
+    MaxConn int    `mapstructure:"max_conn"`
+}
+
+var dbCfg DatabaseConfig
+if err := viper.UnmarshalKey("database", &dbCfg); err != nil {
+    return fmt.Errorf("decoding database config: %w", err)
+}
+```
+
+Prefer `UnmarshalKey` over `viper.Sub` + `Unmarshal` — fewer nil checks and less boilerplate.
+
+## time.Duration
+
+Viper's `GetDuration` parses duration strings (`"1h30m"`, `"500ms"`) from config files and env vars. When using `Unmarshal`, mapstructure does not know how to decode a duration string into `time.Duration` by default.
+
+Register a decode hook:
+
+```go
+import "github.com/mitchellh/mapstructure"
+
+var cfg Config
+err := viper.Unmarshal(&cfg, func(dc *mapstructure.DecoderConfig) {
+    dc.DecodeHook = mapstructure.ComposeDecodeHookFunc(
+        mapstructure.StringToTimeDurationHookFunc(),
+        mapstructure.StringToSliceHookFunc(","),
+        dc.DecodeHook,
+    )
+})
+```
+
+`StringToTimeDurationHookFunc` handles `"1h30m"` → `time.Duration`. `StringToSliceHookFunc(",")` handles `"a,b,c"` → `[]string{"a", "b", "c"}`.
+
+## net.IP and custom types
+
+```go
+import "github.com/mitchellh/mapstructure"
+
+func stringToIPHookFunc() mapstructure.DecodeHookFunc {
+    return func(f reflect.Type, t reflect.Type, data interface{}) (interface{}, error) {
+        if f.Kind() != reflect.String || t != reflect.TypeOf(net.IP{}) {
+            return data, nil
+        }
+        ip := net.ParseIP(data.(string))
+        if ip == nil {
+            return nil, fmt.Errorf("invalid IP address: %s", data)
+        }
+        return ip, nil
+    }
+}
+```
+
+## Squash for embedded structs
+
+```go
+type BaseConfig struct {
+    LogLevel string `mapstructure:"log_level"`
+    Debug    bool   `mapstructure:"debug"`
+}
+
+type ServerConfig struct {
+    BaseConfig `mapstructure:",squash"`  // merge BaseConfig fields at this level
+    Port       int    `mapstructure:"port"`
+}
+```
+
+Without `,squash`, the base config must be nested under a `baseconfig` key in the config file.
+
+## Remain for unknown keys
+
+```go
+type Config struct {
+    Port     int                    `mapstructure:"port"`
+    Remain   map[string]interface{} `mapstructure:",remain"`
+}
+```
+
+Extra keys from the config file are collected in `Remain` instead of being silently dropped. Useful for forward compatibility.
+
+## Weak decoding
+
+Enable weak type decoding (e.g., string `"true"` → bool `true`) when working with env vars that are always strings:
+
+```go
+var cfg Config
+err := viper.Unmarshal(&cfg, func(dc *mapstructure.DecoderConfig) {
+    dc.WeaklyTypedInput = true
+})
+```
+
+Use with caution — weak decoding can hide bugs where a wrong value type is silently converted.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/watch-and-reload.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/watch-and-reload.md
new file mode 100644
index 00000000..93df06d2
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-spf13-viper/references/watch-and-reload.md
@@ -0,0 +1,103 @@
+# Viper WatchConfig and Hot Reload
+
+## Basic setup
+
+```go
+viper.WatchConfig()
+viper.OnConfigChange(func(e fsnotify.Event) {
+    log.Printf("config changed: %s (op: %s)", e.Name, e.Op)
+    // re-read affected values and apply them
+})
+```
+
+`WatchConfig` starts a background goroutine that watches the config file using fsnotify. Call it after `ReadInConfig`.
+
+## The atomic-rename trap
+
+Most editors (vim, neovim, many CI tools) write config files by creating a new file and then renaming it over the old one. This replaces the inode that fsnotify is watching — the watch may not fire, or may fire with `Op: RENAME` instead of `Op: WRITE`, or may fire twice.
+
+**Test hot reload with direct file writes, not editor saves:**
+
+```go
+// reliable in tests:
+os.WriteFile("config.yaml", newContent, 0644)
+
+// unreliable for testing:
+// opening vim and :w — may trigger RENAME instead of WRITE
+```
+
+In production, this is less of an issue if your config management tool (Kubernetes ConfigMap volume mount, Consul Template, etc.) is aware of inode behavior.
+
+## Race-safe reload pattern
+
+Config reload happens in a background goroutine. Any shared state updated in `OnConfigChange` must be synchronized:
+
+```go
+type Config struct {
+    mu       sync.RWMutex
+    LogLevel string `mapstructure:"log_level"`
+    MaxConn  int    `mapstructure:"max_conn"`
+}
+
+var cfg Config
+
+viper.OnConfigChange(func(e fsnotify.Event) {
+    var newCfg Config
+    if err := viper.Unmarshal(&newCfg); err != nil {
+        log.Printf("error reloading config: %v", err)
+        return  // keep old config on error
+    }
+
+    cfg.mu.Lock()
+    cfg.LogLevel = newCfg.LogLevel
+    cfg.MaxConn = newCfg.MaxConn
+    cfg.mu.Unlock()
+
+    log.Printf("config reloaded: log_level=%s", newCfg.LogLevel)
+})
+```
+
+Reads use `appCfg.mu.RLock()`. Never read directly from viper in hot paths during reload — the window between `OnConfigChange` firing and viper updating its internal state is non-deterministic.
+
+## Debouncing rapid changes
+
+Some filesystems fire multiple events per save. Debounce to avoid reloading multiple times:
+
+```go
+var reloadTimer *time.Timer
+var reloadMu sync.Mutex
+
+viper.OnConfigChange(func(e fsnotify.Event) {
+    reloadMu.Lock()
+    defer reloadMu.Unlock()
+    if reloadTimer != nil {
+        reloadTimer.Stop()
+    }
+    reloadTimer = time.AfterFunc(100*time.Millisecond, func() {
+        applyNewConfig()
+    })
+})
+```
+
+## Validating config before applying
+
+Always validate reloaded config before applying it — an invalid config mid-reload should keep the previous working config:
+
+```go
+viper.OnConfigChange(func(e fsnotify.Event) {
+    var candidate Config
+    if err := viper.Unmarshal(&candidate); err != nil {
+        log.Printf("reload: invalid config, keeping previous: %v", err)
+        return
+    }
+    if err := validate(candidate); err != nil {
+        log.Printf("reload: validation failed, keeping previous: %v", err)
+        return
+    }
+    applyConfig(candidate)
+})
+```
+
+## Stopping the watcher
+
+There is no documented way to stop `WatchConfig` once started. Design your application so that the watcher's lifetime matches the process lifetime. For testing, create a new `viper.New()` instance per test — the watcher is per-instance and is garbage-collected with the instance.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stay-updated/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stay-updated/SKILL.md
new file mode 100644
index 00000000..ec0eff1b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stay-updated/SKILL.md
@@ -0,0 +1,140 @@
+---
+name: golang-stay-updated
+description: "Provides resources to stay updated with Golang news, communities and people to follow. Use when seeking Go learning resources, discovering new libraries, finding community channels, or keeping up with Go language changes and releases."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.3"
+  openclaw:
+    emoji: "📰"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch WebSearch
+---
+
+<!-- markdownlint-disable table-column-style -->
+
+# Stay Updated with Go
+
+A curated guide to keeping your finger on the pulse of the Go ecosystem.
+
+## Official Go Resources
+
+| Resource            | URL                                          |
+| ------------------- | -------------------------------------------- |
+| **go.dev**          | Official Go website with tutorials and tools |
+| **pkg.go.dev**      | Discover Go packages and documentation       |
+| **tour.golang.org** | Interactive Go tutorial                      |
+| **play.golang.org** | Go playground for testing code               |
+| **go.dev/blog**     | Official Go blog                             |
+
+## Newsletters
+
+| Newsletter | Description | Subscribe |
+| --- | --- | --- |
+| **Golang Weekly** | Weekly curated Go content, news, and articles | <https://golangweekly.com/> |
+| **Awesome Go Newsletter** | Updates on new Go libraries and tools | <https://go.libhunt.com/> |
+
+## Reddit & Communities
+
+| Community | Description | URL |
+| --- | --- | --- |
+| r/golang | Main Go subreddit with 300K+ members | <https://www.reddit.com/r/golang> |
+| golang wiki | Official wiki with resources and FAQs | <https://go.dev/wiki/> |
+| gophers.slack.com | Official Go Slack community | <https://invite.slack.golangbridge.org> |
+| Go Forum | Official Go discussion forum | <https://forum.golangbridge.org> |
+| Discuss Go | Official Go team discussion | <https://groups.google.com/g/golang-nuts> |
+
+## Famous Go Developers
+
+Follow these influential Go developers and contributors:
+
+### Core Go Team
+
+| Name | GitHub | Twitter/X | LinkedIn | Bluesky |
+| --- | --- | --- | --- | --- |
+| **Rob Pike** | robpike |  |  |  |
+| **Ken Thompson** | ken |  |  |  |
+| **Russ Cox** | rsc | @\_rsc | <https://www.linkedin.com/in/swtch> | <https://bsky.app/profile/swtch.com> |
+| **Brad Fitzpatrick** | bradfitz | @bradfitz | <https://www.linkedin.com/in/bradfitz/> | <https://bsky.app/profile/bradfitz.com> |
+| **Andrew Gerrand** | adg |  |  |  |
+| **Robert Griesemer** | griesemer |  |  |  |
+| **Dmitry Vyukov** | dvyukov | @dvyukov |  |  |
+
+### Go Tooling & Infrastructure
+
+| Name | GitHub | Twitter/X | LinkedIn | Bluesky |
+| --- | --- | --- | --- | --- |
+| **Sam Boyer** | sdboyer | @sdboyer |  |  |
+| **Daniel Theophanes** | kardianos | @kardianos |  |  |
+| **Matt Butcher** | technosophos |  |  |  |
+| **Jaana Dogan** | rakyll | @rakyll | <https://www.linkedin.com/in/rakyll/> |  |
+
+### Popular Go Authors & Educators
+
+| Name | GitHub | Twitter/X | LinkedIn | Bluesky |
+| --- | --- | --- | --- | --- |
+| **Mat Ryer** | matryer | @matryer | <https://linkedin.com/in/matryer> |  |
+| **Dave Cheney** | davecheney | @davecheney | <https://linkedin.com/in/davecheney> |  |
+| **Katherine Cox-Buday** | kat-co |  | <https://linkedin.com/in/katherinecoxbuday> |  |
+| **Johnny Boursiquot** | jboursiquot | @jboursiquot | <https://linkedin.com/in/jboursiquot> |  |
+| **Michał Łowicki** | mlowicki | @mlowicki | <https://linkedin.com/in/michał-łowicki-a60402b> |  |
+
+### Library & Framework Authors
+
+| Name | GitHub | Twitter/X | LinkedIn | Bluesky |
+| --- | --- | --- | --- | --- |
+| **Steve Francia** | spf13 | @spf13 | <https://linkedin.com/in/spf13> |  |
+| **Samuel Berthe** | samber | @samuelberthe | <https://linkedin.com/in/samuelberthe> | <https://bsky.app/profile/samber.bsky.social> |
+| **Mitchell Hashimoto** | mitchellh | @mitchellh | <https://linkedin.com/in/mitchellh> | <https://bsky.app/profile/mitchellh.com> |
+| **Matt Holt** | mholt | @mholt6 |  |  |
+| **Tomás Senart** | tsenart | @tsenart | <https://www.linkedin.com/in/tsenart/> |  |
+| **Björn Rabenstein** | beorn7 |  |  |  |
+
+### Conference Speakers & Community Leaders
+
+| Name | GitHub | Twitter/X | LinkedIn | Bluesky |
+| --- | --- | --- | --- | --- |
+| **Carlisia Campos** | carlisia | @carlisia | <https://linkedin.com/in/carlisia> |  |
+| **Erik St. Martin** | erikstmartin | @erikstmartin |  |  |
+| **Brian Ketelsen** | bketelsen |  |  | @brian.dev |
+
+## Must-Follow Blogs
+
+| Blog            | Author       | URL                                  |
+| --------------- | ------------ | ------------------------------------ |
+| The Go Blog     | Go Team      | <https://go.dev/blog>                |
+| Rob Pike's Blog | Rob Pike     | <https://commandcenter.blogspot.com> |
+| Dave Cheney     | Dave Cheney  | <https://dave.cheney.net>            |
+| Ardan Labs Blog | Bill Kennedy | <https://www.ardanlabs.com/blog>     |
+
+## YouTube Channels
+
+| Channel | Content | URL |
+| --- | --- | --- |
+| Go | Official Go team | <https://www.youtube.com/@golang> |
+| Gopher Academy | Talks & tutorials | <https://www.youtube.com/@GopherAcademy> |
+| GopherCon Europe | European conference talks | <https://www.youtube.com/@GopherConEurope> |
+| GopherCon UK | UK conference talks | <https://www.youtube.com/@GopherConUK> |
+| Golang Singapore | Singapore meetup & conf talks | <https://www.youtube.com/@golangSG> |
+| Ardan Labs | Go training & tips | <https://www.youtube.com/@ArdanLabs> |
+| Applied Go | Go tutorials | <https://youtube.com/appliedgocode> |
+| Learn Go Programming | Beginner tutorials | <https://youtube.com/learn_goprogramming> |
+
+## Quick Tips for Staying Updated
+
+1. **Subscribe to 1-2 newsletters** - Don't overload yourself
+2. **Follow 10-20 key people** on X/Bluesky who post regularly
+3. **Check Go.dev/blog weekly** for official announcements
+4. **Join Go Slack** for real-time discussions
+5. **Bookmark pkg.go.dev** to discover new libraries
+6. **Attend a GopherCon** (virtual or in-person) yearly
+
+---
+
+_Note: This guide is regularly updated. Suggest additions via GitHub issues._
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stay-updated/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stay-updated/evals/evals.json
new file mode 100644
index 00000000..ab723125
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stay-updated/evals/evals.json
@@ -0,0 +1,142 @@
+[
+  {
+    "id": 1,
+    "name": "go-newsletters-recommendation",
+    "description": "Tests whether the model recommends specific Go newsletters for staying updated",
+    "prompt": "I want to stay updated with Go ecosystem news without spending hours browsing. What newsletters should I subscribe to?",
+    "trap": "Without the skill, the model may give generic advice like 'follow blogs' or only mention the official blog, missing curated newsletters",
+    "assertions": [
+      {"id": "1.1", "text": "Recommends Golang Weekly (golangweekly.com)"},
+      {"id": "1.2", "text": "Recommends Awesome Go Newsletter (go.libhunt.com)"},
+      {"id": "1.3", "text": "Advises subscribing to 1-2 newsletters to avoid overload"},
+      {"id": "1.4", "text": "Mentions these provide curated content, articles, and library updates"},
+      {"id": "1.5", "text": "Does not recommend more than 3-4 newsletters (quality over quantity)"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "go-community-channels",
+    "description": "Tests knowledge of specific Go community channels beyond Reddit",
+    "prompt": "I'm a Go developer looking to connect with other Gophers. Where can I find active Go communities for discussion and help?",
+    "trap": "Without the skill, the model may only mention r/golang and Stack Overflow, missing Slack, forums, and golang-nuts",
+    "assertions": [
+      {"id": "2.1", "text": "Mentions r/golang subreddit"},
+      {"id": "2.2", "text": "Mentions gophers.slack.com (official Go Slack)"},
+      {"id": "2.3", "text": "Mentions the Go Forum (forum.golangbridge.org)"},
+      {"id": "2.4", "text": "Mentions golang-nuts Google Group (groups.google.com/g/golang-nuts)"},
+      {"id": "2.5", "text": "Mentions the official Go wiki (go.dev/wiki)"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "go-youtube-channels",
+    "description": "Tests knowledge of specific Go YouTube channels for learning",
+    "prompt": "I prefer learning Go through video content. What YouTube channels should I follow for Go talks and tutorials?",
+    "trap": "Without the skill, the model may only suggest generic programming channels or just GopherCon",
+    "assertions": [
+      {"id": "3.1", "text": "Recommends the official Go YouTube channel (@golang)"},
+      {"id": "3.2", "text": "Recommends Gopher Academy"},
+      {"id": "3.3", "text": "Recommends GopherCon Europe or GopherCon UK channels"},
+      {"id": "3.4", "text": "Recommends Ardan Labs channel"},
+      {"id": "3.5", "text": "Lists at least 3 distinct Go-specific YouTube channels"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "famous-go-core-team-members",
+    "description": "Tests knowledge of Go core team members to follow",
+    "prompt": "Who are the key people behind the Go programming language that I should follow for insights on language direction?",
+    "trap": "Without the skill, the model may only name Rob Pike and Ken Thompson, missing active contributors",
+    "assertions": [
+      {"id": "4.1", "text": "Mentions Rob Pike as a co-creator"},
+      {"id": "4.2", "text": "Mentions Russ Cox and his role in Go"},
+      {"id": "4.3", "text": "Mentions Brad Fitzpatrick"},
+      {"id": "4.4", "text": "Mentions Dave Cheney as an influential Go community member"},
+      {"id": "4.5", "text": "Mentions Robert Griesemer as a co-creator"},
+      {"id": "4.6", "text": "Provides social media handles or GitHub usernames for at least 3 people"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "go-library-authors-to-follow",
+    "description": "Tests knowledge of influential Go library/framework authors",
+    "prompt": "I want to follow Go developers who create popular libraries and frameworks. Who should I follow on GitHub or X?",
+    "trap": "Without the skill, the model may list only a few well-known names, missing the breadth of the ecosystem",
+    "assertions": [
+      {"id": "5.1", "text": "Mentions Steve Francia (spf13) — Cobra, Viper, Hugo"},
+      {"id": "5.2", "text": "Mentions Mitchell Hashimoto (mitchellh) — Terraform, Consul, Vault"},
+      {"id": "5.3", "text": "Mentions Samuel Berthe (samber) — lo, do, oops"},
+      {"id": "5.4", "text": "Mentions Matt Holt (mholt) — Caddy"},
+      {"id": "5.5", "text": "Provides GitHub usernames or X handles for the recommended people"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "official-go-resources",
+    "description": "Tests knowledge of official Go resources and tools",
+    "prompt": "I'm new to Go. What are the essential official resources I should bookmark?",
+    "trap": "Without the skill, the model may only mention go.dev and the tour, missing pkg.go.dev and the playground",
+    "assertions": [
+      {"id": "6.1", "text": "Mentions go.dev as the official Go website"},
+      {"id": "6.2", "text": "Mentions pkg.go.dev for package discovery and documentation"},
+      {"id": "6.3", "text": "Mentions tour.golang.org (Go Tour) for interactive learning"},
+      {"id": "6.4", "text": "Mentions play.golang.org (Go Playground) for testing code"},
+      {"id": "6.5", "text": "Mentions go.dev/blog (official Go blog) for announcements"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "go-blogs-to-follow",
+    "description": "Tests knowledge of must-follow Go blogs beyond the official blog",
+    "prompt": "What Go-focused blogs should I read regularly for in-depth Go articles?",
+    "trap": "Without the skill, the model may only mention the official blog or random Medium posts",
+    "assertions": [
+      {"id": "7.1", "text": "Mentions The Go Blog (go.dev/blog)"},
+      {"id": "7.2", "text": "Mentions Dave Cheney's blog (dave.cheney.net)"},
+      {"id": "7.3", "text": "Mentions Ardan Labs Blog (ardanlabs.com/blog)"},
+      {"id": "7.4", "text": "Lists at least 3 specific blog names with URLs or authors"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "staying-updated-strategy",
+    "description": "Tests the curated strategy for staying updated without information overload",
+    "prompt": "I'm overwhelmed by the amount of Go content out there. Give me a practical plan for staying current with Go without spending all day reading.",
+    "trap": "Without the skill, the model may give generic advice without specific numbers or concrete recommendations",
+    "assertions": [
+      {"id": "8.1", "text": "Recommends subscribing to 1-2 newsletters specifically (not more)"},
+      {"id": "8.2", "text": "Recommends following 10-20 key people on social media"},
+      {"id": "8.3", "text": "Recommends checking go.dev/blog weekly for official announcements"},
+      {"id": "8.4", "text": "Recommends joining Go Slack for real-time discussions"},
+      {"id": "8.5", "text": "Recommends attending GopherCon (virtual or in-person) yearly"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "go-conference-speakers",
+    "description": "Tests knowledge of Go conference speakers and community leaders",
+    "prompt": "Who are notable Go conference speakers I should watch talks from?",
+    "trap": "Without the skill, the model may only name core team members, missing dedicated community speakers",
+    "assertions": [
+      {"id": "9.1", "text": "Mentions at least one of: Carlisia Campos, Erik St. Martin, Brian Ketelsen"},
+      {"id": "9.2", "text": "Mentions Mat Ryer or Johnny Boursiquot as Go educators/speakers"},
+      {"id": "9.3", "text": "Mentions GopherCon as the conference to follow"},
+      {"id": "9.4", "text": "Provides specific names with their social handles or GitHub profiles"},
+      {"id": "9.5", "text": "Lists at least 4 distinct speakers/community leaders"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "go-performance-experts",
+    "description": "Tests knowledge of Go performance and optimization experts to follow",
+    "prompt": "I'm interested in Go performance optimization. Who are the experts I should follow for deep Go performance content?",
+    "trap": "Without the skill, the model may suggest generic Go developers or only Dave Cheney",
+    "assertions": [
+      {"id": "10.1", "text": "Mentions Dmitry Vyukov as a Go performance expert"},
+      {"id": "10.2", "text": "Mentions Dave Cheney for performance-related Go content"},
+      {"id": "10.3", "text": "Provides GitHub usernames (e.g., dvyukov, davecheney)"},
+      {"id": "10.4", "text": "Mentions Bill Kennedy / Ardan Labs for Go performance training"},
+      {"id": "10.5", "text": "Mentions Jaana Dogan (rakyll) for Go internals/performance"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/SKILL.md
new file mode 100644
index 00000000..01ef8458
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/SKILL.md
@@ -0,0 +1,195 @@
+---
+name: golang-stretchr-testify
+description: "Comprehensive guide to stretchr/testify for Golang testing. Covers assert, require, mock, and suite packages in depth. Use when writing tests with testify, creating mocks, setting up test suites, or choosing between assert and require. Covers testify assertions, mock expectations, argument matchers, call verification, suite lifecycle, and advanced patterns like Eventually, JSONEq, and custom matchers. Apply when the codebase imports github.com/stretchr/testify."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.0"
+  openclaw:
+    emoji: "✅"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - gotests
+    install:
+      - kind: go
+        package: github.com/cweill/gotests/...@latest
+        bins: [gotests]
+    skill-library-version: "1.11.1"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs Bash(gotests:*) AskUserQuestion
+---
+
+**Persona:** You are a Go engineer who treats tests as executable specifications. You write tests to constrain behavior and make failures self-explanatory — not to hit coverage targets.
+
+**Modes:**
+
+- **Write mode** — adding new tests or mocks to a codebase.
+- **Review mode** — auditing existing test code for testify misuse.
+
+# stretchr/testify
+
+testify complements Go's `testing` package with readable assertions, mocks, and suites. It does not replace `testing` — always use `*testing.T` as the entry point.
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+## assert vs require
+
+Both offer identical assertions. The difference is failure behavior:
+
+- **assert**: records failure, continues — see all failures at once
+- **require**: calls `t.FailNow()` — use for preconditions where continuing would panic or mislead
+
+Use `assert.New(t)` / `require.New(t)` for readability. Name them `is` and `must`:
+
+```go
+func TestParseConfig(t *testing.T) {
+    is := assert.New(t)
+    must := require.New(t)
+
+    cfg, err := ParseConfig("testdata/valid.yaml")
+    must.NoError(err)    // stop if parsing fails — cfg would be nil
+    must.NotNil(cfg)
+
+    is.Equal("production", cfg.Environment)
+    is.Equal(8080, cfg.Port)
+    is.True(cfg.TLS.Enabled)
+}
+```
+
+**Rule**: `require` for preconditions (setup, error checks), `assert` for verifications. Never mix randomly.
+
+## Core Assertions
+
+```go
+is := assert.New(t)
+
+// Equality
+is.Equal(expected, actual)              // DeepEqual + exact type
+is.NotEqual(unexpected, actual)
+is.EqualValues(expected, actual)        // converts to common type first
+is.EqualExportedValues(expected, actual)
+
+// Nil / Bool / Emptiness
+is.Nil(obj)                  is.NotNil(obj)
+is.True(cond)                is.False(cond)
+is.Empty(collection)         is.NotEmpty(collection)
+is.Len(collection, n)
+
+// Contains (strings, slices, map keys)
+is.Contains("hello world", "world")
+is.Contains([]int{1, 2, 3}, 2)
+is.Contains(map[string]int{"a": 1}, "a")
+
+// Comparison
+is.Greater(actual, threshold)     is.Less(actual, ceiling)
+is.Positive(val)                  is.Negative(val)
+is.Zero(val)
+
+// Errors
+is.Error(err)                     is.NoError(err)
+is.ErrorIs(err, ErrNotFound)      // walks error chain
+is.ErrorAs(err, &target)
+is.ErrorContains(err, "not found")
+
+// Type
+is.IsType(&User{}, obj)
+is.Implements((*io.Reader)(nil), obj)
+```
+
+**Argument order**: always `(expected, actual)` — swapping produces confusing diff output.
+
+## Advanced Assertions
+
+```go
+is.ElementsMatch([]string{"b", "a", "c"}, result)             // unordered comparison
+is.InDelta(3.14, computedPi, 0.01)                            // float tolerance
+is.JSONEq(`{"name":"alice"}`, `{"name": "alice"}`)             // ignores whitespace/key order
+is.WithinDuration(expected, actual, 5*time.Second)
+is.Regexp(`^user-[a-f0-9]+$`, userID)
+
+// Async polling
+is.Eventually(func() bool {
+    status, _ := client.GetJobStatus(jobID)
+    return status == "completed"
+}, 5*time.Second, 100*time.Millisecond)
+
+// Async polling with rich assertions
+is.EventuallyWithT(func(c *assert.CollectT) {
+    resp, err := client.GetOrder(orderID)
+    assert.NoError(c, err)
+    assert.Equal(c, "shipped", resp.Status)
+}, 10*time.Second, 500*time.Millisecond)
+```
+
+## testify/mock
+
+Mock interfaces to isolate the unit under test. Embed `mock.Mock`, implement methods with `m.Called()`, always verify with `AssertExpectations(t)`.
+
+Key matchers: `mock.Anything`, `mock.AnythingOfType("T")`, `mock.MatchedBy(func)`. Call modifiers: `.Once()`, `.Times(n)`, `.Maybe()`, `.Run(func)`.
+
+For defining mocks, argument matchers, call modifiers, return sequences, and verification, see [Mock reference](./references/mock.md).
+
+## testify/suite
+
+Suites group related tests with shared setup/teardown.
+
+### Lifecycle
+
+```
+SetupSuite()    → once before all tests
+  SetupTest()   → before each test
+    TestXxx()
+  TearDownTest() → after each test
+TearDownSuite() → once after all tests
+```
+
+### Example
+
+```go
+type TokenServiceSuite struct {
+    suite.Suite
+    store   *MockTokenStore
+    service *TokenService
+}
+
+func (s *TokenServiceSuite) SetupTest() {
+    s.store = new(MockTokenStore)
+    s.service = NewTokenService(s.store)
+}
+
+func (s *TokenServiceSuite) TestGenerate_ReturnsValidToken() {
+    s.store.On("Save", mock.Anything, mock.Anything).Return(nil)
+    token, err := s.service.Generate("user-42")
+    s.NoError(err)
+    s.NotEmpty(token)
+    s.store.AssertExpectations(s.T())
+}
+
+// Required launcher
+func TestTokenServiceSuite(t *testing.T) {
+    suite.Run(t, new(TokenServiceSuite))
+}
+```
+
+Suite methods like `s.Equal()` behave like `assert`. For require: `s.Require().NotNil(obj)`.
+
+## Common Mistakes
+
+- **Forgetting `AssertExpectations(t)`** — mock expectations silently pass without verification
+- **`is.Equal(ErrNotFound, err)`** — fails on wrapped errors. Use `is.ErrorIs` to walk the chain
+- **Swapped argument order** — testify assumes `(expected, actual)`. Swapping produces backwards diffs
+- **`assert` for guards** — test continues after failure and panics on nil dereference. Use `require`
+- **Missing `suite.Run()`** — without the launcher function, zero tests execute silently
+- **Comparing pointers** — `is.Equal(ptr1, ptr2)` compares addresses. Dereference or use `EqualExportedValues`
+
+## Linters
+
+Use `testifylint` to catch wrong argument order, assert/require misuse, and more. See `samber/cc-skills-golang@golang-lint` skill.
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-testing` skill for general test patterns, table-driven tests, and CI
+- → See `samber/cc-skills-golang@golang-lint` skill for testifylint configuration
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/evals/evals.json
new file mode 100644
index 00000000..b7784651
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/evals/evals.json
@@ -0,0 +1,148 @@
+[
+  {
+    "id": 1,
+    "name": "assert-vs-require-precondition",
+    "description": "Tests whether the model uses require for preconditions and assert for verifications, not mixing them randomly",
+    "prompt": "Write a Go test using testify that parses a JSON config file, checks it has no error, verifies the config is not nil, then checks that config.Port equals 8080, config.Host equals 'localhost', and config.Debug is false.",
+    "trap": "Model may use assert for the error check and nil check (preconditions), which would cause a nil pointer panic on subsequent assertions if parsing fails",
+    "assertions": [
+      {"id": "1.1", "text": "Uses require (not assert) for the NoError check on parsing"},
+      {"id": "1.2", "text": "Uses require (not assert) for the NotNil check on config"},
+      {"id": "1.3", "text": "Uses assert for the subsequent value checks (Port, Host, Debug)"},
+      {"id": "1.4", "text": "Does NOT use require for all assertions indiscriminately"},
+      {"id": "1.5", "text": "Argument order is (expected, actual) not (actual, expected) for Equal calls"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "assert-new-naming-convention",
+    "description": "Tests the skill's specific naming convention: 'is' for assert.New(t) and 'must' for require.New(t)",
+    "prompt": "I'm writing Go tests with testify and I find the repeated 't' parameter verbose. How can I make my assertions more readable? Show me an example with both assert and require.",
+    "trap": "Model may use generic variable names like 'a' and 'r', or 'assertions' and 'requirements' instead of the skill's recommended 'is' and 'must' convention",
+    "assertions": [
+      {"id": "2.1", "text": "Uses assert.New(t) to create a reusable assertion object"},
+      {"id": "2.2", "text": "Uses require.New(t) to create a reusable require object"},
+      {"id": "2.3", "text": "Names the assert.New(t) variable 'is'"},
+      {"id": "2.4", "text": "Names the require.New(t) variable 'must'"},
+      {"id": "2.5", "text": "Shows the 'is' and 'must' variables being used for different purposes (preconditions vs verifications)"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "error-chain-assertion",
+    "description": "Tests knowledge that is.Equal(ErrNotFound, err) fails on wrapped errors and ErrorIs should be used instead",
+    "prompt": "I have a Go function that returns wrapped errors using fmt.Errorf with %w. Write a test that checks whether the returned error is ErrNotFound. The function signature is: func FindUser(id string) (*User, error)",
+    "trap": "Model may use assert.Equal(ErrNotFound, err) which fails on wrapped errors instead of assert.ErrorIs",
+    "assertions": [
+      {"id": "3.1", "text": "Uses ErrorIs (not Equal) to check the error against ErrNotFound"},
+      {"id": "3.2", "text": "Does NOT use assert.Equal or is.Equal to compare errors directly"},
+      {"id": "3.3", "text": "Uses require for the initial error existence check if subsequent assertions depend on it"},
+      {"id": "3.4", "text": "Argument order for ErrorIs is (err, target) not (target, err)"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "mock-assert-expectations",
+    "description": "Tests whether AssertExpectations is called — without it, mock expectations silently pass",
+    "prompt": "Create a Go test using testify/mock for a NotificationService that calls a Sender.Send method. The test should verify that Send is called exactly once with the right email address.",
+    "trap": "Model may set up On().Return() expectations but forget to call AssertExpectations(t), making the test pass even if Send is never called",
+    "assertions": [
+      {"id": "4.1", "text": "Mock embeds mock.Mock"},
+      {"id": "4.2", "text": "Mock method uses m.Called() to forward arguments"},
+      {"id": "4.3", "text": "Test calls m.AssertExpectations(t) to verify all expectations were met"},
+      {"id": "4.4", "text": "Uses .Once() or equivalent call modifier to enforce exactly one call"},
+      {"id": "4.5", "text": "Uses mock.Anything for arguments that don't need specific matching (e.g., context)"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "mock-matched-by-predicate",
+    "description": "Tests knowledge of mock.MatchedBy for custom argument matching beyond exact equality",
+    "prompt": "I have a mock for a Logger interface with method Log(ctx context.Context, entry LogEntry). I need to verify that the LogEntry has Level='error' and Message contains 'timeout', but I don't care about the exact timestamp. How do I write the mock expectation?",
+    "trap": "Model may try to match the entire LogEntry struct exactly (which fails due to timestamp) instead of using mock.MatchedBy with a predicate function",
+    "assertions": [
+      {"id": "5.1", "text": "Uses mock.MatchedBy with a predicate function for the LogEntry argument"},
+      {"id": "5.2", "text": "The predicate checks Level == 'error'"},
+      {"id": "5.3", "text": "The predicate checks that Message contains 'timeout' (using strings.Contains or similar)"},
+      {"id": "5.4", "text": "Uses mock.Anything for the context argument"},
+      {"id": "5.5", "text": "Calls AssertExpectations at the end"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "mock-retry-different-returns",
+    "description": "Tests knowledge of chaining .Once() calls to return different values per call for retry testing",
+    "prompt": "I need to test that my Go HTTP client retries on failure. The client calls Fetcher.Fetch(url string) ([]byte, error). First call should return a timeout error, second call should succeed with some data. How do I set up this mock?",
+    "trap": "Model may not know how to return different values per call and instead use a single Return() that applies to all calls",
+    "assertions": [
+      {"id": "6.1", "text": "Sets up first On().Return() with an error and .Once()"},
+      {"id": "6.2", "text": "Sets up second On().Return() with success data and .Once()"},
+      {"id": "6.3", "text": "The two expectations are on the same method with the same arguments"},
+      {"id": "6.4", "text": "Calls AssertExpectations to verify both calls happened"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "suite-lifecycle-and-launcher",
+    "description": "Tests that suite requires a launcher function (TestXxxSuite) and understands the lifecycle order",
+    "prompt": "Convert these flat Go tests into a testify suite. The tests share a database connection setup and cleanup. There are 3 test functions that all need a fresh mock store before each test.\n\n```go\nfunc TestCreateUser(t *testing.T) { ... }\nfunc TestDeleteUser(t *testing.T) { ... }\nfunc TestListUsers(t *testing.T) { ... }\n```",
+    "trap": "Model may create the suite struct and test methods but forget the launcher function (func TestXxxSuite(t *testing.T) { suite.Run(t, new(Suite)) }), causing zero tests to run",
+    "assertions": [
+      {"id": "7.1", "text": "Creates a suite struct embedding suite.Suite"},
+      {"id": "7.2", "text": "Uses SetupTest (not SetupSuite) for per-test mock store initialization"},
+      {"id": "7.3", "text": "Includes a launcher function: func TestXxxSuite(t *testing.T) with suite.Run()"},
+      {"id": "7.4", "text": "Test methods are named TestXxx (starting with Test) on the suite receiver"},
+      {"id": "7.5", "text": "Uses SetupSuite or TearDownSuite for the shared database connection (one-time setup)"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "suite-require-syntax",
+    "description": "Tests that suite methods use s.Require().NotNil() syntax for require behavior, since s.NotNil() is assert-style",
+    "prompt": "In my testify suite test method, I need to check that a database connection is not nil before proceeding. If it's nil, the test should stop immediately. How do I do a require-style assertion inside a suite?",
+    "trap": "Model may use s.NotNil() thinking it acts like require, but suite methods default to assert behavior. Must use s.Require().NotNil() for fail-fast",
+    "assertions": [
+      {"id": "8.1", "text": "Uses s.Require().NotNil() (not just s.NotNil()) for fail-fast behavior"},
+      {"id": "8.2", "text": "Explains that s.NotNil() and similar suite methods behave like assert (continue on failure)"},
+      {"id": "8.3", "text": "Shows that s.Require() returns a require-style assertion object"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "pointer-comparison-trap",
+    "description": "Tests awareness that is.Equal(ptr1, ptr2) compares addresses, not values",
+    "prompt": "I have two *User pointers pointing to different structs with the same field values. My test `assert.Equal(t, user1, user2)` is failing. Both users have Name='Alice' and Age=30. What's wrong?",
+    "trap": "Model may suggest various debugging approaches without identifying the core issue: Equal on pointers compares addresses",
+    "assertions": [
+      {"id": "9.1", "text": "Identifies that assert.Equal on pointers compares memory addresses, not struct values"},
+      {"id": "9.2", "text": "Recommends dereferencing the pointers (e.g., assert.Equal(t, *user1, *user2)) or using EqualExportedValues"},
+      {"id": "9.3", "text": "Mentions EqualExportedValues as an alternative for comparing only exported fields"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "eventually-with-rich-assertions",
+    "description": "Tests knowledge of EventuallyWithT for async polling with multiple rich assertions (not just bool)",
+    "prompt": "I need to test an async job processor. After submitting a job, I need to poll until the job status is 'completed' AND the result count is greater than 0. The polling should timeout after 10 seconds. How do I write this test with testify?",
+    "trap": "Model may use Eventually with a simple bool function, which only checks one condition and loses assertion error messages. EventuallyWithT allows multiple rich assertions.",
+    "assertions": [
+      {"id": "10.1", "text": "Uses EventuallyWithT (not just Eventually) for rich assertions"},
+      {"id": "10.2", "text": "The callback receives *assert.CollectT (or similar collect parameter)"},
+      {"id": "10.3", "text": "Multiple assertions are made inside the callback (status check AND result count check)"},
+      {"id": "10.4", "text": "Uses assert.NoError/assert.Equal with the CollectT parameter inside the callback, not with t"},
+      {"id": "10.5", "text": "Specifies timeout (10s) and polling interval as separate parameters"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "testifylint-recommendation",
+    "description": "testifylint catches testify-specific mistakes that generic linters miss; model should recommend it over manual code review for testify patterns",
+    "prompt": "Our team's test code review keeps catching the same testify mistakes:\n\n1. `assert.Equal(t, err, ErrNotFound)` instead of `assert.ErrorIs(t, err, ErrNotFound)`\n2. `assert.Equal(t, got, want)` where expected/actual are swapped\n3. Using `assert.NoError(t, err)` instead of `require.NoError(t, err)` before dereferencing a pointer\n4. `assert.Equal(t, true, someCondition)` instead of `assert.True(t, someCondition)`\n\nOur lead says: 'These are all discipline issues — we should just review more carefully and add examples to our style guide.' Is there a better automated solution?",
+    "trap": "The lead's position (careful review + style guide) sounds reasonable for a small team. The model should recognize that testifylint catches all four of these patterns automatically, making manual review for them unnecessary. Without the skill, the model may agree with the lead or only suggest generic linters like staticcheck.",
+    "assertions": [
+      {"id": "11.1", "text": "Recommends testifylint specifically — explains that it is designed to catch exactly the patterns described (not just generic Go linters like staticcheck or golangci-lint defaults)"},
+      {"id": "11.2", "text": "Pushes back on the lead's 'review more carefully' approach — automated linting is more reliable than manual discipline for mechanical patterns"},
+      {"id": "11.3", "text": "Confirms testifylint catches at least two of the four described patterns: wrong argument order (expected/actual swap) and assert/require misuse (using assert before pointer dereference)"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/references/mock.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/references/mock.md
new file mode 100644
index 00000000..ecbe99f6
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-stretchr-testify/references/mock.md
@@ -0,0 +1,99 @@
+# testify/mock — Reference
+
+Mock interfaces to isolate the unit under test. Embed `mock.Mock`, implement methods with `m.Called()`, and always verify with `AssertExpectations(t)`.
+
+## Quick example
+
+```go
+type MockSender struct { mock.Mock }
+
+func (m *MockSender) Send(ctx context.Context, to string, msg Message) error {
+    return m.Called(ctx, to, msg).Error(0)
+}
+
+func TestOrderService_Place(t *testing.T) {
+    is := assert.New(t)
+    m := new(MockSender)
+    m.On("Send", mock.Anything, "buyer@example.com", mock.AnythingOfType("Message")).Return(nil)
+
+    err := NewOrderService(m).Place(context.Background(), order)
+
+    is.NoError(err)
+    m.AssertExpectations(t)
+}
+```
+
+## Defining a mock
+
+```go
+type NotificationSender interface {
+    Send(ctx context.Context, to string, msg Message) error
+    BatchSend(ctx context.Context, recipients []string, msg Message) (int, error)
+}
+
+type MockNotificationSender struct { mock.Mock }
+
+func (m *MockNotificationSender) Send(ctx context.Context, to string, msg Message) error {
+    return m.Called(ctx, to, msg).Error(0)
+}
+
+func (m *MockNotificationSender) BatchSend(ctx context.Context, recipients []string, msg Message) (int, error) {
+    args := m.Called(ctx, recipients, msg)
+    return args.Int(0), args.Error(1)
+}
+```
+
+## Argument matchers
+
+```go
+// mock.Anything — matches any value
+m.On("Send", mock.Anything, mock.Anything, mock.Anything).Return(nil)
+
+// mock.AnythingOfType — matches by type name
+m.On("Send", mock.Anything, mock.AnythingOfType("string"), mock.Anything).Return(nil)
+
+// mock.MatchedBy — custom predicate
+m.On("Send", mock.Anything, mock.MatchedBy(func(to string) bool {
+    return strings.HasSuffix(to, "@example.com")
+}), mock.Anything).Return(nil)
+```
+
+## Call modifiers
+
+```go
+m.On("Send", mock.Anything, mock.Anything, mock.Anything).Return(nil).Once()     // exactly 1 call
+m.On("Send", mock.Anything, mock.Anything, mock.Anything).Return(nil).Times(3)   // exactly 3 calls
+m.On("Send", mock.Anything, mock.Anything, mock.Anything).Return(nil).Maybe()    // optional
+
+// Side effects
+m.On("Send", mock.Anything, mock.Anything, mock.Anything).
+    Run(func(args mock.Arguments) {
+        msg := args.Get(2).(Message)
+        t.Logf("mock received: %s", msg.Subject)
+    }).Return(nil)
+```
+
+## Different returns per call
+
+```go
+// First call returns error, second succeeds (retry testing)
+m.On("Send", mock.Anything, mock.Anything, mock.Anything).Return(errors.New("timeout")).Once()
+m.On("Send", mock.Anything, mock.Anything, mock.Anything).Return(nil).Once()
+```
+
+## Removing expectations
+
+```go
+call := m.On("Send", mock.Anything, mock.Anything, mock.Anything).Return(nil)
+call.Unset()
+m.On("Send", mock.Anything, mock.Anything, mock.Anything).Return(errors.New("fail"))
+```
+
+## Verification
+
+```go
+m.AssertExpectations(t)                                                          // verify all expectations
+m.AssertCalled(t, "Send", mock.Anything, "buyer@example.com", mock.Anything)     // specific call made
+m.AssertNotCalled(t, "BatchSend", mock.Anything, mock.Anything, mock.Anything)   // specific call NOT made
+m.AssertNumberOfCalls(t, "Send", 2)                                              // exact call count
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-structs-interfaces/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-structs-interfaces/SKILL.md
new file mode 100644
index 00000000..09f36b4d
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-structs-interfaces/SKILL.md
@@ -0,0 +1,383 @@
+---
+name: golang-structs-interfaces
+description: 'Golang struct and interface design patterns — composition, embedding, type assertions, type switches, interface segregation, dependency injection via interfaces, struct field tags, and pointer vs value receivers. Use this skill when designing Go types, defining or implementing interfaces, embedding structs or interfaces, writing type assertions or type switches, adding struct field tags for JSON/YAML/DB serialization, or choosing between pointer and value receivers. Also use when the user asks about "accept interfaces, return structs", compile-time interface checks, or composing small interfaces into larger ones.'
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.3"
+  openclaw:
+    emoji: "🧩"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion
+---
+
+**Persona:** You are a Go type system designer. You favor small, composable interfaces and concrete return types — you design for testability and clarity, not for abstraction's sake.
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-structs-interfaces` skill takes precedence.
+
+# Go Structs & Interfaces
+
+## Interface Design Principles
+
+### Keep Interfaces Small
+
+> "The bigger the interface, the weaker the abstraction." — Go Proverbs
+
+Interfaces SHOULD have 1-3 methods. Small interfaces are easier to implement, mock, and compose. If you need a larger contract, compose it from small interfaces:
+
+→ See `samber/cc-skills-golang@golang-naming` skill for interface naming conventions (method + "-er" suffix, canonical names)
+
+```go
+type Reader interface {
+    Read(p []byte) (n int, err error)
+}
+
+type Writer interface {
+    Write(p []byte) (n int, err error)
+}
+
+// Composed from small interfaces
+type ReadWriter interface {
+    Reader
+    Writer
+}
+```
+
+Compose larger interfaces from smaller ones:
+
+```go
+type ReadWriteCloser interface {
+    io.Reader
+    io.Writer
+    io.Closer
+}
+```
+
+### Define Interfaces Where They're Consumed
+
+Interfaces Belong to Consumers.
+
+Interfaces MUST be defined where consumed, not where implemented. This keeps the consumer in control of the contract and avoids importing a package just for its interface.
+
+```go
+// package notification — defines only what it needs
+type Sender interface {
+    Send(to, body string) error
+}
+
+type Service struct {
+    sender Sender
+}
+```
+
+The `email` package exports a concrete `Client` struct — it doesn't need to know about `Sender`.
+
+### Accept Interfaces, Return Structs
+
+Functions SHOULD accept interface parameters for flexibility and return concrete types for clarity. Callers get full access to the returned type's fields and methods; consumers upstream can still assign the result to an interface variable if needed.
+
+```go
+// Good — accepts interface, returns concrete
+func NewService(store UserStore) *Service { ... }
+
+// BAD — NEVER return interfaces from constructors
+func NewService(store UserStore) ServiceInterface { ... }
+```
+
+### Don't Create Interfaces Prematurely
+
+> "Don't design with interfaces, discover them."
+
+NEVER create interfaces prematurely — wait for 2+ implementations or a testability requirement. Premature interfaces add indirection without value. Start with concrete types; extract an interface when a second consumer or a test mock demands it.
+
+```go
+// Bad — premature interface with a single implementation
+type UserRepository interface {
+    FindByID(ctx context.Context, id string) (*User, error)
+}
+type userRepository struct { db *sql.DB }
+
+// Good — start concrete, extract an interface later when needed
+type UserRepository struct { db *sql.DB }
+```
+
+## Make the Zero Value Useful
+
+Design structs so they work without explicit initialization. A well-designed zero value reduces constructor boilerplate and prevents nil-related bugs:
+
+```go
+// Good — zero value is ready to use
+var buf bytes.Buffer
+buf.WriteString("hello")
+
+var mu sync.Mutex
+mu.Lock()
+
+// Bad — zero value is broken, requires constructor
+type Registry struct {
+    items map[string]Item // nil map, panics on write
+}
+
+// Good — lazy initialization guards the zero value
+func (r *Registry) Register(name string, item Item) {
+    if r.items == nil {
+        r.items = make(map[string]Item)
+    }
+    r.items[name] = item
+}
+```
+
+## Avoid `any` / `interface{}` When a Specific Type Will Do
+
+Since Go 1.18+, MUST prefer generics over `any` for type-safe operations. Use `any` only at true boundaries where the type is genuinely unknown (e.g., JSON decoding, reflection):
+
+```go
+// Bad — loses type safety
+func Contains(slice []any, target any) bool { ... }
+
+// Good — generic, type-safe
+func Contains[T comparable](slice []T, target T) bool { ... }
+```
+
+## Key Standard Library Interfaces
+
+| Interface     | Package         | Method                                |
+| ------------- | --------------- | ------------------------------------- |
+| `Reader`      | `io`            | `Read(p []byte) (n int, err error)`   |
+| `Writer`      | `io`            | `Write(p []byte) (n int, err error)`  |
+| `Closer`      | `io`            | `Close() error`                       |
+| `Stringer`    | `fmt`           | `String() string`                     |
+| `error`       | builtin         | `Error() string`                      |
+| `Handler`     | `net/http`      | `ServeHTTP(ResponseWriter, *Request)` |
+| `Marshaler`   | `encoding/json` | `MarshalJSON() ([]byte, error)`       |
+| `Unmarshaler` | `encoding/json` | `UnmarshalJSON([]byte) error`         |
+
+Canonical method signatures MUST be honored — if your type has a `String()` method, it must match `fmt.Stringer`. Don't invent `ToString()` or `ReadData()`.
+
+## Compile-Time Interface Check
+
+Verify a type implements an interface at compile time with a blank identifier assignment. Place it near the type definition:
+
+```go
+var _ io.ReadWriter = (*MyBuffer)(nil)
+```
+
+This costs nothing at runtime. If `MyBuffer` ever stops satisfying `io.ReadWriter`, the build fails immediately.
+
+## Type Assertions & Type Switches
+
+### Safe Type Assertion
+
+Type assertions MUST use the comma-ok form to avoid panics:
+
+```go
+// Good — safe
+s, ok := val.(string)
+if !ok {
+    // handle
+}
+
+// Bad — panics if val is not a string
+s := val.(string)
+```
+
+### Type Switch
+
+Discover the dynamic type of an interface value:
+
+```go
+switch v := val.(type) {
+case string:
+    fmt.Println(v)
+case int:
+    fmt.Println(v * 2)
+case io.Reader:
+    io.Copy(os.Stdout, v)
+default:
+    fmt.Printf("unexpected type %T\n", v)
+}
+```
+
+### Optional Behavior with Type Assertions
+
+Check if a value supports additional capabilities without requiring them upfront:
+
+```go
+type Flusher interface {
+    Flush() error
+}
+
+func writeData(w io.Writer, data []byte) error {
+    if _, err := w.Write(data); err != nil {
+        return err
+    }
+    // Flush only if the writer supports it
+    if f, ok := w.(Flusher); ok {
+        return f.Flush()
+    }
+    return nil
+}
+```
+
+This pattern is used extensively in the standard library (e.g., `http.Flusher`, `io.ReaderFrom`).
+
+## Struct & Interface Embedding
+
+### Struct Embedding
+
+Embedding promotes the inner type's methods and fields to the outer type — composition, not inheritance:
+
+```go
+type Logger struct {
+    *slog.Logger
+}
+
+type Server struct {
+    Logger
+    addr string
+}
+
+// s.Info(...) works — promoted from slog.Logger through Logger
+s := Server{Logger: Logger{slog.Default()}, addr: ":8080"}
+s.Info("starting", "addr", s.addr)
+```
+
+The receiver of promoted methods is the _inner_ type, not the outer. The outer type can override by defining its own method with the same name.
+
+### When to Embed vs Named Field
+
+| Use | When |
+| --- | --- |
+| **Embed** | You want to promote the full API of the inner type — the outer type "is a" enhanced version |
+| **Named field** | You only need the inner type internally — the outer type "has a" dependency |
+
+```go
+// Embed — Server exposes all http.Handler methods
+type Server struct {
+    http.Handler
+}
+
+// Named field — Server uses the store but doesn't expose its methods
+type Server struct {
+    store *DataStore
+}
+```
+
+## Dependency Injection via Interfaces
+
+Accept dependencies as interfaces in constructors. This decouples components and makes testing straightforward:
+
+```go
+type UserStore interface {
+    FindByID(ctx context.Context, id string) (*User, error)
+}
+
+type UserService struct {
+    store UserStore
+}
+
+func NewUserService(store UserStore) *UserService {
+    return &UserService{store: store}
+}
+```
+
+In tests, pass a mock or stub that satisfies `UserStore` — no real database needed.
+
+## Struct Field Tags
+
+Use field tags for serialization control. Exported fields in serialized structs MUST have field tags:
+
+```go
+type Order struct {
+    ID        string    `json:"id"         db:"id"`
+    UserID    string    `json:"user_id"    db:"user_id"`
+    Total     float64   `json:"total"      db:"total"`
+    Items     []Item    `json:"items"      db:"-"`
+    CreatedAt time.Time `json:"created_at" db:"created_at"`
+    DeletedAt time.Time `json:"-"          db:"deleted_at"`
+    Internal  string    `json:"-"          db:"-"`
+}
+```
+
+| Directive               | Meaning                                     |
+| ----------------------- | ------------------------------------------- |
+| `json:"name"`           | Field name in JSON output                   |
+| `json:"name,omitempty"` | Omit field if zero value                    |
+| `json:"-"`              | Always exclude from JSON                    |
+| `json:",string"`        | Encode number/bool as JSON string           |
+| `db:"column"`           | Database column mapping (sqlx, etc.)        |
+| `yaml:"name"`           | YAML field name                             |
+| `xml:"name,attr"`       | XML attribute                               |
+| `validate:"required"`   | Struct validation (go-playground/validator) |
+
+## Pointer vs Value Receivers
+
+| Use pointer `(s *Server)` | Use value `(s Server)` |
+| --- | --- |
+| Method modifies the receiver | Receiver is small and immutable |
+| Receiver contains `sync.Mutex` or similar | Receiver is a basic type (int, string) |
+| Receiver is a large struct | Method is a read-only accessor |
+| Consistency: if any method uses a pointer, all should | Map and function values (already reference types) |
+
+Receiver type MUST be consistent across all methods of a type — if one method uses a pointer receiver, all methods should.
+
+## Preventing Struct Copies with `noCopy`
+
+Some structs must never be copied after first use (e.g., those containing a mutex, a channel, or internal pointers). Embed a `noCopy` sentinel to make `go vet` catch accidental copies:
+
+```go
+// noCopy may be added to structs which must not be copied after first use.
+// See https://pkg.go.dev/sync#noCopy
+type noCopy struct{}
+
+func (*noCopy) Lock()   {}
+func (*noCopy) Unlock() {}
+
+type ConnPool struct {
+    noCopy noCopy
+    mu     sync.Mutex
+    conns  []*Conn
+}
+```
+
+`go vet` reports an error if a `ConnPool` value is copied (passed by value, assigned, etc.). This is the same technique the standard library uses for `sync.WaitGroup`, `sync.Mutex`, `strings.Builder`, and others.
+
+Always pass these structs by pointer:
+
+```go
+// Good
+func process(pool *ConnPool) { ... }
+
+// Bad — go vet will flag this
+func process(pool ConnPool) { ... }
+```
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-naming` skill for interface naming conventions (Reader, Closer, Stringer)
+- → See `samber/cc-skills-golang@golang-design-patterns` skill for functional options, constructors, and builder patterns
+- → See `samber/cc-skills-golang@golang-dependency-injection` skill for DI patterns using interfaces
+- → See `samber/cc-skills-golang@golang-code-style` skill for value vs pointer function parameters (distinct from receivers)
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Large interfaces (5+ methods) | Split into focused 1-3 method interfaces, compose if needed |
+| Defining interfaces in the implementor package | Define where consumed |
+| Returning interfaces from constructors | Return concrete types |
+| Bare type assertions without comma-ok | Always use `v, ok := x.(T)` |
+| Embedding when you only need a few methods | Use a named field and delegate explicitly |
+| Missing field tags on serialized structs | Tag all exported fields in marshaled types |
+| Mixing pointer and value receivers on a type | Pick one and be consistent |
+| Forgetting compile-time interface check | Add `var _ Interface = (*Type)(nil)` |
+| Using `ToString()` instead of `String()` | Honor canonical method names |
+| Premature interface with a single implementation | Start concrete, extract interface when needed |
+| Nil map/slice in zero value struct | Use lazy initialization in methods |
+| Using `any` for type-safe operations | Use generics (`[T comparable]`) instead |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-structs-interfaces/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-structs-interfaces/evals/evals.json
new file mode 100644
index 00000000..99cadfb0
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-structs-interfaces/evals/evals.json
@@ -0,0 +1,153 @@
+[
+  {
+    "id": 1,
+    "name": "interface-at-consumer-not-implementor",
+    "description": "Tests whether the model defines interfaces where they are consumed, not where they are implemented",
+    "prompt": "I'm writing a Go notification service that can send emails. I have an email package with a Client struct that has a Send method. I also have a notification package that needs to use this email client. Where should I define the interface?",
+    "trap": "Without the skill, the model often puts the interface in the email package (the implementor). The skill says interfaces MUST be defined where consumed, not where implemented.",
+    "assertions": [
+      {"id": "1.1", "text": "Interface is defined in the notification package (the consumer), NOT in the email package"},
+      {"id": "1.2", "text": "Interface has only the methods the notification package needs (not the full email.Client API)"},
+      {"id": "1.3", "text": "Email package exports a concrete Client struct, not an interface"},
+      {"id": "1.4", "text": "Explains WHY: keeps the consumer in control of the contract, avoids importing a package just for its interface"},
+      {"id": "1.5", "text": "Notification service depends on its own interface, not on email package types"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "return-structs-not-interfaces",
+    "description": "Tests whether the model returns concrete types from constructors, not interfaces",
+    "prompt": "I'm designing a Go package with a UserService that depends on a UserStore interface. Should my NewUserService constructor return *UserService or UserServiceInterface? Show me the constructor signature.",
+    "trap": "Without the skill, the model may suggest returning an interface for 'flexibility' or 'abstraction'. The skill says functions SHOULD return concrete types -- NEVER return interfaces from constructors.",
+    "assertions": [
+      {"id": "2.1", "text": "Constructor returns *UserService (concrete type), NOT an interface"},
+      {"id": "2.2", "text": "Constructor accepts UserStore as an interface parameter (accept interfaces)"},
+      {"id": "2.3", "text": "Explains WHY: callers get full access to the concrete type's fields/methods; consumers can assign to interface if needed"},
+      {"id": "2.4", "text": "Explicitly states that returning interfaces from constructors is bad practice"},
+      {"id": "2.5", "text": "The accept-interfaces-return-structs principle is stated or demonstrated"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "premature-interface-trap",
+    "description": "Tests whether the model avoids creating interfaces prematurely when there is only one implementation",
+    "prompt": "I'm writing a Go application with a UserRepository that talks to PostgreSQL. It's the only database we'll ever use. Should I create a UserRepository interface and a concrete postgresUserRepository struct, or just use a concrete struct directly?",
+    "trap": "Without the skill, the model almost always suggests creating an interface 'for testability' even with a single implementation. The skill says NEVER create interfaces prematurely -- wait for 2+ implementations or a testability requirement.",
+    "assertions": [
+      {"id": "3.1", "text": "Recommends starting with a concrete struct (not an interface) when there is only one implementation"},
+      {"id": "3.2", "text": "Mentions the principle: don't design with interfaces, discover them"},
+      {"id": "3.3", "text": "Suggests extracting an interface LATER when a second consumer or test mock demands it"},
+      {"id": "3.4", "text": "Acknowledges that testability IS a valid reason to add an interface, but it should be a deliberate choice"},
+      {"id": "3.5", "text": "Does NOT reflexively recommend creating an interface just because it is a repository"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "zero-value-useful-design",
+    "description": "Tests whether the model designs structs with useful zero values using lazy initialization",
+    "prompt": "I have a Go Registry struct that stores items in a map. Users are getting panics when they call Register without calling NewRegistry first. How should I fix this?",
+    "trap": "Without the skill, the model may just say 'always call the constructor' or add nil checks at every call site. The skill says to make the zero value useful with lazy initialization.",
+    "assertions": [
+      {"id": "4.1", "text": "Recommends lazy initialization in the Register method (if r.items == nil { r.items = make(...) })"},
+      {"id": "4.2", "text": "Mentions the Go principle: make the zero value useful"},
+      {"id": "4.3", "text": "The fix allows using var r Registry without calling a constructor"},
+      {"id": "4.4", "text": "Does NOT just say 'always use the constructor' as the primary fix"},
+      {"id": "4.5", "text": "References bytes.Buffer or sync.Mutex as stdlib examples of useful zero values"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "embedding-vs-named-field",
+    "description": "Tests whether the model correctly distinguishes when to embed vs use a named field",
+    "prompt": "I have a Go Server struct that uses a DataStore for persistence and an http.Handler for routing. Should I embed both, use named fields for both, or mix? The Server should expose the Handler's ServeHTTP method but should NOT expose DataStore's internal methods to callers.",
+    "trap": "Without the skill, the model may embed both or use named fields for both. The skill has a clear rule: embed when you want to promote the full API ('is a'), named field when you only need it internally ('has a').",
+    "assertions": [
+      {"id": "5.1", "text": "Embeds http.Handler (to promote ServeHTTP to the Server)"},
+      {"id": "5.2", "text": "Uses a named field for DataStore (not embedded, because its methods should not be exposed)"},
+      {"id": "5.3", "text": "Explains the embed vs named field rule: embed for 'is a' (promote full API), named field for 'has a' (internal use)"},
+      {"id": "5.4", "text": "Mentions that embedding promotes ALL methods of the inner type, which can be undesirable"},
+      {"id": "5.5", "text": "Notes that the receiver of promoted methods is the inner type, not the outer type"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "compile-time-interface-check",
+    "description": "Tests whether the model uses compile-time interface verification",
+    "prompt": "I have a Go type MyBuffer that should implement io.ReadWriter. How can I make sure the compiler catches it if I accidentally break the interface contract later?",
+    "trap": "Without the skill, the model may suggest writing a test or just relying on usage sites to catch it. The skill recommends the var _ Interface = (*Type)(nil) pattern.",
+    "assertions": [
+      {"id": "6.1", "text": "Uses var _ io.ReadWriter = (*MyBuffer)(nil) pattern"},
+      {"id": "6.2", "text": "Places the check near the type definition"},
+      {"id": "6.3", "text": "Explains that this costs nothing at runtime"},
+      {"id": "6.4", "text": "Explains that the build fails immediately if MyBuffer stops satisfying the interface"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "type-assertion-comma-ok",
+    "description": "Bare type assertions panic on wrong type; comma-ok is required even when the type 'should always' be correct",
+    "prompt": "Review this Go event dispatcher and fix any issues:\n\n```go\ntype Event struct {\n    Type    string\n    Payload any\n}\n\nfunc Dispatch(e Event) error {\n    switch e.Type {\n    case \"user.created\":\n        payload := e.Payload.(*UserCreated)\n        return handleUserCreated(payload)\n    case \"order.placed\":\n        payload := e.Payload.(*OrderPlaced)\n        return handleOrderPlaced(payload)\n    case \"payment.failed\":\n        payload := e.Payload.(*PaymentFailed)\n        return handlePaymentFailed(payload)\n    default:\n        return fmt.Errorf(\"unknown event type: %s\", e.Type)\n    }\n}\n```\n\nA teammate says: 'The bare type assertions are fine here — we always put the right payload type for each event type, and we control all the callers. The comma-ok form just adds noise and extra if-checks.' Is the teammate correct? Fix the code if needed.",
+    "trap": "The teammate's argument sounds reasonable — the caller controls event construction and should always set the correct payload type. But bare type assertions panic at runtime on any mismatch (future code, deserialized events, tests with wrong setup). The model should reject the teammate's argument and use comma-ok form.",
+    "assertions": [
+      {"id": "7.1", "text": "Rejects the teammate's argument — bare type assertions panic at runtime on any type mismatch, regardless of how controlled the callers seem"},
+      {"id": "7.2", "text": "Uses comma-ok form for all three type assertions: payload, ok := e.Payload.(*UserCreated)"},
+      {"id": "7.3", "text": "Handles the !ok case by returning an error (not panicking) — e.g., 'unexpected payload type for user.created'"},
+      {"id": "7.4", "text": "Explains the failure mode: future code, deserialized events from external sources, or tests with wrong fixture setup will cause unrecoverable panics with bare assertions"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "optional-behavior-type-assertion",
+    "description": "Tests whether the model uses type assertions for optional interface capabilities",
+    "prompt": "I'm writing a Go function that writes data to an io.Writer. Some writers support flushing (like bufio.Writer) but not all. I want to flush after writing IF the writer supports it, but not require all writers to implement Flush. How should I design this?",
+    "trap": "Without the skill, the model may create a WriteAndFlusher interface and require all callers to implement it. The skill shows the optional behavior pattern with type assertion.",
+    "assertions": [
+      {"id": "8.1", "text": "Defines a separate Flusher interface with just the Flush method"},
+      {"id": "8.2", "text": "Function parameter is io.Writer (not a combined interface)"},
+      {"id": "8.3", "text": "Uses type assertion (f, ok := w.(Flusher)) to check for flush capability"},
+      {"id": "8.4", "text": "Only calls Flush if the type assertion succeeds"},
+      {"id": "8.5", "text": "Mentions this pattern is used in the standard library (e.g. http.Flusher, io.ReaderFrom)"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "nocopy-sentinel-struct",
+    "description": "Tests whether the model uses the noCopy sentinel to prevent struct copying",
+    "prompt": "I have a Go struct ConnPool that contains a sync.Mutex and a slice of connections. A junior developer accidentally passed it by value to a function, which caused a data race. How can I prevent this struct from being copied?",
+    "trap": "Without the skill, the model may just say 'always use pointers' or rely on code review. The skill shows the noCopy sentinel pattern that makes go vet catch accidental copies.",
+    "assertions": [
+      {"id": "9.1", "text": "Recommends embedding a noCopy sentinel struct"},
+      {"id": "9.2", "text": "noCopy implements Lock() and Unlock() methods (empty bodies)"},
+      {"id": "9.3", "text": "Explains that go vet will flag copies of structs containing noCopy"},
+      {"id": "9.4", "text": "Mentions this is the same technique used by sync.WaitGroup, sync.Mutex, or strings.Builder in the stdlib"},
+      {"id": "9.5", "text": "Shows that the struct should be passed by pointer after adding noCopy"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "generics-over-any-interface",
+    "description": "Tests whether the model prefers generics over any/interface{} for type-safe operations",
+    "prompt": "I need to write a Go function that checks if a slice contains a given element. The function should work with any comparable type (ints, strings, etc.). What's the best approach?",
+    "trap": "Without the skill, the model may use []any and any parameters for compatibility. The skill says MUST prefer generics over any for type-safe operations (Go 1.18+).",
+    "assertions": [
+      {"id": "10.1", "text": "Uses generics with a type parameter: func Contains[T comparable](slice []T, target T) bool"},
+      {"id": "10.2", "text": "Does NOT use []any or interface{} parameters"},
+      {"id": "10.3", "text": "Uses the comparable constraint for the type parameter"},
+      {"id": "10.4", "text": "Explains WHY: generics preserve type safety, while any loses it"},
+      {"id": "10.5", "text": "Mentions that any should only be used at true boundaries where type is genuinely unknown (JSON decoding, reflection)"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "receiver-consistency-rule",
+    "description": "Tests whether the model enforces consistent receiver types across all methods of a type",
+    "prompt": "I have a Go struct with 5 methods. Four use value receivers and one uses a pointer receiver because it modifies the struct. Is this fine?",
+    "trap": "Without the skill, the model may accept the mixed receiver approach as valid for each method. The skill says receiver type MUST be consistent -- if one method uses pointer, all should.",
+    "assertions": [
+      {"id": "11.1", "text": "Says mixing pointer and value receivers on the same type is wrong or not recommended"},
+      {"id": "11.2", "text": "Recommends making ALL methods use pointer receivers since one needs to mutate"},
+      {"id": "11.3", "text": "Explains WHY: consistency rule -- if any method uses a pointer receiver, all should"},
+      {"id": "11.4", "text": "Mentions that method sets differ for T and *T which affects interface satisfaction"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/SKILL.md
new file mode 100644
index 00000000..9273bffb
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/SKILL.md
@@ -0,0 +1,228 @@
+---
+name: golang-swagger
+description: "Golang OpenAPI/Swagger documentation with swaggo/swag — annotation comments (@Summary, @Param, @Success, @Router, @Security), swag init code generation, framework integrations (gin, echo, fiber, chi, net/http), security definitions (Bearer/JWT, OAuth2, API key), and struct tags (swaggertype, enums, example, swaggerignore). Apply when adding or maintaining Swagger/OpenAPI docs in a Go project, or when the codebase imports github.com/swaggo/swag, github.com/swaggo/gin-swagger, github.com/swaggo/echo-swagger, github.com/swaggo/http-swagger, or github.com/swaggo/files."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents. Requires go and swag CLI.
+metadata:
+  author: samber
+  version: "1.0.1"
+  openclaw:
+    emoji: "📋"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - swag
+    install:
+      - kind: go
+        package: github.com/swaggo/swag/cmd/swag@latest
+        bins: [swag]
+    skill-library-version: "2.0.0-rc5"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs Bash(swag:*) AskUserQuestion
+---
+
+**Persona:** You are a Go API documentation engineer. You treat docs as a contract — accurate, complete annotations prevent integration bugs and make the Swagger UI the source of truth for API consumers.
+
+**Modes:**
+
+- **Build** — adding Swagger to a new or existing Go project: set up the toolchain, annotate handlers, generate docs, wire the UI endpoint.
+- **Audit** — reviewing existing swagger annotations for completeness, correctness, and security coverage.
+
+**Dependencies:**
+
+- swag: `go install github.com/swaggo/swag/cmd/swag@latest`
+
+## Setup
+
+Three steps to get Swagger UI running:
+
+```bash
+swag init                        # generates docs/ with docs.go, swagger.json, swagger.yaml
+swag init -g cmd/api/main.go     # if general info is not in main.go
+swag fmt                         # format annotation comments (like go fmt)
+```
+
+Import the `docs` package to register the spec. Use a blank import when only wiring the UI; use a named import when you also need to override `docs.SwaggerInfo` at runtime:
+
+```go
+import _ "yourmodule/docs"          // blank: registers spec, no identifier
+import docs "yourmodule/docs"       // named: use when overriding SwaggerInfo
+```
+
+Wire the UI endpoint — pick your framework:
+
+```go
+// Gin
+r.GET("/swagger/*any", ginSwagger.WrapHandler(swaggerFiles.Handler))
+
+// Echo
+e.GET("/swagger/*", echoSwagger.WrapHandler)
+
+// Fiber
+app.Get("/swagger/*", fiberSwagger.WrapHandler(swaggerFiles.Handler))
+
+// net/http
+mux.Handle("/swagger/", httpSwagger.Handler(swaggerFiles.Handler))
+
+// Chi
+r.Get("/swagger/*", httpSwagger.Handler(swaggerFiles.Handler))
+```
+
+Access the UI at `/swagger/index.html`.
+
+For dynamic host/basepath (multi-environment), use a named import and override before serving:
+
+```go
+import docs "yourmodule/docs"
+
+docs.SwaggerInfo.Host     = os.Getenv("API_HOST")
+docs.SwaggerInfo.BasePath = "/api/v1"
+```
+
+[Full CLI reference](references/swag-cli.md)
+
+## General API Info
+
+Place in `main.go` (or the file passed via `-g`). These annotations define the top-level spec:
+
+```go
+// @title           My API
+// @version         1.0
+// @description     Short description of the API.
+// @host            localhost:8080
+// @BasePath        /api/v1
+// @schemes         http https
+
+// @contact.name    API Support
+// @contact.email   support@example.com
+// @license.name    Apache 2.0
+
+// @securityDefinitions.apikey Bearer
+// @in header
+// @name Authorization
+// @description Type "Bearer" followed by a space and the JWT token.
+```
+
+## Operation Annotations
+
+Annotate each handler function. The standard doc comment (`// FuncName godoc`) must precede swag annotations — it anchors indentation for `swag fmt`.
+
+```go
+// ShowAccount godoc
+// @Summary      Get account by ID
+// @Description  Returns account details for the given ID.
+// @Tags         accounts
+// @Accept       json
+// @Produce      json
+// @Param        id      path  int  true  "Account ID"
+// @Param        filter  query string false "Optional search filter"
+// @Success      200  {object}  model.Account
+// @Success      204  "No content"
+// @Failure      400  {object}  api.ErrorResponse
+// @Failure      404  {object}  api.ErrorResponse
+// @Router       /accounts/{id} [get]
+// @Security     Bearer
+func ShowAccount(c *gin.Context) {}
+```
+
+**@Param** format: `@Param <name> <in> <type> <required> "<description>" [attributes]`
+
+| `<in>`     | Usage                                |
+| ---------- | ------------------------------------ |
+| `path`     | URL path segment (`/users/{id}`)     |
+| `query`    | URL query string (`?filter=x`)       |
+| `body`     | Request body — type must be a struct |
+| `header`   | HTTP header                          |
+| `formData` | Multipart/form field                 |
+
+Optional attributes on `@Param`: `default(v)`, `minimum(n)`, `maximum(n)`, `minLength(n)`, `maxLength(n)`, `Enums(a,b,c)`, `example(v)`, `collectionFormat(multi)`.
+
+**@Success/@Failure** format: `@Success <code> {<kind>} <type> "<description>"`
+
+| `<kind>`             | When             |
+| -------------------- | ---------------- |
+| `{object}`           | Single struct    |
+| `{array}`            | Slice of structs |
+| `string` / `integer` | Primitive        |
+
+**Generics** (swag v2): `@Success 200 {object} api.Response[model.User]`
+
+**Nested composition**: `@Success 200 {object} api.Response{data=model.User}`
+
+## Security Definitions
+
+Define once at the API level (in main.go), apply per endpoint with `@Security`.
+
+```go
+// Bearer / JWT
+// @securityDefinitions.apikey Bearer
+// @in header
+// @name Authorization
+
+// API key in header
+// @securityDefinitions.apikey ApiKeyAuth
+// @in header
+// @name X-API-Key
+
+// Basic auth
+// @securityDefinitions.basic BasicAuth
+
+// OAuth2 authorization code
+// @securityDefinitions.oauth2.authorizationCode OAuth2
+// @authorizationUrl https://example.com/oauth/authorize
+// @tokenUrl https://example.com/oauth/token
+// @scope.read Read access
+// @scope.write Write access
+```
+
+Apply to an endpoint:
+
+```go
+// @Security Bearer
+// @Security OAuth2[read, write]
+// @Security BasicAuth && ApiKeyAuth   // AND — both required
+```
+
+## Struct Tags
+
+Enrich models without changing their Go type:
+
+```go
+type CreateUserRequest struct {
+    Name   string `json:"name" example:"Jane Doe" minLength:"2" maxLength:"100"`
+    Role   string `json:"role" enums:"admin,user,guest" example:"user"`
+    Age    int    `json:"age" minimum:"18" maximum:"120"`
+    Avatar []byte `json:"avatar" swaggertype:"string" format:"base64"`
+    Secret string `json:"-" swaggerignore:"true"`  // excluded from docs
+}
+```
+
+| Tag | Purpose |
+| --- | --- |
+| `example` | Example value shown in Swagger UI |
+| `enums` | Comma-separated allowed values |
+| `swaggertype` | Override detected type (e.g., `"primitive,integer"` for `time.Time`) |
+| `swaggerignore:"true"` | Exclude field from the generated schema |
+| `extensions` | Add OpenAPI extensions: `extensions:"x-nullable,x-deprecated=true"` |
+
+## Common Mistakes
+
+| Mistake | Why it breaks | Fix |
+| --- | --- | --- |
+| Missing `_ "yourmodule/docs"` import | Schema not registered; UI loads empty | Add blank import in main.go or server init |
+| Stale `docs/` after code changes | Docs diverge from implementation; consumers get wrong schema | Re-run `swag init` after every annotation change |
+| `@Param body` with primitive type | swag cannot derive schema from `string`; generation fails | Always use a named struct for body params |
+| No `@Security` on protected routes | Swagger UI shows no lock icon; testers send unauthenticated requests | Apply `@Security` to every authenticated endpoint |
+| General info annotations in the wrong file | swag silently skips them; spec has no title/host | Use `-g <file>` flag or move annotations to `main.go` |
+| Using `{object}` with a map type | swag cannot generate a schema for `map[string]any` without help | Use a named struct or annotate with `swaggertype` |
+| Multi-word `@Tags` without quotes | Tags split on spaces, producing malformed grouping | Quote tags with spaces: `@Tags "user accounts"` |
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-security` for securing the Swagger UI endpoint in production (disable or gate with auth middleware).
+- → See `samber/cc-skills-golang@golang-grpc` for gRPC — use grpc-gateway with its own OpenAPI generator instead of swag.
+
+This skill is not exhaustive. Refer to the swaggo/swag documentation and code examples for up-to-date API signatures and usage patterns. Context7 can help as a discoverability platform.
+
+If you encounter a bug or unexpected behavior in swag, open an issue at <https://github.com/swaggo/swag/issues>.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/evals/evals.json
new file mode 100644
index 00000000..9e6ad956
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/evals/evals.json
@@ -0,0 +1,149 @@
+{
+  "skill_name": "golang-swagger",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I've already run `swag init` and the docs/ folder was generated. Now wire up the Swagger UI in my Gin server so the docs actually show up at /swagger/index.html. Here's my main.go:\n\n```go\npackage main\n\nimport \"github.com/gin-gonic/gin\"\n\nfunc main() {\n    r := gin.Default()  \n    r.GET(\"/api/users\", getUsers)\n    r.Run(\":8080\")\n}\n```",
+      "expected_output": "Adds the blank import `_ \"yourmodule/docs\"` AND wires the ginSwagger endpoint. The blank import is the trap — without it the UI loads empty even if the route is registered.",
+      "assertions": [
+        "Adds a blank import of the docs package (e.g., `_ \"<module>/docs\"`)",
+        "Imports github.com/swaggo/gin-swagger",
+        "Imports github.com/swaggo/files",
+        "Registers a GET route matching /swagger/*any using ginSwagger.WrapHandler",
+        "Does not suggest running swag init again (it was already done)"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Our GET /settings endpoint returns a dynamic set of feature flags as a map: `map[string]bool`. Document this endpoint for Swagger so the response schema is visible in the UI.",
+      "expected_output": "Defines a named struct for the response or uses swaggertype annotation — swag cannot generate a schema for map[string]bool directly. The trap is using `{object} map[string]bool` in @Success which fails generation.",
+      "assertions": [
+        "Does NOT use `{object} map[string]bool` directly in @Success",
+        "Defines a named struct for the response OR acknowledges a swaggertype workaround is needed",
+        "@Success annotation uses a named type (not a raw map literal)",
+        "@Router annotation is present with [get] method",
+        "@Produce annotation specifies json"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Document this Go struct for Swagger. We need the docs to look correct:\n\n```go\ntype AuditRecord struct {\n    CreatedAt time.Time\n    UpdatedAt time.Time\n    Payload   []byte\n}\n```",
+      "expected_output": "Uses swaggertype tag to override time.Time (which becomes an object by default) and []byte (which becomes a base64 string). Without the skill the model leaves the types as-is, producing wrong schemas.",
+      "assertions": [
+        "Adds swaggertype tag to CreatedAt field (e.g., `swaggertype:\"string\"` with format:\"date-time\" or `swaggertype:\"primitive,integer\"`)",
+        "Adds swaggertype tag to UpdatedAt field with the same treatment",
+        "Adds swaggertype:\"string\" and format:\"base64\" to the Payload []byte field",
+        "Preserves the json tags (does not remove them)",
+        "Does not leave time.Time fields without any swaggertype override"
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "Set up the Swagger UI for a Chi HTTP router. The BasePath must be set dynamically from an `API_BASE_PATH` environment variable because we deploy behind different path prefixes in staging and production.",
+      "expected_output": "Uses github.com/swaggo/http-swagger for Chi AND sets docs.SwaggerInfo.BasePath from os.Getenv. The trap is not knowing the http-swagger package for Chi and not knowing about the runtime docs.SwaggerInfo override.",
+      "assertions": [
+        "Imports github.com/swaggo/http-swagger",
+        "Uses r.Get (chi method) to register the swagger route with a wildcard pattern",
+        "Sets docs.SwaggerInfo.BasePath using os.Getenv(\"API_BASE_PATH\") or equivalent",
+        "Imports the docs package (blank `_ \"<module>/docs\"` or named `docs \"<module>/docs\"`)",
+        "Does not suggest rebuilding or running swag init per environment"
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "This endpoint requires BOTH an API key AND basic authentication — not one or the other. Both must be present. Show me the @Security annotation for this.",
+      "expected_output": "Uses the && syntax on a single @Security line. Two separate @Security lines mean OR (either is sufficient), which is wrong for AND semantics.",
+      "assertions": [
+        "Uses && between security schemes on a single @Security annotation line",
+        "Does NOT write two separate @Security lines for AND semantics",
+        "References valid security definition names (ApiKeyAuth, BasicAuth, or similar)",
+        "Explains or implies that two separate @Security lines would mean OR, not AND",
+        "@Security line appears inside the handler doc comment block"
+      ]
+    },
+    {
+      "id": 6,
+      "prompt": "Our API has endpoints tagged with 'Internal' and 'Admin' that must not appear in the public Swagger docs we ship to customers. How do we generate a spec that excludes both of these tags?",
+      "expected_output": "Uses swag init --tags flag with ! prefix to exclude tags. Without the skill the model likely suggests code-level filtering, separate spec files, or post-processing the JSON rather than the built-in CLI flag.",
+      "assertions": [
+        "Uses the --tags flag (or -t) with swag init",
+        "Uses ! prefix to exclude tags (e.g., --tags '!Internal,!Admin' or similar)",
+        "Shows a complete swag init command",
+        "Does not suggest manually editing the generated swagger.json",
+        "Does not require writing custom Go code to filter endpoints"
+      ]
+    },
+    {
+      "id": 7,
+      "prompt": "Add swagger annotations to this handler and make sure `swag fmt` formats them correctly:\n\n```go\nfunc CreateOrder(c *gin.Context) {\n    // handler logic\n}\n```",
+      "expected_output": "Includes a standard godoc comment (// CreateOrder godoc) before the @Summary annotation. Without it swag fmt cannot determine indentation and may produce malformed output.",
+      "assertions": [
+        "Adds `// CreateOrder godoc` as the first line of the comment block",
+        "godoc comment appears before any @ annotation",
+        "At minimum includes @Summary, @Router annotations",
+        "@Router specifies both path and HTTP method",
+        "Annotation block is placed directly above the function signature"
+      ]
+    },
+    {
+      "id": 8,
+      "prompt": "Document a GET /export endpoint with two query parameters: `ids` accepts multiple values as separate query keys (e.g., ?ids=1&ids=2&ids=3), and `fields` accepts a comma-separated list of field names (e.g., ?fields=name,email,age). Both are optional.",
+      "expected_output": "Uses collectionFormat(multi) for ids and collectionFormat(csv) for fields. Without the skill the model likely uses multi for both, or omits the collectionFormat attribute entirely and lets it default.",
+      "assertions": [
+        "@Param for ids uses collectionFormat(multi)",
+        "@Param for fields uses collectionFormat(csv) or omits it (csv is the default)",
+        "Both params use []string or []int as data type",
+        "Both params are marked as not required (false)",
+        "@Router annotation is present with [get] method"
+      ]
+    },
+    {
+      "id": 9,
+      "prompt": "We want to expose the Swagger UI in development but disable it entirely in production. Our app reads `APP_ENV=production` or `APP_ENV=development`. How do we conditionally enable the swagger endpoint without separate builds or build tags?",
+      "expected_output": "Guards the swagger route registration behind an os.Getenv check at startup. The trap is suggesting build tags (requires separate builds) or removing the route in a middleware (more complex than needed).",
+      "assertions": [
+        "Uses os.Getenv (or equivalent) to read APP_ENV at runtime",
+        "Conditionally registers the swagger route only when not in production",
+        "Does not require separate builds or build tags",
+        "The blank docs import is still present (or acknowledged as needed)",
+        "Solution works without recompiling between environments"
+      ]
+    },
+    {
+      "id": 10,
+      "prompt": "Our API always wraps responses in this envelope:\n\n```go\ntype Envelope struct {\n    Data    interface{} `json:\"data\"`\n    Message string      `json:\"message\"`\n}\n```\n\nDocument a GET /users/{id} endpoint that returns an Envelope where Data is a User object. The Swagger UI should show the actual User schema inside data, not just `interface{}`.",
+      "expected_output": "Uses nested composition syntax @Success 200 {object} Envelope{data=model.User}. Without the skill the model would document it as plain Envelope, losing the User type information in the generated schema.",
+      "assertions": [
+        "@Success annotation uses nested composition syntax with curly braces (e.g., Envelope{data=model.User})",
+        "The inner type is the User struct (or equivalent named type)",
+        "Does not create a new wrapper struct just for documentation purposes",
+        "@Param for the id path parameter is present with path location",
+        "@Router specifies the correct path and [get] method"
+      ]
+    },
+    {
+      "id": 11,
+      "prompt": "Add swagger documentation to this struct. The Role field should only allow the values 'admin', 'editor', and 'viewer' in the Swagger UI. The Score field should be between 0 and 100.\n\n```go\ntype UserProfile struct {\n    Name  string\n    Role  string\n    Score int\n}\n```",
+      "expected_output": "Uses enums struct tag for Role and minimum/maximum tags for Score. Without the skill the model might only describe constraints in comments or @Param descriptions.",
+      "assertions": [
+        "Adds `enums:\"admin,editor,viewer\"` struct tag to Role field",
+        "Adds `minimum:\"0\"` and `maximum:\"100\"` struct tags to Score field",
+        "Adds json tags to all fields",
+        "Adds example tags to at least one field",
+        "Does not only describe constraints in a comment — they must be machine-readable struct tags"
+      ]
+    },
+    {
+      "id": 12,
+      "prompt": "We have a struct with a `LastModified time.Time` field used for ETag generation in middleware. This field MUST be serialized to JSON for our caching layer to work, but it should NOT appear in the Swagger UI documentation shown to API consumers.",
+      "expected_output": "Uses swaggerignore:\"true\" while keeping the json tag intact. The trap is using json:\"-\" which breaks JSON serialization — the model must understand that swaggerignore is the correct tool when the field must still serialize.",
+      "assertions": [
+        "Uses swaggerignore:\"true\" on the LastModified field",
+        "Keeps a valid json tag on LastModified (NOT json:\"-\")",
+        "Does NOT suggest removing the field from the struct",
+        "Other struct fields retain their json and swagger documentation",
+        "Explains or implies why json:\"-\" would be wrong here (breaks serialization)"
+      ]
+    }
+  ]
+}
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/references/swag-cli.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/references/swag-cli.md
new file mode 100644
index 00000000..f3e89aee
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-swagger/references/swag-cli.md
@@ -0,0 +1,120 @@
+# swag CLI Reference
+
+## swag init — Generate Documentation
+
+```bash
+swag init                                      # parse main.go, generate docs/
+swag init -g cmd/api/main.go                   # general info in a different file
+swag init -d ./handlers,./models               # additional directories to parse
+swag init --exclude ./vendor,./internal/gen    # skip directories
+swag init -ot go,json                          # output only Go and JSON (skip YAML)
+swag init -q                                   # quiet mode (no log output)
+swag init --parseInternal                      # include internal/ packages
+swag init --parseDependency                    # parse vendor/module dependencies
+swag init --requiredByDefault                  # mark all struct fields as required
+swag init -p camelcase                         # property naming: snakecase | camelcase | pascalcase
+swag init --tags Users,Products                # only generate for these tags
+swag init --tags '!Internal'                   # exclude tag (! prefix)
+swag init --td "[[,]]"                         # custom template delimiters
+```
+
+## swag fmt — Format Annotations
+
+```bash
+swag fmt                                       # format all annotation comments
+swag fmt -d ./handlers                         # format specific directory
+swag fmt --exclude ./vendor                    # skip directories
+```
+
+`swag fmt` requires a standard Go doc comment (`// FuncName godoc`) immediately before the first `@` annotation — without it the formatter cannot determine indentation.
+
+## Framework Integration Packages
+
+| Framework                | Package                             |
+| ------------------------ | ----------------------------------- |
+| Gin                      | `github.com/swaggo/gin-swagger`     |
+| Echo                     | `github.com/swaggo/echo-swagger`    |
+| Fiber                    | `github.com/swaggo/fiber-swagger`   |
+| Chi / net/http / Gorilla | `github.com/swaggo/http-swagger`    |
+| Buffalo                  | `github.com/swaggo/buffalo-swagger` |
+| Hertz                    | `github.com/hertz-contrib/swagger`  |
+
+The shared files package (`github.com/swaggo/files`) is required by all integrations.
+
+## Dynamic Configuration
+
+Override spec values at runtime — useful for multi-environment deployments where host and basepath differ between staging and production:
+
+```go
+import docs "yourmodule/docs"  // named import required to access docs.SwaggerInfo
+
+func main() {
+    docs.SwaggerInfo.Title       = "My API"
+    docs.SwaggerInfo.Description = "Production API"
+    docs.SwaggerInfo.Version     = "2.0"
+    docs.SwaggerInfo.Host        = os.Getenv("API_HOST")
+    docs.SwaggerInfo.BasePath    = "/api/v1"
+    docs.SwaggerInfo.Schemes     = []string{"https"}
+}
+```
+
+## Generics (swag v2)
+
+Single type parameter:
+
+```go
+// @Success 200 {object} api.Response[model.User]
+// @Success 200 {array}  api.Response[model.User]
+```
+
+Multiple type parameters:
+
+```go
+// @Success 200 {object} api.Response[model.User, model.Meta]
+```
+
+## Nested Composition
+
+Embed or override fields in the documented schema without changing Go types:
+
+```go
+// @Success 200 {object} api.Envelope{data=model.User}
+// @Success 200 {object} api.Envelope{data=[]model.User}
+// @Success 200 {object} api.Envelope{data=model.User,meta=api.Pagination}
+```
+
+## Response Headers
+
+```go
+// @Header 200       {string} X-Request-ID "Unique request identifier"
+// @Header 200,400   {string} X-Request-ID "Unique request identifier"
+// @Header all       {string} X-Request-ID "Present on every response"
+```
+
+## Function-Scoped Structs
+
+swag can parse structs defined inside handler functions:
+
+```go
+// @Param req body main.CreateUser.request true "Create user input"
+func CreateUser(c *gin.Context) {
+    type request struct {
+        Name  string `json:"name"`
+        Email string `json:"email"`
+    }
+}
+```
+
+## MIME Type Aliases
+
+| Alias                   | Content-Type                      |
+| ----------------------- | --------------------------------- |
+| `json`                  | application/json                  |
+| `xml`                   | application/xml                   |
+| `plain`                 | text/plain                        |
+| `html`                  | text/html                         |
+| `mpfd`                  | multipart/form-data               |
+| `x-www-form-urlencoded` | application/x-www-form-urlencoded |
+| `octet-stream`          | application/octet-stream          |
+| `png` / `jpeg` / `gif`  | image/png, image/jpeg, image/gif  |
+| `event-stream`          | text/event-stream                 |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/SKILL.md
new file mode 100644
index 00000000..f89b7f2c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/SKILL.md
@@ -0,0 +1,428 @@
+---
+name: golang-testing
+description: "Production-ready Golang tests — table-driven tests, testify suites and mocks, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, code coverage, integration tests, idiomatic test naming. Use when writing or reviewing Go tests, choosing a testing approach, setting up Go test CI, or debugging flaky/slow tests. For testify-specific APIs see `samber/cc-skills-golang@golang-stretchr-testify`; for measurement methodology see `samber/cc-skills-golang@golang-benchmark`."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.2"
+  openclaw:
+    emoji: "🧪"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - gotests
+    install:
+      - kind: go
+        package: github.com/cweill/gotests/gotests@latest
+        bins: [gotests]
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent Bash(gotests:*) AskUserQuestion
+---
+
+**Persona:** You are a Go engineer who treats tests as executable specifications. You write tests to constrain behavior, not to hit coverage targets.
+
+**Thinking mode:** Use `ultrathink` for test strategy design and failure analysis. Shallow reasoning misses edge cases and produces brittle tests that pass today but break tomorrow.
+
+**Modes:**
+
+- **Write mode** — generating new tests for existing or new code. Work sequentially through the code under test; use `gotests` to scaffold table-driven tests, then enrich with edge cases and error paths.
+- **Review mode** — reviewing a PR's test changes. Focus on the diff: check coverage of new behaviour, assertion quality, table-driven structure, and absence of flakiness patterns. Sequential.
+- **Audit mode** — auditing an existing test suite for gaps, flakiness, or bad patterns (order-dependent tests, missing `t.Parallel()`, implementation-detail coupling). Launch up to 3 parallel sub-agents split by concern: (1) unit test quality and coverage gaps, (2) integration test isolation and build tags, (3) goroutine leaks and race conditions.
+- **Debug mode** — a test is failing or flaky. Work sequentially: reproduce reliably, isolate the failing assertion, trace the root cause in production code or test setup.
+
+> **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-testing` skill takes precedence.
+
+**Dependencies:**
+
+- gotests: `go install github.com/cweill/gotests/gotests@latest`
+
+# Go Testing Best Practices
+
+This skill guides the creation of production-ready tests for Go applications. Follow these principles to write maintainable, fast, and reliable tests.
+
+## Best Practices Summary
+
+1. Table-driven tests MUST use named subtests -- every test case needs a `name` field passed to `t.Run`
+2. Integration tests MUST use build tags (`//go:build integration`) to separate from unit tests
+3. Tests MUST NOT depend on execution order -- each test MUST be independently runnable
+4. Independent tests SHOULD use `t.Parallel()` when possible
+5. NEVER test implementation details -- test observable behavior and public API contracts
+6. Packages with goroutines SHOULD use `goleak.VerifyTestMain` in `TestMain` to detect goroutine leaks
+7. Use testify as helpers, not a replacement for standard library
+8. Mock interfaces, not concrete types
+9. Keep unit tests fast (< 1ms), use build tags for integration tests
+10. Run tests with race detection in CI
+11. Include examples as executable documentation
+
+## Test Structure and Organization
+
+### File Conventions
+
+```go
+// package_test.go - tests in same package (white-box, access unexported)
+package mypackage
+
+// mypackage_test.go - tests in test package (black-box, public API only)
+package mypackage_test
+```
+
+### Naming Conventions
+
+```go
+func TestAdd(t *testing.T) { ... }               // function test
+func TestMyStruct_MyMethod(t *testing.T) { ... } // method test
+func BenchmarkAdd(b *testing.B) { ... }          // benchmark
+func ExampleAdd() { ... }                        // example
+func FuzzAdd(f *testing.F) { ... }               // fuzz test
+```
+
+## Table-Driven Tests
+
+Table-driven tests are the idiomatic Go way to test multiple scenarios. Always name each test case.
+
+```go
+func TestCalculatePrice(t *testing.T) {
+    tests := []struct {
+        name     string
+        quantity int
+        unitPrice float64
+        expected  float64
+    }{
+        {
+            name:      "single item",
+            quantity:  1,
+            unitPrice: 10.0,
+            expected:  10.0,
+        },
+        {
+            name:      "bulk discount - 100 items",
+            quantity:  100,
+            unitPrice: 10.0,
+            expected:  900.0, // 10% discount
+        },
+        {
+            name:      "zero quantity",
+            quantity:  0,
+            unitPrice: 10.0,
+            expected:  0.0,
+        },
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            got := CalculatePrice(tt.quantity, tt.unitPrice)
+            if got != tt.expected {
+                t.Errorf("CalculatePrice(%d, %.2f) = %.2f, want %.2f",
+                    tt.quantity, tt.unitPrice, got, tt.expected)
+            }
+        })
+    }
+}
+```
+
+## Unit Tests
+
+Unit tests should be fast (< 1ms), isolated (no external dependencies), and deterministic.
+
+## Testing HTTP Handlers
+
+Use `httptest` for handler tests with table-driven patterns. See [HTTP Testing](./references/http-testing.md) for examples with request/response bodies, query parameters, headers, and status code assertions.
+
+## Goroutine Leak Detection with goleak
+
+Use `go.uber.org/goleak` to detect leaking goroutines, especially for concurrent code:
+
+```go
+import (
+    "testing"
+    "go.uber.org/goleak"
+)
+
+func TestMain(m *testing.M) {
+    goleak.VerifyTestMain(m)
+}
+```
+
+To exclude specific goroutine stacks (for known leaks or library goroutines):
+
+```go
+func TestMain(m *testing.M) {
+    goleak.VerifyTestMain(m,
+        goleak.IgnoreCurrent(),
+    )
+}
+```
+
+Or per-test:
+
+```go
+func TestWorkerPool(t *testing.T) {
+    defer goleak.VerifyNone(t)
+    // ... test code ...
+}
+```
+
+## testing/synctest for Deterministic Goroutine Testing
+
+`testing/synctest` (Go 1.25+) provides deterministic tests for goroutines, timers, deadlines, and context cancellation. Time advances only when all goroutines are blocked, making ordering predictable.
+
+When to use `synctest` instead of real time:
+
+- Testing concurrent code with time-based operations (time.Sleep, time.After, time.Ticker)
+- When race conditions need to be reproducible
+- When tests are flaky due to timing issues
+
+```go
+import (
+    "context"
+    "testing"
+    "testing/synctest"
+    "time"
+)
+
+func TestContextTimeout(t *testing.T) {
+    synctest.Test(t, func(t *testing.T) {
+        const timeout = 5 * time.Second
+
+        ctx, cancel := context.WithTimeout(t.Context(), timeout)
+        defer cancel()
+
+        time.Sleep(timeout - time.Nanosecond)
+        synctest.Wait()
+        if err := ctx.Err(); err != nil {
+            t.Fatalf("before timeout: %v", err)
+        }
+
+        time.Sleep(time.Nanosecond)
+        synctest.Wait()
+        if err := ctx.Err(); err != context.DeadlineExceeded {
+            t.Fatalf("after timeout: got %v, want DeadlineExceeded", err)
+        }
+    })
+}
+```
+
+Use `synctest.Test` in Go 1.25+ and Go 1.26+. Do not use the old Go 1.24 experimental `synctest.Run` API in Go 1.25+ or Go 1.26+ code. If a module explicitly targets Go 1.24 and opts into `GOEXPERIMENT=synctest`, use the old API only as a compatibility fallback.
+
+Key differences in `synctest`:
+
+- `time.Sleep` advances synthetic time instantly when the goroutine blocks
+- `time.After` fires when synthetic time reaches the duration
+- All goroutines run to blocking points before time advances
+- Test execution is deterministic and repeatable
+
+## Test Timeouts
+
+For tests that may hang, use a timeout helper that panics with caller location. See [Helpers](./references/helpers.md).
+
+## Benchmarks
+
+→ See `samber/cc-skills-golang@golang-benchmark` skill for advanced benchmarking: `b.Loop()` (Go 1.24+), `benchstat`, profiling from benchmarks, and CI regression detection.
+
+Write benchmarks to measure performance and detect regressions:
+
+```go
+func BenchmarkStringConcatenation(b *testing.B) {
+    b.Run("plus-operator", func(b *testing.B) {
+        for b.Loop() {
+            result := "a" + "b" + "c"
+            _ = result
+        }
+    })
+
+    b.Run("strings.Builder", func(b *testing.B) {
+        for b.Loop() {
+            var builder strings.Builder
+            builder.WriteString("a")
+            builder.WriteString("b")
+            builder.WriteString("c")
+            _ = builder.String()
+        }
+    })
+}
+```
+
+Benchmarks with different input sizes:
+
+```go
+func BenchmarkFibonacci(b *testing.B) {
+    sizes := []int{10, 20, 30}
+    for _, size := range sizes {
+        b.Run(fmt.Sprintf("n=%d", size), func(b *testing.B) {
+            b.ReportAllocs()
+            for b.Loop() {
+                Fibonacci(size)
+            }
+        })
+    }
+}
+```
+
+For Go 1.24+, new benchmarks should use `b.Loop()`. Use legacy `b.N` loops only when the module targets Go <1.24 or when preserving old benchmark code intentionally.
+
+### Go 1.26+: test artifacts
+
+When a test, benchmark, or fuzz target needs to persist files for inspection, use `ArtifactDir()` instead of ad-hoc paths or repo-local output.
+
+```go
+func TestRenderGoldenArtifact(t *testing.T) {
+    dir := t.ArtifactDir()
+
+    out := filepath.Join(dir, "rendered.json")
+    if err := os.WriteFile(out, renderedBytes, 0o644); err != nil {
+        t.Fatal(err)
+    }
+
+    t.Logf("artifact written: %s", out)
+}
+```
+
+Available on `*testing.T`, `*testing.B`, and `*testing.F` in Go 1.26+.
+
+## Parallel Tests
+
+Use `t.Parallel()` to run tests concurrently:
+
+```go
+func TestParallelOperations(t *testing.T) {
+    tests := []struct {
+        name string
+        data []byte
+    }{
+        {"small data", make([]byte, 1024)},
+        {"medium data", make([]byte, 1024*1024)},
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            t.Parallel()
+            is := assert.New(t)
+
+            result := Process(tt.data)
+            is.NotNil(result)
+        })
+    }
+}
+```
+
+## Fuzzing
+
+Use fuzzing to find edge cases and bugs:
+
+```go
+func FuzzReverse(f *testing.F) {
+    f.Add("hello")
+    f.Add("")
+    f.Add("a")
+
+    f.Fuzz(func(t *testing.T, input string) {
+        reversed := Reverse(input)
+        doubleReversed := Reverse(reversed)
+        if input != doubleReversed {
+            t.Errorf("Reverse(Reverse(%q)) = %q, want %q", input, doubleReversed, input)
+        }
+    })
+}
+```
+
+## Examples as Documentation
+
+Examples are executable documentation verified by `go test`:
+
+```go
+func ExampleCalculatePrice() {
+    price := CalculatePrice(100, 10.0)
+    fmt.Printf("Price: %.2f\n", price)
+    // Output: Price: 900.00
+}
+
+func ExampleCalculatePrice_singleItem() {
+    price := CalculatePrice(1, 25.50)
+    fmt.Printf("Price: %.2f\n", price)
+    // Output: Price: 25.50
+}
+```
+
+## Code Coverage
+
+```bash
+# Generate coverage file
+go test -coverprofile=coverage.out ./...
+
+# View coverage in HTML
+go tool cover -html=coverage.out
+
+# Coverage by function
+go tool cover -func=coverage.out
+
+# Total coverage percentage
+go tool cover -func=coverage.out | grep total
+```
+
+## Integration Tests
+
+Use build tags to separate integration tests from unit tests:
+
+```go
+//go:build integration
+
+package mypackage
+
+func TestDatabaseIntegration(t *testing.T) {
+    db, err := sql.Open("postgres", os.Getenv("DATABASE_URL"))
+    if err != nil {
+        t.Fatal(err)
+    }
+    defer db.Close()
+
+    // Test real database operations
+}
+```
+
+Run integration tests separately:
+
+```bash
+go test -tags=integration ./...
+```
+
+For Docker Compose fixtures, SQL schemas, and integration test suites, see [Integration Testing](./references/integration-testing.md).
+
+## Mocking
+
+Mock interfaces, not concrete types. Define interfaces where consumed, then create mock implementations.
+
+For mock patterns, test fixtures, and time mocking, see [Mocking](./references/mocking.md).
+
+## Enforce with Linters
+
+Many test best practices are enforced automatically by linters: `thelper`, `paralleltest`, `testifylint`. See the `samber/cc-skills-golang@golang-lint` skill for configuration and usage.
+
+## Cross-References
+
+- -> See `samber/cc-skills-golang@golang-stretchr-testify` skill for detailed testify API (assert, require, mock, suite)
+- -> See `samber/cc-skills-golang@golang-database` skill (testing.md) for database integration test patterns
+- -> See `samber/cc-skills-golang@golang-concurrency` skill for goroutine leak detection with goleak
+- -> See `samber/cc-skills-golang@golang-continuous-integration` skill for CI test configuration and GitHub Actions workflows
+- -> See `samber/cc-skills-golang@golang-lint` skill for testifylint and paralleltest configuration
+- -> See `samber/cc-skills-golang@golang-continuous-integration` skill for automated AI-driven code review in CI using these guidelines
+
+## Quick Reference
+
+```bash
+go test ./...                          # all tests
+go test -run TestName ./...            # specific test by exact name
+go test -run TestName/subtest ./...    # subtests within a test
+go test -run 'Test(Add|Sub)' ./...     # multiple tests (regexp OR)
+go test -run 'Test[A-Z]' ./...         # tests starting with capital letter
+go test -run 'TestUser.*' ./...        # tests matching prefix
+go test -run '.*Validation.*' ./...    # tests containing substring
+go test -run TestName/. ./...          # all subtests of TestName
+go test -run '/(unit|integration)' ./... # filter by subtest name
+go test -race ./...                    # race detection
+go test -cover ./...                   # coverage summary
+go test -bench=. -benchmem ./...       # benchmarks
+go test -fuzz=FuzzName ./...           # fuzzing
+go test -tags=integration ./...        # integration tests
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/evals/evals.json
new file mode 100644
index 00000000..9b80e02b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/evals/evals.json
@@ -0,0 +1,388 @@
+[
+  {
+    "id": 1,
+    "name": "goleak-goroutine-leak-detection",
+    "description": "Tests use goleak for goroutine leak detection, not just task completion",
+    "prompt": "Write tests for a `workerpool` package. The package has a `Pool` struct with `Start(numWorkers int)`, `Submit(task func())`, and `Stop()` methods. Start spawns goroutines, Submit enqueues work, Stop shuts down gracefully. Write comprehensive unit tests covering start, submit tasks, and stop.",
+    "trap": "Model writes normal unit tests verifying task completion but omits goroutine leak detection — Stop() may appear to work while leaking goroutines",
+    "assertions": [
+      {
+        "id": "1.1",
+        "text": "Uses goleak (go.uber.org/goleak) — either goleak.VerifyTestMain in TestMain or goleak.VerifyNone per-test — to detect goroutine leaks from the worker pool"
+      },
+      {
+        "id": "1.2",
+        "text": "Has a TestMain function if using goleak.VerifyTestMain (the package-level approach)"
+      },
+      {
+        "id": "1.3",
+        "text": "Tests verify that Stop() properly cleans up goroutines (not just that tasks complete)"
+      },
+      {
+        "id": "1.4",
+        "text": "Imports go.uber.org/goleak"
+      }
+    ]
+  },
+  {
+    "id": 2,
+    "name": "integration-build-tag-not-testing-short",
+    "description": "Integration tests use //go:build integration tag; testing.Short() is not an acceptable alternative",
+    "prompt": "Our team disagrees on how to separate integration tests from unit tests in our Go project. A teammate proposes:\n\n```go\nfunc TestUserRepository_Create(t *testing.T) {\n    if testing.Short() {\n        t.Skip(\"skipping integration test\")\n    }\n    db := connectToPostgres(t)\n    // ... test ...\n}\n```\n\nThey argue: 'testing.Short() is the Go standard way — it's in the stdlib, you can configure it with -short, and every Go developer knows it. Build tags are extra complexity for no benefit.'\n\nHow should integration tests be separated? Is the teammate's approach correct? Write the correct implementation for a TestUserRepository_Create integration test.",
+    "trap": "Model accepts testing.Short() as a valid approach because it's a stdlib feature and the teammate's argument sounds reasonable. The skill teaches: build tags are required because testing.Short() still compiles tests into the binary, requires a flag to skip, and leaks DB connection attempts into normal test runs.",
+    "assertions": [
+      {
+        "id": "2.1",
+        "text": "Rejects testing.Short() as the primary separation mechanism — does not accept the teammate's approach as correct"
+      },
+      {
+        "id": "2.2",
+        "text": "Uses `//go:build integration` build tag (at the file level, before the package declaration)"
+      },
+      {
+        "id": "2.3",
+        "text": "Explains why build tags are preferred: tests using testing.Short() still compile and attempt connections when running without -short, whereas build-tagged files are completely excluded from compilation"
+      },
+      {
+        "id": "2.4",
+        "text": "Includes the command to run integration tests: go test -tags=integration ./..."
+      }
+    ]
+  },
+  {
+    "id": 3,
+    "name": "parallel-subtests-pure-function",
+    "description": "Pure function subtests call t.Parallel(); top-level test also parallel",
+    "prompt": "Write table-driven tests for a pure function `Slugify(input string) string` that converts titles to URL-friendly slugs (lowercase, hyphens for spaces, strips special chars). Test at least 6 cases: normal title, unicode, multiple spaces, empty string, already-slugified input, and special characters only.",
+    "trap": "Model omits t.Parallel() since the function is pure and 'already fast enough', missing parallelism opportunities for stateless tests",
+    "assertions": [
+      {
+        "id": "3.1",
+        "text": "Subtests call t.Parallel() — these are independent pure function tests with no shared mutable state"
+      },
+      {
+        "id": "3.2",
+        "text": "Top-level test function also calls t.Parallel()"
+      },
+      {
+        "id": "3.3",
+        "text": "Each test case has a descriptive `name` field used in t.Run"
+      },
+      {
+        "id": "3.4",
+        "text": "At least 6 test cases as requested"
+      },
+      {
+        "id": "3.5",
+        "text": "No shared mutable state between subtests (each subtest captures its own test case variable)"
+      }
+    ]
+  },
+  {
+    "id": 4,
+    "name": "fake-clock-injection-for-time-dependent-tests",
+    "description": "Time-dependent code must accept a clock interface so tests can use clockwork.FakeClock; real time.Sleep is unacceptable",
+    "prompt": "Here is an existing RateLimiter implementation:\n\n```go\ntype RateLimiter struct {\n    limit   int\n    window  time.Duration\n    count   int\n    resetAt time.Time\n}\n\nfunc NewRateLimiter(limit int, window time.Duration) *RateLimiter {\n    return &RateLimiter{\n        limit:   limit,\n        window:  window,\n        resetAt: time.Now().Add(window),\n    }\n}\n\nfunc (r *RateLimiter) Allow() bool {\n    now := time.Now()\n    if now.After(r.resetAt) {\n        r.count = 0\n        r.resetAt = now.Add(r.window)\n    }\n    if r.count >= r.limit {\n        return false\n    }\n    r.count++\n    return true\n}\n```\n\nWrite tests that verify:\n1. Allow() returns true while under the limit\n2. Allow() returns false when the limit is exceeded\n3. The counter resets after the time window expires\n\nThe tests must run in milliseconds, not seconds. You may modify the implementation if needed.",
+    "trap": "Model uses time.Sleep(window + small margin) to test window expiration — the code uses time.Now() directly, making tests slow and flaky. The skill teaches to refactor the code to accept a clock interface (clockwork.Clock) and inject a FakeClock in tests.",
+    "assertions": [
+      {
+        "id": "4.1",
+        "text": "Modifies the RateLimiter to accept a clock interface (e.g., clockwork.Clock or a custom Now() func) rather than calling time.Now() directly"
+      },
+      {
+        "id": "4.2",
+        "text": "Uses clockwork.FakeClock (or equivalent) in tests to advance time without real sleeping — tests run in microseconds"
+      },
+      {
+        "id": "4.3",
+        "text": "Tests the window reset scenario by advancing the fake clock past the window duration (e.g., fakeClock.Advance(window + time.Millisecond))"
+      },
+      {
+        "id": "4.4",
+        "text": "No real-time time.Sleep in test code; use synctest.Test/synctest.Wait or a fake clock for deterministic synthetic time"
+      }
+    ]
+  },
+  {
+    "id": 5,
+    "name": "consumer-site-interface-mocking",
+    "description": "Tests define interfaces at the consumer site and mock those, not concrete structs",
+    "prompt": "Test a `NotificationService` struct that has a `NotifyUser(userID string) error` method. It depends on two concrete structs: `SMTPClient` (with `Send(to, subject, body string) error`) and `AuditLogger` (with `Log(event string) error`). NotifyUser looks up the user's email, sends an email via SMTPClient, and logs the event via AuditLogger. Write comprehensive tests for NotifyUser.",
+    "trap": "Model embeds or wraps concrete SMTPClient/AuditLogger in mock structs, or creates test doubles that shadow the concrete types, instead of extracting consumer-site interfaces",
+    "assertions": [
+      {
+        "id": "5.1",
+        "text": "Defines interfaces for the dependencies (e.g., EmailSender, Logger) rather than using the concrete SMTPClient/AuditLogger structs directly in tests"
+      },
+      {
+        "id": "5.2",
+        "text": "Creates mock implementations of these interfaces (using testify/mock or manual mocks)"
+      },
+      {
+        "id": "5.3",
+        "text": "Does NOT embed or wrap the concrete SMTPClient/AuditLogger structs in mock objects"
+      },
+      {
+        "id": "5.4",
+        "text": "Uses dependency injection — NotificationService accepts interfaces, not concrete types"
+      },
+      {
+        "id": "5.5",
+        "text": "Tests verify both happy path (send succeeds) and error scenarios (send fails, log fails)"
+      }
+    ]
+  },
+  {
+    "id": 6,
+    "name": "test-observable-behavior-not-internals",
+    "description": "Tests verify behavior via public API only, not by inspecting the internal map field",
+    "prompt": "Test a `UserCache` struct with `Get(id string) (*User, bool)`, `Set(id string, user *User)`, and `Len() int` methods. The cache has an internal `data map[string]*User` field. Write tests that verify the cache stores and retrieves users correctly. Make sure to verify the internal map state is consistent after each operation.",
+    "trap": "Model directly accesses the internal data map field to verify state, coupling tests to implementation details",
+    "assertions": [
+      {
+        "id": "6.1",
+        "text": "Tests observable behavior through Get/Set/Len public API only"
+      },
+      {
+        "id": "6.2",
+        "text": "Does NOT directly access or inspect the internal `data` map field"
+      },
+      {
+        "id": "6.3",
+        "text": "Does NOT use same-package (white-box) testing to examine cache internals"
+      },
+      {
+        "id": "6.4",
+        "text": "Tests cover cache hit, cache miss, overwrite, and Len() correctness"
+      }
+    ]
+  },
+  {
+    "id": 7,
+    "name": "external-test-package-resists-internal-access",
+    "description": "Tests use package_test to black-box test; does not access unexported state even when a teammate suggests it",
+    "prompt": "Write tests for a `tokenizer` package that exports `Tokenize(input string) []Token` and a `Token` struct with `Type` and `Value` fields. The package has an unexported `tokenCache map[string][]Token` field on the package level for memoization.\n\nA teammate says: 'We should verify the cache is being populated correctly — access tokenCache directly in the tests. It's in the same package so it's fine, and it makes the tests more reliable since we can confirm memoization is working.'\n\nWrite the tests. Should you follow the teammate's suggestion?",
+    "trap": "Model follows the teammate's suggestion and uses package tokenizer (white-box) to access tokenCache directly, reasoning that it makes tests more reliable. The skill teaches to use package tokenizer_test and test only observable behavior — cache behavior is an implementation detail, not a contract.",
+    "assertions": [
+      {
+        "id": "7.1",
+        "text": "Rejects the teammate's suggestion — does not access tokenCache directly in tests"
+      },
+      {
+        "id": "7.2",
+        "text": "Uses `package tokenizer_test` (external test package) instead of `package tokenizer`"
+      },
+      {
+        "id": "7.3",
+        "text": "Explains why: cache behavior is an implementation detail — tests should verify the observable contract (same input → same output), not whether a specific optimization is in place"
+      },
+      {
+        "id": "7.4",
+        "text": "Tests focus on functional correctness: same input tokenizes identically on repeated calls, edge cases, different token types"
+      }
+    ]
+  },
+  {
+    "id": 8,
+    "name": "example-functions-as-documentation",
+    "description": "Packages need Example functions with // Output: comments that serve as executable documentation in go doc",
+    "prompt": "I've written a `currency` package with these functions:\n\n```go\nfunc Format(cents int64, code string) string  // Format(1234, \"USD\") → \"$12.34\"\nfunc Parse(s string) (int64, string, error)   // Parse(\"$12.34\") → 1234, \"USD\", nil\nfunc Convert(cents int64, from, to string, rate float64) int64\n```\n\nA colleague says: 'The functions are self-explanatory — names and signatures are clear enough. We don't need extra documentation. Just write unit tests with good coverage.'\n\nWrite comprehensive test coverage for this package. Should you follow the colleague's advice about documentation?",
+    "trap": "Model follows the colleague's advice and writes only table-driven unit tests without Example functions — missing the executable documentation that shows real usage in `go doc` and on pkg.go.dev. The skill teaches that Example functions serve as both tests and documentation.",
+    "assertions": [
+      {
+        "id": "8.1",
+        "text": "Disagrees with the colleague — includes Example functions despite the advice to skip them"
+      },
+      {
+        "id": "8.2",
+        "text": "Includes at least one Example function (ExampleFormat, ExampleParse, or ExampleConvert)"
+      },
+      {
+        "id": "8.3",
+        "text": "Example functions have `// Output:` comments so they are verified by go test"
+      },
+      {
+        "id": "8.4",
+        "text": "Explains that Example functions serve as executable documentation visible in go doc and pkg.go.dev — not just tests"
+      }
+    ]
+  },
+  {
+    "id": 9,
+    "name": "fuzz-test-for-critical-functions",
+    "description": "Security-critical functions get fuzz tests with seed corpus and property assertions",
+    "prompt": "Write tests for a `SanitizeHTML(input string) string` function that strips all HTML tags from input while preserving text content. Make sure to test edge cases thoroughly — this function is critical for security.",
+    "trap": "Model writes only table-driven tests for known edge cases, missing the fuzz test that would discover unexpected inputs causing XSS vulnerabilities",
+    "assertions": [
+      {
+        "id": "9.1",
+        "text": "Includes a fuzz test function (FuzzSanitizeHTML or similar)"
+      },
+      {
+        "id": "9.2",
+        "text": "Fuzz test uses f.Add() to provide seed corpus entries"
+      },
+      {
+        "id": "9.3",
+        "text": "Fuzz test includes property-based assertions (e.g., output contains no < or > characters, or double-sanitize is idempotent)"
+      },
+      {
+        "id": "9.4",
+        "text": "Also includes regular table-driven tests for known edge cases"
+      },
+      {
+        "id": "9.5",
+        "text": "Table tests cover tricky cases like nested tags, unclosed tags, or script tags"
+      }
+    ]
+  },
+  {
+    "id": 10,
+    "name": "test-helper-t-helper-attribution",
+    "description": "Test helpers must call t.Helper() so failures point to the caller's line, not the helper's internal line",
+    "prompt": "I have this test helper and some tests using it:\n\n```go\nfunc requireNoError(t *testing.T, err error, msg string) {\n    if err != nil {\n        t.Fatalf(\"%s: unexpected error: %v\", msg, err)\n    }\n}\n\nfunc TestProcessOrder(t *testing.T) {\n    order := NewOrder(\"prod-1\", 2)\n    err := order.Validate()\n    requireNoError(t, err, \"validate\")\n\n    err = order.Submit()\n    requireNoError(t, err, \"submit\")\n}\n```\n\nWhen Validate() fails, the test output reports a failure at the `t.Fatalf` line inside `requireNoError`, not at the `requireNoError(t, err, \"validate\")` call site in `TestProcessOrder`. Is this a problem? How do you fix it?",
+    "trap": "Model says this is expected behavior or suggests switching to t.Error() instead of the real fix. The skill teaches that t.Helper() must be called as the first statement in the helper so Go's test framework reports failures at the caller's line.",
+    "assertions": [
+      {
+        "id": "10.1",
+        "text": "Identifies this as a real problem — the line number pointing to the helper's internal Fatalf is unhelpful for debugging which call caused the failure"
+      },
+      {
+        "id": "10.2",
+        "text": "Fixes it by adding t.Helper() as the first statement in requireNoError — not by restructuring the helper or using a different assertion method"
+      },
+      {
+        "id": "10.3",
+        "text": "Explains that t.Helper() marks the function as a test helper so that the testing framework reports the caller's file:line instead of the helper's file:line"
+      },
+      {
+        "id": "10.4",
+        "text": "Does NOT suggest switching to t.Error() as the fix — t.Helper() is the correct solution regardless of t.Fatal vs t.Error"
+      }
+    ]
+  },
+  {
+    "id": 11,
+    "name": "httptest-recorder-not-real-server",
+    "description": "HTTP handler tests use httptest.NewRecorder, not a real HTTP server",
+    "prompt": "Write end-to-end tests for a REST API handler `HandleCreateOrder(w http.ResponseWriter, r *http.Request)` that accepts POST with JSON body `{\"product\": \"...\", \"quantity\": N}`. It returns 201 with the order JSON on success, 400 for invalid JSON, and 422 for validation errors (empty product, quantity <= 0). Test it like a real client would call it.",
+    "trap": "Model starts a real HTTP server with httptest.NewServer or net/http ListenAndServe, adding unnecessary network overhead and port allocation to tests",
+    "assertions": [
+      {
+        "id": "11.1",
+        "text": "Uses httptest.NewRecorder (not httptest.NewServer or a real HTTP server)"
+      },
+      {
+        "id": "11.2",
+        "text": "Table-driven with named test cases covering multiple scenarios"
+      },
+      {
+        "id": "11.3",
+        "text": "Tests at least 3 status codes (201, 400, 422)"
+      },
+      {
+        "id": "11.4",
+        "text": "Verifies response body content (not just status code)"
+      },
+      {
+        "id": "11.5",
+        "text": "Sets proper Content-Type header on requests"
+      }
+    ]
+  },
+  {
+    "id": 12,
+    "name": "testify-suite-for-integration",
+    "description": "Integration tests use testify/suite with SetupSuite/TearDownTest for organized setup/teardown",
+    "prompt": "Write integration tests for an `OrderRepository` that interacts with PostgreSQL. It has `Create(order *Order) error`, `GetByID(id string) (*Order, error)`, and `ListByUserID(userID string) ([]*Order, error)`. Tests need database setup (create tables), per-test data cleanup, and graceful teardown. Organize them cleanly so setup/teardown happens automatically. These must not run during normal unit tests.",
+    "trap": "Model uses TestMain or plain setup functions with defer for teardown, mixing setup concerns into each test instead of a suite",
+    "assertions": [
+      {
+        "id": "12.1",
+        "text": "Uses testify/suite.Suite struct embedding for test organization"
+      },
+      {
+        "id": "12.2",
+        "text": "Has SetupSuite (or similar) for one-time database connection and schema setup"
+      },
+      {
+        "id": "12.3",
+        "text": "Has SetupTest or TearDownTest for per-test data cleanup (e.g., TRUNCATE)"
+      },
+      {
+        "id": "12.4",
+        "text": "Has TearDownSuite for graceful shutdown (close DB, docker-compose down)"
+      },
+      {
+        "id": "12.5",
+        "text": "Uses `//go:build integration` build tag"
+      },
+      {
+        "id": "12.6",
+        "text": "Has a runner function `func TestXxx(t *testing.T) { suite.Run(t, ...) }`"
+      }
+    ]
+  },
+  {
+    "id": 13,
+    "name": "benchmark-report-allocs-and-input-sizes",
+    "description": "Benchmarks use b.ReportAllocs(), test multiple input sizes, and follow naming conventions",
+    "prompt": "Write benchmarks for a `Compress(data []byte) ([]byte, error)` function that compresses byte slices. We need to measure performance to decide if this is fast enough for our hot path. Just write the benchmark tests.",
+    "trap": "Model writes a single benchmark with one input size and omits b.ReportAllocs(), missing allocation tracking and size-scaling analysis",
+    "assertions": [
+      {
+        "id": "13.1",
+        "text": "Calls b.ReportAllocs() to track memory allocations per operation"
+      },
+      {
+        "id": "13.2",
+        "text": "Tests multiple input sizes using b.Run with descriptive sub-benchmark names (e.g., size=1KB, size=1MB)"
+      },
+      {
+        "id": "13.3",
+        "text": "Uses b.Loop() for Go 1.24+ benchmark loops; uses legacy b.N only for older module targets"
+      },
+      {
+        "id": "13.4",
+        "text": "Follows benchmark naming convention: BenchmarkCompress or BenchmarkCompress_<variant>"
+      },
+      {
+        "id": "13.5",
+        "text": "Prevents compiler optimization of the result (assigns to a package-level variable or uses _ =)"
+      },
+      {
+        "id": "13.6",
+        "text": "Does NOT include setup/allocation costs inside the timed loop (or uses b.ResetTimer if setup is needed)"
+      }
+    ]
+  },
+  {
+    "id": 14,
+    "name": "race-detection-and-test-independence",
+    "description": "Tests for concurrent code include -race flag guidance and ensure test independence (no order dependence)",
+    "prompt": "Write tests for a `SafeMap[K comparable, V any]` struct that provides a goroutine-safe map with `Get(key K) (V, bool)`, `Set(key K, value V)`, `Delete(key K)`, and `Len() int` methods. Multiple goroutines will call these concurrently. Write thorough tests including concurrent access scenarios. Also include a note on how to run these tests in CI.",
+    "trap": "Model writes concurrent tests but omits -race flag guidance for CI and doesn't ensure tests are independently runnable (e.g., shares map state between test functions)",
+    "assertions": [
+      {
+        "id": "14.1",
+        "text": "Includes concurrent test scenarios where multiple goroutines call Get/Set/Delete simultaneously"
+      },
+      {
+        "id": "14.2",
+        "text": "Recommends running with -race flag (go test -race) for CI or includes it in a run command comment"
+      },
+      {
+        "id": "14.3",
+        "text": "Each test function creates its own SafeMap instance — no shared state between test functions"
+      },
+      {
+        "id": "14.4",
+        "text": "Uses sync.WaitGroup or similar synchronization to coordinate concurrent test goroutines"
+      },
+      {
+        "id": "14.5",
+        "text": "Tests are independently runnable (any single test can pass when run in isolation with -run)"
+      }
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/helpers.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/helpers.md
new file mode 100644
index 00000000..3c048770
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/helpers.md
@@ -0,0 +1,42 @@
+# Test Helpers
+
+## Test Timeout
+
+For tests that may hang, use a timeout helper that panics with caller location:
+
+```go
+// https://github.com/stretchr/testify/issues/1101
+func testWithTimeout(t *testing.T, timeout time.Duration) {
+    t.Helper()
+
+    testFinished := make(chan struct{})
+    t.Cleanup(func() {
+        close(testFinished)
+    })
+
+    var pc [1]uintptr
+    n := runtime.Callers(2, pc[:])
+    line, funcName := "", ""
+    if n > 0 {
+        frames := runtime.CallersFrames(pc[:])
+        frame, _ := frames.Next()
+        line = frame.File + ":" + strconv.Itoa(frame.Line)
+        funcName = frame.Function
+    }
+
+    go func() {
+        select {
+        case <-testFinished:
+        case <-time.After(timeout):
+            panic(fmt.Sprintf("%s: Test timed out after: %v\n%s", funcName, timeout, line))
+        }
+    }()
+}
+
+// Usage
+func TestLongRunningOperation(t *testing.T) {
+    testWithTimeout(t, 2*time.Second)
+    result := LongRunningOperation()
+    // If this takes longer than 2 seconds, the test panics with location info
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/http-testing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/http-testing.md
new file mode 100644
index 00000000..a7ff122f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/http-testing.md
@@ -0,0 +1,84 @@
+# HTTP Handler Testing
+
+Use `httptest` package for testing HTTP handlers without starting a server.
+
+## Basic Handler Test
+
+```go
+func TestCreateUserHandler(t *testing.T) {
+    tests := []struct {
+        name           string
+        body           string
+        expectedStatus int
+    }{
+        {
+            name:           "valid request",
+            body:           `{"name": "Alice", "email": "alice@example.com"}`,
+            expectedStatus: http.StatusCreated,
+        },
+        {
+            name:           "invalid JSON",
+            body:           `invalid json`,
+            expectedStatus: http.StatusBadRequest,
+        },
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            is := assert.New(t)
+
+            req := httptest.NewRequest(http.MethodPost, "/users", strings.NewReader(tt.body))
+            req.Header.Set("Content-Type", "application/json")
+
+            w := httptest.NewRecorder()
+            handler := http.HandlerFunc(CreateUserHandler)
+            handler.ServeHTTP(w, req)
+
+            is.Equal(tt.expectedStatus, w.Code)
+        })
+    }
+}
+```
+
+## Query Parameters and Headers
+
+```go
+func TestListUsersHandler(t *testing.T) {
+    tests := []struct {
+        name           string
+        query          string
+        authHeader     string
+        expectedStatus int
+    }{
+        {
+            name:           "paginated results",
+            query:          "?page=1&limit=10",
+            authHeader:     "Bearer token123",
+            expectedStatus: http.StatusOK,
+        },
+        {
+            name:           "missing auth",
+            query:          "?page=1",
+            authHeader:     "",
+            expectedStatus: http.StatusUnauthorized,
+        },
+    }
+
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            is := assert.New(t)
+
+            req := httptest.NewRequest(http.MethodGet, "/users"+tt.query, nil)
+            if tt.authHeader != "" {
+                req.Header.Set("Authorization", tt.authHeader)
+            }
+
+            w := httptest.NewRecorder()
+            handler := AuthMiddleware(ListUsersHandler)
+            handler.ServeHTTP(w, req)
+
+            is.Equal(tt.expectedStatus, w.Code)
+        })
+    }
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/integration-testing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/integration-testing.md
new file mode 100644
index 00000000..ef2cadf4
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/integration-testing.md
@@ -0,0 +1,187 @@
+# Integration Testing
+
+## Docker Compose Fixture
+
+Create `pkg/myfeature/testdata/docker-compose.yml` for test services:
+
+```yaml
+version: "3.8"
+services:
+  postgres:
+    image: postgres:16-alpine
+    environment:
+      POSTGRES_USER: test
+      POSTGRES_PASSWORD: test
+      POSTGRES_DB: testdb
+    ports:
+      - "5433:5432"
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U test"]
+      interval: 5s
+      timeout: 5s
+      retries: 5
+
+  redis:
+    image: redis:7-alpine
+    ports:
+      - "6380:6379"
+    healthcheck:
+      test: ["CMD", "redis-cli", "ping"]
+      interval: 5s
+      timeout: 5s
+      retries: 5
+```
+
+## SQL Schema Fixture
+
+Create `pkg/myfeature/testdata/schema.sql` for database initialization:
+
+```sql
+CREATE TABLE IF NOT EXISTS users (
+    id SERIAL PRIMARY KEY,
+    name VARCHAR(255) NOT NULL,
+    email VARCHAR(255) UNIQUE NOT NULL,
+    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
+);
+
+CREATE TABLE IF NOT EXISTS orders (
+    id SERIAL PRIMARY KEY,
+    user_id INTEGER REFERENCES users(id),
+    amount DECIMAL(10,2) NOT NULL,
+    status VARCHAR(50) DEFAULT 'pending',
+    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
+);
+```
+
+## Test Data Fixture
+
+Create `pkg/myfeature/testdata/testdata.sql`:
+
+```sql
+INSERT INTO users (name, email) VALUES
+    ('Alice Johnson', 'alice@example.com'),
+    ('Bob Smith', 'bob@example.com'),
+    ('Charlie Brown', 'charlie@example.com');
+
+INSERT INTO orders (user_id, amount, status) VALUES
+    (1, 100.00, 'completed'),
+    (1, 50.00, 'pending'),
+    (2, 200.00, 'completed');
+```
+
+## Using Fixtures in Tests
+
+```go
+//go:build integration
+
+package database_test
+
+import (
+    "database/sql"
+    "os"
+    "os/exec"
+    "testing"
+    "time"
+    "github.com/stretchr/testify/assert"
+    "github.com/stretchr/testify/suite"
+)
+
+type DatabaseTestSuite struct {
+    suite.Suite
+    db *sql.DB
+}
+
+func (s *DatabaseTestSuite) SetupSuite() {
+    cmd := exec.Command("docker-compose", "-f", "testdata/docker-compose.yml", "up", "-d")
+    if err := cmd.Run(); err != nil {
+        s.T().Fatalf("failed to start docker-compose: %v", err)
+    }
+
+    time.Sleep(5 * time.Second)
+
+    db, err := sql.Open("postgres", "postgres://test:test@localhost:5433/testdb?sslmode=disable")
+    if err != nil {
+        s.T().Fatalf("failed to connect to database: %v", err)
+    }
+    s.db = db
+
+    schema, _ := os.ReadFile("testdata/schema.sql")
+    _, err = db.Exec(string(schema))
+    if err != nil {
+        s.T().Fatalf("failed to run schema: %v", err)
+    }
+}
+
+func (s *DatabaseTestSuite) TearDownSuite() {
+    cmd := exec.Command("docker-compose", "-f", "testdata/docker-compose.yml", "down", "-v")
+    _ = cmd.Run()
+}
+
+func (s *DatabaseTestSuite) SetupTest() {
+    _, err := s.db.Exec("TRUNCATE TABLE orders, users CASCADE")
+    if err != nil {
+        s.T().Fatalf("failed to clear database: %v", err)
+    }
+
+    testdata, _ := os.ReadFile("testdata/testdata.sql")
+    _, err = s.db.Exec(string(testdata))
+    if err != nil {
+        s.T().Fatalf("failed to load test data: %v", err)
+    }
+}
+
+func (s *DatabaseTestSuite) TestUserCount() {
+    is := assert.New(s.T())
+
+    var count int
+    err := s.db.QueryRow("SELECT COUNT(*) FROM users").Scan(&count)
+    is.NoError(err)
+    is.Equal(3, count)
+}
+
+func (s *DatabaseTestSuite) TestOrderSum() {
+    is := assert.New(s.T())
+
+    var sum float64
+    err := s.db.QueryRow("SELECT SUM(amount) FROM orders").Scan(&sum)
+    is.NoError(err)
+    is.InDelta(350.0, sum, 0.01)
+}
+
+func TestDatabaseTestSuite(t *testing.T) {
+    suite.Run(t, new(DatabaseTestSuite))
+}
+```
+
+## Test Helper with Embedded Fixtures
+
+```go
+package myfeature
+
+import (
+    "database/sql"
+    "embed"
+)
+
+//go:embed testdata/schema.sql testdata/testdata.sql
+var fixtures embed.FS
+
+func SetupDB(db *sql.DB) error {
+    schema, err := fixtures.ReadFile("testdata/schema.sql")
+    if err != nil {
+        return err
+    }
+    if _, err := db.Exec(string(schema)); err != nil {
+        return err
+    }
+
+    data, err := fixtures.ReadFile("testdata/testdata.sql")
+    if err != nil {
+        return err
+    }
+    if _, err := db.Exec(string(data)); err != nil {
+        return err
+    }
+    return nil
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/mocking.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/mocking.md
new file mode 100644
index 00000000..1b6e8371
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-testing/references/mocking.md
@@ -0,0 +1,206 @@
+# Mocking and Test Fixtures
+
+## Mocks with testify/mock
+
+Create interfaces for your dependencies, then mock them.
+
+> For the full testify/mock API (argument matchers, call modifiers, verification), see the `samber/cc-skills-golang@golang-stretchr-testify` skill.
+
+```go
+// Define the interface
+type Database interface {
+    GetUser(id string) (*User, error)
+    CreateUser(user *User) error
+}
+
+// Mock implementation
+type MockDatabase struct {
+    mock.Mock
+}
+
+func (m *MockDatabase) GetUser(id string) (*User, error) {
+    args := m.Called(id)
+    if args.Get(0) == nil {
+        return nil, args.Error(1)
+    }
+    return args.Get(0).(*User), args.Error(1)
+}
+
+func (m *MockDatabase) CreateUser(user *User) error {
+    args := m.Called(user)
+    return args.Error(0)
+}
+
+// Usage in tests
+func TestService_GetUser(t *testing.T) {
+    is := assert.New(t)
+
+    mockDB := new(MockDatabase)
+    service := NewService(mockDB)
+
+    expectedUser := &User{ID: "1", Name: "John"}
+    mockDB.On("GetUser", "1").Return(expectedUser, nil)
+
+    user, err := service.GetUser("1")
+
+    is.NoError(err)
+    is.Equal(expectedUser, user)
+    mockDB.AssertExpectations(t)
+}
+
+func TestService_GetUser_NotFound(t *testing.T) {
+    is := assert.New(t)
+
+    mockDB := new(MockDatabase)
+    service := NewService(mockDB)
+
+    mockDB.On("GetUser", "999").Return(nil, ErrNotFound)
+
+    user, err := service.GetUser("999")
+
+    is.Error(err)
+    is.ErrorIs(err, ErrNotFound)
+    is.Nil(user)
+    mockDB.AssertExpectations(t)
+}
+```
+
+## Mock Organization
+
+For larger codebases, organize mocks alongside the code they mock:
+
+```go
+// user_service.go
+type UserService struct {
+    db    Database
+    email EmailService
+}
+type Database interface {
+    GetUser(id string) (*User, error)
+    CreateUser(user *User) error
+}
+type EmailService interface {
+    SendWelcomeEmail(to string) error
+}
+```
+
+```go
+// user_service_test.go
+package mypackage_test
+
+import (
+    "testing"
+    "github.com/stretchr/testify/assert"
+    "github.com/stretchr/testify/mock"
+    "path/to/mypackage"
+)
+
+// MockDatabase implements mypackage.Database
+type MockDatabase struct {
+    mock.Mock
+}
+func (m *MockDatabase) GetUser(id string) (*mypackage.User, error) {
+    args := m.Called(id)
+    if args.Get(0) == nil { return nil, args.Error(1) }
+    return args.Get(0).(*mypackage.User), args.Error(1)
+}
+func (m *MockDatabase) CreateUser(user *mypackage.User) error {
+    return m.Called(user).Error(0)
+}
+
+// MockEmailService implements mypackage.EmailService
+type MockEmailService struct {
+    mock.Mock
+}
+func (m *MockEmailService) SendWelcomeEmail(to string) error {
+    return m.Called(to).Error(0)
+}
+
+func TestUserService_CreateUser(t *testing.T) {
+    mockDB := new(MockDatabase)
+    mockEmail := new(MockEmailService)
+    service := mypackage.NewUserService(mockDB, mockEmail)
+
+    user := &mypackage.User{Name: "Test", Email: "test@example.com"}
+    mockDB.On("CreateUser", user).Return(nil)
+    mockEmail.On("SendWelcomeEmail", "test@example.com").Return(nil)
+
+    err := service.CreateUser(user)
+
+    assert.NoError(t, err)
+    mockDB.AssertExpectations(t)
+    mockEmail.AssertExpectations(t)
+}
+```
+
+## Test Fixtures
+
+Create reusable test data in a separate package or file:
+
+```go
+package fixtures
+
+import "time"
+
+var (
+    DefaultUser = &User{
+        ID:        "user-123",
+        Name:      "Jane Doe",
+        Email:     "jane@example.com",
+        CreatedAt: time.Date(2024, 1, 1, 0, 0, 0, 0, time.UTC),
+    }
+
+    AdminUser = &User{
+        ID:        "admin-1",
+        Name:      "Admin User",
+        Email:     "admin@example.com",
+        Role:      "admin",
+        CreatedAt: time.Date(2024, 1, 1, 0, 0, 0, 0, time.UTC),
+    }
+)
+
+func NewUser(name, email string) *User {
+    return &User{
+        ID:        "user-" + uuid.New().String(),
+        Name:      name,
+        Email:     email,
+        CreatedAt: time.Now(),
+    }
+}
+```
+
+## Time Mocking
+
+Use `clockwork` to test time-dependent code without `time.Sleep()`:
+
+```go
+import (
+    "testing"
+    "time"
+    "github.com/jonboulle/clockwork"
+    "github.com/stretchr/testify/assert"
+)
+
+func TestScheduler_AddJob(t *testing.T) {
+    is := assert.New(t)
+
+    fakeClock := clockwork.NewFakeClock()
+    scheduler := NewScheduler(fakeClock)
+
+    job := &Job{ID: "1", RunAt: time.Now().Add(1 * time.Hour)}
+    scheduler.AddJob(job)
+
+    is.Equal(1, scheduler.PendingCount())
+
+    // Advance fake time
+    fakeClock.Advance(2 * time.Hour)
+
+    is.Equal(0, scheduler.PendingCount())
+}
+```
+
+Install clockwork:
+
+```bash
+go get github.com/jonboulle/clockwork
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/SKILL.md
new file mode 100644
index 00000000..9830acbc
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/SKILL.md
@@ -0,0 +1,192 @@
+---
+name: golang-troubleshooting
+description: "Troubleshoot Golang programs systematically - find and fix the root cause. Use when encountering bugs, crashes, deadlocks, or unexpected behavior in Go code. Covers debugging methodology, common Go pitfalls, test-driven debugging, pprof setup and capture, Delve debugger, race detection, GODEBUG tracing, and production debugging. Start here for any 'something is wrong' situation. Not for interpreting profiles or benchmarking (→ See `samber/cc-skills-golang@golang-benchmark` skill) or applying optimization patterns (→ See `samber/cc-skills-golang@golang-performance` skill)."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.2.2"
+  openclaw:
+    emoji: "🔍"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+        - dlv
+    install:
+      - kind: go
+        package: github.com/go-delve/delve/cmd/dlv@latest
+        bins: [dlv]
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Bash(dlv:*) Agent WebFetch WebSearch AskUserQuestion
+---
+
+**Persona:** You are a Go systems debugger. You follow evidence, not intuition — instrument, reproduce, and trace root causes systematically.
+
+**Thinking mode:** Use `ultrathink` for debugging and root cause analysis. Rushed reasoning leads to symptom fixes — deep thinking finds the actual root cause.
+
+**Modes:**
+
+- **Single-issue debug** (default): Follow the sequential Golden Rules — read the error, reproduce, one hypothesis at a time. Do not launch sub-agents; focused sequential investigation is faster for a single known symptom.
+- **Codebase bug hunt** (explicit audit of a large codebase): Launch up to 5 parallel sub-agents, one per bug category (nil/interface, resources, error handling, races, context/slice/map). Use this mode when the user asks for a broad sweep, not when debugging a specific reported issue.
+
+**Dependencies:**
+
+- dlv: `go install github.com/go-delve/delve/cmd/dlv@latest`
+
+# Go Troubleshooting Guide
+
+**NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.** Symptom fixes create new bugs and waste time. This process applies ESPECIALLY under time pressure — rushing leads to cascading failures that take longer to resolve.
+
+When the user reports a bug, crash, performance problem, or unexpected behavior in Go code:
+
+1. **Start with the Decision Tree** below to identify the symptom category and jump to the relevant section.
+2. **Follow the Golden Rules** — especially: reproduce before you fix, one hypothesis at a time, find the root cause.
+3. **Work through the General Debugging Methodology** step by step. Do not skip steps.
+4. **Watch for Red Flags** in your own reasoning. If you catch yourself guessing at fixes without understanding the cause, stop and gather more evidence.
+5. **Escalate tools incrementally.** Start with the simplest diagnostic (`fmt.Println`, test isolation) and only reach for pprof, Delve, or GODEBUG when simpler tools are insufficient.
+6. **Never propose a fix you cannot explain.** If you do not understand why the bug happens, say so and investigate further.
+
+## Quick Decision Tree
+
+```
+WHAT ARE YOU SEEING?
+
+"Build won't compile"
+  → go build ./... 2>&1, go vet ./...
+  → See [compilation.md](./references/compilation.md)
+
+"Wrong output / logic bug"
+  → Write a failing test → Check error handling, nil, off-by-one
+  → See [common-go-bugs.md](./references/common-go-bugs.md), [testing-debug.md](./references/testing-debug.md)
+
+"Random crashes / panics"
+  → GOTRACEBACK=all ./app → go test -race ./...
+  → See [common-go-bugs.md](./references/common-go-bugs.md), [diagnostic-tools.md](./references/diagnostic-tools.md)
+
+"Sometimes works, sometimes fails"
+  → go test -race ./...
+  → See [concurrency-debug.md](./references/concurrency-debug.md), [testing-debug.md](./references/testing-debug.md)
+
+"Program hangs / frozen"
+  → curl localhost:6060/debug/pprof/goroutine?debug=2
+  → See [concurrency-debug.md](./references/concurrency-debug.md), [pprof.md](./references/pprof.md)
+
+"High CPU usage"
+  → pprof CPU profiling
+  → See [performance-debug.md](./references/performance-debug.md), [pprof.md](./references/pprof.md)
+
+"Memory growing over time"
+  → pprof heap profiling
+  → See [performance-debug.md](./references/performance-debug.md), [concurrency-debug.md](./references/concurrency-debug.md)
+
+"Slow / high latency / p99 spikes"
+  → CPU + mutex + block profiles
+  → See [performance-debug.md](./references/performance-debug.md), [diagnostic-tools.md](./references/diagnostic-tools.md)
+
+"Simple bug, easy to reproduce"
+  → Write a test, add fmt.Println / log.Debug
+  → See [testing-debug.md](./references/testing-debug.md)
+```
+
+**Remember:** Read the Error → Reproduce → Measure One Thing → Fix → Verify
+
+Most Go bugs are: missing error checks, nil pointers, forgotten context cancel, unclosed resources, race conditions, or silent error swallowing.
+
+## The Golden Rules
+
+### 1. Read the Error Message First
+
+Go error messages are precise. Read them fully before doing anything else:
+
+- **File and line number** → go directly there
+- **Type mismatch** → check function signatures, interface satisfaction
+- **"undefined"** → check imports, exported names, build tags
+- **"cannot use X as Y"** → check concrete types vs interfaces
+
+### 2. Reproduce Before You Fix
+
+NEVER debug by guessing — reproduce first. Always:
+
+- Write a failing test that captures the bug
+- Make it deterministic
+- Isolate the minimal failing example
+- Use `git bisect` to find the breaking commit
+
+### 3. If You Don't Measure It, You're Guessing
+
+Never rely on intuition for performance or concurrency bugs:
+
+- **pprof over intuition**
+- **race detector over reasoning**
+- **benchmarks over assumptions**
+
+### 4. One Hypothesis at a Time
+
+Change one thing, measure, confirm. If you change three things at once, you learn nothing.
+
+### 5. Find the Root Cause — No Workarounds
+
+A band-aid fix that masks the symptom IS NOT ACCEPTABLE. You MUST understand **why** the bug happens before writing a fix.
+
+When you don't understand the issue:
+
+- **Trace the data flow backwards** from the symptom to its origin.
+- **Question your assumptions.** The code you trust might be wrong.
+- **Ask "why" five times.** Keep going until you reach the actual root cause.
+- **Perform more troubleshooting checks.** More fmt.Println, more output inspection...
+
+### 6. Research the Codebase, Not Just the Diff
+
+Before flagging a bug or proposing a fix, trace the data flow and check for upstream handling. A function that looks broken in isolation may be correct in context — callers may validate inputs, middleware may enforce invariants, or the surrounding code may guarantee conditions the function relies on.
+
+1. **Trace callers** — who calls this function and with what values? Call sites can be found with code search tools.
+2. **Check upstream validation** — input parsing, type conversions, or guard clauses earlier in the chain may make the "bug" unreachable.
+3. **Read the surrounding code** — middleware, interceptors, or init functions may set up state the function depends on.
+
+**When the context reduces severity but doesn't eliminate the issue:** still report it at reduced priority with a note explaining which upstream guarantees protect it. Add a brief inline comment (e.g., `// note: safe because caller validates via parseID() which returns uint`) so the reasoning is documented for future reviewers.
+
+### 7. Start Simple
+
+Sometimes `fmt.Println` IS the right tool for local debugging. Escalate tools only when simpler approaches fail. NEVER use `fmt.Println` for production debugging — use `slog`.
+
+## Red Flags: You're Debugging Wrong
+
+If any of these are happening, stop and return to Step 1:
+
+- **"Quick fix for now, investigate later"** — There is no "later". Find the root cause.
+- **Multiple simultaneous changes** — One hypothesis at a time.
+- **Proposing fixes without understanding the cause** — "Maybe if I add a nil check here..." is guessing, not debugging.
+- **Each fix reveals a new problem** — You're treating symptoms. The real bug is elsewhere.
+- **3+ fix attempts on the same issue** — You have the wrong mental model. Re-read the code, trace the data flow from scratch.
+- **"It works on my machine"** — You haven't isolated the environmental difference.
+- **Blaming the framework/stdlib/compiler** — It's almost never a Go bug. Verify your code first.
+
+## Reference Files
+
+- **[General Debugging Methodology](./references/methodology.md)** — The systematic 10-step process: define symptoms, isolate reproduction, form one hypothesis, test it, verify the root cause, and defend against regressions. Escalation guide: when to escalate from `fmt.Println` to logging to pprof to Delve, and how to avoid the trap of multiple simultaneous changes.
+
+- **[Common Go Bugs](./references/common-go-bugs.md)** — The bugs that crash Go code: nil pointer dereferences, interface nil gotcha (typed nil ≠ nil), variable shadowing, slice/map/defer/error/context pitfalls, race conditions, JSON unmarshaling surprises, unclosed resources. Each with reproduction patterns and fixes.
+
+- **[Test-Driven Debugging](./references/testing-debug.md)** — Why writing a failing test is the first step of debugging. Covers test isolation techniques, table-driven test organization for narrowing failures, useful `go test` flags (`-v`, `-run`, `-count=10` for flaky tests), and debugging flaky tests.
+
+- **[Concurrency Debugging](./references/concurrency-debug.md)** — Race conditions, deadlocks, goroutine leaks. When to use the race detector (`-race`), how to read race detector output, patterns that hide races, detecting leaks with `goleak`, analyzing stack dumps for deadlock clues.
+
+- **[Performance Troubleshooting](./references/performance-debug.md)** — When your code is slow: CPU profiling workflow, memory analysis (heap vs alloc_objects profiles, finding leaks), lock contention (mutex profile), and I/O blocking (goroutine profile). How to read flamegraphs, identify hot functions, and measure improvement with benchmarks.
+
+- **[pprof Reference](./references/pprof.md)** — Complete pprof manual. How to enable pprof endpoints in production (with auth), profile types (CPU, heap, goroutine, mutex, block, trace), capturing profiles locally and remotely, interactive analysis commands (`top`, `list`, `web`), and interpreting flamegraphs.
+
+- **[Diagnostic Tools](./references/diagnostic-tools.md)** — Auxiliary tools for specific symptoms. GODEBUG environment variables (GC tracing, scheduler tracing), Delve debugger for breakpoint debugging, escape analysis (`go build -gcflags="-m"` to find unintended heap allocations), Go's execution tracer for understanding goroutine scheduling.
+
+- **[Production Debugging](./references/production-debug.md)** — Debugging live production systems without stopping them. Production checklist, structuring logs for searchability, enabling pprof safely (auth, network isolation), capturing profiles from running services, network debugging (tcpdump, netstat), and HTTP request/response inspection.
+
+- **[Compilation Issues](./references/compilation.md)** — Build failures: module version conflicts, CGO linking problems, version mismatch between `go.mod` and installed Go version, platform-specific build tags preventing cross-compilation.
+
+- **[Code Review Red Flags](./references/code-review-flags.md)** — Patterns to watch during code review that signal potential bugs: unchecked errors, missing nil checks, concurrent map access, goroutines without clear exit, resource leaks from defer in loops.
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-performance` skill for optimization patterns after identifying bottlenecks
+- → See `samber/cc-skills-golang@golang-observability` skill for metrics, alerting, and Grafana dashboards for Go runtime monitoring
+- → See `samber/cc-skills@promql-cli` skill for querying Prometheus metrics during production incident investigation
+- → See `samber/cc-skills-golang@golang-concurrency`, `samber/cc-skills-golang@golang-safety`, `samber/cc-skills-golang@golang-error-handling` skills
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/evals/evals.json
new file mode 100644
index 00000000..acd10244
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/evals/evals.json
@@ -0,0 +1,521 @@
+[
+  {
+    "id": 1,
+    "name": "reproduce-before-fix-failing-test-first",
+    "description": "Tests Golden Rule #2: model must write a failing test before proposing any fix, not jump to code changes",
+    "prompt": "My Go HTTP handler returns 500 for some requests but I can't figure out which ones. The handler parses a JSON body with `json.NewDecoder(r.Body).Decode(&req)` and then calls `processOrder(req)`. Some users report getting 500 errors. Can you fix this?",
+    "trap": "Model jumps directly to adding nil checks or error handling in the handler code without first writing a test that reproduces the failure",
+    "assertions": [
+      {"id": "1.1", "text": "Writes a failing test (or proposes writing one) BEFORE suggesting any code fix"},
+      {"id": "1.2", "text": "Test covers multiple input variations to identify which inputs trigger the 500"},
+      {"id": "1.3", "text": "Does NOT propose a fix without first understanding/reproducing the root cause"},
+      {"id": "1.4", "text": "Asks clarifying questions about the error (logs, request bodies, frequency) or proposes to gather evidence"},
+      {"id": "1.5", "text": "Mentions running the test to confirm it reproduces the issue before fixing"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "one-hypothesis-at-a-time",
+    "description": "Tests Golden Rule #4: change one thing and measure, not multiple simultaneous changes",
+    "prompt": "My Go web service is slow and sometimes returns errors. I think it might be the database queries, or maybe the JSON marshaling, or possibly goroutine contention. Can you fix all three at once to save time? Add connection pooling, switch to a faster JSON library, and add mutexes around shared state.",
+    "trap": "Model applies all three fixes simultaneously as requested, violating the one-hypothesis-at-a-time rule",
+    "assertions": [
+      {"id": "2.1", "text": "Refuses or strongly advises against making all three changes simultaneously"},
+      {"id": "2.2", "text": "Recommends measuring/profiling first to identify which problem is actually causing the symptoms"},
+      {"id": "2.3", "text": "Suggests testing one hypothesis at a time with measurement between changes"},
+      {"id": "2.4", "text": "Mentions pprof, benchmarks, or race detector as diagnostic tools to identify the real bottleneck"},
+      {"id": "2.5", "text": "Explains why multiple simultaneous changes are harmful (can't tell what worked, may introduce new bugs)"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "root-cause-not-symptom-fix",
+    "description": "Tests Golden Rule #5 and Step 8: fix at the source where bad data originates, not where the panic occurs",
+    "prompt": "My Go HTTP server panics with `nil pointer dereference` in the handler when accessing `s.db.Query(...)`. I added a nil check `if s.db == nil { return }` but now the handler silently returns empty responses. How do I fix this properly?",
+    "trap": "Model suggests improving the nil check (better error message, logging) rather than tracing to the root cause — why is s.db nil in the first place",
+    "assertions": [
+      {"id": "3.1", "text": "Identifies that the nil check in the handler is a symptom fix, not the root cause"},
+      {"id": "3.2", "text": "Traces backward to the constructor/initialization code to find why db is nil"},
+      {"id": "3.3", "text": "Suggests validating db != nil in the constructor (e.g., NewServer) and failing fast there"},
+      {"id": "3.4", "text": "Does NOT suggest improving the nil check in the handler as the primary fix"},
+      {"id": "3.5", "text": "Explains that fixing at the symptom location masks the real bug"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "interface-nil-gotcha",
+    "description": "Tests the interface nil gotcha from common-go-bugs: typed nil in interface is not nil",
+    "prompt": "I have this Go code and the error branch always executes even though no error occurred. Debug this:\n\n```go\ntype ValidationError struct{ Field string }\nfunc (e *ValidationError) Error() string { return e.Field + \" invalid\" }\n\nfunc validate(s string) error {\n    var verr *ValidationError\n    if s == \"\" {\n        verr = &ValidationError{Field: \"name\"}\n    }\n    return verr\n}\n\nfunc main() {\n    if err := validate(\"hello\"); err != nil {\n        fmt.Println(\"error:\", err) // This always prints!\n    }\n}\n```",
+    "trap": "Model suggests adding a nil check on verr before returning, or restructuring the if/else, without explaining the interface nil gotcha",
+    "assertions": [
+      {"id": "4.1", "text": "Identifies the interface nil gotcha: a typed nil *ValidationError wrapped in an error interface is NOT a nil interface"},
+      {"id": "4.2", "text": "Explains that the interface has a non-nil type descriptor even when the pointer value is nil"},
+      {"id": "4.3", "text": "Recommends returning nil explicitly (return nil) instead of returning the typed nil variable"},
+      {"id": "4.4", "text": "Does NOT suggest adding an if verr == nil check before return as the primary fix — the correct fix is to return nil explicitly when there's no error"},
+      {"id": "4.5", "text": "Shows or describes the correct fix: check verr != nil before return, and return nil in the else branch"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "variable-shadowing-err",
+    "description": "Tests the variable shadowing with := from common-go-bugs: inner err shadows outer err",
+    "prompt": "My Go function always returns nil error even when someFunc() fails. I verified that someFunc() does return errors in certain cases. What's wrong?\n\n```go\nfunc processData() error {\n    var err error\n    if needsProcessing {\n        result, err := someFunc()\n        if err != nil {\n            return err\n        }\n        use(result)\n    }\n    return err\n}\n```",
+    "trap": "Model focuses on the early return path working correctly and misses that the outer err is always nil because := created a new variable",
+    "assertions": [
+      {"id": "5.1", "text": "Identifies that := inside the if block creates a NEW err variable that shadows the outer one"},
+      {"id": "5.2", "text": "Explains that the outer err remains nil because the inner := never assigned to it"},
+      {"id": "5.3", "text": "Recommends using = (assignment) instead of := to assign to the outer err variable"},
+      {"id": "5.4", "text": "Shows the fix: declare result separately (var result ResultType) and use result, err = someFunc()"},
+      {"id": "5.5", "text": "Mentions the golang.org/x/tools shadow analyzer as a detection tool, without relying on the obsolete go vet shadow flag"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "defer-in-loop-resource-leak",
+    "description": "Tests the defer-in-loop gotcha from common-go-bugs: deferred calls pile up until function returns",
+    "prompt": "My Go program runs out of file descriptors when processing a large directory of files. Here's the code:\n\n```go\nfunc processFiles(paths []string) error {\n    for _, p := range paths {\n        f, err := os.Open(p)\n        if err != nil {\n            return err\n        }\n        defer f.Close()\n        data, err := io.ReadAll(f)\n        if err != nil {\n            return err\n        }\n        process(data)\n    }\n    return nil\n}\n```\nIt works for small directories but crashes with 'too many open files' for large ones.",
+    "trap": "Model suggests increasing the file descriptor limit (ulimit) instead of fixing the defer-in-loop bug",
+    "assertions": [
+      {"id": "6.1", "text": "Identifies that defer f.Close() inside a for loop keeps all files open until the function returns"},
+      {"id": "6.2", "text": "Recommends wrapping the loop body in an anonymous function (closure) so defer runs each iteration"},
+      {"id": "6.3", "text": "Does NOT suggest increasing ulimit or file descriptor limits as the primary solution"},
+      {"id": "6.4", "text": "Shows the correct pattern with func() { f, err := os.Open(...); defer f.Close(); ... }()"},
+      {"id": "6.5", "text": "Alternatively suggests extracting the loop body into a named function"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "break-in-select-inside-for-loop",
+    "description": "Tests the break-in-select gotcha: bare break only exits select, not the enclosing for loop",
+    "prompt": "My Go program's message consumer loop never terminates. When I send 'quit' on the channel, the loop keeps running. What's wrong?\n\n```go\nfor {\n    select {\n    case msg := <-ch:\n        if msg == \"quit\" {\n            log.Println(\"shutting down\")\n            break\n        }\n        handleMessage(msg)\n    case <-ctx.Done():\n        break\n    }\n}\n```",
+    "trap": "Model suggests the channel isn't receiving 'quit' or there's a timing issue, rather than identifying the break-in-select gotcha",
+    "assertions": [
+      {"id": "7.1", "text": "Identifies that break inside a select only exits the select statement, not the for loop"},
+      {"id": "7.2", "text": "Recommends using a labeled break (e.g., break loop) with a label on the for statement"},
+      {"id": "7.3", "text": "Shows the correct pattern with a label like 'loop:' on the for statement and 'break loop' inside select"},
+      {"id": "7.4", "text": "Also fixes the ctx.Done() case which has the same break issue"},
+      {"id": "7.5", "text": "Alternatively mentions return as a solution if the function should exit entirely"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "concurrent-map-fatal-not-panic",
+    "description": "Tests knowledge that concurrent map access is a fatal error that cannot be recovered, unlike most panics",
+    "prompt": "My Go web server occasionally crashes despite having a recover() middleware that catches panics. The error message says 'concurrent map read and map write'. I thought recover() catches all panics — why isn't it working? How should I protect against this?",
+    "trap": "Model suggests the recover middleware is misconfigured or needs to be higher in the middleware chain, rather than explaining that concurrent map access is fatal and unrecoverable",
+    "assertions": [
+      {"id": "8.1", "text": "Explains that concurrent map read/write is a FATAL error that cannot be caught by recover()"},
+      {"id": "8.2", "text": "Distinguishes this from regular panics — the Go runtime kills the process immediately"},
+      {"id": "8.3", "text": "Recommends protecting the map with sync.RWMutex or using sync.Map"},
+      {"id": "8.4", "text": "Recommends using go test -race to find the race condition"},
+      {"id": "8.5", "text": "Does NOT suggest fixing the recover middleware as the solution"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "waitgroup-add-inside-goroutine",
+    "description": "Tests the WaitGroup.Add placement gotcha: Add inside goroutine races with Wait",
+    "prompt": "My Go test passes most of the time but occasionally fails with 'expected 10 results, got 7' (or some other number less than 10). The code launches goroutines to process items in parallel:\n\n```go\nvar wg sync.WaitGroup\nresults := make([]int, 0, 10)\nvar mu sync.Mutex\nfor i := 0; i < 10; i++ {\n    go func(n int) {\n        wg.Add(1)\n        defer wg.Done()\n        val := process(n)\n        mu.Lock()\n        results = append(results, val)\n        mu.Unlock()\n    }(i)\n}\nwg.Wait()\n```",
+    "trap": "Model focuses on the mutex/slice synchronization and misses that wg.Add(1) is inside the goroutine, racing with wg.Wait()",
+    "assertions": [
+      {"id": "9.1", "text": "Identifies that wg.Add(1) is called inside the goroutine instead of before it"},
+      {"id": "9.2", "text": "Explains that wg.Wait() may return before all goroutines have called wg.Add(1)"},
+      {"id": "9.3", "text": "Recommends moving wg.Add(1) before the go func() call"},
+      {"id": "9.4", "text": "Notes this is a race condition that passes most of the time but fails intermittently"},
+      {"id": "9.5", "text": "Does NOT focus primarily on the mutex/slice synchronization as the root cause"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "missing-return-after-http-error",
+    "description": "Tests the missing return after http.Error() bug from common-go-bugs",
+    "prompt": "My Go API endpoint has a security vulnerability — unauthorized users can sometimes access protected resources. The handler checks authorization and sends a 403 Forbidden response, but the protected action still executes. Here's the code:\n\n```go\nfunc handleDelete(w http.ResponseWriter, r *http.Request) {\n    if !isAuthorized(r) {\n        http.Error(w, \"Forbidden\", http.StatusForbidden)\n    }\n    if err := deleteResource(r.Context(), r.URL.Query().Get(\"id\")); err != nil {\n        http.Error(w, err.Error(), 500)\n    }\n    w.WriteHeader(http.StatusNoContent)\n}\n```",
+    "trap": "Model suggests the isAuthorized function is buggy rather than noticing the missing return after http.Error()",
+    "assertions": [
+      {"id": "10.1", "text": "Identifies the missing return statement after http.Error(w, 'Forbidden', http.StatusForbidden)"},
+      {"id": "10.2", "text": "Explains that http.Error() does NOT stop handler execution — it only writes to the ResponseWriter"},
+      {"id": "10.3", "text": "Adds return statements after each http.Error() call"},
+      {"id": "10.4", "text": "Does NOT primarily blame the isAuthorized function"},
+      {"id": "10.5", "text": "Mentions this is a common Go bug pattern and a security concern"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "json-numbers-float64-interface",
+    "description": "Tests JSON unmarshaling gotcha: numbers into interface{} become float64, not int",
+    "prompt": "My Go code panics when processing JSON API responses. The JSON looks like `{\"user_id\": 1234567890123456789}`. I unmarshal into `map[string]interface{}` and then type-assert the user_id to int64:\n\n```go\nvar result map[string]interface{}\njson.Unmarshal(data, &result)\nuserID := result[\"user_id\"].(int64)\n```\nWhy does this panic?",
+    "trap": "Model suggests the JSON is malformed or the field name doesn't match, rather than explaining the float64 type gotcha",
+    "assertions": [
+      {"id": "11.1", "text": "Explains that JSON numbers unmarshaled into interface{} become float64, not int or int64"},
+      {"id": "11.2", "text": "Notes that large integers (> 2^53) silently lose precision when stored as float64"},
+      {"id": "11.3", "text": "Recommends using a typed struct with int64 field as the preferred solution"},
+      {"id": "11.4", "text": "Alternatively mentions json.NewDecoder with UseNumber() and json.Number for when interface{} is required"},
+      {"id": "11.5", "text": "Explains the type assertion panics because the actual type is float64, not int64"}
+    ]
+  },
+  {
+    "id": 12,
+    "name": "strings-trim-vs-trimprefix",
+    "description": "Tests the strings.Trim character-set gotcha from common-go-bugs",
+    "prompt": "My Go function strips the 'application/' prefix from MIME types but gives wrong results for some types. `strings.Trim(\"application/json\", \"application/\")` returns 'js' instead of 'json'. Is this a Go bug?",
+    "trap": "Model suggests it's a Go bug or suggests a regex-based workaround instead of explaining Trim treats the second argument as a character set",
+    "assertions": [
+      {"id": "12.1", "text": "Explains that strings.Trim treats its second argument as a SET of characters to strip, not as a substring"},
+      {"id": "12.2", "text": "Shows why 'json' becomes 'js' — the characters j, o, n are in the set {a,p,l,i,c,t,o,n,/}"},
+      {"id": "12.3", "text": "Recommends strings.TrimPrefix for removing a substring prefix"},
+      {"id": "12.4", "text": "Mentions strings.TrimSuffix for removing suffixes"},
+      {"id": "12.5", "text": "Confirms this is NOT a Go bug — it's working as documented"}
+    ]
+  },
+  {
+    "id": 13,
+    "name": "closed-channel-busy-loop-in-select",
+    "description": "Tests the closed channel in select causing busy loop from common-go-bugs",
+    "prompt": "After running for a few hours, my Go worker's CPU usage jumps to 100% even when there's no work. The worker reads from a channel in a select. Sometimes the upstream producer closes the channel when it's done. Here's the worker:\n\n```go\nfunc worker(ch <-chan Job, done <-chan struct{}) {\n    for {\n        select {\n        case job := <-ch:\n            process(job)\n        case <-done:\n            return\n        }\n    }\n}\n```",
+    "trap": "Model suggests adding a time.Sleep in a default case or reducing GOMAXPROCS, rather than identifying that a closed channel fires continuously in select",
+    "assertions": [
+      {"id": "13.1", "text": "Identifies that a closed channel always returns immediately (zero value) in a select case"},
+      {"id": "13.2", "text": "Explains this causes the select case to fire continuously — a busy loop burning CPU"},
+      {"id": "13.3", "text": "Recommends using the comma-ok idiom (job, ok := <-ch) and nil-ing the channel when closed (ch = nil)"},
+      {"id": "13.4", "text": "Explains that a nil channel blocks forever in select, effectively disabling that case"},
+      {"id": "13.5", "text": "Does NOT suggest adding a default case with time.Sleep as the fix"}
+    ]
+  },
+  {
+    "id": 14,
+    "name": "select-default-spin-loop",
+    "description": "Tests the select-with-default busy-wait pattern from common-go-bugs",
+    "prompt": "I need non-blocking channel reads in my Go message processor. I have a for loop with a select that checks a channel and a default case. The code works but uses 100% CPU even when idle. How do I fix this without blocking?\n\n```go\nfor {\n    select {\n    case msg := <-incoming:\n        handleMsg(msg)\n    default:\n        // check other conditions\n        if shouldStop() {\n            return\n        }\n    }\n}\n```",
+    "trap": "Model keeps the default case and just adds more logic to it, rather than restructuring to remove the busy-wait",
+    "assertions": [
+      {"id": "14.1", "text": "Identifies that select with default inside a for loop is a busy-wait spin loop"},
+      {"id": "14.2", "text": "Explains that default runs immediately when no channel is ready, creating a tight loop"},
+      {"id": "14.3", "text": "Recommends removing the default case and using a second channel or context for the stop signal"},
+      {"id": "14.4", "text": "Alternatively suggests adding a time.Sleep or ticker in the default to yield CPU if non-blocking is truly required"},
+      {"id": "14.5", "text": "Shows a solution using a ctx.Done() or stop channel in a second select case"}
+    ]
+  },
+  {
+    "id": 15,
+    "name": "enum-zero-value-iota-ambiguity",
+    "description": "Tests the iota zero value ambiguity from common-go-bugs",
+    "prompt": "I have a Go enum for user roles using iota. Some users are getting Admin privileges by default when they register, even though I didn't set their role. The zero value of Role seems to be Admin. How should I fix this?\n\n```go\ntype Role int\nconst (\n    Admin   Role = iota  // 0\n    Editor               // 1\n    Viewer               // 2\n)\n\ntype User struct {\n    Name string\n    Role Role\n}\n```",
+    "trap": "Model suggests setting new users' Role field to Viewer explicitly in the constructor, rather than fixing the enum design",
+    "assertions": [
+      {"id": "15.1", "text": "Identifies that iota starting at 0 makes the zero value (default for uninitialized fields) equal to Admin"},
+      {"id": "15.2", "text": "Recommends reserving 0 for an Unknown/Unspecified sentinel value"},
+      {"id": "15.3", "text": "Shows the pattern: RoleUnknown Role = iota, then Admin, Editor, Viewer"},
+      {"id": "15.4", "text": "Explains this applies to any enum — zero value should be the 'unset' state, not a valid value"},
+      {"id": "15.5", "text": "Does NOT primarily suggest fixing it in the constructor or registration logic"}
+    ]
+  },
+  {
+    "id": 16,
+    "name": "recover-only-same-goroutine",
+    "description": "Tests the recover() goroutine boundary from common-go-bugs",
+    "prompt": "My Go server has a panic recovery middleware but child goroutines still crash the entire process. I have:\n\n```go\nfunc handler(w http.ResponseWriter, r *http.Request) {\n    defer func() {\n        if r := recover(); r != nil {\n            http.Error(w, \"Internal Error\", 500)\n        }\n    }()\n    go processAsync(r.Context(), extractData(r))\n    w.WriteHeader(http.StatusAccepted)\n}\n```\nWhen processAsync panics, the whole server crashes instead of just returning 500.",
+    "trap": "Model suggests wrapping the recover middleware differently or using a global recover, not understanding that recover only works within the same goroutine",
+    "assertions": [
+      {"id": "16.1", "text": "Explains that recover() can ONLY catch panics in the same goroutine where it is deferred"},
+      {"id": "16.2", "text": "States that a panic in a child goroutine will crash the entire program regardless of parent recovery"},
+      {"id": "16.3", "text": "Recommends adding defer/recover inside the child goroutine (processAsync or its wrapper)"},
+      {"id": "16.4", "text": "Shows the pattern: go func() { defer func() { if r := recover()... }(); processAsync(...) }()"},
+      {"id": "16.5", "text": "Does NOT suggest reconfiguring the parent middleware as the solution"}
+    ]
+  },
+  {
+    "id": 17,
+    "name": "os-exit-skips-defers",
+    "description": "Tests os.Exit / log.Fatal skipping deferred functions from common-go-bugs",
+    "prompt": "My Go CLI tool creates temp files and defers their cleanup, but sometimes temp files are left behind. The code structure is:\n\n```go\nfunc main() {\n    tmpFile, _ := os.CreateTemp(\"\", \"data-*\")\n    defer os.Remove(tmpFile.Name())\n    defer tmpFile.Close()\n\n    if err := processData(tmpFile); err != nil {\n        log.Fatalf(\"processing failed: %v\", err)\n    }\n    // ... use results\n}\n```",
+    "trap": "Model suggests the error path doesn't clean up properly but misses that log.Fatal calls os.Exit which skips ALL deferred functions",
+    "assertions": [
+      {"id": "17.1", "text": "Identifies that log.Fatal (or log.Fatalf) calls os.Exit(1) internally"},
+      {"id": "17.2", "text": "Explains that os.Exit skips all deferred functions — cleanup never runs"},
+      {"id": "17.3", "text": "Recommends restructuring to avoid log.Fatal — use a run() function pattern or return errors"},
+      {"id": "17.4", "text": "Shows the pattern: move logic into a run() error function, call os.Exit in main only after run returns"},
+      {"id": "17.5", "text": "Does NOT suggest explicitly calling os.Remove before log.Fatal as the primary fix"}
+    ]
+  },
+  {
+    "id": 18,
+    "name": "time-equal-not-double-equals",
+    "description": "Tests the time.Time == vs .Equal() gotcha from common-go-bugs",
+    "prompt": "My Go test comparing time values fails intermittently. I store a time.Time in the database and read it back, then compare with ==. The test passes when I use a fixed time but fails when I use time.Now():\n\n```go\nt1 := time.Now()\nsaveToDatabase(t1)\nt2 := loadFromDatabase()\nassert.True(t, t1 == t2) // fails!\n```\nThe times represent the same instant. Why does == fail?",
+    "trap": "Model suggests the database truncates nanoseconds or timezone differences, not the monotonic clock component",
+    "assertions": [
+      {"id": "18.1", "text": "Identifies that time.Now() includes a monotonic clock reading that database serialization strips"},
+      {"id": "18.2", "text": "Explains that == compares all fields including the monotonic component, so it can fail for equal instants"},
+      {"id": "18.3", "text": "Recommends using .Equal() which ignores the monotonic clock"},
+      {"id": "18.4", "text": "Alternatively mentions t.Round(0) to strip the monotonic reading before comparison or storage"},
+      {"id": "18.5", "text": "Does NOT primarily blame database precision or timezone differences"}
+    ]
+  },
+  {
+    "id": 19,
+    "name": "sql-rows-must-be-closed",
+    "description": "Tests the sql.Rows close requirement and connection leak from common-go-bugs",
+    "prompt": "My Go service starts failing with 'too many connections' after running for a few hours under load. Database queries start timing out. The code:\n\n```go\nfunc getActiveUsers(db *sql.DB) ([]User, error) {\n    rows, err := db.Query(\"SELECT id, name FROM users WHERE active = true\")\n    if err != nil {\n        return nil, err\n    }\n    var users []User\n    for rows.Next() {\n        var u User\n        rows.Scan(&u.ID, &u.Name)\n        users = append(users, u)\n    }\n    return users, nil\n}\n```",
+    "trap": "Model suggests increasing the connection pool size or adding connection timeout, rather than finding the missing rows.Close()",
+    "assertions": [
+      {"id": "19.1", "text": "Identifies the missing defer rows.Close() after the error check"},
+      {"id": "19.2", "text": "Explains that unclosed sql.Rows holds the database connection until garbage collection"},
+      {"id": "19.3", "text": "Adds defer rows.Close() immediately after the err check"},
+      {"id": "19.4", "text": "Also notes the missing rows.Err() check after the loop"},
+      {"id": "19.5", "text": "Does NOT primarily suggest increasing connection pool size"}
+    ]
+  },
+  {
+    "id": 20,
+    "name": "copying-sync-types-value-receiver",
+    "description": "Tests the sync type copying bug from common-go-bugs",
+    "prompt": "My Go concurrent counter gives wrong results. Multiple goroutines call Increment() but the final count is always 0 or some small number, never the expected total. The race detector doesn't fire. What's wrong?\n\n```go\ntype Counter struct {\n    mu    sync.Mutex\n    count int\n}\n\nfunc (c Counter) Increment() {\n    c.mu.Lock()\n    c.count++\n    c.mu.Unlock()\n}\n\nfunc (c Counter) Count() int {\n    c.mu.Lock()\n    defer c.mu.Unlock()\n    return c.count\n}\n```",
+    "trap": "Model suggests the mutex isn't working or suggests using atomic instead, without identifying the value receiver as the root cause",
+    "assertions": [
+      {"id": "20.1", "text": "Identifies that value receivers (c Counter) copy the entire struct including the Mutex on every call"},
+      {"id": "20.2", "text": "Explains that each call operates on a copy — increments are lost and the mutex is duplicated"},
+      {"id": "20.3", "text": "Recommends changing to pointer receivers (c *Counter)"},
+      {"id": "20.4", "text": "Notes that go vet can detect copied sync types"},
+      {"id": "20.5", "text": "Explains this applies to ALL sync types (Mutex, RWMutex, WaitGroup, Once, etc.)"}
+    ]
+  },
+  {
+    "id": 21,
+    "name": "pprof-production-security",
+    "description": "Tests the pprof security requirement: never expose unauthenticated in production",
+    "prompt": "I need to add CPU and memory profiling to my Go production web service. I'll just add `import _ \"net/http/pprof\"` and expose it on the main HTTP port. What's the simplest way to set this up?",
+    "trap": "Model provides the simple blank-import pattern without security warnings, exposing pprof publicly",
+    "assertions": [
+      {"id": "21.1", "text": "Warns that pprof endpoints MUST be protected — never exposed publicly without authentication"},
+      {"id": "21.2", "text": "Recommends basic auth or similar authentication on pprof endpoints"},
+      {"id": "21.3", "text": "Suggests running pprof on a separate port (not the main HTTP port) or localhost only"},
+      {"id": "21.4", "text": "Recommends toggling pprof via an environment variable (e.g., PPROF_ENABLED)"},
+      {"id": "21.5", "text": "Explains the risk: pprof leaks goroutine stacks, memory contents, and can be used for DoS"}
+    ]
+  },
+  {
+    "id": 22,
+    "name": "godebug-gc-tracing-interpretation",
+    "description": "Tests GODEBUG gctrace interpretation from diagnostic-tools reference",
+    "prompt": "My Go service is experiencing periodic latency spikes. I enabled GC tracing with GODEBUG=gctrace=1 and see this output:\n```\ngc 456 @120.5s 18%: 2.1+45+1.2 ms clock, 16+12/45/8 ms cpu, 1024->900->500 MB\n```\nWhat does this tell me and is there a problem?",
+    "trap": "Model focuses only on the heap sizes and misses the 18% GC CPU overhead as the key signal",
+    "assertions": [
+      {"id": "22.1", "text": "Identifies that 18% GC CPU overhead is significantly high (threshold is >10%)"},
+      {"id": "22.2", "text": "Explains the heap size breakdown as heap at GC start, heap at GC end, and live heap"},
+      {"id": "22.3", "text": "Identifies the large pause times (45ms) as a likely cause of the latency spikes"},
+      {"id": "22.4", "text": "Suggests the application is over-allocating and recommends investigating allocation patterns"},
+      {"id": "22.5", "text": "Recommends using pprof heap/alloc profiling to find hot allocation sites"}
+    ]
+  },
+  {
+    "id": 23,
+    "name": "research-codebase-not-just-diff",
+    "description": "Tests Golden Rule #6: trace callers and check upstream validation before flagging a bug",
+    "prompt": "During code review, I found this Go function. It looks like it has a bug — it doesn't validate that `id` is positive before using it as a slice index:\n\n```go\nfunc getItem(items []Item, id int) Item {\n    return items[id]\n}\n```\nShould I flag this as a bug?",
+    "trap": "Model immediately flags it as a bug and suggests adding bounds checking, without considering that callers might already validate",
+    "assertions": [
+      {"id": "23.1", "text": "Recommends checking the callers first before flagging the bug"},
+      {"id": "23.2", "text": "Suggests using Grep or similar to find all call sites of getItem"},
+      {"id": "23.3", "text": "Notes that upstream code may validate the id (e.g., parsing from uint, bounds checking, positive-only input)"},
+      {"id": "23.4", "text": "Advises that if callers validate, the severity is reduced but may still warrant a defensive check"},
+      {"id": "23.5", "text": "Mentions adding an inline comment documenting the assumption if upstream guarantees exist"}
+    ]
+  },
+  {
+    "id": 24,
+    "name": "flaky-test-diagnosis-methodology",
+    "description": "Tests flaky test debugging methodology from testing-debug reference",
+    "prompt": "One of our Go tests fails about 1 in 20 runs in CI but I can never reproduce it locally. The test creates a temp file, writes data, reads it back, and compares. How do I debug this?",
+    "trap": "Model suggests adding retry logic or skipping the test in CI, rather than systematic flaky test diagnosis",
+    "assertions": [
+      {"id": "24.1", "text": "Recommends running with -count=100 to reproduce locally"},
+      {"id": "24.2", "text": "Suggests using -shuffle=on to check for test order dependence"},
+      {"id": "24.3", "text": "Mentions running with -race to check for data races"},
+      {"id": "24.4", "text": "Suggests using t.TempDir() instead of shared temp directories to avoid file system pollution"},
+      {"id": "24.5", "text": "Considers shared mutable state between tests as a potential cause"},
+      {"id": "24.6", "text": "Does NOT suggest retry logic or skipping the test as a solution"}
+    ]
+  },
+  {
+    "id": 25,
+    "name": "defense-in-depth-after-fix",
+    "description": "Tests Step 10 of methodology: multi-layer defense after fixing a bug",
+    "prompt": "I fixed a bug where user-submitted file paths could traverse outside the upload directory using ../. The fix adds filepath.Clean and a strings.HasPrefix check. Is this fix complete?",
+    "trap": "Model says the fix looks good without recognizing that Clean+HasPrefix is not robust confinement and without considering defense-in-depth — os.Root, safer lexical fallback, logging, and test coverage",
+    "assertions": [
+      {"id": "25.1", "text": "States that filepath.Clean plus strings.HasPrefix is not robust confinement"},
+      {"id": "25.2", "text": "Recommends adding a test that specifically verifies the path traversal is blocked"},
+      {"id": "25.3", "text": "Suggests adding logging or metrics to detect future traversal attempts (observability)"},
+      {"id": "25.4", "text": "Considers multiple validation layers — not just one check"},
+      {"id": "25.5", "text": "Recommends os.Root for Go 1.24+ or a filepath.IsLocal/filepath.Rel fallback for older targets"}
+    ]
+  },
+  {
+    "id": 26,
+    "name": "escalation-protocol-three-failed-attempts",
+    "description": "Tests the escalation protocol: after 3 failed fix attempts, step back and question architecture",
+    "prompt": "I've tried fixing this Go data processing bug 4 times now. Each fix reveals a new problem — first the data was truncated, then the order was wrong, then duplicates appeared, now there's a memory leak. The code processes events from a Kafka topic and aggregates them in a map. What should I try next?",
+    "trap": "Model suggests a 5th specific fix (more memory management, deduplication logic, etc.) instead of stepping back to question the architecture",
+    "assertions": [
+      {"id": "26.1", "text": "Recognizes the pattern of cascading failures as a red flag — each fix reveals a new problem"},
+      {"id": "26.2", "text": "Recommends stepping back to question the overall design/architecture rather than trying another fix"},
+      {"id": "26.3", "text": "Suggests re-reading the code from scratch with fresh eyes"},
+      {"id": "26.4", "text": "Considers whether the current abstraction is fundamentally sound"},
+      {"id": "26.5", "text": "Does NOT immediately suggest a 5th specific patch to the existing code"}
+    ]
+  },
+  {
+    "id": 27,
+    "name": "git-bisect-for-regression",
+    "description": "Tests the methodology step 1: using git bisect to find breaking commit for regressions",
+    "prompt": "A feature that was working last week is now broken in our Go service. I'm not sure which commit broke it. There have been about 50 commits since it last worked. How should I find what changed?",
+    "trap": "Model suggests reading through all 50 commit diffs manually or running tests on HEAD",
+    "assertions": [
+      {"id": "27.1", "text": "Recommends git bisect to binary-search for the breaking commit"},
+      {"id": "27.2", "text": "Shows the git bisect start / git bisect bad / git bisect good workflow"},
+      {"id": "27.3", "text": "Mentions that bisect can be automated with a test command (git bisect run go test -run TestBroken ./...)"},
+      {"id": "27.4", "text": "Notes this narrows 50 commits to ~6 steps (log2(50))"},
+      {"id": "27.5", "text": "Does NOT suggest manually reading all 50 commit diffs"}
+    ]
+  },
+  {
+    "id": 28,
+    "name": "check-external-dependencies-first",
+    "description": "Tests Step 4 of methodology: verify external components before assuming code bug",
+    "prompt": "My Go service started returning 'connection refused' errors for API calls to a third-party payment service. This worked fine yesterday. Nothing in our code changed (I checked git log). Where should I look?",
+    "trap": "Model starts investigating Go HTTP client code or TLS configuration instead of checking the external service first",
+    "assertions": [
+      {"id": "28.1", "text": "Suggests checking the external payment service health/status first (curl, health endpoint)"},
+      {"id": "28.2", "text": "Recommends checking DNS resolution (dig or nslookup)"},
+      {"id": "28.3", "text": "Suggests checking network connectivity (nc, telnet, or similar to the port)"},
+      {"id": "28.4", "text": "Considers environment-specific causes: expired credentials, DNS changes, firewall rules, certificate rotation"},
+      {"id": "28.5", "text": "Does NOT start by investigating Go code since nothing changed in the codebase"}
+    ]
+  },
+  {
+    "id": 29,
+    "name": "observability-tools-before-code-dive",
+    "description": "Tests Step 5 of methodology: check observability data before diving into code",
+    "prompt": "Our Go microservice started returning 500 errors about 2 hours ago. I want to start reading the code to find the bug. Where should I start looking in the codebase?",
+    "trap": "Model jumps straight into reading handler code or error paths instead of suggesting checking observability tools first",
+    "assertions": [
+      {"id": "29.1", "text": "Recommends checking monitoring/observability tools BEFORE diving into code"},
+      {"id": "29.2", "text": "Asks what monitoring tools are available (Prometheus, Datadog, Sentry, ELK, etc.)"},
+      {"id": "29.3", "text": "Suggests checking error rate metrics, latency dashboards, or log aggregation"},
+      {"id": "29.4", "text": "Mentions specific things to look for: what changed 2 hours ago (deploy, config change, traffic spike)"},
+      {"id": "29.5", "text": "Does NOT immediately start reading source code files"}
+    ]
+  },
+  {
+    "id": 30,
+    "name": "integer-conversion-silent-truncation",
+    "description": "Tests integer conversion truncation from common-go-bugs",
+    "prompt": "My Go code converts user-provided int64 values to int32 for a legacy protocol. It works for most values but produces wrong results for large numbers. The conversion is `int32(bigValue)`. Is there a Go function to convert safely?",
+    "trap": "Model suggests casting with a simple function or using math.MinInt32/MaxInt32 incorrectly",
+    "assertions": [
+      {"id": "30.1", "text": "Explains that Go integer conversions silently truncate without any error or warning"},
+      {"id": "30.2", "text": "Shows bounds checking before conversion: compare against math.MinInt32 and math.MaxInt32"},
+      {"id": "30.3", "text": "Returns an error when the value overflows instead of silently truncating"},
+      {"id": "30.4", "text": "Notes there is no built-in safe conversion function — you must check bounds manually"},
+      {"id": "30.5", "text": "Mentions this is especially dangerous for external/user-provided data"}
+    ]
+  },
+  {
+    "id": 31,
+    "name": "init-ordering-fragile",
+    "description": "Tests the init() ordering fragility from common-go-bugs",
+    "prompt": "My Go program panics during startup with a nil pointer. I have an init() function that opens a database connection using a config value from another init() in a different file. It works in development but fails in CI. Could the init order be different?",
+    "trap": "Model suggests ensuring the config init file is imported first or adding a side-effect import, rather than recommending explicit initialization",
+    "assertions": [
+      {"id": "31.1", "text": "Confirms that init() ordering across files depends on filename alphabetical order and can change when files are added"},
+      {"id": "31.2", "text": "Explains this makes init() dependencies fragile and hard to debug"},
+      {"id": "31.3", "text": "Recommends replacing init() with explicit initialization in main()"},
+      {"id": "31.4", "text": "Shows the pattern: cfg := loadConfig(); db := setupDatabase(cfg); startServer(db)"},
+      {"id": "31.5", "text": "States init() should only be used for truly self-contained setup (registering drivers, codecs)"}
+    ]
+  },
+  {
+    "id": 32,
+    "name": "goroutine-leak-detection-methodology",
+    "description": "Tests goroutine leak diagnosis from concurrency-debug reference",
+    "prompt": "My Go service's memory usage grows slowly over days. CPU is normal. There's no obvious memory leak in heap profiling. What else could cause the slow growth?",
+    "trap": "Model focuses only on heap analysis and misses goroutine leaks as a major cause of slow memory growth",
+    "assertions": [
+      {"id": "32.1", "text": "Suggests checking goroutine count (runtime.NumGoroutine or pprof goroutine profile)"},
+      {"id": "32.2", "text": "Explains that goroutine leaks cause slow memory growth without appearing in heap profiles"},
+      {"id": "32.3", "text": "Recommends using the pprof goroutine endpoint with ?debug=2 for human-readable stack dumps"},
+      {"id": "32.4", "text": "Lists common causes: unclosed channels, missing context cancellation, forgotten response body close"},
+      {"id": "32.5", "text": "Suggests goleak for detection in tests"}
+    ]
+  },
+  {
+    "id": 33,
+    "name": "production-capture-before-restart",
+    "description": "Tests the production debugging checklist: capture profiles BEFORE restarting",
+    "prompt": "Our Go production service is consuming 4GB of memory and responding slowly. We need to fix this urgently. Should I restart the service first to restore normal operation?",
+    "trap": "Model agrees to restart first to restore service, losing all diagnostic information",
+    "assertions": [
+      {"id": "33.1", "text": "Recommends capturing profiles (heap, goroutine, CPU) BEFORE restarting"},
+      {"id": "33.2", "text": "Explains that restarting destroys the evidence needed to diagnose the root cause"},
+      {"id": "33.3", "text": "Lists specific profiles to capture: heap, goroutine dump (?debug=2), CPU (30s), mutex"},
+      {"id": "33.4", "text": "Also suggests capturing system metrics (file descriptors, socket state, process info)"},
+      {"id": "33.5", "text": "Only after capturing all evidence should the service be restarted if needed"}
+    ]
+  },
+  {
+    "id": 34,
+    "name": "lock-contention-diagnosis",
+    "description": "Tests lock contention diagnosis from performance-debug reference",
+    "prompt": "My Go web server shows high CPU usage but low throughput. Adding more cores doesn't help — performance stays flat. The profiler shows most time in runtime.semacquire. What's going on?",
+    "trap": "Model suggests the workload is CPU-bound and recommends algorithmic optimization, rather than identifying lock contention",
+    "assertions": [
+      {"id": "34.1", "text": "Identifies runtime.semacquire as a signal of lock contention, not CPU computation"},
+      {"id": "34.2", "text": "Recommends enabling mutex profiling with runtime.SetMutexProfileFraction(1)"},
+      {"id": "34.3", "text": "Recommends enabling block profiling with runtime.SetBlockProfileRate(1)"},
+      {"id": "34.4", "text": "Suggests using pprof mutex and block profiles to find the contended locks"},
+      {"id": "34.5", "text": "Lists solutions: reduce critical section, sharding, RWMutex, atomic operations"}
+    ]
+  },
+  {
+    "id": 35,
+    "name": "race-detector-not-reasoning",
+    "description": "Tests Golden Rule #3: never reason about concurrency — use the race detector",
+    "prompt": "I'm reviewing Go code that has goroutines sharing a struct. I don't see any obvious race conditions — the goroutines seem to access different fields. Is this safe?\n\n```go\ntype Stats struct {\n    RequestCount int64\n    ErrorCount   int64\n    LastUpdated  time.Time\n}\n\nfunc (s *Stats) RecordRequest() {\n    s.RequestCount++\n}\n\nfunc (s *Stats) RecordError() {\n    s.ErrorCount++\n}\n```",
+    "trap": "Model reasons through the code and concludes it looks safe because different goroutines access different fields",
+    "assertions": [
+      {"id": "35.1", "text": "Does NOT conclude safety based on code reasoning alone"},
+      {"id": "35.2", "text": "Recommends running go test -race to verify — never trust visual inspection for concurrency"},
+      {"id": "35.3", "text": "Identifies that ++ is not atomic — RequestCount++ and ErrorCount++ are read-modify-write operations"},
+      {"id": "35.4", "text": "Recommends using atomic.Int64 or sync.Mutex to protect the fields"},
+      {"id": "35.5", "text": "Notes that even different fields on the same struct can race if accessed from different goroutines without synchronization"}
+    ]
+  },
+  {
+    "id": 36,
+    "name": "filepath-join-path-traversal",
+    "description": "Tests the filepath.Join path traversal from common-go-bugs",
+    "prompt": "I'm building a Go file server. I use filepath.Join to safely combine the base directory with the user-requested path. Is this implementation secure?\n\n```go\nfunc serveFile(w http.ResponseWriter, r *http.Request) {\n    path := filepath.Join(\"/srv/files\", r.URL.Path)\n    http.ServeFile(w, r, path)\n}\n```",
+    "trap": "Model says filepath.Join handles path cleaning and the code is safe",
+    "assertions": [
+      {"id": "36.1", "text": "Identifies that filepath.Join does NOT prevent path traversal"},
+      {"id": "36.2", "text": "Shows that input like '../../etc/passwd' resolves to '/etc/passwd' after Join"},
+      {"id": "36.3", "text": "Recommends os.Root for Go 1.24+ user-controlled filesystem access"},
+      {"id": "36.4", "text": "For older Go targets, shows a fallback using filepath.IsLocal plus filepath.Rel with separator-aware checks"},
+      {"id": "36.5", "text": "Does NOT present filepath.Clean plus strings.HasPrefix as a complete traversal defense"}
+    ]
+  },
+  {
+    "id": 37,
+    "name": "time-after-in-loop-allocation-churn",
+    "description": "Tests the repeated time.After in loop allocation-churn pattern from code-review-flags and concurrency-debug",
+    "prompt": "My Go worker processes messages from a channel with a timeout. Memory usage grows over time even though messages are processed correctly. Here's the code:\n\n```go\nfor {\n    select {\n    case msg := <-incoming:\n        process(msg)\n    case <-time.After(30 * time.Second):\n        log.Println(\"idle timeout\")\n        return\n    }\n}\n```",
+    "trap": "Model suggests the message processing is leaking memory, without identifying repeated time.After allocation churn and reset semantics as the likely issue",
+    "assertions": [
+      {"id": "37.1", "text": "Identifies that time.After creates a new timer on every loop iteration"},
+      {"id": "37.2", "text": "Explains this causes allocation churn and was a leak-like pattern on older Go versions before Go 1.23 timer GC improvements"},
+      {"id": "37.3", "text": "Recommends using time.NewTimer with Reset() or time.NewTicker instead"},
+      {"id": "37.4", "text": "Shows the correct pattern with a reusable timer and defer timer.Stop()"},
+      {"id": "37.5", "text": "Does NOT suggest heap profiling as the first diagnostic step for this known pattern"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/code-review-flags.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/code-review-flags.md
new file mode 100644
index 00000000..9b307a7b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/code-review-flags.md
@@ -0,0 +1,32 @@
+# Code Review Red Flags
+
+If you see these in code review, flag them:
+
+| Pattern | Why It's Bad |
+| --- | --- |
+| `result, _ := doSomething()` | Silent error — mystery bugs later |
+| `go func() { }()` without context | Can't cancel, leaks goroutine |
+| Channel without close | Goroutine leak when sender exits |
+| `time.After` in hot loop | Repeated timer allocation/churn; use a reusable timer when reset semantics matter |
+| Global map without mutex | Data race |
+| `defer` inside hot loop | Deferred calls pile up until return |
+| `json.Marshal` in hot path | Expensive, causes GC pressure |
+| `for range` without `ok` check | Misses channel close |
+| `var err *MyError; return err` | Interface nil gotcha |
+| `http.Get` without timeout | Default client has no timeout |
+| `fmt.Errorf("...: %v", err)` | Use `%w` to preserve error chain |
+| `:=` shadowing outer `err` | Inner err is a new variable, outer stays nil |
+| `func (c Counter) Lock()` | Value receiver copies sync types |
+| `wg.Add(1)` inside goroutine | Race: Wait() may return before Add() |
+| `http.Error(...)` without return | Handler keeps executing after error |
+| `iota` starting at 0 for enums | Zero value ambiguous with first constant |
+| `strings.Trim(s, "prefix")` | Strips char set, not substring |
+| `log.Fatal(err)` in func w/ defer | `os.Exit` skips all deferred cleanup |
+| `t1 == t2` for `time.Time` | Use `.Equal()` — monotonic clock differs |
+| `rows, _ := db.Query(...)` no Close | Leaks database connections |
+| `ch <- val` after `close(ch)` | Panics — only sender should close |
+| `select { default: }` in loop | Busy loop — burns CPU without blocking |
+| `int32(bigInt64)` | Silent truncation — no overflow check |
+| `filepath.Join(base, userInput)` | Doesn't prevent `../` path traversal |
+| `regexp.MustCompile` in handler | Recompiles every call — move to package var |
+| `fallthrough` in switch | Executes next case unconditionally |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/common-go-bugs.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/common-go-bugs.md
new file mode 100644
index 00000000..2edeb20a
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/common-go-bugs.md
@@ -0,0 +1,858 @@
+# Common Go Bugs
+
+→ See `samber/cc-skills-golang@golang-safety` skill for in-depth nil, slice, and map safety patterns.
+
+## Nil Pointer Dereference
+
+Pointers from external sources MUST be checked before dereferencing.
+
+The most common Go panic. The stack trace tells you the exact line.
+
+```go
+// 1. Uninitialized struct field
+type Server struct {
+    logger *log.Logger  // nil if not set in constructor
+}
+
+// 2. Unchecked error return — if err != nil, val may be nil/zero
+val, err := doSomething()
+val.Method()  // panic if doSomething returned nil val with an error
+
+// 3. Map lookup returns zero value
+m := map[string]*Config{}
+cfg := m["missing"]  // cfg is nil
+cfg.Timeout  // panic
+
+// 4. Type assertion without comma-ok
+var i interface{} = "hello"
+n := i.(int)        // panic
+n, ok := i.(int)    // ok == false, no panic
+```
+
+## Interface Nil Gotcha
+
+NEVER compare an interface to nil when it may contain a typed nil pointer.
+
+A typed nil pointer inside an interface is **not** a nil interface:
+
+```go
+type MyError struct{ msg string }
+func (e *MyError) Error() string { return e.msg }
+
+func doWork() error {
+    var err *MyError  // typed nil pointer
+    return err        // returns non-nil interface containing nil pointer!
+}
+
+func main() {
+    if err := doWork(); err != nil {
+        // This EXECUTES — the interface is non-nil
+        fmt.Println(err)  // panic: nil pointer in Error()
+    }
+}
+
+// FIX: return nil explicitly, not a typed nil variable
+func doWork() error {
+    return nil
+}
+```
+
+## Variable Shadowing with `:=`
+
+The `:=` short declaration creates a new variable in the inner scope instead of assigning to the outer one. Especially dangerous when shadowing `err`, because error handling silently breaks.
+
+```go
+// BAD
+func doWork() error {
+    var err error
+    if condition {
+        result, err := someFunc() // BUG: new err variable, doesn't set outer one
+        if err != nil {
+            return err
+        }
+        process(result)
+    }
+    return err // always nil — inner err was a different variable
+}
+
+// GOOD
+func doWork() error {
+    var err error
+    if condition {
+        var result ResultType
+        result, err = someFunc() // assigns to outer err
+        if err != nil {
+            return err
+        }
+        process(result)
+    }
+    return err
+}
+```
+
+**Detect:** run the `golang.org/x/tools/go/analysis/passes/shadow` analyzer through your lint setup. The old shadow flag is not part of standard `go vet`.
+
+## Slice and Map Gotchas
+
+```go
+// 1. Nil map write panics
+var m map[string]int
+m["key"] = 1  // panic: assignment to entry in nil map
+// FIX: m := make(map[string]int)
+// Note: nil map reads are fine — they return zero value
+
+// 2. Append may share underlying array
+a := []int{1, 2, 3}
+b := a[:2]
+b = append(b, 99)  // overwrites a[2]!
+// FIX: full slice expression — b := a[:2:2] to limit capacity
+
+// 3. Range variable capture in goroutine (Go < 1.22)
+for _, v := range items {
+    go func() {
+        process(v)  // v is shared, will likely be last element
+    }()
+}
+// FIX: pass as argument
+for _, v := range items {
+    go func(v Item) { process(v) }(v)
+}
+// In Go 1.22+, loop variables are per-iteration (no fix needed)
+```
+
+## Defer Gotchas
+
+```go
+// 1. Arguments evaluated immediately
+x := 1
+defer fmt.Println(x)  // prints 1, not 2
+x = 2
+
+// 2. Defer in loop — doesn't run until function returns
+for _, f := range files {
+    file, _ := os.Open(f)
+    defer file.Close()  // all Close() calls pile up until return
+}
+// FIX: wrap in closure
+for _, f := range files {
+    func() {
+        file, _ := os.Open(f)
+        defer file.Close()
+        // use file
+    }()
+}
+
+// 3. Named return + defer interaction
+func readFile() (err error) {
+    f, err := os.Open("file.txt")
+    if err != nil { return }
+    defer func() {
+        if closeErr := f.Close(); err == nil {
+            err = closeErr  // modifies named return
+        }
+    }()
+    // ...
+    return nil
+}
+```
+
+## Error Handling Pitfalls
+
+**Silent error swallowing** is the single most common source of "mysterious" bugs:
+
+```go
+// BAD — silent failure
+result, _ := doSomething()
+json.Unmarshal(data, &config)
+http.ListenAndServe(":8080", nil)
+
+// GOOD — handle or propagate
+result, err := doSomething()
+if err != nil {
+    return fmt.Errorf("doSomething: %w", err)
+}
+```
+
+**Find ignored errors:**
+
+```bash
+go vet ./...
+
+# More thorough
+go get -tool github.com/kisielk/errcheck@latest
+go tool errcheck ./...
+```
+
+**Error wrapping — use `%w`, not `%v`:**
+
+```go
+return fmt.Errorf("reading config from %s: %v", path, err)  // BAD — loses error chain
+return fmt.Errorf("reading config from %s: %w", path, err)  // GOOD — preserves Is/As
+
+// Check for specific errors — use errors.Is, not ==
+if err == sql.ErrNoRows { ... }            // BAD — breaks if wrapped
+if errors.Is(err, sql.ErrNoRows) { ... }   // GOOD — traverses chain
+
+// Extract typed errors
+var pathErr *os.PathError
+if errors.As(err, &pathErr) { ... }
+```
+
+## Context Misuse
+
+```go
+// 1. Forgetting to cancel — leaks goroutines
+ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
+// Missing: defer cancel()
+
+// 2. Using background context when you should propagate
+go doWork(context.Background())  // BAD — can't cancel from parent
+go doWork(ctx)                   // GOOD — respects parent cancellation
+
+// 3. Not checking context error
+err := doWork(ctx)
+if err != nil {
+    // Distinguish timeout from other errors
+    if ctx.Err() == context.DeadlineExceeded {
+        log.Printf("operation timed out")
+    } else if ctx.Err() == context.Canceled {
+        log.Printf("operation cancelled")
+    } else {
+        log.Printf("operation failed: %v", err)
+    }
+}
+
+// 4. Background work outliving request context
+func handler(w http.ResponseWriter, r *http.Request) {
+    // BAD — background work uses request context that cancels when client disconnects
+    go processAsync(r.Context(), data)
+
+    // GOOD — derive a new context for background work (Go 1.21+)
+    bgCtx := context.WithoutCancel(r.Context())
+    go processAsync(bgCtx, data)
+}
+```
+
+## Concurrent Map Read/Write (Fatal)
+
+Maps MUST NOT be accessed concurrently without synchronization.
+
+Unlike most Go runtime errors, a concurrent map read/write is a **fatal error** — it **cannot be caught with `recover()`** and crashes the entire process. Hard to catch in tests because it depends on timing.
+
+```go
+// BAD — fatal: concurrent map read and map write
+m := make(map[string]int)
+go func() { m["key"] = 1 }()  // concurrent write
+go func() { _ = m["key"] }()  // concurrent read — fatal!
+
+// GOOD — protect with mutex
+var mu sync.RWMutex
+m := make(map[string]int)
+go func() { mu.Lock(); m["key"] = 1; mu.Unlock() }()
+go func() { mu.RLock(); _ = m["key"]; mu.RUnlock() }()
+
+// Or use sync.Map for read-heavy workloads with stable key sets
+```
+
+**Detect:** `go test -race ./...` — always run in CI.
+
+## Copying sync Types
+
+Sync types MUST NEVER be copied — use pointer receivers and pass by pointer.
+
+All `sync` types (`Mutex`, `RWMutex`, `WaitGroup`, `Once`, `Cond`, `Map`, `Pool`) must not be copied. Copying them via value receivers, function arguments, or struct assignment silently breaks synchronization.
+
+```go
+// BAD — value receiver copies the Mutex
+type Counter struct {
+    mu    sync.Mutex
+    count int
+}
+
+func (c Counter) Increment() { // BUG: copies mutex on every call
+    c.mu.Lock()
+    c.count++
+    c.mu.Unlock()
+}
+
+// GOOD — pointer receiver
+func (c *Counter) Increment() {
+    c.mu.Lock()
+    defer c.mu.Unlock()
+    c.count++
+}
+```
+
+**Detect:** `go vet` detects mutex copies. Apply to all sync types.
+
+## WaitGroup.Add Inside Goroutine
+
+If `wg.Add(1)` is called inside the goroutine instead of before it, `wg.Wait()` may return before all goroutines start — a race condition that passes tests most of the time but fails intermittently.
+
+```go
+// BAD
+var wg sync.WaitGroup
+for i := 0; i < n; i++ {
+    go func() {
+        wg.Add(1) // BUG: may run after wg.Wait() returns
+        defer wg.Done()
+        doWork()
+    }()
+}
+wg.Wait()
+
+// GOOD
+var wg sync.WaitGroup
+for i := 0; i < n; i++ {
+    wg.Add(1) // called BEFORE launching the goroutine
+    go func() {
+        defer wg.Done()
+        doWork()
+    }()
+}
+wg.Wait()
+```
+
+## Missing Return After HTTP Error Response
+
+After writing an error with `http.Error()`, execution continues. This can cause double writes, corrupted responses, or executing logic that should have been skipped.
+
+```go
+// BAD
+func handler(w http.ResponseWriter, r *http.Request) {
+    if !authorized(r) {
+        http.Error(w, "Forbidden", http.StatusForbidden)
+        // BUG: missing return — handler keeps executing
+    }
+    doSensitiveAction(r)
+}
+
+// GOOD
+func handler(w http.ResponseWriter, r *http.Request) {
+    if !authorized(r) {
+        http.Error(w, "Forbidden", http.StatusForbidden)
+        return
+    }
+    doSensitiveAction(r)
+}
+```
+
+## JSON Pitfalls
+
+### Numbers into `interface{}` become `float64`
+
+When unmarshaling into `map[string]interface{}` or `interface{}`, all JSON numbers become `float64`. Type-asserting to `int` panics. Large integers (> 2^53) silently lose precision.
+
+```go
+// BAD
+var result map[string]interface{}
+json.Unmarshal([]byte(`{"id": 1234567890123456789}`), &result)
+id := result["id"].(int) // PANIC: it's float64, not int
+
+// GOOD — use typed struct (preferred)
+type Response struct {
+    ID int64 `json:"id"`
+}
+
+// GOOD — use json.Number when you must use interface{}
+dec := json.NewDecoder(bytes.NewReader(data))
+dec.UseNumber()
+var result map[string]interface{}
+dec.Decode(&result)
+id, _ := result["id"].(json.Number).Int64()
+```
+
+### Unexported fields silently ignored
+
+Fields starting with lowercase are invisible to `encoding/json`. Marshal produces empty output, unmarshal skips them — no error in either case.
+
+```go
+// BAD
+type User struct {
+    name  string `json:"name"`  // unexported — silently ignored!
+    email string `json:"email"` // unexported — silently ignored!
+}
+u := User{name: "Alice", email: "alice@example.com"}
+data, _ := json.Marshal(u) // data is "{}" — no error
+
+// GOOD
+type User struct {
+    Name  string `json:"name"`
+    Email string `json:"email"`
+}
+```
+
+**Detect:** `go vet` warns when unexported fields have JSON struct tags.
+
+## `strings.Trim` vs `strings.TrimPrefix`
+
+`strings.Trim` treats its second argument as a **set of characters** to strip from both ends, not as a substring. This over-trims unexpectedly.
+
+```go
+// BAD
+s := strings.Trim("application/json", "application/")
+// Result: "js" — stripped all chars in set {a,p,l,i,c,t,o,n,/} from both ends!
+
+// GOOD
+s := strings.TrimPrefix("application/json", "application/")
+// Result: "json"
+```
+
+Use `strings.TrimPrefix`/`strings.TrimSuffix` to remove substrings. Only use `strings.Trim` when you intend to strip a set of characters.
+
+## String Length and Indexing
+
+`len()` on strings returns bytes, not characters. Indexing returns a byte. For multi-byte UTF-8 characters, this gives wrong counts and corrupts data when slicing.
+
+```go
+s := "Hello, 世界"
+fmt.Println(len(s))    // 13 (bytes), not 9 (characters)
+fmt.Println(s[:8])     // "Hello, \xe4" — corrupted! cuts a multi-byte rune
+
+// FIX: use utf8.RuneCountInString for character count
+fmt.Println(utf8.RuneCountInString(s)) // 9
+
+// FIX: convert to []rune for character-based slicing
+runes := []rune(s)
+fmt.Println(string(runes[:8])) // "Hello, 世"
+
+// FIX: use for-range to iterate over characters (runes), not bytes
+for _, r := range s { ... } // iterates runes
+```
+
+## `break` in `select`/`switch` Inside `for` Loop
+
+A bare `break` inside a `select` or `switch` that is inside a `for` loop only exits the `select`/`switch`, not the loop.
+
+```go
+// BAD
+for {
+    select {
+    case msg := <-ch:
+        if msg == "quit" {
+            break // BUG: only breaks the select, loop continues forever
+        }
+        process(msg)
+    }
+}
+
+// GOOD — use labeled break
+loop:
+for {
+    select {
+    case msg := <-ch:
+        if msg == "quit" {
+            break loop // breaks the for loop
+        }
+        process(msg)
+    }
+}
+```
+
+## Enum Zero Value with `iota`
+
+When `iota` starts at 0, the zero value of the type (from uninitialized variables, zero-value struct fields, or missing JSON fields) is indistinguishable from the first constant.
+
+```go
+// BAD
+type Status int
+const (
+    Active   Status = iota // 0 — same as zero value!
+    Inactive               // 1
+)
+type User struct {
+    Status Status // zero value is Active — but was it intentional?
+}
+
+// GOOD — reserve 0 for "unknown"
+type Status int
+const (
+    StatusUnknown  Status = iota // 0 — explicit unset sentinel
+    StatusActive                 // 1
+    StatusInactive               // 2
+)
+```
+
+## `recover()` Only Works in the Same Goroutine
+
+`recover()` can only catch panics in the goroutine where it's deferred. A panic in a child goroutine will crash the entire program — no parent goroutine can catch it.
+
+```go
+// BAD — recover() in main cannot catch panic in child goroutine
+func main() {
+    defer func() {
+        if r := recover(); r != nil {
+            fmt.Println("recovered:", r) // NEVER REACHED
+        }
+    }()
+    go func() {
+        panic("crash!") // crashes the whole program
+    }()
+    time.Sleep(time.Second)
+}
+
+// GOOD — each goroutine must recover its own panics
+func main() {
+    go func() {
+        defer func() {
+            if r := recover(); r != nil {
+                log.Printf("goroutine recovered: %v", r)
+            }
+        }()
+        panic("crash!") // recovered within this goroutine
+    }()
+    time.Sleep(time.Second)
+}
+```
+
+## `os.Exit` Skips Deferred Functions
+
+`os.Exit` terminates the process immediately. No deferred functions run — cleanup, flush, and close operations are skipped. `log.Fatal` calls `os.Exit(1)` internally and has the same problem.
+
+```go
+// BAD — deferred cleanup never runs
+func main() {
+    f, _ := os.Create("data.tmp")
+    defer f.Close()       // NEVER RUNS
+    defer os.Remove(f.Name()) // NEVER RUNS
+
+    if err := process(); err != nil {
+        log.Fatal(err) // calls os.Exit(1) — skips all defers!
+    }
+}
+
+// GOOD — return from main instead, or restructure so defers run
+func main() {
+    if err := run(); err != nil {
+        fmt.Fprintf(os.Stderr, "error: %v\n", err)
+        os.Exit(1) // defers in run() already ran when it returned
+    }
+}
+
+func run() error {
+    f, _ := os.Create("data.tmp")
+    defer f.Close()
+    return process()
+}
+```
+
+## `time.Time` Comparison: `==` vs `.Equal()`
+
+`time.Time` includes a monotonic clock reading. Two `time.Time` values representing the same instant may not be `==` if one has a monotonic component and the other doesn't (e.g., one from `time.Now()`, the other deserialized from JSON/database).
+
+```go
+// BAD — may fail even for the same instant
+t1 := time.Now()
+data, _ := t1.MarshalJSON()
+var t2 time.Time
+t2.UnmarshalJSON(data)
+fmt.Println(t1 == t2) // false! t1 has monotonic, t2 doesn't
+
+// GOOD — .Equal() ignores monotonic clock
+fmt.Println(t1.Equal(t2)) // true
+
+// Also: strip monotonic explicitly when storing/comparing
+t1 = t1.Round(0) // strips monotonic reading
+```
+
+## `sql.Rows` Must Be Closed
+
+`sql.Rows` MUST call `rows.Close()` — always defer it immediately after the query.
+
+Forgetting to close `sql.Rows` leaks database connections. The connection is held until `Rows` is garbage collected, but under load the connection pool exhausts first.
+
+```go
+// BAD — connection leak if rows aren't closed
+rows, err := db.Query("SELECT id FROM users")
+if err != nil { return err }
+for rows.Next() {
+    // ...
+}
+// rows never closed — connection leak!
+
+// GOOD — always defer Close
+rows, err := db.Query("SELECT id FROM users")
+if err != nil { return err }
+defer rows.Close()
+for rows.Next() {
+    // ...
+}
+if err := rows.Err(); err != nil { // don't forget to check rows.Err()
+    return err
+}
+```
+
+Also: use `db.QueryRow()` for single-row queries and `db.Exec()` for non-SELECT statements (INSERT, UPDATE, DELETE). Using `db.Query()` for non-SELECT leaks connections because the returned `Rows` is never iterated/closed.
+
+## Writing to a Closed Channel Panics
+
+Sending to a closed channel panics. Reading from a closed channel returns the zero value immediately (with `ok == false`).
+
+```go
+// BAD — panic: send on closed channel
+ch := make(chan int, 1)
+close(ch)
+ch <- 1 // panic!
+
+// GOOD — only the sender should close, never the receiver
+// Use a done channel or context to signal completion
+func producer(ch chan<- int, done <-chan struct{}) {
+    defer close(ch)
+    for i := 0; ; i++ {
+        select {
+        case ch <- i:
+        case <-done:
+            return
+        }
+    }
+}
+```
+
+**Rule of thumb:** Only the sender closes the channel. If multiple senders, use a `sync.Once` or coordinate with a `sync.WaitGroup`.
+
+## Closed Channel in `select` Causes Busy Loop
+
+A closed channel is always ready to receive (returns zero value). In a `select`, this causes the case to fire continuously — a CPU-burning busy loop.
+
+```go
+// BAD — after ch is closed, this loops at 100% CPU
+for {
+    select {
+    case v := <-ch: // fires continuously after ch closes
+        process(v)   // processes zero values forever
+    case <-done:
+        return
+    }
+}
+
+// GOOD — nil the channel after it closes
+for {
+    select {
+    case v, ok := <-ch:
+        if !ok {
+            ch = nil // nil channel blocks forever in select — disables this case
+            continue
+        }
+        process(v)
+    case <-done:
+        return
+    }
+}
+```
+
+## `select` with `default` Can Spin CPU
+
+A `select` with a `default` case never blocks. Inside a `for` loop, this creates a busy-wait spin loop that burns CPU.
+
+```go
+// BAD — spins at 100% CPU waiting for a message
+for {
+    select {
+    case msg := <-ch:
+        process(msg)
+    default:
+        // runs immediately when ch has nothing — tight loop!
+    }
+}
+
+// GOOD — remove default to block until a message arrives
+for {
+    select {
+    case msg := <-ch:
+        process(msg)
+    case <-ctx.Done():
+        return
+    }
+}
+
+// GOOD — if you need non-blocking check, add a small sleep or ticker
+for {
+    select {
+    case msg := <-ch:
+        process(msg)
+    default:
+        time.Sleep(10 * time.Millisecond) // yield CPU
+    }
+}
+```
+
+## Integer Conversion Silently Truncates
+
+Go integer conversions don't check for overflow — they silently truncate. This is especially dangerous when converting from user input or external data.
+
+```go
+// BAD — silent truncation
+var big int64 = 256
+small := int8(big)
+fmt.Println(small) // 0 — silently overflowed!
+
+var n int64 = math.MaxInt64
+n32 := int32(n)
+fmt.Println(n32) // -1 — silently wrapped!
+
+// GOOD — check bounds before converting
+func safeIntToInt32(n int64) (int32, error) {
+    if n < math.MinInt32 || n > math.MaxInt32 {
+        return 0, fmt.Errorf("value %d overflows int32", n)
+    }
+    return int32(n), nil
+}
+```
+
+## `filepath.Join` Does Not Prevent Path Traversal
+
+`filepath.Join` cleans the path (resolves `..`) but doesn't prevent escaping the base directory. User-supplied paths can traverse outside the intended root.
+
+```go
+// BAD — user can escape the base directory
+base := "/srv/files"
+userInput := "../../etc/passwd"
+path := filepath.Join(base, userInput)
+// path = "/etc/passwd" — escaped!
+
+// GOOD (Go 1.24+) — confine access to the base directory
+root, err := os.OpenRoot("/srv/files")
+if err != nil {
+    return err
+}
+defer root.Close()
+file, err := root.Open(userInput)
+if err != nil {
+    return err
+}
+defer file.Close()
+```
+
+For Go <1.24, use a lexical fallback only when `os.Root` is unavailable:
+
+```go
+func safePath(base, userInput string) (string, error) {
+    if userInput == "" || filepath.IsAbs(userInput) || !filepath.IsLocal(userInput) {
+        return "", fmt.Errorf("invalid relative path: %q", userInput)
+    }
+
+    path := filepath.Join(base, userInput)
+    rel, err := filepath.Rel(base, path)
+    if err != nil {
+        return "", fmt.Errorf("checking path: %w", err)
+    }
+    if rel == ".." || strings.HasPrefix(rel, ".."+string(os.PathSeparator)) {
+        return "", fmt.Errorf("path traversal attempt: %s", userInput)
+    }
+
+    return path, nil
+}
+```
+
+## Pointer Receiver Interface Satisfaction
+
+A value of type `T` cannot satisfy an interface that requires methods with `*T` receivers. But `*T` satisfies interfaces requiring either `T` or `*T` methods.
+
+```go
+type Sizer interface {
+    Size() int
+}
+
+type File struct{ size int }
+func (f *File) Size() int { return f.size } // pointer receiver
+
+var s Sizer
+s = File{}   // COMPILE ERROR: File does not implement Sizer (*File does)
+s = &File{}  // OK — *File has the Size method
+
+// This is because the compiler can't always take the address of a value
+// (e.g., map values, return values). Pointer receiver = pointer required.
+```
+
+## `regexp.MustCompile` in Hot Path
+
+Long-lived regexp MUST be compiled once at package level — not inside functions called repeatedly. Short-lived regexp used once (e.g., in a CLI or test) are acceptable inline.
+
+`regexp.MustCompile` compiles a regex every call. In a hot path (loop, HTTP handler), this is expensive and wasteful.
+
+```go
+// BAD — recompiles regex on every call
+func isEmail(s string) bool {
+    re := regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
+    return re.MatchString(s)
+}
+
+// GOOD — compile once at package level
+var emailRe = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
+
+func isEmail(s string) bool {
+    return emailRe.MatchString(s)
+}
+```
+
+## `init()` Ordering Is Fragile
+
+`init()` functions run in source file order within a package, and in dependency order across packages. But relying on this order creates brittle, hard-to-debug initialization sequences. Multiple `init()` in the same file run top-to-bottom, but across files it's alphabetical by filename — adding a file can change the order.
+
+```go
+// BAD — init() depends on another init() having run first
+var db *sql.DB
+
+func init() {
+    // Assumes config init() already ran — fragile!
+    db, _ = sql.Open("postgres", config.DatabaseURL)
+}
+
+// GOOD — use explicit initialization
+func main() {
+    cfg := loadConfig()
+    db := setupDatabase(cfg)
+    startServer(db)
+}
+```
+
+Prefer explicit initialization in `main()` over `init()`. Use `init()` only for truly self-contained setup (registering drivers, codecs).
+
+## Map Iteration Order Is Random
+
+Go deliberately randomizes map iteration order. Code that assumes a specific order will produce inconsistent results.
+
+```go
+// BAD — output order is random every run
+m := map[string]int{"a": 1, "b": 2, "c": 3}
+for k, v := range m {
+    fmt.Printf("%s=%d ", k, v) // different order each time!
+}
+
+// GOOD — sort keys when order matters
+keys := make([]string, 0, len(m))
+for k := range m {
+    keys = append(keys, k)
+}
+sort.Strings(keys)
+for _, k := range keys {
+    fmt.Printf("%s=%d ", k, m[k])
+}
+```
+
+This is especially dangerous in tests (non-deterministic output comparison), serialization (non-deterministic JSON/output), and logging (confusing diffs).
+
+## `fallthrough` in `switch` Executes Unconditionally
+
+Unlike C, Go's `switch` cases don't fall through by default. But when you explicitly use `fallthrough`, it executes the **next case body unconditionally** — it does not check the next case's condition.
+
+```go
+// Surprising: fallthrough doesn't check the next condition
+switch x := 5; {
+case x > 10:
+    fmt.Println(">10")
+    fallthrough
+case x > 0:
+    fmt.Println(">0")
+    fallthrough
+case x < 0:
+    fmt.Println("<0") // EXECUTES even though 5 is not < 0!
+}
+// Output: >0, <0
+
+// fallthrough is rarely needed. Prefer listing multiple values:
+switch status {
+case "active", "enabled":
+    enable()
+}
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/compilation.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/compilation.md
new file mode 100644
index 00000000..b08dbd68
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/compilation.md
@@ -0,0 +1,27 @@
+# Compilation Issues
+
+## Module Problems
+
+```bash
+go clean -modcache      # clean module cache
+go mod download         # re-download dependencies
+go mod verify           # verify dependencies
+go mod tidy             # tidy dependencies
+go mod why <package>    # why is this dependency here?
+```
+
+## CGO Issues
+
+```bash
+go env CGO_ENABLED                         # check CGO is enabled
+export CGO_CFLAGS="-I/usr/local/include"   # set CGO CFLAGS
+# macOS: brew install pkg-config
+# Ubuntu: apt install pkg-config
+```
+
+## Version Mismatch
+
+```bash
+go version              # check Go version
+go mod edit -go=1.21    # set minimum required version
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/concurrency-debug.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/concurrency-debug.md
new file mode 100644
index 00000000..aa91b744
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/concurrency-debug.md
@@ -0,0 +1,115 @@
+# Concurrency Debugging
+
+## Goroutine Leaks
+
+**Symptoms:** Memory slowly increasing, goroutine count growing, no obvious CPU spike.
+
+**Diagnosis:**
+
+Use pprof goroutine profile (see [pprof.md](./pprof.md)) with `?debug=2` for human-readable output, then look for goroutines stuck in `chan receive`.
+
+For Go 1.26 diagnostics, there is also an experimental goroutine leak profile. It is useful for production-oriented leak investigation, but is gated by `GOEXPERIMENT=goroutineleakprofile`; do not rely on it as default stable behavior.
+
+```bash
+curl http://localhost:6060/debug/pprof/goroutineleak?debug=2
+go tool pprof http://localhost:6060/debug/pprof/goroutineleak
+```
+
+Keep existing tools: `go.uber.org/goleak` in tests, `runtime.NumGoroutine()` for coarse monitoring, `/debug/pprof/goroutine?debug=2` for stack dumps, and `go test -race ./...` for race checks.
+
+```go
+// Programmatic monitoring — log goroutine count to detect leaks
+go func() {
+    for {
+        log.Printf("goroutines: %d", runtime.NumGoroutine())
+        time.Sleep(3 * time.Second)
+    }
+}()
+
+// In tests, use goleak to detect goroutine leaks
+// import "go.uber.org/goleak"
+// func TestMain(m *testing.M) { goleak.VerifyTestMain(m) }
+```
+
+**Common causes:**
+
+```go
+// 1. Unclosed channel — goroutine blocks forever
+// BAD
+for {
+    job := <-jobs
+    process(job)
+}
+// GOOD
+for {
+    select {
+    case job, ok := <-jobs:
+        if !ok { return }
+        process(job)
+    case <-ctx.Done():
+        return
+    }
+}
+
+// 2. Forgotten response body close — leaks HTTP connection
+// Always defer resp.Body.Close() after HTTP calls.
+// See production-debug.md for the correct pattern.
+
+// 3. time.After in hot loop — allocates a new timer each iteration
+// BAD
+for {
+    select {
+    case <-time.After(time.Second):
+        do()
+    }
+}
+// GOOD — reuse a ticker for repeated intervals
+ticker := time.NewTicker(time.Second)
+defer ticker.Stop()
+for {
+    select {
+    case <-ticker.C:
+        do()
+    case <-ctx.Done():
+        return
+    }
+}
+```
+
+## Race Conditions
+
+**Symptoms:** Intermittent failures, "sometimes works sometimes doesn't", different results on different machines.
+
+**Diagnosis:** Race conditions MUST be tested with the `-race` flag:
+
+```bash
+go test -race ./...
+go run -race main.go
+# Race detector slows code ~10x but finds data races reliably
+```
+
+**Common patterns:**
+
+- Shared map without mutex
+- Shared variable without atomic
+- Publishing reference before initialization
+- go func() accessing outer variables without synchronization
+
+## Deadlocks
+
+**Symptoms:** Program hangs, goroutines stuck in "chan receive" or "mutex lock".
+
+**Diagnosis:**
+
+```bash
+curl http://localhost:6060/debug/pprof/goroutine?debug=2
+
+# Or programmatic
+runtime.Stack(buf, true)
+```
+
+**Common patterns:**
+
+1. **Circular wait** — A waits for B, B waits for A
+2. **Forgotten channel send** — sender goroutine exited
+3. **Wrong lock order** — always acquire locks in the same order
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/diagnostic-tools.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/diagnostic-tools.md
new file mode 100644
index 00000000..649942e8
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/diagnostic-tools.md
@@ -0,0 +1,118 @@
+# Diagnostic Tools
+
+## Runtime Diagnostics (GODEBUG)
+
+### Go documentation command
+
+Use `go doc`, not `go tool doc`. Go 1.26 removed the old `cmd/doc` / `go tool doc` path.
+
+### GC Tracing
+
+```bash
+GODEBUG=gctrace=1 ./app
+```
+
+**Output:**
+
+```
+gc 123 @45.67s 4%: 0.8+10+0.3 ms clock, 6+5/10/0 ms cpu, 512->300->150 MB
+```
+
+| Field            | Meaning                                         |
+| ---------------- | ----------------------------------------------- |
+| 4%               | GC CPU overhead (if >10%, over-allocating)      |
+| 512->300->150 MB | Heap at GC start -> heap at GC end -> live heap |
+| Large pause      | Allocation storm                                |
+
+### Scheduler Tracing
+
+```bash
+GODEBUG=schedtrace=1000,scheddetail=1 ./app
+```
+
+| Signal               | Meaning                            |
+| -------------------- | ---------------------------------- |
+| runqueue high        | CPU saturation, goroutines waiting |
+| idleprocs=0          | Fully busy, at capacity            |
+| spinningthreads      | Lock contention                    |
+| threads > gomaxprocs | Blocking syscalls                  |
+
+### GOTRACEBACK
+
+Get full stack traces on panic:
+
+```bash
+GOTRACEBACK=all ./app
+```
+
+| Level    | Shows                                 |
+| -------- | ------------------------------------- |
+| `none`   | No stack traces                       |
+| `single` | Current goroutine only (default)      |
+| `all`    | All goroutines (useful for deadlocks) |
+| `system` | All goroutines + runtime frames       |
+
+---
+
+## Delve Debugger
+
+### Installation
+
+```bash
+go install github.com/go-delve/delve/cmd/dlv@latest
+```
+
+### Basic Usage
+
+```bash
+dlv debug ./cmd/myapp          # debug a program
+dlv test ./mypackage           # debug a test
+dlv attach 12345               # attach to running process
+dlv exec ./myapp -- --flag=v   # execute binary with args
+```
+
+### Common Commands
+
+```
+break main.main      # set breakpoint
+break file.go:42     # break at line
+continue             # continue execution
+next                 # step over (n)
+step                 # step into (s)
+stepout              # step out
+print variable       # print variable
+locals               # print all locals
+args                 # print function arguments
+goroutines           # list all goroutines
+goroutine 5          # switch to goroutine 5
+stack                # show stack trace
+```
+
+### IDE Integration
+
+**VS Code:**
+
+```json
+// .vscode/launch.json
+{
+  "version": "0.2.0",
+  "configurations": [
+    {
+      "name": "Launch Package",
+      "type": "go",
+      "request": "launch",
+      "mode": "auto",
+      "program": "${workspaceFolder}",
+      "env": { "GOTRACEBACK": "all" }
+    }
+  ]
+}
+```
+
+**GoLand:** Run -> Edit Configurations -> Go Build. Click gutter to set breakpoints. Use Debugger tab.
+
+---
+
+## Advanced Analysis
+
+→ See `samber/cc-skills-golang@golang-benchmark` skill (compiler-analysis.md) for detailed guides on escape analysis interpretation, assembly inspection, and compiler diagnostics (SSA dump, inlining decisions). See also trace.md for execution tracer analysis.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/methodology.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/methodology.md
new file mode 100644
index 00000000..ce7c3b14
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/methodology.md
@@ -0,0 +1,236 @@
+# General Debugging Methodology
+
+For any bug, follow this systematic process:
+
+## Step 1: Understand Expected vs Actual
+
+Before touching code, articulate clearly:
+
+- What **should** happen?
+- What **actually** happens?
+- What **changed** recently?
+
+```bash
+# What changed recently?
+git log --oneline -20
+git diff HEAD~5
+
+# Binary search for the breaking commit
+git bisect start
+git bisect bad          # current commit is broken
+git bisect good abc123  # this commit was working
+# git bisect will walk you to the breaking commit
+```
+
+## Step 2: Get the Full Error
+
+```bash
+# Full build errors
+go build ./... 2>&1
+
+# Verbose test output
+go test ./... -v 2>&1
+
+# Static analysis
+go vet ./...
+
+# Run linters — see the golang-lint skill for configuration
+golangci-lint run ./...
+```
+
+Run `golangci-lint` early in your debugging workflow. It catches unchecked errors, suspicious constructs, and many other issues that are easy to miss by reading code. See the `samber/cc-skills-golang@golang-lint` skill for configuration and usage.
+
+## Step 3: Isolate the Problem
+
+Narrow the scope before investigating deeper:
+
+```bash
+# Does a single test fail?
+go test -run TestSpecificName -v ./pkg/...
+
+# Does it fail without cache?
+go test -count=1 -run TestSpecificName ./pkg/...
+
+# Is it a specific package?
+go build ./pkg/suspect/...
+
+# Is it flaky? Run multiple times
+go test -count=10 -run TestSuspect ./pkg/...
+```
+
+Write more tests if you suspect missing test cases or need to test something in different conditions.
+
+## Step 4: Check External Dependencies
+
+Sometimes the bug is not in your code. Before diving deeper, verify that external components behave as expected:
+
+```bash
+# Reproduce an API call outside your app
+curl -v -X POST https://api.example.com/endpoint \
+  -H "Content-Type: application/json" \
+  -d '{"key": "value"}'
+
+# Check database content directly
+psql -h localhost -U myuser -d mydb -c "SELECT * FROM orders WHERE id = 123"
+# Or: mysql, mongosh, redis-cli, etc.
+# Or use a database MCP server to query interactively
+
+# Test connectivity and DNS resolution
+dig api.example.com
+nc -zv api.example.com 443
+
+# Check if an external service is responding at all
+curl -o /dev/null -s -w "HTTP %{http_code} in %{time_total}s\n" https://api.example.com/health
+
+# Inspect message queue state
+rabbitmqctl list_queues
+# Or: kafka-console-consumer, redis-cli LLEN, etc.
+
+# Check certificate validity
+openssl s_client -connect api.example.com:443 -brief
+
+# Verify environment variables and config
+env | grep DATABASE
+env | grep API_KEY
+```
+
+**Common external causes:**
+
+- API contract changed (new required field, different response shape, deprecated endpoint)
+- Database schema drift (missing column, changed type, new constraint, migration not applied)
+- Expired or rotated credentials, tokens, or certificates
+- DNS resolution failure or stale DNS cache
+- Rate limiting or quota exhaustion
+- External service degraded (slow responses, partial failures, 5xx errors)
+- Message queue full, consumer lag, or rebalancing
+- Different behavior between environments (staging vs production config, feature flags)
+- Clock skew affecting JWT validation, cache TTLs, or scheduled jobs
+- TLS/mTLS misconfiguration or CA bundle mismatch
+- Network policy or firewall rule change blocking traffic
+- Proxy or load balancer misconfiguration (wrong backend, sticky sessions, health check)
+- Disk full or read-only filesystem
+- File permissions changed
+- OOM killer terminated a dependency (database, cache, sidecar)
+- Docker/K8s: wrong image tag, missing env var, resource limits, liveness probe misconfigured
+- Third-party SDK or library upgrade with breaking behavioral change
+- Locale, timezone, or encoding mismatch between systems
+- Connection pool exhaustion (database, HTTP, gRPC)
+- Upstream returning cached/stale data
+- Network issue. Webhook or callback URL changed or unreachable
+
+## Step 5: Check Observability Tools
+
+Production debugging MUST start with observability data. The project may already use observability tools that have the answer — look for imports or dependencies like `prometheus`, `opentelemetry`, `datadog`, `sentry`, `elastic/apm` in the codebase. Even if you don't see them in code, the developer may have them deployed separately.
+
+If the information is missing, **ask the user** what monitoring and observability tools they use. Common stacks:
+
+- **Prometheus + Grafana** — Dashboards may show error rate spikes, latency changes, resource saturation. Query examples:
+
+  ```promql
+  rate(http_requests_total{status=~"5.."}[5m])           # error rate
+  histogram_quantile(0.99, rate(http_duration_seconds_bucket[5m]))  # p99 latency
+  go_goroutines                                           # goroutine count over time
+  go_memstats_alloc_bytes                                 # heap allocations
+  rate(go_gc_duration_seconds_sum[5m])                    # GC pressure
+  ```
+
+- **Datadog** — APM traces, error tracking, and infrastructure metrics are available. Query examples:
+
+  ```
+  avg:trace.http.request.duration{service:myapp} by {resource_name}
+  sum:trace.http.request.errors{service:myapp}.as_count()
+  avg:runtime.go.num_goroutine{service:myapp}
+  ```
+
+- **Sentry** — Captured exceptions, breadcrumbs, and error grouping are available. Sentry often captures the full stack trace and context of the first occurrence.
+- **ELK (Elasticsearch + Logstash + Kibana)** — Structured logs can be searched for error patterns:
+
+  ```
+  level:error AND service:myapp AND @timestamp:[now-1h TO now]
+  ```
+
+- **OpenTelemetry / Jaeger / Zipkin** — Distributed traces show latency breakdowns across services, failed spans, and propagation issues.
+
+If the user has an MCP server for any of these tools (Datadog MCP, Grafana MCP, etc.), interactive queries may be available through it.
+
+## Step 6: Compare with Working Code
+
+Before forming a hypothesis, find similar code that **works**:
+
+- Search the codebase for analogous functionality that doesn't have the bug
+- Read the working reference implementation **completely** — don't skim
+- List **every difference** between the working code and the broken code
+- Check: are the dependencies the same? The config? The initialization order? The error handling?
+
+Often the bug becomes obvious when you see what the working version does differently.
+
+## Step 7: Form a Hypothesis and Test It
+
+- Form a **single, specific** hypothesis with clear reasoning
+- Add targeted logging or a focused test
+- Change **one thing**, observe, confirm or reject
+- If the hypothesis was wrong, **revert the change** — don't stack fixes on top of failed attempts
+
+## Step 8: Trace to Root Cause
+
+When the symptom appears deep in the call stack, don't fix where the error surfaces. Trace backward:
+
+1. **Find the immediate cause** — what line panics or returns the wrong value?
+2. **Ask "what called this?"** — trace one level up the call chain
+3. **Keep tracing** — repeat until you find where the invalid data **originated**, not where it was **consumed**
+4. **Fix at the source** — the fix belongs where the bad value was created, not where it caused a crash
+
+```go
+// Example: panic in handler — but the bug is in the constructor
+// ✗ Bad — fixing at the symptom
+func (s *Server) Handle(w http.ResponseWriter, r *http.Request) {
+    if s.db == nil {  // nil check masks the real bug
+        http.Error(w, "db unavailable", 500)
+        return
+    }
+    // ...
+}
+
+// ✓ Good — fixing at the source
+func NewServer(db *sql.DB) *Server {
+    if db == nil {
+        panic("NewServer: db must not be nil")  // fail fast at construction
+    }
+    return &Server{db: db}
+}
+```
+
+When you can't trace manually, add temporary instrumentation:
+
+```go
+// Log the full call chain before the dangerous operation
+func suspectFunction(val string) {
+    fmt.Fprintf(os.Stderr, "DEBUG suspectFunction: val=%q\n%s\n", val, debug.Stack())
+    // ...
+}
+```
+
+## Step 9: Fix and Verify
+
+- Fix the root cause, not the symptom
+- The failing test from step 1 should now pass
+- Run the full test suite to check for regressions
+
+## Step 10: Defense-in-Depth
+
+After fixing a bug, ask: "How do I make this bug structurally impossible?" A single fix at one layer can be bypassed by different code paths or future refactoring. Add validation at multiple layers:
+
+1. **Entry point** — reject invalid input at public API boundaries (`New*` constructors, exported functions)
+2. **Business logic** — assert preconditions inside internal functions that receive the data
+3. **Runtime guards** — use build tags or env checks to catch dangerous operations in tests (e.g., refuse writes outside temp dirs)
+4. **Observability** — add structured logging or metrics so the same class of bug is instantly visible if it recurs
+
+Not every fix needs all four layers — use judgment. But when a bug could cause data loss, corruption, or security issues, multi-layer defense is worth the cost.
+
+## When You're Stuck: Escalation Protocol
+
+If your fix doesn't work:
+
+- **< 3 failed attempts:** Return to Step 1. You misidentified the root cause. Gather more evidence.
+- **>= 3 failed attempts:** Stop fixing. The problem is likely architectural, not a simple bug. Step back and question your assumptions about how the system works. Ask: "Is the design fundamentally sound, or am I patching a broken abstraction?"
+- **Each fix reveals a new problem:** You're chasing symptoms, not the root cause. See the Red Flags section in [SKILL.md](./SKILL.md).
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/performance-debug.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/performance-debug.md
new file mode 100644
index 00000000..1d363298
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/performance-debug.md
@@ -0,0 +1,46 @@
+# Performance Troubleshooting
+
+## CPU Profiling
+
+Use pprof CPU profile to capture a 30s sample (see [pprof.md](./pprof.md) for commands), then inspect with `top`, `web`, or `list funcName`.
+
+**Common CPU hogs:**
+
+1. JSON marshal/unmarshal in hot path — preallocate buffers, use faster libraries
+2. Reflection in critical path
+3. Unnecessary allocations — use sync.Pool
+4. O(n^2) hidden in nested loops
+5. Too many syscalls — batch operations
+
+## Memory Profiling
+
+Use pprof heap profile (see [pprof.md](./pprof.md)). Compare heap snapshots over time with `go tool pprof -base heap1.prof heap2.prof` to find growth. Use escape analysis (see [diagnostic-tools.md](./diagnostic-tools.md)) to find unexpected heap allocations in hot paths.
+
+**Common memory leaks:**
+
+1. Unbounded cache without eviction
+2. Growing slices in loops (forgetting to reset)
+3. Global maps never cleared
+4. String concatenation in loops (use `strings.Builder`)
+5. Large structs passed by value
+
+## Lock Contention
+
+**Symptoms:** CPU high but throughput low, latency increases with load, multiple cores don't help.
+
+**Enable profiling in code:**
+
+```go
+runtime.SetMutexProfileFraction(1)
+runtime.SetBlockProfileRate(1)
+```
+
+Then use pprof mutex and block profiles (see [pprof.md](./pprof.md)).
+
+**Solutions:**
+
+1. Reduce critical section — hold lock for minimal time
+2. Sharding — multiple locks for different data
+3. `sync.Map` — for read-heavy workloads
+4. `atomic` — for simple counters
+5. `RWMutex` — when reads >> writes
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/pprof.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/pprof.md
new file mode 100644
index 00000000..12a56557
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/pprof.md
@@ -0,0 +1,123 @@
+# pprof Reference
+
+## Enable pprof HTTP Server
+
+Pprof endpoints MUST be protected with basic auth — NEVER expose them publicly. They leak sensitive runtime information (goroutine stacks, memory contents) and can be abused to DoS your service (CPU profiling is expensive). Pprof SHOULD be toggled via a `PPROF_ENABLED` environment variable.
+
+### Quick Setup (Development)
+
+```go
+import _ "net/http/pprof"
+
+func main() {
+    go func() {
+        log.Println(http.ListenAndServe("localhost:6060", nil))
+    }()
+    // ... rest of app
+}
+```
+
+### Secure Setup (Production)
+
+For production, protect endpoints with basic auth:
+
+```go
+import "net/http/pprof"
+
+func setupPprof(mux *http.ServeMux) {
+    if os.Getenv("PPROF_ENABLED") != "true" {
+        return
+    }
+
+    // Protect pprof endpoints with basic auth — never expose unauthenticated
+    username := os.Getenv("PPROF_USERNAME")
+    password := os.Getenv("PPROF_PASSWORD")
+    if username == "" || password == "" {
+        panic("PPROF_USERNAME and PPROF_PASSWORD must be set when pprof is enabled")
+    }
+    auth := basicAuth(username, password)
+
+    mux.Handle("/debug/pprof/", auth(http.HandlerFunc(pprof.Index)))
+    mux.Handle("/debug/pprof/cmdline", auth(http.HandlerFunc(pprof.Cmdline)))
+    mux.Handle("/debug/pprof/profile", auth(http.HandlerFunc(pprof.Profile)))
+    mux.Handle("/debug/pprof/symbol", auth(http.HandlerFunc(pprof.Symbol)))
+    mux.Handle("/debug/pprof/trace", auth(http.HandlerFunc(pprof.Trace)))
+
+    slog.Info("pprof endpoints enabled (basic auth required)")
+}
+
+// basicAuth wraps an http.Handler with HTTP Basic Authentication.
+func basicAuth(username, password string) func(http.Handler) http.Handler {
+    return func(next http.Handler) http.Handler {
+        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+            u, p, ok := r.BasicAuth()
+            if !ok || u != username || subtle.ConstantTimeCompare([]byte(p), []byte(password)) != 1 {
+                w.Header().Set("WWW-Authenticate", `Basic realm="pprof"`)
+                http.Error(w, "unauthorized", http.StatusUnauthorized)
+                return
+            }
+            next.ServeHTTP(w, r)
+        })
+    }
+}
+```
+
+## Profile Types
+
+| Profile | Command | What It Shows |
+| --- | --- | --- |
+| **CPU** | `go tool pprof profile` | Where CPU time is spent |
+| **Heap** | `go tool pprof heap` | Memory allocations, live objects |
+| **Goroutine** | `go tool pprof goroutine` | Stack traces of all goroutines |
+| **Block** | `go tool pprof block` | Blocking operations (needs SetBlockProfileRate) |
+| **Mutex** | `go tool pprof mutex` | Lock contention (needs SetMutexProfileFraction) |
+| **Alloc** | `go tool pprof -alloc_space heap` | Cumulative allocations (not current heap) |
+
+## Capturing Profiles
+
+```bash
+# CPU profiles SHOULD capture at least 30 seconds for meaningful data (30s default).
+# Ensure your HTTP server's request timeout exceeds the capture duration.
+curl http://localhost:6060/debug/pprof/profile?seconds=30 > cpu.prof
+
+# Heap snapshot
+curl http://localhost:6060/debug/pprof/heap > heap.prof
+
+# Goroutine dump (human-readable)
+curl http://localhost:6060/debug/pprof/goroutine?debug=2 > goroutines.txt
+
+# Goroutine profile (for pprof analysis)
+curl http://localhost:6060/debug/pprof/goroutine > goroutine.prof
+
+# Go 1.26 experimental goroutine leak profile, only with GOEXPERIMENT=goroutineleakprofile
+curl http://localhost:6060/debug/pprof/goroutineleak?debug=2
+go tool pprof http://localhost:6060/debug/pprof/goroutineleak
+
+# Mutex contention
+curl http://localhost:6060/debug/pprof/mutex > mutex.prof
+
+# Block profile
+curl http://localhost:6060/debug/pprof/block > block.prof
+```
+
+## Analyzing and Interpreting Profiles
+
+→ See `samber/cc-skills-golang@golang-benchmark` skill (pprof.md) for interpreting profiles: `top`, `list`, `peek`, common profile patterns (flat vs cum, GC churn, memory leaks), and compiler diagnostics. See also compiler-analysis.md for escape analysis and inlining decisions.
+
+**Quick start:**
+
+```bash
+go tool pprof cpu.prof          # interactive analysis
+go tool pprof -http=:8080 cpu.prof  # graphical flamegraph
+go tool pprof -base heap1.prof heap2.prof  # compare heap snapshots
+```
+
+## Remote Profiling (Production)
+
+For production servers, replace `localhost:6060` with your server address and use basic auth credentials.
+
+**Safety:** idle pprof endpoints have low overhead, but profile captures are not free. CPU profiling samples for the requested duration, heap profiles may trigger extra work, and block/mutex profiles add runtime overhead when enabled.
+
+---
+
+→ See `samber/cc-skills-golang@golang-observability` skill for continuous profiling with Pyroscope. → See `samber/cc-skills-golang@golang-benchmark` skill for investigation session setup and Prometheus-based performance tracking.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/production-debug.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/production-debug.md
new file mode 100644
index 00000000..d2940cd7
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/production-debug.md
@@ -0,0 +1,126 @@
+# Production Debugging
+
+## Production Debugging Checklist
+
+When paged for a production issue:
+
+### Step 1: Capture Immediately (don't restart!)
+
+Capture all profiles before restarting the process. The curl commands in [pprof.md](./pprof.md) can be used targeting your production server address. At minimum, capture: goroutine dump (`?debug=2`), heap, CPU (30s), and mutex profiles.
+
+### Step 2: System Metrics
+
+```bash
+ps aux | grep myapp
+lsof -p PID | wc -l       # file descriptors
+ss -s                       # socket summary
+netstat -an | grep ESTABLISHED | wc -l
+```
+
+### Step 3: Analyze Locally
+
+Download the captured `.prof` files and analyze with `go tool pprof` (see [pprof.md](./pprof.md)).
+
+---
+
+## Logging & Observability
+
+### Strategic Log Placement
+
+Place logs at **component boundaries**, not sprinkled randomly. The goal is to see data entering and exiting each layer, so you can identify exactly which component corrupts or drops it:
+
+```go
+// 1. Function entry/exit with key parameters
+func ProcessOrder(ctx context.Context, orderID string) error {
+    log.Printf("ProcessOrder: start orderID=%s", orderID)
+    defer log.Printf("ProcessOrder: done orderID=%s", orderID)
+    // ...
+}
+
+// 2. Before and after external calls
+log.Printf("calling payment API for order %s", orderID)
+resp, err := paymentClient.Charge(ctx, req)
+if err != nil {
+    log.Printf("payment API: err=%v", err)
+} else {
+    log.Printf("payment API: status=%d", resp.StatusCode)
+}
+
+// 3. At decision points
+if user.IsAdmin {
+    log.Printf("admin path for user %s", user.ID)
+}
+```
+
+### Structured Logging (Go 1.21+)
+
+```go
+import "log/slog"
+
+slog.Info("processing request",
+    "method", r.Method,
+    "path", r.URL.Path,
+    "user_id", userID,
+)
+
+slog.Error("database query failed",
+    "err", err,
+    "query", query,
+    "duration_ms", elapsed.Milliseconds(),
+)
+```
+
+### Request ID Tracing
+
+```go
+type ctxKey string
+
+func WithRequestID(ctx context.Context, id string) context.Context {
+    return context.WithValue(ctx, ctxKey("request_id"), id)
+}
+
+func RequestID(ctx context.Context) string {
+    id, _ := ctx.Value(ctxKey("request_id")).(string)
+    return id
+}
+```
+
+---
+
+## Network & HTTP Debugging
+
+### HTTP Client Issues
+
+```go
+// 1. HTTP clients MUST set timeouts — default http.Client has NO timeout
+client := &http.Client{
+    Timeout: 30 * time.Second,
+    Transport: &http.Transport{
+        DialContext:          (&net.Dialer{Timeout: 5 * time.Second}).DialContext,
+        TLSHandshakeTimeout: 5 * time.Second,
+        IdleConnTimeout:     90 * time.Second,
+        MaxIdleConns:        100,
+        MaxIdleConnsPerHost: 10,
+    },
+}
+
+// 2. Response body MUST be closed
+resp, err := client.Do(req)
+if err != nil {
+    return err
+}
+defer resp.Body.Close()
+
+// 3. Read body on error status (for error messages from server)
+if resp.StatusCode >= 400 {
+    body, _ := io.ReadAll(resp.Body)
+    return fmt.Errorf("API error %d: %s", resp.StatusCode, body)
+}
+
+// 4. Dump full request/response for debugging
+import "net/http/httputil"
+dump, _ := httputil.DumpRequestOut(req, true)
+log.Printf("request:\n%s", dump)
+dump, _ = httputil.DumpResponse(resp, true)
+log.Printf("response:\n%s", dump)
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/testing-debug.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/testing-debug.md
new file mode 100644
index 00000000..02787654
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-troubleshooting/references/testing-debug.md
@@ -0,0 +1,97 @@
+# Test-Driven Debugging
+
+A failing test MUST be written before fixing a bug. Writing a failing test is often the fastest debugging path. It gives you a reproducible, isolated environment.
+
+## Reproduce the Bug in a Test
+
+```go
+func TestBugDescription(t *testing.T) {
+    // Setup: exact conditions that trigger the bug
+    svc := NewService(testConfig)
+
+    // Act: the operation that fails
+    result, err := svc.Process(badInput)
+
+    // Assert: what should happen
+    if err != nil {
+        t.Fatalf("unexpected error: %v", err)
+    }
+    if result.Status != "ok" {
+        t.Errorf("got status %q, want %q", result.Status, "ok")
+    }
+}
+```
+
+## Expand Edge Cases with Table Tests
+
+When debugging, add edge cases to find the boundary of the bug:
+
+```go
+tests := []struct {
+    name    string
+    input   string
+    want    time.Duration
+    wantErr bool
+}{
+    {"valid", "5s", 5 * time.Second, false},
+    {"empty", "", 0, true},
+    {"negative", "-1s", -time.Second, false},
+    {"zero", "0s", 0, false},
+    {"overflow", "99999999h", 0, true},
+    {"whitespace", " 5s ", 0, true},
+}
+for _, tt := range tests {
+    t.Run(tt.name, func(t *testing.T) {
+        got, err := ParseDuration(tt.input)
+        if (err != nil) != tt.wantErr {
+            t.Errorf("error = %v, wantErr %v", err, tt.wantErr)
+        }
+        if got != tt.want {
+            t.Errorf("got %v, want %v", got, tt.want)
+        }
+    })
+}
+```
+
+## Useful Test Flags
+
+```bash
+go test -v ./...                          # verbose output
+go test -run TestName -v ./pkg/...        # single test
+go test -count=1 ./...                    # disable cache
+go test -timeout 10s ./...                # short timeout (find hangs)
+go test -parallel 1 ./...                 # sequential execution
+go test -race ./...                       # race detector
+go test -cover ./...                      # coverage summary
+go test -coverprofile=c.out ./... && go tool cover -html=c.out  # coverage report
+go test -failfast ./...                   # stop on first failure
+go test -shuffle=on ./...                # randomize test order (Go 1.17+)
+```
+
+## Debugging Flaky Tests
+
+Flaky tests (pass sometimes, fail sometimes) are usually caused by one of:
+
+1. **Shared mutable state between tests** — global variables, package-level maps, singletons
+   - Fix: reset state in `TestMain` or use `t.Cleanup`
+2. **Test order dependence** — one test sets up state another test relies on
+   - Diagnose: `go test -run TestSuspect -count=1` (run in isolation)
+   - Diagnose: `go test -shuffle=on` (randomize order)
+   - Fix: each test must set up its own preconditions
+3. **Timing sensitivity** — `time.Sleep` in tests, race between goroutines
+   - Fix: use channels/waitgroups to synchronize, not sleeps
+4. **Port conflicts** — tests binding to fixed ports
+   - Fix: use port `0` and read the assigned port
+5. **File system pollution** — tests writing to shared temp directories
+   - Fix: use `t.TempDir()` for per-test directories
+
+```bash
+# Confirm flakiness by running many times
+go test -count=100 -run TestSuspect ./pkg/... -failfast
+
+# Check for parallelism issues
+go test -parallel 1 -count=10 ./pkg/...
+
+# Check for order dependence
+go test -shuffle=on ./pkg/...
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/SKILL.md
new file mode 100644
index 00000000..14ef5b5a
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/SKILL.md
@@ -0,0 +1,225 @@
+---
+name: golang-uber-dig
+description: "Implements dependency injection in Golang using uber-go/dig — reflection-based container, Provide/Invoke, dig.In/dig.Out parameter and result objects, named values, value groups, optional dependencies, scopes, and Decorate. Apply when using or adopting uber-go/dig, when the codebase imports `go.uber.org/dig`, or when wiring an application graph at startup. For higher-level lifecycle and modules, see `samber/cc-skills-golang@golang-uber-fx` skill."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.0"
+  openclaw:
+    emoji: "⛏"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "1.19.0"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs
+---
+
+**Persona:** You are a Go architect wiring an application graph with dig. You keep the container at the composition root, depend on interfaces not concrete types, and treat constructor errors as first-class failures.
+
+# Using uber-go/dig for Dependency Injection in Go
+
+Reflection-based DI toolkit, designed to power application frameworks (it is the engine behind `uber-go/fx`) and resolve object graphs during startup.
+
+**Official Resources:**
+
+- [pkg.go.dev/go.uber.org/dig](https://pkg.go.dev/go.uber.org/dig)
+- [github.com/uber-go/dig](https://github.com/uber-go/dig)
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+```bash
+go get go.uber.org/dig
+```
+
+## dig vs. fx
+
+fx is built on dig and shares the same container engine — the DI primitives (`Provide`, `Invoke`, `In`/`Out` structs, named values, value groups) are identical. `fx.In`/`fx.Out` are re-exports of `dig.In`/`dig.Out`.
+
+What fx adds on top of dig:
+
+| Concern | dig | fx |
+| --- | --- | --- |
+| DI container | ✅ `dig.New()` | ✅ (embedded) |
+| Lifecycle hooks | ❌ | ✅ `fx.Lifecycle` OnStart/OnStop |
+| Module system | ❌ | ✅ `fx.Module` with scoped decorators |
+| Signal-aware run loop | ❌ | ✅ `app.Run()` blocks on SIGINT/SIGTERM |
+| Structured event logging | ❌ | ✅ `fx.WithLogger` / `fxevent` |
+| Startup/shutdown timeout | ❌ | ✅ `fx.StartTimeout` / `fx.StopTimeout` |
+
+**Choose dig** when you need the wiring graph only: CLI tools, libraries exposing a container to callers, test harnesses, or embedding DI into an existing app that manages its own lifecycle.
+
+**Choose fx** for long-running services (HTTP servers, workers, daemons) — lifecycle and signal handling are non-negotiable there. See `samber/cc-skills-golang@golang-uber-fx` skill.
+
+## Container
+
+```go
+import "go.uber.org/dig"
+
+c := dig.New()
+```
+
+Useful options: `dig.DeferAcyclicVerification()` (faster startup), `dig.RecoverFromPanics()` (turn panics into `dig.PanicError`), `dig.DryRun(true)` (validate without invoking).
+
+## Provide and Invoke
+
+```go
+// Register a constructor — lazy, only runs when its output is needed
+err := c.Provide(func(cfg *Config) (*sql.DB, error) {
+    return sql.Open("postgres", cfg.DSN)
+})
+
+// Pull a service out of the container by asking for it as a function parameter
+err = c.Invoke(func(db *sql.DB) error {
+    return db.Ping()
+})
+```
+
+Constructors are **lazy** and **memoized**: each output type is built once and shared (singleton per container). `Provide` errors at registration if the constructor is malformed; `Invoke` returns the constructor's error wrapped with the dependency path that triggered it.
+
+A dig constructor is any function. Inputs are dependencies, outputs are provided types. `error` (last return) signals construction failure. Follow "accept interfaces, return structs".
+
+## Parameter Objects with `dig.In`
+
+Once a constructor has 4+ dependencies, embed `dig.In` to group them as struct fields and tag fields:
+
+```go
+type HandlerParams struct {
+    dig.In
+
+    Logger *zap.Logger
+    DB     *sql.DB
+    Cache  *redis.Client `optional:"true"`           // zero value if not provided
+    DBRO   *sql.DB       `name:"readonly"`           // named dependency
+    Routes []http.Handler `group:"routes"`           // value group
+}
+
+func NewHandler(p HandlerParams) *Handler { /* ... */ }
+```
+
+Tags: `name:"..."`, `optional:"true"`, `group:"..."`.
+
+## Result Objects with `dig.Out`
+
+Return several values from one constructor and attach `name`/`group` tags to results:
+
+```go
+type ConnResult struct {
+    dig.Out
+
+    ReadWrite *sql.DB `name:"primary"`
+    ReadOnly  *sql.DB `name:"readonly"`
+}
+
+func NewConnections(cfg *Config) (ConnResult, error) { /* ... */ }
+```
+
+## Named Values
+
+Two providers of the same type collide. Disambiguate with `dig.Name`:
+
+```go
+c.Provide(NewPrimaryDB,  dig.Name("primary"))
+c.Provide(NewReadOnlyDB, dig.Name("readonly"))
+```
+
+Consume by adding `name:"primary"` / `name:"readonly"` to a `dig.In` field.
+
+## Value Groups
+
+Many providers, one consumer slice — typical for HTTP handlers, health checks, migrations:
+
+```go
+type RouteResult struct {
+    dig.Out
+    Handler http.Handler `group:"routes"`
+}
+
+func NewUserHandler(db *sql.DB) RouteResult { /* ... */ }
+func NewPostHandler(db *sql.DB) RouteResult { /* ... */ }
+
+type ServerParams struct {
+    dig.In
+    Routes []http.Handler `group:"routes"`
+}
+```
+
+**Flatten** — append `,flatten` (e.g. `group:"routes,flatten"`) to unwrap a slice instead of nesting it. Group order is **not guaranteed**; if order matters, provide an explicit ordered slice from a single constructor.
+
+## Provide as Interface (`dig.As`)
+
+Register a concrete constructor and expose it under one or more interfaces without a separate adapter:
+
+```go
+c.Provide(NewPostgresDB, dig.As(new(Database), new(io.Closer)))
+// Consumers ask for Database or io.Closer; *PostgresDB stays hidden.
+```
+
+## Full Application Example
+
+```go
+func main() {
+    c := dig.New()
+
+    must(c.Provide(NewConfig))
+    must(c.Provide(NewLogger))
+    must(c.Provide(NewDatabase))
+    must(c.Provide(NewServer))
+
+    err := c.Invoke(func(srv *http.Server) error {
+        return srv.ListenAndServe()
+    })
+    if err != nil {
+        log.Fatal(err)
+    }
+}
+
+func must(err error) { if err != nil { panic(err) } }
+```
+
+dig has **no built-in lifecycle**. If you need OnStart/OnStop hooks, signal handling, and graceful shutdown, use fx — see `samber/cc-skills-golang@golang-uber-fx` skill.
+
+For Decorate, Scopes, optional deps, error helpers, and Visualize, see [advanced.md](./references/advanced.md).
+
+## Best Practices
+
+1. Keep the container at the composition root — never pass `*dig.Container` as a parameter; treat it like a plumbing detail of `main()`. Service-locator patterns defeat the testability gains of DI.
+2. Depend on interfaces, not concrete types — lets you swap implementations in tests without touching production code, and lets you use `dig.As` to expose narrow interfaces from wide structs.
+3. Prefer parameter objects (`dig.In` structs) once a constructor has 4+ dependencies — call sites stay readable and adding a new dependency is a one-line change instead of a signature break.
+4. Group registration by module (one file per module that calls `c.Provide` for its types) — review and refactoring become a per-module concern, and you can extract a module into a fx.Module later without rewriting wiring.
+5. Validate the graph eagerly in tests — call `c.Invoke` against the composition root in CI to surface missing providers at boot time, not at first request. `DryRun(true)` skips constructor execution.
+6. Return errors from constructors instead of panicking — dig wraps them with the dependency path, which makes the failure point obvious.
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Passing the container into services | The container belongs to `main()`. Inject the typed dependencies a service needs; otherwise tests need to build a real container. |
+| Two providers for the same type without `Name` | dig errors at `Provide` time. Either name them, or merge into a single provider that returns a `dig.Out` result struct. |
+| Ignoring `Provide` errors | Wrap each `Provide` with a `must` helper. A silent registration error becomes a missing-type error far later. |
+| Using groups when ordering matters | Groups are unordered. If order matters (middleware chain, migration sequence), provide an explicit ordered slice with one constructor. |
+| Constructors with side effects on import | Keep `init()` empty — start work only inside the constructor, after the graph is built. |
+
+## Testing
+
+dig containers are cheap — build a fresh one per test, override providers with `Decorate`, and call `Invoke` to drive the system. For full patterns (per-test wiring, shared helpers, graph validation in CI, asserting wire-time errors, recovering from constructor panics), see [testing.md](./references/testing.md).
+
+## Further Reading
+
+- [advanced.md](./references/advanced.md) — Decorate, Scopes, optional deps, error helpers, Visualize, full Quick Reference
+- [recipes.md](./references/recipes.md) — end-to-end examples: HTTP server with route group, two databases, request scopes, decorators, dry-run validation
+- [testing.md](./references/testing.md) — testing patterns and graph validation
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-uber-fx` skill for application lifecycle, modules, and signal-aware Run() built on top of dig
+- → See `samber/cc-skills-golang@golang-dependency-injection` skill for DI concepts and library comparison
+- → See `samber/cc-skills-golang@golang-samber-do` skill for a generics-based alternative without reflection
+- → See `samber/cc-skills-golang@golang-google-wire` skill for compile-time DI (no runtime container)
+- → See `samber/cc-skills-golang@golang-structs-interfaces` skill for interface design patterns
+- → See `samber/cc-skills-golang@golang-testing` skill for general testing patterns
+
+If you encounter a bug or unexpected behavior in uber-go/dig, open an issue at <https://github.com/uber-go/dig/issues>.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/evals/evals.json
new file mode 100644
index 00000000..9962d5a9
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/evals/evals.json
@@ -0,0 +1,154 @@
+[
+  {
+    "id": 1,
+    "name": "param-objects-many-deps",
+    "description": "Tests use of dig.In parameter objects when a constructor has many dependencies",
+    "prompt": "I'm wiring a Go service with uber-go/dig. I have a NewServer constructor that needs *zap.Logger, *sql.DB, *redis.Client, *Config, and *MetricsRegistry. The signature is getting unwieldy. How should I clean it up?",
+    "trap": "Without the skill, the model keeps the long signature or wraps args in an ad-hoc struct without dig.In, missing the parameter-object pattern that lets the container fill the fields.",
+    "assertions": [
+      {"id": "1.1", "text": "Embeds dig.In in the parameter struct"},
+      {"id": "1.2", "text": "Constructor takes the params struct as a single argument"},
+      {"id": "1.3", "text": "Does NOT just keep the long parameter list as the answer"},
+      {"id": "1.4", "text": "Does NOT use a plain struct without dig.In (which would not be filled by the container)"},
+      {"id": "1.5", "text": "Mentions readability/maintainability benefit (adding a new dep is a one-line change)"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "value-groups-for-handlers",
+    "description": "Tests value groups when many constructors must contribute to one slice",
+    "prompt": "In my Go HTTP server wired with uber-go/dig, I have several constructors (NewUserHandler, NewPostHandler, NewHealthHandler) and a NewRouter that should consume all of them. Each handler is registered independently. How do I wire this without the router knowing which handlers exist?",
+    "trap": "Without the skill, the model invokes each handler individually inside main() and passes a slice to NewRouter, missing the group:\"...\" tag that decouples producers from consumers.",
+    "assertions": [
+      {"id": "2.1", "text": "Each handler constructor returns a dig.Out struct (or uses dig.Group via Provide option) tagged with group:\"routes\" (or similar group name)"},
+      {"id": "2.2", "text": "NewRouter consumes a dig.In with a slice field tagged group:\"routes\""},
+      {"id": "2.3", "text": "Handlers are added with c.Provide — no manual slice assembly in main()"},
+      {"id": "2.4", "text": "Does NOT manually assemble the handler slice and pass it to NewRouter"},
+      {"id": "2.5", "text": "Mentions that group order is not guaranteed (or is silent on it; does NOT claim a specific order is guaranteed)"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "named-values-multiple-dbs",
+    "description": "Tests dig.Name for multiple instances of the same type",
+    "prompt": "My Go app needs two *sql.DB connections — one to the primary write database and one to a read replica. Both use the same *sql.DB type. Show me how to register and consume them with uber-go/dig.",
+    "trap": "Without the skill, the model wraps the two connections in different types (struct PrimaryDB / struct ReadOnlyDB) instead of using dig.Name on a single type.",
+    "assertions": [
+      {"id": "3.1", "text": "Uses dig.Name(\"...\") on c.Provide for at least one of the two databases (or uses dig.Out result tags name:\"...\")"},
+      {"id": "3.2", "text": "Both providers register the same *sql.DB type, distinguished by name"},
+      {"id": "3.3", "text": "Consumer uses dig.In with name:\"primary\" / name:\"readonly\" tags"},
+      {"id": "3.4", "text": "Does NOT introduce wrapper types like type PrimaryDB *sql.DB just to disambiguate"},
+      {"id": "3.5", "text": "Does NOT register both as plain *sql.DB without names (which dig rejects at Provide time)"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "as-to-hide-concrete",
+    "description": "Tests dig.As to expose only an interface to consumers",
+    "prompt": "I have a *PostgresDB concrete struct in my Go code that has many internal fields and methods. I want consumers to depend only on a Database interface (Query, Exec). How do I register it with uber-go/dig so consumers can never accidentally see the concrete type?",
+    "trap": "Without the skill, the model registers the constructor returning Database (interface) directly, which works but loses type info; or writes a separate adapter constructor — missing dig.As that does this in one line.",
+    "assertions": [
+      {"id": "4.1", "text": "Uses dig.As(new(Database)) as a Provide option on the *PostgresDB constructor"},
+      {"id": "4.2", "text": "The constructor itself returns the concrete *PostgresDB"},
+      {"id": "4.3", "text": "Consumers ask for the Database interface, not *PostgresDB"},
+      {"id": "4.4", "text": "Does NOT write a separate wrapper/adapter constructor that just returns the interface"},
+      {"id": "4.5", "text": "Mentions or demonstrates that only the interface is exposed in the graph"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "scopes-for-request-locals",
+    "description": "Tests scopes for per-request dependencies",
+    "prompt": "In my Go web app wired with uber-go/dig, I have global services (logger, database) and per-request data (current user, request ID). How do I keep request-scoped values from leaking across concurrent requests?",
+    "trap": "Without the skill, the model registers everything in the root container and uses context.Value for per-request data — missing dig.Scope which provides isolated child containers.",
+    "assertions": [
+      {"id": "5.1", "text": "Uses c.Scope(\"request\") (or root.Scope) to create a child container per request"},
+      {"id": "5.2", "text": "Global services (logger, database) stay registered on the root"},
+      {"id": "5.3", "text": "Per-request providers are registered on the request scope, not on the root"},
+      {"id": "5.4", "text": "Mentions that the child scope inherits root providers"},
+      {"id": "5.5", "text": "Does NOT register per-request providers globally where they would be shared across requests"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "container-not-passed-around",
+    "description": "Tests that the container stays at the composition root",
+    "prompt": "I'm using uber-go/dig in my Go service. My UserHandler depends on UserService and AuditLogger. Should I inject *dig.Container into UserHandler so it can resolve its own dependencies on demand?",
+    "trap": "Without the skill, the model agrees to pass the container, turning it into a service-locator anti-pattern that hides dependencies and breaks testability.",
+    "assertions": [
+      {"id": "6.1", "text": "Advises against passing *dig.Container into business code"},
+      {"id": "6.2", "text": "States that the container should only live at the composition root (main / startup)"},
+      {"id": "6.3", "text": "Recommends UserHandler take typed dependencies (UserService, AuditLogger) as constructor parameters"},
+      {"id": "6.4", "text": "Mentions service locator anti-pattern OR explains the testability/visibility downside"},
+      {"id": "6.5", "text": "Does NOT show example code that injects the container into a handler"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "graph-validation-dryrun",
+    "description": "Tests dig.DryRun for validating the graph in CI without running constructors",
+    "prompt": "I want a Go test that catches missing-provider errors and cycles in my uber-go/dig wiring without actually starting database connections, HTTP servers, or any real side effects. How do I write that test?",
+    "trap": "Without the skill, the model spins up a real container with real constructors, or skips validation entirely — missing dig.DryRun(true) which validates types without invocation.",
+    "assertions": [
+      {"id": "7.1", "text": "Uses dig.New(dig.DryRun(true)) to build the test container"},
+      {"id": "7.2", "text": "Registers the same Provides as the production binary"},
+      {"id": "7.3", "text": "Calls c.Invoke against the composition root (or top-level dependency) to trigger validation"},
+      {"id": "7.4", "text": "Asserts no error is returned"},
+      {"id": "7.5", "text": "Does NOT actually instantiate real services in the test"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "decorate-not-rewrite",
+    "description": "Tests Decorate to wrap an existing value (e.g., logger) instead of replacing the constructor",
+    "prompt": "In my Go app using uber-go/dig, I want every component in the 'worker' module to receive a *zap.Logger that is named 'worker' (i.e., adds a 'logger':'worker' field). Other modules should keep the unnamed logger. What's the cleanest way?",
+    "trap": "Without the skill, the model rewrites NewLogger or wraps every constructor manually — missing c.Decorate which transforms the value at the scope/module boundary.",
+    "assertions": [
+      {"id": "8.1", "text": "Uses Decorate (c.Decorate or scope.Decorate) on *zap.Logger"},
+      {"id": "8.2", "text": "The decorator returns log.Named(\"worker\") (or equivalent)"},
+      {"id": "8.3", "text": "Decorate is applied at the worker scope/module, not globally"},
+      {"id": "8.4", "text": "Does NOT modify or duplicate the original NewLogger constructor"},
+      {"id": "8.5", "text": "Mentions decorator scope semantics (applies to scope and descendants only) OR places Decorate inside a scope"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "panic-recovery-option",
+    "description": "Tests RecoverFromPanics container option",
+    "prompt": "Some third-party constructors I'm registering with uber-go/dig occasionally panic on invalid configuration. I want my Go app to convert those panics into error returns from c.Invoke instead of crashing the process. How do I configure the container?",
+    "trap": "Without the skill, the model wraps every constructor in defer/recover — missing dig.RecoverFromPanics() which does this at the container level.",
+    "assertions": [
+      {"id": "9.1", "text": "Uses dig.New(dig.RecoverFromPanics()) (or passes the option to dig.New)"},
+      {"id": "9.2", "text": "Mentions or shows that the panic surfaces as a typed dig.PanicError"},
+      {"id": "9.3", "text": "Does NOT recommend wrapping every constructor in defer recover() manually"},
+      {"id": "9.4", "text": "Uses errors.As(err, &dig.PanicError{}) or equivalent to detect the panic case"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "groups-flatten-tag",
+    "description": "Tests group:\",flatten\" tag when one constructor produces multiple group entries",
+    "prompt": "I have a NewMigrations constructor in my Go app (using uber-go/dig) that returns a slice of Migration values. I want every Migration in this slice to be visible to consumers that consume the 'migrations' group as []Migration. How do I do this without nesting?",
+    "trap": "Without the skill, the model registers []Migration as a single group entry, leaving consumers with [][]Migration. The right answer is the ',flatten' tag on the group.",
+    "assertions": [
+      {"id": "10.1", "text": "Uses group:\"migrations,flatten\" tag (with the flatten suffix)"},
+      {"id": "10.2", "text": "Result struct has a slice field []Migration with the tag"},
+      {"id": "10.3", "text": "Consumer receives []Migration (flat slice), not [][]Migration"},
+      {"id": "10.4", "text": "Does NOT silently produce a nested-slice consumer signature"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "fx-vs-dig-when-lifecycle",
+    "description": "Tests recommending fx (instead of raw dig) when the user needs lifecycle/signal handling",
+    "prompt": "I'm starting a new Go service with uber-go/dig. The service needs to gracefully shut down on SIGTERM, run startup migrations, and start a background worker. Should I implement signal handling and start/stop sequencing on top of dig myself?",
+    "trap": "Without the skill, the model writes custom signal handling code on top of raw dig — missing that uber-go/fx is built specifically for this and provides fx.Lifecycle, fx.Hook, and signal-aware Run().",
+    "assertions": [
+      {"id": "11.1", "text": "Recommends migrating to or considering uber-go/fx for the lifecycle requirements"},
+      {"id": "11.2", "text": "Mentions that fx is built on top of dig (so existing wiring patterns transfer)"},
+      {"id": "11.3", "text": "Mentions fx.Lifecycle / fx.Hook (OnStart/OnStop) for graceful boot/shutdown"},
+      {"id": "11.4", "text": "Mentions app.Run() handling SIGINT/SIGTERM"},
+      {"id": "11.5", "text": "Does NOT walk the user through writing custom signal handling on top of raw dig as the primary recommendation"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/advanced.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/advanced.md
new file mode 100644
index 00000000..ac400584
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/advanced.md
@@ -0,0 +1,119 @@
+# Advanced — uber-go/dig
+
+Detail topics that are referenced from `SKILL.md`. Each section is self-contained.
+
+## Decorate
+
+`Decorate` modifies a value already provided in the container — the decorator receives the original instance and returns a replacement. Common uses: enriching a logger with context, wrapping a metrics scope with tags, swapping a real client for a recording one in a child scope.
+
+```go
+c.Decorate(func(log *zap.Logger) *zap.Logger {
+    return log.Named("worker")
+})
+```
+
+Decorators apply to the scope they were registered in and to that scope's descendants. Use them at scope boundaries or package wiring boundaries, not in main(), so changes stay local.
+
+## Scopes
+
+A `Scope` is a child container that inherits providers from its parent and can add or override its own. Scopes let request-, tenant-, or module-level dependencies coexist with shared singletons:
+
+```go
+root := dig.New()
+root.Provide(NewLogger)
+root.Provide(NewDatabase)
+
+requestScope := root.Scope("request")
+requestScope.Provide(NewRequestContext)            // only visible inside requestScope
+requestScope.Decorate(func(l *zap.Logger) *zap.Logger {
+    return l.With(zap.String("scope", "request"))
+})
+```
+
+By default, providers registered to a scope are private to that scope and its children. Pass `dig.Export(true)` to `Provide` inside a scope to make the type visible from the parent:
+
+```go
+requestScope.Provide(NewSharedCache, dig.Export(true))
+```
+
+## Optional Dependencies
+
+`optional:"true"` lets a consumer compile and run when a provider is missing. Use it sparingly — optional dependencies hide configuration mistakes. They make sense for genuinely optional features (a tracing exporter, an in-memory cache) but not for core services like a database.
+
+```go
+type Params struct {
+    dig.In
+
+    Logger *zap.Logger
+    Tracer trace.Tracer `optional:"true"`
+}
+```
+
+## Error Handling
+
+dig wraps the constructor error with the dependency path so you can see _which_ graph edge failed:
+
+```go
+if err := c.Invoke(run); err != nil {
+    // err describes the chain: "could not build *http.Server: ..."
+}
+```
+
+Useful helpers:
+
+- `errors.As(err, &dig.Error{})` — true if the error originated inside dig
+- `dig.RootCause(err)` — unwrap to the original constructor error returned by user code
+- `dig.IsCycleDetected(err)` — true if the graph contains a cycle (typically reported at first `Invoke` unless `DeferAcyclicVerification` is set)
+- `errors.As(err, &dig.PanicError{})` — when `RecoverFromPanics` is enabled, a panicking constructor surfaces as this typed error
+
+## Visualization
+
+dig can emit the dependency graph in DOT format — useful when wiring becomes too tangled to reason about by reading code:
+
+```go
+f, _ := os.Create("graph.dot")
+_ = dig.Visualize(c, f)
+// then: dot -Tpng graph.dot -o graph.png
+```
+
+`dig.VisualizeError(err)` highlights the failed edges when an `Invoke` returns an error — invaluable for debugging "missing type" failures in deep graphs.
+
+## Quick Reference
+
+### Container
+
+| Function/Method | Purpose |
+| --- | --- |
+| `dig.New(opts...)` | Create a root container |
+| `c.Provide(ctor, opts...)` | Register a constructor |
+| `c.Invoke(fn, opts...)` | Run a function with injected dependencies |
+| `c.Decorate(fn, opts...)` | Modify a previously-provided value within a scope |
+| `c.Scope(name, opts...)` | Create a child scope (private providers by default) |
+| `c.String()` | Human-readable text summary of providers (not DOT; use `dig.Visualize` for DOT) |
+
+### Provide options
+
+| Option | Purpose |
+| --- | --- |
+| `dig.Name("...")` | Disambiguate same-typed providers |
+| `dig.Group("...")` | Add the result to a value group |
+| `dig.As(new(I))` | Provide the concrete value as one or more interfaces |
+| `dig.Export(true)` | Make a scope-level provider visible from the root |
+| `dig.FillProvideInfo(&info)` | Capture metadata for tooling |
+
+### Container options
+
+| Option | Purpose |
+| --- | --- |
+| `dig.DeferAcyclicVerification()` | Defer cycle check to first `Invoke` |
+| `dig.RecoverFromPanics()` | Convert constructor panics into `dig.PanicError` |
+| `dig.DryRun(true)` | Validate without invoking constructors |
+
+### Errors
+
+| Helper                              | Purpose                           |
+| ----------------------------------- | --------------------------------- |
+| `dig.RootCause(err)`                | Unwrap to the user-returned error |
+| `dig.IsCycleDetected(err)`          | True if the graph has a cycle     |
+| `errors.As(err, &dig.PanicError{})` | Detect a recovered panic          |
+| `dig.Visualize(c, w, opts...)`      | Write the graph in DOT format     |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/recipes.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/recipes.md
new file mode 100644
index 00000000..81c7b30c
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/recipes.md
@@ -0,0 +1,264 @@
+# Recipes — uber-go/dig
+
+End-to-end examples that go beyond the SKILL.md basics. Each recipe is self-contained and shows a real wiring problem.
+
+## HTTP server with route group
+
+```go
+package main
+
+import (
+    "fmt"
+    "log"
+    "net/http"
+
+    "go.uber.org/dig"
+)
+
+// Each handler contributes one route to the "routes" group.
+type RouteResult struct {
+    dig.Out
+    Route Route `group:"routes"`
+}
+
+type Route struct {
+    Pattern string
+    Handler http.Handler
+}
+
+func NewHealthRoute() RouteResult {
+    return RouteResult{Route: Route{
+        Pattern: "/health",
+        Handler: http.HandlerFunc(func(w http.ResponseWriter, _ *http.Request) {
+            w.WriteHeader(http.StatusOK)
+        }),
+    }}
+}
+
+func NewUserRoute(repo *UserRepo) RouteResult {
+    return RouteResult{Route: Route{
+        Pattern: "/users",
+        Handler: http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+            users, err := repo.List(r.Context())
+            if err != nil {
+                http.Error(w, http.StatusText(http.StatusInternalServerError), http.StatusInternalServerError)
+                return
+            }
+            fmt.Fprintf(w, "%d users", len(users))
+        }),
+    }}
+}
+
+// The server consumes every Route registered to "routes".
+type ServerParams struct {
+    dig.In
+    Routes []Route `group:"routes"`
+}
+
+func NewServer(p ServerParams) *http.Server {
+    mux := http.NewServeMux()
+    for _, r := range p.Routes {
+        mux.Handle(r.Pattern, r.Handler)
+    }
+    return &http.Server{Addr: ":8080", Handler: mux}
+}
+
+func main() {
+    c := dig.New()
+
+    must(c.Provide(NewDB))           // *sql.DB
+    must(c.Provide(NewUserRepo))     // *UserRepo
+    must(c.Provide(NewHealthRoute))  // adds to group
+    must(c.Provide(NewUserRoute))    // adds to group
+    must(c.Provide(NewServer))
+
+    err := c.Invoke(func(srv *http.Server) error {
+        log.Println("listening on", srv.Addr)
+        return srv.ListenAndServe()
+    })
+    if err != nil {
+        log.Fatal(err)
+    }
+}
+
+func must(err error) {
+    if err != nil {
+        panic(err)
+    }
+}
+```
+
+## Two databases (read-write + read-only)
+
+```go
+type DBResult struct {
+    dig.Out
+    Primary  *sql.DB `name:"primary"`
+    ReadOnly *sql.DB `name:"readonly"`
+}
+
+func NewDatabases(cfg *Config) (DBResult, error) {
+    rw, err := sql.Open("postgres", cfg.PrimaryDSN)
+    if err != nil {
+        return DBResult{}, fmt.Errorf("primary: %w", err)
+    }
+    ro, err := sql.Open("postgres", cfg.ReadOnlyDSN)
+    if err != nil {
+        rw.Close()
+        return DBResult{}, fmt.Errorf("readonly: %w", err)
+    }
+    return DBResult{Primary: rw, ReadOnly: ro}, nil
+}
+
+type RepoParams struct {
+    dig.In
+    Writer *sql.DB `name:"primary"`
+    Reader *sql.DB `name:"readonly"`
+}
+
+func NewUserRepo(p RepoParams) *UserRepo {
+    return &UserRepo{w: p.Writer, r: p.Reader}
+}
+```
+
+## Provide as interface (`dig.As`) to hide concrete types
+
+```go
+type Cache interface {
+    Get(key string) (string, bool)
+    Set(key, value string)
+}
+
+type RedisCache struct {
+    client *redis.Client
+    metrics *Metrics // an internal field consumers should not see
+}
+
+func NewRedisCache(client *redis.Client, m *Metrics) *RedisCache {
+    return &RedisCache{client: client, metrics: m}
+}
+
+func (c *RedisCache) Get(key string) (string, bool) { /* ... */ }
+func (c *RedisCache) Set(key, value string)         { /* ... */ }
+
+func main() {
+    c := dig.New()
+    must(c.Provide(NewRedisClient))
+    must(c.Provide(NewMetrics))
+    // Consumers see Cache, never *RedisCache or its internals.
+    must(c.Provide(NewRedisCache, dig.As(new(Cache))))
+    must(c.Invoke(func(cache Cache) {
+        cache.Set("hello", "world")
+    }))
+}
+```
+
+## Request-scoped dependencies
+
+A child scope inherits its parent's providers but adds request-local ones:
+
+```go
+root := dig.New()
+must(root.Provide(NewLogger))
+must(root.Provide(NewDB))
+must(root.Provide(NewHandler)) // *Handler is shared; the scope inherits it
+
+func handle(w http.ResponseWriter, req *http.Request) {
+    scope := root.Scope("request")
+
+    // Request-scoped values
+    must(scope.Provide(func() *http.Request { return req }))
+    must(scope.Provide(func() RequestID { return RequestID(req.Header.Get("X-Request-ID")) }))
+    must(scope.Decorate(func(l *zap.Logger) *zap.Logger {
+        return l.With(zap.String("request_id", req.Header.Get("X-Request-ID")))
+    }))
+
+    err := scope.Invoke(func(h *Handler) error {
+        return h.Serve(w, req)
+    })
+    if err != nil {
+        http.Error(w, err.Error(), 500)
+    }
+}
+```
+
+The decorator only applies inside the request scope — sibling scopes (other in-flight requests) keep their own logger.
+
+## Optional dependency for graceful degradation
+
+```go
+type WorkerParams struct {
+    dig.In
+
+    DB     *sql.DB
+    Tracer trace.Tracer `optional:"true"` // app still boots without OTel
+}
+
+func NewWorker(p WorkerParams) *Worker {
+    w := &Worker{db: p.DB}
+    if p.Tracer != nil {
+        w.tracer = p.Tracer
+    } else {
+        w.tracer = trace.NewNoopTracerProvider().Tracer("noop")
+    }
+    return w
+}
+```
+
+Reach for `optional` only when the dependency is genuinely optional — a missing DB hidden behind `optional` becomes a nil-pointer panic at first use.
+
+## Decorate to add cross-cutting behavior
+
+```go
+// Wrap the *sql.DB with a metrics-recording wrapper everywhere.
+must(c.Decorate(func(db *sql.DB, m *Metrics) *sql.DB {
+    return wrapWithMetrics(db, m)
+}))
+
+// Wrap the logger with service tags.
+must(c.Decorate(func(log *zap.Logger, cfg *Config) *zap.Logger {
+    return log.With(
+        zap.String("service", cfg.ServiceName),
+        zap.String("env", cfg.Env),
+    )
+}))
+```
+
+Decorators are scope-local. A decorator on the root applies everywhere; a decorator on a child scope only applies to that subtree.
+
+## DryRun for graph validation in tests
+
+```go
+func TestWiringIsValid(t *testing.T) {
+    c := dig.New(dig.DryRun(true))
+
+    // Register everything main() registers
+    must := func(err error) {
+        require.NoError(t, err)
+    }
+    must(c.Provide(NewConfig))
+    must(c.Provide(NewLogger))
+    must(c.Provide(NewDB))
+    must(c.Provide(NewServer))
+
+    // Invoke the composition root: dig validates types without running constructors.
+    require.NoError(t, c.Invoke(func(*http.Server) {}))
+}
+```
+
+This catches "no provider for \*X" failures at build time instead of in production.
+
+## Visualizing a failed graph
+
+```go
+err := c.Invoke(run)
+if err != nil {
+    f, _ := os.Create("graph.dot")
+    defer f.Close()
+    _ = dig.Visualize(c, f, dig.VisualizeError(err))
+    log.Fatalf("wiring failed (graph in graph.dot): %v", err)
+}
+// Render: dot -Tpng graph.dot -o graph.png
+```
+
+`VisualizeError` highlights the missing edges in red — much faster than reading the wrapped error chain.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/testing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/testing.md
new file mode 100644
index 00000000..d5e8144f
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-dig/references/testing.md
@@ -0,0 +1,124 @@
+# Testing with uber-go/dig
+
+dig containers are cheap to create. Build a fresh one per test, override what you need, drive the system with `Invoke`.
+
+## Per-test container
+
+```go
+func TestUserService_Create(t *testing.T) {
+    c := dig.New()
+
+    fakeDB := &fakeDatabase{}
+    require.NoError(t, c.Provide(func() Database { return fakeDB }))
+    require.NoError(t, c.Provide(NewUserService))
+
+    require.NoError(t, c.Invoke(func(s *UserService) {
+        err := s.Create(context.Background(), "alice@example.com")
+        require.NoError(t, err)
+    }))
+
+    require.Len(t, fakeDB.inserted, 1)
+}
+```
+
+## Shared test wiring
+
+For larger suites, factor the common providers into a helper:
+
+```go
+func newTestContainer(t *testing.T, overrides ...func(*dig.Container)) *dig.Container {
+    t.Helper()
+    c := dig.New()
+    require.NoError(t, c.Provide(NewTestLogger))
+    require.NoError(t, c.Provide(NewInMemoryCache))
+    require.NoError(t, c.Provide(func() Database { return &fakeDatabase{} }))
+    require.NoError(t, c.Provide(NewUserService))
+
+    for _, override := range overrides {
+        override(c)
+    }
+    return c
+}
+
+func TestUserService_NotFound(t *testing.T) {
+    c := newTestContainer(t, func(c *dig.Container) {
+        // Replace the default DB with one that returns sql.ErrNoRows.
+        require.NoError(t, c.Decorate(func(db Database) Database {
+            return &notFoundDB{Database: db}
+        }))
+    })
+
+    require.NoError(t, c.Invoke(func(s *UserService) {
+        _, err := s.Get(context.Background(), "missing")
+        require.ErrorIs(t, err, ErrUserNotFound)
+    }))
+}
+```
+
+`Decorate` is the cleanest way to swap a dependency in tests — the test reads almost like production wiring with one extra line.
+
+## Validate the production graph in CI
+
+```go
+func TestProductionGraph(t *testing.T) {
+    c := dig.New(dig.DryRun(true))
+
+    // Replicate every Provide() from main()
+    require.NoError(t, registerAll(c))
+
+    // Invoke the same root the production binary does
+    require.NoError(t, c.Invoke(func(*http.Server, *Worker, *MetricsExporter) {}))
+}
+```
+
+`DryRun(true)` skips constructor execution — the graph is validated structurally. This catches missing-provider and type-mismatch errors without spinning up real DB connections.
+
+## Detecting cycles before deploy
+
+A cyclic graph fails at the first `Invoke` (or at `Provide` time when `DeferAcyclicVerification` is off, which is the default):
+
+```go
+func TestNoCycles(t *testing.T) {
+    c := dig.New()
+    require.NoError(t, registerAll(c))
+
+    err := c.Invoke(func(*App) {})
+    require.False(t, dig.IsCycleDetected(err), "cycle in dependency graph: %v", err)
+}
+```
+
+## Asserting a constructor's error path
+
+When a constructor returns an error, dig wraps it with the dependency path. Use `dig.RootCause` to assert the original error:
+
+```go
+func TestDBProvider_BadDSN(t *testing.T) {
+    c := dig.New()
+    require.NoError(t, c.Provide(func() *Config {
+        return &Config{DSN: "not a dsn"}
+    }))
+    require.NoError(t, c.Provide(NewDB))
+
+    err := c.Invoke(func(*sql.DB) {})
+    require.Error(t, err)
+    require.ErrorContains(t, dig.RootCause(err), "invalid connection string")
+}
+```
+
+## Recovering from constructor panics
+
+Wrap constructors that may panic on misuse so the test reports a typed error instead of crashing the runner:
+
+```go
+c := dig.New(dig.RecoverFromPanics())
+
+require.NoError(t, c.Provide(func() *App {
+    panic("intentionally broken")
+}))
+
+err := c.Invoke(func(*App) {})
+
+var pe dig.PanicError
+require.True(t, errors.As(err, &pe))
+require.Contains(t, pe.Error(), "intentionally broken")
+```
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/SKILL.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/SKILL.md
new file mode 100644
index 00000000..16e7e90b
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/SKILL.md
@@ -0,0 +1,231 @@
+---
+name: golang-uber-fx
+description: "Golang application framework using uber-go/fx — fx.New, fx.Provide, fx.Invoke, fx.Module, fx.Lifecycle hooks, fx.Annotate (name/group/As), fx.Decorate, fx.Supply, fx.Replace, fx.WithLogger, and signal-aware Run(). Apply when using or adopting uber-go/fx, when the codebase imports `go.uber.org/fx`, or when wiring services with fx.New. For raw DI without lifecycle, see `samber/cc-skills-golang@golang-uber-dig` skill."
+user-invocable: true
+license: MIT
+compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
+metadata:
+  author: samber
+  version: "1.1.0"
+  openclaw:
+    emoji: "🏭"
+    homepage: https://github.com/samber/cc-skills-golang
+    requires:
+      bins:
+        - go
+    install: []
+    skill-library-version: "1.24.0"
+allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs
+---
+
+**Persona:** You are a Go architect building a long-running service with fx. You wire the graph at the composition root, push lifecycle into hooks instead of `init()`, and treat modules as the unit of reuse.
+
+# Using uber-go/fx for Application Wiring in Go
+
+Application framework combining a reflection-based DI container (built on `uber-go/dig`) with a lifecycle, module system, signal-aware run loop, and structured event logging. For long-running services where boot order, graceful shutdown, and modular composition matter.
+
+**Official Resources:**
+
+- [pkg.go.dev/go.uber.org/fx](https://pkg.go.dev/go.uber.org/fx)
+- [uber-go.github.io/fx](https://uber-go.github.io/fx/)
+- [github.com/uber-go/fx](https://github.com/uber-go/fx)
+
+This skill is not exhaustive. Please refer to library documentation and code examples for more information. Context7 can help as a discoverability platform.
+
+```bash
+go get go.uber.org/fx
+```
+
+## fx vs. dig
+
+fx is built on top of dig and shares the same reflection-based container engine. The DI primitives (`Provide`, `Invoke`, `In`/`Out` structs, named values, value groups) are identical — `fx.In`/`fx.Out` are re-exports of `dig.In`/`dig.Out`.
+
+What fx adds on top:
+
+| Concern | dig | fx |
+| --- | --- | --- |
+| DI container | ✅ `dig.New()` | ✅ (embedded) |
+| Lifecycle hooks | ❌ | ✅ `fx.Lifecycle` OnStart/OnStop |
+| Module system | ❌ | ✅ `fx.Module` with scoped decorators |
+| Signal-aware run loop | ❌ | ✅ `app.Run()` blocks on SIGINT/SIGTERM |
+| Structured event logging | ❌ | ✅ `fx.WithLogger` / `fxevent` |
+| Startup/shutdown timeout | ❌ | ✅ `fx.StartTimeout` / `fx.StopTimeout` |
+
+**Choose fx** for long-running services (HTTP servers, workers, daemons) — lifecycle and signal handling are mandatory there, and modules make large service graphs manageable.
+
+**Choose raw dig** when you need wiring without a framework: CLI tools, libraries that expose a container to callers, test harnesses, or embedding DI into an existing app that manages its own lifecycle. See `samber/cc-skills-golang@golang-uber-dig` skill.
+
+## The Application
+
+```go
+import "go.uber.org/fx"
+
+app := fx.New(
+    fx.Provide(NewLogger, NewDatabase, NewServer),
+    fx.Invoke(RegisterRoutes),
+)
+app.Run() // blocks until SIGINT/SIGTERM, then runs OnStop hooks
+```
+
+Boot stages: `fx.New` validates types (constructors do not run); `app.Start(ctx)` runs each `fx.Invoke` and fires OnStart hooks in topological order; main blocks on `app.Done()`; `app.Stop(ctx)` fires OnStop hooks in reverse order. Default timeout is **15 seconds** — override with `fx.StartTimeout` / `fx.StopTimeout`.
+
+## Provide and Invoke
+
+```go
+fx.New(
+    fx.Provide(NewLogger, NewDatabase, NewServer),  // lazy
+    fx.Invoke(RegisterRoutes, StartMetricsExporter), // always run during Start
+)
+```
+
+`fx.Provide` registers constructors; `fx.Invoke` is the trigger — without an Invoke (directly or transitively) referencing a type, its constructor never runs.
+
+## Lifecycle Hooks
+
+Inject `fx.Lifecycle` and append hooks. Constructors should return quickly; long-running work belongs in `OnStart`.
+
+```go
+func NewHTTPServer(lc fx.Lifecycle, log *zap.Logger, cfg *Config) *http.Server {
+    srv := &http.Server{Addr: cfg.Addr}
+
+    lc.Append(fx.Hook{
+        OnStart: func(ctx context.Context) error {
+            ln, err := net.Listen("tcp", srv.Addr)
+            if err != nil { return err }
+            go srv.Serve(ln)         // blocking work in a goroutine
+            return nil
+        },
+        OnStop: func(ctx context.Context) error {
+            return srv.Shutdown(ctx)
+        },
+    })
+    return srv
+}
+```
+
+Both callbacks receive a context bounded by `StartTimeout`/`StopTimeout` — respect cancellation. **OnStart must return quickly** — spawn a goroutine for blocking work; otherwise startup hangs and dependent hooks never fire.
+
+`fx.StartHook` / `fx.StopHook` / `fx.StartStopHook` adapt simpler signatures (no context, no error, or both):
+
+```go
+lc.Append(fx.StartStopHook(srv.Start, srv.Stop))   // matched pair
+```
+
+## Parameter and Result Objects
+
+fx re-exports dig's `dig.In` / `dig.Out` as `fx.In` / `fx.Out`. Use them when a constructor has 4+ dependencies, or when you need `name`/`group`/`optional` tags.
+
+```go
+type ServerParams struct {
+    fx.In
+
+    Logger *zap.Logger
+    DB     *sql.DB
+    Cache  *redis.Client     `optional:"true"`
+    Routes []http.Handler    `group:"routes"`
+}
+
+func NewServer(p ServerParams) *Server { /* ... */ }
+```
+
+## fx.Annotate
+
+`fx.Annotate` wraps a constructor to add tags or interface bindings without a `fx.Out` struct. Prefer it for ergonomic name/group/As bindings:
+
+```go
+fx.Provide(
+    fx.Annotate(NewPrimaryDB, fx.ResultTags(`name:"primary"`)),
+    fx.Annotate(NewPostgresDB, fx.As(new(Database))),    // expose interface
+    fx.Annotate(NewUserHandler,
+        fx.As(new(http.Handler)),
+        fx.ResultTags(`group:"routes"`),
+    ),
+)
+```
+
+## Value Groups
+
+Many constructors, one consumer slice — typical for routes, health checks, metrics collectors:
+
+```go
+type RouteResult struct {
+    fx.Out
+    Handler http.Handler `group:"routes"`
+}
+
+type ServerParams struct {
+    fx.In
+    Routes []http.Handler `group:"routes"`
+}
+```
+
+Append `,flatten` (`group:"routes,flatten"`) to unwrap a slice instead of nesting it. Order is **not guaranteed** — provide an explicit ordered slice when sequence matters.
+
+## fx.Module
+
+`fx.Module` groups providers, invokes, and decorators under a name. Modules **scope decorators** to themselves and their children — a logger renamed in `fx.Module("db", ...)` only appears renamed for code inside that module.
+
+```go
+var DatabaseModule = fx.Module("database",
+    fx.Provide(NewConnection, NewUserRepository),
+    fx.Decorate(func(log *zap.Logger) *zap.Logger {
+        return log.Named("db")
+    }),
+)
+
+func main() {
+    fx.New(
+        fx.Provide(NewConfig, NewLogger),
+        DatabaseModule,
+        HTTPModule,
+    ).Run()
+}
+```
+
+Treat each module as a small library that can be lifted into another app — its public surface is the types it Provides.
+
+For `fx.Supply`/`fx.Replace`/`fx.Decorate`, optional deps, custom logging, manual lifecycle, and Quick Reference, see [advanced.md](./references/advanced.md).
+
+## Best Practices
+
+1. Keep `main()` thin — providers, modules, and a single `Run()`. Push real work into modules so each can be tested in isolation.
+2. Use lifecycle hooks instead of `init()` or goroutines launched from constructors — Start/Stop ordering depends on graph topology, but `init()` goroutines do not, which leads to races and leaks.
+3. OnStart must return promptly — long work goes in a goroutine inside the hook. A blocking OnStart hangs the rest of the boot.
+4. Respect `ctx.Done()` in hooks — a hook that ignores cancellation is reported as a timeout failure but its goroutine continues, leaking resources.
+5. Group by module, not by layer — a module owns the providers, lifecycle, and decorators for one concern (HTTP, DB, metrics).
+6. Use `fx.Annotate` for tags rather than wrapping a constructor in an `fx.Out` struct — keeps the constructor reusable outside fx.
+7. Replace `fx.Provide` with `fx.Supply` for pre-built values (config, command-line flags). Shorter, signals intent.
+8. Validate the graph in CI by booting under `fx.New(...).Err()` — catches missing providers and cycles before deploy.
+
+## Common Mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| Long-running work directly in OnStart | Spawn a goroutine inside OnStart; the hook itself must return quickly so dependent hooks can run. |
+| `fx.Provide` something that should be `fx.Supply` | Pre-built values (config, secrets) belong in `fx.Supply` — clearer and avoids a no-op constructor. |
+| Module decorator leaking to siblings | Decorate inside `fx.Module(...)` — decorators flow only to descendants. A top-level `fx.Decorate` is global. |
+| Group order assumed | Groups are unordered. If order matters, provide an ordered slice from one constructor. |
+| Constructors with side effects | Side effects belong in OnStart — constructors should be cheap and pure-ish, since they may run concurrently and lazily. |
+| Forgotten `fx.Invoke` | Without an Invoke (or downstream consumer), constructors never run. Add at least one Invoke per app. |
+
+## Testing
+
+Use `go.uber.org/fx/fxtest` to integrate fx with `*testing.T` (failures call `t.Fatal`, `RequireStop` registers as `t.Cleanup`). `fx.Populate(&target)` pulls values out of the graph; `fx.Replace` swaps real dependencies for fakes. Full patterns in [testing.md](./references/testing.md).
+
+## Further Reading
+
+- [advanced.md](./references/advanced.md) — Supply/Replace/Decorate, optional deps, custom event logging, manual lifecycle, full Quick Reference
+- [recipes.md](./references/recipes.md) — full HTTP service with database/metrics, background workers with graceful drain, multiple impls of the same interface, manual lifecycle for CLI embedding
+- [testing.md](./references/testing.md) — fxtest patterns, `fx.Replace`, `fx.Populate`, isolated lifecycle tests, CI graph validation
+
+## Cross-References
+
+- → See `samber/cc-skills-golang@golang-uber-dig` skill for the underlying container, `dig.In`/`dig.Out`, and DI without lifecycle
+- → See `samber/cc-skills-golang@golang-dependency-injection` skill for DI concepts and library comparison
+- → See `samber/cc-skills-golang@golang-samber-do` skill for a generics-based alternative without reflection
+- → See `samber/cc-skills-golang@golang-google-wire` skill for compile-time DI (no runtime container)
+- → See `samber/cc-skills-golang@golang-structs-interfaces` skill for interface design patterns
+- → See `samber/cc-skills-golang@golang-context` skill for context propagation in OnStart/OnStop hooks
+- → See `samber/cc-skills-golang@golang-testing` skill for general testing patterns
+
+If you encounter a bug or unexpected behavior in uber-go/fx, open an issue at <https://github.com/uber-go/fx/issues>.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/evals/evals.json b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/evals/evals.json
new file mode 100644
index 00000000..c90557f5
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/evals/evals.json
@@ -0,0 +1,156 @@
+[
+  {
+    "id": 1,
+    "name": "lifecycle-not-init",
+    "description": "Tests use of fx.Lifecycle hooks instead of init() or constructor side effects for startup work",
+    "prompt": "In my Go service using uber-go/fx, I have a NewHTTPServer constructor that should listen on a port and serve requests. Where should I call srv.Serve(ln) — inside the constructor, in init(), or somewhere else?",
+    "trap": "Without the skill, the model calls srv.Serve in init() or directly inside the constructor (which would block boot), or writes a goroutine inside the constructor (which fires before lifecycle ordering applies). The right answer is OnStart with a goroutine.",
+    "assertions": [
+      {"id": "1.1", "text": "Injects fx.Lifecycle into NewHTTPServer"},
+      {"id": "1.2", "text": "Calls lc.Append with an fx.Hook (or fx.StartHook/StopHook) — OnStart starts the server, OnStop calls Shutdown"},
+      {"id": "1.3", "text": "OnStart launches srv.Serve inside a goroutine so the hook returns quickly"},
+      {"id": "1.4", "text": "Does NOT call srv.Serve directly inside the constructor"},
+      {"id": "1.5", "text": "Does NOT use init() to start the server"},
+      {"id": "1.6", "text": "OnStop calls srv.Shutdown(ctx) for graceful shutdown"}
+    ]
+  },
+  {
+    "id": 2,
+    "name": "annotate-vs-fxout-struct",
+    "description": "Tests fx.Annotate as the modern way to add tags or interface bindings",
+    "prompt": "I have NewPostgresDB returning *PostgresDB in my Go app using uber-go/fx. I want consumers to ask for a Database interface, and I want this DB tagged with name:\"primary\" so I can add a replica later. Show me how.",
+    "trap": "Without the skill, the model writes a separate adapter constructor returning Database, or wraps the result in an fx.Out struct — missing fx.Annotate(NewPostgresDB, fx.As(new(Database)), fx.ResultTags(...)) which does both in one line.",
+    "assertions": [
+      {"id": "2.1", "text": "Uses fx.Annotate around NewPostgresDB"},
+      {"id": "2.2", "text": "Uses fx.As(new(Database)) inside the annotation to bind the interface"},
+      {"id": "2.3", "text": "Uses fx.ResultTags(`name:\"primary\"`) for the named tag"},
+      {"id": "2.4", "text": "Does NOT introduce a separate adapter/wrapper constructor"},
+      {"id": "2.5", "text": "Does NOT rewrite NewPostgresDB to return Database directly (since the original constructor stays untouched)"}
+    ]
+  },
+  {
+    "id": 3,
+    "name": "module-organization",
+    "description": "Tests fx.Module for organizing related providers/invokes/decorators",
+    "prompt": "My Go application using uber-go/fx is growing — main.go now has dozens of fx.Provide calls for HTTP, database, metrics, and worker concerns mixed together. How should I reorganize this?",
+    "trap": "Without the skill, the model splits providers across several Go packages but keeps a flat list in main(), missing fx.Module which groups providers, invokes, and decorators under a name and lets decorators be module-scoped.",
+    "assertions": [
+      {"id": "3.1", "text": "Recommends fx.Module to group related options"},
+      {"id": "3.2", "text": "Shows at least 2 separate modules (e.g., HTTPModule, DatabaseModule)"},
+      {"id": "3.3", "text": "main() composes the modules via fx.New(HTTPModule, DatabaseModule, ...)"},
+      {"id": "3.4", "text": "Mentions OR demonstrates that fx.Decorate inside a module is scoped to that module"},
+      {"id": "3.5", "text": "Each module includes its own fx.Provide (and possibly fx.Invoke / fx.Decorate) calls"}
+    ]
+  },
+  {
+    "id": 4,
+    "name": "supply-vs-provide",
+    "description": "Tests fx.Supply for pre-built values (config, secrets) instead of fx.Provide with a no-op constructor",
+    "prompt": "In my Go application using uber-go/fx, I parse a *Config from flags and load an API_KEY environment variable in main() before calling fx.New. How should I make these available to the rest of the graph?",
+    "trap": "Without the skill, the model writes fx.Provide(func() *Config { return cfg }) — a redundant constructor that just returns the existing value. fx.Supply does this without the boilerplate.",
+    "assertions": [
+      {"id": "4.1", "text": "Uses fx.Supply(cfg) (or fx.Supply with both values)"},
+      {"id": "4.2", "text": "Does NOT wrap the pre-built values in fx.Provide(func() *Config { return cfg })"},
+      {"id": "4.3", "text": "Mentions or demonstrates that fx.Supply makes pre-built values first-class graph members"},
+      {"id": "4.4", "text": "If both values are supplied as the same type or need a tag, optionally uses fx.Annotate within fx.Supply for tagging"}
+    ]
+  },
+  {
+    "id": 5,
+    "name": "fxtest-with-populate",
+    "description": "Tests fxtest.New + fx.Populate for testing instead of raw fx.New + fx.Invoke",
+    "prompt": "I have a *UserService wired in my Go app using uber-go/fx. I want a unit test that pulls *UserService out of the graph (with a fake Database injected) and asserts behavior. Show me the minimal test.",
+    "trap": "Without the skill, the model uses fx.New + fx.Invoke(func(s *UserService) { ... }) — works but doesn't fail the test cleanly and has no Cleanup integration. fxtest.New + fx.Populate is idiomatic.",
+    "assertions": [
+      {"id": "5.1", "text": "Uses fxtest.New(t, ...) instead of fx.New"},
+      {"id": "5.2", "text": "Uses fx.Populate(&svc) to extract the *UserService from the graph"},
+      {"id": "5.3", "text": "Calls app.RequireStart() (or .Start) and app.RequireStop() (e.g., as t.Cleanup or defer)"},
+      {"id": "5.4", "text": "Provides a fake Database (interface) — does NOT use the real DB"},
+      {"id": "5.5", "text": "Does NOT use fx.Invoke as the primary mechanism for extracting the service"}
+    ]
+  },
+  {
+    "id": 6,
+    "name": "replace-for-fakes",
+    "description": "Tests fx.Replace inside fxtest to swap a real dependency embedded in a module",
+    "prompt": "My Go app uses uber-go/fx with a ProductionModule that bundles all real wiring. In one integration test, I want to replace the real Database with an erroring fake — without rewriting the module. How?",
+    "trap": "Without the skill, the model rewrites the module (or copies it) to inject the fake — missing fx.Replace which overrides a previously-provided type without touching the module.",
+    "assertions": [
+      {"id": "6.1", "text": "Uses fx.Replace(...) inside fxtest.New (or fx.New) to override the Database"},
+      {"id": "6.2", "text": "Composes ProductionModule alongside fx.Replace (the module is reused unchanged)"},
+      {"id": "6.3", "text": "Uses fx.Annotate inside fx.Replace if needed for fx.As(new(Database)) binding"},
+      {"id": "6.4", "text": "Does NOT modify or duplicate the production module to inject the fake"},
+      {"id": "6.5", "text": "Mentions that fx.Replace is appropriate for tests (not production code)"}
+    ]
+  },
+  {
+    "id": 7,
+    "name": "value-groups-handlers",
+    "description": "Tests value groups when many handler constructors must contribute to one slice",
+    "prompt": "In my Go HTTP server using uber-go/fx, I want every NewXxxHandler constructor to register itself with the router automatically — no manual list of handlers in main(). I have NewUserHandler, NewPostHandler, NewHealthHandler. The router consumes []http.Handler. Wire this.",
+    "trap": "Without the skill, the model assembles a slice manually in main() or writes one constructor that builds all handlers — missing the group:\"...\" tag pattern that keeps producers and the consumer decoupled.",
+    "assertions": [
+      {"id": "7.1", "text": "Each handler is registered with fx.Annotate(... fx.ResultTags(`group:\"routes\"`)) (or via an fx.Out struct with a group tag)"},
+      {"id": "7.2", "text": "The router (or server) consumes a fx.In with []http.Handler tagged group:\"routes\""},
+      {"id": "7.3", "text": "Optionally uses fx.As(new(http.Handler)) inside the annotation if the constructor returns a concrete type"},
+      {"id": "7.4", "text": "Does NOT manually maintain a slice of handlers in main()"},
+      {"id": "7.5", "text": "Does not assert ordering of the resulting slice (or explicitly notes order is unspecified)"}
+    ]
+  },
+  {
+    "id": 8,
+    "name": "logger-fxevent-zap",
+    "description": "Tests fx.WithLogger + fxevent.ZapLogger to route fx events through the app's structured logger",
+    "prompt": "My Go service using uber-go/fx logs everything through *zap.Logger. The default fx output goes to stderr in a different format and is noisy in production. How do I route fx's own events (provide/invoke/start/stop) through my zap logger?",
+    "trap": "Without the skill, the model suggests overriding os.Stderr or grepping logs — missing fx.WithLogger which lets you provide an fxevent.Logger backed by zap.",
+    "assertions": [
+      {"id": "8.1", "text": "Uses fx.WithLogger(...) as an fx.New option"},
+      {"id": "8.2", "text": "The provided fxevent.Logger is &fxevent.ZapLogger{Logger: log}"},
+      {"id": "8.3", "text": "The logger inside fx.WithLogger receives the *zap.Logger as a parameter (so fx wires it from the graph)"},
+      {"id": "8.4", "text": "Does NOT redirect stderr or modify global log output"},
+      {"id": "8.5", "text": "May mention fx.NopLogger as an option to silence fx events"}
+    ]
+  },
+  {
+    "id": 9,
+    "name": "manual-lifecycle-cli",
+    "description": "Tests app.Start / app.Done / app.Stop for embedding fx in a larger program",
+    "prompt": "I'm building a Go CLI tool that has an interactive sub-command and a serve sub-command. I want the serve sub-command to spin up an fx graph, start it, wait for SIGINT, and shut down — but I don't want fx hijacking the entire process via app.Run() (because the CLI may resume to other work after). How do I drive fx manually?",
+    "trap": "Without the skill, the model calls app.Run() and then can't return to the CLI — missing manual Start/Done/Stop, which is exactly what the user is asking for.",
+    "assertions": [
+      {"id": "9.1", "text": "Uses app.Start(ctx) explicitly with a context (often timeout-bounded)"},
+      {"id": "9.2", "text": "Waits on app.Done() (or a select including parent context cancellation) instead of calling app.Run()"},
+      {"id": "9.3", "text": "Uses app.Stop(ctx) explicitly with a context"},
+      {"id": "9.4", "text": "Does NOT recommend app.Run() as the primary mechanism for this scenario"},
+      {"id": "9.5", "text": "Mentions that app.Err() can validate wiring without starting"}
+    ]
+  },
+  {
+    "id": 10,
+    "name": "onstart-non-blocking",
+    "description": "Tests that long-running OnStart work is launched in a goroutine, not run synchronously",
+    "prompt": "In my Go app using uber-go/fx, the OnStart hook for a worker calls a method that runs forever (consuming jobs from a queue until the app stops). Show me the OnStart implementation.",
+    "trap": "Without the skill, the model calls the long-running method synchronously inside OnStart — which hangs startup. The right pattern is to spawn a goroutine and return nil quickly.",
+    "assertions": [
+      {"id": "10.1", "text": "OnStart launches the long-running method inside a goroutine"},
+      {"id": "10.2", "text": "OnStart itself returns nil (or an error) quickly without waiting for the worker to finish"},
+      {"id": "10.3", "text": "OnStop signals the worker to stop (closing a channel, calling Cancel, etc.) and waits for it to drain"},
+      {"id": "10.4", "text": "Does NOT call the long-running method synchronously inside OnStart"},
+      {"id": "10.5", "text": "Mentions that a blocking OnStart would hang the boot / dependent hooks"}
+    ]
+  },
+  {
+    "id": 11,
+    "name": "fx-when-not-dig",
+    "description": "Tests recommending raw dig (instead of fx) when the user does not need lifecycle / app boot",
+    "prompt": "I'm writing a one-shot Go CLI command that builds a small object graph (parses input, creates a few services, calls one of them, exits). I'm reading about uber-go/fx but it seems heavy. Should I use fx for this?",
+    "trap": "Without the skill, the model unconditionally recommends fx — missing that for one-shot programs without lifecycle, raw uber-go/dig is the lighter, simpler choice.",
+    "assertions": [
+      {"id": "11.1", "text": "Recommends raw uber-go/dig (or notes fx is overkill for this case)"},
+      {"id": "11.2", "text": "Mentions that fx is built on dig — the wiring patterns are nearly identical"},
+      {"id": "11.3", "text": "Mentions that fx adds value when the program needs lifecycle hooks, signal handling, or modular composition"},
+      {"id": "11.4", "text": "Does NOT recommend introducing fx.Lifecycle/fx.Module to a one-shot program"},
+      {"id": "11.5", "text": "May recommend manual constructor injection if the graph is very small"}
+    ]
+  }
+]
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/advanced.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/advanced.md
new file mode 100644
index 00000000..94717c5e
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/advanced.md
@@ -0,0 +1,135 @@
+# Advanced — uber-go/fx
+
+Detail topics referenced from `SKILL.md`. Each section is self-contained.
+
+## fx.Supply, fx.Replace, fx.Decorate
+
+| Option | Purpose |
+| --- | --- |
+| `fx.Supply(values...)` | Provide pre-built values directly. Use for config, secrets, parsed flags. |
+| `fx.Replace(values...)` | Replace an already-provided type. Most useful in tests: swap real for fake. |
+| `fx.Decorate(fn)` | Wrap or modify an existing value. Scoped to the surrounding module. |
+
+```go
+fx.Supply(cfg, secret)
+
+// Replace inside fxtest
+fx.Replace(fx.Annotate(&fakeDB{}, fx.As(new(Database))))
+
+// Decorate, module-scoped
+fx.Module("worker",
+    fx.Decorate(func(s metrics.Scope) metrics.Scope {
+        return s.Tagged(map[string]string{"component": "worker"})
+    }),
+)
+```
+
+## Optional Dependencies
+
+`optional:"true"` lets a consumer compile and run when no provider exists. Use it for genuinely optional features (a tracer, a cache) — not for core services like a database.
+
+```go
+type Params struct {
+    fx.In
+
+    Logger *zap.Logger
+    Tracer trace.Tracer `optional:"true"`
+}
+```
+
+## Logging fx Events
+
+fx emits structured events (provide, invoke, hook execution, errors) through `fxevent.Logger`. By default it writes to stderr — replace with a Zap logger or silence it in tests:
+
+```go
+fx.New(
+    fx.Provide(NewZapLogger),
+    fx.WithLogger(func(log *zap.Logger) fxevent.Logger {
+        return &fxevent.ZapLogger{Logger: log}
+    }),
+    // Or silence: fx.NopLogger
+)
+```
+
+## Manual Lifecycle Control
+
+`app.Run()` is convenient but inflexible. For tests, custom signal handling, or embedding fx in a larger program, drive the lifecycle manually:
+
+```go
+app := fx.New(/* ... */)
+
+startCtx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
+defer cancel()
+if err := app.Start(startCtx); err != nil {
+    log.Fatal(err)
+}
+
+<-app.Done() // waits for SIGINT/SIGTERM
+
+stopCtx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
+defer cancel()
+if err := app.Stop(stopCtx); err != nil {
+    log.Fatal(err)
+}
+```
+
+`fx.StartTimeout` and `fx.StopTimeout` set defaults; pass an explicit context to override per-call.
+
+## Quick Reference
+
+### Application
+
+| Function          | Purpose                                                |
+| ----------------- | ------------------------------------------------------ |
+| `fx.New(opts...)` | Build the application graph                            |
+| `app.Run()`       | Start, wait for signal, Stop — single call             |
+| `app.Start(ctx)`  | Run OnStart hooks in dependency order                  |
+| `app.Stop(ctx)`   | Run OnStop hooks in reverse order                      |
+| `app.Done()`      | Channel that closes on SIGINT/SIGTERM                  |
+| `app.Err()`       | Wiring error from `fx.New` (validate without starting) |
+
+### Wiring
+
+| Option                     | Purpose                                     |
+| -------------------------- | ------------------------------------------- |
+| `fx.Provide(ctors...)`     | Register constructors                       |
+| `fx.Invoke(fns...)`        | Run functions during Start                  |
+| `fx.Supply(values...)`     | Provide pre-built values                    |
+| `fx.Replace(values...)`    | Replace previously-provided values (tests)  |
+| `fx.Decorate(fn)`          | Wrap an existing value (module-scoped)      |
+| `fx.Module(name, opts...)` | Group providers/invokes/decorators          |
+| `fx.Options(opts...)`      | Bundle options into a single value          |
+| `fx.Populate(targets...)`  | Extract typed values from the graph (tests) |
+
+### Annotations
+
+| Function | Purpose |
+| --- | --- |
+| `fx.Annotate(fn, opts...)` | Tag/interface-wrap a constructor |
+| `fx.ParamTags("...")` | Tag parameters of an annotated constructor |
+| `fx.ResultTags("...")` | Tag results of an annotated constructor |
+| `fx.As(new(I))` | Provide as one or more interfaces |
+| `fx.From(types...)` | Bind annotated parameters to specific provided types |
+
+### Lifecycle
+
+| Helper | Purpose |
+| --- | --- |
+| `fx.Hook{OnStart, OnStop}` | Full hook with context-aware callbacks |
+| `fx.StartHook(fn)` | Adapt a simple Start function |
+| `fx.StopHook(fn)` | Adapt a simple Stop function |
+| `fx.StartStopHook(start, stop)` | Pair of simple Start/Stop functions |
+| `fx.StartTimeout(d)`, `fx.StopTimeout(d)` | Override default 15s lifecycle timeouts |
+| `fx.ErrorHook(h)` | Intercept lifecycle errors (e.g. failed OnStart) for alerting or cleanup |
+
+### Logging & Testing
+
+| Helper | Purpose |
+| --- | --- |
+| `fx.WithLogger(fn)` | Plug in a custom `fxevent.Logger` |
+| `fx.NopLogger` | Silence fx event logging |
+| `fxevent.ZapLogger{Logger: log}` | Bridge fx events into zap |
+| `fxevent.SlogLogger{Logger: log}` | Bridge fx events into log/slog |
+| `fxtest.New(t, opts...)` | App that fails the test on errors |
+| `app.RequireStart()`, `app.RequireStop()` | Start/Stop with `t.Fatal` on failure |
+| `fxtest.NewLifecycle(t)` | Standalone lifecycle for unit tests |
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/recipes.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/recipes.md
new file mode 100644
index 00000000..cf412862
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/recipes.md
@@ -0,0 +1,331 @@
+# Recipes — uber-go/fx
+
+End-to-end examples that go beyond the SKILL.md basics. Each recipe is self-contained and shows a real wiring problem.
+
+## Full HTTP service with database, metrics, and graceful shutdown
+
+```go
+package main
+
+import (
+    "context"
+    "database/sql"
+    "fmt"
+    "net"
+    "net/http"
+    "time"
+
+    "github.com/prometheus/client_golang/prometheus"
+    "github.com/prometheus/client_golang/prometheus/promhttp"
+    "go.uber.org/fx"
+    "go.uber.org/fx/fxevent"
+    "go.uber.org/zap"
+)
+
+func main() {
+    fx.New(
+        fx.Provide(
+            NewConfig,
+            NewLogger,
+            NewDatabase,
+            NewMetricsRegistry,
+        ),
+
+        DatabaseModule,
+        HTTPModule,
+        MetricsModule,
+
+        fx.WithLogger(func(log *zap.Logger) fxevent.Logger {
+            return &fxevent.ZapLogger{Logger: log}
+        }),
+
+        fx.StartTimeout(30 * time.Second),
+        fx.StopTimeout(30 * time.Second),
+    ).Run()
+}
+
+var DatabaseModule = fx.Module("database",
+    fx.Provide(
+        NewUserRepository,
+        NewPostRepository,
+    ),
+    fx.Decorate(func(log *zap.Logger) *zap.Logger {
+        return log.Named("db")
+    }),
+)
+
+var HTTPModule = fx.Module("http",
+    fx.Provide(
+        NewRouter,
+        NewHTTPServer,
+        // Each handler joins the "routes" group.
+        AsRoute(NewUserHandler),
+        AsRoute(NewPostHandler),
+        AsRoute(NewHealthHandler),
+    ),
+    fx.Invoke(func(*http.Server) {}), // forces server to be built
+)
+
+var MetricsModule = fx.Module("metrics",
+    fx.Provide(NewPrometheusHandler),
+    fx.Invoke(RegisterMetrics),
+)
+
+// Helper to register a handler with the "routes" group.
+func AsRoute(ctor any) any {
+    return fx.Annotate(
+        ctor,
+        fx.As(new(Route)),
+        fx.ResultTags(`group:"routes"`),
+    )
+}
+
+type Route interface {
+    Pattern() string
+    http.Handler
+}
+
+type RouterParams struct {
+    fx.In
+    Routes []Route `group:"routes"`
+}
+
+func NewRouter(p RouterParams) *http.ServeMux {
+    mux := http.NewServeMux()
+    for _, r := range p.Routes {
+        mux.Handle(r.Pattern(), r)
+    }
+    return mux
+}
+
+func NewHTTPServer(lc fx.Lifecycle, log *zap.Logger, mux *http.ServeMux, cfg *Config) *http.Server {
+    srv := &http.Server{
+        Addr:         cfg.Addr,
+        Handler:      mux,
+        ReadTimeout:  10 * time.Second,
+        WriteTimeout: 10 * time.Second,
+    }
+
+    lc.Append(fx.Hook{
+        OnStart: func(ctx context.Context) error {
+            ln, err := net.Listen("tcp", srv.Addr)
+            if err != nil {
+                return fmt.Errorf("listen %s: %w", srv.Addr, err)
+            }
+            go func() {
+                if err := srv.Serve(ln); err != nil && err != http.ErrServerClosed {
+                    log.Error("server error", zap.Error(err))
+                }
+            }()
+            log.Info("listening", zap.String("addr", srv.Addr))
+            return nil
+        },
+        OnStop: func(ctx context.Context) error {
+            log.Info("shutting down")
+            return srv.Shutdown(ctx)
+        },
+    })
+    return srv
+}
+```
+
+## Background worker with graceful drain
+
+```go
+type Worker struct {
+    log    *zap.Logger
+    queue  chan Job
+    done   chan struct{}
+}
+
+func NewWorker(lc fx.Lifecycle, log *zap.Logger) *Worker {
+    w := &Worker{
+        log:   log,
+        queue: make(chan Job, 100),
+        done:  make(chan struct{}),
+    }
+
+    lc.Append(fx.Hook{
+        OnStart: func(ctx context.Context) error {
+            go w.run()
+            return nil
+        },
+        OnStop: func(ctx context.Context) error {
+            close(w.queue) // signal "no more jobs"
+            select {
+            case <-w.done:
+                w.log.Info("worker drained cleanly")
+                return nil
+            case <-ctx.Done():
+                w.log.Warn("worker stop timeout")
+                return ctx.Err()
+            }
+        },
+    })
+
+    return w
+}
+
+func (w *Worker) run() {
+    defer close(w.done)
+    for job := range w.queue {
+        job.Do(w.log)
+    }
+}
+```
+
+The worker honors the stop context — under a 30-second `fx.StopTimeout` it has 30 seconds to drain. Beyond that, fx reports the timeout and the process exits.
+
+## Multiple implementations of the same interface
+
+Use named annotations + `fx.As` to register two `Cache` implementations and inject them by name:
+
+```go
+fx.Provide(
+    fx.Annotate(
+        NewRedisCache,
+        fx.As(new(Cache)),
+        fx.ResultTags(`name:"redis"`),
+    ),
+    fx.Annotate(
+        NewMemcachedCache,
+        fx.As(new(Cache)),
+        fx.ResultTags(`name:"memcached"`),
+    ),
+)
+
+type ServiceParams struct {
+    fx.In
+    Primary  Cache `name:"redis"`
+    Fallback Cache `name:"memcached"`
+}
+```
+
+## fx.Supply for config and secrets
+
+```go
+func main() {
+    cfg := mustLoadConfig() // parsed flags + env, before fx
+    secret := os.Getenv("API_KEY")
+
+    fx.New(
+        fx.Supply(cfg),                  // *Config available everywhere
+        fx.Supply(fx.Annotate(secret, fx.ResultTags(`name:"apikey"`))),
+
+        fx.Provide(NewLogger, NewAPIClient),
+        fx.Invoke(run),
+    ).Run()
+}
+
+func NewAPIClient(cfg *Config, p struct {
+    fx.In
+    APIKey string `name:"apikey"`
+}) *APIClient {
+    return &APIClient{baseURL: cfg.APIBaseURL, key: p.APIKey}
+}
+```
+
+`fx.Supply` makes pre-built values first-class graph members. It is shorter and clearer than `fx.Provide(func() *Config { return cfg })`.
+
+## Module-scoped decorator
+
+```go
+var WorkerModule = fx.Module("worker",
+    fx.Provide(NewWorker, NewJobQueue),
+    // Inside this module, *zap.Logger is automatically named "worker".
+    fx.Decorate(func(log *zap.Logger) *zap.Logger {
+        return log.Named("worker")
+    }),
+)
+
+var APIModule = fx.Module("api",
+    fx.Provide(NewServer, NewRouter),
+    fx.Decorate(func(log *zap.Logger) *zap.Logger {
+        return log.Named("api")
+    }),
+)
+```
+
+The two modules see different loggers — there is no shared mutation of the parent value.
+
+## Optional dependency for tracing
+
+```go
+type ServerParams struct {
+    fx.In
+
+    Logger *zap.Logger
+    Tracer trace.Tracer `optional:"true"`
+}
+
+func NewServer(p ServerParams) *Server {
+    s := &Server{log: p.Logger}
+    if p.Tracer == nil {
+        s.tracer = trace.NewNoopTracerProvider().Tracer("noop")
+    } else {
+        s.tracer = p.Tracer
+    }
+    return s
+}
+```
+
+Reach for `optional` only when the dependency is genuinely optional. A missing core service hidden behind `optional` becomes a nil-pointer panic at first use.
+
+## Manual lifecycle for embedding fx in a CLI
+
+When fx is one component inside a larger program (a CLI tool, a test runner), drive Start/Stop yourself instead of calling `Run()`:
+
+```go
+func runFxApp(parent context.Context) error {
+    app := fx.New(
+        fx.Provide(NewConfig, NewLogger, NewWorker),
+        fx.Invoke(func(*Worker) {}),
+    )
+    if err := app.Err(); err != nil {
+        return fmt.Errorf("wire: %w", err)
+    }
+
+    startCtx, cancel := context.WithTimeout(parent, 30*time.Second)
+    defer cancel()
+    if err := app.Start(startCtx); err != nil {
+        return fmt.Errorf("start: %w", err)
+    }
+
+    select {
+    case <-parent.Done():
+    case <-app.Done(): // SIGINT/SIGTERM
+    }
+
+    stopCtx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
+    defer cancel()
+    return app.Stop(stopCtx)
+}
+```
+
+`app.Err()` validates wiring without starting — useful for `--check` style flags.
+
+## Custom event logger that filters noise
+
+```go
+type ProductionLogger struct {
+    inner *fxevent.ZapLogger
+}
+
+func (l *ProductionLogger) LogEvent(e fxevent.Event) {
+    switch e.(type) {
+    case *fxevent.Provided, *fxevent.Supplied, *fxevent.Decorated:
+        return // drop the per-Provide chatter
+    default:
+        l.inner.LogEvent(e)
+    }
+}
+
+fx.New(
+    fx.Provide(NewZapLogger),
+    fx.WithLogger(func(log *zap.Logger) fxevent.Logger {
+        return &ProductionLogger{inner: &fxevent.ZapLogger{Logger: log}}
+    }),
+)
+```
+
+In production, filtering provide/decorate noise leaves only lifecycle (start/stop) events and errors — much easier to audit.
diff --git a/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/testing.md b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/testing.md
new file mode 100644
index 00000000..af86f126
--- /dev/null
+++ b/packages/autoskills/skills-registry/samber-go-skills/skills/golang-uber-fx/references/testing.md
@@ -0,0 +1,144 @@
+# Testing with uber-go/fx
+
+`go.uber.org/fx/fxtest` integrates fx applications with `*testing.T`: errors fail the test instead of crashing the process, and lifecycle teardown is registered automatically.
+
+## Pulling a value out of the graph with `fx.Populate`
+
+```go
+func TestUserService_Create(t *testing.T) {
+    var svc *UserService
+
+    app := fxtest.New(t,
+        fx.Provide(
+            func() Database { return &fakeDatabase{} },
+            NewUserService,
+        ),
+        fx.Populate(&svc),
+    )
+    defer app.RequireStop()
+    app.RequireStart()
+
+    require.NoError(t, svc.Create(context.Background(), "alice@example.com"))
+}
+```
+
+`fx.Populate(&svc)` fills `svc` with the value the graph would resolve. It replaces ad-hoc `fx.Invoke(func(s *UserService) { svc = s })` patterns.
+
+## `fx.Replace` to swap a real dependency for a fake
+
+```go
+func TestServer_HandlesDBError(t *testing.T) {
+    var srv *http.Server
+    fakeDB := &erroringDatabase{}
+
+    app := fxtest.New(t,
+        ProductionModule,                                 // the real wiring
+        fx.Replace(fx.Annotate(fakeDB, fx.As(new(Database)))),
+        fx.Populate(&srv),
+    )
+    defer app.RequireStop()
+    app.RequireStart()
+
+    // Drive the server with a fake DB
+    rec := httptest.NewRecorder()
+    req := httptest.NewRequest(http.MethodGet, "/users", nil)
+    srv.Handler.ServeHTTP(rec, req)
+    require.Equal(t, http.StatusInternalServerError, rec.Code)
+}
+```
+
+`fx.Replace` works even when the original provider is buried inside a module — it overrides the resolved type without rewriting the module.
+
+## Standalone lifecycle for a unit test
+
+`fxtest.NewLifecycle(t)` gives you an `fx.Lifecycle` outside the `fx.New` machinery, useful for testing a single constructor that registers hooks:
+
+```go
+func TestWorker_StartStop(t *testing.T) {
+    lc := fxtest.NewLifecycle(t)
+
+    worker := NewWorker(lc, zaptest.NewLogger(t))
+    require.NotNil(t, worker)
+
+    lc.RequireStart() // runs OnStart hooks
+    require.True(t, worker.IsRunning())
+
+    lc.RequireStop()  // runs OnStop hooks
+    require.False(t, worker.IsRunning())
+}
+```
+
+This is the lightest test for a constructor — no full graph, no `fx.New`.
+
+## Asserting wire-time errors
+
+```go
+func TestWiring_MissingDependency(t *testing.T) {
+    app := fx.New(
+        fx.Provide(NewServer), // depends on *sql.DB which is not provided
+        fx.NopLogger,
+    )
+    require.Error(t, app.Err())
+    require.Contains(t, app.Err().Error(), "missing type: *sql.DB")
+}
+```
+
+Use `fx.New` (not `fxtest.New`) when you _expect_ the wiring to fail — `fxtest.New` would call `t.Fatal`.
+
+## Validating the production graph in CI
+
+```go
+func TestProductionGraph(t *testing.T) {
+    app := fx.New(
+        ProductionOptions(), // every fx.Provide / fx.Module the binary uses
+        fx.NopLogger,
+    )
+    require.NoError(t, app.Err())
+}
+```
+
+`fx.New` validates the type graph without starting. The test fails before deploy on any missing-provider, cycle, or annotation mismatch.
+
+## Test logger that captures fx events
+
+When you want to assert on lifecycle behavior, route fx events into an in-memory observer:
+
+```go
+// go.uber.org/zap/zaptest/observer
+core, recorded := observer.New(zap.InfoLevel)
+log := zap.New(core)
+
+app := fxtest.New(t,
+    fx.WithLogger(func() fxevent.Logger {
+        return &fxevent.ZapLogger{Logger: log}
+    }),
+    fx.Provide(NewWorker),
+    fx.Invoke(func(*Worker) {}),
+)
+defer app.RequireStop()
+app.RequireStart()
+
+require.NotEmpty(t, recorded.FilterMessage("OnStart hook executed").All())
+```
+
+## Testing a lifecycle hook in isolation
+
+If a constructor returns a value _and_ registers a hook, you often want to test both halves:
+
+```go
+func TestNewServer_OnStartFailsBindError(t *testing.T) {
+    // Bind a port so :0 is unavailable... no, simpler: pre-bind and pass that addr
+    listener, err := net.Listen("tcp", "127.0.0.1:0")
+    require.NoError(t, err)
+    defer listener.Close()
+    addr := listener.Addr().String()
+
+    cfg := &Config{Addr: addr}
+    lc := fxtest.NewLifecycle(t)
+
+    NewHTTPServer(lc, zaptest.NewLogger(t), cfg)
+
+    // Use Start directly (not RequireStart) so we can assert the error.
+    require.Error(t, lc.Start(context.Background()))
+}
+```
diff --git a/packages/autoskills/tests/cli.test.ts b/packages/autoskills/tests/cli.test.ts
index 3c787cda..b39e704c 100644
--- a/packages/autoskills/tests/cli.test.ts
+++ b/packages/autoskills/tests/cli.test.ts
@@ -319,9 +319,9 @@ describe("CLI", () => {
       writeFile(tmp.path, "go.mod", "module example.com/test\n\ngo 1.24.0\n");
       const output = run(["--dry-run"], tmp.path);
       ok(output.includes("Go"));
-      ok(output.includes("golang-patterns"));
-      ok(output.includes("golang-testing"));
-      ok(output.indexOf("golang-patterns") < output.indexOf("golang-testing"));
+      ok(output.includes("golang-code-style"));
+      ok(output.includes("golang-concurrency"));
+      ok(output.indexOf("golang-code-style") < output.indexOf("golang-concurrency"));
       ok(!output.includes("No skills available for your stack yet."));
       ok(output.includes("nothing was installed"));
     });
diff --git a/packages/autoskills/tests/collect.test.ts b/packages/autoskills/tests/collect.test.ts
index 4bdbce23..7a5600ec 100644
--- a/packages/autoskills/tests/collect.test.ts
+++ b/packages/autoskills/tests/collect.test.ts
@@ -77,8 +77,8 @@ describe("collectSkills", () => {
     deepStrictEqual(
       skills.slice(0, 2).map(({ skill, sources }) => ({ skill, sources })),
       [
-        { skill: "affaan-m/everything-claude-code/golang-patterns", sources: ["Go"] },
-        { skill: "affaan-m/everything-claude-code/golang-testing", sources: ["Go"] },
+        { skill: "samber/cc-skills-golang/golang-code-style", sources: ["Go"] },
+        { skill: "samber/cc-skills-golang/golang-concurrency", sources: ["Go"] },
       ],
     );
   });

From f8c22d1b917abf586077e690a7a6ca3709bfa106 Mon Sep 17 00:00:00 2001
From: seba3567 <sebastian26481@gmail.com>
Date: Mon, 15 Jun 2026 18:33:55 -0400
Subject: [PATCH 7/7] fix(review): update review metadata and restrict
 PostgreSQL detection

---
 packages/autoskills/installer.ts              |   2 +-
 packages/autoskills/skills-map.ts             |   2 +-
 .../autoskills/skills-registry/index.json     | 164 +++++++++---------
 3 files changed, 84 insertions(+), 84 deletions(-)

diff --git a/packages/autoskills/installer.ts b/packages/autoskills/installer.ts
index dd5e4b49..15fea478 100644
--- a/packages/autoskills/installer.ts
+++ b/packages/autoskills/installer.ts
@@ -32,7 +32,7 @@ export interface RegistryEntry {
   sha256: Record<string, string>;
   bundleHash: string;
   review: {
-    status: "approved" | "flagged";
+    status: "approved" | "flagged" | "skipped";
     flags: string[];
     summary: string;
     model: string;
diff --git a/packages/autoskills/skills-map.ts b/packages/autoskills/skills-map.ts
index 1aeff6f9..60a4f98c 100644
--- a/packages/autoskills/skills-map.ts
+++ b/packages/autoskills/skills-map.ts
@@ -940,7 +940,7 @@ export const SKILLS_MAP: Technology[] = [
     id: "postgresql",
     name: "PostgreSQL",
     detect: {
-      packages: ["pg", "postgres", "pg-promise", "sequelize", "typeorm", "mikro-orm"],
+      packages: ["pg", "postgres", "pg-promise"],
     },
     skills: [
       "neondatabase/postgres-skills/postgres-best-practices",
diff --git a/packages/autoskills/skills-registry/index.json b/packages/autoskills/skills-registry/index.json
index fd5eb40e..4ffe1b50 100644
--- a/packages/autoskills/skills-registry/index.json
+++ b/packages/autoskills/skills-registry/index.json
@@ -742,8 +742,8 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Svelte 5 reactivity runes implementation skill",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
         "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
@@ -762,8 +762,8 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "SvelteKit file structure and routing conventions",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
         "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
@@ -782,8 +782,8 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Svelte core best practices guidelines",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
         "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
@@ -808,8 +808,8 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Svelte LayerChart data visualization component guidelines for Svelte 5",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
         "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
@@ -828,8 +828,8 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "SvelteKit data flow and form actions",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
         "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
@@ -848,8 +848,8 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Svelte UI components and integration guidelines",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
         "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
@@ -4562,10 +4562,10 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Go code style guidelines",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T22:06:00.000Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "golang-concurrency": {
@@ -4582,10 +4582,10 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Go concurrency patterns guidelines",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T22:06:00.000Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "golang-context": {
@@ -4602,10 +4602,10 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Go context propagation guidelines",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T22:06:00.000Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "golang-database": {
@@ -4630,10 +4630,10 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Go database best practices and library choice guidelines",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T22:06:00.000Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "golang-error-handling": {
@@ -4650,10 +4650,10 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Go error handling patterns",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T22:06:00.000Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "golang-performance": {
@@ -4670,10 +4670,10 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Go performance and memory optimization guidelines",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T22:06:00.000Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "golang-testing": {
@@ -4690,10 +4690,10 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Go testing structure and implementation guidelines",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T22:06:00.000Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "golang-observability": {
@@ -4710,10 +4710,10 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Go logging and telemetry guidelines",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T22:06:00.000Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "golang-security": {
@@ -4730,10 +4730,10 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Go security standards and injection prevention",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T22:06:00.000Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "golang-structs-interfaces": {
@@ -4750,10 +4750,10 @@
       "review": {
         "status": "approved",
         "flags": [],
-        "summary": "Go structures and interface composition guidelines",
-        "model": "gpt-5.4",
+        "summary": "review skipped (--no-review)",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T22:06:00.000Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "java-coding-standards": {
@@ -5253,9 +5253,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.549Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "java-springboot": {
@@ -5273,9 +5273,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.558Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "dotnet-best-practices": {
@@ -5293,9 +5293,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.567Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "dotnet-design-pattern-review": {
@@ -5313,9 +5313,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.576Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "dotnet-upgrade": {
@@ -5333,9 +5333,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.586Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "csharp-xunit": {
@@ -5353,9 +5353,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.595Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "csharp-async": {
@@ -5373,9 +5373,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.604Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "csharp-docs": {
@@ -5393,9 +5393,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.614Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "csharp-nunit": {
@@ -5413,9 +5413,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.623Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "csharp-mstest": {
@@ -5433,9 +5433,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.632Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "csharp-tunit": {
@@ -5453,9 +5453,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.641Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "containerize-aspnetcore": {
@@ -5473,9 +5473,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.650Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "fluentui-blazor": {
@@ -5501,9 +5501,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.660Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "aspnet-minimal-api-openapi": {
@@ -5521,9 +5521,9 @@
         "status": "approved",
         "flags": [],
         "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-04-17T22:43:41.669Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       }
     },
     "prisma-database-setup": {
@@ -13299,12 +13299,12 @@
       },
       "bundleHash": "6249e41a2601b9523614f4bf653fcc34f5f8a848cc960cf54d9c4ddc949332f2",
       "review": {
-        "status": "approved",
+        "status": "skipped",
         "flags": [],
-        "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "summary": "No review was performed because the sync process was executed with the --no-review flag.",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T20:58:27.147Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       },
       "securityCheck": {
         "status": "ok",
@@ -13327,12 +13327,12 @@
       },
       "bundleHash": "2897990a74483e7015350b14e72bc2d44a86052d2960390b71057f67f5f3a58c",
       "review": {
-        "status": "approved",
+        "status": "skipped",
         "flags": [],
-        "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "summary": "No review was performed because the sync process was executed with the --no-review flag.",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T21:07:32.664Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       },
       "securityCheck": {
         "status": "ok",
@@ -13353,12 +13353,12 @@
       },
       "bundleHash": "60cd76411c1aa29f5cb2f609c180a466c7c43e3552d086edd5d7f26b70beb68c",
       "review": {
-        "status": "approved",
+        "status": "skipped",
         "flags": [],
-        "summary": "review skipped (--no-review)",
-        "model": "gpt-5.4",
+        "summary": "No review was performed because the sync process was executed with the --no-review flag.",
+        "model": "gpt-4",
         "promptVersion": "1.0.0",
-        "reviewedAt": "2026-06-15T21:08:44.639Z"
+        "reviewedAt": "2026-06-15T21:49:00.000Z"
       },
       "securityCheck": {
         "status": "ok",