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.
In this repository18 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- android-app-reverserSkill
- android-emulator-app-live-inspectSkill
- aula-pii-scanSkill
- de-ai-proseSkill
- drawio-figure-reviewerSkill
- explainer-videoSkill
- justfile-hygieneSkill
- model-raceSkill
- nix-scaffoldSkill
- phase1-prd-grillSkill
- phase2-backlog-snowballSkill
- phase3-backlog-ralphSkill
- readme-improverSkill
- refactor-smellerSkill
- scrub-for-publicSkill
- xterm-tmux-controlSkill
- zellij-controlSkill
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
- Very specific: line 35
If no path is given, default to the repo root and the common artifact locations below.
- Very specific: line 42
Commit messages: git log --format='%B' -n 400 (or a range the user names).
- Distinctive: line 72
When in doubt, treat it as immutable and report rather than edit.
- Very specific: line 79
Before flagging vocabulary, extract the project's legitimate glossary from its canonical sources (TESTING.md, design docs, a GLOSSARY.md, …
- Very specific: line 146
Run the grep/rg basis for each tell.
- Distinctive: line 152
Every number must be reproducible from a stated command.
- Distinctive: line 156
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 …
- Distinctive: line 173
Keep the project's adopted jargon (bucket 1) and any deliberately strong line.
- Very specific: line 175
Do not humanize by degradation: no invented anecdotes, fake uncertainty, deliberate errors, or filler (see de-ai-prose, "Do not humanize by …
- Distinctive: line 185
If the project keeps agent memory, write a short feedback memory naming the top 3–5 tells this project actually exhibits, with the …
- Distinctive: line 191
Keep the guardrail short and specific to observed patterns.
≈ “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.
Files
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, aCLAUDE.mdsection, 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/-cand 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:
- Adopted jargon — defined in the glossary, load-bearing to meaning. Flag for density only (is it stacked onto every noun?), never for mere presence.
- Context-dependent — a real engineering term that LLMs also overuse. Flag with its count and glossary status, and let the author decide.
- 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 -lplusgrep -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 -lagainst 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
- Concatenate or iterate each corpus; get a word count for density ratios.
- Run the
grep/rgbasis for each tell; record raw counts and per-1000-word density where relevant. - Pull 2–4 verbatim examples per high-signal tell, with a short source label (commit / backlog / PRD / transcript). Quote exactly; keep excerpts short.
- Rank tells by signal, not by raw count alone (a structural tell at count 50 outranks an em-dash at count 900).
- 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)
- Confirm the surface is mutable (scope discipline above). Skip immutable ones.
- Preserve every factual claim, number, date, identifier, command, and causal link. Technical specificity is substance, not a tell.
- 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.
- Keep the project's adopted jargon (bucket 1) and any deliberately strong line. Do not flatten all voice.
- Do not humanize by degradation: no invented anecdotes, fake uncertainty,
deliberate errors, or filler (see
de-ai-prose, "Do not humanize by degradation"). - 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.
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
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.

