de-slop

去除低质产物

AI 辅助开发会留下三类低质产物。代码低质产物能够编译，但读起来像机器生成的。产品低质产物虽然发布了，但对付费客户来说仍显得不完善。文案低质产物带有 AI 写作痕迹：浮夸表达、习惯性使用破折号、聊天机器人套话，以及缺乏鲜明立场的中性措辞。此技能会清除这三类问题。默认清理代码低质产物。--product 会增加产品检查。prose 会执行文案检查。ui 只执行设计系统检查。

此技能会编辑并删除代码，因此需要经过确认门槛，并优先处理分支差异。若只需只读检查并标记问题，请使用 structural-review / /review。若要遵循分层文档标准（Diátaxis、STE、Global English），请使用 technical-writing，然后应用此处的文案目录。

其他需要文案目录的技能会引用 references/prose-slop.md，但不会触发此技能。

约定

输入：

• 要清理的包、仓库或文案内容；可选范围（--changed、all、dry-run）和维度（--product、ui、prose）。

输出：

• 已应用的编辑（若使用 dry-run，则输出按类别整理的拟修改报告），以及按类型统计的已移除产物数量简报。

创建/修改：

• 编辑源文件或指定文案。绝不删除入口文件、配置文件或 README。

外部副作用：

• 除本地文件编辑外，没有其他副作用。代码编辑后会运行类型检查和测试。

需要确认：

• 扫描整个代码树（all）之前，或重写意图不明确的产品文案之前。

委派给：

• 在结构性低质产物清除后，交给 polish 进行最后的细节润色。
• 若修复属于真正的重构，而非机械式清理，则交给 refactor-code。
• 若需求涉及文档、RFC、README、PR 或提交规范，而非清理低质产物，则交给 technical-writing。

代码低质产物（默认）

按照文件现有风格进行清理：

1. 控制台语句 → 项目日志记录器。
2. any 类型 → 真实类型，或 unknown + 类型守卫。
3. 未使用的导入项 / 变量 → 删除。
4. 已注释掉的代码 → 删除（git 会保留历史记录）。
5. 调试代码 / 临时代码 → 删除遗留的 TODO/FIXME 调试行。
6. 多余的注释 — 删除那些只重述做什么的注释；保留解释为什么的注释。
7. 不必要的防御性检查 — 对确定不会失败的可信内部路径，移除 try-catch 和空值守卫；对真正的外部边界则保留守卫。
8. 嵌套过深 — 将层层嵌套的 if/else 金字塔改为提前返回。

文案低质产物（prose）

当第一个参数为 prose，或目标是回复、README、RFC、PR 描述、提交信息或其他写作内容时，请应用 references/prose-slop.md。

1. 扫描 31 种模式。
2. 重写内容。保留含义，符合预期语气。
3. 增添灵魂：表达观点、调整节奏、加入具体事实。
4. 自我审查：“哪些地方显然是 AI 生成的？”修复剩余痕迹。

--product 清理文案时也会运行此目录。如果预期文案不明确，不要擅自编造产品语气；应标记出来。

产品低质产物（--product）

这一层用于判断应用是否完善。完整的“错误 → 正确”目录请参见 references/product-slop.md；问题分为三类：

• 文案 — 营销填充语、泛泛的 AI 式措辞、毫无帮助的空状态和错误消息。对每条文案都运行文案目录。
• UI — 原封不动的 shadcn 加紫色渐变风格、不一致的间距 / 圆角，以及未设置样式或完全缺失的加载和错误状态。
• UX — 按钮没有实际功能、流程走到死胡同、看似正式的导航后面却是占位页面，以及缺少验证或成功反馈的表单。

清理产品低质产物需要判断，而不只是删除。遇到任何不明确之处都应标记，而不是猜测预期文案或行为。

UI 糟粕（ui）

当第一个参数为 ui 时，仅运行 UI 检查。不要先运行代码清理工作流。

不要在此技能中编写特定于组件的样式规则。应从目标项目中推导这些规则。

在评判审美之前，先检查本地权威来源：

• 设计文档、令牌、主题文件、CSS 变量、Tailwind 配置或同类内容。
• 共享 UI 基元，例如卡片、按钮、输入框、对话框、表格、标签页、导航、徽章、工具提示、菜单和加载状态。
• 同一应用或程序包中三个相近的优质示例。
• 目标屏幕／组件代码，以及可用时的渲染结果。

创建一份简短的工作清单：

• 已批准的令牌及间距／圆角／阴影模式。
• 共享基元及其变体。
• 已审查界面的 UI 角色映射：基元、已记录的配方，或缺失。
• 已达到生产就绪水平的本地示例。
• 受影响的目标文件和路由。

针对已审查界面上的每种 UI 角色，确定项目是否提供共享基元或已记录的配方：

• 表面、卡片、面板。
• 按钮或操作。
• 链接或导航。
• 输入框、选择框、文本区域。
• 复选框、单选框、开关。
• 徽章或状态。
• 模态框、对话框、抽屉、弹出框、工具提示。
• 表格、列表、网格。
• 标签页或分段控件。
• 空状态、加载状态、错误状态。
• 应用外壳、导航、布局区块。

如果存在基元：

• 使用该基元，而不是原始 HTML、复制的标记或本地样式。
• 仅使用其公开的属性、变体、插槽和有文档说明的组合模式。
• 不要在调用处覆盖其核心视觉约定：背景、边框、圆角、阴影、字体排版、间距、焦点、禁用、加载或状态样式。
• 如果所需变体不存在，只有在需求明确且可复用时才向基元添加命名变体。否则记录问题并暂缓处理。

如果不存在基元：

• 遵循有文档说明的设计配方或最有代表性的相近本地模式。
• 如果同一配方反复出现，建议提取为基元或命名变体。
• 除非用户明确要求定制设计，否则不要自行设计一次性的视觉处理方式。

原始语义化 HTML 可用于文档结构和正文。如果原始 HTML 被用作设计系统控件或界面表面，则不应使用。

先修正客观的设计系统偏差，再处理主观审美问题。将更改限制在已审查界面范围内；对于需要产品判断的事项，应记录具体问题并暂缓处理，而不是擅自揣测意图。

工作流

1. 路由模式 — ui 运行 UI 检查后停止。prose 运行文案检查目录后停止。--product 在代码糟粕检查后追加产品和文案检查。

2. 识别结构 — 判断是单体仓库还是单个程序包（ls packages/ 2>/dev/null）。分别处理每个程序包。

3. 限定范围 — 在 --changed 模式下，将编辑限制在分支差异范围内：

   BASE="$(git merge-base HEAD origin/HEAD 2>/dev/null || git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)"
   git diff --name-only "$BASE"..HEAD    # files this branch touched
   

   仅修改这些文件／代码块；在此模式下，不要清理其他位置原有的糟粕。

4. 剔除上述类别中的内容。

5. 验证 — 代码更改必须仍能构建并通过：

   bun run type-check || bunx tsc --noEmit
   bun run test
   

6. 记录 — 如果当前仓库存在会话日志，则记录已清理的程序包及各类型的数量。

模式

• default — 检查代码糟粕，处理当前程序包并应用更改。
• ui — 运行 UI／设计系统基元检查。
• prose — 仅运行文风特征检查目录。
• --changed — 仅处理此分支引入的文件／代码块（最适合 PR）。
• --product — 追加产品糟粕检查（文案／UI／UX）和文案检查目录。
• all — 扫描单体仓库中的所有程序包，分别处理每个程序包。
• dry-run — 仅检测；按类型分组并统计报告所有产物，不做任何修改。可与任何范围选项组合。

反模式

• 本应限定分支范围，却清理了整个目录树 — --changed 能让 PR 保持易于审查；修改整个目录树前需要确认。
• 删除副作用导入（CSS、polyfill）或关键文件 （README、配置文件、入口文件）。
• 因为「为什么」注释看起来多余就将其删除 — 只有重复说明 做什么 的注释才应删除。
• 猜测产品文案或预期行为 — 如果产品文案含糊不清，应标记出来交由用户处理，而不是自行编造修复方案。
• 打着清理的旗号重写逻辑 — 行为变更属于重构（refactor-code），而不是去除冗余。
• 清理之后留下毫无生气的文字 — 生硬的文字依然是冗余。