feat: add specifier skill
This commit is contained in:
@@ -0,0 +1,39 @@
|
||||
# HTML PRD 生成规范
|
||||
|
||||
## 页面目标
|
||||
|
||||
HTML 是给人离线评审的交付物，不是运行中的产品页面。它必须自包含、可打印、可搜索，并且
|
||||
在没有网络、构建工具或额外服务时仍能阅读。
|
||||
|
||||
推荐使用 [templates/prd.template.html](../templates/prd.template.html) 的结构；可以按需求增删
|
||||
章节，但不能删除版本信息、变更摘要、未决问题和验收标准。
|
||||
|
||||
## 必需章节
|
||||
|
||||
1. 摘要：需求、目标用户、问题和成功标准。
|
||||
2. 范围：包含项、非目标、约束和假设。
|
||||
3. 场景：用户角色、主流程、异常流程和权限边界。
|
||||
4. 方案：候选方案、取舍、推荐方案和被否决方案。
|
||||
5. 设计：交互、领域模型、状态流、API/数据变化和迁移。
|
||||
6. 非功能：安全、性能、兼容性、可观测性、发布和回滚。
|
||||
7. 任务预览：垂直切片、依赖、关键路径、`expected`、`verification`。
|
||||
8. 验收：逐条可观察的用户、API、数据和错误信号。
|
||||
9. 风险与未决：负责人、影响、缓解动作和需要确认的选择。
|
||||
10. 版本记录：当前版本、基线版本、本轮变更和评审状态。
|
||||
|
||||
## 渲染要求
|
||||
|
||||
- CSS 写在页面内，脚本只用于不影响阅读的目录或打印增强。
|
||||
- 不使用远程 CDN、远程字体、外部图片或需要联网的脚本。
|
||||
- 颜色和状态不能只依靠颜色表达；为状态提供文字标签。
|
||||
- 长表格允许横向滚动，代码或 API 示例使用 `pre`，正文保持可复制。
|
||||
- `h1` 只有一个；标题层级连续；链接和表格有可读的焦点/边框状态。
|
||||
- 页首显示 feature ID、PRD 版本、状态、生成时间和基于的版本。
|
||||
- 变更内容用文字摘要或 `ins` / `del` 标记表达，不要只用颜色标记。
|
||||
|
||||
## 内容质量
|
||||
|
||||
- 把“体验好”“性能足够”“支持权限”等不可验证表述改成可观察信号或明确待决策项。
|
||||
- 不把实现方案伪装成用户需求；需求、决策和任务分开写。
|
||||
- 未知事实写“待确认”，并加入未决问题，不填看似合理的数字、接口或页面。
|
||||
- 每条验收都能被 ACK 的 Test 按步骤观察；测试工具不可用时仍能区分产品失败和环境失败。
|
||||
@@ -0,0 +1,98 @@
|
||||
# HTML PRD 评审闭环
|
||||
|
||||
## 目录
|
||||
|
||||
- [状态](#状态)
|
||||
- [每轮评审](#每轮评审)
|
||||
- [批准](#批准)
|
||||
- [批准后的变更](#批准后的变更)
|
||||
|
||||
## 状态
|
||||
|
||||
`current.yaml` 至少记录：
|
||||
|
||||
```yaml
|
||||
featureId: tenant-permissions
|
||||
currentRevision: v002
|
||||
status: review
|
||||
prd: prd-v002.html
|
||||
approvedRevision: null
|
||||
reviews: review.yaml
|
||||
```
|
||||
|
||||
允许的状态：
|
||||
|
||||
| 状态 | 含义 | 允许的下一步 |
|
||||
|---|---|---|
|
||||
| `draft` | 已建立需求，但还没形成可审版本 | 生成 PRD |
|
||||
| `review` | 当前版本等待人评审 | 接收意见或批准 |
|
||||
| `changes_requested` | 人明确要求修改 | 生成新版本 |
|
||||
| `approved` | 指定版本已被明确批准 | 生成 handoff |
|
||||
| `handed_off` | handoff 已生成并交给 ACK | 只能创建后续修订 |
|
||||
| `superseded` | 版本被后续版本替代 | 只读历史 |
|
||||
| `parked` | 用户暂缓 | 用户恢复后继续评审 |
|
||||
| `rejected` | 用户明确拒绝 | 不再自动推进 |
|
||||
|
||||
`review.yaml` 每轮追加一条记录，不覆盖历史：
|
||||
|
||||
```yaml
|
||||
- revision: v002
|
||||
status: changes_requested
|
||||
feedback:
|
||||
- section: permissions
|
||||
type: decision
|
||||
request: "租户管理员不能查看平台级审计日志"
|
||||
disposition: applied
|
||||
unresolved:
|
||||
- id: Q-002
|
||||
question: "跨租户查询是否允许平台运维角色使用？"
|
||||
owner: user
|
||||
changedFrom: v001
|
||||
```
|
||||
|
||||
不要补写用户没有提供的姓名、时间或审批理由。时间可使用当前环境时间；审批人未知时写
|
||||
`user`，不要猜测真实身份。
|
||||
|
||||
## 每轮评审
|
||||
|
||||
1. 读取 `current.yaml`、当前 HTML 和所有未解决的 review 项；不要只读用户最新一句话。
|
||||
2. 将新反馈归类：`change`、`decision`、`question`、`rejected`、`parked`。
|
||||
3. 说明每个反馈对范围、架构、任务和验收的影响。
|
||||
4. 生成新版本 HTML，保留旧文件。
|
||||
5. 更新 `current.yaml` 和 `review.yaml`，并在回复中给出：新版本路径、变更摘要、未决问题、
|
||||
是否仍需批准。
|
||||
|
||||
如果反馈只影响措辞，也生成新版本；评审记录需要保持可追溯。若用户明确说不采纳，记录理由，
|
||||
不要悄悄删除意见。
|
||||
|
||||
## 批准
|
||||
|
||||
只有以下类型的表达才可作为批准信号：
|
||||
|
||||
- “批准 specifier 的 v002 PRD”
|
||||
- “确认按 v002 开发”
|
||||
- “需求文档 v002 通过，可以生成 handoff”
|
||||
|
||||
批准前必须确认：
|
||||
|
||||
- 没有未决的阻塞问题；
|
||||
- 范围和非目标明确；
|
||||
- 关键方案和风险已确认；
|
||||
- 任务都有 `expected` 和 `verification`；
|
||||
- HTML 版本、状态文件和 review 记录一致。
|
||||
|
||||
如果用户说“继续”“可以”“看起来不错”，但没有绑定版本，继续保持 `review`，请用户确认
|
||||
具体版本。批准后把 `approvedRevision` 写入 `current.yaml`，再生成 handoff；不要同时启动 ACK。
|
||||
|
||||
## 批准后的变更
|
||||
|
||||
批准后的需求不能原地编辑。用户提出变化时：
|
||||
|
||||
1. 保留已批准版本和 handoff；
|
||||
2. 将当前状态标为 `superseded` 或创建新的修订链；
|
||||
3. 生成下一个 PRD 版本；
|
||||
4. 标记受影响的任务、验收、风险和 ACK handoff 字段；
|
||||
5. 重新等待用户批准。
|
||||
|
||||
已经进入 ACK 的任务不会因 HTML 更新而自动改变。需要执行变更时，明确告诉用户应创建新的
|
||||
ACK 任务或由 ACK 重新规划，不能静默改写执行记录。
|
||||
Reference in New Issue
Block a user