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.

Documentation loses to --help on location, so embed the docs in the binary: a terminal browser and an assistant grounded only in your own pages.

BDD earns its place on narratives such as a lifecycle state machine, and nowhere else. Keep table-driven Go tests as the baseline everywhere.

You do not need LangChain in a command-line tool. A four-method chat interface can hide five providers, tool calling and structured output.

Config loaders ignore keys they do not recognise, so a typo runs on the old value. Deriving a validation schema from struct tags to catch it.

Go allows only one trailing variadic parameter, so adding another argument to a function that already has one is impossible. What to do instead.

The other audience for a CLI is the script that greps its output and breaks. Giving every command a JSON output mode with one response envelope.

When a Go CLI grows into a service: ordered graceful shutdown on SIGTERM, separate liveness and readiness probes, and an opt-in restart supervisor.

Timing, auth, recovery and logging are cross-cutting in a CLI too. Wrapping Cobra commands in web-style middleware rather than PreRun hooks.

One tool, three logging backends: colour for a terminal, JSON for a container, silence for tests. Depend on the interface, choose the backend once.

Recovery advice belongs in a structured error hint, not buried in the message string. One error handler then decides how to show it.