# Windows Protocols

> Local Microsoft Open Specifications corpus navigator for Windows protocols. Parses protocol message formats, looks up field definitions, maps data types, traces protocol state machines, and performs cross-reference analysis across related specifications. Use when the user asks protocol-level questions, needs message/structure details or wire-format field definitions, wants section-by-section summaries, needs to trace protocol state machines or sequencing rules, or requires cross-references across related MS-* specifications.

- Skill: `awakecoding/windows-protocols` (Agent Skill, multi-file: 2908 files)
- Install (CLI): `npx skillmds@latest add awakecoding/windows-protocols`
- Raw SKILL.md: https://api.skillmd.com/api/skills/awakecoding/windows-protocols/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: awakecoding (https://skillmd.com/u/awakecoding)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/awakecoding/windows-protocols

---


# Windows Protocols Corpus Navigator

## Overview

- The corpus is already extracted next to `SKILL.md`.
- Use local files only; do not use network lookup, downloads, or setup commands.

## Corpus Layout

- `README.md` — top-level index. Start with Overview Documents for topical discovery.
- `LEGAL.md` — legal and redistribution notice.
- `<PROTOCOL-ID>/` — protocol directories.
- `<PROTOCOL-ID>/<PROTOCOL-ID>.md` — primary markdown spec content.
- `<PROTOCOL-ID>/media/` — extracted figures and image assets referenced by the markdown.

When the question is broad, start from Overview Documents or protocol families such as `MS-RDP*`, `MS-AD*`, or `MS-MQ*`.

## Reference File

- Use `SKILL.md` for the default workflow, worked example, and answer contract.
- Open `REFERENCE.md` only for these lookup aids: Domain Clusters, Canonical Spec Structure, and Section-First Routing.

## Navigation Workflow

Use this unified workflow for all queries:

1. **Topical questions**: identify the domain, open the matching Overview document from `README.md`, and follow its member-spec links.
   - **Anti-pattern**: do not rely on README keyword search alone; Overview documents provide the authoritative topic-to-protocol mapping.
2. **Known protocol ID**: Validate against `README.md` and directory names (`<PROTOCOL-ID>/`), then open the spec directly.
   - If the protocol is missing, say so and ask for the exact protocol ID or a narrower scope.
3. **Ambiguous acronyms**: List 2–4 likely protocols (via Overview docs) and ask the user to choose before deep analysis.
4. Scan the spec TOC (`<summary>` blocks and numbered entries) before deep reading.
5. Read sections in this order: orientation/versioning → syntax → behavior/sequencing → security/product behavior.
6. Cross-check base vs. extension specs when requirements are split, following cross-reference links as needed.
7. Answer with explicit protocol IDs and exact section headings; separate confirmed facts from inference.

### Link-Following

- Follow Overview-document references and inline links rather than guessing paths.
- Treat Overview → spec → related spec as the intended path.
- When a spec references another spec for types, extensions, or dependencies, follow that link to the authoritative source.
- Do not stop at the first mention; keep following links until the authoritative section answers the question.

## Worked Example

**User question**: "In SMB2, how does the server signal that it supports persistent handles?"

Path: File Access Overview → `MS-SMB2` → `2.2.4 NEGOTIATE Response` → `3.3.5.4 Receiving an SMB2 NEGOTIATE Request`.

Answer: cite `MS-SMB2`, note that the server signals support by setting `SMB2_GLOBAL_CAP_PERSISTENT_HANDLES (0x00000010)` in the NEGOTIATE Response `Capabilities` field, and put version-specific caveats under uncertainty or product behavior notes.

## Answer Contract

Default answer shape:

1. `Protocols consulted`: list exact IDs.
2. `Sections used`: list exact section titles (and numbers when available).
3. `Findings`: concise facts tied to those sections.
4. `Inference / uncertainty`: explicit separation from confirmed text.

Guidance:

- Prefer section-grounded answers and include exact protocol IDs.
- For non-obvious, contested, or security-sensitive claims, include section-grounded evidence.
- For straightforward facts, concise section references are enough.
- If two specs disagree, report both and identify likely version or context scope.
- State uncertainty explicitly, and never present inferred behavior as normative requirement text.