re0-style

修复指定的变更或一组文件，使其符合代码仓库现有的约定，只更改风格，不改动其他内容。

目标

某次会话中编写的代码，往往会偏离周围代码的风格：引号样式不同、命名大小写不同、导入顺序不同，抛出错误的方式也不同于上一个项目。这样一来，读者就得琢磨每处差异是否意味着什么。re0-style 会让指定范围内的代码与相邻代码保持一致。它完全依据仓库自身的约定：先遵循项目配置的格式化工具和 linter，再参照相邻文件的惯例处理工具无法决定的部分，并就地应用修复，同时保持行为不变。如果仓库内部存在两种并行的约定，它会先询问，而不是擅自选择。最终结果是仅包含风格更改的差异，以及按文件和规则列出的每项更改报告。

工作流

1. 明确范围。 指明变更（工作区差异，或与用户指定基准版本的差异），或用户给出的文件列表。对于变更，范围单位是已更改的行：变更未涉及的文件不在范围内，已涉及文件中未更改的行也不在范围内。现在按项目清单、任务运行器或 CI 工作流指定的命令运行一次项目测试，并记录结果，以免将原有故障归咎于本次检查。
2. 排除非仓库自有内容。 在此技能的文件夹中，对范围内的文件运行 node scripts/scope.mjs <files...> [--json]。该命令会逐个文件列出 linguist-generated 和 linguist-vendored 属性、文件前几行中的生成文件标头、格式化工具和代码检查工具的关闭标记及其行号，以及从文件所在文件夹到仓库根目录适用的样式配置文件；退出码 0 表示没有文件被标记，3 表示有一个或多个文件被标记，2 表示用法错误或输入无法读取。发现标记只是需要查看的线索，并非结论：确实为生成或 vendored 的文件应从范围中排除；所有关闭标记覆盖的区域都保持原样。
3. 查看工具的判定依据。 根据第 2 步列出的配置，以及项目清单、脚本、锁文件、CI 工作流和 pre-commit 配置，列出仓库运行的格式化工具和代码检查工具及其选项。通过项目自身的解析方式（npm exec、bun run、./node_modules/.bin/、uv run、poetry run、固定的工具链）解析每个工具，打印即将运行的版本（通过同一解析方式运行工具的 --version），并与锁文件或清单声明的版本进行比较。版本不匹配，或工具只能通过全局二进制文件或临时安装使用时，应停止对该工具进行修复，并在报告中说明。
4. 查看工具无法判定的事项。 对范围引出的、没有已配置工具可以判定的每个问题（按类别区分标识符大小写、导入分组和顺序、文件和文件夹布局、导出风格、错误的抛出方式和措辞），抽查相邻文件，从最近的开始：同一文件夹中的文件，然后是仓库其他位置同类型的文件。统计每种模式出现的次数。如果几乎所有抽查样例都遵循某种模式，且例外看起来是偏离惯例的个别情况（散落在不同位置的单个文件，且通常较新），则该模式就是惯例。如果另一种模式占据整个文件夹或模块，或反复出现在无法视为偏离惯例的多个文件中，则仓库在这些位置保留了两种惯例；记录两种模式各自的数量及所在位置。如果无法判断，则按两种惯例处理并提出问题。文件夹自身一致的惯例优先于仓库其他部分采用的惯例。
5. 应用工具修复。 仅对范围内的文件运行格式化工具，然后运行代码检查工具的修复模式；只应用工具标记为安全的修复。对于变更，先对每个文件的基准版本运行格式检查（通过 git show <base>:<path> 将其读入临时副本）：如果基准版本已经格式正确，格式化整个文件只会改动变更内容；如果基准版本不符合格式要求，则只保留已更改行内的编辑（使用工具的范围选项，或保留与这些行重叠的代码块），并报告遗留的原有偏差。若用户要求配置仓库尚未采用的格式化工具或代码检查工具，则配置其生态系统和项目清单已指向的工具，按第 4 步发现的代码风格设置各项选项，并且仅对范围内的内容运行；报告工具仍会改动的范围外内容，绝不应用这些改动。
6. 应用手动修复。 修复剩余的代码检查问题，并在范围内修正每项偏离第 4 步惯例的情况，同时保持行为不变。重命名局部或私有标识符时，也要重命名它的所有引用。若重命名会影响公共 API（被其他模块或软件包导入的导出项、CLI 标志、配置键、路由、序列化字段），则在报告中提出，并列出会受影响的所有调用方；只有用户确认后才能应用。若某项代码检查问题只能通过逻辑变更解决，则保留原样并在报告中说明。
7. 指出惯例分歧。 对于第 4 步发现存在两种惯例的每个位置，保持代码原样，并在报告中提出问题：说明两种模式、各自数量、各自所在位置，以及等待答复的范围内代码行。无需因此停止本轮检查；后续检查轮次再根据答复处理。
8. 验证并报告，如下所述。

规则

• 每条约定都必须来自仓库：仓库保留的配置（包括该配置明确扩展的已发布风格指南），或仓库自身文件一贯遵循的模式。绝不采用外部风格指南、某种语言广为采用的默认规范，或仓库本身未遵循的个人偏好。
• 仅处理用户指定的范围，或用户调用的流水线传入的范围。绝不重新排版未触及的文件或行，也绝不扩大范围；在范围外发现的偏差应报告，不要修复。
• 运行每个工具时，都必须通过项目自身的解析方式调用，并打印其版本进行比较；全局二进制文件或临时安装是不同的工具链，其检查结果不能代表项目的检查结果。
• 仅调整风格。不得更改值、条件、调用、控制流或公开名称。保留会在加载时运行代码的导入项（polyfill、注册项、样式表）的原有顺序，因为移动它们会改变行为。
• 绝不擅自从两种相互冲突的约定中选择一种；应将分歧及各自的数量作为问题交给用户。
• 遵守仓库的保护规则：生成文件和供应商文件，以及格式化工具或 linter 的关闭标记覆盖的所有区域，都必须保持不变。
• 交由其他处理流程负责的内容应移交：散文和注释中的标点（破折号交给 dedash，韩语间隔点交给 dedot），以及冗长的散文或没有实际作用的代码（死代码、复述代码内容的注释）交给 debloat。在报告中列出每项移交，不要自行处理。
• 如果某项检查未发现违反约定的内容，则不做任何更改。
• 安全地编辑：更改前确认每个目标都存在，并将未找到的目标报告为 MISS，不得静默跳过；以 UTF-8 编码读写文件，且不改变换行符；逐处替换，不做一概而论的批量替换；大规模机械性更改应使用脚本。

验证

完成前，确认：

1. 通过项目自身的解析方式运行格式化工具和 linter，确认被修改的文件均符合规范；或者列出它们仍报告的每一项问题，并说明保留该问题的原因。
2. 项目测试结果与步骤 1 中的运行结果一致。
3. 差异中的每个文件都在范围内，且每个差异块都对应一项已报告的更改：逐块对照差异和仅调整风格的规则。
4. 每项分歧都附有各模式的数量；除非用户已确认，否则应提出公开名称的更名建议，不得直接更名。

按文件和规则报告每项更改（注明工具的规则 ID，或列出据以判定的约定及数量），然后说明未处理的内容：作为问题提出并附上数量的分歧、只有更改逻辑才能解决的问题、建议的公开名称更改、范围外的偏差、工具版本不匹配，以及每项移交。