在已有项目中检测并遵循项目专属编码约定（命名、结构、风格）

加入已有代码库或生成新代码前，先分析现有模式再匹配，避免强加通用规范。

适用场景

解决思路

1. 先观察再强制：在分析现有代码库之前绝不强加约定；已有 200 个 internal sealed class 处理器的项目不应新增 public class 处理器，先检测再匹配。
2. 项目约定优先于通用规则：若项目用 *Service 而非 *Handler，就遵循项目约定，即使工具包默认不同；显式的 .editorconfig 和 Directory.Build.props 规则永远优先。
3. 用 MCP 工具做分析：get_public_api 揭示命名模式，get_project_graph 展示结构约定，detect_antipatterns 跟踪质量趋势；工具提供客观数据，读文件用于确认。
4. 记录发现：检测到约定后，建议将其加入项目的 CLAUDE.md；未记录的约定会在原开发者离开后丢失。
5. 一致性优于完美：一致的 snake_case 数据库列胜过一半 snake_case 一半 PascalCase；匹配现有模式，即使另一种约定理论上更优。
6. 第 1 步 项目结构分析：运行 get_project_graph，检测项目命名（PascalCase？带点？MyApp.Domain vs Domain）、分层组织（按层 Domain/Application/Infrastructure 还是按功能）、测试项目命名（*.Tests、*.UnitTests、*.IntegrationTests）、共享项目（Common/、Shared/、BuildingBlocks/）。
7. 第 2 步 类型命名模式：对不同层的 3-5 个关键类型运行 get_public_api，检测类修饰符（sealed？internal？internal sealed？）、接口前缀（I* 还是无前缀）、后缀约定（Handler、Service、Repository、Validator、Endpoint）、record 用法（用于 DTO？值对象？命令/查询？）、主构造函数用法（一致使用还是选择性使用）。
8. 第 3 步 文件夹结构模式：扫描文件系统检测结构约定——功能文件夹 Features/{FeatureName}/ 是否把所有文件放一起、分层文件夹 Controllers/、Services/、Repositories/ 是否分离、共享模式 Common/、Extensions/、Middleware/、配置位置（根目录？Config/？Infrastructure/？）。
9. 第 4 步 配置检测：查找 Directory.Build.props（TreatWarningsAsErrors、Nullable 全局启用、ImplicitUsings、AnalysisLevel）、.editorconfig（命名规则如 camelCase 字段、_ 前缀私有字段；代码风格如 var 偏好、表达式体、using 位置）、global.json（SDK 版本是否固定、roll-forward 策略）。
10. 第 5 步 构建约定摘要：将发现编译为结构化摘要，包含命名（如类为 internal sealed class 占 95%、Handler/Validator 后缀、record 用于 DTO 和命令/查询）、结构（如垂直切片架构、Features/{Name}/ 单文件包含 command/handler/validator/endpoint）、代码风格（如主构造函数一致用于 DI 注入、Nullable 全局启用无 ! 抑制、file-scoped namespace 100% 一致），并按需添加 EF Core、测试等类别。
11. 生成代码时匹配每个检测到的模式：若现有处理器是 internal sealed class + 主构造函数，就生成 internal sealed class CreateProductHandler(AppDbContext db, TimeProvider clock)，而非 public class 或缺少 sealed；若现有 DTO 是带 init 属性的 record，就生成 public record ProductResponse(Guid Id, string Name, decimal Price)，而非带 get;set; 的 class。
12. 审查代码时标记偏离检测约定的地方：例如提示 CreateOrderHandler 是 public class 但项目约定是 internal sealed class（12/12 现有处理器均如此），并给出修改建议。
13. 建议强制规则：检测到约定后，建议用 .editorconfig 规则自动强制，如 dotnet_diagnostic.CA1852.severity = warning（密封内部类型）、csharp_style_namespace_declarations = file_scoped:warning、csharp_style_prefer_primary_constructors = true:suggestion，若检测到私有字段 _camelCase 前缀则添加 dotnet_naming_rule 条目。
14. 用 detect_antipatterns 跟踪反复出现的质量问题：定期以 scope: solution 运行，跟踪同一模式是否反复出现（DateTime.Now 不断出现）、是否出现新模式（新模块中的 new HttpClient()）、数量趋势上升还是下降。
15. 对反模式排优先级：用表格列出反模式、数量、趋势、优先级，例如 DateTime.Now 12 次 ↑+3 高（加入 CLAUDE.md 约定）、async void 1 次 → 持平 中（一次性修复）、new HttpClient 0 次 ↓-2 低（已在修复）。
16. 当模式反复出现时，向 CLAUDE.md 添加显式规则，例如「NEVER use DateTime.Now — Use TimeProvider.GetUtcNow()（发现 12 处违规，修复中）」。
17. 避免未检测就强制：不要对已有自己约定的项目强加工具包默认值（如声称所有处理器都应是 internal sealed class，而项目实际用 public class + 接口便于测试）；应先 get_public_api 发现 8/8 处理器是 public class 实现 IHandler<T>，再匹配该约定。
18. 避免覆盖显式项目规则：不要因工具包规定而忽略 .editorconfig（如 .editorconfig 说 csharp_style_expression_bodied_methods = false 却仍生成表达式体方法）；.editorconfig 和 Directory.Build.props 永远优先。
19. 避免把通用约定套用到非常规项目：不要对垂直切片项目强加 Clean Architecture 命名（如要求 Services/ 和 Repositories/ 文件夹）；应匹配项目组织约定，把新功能加到 Features/Shipping/ 并让相关文件放在一起。
20. 避免无证据地记录约定：不要基于读一个文件就声称「约定：到处用 var」；应基于多个文件确认，例如对 5 个类型运行 get_public_api 确认 100% 对非显而易见情况用显式类型，再记录「非显而易见情况（如方法返回值）用显式类型，显而易见情况（如 new MyClass()）用 var，已在 5 个文件中确认」。
21. 决策指南：加入已有项目→运行完整约定检测流程（get_project_graph、get_public_api）；生成新代码→先检查已检测约定；审查代码→标记约定偏离（get_public_api + 对比）；工具包与项目冲突→项目优先；团队分歧→记录两者并建议 .editorconfig；未检测到约定→用工具包默认并记录（architecture-advisor 技能）；反复反模式→加入 CLAUDE.md（detect_antipatterns）；新成员入职→运行检测并生成约定文档；存在 .editorconfig→信任它不要覆盖；无 .editorconfig→基于检测模式建议创建；模式只出现一次→通过 instinct-system 技能以 0.3 置信度创建 instinct；模式确认 3 次以上→instinct 自动提升到 0.7，建议加入 CLAUDE.md。

适用边界 · 注意事项

• 项目已有明确且显式的约定文件（.editorconfig、Directory.Build.props）时，不要用工具包默认值覆盖它们。
• 不要基于单个文件或单次观察就记录约定，必须有跨多个文件的证据。
• 不要对采用非常规组织方式（如垂直切片架构）的项目强加通用架构命名（如 Clean Architecture 的 Services/、Repositories/）。