ask-fable

name	ask-fable
description	現在のセッションの議論・調査・実装内容を自己完結した brief に梱包し、 model: fable の subagent を壁打ち相手として起動する。Fable の回答を 原文で示したうえで main (Opus) の評価を添えて提示する。 「fable に聞いて」「fable に相談」「fable のアドバイスをもらって」 「fable の意見は」「fable に壁打ち」など、Fable を名指しで相談・ レビュー依頼するときに使う。Fable は現在のセッションを見られないため、 第三者モデルの視点・セカンドオピニオンを得たいときに必ずこの skill で 文脈を梱包してから呼び出す。
user_invocable	true

ask-fable

現在のセッションの議論・調査・実装内容について、model: fable の subagent を壁打ち相手として起動し、その回答を評価つきで提示する。

なぜ brief の梱包が必要か

Agent tool で起動した subagent は fresh な context で始まり、 現在のセッションの会話・調査・変更を一切見られない。 "このセッションについて相談する" ためには、main session が 議論の経緯・調査結論・実装内容を自己完結した brief にまとめ、 参照すべきファイルパスとともに渡す必要がある。

brief が不完全だと Fable は的外れな一般論しか返せない。 この skill の価値は Fable を呼ぶこと自体ではなく、 文脈を欠落なく梱包する手順にある。

処理フロー

1. 核心の問いを定める

Fable に何を答えてほしいのかを 1〜2 文で確定する。

• ユーザーの依頼に具体的な問い（例: 「この設計で大丈夫か」）が 含まれていれば、それを核心の問いとする
• 「fable に相談して」だけで焦点が無い場合は、直近の議論から 争点を推定し、その framing で進める。推定が外れそうなら 一言だけユーザーに確認する

2. セッション文脈を棚卸しする

今セッションで扱ってきた以下を洗い出す。会話の中だけに存在する 決定・前提は、ファイルに無いので brief に文章で書き起こす。

• 議論: 目的、検討した選択肢、決定事項、未決事項
• 調査: 分かったこと、その根拠（ファイルパス・出力）
• 実装: 変更した対象と要点

実装内容は今扱っている対象に絞る。作業ツリー全体の git diff を無差別に渡さない。無関係な変更が混じると Fable の焦点がぶれる。関連する変更だけ、必要なら git diff -- <path> で範囲を限定して brief に含める。

3. brief を scratchpad に書く

system prompt に記載の scratchpad ディレクトリに fable-brief.md として書き出す。テンプレートは references/brief-template.md を使う。

自己完結を必ず守る。「先ほど議論したとおり」「上記の方針で」の ような、このセッションを見ないと解決しない参照を残さない。 指示語で外部を指したら、その内容を brief 内に書き下す。

4. Fable subagent を起動する

Agent tool を次の設定で呼ぶ。

• model: "fable"
• subagent_type: "general-purpose"（ファイルを Read して 推論させるため）
• run_in_background: false（回答を待って提示するため）
• name: 指定しない。name を付けると subagent が teammate 扱いになり mailbox 経由の非同期起動へ切り替わる。teammate の plain text は自動返却されず、SendMessage を明示しない 限り main に届かない（宛先名も環境依存）。無名なら最終 テキストが tool の戻り値として同期返却され、戻り値の agentId で継続もできる
• prompt: 下記テンプレート

あなたは第三者の技術アドバイザーです。別のセッションで進行中の
作業について、壁打ち相手としてレビューします。手がかりは以下の
brief と参照ファイルですが、brief は被レビュー者自身が書いており、
その見落としが brief の欠落としてそのまま伝播しうる点に注意する。

手順:
1. brief を読む: <fable-brief.md の絶対パス>
2. brief 末尾の「参照ファイル一覧」を Read で読む
3. brief の主張が怪しい・裏取りが要ると感じたら、リポジトリや
   git 履歴を自分で調べてよい。「brief に無いが判断に必要な情報」
   に気づいたら、その欠落自体を必ず指摘する。
4. 次の観点を出発点として率直に評価する（該当しない観点は
   飛ばしてよい）:
   - 「核心の問い」への直接の回答
   - 議論・方針の妥当性、見落とし、リスク
   - 調査結論の妥当性（根拠は十分か、反例はないか）
   - 実装の正しさ・設計上の懸念
   - 検討すべき別案（技術的根拠つき）
5. 追認だけで終えない。弱点・別視点があれば重要度順に挙げる。
   重大な弱点が無ければ「重大な弱点は見当たらない」と述べてよい
   （quota を埋めるための nitpick を無理に作らない）。
6. ファイルは変更しない。読むだけに徹する。

出力は重要度順に並べ、些末な指摘は一行に圧縮する。あなたの出力は
そのままユーザーに提示されます。orchestrator への報告ではなく、
アドバイスそのものを書いてください。日本語で。

5. 回答を評価つきで提示する

Fable の回答を原文で示し、続けて main の評価を添える。 評価では追認に流れず、技術的根拠を示して賛否・別案を述べる （global rule の建設的批判に従う）。

main と Fable は、被評価者（main）が評価者を兼ねる構造にある。 防衛バイアスを避けるため、Fable の指摘は重要度で選別し （quota 充足の低重要度指摘は割り引く）、両者で結論が割れた点は main が裁定せず、未決事項としてユーザーに委ねる。

## Fable の回答（原文）

<Fable の返答をそのまま引用>

## main の評価

- 同意する点:
- 反論・留保（技術的根拠）:
- 結論が割れた点（ユーザー判断に委ねる）:
- 推奨アクション:

Fable の回答が的外れ・一般論に留まった場合や、追加で問いたい ことが出た場合は、brief に前回の Q&A と補足を追記して Fable を再起動する。fresh context での再読はセカンドオピニオンの 独立性（前回回答への anchoring 回避）とむしろ整合する。同一 context を保ちたい場合のみ、起動時の戻り値に含まれる agentId へ SendMessage して継続する。brief の不足が原因なら、どこが 足りなかったかを追記に明記する。

ガード

• セッションにまだ実質的な内容が無い（相談材料が無い）場合は、 梱包せず、何について相談したいかをユーザーに確認する
• model: fable が使えない環境で Agent 呼び出しが失敗した場合は、 その旨を報告する。別モデルへ勝手にフォールバックしない （Fable の視点を得るのが目的のため）
• main session の model が既に fable の場合、Fable が Fable に 相談する形になり「第三者モデルの視点」は得られない（fresh context の価値のみ残る）。その旨をユーザーに伝えてから進める