Semantic Versioning

Version 0.1.1.

Help agents assess changes throughout development, maintain native release intent, configure release PRs and verify publication. This package is independent: no MCP server, daemon, telemetry, hooks, or other plugin is required. Helpers require Python 3.11+; native build/release tools are needed only for the selected project.

Try it in Codex

Choose a skill or use one of these starter requests.

Skill	What it helps with	Starter request
Semantic Versioning	Assess changes and reconcile release intent	Assess the release impact of my current changes.
Configure Releases	Set up version ownership and release automation	Configure release PRs and publishing for this project.
Verify Release	Check release consistency and recover publication	Verify this release and identify any incomplete publication.

Start here

Assess code changes: release units, contracts, cumulative impact and correct version ownership.
Configure releases: native automation, CI examples and scoped migrations.
Verify or recover a release: exact source/package identity, remote state and consumer checks.

Load the skill and only its relevant references. Each skill stays below 900 words. Opt-in repository instructions help make assessment part of coding work; installation alone cannot guarantee invocation.

Read-only tools

From this package directory:

python3 scripts/inspect_repository.py /path/to/project --json
python3 scripts/inspect_repository.py /path/to/project --scope packages/library
python3 scripts/check_version.py validate 1.2.3 2.0.0-rc.1
python3 scripts/check_version.py compare 1.2.3 1.3.0
python3 scripts/check_version.py check 1.2.3 1.3.0 --impact minor --json

Both tools emit schema_version 1 JSON with --json. Exit 0 means success; 1 means a failed contract check; 2 means invalid input or an operational error. Discovery reports candidate evidence and unresolved dynamic configuration; it does not execute project files, fetch Git history, install dependencies, or decide semantic impact. Version checks implement SemVer arithmetic, not ecosystem range resolution or ABI analysis. A prerelease baseline permits only same-core iteration or promotion; assess new cumulative impact against the preceding stable baseline.

Git status remains unresolved when clean/process filters are configured, because comparison could execute project code. Status excludes nested submodule worktrees; inspect each submodule release unit separately. Discovery disables Git lazy fetching and transport access, and leaves unavailable evidence unresolved.

Reference library

Core rules, release architectures, recovery, and policy worksheet separate general decisions from ecosystem detail.

Ecosystem	Guide	Examples
JS/TS	JavaScript	Projects
Python	Python	Projects
Rust	Rust	Workspace
Go	Go	Module
Java/Kotlin	JVM	Projects
.NET	.NET	Project
Swift/mobile	Mobile	Definitions
C/C++	C/C++	Definitions
Ruby/PHP	Ruby/PHP	Definitions
OCI/Helm/plugins	Distribution	Definitions

GitHub CI guide explains inactive workflow templates and their prerequisites. Consumer workflows must be deliberately installed and configured under authority; nothing here publishes this marketplace automatically.

Evidence and maintenance

Run repository plugin, distribution and marketplace validators and the semantic-versioning test suite. See the repository validation report for actual commands and limitations. Every template must distinguish static/native validation from hosted publication. Refresh source links, action pins and tool compatibility together when changing recipes. Never claim support for an untested tool version from a current URL alone.

The public contract includes skill responsibilities, helper CLI/JSON behavior, and documented template behavior. Follow SemVer for changes to that contract. Release identity is semantic-versioning-v0.1.1. Install with codex plugin add semantic-versioning@sealad886-codex-marketplace after adding this marketplace. Publishing from the example workflows requires project-specific configuration and authorization.