action-item-organizer

Action Item Organizer 是一个系统化框架，用于从非结构化文档中提取可执行事项，并将其转化为组织良好、按优先级排序、可追踪的 Markdown 待办清单。

适用场景

该技能适用于以下情况：将代码审查报告转换为 TODO 列表；从会议记录中提取行动项；将审计发现整理为整改清单；将项目规划文档拆解为任务列表；将问题报告结构化为可执行工作项；从任何包含嵌入式行动项的文档创建可追踪清单；按优先级组织团队待办积压；创建冲刺规划清单。

核心原则

带上下文保留的提取：行动项必须附带足够上下文被提取，使任何阅读清单的人都能理解需要做什么、为什么重要、适用于哪里（文件、系统、组件）、由谁负责、何时应完成（优先级与估时）。
基于优先级的组织：使用清晰的优先级框架按紧急性和影响组织事项。P0 / 阻塞项：阻止进展、部署或合并的关键问题；P1 / 高优先级：需要及时关注的重大质量、安全或正确性问题；P2 / 中优先级：提升系统的重要改进和重构；P3 / 低优先级：未来优化、次要建议和锦上添花的增强。在每个优先级内，按逻辑分组相关事项（如安全事项归在一起、性能事项归在一起）。
复杂任务的嵌套结构：将复杂行动项拆解为层级化清单。父项代表主任务或目标，子项代表具体步骤或子任务，孙项代表详细实现步骤。这创建了清晰的执行路径，并允许细粒度进度追踪。
可追溯性与元数据：维护行动项与其来源之间的链接，包括文件路径与行号、问题或追踪 ID、负责人或负责团队、时间估算、来自源文档的原始上下文。这支持双向追溯和知情的优先级排序。

提取工作流

第 1 步：文档分析。阅读完整源文档，识别包含可执行内容的章节（如“Action Items”“Todo List”“Recommendations”“Issues”“Findings”“Follow-ups”“Next Steps”“Tasks”“Requirements”），理解文档结构和约定。

第 2 步：行动项识别。提取可执行、可测试、可分配或可指派、带上下文的条目。跳过纯信息性（除非暗示行动）、已完成、或缺乏额外上下文而含糊不清的条目。

第 3 步：元数据提取。为每个行动项提取必需元数据（任务描述、优先级）和可选元数据（文件路径与行号、负责人、时间估算、问题/追踪编号、类别或领域、实现步骤或子任务）。

第 4 步：优先级分类。依据标准将每个事项分配到优先级。P0 标准：阻止部署或合并、关键安全漏洞、数据丢失或损坏风险、系统可用性影响、合规违规。P1 标准：重大安全问题、重大性能影响、影响功能的正确性问题、重要架构问题、高技术债。P2 标准：代码质量改进、中等重构需求、测试覆盖缺口、文档需求、次要性能优化。P3 标准：代码风格与一致性、未来增强、锦上添花的功能、次要优化、探索性任务。

第 5 步：层级化组织。使用嵌套清单组织事项，格式包含带追踪 ID 的主任务描述、子任务、更细的实现步骤，以及文件、负责人、估时、上下文等元数据。

第 6 步：摘要生成。为每个优先级章节计算总条目数、总估算小时数（如有）、完成百分比（如追踪现有清单）。

第 7 步：输出格式化。创建结构化 Markdown 文档，包含标题、生成元数据、来源引用、概述、P0–P3 优先级章节及摘要、底部完成度追踪。

清单格式标准

基本复选框项：- [ ] Task description。带元数据的项在主任务后附带 File、Owner、Estimate、Context。嵌套子任务使用缩进的复选框。章节摘要形如 **Summary**: 5 items | 12 hours estimated。

完整输出模板

模板包含标题区（来源文档、日期、总条目数与总估时）、P0 阻塞项（合并前必须修复）、P1 高优先级、P2 中优先级、P3 低优先级/未来，以及底部的完成度追踪，按各优先级列出已完成数与百分比和总体进度。

最佳实践

上下文保留：包含足够细节让读者理解每项任务为何重要，保留原始理由和依据，链接到相关问题或文档，记录未完成任务的影�响。逻辑分组：在优先级内分组相关事项，使用类别前缀（Security、Performance、Testing 等），保持依赖任务相邻，在分组时考虑执行顺序。可执行性：每个复选框应是清晰、可完成的行动，避免“improve performance”这类含糊任务，使用具体动词（implement、add、remove、refactor、fix），在有帮助时包含成功标准。可追溯性：始终链接回源文件和行号，包含问题或追踪 ID，引用原始文档，支持双向导航。完整性：验证源中所有行动项均被包含，保留嵌套关系，不在提取中丢失元数据，显式处理边界情况。

边界情况处理

缺少优先级：放入底部“Uncategorized”章节，标记待审查和优先级排序，尽可能用上下文线索推断。缺少元数据：对缺失估时使用“TBD”标记，注明“File: TBD”以提示调查，标记上下文不足的事项。优先级冲突：遵循源中的显式优先级标记，考虑影响和紧急性，记录优先级分配理由。已有 TODO 文件：覆盖前确认，考虑带时间戳的文件名，适当时与现有文件合并。多来源：分别独立处理，或合并为带来源标记的单一列表，适当时去重。

应避免的反模式

丢失上下文（如“- [ ] Fix bug”，应改为带类别、具体问题和追踪编号的完整描述）；扁平结构（复杂任务应使用一个父项加嵌套子任务，而非十个独立项）；缺少可追溯性（应始终包含位置元数据）；含糊任务（应给出具体数据和效果）；优先级通胀（P0 应仅保留给真正的阻塞项）。

示例

示例 1：代码审查报告转 TODO。输入为含安全发现的代码审查报告，输出为含 P0 阻塞项（如为 token 端点添加认证、移除硬编码凭证）及其子任务、文件路径、负责人、估时和上下文的 TODO 列表。

示例 2：会议记录转行动项。输入为含分散行动项的团队会议记录，输出为含 P1 高优先级项（如设计新 API 网关、更新入门指南）及其子任务、负责人、估时和上下文的清单。

参考文件

references/priority-framework.md：全面的优先级分类标准及领域特定示例。references/metadata-extraction-patterns.md：从各种文档格式提取不同类型元数据的详细模式。references/TODO_LIST.template.md：基于优先级组织（P0-P3）、包含阻塞任务和完成度追踪的 TODO 列表模板。在需要更深入的优先级决策或元数据提取策略指导时加载这些参考文件。

技能介绍