用途：执行由 spec-driven-planning 产出的规划产物，并按模式运行对应流程。触发时机包括：用户说“实现这个功能”“开始写代码”“执行计划”，或提到 tasks、TDD、execution，或规划阶段已完成。
模式识别（先做）：在 docx/features/ 中选择最近或用户指定的功能目录，然后按目录内文件判断模式。仅有 plan.md 为 Quick 模式；仅 tasks.md 或 tasks.md + plan.archived.md 为 Full 模式；plan.md 与 tasks.md 同时存在且无归档时属歧义状态，需停止并询问用户哪个文件为准；两者都无则报错，提示先运行 /dev-workflow:spec。plan.archived.md 仅作参考，不影响模式判断。识别后先公布模式。
Quick 模式：来源为 plan.md，采用基于行为的验证而非测试套件。先通读计划并做预检，检查文件路径是否真实、步骤能否达成目标、是否有明显缺口；有问题先反馈等待指引。随后逐任务执行：在 Progress 中将任务标记为进行中，逐步执行动作并运行计划中的验证命令，对比预期输出，不符即停止询问，完成后用 Edit 将步骤复选框改为已勾选并提交，最后标记任务完成。规则：不强制红–绿–重构，计划有测试步骤才执行，不擅自扩大范围，被阻塞就停止。
Full 模式：来源为 requirements.md、design.md、tasks.md。先做前置检查与预检（路径真实性、需求是否匹配、设计是否满足需求、缺口），有问题先停止提问。Phase 4 按 TDD 拆解任务，每个任务含 RED、GREEN、REFACTOR、验收标准与关联需求 ID，任务规模约 30–60 分钟，需可独立测试并做需求可追溯。Phase 5 逐任务执行：标记进行中，写失败测试并验证失败、提交；写最小实现使测试通过、提交；重构并保持测试通过、提交；勾选完成、更新 Progress Summary。每 2–3 个任务提供检查点，更新测试、类型检查、lint、完成数等。
跟踪要求：必须用 Edit 工具更新 tasks.md 的复选框与状态，而非仅口头汇报；每次任务完成同步 Progress Summary；若发现需求缺失或设计问题，应返回规划阶段，使用 /dev-workflow:spec 更新规划文档。相关技能包括 test-driven-development、git-workflow、review。