Release Skill

A thin, repo-aware release assistant. On first run it inspects the project and CI to derive release rules, stores them in .omc/RELEASE_RULE.md for future use, then walks you through a release using those rules.

Usage

/oh-my-claudecode:release [version]

• version is optional. If omitted the skill will ask. Accepts patch, minor, major, or an explicit semver like 2.4.0.
• Add --refresh to force re-analysis of the repo even when a cached rule file exists.

Execution Flow

Step 0, Load or Build Release Rules

Check whether .omc/RELEASE_RULE.md exists.

If it does NOT exist (or --refresh was passed): Run the full repo analysis below and write the file.

If it DOES exist: Read the file. Then do a quick delta check, scan .github/workflows/ (or equivalent CI dirs: .circleci/, .travis.yml, Jenkinsfile, bitbucket-pipelines.yml, gitlab-ci.yml) for any modifications newer than the last-analyzed timestamp in the rule file. If relevant workflow files changed, re-run the analysis for those sections and update the file. Report what changed.

---

Step 1, Repo Analysis (first run or --refresh)

Inspect the repo and answer the following. Write answers into .omc/RELEASE_RULE.md.

1a. Version Sources

• Locate all files that contain a version string matching the current version in package.json / pyproject.toml / Cargo.toml / build.gradle / VERSION file / etc.
• List each file and the field or regex pattern used to find the version.
• Detect whether there is a release automation script (e.g. scripts/release.*, Makefile release target, bump2version, release-it, semantic-release, changesets, goreleaser).

1b. Registry / Distribution