@einja/dev-cli 0.1.40 → 0.1.44

package/presets/default/.claude/{commands/einja/task-exec.md → skills/einja-task-exec/SKILL.md}

@@ -1,9 +1,4 @@
----
-description: "GitHub Issueのタスクグループを実行するコマンド。ARGUMENTS: Issue番号（必須、#123形式）とタスクグループ番号（必須、1.1形式）"
-allowed-tools: Task, Read, Write, Edit, MultiEdit, Bash, Grep, Glob, WebFetch, mcp__github__*, mcp__serena__*
----
-
-# タスク実行コマンド
+# タスク実行 Skill
 
 ## 役割
 
@@ -36,7 +31,7 @@ $ARGUMENTSから以下を解析：
 
 | Phase番号 | 判定 | 処理フロー |
 |-----------|------|-----------|
-| 1〜98 | 通常タスク | task-executer → task-reviewer → task-qa → einja-task-commit Skill |
+| 1〜98 | 通常タスク | Issueパース → spec読込 → TaskCreate登録 → 並列実行 → task-reviewer → task-qa → einja-task-commit Skill |
 | 99 | ドキュメント反映タスク | docs-updater → einja-task-commit Skill |
 
 ### 通常タスクのフロー（Phase 1〜98）
@@ -45,10 +40,15 @@ $ARGUMENTSから以下を解析：
 ┌─────────────────────────────────────────────────────────┐
 │                    品質保証ループ                        │
 │                                                         │
-│  task-executer → task-reviewer → task-qa               │
-│       ↑              │              │                   │
-│       └──────────────┴──────────────┘                   │
-│          （MAJOR/テスト失敗時は自動的に戻る）             │
+│  Issueパース → specパス特定 → TaskCreate登録            │
+│       ↓                                                 │
+│  依存関係ベース並列実行:                                │
+│       task-executer × N（独立タスク並列）               │
+│       ↓ 全タスク完了                                    │
+│  task-reviewer → task-qa                                │
+│       ↑              │                                  │
+│       └──────────────┘                                  │
+│          （MAJOR/テスト失敗時は該当タスクのみ再実行）    │
 │                                                         │
 │  QA合格後 ↓                                             │
 │  ┌─────────────────────────────────────────────┐       │
@@ -101,21 +101,104 @@ $ARGUMENTSから以下を解析：
 
 各フェーズ完了後、サブエージェントの出力を表示したら即座に次のフェーズへ進む。ユーザーの応答は待たない。
 
-### 1. 実装フェーズ（task-executer）
-- 要件定義・設計書に基づいた実装を実行
-- 完了後、出力を表示して即座にレビューフェーズへ
+### Step 0: 入力解析
+
+$ARGUMENTSからIssue番号とタスクグループ番号を解析する（現行通り）。
+
+### Step 1: Issueフェッチ + タスク解析
+
+1. `gh issue view {issue番号} --json body,title` でIssue本文を取得
+2. 指定タスクグループ（X.Y）配下のタスク（X.Y.Z）をパース
+3. 各タスクのメタデータを抽出:
+   - タスク名
+   - 要件（Story番号）
+   - 依存関係（なし / X.Y.Z形式）
+   - 完了条件
+   - 対応設計セクション名
+   - シナリオテスト
 
-### 2. レビューフェーズ（task-reviewer）
+### Step 2: spec読み込み + AC抽出
+
+**目的**: task-executerから spec/Issue 読み込み責務を移管し、親が一括で行う。
+
+1. **specディレクトリを探索**: `docs/specs/issues/*/issue{N}-*/` パターンで検索
+2. **存在チェック**:
+   - 完全なspec（requirements.md + design.md + qa-tests/） → 次へ
+   - 部分的spec → エラー終了（`einja-issue-spec-create` Skill の実行を案内）
+   - specなし → `_einja-general-context-loader` Skill を呼び出してコンテキスト収集
+3. **requirements.md を読み込み**、各タスクのメタデータ（`**要件**: Story X`）に基づいてACを抽出
+   - ACはGiven/When/Then形式で小さい（~50-100トークン/AC）ので直接保持
+4. **design.md はパスのみ特定**（内容は読み込まない）
+   - 各タスクの`**対応設計**: design.md「セクション名」`からセクション名を記録
+
+### Step 3: TaskCreate登録
+
+各タスクを `TaskCreate` で登録し、依存関係を設定する。
+
+**TaskCreate の形式**:
+```
+TaskCreate:
+  subject: "X.Y.Z タスク名"
+  description: |
+    ## 受け入れ基準（抽出済み）
+    - AC1.2: Given: ... When: ... Then: ...
+    - AC1.3: Given: ... When: ... Then: ...
+    ## 設計参照
+    {specパス}/design.md → 「セクション名」セクション
+    ## 完了条件
+    （Issueから抽出した完了条件 + ACを満たす）
+    ## 参考（追加情報が必要な場合）
+    - requirements.md: {specパス}/requirements.md
+    - design.md: {specパス}/design.md
+  activeForm: "タスクX.Y.Zを実装中"
+```
+
+**依存関係の設定**:
+- `TaskUpdate` の `addBlockedBy` で依存関係を設定
+- `**依存関係**: X.Y.Z` → 対応するTaskのIDを `addBlockedBy` に設定
+- `**依存関係**: なし` → ブロックなし
+- `**依存関係**: X.Y`（タスクグループ依存） → グループ外依存のため事前に完了済みと想定
+
+**タスク番号→TaskID のマッピングテーブル**を保持し、依存関係解決に使用する。
+
+### Step 4: 依存関係ベース並列実行ループ
+
+```
+while (未完了タスクが存在):
+  1. TaskList で未完了タスクを確認
+  2. blockedBy が空かつ pending のタスクを収集
+  3. 収集したタスクを TaskUpdate で in_progress に設定
+  4. Task ツールで複数の task-executer を並列起動:
+     - 各 task-executer のpromptに以下を含める（ハイブリッド方式）:
+       a. タスクID + タスク名 + 実装指示（Issueから抽出したサブタスク内容）
+       b. AC（受け入れ基準）→ 直接埋め込み（親が抽出済み）
+       c. 設計 → design.mdパス + セクション名（executerが自分でRead）
+       d. 完了条件
+       e. フォールバック用specファイルパス（追加情報が必要な場合）
+     - run_in_background: true で非同期起動（2タスク以上の場合）
+  5. 各エージェントの完了を待機（TaskOutput で結果取得）
+  6. 完了したタスクを TaskUpdate で completed に設定
+  7. ループ先頭に戻る
+```
+
+**注意事項**:
+- 並列起動するタスク間でファイル変更対象が重複しないよう、設計セクションから推定して確認する
+- 重複懸念がある場合は直列化する
+- task-executerにはコミットさせない（Step 7でまとめて実行）
+
+### Step 5: レビューフェーズ（task-reviewer）
+- 全タスク完了後、グループ全体で1回実行
 - 要件定義・設計との整合性確認
-- MAJOR判定 → 実装フェーズに戻る
+- MAJOR判定 → 該当タスクのみ再実行（Step 4に戻る）
 - PASS/MINOR判定 → 品質保証フェーズへ
 
-### 3. 品質保証フェーズ（task-qa）
+### Step 6: 品質保証フェーズ（task-qa）
+- グループ全体で1回実行
 - 受け入れ条件に基づく動作確認
-- テスト失敗 → 実装フェーズに戻る
+- テスト失敗 → 該当タスクのみ再実行（Step 4に戻る）
 - 全テスト合格 → コミット・プッシュフェーズへ
 
-### 4. コミット・プッシュフェーズ（einja-task-commit Skill）
+### Step 7: コミット・プッシュフェーズ（einja-task-commit Skill）
 - QA合格後、Skill toolで `einja-task-commit` Skillを直接呼び出し
 - 変更がある場合のみ実行（変更なしの場合はスキップ）
 - コミット分割案の確認はスキップ（QA合格済みのため自動適用）
@@ -156,76 +239,6 @@ Issue #123 のPhase 99 タスク（タスクグループ 99.1）を実行して
 
 ---
 
-## 受け入れ条件の参照方法
-
-このセクションは、task-executer、task-reviewer、task-qaサブエージェントが受け入れ条件を参照する際の標準手順を定義します。
-
-### requirements.mdの標準構造
-
-**必須セクション**:
-- **受け入れ基準（Acceptance Criteria）**: 各ACが以下の形式で記載
-
-**AC（Acceptance Criteria）の形式**:
-```markdown
-##### 機能要件
-- [ ] Given: 前提条件
-      When: 実行する操作
-      Then: 期待される結果
-```
-
-### task-executerの受け入れ条件参照方法
-
-1. タスクグループの関連ドキュメント（`requirements.md`）を読み込む
-2. 各ユーザーストーリー配下の「受け入れ基準」セクションを特定
-3. **検証レベルが「Unit」の AC のみ**を実装対象とする
-4. 各 AC（Given/When/Then）に対して実装と単体テストを作成
-5. `design.md` の技術仕様に準拠した実装を行う
-
-**検証責務**:
-- **Unit テスト**: 必須実装、実装と同時に作成
-- **Integration/Browser テスト**: 実装不要（task-qa が担当）
-
-**完了条件**:
-- 実装したコードの単体テストが全て合格
-- 検証レベルが「Unit」の AC を全て満たす
-- Integration/Browser レベルの AC は未検証でも実装フェーズ完了とする
-
-> **Note**: 検証レベルの詳細は `docs/einja/steering/terminology.md` を参照してください。
-
-### task-reviewerの受け入れ条件参照方法
-
-1. `requirements.md` の各ユーザーストーリー配下の「受け入れ基準」セクションを参照
-2. 実装が各ACを満たしているかを確認
-3. ACとの整合性をレビュー観点の最優先項目とする
-
-### task-qaの受け入れ条件参照方法
-
-**⚠️ 最重要**: QAエージェントは以下の手順で受け入れ条件を参照
-
-1. **受け入れ基準の抽出**
-   - タスクグループの `requirements.md` を読み込む
-   - 各ユーザーストーリー配下の「受け入れ基準」セクションを特定
-   - **検証レベルが「Integration」「Browser」の AC のみ**を抽出
-   - 検証レベルが「Unit」の AC はスキップ（task-executer が既に検証済み）
-
-2. **テストシナリオの作成**
-   - 各 AC に対して、Given/When/Then に基づくテストシナリオを作成
-   - Integration: API + DB + ミドルウェアの連携テスト
-   - Browser: Playwright MCP を使用したユーザーシナリオテスト
-   - QA 仕様書（`qa-tests/story{N}.md`）に記録
-
-3. **SUCCESS 判定基準**
-   - **検証レベルが「Integration」「Browser」の全ての AC が満たされた場合のみ**、SUCCESS 判定
-   - 1つでも AC を満たさない場合、FAILURE 判定して適切な戻し先を決定
-
-> **用語の明確化**: 「E2E」はPlaywrightコードによる自動テスト（`pnpm test:e2e`）を指します。task-qaが実行するPlaywright MCPテストは「Browser」検証レベルです。詳細は `docs/einja/steering/terminology.md` を参照してください。
-
-4. **参照ドキュメント**
-   - QA テスト項目作成方針: `docs/einja/steering/acceptance-criteria-and-qa-guide.md`
-   - テンプレート: `docs/einja/templates/requirements.md.template`
-
----
-
 ## 失敗時のリカバリーフロー
 
 ### 失敗原因の分類
@@ -388,3 +401,7 @@ AskUserQuestion:
 - Issue番号とタスクグループ番号の両方が必須
 - GitHub Issueのチェックボックス更新は自動では行わない
 - コミット時は [コミットルール](../../docs/einja/steering/commit-rules.md) を遵守
+
+<!-- @einja:project-private:start id="task-exec-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/.claude/skills/einja-task-qa/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: task-qa
+name: einja-task-qa
 description: "タスクの品質保証を実行するSkill。必須自動テスト、AC検証、動作確認を実施し、qa-tests/に結果を記録します"
 allowed-tools:
   - Task
@@ -92,7 +92,7 @@ AskUserQuestion:
 
 ### ステップ3: 既存テスト仕様の読み込み
 
-**前提**: テスト仕様は `spec-qa-generator` が作成済み。task-qaは**実行のみ**を担当。
+**前提**: テスト仕様は `qa-generator` が作成済み。task-qaは**実行のみ**を担当。
 
 1. **テスト仕様ファイルの特定**: 自然言語で指定されたAC番号からStoryを判定
    - 例: 「AC1.1, AC1.2のテストを実行」→ AC番号の先頭数字（1）からStory 1を特定 → `qa-tests/story1.md`
@@ -100,7 +100,7 @@ AskUserQuestion:
 2. **シナリオテストの確認**: `qa-tests/scenarios.md` で該当ACの実施タイミングを確認
 3. **テスト仕様の読み込み**: story{N}.md内の該当ACセクションからテストシナリオ、確認項目、期待値を把握
 
-**エラー時**: テスト仕様が存在しない場合は失敗分類B（要件齟齬）→ spec-qa-generatorで作成が必要
+**エラー時**: テスト仕様が存在しない場合は失敗分類B（要件齟齬）→ qa-generatorで作成が必要
 
 ---
 
@@ -281,7 +281,7 @@ AskUserQuestion:
 
 ## 実行制約
 
-**task-execからの呼び出し**: task-qa.md（ラッパー）経由、完了報告はtask-qa.mdが生成
+**einja-task-exec Skillからの呼び出し**: task-qa.md（ラッパー）経由、完了報告はtask-qa.mdが生成
 
 **独立使用**: トリガーワードで自律起動、完了報告は本Skillが生成
 
@@ -306,3 +306,7 @@ AskUserQuestion:
 ---
 
 **最終更新**: 2025-12-20
+
+<!-- @einja:project-private:start id="einja-task-qa-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/.claude/skills/einja-task-qa/references/troubleshooting.md

@@ -21,7 +21,7 @@ QA実行時によくある問題と対処法。
 
 **対処法**:
 1. 仕様書ディレクトリパスを確認
-2. 不在の場合はspec-requirements-generatorで作成
+2. 不在の場合はrequirements-generatorで作成
 
 **失敗分類**: D（環境問題）またはB（要件未定義）
 

package/presets/default/.claude/skills/einja-task-qa/references/usage-patterns.md

@@ -4,10 +4,10 @@ task-qa Skillの利用方法パターン集。
 
 ---
 
-## パターン1: task-execからの呼び出し（標準ワークフロー）
+## パターン1: einja-task-exec Skillからの呼び出し（標準ワークフロー）
 
 ```
-ユーザー: task-exec #123 1.1
+ユーザー: einja-task-exec #123 1.1
   → starter → executer → reviewer → qa
                                       ↓
                             task-qa.md（ラッパー）→ SKILL.md

package/presets/default/.claude/skills/einja-team-exec/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: einja-team-exec
+description: "Agent Teamsによるチーム並列実行を行うSkill。ユーザーが「チームで」「Teamで」「Agent Teamsで」「並列チームで」等と明示的にチーム実行を指示した場合に使用。通常のサブエージェント委託とは異なり、独立したClaude Codeインスタンスによるチーム協調を行う"
+---
+<!-- 参考: https://code.claude.com/docs/en/agent-teams -->
+
+# Agent Teams チーム実行
+
+## 概要
+
+Agent Teams機能を使い、複数のteammateを編成してタスクを並列実行する。各teammateは独立したClaude Codeインスタンスとして動作し、自身のコンテキストウィンドウを持つ。サブエージェント（`Task`ツール）とは根本的に異なるアーキテクチャ。
+
+### サブエージェントとの違い
+
+| 項目 | Agent Teams (Teammates) | サブエージェント (Task) |
+|------|------------------------|----------------------|
+| 実体 | 独立したClaude Codeインスタンス | メインセッション内の子プロセス |
+| コンテキスト | 各自独立（リードの会話履歴は引き継がない） | メインの指示を引き継ぎ |
+| 通信 | メンバー間で直接メッセージ可能 | メインにのみ結果を報告 |
+| 協調 | 共有タスクリストで自己調整 | メインが全作業を管理 |
+| 適用場面 | 議論・協調が必要な複雑な作業 | 結果のみが重要な集中タスク |
+| トークンコスト | 高い（各自が独立コンテキスト） | 低い（結果がメインに要約される） |
+
+### 有効なユースケース
+
+- **リサーチ・レビュー**: 複数の観点から同時に調査し、知見を共有・検証
+- **新規モジュール・機能開発**: 各teammateが異なるファイル群を担当
+- **競合仮説のデバッグ**: 異なる理論を並行検証し、議論で収束
+- **クロスレイヤー変更**: フロントエンド・バックエンド・テストを各teammateが担当
+
+## 前提条件
+
+`settings.json`に以下が設定されていること:
+```json
+{
+  "env": {
+    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
+  }
+}
+```
+
+## ワークフロー
+
+### 1. チーム構成の設計
+
+タスク内容を分析し、以下を決定する:
+
+- **teammate数**: 3-5名が推奨（コスト・協調のバランス）
+- **役割分担**: 各teammateの担当範囲と責務を明確化
+- **タスク粒度**: 5-6タスク/teammateが目安
+- **ファイル分割**: 各teammateが異なるファイル群を担当するよう分割
+
+### 2. 自然言語でチーム起動を指示
+
+リードに対して、タスク内容とチーム構成を自然言語で指示する。`subagent_type`等のパラメータ指定は不要。
+
+**プロンプト例:**
+
+```
+Create an agent team for [タスク名].
+Spawn teammates:
+- [役割1]: [担当範囲と具体的な指示]
+- [役割2]: [担当範囲と具体的な指示]
+- [役割3]: [担当範囲と具体的な指示]
+```
+
+**具体例（フルスタック機能開発）:**
+
+```
+認証機能を実装するチームを作成してください。
+teammateを3名spawn:
+- frontend: src/app/auth/ 配下のログインフォーム・認証画面を実装。NextAuth.jsを使用
+- backend: src/server/auth/ 配下のAPI・ミドルウェアを実装。JWT + httpOnly Cookie方式
+- testing: 認証機能のE2Eテスト・ユニットテストを作成。Playwright + Vitest使用
+各teammateは担当ファイル以外を編集しないこと。
+```
+
+**具体例（コードレビュー）:**
+
+```
+PR #142をレビューするチームを作成してください。
+3名のレビュアーをspawn:
+- セキュリティ観点でのレビュー
+- パフォーマンス影響のチェック
+- テストカバレッジの検証
+各自レビュー後に発見事項を報告してください。
+```
+
+### 3. spawn時のプロンプト設計ガイド
+
+teammateはリードの会話履歴を引き継がないため、spawn時のプロンプトに十分なコンテキストを含める。
+
+#### 含めるべき情報
+- **担当範囲**: 具体的なファイルパスやディレクトリ
+- **技術的コンテキスト**: 使用するライブラリ・フレームワーク・パターン
+- **制約**: 編集してはいけないファイル、守るべきルール
+- **成果物**: 何を完了とするか
+
+#### 含めなくてよい情報
+- プロジェクトの基本構成（CLAUDE.md経由で自動ロードされる）
+- git操作安全ルール（CLAUDE.md経由で自動適用される）
+- MCP設定（自動的に引き継がれる）
+
+### 4. 実行と監視
+
+- teammateはタスク完了時に自動的にリードにメッセージを送信する
+- idle通知は自動配信されるため、手動チェック不要
+- 必要に応じてteammateに追加指示を送る:
+  - **個別指示**: `SendMessage`（type: `message`）で特定のteammateに
+  - **全体通知**: `SendMessage`（type: `broadcast`）で全員に（コスト高、緊急時のみ）
+- `Shift+Down`でteammate間を切り替え（in-processモード）
+- ブロッカー発生時は即座にユーザーに報告する
+
+### 5. 完了とシャットダウン
+
+1. 全タスクの完了を`TaskList`で確認
+2. 各teammateに`SendMessage`（type: `shutdown_request`）を送信
+3. 各teammateがシャットダウンを承認するまで待機
+4. 全teammate停止後、`TeamDelete`でチームリソースをクリーンアップ
+5. ユーザーに最終結果を報告
+
+**重要**: クリーンアップは必ずリードが実行する。teammateからのクリーンアップは不整合を招く。
+
+## ファイル競合の防止
+
+Agent Teamsにおける最大のリスクはファイル競合。2つのteammateが同じファイルを編集すると上書きが発生する。
+
+### 防止策
+
+- **チーム設計時にファイル担当を明確に分割する**
+- 各teammateのspawnプロンプトに担当ファイル/ディレクトリを明記
+- 共有ファイル（設定ファイル等）の編集は1名のteammateに限定
+
+## コミット管理
+
+CLAUDE.mdの「サブエージェントのgit操作安全ルール」がCLAUDE.md経由で全teammateに自動適用される。
+
+### 追加の注意点
+
+- `einja-task-commit` Skill経由でコミットを一元管理するのが望ましい
+- teammateに直接コミットさせる場合は、変更対象ファイルをspawnプロンプトで明示的に指定
+- 完了検証: teammateの「完了」報告を鵜呑みにせず、`Read`や`Grep`で変更がディスク上に存在することを確認
+
+## チーム設計のベストプラクティス
+
+- **3-5名で開始**: バランスの良い並列度。それ以上はコスト対効果が下がる
+- **1 teammateあたり5-6タスク**: 生産性とコンテキスト切り替えのバランス
+- **リサーチ・レビューから始める**: 実装より低リスクで、並列探索の効果を確認しやすい
+- **タスク粒度を適切に**: 小さすぎ→協調オーバーヘッドが上回る / 大きすぎ→チェックインなく進行し、リスク増大
+- **定期的に進捗を確認**: 放置すると無駄な作業が蓄積する
+- **plan approval活用**: 複雑・リスクの高いタスクではteammateにplan mode必須を設定
+
+## 制限事項（実験機能）
+
+- セッション再開（`/resume`）でin-processのteammateは復元されない
+- タスクステータスの更新が遅延することがある
+- シャットダウンに時間がかかる場合がある（現在のリクエスト完了を待つ）
+- 1セッションにつき1チームのみ
+- nested teams（teammateが自身のチームを作る）は不可
+- リードは固定（交代不可）
+- split panesはtmux/iTerm2が必要
+
+<!-- @einja:project-private:start id="einja-team-exec-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/.envrc

@@ -23,6 +23,11 @@ MAIN_WORKTREE=$(get_main_worktree)
 if [ -n "$MAIN_WORKTREE" ] && [ -f "$MAIN_WORKTREE/.env.personal" ]; then
   dotenv_if_exists "$MAIN_WORKTREE/.env.personal"
 fi
+
+# Serena MCP サーバー自動起動
+if [ -n "$MAIN_WORKTREE" ] && [ -f "$MAIN_WORKTREE/scripts/ensure-serena.sh" ]; then
+  source "$MAIN_WORKTREE/scripts/ensure-serena.sh" "$MAIN_WORKTREE"
+fi
 # @einja:managed:end
 
 # @einja:seed:start id="project-env"

package/presets/default/.mcp.json

@@ -32,18 +32,8 @@
 			]
 		},
 		"serena": {
-			"type": "stdio",
-			"command": "uvx",
-			"args": [
-				"--from",
-				"git+https://github.com/oraios/serena",
-				"serena",
-				"start-mcp-server",
-				"--context",
-				"claude-code",
-				"--open-web-dashboard",
-				"false"
-			]
+			"type": "http",
+			"url": "http://127.0.0.1:${SERENA_PORT:-9850}/mcp"
 		},
 		"github": {
 			"type": "http",

package/presets/default/CLAUDE.md.template

@@ -10,6 +10,16 @@
 3. **影響範囲の最小化**: 変更は必要な箇所のみ。関係ないコードに触れない
 4. **直接実装の禁止**: あなたは絶対に直接実装を行わない。すべての作業はsubagentに委託し、可能な限り並行で呼び出す。サブエージェントの出力はユーザにも見える場所に出力すること
 5. **実装品質の自己検証**: 複雑な変更では完了前に「よりエレガントな方法はないか」を自問する。ただし単純な修正には不要
+6. **Skill-First原則**: 実装着手前に `einja-skill-first` Skillで「Skillを先に作るべきか」を評価する。反復性のある作業はSkill化してから本作業を開始する
+
+## Agent Teams の使用制限
+
+**Agent Teams（`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`）はユーザーが明示的にチーム編成を指示した場合のみ使用すること。**
+
+- 通常のタスクではサブエージェント（`Task`ツール）を使用する
+- 「チームで」「複数agentで並列に」等の明示的な指示があった場合のみAgent Teamsを起動する
+- チーム実行時は `einja-team-exec` Skillの手順に従う
+- 判断に迷う場合はサブエージェントを使用する（デフォルト動作）
 
 ## サブエージェント委託ルール
 
@@ -17,7 +27,6 @@
 
 | 作業 | 委託先 |
 |------|--------|
-| コンフリクト解消 | `conflict-resolver` |
 | Codex作業（レビュー・実装支援等） | `codex-agent` |
 | フロントエンド アーキテクチャ設計 | `frontend-architect` |
 | フロントエンド デザイン実装 | `design-engineer` |
@@ -31,9 +40,21 @@
 | `einja-task-commit` | コミット・プッシュ |
 | `einja-conflict-resolver` | gitコンフリクト解消 |
 | `einja-skill-creator` | Skill作成・更新 |
+| `einja-skill-first` | 作業前のSkill作成必要性評価（Plan/einja-issue-spec-create時に自動起動） |
 | `einja-infra-maintenance` | インフラ環境セットアップ・メンテナンス |
-| `einja:task-exec` | タスクグループ実行 |
-| `einja:spec-create` | 仕様書作成 |
+| `einja:issue-exec` | Issue全体の階層的並列実行（Command） |
+| `einja-task-exec` | タスクグループ実行（Skill tool） |
+| `einja-issue-spec-create` | Issue仕様書作成（Skill tool） |
+
+#### サブエージェント質問プロトコル（PENDING_QUESTIONS）
+
+サブエージェントではAskUserQuestionが動作しないため、質問が必要な場合は `## PENDING_QUESTIONS` 形式で返却される。
+
+サブエージェント出力に `## PENDING_QUESTIONS` が含まれている場合:
+1. 質問内容を解析し、AskUserQuestionでユーザーに確認する
+2. Agent toolの `resume` パラメータで同じサブエージェントを再開（コンテキスト維持）
+3. プロンプトにユーザーの回答を含めて渡す（例: `ユーザーの回答: Q1→A、Q2→B。これを踏まえて作業を継続してください。`）
+4. 再度PENDING_QUESTIONSがある場合は同様に処理（最大2回まで）
 
 ## コード変更時の動作方針
 
@@ -41,9 +62,16 @@
 
 ### 必須フロー
 1. 問題・要件を調査・分析する
-2. 修正計画を `docs/plans/` に作成し提示する
-3. **ユーザーの明示的な承認を得る**
-4. 承認後、`docs/plans/todo-{plan名}.md` で進捗管理しながら実装を開始する
+2. 修正計画を `docs/plans/` に作成する
+3. `einja-skill-first` で「Skill を先に作るべきか」を評価する
+   - Plan mode中は `UserPromptSubmit` hookにより自動でリマインダーが注入される
+   - `.claude/skills/einja-skill-first/SKILL.md` を読み込んで評価を実施する
+   - 推奨判定 → AskUserQuestion でユーザーに提案
+   - 承認 → 計画の TODO-0 に Skill 作成を追加
+   - 不要判定 → そのまま次へ進む
+   - ※ スキップ基準に該当する場合は評価自体を省略
+4. 計画をユーザーに提示し、**明示的な承認を得る**
+5. 承認後、`docs/plans/todo-{plan名}.md` で進捗管理しながら実装を開始する（TODO-0 があれば Skill 作成から）
 
 ### 例外（承認不要）
 - 読み取り専用操作（質問への回答、情報調査、コード調査）
@@ -108,8 +136,8 @@
 ## プロジェクト概要
 
 Turborepoモノレポ構成（pnpm workspaces）。詳細が必要な場合は以下のSkillを参照:
-- `einja-project-overview` - 構成、技術スタック、頻出コマンド
-- `einja-coding-standards` - コーディング規約、インポートパス規約
+- `_einja-project-overview` - 構成、技術スタック、頻出コマンド
+- `docs/einja/steering/development/coding-standards.md` - コーディング規約、インポートパス規約
 - `einja-infra-maintenance` - 開発環境セットアップ、サーバー管理
 
 ## マネージドディレクトリ（編集禁止）
@@ -147,6 +175,11 @@ Turborepoモノレポ構成（pnpm workspaces）。詳細が必要な場合は
 - 番号付きリスト: 詳細説明が必要な場合
 - 推奨オプションには `（推奨）` と理由を付記
 
+### 選択肢の記述ルール
+- 各選択肢の `description` に**必ず詳細説明・注意点・補足**を記載する
+- トレードオフ、影響範囲、前提条件など判断に必要な情報を含める
+- ラベルだけで選択させない。ユーザーが十分な情報に基づいて判断できるようにする
+
 ## 報告ルール
 
 ### 出力形式
@@ -189,4 +222,8 @@ Turborepoモノレポ構成（pnpm workspaces）。詳細が必要な場合は
 - サブエージェントの「完了」報告のみで完了判定しない
 - 検証をスキップして完了宣言しない
 
+<!-- @einja:project-private:start id="claude-md-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->
+
 

package/presets/default/docs/einja/example/specs/issues/issue999-example-task/tasks.md

@@ -159,7 +159,7 @@
 
 ### タスク階層（4階層）
 - **Phase（フェーズ）**: 最上位単位（1, 2, 3...）
-- **タスクグループ**: Vibe-KanbanタスクとPRの作成単位（1.1, 1.2...）、**チェックボックス付き**（`- [ ]`）、1-4時間
+- **タスクグループ**: PRの作成単位（1.1, 1.2...）、**チェックボックス付き**（`- [ ]`）、1-4時間
 - **タスク**: 作業単位・コミット単位（1.1.1, 1.1.2...）、**チェックボックスなし**、15-60分
 - **サブタスク**: タスク内の詳細作業項目、**箇条書き**（`-`）
 

package/presets/default/docs/einja/instructions/deployment-setup.md

@@ -35,7 +35,7 @@
 |--------|----------------|------|
 | Volta | `curl https://get.volta.sh \| bash` | Node.jsバージョン管理 |
 | pnpm | `volta install pnpm` | パッケージ管理 |
-| Docker | [Docker Desktop](https://www.docker.com/products/docker-desktop/) | PostgreSQL実行 |
+| Docker | macOS: [OrbStack](https://orbstack.dev/)（推奨）/ その他: [Docker Engine](https://docs.docker.com/engine/install/) | PostgreSQL実行 |
 | GitHub CLI (`gh`) | `brew install gh` | GitHub操作 |
 | Vercel CLI | `pnpm add -g vercel` | Vercelデプロイ |
 | Neon CLI (`neonctl`) | `npm install -g neonctl` | Neonデータベース管理 |
@@ -599,11 +599,6 @@ gh secret set TURBO_TOKEN --body "new-token"
 - [GitHub Actions - Encrypted secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
 <!-- @einja:managed:end -->
 
----
-
-<!-- @einja:seed:start id="deployment-setup-project" -->
-## プロジェクト固有の設定
-
-<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="deployment-setup-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/docs/einja/instructions/environment-setup.md

@@ -639,11 +639,6 @@ dotenvx run -f .env -f .env.local -- <command>
 - **共有禁止**: 他の開発者とトークンを共有しないこと
 <!-- @einja:managed:end -->
 
----
-
-<!-- @einja:seed:start id="environment-setup-project" -->
-## プロジェクト固有の設定
-
-<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
-<!-- einja syncで上書きされません -->
-<!-- @einja:seed:end -->
+<!-- @einja:project-private:start id="environment-setup-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->