@amaster.ai/pi-lark 0.1.7 → 0.1.9

package/skills/lark-base/references/lark-base-data-analysis-sop.md

@@ -1,210 +0,0 @@
-# Base data analysis SOP
-
-Base 数据查询与分析任务的执行契约。覆盖记录读取、筛选、排序、Top/Bottom N、聚合统计、分组聚合、多表关联、临时分析和查询后写入前的目标定位。
-
-本文只管查询选路和正确性边界；具体操作前先读真实结构和现状，复杂 JSON 再跳到 reference：
-
-- `+data-query`: entry guide [lark-base-data-query-guide.md](lark-base-data-query-guide.md), full DSL SSOT [lark-base-data-query.md](lark-base-data-query.md)
-- 视图筛选: [lark-base-view-set-filter.md](lark-base-view-set-filter.md)
-- 记录读取: `+record-list` / `+record-search` / `+record-get`，先确认字段 ID、字段名、分页和投影范围
-
-## 0. Hard Rules
-
-- 全局问题不能用默认 `+record-list --limit N` 片面地回答。
-- `jq` / shell / 本地代码是在个人电脑或当前运行环境中处理已返回数据，只适合小范围结果；超过 200 行默认不推荐本地统计、排序或求极值，应改用 Base 云端查询服务的 filter/sort/aggregate。
-- “最高、最低、最新、最早、Top、Bottom、总数、全部、异常、最大、最小、最多、最少、优先级最高”等全局语义，必须在 Base 云端查询服务中完成筛选、排序或聚合。
-- 一次性原始记录查询优先用 `+record-list` / `+record-search` 的 filter/sort；聚合分析优先用 `+data-query`。
-- `+record-search` 用于关键词检索字段的展示文本；金额、状态、日期、空值、关联等结构化条件继续用 `--filter-json` 表达。
-- 不要依赖已有视图，除非用户明确指定该视图，或你已读取并验证其 filter/sort/projection 符合当前问题。
-- 交付输出必须使用用户可读的真实字段值；内部 ID、`record_id`、关联记录 ID、open_id、编码字段只可作为连接键或定位键，不能替代最终输出，除非用户明确要求输出这些键值。
-- 每次读取必须做最小投影，并包含后续解释、回查或写入需要的业务 key。
-
-## 1. Intent -> Tool Path
-
-| 用户意图 | 首选路径 | 关键规则 |
-| --- | --- | --- |
-| 看几条、预览、示例 | `+record-list --limit N --field-id ...` | 保持局部语义；不要推广为全局结论 |
-| 已知 `record_id` | `+record-get` | 直接读取；不要 search/list 反查 |
-| 明确关键词 | `+record-search --keyword ... --search-field ... --field-id ...` | 必须显式指定 `--search-field`；可叠加 `--filter-json` |
-| 按条件找原始记录 | `+record-list --filter-json ...` | `filter-json` 与视图筛选结构一致，支持文本、数字、日期、选项、人员、群组、关联等值 |
-| 排序 / TopN 原始记录 | `+record-list --filter-json ... --sort-json ... --limit N` | 最高/最新用 `desc:true`，最低/最早用 `desc:false`；数组顺序表达优先级；最多 10 个排序条件 |
-| 聚合 / 分组 / 分组排序 | `+data-query` | 使用 filters/dimensions/measures/sort/limit |
-| 聚合后输出逐条记录 | `+data-query` 得到业务 key 或候选字段组合 -> `+record-list --filter-json` / `+record-get` 回查 | `+data-query` 维度行按字段组合去重且不返回 `record_id` |
-| 多表 / 多跳关联 | 以候选数最小的事实表为驱动表，沿业务 key 或 link `record_id` 逐跳回查 | 读出 link 单元格里的关联 `record_id` 后，到被关联表批量 `+record-get` 展示字段 |
-| 查询后写入 / 视图化 | 先用本 SOP 得到可复核的目标记录 id 集合 | 再进入记录写入或视图配置；高价值可复用查询可沉淀为持久视图 |
-
-## 2. Execution Patterns
-
-### 2.1 结构化原始记录与 TopN
-
-使用 `+record-list` 的 filter/sort 路径：
-
-1. `+field-list` 确认筛选字段、排序字段、展示字段、业务 key。
-2. 筛选只用 `--filter-json` 或 `--filter-json @file`。
-3. 排序用 `--sort-json`。
-4. `--field-id` 做最小投影，`--limit` 控制返回数量。
-
-Example: string/number 条件 + TopN：
-
-```bash
-lark-cli base +record-list \
-  --base-token <base_token> \
-  --table-id <table_id> \
-  --filter-json '{"logic":"and","conditions":[["Title","==","Launch plan"],["Score",">=",80]]}' \
-  --sort-json '[{"field":"Updated","desc":true}]' \
-  --field-id Name \
-  --field-id Title \
-  --field-id Score \
-  --limit 20
-```
-
-Example: 复杂筛选从文件读取：
-
-```bash
-lark-cli base +record-list \
-  --base-token <base_token> \
-  --table-id <table_id> \
-  --filter-json @filter.json \
-  --sort-json '[{"field":"Priority","desc":true}]' \
-  --field-id Name \
-  --field-id Tags \
-  --limit 50
-```
-
-`filter-json` 与视图筛选结构一致。下面只列常用 fewshot；字段类型、operator、value 形状拿不准，或需要人员、群组、关联、空值、地理位置、formula / lookup 等完整筛选时，先读 [lark-base-view-set-filter.md](lark-base-view-set-filter.md)，再把同样的 filter JSON 传给 `--filter-json`。
-
-文本 `==`：字段值等于目标文本。
-```json
-{"logic":"and","conditions":[["Title","==","Launch plan"]]}
-```
-
-文本包含 / like：文本字段包含目标片段；operator 写 `intersects`。
-```json
-{"logic":"and","conditions":[["Title","intersects","urgent"]]}
-```
-
-数字 `==`：字段值等于目标数字。
-```json
-{"logic":"and","conditions":[["Score","==",95]]}
-```
-
-日期 `==`：字段值等于目标日期；datetime / created_at / updated_at 用 `ExactDate(...)`。
-```json
-{"logic":"and","conditions":[["Due Date","==","ExactDate(2026-06-02)"]]}
-```
-
-选项 `==`：字段值匹配单个选项；选项值使用选项名数组，单个选项也写数组。
-```json
-{"logic":"and","conditions":[["Priority","==",["P0"]]]}
-```
-
-选项 `intersects`：字段值与给定选项集合有交集，常用于多选或“命中任一选项”。
-```json
-{"logic":"and","conditions":[["Tags","intersects",["P0","Blocked"]]]}
-```
-
-`--sort-json` 传排序数组，数组顺序就是优先级，`desc:true` 为降序，`desc:false` 为升序，最多 10 个排序条件。
-
-### 2.2 关键词检索后叠加结构化条件
-
-使用 `+record-search` 做关键词命中，结构化条件仍用 `--filter-json` 下推：
-
-```bash
-lark-cli base +record-search \
-  --base-token <base_token> \
-  --table-id <table_id> \
-  --keyword Alice \
-  --search-field Name \
-  --filter-json '{"logic":"and","conditions":[["Status","!=","Done"]]}' \
-  --sort-json '[{"field":"Updated","desc":true}]' \
-  --field-id Name \
-  --field-id Status \
-  --limit 20
-```
-
-不要把 `+record-search` 当成金额、状态、日期、空值、关联字段的结构化筛选入口；这些条件继续写成 `--filter-json`。
-
-### 2.3 聚合分析与 TopN
-
-使用 `+data-query`：
-
-- 让 Base 云端查询服务完成 filters、dimensions、measures、sort、pagination.limit。
-- `pagination.limit` 是 Base 云端查询服务中的结果限制，不是本地分页扫描。
-- 常用聚合 fewshot 先读 [lark-base-data-query-guide.md](lark-base-data-query-guide.md)；字段类型、日期 value、DSL shape 以 [lark-base-data-query.md](lark-base-data-query.md) 为准。
-- `+data-query` 可返回聚合结果或维度字段行；维度字段行按字段组合去重且不返回 `record_id`，不能当逐条原始记录结果使用。
-- 需要输出逐条记录、记录定位或完整行级字段时，先用 `+data-query` 得到业务 key、分组值或候选字段组合，再用 `+record-list --filter-json` / `+record-get` 回查。
-
-Example: 分组计数：
-
-```bash
-lark-cli base +data-query \
-  --base-token <base_token> \
-  --dsl '{"datasource":{"type":"table","table":{"tableId":"<table_id>"}},"dimensions":[{"field_name":"Status","alias":"status"}],"measures":[{"field_name":"Status","aggregation":"count","alias":"count"}],"shaper":{"format":"flat"}}'
-```
-
-Example: 过滤后汇总并取 TopN：
-
-```bash
-lark-cli base +data-query \
-  --base-token <base_token> \
-  --dsl '{"datasource":{"type":"table","table":{"tableId":"<table_id>"}},"dimensions":[{"field_name":"Owner","alias":"owner"}],"measures":[{"field_name":"Amount","aggregation":"sum","alias":"total_amount"}],"filters":{"type":1,"conjunction":"and","conditions":[{"field_name":"Status","operator":"is","value":["Done"]}]},"sort":[{"field_name":"total_amount","order":"desc"}],"pagination":{"limit":10},"shaper":{"format":"flat"}}'
-```
-
-### 2.4 视图化与复用
-
-一次性查询先用 `+record-list` / `+record-search` 的 filter/sort 验证。需要用户长期打开、共享或复用时，再把同一套 filter/sort 沉淀为视图。
-
-Example: 将已验证的筛选排序写入视图：
-
-```bash
-lark-cli base +view-set-filter \
-  --base-token <base_token> \
-  --table-id <table_id> \
-  --view-id <view_id> \
-  --json @filter.json
-
-lark-cli base +view-set-sort \
-  --base-token <base_token> \
-  --table-id <table_id> \
-  --view-id <view_id> \
-  --json '{"sort_config":[{"field":"Priority","desc":true}]}'
-```
-
-手动配置和视图配置的优先级：
-
-1. `--filter-json` 覆盖 `--view-id` 保存的 view filter JSON。
-2. `--sort-json` 覆盖 `--view-id` 保存的 view sort config。
-3. 没有手动 filter/sort 时，`--view-id` 使用视图自身保存的 filter/sort。
-
-### 2.5 关系查询与回查
-
-- link 单元格通常是关联表 `record_id` 数组，不是用户可读内容，只是连接键。
-- 先用 `+field-list` 确认 link 字段的 `link_table`、业务唯一键和展示字段。
-- 从驱动表拿到候选记录后，用关联 `record_id` 到关联表 `+record-get` 批量读取记录内容。
-- 多跳关系逐跳建立 `record_id/key -> 用户可读字段` 映射；最终用户可读的信息。
-
-禁止：
-
-- 把 link `record_id` 当最终输出。
-- 用 `+record-search` 搜 link `record_id`。
-- 基于 ID、自增编号、link 值做语义猜测；禁止依赖字段先验、样本记忆补全交付输出。
-
-## 3. Range & Pagination Contract
-
-- `+record-list` 默认页、固定 `--limit`、本地 `jq`、shell 管道、手工浏览输出，都只覆盖已读取范围；超过 200 行不要把本地处理当作推荐路径。
-- `has_more=true`、存在下一页 offset/page token、或返回行数等于 page size，都表示可能还有未读取数据。
-- 对全局问题，只有 Base 云端查询服务已经通过 filter/sort/aggregate 收敛目标范围，或 `+data-query` 已在云端完成聚合、排序和限制时，才可以用有限返回形成结论。
-- 必须全量导出时，按 `+record-list` 分页语义串行翻页；不要并发调用 `+record-list`。
-
-## 4. Final Answer Check
-
-形成交付输出前必须能确认：
-
-- 问题范围是局部样例、单点定位、全局原始记录、聚合分析、多表关联，还是查询后写入。
-- 筛选、排序、聚合是否发生在 Base 云端查询服务中，而不是本地 `jq` / shell 中。
-- 如果使用 `jq` / shell，本地输入是否是 200 行以内的小范围结果；超过 200 行是否已改用 Base 云端查询服务查询。
-- 如果使用 `+record-list` / `+record-search`，是否处理了 `has_more`，且投影包含业务 key 和解释字段。
-- 如果涉及关系查询，是否按 `record_id` 或业务 key 精确回查，交付输出是否来自关联表真实字段。
-- 交付输出能追溯到表、字段、筛选条件、排序/聚合条件和连接键。
-
-任一项无法确认时，继续查询或明确说明只能得到局部结论。

package/skills/lark-base/references/lark-base-data-query-guide.md

@@ -1,61 +0,0 @@
-# Base data-query guide
-
-This guide is the entry point for `+data-query`. Use it for common aggregation fewshots and command selection. For the complete DSL fields, operators, limits, and response details, use [lark-base-data-query.md](lark-base-data-query.md) as the DSL SSOT.
-
-Before using `+data-query`, also follow [lark-base-data-analysis-sop.md](lark-base-data-analysis-sop.md) to confirm that the task really needs aggregation instead of record listing or a temporary view.
-
-## When to use
-
-Use `+data-query` when the user asks for server-side:
-
-- group by / aggregation
-- sum, average, min, max, count, distinct count
-- filtered aggregation
-- sorted Top N or Bottom N
-- global statistical conclusions
-
-`+data-query` can return dimension field rows, but those rows are grouped by dimension values and do not include `record_id`. Use `+record-list`, `+record-search`, or `+record-get` for row-level output, record identity, or full raw record details.
-
-## Common Fewshots
-
-Count records by a category field:
-
-```bash
-lark-cli base +data-query \
-  --base-token <base_token> \
-  --dsl '{"datasource":{"type":"table","table":{"tableId":"<table_id>"}},"dimensions":[{"field_name":"Status","alias":"status"}],"measures":[{"field_name":"Status","aggregation":"count","alias":"count"}],"shaper":{"format":"flat"}}'
-```
-
-Sum a number field by category and return Top 10:
-
-```bash
-lark-cli base +data-query \
-  --base-token <base_token> \
-  --dsl '{"datasource":{"type":"table","table":{"tableId":"<table_id>"}},"dimensions":[{"field_name":"Region","alias":"region"}],"measures":[{"field_name":"Amount","aggregation":"sum","alias":"total_amount"}],"sort":[{"field_name":"total_amount","order":"desc"}],"pagination":{"limit":10},"shaper":{"format":"flat"}}'
-```
-
-Aggregate only records matching a filter:
-
-```bash
-lark-cli base +data-query \
-  --base-token <base_token> \
-  --dsl '{"datasource":{"type":"table","table":{"tableId":"<table_id>"}},"dimensions":[{"field_name":"Owner","alias":"owner"}],"measures":[{"field_name":"Amount","aggregation":"sum","alias":"total_amount"}],"filters":{"type":1,"conjunction":"and","conditions":[{"field_name":"Status","operator":"is","value":["Done"]}]},"shaper":{"format":"flat"}}'
-```
-
-Use `tableName` when the table ID is unavailable but the table name is known:
-
-```bash
-lark-cli base +data-query \
-  --base-token <base_token> \
-  --dsl '{"datasource":{"type":"table","table":{"tableName":"Orders"}},"measures":[{"field_name":"Amount","aggregation":"sum","alias":"total_amount"}],"shaper":{"format":"flat"}}'
-```
-
-## Routing to the DSL SSOT
-
-Read [lark-base-data-query.md](lark-base-data-query.md) when you need:
-
-- the full DSL field reference
-- supported aggregations and field types
-- filter operator details
-- pagination and result limits
-- response shape and error recovery

package/skills/lark-base/references/lark-base-record-upsert.md

@@ -1,63 +0,0 @@
-# base +record-upsert
-
-> **前置条件：** 先阅读 [`../lark-shared/SKILL.md`](../../lark-shared/SKILL.md) 了解认证、全局参数和安全规则。
-
-创建记录，或在带 `--record-id` 时更新记录。
-
-## 推荐命令
-
-```bash
-# 创建记录
-lark-cli base +record-upsert --base-token <base_token> --table-id <table_id> \
-  --json '{"项目名称":"Apollo","状态":"进行中"}'
-
-# 更新记录
-lark-cli base +record-upsert --base-token <base_token> --table-id <table_id> --record-id <record_id> \
-  --json '{"项目名称":"Apollo","状态":"完成","完成时间":"2026-03-24 10:00:00"}'
-```
-
-## 参数
-
-| 参数 | 必填 | 说明 |
-|------|------|------|
-| `--base-token <token>` | 是 | Base Token |
-| `--table-id <id_or_name>` | 是 | 表 ID 或表名 |
-| `--record-id <id>` | 否 | 传入时走更新，不传时走创建 |
-| `--json <body>` | 是 | 字段写入对象，类型 `Map<FieldNameOrID, CellValue>` |
-
-## API
-
-- 创建：`POST /open-apis/base/v3/bases/:base_token/tables/:table_id/records`
-- 更新：带 `--record-id` 时改走 `PATCH /records/:record_id`
-
-## `--json` 结构
-
-- `--json` 必须是 **JSON object map**，形状是 `Map<FieldNameOrID, CellValue>`。
-- key 是字段名或字段 ID；value 是该字段的 `CellValue`。
-- 一次请求里同一字段只用一种标识，避免重复写入冲突。
-- 写入前先 `+field-list` 确认字段类型和字段名/ID。
-- CellValue 统一看 [lark-base-cell-value.md](lark-base-cell-value.md)。
-
-```json
-{
-  "项目名称": "Apollo",
-  "状态": "进行中",
-  "完成时间": "2026-03-24 10:00:00"
-}
-```
-
-## 返回重点
-
-- 创建时返回 `record` 和 `created: true`。
-- 更新时返回 `record` 和 `updated: true`。
-- 如果写入了 `formula / lookup / created_at / updated_at / created_by / updated_by` 等只读字段，返回里可能出现 `ignored_fields`，这些字段不会被更新。
-
-## 坑点
-
-- 有 `--record-id` 就一定更新；不传就一定创建，不会自动查重或按业务键 upsert。
-- `select` 字段只支持写入字段中已有的选项；构造 CellValue 前先用 `+field-list` 或 `+field-search-options` 确认目标选项存在。
-- 这是写入操作，执行前必须确认目标表和字段。
-
-## 参考
-
-- [lark-base-cell-value.md](lark-base-cell-value.md) — CellValue 格式规范

package/skills/lark-doc/references/lark-doc-word-stat.md

@@ -1,93 +0,0 @@
-# 文档统计：总字数 / 总字符数
-
-当用户需要统计 Docx / Wiki 文档的总字数或总字符数时，使用本 skill 附带脚本 `scripts/doc_word_stat.py`。统计口径以该脚本为准，不要改用其他方式自行计算，也不要只读取 simple 摘要后统计。
-
-## 调用方式
-
-在线文档使用 XML full 内容，并让脚本读取 `docs +fetch --format json` 的 envelope：
-
-```bash
-lark-cli docs +fetch --doc "$URL" --doc-format xml --detail full --format json \
-  | python3 skills/lark-doc/scripts/doc_word_stat.py --protocol xml --lark-json --pretty
-```
-
-`$URL` 可以是用户给出的 docx/wiki URL，也可以是可被 `docs +fetch` 解析的 token。
-
-## 统计范围
-
-先判断用户要求的是**整篇文档**还是**局部内容**：
-
-- 整篇文档的总字数 / 总字符数：按上方「调用方式」抓取 `full` 内容后统计。
-- 本次新增 / 替换 / 改写片段的字数：优先统计拟写内容本身；内容已写入文档时，只 fetch 对应 block / range 后统计。不得用整篇文档字数对比局部目标。
-
-如需在自动化或回归验证中发现未覆盖块类型，追加严格参数：
-
-```bash
-lark-cli docs +fetch --doc "$URL" --doc-format xml --detail full --format json \
-  | python3 skills/lark-doc/scripts/doc_word_stat.py --protocol xml --lark-json --pretty --fail-on-unsupported --fail-on-unknown
-```
-
-## 如何读取结果
-
-脚本输出 JSON。对用户汇报时默认只读两个核心字段：
-
-- `word_count`：总字数。按语义单位统计汉字、英文单词/URL/code path、数字、中文标点；普通贴着英文的英文标点不计入，但独立 ASCII 符号、中文之间的 `/` 等以脚本结果为准。
-- `char_count`：总字符数。统计汉字、英文字母、数字、中英文标点和脚本识别的可见符号；空格不计入。
-
-其余字段用于排查或解释：
-
-- `breakdown`：拆分统计来源，例如 `han_chars`、`english_words`、`digits`、`chinese_punctuations`。
-- `unknown_blocks`：脚本遇到未知 XML/Markdown 块类型；通常表示需要扩展解析规则。
-- `unsupported_blocks`：脚本识别到块类型，但当前无法可靠提取可见文本。
-- `diagnostics.has_unknown` / `diagnostics.has_unsupported`：快速判断统计是否存在覆盖风险。
-
-如果 `unknown_blocks` 或 `unsupported_blocks` 非空，回复用户时要说明“已统计可提取文本，但存在未覆盖块，结果可能偏低”，并列出对应块类型。为空时可直接给出结果。
-
-## 字数遵循校验
-
-当用户给了明确字数要求（写 N 字 / x-y 字 / x 字左右 / 上下浮动）时执行；没有明确字数要求则跳过。字数必须按本文流程用脚本统计，不要自己估。
-
-1. 先按「统计范围」确认统计对象，再把要求归一成目标区间：`>x`→`[x+1, +∞)`；`<y`→`(-∞, y-1]`；`x-y`→`[x, y]`；`x 字左右`→`[round(0.9x), round(1.1x)]`
-2. 按统计对象选择对应输入并调用脚本统计实际字数，读取输出里的 `word_count`
-3. 对比 `word_count` 与目标区间：区间内即通过；低于下限 → 补充**实质内容**（非注水）；高于上限 → 删减冗余内容。改完重新统计
-4. **最多 2 轮**。2 轮后仍不达标：停止，不得为达标而注水或删关键内容；如实汇报【目标区间 / 当前字数 / 差值与方向 / 已试 2 轮 / 未达原因】，**禁止谎称达标**
-
-## 输出示例
-
-输入正文等价于：`标题` + `一个苹果是 an apple。` 时，输出形态如下：
-
-```json
-{
-  "word_count": 10,
-  "char_count": 15,
-  "breakdown": {
-    "han_chars": 7,
-    "english_words": 2,
-    "number_words": 0,
-    "chinese_punctuations": 1,
-    "english_letters": 7,
-    "digits": 0,
-    "english_punctuations": 0,
-    "symbol_words": 0,
-    "symbol_chars": 0
-  },
-  "protocol": "xml",
-  "unknown_blocks": [],
-  "unsupported_blocks": [],
-  "diagnostics": {
-    "has_unknown": false,
-    "has_unsupported": false,
-    "types": {},
-    "unknown_types": {},
-    "unsupported_types": {},
-    "actions": {}
-  }
-}
-```
-
-面向用户的回复可简化为：
-
-```text
-总字数：10
-总字符数：15
-```

package/skills/lark-doc/references/style/lark-doc-create-workflow.md

@@ -1,47 +0,0 @@
-# 从零创作工作流
-
-用户提供主题、需求或简要说明，需要生成一份新的飞书文档时，遵循本工作流。
-
-## 核心方法论 — Code-Act Loop
-
-通过自适应的 **Code-Act Loop** 驱动文档创作，而非固定模板式的工作流。每次任务都循环执行：
-
-1. **Plan（规划）** — 根据用户目标和文档当前状态，评估下一步该做什么
-2. **Execute（执行）** — 由主 Agent 自己运行 `lark-cli docs` 命令推进正文；仅画板渲染按需隔离到 SubAgent（见步骤三）
-3. **Observe（观察）** — 检查命令输出，验证正确性，确认内容是否满足用户目标
-4. **Iterate（迭代）** — 如需调整，回到 Plan 继续循环
-
-循环在文档达到质量标准且满足用户需求时结束。不要试图一次性产出完美内容——迭代打磨效果更好。根据用户实际需求灵活决定文档结构和版块，而不是套用固定模板。
-
-
-## 典型 Code-Act Loop 流程
-
-### 步骤一：规划与撰写（单 Agent 串行）
-
-正文由主 Agent 串行维护，**不按章节拆给并行 Agent**，避免上下文割裂、重复矛盾和全文级约束失效。
-
-1. 分析用户需求：受众、目的、范围
-2. 设计大纲：根据任务自然选择结构。可以是短文、纪要、FAQ、方案、报告、清单或其他形式；不要默认套固定章节、固定开头或固定富 block 配比
-3. `docs +create` 创建并撰写：
-   - **短文档**：一次写入完整内容。使用 Markdown 时，避免同时传入 `--title` 和同名 `# 标题`
-   - **长文档**：先建骨架（标题 + 各级标题），再由主 Agent **顺序逐节**用 `block_insert_after --block-id <章节标题 block_id>` 补全正文；写完一节再写下一节，始终带着已写内容的上下文，保证衔接、不重复
-   - ⚠️ 不要一次性把超长完整内容塞进 `--content`，容易触发字符/参数限制；长文按节分次写入
-   - ⚠️ 同一节内多次插入时，要锚到**上一个新插入的 block**（按 [`lark-doc-update.md`](../lark-doc-update.md) 的「Block ID 生命周期」），否则反复锚同一个标题会让段落顺序颠倒
-   - ⚠️ 若先建骨架写了占位摘要，补正文时**删除占位摘要**，不要留残渣
-   - ⚠️ **`@file` 路径限制**：`--content @file` 只接受当前工作目录下的相对路径，传绝对路径（如 `@/tmp/xxx.md`）会报 `unsafe file path`。需要落盘时，将文件写在 cwd 下，用完自行清理
-
-### 步骤二：整合审查与画板识别（串行）
-
-4. `docs +fetch --api-version v2 --detail with-ids` 获取文档，审查整体效果
-5. 评估内容是否满足用户目标：事实是否完整、结构是否清楚、语气是否匹配、是否保留必要素材；检查跨节有无重复、矛盾或断流。再按 `lark-doc-style.md` 的「写完自检」快速核对，发现问题就地定向修正
-6. **画板识别**：逐章节扫描，判断是否有段落用图明显比文字更易懂（流程 / 架构 / 时间线 / 对比 / 占比等，见 `lark-doc-style.md` 的画板原则）。默认用文字，只有确需图示才记录需要插图的章节、推荐画板类型、mermaid/SVG 路径和用于画图的源内容
-
-### 步骤三：画板处理与润色
-
-7. **优先处理步骤二识别出的画板需求**：读取并按 [lark-doc-whiteboard.md](../lark-doc-whiteboard.md) 选型和插入；正文本身不交给 SubAgent
-8. 由**主 Agent 自行润色**（不另起内容子 Agent，正文始终一人维护）：文字密集且不易读时，优先拆段、加小标题或调整顺序——叙述内容保持成段，**不要默认改成列表**，只有确属并列要点 / 步骤才用列表（见 `lark-doc-style.md`）；只有确实存在行列数据时才用 `<table>`。其余富 block 的取舍一律遵循 `lark-doc-style.md` 的写作原则，不主动堆叠。需要明显分隔的主题可补充 `<hr/>`，不强制章节间都使用。本地图片使用 `docs +media-insert` 插入
-
-### 步骤四：专项校验
-
-9. **字数门禁**：如果用户给出任何明确字数要求（如“700-800 字”“1000 字左右”“不少于 500 字”“控制在 800 字以内”），本步骤必须执行，不属于按需项。读取并执行 [`lark-doc-word-stat.md`](../lark-doc-word-stat.md) 的「字数遵循校验」；未得到脚本统计结果前，不得向用户声明“符合字数要求”。若没有明确字数要求，则跳过本项，不读取该 workflow。若执行了专项校验，向用户呈现目标区间、`word_count` 和达标结论
-10. **重复标题检查**：文档生成后，检查文档标题和正文第一个标题块是否重复；若重复，删除或改写正文第一个标题块，避免读者看到同一标题连续出现

package/skills/lark-doc/references/style/lark-doc-style.md

@@ -1,68 +0,0 @@
-# 飞书文档写作原则
-
-写飞书文档，像一个该领域资深的人类作者那样写，而不是把内容"装配"成组件。
-本文只讲"何时用、什么风格"；具体标签 / 命令语法见 [`lark-doc-xml.md`](../lark-doc-xml.md)。
-
-## 一、用户明确要求优先
-
-用户点名要某种格式——高亮块、分栏、列表、某编号体例、表格、画板、某模板、某已有文档的风格——**一律照用户的来，下面的"默认克制"全部让位**。用户给了样例或已有文档，就沿用它的结构与语气。
-
-## 二、默认写连贯段落
-
-用户没指定时，**默认是连贯段落**；其余按内容类型分流，别一律"少用结构"，也别什么都升标题：
-
-| 内容 | 用什么 | ❌ 别 |
-|---|---|---|
-| 叙述、论证、分析、说明 | **连贯段落** | 拆成列举 |
-| 真·行列数据（预算、指标、对比、排期、字段说明） | **表格** | 写成段落或把字段堆成一行 |
-| 字段:值（主题、时长、负责人等，少量） | **加粗标签行**或一句话 | 每字段一个标题 |
-| 方法 / 措施 + 每项一段描述 | **加粗引导句段落**（「**全程督导。**…」） | 每项升标题 |
-| 任务清单 / 检查项 / 待办事项 | **`<checkbox>`** | 用普通列表替代可交互待办 |
-| 纯短并列项（无描述，如材料清单） | 列表 | — |
-| 章节（内容成块、需在目录导航） | 标题层级 | — |
-
-- 判断标准：**去掉结构后能顺成段落，就用段落；成行成列的数据，就用表格。**
-- **红线一：标题层级只给"章节"。** "小标题 + 一两句话"的小项（字段、方法、要点）不该占标题层级——按上表降成标签行 / 加粗引导句段落（否则目录里全是没信息量的条目）。
-- **红线二：列举（「一是 / 二是」「第一 / 第二」「(1)(2)(3)」）只给真正并列的具体项，且别每节都用。**
-  - 「一是 / 二是」是党务列举的措辞——只用在列具体的**问题 / 措施**那一处；背景、现状、认识、分析、过渡、总结**一律成段**。
-  - **整篇每段 / 每节都"一是 / 二是"，和"每段一个 bullet"是同一个骨架化的错——不因为是党务就变对**（纯清单 / 台账类除外）。
-
-## 三、按体裁写
-
-- **公文 / 法律 / 学术 / 申报 / 项目方案等严肃正式提交物**：靠规范的标题层级、段落与编号体系表达；**默认不用高亮块、分栏**，要强调用加粗或规范小标题。
-- **面向公众号、微信等外部平台粘贴 / 发布的内容**：不用飞书特有富 block（高亮块、分栏等），粘出去会丢样式 / 错乱；改用标准标题、段落、列表、引用。
-- **一般文档**：以可读为先，不堆砌结构。
-
-## 四、编号与层级
-
-- **一套编号体例、全篇一致；最忌中文大层级与阿拉伯小数编号混用。**
-  - 公文 / 正式材料常用：「一、→（一）→ 1.→（1）」（中文大层级 + 阿拉伯细分层级）。
-  - 学术 / 技术 / 商业报告：「1 → 1.1 → 1.1.1」或「一、→（一）→ 1.」，**择一**。
-  - ⚠️ **「一、」只能配「（一）」；要用阿拉伯小数就从顶层全用「1 / 1.1」。绝不「一、」配「1.1 / 2.1」**——这是最常见的混用。
-  - **不混用**多套（别"第X部分"+"一、"+"1."混着来）；**同级不跳号**；**不跳级**。
-- **编号 / 标题层级只给"章节"**，不要为了凑齐体例把每个小项都编上「（一）」、升成标题（小项处理方式见上文「二、默认写连贯段落」）。
-- 简单的 1.2.3 并列项用原生 `<ol><li seq="auto">…</li></ol>` 让飞书自动编号、自动对齐；「一、(一)」原生产不出，才手打成文字——此时用标题级别表达层次，**不靠手动缩进**、各级顶格（全角括号「（）」叠手动缩进会视觉错位）。
-
-## 五、飞书特有组件，克制使用
-
-- **高亮块 `<callout>`**：很重的强提醒信号，**默认不用**；只给"不提醒就会出错 / 遗漏"的关键项，全文极少（0~1 个），不要每节导语 / 结论都做成高亮块。
-- **分栏 `<grid>`**：仅左右信息量相当、确需并排对照的短内容；否则用段落或表格。
-- **画板**：默认用文字，只在**图示明显比文字更易懂**（流程、架构、时间线、对比、占比等）或用户要求时才用。怎么插、用哪种类型见 [`lark-doc-xml.md`](../lark-doc-xml.md) 与 [`lark-doc-whiteboard.md`](../lark-doc-whiteboard.md)。
-- **颜色**：默认朴素、不上色；需要时保持语义一致，按下表选择对应颜色，不为装饰上色。可用色见 [`lark-doc-xml.md`](../lark-doc-xml.md) 的「美化系统」。
-
-| 语义 | 背景色 | 文字色 |
-|-|-|-|
-| 信息、说明 | `light-blue` | `blue` |
-| 成功、推荐 | `light-green` | `green` |
-| 警告 / 错误 / 风险 | `light-red` | `red` |
-| 注意、待确认 | `light-yellow` | `yellow` |
-| 中性、辅助 | `light-gray` | — |
-
-## 六、写完自检
-
-交付前快速回看：
-- **叙述是否被列举化**：背景 / 现状 / 认识 / 分析 / 成效 / 过渡 / 总结等应成段；列举只用于同层级、可并列处理的信息，如问题、措施、步骤、任务或材料清单。若正文反复使用连续编号、项目符号或固定并列句式，导致内容缺少叙述，应把背景 / 认识 / 分析 / 过渡改写成有承接关系的段落（纯清单 / 台账类除外）。
-- **数据是否正确呈现**：成行成列的数据应使用表格呈现，不要写成段落，也不要用分隔符把多个字段硬串在一起。
-- **标题是否滥用**："小标题 + 一句话"的小项不要升成标题；应改成标签行、加粗引导句段落或普通段落。
-- **编号是否统一**：全篇一套、不跳号、不跳级，尤其不要中文 + 阿拉伯混用（如「一、」配「1.1」）。
-- **组件是否克制且保真**：高亮块 / 分栏 / 画板 / 颜色应符合体裁和用户要求；引用 / 图片 / 资源块必须保留。

package/skills/lark-doc/references/style/lark-doc-update-workflow.md

@@ -1,48 +0,0 @@
-# 改写增强工作流
-
-用户提供已有文档链接或 token，需要改写、润色、补充或重排版时，遵循本工作流。
-
-## 核心方法论 — Code-Act Loop
-通过自适应的 **Code-Act Loop** 驱动文档改写，而非固定模板式的工作流。每次任务都循环执行：
-1. **Plan（规划）** — 根据用户目标和文档当前状态，评估下一步该做什么
-2. **Execute（执行）** — 由主 Agent 自己运行 `lark-cli docs` 命令推进改写；仅画板渲染按需隔离到 SubAgent（见步骤二）
-3. **Observe（观察）** — 检查命令输出，验证正确性，确认内容是否满足用户目标
-4. **Iterate（迭代）** — 如需调整，回到 Plan 继续循环
-
-## 核心原则：精准手术优于全量覆盖
-1. **精准手术**：只改用户指定的 block，不改其他 block。
-2. **全量覆盖**：如果用户明确要改整篇，才用 `overwrite` 命令。
-3. **保真约束**：改写时原文里的 `<cite type="user">`（@人）、`<cite type="doc">`（@文档）、`<img>`、`<source>`、`<whiteboard>`、`<sheet>`、`<bitable>`、`<synced_reference>` 等行内组件和资源块一律原样保留（含所有 token / user-id / doc-id 属性），不许替换成纯文本姓名、链接或占位符。
-
-## 工作流程
-
-### 步骤一：分析与画板识别（串行）
-
-1. **选择读取范围**（节省上下文的关键）：
-   - 用户只改某一节 / 文档较大 → 先 `docs +fetch --scope outline --max-depth 2` 拿目录，再 `docs +fetch --scope section --start-block-id <目标标题id> --detail with-ids` 精读该节（`section` 会自动展开到下一个同级/更高级标题前，不用手动算结束 block id）
-   - 需要精确跨节区间 → `docs +fetch --scope range --start-block-id xxx --end-block-id yyy`（或 `--end-block-id -1` 读到末尾）
-   - 用户只给了模糊关键词 → `docs +fetch --scope keyword --keyword xxx --context-before 1 --context-after 1 --detail with-ids`
-   - 用户明确要改整篇 → `docs +fetch --detail with-ids`
-   - 详见 [`lark-doc-fetch.md`](../lark-doc-fetch.md) 中「选 `--scope`（读取范围）」小节
-2. 系统性评估：用户想改什么、现有文档风格是什么、哪些内容需要保留、哪些问题影响理解
-3. **画板识别**：逐章节扫描，判断是否有段落用图明显比文字更易懂（流程 / 架构 / 时间线 / 对比 / 占比等，见 `lark-doc-style.md` 的画板原则）。默认用文字，只有确需图示才记录需要插图的章节（block ID）、推荐画板类型、mermaid/SVG路径和源内容片段
-4. 向用户简要说明改进计划（包含识别出的画板机会）
-
-### 步骤二：定向改写（单 Agent 串行）
-
-5. **优先处理步骤一识别出的画板候选段落**：读取并按 [lark-doc-whiteboard.md](../lark-doc-whiteboard.md) 选型和插入；正文本身不交给 SubAgent
-6. 由主 Agent **顺序逐节**改写，**不按章节拆给并行 Agent**，避免上下文割裂、重复矛盾和全文级约束失效：
-   - 沿用或轻微调整已有文档风格，除非用户要求彻底重排版
-   - 优先通过重写段落、调整标题、补充小标题提升可读性；叙述内容保持成段，**不要默认改成列表**，只有确属并列要点 / 步骤才用列表（见 `lark-doc-style.md`）
-   - 富 block 是可选表达手段，不因固定比例而添加，取舍遵循 `lark-doc-style.md` 的写作原则；画板类需求只走第 5 步
-
-### 步骤三：验证（串行）
-
-7. 获取更新后文档局部内容，检查是否符合用户目标和已有风格
-8. 检查是否满足用户目标并保留原有关键内容。再按 `lark-doc-style.md` 的「写完自检」快速核对，发现问题则定向修正
-
-### 步骤四：专项校验（按需执行）
-
-9. 仅当用户预期需要校验字数时，才读取并执行 [`lark-doc-word-stat.md`](../lark-doc-word-stat.md) 的「字数遵循校验」；否则跳过本项，不读取该 workflow。若执行了专项校验，向用户呈现结果
-
-**上下文节省提示**：主 Agent 改某节时如需重新读取，优先用 `docs +fetch --scope section --start-block-id <章节标题id>`（自动覆盖整节），或 `--scope range --start-block-id xxx --end-block-id yyy` 精确区间，只拉当前章节，不要重复拉全文。