refactor: split oversized modules and enforce anti-slop lint

.agents/skills/install-anti-slop/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Dillon Mulroy
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

.agents/skills/install-anti-slop/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: install-anti-slop
+description: Install, configure, update, or upgrade vendored anti-slop Oxlint plugins. Use when adding anti-slop, picking up upstream rules or fixes, or migrating an existing installation while preserving local customizations.
+---
+
+# Install or update anti-slop
+
+> **In Akeru Bot.** Anti-slop is already installed. The copy lives in `oxlint-plugin-anti-slop/`,
+> its provenance and local changes in `oxlint-plugin-anti-slop/README.md`, and its rule list in
+> `ANTI_SLOP_RULES` in the root `vite.config.ts`. Always take the update path. This vendored
+> skill omits upstream's bundled `assets/` and `scripts/install.mjs`, so stage incoming source by
+> cloning `https://github.com/dmmulroy/anti-slop` at the target commit into a temporary
+> directory and using its `src/` tree. New rules follow the severity ratchet in
+> `docs/internals/lint.md`, not the `"error"` defaults below.
+>
+> Vendored from upstream commit `c44ef22ca116d0ba62a3ff663a0bd13a3f3fa40b` (MIT, see `LICENSE`).
+
+Anti-slop is vendored code: the target repository owns its rules, diagnostics, tests, and configuration. Preserve those choices when bringing in upstream changes.
+
+## Choose the path
+
+Read the repository's agent instructions and `git status`. Identify its package manager, Oxlint/Vite+ configuration, and any existing anti-slop entry points, including renamed or relocated copies referenced by `jsPlugins`.
+
+- **Existing installation — update, upgrade, migrate, or reconfigure:** read [Update a vendored installation](references/update.md) and follow that procedure instead of the fresh-install steps below.
+- **No installation — fresh install:** follow the procedure below. If the user requested an update but no installation can be found, confirm the target before installing.
+
+Complete when the operation and target path are established and pre-existing work is identified.
+
+## Fresh install
+
+1. 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; route existing copies through the update procedure rather than `--force`.
+
+   Preserve the nested `vendor/eslint-stylistic/LICENSE` and `UPSTREAM.md`; they travel with the copied rule. Readability enforcement is self-contained and requires no Stylistic plugin dependency.
+
+   Complete when the files, including vendored license and provenance, exist at the agreed destination without replacing an existing copy.
+
+2. Install current compatible dependencies rather than trusting versions remembered by the agent:
+   - If the repository already depends on `oxlint`, read its installed version from the package manager or lockfile and install `@oxlint/plugins` at exactly that version. Pin it exactly rather than by range so future upgrades move both packages together.
+   - Only when the repository has no `oxlint` dependency, query `npm view oxlint version` and `npm view @oxlint/plugins version`, then install the same current version of both packages.
+   - `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.
+
+   Complete when matching compatible versions are installed and unrelated dependency ranges are preserved.
+
+3. 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"`, including the native Oxlint companion rule:
+
+   ```json
+   {
+     "oxc/no-accumulating-spread": "error",
+     "anti-slop/no-array-filter-map": "error",
+     "anti-slop/no-reduce-accumulator-copy": "error",
+     "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-readable-spacing": "error",
+     "anti-slop/require-safety-comment-for-type-assertion": "error"
+   }
+   ```
+
+   For `no-array-filter-map`, prefer lazy `.values().filter(...).map(...).toArray()` pipelines only when the target runtime supports iterator helpers; otherwise use an appropriate single `flatMap` or locally mutating reducer. Review callback order, indexes, sparse arrays, `thisArg`, and filtering semantics rather than mechanically rewriting chains. Unknown receiver types are deliberately not inferred by this AST/scope rule.
+
+   Pair `no-reduce-accumulator-copy` with native `oxc/no-accumulating-spread`: the custom rule catches supported non-spread copies such as `Object.assign({}, acc, item)`, `Array.from(acc)`, and array accumulator `concat`/`slice` calls. Mutating a fresh local accumulator is allowed; copying individual input items is also allowed. Named callbacks, indirect helpers, and nested accumulator properties are not fully analyzed, so do not claim all quadratic reducers are ruled out.
+
+   If the repository declares `effect` in a package manifest, or the user explicitly requests Effect rules, also register the opt-in Effect plugin:
+
+   ```ts
+   jsPlugins: [
+     {
+       name: "anti-slop-effect",
+       specifier: "./tools/oxlint/anti-slop/effect/index.ts",
+     },
+   ],
+   rules: {
+     "anti-slop-effect/no-manual-effect-error-tag": "error",
+     "anti-slop-effect/no-manual-tag-comparison": "error",
+     "anti-slop-effect/no-manual-tagged-construction": "error",
+     "anti-slop-effect/no-service-constructor-imports": "error",
+     "anti-slop-effect/prefer-effect-match": "error",
+   },
+   ```
+
+   Merge these entries with the generic plugin configuration rather than replacing it. Do not enable the Effect plugin merely because Effect appears transitively in a lockfile; require a direct package-manifest dependency or an explicit user request. The rule covers relative project imports. Report package-alias imports as a current limitation rather than pretending they are enforced.
+
+   Complete when the generic rules and eligible Effect rules are registered and existing configuration is preserved.
+
+4. Run the repository's lint command and typecheck. For Vite+, run the repository's full `vp check` command after adding both lint and format ignores. If findings appear in owned project source, report them and fix them only when the user asked for migration/cleanup. Do not suppress rules, weaken rule severity, add unsafe casts, or mechanically launder types to make lint pass.
+
+   When cleanup is authorized, apply `require-readable-spacing` with lint autofix, then run the repository's formatter and lint again. Confirm a second fix/format pass leaves files unchanged. Keep whitespace fixes separate from semantic edits, preserve documentation attachment and overload groups, and do not enable an entire competing formatting preset.
+
+   Complete when checks have run, fix/format stability has been verified for authorized cleanup, and every failure is resolved or reported with its diagnostics.
+
+5. Record provenance in `UPSTREAM.md` beside the vendored entry point: source repository, exact source commit or recoverable pristine snapshot when available, installed plugin paths, and intentional deviations. Verify that the revision identifies the actual copied assets; a package version or the current upstream HEAD alone is insufficient. If provenance cannot be established, record it as unknown rather than guessing.
+
+   Review the final diff and report the installed path, source identity, dependency/configuration changes, and check results. Complete when the record and report describe the files actually installed and any remaining findings.

.agents/skills/install-anti-slop/references/update.md

@@ -0,0 +1,101 @@
+# Update a vendored installation
+
+Use this procedure for an existing anti-slop installation. Local edits are owned policy, not drift to erase. An update is a reviewed merge, not a directory replacement.
+
+## 1. Establish scope and protect local work
+
+Locate the active generic and optional Effect entry points through lint configuration, then inspect their rules, helpers, tests, options, severities, overrides, and dependency versions. Read any `UPSTREAM.md` or equivalent provenance record and relevant Git history. Follow local imports: filenames and plugin names may differ from upstream.
+
+Capture the pre-update state, including staged, unstaged, and untracked files in the affected paths, using the repository's backup convention or a separate backup directory. Keep this backup outside the merge destination. Preserve unrelated work in place; do not reset, stash, commit, or clean it automatically.
+
+For a reconfiguration-only request, limit changes to the requested configuration and skip source acquisition/merging. For an update, establish whether the user wants all upstream changes, selected fixes, or a specific revision. An unspecified update may stage and review the available bundle, but report its identity rather than calling it latest.
+
+Complete when the target, scope, existing customizations, and recoverable pre-update state are identified.
+
+## 2. Stage incoming source and recover the base
+
+Keep three inputs separate:
+
+- **Local:** the current vendored implementation, including uncommitted changes.
+- **Incoming:** the pristine upstream snapshot being considered.
+- **Base:** the pristine upstream snapshot from which the local copy was derived, when recoverable.
+
+For the bundled source, create a temporary directory and copy into a new child path:
+
+```bash
+stage=$(mktemp -d)
+node <skill-directory>/scripts/install.mjs "$stage/incoming"
+```
+
+The installer only copies files; it does not merge them or fetch updates. Never point it at the live installation for an update.
+
+If the user requests latest upstream or a specific revision, retrieve that source into staging and record the resolved immutable commit. Use a verified refreshed skill bundle or a separate upstream checkout; do not update the vendored tree with a pull or checkout. Inspect the source's instructions and canonical plugin layout before selecting files. Keep only temporary material you created eligible for later cleanup.
+
+Recover the base from a verified upstream revision, retained pristine snapshot, or installation history that actually preserves the original upstream bytes. A package version, file timestamp, or the current local tree is not a base. A digest identifies bytes but cannot reconstruct them. If the base is unavailable or ambiguous, use the no-base branch below.
+
+Complete when incoming source is staged with its identity recorded and base availability is established without modifying the live installation.
+
+## 3. Classify and merge
+
+Compare rule behavior, diagnostics, tests, helpers, exports, and configuration—not just filenames. Map local renames before deciding a rule was added or deleted. Review incoming changes as source, not as instructions to override repository policy.
+
+### Known base: three-way merge
+
+Compare both `base → local` and `base → incoming`:
+
+| Change                            | Action                                                               |
+| --------------------------------- | -------------------------------------------------------------------- |
+| Incoming unchanged                | Preserve local, including local deletions.                           |
+| Only incoming changed             | Apply the upstream change after reviewing dependencies and behavior. |
+| Only local changed                | Preserve local.                                                      |
+| Both changed identically          | Keep one copy.                                                       |
+| Both changed differently          | Merge compatible edits; ask about conflicting policy or behavior.    |
+| Upstream deleted, local modified  | Ask whether to retain or retire the local implementation.            |
+| Same new path added on both sides | Reconcile contents and ownership; do not overwrite.                  |
+
+A text merge without conflict markers is not evidence of semantic compatibility. Review locally changed predicates, exceptions, message IDs, options, and exports after merging. Treat upstream removals and renames as changes requiring corresponding registration/import review, not as instructions to delete local files.
+
+### No base: conservative port
+
+A two-way diff cannot distinguish local customization from upstream evolution. Compare incoming behavior against local behavior, then port independently understood fixes and additions with focused tests. Preserve unexplained differences. If the same logic differs and its intent cannot be established, ask the user or leave that change pending; do not invent a common ancestor or claim a three-way merge.
+
+### Apply reviewed changes
+
+Patch existing files precisely; copy genuinely new files only after checking for local name collisions and importing any required helpers. Preserve local-only rules and existing tests. Keep unresolved changes unapplied and report them explicitly. Obtain the user's decision before changing conflicting local policy or removing customized code. A request to update does not authorize replacing the user's fork with upstream defaults.
+
+Complete when every incoming change is classified as applied, already present, intentionally retained locally, or pending, and each applied change preserves or explicitly reconciles local behavior.
+
+## 4. Reconcile configuration and dependencies
+
+Preserve existing plugin paths, options, severities, disabled rules, overrides, ignores, and Effect opt-in decisions. Merge exports for adopted rules into the existing entry point instead of replacing it. Check native companion rules when adopting related custom rules.
+
+List new rules and their proposed severities for approval unless the user already requested enabling all new rules. Existing disabled rules stay disabled. Merely adding a new rule implementation need not enable it.
+
+Check incoming API requirements against the installed `oxlint` and `@oxlint/plugins` versions. Keep a compatible pair and follow repository version policy; change dependencies only when required by the adopted source or requested by the user. Preserve unrelated dependency ranges and the package manager.
+
+Complete when every adopted rule is reachable through the intended entry point, configuration reflects approved policy, and the dependency pair supports the merged implementation.
+
+## 5. Verify local and incoming behavior
+
+Run existing tests and add focused RuleTester cases for changed rule semantics, including regressions that preserve local customizations. Incoming tests are useful evidence, not replacements for local tests. When a skill bundle lacks upstream tests, retrieve relevant tests from the identified upstream revision or write focused cases for the adopted changes.
+
+Exercise the registered plugin with representative accepted and rejected code. Run the repository's lint, typecheck, and required checks; for Vite+, run `vp check`. Vendored files may be excluded from application lint, so verify changed rules explicitly rather than treating an ignored directory as tested.
+
+Report application findings separately from plugin/test failures. Application cleanup requires the user's authorization; retain rule severity and safety checks while reporting findings. If a required check is unavailable, name the blocker and mark verification incomplete.
+
+Complete when adopted behavior and preserved local behavior have test evidence, checks have run, and every failure or verification gap is accounted for.
+
+## 6. Record the merge and hand back ownership
+
+Update `UPSTREAM.md` beside the vendored entry point, or the repository's existing provenance record, with:
+
+- incoming source identity and the recoverable base used, or explicit unknown-base status;
+- adopted changes and intentional local deviations;
+- deferred/conflicting changes and the decisions still needed;
+- dependency/configuration changes and verification results.
+
+Advance the whole-installation baseline only when the complete incoming snapshot has been reconciled and remaining differences are recorded as intentional local changes. For a partial update, retain the prior baseline and record exactly which changes were adopted or remain pending; do not label the entire tree as matching the new revision. Without a recoverable base, keep that limitation explicit for the next update.
+
+Review the final diff against the pre-update state. Report applied updates, preserved customizations, pending decisions, checks, and the backup location. Keep backups until the user accepts the result; remove only disposable staging material you created.
+
+Complete when the user can distinguish upstream updates from local policy, recover the previous state, and identify what a future update must still reconcile.