merge

合并拉取请求

通过拉取请求、已验证的合并以及安全的本地清理，完成当前请求中的更改。完成必要的提交、同步、发布和 PR 工作：使用 pull 技能同步基准分支，使用 pr 技能创建或更新拉取请求，并在合并后使用 clean-branches 技能进行清理。

此技能需要 pull、pr 和 clean-branches。开始任何工作之前，确认这三项技能均已安装。若缺少任何一项，请停止并提供其安装命令 npx skills@latest add toy-crane/skills --skill <name>；如果项目固定使用某个包管理器运行器，则使用该运行器。

以当前远程状态为准。保留无关工作；仅将本请求的更改作为符合 Conventional Commits 规范的逻辑提交提交。解析指定的基准分支，或远程公布的默认分支。如果更改或其拉取请求已合并，请验证并报告结果，不要另建一个拉取请求。对于现有的开放 PR，获取其最新 head，并将检出状态与之同步，同时保留已观察到的远程提交和范围内的本地工作。如果无法明确它们应如何组合，请在变基或发布前报告阻碍。然后调用 pull，并传入已解析的远程仓库和基准分支，再进行验证、发布以及创建或更新待审查 PR；该技能会返回已变基到获取到的基准分支上的检出状态，或者在无法安全变基时返回具体阻碍。 保留无关的本地工作；不要为了使同步成为可能而悄悄提交、暂存或丢弃这些工作。只有在预期结果明确时才解决冲突；否则，应确保工作仍可恢复并报告阻碍。发布前验证最终的 HEAD；只有在刚刚观察到远程 PR 分支状态后，才可发布经过改写的历史记录。 如果仓库的 AGENTS.md 或 CLAUDE.md 中包含 ## Issue tracker 章节，则阅读其中链接的详细约定（如有）；旧版内嵌约定也可使用，无需额外安装设置技能。如果没有该章节，则跳过此技能中的所有 Issue 步骤。对于已配置的问题跟踪器，在合并前、分支仍存在且 squash 尚未移除相关内容时，从该分支的提交中读取 Spec-Folder: docs/specs/<slug>/ trailers，并在后续步骤中保留这些文件夹。

使用 pr 创建或更新 PR

验证同步后的 HEAD 后，调用 pr 技能并传入已解析的远程仓库和基准分支。该技能会发布分支并创建待审查 PR，或复用已有的开放 PR，并使其正文和佐证与最终更改保持一致，包括任何 Issue 链接。由于此操作会发布，请务必在调用前进行验证。pr 会以返回 PR URL 结束；在这里这只是中间步骤，因此继续执行下方的合并，而不要停下报告结果。只有当更改本身导致正文过时，而非仅因变基移动了 head 时，才再次调用该技能。

如果已配置问题跟踪器，请在合并前确认远程 PR 中的内容与下方协调步骤将读取的内容一致：PR 涉及的每个规格文件夹都有且仅有一个 Issue，该 Issue 由其 spec.md 中的 Issue: <tracker>:<id> 行指定，并在 PR 正文中重复列出；仅当 PR 交付了实现时，正文才包含约定规定的关闭引用。如果无法读取链接的约定，请报告缺失的信息，不要猜测 Issue 操作，也不要声称已关联或关闭 Issue。

合并与清理

只有当多个提交是有意义、相互独立且值得保留在基础分支中的单元时，才使用变基合并保留这些提交；否则使用压缩合并。 如果 GitHub 因 PR 的提交与基础分支冲突而无法对其执行变基合并，请在 PR 分支上重复上文的 pull 同步操作。 确认预期的合并结果后解决冲突，保留无关的本地工作，并且只在刚刚确认的 PR 分支状态上发布改写后的历史记录。如果意图不明确，或远程分支意外发生变化，请保持 PR 开启并报告阻碍因素。

更新 PR 头部后，只能基于当前头部进行验证；先前的 CI 结果无法验证新的提交。在允许合并前，完成 GitHub 不要求的相关检查。只有当仓库允许、GitHub 会针对当前基础分支强制执行检查（例如，要求分支保持最新，或使用合并队列），且只剩 GitHub 强制要求待处理时，才启用自动合并。确认已启用，然后等待远程报告 MERGED。如果不强制执行针对当前基础分支的验证、无法使用自动合并，或 PR 已可合并，则完成其相关 CI、必需检查和评审，并在重新检查当前头部和基础分支后，使用选定的方法直接合并。gh pr merge --auto 可能会立即合并已可合并的 PR；它并不是通用的等待标记。如果启用自动合并失败，请重新评估 PR，并仅在验证和要求均已通过后直接合并。

等待期间，重新检查当前头部、基础分支、相关 CI、必需检查和评审。如果头部或基础分支发生变化，请重新评估可合并性，并针对当前头部重复验证。启用请求中的头部匹配选项不会将后续自动合并限定在该头部；拥有写入权限的人推送提交后，自动合并仍可能保持启用状态。每当需要新的 Agent 侧验证或非必需验证时（包括仅基础分支变更后，或同一头部上的检查稍后完成后），如果 PR 仍处于开启状态，请先禁用待处理的自动合并，并确认其已被移除，再等待该验证。如果无法再确认合并意图且必须停止工作，也请禁用自动合并。如果因 CI 失败或要求仍未满足而要在 PR 仍开启时结束工作，请禁用任何待处理的自动合并，并确认其已被移除。报告这些阻碍因素，不要绕过它们。遵守必需的检查和评审，但不要要求仓库不要求的评审；以远程 PR 状态作为合并是否成功的依据。

只有远程报告 MERGED 后，才清理已合并的分支，并且只能清理该分支。调用 clean-branches 时，传入已合并的分支、其工作树（如果存在）、已获取的基础分支，以及已合并 PR 的头部提交，这样压缩合并的分支也能被删除。它会运行项目声明的清理命令，仅在其中没有任何工作正在进行时移除工作树和本地分支；如果某个文件夹是本次会话正在使用的目录、某个分支有未提交的更改，或该分支包含基础分支中没有的提交，则会保留它。请在确认合并的同时报告其结果行，包括任何 holder 进程或被保留的分支。保留其他工作树、进程和用户更改。如果已合并的分支位于关联工作树中，clean-branches 不会更改规范基础检出，因此之后请使用当前主机提供的安全方式，使其与已合并的远程状态同步；如果该分支位于主检出中，clean-branches 已完成此操作。

将 spec 文件夹与 issue 跟踪器同步

远程报告 MERGED 后，且仅当仓库的 AGENTS.md 或 CLAUDE.md 中包含 ## Issue tracker 小节时，才使用该约定指定的工具、 issue ID 格式和操作，将跟踪器与当前位于 base 分支上的 spec 文件夹同步。阅读这两个文件，使用 首先找到的小节，以及其中链接的详细约定（如果有）。如果没有该小节，则完全跳过此操作。

比较合并范围内 docs/specs/<slug>/ 文件夹的差异，并通过其 spec.md 中的 Issue: 行查找每个文件夹对应的 issue，绝不能按标题查找。此处不创建 issue；没有该行的文件夹尚无 issue。对于 spec.md 有变更的每个 issue，通过约定更新其限定范围内的 spec 部分，仅保留其标题和正文中的其他所有内容不变，并在之后重新检查该内容。Agent 创建的 issue 与个人创建的 issue 完全一样：其标题不会随之后的 spec 标题变更而更新。如果 Blocked by 行发生变更，则替换其阻塞关系边，并通过每个阻塞文件夹自身的 Issue: 行解析该文件夹对应的 issue。删除文件夹绝不会关闭其 issue；只有确认实现已交付时才会关闭。

在实际交付实现的 PR 合并后，如果 Spec-Folder trailer 指定的每个已实现文件夹对应的 issue 仍处于打开状态，就关闭该 issue，无论跟踪器的自动关闭功能如何：合并到非默认 base 分支、squash 消息中没有 trailer，或跟踪器没有关闭引用，都可能导致 issue 仍处于打开状态。仅包含 spec 的合并绝不会关闭 issue，即使其提交带有该 trailer。直接实现小功能的 PR 可能没有 spec 文件夹或 trailer：检查当前 PR 中准确的 Issue: 行、差异和验证结果；当这些证据确认实现已交付时，立即关闭该 issue。仅凭一行内容绝不关闭 issue。验证跟踪器最终状态，并报告关闭失败，以便重试。仅包含 spec 的 PR 合并后，保持其 issue 为打开状态，并使用约定中的标记为就绪操作，清除 PR 审核或进行中信号，使其处于非活动的、 待实现状态。先检查是否有更新的活跃实现；绝不要将已开始的工作降级。验证最终状态，确保 implement 无需特殊恢复请求即可认领该任务。如果约定中没有此操作，或更新失败，则报告交接受阻，而不要假定 issue 已就绪。

跟踪器故障不会撤销已验证的合并：报告失败的操作及原因。后续运行时，在已合并 PR 的正文中搜索准确的 Issue: <tracker>:<id> 行，通过该 ID 获取每个 issue；仅当该 PR 的差异 和验证结果确认实际实现已交付时，才重试关闭仍处于打开状态的 issue。仅有 spec PR 链接或 trailer 均不足以作为依据。对于已合并的仅 spec PR，如果 issue 仍带有审核或活跃信号，且没有更新的实现已开始，则重试记录的标记为就绪操作。报告证据缺失或重试失败。即使 squash 合并后原始分支和 trailer 已消失，这种追补机制仍然有效。

最后提供已合并 PR 的 URL、合并策略、已验证的远程状态、清理结果，以及已创建、更新或关闭的跟踪器 issue。即使清理或跟踪器操作失败，也要明确报告，不得错误描述已验证的合并。