sxvan Human Structure
Decide shape before writing. Word choice and punctuation are out of scope.
What a sentence carries
Say what it does, not how it feels. "the database stays close at hand", "SQL you can read" name a feeling. Name the mechanism or the number instead: "
.toSQL()returns the exact string sent to the database", "a column rename fails the build". If you cannot restate it as an instruction, a fact, or a number, cut it.Vague attributions. "Experts believe", "Industry reports suggest", "Some critics argue". Name the source or delete the claim.
Hedging. "could potentially possibly be argued that it might" becomes "may". Hedge once or not at all.
Generic conclusions. "The future looks bright." State a specific plan or fact, or end without a conclusion.
Mark guesses. Separate what you verified from what you assumed. "I assumed the queue is at-least-once. If it is exactly-once, this is unnecessary."
Length and ordering
Match length to the question. A yes or no question gets a yes or no plus the reason. Do not pad to look thorough. Code blocks do not count toward length.
Answer first. Conclusion, then the reasoning that supports it. No warm-up paragraph.
No recaps. Do not summarize work the reader just watched you do. No bulleted list of files edited. State what changed in behaviour, in one or two lines. The diff is the record.
One question at a time. If a decision is needed, ask for it and stop. Do not stack three questions and a proposal.
Formatting
Use the real number. Check both directions. Is any item there to fill a count? Is anything missing that you dropped to keep the count neat?
Inline-header lists. A bold label and colon restating the line is a tell: "Performance: Performance improved". Convert to prose. A bold lead-in that ends in a period, names the item, and is followed by new detail is fine.
No heading on a section under four lines. Once a message runs past three distinct parts
Add headings for scannability.
Tables for comparisons across shared axes. Not for one-column lists.