Shepherd 用于在 Exarchos 工作流的合成阶段内，对已发布的 PR 进行迭代看护，直至 CI 检查与代码评审全部满足合并就绪条件。它并非独立的 HSM 阶段，而是在 synthesize 阶段中循环执行，阶段保持不变；进度通过 shepherd.iteration、ci.status 等事件与 shepherd_status 视图跟踪。
主要能力：通过 assess_stack 复合动作一次性评估全部 PR 的 CI 状态、正式评审（APPROVED / CHANGES_REQUESTED）、内联评论线程解析与栈健康；产出 actionItems 与建议（request-approval、fix-and-resubmit、wait、escalate）。默认目标是处理全部反馈，包括次要或 nit 级评论，每条内联评论都需修复或回复。
典型流程：先查询 code_quality 质量信号；评估后用 classify_review_items 将条目分组为 direct、delegate-fixer 或 delegate-scaffolder；按类型修复（ci-fix 读日志复现并提交，comment-reply 回复，review-address 改代码并逐线程回复，restack 执行 git rebase origin/<base>）；应用修复前发出 remediation.attempted，确认后发出 remediation.succeeded。修复后以 git push --force-with-lease 重提交，必要时用 merge_pr 重新启用自动合并，再回到评估步骤。默认迭代上限 5 次，达到上限未获 request-approval 则按升级标准升级。
VCS 操作经由 Exarchos MCP 动作（check_ci、list_prs、merge_pr、get_pr_comments、add_pr_comment 等）自动路由到 GitHub、GitLab 或 Azure DevOps，无需 gh/glab/az 命令。此时 merge_pr 指远端的 PR 合并原语，与上游合并待定子状态的集成合并路径 serialize_merge 不同，本技能不调用 serialize_merge 或 merge_orchestrate。内联线程回复在 GitHub 支持；GitLab 与 Azure DevOps 返回“尚不支持”的能力信号。
请求批准前需确认无遗留 comment-reply 条目。若在 .exarchos.yml 的 invariants.catalogs 注册了目录，可对 PR diff 运行 check_invariant_conformance（非阻塞、评审阶段作用域），供合并门读取架构不变量。修复组合阶段应按 .exarchos/invariants.md 锚定不变量；未注册目录时跳过相应步骤。
适用前提：已有发布 PR（PR 链接位于 synthesis.prUrl 或 artifacts.pr）、PR 已创建并推送、Exarchos MCP 工具可用。限制与注意事项：不要直接轮询 CI 或评审，不要在有失败 CI 时强制合并，不要因建议为 request-approval 而跳过次要评论，不要无限循环，所有修复都走栈分支而非直接推 main。其他细节（如具体运行手册或参考文件内容）资料未在正文给出，暂未提供。