规则不是写给领导看的
我见过把整本编码规范贴进 Rules 的——Agent 未必吃得下，自己也懒得维护。我的原则是：只写我会重复念叨的那几条。
个人偏好举例：用中文回复、改完说明怎么验证、别擅自提交、别碰 .env。项目级再补目录约定和硬性禁止事项。
我分层放规则
用户级
解释风格、语言、我个人的审查习惯。换仓库也带着走。
项目级
目录结构、禁止提交的文件、测试要求。跟仓库一起共享。
路径级
前端 / 后端约束不同时再用。不是每个项目都需要。
什么值得写成 Skill
Skills 适合「固定流程」：发 PR 检查清单、一类 Bug 的排查步骤。偶发一次的事，直接在对话里说更快，没必要封装。
- 回答用简体中文，先给结论再展开
- 控制器放 app/controller，视图放 view/
- 不要提交 .env、密钥；不要乱动无关锁文件
- 改 UI 后说明桌面和手机分别怎么看
- 未经要求不要 git commit / push维护规则的小习惯
- 同一句话我说了三遍，就考虑写进 Rules
- 规则失效或总被违反，就改措辞，别堆更长
- 项目专属约定优先进仓库，方便同事和未来的自己