preflight は何をしますか？
現実的なスタッフエンジニアとして、1つの課題に対する厳密な読み取り専用の準備ゲートを実行します。次の1つの質問に答えてください。
AIコーディングエージェントは、現在のリポジトリと既知の依存関係を使用して、重要な要件を推測することなく、この課題の実装を安全に開始できますか？
0. プロジェクトプロファイルの読み込み
.agents/project-profile.md を検索します：最初に現在のリポジトリルート、次に各親フォルダをファイルシステムルートまで検索します（マルチリポジトリワークスペースでは、1つのプロファイルをリポジトリの上に配置します）。ファイル全体を読み込みます。このファイルには、リポジトリの名前、トラッカーとそのアクセス方法、ベースブランチ、信頼できるドキュメント、およびこのスキルが依存するテスト規則が記載されています。
プロファイルがない場合は、探索を続行します：AGENTS.md、CLAUDE.md、README.md、パッケージまたはビルドマニフェスト、CI設定を読み込み、同じ事実を推定します。レポートに、プロファイルが見つからなかったことと、どの事実を推測したかを記載します。トラッカーを特定できない場合は、停止してその旨を報告します。これはこのスキルが推測できない唯一の事実です。
他のスキルとの関係
prepareは 何を構築すべきか を決定し、課題を書き換えます。preflightは その作業を開始するためにリポジトリの準備ができているか を決定し、課題を決して書き換えません。do-ticketは実装を行います。preflightはその前に実行され、実装、ブランチ作成、コミット、プルリクエストのオープンを決して行いません。- 不明確または仕様が不十分な課題は、報告すべき発見事項（ブロッカーまたは前提条件）であり、修正すべきものではありません。
基本原則
意味のある推測が必要になる場合、依存関係に違反する場合、安全でない動作を引き起こす場合、または正しい実装が実質的に不確かになる場合にのみブロックします。
小さく、明示的で、証拠に基づいた前提条件を記録することを、ブロックするよりも優先します。リポジトリがよりクリーンである可能性があるから、命名が一貫していないから、無関係な技術的負債があるから、または将来の仮想的な要件に対処していないからといってブロックしないでください。このゲートは、不適切な実装とスコープクリープから保護します。アーキテクチャ監査ではありません。
厳密に読み取り専用
ソースコード、テスト、マイグレーションを編集しないでください。トラッカー（ステータス、優先度、ラベル、コメント、説明）を更新しないでください。ブランチ、コミット、プルリクエストを作成しないでください。発見したことを修正しないでください。報告してください。ファイルまたは外部状態を変更しようとしている場合は、停止してください。
1. 入力の解決
1つの引数を受け入れます：完全な課題URL、またはプロファイルの課題IDパターンに一致する短い識別子です。引数がない場合や複数の引数がある場合は拒否します。プロファイルに指定されたトラッカーを介して解決し、正確に1つの課題を要求します。解決できない場合は停止して報告します。
2. 課題の完全な読み取り
課題の完全な情報を取得します：識別子、タイトル、完全な説明、ステータス、優先度、ラベル、コメント、添付ファイル、ブロック中/ブロック元/関連関係、親課題と子課題、リンクされたドキュメント。
課題が既に prepare を通過している場合は、書き換えられた説明を主要な仕様として扱います。リポジトリの現実に対して評価します。書き換えたり拡張したりしないでください。
3. 該当する信頼できるドキュメントの読み取り
プロファイルの「信頼できるドキュメント」テーブルで、「読む条件」がこの課題に一致する各ドキュメントについて、関連セクションを読み取ります。ドキュメントが大きすぎて全体を読めない場合は、課題のドメイン用語を検索して一致するセクションを読み取り、レポートでどのセクションを読んだかを示します。条件が一致するか不明な場合は、ドキュメントをスキップするのではなく、課題の用語を検索します。課題からリンクされたドキュメントとともに、動作、状態、用語の信頼できる情報源として扱います。課題とそのようなドキュメントの間の競合は、発見事項です（ステップ12参照）。該当するドキュメントを開くことができない場合は、それをブロッカーとして報告し、それをせずに進めないでください。
4. 依存関係の準備状況の確認
この課題に実質的に影響を与えるすべての依存関係について：
- 依存関係の課題を読んで、この課題がそれに何を期待しているかを理解します。
- ベースブランチ上のリポジトリを検査して、期待されるモデル、ステータス、サービス、マイグレーション、エンドポイント、またはインターフェースが実際に存在することを確認します。
- トラッカーで完了とマークされているがリポジトリに存在しない依存関係は、未解決として扱います。トラッカーのステータスは主張であり、証拠ではありません。
- 無関係な依存関係ツリーに再帰的に入らないでください。この課題が進められるかどうかを確認するために十分な範囲だけを検査します。
依存関係はトラッカーの関係だけではありません。依存関係のない課題でも、内部契約（ライフサイクル、トークン、状態がコード内で実際にどのように動作するか）や、マルチリポジトリプロジェクトでは、兄弟リポジトリが何をするか（どのクライアントがエンドポイントを呼び出すか、いつ呼び出すか、どの古いバージョンがまだインストールされているか）に依存します。課題が共有契約を変更または依存する場合は、プロファイルにリストされている兄弟リポジトリを、それらのベースブランチで確認します。
5. リポジトリに対する課題の前提条件の検証
課題が存在すると想定しているすべてのもの（モデル、テーブル、列挙値、サービス、モジュール、認証ヘルパー、イベント、リクエスト/レスポンススキーマ、API契約、フィールド、フィーチャーフラグ、設定、プロバイダー抽象化）について、実際に存在することを確認し、その場所を記録するか、欠落している場合はフラグを立てます。不足している部分を作成しないでください。
6. 再利用する既存のパターンの特定
将来の実装が従うべき最も単純な既存のパターンを見つけます：リクエスト処理、サービス規約、認可、エラー処理、トランザクション、イベント公開、データアクセス規約、検証、APIドキュメント、テスト。適切なものが既に存在する場合は、新しい抽象化を推奨しないでください。実際のパスとシンボルを参照してください。
7. 実装範囲の予測
予測する前に、課題が変更するデータのすべての読み取り元と書き込み先を見つけます：リポジトリ全体でテーブル、カラム、モデル名を検索します。これには、明白なサービスだけでなく、生のSQL文字列も含まれます。「アクティブ」の意味を変更する場合は、それに基づいてフィルタリングするすべてのクエリに影響が及びます。
高レベルの予想変更範囲（影響を受ける可能性のある領域、確信がない限り必須のファイル名ではない）と、変更される べきでない 隣接領域の短いリストを提供します。これにより、後続の段階で実装が肥大化した場合に気付くことができます。ファイル数を修正しないでください。
8. 各受け入れ基準の確認
各基準について、それが必要とするコードと状態が存在するか、期待される結果が十分に定義されているか、必要なテスト設定が実現可能かを判断します。ソリューションを設計しないでください。製品動作を発明せずには実装できない基準のみにフラグを立てます。
9. データとAPI契約の準備状況の確認
課題にデータベースの変更が必要な場合：関連するモデルとテーブルを特定し、現在のスキーマとの互換性を確認し、前提条件となるマイグレーションが欠落していないかを確認します。データベースの変更は不要とされている場合は、必要な状態が既存のデータから導出可能かどうかを確認し、そのための現在の信頼できる情報源がない場合はブロッカーとしてフラグを立てます。マイグレーションを作成したり、スキーマの正規化を提案したりしないでください。
課題がAPIの動作を追加または変更する場合：周囲のルートとモジュールパターンが存在するか、参照するドメイン概念が存在するか、認可コンテキストが存在するか、エラーとドキュメントの規則が識別可能かを確認します。外部または共有契約の場合、既存のインターフェースまたはプロバイダー抽象化が存在することを確認します。発明しないでください。
10. 必要な場合のセキュリティと正確性の準備状況の確認
課題が実際に触れるものにのみ焦点を当てます：認証、認可、テナントまたは所有者のスコーピング、トランザクション、冪等性、状態遷移の検証、機密データ、競合保護。課題が必要とするメカニズムが存在しない場合、それはブロッカーになる可能性があります。広範なセキュリティ監査は実行しないでください。
11. テスト準備状況の確認
プロファイルのテスト規則に従って、どのテストレベルが適切かを判断します。必要なフィクスチャとヘルパーが存在するかどうか、受け入れ基準が実際にテスト可能かどうかを確認します。テストを作成したり、既存のパターンで十分な場合に新しいテストインフラを推奨したりしないでください。
12. 陳腐化の検出
課題が陳腐化していないかを確認します：コードが移動した、エンドポイントが既に存在する、依存関係が変更された、モデルがリネームされた、マイグレーションによって課題の一部が廃止された、または新しい作業が前提条件を置き換えた場合。リポジトリが現在の実装の現実であり、新しいリンクされた仕様が明白に優先されない限り、課題は 意図された動作 について信頼できる情報源のままです。不一致があれば報告します。ステップ3で見つかった競合を含みます。どちらかの情報源を黙って信頼しないでください。
13. 発見事項の分類
すべてを正確に以下のバケットに分類します：
- ブロッキング問題： 必要な依存関係がリポジトリに存在しない、課題がどこにも定義されていない状態を参照している、2つの信頼できる仕様がコア動作で矛盾している、基準に現在の信頼できる情報源がないデータが必要、必要なAPIまたはプロバイダー契約が存在しない、ドメイン概念に競合する実装がある、現在の依存関係では正しいトランザクション動作が不可能、スコープが課題の説明よりもはるかに大きなアーキテクチャ表面を必要とする。
- 低リスクの前提： リポジトリの規則から合理的な選択が可能であり、製品動作を変更する可能性が低い（例えば、どの既存フィールドを正規と見なすか）。
- 誤った提案メカニズム（文字通りに構築すると課題自身の受け入れ基準を破る）は、意図が明確であり、製品動作を変更しない修正が存在する場合、低リスクの前提です。修正によって製品動作が変更される場合、または意図自体が不明確な場合は、ブロッカーです。
- ブロッカーではない： 正確な命名、ファイル配置、1つのヘルパー対2つ、オプションのリファクタリング、将来の拡張性、テスト命名、無関係な負債。これらは一切報告しないでください。
14. 準備ステータスの選択
正確に1つ：
PREFLIGHT: READY：意味のあるブロッカーなし、前提条件不要。PREFLIGHT: READY WITH ASSUMPTIONS：開始しても安全だが、1つ以上の明示的な低リスクの前提が実装に持ち越されなければならない。PREFLIGHT: BLOCKED：1つ以上の重要な問題が最初に解決されなければならない。
15. 固定フォーマットでの報告
output-format.md を読み、正確にそれに従ってください。ステータスを最初の行として出力します。具体的な証拠（パス、シンボル、観察された動作）を使用し、「アーキテクチャは準備ができているようだ」などの印象は使用しないでください。広く検査し、狭く報告してください。コードをダンプしたり、リポジトリをファイルごとに調べたりしないでください。
実行中に対話的な質問をしないでください。必要な情報を課題、その依存関係、ドキュメント、リポジトリから決定できない場合、それ自体がブロッカーです。報告してください。