weekly-digests

週次ダイジェスト

プロジェクトの claude-mem の全履歴をもとに、連続する複数章の物語形式のダイジェストを作成します。timeline-report（1つの長いレポート）とは異なり、ISO 週ごとに1つのダイジェストを生成します。各サブエージェントは、物語の一貫性を保つため、前週の引き継ぎブロックを読み込みます。

章の数は、タイムラインが対象とする ISO 週の数と同じです。 2週間分のデータがあるプロジェクトなら2章、30週間分なら30章を作成します。長さは固定されていません。まず週数を数え、その数に応じてパイプラインを実行してください。

使用するタイミング

ユーザーから次のような依頼があった場合に実行します。

• 「週次ダイジェスト」
• 「週ごとのストーリー」
• 「連続するタイムライン」
• 「[project] のストーリーの各章」
• 「週ごとにダイジェストを実行」
• 「週ごとにストーリーを続ける」

プロジェクト全体をまとめた単一のレポートを求めている場合は、代わりに timeline-report を使用してください。このスキルは、連続した章形式の出力向けです。

前提条件

• claude-mem ワーカーが実行中であること
• プロジェクトに少なくとも1 ISO 週分の観測データがあること（パイプラインは適切に縮退するため、N=1 でも動作します）
• ユーザーが書き込みに同意した、空の出力ディレクトリ

ワーカーポートを解決します（一度だけ実行し、$WORKER_PORT を再利用してください）。

WORKER_PORT="${CLAUDE_MEM_WORKER_PORT:-$(node -e "const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}" 2>/dev/null)}"

ワークフロー

ステップ 1：プロジェクト名を特定する

timeline-report と同じワークツリー検出パターンを使用します。ワークツリー内では、データソースは親プロジェクトです。

git_dir=$(git rev-parse --git-dir 2>/dev/null)
git_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)
if [ "$git_dir" != "$git_common_dir" ]; then
  parent_project=$(basename "$(dirname "$git_common_dir")")
else
  parent_project=$(basename "$PWD")
fi
echo "$parent_project"

ステップ 2：タイムライン全体を取得して保存する

mkdir -p .scratch
curl -s "http://localhost:${WORKER_PORT}/api/context/inject?project=PROJECT_NAME&full=true" \
  > .scratch/cm-timeline.md
wc -l .scratch/cm-timeline.md

簡易チェックとして、ファイルが空でないことと、想定される構造になっていることを確認します（冒頭部分、その後に ### Mon DD, YYYY のような日付見出し、<id> <time> <emoji> <title> 形式の数値付き観測行、S<n> <prompt> (Mon DD at HH:MMpm) 形式のセッション境界行）。

ステップ 3：タイムラインを ISO 週ごとのファイルに分割する

次の処理を行う Python スクリプトを .scratch/split-timeline.py に作成します。

1. 日付見出し（### Mon DD, YYYY）を解析します。
2. date.isocalendar() を使用して日付を ISO 週（月曜始まり）ごとにグループ化します。
3. 各日のセクションをそのまま保持し、週ごとに1つのファイルを docs/timeline-weeks/<YYYY>-W<NN>-<MonDD>-to-<MonDD>.md に出力します。
4. 二重パスの簡易チェックを実行します。分配された観測データの合計が、ソースファイル内の件数と一致していることを確認します。

出力構造（ファイル名は例です）。

docs/timeline-weeks/
  README.md                       # weekly index table
  YYYY-W<NN>-MonDD-to-MonDD.md    # one per ISO week the timeline covers
  ...

各週のファイルでは、元の日ごとのセクションをそのまま保持してください。この段階では言い換えないでください。ダイジェストエージェントには、忠実な生データが必要です。

パイプラインを開始する前に、生成されたファイル数を数えてください。その数が TOTAL となり、以降の各ステップで使用されます。データのある週の間にある空の週（観測データがゼロの週）は除外してください。パイプラインはデータのある週のみを対象とします。

ステップ 4：週次インデックス README を作成する

docs/timeline-weeks/README.md に、Week | Dates | Observations | Sessions | File の列を持つ Markdown テーブルを作成します。これは担当者用のロードマップとなり、エージェントが週ごとのペース配分（ピーク週と閑散週）を把握するのに役立ちます。

ステップ 5：連続したサブエージェントパイプラインを実行する

重要：サブエージェントは並列ではなく、順番に実行します。 各エージェントには、前のエージェントの引き継ぎブロックを渡します。これがこのスキルの要点です。これがなければ、互いに無関係な N 個の要約になります。これがあれば、N 章からなる連続した物語になります。

出力ディレクトリを作成します。

mkdir -p docs/timeline-weeks/digests

各週について、時系列順に、次のプロンプトテンプレートを使用して Task サブエージェント（汎用）を起動します。次のエージェントを起動する前に、現在のエージェントが完了するまで待ちます。 結果から引き継ぎブロックを取得し、次のプロンプトの STORY_SO_FAR に挿入します。

サブエージェントのプロンプトテンプレート

You are writing chapter {N} of {TOTAL} in a serial week-by-week digest of the {PROJECT} project's development history. Chapters 1 through {N-1} are written. {SPECIAL_NOTE: e.g. "This is the LARGEST week", "This is the TROUGH", "This is the FINAL chapter", "This is the ONLY chapter — both first AND final week"}.

**Source file (read in full):**
{ABSOLUTE_PATH_TO_WEEK_FILE}

**Output digest file (write):**
{ABSOLUTE_PATH_TO_DIGEST_FILE}

**Format key for the source file:**
- Numeric lines like `1 7:59p 🔵 Save hook file is empty` are observations (ID, time, type-emoji, title)
- `S##` lines are session boundaries (the user prompt that started the session)
- Emoji legend: 🎯session 🔴bugfix 🟣feature 🔄refactor ✅change 🔵discovery ⚖️decision 🚨security_alert 🔐security_note 🤫sensitive

**Story so far (carry-forward from Week {N-1}):**

{STORY_SO_FAR_BLOCK_OR_EMPTY_FOR_WEEK_1}

**Your digest must include:**
1. **Title line** — `# Week {N} ({WEEK_LABEL}): {DATE_RANGE} — [your chosen subtitle]`
2. **One-line tagline** — what this week is about, in plain English
3. **Narrative section** ({BUDGET}) — tell the story. Resolve threads from prior weeks where the data shows resolution. Introduce new arcs. Use specific observation details.
4. **Threads continued / opened / resolved** sections
5. **Cliffhanger / What's next**
6. **Carry-forward block** at the very bottom, fenced as ```carry-forward ... ``` — structured handoff for the next week's agent.

**CARRY-FORWARD DISCIPLINE:**
- Cap at ~350 words.
- AGGRESSIVELY PRUNE: drop arcs that didn't surface this week unless they're actively unresolved cliffhangers.
- Drop cast members absent 2+ weeks unless load-bearing for the long arc.
- Quality over completeness. The next agent inherits what you mention; mention judiciously.

Required carry-forward sub-sections:
- **Active arcs** — ongoing themes/projects the next agent should watch for
- **Cast** — notable named systems/people/tools (continuing + new)
- **Unresolved** — open questions or unfinished work
- **Tone notes** — how the story is being told (voice, perspective, register evolution)

**Tone rules:**
- Third-person narrator, sharp, observational. Not twee.
- AI is "Claude"; human is "{USER_FIRST_NAME}".
- Treat codebase components as characters — whatever the project's recurring named systems are (e.g. a worker, a queue, a process manager, a recurring bug, a flaky migration). Don't import names from another project; use what shows up in this project's observations.
- Don't manufacture drama. Name what's there.
- Track the user's prompt-register evolution week by week (frustration markers, escalation language, shifts in tone).
- Note meta-recursion if the project is reflexive about its own behavior (e.g. a tool that documents its own work, an AI agent debugging itself, a system that catches its own regressions).
- Watch for new villains or co-stars and name them.
- For trough/silent weeks: silence IS the story. Don't pad. Name what didn't happen.
- For surge weeks (>2,000 obs): pick 4-7 spine arcs and tell them well. Don't catalog.

**Important:** Do NOT speculate beyond what's in the source file.

After writing the file, return:
1. Path of the file you wrote
2. The carry-forward block verbatim
3. One-sentence summary of the week

観測件数に応じた物語の分量

その週のデータ量に比例して、物語の長さを調整します。

観測件数	物語セクションの分量
< 100	200～400語
100～500	300～600語
500～1,500	500～900語
1,500～3,000	700～1,100語
3,000+	800～1,300語

各週のプロンプトの {BUDGET} に、上記の分量を設定してください。

最初の週

第 1 週では、空の STORY_SO_FAR_BLOCK を渡し、起点となる章であることを伝える指示を添えます。エージェントには、以降のすべての章に向けて、登場人物、トーン、全員の物語の軌跡を最初に確立してもらいます。

最終週

最終週では、締めくくり方を変えます。引き継ぎブロックは含めません。代わりに、執筆時点で未解決のことを挙げる ## Where We Are セクション（約 250 語）を書くようエージェントに指示します。プロジェクトは進行中であり、ダイジェストは終わっても、物語は終わらないことを伝えます。物語を偽りの結末で終わらせないでください。

N = 1 の場合（1 週間のプロジェクト）

同じ章に両方の処理を適用します。空の STORY_SO_FAR_BLOCK を渡し、引き継ぎブロックの代わりに ## Where We Are を記載します。エージェントは起点と締めくくりの両方を一度に書きます。存在しない過去や未来の章に言及しないでください。

ステップ 6：ファイル名を並べ替え可能な形式に変更する

エージェントは YYYY-W<NN>-digest.md のような名前でダイジェストを書き出します。プロジェクト名の中で年をまたがない限り、これらは ISO 週に基づいてすでに時系列順に並びますが、ディレクトリを閲覧したりスクリプトで処理したりする人にも順序が明確になるよう、ゼロ埋めした数値の接頭辞を追加します。

cd docs/timeline-weeks/digests
total=$(ls *.md | wc -l | tr -d ' ')
width=${#total}                  # 1 for N<10, 2 for N<100, 3 for N<1000
[ "$width" -lt 2 ] && width=2    # always pad to at least 2 for readability
i=0
for f in *.md; do
  printf -v prefix "%0${width}d" $i
  mv "$f" "${prefix}-$f"
  i=$((i+1))
done

N=30 の場合：00-...md から 29-...md。N=4 の場合：00-...md から 03-...md。N=120 の場合：000-...md から 119-...md。必ずゼロ埋めしてください。ゼロ埋めしないと、1-...md と 10-...md は正しく並びません。

ダイジェスト内のタイトル行にも順序番号を追加してはいけません。ファイル名の接頭辞は並べ替え用です。タイトルはシンプルなままにします：# Week N (W##): Date — Subtitle。

ステップ 7：完了を報告する

ユーザーに次の内容を伝えます：

• ダイジェスト化した週の合計数（N）
• 出力ディレクトリのパス
• 対象期間
• 注意すべき、活動の少ない週や谷間の週
• 物語の展開を要約する一文の総括。最終章のエージェントが書いたもの、または最終エージェントの ## Where We Are セクションをもとにオペレーターが作成したもの。

パイプラインの運用規律

これらのルールはパイプラインを最初から最後まで実行する中で得られました。毎回、必ず適用してください。

1. 並列ではなく、逐次実行する。 引き継ぎの連鎖こそが重要です。並列処理では連鎖が崩れます。
2. 引き継ぎの内容は制限する。 積極的に整理しないと、どんどん肥大化します。すべてのエージェントに、約 350 語を上限とし、休止中の筋書きや不在の登場人物は削除するよう伝えます。
3. 文体の変化を明示的に追跡する。 週ごとのユーザーのプロンプトのスタイルも、物語の展開の一部です。苛立ちを示す表現は、プロジェクトのデータに応じて時とともに変化します。その変化を明記します。
4. コンポーネントを登場人物として扱う。 観察内容に繰り返し登場する名前付きシステムは、このプロジェクトの敵役や共演者です。週をまたいで登場人物を安定させることで、物語に一貫性が生まれます。
5. 沈黙を尊重する。 谷間の週（観察数 10～100 件）も、実際の章です。起きなかったことを明記します。内容を水増ししないでください。
6. ドラマを作り出さない。 データをそのまま観察します。プロジェクトが再帰的なら、その再帰性自体がドラマです。さらに付け加える必要はありません。
7. 最終週に偽りの結末をつけない。 ダイジェストは終わっても、プロジェクトは終わりません。「これで終わり」ではなく、## Where We Are を書きます。

エラー処理

• タイムラインが空の場合：プロジェクト名が間違っているか、ワーカーが実行されていません。次のコマンドで確認します：curl -s "http://localhost:${WORKER_PORT}/api/search?query=*&limit=1"
• ワーカーが実行されていない場合：通常の方法で起動するか、ps aux | grep worker-service を確認します。
• サブエージェントの引き継ぎ内容の形式が不正な場合：正規表現（```carry-forward ... ```）で引き継ぎブロックを抽出し、そのまま次に渡します。見つからない場合は、エージェントに「返信の最後に、carry-forward ... で囲んだ引き継ぎブロックを必ず含めてください」と明示して再試行を依頼します。
• パイプラインの途中でエージェントが失敗した場合：同じ引き継ぎ内容を使って、その週を再試行します。スキップしてはいけません。連鎖が崩れます。
• 引き継ぎ内容が約 500 語を超えて増え続ける場合：以降のプロンプトで運用規律に関する指示を強化します。明示的に内容を削るよう求めます。

例

長期にわたるプロジェクト（約30週間）

ユーザー：「[project] の開始から終了まで、週ごとのダイジェストを作成してください」

1. ワーカーポートを特定し、プロジェクト名を検出します。
2. タイムライン全体を取得して、.scratch/cm-timeline.md に保存します。
3. .scratch/split-timeline.py を実行し、docs/timeline-weeks/ に N 個の週次ファイルを作成します（例：30 個）。
4. docs/timeline-weeks/README.md のインデックスを生成します。
5. 週ごとに1つずつ、N 個のサブエージェントを順番に起動します。それぞれに、前週から引き継ぐ内容を渡します。最初の章では引き継ぎ内容を空にし、最終章では引き継ぎブロックの代わりに ## Where We Are を記述します。
6. ダイジェストのファイル名の先頭に、ゼロ埋めした順序番号を付けます（00-...md から 29-...md まで）。
7. 章の総数、期間、谷やピークの有無、最終エージェントが作成した締めくくりの一文を報告します。

短期間のプロジェクト（約3週間）

同じ手順ですが、規模は小さくなります。N=3 のため、次のようになります。

• 第1章：引き継ぎ内容を空にし、登場人物、語調、展開を確立します。
• 第2章：第1章の引き継ぎ内容を受け取り、それを発展させます。
• 第3章：第2章の引き継ぎ内容を受け取りますが、最終章の扱いを適用し、引き継ぎブロックの代わりに ## Where We Are を記述します。
• ファイル名：00-...md、01-...md、02-...md。

1週間のプロジェクト（N=1）

唯一の章に、最初と最後の章の両方の扱いを適用します。引き継ぎ内容は空にし、締めくくりに ## Where We Are を記述し、章間の参照は含めません。ファイル名は 00-...md とします。