anti-slop
Anti-Slop
Audits source code for AI-generated slop patterns and outputs a structured report.
Workflow
Step 1 — Resolve files
Parse the argument as file paths or glob patterns. Expand globs to a concrete file list.
# If argument is a glob like "src/**/*.ts", expand it
# If argument is a file path, use it directly
# If multiple paths/globs, expand all
Supported extensions: .ts, .tsx, .js, .jsx, .py, .go, .rs, .java, .rb, .php, .swift, .kt
Skip files larger than 1000 lines — flag them as "skipped (too large)" in the report. For those, audit only the first 500 lines.
If no argument is provided, prompt the user:
"Which files should I audit? Pass file paths or glob patterns (e.g.
src/**/*.ts)."
Step 2 — Read the pattern catalog
Read references/slop-code-patterns.md for the full detection rules and severity guide.
Step 3 — Audit each file
For each file:
-
Read the file contents
-
Scan for patterns across all 7 categories:
- Cat 1: Unnecessary comments — restating code, obvious JSDoc, vague TODOs, section dividers, "removed" markers
- Cat 2: Over-engineering — premature abstractions, unnecessary factories, config for hardcoded values, forwarding wrappers, one-off interfaces
- Cat 3: Defensive over-coding — null checks on non-nullable types, try-catch on infallible ops, redundant else-after-return, verbose error messages, fallbacks hiding bugs
- Cat 4: AI voice — "enhanced/optimized/improved" naming, "ensure/robust/graceful" comments, control-flow narration, apologetic comments
- Cat 5: Dead code — unused imports, assigned-but-unread variables, unreachable code, backwards-compat re-exports
- Cat 6: Type workarounds —
as any, unexplained@ts-ignore, unnecessary assertions - Cat 7: Verbose patterns — ternary replaceable by
??, boolean verbosity, unnecessary async/await, pointless spread
-
For each issue found, record:
- Line number(s)
- Category (1-7)
- Pattern (e.g., "1a: restating code")
- Severity (high / medium / low)
- The offending code (1-3 lines)
- Suggested fix (brief — what to do, not the full rewrite)
Step 4 — Cross-file checks
After individual file audits, check for cross-file patterns:
- Functions called from only one file — may be premature abstractions (Cat 2a)
- Exported symbols not imported elsewhere — may be dead code (Cat 5d)
- Duplicated utility functions across files — AI often creates the same helper in multiple places
Only run these if auditing 3+ files. Use grep to search for function/export usage across the codebase.
Step 5 — Output the report
Format the report as follows:
## Anti-Slop Audit Report
**Files audited:** N
**Issues found:** N (H high, M medium, L low)
---
### `path/to/file.ts`
| Line | Severity | Category | Pattern | Issue |
|------|----------|----------|---------|-------|
| 12 | medium | Unnecessary comment | 1a: restating code | `// set the name` above `this.name = name` |
| 45-52 | medium | Over-engineering | 2a: premature abstraction | `formatDate()` called once, body is one line |
| 89 | high | Type workaround | 6a: `as any` | `response.data as any` — fix the response type |
**Suggested fixes:**
- L12: Delete the comment
- L45-52: Inline `formatDate()` at L78
- L89: Type `response.data` as `ApiResponse` based on the fetch call at L85
---
### `path/to/other-file.ts`
...
---
### Cross-File Issues
- `formatSlug()` defined in `utils.ts:34` is only imported by `page.ts:2` — consider inlining
- `UserDTO` exported from `types.ts:12` is not imported anywhere
---
### Summary by Category
| Category | Count |
|----------|-------|
| 1. Unnecessary comments | N |
| 2. Over-engineering | N |
| 3. Defensive over-coding | N |
| 4. AI voice | N |
| 5. Dead code | N |
| 6. Type workarounds | N |
| 7. Verbose patterns | N |
If zero issues are found, output:
## Anti-Slop Audit Report
**Files audited:** N
**Issues found:** 0
Clean. No slop detected.
More from b4r7x/agent-skills
react-design-patterns
Use when choosing a React component pattern — custom hooks, control props, compound components, headless components, render props, container/presentational, or other architectural patterns. Includes 13 patterns with decision guide and 2025 popularity ranking.
26human-commit
Generates human-like git commit messages based on staged or unstaged changes. Reads git diff, analyzes what changed, and outputs 3 natural commit message options that sound like they were written by a developer — not AI. This skill should be used when the user wants a commit message, asks "what should I write for commit", "generate commit message", "human like commit", "wiadomość do commita", or just asks for help committing.
24humanize-readme
Rewrites a README.md to remove AI slop — buzzwords, generic openers, fake enthusiasm, and formulaic structure — replacing it with direct, honest, human-sounding writing. This skill should be used when the user wants to humanize a README, remove AI-generated writing patterns, make documentation sound less like ChatGPT wrote it, or asks to "fix the README", "humanize readme", "remove AI slop", "make it sound human".
24improve-prompt
Transforms a rough, unpolished prompt idea into a precise, structured AI coding prompt. Automatically researches the current project context (stack, file structure, conventions, git history) before generating. This skill should be used when the user provides a vague or "dirty" prompt idea and asks to refine, improve, or rewrite it — e.g. "improve this prompt", "refine my prompt", "ulepszony prompt", "dopracuj prompt", or simply describes what they want done in rough terms.
23react-anti-patterns
Use when reviewing React code — especially AI-generated code — to catch common anti-patterns. Covers 18 anti-patterns with detection difficulty, including stale closures, state mutation, useEffect abuse, and boolean explosion.
21deep-plan
Takes a rough, unpolished prompt idea and autonomously turns it into an implementation plan. Researches the project deeply, asks clarifying questions, generates a precise internal prompt, then executes it to produce a structured plan with todos. Designed for plan mode. Use when the user gives a vague feature request, rough idea, or "dirty" prompt and wants a ready-to-execute implementation plan — e.g. "plan this", "deep plan", "turn this into a plan", "zaplanuj to", "zrób plan".
19