Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsBlogPro
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Authors
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges
  • Chrome Extension
  • Skill Manager

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

ProTermsPrivacyRefunds
Back to skills

Done

ASecurity

Issue #27 requests a new skill that adds GoReleaser configuration and a GitHub Actions release workflow to an **existing** Go CLI project, with Homebrew tap publishing. This pattern is virtually identical across 4 repos (jm, gh-problemas, bopca, right-round) and is error-prone to configure manually. Unlike `scaffold-go-cli` (which creates new projects from scratch), this skill targets projects that already have Go code, a `go.mod`, and possibly a Makefile.

2 stars
0 votes
0 copies
0 views
Added 10/2/2026
developmentgorubyshellrefactoringgitapiperformancedocumentation

Works with

cliapi

Security Analysis

A100/100

Pro scans all 21 files and shows the line behind each finding

Scanned 10/2/2026

$npx -y skills add cboone/agent-harness-plugins --skill done --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Done?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Done
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/cboone-done/badge)](https://www.skillsdirectory.com/skills/cboone-done)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
Files
2026-02-15-add-create-worktree-skill-with-prompt-injection.md
# Plan: Add GoReleaser Homebrew Skill

## Context

Issue #27 requests a new skill that adds GoReleaser configuration and a GitHub Actions release workflow to an **existing** Go CLI project, with Homebrew tap publishing. This pattern is virtually identical across 4 repos (jm, gh-problemas, bopca, right-round) and is error-prone to configure manually. Unlike `scaffold-go-cli` (which creates new projects from scratch), this skill targets projects that already have Go code, a `go.mod`, and possibly a Makefile.

The skill introduces one new pattern not present in any reference repo or in `scaffold-go-cli`: **conventional commit changelog grouping** (using `changelog.groups` instead of simple `sort+filters`).

## Files to Create (6 new files)

### 1. `plugins/add-goreleaser-homebrew/.claude-plugin/plugin.json`

Standard plugin manifest at version `1.0.0`. Keywords: `github-actions`, `go`, `golang`, `goreleaser`, `homebrew`.

### 2. `plugins/add-goreleaser-homebrew/skills/add-goreleaser-homebrew/SKILL.md`

Main skill file following the `scaffold-go-cli` workflow pattern (numbered `### N. Step Name` subsections). Workflow steps:

1. **Verify the Project** -- Check `go.mod` exists; read module path; check for existing `.goreleaser.yml`/`.goreleaser.yaml` and `.github/workflows/release.yml`; warn if either exists and ask whether to overwrite
1. **Detect User Identity** -- `gh api user -q .login` and `git config user.name` (same pattern as `scaffold-go-cli`)
1. **Gather Project Information** -- Short description (infer from README first), Homebrew dependencies
1. **Detect Project Features** -- Three conditionals:
   - **Completions**: check for `cmd/completion.go` or grep for `"completion"` cobra command registration
   - **Man pages**: check for `cmd/man.go` or grep for `"man"` cobra command, and for `cobra/doc` or `mango` imports
   - **macOS-only**: check for GOOS=darwin constraints in Makefile or build tags, or ask the user
   - Present detected features for user confirmation
1. **Determine ldflags Target** -- Find where `var version` is declared (typically `main` or `cmd` package) and detect the correct `-X` path
1. **Determine Build Entry Point** -- Check if `main()` is in the repo root or a subdirectory like `./cmd/project-name`
1. **Generate .goreleaser.yml** -- Base template from `./references/goreleaser.md` + conditional modifications from `./references/conditional-features.md`
1. **Generate Release Workflow** -- Template from `./references/release-workflow.md` (use `macos-latest` if macOS-only)
1. **Optionally Update Makefile** -- Append `release-dry-run` target from `./references/makefile-target.md`
1. **Verify Configuration** -- Run `goreleaser check` if installed
1. **Summary** -- List created/modified files, applied conditionals, remind about `HOMEBREW_TAP_TOKEN` secret

### 3. `plugins/add-goreleaser-homebrew/skills/add-goreleaser-homebrew/references/goreleaser.md`

Base `.goreleaser.yml` template (GoReleaser v2). Key contents:

- `version: 2`
- `builds:` with `CGO_ENABLED=0`, cross-platform (`linux`, `darwin`, `windows` / `amd64`, `arm64`), ldflags `-s -w -X`
- `archives:` with `tar.gz` default, `zip` for Windows, `name_template` with version
- `checksum:` with `checksums.txt`
- `release:` with `prerelease: auto`
- **`changelog:` with conventional commit groups** -- This is the new pattern:
  - Features (feat), Bug Fixes (fix), Performance (perf), Refactoring (refactor), Documentation (docs), Build (build/ci), Other (catch-all order 999)
  - Filters excluding `chore:`, `test:`, `style:`
- `brews:` with `GITHUB-USERNAME/homebrew-tap`, `HOMEBREW_TAP_TOKEN`, `Formula` directory, basic version test
- Placeholders: `PROJECT-NAME`, `PROJECT-DESCRIPTION`, `GITHUB-USERNAME`
- `## Notes` section explaining each design decision (following `scaffold-go-cli/references/goreleaser.md` convention)

### 4. `plugins/add-goreleaser-homebrew/skills/add-goreleaser-homebrew/references/release-workflow.md`

Release workflow template using latest action versions:

- `actions/checkout@v6` with `fetch-depth: 0`
- `actions/setup-go@v6` with `go-version-file: go.mod`
- `goreleaser/goreleaser-action@v6` with `version: "~> v2"`, `args: release --clean`
- `GITHUB_TOKEN` and `HOMEBREW_TAP_TOKEN` environment variables
- Default `runs-on: ubuntu-latest`
- A `## macOS-Only Variant` section showing `runs-on: macos-latest`
- `## Notes` section

### 5. `plugins/add-goreleaser-homebrew/skills/add-goreleaser-homebrew/references/makefile-target.md`

Small snippet for the optional `release-dry-run` target:

```makefile
release-dry-run: ## Run GoReleaser in dry-run mode (no publish)
	goreleaser release --snapshot --clean
```

With notes on how to merge into an existing Makefile (add to `.PHONY`, append the target).

### 6. `plugins/add-goreleaser-homebrew/skills/add-goreleaser-homebrew/references/conditional-features.md`

Documents all three conditional feature modifications with detection logic and YAML/Ruby snippets to apply:

- **Shell Completions**: Detection heuristics + `generate_completions_from_executable(bin/"BINARY", "completion")` in brews install
- **Man Pages**: Detection heuristics + `before.hooks` (`go run . man man/man1`), `archives.files` mapping, `man1.install Dir["man/man1/*"]` in brews install
- **macOS Only**: Detection heuristics + restrict `goos: [darwin]`, optionally `goarch: [arm64]`, `custom_block: depends_on :macos`, `runs-on: macos-latest` in workflow
- **Combining Features**: How to merge multiple conditionals into a single config (with bopca as a real-world example)

## Files to Modify (3 existing files)

### 7. `.claude-plugin/marketplace.json`

- Bump `metadata.version` from `"1.9.0"` to `"1.10.0"` (adding a plugin)
- Insert new entry as **first** in `plugins` array (alphabetically before `address-review`)
- Entry fields: `category: "productivity"`, `version: "1.0.0"`, matching description/keywords from `plugin.json`

### 8. `README.md`

**ToC** (line 9-10 area): Insert before the current first Workflow entry. "Address Review" gets a `∙` prefix:

```markdown
<br>Workflow:
[Add GoReleaser Homebrew](#add-goreleaser-homebrew)
∙ [Address Review](#address-review)
```

**Description section** (before line 48 "### Address Review"): Insert new H3 section:

```markdown
### Add GoReleaser Homebrew

Add GoReleaser configuration and a GitHub Actions release workflow to an
existing Go CLI project with Homebrew tap publishing to
`cboone/homebrew-tap`. Detects project features (shell completions, man page
generation, macOS-only constraints) and generates appropriate configuration
with conventional commit changelog grouping. Optionally adds a
`release-dry-run` Makefile target.

> **Trigger:** `/add-goreleaser-homebrew`
```

### 9. `CLAUDE.md`

Insert new entry in the directory tree as the **first** plugin under `plugins/` (alphabetically before `address-review/`):

```text
    ├── add-goreleaser-homebrew/     # GoReleaser + Homebrew tap setup skill
    │   ├── .claude-plugin/
    │   │   └── plugin.json
    │   └── skills/
    │       └── add-goreleaser-homebrew/
    │           ├── SKILL.md
    │           └── references/
    │               ├── conditional-features.md
    │               ├── goreleaser.md
    │               ├── makefile-target.md
    │               └── release-workflow.md
```

## Key Design Decisions

1. **Conventional commit changelog groups** (new pattern): The issue explicitly asks for this. None of the 4 reference repos currently use it -- they use simple `sort+filters` or `github-native`. This skill introduces a better pattern that groups commits under headings (Features, Bug Fixes, Refactoring, etc.).

1. **4 reference files in a single directory** (not 6): Conditional features (completions, man pages, macOS-only) are documented together in one file since they modify the same goreleaser config and are interrelated. The base templates (goreleaser, workflow, Makefile target) get their own files.

1. **Detection-then-confirm workflow**: The skill detects existing project features automatically, then presents findings for user confirmation before generating configs. This avoids both false positives and unnecessary questioning.

1. **`go-version-file: go.mod`** (not hardcoded): Best practice for the release workflow, matching `scaffold-go-cli` convention.

1. **Latest action versions** (`@v6` for checkout, setup-go, goreleaser-action): Consistent with the most recent reference repo configs.

## Implementation Order

Implement in this order, committing at each logical boundary:

1. Create `plugin.json`
1. Create reference files (`goreleaser.md`, `release-workflow.md`, `makefile-target.md`, `conditional-features.md`)
1. Create `SKILL.md`
1. Update `marketplace.json`
1. Update `README.md`
1. Update `CLAUDE.md`

## Verification

1. Run `/check-versions` to verify version consistency between `plugin.json` and `marketplace.json`
1. Run `/lint-and-fix` to check formatting
1. Verify alphabetical ordering in marketplace.json, README ToC, README descriptions, and CLAUDE.md tree
1. Verify all placeholder names are consistent across templates (`PROJECT-NAME`, `GITHUB-USERNAME`, etc.)
1. Verify YAML templates are syntactically valid

Attribution

cboonecboone
View sourceSee grades on GitHubMore from cboone →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Clean Code

Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments

304955 votes

Browser Extension Developer

Use this skill when developing or maintaining browser extension code in the `browser/` directory, including Chrome/Firefox/Edge compatibility, content scripts, background scripts, or i18n updates.

286712 votes

Seo Optimizer

SEO optimization with keyword analysis, readability assessment, technical validation, content quality. Use for search rankings, blog posts, content audits, or encountering keyword density, readability scores, meta tags, schema markup errors.

2222 votes

Google Official Seo Guide

Official Google SEO guide covering search optimization, best practices, Search Console, crawling, indexing, and improving website search visibility based on official Google documentation

1862 votes

Writing Plans

Use when you have a spec or requirements for a multi-step task, before touching code

2927051 votes
View all in development →