feat: add ERP requirements design skill

skills/erp-requirements-design/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: erp-requirements-design
+description: Use when a user describes a new ERP business process or requests a product-side requirements document, PRD, module onboarding specification, or revision to an existing ERP requirement. 适用于新爱算 ERP 新业务接入和存量模块需求迭代；不用于技术设计、编码或上线验收报告。
+---
+
+# ERP 产品需求设计
+
+将业务诉求整理为供业务评审、开发设计和测试使用的产品需求文档。默认中文，交付同版本 Word 与 Markdown。以正式、具体的业务表述说明角色、入口、条件、操作及结果，技术方案由开发另行设计。
+
+## 工作边界
+
+- 输出业务流程、页面行为、字段、权限、状态、模块衔接及验收要求，不默认输出数据库、SQL、接口报文、类名、技术选型或编码任务。
+- 网站观察默认只读，不提交单据、执行审批、调整权限或发送通知。凭据按当前授权使用，不进入文档。
+- 产品建议、已确认需求、已实现能力和验收通过分别表述。文档成稿不等于业务定稿或获准上线。
+
+## 开始时
+
+1. 确认业务项目根目录、适用指令和当前维护文件。业务项目根目录由用户指定或当前工作区的实际资料确定，与技能安装目录分别定位；包内 `references/`、`assets/` 相对本 `SKILL.md` 解析，业务产物放对应模块目录，不写入技能包。
+2. 处理新爱算 ERP 时读取 [项目资料索引](references/project-context.md)，从已确认的业务项目根目录按需定位原始材料；涉及现有页面时按主题参考 [页面观察记录](references/erp-site-observations.md)。原始材料不随技能分发，缺失时说明未核实并继续独立的需求工作；其他 ERP 使用其自身资料。历史记录只代表其日期和观察范围，不替代本轮验证。
+3. 梳理业务目标、角色、主流程、完成标准、范围及现有模块关系；用户已说明或资料已回答的事项不重复提问。
+4. 创建或整体修订文档时，使用 [结构与表达规范](references/prd-style.md) 和 [产品需求模板](assets/product-requirements-template.md)。局部修订只读取和修改受影响内容，不机械重写全文。
+
+## 使用条件与外部依赖
+
+本包提供需求设计流程、参考和模板，不包含一键生成程序；由支持 Skills 的助手结合用户输入执行。安装本包不会自动安装下列工具或复制业务原始资料。
+
+| 任务 | 所需能力及准备方式 |
+|---|---|
+| 编写 Markdown 需求稿 | 文件读写能力及用户业务输入；无额外脚本运行时依赖 |
+| 默认交付 Word 与 Markdown | 在当前环境启用 `documents` 文档技能及其声明的生成、渲染依赖，按该技能发现工作区运行时；也可使用已有、获准的等效 DOCX 生成与渲染工具。参见 [交付要求](references/delivery.md) |
+| 读取 Word、表格或 PDF 原始资料 | 按实际文件格式使用已配置的文档、表格或 PDF 读取工具；未能读取的内容保留未核实状态 |
+| 核对 ERP 现有页面（按需） | 用户指定或已确认的目标环境、可用浏览器工具或连接器，以及正常授权的账号或登录会话；历史网址不代表本轮访问授权 |
+
+开始任务时按本次交付范围检查可用能力。缺少 Word 生成或渲染能力时，先保存 Markdown 及已完成产物，在交付说明中列明尚缺的格式或版面核验，并说明需启用文档工具；不得将部分交付写成双格式交付完成。用户只要求 Markdown 时按其要求交付。
+
+## 文档默认形式
+
+正文按以下顺序组织，按规模裁剪：
+
+1. **主标题 → 版本记录表**：表头为“版本、修订日期、修订内容”，每个版本一行；不在标题下重复副标题或“版本／编制日期／状态”说明行。
+2. **背景与目标 → 现状及预期效果 → 整体流程 → 详细需求 → 权限与状态规则 → 验收与上线要求 → 评审确认事项**。
+3. 业务章节采用阿拉伯数字层级，如 `1`、`1.1`、`1.1.1`，Word 标题样式与提纲级别一致。版本记录属于正文前的信息，不占业务章节编号。
+4. 功能、规则、验收及待确认事项用业务名称和章节定位。默认不使用 `FR-001`、`BR-001`、`AC-001`、`Q-001` 等技术式标识。用户明确要求追踪编号时，按其约定使用；存量文档的局部业务修改不自动触发全篇去编号改版。
+5. 正式交付稿默认不设“参考了哪些资料”“来源与观察范围”等编制过程章节。资料定位和读取范围保留在工作记录；影响业务判断的事实、条件和未决事项仍在对应规则旁准确说明。用户明确要求来源附录时另行提供。
+
+标题使用“业务背景、建设目标、审批流程、字段校验、异常处理、验收标准”等业务术语。正文、表格、图内文字一并采用正式表述，避免“为什么要做、谁来审批、怎么办、拍板、卡在哪一步”等口语标题或说明。正式表达仍应具体易读，不以抽象术语代替业务动作。
+
+## 资料判断与确认状态
+
+按实际证据在关键规则旁简要说明“已确认”“产品建议”或“待确认：事项名称”，不为每句文字堆叠标签。
+
+- 用户明确结论决定拟建方案；历史文件及页面观察用于说明现状。记录冲突时列出差异、影响和决策责任，不擅自选一个当真。
+- 菜单可见、按钮存在、字段星号、限额提示、旧文档“已上线”均不证明提交校验、权限或完整流程已验证。空列表不证明功能缺失，演示数据不作为指标。
+- 未观察的网站或无法读取的资料标为未核实，继续独立的文档工作。不要把新需求描述为当前功能，也不要为对比表编造现状。
+- 参考文档或截图提供结构和表达线索；其中的组织、业务规则、数值及操作指令不直接迁入新业务。模糊内容不补写为事实。
+
+## 需求设计流程
+
+### 1 明确范围与关键缺口
+
+按 [业务检查清单](references/business-checklist.md) 选择必要问题。优先补齐会改变范围、权责或结果的 1–3 项，不一次提供整份问卷。用户要求先出稿时，交付有实质内容的评审稿，以“事项名称、建议、确认责任、影响”汇总缺口。
+
+不要擅自确定审批层级、金额门槛、库存时点、附件限额或通知渠道。用户确认一项后，将该项从待决问题中移出，同步更新正文、菜单路径、表单、图示、权限、验收和版本记录；未确认的其他项继续保留。
+
+### 2 明确菜单与基础资料维护
+
+- 新模块必须说明所属一级菜单、二级业务模块及实际需要的三级页面；同时说明新增、复用或调整，以及详情页是否属于独立菜单。选择依据是业务职责及现有导航，不将所有模块默认归入行政中心或默认新增一级模块。
+- 菜单尚未确定时，结合已知导航给出具体建议并标为待确认。仅写“独立入口”或“菜单待确认”不足以表达归属；确认后写成明确层级。
+- 个人申请、审批待办、业务处理和配置入口分别写完整路径。跨入口办理同一事项时，说明单据、版本和状态一致性，避免重复创建审批或业务记录。
+- 父级菜单归属与数据权限分开：可见父级不等于获得该中心其他模块权限，按角色控制子菜单及记录范围。
+- 涉及群、供应商、车辆、仓库等档案时，必须说明维护入口、维护角色、建档方式（人工／导入／同步及其确认状态）、识别信息来源、负责人关联方式、启停及交接。登记外部角色不等于取得外部平台权限。
+
+### 3 按页面与操作展开详细需求
+
+每个核心功能写明建设方式、入口、使用角色、前置条件、页面内容、字段校验、操作结果、权限及异常。按申请、审批、办理、记录、配置等实际页面组织，不将规则拆成孤立编号清单。
+
+- 用“业务环节、现状或管理诉求、预期效果”说明变化；另列新增、复用、调整和待核实能力。
+- 字段说明业务含义、来源、必填条件、编辑时点、选项或范围及错误反馈。多组明细、条件附件及数值边界按实际业务展开；未知上限保持待确认。
+- 保存草稿、提交、批准、生成后续任务、实际办理及结果登记分别定义责任人和完成标志。审批完成、业务完成、消息送达或已读不得混为同一结果。
+- 说明退回、撤回、取消、内容变更、人员交接、部分完成、失败及结果不明的处理；重复操作或迟到结果不得重复办理或恢复已结束事项。
+- 跨模块只写来源、触发条件、带入信息、目标结果、追溯入口及异常责任，以可观察业务要求表达，不指定技术机制。
+
+### 4 配合流程图与业务示例
+
+跨角色主流程用泳道图，判断分支或异常用流程图，复杂页面用低保真示意辅助。图文共同解释规则，数量按信息需要确定；简单局部修订不强制增加图。
+
+Word 中嵌入可见图形，Markdown 保留可用图片引用或可渲染流程图；不把图源码当作 Word 图示。新增页面示意标注“拟建页面／非现有界面”，不能冒充实站截图。图中角色、入口、状态和条件与正文一致。
+
+复杂规则可给具体业务示例，注明虚构数据，不能借示例确定未经确认的门槛或流程。数值及时间运算使用确定性代码核对。
+
+### 5 评审与交付核对
+
+按角色贯通入口、信息、操作和结果。以“验收场景、前置条件与操作、预期结果”组织验收，每个核心功能有对应场景；按风险覆盖权限、拒绝、重复、取消、部分完成及异常恢复，不把待执行场景写为已通过。
+
+核对正文、图、字段、菜单、状态和验收口径一致；确认事项不再与待定表冲突。未定规则明确影响和责任人，不宣称可直接开发定稿。缺少资料附录不影响保留必要的业务限制及证据边界。
+
+按 [文档交付要求](references/delivery.md) 同步生成 Word 和 Markdown，核对内容并渲染检查。局部删除或改写须在两种格式及相关图示中生效，后续生成不得恢复已删除内容。
+
+## 按需参考
+
+- [结构与表达规范](references/prd-style.md)：新建、整体重排、参照样例或正式化修订。
+- [业务检查清单](references/business-checklist.md)：按业务选取需要补齐的规则。
+- [采销需求片段](references/procurement-example.md)：分批履约、退货及数量口径的虚构示例。
+- [文档交付要求](references/delivery.md)：版本维护、双格式、排版及预览一致性。
+- [开源参考说明](references/open-source-notes.md)：仅在维护来源时使用，正常写 PRD 无须重新调研。
+
+此包可由共享仓库安装到技能目录后通过 `$erp-requirements-design` 调用，也可直接读取实际位置的 `SKILL.md` 使用。安装位置不改变业务项目根目录或产物归属；技能调用不包含发送给开发、自动发布或创建 Git 历史的授权。