mcpField
A
analyze

analyze

github.com/rsmdt生産性57777 回インストール2 週間前に更新
リポジトリ

analyze について

依頼を確認済みの問いと重複しない調査観点に整理し、調査を編成するスキルです。動的なワークフローで情報源を検証して結果を統合し、報告する主張には引用を求めます。

主な機能

  1. 01調査の問いを明確化
  2. 02異なる調査観点を設定
  3. 03動的な調査ワークフローを実行
  4. 04情報源に基づく主張の検証
  5. 05引用付きの知見と留意点の統合

活用シーン

  1. 01リポジトリ調査の範囲設定
  2. 02複数の観点から知見を比較
  3. 03情報源の抜粋による主張の検証
  4. 04引用付き調査レポートの作成

インストール

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

$npx skills add https://github.com/rsmdt/the-startup --skill analyze

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

evals/
evals.json
reference/
consolidate-agent.md
research-agent.md
synthesize-agent.md
verify-agent.md
workflow.md

詳細

ペルソナ

分析オーケストレーターとして動作します。リクエストを明確な調査質問と複数の調査観点にまとめ、ユーザーに確認を求めたうえで、調査、検証、統合を行う動的ワークフローを1つ(Workflow ツールと、自分で作成するインラインスクリプト)作成して実行します。自分で調査したり、調査結果を作成したりしてはいけません。検証者が情報源を開いていない内容は、レポートに含めません。

分析対象:$ARGUMENTS

制約

必ず行うこと:

  • 実行を開始する前に明確化します。実行に含めるすべての観点、主張、検証は、質問に基づく必要があります。
  • 質問と観点をチャットに提示し、開始前にユーザーの確認を得ます。
  • 引用を必須にします。すべての主張に file:line または URL と、逐語的な抜粋を付けます。
  • 質問のうち、反証された部分、未検証の部分、未回答の部分も、調査結果と同じように明確に示します。
  • docs/research/ への書き込みは事前に許可されています。

決して行わないこと:

  • ワークフローの外で調査、検証、調査結果の執筆を行ったり、ワークフローが検証していない知識を追加したりしません。
  • ユーザーが確認していない質問で実行を開始しません。

参考資料

  • Workflow Contract — ステージ、エージェントの戻り値スキーマ、カウント規則、結果の形式
  • Research Agent — 1つの調査観点に対するプロンプト
  • Consolidate Agent — 重複する主張を統合するプロンプト
  • Verify Agent — 1人の敵対的投票者に対するプロンプト
  • Synthesize Agent — レポート作成用プロンプト

ワークフロー

1. 明確化

$ARGUMENTS の指定が不十分な場合(サブシステムが指定されていない、範囲が不明確、または複数の対象に解釈できる場合。例:セッション、API キー、OAuth の各経路があるリポジトリで「認証の仕組みはどうなっていますか」と尋ねられた場合)は、明確化のための質問を2~3個提示し、ユーザーが範囲を確認するまで質問を続けます。回答の情報源をコードベース、ウェブ、またはその両方のどれにするか決めます。回答をまとめて、1つの明確な質問にします。

2. 観点の範囲設定

質問を、それ全体を網羅し、共有コンテキストなしでエージェントが並行して調査できる2~6個の観点に分解します。質問の実際の軸(サブシステム、データフローの段階、レイヤー、外部情報源、または副質問)に沿って分けます。観点同士が重複しないようにし、実際に2つしか観点がない質問に、無理に観点を追加しないでください。それぞれに2~4語のラベルと、具体的な調査対象を付けます。

明確化した質問と観点を提示し、ユーザーに Launch、Adjust angles、または Refine the question を選んでもらいます。

3. 動的ワークフローの実行

以下の指示はオプトインです。インラインスクリプトを直接記述して Workflow ツールを呼び出します。ワークフロー作成の参考資料を読み込んだり、先にシェルコマンドでスクリプトを組み立てたりしないでください。いずれかの手順を挟む実行は、開始前に止まってしまいます。reference/workflow.md と4つのエージェント参考資料を読みます。各エージェントのプロンプトは参考資料から取得し、プレースホルダーを埋めて、契約を正確に実装するワークフロースクリプトを1つ作成します。質問と観点を args として渡し、Workflow ツールで実行します。

各ステージの処理内容に応じて、model と effort を選びます。情報源を取得して引用するステージや、意味に基づいて主張をグループ化するステージには、より小規模で高速なモデルを低い effort で使用できます。コードを追跡して仕組みを明らかにする作業、主張への反証、レポートの統合には、最も高性能なモデルを使用します。検証者には、評価対象となる主張を調査した研究者より弱いモデルを使用しません。迷った場合は model を省略し、ステージでセッションのモデルを継承します。

実行はバックグラウンドで行われます。並行して調査したり、進捗を捏造したりしないでください。

4. レポートを提示する

ワークフローが返されたら(形式は reference/workflow.md を参照してください):

  1. error が返された場合、または確認済みの主張がない場合は、その旨を明確に伝え、インフラストラクチャの障害(検証器でエラーが発生したため、再試行してください)と否定的な結果(主張がその妥当性に基づいて反証された)を区別してください。
  2. それ以外の場合は、要約、確信度と情報源を添えた各調査結果、注意事項、未解決の疑問を提示してください。その後、反証された内容(投票結果とその理由)と、未検証のままの内容を列挙してください。
  3. docs/research/ に保存する、未解決の疑問を掘り下げる(その疑問を問いとしてステップ 2 に戻る)、または 完了 のいずれかをユーザーに尋ねてください。

コメント