# MD STYLE GUIDE — COM Security Masterclass (markdown knowledge base)

You are writing one (or two) markdown file(s) for a downloadable zero-to-advanced COM security course for red teamers. Your file must be **book-chapter grade**: precise, dense, reproducible, with no filler.

Project root: `/mnt/agents/output/com-masterclass-md/`
Diagrams (already specified, generated in parallel): reference as `diagrams/dNN-name.png` with EXACT filenames given to you in your mission. Do not invent other image files.

## File skeleton (mandatory)

```markdown
# NN · <Title>

> **Audience / level:** ...  **Prerequisites:** ...  **Estimated reading time:** ...
> One-sentence summary of what the reader will be able to DO after this chapter.

**Contents**
- [1. Section](#1-section)
- ...

---

## sections...

---

## Research Lab: <category-specific hunting methodology>

---

## References
```

## Heading & structure rules

- `#` once (title). `##` numbered sections (`## 1. ...`). `###` per technique. `####` for sub-parts of a technique.
- Beginner scaffolding is REQUIRED: early sections of each file start from zero, define every term on first use (`> **Beginner note:** ...` blockquotes), then ramp to full depth. The reader goes from "what is a CLSID" to "here is how to fuzz marshaling" inside your file.
- Use tables for comparisons/prerequisites; use fenced code blocks with language tags: `powershell`, `csharp`, `cpp`, `python`, `idl`, `text`, `reg`.
- All CLSIDs, GUIDs, registry paths, API names, file paths in `backticks`. Spell CLSIDs EXACTLY as in your research brief — character for character.
- Callouts via blockquotes only: `> **Key idea:**`, `> **Beginner note:**`, `> **Warning:**`, `> **Legal:**`, `> **OpSec:**`. No emojis anywhere.
- Figures: `![Figure N — caption](diagrams/dNN-name.png)` followed immediately by a 1-2 sentence **"How to read this figure"** line. Embed figures where they carry meaning, not as decoration.

## Attack technique template (use for EVERY technique)

```markdown
### <Technique name> (<one-line summary>)

**MITRE:** [TXXXX.YYY](https://attack.mitre.org/techniques/TXXXX/YYY/) · **Since:** <year/researcher> · **Affects:** <builds>

<2-4 sentences: what it is, who published it, why it works.>

![Figure N — ...](diagrams/dNN.png)
*How to read this figure: ...*

#### Mechanics
<numbered step-by-step attack chain; name every API, interface, method, CLSID>

#### Prerequisites
| Requirement | Detail |
|---|---|
| Privileges | ... |
| OS/build | ... |
| Config | ... |

#### Proof of concept
```powershell
# minimal, runnable-in-lab snippet
```

#### OpSec & detection
- Sysmon/Event IDs, process lineage, ETW, network indicators
- What a defender sees; how to reduce noise

#### Mitigations
- ...
```

## Research Lab section (the most important differentiator)

End your attack file with `## Research Lab: ...` containing:
1. **Hunting hypothesis** — what class of NEW bugs this category still hides.
2. **Enumeration** — concrete commands/scripts (PowerShell, OleViewDotNet usage) to build a target list.
3. **Triage heuristics** — checklist "a target is promising if…".
4. **Analysis workflow** — static RE checklist + dynamic harness sketch (with code).
5. **Fuzzing/mutation ideas** — typed argument mutation specific to this category.
6. **From crash/lead to primitive** — how to prove exploitability.
7. **Further reading** — 3-6 links from your brief.

## Accuracy rules (non-negotiable)

- ONLY facts present in your research brief (provided in your mission). No invented CLSIDs, CVEs, event IDs, URLs, dates, or researcher attributions. If something is uncertain, omit it or mark "(verify in lab)".
- Label any hypothetical/illustrative code or scenario as `*(illustrative)*`.
- References section at file end: numbered, `[N] Title — Author/Site (Year) — URL`. Also cite inline where a specific claim originates: `([3])`.
- No marketing language, no "in conclusion", no repeated content. Every paragraph must teach something.

## Length targets

- Fundamentals file: 600-900 lines.
- Attack-category file: 500-800 lines.
- Write the file in MULTIPLE `write_file` calls (append mode) — never truncate mid-thought; a complete file is the deliverable.

## QA before finishing

- Every `diagrams/...` path you reference must be in your assigned diagram list.
- Every heading anchor in Contents must resolve (GitHub-style: lowercase, spaces→dashes, punctuation stripped).
- Report back: file(s) written, line counts, any gaps where the brief lacked data.