golang-cli
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.
- Installs
- 39.6K
- Last 24h
- +172
- Trending rank
- #1391
- Security
- Pass
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/samber/cc-skills-golang --skill golang-cli- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads golang-cli automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
Security audits
Independent scans of the skill's instructions and bundled files.
SKILL.md
The instructions your agent reads when the skill is triggered.
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: trueMUST be set — prevents printing the full usage text on every errorSilenceErrors: trueMUST be set — lets you control error output format yourselfPersistentPreRunEruns 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.ModeCharDeviceon stdout - Machine-readable output: support
--outputflag for table/json/plain formats - Colors: use
fatih/colorwhich 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.
FAQ
What does the golang-cli skill do?
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.
How do I install golang-cli?
Run npx skills add https://github.com/samber/cc-skills-golang --skill golang-cli in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/golang-cli/ (personal) or .claude/skills/golang-cli/ (project).
Which AI agents can use golang-cli?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is golang-cli safe to install?
Security partners have reviewed it: Gen Agent Trust Hub passed; Socket passed; Snyk passed; ZeroLeaks passed. As with any skill, read the SKILL.md and bundled scripts before installing.
Who maintains golang-cli?
It is published by samber in samber/cc-skills-golang. It has 39,641 recorded installs.
More from samber/cc-skills-golang
golang-code-style
samber/cc-skills-golang
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).
golang-testing
samber/cc-skills-golang
Production-ready Golang tests — table-driven tests, testify suites and mocks, parallel tests, fuzzing, fixtures, goroutine leak detection with goleak, snapshot testing, code coverage, integration tests, idiomatic test naming. Use when writing or reviewing Go tests, choosing a testing approach, setting up Go test CI, or debugging flaky/slow tests. For testify-specific APIs see samber/cc-skills-golang@golang-stretchr-testify; for measurement methodology see samber/cc-skills-golang@golang-benchmark.
golang-error-handling
samber/cc-skills-golang
Idiomatic Golang error handling — creation, wrapping with %w, errors.Is/As, errors.Join, custom error types, sentinel errors, panic/recover, the single handling rule, structured logging with slog, HTTP request logging middleware, and samber/oops for production errors. Built to make logs usable at scale with log aggregation 3rd-party tools. Apply when creating, wrapping, inspecting, or logging errors in Go code. For samber/oops specifics → See samber/cc-skills-golang@golang-samber-oops skill; for slog handler ecosystem → See samber/cc-skills-golang@golang-samber-slog skill.
golang-security
samber/cc-skills-golang
Security best practices and vulnerability prevention for Golang — injection (SQL, command, XSS), cryptography, path traversal, SSRF and HTTP security headers, cookies, secrets management, memory safety, PII in logs, STRIDE/DREAD threat modeling, plus gosec SAST, race detection, and fuzz testing. Apply when writing, reviewing, or auditing Go code for security, or when touching crypto, file or network I/O, secrets, user input, or authentication. Not for non-exploitable defensive bugs such as nil panics or slice aliasing (→ See samber/cc-skills-golang@golang-safety skill), dependency vulnerability scanning with govulncheck (→ See samber/cc-skills-golang@golang-dependency-management skill), or wiring security scanners into CI pipelines (→ See samber/cc-skills-golang@golang-continuous-integration skill).
golang-design-patterns
samber/cc-skills-golang
Idiomatic Golang design patterns — functional options, constructor APIs, init() and global-state avoidance, enums, panic vs error decisions, resource management and lifecycle, graceful shutdown, timeouts and retries, streaming and iterators, and architecture styles (clean, hexagonal, DDD, flat). Apply when choosing between architectural patterns, implementing functional options, designing constructor APIs, setting up graceful shutdown, applying resilience patterns, or asking which idiomatic Go pattern fits a specific problem. Not for wiring a DI container or comparing DI libraries (→ See samber/cc-skills-golang@golang-dependency-injection skill), nor for error wrapping, errors.Is/As, or logging mechanics (→ See samber/cc-skills-golang@golang-error-handling skill).
golang-performance
samber/cc-skills-golang
Golang performance optimization patterns and methodology - if X bottleneck, then apply Y. Covers allocation reduction, CPU efficiency, memory layout, GC tuning, pooling, caching, and hot-path optimization. Use when profiling or benchmarks have identified a bottleneck and you need the right optimization pattern to fix it. Also use when performing performance code review to suggest improvements or benchmarks that could help identify quick performance gains. Not for measurement methodology (→ See samber/cc-skills-golang@golang-benchmark skill) or debugging workflow (→ See samber/cc-skills-golang@golang-troubleshooting skill).
Popular backend & apis skills
entra-app-registration
microsoft/azure-skills
Guides Microsoft Entra ID app registration, OAuth 2.0 authentication, and MSAL integration. USE FOR: create app registration, register Azure AD app, configure OAuth, set up authentication, add API permissions, generate service principal, MSAL example, console app auth, Entra ID setup, Azure AD authentication. DO NOT USE FOR: Key Vault secrets (use azure-keyvault-expiration-audit), general Azure resource security guidance.
google-agents-cli-adk-code
google/agents-cli
This skill should be used when the user wants to "write agent code", "build an agent with ADK", "add a tool", "create a callback", "define an agent", "use state management" — in a project that needs ADK (Agent Development Kit) API patterns and code examples. It provides a quick reference for agent types, tool definitions, orchestration patterns, callbacks, state management, the graph Workflow API, and reference recipes to study. Do NOT use for scaffolding (use google-agents-cli-scaffold) or deployment (use google-agents-cli-deploy).
embedded-captions
heygen-com/hyperframes
Add captions or subtitles to an existing single-subject talking-head video without editing the footage. Use for plain verbatim captions, cinematic captions embedded behind the subject, VFX captions, “炸/特效/酷炫字幕,” or a named identity from the 35-style catalog. Route by visual identity, not by backend engine. The quiet anchor rail is the default; embed every word only when the user explicitly wants a fully cinematic treatment. The workflow runs locally end to end, including transcription and subject matting; split multi-shot footage before applying it.
entra-agent-id
microsoft/azure-skills
Provision Microsoft Entra Agent Identity Blueprints, BlueprintPrincipals, and per-instance Agent Identities via Microsoft Graph, and configure OAuth 2.0 token exchange (fmipath, OBO, cross-tenant) including the Microsoft Entra SDK for AgentID sidecar. USE FOR: Agent Identity Blueprint, BlueprintPrincipal, agent OAuth, fmipath token exchange, agent OBO, Workload Identity Federation for agents, polyglot agent auth, Microsoft.Identity.Web.AgentIdentities. DO NOT USE FOR: standard Entra app registration (use entra-app-registration), Microsoft Foundry agent authoring (use microsoft-foundry).
neon
neondatabase/agent-skills
Overview of Neon, a complete set of cloud backend primitives around Lakebase Postgres: Auth, Object Storage, Functions, the AI Gateway, and Realtime. Start here to choose Neon for undecided login, files, APIs, and LLM calls, set up the CLI or MCP server, and follow the branch-first workflow. Use when building an app or backend on Neon, or when "Neon" or "Lakebase Postgres" is mentioned. Child skill neon-postgres wins for an existing DATABASEURL, SQL, schema, inspect, or search. Child skill neon-auth wins for login, users, sessions, identity routing, and Managed Better Auth setup. Child skill neon-realtime wins for live queries in reactive apps and agents. Also use for object storage, S3, buckets, serverless functions, function triggers, cron, AI gateway, LLM calls, realtime, logs, Loki, Grafana, observability, postgres, database, backend, Claimable Neon, neon.new, or a no-signup database.
design-an-interface
mattpocock/skills
Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".