Many embedded filesystems, one merged view
Go embed.FS is per-package, so a modular CLI ends up with islands. Merging them into one filesystem, and deep-merging YAML and JSON across them.
Categories
76 pages
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.
Props: the container that does the heavy lifting
Passing dependencies to Go commands in a typed struct rather than stuffing them in context.Context, so the compiler checks them and tests stay simple.
Design your whole CLI in one file
go-tool-base keeps an entire CLI command tree in one manifest file and generates the wiring from it, without locking you out of hand-written Go.
Scaffolding that respects your edits
How a Go scaffolder can re-run safely: hash every generated file, overwrite what is untouched, and prompt before it stands on your edits.
Your CLI is already an AI tool
A well-built CLI already has what an agent needs: named operations, descriptions and typed parameters. Exposing one over MCP takes no AI code.
go-tool-base: I got tired of reinventing the wheel
How a pile of separate Go CLI plumbing packages became one library, with a typed container for dependencies and a generator on top.
