weekly-report-writer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Weekly Report Writer (周报撰写助手)

Weekly Report Writer (Weekly Report Writing Assistant)

概览

Overview

此技能自动化了周报/双周报的创建过程。它通过查找指定日期范围内的所有相关文档，阅读其内容，并根据模板或分层结构合成信息。它特别注重项目的连续性（追踪上一份报告的任务状态）和内容的深度（通过链接溯源）。

This skill automates the creation process of weekly/biweekly reports. It finds all relevant documents within a specified date range, reads their content, and synthesizes information based on templates or a hierarchical structure. It pays special attention to project continuity (tracking task status from the previous report) and content depth (traceability via links).

何时使用

When to Use

当用户要求：

“写我的周报”或“起草本周摘要”。
总结两个日期之间的进度。
基于上一份报告和一组新文档创建新报告。

此技能在文档知识库，如 Obsidian 知识库中特别有效。

When the user requests:

"Write my weekly report" or "Draft a summary of this week".
Summarize progress between two dates.
Create a new report based on the previous report and a set of new documents.

This skill is especially effective in document knowledge bases, such as Obsidian vaults.

工作流

Workflow

遵循此工作流生成报告。

Follow this workflow to generate reports.

第一步：收集用户输入

Step 1: Collect User Input

在开始之前，与用户确认以下信息：

开始日期：报告周期的开始。
结束日期：报告周期的结束。
仓库文件名是否包含日期前缀：确认文件命名约定（如
```
YYYY-MM-DD-描述.md
```
）。
上一份报告路径：上一份周报的文件路径。这对追踪正在进行的任务至关重要。
笔记库目录：文档存储库的根目录（例如他们的 Obsidian vault 路径）。
（可选）报告模板路径：如果用户有特定模板，请提供其路径。
（可选）项目背景路径：总结更大组织所有项目的文档路径（如果有）。

Before starting, confirm the following information with the user:

Start date: The start of the reporting period.
End date: The end of the reporting period.
Whether repository filenames include date prefixes: Confirm the file naming convention (e.g.
```
YYYY-MM-DD-description.md
```
).
Previous report path: The file path of the last weekly report. This is critical for tracking ongoing tasks.
Vault directory: The root directory of the document repository (e.g. their Obsidian vault path).
(Optional) Report template path: If the user has a specific template, provide its path.
(Optional) Project background path: The path of the document that summarizes all projects of the larger organization (if available).

第二步：查找文档

Step 2: Locate Documents

查找日志：使用用户提供的

笔记库目录

和日期范围，查找日期范围匹配的所有 Markdown 文件。

Log lookup: Use the

vault directory

and date range provided by the user to find all Markdown files that match the date range.

第三步：与用户确认文件列表

Step 3: Confirm File List with User

向用户展示找到的文件列表（日志 + 探测到的模板）。请用户确认列表，并反馈任何应 重点关注 或跳过的文件。一般来说，摘抄的文档、语音转写原文日志等应跳过；每日工作小结、会议纪要、项目更新等应重点关注。

Present the list of found files (logs + detected templates) to the user. Ask the user to confirm the list and provide feedback on any files that should be focused on or skipped. Generally, excerpted documents, original voice transcription logs, etc. should be skipped; Daily work summaries, meeting minutes, project updates, etc. should be focused on.

第四步：阅读、深度溯源与合成

Step 4: Read, Deep Traceability and Synthesis

确认后，阅读所有文件的内容。过程中要注意：

几个注意事项：

链接追踪：在阅读每日摘要/日志时，如果遇到一个指向另一个文档的“关键事项”，且包含
```
[[文档链接]]
```
，你应该使用工具读取那个被链接的文档。原因是，每日摘要通常只是一句话（“完成了... ”），而高质量周报需要源文档中的具体产出、方法和数据。
信息合成：过程中，合成信息时要注意：
- 追踪“上一份报告”中的项目，凸显其进展。
- 识别待办 (
```
🟥
```
  )、已完成 (
```
🟩
```
  )、进行中 (
```
🟨
```
  ) 和新想法 (
```
💡
```
  )，标记各个事项。
- 待办继承：上一份报告中任何
```
🟥
```
  (待办) 或
```
🟨
```
  (进行中) 的项目，必须带入新报告的“待办/积压”区域，除非在新报告中已经包括并明确标记为
```
🟩
```
  (已完成)。

After confirmation, read the content of all files. Pay attention to the following during the process: Several notes:

Link tracking: When reading daily summaries/logs, if you encounter a "key item" pointing to another document that includes
```
[[document link]]
```
, you should use the tool to read the linked document. The reason is that daily summaries are usually just one sentence ("Completed..."), while high-quality weekly reports require specific deliverables, methods and data from the source document.
Information synthesis: During the process, pay attention to the following when synthesizing information:
- Track projects in the "previous report" and highlight their progress.
- Identify to-do (
```
🟥
```
  ), completed (
```
🟩
```
  ), in progress (
```
🟨
```
  ) and new ideas (
```
💡
```
  ), and mark each item.
- To-do inheritance: Any
```
🟥
```
  (to-do) or
```
🟨
```
  (in progress) items in the previous report must be carried over to the "to-do/backlog" section of the new report, unless they are already included in the new report and clearly marked as
```
🟩
```
  (completed).

第五步：起草报告 (分层输出)

Step 5: Draft Report (Hierarchical Output)

起草报告。如果在第二步中找到了特定模板，请严格遵循它。否则，使用标准分层结构：

第一部分：个人状态同步

这是个人日志。
受众：自己 / 知识库。
内容：详细的技术背景、指向深度文档的链接、个人思考 (
```
💡
```
) 和具体状态更新。保留
```
[[Wiki Link]]
```
格式。

第二部分：团队对外同步

这是团队报告中「自己负责的部分」。
受众：管理者 / 团队。
内容：高层级摘要。
- 关键进展：交付了什么？（关注价值）。
- 风险/卡点：需要什么支持？
- 下一步计划：近期计划是什么？
- 提及：使用
```
@用户
```
  格式标记负责人。

报告文件名：使用文档库的文件名定义，和之前的报告文件名风格保持一致。

Draft the report. If a specific template is found in Step 2, follow it strictly. Otherwise, use the standard hierarchical structure:

Part 1: Personal Status Sync

This is a personal log.
Audience: Self / Knowledge base.
Content: Detailed technical background, links to in-depth documents, personal thoughts (
```
💡
```
) and specific status updates. Keep the
```
[[Wiki Link]]
```
format.

Part 2: Team External Sync

This is the "part you are responsible for" in the team report.
Audience: Managers / Team members.
Content: High-level summary.
- Key progress: What was delivered? (Focus on value).
- Risks/Blockers: What support is needed?
- Next steps: What are the short-term plans?
- Mentions: Use the
```
@user
```
  format to mark responsible persons.

Report filename: Use the filename convention of the document library, and keep it consistent with the style of previous report filenames.

第六步：遗漏检查 (Gap Analysis)

Step 6: Gap Analysis

草稿生成后，针对高价值产出进行一轮“遗漏检查”。提醒用户「检查草稿，若有遗漏，请补充」。然后按用户反馈对草稿做编辑更新。

After the draft is generated, conduct a round of "gap check" for high-value deliverables. Remind the user to "check the draft, and supplement if there are omissions". Then edit and update the draft according to user feedback.