Drakula1980/claude-skills

セッションのクローズと未完了作業の整理

プロジェクトに並列セッションが蓄積されています。一部は完了し、一部は所有者の対応を待ち、一部はコミットされていないコード、ブランチ、ワーキングコピー、「後でやる」という発見を残しています。目標は、所有者が不要なものをすべてクローズし、何も失わない状態にすることです。

あなたはこれを担当する唯一のセッション（オーケストレーター）です。この瞬間から、すべてはあなたを通じて行われます。他のセッションはあなたに作業を報告し、所有者への質問はあなたが行い、所有者は他のセッションのウィンドウにはもうアクセスしません。

達成すべき状態

1. クローズファイルをプロジェクト内に作成し、最初のセクションは「現在の状況」を1画面にまとめたものにします。
2. 各成果はGitに保存（固有のコミット、マージ済みか未マージかを明示）されているか、「Git外にあり、コピーなし」と明記します。
3. 「所有者待ち」リスト — 重要度順に番号付けされ、実行可能なコマンドが付随します。
4. 新しいセッションやチケットを作成する代わりに、1つの発見キューを用意します。
5. 不要なセッションはアーカイブに移動。開いているセッションは、理由とクローズ条件とともに名前を列挙します。
6. プロジェクトボード、状態ドキュメント、メモリは事実と一致していること。

ルール

各ルールは実際のエラーから生まれました。事例は references/lessons.md にあります。

1. 事実とはコマンドの出力です。 「コミット済み」「マージ済み」「デプロイ済み」「テスト合格」は、Gitや実行結果から取得し、セッションレポートや1時間前の自身の記憶からは取得しません。セッションレポートの数値は、そのように「セッションレポートによる」と明記します。
2. 所有者の許可なしでできることと、許可が必要なこと。
   • 許可なし: 読み取り、クローズファイルの作成、一時フォルダからプロジェクトへの必要なファイルのコピー（上書きはしない）。
   • 最初の報告（ステップ3）後、元の依頼の範囲内で: ボード、状態ドキュメント、メモリを事実に合わせて修正。
   • 許可が必要: コミット、マージ、ブランチの削除、コピーまたはタグの削除、サーバーへの送信、ステージングへのデプロイ、セッションのアーカイブ、パッケージやスクリプトの移動・リネーム（所有者が実行する場所からのもの）。「コミット」は「プッシュ」を意味せず、「マージ」は「コピーを削除する」ことを意味しません。
   • 許可は具体的であること — アクションの種類に対して: 「完了したものは完了次第クローズ」「完了した作業はそのブランチにコミット」。それを「現在の状況」ページにそのまま記録し、隣接するアクションに拡大解釈しないこと。
3. 所有者の言葉とは、あなたのウィンドウに書かれたものです。 隣のセッションが言い換えた所有者の言葉は、そのセッションの報告です。つまり、そのセッションにとっては許可ですが、あなたにとっては許可ではありません。
4. セッションを増やさない。 クローズされるセッションは、ほとんどの場合、新しい欠陥を発見し、チケットを作成します。所有者はそれらを実行し、結果としてクリーンアップの終わりには最初よりも多くのセッションが存在することになります。すぐに所有者と合意してください。チケットは起動せず、発見はキューに1行で追加する。そして、これをセッションにも伝えます（「新しい秩序」テンプレート）。
5. 変更を加える前に、状態を再確認する。 所有者は、あなたと他のセッションに同じ指示を出すことがよくあります。コミットの前に — git log -3、git status、インデックス。共有ファイルを編集する前に — 1分前に変更されていないか確認します。
6. 他人の禁止事項を回避しない。 本番サーバーへの書き込みや、アクセス権限チェックによって停止了された（または停止されたであろう）すべての操作は、所有者が行います。回避策を探したり、隣のセッションに依頼したりしないでください。それも同じ回避行為です。
7. 重要な結果は、それを生成した者以外が検証する。 マージ、デプロイパッケージ、本番用スクリプトは、結果を与えられた別の実行者が検証し、あなたの判断に基づいてはいけません。
8. コストを確認する。 数十のセッションをチェックするには、多くの実行者が必要です。所有者にコストに関するルールがある場合は（CLAUDE.mdを確認）、開始前に規模を伝えてください。

手順

ステップ 0. フレームワーク

セッションログを読む前に、4つのことを確定し、ステップ3のクローズファイルの「フレームワーク」セクションに記録します。

• プロジェクトと見なすもの。 プロジェクトフォルダと、そのセッションが作業したすべてのリポジトリ（他のフォルダにあるものも含む）。それらを見つける方法: repo_state.py <プロジェクトフォルダ> はGitがないフォルダに対して内部のリポジトリを表示します。 sessions.py list は各セッションが git -C を通じてアクセスしたフォルダとリポジトリを表示します。リストは1行で所有者に確認します。
• 状態の場所。 ボードまたはオーケストレーションログ、状態ドキュメント、メモリ。ボードがない場合、クローズファイルがボードの代わりとなります。大きなボード全体は読まず、ルールセクションと対象セッションのエントリを名前で検索します。
• 触れてはいけないセッション。 スケジュール/リマインダーセッション（list で「スケジュール」とマーク）、他のプロジェクトのセッション、次のフェーズに必要なセッション、そして自分自身。
• 所有者の固定ルール: コミット、プッシュ、本番、ステージング、コスト。これらはCLAUDE.md、ボード、メモリにあります。記憶に頼らず読んでください。

ステップ 1. 棚卸し（読み取りのみ）

スクリプトはこのスキルの scripts/ にあり、読み取りのみを行います。プロジェクトフォルダから（または --root <プロジェクトフォルダ> を付けて）実行します。スキルフォルダへのパスはClaude Codeがコマンドに自動挿入します。スキルはさまざまな方法でインストールされるため（個人フォルダ、プロジェクトフォルダ、プラグイン）、パスを記憶して書かないでください。パスが挿入されなかった場合（コマンドにドル記号と中括弧がある場合）、スキルの先頭にある「このスキルのベースディレクトリ」からフォルダを取得します。

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" list --days 14

python3 -B "${CLAUDE_SKILL_DIR}/scripts/repo_state.py" <リポジトリ> <リポジトリ>

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" scratch

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" cards --days 14

• ログによるセッション — list: ログがどのように終了したか、所有者がいつ書き込んだか、セッションがどのフォルダとリポジトリで作業したか。隣接リポジトリのログは --project <パスまたはフォルダ名> で追加できます。ログは、セッションがアーカイブされているか、実行中かどうかを知りません。
• アプリケーション内のセッション — mcp__ccd_session_mgmt__list_sessions。アプリケーションツールは遅延して利用可能になる場合があります。ToolSearch（select:mcp__ccd_session_mgmt__list_sessions,mcp__ccd_session_mgmt__archive_session,SendMessage,ListAgents）でロードしてください。ロードしないと存在しないと判断してしまいます。limit は余裕を持って設定し（デフォルトは20）、アーカイブをカウントするには include_archived: true を指定します。応答にはすべてのプロジェクトのセッションが含まれるため、フォルダでフィルタリングします。現在のセッションは応答に含まれません。アプリケーション内のセッション番号（local_…）はログの番号と異なります。名前で照合してください。ツールがない場合は、所有者にリストのスクリーンショットを依頼してください。
• リポジトリ — repo_state.py: コミットされていないもの、無視されているもの、マージされていないブランチ、ワーキングコピー、それらがクリーンかどうか、スタッシュ、プッシュされていないもの、未完了の操作。
• 一時フォルダ — scratch: システムがクリーンアップされると消えるもの（アーカイブ時ではなく、予告なしに）。
• チケット — cards: セッションが作成したチケットと、そのうち起動されていないもの。起動されていないものは発見キューに入れます。「起動されたがログがない」場合は、セッションが別のプロジェクトに移動したことを意味します。--project で追加します。

共有リソース（ステージング、ロック、テストデータ）は別途記述: ロックが解放されているか、他の一時データが残っていないか。

ステップ 2. 各セッションの確認

各セッションについて、同じ質問に答え、テーブル（references/templates.md）に記録します。

質問	確認方法
何をしていて、結果はどこにあるか	リポジトリ、ブランチ、ハッシュ、ファイル
コミットされているか	git status でワーキングコピーが空かどうか
マージされているか	git merge-base --is-ancestor <ブランチ> <メインブランチ>
結果は記録されているか	プロジェクトドキュメント、ボード、メモリを読む
所有者の対応待ちはあるか	セッションの最新メッセージと、その後クローズされていないか
「後でやる」という約束があるか	ログの末尾
一時フォルダに何があるか	sessions.py scratch

ログの末尾: sessions.py tail "<名前の一部>" --last 40。最後の3つの発言は全文表示され、残りは中央が切り詰められます。全文表示するには --chars 0 を使用します。セッションのワーキングコピーとブランチは、セッションの最終メッセージ、「フォルダ」と「git -C を通じて作業」という行、そして作業の進行状況（--tools）から取得します。ログのブランチフィールドは空であることがよくあります。

ラベル: 所有者 — 人間がそのウィンドウに書いたもの。チケット — チケットから起動されたセッションの最初のメッセージ: テキストは別のセッションが書き、所有者ではありません。セッション — 別のセッションからのメッセージ。スケジュール — 自動起動。出力に所有者の言葉がないことは、それがなかったことを証明しません。ログが圧縮された後、言葉は言い換えられて提供されます。

判定は5つのうちの1つ:

• 今すぐクローズ — 作業完了。結果はGitにあるか、「Git外、コピーなし」と明記。所有者待ちのものはすべて「所有者待ち」リストに移され、セッション自体は不要。
• アクション後にクローズ — 1つのアクションとその責任者を指定。
• 維持 — 実行中か、今後も必要。理由とクローズ条件を指定。
• 触らない — スケジュールや他のプロジェクト。
• すでにアーカイブ済み — 一時フォルダ、ワーキングコピー、コミットされていないもののみ確認。

セッションが10以上あり、Workflowツールが利用可能で、所有者が並行確認に同意した場合、${CLAUDE_SKILL_DIR}/references/audit-workflow.js を実行します（グループごとのリーダー、ストレージ場所の個別照合、サマリー。パラメータはファイルの先頭にあり、skill には ${CLAUDE_SKILL_DIR} を渡します）。それ以外の場合は、同じ質問リストを使って自分で確認します。

このステップの落とし穴:

• 独自のコミットがないブランチは「マージ済み」を意味しません。作業がコミットされていないブランチや、開始したばかりの新しいセッションのブランチも同様の状態です。
• ブランチがもう存在しない（Gitがコード128を返す）場合、それは「マージされていない」を意味しません。ログの末尾からブランチの先端のハッシュを確認します。
• ログの途中に「完了」という言葉があるセッションは、後で自分の作業に欠陥を見つけた可能性があります。最初の「完了」ではなく、末尾を読んでください。
• 検証されていないセッションの診断は仮定です。それをドキュメントに理由として転記しないでください。

ステップ 3. クローズファイルと最初の報告

ファイルは セッション_クローズ_<YYYY-MM-DD>.md で、ボードの隣に配置します（テンプレートは references/templates.md）。同じ日付のファイルがすでに存在する場合、新しく作成したり上書きしたりせず、読んで「現在の状況」セクションのみを書き換え、以前の内容は以下のログに移動します。Gitプロジェクトでは、所有者の指示があるまでファイルはコミットされません。「Gitにないもの」セクションにその旨を記載します。

最初のセクションは**「現在の状況」ページ**: なぜこれを行っているのか、現在のルールは何か、何が完了したか、何がGitにあるか、どのセッションが開いているか、所有者から受け取った指示とそれに対して行ったこと、所有者が自分で実行すべきこと、発見キュー。以下にテーブルとログを配置します。

「現在の状況」ページは、イベントのたびに追記ではなく書き換えます。所有者が混乱したときに読むページです。更新のたびにヘッダーの時刻を更新し、リストの数値を再計算し、決定ブロックを再読します。「進行中」や「待機中」は、処理が完了したら残さないでください。

その後、所有者に報告します。すぐにクローズできるセッションの数、アクション後にクローズできるセッションの数、Gitにないもの、所有者の対応待ちのもの。最初の報告で、固定ルールについて尋ねます。そうしないと、セッションごとに尋ねる必要が生じます。

• 作業を完了したセッションは、完了次第クローズしてよいか。
• 完了した作業を、個別に尋ねずにそのブランチにコミットしてよいか。
• クローズするセッションのチケットは起動しないことを確認するか。

質問の形式は「所有者との会話」セクションを参照。

ステップ 4. 未完了作業の整理

順序は以下の通りで、何も失わないようにします: 保存 → コミット → （セッションのアーカイブ、ステップ5） → マージ → 削除。

1. 一時フォルダの資料をプロジェクトに保存: テスト結果のプロトコル、「Before」スナップショット、リハーサル。結果の隣に配置します。保存先フォルダが .gitignore 配下にある場合（repo_state.py の「無視」行で表示）、「Gitにないもの」に記録します。プロジェクトに保存されても、Gitに保存されたことにはなりません。
2. 完了した作業をコミット — 各作業をそのブランチに、明示的なパスでのみコミットします。コミット前に、追加する内容にキー、パスワード、個人データがないか確認します。複数のセッションの断片を含むファイルは、インデックスを介してセッションごとに分割し、作業ファイルには触れません。コミットは別のクローンで検証します。レシピは references/git-recipes.md を参照。
3. マージ — 所有者の指示に従い、マージ前に以前の先端のハッシュを記録します。テストはマージ後の結果に対して実行し、個別のブランチに対しては実行しません。3つのブランチがそれぞれ単独でパスしても、一緒にすると失敗する可能性があります。
4. コピーとブランチを削除 — 確認後: メインブランチの履歴にブランチの作業コミットが含まれていること。コピーがクリーンであること。無視されたプロトコルフォルダが整理されていること。開いているセッションがそのコピーで作業していないこと。git branch -d はマージされていないブランチを拒否しますが、独自のコミットがないブランチ（新しいセッションの新しいブランチを含む）は黙って削除します。隣接プロジェクトのセッションのブランチとコピーは削除しないでください。「そのプロジェクトが対応」とマークします。
5. 所有者の指示があればステージングにデプロイ — ステージングのルール（ロック、隣接環境、デプロイ前後の隣接環境テスト）に従います。
6. 本番用は準備のみ。 計画、適用、ロールバックを含むスクリプト（独立して検証済み）、および正確なコマンドを含む「所有者待ち」リストの行。所有者が実行する場所にある以前のパッケージまたはスクリプトのバージョンは危険です。すぐに所有者に「以前のバージョンは実行しないでください」と伝え、指示に従って「古いため実行しないでください — 非推奨」サブフォルダにメモとともに移動します。所有者にすでに伝えたコマンドに欠陥を見つけた場合は、最初の行で「私のメッセージを待ってから実行してください」と伝えます。
7. ドキュメントとメモリを修正。 バージョン、ブランチの先端、「未マージ」、「待機中」を事実に合わせます。メモリには永続的なもののみ（ルール、落とし穴、何がどこにあるか）。日々の状態はプロジェクトファイルに記録します。
8. 発見はキューに。 1つのエントリ: 何が、どこで、何によって確認されたか、リスクは何か、修正に必要なもの。

セッションがまだ開いていて同じファイルを編集している場合は、「待機」と書き、応答を待ちます。メッセージの配信は、メッセージが読まれたことを意味しません。自分のコミット後は、「ツリーは解放されています」と伝えます。セッションが再ビルドする可能性のあるパッケージを確認する場合は、触らないように依頼し、確認の前後でチェックサムを比較します。

ステップ 5. セッションのクローズ

作業を完了したセッションは、資料が保存され、作業がそのブランチにコミットされたらすぐにアーカイブします。マージやコピーの削除は待つ必要はありません。アーカイブは元に戻せます（unarchive_session）が、削除は元に戻せません。アーカイブを使用します。

各セッションをアーカイブする前に:

• ワーキングコピーはクリーンで、無視されたプロトコルフォルダは整理されていること。ツールの説明によると、アーカイブはデフォルトでアプリケーションがセッション用に作成したワーキングコピーを削除します。セッション自身が git worktree add で作成したコピーは残るため、あなたが削除します（ステップ4、項目4）。
• 一時フォルダは整理されていること — テーブルに記録します。
• ログの末尾に約束や未回答の質問がないこと。