القائمة
Semantic Versioning 2.0.0 guidelines for SWPM. Defines version increment rules and activates when user modifies CHANGELOG.md or updates version in package.json.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Automated code review bash script for SWPM. Checks typing standards (type vs interface, no any), naming conventions, file structure, export patterns, and project constraints. Invoke via executable script.
Conventional Commits 1.0.0 specification for SWPM. Defines commit message format with types (feat, fix, etc.), scopes, breaking changes, and body/footer conventions. Activates when writing commit messages or modifying git commits.
Development guide for setting up, debugging, and testing SWPM locally. Includes project structure, build commands, testing, and common development tasks.
Keep a Changelog 1.1.0 standards for SWPM. Defines format, sections, and conventions for CHANGELOG.md entries. Activates when user modifies CHANGELOG.md.
Manage cmds and args props in SWPM package manager configs (src/packages/managers/*.ts), including adding, modifying or removing command and argument mappings across npm, yarn, pnpm, bun, deno. Includes internal templates and real-world examples.
Automated release bash script for SWPM. Updates version in package.json, moves `[Unreleased]` entries to new version section in CHANGELOG.md, and follows SemVer and Keep a Changelog standards. Analyzes commits to suggest version bump or accepts manual version argument.
| name | swpm-semver |
| id | swpm-semver |
| version | 1.0.0 |
| tags | ["swpm","semver","versioning","release","changelog"] |
| description | Semantic Versioning 2.0.0 guidelines for SWPM. Defines version increment rules and activates when user modifies CHANGELOG.md or updates version in package.json. |
Use this skill when questions arise about version numbering, when to increment versions, release planning, or when modifying CHANGELOG.md for SWPM.
Given a version number MAJOR.MINOR.PATCH:
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Check package.json for current version:
{
"version": "2.6.0"
}
Example: 2.6.0 → 2.6.1
Example: 2.6.0 → 2.7.0
Example: 2.6.0 → 3.0.0
For testing before stable release:
2.7.0-alpha
2.7.0-alpha.1
2.7.0-beta
2.7.0-rc.1
Pre-release versions have lower precedence than the associated normal version.
Build metadata is ignored when determining version precedence:
2.6.0+build.123
2.6.0-beta+build.456
Both are equivalent to 2.6.0 for precedence.
Compare versions from left to right:
1.0.0 < 2.0.0 < 2.1.0 < 2.1.1
1.0.0-alpha < 1.0.0
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta
SWPM is already at version 2.x.x, so this doesn't apply. However, for reference:
0.y.z is for initial developmentBefore releasing a new version:
package.jsonCHANGELOG.md with changes following Keep a Changelog format:
YYYY-MM-DD date format (not slashes)### Added, ### Changed, ### Deprecated, ### Removed, ### Fixed, ### Security- Description of changenpm run build to verify build worksnpm run test to verify no regressionsgit tag v2.x.xgit push origin v2.x.xSWPM follows Keep a Changelog 1.0.0:
## [2.6.0] - 2023-12-26
### Changed
- Revert the `--location=global` flag translation on npm
### Updated
- Bump package versions
### Added - for new features### Changed - for changes in existing functionality### Deprecated - for once-stable features removed in upcoming releases### Removed - for deprecated features removed in this release### Fixed - for any bug fixes### Security - to invite users to upgrade in case of vulnerabilities2023-12-26 (YYYY-MM-DD with hyphens)2023/12/26 (slashes)Q: "I fixed a bug, what version should I release?"
A: Increment PATCH version (e.g., 2.6.0 → 2.6.1)
Q: "I added a new command, what version should I release?"
A: Increment MINOR version (e.g., 2.6.0 → 2.7.0)
Q: "I removed a command, what version should I release?"
A: Increment MAJOR version (e.g., 2.6.0 → 3.0.0)
Q: "Can I release 2.6.0-alpha?"
A: Yes, use pre-release tags for testing: 2.7.0-alpha, 2.7.0-beta, etc.
Q: "What's the difference between 2.6.0+build.1 and 2.6.0+build.2?"
A: Build metadata is ignored for precedence, both are equivalent to 2.6.0
Before answering versioning questions:
package.jsonCHANGELOG.md for recent changes and format complianceFull SemVer 2.0.0 specification: https://semver.org/