@einja/dev-cli 0.1.40 → 0.1.44

package/presets/default/.claude/{commands/einja/spec-create.md → skills/einja-issue-spec-create/SKILL.md}

@@ -1,16 +1,11 @@
----
-description: "タスクの仕様書（requirements.md、design.md、qa-tests/）を段階的に作成・修正するワークフローを実行します。ARGUMENTS: タスク内容の説明またはAsanaタスクURL（必須）、既存仕様書のパス（オプション）"
-allowed-tools: Task, Read, Write, Edit, MultiEdit, Bash, Grep, Glob, TodoRead, TodoWrite, mcp__asana__*, mcp__figma_dev_mode__*
----
-
-# タスク仕様書作成コマンド
+# Issue仕様書作成Skill
 
 ## あなたの役割
 プロダクト開発のシニアテクニカルアーキテクト兼シニアプロダクトエンジニアとして、ATDD（受け入れテスト駆動開発）に基づく仕様書を段階的に作成します。
 
 ## タスク管理
 TodoWriteツールを使用して全体の進捗を可視化し、ユーザーに現在の状況を明確に伝えます：
-- 各仕様書作成フェーズ（requirements.md、design.md、QAテスト仕様、GitHub Issueへのタスク記述）をトップレベルタスクとして管理
+- 各仕様書作成フェーズ（requirements.md、ui-design.pen、design.md、QAテスト仕様、GitHub Issueへのタスク記述）をトップレベルタスクとして管理
 - エージェント起動前にタスクを「in_progress」に更新
 - エージェント完了後に「completed」に更新
 - ユーザー承認待ちの状態も明示的に表示
@@ -32,7 +27,7 @@ TodoWriteツールを使用して全体の進捗を可視化し、ユーザー
 
 ### 0. 前提確認フェーズ（ワークフロー開始時）
 
-**⚠️ 重要**: 仕様書作成開始前に、以下の3つの質問で前提を確認すること。
+**⚠️ 重要**: 仕様書作成開始前に、以下の確認を行うこと。
 
 #### 0.1 TDD適用判定
 
@@ -108,6 +103,16 @@ AskUserQuestion:
 **「その他」選択時の対応**:
 - ブランチ名をユーザーに確認し、IssueBranchBaseとして記録する
 
+#### 0.4 Skill作成必要性の評価
+
+`einja-skill-first` Skillを使用して、このタスクに対してSkillを先に作るべきかを自動評価する。
+
+- **スキップ基準に該当する場合**（単発修正、具体的な小規模指示等）: 評価を省略し次へ進む
+- **評価実行時**: Skillが構造化された評価結果（🟢推奨/🟡拡張推奨/⚪不要）を返却
+  - 🟢推奨 → AskUserQuestionでユーザーに提案。承認されたら仕様書作成前にSkill作成を実施
+  - 🟡拡張推奨 → 既存Skill拡張の提案をユーザーに確認
+  - ⚪不要 → そのまま次へ進む
+
 ### 1. 外部リソースの確認
 
 **AsanaタスクURL**の場合：
@@ -140,7 +145,7 @@ AskUserQuestion:
 **重要**: 各段階で必ずユーザー承認を得て、コミット＆プッシュしてから次へ進行すること。
 
 #### Phase 1: requirements.md（要件定義書）
-1. spec-requirements-generatorエージェントで作成
+1. requirements-generatorエージェントで作成
    - エージェント内で既存コードの分析を実施
    - ATDD形式のユーザーストーリーと受け入れ基準
 2. **ユーザーに内容確認を依頼**
@@ -152,11 +157,38 @@ AskUserQuestion:
    - 他のメンバーがレビューできるようにする
 4. **承認を得てから次のステップ（design.md）に進む**
 
-#### Phase 2: design.md（設計書）
-1. spec-design-generatorエージェントで作成
+#### Phase 2: ui-design.pen（UIデザイン）
+
+**スキップ判定**: requirements.mdに画面・UI関連の要件がない場合はスキップ
+- 判定基準: requirements.md内に「画面」「UI」「フォーム」「ダッシュボード」「表示」「ボタン」「入力」等のキーワードが含まれるか確認
+- 判断が曖昧な場合はAskUserQuestionでユーザーに確認
+
+**実行手順:**
+1. **既存画面確認（改修の場合）**
+   - Playwright MCPで既存画面のスクリーンショットを取得
+   - 改修対象のUIパターンを把握
+
+2. **ui-design-generatorエージェントで.pen生成**
+   - requirements.mdの内容を参照
+   - Pencil MCPでビジュアルモックアップを作成
+   - 出力: `{仕様書ディレクトリ}/ui-design.pen`
+
+3. **ユーザーに内容確認を依頼**
+   - Pencil MCPのget_screenshotで各画面プレビューを提示
+   - 確認ポイントを明示（UIの方向性、レイアウト、コンポーネント選択など）
+
+4. **ユーザー承認後、コミット＆プッシュ**
+   - コミットメッセージ: `docs: {機能名}のUIデザインを追加`
+   - ブランチは `issue/{issue番号}` にプッシュ
+
+5. **承認を得てから次のステップ（design.md）に進む**
+
+#### Phase 3: design.md（設計書）
+1. design-generatorエージェントで作成
    - エージェント内で既存アーキテクチャの調査を実施
    - 技術アーキテクチャとデータモデル
    - requirements.mdの内容を参照
+   - **ui-design.penが存在する場合、Pencil MCPでビジュアルモックアップを参照してUI関連セクション（9-11）を作成**
 2. **ユーザーに内容確認を依頼**
    - 作成したファイルのパスと概要を提示
    - 確認ポイントを明示（アーキテクチャの妥当性、実装方針など）
@@ -165,8 +197,8 @@ AskUserQuestion:
    - ブランチは `issue/{issue番号}` にプッシュ
 4. **承認を得てから次のステップ（QAテスト仕様生成）に進む**
 
-#### Phase 3: QAテスト仕様生成（シナリオテスト含む）
-1. spec-qa-generatorエージェントで作成
+#### Phase 4: QAテスト仕様生成（シナリオテスト含む）
+1. qa-generatorエージェントで作成
    - requirements.mdとdesign.mdの内容を参照
    - **シナリオテスト（scenarios.md）**: 複数タスクをまたぐ継続操作フローのテスト仕様
    - **Story別テスト仕様**: 各ユーザーストーリー（AC単位）のテスト仕様
@@ -179,38 +211,38 @@ AskUserQuestion:
    - ブランチは `issue/{issue番号}` にプッシュ
 4. **承認を得てから次のステップ（GitHub Issueへのタスク記述）に進む**
 
-#### Phase 4: GitHub Issueへのタスク記述
+#### Phase 5: GitHub Issueへのタスク記述
 
-##### 4.1 タスク生成・検証ループ
+##### 5.1 タスク生成・検証ループ
 
 **重要**: タスク生成後は自動的にフォーマット検証を行い、違反があれば差し戻します。
 
 ```
 【タスク生成・検証ループ】（最大3回）
   │
-  ├─ spec-tasks-generator 呼び出し
+  ├─ tasks-generator 呼び出し
   │   └─ タスク一覧を生成（またはエラーフィードバックを元に修正版を生成）
   │
-  ├─ spec-tasks-validator 呼び出し
+  ├─ tasks-validator 呼び出し
   │   └─ フォーマット検証
   │
   └─ 検証結果判定
       ├─ SUCCESS → ループ終了、ユーザー確認へ
-      └─ FAILURE → spec-tasks-generator に差し戻し
+      └─ FAILURE → tasks-generator に差し戻し
                    └─ エラーレポート付きで再呼び出し
                    └─ ループ再開（最大3回）
 
   ※ 3回失敗 → ユーザーに手動修正を依頼
 ```
 
-1. **spec-tasks-generatorエージェントでタスク生成**
+1. **tasks-generatorエージェントでタスク生成**
    - エージェント内で実装の影響範囲を分析
    - 実装タスクの分解と依存関係
    - requirements.md、design.md、**qa-tests/scenarios.md**の内容を参照
    - 各タスクに**シナリオテスト実施タイミング**を明記
    - **GitHub Issueの説明文にタスク一覧を記述**
 
-2. **spec-tasks-validatorエージェントでフォーマット検証**
+2. **tasks-validatorエージェントでフォーマット検証**
    - タスク階層（Phase/タスクグループ/タスク/サブタスク）の形式チェック
    - メタデータ（要件・依存関係・完了条件・対応設計・シナリオテスト）の必須チェック
    - 依存関係の書式・参照先の検証
@@ -219,13 +251,13 @@ AskUserQuestion:
 3. **検証結果の処理**
    - **SUCCESS**: ユーザー確認フェーズへ進む
    - **FAILURE（リトライ可能）**:
-     - エラーレポートを spec-tasks-generator に渡して再生成
+     - エラーレポートを tasks-generator に渡して再生成
      - ループ再開（現在の試行回数をインクリメント）
    - **MAX_RETRIES_EXCEEDED（3回失敗）**:
      - ユーザーに手動修正を依頼
      - エラー内容を提示し、修正後に続行できるよう案内
 
-##### 4.2 ユーザー確認
+##### 5.2 ユーザー確認
 
 4. **ユーザーに内容確認を依頼**
    - 更新したGitHub IssueのURL（#{issue_number}）と概要を提示
@@ -259,6 +291,7 @@ AskUserQuestion:
    - 本文に以下を含める:
      - Spec PR へのリンク
      - 要件ドキュメントへのリンク（requirements.mdまたはrequirements/README.md）
+     - UIデザインへのリンク（ui-design.pen、存在する場合のみ）
      - 設計ドキュメントへのリンク（design.mdまたはdesign/README.md）
      - QAテスト仕様へのリンク（qa-tests/scenarios.md）
      - タスク一覧（Phase別チェックボックス形式、シナリオテスト実施タイミング明記）
@@ -280,6 +313,7 @@ AskUserQuestion:
 └── {機能カテゴリ名}/
     └── issue{issue番号}-{機能名}/
         ├── requirements.md  # 要件定義書（ATDD形式）
+        ├── ui-design.pen    # UIデザイン（UI関連のみ）
         ├── design.md        # 設計書（技術詳細）
         └── qa-tests/        # QAテスト仕様
             ├── scenarios.md # シナリオテスト（複数タスクをまたぐフロー）
@@ -300,6 +334,7 @@ AskUserQuestion:
         │   ├── overview.md          # 概要とスコープ
         │   ├── stories.md           # ユーザーストーリー
         │   └── technical.md         # 技術要件
+        ├── ui-design.pen            # UIデザイン（UI関連のみ）
         ├── design/                  # 設計書ディレクトリ
         │   ├── README.md            # 目次
         │   ├── architecture.md      # アーキテクチャ
@@ -326,4 +361,6 @@ AskUserQuestion:
 - Next.js + Hono + Prisma技術スタック対応
 - Asana/Figma連携によるトレーサビリティ確保
 
-実行を開始します...
+<!-- @einja:project-private:start id="issue-spec-create-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/.claude/skills/einja-issue-spec-generator/SKILL.md

@@ -0,0 +1,105 @@
+# Issue仕様タスク生成 Skill
+
+## 概要
+
+このSkillは、要件定義書（requirements.md）と設計書（design.md）に基づいて、GitHub Issueにタスク一覧を生成します。
+
+## 責務
+
+- タスク一覧の生成（検証・修正は行わない）
+- エラーフィードバック付きで呼び出された場合は修正版を生成
+
+## 使用タイミング
+
+- tasks-generator サブエージェントから呼び出される
+- einja-issue-spec-create Skillのタスク生成フェーズで使用
+
+## 入力
+
+### 必須入力
+- `spec_directory`: 仕様書ディレクトリパス（requirements.md, design.md, qa-tests/を含む）
+- `issue_number`: GitHub Issue番号（既存Issueを更新する場合）
+
+### オプション入力
+- `error_feedback`: バリデーション失敗時のエラーレポート（Markdown形式）
+  - 差し戻し時に渡される
+  - このフィードバックを元に修正版を生成
+
+## 出力
+
+GitHub Issueの本文（Markdown形式）:
+- AS-IS / TO-BE / 対応方針
+- タスク一覧（Phase → タスクグループ → タスク → サブタスク）
+
+## フォーマットルール
+
+**[タスク管理ガイドライン](../../../docs/einja/steering/task-management.md)** を必ず参照。
+
+### クイックリファレンス
+
+| 階層 | 書式 |
+|------|------|
+| Phase | `### Phase 1: [名前]` |
+| タスクグループ | `- [ ] 1.1 [名前]` |
+| タスク | `  - 1.1.1 [名前]` + メタデータ |
+
+### タスクの必須メタデータ
+
+各タスク（X.Y.Z）に以下を必ず付与：
+- **要件**: Story X
+- **依存関係**: なし / X.Y / Phase X完了
+- **完了条件**: [条件]（ACX.Xを満たす）
+- **対応設計**: design.md「[セクション名]」
+- **実装AC**: ACX.X, ACX.Y（このタスクで実装するAC番号）
+- **シナリオテスト**: なし / シナリオX Step Y-Z
+
+## TDDデフォルト適用
+
+**原則**: ロジック・コード実装があるタスクは**TDDをデフォルトで適用**する。
+
+| 対象 | TDD適用 |
+|------|---------|
+| Domain/UseCase/Validator/Repository | **適用** |
+| API実装、UI実装 | **適用** |
+| 設定ファイル、マイグレーション、シードデータ | 不適用 |
+
+**注意**: requirements.mdへの「TDD採用」明記は不要。
+
+### TDDタスク構造テンプレート
+
+TDDは**1タスク内のサブタスク**として記載（3タスク分割ではない）：
+
+```markdown
+- X.Y.Z 機能名の実装（TDD）
+  - **テスト作成（Red）**:
+    - [テスト内容]
+  - **実装（Green）**:
+    - [実装内容]
+  - **リファクタリング**:
+    - [改善内容]
+  - **要件**: Story X
+  - **依存関係**: ...
+  - **完了条件**: ...
+  - **対応設計**: ...
+  - **実装AC**: ACX.X, ACX.Y
+  - **シナリオテスト**: ...
+```
+
+詳細は[タスク管理ガイドライン](../../../docs/einja/steering/task-management.md)の「TDDタスク構造」セクションを参照。
+
+## エラーフィードバック対応
+
+`error_feedback` が渡された場合：
+1. エラーレポートを解析
+2. 指摘された問題を特定
+3. 修正版のタスク一覧を生成
+4. 同じエラーを繰り返さないよう注意
+
+## 関連ドキュメント
+
+- [タスク管理ガイドライン](../../../docs/einja/steering/task-management.md) - フォーマット定義（Single Source of Truth）
+- [tasks-generator サブエージェント](../../agents/einja/issue-specs/tasks-generator.md) - 呼び出し元
+
+<!-- @einja:project-private:start id="einja-issue-spec-generator-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/.claude/skills/einja-issue-spec-generator/references/format-rules.md

@@ -0,0 +1,35 @@
+# タスクフォーマット簡易参照
+
+**詳細は [タスク管理ガイドライン](../../../../docs/einja/steering/task-management.md) を参照**
+
+## タスク階層
+
+| 階層 | 番号形式 | Markdown形式 |
+|------|---------|-------------|
+| Phase | 1, 2, 3 | `### Phase 1: 名前` |
+| タスクグループ | X.Y | `- [ ] 1.1 名前` |
+| タスク | X.Y.Z | `  - 1.1.1 名前` |
+| サブタスク | なし | `    - 内容` |
+
+## メタデータ（タスク単位で必須）
+
+```markdown
+- 1.1.1 タスク名
+  - サブタスク内容
+  - **要件**: Story X
+  - **依存関係**: なし
+  - **完了条件**: [条件]（ACX.Xを満たす）
+  - **対応設計**: design.md「セクション名」
+  - **シナリオテスト**: なし（理由）
+```
+
+## 依存関係の書式
+
+| 形式 | 例 |
+|------|-----|
+| なし | `**依存関係**: なし` |
+| タスクグループ依存 | `**依存関係**: 1.1` |
+| 複数依存 | `**依存関係**: 1.2, 1.3` |
+| Phase依存 | `**依存関係**: Phase 1完了` |
+
+**使用禁止形式**: `1.1完了`、`タスク1.1`

package/presets/default/.claude/skills/einja-issue-spec-validator/SKILL.md

@@ -0,0 +1,130 @@
+# Issue仕様タスク検証 Skill
+
+## 概要
+
+このSkillは、生成されたタスク一覧のフォーマットを検証し、違反があればエラーレポートを生成します。
+
+## 責務
+
+- 生成されたタスクのフォーマット検証
+- 違反検出時にエラーレポート（Markdown形式）を生成
+- 差し戻し判定（SUCCESS / FAILURE + エラー詳細）
+
+## 使用タイミング
+
+- tasks-validator サブエージェントから呼び出される
+- einja-issue-spec-create Skillのタスク検証フェーズで使用
+- タスク生成直後に自動実行
+
+## 入力
+
+- `tasks_markdown`: 検証対象のタスク一覧（Markdown形式）
+- `retry_count`: 現在のリトライ回数（0から開始）
+- `max_retries`: 最大リトライ回数（デフォルト: 3）
+
+## 出力
+
+### 成功時
+```markdown
+## バリデーション結果: SUCCESS
+
+タスク一覧のフォーマットは正しいです。
+次のフェーズに進んでください。
+```
+
+### 失敗時
+```markdown
+## バリデーション結果: FAILURE
+
+### エラー一覧
+
+1. **タスク X.Y.Z** - [エラー種別]
+   - 問題: [問題の説明]
+   - 修正案: [具体的な修正方法]
+
+2. **行 NN** - [エラー種別]
+   - 問題: [問題の説明]
+   - 修正案: [具体的な修正方法]
+
+### リトライ情報
+- 現在の試行回数: N
+- 最大試行回数: 3
+- 残り試行回数: M
+```
+
+## 検証項目
+
+### 1. 構造検証
+- [ ] Phase番号が1から連番になっているか
+- [ ] タスクグループIDが `X.Y` 形式か
+- [ ] タスクIDが `X.Y.Z` 形式か
+
+### 2. インデント検証
+- [ ] タスクが2スペースインデントか
+- [ ] サブタスク/メタデータが4スペースインデントか
+
+### 3. メタデータ検証（タスク単位で必須）
+- [ ] **要件**: Story X
+- [ ] **依存関係**: なし / X.Y / Phase X完了
+- [ ] **完了条件**: [条件]（ACX.Xを満たす）
+- [ ] **対応設計**: design.md「セクション名」
+- [ ] **シナリオテスト**: なし（理由） / シナリオX
+
+### 4. 依存関係検証
+- [ ] 参照先のタスクグループが存在するか
+- [ ] 循環依存がないか
+- [ ] 依存関係の書式が正しいか（`X.Y完了` は不可）
+
+### 5. ATDDチェック
+- [ ] Phase数が2-3個以内か
+- [ ] タスクグループが縦切り（フルスタック）になっているか
+
+### 6. 横切り検出（最重要）
+
+**タスクグループ名に以下の禁止ワードが含まれていないか確認**：
+
+| 禁止ワード | 理由 |
+|-----------|------|
+| `Domain` | レイヤーごとの分割 |
+| `Infra` / `Infrastructure` | レイヤーごとの分割 |
+| `UseCase` / `Application` | レイヤーごとの分割 |
+| `API` / `Presentation` | レイヤーごとの分割 |
+| `UI` / `画面` / `フロントエンド` | レイヤー/画面ごとの分割 |
+| `層` | レイヤーごとの分割 |
+| `Repository` | クラスごとの分割 |
+| `Validator` | クラスごとの分割 |
+| `Entity` | クラスごとの分割 |
+| `Mapper` | クラスごとの分割 |
+| `一覧` / `詳細` / `編集` / `削除` (単体) | 画面ごとの分割 |
+
+**例外**:
+- 「ユーザー作成・編集・削除機能」のように複数をまとめた場合はOK
+- 「Domain〜UIまでフルスタック」のようにサブタスク説明に含まれる場合はOK
+- タスク名（X.Y.Z）に含まれる場合はOK（タスクグループ名のみチェック）
+
+**検出ロジック**:
+```
+タスクグループ名（X.Y 名前）の「名前」部分に禁止ワードが含まれていたらエラー
+```
+
+## エラー種別
+
+| 種別 | 説明 |
+|------|------|
+| `missing_metadata` | 必須メタデータが欠落 |
+| `invalid_indent` | インデントが不正 |
+| `invalid_id_format` | ID形式が不正 |
+| `invalid_dependency` | 依存関係の書式が不正 |
+| `missing_dependency_target` | 依存先が存在しない |
+| `too_many_phases` | Phase数が多すぎる |
+| `horizontal_split` | 横切り分割（アンチパターン） |
+| `horizontal_split_keyword` | タスクグループ名に禁止ワードが含まれる |
+
+## 関連ドキュメント
+
+- [タスク管理ガイドライン](../../../docs/einja/steering/task-management.md) - フォーマット定義（Single Source of Truth）
+- [tasks-validator サブエージェント](../../agents/einja/issue-specs/tasks-validator.md) - 呼び出し元
+
+<!-- @einja:project-private:start id="einja-issue-spec-validator-project" -->
+<!-- プロジェクト固有の情報を記入 -->
+<!-- @einja:project-private:end -->

package/presets/default/.claude/skills/einja-issue-spec-validator/references/validation-rules.md

@@ -0,0 +1,52 @@
+# バリデーションルール詳細
+
+**詳細は [タスク管理ガイドライン](../../../../docs/einja/steering/task-management.md) を参照**
+
+## 必須メタデータ一覧
+
+各タスク（X.Y.Z）に以下が必須：
+
+| メタデータ | 形式 | 例 |
+|-----------|------|-----|
+| 要件 | `**要件**: Story X` | `**要件**: Story 1` |
+| 依存関係 | `**依存関係**: なし/X.Y/Phase X完了` | `**依存関係**: 1.1` |
+| 完了条件 | `**完了条件**: [条件]（ACX.Xを満たす）` | `**完了条件**: テスト通過（AC1.1を満たす）` |
+| 対応設計 | `**対応設計**: design.md「セクション名」` | `**対応設計**: design.md「認証フロー」` |
+| シナリオテスト | `**シナリオテスト**: なし/シナリオX` | `**シナリオテスト**: シナリオ1 Step 1-3` |
+
+## 依存関係の有効形式
+
+| 形式 | 有効 | 例 |
+|------|------|-----|
+| `なし` | 有効 | `**依存関係**: なし` |
+| `X.Y` | 有効 | `**依存関係**: 1.1` |
+| `X.Y, X.Y` | 有効 | `**依存関係**: 1.2, 1.3` |
+| `Phase X完了` | 有効 | `**依存関係**: Phase 1完了` |
+| `X.Y完了` | 無効 | スクリプト認識不可 |
+| `タスクX.Y` | 無効 | スクリプト認識不可 |
+
+## インデントルール
+
+```
+### Phase 1: 名前          <- インデントなし
+- [ ] 1.1 タスクグループ名  <- インデントなし
+  - 1.1.1 タスク名         <- 2スペース
+    - サブタスク           <- 4スペース
+    - **要件**: Story 1    <- 4スペース
+```
+
+## ATDD粒度チェック
+
+| 項目 | 基準 |
+|------|------|
+| Phase数 | 2-3個（4個以上は不可） |
+| タスクグループ/Phase | 2-4個（6個以上は不可） |
+| タスクグループ分割 | 縦切り（フルスタック）のみ |
+
+## アンチパターン検出
+
+以下のパターンを検出したらエラー：
+
+1. **画面ごとの分割**: 「一覧画面」「詳細画面」「編集画面」が別タスクグループ
+2. **レイヤーごとの分割**: 「Domain層」「Infra層」「UseCase」が別タスクグループ
+3. **クラスごとの分割**: 「Entity」「Repository」「Mapper」が別タスクグループ