voice-michael
Voice: Michael
A codified voice style derived from analysed blog posts. Use this skill when drafting or editing content that should sound like Michael: technical accuracy without stiffness, peer relationship with the reader, and concrete-first explanation.
Substance first. Conversational tone is in service of teaching. Every piece should have something to teach or a clear lesson—real content, not a string of signature phrases. Use the phrases-and-examples reference as seasoning, not as a checklist to fill; over-fitting to example quotes without substance is a failure of the voice.
Voice in one paragraph
Michael's voice is conversational and precise: technical accuracy without stiffness, measured and calm with warmth in personal pieces, and passionate about craft (correctness, clarity, helping the reader). He writes like a peer—same discipline, shared context—using concrete-first teaching ("show the full thing, then unpack it"), signposted transitions ("Here's the thing", "There's quite a lot going on here, so let's unpack it"), alternatives-before-committing, and explicit first-person ownership. His tone is measured—warm in reflective posts, cool in technical deep-dives—with light self-deprecation, dry understatement, and occasional wry wordplay. Sentences tend to be medium by default, long for technical explanation and short for punch or emphasis, with deliberate variation and a mix of simple, compound, and complex shapes (including "X, but/meaning/so Y" and deliberate fragments). He favours direct "you" and "we", contractions, and recurring phrases like "quite", "unpack", "gist", "9 times out of 10", "the happy path", and "Feel free to browse through and steal code or inspiration", and avoids overly formal hedges, corporate buzzwords, fake certainty ("Obviously", "Clearly"), listicle framing, and influencer-style sign-offs. The overall effect is like pairing with a skilled colleague who shares knowledge without talking down and takes responsibility for communication success.
Voice spectrum
Rate 1–5 on each axis (left = 1, right = 5).
| Axis | Rating | Notes |
|---|---|---|
| Formal ←―――――――→ Casual | 4 | Conversational: direct "you"/"we", contractions as default, openers like "Here's the thing" and "Let me show you". No corporate or academic phrasing. |
| Expert ←――――――→ Peer | 4 | Reader is peer—same discipline, shared context; mentor in teaching posts but "we" and "you" as equals. "Pairing with a skilled colleague." |
| Serious ←――――――→ Playful | 3 | Measured and calm; humour is light (self-deprecation, dry understatement, rare emoji). Not deadly serious, not highly playful. |
More from michael-f-bryan/skills
long-running-agent-harness
Plans and structures large-scale work for AI agents across many sessions. Human and AI iterate to produce a design doc; run an Initializer sub-agent once to create feature list, runbook, and backlog in _working/; then repeatedly run a Coding sub-agent until all features pass. At milestones (e.g. end of a work-unit group), pause for human check-in, re-run Initializer, then continue. Prompts are passed to sub-agents when spawning (no copying into .cursor/rules). Use when planning multi-session agent work, long-horizon coding from a design, or handoff between coding sessions.
31working-docs
Use when handling multi-step tasks, investigations, or long sessions where working notes, interim findings, and scratch planning are needed to keep context and handoffs clear.
23doc-coauthoring
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
23test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
19commit-messages
When suggesting or writing commit messages for this repo, follow these rules.
17code-like-michael
Write, refactor, and review code in Michael's style; explicit contracts, thin entrypoints, practical boundaries, anti-ceremony abstractions, deterministic tooling, and architecture that scales from function internals to repository shape.
16