Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed β fix this file immediately, don't defer. Only update for real, reproducible issues.
Confirm successful installation by checking the skill directory location:
.cursor/skills/semantic-release
Restart Cursor to activate semantic-release. Access via /semantic-release in your agent's command palette.
β
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed β fix this file immediately, don't defer. Only update for real, reproducible issues.
Overview
Automate semantic versioning and release management using semantic-release v25+ (Node.js) following 2025 best practices. Works with all languages (JavaScript, TypeScript, Python, Rust, Go, C++, etc.) via the @semantic-release/exec plugin. Create shareable configurations for multi-repository setups, initialize individual projects with automated releases, and configure GitHub Actions workflows with OIDC trusted publishing.
Important: This skill uses semantic-release (Node.js) exclusively, NOT python-semantic-release, even for Python projects. Rationale: 23.5x larger community, 100x+ adoption, better future-proofing.
When to Use This Skill
Invoke when:
Setting up local releases for a new project (any language)
Creating shareable semantic-release configuration for organization-wide use
Migrating existing projects to 2025 semantic-release patterns
Troubleshooting semantic-release setup or version bumps
Setting up Python projects (use Node.js semantic-release, NOT python-semantic-release)
Configuring GitHub Actions (optional backup, not recommended as primary due to speed)
22,900 GitHub stars - Large, active community
1.9M weekly downloads - Proven adoption
126,000 projects using it - Battle-tested at scale
35+ official plugins - Rich ecosystem
Multi-language support - Works with any language via @semantic-release/exec
Do NOT use python-semantic-release. It has a 23.5x smaller community (975 vs 22,900 stars), ~100x less adoption, and is not affiliated with the semantic-release organization.
Release Workflow Philosophy: Local-First
Default approach: Run releases locally, not via GitHub Actions.
Why Local Releases
Primary argument: GitHub Actions is slow
β±οΈ GitHub Actions: 2-5 minute wait for release to complete
β‘ Local release: Instant feedback and file updates
π Immediate workflow continuity - no waiting for CI/CD
# .releaserc.ymlplugins:--"@semantic-release/commit-analyzer"-releaseRules:# Marketplace plugins require version bump for ANY change-{type:"docs",release:"patch"}-{type:"chore",release:"patch"}-{type:"style",release:"patch"}-{type:"refactor",release:"patch"}-{type:"test",release:"patch"}-{type:"build",release:"patch"}-{type:"ci",release:"patch"}
Why marketplace plugins need this: Plugin updates are distributed via version tags. Without a version bump, users running /plugin update see no changes even if content was modified.
MANDATORY: Every Release Must Increment Version
Pre-release validation: Before running semantic-release, verify releasable commits exist since last tag. A release without version increment is invalid.
Autonomous check sequence:
List commits since last tag: compare HEAD against latest version tag
Identify commit types: scan for feat:, fix:, or BREAKING CHANGE: prefixes
If NO releasable commits found β STOP - do not proceed with release
Inform user: "No version-bumping commits since last release. Use feat: or fix: prefix for releasable changes."
Commit type selection guidance:
Use fix: for any change that improves existing behavior (bug fixes, enhancements, documentation corrections that affect usage)
Use feat: for new capabilities or significant additions
Reserve chore:, docs:, refactor: for changes that truly don't warrant a release
Why this matters: A release without version increment creates confusion - users cannot distinguish between releases, package managers may cache old versions, and changelog entries become meaningless.
MAJOR Version Breaking Change Confirmation
Trigger: BREAKING CHANGE: footer or feat!: / fix!: prefix in commits.
When MAJOR is detected, this skill runs a 3-phase confirmation workflow:
Detection: Scan commits for breaking change markers
Analysis: Spawn 3 parallel subagents (User Impact, API Compat, Migration)
Confirmation: AskUserQuestion with proceed/downgrade/abort options
See MAJOR Confirmation Workflow for complete details including subagent prompts, decision tree, and example output.
Examples
Feature (MINOR):
feat: add BigQuery data source support
Bug Fix (PATCH):
fix: correct timestamp parsing for UTC offsets
Breaking Change (MAJOR):
feat!: change API to require authentication
BREAKING CHANGE: All API calls now require API key in Authorization header.
Documentation Linking
Auto-include doc changes in release notes. Add to .releaserc.yml:
./scripts/init-project.mjs --project# Initialize current project./scripts/init-project.mjs --user# Create user-level shareable config./scripts/init-project.mjs --help# See all options
βΊAccess to product documentation and roadmap tools (Jira, Notion, etc.)
βΊUnderstanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
βΊStakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
β Not validating competitive researchβverify facts before sharing
β Accepting user stories without involving engineering team
β Over-relying on frameworks without qualitative judgment
β Not customizing outputs to company culture and communication style
β Skipping stakeholder validation of generated requirements
Best Practices
β Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
β Don't
βDon't publish competitive analysis without fact-checking
βDon't finalize user stories without engineering review
βDon't make prioritization decisions solely on AI scoring
βDon't skip customer validation of generated requirements
βDon't ignore company-specific context and culture
π‘ Pro Tips
β Provide context: company goals, constraints, customer feedback
β Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
β Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
β Use skill for 70% generation + 30% customization to company needs
When to Use This
β Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
β Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates