action-item-organizer
Systematic framework for extracting actionable items from documents and organizing them into prioritized, trackable checklists. Use when converting reports, meeting notes, audits, or any document with embedded action items into structured TODO lists.
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
[Skill 名] action-item-organizer
アクションアイテムオーガナイザー
このスキルは、非構造化ドキュメントから実行可能なアイテムを抽出し、それらを整理され、優先順位付けされ、追跡可能なチェックリストとして Markdown 形式に変換するための体系的なフレームワークを提供します。
このスキルを使用する場面
- コードレビューレポートをTODOリストに変換する
- 会議の議事録からアクションアイテムを抽出する
- 監査結果を改善チェックリストに整理する
- プロジェクト計画ドキュメントをタスクリストに分解する
- 課題レポートを実行可能な作業項目に構造化する
- 埋め込まれたアクションアイテムを含むあらゆるドキュメントから追跡可能なチェックリストを作成する
- チームのバックログを優先順位別に整理する
- スプリント計画チェックリストを作成する
核となる原則
1. コンテキストを保持した抽出
アクションアイテムは、チェックリストを読む人が誰でも以下の点を理解できるように、十分なコンテキストとともに抽出される必要があります。
- 何を行う必要があるか
- なぜそれが重要か
- どこに適用されるか(ファイル、システム、コンポーネント)
- 誰が責任者か
- いつ完了すべきか(優先順位と見積もり)
2. 優先順位に基づいた整理
緊急性と影響度に基づいてアイテムを整理するために、明確な優先順位フレームワークを使用します。
- P0 / Blockers: 進行、デプロイ、またはマージを妨げる重大な問題
- P1 / High Priority: 迅速な対応が必要な重要な品質、セキュリティ、または正確性に関する懸念
- P2 / Medium Priority: システムを強化する重要な改善とリファクタリング
- P3 / Low Priority: 将来の最適化、軽微な提案、およびあれば良い程度の機能強化
各優先順位レベル内で、関連するアイテムを論理的にグループ化します(例:セキュリティアイテムをまとめる、パフォーマンスアイテムをまとめる)。
3. 複雑なタスクのためのネストされた構造
複雑なアクションアイテムを階層的なチェックリストに分解します。
- 親アイテムは主要なタスクまたは目標を表します
- 子アイテムは特定のステップまたはサブタスクを表します
- 孫アイテムは詳細な実装ステップを表します
これにより、明確な実行パスが作成され、きめ細かな進捗追跡が可能になります。
4. トレーサビリティとメタデータ
アクションアイテムとそれらのソース間のリンクを維持します。
- ファイルパスと行番号
- 課題または追跡ID
- 所有者または担当チーム
- 時間見積もり
- ソースドキュメントからの元のコンテキスト
これにより、双方向のトレーサビリティと情報に基づいた優先順位付けが可能になります。
抽出ワークフロー
ステップ 1: ドキュメント分析
- ソースドキュメント全体を読みます
- 実行可能なコンテンツを含むセクションを特定します。
- "Action Items", "Todo List", "Recommendations"
- "Issues", "Findings", "Follow-ups"
- "Next Steps", "Tasks", "Requirements"
- ドキュメントの構造と慣例を理解します
ステップ 2: アクションアイテムの特定
以下のアイテムを抽出します。
- 実行可能: 完了できる具体的なタスク
- テスト可能: 明確な完了基準
- 割り当て済みまたは割り当て可能: 個人またはチームが所有できる
- コンテキストを含む: タスクを理解するのに十分な詳細が含まれている
以下のアイテムはスキップします。
- 純粋に情報的なもの(アクションを暗示しない限り)
- すでに完了しているもの
- 追加のコンテキストなしでは曖昧または不明確なもの
ステップ 3: メタデータ抽出
各アクションアイテムについて、以下を抽出します。
必須メタデータ:
- タスクの説明
- 優先順位レベル
オプションメタデータ(利用可能な場合のみ抽出):
- ファイルパスと行番号
- 所有者/担当者
- 時間見積もり
- 課題/追跡番号
- カテゴリまたはドメイン(セキュリティ、パフォーマンスなど)
- 実装ステップまたはサブタスク
ステップ 4: 優先順位分類
各アイテムを以下の基準に基づいて優先順位レベルに割り当てます。
P0 基準:
- デプロイまたはマージをブロックする
- 致命的なセキュリティ脆弱性
- データ損失または破損のリスク
- システム可用性への影響
- コンプライアンス違反
P1 基準:
- 重要なセキュリティ上の懸念
- 主要なパフォーマンスへの影響
- 機能に影響を与える正確性の問題
- 重要なアーキテクチャ上の問題
- 高い技術的負債
P2 基準:
- コード品質の改善
- 中程度の規模のリファクタリングの必要性
- テストカバレッジのギャップ
- ドキュメントの必要性
- 軽微なパフォーマンス最適化
P3 基準:
- コードスタイルと一貫性
- 将来の機能強化
- あれば良い程度の機能
- 軽微な最適化
- 探索的なタスク
ステップ 5: 階層的整理
ネストされたチェックリストを使用してアイテムを構造化します。
- [ ] **Category: Main task description** (#tracking-id)
- [ ] Sub-task 1
- [ ] Sub-task 2
- [ ] Detailed implementation step
- **File**: `path/to/file.ext:lines`
- **Owner**: Team/Person
- **Estimate**: Time estimate
- **Context**: Why this matters and what it achieves
ステップ 6: 要約生成
各優先順位セクションについて、以下を計算します。
- アイテムの総数
- 合計見積もり時間(利用可能な場合)
- 完了率(既存のチェックリストを追跡している場合)
ステップ 7: 出力フォーマット
以下の要素を含む構造化された Markdown ドキュメントを作成します。
- ヘッダー: タイトル、生成メタデータ、ソース参照
- 概要: すべての優先順位にわたる合計アイテム数と時間
- 優先順位セクション: P0、P1、P2、P3 とその要約
- 完了追跡: 下部に進捗メトリクス
チェックリスト形式の標準
基本的なチェックボックスアイテム
- [ ] Task description
メタデータ付きアイテム
- [ ] **Category: Task description** (#123)
- **File**: `src/file.js:45-67`
- **Owner**: Backend Team
- **Estimate**: 3 hours
- **Context**: Explanation of why this matters
ネストされたサブタスク
- [ ] **Security: Implement authentication** (#456)
- [ ] Add session validation
- [ ] Implement rate limiting
- [ ] Add authorization checks
- **File**: `api/auth.ts`
- **Owner**: Security Team
- **Estimate**: 8 hours
セクション要約
## P0 - Blockers (Must Fix Before Merge)
**Summary**: 5 items | 12 hours estimated
- [ ] Item 1...
- [ ] Item 2...
完全な出力テンプレート
# TODO List
> Generated from: [source-document.md]
> Date: YYYY-MM-DD HH:MM:SS
> Total Items: X | Total Estimated Hours: Y
## P0 - Blockers (Must Fix Before Merge)
**Summary**: N items | M hours estim 📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Action Item Organizer
This skill provides a systematic framework for extracting actionable items from unstructured documents and transforming them into well-organized, prioritized, trackable checklists in markdown format.
When to Use This Skill
- Converting code review reports into TODO lists
- Extracting action items from meeting notes
- Organizing audit findings into remediation checklists
- Breaking down project planning documents into task lists
- Structuring issue reports into actionable work items
- Creating trackable checklists from any document containing embedded action items
- Organizing team backlogs by priority
- Creating sprint planning checklists
Core Principles
1. Extraction with Context Preservation
Action items must be extracted with sufficient context so that anyone reading the checklist understands:
- What needs to be done
- Why it matters
- Where it applies (files, systems, components)
- Who is responsible
- When it should be completed (priority and estimates)
2. Priority-Based Organization
Use a clear priority framework to organize items by urgency and impact:
- P0 / Blockers: Critical issues that prevent progress, deployment, or merge
- P1 / High Priority: Significant quality, security, or correctness concerns requiring prompt attention
- P2 / Medium Priority: Important improvements and refactorings that enhance the system
- P3 / Low Priority: Future optimizations, minor suggestions, and nice-to-have enhancements
Within each priority level, group related items logically (e.g., security items together, performance items together).
3. Nested Structure for Complex Tasks
Break down complex action items into hierarchical checklists:
- Parent items represent the main task or goal
- Child items represent specific steps or sub-tasks
- Grandchild items represent detailed implementation steps
This creates a clear execution path and allows for granular progress tracking.
4. Traceability and Metadata
Maintain links between action items and their sources:
- File paths and line numbers
- Issue or tracking IDs
- Owner or responsible team
- Time estimates
- Original context from source document
This enables bidirectional traceability and informed prioritization.
Extraction Workflow
Step 1: Document Analysis
- Read the complete source document
- Identify sections containing actionable content:
- "Action Items", "Todo List", "Recommendations"
- "Issues", "Findings", "Follow-ups"
- "Next Steps", "Tasks", "Requirements"
- Understand the document structure and conventions
Step 2: Action Item Identification
Extract items that are:
- Actionable: Specific tasks that can be completed
- Testable: Clear completion criteria
- Assigned or assignable: Can be owned by a person or team
- Contextual: Include enough detail to understand the task
Skip items that are:
- Purely informational (unless they imply action)
- Already completed
- Vague or unclear without additional context
Step 3: Metadata Extraction
For each action item, extract:
Required Metadata:
- Task description
- Priority level
Optional Metadata (extract if available):
- File paths and line numbers
- Owner/responsible party
- Time estimate
- Issue/tracking numbers
- Category or domain (security, performance, etc.)
- Implementation steps or sub-tasks
Step 4: Priority Classification
Assign each item to a priority level based on:
P0 Criteria:
- Blocks deployment or merge
- Critical security vulnerability
- Data loss or corruption risk
- System availability impact
- Compliance violation
P1 Criteria:
- Significant security concern
- Major performance impact
- Correctness issues affecting functionality
- Important architectural problems
- High technical debt
P2 Criteria:
- Code quality improvements
- Moderate refactoring needs
- Test coverage gaps
- Documentation needs
- Minor performance optimizations
P3 Criteria:
- Code style and consistency
- Future enhancements
- Nice-to-have features
- Minor optimizations
- Exploratory tasks
Step 5: Hierarchical Organization
Structure items using nested checklists:
- [ ] **Category: Main task description** (#tracking-id)
- [ ] Sub-task 1
- [ ] Sub-task 2
- [ ] Detailed implementation step
- **File**: `path/to/file.ext:lines`
- **Owner**: Team/Person
- **Estimate**: Time estimate
- **Context**: Why this matters and what it achieves
Step 6: Summary Generation
For each priority section, calculate:
- Total number of items
- Total estimated hours (if available)
- Completion percentage (if tracking existing checklist)
Step 7: Output Formatting
Create a structured markdown document with:
- Header: Title, generation metadata, source reference
- Overview: Total items and time across all priorities
- Priority Sections: P0, P1, P2, P3 with summaries
- Completion Tracking: Progress metrics at the bottom
Checklist Format Standards
Basic Checkbox Item
- [ ] Task description
Item with Metadata
- [ ] **Category: Task description** (#123)
- **File**: `src/file.js:45-67`
- **Owner**: Backend Team
- **Estimate**: 3 hours
- **Context**: Explanation of why this matters
Nested Sub-tasks
- [ ] **Security: Implement authentication** (#456)
- [ ] Add session validation
- [ ] Implement rate limiting
- [ ] Add authorization checks
- **File**: `api/auth.ts`
- **Owner**: Security Team
- **Estimate**: 8 hours
Section Summary
## P0 - Blockers (Must Fix Before Merge)
**Summary**: 5 items | 12 hours estimated
- [ ] Item 1...
- [ ] Item 2...
Complete Output Template
# TODO List
> Generated from: [source-document.md]
> Date: YYYY-MM-DD HH:MM:SS
> Total Items: X | Total Estimated Hours: Y
## P0 - Blockers (Must Fix Before Merge)
**Summary**: N items | M hours estimated
- [ ] **Category: Task description** (#id)
- [ ] Sub-task
- **File**: `path/file.ext:lines`
- **Owner**: Team
- **Estimate**: X hours
- **Context**: Why this matters
## P1 - High Priority
**Summary**: N items | M hours estimated
[items...]
## P2 - Medium Priority
**Summary**: N items | M hours estimated
[items...]
## P3 - Low Priority / Future
**Summary**: N items | M hours estimated
[items...]
---
## Completion Tracking
- P0 Blockers: 0/N completed (0%)
- P1 High Priority: 0/M completed (0%)
- P2 Medium Priority: 0/K completed (0%)
- P3 Low Priority: 0/J completed (0%)
**Overall Progress**: 0/X tasks completed (0%)
Best Practices
Context Preservation
- Include enough detail that readers understand WHY each task matters
- Preserve the original rationale and justification
- Link to related issues or documentation
- Capture the impact of not completing the task
Logical Grouping
- Group related items within priority levels
- Use category prefixes (Security, Performance, Testing, etc.)
- Keep dependent tasks near each other
- Consider execution order in grouping
Actionability
- Each checkbox should be a clear, completable action
- Avoid vague tasks like "improve performance"
- Use specific verbs: implement, add, remove, refactor, fix
- Include success criteria when helpful
Traceability
- Always link back to source files and line numbers
- Include issue or tracking IDs
- Reference original documentation
- Enable bidirectional navigation
Completeness
- Verify all action items from source are included
- Preserve nested relationships
- Don't lose metadata in extraction
- Handle edge cases explicitly
Handling Edge Cases
Missing Priority
- Place in "Uncategorized" section at bottom
- Flag for review and prioritization
- Use context clues to infer if possible
Missing Metadata
- Use "TBD" markers for missing estimates
- Note "File: TBD" to prompt investigation
- Flag items with insufficient context
Conflicting Priorities
- Defer to explicit priority markers in source
- Consider impact and urgency
- Document rationale for priority assignment
Existing TODO Files
- Confirm before overwriting
- Consider timestamped filenames
- Merge with existing if appropriate
Multiple Sources
- Process each independently
- Or consolidate into single list with source markers
- Deduplicate when appropriate
Anti-Patterns to Avoid
Losing Context
Bad: - [ ] Fix bug
Good: - [ ] **Bug Fix: Handle null response in user fetch** (#789)
Flat Structure
Bad: Ten separate items for one complex task Good: One parent with nested sub-tasks
Missing Traceability
Bad: No file paths or line numbers Good: Always include location metadata
Vague Tasks
Bad: - [ ] Improve performance
Good: - [ ] **Performance: Add caching to user query** - reduces DB calls from 100/req to 1/req
Priority Inflation
Bad: Everything is P0 Good: Reserve P0 for true blockers
Examples
Example 1: Code Review Report to TODO
Input: Code review report with security findings
Output:
# TODO List
> Generated from: CODE_REVIEW_REPORT.md
> Date: 2025-12-09 10:30:00
> Total Items: 8 | Total Estimated Hours: 23
## P0 - Blockers (Must Fix Before Merge)
**Summary**: 2 items | 5 hours estimated
- [ ] **Security: Add authentication to token endpoint** (#1)
- [ ] Implement getServerSession check
- [ ] Add authorization verification
- [ ] Add rate limiting (10 req/min per IP)
- **File**: `app/api/livekit/token/route.ts:15-30`
- **Owner**: Backend Team
- **Estimate**: 4 hours
- **Context**: Public endpoint exposed without auth allows unauthorized access
- [ ] **Security: Remove hardcoded credentials** (#2)
- [ ] Remove fallback values from environment reads
- [ ] Add explicit validation for required credentials
- [ ] Fail fast if credentials missing at startup
- **File**: `experiments/livekit/src/index.ts:182-183`
- **Owner**: Backend Team
- **Estimate**: 1 hour
- **Context**: Hardcoded fallbacks create security risk in production
Example 2: Meeting Notes to Action Items
Input: Team meeting notes with scattered action items
Output:
# Action Items - Q4 Planning Meeting
> Generated from: team-meeting-2025-12-09.md
> Date: 2025-12-09 14:00:00
> Total Items: 12 | Total Estimated Hours: 45
## P1 - High Priority
**Summary**: 5 items | 20 hours estimated
- [ ] **Architecture: Design new API gateway** (#45)
- [ ] Research existing solutions (Kong, Tyk, AWS API Gateway)
- [ ] Document requirements and constraints
- [ ] Create comparison matrix
- [ ] Present findings to team
- **Owner**: Sarah
- **Estimate**: 8 hours
- **Context**: Current gateway hitting scale limits at 1000 req/s
- [ ] **Documentation: Update onboarding guide** (#46)
- [ ] Add sections on local development setup
- [ ] Document deployment process
- [ ] Add troubleshooting guide
- **Owner**: Mike
- **Estimate**: 4 hours
- **Context**: New engineers spending 2 days on setup
Reference Files
For detailed guidance on specific aspects of action item organization:
references/priority-framework.md: Comprehensive priority classification criteria with domain-specific examplesreferences/metadata-extraction-patterns.md: Detailed patterns for extracting different types of metadata from various document formatsreferences/TODO_LIST.template.md: TODO list template with priority-based organization (P0-P3), blocked tasks, and completion tracking
Load these references when you need deeper guidance on priority decisions or metadata extraction strategies.
Related Workflows
- Code review processes
- Sprint planning
- Issue triage
- Project management
- Audit remediation
- Meeting facilitation
- Documentation review