用途：该技能专用于前端规划阶段。它接收设计文档，生成测试骨架，创建前端工作计划，并对计划进行审查，最终需要用户批准计划内容后才算完成。
主要能力：
- 设计文档选择：检查 docs/design/ 下是否存在设计文档；若存在多份会给出选项（可通过 $ARGUMENTS 指定）。若无设计文档，则通知用户并中止。
- 测试骨架生成：通过 acceptance-test-generator 从设计文档生成测试骨架，若存在 UI Spec 也会传入。
- 工作计划创建：通过 work-planner 创建设计文档对应的工作计划，并传入集成测试文件、fixture-e2e 测试文件、service-integration-e2e 测试文件以及各 lane 缺少 E2E 的原因；集成测试随每个阶段实现创建，fixture-e2e 与 UI 实现并行运行，service-integration-e2e 仅在存在服务 E2E 文件的最终阶段运行；工作计划头部包含 Implementation Readiness: pending。
- 工作计划审查：通过 document-reviewer 以 composite 模式审查，检查语义可追溯性、Reference Contract Values 保真度、早期验证位置、真实边界验证覆盖、Proof Strategy、Failure Mode Checklist、Review Scope 和 Quality Assurance 覆盖。
- 审查结果分支：approved 则让 work-planner 更新状态为 approved、Conditions: none，进入下一步；approved_with_conditions 或 needs_revision 则根据发现或条件更新后重复审查，最多 2 次修订迭代；rejected 则停止并向用户呈现阻塞性发现。
- 计划批准：与用户交互以完成计划并获取批准，澄清具体实现步骤和风险；未获用户明确批准不得继续。
使用方式：在执行前需要加载 documentation-criteria、implementation-approach、subagents-orchestration-guide、llm-friendly-context 等技能（如未激活）。每次 spawn_agent 调用使用 fork_turns="none"，使子代理仅接收任务消息和显式提供的上下文。
适用场景：前端开发规划阶段，尤其是在需要从设计文档派生测试骨架、生成可审查工作计划的流程中。
限制：必须存在设计文档，否则会阻塞并中止；完成标准包括设计文档已选择、测试骨架已生成、工作计划已创建、已通过 document-reviewer 审查以及用户已批准计划内容。未批准的计划无效。该资料未提供具体收费、价格、平台或额外安装命令信息。