odoo-forge-bundle 0.1.0

package/payload/skills/prd/references/section-guide.md

@@ -0,0 +1,191 @@
+# PRD 章节深度标准
+
+本文件用于约束 `prd` 在各章节里“要写到多深才算够用”。
+
+目标不是把文档写得很长，而是让 `trd` 和 `uat` 读完后不用再猜。
+
+## 一、用户故事与范围
+
+### 先总后分的做法
+
+先列 EPIC 的能力总览或闭环清单，再拆用户故事。
+
+不要一开始就零散写故事，结果最后才发现边界没圈住。
+
+### 每条用户故事至少要满足
+
+- 有明确角色，不要只写“用户”
+- 有具体操作，不要只写“管理”“维护”
+- 有可观察结果，要能看到状态、数据、通知或页面变化
+- 有验收标准，不能只写“支持”
+- 有来源，尽量标明来自 `BRD`、`Solution`、EPIC 概述或 `GAP-N`
+
+推荐格式：
+
+```markdown
+| ID | 角色 | 操作 | 期望结果 | 验收标准 | 来源 |
+|----|------|------|----------|----------|------|
+| US-01 | {角色} | {操作} | {结果} | {标准} | {来源} |
+```
+
+### 范围排除必须写清楚
+
+`PRD` 不是只写“做什么”，还要写“不做什么”。
+
+至少回答：
+
+- 哪些能力明确在本 EPIC 内
+- 哪些能力明确不在本 EPIC 内
+- 不做的原因是什么
+- 如果归到其他 EPIC，要写清归属
+
+## 二、业务对象与信息
+
+### 先列对象总览，再展开重点对象
+
+如果对象较多，先列一张对象总览表，再逐个展开主对象和关键从属对象。
+
+### 怎么写才够用
+
+- 写业务含义，不直接写技术实现
+- 写关键信息项，不要只写对象名
+- 当字段渲染方式会明显影响交互时，可以写 `渲染方式`
+- 说明对象是新建还是在现有对象上扩展
+- 如果对象或字段受 `Solution` 里的 `GAP` 影响，要显式标注来源
+
+### 不够用的写法
+
+- 只列字段名，没有说明
+- 只有对象，没有对象关系
+- 只写“支持录入”，没说录什么、为什么录
+
+## 三、业务逻辑
+
+这是 `PRD` 最核心的章节，默认拆成四层：
+
+1. 主流程
+2. 分支与异常处理
+3. 状态机
+4. 业务规则分类
+
+### 1. 主流程
+
+目标：
+
+- 让人看懂 happy path 怎么走完
+- 让 `trd` 知道每一步谁操作、系统做什么
+
+推荐组合：
+
+- Mermaid 图
+- 步骤说明
+
+当多角色顺序配合明显时，优先用 `sequenceDiagram`。
+当分支决策多时，优先用 `flowchart`。
+
+### 2. 分支与异常处理
+
+至少覆盖：
+
+- 取消
+- 驳回
+- 退回重提
+- 超时
+- 无数据或缺数据时的处理
+- 例外权限
+
+不要只有主流程，没有异常路径。
+
+### 3. 状态机
+
+当对象存在阶段性流转时，尽量补状态图和状态转换表。
+
+状态转换表至少写：
+
+- 起始状态
+- 目标状态
+- 触发操作
+- 操作角色
+- 前置条件
+- 系统动作
+
+### 4. 业务规则分类
+
+推荐至少分成下面四类：
+
+- 校验规则
+- 自动计算
+- 自动化动作
+- 编号 / 命名规则
+
+如果有审批、锁定、例外授权，也可补充对应规则表。
+
+## 四、页面与菜单
+
+### PRD 在页面章节里要回答什么
+
+- 这个 EPIC 需要哪些视图
+- 主工作界面是什么
+- 关键操作从哪里进入
+- 菜单层级怎么组织
+
+`PRD` 不需要写到 XML 或技术属性层，但不能只写一句“有个表单页”。
+
+### 什么时候调用 `view-spec`
+
+以下情况优先调用 `view-spec`：
+
+- 有状态机或明显工作流
+- 有多个头部按钮
+- 有明细行、统计或复杂表单结构
+- 这是 EPIC 的主工作界面
+
+以下情况可以只写简洁版说明：
+
+- 纯 CRUD 配置页
+- 字段很少的简单从属对象
+- 只读统计页
+
+## 五、角色与权限
+
+权限要用业务语言写，让产品、业务和研发都看得懂。
+
+推荐至少回答：
+
+- 谁能看到哪些数据
+- 谁能创建
+- 谁能编辑
+- 谁能删除
+- 谁能推动状态变化
+- 谁在什么情况下有例外权限
+
+不要直接写技术 domain，也不要只写“按角色控制”。
+
+## 六、按需章节
+
+### 外部接口
+
+只有和第三方系统有明确交互时才写。
+
+### 报表与打印
+
+当 EPIC 明确包含统计、透视、图表、打印单据时再写。
+
+### 配置项
+
+当存在可以影响业务行为的可配置开关、阈值或策略时再写。
+
+没有内容就不要硬保留空章节。
+
+## 七、常用辅助 skill
+
+- `view-spec`
+  - 用于复杂视图规格下钻
+- `mermaid-diagrams`
+  - 用于流程图、状态图、时序图
+- `industry-practice`
+  - 用于判断某些流程和规则在行业里通常做多严、多细
+- `company-rules`
+  - 用于审批、编号、归档、签署、质控、交付规范相关补充
+- `review`
+  - 当本次有实质写回，且准备交给下游时做快速审查

package/payload/skills/review/SKILL.md

@@ -0,0 +1,249 @@
+---
+name: review
+description: Odoo Forge 通用文档审查 skill。用于审查 BRD、Solution、PRD、TRD、UAT 的完整性、一致性、Odoo 适配性和交付就绪度。当用户提到“审查文档”“review 一下 BRD / Solution / PRD / TRD / UAT”“看看有没有问题”“能不能进入下一阶段”“做质量门检查”时必须使用。它不负责共创正文，而是作为横切质量门检查已有文档，并在需要时调用行业、公司制度、官方文档或模块类 skill 补证据。
+---
+
+# 文档审查
+
+## 你是谁
+
+你是 Odoo Forge 的通用文档审查员。
+
+你的职责不是写文档，而是作为横切质量门检查已有文档的质量，帮助团队回答四个问题：
+
+1. 这份文档有没有明显缺失
+2. 这份文档有没有前后冲突
+3. 这份文档是否顺着 Odoo 心智模型
+4. 这份文档现在够不够进入下一阶段
+
+你可以按需调用：
+
+- `industry-practice`
+- `company-rules`
+- `odoo18-docs`
+- `module-research`
+- `module-report`
+- `view-dev`
+
+但你自己负责统一收敛结论，不把 subagent 的原话直接当最终报告。
+
+## 什么时候使用
+
+以下场景必须使用本 skill：
+
+- “帮我审查一下这份 BRD / Solution / PRD / TRD / UAT”
+- “看看这份文档还有没有问题”
+- “这份文档能不能进入下一阶段”
+- “做一次质量门检查”
+- 共创 skill 在一次实质更新后，需要做快速复核
+- 文档准备锁定前，需要做完整审查
+
+以下情况不要用本 skill：
+
+- 还没有可审查的文档，应该先去共创正文
+- 只是想问一个行业问题，用 `industry-practice`
+- 只是想问一个公司制度问题，用 `company-rules`
+- 只是想查官方能力边界，用 `odoo18-docs`
+
+## 必需上游上下文
+
+| 上游内容 | 必需性 | 用途 | 缺失时怎么做 |
+|----------|--------|------|--------------|
+| `全局资源` 页面及其子页 | 必需 | 恢复项目背景、组织、术语、约束 | 如果没有，明确说明审查可信度受限 |
+| 当前要审查的文档 | 必需 | 作为审查对象 | 没有就停止，不做伪审查 |
+| 当前业务域根页面下的页面 `待确认事项` | 推荐 | 判断当前未决问题和重复问题 | 没有则先创建 |
+| 必要的上下游文档 | 视文档类型而定 | 判断一致性和可交付性 | 缺失时在报告中明确指出 |
+
+## FlowUS 页面怎么找
+
+本 skill 的正式上下文只来自 FlowUS。
+
+进入项目文档时，默认按下面的顺序定位：
+
+1. 先定位根页面 `产品设计`
+2. 读取 `产品设计` 的页面树
+3. 进入子页面 `全局资源`
+4. 再进入当前业务域根页面
+5. 在业务域根页面下读取：
+   - `BRD`
+   - `Solution`
+   - `待确认事项`
+   - 相关 EPIC 页面及其 `PRD / TRD / UAT`
+
+如果当前业务域根页面下还没有页面 `待确认事项`，先创建页面 `待确认事项`。
+
+## 三种工作模式
+
+### 模式一：快速审查
+
+适合：
+
+- 共创过程中一次实质更新后的快速复核
+- 被其他 skill 作为 subagent 调用
+
+输出目标：
+
+- 快速指出关键问题
+- 提醒是否应写入页面 `待确认事项`
+- 给出是否建议继续往下推进的短结论
+
+### 模式二：完整审查
+
+适合：
+
+- 文档准备锁定前
+- 用户明确要求“完整 review”
+
+输出目标：
+
+- 给出结构化审查报告
+- 按严重程度归类问题
+- 明确说明是否建议进入下一阶段
+
+### 模式三：阶段 Gate
+
+适合：
+
+- `BRD -> Solution`
+- `Solution -> PRD`
+- `PRD -> TRD`
+- `TRD -> DEV`
+- `UAT -> 执行验收`
+
+输出目标：
+
+- 判断当前文档是否达到进入下一阶段的最低标准
+- 明确红旗问题
+- 给出 `可以进入 / 补充后进入 / 暂不建议进入` 结论
+
+## 文档类型路由
+
+| 文档类型 | 必读内容 | 默认检查清单 | 默认 subagent |
+|----------|----------|--------------|---------------|
+| `BRD` | `全局资源 + BRD + 待确认事项` | `references/brd-checklist.md` | `industry-practice`、`company-rules` |
+| `Solution` | `全局资源 + BRD + Solution + 待确认事项` | `references/solution-checklist.md` | `industry-practice`、`company-rules`、`odoo18-docs` |
+| `PRD` | `全局资源 + BRD + Solution + PRD + 待确认事项` | `references/prd-checklist.md` | `industry-practice`、`company-rules` |
+| `TRD` | `全局资源 + Solution + PRD + TRD + 待确认事项` | `references/trd-checklist.md` | `company-rules`、`odoo18-docs`、`view-dev` |
+| `UAT` | `全局资源 + PRD + TRD + UAT + 待确认事项` | `references/uat-checklist.md` | `industry-practice`、`company-rules` |
+
+## 通用审查流程
+
+1. **识别审查对象**
+   确认当前文档类型、所在业务域、当前工作模式。
+2. **读取 FlowUS 上下文**
+   先读 `全局资源`，再读当前文档、必要上下游文档和页面 `待确认事项`。
+3. **加载对应清单**
+   按文档类型读取对应 checklist，不混用检查点。
+4. **逐项检查**
+   至少覆盖：
+   - 完整性
+   - 一致性
+   - Odoo 适配性
+   - 交付就绪度
+5. **按需补证据**
+   当某个判断涉及行业常规、公司制度、官方能力或模块选型时，再调用对应 subagent。
+6. **处理未决问题**
+   如果发现某个问题现在还不能定论，但会影响后续判断，建议写入当前业务域根页面下的页面 `待确认事项`。
+7. **输出报告**
+   使用 `references/output-template.md` 的结构输出结果。
+   如果是阶段 Gate，再结合 `references/gate-rules.md` 给出阶段结论。
+
+## Subagent 调用规则
+
+### 审 `BRD`
+
+- 默认可调 `industry-practice`
+  - 用途：补行业常规做法、识别表面诉求、找行业盲区
+- 默认可调 `company-rules`
+  - 用途：补公司制度相关的流程、审批、签署、归档、会签、编号、质量控制要求
+
+### 审 `Solution`
+
+- 默认可调 `industry-practice`
+- 默认可调 `company-rules`
+- 默认可调 `odoo18-docs`
+- 按需调 `module-research`
+- 按需调 `module-report`
+
+### 审 `PRD`
+
+- 默认可调 `industry-practice`
+- 默认可调 `company-rules`
+
+### 审 `TRD`
+
+- 默认可调 `company-rules`
+- 默认可调 `odoo18-docs`
+- 涉及视图实现时按需调 `view-dev`
+
+### 审 `UAT`
+
+- 默认可调 `industry-practice`
+- 默认可调 `company-rules`
+
+### 总原则
+
+- subagent 负责带回证据和建议
+- 你负责统一收敛最终审查意见
+- 不要为了显得全面而默认把所有 subagent 一起调用
+
+## 页面《待确认事项》处理
+
+所有审查发现的未决问题，都统一写进当前业务域根页面下的页面 `待确认事项`。
+
+只有在以下情况才建议加入页面 `待确认事项`：
+
+- 问题需要产品或业务确认
+- 如果不确认，会影响当前文档结论
+- 该问题会影响下游文档或阶段 Gate
+
+建议写法：
+
+```md
+- [ ] `review` {明确的问题句}
+  影响：{影响哪份文档或哪个关键块}
+  当前判断：{若有}
+```
+
+问题确认后：
+
+1. 先更新权威文档
+2. 再把页面 `待确认事项` 中的对应条目标记为 `- [x]`
+
+## 输出结构
+
+统一使用 `references/output-template.md` 的结构。
+
+报告至少应包含：
+
+- 审查对象
+- 整体判断
+- 阶段结论
+- 关键问题
+- 重要问题
+- 优化建议
+- 建议加入页面 `待确认事项`
+- 审查覆盖范围
+- 残留风险
+
+## 结束时给出的下一步建议
+
+审查结束后，只给自然建议，不强制路由。
+
+常见建议包括：
+
+- 先修正文档中的关键问题
+- 把若干问题加入页面 `待确认事项`
+- 补一次快速共创
+- 进入下一阶段
+- 锁定当前文档
+
+## Guardrails
+
+- 不替代主 skill 共创正文
+- 不直接重写权威文档
+- 不把未确认结论硬写成已定事实
+- 不把顾问意见伪装成事实
+- 不为凑完整而制造问题
+- 不忽略当前业务域根页面下的页面 `待确认事项`
+- 不越过 `references/gate-rules.md` 擅自放行阶段切换

package/payload/skills/review/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "文档审查"
+  short_description: "统一审查 BRD、Solution、PRD、TRD、UAT，判断质量和阶段就绪度"
+  icon_small: "./assets/icon-small.svg"
+  icon_large: "./assets/icon-large.svg"
+  brand_color: "#714B67"

package/payload/skills/review/assets/icon-large.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 919 495"><path d="M695,346a75,75,0,1,1,75-75A75,75,0,0,1,695,346Zm0-31a44,44,0,1,0-44-44A44,44,0,0,0,695,315ZM538,346a75,75,0,1,1,75-75A75,75,0,0,1,538,346Zm0-31a44,44,0,1,0-44-44A44,44,0,0,0,538,315Zm-82-45c0,41.9-33.6,76-75,76s-75-34-75-75.9S336.5,196,381,196c16.4,0,31.6,3.5,44,12.6V165.1c0-8.3,7.3-15.1,15.5-15.1s15.5,6.8,15.5,15.1Zm-75,45a44,44,0,1,0-44-44A44,44,0,0,0,381,315Z" style="fill:#8f8f8f"/><path d="M224,346a75,75,0,1,1,75-75A75,75,0,0,1,224,346Zm0-31a44,44,0,1,0-44-44A44,44,0,0,0,224,315Z" style="fill:#714b67"/></svg>

package/payload/skills/review/assets/icon-small.svg

@@ -0,0 +1,5 @@
+<svg width="400" height="400" viewBox="0 0 400 400" fill="none" xmlns="http://www.w3.org/2000/svg">
+<rect width="400" height="400" fill="white"/>
+<circle cx="200.5" cy="199.5" r="176.5" fill="#5D3854"/>
+<circle cx="200.5" cy="199.5" r="107.5" fill="white"/>
+</svg>

package/payload/skills/review/evals/evals.json

@@ -0,0 +1,23 @@
+{
+  "skill_name": "review",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "请 review 一下经营管理域的 BRD，看有没有遗漏的业务规则、异常流，以及是否缺少公司制度层面的补充点。",
+      "expected_output": "应触发 BRD 审查模式，读取全局资源、BRD、待确认事项，并按 BRD 清单输出结构化问题与阶段结论。",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "这份 Solution 准备定稿了，帮我做完整审查，重点看是不是顺着 Odoo 做、有没有过度定制、能不能进入 PRD。",
+      "expected_output": "应触发 Solution 完整审查或阶段 Gate，必要时调用官方文档或模块类 skill，输出是否建议进入 PRD。",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "请审查这个 EPIC 的 PRD、TRD、UAT 是否已经足够让研发开工并且后面能做验收，缺的问题帮我列出来。",
+      "expected_output": "应识别为多文档审查任务，至少对 PRD、TRD、UAT 分别使用对应清单，并指出关键缺口和待确认项。",
+      "files": []
+    }
+  ]
+}

package/payload/skills/review/references/brd-checklist.md

@@ -0,0 +1,43 @@
+# BRD 审查清单
+
+## 必须检查
+
+- 业务目标是否清楚，不只是功能列表
+- 角色是否完整，职责边界是否明确
+- 主流程是否闭环，是否有明确开始和结束
+- 异常流、驳回流、退回流是否覆盖
+- 业务规则、约束和口径是否明确
+- 业务对象是否足够支撑后续方案设计
+- 跨域依赖是否指出
+
+## 高价值检查
+
+- 有没有把表面诉求误写成真实需求
+- 有没有把旧系统补丁当成未来产品主路径
+- 有没有把“业务现在怎么干”直接等同于“未来系统应该怎么做”
+- 是否遗漏统计、追踪、留痕、审批说明
+
+## 制度补充检查
+
+审 `BRD` 时，要结合 `company-rules` 看一下是否存在明显不合理或缺失的制度性补充点，例如：
+
+- 审批层级是否明显少了必要角色
+- 会签、签署、编号、归档、留痕要求是否明显缺失
+- 质量控制、设计评审、设计输入、设计变更等制度性动作是否被漏掉
+
+这里不是把 BRD 写成制度文档，而是防止业务需求阶段漏掉明显制度边界。
+
+## 红旗信号
+
+- 只有页面或按钮，没有业务目标
+- 只有主流程，没有异常流
+- 只有操作步骤，没有规则口径
+- 只写“支持导入 / 支持审批 / 支持统计”，但没有解释真实问题
+- 关键对象、角色或跨域关系缺失
+
+## 适合加入页面《待确认事项》的典型问题
+
+- 某个审批动作是否必须增加会签角色
+- 某个流程是否必须保留纸面签字或电子留痕
+- 某个业务对象的编号、归档、签署口径是否已定
+- 某个业务规则是行业通用还是当前组织的临时做法

package/payload/skills/review/references/gate-rules.md

@@ -0,0 +1,73 @@
+# 阶段 Gate 规则
+
+## BRD -> Solution
+
+### 进入条件
+
+- 业务目标已清楚
+- 核心角色和主流程已成型
+- 关键规则和异常流已具备基本闭环
+- 没有决定性缺失会直接阻断方案设计
+
+### 红旗
+
+- 主流程都还没理清
+- 关键角色或对象缺失
+- 大量问题还停留在表面诉求
+
+## Solution -> PRD
+
+### 进入条件
+
+- 方案方向已基本收敛
+- 模块与能力蓝图清楚
+- 关键取舍和 GAP 已有结论
+- 没有关键路径上的方案未决项
+
+### 红旗
+
+- 方案仍停留在大量并列候选
+- 官方 / OCA / 定制边界没说清
+- 是否重定制都还没定
+
+## PRD -> TRD
+
+### 进入条件
+
+- 规则、状态、权限、视图和异常流已经足够清楚
+- TRD 不需要回头猜业务逻辑
+- 关键待确认项不再阻断技术设计
+
+### 红旗
+
+- 状态和规则未定
+- 关键交互未定
+- 权限边界不清
+
+## TRD -> DEV
+
+### 进入条件
+
+- 模块、模型、权限、视图实现思路清楚
+- 技术前提明确
+- 开发可以直接开工
+
+### 红旗
+
+- 核心模型或行为定义缺失
+- 权限 / 视图实现冲突
+- 关键依赖或实现边界未定
+
+## UAT -> 执行验收
+
+### 进入条件
+
+- 主路径和关键规则均有验收步骤
+- 验收步骤可执行
+- 预期结果明确
+
+### 红旗
+
+- 只有功能清单，没有操作闭环
+- 关键异常流没有验收
+- 非研发人员无法照着执行

package/payload/skills/review/references/output-template.md

@@ -0,0 +1,43 @@
+# 审查报告模板
+
+统一使用下面的结构输出。
+
+```md
+# 审查报告
+
+## 审查对象
+- 文档类型：
+- 审查模式：
+- 文档位置：
+- 审查依据：
+
+## 整体判断
+- 总体结论：
+- 是否建议进入下一阶段：可以进入 / 补充后进入 / 暂不建议进入
+- 原因：
+
+## 关键问题
+1. ...
+
+## 重要问题
+1. ...
+
+## 优化建议
+1. ...
+
+## 建议加入页面《待确认事项》
+- [ ] ...
+
+## 审查覆盖范围
+- 已检查：
+- 未展开：
+
+## 残留风险
+- ...
+```
+
+## 使用规则
+
+- `快速审查` 可以保留相同结构，但内容压缩
+- `完整审查` 应完整输出所有章节
+- `阶段 Gate` 必须明确写出“是否建议进入下一阶段”

package/payload/skills/review/references/prd-checklist.md

@@ -0,0 +1,39 @@
+# PRD 审查清单
+
+## 必须检查
+
+- 用户故事是否覆盖核心角色和目标
+- 业务规则是否明确
+- 状态机是否闭环
+- 权限边界是否清楚
+- 视图、菜单、入口是否清楚
+- 异常流、边界条件是否覆盖
+- 与 BRD、Solution 是否一致
+
+## 高价值检查
+
+- TRD 拿到后是否还需要猜业务逻辑
+- 是否存在模糊词：支持、适配、灵活、可配置，但没有具体定义
+- 是否存在状态、按钮、规则之间对不上的情况
+- 是否缺少影响交互的重要前置条件和后置结果
+
+## 交付就绪检查
+
+- 规则是否细到可以被技术设计接住
+- 页面行为是否清楚到可以继续下钻视图规格
+- 权限与流程的对应关系是否成立
+
+## 红旗信号
+
+- 只有流程，没有规则
+- 只有字段，没有行为
+- 只有 happy path，没有异常流
+- 视图描述和状态规则互相打架
+- “由系统判断”“按规则处理”但没有说规则是什么
+
+## 适合加入页面《待确认事项》的典型问题
+
+- 某个状态转换的真实触发条件未定
+- 某个角色是否应该有例外权限未定
+- 某个页面行为是否要走更简还是更严的流程未定
+- 某个业务规则的优先级或冲突处理未定