@einja/dev-cli 0.1.6

package/presets/minimal/.claude/commands/einja/sync-cursor-commands.md

@@ -0,0 +1,203 @@
+---
+description: ".claude/commands配下のコマンドを.cursor/commands用に自動変換"
+---
+
+# Cursor コマンド同期ツール
+
+## あなたの役割
+
+あなたは Claude Code のカスタムコマンドを Cursor 互換形式に自動変換する専門家です。`.claude/commands/` 配下の全コマンドファイルをスキャンし、Cursor で動作する形式に変換して `.cursor/commands/` に保存します。
+
+## 処理フロー
+
+### 1. ソースファイルのスキャン
+
+**実行手順**:
+```bash
+# .claude/commands 配下の全 .md ファイルを検索
+Glob: .claude/commands/*.md
+```
+
+各ファイルを Read で読み込み、変換対象として処理します。
+
+**除外対象**:
+以下のファイルは変換対象から除外します：
+- `sync-cursor-commands.md`（このファイル自体。Claude Code専用機能のため）
+
+### 2. 変換処理
+
+各ファイルに対して以下の変換を実行します：
+
+#### 2.1 サブエージェント参照の検出と変換
+
+**検出パターン**:
+以下のようなサブエージェント参照を検出します：
+- 「Task ツールで {subagent_name} を呼び出す」
+- 「{subagent_name} サブエージェントを使用」
+- 「Task({subagent_type}: {subagent_name})」
+
+**サブエージェントファイルパスの特定**:
+`.claude/agents/` 配下を再帰的に検索し、`{サブエージェント名}.md` に一致するファイルを使用
+
+例：
+- `task-executer` → `.claude/agents/task/task-executer.md`
+- `spec-requirements-generator` → `.claude/agents/specs/spec-requirements-generator.md`
+
+**変換テンプレート**:
+
+変換前（Claude Code 形式）の記述を、以下のテンプレートで置き換えます：
+
+```markdown
+{subagent_name} の処理を実行：
+
+**📖 サブエージェントプロンプトの読み込み**
+- `.claude/agents/` 配下から `{subagent_name}.md` を検索して Read ツールで読み込む
+- YAML フロントマター（`---` で囲まれた部分）を除外
+- 本文のプロンプト内容を取得
+
+**🔨 プロンプトに従った処理の実行**
+- 取得したプロンプト内容に記載された手順・指示に従って処理を実行
+- プロンプト内の「自動探索・実行プロセス」セクションの手順を順次実行
+- プロンプト内の「出力形式」セクションを確認
+
+**📋 完了報告**
+- サブエージェント定義ファイルの「出力形式」セクションに記載された形式で報告を出力
+- 報告内容は構造化マークダウン（絵文字付き見出し使用）
+```
+
+#### 2.2 Cursor 用の注意書きを追加
+
+ファイルの冒頭（YAML フロントマターの直後）に以下のセクションを追加：
+
+```markdown
+---
+[既存のYAMLフロントマター]
+---
+
+> **⚠️ Cursor での動作について**
+>
+> このコマンドは `.claude/agents/` 配下のサブエージェント定義ファイルを参照します。
+> サブエージェント呼び出し箇所では、該当する `.md` ファイルを Read で読み込み、
+> そのプロンプト内容に従って処理を実行してください。
+>
+> **サブエージェント実行の手順**:
+> 1. サブエージェント `.md` ファイルを Read で読み込む
+> 2. YAML フロントマターを除外し、本文プロンプトを取得
+> 3. プロンプトの指示に従って処理を実行
+> 4. プロンプト内の「出力形式」に従った報告を生成
+
+[既存のコマンド内容]
+```
+
+### 3. ファイルの出力
+
+変換後のファイルを `.cursor/commands/` に Write します：
+
+```bash
+# 例
+.claude/commands/task-exec.md → .cursor/commands/task-exec.md
+.claude/commands/spec-create.md → .cursor/commands/spec-create.md
+```
+
+### 4. 変更サマリーの表示
+
+処理完了後、以下の形式で報告を出力してください：
+
+```markdown
+## 🎉 Cursor コマンド同期完了
+
+### 処理サマリー
+- **変換元ディレクトリ**: `.claude/commands/`
+- **変換先ディレクトリ**: `.cursor/commands/`
+- **処理ファイル数**: N個
+
+### 変換済みファイル一覧
+1. ✅ spec-create.md
+   - サブエージェント参照: 3箇所変換
+
+2. ✅ task-exec.md
+   - サブエージェント参照: 4箇所変換
+
+3. ✅ start-dev.md
+   - 変換不要（サブエージェント参照なし）
+
+4. ✅ update-docs-by-task-specs.md
+   - 変換不要（サブエージェント参照なし）
+
+### 除外されたファイル
+- ⏭️ sync-cursor-commands.md（Claude Code専用機能のため除外）
+
+### 次のステップ
+Cursor で以下のコマンドが利用可能になりました：
+- `/spec-create`
+- `/task-exec`
+- `/start-dev`
+- `/update-docs-by-task-specs`
+```
+
+
+## 変換時の注意事項
+
+### 保持すべき内容
+- YAML フロントマター（description など）
+- コマンドの基本的なロジックと手順
+- ユーザー向けの説明文
+- 実行例とサンプルコード
+
+### 変更すべき内容
+- `Task` ツール呼び出し → サブエージェントファイル読み込み形式
+- サブエージェント参照の説明
+- Cursor 固有の注意書き追加
+
+### 削除すべき内容
+- Claude Code 固有のツール説明（Task ツールの使い方など）
+- サブエージェント実行の内部実装詳細
+
+
+## 使用例
+
+```bash
+# コマンド実行
+/sync-cursor-commands
+
+# 実行結果
+✅ 4個のコマンドファイルを変換しました
+- spec-create.md: 3箇所のサブエージェント参照を変換
+- task-exec.md: 4箇所のサブエージェント参照を変換
+- start-dev.md: 変換不要
+- update-docs-by-task-specs.md: 変換不要
+```
+
+## エラー処理
+
+以下のエラーに適切に対処してください：
+
+1. **ソースファイルが存在しない**
+   - `.claude/commands/` ディレクトリが空の場合
+   - エラーメッセージを表示して終了
+
+2. **サブエージェントファイルが見つからない**
+   - 参照されているサブエージェントファイルが存在しない場合
+   - 警告を表示し、該当箇所をスキップ
+
+3. **書き込み権限エラー**
+   - `.cursor/commands/` ディレクトリが書き込み不可の場合
+   - エラーメッセージを表示して終了
+
+## 拡張性
+
+### 新しいサブエージェントの追加
+
+将来的に新しいサブエージェントが追加された場合：
+
+1. `.claude/agents/` 配下に新しいサブエージェントファイルを配置
+2. 必要に応じてサブディレクトリで整理
+3. このツールは自動的にファイルを検索して変換（設定変更不要）
+
+### カスタマイズ
+
+プロジェクト固有のニーズに応じて、以下をカスタマイズ可能：
+
+- 変換テンプレートの形式
+- 注意書きの内容
+- エラーハンドリングの詳細度

package/presets/minimal/.claude/commands/einja/task-exec.md

@@ -0,0 +1,390 @@
+---
+description: "GitHub Issueのタスクグループを実行するコマンド。ARGUMENTS: Issue番号（必須、#123形式）とタスクグループ番号（必須、1.1形式）"
+allowed-tools: Task, Read, Write, Edit, MultiEdit, Bash, Grep, Glob, WebFetch, mcp__github__*, mcp__serena__*
+---
+
+# タスク実行コマンド
+
+## 役割
+
+指定されたタスクグループの実装を管理し、QA合格まで自動的にループ実行する。
+
+## 入力の解析
+
+$ARGUMENTSから以下を解析：
+- **Issue番号**（必須、例: `#123`、`123`）
+- **タスクグループ番号**（必須、例: `1.1`、`2.3`）
+
+どちらかが欠けている場合はユーザーに要求する。
+
+解析した値は、各サブエージェント呼び出し時のpromptに含めて渡す。
+
+## サブエージェント出力の表示ルール
+
+サブエージェントの出力表示は、**CLAUDE.mdの「サブエージェント結果報告のルール」セクションに従うこと**。
+
+### 要点
+- Taskツールから返却されたメッセージを**そのまま全文出力**する
+- 出力後、次のフェーズへの移行メッセージを追加する
+- 省略・要約・言い換えは**禁止**
+
+## 処理フロー
+
+### タスク種別の判定
+
+タスクグループ番号の先頭（Phase番号）に基づいて処理を分岐：
+
+| Phase番号 | 判定 | 処理フロー |
+|-----------|------|-----------|
+| 1〜98 | 通常タスク | task-executer → task-reviewer → task-qa → task-committer |
+| 99 | ドキュメント反映タスク | docs-updater → task-committer |
+
+### 通常タスクのフロー（Phase 1〜98）
+
+```
+┌─────────────────────────────────────────────────────────┐
+│                    品質保証ループ                        │
+│                                                         │
+│  task-executer → task-reviewer → task-qa               │
+│       ↑              │              │                   │
+│       └──────────────┴──────────────┘                   │
+│          （MAJOR/テスト失敗時は自動的に戻る）             │
+│                                                         │
+│  QA合格後 ↓                                             │
+│  ┌─────────────────────────────────────────────┐       │
+│  │ task-committer（コミット・プッシュ）          │       │
+│  │ ※ 確認なしで自動実行                         │       │
+│  └─────────────────────────────────────────────┘       │
+│                                                         │
+└─────────────────────────────────────────────────────────┘
+                           │
+                           ↓ コミット完了
+                   追加指示待ち状態
+                           │
+              ┌────────────┴────────────┐
+              ↓                         ↓
+    ユーザーが追加指示           ユーザーが「終了」
+              │                         │
+              ↓                         ↓
+    task-modification-analyzer      コマンド終了
+              │
+              ↓ 承諾後
+    推奨パターンで実行
+              │
+              └──→ 追加指示待ち状態に戻る
+```
+
+### Phase 99 タスクのフロー（ドキュメント反映）
+
+```
+┌─────────────────────────────────────────────────────────┐
+│               ドキュメント反映フロー                       │
+│                                                         │
+│  docs-updater（タスク仕様書をfeature/steering仕様書に反映）│
+│       │                                                 │
+│       ↓ 反映完了                                        │
+│  ┌─────────────────────────────────────────────┐       │
+│  │ task-committer（コミット・プッシュ）          │       │
+│  │ ※ 確認なしで自動実行                         │       │
+│  └─────────────────────────────────────────────┘       │
+│                                                         │
+└─────────────────────────────────────────────────────────┘
+                           │
+                           ↓ コミット完了
+                       コマンド終了
+```
+
+**Phase 99 の特徴**:
+- task-executer、task-reviewer、task-qa をスキップ
+- docs-updater エージェントを直接呼び出し
+- 追加指示待ち状態なし（完了後は即座に終了）
+
+各フェーズ完了後、サブエージェントの出力を表示したら即座に次のフェーズへ進む。ユーザーの応答は待たない。
+
+### 1. 実装フェーズ（task-executer）
+- 要件定義・設計書に基づいた実装を実行
+- 完了後、出力を表示して即座にレビューフェーズへ
+
+### 2. レビューフェーズ（task-reviewer）
+- 要件定義・設計との整合性確認
+- MAJOR判定 → 実装フェーズに戻る
+- PASS/MINOR判定 → 品質保証フェーズへ
+
+### 3. 品質保証フェーズ（task-qa）
+- 受け入れ条件に基づく動作確認
+- テスト失敗 → 実装フェーズに戻る
+- 全テスト合格 → コミット・プッシュフェーズへ
+
+### 4. コミット・プッシュフェーズ（task-committer）
+- QA合格後、自動的にコミット・プッシュを実行
+- 変更がある場合のみ実行（変更なしの場合はスキップ）
+- コミット分割案の確認はスキップ（QA合格済みのため自動適用）
+- 品質チェック（lint/typecheck/test/build）はQAで実行済みのためスキップ
+- 完了後、追加指示待ち状態へ
+
+### 5. Phase 99 タスクの処理（docs-updater）
+
+タスクグループ番号が `99.*` 形式の場合、以下のフローで処理：
+
+1. **タスク種別判定**
+   - タスクグループ番号の先頭が `99` かどうかを確認
+   - 例: `99.1` → Phase 99 タスク
+
+2. **docs-updater の呼び出し**
+   - Task ツールで docs-updater エージェントを呼び出し
+   - prompt に以下を含める：
+     - Issue番号
+     - タスクグループ番号
+     - 対象タスクspecのパス（全Phaseで完了したタスクspec）
+
+3. **コミット・プッシュ**
+   - docs-updater 完了後、task-committer を呼び出し
+   - ドキュメント変更をコミット・プッシュ
+
+4. **終了**
+   - Phase 99 タスクは追加指示待ち状態なし
+   - 完了後、即座にコマンド終了
+
+**docs-updater への prompt 例**:
+```
+Issue #123 のPhase 99 タスク（タスクグループ 99.1）を実行してください。
+
+以下のタスクspecをfeature/steering仕様書に反映してください：
+- docs/specs/tasks/feature-name/20251104-task1
+- docs/specs/tasks/feature-name/20251105-task2
+```
+
+---
+
+## 受け入れ条件の参照方法
+
+このセクションは、task-executer、task-reviewer、task-qaサブエージェントが受け入れ条件を参照する際の標準手順を定義します。
+
+### requirements.mdの標準構造
+
+**必須セクション**:
+- **受け入れ基準（Acceptance Criteria）**: 各ACが以下の形式で記載
+
+**AC（Acceptance Criteria）の形式**:
+```markdown
+##### 機能要件
+- [ ] Given: 前提条件
+      When: 実行する操作
+      Then: 期待される結果
+```
+
+### task-executerの受け入れ条件参照方法
+
+1. タスクグループの関連ドキュメント（`requirements.md`）を読み込む
+2. 各ユーザーストーリー配下の「受け入れ基準」セクションを特定
+3. **検証レベルが「Unit」の AC のみ**を実装対象とする
+4. 各 AC（Given/When/Then）に対して実装と単体テストを作成
+5. `design.md` の技術仕様に準拠した実装を行う
+
+**検証責務**:
+- **Unit テスト**: 必須実装、実装と同時に作成
+- **Integration/Browser テスト**: 実装不要（task-qa が担当）
+
+**完了条件**:
+- 実装したコードの単体テストが全て合格
+- 検証レベルが「Unit」の AC を全て満たす
+- Integration/Browser レベルの AC は未検証でも実装フェーズ完了とする
+
+> **Note**: 検証レベルの詳細は `docs/einja/steering/terminology.md` を参照してください。
+
+### task-reviewerの受け入れ条件参照方法
+
+1. `requirements.md` の各ユーザーストーリー配下の「受け入れ基準」セクションを参照
+2. 実装が各ACを満たしているかを確認
+3. ACとの整合性をレビュー観点の最優先項目とする
+
+### task-qaの受け入れ条件参照方法
+
+**⚠️ 最重要**: QAエージェントは以下の手順で受け入れ条件を参照
+
+1. **受け入れ基準の抽出**
+   - タスクグループの `requirements.md` を読み込む
+   - 各ユーザーストーリー配下の「受け入れ基準」セクションを特定
+   - **検証レベルが「Integration」「Browser」の AC のみ**を抽出
+   - 検証レベルが「Unit」の AC はスキップ（task-executer が既に検証済み）
+
+2. **テストシナリオの作成**
+   - 各 AC に対して、Given/When/Then に基づくテストシナリオを作成
+   - Integration: API + DB + ミドルウェアの連携テスト
+   - Browser: Playwright MCP を使用したユーザーシナリオテスト
+   - QA 仕様書（`qa-tests/phaseN/X-Y.md`）に記録
+
+3. **SUCCESS 判定基準**
+   - **検証レベルが「Integration」「Browser」の全ての AC が満たされた場合のみ**、SUCCESS 判定
+   - 1つでも AC を満たさない場合、FAILURE 判定して適切な戻し先を決定
+
+> **用語の明確化**: 「E2E」はPlaywrightコードによる自動テスト（`pnpm test:e2e`）を指します。task-qaが実行するPlaywright MCPテストは「Browser」検証レベルです。詳細は `docs/einja/steering/terminology.md` を参照してください。
+
+4. **参照ドキュメント**
+   - QA テスト項目作成方針: `docs/einja/steering/acceptance-criteria-and-qa-guide.md`
+   - テンプレート: `docs/einja/templates/requirements.md.template`
+
+---
+
+## 失敗時のリカバリーフロー
+
+### 失敗原因の分類
+
+task-qa は以下の基準で失敗原因を分類し、適切な戻し先を決定します：
+
+#### A: 実装ミス（コードロジックの問題）
+- **症状**: 期待値と実際の挙動が異なる、エラーが発生
+- **戻し先**: task-executer（実装フェーズ）
+- **対応**: コード修正 → 再度 reviewer → qa
+- **例**: API が 404 を返す、バリデーションが動作しない
+
+#### B: 要件理解の齟齬（要件定義の問題）
+- **症状**: 実装は正しいが、要件と一致しない
+- **戻し先**: requirements.md 修正 → 再度 task-executer
+- **対応**: 要件明確化 + 再実装 → reviewer → qa
+- **例**: 想定していなかったエッジケース、曖昧な要件の誤解
+
+#### C: 設計不備（アーキテクチャの問題）
+- **症状**: 実装方法が技術的に不適切
+- **戻し先**: design.md 修正 → 再度 task-executer
+- **対応**: 設計見直し + 再実装 → reviewer → qa
+- **例**: パフォーマンス問題、セキュリティ脆弱性
+
+#### D: テスト環境の問題（一時的なエラー）
+- **症状**: 実装は正しいが、環境要因で失敗
+- **戻し先**: QA 再実行（修正不要）
+- **対応**: 環境調整のみ
+- **例**: ネットワークタイムアウト、データベース接続エラー
+
+### task-qa の判定ロジック
+
+1. テスト結果を詳細に確認
+2. 失敗原因を以下の 4 分類に分類:
+   - A: 実装ミス
+   - B: 要件理解の齟齬
+   - C: 設計不備
+   - D: テスト環境の問題
+3. 分類に基づいて戻し先を決定
+4. 完了報告に分類結果と推奨アクションを明記
+5. 分類に応じた戻し先に自動的に進む
+
+---
+
+## QA仕様書の作成・更新フロー
+
+### 初回実行時（qa-tests/phaseN/X-Y.md が存在しない場合）
+
+1. **ファイルの新規作成**
+   - タスクグループ番号に基づいて `qa-tests/phaseN/X-Y.md` を新規作成
+   - 例: タスクグループ1.1 → `qa-tests/phase1/1-1.md`
+
+2. **受け入れ基準の抽出**
+   - `requirements.md` の各ユーザーストーリー配下の「受け入れ基準」セクションから各ACを抽出
+
+3. **テストシナリオの作成**
+   - 各ACに対してテストシナリオを作成
+   - テンプレート: `docs/einja/steering/acceptance-criteria-and-qa-guide.md` 参照
+
+4. **QA仕様書の構造**:
+```markdown
+## 機能名: [タスク名]
+- 背景/価値: [requirements.mdから抽出]
+- 関連 AC: AC1.1, AC1.2, AC2.1
+- テスト範囲: Integration / Browser
+
+- シナリオ:
+  1. [AC1.1に対応するシナリオ]
+     - 前提: [Given]
+     - 操作: [When]
+     - 期待結果: [Then]
+     - ログ/メトリクス確認方法: [確認手段]
+
+### 実施結果（最終更新: YYYY-MM-DD）
+**ステータス: [✅ SUCCESS / ❌ FAILURE / ⚠️ PARTIAL]**
+```
+
+### 2回目以降の実行時（qa-tests/phaseN/X-Y.md が既に存在する場合）
+
+1. **既存ファイルの読み込み**
+   - `qa-tests/phaseN/X-Y.md` を読み込む
+
+2. **更新対象の特定**
+   - 「実施結果」セクションのみを更新対象とする
+   - シナリオ部分は**保持**（変更しない）
+
+3. **結果の記録**
+   - 最新のテスト実施結果を「実施結果」セクションに追記
+   - ステータスを更新（SUCCESS / FAILURE / PARTIAL）
+
+---
+
+## 追加指示待ち状態
+
+QA合格後、以下を表示：
+
+```
+タスクグループの実装が完了しました。
+
+追加の修正や改善がある場合は指示してください。
+完了する場合は「終了」または「完了」と入力してください。
+```
+
+### 追加修正の対応（task-modification-analyzer）
+
+ユーザーから追加指示があった場合、以下の手順で対応：
+
+#### 1. 修正規模の確認
+
+まず、修正の規模を確認するため、AskUserQuestionで以下を提示：
+
+```yaml
+AskUserQuestion:
+  question: "追加修正の規模を確認してください"
+  header: "修正規模の選択"
+  options:
+    - label: "小規模（ロジック修正のみ）"
+      description: "メリット: 迅速に対応可能。デメリット: 影響範囲を見逃す可能性。対応: task-executerのみで実施"
+    - label: "中規模（複数ファイル修正）"
+      description: "メリット: 関連箇所も含めて修正。デメリット: 時間がかかる。対応: task-executer → task-reviewer"
+    - label: "大規模（設計変更が必要）"
+      description: "メリット: 根本的な問題解決。デメリット: 全ワークフローの再実行が必要。対応: requirements.md/design.md修正後に再実行"
+```
+
+#### 2. 修正内容の曖昧性確認（必要な場合）
+
+修正内容が不明確な場合、以下をAskUserQuestionで確認：
+
+```yaml
+AskUserQuestion:
+  question: "修正内容を明確にしてください"
+  header: "修正内容の分類"
+  options:
+    - label: "追加機能の実装"
+      description: "メリット: 新機能追加で価値向上。デメリット: 既存機能への影響リスク。対応: 新しい機能やコンポーネントを追加"
+    - label: "既存機能の変更"
+      description: "メリット: 要件に合った改善。デメリット: 回帰テストが必要。対応: 既存の動作を変更または拡張"
+    - label: "バグ修正"
+      description: "メリット: 品質向上、ユーザー満足度向上。デメリット: 根本原因の調査に時間がかかる場合あり。対応: 期待通りに動作しない箇所を修正"
+    - label: "リファクタリング"
+      description: "メリット: 保守性向上、技術的負債の解消。デメリット: 短期的には機能追加なし。対応: 機能は変えずにコード品質を改善"
+```
+
+#### 3. task-modification-analyzerの呼び出し
+
+上記の確認後、task-modification-analyzerを呼び出し：
+1. Issue番号、タスクグループ番号、ユーザー指示を渡す
+2. 分析結果を表示してユーザーの承諾を待つ
+3. 承諾後、推奨パターンで実行：
+   - 小規模修正: task-executerのみ
+   - 中規模以上: task-executer → task-reviewer → task-qa
+4. 完了後、追加指示待ち状態に戻る
+
+### 終了条件
+
+ユーザーが「終了」「完了」「done」と入力した場合、コマンドを終了。
+
+## 注意事項
+
+- Issue番号とタスクグループ番号の両方が必須
+- GitHub Issueのチェックボックス更新は自動では行わない
+- コミット時は [コミットルール](../../docs/einja/steering/commit-rules.md) を遵守