mcpField
D
discovery

discovery

github.com/avelikiy開発11153 回インストール今日更新
リポジトリ

discovery について

discovery は、決定を下す前に不足している背景情報を明らかにする開発スキルです。依存関係や規模から、予算、障害の影響、過去の作業、決定者まで、7 つの観点を確認します。

主な機能

  1. 017 つのコンテキスト観点
  2. 02依存関係と規模の確認
  3. 03制約と予算の把握
  4. 04障害影響の評価
  5. 05過去の作業の検索
  6. 06省略できるケースの提示

活用シーン

  1. 01技術判断レポートの作成
  2. 02変更前の依存関係の確認
  3. 03規模や予算の未確定事項の特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/avelikiy/great_cto --skill discovery

インストール後、Claude Code で/discoveryを入力して読み込まれたか確認します。

詳細

ディスカバリー — 隠れた制約を最初に洗い出す

エージェントの出力が悪くなる最大の原因は、コンテキストの不足です。判断を確定する前に、不明な点を列挙して明らかにしてください。

ディスカバリーの7つの観点

重要度の高い依頼では、次の項目を確認し、レポートの「Context」セクションに調査結果を記録してください。

1. これに依存しているのは誰か？
  • 変更対象を利用する他のサービスやチームはありますか？
  • 公開 API や OSS ユーザーなど、外部の利用者はいますか？
  • 互換性を損なう場合、非推奨化の手順はありますか？

検索対象：リポジトリと、アクセス可能なすべての関連リポジトリで grep -rE "import.*<your-module>|require.*<your-module>" を実行します。

2. 現在の規模はどのくらいで、6か月後はどうなっていますか？
  • 現在のトラフィック：リクエスト数/秒、クエリ数/秒、MB/日、1日のアクティブユーザー数
  • ストレージ：主要テーブルの行数、ディスク上のサイズ
  • コスト：LLM とインフラの月額費用
  • 6か月後の予測：線形？指数関数的？不明？

不明な場合は、次のように記載してください。「規模は不明 — 続行する前にユーザーに確認してください。」

3. 絶対に変更してはいけないものは何ですか？
  • 既存の API 契約（後方互換性を維持する期間）
  • レポートや BI が参照するデータベーススキーマのカラム
  • 他のツールが利用するファイル形式
  • 規制上の取り決め（監査ログの保持期間、SLA の RPO/RTO）
4. 予算はいくらですか？
  • 月額費用の上限（LLM ＋ インフラ）
  • 必要な人員：1人で対応するタスクか、複数チームで取り組む作業か
  • スケジュール：「Xまでにリリース必須」か「Yまでが望ましい」か

明示されていない場合は、「小規模プロジェクト、エンジニア1人で1週間、月額予算200ドル未満」をデフォルトとします。このデフォルトをレポートに明記し、ユーザーが訂正できるようにしてください。

5. どの障害モードが重要ですか？

次のように質問してください。「この機能が午前3時に壊れたら、何が原因でページャーが鳴りますか？」

  • データ損失 → CRITICAL
  • ユーザーへの誤った回答 → HIGH
  • 応答の遅延 → MEDIUM
  • UX の悪化（見た目の問題） → LOW

障害モードによって、必要な投資レベルが決まります（例：カナリアが必要か、サーキットブレーカーが必要か、フィーチャーフラグだけで十分か）。

6. これまでに試したことはありますか？
  • Beads を検索します：bd search "<keyword>" — 以前に試されたことはありますか？
  • ドキュメントや決定事項を検索します。このトピックに関する、置き換えられた ADR はありますか？
  • lessons.md を検索します。このパターンについて、過去に得た教訓はありますか？

過去の取り組みがあれば、それを活用してください。やり直す必要はありません。

7. 誰が決定しますか？
  • CTO の承認（gate:plan、gate:ship）が必要ですか？
  • コンプライアンス担当者によるレビューが必要ですか（フィンテックなら PCI、医療なら HIPAA）？
  • RFC が必要ですか（複数チームにまたがる決定）？

出力

レポートの冒頭に、ディスカバリーのセクションを記載します。

## Context

- **Consumers:** <list, or "unknown — TBD with user">
- **Scale:** <today, 6mo projection>
- **Frozen contracts:** <list, or "none identified">
- **Budget:** <cost + time + people>
- **Failure-mode tier:** Critical | High | Medium | Low
- **Prior work:** <links to ADRs/lessons, or "none found">
- **Decision-makers:** <gate or RFC required>

省略する場合

  • nano project_size — ディスカバリーは負担になるため、省略してください。省略したことを次のように記録します：「nano — スキルのルールに従ってディスカバリーを省略しました。」
  • 動作を変更しない純粋なユーティリティの抽出 — 省略してください。
  • 再現手順が明確な、ユーザーからの口頭でのバグ修正依頼 — 省略してください。

よくある落とし穴

  • 決めつけないでください。「ユーザーは X を望んでいると仮定します」と書く場合、その仮定は事実ではなく、質問として Context に記載してください。
  • ユーザーに丸投げしないでください。 ディスカバリーはあなたの仕事です。Glob/Grep/git でわかる限りの情報を集めてください。ユーザーに尋ねるのは、コードから判断できないことだけにしてください。

コメント

Markdown 対応