adaptive-enforcement-lab/release-please-configuration
plugins/build/skills/release-please-configuration/SKILL.md
Configure automated versioning with release-please. Set up semantic versioning, changelog generation, and monorepo support using GitHub App token authentication.
documentation
Updated Mar 27, 2026
$ install --global
skillsauthnpx skillsauth add adaptive-enforcement-lab/claude-skills release-please-configurationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Mar 29, 2026, 8:35 AM37.1s1 file scanned
SKILL.md
- name:
- release-please-configuration
- description:
- >-
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
- Source Documentation
- AEL Build
Related Skills
adaptive-enforcement-lab/workload-identity-federation-implementation
documentation
VerifiedTrustedCommunity
Workload Identity Federation implementation guide. GKE setup, IAM bindings, ServiceAccount configuration, migration from service account keys, and troubleshooting patterns.
SKILL.mdUpdated Mar 27, 2026
adaptive-enforcement-lab/workflow-trigger-security
development
VerifiedTrustedCommunity
Secure GitHub Actions trigger patterns for pull requests, forks, and reusable workflows. Preventing privilege escalation and code injection through trigger misconfiguration.
SKILL.mdUpdated Mar 27, 2026
adaptive-enforcement-lab/third-party-action-risk-assessment
development
VerifiedTrustedCommunity
Structured framework for evaluating GitHub Actions security before adoption. Trust tiers, risk assessment checklist, and decision tree for action evaluation.
SKILL.mdUpdated Mar 27, 2026
adaptive-enforcement-lab/storing-credentials
testing
VerifiedTrustedCommunity
Securely store GitHub App credentials across different environments. GitHub Actions secrets, external CI, Kubernetes, and automated rotation patterns.
SKILL.mdUpdated Mar 27, 2026