菜单
Release process for mdvs. Use when the user asks to make a release (patch, minor, major, or release candidate).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | release |
| description | Release process for mdvs. Use when the user asks to make a release (patch, minor, major, or release candidate). |
Releases go through a branch + PR (because main is protected), then a tag push triggers the GitHub Actions release workflow (cargo-dist) that builds cross-platform binaries and creates a GitHub Release.
Before releasing, verify:
cargo test
cargo clippy -- -D warnings
cargo fmt --check
git checkout main && git pull
git status # must be clean
git log --oneline -5 # review recent commits
gh run list --limit 1
git checkout -b release/v<version> main
Use cog bump with --skip-push (since we can't push directly to main):
cog bump --<level> --skip-push # or --auto --skip-push
This will:
Cargo.tomlCHANGELOG.md from conventional commitsv<new_version>If cog bump doesn't support --skip-push, do it manually:
Cargo.toml version fieldcog changelog > CHANGELOG.md (or update manually)git commit -am "chore(release): v<version>"git push -u origin release/v<version>
gh pr create --title "chore(release): v<version>" --body "Version bump and changelog for v<version>"
Wait for CI to pass, then merge the PR.
After the PR is merged, tag main and push the tag:
git checkout main && git pull
git tag v<version>
git push origin v<version>
The tag push triggers .github/workflows/release.yml, which builds binaries for macOS, Linux, and Windows, and creates a GitHub Release.
| Level | Example | Use case |
|---|---|---|
--patch | 0.1.0 → 0.1.1 | Bug fixes |
--minor | 0.1.0 → 0.2.0 | New features |
--major | 0.1.0 → 1.0.0 | Breaking changes |
--minor --pre rc | 0.1.0 → 0.2.0-rc.1 | Release candidate |
--auto | (auto-detected) | Let commits decide |
gh run list --limit 1 # find the run ID
gh run watch <run-id> --exit-status # live follow
If a build fails:
gh run view --job=<job-id> --log-failed
After success, verify the GitHub Release:
gh release view v<version>
cog.toml — cocogitto config (tag prefix, bump hooks, changelog, commit validation)Cargo.toml — version field, [package.metadata.dist].github/workflows/release.yml — auto-generated by dist generate, do not hand-editpublish = false — no crates.io publishing. Releases are GitHub-only for now.v{version} (e.g., v0.1.0), configured by tag_prefix = "v" in cog.toml.v0.1.0-rc.1) create a GitHub Release marked as prerelease.--auto reads commits since last tag: feat: → minor, fix: → patch, BREAKING CHANGE → major.dist generateUse `mdvs search` for any content lookup in a markdown directory — semantic / hybrid / SQL-filtered, beats Grep / Glob for finding by meaning. `mdvs init` infers a schema from existing markdown, `mdvs check` validates frontmatter, `mdvs update` evolves the schema as the KB grows. Activate whenever the project contains markdown with frontmatter, whether or not `mdvs.toml` exists yet.
Use when the user asks to commit, commit and push, or make a git commit. Covers branching, commit workflow, conventional commits, TODO updates, and push/PR rules.
Use when writing, modifying, or removing Rust code in the mdvs codebase. Covers implementation workflow, testing, verification, and downstream updates (specs, example_kb, mdbook).
mdBook documentation conventions. Apply when writing, editing, or reviewing pages in book/src/. Covers content rules, example verification, tone, and structure.
GitHub Issues + Project tracking. Use when creating, updating, or querying issues and managing the project board.
Rust coding conventions. Apply when writing, reviewing, or modifying Rust code. Covers error handling, types, ownership, testing, and anti-patterns.