Agent skill
release-please-configuration
Configure automated versioning with release-please. Set up semantic versioning, changelog generation, and monorepo support using GitHub App token authentication.
Install this agent skill to your Project
npx add-skill https://github.com/adaptive-enforcement-lab/claude-skills/tree/main/plugins/build/skills/release-please-configuration
SKILL.md
Release-Please Configuration
When to Use This Skill
Release-please reads your commit history and:
- Groups changes by type (feat, fix, chore, etc.)
- Generates changelogs
- Bumps versions according to semantic versioning
- Creates pull requests for releases
- Tags releases when PRs merge
Implementation
Release-please automates version management based on conventional commits. It creates release PRs with updated changelogs, version bumps, and Git tags.
Schema Validation
Always include the
$schemaproperty in your config file. It catches invalid options immediately and saves debugging time.
Overview
Release-please reads your commit history and:
- Groups changes by type (feat, fix, chore, etc.)
- Generates changelogs
- Bumps versions according to semantic versioning
- Creates pull requests for releases
- Tags releases when PRs merge
Configuration Files
release-please-config.json
The main configuration file defines packages and their versioning behavior:
See examples.md for detailed code examples.
.release-please-manifest.json
Tracks current versions for each package:
{
"charts/my-app": "1.0.0",
"packages/backend": "1.0.0",
"packages/frontend": "1.0.0"
}
Configuration Options
Global Options
| Option | Description | Example |
|---|---|---|
include-v-in-tag |
Prefix tags with v |
true = v1.0.0, false = 1.0.0 |
tag-separator |
Separator between component and version | - = backend-1.0.0 |
separate-pull-requests |
Create one PR per component | Recommended for monorepos |
changelog-sections |
How to group commits in changelogs | See example above |
Package Options
| Option | Description | Values |
|---|---|---|
release-type |
Package ecosystem | node, helm, simple, python, go, etc. |
component |
Component name for tagging | Any string |
include-component-in-tag |
Include component in tag | true = backend-1.0.0 |
package-name |
Package name (for node, etc.) | Matches package.json name |
Schema Validation
Always validate configuration against the official schema:
{
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json"
}
This catches invalid options immediately. Options like release-name don't exist. The schema prevents wasted debugging time.
In This Section
- Release Types - Node, Helm, Simple, and changelog customization
- Extra-Files - Version tracking in arbitrary files
- Workflow Integration - GitHub Actions setup and outputs
- Troubleshooting - Common issues and solutions
Related
- Change Detection - Skip unnecessary builds
- Workflow Triggers - GITHUB_TOKEN compatibility
- Content Comparison - Skip version-only changes
References
- Release-please Action - GitHub Marketplace
- Release-please Repository - googleapis
- Manifest Releaser Documentation - Monorepo configuration
- Configuration Schema - JSON schema for validation
Overview
Release-please reads your commit history and:
- Groups changes by type (feat, fix, chore, etc.)
- Generates changelogs
- Bumps versions according to semantic versioning
- Creates pull requests for releases
- Tags releases when PRs merge
Configuration Files
release-please-config.json
The main configuration file defines packages and their versioning behavior:
See examples.md for detailed code examples.
.release-please-manifest.json
Tracks current versions for each package:
{
"charts/my-app": "1.0.0",
"packages/backend": "1.0.0",
"packages/frontend": "1.0.0"
}
Configuration Options
Global Options
| Option | Description | Example |
|---|---|---|
include-v-in-tag |
Prefix tags with v |
true = v1.0.0, false = 1.0.0 |
tag-separator |
Separator between component and version | - = backend-1.0.0 |
separate-pull-requests |
Create one PR per component | Recommended for monorepos |
changelog-sections |
How to group commits in changelogs | See example above |
Package Options
| Option | Description | Values |
|---|---|---|
release-type |
Package ecosystem | node, helm, simple, python, go, etc. |
component |
Component name for tagging | Any string |
include-component-in-tag |
Include component in tag | true = backend-1.0.0 |
package-name |
Package name (for node, etc.) | Matches package.json name |
Schema Validation
Always validate configuration against the official schema:
{
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json"
}
This catches invalid options immediately. Options like release-name don't exist. The schema prevents wasted debugging time.
In This Section
- Release Types - Node, Helm, Simple, and changelog customization
- Extra-Files - Version tracking in arbitrary files
- Workflow Integration - GitHub Actions setup and outputs
- Troubleshooting - Common issues and solutions
Related
- Change Detection - Skip unnecessary builds
- Workflow Triggers - GITHUB_TOKEN compatibility
- Content Comparison - Skip version-only changes
References
- Release-please Action - GitHub Marketplace
- Release-please Repository - googleapis
- Manifest Releaser Documentation - Monorepo configuration
- Configuration Schema - JSON schema for validation
Examples
See examples.md for code examples.
Related Patterns
- Change Detection
- Workflow Triggers
- Content Comparison
References
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
adaptive-enforcement-lab/claude-skills
github-token-permissions-overview
Understanding GITHUB_TOKEN scope, default permissions, and implementing least-privilege principle for GitHub Actions workflows.
adaptive-enforcement-lab/claude-skills
secure
Find and fix security issues before they become incidents. Vulnerability scanning, SBOM generation, supply chain security, and secure authentication workflows.
adaptive-enforcement-lab/claude-skills
complete-workflow-examples
Copy-paste hardened CI/CD workflows with SHA-pinned actions, minimal GITHUB_TOKEN permissions, OIDC authentication, and comprehensive security scanning for GitHub Actions.
adaptive-enforcement-lab/claude-skills
ephemeral-runner-patterns
Disposable runner patterns for GitHub Actions. Container-based, VM-based, and ARC deployment strategies with complete state isolation between jobs.
adaptive-enforcement-lab/claude-skills
action-pinning-overview
Why pinning GitHub Actions to SHA-256 commits matters for supply chain security. Attack vectors from unpinned actions and comparison of tag vs SHA pinning.
adaptive-enforcement-lab/claude-skills
github-actions-security-patterns-hub
Complete security patterns for GitHub Actions covering action pinning, GITHUB_TOKEN permissions, third-party action risks, secret management, and runner security.
Didn't find tool you were looking for?