mcpField
S
session-guard

session-guard

github.com/wshobsonエージェントワークフロー41.9k2.9k 回インストール2 週間前に更新
リポジトリ

session-guard について

長時間のセッションで、コンテキストの欠落、ルールのずれ、作業範囲の拡大を監視する行動スキルです。ツール呼び出しの閾値、チェックポイント、ルールの再確認、引き継ぎを使い、パッケージやデータベースには依存しません。

主な機能

  1. 01ツール呼び出しの閾値を監視
  2. 02セッションのチェックポイントを作成
  3. 03重要なプロジェクト規則を再確認
  4. 04コンテキスト圧縮後に根拠を再読
  5. 05作業を分割して引き継ぎを準備

活用シーン

  1. 01ツール呼び出しの多いセッション管理
  2. 02圧縮後のプロジェクト規則の再確認
  3. 03判断の矛盾やスタイルのずれへの対応
  4. 04作業範囲が広がる際のタスク分割

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/wshobson/agents --skill session-guard

インストール後、Claude Code で/session-guardを入力して読み込まれたか確認します。

詳細

Session Guard

概要

長いセッションは静かに破綻します。コンテキストの圧縮は、予告なく指示を失わせます。フックでは修正できません（GitHub の issue #19471、#9796、#64171 で複数の開発者が確認済み）。このスキルは、行動規範の自己徹底によって両方を防ぎます。ヘルス状態を監視し、重要なルールを圧縮を越えて固定し、損傷が起きる前に分割します。パッケージもデータベースも不要 - あらゆるハーネスで機能する純粋な行動規範の徹底です。

使用する場面

  • セッションが 40 回のツール呼び出しを超えたとき
  • エージェントが以前の決定と矛盾したとき
  • スタイルや命名規則がずれ始めたとき
  • あらゆるコンテキスト圧縮イベントの後
  • タスクのスコープが無制限に膨らんでいるとき

ヘルスシグナル

シグナルしきい値アクション
ツール呼び出し回数>40YELLOW: チェックポイント + 重要ルールの復唱
ツール呼び出し回数>60RED: 分割またはアンカー付きで圧縮
エージェントが以前の決定と矛盾いずれでもVERIFY: 信頼できる情報源を再読する
スタイルや命名のずれいずれでもRECITE: 有効なルールを声に出して述べる
ファイル読み取りが予期しない内容を返すいずれでもRE-READ: キャッシュされた状態を信用しない
タスクのスコープが無制限に膨らんでいる継続的SPLIT: 1 セッションにつき 1 タスク

プロトコル

グリーンゾーン（0〜40 回のツール呼び出し）

通常操作。介入は不要です。

イエローゾーン（40〜60 回のツール呼び出し）
  1. CHECKPOINT - 進捗を 1 段落で要約します
  2. RECITE - 有効な最も重要な 3〜5 個のルールを声に出して述べます: 「有効なルール: [命名規則]、[ファイル構造]、[エラー処理パターン]、[テスト要件]」
  3. ASSESS - ほぼ完了していますか？ そのまま進めます。完了していませんか？ 分割を準備します。
  4. REDUCE - 探索的な読み取りはしません。対象を絞った操作のみです。
レッドゾーン（60 回以上のツール呼び出し、またはずれのシグナル）
  1. STOP - これ以上ツール呼び出しを行いません
  2. VERIFY - プロジェクトのルールを再読します（記憶を信用しないでください）
  3. CHECKPOINT - 状態を引き継ぎドキュメントに書き出します
  4. SPLIT - 引き継ぎを作成し、新しいセッションを提案します

コンテキストのアンカリング（圧縮対策）

圧縮が発生したとき（以前のコンテキストの突然の喪失、または /compact の後）:

  1. プロジェクトのルールファイルを直ちに再読します
  2. 応答内で最も重要な 3〜5 個のルールを声に出して復唱します
  3. 実行する前に、計画している次のアクションがそれらのルールに一致することを検証します
  4. 以前の決定について少しでも不確かなら、推測せずにソースファイルを再読します
圧縮を生き残るもの:
  • 直近のユーザーメッセージ（優先度が高い）
  • 現在呼び出されているスキルの本体（5K トークンで上限、古いものから順に破棄）
  • Git のステータスとプロジェクト構造
  • 圧縮後に読み取ったファイルの内容
圧縮で失われるもの:
  • 会話の早い段階で下された決定
  • 口頭でのみ述べられたアーキテクチャ上のルール（ファイルにないもの）
  • ツール出力からのコンテキスト（ファイル読み取り、コマンド出力）
圧縮に強いパターン

重要な指示は会話の中ではなく、ファイル（CLAUDE.md、CONTEXT.md）に置きます。ルールが重要なものであるなら、エージェントが再読できるファイルに存在しなければなりません - 以前に合意した何かの中ではなく。

よくある間違い

  • 50 回以上のツール呼び出しの後でもルールを覚えていると信じること（覚えていません - 再読してください）
  • 安全のためにすべてを再読すること（ツール呼び出しを浪費します - 対象を絞ってください）
  • 調子が良いからといってコンテキストも問題ないと想定すること（圧縮は静かに起きます）
  • 問題に気づいた後に分割すること（分割は前に行います - 復旧ではなく予防です）

これが重要な理由

コンテキスト圧縮は、2026 年における未解決のプラットフォーム問題の第 1 位です。フックでは修正できません（確認済み: 圧縮サマリーが物語の勢いを生み出すため、エージェントは圧縮後の注入を無視します）。このスキルは軽量な行動規範の対策です。インフラもパッケージも不要 - あらゆるハーネスで機能する、規律ある自己監視です。

コメント

Markdown 対応