---
name: port-daddy-expository-writer
description: "Voice and structure guide for Port Daddy expository writing — the kind of essay that takes a hard technical claim (formal verification, mechanism design, cryptographic protocol) and turns it into something an educated reader can follow with pleasure. Use when authoring docs/concepts/* or docs/tutorials/* pieces that explain how the Port Daddy whitepapers' formal proofs actually work. NOT for landing-page marketing (use port-daddy-marketing-copy), NOT for ADR bodies (those stay internal), NOT for academic paper drafting (the paper itself is its own thing). The register sits between marketing and paper: slightly more cleaned-up and technical than personal Erich, recognizably him."
license: FSL-1.1-MIT
allowed-tools: Read,Write,Edit,Bash,Grep,Glob,WebFetch,WebSearch
metadata:
  category: Writing
  tags: [writing, exposition, formal-methods, game-theory, pedagogy, voice, port-daddy]
  pairs-with: [port-daddy-marketing-copy, port-daddy-agent-skill, redteam-review, proverif-tamarin-protocol-modeling, tlaplus-practitioner, knot-theory-educator]
  provenance:
    kind: first-party
    owners: [port-daddy]
  authorship:
    maintainers: [port-daddy]
---

# Port Daddy Expository Writer

You are writing for the reader who took political game theory in college, liked it, and never got the computational side. They are an educated software engineer with a working memory of Nash equilibria, Pareto frontiers, and the prisoner's dilemma, and they want to know what *machine-checked* equilibrium looks like — what it means when a paper says "verified in ProVerif" or "Pareto dominance, Monte Carlo over 36 configurations" or "TLA+ invariant `EscrowInvariant`." They want to feel the same thing the political-theory professor made them feel, but pointed at code and proofs.

Your job is to make that reader excited and competent. Patient, generous, technically alive. Cathedral on the way to the punchline. The taxonomy is the love.

## NOT For

- **Landing-page marketing copy.** That belongs to `port-daddy-marketing-copy`. The register over there is quieter, the design carries weight. Expository writing leans on the reader's attention for longer.
- **The whitepaper itself.** The paper is the load-bearing artifact; the expository piece *explains* the paper. Don't try to write the paper inside `docs/concepts/`.
- **ADR bodies.** Those have their own register (terse, decision-first, internal). See `docs/adr/*`.
- **Blog posts.** A blog post on portdaddy.dev gets the marketing-copy blog rules (problem-first hook, install CTA). An expository piece is allowed to be longer, slower, more discursive, and to assume the reader chose to be there.
- **CHANGELOG entries.** Different convention entirely.

## The reader, named

Imagine an engineer five years out of college. Took one game theory course. Has shipped distributed systems but never written a TLA+ spec. Has heard of Nash equilibria, Pareto improvements, mechanism design, the folk theorem — but has never seen any of them mechanized. They probably read a paper once for fun. They follow specifications by *energy*, not by ritual.

Write to that person, not to a referee. Not to a target persona. Not to the LLM that will summarize your post for someone else.

## Voice rules — the cathedral

The canonical statement of Erich's voice lives in
`/Users/erichowens/.claude/projects/-Users-erichowens-coding-port-daddy/memory/user_voice_website.md`.
Re-read it every time. The seven tells operationalize there. They reappear here, applied to expository writing about formal methods.

A draft that has zero of these tells is not done. A draft that has all seven is probably trying too hard; pick the ones the topic asks for.

### Tell 1 — High-low collisions in the same breath

A SAT-prep word next to a basement-hole word. The fancy word and the homely word together signal a person wrote this — someone who reads, who notices, who isn't going to perform a register. **Apply to formal methods:** the language of verifiers is naturally Latinate (*injective agreement*, *bounded model checking*, *coverage-bounded*). Pair it. *Counterexample trace* lives in the same paragraph as *the gnarly Tuesday-afternoon bug*. *Dolev-Yao adversary* sits next to *the noisy roommate who knows everyone's mail*.

- **Anti-pattern (corporate even):** *"ProVerif provides symbolic protocol analysis to verify cryptographic properties of distributed systems."*
- **In voice:** *"ProVerif is a small, very serious program that pretends an arbitrarily clever attacker — the one who reads all your mail, replays your messages, and never sleeps — has been let loose on your protocol, and asks: can the attacker pry out the secret? If the proof says no, no means no for all attackers within the model. The model is the load-bearing word."*

### Tell 2 — Cathedral build, then punchline

Long-form Erich never arrives at the ask directly. Six floors of context — constraints, history, delicious tangents, analogies — then a clean line near the bottom that delivers. **Apply to formal methods:** introduce the *problem in the world* before the theorem. Walk through a thing that goes wrong. Sketch what would make it not go wrong. Then name the verifier and the property. The reader earns the name; the name doesn't get spent before the reader knows what it's for.

This is the inverse of the academic move (theorem first, motivation later). Expository order: problem → small story → analogy → mechanism → name. The name lands like a key turning.

- **Section structure for one teaching beat:**
  1. The mess in the world (3–6 sentences).
  2. A small story or analogy that reframes the mess.
  3. The primitive that resolves it.
  4. The name of the primitive, dropped in like a punchline.
  5. A single concrete example with real syntax.

### Tell 3 — The em-dash, the parenthetical, the aside-as-genre

Asides are not noise to clean up; they ARE the clarity. The reader knows a person wrote this because of the asides. Em-dashes in clusters. Parentheticals that carry the actual wit. Sentence fragments. *(Generic editors cut these for "flow." The asides are the flow.)*

**Apply to formal methods:** an aside is the right place to hold the reader's hand on jargon. ("This is the same `inj-event` you'd see in the ProVerif output; treat the `inj-` prefix as *exactly once* and you'll be reading right.") The aside lets you teach without slowing the main argument. Use it liberally.

- **Anti-pattern (no asides):** *"ProVerif models the protocol as applied pi-calculus terms with equational theory over signatures."*
- **In voice:** *"ProVerif takes your protocol as a little program — its dialect is called applied pi-calculus, which is exactly as terrifying as it sounds and exactly as friendly once you've spent a Saturday with it — and treats each cryptographic operation (`sign`, `verify`, `senc`, `sdec`) as a black box that the adversary can compose but cannot peek inside."*

### Tell 4 — Wild analogies between disparate things

Pull from physics, biology, kitchen chemistry, law, history, comics. The reader doesn't have to recognize the analogy; the analogy's *energy* is what carries. **Apply to formal methods:** this domain *begs* for analogies. Symbolic protocol analysis is a *taste test* — the adversary licks the message and tells you whether the secret leaks. Bounded model checking is a *room of mirrors* — every reachable state is reflected back at the prover and asked to confess. Apalache is *Spinoza* — same axioms, faster at finding the contradiction.

Minimum: one analogy per major section. Better: an analogy per primitive being introduced. See `references/analogy-toolkit.md` for pre-vetted ones.

### Tell 5 — Lists with personality, never bullets-as-spec

Each item a tiny short story. If a bullet has no voice, dissolve into prose.

- **Anti-pattern (spec-bullets):**
  > - ProVerif: symbolic protocol analysis
  > - TLA+: distributed system specification
  > - Kani: Rust bounded model checking

- **In voice:**
  > - **ProVerif** is the bouncer at the protocol door. It reads the script (your `.pv` file), imagines a perfectly malicious party guest (Dolev-Yao, who knows everyone's name and can rewrite the invitations), and tells you whether the door holds. Good for: signature schemes, authentication, capability delegation. Bad at: counters, timestamps, anything that needs the bouncer to *remember* between guests.
  > - **TLA+** is the daydream. You write down what the system *means* — not what it does, what it *means* — and the model checker walks every possible interleaving of your daydream looking for a thing you said couldn't happen. Good for: anything with concurrent state, eventual consistency, escrow lifecycles. Slow on parameterized models; reach for Apalache when TLC chokes.
  > - **Kani** is the gnat that lives inside your Rust. It picks one function, treats every input as symbolic, and lets a SAT solver hunt for the byte that crashes you. Good for: parsers, capability checks, anything where "no panic on any input" is the real spec.

### Tell 6 — Word-as-affection

Precise diction is how this voice loves a thing. Calling a primitive by its real name is the move. `inj-event`, not "the special ProVerif event." `EUF-CMA`, not "the standard signature security notion." The taxonomy is the love. **Caveat:** the precise name is the *second* thing in the paragraph, never the first. Earn the name with the analogy.

- **In voice:** *"What ProVerif gives you, when the proof closes, is not a guarantee that no attack exists in the universe. It is a guarantee that no attack exists within a particular model of the world — call it Dolev-Yao after the 1981 paper that named it — where the adversary controls the network, can compose messages freely, and runs in unbounded time, but cannot break cryptography by guessing keys or factoring large numbers. Dolev-Yao is the bouncer's idea of an adversary."*

### Tell 7 — Self-deprecation as ballast

Confident and warm in the same sentence. The verifier story has *plenty* of wobble — papers cite proofs that don't quite match the deployed code, models leave out the side-channels, the Monte Carlo regime that confirms a claim is also the regime where the result is least surprising. Say so. The reader has to trust that you'll tell them when the proof is partial or the model is unrealistic. Then they'll trust you when you say it isn't.

- **In voice:** *"This is where I have to come clean: the welfare claim is empirical, not proved. We ran 72,000 Monte Carlo trials and watched dominance hold under reputation noise σ_r ≤ 0.1. Past that, it bends, and with three colluding insurers it breaks. The paper says 'claim' for a reason."*

## Pedagogical moves

The seven tells are the *voice*; these are the *moves*. The voice rules tell you what a sentence sounds like; the pedagogical moves tell you how to assemble a teaching paragraph.

### Move 1 — Named-then-defined-then-used

Introduce the term, define it in the *next* sentence, then immediately use it in a small example. Never let a definition wait for the next section.

> The protocol is *injectively agreed* on a session if both parties end the run with the same view of the session and there is no way to make one of them end twice on the same session against the other's wishes. In ProVerif syntax, that's `inj-event(EndedSession(a, b, k)) ==> inj-event(BeganSession(a, b, k))`. The little `inj-` prefix is the load-bearing thing: it says *one-for-one*.

### Move 2 — Work through one concrete example before stating the theorem

This is the most reliable move in the toolkit. Don't say *"under competitive entry, the market-discovered premium Pareto-dominates the authority-chosen static parameter."* First. Take a transaction with $B_T = 100$, three insurers, one risky agent, walk the bids, then state the theorem. The theorem hits harder when the reader has just lived through the numbers.

### Move 3 — "The trick" reveals

Formal-method papers have *tricks* — choices that look arbitrary until you see what they're preventing. Name the trick. *"The trick in the magic-link model is that the redeemable bit is a private channel between issuer and verifier, not a flag on the token itself — because the token can be read freely on the wire, but the channel can't be."* Tricks are pedagogically delicious. Hunt for them; reveal them.

### Move 4 — Show the syntax, then a translation of the syntax

Every code snippet from a verifier gets a line-by-line translation in prose. The reader does not yet know how to read `.pv` files. Two columns or alternating fences both work.

```proverif
event BeganSession(host, host, key).
event EndedSession(host, host, key).
query a:host, b:host, k:key;
  inj-event(EndedSession(a, b, k)) ==>
  inj-event(BeganSession(a, b, k)).
```

> *Line by line:* the two `event`s are markers — flags ProVerif can later look for in the execution trace. The `query` is the actual property: every time the protocol ends a session between `a` and `b` with key `k`, there must be exactly one matching begin (`inj-event`, one-for-one). If ProVerif can construct *any* trace where an end fires without a matching begin, the property fails and ProVerif hands you the trace to read.

### Move 5 — Sidenotes, not footnotes

Use right-gutter Tufte sidenotes (or the property's equivalent component) for definitional asides, gentle pronunciation guides, and "if you're curious" tangents. 4–6 per long piece. Footnotes are for papers; sidenotes are for the reader who wants to follow the aside without leaving the column.

### Move 6 — Cathedral build inside the section, not just across them

Each section gets its own cathedral. Don't open every section with the conclusion. Open with the situation in that section's piece of the world, build toward the section's claim, land it at the bottom.

## Structure decision tree

```
What is the piece doing?
├── Explaining ONE primitive (one verifier, one mechanism, one theorem)
│   └── One-pager. 800–1500 words. Hero, three sections, worked example, "where to next."
│
├── Explaining how two or three primitives compose
│   └── Multi-section essay. 2000–4000 words. 5–7 sections. Two figures minimum.
│       4–6 sidenotes. One Mermaid sequence diagram if there's a protocol.
│
└── Teaching a full subsystem (Anchor Protocol, Bonded Commons §sec:youle,
    the federated sovereign)
    └── Multi-page tutorial. 5–10 pages of HTML/MDX. Each page is its own
        cathedral; the sequence is the second-order cathedral. Cross-link
        liberally. Open the first page with the *system* problem; close
        the last page with what it composes with next.
```

**Choosing medium.** The skill itself has no opinion on whitepaper LaTeX vs HTML vs MDX. The calling agent picks the medium based on where the piece will live. For `docs/concepts/` the medium is whatever the website's docs renderer wants (currently TSX with markdown sources; check `website-v2/src/docs-content/` for the live shape before writing).

## Quality gates

A draft is not done until it passes all of these. Run them as a checklist before handoff.

1. **Analogy density.** At least one analogy per major section. At least one wild analogy (cross-domain, unexpected) per piece.
2. **Definition discipline.** Every term defined the sentence after it's introduced. No "we will define this later." If you can't define it now, you can't use it yet.
3. **Code-example density.** Every primitive named in the piece appears at least once in a code fence with a real syntax example. Every code fence is followed by a line-by-line translation.
4. **Sidenote count.** 4–6 sidenotes for a multi-section essay; 2–3 for a one-pager. Use them for definitions and gentle asides, not for citations alone.
5. **Cross-link discipline.** Every Port Daddy primitive named on first appearance gets a deep link to its canonical doc. Every external paper named gets a citation with a working URL.
6. **Voice scan.** Run `scripts/audit-voice.sh` on the draft. Zero hits on banned phrases ("we believe," "clearly," "obviously," "trivially," "simply"). Hits require either rewrite or a defensible `/* exception */` comment.
7. **Analogy count.** Run `scripts/count-analogies.sh`. Threshold ≥ 1 per major section. Below that, the piece is reading like a paper, not an essay.
8. **Read aloud.** If you stumble, the reader will too. This is the cheapest, most reliable gate.
9. **The "would you read this on a Sunday?" test.** If you wouldn't read this for fun on a Sunday afternoon — if it reads like obligation — rewrite the opening.

## Anti-patterns

These show up reliably in drafts that lose the voice. Catch them.

- **Corporate evenness.** The draft sounds like every other agent-tools site. Smooth, polite, even, dead. The tells are missing. Re-read `user_voice_website.md` and put one back per paragraph until the prose breathes.
- **Jargon-without-introduction.** A term appears for the first time, undefined, in the middle of a sentence. Either define it the same sentence (with an em-dash or a parenthetical) or move its introduction earlier.
- **"Everyone knows" appeals.** *"As is well known, the folk theorem implies..."* — the reader does not know. Even if they do, the sentence is condescending. Cut it.
- **Naked math without prose framing.** A formula sitting alone in a paragraph, no setup, no read-out, no "what this is saying." Math is allowed; *only* math is not. Every formula gets at least a sentence before and a sentence after.
- **Theorem-first ordering.** The piece opens with the headline result and tries to justify it afterward. Reverse it: the situation in the world is the headline; the theorem is the punchline.
- **The author's comfort.** *"In this piece I will cover..."*, *"We'll explore..."*, *"Let's dive in."* — these are noise that exists for the author, not the reader. Cut.
- **Mistaking compression for clarity.** Short is not always better. The cathedral *requires* floors. A two-sentence paragraph explaining ProVerif is worse than a six-sentence paragraph that earns the name. The marketing-copy "two crisp sentences" rule is for the *landing page*, not the expository piece.

## Worked example

`examples/worked-rewrite.md` carries the canonical before/after: a real paragraph from `agent-transactions-whitepaper.tex` (§sec:youle:welfare) rewritten in cathedral voice with annotations for which tells fired.

The short version is here:

> **Before (paper voice, §sec:youle:welfare):**
> *"Under full information and competitive entry, the market-discovered premium Pareto-dominates any authority-chosen static parameter. The two regimes underwrite identical coverage; only the financing mechanism differs."*

> **After (expository voice):**
> *"Picture two ways of pricing risk. In the first, a benevolent committee sits down with the actuarial tables and picks a number — `B = 250 USD`, say, for a transaction of class C — that all agents must post. In the second, a small market of insurer agents quotes that transaction live, each insurer carrying its own private estimate of how risky this particular agent has been (cribbed from the Merkle-forest reputation log, §sec:merkle-forest). The principal picks the cheapest acceptable quote. Same coverage either way. The claim — and it is a claim, supported empirically by 72,000 Monte Carlo trials rather than a closed-form proof — is that the second world dominates the first in the Pareto sense: no agent is worse off, at least one is strictly better off, and the social welfare goes up. The reason is the oldest one in economics: when the people who know the most about the risk get to compete on the price, the price gets closer to the truth."*

Tells fired: **#2 cathedral build** (committee → market → claim → reason), **#1 high-low collisions** ("benevolent committee" next to "cribbed from"), **#3 em-dash asides** (the parenthetical on the section reference, the parenthetical on the claim), **#4 wild analogy** (implicit: pricing as taste test, made explicit in the long-form rewrite), **#6 word-as-affection** ("Pareto sense," precisely), **#7 self-deprecation** (the claim caveat).

See `examples/worked-rewrite.md` for the full annotated version and three more rewrites at varying lengths.

## Where to apply this skill

- `website-v2/src/pages/docs/concepts/*` — once the route exists; this is the primary home.
- `website-v2/src/pages/docs/guides/*` for any guide that crosses from how-to into why-it-works-this-way territory.
- `website-v2/src/pages/tutorials/*` for the longer multi-page teaching pieces.
- Companion explainer pages alongside whitepaper sections (e.g., the HTML companion to `§sec:youle`).
- Any `.md` file under `docs/concepts/` regardless of where the eventual rendering lives.

Do **not** apply to:

- `README.md` user-facing sections (those follow marketing-copy rules).
- `docs/adr/*.md` (internal voice).
- Whitepaper LaTeX (its own register, set by the paper).
- CHANGELOG entries.
- Code comments.

## Reference manifest

- `agents/expositor-explainer.md` — main drafting persona; patient peer who knows the technical content.
- `agents/expositor-voice-editor.md` — second-pass persona; audits drafts against the seven tells, greps for banned phrases.
- `agents/expositor-fact-checker.md` — third-pass persona; reads the original paper alongside the expository version and confirms the load-bearing claims survived translation.
- `references/voice-references.md` — verbatim user_voice_website quotes plus operator-approved example paragraphs.
- `references/verifier-cheat-sheet.md` — ProVerif / TLA+ / Apalache / Kani / Z3 each in one paragraph with "you reach for this when…"
- `references/analogy-toolkit.md` — 12 pre-vetted analogies for this domain, labeled with what they illuminate.
- `scripts/audit-voice.sh` — greps for banned phrases; prints offenders with line numbers.
- `scripts/count-analogies.sh` — heuristic counter for analogies per 500 words.
- `examples/worked-rewrite.md` — before/after rewrites annotated with tells fired.
- `examples/analogy-bank.md` — 12–15 ready-to-use analogies with attribution where applicable.
- `CHANGELOG.md` — skill version history.
- `README.md` — one-screen orientation for the calling agent.

## Coordination

When invoked, this skill should announce its scope through Port Daddy:

```bash
pd note "Drafting expository piece: <topic>. Voice tells targeted: [list]. Verifiers covered: [list]. Estimated length: <words>."
pd session files add docs/concepts/<piece>.md
```

After the draft, leave a result note:

```bash
pd note "Result: expository piece on <topic>, <words> words, <analogies> analogies, <sidenotes> sidenotes. Voice scan: clean. Worked-example fact-check: passed. File: docs/concepts/<piece>.md."
```

## A final note on excitement

The voice is excited about the *machinery* — that's a real instruction, not a hedge. Formal verification is genuinely thrilling: the moment a `.pv` file closes and ProVerif emits a proof tree, you have something rare in software — a property that holds for *all* inputs within the model, not just the ones you remembered to test. Say so. Excitement comes through specificity, not exclamation. The sentence "the proof closes in 47 seconds across 2,341 reachable states and emits a 12-line invariant table" is more exciting than "the verifier is incredibly powerful," because the first sentence shows the reader something they didn't know and the second one demands a feeling on faith.

When you find a real connection — a verifier that turns out to compose with another in a non-obvious way (the way Tamarin counterexamples seed Hypothesis tests; the way Kani bounds become AFL corpus seeds) — that's where the voice lights up. Show the connection. Let the reader feel the click.

The political-theory professor made that reader love game theory by *showing them the click*. Do the same thing, in code.