@amaster.ai/pi-lark 0.1.2-beta.52 → 0.1.2-beta.54

package/skills/lark-doc/references/genres/route-personal-brand.md

@@ -0,0 +1,36 @@
+# Genre Contract: Personal Brand / 个人品牌 (`router.personal_brand`)
+
+## 体裁规则表（硬约束）
+
+| 规则项 | 规则 |
+|-|-|
+| 写作风格 | 可信、具体、有辨识度，声音服从目标读者和真实经历，不用自我评价替代成果证据 |
+| 内容逻辑 | 从目标读者和目标机会出发，用“身份 / 价值定位 → 相关经历 → 可验证贡献 → 做事方式 → 下一步意图”组织；每项经历说明情境、本人动作、结果及与目标的关系 |
+| 事实 / 边界 | 职位、时间、职责、学历、技能、作品和指标须真实可核，个人贡献与团队成果分开；尊重保密、个人信息、雇主和作品权利，作品、图片和推荐语须确认归属、使用权限与必要语境，非文字证据须有文字等价信息；关键身份、时间、归属或公开权限缺失时用具体占位，无法安全表述则 blocked |
+| 错误 | 夸大头衔 / 技能 / 指标、把团队成果全归个人、关键词堆砌、伪造推荐语或客户、泄露敏感信息、作品无归属 / 权限、同一经历前后矛盾、渠道语气改变事实，任一出现即失败 |
+
+## 适用与消歧
+
+用于让招聘方、合作方、客户或专业社群判断“这个人是谁、做过什么、能带来什么”。仅出现平台名称不触发；明确要求最终交付 Email、小红书笔记或微信公众号文章时走 `route_platform`，再选择对应 leaf，个人身份、经历和信誉目标作为该 leaf contract 的硬约束，不再并读 Personal Brand。
+
+以项目经验得失来改进下一轮走 Retrospective；以购买体验帮助他人选择走 Consumer；以组织身份转化客户走 Marketing。出现“介绍、主页、复盘”不能单独触发，须确认目标是个人能力和信誉呈现。
+
+## 子类型
+
+| 子类型 | 读者任务与推进 |
+|-|-|
+| 简历 / CV | 快速判断岗位匹配；摘要 → 相关经历与成果 → 技能 / 教育 → 必要补充 |
+| 求职信 / 自我介绍 / 简介 | 理解动机与差异化价值；目标 → 相关证据 → 工作方式 → 明确下一步 |
+| 个人主页 | 建立清晰定位并找到入口；一句定位 → 代表证据 → 领域 / 服务 → 联系或作品 |
+| 作品集 / 案例集 | 判断能力如何形成结果；问题 → 约束与本人角色 → 过程决策 → 结果与反思 |
+| 个人成长回顾 | 理解身份与能力变化；起点 → 关键选择 → 证据 → 学到什么 → 下一方向 |
+
+## 证据与真实性
+
+- 成果优先写可核结果及其口径，不能量化时写可观察变化、交付物或他人采用情况，不编造数字。明确“负责、协作、支持、批准”等角色差异。
+- 时间线、组织名、客户名、作品链接和推荐语在公开前确认准确与授权；需匿名时保留问题、本人动作和结果的判断价值，不留下可反推的敏感细节。
+- 技能由近期作品、职责范围或实际使用场景支撑；自我定位可以有主张，但不能使用未获认可的资质、奖项或身份。
+
+## 结构与高质量写法
+
+先筛选与目标读者最相关的经历，不把完整人生经历当作专业证明。经历条目以动作和影响开头，背景只写理解贡献所需的约束；案例说明权衡和本人判断，比工具清单更能证明能力。CTA 具体到希望发生的下一步，并只提供获授权的联系方式。

package/skills/lark-doc/references/genres/route-platform.md

@@ -0,0 +1,9 @@
+# Genre Router: Platform / 平台发布稿 (`route_platform`)
+
+仅当最终交付物是小红书笔记、微信公众号文章或邮件成稿时进入本 router；按目标平台选择且只读取一个 leaf。仅把平台作为研究对象、信息来源或业务渠道时不触发；多平台成稿分别路由和生成。
+
+| 关键词             | Leaf                               |
+|-----------------|------------------------------------|
+| XHS、小红书         | [`xiaohongshu.md`](xiaohongshu.md) |
+| 微信、wechat       | [`wechat.md`](wechat.md)           |
+| 邮件、email、e-mail | [`email.md`](email.md)             |

package/skills/lark-doc/references/genres/route-report.md

@@ -0,0 +1,10 @@
+# Genre Router: Report (`router.report`)
+
+用数据、样本或研究形成洞察走本类；按读者任务选择且只读一个 leaf，关键词仅用于召回，`报告 / 分析 / 研究 / 数据 / 白皮书`单独不决定路由。组织执行 / 批准走 Workplace，自主学习走 Knowledge。
+
+| 读者任务 / 关键词、强信号与排除 | Leaf |
+|-|-|
+| 回答明确研究问题，方法、样本和可推广边界决定可信度；调研报告、访谈 / 问卷 / 用户研究。仅解读既定指标时排除 | [`research-report.md`](research-report.md) |
+| 解读已定义指标、趋势、分布、漏斗或实验观察值；数据报告、经营数据、指标复盘。需重新设计样本回答问题时排除 | [`data-report.md`](data-report.md) |
+| 让专业读者系统理解并评估问题、框架或方案；白皮书、行业框架、技术 / 政策议题。获客、产品卖点或 CTA 为主时排除 | [`white-paper.md`](white-paper.md) |
+| 比较战略、投资、市场、产品或资源选项及成本、收益、风险；商业分析、可行性、进入 / 自建或采购判断。正文要求具名决策者选择 / 批准，或形成授权、资源拨付、执行承诺入口时排除 | [`business-analysis.md`](business-analysis.md) |

package/skills/lark-doc/references/genres/route-workplace.md

@@ -0,0 +1,17 @@
+# Genre Router: Workplace (`router.workplace`)
+
+组织内决策、执行、留档走本类；先按读者任务与生命周期选择且只读一个 leaf，关键词仅用于召回，排除信号优先于同名词。
+
+| 读者任务 / 关键词、强信号与排除 | Leaf |
+|-|-|
+| 快速知悉、短判断或会前准备；备忘录、决策摘要、会前材料。完整批准论证走 Proposal，周期状态走 Weekly | [`memo-brief.md`](memo-brief.md) |
+| 按周期判断相对承诺的状态、偏差、风险和下一步；周报、日报、月报、项目状态。原因学习走 Retrospective，完整分析走 Report | [`weekly-report.md`](weekly-report.md) |
+| 请具名决策者批准方向、预算、资源或执行承诺；提案、立项、资源申请。已定产品行为走 PRD | [`proposal.md`](proposal.md) |
+| 将方向已定的一次性项目、变更、专项行动或营销战役转成可协同推进的交付、依赖、里程碑与验收；项目计划、执行方案、实施计划。仍在比较方向或请求批准走 Proposal / Report，重复稳定路径走 SOP | [`execution-plan.md`](execution-plan.md) |
+| 将已授权的内部规则 / 安排、可复核的检查整改记录或已核定组织立场写成正式载体；制度、公司通知、整改记录、讲话底稿。待批准方向走 Proposal，复杂执行走 Execution Plan，法定公文走 Official；`正式`单独不触发 | [`formal-doc.md`](formal-doc.md) |
+| 党政机关法定公文拟制、审校或制发；明确要求公文 / 红头 / 套红 / 正式发文，或法定文种与机关行文关系、文号、主送等制发要素共同出现。`通知 / 报告 / 公告 / 纪要 / 正式 / 官方`单独不触发 | [`official-redhead.md`](official-redhead.md) |
+| 记录已发生会议的决定、异议、行动和批准状态；会议记录、行动项。逐字稿不走本 leaf，法定公文纪要走 Official | [`meeting-minutes.md`](meeting-minutes.md) |
+| 从已结束周期 / 事件提炼证据化学习并改变下一轮；复盘、回顾、经验教训。当前状态走 Weekly，活跃未知事故走 Technical | [`retrospective.md`](retrospective.md) |
+| 方向已定，定义用户问题、范围、产品行为与验收；PRD、用户故事、验收标准。是否投入走 Proposal，实现取舍走 Technical | [`prd.md`](prd.md) |
+| 评审未来技术设计、查询精确契约或调查未知故障；RFC、API、架构、事故调查。产品行为走 PRD，已定重复路径走 SOP | [`technical-doc.md`](technical-doc.md) |
+| 按已批准、可验证路径重复达到终态，或为已知事件类别预置响应路径；SOP、runbook、值班 / 操作手册、BCP / 处置预案。应急预案若主要发布权威职责走 Formal，法定制发走 Official，活跃未知事故走 Technical，一次学习教程走 Knowledge | [`sop-tutorial.md`](sop-tutorial.md) |

package/skills/lark-doc/references/genres/sop-tutorial.md

@@ -0,0 +1,41 @@
+# Genre Contract: SOP / Runbook (`workplace.sop_tutorial`)
+
+## 体裁规则表（硬约束）
+
+| 规则项 | 规则 |
+|-|-|
+| 写作风格 | 命令式、具体、顺序稳定，一步一动作并紧邻可观察判据，不写无条件的“适当 / 必要时” |
+| 内容逻辑 | 先定 routine / controlled / high-risk，并识别是否为响应预案，再按“版本 → 触发 / 范围 / 终态 → 角色 / 前置 → 动作 / 判据 / 证据 → 异常 / 停止 / 恢复 → 完成记录 / 复审”推进 |
+| 事实 / 边界 | owner、版本、环境、资格、权限、工具、命令、阈值、预期结果和恢复路径均须已验证；警告在动作前；命令成功不等于业务终态；流程图 / 示意不能替代可执行步骤、判据与异常路径，须有文字等价；关键未知使可发布稿 `blocked` |
+| 错误 | 教程冒充 SOP、未分风险、缺 owner / 版本 / 前置、一条多动作、编造入口 / 阈值 / 权限 / 命令、停止后状态未知、只写“必要时回滚”或未验证终态；响应预案无分级触发、替补指挥、降级路径或解除条件，任一出现即失败 |
+
+## 适用与风险分类
+
+用于组织规定的重复作业、沿已批准路线取得确定终态的 runbook，或针对已知事件类别预置并授权的响应 / 业务连续性路径。一次性自助 how-to / 学习走 Knowledge；未来设计取舍、活跃未知故障或临场根因调查走 `technical-doc.md`；只建立组织权威、职责或发布要求而不提供现场步骤走 `formal-doc.md`。“教程 / 操作 / 手册 / 应急预案”单词本身不触发。
+
+| 分类 | 增量证明义务 |
+|-|-|
+| `routine` | 阶段或终态验证、常见异常和升级 |
+| `controlled` | 再含审批、接受 / 拒绝、偏差记录、变更复审和代表性试跑 |
+| `high-risk` | 再含 precheck、hold point、go / no-go、停止条件，以及可执行 rollback / fallback / roll-forward 和恢复验证 |
+
+## 响应预案增量
+
+- 涉及人身安全或法定直报时，其优先级高于业务与财产；按已核风险设置进入、升级、降级和解除条件，明确指挥 / 决策权限、替补角色、首轮动作、信息报送与对外口径边界。联络序列、等待时长和重试次数须预先批准；未知时保留占位，仅放行无需等待授权的安全动作。
+- 预设负责人失联、断网断电、主资源不可用等降级场景及可达的安全终态；恢复须验证真实业务终态。发布前按风险做桌面推演或代表性演练，高风险场景包含故障注入并记录缺口、owner 和复验。
+
+## 文控与证据
+
+写明触发、目标终态、范围、owner / 资格、当前版本 / 环境、前置、权限、工具和输入。命令、参数、阈值、预期输出、备份 / 恢复资产和试跑结果须来自真实环境；流程变更后更新、复审并标 superseded 状态。
+
+关键缺口就近使用`[待环境 owner 验证]`等具体占位。命令、权限、阈值、停止或恢复判据未知时只保留安全只读 precheck，不得创建可执行稿。
+
+## 步骤、异常与恢复
+
+- 每个关键步骤只写一个动作，紧邻可观察结果、阈值与证据；验证需要操作时另列一步。未知偏差停止于已知安全状态，记录证据并升级。
+- high-risk 在不可逆动作前设置 hold point：列 go / no-go 信号、决策人和信号缺失时的安全终态。rollback 写触发条件、适用范围、步骤、阈值、停止点和恢复后业务验证，不能只写命令回执。
+- 有状态迁移另列不可逆点、写入归属、checkpoint / 幂等，以及完整、无重复、有序或等价验证；关闭 fallback 前必须证明新终态稳定。
+
+## 高质量写法
+
+让具备规定基础资格但不熟流程的人可独立复现；选择条件写在动作前，稳定原理链接出去，不混入原理课或临场诊断。按风险裁剪篇幅但不删证明义务；按适用治理要求由代表性执行者试跑，未经任何实际验证不得发布。

package/skills/lark-doc/references/genres/technical-doc.md

@@ -0,0 +1,39 @@
+# Genre Contract: Technical Document / 技术文档 (`workplace.technical_doc`)
+
+## 体裁规则表（硬约束）
+
+| 规则项 | 规则 |
+|-|-|
+| 写作风格 | 精确、可证伪、术语与版本稳定；规范词仅用于明确采用的互操作、安全或验收语义 |
+| 视觉约束 | 在有明确内容作用时用代码、表格、架构 / 状态 / 时序图等组件降低实现与诊断成本，但不得替代契约、证据或操作说明 |
+| 内容逻辑 | 必须且只能选 design_rfc、api_reference、incident_diagnostic 一种主模式；分别按“证据 → 取舍 / 设计 → 验收”“契约 → 错误 / 兼容”“影响 → 假设 / 检查 → 验证 / 升级”推进 |
+| 事实 / 边界 | 标对象、环境、版本、时间、范围和证据窗；事实、推断、决定、未知分开；示例 / 图不替代契约；任何改状态动作须有授权、影响、停止、还原和恢复验证，关键缺口按 reader impact 处理 |
+| 错误 | 按关键词路由、三模式混写、设计无取舍 / 验收、reference 漏权限 / 错误 / 生命周期 / 兼容、未知故障直接定根因、改状态无授权 / 停止 / 还原或图作唯一证据，任一出现即失败 |
+
+## 先选唯一主模式
+
+| 主模式 | 读者任务 | 排除 |
+|-|-|-|
+| `design_rfc` | 评审者能批准并实现未来技术状态，理解替代、后果和验收 | 产品可观察行为走 PRD；既定路径走 SOP |
+| `api_reference` | 调用者无需猜版本、权限、输入、行为、副作用、错误与生命周期 | 仍在讨论接口取舍时走 design_rfc |
+| `incident_diagnostic` | 响应者以安全、有区分度的动作缩小未知、止损、恢复或升级 | 单纯团队学习走 Retrospective；已知重复处置走 SOP |
+
+## 共同证据边界
+
+标明对象、环境、版本、时间、范围 / 前置和证据位置 / 窗口；结论回链仓库、IDL / schema、日志、metrics、traces、变更记录或验证实验。缺口就近使用具体占位、收窄或 `blocked`；数据分级、访问、保留、重放、owner、时限和升级只在适用时形成门禁。
+
+代码与命令示例须实际验证并标环境 / 版本；架构、状态或时序图必须附文字等价，不能成为唯一证据或唯一操作说明。
+
+## Design RFC
+
+按问题证据 → 目标 / 非目标 → 约束 / 不变量 → 真实备选与同口径取舍 → 接口 / 数据 / 状态设计 → 失败、安全、兼容与迁移 → 上线 / rollback → 可观测性、测试 / 验收 → 未决决定推进。每项关键决定写 why、被否方案及后果；不得隐藏低置信度或版本偏差。
+
+## API Reference
+
+写清版本 / 环境 / 权限 / 签名、输入约束、行为 / 副作用 / 幂等、输出、已知错误及可操作恢复、限流 / 分页 / 重试、兼容 / 弃用。事件、异步、CLI、SDK、流式按需补 channel / message、交付 / 顺序、生命周期 / 耗尽、I/O、取消与背压；未知语义明确 unspecified，不从示例推断承诺。
+
+## Incident Diagnostic
+
+按影响与 expected / actual → 当前状态与证据链 → 可证伪假设 → 信息增益高且副作用低的检查 → 止损 / 恢复验证 → 升级与后续 RCA 推进。每项检查写预期观察及其支持 / 排除的假设。
+
+修改状态前必须确认授权、目标范围、潜在副作用、停止条件、还原路径和恢复判据；分开止损、根因与永久修复。缺证据、授权、owner、还原或升级路径时只给安全只读检查并 `blocked`；涉及安全 / 法务时先保全证据和升级。

package/skills/lark-doc/references/genres/wechat.md

@@ -0,0 +1,39 @@
+# Genre Contract: WeChat Official Account / 微信公众号文章 (`platform.wechat`)
+
+## 核心定位（硬约束）
+
+- 交付物是飞书文档中的“微信公众号风格”内容稿，不代表实际发布，也不执行微信平台审核、流量、商业或发布规则。
+- 视觉策略默认使用 `rich`，主动寻找图文结合的表达机会，但每个组件必须服务主线。
+- 写作风格可信、有观点、有叙事或论证推进，在专业感与亲近感之间保持平衡。公众号不是加长版小红书，也不是公文或报告换皮。
+- 一篇只服务一个读者任务和一个可兑现承诺；标题、封面、摘要、导语、正文与结尾围绕同一主线。不编造亲历、身份、数据、引语、案例或效果；无来源时不用“多数、普遍、研究表明”等统计口吻，材料不足时明确收窄表达。
+- 飞书源稿禁止使用 `callout`；生成后通过 Draft Profile Check 的 `profile.blocks` 检查，其他 block 按真实信息关系选择。
+
+## 适用与消歧
+
+用户明确要“微信公众号文章、公众号推文、微信长文、微信爆文、公众号风格”时使用，内容保存在哪里不影响本合同生效。
+
+普通微信聊天消息、群公告、朋友圈文案、视频号口播、小程序页面和服务通知不走本合同。仅把微信作为研究对象、信息来源或业务渠道时也不触发；若同时要公众号稿和正式体裁，分别生成，不混写。
+
+## 内容模式
+
+| 模式 | 内容脊柱 |
+|-|-|
+| 知识 / 方法 | 读者处境 → 核心原理 / 结论 → 方法与验证 → 成本、例外和适用边界 → 可执行认识 |
+| 观点 / 解释 | 现象或争点 → 中心判断 → 理由、证据与机制 → 相关反论 / 边界 → 校准后的结论 |
+| 资讯 / 热点 | 已确认事实 → 为什么重要 → 必要背景与多方信息 → 争议 / 未知 → 当前结论或更新点 |
+| 案例 / 故事 | 具体场景 → 选择与行动 → 可观察结果 → 代价 / 失误 → 可迁移洞见 |
+| 品牌 / 行动 | 读者场景 → 有边界的价值 → 证据 / 体验 → 条件与取舍 → 清楚结论 |
+
+## 成稿要求
+
+- 先钉住具体读者、核心问题与中心判断；内部比较信息清晰型、问题 / 冲突型、观点浓缩型标题，成稿只输出既有张力又不透支正文的一个。
+- 标题负责建立准确预期；摘要按需补充关键背景、判断或阅读收益，不复述标题。摘要、导语和首节必须各有信息增量。封面只保留一个视觉中心，图片文案不制造第二个主题。
+- 导语在首屏内用具体场景、问题、变化或判断说明“为什么值得读”，随后尽快进入主线，不用宏大背景、客套话或悬念拖延核心信息。
+- 正文沿一条逻辑线展开，小标题概括本节增量。段落各有一个主要意思，但长短随内容变化：重点句可独立成段，证据、故事和推理要保留完整上下文，避免短句过多造成逻辑断裂。
+- 使用自然、可交流的书面语；用具体细节、例子、转折和取舍形成作者声音，不靠网络热词、排比口号或统一句式制造“爆文感”，避免连续复用同一反转句式。
+- 完整稿至少给出一个封面或正文视觉方案；已有图片时就近用于提供证据、解释信息、建立场景或调节长文节奏。图片不设固定数量，也不为“图文并茂”强塞装饰图，正文仍须独立可读。
+- 结尾回扣开头问题或中心判断，留下结论、影响或自然的下一步；互动句、emoji 和话题标签均按需使用，不要求固定收尾动作。
+
+## 交付前检查
+
+确认标题没有透支正文，摘要与导语没有重复，文章主线连续，每节都在推进事实、故事、论证或方法，手机上容易扫读但不过度碎片化，图片确实帮助理解，且没有空洞口号、标题党、模板腔或虚构事实。

package/skills/lark-doc/references/genres/weekly-report.md

@@ -0,0 +1,24 @@
+# Genre Contract: Weekly / Status Report (`workplace.weekly_report`)
+
+## 体裁规则表（硬约束）
+
+| 规则项 | 规则 |
+|-|-|
+| 写作风格 | 具体、短、面向判断，稳定使用最小字段与状态语义，不用“持续推进”代替产出 |
+| 内容逻辑 | 围绕报告对象和周期，按“总体状态 / 最大变化 → 对照基线的产出 → 偏差 / 风险 / 依赖 → 下一里程碑 → ask”推进，只写影响判断的变化 |
+| 事实 / 边界 | 状态须回链范围、时间、质量、成本、资源或阻塞证据；事实、当前状态和下期计划分开；无基线或数据不足时写 unknown，不猜完成率、原因、owner 或日期 |
+| 错误 | 活动流水账、无周期 / 基线、健康色无判据、风险被埋、猜测根因冒充事实、下一步无里程碑、ask 不可执行或自动汇总不可追，任一出现即失败 |
+
+## 适用与消歧
+
+用于按固定或约定周期判断当前相对目标 / 计划 / 承诺的位置。解释已结束周期为何如此并改变下一轮走 `retrospective.md`；完整指标洞察走数据报告；一次性高层知会走 `memo-brief.md`。“报告 / 进展”单词本身不触发本体裁。
+
+## 状态与证据
+
+- 标明报告对象、周期 / 截至时间；进展使用已验收产出、里程碑或有口径指标，会议数、沟通和投入时长本身不等于进展。
+- On track / 红黄绿等状态须有预先定义或就近说明的判据。无基线时明确“无法判断是否按计划”，而不是默认绿色。
+- 风险、问题、依赖和阻塞按已知程度写影响、当前缓解、责任方与升级需求；冲突数据并列保留并标`[口径待核]`。
+
+## 结构与高质量写法
+
+个人短更新可收缩，项目群 / 月报可按需增加趋势、成本或预算，但不复制无用栏目。优先写相对上期和相对承诺的 delta；稳定低风险项可链接原记录。ask 写明对象、事项和需要时间，关键数据延迟时说明最近可用时间点及其判断影响。

package/skills/lark-doc/references/genres/white-paper.md

@@ -0,0 +1,32 @@
+# Genre Contract: White Paper / 白皮书 (`report.white_paper`)
+
+## 体裁规则表（硬约束）
+
+| 规则项 | 规则 |
+|-|-|
+| 写作风格 | 系统、清楚、克制；权威来自真实主体、证据与归属，不来自篇幅、正式腔或视觉复杂度 |
+| 内容逻辑 | 先确认白皮书类型、发布主体、专业读者和期望判断，再用证据建立问题、评价标准或框架、论证、反例及应用边界；框架必须实际解释或比较 |
+| 事实 / 边界 | 客观主张连接真实来源、时点、范围和限制；事实、解释、价值判断、提议与品牌立场可区分；政策身份、发布状态、利益、资助和案例选择不得虚构或隐匿；证据图与材料须确认使用权、来源和说明，复杂视觉附文字等价信息 |
+| 错误 | 政策与品牌身份混写；标题或版式伪造权威；宏大背景填篇幅；自创框架仅作装饰；来源不可追；单一案例冒充共识；忽略反证 / 利益冲突；CTA 吞没证据；复杂组件代替论证 |
+
+## 适用与消歧
+
+让专业读者系统理解并评估问题、框架或解决路径。先区分有权主体的政府政策白皮书与专业、技术或品牌资助白皮书；`白皮书`、`正式`、`权威`单独不产生政府或标准身份。明确研究问题和方法为核心走 [`research-report.md`](research-report.md)，特定组织选项决策走 [`business-analysis.md`](business-analysis.md)，设计 / RFC / 接口契约走 Technical，产品卖点、获客或 CTA 为主走 Marketing。
+
+## 子类型
+
+- **政府政策白皮书**：只有真实有权主体可使用；准确标政策、咨询、立法与发布状态，不模拟批准或法律效力。
+- **政策 / 专业问题白皮书**：围绕问题、证据、评价标准、方案和影响形成可审查论证。
+- **技术 / 行业 landscape 白皮书**：解释技术、标准或系统框架；一旦主要任务是批准实现设计或查询精确契约，改走 Technical。
+- **品牌资助白皮书**：证据评估仍须是主体任务；披露资助、产品利益和案例选择，转化内容与论证分层。
+
+## 证据与边界
+
+- 开头明确作者 / 发布主体、读者、使用场景、范围、文档状态、核心立场和期望判断。
+- 主张强度匹配证据层级；有限测试、相关观察、厂商数据或单一案例不得扩写成绝对承诺或行业共识。
+- 框架的每一层都须增加解释、比较或选择价值；问题原因、评价标准与方案逻辑相连，并处理重要反证、替代解释和可行性限制。
+- 主体或授权不明时用 `[发布主体待确认]`，不得写成政府、官方或标准；核心证据不足时收窄为 concept note / outline。利益关系或关键政策状态无法确认的发布稿标记 `blocked`。
+
+## 结构与高质量写法
+
+独立摘要（主体、论点、证据边界） → 问题与现有证据 → 评价标准或核心框架 → 逐层论证、方案与反例 → 应用 / 政策含义及条件 → 限制、利益关系与来源。摘要让忙碌读者复述主张和保留条件；长篇才增加目录或附录，不以背景、封面、缩写或组件制造权威感。

package/skills/lark-doc/references/genres/xiaohongshu.md

@@ -0,0 +1,38 @@
+# Genre Contract: Xiaohongshu Note / 小红书笔记 (`platform.xiaohongshu`)
+
+## 核心定位（硬约束）
+
+- 交付物是飞书文档中的“小红书风格”内容稿，不代表实际发布，也不执行小红书平台审核、禁词、流量或商业规则。
+- 视觉策略默认使用 `rich`，偏爱图文并茂和清晰轻松的阅读体验，但装饰不能代替内容。
+- 写作风格鲜活、有节奏、有画面感，可使用符合语境的 emoji。
+- 一篇只解决一个主要问题；标题、封面、首屏和正文围绕同一获得感并真正兑现。不编造亲历、身份、数字、效果或用户反馈，材料不足时用第二人称、场景化讲解或中性叙述。
+- 飞书源稿禁止使用 `callout`；生成后通过 Draft Profile Check 的 `profile.blocks` 检查，其他 block 按真实信息关系选择。
+
+## 适用与消歧
+
+用户明确要“小红书笔记、小红书写法、小红书 style、红书感、XHS 风格”时使用，内容保存在哪里不影响本合同生效。
+
+仅把小红书作为研究对象、数据源或业务渠道时不触发：小红书运营方案走 Workplace，平台数据或竞品分析走 Report，规则说明走 Knowledge。若同时要小红书风格稿和正式体裁，分别生成，不混写。
+
+## 笔记主任务
+
+| 主任务 | 内容脊柱 |
+|-|-|
+| 教程 / 攻略 / 知识 | 痛点场景 → 核心判断 → 分步做法 → 易错点 / 限制 → 马上可做的一步 |
+| 体验 / 测评 / 探店 | 使用场景 → 具体观察 → 亮点与槽点 → 适合谁 / 不适合谁 → 选择建议 |
+| 观点 / 热点 | 争议或反差 → 核心判断 → 理由与例子 → 另一面 / 边界 → 留给读者的问题 |
+| 个人经历 / 成长 | 真实困扰 → 转折瞬间 → 做过什么 → 可观察变化 → 可迁移认识 |
+| 推荐 / 种草 / 活动 | 目标人群与场景 → 核心价值 → 具体理由 / 体验 → 使用条件与取舍 |
+
+## 成稿要求
+
+- 先钉住具体读者、场景与获得感；内部比较搜索清晰型、痛点共鸣型、反差好奇型 3 个标题，成稿只输出正文能兑现的最强一个。
+- 首屏用 1—3 个短段落完成“具体场景 / 冲突 → 核心判断 → 内容预告”，不从宏大背景或自我介绍讲起。
+- 正文用短段落和有意义的小标题按信息增量推进；每节新增动作、观察、例子、判断或限制。“活人感”来自具体细节、选择和取舍，不靠强塞网感词。
+- emoji 可比正式体裁用得更积极，用于导航、语气和停顿，但不连续堆叠。围绕一个视觉中心设计封面，图片 / 截图 / 示意图就近服务对应内容；无可用图片时给出简短配图建议，正文仍须独立可读。
+- 核心主题词自然出现在标题或首屏，相关表达按需进入小标题和正文；话题标签少而相关，不为覆盖关键词而复读。
+- 结尾用一句记忆点收束；互动问题可选且至多一个，不要求固定收尾动作。
+
+## 交付前检查
+
+确认读者能一眼判断“这和我有关”，标题承诺已兑现，每节都有实质信息，手机上容易扫读，emoji 与图片确实帮助理解。出现公文腔、长铺垫、文字墙、题文错配、空情绪或虚构事实时返工。

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

@@ -0,0 +1,121 @@
+# Lark Doc Authoring
+
+## Philosophy
+
+以下原则是每个内容、结构和视觉决策的判定依据；写作和复查时逐条套用，冲突时按「约束栈」排序。
+
+- **读者本位**：落地前先回答：读者是谁、为什么要读、带着什么任务来。按读者的任务组织内容，不按功能或作者视角罗列。
+- **结构先行**：结论先行，先整体后局部；按逻辑分组与递进，依据关系选择列表、步骤或表格，使内容便于扫读。（特殊体裁除外）
+- **视觉服从语义**：先确定全篇主线和每节的中心任务或命题，再让视觉层级复现内容优先级。文档脱离讲解仍须完整、连续、可独立阅读。
+- **最低理解成本**：选择最能降低读者理解、执行和出错成本的表达形式，而不是机械选择字符最少或制作成本最低的形式；删冗余，用短句、动词和数据，并按真实信息关系使用图、表格或交互组件。
+- **克制且连贯**：每个视觉元素必须承担导航、比较、解释、证据、行动，或体裁所需的氛围与品牌功能；相关文字与视觉相邻，同类关系复用同类组件和样式。去掉后不影响读者任务或预期语气的装饰应删除。
+- **约束栈**：事实 > 用户硬约束 > 读者任务 > 内容 > 组件样式；后项不得牺牲或放宽前项，格式与组件不得反向改变内容判断。
+- **表达一致**：同一对象、动作和状态全文同名；标题层级与编号采用统一体系，如下；用户提供样例时，在不违反更高优先级规则的前提下延续其有效结构、语气、术语和编号。
+  - **自动编号模式**：每一个正文标题都写 `seq="auto"`，标题文本不手写任何前置序号。
+  - **中文手写模式**：适用于公文或正式场景，在标题文本中手写 `一、→（一）→ 1.→（1）`；最忌中文层级配阿拉伯小数，绝不出现 `一、` 下接 `1.1`。
+
+## Step Plan
+
+**CRITICAL：从零创作文档时按下述步骤依次执行，不可跳步。**
+
+### Step 1：理解读者任务、文档格式要求、硬约束和禁区。
+
+### Step 2：选择 genre content contract。
+
+下表文件均位于当前 Skill 的 `references/genres/` 目录。
+
+- 路由表仅用于选择候选，不代替 contract。高置信命中后必须读取对应 Profile / Adapter，并按其中的路由与消歧规则复核；未读取不得确定该值或进入 Step 3。确认后记录固定短名，最多各读取一个；未命中时，`genre_contract` 和 `adapter` 均可使用 `"none"` 或 `null`。
+- contract 决定内容任务、证据和体裁边界；adapter 只调整与所选 contract 兼容的平台结构、写作风格和组件约束。
+
+   | Content Profile | 独特专业任务 |
+   |-|-|
+   | [`route-workplace.md`](genres/route-workplace.md) | 组织决策、执行、留档 |
+   | [`route-report.md`](genres/route-report.md) | 数据、研究和证据形成洞察 |
+   | [`route-knowledge.md`](genres/route-knowledge.md) | 理解、自学、一次已知操作或检索 |
+   | [`route-media.md`](genres/route-media.md) | 独立采集、核实和公共理解 |
+   | [`route-opinion.md`](genres/route-opinion.md) | 形成并论证判断 |
+   | [`route-consumer.md`](genres/route-consumer.md) | 以真实体验或测试辅助消费选择 |
+   | [`route-marketing.md`](genres/route-marketing.md) | 组织授权的认知、转化或公关内容 |
+   | [`route-personal-brand.md`](genres/route-personal-brand.md) | 本人经历、能力和作品的可信呈现 |
+   | [`route-creative.md`](genres/route-creative.md) | 角色、冲突、情节与分支叙事 |
+
+   | Adapter | 渠道 |
+   |-|-|
+   | [`route-platform.md`](genres/route-platform.md) | Email、微信公众号、小红书 |
+
+### Step 3：收集资料并扫描表达机会。
+
+1. 强制扫描事实、数据、案例、引用和图片等资源缺口；内容需要而现有材料不足时必须检索或生成，判断需要图片且用户未提供素材时必须搜索图片。
+2. 根据用户要求、contract / adapter 限制和内容需要确定 `presentation_mode`，再识别真实信息关系并选择候选表达；不因命中关系就机械使用组件。
+
+   | 信息关系 | 候选表达 |
+   |-|-|
+   | 同组字段的精确比较或映射 | `table` |
+   | 流程、依赖、分支、时序、层级、因果、空间或拓扑关系 | `whiteboard` |
+   | 对象、场景、界面、外观、氛围、示例或视觉证据 | `img` |
+   | 复杂交互、动态状态、可探索数据或应用式布局 | `html5-block` |
+   | 两组简短、等权且适合横向阅读的信息 | `grid` |
+   | 单个关键提醒或限制 | `callout` |
+   | 简单并列、步骤或连续论述 | 列表或段落 |
+
+3. 按全篇、章节、block 三个尺度构图：相关内容相邻，同类关系保持相同顺序与对齐；正文可以是主表达，不要求每节都有 presentation block。
+4. 在写正文前确定计划使用的 block 和具体 `purpose`。Presentation Decision 的 `visual_plan.blocks` 只记录确需最低数量约束的 `whiteboard`、`img`、`html5-block`。三类均无硬性数量要求时写 `"blocks": []`。
+
+`presentation_mode` 只表示模型采用的视觉策略；只有用户要求、contract / adapter 限制互相冲突时才询问用户：
+
+- `formal`：视觉正式、克制；不使用高亮块、emoji 或装饰性组件，只保留正式体裁确有必要的结构。
+- `normal`：按内容需要使用组件；只有能降低理解、执行或出错成本时才扩展视觉表达。
+- `rich`：主动利用图片、画板、HTML 和其他飞书组件；每个组件须有明确目的，不设全局数量配额。
+
+### Step 4：提交 Presentation Decision，并初始化草稿。
+
+生成完整 JSON；字段值必须来自 Step 1–3，不得照抄示例。`word_count` 仅在用户明确提出字数要求时加入，使用 `min` / `max`；单边无限制写 `null`，“约 N 字”按 ±10%，无要求时省略整个字段：
+
+```json
+{
+  "audience": "项目负责人",
+  "reader_task": "判断偏差并决定下一轮动作",
+  "genre_contract": null,
+  "adapter": null,
+  "presentation_mode": "rich",
+  "visual_plan": {
+    "reason": "需要用因果图解释偏差来源与后续行动依赖",
+    "blocks": [
+      {"type": "whiteboard", "min_count": 1, "purpose": "展示偏差成因与行动依赖"}
+    ]
+  }
+}
+```
+
+不预建临时目录、草稿或决策文件。将上述 JSON 原样替换命令中的占位符并实际执行：
+
+```bash
+lark-cli docs +script --command init-draft --presentation-decision '<上方完整 JSON>' --format json
+```
+
+成功后：
+
+- 保持当前工作目录不变；将 `data.workspace` 原样记为 `work_dir`，将 `data.draft_path` 原样记为 `draft_path`；遵循 `data.tip`，后续始终使用 `@./<draft_path>`。
+- CLI 会创建独占的 `work_dir` 并保存 `.presentation-decision.json` 作为固定基线，**但不会创建 `draft_path` 指向的 XML**。`draft_path` 是当前任务可直接写入的新文件路径；要求、资料或 contract 实质变化时，提交新决策并重新初始化，不得直接改基线。
+
+### Step 5：生成 release candidate。
+
+读取 [`lark-doc-xml.md`](lark-doc-xml.md)，并结合 Presentation Decision、适用 contract 和 Philosophy 生成完整 XML。使用扩展标签时按需读取 [`拓展标签`](lark-doc-xml-extended-blocks.md)。
+
+1. 公开网络图片使用 `<img href="URL"/>`；已有本地图片使用 `<img path="@./relative/path"/>`；画板使用 `<whiteboard path="@./relative/path"/>` 并遵循[`画板工作流`](lark-doc-whiteboard.md)；HTML 使用 `<html5-block path="@./file.html"/>` 并遵循[`拓展标签`](lark-doc-xml-extended-blocks.md)。
+2. 直接在 Step 4 返回的 `draft_path` 创建并写入完整 release candidate。
+3. 首次写入后，发现 XML 语法问题时只修复最小范围，不无故重写正确内容。
+
+### Step 6：执行 Draft Profile Check。
+
+1. 执行 `lark-cli docs +script --command parse --content "@./<draft_path>" --format json`。顶层 `ok` 仅表示命令执行成功，是否通过看 `data.assessment.status`。失败时按 `data.diagnostics[]` 局部修复；只有草稿为空、截断或结构无效时才全文重建。`parse` 不替代 XML 规则或服务端校验。
+2. Profile Check 通过后，按 [`lark-doc-xml.md`](lark-doc-xml.md) 复查标签、属性和值，并依据 Philosophy 检查事实与来源、用户硬约束、适用 contract / adapter 以及 `visual_plan`。最终 XML 能否写入以 `docs +create` 的服务端结果为准。
+
+### Step 7：创建文档并处理局部失败。
+
+1. 只有最新 release candidate 完成 Draft Profile Check 和 XML 规则复查后，才读取 [`lark-doc-create.md`](lark-doc-create.md)，使用同一个 `draft_path` 创建文档。
+2. 创建结果存在 warning、局部资源失败或回查发现局部问题时，不得再次新建文档；读取 [`lark-doc-update.md`](lark-doc-update.md)，对已创建文档做最小范围修复，并按 update 流程 fetch 验证。
+
+### Step 8：清理并交付。
+
+无论创建成功、失败或被阻塞，只要 Step 4 已返回 `work_dir`，就先离开该目录，再使用当前运行时的文件删除能力精确删除整个 `work_dir`；不要使用通配符，也不要删除目录外的用户原始文件。最终只交付用户需要的结果，并说明必要来源、未关闭缺口、异常、失败或阻塞原因，以及文档 URL 或 token。

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

@@ -1,24 +1,15 @@
 # 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) — 写作原则（默认段落、按体裁、组件克制）
-> 3. [`lark-doc-create-workflow.md`](style/lark-doc-create-workflow.md) — 从零创作工作流（Code-Act Loop、单 Agent 串行撰写）
->
-> **未读完以上文件就生成内容会导致格式错误。**
+从 XML（默认）或 Markdown 内容创建一个新的飞书云文档；语义创作默认使用 XML，只有 Authoring 明确判定为 Markdown 例外时才使用 Markdown。
 
-从 XML（默认）或 Markdown 内容创建一个新的飞书云文档。
-
-> **⚠️ 格式选择规则：** 创建 / 导入场景下 XML 和 Markdown 都可以——用户提供 `.md` 本地文件、或明确说"导入 Markdown"时，直接用 Markdown；没有明确指示时默认 XML（表达能力更强，可承载更丰富的结构化内容）。不要在用户没要求的情况下主动从 XML 切到 Markdown，也不要在用户已给出 Markdown 时强行改成 XML。
+写入前必须按 `--doc-format` 读取对应格式参考：`xml` 读取 [`lark-doc-xml.md`](lark-doc-xml.md)，`markdown` 读取 [`lark-doc-md.md`](lark-doc-md.md)；Markdown 中使用 XML 扩展标签时还须读取 `lark-doc-xml.md`。
 
 ## 命令
 
 ```bash
-# 创建 XML 文档（默认格式，推荐）
-lark-cli docs +create --content '<title>项目计划</title><h1>目标</h1><p>记录本周重点。</p>'
-
-# 仅当用户明确要求导入 Markdown 时才使用；文档标题用 --title，正文标题按内容自然组织
-lark-cli docs +create --doc-format markdown --title "项目计划" --content $'## 目标\n\n- 明确重点\n- 记录待办'
+# 简单内容优先使用 `--content -`，文件导入如下：
+lark-cli docs +create --doc-format xml --content "@<XML 文件相对路径>"
+lark-cli docs +create --doc-format markdown --content "@./draft.md"
 ```
 
 ## 返回值
@@ -35,46 +26,29 @@ lark-cli docs +create --doc-format markdown --title "项目计划" --content $'#
       "new_blocks": [
         { "block_id": "blkcnXXXX", "block_type": "whiteboard", "block_token": "boardXXXX" }
       ]
-    }
+    },
+    "warnings": [],
+    "tips": ""
   }
 }
 ```
 
-- **`document.new_blocks`**：本次操作新增的 block 列表（如画板）。`block_id` 可用于 `docs +update` 的 `--block-id` 做精确编辑；`block_token` 是资源块（如画板）的 token，可交给 `lark-whiteboard` 等 skill 继续操作
-
-> \[!IMPORTANT]
-> 如果文档是**以应用身份（bot）创建**的，如 `lark-cli docs +create --as bot` 在文档创建成功后，CLI 会**尝试为当前 CLI 用户自动授予该文档的 `full_access`（可管理权限）**。
->
-> 以应用身份创建时，结果里会额外返回 `permission_grant` 字段，明确说明授权结果：
-> - `status = granted`：当前 CLI 用户已获得该文档的可管理权限
-> - `status = skipped`：本地没有可用的当前用户 `open_id`，因此不会自动授权；可提示用户先完成 `lark-cli auth login`，再让 AI / agent 继续使用应用身份（bot）授予当前用户权限
-> - `status = failed`：文档已创建成功，但自动授权用户失败；会带上失败原因，并提示稍后重试或继续使用 bot 身份处理该文档
->
-> `permission_grant.perm = full_access` 表示该资源已授予”可管理权限”。
->
-> **不要擅自执行 owner 转移。** 如果用户需要把 owner 转给自己，必须单独确认。
+- **`document.new_blocks`**：本次操作新增的 block 列表（如画板）。`block_id` 可用于 `docs +update` 的 `--block-id` 做精确编辑；`block_token` 是资源块（如画板）的 token，可交给 `lark-whiteboard` 等 skill 继续操作。
+- **`warnings`**：服务端返回的警告列表；`ok=true` 时也要检查，按提示确认是否存在降级或未完全处理的内容。
+- **`tips`**：服务端返回的后续处理建议；为空表示没有额外建议，非空本身不表示创建失败。
+- **`permission_grant`**：仅以 bot 身份创建时返回。CLI 会尝试为当前 CLI 用户授予新文档的 `full_access`；`status` 为 `granted` 表示授权成功，`skipped` 表示没有可用的当前用户 `open_id`，`failed` 表示文档已创建但授权失败。`perm` 固定为 `full_access`，失败或跳过时按 `message` / `hint` 处理。**自动授权不等于 owner 转移；用户要求转移 owner 时必须单独确认。**
 
 ## 参数
 
-| 参数                  | 必填 | 说明                                          |
-| ------------------- | -- |---------------------------------------------|
-| `--title`           | 否  | 文档标题，Markdown 导入时使用；XML 创建推荐在 `--content` 开头写 `<title>...</title>`；多个标题仅保留第一个并在 `warnings` / `degrade_details` 提示 |
-| `--content`         | 视情况 | 文档内容（XML 或 Markdown 格式）；不传 `--content` 时必须传 `--title` |
-| `--reference-map` | 否 | 结构化 `reference_map` JSON object；必须与 `--content` 一起使用。普通写入优先把结构写在正文里；该参数主要用于保留或回放已有 `document.reference_map`。支持直接 JSON、`@reference-map.json`（相对路径）或 `-` 从 stdin 读取。 |
-| `--doc-format`      | 否  | 内容格式：`xml`（默认，始终优先使用）\| `markdown`（仅用户明确要求时） |
-| `--parent-token`    | 否  | 父文件夹或知识库节点 token（与 `--parent-position` 互斥）  |
-| `--parent-position` | 否  | 父节点位置，如 `my_library`（与 `--parent-token` 互斥） |
-
-## 最佳实践
-
-- **较长文档**：参考 [`lark-doc-create-workflow.md`](style/lark-doc-create-workflow.md) 先建骨架再分段写入；短文档可一次写完整内容
-- **表达形式**：由用户目标和内容决定。需要结构化表达时可参考 [`lark-doc-style.md`](style/lark-doc-style.md)，但不要默认套用固定开头、固定富 block 比例或固定图表
+|参数|必填|说明|
+|-|-|-|
+|`--title`|否|文档标题，Markdown 导入时使用；XML 创建推荐在 `--content` 开头写 `<title>...</title>`；多个标题仅保留第一个|
+|`--content`|视情况|文档内容（XML 或 Markdown 格式）；不传 `--content` 时必须传 `--title`|
+|`--reference-map`|否|结构化 `reference_map` JSON object；必须与 `--content` 一起使用。普通写入优先把结构写在正文里；该参数主要用于保留或回放已有 `document.reference_map`。支持直接 JSON、任务独占目录内的相对 `@file`，或 `-` 从 stdin 读取。|
+|`--doc-format`|否|CLI 与语义创作均默认 `xml`，并建议显式传入；仅用户明确要求 Markdown 或保真导入 Markdown 时使用 `markdown`。不要混用完整的 XML 与 Markdown 文档格式；Markdown 中允许使用文档已定义的 XML 扩展标签。|
+|`--parent-token`|否|父文件夹或知识库节点 token（与 `--parent-position` 互斥）|
+|`--parent-position`|否|父节点位置，如 `my_library`（与 `--parent-token` 互斥）|
 
-## 参考
+## 需要回查文档
 
-- [`lark-doc-create-workflow.md`](style/lark-doc-create-workflow.md) — 从零创作工作流（Code-Act Loop、单 Agent 串行撰写）
-- [`lark-doc-style.md`](style/lark-doc-style.md) — 文档写作原则（默认段落、按体裁、组件克制）
-- [`lark-doc-xml.md`](lark-doc-xml.md) — XML 语法规范
-- [`lark-doc-fetch.md`](lark-doc-fetch.md) — 获取文档
-- [`lark-doc-update.md`](lark-doc-update.md) — 更新文档
-- [`lark-doc-media-insert.md`](lark-doc-media-insert.md) — 插入图片/文件到文档
+用 `lark-cli docs +fetch --doc "<document_id 或文档 URL>" --detail with-ids` 回查，若需要更多信息可查看 [`+fetch`](lark-doc-fetch.md)。