Map vs Territory：その距離こそが unknowns
Claude に指定したプロンプト/コンテキストは次のとおりです。 地図。実際のコードベースとバインディングは次のとおりです。 地域。 この二人の間の距離をこう呼ぶ unknowns.
Fable 5 を使用すると、output の品質は unknowns の明確化能力によって制限されます。 ユーザー — model の能力のせいではありません。 モデルが強力であればあるほど、悪いマップの代償は大きくなります。これは、モデルは立ち止まって質問するのではなく、自信を持って間違った方向に実行するためです。
promptに明確に書いてあること。 Claude は読んで従うだけです。推測する必要はありません。
自分自身が知っていること 未定 — トレードオフ、変数名、戦略 migration はオープンのままです。
標準は「見ればわかる」ですが、それを言葉で表現することはできません。output が間違っている場合にのみ表示されます。
知らなかった質問は尋ねる必要があります。これは最も危険なギャップであり、排除すべき主な目標です。
merge 当時の領土は地図上で間違った形状になっていたため、修復費用は何倍も高価でした。
3 つの重要なギャップを埋めるために書いた custom skill
ClaudeKit core の一部ではありません — このメソッドが必要とする正確なギャップを埋めるために構築された 3 つの小さな skill: コーディング前に unknown unknowns を見つけ、それが発生した瞬間に deviation を記録し、コーディング後に人々を理解する gate。
「何がわからないのかわからない」を、鋭い、粘り強い prompt に変えます。
逸脱が起こった瞬間に、それが謎になる前に、逸脱をキャッチします。
クイズに絶対に合格しないと合併しません。それはとても簡単です。
各skillの詳細
/blindspot — 領域に入る前のブラインドスキャン
- スカウトcodebase+ピーチ
git log見つける unknown unknowns ユーザーの代わりにタスクを解決するのではなく、 - 調査結果では、evidence: 特定のファイル、commit ハッシュ、またはドキュメントを引用する必要があります。一般的な推測は受け入れられません。
- 最も価値のあるトリック: 同様のタスクを実行した commit を見つけます (
git log --grep） すでにgit show --stat <hash>— その footprint ファイルは、利用可能な checklist touchpoint、通常は最高の信号 artifact です。
/ck:brainstorm または /ck:plan 次のステップで。/impl-notes — 発生した瞬間に deviation をログに記録します
- File
implementation-notes.mdghi Decisions / Deviations / Surprises セッション終了時の振り返りではなく、それが起こった瞬間に/ck:journal. - スタンディングルールはすぐそこにあります ファイルのヘッダー — 会話が長くなると、context compaction がルールを破ってしまうため、会話の記憶に頼らないでください。ファイルを再読み取りする agent は、ルールを自動的に「再採用」します。
- edge caseに遭遇 計画から逸脱 → 選択肢を選択 保守的 (reversible 最小)、ログ 4 行、前進 - ユーザーが元に戻せる決定を待つのを停止しません。
quiz-gate (deviations = 最高の quiz material) および /ck:journal./quiz-gate — 人が人をチェックする
- 変数の名前変更に関するトリビアではなく、行動クイズを使用して変更 (TL;DR、コンテキスト、直感、blast radius) に関する HTML explainer を生成します。
- ゲートは応答する場合のみ通過します 100%正しい。どの文が間違っているか → 誤解されている概念を正しい関連コードで説明し、正しい箇所を対象に新しい文を再クイズし、合格するまで繰り返します。
- 重要な修正が適用されました: 初期 report 質問のみが含まれています、answer key は HTML のみに書き込まれます。 gate の解決後 (パスまたは中止) - 最初に書かれた場合、ユーザーが回答を読み、gate は無意味です。
/ck:git または /ck:ship.custom skill と ClaudeKit を組み合わせた 6 段階 pipeline
各期間は、unknowns を見つけるための前払い料金です。
/blindspotcodebase + git history をスキャン → unknown unknowns、ポットホール、およびよりシャープな prompt をレポートしてステージ 1 に進みます。
/ck:brainstorm --htmlblindspot から prompt を取得 → スカウト + インタビュー組み込み → 2-3 アプローチ + 設計ドキュメント。
高リスク: さらに多くの /ck:predict (5人の人物によるディベート) または /ck:scenario (edge case 12ウェイ)。
/ck:plan （または --tdd)輸出 plans/<ts>-<slug>/plan.md + phase files.
高リスク: + red-team (敵対的な reviewer が計画を台無しにしました)。 + validate (主張と実際の codebase を確認してください)。
大文字と小文字が区別される (OpenAI サブルーチンが必要): /codex:adversarial-review 計画通り — gate が model を超えました、実行します ファイナル red-team + validate の後: 洗練された計画を攻撃し、両方の Claude が盲目である場所を見つけます。
/impl-notes init → /ck:cook → /impl-notes review/impl-notes init 作成する implementation-notes.md プランディレクトリ内 前に cookの場合。 /ck:cook <plan> 実行 — 計画から逸脱する場合: 保守的なオプションを選択します。 /impl-notes log、 どうぞ。セッション終了: /impl-notes review 次のセッションのために学びを抽出します。
/ck:code-review + /quiz-gateコードレビューはコードの品質をチェックします (コードチェッカー)。 quiz-gate は、2 つの異なる軸で人間の知識をテストします (人間が人間をチェックします)。
高リスク (OpenAI サブシステムが必要): /codex:adversarial-review コードの差分 — gate は model と交差し、その間で実行されます。 /ck:code-review そして /quiz-gate、focus text は、impl-notes の偏差セクションから抜粋。
/ck:git または /ck:ship + /ck:journalコミット/プッシュまたは PR pipeline、gate がステージ 4 になった後にのみ実行 PASSED。ジャーナルは impl-notes をフィードとして読み取り、反映します。
ck:cook を囲む 3 つの固定 gate + 2 つの任意 cross-model gate
チェックは重複していません。各 gate は、実行ステップの両端にある別個の未知の軸をターゲットとしています。 /quiz-gate 常に gate 最後のピン: 停止条件です。
計画上で
コードの差分について
水平にスクロールして 6 つのノードをすべて表示します →
Gate 1 · /ck:plan red-team — agent は agent をチェックします
2-4 reviewer subagent 敵対的なペルソナが、誰も思いつかなかった失敗モードを見つける計画を台無しにしました。 Which finding doesn't have evidence? file:line 特に自動拒否 — 曖昧な苦情を避けます。
Gate 2 · /ck:plan validate — red-team の後、cook の前に実行されます。
検証パスは文字通り「マップとテリトリー」をチェックします。 codebase を grep して、プランのクレーム (ファイル、シンボル、エンドポイント) が実際に存在するかどうかを確認します。 Then interview 3-8 questions 友達 Close the remaining open assumptions. red-team → validate の順序は、agent が他の人たちと最終決定する前に計画を破棄して編集し、改訂されようとしている草案で最終決定するのを避けることを目的としています。
オプションゲート・ /codex:adversarial-review 計画通り — cook 前、validate 後 (OpenAI サブが必要)
重大なケースのみ (migration、security、public contract)。走る ファイナル 計画段階では、計画が red-team + validate によって洗練された後、計画全体を攻撃し、Claude ファミリ全体が盲目になる場所を探します。
オプションゲート・ /codex:adversarial-review コードの差分 — cook の後、quiz-gate 前 (OpenAI サブルーチンが必要)
修正された gate は、Claude をチェックするすべての Claude です。同じ model ファミリ、同じ盲点であり、reviewer は、それ自体が発生するエラーをキャッチしません。クロスゲートmodel→agent model以外 (GPT-5.5) in — 残りの不明なタイプを適切に削除します: unknown unknowns model 自身による。 impl-notes の偏差セクションから取得したテキストに焦点を当てます。詳細はセクション07を参照してください。
Gate 3 · /quiz-gate — ヒューマン チェッカー、gate 最後のピン
出荷前の最後のゲートとして、出荷されたばかりの自分の unknowns を非アクティブ化します。マシン レビュー コード (または他の model) が合格したからといって、新しい動作を完全に理解したわけではありません。人は停止条件です。
シナリオコンボ – リスクに見合った保険料を支払う
変なエリアのみフルpipeline(ステージ0→5)＋ぼかしscope＋ハイリスク。より一般的な状況では、より薄いコンボが必要になります。
| シナリオ | 使うコンボ | 省略するもの |
|---|---|---|
| 前回のセッションで計画があったので、続行します | /ck:watzup ステータスを読む → 古い impl-notes の「次のセッションの学習」を読む → /impl-notes init → /ck:cook 次のフェーズ → /quiz-gate。古い impl-notes をまだ持っていませんか (以前 ClaudeKit を使用したプロジェクトに 3 つの custom skill を追加しただけです)?読み飛ばす 学習内容 — /impl-notes init アクティブなプラン ディレクトリに新しいファイルを作成すると、このセッションから学習が蓄積されます。 |
フェーズ 0-2 — unknowns は前のセッションで料金を支払いました |
| 小さなバグ修正、おなじみの領域 | /ck:fix →commit。ロイ deviation それでは /impl-notes log |
10 行を修正するための gate — quiz-gate 全体は過剰摂取です |
| 奇妙なエリアですが、scope はクリアです | /blindspot <area> → better-prompt をそのまま貼り付けます。 /ck:plan |
ck:brainstorm — scope がロックされているときは議論することが何もありません |
| 完全に新しいドメイン (コードではない) | /blindspot --domain (まずは教える、語彙を学ぶ) → /ck:brainstorm --html |
スカウト codebase — ギャップはリポジトリではなく知識にあります |
| 高リスク (public contract、security、migration) | Full pipeline + /ck:predict//ck:scenario ステージ1+で red-team → validate ステージ2+で /codex:adversarial-review ステージ 4 (OpenAI サブがある場合); quiz-gate 義務的な |
何もあきらめないでください |
| Claude がスタックする — debug loop、何度も修正されましたが失敗しました | /codex:rescue (OpenAI サブが必要) — 別の死角から見える GPT-5.5 にタスクを割り当てます。 --resume 古いスレッドを続けます |
gate を変更しても問題は解決しません。問題は model の盲点にあり、別の model が必要です。 |
| 計画は完了しました。リスクは中程度です。red-team に群がる価値はありません | /ck:plan validate — 主張の検証 + 最終仮定のインタビュー → /ck:cook |
red-team (中等度のリスクの場合は過剰摂取)、 /ck:predict//ck:scenario |
| 他の人が書いた PR をレビューする | /quiz-gate --pr <n> 単独で使用 — クイズは PR を詳しく読む方法です |
blindspot, impl-notes — 私が書いたコードではありません |
| 純粋なリファクタリング、動作は変更なし | /ck:code-review + test suite |
quiz-gate オプション — 誤解を招くような新しい動作はありません |
Fable 5 はどこで使うべきか？
原則: unknowns を見つけるための初期費用は安くなります。最も高価な model をプロセスに投入すると推測されます 検出して決定する、プロセスには安価なmodelを使用してください 指示通りに実行する — 計画が優れているほど、model の実装もより優れたものになります。
| 工程 | モデル | 理由 |
|---|---|---|
/blindspot |
Fable 5 | 価値は解釈にあります。git history を「ポットホール」に読み取り、どの commit が従う価値のあるパターンであるかを認識します。弱いモデルはファイルをリストするだけです。 |
/ck:brainstorm, /ck:plan, /ck:predict |
Fable 5 | アーキテクチャ上の決定 - ここで間違っていると、その後のすべてのステップが無意味になります。 |
/quiz-gate (質問を生成) |
Fable 5 / Opus | 優れた注意をそらす人は、コード作成者よりも動作をより深く理解する必要があります。回答者は、model さんがこのトピックを指摘したあなたです。 |
/ck:plan red-team |
Fable controller + Opus/Sonnet | レビュー担当者 subagent は、evidence で故障モードを見つけるだけで済みます。 file:line (あらかじめ決められたペルソナ — Opus は十分以上の能力を持っています)。新しい裁判結果にはインテリジェンスが必要であり、メインセッションで実行されます。たとえば、subagent あたりは最も美しい pipeline です。 |
/ck:plan validate |
Sonnet/Opus | 検証パスは、checklist 層に従った機械的な grep です。知性は答える人にあります。model は正しい質問をするだけで済みます。 |
/ck:cook 詳細な計画に従って |
Sonnet | 優れた計画により、unknowns は排除されました。実装は地図に従ってください。最大の貯蓄場所。 |
/ck:code-review |
Opus/Sonnet | checklist + evidence によるレビュー; Fable は public contract に変更するだけの価値があります。 |
/impl-notes log, /ck:git, /ck:ship, /ck:watzup |
Haiku/Sonnet | メカニズム: 数行の commit を追加し、ステータスを要約します。簡単です。 |
/ck:scout raw discovery |
Haiku | Glob/Grep でファイルを探すだけなら Fable usage を使う価値は薄い。Explore/subagent で大きく scout するなら、先に安い model を pin する。blindspot はその上の解釈層で使う。 |
/codex:review, /codex:adversarial-review, /codex:rescue |
GPT-5.5 (OpenAIを使用、別途サブスクリプション) | クロスゲート model — Claude トークンの書き込みはなく、個別の請求が行われます。価値は盲点にある 他の より強力な model ではありません。 |
Explore は v2.1.198 以降、main conversation の model を継承することがあります。main session が Fable 5 の場合、Explore も Fable usage を消費する可能性があります。他の subagent に影響させず安く scout したいなら、custom subagent explore.md を作り、name: Explore として model: haiku または model: sonnet を pin します。詳しくは Claude Code の built-in subagents docs を参照。
避けるべきアンチパターン: cook には Fable を使用しますが、プランには Sonnet を使用します。これは、unknowns が以前に削除されるべきだったと推測させるために高価な model を支払うことを意味し、まさに記事が警告している「貧弱なマップ、高価な領域」の罠です。
Codex — 別の model を入れて Claude をレビューする
このセクションには OpenAI のサブスクリプションプラン（ChatGPT Plus/Pro または API）と、ログイン済みの Codex CLI が必要です。なければスキップして構いません。上の固定 3-gate pipeline だけでも十分使えます。
Plugin codex-plugin-cc Codex/GPT-5.5をClaude Codeに挿入します。本質的な価値観は「modelが強い」ではなく、 model KHÁC: すべての内部 gate は、Claude をテストする Claude です。同じトレーニング、同じ systematic バイアスを使用すると、reviewer は、同様に発生するエラーをキャッチしません。 Codex には他にも盲点があります → unknown unknowns を model から削除できます。
設定
/plugin marketplace add openai/codex-plugin-cc /plugin install codex@openai-codex /codex:setup
plugin ではなく Codex MCP を使う場合
Codex CLI は MCP server として起動し、他の agent から呼び出すこともできます。ただし MCP 経由では、Claude は plugin の command/gate に縛られません。brainstorm、plan、cook、review、close phase のどこでも Codex に聞けてしまいます。この使い方は可能ですが、明確な guardrails が必要です：
- いつ聞くか：本当にリスクがある checkpoint だけにする — critical plan、material code diff、security/migration/public contract、または debug loop で 2 方向試しても詰まった場合。
- 何を聞くか：毎回、具体的な artifact、具体的な scope、具体的な質問、evidence のない finding を reject するルールを渡す。
- 最大何 round か：デフォルトは 1 round。round 1 が material change につながった場合だけ round 2。ask → red-team → review → 再 ask の無限チェーンにしない。
- 誰が最終判断するか：Codex が単独で plan を approve したり、phase を close したり、ship 許可を出したりしない。Claude/human が各 finding を evidence 付きで accept/reject し、その後に修正する。
Claude Code workflow で ultracode のような keyword/feature を使って Codex を呼び、権限の広い review session を spawn する場合、ユーザーが明示的に edit を approve しない限り review-only として扱います。default path にしないこと。広い review session と複数 round の組み合わせは、token burst を重くしがちです。詳しくは OpenAI の Codex MCP docs を参照。
pipeline 内の各コマンドの場所
| コマンド | タイミング | 役割 |
|---|---|---|
/codex:adversarial-review その上 plan |
フェーズ 2 の終了、red-team + validate 後 | 計画上の 3 番目の model クロスゲート — 重大なケースのみ (migration、security、public contract) |
/codex:adversarial-review その上 code diff |
ステージ4以降 /ck:code-review、 前に /quiz-gate |
本物の使用例 (「出荷前レビュー」) — 設計上の選択、隠れた前提、トレードオフに挑戦します。 focus text は impl-notes の偏差セクションから取得 |
/codex:rescue |
Claude がスタックしたとき (debug loop) | Escape hatch — --resume スレッド Codex をセッションごとに分離する |
/codex:review |
ステージ4 | 結果に対するセカンドオピニオン /ck:code-review 疑わしい; focus text は受け入れられないため、プランには使用しないでください |
Review gate (/codex:setup --enable-review-gate) |
各ターンには編集コードがあります | デフォルトはオフ — 以下の理由をご覧ください |
サンプルプロンプト — 計画に対する敵対的なレビュー
計画が洗練された後、Codex を 3 番目のレビュー レイヤーに配置します。下位レイヤーがキャプチャした内容が見つからないように、その点を明確にします。
/codex:adversarial-review --wait Đây là implementation plan tại plans/<dir>/, chưa phải code — đã qua red-team và validate nội bộ. Đừng verify chi tiết file/symbol. Thay vào đó: (1) challenge HƯỚNG ĐI — đây có phải cách tiếp cận đúng không, có alternative đơn giản hơn không; (2) hidden assumptions mà plan đứng lên trên nhưng không nói ra; (3) tradeoffs bị đánh giá một chiều; (4) pressure-test các phase liên quan [điền risk area thật: auth/data loss/rollback/race].
commit のないプランは、working-tree の変更とみなされます (untracked files はレビュー可能)。プランがcommitの場合はそれを追加します --base <ref>.
所見処理ループ — 自動ではなく人間によるトリガー
敵対的レビューは read-only をロックし、output verbatim を返しました。ユーザー制御ループ:
- Codex 敵対的実行 round 1、結果 verbatim を返します。
- Claude (Fable/Opus) adjudicate: Accept/Reject は evidence と一緒に検索するために使用されます — 結果が検証済みの決定と同じである場合、ソースとともに拒否します。
- 人物が承認します 承認リスト — gate 人は削除できません。
- Claude apply 承認された修正 + 一貫性のスイープ。
- Round 2 修正が適用された場合にのみマテリアルが変更されます。 focus text は、正しい修正領域を指します。 最大2ラウンドまで。
--resume だけで rescue; adversarial-review ステートレス — ラウンド 2 は、focus text で独自のコンテキストを保持する必要があります。
Review gate — なぜデフォルトでオフなのか
プラグインの唯一の自動バージョンは Stop hook で、編集コードのあるすべてのターンをレビューします。オフにする 3 つの理由:
- タイムアウトはターンごとに最大 900 秒 — 各編集は続行する前にレビューが完了するまで待つ必要があります。
- コード内にハード ループ ガードは見られません — OpenAI 自体も、Claude-Codex ループを警告します。
- ターンごとのゲーティングのパラドックス: unattended run にのみ価値がありますが、OpenAI は、モニターに座っているときにのみオンにすることを推奨しています。そして、見ている人はすでに gate です。
交換する： /codex:adversarial-review 走る 一度 ステージ 4 — 同じ補償範囲、1 回の支払い、誰かが広告を掲載します。
system を正しく再設計する
Alex Finn の記事は、Thariq と同じ主張をしていますが、より高いレベルで、各マップを修正する代わりにアップグレードします。 マッププロッター — system を操作する独自のコーディング。すぐに適用できる 4 つの原則を次に示します。
system レイヤーの欠陥により、上記の複利が発生します 全て タスク — したがって、再設計コーディング ループの 1 つの Fable セッションは、後続の数百の cook セッションで償却されます。 output が最もコストパフォーマンスに優れているのは、output です。 再利用可能な構造 (system、skill、プラン)、output が 1 回の実行の場合に最も安価になります。
Thay vì làm ngay task này, hãy thiết kế cho tôi một skill/workflow tái sử dụng để MỌI task cùng loại về sau chạy qua nó. Loại task: [mô tả]. Output cần: quy trình từng bước, file SKILL.md (nếu phù hợp), và tiêu chí đo để biết nó có đang hoạt động tốt không.
Fable に直接読み取らせる rules/、skills、git history — 自分の働き方に関する実際のデータは、自分の言葉よりもはるかに強力です。アーティファクトは実際の動作を反映します。物語は行動のイメージを反映します。
Đừng hỏi tôi làm việc thế nào — lời tự kể không đáng tin. Hãy đọc: thư mục rules/, danh sách skills đang cài, và `git log --oneline -50` của repo này, rồi tự dựng lại bức tranh workflow THỰC TẾ của tôi. Chỉ ra 3 chỗ friction lớn nhất, mỗi chỗ phải cite file hoặc commit làm bằng chứng — không nhận nhận định không có dẫn chứng.
新しい System は次の環境でテストする必要があります。 本当の仕事 次に、output を測定します。system は、議論中ではなく、実際の負荷の下でのみ弱点を明らかにします。最初にプロトタイプを作成し、後で拡張します。
System/skill vừa thiết kế xong: chạy thử nó trên đúng MỘT task thật sau đây: [task]. So sánh với cách làm cũ theo 3 tiêu chí: thời gian, số lần phải sửa lại, chất lượng output. Nếu không hơn rõ rệt, liệt kê chỗ cần chỉnh — đừng khen.
同じ種類の摩擦が発生します 3回以上 impl-notes / ジャーナル / レトロでは、system を再設計する価値があります。ループ: 作業 → deviations のビルド → レトロなパターンの公開 → 再設計 → テスト実行 → 保持または破棄。
Đọc implementation-notes.md và journal/retro gần nhất của tôi. Nhóm các deviation/friction theo loại. Loại nào xuất hiện từ 3 lần trở lên? Với MỖI loại đó, đề xuất một thay đổi system NHỎ NHẤT khử được nó. Loại nào dưới 3 lần: bỏ qua, đừng đề xuất gì.