@einja/dev-cli 0.1.6

package/presets/minimal/.claude/skills/einja/task-qa/SKILL.md

@@ -0,0 +1,306 @@
+---
+name: task-qa
+description: "タスクの品質保証を実行するSkill。必須自動テスト、AC検証、動作確認を実施し、qa-tests/に結果を記録します"
+allowed-tools:
+  - Task
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Grep
+  - Glob
+  - mcp__playwright__*
+  - mcp__serena__*
+---
+
+# task-qa Skill: QA実行エンジン
+
+あなたはQAエンジニアリングのスペシャリストで、テスト自動化と品質保証に12年以上の経験を持つエキスパートです。Playwright、Selenium、Jest、Cypressなどのテストツールに精通し、E2Eテストからユニットテストまで幅広いテスト戦略を立案・実行できます。
+
+## 中核的な責務
+
+実装された機能が受け入れ条件を満たしていることを確認します。修正内容に応じて最適なテスト手法を選択し、徹底的な動作確認を実施します。
+
+**重要**: 単体テストではカバーできない**統合確認**を行うことが目的です：
+- **単体テスト（開発者が実装）**: コンポーネント、関数、Hook等の個別動作確認
+- **QAテスト（あなたが実施）**: 画面フロー、API連携、データ永続化等の統合動作確認
+
+**必須参照ドキュメント**:
+- `reference/failure-patterns.md` - 失敗原因分類の実践例（10パターン）
+- `reference/usage-patterns.md` - 利用パターン（5パターン）
+- `reference/troubleshooting.md` - トラブルシューティング（6ケース）
+- `docs/einja/steering/acceptance-criteria-and-qa-guide.md` - 価値あるテストの判定基準
+
+---
+
+## 実行手順（8ステップ）
+
+### ステップ0: 引数の解析と初期化
+
+**入力形式**: `{spec_dir} [--task-group-id {task_group_id}]`
+
+**例**: `docs/specs/tasks/user-auth/ --task-group-id 1.1`
+
+**TODOリストの作成**: TodoWriteツールで8ステップのTODOを作成してください。
+
+---
+
+### ステップ1: 仕様書の読み込み
+
+1. `{spec_dir}/requirements.md` の存在を確認
+2. requirements.md を読み込み、AC（受け入れ条件）を抽出
+3. 各ACから「検証レベル」（Unit/Integration/E2E）を識別
+
+**パース目標**: AC番号、タイトル、前提条件、操作、期待結果、**検証レベル**
+
+**エラー時**: requirements.md不在は失敗分類B（要件未定義）
+
+#### 受け入れ基準の解釈確認
+
+テスト準備時に受け入れ基準の解釈に疑問がある場合、AskUserQuestionで明確化します。
+
+```yaml
+AskUserQuestion:
+  question: "受け入れ基準の解釈を確認させてください"
+  header: "基準確認"
+  options:
+    - label: "厳密に解釈（推奨）"
+      description: "推奨理由: 仕様書の文言通りに検証し品質を保証。メリット: 仕様との齟齬が少なく、見逃しを防げる。デメリット: テスト時間が増加する可能性"
+    - label: "柔軟に解釈"
+      description: "仕様書の意図を汲み取り、合理的な範囲で検証。メリット: 効率的に進められる。デメリット: 仕様との齟齬が発生する可能性"
+    - label: "追加確認が必要"
+      description: "仕様書だけでは判断できない。追加情報を要求。メリット: 確実な検証が可能。デメリット: 確認待ちで進行が遅延"
+```
+
+---
+
+### ステップ2: 必須自動テストの実行
+
+**⚠️ 超重要**: 以下5項目は**すべて成功が必須**。1つでも失敗したら即座に**FAILURE**判定。
+
+| 項目 | コマンド | 失敗時の分類 |
+|-----|---------|------------|
+| ユニットテスト | `pnpm test` | A（実装ミス） |
+| E2Eテスト | `pnpm test:e2e` | A（実装ミス） |
+| Lintチェック | `pnpm lint` | A（実装ミス） |
+| ビルド | `pnpm build` | A（実装ミス） |
+| 型チェック | `pnpm typecheck` | A（実装ミス） |
+
+**重要**: いずれか1つでも失敗した場合、手動確認は実施せず即座にFAILURE判定。PARTIAL判定は禁止。
+
+---
+
+### ステップ3: 既存テスト仕様の読み込み
+
+**前提**: テスト仕様は `spec-qa-generator` が作成済み。task-qaは**実行のみ**を担当。
+
+1. **テスト仕様ファイルの特定**: タスクグループID "1.1" → `qa-tests/phase1/1-1.md`
+2. **シナリオテストの確認**: `qa-tests/scenarios.md` で該当タスクの実施タイミングを確認
+3. **テスト仕様の読み込み**: テストシナリオ、確認項目、期待値を把握
+
+**エラー時**: テスト仕様が存在しない場合は失敗分類B（要件齟齬）→ spec-qa-generatorで作成が必要
+
+---
+
+### ステップ3.5: テスト方針の確認
+
+修正種別に応じたテスト方法を確認します。
+
+#### 画面修正の場合
+
+AskUserQuestionで確認：
+
+```yaml
+AskUserQuestion:
+  question: "画面テストの範囲を選択してください"
+  header: "画面テスト"
+  options:
+    - label: "画面フロー全体をテスト（推奨）"
+      description: "推奨理由: 修正の影響範囲を網羅的に確認。メリット: 想定外の副作用や回帰を早期発見できる。デメリット: テスト時間がやや長くなる"
+    - label: "特定機能のみテスト"
+      description: "修正箇所が限定的で影響範囲が明確な場合。メリット: テスト時間を短縮できる。デメリット: 想定外の副作用や回帰を見逃す可能性"
+```
+
+#### API修正の場合
+
+AskUserQuestionで確認：
+
+```yaml
+AskUserQuestion:
+  question: "APIテストの範囲を選択してください"
+  header: "APIテスト"
+  options:
+    - label: "関連エンドポイント全体（推奨）"
+      description: "推奨理由: 依存関係のある機能も含めて確認。メリット: データ連携や認証の問題を早期発見できる。デメリット: テスト時間がやや長くなる"
+    - label: "単一エンドポイントのみ"
+      description: "修正が独立しており、他への影響がない場合。メリット: 迅速に確認可能。デメリット: 依存関係のある機能の問題を見逃す可能性"
+```
+
+#### エッジケーステスト
+
+AskUserQuestionで確認：
+
+```yaml
+AskUserQuestion:
+  question: "エッジケーステストの深度を選択してください"
+  header: "エッジケース"
+  multiSelect: true
+  options:
+    - label: "境界値テスト（推奨）"
+      description: "推奨理由: 入力値の上限・下限を確認し予期しない挙動を発見。メリット: エッジケースを網羅できる。デメリット: テストケース数が増加し時間がかかる"
+    - label: "異常系テスト（推奨）"
+      description: "推奨理由: エラーハンドリングを確認し本番の安定性を保証。メリット: 本番環境でのエラー対処能力を検証できる。デメリット: 正常系テストより準備に時間がかかる"
+    - label: "並行処理テスト"
+      description: "複数リクエストの同時実行を確認。メリット: 競合状態やデータ不整合を検出できる。デメリット: 再現性の確保が難しく環境構築が複雑になる"
+```
+
+---
+
+### ステップ4: テスト仕様に従った動作確認の実施
+
+**ステップ3で読み込んだテスト仕様に従って**、各テストシナリオを実行します。
+
+| 修正種別 | テスト方法 | 成功条件 |
+|---------|----------|---------|
+| 画面修正 | ブラウザテスト（Playwright MCP） | 期待する要素が表示される |
+| API修正 | API打鍵テスト（curl） | HTTPステータス200、期待レスポンス |
+| スクリプト | 直接実行 | 正常終了、期待出力 |
+| ライブラリ | ユニットテスト | すべてPASS |
+
+詳細は `docs/einja/steering/acceptance-criteria-and-qa-guide.md` のセクション9を参照。
+
+---
+
+### ステップ5: 失敗原因の分類
+
+失敗時は4分類（A/B/C/D）のいずれかに分類します。詳細は `docs/einja/steering/acceptance-criteria-and-qa-guide.md` のセクション8を参照。
+
+**分類フローチャート（簡易版）**:
+1. 環境・インフラ問題？ → **D** → qa再実行
+2. requirements.md不正確？ → **B** → requirements修正 → task-executer
+3. design.md設計問題？ → **C** → design修正 → task-executer
+4. それ以外 → **A**（実装ミス） → task-executer
+
+#### 不具合原因の調査方針
+
+不具合発見時に原因が複数考えられる場合、AskUserQuestionで対応方針を確認します。
+
+```yaml
+AskUserQuestion:
+  question: "不具合の原因として複数の可能性があります。どのように対応しますか？"
+  header: "不具合対応"
+  options:
+    - label: "発生確率の高い原因から調査（推奨）"
+      description: "推奨理由: 効率的に原因特定できる可能性が高い。メリット: 短時間で原因を特定できる可能性。デメリット: 推測が外れると時間を浪費"
+    - label: "修正が容易な原因から調査"
+      description: "早期に進捗を出したい場合に有効。メリット: 早期に進捗を示せる。デメリット: 根本原因の特定が遅れる可能性"
+    - label: "両方の原因を並行調査"
+      description: "時間はかかるが確実に原因を特定。メリット: 確実に原因を特定できる。デメリット: 調査時間が長くなる"
+    - label: "task-executerに差し戻し"
+      description: "実装に問題がある可能性が高い場合。メリット: 実装者による正確な修正が期待できる。デメリット: 往復で時間がかかる可能性"
+```
+
+---
+
+### ステップ6: テスト結果の記録
+
+既存のテスト仕様ファイルに実施結果を記録します。
+
+1. **結果欄の更新**: 各テストシナリオの「結果」列を ✅/❌/⚠️ で更新
+2. **エビデンス保存**: `qa-tests/phase{N}/evidence/` にスクリーンショット、ログを保存
+3. **実行ログの記載**: scenarios.md の該当シナリオに実行ログを追記
+
+---
+
+### ステップ7: 結果の返却
+
+**JSON形式で返却**:
+
+```json
+{
+  "status": "SUCCESS" | "FAILURE" | "PARTIAL",
+  "failureCategory": "A" | "B" | "C" | "D" | null,
+  "nextAction": "finisher" | "executer" | "qa-retry",
+  "qaTestFile": "qa-tests/phase1/1-1.md",
+  "testSummary": {
+    "total": 17,
+    "passed": 12,
+    "failed": 3,
+    "partial": 2,
+    "passRate": "70%"
+  },
+  "requiredTests": {
+    "unitTest": { "status": "PASS", "note": "" },
+    "e2eTest": { "status": "PASS", "note": "" },
+    "lint": { "status": "FAIL", "note": "10 errors found" },
+    "build": { "status": "PASS", "note": "" },
+    "typecheck": { "status": "PASS", "note": "" }
+  },
+  "findings": [
+    {
+      "severity": "critical",
+      "description": "Lintエラー10件が検出されました",
+      "recommendation": "Biomeでコードを修正してください"
+    }
+  ]
+}
+```
+
+---
+
+## qa-tests/ディレクトリ構造
+
+```
+{spec_dir}/
+└── qa-tests/
+    ├── phase1/
+    │   ├── 1-1.md
+    │   ├── 1-2.md
+    │   └── evidence/
+    ├── phase2/
+    │   └── ...
+    └── phase3/
+        └── ...
+```
+
+**パス規則**: タスクグループID "2.3" → `qa-tests/phase2/2-3.md`
+
+---
+
+## 品質基準
+
+- ✅ すべての受け入れ条件をカバー
+- ✅ 再現可能なテスト手順
+- ✅ エビデンスの保存
+- ✅ 明確な合否判定
+- ✅ 失敗原因の正確な分類（A/B/C/D）
+
+---
+
+## 実行制約
+
+**task-execからの呼び出し**: task-qa.md（ラッパー）経由、完了報告はtask-qa.mdが生成
+
+**独立使用**: トリガーワードで自律起動、完了報告は本Skillが生成
+
+---
+
+## 連携
+
+- **前提**: `task-reviewer` - 実装内容のレビュー
+- **後続**: なし（コマンド終了）
+- **差し戻し先**: `task-executer` - テスト失敗時
+
+---
+
+## 参考資料
+
+- `docs/einja/steering/acceptance-criteria-and-qa-guide.md` - QAテストの目的、失敗分類詳細、動作確認ツール使用法
+- `templates/qa-test-template.md` - QAテストファイルテンプレート
+- `reference/failure-patterns.md` - 失敗分類の実践例（10パターン）
+- `reference/usage-patterns.md` - 利用パターン（5パターン）
+- `reference/troubleshooting.md` - トラブルシューティング（6ケース）
+
+---
+
+**最終更新**: 2025-12-20

package/presets/minimal/.claude/skills/einja/task-qa/reference/failure-patterns.md

@@ -0,0 +1,69 @@
+# 失敗分類の実践例（10パターン）
+
+QAテスト失敗時の分類判断に迷った場合の参考事例集。
+
+---
+
+## A: 実装ミス
+
+### 例1: トークン検証エラー
+**症状**: `TypeError: Cannot read property 'token' of undefined`
+**判定**: **A: 実装ミス**（nullチェック漏れ）
+**戻し先**: task-executer
+
+### 例5: ユニットテスト失敗
+**症状**: `pnpm test` で5件失敗
+**判定**: **A: 実装ミス**
+**戻し先**: task-executer
+
+### 例6: Lintエラー
+**症状**: `pnpm lint` でBiomeエラー10件
+**判定**: **A: 実装ミス**（コーディング規約違反）
+**戻し先**: task-executer
+
+### 例8: ビルドエラー
+**症状**: `pnpm build` でTypeScriptエラー
+**判定**: **A: 実装ミス**（型エラー）
+**戻し先**: task-executer
+
+---
+
+## B: 要件齟齬
+
+### 例2: バリデーションエラーメッセージ不一致
+**症状**: requirements.md「400エラー」、実装「422エラー」
+**判定**: **B: 要件齟齬**（ステータスコード不明確）
+**戻し先**: requirements.md修正 → task-executer
+
+### 例9: AC間の矛盾
+**症状**: AC1.2「即座削除」vs AC1.3「バッチ削除」
+**判定**: **B: 要件齟齬**（AC間矛盾）
+**戻し先**: requirements.md修正 → task-executer
+
+---
+
+## C: 設計不備
+
+### 例3: トランザクション未実装
+**症状**: 競合状態で整合性が保証されない
+**判定**: **C: 設計不備**（トランザクション設計欠如）
+**戻し先**: design.md修正 → task-executer
+
+### 例10: DBスキーマ設計ミス
+**症状**: インデックス不適切でパフォーマンス劣化
+**判定**: **C: 設計不備**（スキーマ設計ミス）
+**戻し先**: design.md修正 → task-executer
+
+---
+
+## D: 環境問題
+
+### 例4: PostgreSQL接続エラー
+**症状**: `Error: connect ECONNREFUSED 127.0.0.1:5432`
+**判定**: **D: 環境問題**（コンテナ未起動）
+**戻し先**: qa再実行（環境修復後）
+
+### 例7: Playwright MCPタイムアウト
+**症状**: `Timeout 30000ms exceeded`（ネットワーク遅延）
+**判定**: **D: 環境問題**
+**戻し先**: qa再実行

package/presets/minimal/.claude/skills/einja/task-qa/reference/troubleshooting.md

@@ -0,0 +1,65 @@
+# トラブルシューティング（6ケース）
+
+QA実行時によくある問題と対処法。
+
+---
+
+## 5.1 Playwright MCP 接続失敗
+
+**症状**: `Error: Failed to connect to Playwright MCP server`
+
+**対処法**:
+1. `claude mcp status` でステータス確認
+2. `claude mcp restart playwright` で再起動
+3. ポート確認: `lsof -i :3000`
+
+---
+
+## 5.2 requirements.md 不在
+
+**症状**: `Error: requirements.md not found`
+
+**対処法**:
+1. 仕様書ディレクトリパスを確認
+2. 不在の場合はspec-requirements-generatorで作成
+
+**失敗分類**: D（環境問題）またはB（要件未定義）
+
+---
+
+## 5.3 qa-tests/ 書き込み権限エラー
+
+**症状**: `Error: EACCES: permission denied`
+
+**対処法**:
+1. `ls -la {spec_dir}/qa-tests/` で権限確認
+2. `chmod -R u+w {spec_dir}/qa-tests/` で権限変更
+3. 不在時は `mkdir -p {spec_dir}/qa-tests/phase{N}/evidence/`
+
+---
+
+## 5.4 必須自動テストの失敗
+
+**判定**: **必ずFAILURE**（PARTIAL禁止）
+
+**対処法**: 失敗原因を分類（A/B/C/D）し適切な戻し先に差し戻し
+
+---
+
+## 5.5 タイムアウト問題
+
+**症状**: `Timeout 30000ms exceeded`
+
+**対処法**: Playwrightタイムアウトを60秒に延長
+
+**失敗分類**: D（一時的遅延）またはC（パフォーマンス設計ミス）
+
+---
+
+## 5.6 AC抽出エラー
+
+**症状**: `Warning: No Integration or E2E acceptance criteria found`
+
+**対処法**:
+1. requirements.mdで「検証レベル: Integration/E2E」の記載を確認
+2. 必要な場合はB（要件齟齬）として差し戻し

package/presets/minimal/.claude/skills/einja/task-qa/reference/usage-patterns.md

@@ -0,0 +1,52 @@
+# 利用パターン（5パターン）
+
+task-qa Skillの利用方法パターン集。
+
+---
+
+## パターン1: task-execからの呼び出し（標準ワークフロー）
+
+```
+ユーザー: task-exec #123 1.1
+  → starter → executer → reviewer → qa
+                                      ↓
+                            task-qa.md（ラッパー）→ SKILL.md
+                                      ↓
+                            結果JSON返却 → task-qa.md完了報告生成
+```
+
+**重要**: 既存フォーマット（`## 🧪 品質保証フェーズ完了`）を維持
+
+---
+
+## パターン2: 独立使用（Model-Invoked）
+
+**トリガーワード**: "QAを実行"、"品質保証を実施"、"テストを確認"
+
+```
+ユーザー: "docs/specs/tasks/user-auth/ のQAを実行して"
+  → Skill自動起動 → QA実行 → 結果報告
+```
+
+---
+
+## パターン3: CLI明示的呼び出し（将来機能）
+
+```bash
+claude skill task-qa --spec-dir docs/specs/tasks/user-auth/
+```
+
+---
+
+## パターン4: CI/CD統合
+
+GitHub Actionsで自動QA実行（将来実装）
+
+---
+
+## パターン5: 手動QAレビュー
+
+```
+ユーザー: "タスク1.1のQA結果を見せて"
+  → qa-tests/phase1/1-1.md読み込み → 結果サマリー表示
+```

package/presets/minimal/.claude/skills/einja/task-qa/templates/qa-test-template.md

@@ -0,0 +1,128 @@
+# Phase {phase_num}-{group_num}: {task_name} QAテスト結果
+
+## テスト対象タスク
+- **タスクID**: {開始タスクID}～{終了タスクID}
+- **タスク名**: {task_name}
+- **実装日**: {date}
+- **テスター**: {tester}
+- **最終更新**: {date}
+
+## テストサマリー
+| ステータス | 件数 |
+|----------|-----|
+| ✅ PASS | 0 |
+| ❌ FAIL | 0 |
+| ⚠️ PARTIAL | 0 |
+| 🔄 未実施 | 0 |
+
+---
+
+## 必須自動テスト結果
+
+### 実行コマンド
+```bash
+# 1. ユニットテスト
+pnpm test
+
+# 2. E2Eテスト（該当する場合）
+pnpm test:e2e
+
+# 3. Lintチェック
+pnpm lint
+
+# 4. ビルドチェック
+pnpm build
+
+# 5. 型チェック（TypeScript）
+pnpm typecheck
+```
+
+### 結果
+| テスト項目 | ステータス | 備考 |
+|----------|----------|------|
+| ユニットテスト | 🔄 | - |
+| E2Eテスト | 🔄 | - |
+| Lintチェック | 🔄 | - |
+| ビルドチェック | 🔄 | - |
+| 型チェック | 🔄 | - |
+
+**重要**: 上記のいずれか1つでも失敗した場合、全体ステータスは**❌ FAIL**となります。
+
+---
+
+## タスク {task_id}: {task_name}
+
+### 受け入れ条件
+<!-- requirements.md から該当ACの受け入れ条件を転記 -->
+- AC{N}.{M}: {Given-When-Then形式の基準}
+
+### テストシナリオ
+
+#### {test_category_name}
+
+| No | 手順 | 確認項目 | 期待値 | 結果 | 備考 |
+|----|------|---------|--------|------|------|
+| 1 | {step_description} | {check_item} | {expected_value} | - | - |
+| 2 | {step_description} | {check_item} | {expected_value} | - | - |
+
+**重要**:
+- 手順は自然言語で簡潔に記述（例: 「ログイン画面に移動」「メールアドレス入力: test@example.com」）
+- 「-」は手順のみで確認項目がない場合に使用
+- 備考欄はテストの区切りや注意事項を記載
+
+### 全体ステータス: - （未実施）
+
+#### 主な問題点
+- （実施後に記載）
+
+#### 対応策
+- （実施後に記載）
+
+#### エビデンス
+- ログファイル: `qa-tests/phase{phase_num}/evidence/{task_id}-{evidence_id}.log`
+- スクリーンショット: `qa-tests/phase{phase_num}/evidence/{task_id}-{evidence_id}.png`
+
+---
+
+<!-- 追加のタスクがある場合は上記セクションを繰り返す -->
+
+---
+
+## 統合テスト結果サマリー
+
+### フェーズ{phase_num}-{group_num}全体結果
+- **全体ステータス**: - （未実施）
+- **完了タスク**: 0/{total_tasks}
+- **テスト合格率**: 0% (0/0)
+
+### 修正が必要な項目
+- （実施後に記載）
+
+### 次フェーズへの引き継ぎ事項
+- （実施後に記載）
+
+### 改善提案
+- （実施後に記載）
+
+---
+
+## 報告と対応
+
+### 失敗原因分類
+<!-- 該当する分類にチェック -->
+- [ ] **A: 実装ミス** → task-executerへ差し戻し
+- [ ] **B: 要件齟齬** → requirements.md修正 → task-executerへ差し戻し
+- [ ] **C: 設計不備** → design.md修正 → task-executerへ差し戻し
+- [ ] **D: 環境問題** → qa再実行
+
+### task-executerへの差し戻し（該当する場合）
+以下の項目について修正が必要:
+- （実施後に記載）
+
+### 修正優先度
+- **即座対応**: （実施後に記載）
+- **1週間以内**: （実施後に記載）
+- **2週間以内**: （実施後に記載）
+
+### 回避策（該当する場合）
+- （実施後に記載）