计划工作执行器Skill phx:work

---

name: phx:work description: 从计划文件执行实施。通过复选框跟踪进度，每个任务后运行验证。智能体工作流的执行阶段。 argument-hint: <计划文件路径>

工作

从计划文件执行任务，带有检查点跟踪和验证。

用法

/phx:work .claude/plans/user-auth/plan.md
/phx:work .claude/plans/user-auth/plan.md --from P2-T3
/phx:work --skip-blockers
/phx:work  # 恢复最近使用的计划

参数

• <plan-file> – 计划文件路径（可选，自动检测最近的）
• --from <task-id> – 从特定任务恢复（例如，P2-T3）
• --skip-blockers – 跳过被阻塞的任务继续执行
• --continue – 从复选框恢复进行中的计划

铁律（不可协商）

1. 绝不自动进行到 /phx:review 或任何下一个工作流阶段——总是询问用户下一步做什么
2. 在计划阶段之间自动继续——当阶段 N 完成时，立即开始阶段 N+1。不要在阶段之间停止或请求许可。仅在遇到阻塞或所有阶段完成时停止。
3. 计划复选框就是状态——[x] = 完成，[ ] = 待处理。没有单独的 JSON 状态文件。通过读取计划恢复。
4. 每个任务后验证——绝不跳过验证
5. 最多重试 3 次然后阻塞——不要无限重试
6. 暂存特定文件——绝不使用 git add -A 或 git add .

步骤 1：研究决策

对于超过 3 个任务的计划，询问用户：

这个计划有 {count} 个剩余任务，分布在 {count} 个阶段中。

1. 开始工作——立即开始（熟悉模式）
2. 快速研究——先阅读源文件（约 10 分钟）
3. 深入研究——网页搜索 + 文档（约 30 分钟）

对于 3 个或更少简单任务的计划，跳过此步骤——直接开始。

拆分警告：超过 10 个任务的计划可能经历 2-3 次上下文压缩。如果尚未拆分，建议通过 /phx:plan 拆分。

步骤 2：检查上下文

检查复合文档和草稿本中的先前决策：

grep -rl "关键词" .claude/solutions/ 2>/dev/null
grep -A 3 "决策\|死胡同" .claude/plans/{slug}/scratchpad.md 2>/dev/null

应用发现：跳过死胡同，遵循决策。不要加载整个草稿本——仅进行针对性 grep。

步骤 3：加载和恢复

读取计划文件，统计 [x]（已完成）与 [ ]（剩余）。通过 [Pn-Tm] ID 找到第一个未检查的任务。

使用 --from P2-T3：跳到该特定任务。

查看 references/resume-strategies.md 获取所有恢复模式。

步骤 4：执行任务

对于每个未检查的任务（- [ ] [Pn-Tm][agent] 描述）：

1. 路由 通过 [agent] 注释（见 references/execution-guide.md）
2. 实施 任务
3. 验证：mix format + mix compile --warnings-as-errors （在阶段结束时，还运行 mix test <affected>——见以下层级）
4. 标记 复选框 [x] 在通过时，内联追加实施注释：关键决策、陷阱、实际使用的值。示例： - [x] [P1-T3] 添加用户模式——使用 citext 作为电子邮件，在 [user_id, status] 上创建复合索引 这能存活上下文压缩；恢复时重新读取计划。
5. 失败时：最多重试 3 次，然后创建阻塞并在草稿本中写入死胡同（见 error-recovery.md）

并行组：在 ### Parallel: 标题下的任务作为后台子代理生成。见 references/execution-guide.md 获取生成模式、提示模板和检查点流。

验证层级：

• 每任务：mix format + mix compile --warnings-as-errors （当 Tidewave 可用时，还在编辑后检查 get_logs :error）
• 每阶段：上述 + mix test <affected> + mix credo --strict
• 每功能（Tidewave）：通过 project_eval 进行行为冒烟测试 （创建记录、获取、验证——见 execution-guide.md）
• 最终关卡：mix test（完整套件）

Linter 注意：PostToolUse 钩子检查格式化但不修改文件。在验证步骤或提交前显式运行 mix format。

步骤 5：完成

用 AskUserQuestion 总结结果：

实施完成！{done}/{total} 个任务已完成。 {count} 个文件被修改，跨 {count} 个阶段。

选项：1. 运行审查 (/phx:review)（推荐）， 2. 获取简报 (/phx:brief——了解构建了什么）， 3. 提交更改 (/commit)，4. 手动继续。

有阻塞时：列出它们，提供 重新计划 (/phx:plan)、 先审查 (/phx:review)，或 自行处理。

如果阻塞仍存在，自动写入 HANDOFF 到草稿本：

### [HH:MM] HANDOFF: {计划名称}
状态: {done}/{total} 个任务。阻塞: {列表}。
下一步: {第一个未检查任务 ID 和描述}。
关键决策: {本会话的简要列表}。

这提供了超越复选框的新会话上下文。

绝不自动开始 /phx:review 或任何其他阶段。

步骤 6：检查其他计划

完成后，检查其他待处理计划：

ls .claude/plans/*/plan.md 2>/dev/null

如果存在待处理计划，通知用户。不要自动开始。

集成

/phx:plan → /phx:work（你在此处）→ /phx:review → /phx:compound
                 ↑ 每次转换前询问用户

参考

• references/execution-guide.md——任务路由、并行执行、验证
• references/resume-strategies.md——恢复模式和状态持久化
• references/file-formats.md——计划和进度文件格式
• references/error-recovery.md——错误处理和阻塞