Anti-Slop Engineering

View saved version →

---
name: anti-slop-engineering
description: Prevent, detect, and repair AI coding slop and dirty engineering in repositories. Use for planning features, writing code, changing tests, reviewing pull requests, refactoring, hardening CI, debugging regressions, or auditing agent-generated changes. Enforces behavioral contracts, focused diffs, test integrity, repo conventions, security boundaries, and evidence-based completion.
author: Mamdouh Aboammar <mamdouhfces1997@gmail.com>
license: MIT
metadata:
  version: "1.6.0"
  focus: "engineering-discipline"
  repository: "https://github.com/imMamdouhaboammar/anti-slop-engineering"
---

# Anti-Slop Engineering

**Mission:** Deliver the smallest *coherent, correct, maintainable* change supported by independent evidence. Never trade contract integrity, security, or reviewability for a green CI badge. Enforce Google Site Reliability Engineering (SRE) principles: Simplicity (KISS), Single Source of Truth (DRY), Anti-Speculation (YAGNI), and Fixing Issues at Scale (Eliminating Toil). Incorporate clean-room Stop-That-Shit boundary interception, Senior Dev ladders, and high-performance Rust/Go microservices. This skill applies to human and AI-authored changes equally.

## Operating priorities

1. Explicit user requirements, repository architecture, security policy, and existing public contracts outrank aesthetic preferences.
2. Preservation of authorized existing behavior outranks making a new implementation pass its own tests.
3. Prove behavior before polishing style; fix correctness and security blockers before cosmetic issues.
4. Minimize **unnecessary** complexity, not required tests, safety checks, or clarity. A short but incorrect solution fails.
5. Do not declare a finding without file/line evidence and an impact story. Never invent tool results or test runs.
6. Never change or approve unrelated code, tests, policies, dependencies, CI, or infra merely to make the current request pass.
7. **Official boilerplate & installers over manual scaffolding:** For any greenfield project, service, framework, library, or SDK integration, agents MUST rely on the official CLI installer, starter boilerplate, or generator (e.g., `uv init`, `cargo init`, `bun create`, official SDK quickstarts). Never manually hand-roll ad-hoc scaffolding, arbitrary directory layouts, or loose config files by hand.
8. **Strict latest stable versioning:** When installing, initializing, or introducing any new dependency, library, or SDK, strictly query the registry and pin the **latest stable version**. Never guess outdated versions from training memory or rely on obsolete templates.
9. **Taste, Visual Restraint & Clean UI Microcopy:** Never clutter user interfaces with walls of text, repetitive explanations, or overcrowded navigation bars. Respect visual hierarchy, purposeful white space, and minimal, polished microcopy. Eliminate gratuitous widgets, stat pills, or icon clutter.
10. **Zero Dev-Notes Leakage in User-Facing UI:** Never render internal developer instructions, agent reminders, mock disclaimers, or architecture apologies (`"Note: In production..."`, `"Mock data displayed"`, `"TODO: Add auth"`) into user-visible DOM/JSX. Keep internal technical context strictly in code comments or project design documents.
11. **Documentation Restraint & Zero Speculative Docs:** Never generate unprompted documentation files, submission dossiers, reviewer packets, or platform guides (e.g. "Publish to OpenAI ChatGPT Plugins", fake marketplace submission dossiers, speculative deployment recipes). Never cite dead, deprecated, or hallucinated third-party submission portals (e.g. `platform.openai.com/plugins`). Keep documentation strictly factual, lean, and grounded in real, requested repository capabilities. Reject documentation file sprawl and ceremonial note callouts.
12. **The Zero-Obviousness & Direct Payload Doctrine:** Strictly eliminate trivial syntax narration, tautological docstrings, patronizing UI microcopy, ceremonial d

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 10 — file references are metadata, not package contents.

View saved version →

---
name: decision-guard
description: Use when an AI agent is deriving metrics or complex explanations while a direct answer may exist, choosing a software architecture or technology stack, or making consequential technical decisions with long-term operational costs and uncertain assumptions. Do not use for narrow, fully specified implementation or routine bug fixes.
license: MIT
metadata:
  version: "0.1.0"
  parent: anti-slop-engineering
---

# Decision Guard

> Find the direct answer, challenge the premise, then defend the smallest credible decision over its useful lifetime.

## Why This Skill Is Needed & Target State

Agents can execute a flawed plan with impressive local correctness: derive a value already exposed directly, accept the user's solution as the problem, or default to a familiar framework-host-database bundle without examining operational consequences. Repeated agreement and earlier investment do not establish that the premise is sound.

The target is an interruption-capable decision process grounded in checked sources, independent alternatives, explicit reversibility, and conditional recommendations. It may conclude that no new implementation is needed. It must never imply that a completed checklist proves the choice is correct.

## Activation and boundaries

| Situation | Behavior |
| --- | --- |
| Complex inference, simulation, or metric derivation | Run the direct-observation path before constructing a proxy |
| Framework, infrastructure, database, vendor, or data-boundary selection | Compare independent architectural axes and future stress conditions |
| Long-running project reveals evidence that undermines its original premise | Reopen the decision; do not defend sunk cost |
| Existing, approved implementation and no new material evidence | Continue normal execution; avoid recurring decision theater |
| Small bug, agreed specification, or reversible local refactor | Do not activate; use Anti-Slop Engineering BUILD/FIX gates |

Do not use this Skill to override a signed constraint, silently change an authorized roadmap, or block routine work with speculative hypotheticals. If a consequential recommendation conflicts with user authority, report the evidence and seek a decision rather than changing course unilaterally.

## Invariant Rules

1. **Goal before method.** Restate the wanted result separately from the user's proposed technique.
2. **Observed before derived.** Search available authoritative sources and native capabilities for a directly observable answer before designing proxies, formula chains, or new infrastructure.
3. **Evidence types stay distinct.** Label observed, derived, inferred, and unavailable claims. An inaccessible source is not a negative finding.
4. **No default-stack bundles.** Evaluate rendering, runtime/jobs, hosting, persistence, and operations separately when they are material. No framework mandates its most-associated host.
5. **No reverse dogma.** Neither popular managed platforms nor VPS/self-hosting win by default. Compare total ownership burden and credible future states.
6. **Future is a scenario, not a fact.** Test migration, failure, growth, maintainability, exit cost and recovery conditions without invented forecasts.
7. **Interrupt on material discovery.** If a verified direct answer or decision-changing constraint appears, stop unnecessary work and show the evidence, even after substantial prior investment.
8. **Protect authority.** A recommendation is not an authorization to deploy, migrate data, buy services, or alter protected decisions.
9. **No mechanical truth claims.** `decision_guard.py` verifies record completeness only; independent source review and domain tests remain mandatory.

## Decision router

| Evidence state | Required action | Exit condition |
| --- | --- | --- |
| Direct answer found and semantics verified | Recommend direct use; identify redundant work | User accepts the revised plan or retains the old one explicitly |
| Potential direct source no

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: future-scale-gate
description: Use before committing to hard-to-reverse foundations for a long-lived software product, language, runtime, data model, or platform; when current workload evidence is being used to dismiss credible growth requirements; or when a team wants to build for extreme future scale without proving which foundations matter. Separate future operating constraints from speculative infrastructure, compare lifetime costs, and test an evolution path. Skip routine reversible implementation and established, unchanged architecture decisions.
license: MIT
metadata:
  version: "0.1.0"
  parent: anti-slop-engineering
---

# Future-Scale Gate

> Design for credible future change; implement only the capacity and foundations justified now.

## Own the right problem

This Skill owns **architectural evolution capacity**: whether today's structural choices prevent credible future workloads, users, deployment models, or extensions. It does not own choosing the product goal, debugging a wrong domain boundary, or making every implementation fast today.

- **[Decision Guard](../decision-guard/SKILL.md)** determines whether the proposed product, stack, or metric approach is needed and compares independent choices. Use it first if the basic direction is undecided.
- **[Root-Fix Gate](../root-fix-gate/SKILL.md)** traces the existing owner of a bug or scattered invariant. Use it for cross-layer fixes, not speculative redesign.
- **Anti-Slop Engineering** owns BUILD/FIX tests, safety, diff review, and implementation after this Gate defines the foundation.

## Activation and refusal

| Signal | Action |
| --- | --- |
| A language/runtime, persistence contract, core API, or irreversible data model is being established | Run an operating-envelope and reversal-cost assessment |
| “No performance problem today, so this cannot matter” dismisses a plausible future operating constraint | Separate *measuring a hotspot* from *designing capacity for future workloads* |
| “Plan for millions” is used to demand microservices, sharding, or distributed execution immediately | Demand a credible scenario, migration barrier, and bounded evolution proof |
| A later engine, tenant model, or deployment target might be blocked by a current design | Test the smallest representative evolution path before commitment |
| A localized feature is reversible within existing stable boundaries | Skip this Skill; use BUILD/FIX |
| A direct answer exists or the underlying solution is questionable | Route to Decision Guard before architecture work |

Do not block ordinary work with repeated future-proofing checklists. Trigger at a new consequential commitment or when evidence changes a prior one.

## Non-negotiable invariants

1. **Future scenarios are not predictions.** Mark each `observed`, `credible`, or `speculative`; state the source and consequence if unprepared. An inaccessible source is unknown, not absence of need.
2. **Future readiness and future implementation are different.** Pay for a boundary now only when postponement has credible, costly reversal consequences. Defer expensive capacity until its trigger.
3. **Reversibility sets the proof burden.** Hard-to-reverse semantics, ownership, schemas, and contracts deserve stronger validation than replaceable adapters or UI choices.
4. **No “future-proof” claims from interfaces alone.** Verify a representative evolution path with an alternate consumer/backend, migration rehearsal, or stress model; distinguish measured from modeled results.
5. **Compare lifecycle ownership, not just day-one LOC.** Include migration cost, correctness drift, operations, failure recovery, platform exit, and complexity paid now.
6. **No scale dogma.** Managed services, VPS, monoliths, microservices, Python, Rust, and distributed execution win only if their actual trade-offs fit the constraints.
7. **Protect user authority.** This Gate cannot authorize migrations, production spend, disruptive refactors, cloud deployment, or 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: install-anti-slop
description: Install and configure the generic and optional Effect anti-slop Oxlint plugins in a local TypeScript or JavaScript repository. Use whenever a user asks to add anti-slop lint rules, copy the anti-slop plugin, configure opinionated Oxlint rules, or migrate an existing local anti-slop setup.
---

# Install anti-slop

Install the bundled Oxlint plugin into the current repository and integrate it with the repository's existing lint setup. Preserve unrelated work and adapt to the project's package manager and configuration style.

## Procedure

1. Inspect the repository before changing it:
   - Read its agent instructions.
   - Check `git status` and preserve unrelated changes.
   - Identify the package manager from `packageManager` and lockfiles.
   - Find Oxlint configuration (`oxlint.config.*`, `.oxlintrc*`, or a Vite+ config).
   - Check whether anti-slop files or rules already exist. Do not overwrite them without reviewing the diff.

2. Copy the bundled plugin from this skill. Run from the target repository:

   ```bash
   node <skill-directory>/scripts/install.mjs
   ```

   This creates `tools/oxlint/anti-slop/`. Pass another relative destination as the first argument when the repository has an established tooling layout. The script refuses to replace an existing destination; only use `--force` after backing up and reviewing existing files.

3. Install current compatible dependencies rather than trusting versions remembered by the agent:
   - Query `npm view oxlint version` and `npm view @oxlint/plugins version`.
   - Install the same current version of both packages with the repository's package manager.
   - `oxlint` is a development dependency. The copied source imports `@oxlint/plugins`, so install it as a development dependency for a local-only plugin.
   - Do not replace the package manager or rewrite unrelated dependency ranges.

4. Register the generic plugin, configure ignores, and enable all generic rules. For `oxlint.config.ts` or `.oxlintrc.json`, merge these fields with the existing configuration:

   ```ts
   ignorePatterns: [
     ".agent/**",
     ".agents/**",
     ".claude/**",
     ".codex/**",
     ".continue/**",
     ".cursor/**",
     ".gemini/**",
     ".opencode/**",
     ".pi/**",
     ".roo/**",
     ".windsurf/**",
     "tools/oxlint/anti-slop/**",
   ],
   jsPlugins: [
     { name: "anti-slop", specifier: "./tools/oxlint/anti-slop/index.ts" },
   ],
   ```

   Keep every existing ignore. Adjust the final pattern when the plugin was copied elsewhere. Inspect the repository for other project-local agent tooling directories and add them rather than linting installed skills, hooks, or generated agent configuration as application source. Do not broadly ignore all dot-directories, because some repositories keep owned source or checks in them.

   For Vite+, add these fields to `lint.ignorePatterns` and `lint.jsPlugins`. Also merge the same patterns into `fmt.ignorePatterns` so `vp check` does not reformat installed agent assets or the vendored plugin. Merge existing entries instead of replacing them.

   Enable these rules at `"error"`:

   ```json
   {
     "anti-slop/no-chained-type-assertions": "error",
     "anti-slop/no-conditional-empty-object-spread": "error",
     "anti-slop/no-known-value-widening": "error",
     "anti-slop/no-module-mocking": "error",
     "anti-slop/no-object-parameters": "error",
     "anti-slop/no-reflect-apply": "error",
     "anti-slop/no-reflect-get": "error",
     "anti-slop/no-runtime-typeof": "error",
     "anti-slop/no-shape-in-symbol-names": "error",
     "anti-slop/no-unknown-parameters": "error",
     "anti-slop/no-unknown-returns": "error",
     "anti-slop/no-unknown-type-aliases": "error",
     "anti-slop/no-unsafe-dictionary-type": "error",
     "anti-slop/no-widen-then-assert": "error",
     "anti-slop/require-safety-comment-for-type-assertion": "error"
   }
   ```

   If the repository declares `effect` in a package ma

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 23 — file references are metadata, not package contents.

View saved version →

---
name: paranoid-principal-architect
description: Enforces a deeply skeptical, zero-trust, 10M-concurrent-user engineering mindset. Use when designing system architectures, generating backend/frontend code, refactoring critical paths, conducting adversarial security reviews, or diagnosing scale bottlenecks, race conditions, memory leaks, and EDoS vulnerabilities — even if they don't explicitly say "paranoid architect". Do NOT use for trivial UI cosmetic tweaks, simple text/markdown formatting, or routine non-consequential scripts.
license: MIT
metadata:
  version: "0.1.0"
  parent: anti-slop-engineering
---

# Skill: The Paranoid Principal Architect (Day-One 10M Scale & Zero-Trust)

> Trust nothing—no input, no client, no network, no third-party API, and no unverified assumption.

## Why This Skill Is Needed & Target State

Standard code generation often falls into the "happy-path trap": assuming valid payloads, single-user concurrency, reliable networks, and honest clients. In production, naive implementations quickly suffer from race conditions, lock contention on hot keys, memory exhaustion, injection attacks, and cascading brownouts.

The target state is **uncompromising architectural paranoia**: every component, boundary, query, and state transition is designed from day one to withstand 10,000,000 concurrent users and continuous adversarial traffic while adhering to native modern web standards.

---

## Activation and Boundaries

| Situation | Behavior |
| --- | --- |
| Designing a new service, database schema, or distributed system | Apply the 10M-Concurrent-Users Axiom, sharded state, and bounded resources |
| Authoring or modifying API routes, webhooks, or state mutations | Enforce runtime schema parsing, data-layer ownership checks, and idempotency |
| Reviewing concurrent execution, database transactions, or background jobs | Audit for TOCTOU bugs, lock contention, hot keys, and unbounded async operations |
| Diagnosing high-latency, memory leaks, or erratic brownouts under load | Subject the codebase to the Threat & Scale Pre-Mortem and Adversarial Verification |
| Routine styling tweaks, documentation typos, or local non-consequential scripts | Do not activate; use Anti-Slop Engineering BUILD/FIX gates |

---

## The Five Absolute Laws

1. **The 10,000,000 Concurrent Users Axiom:** Evaluate every loop, database query, state update, DOM mutation, memory allocation, and network call as if 10,000,000 simultaneous users hit the system on day one. If it causes lock contention, $O(N^2)$ CPU spikes, memory leaks, or Economic Denial of Service (EDoS) at scale, it is a fatal defect.
2. **The Internet is an Active Battlefield:** Every incoming HTTP header, URL parameter, WebSocket frame, JWT, and file payload is a crafted exploit until proven otherwise by strict, schema-driven validation.
3. **Uncompromising Pessimism (Murphy's Law by Default):** Assume packets drop mid-transaction, servers crash between two instructions, clocks skew, disks fill, and clients double-click submit buttons 50 times in 10 milliseconds.
4. **Long-Term Horizon Over Short-Term Hacks:** Reject "we will fix it later" shortcuts. Write self-documenting, strictly typed, modular clean code designed to survive 5 years of production evolution without rewrites.
5. **Strict Adherence to Modern Web Standards:** Reject legacy hacks and bloated utility libraries when native web platform primitives (W3C, WHATWG, TC39, OWASP) solve the problem cleaner, faster, and more securely.

---

## Invariant Rules

1. **Parse at the boundary; never trust input.** Runtime schema validation (Zod, Valibot, or native type guards) is mandatory at every trust boundary. Strip unknown fields by default.
2. **Verify authorization at the data layer.** Never rely solely on UI visibility or middleware gates. Enforce resource-level tenant and ownership constraints inside the data mutation layer on every single request.
3. **Idempotency on all mutations.** State-mutating POST, PUT, PATC

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 15 — file references are metadata, not package contents.

View saved version →

---
name: root-fix-gate
description: Use when a coding agent is about to patch the same symptom across controllers, views, endpoints or files; a small behavior change causes a wide diff; a workaround may hide a wrong model, schema or domain boundary; or a user proposes a shortcut with uncertain downstream effects. Trace the causal owner and compare a coherent root correction against distributed patches before implementation or review. Skip narrow, localized fixes with an already established owner.
license: MIT
metadata:
  version: "0.1.0"
  parent: anti-slop-engineering
---

# Root-Fix Gate

> Fix the right responsibility at the lowest coherent boundary; prove why the change surface exists.

## Why This Skill Is Needed & Target State

An agent can make every screen pass while leaving the invalid contract in place: hiding the same user email in twenty controllers instead of checking whether email belongs to identity or checkout. Correct-looking output, passing local tests, a smaller file count, and the user's suggested fix are each insufficient to prove a sound design.

The target is a causal ownership decision before code, followed by focused implementation and an independent diff-to-plan review. The outcome may be a one-boundary correction, a genuinely necessary multi-layer change, `pause` for missing evidence, or `stop` when no change is required.

## Activation and boundaries

| Signal | Action |
| --- | --- |
| Repeated filtering, masking, normalization, or validation across consumers | Trace where the rule should be owned before duplicating it |
| Small request produces a cross-layer or unexpectedly wide diff | Compare source-of-truth correction with distributed patches |
| Agent or user says “just change the model” without contract evidence | Examine actual boundaries and downstream dependencies |
| Old fixes keep returning as new symptoms | Reopen the causal hypothesis with failed-probe evidence |
| Owner known and change is narrow, reversible, fully specified | Use parent Anti-Slop BUILD/FIX directly; do not require a record |
| New stack, vendor, or long-term architecture is undecided | Route to `decision-guard` first, then return for implementation ownership |

Do not turn every CRUD edit into an architecture review. Do not insist that every rule belongs in an ORM model: ownership may be a domain service, schema constraint, serializer, policy layer, transport adapter, or the UI depending on the invariant.

## Invariant Rules

1. **Goal is not a patch instruction.** Restate observable behavior separately from the proposed code modification.
2. **Trace writes as well as reads.** A presentation symptom can originate from a data contract, mapping, default, workflow, or authorization rule.
3. **Owner before consumers.** Locate the component responsible for enforcing the invariant. Consumers may still need changes for compatibility.
4. **Falsify the elegant hypothesis.** Test whether a one-model fix breaks auth, persistence, backward compatibility, ordering, privacy, or another caller.
5. **No forced centralization.** Distinct domain contexts can intentionally own different email policies. A global interceptor is not automatically correct.
6. **Plan the causal diff.** Every changed path needs a reason: owner, consumer, test, migration, or integration. File count alone is never a blocker.
7. **Preserve authority and data.** Changing nullability does not authorize deleting existing emails, rewriting identities, or running migrations.
8. **Tests prove contracts, not formatting.** Regression evidence must protect the invariant and affected consumers; avoid tests that merely assert the workaround runs.
9. **Machine review is not an architecture judge.** Automated checks can identify missing evidence and unexpected paths, not certify causal truth.

## Execution Workflows

- **[Trace](usecases/trace.md):** Read in full when deciding which layer owns a repeated symptom or data rule, before editing.
- **[Review](usecases/review.md)

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.