@einja/dev-cli 0.1.41 → 0.1.44

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 (変換不要)
 ```
 
 ## エラー処理