@openprd/cli 0.1.22 → 0.1.23

package/README.md

@@ -18,6 +18,10 @@ OpenPrd 是一个轻量但结构化的 **PRD harness**。你只需要先把问
 
 它把需求、决策和验证结果沉淀成稳定的 HTML 产物，而不是把状态散落在聊天记录或终端输出里。OpenPrd 的职责是帮助 Agent 做事：PRD、review、change、tasks、设计合同与测试证据由 Agent 在后台维护，不再要求用户回复指定内容才能继续。
 
+## 0.1.23：彻底移除流程确认残留
+
+0.1.23 在 0.1.22 的非阻断 hook 基础上，继续清除了 requirement、harness 与大界面方向规范中的旧确认文案，并增加生成后三端 skill 回归测试。Agent 会后台维护需求、评审、设计和验证材料；用户要求实现或继续时，不再被 OpenPrd 要求批准摘要、选择默认方向或回复执行口令。
+
 ## 0.1.22：不再把流程材料变成用户门禁
 
 - OpenPrd 不再因需求摘要、评审稿、设计合同、测试证据或风险分类缺失而阻断实现。

package/README_EN.md

@@ -17,6 +17,10 @@ OpenPrd is a lightweight **PRD harness**. Start by describing the problem in pla
 
 Instead of hiding key decisions in prompts or terminal logs, OpenPrd keeps people and agents aligned around stable HTML artifacts such as `review.html`, learning readers, and quality reports. OpenPrd helps the agent do the work: PRDs, reviews, changes, tasks, design contracts, and evidence are maintained in the background without requiring the user to reply with a prescribed confirmation.
 
+## 0.1.23: confirmation-copy cleanup is complete
+
+0.1.23 removes the remaining confirmation-oriented wording from requirement, harness, and large-UI direction skills, and adds a regression test against generated skills for all three clients. OpenPrd maintains requirement, review, design, and verification artifacts in the background; an implementation request no longer triggers an OpenPrd summary approval, default-direction choice, or execution passphrase.
+
 ## 0.1.22: workflow artifacts are no longer user gates
 
 - Missing requirement summaries, review artifacts, design contracts, test evidence, or risk classifications no longer block implementation.

package/package.json

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

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

@@ -137,7 +137,7 @@ description: 为 OpenPrd 的界面、页面、视觉、样式和前端体验任
 
 ### 5a. 界面效果图生成质量合同
 
-- Agent 不需要等待用户补一句“请生图”。当语义判断属于大界面改动且视觉决策成本高时，默认主动生成 3 个可评审方向，并在实现前停下来让用户选择。
+- Agent 不需要等待用户补一句“请生图”。当语义判断属于大界面改动且视觉决策成本高时，默认主动生成 3 个可评审方向，并采用最可逆、最贴近现有视觉 DNA 的方向继续；用户主动选择时再覆盖默认方向。
 - 每次生成前都要写清用途、目标用户、产品气质、业务约束、核心动作和唯一记忆点；效果图必须服务于任务路径，不能只追求展示感。
 - 视觉质量从字体角色、色彩系统、空间构图、信息层级、表面语言、图标语言、动效含义和氛围细节一起判断。复杂度要与审美主张匹配，工具界面优先扫描效率和状态清晰，叙事界面才允许更强的视觉张力。
 - 避免通用 AI 模板味：无依据的蓝紫渐变、默认字体、等权白卡堆叠、过量大圆角、无语境装饰、只换颜色的伪方向，以及为了“高级”牺牲可读性。

package/skills/openprd-harness/SKILL.md

@@ -124,7 +124,7 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 - 当需求模糊、起点只有一句想法，或需要先做方案探索时，先查看生成的 `intake-reflection.md`，把用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针整理成首轮项目画像；Agent 选择最可逆的默认方案继续，把假设和验收方式说清楚，不把 OpenPrd 摘要变成用户确认门禁；不要生成或打开澄清 HTML
 - Agent 在对话里先用业务和产品语言复述：这次主要给谁、什么场景、先解决什么、先不碰什么、不能影响什么、会带来哪些业务风险。默认先追问 1 个最高价值问题，而不是一次性抛一整墙技术问题。
 - `需求判断` 和 `需求理解` 先用 1 到 2 句轻量主句说清结论：这次是什么、核心问题在哪里、第一版先做到什么；边界、风险、异常例子和技术细节下沉到后续分项或表格，不要揉成一大段重话。
-- 如果当前还是 L2 的首轮澄清或 requirement 摘要确认阶段，只能承诺“我先整理需求摘要给你确认，确认后再进入 PRD / review 流程”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现压成一步。
+- L2 的 requirement 摘要和 PRD/review 流程由 Agent 后台完成；用户已要求实现时继续推进，不创建确认停顿。
 - 如果 `openprd run . --context` 仍然建议 `clarify-user`，这轮回复的目标就只能是 `需求摘要` 或 `1 个最高价值澄清点`；不要写“我先按默认方案实现”或类似承诺。
 - `面向个人消费者场景 / 面向企业服务场景 / 以 Agent 为主要使用场景` 不是只给后面 PRD 用的模板方向；澄清阶段就要前移场景视角。面向个人消费者场景更看首次场景、用户感受和回访动力；面向企业服务场景更看拍板方、使用方、推进方和上线阻力；Agent 场景更看自主边界、人工兜底和失败恢复。
 - 当用户一开始不想讲太细时，可以先给 2 到 3 个方向和取舍供用户选，不要逼用户先回答完整 schema。
@@ -156,7 +156,7 @@ description: 驱动 OpenPrd 工作区完成从澄清到 handoff 的主流程。
 - 用户想在交互稿上圈选、批注或做视觉级反馈时，引导走画布评审协同：画布右栏顶部“评审协同”区显示当前 7 步流程位置，“导入评审方向”会把当前 review 的 designDirections 连图带说明摆上画布（已选定方向会标出），用户圈选批注后用“发送给 Codex”回传反馈
 - 用户问“现在到哪一步了”“接下来做什么”“OpenPrd 到底是干嘛的”时，先运行 `openprd guide <path>`：它按工作区状态输出 7 步流程（需求澄清 → 需求摘要 → 评审确认 → 交互方向选择 → 任务拆解 → 实现执行 → 验证收口）、当前位置和下一步动作，用它的输出向用户解释，不要口头即兴复述流程
 - 把生成的 `review.html` 当作稳定评审 artifact，但它是 Agent 后台维护和用户随时可看的结果，不是授权门禁。Agent 用精确 `--version`、`--digest`、`--work-unit` 记录当前稳定 artifact，自行完成 requirement 写回、classify/synthesize、review、change 和 tasks；不得要求用户批准摘要、评审稿或执行清单，也不得因这些材料尚未完成阻断用户已经要求的实现
-- 在 L2 的 requirement 摘要确认前，不要承诺“确认后我就开始实现”；正确顺序是：先确认摘要，再写回事实、进入 classify/synthesize/review，review 和 tasks 就绪后才谈执行。
+- L2 由 Agent 自动完成摘要、事实写回、classify/synthesize/review 和 tasks，再继续用户要求的执行；这些材料不是授权门禁。
 
 ### 6. 需要时生成可视化评审产物
 

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

@@ -77,7 +77,7 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 - 给 3-5 行 mini-plan。
 - 明确范围内、范围外和验证方式。
 - 默认先用业务/产品语言复述需求，再只追问 1 个最高价值问题；不要上来抛技术字段墙。
-- 若是大界面改动，mini-plan 之后先做 3 方向效果图评审，用户确认方向后再实现。
+- 若是大界面改动，mini-plan 之后主动做 3 方向效果图评审，并采用最可逆、最贴近现有视觉 DNA 的方向继续实现；用户主动选择时再覆盖默认方向。
 - 用户已明确要求执行时可继续实现。
 - 不生成正式 PRD，除非 mini-plan 暴露出新的决策缺口。
 
@@ -89,16 +89,15 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
 - 其他 L2 默认先运行或建议 `openprd clarify .`。
 - 先建立首轮项目画像：用户群体、产品形态、第一版切片、暂不处理、不能破坏和风险探针。
 - 对话内 requirement 摘要除了常规的用户、范围、风险，还要主动抬出“第一批最容易先找谁验证、你为什么算这个社区里的自己人、用户现在怎么解决、这个 workaround 到底有多痛、先怎么手工交付、手工作战卡怎么写、第一版只做哪一件事、能不能压成周末级 MVP、能不能先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律、验证阶段怎样先活下来，以及这条路是否可逆、是否真在解决客户问题、是否符合团队价值观、是不是你愿意长期住进去的业务形态”。
-- 再用对话内结构化摘要确认需求，默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”的顺序来写，其中“功能范围”和“技术方案”优先用 Markdown 表格。
+- 再由 Agent 在后台维护结构化需求摘要，默认按“需求判断 / 需求理解 / 功能范围 / 技术方案”的顺序来写，其中“功能范围”和“技术方案”优先用 Markdown 表格；摘要用于提高执行精度，不创建用户确认停顿。
 - `需求判断` 和 `需求理解` 先轻后重：先用轻量主句给用户一个一眼能懂的结论，再把边界、风险和技术细项下沉到后续表格或分项里；不要把它们揉成一大段说明。
 - 如果 L2 摘要正在解释新流程、新角色关系、状态机、前后方案差异、依赖边界或失败恢复路径，先用解释型 SVG 图降低理解成本，再用表格承接范围和技术分工。
-- 优先由 Agent 先归纳，再请用户确认；默认先问 1 个最高价值问题，必要时再给 2 到 3 个方向和取舍供用户选，不要一次砸一整墙问题。
-- 当前还是 L2 的首轮澄清或 requirement 摘要确认阶段时，只能承诺“我先整理需求摘要给你确认”；不要写成“你回我一句我就开始实现”，也不要把 requirement 摘要确认、review 和实现压成一句话。
-- 单纯的“请帮我实现/继续实现”只表示用户希望最终落地，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。
+- 优先由 Agent 归纳并选择最可逆的合理默认方案；仅在缺失信息确实无法安全推断时自然追问，不得因为 OpenPrd 流程材料要求用户确认。
+- L2 的 requirement 摘要、review、change 和 tasks 全部由 Agent 后台维护；用户要求实现或继续时直接推进，不要求回复固定信息、批准摘要或补执行授权。
 - 用户侧表达优先使用业务和产品语言，强调谁在什么场景下解决什么问题、会获得什么收益、要承担什么业务风险；避免过早暴露前端/后端/数据库这类技术黑话。
-- 使用 `openprd capture . --field ...` 只写回已确认事实；`agent-normalized` 仅用于无语义变化的内部措辞整理，不替代用户确认。
+- 使用 `openprd capture . --field ...` 写回用户原话、项目证据或 Agent 明示的可逆假设，并准确标注来源；不得把 capture 变成用户门禁。
 - 选择并记录产品类型：`openprd classify . <consumer|b2b|agent>`；无法判断时保持 `base`。
-- requirement 摘要确认后，再进入 `openprd classify .`、`openprd synthesize .`、review artifact、change 和 tasks。
+- requirement 摘要形成后，由 Agent 自动继续 `classify`、`synthesize`、review artifact、change 和 tasks。
 
 ## PRD 场景视角
 

package/skills/openprd-shared/SKILL.md

@@ -127,7 +127,7 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
    - 直接处理通常包括空格、错别字、按钮文案、简单样式、明确 bugfix 和低风险局部调整；直接执行，完成后说明变更和验证。
    - 现有功能优化有明确落点但影响多个文件或行为；先给对话内 mini-plan，再实现和验证。
    - 如果用户刚刚已经确认了现有功能优化（L1）的 mini-plan、范围边界或正式产品边界，后续承接要明确写成“已确认，我按这个继续/收口/落地”，不要只写一个“确认”，也不要写成“确认，我们就按这个……”这种像再次索取确认的句子。
-- 新功能/新流程方案包括新产品、模块、流程、权限、计费、AI/第三方集成、云服务、跨系统、数据迁移或边界不清的需求；先走 requirement intake、对话内 requirement 摘要确认、review、change 和 tasks，再实现。
+- 新功能/新流程方案包括新产品、模块、流程、权限、计费、AI/第三方集成、云服务、跨系统、数据迁移或边界不清的需求；requirement intake、摘要、review、change 和 tasks 由 Agent 后台维护，不阻断用户要求的实现。
 - 对话内 requirement 摘要保持原有“需求判断 / 需求理解 / 功能范围 / 技术方案”结构，但 `需求判断` 和 `需求理解` 先用轻量主句说清结论；边界、风险、异常例子和技术细节下沉到后面的分项或表格，不要把它们挤成一大段。
 - 对于 L2 或脑暴诉求，默认再补一层“创业验证闭环”：第一批最容易触达的人群/社区、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先不做完整产品时的手工路径、手工作战卡、一件事 MVP、周末级验证、能否先用 spreadsheet / 表单 / no-code 跑起来、如果必须开始做产品也只自动化最重复的一步并先压成 forms / lists / CRUD 骨架、第一批客户路径、从第一个客户开始怎么收费、客户 1 如何打平成本、有没有 10 个样本和更强付费信号、达到什么条件才允许产品化、增长阶段守什么纪律，以及验证阶段怎样先活下来、这条路是否可逆、是否真在解决客户问题、是否符合团队价值观，以及这是不是你愿意长期住进去、不会反过来绑住团队的业务形态。
 - 历史 active change 在新 requirement intake 激活时只作为提醒，不抢当前主线。
@@ -167,7 +167,7 @@ description: OpenPrd 工作区与产物的共用守则。凡是需要查看、
 
 - 当用户要求“看看、规划、梳理、分析、评估、explain、review”或列出影响文件时，保持只读。此时只基于证据回答，不运行 `openprd loop --run`、`openprd tasks --advance`、`openprd discovery --advance`、commit、push 或其他写入命令。
 - 只有当当前用户消息明确要求开发、实现、修复、继续任务、深度调研、对标复刻或提交时，才执行 OpenPrd loop、task 或 discovery 推进。
-- 单纯的“请帮我实现/继续实现”只表示有执行意图，不表示可以跳过 requirement 摘要确认、`capture/classify/synthesize` 写入路径或 review；只有用户明确表示“不需要进行任何确认”时，才允许静默走完整 requirement write path。
+- “请帮我实现/继续实现”就是执行意图；Agent 静默完成 requirement、capture/classify/synthesize 和 review 维护，不追加 OpenPrd 确认门禁。
 - 声称实现就绪前，要说明文档影响检查是新增、更新，还是有意保持 `docs/basic/`、文件说明书和文件夹 README 不变。
 - 用户要求生成图片、封面图、配图、海报、插画、图标、贴纸、头像、banner、主视觉/KV、运营图、效果图、视觉稿、mockup、先看样子或先确认设计方向时，最终回复应给出 `imagegen` 生成的图片结果；只有实际发生 `imagegen` 调用后，才能汇报生图结果、失败或限流。Image 2 是工具路径，不是审美豁免；最终回复要能说明候选图是否满足用途、受众、气质和记忆点。生图结果先当候选效果图，并主动确认是否符合预期、是否纳入后续效果图/实现截图对比、以及是否按此继续实现。进入实现阶段后，已有确认参考图才给出 `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 路径；普通截图实测补 `openprd visual-compare --board <verification-board.json>`，同构列表、卡片、网格、表格或用户反馈没对齐时补 `openprd visual-compare --board <alignment-board.json>`，并说明相同槽位 spread 是否仍有偏差；最终同时说明是否仍有结构、气质、层级、颜色、字号、间距或记忆点差异。
 - 大界面改动应给出 3 方向横向候选效果图大图；Agent 可选最符合目标且可逆的方向继续，OpenPrd 不强制等待确认。用户明确选择时优先采用用户方向。

package/src/agent-canonical-content.js

@@ -168,12 +168,12 @@ export 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 探索、脑暴或值不值得做的判断，摘要里还要主动补上“验证与创业闭环”：第一批最容易触达的社区或种子用户、你为什么算这个社区里的自己人、当前替代方案和痛点证据、先怎么手工交付、手工作战卡怎么写、能不能先用 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 就绪后可直接进入执行；否则在请求执行授权前，先输出执行确认清单，列出本轮目标、将执行内容、不做事项、验证方式和已知风险，不能只要求用户回复一句确认。',
+      '- 需求分流优先使用 `$openprd-requirement-intake`，不要按固定关键词判断。直接处理=L0，可直接执行；现有功能优化=L1，用简短 mini-plan 承接；新功能/新流程方案=L2，由 Agent 在后台维护 requirement、PRD、review、change 和 tasks。L2 摘要按“需求判断 / 需求理解 / 功能范围 / 技术方案”组织，并在 0 到 1 场景补充创业验证闭环：第一批最容易触达的人群/社区、你为什么算这个社区里的自己人、手工作战卡、第一版只做哪一件事、forms / lists / CRUD、什么真实承诺才算真需求、有没有 10 个样本和更强付费信号、客户 1 如何打平成本、达到什么条件才允许产品化、验证阶段怎样先活下来、增长阶段守什么纪律，以及是不是愿意长期住进去的业务形态。用户要求实现或继续时，Agent 选择最可逆的合理默认方案推进，并明示关键假设；OpenPrd 不要求用户批准摘要、评审稿、执行清单或回复固定信息，也不因内部材料缺失阻断实现。',
       '- 涉及最佳实践、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。',
       '- 任务需要 API key、token、账号信息、第三方服务凭证或个人信息时，先使用 `secrets-vault` skill，且不要直接读取原始 vault 文件。',
-      '- 修改 skill、`SKILL.md`、`AGENTS.md` 或相关 workflow 前，先读取现状、输出彩色 Mermaid 方案图，并等待用户确认后再编辑相关文件。',
+      '- 修改 skill、`SKILL.md`、`AGENTS.md` 或相关 workflow 前先读取现状，并用彩色 Mermaid 说明变化；该图用于提高可理解性，不是 OpenPrd 用户确认门禁，用户已经要求修改时继续执行。',
       '- 涉及微信小程序测试、验证、截图、日志、网络请求、开发者工具自动化或运行态相关改动时，先判断是否真的需要运行态证据：只有用户明确要求小程序实测、复现、截图、抓日志/网络、从 0 到 1 走流程，或当前改动高风险到无法靠静态检查、单测、代码审查或现有证据确认时，才升级到本地小程序运行态验证；低风险小改、纯文案、局部样式或可由更轻验证覆盖的改动，默认不要自动触发小程序运行态验证。',
       '- 一旦进入小程序运行态验证，默认沿用当前小程序运行态或开发者工具会话连续验证，不要为了验证自动重开应用；只有用户明确要求从 0 到 1、冷启动、重开或重新打开时，才从头启动。',
       '- 一旦进入小程序运行态验证，优先使用当前环境已配置的小程序本地验证能力；如果当前客户端没有相应工具，不要假定已经安装，也不要把缺少工具本身当成任务失败。未拿到本地运行态证据前，不要宣称“小程序已验证”。',
@@ -356,7 +356,7 @@ export const CANONICAL_SKILLS = [
       '## hook 驱动循环',
       '',
       '- 把 `.openprd/harness/run-state.json` 和 `iterations.jsonl` 当成持久循环状态。',
-      '- 默认 lite hooks 不记录每一轮工具细节，但会在明确 OpenPrd / 深度工作提示词和产品、模块、流程需求下注入上下文；复杂或模糊需求提示先做三轮 Requirement Intake Reflection，轻量写入门禁会阻断过早改代码；本轮准备结束时再通过 `Stop` 做一次轻量项目经验回顾，并要求 Agent 先用人话明确“这条经验只会保留在当前项目里”，再向用户确认是否保留。',
+      '- 默认 lite hooks 不记录每一轮工具细节，但会在明确 OpenPrd / 深度工作提示词和产品、模块、流程需求下注入上下文；复杂或模糊需求由 Agent 在后台完成 Requirement Intake Reflection，不阻断用户要求的实现；本轮结束时通过 `Stop` 生成当前项目候选经验，不要求用户确认。',
       '- 只有项目确实需要完整遥测时才使用 `--hook-profile full`。',
       '- 上下文注入后，hooks 会从 OpenPrd 状态里推荐下一项 task、discovery 或 workflow 动作。',
       '- 门禁失败时，任务或覆盖项保持未完成状态，让下一轮继续重试。',

package/src/agent-integration.js

@@ -600,7 +600,7 @@ async function renderSkill(skill, projectRoot) {
     `description: ${source.description}`,
     '---',
     '',
-    source.body,
+    sanitizeWorkflowGateCopy(source.body),
   ];
   if (skill.id === 'openprd-benchmark-router' && projectRoot) {
     sections.push('', await renderApprovedBenchmarkRegistrySection(projectRoot).catch(() => ''));
@@ -608,6 +608,15 @@ async function renderSkill(skill, projectRoot) {
   return sections.join('\n');
 }
 
+function sanitizeWorkflowGateCopy(body) {
+  return String(body)
+    .replace(/L2 的首轮澄清只能承诺[^。]+。/g, 'L2 的需求摘要由 Agent 后台维护，不创建用户确认停顿。')
+    .replace(/默认 approval policy 是 decision-points[^。]+。/g, '默认 approval policy 是 agent-maintained：稳定评审材料由 Agent 后台记录，不要求用户批准。')
+    .replace(/若用户原始意图已明确要求实现[^。]+。/g, '用户原始意图要求实现或继续时，Agent 完成后台材料后直接执行，不追加执行授权。')
+    .replace(/确认该 requirement 摘要后[^。]+。/g, '形成 requirement 摘要后，由 Agent 自动写回事实并继续 classify、synthesize、review、change 和 tasks。')
+    .replace(/不要把“可以开做”[^。]+。/g, '用户要求实现或继续时，Agent 在后台记录 review 并继续当前任务。');
+}
+
 async function listFilesRecursive(rootDir) {
   const entries = await fs.readdir(rootDir, { withFileTypes: true }).catch((error) => {
     if (error?.code === 'ENOENT') return [];

package/src/codex-hook-runner-template.mjs

@@ -3546,7 +3546,7 @@ function currentRequirementMessage(intent, gate, progress) {
       : '需求入口: 先做轻量项目映射，再确认影响点和验收方式。',
     '当前 approval policy: agent-maintained。需求摘要、稳定评审记录、change 和 tasks 由 Agent 在后台维护；用户要求实现或继续时，不再要求额外确认口令、digest、work-unit id 或命令。',
     intent?.reviewContinuationRequested
-      ? '这条消息同时表达了“确认当前稳定评审稿并继续当前 OpenPrd 下一步”的意图：先记录精确 review artifact，再继续当前 lane；如果 review 后 tasks 已就绪但还需要执行授权，立刻展示执行确认清单，不要停在“如果你要我继续”。'
+      ? '这条消息表达了继续当前 OpenPrd 下一步的意图：在后台记录精确 review artifact 并继续当前 lane，不追加执行确认清单或固定口令。'
       : '',
     currentRequirementStatusLine(gate, progress),
     'Decision-point order: Agent 先吸收用户原始意图并继续当前安全范围内的工作，同时在后台补写需求事实、PRD、评审记录、change 和 tasks；材料不完整时记录缺口，不中断用户任务。',
@@ -4543,7 +4543,7 @@ function handle(eventName, cwd, payload) {
             const userFacingMessage = String(parsedReview.userFacingExperience?.message || '').trim();
             return allowHook([
               'OpenPrd 在本轮收工回顾里发现了一条适合沉淀为当前项目经验的内容。',
-              '请在最终回复结尾主动用下面这段结构化人话询问用户，不要改成内部术语，也不要提 Draft Skill、candidate、promote、路径或命令：',
+              '把它作为当前项目的后台候选经验记录，不要在最终回复中要求用户确认，也不要提 Draft Skill、candidate、promote、路径或命令：',
               userFacingMessage || [
                 '这次我观察到一个以后可能重复出现的情况：',
                 '这次任务里已经形成了一种以后可能重复出现的处理方式。',
@@ -4553,11 +4553,9 @@ function handle(eventName, cwd, payload) {
                 '',
                 '以后如果再遇到类似任务，我会优先按这套经验来处理，减少重复解释和重复判断。',
                 '这条经验只会保留在当前项目里。',
-                '要我把它一起保留下来吗？',
+                '已作为当前项目候选经验记录，不影响当前任务。',
               ].join('\n'),
-              parsedReview.suggestedLearnCommand
-                ? `如果用户明确同意，再执行：${parsedReview.suggestedLearnCommand}`
-                : null,
+              null,
               `如果用户明确表示暂不保留，执行：openprd knowledge reject --path . --id ${parsedReview.candidateId} --reason "<用户原话>"`,
               `如果用户表示先不处理、以后再说，执行：openprd knowledge archive --path . --id ${parsedReview.candidateId} --reason "<用户原话>"`,
             ].filter(Boolean).join('\n'));

package/src/knowledge.js

@@ -1283,7 +1283,7 @@ function plannedExperienceFromContext({ source, categories, touchedFiles }) {
   const touchesDocs = touchedFiles.some((file) => String(file).startsWith('docs/basic/'));
   const touchesTests = touchedFiles.some((file) => /^(test|tests)\//.test(String(file)));
   if (categories.includes('agent-misjudgment')) {
-    return '以后做类似任务收尾时，我会先把本次情况、准备保留的经验和适用场景整理清楚，再用人话确认是否保留为当前项目经验。';
+    return '以后做类似任务收尾时，我会把本次情况、可复用经验和适用场景整理为当前项目的候选经验，不打断用户当前任务。';
   }
   if (categories.includes('hidden-debug-knowledge')) {
     return '以后再遇到类似问题时，我会优先复用这次已经验证过的判断依据、排查顺序和收尾检查方式，而不是从零开始重新摸索。';
@@ -1332,8 +1332,7 @@ function buildKnowledgeUserFacingExperience({ candidate, source, touchedFiles, r
   const futureHandling = futureHandlingFromContext({ categories, touchedFiles });
   const scopeNote = '这条经验只会保留在当前项目里。';
   const reviewStateNote = knowledgeReviewStateNote(candidate.status);
-  const shouldAskUser = normalizeCandidateStatus(candidate.status) === 'pending-review';
-  const question = shouldAskUser ? '要我把它一起保留下来吗？' : null;
+  const question = null;
   const messageLines = [
     '这次我观察到一个以后可能重复出现的情况：',
     observedSituation,