name: ci-package-deploy-notify version: 1.0.7 description: "仅当用户明确要求触发 Jenkins 打包/部署，并在成功后发送飞书部署提醒时使用。适用于用户明确点名要打包某些服务、选择环境或分支、等待构建完成后通知部署的场景。模型只负责决定参数，实际执行必须调用本 skill 自带脚本。" metadata: requires: bins: ["python3"]

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

指定 @ 成员：

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

  发现更多技能插件，请访问7w4.net。

这个 Skill 质量较好，文档写得很清楚，告诉你什么时候该用、怎么用、要注意什么。脚本会自动检查 Jenkins 队列防止重复触发，还能智能匹配要通知的同事名字，细节考虑比较周全。主要问题是遇到网络波动没有自动重试，偶尔可能失败。另外它不支持生产环境分支，如果你需要部署到线上就用不了。总体来说，用于日常开发和测试环境的打包部署通知是够用的。