@einja/dev-cli 0.1.41 → 0.1.44

package/presets/default/.claude/skills/einja-skill-first/SKILL.md

@@ -0,0 +1,265 @@
+---
+name: einja-skill-first
+description: >
+  タスク着手前にSkillを先に作るべきかを自動評価するメタSkill。Plan mode進入時やeinja-issue-spec-create実行時に自動起動し、既存Skillのギャップ分析とROI評価を行い、Skill作成の必要性を構造化して提案する。「Skill作るべき？」「Skill化」「skill-first」「Skill-first」等のキーワードでも直接呼び出し可能。
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+---
+
+<!-- ベース: .claude/skills/einja-skill-creator/SKILL.md -->
+
+# einja-skill-first: Skill作成事前評価メタSkill
+
+タスク着手前に「Skillを先に作るべきか」を評価し、必要ならSkill作成をTODOの先頭に積むメタSkill。
+
+Plan mode 内でも動作する（Read / Grep / Glob のみ使用）。Skill作成自体は `einja-skill-creator` に委譲する。
+
+## einja-skill-creator との責務分離
+
+| 責務 | einja-skill-first | einja-skill-creator |
+|------|:---:|:---:|
+| ギャップ分析・ROI評価 | ○ | - |
+| Skill仕様ドラフト（概要） | ○ | - |
+| SKILL.md 作成 | - | ○ |
+| テスト・eval | - | ○ |
+
+---
+
+## 起動方式（3系統）
+
+### 1. Plan mode 進入時（自動）
+
+CLAUDE.md の必須フロー Step2（修正計画作成）→ Step3（ユーザー承認）の間で自動実行する。計画を提示する前に、Skill作成の必要性を評価する。
+
+### 2. einja-issue-spec-create 実行時（自動）
+
+einja-issue-spec-create の Phase 0 で自動実行する。仕様書作成の前にSkillギャップを分析し、Skill-first アプローチの要否を判定する。
+
+### 3. 明示起動（手動）
+
+以下のキーワードで直接呼び出し可能:
+- 「Skill作るべき？」
+- 「Skill化」
+- 「skill-first」
+- 「Skill-first」
+
+---
+
+## スキップ基準（即座に「不要」判定）
+
+以下に該当する場合は評価自体を省略し、即座に「不要」と判定する:
+
+- **単発の小規模修正**: バグ修正、typo、設定値変更
+- **既存キーワードトリガー一致**: CLAUDE.md のキーワードトリガーに既に一致するタスク
+- **具体的かつ限定的な作業指示**: 「ファイルXのY行をZに変更」等
+- **明らかに1回限りの作業**: 特定バグの調査、特定ファイルのリファクタ等
+
+スキップ時は以下を出力して終了:
+
+```
+## Skill作成評価結果
+### 判定: ⚪不要（スキップ基準に該当）
+- 理由: {該当するスキップ基準}
+```
+
+---
+
+## 評価フロー（4ステップ）
+
+### ステップ1: 作業パターン分析
+
+1. **作業カテゴリ特定**: FE / BE / インフラ / ドキュメント / リファクタ等に分類する
+2. **反復性評価**: 今後も繰り返す作業か判定する
+   a. `docs/einja/memory/patterns.md` を Read で参照し、類似パターンの記録がないか確認する
+   b. patterns.md に記録がない場合、`docs/plans/` からも反復パターンを推定する
+      - Glob で `docs/plans/*.md` を取得（`todo-*.md`, `*-agent-*.md` は除外）
+      - Grep で作業カテゴリのキーワード + `# Plan:` タイトル行を検索
+      - 類似カテゴリの作業が2件以上あれば反復性の根拠とする
+3. **複雑度評価**: 手順数・判断分岐数・参照ドキュメント数から複雑度を見積もる
+
+### ステップ2: 既存Skillギャップ分析
+
+1. `.claude/skills/einja-*/SKILL.md` を Glob で動的取得する
+2. 各Skillの name / description を Read で読み取る
+3. タスクに対するカバレッジを3段階で判定する:
+
+| カバレッジ | 判定 | 次のアクション |
+|-----------|------|---------------|
+| **完全カバー** | Skill作成不要 | 既存Skillで実行 |
+| **部分カバー** | 既存Skill拡張を検討 | 拡張箇所を特定 |
+| **カバー外** | 新規Skill作成を検討 | ステップ3へ進む |
+
+### ステップ3: ROI評価（スコアリング）
+
+以下のスコアリングで定量評価する。
+
+**コスト側（各1-3点）:**
+
+| 項目 | 1点 | 2点 | 3点 |
+|------|-----|-----|-----|
+| 作成時間 | 数十分 | 数時間 | 1日以上 |
+| 複雑度 | 直線的 | 分岐あり | 多段判断 |
+| テスト必要度 | 不要 | 簡易 | 網羅的eval必要 |
+
+**価値側（各1-3点）:**
+
+| 項目 | 1点 | 2点 | 3点 |
+|------|-----|-----|-----|
+| 再利用頻度 | 月1回以下 | 週1-2回 | ほぼ毎日 |
+| 品質安定化 | ばらつき小 | 中程度 | 手順ミスが致命的 |
+| 時間節約 | 5分以下/回 | 30分程度/回 | 1時間以上/回 |
+| チーム共有価値 | 個人向け | チーム内 | 全プロジェクト共通 |
+
+**判定基準:**
+```
+価値合計 - コスト合計 >= 2 → 推奨（新規作成）
+価値合計 - コスト合計 >= 0 かつ部分カバー → 拡張推奨
+それ以外 → 不要
+```
+
+### ステップ4: 構造化出力
+
+以下のテンプレートで出力する。
+
+```markdown
+## Skill作成評価結果
+
+### 判定: {判定アイコン}{判定テキスト}
+
+### スコア
+| カテゴリ | 項目 | スコア |
+|---------|------|--------|
+| コスト | 作成時間 | X/3 |
+| コスト | 複雑度 | X/3 |
+| コスト | テスト必要度 | X/3 |
+| **コスト合計** | | **X/9** |
+| 価値 | 再利用頻度 | X/3 |
+| 価値 | 品質安定化 | X/3 |
+| 価値 | 時間節約 | X/3 |
+| 価値 | チーム共有価値 | X/3 |
+| **価値合計** | | **X/12** |
+| **差分（価値-コスト）** | | **X** |
+```
+
+**判定アイコンの定義:**
+- 推奨: `🟢推奨`
+- 拡張推奨: `🟡拡張推奨`
+- 不要: `⚪不要`
+
+### ステップ5: 過去Plan検索によるユースケース収集（推奨/拡張推奨の場合のみ）
+
+以下の手順で過去Planから類似作業を検索し、Skill仕様のユースケースに反映する。
+
+1. Glob で `docs/plans/*.md` を取得する
+   - 除外: `todo-*.md`, `*-agent-*.md`（子エージェント出力）
+2. Grep で以下のキーワードを検索し、関連Planを特定する
+   - ステップ1で特定した作業カテゴリのキーワード
+   - 変更対象ファイルパターン（例: `.claude/skills/`, `CLAUDE.md` 等）
+   - `# Plan:` タイトル行で関連性を粗くフィルタ
+3. 関連性の高いPlan（最大5件）のみ Read で詳細を確認する
+   - `## Context` セクションから作業概要を抽出
+   - 変更対象ファイル・手順から共通パターンを特定
+4. 類似度を判定する
+   - 高: 変更対象ファイルが重複する
+   - 中: 同一ドメインの作業、または手法・パターンが類似
+5. 結果を Skill概要仕様のユースケースセクションに反映する
+
+---
+
+## 判定別の推奨ワークフロー
+
+### 推奨（新規Skill作成）
+
+```markdown
+### Skill概要仕様
+- **名前**: einja-{proposed-name}
+- **目的**: {Skillの目的}
+- **主要フロー**: {主要な処理ステップの概要}
+- **推定作成時間**: {見積もり}
+- **ユースケース（過去Planから）**:
+  - {Plan名}: {作業概要}（類似度: 高/中）
+  - {Plan名}: {作業概要}（類似度: 高/中）
+
+### 推奨ワークフロー
+計画のTODO-0にSkill作成を追加し、`einja-skill-creator` Skillで作成後に本作業を開始する。
+```
+
+### 拡張推奨（既存Skill拡張）
+
+```markdown
+### 推奨ワークフロー
+既存Skill {name} の拡張を検討する。
+- **拡張内容**: {具体的な拡張箇所}
+- **影響範囲**: {拡張による影響}
+```
+
+### 不要
+
+```markdown
+### 推奨ワークフロー
+既存Skillで十分カバー可能。該当Skill: {name}
+```
+
+---
+
+## Plan mode 対応
+
+### Plan mode 内で行うこと
+
+- 既存Skill一覧を Glob + Read で取得する
+- `docs/einja/memory/patterns.md` を Read で参照する
+- ROI評価ロジックを実行する（計算のみ）
+- 構造化された評価結果を返却する
+
+### Plan mode 内で行わないこと
+
+- ファイル作成・編集
+- einja-skill-creator の呼び出し
+- Bash コマンド実行
+
+### 親エージェントの責務（Plan mode内）
+
+1. skill-first の結果を受け取る
+2. AskUserQuestion で提案する（推奨 / 拡張推奨の場合）
+3. 承認された場合、計画ファイルの TODO-0 に Skill 作成を記載する
+
+### Plan mode 解除後のフロー
+
+```
+TODO-0: einja-skill-creator で Skill 作成（承認された場合のみ）
+TODO-1〜: 作成した Skill を活用して本作業を実行
+```
+
+---
+
+## エラー処理
+
+| エラー種別 | 原因 | 対処 |
+|-----------|------|------|
+| Skill一覧取得失敗 | `.claude/skills/` が存在しない | カバレッジ判定をスキップし、ROIのみで評価 |
+| patterns.md 不在 | memory ディレクトリが未初期化 | 反復性評価をスキップし、他の項目で評価 |
+| 作業内容が不明確 | 入力情報が不足 | スキップ基準を適用し「不要」と判定 |
+
+---
+
+## 実行制約
+
+- このSkillは親エージェント（オーケストレーター）から呼び出される
+- Read / Grep / Glob のみ使用可能（Plan mode 互換）
+- Skill作成の実行は行わない（einja-skill-creator に委譲）
+
+---
+
+## 連携
+
+- **呼び出し元**: 親エージェント（Plan mode 進入時、einja-issue-spec-create Phase 0）
+- **委譲先**: `einja-skill-creator` - Skill作成の実行
+- **参照**: `docs/einja/memory/patterns.md` - 過去の作業パターン
+
+---
+
+<!-- @einja:project-private:start id="einja-skill-first-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/.claude/skills/einja-subagent-question-protocol/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: einja-subagent-question-protocol
+description: サブエージェントがユーザーへの質問を返却するためのプロトコル定義。AskUserQuestionが動作しないサブエージェント環境で使用。
+autoload: true
+# autoload: サブエージェントに自動preloadするため。親エージェントはPENDING_QUESTIONSの「受信・ハンドリング」側（CLAUDE.md参照）
+---
+
+# サブエージェント質問プロトコル（PENDING_QUESTIONS）
+
+## 背景
+
+Claude Code v2.0.56以降、**サブエージェントではAskUserQuestionツールがシステムレベルでフィルタリングされ動作しない**。
+そのため、サブエージェントがユーザーへの確認が必要な場合は、以下のプロトコルに従って質問を返却する。
+
+## プロトコル概要
+
+1. サブエージェントは質問を `## PENDING_QUESTIONS` セクションとして出力に含める
+2. 親エージェントが出力を検出し、AskUserQuestionでユーザーに確認する
+3. 親エージェントがAgent toolの `resume` パラメータで同じサブエージェントを再開する
+4. 再開時にユーザーの回答がプロンプトとして渡される
+
+## PENDING_QUESTIONS フォーマット
+
+質問を返却する場合、**必ず以下の形式**で出力し、その後停止すること：
+
+```markdown
+## PENDING_QUESTIONS
+
+以下の不明点の解消が必要です。
+
+### Q1: [質問タイトル]
+**背景**: [なぜこの質問が必要か、どのような文脈で発生したか]
+
+| 選択肢 | 説明 | メリット | デメリット |
+|--------|------|----------|------------|
+| A: [ラベル] | [詳細説明] | [メリット] | [デメリット] |
+| B: [ラベル] | [詳細説明] | [メリット] | [デメリット] |
+| C: [ラベル] | [詳細説明] | [メリット] | [デメリット] |
+
+**推奨**: A（[推奨理由]）
+
+### Q2: [質問タイトル]
+**背景**: [なぜこの質問が必要か]
+
+| 選択肢 | 説明 | メリット | デメリット |
+|--------|------|----------|------------|
+| A: [ラベル] | [詳細説明] | [メリット] | [デメリット] |
+| B: [ラベル] | [詳細説明] | [メリット] | [デメリット] |
+
+**推奨**: B（[推奨理由]）
+```
+
+## ルール
+
+1. **1回にまとめる**: 複数の質問がある場合は Q1, Q2, ... としてまとめて返却する。1問ずつ返却しない
+2. **選択肢と背景を必ず含める**: 各選択肢には説明・メリット・デメリットを記載し、ユーザーが十分な情報に基づいて判断できるようにする
+3. **推奨を明示する**: 各質問に対して推奨選択肢とその理由を記載する
+4. **質問返却後は停止する**: PENDING_QUESTIONSを出力したら、それ以降の作業は行わない。回答を受けてから再開する
+5. **再開後の作業継続**: `resume` で再開された場合、渡された回答に基づいて作業を継続する
+
+## AskUserQuestion YAML → PENDING_QUESTIONS 変換ガイド
+
+エージェント定義にAskUserQuestion YAMLの参考例がある場合、以下のように変換する：
+
+### 変換前（AskUserQuestion YAML）
+```yaml
+AskUserQuestion:
+  question: "状態管理ライブラリを選択してください"
+  header: "状態管理"
+  options:
+    - label: "TanStack Query（推奨）"
+      description: "推奨理由: サーバー状態管理に最適。..."
+    - label: "Zustand"
+      description: "シンプルなグローバル状態管理。..."
+```
+
+### 変換後（PENDING_QUESTIONS形式）
+```markdown
+## PENDING_QUESTIONS
+
+以下の不明点の解消が必要です。
+
+### Q1: 状態管理ライブラリの選択
+**背景**: サーバー状態の管理方式を決定する必要があります。
+
+| 選択肢 | 説明 | メリット | デメリット |
+|--------|------|----------|------------|
+| A: TanStack Query | サーバー状態管理に最適 | 自動キャッシュ管理、型安全 | 学習コスト中程度 |
+| B: Zustand | シンプルなグローバル状態管理 | 軽量、シンプルなAPI | サーバー状態管理は手動 |
+
+**推奨**: A（サーバー状態管理に最適で、キャッシュと再取得が自動化されるため）
+```
+
+## 重要な注意事項
+
+- このプロトコルは**サブエージェントとして動作する場合にのみ**適用される
+- 親エージェント（直接ユーザーと対話する場合）では通常通りAskUserQuestionを使用すること
+- エージェント定義内のAskUserQuestion YAMLは「どんな質問をすべきか」の参照情報として有用なので削除しない

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

@@ -1,6 +1,6 @@
 ---
-name: task-commit
-description: "コミット・プッシュを実行するSkill。docs/einja/steering/commit-rules.mdのルールに従い、分割コミットを実施。直接呼び出し可能（確認あり）、task-exec経由では自動実行"
+name: einja-task-commit
+description: "コミット・プッシュを実行するSkill。docs/einja/steering/commit-rules.mdのルールに従い、分割コミットを実施。直接呼び出し可能（確認あり）、einja-task-exec Skill経由では自動実行"
 allowed-tools:
   - Bash
   - Read
@@ -49,7 +49,7 @@ git stash pop
 
 #### コンフリクト発生時
 
-1. **conflict-resolver エージェント** を Task ツールで呼び出して解消
+1. **einja-conflict-resolver Skill** の手順に従って解消
 2. 解消できない場合は以下を出力して終了:
 
 ```markdown
@@ -139,9 +139,9 @@ AskUserQuestion:
 
 ### ステップ4: 品質チェック
 
-#### task-exec経由での呼び出しの場合
+#### einja-task-exec Skill経由での呼び出しの場合
 
-task-exec経由でQA合格後に呼び出されるため、品質チェック（lint/typecheck/test/build）は**スキップ**します。
+einja-task-exec Skill経由でQA合格後に呼び出されるため、品質チェック（lint/typecheck/test/build）は**スキップ**します。
 
 QAフェーズで既に実行済みのため、重複実行は不要です。
 
@@ -171,7 +171,7 @@ QAフェーズで既に実行済みのため、重複実行は不要です。
 
 #### コミットコマンド
 
-**task-exec経由での呼び出しの場合**（QA済み）:
+**einja-task-exec Skill経由での呼び出しの場合**（QA済み）:
 
 ```bash
 git add src/auth/login.ts src/auth/logout.ts && git commit -m "$(cat <<'EOF'
@@ -253,7 +253,7 @@ EOF
 
 | エラー種別 | 対処 |
 |-----------|------|
-| git pull コンフリクト | conflict-resolver エージェントを Task ツールで呼び出して解消を試行 |
+| git pull コンフリクト | einja-conflict-resolver Skill の手順に従って解消を試行 |
 | コンフリクト解消失敗 | 報告して終了、手動解決を依頼 |
 | git commit 失敗 | エラー内容を報告 |
 | git push 失敗 | エラー内容を報告、原因を説明 |

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, TaskCreate, TaskUpdate, TaskList, TaskGet, TaskOutput, Skill, Read, Write, Edit, MultiEdit, Bash, Grep, Glob, WebFetch, mcp__github__*, mcp__serena__*
----
-
-# タスク実行コマンド
+# タスク実行 Skill
 
 ## 役割
 
@@ -129,8 +124,8 @@ $ARGUMENTSからIssue番号とタスクグループ番号を解析する（現
 1. **specディレクトリを探索**: `docs/specs/issues/*/issue{N}-*/` パターンで検索
 2. **存在チェック**:
    - 完全なspec（requirements.md + design.md + qa-tests/） → 次へ
-   - 部分的spec → エラー終了（`/einja:spec-create` の実行を案内）
-   - specなし → `einja-general-context-loader` Skill を呼び出してコンテキスト収集
+   - 部分的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 はパスのみ特定**（内容は読み込まない）
@@ -244,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`
-
----
-
 ## 失敗時のリカバリーフロー
 
 ### 失敗原因の分類

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が生成
 

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