golang-cli

Building a command-line tool in Go that behaves the way a terminal expects: settings that can come from a flag, a file or the environment, the right exit code on failure, and a clean stop on Ctrl-C.

WHEN TO USE

SCOPE

USE FOR

Structure a new Go CLI with Cobra commands, subcommands, and layered Viper configuration.
Bind flags to environment variables and a config file so precedence stays predictable.
Map internal errors to the correct Unix exit code instead of a bare crash.
Handle SIGINT and SIGTERM gracefully with signal.NotifyContext during shutdown.
Generate shell completions for bash, zsh, fish, and PowerShell.
Test CLI commands by capturing their output instead of hitting a real terminal.

NOT FOR

Not for Cobra-specific API details covered by the dedicated Cobra skill.
Not for Viper configuration-layering internals covered by the dedicated Viper skill.

This is a saved copy of the skill's SKILL.md instructions. It may differ from the upstream file or the version you install.

In this document (16)

Persona: You are a Go CLI engineer. You build tools that feel native to the Unix shell — composable, scriptable, and predictable under automation.

Modes:

Build — creating a new CLI from scratch: follow the project structure, root command setup, flag binding, and version embedding sections sequentially.
Extend — adding subcommands, flags, or completions to an existing CLI: read the current command tree first, then apply changes consistent with the existing structure.
Review — auditing an existing CLI for correctness: check the Common Mistakes table, verify SilenceUsage/SilenceErrors, flag-to-Viper binding, exit codes, and stdout/stderr discipline.

Go CLI Best Practices

Use Cobra + Viper as the default stack for Go CLI applications. Cobra provides the command/subcommand/flag structure and Viper handles configuration from files, environment variables, and flags with automatic layering. This combination powers kubectl, docker, gh, hugo, and most production Go CLIs.

When using Cobra or Viper, refer to the library's official documentation and code examples for current API signatures.

For trivial single-purpose tools with no subcommands and few flags, stdlib flag is sufficient.

Quick Reference

Concern	Package / Tool
Commands & flags	`github.com/spf13/cobra`
Configuration	`github.com/spf13/viper`
Flag parsing	`github.com/spf13/pflag` (via Cobra)
Colored output	`github.com/fatih/color`
Table output	`github.com/olekukonko/tablewriter`
Interactive prompts	`github.com/charmbracelet/bubbletea`
Version injection	`go build -ldflags`
Distribution	`goreleaser`

Project Structure

Organize CLI commands in cmd/myapp/ with one file per command. Keep main.go minimal — it only calls Execute().

myapp/
├── cmd/
│   └── myapp/
│       ├── main.go              # package main, only calls Execute()
│       ├── root.go              # Root command + Viper init
│       ├── serve.go             # "serve" subcommand
│       ├── migrate.go           # "migrate" subcommand
│       └── version.go           # "version" subcommand
├── go.mod
└── go.sum

main.go should be minimal — see assets/examples/main.go.

Root Command Setup

The root command initializes Viper configuration and sets up global behavior via PersistentPreRunE. See assets/examples/root.go.

Key points:

SilenceUsage: true MUST be set — prevents printing the full usage text on every error
SilenceErrors: true MUST be set — lets you control error output format yourself
PersistentPreRunE runs before every subcommand, so config is always initialized
Logs go to stderr, output goes to stdout

Subcommands

Add subcommands by creating separate files in cmd/myapp/ and registering them in init(). See assets/examples/serve.go for a complete subcommand example including command groups.

Flags

See assets/examples/flags.go for all flag patterns:

Persistent vs Local

Persistent flags are inherited by all subcommands (e.g., --config)
Local flags only apply to the command they're defined on (e.g., --port)

Required Flags

Use MarkFlagRequired, MarkFlagsMutuallyExclusive, and MarkFlagsOneRequired for flag constraints.

Flag Validation with RegisterFlagCompletionFunc

Provide completion suggestions for flag values.

Always Bind Flags to Viper

This ensures viper.GetInt("port") returns the flag value, env var MYAPP_PORT, or config file value — whichever has highest precedence.

Argument Validation

Cobra provides built-in validators for positional arguments. See assets/examples/args.go for both built-in and custom validation examples.

Validator	Description
`cobra.NoArgs`	Fails if any args provided
`cobra.ExactArgs(n)`	Requires exactly n args
`cobra.MinimumNArgs(n)`	Requires at least n args
`cobra.MaximumNArgs(n)`	Allows at most n args
`cobra.RangeArgs(min, max)`	Requires between min and max
`cobra.ExactValidArgs(n)`	Exactly n args, must be in ValidArgs

Configuration with Viper

Viper resolves configuration values in this order (highest to lowest precedence):

CLI flags (explicit user input)
Environment variables (deployment config)
Config file (persistent settings)
Defaults (set in code)

See assets/examples/config.go for complete Viper integration including struct unmarshaling and config file watching.

Example Config File (.myapp.yaml)

port: 8080
host: localhost
log-level: info
database:
  dsn: postgres://localhost:5432/myapp
  max-conn: 25

With the setup above, these are all equivalent:

Flag: --port 9090
Env var: MYAPP_PORT=9090
Config file: port: 9090

Version and Build Info

Version SHOULD be embedded at compile time using ldflags. See assets/examples/version.go for the version command and build instructions.

Exit Codes

Exit codes MUST follow Unix conventions:

Code	Meaning	When to Use
0	Success	Operation completed normally
1	General error	Runtime failure
2	Usage error	Invalid flags or arguments
64-78	BSD sysexits	Specific error categories
126	Cannot execute	Permission denied
127	Command not found	Missing dependency
128+N	Signal N	Terminated by signal (e.g., 130 = SIGINT)

See assets/examples/exit_codes.go for a pattern mapping errors to exit codes.

I/O Patterns

See assets/examples/output.go for all I/O patterns:

stdout vs stderr: NEVER write diagnostic output to stdout — stdout is for program output (pipeable), stderr for logs/errors/diagnostics
Detecting pipe vs terminal: check os.ModeCharDevice on stdout
Machine-readable output: support --output flag for table/json/plain formats
Colors: use fatih/color which auto-disables when output is not a terminal

Signal Handling

Signal handling MUST use signal.NotifyContext to propagate cancellation through context. See assets/examples/signal.go for graceful HTTP server shutdown.

Shell Completions

Cobra generates completions for bash, zsh, fish, and PowerShell automatically. See assets/examples/completion.go for both the completion command and custom flag/argument completions.

Testing CLI Commands

Test commands by executing them programmatically and capturing output. See assets/examples/cli_test.go.

Use cmd.OutOrStdout() and cmd.ErrOrStderr() in commands (instead of os.Stdout / os.Stderr) so output can be captured in tests.

Common Mistakes

Mistake	Fix
Writing to `os.Stdout` directly	Tests can't capture output. Use `cmd.OutOrStdout()` which tests can redirect to a buffer
Calling `os.Exit()` inside `RunE`	Cobra's error handling, deferred functions, and cleanup code never run. Return an error, let `main()` decide
Not binding flags to Viper	Flags won't be configurable via env/config. Call `viper.BindPFlag` for every configurable flag
Missing `viper.SetEnvPrefix`	`PORT` collides with other tools. Use a prefix (`MYAPP_PORT`) to namespace env vars
Logging to stdout	Unix pipes chain stdout — logs corrupt the data stream for the next program. Logs go to stderr
Printing usage on every error	Full help text on every error is noise. Set `SilenceUsage: true`, save full usage for `--help`
Config file required	Users without a config file get a crash. Ignore `viper.ConfigFileNotFoundError` — config should be optional
Not using `PersistentPreRunE`	Config initialization must happen before any subcommand. Use root's `PersistentPreRunE`
Hardcoded version string	Version gets out of sync with tags. Inject via `ldflags` at build time from git tags
Not supporting `--output` format	Scripts can't parse human-readable output. Add JSON/table/plain for machine consumption

Related Skills

See samber/cc-skills-golang@golang-project-layout, samber/cc-skills-golang@golang-dependency-injection, samber/cc-skills-golang@golang-testing, samber/cc-skills-golang@golang-design-patterns skills.

This skill ships inside the Samber Golang Skills plugin.

Install just this skill

Run this outside your AI tool, using Node.js 22.20.0 or newer. Skills CLI 1.7.2 skips skill selection; prompts cancel installation without an interactive terminal. If choosing Project when asked about installation scope, open your project's folder before running this.

Install checklist

Check selected tools if a picker appears; Claude Code may be unchecked under Additional agents. ↑/↓ moves, Space toggles selections, Enter confirms.
Without a tool picker, check Installing to: for your intended tool. Stop if it names a different tool.
If asked, choose Symlink (Recommended) for shared files or Copy to all agents for separate copies; review the summary before confirming installation.
Install the find-skills skill? defaults to Yes, adding another skill for all projects. Choose No if you don't want that extra installation.

Skills CLI 1.7.2 sends install data to skills.sh by default, including the source, skill names, target tools and file details; GitHub sources are reported only when GitHub confirms the repository is public, while other remote sources can also be reported. Confirmed-public GitHub sources also trigger a security-audit request. Before installing, set the environment variable DO_NOT_TRACK=1 or DISABLE_TELEMETRY=1 to disable both.

npx skills add samber/cc-skills-golang --skill "golang-cli" --full-depth

After installing for Claude Code, open it in the installation project if you chose Project; Global makes the skill available across projects on this computer. Once Claude Code loads the skill, its description helps Claude decide when to use it.

If installation created a top-level skills folder that did not exist when your Claude Code session started, run /reload-skills in that session. Run it again after later changes in that folder.

Install the whole plugin

This route installs the Samber Golang Skills plugin package selected for your AI tool.

Add Samuel's marketplace, then install the plugin

Type both lines inside a Claude Code session, not at your shell prompt. The marketplace is a separate repository of Samuel Berthe's, samber/cc, which also lists his other plugins. The second line opens the details of cc-skills-golang, which carries this repository's 46 Go skills; pick one of the install options shown and Claude Code installs it.

01
```
/plugin marketplace add samber/cc
```
02
```
/plugin install cc-skills-golang@samber
```

Run it in your terminal. It copies the whole repository, with its 46 skills, into ~/.openclaw/skills/cc-skills-golang, OpenClaw's skills folder in your home folder. To install it for one OpenClaw workspace instead, Samuel gives ~/.openclaw/workspace/skills/cc-skills-golang as the folder.

git clone https://github.com/samber/cc-skills-golang.git ~/.openclaw/skills/cc-skills-golang

Run it in your terminal, not inside Gemini CLI; installing from GitHub needs git on your computer. It installs the repository, with its 46 skills, as a Gemini CLI extension. To update it later, run gemini extensions update cc-skills-golang.

gemini extensions install https://github.com/samber/cc-skills-golang

Run it in your terminal. It copies the whole repository, with its 46 skills, into ~/.cursor/skills/cc-skills-golang, Cursor's skills folder in your home folder.

git clone https://github.com/samber/cc-skills-golang.git  ~/.cursor/skills/cc-skills-golang

Type it in an interactive GitHub Copilot CLI session, not at your shell prompt. It installs the repository straight from GitHub as a plugin, with its 46 skills and no marketplace to add first.

/plugin install https://github.com/samber/cc-skills-golang

Run it in your terminal. It copies the whole repository, with its 46 skills, into ~/.agents/skills/cc-skills-golang in your home folder.

git clone https://github.com/samber/cc-skills-golang.git ~/.agents/skills/cc-skills-golang

Open plugin page ↗

What's inside

Files included with this skill.

View on GitHub

Same repository

golang-benchmark
Golang benchmarking, profiling, and performance measurement. Use when writing, running, or comparing Go benchmarks, profiling hot paths with pprof, interpreting CPU/memory/trace profiles, analyzing results with benchstat, setting up CI benchmark regression detection, or investigating production performance with Prometheus runtime metrics. Also use when the developer needs deep analysis on a specific performance indicator - this skill provides the measurement methodology, while samber/cc-skills-golang@golang-performance provides the optimization patterns.Read full description
golang-code-style
Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See samber/cc-skills-golang@golang-naming skill), linter configuration (→ See samber/cc-skills-golang@golang-lint skill), or doc comments (→ See samber/cc-skills-golang@golang-documentation skill).Read full description
golang-concurrency
Golang concurrency patterns. Use when writing or reviewing concurrent Go code involving goroutines, channels, select, locks, sync primitives, errgroup, singleflight, worker pools, or fan-out/fan-in pipelines. Also triggers when you detect goroutine leaks, race conditions, channel ownership issues, or need to choose between channels and mutexes.Read full description
golang-context
Idiomatic context.Context usage in Golang — propagation through API boundaries, cancellation, timeouts and deadlines, request-scoped values, context.WithoutCancel for background work outliving requests. Apply when designing context propagation across layers, debugging leaked or unexpired contexts, choosing between context.Background/TODO/WithoutCancel, or storing values in context. Not for code that merely accepts ctx as first parameter.Read full description
golang-continuous-integration
CI/CD pipeline configuration using GitHub Actions for Golang projects — testing, linting, SAST, security scanning, code coverage, Dependabot, Renovate, GoReleaser, code review automation, and release pipelines. Use when setting up or improving Go project CI, configuring GitHub Actions workflows, adding linters or security scanners, automating dependency updates, or adding quality gates.Read full description
golang-data-structures
Golang data structures — slices (internals, capacity growth, preallocation, slices package), maps (internals, hash buckets, maps package), arrays, container/list/heap/ring, strings.Builder vs bytes.Buffer, generic collections, pointers (unsafe.Pointer, weak.Pointer), and copy semantics. Use when choosing or optimizing Go data structures, implementing generic containers, using container/ packages, unsafe or weak pointers, or questioning slice/map internals. Not for applying optimization patterns once profiling has identified a bottleneck (→ See samber/cc-skills-golang@golang-performance skill).Read full description