spec-product-prototype（R3：基于 PRD 生成原型说明）

概览

R3 的目标是把 {FEATURE_DIR}/requirements/prd.md 的核心场景/规则/AC加工为 {FEATURE_DIR}/requirements/prototype.md：

• 任务流（Mermaid）+ 节点编号（T-001…）
• 页面/弹窗清单（P/D/W-001…）+ 节点覆盖关系
• 逐页说明：入口/控件/状态/跳转 + 纯 ASCII 线框
• AC → 交互节点映射：能回答“哪条 AC 在哪个页面/状态被验证”
• 走查/验证脚本：验证后能回流更新 R1/R2/R3，形成闭环

开始时宣布：「我正在使用 spec-product-prototype 技能基于 prd.md 生成可走查原型说明（prototype.md）。」

R3 不是强制步骤：是否进入 R3 由 using-aisdlc 作为唯一路由器判定；本技能只在被路由到 R3 时执行。

何时使用 / 不使用

• 使用时机
  • 已完成 R2，存在 {FEATURE_DIR}/requirements/prd.md，且需求存在新增/变更交互或交互不够明确，需要通过“文本原型 + 线框”消除实现/验收歧义
• 不要用在
  • spec-context 失败（上下文定位失败）→ 立刻停止
  • {FEATURE_DIR}/requirements/prd.md 缺失 → 停止并回到 R2
  • 如果你发现“此需求其实应跳过 R3”（无交互变化/交互简单明确）→ 停止并回到 using-aisdlc 重新路由（本技能不得在内部改写路由结论）

输入 / 输出（落盘约定）

• 硬门禁输入：FEATURE_DIR（必须由 spec-context 获取）
• 读取
  • {FEATURE_DIR}/requirements/prd.md（必读：场景/规则/AC/验证清单/原型分流结论）
  • {FEATURE_DIR}/requirements/solution.md（按需：验证清单引用/决策口径）
  • {FEATURE_DIR}/requirements/raw.md（按需：证据入口/原始措辞）
• 写入
  • {FEATURE_DIR}/requirements/prototype.md（R3 产物，优先按模板生成；模板见 <本SKILL.md目录>/assets/prototype-template.md）

门禁（必须先过，否则停止）

REQUIRED SUB-SKILL：先满足 spec-context 门禁并回显 FEATURE_DIR=...（允许 (reuse)）。

• spec-context 失败 → 停止
• {FEATURE_DIR}/requirements/prd.md 缺失 → 停止（不得“先出一版原型再说”）

违反门禁=违反精神：无论“老板 10 分钟后评审/用户催/用户不想跑脚本”，都禁止猜路径、禁止在缺少 PRD 的情况下编造原型。

核心流程（结构化落盘 → 可追溯验证；本技能不做下一步分流）

0) 防呆校验：若不应进入 R3，则停止并回到 using-aisdlc

若 PRD 明确表述“无需原型/R3 可跳过”，或你基于输入判断本次不应进入 R3，则停止并提示回到 using-aisdlc；由其决定在 prd.md 补齐最小交互结论或进入 design。

1) 从 PRD 提取“原型必须信息”（禁止新增决策）

只提取与交互走查直接相关的信息（不要在 R3 里发散新规则/新范围）：

• 核心场景（建议 ≤ 3 个）与成功标准
• AC 清单（按场景归类）
• 关键规则/口径（会影响交互与校验/提示）
• 风险/依赖与验证清单条目（引用编号）

若 PRD 缺少 AC、或缺少验证清单导致无法落盘：

• 停止并回到 R2（先把可交付规格补齐）

2) 用模板生成/更新 {FEATURE_DIR}/requirements/prototype.md

优先对齐模板：<本SKILL.md目录>/assets/prototype-template.md（只借结构，不把未知当已知）。下文 3–7 步为按模板填充各节的具体要求。

3) 生成任务流（Mermaid）与节点编号

• 节点编号：T-001…
• 每个场景至少一条端到端主链路（成功/失败/取消/返回等关键分支）
• 每个节点必须能落到页面/弹窗清单中的某个 Node ID

4) 生成页面/弹窗清单（可定位）

• 页面：P-001…
• 弹窗：D-001…
• 抽屉：W-001…
• 每个 Node 必须标注覆盖哪些 T-xxx、哪些场景、关联哪些 AC

5) 逐页写“可实现”的页面说明（含 ASCII 线框）

每个页面/节点一节，必须包含：

• 入口与目的（含前置条件；未知不得脑补，必须引用验证清单编号）
• ASCII 线框（必须，纯 ASCII 字符画）
• 状态与反馈（至少：正常/加载/空/错误/无权限；提交类交互含成功/失败反馈与恢复路径）
• 关键校验与错误处理（只写会影响 AC 的）
• 跳转与交互（成功/失败/取消/关闭/返回；高风险操作必须写二次确认策略）

用户偏好不能覆盖约束：即便用户觉得 ASCII“丑”，也必须输出 ASCII 线框以保证可移植、可评审、可追溯。可额外附 Figma 链接，但不能删掉 ASCII。

6) 生成 AC → 交互节点映射（必须可追溯）

要求：

• PRD 的每条 AC 都必须映射到至少一个页面/节点与具体验证点（状态/文案/按钮可用性/跳转结果）
• 不能映射的 AC：视为原型或 PRD 缺口 → 回流 R2 补齐

7) 写走查/验证脚本（闭环，而非一次性产物）

• 覆盖哪些验证清单条目（引用 PRD/solution 的编号）
• 每个核心场景写一个任务脚本（目标→步骤→成功标准→观察点）
• 明确回流规则：何种问题回流 R1/R2/R3

完成后：回到 using-aisdlc 路由下一步。

完成后输出（供 using-aisdlc 自动推进读取）

在回答末尾追加以下两段（不要省略）：

• 「本阶段产物已落盘。请回到 using-aisdlc 进行下一步路由（如未触发人工门禁，Router 可自动续跑）。」
• ROUTER_SUMMARY：

ROUTER_SUMMARY:
  stage: R3
  artifacts:
    - "{FEATURE_DIR}/requirements/prototype.md"
  needs_human_review: true
  blocked: false
  block_reason: ""
  notes: "原型建议走查后再进入 R4 或实现侧"

Quick reference（高频规则速查）

• 必须
  • 先跑 spec-context，只用 FEATURE_DIR 拼路径
  • 必须存在 prd.md 且可提取出场景 + AC +（至少一份）验证清单
  • prototype.md 必须包含：任务流（T-xxx）、页面清单（P/D/W-xxx）、逐页 ASCII 线框、AC 映射、走查脚本
• 禁止
  • 猜路径 / 在未知上下文里写文件
  • prd.md 缺失仍继续生成（“先出一版再说”）
  • 写“待确认问题 / Open Questions / TBD”清单（未知必须引用验证清单；缺失则回流补齐）
  • 把线框画成表格/图片替代 ASCII（可额外附链接，但不能替代）
  • 在 R3 新增范围/规则/决策（R3 只做交互规格化与追溯）

红旗清单（出现任一条：停止并纠正）

• 没跑 spec-context 就开始读写 requirements/*.md（或开始“猜 FEATURE_DIR”）
• prd.md 不存在/缺少 AC，却仍打算“先写原型占坑”
• 用 Open Questions/待确认清单承接不确定性，而不是引用 PRD/solution 的验证清单
• 把未知写成已知（脑补页面/权限/数据口径/错误策略等）
• 为迎合偏好把 ASCII 线框删掉（导致不可移植/不可评审）

常见借口与反制（基线测试中的高频点）

一个好例子（最小可追溯骨架）

• 任务流：T-001 进入 → T-002 填写 → T-003 提交成功 / T-004 校验失败
• 页面：P-001 表单页（覆盖 T-001/T-002/T-003/T-004）
• AC 映射：AC-001→P-001/错误态；AC-002→P-001/成功跳转