@einja/dev-cli 0.1.20 → 0.1.23

package/scaffolds/instructions/task-vibe-kanban-loop.md

@@ -15,7 +15,7 @@ GitHub Issue からタスクを自動選定し、Vibe-Kanban に登録して連
 
 ```bash
 # 1. 仕様書を作成（requirements.md, design.md, GitHub Issue へのタスク記述）
-/spec-create <タスク内容の説明>
+/einja:spec-create <タスク内容の説明>
 
 # 一旦ここまで終わったらDiscordでスレッドを作りチームにレビュー依頼
 
@@ -444,11 +444,11 @@ sequenceDiagram
 
 ---
 
-## `/task-exec` との使い分け
+## `/einja:task-exec` との使い分け
 
 | コマンド | 用途 | 品質保証 | 推奨シーン |
 |---------|------|---------|----------|
-| **`/task-exec`** | 重要タスクの確実な完了 | ✅ 合格まで自動ループ | 複雑な実装、品質重視 |
+| **`/einja:task-exec`** | 重要タスクの確実な完了 | ✅ 合格まで自動ループ | 複雑な実装、品質重視 |
 | **`pnpm task:loop`** | 大量タスクの自動消化 | 並列実行・監視 | 定型作業、並行開発 |
 
 ---
@@ -479,9 +479,9 @@ packages/cli/src/commands/task-loop/
 
 ## 関連ドキュメント
 
-- [タスク実行ワークフロー](./task-execute.md)
+- [タスク実行ワークフロー](./einja:task-execute.md)
 - [タスク管理ガイドライン](../steering/task-management.md)
-- [仕様書作成ワークフロー](./spec-create.md)
+- [仕様書作成ワークフロー](./einja:spec-create.md)
 - [ブランチ運用戦略](../steering/branch-strategy.md) - ブランチ命名規則、同期フロー、ワークフロー図
 <!-- @einja:managed:end -->
 

package/scaffolds/steering/acceptance-criteria-and-qa-guide.md

@@ -99,7 +99,7 @@ ACx.y: <振る舞いの名前>
 ```
 
 **シナリオテストの設計タイミング**:
-- `/spec-create` コマンドの QAテスト仕様生成フェーズで作成
+- `/einja:spec-create` コマンドの QAテスト仕様生成フェーズで作成
 - requirements.md の受け入れ条件を分析し、複数ACをまたぐフローを特定
 - タスク分割前に完了させる
 

package/scaffolds/steering/development-workflow.md

@@ -8,7 +8,7 @@
 本プロジェクトでは、Claude Codeを活用した自動化された開発ワークフローを採用しています。
 
 ```
-仕様書作成（/spec-create）
+仕様書作成（/einja:spec-create）
     ↓
 仕様書レビュー（Discord + Spec PR）
     ↓
@@ -30,15 +30,15 @@
 │ Phase A: 仕様書作成                                                          │
 ├─────────────────────────────────────────────────────────────────────────────┤
 │                                                                              │
-│  /spec-create <タスク内容の説明またはAsanaタスクURL>                          │
+│  /einja:spec-create <タスク内容の説明またはAsanaタスクURL>                          │
 │      │                                                                       │
 │      ├── 1. （AsanaURLの場合）Asanaからタスク情報取得                         │
 │      ├── 2. GitHub Issue作成                                                 │
-│      ├── 3. requirements.md作成 → ユーザー承認 → コミット                      │
-│      ├── 4. design.md作成 → ユーザー承認 → コミット                           │
-│      ├── 5. GitHub Issueにタスク一覧記述 → ユーザー承認                        │
-│      ├── 6. issue/{番号}ブランチ作成                                         │
-│      ├── 7. 仕様書をブランチにプッシュ                                        │
+│      ├── 3. IssueBranchBase選択（AskUserQuestion）                           │
+│      ├── 4. issue/{番号}ブランチ作成（IssueBranchBaseから）                   │
+│      ├── 5. requirements.md作成 → ユーザー承認 → コミット                      │
+│      ├── 6. design.md作成 → ユーザー承認 → コミット                           │
+│      ├── 7. GitHub Issueにタスク一覧記述 → ユーザー承認                        │
 │      └── 8. Spec PR作成                                                     │
 │                                                                              │
 │  成果物:                                                                     │
@@ -126,7 +126,7 @@
 ### コマンド
 
 ```bash
-/spec-create <タスク内容の説明またはAsanaタスクURL>
+/einja:spec-create <タスク内容の説明またはAsanaタスクURL>
 ```
 
 ### ステップ詳細
@@ -135,11 +135,11 @@
 | -------- | --------------------- | ------------------------------------- |
 | 1        | Claude                | タスク情報取得（AsanaURLの場合）      |
 | 2        | Claude                | GitHub Issue作成                      |
-| 3        | Claude → **人間承認** | requirements.md作成 → 確認 → コミット |
-| 4        | Claude → **人間承認** | design.md作成 → 確認 → コミット       |
-| 5        | Claude → **人間承認** | GitHub Issueにタスク一覧記述          |
-| 6        | Claude                | `issue/{番号}`ブランチ作成            |
-| 7        | Claude                | 仕様書をブランチにプッシュ            |
+| 3        | Claude → **人間承認** | IssueBranchBase選択                   |
+| 4        | Claude                | `issue/{番号}`ブランチ作成            |
+| 5        | Claude → **人間承認** | requirements.md作成 → 確認 → コミット |
+| 6        | Claude → **人間承認** | design.md作成 → 確認 → コミット       |
+| 7        | Claude → **人間承認** | GitHub Issueにタスク一覧記述          |
 | 8        | Claude                | **Spec PR作成**                       |
 | 9        | **人間**              | Discordでチームにレビュー依頼         |
 | 10       | **人間**              | Spec PRレビュー・承認・マージ         |
@@ -246,7 +246,7 @@ task-executer → task-reviewer → task-qa → In Review
 
 | PRの種類    | 作成タイミング       | 内容                       | レビュー観点                                   |
 | ----------- | -------------------- | -------------------------- | ---------------------------------------------- |
-| **Spec PR** | `/spec-create`完了時 | requirements.md, design.md | 要件の妥当性、設計の適切さ、スコープの確認     |
+| **Spec PR** | `/einja:spec-create`完了時 | requirements.md, design.md | 要件の妥当性、設計の適切さ、スコープの確認     |
 | **実装PR**  | タスクグループ完了時（Vibe-KanbanでCreate PR） | ソースコード、テスト       | コード品質、設計書との整合性、テストカバレッジ |
 
 ### なぜ2段階でPRを作成するのか
@@ -291,13 +291,13 @@ task-executer → task-reviewer → task-qa → In Review
 
 ```bash
 # タスク内容の説明から仕様書を作成
-/spec-create <タスク内容の説明>
+/einja:spec-create <タスク内容の説明>
 
 # AsanaタスクURLから仕様書を作成
-/spec-create <AsanaタスクURL>
+/einja:spec-create <AsanaタスクURL>
 
 # 既存仕様書のパスを指定して修正
-/spec-create <タスク内容> <既存仕様書パス>
+/einja:spec-create <タスク内容> <既存仕様書パス>
 ```
 
 ### タスク実行
@@ -315,17 +315,17 @@ pnpm task:loop 123 --max-group 4          # Phase 4 まで実行
 pnpm task:loop 123 --max-group 4.2        # タスクグループ 4.2 まで実行
 
 # 単一タスクグループ実行（品質重視・複雑な実装向け）
-/task-exec #<issue_number> <task_group_number>
+/einja:task-exec #<issue_number> <task_group_number>
 
 # 例
-/task-exec #123 1.1                 # Issue #123 のタスクグループ 1.1 を実行
+/einja:task-exec #123 1.1                 # Issue #123 のタスクグループ 1.1 を実行
 ```
 
-### `/task-exec` と `pnpm task:loop` の使い分け
+### `/einja:task-exec` と `pnpm task:loop` の使い分け
 
 | コマンド | 用途 | 品質保証 | 推奨シーン |
 |---------|------|---------|----------|
-| **`/task-exec`** | 重要タスクの確実な完了 | ✅ 合格まで自動ループ | 複雑な実装、品質重視 |
+| **`/einja:task-exec`** | 重要タスクの確実な完了 | ✅ 合格まで自動ループ | 複雑な実装、品質重視 |
 | **`pnpm task:loop`** | 大量タスクの自動消化 | 並列実行・監視 | 定型作業、並行開発 |
 
 ---

package/scaffolds/steering/infrastructure/deployment.md

@@ -40,21 +40,22 @@ graph TB
 
     subgraph "Railway Platform"
         CronProd[cron-worker - Production]
-        CronStaging[cron-worker - Staging]
     end
 
-    subgraph "Database"
-        DB[(PostgreSQL)]
+    subgraph "Neon Database"
+        DBProd[(Production DB)]
+        DBPreview[(Preview DB - 動的生成)]
     end
 
     Main -->|Auto Deploy| WebProd
     Main -->|Auto Deploy| CronProd
 
     Feature -->|PR Deploy| WebPreview
-    Feature -->|Manual Deploy| CronStaging
+    Feature -->|Create Branch| DBPreview
 
-    WebProd --> DB
-    CronProd --> DB
+    WebProd --> DBProd
+    WebPreview --> DBPreview
+    CronProd --> DBProd
 ```
 
 ### デプロイメント対象
@@ -63,6 +64,7 @@ graph TB
 |----------------|--------------|--------------|------|
 | web | Vercel | main push, PR作成 | Production, Preview |
 | cron-worker | Railway | main push | Production |
+| Database | Neon | main push, PR作成 | Production, Preview（動的生成） |
 
 ---
 
@@ -107,6 +109,7 @@ sequenceDiagram
     participant CI as GitHub Actions
     participant Turbo as Turborepo
     participant Cache as Vercel Cache
+    participant Neon as Neon Database
     participant Vercel as Vercel
     participant Railway as Railway
 
@@ -116,6 +119,12 @@ sequenceDiagram
     CI->>Turbo: turbo login
     Turbo->>Cache: キャッシュ認証
 
+    alt PR作成時
+        CI->>Neon: Create branch from main
+        Neon-->>CI: Preview DB URL
+        CI->>CI: Set DATABASE_URL
+    end
+
     CI->>Turbo: turbo run lint
     Turbo->>Cache: キャッシュチェック
     Cache-->>Turbo: キャッシュヒット/ミス
@@ -131,8 +140,10 @@ sequenceDiagram
     Turbo-->>CI: テスト完了
 
     alt main ブランチ
-        CI->>Vercel: web デプロイ
+        CI->>Vercel: web デプロイ（Production DB使用）
         CI->>Railway: cron-worker デプロイ
+    else PR作成時
+        CI->>Vercel: web preview デプロイ（Preview DB使用）
     end
 
     CI-->>Dev: ステータス通知

package/scaffolds/steering/infrastructure/environment-variables.md

@@ -35,8 +35,8 @@
 | 環境 | 管理ファイル | 暗号化 | Git追跡 |
 |------|-------------|--------|--------|
 | ローカル開発 | `.env.local` → `.env` + `.env.personal` | ✅ | `.env.local`のみ |
-| dev検証 | `.env.development` | ✅ | ✅ |
-| ステージング | `.env.staging` | ✅ | ✅ |
+| dev検証 | `.env.develop` | ✅ | ✅ |
+| preview | `.env.preview`（Neon環境変数含む） | ✅ | ✅ |
 | 本番 | `.env.production` | ✅ | ✅ |
 | CI/CD | `.env.ci` | ✅ | ✅ |
 
@@ -168,8 +168,8 @@ A: `.env` は毎回再生成されますが、秘密情報は `.env.local`（暗
 | `.env.example` | ✅ | ❌ | `.env`の参考テンプレート |
 | `.env.personal.example` | ✅ | ❌ | 個人用トークンのテンプレート |
 | `.env.local` | ✅ | ✅ | ローカル開発用（チーム共有） |
-| `.env.development` | ✅ | ✅ | dev検証サーバー用 |
-| `.env.staging` | ✅ | ✅ | ステージング用 |
+| `.env.develop` | ✅ | ✅ | dev検証サーバー用 |
+| `.env.preview` | ✅ | ✅ | Preview環境用（Neon環境変数含む） |
 | `.env.production` | ✅ | ✅ | 本番環境用 |
 | `.env.ci` | ✅ | ✅ | CI/CD用 |
 | `.env.keys` | ❌ | - | 全環境の秘密鍵（1Password等で共有） |
@@ -183,8 +183,8 @@ A: `.env` は毎回再生成されますが、秘密情報は `.env.local`（暗
 ├── .env.example            # 参考テンプレート（Git追跡）
 ├── .env.personal.example   # 個人用トークンテンプレート（Git追跡）
 ├── .env.local              # ローカル開発用・暗号化済み（Git追跡）★
-├── .env.development        # dev検証・暗号化済み（Git追跡）
-├── .env.staging            # ステージング・暗号化済み（Git追跡）
+├── .env.develop            # dev検証・暗号化済み（Git追跡）
+├── .env.preview            # Preview環境・暗号化済み（Git追跡・Neon環境変数含む）
 ├── .env.production         # 本番・暗号化済み（Git追跡）
 ├── .env.ci                 # CI/CD・暗号化済み（Git追跡）
 ├── .env.keys               # 秘密鍵（Git除外・1Password等で共有）
@@ -253,7 +253,7 @@ sequenceDiagram
 | 識別子 | 説明 |
 |--------|------|
 | `_LOCAL` | ローカル開発用 |
-| `_DEVELOPMENT` | dev検証環境用 |
+| `_DEVELOP` | dev検証環境用 |
 | `_STAGING` | ステージング環境用 |
 | `_PRODUCTION` | 本番環境用 |
 | `_CI` | CI/CD環境用 |
@@ -280,9 +280,12 @@ dotenvx採用により、GitHub Secretsは**環境ごとに1つの秘密鍵の
 | Secret名 | 用途 |
 |---------|------|
 | `DOTENV_PRIVATE_KEY_CI` | CI/CD環境の復号 |
+| `DOTENV_PRIVATE_KEY_PREVIEW` | Preview環境の復号（Neon環境変数含む） |
 | `DOTENV_PRIVATE_KEY_PRODUCTION` | 本番デプロイ時の復号 |
 
-**注**: `DOTENV_PRIVATE_KEY_LOCAL`はローカル開発用なのでGitHub Secretsには不要。`.env.keys`でチーム内共有。
+**注**:
+- `DOTENV_PRIVATE_KEY_LOCAL`はローカル開発用なのでGitHub Secretsには不要。`.env.keys`でチーム内共有。
+- Neon環境変数（`NEON_API_KEY`、`NEON_PROJECT_ID`）は`.env.preview`で管理されるため、GitHub Secretsへの個別登録は不要。
 
 ### ローテーション方針
 

package/scaffolds/steering/task-management.md

@@ -87,12 +87,12 @@ GitHub Issueのチェックボックスでタスクグループのステータ
 - [x] 1.1 タスクグループ名
 ```
 
-**注意**: タスクグループの完了時、GitHub Issueのチェックボックス更新はユーザーが明示的に指示した場合のみ行います。`/task-exec`コマンドは自動でIssueを更新しません。
+**注意**: タスクグループの完了時、GitHub Issueのチェックボックス更新はユーザーが明示的に指示した場合のみ行います。`/einja:task-exec`コマンドは自動でIssueを更新しません。
 
 ### Issueのライフサイクル
 
-1. **Issue作成**: `/spec-create`コマンドで仕様書作成時に自動生成
-2. **タスクグループ実行**: `/task-exec #{issue_number} {タスクグループ番号}`でタスクグループを実行
+1. **Issue作成**: `/einja:spec-create`コマンドで仕様書作成時に自動生成
+2. **タスクグループ実行**: `/einja:task-exec #{issue_number} {タスクグループ番号}`でタスクグループを実行
 3. **タスクグループ完了**: 実装・テスト・レビュー完了後、チェックボックスをON（手動更新）
 4. **Issue完了**: すべてのタスクグループが完了したらIssueをClose
 
@@ -160,6 +160,37 @@ ATDDの本質は「受け入れ基準（AC）を中心にタスクを分解す
 - Domain層の実装 / Infra層の実装 / UseCase実装 / API実装 / UI実装
 - 各層単体では検証不可能
 
+### ✅ 縦切り分割の具体例（価値単位）
+
+CRUD機能の場合、以下のように**価値単位（作成 / 閲覧 / 更新・削除）**で3分割する：
+
+```markdown
+### Phase 2: ユーザー管理コア（CRUD）
+
+- [ ] 2.1 ユーザー作成機能
+  - 2.1.1 ユーザー作成機能の実装（TDD）
+    - Domain〜UIまでフルスタック実装
+    - **要件**: Story 1
+    - **完了条件**: ユーザー作成ができること（AC1.1〜AC1.5を満たす）
+
+- [ ] 2.2 ユーザー閲覧機能（一覧・詳細）
+  - 2.2.1 ユーザー閲覧機能の実装（TDD）
+    - Domain〜UIまでフルスタック実装
+    - **要件**: Story 2, 3
+    - **完了条件**: 一覧・詳細が表示できること（AC2.1〜AC3.3を満たす）
+
+- [ ] 2.3 ユーザー更新・削除機能
+  - 2.3.1 ユーザー更新・削除機能の実装（TDD）
+    - Domain〜UIまでフルスタック実装
+    - **要件**: Story 4, 5
+    - **完了条件**: 編集・削除ができること（AC4.1〜AC5.3を満たす）
+```
+
+**ポイント**:
+- 各タスクグループ完了時にACが検証可能
+- 1機能でDomain→Infra→UseCase→API→UIをフルスタック実装
+- レイヤーごとの分割は禁止
+
 ### ❌ アンチパターン（絶対にやってはいけない分割）
 
 **パターン1: 画面ごとの分割**
@@ -197,6 +228,97 @@ ATDDの本質は「受け入れ基準（AC）を中心にタスクを分解す
 - 2.3 HashedPassword VOの実装
 ```
 
+### 🔵 TDD（テスト駆動開発）方針
+
+**原則**: ロジック・コード実装があるタスクは**TDDをデフォルトで適用**する。
+
+| 対象 | TDD適用 |
+|------|---------|
+| Domain層（Entity, Validator, Repository Interface） | **適用** |
+| Infrastructure層（Mapper, Repository実装） | **適用** |
+| Application層（UseCase） | **適用** |
+| Presentation層（API Routes） | **適用** |
+| UI層（Reactコンポーネント） | **適用** |
+| 設定ファイル、マイグレーション、シードデータ | 不適用 |
+
+**注意**: requirements.mdへの「TDD採用」明記は不要。デフォルトでTDD順序を適用する。
+
+### TDDタスク構造（1タスク内サブタスク）
+
+TDDは**3タスク分割（X.Y.1 テスト / X.Y.2 実装 / X.Y.3 リファクタ）ではなく、1タスク内のサブタスクとしてRed→Green→Refactorを記載**する：
+
+```markdown
+- [ ] X.Y 機能名
+
+  - X.Y.Z 機能名の実装（TDD）
+    - **テスト作成（Red）**:
+      - [テスト内容の詳細]
+      - Given-When-Then形式でテストケースを作成
+      - テストが失敗することを確認
+    - **実装（Green）**:
+      - [実装内容の詳細]
+      - テストを通すための最小限の実装
+      - 全テストがパスすることを確認
+    - **リファクタリング**:
+      - [改善内容の詳細]
+      - コード品質の改善（重複削除、命名改善）
+      - テストがパスし続けることを確認
+    - **要件**: Story X
+    - **依存関係**: ...
+    - **完了条件**: [条件]（ACX.Xを満たす）
+    - **対応設計**: design.md「[セクション名]」
+    - **シナリオテスト**: [該当シナリオ]
+```
+
+**TDDタスク構造の適用例**:
+
+```markdown
+- [ ] 2.1 ユーザー作成機能
+
+  - 2.1.1 ユーザー作成機能の実装（TDD）
+    - **テスト作成（Red）**:
+      - 重複メール検証、必須項目検証、権限検証のテスト
+      - Domain層（Entity, Validator）のユニットテスト
+      - Repository、UseCaseの統合テスト
+    - **実装（Green）**:
+      - User Entity、IUserRepository Interface
+      - UserMapper、UserRepository実装
+      - UserUseCases.create
+      - POST /api/rpc/users エンドポイント
+      - UserCreateForm（React Hook Form + Zod）
+    - **リファクタリング**:
+      - コード品質改善、重複削除
+    - **要件**: Story 1
+    - **依存関係**: 1.1
+    - **完了条件**: ユーザー作成ができ、全テストがパス（AC1.1〜AC1.5を満たす）
+    - **対応設計**: design.md「4〜9」全セクション
+    - **シナリオテスト**: シナリオ1 Step 1-3（部分実行：作成まで）
+```
+
+### TDD非適用タスクの例
+
+設定系タスク（マイグレーション、シードデータ等）はTDD不適用：
+
+```markdown
+- [ ] 1.1 サンプルコード削除とDB基盤構築
+
+  - 1.1.1 既存サンプルコードの削除
+    - 既存のUser, Account等のサンプルコード削除
+    - **要件**: Story 1前提条件
+    - **依存関係**: なし
+    - **完了条件**: サンプルコードが削除され、ビルド可能な状態
+    - **対応設計**: design.md「2.3 ディレクトリ構造」
+    - **シナリオテスト**: なし（基盤構築タスク）
+
+  - 1.1.2 Prismaスキーマ作成とマイグレーション
+    - User, Departmentモデル作成、マイグレーション実行
+    - **要件**: Story 1, 2
+    - **依存関係**: 1.1.1
+    - **完了条件**: マイグレーション成功、テーブル作成
+    - **対応設計**: design.md「3. データベース設計」
+    - **シナリオテスト**: なし（DB基盤タスク）
+```
+
 ### メタデータの記述（タスク単位に付与）
 
 各タスク（X.Y.Z）には以下のメタデータを**必須**で付与します：
@@ -253,8 +375,9 @@ ATDDの本質は「受け入れ基準（AC）を中心にタスクを分解す
 > **詳細なフロー（仕様書作成からレビュー・マージまで）は[開発ワークフロー](development-workflow.md)を参照してください。**
 
 ### 1. タスクグループを選定・実行
-- `/task-exec #{issue_number} {タスクグループ番号}`コマンドを実行
+- `/einja:task-exec #{issue_number} {タスクグループ番号}`コマンドを実行
 - タスクグループ番号は必須引数（例: `1.1`, `2.3`）
+- **注意**: `pnpm task:loop <issue番号>`が何らかの理由で使えない場合のオプションの単発実行として`/einja:task-exec`を使用
 - executer → reviewer → qa の3段階で実行
 
 ### 2. タスクを順次実装し、コミット
@@ -338,18 +461,19 @@ design.md「Server Core構築」セクション
 
 **仕様書作成とIssue生成**:
 ```bash
-/spec-create [タスク内容の説明]
+/einja:spec-create [タスク内容の説明]
 ```
 - requirements.md、design.mdを作成し、GitHub Issueを自動生成
 
 **タスクグループ実行**:
 ```bash
-/task-exec #{issue_number} {タスクグループ番号}
+/einja:task-exec #{issue_number} {タスクグループ番号}
 ```
 - Issue番号とタスクグループ番号は両方必須
 - executer → reviewer → qa の3段階で実行
 - QA合格後は追加指示待ち状態に入る
 - GitHub Issue更新はユーザーの明示的指示時のみ
+- **位置づけ**: `pnpm task:loop <issue番号>`が使えない場合の代替となる単発実行コマンド
 
 **自動ループ実行**:
 ```bash
@@ -363,7 +487,7 @@ pnpm task:loop <issue番号> --branch <ブランチ> # ベースブランチ指
 
 **仕様書からドキュメント更新**:
 ```bash
-/update-docs-by-task-specs [タスク仕様書ディレクトリパス]
+/einja:update-docs-by-task-specs [タスク仕様書ディレクトリパス]
 ```
 - タスク仕様書の内容をfeature仕様書とsteering仕様書に反映
 <!-- @einja:managed:end -->

package/presets/default/.claude/agents/einja/task/task-committer.md

@@ -1,88 +0,0 @@
----
-name: task-committer
-description: QA合格後の変更をコミット・プッシュする専用エージェント
-model: sonnet
-color: green
-skills:
-  - task-commit
----
-
-# task-committer エージェント
-
-QA合格後の変更をコミット・プッシュします。
-
-## 役割
-
-- 変更内容を確認し、適切な粒度でコミットを分割
-- `docs/einja/steering/commit-rules.md` のコミットルールに厳格に従う
-- コミット・プッシュを実行し、結果を報告
-
-## 処理
-
-task-commit Skillを実行し、結果を返却します。
-
-### コミット分割案の確認
-
-呼び出し時の指示に**明示的なコミット分割の指定がない場合**は、**AskUserQuestionツールを使用**してコミット分割案の承認を得ます。
-
-- ✅ 「この分割でお願い」「1コミットで」等の指定がある → 指定に従って実行
-- ✅ 分割指定がない → AskUserQuestionで確認を取る
-
-### task-exec経由での呼び出し
-
-task-exec経由で呼び出される場合、以下のみスキップします:
-
-- **品質チェック（prepush）**: QAフェーズで既に lint/typecheck/test が実行済みのため、重複実行は不要
-
-**注意**: コミット分割案の確認はスキップしません。
-
-## 出力形式
-
-task-commit Skillの出力形式に従い、以下の形式で結果を報告します:
-
-```markdown
-## 🚀 コミット・プッシュ完了
-
-### コミットサマリー
-- **コミット数**: {count}個
-- **変更ファイル数**: {files}個
-
-### コミット一覧
-| # | メッセージ | ファイル数 |
-|---|----------|----------|
-| 1 | feat: ... | 3 |
-| 2 | test: ... | 2 |
-
-### ステータス: ✅ SUCCESS / ❌ FAILURE
-```
-
-## 実行制約
-
-このエージェントは `task-exec` コマンドから `Task` ツール経由でのみ呼び出されます。
-
-## コンフリクト発生時
-
-**⚠️ 重要**: コンフリクト解消は「自動モード」の対象外です。必ずユーザー確認が必要です。
-
-`git pull --rebase` でコンフリクトが発生した場合:
-
-1. **自分でコンフリクトを解消してはいけない**
-2. **必ず `conflict-resolver` エージェントを Task ツールで呼び出す**
-3. conflict-resolverが各ファイルについてユーザーに確認を取り、解消を行う
-
-```
-Task ツール呼び出し:
-- subagent_type: conflict-resolver
-- prompt: "rebase中のコンフリクトを解消してください。各ファイルについてユーザーに確認を取りながら進めてください。"
-```
-
-**禁止事項**:
-- ❌ コンフリクトを自動解消すること
-- ❌ `--ours`や`--theirs`を無断で使用すること
-- ❌ ユーザー確認なしでマージ案を適用すること
-
-## 連携エージェント
-
-- **前提**: `task-qa` - 品質保証フェーズ完了後に呼び出される
-- **コンフリクト時**: `conflict-resolver` - rebase/merge時のコンフリクト解消
-- **後続**: なし（追加指示待ち状態へ移行）