From scaffold-go-cli
Scaffold a complete Go CLI project with Cobra, GoReleaser, GitHub Actions CI/CD, Homebrew tap publishing, and Makefile. Use when the user says "scaffold a Go CLI", "new Go CLI project", "create a Go CLI", "start a Go CLI", "bootstrap a Go CLI", or starts a Go command-line tool from scratch. Optionally adds Viper for config file management and Charmbracelet bubbletea/lipgloss/bubbles for TUI work. For Go libraries (no main.go) use scaffold-go-library instead. For language-agnostic boilerplate alone, use scaffold-new-repo.
How this skill is triggered — by the user, by Claude, or both
Slash command
/scaffold-go-cli:scaffold-go-cliThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generate the full boilerplate for a new Go CLI project.
references/ci-workflow.mdreferences/gitignore.mdreferences/go-mod.mdreferences/goreleaser.mdreferences/homebrew-tap-token.mdreferences/license.mdreferences/main-go.mdreferences/makefile.mdreferences/readme.mdreferences/release-workflow.mdreferences/root-go-with-viper.mdreferences/root-go-without-viper.mdGenerate the full boilerplate for a new Go CLI project.
If the user provided a project name in their request, use it as the project name and skip asking for it. Still ask for the remaining parameters (description, Viper, Charmbracelet TUI) unless already provided in the user's initial request.
Ask the user for these parameters:
my-tool)Short field--config flag and ~/.config/<name>/config.yaml support)If the user already provided some or all of these in their initial request, do not re-ask. Derive what you can from context.
Detect the user's GitHub username and full name for use in templates:
# GitHub username (for module paths, URLs, Homebrew tap)
gh api user -q .login
# Full name (for LICENSE copyright)
git config user.name
If either command fails or produces no output, ask the user to provide the value. Use the GitHub username wherever templates reference GITHUB-USERNAME and the full name wherever they reference COPYRIGHT-HOLDER.
The project should be scaffolded in a directory named after the project. If the current directory is already named after the project and is empty (or nearly empty), use it. Otherwise, create a subdirectory.
If the directory already contains Go files, warn the user before proceeding.
Skip if already inside a git repository.
git init
Read ./references/main-go.md for the main.go template and create the file from it.
PROJECT-NAME with the project nameGITHUB-USERNAME with the detected GitHub usernameChoose the template based on the Viper parameter:
./references/root-go-without-viper.md./references/root-go-with-viper.mdReplace in the chosen template:
PROJECT-NAME with the project namePROJECT-DESCRIPTION with the short descriptionRead ./references/go-mod.md for the canonical setup commands. The base sequence:
go mod init github.com/GITHUB-USERNAME/PROJECT-NAME
go get github.com/spf13/cobra@latest
If Viper was selected:
go get github.com/spf13/viper@latest
If Charmbracelet TUI was selected:
go get charm.land/bubbletea/v2@latest
go get charm.land/lipgloss/v2@latest
go get charm.land/bubbles/v2@latest
Then tidy:
go mod tidy
Read ./references/makefile.md for the Makefile template and create Makefile from it.
PROJECT-NAME with the project nameRead ./references/gitignore.md for the .gitignore template and create .gitignore from it.
PROJECT-NAME with the project nameIf a .gitignore already exists, merge the template entries into it rather than overwriting.
Read ./references/goreleaser.md for the GoReleaser template and create .goreleaser.yml from it.
PROJECT-NAME with the project namePROJECT-DESCRIPTION with the short descriptionGITHUB-USERNAME with the detected GitHub usernameRead ./references/ci-workflow.md for the CI workflow template and create .github/workflows/ci.yml from it.
No replacements needed (the workflow is project-name-independent).
Read ./references/release-workflow.md for the release workflow template and create .github/workflows/release.yml from it.
No replacements needed.
Read ./references/license.md for the LICENSE template and create LICENSE from it.
YEAR with the current year (run date +%Y to get it)COPYRIGHT-HOLDER with the detected full nameRead ./references/readme.md for the README template and create README.md from it.
PROJECT-NAME with the project name (kebab-case)PROJECT-DESCRIPTION with the short descriptionGITHUB-USERNAME with the detected GitHub usernameCreate CHANGELOG.md with the initial changelog template:
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
No replacements needed. The release skill will populate version sections and comparison links on the first release.
Create stub directories for the standard project layout:
# internal package stub
mkdir -p internal
touch internal/.gitkeep
# plans directory
mkdir -p docs/plans/todo docs/plans/done
touch docs/plans/todo/.gitkeep docs/plans/done/.gitkeep
# tests directory
mkdir -p tests
touch tests/.gitkeep
Run a quick build to confirm everything compiles:
go build ./...
If the build fails, diagnose and fix the issue before continuing.
Stage all generated files and create the initial commit:
git add -A
git commit -S -m "feat: scaffold Go CLI project"
If .github/copilot-instructions.md exists (created by scaffold-new-repo when running in the bootstrap flow, or already present in an existing repo), append the following entries to the PR review section. Before appending each entry, check whether the bold key text already exists in the file; skip entries that are already present.
To locate the PR review section: look for an existing heading whose text includes "PR Review" or "Code Review" (e.g., ## PR Review, ## Code Review, ## PR Review Checklist (CRITICAL)). If no matching heading exists, append a new ## PR Review section at the end of the file and place the entries there.
cboone/gh-actions reusable workflows manage tool versions internally: The CI and release workflows use cboone/gh-actions reusable workflows that handle tool installation, version pinning, caching, and SHA-256 verification internally. Do not suggest replacing reusable workflow calls with inlined third-party actions.If .github/copilot-instructions.md does not exist, skip this step.
The release workflow requires a HOMEBREW_TAP_TOKEN repository secret to publish Homebrew casks. Read ./references/homebrew-tap-token.md for the full setup steps.
Ask the user whether they want to set up the token now or defer it to later. If they defer, note in the summary that the token must be configured before the first release.
Note: for brand-new projects that have not been pushed to GitHub yet, gh secret commands (including gh secret set and gh secret list) will not work until a GitHub remote exists. See the "No remote yet?" note in the reference.
Print a summary of what was created:
List every file and directory generated
Note which optional features were included (Viper, Charmbracelet TUI)
Remind the user to:
cmd/ as the CLI growsmake help to see available Makefile targetsIf HOMEBREW_TAP_TOKEN setup was deferred in step 20: check whether a GitHub remote exists and is accessible before creating a follow-up issue:
if git remote get-url origin >/dev/null 2>&1 && gh repo view >/dev/null 2>&1; then
gh issue create \
--title "Set up HOMEBREW_TAP_TOKEN repository secret" \
--body "The release workflow needs a HOMEBREW_TAP_TOKEN secret so GoReleaser can push Homebrew cask updates to the tap repository.
See the HOMEBREW_TAP_TOKEN Setup reference in the scaffold-go-cli skill documentation for step-by-step instructions."
fi
If the issue was created successfully, report its URL in the summary.
If no remote exists or the repo is not accessible via gh, print a reminder instead: the user should create the issue manually (or re-run the token setup) after pushing to GitHub for the first time.
go mod init fails, check that Go is installed and on the PATHgo get fails for any dependency, check network connectivity and retry oncegit init fails, continue generating files but warn the user./references/main-go.md -- main.go template./references/root-go-without-viper.md -- cmd/root.go without Viper./references/root-go-with-viper.md -- cmd/root.go with Viper./references/go-mod.md -- go mod init and dependency setup./references/makefile.md -- Makefile template./references/gitignore.md -- .gitignore template./references/goreleaser.md -- .goreleaser.yml template./references/ci-workflow.md -- .github/workflows/ci.yml./references/release-workflow.md -- .github/workflows/release.yml./references/license.md -- MIT license template./references/readme.md -- README template./references/homebrew-tap-token.md -- HOMEBREW_TAP_TOKEN repository-secret setupcboone/gh-actions SHAs before scaffoldingThe cboone/gh-actions reusable-workflow refs in this skill's templates are SHA-pinned with a # vX.Y.Z comment that was current when the template was authored. New releases of cboone/gh-actions rot those SHAs. Before emitting a workflow into a user's repo, refresh both the SHA and the comment to current latest:
TAG="$(gh release view --repo cboone/gh-actions --json tagName --jq '.tagName')"
SHA="$(gh api "repos/cboone/gh-actions/commits/${TAG}" --jq '.sha')"
echo "${SHA} # ${TAG}"
Replace each cboone/gh-actions/.../<workflow>.yml@<old-sha> # <old-tag> in the emitted workflow with the new SHA and tag. Dependabot in the user's repo keeps them in sync afterwards.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub cboone/agent-harness-plugins --plugin scaffold-go-cli