用途：aep-build 在隔离的 git worktree（.feature-workspaces/<name>）与其对应分支 feat/<name> 上自主实现单个功能。它接续 /aep-design 已完成的探索、提案、评审阶段（Phase 1–3），从 Phase 0（工作区初始化）开始，继续 Phase 4（实现）。链路位置：/aep-onboard → /aep-scaffold → [ /aep-design → /aep-launch → /aep-build → /aep-wrap ]。输入为磁盘上的 OpenSpec 工件，输出为已合并的 PR，运行在自主工作区会话中。
主要能力：
- Phase 0 初始化：先做 worktree 守卫，校验当前位于 .feature-workspaces/$WS 与分支 feat/$WS；发现 OpenSpec 变更（读 proposal.md、design.md、specs、tasks.md）；创建 .dev-workflow 并加入 .gitignore；从已安装技能模板生成进度文件、sprint 契约、功能验证清单、会话恢复脚本、信号与经验文件。
- Phase 4 实现：按 tasks.md 逐行线性实现，一行一次提交，提交格式 feat(<scope>): <task description>，并把短 SHA 写入 feature-verification.json 的 commit_sha（仅此字段由生成器负责）。可调用 /opsx:apply 获取逐任务指导；涉及 UI 的故事需遵守 Object Map。
- Phase 5 代码评审与验证：由 verification-recipe.json 的绑定层级决定是否启用独立评审者（standard/deep 启用，light 走结构化自评）。评审循环每轮最多 2 次，失败须先做分类（环境、测试工具抖动、范围、未构建依赖、产品缺陷），仅产品缺陷在阻塞级别继续。
使用方式与限制：每个阶段受统一 --max-turns 预算约束，达到上限视为“可能无法解决并升级”，不等于完成。循环不收敛或仍有阻塞问题时通过 Human-Gate Protocol 升级。worktree 由 /aep-launch 创建，aep-build 只进入而不自行创建；缺失即升级。资料未提供安装命令、具体代码内容之外的价格或平台支持信息。