Weekly Review Authoring（周报写作）

把周报写成推动工作和积累职业证据的工具，而不是活动流水账。工作结果、本人贡献、证据、影响、卡点和所需支援始终优先；工作经验与组织信息只在能改变行动时补充。

开始前

1. 先读取当前工作区适用的 AGENTS.md 和 README.md，遵守更具体的落盘、证据和权限规则。

2. 如果工作区里存在周报目录（路径由用户在 AGENTS.md 或对话中给出），读取其中：

   • 该目录自己的 AGENTS.md / README.md；
   • 所在组织的周报字段模板；
   • 最新的团队样本或范例；
   • 上一周的个人周报。

   没有这个目录时，直接按本技能的默认模板起草，不要虚构团队规范。

3. 起草或实质性复核前，必须完整读取 references/weekly-review-standard.md。

工作方式

1. 确定周期和任务模式

• 用户要“写周报”时，默认起草当周本地 Review 版；日期能从环境和现有文件确定时不要追问。
• 用户要“Review/优化”时，只处理指定草稿和反馈；不要顺手提交或改写其他周报。
• 用户明确确认定稿时，可以生成本地 _定稿.md；保留需要长期追溯的草稿和证据底稿。
• 只有用户在当前任务中明确要求提交或写入 OA / 在线文档，才进入外部写操作；执行前再次核对目标、字段和授权。

2. 先建立证据清单

优先检查用户放入范围的本地资料：Git 状态与提交、当周新改文档、实验记录、数据快照、工作日志、会议产物和既有周报。必要时再只读访问在线协作资料（文档、任务、会议纪要等）。

为候选事项记录：

• 要解决的问题；
• 本人职责和关键判断；
• 已完成产出与当前状态；
• 可复现证据；
• 对业务、技术、效率、质量、成本或风险的影响；
• 下一步和判断门槛；
• 卡点造成的时间/结果成本及所需支援。

不要把文件修改量、会议数量或 Agent 生成量直接当成绩。链接是证据入口，正文仍需讲清结论。

3. 选出结果主线

从证据清单中挑出本周最硬的 1—3 个结果，按重要性而非时间顺序组织。没有最终业务指标时，可使用经验证的中间成果，例如基线、评测口径、数据错配、被排除的错误路线、缩小后的方案空间或可执行实验，但必须标明状态。

4. 按字段写正文

优先使用用户所在组织的实际周报字段。组织没有规定字段时，使用本技能的默认六模块模板：

• Weekly OKR Progress【本周OKR进展】
• Abnormity【异常】
• Obstacle【卡点】
• Refreshedness【知真】
• Interaction【互动】
• Action【决策】

字段名可以整体替换，但参考标准里的内容优先级、结果写作单元和 Review 清单与字段无关，任何模板下都适用。

知真 使用独立主题的总—分 Bullet。论文调研、自动化工具、组织 Context/Agent 等没有直接因果关系的主题必须分开，不为追求统一论点而强行串联。

5. 做提交前审查

确认：

• 最重要结果在开头即可被看见；
• 本人贡献与团队贡献分得清；
• 结论有证据、影响和状态；
• 卡点写清成本、尝试和具体支援；
• 至少一项可直接转成高质量简历或述职材料；
• 技术内容经得起同行追问；
• 未验证判断没有写成事实；
• 次要经验和组织信息没有挤占结果主线。

6. 本地落盘并等待 Review

默认文件名：

YYYY-MM-DD至YYYY-MM-DD_周报_草稿.md

在回复中给出草稿和证据底稿的本地链接，简要说明新增或调整了什么，然后停止等待本人 Review。不要把“草稿写完”表述成“周报已提交”。

权限边界

• 本地起草不代表获得 OA / 在线文档写权限。
• 读取在线资料不构成写入授权。
• 不发送消息、不修改权限、不提交表单、不移动或删除云端文件，除非用户在当前任务中明确要求。
• 外部写入前保留本地最终版本，确保用户能够核对实际提交内容。