P0-1: SessionStart Hook — hooks/session-context.sh 从分支名解析 REQ-ID,调 MCP API 查询需求详情注入 system-reminder P0-2: PreToolUse Hook — hooks/pre-tool-confirm.sh 拦截生产推送、force push、docker prod 容器操作、git reset --hard 等 P0-3: Release Draft 闸门设计文档 — docs/design/release-draft-gate.md 完整架构 + 渐进式落地路径(拆 7 个子任务延后) 附最小可用脚本 hooks/release-draft.sh 创建 Gitea draft release P0-4: Memory 隔离规则 — 写入 req-prd / req-design / req-workflow 禁止 auto-memory 污染模板产出物(章节结构、字段定义、文档结构) P0-5: CLAUDE.md 架构检查 + 架构片段库 dev-coding skill 执行前检查架构关键词 新增 templates/claude-md-snippets/ 含 Go+Gin / React+AntD / Vue+Element / MCP+TS / generic 五套骨架 P0-6: /commit 分支保护自动化 — 新 skill dev-commit-plugin 保护分支自动建功能分支 + Conventional Commits + REQ-XXX 自动关联 安装: bash hooks/install.sh 后续: P0-3 完整实现拆 7 个子任务(P0-3.1 ~ P0-3.7) 建议先部署 hooks 跑 1-2 周观察,再推进 Release 机制落地
445 lines
9.9 KiB
Markdown
445 lines
9.9 KiB
Markdown
---
|
||
name: req-prd
|
||
description: 产品设计与需求管理。用于 PRD 文档编写、需求分析、用户故事创建、功能设计和原型规划。当用户提到产品设计、PRD、需求文档、功能规划、用户故事相关任务时自动激活。
|
||
---
|
||
|
||
# 产品需求设计 Skill (req-prd)
|
||
|
||
## 概述
|
||
|
||
本技能用于辅助产品设计和需求管理工作,包括:
|
||
- PRD 文档编写与管理
|
||
- 需求分析与优先级排序
|
||
- 用户故事创建
|
||
- 功能设计与规划
|
||
- 与 ai-proj 任务系统集成
|
||
|
||
**插件扩展**:
|
||
- `req-compare` — 对比式 PRD 编写(系统平移/竞品借鉴时激活)
|
||
- `req-prototype` — UI 原型生成
|
||
|
||
---
|
||
|
||
## 对比式 PRD 编写
|
||
|
||
> 系统平移、竞品借鉴、版本升级时,使用 `req-compare` 插件进行对比分析。
|
||
> 该插件包含完整的对比工作流、对比式 PRD 模板和竞品分析模板。
|
||
|
||
**触发方式**:当需求涉及参考系统时,req-prd 自动推荐激活 req-compare 插件。
|
||
|
||
---
|
||
|
||
## PRD 文档模板
|
||
|
||
### 标准 PRD 结构
|
||
|
||
```markdown
|
||
# [产品/功能名称] PRD
|
||
|
||
## 1. 概述
|
||
### 1.1 背景
|
||
[为什么需要这个功能?解决什么问题?]
|
||
|
||
### 1.2 目标
|
||
- 业务目标:[量化的业务指标]
|
||
- 用户目标:[用户能获得什么价值]
|
||
- 技术目标:[技术层面要达成什么]
|
||
|
||
### 1.3 成功指标
|
||
| 指标 | 当前值 | 目标值 | 衡量方式 |
|
||
|------|--------|--------|----------|
|
||
| ... | ... | ... | ... |
|
||
|
||
## 2. 用户分析
|
||
### 2.1 目标用户
|
||
[用户画像描述]
|
||
|
||
### 2.2 用户痛点
|
||
1. [痛点1]
|
||
2. [痛点2]
|
||
|
||
### 2.3 用户场景
|
||
[场景描述]
|
||
|
||
## 3. 功能需求
|
||
### 3.1 功能清单
|
||
| 功能 | 优先级 | 描述 | 验收标准 |
|
||
|------|--------|------|----------|
|
||
| ... | P0/P1/P2 | ... | ... |
|
||
|
||
### 3.2 功能详细说明
|
||
#### [功能1]
|
||
- 功能描述:
|
||
- 触发条件:
|
||
- 业务规则:
|
||
- 异常处理:
|
||
|
||
## 4. 交互设计
|
||
### 4.1 用户流程
|
||
[流程图或步骤描述]
|
||
|
||
### 4.2 界面原型
|
||
|
||
> 使用 `/req prototype [REQ-ID]` 基于 PRD 自动生成 Stitch 原型。
|
||
> 生成后截图将自动回填到此章节。
|
||
|
||
[执行 `/req prototype` 后自动填充]
|
||
|
||
## 5. 技术要求
|
||
### 5.1 性能要求
|
||
- 响应时间:
|
||
- 并发量:
|
||
- 数据量:
|
||
|
||
### 5.2 安全要求
|
||
- 权限控制:
|
||
- 数据安全:
|
||
|
||
### 5.3 兼容性要求
|
||
- 浏览器:
|
||
- 设备:
|
||
|
||
## 6. 上线计划
|
||
### 6.1 里程碑
|
||
| 阶段 | 内容 | 完成标准 |
|
||
|------|------|----------|
|
||
| ... | ... | ... |
|
||
|
||
### 6.2 灰度策略
|
||
[灰度发布计划]
|
||
|
||
## 7. 风险评估
|
||
| 风险 | 影响 | 概率 | 应对措施 |
|
||
|------|------|------|----------|
|
||
| ... | 高/中/低 | 高/中/低 | ... |
|
||
|
||
## 8. 附录
|
||
- 相关文档链接
|
||
- 参考资料
|
||
```
|
||
|
||
---
|
||
|
||
## 需求优先级框架
|
||
|
||
### RICE 评分法
|
||
|
||
| 维度 | 说明 | 评分范围 |
|
||
|------|------|----------|
|
||
| Reach (触达) | 影响多少用户 | 1-10 |
|
||
| Impact (影响) | 对用户的影响程度 | 0.25-3 |
|
||
| Confidence (信心) | 估算的置信度 | 0-100% |
|
||
| Effort (工作量) | 需要的人天数 | 实际工作量 |
|
||
|
||
**计算公式**: `RICE = (Reach × Impact × Confidence) / Effort`
|
||
|
||
### 优先级定义
|
||
|
||
| 优先级 | 含义 | 处理方式 |
|
||
|--------|------|----------|
|
||
| P0 | 阻塞性需求 | 必须立即处理 |
|
||
| P1 | 核心需求 | 本迭代必须完成 |
|
||
| P2 | 重要需求 | 尽量本迭代完成 |
|
||
| P3 | 优化需求 | 有余力时处理 |
|
||
|
||
---
|
||
|
||
## 用户故事编写
|
||
|
||
### 标准格式
|
||
|
||
```
|
||
作为 [用户角色],
|
||
我想要 [功能/目标],
|
||
以便 [获得的价值/原因]。
|
||
|
||
验收标准:
|
||
- Given [前置条件]
|
||
- When [用户行为]
|
||
- Then [预期结果]
|
||
```
|
||
|
||
### 示例
|
||
|
||
```
|
||
作为 仓库管理员,
|
||
我想要 扫码快速入库,
|
||
以便 提高入库效率、减少手动输入错误。
|
||
|
||
验收标准:
|
||
- Given 已有采购单且货物到达
|
||
- When 扫描货物条码
|
||
- Then 自动匹配采购单并显示入库确认界面
|
||
```
|
||
|
||
### INVEST 原则检查
|
||
|
||
| 原则 | 含义 | 检查点 |
|
||
|------|------|--------|
|
||
| I - Independent | 独立的 | 故事间无依赖 |
|
||
| N - Negotiable | 可协商 | 非固定规格 |
|
||
| V - Valuable | 有价值 | 交付业务价值 |
|
||
| E - Estimable | 可估算 | 能估算工作量 |
|
||
| S - Small | 足够小 | 可在迭代内完成 |
|
||
| T - Testable | 可测试 | 有明确验收标准 |
|
||
|
||
---
|
||
|
||
## 与 ai-proj 集成
|
||
|
||
### 需求管理工具
|
||
|
||
使用 ai-proj MCP 工具管理需求:
|
||
|
||
```bash
|
||
# 创建需求
|
||
mcp__ai-proj__create_requirement
|
||
- title: "需求标题"
|
||
- description: "需求描述"
|
||
- category: feature/bug/improvement/documentation/other
|
||
- priority: low/medium/high
|
||
- projectId: 项目ID
|
||
|
||
# 查看需求列表
|
||
mcp__ai-proj__list_requirements
|
||
- status: draft/pending/reviewing/approved/rejected/archived
|
||
- priority: low/medium/high
|
||
|
||
# 需求与任务关联
|
||
mcp__ai-proj__link_tasks_to_requirement
|
||
- requirementId: 需求ID
|
||
- taskIds: [任务ID列表]
|
||
```
|
||
|
||
### 任务分解流程
|
||
|
||
1. **创建需求** → `create_requirement`
|
||
2. **需求评审** → `submit_requirement` → `approve/reject_requirement`
|
||
3. **分解任务** → `create_task` / `create_subtask`
|
||
4. **关联任务** → `link_tasks_to_requirement`
|
||
5. **跟踪进度** → `get_requirement_tasks` / `get_requirement_statistics`
|
||
|
||
### 文档管理
|
||
|
||
```bash
|
||
# 创建 PRD 文档并关联任务
|
||
mcp__ai-proj__create-and-attach
|
||
- taskId: 任务ID
|
||
- content: PRD 文档内容 (Markdown)
|
||
- title: 文档标题 (可选)
|
||
|
||
# 更新 PRD 文档
|
||
mcp__ai-proj__update_task_document
|
||
- taskId: 任务ID
|
||
- content: 更新后的内容
|
||
|
||
# 导出 PRD 到文件
|
||
mcp__ai-proj__export_task_document_to_file
|
||
- taskId: 任务ID
|
||
```
|
||
|
||
---
|
||
|
||
## 功能设计流程
|
||
|
||
### 1. 需求收集
|
||
|
||
```
|
||
输入:
|
||
- 用户反馈
|
||
- 业务需求
|
||
- 数据分析
|
||
- 竞品分析
|
||
|
||
输出:
|
||
- 需求池(ai-proj 需求列表)
|
||
```
|
||
|
||
### 2. 需求分析
|
||
|
||
```
|
||
方法:
|
||
- 5W1H 分析法
|
||
- 用户访谈
|
||
- 数据验证
|
||
|
||
输出:
|
||
- 需求文档
|
||
- 优先级排序
|
||
```
|
||
|
||
### 3. 方案设计
|
||
|
||
```
|
||
内容:
|
||
- 功能架构
|
||
- 交互流程
|
||
- 界面原型
|
||
- 技术方案
|
||
|
||
输出:
|
||
- PRD 文档
|
||
- 原型设计
|
||
```
|
||
|
||
### 4. 评审验证
|
||
|
||
```
|
||
评审维度:
|
||
- 业务价值
|
||
- 技术可行性
|
||
- 资源评估
|
||
- 风险评估
|
||
|
||
输出:
|
||
- 评审结论
|
||
- 修改意见
|
||
```
|
||
|
||
---
|
||
|
||
## 竞品分析
|
||
|
||
> 竞品分析模板已移至 `req-compare` 插件。涉及竞品对比时自动激活。
|
||
|
||
---
|
||
|
||
## 产品指标体系
|
||
|
||
### 北极星指标选择
|
||
|
||
| 产品类型 | 典型北极星指标 |
|
||
|----------|----------------|
|
||
| 电商 | GMV / 订单量 |
|
||
| SaaS | MRR / 活跃用户数 |
|
||
| 社交 | DAU / 消息数 |
|
||
| 工具 | 完成任务数 / 使用时长 |
|
||
|
||
### 指标分层
|
||
|
||
```
|
||
北极星指标
|
||
├── 一级指标(核心业务指标)
|
||
│ ├── 二级指标(过程指标)
|
||
│ │ └── 三级指标(功能指标)
|
||
```
|
||
|
||
### 常用指标
|
||
|
||
| 类型 | 指标 | 计算方式 |
|
||
|------|------|----------|
|
||
| 获客 | 新用户数、获客成本 | 注册数 / 推广费用 |
|
||
| 激活 | 激活率、首日留存 | 完成核心动作 / 注册数 |
|
||
| 留存 | 次日/7日/30日留存 | 回访用户 / 新增用户 |
|
||
| 收入 | ARPU、付费率 | 收入 / 用户数 |
|
||
| 传播 | 推荐率、K因子 | 邀请数 / 用户数 |
|
||
|
||
---
|
||
|
||
## 设计检查清单
|
||
|
||
### PRD 完整性检查
|
||
|
||
- [ ] 背景与目标明确
|
||
- [ ] 用户群体定义清晰
|
||
- [ ] 功能需求完整
|
||
- [ ] 验收标准可测试
|
||
- [ ] 异常情况已考虑
|
||
- [ ] 性能要求已定义
|
||
- [ ] 上线计划合理
|
||
- [ ] 风险已评估
|
||
|
||
### 交互设计检查
|
||
|
||
- [ ] 用户流程完整
|
||
- [ ] 边界情况处理
|
||
- [ ] 错误提示友好
|
||
- [ ] 反馈及时
|
||
- [ ] 操作可撤销
|
||
- [ ] 符合用户习惯
|
||
|
||
### 非功能需求检查
|
||
|
||
- [ ] 性能要求已量化(响应时间、并发量)
|
||
- [ ] 安全需求已明确(权限、数据保护)
|
||
- [ ] 兼容性要求已定义(浏览器、设备)
|
||
- [ ] 可用性目标已设定
|
||
|
||
> **技术方案可行性检查**在 design 阶段由 `req-design` 技能完成。
|
||
|
||
---
|
||
|
||
## 常用工具
|
||
|
||
### 原型设计
|
||
- **Stitch** (Google AI) — 集成在 `/req prototype`,自动从 PRD 生成原型
|
||
- Figma — 手动精细设计
|
||
- Sketch
|
||
- Axure
|
||
|
||
### 流程图
|
||
- draw.io
|
||
- ProcessOn
|
||
- Mermaid (Markdown)
|
||
|
||
### 数据分析
|
||
- Metabase
|
||
- Google Analytics
|
||
- Mixpanel
|
||
|
||
### 项目管理
|
||
- ai-proj (内部)
|
||
- JIRA
|
||
- Linear
|
||
|
||
---
|
||
|
||
## 最佳实践
|
||
|
||
1. **需求先行** - 先理解问题,再设计方案
|
||
2. **用户视角** - 始终从用户角度思考
|
||
3. **数据驱动** - 用数据验证假设
|
||
4. **迭代优化** - 小步快跑,持续改进
|
||
5. **跨团队协作** - 早期与技术、设计团队对齐
|
||
6. **文档沉淀** - 及时记录决策和变更
|
||
|
||
---
|
||
|
||
## 安全与合规
|
||
|
||
- 用户隐私保护 (GDPR/个人信息保护法)
|
||
- 数据安全分级
|
||
- 敏感操作审计
|
||
- 权限最小化原则
|
||
|
||
---
|
||
|
||
## Memory 隔离规则(强制,源自 devflow-claude 借鉴)
|
||
|
||
**规则:本 skill 涉及模板/文档产出的命令禁止受 auto-memory 影响产出物。**
|
||
|
||
### 禁止行为
|
||
1. 不得根据 memory 中的偏好跳过或合并 PRD 模板章节
|
||
2. 不得用 memory 里的历史需求/项目内容填充当前 PRD
|
||
3. 不得根据 memory 反馈调整 PRD 章节顺序、表格列数、标题层级
|
||
4. 不得读取 `~/.claude/projects/*/memory/` 辅助生成 PRD 正文
|
||
|
||
### 允许行为
|
||
- memory 可影响**交互风格**(提问详略、确认节奏、语气)
|
||
- memory 可指导**命令选择**(如根据用户习惯推荐先走 req-compare 还是 req-prd)
|
||
- memory 可影响**非产出文本**(如对话中的说明)
|
||
|
||
### Why
|
||
auto-memory 设计用于跨会话建立用户画像。但 PRD/需求文档是正式产出物,必须由**模板结构 + 当前输入**决定,不能因 memory 中的偏好自作主张调整结构,否则会导致:
|
||
- 模板章节漂移(用户不知道为什么这次少了一章)
|
||
- 历史项目内容污染(张冠李戴)
|
||
- 产出不可复现
|
||
|
||
### How to apply
|
||
执行 `/req prd` / PRD 编写 / 需求描述生成等命令时:
|
||
- 仅读取:模板文件、用户当前输入、引用的已有需求文档
|
||
- 不读取:memory 目录下的任何文件
|
||
- 产出前自检:章节数量和顺序与模板完全一致
|
||
|
||
**参考**:devflow-claude 的 `plugins/req/commands/_common.md` 同名规则。
|