complete-work

完成工作

完成本次调用提供的任务：从新建分支开始，经过验证实现，并完成 PR 审查周期。

1. 确定范围并创建分支

根据随附说明和对话，找出所需工作和验收标准。如果提供的是 Linear 问题或工单，请阅读完整要求和验收标准，以及确定范围所需的引用材料；仅凭标题或摘要是不够的。如果没有 Linear 工单，则以完整的用户请求和对话为准。阅读适用的 AGENTS.md 文件和仓库要求。如果未提供任务，请先询问，再创建分支。

如果执行任务需要用户作出决定，例如存在重大歧义、要求冲突、尚未解决的权衡或实现风险，请在创建分支或开始实现之前调用 $grilling，并完成访谈。只有在用户确认双方达成共识后才能继续。这是有条件的辅助步骤，并非必经阶段：如果请求和验收标准清晰且可执行，则跳过；纯操作性阻碍按常规流程处理。

检查工作树、当前分支和远程仓库。保留已有更改，并确保新分支和 PR 不包含无关提交。确定目标基础仓库的远程仓库，并通过 GitHub 元数据或其远程 HEAD 查明该仓库的默认分支（git ls-remote --symref <base-remote> HEAD）。先获取默认分支，再从刚获取的提交直接创建一个描述性的新分支，并使用 --no-track。分支名称必须以 agent/ 开头，例如 agent/add-login-validation；后缀遵循仓库命名约定，并将查明的默认分支用作 PR 的基础分支。验证新分支的初始 HEAD 与刚获取的默认分支提交一致；不要从过时的本地默认分支副本或当前功能分支创建分支。必要时使用隔离工作树，以保留现有工作。如果远程仓库或默认分支不明确、默认分支不存在或获取失败，请停止并报告阻碍。

确认 create-pr 和 finish-pr 技能可用，并确认 GitHub CLI 已通过目标仓库的身份验证。如果缺少前置条件，请明确报告，不要悄然跳过必需阶段。

编辑前，确定目标头仓库的推送远程（它可能与基础仓库不同，例如使用分叉仓库时），然后创建同名的远程分支：git push --set-upstream <head-remote> HEAD:refs/heads/<branch-name>。验证 git rev-parse --abbrev-ref "@{upstream}" 的结果为 <head-remote>/<branch-name>，并将 git ls-remote --exit-code --heads <head-remote> refs/heads/<branch-name> 返回的 SHA 与 git rev-parse HEAD 进行比较，以验证远程分支与本地 HEAD 一致。只有在本地和远程均存在同名分支，且本地分支跟踪该远程分支后，分支设置才算完成。如果推送或验证失败，请停止并报告阻碍。

2. 逐步实现并提交

实现提供的任务，确保改动不超出任务范围。在有意义的检查点提交已完成并验证的连贯改动；不要等到多步骤任务全部结束才一次性提交。小任务可能只需一次提交。只暂存属于此任务的改动，检查每次暂存的差异，并使用描述清晰的提交消息。

维护基于已确定任务整理的简洁评审上下文：要求、决策、排除项和验证证据。将其贯穿 PR 创建和 finish-pr 流程；用它揭示要求缺口，而不是复述整个对话。

根据具体失败风险，选择额外的发布前验证。身份验证、租户隔离、计费、迁移和评审控制器方面的改动，需要进行相关的额外检查，以超越常规的成功路径；例如，真实使用方测试、浏览器操作，或针对尚未解决问题进行一次范围明确的全新上下文评审。如果已有证据涵盖相应风险，就复用现有证据。常规改动沿用现有验证和评审流程。额外的 AI 评审是可选的，范围应明确，且发布前最多进行一次；它不是对每个 PR 默认进行的第二次评审。说明所选检查仍可能遗漏什么。执行操作应在实现所获授权的测试环境中进行；这并不授权仅审查源代码的评审者执行所审查的代码。

发布实现提交前，针对预期基准分支审查完整差异。逐项核对提供的 Linear 工单中的每项要求和验收标准；若未提供 Linear 工单，则核对用户请求的每个部分，并提供满足这些要求的实现和验证证据。运行相关测试和仓库要求的检查，修复由本次改动导致的问题，并检查是否存在意外改动或遗漏。

只有在工作完全满足该范围、相关验证通过且所有任务改动均已提交后，才能进入第 3 步。在继续之前，完成范围内所有剩余工作。如果缺少必要信息、访问权限、决策或验证，请说明具体缺口并向用户索取所需内容；收到后再继续。报告阻碍或限制并不代表满足此门槛。对于部分完成的工作，不要创建或复用 PR，包括草稿 PR：继续创建 PR 即表示你确认所有请求均已落实且工作已完成。

3. 推送并创建 PR

无需强制推送，使用明确的目标地址推送已完成的提交：git push <head-remote> HEAD:refs/heads/<branch-name>。编写 PR 正文前，先阅读并遵循 test-changes，为已完成的工作准备手动验证交接说明。然后加载并遵循 $create-pr (SKILL.md)，根据其 Linear 工单标题前缀、模板选择、分类、简短易懂的用户故事和提交验证规则，针对预期基准分支创建或复用 PR。确保没有技术背景的读者也能理解该故事，包括改写原始故事时。提供任务意图、可用时的原始用户故事、影响任务的 Linear 工单标识符及 PR 完整完成的工单标识符、最终差异、验证结果、基准分支和头部分支的仓库与分支，以及完整的交接说明。始终将该交接说明放在标题为 ## Test changes 的原样章节中：如果模板已有此章节，就使用该章节；否则，即使模板中已有其他测试章节，也要在模板后追加该章节。

调用此工作流即表示授权进行提交、推送、创建 PR 和回复评审意见；应持续完成这些步骤，无需再次确认。

4. 使用 finish-pr 完成 PR

在同一轮运行中，加载并遵循 $finish-pr，处理新创建的 PR。延续任务意图、决策、验证结果和已知限制。继续执行其冲突、CI、反馈和评审收敛工作流，直到满足其完成定义或触发某项停止条件。仅创建 PR 并不意味着此工作流已完成。

除非用户另行要求合并，否则将 PR 保持为开放状态。报告 PR URL、简洁的变更和验证摘要，以及任何尚未解决的阻塞项或待完成的必需检查，并以 finish-pr 的最终审计为准。