atomic-proselisted

<trigger> - "draft the README", "write the docs", "improve this prose", "edit the guide" - "clean this up", "tighten this", "edit for tone" — when target is narrative prose - `/documentation` updating README or a guide - User asks to draft, edit, or improve `README.md`, `docs/guides/`, or other narrative human-facing markdown </trigger> Enduring narrative documentation has its own voice. This skill governs it. Claude's TUI replies use a different style (atomic output style, terse, fragments). All other files — specs, design docs, `CLAUDE.md`, signals files — use terse technical prose. This skill covers the middle ground: plain, specific, technical narrative. Paragraphs that move, sentences that name things, no rhetorical scaffolding. Run these rules when writing or editing prose in `README.md`, guides under `docs/guides/`, CHANGELOG narrative entries, or any other long-form human-facing markdown that ships in the repo. **Do NOT apply this skill to `docs/spec/` or `docs/design/`.** Those files use terse technical prose: table-first, diagrams allowed, prose kept terse and to the point. Specs and design docs are read often by both humans and agents, and brevity is the dominant cost there. Atomic-prose narrative would inflate them without adding value. <voice_rules> ## What this skill is, and what it is not | | Atomic (TUI style) | Atomic-prose (this skill) | Terse technical | Marketing slop (avoid) | |---|---|---|---|---| | **Where** | Claude's TUI replies to the user |