go-cli-ship

name	go-cli-ship
description	Build or upgrade Go CLI projects to production quality with a deterministic workflow: architecture, stable CLI contract, tests/lint gates, cloud smoke tests, release automation, installer, README quality, and skill packaging. Use when users ask to develop a Go CLI from scratch, improve engineering quality, fix CI/release issues, ship versions, or standardize docs and SKILL.md.

Go CLI Ship

将“需求 -> 设计 -> 实现 -> 验证 -> 发版 -> 文档/技能”固化为可重复执行的交付流程。

触发意图

当用户出现以下诉求时使用本技能：

• “开发一个 Go CLI/重构现有 CLI”
• “把项目做成可发布、可安装、可自动化”
• “CI / lint / release 一直报错，帮我闭环”
• “README 不专业，发版质量不稳定”
• “需要技能化，让后续项目复用流程”

第一性原理

1. CLI 本质是自动化接口，不只是命令行工具。
2. 稳定契约优先于局部体验：向后兼容、错误码稳定、JSON 可机读。
3. 发版是系统工程：版本一致性 + workflow 可重复 + 产物可验证。
4. 文档是产品一部分：README 决定信任和采用率。
5. 技能文档不是科普文，应是可执行操作手册。

逆向约束（先防失败）

先检查这些高频失败点：

1. go.mod Go 版本与 CI/lint 构建器是否一致。
2. golangci-lint 是否会因编译器版本低于目标版本而 panic。
3. release artifact 下载后是否为目录结构（checksum 误扫目录）。
4. tag 是否指向正确提交（release 仅对 tag push 触发）。
5. Makefile/install.sh/CHANGELOG.md 版本是否一致。
6. README 是否缺少价值主张、安装路径、云端教程、输出契约。
7. SKILL.md 是否符合 skill-creator（frontmatter 仅 name/description）。

标准交付流程

1) 需求建模

• 定义用户、核心场景、非目标。
• 定义命令边界：
  • 人类输出（table）
  • 机器输出（json，默认）
• 定义错误模型：稳定 code + message + retryable + 可选 details。

2) CLI 合同设计

• 命令命名稳定，不随文案变化。
• 参数新增优先“增量兼容”，不要破坏旧参数。