| name | domain-pack-builder |
| description | Builds and maintains a domain knowledge pack for the data-analysis Skill the way a human analyst would — studying the raw material page by page, synthesising one Understanding Handbook, then deriving the full set of pack files (triggers, README, framework, glossary, computation-reference, data-spec, context-notes, insight-extensions, business-rules, plus an optional design-system slot) from that handbook plus the data profile. It is a research workflow, not an extraction pipeline — the agent reads decks and data visually and thoroughly, writes a handbook, then derives. Use when the user wants to create a domain pack for a new analysis area, refresh an existing pack after new material, new data, or an SME correction, or turn training decks and a sample analysis and a data file into pack files. Triggers include "build/refresh a domain pack", "把这些材料研读成 domain pack", "先写理解手册再派生 pack", and "刷新一下 domain pack". |
Domain Pack Builder
像研究员一样研读材料 → 综合成一份《理解手册》→ 从手册派生 pack 文件，为 data-analysis Skill 构建/维护 domains/<domain>/ pack。
这是研究型 workflow，不是抽取管线：不要把建包做成"按 section 把 transcript/deck 抽成 JSON 槽内容"的机械流程——那会死板、丢失理解。正确做法是先逐页视觉精读每份材料，先综合出一份《理解手册》（outputs/understanding-handbook.md），再从手册 + 数据画像派生 pack 文件。手册是派生一切 pack 文件的桥梁，也是团队对齐的理解背书。
我是谁：两个 skill 共享一份协议——data-analysis 消费 pack 做分析（Step 0 + 9-step workflow），本 skill（domain-pack-builder）研读材料、写手册、派生/维护 pack。槽清单/谁填/文件名以 Domain-Pack Protocol 为唯一权威；本 skill 不另立"pack 含哪些文件"的真理，只负责"如何研读 → 综合 → 派生 → 维护"。
设计动机：业务专家（SME）通常说得清、写不来。让 SME 交出原始材料（训练 deck / 某职能视角 deck / 要复刻的成品分析 / 真实数据文件 / 对着大纲讲一遍的录音），AI 像人一样把它们读懂（图表要看懂，必要时渲染成图来看），先写一份能让人一眼读懂的《理解手册》，再据此派生协议规定的 pack 文件，把拿不准/要 SME 拍板处**就地标 ⚠️待确认**并汇总成 _open-items.md；业务只需用 Typora/Obsidian 就地编辑业务拥有的几个 .md。这是 AI Native IT 交付在"需求采集"环节的具象化。
与 Domain-Pack Protocol 的关系（先读这个）
本 skill 派生出的 pack 文件必须落进协议规定的槽。协议是槽的最终权威（谁填/文件名/必需性以 ../data-analysis/references/domain-pack-protocol.md 为准）。但下表是 builder 自足的「必需槽 manifest」——派生时必须逐槽走一遍、每个都产出（或显式判定"本 domain 不适用/材料未提供"），绝不因"详情在协议"就跳过某个槽。
★ 为什么要自足清单： 若只说"槽清单以协议为准"、不在此列全，派生时很容易只填手上有模板的槽、不追协议指针——triggers.md（必需的路由槽）和设计系统槽会被静默丢掉，产出的 pack 在 Step 0 根本无法被检测。所以本表列全（含 triggers / 设计系统槽），且 Step 4.5 自检会核"必需槽是否都在"。
| 槽（通用文件名） | 类别 | 谁填 / 怎么来 | 本 skill 怎么产 |
|---|
README.md | AI | pack 导览 + 槽→文件 manifest | 从手册综合 |
triggers.md | AI 生成 · 必需 | Step 0 域检测触发块（keyword / data-shape / intent + Excluded 段） | 从领域词汇/别名 + 数据画像的度量列 + 提问模式派生（MECE：全+纯） |
glossary.md | 业务拥有（AI 起草） | 业务直接编辑本 md（WYSIWYG）；AI 起草草稿 | 从手册术语段 + 数据术语（口径/期义，不焊列名）派生 |
data-spec.md | 协议 + AI | §1 字段角色 + §2 当前数据画像 | §1 从分析需求派生；§2 从读数据 profile 派生（数据的列结构/多候选列归这里，不进 glossary） |
framework.md | AI 生成 | AI 从理论材料提炼 | 从手册 Part A 派生（含深度纪律声明：signature_leaves / expand_over+形状 / min_depth / over_caliber） |
computation-reference.md | AI 生成 | 计算配方（角色+pandas 模式+verdict+config；公式引 glossary、不内联本体） | 从手册里的分解/归因桥派生；rule-engine verdict 带 rule_source |
insight-extensions.md | AI 生成 | 输出模板/标签扩展 + deck_audit 配置 + AI-slop 黑名单 SSOT | 从成品示例材料的输出母版派生 |
context-notes.md | 业务拥有（AI 起草） | 情境上下文 + 杠杆偏好 + 合规护栏；业务可直接编辑 | 从手册市场/背景段派生 |
设计系统槽（如 <Brand>-PPT-Design-System.md + logo 资源） | AI/外部 · 可选 | 视觉规范 SSOT（颜色 token / 字号档 / 组件 / logo） | 业务提供品牌 deck 模板/规范则挂载；无则显式声明"缺、回退通用层 insight-templates.md"（不编造） |
clarification-extensions.md | AI + 业务（可选） | 该 domain 常见澄清项 | 从反复出现的歧义派生 |
_open-items.md | AI 生成（索引） | 自动汇总全 pack 的 ⚠️待确认 | 扫描全 pack 生成 |
business-rules.md | 业务拥有（AI 起草） | 业务直接编辑本 md（小数值表） | 从材料里的可调值起草草稿（值一律 ⚠️待确认、绝不编造） |
sources/ | 业务提供 | 原始材料（deck/PDF/PPT/数据/访谈） | 本 skill 的输入 |
Domain pack = 这些 .md（+ 可选 sources/）。没有 Excel、没有中间 workbook、没有抽取 JSON。 业务直接编辑业务拥有的几个 .md（glossary.md 定义、business-rules.md 值、context-notes.md），用所见即所得编辑器（推荐 Typora——像 Word 改表格；或 Obsidian）。
文件名全部通用（context-notes.md 而非 <某domain>-market-notes.md）——内容才特化。如果你发现自己要造一个 domain 专属文件名，停下来，回到协议的通用槽名。
三条核心边界（决定"什么放哪" + "派生要满足什么接口"）
-
概念定义 vs 可调值 —— glossary.md vs business-rules.md：
- 一个词永恒的含义 + 公式 →
glossary.md（业务直编）。
- 会随地区/时点/策略变的具体数值/映射（如分档切点、目标值、对标基准、维度映射等——具体类别由本 domain 从自己材料声明）→
business-rules.md（业务直编小数值表）。
- 判定法：这东西"换个地区/组织单元、换个时点、换套策略会不会变"？会→
business-rules.md；不会→glossary.md。
- 这两个文件 +
context-notes.md 都是业务拥有、直接编辑的 .md；AI 只起草草稿、把拿不准处标 ⚠️待确认。
- AI 派生的文件（framework / computation-reference）只引用、绝不内联这些值。
- ⚠️ 对业务已写进
.md 的值：不删除（业务内容只加不删），改为加指针"权威值以 business-rules.md 为准"。
-
零预置脚本：pack 不预置 scripts/*.py。计算靠 computation-reference.md（配方）+ business-rules.md（值），由 data-analysis 的 agent 运行时现写现跑。本 skill 派生时产出 computation-reference.md 配方，不产出 .py。
-
★ pack 必须满足 data-analysis 的接口契约（派生 = 填接口，不只是填内容）：pack 不是一堆"加载即读的散文"——它要被 data-analysis 的 0+9 workflow + 三道可执行闸门驱动。派生任何 pack 文件前，先读 ../data-analysis/references/9-step-framework.md 的不变量 I1–I5 + coverage / data_integrity / deck_audit 三闸门——你派生的东西必须填满这四个机器接口（缺任一 → 即便 pack 被加载，workflow 也驱动不了它，深度/覆盖/deck 审计全失效）：
- ① framework 的深度纪律声明 ——
signature_leaves（招牌叶子权威清单）· expand_over: <role> + 最小应答形状（grid/ladder/top-N/scalar）· min_depth（二阶深度要素）· over_caliber（并列口径）。喂 coverage gate 的 check 5/6/7 与不变量 I4。
- ② computation 的
rule_source —— rule-engine 驱动的叶子（处方/方向类）verdict 必须带 rule_source（引 business-rules 哪条）。喂不变量 I2。
- ③ insight-extensions 的
deck_audit 配置 —— 第三道闸门（字号下限/禁词/logo/矩阵类）的 domain 配置 + AI-slop 黑名单 SSOT。
- ④ data-spec 的字段角色 + §1.6 映射机制 —— 通用层 profiling 靠它把上传数据映射到角色。喂不变量 I5（跨 sheet 取数 + 粒度继承）。
判据：派生时容易在"有模板的地方"做对、在"模板沉默的接口"漏掉，所以本条把四接口显式点名，pack-templates / derivation-map 的对应模板都带这些字段、Step 4.5 自检逐一核对。这些是"机制"、跨 domain 通用；具体名单（哪些叶子招牌、逐哪个维度、禁哪些词）由本 domain 从自己材料派生，不是通用固定清单。
When this Skill activates
启用条件：
- 用户要为某个分析领域新建 domain pack（哪怕只有零散材料）。
- 用户要刷新/维护现有 pack：来了新数据 / 新材料 / 业务纠正 / 数据 refresh。
- 用户提供训练 deck / 某职能视角 deck / 要复刻的成品分析 / 数据 Excel / SME 访谈录音或文字稿。
- 用户说"把这些材料研读成 domain pack"、"先写理解手册再派生 pack"、"给某领域建/更新 domain pack"、"刷新一下 domain pack"。
不要启用：与 domain pack 无关的通用转录、音频分析（音乐/环境声）、普通会议纪要生成。
The Research Flow — 6 steps（+ Step 4.5 派生后自检）
对齐 Domain-Pack Protocol §4。这是一个可重入的研究循环：首建走全程，增量更新只走受影响的步。
Step 1: Intake & 源分类 材料入库 → sources/；分两类（理论材料 / 数据材料）；标权威权重
Step 2: 视觉逐页精读 ★ deck/PDF/PPT 逐页视觉读（图表要看懂，必要时渲染成图）；
材料多 → 并行派 reader 子 agent（一份材料一个）；各产出逐页研读笔记
Step 3: 写《理解手册》★ 综合所有材料 + 逐份材料逐页解读 → 一份手册（outputs/understanding-handbook.md）；
这是派生一切 pack 文件的桥梁；★ Part A 含「分析深度契约」（喂 framework 深度声明）
Step 4: 从手册 + 数据派生 triggers ← 领域词汇+数据列+提问模式；framework/computation/context ← 理论材料；
data-spec ← 数据；glossary ← 两者；insight-extensions（含 deck_audit 配置）← 成品示例；
★ 逐槽走「必需槽 manifest」+ 填四个机器接口；拿不准处就地标 ⚠️待确认
Step 4.5: 派生后自检 ★新 跑 references/derived-pack-audit.md 的 checklist：必需槽全在（含 triggers/设计系统）、
四接口齐备、SSOT 无双写、双层边界、反幻觉接口；不过 → 回 Step 4 补。再扫全 pack 生成 _open-items.md
Step 5: Business 就地改 .md 业务用 Typora/Obsidian 就地改业务拥有的 .md，删 ⚠️待确认 标记
Step 6: Delta 新材料 / 新数据 / 业务改 md → 重读 delta → 更新手册 → 重派生受影响文件 → 重跑 Step 4.5
★ 三个最容易漏、必须做到的步：Step 2 视觉逐页精读（不能只读文字、不能跳过图表）、Step 3 先产《理解手册》（不能从材料直接跳到 pack 文件；Part A 要含「分析深度契约」）、Step 4.5 派生后自检（没有它，triggers 槽 + 四个机器接口会被静默丢掉、pack 驱动不了 workflow）。
业务触点 = 直接编辑 pack 里业务拥有的几个 .md（glossary.md / business-rules.md / context-notes.md），一个编辑器、一个文件夹。其余全部 AI 研读、AI 派生、业务 review。没有 Excel、没有 workbook、没有抽取 JSON、没有搬运。
Step 1 — Intake & 源分类（材料入库 + 分两类 + 标权威）
Goal: 把材料归到 domains/<domain>/sources/，按用途分两类，并标注每份材料的权威权重（建 pack 时谁说了算）。
两类源（决定一份材料喂哪些 pack 文件）：
| 类 | 是什么 | 教什么 | 喂哪些 pack 文件 |
|---|
| (a) 理论/领域材料 | 训练 deck / PDF / PPT / 成品分析示例 / SME 访谈 | 这个 domain 是什么、怎么分析、什么 context 有用 | framework.md / computation-reference.md / context-notes.md / glossary.md（领域术语）/ triggers.md（keyword+intent）；成品示例额外喂 insight-extensions.md |
| (b) 数据材料 | Excel / CSV | 实际数据结构（sheet/列/粒度/时间口径） | data-spec.md（§1 角色 + §2 画像）/ glossary.md（数据术语）/ triggers.md（data-shape） |
glossary.md 来自两者：领域术语（来自理论材料的概念/KPI 定义）+ 数据术语（来自数据材料的口径/期义，如各类周期口径、分档命名）。
triggers.md 也来自两者：keyword/intent 来自理论材料的领域词汇与提问模式、data-shape 来自数据画像的度量列（详见 Step 4 派生表）。
权威权重（authority weight）：不同材料对不同 pack 文件的权威性不同，建 pack 时要尊重。在 sources/ 的 manifest 里标，例：
- GM 亲自分享的训练 deck → 对
framework.md（模型/杠杆/术语骨架）最权威，照搬不改写。
- 要复刻的成品分析示例（finished sample analysis）→ 对
insight-extensions.md（输出母版）+ framework.md（issue tree）最权威。
- 某职能视角 deck（如某职能/其他视角）→ 补充叙事/优先级排序，与主框架互补。
- 数据文件 → 对
data-spec.md §2 是事实基准（口径冲突时以实际数据列为准）。
Actions:
- 把材料拷入（或登记到）
domains/<domain>/sources/，维护 manifest（每份：来源、日期、谁给的、类别 (a)/(b)、权威权重、覆盖什么主题）。
- 若是音频 → 转写成文字稿（转写脚本运行时现写，遵循本 skill「Scripts（零预置）」一节的编码约定；不预置在本 skill）。
- 验证材料质量；音质差/有缺口 → 标记请补。
Reference: 源分类规则 + 权威权重见 references/source-handling.md。
Step 2 — 视觉逐页精读（★ 关键，现在最容易缺）
Goal: 把每份 deck/PDF/PPT 逐页、视觉地、无遗漏地读懂——每一页的全部内容（文字 + 图表/表格/示意图的判读）都要讲清楚，产出每份材料一份逐页研读笔记。
铁律（不可省）：
- 每一页都讲清，逐页无遗漏，不允许跳页或"次要页合并"——deck 的每一页都承载信息，逐页完整解读（即便是过渡页/封面页也要说明它在叙事里的作用）。
- 视觉地读：图表/表格/示意图必须看懂趋势、轴、系列、数值——不能只读抽出来的文字。必要时把页面渲染成图片/截图来看（PDF→200dpi PNG；PPTX→渲染或导 PDF 再渲染）。渲染/解析代码运行时现写，遵循本 skill「Scripts（零预置）」一节约定，产物落
outputs/。
- 每页记三样：①这页讲什么（标题 + 该页全部要点，完整覆盖）②图表判读（每张图/表在说什么趋势/对比/数值，轴/系列/单位都要交代）③我的解读（这页对本 domain 分析意味着什么、喂哪个 pack 文件）。
- 数据材料（Excel/CSV）的对应动作是逐 sheet 读：profile 出 sheet/列/粒度/join/时间口径（靠读数据，不靠 LLM 猜），产出数据画像笔记。
材料多 → 并行派 reader 子 agent：一份材料派一个子 agent，各自做逐页精读、各产出一份逐页研读笔记到 outputs/material-notes/<material>.md。主 agent 在 Step 3 综合这些笔记。
Outputs: outputs/material-notes/<material>.md（每份材料一份逐页研读笔记，含图表判读）。
Reference: 视觉精读规则 + 渲染约定 + 笔记结构见 references/source-handling.md。
Step 3 — 写《理解手册》（★ 派生一切的桥梁，现在缺）
Goal: 把所有材料综合成一份《理解手册》，它既综合整体理解、又逐份材料逐页解读，是派生一切 pack 文件的桥梁，也是团队对齐的理解背书。先有手册，再派生 pack——不要从材料直接跳到 pack 文件。
质量 bar（高标准、彻底，不可降）：
- 逐页全覆盖：Part B 里每份理论材料的每一页都要完整讲清该页的全部内容——文字要点 + 图表/表格/示意图的判读，不允许"次要页合并/跳过"。逐页、无遗漏。
- 整体理解必须全面、透彻、成体系：Part A 不能浅尝辄止——要提炼出统领整个 domain 的模型，讲清各模块如何咬合、关键公式/方法/算法、以及每一块"这对分析意味着什么"的解读。读完手册的人应当对整个 domain 形成系统化、可操作的认知，而不只是页面摘要的堆叠。
- 手册越透彻，派生越扎实：手册是派生 framework/glossary/computation-reference 的唯一桥梁；它有多深，派生出的 pack 文件就有多扎实。宁可手册厚而透，不要薄而浅。
手册结构（四部分）：
- Part A — 整体理解：把所有理论材料综合成"这个 domain 是什么、统领模型、各模块如何咬合、分析框架/杠杆、关键公式与方法、真实成品长什么样、合规红线、对分析的启示"。这是
framework.md 等文件的"理解背书"，必须成体系、透彻。
- Part B — 逐份材料逐页解读：每份理论材料一节，逐页、无遗漏——每一页都完整讲清（讲什么 + 图表判读 + "这页对我们意味着什么"），链接回 Step 2 的逐页笔记。
- Part C — 数据的理解：综合数据画像笔记（sheet 关系、口径、能做什么/不能做什么）。
- Part D — 待业务确认清单：AI 从材料推断、需业务拍板的项（口径冲突、阈值、To-Be 目标等）汇总。
写作约定：描述用中文；domain 关键术语、KPI、公式、模板字段保留英文。手册落在 outputs/understanding-handbook.md（运行时产物，团队可读），不在 pack 里——pack 文件是从它派生的产物。
Reference: 手册指引见 references/understanding-handbook.md。
Step 4 — 从手册 + 数据画像派生 pack 文件 + 标 ⚠️待确认 + 生成 _open-items.md
Goal: 从《理解手册》+ 数据画像派生协议规定的全部 pack 文件；拿不准/要业务拍板处就地标 ⚠️待确认；扫描全 pack 自动生成 _open-items.md。
派生映射（手册/数据 → pack 文件）：
★ 逐槽走「必需槽 manifest」（上文槽表），一个都不跳——尤其别漏 triggers.md（必需路由槽）和设计系统槽（不显式核，这两个最容易被静默丢掉）。
| pack 文件 | 从哪派生 | 派生什么 |
|---|
triggers.md 必需 | 领域词汇/别名（理论材料）+ 数据画像的度量列 + 提问模式 | 三类信号 MECE（keyword / data-shape / intent）+ Excluded 段（专有名词/实体名、强歧义缩写、泛词，防误触发）+ slug + Brief |
framework.md | 手册 Part A（理论材料）+ Part A 分析深度契约 | 模型结构 + 杠杆 + 默认 issue tree + 假设模板 + 决策规则 + ★ 深度声明（signature_leaves / expand_over+最小形状 / min_depth / over_caliber）。值→指向 business-rules.md、公式→指向 glossary.md，均不内联 |
computation-reference.md | 手册里的分解/归因桥（理论材料） | 计算配方：字段角色 + pandas 模式 + verdict 形状（rule-engine 叶子带 rule_source）+ config/公式指针（不是 .py、不内联公式本体）+ §0 dynamic-read 契约 + 跨 sheet 角色解析 + Batch A/B 划分 |
context-notes.md（业务拥有） | 手册 Part A 的市场/组织/情境段（理论材料） | 市场背景/竞争格局/杠杆偏好 + 合规护栏（区分 fact vs SME opinion；纯 opinion 段 AI 留空占位 + ⚠️待确认、不编造）。时效存疑处标 ⚠️待确认 |
data-spec.md | 数据材料（§1 从分析需求；§2 从读数据 profile） | §1 字段角色（抽象接口）+ §1.6 角色→列映射机制 + 粒度层级/分类继承（I5） + §2 当前画像 + §2.6 多候选列辨析。§3 gap 不写——运行时产物 |
glossary.md（业务拥有） | 两者：理论材料的领域术语 + 数据材料的数据术语（口径/期义，不焊具体列名/表结构） | 术语 + 定义 + 公式（概念公式 owner=glossary）+ 别名。推断/冲突处标 ⚠️待确认 |
insight-extensions.md | 成品示例材料的输出母版（可回读 Step 2 逐页笔记取高保真细节） | 域标签 + 输出章节 + 图表词汇 + verdict 串模板 + deck_audit 配置 + AI-slop 黑名单 SSOT |
| 设计系统槽（可选） | 业务提供的品牌 deck 模板/规范 | 视觉规范 SSOT（颜色/字号/组件/logo）。材料无 → 显式声明"缺、回退通用层 insight-templates.md"，不编造 |
business-rules.md（业务拥有） | 材料里的可调值 | 值小表（如分档切点/目标值/对标基准/维度映射等，具体类别由本 domain 从自己材料声明）。每个值 ⚠️待确认、绝不填确定值 |
clarification-extensions.md（可选） | 反复出现的歧义 | 该 domain 常见澄清项（仅当会改变分析方向才问） |
_open-items.md（索引） | 扫描全 pack（Step 4.5） | 汇总全 pack 的 ⚠️待确认 当业务 checklist |
README.md | 手册综合 | pack 导览 + 槽→文件 manifest（含 triggers/设计系统槽）+ 阅读顺序 |
关键约束：
- 业务拥有的三个
.md（glossary.md / business-rules.md / context-notes.md）AI 只起草草稿，把拿不准/推断/冲突/要业务定值处就地标 ⚠️待确认——AI 不替业务编最终定义/值。纯 SME opinion 段（如"我觉得…"）AI 留空占位 + ⚠️待确认，绝不代写。
framework.md / computation-reference.md 里凡涉及"会变的值"→ 写成指向 business-rules.md 的指针，不内联具体数字；凡概念公式 → 指向 glossary.md，不抄公式本体（防 glossary↔computation 双写）。- ★ 四个机器接口必填（见三条核心边界 §3）：framework 深度声明 · computation
rule_source · insight-extensions deck_audit 配置 · data-spec §1 角色 + §1.6 映射机制。缺任一 → Step 4.5 自检 FAIL。
- 数据的列结构/多候选列辨析归
data-spec.md §2，不进 glossary.md（glossary 保持列名无关）。
data-spec.md 只写 §1（角色）+ §2（画像）；不写 §3 gap（运行时产）。insight-extensions.md 优先从要复刻的成品示例派生（它是输出母版）；高保真细节（确切标题语法/组件/陷阱）可回读 Step 2 逐页笔记。
Outputs: outputs/domain-pack-draft/<domain>/ 下的草稿 markdown（绝不直接覆盖 domains/<domain>/）；_open-items.md 在 Step 4.5 扫描后生成。
Reference: 派生映射见 references/derivation-map.md；各 pack 文件模板见 references/pack-templates.md；⚠️待确认 + _open-items.md 机制见 references/open-items.md。
Step 4.5 — 派生后自检（★ 新增，防"必需槽 + 机器接口被静默丢掉"）
Goal: 派生完、交草稿给业务前，跑一份 checklist 验证产出的 pack 既内容对、又能被 data-analysis 驱动。这道护栏把"漂移"从"静默出厂"变成"必须显式过关"——没有它，triggers.md 和四个机器接口最容易被无声丢掉。
做法： 按 references/derived-pack-audit.md 的 checklist 逐条自查，任一 FAIL → 回 Step 4 补，不带缺口进 Step 5。核心六查：
- 必需槽全在（含
triggers.md、设计系统槽的"有/显式声明缺"）——对照上文「必需槽 manifest」。
- 9-step 四接口齐备：① framework 声明
signature_leaves/expand_over+形状/min_depth/over_caliber ② computation rule-engine verdict 带 rule_source ③ insight-extensions 填 deck_audit 配置 ④ data-spec §1 角色 + §1.6 映射。
- SSOT 无双写：公式只在 glossary、值只在 business-rules、视觉实数只在设计系统槽——别处只引用。
- 双层边界：只动了
domains/<x>/，没往通用层 references/ 写 domain 词。
- 反幻觉接口：业务值全外置 + dynamic-read 指针；
⚠️待确认 纪律；纯 opinion 段留空未编造。
- 过拟合红旗：抽象规则/配方/framework/data-spec §1/glossary 定义里没焊死某份数据的 sheet 名/列名/join 键（具体列只能出现在 data-spec §2 实例画像）。
再扫全 pack 的 ⚠️待确认 生成 _open-items.md。（多 agent 拆分派生时，由主 agent 在全部文件落盘后统一扫描——见 references/open-items.md。）
Reference: references/derived-pack-audit.md（自检 checklist 全文）。
Step 5 — Business 就地编辑业务拥有的 .md（人工）
Goal: 业务按 _open-items.md 清单，用所见即所得编辑器就地把草稿改成最终值、删掉 ⚠️待确认 标记。
业务怎么做：
- 用 Typora（像 Word 改表格，不写 Markdown 语法）或 Obsidian 打开 pack 文件夹。
- 打开
_open-items.md，按清单逐条定位（glossary.md 定义、business-rules.md 值、context-notes.md 上下文）。
- 就地把 AI 草稿改成最终定义/值，并删掉那个
⚠️待确认 标记。重生成索引后它就消失。
- 也可主动补充 AI 没派生到的术语/值/上下文。
本步是人工的；本 skill 的职责是把草稿 + _open-items.md 索引做得足够低摩擦。预期业务时间：视条目数，通常 15–30 分钟。
Step 6 — Delta（增量更新触发）
pack 不是一次性产物。以下任一触发 → 回到对应步做增量（delta），而非全量重建。关键：delta 也要经过手册——先重读 delta、更新手册对应段，再重派生受影响的 pack 文件。
| 触发 | 回到哪步 | 做什么 delta |
|---|
| 来了新理论材料（新 deck / 新访谈） | Step 1→2→3→4 | 入库分类 + 逐页精读新材料 + 更新手册 + 重派生受影响的 pack 文件 + 新增 ⚠️待确认 |
| 来了新数据 / 数据 refresh | Step 2(读数据)→3(更新 Part C)→4 | 重读数据画像 + 更新手册 Part C + 重派生 data-spec.md §2；§1 角色一般不变 |
| 业务就地改了某个定义/值 | Step 5→4 | 业务在业务拥有 .md 就地改 + 删 ⚠️待确认 → AI 重扫索引；无需重跑全程 |
| 新的不确定项浮现 | Step 4 | 在对应 .md 就地补一个 ⚠️待确认 → 重生成 _open-items.md |
产出 diff，不产出覆盖：每次 delta 先产 outputs/diff-report.md（draft vs 现有 pack），人工 review 后 apply。
Hard Rules
- 研读优先于派生：先逐页视觉精读（Step 2）+ 先写《理解手册》（Step 3），绝不从材料直接跳到 pack 文件。
- 视觉地读 deck：图表/表格/示意图必须看懂；只读文字不算读懂——必要时渲染成图来看。
- 永不直接覆盖
domains/<domain>/：始终产 draft + diff，人工 apply。
- 永不编造 domain 知识：材料没覆盖的 → 就地标
⚠️待确认，进 _open-items.md。
- 遵循协议、不另立真理："pack 含哪些文件 / 谁填 / 文件名"以协议为最终权威；但本 skill 自带一份自足的必需槽 manifest（不把槽清单甩给协议指针，否则漏槽），只在"怎么研读/派生/维护"上展开。
- 零预置脚本：派生
computation-reference.md 配方，不派生 .py；转写/渲染/解析代码运行时现写。
- 定义/值分家 + 公式不双写：定义/概念公式→
glossary.md，值→business-rules.md，视觉实数→设计系统槽（均单一 owner），AI 派生文件（framework/computation）只引用不内联——computation 尤其不抄公式本体（引 glossary）。
- 业务内容只加不删：对业务已就地写进业务拥有
.md 的内容，AI 加指针、不删/不改写原文；纯 SME opinion 段留空占位 + ⚠️待确认、不代写。
- 保留原话 + 引用来源：定义尽量用 SME 原措辞；每条派生注明出处（手册段落 / deck 页码 / sheet·列 / 访谈时间戳）。
- 尊重权威权重：口径冲突时按 Step 1 标的权威权重定（如 framework 以 GM deck 为准、§2 画像以实际数据为准），拿不准则就地标
⚠️待确认 请业务定。
- ★ 填满四个机器接口（否则 pack 驱动不了 data-analysis）：framework 深度声明 · computation
rule_source · insight-extensions deck_audit 配置 · data-spec §1 角色 + §1.6 映射机制（见三条核心边界 §3）。
- ★ 派生后必过 Step 4.5 自检：必需槽全在（含 triggers/设计系统）、四接口齐备、SSOT 无双写、双层边界、无过拟合——不过关不交草稿。
- ★ 跨市场材料去偏：他国/他市场的指令集吸收其方法/公式，但本地化或剔除其市场专属的具体实体（具体竞争者/机构/计量单位命名），命名撞车吸收成映射（不是让外来实体泄漏进本 domain）。
References（按需加载）
Scripts（零预置）
本 skill 不预置脚本。需要的代码（音频转写、PDF/PPTX→图片渲染、数据 profiling、draft↔pack diff）由 agent 运行时现写，遵循以下编码约定：
- 可发现：每个脚本支持
--help，打印用途 + 参数。
- 可重入：可重复运行不破坏已有产物。
- 产物落
outputs/：所有中间/最终产物写到运行时 outputs/ 目录，不污染 pack。
- JSON 契约：脚本间传数据用结构化 JSON，不靠 LLM 转述数字。
- 反幻觉：数字来自脚本读真实数据/文件，不让 LLM 凭空算。
Output state
outputs/ 是运行时目录（手册、笔记、草稿都落这里）；正式 pack 在 domains/<domain>/：
outputs/ ← 运行时草稿/中间产物（不入 pack）
├── interview-transcript.txt (音频情形)
├── understanding-handbook.md ← Step 3《理解手册》（团队可读，派生桥梁；不在 pack 里）
├── material-notes/ ← Step 2 每份材料的逐页研读笔记（含图表判读）
│ ├── <material-a>.md
│ └── <material-data>.md (数据画像笔记)
├── domain-pack-draft/
│ └── <domain>/
│ ├── triggers.md ← ★ 必需路由槽（keyword/data-shape/intent + Excluded）
│ ├── README.md / glossary.md (草稿，业务拥有，含 ⚠️待确认)
│ ├── data-spec.md (§1+§1.6+§2，无 §3)
│ ├── framework.md (含深度声明) / computation-reference.md (草稿)
│ ├── context-notes.md (业务拥有，含 ⚠️待确认) / insight-extensions.md (含 deck_audit 配置)
│ ├── business-rules.md (业务拥有的值表草稿，含 ⚠️待确认)
│ ├── clarification-extensions.md (可选) / <Brand>-Design-System.md + logo (可选，或声明缺)
│ └── _open-items.md ← 自动扫描全 pack 的 ⚠️待确认 生成的业务 checklist
└── diff-report.md ← Step 6 delta：draft vs 现有 pack
domains/<domain>/ ← 人工 apply 后的正式 pack（协议槽）
└── (槽清单以 ../data-analysis/references/domain-pack-protocol.md 为权威)
注：没有 Excel / workbook / 抽取 JSON / 独立 memo。业务拥有的 glossary.md / business-rules.md / context-notes.md 由业务用 Typora/Obsidian 就地编辑；澄清机制 = 文件里的 ⚠️待确认 行内标记 + 自动生成的 _open-items.md 索引。
各产物应长什么样（质量与结构要求）
按这个研究流跑出来的产物应当满足下面的结构 + 质量要求（用文字描述，不指向任何具体文件）：
- 《理解手册》 →
outputs/understanding-handbook.md：四部分齐全（Part A 成体系的整体理解 / Part B 逐页无遗漏解读 / Part C 数据理解 / Part D 待确认）；Part A 透彻到能让人形成系统认知，Part B 每页都完整覆盖（文字 + 图表判读 + 解读）。
- 逐页研读笔记 →
outputs/material-notes/<material>.md：每份材料一份，逐页记三样（讲什么 / 图表判读 / 我的解读），数据材料则逐 sheet profile（sheet 关系 + 列清单 + 能做/不能做）。
- 派生出的 pack 文件 →
outputs/domain-pack-draft/<domain>/：逐槽走全「必需槽 manifest」——triggers（必需路由槽）/ README / framework（含深度声明）/ glossary / computation-reference / data-spec / context-notes / insight-extensions（含 deck_audit 配置）/ business-rules / clarification-extensions / 设计系统槽（可选或声明缺）/ _open-items。每条都能 trace 回手册某段 / 数据某 sheet·列 / 材料某页；值进 business-rules.md、正文只引用；四个机器接口填齐（Step 4.5 自检把关）。
⚠️待确认 + 索引 → 业务拥有的 .md 里就地标 ⚠️待确认 + 一句理由，扫描汇总成 _open-items.md 业务 checklist。
Why this Skill matters
没有它：SME 面对空白页瘫痪——他有知识但不知如何文档化，或被迫去写本该 AI 生成的 framework / computation。或者 AI 走捷径"抽取"——只读文字、跳过图表、丢掉理解，pack 派生得机械而失真。
有它：raw 材料 → AI 像人一样逐页视觉精读（图表看懂）→ 综合出一份《理解手册》（团队对齐 + 派生桥梁）→ 从手册 + 数据派生全部 pack 文件（拿不准处就地标 ⚠️待确认）+ 自动生成 _open-items.md → SME 用 Typora/Obsidian 就地编辑业务拥有的几个 .md。SME 的活从"从零写整个 pack"压缩到"在熟悉的编辑器里改几张表、删几个标记"。这正是 AI Native IT 交付：理解与需求采集本身被 AI 自动化，人只做就地验证。
Changelog
- v0.2（2026-07-05，与已迭代的 data-analysis 重新对齐）：早期 builder 停在 pack 的早期形态，漏了 pack 后来长出的、与 9-step 咬合的接口。本版补齐：
- 自足「必需槽 manifest」（含
triggers.md 必需路由槽 + 设计系统槽），不把槽清单甩给协议指针——否则派生时只填手上模板、静默丢槽。
- 三条核心边界 + 四个机器接口：pack 不只填内容、还要填
data-analysis 的接口——① framework 深度声明（signature_leaves / expand_over+形状 / min_depth / over_caliber）② computation rule_source ③ insight-extensions deck_audit 配置 + AI-slop 黑名单 SSOT ④ data-spec §1 角色 + §1.6 映射 + I5 粒度继承。derivation-map / pack-templates 模板同步带这些字段。
- 手册 Part A 加「分析深度契约」：从成品 deck 逆推招牌 / expand_over / min_depth / 口径，作为 framework 深度声明的源头。
- computation 停止内联公式本体（引 glossary，防双写）；数据列结构归 data-spec §2、glossary 保持列名无关。
- 新增 Step 4.5 派生后自检（
references/derived-pack-audit.md）：必需槽全在 + 四接口齐备 + SSOT 无双写 + 双层边界 + 无过拟合，把漂移从"静默出厂"变"必须显式过关"。
- source-handling 加跨市场吸收规则（吸收方法、去偏他市场实体、撞名转映射）；补 clarification-extensions 模板；多 agent 拆分派生时
_open-items 扫描归属。references 由 5 增至 6 份（加 derived-pack-audit.md）。
- 研究型 workflow（设计基线）：本 skill 是"像人一样研读材料 → 综合成《理解手册》→ 派生 pack 文件"的研究流，而非抽取管线。6 步；两个最易缺的关键步是 Step 2 视觉逐页精读、Step 3 先写《理解手册》。不采用：extraction-JSON-schema、按 section 机械抽取、中间抽取 JSON——与"研读 + 综合 + 派生"模型不符。
