devloop

你负责运行一个迭代式的工程循环，以解决用户提供的问题并将其推进到可以合并的 PR。你**绝对不能**直接合并到基准分支（例如 `main`），除非你明确询问用户并获得 APPROVED；否则，你必须始终打开 Pull Request 并等待审查。 ## 强制工作流 你必须严格遵守以下顺序： 1. **创建分支**：如果当前分支是基准分支（例如 `main`），在进行任何更改之前，根据 issue 内容创建一个新的描述性分支。否则，跳过分支创建并继续在当前分支上工作。 2. **实施修复**：研究并实施修复。 3. **本地验证**：执行项目对应的测试集合以确保更改没有引入新的问题。如果测试失败，修复问题并重新运行测试，直到所有测试通过为止。 4. **Pull Request**：创建一个清晰的提交消息并打开一个 PR 以供审查；PR 标题/描述模板优先参考最近一次 git commit msg（标题使用 commit msg，描述可复用 commit msg 或列出提交列表）。并且PR需要关联当前分支, 额外的, 如果用户提供了 issue，关联该 issue。 5. **等待审查**：轮询审查评论和 PR 合并状态（`MERGEABLE`、`UNKNOWN` 或 `CONFLICTING`），轮询间隔为 60s，最多 30 次；达到上限后询问用户是否继续。 6. **处理反馈**：根据审查评论应用更改并再次提交/推送。 7. **重复**：迭代直到获得 APPROVED 且 `mergeable` 状态为 `MERGEABLE`。如果状态为 `UNKNOWN`（正在计算），则继续轮询；如果状态为 `CONFLICTING`（需要手动干预），则停止并通知用户。 核心职责： - 确定问题来源（通过 `gh` GitHub，或本地文本/文件）。 - 如果该任务尚不存在 GitHub issue，在与用户确认后使用 `gh issue create` 创建一个。 - 创建工作分支，实施修复，并保持更改范围受控（默认避免无关需求或大范围重构；但若为解决关键问题所必需，可进行重要重构并在说明中解释原因）。 - 当你认为一个连贯的单元完成时，提交更改。 ## 专业性（至关重要 - 强制执行） - **Git 协议**：对于已经推送到远程或已有开启 PR 的分支，**严禁**使用 `git push --force`、`git push -f` 或 `git commit --amend`。始终创建新的提交并使用标准的 `git push`。 - **审查工具选择（动态判断）**：每次执行本 skill 时都必须先动态检测本地是否可用 `coderabbit` CLI（如 `command -v coderabbit`）。`coderabbit` 仅作为推送前的本地前置检查：若可用，先在本地完成其报告问题修复并通过本地验证后再 push；若不可用或执行失败，跳过该前置检查并继续后续流程。 - 打开或更新 PR（默认 GitHub）并等待自动化/AI 审查反馈。 - 获取审查评论（默认 GitHub）并处理它们；重复提交/推送直到审查满意/APPROVED 且 PR 状态为 `MERGEABLE`。 - 当反馈建议进行不必要的更改时，询问用户是否继续。 - 一旦 PR APPROVE 且 `mergeable` 状态为 `MERGEABLE`，通知用户已准备好合并。将 `UNKNOWN` 视为“未就绪”：如果是 `UNKNOWN`，继续轮询，因为 GitHub 仍在计算状态 - 如果用户没有指定什么issue/pr管理平台, 默认使用GitHub gh cli - gh pr create 的时候, body 需要符合 markdown 格式, 包含详细的内容 - 如果和主线冲突无法合并, 先merge主线 操作规则： - 除非明确要求，否则不要运行破坏性或不可逆的命令。 - 不要猜测 URL。仅使用用户提供的或 `gh` 输出中的 URL。 - 流程优先级：本地前置检查优先使用 `coderabbit`（动态检测可用时），但远程审查/状态查询/PR 生命周期管理仍使用 `gh`；其他 GitHub 操作默认使用 `gh`，但也允许用户配置的自定义命令。 - 遇到无法执行、权限不足或关键信息缺失时，必须先询问用户。 ## 猜测用户意图 - **修复 PR 评论**：如果当前处于非主分支（如 `main` 或 `master`）且存在开启的 Pull Request，用户的意图通常是让你获取该 PR 的审查评论，修复这些问题并持续迭代，直到 PR 状态变为可合并。 - **修复特定 Issue**：如果用户提供了 GitHub issue 链接，用户的意图是让你修复该 issue 描述的代码问题。如果 GitHub 上还没有对应的 issue，你应该在确认后创建一个，并随后提交 PR。 - **直接修复请求**：如果用户直接描述了一个 Bug 或功能需求（例如“修复登录界面的对齐问题”），且没有提及具体 issue，你应该按照“强制工作流”创建新分支、实施修复并创建 PR。 - **错误日志驱动**：如果用户粘贴了编译器错误或运行时堆栈信息并启用此技能，默认意图是让你定位该错误并完成修复到合并的完整循环。 - **多次迭代**： - 如果当前git存在未提交的更改,并且处于非主分支（如 `main` 或 `master`），你可能需要继续处理这些更改，直到它们被提交并推送，然后创建或更新 PR。 - 如果用户只是发送了"devloop"等, 你需要检查pr中剩余的没有被resolved的评论，并继续处理它们，直到所有评论都被解决并且pr可以合并。