Deslop

Deslop

Take code that was just written and make it feel tighter, simpler, and more deliberate.

Read style.md first. That file is the source of truth for the style rules.

Process

1. Identify the target files.
   • Start with files modified in this session.
   • Use git diff if available, otherwise use recent edits or the user's explicit file list.
   • Do not touch unrelated files.
2. Read each target file before editing it.
3. Use parallel subagents for the cleanup pass.
   • If there are multiple files, split them across subagents.
   • If there is one large file, it is still fine to use one subagent for an isolated second pass.
   • Give each subagent the exact file list it owns.
   • If the scope is only one to three small files, a single pass is fine. Do not add subagent overhead just to satisfy the rule mechanically.
4. Tell each subagent to:
   • read skills/deslop/style.md
   • simplify only its assigned files
   • preserve behavior exactly
   • skip any change that adds churn without making the code clearer
   • report a short summary of what changed and what was intentionally skipped
5. Review the subagent output, apply the changes, then do a final sanity pass yourself.
6. Summarise the cleanup in concrete terms.
   • Example: "flattened 3 nested conditionals, renamed 2 booleans, replaced 1 non-null assertion"

Constraints

• Never change behavior. This is a style pass, not a refactor.
• If a style rule conflicts with preserving behavior, preserving behavior wins.
• Prefer small, local edits over wide rewrites.
• If the code only becomes meaningfully cleaner after a deeper architectural refactor, stop and say so instead of forcing deslop beyond its scope.
• Skip generated files, vendor code, build output, and lockfiles.
• Skip tests unless the user asked to include them.
• Skip any rule when applying it would make the code harder to read.
• Preserve exported and public APIs unless the user explicitly asked for API changes.
• Preserve exported TypeScript signatures unless the user explicitly asked for typing or API changes.
• If the code is already clean, say that instead of forcing changes.

What To Look For First

• Guard clauses instead of nested conditionals
• if plus early return instead of else
• const instead of let when there is no reassignment
• narrowing or direct removal instead of ! non-null assertions
• Boolean(value) or explicit comparisons instead of !!value
• clearer boolean names like isOpen, hasItems, canRetry
• shorter functions with one clear job
• smaller orchestration functions with extracted helpers
• query/data gathering separated from action/side effects
• function names that describe side effects honestly
• overloaded hooks or components split with small pure helpers
• object parameters instead of long positional argument lists
• exhaustive handling for discriminated unions
• React render branches flattened with early returns
• inline JSX handlers when the logic is only used once
• keep handlers hoisted when they are reused in multiple places

Bad vs good

// Bad: nested control flow and unnecessary else
function getLabel(user?: User) {
  if (user) {
    if (user.name) {
      return user.name;
    } else {
      return "Anonymous";
    }
  } else {
    return "Anonymous";
  }
}

// Good: early returns, flat flow
function getLabel(user?: User) {
  if (!user?.name) return "Anonymous";
  return user.name;
}

// Bad: hoisted one-off handler and && render
const handleClick = () => doSave();
return hasError && <ErrorBanner />;

// Good: inline simple handler and explicit null branch
return hasError ? <ErrorBanner => doSave()} /> : null;

Checklist

• style.md was read first
• only relevant files were touched
• cleanup used subagents where it helped
• behavior was preserved
• skipped changes were intentional
• final summary explains what changed