antislop-code

Removes generic AI-style comments from code while preserving informative ones.

Updated Sep 17, 2026
One-click install
npx skills add https://github.com/bramanda48/skills --skill antislop-code-bramanda48
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: antislop-code
Source: https://github.com/bramanda48/skills/tree/main/skills/antislop-code
Command: npx skills add https://github.com/bramanda48/skills --skill antislop-code-bramanda48

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? AI coding agents tend to leave decorative, redundant, or overly long comments in code—banner separators, step-by-step narration, signature echoes, and vague TODOs—that add noise without information. This Skill defines rules to identify and remove those comments while protecting the ones that carry real value. ## Core Features & Use Cases - Slop Comment Detection: Identifies decorative separators, restated obvious lines, workflow narration, empty labels, vague TODOs, signature echoes, decorative emoji, and end markers. - Value Preservation Rules: Explicitly protects comments explaining business logic, security, performance trade-offs, workarounds, edge cases, and API contracts. - Scope Guardrail: Modifies comments only—never touches executable code, identifiers, formatting, or logic. - Use Case: After an AI agent generates a module full of // Step 1: Validate input and // ===== ROUTES ===== comments, run this Skill to strip the noise and keep only the one-line constraint notes that matter. ## Quick Start Review the comments in this file, remove any generic AI-style comments, and keep only the ones that explain non-obvious behavior without changing any code.

Frequently Asked Questions about antislop-code

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I remove AI-generated comments from code?

Apply the antislop-code rules to identify decorative separators, restated obvious lines, step-by-step narration, empty labels, and vague TODOs, then delete them. Keep comments that explain constraints, workarounds, or non-obvious behavior the code does not show.

What kinds of code comments should be kept during cleanup?

Keep comments explaining business logic, architectural decisions, security considerations, performance trade-offs, concurrency behavior, protocol details, API contracts, workarounds, edge cases, and licensing notices. A comment earns its place when it states something the code does not already show.

Does cleaning up comments risk changing the code behavior?

No. The Skill enforces a strict scope guardrail: only comments are modified. Executable code, identifiers, imports, formatting, indentation, whitespace, control flow, and logic are never touched.

When should a TODO comment be removed?

Remove a TODO when it names a feeling rather than a task, such as "TODO: improve this" or "add more validation." Keep it only when it describes a specific, actionable task with enough context to act on.

How long should a code comment be?

One line, or two only when the second line carries a new fact. Cut issue numbers, version history, and reasoning chains; keep only the constraint, platform trap, or silent failure the reader needs.