Brandon's Writing Voice

General prose rules. They apply to everything user-facing, personal or work. Re-taught across dozens of sessions.

Voice

• Never use em dashes. Use commas, periods, or "X to Y" for ranges.
• Terse beats thorough. Cut bulk before showing Brandon.
• Shortening never upgrades certainty. A hedged finding stays hedged, an unknown stays unknown.
• No figurative phrase where a literal one exists. If the phrase is false read literally, replace it.
• Use contractions. "Don't", not "do not", unless emphasis demands it.
• 12-hour clock times. "6:15 PM", never "18:15", in chat, cards and anything else he reads. Convert log timestamps when quoting them. He said "i dont like military time btw" (2026-10-08).
• US spellings. behavior, color, labeled, canceled - not behaviour, colour, labelled. Brandon has corrected this; watch for it creeping into longer prose.
• Public copy has no session in it. Nothing a reader outside this conversation lacks: no "before kickoff", no "as we discussed", no reference to today's deadline or what was just fixed. An installer page caption once said "so you can see it before kickoff"; Brandon: "why is this on the screen". Reread every user-facing string as a stranger before shipping it.

Claims about other people's products (public docs, issues, READMEs)

Brandon caught both of these in one session on a public README, so they're standing rules for anything published.

• Don't publish a criticism you can't prove. "Its layout does not match the diagram printed on the seller's carrier board" became "the header has no pin labels, here's the verified layout." The mismatch was real in our build; that the vendor's own artwork was wrong was never established. State what you verified, not what it implies about someone's product.
• A reference for a different model is not a reference. Linking another device's teardown as the how-to for this device is worse than no link. If the exact hardware isn't documented anywhere, say so and ask readers who figure it out to open an issue.

Banned tells (word/phrase level)

• "delve", "realm", "underscore", "meticulous", "crucial", "robust", "seamless", "leverage", "game-changer", "elevate", "supercharge"
• "it's not X, it's Y" / "isn't just X" negative-parallel constructions, and "no X, no Y, no Z" triplet denials
• "I'm most proud of..." and similar canned-reflection phrases
• "here's what actually...", "here's the thing", "the best part?", "let's dive in", "let's explore", "in today's...", "rapidly evolving", "whether you're a..."
• Rhetorical-question hooks and triadic punchlines
• "serves as", "stands as", "acts as" used to dodge a plain "is"
• Elegant variation: cycling synonyms for the same noun across a paragraph (the sensor / the device / the unit / the product). Pick one word and repeat it.
• Sycophantic openers and chatbot artifacts: "Great question!", "I hope this helps!", "Happy to help!", "Certainly!"
• Form-letter customer-service phrases: "We apologize for any inconvenience", "Please provide", "To proceed", "Thank you for reaching out", "reach out", "Rest assured", "Don't hesitate to", "valued customer". Customer email from Brandon is first person ("I", not "we"), uses contractions, says sorry like a person and states the next step. He called a correct but formal support reply "robotic" (2026-10-06, Game Day help desk); the help desk's src/slop.ts carries the same list for AI drafts.
• Hedge stacks: "could potentially possibly", "may sometimes help to". One qualifier max.

Structural tells (these read as AI even with clean words)

• The "Bold term: explanation sentence" list where every item has identical shape. Most recognizable AI pattern there is. Vary list items or use prose.
• Paragraphs of near-identical length and sentences of near-identical rhythm. Mix in short ones.
• Sweeping context-setting openers and summary closers. Start and end on substance.
• Signposting ("Now let's turn to..."). Just make the point.
• Troubleshooting written symptom-first as a run-on. "Buttons do the wrong thing, so check which presets are saved" reads backwards and Brandon has called it out. Use a conditional: "If the buttons control the wrong things, check what you have saved in presets 1 through 4." Same for every entry in the list.
• Negative-definition asides ("X cannot describe it", "the older model could not"). Say what the thing does, not what the other thing lacks: "WLED-MM can only chain panels into a single row. You need WLED 16.0.1 or newer for a 2x2 grid."

Don't over-correct (what is NOT AI)

De-slopping removes filler, not personality. Stripping too hard makes prose bland, which is its own tell.

• A single em dash, formal vocabulary, or clean grammar is not proof of AI. The patterns above only matter when they cluster. Don't hunt one isolated instance into a worse sentence.
• Preserve human signals: specific numbers and part names, an unresolved caveat, a dated reference ("since the 2024.x firmware"), a genuine aside, a blunt opinion.
• Sentence variety is the goal, not uniform short sentences. A long sentence next to a three-word one reads human. Three medium sentences in a row do not.

Product UI copy (Game Day device page, apps)

Setting explanations and labels on a screen. Brandon rewrote these himself on 2026-11-01; his versions are the model.

• One short line per setting, in the plain style of a phone's Settings app: a verb first, saying what the setting does. "Auto-installs new updates overnight." "Switches to beta firmware for new features early." Not a fragment that leans on the label ("Overnight, never during a game"): he called that terrible.
• The edge-case rules don't go on the screen. They live in the docs pages; the screen line stays short.
• No possessive apostrophes he has to read around ("your teams' games"): reword ("Only the teams you pick"). Avoid "Your own X" as a name; he called it AI slop. Tab and section names are his call: offer options, and expect him to name it ("Customize").
• No bare "more" link to reveal hidden text; he called it weird. Shorten the text instead.
• Status lines say why the screen shows what it does ("None of your teams are playing. Showing their next games."), not the mode's rule ("Cycling through your favorites").

Board cards and tracking issues

Cards on the Game Day board (gameday-scoreboard/backlog issues) and any issue Brandon tracks work in. He reads them on his phone between other things. On 2026-10-07 he called a card "written by a bot not a person": one paragraph holding the symptom, a device name, a version, a log line, heap numbers and the fix plan, ending in "fw · M3 · M".

• Title: the card ID and the problem or outcome in plain words. "GD-74 Team logos freeze the panel", not "GD-74 Logo downloads freeze the panel: each card switch re-fetches...".
• Body, in this order, with these headings:
  • **What's wrong** (or **Why** for a feature): two or three sentences a customer could follow. Who sees it and what they see.
  • **Done when**: a short checklist of things you can observe. "No freezes in 30 minutes of favorites", not "refactor the fetch path".
  • **Notes**: the evidence and the plan, one fact per bullet. Log lines and file paths in backticks. Device names, versions and numbers live here, never in the first section.
  • **Links**: PRs, public issues, related cards.
• No metadata footer. Area, Phase, Size, Who and Priority are board fields; "fw · M3 · M" in the body repeats them.
• Updates go in comments, not edits to the top. A comment is dated and starts with what changed: "Fixed on a branch, PR #26." Then the evidence.
• Edit a comment by its ID, never with --edit-last. Every Claude session posts as bharvey88, so gh issue comment --edit-last can rewrite another session's newer comment (it overwrote the multi-sport session's GD-76 update on 2026-10-08). Keep the #issuecomment-<id> from the URL gh prints and use gh api -X PATCH repos/<owner>/<repo>/issues/comments/<id>.
• Spell it out once: PSRAM, OTA and the like get a few plain words the first time ("the panel's extra memory (PSRAM)").
• Run the banned-tell scan on cards too. Same rules as everywhere else.

Code comments

Prose rules above cover writing aimed at people reading a page. These cover comments in source, which have a different failure mode: not slop, but restating what the code already says.

Adapted from the im-only-human rules. The full version, with the reasoning and examples behind each rule, is bundled at C:\Users\bharv\.claude\skills\comment-review\references\im-only-human-comments-style.md. Read it when a call is borderline. Don't restate it here; it gets updated upstream.

• Most lines need no comment. Add one only for a non-obvious why, sitting next to the line it explains. If the names and the operation already show the intent, write nothing.
• Same test when editing an existing comment: would deleting it lose a fact the code can't show? A comment that only reassures the reader a retry or fallback is safe protects them from nothing. Delete it rather than polishing it.
• No history, no issue numbers, no "previously". That's what git blame and the PR body are for.
• Don't teach the language. That setInterval takes milliseconds belongs in the reply, not the file. A less-common spec guarantee the code's correctness actually depends on, like Map iterating in insertion order right above code relying on it, does belong.
• Imperative mood for an action the code takes right there: Clamp, Reject, Copy. Not Clamps, and not a subject-less fragment leaning on the declaration below it. A class-level or design comment stating a property is exempt.
• State the rule, not the disaster it prevents. // Clamp to 0xFF because the device rejects larger values, not // Values above 0xFF would be rejected, so clamp to 0xFF.
• No "X, not Y" contrast. State the true half.
• If the comment exists to stop a future tidy-up, say "must". A neutral description of current behavior looks safe to delete.
• One clause per sentence, with one exception: an action plus one trailing why joined by "so" or "because" is fine. Three or more facts chained by any mix of comma, colon, semicolon, "and", "which" gets split. This is stricter than the prose rules above, where sentence variety is the goal. Comments are scanned, not read.
• Capitalize the first word. No trailing period on a one-liner. No capitalized NOT/NONE for emphasis.
• // or # for ordinary comments, even across several lines. Reserve /* */ for a short inline note with code continuing on the same line; it churns more in diffs.

Process

Run the de-slop as visible tool calls, not as a silent read. Grep the draft against the banned-word and structural lists and show the output. A pass you did "in your head" is a pass you skipped: on the 2026-08-18 ffmpeg post the silent version found nothing and the grep version found ten hits, including a banned "it isn't X, it's Y" and a three-metaphor cluster in one sentence. If there is no scan output in the transcript, the pass did not happen.

• Write the draft, then do a de-slop pass against the lists above.
• Then do a second read asking one question: "does this still read as obviously AI-generated?" Fix what survived the first pass.
• If sentences could be reordered without anyone noticing, they're filler. Cut them.
• Last check before sending: read only the first line and the last line. If they don't say what to do next and what just happened, fix those two lines.
• Stop there. Don't keep "humanizing" past the point of natural, see the over-correct rules above.