复合工程任务分类与整理

工作流程

第1步：逐一呈现发现

对于每个发现，按以下格式呈现：

---
任务 #X：[简短标题]

严重程度：🔴 P1（严重）/ 🟡 P2（重要）/ 🔵 P3（可做可不做）

类别：[安全/性能/架构/缺陷/功能/其他]

描述：
[问题的详细说明或改进建议]

位置：[file_path:line_number]

问题场景：
[问题出错的逐步说明]

建议方案：
[如何修复]

预估工作量：小（< 2小时）/ 中（2-8小时）/ 大（> 8小时）

---
是否要将其添加到待办列表？
1. 是 - 创建待办文件
2. 下一个 - 跳过此项
3. 自定义 - 修改后再创建

第2步：处理用户决策

当用户说“是”时：

1. 更新现有待办文件（如果存在）或创建新文件名：

   如果待办已存在（来自代码审查）：

   • 将文件从 {id}-pending-{priority}-{desc}.md 重命名为 {id}-ready-{priority}-{desc}.md
   • 更新 YAML 前置元数据：status: pending → status: ready
   • 保留 issue_id、优先级和描述不变

   如果是创建新待办：

   {next_id}-ready-{priority}-{brief-description}.md
   

   优先级映射：

   • 🔴 P1（严重）→ p1
   • 🟡 P2（重要）→ p2
   • 🔵 P3（可做可不做）→ p3

   示例：042-ready-p1-transaction-boundaries.md

2. 更新 YAML 前置元数据：

   ---
   status: ready # 重要：从 "pending" 改为 "ready"
   priority: p1 # 或 p2、p3，取决于严重程度
   issue_id: "042"
   tags: [category, relevant-tags]
   dependencies: []
   ---
   

3. 填充或更新文件：

   # [问题标题]
   
   ## 问题描述
   [来自发现的描述]
   
   ## 发现
   - [关键发现]
   - 位置：[file_path:line_number]
   - [场景详情]
   
   ## 建议的解决方案
   
   ### 选项1：[主要方案]
   - **优点**：[好处]
   - **缺点**：[如果有缺点]
   - **工作量**：[小/中/大]
   - **风险**：[低/中/高]
   
   ## 推荐操作
   [在分类期间填写 - 具体的操作计划]
   
   ## 技术细节
   - **受影响的文件**：[列出的文件]
   - **相关组件**：[受影响的组件]
   - **数据库变更**：[是/否 - 如果为是，请描述]
   
   ## 资源
   - 原始发现：[该问题的来源]
   - 相关问题：[如果有]
   
   ## 验收标准
   - [ ] [具体的成功标准]
   - [ ] 测试通过
   - [ ] 代码已审查
   
   ## 工作日志
   
   ### {日期} - 批准工作
   **提交者：** Claude 分类系统
   **操作：**
   - 问题在分类会议中获批
   - 状态从 pending → ready 更改
   - 可被领取并开始处理
   
   **经验总结：**
   - [上下文和见解]
   
   ## 备注
   来源：在 {日期} 的分类会议
   

4. 确认批准： "✅ 已批准：{new_filename}（任务 #{issue_id}）- 状态：ready → 可以开始处理"

当用户说“下一个”时：

• 删除待办文件 - 由于不相关，从其当前位置移除
• 跳到下一项
• 记录跳过的项目以便总结

当用户说“自定义”时：

• 询问要修改的内容（优先级、描述、细节）
• 更新信息
• 呈现修改后的版本
• 再次询问：是/下一个/自定义

第3步：继续直到全部处理完毕

• 逐一处理所有项目
• 使用基于文件的待办事项（todos/ + /skill:file-todos）进行跟踪以实现可见性
• 不要在项目之间等待批准——持续推进

第4步：最终总结

所有项目处理完毕后：

## 分类完成

**总项目数：** [X] **已批准的待办（就绪）：** [Y] **已跳过：** [Z]

### 已批准的待办（可以开始处理）：

- `042-ready-p1-transaction-boundaries.md` - 事务边界问题
- `043-ready-p2-cache-optimization.md` - 缓存性能改进 ...

### 已跳过的项目（已删除）：

- 项目 #5：[原因] - 已删除
- 项目 #12：[原因] - 已删除

### 所做更改摘要：

在分类期间，进行了以下状态更新：

- **Pending → Ready：** 文件名和前置元数据已更新以反映已批准状态
- **已删除：** 已跳过发现的待办文件已移除
- 每个已批准的文件现在在 YAML 前置元数据中具有 `status: ready`

### 后续步骤：

1. 查看准备就绪的可处理待办：
   ```bash
   ls .context/compound-engineering/todos/*-ready-*.md todos/*-ready-*.md 2>/dev/null
   ```

2. 开始处理已批准的项目：

   /resolve-todo-parallel  # 同时处理多个已批准的项目
   

3. 或者选择单个项目进行处理

4. 在处理过程中，更新待办状态：

   • Ready → In Progress（在工作时的本地上下文中）
   • In Progress → Complete（重命名文件：ready → complete，更新前置元数据）

---

示例响应格式

---
任务 #5：多步骤操作缺少事务边界

严重程度：🔴 P1（严重）

类别：数据完整性 / 安全

描述：GoogleOauthCallbacks concern 中的 google_oauth2_connected 回调在没有事务保护的情况下执行多个数据库操作。如果任何步骤中途失败，数据库将处于不一致状态。

位置：app/controllers/concerns/google_oauth_callbacks.rb:13-50

问题场景：

1. User.update 成功（电子邮件已更改）
2. Account.save! 失败（验证错误）
3. 结果：User 的电子邮件已更改但没有关联的 Account
4. 下次登录尝试完全失败

没有事务的操作：

- 用户确认（第13行）
- 移除等待列表（第14行）
- 用户资料更新（第21-23行）
- 帐户创建（第28-37行）
- 头像附件（第39-45行）
- 旅程创建（第47行）

建议方案：将所有操作包裹在 ApplicationRecord.transaction do ... end 块中

预估工作量：小（30分钟）

---
是否要将其添加到待办列表？

1. 是 - 创建待办文件
2. 下一个 - 跳过此项
3. 自定义 - 修改后再创建

重要实现细节

分类期间的状态转换

选择“是”时：

1. 重命名文件：{id}-pending-{priority}-{desc}.md → {id}-ready-{priority}-{desc}.md
2. 更新 YAML 前置元数据：status: pending → status: ready
3. 使用分类批准条目更新工作日志
4. 确认："✅ 已批准：{filename}（任务 #{issue_id}）- 状态：ready"

选择“下一个”时：

1. 从其当前位置删除待办文件
2. 跳到下一项
3. 系统中不留文件

进度跟踪

每次将待办作为标题呈现时，请包含：

• 进度： X/Y 已完成（例如，“3/10 已完成”）
• 预计剩余时间： 根据推进速度估算
• 节奏： 监控每个发现的耗时并相应调整估算

示例：

进度：3/10 已完成 | 预计剩余时间：约 2 分钟

分类期间不编写代码

• ✅ 呈现发现
• ✅ 做出是/下一个/自定义的决策
• ✅ 更新待办文件（重命名、前置元数据、工作日志）
• ❌ 不要实现修复或编写代码
• ❌ 不要添加详细的实现细节
• ❌ 这属于 /resolve-todo-parallel 阶段

完成后，给出以下选项

接下来您想做什么？

1. 运行 /resolve-todo-parallel 来解决待办事项
2. 提交待办事项
3. 什么也不做，去休息