mcpField
R
research

research

github.com/davidleeエージェントワークフロー266 回インストール3 日前に更新
リポジトリ

research について

ソフトウェアのスライス作業向けに、ガバナンス上の制約とコードマップをまとめ、`research.md` として保存するリサーチスキルです。引用、利用側での検証、鮮度確認を重視します。

主な機能

  1. 01ガバナンスとコードマップを並行調査
  2. 02スレッド間の知見と設計への影響を統合
  3. 03証拠文書 `research.md` を作成
  4. 04主張にエンティティまたはコード位置を引用
  5. 05リサーチの鮮度を確認

活用シーン

  1. 01スライス設計前に制約とコードの注目箇所を調査
  2. 02計画作成時にリサーチを検証
  3. 03コード変更後に該当セクションを更新

インストール

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

$npx skills add https://github.com/davidlee/doctrine --skill research

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

詳細

リサーチ

設計前のリサーチラウンドでは、後続のステージが再調査する代わりに参照する、永続化されたエビデンス成果物 research.md を作成します。2つの読み取り専用スレッド(ガバナンスの適用可能性、コードマップ)と、スレッドを横断した統合結果を、オーケストレーションエージェントが1つのドキュメントにまとめます。

成果物は .doctrine/slice/NNN/research/ に置かれます。スライスフォルダー内に直接配置され、その場で Git の追跡対象から除外されます。ランタイム層は破棄可能な作業用エビデンスです。永続的な知見はスライスの終了時に抽出されます。

コマンド: doctrine slice research <id> — ラウンド開始時に実行します(リサーチフォルダーを作成し、古さ判定の基準となる baseline.toml を記録します)。また、成果物を使用するたびに再実行して鮮度を確認します。これは助言であり、ゲートではありません。ドリフトの出力は更新を促すもので、コマンドは常に成功します。フラグと仕組みについては、CLI のヘルプを参照してください。

成果物 — research.md

必須のひな形です。更新ラウンドではセクションをその場で改訂し、追加セクションは自由形式で記述できます。

  • ヘッダー — 各スレッドを実行した担当者/処理、ベースラインの参照先。
  • 検証凡例 — 以下の ✓ に関するルール。
  • スレッド 1 — ガバナンスの適用可能性 — 拘束力のある制約、適用対象外として確認した事項(明示した理由を含む)、改訂候補。
  • スレッド 2 — コードマップ — 変更の可能性が高いファイル(ホットスポット)、引用付きの事実、命名の先例。
  • スレッド横断の知見 — スレッド間の接点や矛盾。多くの場合、最も価値の高いセクションです。
  • 設計入力の差分 — このリサーチによって意図した設計がどう変わるか。

併せて raw/<thread>.md(スレッドの出力そのまま)と baseline.toml(コマンドが記録)があります。

引用形式

  • ガバナンスに関する主張は、永続的なエンティティ ID を引用します。
  • コードに関する主張は、file:line を引用します。
  • 引用のない主張は、定義上、検証できません。

検証の規律

  • ✓ = 主張を使用するエージェントが独自に検証した(引用箇所を grep または読み取りで確認した)ことを示します。印がないものはリサーチ担当者の主張であり、引用はありますが確認されていません。
  • 設計と計画では、✓ が付いた行、または使用時点で検証した行のみを根拠として使用できます。
  • 検証は非対称です。すべてを確認するのではなく、根拠として使うものを検証します(根拠となる主張ごとに grep を1回程度)。

ラウンドの実行

  • プロジェクトのリサーチエージェントをスレッドごとに1つ起動し、読み取り専用で実行します。各スレッドの標準出力を research/raw/<thread>.md に保存し、大量の出力を会話に直接含めないでください。
  • リサーチエージェントの内容(コマンド、モデル、期待事項)はプロジェクトごとに定義されています。プロジェクトのガバナンスドキュメントにある Research agents セクションを参照してください。Doctrine には実行ツールは付属していません。
  • 段階的なフォールバック: プロジェクトでリサーチエージェントが定義されていない場合は、自分で各スレッドを実行するか、ラウンドを省略して、その旨を成果物のヘッダーに記載します。
  • リサーチ担当者はファイルやメモリーを書き込みません。オーケストレーションエージェントが raw/ の内容を整理して成果物にまとめます。大量の内容については、ドキュメントから raw/ を参照します。

プロンプトで求める事項

各スレッドのプロンプトでは、必ず次を要求します。

  • 上記の引用形式を使うこと。
  • 構造化された適用対象外の形式を使うこと(除外する権威ある情報源をそれぞれ明記し、理由を示す)。
  • 成果物のセクション構成に沿った形式で出力すること。
  • 前置きを付けないこと(軽量モデルは前置きを加えるため、取りまとめ時に削除します)。

誰がこれを呼び出すか

定義はここに一元化し、呼び出すスキルには短い助言のみを記載します。

  • /slice — スコープを決めた後、/design の前にラウンドを実行します。
  • /design — 成果物を使用します。スレッド 1 がガバナンスの大半を調査する役割を担い、設計上の主張では research.md を引用します。
  • /plan — 古さに関する助言を確認し、スレッド 2 のホットスポットマップをもとにセレクターを作成します。
  • /phase-plan — 助言を確認します。ドリフトがある場合は、影響を受けたセクションのみを更新してから、ベースラインを再記録します。

コメント