Semantic versioning and changelog formatting for software releases. Use when: preparing releases, updating version numbers, writing changelogs. Keywords: version, release, changelog, semver, major, minor, patch, 版本, 發布, 變更日誌.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
This skill provides semantic versioning and changelog formatting standards.
MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD]
Examples:
2.3.1
1.0.0-alpha.1
3.2.0-beta.2+20250112
| Component | When to Increment | Example |
|---|---|---|
| MAJOR | Breaking changes | 1.9.5 → 2.0.0 |
| MINOR | New features (backward-compatible) | 2.3.5 → 2.4.0 |
| PATCH | Bug fixes (backward-compatible) | 3.1.2 → 3.1.3 |
| Identifier | Stability | Audience |
|---|---|---|
alpha | Unstable | Internal team |
beta | Mostly stable | Early adopters |
rc | Stable | Beta testers |
| Category | Usage |
|---|---|
| Added | New features |
| Changed | Changes in existing functionality |
| Deprecated | Soon to be removed |
| Removed | Removed features |
| Fixed | Bug fixes |
| Security | Vulnerability fixes |
For complete standards, see:
## [VERSION] - YYYY-MM-DD
### Added
- Add user dashboard with customizable widgets (#123)
### Changed
- **BREAKING**: Change API response format from XML to JSON
### Fixed
- Fix memory leak when processing large files (#456)
### Security
- Fix SQL injection vulnerability (CVE-2025-12345)
Mark breaking changes with BREAKING prefix:
### Changed
- **BREAKING**: Remove deprecated `getUserById()`, use `getUser()` instead
# Create annotated tag (recommended)
git tag -a v1.2.0 -m "Release version 1.2.0"
# Push tag to remote
git push origin v1.2.0
1.0.0-alpha.1 < 1.0.0-alpha.2 < 1.0.0-beta.1 < 1.0.0-rc.1 < 1.0.0
This skill supports project-specific configuration.
CONTRIBUTING.md for "Disabled Skills" section
CONTRIBUTING.md for "Release Standards" sectionIf no configuration found and context is unclear:
CONTRIBUTING.md:## Release Standards
### Versioning
This project uses **Semantic Versioning** (MAJOR.MINOR.PATCH).
### Changelog
This project follows **Keep a Changelog** format.
In project's CONTRIBUTING.md:
## Release Standards
### Versioning
This project uses **Semantic Versioning** (MAJOR.MINOR.PATCH).
### Changelog
This project follows **Keep a Changelog** format.
### Release Process
1. Update version in package.json
2. Update CHANGELOG.md
3. Create git tag with `v` prefix (e.g., v1.2.0)
4. Push tag to trigger release workflow
License: CC BY 4.0 | Source: universal-dev-standards
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Prevent AI hallucination and ensure evidence-based responses when analyzing code or making suggestions. Use when: analyzing code, making recommendations, providing options, or when user asks about confidence/certainty. Keywords: certainty, assumption, inference, evidence, source, 確定性, 推測, 假設, 來源, 證據.
The English summary is being prepared. Showing the original description.
Systematic code review checklist and pre-commit quality gates for PRs. Use when: reviewing pull requests, checking code quality, before committing code. Keywords: review, PR, pull request, checklist, quality, commit, 審查, 檢查, 簽入.
The English summary is being prepared. Showing the original description.
Format commit messages following conventional commits standard. Use when: writing commit messages, git commit, reviewing commit history. Keywords: commit, git, message, conventional, 提交, 訊息, feat, fix, refactor.
The English summary is being prepared. Showing the original description.
Guide documentation structure, README content, and project documentation best practices. Use when: creating README, documentation, docs folder, project setup. Keywords: README, docs, documentation, CONTRIBUTING, CHANGELOG, 文件, 說明文件.
The English summary is being prepared. Showing the original description.
Guide Git branching strategies, branch naming, and merge operations. Use when: creating branches, merging, pull requests, Git workflow questions. Keywords: branch, merge, PR, pull request, GitFlow, GitHub Flow, 分支, 合併, 工作流程.
The English summary is being prepared. Showing the original description.
Guide requirement writing, user story creation, and feature specification. Use when: writing requirements, user stories, issues, feature planning. Keywords: requirement, user story, issue, feature, specification, 需求, 功能規劃, 規格.
The English summary is being prepared. Showing the original description.