context-surfing

コンテキストサーフィン

インストール

gh skill install pskoett/pskoett-skills context-surfing

Agent Skills CLI を使った代替方法：

npx skills add pskoett/pskoett-skills/skills/context-surfing

エージェントは、コンテキストがピークに達する波に乗ります。波が頂点に達したら、コミットします。ドリフトを検知したら、状態を保存して引き継ぎ、次のセッションが次の波に乗れるようにして、きれいに離脱します。

転倒も、ゾンビセッションもありません。意図的で、忠実度の高い実行だけです。

---

メンタルモデル

コンテキストを海の波のように考えてください。

• パドリング ＝ 意図の枠組み、計画、初期コンテキストの読み込みです。エネルギーが高まっていきます。
• ピーク ＝ コンテキストの一貫性が最大の状態です。エージェントは、何をしているのか、なぜそうしているのかを正確に把握しています。実行するのはこのタイミングです。
• ショルダー ＝ コンテキストが平坦になり始めた状態です。まだ乗れますが、出力の密度は下がっています。
• クローズアウト ＝ ドリフトです。矛盾、曖昧な言い回し、疑念、あるいは幻覚による詳細が現れます。転倒の危険がある状態です。

このスキルの役割は、波の状態が良い間は乗り続け、クローズアウトする前に離脱することです。

---

ライフサイクル上の位置づけ

[plan-interview (optional)] → [initial intent frame] → [session-context]
  → [finalize approach] → [context-surfing ACTIVE during execution]
  → [verify-gate] → [simplify-and-harden] → [self-improvement]

コンテキストサーフィンは、コンテキストへの負荷が無視できない作業に使う、任意の実行レイヤーです。タスクが大規模、長時間実行、複数セッションにまたがる場合、コンテキストの監視を明示的に求められた場合、または具体的なドリフトのリスクがある場合に限り、意図の記録から完了後のレビューまでの実行を支援します。

intent-framed-agent との関係

コンテキストサーフィンが有効な場合、実行中は両方のスキルが有効になります。それぞれ異なる失敗モードを監視します。

• intent-framed-agent は、スコープのドリフト、つまり「正しいことをしているか」を監視します。作業が明示された成果の範囲を外れたとき、構造化されたインテントチェックを発動します。
• context-surfing は、コンテキスト品質のドリフト、つまり「今も適切に実行できる状態か」を監視します。エージェント自身の一貫性が低下したとき（幻覚、矛盾、曖昧な言い回し）に発動します。

両者は相補的であり、重複するものではありません。エージェントはスコープから完全に逸脱していなくても、コンテキスト品質が低下することがあります（たとえば、正しい作業をしているのに、詳細を幻覚し始める場合）。逆に、コンテキスト品質が完璧でも、スコープから逸脱することがあります（エージェントが意図的に脇道を追う場合）。intent-framed-agent のインテントチェックは、context-surfing の波の監視と並行して発動し続けます。

優先順位ルール： 両方のスキルが同時に発動した場合（インテントチェックとドリフトによる離脱が同時に発生した場合）、context-surfing の離脱が優先されます。コンテキストが劣化するとスコープチェックの信頼性も低下するため、まずコンテキストの問題を解決し、次のセッションでスコープの監視を再開してください。

実行タイミングの分離： インテントチェックはスコープの境界で発動します。つまり、「新しい領域やファイルに触れる前、新しい論理単位の作業を始める前、現在の操作が本筋から外れていると感じたとき」です（intent-framed-agent/SKILL.md）。context-surfing のコミット前アンカーチェックは、副作用を伴う操作のタイミング、つまり特定のツール呼び出し、書き込み、コミット、コミット単位の出力の前に発動します。同じタイミングで両方を実行しないでください。インテントチェックが直前に発動し、問題なく解決した場合、同じ作業単位内で次に行う副作用を伴う操作に、新たなアンカーチェックは必要ありません。すでに意図を再確認しているためです。

フルパイプラインを使う場合

すべてのタスクで、パイプライン内のすべてのスキルが必要なわけではありません。タスクの複雑さに応じて、パイプラインの深さを調整してください。

タスクの種類	使用するスキル
些細な作業（名前の変更、誤字の修正）	なし — そのまま実行
小規模（限定的なバグ修正、単一ファイルの変更）	verify-gate + simplify-and-harden
中規模（既知の領域での機能追加、複数ファイル）	intent-framed-agent + session-context + verify-gate + simplify-and-harden
大規模（複雑なリファクタリング、新しいアーキテクチャ、未経験のコードベース）	フルパイプライン
長時間実行（複数セッションにまたがる、コンテキストへの負荷が高い）	context-surfing を重要なスキルとして含むフルパイプライン

この表は、正式なルーティング元である skill-pipeline のタスク分類に準拠しています。

迷ったときは、まず軽い構成から始めてください。タスクの途中でドリフトや品質上の問題に気づいたら、スキルを追加してください。

---

有効化

タスクが大規模または長時間にわたる場合、作業が複数のセッションにまたがる場合、ユーザーが明示的にコンテキストの監視を求めた場合、または具体的な挙動からドリフトのリスクが示される場合に、このスキルを有効化します。意図フレームと計画があるだけでは、有効化の十分な理由にはなりません。通常の中規模タスクでは自動的に有効化しないでください。

有効化時には、必要最小限の基準情報を読み込みます。

1. ユーザーの現在のタスクと直近のスコープ変更
2. 該当するエージェント指示ファイル
3. 存在する場合は、承認済みの意図フレームと計画
4. 作業を再開する場合は、以前の引き継ぎ情報
5. 利用可能な場合は、Entire の現在のセッション状態

意図フレームも計画も存在しない場合（単独モード）は、ユーザーの最初のタスク説明とプロジェクトのコンテキストファイルを組み合わせ、ウェーブの基準情報として使用します。これで十分です。このスキルは段階的に機能を縮小し、致命的に停止することはありません。

Entire CLI との統合

Entire CLI（github.com/entireio/cli）は、ドリフトチェックと引き継ぎファイルの外部の信頼できる情報源となる、永続的なセッション状態を提供します。

有効化時に Entire を検出します。

entire status 2>/dev/null

• コマンドが成功し、アクティブなホストアダプターが関連するライフサイクルイベントに対応している場合、Entire はフックを通じて、対応するイベントを受動的に記録します。entire status だけから、トランスクリプトやチェックポイントがすべて網羅されていると推測しないでください。利用可能な状態を確認し、ホストで対応していない範囲を明示的に記録するには、entire status と entire explain --session <id> を使用します。
• 利用できない場合、または失敗した場合は、理由を限定的に記録したうえで、任意の統合機能を利用できないものとして扱い、処理を続行します。代わりに、意図フレームと計画ファイルをウェーブの基準情報として使用します。任意のテレメトリーの失敗を、委任やポリシーによる拒否の理由にしないでください。また、インストールを繰り返し試したり、催促したりしないでください。

ウェーブの基準情報は、頭の中だけに保持するものではありません。利用可能な外部の永続的な成果物から構成されます。ドリフトチェックでは毎回、記憶から再構成するのではなく、それらの情報を直接読み取ります。

引き継ぎは学習シグナルになる

コンテキストサーフィングによるドリフト時の終了処理で引き継ぎファイルが作成されると、対応するホストアダプターが Entire 内の関連する Stop／SessionEnd イベントも記録する場合があります。定期実行時、learning-aggregator --deep は、実際に利用可能な範囲のトランスクリプトだけを読み取り、次の情報を抽出します。

• 引き継ぎを最もよく引き起こすドリフトシグナル → セッション設計上の潜在的な問題
• ドリフト時に終了したセッションと、正常に完了したセッションの数 → セッション健全性のベースライン
• ドリフト発生時に不足していたコンテキスト成果物 → プロジェクト指示ファイルへの追加候補

規則的なセクション見出しを含む構造化された引き継ぎファイル（.context-surfing/handoff-<slug>-<timestamp>.md）を使うと、解析可能になります。特別な対応は不要です。引き継ぎの形式を一貫させてください。

• 完全なパイプライン： 意図フレーム＋計画ファイル＋Entire CLI のセッション状態
• 部分的なパイプライン： 意図フレームまたは計画のうち、存在するものに加えて、該当する指示ファイル
• 単独モード： ユーザーの最初のタスク説明＋該当する指示ファイル

単独モードでは、照合に使える成果物が少ないため、基準情報は弱くなりますが、常に存在します。弱い基準情報でも、何もないよりは有用です。

---

プロジェクトのコンテキストファイル

実行前に、タスクに必要な最低限の常設コンテキストを特定します。デフォルトでは、ルートにあるすべての Markdown ファイルを調べたり読み込んだりしないでください。

有効化時に必ず読み込む

• AGENTS.md、CLAUDE.md、.github/copilot-instructions.md など、該当するエージェント指示ファイル
• ユーザーの現在のタスクと直近のスコープ変更
• 存在する場合は、承認済みの計画／意図の成果物
• 作業を再開する場合は、選択した引き継ぎファイル

必要に応じて読み込む（現在のタスクに関連する場合）

• プロジェクトの目的や構成を把握するための README.md
• アクティブな指示またはタスクで指定された特定のルート Markdown ファイル
• skills/、docs/、.learnings/ などのディレクトリ内にある .md ファイル
• このスキルと併せて使用するスキルの SKILL.md ファイル

コンテキストファイルのルール

1. コンテキストファイルは常にウェーブアンカーの一部です。 出力がプロジェクトの .md ファイルと矛盾する場合、それはドリフトの兆候であり、強い兆候として扱ってください。
2. タスクの分野や範囲が変わったら、再度読み直してください。 20ステップ前の内容を正しく覚えていると思い込まないでください。
3. 主要な制約を引き継ぎファイルに記載してください。 次のセッションでも再読み込みが必要です。どのファイルが有効だったか、セッション中に更新されたかどうかを記録してください。
4. セッション中に .md ファイルを変更した場合は、 引き継ぎファイルの「Modified Context Files」セクションに明記してください。そうすれば、次のセッションで引き継ぎの要約に頼らず、新たに読み直せます。

---

ドリフトの検出

以下の兆候がないか継続的に確認してください。強い兆候があれば即座に終了します。ウェーブは終了段階に入っています。弱い兆候があれば、まずリカバリープロトコルを実行してください。まだ立て直せる可能性があります。

これらの兆候は、出力だけでなく、自身の推論の連鎖にも当てはまります。テキストだけでなく、思考も確認してください。 ドリフトは、目に見える文章として現れる前に推論の過程で発生します。アンカーの役割は、出力後に監査するだけでなく、推論を制御することです。副作用を伴う操作の前に推論レベルで確認することは、操作後に出力レベルで確認するよりも厳密に上流の段階で行われます。

強い兆候（即座に終了）

• エージェントが、すでに決定し確定した内容と矛盾する
• エージェントがアンカーと矛盾する詳細を確定し、整合させられない
• エージェントが、計画で明確に解決済みの範囲に関する質問を再び持ち出す

弱い兆候（リカバリーを実行）

• 回答が長くなる一方で、有用性が高まらない
• 「場合によります」「〜かもしれません」「〜を検討するとよいでしょう」といった、曖昧な表現が増える
• ユーザーから明示的な指示がないのに、タスクの途中でエージェントが手法を切り替える
• 元の意図への言及が曖昧になったり、正確さを欠く言い換えになったりする
• すでに分かっているはずの答えについて、エージェントが確認の質問をする
• タスクを実行する代わりに、出力でタスクの説明を繰り返し始める
• 新しい、根拠のない詳細が現れ、アンカーに照らした確認が必要になる

ドリフトではないもの

• 範囲内で通常どおり反復や改善を行うこと
• 元のコンテキストにない、本当に新しい情報について尋ねること
• 以前の出力を簡潔にすること（それはウェーブが機能しているのであり、破綻しているわけではありません）

モニタリングのパラドックス

コンテキストが劣化したエージェントは、自身の劣化を検知できる可能性が最も低い存在です。強いシグナル（幻覚、矛盾）は、まさに侵害されたエージェントが見落とすものです。矛盾を認識するためのコンテキストを失っているからです。

これは自己モニタリングに固有の限界です。外部からの根拠付けによって軽減してください。

1. コミット前のアンカーチェック。 あらゆる副作用を伴うアクション（ファイルへの書き込み、コミット、状態を変更する外部ツールの呼び出し、ユーザーに見えるコミットレベルの出力）の前に、推論の流れの中で次の確認を行ってください。

   • 関連するアンカー行を、記憶からではなく、最新の読み込みからそのまま引用します。インテントフレームがある場合は、それを開いて引用します。プランファイルがある場合は、関連するセクションを引用します。スタンドアロンモードでは、ユーザーの元のタスク説明から引用します。
   • 実行予定のアクションを1行で述べます。
   • そのアクションが引用した行にさかのぼって関連付けられることを確認します。
   • 追跡可能性が不明確な場合は、ただ「停止」するのではなく、以下のリカバリープロトコルに進みます。次の分岐を明示しない「停止」は、最も手軽な方針に流れがちであり、通常は気付かれないまま作業を続けることになります。

   アンカーの可変性： セッション中にコンテキストファイルが変更された場合、コミット前チェックでは、アクティベーション時のスナップショットではなく、ファイルの最新バージョンを使用します。先入観なしに読み直してください。

2. 外部記憶としてEntire CLIのログを使う。 Entireが利用可能な場合、重要な判断を下す前に自身のセッションログを読み返してください。ログに記録された状態は、記憶している状態より信頼できます。

3. ユーザーをドリフトセンサーとして扱う。 ユーザーが混乱を示したり、「なぜそんなことをしているのですか？」と尋ねたり、別の方向へ誘導したりした場合は、自分自身の評価にかかわらず、強いシグナルとして扱ってください。

弱いシグナル（ためらい、冗長さ）は、事実ではなく行動に関するものだからこそ、自己検知の信頼性が高くなります。早期警告として、これらに注意してください。

リカバリープロトコル（波の再アンカー）

弱いシグナルが積み重なっても、すぐに終了せず、まずは再アンカーを試みてください。再び根拠を確認できるなら、波の肩に乗り続けることは可能です。

ステップ1：一時停止して読み直す

出力の生成を止めます。利用可能な波のアンカーとなる成果物を読み直してください。

1. インテントフレームがある場合は、それを開き、記憶に頼らずそのまま読みます
2. プランファイルがある場合は、開いて関連するセクションを読みます
3. スタンドアロンモードでは、ユーザーの元のタスク説明とプロジェクトのコンテキストファイルを読み直します
4. Entire CLIが利用可能な場合は、セッションログを読み返します

現在の作業内容と、これらの成果物に記載された作業内容を照らし合わせてください。

ステップ 2：整合性を確認する

• 不一致が解消した場合 — 起点から現在の作業まで明確につながりをたどれるなら、実行を再開します。弱い兆候はドリフトではなく、単なるノイズでした。
• 不確実さが残る場合 — ユーザーにエスカレーションする前に、コールドコンテキストでのセカンドオピニオンとして context-monitor サブエージェントを起動します。（context-monitor はプラグインバンドル内の plugin/agents/context-monitor.md で定義されています。環境で利用できない場合は、同じ概要を渡して汎用の読み取り専用サブエージェントを起動してください。）意図の枠組み（または計画、または元のタスクの説明）、現在の次のアクション、確認した具体的な弱い兆候を伝えます。新しいコンテキストのサブエージェントは、モニタリングのパラドックスから抜け出す唯一の確実な方法です。自分で読み返すと、劣化している可能性のある同じコンテキスト内での作業になりますが、context-monitor は成果物を予備知識のない状態で読み取ります。
• context-monitor が「healthy」または「weak signals only」と返した場合 — その修正を反映して、実行を再開します。
• context-monitor が「strong drift detected」と返した場合、または報告を受けても整合性を確認できない場合 — ユーザーにエスカレーションします。状況を率直に伝えてください。「ドリフトが起きているようです。現在の状況と計画上の状況は次のとおりです。context-monitor の調査結果は次のとおりです。どのように進めればよいでしょうか？」
• ユーザーが再度軌道に戻してくれた場合 — その説明を反映して、実行を再開します。再アンカーに成功しました。
• ユーザーも解決できない場合、または元の意図が根本的に変わった場合 — Exit Protocol に進みます。

再アンカーの上限

同じドリフトの発生について、ローカルでの再アンカーは最大 1 回、コールドコンテキストでの確認は最大 1 回までとします。解決しない場合は、エスカレーションするか終了してください。強い兆候がある場合は復旧を省略し、ただちに終了します。

---

波に乗る

コンテキストが健全な間は、次のようにします。

1. 確信を持って実行します。 ためらったり、すでに決定した内容を蒸し返したりしません。計画どおりに進めます。
2. 副作用を伴う操作の前に、コミット前アンカーチェックを実施します。 手順については「モニタリングのパラドックス」セクションを参照してください（逐語的に引用 → 保留中のアクションを述べる → 遡って確認する → 失敗した場合は「停止」するだけでなく、Recovery Protocol に入る）。このチェックは実行中のコンテキスト品質を判定する主要なゲートであり、あれば望ましい程度のものではありません。スコープレベルのチェックは intent-framed-agent の役割であり、異なる境界で実行されます（頻度の違いについては「intent-framed-agent との関係」を参照してください）。
3. 完了状況を記録します。 終了時ではなく、作業の進行に合わせて完了済み、進行中、保留中の項目を記録します。Entire CLI が利用できる場合は、セッションログとして使用します。利用できない場合は、出力内で状況を継続的に記録します。必要に応じて、これが引き継ぎに使われます。
4. スコープの拡大を避けます。 興味深くてもスコープ外の内容が出てきた場合は、メモ（Entire CLI または出力内）にとどめ、追いかけないでください。

---

Exit Protocol（波の終了処理）

強い兆候が現れた場合、または Recovery Protocol で再アンカーに失敗した場合は、適切に終了します。無理に続行しないでください。

ステップ 1：実行を停止する

ただちにタスクの実行を一時停止します。劣化したコンテキストによって損なわれる可能性のある出力を、これ以上生成しないでください。

ステップ 2：引き継ぎファイルを作成する

.context-surfing/handoff-[slug]-[timestamp].md という名前のファイルを作成します（.context-surfing/ ディレクトリが存在しない場合は作成します）。.context-surfing/ を .gitignore に追加します。引き継ぎファイルはセッションの成果物であり、プロジェクトの履歴ではありません。

構成：

# Context Surf Handoff

## Session Info
- Task: [task name / slug]
- Started: [timestamp]
- Ended: [timestamp]
- Exit reason: [what drift signal was detected]

## Intent Frame (if available — read verbatim, do not reconstruct)
[copy directly from the intent-framed-agent artifact, or "N/A — standalone session" if none exists]

## Plan (if available — read verbatim, do not reconstruct)
[copy directly from the plan-interview artifact, or "N/A — standalone session" if none exists]

## Original Task Description (standalone fallback)
[copy the user's original task description if no intent frame or plan exists]

## Completed Work (from Entire CLI session state or running output log)
[pull directly from CLI log or structured output — do not reconstruct from memory]

## In Progress at Exit (from Entire CLI session state or running output log)
[what the session log shows as active at the moment of exit]
[include any partial outputs if useful]

## Pending Work (from plan-interview output — cross-reference session log to confirm what's genuinely not done)
[remaining tasks from the plan, in order]

## Drift Notes
[what specifically triggered the exit — be precise, this helps the next session replan intelligently]

## Active Context Files
[list all .md files loaded during this session — root level and any skill/docs files consulted]

## Modified Context Files
[any .md files that were changed during this session — next session must re-read these, not trust the handoff summary]

## Scope Notes (Out-of-Band)
[anything interesting discovered that's outside scope — flagged for the next session to decide on]

## Recommended Re-entry Point
[where the next session should pick up, and any replanning it should do before continuing]

ステップ 3：ユーザーに通知する

簡潔かつ明確に伝えます。

「コンテキストの波が終了しました。セッションの状態を .context-surfing/[filename] に保存しました。次のセッションでは、このファイルを読み込んで [再開地点] から再開してください。引き継ぎに未解決の要件や重要なスコープ変更が記録されている場合に限り、計画を立て直してください。終了のきっかけは次のとおりです：[ドリフトの兆候を 1 文で記載]。」

詳しく説明しすぎないでください。詳細は引き継ぎファイルに記載されています。

---

次のセッションへの引き継ぎ

次のセッションでは、以下を行います。

1. ほかの作業を始める前に、引き継ぎファイルを最後まで読みます
2. 引き継ぎファイルで承認済みの計画と意図フレームが完全な状態で変更されていないことが確認できた場合は、それらを再利用します
3. plan-interview を実行するのは、引き継ぎファイルに未解決の要件、重大なスコープ変更、または無効になった計画が記録されている場合のみです
4. スタンドアロンモードでは、タスクの説明とドリフトに関するメモをもとに、改めて方向性を確認します
5. 推奨される再開ポイントから再開します
6. 再開が成功した後にのみ、引き継ぎを消費済みとしてマークします

これは失敗ではありません。システムが正しく機能しているということです。きれいに終了するほうが、ゾンビのように力なくゴールまで進むセッションよりも、全体的な成果が向上します。

---

セッション終了（通常完了）

健全なウェーブ内でタスクが完了した場合（ドリフトによる終了が不要な場合）は、以下を行います。

1. 計画の項目がすべて完了していることを確認します（スタンドアロンモードでは、元のタスクの説明が満たされていることを確認します）
2. 簡潔な要約にセッション終了を記録します（任意。完全な引き継ぎファイルを作成する必要はありません）
3. 簡素化と堅牢化の準備ができたことを通知します。パイプラインの次のスキルがここから引き継ぎます

問題なく完了した場合、引き継ぎファイルは不要です。成果物と一行のステータスだけで十分です。

---

他のスキルとの相互運用

このスキルが受け取るもの

• plan-interview から（任意）： 計画ファイル（docs/plans/plan-NNN-<slug>.md）。利用可能な場合、ウェーブの基準を強化します。
• intent-framed-agent から（任意）： 意図フレームの成果物。利用可能な場合、ウェーブの基準を強化します。
• ユーザーから（常に利用可能）： 元のタスクの説明。上流の成果物がない場合、スタンドアロンのウェーブ基準として使用します。
• Entire CLI から（任意）： 進捗の追跡と外部メモリに使用するセッション状態。

このスキルが生成するもの

• simplify-and-harden 向け： 通常完了時の「準備完了」シグナル。simplify-and-harden は完了した作業を引き継ぎます。
• 次のセッション向け（ドリフトによる終了時）： セッションを再開するための完全な状態を含む、.context-surfing/ 内の引き継ぎファイル。
• 自己改善向け： セッション中に観察されたドリフトのパターンが再発する場合、学びとして記録できます。

パイプライン内の位置

1. plan-interview（任意。要件の整理用）
2. intent-framed-agent（初期実行契約とスコープドリフトの監視）
3. session-context（アプローチを確定する前に、前のセッションの証拠を確認）
4. context-surfing（大規模、長時間実行、または明示的にコンテキストが重要な実行における、任意のコンテキスト品質監視）
5. verify-gate（機械的な検証：コンパイル＋テスト＋リンティング）
6. simplify-and-harden（完了後の品質／セキュリティ確認）
7. self-improvement（再発するパターンを記録し、永続的なルールに反映）

---

フックとの統合

セッション開始時に引き継ぎを自動検出できるようにします。これにより、以前のコンテキスト終了時に作成された引き継ぎファイルが、気付かれないまま無視されることを防ぎます。

セットアップ（Claude Code）

.claude/settings.json に追加します。コマンドのパスは、スキルのインストール先に合わせます（gh skill install／npx skills add の場合は .claude/skills/context-surfing/、このリポジトリにベンダーとして含めている場合は skills/context-surfing/。プラグインバンドルでは ${CLAUDE_PLUGIN_ROOT} パスを使って、このフックが自動登録されます）。

{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "${CLAUDE_PROJECT_DIR}/.claude/skills/context-surfing/scripts/handoff-checker.sh"
      }]
    }]
  }
}

Codex CLI は <repo>/.codex/hooks.json を介して同じ SessionStart イベントをサポートします（試験的機能で、config.toml の codex_hooks = true によって有効になります）。ここでも、スクリプトの標準出力は開発者コンテキストに追加されます。

これはセッション開始時に .context-surfing/ 内の保留中の引き継ぎファイルを確認します。 再開が成功したら、隣接する handoff-<slug>-<timestamp>.md.consumed マーカーを作成して、今後のセッションで 同じリマインダーが繰り返されないようにします。このマーカーは、すでに 無視対象となっている .context-surfing/ ディレクトリ内のセッション状態です。

Copilot／チャットでの代替手順

フックに対応していないエージェントでは、セッション開始時に手動で確認します。

ls .context-surfing/handoff-*.md 2>/dev/null

---

原則

波の頂点に乗り、海全体に乗り続けないこと。 忠実度の高い短いセッションのほうが、徐々に破損していく長いセッションより優れています。

終了は失敗ではありません。 波のクローズアウトは機能の一つです。それを早期に検知することがスキルです。

引き継ぎファイルが継続性を保ちます。 これはドキュメント作成の余計な負担ではありません。次のセッションを、今回の開始時と同じように鋭くするものです。

終了を決して隠さないでください。 コンテキストの終了が発生したことと、その理由を必ずユーザーにはっきり伝えてください。劣化したコンテキストで黙って続けるのが、最悪の結果です。