kairo-tasks

目的

設計文書に基づいて実装タスクを1日単位の粒度で分割し、1ヶ月単位のフェーズに整理する。各タスクを個別ファイルで作成し、依存関係を考慮した適切な順序で管理する。

前提条件

docs/design/{要件名}/ に設計文書が存在する
設計がユーザによって承認されている（または承認が省略されている）
docs/tasks/ ディレクトリが存在する（なければ作成）
思考は英語で実施。ファイルは日本語で記述
task_id は TASK-{4桁の数字} (例 TASK-0001)にする

context

出力ディレクトリ="docs/tasks" 要件名={{requirement_name}} 作業規模={{work_scope}} 信頼性評価=[]

step

$ARGUMENTS がない場合、「引数に要件名を指定してください（例: ユーザー認証システム）」と言って終了する
$ARGUMENTS の内容と context の内容をまとめてユーザに宣言する
step2 を実行する

step2: 作業規模の確認

AskUserQuestion ツールを使って作業規模を質問する：
- question: "このタスク分割の作業規模について教えてください"
- header: "作業規模"
- multiSelect: false
- options:
  - label: "詳細タスク分割（推奨）" description: "詳細な実装手順、包括的なテストケース、完全な依存関係分析、UI/UX要件含む"
  - label: "軽量タスク分割" description: "必要最小限のタスク定義、基本的な実装手順のみ、主要な依存関係のみ"
  - label: "カスタム" description: "含めたい項目を個別に選択"
ユーザーの選択を context の {{work_scope}} に保存
カスタムを選択した場合は、AskUserQuestion ツールを使って以下を質問：
- question: "タスク定義に含める項目を選択してください（複数選択可）"
- header: "含める項目"
- multiSelect: true
- options:
  - label: "詳細な実装手順" description: "ステップバイステップの実装ガイド"
  - label: "包括的なテストケース" description: "単体・統合テストの詳細な定義"
  - label: "UI/UX要件の詳細化" description: "ローディング状態・エラー表示・モバイル対応等"
  - label: "依存関係の詳細分析" description: "タスク間の依存関係の詳細な分析"
step3 を実行する

step3: 開発コンテキストの準備

タスクノートの読み込み
- docs/spec/{要件名}/note.md が存在する場合は読み込み
- 存在しない場合:
  - Task ツールを使用して subagent_type: "general-purpose" で /tsumiki:kairo-tasknote {要件名} コマンドを実行してノートを生成
  - 生成されたノートファイルを読み込み
- ノートには技術スタック、開発ルール、関連実装、設計文書、注意事項が含まれる
追加ルールの読み込み
- docs/rule ディレクトリが存在する場合は読み込み
- docs/rule/kairo ディレクトリが存在する場合は読み込み
- docs/rule/kairo/tasks ディレクトリが存在する場合は読み込み
- 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用
技術スタック定義の読み込み
- docs/tech-stack.md が存在する場合は読み込み
- 存在しない場合は CLAUDE.md から技術スタックセクションを読み込み
- どちらも存在しない場合は .claude/commands/tech-stack.md のデフォルト定義を使用
要件定義・設計文書の読み込み
- docs/spec/{要件名}-requirements.md または docs/spec/{要件名}/requirements.md を読み込み
- docs/design/{要件名}/architecture.md を読み込み
- docs/design/{要件名}/database-schema.sql を読み込み
- docs/design/{要件名}/api-endpoints.md を読み込み
- docs/design/{要件名}/interfaces.ts を読み込み
- docs/design/{要件名}/dataflow.md を読み込み
- 読み込んだ技術スタック定義に基づいて実装技術を特定
既存タスクファイルの確認
- @agent-symbol-searcher で既存タスクIDを検索し、見つかったタスクファイルをReadツールで読み込み
- 既存のdocs/tasks/{要件名}-TASK-*.mdファイルをReadツールで読み込み
- 使用済みタスク番号（TASK-0000形式）を抽出
- 新規タスクで重複しない番号を割り当て
step4 を実行する

step4: タスク分析とヒアリング

作業規模に応じてヒアリング項目を調整。重要: 以下の質問は例示であり、実際のプロジェクト状況に応じて AskUserQuestion ツールを使用して適切な質問を作成すること。

詳細タスク分割の場合

以下のカテゴリごとに、設計文書から特定した具体的な課題・不明点について AskUserQuestion ツールで質問する：

タスク粒度の確認

1日単位（8時間）のタスク粒度で問題ないか確認
より細かい分割が必要な場合は具体的な単位を質問

例: AskUserQuestion ツールで以下のように質問

question: "タスクの粒度について、1日（8時間）単位で問題ないでしょうか？"
header: "タスク粒度"
multiSelect: false
options:
- label: "1日単位で問題ない" description: "8時間単位のタスク分割"
- label: "より細かい分割が必要" description: "半日（4時間）単位など、より細かい分割（その他で詳細を記入）"

実装優先順位の確認

設計文書の実装順序について確認が必要な場合質問
並行実行可能なタスクの優先順位について質問
フェーズ分割の基準について質問

技術的制約の確認

技術スタックの選択について確認が必要な場合質問
パフォーマンス要件の実装方法について質問
外部システム連携のタイミングについて質問

テスト要件の詳細化

単体テストのカバレッジ目標について質問
統合テストの実施範囲について質問
E2Eテストの実施タイミングについて質問

UI/UX実装の詳細確認

ローディング状態の実装方針について質問
エラー表示の詳細について質問
モバイル対応の範囲について質問
アクセシビリティ要件の詳細について質問

軽量タスク分割の場合

必須項目のみ確認 AskUserQuestion ツールを使って、以下の項目について簡潔に質問:

主要なタスクの実行順序の確認
基本的な依存関係の確認
最低限のテスト要件確認

カスタムの場合

step2 で選択した項目に関連するヒアリングのみ実施。 AskUserQuestion ツールを使って、選択された項目に応じた質問を作成する。

注意事項:

すべての質問を一度に投げるのではなく、文脈に応じて段階的に質問する
ユーザーの回答を受けて、必要に応じて追加質問を行う
質問は具体的で、はい/いいえで答えられるか、選択肢から選べる形式にする
自由記述が必要な場合は「その他」オプションを用意する

ヒアリング記録の作成:

すべての質問と回答を記録する
各質問について、以下を記録：
- 質問内容
- 質問日時
- カテゴリ（タスク粒度/優先順位/技術制約/テスト要件/UI要件）
- 質問の背景（なぜこの質問が必要だったか）
- ユーザーからの回答
- 信頼性への影響（この回答により信頼性レベルがどう変化したか）
ヒアリング結果のサマリーを作成
step5 を実行する

step5: タスク作成

【重要】: このステップでは、洗い出したすべてのタスクファイルを作成する必要があります。途中で止めないでください。

【信頼性レベル指示】: 各項目について、元の資料（要件定義書・設計文書・ユーザヒアリング含む）との照合状況を以下の信号でコメントしてください：

🔵 青信号: 要件定義書・設計文書・ユーザヒアリングを参考にしてほぼ推測していない場合
🟡 黄信号: 要件定義書・設計文書・ユーザヒアリングから妥当な推測の場合
🔴 赤信号: 要件定義書・設計文書・ユーザヒアリングにない推測の場合

5.1 タスクの洗い出し

設計文書に基づいて、以下のカテゴリでタスクを洗い出す：

基盤タスク（DB設定、環境構築など）
バックエンドタスク（API実装）
フロントエンドタスク（UI実装）
- 画面のグループ毎に細かく分割する
統合タスク（E2Eテストなど）

洗い出しの記録:

洗い出したタスクの総数を記録する
各カテゴリごとのタスク数を記録する
この総数が、step5.6で作成するファイル数と一致する必要がある

5.2 依存関係の分析

タスク間の依存関係を明確化
並行実行可能なタスクを識別
クリティカルパスを特定

5.3 タスクの詳細化

各タスクに以下を含める：

タスクID（TASK-0000形式）
タスク名
タスクタイプ（TDD/DIRECT）
- TDD: コーディング、ビジネスロジック実装、UI実装、テスト実装など開発作業
- DIRECT: 環境構築、設定ファイル作成、ドキュメント作成、ビルド設定など準備作業
要件へのリンク
依存タスク
実装詳細（信頼性レベル付き）
単体テスト要件（信頼性レベル付き）
統合テスト要件（信頼性レベル付き）
UI/UX要件（該当する場合、信頼性レベル付き）
- ローディング状態
- エラー表示
- モバイル対応
- アクセシビリティ要件
タスク全体の信頼性レベル評価

5.4 タスクの順序付け

依存関係に基づいて実行順序を決定
マイルストーンを設定
並行実行可能なタスクをグループ化

5.5 フェーズ分割

各タスクを1日単位の粒度で設計
タスクを1ヶ月(20日想定)以内の期間でフェーズに分割
- フェーズは180時間以内を目標にする
- フェーズの分割はアーキテクチャのレイヤーを基準にする
- 事前検討した分割基準を前提としない

5.6 個別タスクファイルの作成

重要: 各タスクを個別ファイルで作成
必須: step5.1で洗い出したすべてのタスクファイルを作成する（途中で止めない）
フェーズ別並列処理: フェーズ毎にTaskツールを使い、複数フェーズを並列実行して効率的にファイルを作成する
作業規模に応じた <task_template> を選択：
- 詳細タスク分割: <full_task_template>
- 軽量タスク分割: <minimal_task_template>
- カスタム: 選択項目に応じた組み合わせ
作成プロセス:
1. step5.1で洗い出した全タスクリストを確認
2. 洗い出した全タスク情報（タスクID、タスク名、タイプ、工数、フェーズ、依存関係、実装詳細、テスト要件等）をフェーズ別に整理
3. フェーズ毎に並列でTaskツールを実行 (1つのメッセージで複数のTask tool callsを送信):
  - Phase 1タスク用のTask tool call
  - Phase 2タスク用のTask tool call
  - Phase 3タスク用のTask tool call
  - Phase 4タスク用のTask tool call
  - (フェーズ数に応じて調整)
4. 各Task tool callには以下を含む詳細なプロンプトを指定：
  - 該当フェーズのタスクリスト（タスク番号、タスク名、タイプ、依存関係等）
  - 各タスクの詳細情報（実装詳細、テスト要件、UI/UX要件等）
  - 使用するテンプレート（<full_task_template>または<minimal_task_template>）
  - ファイル出力先: docs/tasks/{要件名}/TASK-XXXX.md
  - 信頼性レベルの付与ルール
  - 注意事項: "このフェーズのすべてのタスクファイルを作成すること。途中で止めないこと。"
5. すべてのTaskツールの実行完了を待つ
6. 作成されたファイル数と洗い出したタスク数が一致することを確認
各タスクファイルには以下を含める：
- タスク全体の信頼性レベル（🔵🟡🔴）
- 実装詳細の各項目に信頼性レベル（🔵🟡🔴）
- テスト要件の各項目に信頼性レベル（🔵🟡🔴）
- ファイル末尾に信頼性レベルサマリー
- 関連文書へのリンク（overview、要件定義、設計文書）
チェックポイント:
- 洗い出したタスク数: {N}件
- 作成したファイル数: {N}件
- フェーズ別作成数の確認（Phase 1: X件, Phase 2: Y件, ...）
- すべてのタスクファイルが作成されたことを確認

重要:

各Taskツールに渡すプロンプトには、該当フェーズの全タスクの完全な情報を含めること
エージェントが追加のコンテキスト収集なしで全ファイルを作成できるようにする
複数のフェーズのTask tool callsを1つのメッセージで送信し、並列実行を最大化する
step6 を実行する

step6: overview作成と完了報告

6.1 overviewファイルの作成

全タスクファイル作成後に overview を作成
作成したタスクファイルの情報を集約
<overview_template> を使用してファイルを作成
docs/tasks/{要件名}/overview.md に出力

6.2 品質評価

作成したタスクファイルの内容について、品質判定基準に基づいて以下を評価：

タスクの粒度の適切性
依存関係の完全性
実装可能性
信頼性レベル（🔵🟡🔴の分布）- すべてのタスクファイルを通じて集計

品質判定結果をユーザーに表示する（全ファイル統合の信頼性レベル分布を含む）

6.3 TODO更新

TodoWrite ツールで TODO ステータスを更新する
- 現在のTODOを「completed」にマーク
- タスク分割フェーズの完了をTODO内容に反映
- 次のフェーズ「タスク実装」をTODOに追加
- 品質判定結果をTODO内容に記録

6.4 完了報告

完了報告を表示：

step3で収集した開発コンテキスト情報のサマリー
step4でのヒアリング結果と設計文書との差分
作成ファイル数の確認:
- 洗い出したタスク総数: {N}件
- 作成したタスクファイル数: {N}件
- overviewファイル: 1件
- ✅ すべてのタスクファイルが作成されたことを確認
作成したファイルのパス一覧（overview.md、各タスクファイル）
各タスクファイルの信頼性レベル分布
全体の信頼性レベル分布（すべてのタスクファイルを通じた集計）
タスク総数、推定工数、フェーズ数
各ファイル内のリンクが正しく設定されていることを確認

次のステップ表示: 「次のお勧めステップ: /tsumiki:kairo-implement でタスクを実装します。特定のタスクを実装する場合は /tsumiki:kairo-implement TASK-0001 のように指定してください。」

rules

ファイル名のルール

出力ファイルのパス形式

docs/tasks/{要件名}/overview.md
docs/tasks/{要件名}/TASK-0001.md (1ファイル1タスク)
docs/tasks/{要件名}/TASK-0002.md
（全タスク分）

ファイル名の命名規則

要件名を簡潔な英語に変換する
ケバブケース（kebab-case）を使用
最大50文字程度に収める
例:
- "ユーザー認証システム" → "user-auth-system"
- "データエクスポート機能" → "data-export"
- "パスワードリセット" → "password-reset"

品質判定基準

✅ 高品質:
- タスク粒度: 適切（1日単位）
- 依存関係: 完全に定義
- 実装可能性: 確実
- 信頼性レベル: 🔵（青信号）が多い

⚠️ 要改善:
- タスクに曖昧な部分がある
- 依存関係が不明確
- 技術的制約が不明
- 実装手順の確認が必要
- 信頼性レベル: 🟡🔴（黄・赤信号）が多い

TODO更新パターン

- 現在のTODOを「completed」にマーク
- タスク分割フェーズの完了をTODO内容に反映
- 次のフェーズ「タスク実装」をTODOに追加
- 品質判定結果をTODO内容に記録

信頼性レベル指示

各項目について、元の資料（要件定義書・設計文書・ユーザヒアリング含む）との照合状況を以下の信号でコメントしてください：

🔵 青信号: 要件定義書・設計文書・ユーザヒアリングを参考にしてほぼ推測していない場合
🟡 黄信号: 要件定義書・設計文書・ユーザヒアリングから妥当な推測の場合
🔴 赤信号: 要件定義書・設計文書・ユーザヒアリングにない推測の場合

ファイルパスの記載ルール

プロジェクトルートを基準とした相対パスを使用する
フルパス（絶対パス）は記載しない
例:
- ❌ /Users/username/projects/myapp/src/utils/helper.ts
- ✅ src/utils/helper.ts

作業規模別の出力調整

詳細タスク分割

すべてのセクションを含む
詳細な実装手順作成
包括的なテストケース作成
UI/UX要件を網羅

軽量タスク分割

基本的なタスク定義のみ
主要な実装手順のみ
基本的なテスト要件のみ
UI/UX要件は最低限

カスタム

選択された項目のみ含める

タスクプロセス定義

TDDタスク

/tsumiki:tdd-requirements - 詳細要件定義
/tsumiki:tdd-testcases - テストケース作成
/tsumiki:tdd-red - テスト実装（失敗）
/tsumiki:tdd-green - 最小実装
/tsumiki:tdd-refactor - リファクタリング
/tsumiki:tdd-verify-complete - 品質確認

DIRECTタスク

/tsumiki:direct-setup - 直接実装・設定
/tsumiki:direct-verify - 動作確認・品質確認

info

AskUserQuestion ツールの使用例

すべてのヒアリングは AskUserQuestion ツールを使用して行います。以下は具体的な使用例です。

タスク粒度確認

AskUserQuestion({
  questions: [{
    question: "タスクの粒度について、1日（8時間）単位で問題ないでしょうか？",
    header: "タスク粒度",
    multiSelect: false,
    options: [
      {
        label: "1日単位で問題ない",
        description: "8時間単位のタスク分割"
      },
      {
        label: "より細かい分割が必要",
        description: "半日（4時間）単位など"
      }
    ]
  }]
})

優先順位確認

AskUserQuestion({
  questions: [{
    question: "以下のタスクグループの実装優先順位を教えてください",
    header: "優先順位",
    multiSelect: false,
    options: [
      {
        label: "基盤→バックエンド→フロントエンド",
        description: "標準的な実装順序"
      },
      {
        label: "フロントエンド優先",
        description: "UI/UXの早期確認を重視"
      },
      {
        label: "並行開発",
        description: "可能な限り並行して開発"
      }
    ]
  }]
})

テスト要件確認

AskUserQuestion({
  questions: [{
    question: "単体テストのカバレッジ目標を教えてください",
    header: "カバレッジ",
    multiSelect: false,
    options: [
      {
        label: "80%以上",
        description: "高いカバレッジを目指す"
      },
      {
        label: "60%以上",
        description: "標準的なカバレッジ"
      },
      {
        label: "主要機能のみ",
        description: "最小限のテスト"
      }
    ]
  }]
})

注意事項

header は12文字以内の短いラベル
question は明確で具体的な質問文
options は2-4個の選択肢
multiSelect は複数選択可能にする場合true
ユーザーは常に「その他」を選択して自由記述できる（自動提供）

templates

<overview_template>

{要件名} タスク概要

作成日: {作成日時} プロジェクト期間: {開始日} - {終了日}（{総日数}日） 推定工数: {総工数}時間 総タスク数: {タスク数}件

フェーズ構成

フェーズ	期間	成果物	タスク数	工数	ファイル
Phase 1	{期間}	{成果物}	{件数}	{工数}h	TASK-0001~0010
Phase 2	{期間}	{成果物}	{件数}	{工数}h	TASK-0011~0020
Phase 3	{期間}	{成果物}	{件数}	{工数}h	TASK-0021~0030
Phase 4	{期間}	{成果物}	{件数}	{工数}h	TASK-0031~0040

タスク番号管理

使用済みタスク番号: TASK-0001 ~ TASK-{最終番号} 次回開始番号: TASK-{次の番号}

全体進捗

Phase 1: 基盤構築
Phase 2: バックエンド実装
Phase 3: フロントエンド実装
Phase 4: 統合テスト

マイルストーン

M1: 基盤完成 ({日付}): データベース・環境構築完了
M2: API完成 ({日付}): バックエンドAPI実装完了
M3: UI完成 ({日付}): フロントエンド実装完了
M4: リリース準備完了 ({日付}): 全テスト完了

Phase 1: 基盤構築

期間: {期間} 目標: {目標} 成果物: {成果物}

タスク一覧

TASK-0001: {タスク名} - {推定工数}h ({タイプ}) 🔵
TASK-0002: {タスク名} - {推定工数}h ({タイプ}) 🔵
TASK-0003: {タスク名} - {推定工数}h ({タイプ}) 🟡

依存関係

TASK-0001 → TASK-0002
TASK-0001 → TASK-0003

Phase 2: バックエンド実装

期間: {期間} 目標: {目標} 成果物: {成果物}

タスク一覧

TASK-0011: {タスク名} - {推定工数}h ({タイプ}) 🔵
TASK-0012: {タスク名} - {推定工数}h ({タイプ}) 🔵

依存関係

TASK-0003 → TASK-0011
TASK-0011 → TASK-0012

Phase 3: フロントエンド実装

期間: {期間} 目標: {目標} 成果物: {成果物}

タスク一覧

TASK-0021: {タスク名} - {推定工数}h ({タイプ}) 🔵
TASK-0022: {タスク名} - {推定工数}h ({タイプ}) 🟡

依存関係

TASK-0012 → TASK-0021
TASK-0021 → TASK-0022

Phase 4: 統合テスト

期間: {期間} 目標: {目標} 成果物: {成果物}

タスク一覧

TASK-0031: {タスク名} - {推定工数}h ({タイプ}) 🔵
TASK-0032: {タスク名} - {推定工数}h ({タイプ}) 🔵

依存関係

TASK-0022 → TASK-0031
TASK-0031 → TASK-0032

信頼性レベルサマリー

全タスク統計

総タスク数: {件数}件
🔵 青信号: {件数}件 ({割合}%)
🟡 黄信号: {件数}件 ({割合}%)
🔴 赤信号: {件数}件 ({割合}%)

フェーズ別信頼性

フェーズ	🔵 青	🟡 黄	🔴 赤	合計
Phase 1	{件数}	{件数}	{件数}	{件数}
Phase 2	{件数}	{件数}	{件数}	{件数}
Phase 3	{件数}	{件数}	{件数}	{件数}
Phase 4	{件数}	{件数}	{件数}	{件数}

品質評価: {高品質/要改善/要ヒアリング}

クリティカルパス

TASK-0001 → TASK-0002 → TASK-0011 → TASK-0012 → TASK-0021 → TASK-0031 → TASK-0032

クリティカルパス工数: {工数}時間 並行作業可能工数: {工数}時間

次のステップ

タスクを実装するには:

全タスク順番に実装: /tsumiki:kairo-implement
特定タスクを実装: /tsumiki:kairo-implement TASK-0001 </overview_template>

<full_task_template>

TASK-{タスク番号}: {タスク名}

タスクID: TASK-{タスク番号} タスクタイプ: {TDD/DIRECT} 推定工数: {工数}時間 フェーズ: Phase {フェーズ番号} - {フェーズ名} 信頼性レベル: {🔵/🟡/🔴} {出典}

タスク概要

{タスクの概要説明}

依存タスク

前提タスク: TASK-{番号}: {タスク名}
後続タスク: TASK-{番号}: {タスク名}

完了条件

{完了条件1}
{完了条件2}
{完了条件3}

実装詳細

1. {実装項目1} 🔵

信頼性: 🔵 設計文書 architecture.md より

{実装内容の詳細}

実装ファイル: {ファイルパス}

// 実装例
{コード例}

2. {実装項目2} 🟡

信頼性: 🟡 設計文書から妥当な推測

{実装内容の詳細}

実装ファイル: {ファイルパス}

3. {実装項目3} 🔵

信頼性: 🔵 API仕様書より

{実装内容の詳細}

単体テスト要件

テストケース1: {テストケース名} 🔵

信頼性: 🔵 要件定義書 REQ-001 より

Given: {前提条件} When: {実行条件} Then: {期待結果}

テストファイル: {テストファイルパス}

// テストコード例
describe('{テスト対象}', () => {
  it('{テストケース}', async () => {
    // テスト実装
  });
});

テストケース2: {テストケース名} 🟡

信頼性: 🟡 既存実装から妥当な推測

Given: {前提条件} When: {実行条件} Then: {期待結果}

統合テスト要件

統合テスト1: {テスト名} 🔵

信頼性: 🔵 dataflow.md より

テスト内容: {テスト内容} 期待結果: {期待結果}

UI/UX要件

ローディング状態 🔵

信頼性: 🔵 要件定義書 NFR-201 より

{ローディング状態の詳細}

エラー表示 🟡

信頼性: 🟡 既存実装から妥当な推測

{エラー表示の詳細}

モバイル対応 🔵

信頼性: 🔵 要件定義書 NFR-202 より

{モバイル対応の詳細}

アクセシビリティ 🔵

信頼性: 🔵 要件定義書 NFR-203 より

{アクセシビリティ要件の詳細}

実装手順

TDDタスクの場合

/tsumiki:tdd-requirements TASK-{番号} - 詳細要件定義
/tsumiki:tdd-testcases - テストケース作成
/tsumiki:tdd-red - テスト実装（失敗）
/tsumiki:tdd-green - 最小実装
/tsumiki:tdd-refactor - リファクタリング
/tsumiki:tdd-verify-complete - 品質確認

DIRECTタスクの場合

/tsumiki:direct-setup - 直接実装・設定
/tsumiki:direct-verify - 動作確認・品質確認

注意事項

{注意事項1}
{注意事項2}

信頼性レベルサマリー

項目別信頼性

カテゴリ	🔵 青	🟡 黄	🔴 赤	合計
実装詳細	{件数}	{件数}	{件数}	{件数}
単体テスト	{件数}	{件数}	{件数}	{件数}
統合テスト	{件数}	{件数}	{件数}	{件数}
UI/UX要件	{件数}	{件数}	{件数}	{件数}

全体評価

総項目数: {件数}項目
🔵 青信号: {件数}項目 ({割合}%)
🟡 黄信号: {件数}項目 ({割合}%)
🔴 赤信号: {件数}項目 ({割合}%)

品質評価: {高品質/要改善/要ヒアリング}

推測が多い項目: {推測が多い項目のリスト} </full_task_template>

<minimal_task_template>

TASK-{タスク番号}: {タスク名}

タスク概要

{タスクの概要説明}

依存タスク

前提タスク: TASK-{番号}
後続タスク: TASK-{番号}

完了条件

{完了条件1}
{完了条件2}

主要実装項目

{実装項目1} 🔵

信頼性: 🔵 {出典}

{実装内容}

実装ファイル: {ファイルパス}

{実装項目2} 🟡

信頼性: 🟡 {出典}

{実装内容}

基本的なテスト要件

{テストケース名} 🔵

信頼性: 🔵 {出典}

{テスト内容}

実装手順

TDDタスクの場合

/tsumiki:tdd-requirements TASK-{番号} - 詳細要件定義
/tsumiki:tdd-testcases - テストケース作成
/tsumiki:tdd-red - テスト実装（失敗）
/tsumiki:tdd-green - 最小実装
/tsumiki:tdd-refactor - リファクタリング
/tsumiki:tdd-verify-complete - 品質確認

DIRECTタスクの場合

/tsumiki:direct-setup - 直接実装・設定
/tsumiki:direct-verify - 動作確認・品質確認

信頼性レベルサマリー

総項目数: {件数}項目
🔵 青信号: {件数}項目 ({割合}%)
🟡 黄信号: {件数}項目 ({割合}%)
🔴 赤信号: {件数}項目 ({割合}%)

品質評価: {高品質/要改善/要ヒアリング} </minimal_task_template>

/kairo-tasks

kairo-tasks

目的

前提条件

context

step

step2: 作業規模の確認

step3: 開発コンテキストの準備

step4: タスク分析とヒアリング

詳細タスク分割の場合

軽量タスク分割の場合

カスタムの場合

step5: タスク作成

5.1 タスクの洗い出し

5.2 依存関係の分析

5.3 タスクの詳細化

5.4 タスクの順序付け

5.5 フェーズ分割

5.6 個別タスクファイルの作成

step6: overview作成と完了報告

6.1 overviewファイルの作成

6.2 品質評価

6.3 TODO更新

6.4 完了報告

rules

ファイル名のルール

出力ファイルのパス形式

ファイル名の命名規則

品質判定基準

TODO更新パターン

信頼性レベル指示

ファイルパスの記載ルール

作業規模別の出力調整

詳細タスク分割

軽量タスク分割

カスタム

タスクプロセス定義

TDDタスク

DIRECTタスク

info

AskUserQuestion ツールの使用例

タスク粒度確認

優先順位確認

テスト要件確認

注意事項

templates

{要件名} タスク概要

関連文書

フェーズ構成

タスク番号管理

全体進捗

マイルストーン

Phase 1: 基盤構築

タスク一覧

依存関係

Phase 2: バックエンド実装

タスク一覧

依存関係

Phase 3: フロントエンド実装

タスク一覧

依存関係

Phase 4: 統合テスト

タスク一覧

依存関係

信頼性レベルサマリー

全タスク統計

フェーズ別信頼性

クリティカルパス

次のステップ

TASK-{タスク番号}: {タスク名}

関連文書

タスク概要

依存タスク

完了条件

実装詳細

1. {実装項目1} 🔵

2. {実装項目2} 🟡

3. {実装項目3} 🔵

単体テスト要件

テストケース1: {テストケース名} 🔵