Menü
管理 rules/common/ 目录下规则文件的编辑，确保版本追踪和依赖一致性。 触发条件：用户请求修改规则、修改编码规范。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | nbl.edit-rules |
| description | 管理 rules/common/ 目录下规则文件的编辑，确保版本追踪和依赖一致性。 触发条件：用户请求修改规则、修改编码规范。 |
管理 rules/common/ 目录下规则文件的更新，确保版本追踪和依赖一致性。
| 文件 | 内容范围 |
|---|---|
architecture.md | 分层架构原则、模块化设计、URI规范 |
naming.md | 类命名、方法命名、参数命名规范 |
coding-conventions.md | Spring注入、数据持久化、工具类使用规范 |
coding-style.md | 不可变性、文件组织、错误处理 |
按以下优先级查找 rules 目录，后续所有文件操作均基于此目录：
rules/ 目录 → 使用 {项目根}/rules/~/.claude/rules/原则：项目级 rules 是源文件（有 Git 版本追踪），~/.claude/rules/ 是运行时副本（由 install-rules 安装）。编辑应优先改源文件。
根据用户输入应用变更：
$ARGUMENTS
每个规则文件维护独立版本号：vX.Y.Z
CLAUDE.md，确保 skills 定义与更新后的规则一致skills/**/* 文件，确保技能符合新规则## Spring依赖注入规范 (NON-NEGOTIABLE)
- **推荐方式**: 使用Lombok的`@RequiredArgsConstructor`注解配合`final`字段实现构造器注入
- **禁止**: 使用`@Autowired`字段注入、使用`@Resource`字段注入
- **适用范围**: 所有Spring管理的Bean，包括Controller、Service、Manager、Job等
- **必选依赖**: 所有需要注入的依赖必须声明为`final`字段
// 正确示例（完整类骨架）
// 错误示例（完整类骨架）
## Spring依赖注入
- 使用`@RequiredArgsConstructor` + `final`字段，禁止`@Autowired`/`@Resource`
- 适用：所有Spring Bean（Controller、Service、Manager、Job等）
用户: /update-rules 在 naming.md 中添加新的枚举命名规范
Agent:
# 规则更新报告
## 更新文件
- rules/common/naming.md (v1.0.0 → v1.1.0)
## 变更内容
### 新增规则
- 枚举类命名规范：字典类枚举必须使用 `XxxEnum` 格式命名
## 依赖检查
- ✅ CLAUDE.md 已验证
- ✅ agents/planner.md 已验证
- ⚠ skills/springboot-patterns/SKILL.md 可能需要同步更新
## 建议提交消息
docs: 新增枚举命名规范 (naming.md v1.1.0)
Use when executing implementation plans with independent tasks in the current session
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when you have a spec or requirements for a multi-step task, before touching code
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when creating new skills, editing existing skills, or verifying skills work before deployment