# 🎯 Taskrの仕組み

## 3.3 タスク - 構成要素

### タスクの階層を理解する

タスクはレポートの構成案（アウトライン）のように整理されます：

```
1.0 Build user authentication (parent task)
  1.1 Set up database tables (subtask)
    1.1.1 Create users table (sub-subtask)
    1.1.2 Add password hashing
  1.2 Create login page
    1.2.1 Design login form
    1.2.2 Add validation
  1.3 Implement logout
```

**賢い仕組み：** 1.1.1 と 1.1.2 がすべて完了すると、1.1 は自動的に完了します。1.1、1.2、1.3 がすべて完了すると、1.0 も自動的に完了します！

### タスクタイプの解説

各タスクには、それがどのような作業であるかをAIに伝えるタイプがあります：

- **setup** 🔧 - 準備（パッケージのインストール、フォルダ作成）
- **analysis** 🔍 - 把握（APIの調査、アプローチの計画）
- **implementation** 💻 - 実際の構築（コード記述、機能作成）
- **validation** ✓ - 動作確認（ロジックのチェック、コードレビュー）
- **testing** 🧪 - 動作の証明（テストの記述、テストスイートの実行）

### タスクステータスの流れ

タスクはベルトコンベアのようにステータスを移動します：

1. **open** ⭕ - 未着手
2. **wip** 🔄 - 進行中（work in progress）
3. **done** ✅ - 完了
4. **skipped** ⏭️ - スキップ（不要と判断）

### 「一度に一つのタスク」ルール

非常に重要なことがあります：**AIは一度に一つのタスクしか担当できません**。

なぜでしょうか？マルチタスクは混乱を招くからです！AIがタスクを「wip（進行中）」とマークすると、`wip_agent_id` フィールドを通じて独占的な所有権を得ます。他のエージェントはそれに触れることができず、このエージェントはそのタスクを終えるまで別のタスクを開始することはできません。

これは、PostgreSQLのトリガーと MCP ハンドラーのコードによってデータベースで強制されています！

### 新しいタスクの作成

AIは `create_task` ツールを使用してタスクを作成します：

```
Your AI: "I need to break this down into smaller pieces"
Creates: Subtasks under the current task, or a whole new task list
Speed: Instant
Control: Your AI decides the structure based on your requirements
```

**ヒント：** より大きなプロジェクトの場合は、まず要件をAIのチャットに貼り付けてください。そうすることで、より徹底的で構造化されたタスク階層が作成されます。

### `get_task` の魔法

AIが `get_task` を呼び出すと、舞台裏で次のようなことが起こります：

1. **既存の WIP を確認** - 「すでに何か作業中かな？」
2. **次の論理的なタスクを探す** - 「順序的に次の『open（未着手）』タスクは何かな？」
3. **WIP としてマーク** - 「これは私の担当だ！」
4. **完全なコンテキストを返す** - タスクの詳細 + ノート + ガイダンスルール
5. **競合を防ぐ** - 他のエージェントはこのタスクを要求できません

データベース関数の `get_task_for_agent` がこれらすべてをアトミックに処理します！

---