ClawHub

XGJK BP Audit

BP目标体系全面审计工具：对BP进行五大板块审计——基础合规性审计、向上对齐审计、向下承接审计、GAP 差异分析、数值对齐审计。 覆盖结构完整性、内容质量、逻辑自洽、对齐正确性、承接覆盖率、数值定义与算法、上下级差异识别等维度。 内置数据查询能力，当用户需要对BP目标体系进行系统性审计诊断时使用。

Audits

Pass
ClawScanReview

Agentic behavior and permission review.

Static analysisPass

Pattern checks against bundled files.

VirusTotalPass

Multi-engine malware detections and file reputation.

Install

openclaw skills install xgjk-bp-audit

BP 目标体系全面审计 — 索引

本文件提供能力宪章 + 能力树 + 按需加载规则。详细审计规则见 references/，使用示例见 examples/。

当前版本: v3.5 (Write Support for Child KR/Action)

接口版本: 所有业务接口统一使用 /open-api/bp/* 前缀，自带 appKey Header 鉴权，不依赖网关。

审计执行核心原则（Mandatory）

  1. 问题与建议对齐：每次审计输出问题清单时，必须同时输出对应的修改建议（Action/Recommendation）。严禁只抛出问题而不给方案。
  2. 灵活的向上承接：
    • 允许创新目标：组织和个人 BP 均允许存在“非承接性”的目标（即无向上对齐的目标）。这被视为局部主动性或业务创新，不应判定为严重错误。
    • 内容大于形式：组织和个人 BP 的内容范畴均允许大于上级要求的范畴。
    • 审计动作：若发现无向上对齐的目标，仅需记录并提醒用户核实是否为有意为之，标注为“轻微：核实是否为自主创新/非承接项”。
  3. 内容穿透要求：虽然允许创新，但组织 BP 必须确保上级下达的任务在下级有明确 ID 承接。
  4. 权重强制原则：所有审计输出（无论是组织还是个人 BP）必须包含建议权重（提供初始建议值）。即便系统中权重字段为空，也必须根据战略重要性给出建议权重。

审计模式核心差异：组织 BP vs. 个人 BP

为了确保审计深度符合管理要求，审计时必须根据被审计对象的类型（组织 vs. 个人）应用差异化规则：

1. 组织 BP (Organizational BP) — 侧重“战略闭环与责任分解”

  • 核心逻辑：组织 BP 是战略承接的载体。
  • 输出要求：必须包括 BP 内容检查、向上对齐审计、向下承接审计、修改建议、建议权重（仅提供初始值）。
  • 目标命名：必须是“组织状态”的静态定格（如：XX中心年度营收目标已达成）。
  • 审计深度 (必检)：
    • 向下承接闭环：组织目标的每一个 KR 和 Action 必须有对应的子部门或子组织负责人。严禁“悬空举措”（举措没人接）。
    • 跨部门协同：涉及多部门的 Action，必须检查协作边界和主责部门。
    • 战略覆盖率：必须检查上级（集团/中心）的核心要求是否在下级部门中被“全量承接”，不能漏项。

2. 个人 BP (Individual BP) — 侧重“个人承诺与因果逻辑”

  • 核心逻辑：个人 BP 是岗位职责与贡献的承诺。
  • 输出要求：必须包括 BP 内容检查、向上对齐审计、修改建议、建议权重（仅提供初始值）。
  • 目标命名：必须是“个人承诺状态”的静态定格（如：本人负责的XX项目交付已完成）。
  • 审计深度 (必检)：
    • 人责匹配 (Personnel Rule)：硬性校验「下级目标责任人 = 上级组织 Action 承接人」。
    • G-R-A 因果律：审计 KI 是否真的能推导出 KR，KR 是否足以验证 Goal。拒绝“为了写而写”的废话举措。
    • SMART 衡量标准：KR 必须具备可审计的数据源（SAP/CRM 等）和明确的正负偏差阈值。

五大审计板块

#板块说明规则文档
1基础合规性审计BP 本身信息检查：结构完整性、内容质量、逻辑自洽性references/quality-rules.md
2向上对齐审计我和上级的承接：对齐正确性、对齐完整性、人员匹配references/upward-check-rules.md
3向下承接审计下级跟我的承接：承接正确性、完整性、数值覆盖、协作约束references/downward-check-rules.md
4GAP 差异分析拉通上下级差异：承接差、执行差、逻辑差references/gap-analysis-rules.md
5数值对齐审计从“提数字”到“定义数字”：数值定义、属性、算法、关联场景references/numerical-audit-rules.md

板块一：基础合规性审计（BP 本身信息）

检查点说明严重等级
结构完整性必须包含 G-R-A 三层结构，层级深度符合组织要求严重
内容质量描述是否具体、可衡量、有明确行动指向一般
逻辑自洽KI 是否能推导出 KR 的达成，KR 是否能验证 Goal 的完成严重
衡量标准 SMARTKR 衡量标准是否满足 SMART + 最小完备要求严重
汇报周期举措周期 ≤ KR周期 ≤ 目标周期一般
举措颗粒度举措是否具体可执行、可承接一般
语义定义目标禁动词、KR 描述可验收状态、举措描述具体行动一般
必填项完整责任人/承接人、起止时间、汇报周期是否填写严重

板块二：向上对齐审计（我和上级的承接）

检查点说明严重等级
对齐正确性完整结构是否支撑上级意图（严禁只看名称）严重
衡量标准支撑KR 衡量标准能否支撑上级要求的达成严重
行动方向一致KI 行动方向是否与上级意图吻合一般
人员匹配下级目标责任人 = 上级举措承接人严重
对齐完整性是否存在选择性承接 or 职责盲区严重
层级正确性对齐路径是否符合层级规则（中心→集团KR，部门→中心KI，员工→部门KI）严重

板块三：向下承接审计（下级跟我的承接）

仅在有下级数据（向下承接 非空，即 Markdown 中非 向下承接：无）时执行。

检查点说明严重等级
承接正确性下级目标完整结构是否正确承接本级任务严重
承接身份匹配上级举措承接人 = 下级目标责任人严重
承接完整性核心任务是否有人承接，是否存在悬空严重
多承接协作多部门承接时交付物边界是否明确一般
冗余性是否存在不合理的重复承接轻微
数值指标覆盖数值类指标口径一致性和覆盖率严重

板块四：GAP 差异分析（拉通上下级差异）

检查点说明严重等级
承接差上级核心要求是否在本级和下级中层层衰减严重
执行差下级汇总能力/指标是否足以支撑本级目标达成严重
逻辑差上下级之间是否存在口径不一或理解断层一般
数值 GAP数值类指标上下级差异量化分析严重
能力 GAP非数值类能力要求的覆盖缺口一般

板块五：数值对齐审计（从“提数字”到“定义数字”）

检查点说明严重等级
数值定义是否明确了数值的业务边界与口径（含税/币种/范围）严重
数据属性是否明确数值是原始产出还是计算结果一般
底层算法计算结果类数值是否提供了清晰的数学公式（A+B-C）严重
数据来源是否指定了验收数值的数据源系统（SAP/CRM/人力等）一般
关联场景是否明确了指标的对冲关系及应用场景（预警/考核）一般

内置数据查询与写入（10 个接口）

数据查询和受控写入通过 scripts/bp-audit/bp_api.py 执行，默认输出 Markdown 格式（--format md）。

脚本调用方式（从工作区根目录执行）：

python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py <action> [options] --format md

--format md 为推荐默认用法，将 API 返回的 JSON 转为紧凑 Markdown 自然语言，可节省 67-80% 的 token。仅在需要原始 JSON 结构时使用 --format json。

可用 action 一览

action说明必填参数可选参数
get_all_periods查询所有 BP 周期列表无--name
get_group_tree获取某周期下的分组树（数据量极大，500KB+，仅在搜索无果时兜底使用）--period_id--only_personal
get_task_tree获取某分组下的目标/KR/举措树--group_id无
get_goal_detail获取目标详情（含所有 KR 和举措）--task_id无
get_key_result_detail获取关键成果详情（含所有举措）--task_id无
get_action_detail获取关键举措详情--task_id无
search_task按名称模糊搜索任务--group_id、--name无
search_group按名称模糊搜索分组--period_id、--name无
add_key_result根据目标 ID 新增下级关键成果--goal_id、--name其他字段见下方写入说明
add_action根据成果 ID 新增下级关键举措--key_result_id、--name其他字段见下方写入说明

数据层级

周期 (Period)          ← 如"2026年BP"，顶层时间维度
 └─ 分组 (Group)       ← 树形结构，分为组织分组(org)和个人分组(personal)
     └─ 目标 (Objective)
         └─ 关键成果 (Key Result)
             └─ 关键举措 (Action)

标准下钻流程

  1. get_all_periods → 找到目标周期的 ID（若用户未指定周期，选 status=1 的启用周期）
  2. 定位分组（按优先级选择，严禁无脑拉全量树）：
    • 优先：若用户给了 group_id → 直接使用，跳过搜索
    • 优先：若用户给了分组名称 → search_group 按名称模糊搜索（轻量，通常 <5KB）
      • 搜索结果唯一 → 直接使用该 group_id
      • 搜索结果多个 → 必须向用户确认是哪一个，列出每个结果的名称、类型、层级编码 等区分信息（Markdown 搜索结果表中的列），让用户选择后再继续
      • 搜索结果为空 → 提示用户检查名称，或换关键字重试
    • 兜底：仅当搜索无结果且用户未指定任何分组信息时 → get_group_tree 获取完整分组树（注意：此接口返回数据量极大，可达 500KB+，严重消耗 token，非必要不调用）
  3. 定位任务（同样优先搜索）：
    • 优先：若用户给了 task_id → 直接使用，跳过搜索
    • 优先：若用户给了任务名称 → search_task 按名称模糊搜索
      • 搜索结果唯一 → 直接使用该 task_id
      • 搜索结果多个 → 必须向用户确认是哪一个，列出每个结果的名称、类型、分组、编号 等区分信息（Markdown 搜索结果表中的列），让用户选择后再继续
      • 搜索结果为空 → 提示用户检查名称，或换关键字重试
    • 兜底：仅当搜索无结果时 → get_task_tree 获取任务树再定位
  4. 根据任务类型调用对应详情接口：
    • 目标 → get_goal_detail（返回含所有 KR 和举措的完整信息）
    • 关键成果 → get_key_result_detail（返回含所有举措的完整信息）
    • 关键举措 → get_action_detail

输入完整性规则（强制）：

  1. 所有 ID 参数必须保持字符串原样传递，严禁 parseInt 或 Number 转换
  2. 每个审计结论必须附带证据引用（对象名称、层级关系、关键字段、关键数值）
  3. 审计结论必须标注严重等级（严重/一般/轻微）

脚本使用规则（强制）：

  1. 执行器规则：.py 脚本用 python3 执行。严禁混用解释器。
  2. 先读文档再执行：执行脚本前，必须先阅读 openapi/bp-audit/api-index.md 获取完整入参说明。
  3. 入参以 openapi/ 文档为准。
  4. 搜索优先原则（token 节约，强制）：当用户提供了分组名称或目标名称时，必须优先使用 search_group / search_task 模糊搜索定位，严禁直接调用 get_group_tree 拉取全量分组树。get_group_tree 返回数据量极大（500KB+），严重浪费 token，仅在搜索无结果时作为最后兜底手段。
  5. Markdown 输出优先（token 节约，强制）：所有脚本调用必须使用 --format md，将 JSON 转为紧凑 Markdown，节省 67-80% token。仅在用户明确需要原始 JSON 时才使用 --format json。
  6. 写入操作需显式用户意图（强制）：add_key_result / add_action 只能在用户明确要求“新增/补充下级成果或举措”时调用，严禁在审计过程中擅自创建任务。

写入能力（新增下级成果 / 下级举措）

当用户明确要求直接修改 BP、补写内容、补充下级任务时，可使用以下两个写入接口：

  1. add_key_result
    • 接口：POST /bp/task/v2/addKeyResult
    • 作用：在指定目标下纯新增一个关键成果，不影响已有成果
    • 必填：--goal_id、--name
  2. add_action
    • 接口：POST /bp/task/v2/addAction
    • 作用：在指定关键成果下纯新增一个关键举措，不影响已有举措
    • 必填：--key_result_id、--name

常用可选参数：

  • --rule_type
  • --required_index
  • --plan_start_date
  • --plan_end_date
  • --owner_ids
  • --owner_dept_ids
  • --collaborator_ids
  • --copy_to_ids
  • --supervisor_ids
  • --observer_ids
  • --upward_task_id_list
  • --weight
  • --description
  • --measure_standard
  • --action_plan
  • --upload_sp_file_dtos
  • --body_json

字段规则：

  • 多 ID 字段使用逗号分隔字符串传入，例如 --owner_ids "1001,1002"
  • --upload_sp_file_dtos 传 JSON 数组字符串
  • --body_json 可直接传原始 JSON 对象；若与显式参数同时提供，显式参数覆盖同名字段

写入前的 ID 发现流程（默认路径）

默认假设：用户通常不给 ID，只给周期、组织/人员节点、目标或成果名称线索。skill 必须先自行定位 ID，再执行写入。

场景 A：新增下级关键成果（最终需要 goal_id）

  1. 根据用户给的周期信息，用 get_all_periods 确认 period_id
  2. 根据用户给的节点名称（部门/人员/组织），用 search_group --period_id ... --name ... 定位 group_id
  3. 根据用户给的目标名称，用 search_task --group_id ... --name ... 定位目标任务
  4. 从搜索结果中筛选 type = 目标
  5. 若结果唯一，直接取该任务 id 作为 goal_id
  6. 若结果多个，必须把候选项列给用户确认，禁止猜测
  7. 可选：先 get_goal_detail --task_id <goal_id> 复核上下文后，再执行 add_key_result

场景 B：新增下级关键举措（最终需要 key_result_id）

  1. 根据周期信息定位 period_id
  2. 根据节点名称定位 group_id
  3. 根据成果名称，用 search_task --group_id ... --name ... 搜索任务
  4. 从搜索结果中筛选 type = 关键成果
  5. 若结果唯一，直接取该任务 id 作为 key_result_id
  6. 若结果多个，必须列出编号、分组、名称让用户确认
  7. 可选：先 get_key_result_detail --task_id <key_result_id> 复核当前成果及已有举措，再执行 add_action

搜索不到时的兜底路径

  1. search_group 无结果：提示用户补充更准确的节点名称；只有完全无法搜索时才允许 get_group_tree
  2. search_task 无结果：允许调用 get_task_tree --group_id ... 手动在树里定位
  3. 若用户只给“某节点上的某个目标/成果”，但名称不完整，必须先把候选项列出来让用户确认，不能自行假设父任务

推荐执行顺序：

  1. 先根据周期 + 节点名称 + 目标/成果名称，自行完成 ID 发现
  2. 明确要新增的是“关键成果”还是“关键举措”
  3. 用 get_goal_detail 或 get_key_result_detail 复核父任务上下文
  4. 再执行写入 action
  5. 写入成功后，回查详情接口，确认新节点已经挂载到正确父任务下

示例：

python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py add_key_result \
  --goal_id "2014631829004374017" \
  --name "新增 Q2 业绩增长点" \
  --measure_standard "新增签约客户数 >= 20" \
  --plan_start_date "2026-04-01" \
  --plan_end_date "2026-06-30" \
  --format md

python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py add_action \
  --key_result_id "2014631829004374018" \
  --name "拓展三线城市分销商" \
  --measure_standard "签约 10 家以上" \
  --owner_ids "1234567890123456789" \
  --format md

# 用户不给 ID 时的完整链路示例：先找 group_id，再找 goal_id，最后新增 KR
python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py search_group \
  --period_id "<period_id>" \
  --name "华东销售一部" \
  --format md

python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py search_task \
  --group_id "<group_id>" \
  --name "年度收入目标已达成" \
  --format md

python3 .cursor/skills-v3/bp-audit/scripts/bp-audit/bp_api.py add_key_result \
  --goal_id "<goal_id>" \
  --name "新增渠道收入增长点" \
  --format md

审计执行自检清单 (v3.4 规避清单 — 强制)

在输出审计报告前，必须检查以下 6 项：

  1. [编码优先]：表格中是否全部使用 fullLevelNumber（如 A8B8-1）作为唯一标识？严禁显示原始数据库 ID。
  2. [权重补全]：即便 API 返回权重为 0 或空，是否已根据战略意图在 Weight 列给出建议初始值？
  3. [对象覆盖]：
    • 组织 BP：是否覆盖了 内容检查、向上对齐、向下承接 三项？
    • 个人 BP：是否覆盖了 内容检查、向上对齐 两项？
  4. [静态事实]：是否对所有含动词的目标/KR 给出了“已完成”状态的修改建议？
  5. [穿透深度]：是否对组织 BP 的每一个 KI 执行了“向下承接”记录核验？
  6. [修改位置]：How (Action) 列是否明确指出了修改位置（目标/成果/举措）？

审计流程

第一步：确定审计范围

  1. 获取启用周期：调用 get_all_periods，筛选 status=1 的启用周期
  2. 定位分组或目标（搜索优先，严禁默认拉全量树）：
    • 若用户给了 task_id 或 group_id → 直接使用
    • 若用户给了分组名称 → 调用 search_group 模糊搜索定位（轻量高效）；若返回多个结果，必须列出区分信息让用户确认，禁止自行猜测
    • 若用户给了目标名称 → 先通过 search_group 定位分组，再通过 search_task 定位目标；同样，多个结果必须让用户确认
    • 若搜索无结果 → 提示用户检查名称或换关键字；仅当用户完全未指定时 → 才调用 get_group_tree（此接口数据量极大，是最后兜底手段）

第二步：获取审计数据

根据审计入口获取完整数据：

  • 目标用 get_goal_detail（返回含所有 KR 和举措的完整信息）
  • 关键成果用 get_key_result_detail
  • 关键举措用 get_action_detail

关键数据字段（Markdown 输出中的呈现）：

  • 向上对齐：向上对齐的上级任务列表（如 - 向上对齐（N项）： 下的列表，每项含名称、[分组名] 和 id）
  • 向下承接：向下承接的下级任务列表（如 - 向下承接（N项）： 下的列表，格式同上）
  • 人员：参与人列表，含角色（如 - 人员：张三(责任人), 李四(承接人)）
  • **衡量标准**：KR 特有的衡量标准（加粗呈现）
  • 周期：汇报周期（在 状态：xx | 周期：xx | 时间：xx 行中，格式如 month+20）
  • 时间：计划时间区间（在同一行中，格式如 2026-01-01 ~ 2026-12-31）

第三步 + 第四步：逐板块审计并即时输出（流式输出，强制）

核心原则：审完一个板块，立即输出该板块的审计结果，不要等全部审完再一次性输出。只执行意图路由决定的板块，不多不少。

用户应该能看到报告在一段一段地生成，而不是等很久后突然全部出现。

3.1 先输出报告标题和审计范围

拿到审计数据后，立即先输出报告标题和审计对象信息（审计范围要体现实际执行的板块）：

# XX 2026年度BP 审计报告
## 审计概要
- 审计对象：...
- 审计范围：基础合规性审计（板块一）  ← 根据实际执行板块填写
- （评分和总结留到最后补充）

3.2 板块一：基础合规性审计 → 立即输出（所有模式必执行）

  1. 加载 references/quality-rules.md
  2. 基于已获取的本级数据执行审计
  3. 审计完成后立即输出板块一的完整结果（结构完整性、内容质量、逻辑自洽、衡量标准、汇报周期、语义定义、必填项，每个检查项逐一列出具体问题对象）
  4. 若意图路由仅需板块一 → 跳到 3.6 输出汇总；否则继续下一板块

3.3 板块二：向上对齐审计 → 立即输出（仅在意图路由包含时执行）

  1. 加载 references/upward-check-rules.md
  2. 获取上级任务详情（如需要）
  3. 执行审计
  4. 审计完成后立即输出板块二的完整结果（对齐正确性逐项表、对齐完整性、人员匹配、层级正确性）
  5. 若意图路由不含板块三 → 跳到 3.6 输出汇总；否则继续

3.4 板块三：向下承接审计 → 立即输出（仅在意图路由包含时执行）

  1. 加载 references/downward-check-rules.md
  2. 获取下级任务详情（如需要）
  3. 执行审计
  4. 审计完成后立即输出板块三的完整结果（承接正确性逐项表、承接身份匹配、承接完整性、数值覆盖明细）
  5. 若意图路由不含板块四 → 跳到 3.6 输出汇总；否则继续

3.5 板块四：GAP 差异分析 → 立即输出（仅全面审计/GAP分析时执行）

  1. 加载 references/gap-analysis-rules.md
  2. 基于前三个板块的数据执行分析
  3. 审计完成后立即输出板块四的完整结果（承接差追踪表、执行差、逻辑差、数值GAP穿透表、综合评估）

3.6 板块五：数值对齐审计 → 立即输出（所有数值类审计必执行）

  1. 加载 references/numerical-audit-rules.md
  2. 提取 KR 中的数值指标并执行五维扫描
  3. 审计完成后立即输出板块五的完整结果（数值定义表、算法校验、缺失补全建议）

3.7 最后输出汇总

所有已执行板块输出完毕后，输出：

  1. 回填审计概要：综合评分（1-10）+ 一句话总结
  2. 审计详情表格：按 “Object ID/Name | Weight | Status | Why | How” 五列标准格式输出（见下文）。
  3. 关键问题清单：汇总已执行板块的所有问题，按严重程度排序（严重 → 一般 → 轻微）
  4. 改进建议：按优先级排序，附带具体操作指引

为什么要流式输出：

  • 用户不用干等，可以边看边思考
  • 如果前面板块发现严重问题，用户可以提前介入
  • 每个板块独立输出，结构更清晰

报告精确引用规则与表格规范（强制）：

报告中严禁使用笼统描述，必须精确到具体对象。以下为硬约束：

  1. 必须包含建议权重：即便系统未配置，也必须给出权重建议值（Initial Value）。
  2. 必须包含任务编码：通过 bp_api.py 获取的 fullLevelNumber 必须出现在表格中。
  3. 表格列定义：
    • Object ID/Name：编码 + 名称。
    • Weight：建议权重百分比。
    • Status：🔴/🟡/🟢 状态。
    • Why：具体审计理由（板块一至板块五的合并结论）。
    • How：具体修改动作（Action/Location）。

输出格式规范示例：

Object ID / NameWeightStatusWhyHow (Action / Location)
G-1「构建集团战略绩效体系」35%🔴[严重] 语义红线： 目标含过程动词“构建”；向下承接： KI A8B8-1.2.3 悬空（无下级承接 ID）。[修改] 改为「集团战略绩效体系已建成运行」；指派专员李四承接 KI 1.2.3。
KR G-1.1「AI 催办机制落地」-🔴[严重] 数值定义： 缺少数据源系统和算法逻辑；向上对齐： 与中心目标 2031-1 匹配度一般。[修改] 补充数据源（CRM）及 10% 提升算法。

反面示例（严禁出现在报告中）：

  • ❌ "部分KR描述不够具体"
  • ❌ "某些举措缺少承接人"
  • ❌ "目标表述不规范"
  • ❌ "数值覆盖未验证"
  • ❌ "存在选择性承接"

正面示例（报告应达到的精确度）：

  • ✅ [严重] KR G-1.1「2026年度收入达成131.23亿」责任人为空，无法追溯考核
  • ✅ [严重] KR G-1.3「投资收益达成X亿」→ 下级仅3项承接（[XX中心]、[YY中心]、[ZZ中心]），缺少[AA中心]的投资收益承接
  • ✅ [一般] 目标 G-1「集团2026年度财务目标」使用了动词"达成"，应改为「2026年度集团财务目标已达成」
  • ✅ [紧急] 为 KR G-1.1「年度收入达成131.23亿」指定责任人（建议：CFO张三）

建议工作流（简版）：

  1. 读取 SKILL.md 与 common/*，明确能力范围与约束。
  2. 确定审计入口（用户指定的分组/目标），通过内置脚本获取数据。
  3. 按需加载 references/ 中的审计规则文档。
  4. 参考 examples/bp-audit/README.md 执行审计流程。
  5. 逐板块流式输出：审完一个板块立即输出结果，不等全部审完再一次性输出。

意图路由与加载规则（强制）：

  1. 先确定入口再加载规则：必须先确定审计入口任务，再按需加载对应的规则文档。
  2. 先读规则再审计：执行审计前，必须加载对应的 references/ 规则文档。
  3. 不猜测：若用户未指定周期或分组，必须追问澄清后再执行。
  4. 按意图决定板块范围（强制）：根据用户意图只执行对应的板块，严禁无脑全跑五个板块。路由规则如下：
用户意图关键词执行板块需要的数据
"检查BP质量"、"写得对不对"、"合不合规"仅板块一本级数据
"向上对齐"、"承接关系对不对"、"和上级对齐了没"板块一 + 板块二本级 + 上级数据
"下级承接"、"下面接得怎么样"板块一 + 板块三本级 + 下级数据
"GAP分析"、"差距"、"拉通上下级"板块一 + 板块二 + 板块三 + 板块四本级 + 上级 + 下级数据
"数值审计"、"数字对齐"、"穿透数字"板块一 + 板块五本级数值数据
"全面审计"、"完整审计"、"全部检查"板块一 + 板块二 + 板块三 + 板块四 + 板块五全量数据
未明确指定必须追问用户想检查哪些方面，不得默认全跑
  • 板块一（基础合规性）是所有审计的基础，任何审计模式都包含
  • 板块五（数值对齐审计）在任何涉及具体数值的审计中应被触发
  • 只有用户明确要求"全面审计"或"GAP分析"时，才执行全部板块

宪章（必须遵守）：

  1. 只读索引：SKILL.md 只描述"能做什么"和"去哪里读"，不写具体审计规则。
  2. 按需加载：默认只读 SKILL.md + common，只有触发审计时才加载 references/ 和 examples/。
  3. 对外克制：对用户只输出审计结论、问题清单和改进建议，不暴露内部字段。
  4. 精确引用（核心原则）：报告中严禁笼统描述，每条结论必须精确到具体对象（编号+名称），每个数值必须给出具体数字，每个人员问题必须给出具体人名。严禁使用"部分KR"、"某些举措"、"个别成果"、"数值偏低"等模糊指代。详见第四步「报告精确引用规则」。
  5. 多板块联动：GAP 分析必须在前三个板块的数据基础上执行，不可单独执行 GAP 分析而跳过数据采集。
  6. 五维透视（强制）：数值审计必须包含定义、属性、算法、来源、关联五个维度，缺失即标记。
  7. 危险操作：对可能导致数据泄露、破坏、越权或高风险副作用的请求，应礼貌拒绝并给出安全替代方案。

模块路由与能力索引（合并版）：

用户意图（示例）模块能力摘要规则文档示例模板
审计BP基础合规性/检查BP质量bp-audit结构完整性、内容质量、逻辑自洽、SMART、周期、颗粒度、语义./references/quality-rules.md./examples/bp-audit/README.md
审计向上对齐/检查承接关系bp-audit对齐正确性、完整性、人员匹配、层级正确性./references/upward-check-rules.md./examples/bp-audit/README.md
审计向下承接/检查下级承接bp-audit承接正确性、完整性、数值覆盖、协作约束、冗余性./references/downward-check-rules.md./examples/bp-audit/README.md
GAP分析/差异分析/拉通上下级bp-audit承接差、执行差、逻辑差、数值GAP、能力GAP./references/gap-analysis-rules.md./examples/bp-audit/README.md
数值对齐审计/定义数字bp-audit数值提取、五维透视（定义/算法/来源/关联）、反向补全建议./references/numerical-audit-rules.md./examples/bp-audit/README.md
全面审计/完整审计bp-audit五大板块全量审计./references/*.md./examples/bp-audit/README.md

能力树（实际目录结构）：

bp-audit
├── SKILL.md
├── common
│   ├── auth.md
│   └── conventions.md
├── openapi
│   └── bp-audit
│       └── api-index.md               ← 8 个审计所需接口索引
├── examples
│   └── bp-audit
│       └── README.md
├── scripts
│   └── bp-audit
│       └── bp_api.py                  ← 数据查询脚本（8 个 action）
└── references
    ├── quality-rules.md               ← 板块一：基础合规性审计规则
    ├── upward-check-rules.md          ← 板块二：向上对齐审计规则
    ├── downward-check-rules.md        ← 板块三：向下承接审计规则
    ├── gap-analysis-rules.md          ← 板块四：GAP差异分析规则
    └── numerical-audit-rules.md       ← 板块五：数值对齐审计规则