@openprd/cli 0.1.9 → 0.1.10

package/skills/openprd-benchmark-router/SKILL.md

@@ -23,6 +23,7 @@ description: 为 OpenPrd 产品、CLI、Agent harness、AI code review / PR revi
 
 - 用户提到 OpenPrd、OpenSpec、Superpowers、Anthropic Skills、Lark CLI、Agent harness、AI code review、PR review、review lane、long-running agents、context engineering、prompt engineering、最佳实践、对标、参考、复刻或优化设计。
 - 用户提到图标、icon、图标站、图标库、图标资源、UI 图标、AI 图标、技术图标、3D 图标、功能图标、iconfont 或视觉资产参考。
+- 用户提到界面审美、设计框架、主题库、模板库、组件骨架、视觉资产库、前端体验风格或页面参考方法。
 - 用户要求解释某个 Codex / Claude / Cursor agent 为什么没有发现 skill，或希望提升 skill 自动识别、路由、生成、安装和持续执行能力。
 - 用户没有显式说 skill 名也要触发；不要要求用户记住 `$openprd-benchmark-router`。
 
@@ -48,6 +49,7 @@ description: 为 OpenPrd 产品、CLI、Agent harness、AI code review / PR revi
 - GitHub 仓库：需要理解架构、核心模块、关键流程或对标结论时，先用 DeepWiki。默认顺序是 `read_wiki_structure` 1 次，再 `ask_question` 1-2 次；只有在本地源码和已有结论仍不足时才追加。DeepWiki 不可用或覆盖不足时，再回退到 GitHub README、源码和官方文档。
 - 官方技术文档：涉及第三方库、框架、API、SDK、MCP、CLI 工具的用法、配置、限制、版本差异或迁移路径时，先检查本地代码、锁文件、README、类型定义；本地不足时再用 Context7，默认顺序是 `resolve_library_id` 1 次，再 `query_docs` 1-2 次。Context7 不足时说明缺口，再补官方文档、源码或其他一手资料。
 - 工程文章和产品文档：优先读取当前线上一手页面，只抽取和当前任务相关的观点与设计原则，不复制长文；如果内容可能过时，要说明时效风险。
+- 视觉与设计参考：优先吸收结构、节奏、信息组织、资产策略和质量门，不照搬品牌表层风格。需要官方品牌或产品事实时，优先官方站点、官方媒体包、官方设计系统和项目自身 approved benchmark。
 - 本地源码优先：当前工作区已经有相关源码时，常规修 bug、查实现、改功能优先读本地代码；DeepWiki 主要用于外部仓库架构理解和对标分析。
 - 停止调研：找到足以支持当前决策的 1-3 个高相关来源后停止扩展；候选来源重复时保留更权威、更新或更贴近当前任务的来源。
 - 追加调用前先写清“已确认什么、还缺什么”；不要为了同一问题只换个说法反复查询。
@@ -55,6 +57,7 @@ description: 为 OpenPrd 产品、CLI、Agent harness、AI code review / PR revi
 ## Source Map
 
 - OpenPrd / PRD 设计对标：`obra/superpowers`、`Fission-AI/OpenSpec`。
+- 创业验证 / 需求收口透镜：`slavingia/skills`。
 - CLI 与 skill 体系对标：`larksuite/cli`、`anthropics/skills`、Claude Skills 官方文档、Claude Code Skills 官方文档。
 - 长程 Agent 任务：Anthropic long-running agents harness 工程文章。
 - 通用 harness：OpenAI harness engineering、LangChain agent harness anatomy。
@@ -72,6 +75,7 @@ description: 为 OpenPrd 产品、CLI、Agent harness、AI code review / PR revi
 - 上下文工程：哪些信息常驻、哪些按需检索，是否使用稳定路径、链接和来源 ID 支持 just-in-time 检索，如何处理过期、冲突和可信度。
 - 提示词与 Skill 设计：触发描述是否具体但不过度强制，主说明是否短，细节是否按需放到 reference，是否明确不要硬套参考源。
 - 图标与视觉资产：先判断用途是 UI、AI 品牌、技术栈、3D 物件还是功能图标；优先选最贴近用途的资源站，再在实现阶段选择合适的代码图标库。
+- 前端设计框架：先判断要借的是主题锁定、布局骨架、组件清单、事实前置、素材前置、图片前置还是质量门；把可迁移原则落回 `.openprd/design/`、repo-local skill、hooks 或测试，不要停留在“参考了几个好看页面”。
 - CLI 与开发者体验：命令是否可发现、可组合、可预测；错误信息是否说明发生了什么、影响是什么、下一步怎么做；危险操作是否有确认。
 
 ## 设计输出

package/skills/openprd-frontend-design/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: openprd-frontend-design
+description: 为 OpenPrd 的界面、页面、视觉、样式和前端体验任务提供设计资产框架、前置门禁和实现前方向评审规则。
+---
+
+# OpenPrd Frontend Design
+
+当任务涉及界面、页面、视觉、样式、组件层级、信息架构、内容型页面或前端体验时，使用这份 skill。
+
+## 核心目标
+
+- 让 Agent 在动手实现前，先有一套稳定的前端设计资产和判断顺序。
+- 避免界面任务默认收敛成同一种安全解。
+- 避免“没素材硬做”“事实没核实就写页面”“看起来好看但空心”的情况。
+
+## 先读这些文件
+
+- `.openprd/design/README.md`
+- `.openprd/design/templates/README.md`
+
+如果当前工作区本来就有现成前端结构，或你明确需要偏离模板默认组合，再读：
+
+- `.openprd/design/lenses/frontend-lenses.md`
+- `.openprd/design/themes/theme-catalog.json`
+- `.openprd/design/layouts/layout-catalog.json`
+- `.openprd/design/components/component-catalog.md`
+- `.openprd/design/checklists/ui-quality-gate.md`
+- `.openprd/design/anti-slop.md`
+
+如果本轮已经进入实现准备，再读：
+
+- `.openprd/design/active/facts-sheet.md`
+- `.openprd/design/active/asset-spec.md`
+- `.openprd/design/active/image-preflight.md`
+- `.openprd/design/active/direction-plan.md`
+- `.openprd/design/active/selected-direction.md`
+
+## 使用顺序
+
+1. 先判断这是不是前端体验任务。
+2. 选一个 `lens`，明确这次界面的视觉判断角度。
+3. 选一个 `theme`、一个 `layout skeleton` 和一个 `recipe`。
+4. 如果页面会写具体产品事实，先补 `facts-sheet.md`。
+5. 如果页面依赖品牌素材、产品图、界面图、图库或插图，先补 `asset-spec.md`。
+6. 如果这类页面没有真实图片就会空心，先补 `image-preflight.md`。
+7. 如果用户还没有给参考方向，先补 `direction-plan.md`，明确 3 个异源方向。
+8. 用户选定方向后，再补 `selected-direction.md`，把选中的 lens、theme、layout、组件和风险锁定。
+9. 如果用户已经给了效果图、设计稿、参考截图或其他明确参考图，先把它视为主参考源：优先锁定它的版式、层级、主视觉和关键路径；`starter / lens / theme / layout` 只作为实现加速器，不作为高于参考图的裁决源。
+10. 如果当前是空白工作区的前端/页面冷启动，而且用户原话已经给了明确的页面主题、模块范围或“直接实现”的意图，优先运行 `openprd run . --context --message <用户原话>`，不要先跑不带 message 的 `run --context`。
+11. 跑完 `design-starter` 后，立即进入 `Patch Mode`：把生成的入口文件当成稳定基座，在同一路径里细化结构、内容、样式和交互。
+12. 最后再进入验证，并用 `.openprd/design/checklists/ui-quality-gate.md` 做自检。
+
+## 空白工作区快路径
+
+如果当前工作区几乎没有前端入口文件，或只有 `.openprd/` 与说明文档：
+
+1. 先运行一次 `openprd run . --context` 看建议路径；如果当前轮用户已经把页面主题、模块范围或“直接实现”的意图说清，优先带 `--message <用户原话>`，让建议基于当前请求，而不是只看空白工作区状态。
+2. 如果建议已经是轻量原型/轻量实现路径，或这类 blank frontend task 在带 message 后仍短暂返回 `clarify-user` 但用户原话已足够明确，不要继续长时间翻 `docs/basic/` 占位文档。
+3. 立刻把 `.openprd/design/active/facts-sheet.md`、`asset-spec.md`、`image-preflight.md`、`direction-plan.md`、`selected-direction.md` 写成具体内容；如果当前任务是个人博客、通用静态首页、单页介绍或其他不依赖外部产品事实/品牌素材/真实图片的页面，也要明确写成“无外部事实依赖”“当前无品牌素材依赖”“真实图片不是页面成立前提”，不要长期保留 `pending`。
+4. 选 `.openprd/design/templates/` 里最接近的一份模板；如果用户已经给了效果图、设计稿或参考图，先挑最接近它的 starter / lens / theme / layout；只有确实接近时才复用，不接近就允许偏离默认组合，以用户参考图为准。如果当前任务已经有一句明确页面主题和模块范围，优先直接运行 `openprd design-starter . --starter <starter-id> --out index.html --brief "<页面主题>" --sections "<模块1|模块2|模块3>"`。只有像个人博客、工具台、纯结构化产品页这类确认不靠真实图片成立的静态首页，才补 `--no-external-facts --no-brand-assets --no-real-images`，让 starter 同步写实 active design artifacts，并把 `docs/basic/`、入口文件说明书和根目录文件夹 README 一起补到可过 standards 的状态；如果题目更像旅游、导览、展览、博物馆、城市、自然观察、案例展示或品牌内容页，默认不要带 `--no-real-images`，先让 starter 尝试补首批真实图片。
+5. 下一步动作应该是一轮补丁，同时改 active design artifacts 和生成的入口文件；如果 `design-starter` 已经带 `--brief` 生成了第一版真实内容，就直接在生成的入口文件上细化结构、内容和样式，并立即进入 `Patch Mode`。`Patch Mode` 的意思是：入口路径已经固定，后续所有大改都在当前文件里完成；如果你觉得整页都要重写，也是在同一路径内覆盖，不做 delete-first。禁止删除 `index.html` 后另起新稿；即使结构要大改，也是在当前文件里重排，不要回头整份通读模板源码。如果你真的需要整页重写，先把完整新稿写到同目录 sibling draft，例如 `index.next.html`，确认内容成形后再覆盖回 `index.html`，不要让入口文件出现空窗。starter 一落地后，只允许做一轮就地对焦：快速读一次生成的入口文件和必要的 active design artifacts；这轮对焦结束后，下一步就必须是真实写入口，不要再回头搜网页、翻 `docs/basic/` 或继续模板漫游。把最后一批必要的查事实、查图、读模板动作放在口头宣布之前做完；一旦你已经口头宣布“开始覆盖入口文件”或“进入整页重写”，下一步必须是对 `index.html` 或 sibling draft 的实际写操作，不要继续长时间读模板、翻文档、压图片或停在口头承诺。只有规划、下载图片、补合同或口头说明还不算完成；必须把最终页面真的改到入口文件里。
+
+默认要求：
+
+- 对 blank static prototype，模板默认组合优先于“把所有 catalog 全读一遍再决定”；只有真的需要偏离模板默认组合时，才回头细读 `lenses / themes / layouts / components`。
+- 对 blank static prototype，优先使用 `openprd design-starter . --starter <starter-id> --out index.html`，把“挑模板”和“创建入口文件”变成确定动作，不要让 Agent 自己发明复制步骤。
+- 对 blank static prototype，如果 prompt 已经给了页面主题和模块范围，优先把它们带进 `design-starter` 的 `--brief` 与 `--sections`，让 starter 直接落真实首版，并顺手把基础文档和说明书从模板态拉成当前事实，而不是先生成整页占位再手工回填。
+- 对 blank static prototype，如果当前轮是用户直接给任务，优先让 `openprd run . --context --message <用户原话>` 参与当前请求解析，而不是只看空白工作区自身状态。
+- 如果用户已经给了效果图、设计稿、参考截图或其他明确参考图，默认把它当成这轮实现的主约束；只有现有 starter、theme、layout 足够接近时才复用它们，否则以参考图为准，不强行套库。
+- 对 blank static prototype，如果页面不依赖外部产品事实、品牌素材或真实图片，允许并建议在 active design artifacts 里直接写清：`无外部产品事实依赖`、`当前无品牌素材依赖`、`真实图片不是页面成立前提`；这类页面不该因为“没有更多证据可查”而一直停在 `待填写 / pending`。
+- 对旅游、导览、展览、博物馆、城市、自然观察、馆藏、案例展示这类页面，默认先把“真实图片大概率是页面成立前提”写进判断里；除非你已经有明确降级方案，否则不要顺手补 `--no-real-images`。
+- 跑完 `design-starter` 后，立即替换生成入口文件里的 `title`、首屏文案、CTA 和所有 `[占位]` 文案；除非真的需要额外结构，不要再回头整页阅读模板文件。
+- 跑完 `design-starter` 后，不要再重新判断“要不要删文件重写”；下一步默认就是进入 `Patch Mode`，至少同时修改 `index.html` 和必要的 active design artifacts；直接在生成的入口文件上改。禁止删除 `index.html` 后重起，也不要继续翻 theme / layout / template 源码来给自己找“再等等”的理由。
+- 跑完 `design-starter` 后，如果确实还需要确认当前骨架，只允许做一轮就地对焦：快速读一次生成的入口文件和必要的 active design artifacts；对焦结束后，下一步就必须是真实写入 `index.html` 或 sibling draft，不要再回头搜网页、翻 `docs/basic/` 或继续模板漫游。
+- 如果确实要做整页重写，默认先写 sibling draft，例如 `index.next.html` 或 `index.rewrite.html`，确认新稿已经成形后再覆盖回 `index.html`；不要先把当前入口删掉再慢慢补。
+- 把最后一批必要的查事实、查图、读模板动作放在口头宣布之前做完；一旦你已经说“现在开始覆盖入口文件”或“现在开始整页重写”，下一步必须出现真实写文件动作；优先直接修改 `index.html`，或先写 `index.next.html` / `index.rewrite.html`，不要继续只读浏览或长时间停住。
+- 如果用户已经给了效果图或设计稿，跑完 `design-starter` 后的第一目标不是“回到样式库重新想一版”，而是把参考图里的版式、信息层级、主视觉和关键路径真正映射到当前入口文件里。
+- active design artifacts 是空白工作区里第一批应该被写实的文件，不是实现后补填的附属记录。
+- 当你已经读完 design 框架和 active 模板后，不要继续反复扫描同一批模板文件；直接进入填写和实现。
+- 对静态单页原型，默认优先用单文件 HTML 模板起步；只有复杂交互或现有项目结构已经明确时，才拆成多文件。
+
+## Patch Mode
+
+- `design-starter` 一旦生成入口文件，这个路径就视为稳定基座；后续默认围绕它继续实现。
+- “重写页面”在这里的正确含义是“在同一路径内覆盖结构和内容”，不是先删除文件再慢慢补回来。
+- 如果用户已经给了效果图、设计稿、参考截图或其他明确参考图，这些参考图就是 `Patch Mode` 的主裁决源；现有样式库、starter 和 design tokens 只负责加速，不负责把页面带到另一种风格。
+- 一轮有效的 `Patch Mode` 至少同时收口入口文件和必要的 active design artifacts；如果事实、素材或图片还没准备好，先补这些，再继续改页面，不要把入口文件删空当成思考中间态。
+- 如果要整页重写，先写 sibling draft，再覆盖回正式入口；不要让 `index.html` 在重写过程中处于缺失状态。
+- `design-starter` 刚落地时，如果需要短暂对焦，只允许围绕生成的入口文件和 active design artifacts 做一轮快速确认；对焦之后就进入真实写入，不再回头搜网页、翻 `docs/basic/` 或继续模板漫游。
+- 一旦你已经宣布进入 `Patch Mode` 的覆盖阶段，下一步必须是实际写入 `index.html` 或 sibling draft；不能继续只做素材处理、重复阅读或停在“准备开始改”的状态。把“开始覆盖”这句话视为最后一跳承诺，不要太早说。
+- “Patch 已完成”的最低标准是：入口文件本体已经真正改完，主要占位或“待补”文案已去掉，已准备好的真实图片或参考约束已经映射进页面，相关 active design artifacts 也已同步。
+- 只做规划、下载素材、补合同、写说明或口头承诺“准备开始改”都不算 `Patch Mode` 完成。
+
+## 五个硬门
+
+### 1. Facts Before Assumptions
+
+- 涉及产品名、版本号、发布时间、规格、价格、引用数据、榜单、排名、地点或政策时，不要凭记忆写页面。
+- 先核实，再写入 `.openprd/design/active/facts-sheet.md`。
+- 核实不到就标成 `待确认`，而不是自己补一个像真的答案。
+
+### 2. Assets Before Decoration
+
+- 对品牌页、发布页、内容页、deck、招商页、展览页、产品页来说，logo、产品图、UI 图、图表素材、品牌色和字体都属于一等资产。
+- 先写 `.openprd/design/active/asset-spec.md`，再决定版式。
+- 不要把“先做个好看壳子”当成默认路径。
+
+### 3. Real Images Before Placeholder Harmony
+
+- 如果任务属于旅游、展览、内容、科普、发布、品牌故事、馆藏、案例展示等场景，先判断真实图片是不是内容成立的必要条件。
+- 必要时在 `.openprd/design/active/image-preflight.md` 记录：是否需要真实图、计划来源、风险和降级方案。
+- 页面还没有真实图片时，不要用大片灰块假装已经准备好了内容。
+
+### 4. Three Directions Must Be Heterogeneous
+
+- 没有明确参考图时，不要只出三张“有细微差异的同一种安全解”。
+- 3 个方向至少来自 3 类不同生成逻辑：
+  - `contrast`：刻意拉开气质、密度、明暗或叙事角度
+  - `reference-transfer`：从真实世界成熟范式迁移结构方法
+  - `design-lens`：基于某种明确设计哲学从头重构
+- 每个方向都要写清：为什么它和另外两版不同、适合什么场景、主要风险是什么。
+
+### 5. Theme Lock Before Build
+
+- 一旦方向已选，先锁定 `lens + theme + layout + component set`，再进入编码。
+- 不要在实现中途临时发明颜色、阴影、边角体系或组件结构。
+- 如果实现过程中发现现有 theme 或 layout 不够用，先补库，再继续写页面。
+
+## 前端审美框架
+
+这套框架不是“参考图收藏夹”，而是 Agent 可执行的设计骨架：
+
+- `lenses/`：这次站在哪种设计判断角度看页面
+- `themes/`：色彩、字体、密度、圆角、阴影、边框和留白规则
+- `layouts/`：页面骨架
+- `components/`：高频结构块
+- `recipes/`：按任务类型打包的默认方案
+- `checklists/`：实现前后自检
+- `assets/`：允许反复复用的背景、表面、图案和位图资产说明
+- `templates/`：可直接开工的页面模板，减少空白工作区从 0 到 1 的犹豫
+
+## 什么时候必须补 active artifacts
+
+- 写产品事实、版本事实或具体数据时：必须补 `facts-sheet.md`
+- 依赖品牌素材、产品图、界面图或图库时：必须补 `asset-spec.md`
+- 内容图是不是页面成立前提不明确时：必须补 `image-preflight.md`
+- 没有明确参考方向且要做新界面时：必须补 `direction-plan.md`
+- 用户已经选定方向并准备实现时：必须补 `selected-direction.md`
+
+## 和现有视觉流程怎么配合
+
+- 这份 skill 发生在实现前，用来约束“先决定怎么做”。
+- `imagegen` 仍然负责出候选效果图。
+- `openprd visual-prepare` 负责把整板、多对象或网格参考图整理成可实现的 reference-set。
+- `openprd visual-compare` 负责实现后的视觉证据，而不是替代这份设计前置判断。
+
+## 输出要求
+
+- 对用户说明方向时，用人话描述气质、信息组织、视觉重心和适用场景。
+- 对实现说明时，明确写出选中的 lens、theme、layout 和关键组件。
+- 若因素材缺失、事实未确认或方向未选定而暂不实现，要直说卡点在哪里。

package/skills/openprd-frontend-design/references/design-asset-contract.md

@@ -0,0 +1,34 @@
+# 设计资产合同
+
+## 目标
+
+让“做界面”先有事实源和资产源，而不是先堆样式。
+
+## 最小合同
+
+每个前端体验任务，先明确这几类信息是否存在：
+
+| 维度 | 需要什么 | 缺失时怎么办 |
+| --- | --- | --- |
+| 产品事实 | 产品名、版本、发布时间、关键规格、价格、引用数据 | 先写进 `facts-sheet.md`，未知就标 `待确认` |
+| 品牌资产 | logo、品牌色、字体、口号、icon 风格 | 先写进 `asset-spec.md`，没有就说明缺口 |
+| 内容资产 | 产品图、场景图、摄影图、插图、图表、馆藏图、案例图 | 先写进 `asset-spec.md` 或 `image-preflight.md` |
+| 参考资产 | 用户给的效果图、设计稿、参考截图、参考站点局部 | 先写进 `asset-spec.md` 或 `selected-direction.md`，并声明它是不是主参考源 |
+| 布局资产 | 这次要用的 layout skeleton | 从 `.openprd/design/layouts/` 选，不临场发明 |
+| 组件资产 | 这次要用的 hero、stat、feature-grid、timeline 等 | 优先用 `.openprd/design/components/` 里已有结构 |
+
+## 禁止行为
+
+- 没核实事实就直接写产品页。
+- 没拿到真实内容图却先做内容型页面的大面积版式。
+- 用户已经给了效果图，却还把样式库默认风格当成更高优先级。
+- 一边实现一边临时发明主题、组件和布局体系。
+
+## 完成标准
+
+- 事实写进 `facts-sheet.md`
+- 素材写进 `asset-spec.md`
+- 必要图片判断写进 `image-preflight.md`
+- 方向差异写进 `direction-plan.md`
+- 选中方向写进 `selected-direction.md`
+- 若已有用户参考图，要明确记录它是否是当前实现的主参考源

package/skills/openprd-frontend-design/references/direction-engine.md

@@ -0,0 +1,46 @@
+# 三方向引擎
+
+## 目标
+
+让 3 个候选方向真的来自不同思路，而不是安全解的三个轻微变体。
+
+## 前提
+
+- 如果用户已经给了确认效果图、设计稿或明确参考图，先不要强行再出 3 个方向；先吸收它的版式、层级、主视觉和关键路径。
+- 这时方向引擎的任务变成：找最接近该参考图的 starter / theme / layout 作为实现加速器；如果库里没有接近项，也允许偏离默认组合，以参考图为准。
+
+## 方向类型
+
+### 1. Contrast
+
+- 主动拉开明暗、密度、节奏、叙事方式或视觉温度。
+- 适合用户没有明确风格、但需要先看到差异时。
+
+### 2. Reference Transfer
+
+- 从真实世界成熟范式中迁移结构方法。
+- 借的是组织方式、信息优先级和节奏，不是照着抄外观。
+
+### 3. Design Lens
+
+- 先选一个明确的设计哲学，再从这个 lens 反推页面结构。
+- 例如工具密度优先、展陈叙事优先、产品发布优先、编辑排版优先。
+
+## 每个方向至少回答
+
+- 这个方向的视觉主张是什么
+- 它为什么和另外两版不一样
+- 它更适合什么任务和用户
+- 它最大的风险是什么
+
+## 不合格示例
+
+- 三版都只是浅色留白加不同插图
+- 三版都只是按钮颜色不同
+- 三版都共享同一布局和同一视觉重心，只是文案换序
+
+## 合格示例
+
+- 一版强调沉浸式主视觉和少量强信号
+- 一版强调编辑感和内容节奏
+- 一版强调密度、扫描效率和操作导向

package/skills/openprd-harness/SKILL.md

@@ -21,28 +21,40 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
    - `init/setup/update/doctor` 可能会在 `.openprd/harness/install-manifest.json` 的 `optionalCapabilities` 里记录 Context7、DeepWiki 等非阻断式增强建议。把它当成软提醒：初始化、诊断和当前任务都不因它失败；只有当前任务会明显受益时，才在后续建议里解释能力价值、附官方文档 / GitHub 链接，并视情况提出可代为补配置。
 4. 选择执行单元前，优先运行 `openprd run <path> --context`
 5. 把 `openprd run <path> --context` 当作建议，不要自动执行其中的写入命令
+   - 如果当前轮是空白工作区的前端/页面冷启动，而且用户已经明确给出页面主题、模块范围或“直接实现”的意图，优先改用 `openprd run <path> --context --message <用户原话>`，不要先跑不带 message 的 context
+   - 如果这类前端冷启动在带 message 后仍短暂返回 `clarify-user`，但用户原话已经足够明确，就把它当成 requirement 摘要级提醒；先用 3 到 5 行 mini-plan 收口，再按 `$openprd-frontend-design` 的 `design-starter -> Patch Mode` 路径继续，不要回到 `docs/basic/` 占位文档里打转
    - 同时查看推荐里的 `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、新功能/新流程方案=L2；默认把路由码并进“需求类型：快速修正（L0）”这类标签里，只有内部排障确实受益时才额外补“内部路由码”
+6. 需求复杂度先交给 `$openprd-requirement-intake` 分流；不要按固定关键词判断。它会根据影响面、未知数、决策成本和验证成本判断需求类型，并保留内部路由码对照：直接处理=L0、现有功能优化=L1、新功能/新流程方案=L2；默认把路由码并进“需求类型：直接处理（L0）”这类标签里，只有内部排障确实受益时才额外补“内部路由码”
    - 如果需求涉及界面、页面、视觉、样式或前端体验，先判断是否属于“大界面改动”：会改变信息架构、页面布局、主视觉、关键路径、核心组件密度/层级，或用户需要先选设计方向。大界面改动在需求分流后、进入实现或 PRD 定稿前，先走视觉方案评审。
+   - 任何界面、页面、视觉、样式或前端体验任务在进入实现前，都要额外读取 `$openprd-frontend-design`，并优先检查 `.openprd/design/active/` 下是否已经补齐 `facts-sheet / asset-spec / image-preflight / direction-plan / selected-direction`。
+   - 如果用户已经给了效果图、设计稿、参考截图或其他明确参考图，先把它视为主参考源；只有现有 starter、theme、layout 足够接近时才复用，不接近就允许偏离默认组合，不要为了套库把页面做成另一种样式。
+   - 如果 `design-starter` 之后需要整页重写，默认先写 sibling draft，再覆盖回 `index.html`；不要让入口文件在 rewrite 过程中出现空窗。
+   - `design-starter` 一旦落地，只允许做一轮就地对焦：快速读一次生成的入口文件和必要的 active design artifacts；这轮对焦结束后，下一步就必须是真实写入口，不要再回头搜网页、翻 `docs/basic/` 或继续模板漫游。
+   - 把最后一批必要的查事实、查图、读模板动作放在口头宣布之前做完；一旦已经说“开始覆盖入口文件”或“开始整页重写”，下一步必须出现真实写文件动作；不能继续只读浏览、长时间压图或停在口头承诺。
+   - 如果用户目标是把工作转成可学习、可复用、可回看、可教学或可沉淀的材料，先按期望产物形态判断是否需要 `$openprd-learning-review`：需要章节结构、证据锚点、图文讲解、检索练习、工作示例或长期阅读体验时，优先用 `openprd learn <path> --topic <主题>` 生成学习包骨架、阅读器和证据清单；不要用关键词表触发，普通 Markdown 只能作为辅助讲义。
 7. 如果用户是在规划、分析、架构评审，或问“怎么改”“会动哪些文件”，保持只读并基于证据回答
 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、先看样子或先确认设计方向时，默认直接调用 `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/`；查看合成图后继续复刻或自检，直到没有明显视觉差异或意外漂移
+11. 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup、先看样子或先确认设计方向时，默认直接调用 `imagegen`，也就是 Codex 原生 Image 2，产出图片；除非用户明确指定 HTML、SVG、CSS、Canvas、代码稿或可编辑矢量/source artifact，不要改用临时 HTML/SVG/CSS 再截图。OpenPrd 的 `review.html` 只用于需求评审，不能替代图片或效果图生成；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流。生图结果先当候选效果图，不要默认登记到 `.openprd/harness/visual-reviews/`；如果用户还要继续做实现，主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现
+12. 大界面改动进入实现前，先按用户目标、信息架构变化、视觉决策成本和验证风险判断是否需要视觉方案评审：已有界面时用 Codex Computer Use 进入产品内对应功能并截当前真实界面；冷启动没有现有界面时基于已确认 PRD、用户群体、第一版切片和视觉目标生成设计 brief；再调用 `imagegen`（Codex 原生 Image 2）至少生成 3 个不同设计思想方向；把效果图横向拼接成一张大图，左上角标注 1/2/3，先作为候选效果图展示；主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后才把选定方向、整张图或其中子图整理到 `.openprd/harness/visual-reviews/`，未确认前不要进入大 UI 实现
+   - 3 个方向不能只是同一种安全解的轻微变化。至少要在 `.openprd/design/active/direction-plan.md` 里区分不同生成逻辑、适用场景和主要风险。
+   - 一旦用户确认方向，先在 `.openprd/design/active/selected-direction.md` 锁定选中的 lens、theme、layout 和组件，再进入编码。
+13. 界面、页面、视觉、样式或前端体验任务中，如果已经有确认参考图、设计稿、图片资产、截图或用户给图且进入实现阶段，阶段性完成后先截实现图，再运行 `openprd visual-compare <path> --reference <效果图> --actual <实现截图>`。如果一张参考图里有多个子图、网格或对象，先运行 `openprd visual-prepare <path> --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>`，生成 reference-set、contact sheet 和 compare-plan，再逐项对比。如果没有明确参考图，先判断新建界面还是修改既有界面：新建界面回到实现前 3 方向方案评审，修改既有界面动手前先截修改前截图，完成后用同一入口、视口、账号和数据状态截修改后截图，再运行 `openprd visual-compare <path> --before <修改前截图> --after <修改后截图>`。需要审局部细节时，再补 `openprd visual-compare <path> --board <focus-board.json>`；如果局部变化需要放到同一张证据板里审阅，默认优先把局部变化组合成一张 `focus-board` 再统一验收；并行跑了多个优化方向时，再补 `openprd visual-compare <path> --board <parallel-board.json>`。默认输出 JPG 到 `.openprd/harness/visual-reviews/`；查看合成图后继续复刻或自检，直到没有明显视觉差异或意外漂移；如果用户后续说“跟效果图”“不一致”“好丑”“复刻”，至少先产出一份视觉证据图。对 `design-starter -> Patch Mode` 的静态首页而言，真正完成还包括：入口文件本体已经改完、主要占位已清掉、已准备好的真实图片或参考约束已经落进页面，不是只补合同或只下载素材。
 14. 实现任务新增或修改文件时，做文档影响检查：缺失的 `docs/basic/`、文件说明书、文件夹 README 要补齐；受影响的已有文档要更新；涉及后端、脚本、Agent、工具链、服务或数据处理变更时，把 CLI 与 API 视为同级接入面，更新 `docs/basic/backend-structure.md` 中的命令入口、输出契约、`help`/`doctor`/`dry-run`/`status`、接口协议与不适用说明
+   - 如果这轮实现补充了新的前端设计主题、布局骨架、组件 recipe 或 anti-slop 规则，同步更新 `.openprd/design/` 与 `docs/basic/frontend-guidelines.md`，不要只留在代码里。
 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`
+18. 用户要求界面更好看、更稳定、有一致审美、能复用视觉资产或内置模板时，先路由到 `$openprd-frontend-design`
+19. 用户要求基线文档、文件说明书、文件夹 README 标准或实现就绪检查时，路由到 `$openprd-standards`
+20. 用户要求日志、链路追踪、业务成本护栏、免费额度、滥用防护、评估执行环境、冒烟覆盖、性能基线、极端场景、HTML 质量评估报告或项目级经验 Skill 时，路由到 `$openprd-quality`
+21. 用户需要可视化说明，或系统/产品形态仍不清晰时，在进入需求定稿前路由到 `$openprd-diagram-review`
+22. 默认保持 Codex hooks 轻量。除非项目明确需要完整工具级遥测，否则 `openprd setup/update` 使用 `--hook-profile lite`；默认 `lite` 会保留 `Stop` 收工回顾，用于在本轮结束前提醒是否值得沉淀项目经验，并要求 Agent 用“本次情况 / 准备整理成的经验 / 以后如何复用 / 只保留在当前项目里”的结构化人话向用户确认
+23. hook 会强制阻断几类场景：需求入口未完成就写实现、外部证据不足就直接改第三方集成、skill/AGENTS 变更未先可视化确认、以及敏感信息场景下直接读原始 vault 文件
+24. 当 `doctor` 报告生成引导漂移时，读取 `.openprd/harness/drift-report.json`
 
 ## 主工作流
 
@@ -68,7 +80,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 信号回顾是否要生成项目经验草案，并要求 Agent 先用人话向用户确认是否保留到当前项目里
+  - 默认 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`
@@ -83,15 +95,16 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
   - 让 `.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...>`；需要关注的文件必须在最终回复里以 **后续建议** 表格说明影响位置、关注程度、规模信号、为什么需要关注、本次处理和后续建议，并按 🔴 → 🟠 → 🟡 排序
-  - 用户只是要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、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>` 输出并行实验证据板。未查看对比图、或对比图仍有明显差异/漂移时，不要声称界面视觉完成
+  - 用户只是要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup 或先看样子时，默认调用 `imagegen`（Codex 原生 Image 2）生成图片；除非用户明确指定 HTML/SVG/CSS/Canvas/代码稿，不要生成临时 HTML 再截图；未调用 `imagegen` 前，不要声称生图已完成、失败或限流。生图结果先当候选效果图，不要默认纳入验收
+  - 大界面改动不直接开工：先按用户目标、信息架构变化、视觉决策成本和验证风险判断方案评审形态；已有界面时用 Codex Computer Use 打开产品内对应功能并截图，冷启动没有现有界面时用已确认 PRD、用户群体、第一版切片和视觉目标生成设计 brief；再用 `imagegen`（Codex 原生 Image 2）生成至少 3 个设计方向，横向拼接成一张带 1/2/3 序号的大图作为候选效果图给用户确认；主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后，再把它作为实现参考图进入后续任务
+  - 如果已有确认参考效果图、图片资产、设计稿、截图或用户给图并进入实现阶段，阶段性完成后必须生成实现截图，并用 `openprd visual-compare <path> --reference <效果图> --actual <实现截图>` 输出 JPG 视觉对比图；如果参考图里有多个子图、网格或对象，先运行 `openprd visual-prepare <path> --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>`，检查 contact sheet 后按 compare-plan 逐项对比；如果局部细节更重要，再补 `--board <focus-board.json>` 输出局部焦点证据板；如果没有明确参考图，先判断新建界面还是修改既有界面：新建界面先完成 3 方向方案评审，修改既有界面动手前先生成修改前截图，完成后生成修改后截图，并用 `openprd visual-compare <path> --before <修改前截图> --after <修改后截图>` 输出 JPG 自检图；如果并行试了多个优化方向，再补 `--board <parallel-board.json>` 输出并行实验证据板。未查看对比图、或对比图仍有明显差异/漂移时，不要声称界面视觉完成；如果用户后续说“跟效果图”“不一致”“好丑”“复刻”，至少先产出一份视觉证据图
   - `openprd loop <path> --finish` 前，先完成文档影响检查并更新缺失或过期的 `docs/basic/`、文件说明书和文件夹 README；涉及后端、脚本、Agent、工具链、服务或数据处理变更时，同步评估 CLI 与 API 两个接入面
   - 声称单个任务完成前，只运行本任务最小足够验证，并通过 `--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/`，把它们视作任务交付物的一部分
+  - 如果本轮准备宣称“整体完成”或“项目级完成”，但还没有最终 `openprd quality <path> --verify`、最终 `openprd run <path> --verify`，或 `.openprd/harness/test-reports/` 下的 Markdown / HTML 测试报告，就只能如实说“局部实现或代码修改已完成，项目级收口仍待补齐”，不要把缺少最终验证的状态表述成已经闭环
   - 每个 loop 任务都对应一个全新 Codex 或 Claude 会话边界，不要在同一会话里继续下一项任务
 - 处理历史项目集群前先审计：
   - `openprd fleet <root> --dry-run`
@@ -107,7 +120,9 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 - 当关键产品事实缺失时，先查看 `intake-reflection.md` 的需求入口自省，再把压缩后的必须确认问题问给用户
 - 当需求模糊、起点只有一句想法，或需要先做方案探索时，先查看生成的 `intake-reflection.md`，先把用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针整理成首轮项目画像，再把压缩后的目标、范围、非目标、验收方式和必须确认问题放在对话里请用户确认；不要生成或打开澄清 HTML
 - Agent 在对话里先用业务和产品语言复述：这次主要给谁、什么场景、先解决什么、先不碰什么、不能影响什么、会带来哪些业务风险。默认先追问 1 个最高价值问题，而不是一次性抛一整墙技术问题。
+- `需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清结论：这次是什么、核心问题在哪里、第一版先做到什么；边界、风险、异常例子和技术细节下沉到后续分项或表格，不要揉成一大段重话。
 - 如果当前还是 L2 的首轮澄清或 requirement 摘要确认阶段，只能承诺“我先整理需求摘要给你确认，确认后再进入 PRD / review 流程”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现压成一步。
+- 如果 `openprd run . --context` 仍然建议 `clarify-user`，这轮回复的目标就只能是 `需求摘要` 或 `1 个最高价值澄清点`；不要写“我先按默认方案实现”或类似承诺。
 - `面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景` 不是只给后面 PRD 用的模板方向；澄清阶段就要前移场景视角。面向个人消费者场景更看首次场景、用户感受和回访动力；面向企业服务场景更看拍板方、使用方、推进方和上线阻力；Agent 场景更看自主边界、人工兜底和失败恢复。
 - 当用户一开始不想讲太细时，可以先给 2 到 3 个方向和取舍供用户选，不要逼用户先回答完整 schema。
 - 优先分阶段确认：问题、用户、范围、成功标准和开放问题；复杂需求先让 OpenPrD 内部完成意图归一化、项目上下文映射和产品质量自检，不要把固定问题墙一次性砸给用户
@@ -144,10 +159,11 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
   - 流程 / 旅程确认
   - 需求定稿前的可视化评审
 - 当需求属于大界面改动时，在 PRD 定稿或实现开工前先走“视觉方案评审”：
-  - 用 Codex Computer Use 进入产品内对应功能，截取当前真实界面
-  - 用 `imagegen`（Codex 原生 Image 2）基于该截图做图生图，至少产出 3 个不同设计思想方向
-  - 将 3 张效果图横向拼接为一张大图，每张左上角标注 1/2/3，并保存到 `.openprd/harness/visual-reviews/`
-  - 展示给用户评审确认；未确认方向前，不进入大 UI 实现或声称方案已定
+  - 已有界面时用 Codex Computer Use 进入产品内对应功能，截取当前真实界面；冷启动没有现有界面时，基于已确认 PRD、用户群体、第一版切片和视觉目标生成设计 brief
+  - 用 `imagegen`（Codex 原生 Image 2）基于截图或设计 brief 至少产出 3 个不同设计思想方向
+  - 将 3 张效果图横向拼接为一张大图，每张左上角标注 1/2/3，先作为候选效果图展示给用户
+  - 主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后才把选定方向、整张图或其中子图整理到 `.openprd/harness/visual-reviews/`
+  - 未确认方向前，不进入大 UI 实现或声称方案已定
 
 ### 7. 只在草稿准备好时 freeze
 
@@ -181,8 +197,9 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 - 当 agent 环境可能没有正确跟随 OpenPrd 时，优先用 `openprd doctor`
 - 生成 adapter 文件漂移时，优先运行 `openprd update` 修复，而不是手改生成文件
 - 当方案形态仍不清晰时，优先先 review 再进入需求定稿
-- 当界面改动比较大、用户需要先选方向、或页面信息架构/主视觉会明显变化时，优先先做 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>`，共同作为视觉就绪判断依据
+- 当界面改动比较大、用户需要先选方向、或页面信息架构/主视觉会明显变化时，优先先做 3 方向候选效果图评审，再进入实现
+- 当用户目标是把本次工作转成可学习、可复用、可回看、可教学或可沉淀的材料时，先按期望产物是否需要章节结构、证据锚点、图文讲解、检索练习、工作示例或长期阅读体验来判断；需要时优先调用 `openprd learn .` 生成学习包和阅读器，不要用关键词表触发，普通 Markdown 只能作为辅助讲义
+- 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup 或先看样子时，优先调用 `imagegen`（Codex 原生 Image 2）；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流。生图结果先当候选效果图，并主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现。界面任务进入实现阶段时，已有确认参考图用 `openprd visual-compare --reference/--actual` 生成左右对比 JPG；如果参考图是一张整板、网格图或多对象组合，先运行 `openprd visual-prepare --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>` 整理 reference-set，再逐项对比；没有参考图时先判断新建界面还是修改既有界面，新建界面先完成 3 方向方案评审，修改既有界面用 `openprd visual-compare --before/--after` 生成修改前后自检 JPG；局部细节优先补 `--board <focus-board.json>`，并行优化方向优先补 `--board <parallel-board.json>`，共同作为视觉就绪判断依据。用户后续如果说“跟效果图”“不一致”“好丑”“复刻”，至少先产出一份视觉证据图
 - 遇到 blocker 时，优先把阻塞条件显式暴露出来，而不是悄悄补脑
 
 ## 禁止行为

package/skills/openprd-learning-review/SKILL.md

@@ -7,9 +7,10 @@ description: 生成并维护 OpenPrd 复盘学习包、题材参考库、证据
 
 ## 何时使用
 
-当用户希望把 OpenPrd 工作区、已完成的 loop 任务，或某个项目领域整理成复盘学习包时，使用这份 skill。典型触发包括：
+当用户希望把 OpenPrd 工作区、已完成的 loop 任务，或某个项目领域整理成复盘学习包时，使用这份 skill。不要用关键词表触发；先看用户目标和期望产物形态。
 
 - 长任务结束，或某个已验证 loop 任务刚完成
+- 当前交付需要章节结构、证据锚点、图文讲解、检索练习、工作示例或长期阅读体验；这类形态默认优先走学习包和阅读器，不要只交一篇普通 Markdown
 - 用户明确要求复盘某个项目领域或能力面
 - 需要构建或刷新题材模板、证据清单、检索模块或工作示例
 - 需要生成归档在 `.openprd/` 内的 HTML 电子书阅读器

package/skills/openprd-learning-review/references/style-packs/xianxia-cultivation.prompt.md

@@ -21,7 +21,7 @@
 
 输出：一个像书名的标题和一个短副题。
 
-要求：标题可带“札记/小卷/归藏/心法”等书籍意象，但必须保留 topic 的核心名词。
+要求：标题可带“札记/小卷/藏录/心法”等书籍意象，但必须保留 topic 的核心名词。
 
 ## Outline Prompt
 

package/skills/openprd-quality/SKILL.md

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

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

@@ -19,16 +19,30 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 
 不要按关键词判断。按影响面、未知数、决策成本和验证成本判断。
 
+如果用户明确说“帮我梳理下”“先想清楚”“进入脑暴模式”，或需求只有一句话但明显需要先收敛业务方向、用户、商业目标、竞品和复用能力，必须先进入脑暴模式，不要直接压进 PRD，也不要先拿一版 requirement 摘要代替脑暴产物。默认使用：
+
+- `openprd brainstorm . --topic <当前主题> --open`
+- 如需让 Agent 先提炼展示文案，再补 `openprd brainstorm-presentation . --template`
+
+脑暴模式是独立 lane，不等于普通 clarify：
+
+- 目的不是只补字段，而是先判断值不值得做、给谁做、为什么现在做、有哪些方向、当前工作区能复用什么。
+- 每轮至少要把这几类关键点补齐：第一批最容易触达的社区或人群、现在怎么解决、为什么现在想换、如果先不做完整产品怎么手工交付、什么真实承诺最能证明不是口头兴趣、先怎么低成本验证、验证阶段怎样先活下来、什么情况下先停。
+- 资料来源默认同时包含 benchmark、knowledge、当前工作区文档/代码和开放问题。
+- 如果用户能提供更大的工作区或历史项目目录，优先一起扫描可复用能力、旧流程和已有产品做法。
+- 用户没有明确要求时，Agent 只能“建议进入脑暴模式”，不能静默切换。
+- 用户认可脑暴方向后，再回到 `capture -> classify -> synthesize -> review -> change -> tasks`。
+
 | 用户可见需求类型 | 内部路由码 | 判断含义 | 默认处理方式 |
 |---|---|---|---|
-| 快速修正 | L0 | 单点、低风险、可逆、验收清楚 | 可以直接处理并事后说明 |
+| 直接处理 | L0 | 单点、低风险、可逆、验收清楚 | 可以直接处理并事后说明 |
 | 现有功能优化 | L1 | 目标明确，但影响多个文件、状态或用户可见行为 | 先给对话内 mini-plan，再执行 |
 | 新功能/新流程方案 | L2 | 新产品、模块、入口、流程、权限、计费、账号、AI/第三方、云服务、数据迁移、跨系统、长期工作流，或目标/验收/影响面不清 | 先走 PRD/review/change/tasks |
 
-用户审查时优先把路由码并进“需求类型：快速修正（L0）”这类标签里，不要把内部调度码单独抬成标题。只有审查或调试真的受益时，才额外补“内部路由码：L1”这类信息，并保留上面的对照关系。
+用户审查时优先把路由码并进“需求类型：直接处理（L0）”这类标签里，不要把内部调度码单独抬成标题。只有审查或调试真的受益时，才额外补“内部路由码：L1”这类信息，并保留上面的对照关系。
 用户侧表达优先使用“面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景”这类自然语言，不要把 `consumer`、`b2b`、`agent` 直接当展示词抛给用户。
 
-界面、页面、视觉、样式或前端体验需求需要额外判断 UI 影响面。若会明显改变信息架构、核心布局、主视觉、关键路径、组件层级/密度，或用户需要先选择设计方向，即使属于“现有功能优化”，也要先走“大界面改动视觉方案评审”：Computer Use 截取当前产品内功能截图，`imagegen`（Codex 原生 Image 2）基于截图生成至少 3 个方向，横向拼接带 1/2/3 序号的大图给用户确认。
+界面、页面、视觉、样式或前端体验需求需要额外判断 UI 影响面。若会明显改变信息架构、核心布局、主视觉、关键路径、组件层级/密度，或用户需要先选择设计方向，即使属于“现有功能优化”，也要先走“大界面改动视觉方案评审”：已有界面时用 Computer Use 截取当前产品内功能截图，冷启动没有现有界面时基于已确认 PRD、用户群体、第一版切片和视觉目标生成设计 brief；再用 `imagegen`（Codex 原生 Image 2）生成至少 3 个方向，横向拼接带 1/2/3 序号的大图给用户确认。
 
 如果同一句话同时包含“继续旧任务”和“新增范围”，先判断新增范围是否超出旧 PRD。超出时必须回到需求入口，更新 PRD/change/tasks，不能把“继续”当作实现授权。
 
@@ -39,9 +53,11 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 3. 如果是 L2，读取 `references/prd-template-lenses.md` 选择 PRD 场景视角。
 4. 输出一个短的需求类型判断：
    - 先总后分，优先按下面结构在对话里给用户看：
-   - 需求判断：需求类型（默认写成 `快速修正（L0）` / `现有功能优化（L1）` / `新功能/新流程方案（L2）`）/ 产品类型 / 推荐下一步
+   - 需求判断：需求类型（默认写成 `直接处理（L0）` / `现有功能优化（L1）` / `新功能/新流程方案（L2）`）/ 产品类型 / 推荐下一步
    - 只有内部排障真的受益时，才额外补一行“内部路由码”
    - 需求理解：主要服务对象 / 使用场景 / 第一版先做什么 / 这轮先不做什么 / 必须守住什么
+   - `需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清“这次是什么 / 核心问题是什么 / 第一版先做到什么”；能一句话说清就不要写两句话。范围边界、风险边界、异常例子和技术细节下沉到后面的分项或表格，不要全塞进同一整段长话里。
+   - 这里沉淀的是表达风格，不是固定示例文案；要根据本次内容自适应生成，不要机械套同一句模板。
    - 功能范围：优先用 Markdown 表格写 `功能模块 | 这次先做什么 | 这次先不做什么`
    - 技术方案：优先用 Markdown 表格写 `技术部分 | 初步方案 | 主要负责什么`；涉及前端、后端、Agent、数据或集成时，按用户能看懂的功能视角拆开
    - L2 时补充 PRD 场景视角：通用场景 / 面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景
@@ -66,9 +82,14 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 
 ### L2
 
-- 先运行或建议 `openprd clarify .`。
+- 如果用户明确要梳理、先想清楚、进入脑暴模式，或这句话明显还需要先收敛业务方向，先运行或建议 `openprd brainstorm . --topic <当前主题> --open`，不要只在对话里先给一版 requirement 摘要代替脑暴模式。
+- 进入脑暴模式后，Agent 默认先用“创业验证透镜”追问和收口：第一批可触达社区/种子用户、当前替代方案、手工交付路径、承诺信号、最低成本验证、default alive 约束，再补核心诉求、推荐方向、关键角色和复用基础。
+- 进入脑暴模式后，至少要形成 `brainstorm.html` 这类可继续评审和推进的产物，再基于产物追问或收口。
+- 其他 L2 默认先运行或建议 `openprd clarify .`。
 - 先建立首轮项目画像：用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针。
+- 对话内 requirement 摘要除了常规的用户、范围、风险，还要主动抬出“第一批最容易先找谁验证、用户现在怎么解决、先怎么手工交付、什么承诺才算真需求、最低成本先验证什么、验证阶段怎样先活下来”。
 - 再用对话内结构化摘要确认需求，默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”的顺序来写，其中“功能范围”和“技术方案”优先用 Markdown 表格。
+- `需求判断` 和 `需求理解` 先轻后重：先用轻量主句给用户一个一眼能懂的结论，再把边界、风险和技术细项下沉到后续表格或分项里；不要把它们揉成一大段说明。
 - 优先由 Agent 先归纳，再请用户确认；默认先问 1 个最高价值问题，必要时再给 2 到 3 个方向和取舍供用户选，不要一次砸一整墙问题。
 - 当前还是 L2 的首轮澄清或 requirement 摘要确认阶段时，只能承诺“我先整理需求摘要给你确认”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现压成一句话。
 - 单纯的“请帮我实现/继续实现”只表示用户希望最终落地，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。
@@ -90,3 +111,4 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 
 - 分流有争议、用户输入很长、或涉及“继续旧任务 + 新范围”时，读 `references/routing-rubric.md`。
 - 需要写 PRD、选择产品场景、或用户反馈 PRD 结构奇怪时，读 `references/prd-template-lenses.md`。
+- 需要把 L2 或脑暴收口成更强的创业验证链时，读 `references/startup-validation-lens.md`。