在非 Claude 客户端上执行 pm-skills…

当你在 Codex CLI、Cursor、Windsurf、Copilot 或 Gemini CLI 等非 Claude 客户端上执行 pm-skills 发布，并希望复用 pm-release-conductor 的 6 道门禁流程时使用。

适用场景

解决思路

1. 先做运行时检测，判断当前是哪个 AI 客户端在调用本技能。
2. 若在安装了 pm-skills 插件的 Claude Code 中运行：用用户提供的目标版本号和 $ARGUMENTS 中的可选标志调用 @agent-pm-skills:pm-release-conductor，由原生子代理走完 6 道门禁，并通过 Agent 工具原生链式调用 pm-skill-auditor（G0、G2.5）和 pm-changelog-curator（G2），最后把逐门禁输出返回给用户。
3. 若在其他任意 AI 客户端（Codex CLI、Cursor、Windsurf、Copilot、Gemini CLI 等无原生 pm-skills 插件子代理支持的客户端）中运行：读取 agents/pm-release-conductor.md 中的规范子代理定义。
4. 读取 docs/contributing/release-runbook.md 中的规范 runbook（门禁定义的引用来源）。
5. 把系统提示正文作为你的操作指令执行。
6. 内联走完 6 道门禁；在需要链式组合的门禁处：G0（打标签前就绪检查）不链式调用 pm-skill-auditor，而是读取 agents/pm-skill-auditor.md 并内联执行审计器的 4 步审计流程，捕获分层输出（完整发现 + Status Summary + Status YAML），把 Status YAML 作为 G0 子检查 5 的输入。
7. G2（版本号提升 + CHANGELOG 准备）不链式调用 pm-changelog-curator，而是读取 agents/pm-changelog-curator.md 并内联执行策展器的 8 步起草流程，捕获分层输出，把 Status YAML 作为 G2 子检查 3 的输入。
8. G2.5（重新验证）针对新的 HEAD 重新执行内联审计器的子检查 5。
9. 在每个门禁边界暂停，等待维护者明确确认。
10. 拒绝绕过尝试，遵守拒绝协议。
11. 在 G3 按 D22 只对 G2.5 捕获的 SHA 打标签。
12. 在整个流程中持续返回逐门禁输出。
13. 注意非 Claude 内联执行的上下文预算：conductor + 内联 auditor + 内联 curator 及其子读取的合计 token 预算在长发布中可能接近上下文上限，需提前规划。
14. 确保工具授权：conductor 的工具列表包含 Bash、Read、Edit、Grep、Glob、Agent；auditor 需要 Bash + Read + Grep + Glob；curator 需要 Bash + Read + Grep；非 Claude 客户端上的内联执行应能访问全部这些工具（即不要运行在只读模式）。
15. 处理拒绝级联：若内联 auditor 拒绝（例如校验器无法调用），则 conductor 的 G0 子检查 5 失败、门禁暂停；G2 的 curator 同理。

适用边界 · 注意事项

• 只需要评审一个 PM 产物时，改用 utility-pm-critic。
• 只需要做治理审计（而非发布）时，改用 utility-pm-skill-auditor。
• 只需要起草 CHANGELOG（而非发布）时，改用 utility-pm-changelog-curator。
• 想在无明确门禁确认的情况下执行发布操作时——conductor 拒绝绕过，应改走 conductor 之外的手动发布路径。