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.
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
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
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.
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.
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.
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.
On failure, recover by preserving completed evidence, identifying the narrowest corrective action and owner, and rerunning only the affected checks before handoff.
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.
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):
Superficial competence — looks fine on the surface, no substance underneath.
Asymmetric effort — cheap to produce, costly for a human to read, review, or fix.
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."
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.
1---2name: 28-anti-ai-slop3description: 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.4---56# Anti AI Slop7Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.89<!-- dual-compat-start -->1011## Use When1213- 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.1415## Do Not Use When1617- Do not use when a neighbouring skill owns the requested artefact or the task lacks a concrete source to ground it.18- Do not use this skill to fabricate missing project facts, legal conclusions, test results, approvals, or certification claims.1920## Required Inputs2122| Artefact | Source or provider | Required? | Missing-input behaviour |23|---|---|---:|---|24| 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`. |25| 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. |2627## Capability and permission boundaries2829Default 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.3031## Degraded Mode3233When 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.3435## Decision Rules3637| Condition | Action | Failure or risk avoided |38|---|---|---|39| A claim, metric, citation, API, or package is unverified | Verify, qualify, or remove it before release | Confident wrongness |40| A section has no project-specific evidence or decision | Rewrite or cut it | Superficial template content |4142## Workflow43441. 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.452. 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.463. 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.474. 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.485. On failure, recover by preserving completed evidence, identifying the narrowest corrective action and owner, and rerunning only the affected checks before handoff.496. Produce the named artefact and evidence record; publish, sign, certify, mutate production, or accept risk only under explicit authority.5051## Outputs5253| Artefact | Consumer | Observable acceptance condition |54|---|---|---|55| 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. |56| Gap and decision record | Accountable owner and downstream reviewer | Every gap has status, impact, owner, next action, and no unsupported pass or approval. |5758## Evidence Produced5960| Evidence | Contents | Acceptance condition |61|---|---|---|62| 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. |63| Validation record | Check, result (`pass`, `fail`, or `not assessed`), evidence location, date, and actor | No required check is omitted or silently treated as passed. |6465## Quality Standards6667- Every material claim is traceable, reviewable, and bounded by the available evidence.68- Use deterministic acceptance conditions and preserve traceability from source to decision and output.69- Separate facts, inferences, assumptions, and approvals; never present one as another.70- Apply `28-anti-ai-slop` during authoring and `29-ai-slop-audit` at major checkpoints and release.7172## Anti-Patterns7374- **Producing Guarded production artefact and ship-gate record from assumptions instead of named project sources.** Fix: Cite the source or mark the item unverified.75- **Treating a missing or inaccessible check as passed.** Fix: Mark it `not assessed`, state impact, and block dependent claims.76- **Using vague gates such as `adequate`, `secure`, or `user-friendly`.** Fix: Replace each with an observable criterion, threshold, and evidence source.77- **Copying a generic template without product, control, role, version, or jurisdiction detail.** Fix: Ground every section in the supplied context and remove unused boilerplate.78- **Publishing, signing, certifying, changing production, or accepting risk without authority.** Fix: Prepare a draft and route the decision to the accountable owner.79- **Listing evidence without provenance or an acceptance result.** Fix: Record source, period, integrity check, mapping, and pass/fail/not-assessed status.8081## Worked Example8283Example: 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.8485## References8687- [Repository operating rules](../../AGENTS.md): apply the engine's routing, evidence, and release gates.88- [Independent AI slop audit](../29-ai-slop-audit/SKILL.md): run after major iterations and before release.89- [Human English and reader-centred craft](../../book-extractions/human-english-craft-synthesis-2026.md): language, register, grammar, microcopy, and read-aloud overlay.9091<!-- dual-compat-end -->9293## Machine-error editorial gate (cross-engine Kaizen)9495Apply Digital Research's `docs/continuous-improvement/machine-errors-editorial-gate-2026-09-03.md`96while authoring. Review every requirement clause, rationale, table, and paragraph for:9798| ID | SRS-specific test |99|---|---|100| ME1 | Does this restate a nearby requirement, rationale, or constraint without a new trace, state, or oracle? |101| ME2 | Is parallel requirement structure expressing a real comparison, or only making the specification look balanced? |102| ME3 | Can an implementer or reviewer act from the existing wording without another restatement? |103| ME4 | Does the quality claim exceed its metric, threshold, or evidence? |104| ME5 | Is the example grounded in `_context/`, or would it fit any product? |105| ME6 | Has the same rhetorical construction become a repeated template tic? |106| ME7 | Does the paragraph add a requirement, constraint, test oracle, decision, or trace? |107108Merge or cut units with no delta. Preserve repetition required for deterministic testability,109traceability, accessibility, safety, or exact API/schema identifiers, and record that exception.110111### Impeccable-derived AS overlay112113When an SRS includes a website, UI specification, presentation, rendered document, or design114system, apply AS1-AS7 from the shared gate. For ordinary requirements prose, use AS1, AS3, AS5,115and AS6; mark visual checks `not_applicable` when no visual artifact is in scope.116117| ID | SRS-specific overlay test |118|---|---|119| AS1 | Is the template, terminology, UI pattern, or copy default justified by this product and reader? |120| AS2 | Do labels, badges, metrics, or section numbers add a requirement or merely imply importance? |121| AS3 | Do repeated requirements, cards, or sections represent distinct actors/states, or is the structure cloned? |122| AS4 | Does proposed animation, glow, gradient, or transition serve a state, task, or accessibility need? |123| AS5 | Is each example, icon, asset, endpoint, or screen traceable to product context rather than placeholder material? |124| AS6 | Are buzzwords, em-dash cadence, aphoristic contrasts, or theatrical framing hiding an untestable requirement? |125| AS7 | Does the rendered requirement remain readable, complete, accessible, and structurally valid? |126127For visual SRS deliverables, purple gradients, glassmorphism, neon glow, AI-beige defaults,128decorative editorial scaffolding, and decorative motion are no-ship choices. Preserve repeated129identifiers, acceptance criteria, error states, trace links, and safety wording when they carry130implementation or verification function; record the exception.131132The 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.133134## Real-time application (this is a LIVE constraint, not only a final gate)135136Apply 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.137138## Use When139140- 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.141- As the last gate after the Phase 09 audit and before the consultant sees the draft (PRIME "Inspect" step).142- Whenever you suspect a section reads as filler, hedged, or template-shaped rather than authored against real `_context/`.143144## Do Not Use When145146- You are still gathering `_context/` inputs; this skill checks finished drafts, not raw notes.147- The artefact is a private scratch file that will never reach a person or downstream skill.148149## What "AI slop" is (so you know what you are preventing)150151**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):1521531. **Superficial competence** — looks fine on the surface, no substance underneath.1542. **Asymmetric effort** — cheap to produce, costly for a human to read, review, or fix.1553. **Mass producibility** — generated at volume.156157The 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.158159Two 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.160161## The seven universal guardrails (apply to EVERY output)162163| # | Marker to prevent | Avoidance rule you MUST follow |164|---|---|---|165| **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. |166| **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. |167| **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. |168| **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. |169| **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. |170| **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. |171| **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. |172173## Banned / high-risk vocabulary (the lexical tells)174175These 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.176177This 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."178179- **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.180- **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.181- **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).182- **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").183- **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".184185## Drop-in guardrail block (inherit in dependent skills)186187```188ANTI-SLOP GUARDRAIL (inherit in every output):1891. SPECIFICITY FLOOR — every section carries >=1 concrete, named, domain-specific190 element from _context/. No tool defaults, no placeholder requirement copy.1912. VERIFY-BEFORE-EMIT — no statistic, citation, standard clause, named entity,192 API, schema field, or dependency ships unverified; cite at point of claim;193 flag uncertainty with [CONTEXT-GAP].1943. AUTHORED VOICE — state the engineering rationale / trade-off; no relentless195 positivity, no sycophancy; route real trade-offs into an ADR.1964. COVER THE HARD PARTS — error/edge/empty/failure cases, counter-arguments,197 design constraints; every edge case traces to a requirement.1985. BREAK THE TEMPLATE — vary rhythm and structure; forbid default aesthetics,199 the banned-vocabulary list, and undefined subjective adjectives.200```201202## Domain-specific avoidance (load the relevant block for the output type)203204- **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.205- **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.206- **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.207- **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.208- **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.209- **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.210- **Apps/product:** add genuine value over any wrapped API; transparent pricing + in-app cancel; no deceptive AI-capability claims; least-privilege permissions.211- **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.212- **Image/video:** real specimens only; check anatomy/text/physics; avoid the "AI sheen"; attach provenance (C2PA) where it matters.213214## Ship gate (run before delivering ANY output)215216- [ ] Every section has ≥1 concrete, named, specific element from `_context/` (U1/U2).217- [ ] Every stat, quote, citation, standard clause, named entity, API, schema field, dependency verified (U3).218- [ ] No banned vocabulary used as filler; no subjective adjective without its IEEE-982.1 metric; scanned the output for both lists above.219- [ ] The output states an engineering rationale / trade-off; no sycophancy (U5).220- [ ] Error/edge/empty/failure cases and counter-arguments addressed; every `_context/` edge case traces to a requirement (U6).221- [ ] Sentence length and structure varied; no rule-of-three reflex, no antithesis formula, no em-dash flood (U7).222- [ ] Every functional requirement is stimulus-response with a deterministic test oracle; no empty "Challenges and Future Prospects" section.223- [ ] Output type's domain block applied.224- [ ] When in doubt, run the `29-ai-slop-audit` skill on the draft.225226If any box is unticked, the output is not ready to ship.227228## Anti-Patterns229230- Treating the banned-vocabulary scan as cosmetic while leaving requirements untestable underneath — slop is a substance failure first, a lexical one second.231- Padding an SRS to a target length with restated obvious statements, violating the Minimum-Length Directive.232- Inventing an API, endpoint, or library to fill a `[CONTEXT-GAP]` instead of flagging it.233234## Outputs235236- A ship/no-ship decision plus the ticked gate checklist appended to the draft's review notes.237- Any unresolved item promoted to the matching V&V fail tag (`[V&V-FAIL]`, `[SMART-FAIL]`, `[CONTEXT-GAP]`, `[TRACE-GAP]`).238239## See also240241- `29-ai-slop-audit` — the detection/evaluation/audit companion (analyse any artefact for slop and score it).242- `02-audit-report` and the V&V SOP in `CLAUDE.md` — apply on top of this; IEEE/ISO grounding precedes style.
Run npx skillmds@latest add peterbamuhigire/28-anti-ai-slop in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
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. It is listed under Security on SkillMD.
This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
peterbamuhigire (@peterbamuhigire) published this skill. Their other Agent Skills are listed on their SkillMD profile.
peterbamuhigire