create-einja-app 0.3.2 → 0.3.3

package/templates/default/docs/plans/composed-doodling-mountain.md

@@ -0,0 +1,362 @@
+# GitHub Actions リリースワークフロー + 承認フロー設計
+
+## Context
+
+現在、main/staging/developへのpushで自動Vercelデプロイが走るが、GitHub Release作成・承認フローがない。リリースの可視性と本番デプロイの安全性を向上させるため、以下を導入する：
+
+- staging マージ → GitHub **PreRelease** 自動作成
+- main マージ → GitHub **Release** 自動作成
+- production デプロイに **承認ゲート**（Environment Protection）
+
+## 設計方針
+
+| 項目 | 決定 |
+|------|------|
+| リリース順序 | PRマージ → 自動リリース作成 |
+| 昇格フロー | staging → main 直接マージPR |
+| バージョニング | changesets（Turborepo公式推奨） |
+| 承認フロー | GitHub Environments + Required Reviewer 1名（productionのみ） |
+
+## 全体フロー
+
+```
+feature/* → staging PR（changeset含む）
+  ↓ マージ
+[staging] → CI + Migrate + Deploy（承認不要）
+          → PreRelease自動作成（v0.2.0-rc.42）
+            ※ changeset未消費（タグ作成のみ）
+
+staging → main PR（昇格）
+  ↓ マージ
+[main] → CI + ⚠️承認待ち → Migrate + Deploy
+       → changeset version（バージョン確定）→ Release自動作成（v0.2.0）
+```
+
+## Codexレビュー反映事項
+
+| # | 問題 | 修正内容 |
+|---|------|---------|
+| C-1 | stagingでchangeset消費すると main で残らない | `changeset version` はmainのみ。stagingはRCタグ作成のみ（未消費） |
+| C-2 | `workflow_run` はdefault branch制約がある | release処理を `deploy-stable-branches.yml` 内ジョブに統合（独立ワークフロー廃止） |
+| C-3 | `--previous-tag` は存在しないCLIオプション | `--notes-start-tag` に修正 |
+| C-4 | 承認前にDBマイグレーションが走る | migrate + deploy 両方にproduction environment適用 |
+| H-1 | `ci`ジョブのみの無限ループ防止は不十分 | `GITHUB_TOKEN` はデフォルトでワークフロー再起動しない特性を活用。ワークフロー全体ガード追加 |
+| H-2 | `permissions: contents: write` 未定義 | 明示追加 |
+| H-3 | `environment: ''` の動作が不確実 | ジョブ分割で解消（develop/staging/production別ジョブ） |
+| H-4 | ブランチ保護との衝突リスク | version bumpはmainのみ。GITHUB_TOKEN使用（bot名義でprotection bypass可能な設定前提） |
+
+## 実装ステップ
+
+### Phase 1: changesets基盤導入
+
+**変更ファイル:**
+- `package.json` — `@changesets/cli`, `@changesets/changelog-github` をdevDependenciesに追加。scriptsに `"changeset": "changeset"` 追加
+- `.changeset/config.json` — 新規作成
+
+```json
+{
+  "$schema": "https://unpkg.com/@changesets/config@3.0.0/schema.json",
+  "changelog": ["@changesets/changelog-github", { "repo": "einja-inc/einja-management-template" }],
+  "commit": false,
+  "fixed": [],
+  "linked": [],
+  "access": "restricted",
+  "baseBranch": "main",
+  "updateInternalDependencies": "patch",
+  "ignore": ["@einja/dev-cli", "create-einja-app"]
+}
+```
+
+**リスク:** なし。既存フローに影響しない
+
+### Phase 2: GitHub Environments設定（手動・GitHub UI）
+
+| Environment | Required Reviewers | Wait Timer | Deployment Branches |
+|------------|-------------------|------------|-------------------|
+| `staging` | なし | なし | `staging`のみ |
+| `production` | 1名 | なし | `main`のみ |
+
+**リスク:** なし。ワークフローに`environment`参照がないため、設定だけでは動作変更なし
+
+### Phase 3: `deploy-stable-branches.yml` 大規模改修
+
+**変更概要:** デプロイジョブをブランチ別に分割 + リリース作成ジョブを統合
+
+**改修前の構造:**
+```
+ci → changes → migrate → deploy（全ブランチ共通）
+```
+
+**改修後の構造:**
+```
+ci → changes → (ブランチ別分岐)
+  ├─ [develop]  → deploy-develop（環境なし）
+  ├─ [staging]  → deploy-staging（staging環境）→ release-staging（PreRelease作成）
+  └─ [main]     → migrate-production（production環境・承認待ち）→ deploy-production → release-production（Release作成）
+```
+
+**主要な変更点:**
+
+#### 3-1. ワークフロー全体ガード（無限ループ防止）
+```yaml
+on:
+  push:
+    branches: [main, develop, staging]
+
+# GITHUB_TOKENで作成されたイベントはデフォルトでワークフロー再起動しない
+# 念のため明示的にbotコミットを除外
+jobs:
+  ci:
+    # github-actions[bot] のバージョンバンプコミットはスキップ
+    if: "!contains(github.event.head_commit.message, 'chore: release v')"
+```
+
+#### 3-2. デプロイジョブをブランチ別に分割
+```yaml
+  # develop: 環境なし、承認なし
+  deploy-develop:
+    needs: [ci, changes]
+    if: github.ref_name == 'develop' && needs.changes.outputs.deploy_matrix != '[]'
+    runs-on: ubuntu-latest
+    strategy: ...
+    steps: ... # 既存のdeployステップをそのまま
+
+  # staging: staging環境、承認なし
+  deploy-staging:
+    needs: [ci, migrate, changes]
+    if: github.ref_name == 'staging' && ...
+    environment: staging
+    runs-on: ubuntu-latest
+    strategy: ...
+    steps: ... # 既存のdeployステップをそのまま
+
+  # main: production環境、1名承認 → migrate → deploy
+  migrate-production:
+    needs: ci
+    if: github.ref_name == 'main'
+    environment: production  # ← ここで承認待ち（migrate前にブロック）
+    runs-on: ubuntu-latest
+    steps: ... # 既存のmigrateステップ
+
+  deploy-production:
+    needs: [migrate-production, changes]
+    if: github.ref_name == 'main' && needs.changes.outputs.deploy_matrix != '[]'
+    runs-on: ubuntu-latest
+    strategy: ...
+    steps: ... # 既存のdeployステップ
+```
+
+#### 3-3. リリース作成ジョブを統合（release-app.yml廃止）
+```yaml
+  permissions:
+    contents: write  # タグ作成・Release作成に必要
+
+  # staging: PreRelease作成（changeset未消費）
+  release-staging:
+    needs: deploy-staging
+    if: github.ref_name == 'staging'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - name: Check for changesets
+        id: check
+        run: |
+          COUNT=$(ls .changeset/*.md 2>/dev/null | grep -cv README.md || echo 0)
+          echo "has_changesets=$([[ $COUNT -gt 0 ]] && echo true || echo false)" >> $GITHUB_OUTPUT
+      - name: Create PreRelease tag
+        if: steps.check.outputs.has_changesets == 'true'
+        id: tag
+        run: |
+          VERSION=$(node -p "require('./package.json').version")
+          TAG="v${VERSION}-rc.${{ github.run_number }}"
+          git tag "$TAG"
+          git push origin "$TAG"
+          echo "tag=$TAG" >> $GITHUB_OUTPUT
+      - name: Create GitHub PreRelease
+        if: steps.tag.outputs.tag
+        run: |
+          PREV=$(git tag --list 'v*-rc.*' --sort=-v:refname | grep -v "${{ steps.tag.outputs.tag }}" | head -1)
+          OPTS="--prerelease --target staging --generate-notes"
+          [[ -n "$PREV" ]] && OPTS="$OPTS --notes-start-tag $PREV"
+          gh release create "${{ steps.tag.outputs.tag }}" --title "Pre-release ${{ steps.tag.outputs.tag }}" $OPTS
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+  # main: changeset消費 + Release作成
+  release-production:
+    needs: deploy-production
+    if: github.ref_name == 'main'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - name: Setup
+        uses: ./.github/actions/setup
+      - name: Check for changesets
+        id: check
+        run: |
+          COUNT=$(ls .changeset/*.md 2>/dev/null | grep -cv README.md || echo 0)
+          echo "has_changesets=$([[ $COUNT -gt 0 ]] && echo true || echo false)" >> $GITHUB_OUTPUT
+      - name: Version packages
+        if: steps.check.outputs.has_changesets == 'true'
+        run: npx changeset version
+      - name: Commit version bump and create Release
+        if: steps.check.outputs.has_changesets == 'true'
+        id: release
+        run: |
+          VERSION=$(node -p "require('./package.json').version")
+          TAG="v${VERSION}"
+          git config user.name "github-actions[bot]"
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+          git add -A
+          git commit -m "chore: release ${TAG}" || echo "No changes"
+          git tag "$TAG"
+          git push origin main --follow-tags
+          PREV=$(git tag --list 'v*' --sort=-v:refname | grep -v 'rc' | grep -v "$TAG" | head -1)
+          OPTS="--target main --generate-notes"
+          [[ -n "$PREV" ]] && OPTS="$OPTS --notes-start-tag $PREV"
+          gh release create "$TAG" --title "Release ${TAG}" $OPTS
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+```
+
+**無限ループ防止の多重防御:**
+1. `GITHUB_TOKEN` で作成されたpushイベントはデフォルトでワークフローを再トリガーしない
+2. コミットメッセージ `chore: release v` でのフィルタリング
+3. バージョンバンプコミットは `github-actions[bot]` 名義
+
+**リスク:** 高。ジョブ分割により既存ワークフローの構造が大きく変わる。段階的にテストが必要
+
+### Phase 4: `.github/release.yml` リリースノート設定
+
+```yaml
+changelog:
+  exclude:
+    labels: ["dependencies", "skip-changelog"]
+  categories:
+    - title: "New Features"
+      labels: ["enhancement", "feature"]
+    - title: "Bug Fixes"
+      labels: ["bug", "fix"]
+    - title: "Other Changes"
+      labels: ["*"]
+```
+
+### Phase 5: `changeset-status.yml` 新規作成（任意）
+
+PR上にchangesetの有無を表示するワークフロー。開発体験向上目的。
+
+### Phase 6: einja-create-pr Skill新規作成
+
+**新規ファイル:** `.claude/skills/einja-create-pr/SKILL.md`
+
+**責務:** PR作成時にchangeset自動生成 + ラベル付与 + PR作成を一括実行
+
+**処理フロー（5ステップ）:**
+
+1. **差分分析**: `git log --format="%s%n%b" origin/{base}..HEAD` + `git diff --name-only origin/{base}..HEAD`
+2. **changeset生成判定**:
+   - スキップ条件: staging→main昇格PR、apps/配下に変更なし（docs/CI/設定のみ）、既にchangesetファイルがある
+   - 変更種別推定: コミットメッセージプレフィックスの最大値（feat+fix→minor, feat!→major）
+   - パッケージ判定: ファイルパスから（apps/web/** → @repo/web等）
+3. **changeset生成**: `.changeset/{ランダム名}.md` を作成 → コミット
+4. **ラベル判定**: PRタイトルプレフィックスから単一ラベル選択（enhancement/bug/maintenance）
+5. **PR作成**: `gh pr create --title ... --body ... --label ...`
+
+**動作モード:**
+| モード | トリガー | changeset確認 | ラベル確認 |
+|--------|---------|--------------|-----------|
+| 自動 | task-exec/issue-exec経由 | 推定値で自動決定 | 自動 |
+| 対話 | 手動 `/einja-create-pr` | AskUserQuestionで確認 | AskUserQuestionで確認 |
+
+**既存ワークフローへの統合:**
+- `issue-exec.md` のManagerのPR作成部分を `/einja-create-pr` 呼び出しに変更
+- `task-exec.md` は変更不要（現状PR作成は含まない）
+
+**ラベル判定ルール（単一ラベル、優先度順）:**
+```
+feat!/BREAKING → breaking-change
+feat:          → enhancement
+fix:           → bug
+その他         → maintenance
+```
+
+### Phase 7: 既存ドキュメントへの追記
+
+**`docs/einja/steering/infrastructure/deployment.md`** — 以下のセクションを追記:
+- 「8. リリース管理」: GitHub Release/PreRelease自動作成フロー
+- 「9. バージョニング戦略」: changesets採番ルール、タグ形式
+- 「10. 承認フロー」: GitHub Environments設定、production承認ゲート
+- ワークフロー一覧テーブルに release-staging/release-production ジョブを追加
+
+**`docs/einja/steering/development-workflow.md`** — 以下を追記:
+- changesetの運用フロー（PRにchangeset含める手順）
+- 「Phase A: 仕様書作成」→「Phase B: タスク実行」→「Phase C: リリース」の流れ
+
+## バージョニング採番ルール
+
+### セマンティックバージョニング（changeset指定）
+
+| 変更種別 | changeset指定 | バージョン変更例 | 使用シーン |
+|---------|--------------|----------------|----------|
+| 破壊的変更 | `major` | `0.1.0` → `1.0.0` | API仕様変更、DB破壊的マイグレーション |
+| 新機能追加 | `minor` | `0.1.0` → `0.2.0` | 新画面、新API追加 |
+| バグ修正 | `patch` | `0.1.0` → `0.1.1` | 不具合修正、パフォーマンス改善 |
+
+### タグ形式
+
+| 環境 | タグ形式 | 例 | GitHub Release種別 |
+|------|---------|-----|------------------|
+| staging | `v{version}-rc.{run_number}` | `v0.2.0-rc.42` | PreRelease |
+| production | `v{version}` | `v0.2.0` | Release |
+
+### changeset消費タイミング
+
+| ブランチ | changeset消費 | バージョンバンプ | タグ形式 |
+|---------|-------------|----------------|---------|
+| staging | **消費しない** | なし（package.json据え置き） | `v{current}-rc.{run_number}` |
+| main | `changeset version` で消費 | package.json更新 | `v{new_version}` |
+
+## 変更ファイル一覧
+
+| ファイル | 操作 | Phase |
+|---------|------|-------|
+| `package.json` | 改修（devDeps + scripts追加） | 1 |
+| `.changeset/config.json` | 新規 | 1 |
+| `.github/workflows/deploy-stable-branches.yml` | 大規模改修（ジョブ分割 + リリース統合） | 3 |
+| `.github/release.yml` | 新規 | 4 |
+| `.github/workflows/changeset-status.yml` | 新規（任意） | 5 |
+| `.claude/skills/einja-create-pr/SKILL.md` | 新規（changeset生成 + ラベル付与 + PR作成） | 6 |
+| `.claude/commands/einja/issue-exec.md` | 改修（PR作成部分をeinja-create-pr呼び出しに変更） | 6 |
+| `docs/einja/steering/infrastructure/deployment.md` | 追記（リリース管理・バージョニング・承認フロー） | 7 |
+| `docs/einja/steering/development-workflow.md` | 追記（changeset運用フロー） | 7 |
+
+**変更しないファイル:**
+- `release-cli.yml` / `release-create-einja-app.yml`（NPMリリースは独立運用を維持）
+- `deploy-pr-preview.yml` / `cleanup-*.yml` / `claude.yml`
+- Composite Actions（`setup`, `ci`, `migrate`, `neon-export-env`）
+
+**廃止:**
+- `release-app.yml` は作成しない（deploy-stable-branches.yml内に統合）
+
+## NPMリリースとの棲み分け
+
+| タグパターン | 用途 | 生成元 |
+|-------------|------|--------|
+| `v1.2.0` | アプリ Stable Release | deploy-stable-branches.yml内 release-production ジョブ |
+| `v1.2.0-rc.42` | アプリ PreRelease | deploy-stable-branches.yml内 release-staging ジョブ |
+| `cli-v0.1.41` | @einja/dev-cli | 手動タグ（既存運用） |
+| `create-einja-app-v0.3.2` | create-einja-app | 手動タグ（既存運用） |
+
+## 検証方法
+
+1. **Phase 1検証**: `pnpm changeset` で対話UIが起動し、`.changeset/` にmdファイルが生成されること
+2. **Phase 3検証**:
+   - developブランチにpush → deploy-developが承認なしで実行（従来通り）
+   - stagingブランチにpush → deploy-stagingが承認なしで実行 → release-stagingでPreRelease作成
+   - mainブランチにpush → migrate-productionがGitHub UIで承認待ち → 承認後migrate+deploy → release-productionでRelease作成
+   - バージョンバンプコミットでワークフローが再トリガーされない（無限ループなし）ことを確認
+3. **Phase 6検証**: `/einja-create-pr` でchangeset生成 + ラベル付与 + PR作成が一括実行されること

package/templates/default/docs/plans/dazzling-foraging-cascade.md

@@ -0,0 +1,32 @@
+# Plan: docs-updater Agent を薄いラッパーに簡素化
+
+## Context
+
+`docs-updater` Agent（`.claude/agents/einja/docs/docs-updater.md`）と `update-docs-by-task-specs` Command（`.claude/commands/einja/update-docs-by-task-specs.md`）が機能的にほぼ完全に重複している。Agent側は自ら「`update-docs-by-task-specs` コマンドのロジックに従って処理を実行します」と記載しているが、ステップ1〜6（33〜151行）でコマンドのロジックを丸コピーしている。
+
+docs-updater は task-exec の Phase 99 から Agent ツールで呼ばれるサブエージェントであり、メインコンテキストの肥大化を防ぐ役割がある。Agent定義は残しつつ、ロジックの重複を解消する。
+
+## 変更内容
+
+### 1. docs-updater.md の簡素化
+
+- **対象**: `.claude/agents/einja/docs/docs-updater.md`
+- ステップ1〜6のロジック詳細（33〜151行）を削除
+- 「`.claude/commands/einja/update-docs-by-task-specs.md` を Read して指示に従う」という委託形式に書き換え
+- frontmatter（name, description, model, color）、入力形式、実行制約は維持
+
+### 2. spec-tasks-generator.md の記述確認
+
+- **対象**: `.claude/agents/einja/specs/spec-tasks-generator.md` (264行目、274行目付近)
+- 「docs-updater エージェント」の記述はそのまま維持（docs-updater を残すため変更不要）
+
+## 対象ファイル一覧
+
+| ファイル | 操作 |
+|---------|------|
+| `.claude/agents/einja/docs/docs-updater.md` | 簡素化（ロジック重複部分を委託形式に書き換え） |
+
+## 検証
+
+- 簡素化後の docs-updater.md が正しくコマンドを参照していることを Read で確認
+- `git diff --stat` で意図しない変更がないことを確認

package/templates/default/docs/plans/enchanted-wiggling-ember-agent-a5befd57d0ca4c7c7.md

@@ -0,0 +1,177 @@
+# レビューレポート: enchanted-wiggling-ember.md
+
+レビュー実施日: 2026-03-05
+
+---
+
+## 前回指摘事項の反映確認
+
+| 指摘番号 | 内容 | 反映状況 |
+|---------|------|---------|
+| 1 | 命名の一貫性: `issue-spec-requirements-generator` → 短縮名 | 反映済み（requirements-generator.md 等） |
+| 2 | sync-cursor-commands の更新が必要 | TG-2.3 に追加済み |
+| 3 | エージェント名の長さ: ディレクトリ名でスコープ担保 | 反映済み（issue-specs/ + 短縮ファイル名） |
+| 4 | task-exec リネーム不要 | そのまま維持（妥当） |
+
+前回指摘 4 点はすべて反映されている。
+
+---
+
+## 新たに発見された問題
+
+### 重大（見落とすと壊れる）
+
+#### [CRITICAL-1] copy-presets.mjs の Skill 固定列挙に新Skillが含まれていない
+
+**実態**: `packages/cli/scripts/copy-presets.mjs` の Skill コピーは固定列挙（ハードコード）。
+現在の列挙に含まれているのは以下のみ：
+- einja-conflict-resolver
+- einja-general-context-loader
+- einja-output-format
+- einja-spec-context-loader
+- einja-project-overview
+- einja-skill-creator
+- einja-task-commit
+- einja-task-qa
+
+**問題**: 新規作成される以下の Skill が列挙に入っていないため、ビルド（`pnpm build`）しても `presets/default/` にコピーされない：
+- `einja-issue-spec-create`（新規）
+- `einja-task-exec`（新規）
+- `einja-issue-spec-generator`（リネーム後）
+- `einja-issue-spec-validator`（リネーム後）
+
+また、`einja-task-spec-generator` と `einja-task-spec-validator` の **削除エントリ** も必要。
+
+**対処**: Phase 2 の TG として「`copy-presets.mjs` への新 Skill 追加 + 旧 Skill 削除」を追加する必要がある。
+
+#### [CRITICAL-2] issue-exec.md の更新箇所が「2箇所」では足りない
+
+**実態**: `issue-exec.md` の `/einja:task-exec` 参照は **少なくとも3箇所**：
+- 103行目: 代替手段の説明
+- 206行目: Worker 起動手順の説明
+- 394行目: tmux send-keys の実際のコマンド文字列
+
+計画書には「2箇所」と記載されているが、394行目のコマンド文字列が漏れると Worker 起動が壊れる。
+
+**対処**: TG-2.3 の issue-exec.md 更新対象を「全件」に修正すること。
+
+#### [CRITICAL-3] grep 検証パターンに複数の見逃しがある
+
+現在の TG-3.1 grep パターンの欠落：
+
+| 欠落しているチェック | 実際に残存する箇所 |
+|--------------------|------------------|
+| `agents/specs/`（einja/ なしの短縮形） | sync-cursor-commands.md:54 |
+| `.cursor/commands/` 内の旧ファイル残存 | .cursor/commands/update-docs-by-task-specs.md |
+| `README.md` 内の旧コマンド参照 | README.md:60 |
+
+また、誤検知ノイズになる箇所（除外が必要）：
+- `docs/specs/issues/**/qa-tests/` — 履歴エビデンスなので除外推奨
+- `docs/plans/` — 過去計画ファイルなので除外推奨
+- `modifications/` — 作業記録なので除外推奨
+
+**対処**: TG-3.1 の grep コマンドを修正し、除外パターンに `docs/specs/` `docs/plans/` `modifications/` `packages/create-einja-app/templates/default/docs/plans/` を追加する。また、`agents/specs/` と `.cursor/commands/` のチェックを追加する。
+
+---
+
+### 中リスク（計画漏れ）
+
+#### [MEDIUM-1] README.md の更新が計画に含まれていない
+
+**実態**: `README.md` 60行目に以下の記述がある：
+```
+`.claude/commands/` - `/einja:spec-create`, `/einja:task-exec` などのスラッシュコマンド
+```
+
+TG-2.5 は CLAUDE.md のみで、README.md が含まれていない。
+
+**対処**: TG-2.5 に README.md を追加する（Skill/コマンドテーブルの記述を更新）。
+
+#### [MEDIUM-2] sync-cursor-commands.md のパス例示が現実と不一致
+
+**実態**: `sync-cursor-commands.md` 54行目：
+```
+spec-requirements-generator → .claude/agents/specs/spec-requirements-generator.md
+```
+実際のパスは `.claude/agents/einja/specs/` だが、例示では `agents/specs/` と短縮されている。
+リネーム後は `.claude/agents/einja/issue-specs/requirements-generator.md` になる。
+
+TG-2.3 で「エージェントパス agents/specs/ → agents/issue-specs/」と記載されているが、
+このパターンで置換すると `agents/einja/specs/` を持つパスには一致しない可能性がある。
+
+**対処**: TG-2.3 の sync-cursor-commands.md 更新で、具体的にどの文字列を何に置換するかを明示すること。
+
+#### [MEDIUM-3] .cursor/commands/update-docs-by-task-specs.md の旧ファイル削除が計画されていない
+
+**実態**: `.cursor/commands/update-docs-by-task-specs.md` が存在する。
+`sync-cursor-commands` コマンド再実行で `update-docs-by-issue-specs/RULE.md` が生成されるはずだが、
+旧ファイルの **削除** は自動では行われない（スクリプトが削除しない設計の可能性がある）。
+
+**対処**: TG-3.2（ビルド・テスト）の手順に「`.cursor/commands/` 内の旧ファイル手動削除確認」を追加する。
+
+#### [MEDIUM-4] einja-task-spec-generator/SKILL.md と einja-task-spec-validator/SKILL.md のリンクパス変更が2段階になっている
+
+**実態**:
+- `einja-task-spec-generator/SKILL.md`:101行目 → `../../agents/einja/specs/spec-tasks-generator.md`
+- `einja-task-spec-validator/SKILL.md`:126行目 → `../../agents/einja/specs/spec-tasks-validator.md`
+
+リネーム後（einja-issue-spec-generator/SKILL.md）ではリンクパスを：
+1. ディレクトリ: `specs/` → `issue-specs/`
+2. ファイル名: `spec-tasks-generator.md` → `tasks-generator.md`
+
+の **両方** を変更する必要がある。TG-2.2 の記述では「エージェント名更新」とのみ書かれており、
+パスの `specs/` → `issue-specs/` の変更が明記されていない。
+
+**対処**: TG-2.2 の更新内容に「相対パス内の `specs/` → `issue-specs/` 変更」を明記する。
+
+---
+
+### 更新不要と判断できるもの
+
+| 対象 | 判断 | 理由 |
+|-----|------|------|
+| `docs/specs/issues/**/qa-tests/` 内の旧語 | 更新不要 | 履歴エビデンスなので変更すると証跡が変わる |
+| `docs/plans/` 内の過去計画書の旧語 | 更新不要 | 作業記録。ただし grep 検証からは除外すること |
+| `modifications/` 内の旧語 | 更新不要 | 作業記録 |
+| テストファイル内の旧パス（テストデータ文字列） | 更新不要 | 単なるサンプルデータとして使用。実ファイルパスを参照していない |
+| `packages/cli/presets/default/` 配下 | ビルド後に自動反映 | copy-presets.mjs で上書きされる（ただし Skill の固定列挙更新は必要） |
+
+---
+
+## TG-2.2 の行数確認（Skill ファイル数の計算）
+
+計画書で「TG-2.2: スキル内部参照更新（8ファイル）」とあるが、実際にリストされているのは9行：
+
+1. einja-issue-spec-generator/SKILL.md
+2. einja-issue-spec-validator/SKILL.md
+3. einja-task-qa/SKILL.md
+4. einja-task-qa/references/troubleshooting.md
+5. einja-task-qa/references/usage-patterns.md
+6. einja-task-commit/SKILL.md
+7. einja-general-context-loader/SKILL.md
+8. einja-spec-context-loader/SKILL.md
+9. einja-skill-first/SKILL.md
+
+ヘッダーは「8ファイル」だが実際は9ファイル。minor な誤りだが修正推奨。
+
+---
+
+## 総合評価
+
+### 反映状況
+前回指摘 4 点: 全反映済み。
+
+### 新たなリスク
+- **重大**: 3件（CRITICAL-1〜3）
+- **中リスク**: 4件（MEDIUM-1〜4）
+
+### 最小修正が必要な計画変更
+
+1. **新規 TG を追加**: `copy-presets.mjs` の Skill 固定列挙更新（CRITICAL-1）
+2. **TG-2.3 修正**: issue-exec.md の更新箇所を「全件（少なくとも3箇所）」に修正（CRITICAL-2）
+3. **TG-3.1 修正**: grep パターンに `agents/specs/` チェック追加、`.cursor/commands/` チェック追加、除外パターンに `docs/specs/` `docs/plans/` `modifications/` を追加（CRITICAL-3）
+4. **TG-2.5 修正**: README.md を追加（MEDIUM-1）
+5. **TG-2.3 修正**: sync-cursor-commands.md の置換文字列を具体的に明示（MEDIUM-2）
+6. **TG-3.2 修正**: .cursor/commands/ 旧ファイル削除確認を追加（MEDIUM-3）
+7. **TG-2.2 修正**: 相対パス内の `specs/` → `issue-specs/` 変更を明記（MEDIUM-4）
+8. **ヘッダー修正**: TG-2.2 の「8ファイル」→「9ファイル」（minor）