specstory-session-summary

コンテキスト

最近の SpecStory セッション履歴ファイルを分析し、スタンドアップ形式の要約を提供します。

指定された引数：$ARGUMENTS（デフォルト：5 セッション。「today」の場合は今日のセッションのみ）

タスク

ステップ 1：最近のセッションを見つける

まず、SpecStory の履歴フォルダーがあるか確認し、最近のセッションファイルを一覧表示します。

ls -t .specstory/history/*.md 2>/dev/null | head -20

.specstory/history フォルダーが存在しない場合、または空の場合は、次のように応答します。

このディレクトリに SpecStory のセッション履歴が見つかりません。

SpecStory は AI コーディングセッションを自動的に保存し、後から参照できるようにします。セッションの記録を開始するには、https://specstory.com から SpecStory をインストールしてください。

その後、停止してください。残りのステップには進まないでください。

セッションが見つかった場合は、分析を続けます。引数が「today」の場合は今日の日付で絞り込みます。それ以外の場合は、指定された数（デフォルトは 5）を使用します。

ステップ 2：各セッションを読み取り、分析する

セッションファイルは非常に大きく、複数のユーザーリクエストが含まれている場合があります。次の分割読み取り方法を使用してください。

ステップ 2a：セッションの構成を把握する

まず、すべてのユーザーメッセージマーカーを grep し、セッションの範囲を確認します。

grep -n "_\*\*User\*\*_" <file> | head -10

これにより、ユーザーメッセージの行番号が表示され、次の点を把握できます。

• 個別のリクエストがいくつあったか
• 各リクエストのコンテキストをどこで読むべきか

ステップ 2b：構成に応じて効率的に読む

1. 冒頭（最初の 500 行） — offset=0, limit=500 で読み取ります

   • 貼り付けられたコードやログが含まれていても、最初のリクエストを把握できます
   • 初期のアシスタントの応答から、どのように対応したか分かる場合もあります

2. 末尾（最後の 300 行） — Bash で tail -300 <file> を使用します

   • 最終的な結果と結論が含まれています
   • タスクが完了したか、保留のままかを確認できます

3. ファイル操作 — 変更内容を grep します。

   grep -E "(Edit|Write)\(" <file>
   

ステップ 2c：複数のリクエストがあるセッションの場合

ステップ 2a の grep で、離れた行番号（例：50、800、1500 行目）に複数のユーザーメッセージがある場合、個別のタスクが複数あったことを示しています。このようなセッションでは、次のようにします。

• 各ユーザーメッセージの行番号の前後を読み取ります（例：offset=795, limit=100）
• 最初のタスクだけでなく、主なタスクを 2～3 件要約します

次の情報を抽出します。

1. 目標：_**User**_ ブロックからユーザーのリクエストを抽出します
   • 単一タスクのセッション：主な目標を 1 つ
   • 複数タスクのセッション：主要なタスクを 2～3 件列挙
2. 結果：会話の末尾から判断します
   • ✅ 完了 — タスクが正常に完了
   • 📚 調査 — 情報収集のみで、コード変更なし
   • 🔧 進行中 — 作業を開始したが、セッション終了時点で未完了
   • ❌ 中止 — ユーザーが方針を変えた、または断念した
   • 🚧 停滞 — 解決していないエラーや障害が残った状態で終了
3. ファイル：Edit／Write ツールの使用から変更されたファイルを抽出します（ファイル名のみ）
4. 主な決定事項：会話の中から次の内容を探します
   • 明示的な選択（「～することにした」「～を選んだ」「～の代わりに」）
   • トレードオフについての議論
   • アーキテクチャや設計に関する結論

ステップ 3：出力形式

各セッションを次の形式で提示します。

### {YYYY-MM-DD HH:MM} - {Brief Title from Main Goal}
**Goal**: {1 sentence summarizing what user wanted}
**Outcome**: {emoji} {Brief result description}
**Files**: {comma-separated list, or "None" if research only}
**Key insight**: {Notable decision or learning, if any}

複数タスクのセッションでは、形式を調整します。

### {YYYY-MM-DD HH:MM} - {Overall Theme or Primary Task}
**Tasks**:
  1. {First task} - {outcome emoji}
  2. {Second task} - {outcome emoji}
**Files**: {comma-separated list}
**Key insight**: {Notable decision or learning, if any}

ステップ 4：要約セクション

すべてのセッションの後に、次を追加します。

---
**Patterns**: {Note any recurring themes, files touched multiple times, ongoing work}
**Unfinished**: {Any sessions that ended with TODOs, blockers, or incomplete work}

ガイドライン

• 各セッションの要約は最大 5～6 行にしてください（複数タスクのセッションでは多少長くてもかまいません）
• タイトルはファイル名ではなく、ユーザーの目標から推測してください
• ファイルを記載する場合は、フルパスではなくファイル名のみを優先してください
• 実質的な作業を伴わない、簡単な質問だけのセッションは省略してください
• 複数タスクのセッションでは、主要なタスクを最大 3 件要約し、軽微なタスクは「細かな修正いくつか」としてまとめてください
• 簡潔にしてください。詳細なドキュメントではなく、日々の簡単な振り返り用です
• ファイルの読み取りに失敗した場合や大きすぎる場合は、抽出できる情報をもとに作業し、セッション全体を省略しないでください

出力例

## Session Summary (Last 3 Sessions)

### 2025-10-18 11:42 - Investigate Chat CRDT Storage
**Goal**: Understand why chat index CRDT doesn't contain the thread
**Outcome**: 📚 Explained dual storage design for offline/online sync
**Files**: threads.json, crdt-debug/4X/, crdt-debug/aT/
**Key insight**: Two storage layers (CRDT + JSON) serve different sync scenarios

### 2025-10-18 11:09 - Address Code Review Comments
**Goal**: Fix clarity issues from code review
**Outcome**: ✅ Refactored normalizeChatIndexDoc function
**Files**: chat.go, automerge-bridge.js
**Key insight**: Replaced complex normalization with toPlainString helper

### 2025-10-11 14:30 - Automerge Architecture Deep Dive
**Goal**: Document how Automerge docs are constructed temporally
**Outcome**: 📚 Research complete, walkthrough provided
**Files**: automerge-bridge.js, document.go (read only)

---
**Patterns**: 3 sessions focused on CRDT/chat subsystem; automerge-bridge.js touched repeatedly
**Unfinished**: None detected