AgentStack
SKILL verified MIT Self-run

Release Please

skill-aaronflorey-agent-skills-release-please · by aaronflorey

Set up `release-please` for automated releases in a repository. Use this skill when the user mentions release-please, `googleapis/release-please-action`, release PRs, conventional commits, `release-please-config.json`, `.release-please-manifest.json`, GitHub Actions release automation, or wants to bootstrap or debug release-please in a new or existing repo.

No reviews yet
0 installs
6 views
0.0% view→install

Install

$ agentstack add skill-aaronflorey-agent-skills-release-please

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Release Please? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Setting Up Release-Please

This skill guides you through setting up release-please in a repository.

Before You Start

Ask the user (if not clear from context):

  1. What language/framework? (determines release-type)
  2. Single package or monorepo?
  3. Current version of the package(s)?

Setup Steps

1. Create GitHub Actions Workflow

Create .github/workflows/release-please.yml:

on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

name: release-please

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
        with:
          release-type:   # See references/release-types.md

Unified release-please + GoReleaser workflow (recommended when both are used)

If the project uses both release-please and GoReleaser, prefer a single workflow file. Run release-please first, then run GoReleaser only when release_created is true.

This avoids the common PAT workaround. You do not need a custom RELEASE_PLEASE_TOKEN just to trigger a second workflow for GoReleaser.

For the canonical recipe, see references/release-please-goreleaser-unified-workflow.md.

name: release-please

on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write
  packages: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    outputs:
      release_created: ${{ steps.release.outputs.release_created }}
      tag_name: ${{ steps.release.outputs.tag_name }}
    steps:
      - id: release
        uses: googleapis/release-please-action@v4
        with:
          release-type: 

  goreleaser:
    needs: release-please
    if: ${{ needs.release-please.outputs.release_created == 'true' }}
    runs-on: ubuntu-latest
    permissions:
      contents: write
      packages: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ needs.release-please.outputs.tag_name }}
      - uses: actions/setup-go@v5
        with:
          go-version-file: go.mod
      - uses: goreleaser/goreleaser-action@v6
        with:
          version: latest
          args: release --clean
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

If the user needs CI to run on release PRs (common), they need a PAT for that PR-triggering behavior:

        with:
          token: ${{ secrets.RELEASE_PLEASE_TOKEN }}

Do not use this PAT requirement as the default fix for release-please + GoReleaser integration. Prefer the unified single-workflow pattern above.

2. Create Config Files (for advanced setups)

For monorepos or custom config, create manifest files instead of using release-type input.

release-please-config.json:

{
  "packages": {
    ".": {
      "release-type": ""
    }
  }
}

\.release-please-manifest.json:

{
  ".": ""
}

Then update the workflow to omit release-type:

- uses: googleapis/release-please-action@v4
  with:
    token: ${{ secrets.RELEASE_PLEASE_TOKEN }}

3. Bootstrap Existing Repository

For repos with existing releases, set the current version in .release-please-manifest.json to match the latest release tag.

If there's extensive commit history, add bootstrap-sha to config to limit changelog scope:

{
  "bootstrap-sha": "",
  "packages": { ... }
}

Common Setup Patterns

Node.js Package

  • release-type: node
  • Updates package.json and CHANGELOG.md

Python Package

  • release-type: python
  • Updates pyproject.toml/setup.py and CHANGELOG.md

Go Module

  • release-type: go
  • Updates CHANGELOG.md only (version from tags)

Monorepo

  • Use manifest config with multiple packages
  • Consider node-workspace or cargo-workspace plugins
  • See references/manifest-config.md

Post-Setup Checklist

Tell the user:

  1. Commit and push the new files
  2. Start using conventional commits: feat:, fix:, feat!:
  3. Use squash-merge for PRs (cleaner changelogs)
  4. Release-please will create a Release PR after releasable commits
  5. Merge the Release PR to create the GitHub release

Reference Files

Read these for detailed options:

  • references/release-types.md - All supported languages
  • references/github-actions.md - Action inputs, outputs, examples
  • references/manifest-config.md - Full config options, plugins, monorepos
  • references/release-please-goreleaser-unified-workflow.md - Canonical combined setup for release-please + GoReleaser

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.