research について
ソフトウェアのスライス作業向けに、ガバナンス上の制約とコードマップをまとめ、`research.md` として保存するリサーチスキルです。引用、利用側での検証、鮮度確認を重視します。
主な機能
- 01ガバナンスとコードマップを並行調査
- 02スレッド間の知見と設計への影響を統合
- 03証拠文書 `research.md` を作成
- 04主張にエンティティまたはコード位置を引用
- 05リサーチの鮮度を確認
活用シーン
- 01スライス設計前に制約とコードの注目箇所を調査
- 02計画作成時にリサーチを検証
- 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— 助言を確認します。ドリフトがある場合は、影響を受けたセクションのみを更新してから、ベースラインを再記録します。