各コマンドの初期処理をagentに変更

agents/symbol-searcher.md

@@ -0,0 +1,61 @@
+---
+name: symbol-searcher
+description: Use this agent when you need to search for specific symbols (classes, methods, functions, variables, etc.) across the codebase and retrieve detailed information about their locations and types. This agent is particularly useful for code navigation, refactoring preparation, or understanding code structure. Examples:\n\n<example>\nContext: The user wants to find all occurrences of a specific method across the codebase.\nuser: "Find all instances of the 'createTodo' method in the project"\nassistant: "I'll use the symbol-searcher agent to locate all occurrences of the 'createTodo' method across the codebase."\n<commentary>\nSince the user wants to find specific symbols in the code, use the Task tool to launch the symbol-searcher agent.\n</commentary>\n</example>\n\n<example>\nContext: The user needs to understand where a class is defined and used.\nuser: "Where is the TodoController class defined and what methods does it have?"\nassistant: "Let me search for the TodoController class symbol to find its definition and methods."\n<commentary>\nThe user is asking about a specific class symbol, so use the symbol-searcher agent to find its location and details.\n</commentary>\n</example>
+tools: Glob, Grep, LS, Read, NotebookRead, WebFetch, TodoWrite, WebSearch, mcp__ide__getDiagnostics
+model: haiku
+color: green
+---
+
+You are an expert code symbol analyzer specializing in searching and identifying symbols across codebases. Your primary responsibility is to locate specific symbols (classes, methods, functions, variables, interfaces, types, etc.) and provide comprehensive information about their locations and characteristics.
+
+When searching for symbols, you will:
+
+1. **Search Strategy**:
+   - Use appropriate tools to scan files for the requested symbol names
+   - Consider partial matches and case variations when appropriate
+   - Search across all relevant file types in the project
+   - Prioritize definition locations over usage locations unless specified otherwise
+
+2. **Symbol Classification**:
+   - Accurately identify the symbol type: class, method, function, variable, interface, type, enum, constant, etc.
+   - For methods/functions, include whether they are static, async, private/public
+   - For classes, note if they are abstract, extend other classes, or implement interfaces
+   - Include descriptive context that helps understand the symbol's purpose
+
+3. **Information Extraction**:
+   For each symbol found, you must provide:
+   - **Symbol Name**: The exact name with descriptive context (e.g., 'createTodo - async method for creating new todo items')
+   - **Type**: The specific symbol type (class, method, function, variable, etc.)
+   - **File Path**: The relative path from the project root
+   - **Location**: Line number and, if possible, column number
+   - **Context**: Brief description of what the symbol does based on its name and surrounding code
+
+4. **Output Format**:
+   Present your findings in a structured format:
+   ```
+   Symbol: [Name with description]
+   Type: [Symbol type]
+   File: [Relative path]
+   Location: Line [X], Column [Y]
+   Context: [Brief functional description]
+   ```
+
+5. **Search Completeness**:
+   - Always search the entire codebase unless instructed to limit scope
+   - Group results by symbol type when multiple matches are found
+   - If a symbol has multiple definitions (overloads, implementations), list all occurrences
+   - Distinguish between declarations, definitions, and usages when relevant
+
+6. **Edge Cases**:
+   - If no symbols are found, suggest similar symbol names that exist in the codebase
+   - Handle minified or obfuscated code by noting when symbol names might be transformed
+   - For ambiguous requests, search for all possible interpretations
+   - Consider language-specific naming conventions (camelCase, snake_case, etc.)
+
+7. **Quality Assurance**:
+   - Verify that the symbol at the reported location matches the search criteria
+   - Ensure file paths are correct and relative to the project root
+   - Double-check symbol type classification
+   - Include enough context in descriptions to make the symbol's purpose clear
+
+Remember: Your goal is to provide developers with precise, actionable information about code symbols that helps them navigate and understand the codebase efficiently. Always prioritize accuracy and completeness in your symbol analysis.

commands/auto-debug.md

@@ -0,0 +1,10 @@
+テストエラーを解消して。
+最初に全テストケースの確認をタスク実行してテストケースのエラーをtodoにセットして
+各対象毎に以下の作業を実施して
+　 - タスクで詳細にテストのエラー原因を調る
+ 　- 新たなタスクで /tdd-green を使って修正する
+最後に全体のテストの成功率を確認してレポートして
+ゴールはテストケースの成功数を上げること
+NEVER: テストのスキップ
+NEVER: 既存でテストケースの削除
+#ultrathink

commands/direct-setup.md

@@ -13,11 +13,13 @@ DIRECTタスクの設定作業を実行します。設計文書に基づいて
 ## 実行内容
 
 1. **設計文書の確認**
-   - `docs/design/{要件名}/architecture.md` を確認
-   - `docs/design/{要件名}/database-schema.sql` を確認
-   - その他関連する設計文書を確認
+   - @agent-symbol-searcher で関連設計文書や設定パターンを検索し、見つかったファイルをReadツールで読み込み
+   - `docs/design/{要件名}/architecture.md` をReadツールで読み込み
+   - `docs/design/{要件名}/database-schema.sql` をReadツールで読み込み
+   - その他関連する設計文書をReadツールで読み込み
 
 2. **設定作業の実行**
+   - @agent-symbol-searcher で既存の設定ファイルや環境変数を検索し、見つかったファイルをReadツールで読み込み
    - 環境変数の設定
    - 設定ファイルの作成・更新
    - 依存関係のインストール

commands/direct-verify.md

@@ -15,6 +15,8 @@ DIRECTタスクで実行した設定作業の動作確認とテストを行い
 **【重要】**: direct-setupで作成されたファイルについて、コンパイルエラーや構文エラーが見つかった場合は自動的に解決を試行します。
 
 1. **設定の確認**
+   - @agent-symbol-searcher で関連設定や検証パターンを検索し、見つかったファイルをReadツールで読み込み
+   - `docs/implements/{TASK-ID}/setup-report.md` をReadツールで読み込み、設定作業の結果を確認
    - 環境変数の確認
    - 設定ファイルの内容確認
    - 依存関係のインストール状況確認
@@ -27,6 +29,7 @@ DIRECTタスクで実行した設定作業の動作確認とテストを行い
    - 最低限のコンパイルエラー解消
 
 3. **動作テストの実行**
+   - @agent-symbol-searcher で既存のテストケースや検証スクリプトを検索し、見つかったファイルをReadツールで読み込み
    - 基本的な動作確認
    - 接続テスト
    - 権限の確認

commands/kairo-design.md

@@ -19,7 +19,8 @@
 - 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
 
 1. **要件の分析**
-   - 要件定義書を読み込む
+   - @agent-symbol-searcher で要件定義書を検索し、見つかったファイルをReadツールで読み込み
+   - @agent-symbol-searcher で関連する既存設計文書を確認し、見つかったファイルをReadツールで読み込み
    - 機能要件と非機能要件を整理する
    - システムの境界を明確にする
 
@@ -212,6 +213,7 @@ CREATE INDEX idx_users_email ON users(email);
 
 ## 実行後の確認
 
+- @agent-symbol-searcher で作成した設計と既存システムとの整合性を確認
 - 作成したファイルの一覧を表示
 - 設計の主要なポイントをサマリーで表示
 - ユーザに確認を促すメッセージを表示

commands/kairo-implement.md

@@ -21,11 +21,13 @@
 - 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
 
 1. **タスクの選択**
+   - @agent-symbol-searcher で指定されたタスクIDを検索し、見つかったタスクファイルをReadツールで読み込み
    - ユーザが指定したタスクIDを確認
    - 指定がない場合は、依存関係に基づいて次のタスクを自動選択
    - 選択したタスクの詳細を表示
 
 2. **依存関係の確認**
+   - @agent-symbol-searcher で依存タスクの状態を検索し、見つかったタスクファイルをReadツールで読み込み
    - 依存タスクが完了しているか確認
    - 未完了の依存タスクがある場合は警告
 
@@ -41,42 +43,78 @@
 
    ### A. **TDDプロセス**（コード実装タスク用）
 
-   a. **要件定義** (`tdd-requirements.md`)
-   - タスクの詳細要件を記述
-   - 受け入れ基準を明確化
-
-   b. **テストケース作成** (`tdd-testcases.md`)
-   - 単体テストケースを作成
-   - エッジケースを考慮
-
-   c. **テスト実装** (`tdd-red.md`)
-   - 失敗するテストを実装
-   - テストが失敗することを確認
-
-   d. **最小実装** (`tdd-green.md`)
-   - テストが通る最小限の実装
-   - 過度な実装を避ける
-
-   e. **リファクタリング** (`tdd-refactor.md`)
-   - コードの品質向上
-   - 保守性の改善
-
-   f. **品質確認** (`tdd-verify-complete.md`)
-   - 実装の完成度を確認
-   - 不足があれば c-f を繰り返す
+   a. **要件定義** - `@task general-purpose tdd-requirements.md`
+   ```
+   Task実行: TDD要件定義フェーズ
+   目的: タスクの詳細要件を記述し、受け入れ基準を明確化する
+   コマンド: tdd-requirements.md
+   実行方式: 個別Task実行
+   ```
+
+   b. **テストケース作成** - `@task general-purpose tdd-testcases.md`
+   ```
+   Task実行: TDDテストケース作成フェーズ
+   目的: 単体テストケースを作成し、エッジケースを考慮する
+   コマンド: tdd-testcases.md
+   実行方式: 個別Task実行
+   ```
+
+   c. **テスト実装** - `@task general-purpose tdd-red.md`
+   ```
+   Task実行: TDDレッドフェーズ
+   目的: 失敗するテストを実装し、テストが失敗することを確認する
+   コマンド: tdd-red.md
+   実行方式: 個別Task実行
+   ```
+
+   d. **最小実装** - `@task general-purpose tdd-green.md`
+   ```
+   Task実行: TDDグリーンフェーズ
+   目的: テストが通る最小限の実装を行い、過度な実装を避ける
+   コマンド: tdd-green.md
+   実行方式: 個別Task実行
+   ```
+
+   e. **リファクタリング** - `@task general-purpose tdd-refactor.md`
+   ```
+   Task実行: TDDリファクタリングフェーズ
+   目的: コードの品質向上と保守性の改善を行う
+   コマンド: tdd-refactor.md
+   実行方式: 個別Task実行
+   ```
+
+   f. **品質確認** - `@task general-purpose tdd-verify-complete.md`
+   ```
+   Task実行: TDD品質確認フェーズ
+   目的: 実装の完成度を確認し、不足があればc-fを繰り返す
+   コマンド: tdd-verify-complete.md
+   実行方式: 個別Task実行
+   ```
 
    ### B. **直接作業プロセス**（準備作業タスク用）
 
-   a. **準備作業の実行**
+   a. **準備作業の実行** - `@task general-purpose direct-work-execute`
+   ```
+   Task実行: 直接作業実行フェーズ
+   目的: ディレクトリ作成、設定ファイル作成、依存関係のインストール、環境設定を行う
+   作業内容:
    - ディレクトリ作成
    - 設定ファイル作成
    - 依存関係のインストール
    - 環境設定
-
-   b. **作業結果の確認**
+   実行方式: 個別Task実行
+   ```
+
+   b. **作業結果の確認** - `@task general-purpose direct-work-verify`
+   ```
+   Task実行: 直接作業確認フェーズ
+   目的: 作業完了の検証と成果物確認を行う
+   作業内容:
    - 作業完了の検証
    - 期待された成果物の確認
    - 次のタスクへの準備状況確認
+   実行方式: 個別Task実行
+   ```
 
 6. **タスクの完了処理**
    - タスクのステータスを更新（タスクファイルのチェックボックスにチェックを入れる）
@@ -154,6 +192,33 @@ $ claude code kairo-implement --status
 
 **例**: プロジェクト初期化、データベース設定、開発環境設定
 
+## 個別Task実行アプローチ
+
+### Task実行の方針
+
+各実装ステップを個別のTaskとして実行することで、以下のメリットが得られます：
+
+1. **独立性**: 各ステップが独立して実行され、エラー発生時の切り分けが容易
+2. **再実行性**: 特定のステップのみ再実行が可能
+3. **並列性**: 依存関係のないステップは並列実行可能
+4. **追跡性**: 各ステップの実行状況と結果が明確に記録される
+
+### Task実行パターン
+
+```bash
+# TDDプロセスの場合
+@task general-purpose tdd-requirements.md
+@task general-purpose tdd-testcases.md
+@task general-purpose tdd-red.md
+@task general-purpose tdd-green.md
+@task general-purpose tdd-refactor.md
+@task general-purpose tdd-verify-complete.md
+
+# 直接作業プロセスの場合
+@task general-purpose direct-work-execute
+@task general-purpose direct-work-verify
+```
+
 ## 実装時の注意事項
 
 ### TDDプロセス用
@@ -217,19 +282,23 @@ $ claude code kairo-implement --status
 ### 各ステップ完了時（TDD）
 
 ```
-✅ Step 1/6: 要件定義 完了
+✅ Task 1/6: @task tdd-requirements 完了
    ファイル: /implementation/{要件名}/TASK-101/requirements.md
+   Task実行結果: 要件定義書作成完了
 
-🏃 Step 2/6: テストケース作成 実行中...
+🏃 Task 2/6: @task tdd-testcases 実行中...
+   Task実行: TDDテストケース作成フェーズを開始
 ```
 
 ### 各ステップ完了時（直接作業）
 
 ```
-✅ Step 1/2: 準備作業実行 完了
+✅ Task 1/2: @task direct-work-execute 完了
    作成ファイル: 8個、設定更新: 3個
+   Task実行結果: 準備作業実行完了
 
-🏃 Step 2/2: 作業結果確認 実行中...
+🏃 Task 2/2: @task direct-work-verify 実行中...
+   Task実行: 直接作業確認フェーズを開始
 ```
 
 ### タスク完了時（TDD）
@@ -241,7 +310,8 @@ $ claude code kairo-implement --status
    - [ ] **タスク完了** → [x] **タスク完了**
 
 📊 実装サマリー:
-- 実装タイプ: TDDプロセス
+- 実装タイプ: TDDプロセス (個別Task実行)
+- 実行Taskステップ: 6個 (全て成功)
 - 作成ファイル: 12個
 - テストケース: 25個 (全て成功)
 - カバレッジ: 95%
@@ -263,7 +333,8 @@ $ claude code kairo-implement --status
    - [ ] **タスク完了** → [x] **タスク完了**
 
 📊 実装サマリー:
-- 実装タイプ: 直接作業プロセス
+- 実装タイプ: 直接作業プロセス (個別Task実行)
+- 実行Taskステップ: 2個 (全て成功)
 - 作成ファイル: 8個
 - 設定更新: 3個
 - 環境確認: 正常

commands/kairo-requirements.md

@@ -20,6 +20,7 @@
 
 1. **要件の分析**
    - ユーザから提供された要件の概要を理解する
+   - @agent-symbol-searcher で関連する既存要件・設計文書を検索し、見つかったファイルをReadツールで読み込み
    - 関連するドメイン知識を適用する
    - 不明確な点がある場合は、一般的なベストプラクティスに基づいて補完する
 
@@ -342,6 +343,7 @@ journey
 
 ## 実行後の確認
 
+- @agent-symbol-searcher で作成した要件との関連性を確認
 - 作成した3つのファイルのパスを表示
   - `docs/spec/{要件名}-requirements.md`
   - `docs/spec/{要件名}-user-stories.md` 

commands/kairo-task-verify.md

@@ -19,10 +19,12 @@
 - 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
 
 1. **タスクファイルの確認**
-   - `docs/tasks/{要件名}-tasks.md` を読み込み
+   - @agent-symbol-searcher でタスクファイルを検索し、見つかったファイルをReadツールで読み込み
+   - `docs/tasks/{要件名}-tasks.md` をReadツールで読み込み
 
 2. **出力フォーマット例との比較**
-   - kairo-tasksの出力フォーマット例を確認
+   - @agent-symbol-searcher で関連するタスクフォーマットを検索し、見つかったファイルをReadツールで読み込み
+   - kairo-tasksコマンドファイルをReadツールで読み込み、出力フォーマット例を確認
    - 作成されたタスクファイルに不足している情報を特定
 
 3. **不足情報の追加**

commands/kairo-tasks.md

@@ -20,14 +20,16 @@
 - 🔴 **赤信号**: EARS要件定義書・設計文書にない推測の場合
 
 1. **設計文書の分析**
-   - `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 で設計文書を検索し、見つかったファイルをReadツールで読み込み
+   - `docs/design/{要件名}/architecture.md` をReadツールで読み込み
+   - `docs/design/{要件名}/database-schema.sql` をReadツールで読み込み
+   - `docs/design/{要件名}/api-endpoints.md` をReadツールで読み込み
+   - `docs/design/{要件名}/interfaces.ts` をReadツールで読み込み
+   - `docs/design/{要件名}/dataflow.md` をReadツールで読み込み
 
 2. **既存タスクファイルの確認**
-   - 既存の`docs/tasks/{要件名}-*.md`ファイルを確認
+   - @agent-symbol-searcher で既存タスクIDを検索し、見つかったタスクファイルをReadツールで読み込み
+   - 既存の`docs/tasks/{要件名}-*.md`ファイルをReadツールで読み込み
    - 使用済みタスク番号（TASK-0001形式）を抽出
    - 新規タスクで重複しない番号を割り当て
 
@@ -358,6 +360,7 @@ gantt
 
 ## 実行後の確認
 
+- @agent-symbol-searcher で作成したタスクと既存システムとの整合性を確認
 - 作成したファイルの一覧を表示
   - `docs/tasks/{要件名}-overview.md`: 全体概要とフェーズ一覧
   - `docs/tasks/{要件名}-phase1.md`: フェーズ1詳細