create-einja-app 0.3.2 → 0.3.4

package/templates/default/docs/plans/recursive-fluttering-mitten.md

@@ -0,0 +1,176 @@
+# einja-issue-spec-createにui-designステップを追加 + Pencil MCP設定
+
+## Context
+
+einja-issue-spec-create Skillは仕様書を段階的に作成するワークフローだが、現在はUI設計がdesign.md内のmermaid/表形式のみ。
+Pencil MCPを活用してビジュアルなUIモックアップ（.penファイル）を生成するステップを追加し、UXの合意形成を効率化する。
+
+## Skill-first評価
+
+**スキップ**: 既存のeinja-issue-spec-create Skillへの機能追加であり、新規Skill作成の対象外。
+
+## 変更対象ファイル
+
+| # | ファイル | 操作 | 概要 |
+|---|---------|------|------|
+| 1 | `~/.claude/settings.json` | 変更 | Pencil MCP mcpServers設定追加 |
+| 2 | `.claude/settings.json` | 変更 | Pencil MCP permissions追加 |
+| 3 | `.claude/agents/einja/issue-specs/ui-design-generator.md` | **新規** | UIデザイン生成エージェント |
+| 4 | `.claude/skills/einja-issue-spec-create/SKILL.md` | 変更 | ui-designステップ挿入 + Phase再番号付け |
+| 5 | `.claude/agents/einja/issue-specs/design-generator.md` | 変更 | ui-design.pen参照追加 |
+
+**注意**: `.claude/agents/einja/` および `.claude/skills/einja-*/` 配下のファイルは `presets/default/` に自動コピーされる。直接編集は不要。
+
+## 実装手順
+
+### Step 1: Pencil MCP設定追加（並行可）
+
+#### 1a. `~/.claude/settings.json`（グローバル）にmcpServers追加
+
+MCPサーバー定義はグローバル設定に配置（下流プロジェクトへの影響を防ぐため）:
+
+```json
+"mcpServers": {
+  "pencil": {
+    "transport": "stdio",
+    "command": "/Applications/Pencil.app/Contents/Resources/app.asar.unpacked/out/mcp-server-darwin-arm64",
+    "args": ["--app", "desktop"],
+    "env": {}
+  }
+}
+```
+
+#### 1b. `.claude/settings.json`（プロジェクト）にpermissions追加
+
+`permissions.allow`に以下を追加:
+
+```
+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
+```
+
+### Step 2: `ui-design-generator.md` 新規作成（並行可）
+
+**パス**: `.claude/agents/einja/issue-specs/ui-design-generator.md`
+
+**構造**（既存エージェントパターンに準拠 - `design-generator.md`等と同じ形式）:
+- **frontmatter**: name, description, tools（Pencil MCP + Playwright MCP読み取り用）, model: sonnet, color: purple
+- **ペルソナ**: UIデザイナー/UXエンジニアリング専門家
+- **ワークフロー**:
+  1. ステップ0: requirements.md読み込み + 既存画面判定
+  2. ステップ1: Pencil MCP環境準備（open_document → get_guidelines → get_style_guide）
+  3. ステップ2: 画面設計（find_empty_space_on_canvas → batch_design）
+     - `get_guidelines` でPencil MCPの操作ルール・構文仕様を取得してから実行
+  4. ステップ3: ビジュアル確認（get_screenshot）と修正
+  5. ステップ4: 既存画面改修時のPlaywright連携（スクリーンショット取得 → 参考にデザイン作成）
+- **複数画面管理**: 1つの.penファイル内に複数フレーム。横方向（right）に自動配置、padding: 100px
+- **既存画面改修**: Playwright MCPでスクショ取得 → 参考にしてデザイン作成
+- **出力**: `{仕様書ディレクトリ}/ui-design.pen`（gitコミット対象）
+
+### Step 3: `einja-issue-spec-create/SKILL.md` 更新（Step 1,2に依存）
+
+#### 変更1: allowed-tools に `mcp__pencil__*`, `mcp__playwright__*` 追加
+
+#### 変更2: Phase構成の再番号付け
+
+```
+Phase 1: requirements.md（要件定義書）         ← 変更なし
+Phase 2: ui-design.pen（UIデザイン）           ← 新規
+Phase 3: design.md（設計書）                   ← 旧Phase 2
+Phase 4: QAテスト仕様生成                      ← 旧Phase 3
+Phase 5: GitHub Issueへのタスク記述            ← 旧Phase 4
+```
+
+#### 変更3: Phase 2 ui-design ステップの挿入
+
+Phase 1の後に以下を挿入:
+- **スキップ判定**: requirements.mdに画面・UI・フォーム関連の要件がない場合はスキップ
+  - 明示的な判定基準: requirements.md内に「画面」「UI」「フォーム」「ダッシュボード」「表示」等のキーワードが含まれるか確認
+  - 判断が曖昧な場合はAskUserQuestionでユーザーに確認
+- **既存画面確認**: 改修の場合はPlaywright MCPでスクリーンショット取得
+- **エージェント呼び出し**: `ui-design-generator`で.pen生成
+- **ユーザー確認**: get_screenshotで各画面プレビューを提示
+- **承認後**: ui-design.penをコミット＆プッシュ
+  - コミットメッセージ: `docs: {機能名}のUIデザインを追加`
+
+#### 変更4: 旧Phase 2→3, 3→4, 4→5 の番号修正
+
+全てのPhase参照・セクション番号・サブセクション（4.1→5.1, 4.2→5.2等）を更新。
+
+#### 変更5: Phase 3（旧Phase 2）design.mdセクションに ui-design.pen参照追加
+
+```
+- **ui-design.penが存在する場合、Pencil MCPでビジュアルモックアップを参照してUI関連セクション（9-11）を作成**
+```
+
+#### 変更6: 成果物ディレクトリ構成に `ui-design.pen` 追加
+
+```
+/docs/specs/issues/{機能カテゴリ名}/issue{N}-{機能名}/
+├── requirements.md      # Phase 1
+├── ui-design.pen        # Phase 2（UI関連のみ）
+├── design.md            # Phase 3
+└── qa-tests/            # Phase 4
+```
+
+#### 変更7: Phase 5 Issue説明文にUIデザインへのリンク追加
+
+### Step 4: `design-generator.md` 更新（Step 2に依存）
+
+**パス**: `.claude/agents/einja/issue-specs/design-generator.md`
+
+- ステップ0: ui-design.penの存在確認を追加
+- ステップ1: 優先読み込みリストにui-design.penを追加
+- セクション10（画面設計）: ui-design.pen存在時はPencil MCPで参照（batch_get + get_screenshot）
+- tools: `mcp__pencil__batch_get`, `mcp__pencil__get_screenshot` を追加（読み取り専用）
+
+## ui-design.pen と design.md の関係
+
+| 観点 | ui-design.pen (Phase 2) | design.md (Phase 3) |
+|------|------------------------|---------------------|
+| 形式 | ビジュアル（.penファイル） | テキスト（mermaid/表） |
+| 目的 | UX検証・デザイン合意 | 実装仕様の定義 |
+| git管理 | .penファイルをコミット | 通常のmdファイル |
+| セクション10 画面設計 | 各画面のビジュアルモックアップ | mermaid図（Pencil MCPで.penを参照して作成） |
+
+**補完関係**: ui-design.pen=「何をどう見せるか」、design.md=「どう実装するか」
+
+## 実行順序
+
+```
+Step 1 ─┐
+         ├─→ Step 3 ─→ 完了
+Step 2 ─┤
+         └─→ Step 4
+```
+
+Step 1とStep 2は並行実行可能。Step 3はStep 1,2完了後、Step 4はStep 2完了後。
+
+## Codexレビュー指摘事項への対応
+
+| 指摘 | 対応 |
+|------|------|
+| mcpServersが下流プロジェクトにコピーされる | グローバル設定に配置、プロジェクトはpermissionsのみ |
+| .penファイルのgit管理 | .penファイルをそのままgitコミット |
+| batch_designのAPI仕様未記載 | エージェント内でget_guidelinesで仕様を取得してから実行 |
+| Phase 2スキップ基準が曖昧 | キーワードベースの判定基準を明示 |
+| allowed-tools更新の必要性 | Skillからサブエージェント経由で使うため追加 |
+
+## 検証方法
+
+1. **Pencil MCP接続テスト**: `mcp__pencil__get_editor_state` が応答するか確認
+2. **SKILL.md全体フロー確認**: Phase番号の整合性、次ステップへの参照が正しいか目視確認
+3. **新規エージェント構文確認**: frontmatterの形式が既存エージェント（design-generator.md等）と一致するか確認
+4. **CLIビルドへの影響確認**: agents/、skills/配下の新ファイルが`presets/default/`に自動コピーされることを確認

package/templates/default/docs/plans/todo-create-einja-app-ux-fix.md

@@ -0,0 +1,16 @@
+# TODO: create-einja-app 利用者体験の改善
+
+## 進捗
+
+| # | タスク | 状態 | 担当 |
+|---|--------|------|------|
+| 1 | template.ts に `.sh` ファイルの実行権限付与処理を追加 | ✅ 完了 | sub-agent-1 |
+| 2 | init.sh から `pnpm install` を削除（2ファイル） | ✅ 完了 | sub-agent-2 |
+| 3 | README にトラブルシューティング項目を追加 | ✅ 完了 | sub-agent-3 |
+| 4 | テストのモック順修正 | ✅ 完了 | sub-agent-4 |
+| 5 | 検証（テスト・lint・typecheck） | ✅ 完了 | 親エージェント |
+
+## 検証結果
+- `pnpm -F create-einja-app test`: 108テスト全パス
+- `pnpm prepush`: lint + typecheck + test 全7タスク成功
+- テンプレート `templates/default/` は `.gitignore` 管理。ビルド時に `scripts/init.sh` から自動生成

package/templates/default/docs/plans/todo-direnv-hang-fix.md

@@ -0,0 +1,12 @@
+# TODO: direnvハング修正 + 秘密鍵ローテーション自動化
+
+## 進捗
+
+| TODO | 内容 | 担当 | 状態 |
+|------|------|------|------|
+| TODO-1 | ensure-serena.sh: lsof → nc -z | Agent-A | ✅ 完了 |
+| TODO-2 | env-rotate-secrets.ts: 非対話モード追加 | Agent-B | ✅ 完了 |
+| TODO-3 | post-setup.ts: 処理順序変更 + 自動ローテーション | Agent-C | ✅ 完了 |
+| TODO-4 | .gitignore: .bak パターン追加 | Agent-C | ✅ 完了 |
+| 検証 | prepush (lint + typecheck + test) | 親 | ✅ 全パス |
+| 検証 | git diff 確認 | 親 | ✅ 意図通り |

package/templates/default/docs/plans/todo-github-actions-release-workflow.md

@@ -0,0 +1,34 @@
+# TODO: GitHub Actions リリースワークフロー + 承認フロー
+
+## Phase 1: changesets基盤導入
+- [x] `package.json` に devDependencies + scripts 追加
+- [x] `.changeset/config.json` 新規作成
+- [x] `pnpm install` で依存関係インストール
+
+## Phase 3: deploy-stable-branches.yml 大規模改修
+- [x] ワークフロー全体ガード（無限ループ防止）追加
+- [x] `permissions: contents: write` 追加
+- [x] migrate ジョブをブランチ別に分割
+- [x] deploy ジョブをブランチ別に分割（develop/staging/production）
+- [x] release-staging ジョブ追加（PreRelease作成）
+- [x] release-production ジョブ追加（changeset消費 + Release作成）
+
+## Phase 4: .github/release.yml
+- [x] リリースノート設定ファイル新規作成
+
+## Phase 5: changeset-status.yml
+- [x] PR上のchangesetステータス表示ワークフロー新規作成
+
+## Phase 6: einja-create-pr Skill
+- [x] `.claude/skills/einja-create-pr/SKILL.md` 新規作成
+- [x] `.claude/commands/einja/issue-exec.md` のPR作成部分をeinja-create-pr呼び出しに変更
+
+## Phase 7: ドキュメント追記
+- [x] `docs/einja/steering/infrastructure/deployment.md` にリリース管理セクション追記
+- [x] `docs/einja/steering/development-workflow.md` にchangeset運用フロー追記
+
+## 検証
+- [x] YAML構文検証（deploy-stable-branches.yml, changeset-status.yml）
+- [x] JSON構文検証（.changeset/config.json）
+- [x] ワークフロージョブ構造確認（9ジョブ、ブランチ別分岐、環境設定）
+- [x] `pnpm prepush` 通過（lint + typecheck + test）

package/templates/default/docs/plans/todo-glistening-conjuring-cascade.md

@@ -0,0 +1,20 @@
+# TODO: JSON 配布メカニズムの統一実装
+
+## Phase 1（並列実行）
+
+- [x] **TG-A**: コアSync Engine（Steps 0+2+4: 型定義 + JsonProcessor全面改修 + MetadataManager更新）
+- [x] **TG-B**: copy-presets.mjs（Step 5: package.jsonフルコピー + テンプレートscripts同期）
+- [x] **TG-C**: file-filter.ts（Step 6: root-config + claude-configカテゴリ追加）
+
+## Phase 2（TG-A完了後）
+
+- [x] **TG-D**: sync.ts変更（Steps 1+3: fileName→フルパス + JSON処理フロー変更）
+
+## Phase 3（コード変更完了後、並列）
+
+- [x] **TG-E**: ドキュメント更新（Step 7: setup-flow.md, SKILL.md, CLAUDE.md）
+- [x] **TG-F**: JsonProcessorユニットテスト作成（バグ修正含む）
+
+## Phase 4
+
+- [x] **検証**: ビルド・テスト・prepush（全パス: 607 tests, 29 files, 7 turbo tasks）

package/templates/default/docs/plans/todo-issue-spec-rename.md

@@ -0,0 +1,24 @@
+# TODO: task-spec → issue-spec リネーム + コマンド→Skill移行
+
+## Phase 1: ファイル移動・作成
+
+- [x] TG-1.1: エージェントディレクトリ移動+ファイルリネーム
+- [x] TG-1.2: スキルディレクトリリネーム
+- [x] TG-1.3: spec-create → einja-issue-spec-create Skill移行
+- [x] TG-1.4: task-exec → einja-task-exec Skill移行
+- [x] TG-1.5: update-docs-by-task-specs リネーム
+
+## Phase 2: 参照更新
+
+- [x] TG-2.1: エージェント内部参照更新（10ファイル）
+- [x] TG-2.2: スキル内部参照更新（9ファイル）
+- [x] TG-2.3: コマンド/設定ファイル参照更新（4ファイル）
+- [x] TG-2.4: docs/einja/ 参照更新（5ファイル）
+- [x] TG-2.5: CLAUDE.md + README.md 更新
+
+## Phase 3: 検証
+
+- [x] TG-3.1: 参照整合性チェック（旧パス残存ゼロ確認、1箇所修正）
+- [x] TG-3.2: pnpm prepush 通過確認
+- [x] TG-3.2: .cursor/commands/ 旧ファイル手動削除
+- [ ] TG-3.2: sync-cursor-commands 再生成（コミット後に実行推奨）

package/templates/default/docs/plans/todo-skill-creator-upgrade.md

@@ -0,0 +1,18 @@
+# TODO: einja-skill-creator 公式版追従改善
+
+## Phase 0: plan-mode-skill-loader.sh hook修正
+- [x] hookのデバッグ・修正（`hookSpecificOutput`内に`additionalContext`を配置）
+
+## Phase 1: スクリプト互換性修正
+- [x] 1-a. run_loop.py を公式版ベースに再構築（holdout float化、並列バッチ評価、blinded_history、ブラウザ自動起動、results-dir）
+- [x] 1-b. improve_description.py のblinded_history対応（test_results引数削除）
+- [x] 1-c. aggregate_benchmark.py を公式版に差し替え（旧版→compare_runs.py）
+
+## Phase 2: SKILL.md内容補完
+- [x] 2-a. Phase 1連動のコマンド例更新（holdout 0.4、improve-model、results-dir記載）
+- [x] 2-b. 公式版の重要な詳細を追記（#5 grading.jsonフィールド警告, #6 eval query Good/Bad例, #7 タイミング即時処理, #8 コアループ再掲+TodoList, #9 Claude.ai制限拡充, #12 feedback.jsonスキーマ, #13 Coworkアクセス注記）
+- [x] 2-c. compare_runs.py の説明追加
+
+## Phase 3: UX改善
+- [x] generate_report.py のstdin対応追加（位置引数、-o省略可、stdoutデフォルト）
+- [x] 回帰テスト（init_skill.py, quick_validate.py構文チェック・import確認）

package/templates/default/docs/plans/todo-unified-crafting-valiant.md

@@ -0,0 +1,23 @@
+# TODO: Skill命名規則の文書化 + 配布制御のプレフィックスベース化
+
+## 進捗
+
+| # | タスク | 担当 | 状態 |
+|---|--------|------|------|
+| 1 | einja-skill-creator/SKILL.md に命名規則セクション追加 | Agent-1 | ✅ |
+| 2 | CLAUDE.md 更新（命名規則追加 + L139参照パス + L252注釈更新） | Agent-2 | ✅ |
+| 3 | Skill name フィールド統一 + ディレクトリリネーム + 参照パス更新 | Agent-3 | ✅ |
+| 4 | copy-presets.mjs + file-copier.ts のプレフィックスベース改修 | Agent-4 | ✅ |
+| 5 | ビルド検証（`pnpm --filter @einja/dev-cli build`） | 親 | ✅ |
+| 6 | 全体検証（`pnpm prepush`） | 親 | ✅ |
+| + | 既存バグ修正: setup-flow.md マーカーバリデーションエラー | 親 | ✅ |
+| 7 | Codexレビュー | codex-agent | ⏳ |
+
+## 検証結果
+
+- ビルド成功（`pnpm --filter @einja/dev-cli build`）
+- `presets/default/.claude/skills/` に `_einja-*` 4個 + `einja-*` 15個が配布 ✅
+- `cli-package-specs` は配布されていない ✅
+- 旧ディレクトリ名の残留なし ✅
+- `pnpm prepush` 全パス（lint + typecheck + test: 7 tasks successful）✅
+- 参照パスの漏れなし ✅

package/templates/default/docs/plans/unified-crafting-valiant.md

@@ -0,0 +1,60 @@
+# Plan: ensure-serena.sh の既存インスタンス判定を厳密化
+
+## Context
+
+`ensure-serena.sh` の既存インスタンスチェック（L11-16）は `.serena-port` に記録されたPIDの生存のみを `kill -0` で確認している。
+しかし以下のケースで **別プロジェクトのSerenaに誤接続** する問題がある：
+
+1. 自プロジェクトのSerenaがクラッシュ（PID死亡）
+2. 別プロジェクトのSerenaが同じポートを取得
+3. 次回 `direnv reload` 時、PIDリサイクルで `kill -0` が成功 → 別プロジェクトのSerenaに接続
+
+**根本原因**: PID生存だけでは「そのPIDが記録されたポートを実際にLISTENしているか」が判定できない。
+
+## 変更内容
+
+### TODO-1: 既存インスタンスチェックに PID×ポート検証を追加
+
+**ファイル**: `scripts/ensure-serena.sh` L11-16
+
+**現在のコード**:
+```bash
+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
+```
+
+**修正後**:
+```bash
+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 \
+     && ps -ww -o command= -p "$_saved_pid" 2>/dev/null | grep -q "serena start-mcp-server.*--project ${_SERENA_BASE}"; then
+    # PIDが生存 かつ 自プロジェクトのSerenaプロセス → 再利用
+    export SERENA_PORT="$_saved_port"
+    return 0 2>/dev/null || true
+  fi
+  # PID死亡 or 別プロセス/別プロジェクトのSerena → クリーンアップ
+  rm -f "$_SERENA_PORT_FILE"
+fi
+```
+
+**判定ロジック**: `kill -0`（PID生存） AND `ps`（そのPIDのコマンドラインに `serena start-mcp-server` + `--project <自プロジェクトパス>` が含まれる）の両方を満たす場合のみ、自プロジェクトのSerenaと判定する。
+
+**`lsof` ではなく `ps` を採用した理由**（Codexレビュー指摘）:
+- `lsof` はLinuxで未導入のディストロがある。フォールバックが必要になり複雑化する
+- `ps` はPOSIX標準でmacOS/Linux両方で利用可能
+- `ps` ならプロセス名だけでなく `--project` 引数まで確認でき、「自プロジェクトのSerenaか」を厳密に判定できる
+
+## 検証
+
+1. `source scripts/ensure-serena.sh` で正常起動を確認
+2. 再度 `source` して既存インスタンスが再利用されることを確認
+3. `.serena-port` のPIDを偽の値に書き換え → 再起動が走ることを確認

package/templates/default/docs/plans/velvety-chasing-spark.md

@@ -0,0 +1,28 @@
+# Plan: einja-project-overview SKILL.md の参照先再定義
+
+## Context
+
+「プロジェクト概要」Skillが関心事の異なるドキュメント（コーディング規約、インフラ管理Skill等）を参照していた。「このプロジェクトは何か？どういう構造か？」に答えるハブとして、適切な参照先のみに絞る。
+
+## 変更内容
+
+**対象ファイル**: `.claude/skills/einja-project-overview/SKILL.md`
+
+### 参照すべきドキュメント（3つ）
+
+| 参照 | 目的 |
+|------|------|
+| `docs/einja/steering/README.md` | 全ドキュメントへのナビゲーションハブ |
+| `docs/einja/steering/product.md` | 何のためのプロジェクトか（製品ビジョン） |
+| `docs/einja/steering/architecture.md` | どういう技術構成か |
+
+### 除外するもの
+
+- `infra-maintenance` Skillリンク → インフラ運用は別の関心事
+- コーディング規約・コンポーネント設計 → 開発ガイドラインの関心事
+- `db-schema-design.md` → スキーマ詳細設計であり概要ではない
+- `backend-architecture.md` → 4層設計の実装詳細
+
+## 検証
+
+- SKILL.md の内容を `Read` で確認

package/templates/default/docs/plans/wondrous-strolling-crystal-agent-a0615fc.md

@@ -0,0 +1,215 @@
+# Plan Review: einja-sync コマンド自動化改善
+
+## レビュー対象
+
+`docs/plans/wondrous-strolling-crystal.md`
+
+## レビュー観点
+
+1. 実現可能性
+2. コンフリクト解消の品質（conflict-resolverスキルとの整合性）
+3. エッジケース
+4. allowed-toolsへの `Edit` 追加の妥当性
+5. `npx --yes` の副作用
+6. 孤児削除の再実行アプローチ
+7. 全体の整合性
+
+---
+
+## レビュー結果
+
+### ✅ 良い点
+
+1. **conflict-resolverとの整合性**: 分析→説明→提案→確認の流れを踏襲
+2. **1ファイルずつ確認**: 複数ファイルをまとめて質問しない、という重要な制約を明記
+3. **マージ案の提示**: ローカル・テンプレート双方の分析とメリット・デメリットの説明
+4. **direnv自動化**: `.envrc` 変更検出と自動 `direnv allow` 実行
+5. **JSON出力の活用**: dev-cliの `--json` 出力を活用してコンフリクト検出
+
+---
+
+## 🚨 重大な問題
+
+### 1. `npx --yes` の副作用（最重要）
+
+**問題**: Step 1 の `npx --yes @einja/dev-cli --version` で、`@einja/dev-cli` がインストールされていない場合、**自動的にグローバルキャッシュにインストール**される。
+
+**影響**:
+- CLI検出の意図: 「利用可能か確認」→ 実際: 「なければインストール」
+- ユーザーが意図せずパッケージをインストールしてしまう
+- `--version` チェックが純粋な検出ではなくなる
+
+**推奨修正**:
+- Step 1 で `npx --yes` は使用しない（検出のみ）
+- `command -v npx` で npx 自体の存在確認
+- `npm list -g @einja/dev-cli` または `pnpm list -g @einja/dev-cli` でグローバルインストール確認
+- ローカルに `node_modules/@einja/dev-cli` が存在するか確認
+
+または、より簡潔に:
+```bash
+# npx でキャッシュチェック（インストールなし）
+npx --version @einja/dev-cli 2>/dev/null
+# → 失敗なら未インストール、成功なら利用可能
+```
+
+ただし、Step 3, 4 の実際の sync 実行時は `npx --yes` を使用してOK（この時点で実行意図が明確）。
+
+---
+
+### 2. 孤児削除の再実行アプローチのリスク
+
+**問題**: C. 孤児ファイル自動ハンドリング 4. で `npx --yes @einja/dev-cli sync --only <categories> --clean --yes` を再実行する方式。
+
+**リスク**:
+- 再度 sync 処理が走る（差分がないとはいえ、ファイルスキャンやメタデータ処理が重複）
+- `--clean --yes` を別のタイミングで実行するとコンフリクト解消前のファイルを削除する可能性
+- 孤児削除だけを独立して処理できるCLIオプションがないか確認すべき
+
+**推奨確認事項**:
+- `sync.ts` を確認したところ、孤児削除は `--clean` フラグで処理される（L179-L239, L632-L682）
+- 既に sync 処理後であれば、メタデータに孤児情報が残っているので、CLI側で孤児削除専用の処理を追加する方が安全
+- または、Bash + Read で孤児ファイルを直接削除する（ただし CLI の責務を侵害する可能性）
+
+**代替案**:
+- コマンド側で直接ファイル削除を実装（`rm` / `fs.remove` 相当）
+- ただし、`sync.ts` の孤児削除ロジックを再実装することになり、DRY原則に反する
+
+**判断**:
+- 現状のアプローチ（再実行）は許容範囲内だが、CLIに `--clean-only` オプション追加を提案するのが理想的
+- Plan には「再実行は処理が重複するが、現状のCLI仕様上の制約」と明記すべき
+
+---
+
+### 3. `Edit` ツール追加のリスク評価
+
+**問題**: allowed-tools に `Edit` を追加することの副作用。
+
+**リスク分析**:
+- ✅ コンフリクトマーカー除去に必要（`sed` は壊れやすい）
+- ⚠️ 他のファイルも編集可能になる（スコープが広がる）
+- ⚠️ 誤ってsync対象外のファイルを編集するリスク
+
+**推奨対策**:
+- Step 5-2.e で「必ずコンフリクトファイルのみを編集すること」を明記
+- 編集対象ファイルパスの検証（sync 対象ファイル一覧に含まれるか確認）
+- 編集後の `Grep` 検証で意図しない変更がないかチェック
+
+**判断**: 追加は妥当だが、安全ガードを強化すべき。
+
+---
+
+### 4. エッジケースの見落とし
+
+| ケース | Plan での対応 | 推奨追加 |
+|--------|-------------|---------|
+| コンフリクトが0件 | 5-1 で「コンフリクトなし → スキップ」 | ✅ 記載あり |
+| 孤児が0件 | 記載なし | ⚠️ C-1 に「空なら skip」を追加すべき |
+| direnv未インストール | D-2 で「なければ skip」 | ✅ 記載あり |
+| `.envrc` が変更されない | D-1 で「変更されたか確認」 | ✅ 記載あり |
+| 複数のコンフリクトマーカーが1ファイルに存在 | 5-2.e 「末尾から処理し行番号ずれ防止」 | ✅ 記載あり |
+| ユーザーが「スキップ」を選択した場合の後続処理 | 5-3 で「スキップされたファイルがあれば一覧を再表示」 | ✅ 記載あり |
+| JSON出力が不正な場合 | 記載なし | ⚠️ JSONパースエラー時のフォールバック処理を追加すべき |
+
+---
+
+### 5. allowed-toolsの不足
+
+**問題**: コンフリクト解消で `Read` を使用するのに、`allowed-tools` に `Read` が含まれていない（現状は `Bash, AskUserQuestion` のみ）。
+
+**推奨修正**:
+```diff
+-allowed-tools: Bash, AskUserQuestion
++allowed-tools: Bash, AskUserQuestion, Read, Edit, Grep, Glob
+```
+
+理由:
+- `Read`: コンフリクトファイルの内容読み込み（5-2.a）
+- `Edit`: マーカー除去（5-2.e）
+- `Grep`: 未解消マーカー検証（5-3）
+- `Glob`: ファイル検索（必要に応じて）
+
+---
+
+### 6. create-einja-app の検出・処理
+
+**問題**: create-einja-app は JSON出力に対応していない。Plan では「標準出力から「コンフリクト」行をパース」とあるが、実装の詳細が不足。
+
+**推奨追加**:
+- Step 4 で create-einja-app の標準出力フォーマットを明記
+- 正規表現パターン例: `⚠️.*コンフリクト.*: (.+)`
+- パース失敗時の処理（エラーメッセージ表示 + 手動解消を促す）
+
+---
+
+### 7. 孤児ファイル削除の確認UIの重複
+
+**問題**: C-3 で AskUserQuestion、C-4 で `--clean --yes` による自動削除。ユーザー確認が二重になる可能性。
+
+**推奨修正**:
+- C-3 の確認で「はい」を選択した場合、C-4 では `--yes` を付けて自動実行
+- C-3 の確認で「いいえ」を選択した場合、C-4 をスキップ
+
+現状の記述では「確認 → 再度 --yes で実行」となり、確認の意味がない。
+
+---
+
+### 8. Step 構成の番号ずれ
+
+**問題**: 改修後の Step 構成で Step 6, 7 が新規追加されたが、元の Step 6 (結果サマリー) が Step 8 に、Step 7 (結果詳細) が Step 9 に移動。
+
+**影響**: 現行の `.claude/commands/einja/einja-sync.md` との対応が不明確。
+
+**推奨**: 対応表を追加:
+
+| 現行 | 改修後 | 内容 |
+|------|--------|------|
+| Step 1 | Step 1 | CLI検出 |
+| Step 2 | Step 2 | カテゴリ選択 |
+| Step 3 | Step 3 | dry-run |
+| Step 4 | Step 4 | sync実行 |
+| Step 5 | Step 5 | コンフリクト解消 |
+| - | **Step 6** | **孤児ファイル処理（新規）** |
+| - | **Step 7** | **direnv allow（新規）** |
+| Step 6 | Step 8 | 結果サマリー |
+| Step 7 | Step 9 | 結果詳細 |
+
+---
+
+## 推奨される修正事項（優先順位順）
+
+### 🔴 必須（実装前に修正すべき）
+
+1. **Step 1 の `npx --yes` 削除**: 検出時はインストールしない方式に変更
+2. **allowed-tools に `Read, Edit, Grep, Glob` 追加**
+3. **C-3 と C-4 の確認UIの整理**: 二重確認を回避
+4. **JSON出力パースエラー時のフォールバック処理追加**
+
+### 🟡 推奨（実装時に考慮すべき）
+
+5. **孤児削除の再実行リスクを Plan に明記**: 「処理が重複するが、現状のCLI仕様上の制約」
+6. **create-einja-app の出力パースパターンを明記**
+7. **Step 構成の対応表を追加**: 現行との差分を明確化
+8. **エッジケース（孤児0件）の明示**: C-1 に追記
+
+### 🟢 改善（あると望ましい）
+
+9. **CLI に `--clean-only` オプション追加を提案**: 孤児削除専用処理
+10. **Edit 使用時の安全ガード強化**: 編集対象ファイルの検証ロジック
+
+---
+
+## 総合評価
+
+**実現可能性**: ⭐⭐⭐⭐☆ (4/5)
+- 技術的には実装可能だが、`npx --yes` の副作用と孤児削除の再実行が懸念
+
+**品質**: ⭐⭐⭐⭐☆ (4/5)
+- conflict-resolver との整合性は高い
+- エッジケース対応は概ね網羅されているが、一部追加が必要
+
+**リスク**: ⭐⭐⭐☆☆ (3/5 - 中程度)
+- `npx --yes` の自動インストール問題（最重要）
+- allowed-tools の不足（実装時にエラーになる可能性）
+- 孤児削除の再実行による処理重複
+
+**推奨アクション**: 上記の🔴必須項目を修正してから実装開始すること。