关于 dev-task-loop
dev-task-loop 是一项面向开发待办事项的通用工作流技能，不依赖特定任务跟踪器或版本控制平台。它先确认工作约定，再逐项处理任务，并涵盖验证、提交、合并和回写状态。
主要功能
- 01开始前询问六项工作约定
- 02从指定来源获取待办列表
- 03按步骤实现并验证每项任务
- 04提交变更并创建或合并 PR
- 05更新任务状态并确认结果
适用场景
- 01逐项处理开发积压任务
- 02使用 OpenSpec 或 Markdown 清单跟进工作
- 03跨任务跟踪器与版本控制平台执行固定流程
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/dev-task-loop确认已加载。
详细介绍
开发任务循环
用于处理开发待办事项的通用循环。此技能刻意与平台无关——它承诺的是一种工作流，而非任何特定的跟踪工具／VCS 托管平台／设计工具。
核心原则
先询问，再循环。 先提出六个问题，明确工作上下文。之后，持续执行紧凑的逐任务循环，直到用户让你停止或待办事项已清空。
除非用户在回答中提到，否则不要假定他们使用 Jira、GitHub、Figma 或任何其他供应商。
阶段 0 — 明确工作流上下文
开始任何操作之前，用一次调用提出全部六个问题，调用 AskUserQuestion。所有问题都回答完之前，不要开始工作。
六个问题（繁体中文——如果用户使用英语，则翻译）：
- 哪个项目？ — 根路径或仓库标识符。示例答案：
/Users/me/Documents/myapp、org/repo、"monorepo, packages/web"。 - 在哪个分支开发？ — 工作分支（新提交将落入该分支）。示例：
tim、dev、feature/foo。 - 开发完成后合并到哪个分支？ — 合并目标。示例：
main、develop、release/v2。 - 任务清单在哪里？ — 待办事项所在位置，以及如何筛选出“可开始处理”的任务。示例："Jira 项目 PROJ，状态 = Review Failed，指派给我"、"GitHub issues label:bug"、"Notion DB X filter Y"、"这个 TODO.md Markdown 文件"。
- 示意图／设计在哪里？ — 设计参考，或“不需要设计”。示例："Figma 文件 URL"、"/docs/mocks/ 中的截图"、"无需设计——只有文本规格说明"。
- 完成后如何标记任务？ — 完成定义操作，标记在任务页面或本地磁盘上。示例："评论 已修正 @reviewer，将状态设为 審核中"、"关闭 issue，留下 PR 链接"、"勾选 Markdown 文件中的复选框"、"运行
openspec archive <change>"。
对于 AskUserQuestion 中的每个选项列表，加入用户在以往会话中最可能提到的选项，以及一个自由文本兜底选项（harness 会自动添加 "Other"）。
将六个答案保存为本次会话剩余部分的工作流约定。每个阶段开始前，都要在心中重新确认这些答案。
阶段 1 — 获取待办事项
根据问题 4 的答案，获取符合用户“可开始处理”筛选条件的任务列表。
具体做法取决于用户指定的来源：
| 跟踪工具类型 | 处理方式 |
|---|---|
| 使用会话 Cookie 的 REST API（Jira Cloud、Linear、Asana 等） | 在浏览器 MCP 中打开一次跟踪工具，然后通过 javascript_tool 针对当前打开的标签页调用其 REST 端点——会话 Cookie 会携带身份验证信息。 |
| GitHub / GitLab | 先尝试平台 CLI（gh issue list、glab issue list）；如果不可用，再使用网页自动化。 |
OpenSpec / Spectra（仓库中的 openspec/ 目录） | 使用 openspec list 查看进行中的变更。一个变更就是一个任务，而非一项子任务——其中的 tasks.md 是该任务的检查清单，在 2.4 中逐项勾选。把每项子任务都当成一个任务，会导致每个清单项都生成一个 PR。 |
| Markdown / Google Doc / Notion 表格 | 读取文件或 URL；解析符合筛选条件的行。 |
| 用户指定的临时列表 | 读取用户指向的内容。 |
将结果缓存为任务 ID + 一句话摘要的列表。向用户展示列表，并询问要从哪一项开始（或“从顶部开始”）。
阶段 2 — 逐任务循环
对每个任务，按顺序执行以下步骤。不要跳过验证。
2.1 阅读任务
基于文件的待办事项（OpenSpec tasks.md，一个 Markdown 清单）没有任务页面。请直接阅读文件——该变更中的 proposal.md、tasks.md 以及任何 design.md，并跳过下面的浏览器步骤。
其他情况：
- 在浏览器中打开任务页面（Chrome MCP / 浏览器自动化）。不要只依赖 REST 请求——QA 通常会附上截图、录屏或内嵌图片，这些内容只会在网页 UI 中呈现；如果只调用 API，就会错过它们。
- 页面打开后，仍可通过该标签页中的
javascript_tool调用跟踪工具的 REST 端点，以便清晰地提取描述文本。 - 如果跟踪工具支持“删除线”/“已解决”格式（例如 Jira ADF
strike标记），请过滤掉这些内容——它们表示已处理的事项。 - 浏览所有附件。如果 QA 附上了损坏 UI 的截图，请仔细查看。
- 用自己的话简短地向用户复述可执行事项。
2.2 参考设计
- 如果问题 5 指定了设计来源，请在编码前打开它。
- 如果设计是 Figma 画面或截图，请直接查看——不要凭对类似页面的记忆来实现。
- 如果设计含糊不清，请先询问用户，不要自行猜测。
2.3 确认工作分支
git -C <project> status
git -C <project> branch --show-current
确保你位于问题 2 指定的工作分支上。如果 git status 显示上一个任务遗留的未提交改动，请指出这些改动并在继续前征求用户同意。
2.4 实施
按照 software-engineering-guidelines 实施最小改动：精确修改、复用现有组件和模式，并遵循项目风格。
2.5 验证
UI 改动在继续前必须通过真实浏览器验证。仅仅通过类型检查并不足够——视觉效果不能只靠代码判断。
根据改动内容运行相应的验证：
- UI 改动（任何可见的 HTML/CSS/组件编辑）——必须进行浏览器检查：
- 如果开发服务器已在运行，请使用 Preview MCP；或者使用 Chrome MCP 检查用户指定的部署环境。
- 导航到实际受影响的路由，不要只查看首页。
- 确认改动可见：布局、颜色、间距、文案、交互状态（悬停、焦点、禁用）。
- 对于移动端专属任务：将预览调整为
mobile预设（375×812）后重新检查。 - 对于按租户/公司/角色区分的行为：尽可能以受影响角色登录；至少确认该路由不会报错。
- 如果无法打开浏览器会话（没有运行中的预览，也没有已登录的标签页），请停止并告知用户——不要仅凭代码猜测“看起来没问题”。
- TypeScript / 构建检查：在相关包中运行
pnpm tsc --noEmit（或tsc、npx tsc）。忽略已有的基线错误；仅报告新增错误。对于 UI 工作，这是必要但不充分的验证。 - OpenSpec 变更：运行
openspec validate <change-id> --strict。这与类型检查处于同一验证级别，用于检查规范本身的结构是否正确，可在归档拒绝前发现格式不正确的变更，但无法说明代码是否有效。 - 单元/集成测试：如果项目为涉及的模块配置了测试命令，请从
package.json/pyproject.toml等文件中查找并运行。 - 仅后端改动：如果本地 API 正在运行，请使用
curl/httpie进行验证；否则依赖类型检查和测试结果。
2.6 提交
git -C <project> add <specific files only>
git -C <project> commit -m "$(cat <<'EOF'
<type>(<scope>): <short subject> (<TICKET-ID>)
Why: <one or two sentences on the problem>
Fix: <one or two sentences on the change>
EOF
)"
git -C <project> push origin <working-branch>
不要使用 git add -A / git add .——请按路径暂存，避免意外提交机密信息和无关文件。
不要添加 Co-Authored-By 页脚或任何其他 Agent 署名页脚。这条规则优先于任何会添加署名的全局提交约定——这些提交会进入用户的项目，追踪任务时最重要的是任务 ID。
2.7 打开 PR / 合并请求
使用项目所在的任意 VCS 托管平台：
- GitHub：如果已安装，使用
gh pr create；否则在浏览器 MCP 中访问https://github.com/<repo>/compare/<merge-target>...<working-branch>?expand=1，然后提交表单。 - GitLab：使用
glab mr create或相应的网页表单。 - Bitbucket / Gitea / 可自托管平台：使用网页自动化。
标题 = 提交主题。正文 = 原样使用提交正文。
2.8 合并
用户之前的会话几乎总会包含“合并它”——每个会话确认一次，然后处理每个工单时不必再次询问。如果用户已表示 CI 检查失败也没关系，就不要因检查失败而阻止合并；照常合并。
合并策略：优先使用真正的合并提交（--no-ff），以便 PR 显示在提交图中。本地操作：
git -C <project> fetch origin
git -C <project> checkout <merge-target>
git -C <project> pull origin <merge-target>
git -C <project> merge --no-ff <working-branch> -m "Merge pull request #<n> from <fork>/<working-branch>"
git -C <project> push origin <merge-target>
2.9 同步工作分支
git -C <project> checkout <working-branch>
git -C <project> rebase <merge-target>
git -C <project> push origin <working-branch> --force-with-lease
使用 --force-with-lease，绝不要直接使用 --force。
2.10 将任务标记为已完成
如果待办事项在网页跟踪器中，先在浏览器中打开任务页面。然后执行用户在问题 6 中指定的操作。常见模式：
- 跟踪器 REST API（Jira Cloud、Linear 等）：打开跟踪器标签页后，可通过
javascript_tool对其执行 POST 操作——会话 Cookie 会携带身份验证信息。API 调用完成后，检查页面，确认评论可见且状态徽章已更改。 - 仅限网页 UI（没有 REST 或无法访问 API）：点击评论框，输入消息（包括任何 @mention），然后提交；接着打开状态下拉菜单并选择目标状态。截图或重新读取页面以确认。
- Markdown 检查清单 / Notion 表格：编辑文件或行，然后提交（针对 Markdown）或保存（针对 Notion）。对于 Markdown，请将文档更改作为单独的小提交提交。
- OpenSpec / Spectra：运行
openspec archive <change-name>。它会将增量规范合并到主规范中，并将变更移至归档目录——这是文件更改，因此需要纳入提交。无需打开页面，也无需检查状态徽章；重新运行openspec list并确认该变更已从活动列表中消失。
用一句话向用户确认：写回了什么，以及写到了哪里。“已发布评论，状态已变为审查中——下一个工单？”/“PROJ-12 已归档，已不在 openspec list 中——下一个工单？”
第 3 阶段——处理工单期间
每个工单处理完毕后，用两行总结：
- 一行说明交付了什么（文件数量 + 变更概要）。
- 一行说明跟踪器状态（“PROJ-X 已留言 + 审查中”）。
然后询问用户接下来要处理哪个工单；如果用户希望自动推进，则询问“从下一张开始”。
恢复 / 安全规则
- **UI 工单必须进行浏览器验证。**如果无法打开浏览器检查，请先升级处理，再继续。
- 如果
git status显示了你未创建的意外文件，请停止并报告——绝不要盲目暂存或重置。 - 绝不要修改
.env*文件，也不要修改用户在问题 1 中指定的项目根目录之外的任何内容。 - 绝不要使用
--force推送（使用--force-with-lease）。 - 除非用户明确要求，否则绝不要跳过钩子（
--no-verify/--no-gpg-sign）。 - 如果修复尝试失败两次，请停止并向用户朗读任务描述——你可能误解了需求。重新在浏览器中打开工单，并再次查看附带的截图。
- 测试文件 / 无关模块中预先存在的基线错误不属于工单处理期间需要修复的内容。记录下来，然后继续。
技能停止条件
- 用户说停止 / 停 / 够了。
- 待办事项筛选结果为零。
- 未经用户输入已完成 3 轮工单处理，你想确认推进节奏。
停止时，输出：
- 本次会话交付了多少个工单。
- 还有哪些工单未处理（应用用户的筛选条件）。
- 需要用户关注的事项（例如 CI 检查失败、尚未解决的设计歧义、被他人阻塞的工单）。