anti-ai-prose

Anti-AI-Prose: Audit Writing for Machine-Generated Patterns

Detect and fix the linguistic tells that make written English read as machine-generated. The goal is prose that sounds like a specific, thoughtful human wrote it.

This skill applies to any text: documentation, READMEs, wikis (Confluence, Notion, internal), pull request descriptions, commit messages, release notes, blog posts, emails, slide copy, creative writing, and code comments / docstrings. The vocabulary, syntax, tone, and formatting checks are language-domain, not platform-domain.

Based in part on Wikipedia: Signs of AI writing - a field guide compiled by editors who have read enormous volumes of LLM-generated text and know what it actually looks like.

When to use

• Auditing a README, doc page, or wiki article that feels machine-written
• Reviewing a PR body, commit message, or release note draft before publishing
• Polishing a blog post, email, or presentation script you wrote with LLM help
• Checking creative writing (fiction, essays) for AI tells after an LLM-assisted pass
• Reviewing docstrings and code comments for the same prose patterns
• Any time someone says "this sounds like ChatGPT wrote it"
• Self-check after a heavy LLM-drafting session

When NOT to use

• Code quality, over-abstraction, dependency creep, stale idioms - use anti-slop
• Doc drift after a feature change, API rename, or config update - use update-docs
• Generating or restructuring a prompt from rough notes - use prompt-generator
• Correctness bugs, logic errors, edge cases - use code-review
• Security review of auth, secrets, or attack surface - use security-audit
• Full multi-dimensional repo audit - use full-review

AI Self-Check

Before returning any audit, verify:

• [ ] Findings are patterns, not taste: the issue is a demonstrable AI tell (from the Wikipedia guide or observed LLM output), not personal writing preference
• [ ] Context respected: academic and technical prose can look formal without being AI-generated. Journalism, marketing, and tourism writing have legitimate conventions that overlap with AI tells. Do not flag genre conventions as AI tells
• [ ] Direct quotes preserved: do not edit quoted material from other authors, even if it contains banned vocabulary
• [ ] Domain terms kept: pivotal in hinge hardware specs, landscape in horticulture, foster as a verb in child welfare, realm in fantasy fiction - these are not tells in context
• [ ] Code blocks untouched: do not flag identifiers, strings, or code comments that contain banned words as part of functional code
• [ ] Rewrites are real improvements: every "after" is shorter, clearer, or more specific than the "before". No lateral rewrites that just swap synonyms
• [ ] Severity is honest: do not inflate P3 findings to P2 to pad the report
• [ ] Density and short-text rule applied: density heuristic applied before assigning severity; for text under 100 words, 2+ tells in one paragraph = P1 regardless of per-500-word threshold
• [ ] Audit output itself uses no AI-prose tells (apply these rules to your own output)
• [ ] AI fallback names checked (fiction): protagonist and major-character names compared against the documented fallback set (Elara, Lyra, Aurora, Kael, Vale, Cassius, etc.) and the phonetic tell (2 soft syllables, A/L/R/N consonants, no demographic anchor); fallback-set names allowed only when the setting and population organically produce them
• [ ] Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them
• [ ] Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting
• [ ] Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths
• [ ] Routing overlap checked: overlapping skills, trigger terms, and "When NOT to use" boundaries are checked before returning guidance
• [ ] Spec claims verified: claims about tool behavior, output contracts, or repo conventions are checked against current docs, scripts, or skill files
• [ ] Adverb stacking checked: -ly adverb density scanned; passages with multiple adverb-modified speech tags or adjacent adverb clusters flagged at the same density threshold as vocabulary tells
• [ ] Overflagging avoided: plain but valid technical prose is not labeled AI-written without concrete evidence
• [ ] Audience preserved: edits keep the author's domain vocabulary, intent, and required formality

Performance

• Review a representative sample first, then expand only if the same pattern repeats across the document.
• Group repeated prose issues by pattern instead of leaving near-duplicate comments on every paragraph.
• Prioritize high-visibility text: titles, summaries, intros, conclusions, and user-facing docs.

Best Practices

• Flag exact phrases and structural patterns, not vibes.
• Offer replacement copy when the fix is obvious; otherwise describe the problem and let the author decide.
• Do not erase necessary caveats, compliance language, or domain-specific precision to make prose sound casual.

Workflow

Step 1: Scope the audit

Default scope based on context:

• If invoked on a specific file or paste - audit that text
• If invoked with no target and there are uncommitted changes to .md / .txt / doc files - audit those
• If invoked in a code repo with recent commits - audit the docstrings and comments in changed files
• Otherwise - ask the user for a target

Available scopes:

• Single file - one doc, README, draft, or source file
• Directory - all .md / .rst / .txt under a path
• Pasted text - inline block the user supplies
• Recent changes - git diff against a base
• Comments and docstrings only - scan code files but audit only prose regions

Step 2: Detect text kind

Different text types have different conventions. Before flagging, identify which applies:

• Technical docs - formal is OK, but vocabulary bans still apply
• README / PR / commit - concise is expected, significance padding is especially jarring
• Marketing / product copy - tonal tells (boast, showcase) may be intentional but still weaken the writing
• Creative fiction - many tells (tricolons, elegant variation) are legitimate devices; flag only when they read as mechanical
• Wiki article - neutral voice required, promotional language is always a finding
• Email - conversational is expected, formality inflation is a tell
• Slides / presentation - fragments are fine, but vocabulary and tonal tells still apply

Step 3: Scan for patterns

Apply the four categories (see below). For each match, read the surrounding context - a single instance of an AI word in a 5000-word document is probably noise, but three instances in three paragraphs is a pattern.

Density heuristic (rough guide, not a hard rule):

• Under 1 flagged item per 500 words - noise, usually do not flag
• 2-3 per 500 words - a pattern, flag the cluster as P2
• 4+ per 500 words - dominant voice, P1 severity, recommend structural rewrite

Short text scaling: for text under 100 words, any 2+ tells in a single paragraph is P1 severity regardless of the per-500-words threshold. A single sentence crammed with AI vocabulary is worse than a long doc with scattered instances.

Density only applies to vocabulary and syntax tells. A single travel-guide paragraph is enough to flag on its own. One fabricated citation is always P1.

Classify each finding by category, action, and severity:

Action:

• Fix - clearly a tell, should change
• Consider - judgment call, present it and let the user decide