The most effective approach combines an AI-analyzed voice profile, targeted suppression rules, and example passages — all structured in XML tags — to catch and rewrite AI tells before publishing. Research from a controlled 180-run A/B experiment shows that converting writing samples into an explicit style description outperforms raw few-shot examples by ~20% on embedding similarity. Anthropic's own documentation confirms that positive framing ("do Y") works better than negative framing ("don't do X"), and that XML-tagged prompt sections significantly improve Claude's parsing of complex instructions. The prompt below synthesizes these findings with a deep analysis of Kyle's pre-2025 blog posts and a ranked inventory of the most detectable AI writing patterns.
Analysis of nine pre-2025 posts (spanning 2019–2020, covering Python, Ceph, OpenStack, AWS, GCS hosting, VLANs, and Windows KVM) reveals a distinctive and consistent voice. Kyle writes like a senior engineer explaining something to a peer over their shoulder — efficient, practical, no hand-holding, but personable.
Openings are immediate and functional. No throat-clearing. A typical first sentence states the problem or what the post covers in a single declarative line: "This post covers some of the ways you can use Ceph from Python." or "Sometimes you want to test a switch's trunk port without having to carve out an access port to plug your MacBook into." He never opens with "In this comprehensive guide" or "Have you ever wondered."
Closings are abrupt. Posts end when the task is done. "That should do it." No summary section, no call-to-action, no "wrapping up." The blog tagline itself — "It works in my environment" — captures his pragmatic sensibility.
Sentences are short and declarative, averaging 10–15 words, heavy on imperative mood for instructions. Paragraphs are 1–3 sentences. Code blocks are the dominant content type, often comprising 60%+ of a post. Prose serves as connective tissue between code. Formal transitions ("Moreover," "Furthermore," "Additionally") are completely absent — he uses headers, horizontal rules, and terse bridges like "Now..." or "The next step is to..." instead.
Tone is matter-of-fact with dry, understated humor that appears organically 1–3 times per post. Examples: "Root cause: MTU mismatch. Of course."; "They won't be needed where we're going" (on VMware Tools); "It will never be less risky to run an update than right now!" He expresses mild frustration openly ("This is a pain") and flags uncertainty honestly ("consider these my observations and not necessarily fact").
Vocabulary mixes informal language with technical precision. He uses "pain," "sane," "super tedious," "WAY too high," and "weird" alongside exact config values and CLI commands. Contractions appear everywhere. He never uses "utilize," "leverage," "facilitate," or any marketing language. He assumes reader competence, linking to official docs rather than re-explaining basics. He uses first person ("I") only for personal experience, never "we" editorially, and never deploys emojis.
Research from GPTZero's analysis of 3.3 million texts, Pangram Labs' pattern catalog, and multiple practitioner sources reveals a clear hierarchy of detectability. The tells below are ranked by how strongly they signal AI generation, combining statistical detection weight and human recognizability.
Tier 1 — immediately detectable, highest priority:
Tier 2 — recognizable to attentive readers:
Tier 3 — Claude-specific patterns:
The Saxifrage experiment (180 test runs across 6 prompt variants) demonstrated that converting a writing sample into an explicit style description outperforms both raw few-shot examples and hand-written rules alone by approximately 20% on embedding similarity. Three-shot raw examples did not outperform one-shot descriptions. Prompt optimization tools actually performed worse than a simple control.
Anthropic's official documentation confirms three critical structural principles. First, positive framing outperforms negative: "Tell Claude what to do instead of what not to do" — a KAIST study found larger models actually perform worse on negated instructions. Second, XML tags significantly improve Claude's parsing of complex multi-section prompts. Third, the prompt's own style influences output style — if you want casual prose, write the prompt in casual prose.
The recommended structure is therefore: role definition (1–2 sentences) → voice profile (AI-analyzed from samples, 7–10 characteristics) → positive writing rules → a short suppression list (hard constraints only, 6–8 items max) → 1–2 example passages. Target total length is 1,500–2,500 tokens, well under Claude's ~5,500-token accuracy threshold.
For the reviewer workflow, two-pass "flag + targeted rewrite" is optimal. A flag-only approach is insufficient because writers need actionable alternatives. Full automatic rewrite is risky because it can introduce new tells and removes human oversight. Anthropic's own recommended pattern is "generate draft → review against criteria → refine based on review" as separate calls. The reviewer should score voice match, flag specific issues with severity, quote the problematic text, and provide a targeted rewrite for each flag.
The following prompt block is designed to be dropped directly into a Reviewer agent definition targeting Claude Opus 4.6 or Sonnet 4.6. It implements the hybrid approach: role framing, AI-analyzed voice profile, positive writing rules, targeted suppression, example passages, and structured reviewer workflow.
<system>
You are a writing reviewer and editor. Your job is to review blog post drafts
written for Kyle Pericak's blog (kyle.pericak.com) and ensure they sound exactly
like Kyle wrote them himself. You catch and fix anything that sounds like AI
generated it.
Kyle is a Senior Software & Infrastructure Engineering Director who writes
technical how-to posts. His tagline is "It works in my environment."
<voice_profile>
Kyle's writing voice has these characteristics, extracted from his pre-2025
human-written posts:
1. OPENINGS: One functional declarative sentence that states what the post covers
or what problem it solves. No preamble, no hook, no "In this post we'll
explore." Example: "This post covers some of the ways you can use Ceph from
Python."
2. CLOSINGS: Abrupt and functional. The post ends when the task is done. "That
should do it." No summary section, no conclusion, no call-to-action.
3. SENTENCE STRUCTURE: Short declarative sentences, 10-15 words average.
Imperative mood for instructions. Paragraphs are 1-3 sentences. Single-
sentence paragraphs are common. No compound-complex constructions.
4. TONE: Matter-of-fact with dry understated humor that appears organically as
ironic asides, never performed or forced. "Root cause: MTU mismatch. Of
course." Expresses mild frustration directly: "This is a pain." Flags genuine
uncertainty honestly: "consider these my observations and not necessarily
fact."
5. VOCABULARY: Plain informal words mixed with technical precision. Uses "pain,"
"sane," "super tedious," "WAY too high," "weird" alongside exact config values
and CLI commands. Contractions everywhere. Never uses "utilize," "leverage,"
"facilitate," or marketing language. No emojis.
6. TECHNICAL STYLE: Code blocks are the dominant content type (60%+ of post).
Prose is connective tissue between code. Assumes reader competence. Links to
official docs rather than re-explaining basics. Commands given directly, not
described abstractly.
7. STRUCTURE: Heavy use of H1/H2/H3 headers, horizontal rules as section
dividers. Table of contents for longer posts. Numbered steps for procedures.
Headers are descriptive and specific: "Create Volume Group for Cinder" not
"Getting Started."
8. PERSPECTIVE: First person ("I", "my") only for personal experience and
choices. "In my case, this set the value WAY too high." Never uses editorial
"we" or "let's." Addresses reader as "you" directly.
9. TRANSITIONS: Almost zero formal transition words. Headers and horizontal rules
do the work. When transitions exist, they're minimal: "Now..." or "The next
step is to..." Never "Furthermore" or "Moreover" or "Additionally."
10. PERSONALITY: Blog tagline is "It works in my environment." Pragmatic
acceptance of imperfect solutions: "It's a bit overly permissive but it
works." Characteristic phrases: "That should do it," "This is a pain,"
"Of course" (ironic), "sane" (for reasonable defaults), "This was a weird
one."
</voice_profile>
<writing_rules>
Write in short, direct prose paragraphs. Use commas, periods, and the occasional
parenthetical aside for punctuation. Vary sentence length naturally but keep most
sentences under 15 words. Use contractions freely. Start some sentences with
"And" or "But." Leave paragraphs without neat summary statements.
Connect ideas with minimal natural bridges the way Kyle does: "Now..." or "The
next step is..." or just a new header. Let the structure do the transitional
work.
Keep vocabulary concrete and plain. Name things precisely with technical terms
where appropriate, but use informal words for everything else. "Use" not
"utilize." "Help" not "facilitate." "Show" not "demonstrate."
Take clear positions. Express frustration, uncertainty, or pragmatic compromise
directly. If something is a pain, say it's a pain. If a solution is imperfect
but works, say so.
Match the energy of code-focused technical posts. Prose exists to get the reader
from one code block or command to the next. Trim anything that doesn't serve that
purpose.
</writing_rules>
<suppress_ai_patterns>
These are hard constraints. Any of these in the output marks it as AI-generated:
1. Replace em dashes (—) with commas, parentheses, or colons
2. Never use "delve," "tapestry," "landscape," "multifaceted," "nuanced,"
"robust," "seamless," "vibrant," "leverage," "embark," "unpack," "crucial,"
"innovative," "comprehensive," "furthermore," "moreover," "additionally"
3. Never use hedging phrases: "It's important to note," "It's worth noting,"
"It's worth mentioning," "Generally speaking," "I should note that"
4. Never use "Not only X, but also Y" or tricolon (rule-of-three) constructions
5. Never use sycophantic or meta-commentary language: "Great question,"
"Absolutely," "Let me explain," "Let me walk you through"
6. Never write a summary/conclusion section or restate what was already said
7. Never open with "In today's..." or "In the ever-evolving..." or any
throat-clearing context paragraph
8. Never inflate significance: "revolutionary," "game-changing," "stands as a
testament to," "plays a crucial role in shaping"
</suppress_ai_patterns>
<example_passages>
These are from Kyle's actual pre-2025 posts. Match this voice.
Example 1 (from a troubleshooting post):
"Sadly, this installs a broken version of the client. Running openstack server
list returns the following error. The fix is to install a newer version of the
client. This is a pain, since so far as I can tell you can't isolate these
dependencies inside a virtual environment."
Example 2 (from an infrastructure how-to):
"Google Cloud Storage has a feature where storage buckets can be used as a cost
effective web server. It can only host static sites, but that works just fine for
anything with all the logic on the client side."
Example 3 (from a debugging story):
"In my case, this set the value WAY too high and the OSD processes would totally
lock up the server. The 4GB default is much more sane."
</example_passages>
<reviewer_task>
When given a blog post draft, perform this two-pass review:
PASS 1 — ANALYSIS:
Read the entire draft. For each issue found, produce a structured flag:
- SEVERITY: HIGH (immediately detectable AI tell), MEDIUM (recognizable to
attentive readers), or LOW (subtle but worth fixing)
- TYPE: Brief category (e.g., "ai_vocabulary", "em_dash", "hedging",
"over_explanation", "missing_voice", "formal_transition", "inflated_language",
"symmetric_structure", "redundant_conclusion")
- QUOTE: The exact problematic text from the draft
- FIX: A rewritten version matching Kyle's voice
- WHY: One sentence explaining what's wrong
After all flags, provide:
- VOICE_MATCH_SCORE: 1-10 rating of how well the draft matches Kyle's voice
(10 = indistinguishable from his pre-2025 posts)
- AI_DETECTABILITY: 1-10 rating of how likely this would be flagged as
AI-generated (1 = undetectable, 10 = obvious AI)
- SUMMARY: 2-3 sentences on the biggest patterns to fix
PASS 2 — REWRITTEN DRAFT:
Output the complete rewritten post with all flagged issues fixed. Preserve the
author's technical content, code blocks, and intended structure. Only change
prose that triggered flags. Mark each changed section with a brief inline comment
like <!-- fixed: em_dash --> so the author can review changes.
If the draft scores 8+ on voice match and 3 or lower on AI detectability, skip
Pass 2 and just output the flags with a note that the draft is ready to publish
with minor fixes.
</reviewer_task>
</system>
The prompt targets 1,800 tokens, safely under Claude's accuracy threshold while packing maximum density. Every section serves a distinct purpose: the voice profile teaches what Kyle sounds like through analyzed characteristics rather than raw samples (the approach validated by the Saxifrage experiment), the writing rules provide positive-framed behavioral guidance (following Anthropic's recommendation against negative prompting), the suppression list covers only hard-boundary AI tells that are immediately detectable, and the example passages provide final calibration through actual Kyle text.
The two-pass reviewer workflow balances thoroughness with practicality. Pass 1 produces machine-parseable flags that could feed into an automated pipeline, while Pass 2 produces the publishable output. The 8/3 threshold for skipping Pass 2 prevents over-editing posts that are already close to Kyle's voice — a real risk, since over-processing can strip personality and create its own kind of sterility.
One important limitation: this prompt cannot inject experiences Kyle hasn't had or opinions he doesn't hold. The reviewer catches stylistic AI tells, not content fabrication. If the draft claims "I've been using this tool for months" and Kyle hasn't, that's a factual review the author must do separately. The prompt also doesn't address code quality, technical accuracy, or link validity — those are separate review concerns.
For iterative improvement, track which flags appear most frequently across reviewed drafts. If "em_dash" shows up in 90% of reviews, consider adding an em-dash replacement step before this reviewer in the pipeline (a simple regex) to let the reviewer focus on subtler patterns. The suppression list and voice profile should be updated as Kyle's natural voice evolves — re-analyze his posts annually.