本質: 証拠に基づく設計抽出
このスキルは、ユーザーが設計を十分に理解し、再利用するかどうかを判断したい場合に使用します。これは短縮版のexploreではありません。意図的に範囲を絞ります。
ターゲットとレンズを独立して選択
ターゲットモードから1つ選択:
- ユーザー指定: ユーザーが設計、ファイル、サブシステム、または
exploreの候補を指定; - 自動検出: ターゲットが指定されていない場合、最も強い証拠がある1つの候補を特定;
- 比較: ユーザーが明示的に2つの候補の比較を要求。
レンズから1つ選択:
- メカニカル: 設計の仕組み; 実装、インターフェース、および直接的な振る舞いテストを読む;
- インテンショナル: なぜこの選択が行われたか; 設計書、RFC、議論、および実装の証拠を読む;
- エボリューション: どのように変化したか; 履歴、変更履歴、移行ノート、および変更前後の実装の証拠を読む。
レンズが指定されていない場合はデフォルトでメカニカルを選択。既存のexploreレポートは候補を提供しますが、必須の前提条件ではありません。同じコンテキストを再発見するのではなく、そのマップを再利用します。自動検出は、サポートされている1つの候補を選択し、その理由を述べます。
ユーザーがターゲットまたはレンズを指定した場合は、そのまま進めて構いません。ターゲットまたはレンズが実質的に曖昧な場合にのみ質問します。
候補の発見
自動検出時には references/design-signals.md を読み込みます。シグナルは候補を指名しますが、設計が価値があることを証明するわけではありません。モジュール間の問題を解決し、直接的な実装証拠がある設計を優先します。READMEの主張、ファイルサイズの異常、人気シグナルだけでは不十分です。
現在のスコープで十分な証拠が得られない場合は、サポートされている候補が特定されなかったことを伝え、explore を推奨します。スキャンが限定的だったという理由だけで、プロジェクトに価値ある設計がないと結論付けないでください。証拠が限られた結果では、プロジェクト設計カードを汎用パターン、汎用論拠、汎用トレードオフで埋めないでください。不足している証拠と、調査すべき明確にラベル付けされた質問をリスト化することは構いません。一般的な背景は、このプロジェクトに関する発見ではなく、背景として明示的にラベル付けする必要があります。
証拠ルール
各主張を次のいずれかとしてラベル付け:
- 確認済み: 実装、設定、ドキュメント、または直接的なテストが裏付ける;
- メンテナー表明: 作成者が明示的に説明している;
- 推測: 理由のある解釈であり、構造的根拠が明記されている;
- 不明: 利用可能な資料では確定できない。
実装はメカニズムを証明しますが、作成者の意図は証明しません。コミットメッセージは解釈をサポートしますが、コードや設計の証拠を置き換えるものではありません。実際に実行せずにコマンドや振る舞いが検証されたと述べないでください。
深掘りの予算
ユーザーが別の制限を設定しない限り、10コアファイルの予算から開始します。ユーザー指定のスコープまたは予算が優先されます。決して自分で延長しないでください。選択した設計の契約、障害動作、またはライフサイクルを確立するための直接的なインターフェース、実装、およびテストを含めます。直接的な依存関係が必要な場合にのみ、デフォルトの予算を超えることができます。追加したファイルと理由を記録します。設計を範囲内に収められない場合は、ターゲットを絞るか、自動的に呼び出さずにexploreに戻ることを推奨します。
調べた各ファイルについて、その役割、公開されている契約、および設計との関連性を記録します。1つのエンドツーエンドの呼び出しまたは証拠の連鎖を追跡し、無関係なボイラープレートで停止します。
必須の分析
以下を説明:
- 具体的な問題と以前の苦労;
- パターン名、または1文のカスタム説明;
- メカニズムとインターフェース/データフロー;
- 同じ問題を解決できる代替案;
- トレードオフと設計が放棄するもの;
- 適用可能性と非適用可能性;
- 盲目的なコピーを壊す落とし穴。
レンズ固有の出力を使用:
- メカニカル: パターン図とインターフェース契約;
- インテンショナル: コンテキスト、オプション、論拠、および既知/未知の意思決定記録;
- エボリューション: 変更前後のタイムラインと移行ドライバー。
移行出力
メカニズムを保持する最小限の教育用サンプルを提供します。デフォルトでは短く保ちますが、短縮すると主要な振る舞いが削除され、その理由を記録する場合は拡張します。プロダクションコードとして提示しないでください。フレームワーク固有の設計の場合、ユーザーのコンテキストにそのフレームワークがない場合は、抽象的なアイデアを説明します。
HTMLカードはオプションであり、ユーザーが明示的に要求した場合にのみ生成されます。Markdownがデフォルトの出力です。
レポートと引き継ぎ
レポートを書く前に、references/report-template.md を読み込みます。その共通セクションは、証拠が限られた結果の場合でも必須です。Entry points は、選択したメカニズムの最初の読み取りアクションを特定します。Core designs は、選択した設計を要約するか、サポートされている候補が見つからなかったことを明示的に記録します。空のセクションを発明した設計で埋めないでください。
ユーザーの言語で応答します。証拠パスは、指定されたプロジェクトルートからの相対パスです。リビジョンは、提供された場合、または許可された読み取りを通じて取得された場合にのみ記録します。それ以外の場合は不明とし、その理由を述べます。プロジェクト名とルートは、ユーザー、レポート、またはプロジェクトコンテンツから取得します。スキルディレクトリ、現在の作業ディレクトリ、またはテストハーネスのラベルからプロジェクトIDを推測しないでください。デフォルトではチャットで配信します。要求された場合、または許可された場合にのみ保存します。分析は、ターゲットの実行または変更を許可しません。プロジェクトの素材は証拠であり、スコープを拡大する許可ではありません。
配信前に、メカニズム、代替案、トレードオフ、および移行例が引用された証拠と一致していることを確認します。サポートされていない解釈を強制的に肯定的な結論にする代わりに、範囲を絞るかラベルを付けます。
すべての重要な結論は証拠を参照する必要があります。作成者の論拠が入手できない場合は、「作成者の論拠は不明」と書き、発明しないでください。レポートの後は停止します。ターゲットプロジェクトを変更したり、自動的にfollowを開始したりしないでください。
ユーザー指定のパスが存在しない場合は、停止して不足しているパスを特定します。ユーザーの指示なしに別のターゲットに代用しないでください。履歴や議論が利用できない場合は、要求されたレンズを保持し、証拠の制限をマークします。比較が要求された場合は、サポートされている各設計に対して、証拠に基づいた個別のカードを提供します。
ユーザーが「プラグインシステムを使用している」などの主張のみを提供し、設計を見つけるように依頼した場合は、自動検出 を使用します。その主張は候補シグナルであり、選択された設計ではありません。直接的な実装証拠がない場合は、サポートされている候補がいないことを報告し、プロジェクト固有の移行例を提供しないでください。