关于 milestone-rush
milestone-rush 是用于从仓库当前状态推进指定里程碑的技能,涵盖任务交付、集成验证和发布流程,并要求按审计格式汇报。
主要功能
- 01核对里程碑与仓库状态
- 02规划依赖关系和隔离任务
- 03协调实现与代码审查
- 04验证集成及发布门槛
- 05维护可恢复的流程记录
- 06生成审计式完成报告
适用场景
- 01交付已确认的仓库里程碑
- 02跨议题和拉取请求恢复工作
- 03协调依赖变更与审查
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ frostney/ known-good-route --skill milestone-rush安装后在 Claude Code 中输入/milestone-rush确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
references/event-ledger.mdorchestration.mdscope-changes.mdscripts/event_ledger.pytests/test_event_ledger.py详细介绍
里程碑冲刺
从实际当前状态完成指定里程碑。负责协调各项工作交付,并在经过验证的里程碑边界发布。
授权与门槛
- 必须明确指定仓库和里程碑。明确调用即授权执行范围内的问题评论和替换问题、分支和工作树、实现、验证、提交、普通推送、拉取请求、评审问题修复、压缩合并、配置的集成交付、里程碑配置的发布路径、分支清理,以及关闭该里程碑。
- 可接受已确认的
/roadmap-review交接或直接调用。对于直接调用,执行前须核实当前范围、方向、就绪情况、依赖项和成功衡量标准。若需实质性重新规划,应停止,而不是默默更改里程碑;例如,关闭记录了实质性被拒绝或推迟的产品决策,或实质性扩大范围。 - 仅当已确认的路线图事项说明了目标、范围和非目标,以及可测试的成功衡量标准时,才将其视为
/deliver的迷你规格。 - 遵守项目说明、就绪定义和完成定义、分支保护、评审政策以及远程默认分支。不得修改提交、绕过门槛或覆盖无关工作。普通分支只能通过合并处理;只有
git-workflow可以使用其受保护的原生堆栈重写例外。 - 规划或启动工作进程之前,先阅读并验证仓库根目录中的
ORCHESTRATION.md,参见 references/orchestration.md。随后,在进行第一个问题、拉取请求或工作进程操作之前,将本次运行的首个生命周期事件传递给 references/event-ledger.md 中的ingest命令,以启动被忽略的事件日志;即使运行随后因前置条件而停止,也必须执行。若宿主提供的是日志或遥测操作,而非 shell,则使用该操作;只有两者都不存在时,才报告日志不可用。
核对并制定计划
- 拉取最新的里程碑、议题、拉取请求、审查、检查、默认分支、分支、工作树以及相关本地工作树状态。阅读当前项目方向、完成契约,以及经过验证的编排策略或已报告的提供方无关回退方案。
- 在采用或创建工作树之前,运行编排参考中声明的所有仓库准入预检。在开始实现或执行完整本地门禁之前,迁移或拒绝不安全的工作树;不要通过消耗完整测试套件来确认已知的环境限制。
- 将每个里程碑条目和相关本地更改分类为已交付、开放 PR、正在实现、就绪、受阻或无效。复用有效工作,不要从头重做。
- 根据源代码和合并证据验证已关闭的条目。如果必需工作在未交付的情况下被关闭,请阅读 references/scope-changes.md。
- 检查当前交付面,并纳入编排参考要求的提供方无关 CI 集成建议。这是计划产物,并不代表有权更改工作流、标签、规则集、控制器、凭据或提供方配置。如果执行需要当前缺少的能力,请根据 references/scope-changes.md,将其登记为仓库所有的前置条件;否则,记录当前 CI 的安全回退方案及其代价。
- 构建依赖关系图和潜在冲突图。原生技术栈可以表示真正的依赖链,也可以表示对一个大型议题经过确认的逻辑拆分,前提是每一层都可独立审查。优先处理关键路径和尽早降低风险,然后在当前平台容量范围内,将所有相互独立且就绪的节点分派给隔离的子 Agent 和工作树。不要另行设置议题、波次、审查轮次或重试次数上限。
- 每次议题或 PR 状态转换后,都在被忽略的
.agent/HANDOFF.md中维护外层工作流的可恢复状态。记录里程碑标识、关系图、活动工作树、议题到 PR 的状态、阻碍因素、已观察到的验证结果,以及稳定的决策注册表。切勿暂存或提交此检查点;恢复时要将其与实时状态核对。
执行并集成
- 保持协调者精简:由协调者负责已确认的决策及其来源、图状态、工作者准入与替换、交付状态提升、集成、合并和里程碑关闭。详细调查、实现、修复和验证由工作者负责,每位工作者按照其任务包记录的能力层级执行。
- 为每位工作者提供一个上下文隔离的任务包及其依赖项。使用
/deliver,并提供问题或已确认的路线图事项、所需端点、配置的集成目标以及适用证据。传达选定方案,避免/implement重新审议。任务包中保留此工作流默认的/code-review fix-all审查方式。工作项默认交付至其配置的集成目标;里程碑负责共享的排序和发布。重要选择仍由用户决定。 - 若现有 PR 符合问题要求和项目门槛,则采用该 PR。仅当本地状态的归属和范围明确时才采用;保留含糊、脏、预先存在或无关的状态,并报告出来。
- 让每个
/deliver负责自身的实现、发布、反馈和集成循环。提升其工作项之前,核对返回的修订版本、行为、PR 和目标证据。一个原生依赖栈应由单一交付负责人全权负责其完整就绪状态和原子合并;切勿让多个工作者同时拥有同一依赖栈的操作权限,也不要在必需的修复层下方合并不完整的前缀。 - 将修复验证聚焦于已更改的行为。只有在实现和审查修复均收敛到预期分支头后,才运行一次仓库的完整本地门禁,除非新的重大源代码变更使其失效。不要反复将完整测试套件用作诊断循环。
- 将重量级完整 CI 视为最终晋级证据,而非远程调试器。只有在必需的 PR 检查和所有活跃的审查工具都已针对候选分支头完成后,才启动它。如果 CI 服务支持安全取消,则取消已被取代的运行;否则记录无法避免的浪费。后续分支头、PR 基础分支、拓扑结构或审查变更都会使证明失效;基础分支继续前进则不会。
- 持续集成,不要等到批量处理:每个 PR 或依赖栈一旦满足
git-workflow的合并规则,就立即合并。每次压缩合并后,重新拉取里程碑范围和默认分支状态;仅将更新后的远程基础分支合并到git-workflow判定需要更新的剩余分支中,并重新运行适用的门禁。审查和 CI 证据仅对当前 PR 分支头有效。 - 执行过程中发现新工作、外部将问题添加到里程碑,或里程碑合并导致集成回归时,请阅读 references/scope-changes.md。
在宿主共享容量范围内管理实现和审查工作者。只要仍有有用工作,就让实现节点持续运行;审查维度的工作通道则排队等待空闲名额;临时名额耗尽不代表子 Agent 不可用。如果不支持审查子 Agent、经过有限次数重试后仍不可用,或返回的证据不完整,则由实现工作者直接完成这些工作通道,并在里程碑报告中记录此回退。
规范所有物料生命周期、决策、等待、门禁、用量、重试、返工和集成转换,然后将其传递给事件账本的 ingest 命令。宿主适配器负责将原生事件转换为统一格式;切勿向此技能添加提供商转录解析器。内部交付和审查循环会根据
delivery-wait 的运行规则
启动随附的确定性等待;外部里程碑循环则按照编排参考中描述的事件驱动等待,被动等待工作程序或命令完成,并在每次收到转换后协调其检查点。
如果仓库策略要求被动等待,而当前不支持,则不得启动工作。
阻塞项和完成
- 将受阻节点及其依赖项隔离,然后继续处理所有独立且可运行的节点。只有在无法再安全推进时才暂停。切勿在仍有受阻或未经验证的工作时关闭里程碑。
- 在宿主平台限制范围内,通过事件驱动等待重试暂时性审查、CI、问题和拉取请求状态。如有精确且安全的
retry_at,则使用该值。达到速率限制或缺少判定结果表示仍在等待,不代表通过。 - 关闭前,重新获取里程碑、问题、拉取请求、审查和 CI 状态,并验证所有范围内的事项均已交付并关闭且有证据;没有待处理的里程碑 PR、必需检查、审查线程或活跃的审查工具流程;且已同步的默认分支通过适用的完整项目门禁。针对该确切修订版本的监视器或 CI 结果即为该证据;无需再次运行门禁。失败时恢复执行。
- 关闭前,针对当前
runId运行事件账本的validate和summarize命令。事件账本参考中列出的任何无效关闭证据都会阻止关闭,直至修正或根据架构明确标记为不可用。 - 工作项和集成门禁通过后,使用里程碑的发布授权、已敲定的发布计划和版本或确定性的项目版本策略,以及当前证据,调用
/create-release;仅针对尚未解决的重要发布决策提问。该工具通过配置的发布路径负责准备并发布版本。必需的发布仍在等待或失败时,里程碑交付仍处于进行中状态。没有发布路径的项目需要作出具体决策,不得臆造发布者,也不得假定发布成功。 - 只有在验证必需的发布结果后,才能关闭里程碑。仅移除本次运行创建的、干净且已合并的工作树;保留并报告所有其他工作树。
报告
将每项完成声明与针对该具体操作和目标返回的结果对应起来。发布成功并不能确认清理已完成或消息已送达。发送回顾性问题并收到确认,并不能证明问题已排入队列:请在报告中直接询问,或将其描述为已请求,除非已确认送达。核实必需结果;省略未经确认的可选声明,或将其标记为未经确认,不要暗示操作失败。将此要求应用于整份报告,包括表格和括号中的说明;共享的写作指南请参阅 agent-writing。
返回一份审计风格的摘要,涵盖以下每一项。使用这些项目名称作为标签,并保留编排策略和本技能自身对要求、能力及前置条件的术语(例如 stack prefix、
repository-owned prerequisite、fallback):仓库审计和回顾会逐字匹配这些术语,因此改述会导致无法关联。如果某项结果缺失或未经确认,请明确说明,不要省略:
- 初始和最终范围,包括范围偏移;
- issue、worker/worktree、PR 和 squash-merge 之间的对应关系;
- 每个 PR 的审查维度到泳道的映射、泳道状态,以及每个单 Agent 回退及其原因,使用
code-review的报告术语; - 复用的本地状态或 PR 状态;
- 编排策略状态、决策 ID 和冲突、worker 上下文模式,以及任何监控回退,并明确标为回退;
- CI 集成建议,即使前置条件问题包含相同内容,也要标明为建议,并列出每个
repository-owned prerequisite或当前 CI 回退成本; - 事件日志路径和完整性、干预检查点,以及不可用的遥测字段;
- 最终 PR 头部和集成默认分支的验证与审查证据;
- 必需的新增内容、延期的后续事项、阻塞项和剩余工作;
- 集成目标、发布结果以及修订版本/制品证据;
- 清理或保留的状态,以及里程碑关闭状态。
如果里程碑仍未关闭,请以剩余工作和仍需执行的关闭步骤结尾。如果里程碑已关闭,请在报告中询问是否运行 /run-retro;只有在获得明确批准后才调用。