agentleFS
eisbaweisbaw/mped-skills/skills/de-ai-repo/SKILL.md

de-ai-repo

Skill11 starsChanged 3 months agoMITView on GitHub

Audit and remediate AI-writing tells across a whole repository or corpus of artifacts — commit messages, backlog/issue notes, design docs, PRDs, READMEs, code comments, memory files, and session transcripts — not just a single document. Runs a quantitative, reproducible forensic sweep (grep/rg frequency and density, verbatim examples), separates genuine adopted domain jargon from AI stylistic tics using a per-project glossary, then rewrites only the mutable surfaces while leaving immutable history alone. Use when asked to find how AI-obvious a project's writing has become, scrub tells from its docs, or set up guardrails against them. For rewriting one narrative document's rhetoric, defer to the de-ai-prose skill.

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 6 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If no path is given, default to the repo root and the common artifact locations below.

    line 35
  2. Very specific:

    Commit messages: git log --format='%B' -n 400 (or a range the user names).

    line 42
  3. Distinctive:

    When in doubt, treat it as immutable and report rather than edit.

    line 72
  4. Very specific:

    Before flagging vocabulary, extract the project's legitimate glossary from its canonical sources (TESTING.md, design docs, a GLOSSARY.md, …

    line 79
  5. Very specific:

    Run the grep/rg basis for each tell.

    line 146
  6. Distinctive:

    Every number must be reproducible from a stated command.

    line 152
  7. Distinctive:

    If the corpus spans many files (roughly >12 documents, or transcripts in the tens of MB), delegate to read-only sub-agents (Task tool, one …

    line 156
  8. Distinctive:

    Keep the project's adopted jargon (bucket 1) and any deliberately strong line.

    line 173
  9. Very specific:

    Do not humanize by degradation: no invented anecdotes, fake uncertainty, deliberate errors, or filler (see de-ai-prose, "Do not humanize by …

    line 175
  10. Distinctive:

    If the project keeps agent memory, write a short feedback memory naming the top 3–5 tells this project actually exhibits, with the …

    line 185
  11. Distinctive:

    Keep the guardrail short and specific to observed patterns.

    line 191

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

de-ai-repo — corpus-scale AI-writing audit and remediation

de-ai-prose reviews one document's rhetoric. This skill works one level up: it sweeps a repository's whole body of written artifacts, measures how AI-obvious they have become with reproducible counts, and remediates the surfaces that can still be edited. Reach for it when the unit of work is "the project's writing," not "this article."

The two skills compose. When this skill rewrites a specific narrative document, it applies de-ai-prose's signal catalog and its "do not humanize by degradation" rule. This skill adds what a single-document tool cannot do: frequency across many files, the jargon-versus-tic distinction, mutable-versus- immutable scope discipline, and a fan-out for large corpora.

Modes

Parse $ARGUMENTS as [audit|remediate|guard] [one or more paths].

  • audit (default) — read-only forensic report with counts, examples, and a ranked tell list. Changes nothing.
  • remediate — audit, then rewrite the mutable surfaces in place, then re-count to show the drop. Requires an audit first (run it in the same pass).
  • guard — write or update a project rule (a memory file, a CLAUDE.md section, or a lint recipe) so future writing avoids the tells this project actually exhibits.

If no path is given, default to the repo root and the common artifact locations below. Never edit in audit mode.

The corpora (where a repo's AI writing lives)

Sweep these by default; skip any that do not exist:

  • Commit messages: git log --format='%B' -n 400 (or a range the user names).
  • Issue/task trackers: backlog/tasks/*.md, .backlog/**, issue exports.
  • Design docs: PRD.md, docs/**/*.md, TESTING.md, ARCHITECTURE.md, ADRs.
  • README* and sub-READMEs.
  • Agent/instruction files: CLAUDE.md, AGENTS.md.
  • Code comments and doc-comments (sample by language: ///, /** */, #).
  • Auto-memory: the session memory directory, if the project uses one.
  • Session transcripts, if the user asks and they are available. These are large; never full-read them. Grep with -o/-c and sample a few hits per pattern.

Scope discipline — what may be rewritten

This is the rule that keeps remediation honest.

Mutable (remediate freely): design docs, READMEs, PRDs, open/in-progress task notes, code comments, memory files, uncommitted drafts. These are living text; improving them is safe.

Immutable (audit and report, never rewrite):

  • Committed git history (commit messages already pushed or shared). Rewriting history to scrub prose is destructive and almost never worth it. Report the density so the author fixes it going forward; leave the log alone.
  • Published releases, changelogs for shipped versions, signed or frozen artifacts, golden vectors, anything a downstream consumer pins.
  • Text written by other people. Audit only your own project's authored prose.
  • Closed/Done task records where the note is the historical account of what happened. Correcting a factual error is fine; restyling a settled record is churn.

When in doubt, treat it as immutable and report rather than edit. Say in the output which surfaces you classified each way.

Build the project's jargon glossary first (avoids false positives)

The single most important refinement over a naive tell-scan: a term that this project has defined and adopted as a term of art is not automatically a tic. Before flagging vocabulary, extract the project's legitimate glossary from its canonical sources (TESTING.md, design docs, a GLOSSARY.md, memory files): any term that is explicitly defined and used consistently as a concept.

Then classify every vocabulary hit into one of three buckets:

  1. Adopted jargon — defined in the glossary, load-bearing to meaning. Flag for density only (is it stacked onto every noun?), never for mere presence.
  2. Context-dependent — a real engineering term that LLMs also overuse. Flag with its count and glossary status, and let the author decide.
  3. Ornament — carries no meaning the plain word lacks. Recommend removal.

The author owns the final call on buckets 1 and 2. This skill surfaces frequency and classification; it does not strip a project's real vocabulary.

Tell lexicon

Structural tells carry the most signal; surface tells are weaker individually and judged by density. Every count must be reproducible — state the grep/rg basis in the report.

Structural (high signal)

  • Corrective antithesis: "X, not Y" / "not X but Y" / "A is not a B, it is a C." One is fine; repetition is the tell. Basis: grep -oF ', not ' | wc -l plus grep -oiE 'not [a-z]+,? (but|it.s|rather)'.
  • Slogan density: many sentences shaped as quotable conclusions ("the schema is the contract"). Reduce the surrounding density; keep the occasional strong line.
  • Triads / rule of three: repeated groups of exactly three parallel items. Basis: grep -oiE '[a-z]+, [a-z]+,? and [a-z]+'.
  • Signposting: "The key insight," "The whole point," "It is worth noting," "Here's the thing," "Think of it as," "The lesson is."
  • Over-clean narrative arc in a retrospective: false theory → decisive contradiction → deeper insight → elegant fix → universal lesson, with the real dead ends hidden. Defer to de-ai-prose §4 for the full treatment.

Surface (judge by density, not presence)

  • Em-dash asides. Natural technical prose runs ~1–2 per 1000 words; >5 is a tell. Basis: grep -o '—' <file> | wc -l against a word count.
  • ALL-CAPS mid-sentence emphasis (MUST, NOT, ONLY, NEVER, THE). A formatting reflex; lowercase and let word choice carry weight. Basis: grep -oE '\b(MUST|NOT|ONLY|NEVER|EXACTLY|THE)\b'.
  • Bold-term-colon list items ("Speed: it is fast") where a sentence would do.
  • Turn-opening narration in transcripts: "Let me…", "I'll…", "Perfect,".
  • Emphatic closers: "exactly this," "that is the point," "and that is the whole point."
  • Stock vocabulary: delve, crucial, robust, leverage, seamless, comprehensive, "it's worth noting," "in conclusion."
  • Ornamental metaphor nouns: load-bearing, cornerstone, keystone, vacuous, tautological — when used as decoration rather than a defined term.

Context-dependent (real terms LLMs overuse — flag, defer to the author)

oracle, fail-closed, fail-open, seam, bite/bites, provenance, de-risk, surface (as a verb), honest/honestly. Each is legitimate in security, systems, or test writing, and each is also an LLM favourite. Report the count and whether the glossary defines it; recommend moderation, not deletion, when it is genuinely adopted. oracle/fail-closed/fail-open in particular read as tells to many human reviewers even when technically correct, so surface them explicitly.

Quantitative method

  1. Concatenate or iterate each corpus; get a word count for density ratios.
  2. Run the grep/rg basis for each tell; record raw counts and per-1000-word density where relevant.
  3. Pull 2–4 verbatim examples per high-signal tell, with a short source label (commit / backlog / PRD / transcript). Quote exactly; keep excerpts short.
  4. Rank tells by signal, not by raw count alone (a structural tell at count 50 outranks an em-dash at count 900).
  5. Every number must be reproducible from a stated command.

Fan-out for large corpora

If the corpus spans many files (roughly >12 documents, or transcripts in the tens of MB), delegate to read-only sub-agents (Task tool, one per doc cluster) rather than reading everything in the main context. Give each the same tell lexicon and glossary, and require grep-based counting with sampled examples — not full reads. Reconcile their returned counts and examples centrally. Log any cluster you sampled rather than read exhaustively; never present a sampled sweep as complete.

Remediation workflow (remediate mode)

  1. Confirm the surface is mutable (scope discipline above). Skip immutable ones.
  2. Preserve every factual claim, number, date, identifier, command, and causal link. Technical specificity is substance, not a tell.
  3. Make the smallest edits that reduce the generated feel: collapse repeated antitheses to a plain positive statement, thin em-dashes to commas/periods, lowercase shouted emphasis, replace ornamental metaphors with the plain role, vary templated bullet cadence.
  4. Keep the project's adopted jargon (bucket 1) and any deliberately strong line. Do not flatten all voice.
  5. Do not humanize by degradation: no invented anecdotes, fake uncertainty, deliberate errors, or filler (see de-ai-prose, "Do not humanize by degradation").
  6. Re-run the counts on the edited surface and report the before/after drop as evidence the remediation worked.

Guard mode

Turn the audit's findings into a durable rule so the tells do not recur:

  • If the project keeps agent memory, write a short feedback memory naming the top 3–5 tells this project actually exhibits, with the plain-language alternative for each. Prefer the specifics found here over a generic list.
  • Optionally add a CLAUDE.md/AGENTS.md "writing style" note, or a lint recipe that greps for the highest-signal patterns and reports density (a warning, not a hard failure — these are heuristics).
  • Keep the guardrail short and specific to observed patterns; a long generic style guide gets ignored.

Output format

Audit

## Corpora measured
Files/commits scanned, word counts, which surfaces are mutable vs immutable.

## Ranked tells
For each, most-obvious first:
- name — count (with the grep basis) and density where relevant
- 2–4 verbatim examples with source labels
- classification: structural / surface / adopted-jargon / context-dependent / ornament

## Top 5 that would flag this as AI-authored
Each with a concrete, plainer alternative.

## Recommendation
Which mutable surfaces are worth remediating, and what to leave (and why).

Remediate

Report files changed, the patterns reduced, before/after counts, passages left unchanged and why, and confirmation that numbers and identifiers were preserved.

Anti-patterns

  • Rewriting committed git history or a shipped changelog to scrub prose.
  • Stripping a project's defined domain jargon because it appears on an LLM-tell list.
  • Flattening every sentence into the same plain cadence, erasing real voice.
  • Reporting counts you cannot reproduce, or presenting a sampled sweep as exhaustive.
  • Writing the audit report itself in the tells it catalogs (antithesis stacks, em-dash asides, shouted caps). Practice the prescription.
  • Humanizing by degradation — adding fake personality or invented uncertainty.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.