versioning-rules

Enforces semantic versioning, branch naming, and release checklists for git-based software projects.

Updated Jul 13, 2026
One-click install
npx skills add https://github.com/Ohmnia/site-build --skill versioning-rules-ohmnia
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: versioning-rules
Source: https://github.com/Ohmnia/site-build/tree/main/.opencode/skills/versioning-rules
Command: npx skills add https://github.com/Ohmnia/site-build --skill versioning-rules-ohmnia

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often release software with inconsistent version numbers, mismatched version strings across files, and unclear branch conventions. This Skill standardizes how AI agents manage git branches, semantic versions, and release declarations so every release follows the same rules. ## Core Features & Use Cases - Semantic Versioning Rules: Defines when to increment MAJOR, MINOR, or PATCH versions with concrete examples for features, fixes, and releases. - Version Consistency Enforcement: Requires package.json, index.html, README.md, and git tags to always match, with git tags as the single source of truth. - Branch and Release Governance: Mandates feature/<name> and fix/<name> branch patterns, forbids direct work on main, and requires a release type declaration plus a pre-release checklist. - Use Case: Before merging a new audio system, the agent creates feature/audio-system, declares Release Type: MINOR, bumps v0.3.5 to v0.4.0 across all version files, creates the git tag, and completes the release checklist. ## Quick Start Ask the agent to create a new release branch and bump the project version following the versioning rules before opening a merge request.

Frequently Asked Questions about versioning-rules

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide between a MAJOR, MINOR, or PATCH version bump?

Increment MAJOR for significant public releases, MINOR for new functionality like systems or features, and PATCH for fixes, refactoring, or tuning. When MINOR increases, PATCH resets to zero, such as v0.3.5 becoming v0.4.0.

How to keep version numbers consistent across project files?

Treat the git tag as the single source of truth and make package.json, index.html, and README.md match it exactly. Before any release, verify all three files report the same version as the tag.

What branch naming convention should AI agents use for features and fixes?

Use feature/<feature-name> for new functionality and fix/<issue-name> for bug fixes, such as feature/audio-system or fix/camera-jitter. Agents must never work directly on main or origin/main.

What must be declared before opening a merge request?

The agent must state the Release Type (PATCH, MINOR, or MAJOR) and a short reason explaining the change. It must also complete the release checklist covering tests, build, version increment, git tag, and updated version files.

When should PATCH not be used for a release?

PATCH should not be used when the change introduces new functionality such as a new system, menu, world, or content pipeline. Those changes require a MINOR bump, while PATCH is reserved for fixes, optimization, and documentation updates.