mcpField
P
preflight

preflight

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

preflight について

preflight は、ルーティング後に使う範囲限定の事前調査スキルです。調査の停止条件を定め、次の工程に進む前に前提や未解決の問いを整理します。

主な機能

  1. 01事前調査の深さを見積もる
  2. 02成果物や関連資料を順に確認
  3. 03具体的な停止条件を事前設定
  4. 04入力・前提・リスクを整理
  5. 05次に進む工程を提示

活用シーン

  1. 01設計開始前のタスク範囲の明確化
  2. 02障害診断の調査範囲の設定
  3. 03実装前の依存関係や曖昧さの把握

インストール

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

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

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

詳細

事前調査

/route は /preflight にルーティングします。/route に置き換わるものではありません。直近のニーズが範囲の限定された事前調査であると、ルーティングによって判断された後にのみ使用してください。適用するスキルの経路をまだ選んでいない場合は、作業を止めて、まず /route を使用してください。

これから次の作業に取りかかります:$ARGUMENTS

まず、作業の内容を理解する必要があります。直近のタスクは、この予備調査にどれだけ労力をかけるべきかを正しく判断することです。

調査が足りなくても、やりすぎても問題です。ちょうどよい範囲を見極め、トークンをできる限り残した状態で臨んでください。

次のようなことが求められる場合があります。

  • 曖昧なタスクを明確にする
  • 不具合を体系的に診断する
  • 実装範囲に合った、十分に検討された設計ドキュメントを作成またはレビューする
  • 周到に準備された計画を効率よく実行する
  • サブエージェントに委任して、自分のコンテキストを保つ

このスキルを使って、タスクが /slice、/design、/execute、またはその他の適用スキルの対象かどうかを判断してはいけません。その判断はすでに済んでいる必要があります。

/preflight が適切か判断できない場合は、このスキルではなく /route が必要でしょう。

ユーザーに適切な確認質問をするために必要なことだけを調べてください。たとえば、どこまで詳しく調査すべきか、何がまだ曖昧か、どの前提なら安全に引き継げるかなどです。

途中で生じた疑問を片っ端から追いかけていると、ヘリウム風船のように大空へ消えてしまいます。

その代わりに、次の手順に従ってください。

  1. 目の前にある資料を読む
  2. 関連する /retrieve-memory と /canon を確認する
  3. 調査を広げる前に、調査の停止条件を確認する
  4. 事前に、次の内容を明確にして、声に出して伝える。
  • 具体的に、何を知る必要があるか。
  • すべての答えが揃っていなくても、具体的に、どの時点で調査を止めるか。
  1. 好奇心を持って追加の疑問を集めつつ、それを追いかけて先走らない。
  2. 停止条件を満たしたら、調査を止める。
  3. 準備ができたと宣言する前に、次の見出しを使って批判的な評価を提示する。
  • 確認済みの入力情報
  • 次のステップに引き継ぐ前提
  • 未解決の疑問、リスク、依存関係
  • 資料間、または設計と実装範囲の間に矛盾が見られる場合を含む、緊張関係や曖昧さ
  1. タスクが実装を伴う場合、次のいずれかを明示しない限り、「作業を進める準備ができています」「ブロッカーはありません」などと結論づけてはいけません。
  • 適用される資料を読んだ結果、未解決の疑問は残っていない
  • 未解決の疑問は残っているが、実装上の前提として意識的に受け入れている
  1. スコープを左右する不確実性は、確実なブロッカーではなくても重要なものとして扱ってください。操作の意味、マッピングや定数の管理主体、フェーズ境界の曖昧さ、ウィジェットや API の選択、設計と実装者の裁量の違いなどを指摘してください。
  2. 重要な発見、未解決の疑問、未解決のトレードオフをユーザーに伝えてください。
  3. 次に適用するステップを示してください。次のスキルやワークフローへの移行、または追加調査の必要性を提案してください。

ユーザーから求められた場合は、この手順を繰り返してさらに明確にしてください。

ガイダンス

幅広く高いレベルから始め、必要に応じて掘り下げます。

検索の順序:

  • 提供されたアーティファクト
  • 関連ファイル、リンク先のドキュメント、アーティファクト
  • doctrine search "<query>" — 所有元のアーティファクトを特定できない対象を見つける、最も手軽な方法です。エンティティコーパス全体を対象に、関連度順に並べた結果を返します。メモリやリファレンスドキュメントは検索対象外で、デフォルトの種別にはポリシーと標準が含まれません。対象範囲と範囲を広げる方法については、lib:reference/using-doctrine.md を参照してください。
  • 関連するガバナンス文書(ADR、標準、ポリシー) — /canon を参照してください
  • .doctrine/spec/tech/ 配下の関連技術仕様
  • /retrieve-memory
  • バックログ(backlog list / backlog show <ID>) — この作業はすでに記録されているか、関連する未完了項目はどれかを確認します
  • ナレッジレコード(doctrine knowledge list) — 未解決のレコードが、この作業範囲を妨げたり、方向づけたりしていないかを確認します。引き継ぐことにした前提は、/knowledge を使って ASM として記録します。
  • 関連アーティファクト(暫定的なもので、古くなっている可能性があります)
  • コード

ガードレール

  • /preflight に /route の役割を奪わせないでください。
  • 範囲を限定した調査を、実装を始めてよいという許可と見なさないでください。
  • 新たな関心事が出てきたからといって、範囲を広げないでください。
  • 「コーディングを始められること」と「資料がそろっていること」を混同しないでください。準備が整った状態とは、残る不明点を明らかにし、解決するか、意識的な前提として明示した状態です。

ユーザーの了承を得ずに実装を開始しないでください。

コメント