agentleFS
DeevsDeevsDeevsDeevs/agent-system/anti-ai-slop/SKILL.md

anti-ai-slop

Skill40 starsChanged 8 months agoApache-2.0View on GitHub

After working on the code, ensure the branch contains only the minimal, idiomatic changes by removing AI-generated slop introduced on this branch.

We split this skill into the rules it gives an agent

25 rules. 0 are common, 22 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 22

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Guiding principle: keep the smallest change that accomplishes the goal, and match the local conventions of each touched file.

    line 10
  2. Distinctive:

    If main does not exist locally, use git diff master..HEAD.

    line 21
  3. Distinctive:

    Do not refactor unrelated code outside the displayed diff hunks.

    line 23
  4. Distinctive:

    Do not redesign architecture, rename APIs, or move code unless required by the feature/fix in the diff.

    line 27
  5. Distinctive:

    Do not remove meaningful domain comments that encode invariants, reasoning, constraints, or known pitfalls.

    line 28
  6. Distinctive:

    Do not remove validation at genuine trust boundaries (I/O, parsing, network, user input, third-party callbacks).

    line 29
  7. Distinctive:

    Do not change formatting rules.

    line 30
  8. Distinctive:

    Remove comments/docstrings that merely narrate the code, restate names, or are inconsistent with the file’s comment density and tone.

    line 36
  9. Very specific:

    Remove checks that are redundant because upstream validation/types/invariants already guarantee inputs.

    line 61
  10. Distinctive:

    If the rest of the codebase treats empty tags as impossible here (validated earlier), keep only the essential logic:

    line 73
  11. Distinctive:

    Remove wrappers that only rethrow, add inconsistent logging, or hide errors without providing recovery.

    line 84
  12. Distinctive:

    If the repository does not use log-and-rethrow at this layer, prefer:

    line 98
  13. Distinctive:

    Prefer inlining when it improves clarity and matches surrounding style.

    line 109
  14. Very specific:

    If key is not reused and inlining remains readable:

    line 128
  15. Distinctive:

    If a caller guarantees an invariant, remove repeated checks in the callee unless the subsystem consistently enforces invariants at every …

    line 137
  16. Distinctive:

    Remove or rewrite changes that introduce new patterns inconsistent with the file or repository norms, such as:

    line 158
  17. Distinctive:

    Remove logs that restate the line of code, are inconsistent with the module’s logging level, or spam hot paths.

    line 166
  18. Distinctive:

    Remove “TODO: handle edge cases” style notes that add no actionable guidance and are not aligned with repository practices.

    line 185
  19. Distinctive:

    Remove suspicious or unnecessary Unicode in code and configs, including:

    line 189
  20. Distinctive:

    When in doubt, follow existing patterns in the same module/subsystem.

    line 227
  21. Distinctive:

    Remove additions that are not required to achieve it.

    line 234
  22. Distinctive:

    Remove unused imports, dead code, and redundant helper layers introduced by the branch.

    line 236
  23. Distinctive:

    Keep changes minimal: avoid unrelated refactors.

    line 237
  24. Distinctive:

    Ensure changes still satisfy AGENTS.md (and other repo policies).

    line 238
  25. Very specific:

    If repository tooling exists (formatters/linters/tests), avoid introducing new warnings.

    line 239

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “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

Intent

This skill reviews the diff against main and removes changes that are likely “AI slop”: unnecessary, non-idiomatic, or inconsistent additions that do not materially contribute to the intended feature/fix.

Guiding principle: keep the smallest change that accomplishes the goal, and match the local conventions of each touched file.

Scope and diff source

Operate only on changes introduced on this branch relative to main.

Determine the diff source in this order:

  1. git diff --cached (if non-empty)
  2. git diff (if non-empty)
  3. git diff main..HEAD (fallback)
    If main does not exist locally, use git diff master..HEAD.

Do not refactor unrelated code outside the displayed diff hunks.

Non-goals

  • Do not redesign architecture, rename APIs, or move code unless required by the feature/fix in the diff.
  • Do not remove meaningful domain comments that encode invariants, reasoning, constraints, or known pitfalls.
  • Do not remove validation at genuine trust boundaries (I/O, parsing, network, user input, third-party callbacks).
  • Do not change formatting rules; follow repository tooling and the file’s established style.

What counts as AI slop

A) Comment and documentation bloat

Remove comments/docstrings that merely narrate the code, restate names, or are inconsistent with the file’s comment density and tone.

Python (before):

def clamp(x: float, lo: float, hi: float) -> float:
    # Ensure x is not less than lo and not greater than hi
    if x < lo:
        return lo
    if x > hi:
        return hi
    return x

Python (after):

def clamp(x: float, lo: float, hi: float) -> float:
    if x < lo:
        return lo
    if x > hi:
        return hi
    return x

B) Unnecessary defensive checks inside trusted codepaths

Remove checks that are redundant because upstream validation/types/invariants already guarantee inputs.

Rust (before):

pub fn normalize_tag(tag: &str) -> String {
    if tag.is_empty() {
        return String::new();
    }
    tag.trim().to_ascii_lowercase()
}

If the rest of the codebase treats empty tags as impossible here (validated earlier), keep only the essential logic:

Rust (after):

pub fn normalize_tag(tag: &str) -> String {
    tag.trim().to_ascii_lowercase()
}

C) Try/catch / try blocks that add no value

Remove wrappers that only rethrow, add inconsistent logging, or hide errors without providing recovery.

C++ (before):

void SaveRow(Db& db, const Row& row) {
  try {
    db.Save(row);
  } catch (const std::exception& e) {
    std::cerr << "Error saving row: " << e.what() << std::endl;
    throw;
  }
}

If the repository does not use log-and-rethrow at this layer, prefer:

C++ (after):

void SaveRow(Db& db, const Row& row) {
  db.Save(row);
}

D) Single-use variables and one-off helpers that should be inlined

Prefer inlining when it improves clarity and matches surrounding style.

Python (before):

clean = s.strip().lower()
return clean

Python (after):

return s.strip().lower()

Rust (before):

let key = format!("{}:{}", user.id, user.region);
cache.insert(key, value);

If key is not reused and inlining remains readable:

Rust (after):

cache.insert(format!("{}:{}", user.id, user.region), value);

E) Redundant checks/casts duplicated at caller and callee

If a caller guarantees an invariant, remove repeated checks in the callee unless the subsystem consistently enforces invariants at every boundary.

Python (before):

def handle(req: Request) -> Response:
    user = parse_user(req)  # guarantees user.id is present
    return do_work(user)

def do_work(user: User) -> Response:
    assert user.id is not None
    return Response(user.id)

Python (after):

def do_work(user: User) -> Response:
    return Response(user.id)

F) Style drift and inconsistency with the file

Remove or rewrite changes that introduce new patterns inconsistent with the file or repository norms, such as:

  • Adding type annotations in a Python file that otherwise does not use them.
  • Introducing novel error-handling idioms in Rust (e.g., custom Result wrappers) where the module uses simple anyhow::Result (or vice versa).
  • Adding complex abstractions (factories/providers/managers) for small local logic.

G) Noisy logging and narration

Remove logs that restate the line of code, are inconsistent with the module’s logging level, or spam hot paths.

Rust (before):

log::info!("Starting normalization");
let out = normalize_tag(tag);
log::info!("Finished normalization");
out

Rust (after):

normalize_tag(tag)

(Keep logs that support production debugging when the module’s convention calls for them.)

H) Placeholder TODOs without a ticket/reference

Remove “TODO: handle edge cases” style notes that add no actionable guidance and are not aligned with repository practices.

I) Unicode hazards and emoji noise in code/comments

Remove suspicious or unnecessary Unicode in code and configs, including:

  • non-breaking spaces (U+00A0)
  • zero-width characters (U+200B, U+200D)
  • “smart quotes” (“ ” ‘ ’) in code/config
  • homoglyphs in identifiers
  • emojis in code comments/docs unless the repository explicitly uses them

Python (before):

# ✅ Done! 🚀
name = "ab​c"  # zero-width space

Python (after):

name = "abc"

(Do not “sanitize” legitimate localized/user-facing content unless it appears to be accidental.)

Trust boundaries: when defensive checks are appropriate

Defensive checks are generally appropriate at untrusted boundaries, such as:

  • request/CLI/env input handling
  • parsing and decoding (JSON, CSV, protobuf, HTML, etc.)
  • network/RPC boundaries
  • filesystem reads/writes of external data
  • third-party callbacks and plugin systems

Defensive checks are often slop within trusted internal pipelines, such as:

  • post-validated domain objects
  • post-auth/permission middleware
  • post-schema validation
  • internal-only transforms with strong invariants

When in doubt, follow existing patterns in the same module/subsystem.

Workflow checklist

  1. Identify the diff source (cached, working tree, or main..HEAD).
  2. For each changed hunk:
    • Determine the intended behavior change.
    • Remove additions that are not required to achieve it.
    • Align with local style (naming, typing, error strategy, comment density).
  3. Remove unused imports, dead code, and redundant helper layers introduced by the branch.
  4. Keep changes minimal: avoid unrelated refactors.
  5. Ensure changes still satisfy AGENTS.md (and other repo policies).
  6. If repository tooling exists (formatters/linters/tests), avoid introducing new warnings.

Final report requirement

At the end, output only a 1–3 sentence summary describing what you changed. No bullet points. No emojis. No extended explanation.

Example acceptable summary:

Removed redundant input checks and log-and-rethrow blocks added in this branch, and inlined single-use helpers to match existing style. No functional behavior changes beyond the intended diff; all edits were confined to the branch’s modified hunks.

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.

Reviews can't be read right now.

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.