用途：对 microsoft/apm 中的一个议题执行单议题分级编排。调用方提供仓库的 GOVERNANCE.md 与 CONTRIBUTING.md，人工政策优先于角色指令；缺失时不得虚构权限或评审联系人，需标注上下文缺失。接受建议不等于接受，标签与沉默不等于批准，只有负责的人工维护者才能批准范围、优先级、贡献者邀请、评审容量与发布目标。
主要能力：固定为 2 个必选专家视角 + 最多 3 个条件视角 + 1 个常驻仲裁者，共 6 个角色段落，写在同一条分级评论中。角色包括 DevX UX Expert、Supply Chain Security Expert、APM CEO（常驻仲裁），以及按条件启用的 OSS Growth Hacker、Python Architect、Doc Writer。CLI Logging Expert 与 Auth Expert 默认跳过，留待议题进入 PR 后由 apm-review-panel 处理。
使用方式：在单一 agent 循环内依次扮演各角色，按需加载各角色的 .agent.md，不派发子代理。先读议题上下文与 assets/label-contract.json（以 --help 查看 scripts/triage_state.py 的调用方式，它只读 stdin 的规范化 JSON 并输出 JSON 计划，不调用 GitHub、不发评论）。按规则判定三个条件角色是启用还是记录未启用原因。对必选角色及已启用条件角色逐一执行角色流程。通过完整性闸门后，再执行 CEO 仲裁。若结论为 duplicate-of #N，须先验证该议题存在且开放。最后加载 assets/triage-template.md 渲染评论并返回结构化 triage-recommendation JSON。
适用场景：日常议题分级、建议性重新分级、人工派发的单议题处理。
限制：仅建议性，不得授权实现；每次运行只产出一条评论，由调用方工作流经安全输出通道发布；不要从技能内发帖。评论体与 JSON 尾部仅用 ASCII，不用 emoji 或 Unicode 符号。CEO 仲裁必须在完整性闸门通过后进行。涉及长期未提供的信息（如具体评审人名单）不应编造。