@einja/dev-cli 0.1.40 → 0.1.44

package/presets/default/docs/einja/steering/infrastructure/deployment.md

@@ -134,6 +134,7 @@ graph LR
         ReleaseCLI[release-cli.yml]
         ReleaseApp[release-create-einja-app.yml]
         Claude[claude.yml]
+        ChangesetStatus[changeset-status.yml]
     end
 
     subgraph "Composite Actions"
@@ -155,13 +156,14 @@ graph LR
 
 | ワークフロー | ファイル | トリガー | 用途 |
 |------------|---------|---------|------|
-| **Deploy Stable** | `deploy-stable-branches.yml` | push to main/develop/staging | CI → 本番・開発・ステージング環境デプロイ |
+| **Deploy Stable** | `deploy-stable-branches.yml` | push to main/develop/staging | CI → 動的マトリクス → 変更アプリのみデプロイ（`--env`実行時注入） |
 | **PR Preview** | `deploy-pr-preview.yml` | PR opened/sync/closed | CI → Neonブランチ作成 → プレビューデプロイ |
 | **PR Close Cleanup** | `cleanup-pr-preview-on-close.yml` | PR closed | Neonブランチの即座削除（PR close時） |
 | **Cleanup DB** | `cleanup-pr-preview-db.yml` | 毎日00:00 UTC / 手動 | 孤立したNeonブランチ削除 |
 | **Release CLI** | `release-cli.yml` | tag `cli-v*` / 手動 | @einja/dev-cli をNPM公開 |
 | **Release App** | `release-create-einja-app.yml` | tag `create-einja-app-v*` / 手動 | create-einja-app をNPM公開 |
 | **Claude** | `claude.yml` | @claude メンション | Claude Code実行 |
+| **Changeset Status** | `changeset-status.yml` | PR to main/staging | PR上にchangesetの有無を表示 |
 
 ### Composite Actions（2層構造）
 
@@ -185,8 +187,7 @@ flowchart TB
     end
 
     subgraph "migrate/action.yml"
-        M1[setup action 呼び出し] --> M2[pnpm generate]
-        M2 --> M3[db:migrate:deploy]
+        M1[setup action 呼び出し] --> M3[db:migrate:deploy]
         M3 --> M4{run-seed?}
         M4 -->|true| M5[db:seed]
         M4 -->|false| M6[完了]
@@ -201,7 +202,7 @@ flowchart TB
 |--------|---------|------|-----------|
 | **Setup** | `actions/setup/action.yml` | pnpm + Node.js + install | ci action, migrate action, cleanup |
 | **CI** | `actions/ci/action.yml` | setup → generate → [migrate] → typecheck → lint → test | deploy-stable-branches, deploy-pr-preview |
-| **Migrate** | `actions/migrate/action.yml` | setup → generate → migrate → seed (optional) | deploy-stable-branches |
+| **Migrate** | `actions/migrate/action.yml` | setup → migrate → seed (optional) | deploy-stable-branches |
 | **Neon Export Env** | `actions/neon-export-env/action.yml` | .env.previewからNeon環境変数をエクスポート | deploy-pr-preview, cleanup-pr-preview-on-close |
 
 ### 実行マトリクス
@@ -258,9 +259,8 @@ sequenceDiagram
     rect rgb(240, 255, 240)
         Note over Actions,Vercel: Vercel デプロイ
         Actions->>Vercel: vercel pull
-        Actions->>Vercel: 環境変数同期 (encrypted-only)
         Actions->>Vercel: vercel build (DATABASE_URL=pooled)
-        Actions->>Vercel: vercel deploy --prebuilt
+        Actions->>Vercel: vercel deploy --prebuilt --env（全encrypted変数を実行時注入）
         Vercel-->>Actions: Preview URL
     end
 
@@ -308,10 +308,12 @@ sequenceDiagram
     rect rgb(240, 255, 240)
         Note over Actions,Vercel: Vercel デプロイ
         Actions->>Vercel: vercel pull
-        Actions->>Vercel: 環境変数同期 (encrypted-only)
-        Actions->>Vercel: vercel pull (Re-pull: 同期後の最新化)
+        alt mainブランチのみ
+            Actions->>Vercel: 環境変数同期 (encrypted-only, vercel env add)
+            Actions->>Vercel: vercel pull (Re-pull: 同期後の最新化)
+        end
         Actions->>Vercel: vercel build [--prod]
-        Actions->>Vercel: vercel deploy --prebuilt [--prod]
+        Actions->>Vercel: vercel deploy --prebuilt --env [--prod]（全encrypted変数を実行時注入）
         Vercel-->>Actions: Deploy URL
     end
 
@@ -383,15 +385,15 @@ sequenceDiagram
 ```mermaid
 flowchart TD
     A[git push main] --> B[deploy-stable-branches.yml]
-    B --> C[CI Checks]
-    C --> D{成功?}
+    B --> C[CI Checks + 変更検知]
+    C --> D{成功 & 変更あり?}
     D -->|Yes| E[dotenvx復号化]
-    D -->|No| X[失敗通知]
+    D -->|No| X[スキップ]
     E --> F[Vercel Pull]
-    F --> G[環境変数同期]
+    F --> G[環境変数同期 vercel env add]
     G --> H[DB Migrate]
     H --> I[Vercel Build]
-    I --> J[Vercel Deploy --prod]
+    I --> J[Vercel Deploy --prod --env]
     J --> K[完了]
 
     style A fill:#4CAF50
@@ -413,19 +415,18 @@ flowchart TD
 ```mermaid
 flowchart TD
     A[git push develop] --> B[deploy-stable-branches.yml]
-    B --> C[CI Checks]
-    C --> D{成功?}
+    B --> C[CI Checks + 変更検知]
+    C --> D{成功 & 変更あり?}
     D -->|Yes| E[dotenvx復号化]
-    D -->|No| X[失敗通知]
+    D -->|No| X[スキップ]
     E --> F[Vercel Pull]
-    F --> G[環境変数同期]
-    G --> H[Vercel Build]
-    H --> I[Vercel Deploy]
-    I --> J[Alias設定]
-    J --> K[完了]
+    F --> G[Vercel Build]
+    G --> H[Vercel Deploy --env]
+    H --> I[Alias設定]
+    I --> J[完了]
 
     style A fill:#2196F3
-    style K fill:#2196F3
+    style J fill:#2196F3
 ```
 
 **設定**:
@@ -434,7 +435,7 @@ flowchart TD
 - 復号鍵: `DOTENV_PRIVATE_KEY_DEVELOP`
 - DBマイグレーション: ❌（PR PreviewのNeonブランチで自動同期）
 - DBシード: ❌
-- Alias: `secrets.VERCEL_DEV_DOMAIN`
+- Alias: `.env.develop` 内の `VERCEL_ALIAS_DOMAIN_WEB` / `VERCEL_ALIAS_DOMAIN_ADMIN`（dotenvx復号で取得）
 
 ---
 
@@ -443,20 +444,19 @@ flowchart TD
 ```mermaid
 flowchart TD
     A[git push staging] --> B[deploy-stable-branches.yml]
-    B --> C[CI Checks]
-    C --> D{成功?}
+    B --> C[CI Checks + 変更検知]
+    C --> D{成功 & 変更あり?}
     D -->|Yes| E[dotenvx復号化]
-    D -->|No| X[失敗通知]
+    D -->|No| X[スキップ]
     E --> F[Vercel Pull]
-    F --> G[環境変数同期]
-    G --> H[DB Migrate]
-    H --> I[Vercel Build]
-    I --> J[Vercel Deploy]
-    J --> K[Alias設定]
-    K --> L[完了]
+    F --> G[DB Migrate]
+    G --> H[Vercel Build]
+    H --> I[Vercel Deploy --env]
+    I --> J[Alias設定]
+    J --> K[完了]
 
     style A fill:#FF9800
-    style L fill:#FF9800
+    style K fill:#FF9800
 ```
 
 **設定**:
@@ -465,7 +465,7 @@ flowchart TD
 - 復号鍵: `DOTENV_PRIVATE_KEY_STAGING`
 - DBマイグレーション: ✅
 - DBシード: ❌（既存データ保持）
-- Alias: `secrets.VERCEL_STG_DOMAIN`
+- Alias: `.env.staging` 内の `VERCEL_ALIAS_DOMAIN_WEB` / `VERCEL_ALIAS_DOMAIN_ADMIN`（dotenvx復号で取得）
 
 ---
 
@@ -506,12 +506,12 @@ flowchart TD
 
 > **⚠️ 同時PR運用時の注意**
 >
-> テンプレートでは`vercel deploy --env DATABASE_URL=...`でデプロイ単位で
-> DATABASE_URLを注入しています。これにより、同時に複数のPRがプレビュー
-> デプロイされても、それぞれのPRが固有のNeonブランチDBを参照します。
+> テンプレートでは`vercel deploy --env KEY=VALUE`でデプロイ単位で
+> 全encrypted環境変数（DATABASE_URL含む）を実行時注入しています。
+> これにより、同時に複数のPRがプレビューデプロイされても、
+> それぞれのPRが固有のNeonブランチDBを参照し、環境変数の競合が発生しません。
 >
-> もし`vercel env add DATABASE_URL`方式を使用すると、Vercel Projectの
-> preview環境変数が上書きされ、同時PRで競合するリスクがあります。
+> PR環境では`vercel env add`は使用しません（並行PR間の競合を防ぐため）。
 
 ---
 
@@ -520,20 +520,21 @@ flowchart TD
 | 環境 | ブランチ | Vercel環境 | DBマイグ | シード | Alias | 暗号化ファイル | 復号鍵 |
 |------|---------|-----------|:-------:|:-----:|:-----:|--------------|--------|
 | Production | main | production | ✅ | ❌ | ❌ | `.env.production` | `DOTENV_PRIVATE_KEY_PRODUCTION` |
-| Develop | develop | preview | ❌ | ❌ | ✅ | `.env.develop` | `DOTENV_PRIVATE_KEY_DEVELOP` |
-| Staging | staging | preview | ✅ | ❌ | ✅ | `.env.staging` | `DOTENV_PRIVATE_KEY_STAGING` |
+| Develop | develop | preview | ❌ | ❌ | ✅ `VERCEL_ALIAS_DOMAIN_*` | `.env.develop` | `DOTENV_PRIVATE_KEY_DEVELOP` |
+| Staging | staging | preview | ✅ | ❌ | ✅ `VERCEL_ALIAS_DOMAIN_*` | `.env.staging` | `DOTENV_PRIVATE_KEY_STAGING` |
 | PR Preview | feature/* | preview | ✅ | ✅ | ❌ | `.env.preview` | `DOTENV_PRIVATE_KEY_PREVIEW` |
 
 ### Vercel環境変数の自動同期
 
 ワークフローは **encrypted-only方式** で同期対象を制御:
 
-| ワークフロー | 同期対象 | 除外 | 説明 |
-|------------|---------|------|------|
-| PR Preview | `.env.preview` 内の `encrypted:` キー | `NEON_*`, `DATABASE_*` | dotenvxで管理しているもの = Vercelに同期すべきもの |
-| Stable Branches | `.env.{env}` 内の `encrypted:` キー | なし | dotenvxで管理している全キーを同期 |
+| ワークフロー | 方式 | 同期対象 | 除外 | 説明 |
+|------------|------|---------|------|------|
+| PR Preview | `--env`実行時注入 | `.env.preview` 内の `encrypted:` キー | `NEON_*`, `DOTENV_PUBLIC_KEY_*` | `vercel env add`は使用しない（並行PR競合防止） |
+| Stable (main) | `vercel env add` + `--env`実行時注入 | `.env.production` 内の `encrypted:` キー | `NEON_*` | mainのみVercel環境変数ストアに同期 |
+| Stable (develop/staging) | `--env`実行時注入 | `.env.{env}` 内の `encrypted:` キー | `NEON_*`, `VERCEL_ALIAS_DOMAIN_*`, `DOTENV_PUBLIC_KEY_*` | `vercel env add`は使用しない |
 
-**設計意図**: dotenvxの暗号化ファイル内の `encrypted:` を含む行のキー名のみを対象とし、「dotenvxで管理 = Vercelに同期」の意図を明確にする。ブラックリスト方式（全env走査）ではシステム変数混入や新変数追加時の漏れリスクがあるため廃止。
+**設計意図**: `vercel env add`によるVercel環境変数ストアへの書き込みはmainブランチのみに限定。develop/staging/PRは`vercel deploy --env`による実行時注入で環境変数を渡し、並行デプロイ間の競合を防止する。
 
 ---
 
@@ -680,6 +681,111 @@ sequenceDiagram
 
 ---
 
+## 8. リリース管理
+
+### GitHub Release / PreRelease 自動作成フロー
+
+```mermaid
+flowchart LR
+    subgraph staging
+        S1[staging push] --> S2[CI + Deploy]
+        S2 --> S3[PreRelease作成<br/>v0.2.0-rc.42]
+    end
+
+    subgraph main
+        M1[main push] --> M2[CI]
+        M2 --> M3[⚠️承認待ち]
+        M3 --> M4[Migrate + Deploy]
+        M4 --> M5[changeset version]
+        M5 --> M6[Release作成<br/>v0.2.0]
+    end
+
+    staging -->|昇格PR| main
+```
+
+| 環境 | リリース種別 | タグ形式 | changeset消費 | 承認 |
+|------|------------|---------|:------------:|:----:|
+| staging | PreRelease | `v{version}-rc.{run_number}` | ❌ | 不要 |
+| production | Release | `v{version}` | ✅ | 1名必要 |
+
+### ワークフロー内リリースジョブ
+
+`deploy-stable-branches.yml` 内に統合:
+
+| ジョブ | トリガー | 処理内容 |
+|--------|---------|---------|
+| `release-staging` | staging デプロイ成功後 | RCタグ作成 → GitHub PreRelease作成 |
+| `release-production` | production デプロイ成功後 | changeset version → バージョンバンプ → タグ作成 → GitHub Release作成 |
+
+### NPMリリースとの棲み分け
+
+| タグパターン | 用途 | 生成元 |
+|-------------|------|--------|
+| `v1.2.0` | アプリ Stable Release | deploy-stable-branches.yml |
+| `v1.2.0-rc.42` | アプリ PreRelease | deploy-stable-branches.yml |
+| `cli-v0.1.41` | @einja/dev-cli | 手動タグ（既存運用） |
+| `create-einja-app-v0.3.2` | create-einja-app | 手動タグ（既存運用） |
+
+---
+
+## 9. バージョニング戦略
+
+### changesets
+
+[changesets](https://github.com/changesets/changesets) を使用してセマンティックバージョニングを管理。
+
+| 変更種別 | changeset指定 | バージョン変更例 | 使用シーン |
+|---------|--------------|----------------|----------|
+| 破壊的変更 | `major` | `0.1.0` → `1.0.0` | API仕様変更、DB破壊的マイグレーション |
+| 新機能追加 | `minor` | `0.1.0` → `0.2.0` | 新画面、新API追加 |
+| バグ修正 | `patch` | `0.1.0` → `0.1.1` | 不具合修正、パフォーマンス改善 |
+
+### changeset消費タイミング
+
+| ブランチ | changeset消費 | バージョンバンプ | タグ形式 |
+|---------|-------------|----------------|---------|
+| staging | **消費しない** | なし（package.json据え置き） | `v{current}-rc.{run_number}` |
+| main | `changeset version` で消費 | package.json更新 | `v{new_version}` |
+
+### 無限ループ防止（多重防御）
+
+1. `GITHUB_TOKEN` で作成されたpushイベントはデフォルトでワークフローを再トリガーしない
+2. コミットメッセージ `chore: release v` でのフィルタリング
+3. バージョンバンプコミットは `github-actions[bot]` 名義
+
+---
+
+## 10. 承認フロー
+
+### GitHub Environments
+
+| Environment | Required Reviewers | Wait Timer | Deployment Branches |
+|------------|-------------------|------------|-------------------|
+| `staging` | なし | なし | `staging`のみ |
+| `production` | 1名 | なし | `main`のみ |
+
+### 承認フロー詳細
+
+```mermaid
+sequenceDiagram
+    participant Dev as 開発者
+    participant GH as GitHub Actions
+    participant Rev as Reviewer
+    participant Prod as Production
+
+    Dev->>GH: main push
+    GH->>GH: CI checks
+    GH->>Rev: ⚠️ 承認リクエスト
+    Note over Rev: GitHub UIで承認
+    Rev->>GH: ✅ 承認
+    GH->>Prod: Migrate + Deploy
+    GH->>GH: Release作成
+```
+
+production環境へのデプロイは `migrate-production` ジョブで承認ゲートを設定。承認後にマイグレーションとデプロイが実行される。
+
+---
+
 ## 関連ドキュメント
 
 - [環境変数設計方針](./environment-variables.md)
@@ -688,11 +794,6 @@ sequenceDiagram
 - [Vercel CLI/APIリファレンス](../../instructions/vercel-cli-reference.md)
 <!-- @einja:managed:end -->
 
----
-
-<!-- @einja:seed:start id="deployment-project" -->
-## プロジェクト固有の設定
-
-<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="deployment-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/docs/einja/steering/infrastructure/environment-variables.md

@@ -279,6 +279,7 @@ dotenvx採用により、GitHub Secretsは**環境ごとに1つの秘密鍵の
 
 | Secret名 | 用途 |
 |---------|------|
+| `DOTENV_PRIVATE_KEY_DEVELOP` | dev検証環境の復号 |
 | `DOTENV_PRIVATE_KEY_STAGING` | ステージング環境の復号 |
 | `DOTENV_PRIVATE_KEY_PREVIEW` | Preview環境の復号（Neon環境変数含む） |
 | `DOTENV_PRIVATE_KEY_PRODUCTION` | 本番デプロイ時の復号 |
@@ -302,11 +303,6 @@ dotenvx採用により、GitHub Secretsは**環境ごとに1つの秘密鍵の
 - [デプロイセットアップ手順](../../instructions/deployment-setup.md)
 <!-- @einja:managed:end -->
 
----
-
-<!-- @einja:seed:start id="environment-variables-project" -->
-## プロジェクト固有の設定
-
-<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="environment-variables-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/docs/einja/steering/product.md

@@ -541,11 +541,6 @@ describe('UserRepository', () => {
 すべての開発活動は、このビジョンと原則に従って実施してください。
 <!-- @einja:managed:end -->
 
----
-
-<!-- @einja:seed:start id="product-project" -->
-## プロジェクト固有の設定
-
-<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="product-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/docs/einja/steering/task-management.md

@@ -87,12 +87,12 @@ GitHub Issueのチェックボックスでタスクグループのステータ
 - [x] 1.1 タスクグループ名
 ```
 
-**注意**: タスクグループの完了時、GitHub Issueのチェックボックス更新はユーザーが明示的に指示した場合のみ行います。`/einja:task-exec`コマンドは自動でIssueを更新しません。
+**注意**: タスクグループの完了時、GitHub Issueのチェックボックス更新はユーザーが明示的に指示した場合のみ行います。`einja-task-exec` Skillは自動でIssueを更新しません。
 
 ### Issueのライフサイクル
 
-1. **Issue作成**: `/einja:spec-create`コマンドで仕様書作成時に自動生成
-2. **タスクグループ実行**: `/einja:task-exec #{issue_number} {タスクグループ番号}`でタスクグループを実行
+1. **Issue作成**: `einja-issue-spec-create` Skillで仕様書作成時に自動生成
+2. **タスクグループ実行**: `einja-task-exec` Skillで `#{issue_number} {タスクグループ番号}` を指定してタスクグループを実行
 3. **タスクグループ完了**: 実装・テスト・レビュー完了後、チェックボックスをON（手動更新）
 4. **Issue完了**: すべてのタスクグループが完了したらIssueをClose
 
@@ -356,7 +356,7 @@ TDDは**3タスク分割（X.Y.1 テスト / X.Y.2 実装 / X.Y.3 リファク
 
 ### 依存関係の記述形式（重要）
 
-**🔴 `pnpm task:loop`スクリプトが認識できる形式のみ使用すること**
+**🔴 `/einja:issue-exec` が認識できる形式のみ使用すること**
 
 | 記述形式 | 意味 | 例 |
 |---------|------|-----|
@@ -375,9 +375,9 @@ TDDは**3タスク分割（X.Y.1 テスト / X.Y.2 実装 / X.Y.3 リファク
 > **詳細なフロー（仕様書作成からレビュー・マージまで）は[開発ワークフロー](development-workflow.md)を参照してください。**
 
 ### 1. タスクグループを選定・実行
-- `/einja:task-exec #{issue_number} {タスクグループ番号}`コマンドを実行
+- `einja-task-exec` Skillで `#{issue_number} {タスクグループ番号}` を指定して実行
 - タスクグループ番号は必須引数（例: `1.1`, `2.3`）
-- **注意**: `pnpm task:loop <issue番号>`が何らかの理由で使えない場合のオプションの単発実行として`/einja:task-exec`を使用
+- **注意**: 単一タスクグループを品質重視で確実に完了させたい場合に使用。`/einja:issue-exec` の Worker 内部でも呼ばれる
 - executer → reviewer → qa の3段階で実行
 
 ### 2. タスクを順次実装し、コミット
@@ -396,128 +396,40 @@ TDDは**3タスク分割（X.Y.1 テスト / X.Y.2 実装 / X.Y.3 リファク
 - または、ユーザーが明示的に指示した場合のみ自動更新
 - すべてのタスクグループが完了したら、IssueをClose
 
-## Vibe-Kanbanタスク作成時の必須情報
-
-### タスクタイトル形式
-```
-[タスクグループ番号] タスクグループ名
-```
-
-**例**: `[1.1] Server Core構築とDB設定`
-
-### タスク説明形式
-
-```markdown
-## GitHub Issue
-#{issue_number}
-
-## タスクグループ番号
-<タスクグループ番号>
-
-## 概要
-<タスクグループの概要>
-
-## タスク
-<GitHub Issueから抽出したタスク一覧>
-
-## 依存関係
-<依存するタスクグループ番号>
-
-## 完了条件
-<受け入れ基準を含む完了条件>
-
-## 対応設計
-<design.mdの参照箇所>
-```
-
-**例**:
-```markdown
-## GitHub Issue
-#17
-
-## タスクグループ番号
-1.1
-
-## 概要
-packages/server-coreの初期化からDB接続設定まで、Server Coreの基盤構築を完了
-
-## タスク
-- 1.1.1 packages/server-core初期化とtsconfig設定
-- 1.1.2 DB接続設定とマイグレーション
-
-## 依存関係
-なし
-
-## 完了条件
-server-coreパッケージが動作し、DBに接続できること（AC1.1を満たす）
-
-## 対応設計
-design.md「Server Core構築」セクション
-```
-
-### 親Issue/サブIssue階層（task:loop使用時）
-
-`pnpm task:loop` 使用時は、Vibe-Kanban上でPhase→親Issue、タスクグループ→サブIssueの階層構造で管理されます。
-
-**親Issueタイトル形式**:
-```
-[Issue{N} Phase{M}] {Phase名}
-```
-例: `[Issue17 Phase1] 基盤構築`
-
-**サブIssueタイトル形式**:
-```
-[Issue{N} {X.Y}] {タスクグループ名}
-```
-例: `[Issue17 1.1] Server Core構築とDB設定`
-
-**親子関係の設定**: サブIssue作成後、REST API（PATCH `/api/remote/issues/{id}`）で `parent_issue_id` を設定します。
-
-**注意**: `/einja:task-exec` による単発実行時はこの階層構造は使用されません。`pnpm task:loop` 使用時のみ適用されます。
-
 ## コマンドリファレンス
 
 ### タスク管理関連コマンド
 
 **仕様書作成とIssue生成**:
-```bash
-/einja:spec-create [タスク内容の説明]
-```
+`einja-issue-spec-create` Skillを使用し、タスク内容の説明を引数に指定します。
 - requirements.md、design.mdを作成し、GitHub Issueを自動生成
 
 **タスクグループ実行**:
-```bash
-/einja:task-exec #{issue_number} {タスクグループ番号}
-```
+`einja-task-exec` Skillを使用し、`#{issue_number} {タスクグループ番号}` を引数に指定します。
 - Issue番号とタスクグループ番号は両方必須
 - executer → reviewer → qa の3段階で実行
 - QA合格後は追加指示待ち状態に入る
 - GitHub Issue更新はユーザーの明示的指示時のみ
-- **位置づけ**: `pnpm task:loop <issue番号>`が使えない場合の代替となる単発実行コマンド
+- **位置づけ**: 単一タスクグループを品質重視で実行するSkill。`/einja:issue-exec` の Worker 内部でも使用される
 
-**自動ループ実行**:
+**Issue全体の並列実行**:
 ```bash
-pnpm task:loop <issue番号>
-pnpm task:loop <issue番号> --max-group <番号>  # 指定番号まで実行
-pnpm task:loop <issue番号> --branch <ブランチ> # ベースブランチ指定
+/einja:issue-exec #<issue番号>
+/einja:issue-exec #<issue番号> --merge-mode auto      # 全自動モード
+/einja:issue-exec #<issue番号> --max-phase <番号>      # 指定Phaseまで実行
+/einja:issue-exec #<issue番号> --base <ブランチ>       # ベースブランチ指定
 ```
-- 着手可能なタスクグループを並列でVibe-Kanbanに登録
-- Done状態を監視して次のタスクを自動開始
-- Phase毎に親Issueを作成し、タスクグループをサブIssueとして管理（詳細は「親Issue/サブIssue階層」を参照）
-- **前提**: `npx @einja/cli init` 実行済み、Claude Code インストール済み
+- Manager → Director → Worker の3階層で並列実行
+- tmux セッションで全プロセスを監視可能
+- マージモードで自動化レベルを制御
 
 **仕様書からドキュメント更新**:
 ```bash
-/einja:update-docs-by-task-specs [タスク仕様書ディレクトリパス]
+/einja:update-docs-by-issue-specs [Issue仕様書ディレクトリパス]
 ```
-- タスク仕様書の内容をfeature仕様書とsteering仕様書に反映
+- Issue仕様書の内容をfeature仕様書とsteering仕様書に反映
 <!-- @einja:managed:end -->
 
----
-
-<!-- @einja:seed:start id="task-management-project" -->
-## プロジェクト固有の設定
-
-<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="task-management-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/scripts/ensure-serena.sh

@@ -0,0 +1,75 @@
+#!/bin/bash
+# Serena MCP サーバーの冪等起動
+# .envrc から source して使用
+
+# メインワークツリーをベースにする（worktree 間で共有）
+_SERENA_BASE="${1:-$(pwd)}"
+_SERENA_PORT_FILE="$_SERENA_BASE/.serena-port"
+_SERENA_DEFAULT_PORT="${SERENA_PORT:-9850}"
+
+# --- 既存インスタンスチェック（PIDベース） ---
+if [ -f "$_SERENA_PORT_FILE" ]; then
+  read -r _saved_port _saved_pid < "$_SERENA_PORT_FILE"
+  if [ -n "$_saved_pid" ] && kill -0 "$_saved_pid" 2>/dev/null; then
+    # PIDが生存 → 自プロジェクトのSerena
+    export SERENA_PORT="$_saved_port"
+    return 0 2>/dev/null || true
+  fi
+  # PID死亡 → クリーンアップ
+  rm -f "$_SERENA_PORT_FILE"
+fi
+
+# --- uvx 確認 ---
+if ! command -v uvx &> /dev/null; then
+  echo "[ensure-serena] Warning: uvx not found. Serena will not auto-start." >&2
+  echo "[ensure-serena] Install uv first: curl -LsSf https://astral.sh/uv/install.sh | sh" >&2
+  return 0 2>/dev/null || true
+fi
+
+# --- 空きポート検出 ---
+_port="$_SERENA_DEFAULT_PORT"
+_port_found=false
+for _i in $(seq 1 10); do
+  if ! nc -z 127.0.0.1 "$_port" > /dev/null 2>&1; then
+    _port_found=true
+    break
+  fi
+  _port=$((_port + 1))
+done
+
+if [ "$_port_found" = false ]; then
+  echo "[ensure-serena] Error: No available port found (tried $_SERENA_DEFAULT_PORT-$_port)" >&2
+  return 0 2>/dev/null || true
+fi
+
+# --- バックグラウンド起動 ---
+echo "[ensure-serena] Starting Serena on port $_port..."
+uvx --from git+https://github.com/oraios/serena \
+  serena start-mcp-server \
+  --transport streamable-http \
+  --host 127.0.0.1 \
+  --port "$_port" \
+  --context claude-code \
+  --project "$_SERENA_BASE" \
+  > /dev/null 2>&1 &
+_serena_pid=$!
+disown
+
+# --- 起動待機（PID生存 + ポートLISTEN、最大30秒） ---
+for _i in $(seq 1 60); do
+  if ! kill -0 "$_serena_pid" 2>/dev/null; then
+    echo "[ensure-serena] Warning: Serena process exited unexpectedly" >&2
+    return 0 2>/dev/null || true
+  fi
+  if nc -z 127.0.0.1 "$_port" > /dev/null 2>&1; then
+    echo "$_port $_serena_pid" > "$_SERENA_PORT_FILE"
+    export SERENA_PORT="$_port"
+    echo "[ensure-serena] Serena ready on port $_port (PID: $_serena_pid)"
+    return 0 2>/dev/null || true
+  fi
+  sleep 0.5
+done
+
+# タイムアウト（起動失敗してもdirenvはブロックしない）
+echo "[ensure-serena] Warning: Serena failed to start within 30s" >&2
+return 0 2>/dev/null || true