daily-report-writer

name	daily-report-writer
description	Use when the user explicitly asks for a Chinese daily report such as "日报", "工作日报", "整理日报", or "日报式总结", and the output should be a short personal worklog based on repo progress, task analysis, runs, or TensorBoard findings.

Daily Report Writer

Overview

Generate a short Chinese markdown daily report in the user's personal style. Use repo evidence to infer what was done, but keep the final output compact and daily-log-like rather than formal or over-explained.

Trigger Rules

Use this skill only when the user is explicitly asking for a daily-report-style output. Trigger on requests such as:

• 帮我写个日报
• 整理一下今天的日报
• 做个日报式总结
• 把最近改动总结成工作日报

Do not use this skill for generic requests such as:

• 总结一下这个模块
• 解释这段代码
• 分析这个报错

If the request is ambiguous, prefer not to use this skill unless the wording clearly asks for a daily report or work-log-style summary.

Workflow

1. Classify the request into one of four modes:
   • git/workspace: the user asks about recent changes, current workspace, or recent implementation progress.
   • repo task: the user asks for a daily report about a task, module, feature, or code path.
   • experiment: the user asks about runs, logs, snapshots, TensorBoard, training effect, or experiment comparison.
   • mixed: the request combines code changes and experiment status.
2. Gather evidence before writing:
   • git/workspace: run scripts/collect_git_context.py.
   • experiment: run scripts/collect_experiment_context.py.
   • repo task: inspect relevant code, config, docs, and git context if useful.
   • mixed: collect both code and experiment evidence, then merge.
3. Separate facts from interpretation:
   • Facts: what changed, what was run, what files/runs/configs exist, what metrics are visible.
   • Interpretation: write as 我认为, 建议, TODO, or 待确认.
4. Draft the markdown report directly in Chinese.
5. If evidence is incomplete, keep writing the report and place [图片], [视频], or [命令输出] inline at the exact point where the missing artifact belongs.

Writing Rules

• Output exactly one fenced markdown code block and nothing outside it.
• Keep the default report roughly at most half the length of the earlier real-test drafts unless the user explicitly asks for detail.
• Keep precise names for runs, tasks, configs, checkpoints, branches, and files.
• Prefer short factual paragraphs over decorative prose.
• Summarize task intent, progress, result, and remaining issue. Do not展开到具体代码实现细节，除非该细节本身就是日报重点。
• Use markdown structure actively to improve readability instead of writing one flat block of text.
• Default heading depth is #, ##, and ### only:
  • use one # title for the whole report
  • use ## for major sections such as 今天, 训练效果, 问题, TODO
  • use ### only when a major section needs one more level of grouping, such as multiple experiment groups or a split by time period
  • do not go deeper than ###
• Use adaptive sections. Common sections include:
  • 训练效果
  • 问题
  • 建议
  • TODO
  • 今天
  • 可视化效果
• When listing multiple runs or experiments, use 1. 2. 3. and preserve exact run names.
• Use bullet lists for parallel points, TODOs, and grouped observations.
• Use short tables only when the content is naturally comparative, such as multiple runs, task statuses, or setup/result summaries with the same fields.
• Do not force tables into normal narrative sections. If a short paragraph or list is clearer, prefer that.
• Use inline code for run names, config names, commands, task ids, and other exact identifiers.
• Use bold sparingly to highlight one or two key conclusions, not entire sections.
• Do not fabricate training results, screenshots, or conclusions.
• If a claim is not supported yet, mark it as 猜测, 待确认, or 我认为.
• Do not default to “暂时无法在飞书文档外展示此内容” unless the current context clearly requires that wording.
• Use git status, git diff, file inspection, and helper-script output as internal evidence for synthesis. Do not default to asking the user to paste low-level VCS evidence into the daily report.

Read references/style-guide.md before drafting to align tone and structure.

Source Playbooks

Read references/source-playbooks.md and follow the branch matching the request:

• git/workspace
• repo task
• experiment
• mixed

Use the helper scripts when they fit, but do not limit yourself to them if direct repo inspection is needed.

Missing Material Rules

If the report would benefit from visuals or missing evidence, insert placeholders directly inside the relevant section:

• [图片]
• [视频]
• [命令输出]

Do not append a default final 需要补充的材料 section.

Good patterns:

• In 训练效果: place [图片] right after the sentence that references the missing curve screenshot.
• In 可视化效果: place [视频] where the play/eval result should appear.
• In 网络结构 or command-result paragraphs: place [命令输出] inline where the missing artifact belongs.

Avoid vague requests such as 补点图 or 再截一个结果, and avoid asking for git diff screenshots unless the user explicitly wants a more formal report.