@einja/dev-cli 0.1.41 → 0.1.45

package/presets/default/docs/einja/instructions/task-execute.md

@@ -1,18 +1,18 @@
 <!-- @einja:managed:start -->
 # 開発ワークフロー
 
-このドキュメントでは、`/einja:spec-create`と`/einja:task-exec`コマンドを使用したATDD（受け入れテスト駆動開発）に基づく開発ワークフローについて説明します。
+このドキュメントでは、`einja-issue-spec-create` Skillと`einja-task-exec` Skillを使用したATDD（受け入れテスト駆動開発）に基づく開発ワークフローについて説明します。
 
 ## 概要
 
 開発プロセスは2つの主要なコマンドで構成されています：
 
-1. **`/einja:spec-create`**: 仕様書の作成（要件定義 → 設計 → GitHub Issueへのタスク記述）
-2. **`/einja:task-exec`**: タスクの実行（選定 → 実装 → レビュー → QA → 完了）
+1. **`einja-issue-spec-create` Skill**: 仕様書の作成（要件定義 → 設計 → GitHub Issueへのタスク記述）
+2. **`einja-task-exec` Skill**: タスクの実行（選定 → 実装 → レビュー → QA → 完了）
 
 ## 全体フロー図
 
-### フェーズ1: 仕様書作成 (`/einja:spec-create`)
+### フェーズ1: 仕様書作成 (`einja-issue-spec-create` Skill)
 
 ```mermaid
 graph TD
@@ -27,15 +27,15 @@ graph TD
     E --> H
     G --> H
 
-    H --> I["requirements.md 作成 (spec-requirements-generator)"]
+    H --> I["requirements.md 作成 (requirements-generator)"]
     I --> J["ユーザーストーリー / 受け入れ基準ATDD形式 / 既存コード分析"]
     J --> K{ユーザー承認}
-    K -->|承認| L["design.md 作成 (spec-design-generator)"]
+    K -->|承認| L["design.md 作成 (design-generator)"]
     K -->|修正依頼| I
 
     L --> M["技術アーキテクチャ / データモデル設計 / API仕様"]
     M --> N{ユーザー承認}
-    N -->|承認| O["GitHub Issueにタスク記述 (spec-tasks-generator)"]
+    N -->|承認| O["GitHub Issueにタスク記述 (tasks-generator)"]
     N -->|修正依頼| L
 
     O --> P["実装タスク分解 / 依存関係管理 / 優先順位設定"]
@@ -47,7 +47,7 @@ graph TD
     style Q fill:#c8e6c9
 ```
 
-### フェーズ2: タスク実行 (`/einja:task-exec`)
+### フェーズ2: タスク実行 (`einja-task-exec` Skill)
 
 **注記**: 品質保証ループにより、レビュー/QA失敗時は自動的に実装フェーズに戻ります。複数タスク一括実行も可能です。
 
@@ -59,7 +59,7 @@ graph TD
     C --> LoopStart["⟲ 品質保証ループ開始"]
 
     LoopStart --> D["ステップ1: 実装フェーズ<br/>(task-executer)"]
-    D --> E["requirements.md と design.md を参照"]
+    D --> E["requirements.md, ui-design.pen, design.md を参照"]
     E --> F["SerenaMAP で既存コード分析"]
     F --> G["コード実装・修正<br/>ファイル作成/編集<br/>テストコード追加"]
 
@@ -91,11 +91,11 @@ graph TD
 
 ```mermaid
 graph LR
-    A[/einja:spec-create] --> B[requirements.md]
+    A[einja-issue-spec-create Skill] --> B[requirements.md]
     A --> C[design.md]
     A --> D[GitHub Issue]
 
-    D --> E[/einja:task-exec]
+    D --> E[einja-task-exec Skill]
     B --> E
     C --> E
 
@@ -115,7 +115,7 @@ graph LR
 
 ## コマンド詳細
 
-### 1. `/einja:spec-create` コマンド
+### 1. `einja-issue-spec-create` Skill
 
 **役割**: プロダクト開発のシニアテクニカルアーキテクト兼シニアプロダクトエンジニアとして、ATDD形式の仕様書を段階的に作成します。
 
@@ -123,13 +123,13 @@ graph LR
 
 ```bash
 # Asanaタスクから仕様書作成
-/einja:spec-create https://app.asana.com/0/project/task-id
+einja-issue-spec-create: https://app.asana.com/0/project/task-id
 
 # 機能説明から仕様書作成
-/einja:spec-create "ユーザー認証機能の実装：マジックリンク認証とセッション管理"
+einja-issue-spec-create: "ユーザー認証機能の実装：マジックリンク認証とセッション管理"
 
 # 既存仕様書を修正
-/einja:spec-create "認証機能の改善" /docs/specs/issues/auth/20250111-auth-magic-link/
+einja-issue-spec-create: "認証機能の改善" /docs/specs/issues/auth/20250111-auth-magic-link/
 ```
 
 #### 処理フロー詳細
@@ -150,7 +150,7 @@ Step 1: 外部リソース確認
    └─ /docs/specs/issues/{domain}/{YYYYMMDD}-{domain}-{feature}/
 
 Step 2: requirements.md 作成（要件定義書）
-├─ spec-requirements-generator エージェント起動
+├─ requirements-generator エージェント起動
 ├─ 既存コードベース分析
 ├─ ATDD形式のユーザーストーリー作成
 ├─ 受け入れ基準（Acceptance Criteria）定義
@@ -166,7 +166,7 @@ Step 2: requirements.md 作成（要件定義書）
    - 非機能要件
 
 Step 3: design.md 作成（設計書）
-├─ spec-design-generator エージェント起動
+├─ design-generator エージェント起動
 ├─ 既存アーキテクチャ調査
 ├─ 技術スタック選定（Next.js + Hono + Prisma）
 ├─ データモデル設計
@@ -184,7 +184,7 @@ Step 3: design.md 作成（設計書）
    - エラーハンドリング
 
 Step 4: GitHub Issueにタスク一覧を記述
-├─ spec-tasks-generator エージェント起動
+├─ tasks-generator エージェント起動
 ├─ 実装タスクの洗い出し
 ├─ タスクの分解（Phase別）
 ├─ 依存関係の定義
@@ -195,7 +195,7 @@ Step 4: GitHub Issueにタスク一覧を記述
 │  └─ 修正依頼 → 再作成
 └─ 📄 成果物構成:
    **基本構成**（各ファイル1000行以下）:
-   - requirements.md, design.md
+   - requirements.md, ui-design.pen, design.md
    - GitHub Issueにタスク一覧
 
    **分割構成**（1000行超過時）:
@@ -207,7 +207,7 @@ Step 4: GitHub Issueにタスク一覧を記述
 
 ---
 
-### 2. `/einja:task-exec` コマンド
+### 2. `einja-task-exec` Skill
 
 **役割**: タスク実行マネージャーとして、タスクの選定から実装、レビュー、QA、完了までの一連のプロセスを管理します。
 
@@ -220,13 +220,13 @@ Step 4: GitHub Issueにタスク一覧を記述
 
 ```bash
 # Issue番号を指定（自動選定）
-/einja:task-exec #123
+einja-task-exec: #123
 
 # 特定のタスクグループを指定
-/einja:task-exec #123 1.1
+einja-task-exec: #123 1.1
 
 # Issue番号のみ（#なし）
-/einja:task-exec 123
+einja-task-exec: 123
 ```
 
 #### 処理フロー詳細
@@ -239,7 +239,7 @@ Step 4: GitHub Issueにタスク一覧を記述
 └─────────────────────────────────────────────────────┘
   ↓
   ├─ task-executerサブエージェント起動
-  ├─ requirements.md と design.md を参照
+  ├─ requirements.md, ui-design.pen, design.md を参照
   ├─ SerenaMAP で既存コード分析
   │  ├─ 関連ファイルの検索
   │  ├─ シンボル定義の確認
@@ -323,12 +323,12 @@ Step 4: GitHub Issueにタスク一覧を記述
 詳細については、専用ドキュメントを参照してください：
 **📖 [Issue実行ワークフローガイド](./issue-exec-workflow.md)**
 
-#### `/einja:task-exec`との使い分け
+#### `einja-task-exec` Skillとの使い分け
 
-| コマンド | 用途 | 対象 | 推奨シーン |
+| 実行方法 | 用途 | 対象 | 推奨シーン |
 |---------|------|------|----------|
 | **`/einja:issue-exec`** | Issue全体の並列実行 | 複数Phase・複数タスクグループ | 大規模機能実装 |
-| **`/einja:task-exec`** | 単一タスクグループの確実な完了 | 1つのタスクグループ | 複雑な実装、品質重視 |
+| **`einja-task-exec` Skill** | 単一タスクグループの確実な完了 | 1つのタスクグループ | 複雑な実装、品質重視 |
 
 **詳細な使い分け基準**: [issue-exec-workflow.md](./issue-exec-workflow.md#task-execとの使い分け)
 
@@ -342,10 +342,10 @@ Step 4: GitHub Issueにタスク一覧を記述
 
 ```bash
 # Asanaタスクから仕様書を作成
-/einja:spec-create https://app.asana.com/0/project/auth-magic-link
+einja-issue-spec-create: https://app.asana.com/0/project/auth-magic-link
 
 # または機能説明から作成
-/einja:spec-create "マジックリンク認証機能：
+einja-issue-spec-create: "マジックリンク認証機能：
   - メールアドレスでログイン
   - ワンタイムトークン生成
   - メール送信
@@ -366,7 +366,7 @@ GitHub Issue #123     ← 実装タスク一覧（Phase 1〜3）
 
 ```bash
 # Phase 1-1: トークン生成APIの実装
-/einja:task-exec #123
+einja-task-exec: #123
 
 # 実行内容:
 # 1. task-executer: API実装、バリデーション追加
@@ -379,7 +379,7 @@ GitHub Issue #123     ← 実装タスク一覧（Phase 1〜3）
 
 ```bash
 # Phase 1-2: メール送信機能の実装
-/einja:task-exec #123
+einja-task-exec: #123
 
 # 実行内容:
 # 1. task-executer: メールサービス実装
@@ -392,8 +392,8 @@ GitHub Issue #123     ← 実装タスク一覧（Phase 1〜3）
 
 ```bash
 # Phase 2, Phase 3 のタスクグループを順次実行
-/einja:task-exec #123
-/einja:task-exec #123
+einja-task-exec: #123
+einja-task-exec: #123
 ...
 
 # 最終的にすべてのタスクグループが [x] 完了状態になる
@@ -451,7 +451,7 @@ GitHub Issue #123     ← 実装タスク一覧（Phase 1〜3）
 stateDiagram-v2
     [*] --> 未着手: タスク作成
 
-    未着手 --> 着手中_TaskExec: /einja:task-exec実行
+    未着手 --> 着手中_TaskExec: einja-task-exec Skill実行
     未着手 --> IssueExec開始: /einja:issue-exec実行
 
     着手中_TaskExec --> 実装中: 実装フェーズ
@@ -545,14 +545,14 @@ graph TD
 # 原因: 依存関係が満たされていない
 # 対処: 先行タスクグループを先に完了させる
 
-/einja:task-exec #123 1.1  # 先行タスクグループを指定して実行
+einja-task-exec: #123 1.1  # 先行タスクグループを指定して実行
 ```
 
 #### 2. レビューで差し戻される
 
 ```bash
 # 原因: 要件や設計との不整合
-# 対処: requirements.md と design.md を再確認
+# 対処: requirements.md, ui-design.pen, design.md を再確認
 
 # レビュー結果を確認後、再度実装フェーズから実行される
 # （task-exec内で自動的に実装をやり直します）
@@ -575,8 +575,8 @@ graph TD
 ```mermaid
 sequenceDiagram
     participant User as ユーザー
-    participant SpecCreate as /einja:spec-create
-    participant TaskExec as /einja:task-exec
+    participant SpecCreate as einja-issue-spec-create
+    participant TaskExec as einja-task-exec
     participant Executer as task-executer
     participant Reviewer as task-reviewer
     participant QA as task-qa
@@ -628,15 +628,15 @@ sequenceDiagram
 
 ### 実行の流れ
 
-1. **仕様書作成**: `/einja:spec-create`で要件・設計を作成し、GitHub Issueにタスク一覧を記述
-2. **タスク実行**: `/einja:task-exec`でタスクグループを1つずつ実行
+1. **仕様書作成**: `einja-issue-spec-create` Skillで要件・設計を作成し、GitHub Issueにタスク一覧を記述
+2. **タスク実行**: `einja-task-exec` Skillでタスクグループを1つずつ実行
    - task-executerで実装
    - task-reviewerでレビュー
    - task-qaでQA
    - 完了時にタスクグループを完了状態に更新
-3. **繰り返し**: 全タスクグループが完了するまで`/einja:task-exec`を繰り返す
+3. **繰り返し**: 全タスクグループが完了するまで`einja-task-exec` Skillを繰り返す
 
-開発を始める際は、まず`/einja:spec-create`で仕様書を作成し、その後`/einja:task-exec`でタスクグループを順次実行していきます。
+開発を始める際は、まず`einja-issue-spec-create` Skillで仕様書を作成し、その後`einja-task-exec` Skillでタスクグループを順次実行していきます。
 <!-- @einja:managed:end -->
 
 <!-- @einja:project-private:start id="task-execute-project" -->

package/presets/default/docs/einja/steering/acceptance-criteria-and-qa-guide.md

@@ -110,7 +110,7 @@ ACx.y: <振る舞いの1文要約>
 ```
 
 **シナリオテストの設計タイミング**:
-- `/einja:spec-create` コマンドの QAテスト仕様生成フェーズで作成
+- `einja-issue-spec-create` Skill の QAテスト仕様生成フェーズで作成
 - requirements.md の受け入れ条件を分析し、複数ACをまたぐフローを特定
 - タスク分割前に完了させる
 

package/presets/default/docs/einja/steering/branch-strategy.md

@@ -195,7 +195,7 @@ sequenceDiagram
 **同期の原則**:
 - 先行タスクの PR マージにより Phase ブランチが更新される
 - 後続タスクは更新済み Phase ブランチから派生するため変更を引き継ぐ
-- コンフリクト発生時は conflict-resolver で解消
+- コンフリクト発生時は einja-conflict-resolver Skill で解消
 
 ### 変更の取り込み対象
 

package/presets/default/docs/einja/steering/development-workflow.md

@@ -8,11 +8,11 @@
 本プロジェクトでは、Claude Codeを活用した自動化された開発ワークフローを採用しています。
 
 ```
-仕様書作成（/einja:spec-create）
+仕様書作成（einja-issue-spec-create Skill）
     ↓
 仕様書レビュー（Discord + Spec PR）
     ↓
-タスク実行（/einja:issue-exec or /einja:task-exec）
+タスク実行（/einja:issue-exec or einja-task-exec Skill）
     ↓
 自己レビュー → PR作成（自動）
     ↓
@@ -30,7 +30,7 @@
 │ Phase A: 仕様書作成                                                          │
 ├─────────────────────────────────────────────────────────────────────────────┤
 │                                                                              │
-│  /einja:spec-create <タスク内容の説明またはAsanaタスクURL>                          │
+│  einja-issue-spec-create Skill <タスク内容の説明またはAsanaタスクURL>                │
 │      │                                                                       │
 │      ├── 1. （AsanaURLの場合）Asanaからタスク情報取得                         │
 │      ├── 2. GitHub Issue作成                                                 │
@@ -57,7 +57,7 @@
                             Spec PRをマージ
                                     ↓
 ┌─────────────────────────────────────────────────────────────────────────────┐
-│ Phase B: タスク実行（/einja:issue-exec or /einja:task-exec）                  │
+│ Phase B: タスク実行（/einja:issue-exec or einja-task-exec Skill）                  │
 ├─────────────────────────────────────────────────────────────────────────────┤
 │                                                                              │
 │  /einja:issue-exec #<issue-number>                                          │
@@ -73,7 +73,7 @@
 │           │                                                   │               │
 │           ▼                                                   │               │
 │      ┌─────────────────────────────────────────────────────┐ │               │
-│      │ Worker（/einja:task-exec を実行）                   │ │               │
+│      │ Worker（einja-task-exec Skill を実行）              │ │               │
 │      │                                                      │ │               │
 │      │  task-executer: 実装                                 │ │               │
 │      │       ↓                                              │ │               │
@@ -101,6 +101,22 @@
 │                                                                              │
 │      全 Phase 完了 → 最終 PR 作成（Issue → base ブランチ）                    │
 │                                                                              │
+└─────────────────────────────────────────────────────────────────────────────┘
+                                    ↓
+                     【PRレビュー・マージ → staging / main】
+                                    ↓
+┌─────────────────────────────────────────────────────────────────────────────┐
+│ Phase C: リリース（自動）                                                    │
+├─────────────────────────────────────────────────────────────────────────────┤
+│                                                                              │
+│  staging マージ時:                                                           │
+│      → CI + Deploy（承認不要）                                               │
+│      → PreRelease 自動作成（v0.2.0-rc.42）                                   │
+│                                                                              │
+│  main マージ時（staging → main 昇格PR）:                                     │
+│      → CI + ⚠️承認待ち → Migrate + Deploy                                   │
+│      → changeset version → Release 自動作成（v0.2.0）                        │
+│                                                                              │
 └─────────────────────────────────────────────────────────────────────────────┘
 ```
 
@@ -108,10 +124,12 @@
 
 ## Phase A: 仕様書作成
 
-### コマンド
+### 実行方法
+
+`einja-issue-spec-create` Skillを使用して仕様書を作成します。
 
-```bash
-/einja:spec-create <タスク内容の説明またはAsanaタスクURL>
+```
+タスク内容の説明またはAsanaタスクURL を引数に指定
 ```
 
 ### ステップ詳細
@@ -123,17 +141,19 @@
 | 3        | Claude → **人間承認** | IssueBranchBase選択                   |
 | 4        | Claude                | `issue/{番号}`ブランチ作成            |
 | 5        | Claude → **人間承認** | requirements.md作成 → 確認 → コミット |
-| 6        | Claude → **人間承認** | design.md作成 → 確認 → コミット       |
-| 7        | Claude → **人間承認** | GitHub Issueにタスク一覧記述          |
-| 8        | Claude                | **Spec PR作成**                       |
-| 9        | **人間**              | Discordでチームにレビュー依頼         |
-| 10       | **人間**              | Spec PRレビュー・承認・マージ         |
+| 6        | Claude → **人間承認** | ui-design.pen作成 → 確認 → コミット   |
+| 7        | Claude → **人間承認** | design.md作成 → 確認 → コミット       |
+| 8        | Claude → **人間承認** | GitHub Issueにタスク一覧記述          |
+| 9        | Claude                | **Spec PR作成**                       |
+| 10       | **人間**              | Discordでチームにレビュー依頼         |
+| 11       | **人間**              | Spec PRレビュー・承認・マージ         |
 
 ### 成果物
 
 ```
 docs/specs/issues/{カテゴリ}/issue{番号}-{機能名}/
 ├── requirements.md    # 要件定義書（ATDD形式）
+├── ui-design.pen      # UIモックアップ（Pencil MCP形式）
 └── design.md          # 設計書（技術詳細）
 
 GitHub Issue #{番号}   # タスク一覧（Phase別チェックボックス形式）
@@ -150,7 +170,7 @@ Spec PR                # 仕様書レビュー用
 
 ## Phase B: タスク実行
 
-### コマンド
+### 実行方法
 
 ```bash
 # Issue全体の並列実行（推奨：複数Phase・複数タスクグループの場合）
@@ -161,7 +181,7 @@ Spec PR                # 仕様書レビュー用
 /einja:issue-exec #123 --base develop                  # ベースブランチ指定
 
 # 単一タスクグループ実行（品質重視・複雑な実装向け）
-/einja:task-exec #123 1.1                               # Issue #123 のタスクグループ 1.1 を実行
+# einja-task-exec Skill を使用: Issue #123 のタスクグループ 1.1 を実行
 ```
 
 ### 実行後の流れ（/einja:issue-exec）
@@ -170,18 +190,18 @@ Spec PR                # 仕様書レビュー用
 
 1. **Manager** が Issue をパースし、Phase 毎に Director を tmux で起動
 2. **Director** が Phase 内のタスクグループを依存順に Worker を起動
-3. **Worker** が `/einja:task-exec` を実行（executer → reviewer → qa → commit）
+3. **Worker** が `einja-task-exec` Skill を実行（executer → reviewer → qa → commit）
 4. Worker 完了後、PR が自動作成される
 5. マージモードに応じて PR がマージされ、次のタスクが自動開始
 
 ユーザーは `tmux attach -t einja-{issue番号}` で全プロセスを監視できます。
 
-### `/einja:issue-exec` と `/einja:task-exec` の使い分け
+### `/einja:issue-exec` と `einja-task-exec` Skill の使い分け
 
-| コマンド | 用途 | 対象 | 推奨シーン |
+| 実行方法 | 用途 | 対象 | 推奨シーン |
 |---------|------|------|----------|
 | **`/einja:issue-exec`** | Issue全体の並列実行 | 複数Phase・複数タスクグループ | 大規模機能実装 |
-| **`/einja:task-exec`** | 単一タスクグループの確実な完了 | 1つのタスクグループ | 複雑な実装、品質重視 |
+| **`einja-task-exec` Skill** | 単一タスクグループの確実な完了 | 1つのタスクグループ | 複雑な実装、品質重視 |
 
 ### サブエージェントの役割
 
@@ -227,7 +247,7 @@ Phase 全タスク完了？
 
 | PRの種類    | 作成タイミング       | 内容                       | レビュー観点                                   |
 | ----------- | -------------------- | -------------------------- | ---------------------------------------------- |
-| **Spec PR** | `/einja:spec-create`完了時 | requirements.md, design.md | 要件の妥当性、設計の適切さ、スコープの確認     |
+| **Spec PR** | `einja-issue-spec-create` Skill完了時 | requirements.md, ui-design.pen, design.md | 要件の妥当性、UIデザインの適切さ、設計の適切さ、スコープの確認 |
 | **実装PR**  | タスクグループ完了時（Worker が自動作成） | ソースコード、テスト       | コード品質、設計書との整合性、テストカバレッジ |
 
 ### なぜ2段階でPRを作成するのか
@@ -270,15 +290,17 @@ Phase 全タスク完了？
 
 ### 仕様書作成
 
+`einja-issue-spec-create` Skill を使用します。
+
 ```bash
 # タスク内容の説明から仕様書を作成
-/einja:spec-create <タスク内容の説明>
+<タスク内容の説明>
 
 # AsanaタスクURLから仕様書を作成
-/einja:spec-create <AsanaタスクURL>
+<AsanaタスクURL>
 
 # 既存仕様書のパスを指定して修正
-/einja:spec-create <タスク内容> <既存仕様書パス>
+<タスク内容> <既存仕様書パス>
 ```
 
 ### タスク実行
@@ -291,12 +313,12 @@ Phase 全タスク完了？
 /einja:issue-exec #<issue_number> --merge-mode auto --max-phase 2
 
 # 単一タスクグループ実行（品質重視・複雑な実装向け）
-/einja:task-exec #<issue_number> <task_group_number>
+# einja-task-exec Skill を使用: #<issue_number> <task_group_number>
 
 # 例
 /einja:issue-exec #123                                   # Issue #123 の全タスクを並列実行
 /einja:issue-exec #123 --merge-mode task-group-auto      # タスクPR自動マージ
-/einja:task-exec #123 1.1                                # タスクグループ 1.1 を単発実行
+# einja-task-exec Skill: #123 1.1                        # タスクグループ 1.1 を単発実行
 ```
 
 ---
@@ -310,6 +332,52 @@ Phase 全タスク完了？
 
 ---
 
+## Phase C: リリース
+
+### changeset運用フロー
+
+PRにchangesetを含めることで、バージョン管理とリリースノートが自動化されます。
+
+#### changeset追加手順
+
+```bash
+# 1. changeset対話UIを起動
+pnpm changeset
+
+# 2. 変更対象パッケージを選択（apps/web, apps/admin等）
+# 3. 変更種別を選択（major / minor / patch）
+# 4. 変更サマリーを入力
+# 5. .changeset/ にmdファイルが生成される
+# 6. コミットに含める
+```
+
+#### 自動生成（einja-create-pr Skill）
+
+`/einja-create-pr` またはtask-exec/issue-exec経由でPR作成する場合、changesetは自動生成されます。
+
+#### changesetの要否
+
+| 変更内容 | changeset必要 |
+|---------|:------------:|
+| 新機能追加（apps/配下） | ✅ |
+| バグ修正（apps/配下） | ✅ |
+| ドキュメントのみ | ❌ |
+| CI/CD設定のみ | ❌ |
+| .claude/ 設定のみ | ❌ |
+| packages/（内部パッケージ） | ❌ |
+
+#### changeset消費フロー
+
+```
+feature → staging PR（changeset含む）
+  ↓ マージ
+staging: changeset未消費 → PreRelease（v0.2.0-rc.42）
+  ↓ 昇格PR
+main: changeset version → バージョンバンプ → Release（v0.2.0）
+```
+
+---
+
 ## FAQ
 
 ### Q: Spec PRをマージする前にタスク実行を開始できますか？

package/presets/default/docs/einja/steering/infrastructure/deployment.md

@@ -134,6 +134,7 @@ graph LR
         ReleaseCLI[release-cli.yml]
         ReleaseApp[release-create-einja-app.yml]
         Claude[claude.yml]
+        ChangesetStatus[changeset-status.yml]
     end
 
     subgraph "Composite Actions"
@@ -162,6 +163,7 @@ graph LR
 | **Release CLI** | `release-cli.yml` | tag `cli-v*` / 手動 | @einja/dev-cli をNPM公開 |
 | **Release App** | `release-create-einja-app.yml` | tag `create-einja-app-v*` / 手動 | create-einja-app をNPM公開 |
 | **Claude** | `claude.yml` | @claude メンション | Claude Code実行 |
+| **Changeset Status** | `changeset-status.yml` | PR to main/staging | PR上にchangesetの有無を表示 |
 
 ### Composite Actions（2層構造）
 
@@ -679,6 +681,111 @@ sequenceDiagram
 
 ---
 
+## 8. リリース管理
+
+### GitHub Release / PreRelease 自動作成フロー
+
+```mermaid
+flowchart LR
+    subgraph staging
+        S1[staging push] --> S2[CI + Deploy]
+        S2 --> S3[PreRelease作成<br/>v0.2.0-rc.42]
+    end
+
+    subgraph main
+        M1[main push] --> M2[CI]
+        M2 --> M3[⚠️承認待ち]
+        M3 --> M4[Migrate + Deploy]
+        M4 --> M5[changeset version]
+        M5 --> M6[Release作成<br/>v0.2.0]
+    end
+
+    staging -->|昇格PR| main
+```
+
+| 環境 | リリース種別 | タグ形式 | changeset消費 | 承認 |
+|------|------------|---------|:------------:|:----:|
+| staging | PreRelease | `v{version}-rc.{run_number}` | ❌ | 不要 |
+| production | Release | `v{version}` | ✅ | 1名必要 |
+
+### ワークフロー内リリースジョブ
+
+`deploy-stable-branches.yml` 内に統合:
+
+| ジョブ | トリガー | 処理内容 |
+|--------|---------|---------|
+| `release-staging` | staging デプロイ成功後 | RCタグ作成 → GitHub PreRelease作成 |
+| `release-production` | production デプロイ成功後 | changeset version → バージョンバンプ → タグ作成 → GitHub Release作成 |
+
+### NPMリリースとの棲み分け
+
+| タグパターン | 用途 | 生成元 |
+|-------------|------|--------|
+| `v1.2.0` | アプリ Stable Release | deploy-stable-branches.yml |
+| `v1.2.0-rc.42` | アプリ PreRelease | deploy-stable-branches.yml |
+| `cli-v0.1.41` | @einja/dev-cli | 手動タグ（既存運用） |
+| `create-einja-app-v0.3.2` | create-einja-app | 手動タグ（既存運用） |
+
+---
+
+## 9. バージョニング戦略
+
+### changesets
+
+[changesets](https://github.com/changesets/changesets) を使用してセマンティックバージョニングを管理。
+
+| 変更種別 | 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` | 不具合修正、パフォーマンス改善 |
+
+### changeset消費タイミング
+
+| ブランチ | changeset消費 | バージョンバンプ | タグ形式 |
+|---------|-------------|----------------|---------|
+| staging | **消費しない** | なし（package.json据え置き） | `v{current}-rc.{run_number}` |
+| main | `changeset version` で消費 | package.json更新 | `v{new_version}` |
+
+### 無限ループ防止（多重防御）
+
+1. `GITHUB_TOKEN` で作成されたpushイベントはデフォルトでワークフローを再トリガーしない
+2. コミットメッセージ `chore: release v` でのフィルタリング
+3. バージョンバンプコミットは `github-actions[bot]` 名義
+
+---
+
+## 10. 承認フロー
+
+### GitHub Environments
+
+| Environment | Required Reviewers | Wait Timer | Deployment Branches |
+|------------|-------------------|------------|-------------------|
+| `staging` | なし | なし | `staging`のみ |
+| `production` | 1名 | なし | `main`のみ |
+
+### 承認フロー詳細
+
+```mermaid
+sequenceDiagram
+    participant Dev as 開発者
+    participant GH as GitHub Actions
+    participant Rev as Reviewer
+    participant Prod as Production
+
+    Dev->>GH: main push
+    GH->>GH: CI checks
+    GH->>Rev: ⚠️ 承認リクエスト
+    Note over Rev: GitHub UIで承認
+    Rev->>GH: ✅ 承認
+    GH->>Prod: Migrate + Deploy
+    GH->>GH: Release作成
+```
+
+production環境へのデプロイは `migrate-production` ジョブで承認ゲートを設定。承認後にマイグレーションとデプロイが実行される。
+
+---
+
 ## 関連ドキュメント
 
 - [環境変数設計方針](./environment-variables.md)