名称: 工作流-工作 描述: 高效执行工作计划，同时保持质量并完成功能
参数
[计划文件、规范或待办文件路径]
工作计划执行命令
高效执行工作计划，同时保持质量并完成功能。
介绍
此命令接受一个工作文档（计划、规范或待办文件）并系统化执行。重点是交付完整功能，通过快速理解需求、遵循现有模式和全程保持质量。
输入文档
<input_document> #$ARGUMENTS </input_document>
执行工作流
阶段1：快速启动
-
阅读计划并澄清
- 完整阅读工作文档
- 审查计划中提供的任何参考或链接
- 如果有任何不清晰或模糊之处，现在提出澄清问题
- 获取用户批准以继续
- 不要跳过此步骤 - 最好现在提问，而不是构建错误的东西
-
设置环境
首先，检查当前分支：
current_branch=$(git branch --show-current) default_branch=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@') # 如果远程HEAD未设置，则回退 if [ -z "$default_branch" ]; then default_branch=$(git rev-parse --verify origin/main >/dev/null 2>&1 && echo "main" || echo "master") fi如果已在功能分支上（非默认分支）：
- 询问：“继续在
[current_branch]上工作，还是创建新分支？” - 如果继续，继续步骤3
- 如果创建新分支，遵循选项A或B
如果在默认分支上，选择如何继续：
选项A：创建新分支
git pull origin [default_branch] git checkout -b feature-branch-name使用基于工作的有意义名称（例如
feat/user-authentication、fix/email-validation）。选项B：使用工作树（推荐用于并行开发）
skill: git-worktree # 该技能将在隔离的工作树中从默认分支创建新分支选项C：继续在默认分支上
- 需要明确的用户确认
- 只有在用户明确说“是，提交到 [default_branch]”后才继续
- 没有明确许可，绝不直接提交到默认分支
推荐：如果以下情况，使用工作树：
- 你想同时处理多个功能
- 你想在实验时保持默认分支清洁
- 你计划频繁切换分支
- 询问：“继续在
-
创建待办列表
- 使用TodoWrite将计划分解为可执行任务
- 包括任务之间的依赖关系
- 基于需要先完成的任务进行优先级排序
- 包括测试和质量检查任务
- 保持任务具体且可完成
阶段2：执行
-
任务执行循环
按优先级顺序对每个任务：
while (任务剩余): - 在TodoWrite中将任务标记为进行中 - 从计划中阅读任何参考文件 - 在代码库中寻找相似模式 - 遵循现有约定实施 - 为新功能编写测试 - 更改后运行测试 - 在TodoWrite中将任务标记为已完成 - 在计划文件中勾选相应复选框（[ ] → [x]） - 评估是否进行增量提交（见下文）重要：始终通过勾选已完成项目来更新原始计划文档。使用编辑工具将
- [ ]更改为- [x]对于每个完成的任务。这使计划作为一个显示进度的活动文档，并确保没有复选框留下未勾选。 -
增量提交
完成每个任务后，评估是否创建增量提交：
提交时机… 不提交时机… 逻辑单元完成（模型、服务、组件） 较大单元的小部分 测试通过 + 有意义的进展 测试失败 即将切换上下文（后端 → 前端） 纯脚手架无行为 即将尝试有风险/不确定的更改 需要“WIP”提交消息 启发式：“我能写出描述一个完整、有价值的更改的提交消息吗？如果可以，提交。如果消息是‘WIP’或‘部分X’，则等待。”
提交工作流：
# 1. 验证测试通过（使用项目的测试命令） # 示例：bin/rails test, npm test, pytest, go test 等。 # 2. 仅暂存与此逻辑单元相关的文件（不是 `git add .`） git add <与此逻辑单元相关的文件> # 3. 使用约定提交消息 git commit -m "feat(范围): 描述此单元"处理合并冲突：如果在变基或合并过程中出现冲突，立即解决。增量提交使冲突解决更容易，因为每个提交都小而集中。
注意：增量提交使用干净的约定消息，无归属页脚。最终的阶段4提交/PR包括完整归属。
-
遵循现有模式
- 计划应参考类似代码 - 先阅读那些文件
- 准确匹配命名约定
- 尽可能重用现有组件
- 遵循项目编码标准（见CLAUDE.md）
- 有疑问时，grep寻找类似实现
-
持续测试
- 每次显著更改后运行相关测试
- 不要等到最后才测试
- 立即修复失败
- 为新功能添加新测试
-
Figma设计同步（如果适用）
对于带有Figma设计的UI工作：
- 实施组件遵循设计规范
- 迭代使用figma-design-sync代理进行比较
- 修复识别的视觉差异
- 重复直到实现匹配设计
-
跟踪进度
- 完成任务时保持TodoWrite更新
- 记录任何阻塞或意外发现
- 如果范围扩展，创建新任务
- 保持用户了解重大里程碑
阶段3：质量检查
-
运行核心质量检查
在提交前始终运行：
# 运行完整测试套件（使用项目的测试命令） # 示例：bin/rails test, npm test, pytest, go test 等。 # 运行代码检查（根据CLAUDE.md） # 推送前使用linting-agent -
考虑审查代理（可选）
用于复杂、有风险或大型更改：
- code-simplicity-reviewer：检查不必要的复杂性
- kieran-rails-reviewer：验证Rails约定（Rails项目）
- performance-oracle：检查性能问题
- security-sentinel：扫描安全漏洞
- cora-test-reviewer：审查测试质量（具有全面测试覆盖的Rails项目）
使用任务工具并行运行审查代理：
Task(code-simplicity-reviewer): "审查更改以简化" Task(kieran-rails-reviewer): "检查Rails约定"向用户呈现发现并解决关键问题。
-
最终验证
- TodoWrite中所有任务标记为已完成
- 所有测试通过
- 代码检查通过
- 代码遵循现有模式
- Figma设计与实现匹配（如果适用）
- 无控制台错误或警告
阶段4：交付
-
创建提交
git add . git status # 审查即将提交的内容 git diff --staged # 检查更改 # 使用约定格式提交 git commit -m "$(cat <<'EOF' feat(范围): 描述是什么和为什么 如果需要，简要解释。 🤖 由 [Claude Code](https://claude.com/claude-code) 生成 Co-Authored-By: Claude <noreply@anthropic.com> EOF )" -
捕获并上传UI更改的屏幕截图（任何UI工作必需）
对于任何设计更改、新视图或UI修改，你必须捕获并上传屏幕截图：
步骤1：启动开发服务器（如果未运行）
bin/dev # 后台运行步骤2：使用agent-browser CLI捕获屏幕截图
agent-browser open http://localhost:3000/[路由] agent-browser snapshot -i agent-browser screenshot output.png详见
agent-browser技能。步骤3：使用imgup技能上传
skill: imgup # 然后上传每个屏幕截图： imgup -h pixhost screenshot.png # pixhost无需API密钥 # 替代主机：catbox, imagebin, beeimg捕获内容：
- 新屏幕：新UI的屏幕截图
- 修改的屏幕：前 AND 后屏幕截图
- 设计实现：显示Figma设计匹配的屏幕截图
重要：始终在PR描述中包括上传的图像URL。这为审查者提供视觉上下文并记录更改。
-
创建拉取请求
git push -u origin feature-branch-name gh pr create --title "功能: [描述]" --body "$(cat <<'EOF' ## 总结 - 构建了什么 - 为什么需要 - 关键决策 ## 测试 - 添加/修改的测试 - 执行的测试 ## 前 / 后屏幕截图 | 前 | 后 | |--------|-------| |  |  | ## Figma设计 [如果适用，链接] --- [](https://github.com/EveryInc/compound-engineering-plugin) 🤖 由 [Claude Code](https://claude.com/claude-code) 生成 EOF )" -
通知用户
- 总结完成的内容
- 链接到PR
- 注意任何后续工作
- 如果适用，建议下一步
关键原则
快速启动，更快执行
- 开始时澄清一次，然后执行
- 不要等待完美理解 - 提问并行动
- 目标是完成功能，而不是创建完美过程
计划是你的指南
- 工作文档应参考类似代码和模式
- 加载那些参考并遵循
- 不要重新发明 - 匹配现有内容
边做边测试
- 每次更改后运行测试，不要等到最后
- 立即修复失败
- 持续测试防止大意外
质量内置
- 遵循现有模式
- 为新代码编写测试
- 推送前运行代码检查
- 仅用于复杂/有风险更改时使用审查代理
交付完整功能
- 移动前标记所有任务完成
- 不要把功能做到80%
- 一个完成并交付的功能胜过不完美的功能
质量检查清单
创建PR前，验证：
- [ ] 所有澄清问题已问并回答
- [ ] TodoWrite中所有任务标记为已完成
- [ ] 测试通过（运行项目的测试命令）
- [ ] 代码检查通过（使用linting-agent）
- [ ] 代码遵循现有模式
- [ ] Figma设计与实现匹配（如果适用）
- [ ] 捕获并上传前/后屏幕截图（对于UI更改）
- [ ] 提交消息遵循约定格式
- [ ] PR描述包括总结、测试笔记和屏幕截图
- [ ] PR描述包括复合工程徽章
何时使用审查代理
默认不使用。 仅在以下情况使用审查代理：
- 影响许多文件的大型重构（10+）
- 安全敏感更改（身份验证、权限、数据访问）
- 性能关键代码路径
- 复杂算法或业务逻辑
- 用户明确请求全面审查
对于大多数功能：测试 + 代码检查 + 遵循模式已足够。
常见陷阱避免
- 分析瘫痪 - 不要过度思考，阅读计划并执行
- 跳过澄清问题 - 现在提问，而不是构建错误后
- 忽略计划参考 - 计划有链接是有原因的
- 最后测试 - 持续测试，否则后面受苦
- 忘记TodoWrite - 跟踪进度，否则失去跟踪
- 80%完成综合征 - 完成功能，不要过早移动
- 过度审查简单更改 - 为复杂工作保留审查代理