weekly-report

Weekly Report

Purpose

This skill is used to generate a work weekly report that can be sent directly.

The core goals of a weekly report are:

1. Explain the core work themes within the target time range
2. Explain the evidence source corresponding to each item of work
3. Distinguish completed, in progress, pending scheduling, and discussion only
4. Restore the key points of collaborative communication
5. Provide a next-week plan consistent with the facts

Success Criteria

A qualified weekly report must satisfy:

1. The time range is clear and correct
2. The main body of the weekly report is organized by "work theme"
3. Each core work item is supported by at least two types of evidence, or clearly marked as having insufficient evidence
4. Factual content and inferred content are expressed separately
5. The user can send it directly without manually adding large sections of background

If the above points cannot be achieved, this weekly report is not considered complete.

Time Semantics

Default Rule

• The user explicitly says "this week's weekly report":
  • Take this week's Monday to the current date
• The user does not explicitly say "this week":
  • By default, take last week's Monday to Sunday

Explicit Rule

• 本周: This week's Monday to the current date
• 上周: Last week's Monday to Sunday
• 3月24日那周: The natural week containing that date, ranging from Monday to Sunday

Required Behavior

Before starting collection, the absolute date range must be output first; you cannot only say "this week" or "last week".

Example:

本次周报范围：2026-03-16 00:00:00 +08:00 ~ 2026-03-22 23:59:59 +08:00
覆盖日期：2026-03-16 ~ 2026-03-22

Core Model

Channel

Channel represents an information source that can be independently connected.

Each channel should belong to one channel_family：

• collab_platform
• git
• agent
• local_docs

Each channel only declares which capabilities it provides, and is not responsible for determining the weekly report structure.

Capability

Capability represents a specific collection capability that a channel can provide.

It is recommended to use these capability names:

• calendar
• meeting_notes
• docs_search
• docs_fetch
• message_search
• git_history
• agent_history
• file_metadata

Evidence

Evidence represents a normalized evidence object.

Each piece of evidence should at least try to include:

• source_family
• source_channel
• evidence_type
• title
• summary
• timestamp or time range
• actors
• project_or_topic
• url_or_path
• confidence

Commonly used evidence_type：

• meeting
• meeting_notes
• doc
• message
• commit
• agent_session
• file_metadata

Work Topic

Work Topic represents a group of work themes merged around the same project, feature, special initiative, or goal.

Each work theme must at least answer:

• What this work is
• What the current status is
• What the key conclusions are
• What evidence supports it
• Whether to continue advancing it next week

Pipeline

Step 1: Resolve Time Range

Parse the time range first, then start collection.

If a stable calculation of the week range is needed, prioritize using:

• scripts/resolve_week_range.py

For script description, see:

• references/time.md

Step 2: Discover Channels

Check which channels are available in the current environment:

1. Collaboration platform channel
2. Git channel
3. Agent channel
4. Local document channel

Continue collection only for channels that have been discovered.

Step 3: Inspect Capabilities

For each discovered channel, confirm its available capabilities.

For example:

• The collaboration platform may support calendar、docs_search、message_search
• The Git channel may support git_history
• The Agent channel may support agent_history

When a channel has only some capabilities, it is still allowed to continue execution.

Step 4: Collect Raw Facts

Collect raw information in parallel by channel, prioritizing collection of:

1. Meetings, minutes, documents, and messages in the collaboration platform
2. Git history
3. Agent history
4. Local documents and exported files

Step 5: Normalize Evidence

Organize the raw results into a unified Evidence。

After normalization, at minimum, aggregation by the following dimensions should be supported:

• Time
• Project / Topic
• Person
• Evidence type
• Source channel

Step 6: Extract Candidate Topics

Prioritize extracting candidate work topics from high-signal content:

• Git commit topics
• Document titles and summaries
• Meeting titles and meeting minutes summaries
• High-frequency keywords in messages
• Agent task objectives

Step 7: Merge Into Work Topics

Merge evidence into by topic Work Topic, and determine:

• Whether these pieces of evidence point to the same piece of work
• Whether the current status is completed, in progress, pending scheduling, or discussion only
• Which conclusions can go into the main body of the weekly report

Step 8: Validate Topics

Each work topic should complete cross-evidence verification as much as possible.

Combinations to prioritize for verification:

1. meeting + doc
2. doc + commit
3. commit + agent_session
4. message + meeting / doc

If a certain piece of work hits only a single evidence source:

• First try to supplement the evidence
• If the evidence cannot be supplemented, lower the confidence level
• Clearly state in the results that the evidence is insufficient

Step 9: Write The Report

Organize the final weekly report by work topic, not by listing raw data by platform or channel.

Implementation References

Do not pile platform or channel implementation details into this document; read them as needed:

• Collaboration platform Lark / Feishu:references/lark.md
• Git channel:references/git.md
• Agent channel:references/agent.md
• Local document channel:references/local-docs.md

Channel Contract

Channel Contract Used to standardize how a new platform connects to this skill.

The main document only retains the contract entry point; for specific field requirements and degradation behavior, see:

• references/channel-contract.md

Evidence Rules

Evidence rules are used to define evidence priority, confidence determination, and writing boundaries.

For specific rules, see:

• references/evidence.md

Degrade And Stop Rules

Degrade

Degraded execution is allowed in the following cases:

• Missing message capability
• Missing Agent channel
• Missing some document metadata
• A certain channel supports only partial capabilities

When executing in degraded mode, you must clearly state:

• Which capabilities are missing
• What type of information may be lost

Stop

Stop execution only when basic factual judgment cannot be supported.

For example:

• No valid time range
• No available channels at all
• All channels are unable to provide readable evidence

When stopping, you must clearly state:

• Which channels or capabilities are currently missing
• Why the results are unreliable
• What environment or permissions need to be added to continue

Output Spec

For the output structure and template, see:

• references/output.md
• assets/report-template.md

Completion Checklist

• The date range is clear and correct
• At least two channel families have been collected, or it is clearly explained why execution can only be single-channel
• Evidence normalization has been completed
• Work topics have been extracted
• Each core piece of work is supported by at least two types of evidence, or insufficient evidence is clearly marked
• If message capability exists, a search has been attempted; if it failed, the reason has been explained
• The results can be sent directly without the user needing to manually supplement large sections of content