continue-codex-work

Codex の作業を続行する

続行とは、まだ達成されていない業務上のタスクを完了することです。履歴の読み取りは必須の証拠収集フェーズであり、成果物ではありません。

開始条件：ネイティブな再開ではなく、外部からの引き継ぎ

現在の状況	対応
Codex 自体がこの同じ会話をネイティブに再開し、復元されたターンまたは圧縮状態がすでに現在のコンテキストにある	この Skill または read-codex-history を呼び出さないでください。保持されているコンテキストから直接続行し、変更を加える前に現在のワークスペースと外部状態を確認してください。
新しい／別の Agent コンテキストが、以前の Codex の実行を引き継ぐ必要がある、またはユーザーが、その継続性がここにはすでに存在していない別の Session ID を指定した	この Skill を使用してください。ステップ 1 で検証済みの履歴レシートを取得する必要があります。

再起動したというだけでは、2 行目を選択する根拠にはなりません。判断基準は、Codex のプロセスが再起動されたかどうかではなく、現在の会話が同じ Session のホスト復元による続きかどうかです。

ステップ 1：検証済みの Codex 読み取りレシートを取得する

daymade-claude-code:read-codex-history を呼び出し、正確な Session ID を指定して、Session 全体の時系列証拠に関するブリーフィングを依頼してください。ID が不明な場合は、まずその Skill のインベントリーまたは範囲を限定した検索を使用してください。

レシートには、次の内容を記載する必要があります。

• 使用した prompt-ledger、state-index、rollout の各ソース
• 選択された session_meta.id と、指定した ID と完全に一致するかどうか
• ルートから子へのフォークの系譜と、正確に継承されたバイト境界
• 選択されたタイムラインと継承されたタイムラインの、時系列順のユーザー／アシスタントのターン
• 圧縮されたコンテキスト、最新の計画、終了理由、未解決の呼び出し、ファイル、欠落情報

rollout の不一致、子 rollout の欠落、物理コピーの曖昧さ、親の欠落、バイト境界の破損、または復元可能な親の目的がない続行の合図があれば、処理を中止してください。「最も近い」ファイルを使って続行してはいけません。

ステップ 2：続行のための契約を再構築する

次のアクションを選ぶ前、またはステージの完了を報告する前に、検証済みの読み取りレシートとプロジェクトの現在のステージソースから、この内部契約を埋めてください。プロジェクトのステージソースがない場合は、最新の人間からの依頼を使用してください。

フィールド	必要な証拠
当初の業務上の成果	継承されたタイムラインと選択されたタイムラインを通じて、現在も有効な最も早い人間からの依頼
現在の明示的な依頼	単なる続行の合図ではない、最新の人間からの依頼
現在の提供ステージ／対象外事項	今提供するものと先送りするものを絞り込む、最新の人間による修正。長期的な当初の構想を、現在の要件より優先してはいけません
すでに完了したこと	Agent の説明やアシスタントの最終回答ではなく、独立した完了の証拠。その証拠を成果物／セッションの識別情報と入力条件に紐づけ、条件が変わらない間は再利用してください。変動するランタイムと提供の状態は、改めて読み取ってください。
未達成のこと	完了の証拠がない、依頼された成果
ユーザーによる修正／繰り返してはいけないこと	ある方針、前提、または出力を拒否した人間からのメッセージ
実証済みの資産と成功した経路	既存のコード、ドキュメント、Skills、出力、コマンド、過去に成功した実験
次の直接的なアクション	成功すれば、未達成の業務上の成果を目に見えて前進させるアクションを 1 つ

子に「继续」、「continue」、または /fork しか含まれていない場合は、検証済みの親スナップショットからタスクを引き継いでください。ローカルの合図は、それだけで独立した目標にはなりません。

ステップ 3：現状と照合する

1. 対象プロジェクトの最新の AGENTS.md／CLAUDE.md を読みます。
2. cwd、ブランチ、作業ツリー、関連ファイル、外部の状態を確認します。
3. 記録されたパッチ、コミット、プッシュ、ダウンロード、ジョブ、Agent の出力が実際に反映されたことを確認します。ロールアウトには試行したアクションも記録されています。
4. 置き換えを作成する前に、以前に成功したアセットを取得して再利用します。
5. 使用制限やサービスエラーなど、一時的な失敗については、重複して作業する前に、元のプロセスがその後再開して完了したかを確認します。 既存のネイティブ Goal については、ネイティブ Goal の照合を使用して、未完了の作業、ランタイムの状態、サポートされている復旧方法、自動継続が確認されたかを区別します。あるツールメニューに復旧ツールがないからといって、稼働中のホストに復旧コントロールがないとは限りません。
6. セッション終了時に実行中だった処理を確認します。フォアグラウンドの長時間タスク（リモート診断、ダウンロード、ビルド）はセッションとともに終了し、パイプを通じて永続化されていない出力も失われます。ロールアウトに記録されるのはタスクの開始であり、結果ではありません。そのような結果は未完了として扱います。リモートプロセスまたはその出力ファイルが残っているかを調べ、再実行する前に、結果をディスクに書き出す切り離された経路を用意します（例：リモートで ( cmd > log 2>&1 </dev/null; echo $? > rc ) & を実行し、rc ファイルをポーリングします。対象環境にある場合は setsid／nohup を優先してください。pty に接続されたセッションでは、単独のサブシェルに SIGHUP が送られる場合があるためです）。そうすれば、次に中断しても結果が再び失われることはありません。

ステップ 4：ビジネスタスクを実行する

次に直接必要なアクションを実行し、そのフィードバックループを完了します。レビュー、スキルの作業、インフラのクリーンアップ、書式の調整、追加の安全対策は、元の結果を直接妨げている場合、またはユーザーが明示的に優先度を上げた場合を除き、優先度を下げて扱います。

重要な分岐に進む前に、次のように問いかけます。「これが成功した場合、現在許可されているステージで未達成のどの成果が前進するのか？」答えがないなら、それは継続作業ではありません。ソース、ログイン、プロバイダーへの経路がブロックされても、それに依存する作業だけがブロックされます。タスク全体がブロックされていると宣言する前に、許可された必要な作業をほかに実行します。

ユーザーが成果を利用する場所で結果を検証します。検索可能なバイト列だけではページが読みやすいとは証明できず、生成された提案だけでは人間による判断が保存されたとは証明できません。変更されていない入力に対しては、合格済みのチェックを再利用します。検証を拡張するのは、新たな変更、失敗、または解消されていない証拠の不足がある場合に限ります。

codex resume または codex --continue は実行しないでください。無関係な変更を上書きしないでください。

ステップ 5：契約に照らして報告する

• 復旧した Goal：正確な Session の系譜と元のビジネス上の成果。
• 実行内容：アクションと独立した検証。
• 現在完了している項目：実際に完了した契約上の項目。
• 残件：未解決の項目と具体的なブロッカー。
• 再実行しなかったこと：意図的に避けた、関連する却下済みの経路。

コンテキストの復旧、パーサーの成功、レビューの合格、サブプロセスの完了だけでは、継続が成功したことにはなりません。完了の単位は、ユーザーが求めるビジネス上の成果です。