@einja/dev-cli 0.1.20 → 0.1.23

package/presets/default/.claude/agents/einja/task/task-executer.md

@@ -3,6 +3,14 @@ name: task-executer
 description: タスクグループの実装を実行する専用エージェント。task-execコマンド内から呼び出され、要件定義・設計書に基づいた高品質な実装を行います。
 model: sonnet
 color: blue
+skills:
+  - spec-context-loader
+  - general-context-loader
+  - api-development
+  - frontend-development
+  - backend-architecture
+  - coding-standards
+  - component-design
 ---
 
 あなたはシニアソフトウェアエンジニアで、クリーンアーキテクチャ、TDD、ドメイン駆動設計に精通した実装のエキスパートです。Google、Amazon、Microsoftでの大規模システム開発経験があり、保守性の高いコードを書くことに定評があります。
@@ -45,7 +53,7 @@ color: blue
 spec が不完全です。以下のファイルが不足しています:
 - [不足ファイル一覧]
 
-`/spec-create [タスク内容]` を実行して spec を完成させてください。
+`/einja:spec-create [タスク内容]` を実行して spec を完成させてください。
 ```
 
 #### 1.1 既存実装の分析
@@ -97,19 +105,19 @@ Skill: general-context-loader
 
 **重要**: general-context-loader が AskUserQuestion で確認を行った場合、その回答を要件として扱います。
 
-#### 1.3 実装種別に応じたSkill読み込み
+#### 1.3 実装種別に応じたSkill参照
 
-**⚠️ 必須**: 実装を開始する前に、該当するSkillを読み込むこと。
+実装種別に応じて、以下のSkill（自動注入済み）を参照すること:
 
-| 実装種別 | 読み込むSkill |
-|---------|--------------|
-| **API実装** | `.claude/skills/einja-api-development/SKILL.md` |
-| **フロントエンド実装** | `.claude/skills/einja-frontend-development/SKILL.md` |
-| **バックエンド実装** | `.claude/skills/einja-backend-architecture/SKILL.md` |
-| **コード全般** | `.claude/skills/einja-coding-standards/SKILL.md` |
-| **コンポーネント設計** | `.claude/skills/einja-component-design/SKILL.md` |
+| 実装種別 | 参照Skill |
+|---------|----------|
+| **API実装** | api-development |
+| **フロントエンド実装** | frontend-development |
+| **バックエンド実装** | backend-architecture |
+| **コード全般** | coding-standards |
+| **コンポーネント設計** | component-design |
 
-**詳細規約が必要な場合**:
+**詳細規約が必要な場合**（Readツールで読み込み）:
 - 命名規則: `.claude/skills/einja-coding-standards/reference/naming-conventions.md`
 - 禁止パターン: `.claude/skills/einja-coding-standards/reference/prohibited-patterns.md`
 - TypeScript規約: `.claude/skills/einja-coding-standards/reference/typescript-rules.md`

package/presets/default/.claude/commands/einja/spec-create.md

@@ -32,7 +32,7 @@ TodoWriteツールを使用して全体の進捗を可視化し、ユーザー
 
 ### 0. 前提確認フェーズ（ワークフロー開始時）
 
-**⚠️ 重要**: 仕様書作成開始前に、以下の2つの質問で前提を確認すること。
+**⚠️ 重要**: 仕様書作成開始前に、以下の3つの質問で前提を確認すること。
 
 #### 0.1 TDD適用判定
 
@@ -86,6 +86,28 @@ AskUserQuestion:
 3. **エラー時**: エラーの場合、ユーザーにどう見せたい？
 4. **暗黙の期待**: 「当たり前」だと思っていることは？
 
+#### 0.3 IssueBranchBaseの選択
+
+**質問3: Issueブランチの作成元を確認**
+
+```yaml
+AskUserQuestion:
+  question: "Issueブランチ（issue/{issue番号}）の作成元（IssueBranchBase）を選択してください"
+  header: "IssueBranchBase選択"
+  options:
+    - label: "デフォルトブランチ（推奨）"
+      description: "gitのデフォルトブランチ（main/developなど）を使用します"
+    - label: "main"
+      description: "mainブランチをIssueBranchBaseとして使用します"
+    - label: "develop"
+      description: "developブランチをIssueBranchBaseとして使用します"
+    - label: "その他（ブランチ名を入力）"
+      description: "例: release/2025-01"
+```
+
+**「その他」選択時の対応**:
+- ブランチ名をユーザーに確認し、IssueBranchBaseとして記録する
+
 ### 1. 外部リソースの確認
 
 **AsanaタスクURL**の場合：
@@ -108,6 +130,12 @@ AskUserQuestion:
    - パス指定あり → 指定ディレクトリを使用
    - パス指定なし → `/docs/specs/issues/{機能カテゴリ名}/issue{issue番号}-{機能名}/` で自動作成
 
+3. **Issueブランチ作成（MCP + ローカル）**
+   - `mcp__github__create_branch` を使用
+   - branch: `issue/{issue番号}`（例: `issue/42`）
+   - from_branch: IssueBranchBase（0.3で選択）
+   - ローカルでも `issue/{issue番号}` にチェックアウトして作業を開始
+
 ### 3. 段階的仕様書作成
 **重要**: 各段階で必ずユーザー承認を得て、コミット＆プッシュしてから次へ進行すること。
 
@@ -119,8 +147,8 @@ AskUserQuestion:
    - 作成したファイルのパスと概要を提示
    - 確認ポイントを明示（要件の過不足、受け入れ基準の明確性など）
 3. **ユーザー承認後、コミット＆プッシュ**
-   - コミットメッセージ: `docs: add requirements for {feature-name}`
-   - ブランチは現在のブランチにプッシュ
+   - コミットメッセージ: `docs: {機能名}の要件を追加`
+   - ブランチは `issue/{issue番号}` にプッシュ
    - 他のメンバーがレビューできるようにする
 4. **承認を得てから次のステップ（design.md）に進む**
 
@@ -133,8 +161,8 @@ AskUserQuestion:
    - 作成したファイルのパスと概要を提示
    - 確認ポイントを明示（アーキテクチャの妥当性、実装方針など）
 3. **ユーザー承認後、コミット＆プッシュ**
-   - コミットメッセージ: `docs: add design for {feature-name}`
-   - ブランチは現在のブランチにプッシュ
+   - コミットメッセージ: `docs: {機能名}の設計を追加`
+   - ブランチは `issue/{issue番号}` にプッシュ
 4. **承認を得てから次のステップ（QAテスト仕様生成）に進む**
 
 #### Phase 3: QAテスト仕様生成（シナリオテスト含む）
@@ -147,33 +175,76 @@ AskUserQuestion:
    - 作成したqa-tests/ディレクトリの構成と概要を提示
    - 確認ポイントを明示（シナリオテストの網羅性、実施タイミングの妥当性など）
 3. **ユーザー承認後、コミット＆プッシュ**
-   - コミットメッセージ: `docs: add qa-test specs for {feature-name}`
-   - ブランチは現在のブランチにプッシュ
+   - コミットメッセージ: `docs: {機能名}のQAテスト仕様を追加`
+   - ブランチは `issue/{issue番号}` にプッシュ
 4. **承認を得てから次のステップ（GitHub Issueへのタスク記述）に進む**
 
 #### Phase 4: GitHub Issueへのタスク記述
-1. spec-tasks-generatorエージェントで作成
+
+##### 4.1 タスク生成・検証ループ
+
+**重要**: タスク生成後は自動的にフォーマット検証を行い、違反があれば差し戻します。
+
+```
+【タスク生成・検証ループ】（最大3回）
+  │
+  ├─ spec-tasks-generator 呼び出し
+  │   └─ タスク一覧を生成（またはエラーフィードバックを元に修正版を生成）
+  │
+  ├─ spec-tasks-validator 呼び出し
+  │   └─ フォーマット検証
+  │
+  └─ 検証結果判定
+      ├─ SUCCESS → ループ終了、ユーザー確認へ
+      └─ FAILURE → spec-tasks-generator に差し戻し
+                   └─ エラーレポート付きで再呼び出し
+                   └─ ループ再開（最大3回）
+
+  ※ 3回失敗 → ユーザーに手動修正を依頼
+```
+
+1. **spec-tasks-generatorエージェントでタスク生成**
    - エージェント内で実装の影響範囲を分析
    - 実装タスクの分解と依存関係
    - requirements.md、design.md、**qa-tests/scenarios.md**の内容を参照
    - 各タスクに**シナリオテスト実施タイミング**を明記
    - **GitHub Issueの説明文にタスク一覧を記述**
-2. **ユーザーに内容確認を依頼**
+
+2. **spec-tasks-validatorエージェントでフォーマット検証**
+   - タスク階層（Phase/タスクグループ/タスク/サブタスク）の形式チェック
+   - メタデータ（要件・依存関係・完了条件・対応設計・シナリオテスト）の必須チェック
+   - 依存関係の書式・参照先の検証
+   - ATDD粒度チェック（Phase数、縦切り/横切り）
+
+3. **検証結果の処理**
+   - **SUCCESS**: ユーザー確認フェーズへ進む
+   - **FAILURE（リトライ可能）**:
+     - エラーレポートを spec-tasks-generator に渡して再生成
+     - ループ再開（現在の試行回数をインクリメント）
+   - **MAX_RETRIES_EXCEEDED（3回失敗）**:
+     - ユーザーに手動修正を依頼
+     - エラー内容を提示し、修正後に続行できるよう案内
+
+##### 4.2 ユーザー確認
+
+4. **ユーザーに内容確認を依頼**
    - 更新したGitHub IssueのURL（#{issue_number}）と概要を提示
    - 確認ポイントを明示（タスク分解の粒度、依存関係の妥当性など）
-3. **ユーザー承認後、以下の処理を実行**
+   - **バリデーション合格済みであることを明記**
+
+5. **ユーザー承認後、以下の処理を実行**
 
-   a. **Issueブランチ作成（MCP）**
+   a. **Issueブランチの存在確認（未作成時のみ作成）**
    - `mcp__github__create_branch` を使用
    - branch: `issue/{issue番号}`（例: `issue/42`）
    - ⚠️ **機能名は含めない**（ディレクトリ名とは異なる。上記「命名規則」参照）
-   - from_branch: デフォルトブランチ（main/masterなど）
+   - from_branch: IssueBranchBase（0.3で選択）
 
    b. **仕様書ファイルをプッシュ（MCP）**
    - `mcp__github__push_files` を使用
    - branch: `issue/{issue番号}`
    - files: requirements.md, design.md, qa-tests/（または分割された各ファイル）
-   - message: `docs: add specs for {feature-name} (Issue #{issue_number})`
+   - message: `docs: {機能名}の仕様書を追加 (Issue #{issue_number})`
 
    c. **PR作成（MCP）**
    - `mcp__github__create_pull_request` を使用
@@ -192,7 +263,7 @@ AskUserQuestion:
      - QAテスト仕様へのリンク（qa-tests/scenarios.md）
      - タスク一覧（Phase別チェックボックス形式、シナリオテスト実施タイミング明記）
 
-4. **全ての仕様書作成が完了したことを報告**
+6. **全ての仕様書作成が完了したことを報告**
    - GitHub Issue URLを明記
    - Spec PR URLを明記
 

package/presets/default/.claude/commands/einja/task-exec.md

@@ -36,8 +36,8 @@ $ARGUMENTSから以下を解析：
 
 | Phase番号 | 判定 | 処理フロー |
 |-----------|------|-----------|
-| 1〜98 | 通常タスク | task-executer → task-reviewer → task-qa → task-committer |
-| 99 | ドキュメント反映タスク | docs-updater → task-committer |
+| 1〜98 | 通常タスク | task-executer → task-reviewer → task-qa → einja-task-commit Skill |
+| 99 | ドキュメント反映タスク | docs-updater → einja-task-commit Skill |
 
 ### 通常タスクのフロー（Phase 1〜98）
 
@@ -52,7 +52,7 @@ $ARGUMENTSから以下を解析：
 │                                                         │
 │  QA合格後 ↓                                             │
 │  ┌─────────────────────────────────────────────┐       │
-│  │ task-committer（コミット・プッシュ）          │       │
+│  │ einja-task-commit Skill（コミット・プッシュ） │       │
 │  │ ※ 確認なしで自動実行                         │       │
 │  └─────────────────────────────────────────────┘       │
 │                                                         │
@@ -84,7 +84,7 @@ $ARGUMENTSから以下を解析：
 │       │                                                 │
 │       ↓ 反映完了                                        │
 │  ┌─────────────────────────────────────────────┐       │
-│  │ task-committer（コミット・プッシュ）          │       │
+│  │ einja-task-commit Skill（コミット・プッシュ） │       │
 │  │ ※ 確認なしで自動実行                         │       │
 │  └─────────────────────────────────────────────┘       │
 │                                                         │
@@ -115,8 +115,8 @@ $ARGUMENTSから以下を解析：
 - テスト失敗 → 実装フェーズに戻る
 - 全テスト合格 → コミット・プッシュフェーズへ
 
-### 4. コミット・プッシュフェーズ（task-committer）
-- QA合格後、自動的にコミット・プッシュを実行
+### 4. コミット・プッシュフェーズ（einja-task-commit Skill）
+- QA合格後、Skill toolで `einja-task-commit` Skillを直接呼び出し
 - 変更がある場合のみ実行（変更なしの場合はスキップ）
 - コミット分割案の確認はスキップ（QA合格済みのため自動適用）
 - 品質チェック（lint/typecheck/test/build）はQAで実行済みのためスキップ
@@ -138,7 +138,7 @@ $ARGUMENTSから以下を解析：
      - 対象タスクspecのパス（全Phaseで完了したタスクspec）
 
 3. **コミット・プッシュ**
-   - docs-updater 完了後、task-committer を呼び出し
+   - docs-updater 完了後、Skill toolで `einja-task-commit` Skillを呼び出し
    - ドキュメント変更をコミット・プッシュ
 
 4. **終了**

package/presets/default/.claude/hooks/einja/biome-format.sh

@@ -18,10 +18,10 @@ if [[ "$file_path" =~ \.(ts|tsx|js|jsx|json)$ ]]; then
   cd "$CLAUDE_PROJECT_DIR" 2>/dev/null || exit 0
 
   # biome check（format + lint）を実行、自動修正可能なものは修正
-  npx biome check --write "$file_path" 2>/dev/null || true
+  pnpm exec biome check --write "$file_path" 2>/dev/null || true
 
   # 修正後に残っているlintエラーをチェック（any型など自動修正できないもの）
-  lint_errors=$(npx biome lint "$file_path" 2>&1 | grep -E "lint/|noExplicitAny|error" | head -20)
+  lint_errors=$(pnpm exec biome lint "$file_path" 2>&1 | grep -E "lint/|noExplicitAny|error" | head -20)
 
   if [ -n "$lint_errors" ]; then
     echo "" >&2

package/presets/default/.claude/skills/einja-general-context-loader/SKILL.md

@@ -203,7 +203,7 @@ interface Example {
 
 ### 推奨アクション
 1. ユーザーに追加情報を求める
-2. または `/spec-create` で仕様書を作成する
+2. または `/einja:spec-create` で仕様書を作成する
 ```
 
 ---

package/presets/default/.claude/skills/einja-spec-context-loader/SKILL.md

@@ -145,7 +145,7 @@ interface Example {
 
 ### エラー内容
 - **原因**: [不足ファイル一覧 or エラー詳細]
-- **推奨アクション**: `/spec-create` を実行して仕様書を完成させてください
+- **推奨アクション**: `/einja:spec-create` を実行して仕様書を完成させてください
 ```
 
 ---
@@ -155,9 +155,9 @@ interface Example {
 | エラー種別 | 原因 | 対処 |
 |-----------|------|------|
 | spec ディレクトリ不在 | 指定パスが存在しない | パスを確認して再実行 |
-| requirements.md 不在 | Phase 1 未完了 | `/spec-create` で Phase 1 を実行 |
-| design.md 不在 | Phase 2 未完了 | `/spec-create` で Phase 2 を実行 |
-| qa-tests/ 不在 | Phase 3 未完了 | `/spec-create` で Phase 3 を実行 |
+| requirements.md 不在 | Phase 1 未完了 | `/einja:spec-create` で Phase 1 を実行 |
+| design.md 不在 | Phase 2 未完了 | `/einja:spec-create` で Phase 2 を実行 |
+| qa-tests/ 不在 | Phase 3 未完了 | `/einja:spec-create` で Phase 3 を実行 |
 
 ---
 

package/scaffolds/instructions/deployment-setup.md

@@ -63,14 +63,54 @@
 # 4. [YOUR-PASSWORD] を設定したパスワードに置換
 ```
 
-### Neon
+### Neon（Preview環境DBブランチ自動作成対応）
+
+#### プロジェクト作成
 
 ```bash
 # 1. https://neon.tech でアカウント作成
+
 # 2. 「Create a project」でプロジェクト作成
+#    - Region: AWS ap-northeast-1 (Tokyo)
+#    - Postgres version: 16（推奨）
+#    - Project name: einja-management（任意）
+
 # 3. Connection Details > Connection string をコピー
+#    例: postgresql://user:pass@ep-xxx-xxx.ap-northeast-1.aws.neon.tech/main
 ```
 
+#### Neon環境変数の設定
+
+Neonの環境変数は `.env.preview` で管理します。GitHub Secretsへの登録は不要です。
+
+```bash
+# pnpm env:update でNeon環境変数を追加
+pnpm env:update
+
+# 対話式ウィザードで以下を選択：
+# 1. 「環境設定を変更」を選択
+# 2. 「preview環境」を選択
+# 3. NEON_API_KEY と NEON_PROJECT_ID を追加
+
+# NEON_API_KEY: Neon Console > Account Settings > API Keys から取得
+# NEON_PROJECT_ID: Neon Console > Project Settings > General > Project ID から取得
+```
+
+#### ブランチ命名規則
+
+Preview環境用のDBブランチは以下のルールで自動作成されます：
+
+| PRブランチ名 | 作成されるDBブランチ名 | 親ブランチ |
+|------------|---------------------|----------|
+| `feature/user-auth` | `preview/feature-user-auth` | `main` |
+| `fix/login-bug` | `preview/fix-login-bug` | `main` |
+| `feat/dashboard` | `preview/feat-dashboard` | `main` |
+
+**重要**:
+- DBブランチ名はGitブランチ名から自動変換（`/`→`-`、小文字化）
+- プレフィックス `preview/` が自動付与
+- PR作成時に自動作成、PRクローズ時に自動削除
+
 ### Vercel Postgres
 
 ```bash
@@ -275,8 +315,9 @@ gh secret set RAILWAY_SERVICE_ID --body "サービスID"
 # 1. GitHub リポジトリ > Settings > Secrets and variables > Actions
 # 2. 「New repository secret」で以下を追加
 
-# 必須
+# 必須Secrets
 gh secret set DOTENV_PRIVATE_KEY_CI --body "$(grep DOTENV_PRIVATE_KEY_CI .env.keys | cut -d= -f2)"
+gh secret set DOTENV_PRIVATE_KEY_PREVIEW --body "$(grep DOTENV_PRIVATE_KEY_PREVIEW .env.keys | cut -d= -f2)"
 gh secret set TURBO_TOKEN --body "取得したトークン"
 gh secret set TURBO_TEAM --body "team_xxxxxxxxx"
 

package/scaffolds/instructions/environment-setup.md

@@ -136,8 +136,7 @@ dotenvx decrypt -f .env.production
 {
   "scripts": {
     "build": "dotenvx run -f .env.production -- turbo run build",
-    "build:staging": "dotenvx run -f .env.staging -- turbo run build",
-    "build:dev": "dotenvx run -f .env.development -- turbo run build",
+    "build:dev": "dotenvx run -f .env.develop -- turbo run build",
     "build:local": "turbo run build"
   }
 }
@@ -154,8 +153,7 @@ dotenvx decrypt -f .env.production
 ├── .env.example            # .envの参考テンプレート（Git追跡）
 ├── .env.personal.example   # 個人用トークンのテンプレート（Git追跡）
 ├── .env.local              # ローカル開発用（暗号化・Git追跡）★
-├── .env.development        # dev検証サーバー用（暗号化・Git追跡）
-├── .env.staging            # ステージング用（暗号化・Git追跡）
+├── .env.develop            # dev検証サーバー用（暗号化・Git追跡）
 ├── .env.production         # 本番環境用（暗号化・Git追跡）
 ├── .env.ci                 # CI/CD用（暗号化・Git追跡）
 ├── .env.keys               # 秘密鍵（Git除外・1Password等で共有）
@@ -182,7 +180,7 @@ GITHUB_TOKEN=
 
 ```bash
 # 開発サーバー用
-cat > .env.development << 'EOF'
+cat > .env.develop << 'EOF'
 # Development Environment
 DATABASE_URL="postgresql://user:pass@dev-db:5432/einja_dev"
 NEXTAUTH_SECRET="dev-secret-key"
@@ -190,15 +188,6 @@ NEXTAUTH_URL="https://dev.example.com"
 NODE_ENV="development"
 EOF
 
-# ステージング用
-cat > .env.staging << 'EOF'
-# Staging Environment
-DATABASE_URL="postgresql://user:pass@staging-db:5432/einja_staging"
-NEXTAUTH_SECRET="staging-secret-key"
-NEXTAUTH_URL="https://staging.example.com"
-NODE_ENV="staging"
-EOF
-
 # 本番環境用
 cat > .env.production << 'EOF'
 # Production Environment
@@ -226,8 +215,7 @@ EOF
 
 ```bash
 # 各環境ファイルを暗号化
-dotenvx encrypt -f .env.development
-dotenvx encrypt -f .env.staging
+dotenvx encrypt -f .env.develop
 dotenvx encrypt -f .env.production
 dotenvx encrypt -f .env.ci
 ```
@@ -258,7 +246,7 @@ NODE_ENV=encrypted:BDqRRvYcNnJ5rYo4c8Zhu/lThghcW8b6+7u4+M...
 cat .env.keys
 
 # 出力例:
-# DOTENV_PRIVATE_KEY_DEVELOPMENT=8afef18fa6e433593a5116cc406c83a44c4385b3f4f7d4cc25750e39f2baa320
+# DOTENV_PRIVATE_KEY_DEVELOP=8afef18fa6e433593a5116cc406c83a44c4385b3f4f7d4cc25750e39f2baa320
 # DOTENV_PRIVATE_KEY_STAGING=548887285654af264275d8c58e87c82dd7958ac6e99760fb5aa5eca8e1efb35d
 # DOTENV_PRIVATE_KEY_PREVIEW=bdb34e98e0312b3e06d10475901a841d9da69590993416d5e4141fd4d96b62ba
 # DOTENV_PRIVATE_KEY_PRODUCTION=73890d5288241cb6738b7172d5ee1bf2dd4aac8319442d951e31d123304f180d
@@ -269,7 +257,7 @@ cat .env.keys
 
 ```bash
 # 暗号化されたファイルをコミット
-git add .env.development .env.staging .env.production .env.ci
+git add .env.develop .env.production .env.ci
 git commit -m "chore: 環境変数ファイルを暗号化"
 ```
 

package/scaffolds/instructions/task-execute.md

@@ -1,18 +1,18 @@
 <!-- @einja:managed:start -->
 # 開発ワークフロー
 
-このドキュメントでは、`/spec-create`と`/task-exec`コマンドを使用したATDD（受け入れテスト駆動開発）に基づく開発ワークフローについて説明します。
+このドキュメントでは、`/einja:spec-create`と`/einja:task-exec`コマンドを使用したATDD（受け入れテスト駆動開発）に基づく開発ワークフローについて説明します。
 
 ## 概要
 
 開発プロセスは2つの主要なコマンドで構成されています：
 
-1. **`/spec-create`**: 仕様書の作成（要件定義 → 設計 → GitHub Issueへのタスク記述）
-2. **`/task-exec`**: タスクの実行（選定 → 実装 → レビュー → QA → 完了）
+1. **`/einja:spec-create`**: 仕様書の作成（要件定義 → 設計 → GitHub Issueへのタスク記述）
+2. **`/einja:task-exec`**: タスクの実行（選定 → 実装 → レビュー → QA → 完了）
 
 ## 全体フロー図
 
-### フェーズ1: 仕様書作成 (`/spec-create`)
+### フェーズ1: 仕様書作成 (`/einja:spec-create`)
 
 ```mermaid
 graph TD
@@ -47,7 +47,7 @@ graph TD
     style Q fill:#c8e6c9
 ```
 
-### フェーズ2: タスク実行 (`/task-exec`)
+### フェーズ2: タスク実行 (`/einja:task-exec`)
 
 **注記**: 品質保証ループにより、レビュー/QA失敗時は自動的に実装フェーズに戻ります。複数タスク一括実行も可能です。
 
@@ -91,11 +91,11 @@ graph TD
 
 ```mermaid
 graph LR
-    A[/spec-create] --> B[requirements.md]
+    A[/einja:spec-create] --> B[requirements.md]
     A --> C[design.md]
     A --> D[GitHub Issue]
 
-    D --> E[/task-exec]
+    D --> E[/einja:task-exec]
     B --> E
     C --> E
 
@@ -115,7 +115,7 @@ graph LR
 
 ## コマンド詳細
 
-### 1. `/spec-create` コマンド
+### 1. `/einja:spec-create` コマンド
 
 **役割**: プロダクト開発のシニアテクニカルアーキテクト兼シニアプロダクトエンジニアとして、ATDD形式の仕様書を段階的に作成します。
 
@@ -123,13 +123,13 @@ graph LR
 
 ```bash
 # Asanaタスクから仕様書作成
-/spec-create https://app.asana.com/0/project/task-id
+/einja:spec-create https://app.asana.com/0/project/task-id
 
 # 機能説明から仕様書作成
-/spec-create "ユーザー認証機能の実装：マジックリンク認証とセッション管理"
+/einja:spec-create "ユーザー認証機能の実装：マジックリンク認証とセッション管理"
 
 # 既存仕様書を修正
-/spec-create "認証機能の改善" /docs/specs/issues/auth/20250111-auth-magic-link/
+/einja:spec-create "認証機能の改善" /docs/specs/issues/auth/20250111-auth-magic-link/
 ```
 
 #### 処理フロー詳細
@@ -207,7 +207,7 @@ Step 4: GitHub Issueにタスク一覧を記述
 
 ---
 
-### 2. `/task-exec` コマンド
+### 2. `/einja:task-exec` コマンド
 
 **役割**: タスク実行マネージャーとして、タスクの選定から実装、レビュー、QA、完了までの一連のプロセスを管理します。
 
@@ -220,13 +220,13 @@ Step 4: GitHub Issueにタスク一覧を記述
 
 ```bash
 # Issue番号を指定（自動選定）
-/task-exec #123
+/einja:task-exec #123
 
 # 特定のタスクグループを指定
-/task-exec #123 1.1
+/einja:task-exec #123 1.1
 
 # Issue番号のみ（#なし）
-/task-exec 123
+/einja:task-exec 123
 ```
 
 #### 処理フロー詳細
@@ -323,11 +323,11 @@ Step 4: GitHub Issueにタスク一覧を記述
 詳細については、専用ドキュメントを参照してください：
 **📖 [Vibe-Kanban自動実行ガイド](./task-vibe-kanban-loop.md)**
 
-#### `/task-exec`との使い分け
+#### `/einja:task-exec`との使い分け
 
 | コマンド | 用途 | 品質保証 | 推奨シーン |
 |---------|------|---------|----------|
-| **`/task-exec`** | 重要タスクの確実な完了 | ✅ 合格まで自動ループ | 複雑な実装、品質重視 |
+| **`/einja:task-exec`** | 重要タスクの確実な完了 | ✅ 合格まで自動ループ | 複雑な実装、品質重視 |
 | **`pnpm task:loop`** | 大量タスクの自動消化 | ❌ 各タスクは別プロセス | 定型作業、並行開発 |
 
 **詳細な使い分け基準**: [task-vibe-kanban-loop.md](./task-vibe-kanban-loop.md#task-execとの使い分け)
@@ -342,10 +342,10 @@ Step 4: GitHub Issueにタスク一覧を記述
 
 ```bash
 # Asanaタスクから仕様書を作成
-/spec-create https://app.asana.com/0/project/auth-magic-link
+/einja:spec-create https://app.asana.com/0/project/auth-magic-link
 
 # または機能説明から作成
-/spec-create "マジックリンク認証機能：
+/einja:spec-create "マジックリンク認証機能：
   - メールアドレスでログイン
   - ワンタイムトークン生成
   - メール送信
@@ -366,7 +366,7 @@ GitHub Issue #123     ← 実装タスク一覧（Phase 1〜3）
 
 ```bash
 # Phase 1-1: トークン生成APIの実装
-/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: メール送信機能の実装
-/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 のタスクグループを順次実行
-/task-exec #123
-/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: /task-exec実行
+    未着手 --> 着手中_TaskExec: /einja:task-exec実行
     未着手 --> Vibe登録: /task-vibe-kanban-loop実行
 
     着手中_TaskExec --> 実装中: 実装フェーズ
@@ -545,7 +545,7 @@ graph TD
 # 原因: 依存関係が満たされていない
 # 対処: 先行タスクグループを先に完了させる
 
-/task-exec #123 1.1  # 先行タスクグループを指定して実行
+/einja:task-exec #123 1.1  # 先行タスクグループを指定して実行
 ```
 
 #### 2. レビューで差し戻される
@@ -575,8 +575,8 @@ graph TD
 ```mermaid
 sequenceDiagram
     participant User as ユーザー
-    participant SpecCreate as /spec-create
-    participant TaskExec as /task-exec
+    participant SpecCreate as /einja: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. **仕様書作成**: `/spec-create`で要件・設計を作成し、GitHub Issueにタスク一覧を記述
-2. **タスク実行**: `/task-exec`でタスクグループを1つずつ実行
+1. **仕様書作成**: `/einja:spec-create`で要件・設計を作成し、GitHub Issueにタスク一覧を記述
+2. **タスク実行**: `/einja:task-exec`でタスクグループを1つずつ実行
    - task-executerで実装
    - task-reviewerでレビュー
    - task-qaでQA
    - 完了時にタスクグループを完了状態に更新
-3. **繰り返し**: 全タスクグループが完了するまで`/task-exec`を繰り返す
+3. **繰り返し**: 全タスクグループが完了するまで`/einja:task-exec`を繰り返す
 
-開発を始める際は、まず`/spec-create`で仕様書を作成し、その後`/task-exec`でタスクグループを順次実行していきます。
+開発を始める際は、まず`/einja:spec-create`で仕様書を作成し、その後`/einja:task-exec`でタスクグループを順次実行していきます。
 <!-- @einja:managed:end -->
 
 ---