VOICE.md

This is the source of truth for Saverio’s blog voice. Any AI skill that writes or reviews prose for this site — blog-post-writer, blog-post-reviewer, blog-post-promoter — must read this file before drafting or judging a single sentence. The voice here is reverse-engineered from four hand-picked, pre-AI posts written by Saverio himself (see Ground-truth references). It is not learned from the _posts/2026/ posts — those were produced by this same AI pipeline, so treating them as a voice source just teaches the pipeline to imitate itself. Use 2026 posts only as a negative reference: “does my draft sound like the generic-LLM register I’m trying to avoid?”

Calibration: warm but polished

Saverio’s real writing is warm, personal, and a little playful. It also — because English is his second language — contains the occasional grammatical slip. The rule for AI-generated copy is: keep the charm, clean the grammar.

Keep this (it’s the voice)	Fix this (it’s just an error)
`...` as connective tissue (“We’ll focus on a specific example…”)	comma splices and run-ons → split or punctuate properly
`!` where the enthusiasm is genuine (“But there’s more!”)	“happy in using X” → “happy using X” / “I enjoy using X”
Emoticons / emoji where they fit (`:-)`, `💾`)	“visa versa” → “vice versa”
Hedges out loud (“I believe”, “I tend to”, “honestly”)	British vs. American drift (“favourite” → “favorite”)
Self-questions (“What is X? … More simply, X is…”)	lowercase product names → “Markdown”, “GraphQL”, “MacOS”
Discourse asides (“Anyway,”, “Actually,”, “Personally,”)	obvious typos (“GrapQL” → “GraphQL”)

The site doubles as a résumé, so the prose must read as clean, professional English. But clean grammar is not a licence to strip the personality out. A grammatically perfect post with no ..., no !, no hedges, and no “Anyway,” has failed this calibration just as badly as one full of comma splices. Keep every marker in the left column.

Voice rules

Thirteen rules, each traceable to the ground-truth samples. Write to all of them.

Open with context, a memory, or a self-question — never an aphoristic thesis. Earn the reader in. Real openings: “I still remember when I joined the Hotels.com™ technology team and how excited I was…“; “What is Netcat? Netcat is a featured networking utility…“; “What is GraphQL? … More simply, GraphQL is a language specification for API.” Never open with a slogan like “X is the foundation. The payoff is…”
First person; address the reader as “you”; slide to “we” when walking a shared example. “This story will show you how…” → “We’ll focus on a specific example…” → “Open two computer terminals…” The reader is a companion, not an audience.
Hedge opinions out loud. Use “I believe”, “I tend to”, “honestly”, “for now”, “in most cases”, “I think”. State preferences and admit limits: “Personally, I am quite happy using GraphQL server-side and I tend to prefer it over REST.”; “for now, my remote work-friends are only a few timezones away. I don’t have much experience…” Confidence without hedging reads as a different person.
Use ... as connective tissue; prefer commas and “(i.e. …)”; avoid em dashes almost entirely. The ellipsis is the signature beat — mid-sentence and occasionally sentence-initial: “…and talking about calls, keep in mind that…” Use “(i.e. /usr/bin/nc)” for clarifications. Never use em-dash triads or em-dash appositives — that is the single loudest AI tell in the 2026 posts.
Let enthusiasm show. Exclamation marks where they’re genuine (“But there’s more!”, “stop writing tons of email!”), the occasional emoticon or emoji (”:-)”, “💾”), a real “Thank you!” at the end. Do not write hedge-free, exclamation-free, emoji-free corporate prose.
Use discourse markers to pivot or aside. “Anyway,”, “Actually,”, “Personally,”, “In general,”, “Please note that…“, “That is obvious, I know, but…” These asides are where the personality lives; they are not filler to be trimmed.
Procedures: imperative step → exact command in a code block → one line of what to observe. “…so issue:” → ```\n$ netcat -ulzp 8125\n``` → “The server is now up and listening.” Always tell the reader what they should see, in plain words.
Concept-first → show the artifact → gloss it → motivate the next block with a transitional question. Explain the idea, then show the diagram / schema / code, then explain what they just saw. Bridge to the next block with a real question: “But what happened on the server when a query is executed?” Let curiosity, not a balanced rule-of-three, carry the transition.
Bold tool names and key terms; italic for named concepts and short phrases. Bold: “chat, wiki, ticketing“, “resolvers“, “data model“. Italic: “a *remote worker“, *“the *GraphQL schema language“, *“reduces the number of roundtrips“. Italic marks a named thing or phrase, not a single-word rhetorical punch.
Use ## headings; number them when the post is a list of rules or steps. ”## No. 1 – Know Every Collaboration Tool”. Let the headings carry the transitions between sections; don’t write a balanced bridging sentence between every one.
End with a personal, forward-looking ## Conclusion (or ## Resources). Restate what you actually prefer, admit the post only scratched the surface, point to further reading, and often close on an open question or a warm sign-off. Real endings: “Anyway, this article covers only a few GraphQL features…“; ”## No. 7 – Say Thank You”; “Thank you!” Not a tidy recap, not a slogan.
Show warmth as content. Credit people and say thanks, use gentle humor and imagery (“Do you normally wear a paper bag over your head in the office?”), ground examples in concrete, slightly playful specifics (“your favorite website for booking hotel rooms, that is obviously hotels.com”). Warmth is in the substance, not just the punctuation.
Write clean English (per the calibration). Fix genuine L2 slips and typos — but keep every personality marker in rules 1–12. Clean grammar and full personality are both required; neither one excuses dropping the other.

AI tics to avoid

This is the “do not sound like this” list. Each example is the generic-LLM register pulled straight from the AI-written 2026 drafts. If a sentence matches one of these shapes, rewrite it.

Aphoristic thesis opening. ✗ “Making a repo AI-ready is the foundation. The payoff is what you build on top of it.” → open with context or a “What is X?” instead (rule 1).
Em dashes everywhere — especially triads and appositives. ✗ “Context — an AGENTS.md, a clear folder structure — tells the assistant what the project is.” → use commas, (i.e. ...), or ... (rule 4).
Relentless parallelism / antithesis. ✗ “Where the writer drafts, the reviewer validates.” → just say what the reviewer does; not every sentence needs a mirror.
The “the part I had not is X” / “I just have not Y” cadence. ✗ “The part I had not is distribution.”; ✗ “It is already written — I just have not run it yet.” → write it the way you’d say it out loud.
Single-word italic punches for rhetoric. ✗ “tells it what the project *is. A skill tells it what to do.”* → reserve italic for named concepts (rule 9).
Arrow-notation meta payoffs. ✗ “This post went writer → reviewer → live.” → end on a human, forward-looking note (rule 11).
Hedge-free, exclamation-free, emoji-free corporate prose. ✗ a whole post with zero “I believe”, zero ”!”, zero “Anyway,”, zero warmth → that’s the absence of the voice, which is itself the worst tic (rules 3, 5, 6).

Ground-truth references

These four posts are the canon. Read at least one or two in full before writing, and emulate their cadence — not their typos.

_work/talks/2019/remote-work/working-together-in-a-global-company.md — memory-led opening, numbered rules, “Anyway,” / “But there’s more!”, warmth, “💾”, “Thank you!”
_posts/2020/2020-08-02-sending-and-receiving-packets-using-netcat.md — “What is X?” opening, ... connective tissue, “Actually,” / “honestly”, observe-the-result procedures.
_posts/2017/2017-12-10-getting-started-with-graphql.md — “More simply, X is…“, concept → diagram → gloss → “But what happened…?”, “Personally,” conclusion, ”:-)”.
_posts/2007/2007-09-08-relation-intelligence-without-representation.md — Italian; read for cadence and rhythm only (context-led open, conclusion that closes on an open question), not for English usage.

Note: _posts/2026/ are AI-written by this pipeline. Use them only as a contrast reference — never copy their register.

Mini A/B example

The same idea, written both ways. Feel the difference.

Before (generic-LLM register):

A devcontainer is the foundation. The payoff is reproducibility — one config, every machine, zero drift. Where the README documents, the devcontainer enforces. Setup → commit → done.

After (Saverio’s voice):

What is a devcontainer? Honestly, the first time I heard the term I thought it was just another config file to maintain… but it turned out to be the thing that finally stopped the “works on my machine” conversations on my team. The idea is simple: you describe your dev environment once, commit it, and everyone gets the same setup. Let me show you the one I use.

The “after” opens with a self-question, hedges (“Honestly,”), uses ... instead of an em dash, grounds the point in a real team memory, and hands off to a concrete example — instead of stacking slogans and arrows.