vs-deslop

Files (65)

• LICENSE.anti-slop
• LICENSE.oxlint-plugin-inhuman
• SKILL.md
• openai.yaml · agents/
• anti-slop-effect.oxlintrc.json · scripts/
• anti-slop.oxlintrc.json · scripts/
• load-ts.mjs · scripts/
• reject-anti-slop.mjs · scripts/
• reject-code-slop.mjs · scripts/
• run-anti-slop.mjs · scripts/
• ts-hooks.mjs · scripts/
• anti-slop.static.eval.ts · test/
• anti-slop-bad.ts · test/fixtures/
• anti-slop-good.ts · test/fixtures/
• anti-slop-note.md · test/fixtures/
• ceremony-wrapper.ts · test/fixtures/
• clean-add.ts · test/fixtures/
• comment-only-canary.ts · test/fixtures/
• consumer-pkg-skill.md · test/fixtures/
• deslop-targets-bad.ts · test/fixtures/
• hash-only-skill.md · test/fixtures/
• leftover-oxlint-bad.ts · test/fixtures/
• mention-only-inherit-hash-skill.md · test/fixtures/
• mention-only-inherit-skill.md · test/fixtures/
• no-names-skill.md · test/fixtures/
• oxlint-prose-hash-skill.md · test/fixtures/
• oxlint-prose-skill.md · test/fixtures/
• paragraph-paste-hash-skill.md · test/fixtures/
• paragraph-paste-skill.md · test/fixtures/
• SKILL.md · test/fixtures/published-pair/
• reject-anti-slop.mjs · test/fixtures/published-pair/scripts/
• second-miss-after-pass.ts · test/fixtures/
• try-catch-theater.ts · test/fixtures/
• whole-tree-skill.md · test/fixtures/
• peer-skills-iter.static.eval.ts · test/
• peer-skills.static.eval.ts · test/
• vs-deslop.static.eval.ts · test/
• PINNED · vendor/anti-slop/
• index.ts · vendor/anti-slop/src/effect/
• no-service-constructor-imports.ts · vendor/anti-slop/src/effect/rules/
• index.ts · vendor/anti-slop/src/
• no-chained-type-assertions.ts · vendor/anti-slop/src/rules/
• no-conditional-empty-object-spread.ts · vendor/anti-slop/src/rules/
• no-known-value-widening.ts · vendor/anti-slop/src/rules/
• no-module-mocking.ts · vendor/anti-slop/src/rules/
• no-object-parameters.ts · vendor/anti-slop/src/rules/
• no-reflect-apply.ts · vendor/anti-slop/src/rules/
• no-reflect-get.ts · vendor/anti-slop/src/rules/
• no-runtime-typeof.ts · vendor/anti-slop/src/rules/
• no-shape-in-symbol-names.ts · vendor/anti-slop/src/rules/
• no-unknown-parameters.ts · vendor/anti-slop/src/rules/
• no-unknown-returns.ts · vendor/anti-slop/src/rules/
• no-unknown-type-aliases.ts · vendor/anti-slop/src/rules/
• no-unsafe-dictionary-type.ts · vendor/anti-slop/src/rules/
• no-widen-then-assert.ts · vendor/anti-slop/src/rules/
• require-safety-comment-for-type-assertion.ts · vendor/anti-slop/src/rules/
• dictionary-types.ts · vendor/anti-slop/src/shared/
• lexical-type-parameters.ts · vendor/anti-slop/src/shared/
• reflect-method.ts · vendor/anti-slop/src/shared/
• PINNED · vendor/oxlint-plugin-inhuman/
• …and 5 more

SKILL.md (first lines)

# Deslop

Clean working code without changing behavior. This is the focused cleanup
building block: remove AI-ish noise, needless abstraction, duplicated logic,
stale fallbacks, and review-hostile clutter while preserving the product
contract.

Use [`vs-ponytail`](../vs-ponytail/SKILL.md) in composed mode to prefer
structural deletion and native or existing capabilities over a new
cleanup abstraction.

## Flow Contract

- **Kind:** Building block
- **Inputs:** Changed files or explicit scope, behavior that must stay unchanged, and available verification commands
- **Outputs:** Cleanup summary, changed files, behavior-preservation evidence, and deferred findings
- **Status:** `CLEAN`, `CLEANED`, `WARN`, `FAIL`, or `BLOCKED`
- **Consumers:** `vs:roast-code` Pass 1, `vs:build-it` Phase 4, `vs:ship-it` pre-PR review, standalone cleanup requests
- **Skip conditions:** Skip when the diff is trivial, generated-only, or the user explicitly asks for review-only/no edits

## Cleanup Targets

Inspect the requested scope for:

- flatten first: delete down to one layer. A new wrapper, helper, file,
  or mode flag is not a cleanup
- structural simplifications that delete whole concepts, branches, modes,
  wrappers, or layers instead of merely polishing them
- duplicate logic or copy-paste with tiny variations
- one job per unit: do not restate the same logic in many layers
- unnecessary `async`/`await` or Promise wrapping around sync work
- pass-through wrappers that add no meaning
- ceremony types and files (`Manager`, `Service`, `Factory`, `Helper`,
  `Utils`) that exist for a single call, plus config objects wrapping two
  or three parameters and boolean mode flags that split one path
- a single-use extract: a helper with one call site that only moved lines
- a helper or type that fails the **portability test**: if it could move to
  another repo unchanged, it is generic filler, not this product's logic
- synonym cycling of the same domain concept (rotating the name across
  layers: user / account / customer for one entity)
- defensive null checks on values proven non-null by types or callers
- fallback branches that hide primary-path failures
- silent defaults and optional chaining that hide missing required data:
  `?.` on a required field, `?? []`, `?? {}`, or `|| default` that papers
  over an invariant the caller should have supplied
- try/catch theater: a try/catch around non-throwing code, an empty catch,
  or a catch that logs and swallows a real failure
- `any`, a non-null assertion (`!`), and an uncommented type assertion
  that fabricates evidence
- comments that narrate obvious code, hand-holding notes, and JSDoc that
  is only restating the signature
- dead imports, stale flags, temporary debug leftovers, `console.log` /
  `console.debug` / `console.info` left in production paths, and a stale
  TODO fossil
- inconsistent naming or one-off conventions that fight the codebase
- ad-hoc conditionals bolted into busy flows where a typed model, dispatcher,
  policy object, or canonical helper would make the path easier to reason about
- cast-heavy or optionality-heavy boundaries that hide the real invariant,
  in particular:
  - `unknown` or `object` in a signature where the caller already knows the type
  - `Record<string, unknown>` and equivalents standing in for an owned contract
  - chained assertions (`value as object as User`) that fabricate evidence
  - widening a known value and asserting it back later
  - a broad annotation where `satisfies` would preserve the inferred keys
  - ad-hoc `typeof` narrowing where the value should be parsed once at the
    boundary

Run `skills/vs-deslop/scripts/reject-code-slop.mjs` on each in-scope file
before reporting `CLEAN` or `CLEANED`. Exit 1 is a catalog fail.

Then run the on-demand anti-slop file pass on the same in-scope TS/JS
files (named files only — not a whole-repo lint, and do not write
`oxlint.config` into the consumer repo):

```bash
node skills/vs-deslop/scripts/run-anti-slop.mjs <file.ts> [file.ts ...]
```

That command runs oxlint with the vs-owned config on named files:
the vendored generic anti-slop rules, `eslint/no-useless-catch`,
`eslint/no-console` (`console.error` and `console.warn` allowed),
`eslint/no-empty`, `eslint/no-unused-vars`, `eslint/require-await`,
`typescript/no-explicit-any`, `typescript/no-non-null-assertion`,
`unicorn/no-useless-fallback-in-spread`, `unicorn/no-unnecessary-await`,
`inhuman/no-empty-wrappers`, and `inhuman/no-swallowed-catch`. Exit 1
is a catalog fail (not `CLEAN`). If oxlint or the plugin cannot run,
report `WARN` or `BLOCKED` — do not pretend `CLEAN`. Enable the Effect
rule only when the target repo uses Effect. No-args, a directory, or
zero JS/TS names among args is not a pass (not `CLEAN`). Do not write
`oxlint.config` or `node_modules` into the consumer cwd. Do not spawn
a consumer package CLI.

Score the file pass with `skills/vs-deslop/scripts/reject-anti-slop.mjs`
(identity `9f42cf49e0a4ee9de516dbacbac04e687a0b7ed39e117d23d409555f45e18ef8`;
exit 1 is a fail). Exclusive is the live `skills/vs-deslop/SKILL.md` path
or a published skill-bytes pair. Exclusive cases live under `test/fixtures`.

## Procedure

**Exclusive order:** Lock behavior first, then collect →
validate/discard FP → surgical delete → verify → rescan.
Do not skip or invert these.

1. **Lock behavior first.** Identify the existing tests or direct checks that
   prove behavior. If none exist and cleanup could change behavior, add the
   narrowest regression test before editing. Do not invent types, files,
   flags, or behavior "for cleanliness."
2. **Collect candidates. Do not edit yet.** Name each smell, its category,
   the invariant or call site, and the file it affects. Do not broaden
   scope just because adjacent code is ugly.
3. **Validate each candidate.** Keep a change only when it is formula, not a
   necessary defense (auth, validation at a trust boundary, required error
   handling). A false positive that deletes a real guard is worse than one
   leftover tell. Discard it and say why.
4. **Flatten first.** The first cleanup move is one-layer delete. Before
   extracting a helper, ask whether a simpler state shape, ownership
   boundary, or default flow would remove the branch/helper/wrapper
   entirely. One clean delete beats three clumsy rewrites. Do not clean
   by adding a wrapper, helper, file, or mode flag.

From vltansky/vs, MIT.

More from vltansky/vs