npm - odoo-forge-bundle - Versions diffs - 0.1.10 → 0.1.11 - Mend

odoo-forge-bundle 0.1.10 → 0.1.11

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (4) hide show

package/package.json +1 -1
package/payload/config/product.json +1 -1
package/payload/skills/module-report/SKILL.md +199 -301
package/payload/skills/module-report/agents/openai.yaml +1 -1

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "odoo-forge-bundle",
-  "version": "0.1.10",
+  "version": "0.1.11",
   "description": "Generated bundle payload for Odoo Forge internal 1.0.",
   "type": "module",
   "exports": "./index.js",

package/payload/config/product.json CHANGED Viewed

@@ -1,7 +1,7 @@
 {
   "name": "Odoo Forge",
   "slug": "odoo-forge",
-  "version": "0.1.10",
+  "version": "0.1.11",
   "description": "Unified Odoo agent toolkit for Codex and Claude Code.",
   "localInstallRoot": "~/.odoo-forge",
   "packages": {

package/payload/skills/module-report/SKILL.md CHANGED Viewed

@@ -1,389 +1,287 @@
 ---
 name: module-report
-description: Odoo 模块报告 skill。用于对已选定的模块、仓库或本地路径做深入阅读，生成完整模块报告，并写入 Notion 的“项目Wiki / 模块报告”。当用户需要“精读模块”“沉淀模块知识库”“生成模块报告”时使用；如果还在大范围找候选，则先用 module-research。
+description: Odoo 模块报告 skill。对已选定模块、仓库或本地模块路径做深入精读，结合 Notion 中的“项目 Wiki / 项目概览”判断项目相关度，生成完整报告并写回 Notion「📦 odoo 模块报告」数据库。用户提到“精读模块”“看看值不值得用”“生成模块报告”“把模块写进项目 Wiki 模块报告库”时使用；如果还在大范围找候选，则先用 module-research。
 ---
 # 模块报告
-## 定位
+## 1. 定位
-这是一个 Odoo 模块报告 skill。
+本 skill 只做三件事：
-它只负责：
+1. 精读已选定模块源码
+2. 结合项目背景给出项目口径的简介、评分和使用场景
+3. 将结果写回 Notion `📦 odoo 模块报告` 数据库
-1. 深入阅读已选定的模块或仓库
-2. 生成完整模块报告正文
-3. 将模块报告沉淀到 Notion 的模块知识库
+不要做这些事：
-它**不负责做大范围候选搜索**。如果用户还没确定要看哪个模块，先交给 `module-research`。
+- 不要在用户还没选定目标模块时替代 `module-research`
+- 不要只核实官方模块能力，这类问题交给 `odoo18-docs`
+- 不要脱离项目背景直接评分
+- 不要在 `项目 Wiki` 下新建“每仓库一个数据库”的并行结构
-## 必需上游上下文
+## 2. 先定位 Notion 上下文
-| 上游内容 | 必需性 | 用途 | 缺失时怎么做 |
-|----------|--------|------|--------------|
-| `全局资源` 页面及其子页 | 必需 | 判断模块对你们项目的推荐度、简介口径和使用场景 | 如果没有，仍可写报告，但要明确推荐度可信度下降 |
-| 目标仓库 / 模块 / 本地路径 | 必需 | 决定要精读什么 | 没有目标就停止，先让调用方回到 `module-research` |
-| `项目Wiki / 模块报告` 页面 | 建议 | 写入 Notion 模块知识库 | 如果没有，则先创建 |
-| 相关业务域的 `BRD / Solution` | 推荐 | 结合当前业务域判断该模块在你们项目中的实际使用场景 | 如果没有，则至少基于 `全局资源` 做判断，并说明适用范围仍较宽 |
+先按当前工作区的真实结构定位，不要假设存在旧的“全局资源”页面树。
-## 开始前先读什么
+### 2.1 先看见什么
-在进入模块源码之前，先用 Notion MCP 读取与你们项目有关的上下文，不要直接脱离项目背景写“推荐度 / 使用场景 / 简介”。
+1. 定位页面 `项目 Wiki`
+2. `fetch` `项目 Wiki`
+3. 在页面内容里确认至少存在两个 inline 数据库：
+   - `🏗️ 项目概览`
+   - `📦 odoo 模块报告`
-默认先读：
+如果 `项目 Wiki` 下没有这两个数据库，先停止并说明当前工作区结构与 skill 预期不一致。
-1. `产品设计 / 全局资源 / 项目背景`，了解项目范围、阶段和目标
-2. `产品设计 / 全局资源 / 组织架构`，了解谁会用、谁维护、谁审批
-3. `产品设计 / 全局资源 / 业务域全景图`，了解模块大概率落在哪些业务域
-4. `产品设计 / 全局资源 / 术语表`，避免模块概览里的术语和你们项目口径打架
-5. `产品设计 / 全局资源 / 现有系统清单`，判断是否涉及外部系统或现有系统边界
-6. 如果模块是为某个明确业务域筛出来的，再读该业务域的 `BRD / Solution`
+### 2.2 怎么读到项目级文档
-读这些内容的目的要明确：
+`项目背景`、`业务域全景图` 等并不是 `项目 Wiki` 的普通子页面；它们当前是 `🏗️ 项目概览` 数据库里的页面。
-- `简介`：写成适合你们项目口径的一句话，而不是照抄模块 README
-- `使用场景`：写清楚在你们项目的哪类业务域、流程、角色或需求下可以考虑
-- `推荐度`：结合你们项目背景判断是 `推荐 / 备选 / 谨慎`
+按下面顺序读取：
-## Notion 页面怎么找
+1. `fetch` `🏗️ 项目概览` 数据库，拿到真实 schema 和 view URL
+2. 查询 `🏗️ 项目概览` 的 `全部文档` 视图
+3. 在视图结果里找到并 `fetch` 这些页面：
+   - `项目背景`
+   - `业务域全景图`
+   - `组织架构`
+   - `术语表`
+   - `现有系统清单`
+   - `项目约束`
+4. 先把这些页面当作项目级公共上下文
-写入时默认按下面的顺序定位：
+不要跳过 `项目概览` 直接在全工作区盲搜 `项目背景`。优先沿着 `项目 Wiki -> 项目概览 -> 文档页面` 这条路径读取。
-1. 先定位根页面 `项目Wiki`
-2. 读取 `项目Wiki` 的页面结构
-3. 在 `项目Wiki` 下进入或创建页面 `模块报告`
-4. 在 `模块报告` 下按仓库名定位或创建数据库，数据库名字就是仓库名字
-5. 先 `fetch` 数据库，拿到真实 schema 和 `data_source_id`
-6. 再在对应 `data_source_id` 下按 `标题` 查找记录；有则更新，没有则新建
+### 2.3 怎么补读业务域文档
-这里要按 Notion MCP 的真实工作方式来写，不要再沿用旧的“多维表 + create_page/update_page”心智。
+如果模块明显属于某个业务域，在读完项目级文档后，再补一层业务域上下文即可，不要把所有业务域子文档都读一遍。
-### 页面与数据库创建模板
+建议这样做：
-1. 创建 `项目Wiki` 页面：
+1. 先根据 `业务域全景图` 判断模块最相关的业务域
+2. 去 `产品设计` 下找对应业务域页面
+3. 先读该业务域页本身的 `业务域简介`
+4. 如果只靠 `业务域简介` 已足够判断模块是否匹配该域，就继续写报告
+5. 只有在判断仍不够清楚时，再按需补读该业务域页下面的子文档，例如 `BRD`、`技术方案`、`Epics`
-```json
-{
-  "pages": [
-    {
-      "properties": {
-        "title": "项目Wiki"
-      },
-      "icon": "📚"
-    }
-  ]
-}
-```
+把这层理解成“轻量补证据”：
-2. 在 `项目Wiki` 下创建 `模块报告` 页面：
+- 项目级文档：决定项目范围、一阶段边界、通用术语和系统边界
+- 业务域页：帮助判断模块是不是明显落在这个业务域
+- 业务域子文档：只在需要补充证据时再读
-```json
-{
-  "parent": {
-    "page_id": "{项目Wiki_page_id}"
-  },
-  "pages": [
-    {
-      "properties": {
-        "title": "模块报告"
-      },
-      "icon": "📦"
-    }
-  ]
-}
-```
+如果模块无法明确归到某个业务域，可以只基于项目级文档产出报告，但要在“使用场景”里写清这是宽口径判断。
-3. 在 `模块报告` 页面下创建仓库级数据库。
-推荐 schema 固定为：
+### 2.4 哪些页面是评分必需
-```sql
-CREATE TABLE (
-  "标题" TITLE,
-  "简介" RICH_TEXT,
-  "使用场景" RICH_TEXT,
-  "推荐度" SELECT('推荐':green, '备选':yellow, '谨慎':red)
-)
-```
+评分前的最低门槛如下：
-对应调用形态：
+- `项目背景`：必读。没有它就不要评分
+- `业务域全景图`：必读。没有它就不要评分
+- `组织架构`：推荐读取。缺失时可继续，但角色判断可信度下降
+- `术语表`：推荐读取。缺失时可继续，但要注意用词
+- `现有系统清单`：推荐读取。缺失时可继续，但系统边界要标 `待确认`
+- `项目约束`：推荐读取。缺失时可继续，但一期优先级判断要标 `待确认`
+- 业务域页的 `业务域简介`：模块已能明确归属业务域时推荐读取；若缺失，可继续，但业务贴合度判断要标 `待确认`
+- 业务域子文档如 `BRD / 技术方案 / Epics`：只在 `业务域简介` 不足以支撑判断时再补读
-```json
-{
-  "parent": {
-    "page_id": "{模块报告_page_id}"
-  },
-  "title": "server-tools",
-  "schema": "CREATE TABLE (\"标题\" TITLE, \"简介\" RICH_TEXT, \"使用场景\" RICH_TEXT, \"推荐度\" SELECT('推荐':green, '备选':yellow, '谨慎':red))"
-}
-```
+如果缺少 `项目背景` 或 `业务域全景图`，停止写报告，并明确说明“无法判断项目相关度，因此不评分”。
-4. 创建完数据库后，立刻 `fetch` 该数据库。
-不要跳过这一步，因为后续写记录必须用返回结果里的 `data_source_id` 和真实属性名。
+## 3. 评分口径
-5. 在仓库级数据库里创建模块记录页：
+评分必须结合项目相关度，不能只看模块本身质量或 OCA 活跃度。
-```json
-{
-  "parent": {
-    "data_source_id": "{仓库级数据库_data_source_id}"
-  },
-  "pages": [
-    {
-      "properties": {
-        "标题": "sale_order_tag",
-        "简介": "为销售订单提供标签分类与筛选能力",
-        "使用场景": "适合在你们项目中需要按业务主题、项目来源或专项任务给销售订单分类时考虑",
-        "推荐度": "备选"
-      },
-      "icon": "🧩"
-    }
-  ]
-}
-```
-### 创建后的验证步骤
-每次创建仓库级数据库后，都要立刻做这两步验证：
-1. `fetch` 父页面，确认数据库已经出现在 `模块报告` 页面下
-2. `fetch` 新数据库，确认返回结果中能看到真实 schema 和 `data_source_id`
+| 评分 | 含义 | 典型信号 |
+|------|------|----------|
+| `⭐` | 功能可用但与项目几乎无关 | 业务域不在一期范围，无直接需求对应 |
+| `⭐⭐` | 有通用价值，不在一期范围 | 模块质量尚可，但项目暂无此类需求 |
+| `⭐⭐⭐` | 与项目业务域相关，可作备选 | 需求存在但有其他方案，或需明显二开 |
+| `⭐⭐⭐⭐` | 高度契合需求，建议优先评估 | 能直接覆盖需求，落地成本较低 |
+| `⭐⭐⭐⭐⭐` | 直接解决一期核心痛点 | 不采用就大概率需要从零自研 |
-不要只以“create_database 调用了成功”作为结束条件，
-要以“父页面可见 + schema 可识别 + 可拿到 data_source_id”作为成功标准。
+产出时至少要把这三件事写清楚：
-## Notion 数据库约定
+- `简介`：用项目口径写一句话，不照抄 README
+- `评分`：明确给出 `⭐` 到 `⭐⭐⭐⭐⭐`
+- `使用场景`：写清楚在项目的哪个业务域、流程或角色下可以考虑
-每个仓库一个数据库，数据库标题直接使用仓库名字，例如：
-- `server-tools`
-- `project`
-- `hr`
-每个数据库应具备 4 个核心属性：
-- `标题`
-- `简介`
-- `使用场景`
-- `推荐度`
-推荐类型如下：
-- `标题`：`TITLE`
-- `简介`：`RICH_TEXT`
-- `使用场景`：`RICH_TEXT`
-- `推荐度`：`SELECT('推荐':green, '备选':yellow, '谨慎':red)`
-如果数据库已经存在，则：
-- 先 `fetch` 数据库，读取真实 schema
-- 如果缺少属性，用 `update_data_source` 补齐
-- 如果属性名与预期不一致，先统一命名，再继续写记录
-- 不要在没有拿到 `data_source_id` 的情况下直接写记录
-### 模块记录写入要求
-目标上，模块记录应包含：
-- `标题`
-- `简介`
-- `使用场景`
-- `推荐度`
-摘要字段口径按下面的标准准备：
-```json
-{
-  "标题": "sale_order_tag",
-  "简介": "为销售订单提供标签分类与筛选能力",
-  "使用场景": "适合在你们项目中需要按业务主题、项目来源或专项任务给销售订单分类时考虑",
-  "推荐度": "备选"
-}
-```
-写入时要按这个顺序：
-1. 如果是新记录，用 `create_pages` 在数据库的 `data_source_id` 下创建
-2. 如果是已有记录，先 `fetch` 该页面，再用 `update_page` 更新属性和正文
-3. 写完后重新 `fetch` 页面或数据库，确认属性和值已经落进去
-4. 只有在属性和正文都成功写入后，才可以把本次 Notion 更新当作完成状态
-点开每一行的页面后，再写入完整模块报告正文。
-## 什么时候使用
-以下场景必须使用本 skill：
-- “帮我精读这个模块”
-- “帮我看看这个模块值不值得用”
-- “把候选模块 A/B/C 各出一份精读结论”
-- `solution` 已经找到候选模块，需要沉淀正式模块报告
-- “把这个模块写进项目 Wiki 的模块报告库”
-以下情况不要用本 skill：
-- 只是想快速看看有哪些模块可选，用 `module-research`
-- 只是想核实官方模块能力，用 `odoo18-docs`
-## 工作流
+## 4. 精读工作流
 1. 读 `__manifest__.py`
-2. 读 `README*`
-3. 读核心目录：
+2. 检查 `version` 是否以 `18.0` 开头；如果明显不是 Odoo 18，立即提示版本不匹配，不要硬推荐
+3. 读 `README*`
+4. 读核心目录：
    - `models/`
    - `views/`
    - `security/`
    - `data/`
    - `controllers/`（如有）
-4. 识别：
-   - 核心模型
-   - 关键视图 / 工作流
-   - 依赖模块
-   - 安装前置条件
-   - 维护和兼容性信号
-5. 再回到 Notion 上下文判断：
-   - 对你们项目的推荐度
-   - 在你们项目中的使用场景
-   - 适合写进数据库属性的简介口径
-6. 生成完整模块报告正文，固定按 5 段结构写
-7. 写入 Notion：
-   - 定位仓库名对应的数据库
-   - 先 `fetch` 数据库，确认 schema 和 `data_source_id`
-   - 如果 schema 有问题，先修 schema 再继续
-   - 创建或更新模块记录，并验证 4 个属性已写入
-   - 将完整报告写入该行页面正文
-8. 返回简短摘要给调用方
-## 正文标准
-模块报告正文统一按下面 5 段写，不再自由发挥章节结构。
-### 1. 模块概览
-这一段至少要写清楚：
-- 模块核心作用，一句话说清它解决什么问题
-- 模块主要服务哪个业务对象、流程或工作台
-- 模块来源和维护信号是否正常
-不要只重复 README 第一段。
+5. 识别这些信息：
+   - 核心模型和关键字段
+   - 关键视图、动作和工作流
+   - 自动化、约束、权限和联动
+   - 依赖模块和安装前置
+   - 维护与兼容性信号
+6. 回到 Notion 上下文，结合项目级文档和必要的业务域文档判断：
+   - 该模块在项目中的落点
+   - 该模块的星级评分
+   - 适合写入数据库属性的 `简介`
+   - 正文第 3 段的 `使用场景`
+7. 生成完整报告正文
+8. 写回 Notion
+9. 重新读取已写入页面，确认属性和值都已落库
+## 5. 写回 Notion
+所有模块统一写入 `📦 odoo 模块报告` 数据库，不再按仓库创建多个数据库。
+### 5.1 先拿真实 schema
+1. `fetch` `📦 odoo 模块报告` 数据库
+2. 记录真实 `data_source_id`
+3. 以当前 schema 为准，不要凭记忆写属性名
+当前工作区里，这个数据库至少应包含这些核心属性：
+- `模块名称`
+- `简介`
+- `所属仓库`
+- `评分`
+- `评估人`
+- `评估状态`
-### 2. 功能说明
+如果 schema 与上面明显不一致，先处理再继续。尤其注意：
-这一段重点写模块“实际做了什么”，至少要覆盖：
+- `所属仓库` 必须是能正常存仓库名的类型
+- 如果它仍然是明显不适合仓库名的类型，例如 `email`，先修 schema，再继续写值
+- 如果数据库已有额外字段，不要随意删除；只修会阻塞本次写入的问题
-- 核心模型或关键业务对象
-- 关键页面、动作或工作流
-- 关键规则、自动化或联动
-- 与标准 Odoo 相比的主要补充点
+### 5.2 查重规则
-不要把“功能说明”和“使用场景”混写在一起。
+先按 `模块名称` 精确查重，再决定创建还是更新。
-### 3. 使用场景
+推荐顺序：
-这一段必须结合项目背景写，不能泛泛而谈。
+1. 查询 `📦 odoo 模块报告` 的主表视图，或在该 data source 内搜索模块技术名
+2. 只把 `模块名称` 精确匹配的页面视为同一模块
+3. 如果只有模糊匹配，先 `fetch` 候选页确认后再更新
+4. 如果没有精确匹配，再创建新记录
-至少回答这几个问题：
+不要因为 README 标题相近或功能接近，就覆盖别的模块记录。
-- 在你们项目的哪个业务域或哪类需求里可以考虑这个模块
-- 更适合作为主方案、补充方案，还是备选方案
-- 如果要落地，前提通常是什么
+### 5.3 属性回填口径
-如果没有足够上下文支撑精确判断：
+| 属性 | 期望类型 | 填写标准 |
+|------|----------|----------|
+| `模块名称` | `TITLE` | 模块技术名，如 `sale_order_tag` |
+| `简介` | `RICH_TEXT` / `TEXT` | 一句话说明模块做什么，语气贴近项目口径 |
+| `所属仓库` | `RICH_TEXT` / `SELECT` | 仓库名，如 `server-tools` |
+| `评分` | `SELECT` | 使用 `⭐` 到 `⭐⭐⭐⭐⭐` |
+| `评估人` | `PEOPLE` | 当前执行精读的人；如需写入，先获取当前用户 ID |
+| `评估状态` | `STATUS` | 写完正文并验证后改为 `已出报告` |
-- 先明确是基于 `全局资源` 的哪部分判断
-- 再说明哪些业务背景仍待确认
+建议的属性值长这样：
-### 4. 依赖与安装
+```json
+{
+  "模块名称": "sale_order_tag",
+  "简介": "为销售订单提供标签分类与筛选能力，适合按项目主题或专项任务做快速归类。",
+  "所属仓库": "sale-workflow",
+  "评分": "⭐⭐⭐",
+  "评估状态": "已出报告"
+}
+```
-内容必须包含：
+### 5.4 写入顺序
-- 依赖模块
-- 前置条件
-- 安装步骤
-- 安装后如何确认模块已正确安装
+1. 如果不存在记录，用 `create_pages` 在 `data_source_id` 下创建页面
+2. 如果已存在记录，先 `fetch` 该页面
+3. 先写或更新属性：`模块名称 / 简介 / 所属仓库 / 评分 / 评估人`
+4. 再写完整报告正文
+5. 最后把 `评估状态` 改为 `已出报告`
+6. 重新 `fetch` 页面，确认：
+   - 属性值已正确落库
+   - 正文不是空白页
+   - 状态已变成 `已出报告`
-### 5. 操作指南
+不要只写属性不写正文，也不要只写正文不回填属性。
-这一段必须同时包含“配置指南”和“一个演示场景”，不要只罗列按钮或菜单。
+## 6. 正文模板
-至少拆成这两块：
+正文固定按 5 段写，标题建议保持一致，方便后续横向阅读。
-- `配置指南`
-- `演示场景`
+```markdown
+## 1. 模块概览
-`配置指南` 至少包含：
+- 核心作用：{一句话说清模块解决什么问题}
+- 主要对象/流程：{服务哪个业务对象、流程或工作台}
+- 来源与维护：{模块来源、仓库、维护活跃度、版本匹配情况}
-- 配置入口路径
-- 配置步骤
-- 关键配置项说明
-- 推荐配置方式或常见配置值
-- 配置完成后如何验证生效
+## 2. 功能说明
-`演示场景` 至少包含：
+- 核心模型：{模型、关键字段、关系}
+- 关键界面/动作：{视图、按钮、菜单、动作、自动化}
+- 关键规则：{权限、约束、自动化、与标准 Odoo 的主要差异}
-- 场景名称
-- 适用角色
-- 前置条件
-- 操作步骤
-- 预期结果
+## 3. 使用场景
-至少写 1 个完整闭环演示场景。
-如果模块功能较多，可写 2-3 个典型演示场景。
+- 适用业务域：{结合项目背景和业务域全景图判断}
+- 适用方式：{主方案 / 补充方案 / 备选方案}
+- 落地前提：{依赖什么业务前提、主数据、流程或外部系统}
+- 待确认项：{上下文不足时写清楚缺什么}
-如果是多模块批量精读：
+## 4. 依赖与安装
-- 同仓库模块写入同一个数据库
-- 不同仓库分别写入各自仓库名的数据库
-- 每个模块独立占一行并拥有自己的正文页面
+- 依赖模块：{模块列表}
+- 前置条件：{安装前准备}
+- 安装步骤：{按顺序列出}
+- 安装后验证：{如何确认模块已生效}
-## Notion 写入结果
+## 5. 操作指南
-写入数据库时，摘要字段按下面的口径回填：
+### 配置指南
-- `标题`：模块技术名或最常用名称
-- `简介`：一句话说明模块做什么，语气与术语要尽量贴近你们项目
-- `使用场景`：适合在你们项目中的哪类业务域、流程或需求里考虑
-- `推荐度`：`推荐 / 备选 / 谨慎`
+- 配置入口：{菜单路径}
+- 配置步骤：{步骤列表}
+- 关键配置项：{字段、推荐值、注意事项}
+- 生效验证：{如何检查配置已生效}
-如果同一模块已经存在：
+### 演示场景
-- 优先读取现有记录和数据库 schema，再判断如何更新 4 个属性
-- 更新该行页面正文
-- 不重复新建
+- 场景名称：{一个完整场景}
+- 适用角色：{谁来操作}
+- 前置条件：{需要先准备什么}
+- 操作步骤：{按顺序列出}
+- 预期结果：{系统应表现出什么结果}
+```
-## 质量标准
+补充规则：
-- 不只重复 README，要补代码层判断
-- 不只说“有这个功能”，要说清楚模块的实际使用方式
-- `简介 / 使用场景 / 推荐度` 必须结合 `全局资源`，有业务域上下文时还要结合对应 `BRD / Solution`
-- 不要跳过 `fetch`，要以 Notion 当前真实 schema 和 `data_source_id` 为准
-- 创建或更新模块记录时，目标上不应漏掉 `简介 / 使用场景 / 推荐度`
-- `依赖与安装` 必须细到跟着就能装好
-- `操作指南` 里的配置指南必须细到跟着就能配好
-- `操作指南` 必须包含至少 1 个闭环演示场景，让用户能实际走通一遍
-- 不确定的信息写“待确认”，不要编造
+- `功能说明` 和 `使用场景` 不要混写
+- `使用场景` 必须引用项目背景判断，不要写成通用营销文案
+- 纯库模块或无独立 UI 的模块，`操作指南` 可以简化为“安装即生效 + 验证方式”
+- 如果信息不够，明确写 `待确认`，不要编造
-## 返回给调用方的摘要格式
+## 7. 返回给调用方的摘要
-写完 Notion 后，给调用方返回一段短摘要即可，例如：
+写完 Notion 后，返回一段短摘要即可：
 ```markdown
 ## 模块报告已更新
 - 仓库：{repo_name}
 - 模块：{module_name}
 - 简介：{一句话简介}
-- 推荐度：推荐 / 备选 / 谨慎
-- 使用场景：{一句话}
+- 评分：⭐~⭐⭐⭐⭐⭐
+- 评估状态：已出报告
 - 结论：{一句话总结}
 ```
-## Guardrails
+## 8. 质量边界
-- 不要在用户还没选定目标时替代 `module-research`
-- 不要再写本地 `docs/module_report/`
-- 不要只看 README 就下结论
-- 不要脱离 `全局资源` 直接给“推荐度”
+- 不要只重复 README，要补代码层判断
+- 不要跳过 `项目背景` 和 `业务域全景图` 直接评分
+- 不要在 `项目 Wiki` 下新建并行数据库结构
 - 不要为同一个模块重复创建多条记录
-- 不要擅自新增这 5 段之外的强制章节
-- 如果模块明显版本不匹配，要明确提示，不要硬推荐
+- 不要擅自新增 5 段之外的强制章节
+- 版本不匹配要明确提示，不硬推荐

package/payload/skills/module-report/agents/openai.yaml CHANGED Viewed

@@ -1,6 +1,6 @@
 interface:
   display_name: "模块报告"
-  short_description: "精读已选定模块并把完整模块报告写入 Notion 的项目Wiki/模块报告"
+  short_description: "精读模块，结合项目概览判断适配度并写回 Notion 模块报告"
   icon_small: "./assets/icon-small.svg"
   icon_large: "./assets/icon-large.svg"
   brand_color: "#714B67"