nbl-edit-rules

name	nbl.edit-rules
description	管理 rules/common/ 目录下规则文件的编辑，确保版本追踪和依赖一致性。 触发条件：用户请求修改规则、修改编码规范。

Edit Rules Skill

管理 rules/common/ 目录下规则文件的更新，确保版本追踪和依赖一致性。

激活时机

• 用户请求更新规则
• 修改编码规范
• 新增/修改命名规范

规则文件清单

文件	内容范围
architecture.md	分层架构原则、模块化设计、URI规范
naming.md	类命名、方法命名、参数命名规范
coding-conventions.md	Spring注入、数据持久化、工具类使用规范
coding-style.md	不可变性、文件组织、错误处理

执行流程

0. 确定 rules 目录位置 (NON-NEGOTIABLE)

按以下优先级查找 rules 目录，后续所有文件操作均基于此目录：

1. 如果当前项目根目录存在 rules/ 目录 → 使用 {项目根}/rules/
2. 否则 → 使用 ~/.claude/rules/

原则：项目级 rules 是源文件（有 Git 版本追踪），~/.claude/rules/ 是运行时副本（由 install-rules 安装）。编辑应优先改源文件。

1. 识别需要更新的规则文件

• 用户指定特定文件时，仅更新该文件
• 用户提供具体规则变更时，精确应用
• 用户新增规则时，确定合适的文件位置
• 用户修改现有规则时，定位并更新
• 尽可能保留现有格式和结构

2. 应用变更

根据用户输入应用变更：

$ARGUMENTS

3. 版本管理

每个规则文件维护独立版本号：vX.Y.Z

• MAJOR（主版本）：破坏性变更，需要修改现有项目代码
• MINOR（次版本）：新增规则或实质性扩展指导内容
• PATCH（补丁版本）：澄清说明、措辞调整、错别字修复

4. 一致性传播检查清单

• 读取 CLAUDE.md，确保 skills 定义与更新后的规则一致
• 读取 skills/**/* 文件，确保技能符合新规则
• 检查流程相关文件是否反映更新的流程

格式与风格要求

• 保持Markdown标题层级不变
• 长行控制在100字符以内，但不强制
• 各节之间保持单个空行
• 避免尾部空格
• 保留 "NON-NEGOTIABLE" 标记

规则精简原则

• 每条规则用一句话说清楚「做什么」和「禁止什么」，去掉解释性铺垫
• 禁止「错误示例」代码块，只保留最简「正确示例」（1-3行）
• 禁止重复已在 CLAUDE.md 中声明的信息，用引用代替
• 表格仅用于枚举型数据（字段列表、映射关系），简单规则用列表

反向示例（禁止）

## 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)