请对 openspec/specs/ 下所有规范文件进行审查和整理，按以下流程执行。

## 约束

- 规范描述"应该是什么"，不含实现细节（具体文件路径、代码引用）和变更记录（ADDED/MODIFIED、"移除以下列"等措辞）
- 每批重构操作执行前用提问工具获得用户确认
- 仅删除内容已完全覆盖在其他规范中的冗余规范，非冗余内容仅迁移/合并/重命名

## 1. 收集

并行读取以下内容：
- `openspec/specs/` 每个子目录的 `spec.md`
- 项目源码（backend/、frontend/），理解实际实现
- `openspec/config.yaml`，了解项目约束

## 2. 审查

将每个规范与代码和命名约定对比，按以下维度逐项检查：

| 维度 | 检查点 |
| ---- | ------ |
| 过时 | 描述的功能/组件是否仍存在于代码；引用的路径、类名、API 是否一致；交互流程是否匹配当前实现 |
| 重复 | 不同规范是否描述同一组件/功能/场景（场景级或概念级） |
| 错位 | 场景是否放错了功能域；Requirement 是否归属错误的规范 |
| 合并 | 同一主题是否分散在多个规范；某个规范是否是另一个的子集 |
| 命名 | 是否准确反映内容；是否符合命名约定（见下）；是否暴露可搜索的业务关键词 |
| 格式 | 是否使用 SHALL/WHEN/THEN；是否混入变更记录或实现细节；是否有空目录 |

### 命名约定

| 类型 | 模式 | 示例 |
| ---- | ---- | ---- |
| 平台专属 | `{平台}-{功能}` | admin-platform、console-my-skills |
| 跨平台组件 | `{类别}` | component-library、layout-system |
| 技能领域 | `skill-{方面}` | skill-market、skill-status-rules |
| 业务功能 | `{业务名词}` | account-management、chat-scenarios |

命名原则：统一平台前缀（admin-/console-/developer-）、统一领域前缀（skill-）、2-3 词、避免泛化词（display/basic/general/info/data）和实现模式词（crud/list/table）。

## 3. 报告

输出分析结果：

1. **问题总览表**：问题类型 × 涉及规范数
2. **逐项分析**：每个有问题的规范，说明具体问题和建议（涉及文件、冲突点、推荐操作）
3. **重构方案**：按优先级分批：
   - P0：删除空目录和完全冗余规范
   - P1：合并重复/子集规范到主规范
   - P2：重命名不精准的规范、拆分错位内容
   - P3：修正与代码不匹配的描述、清理实现细节和变更记录
4. **重构后目录结构**：预期的新 specs/ 目录树

## 4. 执行

逐批执行重构（P0→P3），每批执行前：
- 展示该批次的具体操作列表（源路径 → 目标路径、操作类型）
- 用提问工具获得用户确认
- 执行后确认目录结构完整，规范文件可正常读取