develop

开发

develop 会将一项请求从实现推进到可合并的拉取请求。请求可以包含问题引用、书面说明，或两者兼有。

它会按顺序运行四项技能：

1. working-on-issue 查找问题、切换到对应分支、指派问题并将其标记为已开始。
2. implement 修改代码并添加测试。
3. polish 检查已提交的更改，并在发布前修复问题。
4. ready-pr 提交剩余工作、推送分支、更新拉取请求、处理评审反馈，并检查是否已准备好合并。

develop 不会合并拉取请求。它也会使用常规的 implement 流程。用户要求并行实现时，使用 develop-with-workflow。

只有在操作人员调用 develop 时才运行它。它必须能够在没有模拟器、设备或已部署构建的情况下运行。在有帮助时，使用诊断信息和提供的行为观察。

输入

示例：

/develop <issue-reference>
/develop "add null checks to the login handler"
/develop <issue-reference> change only the validation path

书面说明决定要构建的内容。如果书面说明与关联问题不一致，以书面说明为准。使用问题中的分支名称、必需的提交引用和拉取请求链接。

如果请求过于含糊，以至于必须做出产品或设计决策才能实现，请询问用户。验收标准不必正式列出；清晰的书面说明就足够了。

如果 working-on-issue 没有找到问题，请提醒用户，并继续实现和本地评审。提交或创建拉取请求前，先阅读仓库规则。如果规则要求提供问题引用，则停止。

如果已完成的工作与问题正文不同，请在拉取请求中保留必需的关闭引用。告知用户差异，并在编辑问题前征求同意。

必需技能

实现前确认已安装以下技能：

• working-on-issue
• new-branch
• implement
• tdd
• polish
• code-review
• codebase-design
• diagnosing-bugs
• update-branch
• ready-pr

若有任何技能缺失，请停止并指出缺失的技能。提供其当前来源的项目本地安装命令。

如果请求会更改技能、技能说明、frontmatter、示例、参考资料或捆绑脚本，请使用 writing-for-agents。

只有在用户要求制作一次性原型，或需要比较不同的行为或 UI 时，才使用 prototype。除非用户要求保留，否则在 polish 之前删除原型，或将其中有用的部分移入正式实现。

使用这两项技能中的任一项前，都要确认其已安装。如果缺失，请停止、指出缺失的技能，并提供其当前来源的项目本地安装命令。

行为观察

使用报告者保真度观察字段中的上下文字段。将所有可用字段原样传递给 polish 和 ready-pr。在有助于实现时进行诊断。如果调用方未提供观察上下文，则继续执行，不要增加额外工作。

工作流

1. 阅读 AGENTS.md、CLAUDE.md 以及它们要求阅读的任何文件。
2. 确认所需技能已安装。
3. 使用完整请求运行 working-on-issue。保留其 issue、分支和状态结果，以供最终报告使用。
4. 确认请求足够明确，可以开始实施。如果工作需要产品决策、设计决策、凭据、权限、外部访问权限或能够解决冲突的指示，则停止。
5. 当请求需要时，运行 writing-for-agents 或 prototype。
6. 使用 implement 中的构建和测试步骤。如果书面指示与 issue 正文不同，请遵循书面指示。跳过 implement 最后的独立代码审查，因为 polish 会执行该审查。
7. 运行仓库文档中规定的验证命令。如果更改会影响可执行行为，请添加或更新测试。合并目标分支后，遵循 update-branch 的验证规则。目标分支上已存在且有证据证明的问题不会阻止 develop。保留目标提交、命令、失败情况及证明，以供最终报告使用。
8. 针对当前提交运行 polish。向其提供 issue、书面指示和可用的行为观察结果。修复接受的发现，提交修复，然后再次运行 polish。持续执行，直到它通过且没有发现问题，或要求人工决策。
9. 如果仓库要求引用 issue，而第 3 步未找到 issue，则在运行 ready-pr 之前停止。报告已完成的本地工作，并向用户索要 issue。
10. 使用相同的行为观察结果运行 ready-pr。让它提交并推送分支、创建或更新拉取请求、处理可用的反馈，并检查当前拉取请求状态。
11. 如果本地检查或拉取请求检查失败，请修复由此分支导致的问题。审查反馈指出问题时也同样处理。验证并审查每个新提交，将其推送，然后重复此流程，直到拉取请求可合并，或下一步需要人工处理。

工作完成时

只有在以下所有条件都满足时，才报告拉取请求已可合并：

• 实现符合书面指示和任何相关 issue 要求。
• 仓库验证已完成。
• 在适用时，测试覆盖了变更行为。
• polish 已在当前提交上通过，且没有发现问题。
• 拉取请求反馈已得到回应或修复。
• 最新提交上的所有必需拉取请求检查均已通过。
• ready-pr 报告拉取请求已可合并。
• 没有尚未解决的决策或访问问题。

额外的全仓库命令若能证明目标分支上存在失败，不会阻止拉取请求。请在最终报告中附上记录的证明。

如果下一步需要产品或设计决策、凭据、权限、外部访问权限、解决指示冲突，或处理超出本请求范围且有效的工作，则报告工作受阻。

如果 issue 指定了分支，完成工作时必须处于该分支。仅当用户明确要求时才使用其他分支。在最终报告中说明分支名称及使用该分支的原因。

最终报告

开头写 Ready to merge 或 Blocked。然后告知用户：

• 更改了什么
• 工作所在位置
• 哪些验证通过或失败
• polish 更改了什么
• 拉取请求的反馈和检查是否已处理完毕
• 用户接下来必须做什么
• 任何具体的遗留风险或测试缺口

如果有链接，请附上议题和拉取请求的链接。仅当分支与议题分支不同时，才提及分支。

当所有检查都通过时，用一句话概述验证情况。仅在检查失败、跳过检查或需要用户执行步骤时，才提供精确命令。不要重复 GitHub 状态字段，也不要列出每项通过的检查。

长时间运行期间，简短记录请求、议题、分支、当前结果、阻碍因素和下一步。使用该记录恢复工作，避免重复已完成的工作。如果额外的全仓库命令发现了经证实的目标分支问题，也要记录目标提交、命令、失败情况和证据。再次应用 update-branch 的验证规则后，才能重用该证据。