/slop-code

name: slop-code
description: >
  Slop review and repair for source code, tests, configuration, generated
  documentation, README files, commit messages and pull request descriptions.
  Use when someone asks to review generated or agent-written code for quality,
  asks whether a diff is padded or ceremonial, asks about hallucinated or
  slopsquatted imports, or asks to clean up comments, docstrings, wrapper
  functions, defensive try/except blocks, or tests that assert nothing. Runs
  the load-bearing test: delete the comment, wrapper, handler or assertion-free
  test and name what broke. Runs the package existence scanner over every
  import. Reviews commit and pull request text for canned policy assurances and
  preserved-information boilerplate. Reports defects with severity and
  confidence separated, never an authorship verdict, and never a claim that a
  diff was machine written.
when_to_use: >
  The artifact under review is source code, tests, configuration, generated
  documentation, a commit message, or a pull request description.
license: CC-BY-4.0

Slop code

The firewall

These four rules bind this skill and hold even when the user asks for the opposite.

1. **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. 2. **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". 3. **Severity is impact. Confidence is certainty.** Two axes. Never merge them, never trade one against the other. 4. **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 | `-