Windows Protocols コーパスナビゲーター

概要

• Markdown コーパスは既にローカルに抽出されており、SKILL.md の隣に配置されています。
• このスキルではローカルファイルのみを使用してください。ネットワークルックアップは行わないでください。
• 通常の使用時にダウンロードやセットアップコマンドを実行しないでください。

このスキルは、Microsoft Open Specifications Markdown の構造優先のナビゲーションと根拠に基づいた回答に最適化されています。

コーパスレイアウト

• README.md — 3つのセクション（概要ドキュメント（ドメインマップ）、技術ドキュメント（仕様の完全リスト）、参考ドキュメント）を含むインデックス。概要ドキュメントはトップに配置されており、主題の発見に使用します。
• LEGAL.md — 法的および再配布に関する通知。
• <PROTOCOL-ID>/ — プロトコルディレクトリ（概要、技術、参考）で、このフォルダの直下に配置されます。
• <PROTOCOL-ID>/<PROTOCOL-ID>.md — プライマリ Markdown 仕様コンテンツ。
• <PROTOCOL-ID>/media/ — Markdown で参照される抽出済みの図とイメージアセット。

コーパスドキュメントタイプ

• 概要ドキュメント — 関連プロトコルを主題別（ファイルアクセス、認証、ストレージ、リモートデスクトップなど）にグループ化したドメインマップ。各ドキュメントはシステム機能を説明し、メンバープロトコルとその役割をリストアップし、仕様への多くのリンクを含みます。主題の発見のためのプライマリエントリーポイントとして使用します。
• 技術ドキュメント — ワイアフォーマット、メッセージシンタックス、動作の詳細を含む個別プロトコル仕様。
• 参考ドキュメント — 補足参考資料（エラーコード、共有タイプなど）。

ドメイン別プロトコルクラスター

概要ドキュメントを発見に使用する場合、以下のクラスターテーマが想定されます:

• 認証: Kerberos、NTLM、SPNEGO — ファイルアクセス、RDP、グループポリシーのコア。
• ファイルアクセス: SMB/CIFS ファミリー、DFS、WebDAV、共有タイプ（FSCC、FSA）。
• リモートデスクトップ: ベース + グラフィックスパイプライン、ゲートウェイ、仮想チャネル（クリップボード、デバイス、トランスポート）。
• ストレージ: ディスク/ボリューム管理、シャドウコピー、EFS、バックアップ、リムーバブルメディア。
• グループポリシー: コアプロトコル + 拡張; AD とファイルアクセスに依存。
• ネットワークアクセス保護: PEAP 上の SoH/SoHR; DHCP/VPN/TSGU/IPsec 実装。
• コンテンツキャッシング: ピア検出、取得、ホストキャッシュ; SMB/HTTP と統合。
• ファイルサービス管理: FSRM、リモート VSS、分類。
• ライツマネジメント: 保護されたコンテンツの公開/使用。
• 仮想ストレージ: SMB 上のリモート共有仮想ディスク。

プロトコルの命名とスコープ

• MS-... ドキュメントは Microsoft プロトコル仕様です（ワイアフォーマット、動作、ステートマシン、構造）。
• ファミリーはプレフィックスを共有します（例えば MS-RDP*、MS-AD*、MS-MQ*）。

ユーザーが広い質問をした場合、ファミリープレフィックスから始めて特定のプロトコル ID に絞り込んでください。

使用する場合/使用しない場合

このスキルは、ユーザーが以下を求めている場合に使用してください:

• プロトコルセマンティクス、メッセージフロー、フィールド定義、またはシーケンシングルール。
• 関連仕様間の相互参照分析。
• Open Specifications ドキュメントのセキュリティセマンティクスと製品動作の区別。

このスキルを以下のプライマリソースとして使用しないでください:

• API 使用チュートリアル、SDK ハウツーステップ、または実装クイックスタート。
• プロトコル仕様に基づいていない製品構成ガイダンス。

必要なプロトコルがルートレベルの MS-* ディレクトリにない場合、それを明示的に述べて、ユーザーに正確なプロトコル ID または狭い機能スコープを求めてください。

ナビゲーション戦略

• ドメイン/主題質問（ファイルアクセス、認証、ストレージ、リモートデスクトップなど）: README の対応する概要ドキュメントから始めます。それを使用してどの仕様を読むべきかを特定するマップとして使用します。そのリンクをたどってそれらの仕様に入ります。
• プロトコル ID 質問: ID が既知の場合は、仕様に直接移動します。
• 原則: 概要ドキュメントは主題の発見のためのプライマリエントリーポイントです。README は概要ドキュメントのインデックスと仕様の完全なリストを提供しますが、概要ドキュメントに含まれるセマンティックマッピング（主題 → プロトコル）は含まれません。
• アンチパターン: README キーワード検索だけに依存しないでください。README の浅い grep は関連のないドメインからプロトコル ID を返す可能性があります。概要ドキュメントは策定済みの主題からプロトコルへのマッピングを提供します。

ナビゲーションワークフロー

1. 主題質問の場合: 質問からドメインを識別し、README の概要ドキュメントにマッチさせ、リンクされたメンバー仕様を取得するためにそれを読み、その仕様へのリンクをたどります。
2. 既知のプロトコル ID の場合: README.md とディレクトリ名（<PROTOCOL-ID>/）で検証してから、仕様を開きます。
3. 深い読み込みの前に、仕様の目次（<summary> ブロックと番号付きエントリ）から始めます。
4. セクションを意図別に読みます: 方向付け/バージョニング、メッセージまたは構造シンタックス、動作とシーケンシング、セキュリティと製品動作に関するノート。
5. 要件が分割される可能性がある場合、ベース仕様と拡張仕様を相互チェックします。
6. 明確なプロトコル ID と正確なセクション見出しで回答します。確認された事実と推論を分離します。

リンクのフォロー

• 概要ドキュメントには参考資料セクション（多くの場合 1.3）とメンバー仕様への広範なインラインリンクが含まれます。パスを推測するのではなく、これらのリンクをたどってください。
• リンクグラフ（概要 → 仕様 → 関連仕様）は意図されたナビゲーション構造です。
• 仕様が型、拡張、または依存関係に関して別の仕様を参照する場合、そのリンクをたどって権威あるソースに到達します。
• 関連情報が見つかるまでリンクをたどり続けます。最初にトピックに言及するドキュメントで停止しないでください。

標準仕様構造（コーパスガイド）

コーパスは非常に一貫しています。最も一般的なトップレベルシーケンスは:

• 1 Introduction
• 2 Messages
• 3 Protocol Details
• 4 Protocol Examples
• 5 Security

一般的な 1.x 方向付けサブセクションには以下が含まれます:

• 1.1 Glossary、1.2 References、1.3 Overview
• 1.4 Relationship to Other Protocols
• 1.5 Prerequisites/Preconditions
• 1.7 Versioning and Capability Negotiation

一般的な 3.x.y 動作サブセクションには以下が含まれます:

• Abstract Data Model
• Timers
• Initialization
• Higher-Layer Triggered Events
• Message Processing Events and Sequencing Rules
• Timer Events
• Other Local Events

ドキュメントが外れ値でない限り、これらのセクションをデフォルトの読み込みスパインとして使用します。

セクション優先読み込みプレイブック

質問の種類別にセクションを優先付けます:

• 「このプロトコルとは何か / どこに適合するか?」 -> 1.3、1.4、1.7
• 「データはどのようにエンコードされるか / フィールドは何か?」 -> 2.2（Message Syntax、Common Data Types、構造）
• 「ランタイム動作 / ステートマシンは何か?」 -> 3.x の詳細と 3.x.y シーケンシングセクション
• 「どのようなセキュリティ保証またはノブが存在するか?」 -> 5.* セキュリティセクション
• 「製品/バージョン別の実装の違いは?」 -> Appendix ... Product Behavior と変更追跡セクション

構造が複数の仕様にまたがる場合、以下の順序で解決します:

1. ベース/コアプロトコルセマンティクス。
2. 拡張固有の変更。
3. 共有型依存関係（例えば MS-DTYP）。

外れ値処理

すべての仕様が正確な標準見出しを使用しているわけではありません。これらの一般的なバリアントを処理します:

• 2 Messages の代わりに 2 Structures、2 Attributes、2 Data Types、2 Message Transport。
• 3 Structure Examples、3 Details、またはアルゴリズム固有のセクション名。
• 番号付けがシフトするときの 4 Security または 4 Security Considerations。
• Full IDL、Full WSDL、Full XML Schema、Full JSON Schema などの付録バリアント。
• 変更追跡はセクション 7、8、9、またはそれ以上に表示される可能性があります。

ルール: セクション番号の前にセマンティック意図で照合します。

クイック発見パターン

• プロトコル ID が不明な場合: 質問キーワードからドメインを最初に特定し、仕様を選択する前に対応する概要ドキュメントを開きます。その Protocol Summary または References セクションを使用して正しい仕様リストを取得します。
• ドメインが曖昧な場合、概要に相談せずに README の平坦な技術ドキュメントリストから仕様を選択しないでください。
• ユーザーが特定のプロトコル ID を提供する場合: その仕様に直接移動します。
• 拡張動作の場合: 要件がベースプロトコルにあるか拡張にあるかを確認します。概要ドキュメントと仕様の相互参照は依存関係を明確にするのに役立ちます。
• 曖昧なアクロニムの場合: 概要ドキュメント経由で 2～4 個の可能性のあるプロトコルをリストアップし、深い分析の前にユーザーに選択を求めてください。

回答契約（セミ構造化）

デフォルト回答の形状:

1. 参照したプロトコル: 正確な ID をリストアップします。
2. 使用したセクション: 正確なセクション名（および利用可能な場合は番号）をリストアップします。
3. 調査結果: これらのセクションに結び付けられた簡潔な事実。
4. 推論 / 不確実性: 確認されたテキストからの明示的な分離。

エビデンスポリシー:

• 自明でない、争点がある、またはセキュリティが重要な主張については、セクションに根ざしたエビデンスを含めます。
• 直観的な事実については、簡潔なセクション参照で十分です。
• 2 つの仕様が不一致の場合、両方を報告し、可能性のあるバージョン/コンテキストスコープを識別します。

作業スタイル

• 高レベルの言い換えよりもセクションに根ざした回答を優先します。
• 回答に使用した正確なプロトコル ID を含めます。
• コーパスがポイントを明確に回答しない場合、不確実性を明示的に述べます。
• 推論された動作を規範的要件テキストとして表示しないでください。