it235 PM Requirement Spec（产品经理需求规范 · 内容）
Purpose
把 Issue、会议结论、零散想法变成清晰、可评审、可拆任务的 PRD 内容（只管「写什么」，不管「落到哪个平台」）。
与
multica-pm-artifact-publish分工：本 skill = 需求规范与编号；publish = Confluence / JIRA 创建与更新。换平台只改 publish，不动本 skill。
Platform 协作
| Platform skill | 本 skill 用途 |
|---|---|
团队知识库（可选） |
Step 0.5 查术语、历史需求背景（参考，不当新 AC） |
multica-platform-jira / multica-platform-confluence |
不直接调用；读写由 multica-pm-artifact-publish 编排 |
智能体指令见 references/agent-instructions.md。
两阶段（规范 ≠ 提交）
| 阶段 | 动作 | 停止点 |
|---|---|---|
| A 结构化 | 采集 + KB → 编号 PRD 草稿 | 交付 Markdown/HTML 草稿 + 修订记录 |
| B 提交 | 用户/Leader 确认范围后 → multica-pm-artifact-publish |
回传 Confluence + JIRA 链接 |
Review 后修订：回到阶段 A 改内容 → 再调 publish 更新（非重复创建）。详见 publish skill Workflow B。
Step 0.5 — 知识库（用法二分）
调用 团队知识库（可选） → kb_ask.py（禁止 SSH/curl）。
| 信息类型 | 能否写进 PRD | 写哪里 |
|---|---|---|
| 术语、模块边界、历史背景 | 参考 | 背景/修订记录/OP- 引用 |
| 菜单路径、权限名、字段别名（当前需求相关） | 应当使用 | FR-/BR-/AC- 可执行描述 |
| 历史规则、他系统口径、当前需求未写的字段 | 禁止当新 FR/AC | 仅背景；冲突以当前 Issue 为准 |
138 不可用：标注「知识库不可用」，不阻断结构化；禁止臆造业务规则。超时停轮见 platform KB SKILL。
Process
- 识别业务目标（G- + KPI-）
- 用户角色 / 权限
- 范围（含 / 不含）与非目标
- 约束（兼容性 / 性能 / 安全 / 时间）
- 验收标准（AC-，可测试）
- 歧义 → OP- 待确认清单
- 依赖与风险（RISK-）
Requirement Structure
章节基线见 multica-platform-confluence 的 scripts/templates/prd-template.md：
| 章节 | 编号 |
|---|---|
| 一句话定义、背景 | — |
| 目标与成功标准 | G- + KPI- |
| 用户故事 | U- |
| 功能需求 | FR- |
| 业务规则 | BR- |
| 验收标准 | AC- |
| 待确认项 | OP- |
| 风险项 | RISK- |
正式 PRD 至少包含：一句话定义、背景、G-/KPI-、用户与权限、范围、FR-/BR-/AC-、字段口径、空态/异常态/无权限态、RISK-/OP-、修订记录。
Output
- 目标（G-）、范围、非目标
- 验收标准（AC-）、约束、依赖
- 待确认项（OP-）、风险（RISK-）
- 修订记录：版本号、日期、变更摘要（Review 修订后必递增）
Rule
歧义会实质影响实现 → BLOCKED → 说明缺什么、谁提供，只问 1 个最关键问题。
Review 后修订（与 multica-review-product）
| Review 结论 | PM 动作 |
|---|---|
| FAIL | 按修改清单改 PRD 编号条目 → 更新修订记录 → multica-pm-artifact-publish Workflow B 更新 → 请 ProductReviewer 复审 |
| PASS | 交 Leader multica-verification；OP- 未关闭项仍不得进开发 |
ProductReviewer 只评不改；PM 在用户/Leader 授权「按 review 修订」后执行修订。
Handoff
1. multica-pm-requirement-spec — 结构化 PRD（本 skill）
2. multica-pm-artifact-publish — Confluence + JIRA 创建/更新 + 可选钉钉
为什么有效
需求歧义在下游放大。编号 + OP- 清单 + KB 背景（不扩 scope）让 PRD 可评审、可测；内容与平台解耦，Review 后可二次更新而不重复建 Story。