De-AI Prose

Review or revise prose that may feel generated or heavily AI-polished without damaging its technical precision, clarity, or authorial voice.

Invocation

Use one of these modes:

• review — diagnose signals and recommend targeted changes. This is the default.
• rewrite — return a revised version without modifying files.
• edit — revise the named files in place.

Interpret $ARGUMENTS as:

[review|rewrite|edit] [one or more file paths]

If no file is named, use the prose supplied in the conversation. Do not modify files unless the user explicitly selects edit. If edit is selected but no file path is given, fall back to rewrite and say so; do not guess which file was meant.

For long documents, rewrite still returns the complete revised prose. Do not summarize, truncate, or revise only excerpts.

Core principle

Do not ask whether a sentence is polished. Ask whether the text repeatedly uses the same polished rhetorical machinery.

A single antithesis, triad, analogy, or memorable sentence is normal human writing. Treat it as a signal only when it forms a conspicuous pattern.

Never claim certainty that AI wrote a text. Distinguish among:

• likely human-authored;
• human-authored but AI-polished;
• strongly formulaic or generated-sounding;
• impossible to determine from style alone.

Preserve

Keep these unchanged unless they are factually or grammatically wrong:

• measurements, counts, dates, names, commands, symbols, and API identifiers;
• technical terminology and causal relationships;
• qualifications, uncertainty, limitations, and negative results;
• useful concrete detail;
• the author's level of technical sophistication.

Technical specificity is evidence of substance, not evidence of AI.

Do not humanize by degradation

Do not add:

• fake anecdotes or personal history;
• invented uncertainty;
• deliberate typos or grammatical errors;
• arbitrary slang, contractions, or filler;
• random sentence-length variation;
• needless hostility or informality;
• unsupported claims about the author's intent.

The goal is natural technical prose, not worse prose.

Signals to inspect

1. Repeated rhetorical reversals

Look for recurring forms such as:

• “X was real. Y was not.”
• “It was A, not B.”
• “That claim is true, but it is not the same as...”
• “Every clue pointed to X. Every clue was wrong.”

One use may be effective. Repetition makes the prose feel manufactured.

2. Slogan density

Flag paragraphs where many sentences are shaped as quotable conclusions:

• compressed one-liners;
• aphorisms;
• dramatic fragments;
• named takeaways;
• statements optimized to sound memorable rather than to carry evidence.

Examples of the pattern: “the allocator was the amplifier” or “pointer-only traces lied” in a debugging post-mortem; “the schema is the contract” in a design doc; “tests are documentation that cannot lie” in a process article. Do not remove a strong line automatically; reduce the surrounding density.

3. Excessive triads and parallelism

Look for repeated groups of exactly three:

• three questions;
• three proofs;
• three clauses with matching grammar;
• three escalating examples.

Parallel structure is useful, but repeated perfect symmetry can feel generated.

4. An unnaturally perfect narrative arc

Check whether the investigation has been rewritten into an overly clean sequence:

1. convincing false theory;
2. decisive contradiction;
3. deeper conceptual insight;
4. elegant fix;
5. universal lesson.

A retrospective article may legitimately be structured this way. Flag it only when the prose hides uncertainty, failed branches, mundane transitions, or unresolved details to preserve the arc.

5. Excessive explanatory signposting

Look for sentences that repeatedly tell the reader how to interpret the evidence:

• “Hold that fact next to...”
• “The whole puzzle is in the gap...”
• “Think of it as...”
• “This is the story of...”
• “The lesson is...”

Prefer direct evidence and causal explanation when the interpretation is already clear.

6. Generic dramatic framing

Flag stock technical-blog framing such as:

• “Every clue was wrong.”
• “The bug that was not a bug.”
• “The most convincing experiment was also the most misleading.”
• “What happened next changed the investigation.”

Retain drama supported by the facts, but remove framing that could fit almost any debugging story.

7. Executive-copy TL;DR structure

Inspect whether every bullet has the same generated cadence:

1. punchy conclusion;
2. compact mechanism;
3. universal takeaway.

Vary bullets according to their actual function. Some should report results, some mechanisms, some caveats, and some fixes.

8. Retrospective over-certainty

Look for a complete absence of phrases such as:

• “at that point”;
• “on this kernel”;
• “the evidence suggested”;
• “I had not yet ruled out”;
• “this explained most, but not all, of the loss.”

Do not insert uncertainty mechanically. Restore it only where the work genuinely had uncertainty or scope limits. If the text does not reveal what the real uncertainty was, ask the author rather than inventing it; a terse, confident write-up by a human who was actually certain contains none of these phrases and needs no change.

9. Uniform polish

Inspect whether nearly every paragraph contains:

• an opening hook;
• a clean explanatory middle;
• a quotable closing line.

Human prose normally contains some merely functional sentences and transitions. Replace repetitive rhetorical closure with direct continuation where appropriate.

10. Surface-level chatbot tells

The signals above target well-written prose that was AI-polished. Raw generated output has cruder tells; check for these too:

• bold-term-colon bullet lists (“Speed: it is fast”) used where a sentence would do;
• stock vocabulary: delve, crucial, robust, leverage, seamless, comprehensive, “it's worth noting”, “in conclusion”;
• em-dash overuse where commas or separate sentences would be natural;
• a heading for every few sentences of a short document;
• uniformly sized paragraphs regardless of content;
• hedging boilerplate that qualifies nothing specific.

These are weaker evidence individually than the structural signals, since many humans have adopted them; weigh density, not presence.

For bulk em-dash removal in edit mode, scripts/fix-em-dashes.sh replaces every em-dash mechanically (default -, override with -r, count with -n). Use it only when the user wants blanket removal; it cannot choose between a comma, a period, or parentheses, so the default remains contextual editing. Review the result afterwards either way.

Review procedure

1. Read the full text before marking individual sentences.
2. Identify the author's apparent natural voice from less-polished passages, nearby documents, or existing project prose when available.
3. Separate technical substance from rhetorical presentation.
4. Find repeated patterns. Do not build a verdict from isolated examples.
5. Rank the three to five strongest signals by impact.
6. Identify counterevidence that makes the text feel human or grounded.
7. Recommend the smallest edits that would materially reduce the generated feel.
8. State whether the likely issue is generation, heavy polishing, or simply deliberate technical writing.

Revision procedure

When using rewrite or edit:

1. Preserve every factual claim unless correction is explicitly requested.
2. Remove or combine repeated rhetorical reversals.
3. Convert excess slogans into ordinary causal statements.
4. Break perfect triads when the grouping has no technical significance.
5. Put evidence before interpretation where practical.
6. Replace generic drama with concrete observations.
7. Keep strong sentences selectively rather than flattening all personality.
8. Let paragraph lengths and structures follow the material rather than a template.
9. Keep analogies only when they explain something the technical description does not.
10. Make the TL;DR informational rather than promotional.
11. Restore real uncertainty and scope constraints.
12. Compare the revision against the source for lost measurements, identifiers, caveats, and causal links.

Output format

Review mode

Use this compact structure:

## Verdict

One paragraph describing the overall level and likely type of AI influence.

## Strongest signals

| Signal | Evidence | Why it registers | Minimal fix |
|---|---|---|---|

Include only the strongest three to five patterns.

## Counterevidence

Concrete details that make the text feel grounded, technically authored, or plausibly human.

## Prescription

The smallest set of changes likely to improve the prose.

Quote only short excerpts needed to identify a pattern.

Rewrite mode

Return:

1. the complete revised prose;
2. a brief list of the most consequential changes;
3. any factual ambiguity that prevented a safe rewrite.

Do not interleave commentary with the revised prose.

Edit mode

Edit the requested files, then report:

• files changed;
• the main rhetorical patterns reduced;
• any passages deliberately left unchanged;
• verification that technical values and identifiers were preserved.

Final checks

Before finishing, verify:

• Did the review rely on repeated patterns rather than isolated style choices?
• Did the revision preserve technical evidence and causal structure?
• Did it reduce formulaic polish without making the prose clumsy?
• Did it avoid inventing personality, uncertainty, or history?
• Did it acknowledge that skilled humans can deliberately write polished prose?
• Did it distinguish “AI-generated” from “AI-edited” where possible?