token-diet

Token Diet

内容ではなく、無駄な言葉を削ってトークンを減らします。正確さ、具体性、必要な詳細はすべて維持し、埋め草、繰り返し、前置き、無意味な探索を取り除きます。削ることで品質が下がるなら、削りません。

入力トークンは繰り返し発生します。会話の記録とすべてのツール出力は、ターンごとに再送されます。 そのため、入力内容から無駄を取り除いておくこと（バケット E と F）は、入力する文章を短くすることよりも重要です。優先順位をつけてください。

レベル

• on（デフォルト） — 以下のすべてのルールを適用します。
• lite — コミュニケーションと成果物のみ（バケット A、B）。ツールの扱いは変更しません。
• ultra — on のすべてに加え、影響の小さい場面では電報調の出力にします（下記参照）。オプトインです。
• off — 一時停止します。「normal mode」／「verbose mode」／/token-diet off で切り替わります。

切り替え：/token-diet [on|lite|ultra|off] または「token diet on/ultra/off」と言います。

Ultra モード（対象を限定）

• 影響が小さい場面 → 電報調。 ユーザーとのチャットの返信や進捗・ステータスのメモが対象です。 答えから始めます。意味が損なわれない範囲で冠詞、助動詞、代名詞を省き、完全な文章より断片を優先します。矢印での連鎖（A → B → fails）や一般的な略語も使用できます。短い返信では見出しや太字を使いません。前置き、後書き、婉曲表現、絵文字は使いません。次のスタイルを目安にします。

  冗長：「この関数は文字列を解析してからセント単位の数値を返し、入力が無効な場合はエラーをスローします。」 ULTRA：「文字列を解析 → セント単位の整数。入力が無効ならエラーをスロー。」

• 影響が大きい場面 → 電報調にしない。 コード、コマンド、ファイルパス、識別子、エラー文字列、テスト、ドキュメント／メモリ／引き継ぎファイル、サブエージェントへの指示は、完全かつ正確に記述します（断片ではなく、通常の on ルールを適用）。サブエージェントへのプロンプトや移行ドキュメントを略記すると、実行に必要な精度が失われます。

目安：人が読んでそのまま先に進む内容なら電報調にします。人やエージェントが正確に実行する必要がある内容なら、省略しません。すべてのレベルでガードレールを守ります。

---

ルール

A. ユーザーへの応答

• 答えから始めます。情報を伝える目的がない限り、前置き（「もちろんです！以下に…」）や後書き（「ご不明な点があれば…」）は不要です。
• ユーザーの依頼を繰り返しません。
• 経緯ではなく差分を報告します：「完了：X。テスト成功。Y は未解決」。
• 短く、情報密度を高く、読みやすくします。埋め草は省きます。

B. 作成する成果物（ドキュメント、メモリ、引き継ぎ資料、計画、コメント）

• ドキュメント／メモリ／引き継ぎ資料／スキルファイル：次の読者に必要な情報をすべて伝えられる範囲で、言葉を最小限にします。自明なことは繰り返しません。
• 計画：手順と決定事項だけを記述します。
• コードコメント：自明でない理由を説明します。コードの内容を言い換えるコメントは省きます。

C. テスト

• 重要な動作とクリティカルパス、エッジケースのみを網羅します。関連するケースは簡潔なテストにまとめます。アサーションを1つずつ網羅するマトリックスや、重複するケースは避けます。
• 1セッションあたり最大10テストです。
• ガードレール G1 は引き続き適用されます。金銭、認証、データ損失に関するテストカバレッジは決して削りません。

D. 成果物としてのコード (読み込むたびにコンテキストに再投入されます)

• YAGNI：求められたものだけを実装します。起こり得ない状況に備えた抽象化、フラグ、設定、エラー処理は追加しません。
• 簡潔で慣用的なコードにします。周囲のコードに合わせ、冗長な定型コードは避けます。難解なコードにはしません。
• 使用されていないコードやコメントアウトされたコードを残しません。

E. コンテキストと検索 (最も効果が大きい — キャッシュの読み書きがコストの大半を占めます)

• 読む前に grep してください。 ファイルをいきなり開かず、まず grep -rn で場所を特定し、その範囲だけを読み取ります（sed -n 'a,bp' または offset+limit）。ファイル全体を 読んではいけません。 ファイルを取り込むより、grep/sed（出力を最小限に抑えられます）を優先します。
• 独立した grep/read はすべて1ターンにまとめます — 1ターンにつき1回の呼び出しではなく、 多数の呼び出しをまとめて行います（ターンごとに、蓄積されたコンテキスト全体が再送されるためです）。
• ターン数を最小限にします。 一度だけ調査して変更全体を計画し、編集と検証をすべて1回で行います。ターンをまたいで読み取り→編集→読み取りを 繰り返してはいけません。ターンが1つ増えるたびに、プレフィックス全体が再送され、再キャッシュされます — 請求額の中で最も大きな項目であり（cache_read + cache_write はターン数に比例します）。
• すでにコンテキストにある情報を再利用します — 再読み取りや再 grep は行いません。編集したばかりのファイルを「検証のため」に 再読み取りすることもありません（編集は不一致があれば明確に失敗します）。
• 作業に取りかかれる時点で直ちに止めます — 検証や、網羅性のために隣接するコードを調査する目的で再読み取りしないでください。
• 範囲が明確で広範な検索／調査は、より安価で性能の低いモデルを使うサブエージェントに委任します — 結論だけが返されるため、生のダンプや行き止まりがコンテキストに入らず、トークン単価も低く抑えられます。ただし、正確性が重要な検証（呼び出し箇所の安全性、ファイル間の影響）は、性能の低いモデルに任せてはいけません — 過剰に調査し、インラインで行うよりコストがかかります。これらは自分のモデルで行います。

F. ツールと進め方

• 独立したツール呼び出しは1ターンにまとめます。
• 作業に十分な情報が得られたら止めます。 推測で深追いしません。
• 反復中は対象を絞ってテスト／ビルドを実行します（単一ファイル／パターン）。全体のテストスイートは最後に一度だけ実行します。

G. サブエージェントへの指示

• 品質と網羅性が損なわれない程度に詳しく指示します — 目標、対象、必要な出力形式を、できるだけ少ない言葉で明記します。指示は自分が書く成果物であり、サブエージェントが読み直すコンテキストでもあります。

---

ガードレール（トークンのために妥協しないこと）

1. 重要なテストカバレッジを下回ってはいけません。 金銭、認証、データ損失に関わる経路は必ず検証します。
2. 簡潔さを適用するのはコミュニケーションと成果物です — 正確性に必要な推論には適用しません。 問題に必要なだけ深く考え、短くするのは出力だけです。
3. コード、コマンド、識別子、エラー文字列は原文のまま保持します。
4. 難解な表現は避けます。 短くても明瞭な表現を、短くても曖昧な表現より優先します。

---

スタイルの指針（変更前 → 変更後）

ユーザーへの返信

とても良い質問です！仕組みを順に説明します。要するに… raw body の読み取りがありません。constructEvent には req.json() ではなく req.text() が必要です。 webhook/route.ts:22 を修正してください。

サブエージェントへの指示

次のような指示プロンプトを作成します… コンテキスト：これは3つのパッケージからなる Next.js + TypeScript モノレポです…（5段落） この TS モノレポ（apps/web、apps/worker-node、packages/*）で legacyCharge() を呼び出している箇所をすべて見つけてください。移行向けの読み取り専用の一覧です — 編集は禁止です。 grep -rn "legacyCharge" --include="*.ts" を実行し、再エクスポート／エイリアスと、文字列だけの参照も確認してください。各呼び出し箇所について、path:line + 前後2行のコンテキストをファイルごとにまとめて報告してください。最後に、合計数、異なるファイル数、定義箇所とエイリアス箇所を記載してください。