write-go-kitlisted

# Go — a-novel-kit shared libraries This skill governs Go in the `a-novel-kit` organization: the shared-library repos checked out under `kit/` (`golib`, `jwt`, and any future graduate). These are **not** services — there is no `dao`/`services`/`handlers` layering here. Load `write-go` (the base Go conventions) and `write-go-tests` (and `document-code` when documenting) **alongside** this skill. For a-novel backend services use `write-go-service` instead. **Before touching anything**, read the repo's existing code and its README/CONTRIBUTING — kit repos are small, cohesive, and consistent; copy the established pattern. When the change is needed to support a service (or vice versa), load **`manage-versions`** as well: kit changes and the service changes that consume them must be released in the right order. --- ## Why kit exists, and the standing tension Shared libraries exist so services can be written **faster, with more focus** — by removing boilerplate and duplicated glue, not by adding capability. Every line that lands in a kit repo is maintained _forever_ as a community-facing package. So the bar for adding is high, and the default for "should this go in kit?" is **no** until proven otherwise. There are two kinds of kit repo: - **`golib`** — the _tote_ package: a single module (`github.com/a-novel-kit/golib`) whose sub-packages each collect the boilerplate for one concern (`config`, `otel`, `httpf`, `grpcf`, `logging`, `postgres`, `smtp`). Glue lives here until