close-chat

/close-chat — チャット締めくくりスキル

目的

チャット内で発見・議論したが未対応のまま終わる項目を「宇宙に浮かせない」。 タスクだけでなく、思想・判断・学びも拾い切る。

Claude がバックログ候補と知識還流候補を提案し、ユーザーが承認した項目のみ記録する。

用語: 以下の「MEMORY.md」は全て auto-memory の MEMORY.md（~/.claude/projects/<project-slug>/memory/MEMORY.md）を指す。project-root の MEMORY.md は使わない（設計変更 ADR-0008 参照）。

手順

Step 1: 完了サマリ

このチャットで完了した作業を箇条書きで提示する。

完了した作業:
- （PR番号 or コミット hash と内容）

Step 1.5: 最新状態の取得

バックログ候補を抽出する前に、以下を実行して現在の実態を把握する。 会話冒頭の git status スナップショットは古くなっている可能性があるため、必ず最新を取る。

git status          # 未コミット変更の有無
git log --oneline -5  # 直近コミット（他チャットで進んだ作業の確認）

• チャット冒頭のスナップショットと差異がある場合、最新の結果を正とする
• 他チャットで既にコミット/マージ済みの項目は「完了済み」として Step 2 から除外する

Step 2: バックログ候補の抽出

チャット全体を振り返り、Step 1.5 の最新状態を踏まえて以下のカテゴリで未対応項目を抽出する。

抽出ルール:

• 完了済みのものは含めない
• 「次回でいい」と明示されたものはバックログに分類
• 「まだ決まっていない」は継続検討に分類
• ユーザーが「不要」と言ったものは抽出しない

Step 2.5: 知識還流チェック

チャット内で出た判断・思想・学びを振り返り、以下の3カテゴリに分類する。 これにより、タスク以外の知識がセッション終了時に消えることを防ぐ。

分類基準・抽出対象・抽出しないものの詳細は references/knowledge-reflux-guide.md を参照。

Step 3: ユーザーへの提示・確認

抽出した候補を以下のフォーマットで提示し、各項目の扱いをユーザーに確認する。

=== チャット締めくくり ===

完了:
- ...

バックログ候補（行き先 = backlog or Issue）:
  ※ 振り分け（intake routing・ADR-0022）: 他人が拾える / チームに見せたい / 具体的な作業単位 → **Issue** ／ 個人の次セッション用・working・未成形 → **backlog（既定）**
1. [ ] 内容（コンテキスト）［推奨: backlog or Issue］

継続検討候補:
1. [ ] 内容（未解決の論点）

ADR未記録の判断:
1. [ ] 判断内容 → /record-decision で記録できます

設計書未更新:（Notion連携プロジェクトの場合のみ表示）
1. [ ] 設計書名 + 変更内容

知識還流候補（思想・判断・学び）:
  OSS 還流候補（業界共通の判断軸 → sidekick OSS テンプレートへ手動 PR）:
  1. [ ] 内容 → OSS テンプレート (sidekick `brain/thinking.md`) のどのセクションに影響するか
  個人 brain 昇格候補（複数 PJ 横断の判断軸）:
  1. [ ] 内容 → 個人 brain (`~/.claude/brain/thinking.md`) への昇格候補
  PJ 固有（この PJ ドメイン依存）:
  1. [ ] 内容 → PJ brain (`<PJ>/.claude/brain/thinking.md`) への昇格 or feedback_*.md or ADR

─────────────────
各項目について「積む(backlog) / Issue化 / クローズ / 次回」を教えてください。
知識還流候補は「記録する/スキップ」で判断してください。

Step 4: 記録実行

ユーザーの確認後、承認された項目を実行する。

バックログへの追記

「積む」と判断された項目を MEMORY.md の ## Backlog セクションに追記する。

- [ ] 内容（コンテキスト。どのチャット・どの調査で浮かんだか）

追記ルール:

• 追記は Edit ツールで MEMORY.md の Backlog セクションに行う
• 既存のバックログ項目は削除しない（新規追記のみ）
• コンテキストは「次チャットでゼロから読んでも意味がわかる」程度に書く

Issue 起票（チーム/機能改善/bug/可視化したいもの）

「Issue化」と判断された項目を gh issue create（適切なテンプレ + ラベル）で起票する。

ルール（intake routing・ADR-0022・.claude/rules/task-management.md 参照）:

• backlog には積まない（1 アイテム＝1 ホーム・重複禁止）。
• 既に backlog にある項目を Issue へ昇格する場合は、backlog 側を削除し本文に Issue# を残す（feedback→brain と同じ昇格ラダー）。
• ユーザーが会話中に「これ Issue にして」と言った項目も、フルフロー（/discover）を通さず単発 gh issue create で起票してよい（casual 起票）。

ADR記録

「記録する」と判断された場合は /record-decision スキルを呼び出す。

知識還流の記録

承認された知識還流候補を、分類（.claude/docs/knowledge-reflux.md R7）に応じて還流タグ付きで記録する。手順は references/knowledge-reflux-guide.md の「記録アクション」に従う。

重要: 即座に brain ファイル（PJ brain / 個人 brain / OSS テンプレート）を更新しない。 フラグを立てるだけ。統合は棚卸し時にまとめてやる。 ただし、ユーザーが「今すぐ反映して」と言った場合はその場で実行する。

Step 5: Active Work の更新

このチャットで完了した Worktree があれば、MEMORY.md の Active Work のステータスを更新する。 （Worktree 運用プロジェクトの場合）

Step 5.5: CHANGELOG 整合性チェック

PR が main にマージされた場合、CHANGELOG.md に該当エントリがあるか確認する。

前提条件: CHANGELOG.md がリポジトリルートに存在する場合のみ実行。 存在しないプロジェクトはスキップ。

チェック手順:

1. 直近のマージコミット（git log --oneline main --merges -5）を取得
2. CHANGELOG.md の [Unreleased] セクションを読む
3. マージされた PR 内容が反映されているか確認

未反映の場合:

• ユーザーに「CHANGELOG に未反映のマージがあります。追記しますか？」と確認
• Yes なら [Unreleased] セクションに追記（Added / Changed / Fixed の適切なカテゴリ）
• No なら「次の /weekly-inventory または /release 時に反映」としてスキップ

Step 5.6: PII スキャン（公開ファイル変更時）

このセッションで docs/, README*, CHANGELOG.md, LICENSE, brain/, .claude/rules/, .claude/skills/, .github/ 配下を編集した場合、pii-prevention.md の scan_pii で個人情報の混入をチェックする。

実行条件: 上記ディレクトリの変更が（ステージ済 or 未ステージで）存在する場合のみ。なければスキップ。

# pii-prevention.md から scan_pii / scan_staged_public 関数を取り込む
source <(awk '/^```bash$/{flag=1; next} /^```$/{flag=0} flag' .claude/rules/pii-prevention.md)

# 未ステージ + ステージ済みの公開ファイルを対象
TARGETS=$(git status --porcelain | awk '{print $2}' | \
  grep -E '^(docs/|README|CHANGELOG|LICENSE|brain/|\.claude/rules/|\.claude/skills/|\.github/)' | \
  grep -v -E '(MEMORY\.md|CLAUDE\.local\.md|settings\.local\.json|\.data/|agent-memory-local/)')

[ -n "$TARGETS" ] && scan_pii $TARGETS

検出ありの場合: ユーザーに該当行を提示し「修正してから commit」を提案。Step 6 へ進む前に解消する。 検出なし or 対象ファイルなし: そのまま Step 6 へ。

oss-doc-authoring.md の書きぶり（時系列描写・出典なし言及・思考の揺れ）も該当ファイル種別なら併せて確認する。

ここまでが標準フロー。 外部DB連携がないプロジェクトではセッション終了してよい。

Step 6: 外部タスクDB同期（Layer 2 オプション）

前提条件: CLAUDE.md の NOTION_ENABLED が true、かつタスクDB連携の設定ファイル（.claude/rules/ 配下）が存在するプロジェクトのみ実行する。 該当しない場合はこのステップをスキップし、Step 5 で終了する。

Tasks DB（Notion）に自PJのタスクがあれば、以下を同期する。 MEMORY.md は「Claudeのローカル作業メモ」、Tasks DB は「オーナー向けの報告チャネル」。粒度と読者が異なるため並行運用する。

同期対象

• Doing → 完了した作業があれば Completion Note に記録、Status → Done
  • Sourceタグを確認し、該当する全DBを更新する
• 新しいブロッカーが発生 → Blocker Type/Detail を更新、Status → Waiting
• Waiting → ブロッカーが解消した場合 → Status → Todo or Doing に戻す
• 新規タスク投入（即時）: オーナーの判断が必要なものは 即座にタスクDBへ投入する
  • 投入基準: 「このまま放置すると次のセッションで作業が止まるか？」→ Yes なら即投入
  • 投入時のプロパティ: Status=Waiting, Blocker Type=該当するもの, Blocker Detail=具体的内容
  • オーナーの判断不要な細かいものは従来通り MEMORY.md Backlog に記録

同期しないもの

• MEMORY.md Backlog の細かい調査メモ・検討残（Claude内部の作業コンテキスト）
• オーナーの判断が不要な軽微な作業

Step 6.5: Notion 判断ログDB 同期（Layer 2 オプション、独立フラグ）

前提条件: CLAUDE.md の NOTION_JUDGMENT_SYNC が true、かつ NOTION_JUDGMENT_DB_URL が設定されている、かつ Notion MCP が接続済み。 いずれか欠けている場合はこのステップ全体をスキップする。

セッション中に出た設計判断・方針判断を Notion 判断ログDB に集約する（.claude/docs/task-db-layer2.md の「判断ログ同期」セクション参照）。

抽出

セッションの会話履歴から以下を抽出:

• 複数選択肢から1つを選んだ設計判断・方針判断・技術選定
• ADR化された判断も含む（Notion 側で横断閲覧するため）
• ADR化されなかった軽微な判断も含む（再利用可能な知見として記録するため）

除外:

• 単なる実装（「このファイルを編集した」）
• 調査結果・エラー解決の手順
• デバッグ中の試行錯誤

判断か実装かの境界が曖昧な場合はユーザーに確認してから登録する。

登録

NOTION_JUDGMENT_DB_URL のDBに以下スキーマで新規ページ作成:

冪等性

同じ判断を複数回送信しないため、各判断に決定的キーを付与して auto-memory に記録する:

• キー形式: <YYYY-MM-DDTHH:MM>-<タイトル先頭32文字の正規化ハッシュ>
  • 日時部分は判断がなされた時刻（分単位、ISO 8601）
  • タイトル先頭32文字を NFKC 正規化 → 空白圧縮 → SHA-1 先頭8桁
• 記録先: project_judgment_sync_<YYYYMMDD>.md（セッション日ごとにファイルを分ける）
• 重複判定: 次回 /close-chat 実行時、当日のファイルに同キーがあれば送信スキップ

失敗ハンドリング

• MCP 未接続・URL 不正・rate limit 超過 等の失敗時は、該当判断を「失敗リスト」として retain し、auto-memory に記録しない（次回再送対象とする）
• 部分失敗時もロールバックは行わない（Notion 側は追記型のため）
• 3回連続で失敗した場合はユーザーに報告してステップを中断する

センシティブ情報の除外

• コンテキスト/判断理由には接続文字列・認証情報・顧客固有名詞を含めない
• 下流PJ 固有のマスクルールがあれば .claude/rules/ に追記し、送信前に適用する

報告

登録件数・失敗件数・スキップ件数（冪等性による重複）をユーザーに報告する。

バックログの扱い（次チャット）

次チャット開始時に MEMORY.md が自動ロードされるため、Backlog セクションの項目は Claude が自動的に認識する。

ユーザーが「バックログ確認して」と言えば一覧を提示し、「これをやろう」となったタイミングで着手する。

バックログ項目が完了したら、MEMORY.md の対応行を削除する（チェックマークではなく削除）。

還流フラグの扱い

[OSS 還流候補] [個人 brain 昇格] [PJ 固有] のプレフィックス付き項目は、通常のバックログとは性質が異なる:

• 棚卸し時にまとめて処理する
• 個別に消化するのではなく、蓄積してからパターンを見てまとめて統合する
• 溜まりすぎた場合（5件以上）は、次回棚卸しを前倒しすることをユーザーに提案する

Gotchas

• Step 1.5 のスナップショット依存 — チャット冒頭の git status は古くなっている。特に長時間セッションや並行チャットがある場合、Step 1.5 で最新を取り直す前にバックログ候補を判断してはならない
• 知識還流の過剰抽出 — 「全ての判断を記録すべき」ではない。自明な判断（明らかな typo 修正など）や一時的なコンテキスト（デバッグ中の試行錯誤）は還流対象外。references/knowledge-reflux-guide.md の「抽出しないもの」を必ず参照する
• 外部DB同期の前提見落とし — .claude/rules/ に連携設定ファイルが存在しない PJ では Step 6 をスキップする。存在チェックなしに Notion API を呼ぶとエラーになる。また、設定ファイルがあっても Notion MCP が未接続の場合 は API コールが失敗する。MCP接続状態を先に確認すること
• 判断ログ同期フラグの混同 — NOTION_ENABLED（Tasks DB 連携）と NOTION_JUDGMENT_SYNC（判断ログDB 連携）は独立フラグ。Step 6 は前者、Step 6.5 は後者で制御する。片方だけ有効な PJ もあるので前提条件は個別に判定する（ADR-0012）
• 判断抽出の過剰 — 「全ての発言を判断として登録」は NG。複数選択肢から1つを選んだケースに限定する。境界が曖昧なら登録前にユーザー確認
• 判断ログ同期の部分失敗 — Step 6.5 で一部判断の Notion 登録が失敗してもロールバックしない（Notion は追記型）。失敗した判断は auto-memory に冪等性キーを記録せず、次回再送対象とする。3回連続失敗時はユーザー報告してステップ中断
• バックログ肥大化 — 「念のため積んでおく」を繰り返すと MEMORY.md が 200 行を超える。積む前に「次回のセッションで本当に必要か」を自問する

注意事項

• Claude が勝手に積まない: 必ずユーザーの確認を取る
• 積みすぎない: 重要度が低いものはクローズ推奨。バックログは「忘れたくないもの」に限定
• MEMORY.md の行数に注意: 過度に肥大化しないよう、定期的に古い完了項目を整理する
• 知識還流は「フラグを立てる」だけ: 即座の反映ではなく、棚卸し時にまとめて統合する設計。これにより各セッションの負荷を軽く保つ