weekly-report

週報

目的

このスキルは、そのまま送信できる業務週報を作成するためのものです。

週報の主な目的は次のとおりです。

1. 対象期間における主な業務テーマを説明する
2. 各業務に対応する根拠の出典を示す
3. 完了、進行中、予定待ち、議論のみを区別する
4. 協業に関するコミュニケーションの要点を再現する
5. 事実と一致する翌週の計画を提示する

以下の条件を満たせない場合、この週報は完成したとはみなされません。

成功基準

適切な週報は、次の条件を満たす必要があります。

1. 対象期間が明確で正確である
2. 週報の本文が「業務テーマ」ごとに構成されている
3. 各主要業務に少なくとも2種類の根拠がある、または根拠が不足していることが明記されている
4. 事実と推論が分けて記述されている
5. ユーザーが背景情報を大幅に手作業で補うことなく、そのまま送信できる

時間の扱い

デフォルトルール

• ユーザーが「今週の週報」と明示した場合：
  • 今週の月曜日から今日まで
• ユーザーが「今週」と明示していない場合：
  • デフォルトでは先週の月曜日から日曜日まで

明示的な指定ルール

• 今週：今週の月曜日から今日まで
• 先週：先週の月曜日から日曜日まで
• 3月24日の週：その日を含む暦週。月曜日から日曜日まで

必須の動作

情報の収集を始める前に、絶対日付で対象期間を示す必要があります。「今週」や「先週」とだけ記載してはいけません。

例：

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

基本モデル

Channel

Channel は、個別に接続できる情報ソースを表します。

各チャンネルは、次のいずれかの channel_family に属する必要があります。

• collab_platform
• git
• agent
• local_docs

各チャンネルは、自身が提供する機能のみを宣言し、週報の構成は決定しません。

Capability

Capability は、チャンネルが提供できる具体的な収集機能を表します。

次の機能名を使用することを推奨します。

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

Evidence

Evidence は、正規化済みの根拠オブジェクトを表します。

各根拠には、可能な限り次の情報を含める必要があります。

• source_family
• source_channel
• evidence_type
• title
• summary
• timestamp または時間範囲
• actors
• project_or_topic
• url_or_path
• confidence

よく使われる evidence_type：

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

Work Topic

Work Topic は、同じプロジェクト、機能、特別プロジェクト、または目標を中心にまとめた業務テーマを表します。

各業務テーマでは、少なくとも次の点に答える必要があります。

• この業務は何か
• 現在の状態はどうか
• 重要な結論は何か
• どの根拠に基づいているか
• 翌週も引き続き進めるか

パイプライン

ステップ1：対象期間を確定する

まず対象期間を解析してから、情報の収集を開始します。

週の範囲を安定して計算する必要がある場合は、次を優先して使用します。

• scripts/resolve_week_range.py

スクリプトの説明は次を参照してください。

• references/time.md

ステップ2：チャンネルを検出する

現在の環境で利用可能なチャンネルを確認します。

1. 協業プラットフォームチャンネル
2. Git チャンネル
3. Agent チャンネル
4. ローカルドキュメントチャンネル

検出されたチャンネルのみを対象に、以降の情報収集を続けます。

ステップ3：機能を確認する

検出された各チャンネルについて、利用可能な機能を確認します。

例：

• 協業プラットフォームは calendar、docs_search、message_search に対応している場合があります
• Git チャンネルは git_history に対応している場合があります
• Agent チャンネルは agent_history に対応している場合があります

一部の機能にしか対応していないチャンネルでも、処理を続行できます。

ステップ4：生の事実を収集する

チャンネルごとに並行して生の情報を収集します。次の情報を優先して収集します。

1. 協業プラットフォーム上の会議、議事録、ドキュメント、メッセージ
2. Git の履歴
3. Agent の履歴
4. ローカルドキュメントとエクスポートファイル

ステップ5：根拠を正規化する

生の結果を統一された Evidence に整理します。

正規化後は、少なくとも次の観点で集約できる必要があります。

• 時間
• プロジェクト／テーマ
• 人物
• 根拠の種類
• 出典チャンネル

ステップ6：候補となるテーマを抽出する

情報量の多い内容から、候補となる業務テーマを優先的に抽出します。

• Git コミットのテーマ
• ドキュメントのタイトルと概要
• 会議のタイトルと議事録の要約
• メッセージ内の頻出キーワード
• Agent のタスク目標

ステップ7：業務テーマにまとめる

テーマごとに根拠をまとめて Work Topic を作成し、次の点を判断します。

• これらの根拠は同じ業務を示しているか
• 現在の状態は、完了、進行中、予定待ち、議論のみのいずれか
• どの結論を週報の本文に含められるか

ステップ8：テーマを検証する

各業務テーマについて、複数の根拠を使った検証をできる限り行います。

優先して検証する組み合わせ：

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

ある業務について根拠の出典が1種類しかない場合：

• まず根拠を追加で探します
• 根拠を追加できない場合は、信頼度を下げます
• 結果に根拠不足であることを明記します

ステップ9：週報を作成する

最終的な週報は業務テーマごとに構成し、プラットフォームやチャンネルごとに生データを列挙しません。

実装リファレンス

プラットフォームやチャンネルの実装詳細をこのファイルに詰め込まず、必要に応じて次を参照してください。

• 協業プラットフォーム Lark / 飛書：references/lark.md
• Git チャンネル：references/git.md
• Agent チャンネル：references/agent.md
• ローカルドキュメントチャンネル：references/local-docs.md

チャンネルの契約

Channel Contract は、新しいプラットフォームをこのスキルに接続する方法を定めます。

メインドキュメントには契約への入口のみを記載し、具体的なフィールド要件と縮退動作については、次を参照してください。

• references/channel-contract.md

根拠のルール

根拠のルールは、根拠の優先順位、信頼度の判断、記述上の制約を定めます。

具体的なルールは次を参照してください。

• references/evidence.md

縮退と停止のルール

縮退

次の場合は、縮退して実行できます。

• メッセージ機能がない
• Agent チャンネルがない
• ドキュメントのメタデータが一部欠けている
• いずれかのチャンネルが一部の機能にしか対応していない

縮退して実行する場合は、次の点を明確に説明する必要があります。

• どの機能が不足しているか
• どの種類の情報が失われる可能性があるか

停止

基本的な事実判断を裏付けられない場合に限り、処理を停止します。

例：

• 有効な対象期間がない
• 利用可能なチャンネルがない
• すべてのチャンネルから読み取り可能な根拠を取得できない

停止する場合は、次の点を明確に説明する必要があります。

• 現在どのチャンネルまたは機能が不足しているか
• 結果が信頼できない理由
• 続行するために必要な環境や権限

出力仕様

出力構成とテンプレートは次を参照してください。

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

完了チェックリスト

• 日付の範囲が明確で正確である
• 少なくとも2つのチャンネルファミリーから情報を収集した、または1つのチャンネルのみで実行する理由を明記した
• 根拠の正規化を完了した
• 業務テーマを抽出した
• 各主要業務に少なくとも2種類の根拠がある、または根拠不足であることを明記した
• メッセージ機能がある場合は検索を試み、失敗した場合は理由を説明した
• ユーザーが内容を大幅に手作業で補うことなく、そのまま送信できる結果である