跳到主内容
智客 ZICQ

技能库 智客分类:Agent 工作流 golang-cli

Golang Cli

Golang CLI应用开发. 在构建,修改,或审查Go CLI工具时使用——特别是用于指令结构,旗帜处理,配置分层,版本嵌入,退出代码,I/O模式,信号处理, shell补全,参数验证,以及CLI单位测试. 当代码使用眼镜蛇,毒蛇,或urfave/cli时也会触发. 眼镜蛇特有的API → 见 “ samber/cc-skilling-golang@golang-spf13-cobra” 技能; 蛇配置层 → 见`Samber/cc-skills-golang@golang-spf13-viper ' 技能.

38459 安装量

官方网址:作者主页

技能介绍

先看中文介绍;官方 description 原文单独保留,不改写 SKILL.md。

做什么

Golang CLI 应用程序开发

何时用

官方 description 未单独写出 Use when。按规范,代理会在用户任务与这段 description 的关键词匹配时激活本技能。

代理如何加载

按 Agent Skills 渐进披露:启动时只加载 name 与 description(约 100 token);任务匹配后才读入整份 SKILL.md 正文;scripts/、references/、assets/ 仅在需要时再读。 本文件正文结构:Go CLI Best Practices、Quick Reference、Project Structure、Root Command Setup、Subcommands、Flags。

文件分析

文件分析:除 SKILL.md 外,正文引用了 assets/examples/main.go、assets/examples/root.go、assets/examples/serve.go、assets/examples/flags.go、assets/examples/args.go、assets/examples/config.go,属于带资源的技能包,这些文件按需再读。

官方 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.

Go CLI Best PracticesQuick ReferenceProject StructureRoot Command SetupSubcommandsFlagsPersistent vs LocalRequired FlagsFlag Validation with RegisterFlagCompletionFuncAlways Bind Flags to ViperArgument ValidationConfiguration with Viper

兼容:Designed for Claude Code, Codex or similar harness, and for projects using Golang. · 许可:MIT · allowed-tools:Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion

来源分类:skills.sh agent-skill

SKILL.md 与 Agent 调用

官方规范 ↗
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.
compatibility
Designed for Claude Code, Codex or similar harness, and for projects using Golang.
allowed-tools
Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent AskUserQuestion实验字段,支持情况取决于客户端;字段声明本身不会授予工具权限。
许可
MIT
  1. 发现技能客户端向 Agent 提供名称与描述目录。
  2. 匹配与调用用户指定或任务匹配后,载入 SKILL.md 指令。
  3. 按需加载按步骤读取参考文档、使用脚本与素材。
指令中引用的文件 · 6
  • assets/examples/main.go
  • assets/examples/root.go
  • assets/examples/serve.go
  • assets/examples/flags.go
  • assets/examples/args.go
  • assets/examples/config.go

以下路径提取自原文;文件是否齐全请以来源仓库中的完整目录为准。

具体调用语法与可用工具以目标 Agent 客户端为准。 查看调用机制说明 ↗

安装这个技能

Skills CLI ↗

先选择目标 Agent 和安装范围,保留技能包的附属文件,安装后检查客户端能否发现该技能。

该技能引用了附属文件,请从来源获取完整目录;仅复制 SKILL.md 可能缺少依赖。

交给 Agent 安装

复制安装指令给支持 Agent Skills 的代理,确认其中的目标目录与客户端匹配。

把 Agent Skill「golang-cli」安装到我的项目:SKILL.md 原文与官方 description 见 https://zicq.com/zh/skills/skl-6fc51eae1fb09bbc-Golang-Cli.html
请存为 .cursor/skills/golang-cli/SKILL.md 或 .claude/skills/golang-cli/SKILL.md,frontmatter 的 name 与 description 保持原样,不要改写。
该技能还带 scripts/、references/、assets/ 等文件,请从 https://github.com/samber/cc-skills-golang 取完整目录,不要只建一个 SKILL.md。

GitHub 完整包 ↗

终端安装 · Skills CLI

需要 Node.js 与 npx。先查看仓库技能列表,确认实际名称。

npx skills add 'https://github.com/samber/cc-skills-golang' --list

npx skills add 'https://github.com/samber/cc-skills-golang' --skill 'golang-cli'

CLI 会交互选择目标 Agent,默认安装到项目;用户级安装使用 -g。先通过查看命令核对仓库内容,再用 npx skills list 检查已安装技能。

阅读排版

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.

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):

  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 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.

相关技能

Agent 工作流

Skill Creator

创造有效技能指南。 当用户想创造出新的技能(或更新现有的技能),以专业知识,工作流程,或工具集成来扩展克洛德的能力时,应该使用这种技能.

Agent 工作流

Clawdhub

使用ClawdHub CLI搜索,安装,更新并发布从taladhub.com的代理技能. 需要获取苍蝇上的新技能时使用,将安装的技能同步到最新版本或特定版本,或者发布 npm-instainddhub CLI 的新/更新的技能文件夹.

Agent 工作流

Agent Team Orchestration

管弦乐团多代理团队,任务设定周期,交接协议,审查工作流程. 使用时间: (1)建立2+特派员队伍,具有不同专业,(2)确定任务路线和生命周期(收录框_ spec_建设_审查_完成),(3)在特派员之间制定交接协议,(4)建立审查和质量关口,(5)管理特派员之间的交流和文物共享.

Agent 工作流

Superpowers

Spec-first,TDD,子代理驱动的软件开发工作流程. 当:(1)构建任何新功能或应用——触发脑暴_计划_子代理执行回路,(2)调试出一个bug或测试失败——触发系统性的根起过程,(3)用户说"让我们构建","帮助我计划","我想添加X",或"这个被打破",(4)完成一个功…