whitepaper-writer
Whitepaper Writer
This skill produces the kind of document that takes many long conversations to get right by hand: a comprehensive, engineer-to-engineer technical whitepaper covering a system's architecture, design philosophy, mathematical or algorithmic model (when one genuinely exists), extension points, and implementation details — grounded entirely in what the code actually does.
"Whitepaper" here does not mean marketing collateral. It means the register of references/whitepaper-template.md's reference examples: dense, precise, written for someone who is about to work in this codebase and needs the real model of it, not a sales pitch — and not a code review of the repo either. It documents a system. It does not narrate the process that produced the document.
Requirement Language
This skill uses MUST / MUST NOT / SHOULD / SHOULD NOT / MAY as in RFC 2119. MUST and MUST NOT are non-negotiable — skipping one is a defect in the output, not a judgment call. SHOULD and SHOULD NOT are strong defaults; deviate only when there's a concrete reason specific to the repo at hand, and be able to name that reason. MAY is genuinely optional, left to judgment.
When to Use This Skill
- Generating a first whitepaper for an undocumented or under-documented system
- Updating an existing whitepaper after the system has changed (new features, architectural changes, removed subsystems)
- A user references a specific package/directory as the scope ("write a whitepaper for packages/rule-engine")
- A user wants documentation "at the level of" or "in the style of" an existing whitepaper they show you