feat: version 1.1.1 updates

.claude-plugin/marketplace.json

@@ -7,14 +7,14 @@
   },
   "metadata": {
     "description": "AI-driven development toolkit for TDD and SDD workflows, providing comprehensive command templates and agents to enhance developer productivity with Claude Code",
-    "version": "0.0.7"
+    "version": "1.1.1"
   },
   "plugins": [
     {
       "name": "tsumiki",
       "source": "./",
       "description": "AI-driven development toolkit for TDD and SDD workflows, providing comprehensive command templates and agents to enhance developer productivity with Claude Code",
-      "version": "0.0.7",
+      "version": "1.1.1",
       "author": {
         "name": "makoto kuroeda",
         "email": "kuroeda.makoto@classmethod.jp"

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "tsumiki",
-  "version": "0.0.7",
+  "version": "1.1.1",
   "description": "AI-driven development toolkit for TDD and SDD workflows, providing comprehensive command templates and agents to enhance developer productivity with Claude Code",
   "author": {
     "name": "makoto kuroeda",
@@ -10,6 +10,5 @@
   "repository": "https://github.com/classmethod/tsumiki",
   "license": "MIT",
   "keywords": ["ai-development", "sdd", "tdd"],
-  "commands": "./commands/",
-  "agents": ["./agents/symbol-searcher.md"]
+  "commands": "./commands/"
 }

commands/auto-debug.md

@@ -2,20 +2,143 @@
 description: テストエラーを解消するための自動デバッグプロセス。全テストケースの確認からエラー原因の調査、修正まで段階的に実行し、テストケースの成功率向上を目指します。
 ---
 テストエラーを解消して。
-#ultrathink
 
 # step
-1. 最初に全テストケースの確認をタスク実行してテストケースのエラーをtodoにセットして
-2. 各対象毎に以下の作業を実施して
-　 - タスクで詳細にテストのエラー原因を調る
- 　- <green_task> をTask ツールで直接実行して修正する。パラメータとしてエラーの原因を渡す
-3. ゴールはテストケースの成功数を上げること
-4. テストエラー解消後に <refactor_task> をTask ツールで直接実行してリファクタリングを実施する
-5. 最後に全体のテストの成功率を確認してレポートして
+
+## step1: 失敗テストの特定
+
+1. **全テストケースの確認**
+   ```bash
+   npm test -- --verbose 2>&1 | tee test-results.log
+   ```
+   - 失敗しているテストのみをリスト化
+   - 各テストの失敗内容を記録
+   - テストファイルごとにグループ化
+
+2. **失敗テストをTODOに登録**
+   - TodoWrite ツールで各失敗テストをTODO項目として登録
+   - 優先度を設定（重要度: 高/中/低）
+   - メタデータに以下を含める:
+     - `retry_count: 0` - リトライ回数の初期値
+     - `max_retry: 3` - 最大リトライ回数
+     - `status: pending` - 処理状態（pending/in_progress/resolved/on_hold）
+
+## step2: テストファイル単位での修正
+
+**各失敗テストファイルに対して以下を実施（最大3回まで）**:
+
+1. **リトライカウンタの初期化**
+   - 各テストファイルのリトライ回数を0に設定
+   - 保留テストリストを初期化（空のリスト）
+
+2. **該当テストファイルのみを実行して詳細確認**
+   ```bash
+   npm test -- <失敗したテストファイル> --verbose
+   ```
+
+3. **エラー原因の分析**
+   - Task tool (subagent_type: Explore, thoroughness: quick) を使用
+   - エラーメッセージから原因を特定
+   - 修正方針を決定
+
+4. **修正実装**
+   - <green_task> をTask ツールで直接実行して修正
+   - パラメータとしてエラーの原因と該当テストファイルを渡す
+
+5. **該当テストファイルのみを再実行**
+   ```bash
+   npm test -- <修正したテストファイル>
+   ```
+
+6. **リトライ判定**
+   - ✅ 成功: 次のテストファイルへ
+   - ❌ 失敗かつリトライ回数 < 3:
+     - リトライ回数を+1
+     - step2の3に戻って再分析
+   - ❌ 失敗かつリトライ回数 >= 3:
+     - このテストは保留リストに追加
+     - 保留理由を記録（例: "3回の修正試行後も解消できず"）
+     - 次のテストファイルへ進む
+
+## step3: 全テスト実行による確認
+
+**全ての失敗テストの修正試行が完了した後**:
+
+1. **全テスト実行**
+   ```bash
+   npm test -- --verbose
+   ```
+
+2. **結果確認**
+   - 新たに失敗したテストがないか確認
+   - 既存のテストが通ることを確認
+   - 保留テストの状態を確認
+
+3. **追加修正が必要な場合**
+   - 新規失敗テスト: step2に戻って対応（リトライ回数0から開始）
+   - 保留テストの再試行: ユーザーに確認後、step2に戻って対応
+
+## step4: リファクタリング
+
+**全テストが通った後**:
+
+- <refactor_task> をTask ツールで直接実行してリファクタリングを実施
+
+## step5: 最終レポート
+
+**最後に全体のテストの成功率を確認してレポート**:
+
+```markdown
+# テストエラー解消レポート
+
+## 結果サマリー
+- 修正前の失敗テスト数: XX個
+- 修正後の失敗テスト数: XX個
+- 解消したテスト数: XX個
+- 保留したテスト数: XX個（3回の修正試行後も解消できず）
+- テスト成功率: XX%
+
+## 修正内容
+1. test/user.test.js
+   - エラー原因: データベース接続エラー
+   - 修正内容: 接続プールの初期化を修正
+   - 実行時間: 15秒 → 2秒
+   - リトライ回数: 1回
+
+2. test/file.test.js
+   - エラー原因: ファイルパスの不一致
+   - 修正内容: パス解決ロジックを修正
+   - 実行時間: 8秒 → 0.5秒
+   - リトライ回数: 0回
+
+## 保留テスト（要手動確認）
+1. test/complex.test.js
+   - 保留理由: 3回の修正試行後も解消できず
+   - 最終エラー: [エラーメッセージ]
+   - 推奨対応: [手動での詳細調査が必要な理由]
+```
+
+## step6: テスト実行時間のチェック
+
+**3秒以上かかるテストがある場合は警告表示**:
+
+```
+⚠️ 遅いテストが検出されました（3秒以上）
+
+以下のテストファイルの実行時間が長くなっています:
+- test/user.test.js: 15秒
+- test/integration.test.js: 8秒
+
+テスト実行速度の改善を推奨します:
+1. `/tsumiki:dcs:test-performance-analysis` で詳細分析
+2. `/tsumiki:test-optimization-patterns` でリファクタリングパターンを確認
+```
 
 # rule
 NEVER: テストのスキップ
 NEVER: 既存テストケースの削除
+MUST: 各テストファイルの修正は最大3回まで（無限ループ防止）
+MUST: 3回試行後も解消できないテストは保留リストに追加
 
 # info
 
@@ -35,10 +158,10 @@ NEVER: 既存テストケースの削除
    - `docs/rule/tdd/green` ディレクトリが存在する場合は読み込み
    - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用
 
-2. **@agent-symbol-searcher で実装関連情報を検索し、見つかったファイルを読み込み**
-   - 既存の類似機能やユーティリティ関数を検索し、該当ファイルをReadツールで読み込み
-   - 実装パターンやアーキテクチャガイドラインを特定し、設計文書をReadツールで読み込み
-   - 依存関係やインポートパスを確認し、関連ファイルをReadツールで読み込み
+2. **Task tool (subagent_type: Explore, thoroughness: quick) を使用して実装関連情報を探索**
+   - 既存の類似機能やユーティリティ関数を探索
+   - 実装パターンやアーキテクチャガイドラインを特定
+   - 依存関係やインポートパスを確認
 
 
 読み込み完了後、準備されたコンテキスト情報を基にGreen task（実装）の作業を開始します。
@@ -256,10 +379,10 @@ TDDのRefactorフェーズを実行します。
    - `docs/rule/tdd/refactor` ディレクトリが存在する場合は読み込み
    - 各ディレクトリ内のすべてのファイルを読み込み、追加ルールとして適用
 
-2. **@agent-symbol-searcher でリファクタリング関連情報を検索し、見つかったファイルを読み込み**
-   - 既存のコードスタイルやベストプラクティスを検索し、スタイルガイドをReadツールで読み込み
-   - プロジェクト全体のアーキテクチャパターンを特定し、設計文書をReadツールで読み込み
-   - 再利用可能なユーティリティ関数やコンポーネントを確認し、関連ファイルをReadツールで読み込み
+2. **Task tool (subagent_type: Explore, thoroughness: quick) を使用してリファクタリング関連情報を探索**
+   - 既存のコードスタイルやベストプラクティスを探索
+   - プロジェクト全体のアーキテクチャパターンを特定
+   - 再利用可能なユーティリティ関数やコンポーネントを確認
 
 3. **関連ファイルを直接読み込み**
    - 関連する設計文書やタスクファイルも必要に応じて読み込み