@openprd/cli 0.1.0 → 0.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md
CHANGED
|
@@ -12,7 +12,7 @@ OpenPrd is a lightweight **PRD harness** for teams and agents that need more tha
|
|
|
12
12
|
|
|
13
13
|
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.
|
|
14
14
|
|
|
15
|
-
|
|
16
16
|
|
|
17
17
|
## Why OpenPrd
|
|
18
18
|
|
|
@@ -70,21 +70,21 @@ and agents can look at the same artifact before work moves forward.
|
|
|
70
70
|
Use a review-ready PRD surface instead of asking teammates to reconstruct the
|
|
71
71
|
latest requirement state from chat history.
|
|
72
72
|
|
|
73
|
-
|
|
74
74
|
|
|
75
75
|
### Learning reader
|
|
76
76
|
|
|
77
77
|
Turn a finished requirement, fix, or workflow into a readable learning package
|
|
78
78
|
that new collaborators can study without replaying the whole thread.
|
|
79
79
|
|
|
80
|
-
|
|
81
81
|
|
|
82
82
|
### Quality regression report
|
|
83
83
|
|
|
84
84
|
Summarize readiness, required gates, evidence coverage, and manual decisions in
|
|
85
85
|
one human-readable quality surface before handoff, release, or publish.
|
|
86
86
|
|
|
87
|
-
|
|
88
88
|
|
|
89
89
|
### Auto-optimized reference-to-screenshot comparison
|
|
90
90
|
|
|
@@ -92,7 +92,7 @@ Put the reference and implementation into one side-by-side artifact for staged
|
|
|
92
92
|
UI review, especially for auth-entry redesign, localized legal pages, and modal
|
|
93
93
|
replication work.
|
|
94
94
|
|
|
95
|
-
|
|
96
96
|
|
|
97
97
|
## Self-Evolving Collaboration
|
|
98
98
|
|
|
@@ -101,7 +101,7 @@ keeps proven team habits as reusable `Project-Level Skill`s. The other keeps
|
|
|
101
101
|
`Dynamic Parameter Config` adaptive, so different project situations start with
|
|
102
102
|
different collaboration defaults instead of the same generic checklist.
|
|
103
103
|
|
|
104
|
-
|
|
105
105
|
|
|
106
106
|
### Scenario 1: Project-Level Skill
|
|
107
107
|
|
|
@@ -156,10 +156,10 @@ automatically.
|
|
|
156
156
|
|
|
157
157
|
## One-line Install
|
|
158
158
|
|
|
159
|
-
Install
|
|
159
|
+
Install from npm:
|
|
160
160
|
|
|
161
161
|
```bash
|
|
162
|
-
npm install -g
|
|
162
|
+
npm install -g @openprd/cli
|
|
163
163
|
```
|
|
164
164
|
|
|
165
165
|
Then verify:
|
|
@@ -516,7 +516,7 @@ and workspace validation are healthy. `update` refreshes the generated adapter
|
|
|
516
516
|
files from the canonical OpenPrd source while preserving unrelated user hook
|
|
517
517
|
groups.
|
|
518
518
|
|
|
519
|
-
`self-update` updates the OpenPrd CLI itself from the public
|
|
519
|
+
`self-update` updates the OpenPrd CLI itself from the public npm package.
|
|
520
520
|
`upgrade` composes the two update layers: it first runs `self-update`, then
|
|
521
521
|
re-resolves the installed `openprd` executable and runs either `update <project>`
|
|
522
522
|
or, with `--fleet`, `fleet <root> --update-openprd`. Both commands support
|
package/README_CN.md
CHANGED
|
@@ -18,7 +18,7 @@ OpenPrd 是一个轻量但结构化的 **PRD harness**。它不只是“生成
|
|
|
18
18
|
|
|
19
19
|
它把关键确认点沉淀成稳定的 HTML 产物，而不是把版本状态散落在聊天记录或终端输出里。
|
|
20
20
|
|
|
21
|
-
|
|
22
22
|
|
|
23
23
|
## 适合什么场景
|
|
24
24
|
|
|
@@ -68,31 +68,31 @@ OpenPrd 会生成可以直接分享的 HTML 面板，让产品、研发和 Agent
|
|
|
68
68
|
|
|
69
69
|
把当前需求版本整理成可评审页面，适合先给产品、研发或负责人确认“这次到底在做什么”。
|
|
70
70
|
|
|
71
|
-
|
|
72
72
|
|
|
73
73
|
### 学习阅读器
|
|
74
74
|
|
|
75
75
|
把一次需求、修复或协作方法整理成图文学习资料，方便新成员理解“这套流程为什么这样设计”。
|
|
76
76
|
|
|
77
|
-
|
|
78
78
|
|
|
79
79
|
### 质量回归报告
|
|
80
80
|
|
|
81
81
|
把准备就绪状态、必需门禁、验证材料和仍需人工判断的点放到一个可读页面里，再决定是否继续交付或发布。
|
|
82
82
|
|
|
83
|
-
|
|
84
84
|
|
|
85
85
|
### 效果图与截图拼图对比，自动优化
|
|
86
86
|
|
|
87
87
|
把效果图和实现截图放进同一张左右对比图里，适合登录入口改造、条款页本地化、弹窗复刻这类阶段性评审。
|
|
88
88
|
|
|
89
|
-
|
|
90
90
|
|
|
91
91
|
## 自我成长机制
|
|
92
92
|
|
|
93
93
|
OpenPrd 会沿着两条看得见的循环，越用越贴合你们的协作方式。一条循环把真实项目里反复验证过的做法沉淀成可复用的 `项目级 Skill`；另一条循环把不同场景下更合适的协作设置沉淀成 `动态参数配置`，让下次启动时直接带上更合适的默认做法。
|
|
94
94
|
|
|
95
|
-
|
|
96
96
|
|
|
97
97
|
### 场景一：项目级 Skill
|
|
98
98
|
|
|
@@ -131,7 +131,7 @@ OpenPrd 会沿着两条看得见的循环，越用越贴合你们的协作方式
|
|
|
131
131
|
## 一句话安装
|
|
132
132
|
|
|
133
133
|
```bash
|
|
134
|
-
npm install -g
|
|
134
|
+
npm install -g @openprd/cli
|
|
135
135
|
```
|
|
136
136
|
|
|
137
137
|
安装后验证：
|
|
@@ -452,7 +452,7 @@ openprd loop /path/to/project --run --agent codex --dry-run
|
|
|
452
452
|
|
|
453
453
|
`doctor` 会检查三端引导、Codex hooks 开关、项目标准化和 OpenPrd 工作区验证是否健康。`update` 会从 OpenPrd 的统一源刷新这些生成文件，并保留用户自己已有的 hook 分组。
|
|
454
454
|
|
|
455
|
-
`self-update` 只更新 OpenPrd CLI 自身，默认使用公开
|
|
455
|
+
`self-update` 只更新 OpenPrd CLI 自身，默认使用公开 npm 包。
|
|
456
456
|
`upgrade` 会编排两层更新：先执行 `self-update`，再重新解析安装后的
|
|
457
457
|
`openprd` 可执行文件，然后执行 `update <project>`；加 `--fleet` 时会执行
|
|
458
458
|
`fleet <root> --update-openprd`，只刷新已有 `.openprd/` 的历史项目。两个入口都支持
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: openprd-requirement-intake
|
|
3
|
-
description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品需求、功能变更、bugfix、流程调整、跨对话续做、OpenPrd/PRD 生成、review/change/tasks
|
|
3
|
+
description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品需求、功能变更、bugfix、流程调整、跨对话续做、OpenPrd/PRD 生成、review/change/tasks 前置判断时，先按语义判断用户可见需求类型和内部 L0/L1/L2 路由码，并选择 base、consumer、b2b 或 agent PRD 模板 lens。
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# OpenPrd Requirement Intake
|
|
@@ -9,7 +9,7 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
|
|
|
9
9
|
|
|
10
10
|
这份 skill 只做需求入口分流，不负责实现代码。
|
|
11
11
|
|
|
12
|
-
-
|
|
12
|
+
- 判断当前用户输入的用户可见需求类型和内部 L0/L1/L2 路由码
|
|
13
13
|
- 决定下一步是直接澄清、mini-plan，还是正式 PRD
|
|
14
14
|
- 为 L2 选择 `base`、`consumer`、`b2b` 或 `agent` PRD lens
|
|
15
15
|
- 把用户当前需求和历史 active change 分开，避免“继续任务”吞掉新范围
|
|
@@ -19,9 +19,13 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
|
|
|
19
19
|
|
|
20
20
|
不要按关键词判断。按影响面、未知数、决策成本和验证成本判断。
|
|
21
21
|
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
22
|
+
| 用户可见需求类型 | 内部路由码 | 判断含义 | 默认处理方式 |
|
|
23
|
+
|---|---|---|---|
|
|
24
|
+
| 快速修正 | L0 | 单点、低风险、可逆、验收清楚 | 可以直接处理并事后说明 |
|
|
25
|
+
| 现有功能优化 | L1 | 目标明确，但影响多个文件、状态或用户可见行为 | 先给对话内 mini-plan，再执行 |
|
|
26
|
+
| 新功能/新流程方案 | L2 | 新产品、模块、入口、流程、权限、计费、账号、AI/第三方、云服务、数据迁移、跨系统、长期工作流，或目标/验收/影响面不清 | 先走 PRD/review/change/tasks |
|
|
27
|
+
|
|
28
|
+
用户审查时优先显示“需求类型”，不要把 `Intake Decision: L1` 这类内部码当成标题。需要审查或调试时，可以在同一段里附上“内部路由码：L1”，并保留上面的对照关系。
|
|
25
29
|
|
|
26
30
|
如果同一句话同时包含“继续旧任务”和“新增范围”，先判断新增范围是否超出旧 PRD。超出时必须回到需求入口，更新 PRD/change/tasks，不能把“继续”当作实现授权。
|
|
27
31
|
|
|
@@ -30,8 +34,9 @@ description: OpenPrd 需求入口与 PRD 分流 skill。用于用户提出产品
|
|
|
30
34
|
1. 读取 `.openprd/` 状态和 `openprd run . --context`，但把它当作建议。
|
|
31
35
|
2. 用 `references/routing-rubric.md` 判断 L0/L1/L2。
|
|
32
36
|
3. 如果是 L2，读取 `references/prd-template-lenses.md` 选择 PRD lens。
|
|
33
|
-
4.
|
|
34
|
-
-
|
|
37
|
+
4. 输出一个短的需求类型判断：
|
|
38
|
+
- 需求类型：快速修正 / 现有功能优化 / 新功能/新流程方案
|
|
39
|
+
- 内部路由码：L0 / L1 / L2
|
|
35
40
|
- 理由：影响面、未知数、风险、验证成本
|
|
36
41
|
- 当前需求是否覆盖历史 active change
|
|
37
42
|
- 推荐下一步
|
|
@@ -2,7 +2,13 @@
|
|
|
2
2
|
|
|
3
3
|
## 判断维度
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
按下面四个维度判断，不按固定关键词判断。用户审查时优先展示“需求类型”，内部调度和排障时再附上“内部路由码”。
|
|
6
|
+
|
|
7
|
+
| 用户可见需求类型 | 内部路由码 | 默认路径 |
|
|
8
|
+
|---|---|---|
|
|
9
|
+
| 快速修正 | L0 | 直接处理，完成后说明验证 |
|
|
10
|
+
| 现有功能优化 | L1 | 先给 mini-plan，再实现和验证 |
|
|
11
|
+
| 新功能/新流程方案 | L2 | 先澄清并进入 PRD/review/change/tasks |
|
|
6
12
|
|
|
7
13
|
| 维度 | L0 | L1 | L2 |
|
|
8
14
|
|---|---|---|---|
|
|
@@ -11,7 +17,7 @@
|
|
|
11
17
|
| 决策成本 | 不需要产品决策 | 需要简短方案选择 | 需要先评审意图和范围 |
|
|
12
18
|
| 验证成本 | 单元/局部验证 | 组合验证或 E2E | 需要分阶段任务、回归、业务/成本/权限验证 |
|
|
13
19
|
|
|
14
|
-
## L0
|
|
20
|
+
## L0：快速修正
|
|
15
21
|
|
|
16
22
|
适合直接处理：
|
|
17
23
|
|
|
@@ -20,20 +26,20 @@
|
|
|
20
26
|
- 简单样式调整，不改变信息架构或用户流程
|
|
21
27
|
- 单个配置值或展示值修正
|
|
22
28
|
|
|
23
|
-
|
|
29
|
+
输出：需求类型为“快速修正”，直接做，完成后说明验证。不要生成 PRD。
|
|
24
30
|
|
|
25
|
-
## L1
|
|
31
|
+
## L1：现有功能优化
|
|
26
32
|
|
|
27
33
|
适合 mini-plan：
|
|
28
34
|
|
|
29
35
|
- 目标明确，但需要改多个文件
|
|
30
36
|
- 用户可见行为变化，但不引入新角色、新流程或新依赖
|
|
31
|
-
-
|
|
37
|
+
- 一个现有功能或现有流程里的局部体验优化
|
|
32
38
|
- 一个明确 bug 的系统化修复，需要补测试和文档
|
|
33
39
|
|
|
34
|
-
|
|
40
|
+
输出：需求类型为“现有功能优化”，先给 3-5 行 mini-plan，包含范围内、范围外、验证方式。用户已经要求执行时可继续。
|
|
35
41
|
|
|
36
|
-
## L2
|
|
42
|
+
## L2：新功能/新流程方案
|
|
37
43
|
|
|
38
44
|
必须进入 PRD：
|
|
39
45
|
|
|
@@ -44,7 +50,7 @@
|
|
|
44
50
|
- 用户说“继续任务”但补充了会改变范围的新目标
|
|
45
51
|
- 影响面和验收不清，Agent 需要猜产品决策
|
|
46
52
|
|
|
47
|
-
|
|
53
|
+
输出：需求类型为“新功能/新流程方案”，先澄清并进入 PRD/review/change/tasks。
|
|
48
54
|
|
|
49
55
|
## 续接规则
|
|
50
56
|
|
package/src/self-update.js
CHANGED
|
@@ -3,7 +3,7 @@ import path from 'node:path';
|
|
|
3
3
|
import { spawn } from 'node:child_process';
|
|
4
4
|
import { fileURLToPath } from 'node:url';
|
|
5
5
|
|
|
6
|
-
export const DEFAULT_SELF_UPDATE_SOURCE = '
|
|
6
|
+
export const DEFAULT_SELF_UPDATE_SOURCE = '@openprd/cli@latest';
|
|
7
7
|
|
|
8
8
|
const MODULE_DIR = path.dirname(fileURLToPath(import.meta.url));
|
|
9
9
|
const DEFAULT_PACKAGE_ROOT = path.resolve(MODULE_DIR, '..');
|