@einja/dev-cli 0.1.39 → 0.1.41

package/presets/default/.envrc

@@ -23,6 +23,11 @@ MAIN_WORKTREE=$(get_main_worktree)
 if [ -n "$MAIN_WORKTREE" ] && [ -f "$MAIN_WORKTREE/.env.personal" ]; then
   dotenv_if_exists "$MAIN_WORKTREE/.env.personal"
 fi
+
+# Serena MCP サーバー自動起動
+if [ -n "$MAIN_WORKTREE" ] && [ -f "$MAIN_WORKTREE/scripts/ensure-serena.sh" ]; then
+  source "$MAIN_WORKTREE/scripts/ensure-serena.sh" "$MAIN_WORKTREE"
+fi
 # @einja:managed:end
 
 # @einja:seed:start id="project-env"

package/presets/default/.mcp.json

@@ -32,18 +32,8 @@
 			]
 		},
 		"serena": {
-			"type": "stdio",
-			"command": "uvx",
-			"args": [
-				"--from",
-				"git+https://github.com/oraios/serena",
-				"serena",
-				"start-mcp-server",
-				"--context",
-				"claude-code",
-				"--open-web-dashboard",
-				"false"
-			]
+			"type": "http",
+			"url": "http://127.0.0.1:${SERENA_PORT:-9850}/mcp"
 		},
 		"github": {
 			"type": "http",

package/presets/default/CLAUDE.md.template

@@ -11,6 +11,15 @@
 4. **直接実装の禁止**: あなたは絶対に直接実装を行わない。すべての作業はsubagentに委託し、可能な限り並行で呼び出す。サブエージェントの出力はユーザにも見える場所に出力すること
 5. **実装品質の自己検証**: 複雑な変更では完了前に「よりエレガントな方法はないか」を自問する。ただし単純な修正には不要
 
+## Agent Teams の使用制限
+
+**Agent Teams（`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`）はユーザーが明示的にチーム編成を指示した場合のみ使用すること。**
+
+- 通常のタスクではサブエージェント（`Task`ツール）を使用する
+- 「チームで」「複数agentで並列に」等の明示的な指示があった場合のみAgent Teamsを起動する
+- チーム実行時は `einja-team-exec` Skillの手順に従う
+- 判断に迷う場合はサブエージェントを使用する（デフォルト動作）
+
 ## サブエージェント委託ルール
 
 #### カスタムサブエージェント（直接委託）
@@ -31,7 +40,9 @@
 | `einja-task-commit` | コミット・プッシュ |
 | `einja-conflict-resolver` | gitコンフリクト解消 |
 | `einja-skill-creator` | Skill作成・更新 |
+| `einja-skill-first` | 作業前のSkill作成必要性評価（Plan/spec-create時に自動起動） |
 | `einja-infra-maintenance` | インフラ環境セットアップ・メンテナンス |
+| `einja:issue-exec` | Issue全体の階層的並列実行（Manager→Director→Worker） |
 | `einja:task-exec` | タスクグループ実行 |
 | `einja:spec-create` | 仕様書作成 |
 
@@ -41,9 +52,16 @@
 
 ### 必須フロー
 1. 問題・要件を調査・分析する
-2. 修正計画を `docs/plans/` に作成し提示する
-3. **ユーザーの明示的な承認を得る**
-4. 承認後、`docs/plans/todo-{plan名}.md` で進捗管理しながら実装を開始する
+2. 修正計画を `docs/plans/` に作成する
+3. `einja-skill-first` で「Skill を先に作るべきか」を評価する
+   - Plan mode中は `UserPromptSubmit` hookにより自動でリマインダーが注入される
+   - `.claude/skills/einja-skill-first/SKILL.md` を読み込んで評価を実施する
+   - 推奨判定 → AskUserQuestion でユーザーに提案
+   - 承認 → 計画の TODO-0 に Skill 作成を追加
+   - 不要判定 → そのまま次へ進む
+   - ※ スキップ基準に該当する場合は評価自体を省略
+4. 計画をユーザーに提示し、**明示的な承認を得る**
+5. 承認後、`docs/plans/todo-{plan名}.md` で進捗管理しながら実装を開始する（TODO-0 があれば Skill 作成から）
 
 ### 例外（承認不要）
 - 読み取り専用操作（質問への回答、情報調査、コード調査）
@@ -109,7 +127,7 @@
 
 Turborepoモノレポ構成（pnpm workspaces）。詳細が必要な場合は以下のSkillを参照:
 - `einja-project-overview` - 構成、技術スタック、頻出コマンド
-- `einja-coding-standards` - コーディング規約、インポートパス規約
+- `docs/einja/steering/development/coding-standards.md` - コーディング規約、インポートパス規約
 - `einja-infra-maintenance` - 開発環境セットアップ、サーバー管理
 
 ## マネージドディレクトリ（編集禁止）
@@ -189,4 +207,8 @@ Turborepoモノレポ構成（pnpm workspaces）。詳細が必要な場合は
 - サブエージェントの「完了」報告のみで完了判定しない
 - 検証をスキップして完了宣言しない
 
+<!-- @einja:project-private:start id="claude-md-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->
+
 

package/presets/default/docs/einja/example/specs/issues/issue999-example-task/tasks.md

@@ -159,7 +159,7 @@
 
 ### タスク階層（4階層）
 - **Phase（フェーズ）**: 最上位単位（1, 2, 3...）
-- **タスクグループ**: Vibe-KanbanタスクとPRの作成単位（1.1, 1.2...）、**チェックボックス付き**（`- [ ]`）、1-4時間
+- **タスクグループ**: PRの作成単位（1.1, 1.2...）、**チェックボックス付き**（`- [ ]`）、1-4時間
 - **タスク**: 作業単位・コミット単位（1.1.1, 1.1.2...）、**チェックボックスなし**、15-60分
 - **サブタスク**: タスク内の詳細作業項目、**箇条書き**（`-`）
 

package/presets/default/docs/einja/instructions/deployment-setup.md

@@ -599,11 +599,6 @@ gh secret set TURBO_TOKEN --body "new-token"
 - [GitHub Actions - Encrypted secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
 <!-- @einja:managed:end -->
 
----
-
-<!-- @einja:seed:start id="deployment-setup-project" -->
-## プロジェクト固有の設定
-
-<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="deployment-setup-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/docs/einja/instructions/environment-setup.md

@@ -639,11 +639,6 @@ dotenvx run -f .env -f .env.local -- <command>
 - **共有禁止**: 他の開発者とトークンを共有しないこと
 <!-- @einja:managed:end -->
 
----
-
-<!-- @einja:seed:start id="environment-setup-project" -->
-## プロジェクト固有の設定
-
-<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="environment-setup-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/docs/einja/instructions/issue-exec-workflow.md

@@ -0,0 +1,276 @@
+<!-- @einja:managed:start -->
+# `einja:issue-exec` コマンド
+
+## 概要
+
+GitHub Issue のタスクを Manager → Director → Worker の3階層プロセスで並列実行する Claude Code カスタムコマンド。tmux セッション、git worktree、ステータスファイルで全プロセスを管理する。
+
+**⚠️ 重要**: Vibe-Kanban（`pnpm task:loop`）は廃止され、`/einja:issue-exec` に移行しました。
+
+---
+
+## 使用方法
+
+### コマンド実行
+
+```bash
+# 基本
+/einja:issue-exec #123
+
+# オプション指定
+/einja:issue-exec #123 --merge-mode task-group-auto   # タスクPR自動マージ
+/einja:issue-exec #123 --merge-mode auto               # 全自動
+/einja:issue-exec #123 --max-phase 2                   # Phase 2 まで
+/einja:issue-exec #123 --base develop                  # ベースブランチ指定
+/einja:issue-exec #123 --resume                        # セッション復旧
+```
+
+### 事前準備
+
+- tmux がインストールされていること
+- GitHub CLI（`gh`）がインストール・認証済みであること
+- Docker が起動していること（必要な場合）
+
+---
+
+## アーキテクチャ
+
+### 3階層プロセス
+
+```
+Manager (Claude Code: /einja:issue-exec)
+│  メインリポ or Issue worktree
+│
+├─ tmux window → Director Phase1 (claude 対話モード)
+│  │  Phase worktree: ~/.einja/worktrees/issue-123/phase1/
+│  │
+│  ├─ tmux window → Worker 1.1 (claude 対話モード)
+│  │   Task worktree: ~/.einja/worktrees/issue-123/task-1.1/
+│  │   → /einja:task-exec #123 1.1
+│  │     ├─ サブエージェント: Task 1.1.1 実装（run_in_background）
+│  │     ├─ サブエージェント: Task 1.1.2 実装（run_in_background）
+│  │     └─ reviewer → QA → commit
+│  │
+│  ├─ tmux window → Worker 1.2 (claude 対話モード)
+│  │   → /einja:task-exec #123 1.2
+│  │
+│  └─ (依存タスクグループは先行完了後に起動)
+│
+├─ tmux window → Director Phase2 (Phase1完了後 or 並列)
+│  └─ ...
+│
+└─ 全Phase完了 → PR: issue/123 → main
+```
+
+### 各階層の責務
+
+| 階層 | 責務 | 実行方式 |
+|------|------|---------|
+| **Manager** | Issue パース、ブランチ管理、worktree 管理、tmux 管理、Director 起動、Phase マージ、質問エスカレーション、エラー監視 | Claude Code カスタムコマンド |
+| **Director** | Phase 内のタスクグループ管理、Worker 起動、並列制御、PR マージ検知、変更伝播、質問対応、worktree クリーンアップ | claude 対話モード（tmux window） |
+| **Worker** | task-exec 実行（executer→reviewer→qa→commit）、Phase 変更取り込み、PR 作成、完了報告 | claude 対話モード（tmux window） |
+
+### 各階層の通信方式
+
+| 階層間 | 方式 | 理由 |
+|--------|------|------|
+| Manager → Director | tmux + ステータスファイル + 質問エスカレーション | 別 worktree が必要 |
+| Director → Worker | tmux + ステータスファイル + 質問エスカレーション | 別 worktree が必要 |
+| Worker 内部（タスク間） | サブエージェント（Task ツール） | 既存 task-exec フローを活用 |
+
+---
+
+## ブランチ & worktree 構成
+
+### ブランチ階層
+
+```
+main (デフォルト)
+ └── issue/123                        Manager管理
+      ├── issue/123-phase1             Director1 worktree
+      │    ├── task/123-1.1            Worker1.1 worktree
+      │    ├── task/123-1.2            Worker1.2 worktree
+      │    └── task/123-1.3            Worker1.3 worktree（1.1完了後に作成）
+      └── issue/123-phase2             Director2 worktree
+           └── task/123-2.1            Worker2.1 worktree
+```
+
+### worktree 物理パス
+
+```
+~/.einja/worktrees/issue-123/
+├── phase1/                     ← Director1 cwd
+├── task-1.1/                   ← Worker1.1 cwd
+├── task-1.2/                   ← Worker1.2 cwd
+└── phase2/                     ← Director2 cwd
+```
+
+---
+
+## マージモード
+
+| モード | タスクPR (task→phase) | Phase PR (phase→issue) | 最終PR (issue→base) |
+|---|---|---|---|
+| `manual` | 人間マージ待ち | 人間マージ待ち | 人間マージ待ち |
+| `task-group-auto` | CI通過後に自動マージ | 人間マージ待ち | 人間マージ待ち |
+| `auto` | CI通過後に自動マージ | CI通過後に自動マージ | 人間マージ待ち（常に手動） |
+
+---
+
+## tmux セッション構成
+
+```
+tmux session: einja-123
+  window 0: Manager (メインプロセスのログ表示)
+  window 1: Director-Phase1 (claude 対話モード)
+  window 2: Worker-1.1 (claude 対話モード → /einja:task-exec #123 1.1)
+  window 3: Worker-1.2 (claude 対話モード → /einja:task-exec #123 1.2)
+  window 4: Director-Phase2 (claude 対話モード)
+  window 5: Worker-2.1 (claude 対話モード → /einja:task-exec #123 2.1)
+```
+
+ユーザーは `tmux attach -t einja-123` で全プロセスを監視可能。
+
+---
+
+## ステータスファイル
+
+パス: `~/.einja/sessions/issue-123/`
+
+```
+session.json                    # セッション全体（Manager PID、開始時刻、マージモード等）
+phase-1/
+  status.json                   # Phase状態 + Director PID
+  task-1.1.json                 # { status, prNumber, branch }
+  task-1.2.json
+phase-2/
+  status.json
+questions/
+  q-{uuid}.json                 # 質問ファイル（1ファイル1質問）
+events.jsonl                    # JSON Lines 形式の追記型イベントログ
+```
+
+### ステータスファイル永続化
+
+- `~/.einja/sessions/` に配置し、システム再起動後も `--resume` で復元可能
+- 完了時に Manager が自動クリーンアップ
+- `status.json` の更新は `flock` による排他制御を使用
+- git push 対象外（純粋にローカル実行状態管理）
+
+---
+
+## 質問エスカレーション
+
+### チェーン
+
+```
+Worker（task-exec 実行中に疑問発生）
+  ↓ ステータスファイル（質問キュー）
+Director（spec/design/issue で回答可能？）
+  ├─ Yes → 回答をステータスファイルに書き込み
+  └─ No ↓ ステータスファイル（質問キュー）
+Manager（Claude Code カスタムコマンド）
+  ↓ AskUserQuestion で人間に質問
+Human（回答入力）
+  ↓ 回答をステータスファイルに書き込み → 逆順で伝播
+```
+
+### 質問ファイル形式
+
+```json
+{
+  "id": "q-001",
+  "from": "worker-1.1",
+  "question": "ユーザー認証にJWTとセッションのどちらを使うべきか？",
+  "context": "design.md にはどちらの記載もない",
+  "status": "pending",
+  "escalatedTo": null,
+  "answer": null,
+  "answeredBy": null
+}
+```
+
+### 回答のドキュメント還元
+
+回答のうちドキュメント未記載のものは適切なドキュメントに追記:
+
+| 回答の種類 | 追記先 |
+|-----------|--------|
+| 要件・仕様に関する判断 | requirements.md |
+| 技術的な設計判断 | design.md |
+| プロジェクト横断の方針 | docs/einja/memory/decisions.md |
+| 再利用可能なパターン | docs/einja/memory/patterns.md |
+
+---
+
+## タスク完了フロー
+
+```
+Worker-1.1 作業中
+ │
+ ├─ 0. git rebase origin/issue/123-phase1（最新取り込み）
+ ├─ 1. task-exec 完了 → task/123-1.1 に commit & push
+ ├─ 2. CI 完了待機（gh run list ポーリング）
+ ├─ 3. gh pr create --base issue/123-phase1 --head task/123-1.1
+ ├─ 4. ステータスファイル: { status: "pr_created", pr: 456 }
+ └─ 5. claude プロセス終了
+
+Director 検知（ステータスファイル + プロセス監視）
+ │
+ ├─ manual モード: gh pr list --state merged ポーリング → マージ検知まで待機
+ ├─ task-group-auto: gh pr merge --squash --auto 実行
+ ├─ auto: CI通過確認後に gh pr merge --squash 実行
+ │
+ ├─ マージ検知後:
+ │   ├─ 他 active Worker にステータスで sync_required 通知
+ │   ├─ タスク worktree 削除 + tmux window kill
+ │   ├─ GitHub Issue チェックボックス更新
+ │   └─ 依存タスク起動判定 → 新 Worker 起動
+ │
+ └─ Phase 全タスク完了 → ステータスで Manager に報告
+
+Manager 検知
+ │
+ ├─ Phase PR 作成: issue/123-phase1 → issue/123
+ ├─ マージモードに応じた処理
+ ├─ マージ後: Phase worktree 削除
+ ├─ 他 active Phase に変更伝播
+ └─ 次 Phase 起動 or 全完了 → 最終 PR 作成
+```
+
+---
+
+## エラーリカバリ
+
+| 障害 | 検知 | リカバリ |
+|---|---|---|
+| Worker 異常終了（PR作成前） | tmux window 消失 + ステータス未更新 | リトライ（最大2回）→ 失敗時は Manager に報告 → 人間判断 |
+| Worker 異常終了（PR作成済み） | tmux window 消失 + PR あり | スキップ（PR マージ待ちのまま継続） |
+| Director 異常終了 | tmux window 消失 + ステータス未更新 | 各 Worker のステータスを確認 → 未完了 Worker のみ再実行 |
+| Manager 異常終了 | ユーザー手動 | `--resume` でステータスファイルから復元 |
+| rebase コンフリクト | git rebase 失敗 | conflict-resolver で自力解消 |
+| CI 失敗 | gh run status | 修正 → 再push → 再CI待機 |
+| CI 待機タイムアウト | 30分超過 | Manager に通知 → 人間判断 |
+
+---
+
+## `/einja:task-exec` との使い分け
+
+| コマンド | 用途 | 対象 | 推奨シーン |
+|---------|------|------|----------|
+| **`/einja:issue-exec`** | Issue全体の並列実行 | 複数Phase・複数タスクグループ | 大規模機能実装 |
+| **`/einja:task-exec`** | 単一タスクグループの実行 | 1つのタスクグループ | 品質重視、複雑な実装 |
+
+---
+
+## 関連ドキュメント
+
+- [タスク実行ワークフロー](./task-execute.md)
+- [タスク管理ガイドライン](../steering/task-management.md)
+- [仕様書作成ワークフロー](./einja:spec-create.md)
+- [ブランチ運用戦略](../steering/branch-strategy.md)
+<!-- @einja:managed:end -->
+
+<!-- @einja:project-private:start id="issue-exec-workflow-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/docs/einja/instructions/local-server-environment-and-worktree.md

@@ -530,7 +530,7 @@ pnpm build
 環境構築が完了したら、以下のドキュメントも参照してください：
 
 - **[タスク実行ガイド](./task-execute.md)**: /task-execコマンドの使用方法
-- **[コーディング規約](../../../.claude/skills/einja-coding-standards/SKILL.md)**: コードスタイルと規約
+- **[コーディング規約](../steering/development/coding-standards.md)**: コードスタイルと規約
 - **[テストガイドライン](../einja/steering/development/testing-strategy.md)**: Vitestを使用したテスト戦略
 
 ## 質問・サポート
@@ -626,13 +626,75 @@ for cmd in gh vercel neonctl dotenvx; do
   command -v $cmd >/dev/null 2>&1 && echo "✅ $cmd: $(command -v $cmd)" || echo "❌ $cmd: 未インストール"
 done
 ```
-<!-- @einja:managed:end -->
 
----
+### 7. MCP Server (Serena)
+
+Serena MCPサーバーは **1プロジェクト1インスタンス** で共有され、worktree間でも再利用されます。
+
+#### 自動起動の仕組み
+
+```
+cd プロジェクト → direnv → ensure-serena.sh → Serena起動 → .mcp.json(http)で接続
+```
+
+1. `direnv` が `.envrc` を読み込む
+2. `.envrc` が `scripts/ensure-serena.sh` を `source` する
+3. スクリプトが `.serena-port` を確認し、必要に応じて起動
+4. `SERENA_PORT` 環境変数がエクスポートされる
+5. `.mcp.json` の `http://127.0.0.1:${SERENA_PORT:-9850}/mcp` で接続
+
+#### `.serena-port` ファイル仕様
+
+プロジェクトルートに自動生成される管理ファイル（`.gitignore` 対象）。
+
+- **形式**: `PORT PID`（スペース区切り、例: `9850 12345`）
+- **PIDベース所有権管理**: `kill -0 PID` でプロセス生存を確認
+  - PID生存 → 再利用（ポートをエクスポートして終了）
+  - PID死亡 → ファイル削除 → 新規起動
+
+> **なぜcurlではなくPIDか**: MCP streamable-http の `/mcp` はPOST専用。GETの `curl -sf` は405を返し「未起動」と誤判定するため、PIDチェックでプロトコル非依存の判定を行う。
+
+#### ポート自動解決
+
+- デフォルト: `9850`
+- ポート衝突時: `+1` で10回まで試行（9850〜9859）
+- 全ポート使用中: 警告メッセージを出力（direnvはブロックしない）
 
-<!-- @einja:seed:start id="local-server-environment-and-worktree-project" -->
-## プロジェクト固有の設定
+#### 手動操作
+
+```bash
+# 状態確認
+cat .serena-port  # PORT PID を表示
+
+# 停止
+./scripts/stop-serena.sh
+
+# 再起動
+./scripts/stop-serena.sh && direnv reload
+
+# 再起動（direnv経由）
+direnv reload
+```
+
+#### トラブルシューティング
+
+| 症状 | 原因 | 対処 |
+|------|------|------|
+| Serena接続エラー | プロセスが停止している | `direnv reload` で再起動 |
+| ポートが意図と違う | 別プロセスが使用中 | `lsof -i :9850` で確認、不要なら停止 |
+| ゾンビ `.serena-port` | プロセスが異常終了 | `rm .serena-port && direnv reload` |
+| uvx not found | uv未インストール | `curl -LsSf https://astral.sh/uv/install.sh \| sh` |
+
+#### `.env.personal` でのオーバーライド
+
+デフォルトポートを変更したい場合:
+
+```bash
+# .env.personal に追記
+SERENA_PORT=9851
+```
+<!-- @einja:managed:end -->
 
-<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="local-server-environment-and-worktree-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/docs/einja/instructions/neon-cli-reference.md

@@ -595,11 +595,6 @@ neonctl branches delete $BRANCH_ID --project-id $PROJECT_ID
 - [neonctl CLI公式ドキュメント](https://neon.tech/docs/reference/neon-cli)
 <!-- @einja:managed:end -->
 
----
-
-<!-- @einja:seed:start id="neon-cli-reference-project" -->
-## プロジェクト固有の設定
-
-<!-- このセクションはプロジェクト固有の内容を追記する場合はここに記載 -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="neon-cli-reference-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/docs/einja/instructions/task-execute.md

@@ -316,21 +316,21 @@ Step 4: GitHub Issueにタスク一覧を記述
 
 ---
 
-### 3. `pnpm task:loop` コマンド
+### 3. `/einja:issue-exec` コマンド
 
-**役割**: 複数タスクの自動連続実行とVibe-Kanbanによる進捗追跡
+**役割**: Issue全体のタスクをManager→Director→Workerの3階層で並列実行
 
 詳細については、専用ドキュメントを参照してください：
-**📖 [Vibe-Kanban自動実行ガイド](./task-vibe-kanban-loop.md)**
+**📖 [Issue実行ワークフローガイド](./issue-exec-workflow.md)**
 
 #### `/einja:task-exec`との使い分け
 
-| コマンド | 用途 | 品質保証 | 推奨シーン |
-|---------|------|---------|----------|
-| **`/einja:task-exec`** | 重要タスクの確実な完了 | ✅ 合格まで自動ループ | 複雑な実装、品質重視 |
-| **`pnpm task:loop`** | 大量タスクの自動消化 | ❌ 各タスクは別プロセス | 定型作業、並行開発 |
+| コマンド | 用途 | 対象 | 推奨シーン |
+|---------|------|------|----------|
+| **`/einja:issue-exec`** | Issue全体の並列実行 | 複数Phase・複数タスクグループ | 大規模機能実装 |
+| **`/einja:task-exec`** | 単一タスクグループの確実な完了 | 1つのタスクグループ | 複雑な実装、品質重視 |
 
-**詳細な使い分け基準**: [task-vibe-kanban-loop.md](./task-vibe-kanban-loop.md#task-execとの使い分け)
+**詳細な使い分け基準**: [issue-exec-workflow.md](./issue-exec-workflow.md#task-execとの使い分け)
 
 ---
 
@@ -452,7 +452,7 @@ stateDiagram-v2
     [*] --> 未着手: タスク作成
 
     未着手 --> 着手中_TaskExec: /einja:task-exec実行
-    未着手 --> Vibe登録: /task-vibe-kanban-loop実行
+    未着手 --> IssueExec開始: /einja:issue-exec実行
 
     着手中_TaskExec --> 実装中: 実装フェーズ
     実装中 --> レビュー中: 実装完了
@@ -461,16 +461,16 @@ stateDiagram-v2
     QA中 --> 実装中: テスト失敗<br/>（ループバック）
     QA中 --> 完了_TaskExec: 全テスト合格
 
-    Vibe登録 --> 実行待機: Vibe-Kanban登録完了
-    実行待機 --> 実行中_Vibe: エージェント開始
-    実行中_Vibe --> 完了_Vibe: 実行成功
-    実行中_Vibe --> 失敗: 実行失敗
+    IssueExec開始 --> Worker割当: Manager/Directorが管理
+    Worker割当 --> 実行中_IssueExec: Worker起動
+    実行中_IssueExec --> PR作成: task-exec完了
+    PR作成 --> 完了_IssueExec: PRマージ
 
-    失敗 --> 手動修正: 開発者が修正
-    手動修正 --> Vibe登録: 再実行
+    実行中_IssueExec --> 失敗: 実行失敗
+    失敗 --> Worker割当: リトライ（最大2回）
 
     完了_TaskExec --> [*]
-    完了_Vibe --> [*]
+    完了_IssueExec --> [*]
 
     note right of 未着手
         状態: [ ]
@@ -482,16 +482,16 @@ stateDiagram-v2
         状態: [🔄]
     end note
 
-    note right of 実行待機
-        1分間隔で再試行
-        最大30回まで
+    note right of Worker割当
+        tmux + worktree で
+        並列実行
     end note
 
     note right of 完了_TaskExec
         状態: [x]
     end note
 
-    note right of 完了_Vibe
+    note right of 完了_IssueExec
         状態: [x]
     end note
 ```
@@ -639,11 +639,6 @@ sequenceDiagram
 開発を始める際は、まず`/einja:spec-create`で仕様書を作成し、その後`/einja:task-exec`でタスクグループを順次実行していきます。
 <!-- @einja:managed:end -->
 
----
-
-<!-- @einja:seed:start id="task-execute-project" -->
-## プロジェクト固有の設定
-
-<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="task-execute-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/docs/einja/instructions/vercel-cli-reference.md

@@ -463,6 +463,7 @@ jobs:
 | `vercel deploy` | `--yes` | デプロイ確認をスキップ |
 | `vercel env add` | パイプ入力 | `echo "value" \| vercel env add NAME <environment>` （environment: production/preview/development 必須） |
 | `vercel env rm` | `--yes` | 削除確認をスキップ |
+| `vercel deploy` | `--env KEY=VALUE` | `vercel deploy --prebuilt --env KEY1=VAL1 --env KEY2=VAL2` （CI/CDでは`--env`で全encrypted変数を実行時注入） |
 
 ### トークン認証
 
@@ -495,10 +496,21 @@ curl -s -H "Authorization: Bearer $VERCEL_TOKEN" \
 
 ## 環境変数同期自動化
 
+### CI/CDでの自動同期
+
+GitHub Actions (`deploy-stable-branches.yml`) が環境変数を自動管理します:
+
+| ブランチ | 方式 | 説明 |
+|---------|------|------|
+| main | `vercel env add` + `vercel deploy --env` | Vercel環境変数ストアに同期 + 実行時注入 |
+| develop/staging | `vercel deploy --env` のみ | 実行時注入のみ（`vercel env add`は使用しない） |
+| PR Preview | `vercel deploy --env` のみ | 実行時注入のみ（並行PR競合防止） |
+
+**設計意図**: `vercel env add`によるVercel環境変数ストアへの書き込みはmainブランチのみ。develop/staging/PRは`vercel deploy --env`で環境変数を実行時注入し、並行デプロイ間の競合を防止する。
+
 ### 初回セットアップ時の手動同期
 
-**注意**: 通常はGitHub Actions (`deploy-stable-branches.yml`) が環境変数を自動同期します。
-以下の手順は**初回セットアップ時のみ**手動で実行してください。
+**注意**: 以下の手順は**初回セットアップ時のみ**手動で実行してください。
 
 ### .env.* からVercelへの環境変数同期
 
@@ -521,11 +533,6 @@ Neon CLIの詳細は [Neon CLI リファレンス](./neon-cli-reference.md) を
 
 <!-- @einja:managed:end -->
 
----
-
-<!-- @einja:seed:start id="vercel-cli-reference-project" -->
-## プロジェクト固有の設定
-
-<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="vercel-cli-reference-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->