Fable5がリデプロイされて残りの期間で何をさせようか考え中の方に向けて筆者のやり方をシェアします

Fableへの期待

みなさんはすでに理解されているかもしれませんがFableはその賢さと引き換えに多くのコストが必要です。

そのため全ての作業をFableにやってもらうということよりも、その賢さを使ってレバレッジを効かせられるようなタスクを依頼したいと筆者は考えています。

そのため考えたことは今あるリポジトリの改善点やセキュリティ関連の調査を依頼しました

プロンプト

## 背景と意図

数日後にこのリポジトリでの Fable 5 の利用枠が終了する。それまでに、後から Sonnet / Opus
で実際の修正作業に着手できるよう、「調査 → GitHub issue 化」までを完了させたい。
つまりあなたの成果物は「修正」ではなく「実行可能な粒度まで落とした issue 群」だ。
issue を読んだ別モデルが、追加調査なしに着手できる状態がゴール。

## タスク

このリポジトリ全体を調査し、以下の観点で改善点を洗い出して GitHub issue を建てる:

1. セキュリティホール(依存の脆弱性、認証/認可、シークレット管理、入力検証、
   IaC の設定ミス、権限過剰など)
2. 推奨設定からの逸脱(CI/CD、リンタ、型設定、ランタイム設定、可観測性)
3. アーキテクチャの抜本的な見直し(結合度、境界の切り方、スケーラビリティ、
   将来の拡張を阻む構造的負債)
4. コード品質・保守性上の重要な改善点

## 進め方

- 独立した調査領域は並列サブエージェントに委任し、待ちながら作業を続けること。
  サブエージェントが脱線したり文脈が不足していれば介入する。
- 十分に判断できる情報が揃ったら動け。すでに確立した事実を再導出したり、
  採用しない選択肢を長々と列挙しない。判断に迷うときは網羅ではなく推奨を出す。
- これは調査タスクだ。コードの修正・リファクタ・ブランチ作成・防御的な変更は
  一切行わないこと。成果物は issue のみ。
- 進捗を報告する前に、各主張をこのセッションのツール実行結果と照合すること。
  裏付けのある発見だけを報告し、未検証のものはその旨を明記する。

## issue の粒度と形式

各 issue は、後から別モデルが追加調査なしで着手できる粒度で書くこと:

- タイトル: [security] / [config] / [architecture] / [quality] などのラベルを接頭辞に
- 本文: (1) 問題の所在(該当ファイル/行/コミットを明示) (2) なぜ問題か
  (3) 推奨される対応方針 (4) 重大度と影響範囲 (5) 着手時の参考情報
- 重複を避け、関連する小さな指摘は 1 issue にまとめる。
- 重大度でラベル付けし、着手優先度がわかるようにする。

まず調査計画とリポジトリ構成の把握を共有し、その後 issue の作成に入ってよい。
破壊的操作や本当に人間の判断が必要な場合のみ止まって確認すること。

ポイントは3つ

意図を先に置く -> あとから別のモデルで修正するから調査だけをしてほしい理由とゴール明記
コード修正禁止を強調
進捗の裏付け指示

ちなみにFableはサイバーセキュリティ関連の内容には自動的にOpusにfallbackする可能性があるとされているため防御的な脆弱性や設定の改善の指摘などは問題ないですが
PoCエクスプロイトなどを含む場合はfallbackされることがあるので注意して使ってみてください。