@openprd/cli 0.1.10 → 0.1.11

package/.openprd/benchmarks/index.md

@@ -9,6 +9,22 @@
 
 ## Approved Sources
 
+### slavingia/skills `github-com-slavingia-skills`
+
+- 状态: approved
+- 来源类型: github
+- 场景: skill-design
+- 触发: 设计 skill 触发、metadata、安装方式、自动识别或项目级覆盖规则
+- 不适用: 普通 PRD / 产品流程设计；与 CLI 无关的一次性 UI 视觉问题；单次脚本报错或纯环境权限问题
+- 研究方式: deepwiki_then_github
+- 来源: https://github.com/slavingia/skills
+- 规范化信源: github.com/slavingia/skills
+- 最近 7 天采纳: 2
+- 累计采纳: 2
+- 最近采纳时间: 2026-06-09 12:58:27
+- 备注: DeepWiki read_wiki_structure + ask_question showed a reusable community -> workaround -> manual-first -> commitment -> productize -> default-alive framework for L2 requirement validation and brainstorm.
+- 价值: DeepWiki read_wiki_structure + ask_question showed a reusable community -> workaround -> manual-first -> commitment -> productize -> default-alive framework for L2 requirement validation and brainstorm.
+
 ### milvus.io/ai-code-review-gets-better-when-models-debate-claude-vs-gemini-vs-codex-vs-qwen-vs-minimax.md `milvus-io-ai-code-review-gets-better-when-models-debate-claude-vs-gemini-vs-code`
 
 - 状态: approved
@@ -41,18 +57,4 @@
 
 ## Candidate Sources
 
-### slavingia/skills `github-com-slavingia-skills`
-
-- 状态: candidate
-- 来源类型: github
-- 场景: skill-design
-- 触发: 设计 skill 触发、metadata、安装方式、自动识别或项目级覆盖规则
-- 不适用: 普通 PRD / 产品流程设计；与 CLI 无关的一次性 UI 视觉问题；单次脚本报错或纯环境权限问题
-- 研究方式: deepwiki_then_github
-- 来源: https://github.com/slavingia/skills
-- 规范化信源: github.com/slavingia/skills
-- 最近 7 天采纳: 1
-- 累计采纳: 1
-- 最近采纳时间: 2026-06-09 11:21:58
-- 备注: DeepWiki read_wiki_structure + ask_question showed a reusable community -> workaround -> manual-first -> commitment -> productize -> default-alive framework for L2 requirement validation and brainstorm.
-- 价值: DeepWiki read_wiki_structure + ask_question showed a reusable community -> workaround -> manual-first -> commitment -> productize -> default-alive framework for L2 requirement validation and brainstorm.
+- 暂无待确认来源。

package/.openprd/benchmarks/sources.yaml

@@ -1,7 +1,59 @@
 version: 1
 schema: openprd.benchmarks.v1
-updatedAt: 2026-06-01 11:56:05
+updatedAt: 2026-06-09 12:58:27
 sources:
+  - id: github-com-slavingia-skills
+    title: slavingia/skills
+    scope: project
+    status: approved
+    sourceType: github
+    sourceKey: github.com/slavingia/skills
+    url: https://github.com/slavingia/skills
+    path: null
+    repo: slavingia/skills
+    researchMethod: deepwiki_then_github
+    scenarios:
+      - skill-design
+    triggerWhen:
+      - 设计 skill 触发、metadata、安装方式、自动识别或项目级覆盖规则
+    notFor:
+      - 普通 PRD / 产品流程设计
+      - 与 CLI 无关的一次性 UI 视觉问题
+      - 单次脚本报错或纯环境权限问题
+    note: DeepWiki read_wiki_structure + ask_question showed a reusable community -> workaround ->
+      manual-first -> commitment -> productize -> default-alive framework for L2 requirement
+      validation and brainstorm.
+    value: DeepWiki read_wiki_structure + ask_question showed a reusable community -> workaround ->
+      manual-first -> commitment -> productize -> default-alive framework for L2 requirement
+      validation and brainstorm.
+    adoptedCount: 2
+    lastUsedAt: 2026-06-09 12:58:27
+    evidence:
+      - observedAt: 2026-06-09 11:21:58
+        task: null
+        reason: DeepWiki read_wiki_structure + ask_question showed a reusable community -> workaround ->
+          manual-first -> commitment -> productize -> default-alive framework for L2 requirement
+          validation and brainstorm.
+        adoptedSignal: user-adopted
+        source: https://github.com/slavingia/skills
+      - observedAt: 2026-06-09 12:58:27
+        task: null
+        reason: "DeepWiki structure + targeted questions completed on 2026-06-09; key extracted principles:
+          community-first, 10 specific people, current workaround as competition, processize before
+          productize, spreadsheet/no-code first, 10+ paying before automation, 100 paying before
+          launch, spend time before money."
+        adoptedSignal: user-adopted
+        source: https://github.com/slavingia/skills
+    recentAdoptedCount: 2
+    promotion:
+      threshold: 3
+      windowDays: 7
+      recommended: false
+      recommendedAt: null
+      approveCommand: null
+    addedAt: 2026-06-09 11:21:58
+    approvedAt: 2026-06-09 12:01:15
+    lastVerified: null
   - id: milvus-io-ai-code-review-gets-better-when-models-debate-claude-vs-gemini-vs-code
     title: milvus.io/ai-code-review-gets-better-when-models-debate-claude-vs-gemini-vs-codex-vs-qwen-vs-minimax.md
     scope: project

package/.openprd/schema/prd.schema.yaml

@@ -31,11 +31,26 @@ sections:
     requiredFields:
       - community
       - seedUsers
+      - communityFit
       - currentAlternative
+      - painEvidence
       - manualPath
+      - manualPlaybook
       - commitmentSignals
       - firstValidationStep
       - defaultAlivePlan
+      - paymentProof
+      - mvpSlice
+      - weekendTest
+      - smallestExecution
+      - productizeGate
+      - firstCustomerPath
+      - pricingHypothesis
+      - customerOneProfitability
+      - growthDiscipline
+      - reversibility
+      - customerTruth
+      - valuesFit
 
   scope:
     requiredFields:

package/.openprd/templates/base/intake.md

@@ -7,11 +7,24 @@
 - 我们要解决什么问题？
 - 主要是给谁用的？他们会在什么场景下最先感受到价值？如果你愿意，也可以直接说它更偏面向个人消费者、面向企业服务，还是以 Agent 为主。
 - 第一批最容易触达、最可能愿意给真实反馈的社区、渠道或人群是谁？
+- 你为什么算这个社区里的“自己人”？他们平时主要在哪里聚集、为什么你现在就能触达？这是不是一个足够小、足够集中的切口？
 - 第一版最小可用切片，最希望先让用户完成什么关键动作？
 - 当前临时解决方式是什么？
+- 这个问题到底有多痛？用户现在是不是已经在为更差的办法花时间、花钱，或者至少在强行 workaround？如果一句话描述客户和痛点，会怎么说？
 - 如果先不做完整产品，能不能先靠手工服务、半自动流程或轻量交付把价值跑出来？
+- 如果先手工交付，这份“手工作战卡”该怎么写：触发条件、关键步骤、用什么工具、单客大概花多久、谁来接力？
+- 如果今天禁止你写复杂代码，只能用 spreadsheet、表单、Zapier/Notion/Airtable 这类现成工具，你会怎么把第一版跑起来？哪些东西现在明确先不 build？如果已经不得不做产品，也只自动化最重复的一步，先压成 forms / lists / CRUD 这种最轻骨架。
+- 第一版到底只做哪一件事？它能不能被压成一个周末级 MVP、一个顾问式试跑，或一个更轻的验证动作？
+- 你现在至少能不能点出 3 到 10 个具体的人、团队或客户样本？如果已经聊过，里面有多少人真的愿意付费、预约试跑、导入真实数据，或者给出同等级别的承诺？
+- 第一批客户最现实的触达顺序是什么？先熟人、现有客户、社区，还是陌生线索？
+- 从第一个客户开始准备怎么收费？什么价格既是 no-brainer，又不会因为免费而失真？
 - 什么真实承诺最能证明这不是口头兴趣，比如付费、预约、提交真实素材、拉人进群或导入数据？
 - 最低成本先验证哪一步最关键？如果验证结果一般，什么情况下应该先停，或者先换更轻的方式继续？
+- 如果只拿到第一个客户，这条路怎么打平时间和交付成本？更接近 default alive 还是 default dead？
+- 你准备在什么条件下才允许自己“产品化”或继续加功能？例如已经服务了 10+ 付费客户、需求已经稳定几周、手工步骤几乎不再变化。一旦真的开始做产品，默认也只自动化一小步，不直接做大平台。
+- 销售和增长这条线准备怎么守纪律？是不是先熟人、再社区、再陌生线索；100 个付费客户前不把 launch 当获客策略；先花时间别先花钱；有自然增长前不急着投广告或招人。
+- 如果结果一般，这个方向有多可逆？更像是在解决客户真问题，还是在满足我们自己的技术冲动？
+- 这条路是否符合团队现在想坚持的价值观和做事方式？如果连续这样做 3 到 5 年，你还愿意住在这套业务里吗？
 - 哪些内容这轮先不做？
 - 哪些既有能力、流程、体验或业务结果不能被破坏？
 - 成功后，用户会明显感受到什么变化？我们怎么判断它值得做成？

package/.openprd/templates/base/prd.md

@@ -31,11 +31,26 @@
 
 - 可触达社区:
 - 第一批种子用户:
+- 社区契合与触达依据:
 - 当前替代方案:
+- 痛点与替代证据:
 - 手工交付路径:
+- 手工作战卡:
 - 承诺信号:
 - 首个低成本验证:
 - 先活下来方案:
+- 付费验证信号:
+- 第一版只做一件事:
+- 周末级验证:
+- 最小工具桥接:
+- 产品化门槛:
+- 第一批客户路径:
+- 初始收费假设:
+- 客户 1 盈利路径:
+- 销售与增长纪律:
+- 可逆性判断:
+- 客户真问题校验:
+- 价值观一致性:
 
 ## 6. 范围与非目标
 

package/AGENTS.md

@@ -25,7 +25,7 @@
 
 1. 动手前先从 `.openprd/` 重建状态，并先运行 `openprd run . --context`；它是建议上下文，不是自动执行指令。
 2. 规划、分析、架构评审、“怎么改”或“会动哪些文件”类请求保持只读；只有用户明确要求实现、继续任务、深度调研、对标复刻或提交时才进入执行。
-3. 先分流再执行：`openprd-requirement-intake` 按影响面、未知数、决策成本和验证成本判断需求类型，并保留内部路由码对照：直接处理=L0，现有功能优化=L1，新功能/新流程方案=L2。用户审查默认把路由码并进“需求类型：直接处理（L0）”这类标签里；只有内部排障确实受益时，才额外附“内部路由码”。直接处理类需求可直接处理并事后说明，不打开正式 PRD/review/change/tasks；现有功能优化先在对话内给 mini-plan 再执行，默认不生成正式 PRD/change/tasks；如果用户刚刚已经确认了 L1 mini-plan、范围边界或正式产品边界，后续承接要写成“已确认，我按这个继续”，不要用“确认，我们就按这个……”这类像再次索取确认的句子。只有新功能/新流程方案才先走 requirement intake、对话内 requirement 摘要确认，再 `review/change/tasks`，最后才实现。L2 的 requirement 摘要默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”来写，其中“功能范围”和“技术方案”优先用 Markdown 表格，帮助用户一眼看清；`需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清这次是什么、核心问题和第一版目标，边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们都塞进一整段长话里，也不要把某条示例文案写成固定模板。若当前仍在 0 到 1 探索、脑暴或值不值得做的判断，摘要里还要主动补上“验证与创业闭环”：第一批最容易触达的社区或种子用户、当前替代方案、先怎么手工交付、什么承诺才算真需求、最低成本先验证什么，以及验证阶段怎样先活下来。L2 的首轮澄清只能承诺“我先整理需求摘要给你确认”，不能把 requirement 摘要确认、review 和实现压成一句“你回我一句我就开始实现”。如果 `openprd run . --context` 仍然建议 `clarify-user`，当前这轮回复的目标就只能是 `需求摘要` 或 `1 个最高价值澄清点`，不要写成“我先按默认方案实现”。如果用户的下一条回复只是承接上一轮 requirement 摘要的短跟进，而不是提出新范围、改目标或重新发起分析请求，就把它当成对上一轮摘要、默认方向或选项的继续确认，不要重新开一轮泛化 clarify；应直接按当前对话上下文把已确认事实用 canonical capture 路径、`user-confirmed` 来源写回，而不是继续写 `agent-inferred/project-derived` 的用户澄清字段。单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。`review.html` 是稳定评审 artifact，不再默认等于唯一的人类停顿点；默认按 decision-points approval policy 执行，只有当前 lane 仍要求人类决策时才在 final answer 主体里停下请求确认；当 review 已确认且 tasks 已就绪但还需要执行授权时，先给执行确认清单再请用户确认。
+3. 先分流再执行：`openprd-requirement-intake` 按影响面、未知数、决策成本和验证成本判断需求类型，并保留内部路由码对照：直接处理=L0，现有功能优化=L1，新功能/新流程方案=L2。用户审查默认把路由码并进“需求类型：直接处理（L0）”这类标签里；只有内部排障确实受益时，才额外附“内部路由码”。直接处理类需求可直接处理并事后说明，不打开正式 PRD/review/change/tasks；现有功能优化先在对话内给 mini-plan 再执行，默认不生成正式 PRD/change/tasks；如果用户刚刚已经确认了 L1 mini-plan、范围边界或正式产品边界，后续承接要写成“已确认，我按这个继续”，不要用“确认，我们就按这个……”这类像再次索取确认的句子。只有新功能/新流程方案才先走 requirement intake、对话内 requirement 摘要确认，再 `review/change/tasks`，最后才实现。L2 的 requirement 摘要默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”来写，其中“功能范围”和“技术方案”优先用 Markdown 表格，帮助用户一眼看清；`需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清这次是什么、核心问题和第一版目标，边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们都塞进一整段长话里，也不要把某条示例文案写成固定模板。若当前仍在 0 到 1 探索、脑暴或值不值得做的判断，摘要里还要主动补上“验证与创业闭环”：第一批最容易触达的社区或种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先怎么手工交付、手工作战卡怎么写、能不能先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一版只做哪一件事、能不能压成周末级 MVP、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律、这条路是否可逆、是否真在解决客户问题、以及是否符合团队价值观、是不是你愿意长期住进去的业务形态。L2 的首轮澄清只能承诺“我先整理需求摘要给你确认”，不能把 requirement 摘要确认、review 和实现压成一句“你回我一句我就开始实现”。如果 `openprd run . --context` 仍然建议 `clarify-user`，当前这轮回复的目标就只能是 `需求摘要` 或 `1 个最高价值澄清点`，不要写成“我先按默认方案实现”。如果用户的下一条回复只是承接上一轮 requirement 摘要的短跟进，而不是提出新范围、改目标或重新发起分析请求，就把它当成对上一轮摘要、默认方向或选项的继续确认，不要重新开一轮泛化 clarify；应直接按当前对话上下文把已确认事实用 canonical capture 路径、`user-confirmed` 来源写回，而不是继续写 `agent-inferred/project-derived` 的用户澄清字段。单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。`review.html` 是稳定评审 artifact，不再默认等于唯一的人类停顿点；默认按 decision-points approval policy 执行，只有当前 lane 仍要求人类决策时才在 final answer 主体里停下请求确认；当 review 已确认且 tasks 已就绪但还需要执行授权时，先给执行确认清单再请用户确认。
 4. change/tasks 就绪后，用 `openprd-test-strategy` 按风险选择单元、集成、端到端、人工、视觉、小程序、性能或安全验证组合，并在任务或报告中保留 evidence-plan；同时根据任务边界记录 execution strategy：小范围修正保持 `serial`，中等规模 L1/L2 可推荐 `parallel-workers`，高风险或大规模实现再升级到 `parallel-workers-isolated`；70/20/10 只作健康形状参考，不作硬门禁。
 5. 纯图片、封面图、配图、海报、插画、图标、贴纸、mockup 或“先看样子”请求默认直接使用 `imagegen`，也就是 Codex 原生 Image 2；其中 logo、icon、avatar、badge 等开发素材在用户未明确要求场景化展示时，默认按独立素材输出（standalone asset）生成：全画布单主体，不额外添加卡片、设备框或其他展示容器；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流。生图结果先当候选效果图，不要默认登记到 `.openprd/harness/visual-reviews/`。Agent 要主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后，才把选定方向、整张图或其中子图整理成 reference-set 并进入实现。进入实现阶段时，已有确认参考图用 `openprd visual-compare --reference/--actual`；如果参考图是一张整板、网格图或多对象组合，先运行 `openprd visual-prepare --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>`，确认 contact sheet 后再逐项对比；没有参考图时先判断新建界面还是修改既有界面，新建界面先按用户目标、信息架构变化、视觉决策成本和验证风险完成 3 方向方案评审，修改既有界面用 `openprd visual-compare --before/--after`；局部细节重点则补 `openprd visual-compare --board <focus-board.json>`，多方向实验则补 `openprd visual-compare --board <parallel-board.json>`。用户后续如果说“跟效果图”“不一致”“好丑”“复刻”，不能只口头说对比过了，至少先产出一份视觉证据图。如果用户目标是把工作转成可学习、可复用、可回看、可教学或可沉淀的材料，先按期望产物是否需要章节结构、证据锚点、图文讲解、检索练习、工作示例或长期阅读体验来判断；需要时优先走 `openprd learn .` 生成学习包和阅读器，不要用关键词表触发。
 6. 界面、页面、视觉、样式、信息架构或前端体验任务进入实现前，先读取 `$openprd-frontend-design`，并用 `.openprd/design/active/` 补齐 `facts-sheet / asset-spec / image-preflight / direction-plan / selected-direction`；空白工作区优先从 `.openprd/design/templates/` 选最近模板。若用户已经给了效果图、设计稿、参考截图或其他明确参考图，先把它当成主参考源；只有现有 starter、theme、layout 足够接近时才复用，不接近就允许偏离默认组合，以参考图为准。若当前轮用户已经把页面主题、模块范围或“直接实现”的意图说清，优先运行 `openprd run . --context --message <用户原话>`。若页面主题和模块范围已经明确，优先运行 `openprd design-starter . --starter <starter-id> --out index.html --brief "<页面主题>" --sections "<模块1|模块2|模块3>"` 起第一版真实页面；只有这个页面本来就不依赖外部产品事实、品牌素材或真实图片时，才在 active design artifacts 写清无依赖并补 `--no-external-facts --no-brand-assets --no-real-images`；若题目更像旅游、导览、展览、博物馆、城市、自然观察或案例内容页，先不要带 `--no-real-images`，让 starter 先尝试补首批真实图片；若这类冷启动即使带 message 仍短暂返回 `clarify-user`，把它当成摘要级提醒，先用 3 到 5 行 mini-plan 收口，再继续。starter 落地后默认进入 `Patch Mode`，必须直接在生成的入口文件上补丁修改；即使结构要大改，也是在同一路径内覆盖，不做 delete-first，更不要删除 `index.html` 后另起新稿。如果确实要整页重写，先把完整新稿写到 sibling draft，例如 `index.next.html`，确认内容成形后再覆盖回 `index.html`，不要让正式入口出现空窗；starter 一落地后，只允许做一轮就地对焦：快速读一次生成的入口文件和必要的 active design artifacts；这轮对焦结束后，下一步就必须是真实写入口，不要再回头搜网页、翻 `docs/basic/` 或继续模板漫游；把最后一批必要的查事实、查图、读模板动作放在口头宣布之前做完；一旦已经说“开始覆盖入口文件”或“开始整页重写”，下一步必须出现真实写文件动作，而不是继续只读浏览、压图或停在口头承诺；必要时 hook 会把这类非写入动作挡回去；`Patch Mode` 完成不等于只补合同、只下载素材或只写计划；至少要把入口文件本体改完、主要占位清掉，并把已准备好的真实图片或参考约束真正落进页面；没有明确参考方向时，不要直接落回同一种安全极简解。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openprd/cli",
-  "version": "0.1.10",
+  "version": "0.1.11",
   "description": "AI-native PRD workspace and lifecycle CLI",
   "type": "module",
   "license": "MIT",

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

@@ -57,7 +57,7 @@ description: 为 OpenPrd 产品、CLI、Agent harness、AI code review / PR revi
 ## Source Map
 
 - OpenPrd / PRD 设计对标：`obra/superpowers`、`Fission-AI/OpenSpec`。
-- 创业验证 / 需求收口透镜：`slavingia/skills`。
+- 创业验证 / 需求收口透镜：`slavingia/skills`，重点吸收 community-first、10 specific people、current workaround as competition、Magic Piece of Paper、spreadsheet / no-code first、automate-one-step-at-a-time、forms and lists / CRUD first、build for today's customers not hypothetical future ones、avoid irreversible decisions、one-thing MVP、weekend test、3-of-10 payment proof、10+ paying before productize、first-customer circles、100 paying before launch、charge-from-day-one、customer-1 profitability、spend time before money、minimalist review 和 default alive，并优先按 `find-community -> validate-idea -> processize -> mvp -> first-customers -> pricing -> marketing-plan -> grow-sustainably -> company-values -> minimalist-review` 的时序来落地。
 - 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。
@@ -81,6 +81,7 @@ description: 为 OpenPrd 产品、CLI、Agent harness、AI code review / PR revi
 ## 设计输出
 
 - 给出 OpenPrd 应该内置什么、生成什么、路由什么、保留什么门禁。
+- 如果来源本质上在讲 0 到 1 验证或创业判断，优先把“社区契合 -> 当前替代与痛点证据 -> 手工/表单/no-code 桥接 -> 付费验证 -> 单步自动化 / 最轻产品壳 -> 产品化门槛 -> 增长纪律”落到 requirement-intake、brainstorm、PRD 模板和 hook 提示里，而不是只加一条灵感备注。
 - 优先把结论落到 `CANONICAL_SKILLS`、repo-local skills、AGENTS/CLAUDE/Cursor 生成规则、hooks 或测试，而不是停留在口头建议。
 - 不把外部项目整包复制进 OpenPrd；只吸收可验证的路由、生成、门禁、状态承接和用户体验原则。
 - 需要显式说明时，简短写出参考了哪个来源、借鉴点、适用原因、不照搬边界，以及落到当前任务的具体决策。

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

@@ -27,7 +27,7 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 脑暴模式是独立 lane，不等于普通 clarify：
 
 - 目的不是只补字段，而是先判断值不值得做、给谁做、为什么现在做、有哪些方向、当前工作区能复用什么。
-- 每轮至少要把这几类关键点补齐：第一批最容易触达的社区或人群、现在怎么解决、为什么现在想换、如果先不做完整产品怎么手工交付、什么真实承诺最能证明不是口头兴趣、先怎么低成本验证、验证阶段怎样先活下来、什么情况下先停。
+- 每轮至少要把这几类关键点补齐：第一批最容易触达的社区或人群、你为什么算这个社区里的自己人、现在怎么解决、当前 workaround 到底有多痛、如果先不做完整产品怎么手工交付、能否先用 spreadsheet 或 no-code 跑起来、什么真实承诺最能证明不是口头兴趣、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、先怎么低成本验证、验证阶段怎样先活下来，以及什么情况下先停。
 - 资料来源默认同时包含 benchmark、knowledge、当前工作区文档/代码和开放问题。
 - 如果用户能提供更大的工作区或历史项目目录，优先一起扫描可复用能力、旧流程和已有产品做法。
 - 用户没有明确要求时，Agent 只能“建议进入脑暴模式”，不能静默切换。
@@ -83,11 +83,11 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 ### L2
 
 - 如果用户明确要梳理、先想清楚、进入脑暴模式，或这句话明显还需要先收敛业务方向，先运行或建议 `openprd brainstorm . --topic <当前主题> --open`，不要只在对话里先给一版 requirement 摘要代替脑暴模式。
-- 进入脑暴模式后，Agent 默认先用“创业验证透镜”追问和收口：第一批可触达社区/种子用户、当前替代方案、手工交付路径、承诺信号、最低成本验证、default alive 约束，再补核心诉求、推荐方向、关键角色和复用基础。
+- 进入脑暴模式后，Agent 默认先用“创业验证透镜”追问和收口：第一批可触达社区/种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点强度、手工交付路径、手工作战卡、一件事 MVP、周末级验证、能否先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、初始收费假设、客户 1 盈利路径、10 个样本和付费验证信号、达到什么条件才允许产品化、default alive 约束、增长纪律、可逆性、客户真问题判断和价值观一致性（是不是你愿意长期住进去的业务形态），再补核心诉求、推荐方向、关键角色和复用基础。
 - 进入脑暴模式后，至少要形成 `brainstorm.html` 这类可继续评审和推进的产物，再基于产物追问或收口。
 - 其他 L2 默认先运行或建议 `openprd clarify .`。
 - 先建立首轮项目画像：用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针。
-- 对话内 requirement 摘要除了常规的用户、范围、风险，还要主动抬出“第一批最容易先找谁验证、用户现在怎么解决、先怎么手工交付、什么承诺才算真需求、最低成本先验证什么、验证阶段怎样先活下来”。
+- 对话内 requirement 摘要除了常规的用户、范围、风险，还要主动抬出“第一批最容易先找谁验证、你为什么算这个社区里的自己人、用户现在怎么解决、这个 workaround 到底有多痛、先怎么手工交付、手工作战卡怎么写、第一版只做哪一件事、能不能压成周末级 MVP、能不能先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律、验证阶段怎样先活下来，以及这条路是否可逆、是否真在解决客户问题、是否符合团队价值观、是不是你愿意长期住进去的业务形态”。
 - 再用对话内结构化摘要确认需求，默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”的顺序来写，其中“功能范围”和“技术方案”优先用 Markdown 表格。
 - `需求判断` 和 `需求理解` 先轻后重：先用轻量主句给用户一个一眼能懂的结论，再把边界、风险和技术细项下沉到后续表格或分项里；不要把它们揉成一大段说明。
 - 优先由 Agent 先归纳，再请用户确认；默认先问 1 个最高价值问题，必要时再给 2 到 3 个方向和取舍供用户选，不要一次砸一整墙问题。

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

@@ -9,7 +9,7 @@
 3. 做到什么程度：目标、成功指标、验收标准
 4. 做什么和不做什么：范围、非目标、边界情况
 5. 用户怎么走：主流程、失败路径、恢复路径
-6. 值不值得继续做：第一批可触达社区、种子用户、当前替代方案、手工交付路径、承诺信号、最低成本验证、default alive 约束
+6. 值不值得继续做：第一批可触达社区、种子用户、社区契合依据、当前替代方案、痛点证据、手工交付路径、手工作战卡、手工/表单/no-code 桥接、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、一件事 MVP、周末级验证、第一批客户路径、初始收费假设、客户 1 盈利路径、承诺信号、10 个样本与付费验证、最低成本验证、产品化门槛、增长纪律、default alive 约束、可逆性、客户真问题校验和价值观一致性（是不是你愿意长期住进去的业务形态）
 7. 需求怎么验收：需求矩阵、优先级、验收标准、测试/验证
 8. 有什么风险：依赖、约束、成本、滥用、开放问题
 9. 如何交接：review、change、tasks、负责人、下一步
@@ -103,6 +103,6 @@
 
 - 不输出大段空字段或 TBD 墙；缺事实时进入开放问题。
 - 不把类型专项字段堆在末尾；把它们融进用户、流程、需求矩阵、验收和风险。
-- 如果当前需求仍然像 0 到 1 验证，不要只写“做什么功能”；还要写清第一批先找谁、现在怎么替代、如何先手工交付、什么承诺才算真需求，以及验证阶段怎样先活下来。
+- 如果当前需求仍然像 0 到 1 验证，不要只写“做什么功能”；还要写清第一批先找谁、为什么你算这个社区里的自己人、现在怎么替代、到底痛在哪里、如何先手工交付、手工作战卡、能不能先用表单 / spreadsheet / no-code 跑、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、一件事 MVP、周末级验证、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、什么承诺才算真需求、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律，以及验证阶段怎样先活下来、是否可逆、是否真在解决客户问题、是否符合团队价值观、是不是你愿意长期住进去的业务形态。
 - PRD 写产品判断，`design.md` 写技术方案，`tasks.md` 写执行步骤。
 - 每条 requirement 都应能追踪到验收标准和后续 task。

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

@@ -1,23 +1,108 @@
 # 创业验证透镜
 
-当 L2 需求、脑暴模式或 0 到 1 方向讨论还停留在“做什么功能”时，用这组问题把它收回到更真实的验证闭环。
+当 L2 需求、脑暴模式或 0 到 1 方向讨论还停留在“做什么功能”时，用这组问题把它收回到更真实的创业验证闭环。重点不是多补几个字段，而是把“怎么保持小、什么时候不要继续做大”变成默认判断链。
 
-## 六个关键问题
+## 保持小的六道门
 
-1. 第一批最容易触达的社区、渠道或人群是谁？
-2. 他们现在主要靠什么替代方案、流程或人工方式在解决？
-3. 如果先不做完整产品，怎么靠手工服务、半自动流程或轻量交付先把价值跑出来？
-4. 什么真实承诺最能证明这不是口头兴趣？
-5. 最低成本先验证哪一步最关键？
-6. 在验证阶段，怎样控制成本、时间和交付方式，确保这件事先活下来？
+### 1. 社区门
+
+先问是不是这个社区里的自己人，而不是先问功能点子够不够酷。
+
+- 第一批最容易触达的社区、渠道或人群是谁？
+- 你为什么算这个社区里的自己人？你理解他们的语言、价值观和工作方式吗？
+- 你现在是否已经在这个社区里真实参与、贡献或交付，而不是只把它当作潜在市场？
+- 他们主要在哪里聚集？你现在就能接触到他们吗？
+- 你能不能说出至少 10 个具体的人、团队或试点对象？
+- 这个切口是不是足够小、足够聚焦，能先在一个小圈层里做深？
+
+如果连 10 个具体对象都说不出来，或你其实不属于这个社区，先不要急着进入方案设计。
+
+### 2. 痛点门
+
+先看现在怎么解决，再看值不值得替换。
+
+- 他们现在主要靠什么替代方案、流程、人工 workaround 或更差的付费方案在解决？
+- 这个问题到底有多痛？只是轻微不爽，还是高频、卡业务、卡收入、卡交付？
+- 他们已经在为这个问题花什么时间、精力或金钱？
+- 能不能用一句话说清“谁在什么场景下，被什么问题反复卡住”？
+- 如果需要先教育用户“你其实有这个问题”，这通常是红旗。
+
+当前 workaround 就是你的真实竞争对手；如果没有 workaround，往往说明痛点还不够真。
+
+### 3. 最小执行门
+
+先 processize，再 productize。
+
+- 如果今天禁止你写复杂代码，只能用自己、电话、表单、spreadsheet、Zapier、Notion、Airtable 这类现成工具，你会怎么把价值跑出来？
+- 先不做完整产品时，怎么靠手工服务、半自动流程或轻量交付把结果交出去？
+- 这份手工作战卡怎么写：触发条件、关键步骤、工具、单客耗时和交接点分别是什么？
+- 第一天到底只做哪一件事？一句话讲不清，就说明范围还没收够。
+- 能不能压成周末级 MVP、顾问式试跑或更轻验证？
+- 如果已经不得不开始做产品，能不能只自动化最重复的一步，并把第一版压成 forms / lists / CRUD 这种最轻骨架？
+- 这一步是在服务今天已经存在的客户和重复需求，还是在为假想中的未来规模、未来角色和未来复杂度提前造壳？
+
+这里的“手工作战卡”就是 `Magic Piece of Paper`。重点不是格式漂亮，而是让别人拿到也能继续交付。
+
+### 4. 付费验证门
+
+兴趣不算验证，交易或更强承诺才算。
+
+- 你是否至少和 10 个潜在对象聊过，或已经能明确列出这 10 个样本？
+- 这 10 个样本里，是否至少有大约 3 个愿意付费、预付、安排试点，或给出更强的真实承诺？
+- 什么真实承诺最能证明这不是口头兴趣？例如愿意预约、导入真实数据、提交真实素材、拉同事一起试、接受明确上线窗口。
+- 从第一个客户开始准备怎么收费？什么价格既是 no-brainer，又不会因为免费而失真？
+- 第一个客户如何覆盖时间和交付成本，让这条路更接近 default alive？
+
+“早收费”不是为了立刻赚钱，而是避免 zero price effect。免费可以短时例外，但不能长期拿免费当真需求证明。
+
+### 5. 产品化门
+
+不是“有点反馈了就继续加功能”，而是“达到门槛才允许产品化”。
+
+- 在继续产品化前，要不要先满足这些条件：已经服务过 10+ 付费客户、需求开始重复、手工作战卡几周没大改、你花在交付上的时间开始明显高于找客户？
+- 如果这些条件还不满足，当前最合理的动作是不是继续手工、继续 no-code、继续顾问式试跑，而不是扩成功能列表？
+- 现在明确先不 build 的东西有哪些？
+- 哪一步最值得先自动化？为什么是它，而不是整个系统一起上？
+- 就算开始做产品，第一版是否也只自动化这一小步，而不是马上做成平台、工作台或全流程系统？
+- 如果现在继续做大会产生哪些不可逆决策？例如重招聘、长期绑定、复杂权限、重平台化或高维护承诺。
+
+默认先自动化最费时、最稳定、最重复的那一步，而不是把整套系统一次性做完。
+
+### 6. 增长门
+
+先卖，再 launch；先花时间，再花钱。
+
+- 第一批客户最现实的触达顺序是什么？先熟人、现有客户、社区，还是陌生线索？
+- 在有足够付费基础前，是否应该把 launch 当成庆祝而不是获客策略？
+- 在没有自然增长和明确客户画像前，是否应该先花时间做内容、访谈、私聊和手动销售，而不是先投广告或招人？
+- 什么情况下才允许进入更主动的营销、付费增长或团队扩张？
+- 这条路怎样才能先活下来，而不是先把成本、复杂度和维护负担做爆？
+
+`slavingia/skills` 的强约束是：没有真实付费基础前，不要把 marketing、launch、ads 和规模化错当成解决验证问题的手段。
+
+## 常见红旗
+
+- 目标用户太泛，像“所有创业者”“所有做内容的人”“所有用 AI 的团队”。
+- 你并不在这个社区里，只是觉得这个市场可能很大。
+- 需要先教育别人“你有这个问题”，而不是顺着现有抱怨或现有 workaround 切入。
+- 第一反应是做完整产品，而不是先做手工服务、表单、spreadsheet 或 no-code。
+- 明明还没付费验证，就开始讨论规模化架构、复杂权限、自动化编排或营销投放。
+- 还没拿到稳定重复需求，就先往“多功能平台”“一站式工作台”“全流程闭环”扩。
+- 现在服务的还是假想中的未来客户，而不是今天已经能找到、已经在痛的那批人。
+- 还没跑顺最小成交链，就先做重招聘、长期绑定或其他难回头的决策。
 
 ## 使用方式
 
-- 不要机械逐条盘问；优先把它融进 requirement 摘要、脑暴卡片和追问顺序里。
+- 不要机械逐条盘问；优先把这六道门融进 requirement 摘要、脑暴卡片和追问顺序里。
 - 如果用户已经明确提供其中几项，就直接吸收，不要重复确认。
 - 对内部工具、团队流程或 Agent 项目，也照样适用。
   这里的“社区 / 种子用户”可以是维护者、运营、交付、内部试点团队或最先受影响的一线角色。
-- “承诺信号”不等于一定要收费。
-  也可以是愿意预约、提交真实素材、导入数据、拉同事参与、接受试点、给出明确上线窗口等更强承诺。
-- “default alive”不是财务口号，而是提醒 Agent 先问清楚：
-  这件事在验证阶段怎样不把成本、复杂度和维护负担一下子做爆。
+- requirement 摘要和 brainstorm 默认至少要覆盖：
+  - `communityFit`：为什么算自己人、在哪里触达、为什么是小而可达的切口
+  - `painEvidence`：当前 workaround、痛点强度、已付出的时间或金钱
+  - `paymentProof`：10 个样本、3/10 付费意愿或更强承诺
+  - `smallestExecution`：spreadsheet / 表单 / no-code / 手工桥接，以及明确不 build 的部分
+  - `productizeGate`：达到什么条件才继续产品化
+  - `growthDiscipline`：熟人到陌生线索的顺序、何时不该 launch、先花时间别先花钱
+- “default alive”不是财务口号，而是提醒 Agent 先问清楚：这件事在验证阶段怎样不把成本、复杂度和维护负担一下子做爆。
+- “minimalist review” 不只看市场大不大，还要看这条路是不是更简单、更可逆、更贴近客户真问题，并且不违背团队想坚持的价值观；更进一步，还要问这是不是你愿意长期住进去、不会反过来绑住自己的业务形态。

package/skills/openprd-shared/SKILL.md

@@ -119,7 +119,7 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
    - 如果用户刚刚已经确认了现有功能优化（L1）的 mini-plan、范围边界或正式产品边界，后续承接要明确写成“已确认，我按这个继续/收口/落地”，不要只写一个“确认”，也不要写成“确认，我们就按这个……”这种像再次索取确认的句子。
 - 新功能/新流程方案包括新产品、模块、流程、权限、计费、AI/第三方集成、云服务、跨系统、数据迁移或边界不清的需求；先走 requirement intake、对话内 requirement 摘要确认、review、change 和 tasks，再实现。
 - 对话内 requirement 摘要保持原有“需求判断 / 需求理解 / 功能范围 / 技术方案”结构，但 `需求判断` 和 `需求理解` 先用轻量主句说清结论；边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们挤成一大段。
-- 对于 L2 或脑暴诉求，默认再补一层“创业验证闭环”：第一批最容易触达的人群/社区、当前替代方案、先不做完整产品时的手工路径、什么真实承诺才算真需求、最低成本验证动作，以及验证阶段怎样先活下来。
+- 对于 L2 或脑暴诉求，默认再补一层“创业验证闭环”：第一批最容易触达的人群/社区、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先不做完整产品时的手工路径、手工作战卡、一件事 MVP、周末级验证、能否先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律，以及验证阶段怎样先活下来、这条路是否可逆、是否真在解决客户问题、是否符合团队价值观，以及这是不是你愿意长期住进去、不会反过来绑住团队的业务形态。
 - 历史 active change 在新 requirement intake 激活时只作为提醒，不抢当前主线。
    - 会话 ID、task handle、work unit 和用户明确描述的已有需求对象，都比全局 active change 更具体；必须先解析这些显式目标，再决定是否沿用当前工作区状态。
 18. 关键产品事实缺失时，先问用户再推进。

package/src/agent-integration.js

@@ -180,7 +180,7 @@ const CANONICAL_SKILLS = [
       '- 表格优先用于方案对比、状态盘点、问题排查、风险审查、多对象 QA、文件/命令清单、需求场景覆盖和内容/素材规划；单一结论、单一动作、代码示例、命令示例和叙事型说明不要强行表格化。',
       '- 面向用户的时间统一使用上海时区 `YYYY-MM-DD HH:mm:ss` 格式，不带 `T`、`Z` 或毫秒。',
       '- 保持未解决假设可见，不要悄悄补脑。',
-      '- 对于 L2、脑暴或仍在判断值不值得做的 0 到 1 需求，默认再补一层“创业验证闭环”：第一批最容易触达的人群/社区、当前替代方案、先不做完整产品时的手工路径、什么真实承诺才算真需求、最低成本验证动作，以及验证阶段怎样先活下来。',
+      '- 对于 L2、脑暴或仍在判断值不值得做的 0 到 1 需求，默认再补一层“创业验证闭环”：第一批最容易触达的人群/社区、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先不做完整产品时的手工路径、能否先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、什么真实承诺才算真需求、有没有 10 个样本和更强付费信号、最低成本验证动作、达到什么条件才允许产品化，以及验证阶段怎样先活下来、增长阶段守什么纪律，以及这是不是你愿意长期住进去、不会反过来绑住自己的业务形态。',
       '- 项目基线文档路径只能是 `docs/basic/`。',
       '- 声称就绪前，至少通过 `openprd validate .` 和 `openprd standards . --verify`。',
       '- 实现就绪还要运行 `openprd quality . --verify`，并审阅 HTML 质量评估报告中的场景标签、必需 EVO 门禁、可观测性、业务护栏、评估执行环境、性能和知识缺口。L2 或跨页面实现的最终回复必须带上最新 HTML 质量报告和 task-scoped 测试报告路径；缺失时只能说“实现完成但项目级收口未完成”。',
@@ -201,7 +201,7 @@ const CANONICAL_SKILLS = [
       '- 只要实现新增或修改文件，就做文档影响检查；缺失的 `docs/basic/`、文件说明书和文件夹 README 要补齐，已有文档受影响时要更新。',
       '- 涉及后端、脚本、Agent、工具链、服务或数据处理变更时，把 CLI 与 API 视为同级接入面：检查命令入口、参数、输出契约、`help`、`doctor`、`dry-run`、`status` 与接口协议、返回结构、身份边界是否受影响，并同步更新 `docs/basic/backend-structure.md`；若某一面不适用也要明确写原因。',
       '- Codex hooks 默认使用 `lite`：`UserPromptSubmit` 注入上下文、轻量 `PreToolUse` 写入门禁，以及 `Stop` 本轮收工回顾。若发现可复用的项目经验，`Stop` 会要求 Agent 在最终回复结尾用人话说明“本次观察到的情况 / 计划保留的项目经验 / 以后怎么复用 / 只保留在当前项目里”，再询问用户是否保留；只有项目明确需要更重的工具级遥测时，才切到 `full`。',
-      '- 需求分流优先使用 `$openprd-requirement-intake`，不要按固定关键词判断。用户可见需求类型和内部路由码的固定对照为：直接处理=L0、现有功能优化=L1、新功能/新流程方案=L2。用户审查默认把路由码并进“需求类型：直接处理（L0）”这类标签里；只有内部排障确实受益时，才额外附“内部路由码”。L0 可直接处理并事后说明，不打开正式 PRD/review/change/tasks；L1 先给对话内 mini-plan，默认不生成正式 PRD/change/tasks；只有 L2 才进入 requirement intake 与 PRD/review/change/tasks。L2 的对话内 requirement 摘要默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”四段来写，其中“功能范围”和“技术方案”优先用 Markdown 表格，帮助用户先总后分地看清范围和实现方向；`需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清这次是什么、核心问题和第一版目标，边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们都塞进一整段长话里，也不要把某条示例文案写成固定模板。若当前仍是 0 到 1 探索、脑暴或值不值得做的判断，摘要里还要主动补上“验证与创业闭环”：第一批最容易触达的社区或种子用户、当前替代方案、先怎么手工交付、什么承诺才算真需求、最低成本先验证什么，以及验证阶段怎样先活下来。如果用户刚刚已经确认了现有功能优化（L1）的 mini-plan、范围边界或正式产品边界，后续承接要明确写成“已确认，我按这个继续/收口/落地”，不要用“确认，我们就按这个……”这类像再次索取确认的句子。单纯的“请帮我实现/继续实现”不等于跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。若当前仍在 L2 的首轮澄清或 requirement 摘要确认阶段，不要写成“你回我一句我就开始实现”；只能承诺“我先整理需求摘要给你确认，确认后再进入 PRD / review 流程”。如果用户的下一条回复只是承接上一轮 requirement 摘要的短跟进，而不是提出新范围、改目标或重新发起分析请求，就把它当成对上一轮摘要、默认方向或选项的继续确认，不要重新开一轮泛化 clarify；应直接按当前对话上下文把已确认事实用 canonical capture 路径、`user-confirmed` 来源写回，而不是继续写 `agent-inferred/project-derived` 的用户澄清字段。若用户原始意图已经明确要求实现，review 已确认且 tasks 就绪后可直接进入执行；否则在请求执行授权前，先输出执行确认清单，列出本轮目标、将执行内容、不做事项、验证方式和已知风险，不能只要求用户回复一句确认。',
+      '- 需求分流优先使用 `$openprd-requirement-intake`，不要按固定关键词判断。用户可见需求类型和内部路由码的固定对照为：直接处理=L0、现有功能优化=L1、新功能/新流程方案=L2。用户审查默认把路由码并进“需求类型：直接处理（L0）”这类标签里；只有内部排障确实受益时，才额外附“内部路由码”。L0 可直接处理并事后说明，不打开正式 PRD/review/change/tasks；L1 先给对话内 mini-plan，默认不生成正式 PRD/change/tasks；只有 L2 才进入 requirement intake 与 PRD/review/change/tasks。L2 的对话内 requirement 摘要默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”四段来写，其中“功能范围”和“技术方案”优先用 Markdown 表格，帮助用户先总后分地看清范围和实现方向；`需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清这次是什么、核心问题和第一版目标，边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们都塞进一整段长话里，也不要把某条示例文案写成固定模板。若当前仍是 0 到 1 探索、脑暴或值不值得做的判断，摘要里还要主动补上“验证与创业闭环”：第一批最容易触达的社区或种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先怎么手工交付、手工作战卡怎么写、能不能先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一版只做哪一件事、能不能压成周末级 MVP、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律、这条路是否可逆、是否真在解决客户问题、以及是否符合团队价值观、是不是你愿意长期住进去的业务形态。如果用户刚刚已经确认了现有功能优化（L1）的 mini-plan、范围边界或正式产品边界，后续承接要明确写成“已确认，我按这个继续/收口/落地”，不要用“确认，我们就按这个……”这类像再次索取确认的句子。单纯的“请帮我实现/继续实现”不等于跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。若当前仍在 L2 的首轮澄清或 requirement 摘要确认阶段，不要写成“你回我一句我就开始实现”；只能承诺“我先整理需求摘要给你确认，确认后再进入 PRD / review 流程”。如果用户的下一条回复只是承接上一轮 requirement 摘要的短跟进，而不是提出新范围、改目标或重新发起分析请求，就把它当成对上一轮摘要、默认方向或选项的继续确认，不要重新开一轮泛化 clarify；应直接按当前对话上下文把已确认事实用 canonical capture 路径、`user-confirmed` 来源写回，而不是继续写 `agent-inferred/project-derived` 的用户澄清字段。若用户原始意图已经明确要求实现，review 已确认且 tasks 就绪后可直接进入执行；否则在请求执行授权前，先输出执行确认清单，列出本轮目标、将执行内容、不做事项、验证方式和已知风险，不能只要求用户回复一句确认。',
       '- 涉及最佳实践、benchmark、对标、参考产品、prompt engineering、Agent harness、context engineering、图标资源、CLI 或 skill 体系设计时，先使用 `$openprd-benchmark-router` 选择证据源，再进入 Context7、DeepWiki 或官方资料调研。',
       '- 入口路由优先看 `$openprd-router`；具体命令速查优先看 `.openprd/harness/command-catalog.md`。',
       '- `AGENTS.md` 只保留轻量合同；详细执行细则优先沉淀到 repo-local skills、command catalog 和 hooks。',
@@ -289,7 +289,7 @@ const CANONICAL_SKILLS = [
       '',
       '- `Fission-AI/OpenSpec`：适合对标 spec 驱动变更流程、change lifecycle、spec 与 execution artifact 分层、动态 agent 指令组装和验证门禁。',
       '- `obra/superpowers`：适合对标 mandatory skill routing、多平台适配、轻量 bootstrap、worktree/subagent 协作和 skill 深浅分层。',
-      '- `slavingia/skills`：适合对标 0 到 1 验证、community-first、current workaround、manual-first delivery、commitment signals、processize before productize 和 default alive 思路，并把这些原则回写到 requirement-intake、brainstorm 和 PRD 结构。',
+      '- `slavingia/skills`：适合对标 0 到 1 验证、community-first、10 specific people、current workaround、manual-first delivery、Magic Piece of Paper、spreadsheet / no-code first、automate-one-step-at-a-time、forms and lists / CRUD first、build for today\'s customers not hypothetical future ones、avoid irreversible decisions、one-thing MVP、weekend test、3-of-10 payment proof、10+ paying before productize、first-customer circles、100 paying before launch、charge-from-day-one、customer-1 profitability、spend time before money、minimalist review 和 default alive 思路，并把这些原则回写到 requirement-intake、brainstorm 和 PRD 结构。',
       '- 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。',
@@ -313,7 +313,7 @@ const CANONICAL_SKILLS = [
       '## 设计输出',
       '',
       '- 给出 OpenPrd 应该内置什么、生成什么、路由什么、保留什么门禁。',
-      '- 如果来源本质上在讲 0 到 1 验证或创业判断，优先把“社区 -> 替代方案 -> 手工路径 -> 承诺信号 -> 最低成本验证 -> 先活下来”落到 requirement-intake、brainstorm、PRD 模板和 hook 提示里，而不是只加一条灵感备注。',
+      '- 如果来源本质上在讲 0 到 1 验证或创业判断，优先把“社区契合 -> 当前替代与痛点证据 -> 手工/表单/no-code 桥接 -> 付费验证 -> 产品化门槛 -> 增长纪律”落到 requirement-intake、brainstorm、PRD 模板和 hook 提示里，而不是只加一条灵感备注。',
       '- 优先把结论落到 `CANONICAL_SKILLS`、repo-local skills、AGENTS/CLAUDE/Cursor 生成规则、hooks 或测试，而不是停留在口头建议。',
       '- 不把外部项目整包复制进 OpenPrd；只吸收可验证的路由、生成、门禁、状态承接和用户体验原则。',
       '- 需要显式说明时，简短写出参考了哪个来源、借鉴点、适用原因、不照搬边界，以及落到当前任务的具体决策。',
@@ -344,7 +344,7 @@ const CANONICAL_SKILLS = [
       '5. 涉及最佳实践、benchmark、对标、参考产品、prompt engineering、Agent harness、context engineering、图标资源、CLI 或 skill 体系设计时，先使用 `$openprd-benchmark-router`。',
       '6. 先用 `$openprd-requirement-intake` 做需求类型语义分流：直接处理(L0)可直接处理并事后说明，不打开正式 PRD/review/change/tasks；现有功能优化(L1)给对话内 mini-plan 后执行，默认不生成正式 PRD/change/tasks；只有新功能/新流程方案(L2)在改代码前必须先走需求入口：`openprd clarify .` 会生成需求入口自省，并只在对话内输出澄清摘要或简短清单；正式 HTML 评审留给后续 review。若当前问题本质上还在判断值不值得做、先找谁验证、能不能先手工交付，就先补“创业验证透镜”，不要急着把方案写成既定需求。',
       '6a. 任何界面、页面、视觉、样式或前端体验任务在进入实现前，都要额外读取 `$openprd-frontend-design`，并优先检查 `.openprd/design/active/` 下是否已经补齐 `facts-sheet / asset-spec / image-preflight / direction-plan / selected-direction`。',
-      '7. 事实缺失时，先用 `openprd clarify .` 生成需求入口自省，并在对话里先按“需求判断 / 需求理解 / 功能范围 / 技术方案”给 requirement 摘要；其中“功能范围”和“技术方案”优先用 Markdown 表格，分别写清 `功能模块 | 这次先做什么 | 这次先不做什么` 与 `技术部分 | 初步方案 | 主要负责什么`。`需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清这次是什么、核心问题和第一版目标；边界、风险、异常例子和技术细节下沉到后续分项或表格，不要揉成一大段长话，也不要把某条示例文案写成固定模板。若当前更像 0 到 1 验证，摘要里还要主动抬出：第一批最容易触达的社区或种子用户、当前替代方案、先怎么手工交付、什么承诺才算真需求、最低成本先验证什么，以及验证阶段怎样先活下来。确认该 requirement 摘要后，再用 `openprd capture .` 写回已确认事实，并继续 classify/synthesize/review、生成或检查 change、拆任务。如果用户的下一条回复只是承接上一轮 requirement 摘要的短跟进，而不是提出新范围、改目标或重新发起分析请求，就把它当成对上一轮摘要、默认方向或选项的继续确认，不要重新开一轮泛化 clarify；应直接按当前对话上下文把已确认事实用 canonical capture 路径、`user-confirmed` 来源写回，而不是继续写 `agent-inferred/project-derived` 的用户澄清字段。`clarifyPresentation.mode` 为 `inline` 或 `inline-with-checklist`，直接在对话中先整理首轮项目画像：用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针，再压缩成用户容易看懂的总分结构，不打开澄清 HTML。L2 的首轮澄清只能承诺“我先整理需求摘要给你确认，确认后再进入 PRD / review 流程”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现合成一步。review 重点摘要胶囊应控制在 15 个字以内，作为扫读标签，不写成长句；对用户给稳定 artifact 路径，确认命令使用页面复制出的 `--version`、`--digest` 和 `--work-unit`，不要把可被其他对话覆盖的 active review 当成唯一确认入口，也不要把“可以开做”“继续实现”、单纯的“请帮我实现”，或单独一句“不要评审”当成 `review --mark confirmed` 或 requirement 写入路径的依据。生成 spec 和 tasks 时默认使用简体中文，但必要专有名词、品牌名、命令名、路径、字段名和 API 术语可以保留原文；如果只是纯内部措辞整理，可用 `openprd capture . --source agent-normalized` 写回，这类非语义规范化不应重开用户 review。默认 approval policy 是 decision-points：需要时保留稳定 `review.html`，但只有用户明确表示不需要进行任何确认时，才允许跳过 requirement 摘要确认并按当前稳定 artifact 的精确 `version + digest + work-unit` 静默记录 review；单纯的“请帮我实现/继续实现”不触发这个豁免。若用户刚刚已经确认了现有功能优化（L1）的 mini-plan、范围边界或正式产品边界，后续承接要写成“已确认，我按这个继续”，不要写成“确认，我们就按这个……”这类像再次索取确认的句子。若用户原始意图已明确要求实现，则在当前 approval policy 满足且 tasks 就绪后直接进入执行；否则先输出执行确认清单，列出本轮目标、将执行内容、不做事项、验证方式和已知风险，再请求明确执行授权，不能只要求用户回复一句确认。',
+      '7. 事实缺失时，先用 `openprd clarify .` 生成需求入口自省，并在对话里先按“需求判断 / 需求理解 / 功能范围 / 技术方案”给 requirement 摘要；其中“功能范围”和“技术方案”优先用 Markdown 表格，分别写清 `功能模块 | 这次先做什么 | 这次先不做什么` 与 `技术部分 | 初步方案 | 主要负责什么`。`需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清这次是什么、核心问题和第一版目标；边界、风险、异常例子和技术细节下沉到后续分项或表格，不要揉成一大段长话，也不要把某条示例文案写成固定模板。若当前更像 0 到 1 验证，摘要里还要主动抬出：第一批最容易触达的社区或种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先怎么手工交付、手工作战卡怎么写、第一版只做哪一件事、能不能压成周末级 MVP、能不能先用 spreadsheet / 表单 / no-code 跑起来、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律、这条路是否可逆、是否真在解决客户问题、是否符合团队价值观、是不是你愿意长期住进去的业务形态，以及最低成本先验证什么和验证阶段怎样先活下来。确认该 requirement 摘要后，再用 `openprd capture .` 写回已确认事实，并继续 classify/synthesize/review、生成或检查 change、拆任务。如果用户的下一条回复只是承接上一轮 requirement 摘要的短跟进，而不是提出新范围、改目标或重新发起分析请求，就把它当成对上一轮摘要、默认方向或选项的继续确认，不要重新开一轮泛化 clarify；应直接按当前对话上下文把已确认事实用 canonical capture 路径、`user-confirmed` 来源写回，而不是继续写 `agent-inferred/project-derived` 的用户澄清字段。`clarifyPresentation.mode` 为 `inline` 或 `inline-with-checklist`，直接在对话中先整理首轮项目画像：用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针，再压缩成用户容易看懂的总分结构，不打开澄清 HTML。L2 的首轮澄清只能承诺“我先整理需求摘要给你确认，确认后再进入 PRD / review 流程”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现合成一步。review 重点摘要胶囊应控制在 15 个字以内，作为扫读标签，不写成长句；对用户给稳定 artifact 路径，确认命令使用页面复制出的 `--version`、`--digest` 和 `--work-unit`，不要把可被其他对话覆盖的 active review 当成唯一确认入口，也不要把“可以开做”“继续实现”、单纯的“请帮我实现”，或单独一句“不要评审”当成 `review --mark confirmed` 或 requirement 写入路径的依据。生成 spec 和 tasks 时默认使用简体中文，但必要专有名词、品牌名、命令名、路径、字段名和 API 术语可以保留原文；如果只是纯内部措辞整理，可用 `openprd capture . --source agent-normalized` 写回，这类非语义规范化不应重开用户 review。默认 approval policy 是 decision-points：需要时保留稳定 `review.html`，但只有用户明确表示不需要进行任何确认时，才允许跳过 requirement 摘要确认并按当前稳定 artifact 的精确 `version + digest + work-unit` 静默记录 review；单纯的“请帮我实现/继续实现”不触发这个豁免。若用户刚刚已经确认了现有功能优化（L1）的 mini-plan、范围边界或正式产品边界，后续承接要写成“已确认，我按这个继续”，不要写成“确认，我们就按这个……”这类像再次索取确认的句子。若用户原始意图已明确要求实现，则在当前 approval policy 满足且 tasks 就绪后直接进入执行；否则先输出执行确认清单，列出本轮目标、将执行内容、不做事项、验证方式和已知风险，再请求明确执行授权，不能只要求用户回复一句确认。',
       '8. 评审页里的需求关系图、需求流程图和重点摘要不要靠 HTML 截断；`openprd synthesize` 生成版本快照后，不要直接让用户确认 review。必须先用 `openprd review-presentation . --template` 查看展示文案契约，让 Agent 按 reviewPresentation 写短文案，再用 `openprd review-presentation . --presentation <json> --write --fail-on-violation` 校验并写回；脚本会在通过后写入校验元信息并重渲染可确认 review.html。超限时按脚本返回的 jsonPath 和字数限制重新提炼，不手工改快照、不裁剪原文。',
       '8a. 界面、页面、视觉、样式或前端体验需求要额外判断 UI 影响面：若会明显改变信息架构、核心布局、主视觉、关键路径、组件层级/密度，或用户需要先选设计方向，先做“大界面改动视觉方案评审”。在 PRD 定稿或实现开工前，已有界面时用 Codex Computer Use 截取产品内对应功能当前界面，冷启动没有现有界面时基于已确认 PRD、用户群体、第一版切片和视觉目标生成设计 brief；再用 `imagegen`（Codex 原生 Image 2）生成至少 3 个不同设计思想方向，横向拼接为一张左上角标注 1/2/3 的大图作为候选效果图展示。主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后才把选定方向、整张图或其中子图整理到 `.openprd/harness/visual-reviews/`。',
       '8b. 3 个方向不能只是同一种安全解的轻微变化。至少要在 `.openprd/design/active/direction-plan.md` 里区分不同生成逻辑、适用场景和主要风险；一旦用户确认方向，先在 `.openprd/design/active/selected-direction.md` 锁定选中的 lens、theme、layout 和组件，再进入编码。',
@@ -1095,7 +1095,7 @@ function agentContractBody() {
     '',
     '1. 动手前先从 `.openprd/` 重建状态，并先运行 `openprd run . --context`；它是建议上下文，不是自动执行指令。',
     '2. 规划、分析、架构评审、“怎么改”或“会动哪些文件”类请求保持只读；只有用户明确要求实现、继续任务、深度调研、对标复刻或提交时才进入执行。',
-    '3. 先分流再执行：`openprd-requirement-intake` 按影响面、未知数、决策成本和验证成本判断需求类型，并保留内部路由码对照：直接处理=L0，现有功能优化=L1，新功能/新流程方案=L2。用户审查默认把路由码并进“需求类型：直接处理（L0）”这类标签里；只有内部排障确实受益时，才额外附“内部路由码”。直接处理类需求可直接处理并事后说明，不打开正式 PRD/review/change/tasks；现有功能优化先在对话内给 mini-plan 再执行，默认不生成正式 PRD/change/tasks；如果用户刚刚已经确认了 L1 mini-plan、范围边界或正式产品边界，后续承接要写成“已确认，我按这个继续”，不要用“确认，我们就按这个……”这类像再次索取确认的句子。只有新功能/新流程方案才先走 requirement intake、对话内 requirement 摘要确认，再 `review/change/tasks`，最后才实现。L2 的 requirement 摘要默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”来写，其中“功能范围”和“技术方案”优先用 Markdown 表格，帮助用户一眼看清；`需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清这次是什么、核心问题和第一版目标，边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们都塞进一整段长话里，也不要把某条示例文案写成固定模板。若当前仍在 0 到 1 探索、脑暴或值不值得做的判断，摘要里还要主动补上“验证与创业闭环”：第一批最容易触达的社区或种子用户、当前替代方案、先怎么手工交付、什么承诺才算真需求、最低成本先验证什么，以及验证阶段怎样先活下来。L2 的首轮澄清只能承诺“我先整理需求摘要给你确认”，不能把 requirement 摘要确认、review 和实现压成一句“你回我一句我就开始实现”。如果 `openprd run . --context` 仍然建议 `clarify-user`，当前这轮回复的目标就只能是 `需求摘要` 或 `1 个最高价值澄清点`，不要写成“我先按默认方案实现”。如果用户的下一条回复只是承接上一轮 requirement 摘要的短跟进，而不是提出新范围、改目标或重新发起分析请求，就把它当成对上一轮摘要、默认方向或选项的继续确认，不要重新开一轮泛化 clarify；应直接按当前对话上下文把已确认事实用 canonical capture 路径、`user-confirmed` 来源写回，而不是继续写 `agent-inferred/project-derived` 的用户澄清字段。单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。`review.html` 是稳定评审 artifact，不再默认等于唯一的人类停顿点；默认按 decision-points approval policy 执行，只有当前 lane 仍要求人类决策时才在 final answer 主体里停下请求确认；当 review 已确认且 tasks 已就绪但还需要执行授权时，先给执行确认清单再请用户确认。',
+    '3. 先分流再执行：`openprd-requirement-intake` 按影响面、未知数、决策成本和验证成本判断需求类型，并保留内部路由码对照：直接处理=L0，现有功能优化=L1，新功能/新流程方案=L2。用户审查默认把路由码并进“需求类型：直接处理（L0）”这类标签里；只有内部排障确实受益时，才额外附“内部路由码”。直接处理类需求可直接处理并事后说明，不打开正式 PRD/review/change/tasks；现有功能优化先在对话内给 mini-plan 再执行，默认不生成正式 PRD/change/tasks；如果用户刚刚已经确认了 L1 mini-plan、范围边界或正式产品边界，后续承接要写成“已确认，我按这个继续”，不要用“确认，我们就按这个……”这类像再次索取确认的句子。只有新功能/新流程方案才先走 requirement intake、对话内 requirement 摘要确认，再 `review/change/tasks`，最后才实现。L2 的 requirement 摘要默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”来写，其中“功能范围”和“技术方案”优先用 Markdown 表格，帮助用户一眼看清；`需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清这次是什么、核心问题和第一版目标，边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们都塞进一整段长话里，也不要把某条示例文案写成固定模板。若当前仍在 0 到 1 探索、脑暴或值不值得做的判断，摘要里还要主动补上“验证与创业闭环”：第一批最容易触达的社区或种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先怎么手工交付、手工作战卡怎么写、能不能先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一版只做哪一件事、能不能压成周末级 MVP、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律、这条路是否可逆、是否真在解决客户问题、以及是否符合团队价值观、是不是你愿意长期住进去的业务形态。L2 的首轮澄清只能承诺“我先整理需求摘要给你确认”，不能把 requirement 摘要确认、review 和实现压成一句“你回我一句我就开始实现”。如果 `openprd run . --context` 仍然建议 `clarify-user`，当前这轮回复的目标就只能是 `需求摘要` 或 `1 个最高价值澄清点`，不要写成“我先按默认方案实现”。如果用户的下一条回复只是承接上一轮 requirement 摘要的短跟进，而不是提出新范围、改目标或重新发起分析请求，就把它当成对上一轮摘要、默认方向或选项的继续确认，不要重新开一轮泛化 clarify；应直接按当前对话上下文把已确认事实用 canonical capture 路径、`user-confirmed` 来源写回，而不是继续写 `agent-inferred/project-derived` 的用户澄清字段。单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。`review.html` 是稳定评审 artifact，不再默认等于唯一的人类停顿点；默认按 decision-points approval policy 执行，只有当前 lane 仍要求人类决策时才在 final answer 主体里停下请求确认；当 review 已确认且 tasks 已就绪但还需要执行授权时，先给执行确认清单再请用户确认。',
     '4. change/tasks 就绪后，用 `openprd-test-strategy` 按风险选择单元、集成、端到端、人工、视觉、小程序、性能或安全验证组合，并在任务或报告中保留 evidence-plan；同时根据任务边界记录 execution strategy：小范围修正保持 `serial`，中等规模 L1/L2 可推荐 `parallel-workers`，高风险或大规模实现再升级到 `parallel-workers-isolated`；70/20/10 只作健康形状参考，不作硬门禁。',
       '5. 纯图片、封面图、配图、海报、插画、图标、贴纸、mockup 或“先看样子”请求默认直接使用 `imagegen`，也就是 Codex 原生 Image 2；其中 logo、icon、avatar、badge 等开发素材在用户未明确要求场景化展示时，默认按独立素材输出（standalone asset）生成：全画布单主体，不额外添加卡片、设备框或其他展示容器；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流。生图结果先当候选效果图，不要默认登记到 `.openprd/harness/visual-reviews/`。Agent 要主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现；只有确认后，才把选定方向、整张图或其中子图整理成 reference-set 并进入实现。进入实现阶段时，已有确认参考图用 `openprd visual-compare --reference/--actual`；如果参考图是一张整板、网格图或多对象组合，先运行 `openprd visual-prepare --reference <效果图> --grid <列>x<行>` 或 `--boxes <plan.json>`，确认 contact sheet 后再逐项对比；没有参考图时先判断新建界面还是修改既有界面，新建界面先按用户目标、信息架构变化、视觉决策成本和验证风险完成 3 方向方案评审，修改既有界面用 `openprd visual-compare --before/--after`；局部细节重点则补 `openprd visual-compare --board <focus-board.json>`，多方向实验则补 `openprd visual-compare --board <parallel-board.json>`。用户后续如果说“跟效果图”“不一致”“好丑”“复刻”，不能只口头说对比过了，至少先产出一份视觉证据图。如果用户目标是把工作转成可学习、可复用、可回看、可教学或可沉淀的材料，先按期望产物是否需要章节结构、证据锚点、图文讲解、检索练习、工作示例或长期阅读体验来判断；需要时优先走 `openprd learn .` 生成学习包和阅读器，不要用关键词表触发。',
     '6. 界面、页面、视觉、样式、信息架构或前端体验任务进入实现前，先读取 `$openprd-frontend-design`，并用 `.openprd/design/active/` 补齐 `facts-sheet / asset-spec / image-preflight / direction-plan / selected-direction`；空白工作区优先从 `.openprd/design/templates/` 选最近模板。若用户已经给了效果图、设计稿、参考截图或其他明确参考图，先把它当成主参考源；只有现有 starter、theme、layout 足够接近时才复用，不接近就允许偏离默认组合，以参考图为准。若当前轮用户已经把页面主题、模块范围或“直接实现”的意图说清，优先运行 `openprd run . --context --message <用户原话>`。若页面主题和模块范围已经明确，优先运行 `openprd design-starter . --starter <starter-id> --out index.html --brief "<页面主题>" --sections "<模块1|模块2|模块3>"` 起第一版真实页面；只有这个页面本来就不依赖外部产品事实、品牌素材或真实图片时，才在 active design artifacts 写清无依赖并补 `--no-external-facts --no-brand-assets --no-real-images`；若题目更像旅游、导览、展览、博物馆、城市、自然观察或案例内容页，先不要带 `--no-real-images`，让 starter 先尝试补首批真实图片；若这类冷启动即使带 message 仍短暂返回 `clarify-user`，把它当成摘要级提醒，先用 3 到 5 行 mini-plan 收口，再继续。starter 落地后默认进入 `Patch Mode`，必须直接在生成的入口文件上补丁修改；即使结构要大改，也是在同一路径内覆盖，不做 delete-first，更不要删除 `index.html` 后另起新稿。如果确实要整页重写，先把完整新稿写到 sibling draft，例如 `index.next.html`，确认内容成形后再覆盖回 `index.html`，不要让正式入口出现空窗；starter 一落地后，只允许做一轮就地对焦：快速读一次生成的入口文件和必要的 active design artifacts；这轮对焦结束后，下一步就必须是真实写入口，不要再回头搜网页、翻 `docs/basic/` 或继续模板漫游；把最后一批必要的查事实、查图、读模板动作放在口头宣布之前做完；一旦已经说“开始覆盖入口文件”或“开始整页重写”，下一步必须出现真实写文件动作，而不是继续只读浏览、压图或停在口头承诺；必要时 hook 会把这类非写入动作挡回去；`Patch Mode` 完成不等于只补合同、只下载素材或只写计划；至少要把入口文件本体改完、主要占位清掉，并把已准备好的真实图片或参考约束真正落进页面；没有明确参考方向时，不要直接落回同一种安全极简解。',