ci-package-deploy-notify

把“觸發打包/部署 + 成功後發飛書通知”的流程交給固定指令碼處理；不要讓模型自己臨時拼 Jenkins 或飛書請求。

何時使用

只有當用戶明確要求“現在觸發打包 / 觸發部署 / 發部署提醒”時才使用。

當用戶表達這些意圖時使用：

• 明確要求觸發某些服務打包
• 明確要求觸發 Jenkins CI / CI/CD
• 明確要求打包完成後發部署提醒
• 明確要求構建完成後發打包通知
• 明確要求打包並部署 / 直接部署
• 明確指定環境、服務、改動說明，並要求通知 SQA / 部署群

以下情況不要觸發本 skill：

• 只是討論發版方案、釋出時間、部署流程
• 只是查詢構建狀態 / Jenkins 狀態 / 是否發過版
• 只是記錄發版資訊到文件 / 表格 / sheet
• 只是提到“釋出/部署/發版”這些詞，但沒有明確要求“現在執行”
• 只是詢問“能不能打包/能不能部署/這個 skill 是幹什麼的”

模型職責

模型只做這些事：

1. 先判斷使用者是不是在明確要求立即執行；不是的話不要觸發
2. 提取服務/倉庫列表
3. 判斷環境或分支（如 dev / test / demo / sit）
4. 判斷 job 型別（ci / cd）
5. 提取改動說明 changes
6. 如有需要，決定要 @ 的同事名
7. 根據使用者意圖選擇執行鏈路：
   • 使用者說“打包通知部署 / 打包後通知測試部署” → 走 ci
   • 使用者說“打包並部署 / 直接部署” → 預設走 cd，即 複用 CI job + AUTO_CD=true
   • 只有在使用者明確要求“單獨部署”時，才走獨立 CD job
8. 將當前會話裡真實發起人的 Feishu 標識透傳給指令碼：優先使用當前訊息傳送者的 open_id（通常就是會話後設資料裡的 sender_id / open_id），拿不到時才回退 user_id 或配置裡的預設發起人
9. 呼叫固定指令碼
10. 回報結果或錯誤

模型不要：

• 自己呼叫 Jenkins API
• 自己構造飛書卡片
• 自己重寫等待/輪詢邏輯
• 在回覆裡暴露 token / webhook / secret

執行方式

指令碼路徑：scripts/ci_package_deploy_notify.py

基礎呼叫：

python3 <skill_dir>/scripts/ci_package_deploy_notify.py \
  --repos cloud-mall cloud-device \
  --branch test \
  --changes "修復支付回撥" \
  --initiator-id "ou_xxx" \
  --initiator-name "張三"

觸發 CI/CD：

python3 <skill_dir>/scripts/ci_package_deploy_notify.py \
  --repos cloud-mall \
  --branch demo \
  --job-type cd \
  --changes "聯調完成" \
  --initiator-id "ou_xxx" \
  --initiator-name "張三"

說明：

• job-type=ci 時：只觸發 CI，成功後傳送 打包通知 卡片，語義是“已經打包完成，請按需部署”
• job-type=cd 時：預設複用 CI job，並通過 AUTO_CD=true 繼續部署，成功後傳送 部署通知 卡片
• CD 觸發方式支援兩種：
  • 預設模式：複用 CI job，通過 AUTO_CD=true 繼續部署
  • 單獨部署模式：僅在明確需要“單獨部署”時，才使用獨立 CD job，並通過 PROJECTS 等引數選擇服務
• 兩種卡片都會帶上服務、環境/分支、改動說明、發起人、SQA 資訊

指定 @ 成員：

小蔥技能7w4.net有更新，你可以訪問看下。

python3 <skill_dir>/scripts/ci_package_deploy_notify.py \
  --repos cloud-mall cloud-device \
  --branch test \
  --changes "釋出完成" \
  --at Felix,Zack \
  --initiator-id "ou_xxx" \
  --initiator-name "張三"

引數整理規則

• --repos：優先使用 config.json 裡的倉庫鍵名；若配置了 service_aliases，也可使用其中的相容名。像 dl-admin 這類獨立服務，應該在 repos 中單獨配置，不要誤配成其他服務別名
• --branch：優先由使用者明確指定；當前 skill 只支援 dev / test / demo / sit，不支援 prod / master
• --job-type：預設 ci
  • 使用者說“打包通知部署 / 打包後通知測試部署”時，用 ci
  • 使用者說“打包並部署 / 直接部署”時，用 cd
• 當前預設 CD 走 AUTO_CD=true 這條鏈路；只有使用者明確要求“單獨部署”時，才切到獨立 CD job。不要讓模型自己拼 job 引數
• --changes：必須提供；若使用者沒說，先追問一次
• --at：可選，多個名字用逗號分隔；指令碼會優先精確匹配，再做包含匹配和模糊匹配，儘量容忍拼寫不準，但如果同時匹配到多個候選會直接報錯要求明確
• --initiator-id：預設傳當前訊息傳送者的 open_id；在 Feishu 會話裡，優先取會話後設資料中的 sender_id / open_id，只有拿不到時才退回 user_id
• --initiator-name：可選；如果會話裡拿不到可讀姓名，可以不傳，不要為了補名字阻塞執行
• 若未傳 --initiator-id，指令碼才會回退到配置中的預設發起人；因此正常呼叫時應始終透傳當前真實發起人的 open_id
• 若使用者只是“諮詢能不能做”或“問怎麼打包”，不要自行補引數後直接執行
• 若缺少 repos / branch / changes 中任一關鍵引數，先追問，不要半猜測執行

輸出說明

指令碼會按順序執行：

1. 觸發前先檢查 Jenkins 佇列 / 正在執行的同 job、同分支、同 job_type 任務
2. 若已存在相同引數任務，則跳過重複觸發並直接等待現有任務完成
3. 否則觸發 Jenkins job
4. 輪詢 Jenkins 佇列/構建狀態
5. 全部成功後傳送飛書部署提醒
6. 輸出最終結果

成功時重點彙報：

• 哪些服務觸發成功
• 是否命中“重複觸發防重”並複用已有 queue/build
• CI 是否完成
• 若使用者要求部署，AUTO_CD 鏈路是否完成；若明確走單獨部署場景，再看獨立 CD job 是否完成
• 飛書通知是否已傳送
• 當前傳送的是打包通知還是部署通知
• 卡片中是否帶上了環境/分支資訊
• 發起人是否使用了當前訊息傳送者的 open_id
• SQA 是否命中模糊匹配；若匹配不明確，需直接報錯並要求明確名字
• 若未拿到當前訊息傳送者 open_id，是否回退到了預設發起人

失敗時直接彙報失敗服務和原因。 如果使用者給了 prod / master，應直接報“當前 skill 不支援該環境”。

安全說明

• 憑據來自同目錄 config.json
• 不要在聊天裡複述 token / webhook / app secret / jenkins api_token

維護說明

• 當指令碼或 SKILL.md 更新後，如需讓其他有許可權的 agent 也拿到同一版本，使用 clawhub/技能同步流程進行釋出或同步，不要只改當前工作區副本後就預設其他 agent 已生效。

這個 Skill 質量較好，文件寫得很清楚，告訴你什麼時候該用、怎麼用、要注意什麼。指令碼會自動檢查 Jenkins 佇列防止重複觸發，還能智慧匹配要通知的同事名字，細節考慮比較周全。主要問題是遇到網路波動沒有自動重試，偶爾可能失敗。另外它不支援生產環境分支，如果你需要部署到線上就用不了。總體來說，用於日常開發和測試環境的打包部署通知是夠用的。