Lorefall

Lorefall（計画専用）

Lorefall は1つの計画タスクを「パネル」に変える。同じタスクを複数のモデルに同時に投げ、各自が独立に （Web検索とbashで現状コード・制約を調べながら、互いの回答を見ずに）実装計画案を作る。その後、 Fable ペルソナを纏ったメインの Opus 4.8 が全案を読み、パネルの推論構造（合意点・対立点・ 1人だけが見た点・全員が見落とした点）を抽出して、それに根拠づけた統合 PLAN を1本書き、ファイルに 出力する。

核心は independence, then synthesis（独立 → 統合）。パネルが単独モデルに勝つ多様性は、作るのではなく 収穫するもの。同じプロンプトを独立に走らせるだけで推論経路・ツール呼び出し・参照ソースが分岐し、 同一モデルを2回走らせて統合しても1回より良くなる。だから「懐疑役」「最適化役」のようなレンズ／ ペルソナは振らない。各パネリストにはユーザーのタスクを**そのまま(verbatim)**渡し、まっすぐ計画させる。 （references/panel.md 参照）

一つだけ絶対ルール: Opus 4.8 が常に judge し最終 PLAN を書く — パイプラインは逆流できない。 パネリスト側は Opus を呼び戻せないので、Opus が常にドライバ。slug もドライバ先頭で読む。

このスキルは非変更型。どのモードでもコードは書かず、対象 repo を変更しない。成果物は実行可能な粒度の ファイルで、メインのセッションが受け取り、その後は通常モードで実装に進む。Fable ペルソナは本スキル実行中 だけ参照として読み込み、セッションに永続注入しない（実行後はメインの挙動が通常に戻る）。

Step 0a — モードを決める

Lorefall は計画専用ではない。同じ panel→judge 基盤を高難度の判断工程へ適用する。references/modes.md を読む。

モードはユーザーに選ばせない。 既定は plan。ユーザーが -- で明示したらそれを使うが、無ければ task の 意図から mode を推定し、曖昧なら plan にする（誤って重い別モードに倒さない）。呼び出し形:

• /lorefall <mode> -- <task> … -- の前が mode、後ろが task(verbatim)。
• /lorefall <task>（mode 省略）… task から推定、曖昧なら plan（後方互換の主経路）。
• 既知 mode: plan（既定）/ analysis / audit / hard-decision / merge-judgment。全モード非変更型 （コード変更・merge 実行・マイグレーションをしない）。

決めた mode は、Step1 のパネリスト指示文・Step2 で読む references/rubrics/<mode>.md・Step3 のファイル名に効く。 mode の判定でユーザーに聞き返さない（認知負荷を増やさない）。

Step 0b — パネルを選ぶ

bash <skill_dir>/scripts/detect_panel.sh

SLUG= 行に、このマシンで使える最良パネルが出る:

Slug	パネル	必要なもの
opus4.8-gpt5.5	Opus 4.8 + GPT-5.5 を並列 → Opus が judge	codex CLI（既定）
opus4.8-4.8	同一プロンプトを Opus 4.8 で2回独立実行 → Opus が judge	何も不要（常時可）

ユーザーが slug を指定したら従う。ただし必要 CLI が無ければその旨を述べ、そのパネリストを外して次に良い パネルへ降格する（失敗で止めない）。指定が無ければ detector の推奨に従う（既定 opus4.8-gpt5.5）。

Step 1 — Fan out（並列・ブラインド・レンズ無し）

references/panel.md を読む。各パネリストのプロンプトは、ユーザーのタスクをそのまま＋次の短い指示だけ。 成果物の種類だけ mode に合わせる（references/rubrics/<mode>.md の「必須構成」に対応）:

あなたは独立した複数の専門家の一人で、他の人の回答は見られません。Web検索と bash で対象リポジトリの 現状コード・既存実装・制約を実際に調べ、<mode の成果物> を自己完結で1本出してください。 （plan=実装計画 / analysis=分析と推奨 / audit=severity付きfindings / hard-decision=ADR形式の決定 / merge-judgment=merge可否と統合方針）。<rubrics/<mode>.md の必須構成> を含めること。 コードは書かず、対象 repo を変更しないこと。

レンズや役割は割り当てない。タスクを事前要約・事前消化しない。mode が plan のときの成果物は従来どおり 【目的/背景・変更対象ファイル・手順・再利用すべき既存実装(パス付き)・リスク・検証方法】。

全パネリストを1つのターンで起動して同時に走らせる:

• Opus 4.8 パネリスト → Agent tool, subagent_type: general-purpose（Web + bash 内蔵）。 opus4.8-4.8 の場合は同じプロンプトで Opus サブエージェントを2体 spawn（cold run ×2）。 同一メッセージで起動し並列実行。返ってきた各回答が1つのパネル応答。
• GPT-5.5 パネリスト → プロンプトを一意の一時ファイル(mktemp)に書き、対象 repo を渡して バックグラウンド実行:

  PF="$(mktemp "${TMPDIR:-/tmp}/lorefall_codex_prompt.XXXXXX")"
  OF="$(mktemp "${TMPDIR:-/tmp}/lorefall_codex_out.XXXXXX")"
  # プロンプト全文を "$PF" に書いてから:
  bash <skill_dir>/scripts/run_codex.sh "$PF" "$OF" medium 900 <target_repo>
  

  第5引数 <target_repo> は codex に read-only で調べさせる対象リポジトリ(省略時は CWD)。 run_codex.sh は watchdog 付き(timeout→gtimeout→bash、common.sh)で、-s read-only のため codex は repo を変更しない。最終回答だけを "$OF" に書くので完了後に読む。固定名の /tmp パスは 使わない(並行実行で衝突するため必ず mktemp)。 codex が非ゼロ終了・空出力・タイムアウトした場合（codex は在るが版が古い／未ログイン／別モデル設定 等）は、その panelist を欠落のまま放置して Opus 1体で"パネル"を組まないこと。追加で Opus サブエージェントを もう1体 spawn して opus4.8-4.8 相当へ降格し、独立2案を確保したうえで降格した旨を明示する。

パネリストは隔離を保つ: あるパネリストの出力を別のパネリストのプロンプトに絶対に貼らない。 オーケストレーター(あなた)が judge であり、パネリストとは分離する。opus4.8-4.8 では2体とも spawn した サブエージェントであり、あなた自身はパネリストにならない（合成を新鮮な目で読むため）。

Step 2 — Judge（共通5観点 + mode 固有 rubric）

全パネリストが返ったら、references/judge_rubric.md（共通）、選択 mode の references/rubrics/<mode>.md、 references/fable_persona.md を読む。 fable_persona.md は、Claude Fable 5 のシステムプロンプトから判断の作法だけを蒸留した Fable ペルソナである （原文は同梱しない）。そのペルソナ（検証して断定／複雑さに比例した労力／盲点の能動的探索／長時間でも判断が ぶれない）を纏って統合する。

この5観点の構造化は judge の内部作業 + 成果物ファイルの ## Audit Trail に書くものであり、 チャットにそのまま全文を出力しない（チャット出力契約は Step 4）。以下の5観点で各案を構造化し、 出典パネリスト（Opus run A / GPT-5.5 等）を明記する:

• Consensus — 全パネリストが独立に一致した方針・手順。最高信頼。
• Contradictions — 設計判断の直接対立。立場と保持者を述べ、実コードや一次情報を当たった側を優先して 裁定する。決着不能なら、何があれば決まるかを述べる。対立を体裁のため隠さない。
• Partial coverage — 一部パネリストだけが踏み込んだ重要サブ課題（単独案なら漏れた深掘り）。
• Unique insights — 1人だけが挙げた非自明で価値ある観点・落とし穴。多数派に合わなくても保全する。
• Blind spots — パネル全体が見落とした前提・リスク。judge が新たに追加してよい。

原則: 記憶ベースの主張より、実際にコードを実行・一次情報を読んだ主張を重く扱う（モデル種別を問わず）。 パネリストが失敗/欠落した場合は absent として扱い、沈黙を同意とみなさない。

Step 3 — 最終成果物をファイル化（単一ファイル・2層の証跡）

統合した成果物を1つのファイルに Write する。ファイル名は並行・同日再実行でも衝突しない一意名にする （common.sh の lorefall_artifact_name <mode> <slug> 相当: lorefall-<mode>-<slug>-<UTC>-<id>.md）。 保存先は、対象リポジトリがあれば <repo>/.claude/plans/ 配下、無ければ CWD 直下。

ファイルは次の構成にする。証跡はチャットでなくこのファイルに持たせる（透明性はここで担保する）:

1. 本体 — mode 固有の必須構成（references/rubrics/<mode>.md）。plan なら Context（なぜ）/ 変更対象 ファイル / 手順 / 再利用する既存実装(パス付き) / リスク / 検証方法。そのまま使える粒度。判断に必要な 対立・不確実性だけを本体に織り込む。
2. ## Decision provenance — 主要な決定の小表（決定 / 採用根拠 / 出典パネリスト / 対立の有無 / 未解決条件）。本体の各決定がここまで辿れること。
3. ## Audit Trail — Step 2 の5観点（Consensus / Contradictions / Partial coverage / Unique insights / Blind spots）の全文を出典付きで収録する付録。

コードは書かない（計画のみ）。 PLAN は1人のパネリストの案を軽く直したものではなく、5観点の構造化分析 から導出されたものであること。別ファイルの sidecar は作らない（本文と証跡を1ファイルに保つ）。

Step 4 — Present（Fable の声で凝縮して返す）

チャットにはパネル報告書を貼らない。Fable が直接答えたような単一の凝縮回答を返す。 5観点の散文・2案の貼り合わせをチャットに展開しないこと（それらは Step 3 のファイル内 Audit Trail にある）。 チャットに出すのは次だけ:

1. 結論／推奨方針を先頭で断定する（Fable の声 = 文体演技ではなく、断定・選択・根拠密度）。
2. 主要な決定 1〜3 点を決定的に述べる。曖昧な要約・ダラダラした列挙は禁止。
3. 未解決の高影響な対立がある場合のみ、1 文でそれを明示する（透明性。無ければ書かない）。
4. 成果物の保存先パスと「続きは通常モードで」の一言。詳細・全証跡はそのファイル（Decision provenance / Audit Trail）を参照、と案内する。
5. 末尾メタデータとして使用 slug と参加パネリスト。CLI 欠如で降格した場合はその旨と上位パネルの使い方 （codex のインストール/ログイン）を1行で添える。

これでユーザーは短い回答で判断でき、根拠が要るときだけファイルを開く。続きは通常環境で実装に進む。

Cost & latency / 使いどころ

パネルはトークンで概ね N×、最も遅いパネリストの速度で進む。これは「高くつく場面で自信満々に間違えない」 ための意図的なトレード。軽量・低リスクな計画なら単独で直接計画する方が正しい — どのモデルでも明らかに こなせる場面で Lorefall を持ち出さない。