القائمة
Rules and worked examples for writing prose that does not read like AI-generated slop. Consult before writing or editing any prose.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | no-ai-slop |
| description | Rules and worked examples for writing prose that does not read like AI-generated slop. Consult before writing or editing any prose. |
The full rule list lives in the project CLAUDE.md (rules 1 through 24). This skill turns the rules that have worked examples into actionable guidance: each shows a WRONG version (the slop) and a RIGHT version (the fix). The pattern behind every fix is the same: replace the vague claim with a specific, checkable fact.
The character is banned. Use a semicolon, a period, a comma, or restructure.
"Significantly", "dramatically", "extremely" and their kin are placeholders for evidence. Replace the word with the number it was standing in for.
A sentence that asserts importance without a detail says nothing. End every claim on a concrete fact.
Three sections built from the same template read as machine output, even when each fact is true. Vary paragraph count, sentence rhythm, and how each section opens.
In [year], [party] did [thing]. This affected [number] people. [Party] responded by [action].
In [year], [party] did [thing]. This affected [number] people. [Party] responded by [action].
In [year], [party] did [thing]. This affected [number] people. [Party] responded by [action].
Section one: a detailed narrative with timeline and context across two paragraphs.
Section two: a two-sentence summary, because the event is thinly documented.
Section three: opens with the party's stated justification, then the contradicting evidence.
"In today's world", "It's important to note", "When it comes to" add length, not meaning. Open on the fact.
If a sentence could sit on any advocacy or marketing site without changing a word, it is generic. Anchor it to something checkable.
"May potentially", "can help to", "might be able to" hedge a claim into meaninglessness. Either the thing happens or it does not. Say which.
A heading names what the section holds. It does not tease, dramatize, or abstract.
Never put a position in a named person's mouth from inference. State only what they actually did or said, with the real source.
When you contrast two things, name the concrete difference that separates them. Do not assert that one is exempt, newer, better, or unaffected without saying what specifically makes it so.
Whenever you say A differs from B, name the part, the version, the date, the mechanism, or the supply-chain change that makes the difference real. If you do not have that detail, do not imply the difference exists.
Run this pass on every piece of prose before you hand it back. The full banned lists are in ./AI-WRITING.md; check against them directly.
Louis Rossmann's writing voice for general prose: testable-number density, high sentence-length variance, claim-then-proof structure, contractions, contempt shown through precision. Consult when writing in his voice.
Audit code for security vulnerabilities across six trust boundaries — access control (IDOR, privilege escalation, mass assignment), auth & sessions (passwords, JWT, CSRF), injection (SQL, XXE, path traversal), XSS & output encoding, untrusted URLs & uploads (SSRF, open redirect, file upload), and data exposure (secrets, PII, leaky errors). Use when hardening or reviewing a feature, before shipping anything that handles untrusted input, auth, or sensitive data, or when asked to "scan for vulnerabilities", "is this secure", "check for IDOR/XSS/SQLi/SSRF", "security review". Defaults to fail-closed, least-privilege, server-side checks.
Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.
Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.
Build and maintain a grounded picture of the project's users before designing solutions — personas, jobs-to-be-done, as-is/to-be workflows, and the assumptions under them, each tagged evidence or assumption. Use when kicking off a project or feature, before a PRD or user stories, when the team is guessing what users "want," or when another skill needs the user's goals or mental model.
Make a screen self-evident — understood at a glance, no thinking required: clear visual hierarchy, scannable layout, conventional patterns, obvious clickability, ruthless word economy. Use when a screen feels confusing or cluttered, when simplifying copy or layout, reducing cognitive load, or asking "is this clear?"