feat(req-prd): persist docs and prototypes remotely
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: req-prd
|
||||
description: 产品设计与需求管理。用于 PRD 文档编写、需求分析、用户故事创建、功能设计和原型规划。当用户提到产品设计、PRD、需求文档、功能规划、用户故事相关任务时自动激活。
|
||||
description: 产品设计与需求管理。用于 PRD、需求分析、用户故事、功能设计和原型规划，并将正式需求文档双写到本地仓库与 ai-proj Task Document。
|
||||
---
|
||||
|
||||
# 产品需求设计 Skill (req-prd)
|
||||
@@ -19,6 +19,36 @@ description: 产品设计与需求管理。用于 PRD 文档编写、需求分
|
||||
- `req-prototype` — UI 模块在 PRD/缺陷收敛后生成、上传并关联 HTML 原型
|
||||
- `defect-analysis` — 设计访谈确认后，对最新版 PRD 反复审计和修订直至收敛
|
||||
|
||||
## 产品需求文档双写门禁
|
||||
|
||||
本技能创建或修改的所有正式需求文档都必须同时保存到：
|
||||
|
||||
1. 当前产品仓库的本地 Markdown 文件；
|
||||
2. Requirement 对应角色任务的 ai-proj Task Document。
|
||||
|
||||
适用文档至少包括原始诉求/讨论记录、PRD、缺陷优化记录、原型版本与评审记录。Requirement description 只保存已确认的讨论摘要，不能替代 Task Document。
|
||||
|
||||
### 路径与任务映射
|
||||
|
||||
优先遵循仓库已有文档目录和命名约定；没有约定时使用：
|
||||
|
||||
| 文档 | 本地默认路径 | ai-proj 任务角色 |
|
||||
|------|--------------|------------------|
|
||||
| 需求讨论记录 | `docs/product/{REQ-ID}-{slug}-discussion.md` | `documentation` |
|
||||
| PRD（含缺陷修订和原型回填） | `docs/product/{REQ-ID}-{slug}-prd.md` | `prd` |
|
||||
|
||||
同一 Requirement、同一角色只维护一个当前任务文档。不得把本地文件路径当成 ai-proj 持久化，也不得只把远程 Task Document 导出一次后继续单边修改。
|
||||
|
||||
### 每次写入协议
|
||||
|
||||
1. 修改前同时读取本地文件与 ai-proj Task Document；任一不存在则基于另一份初始化，二者都不存在才新建空模板；
|
||||
2. 若两份内容不一致，比较文档 ID、版本、更新时间和内容摘要，保留双方未知内容并显式合并；无法安全合并时停止并请用户选择，禁止静默覆盖；
|
||||
3. 先用安全文件编辑方式写入本地 Markdown，再创建或更新对应 Task Document；
|
||||
4. 写后重新读取两端，计算或比较内容摘要，确认正文一致，并记录本地路径、task_id、document_id、version/updated_at；
|
||||
5. 任一端写入或复读失败都属于未完成的部分写入：保留已成功一端用于恢复，立即报告并停止后续阶段，不得宣称“已保存”“已收敛”或提交评审。
|
||||
|
||||
问答每一轮、每次 PRD 修订、每轮 defect 处置和每次原型回填都执行该协议；不能等到流程结束再一次性补传。
|
||||
|
||||
## 模块设计访谈模式
|
||||
|
||||
设计模块、系统、跨域流程，或目标/边界/业务规则尚未确定时，必须先执行问答式设计访谈，不得直接补全假设后生成 PRD。用户明确要求“你问我答”时也进入此模式。范围小、规则已完整确认的需求可以直接编写 PRD。
|
||||
@@ -41,8 +71,8 @@ description: 产品设计与需求管理。用于 PRD 文档编写、需求分
|
||||
|
||||
1. 原型基于最新版、已完成缺陷收敛的 PRD，并记录 PRD 文档标识、版本或内容摘要；
|
||||
2. 覆盖核心入口、主流程以及 PRD 明确要求的空态、失败态、无权限态和确认/撤销反馈；
|
||||
3. 上传后重新读取 Requirement，确认原型 URL/版本已关联，并验证 URL 可访问、iframe 可展示、核心交互可操作；
|
||||
4. 将 iframe、原型版本、版本说明和验证结果回填 PRD `4.2 界面原型`，并把生成、反馈、修订和确认写入同一讨论文档；
|
||||
3. 将本地 HTML 源文件通过 ai-proj 上传到 OSS；上传后重新读取 Requirement，确认 OSS URL/版本已关联，并验证 URL 可访问、iframe 可展示、核心交互可操作；
|
||||
4. 将 iframe、原型版本、版本说明和验证结果双写到本地 PRD 与 prd 角色 Task Document，并把生成、反馈、修订和确认双写到本地讨论记录与 documentation 任务文档；
|
||||
5. 用户明确确认最终 PRD 与原型表达的是同一方案。
|
||||
|
||||
纯后端、批处理、基础设施等确实没有用户界面的模块可以跳过，但必须在讨论文档和 PRD `4.2` 中记录“无 UI，原型不适用”的理由及用户确认，不得静默省略。
|
||||
@@ -401,6 +431,8 @@ mcp__ai-proj__link_tasks_to_requirement
|
||||
|
||||
### 文档管理
|
||||
|
||||
以下 MCP 操作只完成 ai-proj 侧写入；每次调用前后都必须按“产品需求文档双写门禁”同步并校验本地 Markdown。
|
||||
|
||||
```bash
|
||||
# 创建 PRD 文档并关联任务
|
||||
mcp__ai-proj__create-and-attach
|
||||
@@ -418,6 +450,8 @@ mcp__ai-proj__export_task_document_to_file
|
||||
- taskId: 任务ID
|
||||
```
|
||||
|
||||
导出命令不能代替双写校验：导出后仍需确认目标路径符合仓库约定、正文与 Task Document 当前版本一致，且没有覆盖本地新增内容。
|
||||
|
||||
---
|
||||
|
||||
## 功能设计流程
|
||||
@@ -561,6 +595,8 @@ UI 模块还必须核对最终 HTML 原型与最新版 PRD 一致，并取得用
|
||||
### PRD 完整性检查
|
||||
|
||||
- [ ] 模块/系统设计已完成单轮单问访谈，且全过程已写入 ai-proj 讨论文档
|
||||
- [ ] 讨论记录与 PRD 均已保存到仓库本地 Markdown 和对应 ai-proj Task Document
|
||||
- [ ] 两端复读正文一致，交付说明包含本地路径、task/document 标识和远程版本
|
||||
- [ ] 讨论结论已由用户明确确认
|
||||
- [ ] `defect-analysis` 已基于最新版 PRD 收敛到一轮 0 个新缺陷
|
||||
- [ ] 无未处置的致命/高严重度缺陷
|
||||
|
||||
Reference in New Issue
Block a user