用途：作为混合提供商构建流程的规划环节，把前一探索步骤产出的上下文整理成一份三节规格，交给下游会话执行；属于推理较重的工作，需先把结构规划正确，避免错误逐级放大。
主要能力：读取 $ARGUMENTS 指向的 <run-name>-context.md，从中取得 Spec Path、Repo State、Framework Recommendation、Open Decisions；若上下文指向规格文件则完整阅读两遍，若为“none - description only”则以 Spec Summary 为规格。输出到 .claude/artifacts/<run-name>-plan.md，缺少目录时创建。
输出结构：必须使用固定标题。SECTION A - UI Scope 写明每个页面的路由、用途、内容，每个组件的名称、展示内容与出现位置，并写出实际面向用户的文案（标题、副标题、按钮标签、卡片标题、空状态与错误信息）；SECTION B - Integration Scope 列出所有非 UI 事项，包括认证提供商与流程、后端 API 端点（方法、路径、输入、输出、鉴权）、外部 API/SDK、数据模型（表、字段、索引、数据库）、后台任务；SECTION C - Deployment Plan 明确部署目标（如仅本地、Vercel、Fly.io 或认证提供商的部署命令），并列出部署前步骤与成功标准。选择部署目标或认证提供商时附一句理由。
使用方式：将上下文文件路径作为参数传入；若参数为空或路径无效，向用户询问上下文路径或先运行 /frontend-mix-explore，不臆造需求。运行名取自文件名的 <run-name> 前缀，供下游技能按文件名回读。完成后告知该计划文件的绝对路径与下一步。
限制与注意：不要从零重新探索仓库，仅在上下文确有歧义时用 Read/Glob 做抽查；避免集成关注点与 UI 文案混杂，两节内容若模糊需拆分；下游技能按精确标题提取章节，因此标题须原样使用。官方资料未提供收费、平台支持范围或效果保证等信息。