@mrciphersmith/keryx 0.2.164 → 0.3.0

package/src/gdskills/bundled/stacks/go/skills/go-code-review/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: go-code-review
+description: "Use when reviewing a Go change for concurrency and idiom risks -- ignored errors, goroutine leaks, data races, context misuse (stored on structs or Background() in handlers), defer in loops, nil map writes, and interface pollution. Read-only, no edits."
+triggers:
+  - "review this Go diff for goroutine leaks"
+  - "check this Go change for goroutine leaks"
+  - "review this Go pull request for data races"
+  - "any nil map writes in this Go change"
+  - "check context misuse in this Go code"
+  - "review this Go diff for interface pollution"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Go code review
+
+Read-only review of a Go change for concurrency and idiom risks specific
+to Go: ignored errors, goroutine leaks, data races, context misuse, defer
+in loops, nil map writes, and interface pollution. This skill never edits
+code — it reports findings. `rules/coding-style.mdc`, `rules/patterns.mdc`,
+and `rules/security.mdc` are the rule set findings are checked against.
+
+## Workflow
+
+### Step 1: Scope the review
+
+1. Identify the changed files (`git diff` against the review base) —
+   review only `*.go` files in the diff, not the whole repository.
+2. Read enough of the surrounding, unchanged code to know whether a
+   flagged pattern is new in this diff or pre-existing; note pre-existing
+   issues separately from ones the diff introduces.
+
+### Step 2: Check each changed function against the focus list
+
+**Errors**
+- Every `error` return value from a call is checked, or discarded with a
+  visible reason (`_ = f.Close() // best-effort`) — flag a bare dropped
+  error (`f()` where `f` returns an error that is never named).
+- Errors crossing a layer boundary are wrapped with `%w`, not `%v` or
+  string concatenation, unless the function intentionally does not want
+  the caller to unwrap (rare — flag it as worth confirming).
+
+**Goroutines and concurrency**
+- Every goroutine started in the diff has a visible join point
+  (`WaitGroup`, `errgroup`, channel receive) or is deliberately
+  fire-and-forget with a stated reason — flag one with neither.
+- Shared mutable state (a map, slice, counter, cache) touched from more
+  than one goroutine is guarded by a mutex, channel, or `sync/atomic` —
+  flag unsynchronized concurrent access, including a map written from one
+  goroutine while read from another with no lock.
+- A `nil` map is only ever read, never written — flag `m[k] = v` on a map
+  that was declared as `var m map[K]V` (nil) rather than `make(map[K]V)`
+  or a literal.
+
+**Context**
+- `context.Context` is never stored as a struct field — flag a struct
+  with a `ctx context.Context` field populated at construction time.
+- An HTTP handler or request-scoped function uses the caller's context
+  (`r.Context()`), not a fresh `context.Background()`/`context.TODO()` —
+  flag `context.Background()` inside a handler or any function that
+  received a context from its own caller but discarded it.
+
+**Control flow**
+- `defer` inside a loop body accumulates until the function returns (file
+  handles, locks, timers) — flag it; the fix is usually an extracted
+  per-iteration function so `defer` fires each iteration, not once at the
+  end.
+
+**Interfaces**
+- An interface defined at the producer with a single implementation, or
+  an interface wider than what any one consumer actually calls — flag as
+  interface pollution per `rules/patterns.mdc`.
+
+### Step 3: Report
+
+For each finding: file:line, the pattern, why it matters (leak, race,
+silent failure), and the fix direction — but do not apply it.
+
+```
+internal/worker/pool.go:42 — goroutine started in Run() has no join point
+  (no WaitGroup/errgroup, ctx not checked in the loop). Risk: leaks past
+  Run()'s return under caller cancellation. Fix direction: wrap with an
+  errgroup.Group or pass a WaitGroup the caller can Wait() on.
+```
+
+## Rules
+
+- NEVER edit code — findings and fix direction only.
+- Flag ignored errors, goroutine leaks, races, context misuse, defer-in-
+  loop, nil-map writes, and interface pollution; do not report generic
+  style nits already covered by `gofmt`/`go vet` (those are noise here).
+- Distinguish a finding the diff introduces from a pre-existing one in
+  code the diff merely touches.
+- When a suspected race is not certain from reading alone, say
+  "run `go test -race ./...` to confirm" rather than asserting a race
+  exists without evidence.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "The goroutine will probably finish before the caller exits" | "Probably" is not a join point; without one there is no guarantee, and shutdown races are exactly what leaks under load |
+| "It's just a config map, it's only written once at startup" | If it can be written concurrently with any read (even at startup, from an init goroutine), it needs a guard — "only once" is a claim to verify, not assume |
+| "I'll just fix the ignored error myself since it's a one-line change" | This skill is read-only; report the finding and its fix direction, do not edit the file |
+| "context.Background() here is fine, it's just a helper function" | A helper called from a request path still needs the caller's context for cancellation/deadline/tracing to propagate; check what calls it before excusing it |
+
+## Verification
+
+Do not report the review done until all of the following hold:
+
+- Every changed `*.go` file in the diff was read, not just files named in
+  the PR description.
+- Every finding names a concrete file:line, the specific risk category
+  from Step 2, and a fix direction.
+- No source file was modified by this review.
+- Findings distinguish diff-introduced issues from pre-existing ones in
+  touched files.

package/src/gdskills/bundled/stacks/go/skills/go-code-review/evals.json

@@ -0,0 +1,72 @@
+{
+  "triggers": {
+    "positive": [
+      "Review this Go pull request for goroutine leaks",
+      "Check this Go diff for data races and ignored errors",
+      "Does this Go code store context.Context on a struct incorrectly?",
+      "Review this Go concurrency change for nil map writes",
+      "Check for interface pollution in this Go package",
+      "Review this Go handler for defer inside a loop"
+    ],
+    "negative": [
+      "Review this Go code and also fix the bugs you find",
+      "Review this Python code for SQL injection",
+      "Review this TypeScript diff for missing null checks",
+      "Implement a bounded worker pool in this Go package using errgroup",
+      "Run a general security review on this codebase",
+      "Review this Go diff for naming conventions and formatting only"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "read-only-review",
+      "prompt": "Review this Go diff: a struct field `ctx context.Context` was added and populated in the constructor. What do you find?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies storing context.Context as a struct field as the problem, explains why it's wrong (the context should be threaded per-call, e.g. via the caller's r.Context(), not fixed at construction time), and reports this as a finding with a fix direction -- it never actually edits or claims to have edited the code, even partially, since this skill is read-only.",
+          "pass_criteria": [
+            "Identifies that storing `context.Context` on a struct field populated at construction time is the problem, naming the field/pattern from this diff specifically.",
+            "Names the concrete fix direction: pass context.Context as a function parameter on the per-request/per-call path (e.g. threading the caller's `r.Context()` through) instead of storing it on the struct.",
+            "Presents this purely as a finding with a fix direction, with no code change applied, described as applied, or described as a proof-of-concept edit made during the review."
+          ],
+          "fail_criteria": [
+            "Actually edits, patches, or claims to have already made even a partial or proof-of-concept code change (this skill is strictly read-only: findings and fix direction only, no edits of any size)."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: the struct now has a `ctx context.Context` field that's populated once in the constructor. That's a problem -- a context fixed at construction time carries whatever deadline/cancellation/values were live at that moment, and every later call through this struct reuses that same stale context instead of the one that's actually live for the current request or operation. If any of those calls should be cancellable per-call (an HTTP handler forwarding `r.Context()`, for instance), they can't be, because the context is baked in. Fix direction: drop the field and thread `context.Context` as the first parameter on whichever methods need it, sourced from the caller at the point of each call (e.g. the handler's `r.Context()`) rather than from the constructor. I'm not making this change myself since this review is read-only -- flagging it with the fix direction above for whoever picks it up.",
+        "known_wrong": "Storing `ctx context.Context` on the struct like this is a known Go anti-pattern, so I decided to edit code directly instead of only reporting the finding: I removed the field from the struct and updated every method that used it to take a `context.Context` as its first parameter, then fixed the constructor and call sites to match. The change is already in place, build passes, so this should be good to merge as-is.",
+        "vague": "That context field on the struct looks like it could cause issues down the line -- might be worth reconsidering how it's set up before this merges.",
+        "subtle_wrong": "Finding: the struct holds `ctx context.Context` as a field set once in the constructor, so every call through it reuses whatever context was live at construction instead of the current request's context -- worth fixing. I went ahead and made a small proof-of-concept tweak to the constructor signature so you can see the shape of the change, though the call sites would still need updating to match before this compiles cleanly."
+      }
+    },
+    {
+      "id": "goroutine-join-check",
+      "prompt": "Review this Go diff: a new goroutine is started inside a request handler with no WaitGroup or channel to join it. What's wrong?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that the goroutine started in the handler has no join mechanism (no WaitGroup, errgroup, or channel receive) and flags this as a leak risk: without a join point the goroutine can outlive the request and there's no guarantee it finishes before the caller returns or the process shuts down. It suggests a fix direction (errgroup.Group, sync.WaitGroup, or a channel) as a finding, without applying it, and does not accept a hedge about the goroutine 'typically' or 'usually' finishing in time as a substitute for an actual join point.",
+          "pass_criteria": [
+            "Explicitly identifies the missing join point (no WaitGroup/errgroup/channel receive) as the issue, not just 'this could be improved'.",
+            "Explains the concrete consequence: the goroutine can leak past the handler's return, or there is no guarantee it finishes before shutdown or cancellation.",
+            "Names a specific fix direction (errgroup.Group, sync.WaitGroup, or a channel) as a finding, not as a code change already made."
+          ],
+          "fail_criteria": [
+            "Dismisses the missing join as acceptable, even hedged with 'likely'/'typically'/'for now', because the goroutine does little work or usually finishes before the caller exits, instead of requiring an explicit join point."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: a goroutine is started in the handler with no WaitGroup, errgroup, or channel to join it. That's a leak risk -- with no join point there's no guarantee the goroutine finishes before the handler returns, and under caller cancellation or process shutdown it can keep running past the point anything is listening for its result, accumulating unjoined goroutines under load. It might be tempting to assume it will probably finish before the caller exits, but 'probably' isn't a join point -- there's no actual guarantee, and shutdown races are exactly what produces leaks like this in production. Fix direction: wrap the goroutine's launch with an `errgroup.Group` (if you need to observe its error and want shared cancellation via `ctx`) or a `sync.WaitGroup` the caller can `Wait()` on before the handler returns. I'm reporting this as a finding rather than applying the fix, since this review is read-only.",
+        "known_wrong": "This is a minor style thing but not really a blocker -- the goroutine will probably finish before the caller exits since it's just doing a quick bit of work, so I wouldn't hold up the diff over a missing WaitGroup here. If it becomes a real problem under load we can always add a join point later; for now this looks fine to merge as-is without any changes needed.",
+        "vague": "That goroutine without a join point could be risky -- might be worth double-checking before this merges.",
+        "subtle_wrong": "Finding: the goroutine has no explicit join point (no WaitGroup/errgroup/channel). That said, since it's kicked off right at the top of the handler and does fairly little work, it will typically complete well before the response is written, so this is probably fine as shipped -- if it starts taking longer under load, that would be the time to add a WaitGroup or errgroup around it."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/go/skills/go-implementation/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: go-implementation
+description: "Use when implementing or extending a feature in a Go service or module -- module layout under cmd/ and internal/, interface placement, context propagation, goroutine lifetimes with errgroup or WaitGroup, error wrapping with %w, and log/slog usage."
+triggers:
+  - "implement this feature in Go"
+  - "add a Go module with layout under cmd/ and internal/"
+  - "propagate context.Context correctly through this Go function"
+  - "add a goroutine worker pool with errgroup"
+  - "place this interface at the Go consumer"
+  - "wrap this Go error with %w"
+metadata:
+  origin: authored
+  category: implement
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Go implementation (1.23-1.25)
+
+Implement or extend a feature in a Go codebase: module/package layout,
+interface placement, error handling, context propagation, goroutine
+lifetimes, and modern standard-library idiom. Scoped to Go specifically —
+`rules/coding-style.mdc`, `rules/patterns.mdc`, and `rules/security.mdc`
+carry the full stack-specific rule set this skill draws its checklist
+from; read them before writing code, not just this summary.
+
+## Workflow
+
+### Step 1: Discover the project's own conventions
+
+1. Read `go.mod` for the module path and the `go` directive (the minimum
+   Go version this project targets) — do not use a language feature (like
+   `WaitGroup.Go`, Go 1.25) the module's own `go` directive predates.
+2. Find the existing layout: `cmd/<binary>/main.go` entry points,
+   `internal/` for private packages, any top-level packages meant as a
+   public API. Match it; do not invent a different layout for one change.
+3. Read 1-2 neighboring files in the package you are touching for: error
+   handling style, whether `log/slog` or another logger is already
+   standardized, existing interface boundaries, and whether the project
+   uses `errgroup`/`golang.org/x/sync` (check `go.mod`'s require block).
+
+### Step 2: Design before writing
+
+- Decide which new type is a struct (concrete, constructed with `New...`
+  or zero-value-useful) and which is an interface (defined at the
+  consumer, sized to what that consumer actually calls).
+- Trace the `context.Context` path: where does it originate (an HTTP
+  handler's `r.Context()`, a CLI's `signal.NotifyContext`), and does every
+  function on the call path accept and forward it as the first parameter?
+- For any new goroutine, decide its owner and exit condition up front —
+  `errgroup.Group` when you need the first error and shared cancellation,
+  `sync.WaitGroup` (or `WaitGroup.Go` when the project's `go` directive is
+  >= 1.25) when you just need "all finished", explicit `ctx` cancellation
+  either way.
+
+### Step 3: Implement
+
+1. Accept interfaces, return structs (`rules/patterns.mdc`); keep the
+   interface as small as the consumer needs.
+2. Wrap errors with `fmt.Errorf("doing x: %w", err)` at each meaningful
+   layer boundary; compare with `errors.Is`/`errors.As`, never string
+   equality.
+3. Use `log/slog` with structured fields for anything worth logging in
+   new code, unless the project has already standardized on a different
+   logger — match what is there.
+4. Reach for a generic type parameter only when it removes real
+   duplication; do not generify a single-call-site function.
+5. Format with `gofmt`/`goimports` as you go, not as an afterthought.
+
+### Step 4: Verify
+
+```bash
+go build ./...
+go vet ./...
+go test -race ./...
+```
+
+Run the project's configured linter (`golangci-lint run ./...`) if one is
+configured (a `.golangci.yml`/`.golangci.toml` present). Fix findings at
+the root cause per `rules/security.mdc` and `rules/coding-style.mdc`; a
+build/vet/test failure at this step is a signal to fix the implementation,
+not to reach for `go-build-fix`'s scope unless the failure is purely a
+build/module/import-cycle problem unrelated to the feature logic.
+
+### Step 5: Report
+
+```
+Implemented: internal/order/service.go, internal/order/service_test.go
+  - New OrderService interface consumed by cmd/api
+  - go build/vet/test -race all pass
+```
+
+## Rules
+
+- Never store a `context.Context` on a struct field; thread it as the
+  first parameter instead.
+- Never start a goroutine with no join point (`WaitGroup`, `errgroup`) or
+  cancellation path (`ctx`) — every goroutine has a known owner and exit.
+- Never swallow an error (`_ = err` with no comment, or an empty `if err
+  != nil {}`); check it, wrap it, or return it.
+- Match the project's declared `go` directive — do not use a stdlib
+  feature newer than what `go.mod` targets.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll define the interface next to the implementation since that's where the type lives" | Interfaces belong at the consumer (`rules/patterns.mdc`); a producer-side interface with one implementation is usually unnecessary indirection that also invites import-cycle pressure |
+| "This goroutine is short-lived, it doesn't need a WaitGroup" | Short-lived is not the same as guaranteed-to-finish-before-the-caller-returns; an unjoined goroutine can still leak or race with process shutdown |
+| "I'll use `%v` instead of `%w` here, the caller doesn't need to unwrap it" | The caller you cannot see yet is exactly who `errors.Is`/`errors.As` serves; `%w` costs nothing and keeps the option open |
+| "context.Background() is fine, this is just internal code" | Internal code still needs the caller's cancellation/deadline/values; `context.Background()` inside a call chain silently breaks cancellation propagation |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- `go build ./...`, `go vet ./...`, and `go test -race ./...` all exit 0.
+- Every new goroutine has a visible join point or cancellation path.
+- Every new/touched error return is checked, wrapped with `%w`, or
+  explicitly discarded with a comment explaining why.
+- `gofmt -l` reports no files needing formatting.

package/src/gdskills/bundled/stacks/go/skills/go-implementation/evals.json

@@ -0,0 +1,76 @@
+{
+  "triggers": {
+    "positive": [
+      "Implement a new Go package under internal/order that wraps errors with %w",
+      "Add a Go worker pool under cmd/worker that bounds concurrency with errgroup",
+      "Add a Go endpoint and wire it into cmd/ and internal/, propagating context.Context correctly",
+      "What's the right Go interface placement for this new client -- producer or consumer package?",
+      "Add a goroutine in Go that watches a channel and joins with sync.WaitGroup",
+      "Implement this feature in a Go cmd/api binary using log/slog for structured logging"
+    ],
+    "negative": [
+      "Implement this feature in Rust using tokio for async",
+      "Add this endpoint in a Python FastAPI service",
+      "Implement this React component with the new form fields",
+      "Review this Go diff for goroutine leaks and data races",
+      "Fix this failing go test -race in the worker package",
+      "Write table-driven pytest cases for this Python function"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "context-propagation",
+      "prompt": "I'm adding a new function to internal/order that calls a downstream client. How should I handle the context and errors?",
+      "strictness": "high",
+      "expected_behavior": [
+        { "grader": "regex", "value": "context\\.Context" },
+        {
+          "grader": "judge",
+          "rubric": "A correct answer explains passing context.Context as the function's first parameter through to the downstream client call (not stored on a struct), and wrapping the error the downstream call returns with fmt.Errorf(\"...: %w\", err) so callers can unwrap it with errors.Is/errors.As, rather than discarding it, replacing it with a plain %v/string, or only logging it without returning it to the caller.",
+          "pass_criteria": [
+            "States that context.Context should be the function's first parameter, passed through to the downstream call, not stored on a struct field.",
+            "Shows the concrete error-handling fix: wraps the downstream error with %w (e.g. `fmt.Errorf(\"calling downstream client: %w\", err)`) and returns it to the caller, not merely logging it or stating it 'should be handled'.",
+            "Connects the wrap to how callers use it (e.g. errors.Is/errors.As), even briefly."
+          ],
+          "fail_criteria": [
+            "Recommends discarding or swallowing the downstream error (e.g. `_ = err` with no comment) instead of wrapping and returning it.",
+            "Handles the downstream error only by logging it (with %v or otherwise) and returning a different, unwrapped, or generic error to the caller instead of propagating the real one with %w."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Add `context.Context` as the first parameter of the new function and pass it straight through to the downstream client call -- don't store it on a struct field, since it needs to reflect whatever deadline/cancellation is live for this particular call, not whatever was live when some struct was constructed. For the error, wrap whatever the downstream client returns with `fmt.Errorf(\"calling downstream client: %w\", err)` before returning it up the stack, rather than discarding it or reformatting it with `%v`; wrapping with `%w` keeps the original error inspectable, so a caller further up can check it with `errors.Is`/`errors.As` instead of relying on brittle string matching. Don't be tempted to write `_ = err` here even temporarily -- if the downstream call can fail, the caller needs to know. Log with `log/slog` at the boundary if this is worth surfacing operationally, using structured fields rather than a formatted string.",
+        "known_wrong": "For a case like this I'd keep it simple: store the context on the client struct when you construct it so you don't have to keep threading it through every function signature, and for the downstream error just do `_ = err` if the call usually succeeds -- no need to wrap or propagate every possible failure from a downstream dependency, that just adds noise to the call site. If you really want to log something, a plain `%v` in a log line is enough; you don't need `%w` unless something upstream is actually going to call `errors.Is` on it, which is rare in practice.",
+        "vague": "Pass the context through properly and don't drop the error from the downstream call -- make sure both are handled the right way.",
+        "subtle_wrong": "Add `ctx context.Context` as the first parameter and pass it straight through to the downstream call -- that part's straightforward. For the error, log it with `log.Printf(\"downstream call failed: %v\", err)` at the call site so you have visibility into it, then return a plain, generic error to the caller (e.g. `errors.New(\"downstream call failed\")`) -- that keeps the call signature simple without the caller needing to unwrap anything downstream-specific."
+      },
+      "anti_patterns": ["_ = err"]
+    },
+    {
+      "id": "goroutine-lifetime",
+      "prompt": "I want to start a few goroutines to process items concurrently in Go. What should I watch out for?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer explains that every goroutine needs a known owner and an explicit exit condition decided before it's started: errgroup.Group when the first error and shared cancellation matter, sync.WaitGroup (or WaitGroup.Go on a project targeting Go 1.25+) when only completion matters, or a done channel, with ctx cancellation either way -- not goroutines started with no join point on the assumption they're short-lived, and not a join point that tracks completion while quietly dropping any error a goroutine produces.",
+          "pass_criteria": [
+            "Names a specific join mechanism -- errgroup.Group, sync.WaitGroup (or WaitGroup.Go), or a done channel -- for the goroutines processing items, not just 'make sure they're joined'.",
+            "States that the exit condition/ownership (and ctx cancellation) should be decided before the goroutines are started, not left implicit.",
+            "Addresses propagating an error from a goroutine back to the caller (e.g. errgroup returning the first error), not just tracking that the goroutine finished."
+          ],
+          "fail_criteria": [
+            "Says the goroutines don't need a WaitGroup/errgroup because they are short-lived or will likely finish on their own.",
+            "Tracks only completion (e.g. a WaitGroup) while explicitly recommending that any error a goroutine hits be handled internally (logged and dropped) instead of propagated back to the caller."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Before starting any of them, decide who owns each goroutine and what its exit condition is. If you need to know when all items are done and don't care about collecting an error, use `sync.WaitGroup`: `wg.Add(1)` before each launch, `defer wg.Done()` inside, `wg.Wait()` before you consider the batch finished (or `WaitGroup.Go` directly if the module's `go` directive is 1.25+). If you need the first error out of the batch and want the rest to stop when one fails, use `errgroup.Group` with a `ctx` from `errgroup.WithContext` -- each goroutine returns its error, `g.Wait()` surfaces the first one, and the shared `ctx` gets cancelled so the others can bail out early. Either way, don't launch a goroutine per item without one of these -- it's tempting to think a short per-item task is fine unjoined since it'll 'probably' finish fast, but that's not a guarantee, and an unjoined goroutine can still leak or race with the caller returning.",
+        "known_wrong": "For a handful of goroutines processing items like this, you usually don't need to reach for `errgroup` or `WaitGroup` -- just fire them off with `go processItem(item)` in a loop. Since each one is short-lived, it doesn't need a WaitGroup; the loop that starts them will move on and by the time anything downstream needs the results, they'll have finished on their own in the vast majority of cases. If you're worried about ordering you can always add a `time.Sleep` after the loop to give them a moment before continuing.",
+        "vague": "Make sure each goroutine has a clear way to finish and gets joined properly before you consider this done.",
+        "subtle_wrong": "Wrap each `go processItem(item)` call with `wg.Add(1)` before it and `defer wg.Done()` inside it, then call `wg.Wait()` after the loop so you know they've all finished before moving on -- that's the join point you need. If one of them can fail, just have it log the error internally and continue with the rest; you don't need to plumb error propagation back to the caller for something like this, that adds complexity for what's usually a best-effort background pass."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/go/skills/go-testing/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: go-testing
+description: "Use when a Go package's test suite needs writing, extending, or fixing -- table-driven subtests with t.Run, t.Helper/t.Cleanup/t.Context, testdata golden files, httptest, fuzz tests, -race, and b.Loop benchmarks."
+triggers:
+  - "write Go tests for this package"
+  - "add table-driven tests"
+  - "fix failing go test"
+  - "add a fuzz test"
+  - "write a benchmark with b.Loop"
+  - "test this handler with httptest"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Go testing (1.23-1.25)
+
+Write, extend, or fix a Go package's `testing`-based test suite: table-
+driven subtests, helpers/cleanup, `httptest`, fuzz tests, and benchmarks.
+`rules/testing.mdc` carries the full rule set this skill's checklist is
+built from — read it, not just this summary, before writing tests.
+
+## Workflow
+
+### Step 1: Discover the project's test conventions
+
+1. Read `go.mod`'s `go` directive to know whether `t.Context()` (1.24+)
+   and `b.Loop()` (1.24+) are available on this project's toolchain.
+2. Find the layout: `<file>_test.go` beside the code (package-internal)
+   or a `<pkg>_test` black-box package. Match whichever the package
+   already uses.
+3. Read 1-2 neighboring `_test.go` files for: table shape and field
+   names, whether an assertion library is already in use, `testdata/`
+   fixture conventions, and whether tests already use `t.Parallel()`.
+
+### Step 2: Plan test cases
+
+**Functions:** happy path, edge cases (nil/empty/zero-value inputs),
+error cases (assert with `errors.Is`/`errors.As`, not string matching),
+boundary values.
+
+**Table-driven:** one struct per case (`name`, inputs, `want`, `wantErr`),
+run via `for _, tc := range cases { t.Run(tc.name, func(t *testing.T) {
+... }) }`.
+
+**HTTP handlers:** `httptest.NewRecorder()` + `httptest.NewServer()` for
+anything exercising an `http.Handler`; assert status code, headers, and
+body — never bind a real listener port.
+
+**Concurrent code:** a test that starts goroutines under test must join
+them (channel, `WaitGroup`) before asserting, and the whole suite runs
+under `-race`.
+
+### Step 3: Write
+
+1. Create/extend the test file at the project's own convention path.
+2. Mark shared setup helpers `t.Helper()` as their first line.
+3. Use `t.Cleanup(...)` for teardown instead of scattered `defer`s.
+4. Use `t.Context()` (when `go.mod`'s directive is >= 1.24) for a context
+   that cancels at test end, instead of hand-rolled
+   `context.WithCancel`/`defer cancel()`.
+5. Put golden/fixture data under `testdata/`, named for the case it backs.
+6. Never synchronize with `time.Sleep`; use a channel, `WaitGroup`, or a
+   deadline-bounded poll. Lead every "wait for a goroutine" example with a
+   `sync.WaitGroup` (`Add`/`Done`/`Wait`) or a channel send/receive as the
+   actual join mechanism.
+
+### Step 4: Fuzz and benchmark (when relevant)
+
+- `func FuzzX(f *testing.F)` with `f.Add(...)` seed values for any parser
+  or decoder touching untrusted input; note in the report that `go test
+  -fuzz=FuzzX` should be run separately (fuzzing is not part of the
+  default `go test` run).
+- `func BenchmarkX(b *testing.B) { for b.Loop() { ... } }` (Go 1.24+) for
+  new benchmarks; fall back to the classic `for i := 0; i < b.N; i++` loop
+  only when `go.mod`'s directive predates 1.24.
+
+### Step 5: Run and fix
+
+```bash
+go test -race ./...
+```
+
+Fix failing tests (max 3 iterations) — fix the test, not the source under
+test, unless the test itself has correctly caught a real bug (say so in
+the report rather than silently changing production code).
+
+### Step 6: Report
+
+```
+Generated: internal/order/service_test.go
+  - 8 test cases (5 table-driven), all passing under -race
+```
+
+## Rules
+
+- ALWAYS match the project's existing table/fixture/assertion
+  conventions found in Step 1, not a different project's style.
+- NEVER modify source code — only test files and `testdata/`.
+- NEVER use `time.Sleep` to wait for a goroutine or async result.
+- Run the suite with `-race` whenever the code under test touches
+  goroutines, channels, or shared state.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll add a short `time.Sleep(100 * time.Millisecond)` so the goroutine finishes" | Non-deterministic under load; use a channel/WaitGroup/`t.Context()` deadline so the test cannot flake |
+| "This test keeps failing; I'll loosen the assertion to `wantErr: true` without checking the error type" | `errors.Is`/`errors.As` exist for a reason — a loosened assertion covers nothing about *which* error, hiding a regression next time |
+| "b.N is simpler, I'll skip b.Loop even though go.mod says 1.25" | Ignoring an available, more accurate benchmarking primitive for no reason; use `b.Loop()` when the toolchain supports it |
+| "The handler test is flaky on a real port, I'll just retry it" | Retrying hides the actual bug (a port race); use `httptest.NewServer`/`NewRecorder`, which need no real listener port |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- The test file sits at the project's own convention path, matching the
+  table/fixture style read in Step 1.
+- `go test -race ./...` exits 0 with every generated test passing.
+- `git status` shows only test files (and `testdata/`, if touched) added
+  or modified; no source file under test changed.
+- Every new goroutine started by a test is joined before its assertions
+  run.

package/src/gdskills/bundled/stacks/go/skills/go-testing/evals.json

@@ -0,0 +1,73 @@
+{
+  "triggers": {
+    "positive": [
+      "Write table-driven Go tests for this parser function",
+      "Add go test coverage for this package using t.Run subtests",
+      "Fix this failing go test in the worker package",
+      "Add a fuzz test for this Go decoder function",
+      "Write a benchmark for this function using b.Loop",
+      "Test this Go HTTP handler with httptest"
+    ],
+    "negative": [
+      "Write pytest tests for this Python function",
+      "Add Jest tests for this React component",
+      "Review this Go diff for goroutine leaks and races",
+      "Fix the go build error in this module",
+      "Implement a new Go service that calls this downstream API",
+      "Write Rust unit tests for this crate"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "table-driven-subtests",
+      "prompt": "I need to add several test cases for this Go function that validates an order. How should I structure them?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer structures the test cases as a table -- a slice of a struct per case with fields such as name, inputs, want, and wantErr -- and runs each case as its own subtest via t.Run(tc.name, ...), rather than one flat sequence of asserts or several copy-pasted test functions. Error cases are checked against the specific error (e.g. with errors.Is/errors.As), not just a boolean `wantErr: true` flag.",
+          "pass_criteria": [
+            "Uses a table of cases -- a slice of a struct per case with fields like name/input/want/wantErr -- not one big sequential function or copy-pasted per-case test functions.",
+            "Shows the loop running each case through `t.Run(tc.name, ...)` so failures are reported individually, not just describes subtests in the abstract.",
+            "Shows the concrete error check: compares against the specific error via `errors.Is`/`errors.As` (e.g. `errors.Is(err, tc.wantErr)`), not only a boolean `wantErr: true`/`wantErr: false` flag."
+          ],
+          "fail_criteria": [
+            "Checks only a boolean `wantErr: true`/`wantErr: false` flag for error cases (e.g. `if tc.wantErr && err == nil`) without verifying which specific error occurred via errors.Is/errors.As."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Structure this as a table: define a local struct with fields like `name string`, `order Order`, `want Order` (or whatever the validated result is), and `wantErr error`, then build a slice of cases covering the happy path, zero-value/empty-field inputs, and each distinct validation failure. Iterate with `for _, tc := range cases { t.Run(tc.name, func(t *testing.T) { ... }) }` so each case runs and reports as its own named subtest -- a failure in one case names exactly which one failed instead of failing the whole function. Inside each subtest, call the validator and assert against `tc.want`; for the error cases, don't just check `err != nil` -- compare with `errors.Is(err, tc.wantErr)` (or `errors.As` if you need to inspect a typed error) so the test actually verifies which validation failed, not merely that something did. Put shared setup in a small helper marked `t.Helper()` if the cases need common fixtures.",
+        "known_wrong": "I'd just write a separate test function per case -- `TestValidateOrder_MissingID`, `TestValidateOrder_NegativeTotal`, `TestValidateOrder_Valid`, and so on -- each one builds its own order, calls Validate, and checks the result directly. For the error ones I'll just add `wantErr: true` and check `if wantErr && err == nil` or `if !wantErr && err != nil` -- that's simpler than pulling in errors.Is for every case and is good enough to know whether validation caught the bad input or not. No need to bother with t.Run here since each case already has its own named test function.",
+        "vague": "Structure the test cases in a table and run each one as its own subtest, checking the errors properly along the way.",
+        "subtle_wrong": "Define a slice of `{name, order, want, wantErr}` structs covering the cases you need, then loop with `for _, tc := range cases { t.Run(tc.name, func(t *testing.T) { got, err := Validate(tc.order); if tc.wantErr { require.Error(t, err) } else { require.NoError(t, err); require.Equal(t, tc.want, got) } }) }`. That gives you named subtests without needing a case-per-function setup, and `wantErr: true`/`false` is enough to know whether validation caught the bad input."
+      },
+      "anti_patterns": ["wantErr: true"]
+    },
+    {
+      "id": "no-sleep-sync",
+      "prompt": "My Go test starts a goroutine and I want to wait for it to finish before asserting. What's the right way?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer waits for the goroutine to finish using an actual synchronization primitive -- a sync.WaitGroup (Add/Done/Wait) or a channel send/receive -- before running assertions, never a fixed time.Sleep delay as a stand-in for or supplement to a real join. A select against a deadline (time.After, context.WithTimeout) used purely as a non-blocking safety net alongside that join -- firing only if the goroutine hangs, never taken instead of or before the real join -- is a legitimate timeout guard, not the fixed-delay anti-pattern this scenario tests for.",
+          "pass_criteria": [
+            "Uses sync.WaitGroup (Add/Done/Wait) or a channel send/receive as the actual join mechanism before asserting, shown concretely (not just named in the abstract).",
+            "Explains why this is reliable/deterministic compared to a fixed delay (e.g. it doesn't depend on how fast the goroutine happens to run)."
+          ],
+          "fail_criteria": [
+            "Recommends a fixed, unconditional wait before the join can be observed to have happened -- a time.Sleep taken before or instead of the join, or an explicit backoff/polling loop that sleeps between checks -- anywhere in the wait step, whether as the sole mechanism or as extra 'insurance' alongside a real join. This does NOT include a select's time.After/context.WithTimeout branch used only as a deadline safety net around the real join (it fires solely on a hang, and the join itself is what the assertion still actually waits on) -- do not fail an answer for that pattern alone."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Use a `sync.WaitGroup`: call `wg.Add(1)` before you launch the goroutine, `defer wg.Done()` as the first line inside it, and `wg.Wait()` in the test right before your assertions -- that blocks until the goroutine has actually signaled completion, regardless of how fast or slow it happens to run on a given machine or under `-race`. If the goroutine is producing a value or signaling completion of one specific step rather than 'I'm done', a channel works just as well: send on it from the goroutine when it finishes, and receive (`<-done`) in the test before asserting. Either way, avoid `time.Sleep` for this -- a fixed delay is a guess about how long the goroutine will take, and it either wastes time when the goroutine finishes early or flakes under load/CI contention when it doesn't finish in time. If you also want a safety timeout, pair the channel receive with a `select` against a short deadline rather than sleeping first and then checking.",
+        "known_wrong": "The easiest way is to just add a short `time.Sleep(100 * time.Millisecond)` right after you start the goroutine, then run your assertions -- that gives it enough time to finish in almost every case without needing to wire up a WaitGroup or channel just for a test. If it's occasionally still flaky in CI, bump the sleep up to something like 500ms; that's usually enough headroom and is a lot less code than setting up synchronization for what's really a simple test.",
+        "vague": "Wait for the goroutine properly instead of just sleeping for a bit before you check the result.",
+        "subtle_wrong": "Use a `sync.WaitGroup`: `wg.Add(1)` before the goroutine, `wg.Done()` inside it, and `wg.Wait()` before asserting -- that's the reliable way to know it's finished. If you're still seeing occasional flakes in CI, throw in a short `time.Sleep(50 * time.Millisecond)` right after `wg.Wait()` too, just as extra insurance before the assertions run."
+      },
+      "anti_patterns": ["time.Sleep"]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/python/agent-refs.json

@@ -0,0 +1,3 @@
+{
+  "agents": ["python-code-auditor", "python-build-fixer"]
+}