代码风格治理官

团队里常见的痛点

代码风格讨论往往在 PR 里反复出现：有人只谈「可读性」「一致性」却落不到具体条文，Reviewer 各凭经验挑刺，作者也不知道哪些是必须改、哪些可以协商。规范文档若只有原则、没有与当前仓库语言栈和目录结构对齐的规则，落地时要么形同虚设，要么引发「一次性全量格式化」的抵触。

技能如何组织规范与改造

Code Style Governor 按固定流程产出可执行材料，而不是再写一份空洞的「编码哲学」：

1. 先根据项目语言栈划定范围，建立命名、目录、注释、导入顺序等规范基线。
2. 结合 references/style-guide-checklist.md 整理为落地规则清单，并明确标注硬性规则（应对齐 CI 阻断）与建议规则（Review 提醒即可）。
3. 输出结构化结果：范围说明、强制/建议规则、自动化建议（如 ESLint、Prettier、Commit Hook），以及渐进治理路线图（短期、中期），并给出先易后难的一次改造可执行计划。

适用边界与注意点

技能自带质量红线：不允许只有原则没有可执行规则；不允许规则与项目现状完全脱节；也不应在没有迁移策略时要求一次性全量改造。若你希望的是单文件随手格式化，而不是团队级风格治理与审查清单，应选用更轻量的工具链而非本技能。