action-item-organizer

アクション項目オーガナイザー

このスキルは、構造化されていないドキュメントから実行可能な項目を抽出し、適切に整理され、優先順位が付けられ、追跡可能な Markdown 形式のチェックリストに変換するための体系的なフレームワークを提供します。

このスキルを使用する場面

• コードレビューのレポートを TODO リストに変換する
• 議事録からアクション項目を抽出する
• 監査結果を修正チェックリストに整理する
• プロジェクト計画書をタスクリストに分解する
• 問題の報告を実行可能な作業項目に構成する
• アクション項目を含むあらゆるドキュメントから、追跡可能なチェックリストを作成する
• チームのバックログを優先度別に整理する
• スプリント計画のチェックリストを作成する

基本原則

1. 文脈を保持した抽出

チェックリストを読む人が誰でも理解できるよう、アクション項目は十分な文脈を添えて抽出する必要があります。

• 何を実施する必要があるか
• なぜ重要なのか
• どこに適用されるのか（ファイル、システム、コンポーネント）
• 誰が担当するのか
• いつ完了すべきか（優先度と見積もり）

2. 優先度に基づく整理

緊急度と影響度に基づいて項目を整理するため、明確な優先度の枠組みを使用します。

• P0 / ブロッカー：進行、デプロイ、またはマージを妨げる重大な問題
• P1 / 高優先度：迅速な対応が必要な、品質、セキュリティ、または正確性に関わる重大な懸念事項
• P2 / 中優先度：システムを改善する重要な改良やリファクタリング
• P3 / 低優先度：将来の最適化、軽微な提案、あると望ましい改善

各優先度内では、関連項目を論理的にまとめます（例：セキュリティ関連の項目、パフォーマンス関連の項目）。

3. 複雑なタスクの階層構造

複雑なアクション項目は、階層型チェックリストに分解します。

• 親項目は、メインタスクまたは目標を表します
• 子項目は、具体的な手順またはサブタスクを表します
• 孫項目は、詳細な実装手順を表します

これにより、明確な実行手順が示され、進捗を細かく追跡できます。

4. トレーサビリティとメタデータ

アクション項目とその出典との関連を維持します。

• ファイルパスと行番号
• 課題またはトラッキング ID
• 担当者または担当チーム
• 所要時間の見積もり
• 元のドキュメントにおける文脈

これにより、双方向のトレーサビリティと、根拠に基づいた優先順位付けが可能になります。

抽出ワークフロー

ステップ 1：ドキュメントの分析

1. 元のドキュメントを最後まで読む
2. 実行可能な内容を含むセクションを特定する：
   • 「アクション項目」、「ToDo リスト」、「推奨事項」
   • 「問題」、「調査結果」、「フォローアップ」
   • 「次のステップ」、「タスク」、「要件」
3. ドキュメントの構造と慣例を把握する

ステップ 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 ドキュメントを作成します。

1. ヘッダー：タイトル、生成メタデータ、参照元
2. 概要：すべての優先度における項目数と所要時間
3. 優先度セクション：概要付きの P0、P1、P2、P3
4. 完了状況の追跡：末尾に進捗指標

チェックリスト形式の標準

基本的なチェックボックス項目

- [ ] 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 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%)

ベストプラクティス

コンテキストの保持

• 読者が各タスクの重要性を理解できるだけの詳細を記載します
• 元の根拠や正当性を保持します
• 関連する課題やドキュメントへのリンクを記載します
• タスクを完了しなかった場合の影響を記録します

論理的なグループ化

• 優先度レベル内で関連する項目をグループ化します
• カテゴリーの接頭辞（Security、Performance、Testing など）を使います
• 依存関係のあるタスクを近くに配置します
• グループ化の際に実行順序を考慮します

実行可能性

• 各チェックボックスは、明確で完了可能なアクションにします
• 「パフォーマンスを改善する」のような曖昧なタスクは避けます
• implement、add、remove、refactor、fix など、具体的な動詞を使います
• 有用な場合は、成功の基準を含めます

追跡可能性

• 常に元のファイルと行番号へのリンクを記載します
• 課題 ID または追跡 ID を含めます
• 元のドキュメントを参照します
• 双方向のナビゲーションを可能にします

完全性

• 元の資料にあるすべてのアクション項目が含まれていることを確認します
• ネストされた関係を保持します
• 抽出時にメタデータを失わないようにします
• エッジケースを明示的に扱います

エッジケースの処理

優先度がない場合

• 最下部の「Uncategorized」セクションに配置します
• レビューと優先度付けが必要であることを明示します
• 可能であれば、文脈から推測します

メタデータがない場合

• 不明な見積もりには「TBD」マーカーを使います
• 調査を促すため、「File: TBD」と記載します
• 文脈が不十分な項目を明示します

優先度が競合する場合

• 元の資料に明示された優先度を優先します
• 影響と緊急性を考慮します
• 優先度を割り当てた根拠を記録します

既存の TODO ファイルがある場合

• 上書きする前に確認します
• タイムスタンプ付きのファイル名を検討します
• 適切であれば、既存の内容とマージします

複数のソースがある場合

• それぞれを個別に処理します
• または、ソースマーカーを付けて単一のリストに統合します
• 適切な場合は重複を削除します

避けるべきアンチパターン

コンテキストの喪失

悪い例：- [ ] Fix bug
良い例：- [ ] **Bug Fix: Handle null response in user fetch** (#789)

フラットな構造

悪い例：1 つの複雑なタスクを 10 個の独立した項目に分ける
良い例：親項目 1 つの下にサブタスクをネストする

追跡可能性の欠如

悪い例：ファイルパスや行番号がない
良い例：常に場所のメタデータを含める

曖昧なタスク

悪い例：- [ ] Improve performance
良い例：- [ ] **Performance: Add caching to user query** - DB 呼び出しを 1 リクエストあたり 100 回から 1 回に削減

優先度の過剰な引き上げ

悪い例：すべてを P0 にする
良い例：P0 は本当に作業を妨げる項目に限定する

例

例 1：コードレビュー報告書から TODO への変換

入力：セキュリティ上の指摘を含むコードレビュー報告書

出力：

# 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

例 2：会議メモからアクションアイテムを抽出

入力：アクションアイテムが散在しているチーム会議のメモ

出力：

# 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

参照ファイル

アクションアイテムの整理に関する具体的な項目の詳しいガイダンスについては、以下をご覧ください。

• references/priority-framework.md：分野固有の例を含む、優先度分類基準の詳細
• references/metadata-extraction-patterns.md：さまざまなドキュメント形式から異なる種類のメタデータを抽出するための詳細なパターン
• references/TODO_LIST.template.md：優先度別の整理（P0-P3）、ブロック中のタスク、完了状況の追跡に対応した TODO リストのテンプレート

優先度の判断やメタデータ抽出の方法について、さらに詳しいガイダンスが必要な場合は、これらの参照資料を読み込んでください。

関連ワークフロー

• コードレビューのプロセス
• スプリント計画
• 課題のトリアージ
• プロジェクト管理
• 監査指摘事項の是正
• 会議の進行
• ドキュメントレビュー