mcpField
S
scout

scout

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

scout について

scout は、本番環境の実践例や障害要因を調べるリサーチスキルです。アーキテクチャや技術選定に向け、検索数を制限しながら標準、事例、事後分析を照合します。

主な機能

  1. 01情報源を権威性で分類
  2. 02検索数と取得ページ数を制限
  3. 03標準、事例、事後分析を照合
  4. 04構造化された Scout Report の生成
  5. 05適合性の検討を /clarify、変更計画を /changeset に振り分け

活用シーン

  1. 01本番事例に基づく技術パターンの評価
  2. 02運用上のトレードオフや障害要因の調査
  3. 03アーキテクチャ判断に向けた根拠の準備

インストール

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

$npx skills add https://github.com/venhdev/zenforge --skill scout

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

詳細

scout — 実システムのベストプラクティスと本番環境アーキタイプエンジン

ドメイン評価基準

1. 情報源の権威性の階層

技術的な問い合わせに対し、権威ある本番環境の情報を照合して検証します。

  • Tier 1（標準規格と公式仕様）：RFC、言語仕様、クラウドベンダーのリファレンスアーキテクチャ、正式な技術論文。
  • Tier 2（大規模本番環境のエンジニアリング）：実績のある大規模エンジニアリング組織（Stripe、Netflix、Cloudflare、Discord、Uber、Meta など）の技術ブログやアーキテクチャに関する公開情報。
  • Tier 3（実運用での教訓と事後分析）：エッジケース、運用上のボトルネック、障害モードを明らかにする、文書化された本番環境の障害、事後分析、根本原因分析。
  • 除外フィルター：SEO 対策に最適化されたコンテンツファーム、未検証の個人ブログ記事、ベンダーのマーケティング資料、精査されていない AI による要約は除外します。
2. 検索と採用の上限
  • 調査上限：1 回の調査で、検索クエリは最大 8 件、取得ページは最大 10 件です。
  • 採用上限：シグナルの強い主要な情報源を 3～5 件統合します。
  • 早期終了条件：主要な証拠を照合して、標準的なパターンと既知の障害モードを特定できた時点で検索を終了します。

標準出力契約

# Scout Report: <Topic / Inquiry>

## 1. Executive Summary
- **Canonical Production Archetype**: <Boring, battle-tested standard approach adopted by industry leaders>
- **Operational Reality**: <Key complexity, maintenance overhead, or scaling bottleneck in practice>

## 2. Industry Precedents & Battle Scars
| Source / Organization | Pattern Deployed | Production Scale / Context | Known Failure Mode / Trade-off |
| :--- | :--- | :--- | :--- |
| <Org / Paper> | <Architecture / Tool> | <Traffic, Data Volume, SLA> | <Failure point, latency spike, cost trap> |

## 3. Recommended Baseline vs. Traps
- **Recommended Baseline**: <Simplest robust architecture meeting requirements without premature optimization>
- **Premature Traps to Avoid**: <Over-engineered patterns or hype-driven tools that introduce unnecessary failure modes>

## 4. Primary Citations
- [<Source Title>](<Verified URL>) — <Core insight or concrete data point extracted>
振り分け
  • トレードオフを慎重に検討する場合や、プロジェクトへのアーキテクチャの適合性を評価する場合 →（/clarify 経由）。
  • 基本方針が受け入れられ、十分な裏付けがあり、呼び出し元が変更計画を求めている場合 →（/changeset 経由）。

実行プロトコル

  1. クエリの照合とディスパッチ：

    • 標準規格や RFC、大規模エンジニアリングの事例、障害の事後分析を組み合わせた、対象を絞った検索クエリを 2～3 件作成します。
    • 問い合わせの複雑さ、または呼び出し元が指定した予算に応じて、research サブエージェントを動的に起動します（役割：Real-System Research Scout）。以下を提供します。
      • 照合済みのクエリと検索予算（最大 8 件のクエリ、取得ページは最大 10 件）。
      • 上記の標準出力契約を必須の出力契約として指定します（詳細な比較資料が必要な場合は、.agents/scratch/scout-dossier.md に出力します）。
    • 合成前に URL ツールを使ってページ本文全体を確認するようサブエージェントに指示します。検証済み URL のみを引用し、検索結果のスニペットだけをもとに情報を合成しないよう徹底します。

  2. 合成と終了：

    • 完成したレポートを会話に出力し（別ファイルに出力した資料があればその参照先も示し）、直ちにターンを終了します。

コメント

Markdown 対応