roadmap-review

路线图评审

制定一份经源资料核实、以吞吐量为依据的路线图和发布计划。分析 是交付内容；问题、拉取请求、里程碑和发布的变更均为可选项，且须经确认。

证据要求

• 本次运行时获取当前问题、发布、里程碑、已合并 PR 历史记录和项目 方向文档。记录缺失的来源并降低置信度，不得凭记忆填补空缺。
• 衡量 90 天内已合并 PR 的吞吐量，以及从创建问题到 PR 合并的周期。 只有在明确标注为备用方案时，才能使用从 PR 开启到合并的时间。排除 已关闭但未实施的分流问题。
• 如果存在领域指标，应根据间隔采集的历史 CI 产物衡量其变化趋势。按标签或 领域分配的工作反映的是过去的投入，而非产能。
• 提出或描述工作前，依据当前代码、测试或一手规范，将其分类为已完成、部分完成或未开展，并提供证据。 只提出部分完成或未开展的工作。

默认情况下，若宿主支持，应将相互独立且规模较大的证据调查领域委派给上下文隔离的子代理；较小或相互关联的领域则直接处理。 完成综合分析后再制定计划。

工作流

1. 依据证据要求开展评审，并核对托管代码服务中的问题、拉取请求、 发布和里程碑数量。
2. 评估发布节奏、已合并但尚未发布的工作、里程碑与提交之间的偏差、愿景、范围和非目标。
3. 按证据要求对每个候选项进行分类，并剔除已交付的工作。
4. 将测得的速率应用于经统计的剩余待办事项，并说明依据和置信度。绝不填充时间线。若证据不足以支持具体日历日期，则报告时间范围和依赖项，不提供带日期的甘特图或占位日期。
5. 规划涵盖独立工作流的主题式发布，标注依赖项和最长关键路径。指出真正需要人工决策的事项并给出建议。
6. 对这些决策暂停后续操作，并呈现：
   • 当前状态、偏差和发布节奏建议；
   • 测得的速度和置信度；
   • 已标注版本和规模的工作流；
   • 以吞吐量为依据的时间线，以及条件允许时提供的 Mermaid 甘特图；
   • 待决事项。
7. 提供带日期的 ROADMAP-YYMMDD.md；未经用户请求不得创建。
8. 只有在最终计划获得明确确认后，才创建或修改里程碑、问题、到期日或标签。每个问题都必须通过 /create-issue 创建，并准确报告所有变更。
9. 在确认的里程碑及其跟踪范围建立后，将 /milestone-rush <milestone> 作为明确的后续操作提供。绝不可自动启动 rush；选择该操作即授予该技能限定范围内的实施和合并权限。

报告应聚焦决策并标注快照日期。依据旧报告采取行动前，须重新获取数据。