Skill: lailiai/prdwriter (version 1.0.1)

--- name: product-design-0to1 description: Use this skill when the user wants to design a brand-new (0→1) PRD or prototype for a company-internal process management system, where roles and workflows are first-class concerns. Triggers when the user explicitly says "从0到1设计PRD/原型", "设计一个全新的流程系统", or has been routed here by product-design-router. Produces user stories, swimlane diagrams, ER models, state machines, function modules, high-fidelity interactive prototype, RBAC matrix, tracking plan, and detailed PRD through 7 confirmed steps. --- # Product Design 0→1 (Internal Process System) — v2.1 7-step pipeline. Each step has a human checkpoint. Latest confirmed artifact flows to next step. ## Domain assumption Target is ALWAYS a company-internal process management system. Roles and workflows are core. NOT for ToC products. ## File layout (under `project/`) ``` project/ ├── 00-input/{overview, roles, pain-points, expectations}.md ├── 01-user-stories.md ├── 02-flows/{swimlane.md, state-machine.md} ├── 03-er-model.md # 🆕 v2.1 ├── 03.5-field-decisions.md ├── 04-modules.md ├── 05-rbac-matrix.md # 🆕 v2.1 ├── 06-tracking-plan.md # 🆕 v2.1 └── 07-output/{prototype.html, prd.md} ``` ## The 7 steps (each delegated to a reference file) | Step | Topic | Reference | |---|---|---| | 1 | 入口确认 | inline (one sentence) | | 2 | 输入收集（4 子步 + 领域偏移检测） | `references/steps/step2-input-collection.md` | | 3 | 7 条机械校验 | `references/steps/step3-validation.md` | | 4 | 用户故事（三段式 + AC） | `references/steps/step4-user-stories.md` | | 5 | 泳道图 + 状态机 | `references/steps/step5-flows.md` | | 5.5 | 字段决策清单 | `references/steps/step5.5-field-decisions.md` | | 6 | 功能模块 + ER 模型 + 字段 | `references/steps/step6-modules-er.md` | | 6.5 | RBAC 权限矩阵 + 埋点规划 | `references/steps/step6.5-rbac-tracking.md` | | 7 | 高保真原型 + 12 节 PRD | `references/steps/step7-output.md` | ## Cross-cutting rules (always apply) 1. **强制卡点**：每步产物用 `present_files` 呈现后必须等用户确认（"确认"/"修改 X"），不允许越权进入下一步 2. **AI 推断必须显式化**：所有非用户明示的细节（字段、状态机、权限、埋点）必须通过 Step 5.5 + Step 6.5 让用户拍板 3. **回退即重生成**：任何回退后，下游产物全部重做，禁止智能合并 4. **`[TODO:]` 即时标注**：当某节信息确实不足时，PRD 中用 `[TODO: 具体需要补什么]` 占位，绝不编造（吸收自 create-prd） 5. **领域偏移检测**：Step 2.1 前必须扫描会话历史，发现领域切换主动暂停询问 a/b/c 6. **不发明**：角色/痛点/字段/权限/埋点必须能从用户输入或决策清单溯源 ## Self-check 完成所有步骤后加载 `references/appendices/selfcheck.md` 跑自检清单，输出"通过/待补"清单。 ## End "0→1 设计完成（含 PRD / 原型 / RBAC / 埋点）。下一步可调用 tech-design skill 进行技术方案设计。"

path: references/step7-output.md
content: # Step 7 — 高保真原型 + 12 节 PRD

## 7.1 高保真可交互原型 `07-output/prototype.html`

强制要求：
- 顶部 tab 切换角色视角
- **每个 P0 操作节点入口按钮必须绑定真实交互**（弹窗/抽屉/页面切换/alert），禁止死按钮
- "新建/编辑"按钮打开的表单必须含 `04-modules.md` 全部必填字段及约束提示
- 涉及状态机的列表用不同颜色 badge
- 列表必须处理空状态
- 单 HTML + Tailwind CDN + 原生 JS
- ToB 风格（中性色、表格密度高）

**自检 5 项**（生成后逐条验证）：
- [ ] 每个角色 tab 切换正常
- [ ] 每个"+ 新建/+ 添加"按钮都有弹窗
- [ ] 每个表单都有提交反馈
- [ ] 至少演示一次状态流转
- [ ] 没有 onclick 缺失或空函数

## 7.2 12 节 PRD `07-output/prd.md`

```
1. 产品概述
2. 角色定义
3. 业务现状与痛点
4. 产品目标
5. 用户故事清单（含 AC）
6. 业务流程图（嵌入泳道图 + 状态机图）
7. ER 数据模型 🆕
   - 实体清单 + 关系图（mermaid erDiagram）
8. 功能模块详述
   每个操作节点必须包含:
   - 输入: 数据来源/触发条件/前置依赖
   - 处理逻辑: 关键计算公式、判断分支（伪代码或步骤列表）
   - 输出: 落库字段/通知对象/状态变更/下游触发
   - 异常处理
9. 字段总览（含计算逻辑）
   - 衍生字段必须给计算公式: 实发金额 = 应发 - 扣减
   - 状态字段必须给状态转移表
   - 引用字段必须给引用源
10. RBAC 权限矩阵 🆕（功能权限表 + 数据权限规则）
11. 数据埋点规划 🆕（事件表 + 核心指标）
12. 风险与决策记录
    - 用户在设计阶段做出的高风险决策
    - 未覆盖的边界场景（明确写本期不做哪些）
    - 来自 03.5-field-decisions.md 的关键决策
    - 每条注明: 描述/影响/用户已确认/后续 review 时点
```

**`[TODO:]` 标注规则**（吸收自 create-prd）🆕：
某节信息确实不足时，用 `[TODO: 具体需要补什么]` 占位。例如：
- `[TODO: 请补充考勤系统的 API 文档地址，确认取数字段]`
- `[TODO: 请确认贷款证明 PDF 是否需要财务章/电子签]`

绝不编造内容填空。

PRD **不含接口/API 设计**，技术方案归 `tech-design` skill。

End: "0→1 设计完成（含 PRD / 原型 / RBAC / 埋点）。下一步可调用 tech-design skill。"


path: references/step4-user-stories.md
content: # Step 4 — 用户故事

格式严格遵守：
```
[US-XXX]
作为 <角色>，
我希望 <做什么动作>，
以便 <达到什么业务目的>。

验收条件：
- 当 <前置条件> 时，<角色> 可以 <操作>
- 操作完成后，系统应 <结果>
- 异常情况：<边界处理>
```

## 规则
- 每个角色至少一个故事
- 每条期望至少映射一个故事
- 业务流三段（输入/中间/输出）都有故事覆盖
- 编号 US-001, US-002...

→ `01-user-stories.md`，**STOP** 等用户确认。修改循环至确认。


path: references/step5-flows.md
content: # Step 5 — 泳道图 + 状态机图

## 5.1 泳道图（Mermaid `flowchart TB`）

每个角色一个 subgraph。**允许特殊泳道**（v2 升级）：
- `系统(定时任务)` — 定时触发
- `系统(外部集成)` — 对接外部系统取数/推送
- `系统(自动流转)` — 无人工自动状态流转

特殊泳道在图下方"角色说明"标注触发条件。

规则：
- 每个用户故事的主要动作必须有节点
- 必须有终态节点（归档/完成/结束）

→ `02-flows/swimlane.md`

## 5.2 状态机图（吸收自 create-prd ch10）🆕

为每个**核心业务对象**画状态机（如"工资单"、"质检单"、"申请单"）。Mermaid `stateDiagram-v2`：

```
stateDiagram-v2
    [*] --> 已计算: 系统取数计算
    已计算 --> 已发放: HR触发发放
    已计算 --> 异常: 取数失败/无模板
    异常 --> 已计算: HR处理异常
    已发放 --> [*]
```

规则：
- 必须有起始 `[*]` 和终态 `[*]`
- 每条迁移必须标注触发条件（who/what 触发）
- 异常状态必须有恢复路径

→ `02-flows/state-machine.md`

两图都**STOP** 等用户确认。


path: references/step3-validation.md
content: # Step 3 — 7 条机械校验

输出 ✅/❌ 清单。任一 ❌ 打回对应输入项。

| # | 检查项 | 不通过的标志 |
|---|---|---|
| 1 | 角色完整性 | 痛点/期望提到的角色不在 roles.md |
| 2 | 角色必要性 | roles.md 中角色未在痛点或期望出现 |
| 3 | 痛点可解性 | 痛点描述无法靠流程系统解决（如"老板不重视"） |
| 4 | 期望具体性 | 出现"智能/自动/好用/方便"等模糊词且无具体动作 |
| 5 | 角色-期望对应 | 期望中操作没有明确角色主语 |
| 6 | 闭环性 | 期望共同推导的流程没有终态 |
| 7 | **业务流三段完整性** | 缺少以下任一段：① 输入来源（外部取数/用户录入/定时触发/上游流程）② 流转中间节点（处理/审核/计算/分配类动作）③ 输出去向（落库归档/通知下游/推送用户/对外发布） |

每个 ❌ 必须给出**具体修复建议**（指出缺什么 + 给示例）。

全部 ✅ 才能进 Step 4。


path: references/selfcheck.md
content: # 附录 — 自检清单（Step 7 后执行）

完成全部交付后逐项自检，输出 ✅/⚠️ 清单。

## 完整性
- [ ] 每个 roles.md 角色都至少在 1 个用户故事中出现
- [ ] 每条 expectations.md 期望都至少映射 1 个故事
- [ ] 每个用户故事的主要动作在泳道图中有节点
- [ ] 每个核心业务对象有状态机图
- [ ] 每个 ER 实体在功能模块的"关联实体"中出现
- [ ] 每个 P0 操作节点在 RBAC 矩阵中有权限规则
- [ ] 每个 P0 操作节点在埋点规划中有至少 1 个事件
- [ ] PRD 12 节齐全，无空节

## 一致性
- [ ] 角色名在 roles.md / 用户故事 / 泳道图 / RBAC 中拼写完全一致
- [ ] 字段名在 ER 模型 / 功能模块 / 字段总览中一致
- [ ] 状态名在状态机图 / 模块"后置结果" / RBAC 中一致

## 决策溯源
- [ ] 03.5-field-decisions.md 中所有决策项都已被用户填写（无空白）
- [ ] PRD 第 12 节包含了所有"用户拍板的高风险决策"
- [ ] 没有任何 AI 自行决定却未让用户确认的字段/规则

## 缺口标记
- [ ] 所有 `[TODO:]` 标注都明确说明"需要补什么"，没有空 TODO

## 原型自检（来自 Step 7.1）
- [ ] 5 项原型自检全部通过

输出格式：
```
✅ 全部通过 → 设计完成
⚠️ 待补 N 项 → 列出每项 + 修复建议
```


path: references/step2-input-collection.md
content: # Step 2 — 输入收集（4 子步）

收集 4 项输入，期间不允许返回。收完进 Step 3 校验。

## 2.1 产品概述

**🔴 领域偏移检测（前置）**：扫描会话历史，若新概述核心名词与已声明领域明显不同（如"质检"→"薪酬"），暂停并询问：
> "我注意到你之前提到的是【X】，现在是【Y】。这是：(a) 完全更换需求 (b) Y 是 X 的子模块 (c) 我理解错了？"
确认后才继续。

询问方式：
> "请用 1-3 句话描述你想做的产品。示例：『我要做一个内容质检流程系统，让运营人员配置质检模板，质检员在线完成质检，组长审核结果。』"

追加 1 个澄清问题：业务领域细分（动态生成 4-5 个选项 + "其他"）。

→ 保存 `00-input/overview.md`（含"概述"+"业务领域"两节）

## 2.2 角色（结构化角色卡）

> "请列出本流程涉及的所有角色，每个角色用一句话描述其职责。示例：质检员 — 执行质检任务、提交结果"

→ 解析为表格 `| 角色名 | 一句话职责 |` 保存到 `00-input/roles.md`

## 2.3 痛点（按角色组织）

> "请按角色描述当前业务的痛点。示例：- 质检员：线下质检效率低"

校验：每条痛点提到的角色必须在 roles.md。→ `00-input/pain-points.md`

## 2.4 期望（按角色组织）

> "请按角色描述你希望产品长什么样。示例：- 运营：可在线配置质检模板"

校验：拒绝"无"，每条必须有动词。→ `00-input/expectations.md`

收完 4 项 → 进 Step 3 校验。


path: references/step6-modules-er.md
content: # Step 6 — 功能模块 + ER 模型 + 字段

## 6.1 ER 模型（吸收自 create-prd ch10 三步法）🆕

先于功能模块。从用户故事和状态机中提取实体：

**三步法**：
1. **识别实体**：流程中的核心名词（如 薪酬模板、工资单、员工、岗级）
2. **定义属性**：每个实体的字段
3. **定义关系**：1:1 / 1:N / N:N，标注关系名

输出 Mermaid `erDiagram`：
```
erDiagram
    SALARY_TEMPLATE ||--o{ PAY_SLIP : 适用于
    EMPLOYEE ||--o{ PAY_SLIP : 拥有
    EMPLOYEE }o--|| GRADE : 属于
    GRADE ||--o| SALARY_TEMPLATE : 启用模板
    SALARY_TEMPLATE { string id PK; string name; enum status; }
    PAY_SLIP { string id PK; string month; number actualAmount; enum status; }
```

→ `03-er-model.md`

## 6.2 功能模块（三层结构）

读取 `03.5-field-decisions.md` 用户决策，生成：

```
## 模块 MX: <模块名>
**关联用户故事**: US-XXX
**关联实体**: 引用 ER 模型中的实体名

### 操作节点 MX.Y: <操作名>
- **角色**: ...
- **触发**: 主动操作 / 系统触发 / 定时
- **前置条件**: ...
- **字段**:
  | 字段名 | 类型 | 必填 | 约束 | 关联实体 |
  |---|---|---|---|---|
- **后置结果**: ...（含状态机迁移）
```

字段类型限定: string/number/bool/enum/date/datetime/array/object/file/reference

→ `04-modules.md`，**STOP** 等用户确认。


path: references/step6.5-rbac-tracking.md
content: # Step 6.5 — RBAC 权限矩阵 + 数据埋点规划

## 6.5.1 RBAC 权限矩阵（吸收自 create-prd ch12）🆕

输出**两张表**：

### 功能权限矩阵
```
| 模块/操作 | HR | 管理者 | 员工 |
|---|---|---|---|
| M1 薪酬模板-新建 | ✅ | ❌ | ❌ |
| M1 薪酬模板-启用 | ✅ | ❌ | ❌ |
| M3 工资发放 | ✅ | ❌ | ❌ |
| M4 看板-查看 | ❌ | ✅ | ❌ |
| M5 我的工资条-查看 | ❌ | ❌ | ✅ |
```

### 数据权限规则
```
| 角色 | 可见数据范围 | 规则来源 |
|---|---|---|
| HR | 全公司所有员工工资单 | 决策清单 D-XXX |
| 管理者 | 仅本人所辖部门及下级部门员工 | 按部门隶属（D-XXX） |
| 员工 | 仅本人 | 用户ID = 登录ID |
```

每条规则必须能从 Step 5.5 决策清单或用户输入溯源，**不允许凭空发明**。

→ `05-rbac-matrix.md`，**STOP** 等用户确认。

## 6.5.2 数据埋点规划（吸收自 create-prd ch11）🆕

为 PRD 中每个 P0 操作节点定义关键事件。表格：

```
| 事件名 | 触发时机 | 关键属性 | 用途 |
|---|---|---|---|
| template_created | M1.1 模板新建成功 | 模板ID, 岗级, 薪酬项数 | 监控 HR 配置活跃度 |
| salary_calc_triggered | M2.1 系统触发计算 | 月份, 员工总数, 异常数 | 监控计算成功率 |
| salary_released | M3.1 HR 触发发放 | 月份, 员工总数, 实发总额 | 监控发放及时性 |
| payslip_viewed | M5.1 员工查看 | 员工ID, 月份 | 监控员工活跃度 |
| payslip_pdf_downloaded | M5.2 PDF下载 | 员工ID, 月份 | 监控下载频次 |
```

规则：
- 每个 P0 操作节点至少 1 个事件
- 关键属性必须可统计（避免高基数自由文本）
- "用途"必须明确，不能写"以备后用"

并定义**核心指标**：
- 北极星指标：例如"工资发放及时率 = 当月按时发放员工数 / 应发员工数"
- 健康指标：例如"计算异常率"、"员工查看率"

→ `06-tracking-plan.md`，**STOP** 等用户确认。


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)