Weekly Report

Purpose

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

The core objectives of the weekly report are:

Explain the core work topics within the target time range
Explain the evidence source corresponding to each work
Distinguish between completed, in progress, to be scheduled, and only discussed
Restore the key points of collaborative communication
Provide next week's plans consistent with the facts

Success Criteria

A qualified weekly report must meet the following requirements:

The time range is clear and correct
The main body of the weekly report is organized by "work topics"
Each core work has at least two types of evidence support, or is clearly marked as insufficient evidence
Factual content and inferred content are expressed separately
Users can send it directly without manually adding a large section of background

If the above points are not met, this weekly report is not considered complete.

Time Semantics

Default Rule

Users explicitly say "本周周报": take the period from this Monday to the current date
Users do not explicitly say "本周": the default is from last Monday to last Sunday

Explicit Rule

```
本周
```
: Monday of the current week to the current date
```
上周
```
: Monday of last week to Sunday of last week
```
3月24日那周
```
: The natural week containing the specified date, ranging from Monday to Sunday

Required Behavior

Before starting collection, you must first output the absolute date range, not just "本周" or "上周".

Example:

text

本次周报范围：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 independently accessible information source.

Each channel should belong to a

channel_family

```
collab_platform
```
```
git
```
```
agent
```
```
local_docs
```

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

Capability

Capability

represents the specific collection capability that a channel can provide.

These capability names are recommended:

```
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 try to include at least:

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

Common

evidence_type

```
meeting
```
```
meeting_notes
```
```
doc
```
```
message
```
```
commit
```
```
agent_session
```
```
file_metadata
```

Work Topic

Work Topic

represents a group of work topics merged around the same project, function, special project or goal.

Each work topic should answer at least:

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

Pipeline

Step 1: Resolve Time Range

Parse the time range first, then start collection.

If you need to calculate the week range stably, use first:

```
scripts/resolve_week_range.py
```

For script instructions, see:

```
references/time.md
```

Step 2: Discover Channels

Check which channels are available in the current environment:

Collaboration platform channel
Git channel
Agent channel
Local document channel

Only continue to collect data for discovered channels.

Step 3: Inspect Capabilities

For each discovered channel, confirm its available capabilities.

For example:

Collaboration platform may support
```
calendar
```
,
```
docs_search
```
,
```
message_search
```
Git channel may support
```
git_history
```
Agent channel may support
```
agent_history
```

When the channel only has partial capabilities, execution is still allowed to continue.

Step 4: Collect Raw Facts

Collect original information in parallel by channel, priority collection:

Meetings, minutes, documents, messages in the collaboration platform
Git history
Agent history
Local documents and exported files

Step 5: Normalize Evidence

Organize the original results into unified

Evidence

After normalization, it should support aggregation at least by the following dimensions:

Time
Project / Topic
Person
Evidence type
Source channel

Step 6: Extract Candidate Topics

Extract candidate work topics from high-signal content first:

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

Step 7: Merge Into Work Topics

Merge evidence into

Work Topic

by theme, and judge:

Whether these evidence point to the same work
Whether the current status is completed, in progress, to be scheduled or only discussed
Which conclusions can be included in the main body of the weekly report

Step 8: Validate Topics

Each work topic should try to complete cross-evidence verification.

Priority verification combinations:

```
meeting
```
+
```
doc
```
```
doc
```
+
```
commit
```
```
commit
```
+
```
agent_session
```
```
message
```
+
```
meeting
```
/
```
doc
```

If a work only hits a single evidence source:

Try to supplement evidence first
If evidence cannot be supplemented, reduce the confidence
Clearly indicate insufficient evidence in the results

Step 9: Write The Report

Organize the final weekly report by work topics, do not list raw data by platform or channel.

Implementation References

Do not pile up platform or channel implementation details in this file, read 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

is used to standardize how a new platform accesses this skill.

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

```
references/channel-contract.md
```

Evidence Rules

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

For specific rules see:

```
references/evidence.md
```

Degrade And Stop Rules

Degrade

The following situations allow degraded execution:

Lack of message capability
Lack of Agent channel
Lack of part of document metadata
A channel only supports partial capabilities

When performing degraded execution, you must clearly explain:

What capabilities are missing
What type of information may be lost

Stop

Execution is stopped only when basic fact judgment cannot be supported.