go-clilisted

# Go CLI Development Patterns for building reliable Go CLI tools that interact with external processes (tmux, git, docker, etc.). Distilled from production experience. --- ## Quality Gate: `make check` Every Go CLI project MUST have a `make check` target. This is the single command that must pass before shipping. ```makefile check: fmt vet lint test ``` Where: - `fmt` — `gofmt -w . && goimports -w .` - `vet` — `go vet ./...` - `lint` — `golangci-lint run ./...` - `test` — `go test ./... -v` (all tests including integration) Also provide `test-short` for fast feedback: `go test ./... -v -short` (skips integration tests). **Rule:** If `make check` doesn't pass, don't commit. This means lint must pass — `golangci-lint` errors (including `errcheck` on unchecked error returns) are not warnings, they are build failures. Fix them before moving on. Lint passing is part of the TDD loop: write test → make it pass → make lint pass → refactor. --- ## Testing Strategy: Two-Layer Model Unit tests alone are insufficient for Go CLI tools that interact with external processes. The bugs that escape unit tests live at the seam between argument parsing and execution — where environmental behavior (tmux prefix matching, flag parsing order) determines correctness. ### Layer 1: Unit Tests (pure logic, `-short` mode) Test all logic that doesn't require external processes: - **Argument parsing**: Export `parseFooArgs()` functions and test them directly - **Config serialization**: `WriteC