wemilabs/ship-to-prod

Ship to Prod

當使用者說「ship it」或在完成工作後說出類似指令時，請直接執行以下步驟，無需再次詢問。

流程取決於目前所在的分支。請先偵測環境一次，然後在後續步驟中重複使用偵測結果。

偵測環境

在一開始，並行執行以下步驟：

1. 套件管理器：檢查 repo 根目錄是否有鎖定檔。
   • pnpm-lock.yaml -> pnpm
   • yarn.lock -> yarn
   • bun.lockb 或 bun.lock -> bun
   • package-lock.json -> npm
   • 如果 package.json 中有 packageManager 欄位，則優先使用該值。
   • 如果都沒有找到，預設使用 npm。
2. 預設分支：git symbolic-ref refs/remotes/origin/HEAD（若失敗則以 git config init.defaultBranch 作為備用）。如果兩者都失敗，預設為 main。
3. PR 工具：gh --version。如果已安裝並通過驗證的 gh，則使用它來建立和合併 PR。如果沒有，則改為顯示 PR 網址，讓使用者手動建立。
4. Shell：偵測目前使用的 shell。在 Windows (PowerShell) 上，heredoc 無法使用，因此對 git commit 使用多個 -m 旗標。在 bash/zsh/fish 和其他 Unix shell 上，使用 heredoc。

將這些結果儲存為 <pkg>、<default-branch>、<gh-available> 和 <shell>，供後續流程使用。

步驟

1. 清理（可選）

在提交之前，有兩個技能可以清理 AI 產生的雜亂內容。如果兩者都可用，則執行這兩個技能：

• deslop：從 diff 中移除 AI 程式碼的雜亂內容（不必要的註解、對可信路徑的防禦性檢查、any 型別轉換、深度巢狀結構）。針對目前與預設分支之間的 diff 來呼叫它。
• unslop：從散文（UI 字串、註解、提交訊息、PR 描述）中移除 AI 文字說明。針對你在此 session 中撰寫的任何文字來呼叫它。

在繼續之前，修正這兩個技能標記的所有問題。

如果其中任何一個技能尚未安裝，不要直接忽略。請使用 ask_user_question 工具詢問使用者是否要安裝缺少的技能，並提供以下選項。請提及這兩個技能都來自 Cursor AI 的官方插件 repo (https://github.com/cursor/plugins)，因此是值得信賴的來源：

• 全域安裝（供未來在所有專案中使用）：npx skills add https://github.com/cursor/plugins --skill deslop unslop -g
• 本地安裝（僅限此專案）：npx skills add https://github.com/cursor/plugins --skill deslop unslop
• 跳過（本次執行）：繼續執行，不使用缺少的技能。不要因為缺少可選的依賴項而阻塞整個流程。

使用 ask_user_question 工具呈現選擇。如果使用者選擇全域或本地安裝，請執行安裝指令，然後在呼叫這些技能之前重新檢查它們是否已可用。如果安裝失敗或使用者選擇跳過，則繼續執行流程，使用目前可用的技能。

2. 驗證工作

按順序執行以下檢查，在繼續之前修正任何問題。將 <pkg> 替換為偵測到的套件管理器。npm 始終需要 run（例如 npm run format）；pnpm/yarn/bun 允許直接呼叫（例如 pnpm format）：

1. <pkg> run format（pnpm/yarn/bun 使用 <pkg> format）：自動格式化
2. <pkg> run lint（pnpm/yarn/bun 使用 <pkg> lint）：修正你觸碰過的檔案中的 lint 錯誤（忽略其他檔案中已存在的問題）
3. <pkg> run typecheck（pnpm/yarn/bun 使用 <pkg> typecheck）：必須以 exit code 0 通過
4. <pkg> run build（pnpm/yarn/bun 使用 <pkg> build）：必須以 exit code 0 通過

如果某個 script 不存在（例如沒有 format script），則跳過該步驟並記錄。不要因為缺少可選的 script 而導致整個流程失敗。typecheck 和 build 是必要的（如果它們存在的話）；如果兩者都不存在，則在提出警告後繼續執行。

在可用的檢查通過之前，不要進行提交。

如果驗證後 git status 是乾淨的（沒有暫存或未暫存的變更），則報告「沒有可交付的內容」並停止。不要嘗試進行空提交。

3. 評估目前分支

執行 git branch --show-current 取得目前分支名稱。將其與 <default-branch> 進行比較。然後決定：

• 如果在 <default-branch> 上：直接提交並推送。不需要 PR，不需要合併。跳到步驟 5。
• 如果在任何其他分支上：提交、推送、建立 PR 到 <default-branch> 並合併。繼續執行步驟 4。

4. 檢閱變更

並行執行 git status、git diff 和 git log --oneline -5，以了解變更內容並比對提交風格。

5. 暫存並提交

執行 git add -A，然後使用 conventional-commit 訊息（feat/fix/refactor）進行提交。

提交訊息格式：

<type>: <short description>

<optional body>

在 bash/zsh/fish 和其他 Unix shell 上，使用 heredoc：

git commit -m "$(cat <<'EOF'
type: subject

body
EOF
)"

在 PowerShell (Windows) 上，heredoc 無法使用，因此使用多個 -m 旗標：

git commit -m "type: subject" -m "body"

6. 推送

執行 git push（如果分支還沒有 upstream，則執行 git push -u origin <branch>）。

7. 如果在功能分支上：建立 PR 並合併

如果 <gh-available>：

• 將 PR 主體寫入一個暫存檔，然後使用 --body-file 建立 PR（適用於所有 shell，包括 PowerShell）：
  • gh pr create --base <default-branch> --head <current-branch> --title "<title>" --body-file <temp-file>
• 在 gh pr create 返回後刪除暫存檔。不要讓它留在磁碟上。
• 合併時不指定策略，以便使用使用者的 repo 預設設定：
  • gh pr merge <number>

PR 主體格式：

## Summary
<bullet points>

#### Test plan
- [ ] <checklist>

如果 gh 不可用：

• 推送分支（步驟 6）。
• 顯示使用者應該開啟以手動建立 PR 的網址： <repo-url>/compare/<default-branch>...<current-branch>
• 停止。讓使用者自行建立並合併 PR。不要在沒有 gh 的情況下嘗試合併。

8. 保持目前分支存活

合併後不要刪除工作分支。它應保持開啟，以供下一個功能使用。

9. 確認

向使用者報告 PR 網址（如果有的話）以及合併/推送狀態。

衝突處理

如果功能分支落後於 <default-branch>，請在推送前進行 rebase：

git fetch origin <default-branch>
git rebase origin/<default-branch>

解決任何衝突，然後繼續進行推送、PR 和合併。

注意事項

• 目標始終是偵測到的 <default-branch>，而不是硬編碼的名稱。
• 合併後絕不刪除工作分支。
• 如果在 <default-branch> 上，只需提交並推送。不需要 PR。
• 絕不跳過驗證步驟，即使使用者很急。
• deslop 步驟是可選的。如果缺少某個技能，請先提供安裝選項（全域或本地），然後再回退到跳過。