digest

指定期間（デフォルト直近7日間）に動きのあったアクティビティ・決定事項・成果物をdomainごとに俯瞰するダイジェストを生成する。ユーザーに期間内の動きを伝えることがゴール。読み取り専用skillであり、記録・更新は一切行わない。

「最近何やったっけ」「今週のまとめ」「ここ数日の動きを見せて」「先週から何が決まった？」など、期間ベースの振り返り・俯瞰の依頼で使う。

手順

1. 期間の決定

引数や会話中の期間表現があれば最優先で使う。

• 「今週」→ 今週月曜日 〜 今日
• 「ここ3日」「直近3日」→ 3日前 〜 今日
• 「先週から」→ 先週月曜日 〜 今日
• 「先月から」→ 先月1日 〜 今日

期間表現が無ければ、デフォルトの上限を直近7日間（today - 7日 〜 today）とした上で、文脈量に応じて短縮するか判定する。

1. get_activities(status="active", since=today-7日, limit=1)とget_activities(status="completed", since=today-7日, limit=1)のtotal_countを合算し、直近7日間で動いたアクティビティ数を確認する
2. 合算値が15件を超える場合は直近3日間に短縮する。超えない場合は7日間のまま使う（＝「7日」と「文脈量に応じた短縮後の期間」のうち短い方を採用する）
3. 実際に採用した期間（7日間 or 3日間）とその理由（短縮した場合は「直近7日間はN件と多いため直近3日間に絞った」）を出力冒頭に明記する

以降のsinceはISO日付文字列（YYYY-MM-DD）として扱う。

2. データ取得

get_activitiesとget_timelineのみを使う。record系ツール（add_*/update_*/retract等）は呼ばない。

1. get_activities(status="active", since={期間開始日}, limit=50) で期間内に更新された進行中・保留中のアクティビティを取得する。返り値のtotal_countが取得件数を超えていたらlimitを引き上げて再取得し、期間内の対象を取りこぼさないようにする（get_activitiesにoffset/カーソル等のページネーション手段は無く、取れる手段はlimit引き上げのみ）
2. get_activities(status="completed", since={期間開始日}, limit=50) で期間内に更新のあった（updated_at基準）完了アクティビティを取得する。1と同様にtotal_countと突き合わせてlimitを引き上げて再取得する
3. 1・2で取得した各アクティビティのid_raw（get_activitiesは整数idをid_rawとして返す。返り値にidキー自体は含まれない）を使い、get_timeline(activity_id={id_raw}, entity_types=["decision","log","material"], order="desc") を呼び、紐づくdecision/log/materialを取得する
   • アクティビティ数が多い期間（active＋completed合計で20件超）では、この呼び出しがアクティビティ数に比例して増え応答が遅くなる。その場合はupdated_at降順で直近20件のみget_timelineを呼び出し、超過分はタイトルのみで一覧化して「他N件は詳細省略」と明記する（応答性を優先し全件深掘りはしない）
   • get_timelineに期間指定引数は無い。デフォルトlimit=50・最大100。order="desc"（新しい順）で取得し、created_atが期間開始日より古いitemが現れた時点で以降は全て期間外なので打ち切ってよい
   • 取得件数がlimitに達してもまだ期間開始日まで遡れていない場合は、最後のitemのcreated_atをbeforeカーソルに指定して追加ページを取得する（silent truncation防止）。ただしbeforeはcreated_atへの厳密な<比較のため、ページ境界と同一created_at（同秒）の未取得itemがあった場合はそのitemを取りこぼす可能性がある。本skillは概観目的の読み取り専用skillであり、この境界ケースでの完全性までは保証しない
   • activity_id指定時は関連する全topicのエンティティを集約して返すため、そのアクティビティに紐づく決定・ログ・成果物を漏れなく拾える

アクティビティに紐づかない独立トピックの決定事項は本skillの収集対象外（アクティビティ起点の集約のため）。該当topicの深掘りを求められたらget_timeline(topic_id=...)へ誘導する。

3. グルーピング

• 各アクティビティのtagsからdomain:タグを抽出し、domainごとにアクティビティをまとめる
• domainタグが無いアクティビティは「未分類」として最後にまとめる
• 複数アクティビティが同一topicを共有していると同一decision/log/materialが複数回取得されることがある。出力前にid_raw（無ければtitle）で重複排除する
• decisionは以下の順で分類する:
  1. replaced_byが設定されている（＝supersede済み）decisionは「決まったこと」から除外するか、「上書き済み」と明記して提示する。期間内の方針転換で古くなった決定を最新のように見せない
  2. titleが[議論中]で始まるものは「継続中の論点」に分類する（[未完]はactivity側のプレフィックスでありdecisionには付与されないため判定対象にしない）
  3. 上記以外は「決まったこと」に分類する
• 各domain内では、アクティビティごとに収集したdecision/log/materialを種別（decision/log/material）で整理する

4. 出力

以下の構成でユーザーに提示する。該当がないセクションは丸ごと省略する。

digest: {期間の説明}（{開始日} 〜 {終了日}）

## {domain名}
### 動いたアクティビティ
- [完了] {activity.title}
- [進行中] {activity.title}

### 決まったこと
- {decision.title}（{紐づくactivity名}）

### 継続中の論点
- {[議論中]decision.title}

### 保存された成果物
- {material.title}

• domainが複数ある場合はdomainごとに上記ブロックを繰り返す
• 全体の量が多い場合はdomainごとの件数・要点のみ提示し、詳細はユーザーが指名したdomain/activityだけ展開する

注意

• 読み取り専用skill。add_*/update_*/retract等の記録・更新系ツールは一切呼ばない
• ユーザーへの提示はタイトルベースで行い、内部ID（id_rawなど）は表示しない
• 量が多い場合はdomainごとの要約を優先し、詳細はユーザーが指名したものだけ展開する

関連skillとの境界

• 単一アクティビティに絞った再開・進捗把握はcheck-inの担当。digestは複数アクティビティを期間横断で俯瞰する
• 完了アクティビティ1件を深掘りして教訓を抽出するのはpostmortemの担当。digestは俯瞰に留まり深掘りしない
• 記録から外部共有可能なドキュメントを生成するのはscribeの担当。digestはその場での提示のみで、ドキュメント成果物は作らない