Philosophy

Philosophy

What slopless is for

Slopless exists because the volume of LLM-generated prose has outpaced human editing capacity. Documents, marketing copy, blog posts, and code comments now arrive shaped by patterns specific to language-model output: hedged openers, generic transitions, summative closers, demonstrative emphasis, formulaic contrast structures, semantically thin reveals. Human writers absorb these patterns too, because reading them every day makes them feel correct.

Slopless catches those patterns at the point of writing. It is not a style guide enforcer. It is a slop detector.

What slopless is not

• Not a grammar checker. Use a grammar tool for grammar.
• Not a readability scorer. Readability metrics are included only as supporting signals, not the main event.
• Not an LLM. Slopless never calls an LLM. The same input always produces the same output. This makes it usable in CI, in git hooks, and in editor integrations without rate limits, latency, or API costs.
• Not a style guide. Style guides are per-brand; slopless is per-pattern. The patterns it flags are bad in roughly every register, from internal docs to consumer marketing to literary fiction.

Design principles

• Deterministic. No probabilistic scoring. Every rule is a pattern or a metric with explicit thresholds. The decision to flag is reproducible across machines and across time.
• Narrow rules. Each rule targets one specific pattern. Bundled rules cannot be turned off independently; bundled rules are not slop-checked, they are vibes-checked.
• Owned by data. Dictionary-based rules keep their dictionaries in data/ where they can be reviewed, audited, and versioned independently of code.
• Honest about coverage. Known false positives live in fixtures, not in apologies in the README. If a rule fires on prose that is fine, that's a fixture file documenting the limit.
• Self-validating. Slopless lints its own documentation. If the rules fire on the README, the README changes - not the rules.

Why deterministic

Probabilistic slop detection (LLM-as-judge, embedding similarity, perplexity thresholds) all share the same failure mode: they cannot tell a human writer or a maintainer why a sentence was flagged. They produce scores, not findings. A deterministic rule produces a specific reason ("rule slopless/summative-closer fired on line 14 because the sentence matches the pattern 'that is what makes it work'"). That reason is auditable, testable, and arguable.

When a slopless rule is wrong, you can fix it. When an LLM judge is wrong, you can only retrain it.

Rule families

Rules are grouped into seven families. Each family targets a different layer of prose.

• Metrics. Quantitative measurements: average sentence length, Flesch reading ease, Gunning Fog index, paragraph length, word repetition. These flag stretches of prose that are statistically off.
• Orthography. Surface marks: em dash style, smart quotes, exclamation density, sentence-case headings, fake clock timestamps.
• Phrases and words. Dictionary-driven lookups for clichés, corporate-speak, jargon, LLM-disclaimer leakage ("as an AI language model"), wordiness, redundancy, uncomparables ("very unique").
• Syntactic patterns. Sentence-shape matches: empty emphasis ("this matters"), false questions, fragment stacking, lesson framing, summative closers, triple repetition, demonstrative emphasis.
• Semantic thinness. Low-information templates that gesture at depth without delivering ("something shifted in the room").
• Narrative slop. Stock generated-fiction gestures: body-action density, perception-verb density, narrative clichés.
• Academic slop. Known machine-paraphrased academic phrases ("counterfeit consciousness" instead of "fake intelligence").

The taxonomy is open. A rule should fit into a family or the family should be renamed.