用途：在完成分析工作后，生成事实性的工作日志条目，记录已完成的分析工作，不包含解读或建议。当用户提出“总结工作”“记录结果”“创建工作日志条目”“撰写分析报告”等请求时启用。
主要能力与流程：
- 验证 Git 提交：运行 git status 检查是否有未提交更改；若有，询问用户是否先运行 code-quality-reviewer 代理并提交代码，等待确认后使用 Task 工具（subagent_type="code-quality-reviewer"）并协助提交；随后用 git log -1 --pretty=format:"%H%n%s" 获取提交信息。
- 确认理解：若有近期工作上下文，总结目标、代码位置、输出位置并用 AskUserQuestion 确认；否则向用户询问这些信息，再阅读代码、输出与文档。
- 处理图表：若输出文件夹有图表，执行 mkdir -p Notes/WorkingJournal/attachments 并复制为 Notes/WorkingJournal/attachments/YYYY-MM-DD-description.png，在 Markdown 中以相对路径引用并标注原始来源。
- 创建工作日志：文件名为 Notes/WorkingJournal/YYYY-MM-DD-[Author]-[Description].md，包含 front matter（author、date、project、git_commit、git_message、permalink）。
- 撰写摘要：结构可灵活，通常包含目标、所做工作、数据描述、方法描述、结果（表格/图表）、技术实现细节；使用相对路径引用代码（../../Code/）、输出（../../Output/）、数据（../../Data/）。
- 验证报告质量：创建后使用 Task 工具（subagent_type="report-checker"）传入报告路径、代码位置、输出位置、目标，检查所有声明是否引用准确、无推测、数字与源文件一致、无主观语言；发现问题需修订后再定稿。
关键规则：必须事实客观，只陈述所做与所发现，精确报告数值结果，描述所用方法，每个声明链接到来源；不得在用户未要求时解读经济含义、推测原因或影响、提出建议或下一步、使用主观评价（如“优秀”“成功”）。示例：好——“处理了来自 11,857 份提交的 470 万条持仓”“差异为 -30%（-2430 亿美元）”；坏——“这表明分类不足”“结果显示出强劲表现”。
完成后：告知用户文件路径，列出已记录内容，报告 report-checker 发现的问题，并询问“是否需要我添加任何具体信息？”除非被要求，否则不要建议解读或下一步。
限制：资料未提供该技能的安装方式、收费、平台或效果信息。