mcpField
C
codex-token-saver

codex-token-saver

github.com/dff652エージェントワークフロー167 回インストール8 週間前に更新
リポジトリ

codex-token-saver について

codex-token-saverは、正確性、安全性、検証を損なわずに無駄な作業を減らすためのCodex向けワークフロースキルです。コンテキストの再利用や対象を絞った確認など、状況に応じた進め方を示します。

主な機能

  1. 01簡潔なプロジェクト情報の再利用
  2. 02関連するファイルや箇所だけを確認
  3. 03長時間処理を効率よく待機
  4. 04複数段階のプロジェクトを記録
  5. 05難易度に応じた作業の割り当て
  6. 06脱線や手戻りの抑制

活用シーン

  1. 01変更のないプロジェクトファイルの再読を回避
  2. 02頻繁なポーリングをせず実行中の処理を待機
  3. 03簡潔な状態記録からプロジェクトを再開
  4. 04許可された場合に実装やレビューを分割

インストール

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

$npx skills add https://github.com/dff652/codex-token-saver --skill codex-token-saver

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
VERSION
agents/
openai.yaml

詳細

Codex Token Saver

正確性、検証、安全性、またはユーザーが求める成果を損なうことなく、ワークフローを最適化します。トークンの節約は二次的な制約として扱い、使用量を減らすためだけに必要なファイル、ソース、テスト、承認を決して省略しないでください。

役立つ範囲で最も軽い対応を選ぶ

ワークフローを変更する前に、実際の無駄を特定します。

  • 変更されていないプロジェクトのコンテキストを繰り返し読み込んでいる。
  • 別のプロセスがまだ実行中なのに、頻繁にポーリングしている。
  • 古くなった判断を含む長い会話を引き継いでいる。
  • 範囲の限られた機械的な作業に、高性能または高コストのモデルを使っている。
  • 方針の逸脱、推測に基づく範囲拡大、または作業のやり直しが繰り返されている。

該当する対策だけを適用してください。短く、範囲が明確なタスクに余計なプロセスを追加しないでください。

再読する代わりにコンテキストを再利用する

  • 永続的なコンテキストと、変化する証拠を分けます。永続的なコンテキストには、プロジェクトの目的、アーキテクチャ、コーディング規約、固定の制約、標準コマンドが含まれます。変化する証拠には、新しい要件、編集内容、失敗、ログ、テスト結果が含まれます。
  • 信頼できる簡潔な永続的要約がすでにある場合は、それを再利用します。再読するのは、変更された可能性があるファイルや、現在の判断に実際に関係する箇所だけにします。
  • 大きなファイルを開く前に、シンボルやパスを検索します。ディレクトリやドキュメント全体を広く読むのではなく、対象を絞った範囲やクエリを優先します。
  • 正確性が現在のファイル内容に左右される場合、記憶に頼らないでください。再読が不要だと判断する前に、タイムスタンプ、差分、検索結果、または関連するソースを確認します。
  • 大きなドキュメントでは、レイアウトが重要でなければ、検索可能なテキストを一度抽出します。画像、表、ページ分割、書式が作業に影響する場合は、元のドキュメントを保持して確認します。

長時間の作業を効率よく待つ

  • イベント駆動型の待機、または現在のツールがサポートする最も長い安全な待機間隔を、短い間隔で空のポーリングを繰り返すより優先します。
  • 前回の操作ですでに再利用可能なセッション ID またはセル ID が返されている場合、空の入力やポーリング操作を繰り返し呼び出さないでください。
  • 外側の実行呼び出しが内側の待機を包んでいる場合、適切な余裕時間を含め、内側の結果を受け取るのに十分な時間を外側の呼び出しに設定します。プラットフォームの現在の上限と、より優先度の高い指示に従い、実行環境で許可されていない間隔を固定値として指定しないでください。
  • 実際に長時間待つ場合は、現在の環境で求められる頻度に従い、ユーザー向けに簡潔な進捗状況を伝えます。

長期プロジェクトにチェックポイントを作成する

作業が複数のフェーズにまたがる場合や、別のタスクで再開する可能性が高い場合は、永続化に意味があり、かつ作成がスコープ内であるときに限り、プロジェクト内の DEV_STATE.md を作成または更新します。内容は簡潔かつ事実に基づいたものにします。

# Development State

## Goal
## Verified current state
## Decisions and reasons
## Files changed
## Tests and results
## Next action
## Blockers or open questions
  • 会話の記録ではなく、検証済みの状態を記録します。
  • 以前の計画が不要になったら、蓄積せずに削除します。
  • チェックポイントの内容と食い違う場合は、リポジトリとテスト結果を信頼できる情報源として扱います。
  • 再開時はまずチェックポイントを読み、現在も有効かどうかを検証するために必要なファイルだけを確認します。

許可されている場合は、難易度に応じて作業を振り分ける

モデルの選択や委任が利用可能で、許可されている場合は、次のようにします。

  • 曖昧な目標の解釈、アーキテクチャ上の判断、タスクの分解、最終的な統合は、最も適切な高性能モデルに任せます。
  • 低コストのモデルには、明確な入力、出力、制約、受け入れ条件を指定した、対象の絞られた作業を割り当てます。たとえば、重点的なレビュー、独立した実装、テスト失敗の切り分けなどです。
  • 調整や手戻りにかかるコストのほうが大きくなる可能性がある場合は、トークン節約だけを目的に委任しないでください。
  • 現在のモデル料金やクォータ倍率を決めつけないでください。推奨事項にコストが関係する場合は、OpenAI の公式ドキュメントで最新情報を確認します。
  • サブエージェントやモデル変更に関する環境の許可ルールに従ってください。このスキルは、エージェントの起動やモデルの変更を許可するものではありません。

逸脱や手戻りを防ぐ

  • 実行内容が依頼から逸脱した場合は、成果につながらない作業を中断し、目標と現在得られている根拠を改めて確認してから、妥当な最小の次のステップに進みます。
  • 製品に別のサイド会話機能があり、その回答がメインの履歴で必要ない場合は、一時的な質問をメインの実装コンテキストに持ち込まないようにします。
  • 明示されたニーズを満たす最もシンプルな実装を優先し、任意の拡張を加える前に実行可能な最小構成を作成します。適切な場合は実績のある依存関係を使用し、将来予測されるメンテナンス負債につながる近道は避けます。
  • 失敗の内容を調べてアプローチを変えることなく、同じ失敗した操作を繰り返し再試行しないでください。

結果を報告する

完了時には、ワークフローを大きく変えた最適化、正確性を確認するために引き続き読んだ内容やテストした内容、残っている不確実性を簡潔に述べます。実際の使用データに基づいて測定していない限り、節約したトークン数を割合で示さないでください。

コメント