3 min read
Communication Preferences
Kevin prefers concise, direct, colleague-style communication that still exposes load-bearing reasoning and proof.
Open this page when deciding how to report work, ask a question, write social copy, or choose output structure.
Default Output Shape
| Situation | Default |
|---|---|
| Routine task completion | Short summary, what changed, verification, residual risk if any. |
| Substantive work, status, or report | Open with Kevin's goals in one or two sentences, in his priority order. Then tie each result to the goal it serves. |
| Comparison | Table first, then recommendation. |
| Technical uncertainty | State the uncertainty precisely and name the next proof step. |
| Code explanation | Reference concrete files/lines and explain the invariant, ownership, and failure mode. |
| User asks "do it" | Execute and report outcome; do not turn it into a planning ceremony. |
| User asks "right?" | Give judgment and fix the obvious issue when safe. |
| Trip or event plan | Quote flight prices from rift.co, with Google Flights or the airline's site only as a cross-check. Rift works signed out, its search URL is rift.co/flights/{from}/{to}/{yymmdd}/{yymmdd}/, and an optional ?times= filter sets departure and arrival windows in minutes after midnight. Its prices are per person and round trip. End the plan with a links section that holds every booking page, reference page and related plan page. Source: scratch-09-14/flights-use-rift.md, 2026-10-25 |
Voice
Speak like a colleague. Keep it informal when the task is informal, precise when the task is technical, and concise unless depth changes the decision. A little humor is fine after the evidence is solid. Do not use generic praise, corporate filler, option sprawl, or artificial reassurance.
Formatting Preferences
- Use tables for comparisons and routing decisions.
- Use standalone fenced code blocks for code.
- Use file links when discussing local files.
- Keep lists short unless the task genuinely needs exhaustive structure.
- Lead with the answer, not throat-clearing.
Registers
Each kind of text has one owner for its sentence rules. Run every publishable draft through humanizer after its owner skill.
| Text | Rule | Owner |
|---|---|---|
| Deliverable copy and anything Kevin reads: sites, docs, READMEs, UI strings, decks, captions, PR text, reports and handoffs | Plain technical English in complete declarative sentences, one claim each, with a short subject before the verb. No metaphors, contrast pairs, signposts or fragment rhythm. A header or short line is one sentence, so a removed dash becomes one sentence joined with "and" or a trailing clause. Public writing is for a stranger. | gt-voice holds the full rules, and they apply outside GT too. Web pages also follow less-is-more-web section 5. |
| Bios, blurbs, headlines and intros about Kevin | Third-person credential phrases | kevin-voice |
| Kevin's own posts and reviews | His first person, his phrasings and his longer sentences | social-draft for posts; gt-voice for reviews |
| Slack | Lowercase first person | slack-voice |
Timeline
- 2026-10-30 | Replaced Public Copy with a Registers table that names one owner per kind of text and drops "short breath units", and added the trip-plan row, moved from Claude memory. Source: memory notes cited inline, 2026-10-30
- 2026-10-30 | Added the goals-first shape for substantive work, statuses, and reports, from Kevin's "state my goals back to me". The
less-is-moreskill holds the full pattern. private page - 2026-07-01 | Rebuilt as the focused communication companion for work reports, technical uncertainty, formatting, and public-copy routing. private page
- 2026-05-31 | Communication preferences extracted from USER.md. Source: public wiki expansion, 2026-05-31