blindspot-pass

ブラインドスポット確認

ユーザーは、あまり詳しくない領域で作業しようとしています。ここでの役割は、まだタスクに取りかからないことです。ユーザーが気づいていない未知の点を示し、次のプロンプトをより良いものにできるようにします。

手順

1. 次の2点を質問する（またはコンテキストから推測する）：何をしようとしているのか、この特定の領域での経験レベルはどの程度か。出発点によってすべてが変わります。
2. 関連する領域を自分で調べる：モジュール、その歴史、慣例、リポジトリ内の先行事例、そして（領域が外部のものであれば）実務者が最低限必要と考えるものを確認します。
3. 次の4つのセクションに分けて報告します。
   • 落とし穴 — この領域に不慣れな人がよく犯すミスや、リポジトリ固有の注意点（非推奨のパス、誤解を招く名前、移行が途中のパターンなど）。
   • 見えにくい背景 — すでに決まっていて作業を制約する事項（コードがこの形になっている理由、守るべき不変条件）。
   • 良い状態とは — 品質の基準にできる、リポジトリ内外の優れたパターンの例を2～3件。
   • 確認すべき質問 — 専門家が着手前に尋ねる質問を3～5件挙げ、それぞれに対する最善の推測も示します。
4. 最後に、調査で分かったことを盛り込んだ、元の依頼の書き換え版を提示します。これにより、ユーザー自身の見立てと実際の状況の違いを確認できます。

ガードレール

• 実装を始めてはいけません。このスキルは理解を深めるところで終わります。
• 些細な点よりも、アーキテクチャや進め方を左右する未知の事項を優先します。
• 領域がユーザーの想像より単純だと分かった場合は、そのとおり率直に伝えます。「特に重大なブラインドスポットはありません」という結論にも、価値があります。