@openprd/cli 0.1.1 → 0.1.9

package/skills/openprd-benchmark-router/references/benchmark-sources.md

@@ -10,6 +10,7 @@
 - 第三方工具、SDK、CLI、API、MCP 或版本相关文档，优先用 Context7。
 - 官方工程博客和官方文档只提炼可验证原则，不复制大段原文。
 - 足够支撑当前 OpenPrd 决策后停止调研。
+- 执行过程中被用户采纳的优质来源可用 `openprd benchmark observe <url|repo|file> --notes <text>` 记录为候选 evidence；累计达到阈值后只提示用户 approve，不自动加入长期 registry。
 
 ## 来源分组
 

package/skills/openprd-benchmark-router/references/source-policy.md

@@ -26,6 +26,8 @@
 
 - `benchmark-sources.md` 是路由索引，不是事实来源。
 - 来源目录只代表候选来源，不代表来源内容已经被核验。
+- `openprd benchmark observe` 记录的是“被采纳过的信源线索”和 evidence，不代表该来源内容已经被完整核验。
+- candidate 达到采纳阈值后只推荐 approve；用户确认前仍不能当作长期 approved benchmark。
 - 长期偏好只能记录用户确认过的复用经验，不替代外部核验。
 
 ## 何时停止调研

package/skills/openprd-discovery-loop/SKILL.md

@@ -109,7 +109,7 @@ description: 把自然语言里的 OpenPrd 或 OpenSpec 深度、持续、全面
    - `openprd change <path> --generate --change <id>`
 8. 只有在需要单独检查 change 结构时，才运行 `openprd change <path> --validate --change <id>`；通常 discovery verify 在配置了 `activeChange` 时会一并检查
 9. 报告发现结果就绪前，运行 `openprd standards <path> --verify`
-10. 阶段性实现或任务完成后，运行 `openprd quality <path> --verify`，让 HTML 质量评估报告审查日志、业务护栏、冒烟覆盖、功能覆盖、性能基线、极端数据和知识缺口
+10. 单个任务完成后只保留 task-scoped evidence；阶段收口、全部实现完成或高风险动作前，再运行 `openprd quality <path> --verify`，让 HTML 质量评估报告审查日志、业务护栏、冒烟覆盖、功能覆盖、性能基线、极端数据和知识缺口
 11. 修改文档或任务前，先从当前 run 目录重新读取状态
 
 ## 运行目录
@@ -176,7 +176,7 @@ hook harness 还会写入：
 - 使用 `openprd change <path> --apply --change <id>` 把完成的 change specs 推进到 `openprd/specs`
 - 使用 `openprd change <path> --archive --change <id>` 把完成的 change 文件移动到 `openprd/archive/changes`
 - 当任务或 discovery pass 改动了基线文档、文件说明书或文件夹 README 时，运行 `openprd standards <path> --verify`
-- 在声明任务实现就绪前，运行 `openprd quality <path> --verify`；当某个已验证修复应该沉淀为项目级复用经验时，运行 `openprd quality <path> --learn --from <report>`
+- 在声明单个任务完成前，运行本任务最小足够验证并留下 evidence；在阶段收口或声明整体实现就绪前，运行 `openprd quality <path> --verify`；当某个已验证修复应该沉淀为项目级复用经验时，运行 `openprd quality <path> --learn --from <report>`
 - 如果任务被依赖阻塞，先完成更早的任务 id；不要人工跳过依赖顺序
 - 执行证据应保留在生成的任务事件或 discovery claims 中，不要给每个任务额外挂一堆元数据
 

package/skills/openprd-harness/SKILL.md

@@ -18,27 +18,31 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 1. 读取第一个可用的共用规则文件：`skills/openprd-shared/SKILL.md`、`$HOME/.claude/skills/openprd-shared/SKILL.md` 或 `$HOME/.codex/skills/openprd-shared/SKILL.md`
 2. 从 `.openprd/` 重建当前工作区状态
 3. 如果用户期待自动化 agent 引导，运行 `openprd doctor <path>`，必要时用 `openprd setup <path>` 或 `openprd update <path>` 修复
+   - `init/setup/update/doctor` 可能会在 `.openprd/harness/install-manifest.json` 的 `optionalCapabilities` 里记录 Context7、DeepWiki 等非阻断式增强建议。把它当成软提醒：初始化、诊断和当前任务都不因它失败；只有当前任务会明显受益时，才在后续建议里解释能力价值、附官方文档 / GitHub 链接，并视情况提出可代为补配置。
 4. 选择执行单元前，优先运行 `openprd run <path> --context`
 5. 把 `openprd run <path> --context` 当作建议，不要自动执行其中的写入命令
+   - 同时查看推荐里的 `executionMode` 和 `parallelPlan`：L0/小范围修正默认 `serial`，中等规模 L1/L2 可推荐 `parallel-workers`，高风险或大规模实现再升级到 `parallel-workers-isolated`
    - 如果用户给出会话 ID 并要求继续，按工具无关的历史会话精确续接；不要要求或使用工具专属 ID，也不要用当前 active change、相似历史或当前 requirement gate 替代该会话 ID
    - 如果用户没有给 ID，但明确描述了某个已有需求、change、task 或 work unit，先把这段描述交给 `openprd run <path> --context --message <用户原话>` 做显式对象解析，不要先默认拿当前 active change
-6. 需求复杂度先交给 `$openprd-requirement-intake` 分流；不要按固定关键词判断。它会根据影响面、未知数、决策成本和验证成本判断 L0 小修、L1 mini-plan 或 L2 PRD/review/change/tasks
+6. 需求复杂度先交给 `$openprd-requirement-intake` 分流；不要按固定关键词判断。它会根据影响面、未知数、决策成本和验证成本判断需求类型，并保留内部路由码对照：快速修正=L0、现有功能优化=L1、新功能/新流程方案=L2；默认把路由码并进“需求类型：快速修正（L0）”这类标签里，只有内部排障确实受益时才额外补“内部路由码”
+   - 如果需求涉及界面、页面、视觉、样式或前端体验，先判断是否属于“大界面改动”：会改变信息架构、页面布局、主视觉、关键路径、核心组件密度/层级，或用户需要先选设计方向。大界面改动在需求分流后、进入实现或 PRD 定稿前，先走视觉方案评审。
 7. 如果用户是在规划、分析、架构评审，或问“怎么改”“会动哪些文件”，保持只读并基于证据回答
-8. 实现任务完成代码修改后、最终回复前，针对本轮实际 touched code files 运行 `openprd dev-check <path> <file...>` 或 `node scripts/openprd-dev-check.mjs <path> <file...>`：700 行以内正常；701-1500 行需说明局部职责；超过 1500 行要判断本轮是否扩大职责，扩大则先重构/拆分/解耦并复查，窄 bugfix 或小修暂不拆时说明原因和后续拆分建议
+8. 实现任务完成代码修改后、最终回复前，针对本轮实际 touched code files 运行 `openprd dev-check <path> <file...>` 或 `node scripts/openprd-dev-check.mjs <path> <file...>`：700 行以内正常；701-1500 行需留意；超过 1500 行说明后续改动成本较高。若出现需要关注的文件，最终回复必须以 **后续建议** 为标题，用 Markdown 表格列出影响位置、关注程度、规模信号、为什么需要关注、本次处理和后续建议，并按 🔴 → 🟠 → 🟡 排序
 9. 执行过程中发现新代码后缀、豁免路径、命令别名、项目约定或用户偏好时，不要中途打断当前任务。工具识别补全和减少重复打扰这类高置信低风险项可自动补齐并记录；用户偏好、项目协作规矩和 OpenPrd 默认行为先沉淀为候选，收工时运行 `openprd grow <path> --review` 集中确认
 10. 维护 OpenPrd 本身时，只要新增或修改配置类能力（阈值、规则、识别、豁免、命令别名、环境差异、用户偏好或策略开关），默认先做 grow-aware 自检：高置信应可成长时直接纳入 `openprd grow` 体系；不确定时主动询问用户是否做成可成长配置
-11. 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup、先看样子或先确认设计方向时，默认直接调用 Codex 原生 Image 2 生图能力产出图片；除非用户明确指定 HTML、SVG、CSS、Canvas、代码稿或可编辑矢量/source artifact，不要改用临时 HTML/SVG/CSS 再截图。OpenPrd 的 `review.html` 只用于需求评审，不能替代图片或效果图生成
-12. 界面、页面、视觉、样式或前端体验任务中，如果已经有效果图、设计稿、图片资产、截图或用户给图且进入实现阶段，阶段性完成后先截实现图，再运行 `openprd visual-compare <path> --reference <效果图> --actual <实现截图>`。默认输出 JPG 到 `.openprd/harness/visual-reviews/`，左侧标注“效果图”、右侧标注“实现截图”；查看合成图后继续复刻，直到没有明显视觉差异
-13. 实现任务新增或修改文件时，做文档影响检查：缺失的 `docs/basic/`、文件说明书、文件夹 README 要补齐；受影响的已有文档要更新；涉及后端、脚本、Agent、工具链、服务或数据处理变更时，把 CLI 与 API 视为同级接入面，更新 `docs/basic/backend-structure.md` 中的命令入口、输出契约、`help`/`doctor`/`dry-run`/`status`、接口协议与不适用说明
-14. 长时间实现任务使用 `openprd loop <path> --plan --change <id>`，并且只有当前用户消息明确要求开发、继续任务、深度调研、对标复刻或提交时，才为每个 loop 任务启动一个全新 agent 会话
-15. 需要完整工作流细节时，使用 `openprd status` 和 `openprd next`
-16. 用户要求最佳实践、benchmark、对标、参考产品、prompt engineering、Agent harness、context engineering、图标资源、CLI 或 skill 体系设计时，先路由到 `$openprd-benchmark-router`
-17. 用户要求基线文档、文件说明书、文件夹 README 标准或实现就绪检查时，路由到 `$openprd-standards`
-18. 用户要求日志、链路追踪、业务成本护栏、免费额度、滥用防护、评估执行环境、冒烟覆盖、性能基线、极端场景、HTML 质量评估报告或项目级经验 Skill 时，路由到 `$openprd-quality`
-19. 用户需要可视化说明，或系统/产品形态仍不清晰时，在进入需求定稿前路由到 `$openprd-diagram-review`
-20. 默认保持 Codex hooks 轻量。除非项目明确需要完整工具级遥测，否则 `openprd setup/update` 使用 `--hook-profile lite`；默认 `lite` 会保留 `Stop` 收工回顾，用于在本轮结束前提醒是否值得沉淀项目经验
-21. hook 会强制阻断几类场景：需求入口未完成就写实现、外部证据不足就直接改第三方集成、skill/AGENTS 变更未先可视化确认、以及敏感信息场景下直接读原始 vault 文件
-22. 当 `doctor` 报告生成引导漂移时，读取 `.openprd/harness/drift-report.json`
+11. 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup、先看样子或先确认设计方向时，默认直接调用 `imagegen`，也就是 Codex 原生 Image 2，产出图片；除非用户明确指定 HTML、SVG、CSS、Canvas、代码稿或可编辑矢量/source artifact，不要改用临时 HTML/SVG/CSS 再截图。OpenPrd 的 `review.html` 只用于需求评审，不能替代图片或效果图生成；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流
+12. 大界面改动进入实现前，必须先完成视觉方案评审：用 Codex Computer Use 进入产品内对应功能并截当前真实界面；基于截图调用 `imagegen`（Codex 原生 Image 2）做图生图，至少生成 3 个不同设计思想方向；把效果图横向拼接成一张大图，左上角标注 1/2/3，并保存到 `.openprd/harness/visual-reviews/`；把大图展示给用户确认方向，未确认前不要进入大 UI 实现
+13. 界面、页面、视觉、样式或前端体验任务中，如果已经有效果图、设计稿、图片资产、截图或用户给图且进入实现阶段，阶段性完成后先截实现图，再运行 `openprd visual-compare <path> --reference <效果图> --actual <实现截图>`。如果没有明确参考图但改动界面，动手前先截修改前截图，完成后用同一入口、视口、账号和数据状态截修改后截图，再运行 `openprd visual-compare <path> --before <修改前截图> --after <修改后截图>`。需要审局部细节时，再补 `openprd visual-compare <path> --board <focus-board.json>`；并行跑了多个优化方向时，再补 `openprd visual-compare <path> --board <parallel-board.json>`。默认输出 JPG 到 `.openprd/harness/visual-reviews/`；查看合成图后继续复刻或自检，直到没有明显视觉差异或意外漂移
+14. 实现任务新增或修改文件时，做文档影响检查：缺失的 `docs/basic/`、文件说明书、文件夹 README 要补齐；受影响的已有文档要更新；涉及后端、脚本、Agent、工具链、服务或数据处理变更时，把 CLI 与 API 视为同级接入面，更新 `docs/basic/backend-structure.md` 中的命令入口、输出契约、`help`/`doctor`/`dry-run`/`status`、接口协议与不适用说明
+15. 长时间实现任务使用 `openprd loop <path> --plan --change <id>`，并且只有当前用户消息明确要求开发、继续任务、深度调研、对标复刻或提交时，才为每个 loop 任务启动一个全新 agent 会话
+16. 需要完整工作流细节时，使用 `openprd status` 和 `openprd next`
+17. 用户要求最佳实践、benchmark、对标、参考产品、prompt engineering、Agent harness、context engineering、图标资源、CLI 或 skill 体系设计时，先路由到 `$openprd-benchmark-router`
+18. 用户要求基线文档、文件说明书、文件夹 README 标准或实现就绪检查时，路由到 `$openprd-standards`
+19. 用户要求日志、链路追踪、业务成本护栏、免费额度、滥用防护、评估执行环境、冒烟覆盖、性能基线、极端场景、HTML 质量评估报告或项目级经验 Skill 时，路由到 `$openprd-quality`
+20. 用户需要可视化说明，或系统/产品形态仍不清晰时，在进入需求定稿前路由到 `$openprd-diagram-review`
+21. 默认保持 Codex hooks 轻量。除非项目明确需要完整工具级遥测，否则 `openprd setup/update` 使用 `--hook-profile lite`；默认 `lite` 会保留 `Stop` 收工回顾，用于在本轮结束前提醒是否值得沉淀项目经验，并要求 Agent 用“本次情况 / 准备整理成的经验 / 以后如何复用 / 只保留在当前项目里”的结构化人话向用户确认
+22. hook 会强制阻断几类场景：需求入口未完成就写实现、外部证据不足就直接改第三方集成、skill/AGENTS 变更未先可视化确认、以及敏感信息场景下直接读原始 vault 文件
+23. 当 `doctor` 报告生成引导漂移时，读取 `.openprd/harness/drift-report.json`
 
 ## 主工作流
 
@@ -64,7 +68,7 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
   - 不要把 `run --context` 建议当作直接用户命令
   - 用户给出会话 ID 续接历史任务时，使用 `openprd run <path> --context --message <用户原话或会话ID>` 保留通用会话 ID 语义；先恢复指定会话，不要让当前 active change 抢主线
   - 用户没有给 ID、但明确描述了已有需求/任务对象时，也使用 `openprd run <path> --context --message <用户原话>`；先解析对应的 change/task/work unit，再决定是否沿用当前工作区状态
-  - 默认 lite Codex hooks 会为明确的 OpenPrd、PRD、深度调研、对标复刻、standards、fleet、文档标准化提示词，以及结构上较复杂的需求注入 `$openprd-requirement-intake` 分流提示；L0 小修不打开 requirement gate，L1 用对话内 mini-plan 承接，L2 才进入 PRD/review/change/tasks；轻量 `PreToolUse` 写入门禁会在需求入口未确认前阻断过早实现；本轮准备结束时，`Stop` 会基于 touched files 和 verify/finish 信号回顾是否要生成项目经验草案
+  - 默认 lite Codex hooks 会为明确的 OpenPrd、PRD、深度调研、对标复刻、standards、fleet、文档标准化提示词，以及结构上较复杂的需求注入 `$openprd-requirement-intake` 分流提示；快速修正(L0)不打开 requirement gate，现有功能优化(L1)用对话内 mini-plan 承接，新功能/新流程方案(L2)才进入 PRD/review/change/tasks；轻量 `PreToolUse` 写入门禁会在需求入口未确认前阻断过早实现；本轮准备结束时，`Stop` 会基于 touched files 和 verify/finish 信号回顾是否要生成项目经验草案，并要求 Agent 先用人话向用户确认是否保留到当前项目里
   - 只有当项目确实需要完整 hook 遥测或临时深度诊断时，才用 `openprd update <path> --hook-profile full`
 - 长程实现循环使用：
   - `openprd loop <path> --init`
@@ -73,15 +77,20 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
   - `openprd loop <path> --prompt --agent codex`
   - `openprd loop <path> --run --agent codex --dry-run`
   - `openprd loop <path> --run --agent claude --dry-run`
+  - `openprd loop <path> --run --agent codex` 真实执行前会先运行 `codex --version`；若缺 Codex 平台原生可选依赖，默认只诊断并提示修复命令，不静默安装
+  - `openprd doctor <path> --tools codex --fix` 和 `openprd loop <path> --run --agent codex --repair-agent` 是显式修复入口，只有用户同意全局执行 `npm install -g @openai/codex@latest` 后才使用
   - `openprd loop <path> --finish --item <task-id> --commit`
-  - 让 `.openprd/harness/feature-list.json`、`progress.md`、`agent-sessions.jsonl`、`loop-state.json` 和 `loop-prompts/` 成为持久实现状态
+  - 让 `.openprd/harness/feature-list.json`、`progress.md`、`agent-sessions.jsonl`、`loop-state.json` 和 `loop-prompts/` 成为持久实现状态；feature list 里的 execution strategy 会为 worker shard 标注 `write-scope`、`owner-role`、`local-verify` 和 `integration-owner`
   - 只有在当前用户消息明确要求开发、继续任务、深度调研、对标复刻或提交时，才运行 `openprd loop <path> --run`
-  - 代码修改完成后、最终回复前，运行 `openprd dev-check <path> <file...>`；attention/warning 必须在最终回复里说明是否局部处理、是否已拆分，或为什么窄修暂不拆
-  - 用户只是要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup 或先看样子时，默认调用 Codex 原生 Image 2 生成图片；除非用户明确指定 HTML/SVG/CSS/Canvas/代码稿，不要生成临时 HTML 再截图
-  - 如果已有参考效果图、图片资产、设计稿、截图或用户给图并进入实现阶段，阶段性完成后必须生成实现截图，并用 `openprd visual-compare <path> --reference <效果图> --actual <实现截图>` 输出 JPG 视觉对比图。未查看对比图、或对比图仍有明显差异时，不要声称界面复刻完成
+  - 代码修改完成后、最终回复前，运行 `openprd dev-check <path> <file...>`；需要关注的文件必须在最终回复里以 **后续建议** 表格说明影响位置、关注程度、规模信号、为什么需要关注、本次处理和后续建议，并按 🔴 → 🟠 → 🟡 排序
+  - 用户只是要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup 或先看样子时，默认调用 `imagegen`（Codex 原生 Image 2）生成图片；除非用户明确指定 HTML/SVG/CSS/Canvas/代码稿，不要生成临时 HTML 再截图；未调用 `imagegen` 前，不要声称生图已完成、失败或限流
+  - 大界面改动不直接开工：先用 Codex Computer Use 打开产品内对应功能并截图，再用 `imagegen`（Codex 原生 Image 2）基于截图生成至少 3 个设计方向，横向拼接成一张带 1/2/3 序号的大图给用户确认；用户确认某个方向后，再把它作为实现参考图进入后续任务
+  - 如果已有参考效果图、图片资产、设计稿、截图或用户给图并进入实现阶段，阶段性完成后必须生成实现截图，并用 `openprd visual-compare <path> --reference <效果图> --actual <实现截图>` 输出 JPG 视觉对比图；如果局部细节更重要，再补 `--board <focus-board.json>` 输出局部焦点证据板；如果没有明确参考图但改动界面，动手前先生成修改前截图，完成后生成修改后截图，并用 `openprd visual-compare <path> --before <修改前截图> --after <修改后截图>` 输出 JPG 自检图；如果并行试了多个优化方向，再补 `--board <parallel-board.json>` 输出并行实验证据板。未查看对比图、或对比图仍有明显差异/漂移时，不要声称界面视觉完成
   - `openprd loop <path> --finish` 前，先完成文档影响检查并更新缺失或过期的 `docs/basic/`、文件说明书和文件夹 README；涉及后端、脚本、Agent、工具链、服务或数据处理变更时，同步评估 CLI 与 API 两个接入面
-  - 声称任务就绪前，运行 `openprd quality <path> --verify` 并审阅生成的 HTML 质量评估报告，检查场景标签、必需 EVO 门禁、日志、业务护栏、冒烟覆盖、任务完整性、性能基线、极端场景和知识缺口
-  - 如果本轮修复已经出现可复用模式，可先运行 `openprd quality <path> --learn --review --from .openprd/harness/turn-state.json` 生成 knowledge candidate / draft skill；确认值得长期保留后，再运行 `openprd quality <path> --learn --from <candidate-dir>` promote 为正式项目经验
+  - 声称单个任务完成前，只运行本任务最小足够验证，并通过 `--evidence`、测试报告或任务 metadata 留下 task-scoped evidence；不要在每个任务里反复运行 `openprd quality <path> --verify` 或全局 `openprd run <path> --verify`
+  - 阶段收口、全部任务完成、handoff/commit/release/publish 前，再运行 `openprd quality <path> --verify` 并审阅生成的 HTML 质量评估报告，检查场景标签、必需 EVO 门禁、日志、业务护栏、冒烟覆盖、任务完整性、性能基线、极端场景和知识缺口
+  - 如果当前任务是在发布 OpenPrd 自身到 GitHub，新版本必须同时具备匹配的项目版本号、版本条目、版本 tag 和 GitHub Release；只有 push/tag 没有 Release 不算发布闭环。优先先用 `openprd release <path> --notes ...` 累计版本条目，再用 `node scripts/openprd-github-release-notes.mjs <path> --version <x.y.z> --tag <vX.Y.Z>` 生成发布文案，并确认仓库 workflow 已成功 create/edit 对应 release
+  - 如果本轮修复已经出现可复用模式，可先运行 `openprd quality <path> --learn --review --from .openprd/harness/turn-state.json` 生成项目经验候选；对用户呈现时先用“这次我观察到的情况 / 我计划保留的一条项目经验 / 以后如果再遇到类似任务我会怎么复用 / 这条经验只保留在当前项目里，要不要一起保留”这套结构化人话询问。确认值得长期保留后，再运行 `openprd quality <path> --learn --from <candidate-dir>` 正式沉淀为项目经验
   - `openprd loop <path> --finish` 应同时留下 Markdown 和 HTML 回归证据到 `.openprd/harness/test-reports/`，把它们视作任务交付物的一部分
   - 每个 loop 任务都对应一个全新 Codex 或 Claude 会话边界，不要在同一会话里继续下一项任务
 - 处理历史项目集群前先审计：
@@ -96,7 +105,11 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 - 使用：
   - `openprd clarify <path>`
 - 当关键产品事实缺失时，先查看 `intake-reflection.md` 的需求入口自省，再把压缩后的必须确认问题问给用户
-- 当需求模糊、起点只有一句想法，或需要先做方案探索时，先查看生成的 `intake-reflection.md`，再把压缩后的目标、范围、非目标、验收方式和必须确认问题放在对话里请用户确认；不要生成或打开澄清 HTML
+- 当需求模糊、起点只有一句想法，或需要先做方案探索时，先查看生成的 `intake-reflection.md`，先把用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针整理成首轮项目画像，再把压缩后的目标、范围、非目标、验收方式和必须确认问题放在对话里请用户确认；不要生成或打开澄清 HTML
+- Agent 在对话里先用业务和产品语言复述：这次主要给谁、什么场景、先解决什么、先不碰什么、不能影响什么、会带来哪些业务风险。默认先追问 1 个最高价值问题，而不是一次性抛一整墙技术问题。
+- 如果当前还是 L2 的首轮澄清或 requirement 摘要确认阶段，只能承诺“我先整理需求摘要给你确认，确认后再进入 PRD / review 流程”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现压成一步。
+- `面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景` 不是只给后面 PRD 用的模板方向；澄清阶段就要前移场景视角。面向个人消费者场景更看首次场景、用户感受和回访动力；面向企业服务场景更看拍板方、使用方、推进方和上线阻力；Agent 场景更看自主边界、人工兜底和失败恢复。
+- 当用户一开始不想讲太细时，可以先给 2 到 3 个方向和取舍供用户选，不要逼用户先回答完整 schema。
 - 优先分阶段确认：问题、用户、范围、成功标准和开放问题；复杂需求先让 OpenPrD 内部完成意图归一化、项目上下文映射和产品质量自检，不要把固定问题墙一次性砸给用户
 - 收到答案后，用下面命令写回：
   - `openprd capture <path> --field <section.path> --value <text|json>`
@@ -118,9 +131,11 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 - 使用：
   - `openprd synthesize <path> --title ... --owner ... --problem ... --why-now ...`
 - 如果草稿仍然稀疏，明确说明还缺什么
+- 生成 `spec.md` 和 tasks 时默认使用简体中文；必要专有名词、品牌名、命令名、路径、字段名和 API 术语可以保留原文
 - `synthesize` 生成 `review.html` 后，必须把 HTML 路径告诉用户，并自动打开它（或紧接着运行 `openprd review <path> --open`）
 - 评审页里的需求关系图、需求流程图和重点摘要不要靠 HTML 截断；`openprd synthesize` 生成版本快照后，不要直接把 review 给用户确认。必须先用 `openprd review-presentation <path> --template` 查看展示文案契约，让 Agent 按 `reviewPresentation` 写短文案，再用 `openprd review-presentation <path> --presentation <json> --write --fail-on-violation` 校验并写回。脚本通过后会写入校验元信息并重渲染可确认 review.html；超限时按脚本返回的 jsonPath 和字数限制重新提炼，不手工改快照、不裁剪原文
-- 把生成的 `review.html` 当作首选稳定评审 artifact。默认 approval policy 是 `decision-points`：当前 lane 仍需要人类决策时，请用户先评审问题定义、范围、主流程、风险和开放问题，再运行带精确 `--version`、`--digest`、`--work-unit` 的 `openprd review <path> --mark confirmed`。若用户一开始已经明确要求直接做，并显式表示不需要额外评审或确认，lane 可进入 `silent-record`，这时只允许记录当前精确匹配的稳定 artifact，不能借机替别的版本补确认。review 记录完成且 tasks 就绪后，如果用户原始意图已经明确要求实现，可直接继续执行；否则等待一句明确的执行指令
+- 把生成的 `review.html` 当作首选稳定评审 artifact。默认 approval policy 是 `decision-points`：当前 lane 仍需要人类决策时，请用户先评审问题定义、范围、主流程、风险和开放问题，再运行带精确 `--version`、`--digest`、`--work-unit` 的 `openprd review <path> --mark confirmed`。L2 下先确认对话内 requirement 摘要，再写回确认事实、classify/synthesize，并进入这一步 review。若用户一开始已经明确要求直接做，并显式表示“不需要进行任何确认”，lane 才可进入 `silent-record`；单纯的“请帮我实现/继续实现”或“不要评审”都不触发这个豁免。进入 `silent-record` 后也只允许记录当前精确匹配的稳定 artifact，不能借机替别的版本补确认。review 记录完成且 tasks 就绪后，如果用户刚刚确认的是现有功能优化（L1）的 mini-plan、范围边界或正式产品边界，后续承接要写成“已确认，我按这个继续”，不要写成“确认，我们就按这个……”这种像再次索取确认的句子；如果用户原始意图已经明确要求实现，可直接继续执行；否则先输出执行确认清单，列出本轮目标、将执行内容、不做事项、验证方式和已知风险，再请求明确执行授权，不能只要求用户回复一句确认
+- 在 L2 的 requirement 摘要确认前，不要承诺“确认后我就开始实现”；正确顺序是：先确认摘要，再写回事实、进入 classify/synthesize/review，review 和 tasks 就绪后才谈执行。
 
 ### 6. 需要时生成可视化评审产物
 
@@ -128,6 +143,11 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
   - 架构确认
   - 流程 / 旅程确认
   - 需求定稿前的可视化评审
+- 当需求属于大界面改动时，在 PRD 定稿或实现开工前先走“视觉方案评审”：
+  - 用 Codex Computer Use 进入产品内对应功能，截取当前真实界面
+  - 用 `imagegen`（Codex 原生 Image 2）基于该截图做图生图，至少产出 3 个不同设计思想方向
+  - 将 3 张效果图横向拼接为一张大图，每张左上角标注 1/2/3，并保存到 `.openprd/harness/visual-reviews/`
+  - 展示给用户评审确认；未确认方向前，不进入大 UI 实现或声称方案已定
 
 ### 7. 只在草稿准备好时 freeze
 
@@ -140,7 +160,8 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 - 声称实现就绪前，再校验质量：
   - `openprd quality <path> --verify`
   - 把 `.openprd/quality/reports/<id>.html` 当作面向人的评审产物，用于查看当前场景必需 EVO 门禁、可观测性、业务成本与滥用护栏、评估执行环境、性能、压力数据和项目知识
-  - 如果 HTML 或 `openprd run <path> --verify` 显示 `productionReady=false`，最终回复不得宣称就绪；必须列出缺证据或需关注的必需门禁
+  - 如果 HTML 或 `openprd run <path> --verify` 显示 `productionReady=false`，最终回复不得宣称整体就绪；必须先区分 `taskReady` 与 `workspaceReady`，再列出缺证据或需关注的必需门禁
+  - 如果 `openprd run <path> --verify` 只剩 `feature-coverage` 待关注，要说明是任务账本或覆盖证据未收口，不要把本次功能表述成失败
 - 进入高风险动作前，校验完整 harness：
   - `openprd run <path> --verify`
   - `openprd doctor <path>`
@@ -160,7 +181,8 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 - 当 agent 环境可能没有正确跟随 OpenPrd 时，优先用 `openprd doctor`
 - 生成 adapter 文件漂移时，优先运行 `openprd update` 修复，而不是手改生成文件
 - 当方案形态仍不清晰时，优先先 review 再进入需求定稿
-- 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup 或先看样子时，优先调用 Codex 原生 Image 2；界面任务已有参考图并进入实现阶段时，才用 `openprd visual-compare` 生成左右对比 JPG，作为视觉就绪判断依据
+- 当界面改动比较大、用户需要先选方向、或页面信息架构/主视觉会明显变化时，优先先做 3 方向效果图评审，再进入实现
+- 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup 或先看样子时，优先调用 `imagegen`（Codex 原生 Image 2）；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流。界面任务进入实现阶段时，已有参考图用 `openprd visual-compare --reference/--actual` 生成左右对比 JPG，无参考图但改动界面用 `openprd visual-compare --before/--after` 生成修改前后自检 JPG；局部细节优先补 `--board <focus-board.json>`，并行优化方向优先补 `--board <parallel-board.json>`，共同作为视觉就绪判断依据
 - 遇到 blocker 时，优先把阻塞条件显式暴露出来，而不是悄悄补脑
 
 ## 禁止行为

package/skills/openprd-harness/references/workflow-gates.md

@@ -26,6 +26,21 @@ Route to diagram review before freeze if:
 - dependencies or boundaries are important to approval
 - the user explicitly asks for a diagram, flow, or visual explanation
 
+## Visual Direction Gate
+
+Before large UI changes, route to visual direction review after requirement intake and before implementation or PRD freeze if:
+
+- information architecture, core layout, primary visual language, key path, or component hierarchy/density will change substantially
+- the user asks to compare design directions, effect images, mockups, or "先看样子"
+- the change is an existing feature optimization but product judgment is needed before visual implementation
+
+Required artifact:
+
+- current in-product screenshot captured with Codex Computer Use
+- at least three Image 2 image-to-image directions based on that screenshot
+- one horizontal contact sheet under `.openprd/harness/visual-reviews/`, with each option numbered 1/2/3 in the top-left corner
+- explicit user confirmation of the chosen direction before large UI implementation
+
 ## Freeze Gate
 
 Freeze is appropriate when:

package/skills/openprd-quality/SKILL.md

@@ -16,7 +16,7 @@ description: 评估 OpenPrd 的可观测性、业务成本与滥用护栏、评
 - eval、评估体系、冒烟测试、功能覆盖、异常流程、逆向流程
 - CPU、内存、加载时间、接口耗时、压力测试、极端数据
 - 质量评估报告、HTML 审查产物、质量门禁
-- 界面效果图、实现截图、视觉对比、复刻对标、阶段性视觉评审
+- 界面效果图、实现截图、视觉对比、复刻对标、大界面改动方案评审、阶段性视觉评审
 - 复盘后沉淀经验 Skill，避免同类问题反复出现
 
 ## 核心命令
@@ -29,6 +29,10 @@ description: 评估 OpenPrd 的可观测性、业务成本与滥用护栏、评
   - `openprd quality <path> --learn --review --from .openprd/harness/turn-state.json`
 - 生成界面视觉对比图：
   - `openprd visual-compare <path> --reference <效果图> --actual <实现截图>`
+  - `openprd visual-compare <path> --before <修改前截图> --after <修改后截图>`
+  - `openprd visual-compare <path> --board <focus-board.json|parallel-board.json>`
+- 大界面改动的实现前方案评审：
+  - 先用 Codex Computer Use 截取产品内当前功能截图，再用 `imagegen`（Codex 原生 Image 2）生成至少 3 个设计方向，并保存横向拼接评审大图到 `.openprd/harness/visual-reviews/`
 - 基于已审查报告生成或刷新项目级经验：
   - `openprd quality <path> --learn --from <candidate-dir|report-id-or-json>`
 - 审查执行中发现的配置、规则候选或 user-local 偏好：
@@ -51,9 +55,9 @@ description: 评估 OpenPrd 的可观测性、业务成本与滥用护栏、评
 - 可观测性：前端、后端、agent 工具、异步任务和错误路径能否通过共享 trace/request/task/error id 串起来
 - 业务成本与滥用护栏：免费、试用、消耗型资源、AI 调用、第三方 API、下载、存储等路径是否有额度、负向验证、监控、报警和止损
 - 评估执行环境：冒烟测试、功能覆盖、正常性能和极端数据场景是否存在并持续维护
-- 视觉评审证据：涉及界面视觉实现且已有参考效果图时，确认 `.openprd/harness/visual-reviews/` 下存在本次 `openprd visual-compare` 输出的 JPG，并且 Agent 已基于合成图复核差异
+- 视觉评审证据：大界面改动进入实现前，应存在 3 方向效果图横向评审大图和用户选定方向；涉及界面视觉实现且已有参考效果图时，确认 `.openprd/harness/visual-reviews/` 下存在本次 `openprd visual-compare` 输出的“效果图 / 实现截图”JPG，并且 Agent 已基于合成图复核差异；无参考图但改动界面时，确认存在“修改前 / 修改后”JPG，并已检查预期变化和未改区域漂移；当验收关注局部细节时，确认存在“局部焦点证据板”；当并行跑了多个优化方向时，确认存在“并行实验证据板”
 - HTML 质量评估报告：`.openprd/quality/reports/` 下的人类审查产物是否存在，且足以支持就绪判断
-- 知识 Skill：已验证修复是否应该先生成 `.openprd/knowledge/candidates/` 和 `.openprd/knowledge/drafts/` 下的草案，再 promote 为 `.openprd/knowledge/skills/` 下可复用的项目经验
+- 项目经验沉淀：已验证修复是否应该先生成当前项目内的项目经验候选；若值得保留，先用“本次观察到的情况 / 计划保留的经验 / 以后怎么复用 / 只保留在当前项目里”的结构化人话询问用户，再沉淀为 `.openprd/knowledge/skills/` 下可复用的项目经验
 - 自我成长：配置缺口、文件识别、命令习惯或用户偏好优先沉淀为 `.openprd/growth` 候选，经用户确认后固化；不要把个人偏好混进项目共享质量经验
 
 ## 可观测性规则
@@ -81,8 +85,10 @@ description: 评估 OpenPrd 的可观测性、业务成本与滥用护栏、评
 ## 就绪判断规则
 
 - `openprd quality <path> --verify` 生成 advisory 报告时，仍要认真阅读 HTML，不得只看命令退出结果。
-- `openprd run <path> --verify` 中只要质量报告 `productionReady=false`，就不能宣称整体就绪。
-- UI 任务有参考图但缺少 visual-compare 输出时，不要宣称视觉实现完成；如果对比图仍有明显偏差，先返工而不是把差异留给用户发现。
+- `openprd run <path> --verify` 若显示 `taskReady=true` 且 `workspaceReady=false`，不能宣称整体工作区就绪；先明确区分“当前任务通过，工作区待关注”，再列出未通过门禁。
+- 若只剩 `feature-coverage`，说明是任务账本或覆盖证据未收口，不要把本次功能表述成失败。
+- 大界面改动缺少实现前 3 方向效果图评审或用户未确认方向时，不要进入大 UI 实现，也不要声称方案已定。
+- UI 任务有参考图但缺少 visual-compare 输出时，不要宣称视觉实现完成；无参考图的 UI 改动缺少修改前后截图对比时，不要宣称视觉自检完成；局部细节本该单独审却没有局部焦点证据板时，不要把整屏图当成充分验收；并行跑了多个优化方向却没有并行实验证据板时，不要只凭口头结论收尾；如果对比图仍有明显偏差或漂移，先返工而不是把差异留给用户发现。
 - 最终回复必须列出未通过的必需 EVO 门禁；如果某门禁被判定不适用，要说明它是当前场景可选或已有明确豁免。
 
 ## 经验 Skill 规则

package/skills/openprd-requirement-intake/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openprd-requirement-intake
-description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品需求、功能变更、bugfix、流程调整、跨对话续做、OpenPrd/PRD 生成、review/change/tasks 前置判断时，先按语义判断用户可见需求类型和内部 L0/L1/L2 路由码，并选择 base、consumer、b2b 或 agent PRD 模板 lens。
+description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品需求、功能变更、bugfix、流程调整、跨对话续做、OpenPrd/PRD 生成、review/change/tasks 前置判断时，先按语义判断用户可见需求类型和内部 L0/L1/L2 路由码，并选择通用 / 面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景的 PRD 模板视角。对用户复述时不用 raw enum，`consumer/b2b/agent` 只留给内部记录和命令。
 ---
 
 # OpenPrd Requirement Intake
@@ -11,7 +11,7 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 
 - 判断当前用户输入的用户可见需求类型和内部 L0/L1/L2 路由码
 - 决定下一步是直接澄清、mini-plan，还是正式 PRD
-- 为 L2 选择 `base`、`consumer`、`b2b` 或 `agent` PRD lens
+- 为 L2 选择通用、面向个人消费者场景、面向企业服务场景或以 Agent 为主要使用场景的 PRD 视角；`base/consumer/b2b/agent` 只用于内部记录和命令
 - 把用户当前需求和历史 active change 分开，避免“继续任务”吞掉新范围
 - 给 `$openprd-harness` 输出下一步行动合同
 
@@ -25,7 +25,10 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 | 现有功能优化 | L1 | 目标明确，但影响多个文件、状态或用户可见行为 | 先给对话内 mini-plan，再执行 |
 | 新功能/新流程方案 | L2 | 新产品、模块、入口、流程、权限、计费、账号、AI/第三方、云服务、数据迁移、跨系统、长期工作流，或目标/验收/影响面不清 | 先走 PRD/review/change/tasks |
 
-用户审查时优先显示“需求类型”，不要把 `Intake Decision: L1` 这类内部码当成标题。需要审查或调试时，可以在同一段里附上“内部路由码：L1”，并保留上面的对照关系。
+用户审查时优先把路由码并进“需求类型：快速修正（L0）”这类标签里，不要把内部调度码单独抬成标题。只有审查或调试真的受益时，才额外补“内部路由码：L1”这类信息，并保留上面的对照关系。
+用户侧表达优先使用“面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景”这类自然语言，不要把 `consumer`、`b2b`、`agent` 直接当展示词抛给用户。
+
+界面、页面、视觉、样式或前端体验需求需要额外判断 UI 影响面。若会明显改变信息架构、核心布局、主视觉、关键路径、组件层级/密度，或用户需要先选择设计方向，即使属于“现有功能优化”，也要先走“大界面改动视觉方案评审”：Computer Use 截取当前产品内功能截图，`imagegen`（Codex 原生 Image 2）基于截图生成至少 3 个方向，横向拼接带 1/2/3 序号的大图给用户确认。
 
 如果同一句话同时包含“继续旧任务”和“新增范围”，先判断新增范围是否超出旧 PRD。超出时必须回到需求入口，更新 PRD/change/tasks，不能把“继续”当作实现授权。
 
@@ -33,14 +36,15 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 
 1. 读取 `.openprd/` 状态和 `openprd run . --context`，但把它当作建议。
 2. 用 `references/routing-rubric.md` 判断 L0/L1/L2。
-3. 如果是 L2，读取 `references/prd-template-lenses.md` 选择 PRD lens。
+3. 如果是 L2，读取 `references/prd-template-lenses.md` 选择 PRD 场景视角。
 4. 输出一个短的需求类型判断：
-   - 需求类型：快速修正 / 现有功能优化 / 新功能/新流程方案
-   - 内部路由码：L0 / L1 / L2
-   - 理由：影响面、未知数、风险、验证成本
-   - 当前需求是否覆盖历史 active change
-   - 推荐下一步
-   - L2 时的 PRD lens：base / consumer / b2b / agent
+   - 先总后分，优先按下面结构在对话里给用户看：
+   - 需求判断：需求类型（默认写成 `快速修正（L0）` / `现有功能优化（L1）` / `新功能/新流程方案（L2）`）/ 产品类型 / 推荐下一步
+   - 只有内部排障真的受益时，才额外补一行“内部路由码”
+   - 需求理解：主要服务对象 / 使用场景 / 第一版先做什么 / 这轮先不做什么 / 必须守住什么
+   - 功能范围：优先用 Markdown 表格写 `功能模块 | 这次先做什么 | 这次先不做什么`
+   - 技术方案：优先用 Markdown 表格写 `技术部分 | 初步方案 | 主要负责什么`；涉及前端、后端、Agent、数据或集成时，按用户能看懂的功能视角拆开
+   - L2 时补充 PRD 场景视角：通用场景 / 面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景
 5. 把执行交回 `$openprd-harness`。
 
 ## 输出合同
@@ -55,27 +59,34 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 
 - 给 3-5 行 mini-plan。
 - 明确范围内、范围外和验证方式。
+- 默认先用业务/产品语言复述需求，再只追问 1 个最高价值问题；不要上来抛技术字段墙。
+- 若是大界面改动，mini-plan 之后先做 3 方向效果图评审，用户确认方向后再实现。
 - 用户已明确要求执行时可继续实现。
 - 不生成正式 PRD，除非 mini-plan 暴露出新的决策缺口。
 
 ### L2
 
 - 先运行或建议 `openprd clarify .`。
-- 用对话内摘要确认目标、用户/角色、范围、非目标、验收、开放问题。
-- 使用 `openprd capture . --field ...` 写回确认事实。
+- 先建立首轮项目画像：用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针。
+- 再用对话内结构化摘要确认需求，默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”的顺序来写，其中“功能范围”和“技术方案”优先用 Markdown 表格。
+- 优先由 Agent 先归纳，再请用户确认；默认先问 1 个最高价值问题，必要时再给 2 到 3 个方向和取舍供用户选，不要一次砸一整墙问题。
+- 当前还是 L2 的首轮澄清或 requirement 摘要确认阶段时，只能承诺“我先整理需求摘要给你确认”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现压成一句话。
+- 单纯的“请帮我实现/继续实现”只表示用户希望最终落地，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。
+- 用户侧表达优先使用业务和产品语言，强调谁在什么场景下解决什么问题、会获得什么收益、要承担什么业务风险；避免过早暴露前端/后端/数据库这类技术黑话。
+- 使用 `openprd capture . --field ...` 只写回已确认事实；`agent-normalized` 仅用于无语义变化的内部措辞整理，不替代用户确认。
 - 选择并记录产品类型：`openprd classify . <consumer|b2b|agent>`；无法判断时保持 `base`。
-- 再进入 `openprd synthesize .`、review artifact、change 和 tasks。
+- requirement 摘要确认后，再进入 `openprd classify .`、`openprd synthesize .`、review artifact、change 和 tasks。
 
-## PRD Lens
+## PRD 场景视角
 
-- `base`：通用产品或工程需求，强调问题、目标、范围、流程、需求矩阵、验收和风险。
-- `consumer`：面向个人用户或 C 端体验，强调用户旅程、首次成功、激活、留存、情绪价值和增长指标。
-- `b2b`：面向企业、团队、后台、SaaS 或组织流程，强调买方/使用者/管理员/运营者、权限矩阵、审批审计、集成依赖、SLA 和上线支持。
-- `agent`：面向 AI Agent、harness、skill、自动化或人机协作工作流，强调 Human-Agent contract、自主边界、工具边界、状态模型、失败恢复和评估计划。
+- `base`：通用产品或工程场景，强调问题、目标、首轮项目画像、范围、流程、需求矩阵、验收和风险。
+- 内部 `consumer`：面向个人消费者场景，强调用户旅程、首次成功、激活、留存、情绪价值和增长指标。
+- 内部 `b2b`：面向企业服务场景，强调买方/使用者/管理员/运营者、权限矩阵、审批审计、集成依赖、SLA 和上线支持。
+- 内部 `agent`：以 Agent 为主要使用场景，强调 Human-Agent contract、自主边界、工具边界、状态模型、失败恢复和评估计划。
 
-模板 lens 应融入正文结构，不要作为 PRD 末尾的字段附录。比如 B2B 的角色、权限和审批应该贯穿用户、流程、需求矩阵和验收标准；Agent 的自主边界应该贯穿范围、风险、任务和验证。
+模板视角应融入正文结构，不要作为 PRD 末尾的字段附录。比如企业服务场景的角色、权限和审批应该贯穿用户、流程、需求矩阵和验收标准；Agent 场景的自主边界应该贯穿范围、风险、任务和验证。
 
 ## 何时读取参考
 
 - 分流有争议、用户输入很长、或涉及“继续旧任务 + 新范围”时，读 `references/routing-rubric.md`。
-- 需要写 PRD、选择产品类型、或用户反馈 PRD 结构奇怪时，读 `references/prd-template-lenses.md`。
+- 需要写 PRD、选择产品场景、或用户反馈 PRD 结构奇怪时，读 `references/prd-template-lenses.md`。

package/skills/openprd-requirement-intake/references/prd-template-lenses.md

@@ -1,4 +1,4 @@
-# PRD Template Lenses
+# PRD 场景视角参考
 
 ## 共同骨架
 
@@ -13,9 +13,9 @@
 7. 有什么风险：依赖、约束、成本、滥用、开放问题
 8. 如何交接：review、change、tasks、负责人、下一步
 
-`base/prd.md` 提供这个骨架。其他模板不是附录，而是 lens：它们改变正文组织、需求矩阵和验收重点。
+`base/prd.md` 提供这个骨架。其他模板不是附录，而是场景视角：它们会改变正文组织、需求矩阵和验收重点。
 
-## Base
+## 通用产品或工程场景（Base）
 
 用于无法明确归类、或通用工程/产品需求。
 
@@ -32,7 +32,7 @@
 - 约束、依赖、风险、开放问题
 - 交接与下一步
 
-## Consumer
+## 面向个人消费者场景（Consumer）
 
 用于个人用户、C 端体验、内容、增长、留存或情绪价值明显的需求。
 
@@ -53,7 +53,7 @@
 - Activation / Retention Signal
 - UX Risk
 
-## B2B
+## 面向企业服务场景（B2B）
 
 用于企业、团队、后台、SaaS、组织流程、管理/审批/权限相关需求。
 
@@ -74,7 +74,7 @@
 - Admin / Operator Impact
 - Integration Dependency
 
-## Agent
+## 以 Agent 为主要使用场景（Agent）
 
 用于 AI Agent、harness、skill、自动化、代码代理、人机协作或评估体系。
 

package/skills/openprd-requirement-intake/references/routing-rubric.md

@@ -2,7 +2,7 @@
 
 ## 判断维度
 
-按下面四个维度判断，不按固定关键词判断。用户审查时优先展示“需求类型”，内部调度和排障时再附上“内部路由码”。
+按下面四个维度判断，不按固定关键词判断。用户审查时优先展示“需求类型：快速修正（L0）”这类合并标签；只有内部调度和排障真的受益时，才额外附上“内部路由码”。
 
 | 用户可见需求类型 | 内部路由码 | 默认路径 |
 |---|---|---|
@@ -17,6 +17,14 @@
 | 决策成本 | 不需要产品决策 | 需要简短方案选择 | 需要先评审意图和范围 |
 | 验证成本 | 单元/局部验证 | 组合验证或 E2E | 需要分阶段任务、回归、业务/成本/权限验证 |
 
+## UI 影响面补充判断
+
+界面、页面、视觉、样式或前端体验需求先按 L0/L1/L2 分流，再判断是否需要视觉方案评审。
+
+- 小 UI 调整：按钮文案、颜色、间距、字号、单点样式、局部 bug，通常仍按 L0 或 L1。
+- 大界面改动：信息架构、核心布局、主视觉、关键路径、组件层级/密度明显变化，或用户需要先选设计方向。
+- 大界面改动不直接实现；在 mini-plan、PRD 定稿或实现开工前，先用 Computer Use 截当前产品内功能图，再用 Image 2 生成至少 3 个方向，横向拼接带 1/2/3 序号的大图给用户确认。
+
 ## L0：快速修正
 
 适合直接处理：
@@ -37,7 +45,7 @@
 - 一个现有功能或现有流程里的局部体验优化
 - 一个明确 bug 的系统化修复，需要补测试和文档
 
-输出：需求类型为“现有功能优化”，先给 3-5 行 mini-plan，包含范围内、范围外、验证方式。用户已经要求执行时可继续。
+输出：需求类型为“现有功能优化”，先给 3-5 行 mini-plan，包含范围内、范围外、验证方式。若属于大界面改动，先补视觉方案评审；用户确认方向后才进入大 UI 实现。
 
 ## L2：新功能/新流程方案
 

package/skills/openprd-router/SKILL.md

@@ -22,12 +22,12 @@ description: OpenPrd 入口路由 skill。先判断当前任务该读哪个 repo
 
 ## 路由表
 
-- 需求入口分流、L0/L1/L2 判断、PRD lens 选择：`skills/openprd-requirement-intake/SKILL.md`
+- 需求入口分流、用户可见需求类型与内部 L0/L1/L2 路由码对照、PRD 场景视角选择：`skills/openprd-requirement-intake/SKILL.md`
 - 主工作流、review/change/tasks、`run/loop`：`skills/openprd-harness/SKILL.md`
 - 最佳实践、benchmark、公开 GitHub 仓库、第三方技术事实、prompt/context engineering：`skills/openprd-benchmark-router/SKILL.md`
 - `docs/basic/`、文件说明书、文件夹 README、文档标准：`skills/openprd-standards/SKILL.md`
 - 就绪验证、EVO 门禁、HTML 质量评估报告、项目经验沉淀：`skills/openprd-quality/SKILL.md`
-- 架构图、产品流程图、可视评审：`skills/openprd-diagram-review/SKILL.md`
+- 架构图、产品流程图、可视评审、大界面改动效果图方案评审：`skills/openprd-diagram-review/SKILL.md` 与 `skills/openprd-harness/SKILL.md`
 - 长时间只读挖掘、参考项目持续调研、requirements/specs/tasks 补全：`skills/openprd-discovery-loop/SKILL.md`
 - 学习包、归档阅读器、知识整理：`skills/openprd-learning-review/SKILL.md`