@mrciphersmith/keryx 0.2.164 → 0.3.0

package/src/gdskills/bundled/stacks/go/governance/scout.json

@@ -0,0 +1,31 @@
+[
+  {
+    "query": "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.",
+    "decision": "create",
+    "topMatch": "python/python-implementation",
+    "recordedAt": "2026-09-24T12:08:06.318Z",
+    "skillName": "go-implementation"
+  },
+  {
+    "query": "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.",
+    "decision": "create",
+    "topMatch": "ts-js-node/nodejs-testing",
+    "recordedAt": "2026-09-24T12:08:08.013Z",
+    "skillName": "go-testing"
+  },
+  {
+    "query": "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.",
+    "decision": "create",
+    "topMatch": "ts-js-node/nodejs-code-review",
+    "recordedAt": "2026-09-24T12:08:09.683Z",
+    "skillName": "go-code-review"
+  },
+  {
+    "query": "Use when go build/go vet fails, or go.mod/go.sum are out of sync -- resolves module/toolchain mismatches, import cycles, generic type inference errors, staticcheck/golangci-lint failures, and a failing go test -race, with the smallest root-cause fix.",
+    "decision": "fork",
+    "topMatch": "ts-js-node/nodejs-build-fix",
+    "recordedAt": "2026-09-24T12:08:16.513Z",
+    "skillName": "go-build-fix",
+    "justification": "Nearest matches: ts-js-node/nodejs-build-fix (0.44) fixes tsc type errors, ESM/CJS module resolution, and eslint failures for Node/TS -- not Go's go vet/staticcheck/golangci-lint findings or go.mod/go.sum toolchain mismatches. python/python-build-fix (0.41) resolves pip/pyproject dependency and import errors for Python, not Go's import-cycle-via-internal/ restructuring or generic type-inference errors. react/react-build-fix (0.32) fixes JSX/TSX prop and bundler errors for React, unrelated to Go's compiler/toolchain surface. None share Go-specific vocabulary (go vet, staticcheck, golangci-lint, go.mod/go.sum, internal/) so this is a genuine fork, not a substitute."
+  }
+]

package/src/gdskills/bundled/stacks/go/pack.json

@@ -0,0 +1,41 @@
+{
+  "id": "go",
+  "family": "language",
+  "modules": ["go-rules", "go-skills"],
+  "detectionMarkers": ["go"],
+  "provenance": {
+    "origin": "authored",
+    "sourceRef": "flow 314, Wave 4 batch 1"
+  },
+  "stability": "stable",
+  "skills": {
+    "implement": ["go-implementation"],
+    "test": ["go-testing"],
+    "review": ["go-code-review"],
+    "build-fix": ["go-build-fix"],
+    "migrate": []
+  },
+  "agentProfile": {
+    "displayName": "Go",
+    "auditFocus": [
+      "an error return that is discarded or shadowed instead of checked or wrapped with %w",
+      "a goroutine started with no owned cancellation path (context, channel close, or WaitGroup) that can leak",
+      "a context.Context stored on a struct field, or a fresh context.Background()/TODO() created inside a request handler instead of threading the caller's ctx",
+      "concurrent map or slice access with no mutex/sync primitive guarding it",
+      "a defer inside a loop body that accumulates resources until the function returns",
+      "an exported type whose constructor returns an interface instead of the concrete struct, or an interface defined on the producer side instead of at the consumer"
+    ],
+    "buildCommands": [
+      "go build ./...",
+      "go vet ./...",
+      "go test -race ./...",
+      "golangci-lint run ./... (only when the project has a golangci-lint config)"
+    ],
+    "fixGuardrails": [
+      "Never silence a vet/lint finding with a blank `_ = err` or a `//nolint` comment instead of fixing the root cause.",
+      "Never change `go.mod`'s `go` directive or a dependency's major version just to make an error disappear; fix the code against the declared toolchain.",
+      "Never add a `replace` directive to route around a real compile error in a dependency without saying so in the report.",
+      "Never delete or skip a failing test to reach a green build."
+    ]
+  }
+}

package/src/gdskills/bundled/stacks/go/rules/coding-style.mdc

@@ -0,0 +1,85 @@
+---
+extends: common
+paths: ["**/*.go"]
+metadata:
+  origin: authored
+---
+
+# Go coding style
+
+Narrows `core-common-rules`' stack-agnostic style rules to modern Go
+(1.23-1.25) idiom. Applies only to `*.go` files — everything not
+Go-specific still comes from the common rules this file `extends`.
+
+## Naming and structure
+
+- Package names are short, lowercase, no underscores or `mixedCaps`
+  (`user`, not `user_service` or `userService`); do not stutter the package
+  name in exported identifiers (`user.User`, not `user.UserAccount`).
+- `MixedCaps`/`mixedCaps`, never `snake_case`, for identifiers — exported
+  starts with an uppercase letter, unexported with lowercase.
+- Keep `main` thin: business logic lives in packages under `internal/` (or
+  a library's own top-level packages), `cmd/<binary>/main.go` only wires
+  flags/config and calls into them.
+- An identifier's name shrinks with its scope: a loop index is `i`, a
+  package-level exported function gets a full descriptive name.
+
+## Interfaces and structs
+
+- Accept interfaces, return structs: a function parameter should be the
+  narrowest interface the callee needs; a constructor returns the concrete
+  `*Thing`, not an interface, so callers get the full method set and the
+  compiler catches a missing method at the definition site.
+- Define an interface at the consumer (the package that calls through it),
+  not the producer (the package that implements it) — `io.Reader`-sized:
+  one or two methods. A producer-side interface with only one
+  implementation is usually unnecessary indirection.
+- Prefer a zero-value-useful struct (`var b bytes.Buffer` works with no
+  constructor) over requiring `New()` when the zero value is meaningful.
+
+## Errors
+
+- Every returned `error` is checked or explicitly and visibly discarded
+  (`_ = f.Close() // best-effort`) — never silently dropped.
+- Wrap with context using `fmt.Errorf("doing x: %w", err)`, not `%v`, so
+  the original error survives for `errors.Is`/`errors.As` up the call
+  stack. Wrap once per meaningful layer, not at every call site.
+- Compare sentinel errors with `errors.Is`, and unwrap typed errors with
+  `errors.As` — never a string comparison (`err.Error() == "..."` ) or a
+  bare `==` against a wrapped error.
+- A package-level sentinel error is `var ErrNotFound = errors.New("...")`,
+  named `Err<Reason>`; a custom error type implements `Error() string` and,
+  when it wraps another error, `Unwrap() error`.
+
+## Concurrency and context
+
+- `context.Context` is always the first parameter, named `ctx`, and is
+  never stored on a struct field — thread it through call chains instead.
+- Every goroutine a function starts has an explicit owner that knows when
+  it exits: joined with `sync.WaitGroup` (or `WaitGroup.Go` on a toolchain
+  that has it), bounded by `errgroup.Group`, or cancelled through the
+  `ctx` it was given. A goroutine with no join point and no cancellation
+  path is a leak, not fire-and-forget.
+- Check `ctx.Err()` / respect `ctx.Done()` in any loop or blocking call
+  that should stop when the caller cancels.
+
+## Generics and modern idiom
+
+- Reach for a type parameter only when it removes real duplication (a
+  container, a generic algorithm over `constraints.Ordered`-like sets) —
+  do not generify a function with one concrete call site "for the future".
+- Use `log/slog` for structured logging in new code, not `log.Printf` or a
+  bespoke logger, unless the project has already standardized on
+  something else.
+- A `range-over-func` iterator (`func(yield func(T) bool)`) is fine for a
+  package's own lazy sequence API on Go 1.23+; do not introduce it purely
+  to look modern when a plain slice-returning function reads more clearly.
+
+## Formatting and imports
+
+- Format with `gofmt`/`goimports` before finishing a change; do not
+  hand-format around a formatter that is already configured (CI enforces
+  `gofmt -l` in most Go repos).
+- Group imports stdlib / third-party / local with a blank line between
+  groups — `goimports` does this automatically; run it instead of
+  hand-ordering.

package/src/gdskills/bundled/stacks/go/rules/patterns.mdc

@@ -0,0 +1,65 @@
+---
+extends: common
+paths: ["**/*.go"]
+metadata:
+  origin: authored
+---
+
+# Go patterns
+
+Narrows `core-common-rules`' stack-agnostic design guidance to idiomatic
+Go design and its common anti-patterns. Applies only to `*.go` files.
+
+## Module and package layout
+
+- `cmd/<binary>/` holds one `main` package per executable; `internal/`
+  holds packages this module's own code may import but nothing outside
+  the module can — put anything not meant as a public API surface there.
+- A package should have a clear, single responsibility; a package that
+  only holds shared types with no behavior ("models", "types", "common")
+  invites import cycles as the project grows — prefer colocating a type
+  with the package that owns its behavior.
+- Avoid import cycles by depth, not by breaking them with an `internal`
+  workaround package — if package A needs package B's type and B needs
+  A's, one of the two owns too much; extract the shared piece into a
+  third package both depend on.
+
+## Idiomatic concurrency patterns
+
+- Fan-out/fan-in: bound the number of concurrent workers (a worker pool or
+  `golang.org/x/sync/errgroup`'s `SetLimit`), never spawn one goroutine per
+  input item on an unbounded input source.
+- Use `errgroup.Group` when a set of goroutines shares one cancellation
+  and you need the first error; use a plain `sync.WaitGroup` when you only
+  need to know they finished and errors are handled another way.
+- Prefer channels for signaling and handoff, mutexes for protecting shared
+  state — do not build a hand-rolled semaphore out of a channel when
+  `sync.Mutex` (or `errgroup.SetLimit`) already says what you mean.
+- Close a channel only from the sender, never the receiver, and only
+  once; a `nil` channel blocks forever on send/receive, which is
+  occasionally the correct way to disable a `select` case.
+
+## Composition over inheritance
+
+- Use struct embedding to reuse behavior only when the embedding type
+  genuinely "is-a" superset of the embedded one's API; prefer an explicit
+  field plus delegation when you would otherwise promote methods the
+  caller should not see.
+- Functional options (`func WithTimeout(d time.Duration) Option`) for a
+  constructor with many optional parameters, instead of a boolean-heavy
+  positional signature or a half-filled config struct.
+
+## Anti-patterns to flag
+
+- A large `interface{}`/`any`-typed function signature where a generic
+  type parameter or a smaller concrete interface would give compile-time
+  safety back.
+- A "god package" (`utils`, `helpers`, `common`) that accumulates
+  unrelated functions — split by what the code actually does.
+- Returning a pointer to a struct solely to allow a `nil` "not found"
+  value where a `(T, bool)` or a named error (`ErrNotFound`) return is
+  clearer and avoids nil-pointer-dereference risk at the call site.
+- Panic used for ordinary control flow (a missing map key, a failed
+  lookup); reserve `panic` for programmer errors that should crash during
+  development (a violated invariant, an unreachable `default` case), and
+  return an `error` for everything a caller could reasonably handle.

package/src/gdskills/bundled/stacks/go/rules/security.mdc

@@ -0,0 +1,73 @@
+---
+extends: common
+paths: ["**/*.go"]
+metadata:
+  origin: authored
+---
+
+# Go security
+
+Narrows `core-common-rules`' stack-agnostic security rules to Go-specific,
+OWASP-relevant risks and the safe standard-library API to use instead.
+Applies only to `*.go` files.
+
+## Command and shell execution
+
+- Build an argument list for `os/exec.Command(name, args...)`; never
+  interpolate untrusted input into a shell string passed to
+  `exec.Command("sh", "-c", cmd)` — that reintroduces shell injection that
+  `exec.Command`'s arg-list form avoids by construction.
+- When a shell really is required (globbing, pipelines), validate/allowlist
+  every piece of untrusted input that reaches the string before it is
+  built, and say so in the change.
+
+## Templating and output encoding
+
+- Use `html/template` for any output rendered into HTML/JS/CSS/URL
+  context — it contextually auto-escapes. `text/template` performs no
+  escaping and is an XSS vector the moment its output reaches a browser;
+  reserve `text/template` for genuinely non-HTML output (config files,
+  emails in plain text).
+
+## SQL and data access
+
+- Use `database/sql` placeholders (`?` or `$1` depending on driver), never
+  `fmt.Sprintf`/string concatenation to build a query with any
+  user-influenced value — placeholders are the injection defense, not an
+  input-validation substitute for it.
+- An ORM/query builder's raw-SQL escape hatch carries the same rule: pass
+  parameters through its placeholder API, not through interpolated
+  strings.
+
+## Randomness and secrets
+
+- Use `crypto/rand` for anything security-sensitive — tokens, session
+  IDs, keys, nonces. `math/rand`/`math/rand/v2` is deterministic given a
+  seed and unsuitable for secrets even though its API looks similar.
+- Never hard-code a credential, API key, or signing secret in source;
+  load it from environment/secret storage the project already uses.
+
+## Filesystem and path handling
+
+- `filepath.Clean` normalizes a path but does not contain it — a cleaned
+  path can still climb outside an intended root via `..` before cleaning,
+  or via a symlink. For serving/opening files under a fixed root from an
+  untrusted relative path, prefer `os.Root` (Go 1.24+) or
+  `filepath.IsLocal` to confirm containment before opening, rather than
+  `filepath.Clean` alone.
+
+## TLS and network
+
+- Never set `InsecureSkipVerify: true` on a `tls.Config` outside of a
+  short-lived local test, and never ship it that way — it disables
+  certificate validation entirely, including hostname checks.
+- Configure `http.Server` with explicit `ReadHeaderTimeout` (and
+  typically `ReadTimeout`/`WriteTimeout`/`IdleTimeout`); a server with no
+  timeouts is vulnerable to slow-client resource exhaustion (Slowloris).
+
+## Dependency hygiene
+
+- Run `govulncheck ./...` when introducing or updating dependencies, or
+  when asked to check a module for known vulnerabilities — it correlates
+  the Go vulnerability database against actually-reachable code paths,
+  not just declared dependency versions.

package/src/gdskills/bundled/stacks/go/rules/testing.mdc

@@ -0,0 +1,68 @@
+---
+extends: common
+paths: ["**/*.go"]
+metadata:
+  origin: authored
+---
+
+# Go testing
+
+Narrows `core-common-rules`' stack-agnostic testing rules to the standard
+`testing` package and its modern (1.23-1.25) additions. Applies only to
+`*.go` files.
+
+## Layout and naming
+
+- Tests live beside the code they cover as `<file>_test.go` in the same
+  package (or `<pkg>_test` for a black-box test that only exercises the
+  exported API) — no separate `tests/` tree.
+- Table-driven tests with `t.Run(tc.name, func(t *testing.T) { ... })`
+  subtests are the default shape for anything with more than one case;
+  name each case descriptively, not `case1`/`case2`.
+- `testdata/` holds golden files and fixtures a test reads; Go's tooling
+  already excludes it from builds — do not invent another fixture
+  directory convention.
+
+## Test helpers and lifecycle
+
+- Mark a helper function `t.Helper()` as its first line so failures report
+  the caller's line, not the helper's.
+- Use `t.Cleanup(func() { ... })` for teardown instead of a manual
+  `defer` chain scattered across a subtest — it composes correctly with
+  `t.Run` and parallel subtests.
+- Use `t.Context()` (Go 1.24+) for a context that is canceled when the
+  test completes, instead of hand-rolling `context.WithCancel` plus a
+  `defer cancel()` in every test.
+- Call `t.Parallel()` deliberately, only when the subtest's fixtures are
+  genuinely independent — a parallel subtest sharing mutable fixture
+  state races silently.
+
+## Assertions and determinism
+
+- Plain `if got != want { t.Errorf(...) }` (or the project's already-
+  configured assertion library) — do not introduce a new assertion
+  library into a project that has not adopted one.
+- Never synchronize with `time.Sleep` to wait for a goroutine/async result
+  — use a channel, `sync.WaitGroup`, `context` deadline, or a polling
+  helper with a timeout so the test is deterministic and not flaky under
+  load.
+- `httptest.NewServer`/`httptest.NewRecorder` for HTTP handler tests
+  instead of binding a real port.
+
+## Fuzzing and benchmarks
+
+- `func FuzzX(f *testing.F)` with `f.Add(...)` seed corpus entries for
+  parsers, decoders, or anything that touches untrusted input formats;
+  run locally with `go test -fuzz=FuzzX` before relying on it in CI.
+- Benchmarks use `for b.Loop() { ... }` (Go 1.24+) rather than the older
+  `for i := 0; i < b.N; i++`; `b.Loop()` resets the timer automatically
+  and keeps loop-body values alive against dead-code elimination, so
+  results are not accidentally optimized away.
+
+## Race detection and coverage
+
+- Run `go test -race ./...` for any change touching goroutines, shared
+  state, or channels — the race detector catches data races unit
+  assertions cannot see.
+- New behavior gets a new test in the same change; a bug fix gets a
+  regression test that fails before the fix and passes after.

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

@@ -0,0 +1,138 @@
+---
+name: go-build-fix
+description: "Use when go build/go vet fails, or go.mod/go.sum are out of sync -- resolves module/toolchain mismatches, import cycles, generic type inference errors, staticcheck/golangci-lint failures, and a failing go test -race, with the smallest root-cause fix."
+triggers:
+  - "go build is failing"
+  - "fix go.mod go.sum mismatch"
+  - "resolve this import cycle in Go"
+  - "go vet error"
+  - "golangci-lint is failing"
+  - "go test -race is failing"
+metadata:
+  origin: authored
+  category: build-fix
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Go build fix
+
+Resolve a `go build`/`go vet` failure, a `go.mod`/`go.sum` mismatch, an
+import cycle, a generic type-inference error, a `staticcheck`/
+`golangci-lint` failure, or a failing `go test -race` — with the smallest
+change that fixes the actual root cause. `rules/coding-style.mdc` and
+`rules/security.mdc` govern what a "correct" fix looks like; this skill
+never reaches for a suppression instead of a fix.
+
+## Workflow
+
+### Step 1: Reproduce and classify
+
+```bash
+go build ./...
+go vet ./...
+```
+
+Run the project's configured linter if present (`golangci-lint run
+./...`, checked via a `.golangci.yml`/`.golangci.toml`). Read the exact
+error text and classify it:
+
+- **Compile error** (undefined symbol, type mismatch, wrong arg count).
+- **Module/toolchain** (`go.mod`/`go.sum` mismatch, missing `go mod
+  tidy`, a `replace` directive pointing somewhere stale, a `go` /
+  `toolchain` directive older than a feature the code uses).
+- **Import cycle** (`import cycle not allowed`).
+- **Generic inference** (`cannot infer T`, a type parameter that cannot
+  be resolved from the call site).
+- **Vet/lint finding** (`go vet`'s own checks, or a `staticcheck`/
+  `golangci-lint` rule).
+- **Race** (`go test -race` reports a `DATA RACE`).
+
+### Step 2: Fix by category
+
+**Module/toolchain:** run `go mod tidy` when `go.sum` is simply stale
+against `go.mod`'s requirements. For a genuine version conflict, check
+`go mod why -m <module>` and `go mod graph` before bumping a version by
+hand. Only add/edit a `replace` directive when it points at a real,
+intentional local override (a monorepo sibling, a patched fork) — never
+to paper over a version conflict without understanding it, and say so in
+the report either way.
+
+**Import cycle:** find the shared type/function both packages need and
+extract it into a third package both can depend on, or invert one
+dependency by defining the needed interface at the consumer (per
+`rules/patterns.mdc`) instead of importing the concrete producer package.
+Do not "fix" a cycle by merging the two packages into one unless they
+were genuinely one responsibility already.
+
+**Generic inference failure:** check whether the call site can supply the
+type argument explicitly (`Func[T](...)`) before restructuring the
+generic signature; if inference is failing because the type parameter
+does not actually vary at the call sites, consider whether generics are
+buying anything here at all.
+
+**Vet/lint finding:** fix the underlying issue the finding names (e.g. a
+real `printf`-format mismatch, an unreachable branch, an unused
+`context.Context` parameter meant to be used). Never add `//nolint` or a
+`_ = ` discard whose only purpose is to make the checker stop complaining
+without addressing what it found.
+
+**Race:** read the reported access pair (`go test -race`'s output names
+both goroutines and lines). Add the missing synchronization (mutex,
+channel handoff, `sync/atomic`) at the actual shared-state access point —
+do not just serialize the whole test or add a `time.Sleep` to hide the
+timing window.
+
+### Step 3: Verify
+
+```bash
+go build ./...
+go vet ./...
+go test -race ./...
+```
+
+Re-run the project's linter if it was part of the original failure. All
+must exit 0 before reporting done.
+
+### Step 4: Report
+
+```
+Fixed: go.mod/go.sum toolchain mismatch (ran `go mod tidy`)
+  - Root cause: go.sum predated a dependency bump in go.mod
+  - go build/vet/test -race all pass
+```
+
+State the root cause in one sentence, not just "fixed the error."
+
+## Rules
+
+- Find and fix the smallest change that addresses the actual root cause —
+  never widen a fix beyond what the failure requires.
+- NEVER add `//nolint` or a blank `_ =` discard to silence a vet/lint
+  finding instead of fixing what it found.
+- NEVER change the `go` directive or a major dependency version just to
+  make an error disappear without understanding why it changed.
+- NEVER add a `replace` directive to route around a real compile error
+  without confirming it is an intentional, documented override.
+- NEVER delete or skip a failing test to reach a green build.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll add `//nolint:errcheck` here so the linter stops complaining" | Silences the finding without fixing the ignored error it caught; check the error instead |
+| "Bumping the go directive to 1.25 makes this compile" | Changes the module's declared minimum toolchain for every consumer to dodge one error; understand why the code needs 1.25 first, or fix the code to work at the declared version |
+| "This test is flaky under -race, I'll just run it without -race in CI" | Hides a real data race instead of fixing the missing synchronization; add the mutex/channel instead |
+| "I'll merge these two packages to kill the import cycle" | A cycle usually means a shared piece belongs in a third package, not that the two packages were never separate — check the actual dependency shape first |
+
+## Verification
+
+Do not report the fix done until all of the following hold:
+
+- `go build ./...`, `go vet ./...`, and `go test -race ./...` all exit 0.
+- The project's linter (if configured) exits 0.
+- The change is the smallest one that addresses the stated root cause —
+  no unrelated files touched.
+- The report states the root cause in one sentence, not just "build now
+  passes."

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

@@ -0,0 +1,75 @@
+{
+  "triggers": {
+    "positive": [
+      "go build is failing with an undefined symbol error",
+      "go.mod and go.sum are out of sync, please fix",
+      "Resolve this Go import cycle between two internal packages",
+      "go vet is reporting a printf format error",
+      "golangci-lint is failing on this Go package",
+      "go test -race is failing with a data race, fix the build"
+    ],
+    "negative": [
+      "npm install is failing with a peer dependency conflict",
+      "cargo build is failing for this Rust crate",
+      "pip install is failing for this Python project",
+      "Implement a new Go feature in the order package",
+      "Review this Go diff for concurrency bugs",
+      "Write Go tests for this function"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "module-mismatch",
+      "prompt": "go build fails saying go.sum is out of date after I bumped a dependency in go.mod. How do I fix it?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies that go.sum is stale relative to go.mod's requirements after the dependency bump and fixes it by running `go mod tidy`. For a genuine version conflict it checks `go mod why`/`go mod graph` before bumping a version by hand, rather than routing around the error some other way.",
+          "pass_criteria": [
+            "Names `go mod tidy`, run from the module root, as the concrete command that resolves the stale go.sum -- not merely 'sync the files' or 'run the tool that fixes this'.",
+            "States the root cause: go.sum no longer matches what go.mod now requires after the version bump, not just 'run this command' with no explanation.",
+            "Either names a concrete verification step afterward (`go build ./...` and/or `go test ./...`) or does not suggest skipping verification."
+          ],
+          "fail_criteria": [
+            "Recommends changing the `go` directive (the module's minimum toolchain version) to make the error go away, or bumping another dependency's version by hand, as a substitute for running `go mod tidy`.",
+            "Recommends hand-editing the hash lines in go.sum directly instead of regenerating it with `go mod tidy`."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "This means go.sum no longer matches what go.mod now requires after you bumped the dependency version. The fix is to run `go mod tidy` from the module root -- it recomputes go.sum against go.mod's require block, adding the new entries and dropping stale ones, and will also flag if the bump pulled in a transitive dependency that needs its own version resolved. If `go mod tidy` itself reports a version conflict (rather than a simple stale-sum error), don't just bump another module by hand -- run `go mod why -m <module>` and `go mod graph` first to see what's actually pulling in the conflicting version, so you understand the change before you make it. After `go mod tidy` finishes, re-run `go build ./...` and `go test ./...` to confirm the module is consistent again before considering this done. Avoid hand-editing the hashes in go.sum directly; that file is generated and meant to be regenerated by tooling, not patched by hand.",
+        "known_wrong": "Honestly the fastest fix here is to bump the go directive in go.mod to a newer toolchain version -- that usually makes go.sum errors like this go away without you needing to figure out what `go mod tidy` would even change. Just edit the `go 1.21` line to `go 1.25` and re-run the build; if it still complains, bump the specific dependency version in go.mod up a bit further too until the error clears. You don't really need to run `go mod why` or dig into the dependency graph for a simple sum mismatch like this -- that's overkill for what's usually just a version string being out of date.",
+        "vague": "This is just a dependency sync issue -- make sure your module files are consistent with each other again and the build should pass.",
+        "subtle_wrong": "Bump the dependency's version in go.mod directly to match what your code now needs, then try `go build` again -- if go.sum still complains about a missing sum for that version, add the missing hash lines to go.sum by hand so the two files line up. That gets you to a green build without having to run the whole module through `go mod tidy` and re-resolve everything else it might touch."
+      }
+    },
+    {
+      "id": "no-nolint-suppression",
+      "prompt": "golangci-lint is flagging an ignored error return in my Go code. How should I fix it?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer fixes the actual ignored error return -- checks it, wraps it with %w and returns/propagates it, or explicitly discards it with a comment explaining why -- instead of suppressing the linter finding with `//nolint` or a blank `_ =` discard, and instead of merely logging it without propagation.",
+          "pass_criteria": [
+            "Checks the error explicitly with an `if err != nil` branch (or equivalent) rather than leaving it dropped.",
+            "Shows the concrete fix: wraps and returns the error to the caller (e.g. `return fmt.Errorf(\"...: %w\", err)`), or explicitly discards it with a comment naming why that specific discard is safe -- not merely a statement that the error 'should be handled'. The prompt itself names no call site or code, so a concrete illustrative example in either shape (a wrap-and-return snippet, or a `_ = ... // reason` discard snippet) satisfies this requirement; it does not require identifying an 'actual flagged call site' the prompt never supplied.",
+            "Does not rely on `//nolint` or a bare `_ =` discard as the fix for the flagged finding."
+          ],
+          "fail_criteria": [
+            "Recommends adding a `//nolint` comment (e.g. `//nolint:errcheck`) to silence the finding instead of handling the error.",
+            "Handles the error only by logging it (e.g. `log.Printf(...)` or `log.Println(...)`) with no return, no wrap, and no propagation to the caller, and no comment justifying why logging alone is a safe discard."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "golangci-lint's errcheck is telling you the returned error from that call is never examined, which usually means a real failure could pass through silently. Add an explicit `if err != nil { ... }` branch: if the error matters to the caller, wrap it with `fmt.Errorf(\"doing x: %w\", err)` and return it so callers can unwrap it with `errors.Is`/`errors.As`; if it genuinely doesn't matter (a best-effort `Close()`, for instance), discard it explicitly with a comment naming why, like `_ = f.Close() // best-effort cleanup, nothing to recover`. Don't reach for `//nolint:errcheck` here -- that just tells the linter to stop looking, it doesn't address whether the error mattered. Once you've handled it one way or the other, re-run golangci-lint to confirm the finding is actually resolved rather than merely hidden.",
+        "known_wrong": "The simplest fix is to just add `//nolint:errcheck` on the line above the call -- that error genuinely doesn't matter here, and it stops golangci-lint from flagging it every time CI runs. You don't need to touch the actual logic or add an if-check; the nolint directive is exactly what it's for. If the linter later flags something similar nearby, you can add the same `//nolint:errcheck` comment there too rather than working through each ignored error individually.",
+        "vague": "You should handle that error properly instead of suppressing the finding -- make sure it's actually checked and dealt with before you call this done.",
+        "subtle_wrong": "That errcheck finding is easy to clear without touching the surrounding logic: wrap the call in `if err != nil { log.Printf(\"unexpected error: %v\", err) }` so it shows up in the logs if it ever happens, and move on. That way you're not silently dropping it anymore, and you don't have to change the function's return signature or work out how the caller should react to it."
+      },
+      "anti_patterns": ["nolint"]
+    }
+  ]
+}