stop-slop-code
Skill2 starsChanged 6 days agoApache-2.0View on GitHub
Review a local diff or working tree for structural defects that mark incomplete or lazily generated code: dead abstractions, copy-paste divergence, unused parameters, swallowed errors, tests that assert nothing. Use before pushing, when the user says "find bugs in these changes", "review before I push", or "clean up this code", and as the pre-PR quality gate on a change your own agents wrote. Operates on the local diff, not a PR URL. Do NOT use to review a published pull request (see parallax-review).
- Reads credentials
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adopt-evalSkill
- contract-validationSkill
- create-prSkill
- designSkill
- graphifySkill
- helm-upgradeSkill
- ingest-readingSkill
- investigate-alertSkill
- k8s-debugSkill
- parallax-reviewSkill
- shiny-engineerSkill
- stakeholder-commsSkill
- systematic-debuggingSkill
- upstream-triageSkill
- verify-claimsSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
Before creating a PR (as part of review)
- Distinctive: line 20
When reviewing code produced by any sub-agent
- Distinctive: line 21
When auditing code quality of generated changes
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Skill: Stop Slop (Code Mode)
Detects structural code problems that indicate incomplete, lazy, or AI-generated code. Run during code review or before PR creation.
When to use
- Before creating a PR (as part of review)
- When reviewing code produced by any sub-agent
- When auditing code quality of generated changes
Detection patterns
1. Placeholder detection (hard failure)
Any match is immediate fix required -- no scoring, no exceptions.
pass\s*(#.*)?$ # bare pass statements (Python)
TODO\b # TODO comments
FIXME\b # FIXME comments
raise NotImplementedError # Python stubs
\.\.\.\s*$ # ellipsis as function body
throw new Error\("not implemented"\) # JS/TS stubsAlso flag:
- Function body is empty
{} - Function body is a single
passor ellipsis - Class body is a single
passwith no docstring
2. God function detection (warning at 50 SLOC, failure at 100)
Count non-blank, non-comment, non-decorator lines inside the function body.
- > 50 SLOC: Warning -- consider decomposing
- > 100 SLOC: Hard failure -- must decompose before merge
3. Near-duplicate code blocks
Flag any two code blocks (3+ lines) with high similarity within the same file or across files in the same diff.
- > 80% token similarity: Warning -- extract shared utility
- > 95% similarity: Hard failure -- copy-paste detected, must refactor
4. Identity transforms
Comprehensions that return the loop variable unchanged:
# Flagged:
[x for x in items]
{k: v for k, v in d.items()}
# Not flagged (these transform):
[x.name for x in items]
[x for x in items if x.active]5. Unnecessary defensive comparisons
# Flagged -> Fix
if x == True: -> if x:
if x == False: -> if not x:
if x == None: -> if x is None:
if len(items) > 0: -> if items:
if bool(x): -> if x:6. Hardcoded values outside config
Flag URLs, ports, timeouts, and sleep values in production code:
https?://[^\s"']+ # URLs
:\d{4,5}[/"'\s] # port numbers
timeout\s*=\s*\d+ # hardcoded timeouts
sleep\(\s*\d+ # hardcoded sleep valuesExempt: files in **/config/**, **/.env*, **/test*/**, **/fixture*/**, **/mock*/**.
7. Missing test coverage for new functions
For any new function added in a diff, check that a corresponding test exists:
test_<function_name>in test files<function_name>.test.tsor<function_name>.spec.tsdescribe("<FunctionName>"block
Missing test for new public function = warning. Missing test file entirely = hard failure.
Scoring
Hard failures block delivery. Warnings accumulate:
- 0 warnings: Clean
- 1-3 warnings: Proceed with notice
- 4+ warnings: Block until addressed
Review output format
SLOP CHECK REPORT:
| Placeholders: PASS / FAIL (N found)
| God functions: PASS / WARN / FAIL (list with SLOC counts)
| Near-duplicates: PASS / WARN / FAIL (file pairs + similarity %)
| Identity transforms: PASS / FAIL (N found)
| Defensive comparisons: PASS / FAIL (N found)
| Hardcoded values: PASS / WARN (N found, list files)
| Missing tests: PASS / WARN / FAIL (new functions without tests)
| ---
| Hard failures: N
| Warnings: N
| Verdict: CLEAN / WARN / BLOCKEDIntegration
This skill is referenced during code review. When reviewing a diff:
- Scan changed files against all detection patterns above
- Produce the slop check report
- Include findings in review comments with specific file + line references
- Hard failures must be resolved before approval
This does NOT replace functional review -- it catches structural problems that functional review misses.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

