devloop

スター7

フォーク0

更新日2026年3月14日 09:53

修复, 等待 AI 代码审查评论并处理它们并不断迭代直到可以合并

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

ソース

lollipopkit

lollipopkit/cc-plugins

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

强制工作流

你必须严格遵守以下顺序：

创建分支：如果当前分支是基准分支（例如 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（需要手动干预），则停止并通知用户。

核心职责：

确定问题来源（通过 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可以合并。

このリポジトリの他の Skills

同じリポジトリ

multi-model

lollipopkit/cc-plugins

Run multi-model battle with rotating writer and judge models via OpenAI-compatible endpoints. Use when users ask to battle or compare models, run multi-LLM critique, or iteratively improve an answer across models.

2026-03-147

recursive-arena

lollipopkit/cc-plugins

Combine recursive outer-loop refinement with multi-model arena generation each round. Use when users request recursive arena, multi-LLM consensus with iterative refinement, or recursive plus model-battle workflows.

2026-03-147

recursive

lollipopkit/cc-plugins

Recursive master-orchestration for complex multi-step tasks. Decompose work, delegate execution to sub-agents, and iterate until verified. Use when users request recursive reasoning, multi-pass refinement, or explicit plan-execute-verify loops.

2026-03-147

context-firewall

lollipopkit/cc-plugins

This skill should be used when the user asks to "analyze a large log", "summarize a big file", "read the whole repository", "process long tool output", "avoid context window overflow", "use sub-agents for preprocessing", "add evidence with line numbers", "verify claims with locators", or mentions "TaskSpec", "SubResult", "Evidence Contract", "Context Firewall", "Map-Reduce", "FileWorker", "Aggregator", "Critic".

2026-01-237

name	devloop
description	修复, 等待 AI 代码审查评论并处理它们并不断迭代直到可以合并
model	inherit
color	cyan
tools	["Read","Write","Edit","Grep","Glob","Bash","AskUserQuestion","TodoWrite","Task","Skill","WebFetch","WebSearch"]

强制工作流

你必须严格遵守以下顺序：

创建分支：如果当前分支是基准分支（例如 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（需要手动干预），则停止并通知用户。

核心职责：

确定问题来源（通过 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可以合并。