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.

An agent is a model in a loop with tools it can really call and results it can really see. Taking the ReAct pattern apart in go-tool-base.

If the platform hosting your code also hands out the key that verifies it, the signature proves nothing. Where to publish a public key instead.

Where a signing key lives is the most provider-specific decision in the whole business, so the framework deliberately refuses to have an opinion.

Wiring OTel-native observability through a gRPC service with a REST gateway, and discovering the gateway had split a single trace into two.

A gpg call that hung and never returned, and why release signing ended up built into the Go tool itself rather than shelled out to the gpg binary.

Choosing a CLI library in Go and Rust. Go is a ladder you climb from the standard library; Rust asks a different question much earlier.

Running three different coding agents against one repository, and the house rules that stopped them undoing each other's work.

A secret scanner failed a merge request over a test key and a documentation PEM that the change did not contain. Scoping a scan properly.

Building on your own framework means finding its gaps as a user rather than an author, and having to file the request against yourself.

A tool-failure log dumped a wall of Go stack frames where one line would have done. What a log record owes the person reading it.