golang-clilisted

# Go CLI Engineering Build a predictable interface for both people and automation. Preserve the project's existing command framework and conventions unless the user asks to change them. ## Start with the current contract Before editing: 1. Read `go.mod`, command entry points, existing command and configuration packages, tests, release scripts, completion/docs generation, and user-facing docs. 2. Identify supported platforms, installation channels, whether output is consumed by scripts, and compatibility promises for flags, exit codes, version output, and output formats. 3. Separate the command layer from domain work. Commands should parse input, call testable application logic, render results, and map failures at one outer boundary. 4. Treat renaming a flag, changing a default, moving output between streams, or changing JSON fields as an API change. Do not add a CLI or configuration dependency merely to follow a preferred pattern. The standard library flag package is often enough for a small, flat command. A framework can be justified by an existing codebase or requirements such as nested commands, completion, shared flags, and extensive help generation. When implementing the boundary, read [command recipes](references/command-recipes.md) for testable standard-library and Cobra shapes, explicit flag/config precedence, signal ownership, and separate output capture. Use only the branch matching the existing project. ## Design the command surface - Make command and flag