- Home
- Skills
- Adibfirman
- Dotfiles
- Deslop Simply Ai Code
deslop-simply-ai-code_skill
- Shell
2
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill adibfirman/dotfiles --skill deslop-simply-ai-code- SKILL.md4.8 KB
Overview
This skill removes AI-generated "slop" from code diffs and pull requests to improve clarity, consistency, and maintainability while preserving exact behavior. It focuses on eliminating redundant patterns, over-verbosity, and needless abstractions so changes match the existing codebase style. Use it as part of code review to make LLM-produced edits review-ready.
How this skill works
The skill scans changed lines (git diff against main or a provided diff) and detects common LLM noise: redundant guards, verbose logging, single-use helpers, and explanatory comments that restate code. For each finding it proposes a minimal refactor or removal that preserves behavior and aligns with project idioms, and it verifies the change does not alter functionality. It highlights exceptions where defensive checks, linter-required comments, or justified abstractions must stay.
When to use it
- Reviewing PRs with AI-generated changes or suggested patches
- Cleaning up branch diffs before merging to main
- Running a focused pass after an LLM refactor to remove verbosity
- Checking a codebase for redundant checks and single-use wrappers
- Preparing commits for maintainability and code review readiness
Best practices
- Start by matching the existing code style and naming conventions in the repo
- Use git diff main...HEAD or provide a focused diff to limit scope
- Prefer removing or collapsing noise over replacing with clever abstractions
- Always run tests or basic verification after each simplification to preserve behavior
- Keep defensive checks at external boundaries and maintain required linter/documentation comments
Example use cases
- Remove repetitive == true/== false comparisons and simplify conditionals
- Replace single-use helper functions with inline code or direct calls
- Remove debug prints and verbose entry/exit logs introduced by LLMs
- Collapse redundant null/empty checks that the type system or prior validation already guarantees
- Shorten over-descriptive identifiers and rename to match project naming style
FAQ
No. The rule is preserve behavior: simplifications only restructure or remove redundant code. Every change should be validated by tests or manual verification before merge.
What patterns are never removed?
Defensive checks at API boundaries, linter-required comments, essential logs for auditing, and abstractions justified for testing or future extension are preserved.
How do you ensure changes match the codebase?
The process begins by inspecting existing files for style, idioms, and naming. Proposals follow those conventions and aim to make new code look like it belongs to the project.