@openprd/cli 0.1.8 → 0.1.10

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

@@ -9,9 +9,10 @@
 3. 做到什么程度：目标、成功指标、验收标准
 4. 做什么和不做什么：范围、非目标、边界情况
 5. 用户怎么走：主流程、失败路径、恢复路径
-6. 需求怎么验收：需求矩阵、优先级、验收标准、测试/验证
-7. 有什么风险：依赖、约束、成本、滥用、开放问题
-8. 如何交接：review、change、tasks、负责人、下一步
+6. 值不值得继续做：第一批可触达社区、种子用户、当前替代方案、手工交付路径、承诺信号、最低成本验证、default alive 约束
+7. 需求怎么验收：需求矩阵、优先级、验收标准、测试/验证
+8. 有什么风险：依赖、约束、成本、滥用、开放问题
+9. 如何交接：review、change、tasks、负责人、下一步
 
 `base/prd.md` 提供这个骨架。其他模板不是附录，而是场景视角：它们会改变正文组织、需求矩阵和验收重点。
 
@@ -25,6 +26,7 @@
 - 背景与问题
 - 用户与相关方
 - 目标与成功标准
+- 验证与创业闭环
 - 范围与非目标
 - 场景与流程
 - 需求矩阵
@@ -101,5 +103,6 @@
 
 - 不输出大段空字段或 TBD 墙；缺事实时进入开放问题。
 - 不把类型专项字段堆在末尾；把它们融进用户、流程、需求矩阵、验收和风险。
+- 如果当前需求仍然像 0 到 1 验证，不要只写“做什么功能”；还要写清第一批先找谁、现在怎么替代、如何先手工交付、什么承诺才算真需求，以及验证阶段怎样先活下来。
 - PRD 写产品判断，`design.md` 写技术方案，`tasks.md` 写执行步骤。
 - 每条 requirement 都应能追踪到验收标准和后续 task。

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

@@ -2,11 +2,11 @@
 
 ## 判断维度
 
-按下面四个维度判断，不按固定关键词判断。用户审查时优先展示“需求类型：快速修正（L0）”这类合并标签；只有内部调度和排障真的受益时，才额外附上“内部路由码”。
+按下面四个维度判断，不按固定关键词判断。用户审查时优先展示“需求类型：直接处理（L0）”这类合并标签；只有内部调度和排障真的受益时，才额外附上“内部路由码”。
 
 | 用户可见需求类型 | 内部路由码 | 默认路径 |
 |---|---|---|
-| 快速修正 | L0 | 直接处理，完成后说明验证 |
+| 直接处理 | L0 | 直接处理，完成后说明验证 |
 | 现有功能优化 | L1 | 先给 mini-plan，再实现和验证 |
 | 新功能/新流程方案 | L2 | 先澄清并进入 PRD/review/change/tasks |
 
@@ -23,9 +23,9 @@
 
 - 小 UI 调整：按钮文案、颜色、间距、字号、单点样式、局部 bug，通常仍按 L0 或 L1。
 - 大界面改动：信息架构、核心布局、主视觉、关键路径、组件层级/密度明显变化，或用户需要先选设计方向。
-- 大界面改动不直接实现；在 mini-plan、PRD 定稿或实现开工前，先用 Computer Use 截当前产品内功能图，再用 Image 2 生成至少 3 个方向，横向拼接带 1/2/3 序号的大图给用户确认。
+- 大界面改动不直接实现；在 mini-plan、PRD 定稿或实现开工前，已有界面时先用 Computer Use 截当前产品内功能图，冷启动没有现有界面时基于已确认 PRD、用户群体、第一版切片和视觉目标生成设计 brief；再用 Image 2 生成至少 3 个方向，横向拼接带 1/2/3 序号的大图给用户确认。
 
-## L0：快速修正
+## L0：直接处理
 
 适合直接处理：
 
@@ -34,7 +34,7 @@
 - 简单样式调整，不改变信息架构或用户流程
 - 单个配置值或展示值修正
 
-输出：需求类型为“快速修正”，直接做，完成后说明验证。不要生成 PRD。
+输出：需求类型为“直接处理”，直接做，完成后说明验证。不要生成 PRD。
 
 ## L1：现有功能优化
 
@@ -60,6 +60,10 @@
 
 输出：需求类型为“新功能/新流程方案”，先澄清并进入 PRD/review/change/tasks。
 
+补充判断：
+
+- 如果这句话本质上还在问“值不值得做、先找谁验证、现在怎么替代、能不能先手工交付、什么承诺才算真需求”，即使功能点看起来不多，也优先按 L2 进入脑暴或 clarify，不要直接下实现判断。
+
 ## 续接规则
 
 当用户提供会话 ID、work unit、task handle 或说“继续这个任务”：

package/skills/openprd-requirement-intake/references/startup-validation-lens.md

@@ -0,0 +1,23 @@
+# 创业验证透镜
+
+当 L2 需求、脑暴模式或 0 到 1 方向讨论还停留在“做什么功能”时，用这组问题把它收回到更真实的验证闭环。
+
+## 六个关键问题
+
+1. 第一批最容易触达的社区、渠道或人群是谁？
+2. 他们现在主要靠什么替代方案、流程或人工方式在解决？
+3. 如果先不做完整产品，怎么靠手工服务、半自动流程或轻量交付先把价值跑出来？
+4. 什么真实承诺最能证明这不是口头兴趣？
+5. 最低成本先验证哪一步最关键？
+6. 在验证阶段，怎样控制成本、时间和交付方式，确保这件事先活下来？
+
+## 使用方式
+
+- 不要机械逐条盘问；优先把它融进 requirement 摘要、脑暴卡片和追问顺序里。
+- 如果用户已经明确提供其中几项，就直接吸收，不要重复确认。
+- 对内部工具、团队流程或 Agent 项目，也照样适用。
+  这里的“社区 / 种子用户”可以是维护者、运营、交付、内部试点团队或最先受影响的一线角色。
+- “承诺信号”不等于一定要收费。
+  也可以是愿意预约、提交真实素材、导入数据、拉同事参与、接受试点、给出明确上线窗口等更强承诺。
+- “default alive”不是财务口号，而是提醒 Agent 先问清楚：
+  这件事在验证阶段怎样不把成本、复杂度和维护负担一下子做爆。

package/skills/openprd-router/SKILL.md

@@ -15,15 +15,22 @@ description: OpenPrd 入口路由 skill。先判断当前任务该读哪个 repo
 
 ## 入口顺序
 
-1. 先从 `.openprd/` 重建当前状态，并运行 `openprd run . --context`
-2. 需要具体命令时，优先读取 `.openprd/harness/command-catalog.md`
-3. 需要共用约束时，读取 `skills/openprd-shared/SKILL.md`
-4. 需要主工作流时，读取 `skills/openprd-harness/SKILL.md`
+1. 如果用户当前明确在说“帮我梳理下”“先想清楚”“进入脑暴模式”，先读取 `skills/openprd-requirement-intake/SKILL.md`，并优先运行 `openprd run . --context --message <用户原话>`；需要时直接进入 `openprd brainstorm . --open`，不要只跑不带 message 的 `openprd run . --context`
+2. 其他情况再从 `.openprd/` 重建当前状态，并运行 `openprd run . --context`
+3. 如果当前是空白工作区的前端/页面冷启动，而且用户已经给了明确的页面主题、模块范围或“直接实现”的意图，优先改用 `openprd run . --context --message <用户原话>`；不要先跑不带 message 的 `openprd run . --context`，再被空白工作区自己的 `clarify-user` 带偏
+4. 需要具体命令时，优先读取 `.openprd/harness/command-catalog.md`
+5. 需要共用约束时，读取 `skills/openprd-shared/SKILL.md`
+6. 需要主工作流时，读取 `skills/openprd-harness/SKILL.md`
+7. 任务涉及界面、页面、视觉、样式、信息架构、内容型页面或前端体验时，额外读取 `skills/openprd-frontend-design/SKILL.md`
+8. 如果当前是轻量前端原型任务，而且工作区几乎没有现成页面文件，读完前端设计 skill 后先填写 `.openprd/design/active/*`，不要在 `docs/basic/` 占位文档里来回打转
+9. 如果用户已经给了效果图、设计稿、参考截图或其他明确参考图，仍然走前端设计 skill，但要把参考图当主约束；只有现有 starter / theme / layout 足够接近时才复用，不要让样式库把页面带到另一种风格
+10. 如果这类空白前端任务在带 message 的前提下仍短暂返回 `clarify-user`，但用户原话已经明确要求直接实现单页/首页/原型，就把它当成摘要级提醒；先用 3 到 5 行 mini-plan 收口，再按 frontend design 的 `design-starter -> Patch Mode` 路径继续，不要回到长澄清或模板源码漫游
 
 ## 路由表
 
 - 需求入口分流、用户可见需求类型与内部 L0/L1/L2 路由码对照、PRD 场景视角选择：`skills/openprd-requirement-intake/SKILL.md`
 - 主工作流、review/change/tasks、`run/loop`：`skills/openprd-harness/SKILL.md`
+- 前端设计框架、审美资产库、主题/骨架/组件/配方、事实与素材前置门：`skills/openprd-frontend-design/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`
@@ -37,4 +44,5 @@ description: OpenPrd 入口路由 skill。先判断当前任务该读哪个 repo
 - hooks 已经强制处理 requirement / research / secrets / skill-visualization / weapp / browser / copy 这些门禁
 - 公开 GitHub 仓库架构/对标先 DeepWiki；第三方库、API、SDK、MCP、CLI 用法先查本地证据，本地不足时再按 `resolve_library_id -> query_docs` 使用 Context7
 - 如果用户只是要规划、分析、评审或解释影响范围，保持只读，不要因为命令存在就直接执行写入
-- 不要用固定关键词决定是否写 PRD；先让 `openprd-requirement-intake` 按影响面、未知数、决策成本和验证成本做语义分流
+- 用户原话里已经明确要求“先梳理/脑暴”时，用户意图优先于不带 message 的默认 run context；先把原话带进 `openprd run . --context --message ...`，或直接进入脑暴模式
+- 不要用固定关键词决定是否写 PRD，也不要用词表决定工具；先让 `openprd-requirement-intake` 按影响面、未知数、决策成本和验证成本做语义分流，再按用户目标、期望产物、交付阶段和证据缺口选择学习器、视觉评审或质量收口工具

package/skills/openprd-shared/SKILL.md

@@ -15,7 +15,7 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
 - 用户耐心低，输出要先给结论和下一步；能一句说清楚就不要拆成两步，细节等用户追问时再展开。
 - 面向用户的 HTML、报告、评审说明和对话回复，避免 `freeze`、hook、门禁、EVO、schema、runtime 等内部词；必要技术名词只在确实影响决策时出现，并用业务语言解释结果。
 - 主动替用户补全没有想到的情况：范围边界、失败路径、恢复路径、实现成本、维护成本、滥用风险、第三方依赖、上线后验证和后续扩展。
-- 对外 README、首页概览、发布说明和带文字的示意图，默认先站在产品和业务用户角度解释：谁在什么场景下遇到什么问题、怎么确认、收益和风险是什么。解释需求分流时，优先使用“快速修正 / 现有功能优化 / 新功能/新流程方案”这些用户可理解名称，再在内部保留 L0/L1/L2。
+- 对外 README、首页概览、发布说明和带文字的示意图，默认先站在产品和业务用户角度解释：谁在什么场景下遇到什么问题、怎么确认、收益和风险是什么。解释需求分流时，优先使用“直接处理 / 现有功能优化 / 新功能/新流程方案”这些用户可理解名称，再在内部保留 L0/L1/L2。
 - 默认成本敏感，追求“效果足够好 + 投入最少 + 后续维护不重”的性价比；不要为了技术漂亮引入昂贵或复杂方案。
 - 涉及第三方 API、模型、云服务、付费工具或外部供应商时，优先比较多家可行方案，用表格列出效果、价格、接入成本、限制、风险和推荐理由，并给出性价比最好的默认选择。
 - 当用户的问题包含多个对象、方案、文件、场景、风险、验证项、素材或任务，并且需要同时呈现状态、证据、影响、动作或推荐时，Agent 应主动使用 Markdown 表格，不等用户要求。先用一句话给结论，再给表格。
@@ -61,7 +61,8 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
    - 用户给出会话 ID 并要求继续时，按工具无关的历史会话精确续接；不要要求工具专属 ID，也不要用当前 active change、相似历史或 requirement gate 替代指定会话。
    - 用户没有给 ID、但明确描述了某个已有需求、change、task 或 work unit 时，先按描述解析对应对象；只有解析不出来时，才把当前工作区状态当作背景继续看。
    - 使用 `.openprd/harness/install-manifest.json`、`hook-state.json`、`events.jsonl` 和 `drift-report.json` 判断生成引导是否健康。
-   - 使用 `.openprd/harness/visual-reviews/` 承接大界面改动的效果图方案评审、选中方向、实现后视觉对比证据、局部焦点证据板和并行实验证据板。
+   - 前端体验任务进入实现前，优先读取 `skills/openprd-frontend-design/SKILL.md` 与 `.openprd/design/`，先锁定 lens、theme、layout 和组件，再决定是否实现。
+   - 使用 `.openprd/harness/visual-reviews/` 承接用户已经确认纳入后续对比的 reference-set、选中方向、实现后视觉对比证据、局部焦点证据板和并行实验证据板；候选效果图默认不要直接登记进去。
    - 使用 `.openprd/quality/config.json`、`.openprd/quality/reports/` 和 `.openprd/knowledge/` 判断实现就绪、当前场景必需 EVO 证据和可复用经验。
    - 使用 `.openprd/growth/` 承接收工阶段的自我成长复盘；工具识别补全和减少重复打扰这类高置信低风险项可自动补齐，用户偏好、项目协作规矩和 OpenPrd 默认行为留到收工时集中确认。
 10. 生成图片内容时默认使用 `imagegen`，也就是 Codex 原生 Image 2。
@@ -70,25 +71,34 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
    - 只有当用户明确要求 mockup、场景化效果图、容器化呈现，或参考图本身就包含这些承载结构时，才生成对应的容器或场景。
    - 除非用户明确指定 HTML、SVG、CSS、Canvas、代码稿或可编辑矢量/source artifact，不要改用临时 HTML/SVG/CSS 再截图。
    - 只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流；未调用 `imagegen` 前，不要声称“生图限流”或“生图失败”。
-   - OpenPrd 的 `review.html` 只用于需求评审，不能替代图片或效果图生成；`visual-compare` 只用于实现阶段视觉证据：已有参考图时做“效果图 / 实现截图”对比，无参考图但改动界面时做“修改前 / 修改后”自检；当局部细节更重要时，优先改用 `--board` 生成“局部焦点证据板”；当并行跑了多个优化方向时，优先改用 `--board` 生成“并行实验证据板”。
+   - 生图结果先当候选效果图，不要默认登记到 `.openprd/harness/visual-reviews/`。如果用户还要继续做实现，主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后才把选定方向、整张图或其中子图整理成 reference-set。
+   - OpenPrd 的 `review.html` 只用于需求评审，不能替代图片或效果图生成；`visual-compare` 只用于实现阶段视觉证据：已有确认参考图时做“效果图 / 实现截图”对比；没有参考图时先判断新建界面还是修改既有界面，新建界面回到实现前 3 方向方案评审，修改既有界面做“修改前 / 修改后”自检；当局部细节更重要时，优先改用 `--board` 生成“局部焦点证据板”；当并行跑了多个优化方向时，优先改用 `--board` 生成“并行实验证据板”。
 11. 界面视觉实现有参考图时，必须留下左右对比图。
    - 只要任务涉及界面、页面、视觉、样式或前端体验，并且已经有效果图、设计稿、截图或用户给图且进入实现阶段，阶段性完成后先截取实现截图。
    - 运行 `openprd visual-compare . --reference <效果图> --actual <实现截图>`，默认输出 JPG 到 `.openprd/harness/visual-reviews/`。
-   - 合成图左侧必须标注“效果图”，右侧必须标注“实现截图”；查看合成图后继续对标，直到没有明显视觉差异。
+   - 如果一张参考图里有多个子图、网格或对象，先运行 `openprd visual-prepare . --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>`，检查 contact sheet 后再逐项对比。
+   - 合成图左侧必须标注“效果图”，右侧必须标注“实现截图”；查看合成图后继续对标，直到没有明显视觉差异。若用户后续说“跟效果图”“不一致”“好丑”“复刻”，至少先产出一份视觉证据图，不要只口头说已经对比过了。
    - 如果整体图之外还要审局部细节，再补一份 `openprd visual-compare . --board <focus-board.json>`，把整体标框和局部放大放在同一张证据板里。
    - 未生成并查看对比图，或对比图仍有明显差异时，不要声称界面复刻或视觉实现完成。
-12. 界面视觉实现无参考图时，必须留下修改前后自检图。
-   - 只要任务涉及界面、页面、视觉、样式或前端体验，但没有明确效果图、设计稿、截图或用户给图，动手前先用 Computer Use、Browser、Playwright 或项目现有工具截取修改前截图。
-   - 完成后用同一入口、视口、账号和数据状态截取修改后截图，再运行 `openprd visual-compare . --before <修改前截图> --after <修改后截图>`。
+12. 界面视觉实现无参考图时，先区分新建界面和修改既有界面。
+   - 只要任务涉及界面、页面、视觉、样式或前端体验，但没有明确效果图、设计稿、截图或用户给图，先判断这是新建界面还是修改既有界面。
+   - 新建首屏、首页、控制台或核心页面时，回到实现前 3 方向方案评审；修改既有界面时，动手前先用 Computer Use、Browser、Playwright 或项目现有工具截取修改前截图。
+   - 修改既有界面完成后，用同一入口、视口、账号和数据状态截取修改后截图，再运行 `openprd visual-compare . --before <修改前截图> --after <修改后截图>`。
    - 合成图左侧必须标注“修改前”，右侧必须标注“修改后”；查看合成图后确认预期变化出现，并检查未改区域没有明显布局、颜色、密度或状态漂移。
    - 如果并行试了多条优化方向，再补一份 `openprd visual-compare . --board <parallel-board.json>`，把多方案截图、GIF 首帧和指标放到同一板里对比。
    - 这类自检不能替代大界面方向性改造的实现前方案评审。
 13. 大界面改动实现前必须先完成视觉方案评审。
    - 触发条件：会明显改变页面信息架构、主视觉、核心布局、关键路径、组件层级/密度，或用户需要先选择设计方向。
    - 位置：需求分流之后、PRD 定稿或实现开工之前；它不是 `review.html`，也不是实现后的 `visual-compare`。
-   - 步骤：用 Codex Computer Use 进入产品内对应功能并截当前真实界面；用 `imagegen`（Codex 原生 Image 2）基于截图做图生图；至少生成 3 个不同设计思想方向；把效果图横向拼成一张大图，每张左上角标注 1/2/3，并保存到 `.openprd/harness/visual-reviews/`。
-   - 交互：把横向大图展示给用户评审确认；用户确认方向前，不进入大 UI 实现，也不要声称界面方案已定。
-14. 把文档与结构回顾视为实现的一部分，而不是开工前的噪声。
+   - 步骤：已有界面时用 Codex Computer Use 进入产品内对应功能并截当前真实界面；冷启动没有现有界面时，基于已确认 PRD、用户群体、第一版切片和视觉目标生成设计 brief；用 `imagegen`（Codex 原生 Image 2）基于截图或设计 brief 至少生成 3 个不同设计思想方向；把效果图横向拼成一张大图，每张左上角标注 1/2/3，先作为候选效果图展示。
+   - 交互：主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后才把选定方向、整张图或其中子图整理到 `.openprd/harness/visual-reviews/`。用户确认前，不进入大 UI 实现，也不要声称界面方案已定。
+14. 界面任务进入实现前，先用 `.openprd/design/` 锁定设计框架。
+   - 页面涉及具体产品事实、版本、发布时间、规格、价格、引用数据或地点事实时，先补 `.openprd/design/active/facts-sheet.md`，不要凭记忆写页面。
+   - 页面依赖 logo、产品图、UI 图、摄影图、插图、图表或品牌色字体时，先补 `.openprd/design/active/asset-spec.md`。
+   - 旅游、展览、内容、案例、发布、品牌故事等内容型页面，要先判断真实图片是不是页面成立前提；必要时先补 `.openprd/design/active/image-preflight.md`，不要默认用占位块硬做。
+   - 没有明确参考方向时，先补 `.openprd/design/active/direction-plan.md`，并确保 3 个方向来自不同生成逻辑，而不是三个同一种安全解的轻微变体。
+   - 用户选定方向后，再补 `.openprd/design/active/selected-direction.md`，把选中的 lens、theme、layout、组件和风险锁定。
+15. 把文档与结构回顾视为实现的一部分，而不是开工前的噪声。
    - 代码修改完成后、最终回复前，针对本轮实际新增或修改的 code files 运行 `openprd dev-check . <file...>` 或 `node scripts/openprd-dev-check.mjs . <file...>`。
    - dev-check 默认是收工回顾，不是开工许可证；只有用户明确询问影响文件、拆分边界，或你已经判断需要先设计拆分范围时，才在开发前额外运行。
    - 行数状态按研发期标准解读：700 行以内正常；701-1500 行需留意；超过 1500 行说明后续改动成本较高。若出现需要关注的文件，最终回复必须以 **后续建议** 为标题，用 Markdown 表格列出影响位置、关注程度、规模信号、为什么需要关注、本次处理和后续建议，并按 🔴 → 🟠 → 🟡 排序；若只是窄 bugfix 或小修且暂不拆，要在表格里说明本次处理边界并留下后续拆分建议。
@@ -98,42 +108,44 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
    - 当职责、流程、结构、依赖或产品行为变化时，补齐缺失文档并更新已有文档。
    - 涉及后端、脚本、Agent、工具链、服务或数据处理变更时，把 CLI 与 API 视为同级接入面；检查命令入口、参数、输出契约、`help`/`doctor`/`dry-run`/`status` 与接口协议、返回结构、身份边界是否受影响，并同步更新 `docs/basic/backend-structure.md`；若某一面不适用也要明确写原因。
    - `.openprd/harness/install-manifest.json` 的 `optionalCapabilities` 用来记录非阻断式增强建议，例如 Context7、DeepWiki。当前任务明显受益但状态仍是 `recommended` 时，在后续建议里解释它能帮什么、附官方文档和 GitHub 链接，并可顺手提出“如果你愿意，我可以按当前客户端帮你补配置”；不要因为它未配置就阻断当前任务。
-14. hook 重量要和任务风险匹配。
+16. hook 重量要和任务风险匹配。
    - 默认 Codex hook profile 是 `lite`：`UserPromptSubmit` 注入上下文，轻量 `PreToolUse` 写入门禁阻断过早实现，`Stop` 在本轮结束前回顾是否值得沉淀项目经验。明确的 OpenPrd / 深度工作提示词，以及新的产品、模块、流程需求都会注入上下文。
    - 只有项目明确需要完整 hook 遥测或临时深度诊断时才使用 `full`。
-15. 需求流程先分流再加门禁。
+17. 需求流程先分流再加门禁。
    - 分流优先使用 `$openprd-requirement-intake`，不要按固定关键词判断。
-   - 用户可见需求类型和内部路由码的固定对照为：快速修正=L0、现有功能优化=L1、新功能/新流程方案=L2；默认把路由码并进“需求类型：快速修正（L0）”这类标签里，只有内部排障确实受益时才额外补“内部路由码”。
-   - 快速修正包括空格、错别字、按钮文案、简单样式、明确 bugfix 和低风险局部调整；直接执行，完成后说明变更和验证。
+   - 用户可见需求类型和内部路由码的固定对照为：直接处理=L0、现有功能优化=L1、新功能/新流程方案=L2；默认把路由码并进“需求类型：直接处理（L0）”这类标签里，只有内部排障确实受益时才额外补“内部路由码”。
+   - 直接处理通常包括空格、错别字、按钮文案、简单样式、明确 bugfix 和低风险局部调整；直接执行，完成后说明变更和验证。
    - 现有功能优化有明确落点但影响多个文件或行为；先给对话内 mini-plan，再实现和验证。
    - 如果用户刚刚已经确认了现有功能优化（L1）的 mini-plan、范围边界或正式产品边界，后续承接要明确写成“已确认，我按这个继续/收口/落地”，不要只写一个“确认”，也不要写成“确认，我们就按这个……”这种像再次索取确认的句子。
-   - 新功能/新流程方案包括新产品、模块、流程、权限、计费、AI/第三方集成、云服务、跨系统、数据迁移或边界不清的需求；先走 requirement intake、对话内 requirement 摘要确认、review、change 和 tasks，再实现。
-   - 历史 active change 在新 requirement intake 激活时只作为提醒，不抢当前主线。
+- 新功能/新流程方案包括新产品、模块、流程、权限、计费、AI/第三方集成、云服务、跨系统、数据迁移或边界不清的需求；先走 requirement intake、对话内 requirement 摘要确认、review、change 和 tasks，再实现。
+- 对话内 requirement 摘要保持原有“需求判断 / 需求理解 / 功能范围 / 技术方案”结构，但 `需求判断` 和 `需求理解` 先用轻量主句说清结论；边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们挤成一大段。
+- 对于 L2 或脑暴诉求，默认再补一层“创业验证闭环”：第一批最容易触达的人群/社区、当前替代方案、先不做完整产品时的手工路径、什么真实承诺才算真需求、最低成本验证动作，以及验证阶段怎样先活下来。
+- 历史 active change 在新 requirement intake 激活时只作为提醒，不抢当前主线。
    - 会话 ID、task handle、work unit 和用户明确描述的已有需求对象，都比全局 active change 更具体；必须先解析这些显式目标，再决定是否沿用当前工作区状态。
-16. 关键产品事实缺失时，先问用户再推进。
+18. 关键产品事实缺失时，先问用户再推进。
    - 如果当前模式不能使用结构化 ask-user 工具，就用自然语言直接询问。
    - 不要把“工具不可用”当成可以悄悄猜测的理由。
-17. 外部技术与公开仓库调研遵循“本地优先、外部证据最小够用”。
+19. 外部技术与公开仓库调研遵循“本地优先、外部证据最小够用”。
    - 先读本地代码、锁文件、README、类型定义和现有上下文。
    - 涉及第三方库、框架、API、SDK、MCP、CLI 工具的用法、配置、限制、版本差异或迁移路径，本地证据不足时再交给 `$openprd-benchmark-router`，并按 `resolve_library_id -> query_docs` 使用 Context7。
    - 涉及公开 GitHub 仓库的架构、核心模块、关键流程或对标结论时，先交给 `$openprd-benchmark-router`，并按 `read_wiki_structure -> ask_question` 使用 DeepWiki。
    - 一旦证据足够支撑当前决策就停止扩展；如果 DeepWiki、Context7 或官方资料覆盖不足，要明确写出缺口。
-18. 涉及凭证、账号和个人信息时，先走 `secrets-vault`。
+20. 涉及凭证、账号和个人信息时，先走 `secrets-vault`。
    - 任务需要 API key、token、账号信息、第三方服务凭证或个人信息时，先使用 `secrets-vault` skill 获取已有凭证，不要立即向用户索要。
    - 只读取当前任务所需的最小字段；不要直接读取原始 vault 文件，也不要在日志、代码、回复或提交里暴露完整密钥。
-19. 修改 skill、`SKILL.md`、`AGENTS.md` 或相关 workflow 前，先可视化确认。
+21. 修改 skill、`SKILL.md`、`AGENTS.md` 或相关 workflow 前，先可视化确认。
    - 先读取当前 skill / AGENTS 现状，再输出一张彩色 Mermaid 方案图。
    - Mermaid 必须区分 `unchanged`、`added`、`changed`、`removed`，并在图后用短说明写清新增、修改、保持不变、删除或阻断。
    - 必须等待用户明确确认后，才能修改相关文件。
-20. 涉及微信小程序运行态时，只在明确需要运行态证据时再升级到本地验证。
+22. 涉及微信小程序运行态时，只在明确需要运行态证据时再升级到本地验证。
    - 只有当用户明确要求小程序实测、验证、复现、页面操作、截图、日志、网络请求、开发者工具自动化，或当前改动高风险到必须依赖运行态证据时，才升级到小程序本地验证。
    - 一旦进入小程序运行态验证，默认沿用当前小程序运行态或开发者工具会话连续验证，不要为了验证自动重开应用；只有用户明确要求从 0 到 1、冷启动、重开或重新打开时，才从头启动。
    - 优先使用当前环境已配置的小程序本地验证能力；如果当前客户端没有相应工具，不要假定已经安装，也不要把缺少工具本身当成任务失败。
    - 未拿到本地运行态证据前，不要宣称“小程序已验证”。
-21. 浏览器高风险动作要先确认窗口归属。
+23. 浏览器高风险动作要先确认窗口归属。
    - 用户明确要求使用 Computer Use 时，优先尊重该工具选择，并尽量在 Codex-owned browser window 中操作。
    - 对提交表单、删除内容、发送消息、切换账号、退出登录、支付、关闭标签页等高风险动作，先确认窗口标题、目标页面和可见内容仍属于本任务。
-22. 产品内文案默认面向普通用户，并先检查多语言结构。
+24. 产品内文案默认面向普通用户，并先检查多语言结构。
    - 修改用户可见文案前，先检查是否已有 `i18n`、`locales`、`translations`、`Localizable` 或其他语言资源；若已有，用户可见文案要同步维护到所有已支持语言。
    - 文案优先说明用户能做什么、会发生什么、下一步怎么做；避免把 API、SDK、模型、数据库、缓存、错误码等实现细节直接暴露给用户。
    - commit 说明、handoff / 版本说明、review 摘要这类面向人阅读的变化说明，默认优先使用 `新增 / 修复 / 优化 / 调整 / 移除` 这类短标签，并从用户可感知变化出发组织一句话说明。
@@ -147,8 +159,8 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
 - 只有当当前用户消息明确要求开发、实现、修复、继续任务、深度调研、对标复刻或提交时，才执行 OpenPrd loop、task 或 discovery 推进。
 - 单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。
 - 声称实现就绪前，要说明文档影响检查是新增、更新，还是有意保持 `docs/basic/`、文件说明书和文件夹 README 不变。
-- 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup、先看样子或先确认设计方向时，最终回复应给出 `imagegen` 生成的图片结果；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流。进入实现阶段后，已有参考图才给出 `openprd visual-compare --reference/--actual` 生成的 JPG 路径，无参考图但改动界面时给出 `openprd visual-compare --before/--after` 生成的 JPG 路径，并说明是否仍有差异或漂移。
-- 大界面改动进入实现前，最终回复或阶段性回复应给出 3 方向横向效果图大图，并明确等待用户选择方向；用户确认后再进入实现。
+- 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup、先看样子或先确认设计方向时，最终回复应给出 `imagegen` 生成的图片结果；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流。生图结果先当候选效果图，并主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现。进入实现阶段后，已有确认参考图才给出 `openprd visual-compare --reference/--actual` 生成的 JPG 路径；如果参考图是一张整板、网格图或多对象组合，先运行 `openprd visual-prepare --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>` 并说明 contact sheet / compare-plan；没有参考图时先判断新建界面还是修改既有界面，新建界面先完成 3 方向方案评审，修改既有界面给出 `openprd visual-compare --before/--after` 生成的 JPG 路径，并说明是否仍有差异或漂移。
+- 大界面改动进入实现前，最终回复或阶段性回复应给出 3 方向横向候选效果图大图，并明确等待用户确认是否纳入后续对比和继续实现；只有确认后再进入实现。
 - 在系统形态、产品流程或外部依赖仍有实质不确定性时，需求定稿前先向用户确认。
 - 当用户还没看过最新的 synthesize 产物或图示产物时，handoff 前先确认。
 - 当用户要求可视化说明时，路由到 `$openprd-diagram-review`。
@@ -157,6 +169,7 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
 
 - 需要判断需求该直接做、mini-plan 还是写 PRD：使用 `$openprd-requirement-intake`
 - 需要推进主工作流生命周期：使用 `$openprd-harness`
+- 需要前端审美框架、设计资产、主题/骨架/组件/任务 recipe、事实/素材/image-preflight/direction-plan：使用 `$openprd-frontend-design`
 - 需要最佳实践、benchmark、对标、参考产品、prompt engineering、Agent harness、context engineering、图标资源、CLI 或 skill 体系设计：先使用 `$openprd-benchmark-router` 选择证据源，再按 DeepWiki、Context7 或官方资料规则调研
 - 需要架构图、产品流程图、用户旅程或可视确认循环：使用 `$openprd-diagram-review`
 - 需要更细的语言规则或命令分类说明时，阅读：