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 /scripts/ci_package_deploy_notify.py 
  --repos cloud-mall cloud-device 
  --branch test 
  --changes "修复支付回调" 
  --initiator-id "ou_xxx" 
  --initiator-name "张三"

触发 CI/CD：

python3 /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 信息

指定 @ 成员：

python3 /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 已生效。