# 28 Anti AI Slop

> Use when producing any SRS, requirement, design, test, ADR, document, or code artefact; apply continuously and at the pre-ship gate to prevent generic, unverified, template-shaped output. Use 29-ai-slop-audit for independent detection and grading.

- Skill: `peterbamuhigire/28-anti-ai-slop` (Agent Skill)
- Install (CLI): `npx skillmds@latest add peterbamuhigire/28-anti-ai-slop`
- Raw SKILL.md: https://api.skillmd.com/api/skills/peterbamuhigire/28-anti-ai-slop/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: peterbamuhigire (https://skillmd.com/u/peterbamuhigire)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/peterbamuhigire/28-anti-ai-slop

---


# Anti AI Slop
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.

<!-- dual-compat-start -->

## Use When

- Use when producing any SRS, requirement, design, test, ADR, document, or code artefact; apply continuously and at the pre-ship gate to prevent generic, unverified, template-shaped output. Use 29-ai-slop-audit for independent detection and grading.

## Do Not Use When

- Do not use when a neighbouring skill owns the requested artefact or the task lacks a concrete source to ground it.
- Do not use this skill to fabricate missing project facts, legal conclusions, test results, approvals, or certification claims.

## Required Inputs

| Artefact | Source or provider | Required? | Missing-input behaviour |
|---|---|---:|---|
| Target sources: The concrete target artefact, intended audience, applicable baseline, and project evidence. | Project owner, approved workspace artefacts, or accountable control owner | Yes | Stop dependent claims; list the missing item, owner, and consequence. For review checks, record `not assessed`. |
| Scope, audience, baseline/version, and accountable decision owner | Requester or project context | Yes | Ask for or record the gap; do not infer authority or scope. |

## Capability and permission boundaries

Default to read-only. Read and search access to the supplied artefacts are required. Editing is limited to an explicitly authorised requested draft or project files. Execute validation only when authorised; publishing, signature, certification, production mutation, destructive action, spending, and risk acceptance require explicit authority.

## Degraded Mode

When files, tools, network, rendering, fonts, execution, or evidence are unavailable, return the narrowest useful qualified draft or finding set. Name every unavailable check and its consequence; an unassessed check is never a pass. Preserve evidence already gathered and provide the exact next verification step.

## Decision Rules

| Condition | Action | Failure or risk avoided |
|---|---|---|
| A claim, metric, citation, API, or package is unverified | Verify, qualify, or remove it before release | Confident wrongness |
| A section has no project-specific evidence or decision | Rewrite or cut it | Superficial template content |

## Workflow

1. Confirm the requested artefact, audience, scope, decision owner, and applicable baseline or version. Work read-only by default; source mutation, publication, signature, certification, production change, or risk acceptance requires explicit authority.
2. Select one requirement, section, flow, or evidence unit and inspect every required input before changing it. Record missing, stale, conflicting, or inaccessible evidence; stop claims that depend on an unresolved required input.
3. Apply the Decision Rules, then execute the existing Core Instructions below in order; preserve project terminology, trace each material statement to its source, and make one concrete refinement before selecting the next unit.
4. Test the draft against the output acceptance conditions and domain quality standards. If a check cannot run, mark it `not assessed` and never convert it into a pass.
5. On failure, recover by preserving completed evidence, identifying the narrowest corrective action and owner, and rerunning only the affected checks before handoff.
6. Produce the named artefact and evidence record; publish, sign, certify, mutate production, or accept risk only under explicit authority.

## Outputs

| Artefact | Consumer | Observable acceptance condition |
|---|---|---|
| Guarded production artefact and ship-gate record | Accountable reviewer, control owner, auditor, or release authority | Every material claim is traceable, reviewable, and bounded by the available evidence. |
| Gap and decision record | Accountable owner and downstream reviewer | Every gap has status, impact, owner, next action, and no unsupported pass or approval. |

## Evidence Produced

| Evidence | Contents | Acceptance condition |
|---|---|---|
| Guarded production artefact and ship-gate record evidence record | Source identifiers, scope/version, decisions, checks, exceptions, and approval state | A reviewer can reproduce each material conclusion from named sources. |
| Validation record | Check, result (`pass`, `fail`, or `not assessed`), evidence location, date, and actor | No required check is omitted or silently treated as passed. |

## Quality Standards

- Every material claim is traceable, reviewable, and bounded by the available evidence.
- Use deterministic acceptance conditions and preserve traceability from source to decision and output.
- Separate facts, inferences, assumptions, and approvals; never present one as another.
- Apply `28-anti-ai-slop` during authoring and `29-ai-slop-audit` at major checkpoints and release.

## Anti-Patterns

- **Producing Guarded production artefact and ship-gate record from assumptions instead of named project sources.** Fix: Cite the source or mark the item unverified.
- **Treating a missing or inaccessible check as passed.** Fix: Mark it `not assessed`, state impact, and block dependent claims.
- **Using vague gates such as `adequate`, `secure`, or `user-friendly`.** Fix: Replace each with an observable criterion, threshold, and evidence source.
- **Copying a generic template without product, control, role, version, or jurisdiction detail.** Fix: Ground every section in the supplied context and remove unused boilerplate.
- **Publishing, signing, certifying, changing production, or accepting risk without authority.** Fix: Prepare a draft and route the decision to the accountable owner.
- **Listing evidence without provenance or an acceptance result.** Fix: Record source, period, integrity check, mapping, and pass/fail/not-assessed status.

## Worked Example

Example: if a claim, metric, citation, API, or package is unverified, verify, qualify, or remove it before release. Record the evidence and result in the validation record; this avoids confident wrongness.

## References

- [Repository operating rules](../../AGENTS.md): apply the engine's routing, evidence, and release gates.
- [Independent AI slop audit](../29-ai-slop-audit/SKILL.md): run after major iterations and before release.
- [Human English and reader-centred craft](../../book-extractions/human-english-craft-synthesis-2026.md): language, register, grammar, microcopy, and read-aloud overlay.

<!-- dual-compat-end -->

## Machine-error editorial gate (cross-engine Kaizen)

Apply Digital Research's `docs/continuous-improvement/machine-errors-editorial-gate-2026-09-03.md`
while authoring. Review every requirement clause, rationale, table, and paragraph for:

| ID | SRS-specific test |
|---|---|
| ME1 | Does this restate a nearby requirement, rationale, or constraint without a new trace, state, or oracle? |
| ME2 | Is parallel requirement structure expressing a real comparison, or only making the specification look balanced? |
| ME3 | Can an implementer or reviewer act from the existing wording without another restatement? |
| ME4 | Does the quality claim exceed its metric, threshold, or evidence? |
| ME5 | Is the example grounded in `_context/`, or would it fit any product? |
| ME6 | Has the same rhetorical construction become a repeated template tic? |
| ME7 | Does the paragraph add a requirement, constraint, test oracle, decision, or trace? |

Merge or cut units with no delta. Preserve repetition required for deterministic testability,
traceability, accessibility, safety, or exact API/schema identifiers, and record that exception.

### Impeccable-derived AS overlay

When an SRS includes a website, UI specification, presentation, rendered document, or design
system, apply AS1-AS7 from the shared gate. For ordinary requirements prose, use AS1, AS3, AS5,
and AS6; mark visual checks `not_applicable` when no visual artifact is in scope.

| ID | SRS-specific overlay test |
|---|---|
| AS1 | Is the template, terminology, UI pattern, or copy default justified by this product and reader? |
| AS2 | Do labels, badges, metrics, or section numbers add a requirement or merely imply importance? |
| AS3 | Do repeated requirements, cards, or sections represent distinct actors/states, or is the structure cloned? |
| AS4 | Does proposed animation, glow, gradient, or transition serve a state, task, or accessibility need? |
| AS5 | Is each example, icon, asset, endpoint, or screen traceable to product context rather than placeholder material? |
| AS6 | Are buzzwords, em-dash cadence, aphoristic contrasts, or theatrical framing hiding an untestable requirement? |
| AS7 | Does the rendered requirement remain readable, complete, accessible, and structurally valid? |

For visual SRS deliverables, purple gradients, glassmorphism, neon glow, AI-beige defaults,
decorative editorial scaffolding, and decorative motion are no-ship choices. Preserve repeated
identifiers, acceptance criteria, error states, trace links, and safety wording when they carry
implementation or verification function; record the exception.

The guardrail every generated artefact passes before it ships. Detection lives in the companion `29-ai-slop-audit` skill; this skill governs **production** — writing the SRS, spec, design doc, test doc, or code so slop never appears in the first place. It sits on top of this engine's V&V SOP and IEEE/ISO grounding, never below them: a requirement that is verifiable but generic still fails here.

## Real-time application (this is a LIVE constraint, not only a final gate)

Apply these rules **continuously, as you author** — to every requirement, section, acceptance criterion, design statement, and line of code at the moment it is written, not only in one pass at the end. The moment you reach for a banned word, a subjective adjective with no IEEE-982.1 metric, a generic placeholder, an unverified figure, a hallucinated API, or a template default, stop and correct it in place. The ship-gate checklist at the end is the final confirmation, not the first time these rules are consulted. If you are mid-draft and notice slop accumulating — an empty "Challenges and Future Prospects" heading, a "shall be reliable" with no threshold, a requirement with no test oracle — fix it then; do not defer to a cleanup pass.

## Use When

- Before delivering any generated SRS section, PRD, user story, acceptance criterion, HLD/LLD, API spec, database design, test strategy/plan/case, runbook, ADR, or shipped code.
- As the last gate after the Phase 09 audit and before the consultant sees the draft (PRIME "Inspect" step).
- Whenever you suspect a section reads as filler, hedged, or template-shaped rather than authored against real `_context/`.

## Do Not Use When

- You are still gathering `_context/` inputs; this skill checks finished drafts, not raw notes.
- The artefact is a private scratch file that will never reach a person or downstream skill.

## What "AI slop" is (so you know what you are preventing)

**AI slop** is low-quality content produced in quantity by generative AI and pushed at people who did not ask for it (Merriam-Webster 2025 Word of the Year, verified). Its three diagnostic properties (Kommers et al., *"Why Slop Matters"*, arXiv 2601.06060, verified):

1. **Superficial competence** — looks fine on the surface, no substance underneath.
2. **Asymmetric effort** — cheap to produce, costly for a human to read, review, or fix.
3. **Mass producibility** — generated at volume.

The human tell named in every domain studied: **absence of intent** — the sense that no one *meant* anything by it. In an SRS this shows up as requirements no engineer could build a test against. Your job is to re-internalise effort (specificity, verification, authored decisions) before the artefact reaches a person.

Two verified data points anchor why this matters for spec-driven code. Spracklen et al. (USENIX Security 2025) measured a 19.7% package-hallucination rate in AI-generated code — invented dependencies that a spec citing a non-existent API will propagate downstream. GitClear found code-duplication share rising from 8.3% (2020) to 12.3% (2024), the kind of copy-paste bulk that asymmetric-effort slop produces.

## The seven universal guardrails (apply to EVERY output)

| # | Marker to prevent | Avoidance rule you MUST follow |
|---|---|---|
| **U1** | Genericness / averaging | Every section carries ≥1 concrete, named, domain-specific element (a real `_context/` entity, a measured threshold, a named actor, a stimulus-response pair) a generic template could not produce. Forbid tool defaults and stock requirement boilerplate. |
| **U2** | Superficial competence | Enforce a substance floor: include a requirement, constraint, test oracle, or decision the artefact could not exist without. A "Challenges and Future Prospects" section with no named challenge is filler — cut or replace it. |
| **U3** | Confident wrongness / hallucination | Verify every statistic, citation, standard clause, named entity, API, schema field, and dependency before emit. Cite at the point of claim. Flag uncertainty with `[CONTEXT-GAP]` rather than inventing. Never specify an API or library that does not exist. |
| **U4** | Volume over substance | Prefer one verifiable requirement over three hollow ones. Do not pad to reach a section length. Honour the Minimum-Length Directive. |
| **U5** | Absence of authored voice / intent | State the engineering rationale, trade-off, or named decision behind a requirement. Ban relentless positivity and sycophancy. Record real trade-offs in an ADR rather than smoothing them over. |
| **U6** | Skipping the hard parts | Specify the error, edge, empty, and failure cases, the counter-arguments, and the design constraints — not just the happy-path requirement. Every edge case in `_context/` must trace to a requirement. |
| **U7** | Mechanical uniformity | Vary sentence length and structure. Break the template. No rule-of-three reflex, no "it's not X, it's Y" formula, no em-dash flood. |

## Banned / high-risk vocabulary (the lexical tells)

These words and constructions are statistically over-produced by LLMs (FSU/COLING-2025; PubMed "delve" +400%). **Do not use them as default register.** A word here is allowed only when it is the genuinely precise term, never as filler.

This list merges with this engine's standing prohibition (CLAUDE.md Principle 7): never use **fast, intuitive, reliable, robust, seamless,** or any subjective adjective without its defined IEEE-982.1 metric. Replace with a measurable threshold: "response time ≤ 500 ms at P95 under normal load."

- **Words:** delve, tapestry, realm, landscape (as metaphor), navigate (as metaphor), leverage, foster, harness, synergy, embark, robust, vibrant, holistic, seamless, intricate, commendable, meticulous, pivotal, underscore, testament, resonate, elevate, paramount, unwavering, multifaceted.
- **Engine-specific banned adjectives (no metric = no use):** fast, intuitive, reliable, scalable, performant, user-friendly, cutting-edge, state-of-the-art, enterprise-grade — each is a `[SMART-FAIL]` unless paired with a specific IEEE-982.1 / ISO 25010 metric.
- **Phrases:** "in today's fast-paced world", "in the ever-evolving landscape of", "it is important to note that", "it's worth mentioning", "let's dive in", "here's the kicker", "at the end of the day", "in conclusion", "studies show" (without a named study), "Challenges and Future Prospects" (as an empty placeholder heading).
- **Constructions:** the "it's not just X, it's Y" antithesis; reflexive rule-of-three lists; em-dash used to manufacture drama; relentless triplet adjectives ("robust, scalable, and reliable").
- **French equivalents** (for Francophone output): "plongeons dans", "il est important de noter que", "force est de constater", "dans un monde en constante évolution", "par ailleurs/de plus/en outre" as filler connectors, "au cœur de", "pierre angulaire".

## Drop-in guardrail block (inherit in dependent skills)

```
ANTI-SLOP GUARDRAIL (inherit in every output):
1. SPECIFICITY FLOOR — every section carries >=1 concrete, named, domain-specific
   element from _context/. No tool defaults, no placeholder requirement copy.
2. VERIFY-BEFORE-EMIT — no statistic, citation, standard clause, named entity,
   API, schema field, or dependency ships unverified; cite at point of claim;
   flag uncertainty with [CONTEXT-GAP].
3. AUTHORED VOICE — state the engineering rationale / trade-off; no relentless
   positivity, no sycophancy; route real trade-offs into an ADR.
4. COVER THE HARD PARTS — error/edge/empty/failure cases, counter-arguments,
   design constraints; every edge case traces to a requirement.
5. BREAK THE TEMPLATE — vary rhythm and structure; forbid default aesthetics,
   the banned-vocabulary list, and undefined subjective adjectives.
```

## Domain-specific avoidance (load the relevant block for the output type)

- **SRS / technical spec (primary):** no vague requirement ("the system shall be fast/intuitive/reliable") — every quality attribute carries an IEEE-982.1 / ISO 25010 metric and threshold; no empty "Challenges and Future Prospects" or "Future Enhancements" placeholder section; every functional requirement uses a stimulus-response pattern with a deterministic test oracle; every edge, error, and empty case in `_context/` has a matching requirement; no hallucinated API, endpoint, schema field, or library — resolve each against a real source; every requirement traces back to a business goal and forward to a test case.
- **User stories / acceptance criteria:** real named persona from `_context/stakeholders.md`, not "as a user"; Given-When-Then with concrete data values, not abstractions; INVEST-checked; negative and boundary criteria present, not only the happy path.
- **Design docs (HLD/LLD/API/DB):** named components and real data flows over generic boxes; documented trade-off per significant decision (link the ADR); failure modes, timeouts, and back-pressure specified; API examples use real field names and types; no invented standard clause.
- **Test docs:** each test case has a deterministic pass/fail oracle, not "verify it works"; coverage maps to specific requirement IDs; negative, boundary, and error-path cases included.
- **Written content:** no focal-word clusters; vary sentence length (mix 3–10 with 25–40 words); ≤1 em-dash/paragraph; no "in conclusion"; specific examples over generic claims; a stated point of view.
- **UI/UX:** no indigo-500/purple-gradient default; no Inter-only typography; intentional (not uniform) radius/shadow; WCAG contrast ≥4.5:1; design ALL states (error/empty/loading/focus/disabled); real testimonials only.
- **Apps/product:** add genuine value over any wrapped API; transparent pricing + in-app cancel; no deceptive AI-capability claims; least-privilege permissions.
- **Code (specs drive code):** verify every imported package exists (slopsquatting — Spracklen et al. measured 19.7% hallucinated packages); no placeholder stubs/TODOs/`NotImplementedError`/`...` in shipped code; parameterised queries (never string-built SQL); no `innerHTML = userInput` (XSS); no hardcoded secrets; idiomatic and deduplicated (GitClear duplication 8.3%→12.3%); real tests, never `assert true`; cover the edge cases the spec named. Veracode found 45% of AI-generated code samples introduced an OWASP-relevant flaw (XSS present in 86%, log-injection in 88%) — verify, do not trust.
- **Image/video:** real specimens only; check anatomy/text/physics; avoid the "AI sheen"; attach provenance (C2PA) where it matters.

## Ship gate (run before delivering ANY output)

- [ ] Every section has ≥1 concrete, named, specific element from `_context/` (U1/U2).
- [ ] Every stat, quote, citation, standard clause, named entity, API, schema field, dependency verified (U3).
- [ ] No banned vocabulary used as filler; no subjective adjective without its IEEE-982.1 metric; scanned the output for both lists above.
- [ ] The output states an engineering rationale / trade-off; no sycophancy (U5).
- [ ] Error/edge/empty/failure cases and counter-arguments addressed; every `_context/` edge case traces to a requirement (U6).
- [ ] Sentence length and structure varied; no rule-of-three reflex, no antithesis formula, no em-dash flood (U7).
- [ ] Every functional requirement is stimulus-response with a deterministic test oracle; no empty "Challenges and Future Prospects" section.
- [ ] Output type's domain block applied.
- [ ] When in doubt, run the `29-ai-slop-audit` skill on the draft.

If any box is unticked, the output is not ready to ship.

## Anti-Patterns

- Treating the banned-vocabulary scan as cosmetic while leaving requirements untestable underneath — slop is a substance failure first, a lexical one second.
- Padding an SRS to a target length with restated obvious statements, violating the Minimum-Length Directive.
- Inventing an API, endpoint, or library to fill a `[CONTEXT-GAP]` instead of flagging it.

## Outputs

- A ship/no-ship decision plus the ticked gate checklist appended to the draft's review notes.
- Any unresolved item promoted to the matching V&V fail tag (`[V&V-FAIL]`, `[SMART-FAIL]`, `[CONTEXT-GAP]`, `[TRACE-GAP]`).

## See also

- `29-ai-slop-audit` — the detection/evaluation/audit companion (analyse any artefact for slop and score it).
- `02-audit-report` and the V&V SOP in `CLAUDE.md` — apply on top of this; IEEE/ISO grounding precedes style.