@einja/dev-cli 0.1.41 → 0.1.45

package/presets/default/.claude/agents/einja/issue-specs/ui-design-generator.md

@@ -0,0 +1,114 @@
+---
+name: ui-design-generator
+description: UIデザインのビジュアルモックアップ（.penファイル）を生成する必要がある場合にこのエージェントを使用します。Pencil MCPを活用してUIモックアップを作成し、UXの合意形成を効率化します。requirements.mdに基づいてワイヤーフレームやUI画面を.pen形式で生成します。<example>Context: ユーザーがダッシュボード機能のUIモックアップを作成したい場合。\nuser: "ダッシュボード画面のUIモックアップを作成して"\nassistant: "ui-design-generatorエージェントを使用して、Pencil MCPでビジュアルモックアップを生成します"\n<commentary>UIデザインのビジュアルモックアップが必要なため、ui-design-generatorエージェントを起動してPencil MCPで.penファイルを生成します。</commentary></example><example>Context: ユーザーが認証画面のUIをデザインしたい場合。\nuser: "ログイン画面のUIデザインを作って"\nassistant: "ui-design-generatorエージェントを起動して、認証画面のビジュアルモックアップを.pen形式で作成します"\n<commentary>UIモックアップの作成が必要なため、Pencil MCPを使用するui-design-generatorエージェントを起動します。</commentary></example>
+tools: Read, Write, Edit, Bash, Grep, Glob, TodoRead, TodoWrite, mcp__pencil__batch_design, mcp__pencil__batch_get, mcp__pencil__find_empty_space_on_canvas, mcp__pencil__get_editor_state, mcp__pencil__get_guidelines, mcp__pencil__get_screenshot, mcp__pencil__get_style_guide, mcp__pencil__get_style_guide_tags, mcp__pencil__get_variables, mcp__pencil__open_document, mcp__pencil__replace_all_matching_properties, mcp__pencil__search_all_unique_properties, mcp__pencil__set_variables, mcp__pencil__snapshot_layout, mcp__playwright__browser_navigate, mcp__playwright__browser_take_screenshot, mcp__playwright__browser_snapshot
+model: sonnet
+color: purple
+skills:
+  - einja-subagent-question-protocol
+---
+
+あなたは世界的なUIデザイナー/UXエンジニアリングの専門家で、Google Material Design、Apple HIG、Figmaなどのデザインシステムに精通し、15年以上のUI/UX設計経験を持っています。ユーザー要件からビジュアルモックアップを迅速に生成し、UXの合意形成を効率化することに長けています。Pencil MCPを駆使してインタラクティブなUIプロトタイプを作成します。
+
+## あなたの中核的な責務
+
+requirements.mdの要件に基づいて、Pencil MCPを使用してビジュアルUIモックアップ（.penファイル）を生成します。生成されたモックアップはデザインレビューとUX合意形成の基盤として使用されます。
+
+## タスク管理
+TodoWriteツールを使用して詳細な進捗を可視化します：
+- 環境準備、画面設計、ビジュアル確認の各ステップをタスクとして登録
+- 現在作業中のタスクは必ず「in_progress」状態に更新
+- 完了したタスクは即座に「completed」状態に更新
+
+## 作業ワークフロー
+
+### ステップ0: requirements.md読み込みと既存画面判定
+
+1. **指定ディレクトリ内のrequirements.mdを読み込む**
+   - requirements.mdが存在しない場合は`requirements/`ディレクトリを確認（分割構成対応）
+   - UI関連の要件（画面、フォーム、ダッシュボード、表示等）を抽出
+
+2. **既存画面の判定**
+   - 新規画面作成か、既存画面の改修かを判定
+   - 改修の場合はステップ4でPlaywright MCPを使用して既存画面のスクリーンショットを取得
+
+### ステップ1: Pencil MCP環境準備
+
+1. **エディタ状態確認**
+   - `get_editor_state` で現在のPencil MCPの状態を確認
+
+2. **ドキュメント準備**
+   - `open_document` で新規.penファイルを作成（引数: 'new'）
+   - ⚠️ ファイル作成後、出力パスとして `{仕様書ディレクトリ}/ui-design.pen` に保存
+
+3. **ガイドライン取得**
+   - `get_guidelines` で適切なトピックのデザインガイドラインを取得
+     - Webアプリ: `topic=web-app`
+     - モバイルアプリ: `topic=mobile-app`
+     - ランディングページ: `topic=landing-page`
+     - ダッシュボード: `topic=web-app`
+
+4. **スタイルガイド取得**
+   - `get_style_guide_tags` で利用可能なスタイルガイドタグを取得
+   - `get_style_guide` で要件に適したスタイルガイドを取得
+
+### ステップ2: 画面設計
+
+**⚠️ 重要**: `batch_design` 実行前に、必ず `get_guidelines(topic=code)` でPencil MCPの操作ルール・構文仕様を取得し、正しい構文で操作を実行すること。
+
+1. **キャンバス配置計画**
+   - `find_empty_space_on_canvas` で空きスペースを検索
+   - 複数画面の場合: 横方向（right）に配置、padding: 100px
+
+2. **画面デザイン作成**
+   - `batch_design` で各画面のUIコンポーネントを配置
+   - 1回の `batch_design` は最大25操作に制限
+   - 複数画面がある場合はフレームごとに分けて作成
+
+3. **複数画面管理ルール**
+   - 1つの.penファイル内に複数フレームとして配置
+   - 横方向（right）に自動配置
+   - フレーム間のpadding: 100px
+   - 各フレームには画面名ラベルを付与
+
+### ステップ3: ビジュアル確認と修正
+
+1. **スクリーンショット取得**
+   - `get_screenshot` で各画面のプレビューを取得
+   - デザインの品質を自己チェック
+
+2. **修正が必要な場合**
+   - `batch_design` で修正操作を実行
+   - 再度 `get_screenshot` で確認
+
+3. **レイアウト確認**
+   - `snapshot_layout` でレイアウト構造を確認
+   - 要素の配置やサイズが適切か検証
+
+### ステップ4: 既存画面改修時のPlaywright連携
+
+**既存画面を改修する場合のみ実施：**
+
+1. **既存画面のスクリーンショット取得**
+   - `mcp__playwright__browser_navigate` で対象画面に遷移
+   - `mcp__playwright__browser_take_screenshot` でスクリーンショット取得
+   - スクリーンショットを参考にデザインを作成
+
+2. **デザイン参考資料として活用**
+   - 既存画面のレイアウト、配色、コンポーネントパターンを参考にする
+   - 一貫性のあるUI改修を実現
+
+## 出力
+
+- **ファイルパス**: `{仕様書ディレクトリ}/ui-design.pen`
+- **ファイル形式**: Pencil MCP形式（.penファイル）
+- ⚠️ .penファイルの内容は暗号化されており、Pencil MCPツール経由でのみアクセス可能
+- gitコミット対象としてそのまま管理
+
+## 品質ガイドライン
+
+1. **一貫性**: プロジェクト全体のデザインパターンとの整合性
+2. **ユーザビリティ**: 直感的なナビゲーションとインタラクション
+3. **レスポンシブ**: デスクトップ/タブレット/モバイルの考慮（要件に応じて）
+4. **アクセシビリティ**: コントラスト比、フォントサイズ、操作性の考慮
+5. **要件準拠**: requirements.mdの全UI要件をカバー

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

@@ -1,9 +1,10 @@
 ---
 name: task-executer
-description: タスクグループの実装を実行する専用エージェント。task-execコマンド内から呼び出され、要件定義・設計書に基づいた高品質な実装を行います。
+description: タスクグループの実装を実行する専用エージェント。einja-task-exec Skill内から呼び出され、要件定義・設計書に基づいた高品質な実装を行います。
 model: sonnet
 color: blue
-skills: []
+skills:
+  - einja-subagent-question-protocol
 ---
 
 あなたはシニアソフトウェアエンジニアで、クリーンアーキテクチャ、TDD、ドメイン駆動設計に精通した実装のエキスパートです。Google、Amazon、Microsoftでの大規模システム開発経験があり、保守性の高いコードを書くことに定評があります。
@@ -70,6 +71,11 @@ ACはpromptに直接含まれるので即座に参照可能。
 - モジュール分割の方針
 - 依存関係の設計
 
+> ⚠️ サブエージェントではAskUserQuestionは動作しません。
+> 以下のYAML例は「どんな質問をすべきか」の参照情報です。
+> 実際にはpreload済みの「サブエージェント質問プロトコル」に従い、
+> PENDING_QUESTIONS形式で質問を返却して停止してください。
+
 **⚠️ AskUserQuestion 確認ポイント**:
 以下の場合のみ AskUserQuestion で確認:
 - 複数の実装方法が考えられる場合
@@ -292,7 +298,7 @@ function slugify(text: string): string {
 
 ## 実行制約
 
-このエージェントは`task-exec`コマンドから`Task`ツール経由でのみ呼び出されます。直接実行することはできません。
+このエージェントは`einja-task-exec` Skillから`Task`ツール経由でのみ呼び出されます。直接実行することはできません。
 
 ## 連携エージェント
 

package/presets/default/.claude/agents/einja/task/task-modification-analyzer.md

@@ -1,6 +1,6 @@
 ---
 name: task-modification-analyzer
-description: タスク完了後の追加修正指示を解析し、ドキュメント修正の必要性・修正規模・品質保証プロセスを判定する専用エージェント。task-execコマンド内から呼び出され、修正方針を提案します。
+description: タスク完了後の追加修正指示を解析し、ドキュメント修正の必要性・修正規模・品質保証プロセスを判定する専用エージェント。einja-task-exec Skill内から呼び出され、修正方針を提案します。
 model: sonnet
 color: orange
 ---
@@ -340,7 +340,7 @@ color: orange
 ## 重要な制約事項
 
 ### 実行制約
-- このエージェントはtask-execコマンド内でのみ使用されます
+- このエージェントはeinja-task-exec Skill内でのみ使用されます
 - 直接ユーザーから呼び出すことはできません
 - 必ずユーザーの承諾を待ってから次のフェーズに進みます
 

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

@@ -4,12 +4,12 @@ description: 実装されたタスクグループの品質保証と動作確認
 model: sonnet
 color: purple
 skills:
-  - task-qa
+  - einja-task-qa
 ---
 
 # QA実行エージェント
 
-task-qa Skillの手順に従ってQAを実行し、結果を親プロセス（task-exec）に返却します。
+task-qa Skillの手順に従ってQAを実行し、結果を親プロセス（einja-task-exec Skill）に返却します。
 
 ## 絶対禁止事項
 
@@ -34,7 +34,7 @@ task-qa Skillの手順に従って実行してください。
 
 ## 出力形式（親プロセスへの橋渡し）
 
-SkillでJSON結果を生成後、以下のtask-exec互換形式に変換して出力:
+SkillでJSON結果を生成後、以下のeinja-task-exec Skill互換形式に変換して出力:
 
 ```markdown
 ## 🧪 品質保証フェーズ完了

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

@@ -1,8 +1,10 @@
 ---
 name: task-reviewer
-description: 実装内容をレビューし、要件定義・設計との整合性を確認する専用エージェント。task-execコマンド内から呼び出され、仮実装の検出や品質問題の特定を行います。
+description: 実装内容をレビューし、要件定義・設計との整合性を確認する専用エージェント。einja-task-exec Skill内から呼び出され、仮実装の検出や品質問題の特定を行います。
 model: sonnet
 color: yellow
+skills:
+  - einja-subagent-question-protocol
 ---
 
 あなたはコードレビューの専門家です。実装されたコードを要件定義・設計書と照合し、本番リリース可能な品質を保証します。
@@ -50,6 +52,11 @@ Task(subagent_type='Explore', prompt='[レビュー対象ファイル一覧]を
 **設計仕様との乖離発見時**:
 設計仕様と実装に大きな乖離が見られる場合、AskUserQuestionでロールバック/再実装の判断を仰ぐ。
 
+> ⚠️ サブエージェントではAskUserQuestionは動作しません。
+> 以下のYAML例は「どんな質問をすべきか」の参照情報です。
+> 実際にはpreload済みの「サブエージェント質問プロトコル」に従い、
+> PENDING_QUESTIONS形式で質問を返却して停止してください。
+
 ```yaml
 AskUserQuestion:
   question: "設計仕様と実装に大きな乖離があります。どのように対応しますか？"
@@ -81,6 +88,11 @@ AskUserQuestion:
 **複数の改善案がある場合**:
 複数の改善案がある場合、優先順位をAskUserQuestionで確認する。
 
+> ⚠️ サブエージェントではAskUserQuestionは動作しません。
+> 以下のYAML例は「どんな質問をすべきか」の参照情報です。
+> 実際にはpreload済みの「サブエージェント質問プロトコル」に従い、
+> PENDING_QUESTIONS形式で質問を返却して停止してください。
+
 ```yaml
 AskUserQuestion:
   question: "複数の改善案があります。どの順序で対応しますか？"

package/presets/default/.claude/commands/einja/einja-sync.md

@@ -1,6 +1,6 @@
 ---
 description: "テンプレート同期を実行。dev-cli/create-einja-appのsyncをカテゴリ選択式で実行し、コンフリクトも自動解消します"
-allowed-tools: Bash, AskUserQuestion, Read, Grep, Glob
+allowed-tools: Bash, AskUserQuestion, Read, Grep, Glob, Edit
 ---
 
 # テンプレート同期コマンド
@@ -16,8 +16,8 @@ allowed-tools: Bash, AskUserQuestion, Read, Grep, Glob
 以下のコマンドで利用可能なCLIを検出する。
 
 ```bash
-npx @einja/dev-cli --version 2>/dev/null
-npx create-einja-app --version 2>/dev/null
+npx --no @einja/dev-cli --version 2>/dev/null
+npx --no create-einja-app --version 2>/dev/null
 ```
 
 | 検出結果 | 動作 |
@@ -104,10 +104,10 @@ AskUserQuestion:
 
 ```bash
 # dev-cli の場合
-npx @einja/dev-cli sync --only <categories> --dry-run --yes
+npx --yes @einja/dev-cli sync --only <categories> --dry-run --yes
 
 # create-einja-app の場合
-npx create-einja-app sync --categories <categories> --dry-run
+npx --yes create-einja-app sync --categories <categories> --dry-run
 ```
 
 > **注**: 両CLIでカテゴリ指定のオプション名が異なる（dev-cli: `--only` / create-einja-app: `--categories`）
@@ -116,9 +116,15 @@ npx create-einja-app sync --categories <categories> --dry-run
 - 差分がない場合は「変更はありません」と表示して該当CLIの処理をスキップ
 - 差分がある場合はファイル一覧と変更内容をユーザーに提示
 
+#### dev-cli 使用時: 孤児ファイルの事前検出
+
+dry-run の JSON出力から `orphans` 配列を確認する。存在する孤児（`exists: true`）がある場合は一覧をテーブル表示し、Step 4 の確認時に孤児削除を含めるかユーザーに確認する。
+
 ### Step 4: 実行確認 → sync実行
 
-差分プレビューを見せた上で、ユーザーに実行可否を確認する。
+差分プレビューと孤児ファイル情報を見せた上で、ユーザーに実行可否を確認する。
+
+#### 孤児ファイルがない場合
 
 ```yaml
 AskUserQuestion:
@@ -131,75 +137,142 @@ AskUserQuestion:
       description: "変更を適用せずに終了します"
 ```
 
+#### 孤児ファイルがある場合（dev-cli 使用時）
+
+```yaml
+AskUserQuestion:
+  question: "上記の変更を適用しますか？（孤児ファイルN個を検出）"
+  header: "同期実行の確認"
+  options:
+    - label: "孤児ファイルも削除して同期（推奨）"
+      description: "表示された差分を適用し、テンプレートから削除されたファイル(N個)も削除します"
+    - label: "孤児ファイルは残して同期"
+      description: "表示された差分のみ適用し、孤児ファイルは残します"
+    - label: "キャンセル"
+      description: "変更を適用せずに終了します"
+```
+
 **実行順序**: dev-cli を先に実行し、次に create-einja-app を実行する（dev-cli が Claude Code 設定を先に更新するため）。
 
 ```bash
-# dev-cli
-npx @einja/dev-cli sync --only <categories> --yes --json
+# dev-cli（孤児削除あり）
+npx --yes @einja/dev-cli sync --only <categories> --yes --json --clean
+
+# dev-cli（孤児削除なし）
+npx --yes @einja/dev-cli sync --only <categories> --yes --json
 
 # create-einja-app
-npx create-einja-app sync --categories <categories>
+npx --yes create-einja-app sync --categories <categories>
 ```
 
 - dev-cli は `--json` オプションで構造化出力を取得しパースする
-- create-einja-app sync には `--yes` フラグがないが、`--categories` 指定時は対話プロンプトをスキップする
+- 孤児削除を選択した場合は `--clean` フラグを追加する（sync と孤児削除を1回の実行で完了）
+- create-einja-app sync には `--yes` フラグがない。`--categories` 指定時でもプロジェクト設定検出失敗時や依存バージョン競合時に対話プロンプトが発生する可能性がある。その場合は標準出力を確認し、必要に応じてユーザーに手動対応を促す
 
-### Step 5: コンフリクト検出 → 手動解消サポート
+### Step 5: コンフリクト検出 → 対話的解消（dev-cli のみ）
 
-sync 固有のコンフリクトを検出し、対話的に解消する（git コンフリクトとは異なる）。
+dev-cli の sync 固有のコンフリクトを検出し、1ファイルずつ対話的に解消する（git コンフリクトとは異なる）。create-einja-app にはファイルコンフリクトの概念がないため、このStepは dev-cli 使用時のみ実行する。
 
-#### コンフリクトの検出方法
+#### 5-1. コンフリクトファイル一覧取得
 
-| CLI | 検出方法 |
-|-----|---------|
-| dev-cli | JSON出力の `status: "partial_success"` かつ `conflicts > 0` |
-| create-einja-app | 標準出力に「コンフリクト」文字列が含まれる |
+dev-cli の JSON出力の `files` 配列から `status === "conflict"` のエントリを抽出する。
 
-#### コンフリクト解消フロー
+- コンフリクトなし → このStepをスキップ
+- コンフリクトファイル一覧をテーブル表示（ファイルパス、コンフリクト箇所数）
+- JSON出力のパースに失敗した場合は、標準出力をそのまま表示し、同期対象カテゴリのファイルパスのみを対象に `Grep` で dev-cli 固有のコンフリクトマーカー `<<<<<<< LOCAL (your changes)` を検索して検出する（プロジェクト全体を検索しないこと）
 
-1. **コンフリクトファイルの一覧を取得・表示**
-   - dev-cli: JSON出力の `conflicts` 配列からファイルパスを抽出
-   - create-einja-app: 標準出力から「コンフリクト」を含む行を抽出し、ファイルパスをパース
-   - 取得したファイルパスを表形式で一覧表示
+#### 5-2. 各ファイルを1ファイルずつ処理
 
-2. **各ファイルの差分内容を確認**
-   - `Read` ツールでコンフリクトファイルの内容を読み込み、差分をユーザーに提示
+以下を各コンフリクトファイルについて繰り返す:
 
-3. **ユーザーに解決方針を確認**
+a. `Read` でファイル全体を読み込む
+b. コンフリクトマーカーブロックを特定し、**双方の内容を分析・説明**:
+   - ローカル側: 何がカスタマイズされているか（例: プロジェクト固有の設定値）
+   - テンプレート側: 何が更新されたか（例: 新しいフィールド追加、バグ修正）
+   - 影響の説明: どちらを採用した場合に何が起きるか
+c. **具体的なマージ案を提案**: 両方の変更を分析し、統合案を作成（可能な場合）
+d. AskUserQuestion で解消方法を確認:
 
 ```yaml
 AskUserQuestion:
-  question: "コンフリクトの解決方針を選択してください"
-  header: "コンフリクト解決"
+  question: "{ファイル名}のコンフリクト解消方法を選択してください"
+  header: "コンフリクト解消"
   options:
-    - label: "テンプレート優先（リモートの最新版で上書き）"
-      description: "テンプレートの内容を採用し、ローカルのカスタマイズを破棄します"
-    - label: "ローカル優先（現在の内容を維持）"
-      description: "現在のローカルファイルを維持し、テンプレートの変更を破棄します"
-    - label: "手動マージ（1ファイルずつ確認）"
-      description: "各ファイルの差分を確認しながら、手動でマージ内容を決定します"
+    - label: "テンプレート優先"
+      description: "テンプレートの内容を採用。メリット: 最新の更新を取り込める。デメリット: ローカルのカスタマイズが失われる"
+    - label: "ローカル優先"
+      description: "現在の内容を維持。メリット: カスタマイズを保全できる。デメリット: テンプレートの更新が適用されない"
+    - label: "マージ案（両方の変更を統合）"
+      description: "{具体的なマージ内容の説明}。メリット: {利点}。デメリット: {欠点}"
+    - label: "このファイルをスキップ"
+      description: "コンフリクトマーカーを残して後で手動解消。メリット: 判断を保留できる。デメリット: 後で対応が必要"
 ```
 
-4. **方針に従って解消**
-   - テンプレート優先: dry-run出力やCLIのコンフリクト情報からテンプレート側の内容を特定し、`Edit` ツールで上書き
-   - ローカル優先: 現在の内容を維持（変更なし）
-   - 手動マージ: テンプレート内容とローカル内容を両方表示し、ユーザーと対話しながら `Edit` で編集
+**重要**: 必ず1ファイルごとにAskUserQuestionを実行する。複数ファイルをまとめて質問しない。
+
+e. 選択に応じて `Edit` でコンフリクトマーカーを解消する
+   - 複数マーカーがある場合はファイル末尾側から処理し、行番号ずれを防止する
+   - テンプレート優先: `<<<<<<< LOCAL` 〜 `=======` を削除し、`=======` 〜 `>>>>>>> TEMPLATE` のテンプレート側を残す
+   - ローカル優先: `<<<<<<< LOCAL` のローカル側を残し、`=======` 〜 `>>>>>>> TEMPLATE` を削除する
+   - マージ案: 提案したマージ内容でマーカーブロック全体を置換する
+f. 解消結果を `Read` で確認し、ユーザーに表示
+
+**コンフリクトマーカー形式**: `<<<<<<< LOCAL (your changes)` / `=======` / `>>>>>>> TEMPLATE (from @einja/cli)`
+
+#### 5-3. 全ファイル解消後の検証
 
-### Step 6: 結果サマリー表示
+- `Grep` で `<<<<<<<` パターンを検索し、未解消マーカーが残っていないか検証
+- スキップされたファイルがあれば一覧を再表示
+
+### Step 6: 孤児ファイル処理結果の確認（dev-cli のみ）
+
+Step 4 で孤児削除を選択した場合、JSON出力の `summary.orphansDeleted` を確認し、削除されたファイル一覧を記録する（Step 9 の詳細表示で使用）。
+
+Step 4 で孤児削除をスキップした場合、孤児ファイル一覧を再表示し「後で `npx --yes @einja/dev-cli sync --only <categories> --clean --yes` で削除できます」と案内する。
+
+### Step 7: direnv allow 実行確認
+
+`.envrc` が正常に更新された場合に `direnv allow` を実行する。
+
+1. dev-cli の JSON出力の `files` 配列から `.envrc` のエントリを確認する
+2. 以下の条件をすべて満たす場合のみ実行対象とする:
+   - `.envrc` の `status` が `"success"` である（`"skipped"`, `"conflict"`, `"error"` は対象外）
+   - ファイル内にコンフリクトマーカー（`<<<<<<< LOCAL`）が含まれていない
+3. `command -v direnv` で direnv の存在を確認する（インストールされていなければスキップし、Step 8 で案内表示）
+4. AskUserQuestion で確認:
+
+```yaml
+AskUserQuestion:
+  question: ".envrc が更新されました。direnv allow を実行しますか？"
+  header: "direnv allow"
+  options:
+    - label: "実行する（推奨）"
+      description: "更新済み .envrc を有効化します。環境変数が即座に反映されます"
+    - label: "スキップ"
+      description: "後で手動で direnv allow を実行します"
+```
+
+5. 「実行する」選択時に `direnv allow` を実行
+6. 結果を表示（成功/失敗。失敗しても同期処理全体は継続する）
+
+### Step 8: 結果サマリー表示
 
 テーブル形式で同期結果の概要を表示する。
 
 ```markdown
 ## 同期結果サマリー
 
-| CLI | 成功 | スキップ | コンフリクト |
-|-----|------|---------|------------|
-| dev-cli | 5 | 2 | 1 (解消済み) |
-| create-einja-app | 8 | 3 | 0 |
-| **合計** | **13** | **5** | **1** |
+| CLI | 成功 | スキップ | コンフリクト | 孤児削除 |
+|-----|------|---------|------------|---------|
+| dev-cli | 5 | 2 | 1 (解消済み) | 2 |
+| create-einja-app | 8 | 3 | 0 | - |
+| **合計** | **13** | **5** | **1** | **2** |
 ```
 
-### Step 7: 結果詳細表示
+- `.envrc` が変更された場合は「✓ direnv allow 実行済み」を表示
+- `.envrc` が変更されたが direnv 未インストールの場合は「⚠ direnv 未インストール。手動で `direnv allow` を実行してください」を表示
+
+### Step 9: 結果詳細表示
 
 各ファイルの詳細結果を以下の形式で表示する。
 
@@ -209,6 +282,7 @@ AskUserQuestion:
   ✓ .claude/skills/einja-task-commit/SKILL.md (更新)
   ⏭ .claude/agents/einja/task-executer.md (変更なし)
   ⚠ .claude/hooks/einja/pre-commit.sh (コンフリクト → 解消済み)
+  🗑️ .claude/skills/old-skill/SKILL.md (孤児ファイル削除)
 
 ### create-einja-app sync 詳細
   ✨ .github/workflows/ci.yml (新規)
@@ -224,6 +298,7 @@ AskUserQuestion:
 | ✨ | 新規ファイル追加 |
 | ⏭ | 変更なし（スキップ） |
 | ⚠ | コンフリクト発生（解消済み） |
+| 🗑️ | 孤児ファイル削除 |
 
 **パース方法:**
 - dev-cli: `--json` 出力の `files` 配列をパースして各ファイルのステータスを表示。JSON形式が不正な場合は標準出力をそのまま表示

package/presets/default/.claude/commands/einja/issue-exec.md

@@ -100,7 +100,7 @@ $ARGUMENTS をLLMとして自然言語解析し、以下の情報を抽出する
 - 以下を表示して**停止**:
   > issue-exec は tmux を必須としており、この環境では利用できません。
   > WSL2 環境での実行を推奨します。
-  > 代替: `/einja:task-exec` で個別タスクグループを逐次実行することは可能です。
+  > 代替: `einja-task-exec` Skill で個別タスクグループを逐次実行することは可能です。
 
 **インストール後の検証:**
 - `hash -r` で PATH をリフレッシュし、`command -v tmux && tmux -V` で成功確認
@@ -111,6 +111,8 @@ $ARGUMENTS をLLMとして自然言語解析し、以下の情報を抽出する
 
 #### 3. セッション復元
 - `--resume` フラグがある場合、`~/.einja/sessions/issue-{N}/session.json` からセッション状態を復元
+  - Manager worktree の存在確認: `git worktree list | grep issue-{N}/manager`
+    - 存在しない場合は再作成: `git worktree add ~/.einja/worktrees/issue-{N}/manager issue/{N}`
   - 未完了のPhaseのDirectorを再起動する
 
 ### Step 1: Issue パース
@@ -122,16 +124,18 @@ $ARGUMENTS をLLMとして自然言語解析し、以下の情報を抽出する
 3. `--max-phase` が指定されている場合、その番号以降のPhaseを除外
 
 ### Step 2: ブランチ & worktree 作成
-1. Issue ブランチ作成: `issue/{issue番号}`（base ブランチから）
-2. 各 Phase のブランチ作成: `issue/{issue番号}-phase{N}`（issue ブランチから）
-3. git worktree 作成:
+1. Issue ブランチ作成（メインリポジトリから）: `issue/{issue番号}`（base ブランチから）
+2. Manager worktree 作成（メインリポジトリから）:
    ```bash
    mkdir -p ~/.einja/worktrees/issue-{N}/
-   git worktree add ~/.einja/worktrees/issue-{N}/phase{M} issue/{N}-phase{M}
+   git worktree add ~/.einja/worktrees/issue-{N}/manager issue/{N}
+   git push -u origin issue/{N}
    ```
-4. worktree 作成時は必ずリモートにpush:
+3. **以降の操作は全て Manager worktree 内から実行**（cwd: `~/.einja/worktrees/issue-{N}/manager`）
+4. 各 Phase のブランチ作成（Manager worktree から）: `issue/{issue番号}-phase{N}`（issue ブランチから）
+5. Phase worktree 作成（Manager worktree から）:
    ```bash
-   git push -u origin issue/{N}
+   git worktree add ~/.einja/worktrees/issue-{N}/phase{M} issue/{N}-phase{M}
    git push -u origin issue/{N}-phase{M}
    ```
 
@@ -164,7 +168,7 @@ session.json の初期状態:
 
 ### Step 4: tmux セッション作成
 ```bash
-tmux new-session -d -s einja-{issue番号} -n manager
+tmux new-session -d -s einja-{issue番号} -n manager -c ~/.einja/worktrees/issue-{N}/manager
 ```
 
 ### Step 5: Director 起動（Phase単位）
@@ -199,15 +203,16 @@ tmux send-keys -t einja-{N}:director-phase{M} '
 1. 依存関係のないタスクグループは並列でWorkerを起動してください
 2. 各Worker には tmux window + claude 対話モードで起動:
    - worktree作成: git worktree add ~/.einja/worktrees/issue-{N}/task-{X.Y} task/{N}-{X.Y}
-   - tmux: tmux new-window + claude 起動 + /einja:task-exec #{N} {X.Y} を実行
+   - tmux: tmux new-window + claude 起動 + einja-task-exec Skill で #{N} {X.Y} を実行
 3. Worker完了後:
    - ステータスファイルでPR番号を確認
    - マージモードに応じたPR処理
    - 他active Workerにsync通知
    - 完了したworktree削除
-4. 質問対応: Workerからの質問にspec/design/issueベースで回答。回答不可ならManagerにエスカレーション
-5. Phase完了時: ステータスファイルで Manager に報告
-6. GitHub Issue のチェックボックス更新
+4. Phase完了時: `/einja-create-pr --auto --base issue/{N}` でPhase PRを作成
+5. 質問対応: Workerからの質問にspec/design/issueベースで回答。回答不可ならManagerにエスカレーション
+6. Phase完了時: ステータスファイルで Manager に報告
+7. GitHub Issue のチェックボックス更新
 
 ## 質問エスカレーション
 回答不可な質問は ~/.einja/sessions/issue-{N}/questions/ にJSONファイルを作成してManagerに通知してください。
@@ -237,7 +242,8 @@ Manager は以下を定期的に監視:
    - Director/Worker の tmux window が消失した場合のリカバリ処理
 
 ### Step 7: 全Phase完了 → 最終PR
-1. 最終PR作成: `gh pr create --base {baseBranch} --head issue/{N}`
+1. 最終PR作成: `/einja-create-pr --auto --base {baseBranch}` を実行
+   - changeset自動生成 + ラベル付与 + PR作成が一括実行される
 2. PR URL を表示
 3. セッションクリーンアップ（worktree 削除、セッションファイル削除）
 
@@ -253,7 +259,7 @@ Manager は以下を定期的に監視:
 
 ```
 {baseBranch}
- └── issue/{N}                        Manager管理
+ └── issue/{N}                        Manager worktree
       ├── issue/{N}-phase1             Director1 worktree
       │    ├── task/{N}-1.1            Worker1.1 worktree
       │    ├── task/{N}-1.2            Worker1.2 worktree
@@ -265,6 +271,7 @@ Manager は以下を定期的に監視:
 ## worktree 物理パス
 ```
 ~/.einja/worktrees/issue-{N}/
+├── manager/                      ← Manager cwd
 ├── phase{M}/                     ← Director cwd
 ├── task-{X.Y}/                   ← Worker cwd
 ```
@@ -339,7 +346,7 @@ Manager は以下を定期的に監視:
 | Worker異常終了（PR作成済み） | tmux window消失 + PRあり | スキップ（PRマージ待ち継続） |
 | Director異常終了 | tmux window消失 + ステータス未更新 | 各Workerのステータスを確認 → 未完了Workerのみ再実行 |
 | Manager異常終了 | ユーザー手動 | `--resume` でセッション復元 |
-| rebaseコンフリクト | git rebase失敗 | conflict-resolverで自力解消 |
+| rebaseコンフリクト | git rebase失敗 | einja-conflict-resolver Skillで自力解消 |
 | CI失敗 | gh run status | 修正 → 再push → 再CI待機 |
 
 ## CI 待機タイムアウト
@@ -382,22 +389,25 @@ git worktree add ~/.einja/worktrees/issue-{N}/task-{X.Y} task/{N}-{X.Y}
 tmux new-window -t einja-{N} -n worker-{X.Y}
 tmux send-keys -t einja-{N}:worker-{X.Y} 'cd ~/.einja/worktrees/issue-{N}/task-{X.Y} && claude' Enter
 
-# 3. task-exec コマンドを実行
+# 3. einja-task-exec Skill を実行
 # claude 起動後に以下を送信:
-tmux send-keys -t einja-{N}:worker-{X.Y} '/einja:task-exec #{N} {X.Y}' Enter
+tmux send-keys -t einja-{N}:worker-{X.Y} '/einja-task-exec #{N} {X.Y}' Enter
 ```
 
 ## セッションクリーンアップ
 
 Issue完了時に以下を自動削除:
 - `~/.einja/sessions/issue-{N}/` （セッションファイル）
-- `~/.einja/worktrees/issue-{N}/` （worktree。事前に `git worktree remove` を実行）
+- `~/.einja/worktrees/issue-{N}/` （worktree。事前に `git worktree remove` を各ディレクトリに対して実行）
+  - `git worktree remove ~/.einja/worktrees/issue-{N}/task-{X.Y}`（Worker）
+  - `git worktree remove ~/.einja/worktrees/issue-{N}/phase{M}`（Director）
+  - `git worktree remove ~/.einja/worktrees/issue-{N}/manager`（Manager - 最後に削除）
 - ローカルブランチのクリーンアップ（task/*, issue/*-phase*）
 
 ## 注意事項
 
 - 全プロセスは**対話モード**（`claude`、非 `-p`）で起動。質問エスカレーションのため
-- Worker 内部のタスク並列実行は既存の task-exec フロー（Task ツール + run_in_background）をそのまま活用
+- Worker 内部のタスク並列実行は既存の einja-task-exec Skill フロー（Task ツール + run_in_background）をそのまま活用
 - ステータスファイルの `status.json` 更新には `flock` による排他制御を使用
 - 質問ファイルは1ファイル1質問のためロック不要（UUID でアトミック書き込み）
 - Worker は各タスク完了毎 + PR作成前にステータスファイルをチェック（sync_required検知時は次タスク開始前にrebase）

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

@@ -51,7 +51,7 @@ Glob: .claude/commands/**/*.md
 
 例：
 - `task-executer` → `.claude/agents/task/task-executer.md`
-- `spec-requirements-generator` → `.claude/agents/specs/spec-requirements-generator.md`
+- `requirements-generator` → `.claude/agents/issue-specs/requirements-generator.md`
 
 **変換テンプレート**:
 
@@ -131,8 +131,8 @@ alwaysApply: false
 
 ```bash
 # 例（フォルダ形式）
-.claude/commands/task-exec.md → .cursor/rules/task-exec/RULE.md
-.claude/commands/spec-create.md → .cursor/rules/spec-create/RULE.md
+.claude/skills/einja-task-exec/SKILL.md → .cursor/rules/task-exec/RULE.md
+.claude/skills/einja-issue-spec-create/SKILL.md → .cursor/rules/spec-create/RULE.md
 .claude/commands/einja/start-dev.md → .cursor/rules/start-dev/RULE.md
 ```
 
@@ -178,8 +178,8 @@ Cursor で以下のルールが利用可能になりました：
 
 ### レガシーファイル
 以下の古い形式のファイルが検出されました（削除推奨）：
-- `.cursor/commands/task-exec.md`
-- `.cursor/commands/spec-create.md`
+- `.cursor/commands/einja-task-exec.md`
+- `.cursor/commands/einja-issue-spec-create.md`
 ```
 
 
@@ -216,7 +216,7 @@ Cursor で以下のルールが利用可能になりました：
 ├── .cursor/rules/spec-create/RULE.md (3箇所のサブエージェント参照を変換)
 ├── .cursor/rules/task-exec/RULE.md (4箇所のサブエージェント参照を変換)
 ├── .cursor/rules/start-dev/RULE.md (変換不要)
-└── .cursor/rules/update-docs-by-task-specs/RULE.md (変換不要)
+└── .cursor/rules/update-docs-by-issue-specs/RULE.md (変換不要)
 ```
 
 ## エラー処理