用途：在 CLHbid Delivery 看板上完成“双周左右一次”的周期评审闭环。分支 A 把会议纪要发布为 GitHub Discussion 并起草为邮件议程，会议讨论后由项目经理以评论形式发布决定，分支 B 把这些决定转成跟踪器写入。Discussion 是记录，也是下一周期笔记的对比基线。
主要能力与用法：
- 分支 A「Prepare」：先做账务步骤（检查 Microsoft 365、开启下一周期、内务、已合并仍开启项、未计入周期的工作回填），再读看板、在 Claude Doc 或本地 Markdown 起草笔记；按 Last Cycle、Upcoming Dates、Next Review、Decided by Email、Decisions、This Cycle、Cycle After & Backlog、Next Actions 分段，编号按阅读顺序；发布 Discussion 并创建邮件草稿（由项目经理发送，绝不代发）。
- 分支 B「Process」：按 discussion 编号读取正文与项目经理评论，解析引用，扫尾（不允许开启项仍带上一周期）、应用 Next Review 日期到 Cycle 配置并创建私有的一小时准备日历事件、把每个已答问题记录到 issue 的评论与正文，并把状态从 Waiting on input 路由到 Ready for Agent、Ready for Human 或 Backlog。
- 分支 C「Adjust」：调整周期归属或延期。
角色解析：closing、current、future 角色依据 Cycle 字段配置对会议日期解析，解析失败必须停止，不得臆造。
适用场景：需要以业务语言撰写、面向无 GitHub 访问权限的业务方、由项目经理口吻（仅其一名开发者时用“我”）输出的周期评审会议纪要及其决策回写。
限制与注意：每次变更前必须确认，写入后回读；Discussion 为唯一记录，会议期间不编辑笔记；业务决策与分诊到达即用邮件发给业务方；开发者专属分诊不进入笔记或邮件；笔记约 60 行、表格最多 5 行，按 30 分钟会议预算分配；议事日程邮件在会议前两个工作日（不含周末）发出；不做未要求之事。安装命令、收费、平台支持等资料暂未提供。