How do I install the Cc Switch Release skill?

Run npx skillmds@latest add cp-yu/cc-switch-release in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Cc Switch Release safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Cc Switch Release?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Cc Switch Release free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Cc Switch Release?

cp-yu (@cp-yu) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Cc Switch Release by cp-yu — Agent Skill

Name: Cc Switch Release
Rating: 4.2 (5 reviews)
Author: cp-yu

Cc Switch Release

Manage version sync, release commits, tags, pushes, and post-release verification for the cc-switch fork. Use when the user asks to bump or align versions, cut a new release, create or push a tag, verify GitHub Actions or Releases, or troubleshoot why a build artifact did not appear in the release for this repository.

cp-yu Updated Sep 9, 2026

File contents

CC Switch Release

Use this skill for repo-specific release work in cc-switch.

Core Rules

Treat origin as the release repo: cp-yu/cc-switch-web.
Treat upstream as the source mirror. Do not use it for release verification unless the user explicitly asks.
Pass -R cp-yu/cc-switch-web to gh when checking Actions or Releases. The default gh repo may point elsewhere.
Treat official GitHub Releases as Web-only. Build Web Release runs on tag push. Desktop Release (Manual) is manual only.
Keep version fields aligned in:
- package.json
- src-tauri/Cargo.toml
- src-tauri/tauri.conf.json
Prefer scripts/release-manager.mjs over hand-editing version files when the task is version sync or release cutting.

Standard Workflow

Inspect repo state first. Run git status --short --branch, git log --oneline --decorate -5, and if needed read references/release-facts.md.
Decide the operation. Use sync when the user only wants version fields updated. Use release when the user wants commit + tag + optional push.
Preserve user intent in the index. Do not auto-stage unrelated files. If releasing, require the intended code changes to be staged before calling the release tool.
Run the repo helper. Version sync only: pnpm release:sync-version -- <version> Full release: pnpm release:cut -- <version> --push
Verify the result. Confirm git status is clean, HEAD/tag moved as expected, and version values match. For remote verification, use: gh -R cp-yu/cc-switch-web run list --limit 5 gh -R cp-yu/cc-switch-web release view v<version> --json tagName,name,publishedAt,url,assets

Failure Handling

If release-manager.mjs rejects the worktree, fix staging hygiene instead of bypassing the check.
If a tag already exists remotely, do not rewrite it unless the user explicitly asks for destructive history changes.
If Actions succeeded but a release is missing, verify the run and release against cp-yu/cc-switch-web, not the upstream repo.
If the task involves changing release behavior itself, edit the workflow or helper script first, then cut a new tag.

Resources

Read references/release-facts.md when you need the exact repo/remotes/workflow/version-file map.

---name: cc-switch-releasedescription: Manage version sync, release commits, tags, pushes, and post-release verification for the cc-switch fork. Use when the user asks to bump or align versions, cut a new release, create or push a tag, verify GitHub Actions or Releases, or troubleshoot why a build artifact did not appear in the release for this repository.--- # CC Switch Release Use this skill for repo-specific release work in `cc-switch`. ## Core Rules - Treat `origin` as the release repo: `cp-yu/cc-switch-web`. - Treat `upstream` as the source mirror. Do not use it for release verification unless the user explicitly asks. - Pass `-R cp-yu/cc-switch-web` to `gh` when checking Actions or Releases. The default `gh` repo may point elsewhere. - Treat official GitHub Releases as Web-only. `Build Web Release` runs on tag push. `Desktop Release (Manual)` is manual only. - Keep version fields aligned in: - `package.json` - `src-tauri/Cargo.toml` - `src-tauri/tauri.conf.json` - Prefer `scripts/release-manager.mjs` over hand-editing version files when the task is version sync or release cutting. ## Standard Workflow 1. Inspect repo state first. Run `git status --short --branch`, `git log --oneline --decorate -5`, and if needed read [references/release-facts.md](references/release-facts.md). 2. Decide the operation. Use `sync` when the user only wants version fields updated. Use `release` when the user wants commit + tag + optional push. 3. Preserve user intent in the index. Do not auto-stage unrelated files. If releasing, require the intended code changes to be staged before calling the release tool. 4. Run the repo helper. Version sync only: `pnpm release:sync-version -- <version>` Full release: `pnpm release:cut -- <version> --push` 5. Verify the result. Confirm `git status` is clean, HEAD/tag moved as expected, and version values match. For remote verification, use: `gh -R cp-yu/cc-switch-web run list --limit 5` `gh -R cp-yu/cc-switch-web release view v<version> --json tagName,name,publishedAt,url,assets` ## Failure Handling - If `release-manager.mjs` rejects the worktree, fix staging hygiene instead of bypassing the check. - If a tag already exists remotely, do not rewrite it unless the user explicitly asks for destructive history changes. - If Actions succeeded but a release is missing, verify the run and release against `cp-yu/cc-switch-web`, not the upstream repo. - If the task involves changing release behavior itself, edit the workflow or helper script first, then cut a new tag. ## Resources - Read [references/release-facts.md](references/release-facts.md) when you need the exact repo/remotes/workflow/version-file map.

Frequently asked questions