釋出技能
一個輕量、感知專案的釋出輔助工具。首次執行時會檢查專案與 CI 以推導釋出規則，將其儲存在 .omc/RELEASE_RULE.md 供後續使用，然後依照這些規則逐步引導你完成釋出。
使用方式
/oh-my-claudecode:release [version]
version為選填。若省略，技能會詢問你。接受patch、minor、major或明確的 semver 版本，例如2.4.0。- 加上
--refresh可強制重新分析專案，即使已有快取的規則檔。
執行流程
步驟 0 — 載入或建立釋出規則
檢查 .omc/RELEASE_RULE.md 是否存在。
如果不存在（或已傳入 --refresh）： 執行下列完整的專案分析，然後寫入該檔案。
如果存在： 讀取該檔案。接著進行快速差異檢查 — 掃描 .github/workflows/（或同等 CI 目錄：.circleci/、.travis.yml、Jenkinsfile、bitbucket-pipelines.yml、gitlab-ci.yml）中是否有任何修改時間晚於規則檔中的 last-analyzed 時間戳記。如果相關的工作流程檔案有變更，則重新分析那些部分並更新檔案。回報有哪些變更。
步驟 1 — 專案分析（首次執行或 --refresh）
檢查專案並回答以下問題。將答案寫入 .omc/RELEASE_RULE.md。
1a. 版本來源
- 找出所有包含與目前版本相符版本字串的檔案（
package.json/pyproject.toml/Cargo.toml/build.gradle/VERSION檔案等）。 - 列出每個檔案以及用來尋找版本的欄位或正規表示式模式。
- 偵測是否有釋出自動化腳本（例如
scripts/release.*、Makefile release目標、bump2version、release-it、semantic-release、changesets、goreleaser）。
1b. 註冊 / 散佈
- npm（
package.json含publishConfig或 CI 中的npm publish）、PyPI（pyproject.toml+twine/flit）、Cargo（Cargo.toml）、Docker（Dockerfile+ push 步驟）、GitHub Packages、其他。 - 是否有 CI 步驟會在標籤推送時自動發布？是哪個工作流程檔案和工作？
1c. 釋出觸發條件
- 識別什麼會啟動釋出：標籤推送（
v*）、手動觸發（workflow_dispatch）、合併到 main/master、合併到釋出分支、提交訊息模式。
1d. 測試關卡
- 識別測試指令以及在 CI 中何處執行。
- 測試是否必須在發布前通過？註明任何跳過標誌。
1e. 釋出備註 / 更新日誌
- 是否存在
CHANGELOG.md或CHANGELOG.rst？ - 使用什麼慣例：Keep a Changelog、Conventional Commits、GitHub 自動產生、無？
- 是否有在標籤前就已提交的釋出內容檔案（例如
.github/release-body.md）？
1f. 初次使用者檢查
- 釋出工作流程是否存在於
.github/workflows/（或同等位置）？如果沒有，標記並提議建立一個骨架。 - 是否有
.gitignore項目阻止建置成品被提交？如果沒有，標記。 - 是否使用了 git 標籤？執行
git tag --list檢查。如果沒有標籤，標記並解釋最佳實踐。
步驟 2 — 寫入 .omc/RELEASE_RULE.md
建立或覆寫該檔案，結構如下：
# 釋出規則
<!-- last-analyzed: YYYY-MM-DDTHH:MM:SSZ -->
## 版本來源
<!-- 檔案 + 模式列表 -->
## 釋出觸發條件
<!-- 什麼會啟動釋出 -->
## 測試關卡
<!-- 指令 + CI 工作名稱 -->
## 註冊 / 散佈
<!-- npm、PyPI、Docker 等 + 發布的 CI 工作 -->
## 釋出備註策略
<!-- 慣例 + 檔案 -->
## CI 工作流程檔案
<!-- 相關工作流程檔案的路徑 -->
## 首次設定缺口
<!-- 分析時發現的任何缺少項目，或「無」 -->
步驟 3 — 決定版本
如果使用者提供了版本引數，則使用它。否則：
- 顯示目前版本（來自主要版本檔案）。
- 顯示
patch、minor、major會產生的版本。 - 詢問使用者要使用哪一個。
驗證所選版本是否為有效的 semver 字串。
步驟 4 — 釋出前核對清單
根據釋出規則呈現一份核對清單。至少應包含：
- 此次釋出相關的所有變更都已提交並推送
- CI 在目標分支上為綠色
- 測試在本機通過（執行測試關卡指令）
- 版本號更新已套用到所有版本來源檔案
- 釋出備註 / 更新日誌已準備好（請參閱步驟 5）
要求使用者確認後再繼續，或如果他們說「繼續」，則執行每個步驟。
步驟 5 — 釋出備註撰寫指引
協助使用者撰寫良好的釋出備註。套用專案所使用的慣例。若未偵測到慣例時的預設指引：
什麼是良好的釋出備註：
- 以使用者會看到什麼改變為開頭，而非內部實作細節。
- 按類型分組：
新功能、錯誤修正、重大變更、棄用、內部 / 雜項。 - 每個項目：一句話，附上 PR 或 issue 的連結，如果是外部貢獻者請標註其名稱。
- 重大變更要放在最前面，且必須包含遷移路徑。
- 省略使用者永遠看不到的變更（重構、CI 調整、僅測試相關的變更），除非它們影響建置再現性。
項目格式範例：
### 錯誤修正
- 修正工作階段在權杖過期時被中斷的問題 (#123) — @contributor
如果專案使用 Conventional Commits，則從 git log <prev-tag>..HEAD --no-merges --format="%s" 依提交類型分組產生一份草稿更新日誌。呈現給使用者，讓他們編輯。
步驟 6 — 執行釋出
使用所發現的規則，逐步進行：
- 更新版本 — 套用到每個版本來源檔案。
- 執行測試 — 執行測試關卡指令。
- 提交 —
git add <版本檔案> CHANGELOG.md，並以chore(release): bump version to vX.Y.Z提交。 - 標籤 —
git tag -a vX.Y.Z -m "vX.Y.Z"（優先使用附註標籤而非輕量標籤）。 - 推送 —
git push origin <分支> && git push origin vX.Y.Z。 - CI 接手 — 如果釋出觸發條件是標籤推送，提醒使用者 CI 會處理其餘部分（發布、建立 GitHub Release）。顯示預期的 CI 工作流程檔案。
- 手動發布 — 如果沒有 CI 自動化，列出手動發布指令（例如
npm publish --access public、twine upload dist/*）。
步驟 7 — 首次設定建議
如果在步驟 1f 中發現了缺口，提供具體的協助：
沒有釋出工作流程：
你的專案沒有釋出 CI 工作流程。最常見的最佳實務是以
v*標籤推送觸發的 GitHub Actions 工作流程。它可以：
- 執行測試
- 發布到 npm/PyPI 等
- 使用你的釋出備註建立 GitHub Release
要我為你的技術堆疊建立一個
.github/workflows/release.yml骨架嗎？
沒有 git 標籤：
這看起來是首次釋出。Git 標籤讓 GitHub、npm 和其他工具能理解你的版本歷史。我們會在步驟 6 建立你的第一個標籤。
建置成品未 gitignore：
建置成品存在於 git 歷史中或未被 gitignore。這會導致儲存庫大小膨脹並產生合併衝突。要將它們加入
.gitignore嗎？
步驟 8 — 驗證
推送之後：
- 檢查 CI 狀態：
gh run list --workflow=<釋出工作流程> --limit=3（如果gh可用）。 - 幾分鐘後檢查註冊平台（npm、PyPI）是否有新版本。
- 確認已建立 GitHub Release：
gh release view vX.Y.Z。
回報成功或標記任何失敗。
備註
- 此技能不會硬編碼任何專案特定的版本檔案或指令。所有內容皆由專案檢查推導得出。
.omc/RELEASE_RULE.md是本地快取。如果要與團隊共用推導出的規則，請將它提交到你的專案；如果希望它保留在本機，則將它加入.gitignore。- 對於複雜的 monorepo 或多套件工作區，技能會偵測工作區模式（npm workspaces、pnpm workspaces、Cargo workspace）並相應調整。