diff --git a/skills/lark-doc/SKILL.md b/skills/lark-doc/SKILL.md
index dba61d2d7..3f5960b1a 100644
--- a/skills/lark-doc/SKILL.md
+++ b/skills/lark-doc/SKILL.md
@@ -24,9 +24,12 @@ lark-cli docs +update --doc "文档URL或token" --command append --content '<p>
 **CRITICAL — 执行对应操作前，MUST 先用 Read 工具读取以下文件，缺一不可：**
 1. [`../lark-shared/SKILL.md`](../lark-shared/SKILL.md) — 认证、权限处理、全局参数（所有操作通用）
 2. **读取文档（`docs +fetch`）** → 必读 [`lark-doc-fetch.md`](references/lark-doc-fetch.md)（`--scope` / `--detail` 选择、局部读取策略、`<fragment>` / `<excerpt>` 输出结构）
-3. **创建或编辑文档内容** → 必读 [`lark-doc-xml.md`](references/lark-doc-xml.md)（XML 语法规则，仅当用户明确要求 Markdown 时改读 [`lark-doc-md.md`](references/lark-doc-md.md)）和 [`lark-doc-style.md`](references/style/lark-doc-style.md)（元素选择、丰富度规则、颜色语义）；从零创建时加读 [`lark-doc-create.md`](references/lark-doc-create.md)（含 Document Authoring Loop）；编辑已有文档时加读 [`lark-doc-update.md`](references/lark-doc-update.md)（含 Observe-Diagnose-Patch Loop）
+3. **创建、重写、润色、排版或生成较多正文** → 必读 [`lark-doc-design-philosophy.md`](references/lark-doc-design-philosophy.md) 和 [`lark-doc-xml.md`](references/lark-doc-xml.md)（仅当用户明确要求 Markdown 或提供 `.md` 文件时改读 [`lark-doc-md.md`](references/lark-doc-md.md)）；
+   - 如果 `lark-doc-design-philosophy.md` 的体裁路由命中某个 `references/genres/*.md` 文件，只读取该体裁文件；
+   - 从零创建时加读 [`lark-doc-create.md`](references/lark-doc-create.md)；
+   - 编辑已有文档时加读 [`lark-doc-update.md`](references/lark-doc-update.md)。
 
-**未读完以上文件就执行相应操作会导致参数选择错误或格式错误。**
+**Philosophy 负责判断；Genre 负责偏好；Create / Update 负责执行；XML 负责合法表达。未读完以上文件就执行相应操作会导致参数选择错误或格式错误。**
 
 > **格式选择规则（全局）：**
 > - **创建 / 导入场景**（`docs +create`，或 `docs +update --command append/overwrite` 的整段写入）：XML 和 Markdown 都可以。用户提供 `.md` 本地文件、或明确说"导入 Markdown"时，直接用 Markdown；否则默认 XML（可用 callout、grid、checkbox 等富 block）。
diff --git a/skills/lark-doc/references/genres/formal-doc.md b/skills/lark-doc/references/genres/formal-doc.md
new file mode 100644
index 000000000..6338cd4e3
--- /dev/null
+++ b/skills/lark-doc/references/genres/formal-doc.md
@@ -0,0 +1,38 @@
+# Genre: Formal Document
+
+适用：通知、制度、公告、汇报、立项、正式方案、对外说明、需要归档或跨团队协作的文档。
+
+## Structure patterns
+
+按任务选择结构，不要机械套用：
+
+- **事项通知**：事项 → 适用范围 → 具体安排 → 时间节点 → 责任人 / 联系方式。
+- **决策汇报**：结论 / 建议 → 背景 → 方案对比 → 风险影响 → 待决策问题。
+- **制度规范**：目的 → 适用范围 → 规则正文 → 例外情况 → 执行与解释。
+- **正式方案**：问题定义 → 目标与范围 → 方案 → 资源 / 排期 → 风险 → 下一步。
+
+## Style
+
+准确、克制、明确责任边界。优先写清对象、动作、时间、范围和责任人。少用夸张修饰，不使用网感标题。避免用“赋能、闭环、抓手、沉淀、拉通、对齐”等空泛词替代具体动作。
+
+## Component bias
+
+- 时间、责任、范围、事项清单：优先 table。
+- 风险、待确认、强约束：可用 callout。
+- 方案对比：table / grid / 决策矩阵。
+- 流程、组织关系、里程碑：必要时用 whiteboard。
+- 长期归档、对外说明：少用颜色和 emoji，保持朴素。
+
+## Avoid
+
+- 开头铺太长背景，迟迟不给结论。
+- 缺少责任人、时间、范围、生效条件。
+- 为了正式感堆砌抽象词。
+- 为了美观强行加入 callout、grid 或画板。
+
+## Final check
+
+- 事项、范围、责任、时间是否明确？
+- 结论和待决策问题是否前置？
+- 语气是否正式、克制、无夸张？
+- 是否适合归档和后续追责？
\ No newline at end of file
diff --git a/skills/lark-doc/references/genres/prd.md b/skills/lark-doc/references/genres/prd.md
new file mode 100644
index 000000000..5c926c304
--- /dev/null
+++ b/skills/lark-doc/references/genres/prd.md
@@ -0,0 +1,39 @@
+# Genre: PRD / Product Requirement
+
+适用：PRD、需求说明、用户故事、产品方案、功能设计、版本范围说明。
+
+## Structure patterns
+
+按任务选择结构：
+
+- **标准 PRD**：背景与问题 → 用户与场景 → 目标与非目标 → 方案概述 → 功能范围 → 交互 / 流程 → 数据与埋点 → 边界异常 → 验收标准 → 风险依赖。
+- **轻量需求**：问题 → 目标 → 用户故事 → 规则 → 验收标准 → 待确认。
+- **产品方案**：现状 → 机会 / 问题 → 方案 → 取舍 → 里程碑 → 风险。
+- **功能评审**：结论 → 范围变化 → 核心流程 → 争议点 → 待决策问题。
+
+## Style
+
+具体、可评审、可验收。多写用户行为、系统响应、状态变化和规则，少写抽象愿景。每个需求尽量落到状态、规则、字段、交互或验收条件。
+
+## Component bias
+
+- 用户故事、验收标准：列表 / checkbox。
+- 字段、规则、状态、埋点：table。
+- 用户流程、系统流程、状态机：whiteboard。
+- 风险、依赖、待确认：callout。
+- 版本范围、需求优先级：table / 小标题。
+
+## Avoid
+
+- 只有需求描述，没有验收标准。
+- 混淆目标、方案、交互和实现细节。
+- 没有非目标，导致范围无限扩大。
+- 缺少异常状态、边界条件和数据规则。
+- 用“大幅提升体验”替代具体用户收益。
+
+## Final check
+
+- 目标、非目标和范围是否清楚？
+- 用户、场景、规则和状态是否可评审？
+- 验收标准是否可验证？
+- 风险、依赖和待确认项是否明确？
\ No newline at end of file
diff --git a/skills/lark-doc/references/genres/retrospective.md b/skills/lark-doc/references/genres/retrospective.md
new file mode 100644
index 000000000..8f655e2d9
--- /dev/null
+++ b/skills/lark-doc/references/genres/retrospective.md
@@ -0,0 +1,39 @@
+# Genre: Retrospective / Summary
+
+适用：项目复盘、事故复盘、阶段总结、周报、月报、季度总结、问题回顾。
+
+## Structure patterns
+
+按任务选择结构：
+
+- **事故复盘**：结论 → 影响范围 → 时间线 → 根因 → 处置过程 → 暴露问题 → 改进动作 → 负责人 / 截止时间。
+- **项目复盘**：目标 → 结果 → 关键事实 → 做得好的地方 → 问题与原因 → 经验沉淀 → 后续动作。
+- **周报 / 月报**：核心进展 → 关键结果 → 风险阻塞 → 下阶段计划 → 需要支持。
+- **阶段总结**：目标回顾 → 数据 / 事实 → 判断 → 问题 → 后续重点。
+
+## Style
+
+事实和判断分开。避免甩锅，也避免空泛反思。后续动作必须具体到负责人、时间和验收方式。不要用“加强对齐、持续优化、提升意识”替代真实动作。
+
+## Component bias
+
+- 时间线：table / whiteboard。
+- 根因和影响链路：列表 / 鱼骨图 / 因果图。
+- 行动项：checkbox / table。
+- 风险和阻塞：callout。
+- 数据对比：table / chart / whiteboard。
+
+## Avoid
+
+- 只有情绪评价，没有事实。
+- 只有“后续加强”，没有负责人和时间。
+- 时间线缺失，无法复盘过程。
+- 结论与证据不匹配。
+- 把复盘写成汇功或甩锅材料。
+
+## Final check
+
+- 事实、判断、动作是否分开？
+- 时间线和影响范围是否清楚？
+- 根因是否有证据支持？
+- 后续动作是否有负责人、截止时间和验收标准？
\ No newline at end of file
diff --git a/skills/lark-doc/references/genres/social-xhs.md b/skills/lark-doc/references/genres/social-xhs.md
new file mode 100644
index 000000000..30369a982
--- /dev/null
+++ b/skills/lark-doc/references/genres/social-xhs.md
@@ -0,0 +1,41 @@
+# Genre: Xiaohongshu / Social Content
+
+适用：小红书笔记、爆文、种草、攻略、经验分享、标题优化、社媒传播型内容。
+
+## Structure patterns
+
+按任务选择结构：
+
+- **经验型**：强钩子 → 痛点场景 → 个人经验 / 观察 → 方法清单 → 适用人群 → 互动结尾。
+- **攻略型**：结果承诺 → 准备条件 → 步骤 → 避坑点 → 清单总结。
+- **种草型**：使用场景 → 核心卖点 → 真实体验 → 对比 / 注意事项 → 行动建议。
+- **观点型**：反常识判断 → 论据 → 例子 → 常见误区 → 行动建议。
+- **清单型**：适用人群 → 清单分组 → 每项解释 → 收藏提醒 / 使用方式。
+
+## Style
+
+口语化、具体、有节奏。短段落优先，多用场景、例子和清单。可以有情绪，但不能编造经历、数据或效果。标题可以吸引人，但正文必须兑现标题承诺。
+
+## Component bias
+
+- 开头钩子：短段落 / callout。
+- 方法步骤：列表 / checkbox。
+- 避坑、对比、清单：grid / table。
+- 可收藏内容：checkbox / table。
+- 复杂流程才用 whiteboard；轻内容不要图表化。
+- emoji 可用，但要克制并保持语义一致。
+
+## Avoid
+
+- 标题党但正文兑现不了。
+- 过度使用“绝了、封神、天花板、救命、狠狠爱住”等空泛网感词。
+- 编造个人经历、效果数据、医学 / 金融 / 法律结论。
+- 信息太散，没有可保存的方法、清单或判断。
+- 为了网感牺牲事实准确性。
+
+## Final check
+
+- 标题是否有吸引力且不虚假？
+- 开头 3 秒内是否说明痛点或利益？
+- 正文是否有具体方法、例子或清单？
+- 是否适合收藏、转发或执行？
\ No newline at end of file
diff --git a/skills/lark-doc/references/genres/sop-tutorial.md b/skills/lark-doc/references/genres/sop-tutorial.md
new file mode 100644
index 000000000..f346e0715
--- /dev/null
+++ b/skills/lark-doc/references/genres/sop-tutorial.md
@@ -0,0 +1,40 @@
+# Genre: SOP / Tutorial
+
+适用：SOP、操作手册、培训材料、入门指南、使用说明、FAQ、流程规范。
+
+## Structure patterns
+
+按任务选择结构：
+
+- **SOP**：适用范围 → 前置条件 → 操作步骤 → 检查标准 → 异常处理 → 责任边界。
+- **入门教程**：适合谁 → 准备什么 → 快速开始 → 分步说明 → 常见问题 → 下一步。
+- **操作手册**：任务列表 → 每个任务的步骤 → 注意事项 → 错误处理 → 参考链接。
+- **FAQ**：问题分类 → 问题 → 简短答案 → 详细说明 / 操作入口。
+
+## Style
+
+直接、清楚、面向操作者。一句话只承担一个任务。按用户看到的界面命名，不按系统内部实现命名。优先使用动词开头的步骤，例如“打开”“选择”“填写”“确认”。
+
+## Component bias
+
+- 步骤：有序列表。
+- 检查项：checkbox。
+- 命令、配置、日志：pre / code。
+- 错误处理、条件分支：table / callout。
+- 流程复杂时：whiteboard。
+- 入口链接：button / link / url-preview。
+
+## Avoid
+
+- 缺少前置条件。
+- 步骤跳跃，默认读者知道上下文。
+- 用内部术语命名用户界面。
+- 没有失败处理或校验方式。
+- 一个步骤里塞多个动作。
+
+## Final check
+
+- 新手能否按步骤完成任务？
+- 前置条件、输入、输出和校验是否清楚？
+- 异常情况是否有处理方式？
+- 每一步是否只做一件事？
\ No newline at end of file
diff --git a/skills/lark-doc/references/genres/technical-doc.md b/skills/lark-doc/references/genres/technical-doc.md
new file mode 100644
index 000000000..307ae117b
--- /dev/null
+++ b/skills/lark-doc/references/genres/technical-doc.md
@@ -0,0 +1,40 @@
+# Genre: Technical Document
+
+适用：技术方案、架构设计、接口说明、API 文档、部署手册、迁移方案、排障指南、研发交接。
+
+## Structure patterns
+
+按任务选择结构：
+
+- **技术方案**：问题 / 背景 → 目标与非目标 → 约束 → 总体设计 → 模块设计 → 数据 / 接口 → 风险 → 验证 → 灰度 / 回滚。
+- **接口文档**：适用范围 → 鉴权 → 请求参数 → 响应结构 → 错误码 → 示例 → 兼容性。
+- **排障指南**：现象 → 影响范围 → 快速判断 → 排查步骤 → 常见原因 → 修复方式 → 升级路径。
+- **迁移方案**：范围 → 前置条件 → 步骤 → 校验 → 回滚 → 风险与窗口期。
+- **架构文档**：目标 → 上下文 → 架构图 → 核心链路 → 模块职责 → 数据流 → 边界限制。
+
+## Style
+
+精确、朴素、可实现、可验证。术语保持一致，不为了通俗牺牲准确性。不确定处标注“假设”或“待确认”。不要把技术取舍写成宣传话术。
+
+## Component bias
+
+- 命令、代码、配置、日志：pre / code。
+- 参数、字段、错误码、兼容性：table。
+- 架构、调用链、状态流转、部署拓扑：whiteboard / Mermaid。
+- 操作步骤、验收项：列表 / checkbox。
+- 风险、限制、回滚条件：callout。
+
+## Avoid
+
+- 只有概念，没有接口、数据、边界或验证。
+- 忽略失败场景、兼容性、监控、回滚。
+- 图很多，但没有说明依赖、调用关系或数据流。
+- 使用营销腔描述技术收益。
+- 改写时破坏代码、图片、引用、资源块或 token 化内容。
+
+## Final check
+
+- 读者能否据此实现、集成、排查或评审？
+- 目标、非目标、边界和失败场景是否清楚？
+- 参数、命令、接口和示例是否准确？
+- 是否有验证、灰度、回滚或排障路径？
\ No newline at end of file
diff --git a/skills/lark-doc/references/lark-doc-create.md b/skills/lark-doc/references/lark-doc-create.md
index 08860dcb1..037f3bbab 100644
--- a/skills/lark-doc/references/lark-doc-create.md
+++ b/skills/lark-doc/references/lark-doc-create.md
@@ -1,10 +1,10 @@
 # docs +create（创建飞书云文档）
 
 > **前置条件（MUST READ）：** 生成文档内容前，必须先用 Read 工具读取以下文件，缺一不可：
-> 1. [`lark-doc-xml.md`](lark-doc-xml.md) — XML 语法规则（使用 Markdown 格式时改读 [`lark-doc-md.md`](lark-doc-md.md)）
-> 2. [`lark-doc-style.md`](style/lark-doc-style.md) — 排版指南（元素选择、丰富度规则、颜色语义）
+> 1. [`lark-doc-design-philosophy.md`](lark-doc-design-philosophy.md) — 文档设计判断（读者任务、结构取舍、组件选择、反模板化）
+> 2. [`lark-doc-xml.md`](lark-doc-xml.md) — XML 语法规则（使用 Markdown 格式时改读 [`lark-doc-md.md`](lark-doc-md.md)）
 >
-> **未读完以上文件就生成内容会导致格式错误。**
+> **未读完以上文件就生成内容会导致结构失焦或格式错误。**
 
 从 XML（默认）或 Markdown 内容创建一个新的飞书云文档。
 
diff --git a/skills/lark-doc/references/lark-doc-design-philosophy.md b/skills/lark-doc/references/lark-doc-design-philosophy.md
new file mode 100644
index 000000000..2124f0ee0
--- /dev/null
+++ b/skills/lark-doc/references/lark-doc-design-philosophy.md
@@ -0,0 +1,98 @@
+# Lark Doc Design Philosophy
+
+- 把飞书云文档当作帮助读者完成理解、判断、决策或行动的界面，而不是内容容器。你的任务不是把信息铺满页面，而是为具体读者设计一条清晰、可信、可执行的阅读路径。
+- 本文件负责文档设计判断：读者任务、结构取舍、表达组件、反模板化和质量自检。具体执行流程见 `lark-doc-create.md` 和 `lark-doc-update.md`；XML / Markdown 语法见 `lark-doc-xml.md` / `lark-doc-md.md`；体裁结构和语气差异见 `lark-doc-genres.md`。
+
+## 0. Priority order
+
+当目标冲突时，按此顺序取舍：**事实准确性 > 信息层级 > 可扫描性 > 协作可执行性 > 视觉整洁 > 个性化表达**。事实不确定就标注假设 / 待确认；结构混乱先调信息层级；视觉和个性只能增强理解，不能牺牲事实、结构和执行。
+
+## 1. Ground it in the document job
+
+写作或改写前，先判断这篇文档的工作：
+
+- 读者是谁：决策者、执行者、评审者、客户、开发者、运营者，还是未来维护者？
+- 读者要完成什么：理解背景、做出决策、执行任务、评审方案、排查问题、学习方法、传播内容，还是留档备查？
+- 读完后读者应该能做什么：拍板、执行、确认风险、复用、转发、评论、排查或完成任务？
+- 文档寿命是什么：一次性沟通、项目周期内维护、长期知识库、正式归档，还是外部传播？
+
+如果用户没有明确这些信息，能安全假设时说明假设并继续；事实来源、产品口径、结论归属不确定时，先询问或标注待确认，不要编造确定性。
+
+## 2. Route by genre
+
+体裁决定结构、语气、证据密度和表达方式。不要用同一套“背景 / 目标 / 方案 / 风险 / 下一步”应对所有任务。
+
+当用户明确或暗示体裁时，只读取一个最匹配的体裁文件；不要读取整个 `genres/` 目录。简单编辑已有文档时，优先沿用原文体裁和风格，不额外读取体裁文件。
+
+| 用户意图 / 信号词 | 读取文件 |
+|---|---|
+| 通知、制度、公告、汇报、立项、正式方案、对外说明 | `genres/formal-doc.md` |
+| 架构、接口、API、部署、迁移、排障、研发方案、技术设计 | `genres/technical-doc.md` |
+| 小红书、爆文、种草、笔记、攻略、社媒传播、标题优化 | `genres/social-xhs.md` |
+| PRD、需求说明、用户故事、产品方案、功能设计 | `genres/prd.md` |
+| 复盘、事故总结、项目总结、周报、月报、阶段总结 | `genres/retrospective.md` |
+| SOP、操作手册、培训材料、入门指南、使用说明、FAQ | `genres/sop-tutorial.md` |
+
+如果任务混合多个体裁，优先选择决定**内容结构**的主文件；语气可以参考用户要求调整，不要为轻微语气差异读取第二个体裁文件。例如“写给领导看的技术方案”优先读 `technical-doc.md`，并采用更正式克制的语气。
+
+## 3. Structure is information
+
+- 结构不是装饰。标题、顺序、列表、表格、callout、grid、画板和引用块，都应该表达真实的信息关系。
+- 选择结构前先判断：这是顺序、并列、对比、因果、层级、状态、证据，还是行动关系？读者需要先知道什么，才能理解后面的内容？哪些信息应该前置为结论，哪些适合压缩或放到附录？
+- 文档开头不是固定的“背景”。决策文档先给结论和待拍板问题；执行文档先给目标、范围和时间线；复盘文档先给事实结论、影响和后续动作；技术文档先给适用范围、前置条件和快速路径；传播文档先给痛点、利益点或钩子。
+- 较长、复杂或面向传播 / 汇报 / 决策的文档，最好有一个主组织锚点，如一句话结论、决策矩阵、风险雷达、路线图、架构图、时间线、对比表或 checklist。只保留一个，不要到处制造亮点；短文档、微编辑、正式归档或简单 SOP 不必强行设计。锚点必须服务事实准确、信息层级和协作执行，不能为了个性化表达增加理解成本。
+
+## 4. Rich blocks must earn their place
+
+飞书富 block 是表达手段，不是装饰指标。不要为了“丰富”“高级”“专业”而加入固定比例的 callout、grid、table 或 whiteboard，优先选择最能降低理解成本的表达方式。
+
+| 信息关系 / 场景 | 优先表达 |
+|---|---|
+| 判断、背景、解释、理由 | 段落 / 小标题 |
+| 并列项、短步骤、注意点 | 列表 |
+| 待办、检查项、验收项 | checkbox |
+| 多对象、多字段、排期、指标、接口参数 | table |
+| 少数组并列信息、轻量对比、模块卡片 | grid |
+| 风险、限制、例外、强约束、待确认 | callout |
+| 外部意见、原话、会议纪要、引用材料 | blockquote |
+| 代码、命令、配置、日志 | pre / code |
+| 流程、架构、依赖、路线图、因果链路、复杂模型 | whiteboard |
+
+- 组件由信息关系决定，不由重要度决定。重要结论可以是段落、callout、表格或画板，选择标准是它能否让读者更快理解、比较、判断或行动。
+- 关键章节需要判断是否存在图示机会，画板用于图示明显降低理解成本的关系：流程、架构、依赖、时间线、因果、分层、组织关系、复杂对比。结构简单或文字更清楚时，不要强行画板化。具体 Mermaid / SVG / SubAgent 路由见 `lark-doc-whiteboard.md`。
+- 颜色只在帮助识别语义时使用；正式文档、技术文档、长期知识库和归档材料优先保持朴素。
+
+## 5. Writing style
+
+- 从读者一侧写，而不是从系统实现一侧写。用读者能识别和控制的事物命名，默认使用具体、主动、可执行的表达。
+- 具体比聪明更好。一致比花哨更重要。文档词汇是读者导航的路标，同一动作、状态、对象在全文中保持同名。
+
+## 6. Calibrate against AI-doc defaults
+
+写作或改写前，主动避开这些 AI 文档默认值：
+
+1. 不管任务是什么都套“背景 / 目标 / 方案 / 风险 / 下一步”。
+2. 用“赋能、闭环、抓手、沉淀、拉通、对齐”等空泛词替代具体动作。
+3. 开头写摘要，但没有结论、取舍、风险或行动。
+4. 为了“丰富”强行加入 callout、table、grid 或 whiteboard。
+5. 把所有重要信息都画板化。
+6. 标题整齐，但章节之间没有真实推进关系。
+7. 章节之间像多个 Agent 拼接，术语、语气、事实口径不一致。
+8. 改写已有文档时全文覆盖，破坏评论、引用、图片、画板或资源块。
+
+如果你的计划看起来像面对任何类似请求都会写出的文档，就修改它，使结构、语气和组件选择更贴合当前读者、任务和体裁。
+
+## 7. Final self-check
+
+交付前检查：
+
+| 指标 | 自检问题 |
+|---|---|
+| 读者任务 | 这篇文档是否帮助目标读者完成理解、判断、决策或行动？ |
+| 体裁匹配 | 结构、语气和证据密度是否符合当前体裁？ |
+| 信息结构 | 标题、顺序、列表、表格和组件是否表达真实关系？ |
+| 阅读负担 | 是否有段落过长、层级过深、表格过宽或组件过多？ |
+| 组件必要性 | callout、grid、table、whiteboard 是否真的降低理解成本？ |
+| 风格一致 | 是否延续用户给定样例或已有文档风格？ |
+| 事实保真 | 改写时是否保留事实、引用、图片、附件、资源块和关键措辞？ |
+| 行动清晰 | 读者下一步应该做什么是否明确？ |
\ No newline at end of file
diff --git a/skills/lark-doc/references/lark-doc-update.md b/skills/lark-doc/references/lark-doc-update.md
index bf2d6f40c..10579e4c7 100644
--- a/skills/lark-doc/references/lark-doc-update.md
+++ b/skills/lark-doc/references/lark-doc-update.md
@@ -1,11 +1,11 @@
 
 # docs +update（更新飞书云文档）
 
-> **前置条件（MUST READ）：** 生成文档内容前，必须先用 Read 工具读取以下文件，缺一不可：
-> 1. [`lark-doc-xml.md`](lark-doc-xml.md) — XML 语法规则（使用 Markdown 格式时改读 [`lark-doc-md.md`](lark-doc-md.md)）
-> 2. [`lark-doc-style.md`](style/lark-doc-style.md) — 排版指南（元素选择、丰富度规则、颜色语义）
->
-> **未读完以上文件就生成内容会导致格式错误。**
+> **前置条件（MUST READ）：**
+> - 仅做明确旧文本 → 新文本的简单替换、错别字修正、日期 / 人名 / 数字替换时，读取本文件即可；写后必须 fetch 验证。
+> - 涉及新增正文、重写段落、调整结构、润色语气、美化排版、补充图表或保真改写时，必须读取：
+>   1. [`lark-doc-design-philosophy.md`](lark-doc-design-philosophy.md) — 文档设计判断（读者任务、结构取舍、组件选择、反模板化）
+>   2. [`lark-doc-xml.md`](lark-doc-xml.md) — XML 语法规则（使用 Markdown 格式时改读 [`lark-doc-md.md`](lark-doc-md.md)）
 
 通过八种指令精确更新飞书云文档。支持字符串级别和 block 级别的操作。
 
diff --git a/skills/lark-doc/references/style/lark-doc-create-workflow.md b/skills/lark-doc/references/style/lark-doc-create-workflow.md
deleted file mode 100644
index d845e91c0..000000000
--- a/skills/lark-doc/references/style/lark-doc-create-workflow.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# 从零创作工作流
-
-用户提供主题、需求或简要说明，需要生成一份新的飞书文档时，遵循本工作流。
-
-## 核心方法论 — Code-Act Loop
-
-通过自适应的 **Code-Act Loop** 驱动文档创作，而非固定模板式的工作流。每次任务都循环执行：
-
-1. **Plan（规划）** — 根据用户目标和文档当前状态，评估下一步该做什么
-2. **Execute（执行）** — 运行相应的 `lark-cli docs` 命令，或 **spawn** Agent 子任务并行推进
-3. **Observe（观察）** — 检查命令输出，验证正确性，确认内容是否满足用户目标
-4. **Iterate（迭代）** — 如需调整，回到 Plan 继续循环
-
-循环在文档达到质量标准且满足用户需求时结束。不要试图一次性产出完美内容——迭代打磨效果更好。根据用户实际需求灵活决定文档结构和版块，而不是套用固定模板。
-
-
-## 典型 Code-Act Loop 流程
-
-### 步骤一：规划与初始创建（串行）
-
-1. 分析用户需求：受众、目的、范围
-2. 设计大纲：根据任务自然选择结构。可以是短文、纪要、FAQ、方案、报告、清单或其他形式；不要默认套固定章节、固定开头或固定富 block 配比
-3. `docs +create` 创建文档。长文档可**只建骨架**：标题 + 各级标题 + 每节一句占位摘要；短文档可以一次写入完整内容
-   - ⚠️ 创建较长文档时，**不要**一次性把完整章节内容塞进 `--content`。超长 `--content` 容易触发字符/参数限制。
-   - 完整内容留到步骤二，由各 Agent 用 `block_insert_after --block-id <章节标题 block_id>` 分段写入。
-   - ⚠️ **`@file` 路径限制**：`--content @file` 只接受当前工作目录下的相对路径，传绝对路径（如 `@/tmp/xxx.md`）会报 `unsafe file path`。需要落盘时，将文件写在 cwd 下，用完自行清理。
-
-### 步骤二：分段撰写（并行 Agent）
-
-4. Spawn Agent 并行撰写各章节。每个 Agent 需收到：
-   - 文档 token、负责的章节范围、用户目标、目标读者和已有风格线索
-   - `lark-doc-xml.md` 和 `lark-doc-style.md` 的完整路径（Agent 须先读取）
-   - 使用 `block_insert_after --block-id <章节标题 block_id>` 写入对应章节内容
-
-### 步骤三：整合审查与画板识别（串行）
-
-5. `docs +fetch --detail with-ids` 获取文档，审查整体效果
-6. 评估内容是否满足用户目标：事实是否完整、结构是否清楚、语气是否匹配、是否保留必要素材
-7. **画板意图识别**：逐章节扫描，按 `lark-doc-style.md`「画板意图识别」表判断是否有段落适合用图表达。重要信息优先画板化，记录需要插图的章节、推荐画板类型、mermaid/SVG 路径和用于画图的源内容
-
-### 步骤四：画板处理与润色（并行 Agent）
-
-8. **优先处理步骤三识别出的画板需求**：
-   参考 [lark-doc-whiteboard.md](../lark-doc-whiteboard.md)中的方式，插入图表画板。
-9. Spawn 内容改写 Agent 定向润色：
-   - 文字密集且不易读时，优先拆段、改列表、增加小标题或调整顺序；只有确实存在行列数据、并列对比或强提醒信息时，才考虑 `<table>` / `<grid>` / `<callout>`
-   - 需要明显分隔的主题可补充 `<hr/>`，不强制章节间都使用
-   - 本地图片使用 `docs +media-insert` 插入
-
-
-## Agent 子任务要求
-
-内容改写 Agent 必须收到：文档 token、章节范围（标题/block ID）、`lark-doc-xml.md` 和 `lark-doc-style.md` 路径、用户目标/风格要求、具体的 `docs +update` command 和 `--block-id`。
-
-Mermaid 图由主 Agent 直接插入 `<whiteboard type="mermaid">...</whiteboard>`，无需 SubAgent。
-
-SVG SubAgent 必须收到：文档 token、插入位置（标题/block ID）、图表目标、源内容片段、`lark-doc-xml.md` 路径，以及[lark-doc-whiteboard.md](../lark-doc-whiteboard.md) 中的 "SVG 设计 Workflow" 指南。它只负责插入一个 `<whiteboard type="svg">...</whiteboard>`，不改其他正文，也不读取 `lark-whiteboard`。
-
-已有画板更新 SubAgent 必须收到：board_token、图表目标、推荐画板类型、源内容片段、[`../../../lark-whiteboard/SKILL.md`](../../../lark-whiteboard/SKILL.md) 路径。它只负责写入画板，不改文档正文。
diff --git a/skills/lark-doc/references/style/lark-doc-style.md b/skills/lark-doc/references/style/lark-doc-style.md
deleted file mode 100644
index 81f2fbdc6..000000000
--- a/skills/lark-doc/references/style/lark-doc-style.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# 文档表达组件参考
-
-本文件说明飞书文档可用的结构化表达方式，供模型在需要时选择。它不是固定模板，也不是强制排版规范。
-
-默认原则：优先理解用户目标、受众、素材形态和已有文档风格，由模型自主决定结构、语气和视觉呈现。只有当用户明确要求“美化、重排版、做成报告/方案/看起来更专业”等，或内容本身明显需要结构化承载时，才主动使用下列组件。
-
-## 一、核心原则
-
-1. **服务内容，而非套模板**：先判断信息最自然的表达方式，再选择段落、列表、表格、分栏、画板等元素
-2. **尊重用户风格**：用户给出样例、语气、结构或已有文档时，优先沿用；没有要求时不强行使用固定开头、固定章节或固定视觉组件
-3. **适度结构化**：结构化 block 用于降低理解成本，不为了“丰富”而堆叠
-4. **保持一致但不过度统一**：同类信息可使用相近表达，但允许因内容差异采用不同形式
-5. **图示服务理解**：流程、架构、对比、风险、路线图、指标趋势等内容在图示明显降低理解成本时，可使用画板表达
-
-## 二、元素选择指南
-
-需要图表时，按类型选择插入方式：思维导图/时序图/类图/饼图/甘特图可用 `<whiteboard type="mermaid">` 直接内嵌；简单 SVG 可由主 Agent 直接写入；复杂 SVG 可启动 SubAgent 插入 `<whiteboard type="svg">完整 SVG</whiteboard>`；只有编辑**已有**画板或特别复杂图表时才调用 **lark-whiteboard** skill。
-
-| 场景                                         | 可选表达方式                                |
-|--------------------------------------------|---------------------------------------|
-| 少数需要视觉提醒的短句，如风险、限制、待确认事项或关键提醒          | 需要视觉提醒时可用 `<callout>`；普通结论、摘要或章节导语优先使用段落、列表、小标题或加粗 |
-| 方案对比 / 优劣势 / Before vs After                | 简短对比可用段落、列表或 `<grid>`；维度较多且需要逐项比较时再考虑 `<table>` 或画板 |
-| 简短低风险对比                                    | `<grid>` 2 列分栏                        |
-| 需要按行列精确比较或查阅的数据，如指标、清单、字段说明、排期           | 可用 `<table>`；短要点、步骤、摘要或普通说明优先使用段落、列表或小标题 |
-| 任务清单 / 检查项                                 | `<checkbox>`                          |
-| 代码片段                                       | `<pre lang="x" caption="说明">`         |
-| 引用 / 公式                                    | `<blockquote>` / `<latex>`            |
-| 操作入口 / 跳转链接                                | `<button>` / `<a type="url-preview">` |
-| 流程图 / 时间线 / 示意图 / 自定义图形 / 架构图 / 数据图 / 思维导图等 | 画板图表                                  |
-
-
-### 画板意图识别
-
-撰写或审查每个段落/章节时，**必须判断该内容是否适合用图表达**。满足以下任一特征时，应使用画板而非纯文本；如果该内容承载章节核心结论、关键决策或主要论据，即使结构较简单也优先画板化：
-
-| 内容特征 | 信号词 / 模式 | 推荐画板类型 |
-|-|-|-|
-| 多步骤的操作流程或决策路径 | "先…然后…最后"、"步骤 1/2/3"、"如果…则…否则" | 流程图 / 泳道图 |
-| 系统或模块间的依赖与交互 | "调用"、"依赖"、"上游/下游"、"请求→响应" | 架构图 |
-| 上下级或从属关系 | "汇报给"、"下属"、"隶属"、"团队结构" | 组织架构图 |
-| 时间线或阶段演进 | "Q1/Q2"、"里程碑"、"阶段一→阶段二"、日期序列 | 时间线 / 里程碑 |
-| 因果分析或问题归因 | "根因"、"原因"、"导致"、"影响因素" | 鱼骨图 |
-| 两个及以上方案/对象的多维度对比 | "vs"、"方案 A/B"、"优劣"、"对比" | 对比图 |
-| 层级递进或优先级排序 | "基础→进阶→高级"、"L1/L2/L3"、"核心→外围" | 金字塔图 |
-| 数值趋势或周期变化 | 带数字的时间序列、"增长/下降"、百分比变化 | 折线图 / 柱状图 |
-| 漏斗或转化率 | "转化率"、"漏斗"、"从…到…留存" | 漏斗图 |
-| 发散或归纳的思维结构 | "要点"、"维度"、"分支"、多层嵌套列表 | 思维导图 |
-| 循环或飞轮效应 | "正循环"、"飞轮"、"闭环"、"A 驱动 B 驱动 C" | 飞轮图 |
-| 占比分布 | "占比"、"份额"、"分布"、百分比加总 ≈100% | 饼图 / 树状图 |
-
-**判断规则：**
-- 重要信息能图示就图示；不要为了省步骤把关键流程、架构、对比、风险链路写成纯文本
-- 低重要度、局部辅助信息才用 `<table>` / `<grid>` / `<callout>` 承载
-- 确定需要插入哪些图表后，参照 [lark-doc-whiteboard.md](../lark-doc-whiteboard.md) 中的方式，插入图表画板。
-
-## 三、颜色语义
-
-如果使用颜色，建议保持语义一致；不需要颜色时可以保持朴素文本风格：
-
-| 语义 | emoji 前缀 | callout 背景色 | 文字色 |
-|-|-|-|-|
-| 信息、说明 | ℹ️ "说明：" | `light-blue` | `blue` |
-| 成功、推荐 | ✅ "推荐：" | `light-green` | `green` |
-| 警告 / 错误 / 风险 | ⚠️❌ | `light-red` | `red` |
-| 注意、待确认 | ❗"注意：" | `light-yellow` | `yellow` |
-| 中性、辅助 | — | `light-gray` | — |
-
-- 表头可使用 `background-color="light-gray"`，也可以保持默认样式
-- 关键指标如使用 `<span text-color="green/red">` 突出，建议同时用 ↑↓ 或 +/- 标注方向（色觉无障碍）
-
-## 四、排版规范
-
-- 标题层级、段落长度、列表嵌套和 Grid 列数应以可读性为准，避免过深层级和过宽分栏
-- 文档开头可以是结论、背景、摘要、问题陈述、目录或直接正文，不强制使用 `<callout>`
-
-## 五、质量自检
-
-生成内容后可以从以下角度自检，但不要把这些项当作硬性比例或固定模板：
-
-| 指标 | 自检问题 |
-|-|-|
-| 信息表达 | 当前结构是否符合用户目标，而不是套用固定报告模板？ |
-| 阅读负担 | 是否有段落过长、层级过深、表格过宽或组件过多的问题？ |
-| 风格匹配 | 是否延续了用户给定样例或已有文档风格？ |
-| 组件必要性 | callout、grid、table、whiteboard 等是否真的提升理解？ |
-| 保真度 | 改写时是否保留了原文事实、引用、图片、附件和资源块？ |