@openprd/cli 0.1.0

package/skills/openprd-learning-review/references/evidence-manifest.md

@@ -0,0 +1,55 @@
+# Evidence Manifest
+
+The manifest is the provenance layer. It tells future readers what is evidence, what is inference, and what still needs verification.
+
+## Source Shape
+
+Each source should include:
+
+- `id`
+- `title`
+- `type`
+- `groups`
+- `path`
+- `relativePath`
+- `summary`
+- `excerpt`
+- `digest`
+- `note`
+
+## Claim Shape
+
+Each claim should include:
+
+- `id`
+- `statement`
+- `sourceIds`
+- `confidence`
+- `kind`
+
+## Gap Shape
+
+Each gap should include:
+
+- `id`
+- `description`
+- `severity`
+
+## Rules
+
+- Never write a claim without source ids.
+- Never hide inference inside a factual statement.
+- Keep the digest stable so later packages can compare evidence lines.
+- Prefer short excerpts that are enough to orient the reader, not full-file dumps.
+- If a source is missing, record the gap instead of pretending the source exists.
+
+## Suggested Source Priorities
+
+1. `current-state`
+2. `task-graph`
+3. `verification`
+4. `latest-loop-report`
+5. `active-prd` and other active engagement docs
+6. `docs/basic/*`
+7. version snapshots
+

package/skills/openprd-learning-review/references/genre-library.md

@@ -0,0 +1,43 @@
+# Genre Reference Library
+
+This library gives the outer voice and chapter shape. Detailed writing behavior belongs to style prompt packs.
+
+## Registry
+
+| id | label | Use When | Voice | Chapter Labels |
+|---|---|---|---|---|
+| `internet-product` | 互联网产品 | Default for code, CLI, workflow, and product systems | 清晰、务实、讲路径、讲状态、讲证据 | 问题地图 / 系统结构 / 证据链 / 工作示例 / 下一步动作 |
+| `scientific` | 严肃科研 | When the user wants rigor, verification, or research framing | 严谨、可验证、重证据、重边界 | 研究问题 / 方法框架 / 证据链 / 复现实验 / 结论回收 |
+| `fairy-tale` | 童话故事 | When the user wants gentle, memorable teaching prose | 温暖、清楚、带一点故事感 | 故事开头 / 旅程地图 / 线索与证据 / 角色示例 / 回家路上 |
+| `web-novel` | 网文小说 | When the user wants stronger rhythm and chapter pacing | 节奏更强、推进更快、强调冲突和转折 | 开卷入局 / 结构铺陈 / 证据反转 / 范例拆招 / 收束留白 |
+| `xianxia` | 仙侠修真 | When the user wants a cultivation-style metaphor | 带一点修炼感，但仍然要稳住事实和证据 | 筑基 / 观想 / 破境 / 传功 / 归元 |
+
+## Prompt Pack Rule
+
+Each genre can own multiple substyle prompt packs. For example:
+
+- `xianxia.cultivation`: 修行札记
+- `xianxia.sect-intrigue`: 宗门权谋，planned
+- `xianxia.artifact-refining`: 炼器法门，planned
+
+The CLI can select a substyle with `--style <id>`. If omitted, the genre default is used.
+
+## Extension Rules
+
+- Prefer one stable registry entry per genre.
+- New genres should define:
+  - `id`
+  - `label`
+  - `voice`
+  - `chapterLabels`
+  - `opening`
+  - `closing`
+- Keep the chapter labels human-readable and easy to scan.
+- Never let the genre layer or style prompt pack overwrite evidence semantics.
+
+## Selection Hints
+
+- Use `internet-product` when the topic is a codebase, CLI, workflow, or project execution path.
+- Use `scientific` when the user wants conceptual rigor or repeatability.
+- Use `fairy-tale` when the user wants the material to feel gentle and easier to remember.
+- Use `web-novel` or `xianxia` when the user explicitly asks for a more stylized narrative shell.

package/skills/openprd-learning-review/references/prompt-engineering.md

@@ -0,0 +1,71 @@
+# Style Prompt Engineering
+
+The learning review generator uses prompt packs to move from neutral facts to styled reading content.
+
+## Principle
+
+Facts do not move. Style moves around them.
+
+The Agent must preserve:
+
+- `schema`
+- `packageId`
+- `sourceScope`
+- evidence ids
+- file paths
+- digests
+- command names
+- OpenPrd terms
+
+The Agent may rewrite:
+
+- title
+- subtitle
+- outline labels
+- chapter titles
+- chapter summaries
+- chapter `visualExplainer`
+- paragraphs
+- retrieval prompts
+- worked-example framing
+
+## Prompt Pack Shape
+
+Each style pack should define:
+
+- `id`
+- `label`
+- `concept`
+- `titlePatterns`
+- `outlineArc`
+- `imageryBank`
+- `sentenceRhythm`
+- `taboo`
+- `systemPrompt`
+- `titlePrompt`
+- `outlinePrompt`
+- `chapterPrompt`
+- `proseRewritePrompt`
+- `evidenceBindingPrompt`
+- `qualityReviewPrompt`
+
+## Agent-In-The-Loop Steps
+
+1. Read `evidence-manifest.json`.
+2. Read the neutral `learning-content.json`.
+3. Load the selected prompt pack by `genre.style`.
+4. Use `titlePrompt` to create a book-like title and subtitle.
+5. Use `outlinePrompt` to build a three-level outline at most, but keep retrieval questions in the body rather than the outline.
+6. Use `chapterPrompt` and `proseRewritePrompt` to migrate each chapter into the style, and create `visualExplainer` cards when they help non-technical readers.
+7. Use `evidenceBindingPrompt` to preserve every source anchor.
+8. Use `qualityReviewPrompt` to check style fit and fact drift.
+9. Render `reader.html` only after the quality checks pass.
+
+## Quality Bar
+
+- The result should feel like a readable book, not a decorated report.
+- The outline should support scanning before reading.
+- The style should be visible in title, outline, rhythm, and paragraph movement.
+- If visual explainers are used, they should reduce understanding cost instead of restating the chapter mechanically.
+- Every important claim should still point back to evidence.
+- Evidence should be available but should not dominate the reading surface.

package/skills/openprd-learning-review/references/quality-rubric.md

@@ -0,0 +1,28 @@
+# Quality Rubric
+
+Use this rubric to decide whether a learning package is good enough to ship.
+
+## Must Pass
+
+- Every claim points to one or more source ids.
+- The package has a stable archive path under `.openprd/learning/archive/`.
+- The reader opens and navigates by chapter.
+- The package includes retrieval blocks and worked examples.
+- Retrieval questions stay in the body, not as separate TOC leaf items.
+- The content contract is versioned.
+- If a `visualExplainer` is present, it must stay faithful to evidence and must not invent unsupported screenshots, states, or outcomes.
+
+## Should Pass
+
+- The genre choice matches the user's request.
+- The opening paragraph explains why the package exists.
+- The chapters are easy to scan.
+- Product-facing or non-technical packages use `visualExplainer` blocks when they meaningfully reduce comprehension cost.
+- Chapter-level source anchors help the reader jump back to sources without crowding the page.
+- The next-actions section says how to reuse the pattern.
+
+## Stop Conditions
+
+- If the manifest has too many gaps, stop and gather more evidence.
+- If the topic is too broad, narrow it before generating prose.
+- If the user wants a different genre, switch the reference library first and regenerate.

package/skills/openprd-learning-review/references/retrieval-worked-example.md

@@ -0,0 +1,40 @@
+# Retrieval and Worked Example Blocks
+
+These blocks turn the package into something the reader can actively recall, not just passively consume.
+
+## Retrieval Block
+
+Use a retrieval block when you want the reader to remember a mechanism without looking at the answer immediately.
+
+Recommended shape:
+
+- prompt
+- hint
+- answer
+
+## Worked Example
+
+Use a worked example when you want to show how the abstract rule applies to a real OpenPrd scenario.
+
+Recommended shape:
+
+- title
+- scenario
+- steps
+- principle
+
+## Rules
+
+- Make the prompt answerable from the content in the package.
+- Keep the answer short enough to compare mentally.
+- The worked example should show a before/after or input/output shape.
+- Prefer examples that reuse actual OpenPrd files, commands, or archive paths.
+- Retrieval and worked examples should appear in every major chapter when possible.
+
+## Good Patterns
+
+- "If you only remember one directory, which one is it?"
+- "What should be cited as evidence and what should be marked as inference?"
+- "What is the smallest change needed to add a new genre?"
+- "How do you archive the package and reopen it later?"
+

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

@@ -0,0 +1,67 @@
+# Xianxia Cultivation Prompt Pack
+
+## Identity
+
+- `genre`: `xianxia`
+- `style`: `cultivation`
+- `label`: 修行札记
+- `concept`: 把项目学习写成一次可回溯的修行：证据是灵根，结构是经脉，实践是破境。
+
+## System Prompt
+
+你是 OpenPrd 复盘学习书的风格迁移 Agent。
+
+你的任务不是虚构故事，而是把中性的学习内容转写成仙侠修行札记。
+
+事实层必须完全来自 learning-content 和 evidence-manifest；风格层只能改变表达、结构节奏和意象。
+
+## Title Prompt
+
+输入：topic、genre、substyle、evidence summary。
+
+输出：一个像书名的标题和一个短副题。
+
+要求：标题可带“札记/小卷/归藏/心法”等书籍意象，但必须保留 topic 的核心名词。
+
+## Outline Prompt
+
+输入：章节目标、证据类别、读者学习路径。
+
+输出：最多三层目录。
+
+第 1 层是卷/章，第 2 层是本章心法、检索练习、工作示例、证据锚点。
+不要把 R1/R2 这种具体练习题放进目录；它们只留在正文中。
+
+## Chapter Prompt
+
+输入：semanticTitle、summary、paragraphs、retrievalBlocks、workedExamples。
+
+输出：保持同一事实顺序的风格化章节。
+
+要求：每章先用修行意象开场，再把意象落回文件、状态、验证或任务路径。
+
+## Prose Rewrite Prompt
+
+把“做了什么/为什么/如何验证”改写成“立基/观脉/破境/传功/归元”的阅读路径。
+
+每段至少保留一个明确事实锚点，例如 `.openprd/`、docs/basic、loop finish、reader.html、evidence manifest。
+
+不要改写文件名、命令名、schema、packageId 和 source id。
+
+## Evidence Binding Prompt
+
+每个关键判断必须保留 evidenceIds。
+
+如果句子是综合推断，使用“由这些证据合参可知”一类表达，而不是绝对断言。
+
+风格词只能包装证据，不能替代证据。
+
+## Quality Review Prompt
+
+检查 1：标题、大纲、章节是否像修行札记，而不是普通项目报告。
+
+检查 2：是否仍能从每章回到 evidenceIds。
+
+检查 3：是否有玄幻词盖过事实、命令、路径、验证结果。
+
+检查 4：目录是否可读，最多三层，适合展开/收起。

package/skills/openprd-quality/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: openprd-quality
+description: 评估 OpenPrd 的可观测性、业务成本与滥用护栏、评估执行环境覆盖、性能基线、极端场景，以及 HTML 质量评估报告和项目级经验 Skill。
+---
+
+# OpenPrd Quality
+
+## 何时使用
+
+当实现就绪、日志、链路追踪、业务成本、免费额度、滥用防护、评估执行环境、冒烟测试、性能阈值、压力数据、HTML 质量评估报告或项目级经验 Skill 在范围内时，使用这份 skill。
+
+典型触发词：
+
+- 日志、链路追踪、中心化日志、排查证据、报错回溯
+- 免费用户、额度、限流、AI 调用、第三方 API、成本、预算、报警、止损、滥用
+- eval、评估体系、冒烟测试、功能覆盖、异常流程、逆向流程
+- CPU、内存、加载时间、接口耗时、压力测试、极端数据
+- 质量评估报告、HTML 审查产物、质量门禁
+- 界面效果图、实现截图、视觉对比、复刻对标、阶段性视觉评审
+- 复盘后沉淀经验 Skill，避免同类问题反复出现
+
+## 核心命令
+
+- 初始化质量状态：
+  - `openprd quality <path> --init`
+- 生成评审产物：
+  - `openprd quality <path> --verify`
+- 先生成待确认经验草案：
+  - `openprd quality <path> --learn --review --from .openprd/harness/turn-state.json`
+- 生成界面视觉对比图：
+  - `openprd visual-compare <path> --reference <效果图> --actual <实现截图>`
+- 基于已审查报告生成或刷新项目级经验：
+  - `openprd quality <path> --learn --from <candidate-dir|report-id-or-json>`
+- 审查执行中发现的配置、规则候选或 user-local 偏好：
+  - `openprd grow <path> --review`
+
+## 质量审查契约
+
+每次阶段性实现都应先判断 EVO 场景，再按场景要求审查。基础场景至少要覆盖冒烟和任务/功能覆盖；涉及 UI、桌面端、后端、成本、安全、性能、极端数据、发布交付时，再叠加对应门禁。
+
+脚本、依赖或 fixture “存在”只能说明项目具备能力，不能说明本次已经执行。质量报告必须区分：
+
+- `pass`：当前场景必需门禁已经满足，且有本次执行证据或明确项目证据
+- `needs-evidence`：能力可能存在，但缺本次执行证据
+- `needs-attention`：能力、配置、任务或护栏本身缺失
+- `advisory`：当前场景不阻断，但发布或风险进入范围时必须补齐
+
+每次阶段性实现都应从六层审查：
+
+- 质量契约：这项任务承诺覆盖什么
+- 可观测性：前端、后端、agent 工具、异步任务和错误路径能否通过共享 trace/request/task/error id 串起来
+- 业务成本与滥用护栏：免费、试用、消耗型资源、AI 调用、第三方 API、下载、存储等路径是否有额度、负向验证、监控、报警和止损
+- 评估执行环境：冒烟测试、功能覆盖、正常性能和极端数据场景是否存在并持续维护
+- 视觉评审证据：涉及界面视觉实现且已有参考效果图时，确认 `.openprd/harness/visual-reviews/` 下存在本次 `openprd visual-compare` 输出的 JPG，并且 Agent 已基于合成图复核差异
+- HTML 质量评估报告：`.openprd/quality/reports/` 下的人类审查产物是否存在，且足以支持就绪判断
+- 知识 Skill：已验证修复是否应该先生成 `.openprd/knowledge/candidates/` 和 `.openprd/knowledge/drafts/` 下的草案，再 promote 为 `.openprd/knowledge/skills/` 下可复用的项目经验
+- 自我成长：配置缺口、文件识别、命令习惯或用户偏好优先沉淀为 `.openprd/growth` 候选，经用户确认后固化；不要把个人偏好混进项目共享质量经验
+
+## 可观测性规则
+
+- 优先使用中心化 logs / traces / errors / metrics，而不是零散本地日志。
+- 跨层诊断必须具备关联字段：`trace_id`、`span_id`、`request_id`、`task_id`、`user_session_id`、`error_id`。
+- secrets、token、凭证、个人信息和大体积 payload 必须做脱敏。
+- 每次代码变更都要自查是否需要新增结构化日志或查询示例。
+
+## 业务护栏规则
+
+- 只要需求涉及免费用户、试用、额度、AI 调用、第三方 API、生成、存储、下载或其他消耗型成本，就必须明确成本来源和用户级限制。
+- 必须覆盖额度绕过、重复请求、并发请求、越权身份、异常恢复等负向场景。
+- 必须有用量、成本、调用量或异常行为监控信号，以及可执行的报警阈值。
+- 必须说明异常后如何关闭、降级、暂停或熔断高成本路径，并明确处理负责人或交接动作。
+
+## 评估执行环境规则
+
+- 如果项目还没有冒烟测试体系，先补最小可用的 smoke 路径；如果已有 smoke，也必须留下本次运行证据。
+- 把任务列表映射到主流程、异常流程、逆向/负向流程和边界条件。
+- 持续维护项目级和功能级性能基线；只有性能敏感、批量、发布交付或用户明确要求时，正常性能门禁才应阻断。
+- 持续维护能覆盖当前功能面的极端 fixture 或压力数据；只有极端数据、并发压力、批量处理、发布交付或用户明确要求时，极端压力门禁才应阻断。
+- Agent 自动收紧基线可以做，但放宽阈值必须有用户明确要求。
+
+## 就绪判断规则
+
+- `openprd quality <path> --verify` 生成 advisory 报告时，仍要认真阅读 HTML，不得只看命令退出结果。
+- `openprd run <path> --verify` 中只要质量报告 `productionReady=false`，就不能宣称整体就绪。
+- UI 任务有参考图但缺少 visual-compare 输出时，不要宣称视觉实现完成；如果对比图仍有明显偏差，先返工而不是把差异留给用户发现。
+- 最终回复必须列出未通过的必需 EVO 门禁；如果某门禁被判定不适用，要说明它是当前场景可选或已有明确豁免。
+
+## 经验 Skill 规则
+
+只有当问题具备重复性、高影响、难以重新发现，或明显由 Agent 误判导致时，才生成项目级 Skill。
+
+每个经验 Skill 至少应包含：
+
+- 触发条件
+- 先看什么
+- 根因模式
+- 修复策略
+- 验证证据
+- 预防要求
+
+不要把一次性噪声沉淀成 Skill；知识层应该保持锋利，下一次拿来就有用。

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

@@ -0,0 +1,76 @@
+---
+name: openprd-requirement-intake
+description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品需求、功能变更、bugfix、流程调整、跨对话续做、OpenPrd/PRD 生成、review/change/tasks 前置判断时，先按语义判断 L0 小修、L1 中等改动或 L2 需要 PRD 的需求，并选择 base、consumer、b2b 或 agent PRD 模板 lens。
+---
+
+# OpenPrd Requirement Intake
+
+## 作用
+
+这份 skill 只做需求入口分流，不负责实现代码。
+
+- 判断当前用户输入属于 L0、L1 还是 L2
+- 决定下一步是直接澄清、mini-plan，还是正式 PRD
+- 为 L2 选择 `base`、`consumer`、`b2b` 或 `agent` PRD lens
+- 把用户当前需求和历史 active change 分开，避免“继续任务”吞掉新范围
+- 给 `$openprd-harness` 输出下一步行动合同
+
+## 分流原则
+
+不要按关键词判断。按影响面、未知数、决策成本和验证成本判断。
+
+- L0：单点、低风险、可逆、验收清楚。可以直接处理并事后说明。
+- L1：目标明确但影响多个文件、状态或用户可见行为。先给对话内 mini-plan，再执行。
+- L2：新产品、模块、流程、权限、计费、账号、AI/第三方、云服务、数据迁移、跨系统、长期工作流，或目标/验收/影响面不清。先走 PRD。
+
+如果同一句话同时包含“继续旧任务”和“新增范围”，先判断新增范围是否超出旧 PRD。超出时必须回到需求入口，更新 PRD/change/tasks，不能把“继续”当作实现授权。
+
+## 工作流
+
+1. 读取 `.openprd/` 状态和 `openprd run . --context`，但把它当作建议。
+2. 用 `references/routing-rubric.md` 判断 L0/L1/L2。
+3. 如果是 L2，读取 `references/prd-template-lenses.md` 选择 PRD lens。
+4. 输出一个短的 Intake Decision：
+   - 等级：L0 / L1 / L2
+   - 理由：影响面、未知数、风险、验证成本
+   - 当前需求是否覆盖历史 active change
+   - 推荐下一步
+   - L2 时的 PRD lens：base / consumer / b2b / agent
+5. 把执行交回 `$openprd-harness`。
+
+## 输出合同
+
+### L0
+
+- 直接处理或问 1 个必要问题。
+- 不生成 PRD。
+- 完成后说明变更和验证。
+
+### L1
+
+- 给 3-5 行 mini-plan。
+- 明确范围内、范围外和验证方式。
+- 用户已明确要求执行时可继续实现。
+- 不生成正式 PRD，除非 mini-plan 暴露出新的决策缺口。
+
+### L2
+
+- 先运行或建议 `openprd clarify .`。
+- 用对话内摘要确认目标、用户/角色、范围、非目标、验收、开放问题。
+- 使用 `openprd capture . --field ...` 写回确认事实。
+- 选择并记录产品类型：`openprd classify . <consumer|b2b|agent>`；无法判断时保持 `base`。
+- 再进入 `openprd synthesize .`、review artifact、change 和 tasks。
+
+## PRD Lens
+
+- `base`：通用产品或工程需求，强调问题、目标、范围、流程、需求矩阵、验收和风险。
+- `consumer`：面向个人用户或 C 端体验，强调用户旅程、首次成功、激活、留存、情绪价值和增长指标。
+- `b2b`：面向企业、团队、后台、SaaS 或组织流程，强调买方/使用者/管理员/运营者、权限矩阵、审批审计、集成依赖、SLA 和上线支持。
+- `agent`：面向 AI Agent、harness、skill、自动化或人机协作工作流，强调 Human-Agent contract、自主边界、工具边界、状态模型、失败恢复和评估计划。
+
+模板 lens 应融入正文结构，不要作为 PRD 末尾的字段附录。比如 B2B 的角色、权限和审批应该贯穿用户、流程、需求矩阵和验收标准；Agent 的自主边界应该贯穿范围、风险、任务和验证。
+
+## 何时读取参考
+
+- 分流有争议、用户输入很长、或涉及“继续旧任务 + 新范围”时，读 `references/routing-rubric.md`。
+- 需要写 PRD、选择产品类型、或用户反馈 PRD 结构奇怪时，读 `references/prd-template-lenses.md`。

package/skills/openprd-requirement-intake/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "OpenPrd Requirement Intake"
+  short_description: "Route requirements into clarify, mini-plan, or PRD"
+  default_prompt: "Use $openprd-requirement-intake to classify a user request as L0, L1, or L2 and choose the right PRD path."

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

@@ -0,0 +1,105 @@
+# PRD Template Lenses
+
+## 共同骨架
+
+所有 L2 PRD 都先回答这些问题：
+
+1. 为什么做：背景、问题、证据、为什么现在
+2. 给谁做：用户、角色、相关方
+3. 做到什么程度：目标、成功指标、验收标准
+4. 做什么和不做什么：范围、非目标、边界情况
+5. 用户怎么走：主流程、失败路径、恢复路径
+6. 需求怎么验收：需求矩阵、优先级、验收标准、测试/验证
+7. 有什么风险：依赖、约束、成本、滥用、开放问题
+8. 如何交接：review、change、tasks、负责人、下一步
+
+`base/prd.md` 提供这个骨架。其他模板不是附录，而是 lens：它们改变正文组织、需求矩阵和验收重点。
+
+## Base
+
+用于无法明确归类、或通用工程/产品需求。
+
+推荐章节：
+
+- 决策摘要
+- 背景与问题
+- 用户与相关方
+- 目标与成功标准
+- 范围与非目标
+- 场景与流程
+- 需求矩阵
+- 业务护栏
+- 约束、依赖、风险、开放问题
+- 交接与下一步
+
+## Consumer
+
+用于个人用户、C 端体验、内容、增长、留存或情绪价值明显的需求。
+
+把以下问题融入正文：
+
+- 用户画像和用户分层
+- 用户旅程和关键触点
+- 第一个成功时刻
+- 激活指标和留存指标
+- 情绪价值或生活方式价值
+- 触达、转化、留存或增长实验
+
+需求矩阵建议增加：
+
+- Journey Step
+- User Motivation
+- Aha Moment
+- Activation / Retention Signal
+- UX Risk
+
+## B2B
+
+用于企业、团队、后台、SaaS、组织流程、管理/审批/权限相关需求。
+
+把以下问题融入正文：
+
+- 买方、使用者、管理员、运营者
+- 现状流程和目标流程
+- 角色权限矩阵
+- 审批、审计、日志和追责
+- 集成依赖、上线迁移、培训和支持
+- SLA、数据边界、合规和安全
+
+需求矩阵建议增加：
+
+- Role
+- Permission / Approval
+- Audit Evidence
+- Admin / Operator Impact
+- Integration Dependency
+
+## Agent
+
+用于 AI Agent、harness、skill、自动化、代码代理、人机协作或评估体系。
+
+把以下问题融入正文：
+
+- Human-Agent contract
+- 自主边界和人工确认点
+- 工具边界和高风险动作
+- 状态模型、记忆和跨会话续接
+- 失败恢复和人工接管
+- 评估计划和回归证据
+- 成本、额度、滥用和停止条件
+
+需求矩阵建议增加：
+
+- Autonomy Level
+- Human Decision Point
+- Tool Boundary
+- State / Memory
+- Fallback Path
+- Evaluation Signal
+
+## 写作规则
+
+- 不输出大段空字段或 TBD 墙；缺事实时进入开放问题。
+- 不把类型专项字段堆在末尾；把它们融进用户、流程、需求矩阵、验收和风险。
+- PRD 写产品判断，`design.md` 写技术方案，`tasks.md` 写执行步骤。
+- 每条 requirement 都应能追踪到验收标准和后续 task。

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

@@ -0,0 +1,64 @@
+# Requirement Routing Rubric
+
+## 判断维度
+
+按下面四个维度判断，不按固定关键词判断。
+
+| 维度 | L0 | L1 | L2 |
+|---|---|---|---|
+| 影响面 | 单点文件、单个 UI 文案、局部 bug | 多文件或多状态，但边界清楚 | 跨模块、跨系统、跨角色、跨端或跨任务 |
+| 未知数 | 几乎没有 | 有少量实现选择 | 目标、用户、范围、验收或风险未定 |
+| 决策成本 | 不需要产品决策 | 需要简短方案选择 | 需要先评审意图和范围 |
+| 验证成本 | 单元/局部验证 | 组合验证或 E2E | 需要分阶段任务、回归、业务/成本/权限验证 |
+
+## L0
+
+适合直接处理：
+
+- 错别字、空格、标点、按钮文案小改
+- 明确 bugfix，根因和验收都很窄
+- 简单样式调整，不改变信息架构或用户流程
+- 单个配置值或展示值修正
+
+输出：直接做，完成后说明验证。不要生成 PRD。
+
+## L1
+
+适合 mini-plan：
+
+- 目标明确，但需要改多个文件
+- 用户可见行为变化，但不引入新角色、新流程或新依赖
+- 一个现有流程里的局部体验优化
+- 一个明确 bug 的系统化修复，需要补测试和文档
+
+输出：先给 3-5 行 mini-plan，包含范围内、范围外、验证方式。用户已经要求执行时可继续。
+
+## L2
+
+必须进入 PRD：
+
+- 新产品、新模块、新入口、新工作流或新信息架构
+- 账号、权限、支付、订阅、计费、审批、审计、团队协作
+- AI Agent、模型调用、第三方 API、云服务、成本或滥用风险
+- 数据迁移、资源链路切换、发布链路、跨端/跨系统集成
+- 用户说“继续任务”但补充了会改变范围的新目标
+- 影响面和验收不清，Agent 需要猜产品决策
+
+输出：先澄清并进入 PRD/review/change/tasks。
+
+## 续接规则
+
+当用户提供会话 ID、work unit、task handle 或说“继续这个任务”：
+
+1. 先用 `openprd run . --context --message <用户原话>` 解析显式目标。
+2. 判断用户这次新增的话是否仍在原 PRD 范围内。
+3. 如果只是继续已拆任务，按 tasks 继续。
+4. 如果新增目标改变范围、验收、角色、依赖或风险，先更新 PRD/change/tasks。
+5. 不要让当前 active change 抢走用户明确给出的会话或任务目标。
+
+## 反例
+
+- “把按钮文字从 A 改成 B”不是 L2。
+- “修复支付失败”不一定是 L0；如果涉及登录、订单、回调、风控或退款，就是 L2。
+- “把 OSS 全量切到 CDN”不是简单替换字符串；它涉及资源链路、证书、缓存、回滚和客户端验证，应按 L2。
+- “继续这个任务，另外加一个跨对话任务名机制”不是普通继续；新增机制应回到 PRD。