go-tool-base

The underpinnings for any Go command-line tool, and (as a few of my projects now prove) for comprehensive web services too. It standardises the boilerplate and wiring you end up writing in every Go project, and puts config, logging, self-update, a DI container and the rest straight at your fingertips. Highly opinionated, and it makes some calls people will disagree with, but it works, and it works really well. The CLI it ships with is a big part of that: keeping a Go app built, updated and maintained becomes almost trivial.

Why a write-once boolean still needs a mutex: the Go memory model needs a happens-before edge before another goroutine is guaranteed to see it.

Reassigning a package-level function variable in tests is a latent data race that t.Parallel exposes. The fix is structural, not another lock.

Running OpenSSF Scorecard on a Go project flagged mutable action tags, over-broad workflow token permissions, and a missing maintenance signal.

You cannot test the model, but you can test your code: snapshot the prompt as a golden file and mock the response to cover the ugly cases.

Five AI providers behind one Go interface, including one that shells out to a locally authenticated CLI for networks that allow no API calls.

Persisting an AI conversation in Go: snapshot the messages, prompt and tool metadata, and deliberately never the handlers or the API token.

Generate-and-hope does not work for codegen. Handing the draft to a repair agent with a fixed toolset that has to make build, test and lint pass.

Stop parsing an LLM's prose with regular expressions. Derive a JSON schema from your Go or Rust type so the schema and the type cannot drift.

Opt-in telemetry for a command-line tool: off until someone says yes, no personal data, a pluggable backend, and a consent flow that meets GDPR.

Tool calling and the reason-act-observe loop explained, and how to define a tool in Go so the schema comes from the type rather than by hand.