ce-pickup は何をしますか?
過去のHermesセッションから ce-handoff/v1 ドキュメントをローカルモデルで抽出します。フロンティアトークンコストはゼロ。出力は標準の ce-handoff/v1 Markdown形式なので、/ce-handoff resume <path> で即座に再開できます。
冷えたセッションで /ce-handoff を実行してサブスクリプション枠を消費してキャッチアップする代わりに、こちらを使用してください。
使用するタイミング
- ユーザーが未完了のセッションを再開したいが、再度読み込むためにフロンティアトークンを使いたくない場合
- 過去の1つ以上のセッションからハンドオフが必要だが、コンテキストウィンドウがすでに一杯の場合
- ユーザーが古いセッションの「ピックアップ」や「キャッチアップ」を依頼した場合
- 大規模なコールドセッションで
/ce-handoffを実行するとコストがかかる場合
クイックスタート
bash ~/.hermes/scripts/ce-pickup.sh セッションID[,セッションID,...]
デフォルトでは /tmp/compound-engineering-$(id -u)/ce-pickup/ に出力されます。
その後、任意の出力ファイルから再開できます:
/ce-handoff resume /tmp/compound-engineering-<uid>/ce-pickup/<スラッグ>.md
引数
- 引数1(必須):カンマ区切りのセッションID(
session_searchまたはHermesブラウズから) - 引数2(オプション):Ollamaモデル名 — デフォルトは
hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF:Q5_K_M - 引数3(オプション):出力ディレクトリの上書き
環境変数による上書き(テストや別ホスト用):CE_PICKUP_DB(デフォルト ~/.hermes/state.db)、CE_PICKUP_OLLAMA_URL(デフォルト http://localhost:11434/api/chat)、CE_PICKUP_MAX_CHARS(デフォルト 24000)。
モデルルーティング
デフォルト:Ornith-1.5-35B-A3B-GGUF:Q5_K_M — 抽出品質が確認されており、ローカルで動作します。
Ornithがロードされていない場合でも、有能なローカルOllamaモデルが動作します。フロンティアモデルは使用しないでください(目的に反します)。
利用可能なモデルを確認:ollama list
仕組み
sqlite3で~/.hermes/state.dbを読み取り — PythonやTCCプロンプトは不要- タイムスタンプ順に
user+assistantメッセージを抽出 - トランスクリプトを24000文字(約6000トークン)に切り詰め — 意味のある抽出には十分
- 構造化された抽出プロンプトを用いて
curlでOllamaの/api/chatを呼び出し ce-handoff/v1フロントマターとモデルボディを出力ディレクトリに書き込み- ファイル名はセッションタイトルのスラッグ化、衝突時は数値サフィックス
出力形式
すべての出力ファイルは有効な ce-handoff/v1 であり、以下を含みます:
artifact_contract: "ce-handoff/v1"フロントマターsession_id、cwd、branch、repository(利用可能な場合)- 対象範囲:目標、完了作業、現在の状態、決定事項/制約、障害、失敗したアプローチ、参照、次のステップ
コンテキスト天井ウォッチドッグ(コンパニオン)
scripts/context-ceiling-watchdog.sh は、ライブセッションコンテキストを監視する決定論的でエージェント不要のモニターです。各ライブセッションの現在のコンテキストを推定し(active=1 メッセージの文字数 ÷ 4文字/トークン — 累積請求量を含むコンテキスト再読み込みを示す sessions.input_tokens は決して使用しない)、以下の閾値を強制します:
>= 50kREMIND — 1行のナッジ、1時間ごとに繰り返し>= 70kALERT — チェックポイント警告、30分ごとに繰り返し>= 80kEXTRACT — ce-pickupをローカルで実行し、ce-handoff/v1パスを報告。抽出後は、セッションがさらに約10k上昇した場合のみ再警告(CRIT)
閾値が発火しない限りサイレント(空の標準出力)であるため、変更検出付きのエージェント不要のcronジョブに直接組み込めます。状態は ~/.cache/context-ceiling-watchdog/ に保存されます(フラットTSV — LLMメモリや再帰的な継続性はなし)。Hermesの設定やランタイム状態に書き込むことはなく、state.dbはsqlite3の -readonly で開かれます。
実際のモデルなしでテストするには:bash scripts/mock-ollama.sh 21143 & を実行し、bash scripts/test-watchdog.sh(フィクスチャDB + スケーリングされた閾値、20回チェック)を実行します。
落とし穴
PythonからのTCCダイアログ(macOS Sequoia+):広範な権限を持つアプリのサブプロセスとしてPythonを実行すると、iCloud DriveやDocumentsに対するTCCプロンプトが発生する可能性があります — ~/.hermes/state.db のみを読み取る場合でも。このシェルスクリプトは sqlite3 + curl + jq + awk のみを使用し、TCCをトリガーしません。ユーザーが明示的にTCCプロンプトを受け入れない限り、このワークフローのPythonベースの実装は決して使用しないでください。
トランスクリプトの切り詰め:24000文字でほとんどのセッションをカバーできます。非常に長いセッション(200メッセージ以上で大きなツール出力を含む)は末尾が切り詰められます。ハンドオフが不足していると感じる場合は、より狭いクエリに分割してください。
思考モデル + num_predict:Ollamaの num_predict は、message.thinking を含む生成トークンの総数を制限します。思考モデル(Ornithはそう)は思考チャネル全体で予算を消費し、空のまたは末尾が切れた message.content を返す可能性があります — スクリプトはこれを排他的に読み取ります。症状:「Ollamaからの空の応答」またはハンドオフが文中で停止する — モデルの品質問題のように見えますが、ペイロードのバグです。スクリプトは think:false を送信します(そのフラグを拒否するモデル向けのフラグなし再試行フォールバック付き)。Wesleyからのスコープノート:このフラグはこの機械的な抽出ジョブにのみ正しく機能します — Ornithの思考はエージェントエンジニアリングでは資産ですが、抽出実行がエージェント能力について何かを語ることはありません。抽出不良をモデル全体の評決に一般化しないでください。
Ollamaが実行中である必要があります:呼び出し前に ollama list で確認してください。
出力は /tmp:OSは再起動時に回収する可能性があります。再起動をまたいで再開する場合は、安定したパスにコピーしてください。
スクリプト
正規の実装はこのスキルの scripts/ce-pickup.sh です — スキルパスで呼び出してください。ホスト側のコピーは歴史的に ~/.hermes/scripts/ce-pickup.sh にありました(シンボリックリンクとして文書化)。そのコピーが存在するがシンボリックリンクでないマシンでは、それは古いものです — スキルディレクトリを信頼してください。
関連項目:ハンドオフドキュメントが存在した後の再開ワークフローについては、ce-handoff スキルを参照してください。