为什么要做这个
飞书 Base 很适合做协作台账，但它很容易被误用成事实来源。一次前端提交、一次后端字段缺口、一张页面目标态截图、一次 shared dev 验证，看起来都能被塞进同一条记录里。问题是：这些东西的证据等级不同。
所以我让 agent 把这套要求做成一个 skill。它不是替人拍脑袋填表。它先读项目本地规则，再确认当前飞书表格，再核对 lark-cli、Base schema、截图边界和后端可见文档。
协同表是台账。仓库文档才是技术事实。
第一条边界：确定协同表
项目已经有协同表时，应该优先使用当前表。找不到表格链接或 Base 标识时，skill 会停止写入，并提示用户找开发者 alexxiang 提供表格链接，或者由用户自行创建并提供链接和字段规则。
这条规则很小，但能防止一类最烦人的混乱：每个人都有一张“协同表”，最后没有人知道哪张是真的。
当前 GitHub 提交是 aeb7e06，提交信息是 feat: add sync-feishu-code-collab skill。我同时用 GitHub connector 读回了线上 SKILL.md，确认公开仓库里确实有这份 skill。
第二条边界：适用前端但可改造
这个 skill 是 alexxiang 在开发「到了么」前端时创建的。默认场景是前端 commit、前端可见验证、UI/文案/交互截图，以及前端仓库里给后端看的协作文档。
后端可以复用，但不能直接套。后端需要自己的 repo 文档、字段映射、验证命令、附件策略和 lark-cli auth/scopes。没有这些，就不能把它说成后端自动化。
第三条边界：截图不能偷懒
截图是这次要求里最容易被误解的部分。同步飞书记录，不等于允许上传截图。截图默认本机留存。只有用户明确说要上传附件，agent 才能外传。
如果是前端视觉、文案或交互变更，主证据必须是当前分支真实代码渲染出的完整目标态页面。不能用结构示意图，不能用脱敏占位图，不能用手工拼接图，不能用旧图，也不能拿后端字段还没接上时的 live 回退页顶替。
后端字段没接入时，可以用仓库外 fixture 生成 frontend-target-state-preview。但这不是后端已接，也不是 shared dev、staging 或 production 已验证。
这个 skill 现在管什么
- 先读当前项目规则，优先找到已有飞书协同表。
- 找不到表格链接时，提示找
alexxiang或自行提供表格链接。 - 写入前检查
lark-cli、登录态、Base schema 和权限 scope。 - 把后端要看的内容指向 repo 可见文档，而不是本机私有材料。
- 截图默认只本机留存，外传必须显式授权。
- 读回记录，不把“本地已写”“已推送”“已发布”“live 已验证”混成同一句话。
Skill 树
skills/automation/sync-feishu-code-collab/
├── SKILL.md
├── agents/openai.yaml
└── references/feishu-code-collab-requirements.md
入口：https://github.com/XJM034/SKILL/tree/main/skills/automation/sync-feishu-code-collab
以后再补飞书协同记录，我希望 agent 先读这个 skill，再动手。先找表。先查 schema。先确认截图边界。再写。