name: ctx-add-convention description: “记录一项编码规范。当某个重复出现的模式需要被规范化，以确保所有会话都一致遵循时使用。” allowed-tools: Bash(ctx:*)
在 CONVENTIONS.md 文件中记录一项编码规范。
何时使用
- 当某个模式已被使用 2-3 次且需要标准化时
- 当建立命名、格式或结构规则时
- 当新贡献者需要了解“我们在这里如何做事”时
- 当用户说“将其规范化”或“使其成为一项规范”时
何时不使用
- 一次性实现细节（请改用代码注释）
- 涉及权衡的架构决策（使用
/ctx-add-decision） - 调试见解或注意事项（使用
/ctx-add-learning） - 已由代码检查器或格式化工具强制执行的规则
收集信息
规范比决策或学习更简单。你需要：
- 名称：该规范叫什么？（例如，“CLI标志使用短横线命名法”）
- 规则：规则是什么？一个清晰的句子。
- 章节：它属于 CONVENTIONS.md 中的哪个章节？（例如，“命名”、“输出”、“测试”）
如果用户只提供了描述，请根据主题推断章节。首先检查 CONVENTIONS.md 中的现有章节以将其正确放置——如果现有章节合适，则不要创建新章节。
如果该规范与现有规范重叠，请提及： “函数命名已有一个规范。您希望我将其添加在旁边还是更新现有规范？”
执行
ctx add convention "所有CLI标志名称使用短横线命名法" --section "命名"
ctx add convention "CLI输出使用 cmd.Printf/cmd.Println，绝不使用 fmt.Printf/fmt.Println" --section "输出"
ctx add convention "测试文件与实现文件放在一起（*_test.go 放在 *.go 旁边）" --section "测试"
如果未提供 --section，则该规范将附加到文件末尾。建议指定章节以便组织。
质量检查清单
记录前，请验证：
- [ ] 规则足够清晰，不熟悉的人也能遵循
- [ ] 它是本项目特定的（不是通用的 Go/JS 等规则）
- [ ] 它尚未存在于 CONVENTIONS.md 中（请先检查）
- [ ] 章节与现有章节匹配，或者确实需要新章节
- [ ] 它描述的是一个模式，而不是一次性的选择（那是决策）
确认规范已添加。