create-einja-app 0.3.2 → 0.3.3

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 の不足（実装時にエラーになる可能性）
+- 孤児削除の再実行による処理重複
+
+**推奨アクション**: 上記の🔴必須項目を修正してから実装開始すること。

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

@@ -0,0 +1,182 @@
+# Plan: NPMリリースSkill統合
+
+## Context
+
+現在 `dev-cli-release` と `create-einja-app-release` の2つの独立したリリースSkillがあり、パッケージ公開時にどちらのSkillを使うか意識する必要がある。変更があったパッケージを自動検出し、1つのSkillで両方のリリースを処理できるようにする。
+
+## 変更対象ファイル
+
+| # | ファイル | 変更内容 |
+|---|---------|---------|
+| 1 | `.claude/skills/einja-npm-release/SKILL.md` | **新規作成**: 統合リリースSkill |
+| 2 | `.claude/skills/dev-cli-release/SKILL.md` | **削除** |
+| 3 | `.claude/skills/create-einja-app-release/SKILL.md` | **削除** |
+| 4 | `CLAUDE.md` | キーワードトリガーを統合Skillに変更 |
+
+## 統合Skillの設計
+
+### パッケージ定義テーブル
+
+Skill内でパッケージごとの差分を定数テーブルとして定義:
+
+| キー | `@einja/cli` | `create-einja-app` |
+|------|-------------|-------------------|
+| path | `packages/cli` | `packages/create-einja-app` |
+| pnpm filter | `@einja/cli` | `create-einja-app` |
+| workflow | `release-cli.yml` | `release-create-einja-app.yml` |
+| tag prefix | `cli-v` | `create-einja-app-v` |
+| commit scope | `cli` | `create-einja-app` |
+| build/test | build, test, typecheck | build, test, typecheck, lint |
+
+### 処理フロー
+
+#### Step 1: 前提条件の確認
+- `git branch --show-current` → mainブランチ確認
+- `git status --porcelain` → 未コミット変更の確認
+- 未コミット変更がある場合 → AskUserQuestion（コミットしてから/スタッシュ/そのまま）
+
+#### Step 2: 変更パッケージの自動検出
+
+各パッケージについて、最新タグからの差分を検出:
+
+```bash
+# dev-cli: 最新タグ取得
+git tag --list 'cli-v*' --sort=-version:refname | head -1
+
+# create-einja-app: 最新タグ取得
+git tag --list 'create-einja-app-v*' --sort=-version:refname | head -1
+
+# 各パッケージの差分をチェック
+git diff --name-only {latest_tag}..HEAD -- packages/cli/
+git diff --name-only {latest_tag}..HEAD -- packages/create-einja-app/
+```
+
+結果をテーブル表示:
+
+```markdown
+| パッケージ | 現バージョン | 最新タグ | 変更ファイル数 |
+|-----------|------------|---------|-------------|
+| @einja/cli | 0.1.41 | cli-v0.1.41 | 3 |
+| create-einja-app | 0.3.2 | create-einja-app-v0.3.2 | 5 |
+```
+
+#### Step 3: リリース対象の確認
+
+AskUserQuestion で確認:
+
+```yaml
+# 両方に変更がある場合
+question: "どのパッケージをリリースしますか？"
+header: "リリース対象"
+options:
+  - label: "両方リリース（推奨）"
+    description: "@einja/cli (変更N件) と create-einja-app (変更M件) の両方をリリース"
+  - label: "@einja/cli のみ"
+    description: "@einja/cli のみリリース"
+  - label: "create-einja-app のみ"
+    description: "create-einja-app のみリリース"
+
+# 片方のみ変更がある場合
+question: "{パッケージ名} に変更があります。リリースしますか？"
+header: "リリース確認"
+options:
+  - label: "はい"
+  - label: "いいえ"
+
+# 変更がない場合でもリリースできるように「Other」選択肢で対応
+```
+
+#### Step 4: バージョン種別の決定
+
+対象パッケージごとにAskUserQuestion:
+
+```yaml
+question: "{パッケージ名} のバージョン種別を選択してください（現在: v{current}）"
+header: "バージョン"
+options:
+  - label: "patch（推奨）"
+  - label: "minor"
+  - label: "major"
+```
+
+複数パッケージの場合、1つの AskUserQuestion で同時に聞けないので順番に確認。
+
+#### Step 5: ビルド・テスト
+
+対象パッケージごとに実行（並列実行可能）:
+
+```bash
+# dev-cli
+pnpm --filter @einja/cli build && pnpm --filter @einja/cli test && pnpm --filter @einja/cli typecheck
+
+# create-einja-app
+pnpm -F create-einja-app build && pnpm -F create-einja-app test && pnpm -F create-einja-app typecheck && pnpm -F create-einja-app lint
+```
+
+#### Step 6: バージョン更新・コミット・プッシュ
+
+**順次実行**（gitコミットは直列化が必要）。全パッケージ統一で `--no-git-tag-version` + 手動タグ方式:
+
+```bash
+# 1. バージョン更新（タグなし）
+npm version {type} --no-git-tag-version --prefix {path}
+
+# 2. package.jsonのみコミット
+git add {path}/package.json
+git commit -m "chore({scope}): v{version}にバージョンアップ"
+
+# 3. タグ作成
+git tag {tag_prefix}{version}
+```
+
+全パッケージ分のコミット・タグ作成が完了してから一括プッシュ:
+
+```bash
+git push origin main
+git push origin {tag1}
+git push origin {tag2}  # 2パッケージの場合
+```
+
+#### Step 7: GitHub Actions 監視
+
+対象パッケージごとにワークフローを監視（並列監視可能）:
+
+```bash
+gh run list --workflow={workflow} --limit=1 --json databaseId,status,conclusion
+```
+
+- 30秒間隔でポーリング
+- 失敗時: `gh run view {run_id} --log-failed` で原因特定 → 自律修正 → 再リリース
+- 最大3回リトライ
+
+#### Step 8: 完了報告
+
+```markdown
+## 📦 NPM パッケージリリース完了
+
+| パッケージ | バージョン | タグ | Actions |
+|-----------|----------|-----|---------|
+| @einja/cli | 0.1.41 → 0.1.42 | cli-v0.1.42 | ✅ |
+| create-einja-app | 0.3.2 → 0.3.3 | create-einja-app-v0.3.3 | ✅ |
+```
+
+## CLAUDE.md キーワードトリガー変更
+
+変更前:
+```
+| `einja cli` `@einja/dev-cli` `公開` `リリース` `publish` `release` | `.claude/skills/dev-cli-release/SKILL.md` |
+| `create-einja-app` | `.claude/skills/create-einja-app-release/SKILL.md` |
+```
+
+変更後:
+```
+| `einja cli` `@einja/dev-cli` `create-einja-app` `公開` `リリース` `publish` `release` | `.claude/skills/einja-npm-release/SKILL.md` |
+```
+
+**注**: `create-einja-app` キーワードはリリース以外の文脈（例: sync）でも使われるが、統合Skillは変更検出で自動判別するため問題ない。
+
+## 検証方法
+
+1. `git diff --stat` で変更ファイルが4つ（新規1、削除2、編集1）であることを確認
+2. Skill内のパッケージ定義テーブルが正しいことを確認
+3. `Grep` で旧Skill名（`dev-cli-release`, `create-einja-app-release`）が残っていないことを確認

package/templates/default/docs/plans/zesty-roaming-steele.md

@@ -0,0 +1,74 @@
+# NPMリリース後の反映遅延修正
+
+## Context
+
+NPMリリース後、利用者が`npx create-einja-app`や`npx @einja/dev-cli`を実行しても古いバージョンが使われ続ける問題。根本原因は**npxのキャッシュ仕様**（npm 7以降、`@latest`未指定だとキャッシュ内の古いバージョンを無期限に使い続ける）。
+
+## 修正箇所
+
+### 1. npx呼び出しに`@latest`追加 + エラーメッセージ更新
+
+**`packages/create-einja-app/src/generators/post-setup.ts`**
+
+| 行 | Before | After |
+|----|--------|-------|
+| 119 | `execa("npx", ["@einja/dev-cli", ...])` | `execa("npx", ["--yes", "@einja/dev-cli@latest", ...])` |
+| 123 | `'npx @einja/dev-cli init'` | `'npx --yes @einja/dev-cli@latest init'` |
+
+**`package.json`（ルート・scriptsセクション）**
+
+| キー | Before | After |
+|------|--------|-------|
+| `einja:sync` | `npx --yes @einja/dev-cli sync` | `npx --yes @einja/dev-cli@latest sync` |
+| `task:loop` | `npx @einja/dev-cli task:loop` | `npx --yes @einja/dev-cli@latest task:loop` |
+
+### 2. テスト期待値の更新
+
+**`packages/create-einja-app/tests/unit/generators/post-setup.test.ts`（134行目）**
+- `["@einja/dev-cli", ...]` → `["--yes", "@einja/dev-cli@latest", ...]` に更新
+
+**`packages/create-einja-app/tests/integration/create.test.ts`（21行目）**
+- `args?.[0] === "@einja/dev-cli"` → `args?.[1] === "@einja/dev-cli@latest"` に更新（`--yes`が先頭に入るため）
+
+### 3. release-cli.ymlにtest/typecheck/lint追加
+
+**`.github/workflows/release-cli.yml`** - Buildステップ後に追加:
+```yaml
+- name: Run tests
+  run: pnpm --filter @einja/dev-cli test
+
+- name: Type check
+  run: pnpm --filter @einja/dev-cli typecheck
+
+- name: Lint
+  run: pnpm --filter @einja/dev-cli lint
+```
+参考: `.github/workflows/release-create-einja-app.yml` に同等のステップあり
+
+### 4. パッケージ名の誤記修正
+
+**`packages/cli/RELEASING.md`（50, 53行目）**
+- `@einja/cli` → `@einja/dev-cli`
+
+**`.claude/skills/einja-npm-release/SKILL.md`（25, 28, 137, 232行目）**
+- `@einja/cli` → `@einja/dev-cli` に統一
+
+### 5. フォローアップ（別リポジトリ）
+
+**`docs/einja/cli/preset.yaml`（127-128行目）** - 管理対象ディレクトリ（読み取り専用）
+- `npx @einja/dev-cli sync` → `npx --yes @einja/dev-cli@latest sync` 等
+- **CLIソース側（eenchowリポジトリ）で修正し、`einja sync`で反映する必要あり**
+- 本PR完了後にCLI側Issueとして起票
+
+## Skill-first評価
+
+- npxコマンドの引数修正 + CI設定追加 + 誤記修正という**1回限りの修正**
+- 再現パターンではないためSkill化不要
+
+## 検証方法
+
+1. `pnpm prepush` でlint/typecheck/testが通ることを確認
+2. `grep -r "@einja/dev-cli@latest" packages/create-einja-app/src/` で`@latest`が含まれることを確認
+3. `grep "@einja/cli[^/]" .claude/skills/einja-npm-release/SKILL.md packages/cli/RELEASING.md` で旧名が残っていないことを確認
+4. `release-cli.yml` にtest/typecheck/lintステップが存在することを確認
+5. `git diff --stat` で意図しない変更がないことを確認

package/templates/default/gitignore

@@ -1,7 +1,10 @@
 # See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
 
 # Python
-**/__pycache__
+**/__pycache__/
+
+# auto-generated files
+**/__generated__/
 
 # dependencies
 **/node_modules
@@ -42,7 +45,8 @@ log/*.pid
 .env.personal
 .env.keys
 .env.local.tmp
-.env.local.bak
+.env.*.bak
+.env.keys.bak
 
 # dotenvx - 以下は追跡する（暗号化済み）
 # .env.example（テンプレート）

package/templates/default/package.json

@@ -45,10 +45,14 @@
     "env:encrypt": "dotenvx encrypt",
     "env:show": "tsx scripts/env-show.ts",
     "env:rotate-secrets": "tsx scripts/env-rotate-secrets.ts",
-    "einja:sync": "npx @einja/dev-cli sync",
-    "task:loop": "npx @einja/dev-cli task:loop"
+    "einja:sync": "npx --yes @einja/dev-cli@latest sync",
+    "init:github": "tsx scripts/init-github.ts",
+    "task:loop": "npx --yes @einja/dev-cli@latest task:loop",
+    "changeset": "changeset"
   },
   "devDependencies": {
+    "@changesets/changelog-github": "^0.5.1",
+    "@changesets/cli": "^2.29.0",
     "@clack/prompts": "^0.11.0",
     "@dotenvx/dotenvx": "^1.51.4",
     "@types/node": "^25.0.3",