用途：spec-impl 是一个规范驱动的实现技能，读取 /spec-create 生成的 docs/features/<feature-name>/ 下的规范文件，逐个原子化执行 tasks.md 中的任务，保证可追溯性与测试覆盖。适用于规范已存在、准备实现，或会话中断后恢复实现的场景。创建规范用 spec-create，单任务测试先行用 tdd。
使用方式：调用 /spec-impl <feature-name>，feature-name 必填且须对应 docs/features/ 下已有目录。初始化时校验目录存在，读取 requirements.md、design.md、tasks.md 三份文件，并加载 references/verify-by-language.md 识别项目生态与测试运行器。
主要能力与流程：扫描 tasks.md，按文档顺序选取下一个未被阻塞（Blocked by 依赖均 Complete）且状态为 Not Started 或 In Progress 的任务；编码前复述目标、关键文件、业务规则与验证命令，并将状态置为 In Progress。当任务引用未验证的 TD-X 或在未触碰目录创建文件时，须做设计充分性检查，设计含糊则停下请用户更新设计。实现时若 Verify 命令是测试运行器（如 jest、vitest、pytest、cargo test、go test 等），遵循 tdd 的红绿重构循环，先写失败测试；否则直接实现后验证。运行任务中指定的确切 Verify 命令，退出码 0 才可标记 Complete，否则诊断失败：代码失败修代码（非测试，除非测试本身有误）并重跑；命令失败应告知用户并提供更正建议，经确认后再更新 tasks.md。完成后在 tasks.md 写入 Status: Complete 和一行 Result，通知用户审查与提交。可批量最多 3 个同一 Phase 的连续任务再暂停；Phase 0 [INFRA] 任务可全部批量后统一审查。
限制：不得在验证未通过时标记完成，不得替换验证命令（除非用户确认），不得跳过或乱序执行任务，不得执行 tasks.md 未列出的工作，不得依赖聊天历史（须从文件重建状态），设计含糊时不得臆测。依赖须来自 design.md，否则视为设计缺口并询问用户；文件须在 File Inventory 内，否则先告知用户。测试分单元、集成、E2E 三类按任务性质选择。语言特定验证命令模式见 references/verify-by-language.md。具体价格、平台支持等资料暂未提供。