@einja/dev-cli 0.1.19 → 0.1.21

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/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

@@ -30,6 +30,7 @@
 | 変数名 | 説明 | 用途 | GitHub Actions | Vercel |
 |--------|------|------|:--------------:|:------:|
 | `DOTENV_PRIVATE_KEY_CI` | CI環境用復号鍵 | CI/CD | ◯ | - |
+| `DOTENV_PRIVATE_KEY_PREVIEW` | Preview環境用復号鍵 | Previewビルド | ◯ | - |
 | `DOTENV_PRIVATE_KEY_PRODUCTION` | 本番環境用復号鍵 | ビルド | ◯ | ◯ |
 | `TURBO_TOKEN` | Turborepo Remote Cacheトークン | ビルド高速化 | ◯ | - |
 | `TURBO_TEAM` | VercelチームID | ビルド高速化 | ◯ | - |
@@ -38,9 +39,9 @@
 
 | 変数名 | 説明 | 用途 | GitHub Actions | Vercel |
 |--------|------|------|:--------------:|:------:|
-| `VERCEL_TOKEN` | Vercelデプロイトークン | 手動デプロイ | ◯ | - |
-| `VERCEL_ORG_ID` | Vercel組織ID | 手動デプロイ | ◯ | - |
-| `VERCEL_WEB_PROJECT_ID` | webプロジェクトID | 手動デプロイ | ◯ | - |
+| `VERCEL_TOKEN` | Vercelデプロイトークン | Vercel CLIデプロイ | `.env.ci` に格納 | - |
+| `VERCEL_ORG_ID` | Vercel組織ID | Vercel CLIデプロイ | `.env.ci` に格納 | - |
+| `VERCEL_PROJECT_ID_WEB` | webプロジェクトID | Vercel CLIデプロイ | `.env.ci` に格納 | - |
 | `RAILWAY_TOKEN` | Railway APIトークン | Railwayデプロイ | ◯ | - |
 | `RAILWAY_SERVICE_ID` | RailwayサービスID | Railwayデプロイ | ◯ | - |
 
@@ -62,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
@@ -126,6 +167,32 @@ vercel
 vercel --prod
 ```
 
+### GitHub Actions での Vercel CLI デプロイ
+
+GitHub Actions では `.env.ci` に Vercel CLI の認証情報を保持します。
+
+```bash
+# .env.ci に追加（dotenvxで暗号化されます）
+VERCEL_TOKEN=xxxxxxxxxxxxxxxxxxxx
+VERCEL_ORG_ID=team_xxxxxxxxxxxxx
+VERCEL_PROJECT_ID_WEB=prj_xxxxxxxxxxxxx
+```
+
+#### 取得方法
+
+```bash
+# VERCEL_TOKEN: Vercel Dashboard > Account Settings > Tokens > Create Token
+# VERCEL_ORG_ID: Vercel Dashboard > Team Settings > General > Team ID
+# VERCEL_PROJECT_ID_WEB: Vercel Dashboard > Project Settings > General > Project ID
+```
+
+`.env.ci` を更新する場合は以下を使用してください：
+
+```bash
+pnpm env:update
+# → 「環境設定を変更」→「CI環境」
+```
+
 ---
 
 ## 4. Turborepo Remote Cache設定
@@ -248,15 +315,16 @@ 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"
 
 # オプション（手動デプロイ用）
 gh secret set VERCEL_TOKEN --body "取得したトークン"
 gh secret set VERCEL_ORG_ID --body "team_xxxxxxxxx"
-gh secret set VERCEL_WEB_PROJECT_ID --body "prj_xxxxxxxxx"
+gh secret set VERCEL_PROJECT_ID_WEB --body "prj_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,8 +246,9 @@ 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
 # DOTENV_PRIVATE_KEY_CI=4165a821b257a073b2b0a4b4e180b86accc76eec773ec53c6443626615c7d979
 ```
@@ -268,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: 環境変数ファイルを暗号化"
 ```
 
@@ -329,6 +318,9 @@ git push
 # CI用秘密鍵を登録
 gh secret set DOTENV_PRIVATE_KEY_CI --body "$(grep DOTENV_PRIVATE_KEY_CI .env.keys | cut -d= -f2)"
 
+# Preview用秘密鍵を登録（Preview環境を使う場合）
+gh secret set DOTENV_PRIVATE_KEY_PREVIEW --body "$(grep DOTENV_PRIVATE_KEY_PREVIEW .env.keys | cut -d= -f2)"
+
 # 本番用秘密鍵を登録（必要に応じて）
 gh secret set DOTENV_PRIVATE_KEY_PRODUCTION --body "$(grep DOTENV_PRIVATE_KEY_PRODUCTION .env.keys | cut -d= -f2)"
 ```

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 -->
 
 ---

package/scaffolds/instructions/task-vibe-kanban-loop.md

@@ -15,7 +15,7 @@ GitHub Issue からタスクを自動選定し、Vibe-Kanban に登録して連
 
 ```bash
 # 1. 仕様書を作成（requirements.md, design.md, GitHub Issue へのタスク記述）
-/spec-create <タスク内容の説明>
+/einja:spec-create <タスク内容の説明>
 
 # 一旦ここまで終わったらDiscordでスレッドを作りチームにレビュー依頼
 
@@ -444,11 +444,11 @@ sequenceDiagram
 
 ---
 
-## `/task-exec` との使い分け
+## `/einja:task-exec` との使い分け
 
 | コマンド | 用途 | 品質保証 | 推奨シーン |
 |---------|------|---------|----------|
-| **`/task-exec`** | 重要タスクの確実な完了 | ✅ 合格まで自動ループ | 複雑な実装、品質重視 |
+| **`/einja:task-exec`** | 重要タスクの確実な完了 | ✅ 合格まで自動ループ | 複雑な実装、品質重視 |
 | **`pnpm task:loop`** | 大量タスクの自動消化 | 並列実行・監視 | 定型作業、並行開発 |
 
 ---
@@ -479,9 +479,9 @@ packages/cli/src/commands/task-loop/
 
 ## 関連ドキュメント
 
-- [タスク実行ワークフロー](./task-execute.md)
+- [タスク実行ワークフロー](./einja:task-execute.md)
 - [タスク管理ガイドライン](../steering/task-management.md)
-- [仕様書作成ワークフロー](./spec-create.md)
+- [仕様書作成ワークフロー](./einja:spec-create.md)
 - [ブランチ運用戦略](../steering/branch-strategy.md) - ブランチ命名規則、同期フロー、ワークフロー図
 <!-- @einja:managed:end -->
 

package/scaffolds/steering/acceptance-criteria-and-qa-guide.md

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