用途：这是“逆向工程到规格驱动开发”流程的第 6 步（共 6 步），用于依据 specs/ 目录中的规格，系统性地实现缺失功能，并通过验收标准校验。
目录约定：规格与实现计划统一放在 specs/；分阶段实现路线图位于 docs/gap-analysis-report.md；会话状态与进度记录在 .stackshift-state.json。
上下文路由：先运行 git branch --show-current 获取当前分支。若为 main 或 master，执行 Context A（交接），读取 operations/handoff.md 并按其流程操作；若匹配 NNN-* 模式（如 002-feature-name），执行 Context B（标准实现）；两者都不匹配时需询问用户属于哪种情况。交接仅在初次逆向工程后发生一次，之后在功能分支上始终使用 Context B。
标准实现流程：1）阅读 docs/gap-analysis-report.md，识别 Phase 1（P0 关键）、Phase 2（P1 高价值）、Phase 3（P2/P3）分阶段计划，并与用户确认起点、阻塞项与时间限制；2）运行 /speckit.tasks [feature-name] 生成任务清单；3）运行 /speckit.implement [feature-name] 执行实现，逐项生成代码、按验收标准测试、更新规格状态标记并提交；4）运行 /speckit.analyze 校验实现与规格一致、验收标准满足、无冲突且状态标记准确，有问题则修复实现或先更新规格，直至无问题；5）更新 docs/gap-analysis-report.md 与 .stackshift-state.json，并提交 git commit -m "feat: implement [feature-name] ([spec-file].md)"；6）对路线图中每个功能重复步骤 2-5。
检查点与限制：P0 全部完成后暂停并向用户报告，确认后再进入 P1；P1 完成后同样暂停确认再进入 P2/P3。若需实现的功能超过 20 个，每完成 5 个暂停并报告累计进度。所有生成的代码在提交前需人工审查，不应盲目接受。命令失败或部分完成时，读取 operations/error-recovery.md 并按对应恢复流程处理。全部功能完成后，读取 operations/post-implementation.md 执行验证、审查与覆盖率映射；持续开发工作流参见 operations/continuous-development.md。
成功标准：P0、P1 全部实现，P2/P3 实现或有意推迟，specs/ 中所有规格标记为 COMPLETE，/speckit.analyze 无问题，所有测试通过，.stackshift-state.json 更新为最终状态。
其他信息（如具体平台支持、收费方式）暂未提供。