用途：当已存在计划或规格文档，并希望以 Eve 作业方式编排实施工作时使用。典型触发方式是初始作业说明“use eve-plan-implementation to implement the plan”。
编排模型：根 epic 是编排者，只负责规划、委派与协调，不亲自执行重活；阶段作业是子编排者，把阶段拆成任务；任务作业是执行者，各自接收自包含描述并独立执行，无法访问父级上下文。
工作流：1）加载上下文，读取计划文档提取阶段、交付物与阻塞项，如有 AGENTS.md 则读取仓库规则，并用 eve job current --json 获取当前作业上下文；编排者保持轻量，深度分析交给执行作业。2）创建或确认根 epic，使用 eve job create --project $EVE_PROJECT_ID --description "Implement <plan name>" --review human --phase backlog。3）按阶段创建子作业，并用 eve job dep add $EVE_JOB_ID $PHASE_JOB_ID --type waits_for 建立依赖。4）每个阶段拆成 2-6 个原子任务；若阶段只有一个任务则直接在阶段作业中执行。任务描述必须自包含，包含目标、交付物、文件路径、约束与上下文。5）默认并行，独立任务不加依赖，仅对真正需要顺序的场景使用 blocks。6）执行任务并更新阶段，使用 eve job update、eve job submit，无需评审时用 eve job close。7）增加专门的验证作业，门控在实施任务之后；所有任务完成后提交阶段作业，所有阶段完成后提交根 epic 供评审。8）编排者创建子作业并接好依赖后返回等待信号，释放资源让子作业并行执行。
上下文管理：编排者只读足够规划拆解的内容，把文件路径、约定、约束推入子描述，让执行者自行读取与分析，避免重复工作。
可选 Git 控制：若任务需在共享分支改代码，可在创建作业时使用 --git-ref、--git-ref-policy、--git-branch、--git-create-branch、--git-commit、--git-push 等参数，并保持各任务一致以便汇入同一 PR。
限制：资料未提供具体收费、平台支持范围或效果数据；执行者无法访问父级上下文，因此任务描述必须完整，否则可能失败。