Golang CliSAFE
๐ง๐จ A collection of Golang agentic skills that works
Overview
๐ง๐จ A collection of Golang agentic skills that works
3823d8ae0038OBSERVED ยท 2026-10-08Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| claude-code | mentioned | |
| codex | mentioned | |
| openclaw | mentioned |
What it tells the agent
The instruction file, verbatim from the audited commit โ this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
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 includiTrust audit
SAFEgrade B ยท trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | PASS |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
3823d8ae0038full audit observations/trust-audit/skill/samber__golang-cli.json ยท Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-08 | 3823d8ae0038 | SAFE | B | 89 | first audit |
Questions
What does the Golang Cli skill do?
๐ง๐จ A collection of Golang agentic skills that works
Is Golang Cli safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Golang Cli access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
Which assistants does Golang Cli work with?
Its documentation mentions claude-code, codex and openclaw. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (3823d8ae0038), read on 2026-10-08. The repository is watched, and a new audit runs when it changes โ this is the first audit.