golang-cli
This skill guides building Go CLI applications using Cobra for commands and flags, Viper for configuration layering, and Unix best practices.
Community author
- Agents
- Claude Code
- License
- MIT (permissive)
- Pin
- 8e899e2pinned Oct 9, 2026
- Context cost
- about 2,300 tokenswhen the skill loads
- GitHub stars
- 3,424on samber/cc-skills-golang
- Scripts
- 12 scripts
What it does
“Golang CLI application development. Use when building, modifying, or reviewing a Go CLI tool — especially for command structure, flag handling, configuration layering, version embedding, exit codes, I/O patterns, signal handling, shell completion, argument validation, and CLI unit testing. Also triggers when code uses cobra, viper, or urfave/cli. For cobra-specific APIs → See `samber/cc-skills-golang@golang-spf13-cobra` skill; for viper configuration layering → See `samber/cc-skills-golang@golang-spf13-viper` skill.”
Generated summary from the skill's own text
This skill guides building Go CLI applications using Cobra for commands and flags, Viper for configuration layering, and Unix best practices. It covers project structure, argument validation, exit codes, I/O patterns, signal handling, shell completion, and testing strategies for production-quality command-line tools.
When to use it
- Creating new Go CLI tools with subcommands and configuration files
- Adding flags, subcommands, or completions to existing CLIs
- Reviewing CLI code for proper error handling and Unix conventions
- Building tools that need config from files, environment variables, and flags
When not to
- Simple single-purpose scripts with no subcommands or few flags
- Projects already using specialized frameworks beyond Cobra and Viper
- Building graphical user interfaces or web applications
Install
These commands install from the publisher's repository and need no account.
skills CLI
npx skills add samber/cc-skills-golang --skill golang-cliInstalls from the repository's default branch, which may have changed since the commit we checked.
GitHub CLI 2.90 or later
gh skill install samber/cc-skills-golang golang-cli@8e899e20ff0cd4dc524af3993e4c62d8ee8c5717Installs the commit we checked (8e899e2).
Copy by hand
Download the folder at 8e899e2 and put it in .claude/skills/golang-cli for Claude Code and in .agents/skills/golang-cli for Codex, Cursor, Gemini CLI, GitHub Copilot and OpenCode.
Copy for your agent
A prompt for any coding agent. It installs this skill from GitHub at the pinned commit, copies the files as they are, and runs nothing unless you ask.
Prompt
Install the agent skill "golang-cli" by samber. Source, pinned to commit 8e899e20ff0cd4dc524af3993e4c62d8ee8c5717: https://github.com/samber/cc-skills-golang/tree/8e899e20ff0cd4dc524af3993e4c62d8ee8c5717/skills/golang-cli 1. Download that folder at exactly this commit. Do not use the default branch. 2. Copy every file unchanged, keeping the folder structure, into .claude/skills/golang-cli/ for Claude Code and .agents/skills/golang-cli/ for Codex, Cursor, Gemini CLI, GitHub Copilot and OpenCode. Create the folders if they do not exist. 3. Do not edit the files, and do not run any script in the folder unless I ask you to. 4. When you are done, list the files you copied and where you put them. Listing and checks: https://www.agentnative.dev/skills/samber/golang-cli
SKILL.md at the pin
---
name: golang-cli
description: "Golang CLI application development. Use when building, modifying, or reviewing a Go CLI tool — especially for command structure, flag handling, configuration layering, version embedding, exit codes, I/O patterns, signal handling, shell completion, argument validation, and CLI unit testing. Also triggers when code uses cobra, viper, or urfave/cli. For cobra-specific APIs → See `samber/cc-skills-golang@golang-spf13-cobra` skill; for viper configuration layering → See `samber/cc-skills-golang@golang-spf13-viper` skill."
user-invocable: true
license: MIT
compatibility: Designed for Claude Code, Codex or similar harness, and for projects using Golang.
metadata:
author: samber
version: "1.3.0"
openclaw:
emoji: "💻"
homepage: https://github.com/samber/cc-skills-golang
requires:
bins:
- go
install: []
allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion
paths:
- "**/*.go"
---
**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](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](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](assets/examples/serve.go) for a complete subcommand example including command groups.
## Flags
See [assets/examples/flags.go](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](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):
1. **CLI flags** (explicit user input)
2. **Environment variables** (deployment config)
3. **Config file** (persistent settings)
4. **Defaults** (set in code)
See [assets/examples/config.go](assets/examples/config.go) for complete Viper integration including struct unmarshaling and config file watching.
### Example Config File (.myapp.yaml)
```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](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](assets/examples/exit_codes.go) for a pattern mapping errors to exit codes.
## I/O Patterns
See [assets/examples/output.go](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](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](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](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.
From samber/cc-skills-golang at 8e899e2, shown as plain text under its license: MIT (permissive). The license text is in skills/golang-cli/SKILL.md.
View SKILL.md on GitHub at 8e899e2Files
- SKILL.md10 KB · da9eef3871a9
- assets/
- examples/
- args.go1.0 KB · 024d75e8fcb5
- cli_test.go1.3 KB · 0086d4f0f075
- completion.go1.7 KB · 3e91ac78c36d
- config.go1.8 KB · 24f6c7653b90
- exit_codes.go494 B · 27d02ca34c93
- flags.go1.3 KB · d8a7164364e6
- main.go120 B · f529e3cfddb3
- output.go1.8 KB · 1520680bb6fe
- root.go1.8 KB · fe6429593d1a
- serve.go735 B · 0b8c5253a1cd
- signal.go831 B · 620e92cdf1a0
- version.go871 B · 660668240b0e
- evals/
- evals.json16 KB · b2a08339a212
14 files, 40 KB in total. Each file has a sha256 in the pin's manifest; the first 12 characters are shown.
Skill folder on GitHub at 8e899e2More from samber
crxjs
CRXJS is a Vite plugin for Chrome extension development that provides true hot-module reloading for popups, options pages, content scripts, and side panels.
Claude Code · about 2.3K tokens · pinned 6 days ago
api-integration-surface-strategy
Helps platform teams decide which integration surfaces to build, REST, GraphQL, webhooks, SDKs, MCP, SQL, embedded components, and in what order, guided by…
Claude Code, Codex, Cursor +4 · about 4.2K tokens · pinned 6 days ago
cross-event-promotion
This skill helps event organizers set up mutual visibility trades with independent events run by other organizers.
Claude Code, Codex, Cursor +4 · about 4.2K tokens · pinned 6 days ago
changelog-writing
Transforms raw commits, pull requests, and tickets into well-structured release notes that readers can scan quickly to understand what changed and what breaks.
Contains scripts
Claude Code, Codex, Cursor +3 · about 6K tokens · pinned 6 days ago
Related in Coding workflow
go-error-handling
This skill guides agents writing Go error handling by choosing between sentinel errors, custom types, and wrapping strategies using fmt.Errorf with %w or %v.
by cxuuCommunity
Contains scripts
Claude Code, Codex, Cursor +3 · about 1.4K tokens · pinned 6 days ago
planning
This skill orchestrates multi-workflow projects with dependencies and shared data tables by creating a task graph in the orchestrator via the create-tasks tool.
by n8nOfficial publisher
Claude Code, Codex, Cursor +3 · about 2.4K tokens · pinned 6 days ago
progressive-building
This skill implements incremental workflow development for agents building or extending workflows.
by n8nOfficial publisher
Claude Code, Codex, Cursor +3 · about 1.4K tokens · pinned 6 days ago
workflow-builder
Builds and edits n8n workflows using the TypeScript SDK.
by n8nOfficial publisher
Claude Code, Codex, Cursor +3 · about 14.2K tokens · pinned 6 days ago
remotion-upgrade
This skill upgrades Remotion and its related packages to the latest stable version.
by RemotionOfficial publisher
Claude Code, Codex, Cursor +3 · about 460 tokens · pinned 6 days ago
remotion-upgrade
This skill upgrades Remotion and related packages across a project, automatically detecting the package manager and workspaces.
by RemotionOfficial publisher
Claude Code, Codex, Cursor +3 · about 460 tokens · pinned 6 days ago