format

dotnet format

使用所选 .NET SDK 自带的格式化工具。保留仓库当前的格式化工具职责、已有更改和已配置的样式，不要引入新的偏好。

诊断输出预算

保留警告/错误及简洁的结果；避免例行的冗长或诊断性控制台输出。运行测试时保留原生进度/ANSI 输出。如果失败，仅显示相关诊断和堆栈帧，并去重；每次响应最多 80 行 / 8 KiB。只有在问题仍未解决时，才在模型上下文之外、大小受限的文件中收集额外诊断；提供链接并检查精确的有限摘录。绝不要转储完整日志/报告，也不要通过筛选隐藏命令退出代码。

工作流程

1. 阅读最近的 AGENTS.md、global.json、解决方案/项目文件、.editorconfig 和当前 Git 状态。
2. 确认要加载的确切可信工作区。dotnet format 可能会从该工作区还原、编译并运行分析器。
3. 判断请求是只读验证，还是允许应用修复。对于审查、说明或诊断请求，不要运行会修改内容的命令。
4. 格式化前保留当前差异。如果范围不明确，先使用 --verify-no-changes 或较窄的 --include 列表。
5. 选择与请求相符的最小格式化范围：
   • whitespace：用于缩进、空格和行尾规则；
   • style：用于内置 .NET 代码样式诊断；
   • analyzers：用于可修复的非样式分析器诊断；
   • 仅当计划处理所有适用范围时，才使用不带子命令的命令。
6. 将 --include 和 --exclude 的值视为相对于工作区的文件或目录路径，而非 shell 通配符。使用 --diagnostics 按规则 ID 缩小样式或分析器修复范围。
7. 执行修改操作后，检查 git diff --stat、有代表性的差异、行尾以及每个已更改文件。如果范围意外扩大，停止并缩小命令范围；绝不要丢弃用户已有更改。
8. 使用 --verify-no-changes 重新运行对应命令。应用分析器修复后，还要构建并运行与更改行为相关的测试。

不变条件

• .editorconfig 和现有的 MSBuild 分析器配置是事实来源。除非用户要求，否则不要添加任意样式模板。
• 仅在依赖项已成功还原后使用 --no-restore。
• 除非仓库明确负责生成文件并对其进行格式化，否则生成文件应保持排除状态。
• 格式化工具进程成功并不能证明每项诊断都有自动修复。请检查其输出或 JSON 报告，并以构建/分析器结果作为最终依据。
• 如果 CSharpier、ReSharper 清理工具、生成代码工具或其他格式化工具并存，请明确各自的职责。

参考资料

• 有关本地、CI、筛选和故障排查命令的详情，请阅读 references/commands.md。
• 如果要更改 .editorconfig、分析器严重级别或格式化工具职责，请阅读 references/config.md。