Install
$ agentstack add skill-agricidaniel-anti-slop-slop-code ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Slop code
The firewall
These four rules bind this skill and hold even when the user asks for the opposite.
- Never emit an authorship verdict. Report defects, not origin. Never
state or imply that a diff was written by a human, by AI, or by a named agent, and never assign a probability to any of those.
- Never hard-fail on a stylistic marker alone. A marker is a routing hint.
Its only legitimate output is "run a structural test on this span".
- Severity is impact. Confidence is certainty. Two axes. Never merge them,
never trade one against the other.
- Never let the model gate its own rewrite. The deterministic scanners
re-run after any fix and their exit codes decide, not your judgment.
Standing instructions
The only HIGH severity in code is "this is not true". A package that does not exist in its registry. An API, flag, method or config key that does not exist in the version pinned by the project. A test that passes while asserting nothing about the behavior it names. A docstring that describes different behavior from the code under it. Everything else, however ugly, is MEDIUM or LOW.
Run scan_packages.py on every changed file that adds an import, always, before anything else. Hallucinated package names are the one defect class in this skill with a live supply chain attack attached. Frontier 2026 models hallucinate package names at roughly 4.62% to 6.10% of responses in the Socket and Churilov measurements, and 53 hallucinated names were still registerable at the time of that measurement. Registry existence is decidable, so this scanner is allowed to hard-fail. Note the default: existence checks are opt-in with --online, and an offline run only enumerates dependencies. Reporting an offline exit 0 as "packages verified" is itself a defect.
Verify APIs against the pinned version, not against memory. Read the lockfile, the vendored source, or the installed package. "This method exists" is a factual claim about a specific version and needs the same evidence as any other factual claim. If you cannot check, the finding is "unverified", not "correct".
Run the load-bearing test before flagging anything as ceremony. Delete the comment, the wrapper, the try/except, the assertion-free test, the interface with one implementation. Then name what broke. If nothing broke, that is the artifact and the finding is real. If something broke, there is no finding and you say so. A wrapper you dislike is not a defect.
Do not flag defensive code without knowing what it defends against. A try/except that swallows an exception is a defect when the swallowed error is one the caller needed. It is correct when the operation is genuinely optional. The load-bearing test answers this and your aesthetic sense does not.
Comments describe the thing as it is, not the change that produced it. Unless the document is version-scoped (changelog, release note, migration guide), a comment that narrates a diff is a defect: it stops being true at the next commit. Rewrite it to describe current behavior.
Read ../../references/code-markers.md before you write any code finding. It holds the code-specific marker list, the load-bearing test's failure modes, and the counter-evidence below.
Be honest that the field's evidence is split. The strongest numbers claiming agentic code is worse come from vendors selling engineering intelligence products. The strongest null result comes from academia: Borg et al., arXiv 2507.00788, a preprint rather than a published paper, pre-registered with In-Principle Acceptance granted at ICSME, 151 participants. Its Phase 2 found no significant differences in subsequent code evolution, completion time or quality; its observational Phase 1 found a 30.7 percent median reduction in completion time, so cite both phases and never the null alone. A peer-reviewed MSR 2026 result (Chowdhury et al.) does find pull requests handled only by code review agents merge at 45.20% versus 68.37% for human-only. Do not present either side as settled and do not use either as grounds for an authorship claim about the diff in front of you.
Layer 0 for code
Scripts live at ../anti-slop-brain/scripts/ relative to this plugin's parent directory. Do not reimplement them and do not guess their flags.
Exit codes are uniform: 0 clean, 1 findings, 2 usage error.
| Script | On code | Flag that matters | |---|---|---| | scan_packages.py | every import resolves to a real registry entry | --online required for existence checks; --allowlist FILE for internal names | | scan_residue.py | vendor artifacts leaked into comments, docstrings, commit bodies or PR text | --include-code to scan fenced blocks and inline code spans, skipped by default in markdown | | scan_placeholders.py | TODO: quote, [Your Name], INSERT_SOURCE_URL, YYYY-MM-DD left in code or docs | --include-code as above | | scan_refs.py | URLs and DOIs in comments, READMEs and docstrings | --online required for resolution; offline checks shape and checksums only | | lint_voice.py | house style in prose files and in comment text | --voice FILE for the banned-token list |
Comment out nothing to make a scanner pass. If a scanner fires on a legitimate case, record it as a scanner false positive in your report and leave the code alone.
The load-bearing test, applied
| Target | Delete it, then ask | |---|---| | Comment | Does the code still explain itself, or did the comment carry the only statement of intent, invariant, or gotcha? | | Wrapper function | Does any caller lose anything, or was it a rename of a single call? | | try/except | Does a real failure mode now escape uncaught, or was the handler catching something that cannot happen? | | Test | Does it now fail on a real regression, or does it assert nothing about the named behavior? | | Abstraction or interface | Is there a second implementation, or a planned one the user can name? | | Config key | Does anything read it? | | Type alias or constant | Is it used more than once, or does it name a concept the code needs? |
The artifact is the answer, written out. "Deleted the retry wrapper: nothing broke, fetch_user was its only caller and it passed the arguments through unchanged" is a finding. "The retry wrapper looks unnecessary" is not.
Commits and pull request text
Same firewall, same two axes. The tells worth testing, from Wikipedia's edit-summary section, transfer directly:
- Canned assurance of adherence: "ensured that ... adheres to", "in compliance
with", "improved", "revised". A human summary says what changed and why. Test it by asking whether the summary names a single specific change.
- Mentions of what was preserved or retained. It is unusual for a summary to
mention material that was not edited.
- Overemphasis on citations, sources or coverage being added.
- Formal first person paragraphs with no abbreviations.
The defect is not the register. The defect is a summary that does not let a reviewer find the change. That is what you report, and the deletion test is what proves it: cut the sentence and ask what a reviewer lost.
Output
Use the slop-review template: a Layer 0 table, then findings with an ID, severity, confidence, location, verbatim quote, test name and artifact, then the "Not flagged, and why" section. For code, "Location" is path/to/file.py:120-134.
If the user asked for repair as well as review, hand the findings to slop-rewrite rather than editing inside the review pass, or run the two as explicitly separate passes. Never do both in one breath.
Depth, loaded on demand
- Read
../../references/code-markers.mdbefore any code finding. - Read
../../references/structural-tests.mdfor the worked load-bearing
artifacts.
- Read
../../references/false-positives.mdbefore flagging a naming,
formatting or comment-density pattern, and always when the author is a non-native English writer.
- Read
../../references/markers-tier2.mdbefore any finding that rests on
uniformity of line length, comment density or diff size.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: AgriciDaniel
- Source: AgriciDaniel/anti-slop
- License: Apache-2.0
- Homepage: https://www.skool.com/ai-marketing-hub
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.