59 lines
2.7 KiB
Markdown
59 lines
2.7 KiB
Markdown
请对 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），每批执行前：
|
||
- 展示该批次的具体操作列表（源路径 → 目标路径、操作类型）
|
||
- 用提问工具获得用户确认
|
||
- 执行后确认目录结构完整，规范文件可正常读取
|