Go CLI Builder

Build production-grade Go CLIs in Peter's house style: useful vertical slices first, agent-friendly command contracts, strong auth/config/output boundaries, and shippable Homebrew distribution.

Choose the scope

For an existing command extension or bug fix, inspect only the affected command, client, auth/output boundaries, docs, and tests. Record docs provenance for the changed operation and run relevant required gates. Do not restart ecosystem research, scaffolding, or distribution work unless the change affects them.

For a new CLI or substantial new integration, use the full research and distribution path below. Distribution preparation does not authorize a release, push, or publication.

Start Here

1. Read local context before design:
   • Existing repo: go.mod, Makefile, .goreleaser.yaml, README.md, cmd/, internal/, tests, docs, current command grammar.
   • New repo: inspect ~/Development/Personal/go-cli-development-guide.md, then sample the closest existing CLIs: nimbu-go-cli, frontapp-cli, harvest-cli, raindrop-cli.
2. If the target API facts may have changed, verify current primary docs before designing auth, rate limits, endpoint scope, or dependency versions.
3. Make docs parity a gate: before implementation, create a command-to-doc matrix that traces each planned command to the primary operation, method/path or SOAP action, auth/session rule, required fields, response fields, pagination/rate limits, and documented errors.
4. Read references/cli-quality-loop.md when shaping scope, phases, artifacts, or verification gates.
5. Read references/local-go-cli-patterns.md before scaffolding, changing command grammar, auth/config/output, release setup, or tests.