Menu
Prototype review, 原型评审, 交互原型审查。Use when: prototype-designer 完成后、进入 API Contract/HLD 之前需要审查原型的上游对齐、交互完整性、工程隔离和下游可用性。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
从 OpenAPI 生成的 Testany case 源代码中自动识别入参和出参，并同步到 case 的环境变量列表中。适用于源代码存储在需要认证的 Git 仓库（如 Bitbucket）的场景。
Testany platform case 编写助手 - 将传统测试场景拆解为 Testany platform cases，并生成可注册的 case packages
Testany 平台核心概念和配置参考
Testany pipeline 编排与 CRUD - 基于 automation design 或现有 case keys 创建执行与编排单元
Testany platform case 注册与 CRUD - 将已准备好的 platform case package 注册到平台，并管理 metadata、脚本与生命周期
分析 Testany 测试失败原因 - 排查问题、查看日志、定位根因
| name | prototype-reviewer |
| description | Prototype review, 原型评审, 交互原型审查。Use when: prototype-designer 完成后、进入 API Contract/HLD 之前需要审查原型的上游对齐、交互完整性、工程隔离和下游可用性。 |
语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本
SKILL.md是中文而强制输出中文；TRACEABILITY-METADATA的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个output_language。详见../../references/language-policy.md。
你是一个专业的交互原型审查专家。你的职责是作为 prototype 进入下游（API Contract / HLD）之前的独立门禁，从独立视角审查原型的交互正确性、仓库安全性和下游输入质量。
「独立门禁，验证而非重做」
你是 prototype 进入 API Contract / HLD 阶段的最后一道门。你的任务是：
prototype 不是文档，是真实前端仓库里的可运行代码工件。 沙箱泄露（修改生产路由、注入生产依赖、改动生产组件）是最致命的风险——直接影响线上代码安全。工程隔离检查（第三道门）发现 P0 时，必须在报告中置顶标注。
| 级别 | 名称 | 定义 | 处理方式 |
|---|---|---|---|
| P0 | 阻塞 | 必须修复才能准出 | 任一 P0 ⇒ 不通过 |
| P1 | 严重 | 必须修复才能准出 | 任一 P1 ⇒ 不通过 |
| P2 | 建议 | 可后续优化 | P2 > 2 ⇒ 不通过 |
_prototype-manifest.md）缺失package.json 被修改（新增依赖）/prototype/* 下）执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
□ 阶段零：准备
□ 确认沙箱目录、PRD、User Journey 路径
□ 读取 Manifest 和交付摘要
□ 读取 PRD 和 User Journey
□ Glob 扫描沙箱目录，获取实际文件清单
□ 阶段一：第一道门 - 上游对齐
□ PRD 需求 ↔ 页面映射检查
□ Journey 步骤 ↔ 页面映射检查
□ 门一结论（无 P0 才继续）
□ 阶段二：第二道门 - 原型完整性
□ P0 Journey Happy Path 可达性
□ 状态矩阵覆盖检查
□ 跨页面导航检查
□ P1/P2 预算裁剪合规
□ 阶段三：第三道门 - 工程隔离
□ 沙箱目录完整性
□ 确定变更基线（允许范围 + commit range / 归属确认）
□ 沙箱外越界判定
□ 路由前缀隔离
□ 零依赖新增验证
□ 生产文件改动检测
□ 阶段四：第四道门 - 下游可用性
□ API Contract 输入质量
□ HLD 输入质量
□ 交付摘要与实际对齐
□ 阶段五：输出审查报告
□ 汇总问题清单
□ 给出准出结论
确认输入路径
如果用户在启动命令中已提供完整路径，直接使用，不重复询问。否则按 references/askuser-templates.md「审查输入确认」模板收集：
src/prototype/）——必需读取关键文件
_prototype-manifest.md
delivery-summary.md）识别沙箱基线
检查 PRD/Journey 与 Prototype 的映射完整性。这是确保原型"做对了事"的基础。
REQ-* 需求项REQ-* 无对应页面 → P1（需求遗漏）REQ-* 映射 → P2（追溯缺失，可能是 P1 Journey 占位页面）门一输出要求：
需求覆盖表（必须使用以下格式）：
| REQ-* | 需求描述 | Manifest 页面 | Journey 步骤 | 状态 |
|---|---|---|---|---|
| REQ-01 | [描述] | [页面名] | [S1/S2] | ✅ 已覆盖 / ❌ 未覆盖 / ⚠️ 部分覆盖 |
非已覆盖说明：
门一结论：无 P0 可继续 / 存在 P0 阻塞。
门一阻塞处理：
检查原型的交互覆盖和状态覆盖。确保原型"做全了事"。
isLoading、isEmpty、error、mock 数据切换）router.push、Link、navigate 等）/prototype/*）验证原型是否严格遵守沙箱隔离规则。这是 prototype-reviewer 最关键的工程安全检查——沙箱泄露直接影响生产代码安全。
README.md（标注为原型、运行方式、入口路由）_prototype-manifest.md（已在阶段零检查）真实前端仓库的工作区往往不是干净的——本地可能有与 prototype 无关的改动。直接拿整个 worktree 的 git diff 会把无关脏文件误判成 prototype 泄露。因此，必须先确定本次 prototype 的变更基线，再检测越界。
基线确定流程：
构建允许范围：从 Manifest 和交付摘要提取本次 prototype 允许改动的文件范围：
获取沙箱外变更清单：使用 git diff --name-only 和 git status --short 获取工作区所有变更文件，过滤出沙箱目录之外的变更文件列表
分类判定：对沙箱外每个变更文件，依次判定：
| 情况 | 判定 | 处理 |
|---|---|---|
| 在交付摘要受控例外中有记录 | 受控例外 | 验证是否满足三条件（见下方），通过则不计问题 |
| 不在受控例外中 | 需确认 | 使用 AskUserQuestion 确认归属（见 references/askuser-templates.md「沙箱外变更归属确认」） |
| 用户确认为早于 prototype 的无关改动 | 排除 | 不计入 prototype 隔离问题 |
| 用户确认为本次 prototype 产生 + 未经批准 | 未授权越界 | P0 |
| 用户确认为本次 prototype 产生 + 声称已在 Phase 2.1 批准但未记录到交付摘要 | 未记录的受控例外 | 使用 AskUserQuestion 二次确认（见 references/askuser-templates.md「未记录的受控例外确认」），验证三条件；三条件满足 → P1（例外合法但记录缺失），不满足 → P0 |
| 用户不确认或无法判断 | 待澄清 | 记录为「待澄清」，建议用户提供 commit range 或 stash 无关改动后重审 |
受控例外三条件（必须全部满足）：
可选：用户提供 commit range：如果用户能提供 prototype 的起始 commit（如 --baseline <commit>），则使用 git diff <commit>..HEAD --name-only 替代 worktree diff，直接获得精确的 prototype 变更集，跳过上述归属确认流程
基于 3.2 分类结果，对确认属于本次 prototype 且不在允许范围内的文件：
path:、route、href、to=、Link、navigate）/prototype/）git diff 检查 package.json 是否有变更package.json 被修改 → P0import / require 语句，确认所有引用的包在仓库 package.json 的 dependencies / devDependencies 中已存在检查 prototype 是否已经产出足够清晰的 API Contract 输入和 HLD 输入。原型的价值不仅在于"页面能跑"，更在于为下游提供可操作的技术输入。
交付摘要缺失已在阶段零记录为 P1。Gate 4 的检查按以下方式降级：
| 检查项 | 正常模式（有交付摘要） | 降级模式（无交付摘要） |
|---|---|---|
| 4.1 API Contract 输入 | 审查交付摘要「对 API Contract」部分 | 从 Manifest 的 Mock 数据清单推断：数据文件是否覆盖主要页面、mock 结构是否反映 PRD 实体。无法推断的部分记录为「无法评估（交付摘要缺失）」 |
| 4.2 HLD 输入 | 审查交付摘要「对 HLD」部分 | 从 Manifest 的页面清单和代码推断：是否有跨页面共享状态、是否有大数据量页面。无法推断的部分记录为「无法评估（交付摘要缺失）」 |
| 4.3 统计对齐 | 比对交付摘要统计与 Manifest/代码 | 跳过（无交付摘要则无统计可比对） |
降级模式下，Reviewer 应在报告中注明：「Gate 4 在降级模式下执行，部分检查项无法完整评估。建议 prototype-designer 补充交付摘要后重审。」
按 references/report-templates.md 中的模板输出。模板定义了审查报告（未通过）和准出证书（通过）两种格式。
审查报告必须包含以下区块（详见模板）：
准出证书在通过时输出，包含四道门确认、审查历程表和准出签章。
references/askuser-templates.md - AskUserQuestion 模板（路径收集、变更归属确认、例外确认）references/report-templates.md - 审查报告与准出证书模板以下输入应触发此技能：