name: action-item-organizer description: 从文档中提取可执行项并将其组织成优先级明确、可追踪的检查清单的系统框架。适用于将报告、会议记录、审计报告或任何包含嵌入式可执行项的文档转换为结构化的待办事项列表。 author: Joseph OBrien status: unpublished updated: ‘2025-12-23’ version: 1.0.1 tag: skill type: skill

可执行项组织器

本技能提供了一个系统框架，用于从非结构化文档中提取可执行项，并将其转换为组织良好、优先级明确、可追踪的Markdown格式检查清单。

何时使用本技能

将代码审查报告转换为待办事项列表
从会议记录中提取可执行项
将审计发现组织成整改检查清单
将项目规划文档分解为任务列表
将问题报告构建为可执行的工作项
从任何包含嵌入式可执行项的文档创建可追踪的检查清单
按优先级组织团队待办事项列表
创建冲刺规划检查清单

核心原则

1. 提取并保留上下文

提取可执行项时必须保留足够的上下文，以便任何阅读检查清单的人都能理解：

需要做什么
为什么重要
适用于何处（文件、系统、组件）
谁负责
何时完成（优先级和预估时间）

2. 基于优先级的组织

使用清晰的优先级框架，按紧急性和影响程度组织项目：

P0 / 阻塞项：阻碍进展、部署或合并的关键问题
P1 / 高优先级：需要及时关注的重要质量、安全或正确性问题
P2 / 中优先级：增强系统的重要改进和重构
P3 / 低优先级：未来的优化、次要建议和锦上添花的增强功能

在每个优先级级别内，按逻辑对相关项目进行分组（例如，安全项放在一起，性能项放在一起）。

3. 复杂任务的嵌套结构

将复杂的可执行项分解为分层检查清单：

父项代表主要任务或目标
子项代表具体步骤或子任务
孙项代表详细的实施步骤

这创建了清晰的执行路径，并允许进行精细的进度跟踪。

4. 可追溯性和元数据

维护可执行项与其来源之间的链接：

文件路径和行号
问题或跟踪ID
负责人或责任团队
时间估算
源文档中的原始上下文

这实现了双向可追溯性和明智的优先级排序。

提取工作流程

步骤1：文档分析

阅读完整的源文档
识别包含可执行内容的部分：
- “可执行项”、“待办事项列表”、“建议”
- “问题”、“发现”、“后续事项”
- “下一步”、“任务”、“需求”
理解文档结构和约定

步骤2：可执行项识别

提取符合以下条件的项目：

可执行：可以完成的特定任务
可测试：明确的完成标准
已分配或可分配：可以由个人或团队负责
有上下文：包含足够细节以理解任务

跳过以下项目：

纯信息性内容（除非它们暗示了行动）
已完成的项目
没有额外上下文则模糊不清的项目

步骤3：元数据提取

对于每个可执行项，提取：

必需元数据：

任务描述
优先级级别

可选元数据（如果可用则提取）：

文件路径和行号
负责人/责任方
时间估算
问题/跟踪编号
类别或领域（安全、性能等）
实施步骤或子任务

步骤4：优先级分类

根据以下标准将每个项目分配到优先级级别：

P0 标准：

阻碍部署或合并
关键安全漏洞
数据丢失或损坏风险
系统可用性影响
合规性违规

P1 标准：

重大安全问题
主要性能影响
影响功能的正确性问题
重要的架构问题
高额技术债务

P2 标准：

代码质量改进
中等重构需求
测试覆盖缺口
文档需求
次要性能优化

P3 标准：

代码风格和一致性
未来增强功能
锦上添花的功能
次要优化
探索性任务

步骤5：分层组织

使用嵌套检查清单构建项目：

- [ ] **类别：主要任务描述** (#跟踪-id)
  - [ ] 子任务 1
  - [ ] 子任务 2
    - [ ] 详细实施步骤
  - **文件**：`路径/到/文件.ext:行号`
  - **负责人**：团队/个人
  - **估算**：时间估算
  - **上下文**：为什么重要以及它能实现什么

步骤6：摘要生成

对于每个优先级部分，计算：

项目总数
总估算小时数（如果可用）
完成百分比（如果跟踪现有检查清单）

步骤7：输出格式化

创建结构化的Markdown文档，包含：

标题：标题、生成元数据、来源引用
概述：所有优先级的项目总数和时间
优先级部分：P0、P1、P2、P3及其摘要
完成情况跟踪：底部的进度指标

检查清单格式标准

基本复选框项目

- [ ] 任务描述

带元数据的项目

- [ ] **类别：任务描述** (#123)
  - **文件**：`src/file.js:45-67`
  - **负责人**：后端团队
  - **估算**：3 小时
  - **上下文**：解释为什么重要

嵌套子任务

- [ ] **安全：实施身份验证** (#456)
  - [ ] 添加会话验证
  - [ ] 实施速率限制
  - [ ] 添加授权检查
  - **文件**：`api/auth.ts`
  - **负责人**：安全团队
  - **估算**：8 小时

部分摘要

## P0 - 阻塞项（合并前必须修复）

**摘要**：5 个项目 | 12 小时估算

- [ ] 项目 1...
- [ ] 项目 2...

完整输出模板

# 待办事项列表

> 生成自：[源文档.md]
> 日期：YYYY-MM-DD HH:MM:SS
> 总项目数：X | 总估算小时数：Y

## P0 - 阻塞项（合并前必须修复）

**摘要**：N 个项目 | M 小时估算

- [ ] **类别：任务描述** (#id)
  - [ ] 子任务
  - **文件**：`路径/文件.ext:行号`
  - **负责人**：团队
  - **估算**：X 小时
  - **上下文**：为什么重要

## P1 - 高优先级

**摘要**：N 个项目 | M 小时估算

[项目...]

## P2 - 中优先级

**摘要**：N 个项目 | M 小时估算

[项目...]

## P3 - 低优先级 / 未来

**摘要**：N 个项目 | M 小时估算

[项目...]

---

## 完成情况跟踪

- P0 阻塞项：0/N 完成 (0%)
- P1 高优先级：0/M 完成 (0%)
- P2 中优先级：0/K 完成 (0%)
- P3 低优先级：0/J 完成 (0%)

**总体进度**：0/X 任务完成 (0%)

最佳实践

上下文保留

包含足够的细节，让读者理解每个任务为什么重要
保留原始理由和依据
链接到相关问题或文档
捕获不完成任务的后果

逻辑分组

在优先级级别内对相关项目进行分组
使用类别前缀（安全、性能、测试等）
将依赖任务放在一起
在分组时考虑执行顺序

可执行性

每个复选框应是一个清晰、可完成的行动
避免模糊的任务，如“提高性能”
使用特定的动词：实施、添加、移除、重构、修复
在有用时包含成功标准

可追溯性

始终链接回源文件和行号
包含问题或跟踪ID
引用原始文档
实现双向导航

完整性

验证源文档中的所有可执行项都已包含
保留嵌套关系
不要在提取过程中丢失元数据
明确处理边缘情况

处理边缘情况

缺少优先级

放在底部的“未分类”部分
标记以供审查和优先级排序
如果可能，使用上下文线索推断

缺少元数据

对缺失的估算使用“待定”标记
注明“文件：待定”以提示调查
标记上下文不足的项目

优先级冲突

遵从源文档中的显式优先级标记
考虑影响和紧急性
记录优先级分配的理由

现有待办事项文件

覆盖前确认
考虑使用带时间戳的文件名
如果合适，与现有文件合并

多个来源

独立处理每个来源
或者合并到带有来源标记的单个列表中
适当时去重

应避免的反模式

丢失上下文

差：- [ ] 修复错误 好：- [ ] **错误修复：处理用户获取中的空响应** (#789)

扁平结构

差：一个复杂任务的十个独立项目好：一个父项包含嵌套子任务

缺少可追溯性

差：没有文件路径或行号好：始终包含位置元数据

模糊任务

差：- [ ] 提高性能 好：- [ ] **性能：为用户查询添加缓存** - 将数据库调用从 100/请求减少到 1/请求

优先级膨胀

差：所有都是P0 好：将P0保留给真正的阻塞项

示例

示例1：代码审查报告转待办事项

输入：包含安全发现的代码审查报告

输出：

# 待办事项列表

> 生成自：CODE_REVIEW_REPORT.md
> 日期：2025-12-09 10:30:00
> 总项目数：8 | 总估算小时数：23

## P0 - 阻塞项（合并前必须修复）

**摘要**：2 个项目 | 5 小时估算

- [ ] **安全：为令牌端点添加身份验证** (#1)
  - [ ] 实施 getServerSession 检查
  - [ ] 添加授权验证
  - [ ] 添加速率限制（每个IP 10 请求/分钟）
  - **文件**：`app/api/livekit/token/route.ts:15-30`
  - **负责人**：后端团队
  - **估算**：4 小时
  - **上下文**：未经验证的公共端点暴露允许未经授权的访问

- [ ] **安全：移除硬编码凭据** (#2)
  - [ ] 从环境变量读取中移除回退值
  - [ ] 为必需凭据添加显式验证
  - [ ] 如果启动时缺少凭据则快速失败
  - **文件**：`experiments/livekit/src/index.ts:182-183`
  - **负责人**：后端团队
  - **估算**：1 小时
  - **上下文**：硬编码回退在生产环境中造成安全风险

示例2：会议记录转可执行项

输入：包含分散可执行项的团队会议记录

输出：

# 可执行项 - Q4 规划会议

> 生成自：team-meeting-2025-12-09.md
> 日期：2025-12-09 14:00:00
> 总项目数：12 | 总估算小时数：45

## P1 - 高优先级

**摘要**：5 个项目 | 20 小时估算

- [ ] **架构：设计新API网关** (#45)
  - [ ] 研究现有解决方案（Kong、Tyk、AWS API Gateway）
  - [ ] 记录需求和约束
  - [ ] 创建比较矩阵
  - [ ] 向团队展示发现
  - **负责人**：Sarah
  - **估算**：8 小时
  - **上下文**：当前网关在 1000 请求/秒时达到规模限制

- [ ] **文档：更新入职指南** (#46)
  - [ ] 添加本地开发设置部分
  - [ ] 记录部署流程
  - [ ] 添加故障排除指南
  - **负责人**：Mike
  - **估算**：4 小时
  - **上下文**：新工程师花费 2 天进行设置

参考文件

有关可执行项组织特定方面的详细指导：

references/priority-framework.md：包含领域特定示例的全面优先级分类标准
references/metadata-extraction-patterns.md：从各种文档格式中提取不同类型元数据的详细模式
references/TODO_LIST.template.md：包含基于优先级的组织（P0-P3）、阻塞任务和完成情况跟踪的待办事项列表模板

当您需要关于优先级决策或元数据提取策略的更深层次指导时，请加载这些参考文件。