lollipopkit 你负责运行一个迭代式的工程循环，以解决用户提供的问题并将其推进到可以合并的 PR。你绝对不能直接合并到基准分支（例如 main），除非你明确询问用户并获得 APPROVED；否则，你必须始终打开 Pull Request 并等待审查。
强制工作流
你必须严格遵守以下顺序：
- 创建分支：如果当前分支是基准分支（例如
main），在进行任何更改之前，根据 issue 内容创建一个新的描述性分支。否则，跳过分支创建并继续在当前分支上工作。 - 实施修复：研究并实施修复。
- 本地验证：执行项目对应的测试集合以确保更改没有引入新的问题。如果测试失败，修复问题并重新运行测试，直到所有测试通过为止。
- Pull Request：创建一个清晰的提交消息并打开一个 PR 以供审查；PR 标题/描述模板优先参考最近一次 git commit msg（标题使用 commit msg，描述可复用 commit msg 或列出提交列表）。并且PR需要关联当前分支, 额外的, 如果用户提供了 issue，关联该 issue。
- 等待审查：轮询审查评论和 PR 合并状态（
MERGEABLE、UNKNOWN或CONFLICTING），轮询间隔为 60s，最多 30 次；达到上限后询问用户是否继续。 - 处理反馈：根据审查评论应用更改并再次提交/推送。
- 重复：迭代直到获得 APPROVED 且
mergeable状态为MERGEABLE。如果状态为UNKNOWN（正在计算），则继续轮询；如果状态为CONFLICTING（需要手动干预），则停止并通知用户。
核心职责：
- 确定问题来源（通过
ghGitHub，或本地文本/文件）。 - 如果该任务尚不存在 GitHub issue，在与用户确认后使用
gh issue create创建一个。 - 创建工作分支，实施修复，并保持更改范围受控（默认避免无关需求或大范围重构；但若为解决关键问题所必需，可进行重要重构并在说明中解释原因）。
- 当你认为一个连贯的单元完成时，提交更改。
专业性（至关重要 - 强制执行）
- Git 协议：对于已经推送到远程或已有开启 PR 的分支，严禁使用
git push --force、git push -f或git commit --amend。始终创建新的提交并使用标准的git push。 - 审查工具选择（动态判断）：每次执行本 skill 时都必须先动态检测本地是否可用
coderabbitCLI（如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可以合并。
- 如果当前git存在未提交的更改,并且处于非主分支（如