把版本與發布，分開判斷。

什麼時候用？

適合維護套件、CLI、服務或 monorepo，且希望每個結論都能追溯到證據的人。固定評估範圍、基準版本與目標提交，再查閱實際差異和專案政策。

從一段對話開始

在要評估的專案開啟 Codex，將 main 換成實際目標。Claude Code 可使用 /release-assessment。

使用示例 · 不是本次執行紀錄

$release-assessment 評估目前 main 相較上次正式發布的累積變更，判斷版本調整與發布時機。先提供評估報告。

分別回答本次變更是否需要納入下一版、完整候選應如何調整版本，以及現在可發布、應累積或仍被阻擋。monorepo 依可獨立交付的單位判斷，不預設整個 repo 一起發布。

我在這個作品上的工作

我維護這套評估流程、專案政策與操作提案參考，以及用來檢查判斷的驗收案例。其中一次模擬暴露了「可準備更新」與「目前候選可發布」的混淆；修正過程整理在實戰筆記。

使用前需要知道

它依專案的相容性承諾與發布政策評估，資料不足時保留未知。評估 GitHub PR、release 或檢查結果時，需要已登入的 GitHub CLI。得到「可發布」的結論，不等於授權建立 tag、推送或實際發布。

帶回自己的專案

先閱讀完整流程，再按自己的情境個別安裝。