Asw Remove AI Slops

Antigravity Swarm Remove AI Slops

Use this skill when the user asks to remove slop, clean generated-looking code, deslop a branch, remove noisy comments, simplify over-defensive logic, or tidy recent AI-assisted changes.

The invariant: behavior is locked before cleanup. A checklist is not safety. A passing characterization or regression check is the safety mechanism.

Inputs

• Default scope: changed files in the current branch compared with the merge base of main.
• Optional scope: an explicit file list from the user or from an ASW plan.
• Accepted file types: source, tests, docs, installer scripts, hook scripts, and configuration files owned by the current change.
• Excluded file types: deleted files, binaries, vendored directories, generated output, lockfiles unless the lockfile is the requested surface.

What this skill does

This skill cleans a bounded set of files while preserving behavior.

It does four things:

1. Determines scope.
2. Locks current behavior with tests or characterization checks.
3. Runs categorized cleanup in safe order.
4. Verifies with quality gates and an ASW review.

It does not:

• change public APIs unless the user explicitly asked,
• remove validation at external boundaries,
• rewrite architecture for taste,
• optimize code when behavior equivalence is not obvious,
• claim completion from green tests alone.

Categories

1. Obvious Comments

Remove:

• comments that restate the next line,
• trivial docstrings on self-explanatory functions,
• section banners,
• commented-out code,
• vague TODOs without owner or issue,
• notes that expose internal process instead of product behavior.

Keep:

• comments explaining why,
• issue links,
• algorithm notes,
• regex explanations,
• boundary or compatibility constraints,
• BDD markers in tests.

2. Over-Defensive Code

Remove or simplify:

• null checks for guaranteed values,
• default values for required parameters,
• broad catches around code that cannot throw,
• duplicated validation after a trusted parse step,
• stale compatibility shims no longer documented or tested,
• empty catches and log-only catches that swallow unknown failures.

Keep:

• validation at user input, network, filesystem, subprocess, database, and external API boundaries,
• nullable data handling,
• top-level CLI or server boundary error handling with explicit reporting,
• security checks.

When narrowing broad catches, handle known errors and rethrow unknown errors.

3. Excessive Complexity

Look for:

• nesting deeper than three levels,
• nested ternaries,
• boolean expressions with four or more predicates,
• long parameter lists,
• functions doing several responsibilities,
• type or variant discrimination through long conditional chains,
• generic catch-all object shapes where a typed shape is known.

Preferred cleanup:

• guard clauses,
• named intermediate values,
• small responsibility extraction,
• exhaustive variant handling in the local language,
• typed input parsing at the boundary.

Skip when:

• the pattern is established and clearer in this codebase,
• the path is performance-critical and intentionally shaped,
• the simplification would require a behavior proof you do not have.

4. Needless Abstraction

Remove:

• pass-through wrappers,
• single-use helpers that hide simple code,
• speculative interfaces,
• factories that only call constructors,
• indirection created only because future changes might happen.

Keep:

• abstractions with multiple implementations,
• test seams that reduce real coupling,
• framework-required boundaries,
• public extension points.

5. Boundary Violations

Flag and fix only when safe:

• UI or command layer importing storage internals,
• hook scripts owning installer policy,
• package tests depending on private reference trees,
• docs claiming behavior not covered by the package,
• pure-named functions with hidden side effects.

When unsure, report the boundary issue and skip the edit.

6. Dead Code

Remove:

• unused imports,
• unused private helpers,
• unreachable branches,
• stale feature flags,
• debug output,
• removed-code comments,
• orphaned exports not referenced by docs, tests, package manifests, or dynamic lookup.

Keep:

• dynamic dispatch targets,
• plugin manifest entries,
• public exports,
• intentional rollback flags with evidence.

7. Duplication

Remove:

• copy-pasted branches with trivial differences,
• repeated literal sequences,
• redundant helpers doing the same thing,
• duplicated package or hook path logic.

Keep:

• similar code with different intent,
• local duplication that is clearer than premature sharing.

8. Performance Equivalences

Apply only when behavior equivalence is obvious:

• list scan to set lookup,
• repeated computation in a loop hoisted outside,
• eager collection to lazy iteration,
• string concatenation in loop to join,
• repeated API or database calls batched when result ordering and errors stay the same,
• redundant clones or deep copies removed,
• repeated length checks cached when the collection cannot mutate.

Do not:

• alter algorithms with subtle correctness conditions,
• micro-optimize without a benchmark,
• change ordering, exception timing, or side effects.

9. Missing Tests

If changed behavior is uncovered, add the narrowest regression test before cleanup. The fix is not to remove code; the fix is to lock behavior.

Tests should pin observable outputs, public errors, package contents, generated files, or CLI text rather than private implementation details.