| name | work-duty-summary |
| description | 工作职责总结：从当前用户全量的重要飞书资产——本人写的自评/述职/晋升/总结类文档、OKR、任务、会议与妙记、日历例会、我主编的文档、审批、IM 高频协作——中，反推并成文地写出这个人最近半年真实在做的工作职责，用『职责域 + 关键结果 + 利益相关方』的成熟框架描述，交给用户微调确认，再写成一个可复用的职责档案文件，并可选写进 Agent 记忆作为长期锚点，还支持定期重跑、对比变化、经用户确认后刷新锚点。用于给 AI 一个稳定的『本人真正关心什么』的 grounding，避免后续探索、查找、判断时偏离本人关注点。当用户说『工作职责总结』『我的工作职责』『我最近在负责什么』『总结我的职责/岗位职责』『帮我沉淀一份工作职责给你记住』『让你更懂我在做什么』『定期更新我的工作职责』，或要基于飞书真实活动反推现任职责时使用。不负责撰写招聘 JD、绩效评估、写 OKR 本身（走 feishu-okr-drafter）。 |
工作职责总结
目标与边界
从当前用户真实的飞书工作活动中，归纳出最近约半年本人实际承担的工作职责，成文、可微调、可写入记忆，作为后续所有任务的稳定锚点。核心价值是：让 AI 在探索、查找、判断时对齐"本人真正关心什么"，而不是发散到无关信息。
产出的不是招聘用的 JD，也不是能力全景评估，而是给 AI 自己用的职责画像：用户最近在负责哪些事、对什么结果负责、要和谁协作。
三条底线：
- 以真实做的事为主，头衔为辅。职责从 OKR、任务、会议、文档、协作等真实活动归纳；名义头衔只做校准，不作为职责来源。
- 不过度断言。这是基于可见活动窗口的推断，不是全面能力评估。证据不足的职责标
[推断待确认]，宁可少写也不编。
- 默认脱敏、隐私优先。原始聊天记录、邮件正文、敏感数字不进档案和记忆；只保留抽象后的职责陈述 + 证据索引（来源类型/时间，不含敏感原文）。
前置：先读依赖
开始前先用 Read 读取 ../lark-shared/SKILL.md（认证、身份、租户、权限处理）。读取飞书内容默认 --as user，并先核验身份与租户：
lark-cli auth status --json --verify
lark-cli contact +get-user --as user
支持 auth status --json --verify 的环境必须确认 identity=user；不支持时退回 contact +get-user --as user 解析当前用户。写入记忆或飞书前，务必再次确认租户与身份——个人与公司飞书必须隔离，不混用 token/profile。
数据源：默认全量采集重要飞书资产
默认采集下列全部资产，它们都是反推职责的一等信号，不做"核心 vs 次要"取舍。用户明确说"只要快、跑核心就行"时，才收敛到 OKR+任务。运行时告知用户本次实际覆盖了哪几类、哪类缺权限或被跳过。
| 资产 | 反映什么 | 依赖 skill |
|---|
| 自评/述职/总结类文档 | 本人亲手写的自评、述职、晋升材料、H1/H2 总结、工作复盘——直白写了"我做了什么、拿了什么结果"，反推职责的最强信号 | lark-drive、lark-doc |
| OKR | 我主动承诺推动的目标、纵向承接关系 | lark-okr |
| 任务 | 我实际在做、对谁负责的具体事项 | lark-task |
| 会议 + 妙记 | 我参与/主持的议题、协作面与话语权 | lark-vc、lark-minutes |
| 日历例会 | 常规例会与固定协作节奏 | lark-calendar |
| 我主编的文档 | 我的产出物与专业领域 | lark-drive、lark-doc、lark-wiki |
| 审批 | 我发起/审批的事项 = 我的职权边界 | lark-approval |
| IM 高频协作 | 高频沟通的群与人 = 利益相关方（隐私最敏感） | lark-im、lark-contact |
缺权限不等于跳过：某类资产因 scope 缺失读不到时（例如 OKR 常缺 okr:okr.period:readonly），先告诉用户"这是职责的重要信号，是否补一次授权再采集"，用户同意就 lark-cli auth login --scope ... 补授权后重采；用户不补才降级，并在报告里标注该类缺失。不要默默降级把重要资产丢掉。（飞书绩效系统 OpenAPI 一般拿不到授权，故本 skill 以"本人写的自评/述职/总结类文档"替代作为最强信号；有绩效授权时可作可选加强，见 playbook。）
IM 层默认纳入（这是用户本人的数据、自助分析），只做频度/对象聚合，不读消息内容、不落原文；用户明确不同意时才跳过。
采集口径、命令与解析细节见 references/collection-playbook.md。
工作流
1. 对齐范围与数据源
确认三件事：时间窗（默认近 6 个月，2026-02-17 ~ 2026-08-17 这类显式区间；自评/述职/晋级类文档单独放宽到近 12 个月，因为最完整的常写于上一考核周期）、纳入哪些资产（默认全量重要资产）、产出落点（档案文件，可选写记忆）。用户没特别要求就用默认，直接开跑，不必逐项追问。若某类重要资产缺权限，按数据源一节的规则先征询是否补授权（只读演练/无人值守时默认降级并标注，不阻塞），再决定采不采。
2. 采集真实活动证据
按 references/collection-playbook.md 逐类采集，边采边建证据台账（不落敏感原文）：
证据 → 来源类型 → 时间 → 指向的职责线索
Base/接口读取注意串行 + 退避，避免限流；详见 playbook。
3. 聚类成职责域
把散点证据按业务结果聚类，而不是按项目名或工具堆叠。归纳原则见 references/synthesis-rules.md。典型聚类方向：客户/商业结果、端到端流程效率、产品化与复制、组织机制与影响力、专业能力沉淀。
每个职责域回答三问：我负责什么领域、要交付什么关键结果、对谁负责/和谁协作。一般 3–6 个职责域；范围窄时可更少。反复出现、跨多源印证的才是主职责；偶发的进候选或舍弃。
4. 用成熟框架成文
用「职责域 + 关键结果 + 利益相关方」三段式写每条职责，参照 assets/profile-template.md 的结构与措辞。风格要求：成熟、克制、结论先行、不 AI 味、不堆动词（避免"负责、推进、跟进、赋能"空转）。
每条职责的措辞规范与正反例见 references/synthesis-rules.md。证据不足的标 [推断待确认]。
5. 交付草稿并让用户微调
先把成文档案 + 证据覆盖说明呈现给用户，明确请他微调：增删职责域、调整措辞、纠正利益相关方、删掉不准的推断。这一步必须等用户确认，不要自行认定为最终版。
6. 写成可复用档案文件
用户确认后，按 assets/profile-template.md 写成档案文件。默认路径：优先写到当前工作目录的 outputs/工作职责总结.md；无 outputs 约定时问用户放哪或放当前目录。文件里只留最终职责陈述 + 脱敏证据索引，不留草稿痕迹、口径声明、过程叙述。
7. 可选：写进 Agent 记忆做锚点
问用户是否要把这份职责写进 Agent 记忆，使后续所有任务默认对齐。只有用户明确同意才写。写入方式遵守宿主 agent 的记忆规范：不直接改记忆主文件，而是新增一个 <timestamp>-work-duty-summary.md 更新笔记，内容为浓缩后的职责锚点（职责域 + 关键结果 + 利益相关方 + 时间窗 + 档案文件路径 + 下次刷新日期）。各 agent 的落点、格式与锚点内容见 references/memory-write.md。
核心不变：存抽象职责锚点，不存原始飞书数据；经用户同意；可刷新。宿主环境无既定记忆机制时，按该 agent 的记忆约定落地。
8. 定期刷新（重跑 → 对比 → 确认后刷新）
职责会随时间漂移，但绝不自动覆盖记忆锚点——某段时间的临时项目可能把锚点带歪。刷新遵循"自动重跑、自动对比、写入前必须用户确认"：
- 判断是否该刷：读已有记忆锚点里的"下次刷新日期"，到期或用户主动要求时才重跑；未到期则跳过，避免无意义重算。
- 重跑：按 1–4 步用新的时间窗重新采集、成文，得到新职责画像。
- 对比：与已有锚点逐条 diff，归纳"新增职责 / 消失职责 / 权重变化 / 利益相关方变化"，只汇报变化，不重复未变部分。
- 确认后刷新：把变化清单交用户确认；用户同意后才更新档案文件与记忆锚点（新增更新笔记，不改旧笔记），并写入下一个"下次刷新日期"。用户不确认则保留旧锚点不动。
定期触发属于宿主环境能力，本 skill 不自带调度器。挂定时任务的方式（桌面端 automation / 系统 cron）见 references/memory-write.md 末节；无论怎么触发，"写入记忆前需用户确认"这条不变。
参考资料路由
