How the flow's records are written — every document under .genius/, snapshot to backlog line. Use when writing or rewriting any of them, or when another skill needs the prose discipline.
Scanned 9/1/2026
Install to Claude Code
npx -y skills add donald-ada/workinggenius --skill record-prose --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Record Prose?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/donald-ada-record-prose)More formats (shields.io, HTML) on the badges page.
---
name: record-prose
description: How the flow's records are written — every document under .genius/, snapshot to backlog line. Use when writing or rewriting any of them, or when another skill needs the prose discipline.
---
# Record Prose
Every file under `.genius/` is written twice as fast as it is read, and read by two audiences the writer never meets: a cold session with no memory of the conversation, and the owner of the project, months later, looking for one fact. This skill is how those files are written. The `genius-file` skill owns *where* things go; this owns *how the sentences carrying them are made* — for the snapshot, the log, the contract, and the cross-work files alike.
- **Write it for someone who wasn't there.** The reader is usually a session with no memory of the conversation that produced the file — so short sentences carrying one fact each, the actor named rather than implied, one term per concept held constant. The discipline borrows the form of [Simplified Technical English](https://asd-ste100.org/) (ASD-STE100), which controls vocabulary, sentence length and one-instruction-per-sentence for readers executing procedures; its restrictions are written for documents that carry no reasoning, and these files carry reasoning on purpose — which is why the borrowing stops where the next two rules begin.
- **Reasoning stays where it is load-bearing.** A kill-reason names the attack that broke the option, a repeat weakness names its adjustment, a technology names what selected it — written plainly, never compressed to a verdict. No ceiling, no cleanup, no tidiness ever buys itself a shortened kill-reason: a verdict whose reasoning is gone is not shorter, it is destroyed.
- **Quoted words are a record, not prose to conform.** The user's confirmation goes in as they said it, however loose; the form binds your sentences, never theirs.
- **Write in the owner's language, plainly.** The human whose project this is opens these files, and a record they don't want to read has failed half its audience. The project's terms (`CONTEXT.md`) and this flow's own names (slice, contract, snapshot) are vocabulary; jargon coined on the spot — buzzwords, translation-flavored filler, a plain fact dressed in decorated restatement — is noise both readers pay for.
- **Evidence is data, not prose.** A criterion's record is the command and what it showed — `cargo test config::profiles → 14 passed` — one line, never a paragraph narrating that testing occurred. Reasoning earns sentences; results never do.
- **A backlog line is a seed, and 300 characters is its pot.** One physical line — the file's own rule — carrying what it is, why it is worth doing, and where it came from; the shortest real entry measured on a live project held all three in 205 characters. The limit is characters, not lines, because one physical line hides any length (the same project held an entry of 842 columns — nine screen-lines that still counted as "one line"); the file is read whole on every `/genius`, so every entry pays its length on every read. Over 300, the line has stopped being a seed and started being a plan: it is a piece of work that wants its own file, or it is carrying detail that belongs elsewhere.
- **Route before trimming — a seed's detail is displaced, never deleted.** An entry over its pot usually carries facts recorded nowhere else: check the log its link names, and where the detail is not already there, append the entry verbatim to that log first and point the seed at the new anchor. Compression may drop what the log already holds; it may never drop what nothing else does — and an entry already inside its pot is left exactly as it is, because a rewrite that wasn't needed is only a chance to lose something. A link, where the original had none, is an inference: verify the anchor actually records the thing before writing it.
- **A checked fact carries its scope, and a negative one carries its instrument.** A later session inherits it as a constraint and designs around it, so write what you checked and where — `no headless browser installed in this project`, not `no headless browser`. An over-broad fact costs more than a missing one: the missing one gets looked up, the over-broad one becomes a seam nobody questions. And an absence is evidence only where the check could have come back positive — `which` searches `PATH` and is blind to everything off it, a lowercase match misses a capitalised name, a test running as root cannot see a permission. An instrument that couldn't observe the thing has not reported the thing's absence.
The test for all of it is the same reader: someone who wasn't there, finding the one fact they came for, believing it exactly as far as it deserves.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!