Imported from ymegane/claude-code-plugins (
fable-advisor/skills/fable-advisor/SKILL.md). Install upstream withnpx skills add ymegane/claude-code-plugins --skill fable-advisor. Copyright stays with the author.
Fable 5 アドバイザーへの相談
fable-advisor エージェント（${CLAUDE_PLUGIN_ROOT}/agents/fable-advisor.md・model: fable）に相談し、セカンドオピニオンを得る。アドバイザーは助言のみ行い、コードは変更しない。実装するのは常に呼び出し元（あなた）。
いつ相談するか
相談する価値があるのは「判断」が難しいとき。「調べればわかること」はアドバイザーに聞かない — 自分で Read / Grep する方が速く安い。Fable 5 は最上位モデルでコストが大きいため、1相談で答えが出るようブリーフに投資する。
| 相談する | 相談しない |
|---|---|
| 有力案が複数あり決め手がない設計判断 | コードを読めばわかる仕様確認 |
| 仮説を2回以上棄却したデバッグ難航 | 初手の調査（まず自分で切り分ける） |
| 不可逆性の高い判断（データモデル・API・移行）の確定前 | 好み・優先度の判断（これは人間に聞く） |
| 自分の推論に見落としがないか不安な複雑トレードオフ | 些末なリファクタ方針 |
注意: プロダクト仕様・優先度・見た目の判断はユーザーの領分。アドバイザーの助言で代替せず、判断材料を揃えてユーザーに確認する。
相談ブリーフの組み立て
助言の質はブリーフの質で決まる。 アドバイザーは会話履歴を一切見られない新規コンテキストなので、必要な文脈をすべてブリーフに含める。以下の型で書く：
## 相談種別
設計 / デバッグ
## ゴール
何を判断・解決したいか（一文）
## 背景・制約
チケット・既存方針・非目標・締切など。プロジェクトの規約ファイルがあれば名指す
## 検討済み事項
- 設計相談: 候補案A/B/…と、現時点の傾き・迷っている点
- デバッグ相談: 試した仮説と棄却理由、観測事実（エラーメッセージは原文のまま）
## 関連ファイル
パスを列挙（アドバイザーはここを起点に自分で裏取りする）
## 問い
具体的に。選択式（A or B）や Yes/No に落とせるならその形で
手を抜きやすいのは「検討済み事項」だが、ここが薄いと既に棄却した案を提案されて往復が増える。逆に自分の結論を断定調で書きすぎると追認されやすい — 事実と自分の解釈を分けて書く。
spawn 手順
Agent tool で spawn する：
Agent(
subagent_type: "fable-advisor:fable-advisor",
description: "設計相談: <トピック>",
name: "fable-advisor",
prompt: <上記ブリーフ>,
run_in_background: false
)
subagent_type はプラグイン名を冠した fable-advisor:fable-advisor（プラグインが提供するエージェント型の命名規則）。name は同一セッション内での呼び名なので、SendMessage の宛先に使う短い名前でよい。
run_in_background: false— 助言を待ってから作業を続けるのが基本形。相談と並行して進められる独立作業がある場合のみ background にする- 追加の質問・往復は新規 spawn せず
SendMessage（to: "fable-advisor"）で継続する。コンテキストが保たれ、ブリーフの再送が不要
フォールバック: 実行環境に fable-advisor エージェント型が登録されていない場合（サブエージェントとして動作中など）は、subagent_type: "general-purpose" + model: "fable" で spawn し、${CLAUDE_PLUGIN_ROOT}/agents/fable-advisor.md の本文（役割の境界・進め方・出力形式）を Read してブリーフの前に埋め込むことで代替する。model 指定だけ移して定義本文を省くと、助言専任の役割境界と出力の型が失われるので必ず両方移す。
助言の扱い
アドバイザーの助言は一次判定ではなくトリアージの入力（別モデルの自動レビュー所見を扱うときと同じ原則）。採否は自分の判断で確定する：
- 助言の「根拠」に挙げられた file:line を自分でも確認する。事実誤認があれば採用しない
- デバッグ相談: 提案された検証手順を実行して仮説を確定させてから修正する。助言を根拠に直接修正しない
- 設計相談: 採用する場合も「前提・リスク」欄の未確認前提を潰してから進める
- ユーザーへの報告では、アドバイザーの推奨・自分の判断・その理由を区別して伝える
自発的に相談した場合は、相談した事実と要旨をユーザーへの報告に含める（黙って外部判断を混ぜない）。