Go CLI Command Design
Design the command as a public interface before treating it as an implementation.
Keep results pipeable, failures diagnosable, and process-global state at the edge.
Core Workflow
- State the command purpose, invocation syntax, callers, and compatibility promises.
- Assign each input to a flag, operand, stdin, environment, or config source.
- Define precedence, validation, conflicts, defaults, and blocking behavior.
- Reserve stdout for results and requested help; use stderr for diagnostics,
invalid-usage help, and progress.
- Return errors from command logic and map exit codes at the process boundary.
- Inject streams, configuration, and effects behind a small testable runner.
- Verify help, invalid usage, operational failures, and supported target behavior.
- Verify noninteractive, color-disabled, canceled, and short-reading pipe behavior.
Read Next
| Task |
Load |
| Design or change a complete command contract |
guidelines.md, workflows/design-command-interface.md |
| Implement flags, streams, environment, or errors |
references/command-interface/rules.md, references/command-interface/examples.md |
| Understand the design rationale |
references/command-interface/knowledge.md |
| Review an existing command |
references/command-interface/checklist.md |
Guardrails
- Prefer a dedicated
flag.FlagSet over package-global flags in reusable code.
- Do not read stdin unless the documented invocation requires it.
- Do not call
os.Exit below the outer process boundary.
- Treat structured output, exact text, and exit codes as APIs when automation relies on them.
- Never prompt, animate, or emit ANSI sequences in structured or noninteractive mode.
- Treat closed downstream pipes as normal pipeline termination when appropriate.
- Cross-compilation does not replace target-level smoke testing.
Source Notes
Guidance is transformed and paraphrased from Ricardo Gerardi,
Powerful Command-Line Applications in Go (Pragmatic Bookshelf, 2021),
especially Chapters 1-2. Examples are original adaptations.
Modern interaction, cancellation, and output-mode guidance also incorporates
transformed material from Marian Montagnino, Building Modern CLI Applications
in Go (Packt, 2023), especially Chapters 1, 5, 8, and 10.
Book: https://pragprog.com/titles/rggo/powerful-command-line-applications-in-go/
Modern API details should be verified against https://pkg.go.dev/flag and the
current Go documentation before implementation.
Parser grammar and validation guidance also incorporates transformed material
from Inanc Gumus, Go by Example: Programmer's Guide to Idiomatic and Testable
Programs (Manning, 2025), Chapter 4.
1---2name: go-cli-command-design3description: Design and review predictable Go command-line interfaces with canonical names and flags; explicit inputs and precedence; human, plain, and structured output; safe prompting; stdout and stderr contracts; help; errors; exit codes; cancellation; dependency injection; and platform behavior. Use when creating a Go CLI, changing its public command contract, making command code testable, or reviewing compatibility for people, scripts, AI agents, and CI.4license: MIT5---67# Go CLI Command Design89Design the command as a public interface before treating it as an implementation.10Keep results pipeable, failures diagnosable, and process-global state at the edge.1112## Core Workflow13141. State the command purpose, invocation syntax, callers, and compatibility promises.152. Assign each input to a flag, operand, stdin, environment, or config source.163. Define precedence, validation, conflicts, defaults, and blocking behavior.174. Reserve stdout for results and requested help; use stderr for diagnostics,18 invalid-usage help, and progress.195. Return errors from command logic and map exit codes at the process boundary.206. Inject streams, configuration, and effects behind a small testable runner.217. Verify help, invalid usage, operational failures, and supported target behavior.228. Verify noninteractive, color-disabled, canceled, and short-reading pipe behavior.2324## Read Next2526| Task | Load |27|---|---|28| Design or change a complete command contract | `guidelines.md`, `workflows/design-command-interface.md` |29| Implement flags, streams, environment, or errors | `references/command-interface/rules.md`, `references/command-interface/examples.md` |30| Understand the design rationale | `references/command-interface/knowledge.md` |31| Review an existing command | `references/command-interface/checklist.md` |3233## Guardrails3435- Prefer a dedicated `flag.FlagSet` over package-global flags in reusable code.36- Do not read stdin unless the documented invocation requires it.37- Do not call `os.Exit` below the outer process boundary.38- Treat structured output, exact text, and exit codes as APIs when automation relies on them.39- Never prompt, animate, or emit ANSI sequences in structured or noninteractive mode.40- Treat closed downstream pipes as normal pipeline termination when appropriate.41- Cross-compilation does not replace target-level smoke testing.4243## Source Notes4445Guidance is transformed and paraphrased from Ricardo Gerardi,46*Powerful Command-Line Applications in Go* (Pragmatic Bookshelf, 2021),47especially Chapters 1-2. Examples are original adaptations.4849Modern interaction, cancellation, and output-mode guidance also incorporates50transformed material from Marian Montagnino, *Building Modern CLI Applications51in Go* (Packt, 2023), especially Chapters 1, 5, 8, and 10.5253Book: https://pragprog.com/titles/rggo/powerful-command-line-applications-in-go/5455Modern API details should be verified against https://pkg.go.dev/flag and the56current Go documentation before implementation.5758Parser grammar and validation guidance also incorporates transformed material59from Inanc Gumus, *Go by Example: Programmer's Guide to Idiomatic and Testable60Programs* (Manning, 2025), Chapter 4.
LVTD-LLC