deslop

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

接收刚编写完成的代码，让它变得更紧凑、简洁、更具设计感。

请首先阅读 style.md，该文件是风格规则的唯一可信来源。

Process

流程

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.
Read each target file before editing it.
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.
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
Review the subagent output, apply the changes, then do a final sanity pass yourself.
Summarise the cleanup in concrete terms.
- Example: "flattened 3 nested conditionals, renamed 2 booleans, replaced 1 non-null assertion"

确定目标文件
- 从本次会话中修改过的文件开始处理
- 若可用则使用
```
git diff
```
  ，否则使用最近编辑记录或用户明确给出的文件列表
- 不要修改无关文件
编辑每个目标文件前先通读全文
清理阶段使用并行Subagent
- 若存在多个文件，将它们拆分给不同的Subagent处理
- 若只有一个大文件，也可以使用单个Subagent执行独立的二次走查
- 给每个Subagent分配明确的负责文件列表
- 如果处理范围只有1-3个小文件，单次处理即可，不要为了机械满足规则强行增加Subagent的开销
要求每个Subagent执行以下操作：
- 阅读
```
skills/deslop/style.md
```
- 仅简化分配给它的文件
- 完全保留代码原有行为
- 跳过所有只会增加改动量但不会提升代码清晰度的修改
- 提交简短的变更总结，说明修改了什么内容、哪些内容是刻意跳过的
审核Subagent的输出，应用变更，然后自行执行最终的合理性校验
用具体的内容总结清理结果
- 示例：「扁平化了3层嵌套条件判断，重命名了2个布尔变量，替换了1个非空断言」

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.

绝对不要修改代码行为，这是风格调整流程，不是重构
若风格规则和保留行为冲突，以保留行为为准
优先做小规模的局部修改，而非大范围重写
如果代码只有经过深度架构重构才能得到明显的优化，停止操作并告知用户，不要强行执行超出范围的deslop操作
跳过生成文件、vendor代码、构建产物和lockfile
跳过测试文件，除非用户明确要求包含
若应用某条规则会让代码更难读，跳过该规则
保留导出的公共API，除非用户明确要求修改API
保留导出的TypeScript签名，除非用户明确要求修改类型或API
如果代码已经足够简洁，直接告知用户即可，不要强行做修改

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

使用守卫子句替代嵌套条件判断
使用
```
if
```
加提前返回替代
```
else
```
无重新赋值的场景下用
```
const
```
替代
```
let
```
用类型收窄或直接移除替代
```
!
```
非空断言
用
```
Boolean(value)
```
或显式比较替代
```
!!value
```
使用更清晰的布尔变量名，比如
```
isOpen
```
、
```
hasItems
```
、
```
canRetry
```
更短小的、职责单一的函数
拆分出辅助函数，简化编排逻辑的主函数
查询/数据收集逻辑和操作/副作用逻辑分离
函数名如实描述其副作用
拆分过载的hook或组件，抽离小型纯辅助函数
使用对象参数替代长位置参数列表
对可辨识联合做穷尽处理
使用提前返回扁平化React渲染分支
逻辑仅使用一次时用内联JSX处理函数
处理函数在多处复用时保留提升定义的写法

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;
}

tsx

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

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

// Bad: 嵌套控制流和不必要的else
function getLabel(user?: User) {
  if (user) {
    if (user.name) {
      return user.name;
    } else {
      return "Anonymous";
    }
  } else {
    return "Anonymous";
  }
}

// Good: 提前返回，扁平化流程
function getLabel(user?: User) {
  if (!user?.name) return "Anonymous";
  return user.name;
}

tsx

// Bad: 仅使用一次的处理函数被提升，且使用&&渲染
const handleClick = () => doSave();
return hasError && <ErrorBanner onRetry={handleClick} />;

// Good: 简单处理函数内联，显式返回空分支
return hasError ? <ErrorBanner onRetry={() => 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

已首先阅读
```
style.md
```
仅修改了相关文件
有帮助的场景下使用了Subagent
代码行为完全保留
所有跳过的修改都是刻意为之
最终总结清晰说明了变更内容