create-einja-app 0.1.1

package/templates/turborepo-pandacss/.cursor/commands/update-docs-by-task-specs.md

@@ -0,0 +1,448 @@
+---
+description: "タスク仕様書をfeature仕様書とsteering仕様書に反映。ARGUMENTS: タスク仕様書ディレクトリパス（複数可、カンマ区切り）"
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# タスク仕様書からドキュメント反映コマンド
+
+## あなたの役割
+
+タスク仕様書（`docs/specs/tasks/` 配下）から設計情報を抽出し、以下の2つの階層に反映する専門エージェントです：
+
+1. **Feature仕様書**（`docs/specs/features/<feature-name>/`）- 機能レベルの設計
+2. **Steering仕様書**（`docs/einja/steering/`）- プロジェクト全体の設計
+
+タスク仕様書の内容を構造化して抽出し、適切な階層のドキュメントにインテリジェントにマージします。
+
+## 実行フロー
+
+### 1. タスク仕様書の検証と読み込み
+
+**入力形式**:
+```
+/update-docs-by-task-specs <task-spec-dir-path> [<task-spec-dir-path2> ...]
+```
+
+**処理**:
+- 指定されたディレクトリパスを解析（カンマ区切り対応）
+- 各ディレクトリに以下のファイルが存在するか確認：
+  - `requirements.md`（必須）
+  - `design.md`（必須）
+  - `tasks.md`（オプション）
+- ファイルが存在しない場合はエラーを表示して終了
+- 各ファイルを読み込み、構造化された情報を抽出
+
+### 2. 機能（Feature）の判定【対話的】
+
+各タスクspecについて、どの機能（Feature）に関連するかを判定します。
+
+**判定手順**:
+1. タスクディレクトリ名とrequirements.mdの内容を分析
+2. 既存の`docs/specs/features/`ディレクトリをスキャン
+3. 以下の候補をユーザーに提示：
+   - 既存の機能（例: `login`, `signup`など）
+   - 新規機能作成（機能名を入力）
+   - Steeringのみ反映（機能specには反映しない）
+
+**AskUserQuestionを使用**:
+```
+質問: "タスク『{タスク名}』はどの機能に関連しますか？"
+選択肢:
+- login（既存）
+- signup（既存）
+- 新規機能を作成
+- Steeringのみ反映
+```
+
+### 3. Feature仕様書への反映【Task → Feature】
+
+機能が指定された場合、`docs/specs/features/<feature-name>/`に反映します。
+
+#### 3.1 機能ディレクトリの作成確認
+
+**機能specディレクトリが存在しない場合**:
+- ユーザーに確認：「機能spec『{feature-name}』を新規作成しますか？」
+- 承認されたら以下を作成：
+  ```
+  docs/specs/features/<feature-name>/
+  ├── requirements.md
+  ├── design.md
+  └── tasks.md
+  ```
+
+#### 3.2 requirements.md への反映
+
+**対象**: `docs/specs/features/<feature-name>/requirements.md`
+
+**タスクspecから抽出する情報**（`requirements.md`から）:
+- **ビジネス価値**（ビジネス価値セクション）
+- **ユーザーストーリー**（ユーザーストーリーセクション）
+- **受け入れ基準**（各ストーリーの受け入れ基準）
+- **成功指標**（成功指標セクション）
+- **非機能要件**（非機能要件セクション）
+
+**反映形式**:
+```markdown
+## タスク: {タスク名} ({日付})
+
+**反映日時**: {現在日時}
+**ソース**: {タスクspecパス}
+
+### ビジネス価値
+{抽出した内容}
+
+### ユーザーストーリー
+{抽出した内容}
+
+### 受け入れ基準
+{抽出した内容}
+
+---
+```
+
+**マージロジック**:
+- 既存内容の最後に追記（セクションが存在する場合）
+- セクションが存在しない場合は新規作成
+- 同じタスクからの重複反映を防止（タスク名+日付でチェック）
+
+#### 3.3 design.md への反映
+
+**対象**: `docs/specs/features/<feature-name>/design.md`
+
+**タスクspecから抽出する情報**（`design.md`から）:
+- **API仕様**（APIエンドポイントセクション）
+- **コンポーネント設計**（コンポーネントとインターフェースセクション）
+- **シーケンス図**（シーケンス図セクション）
+- **テスト設計**（テスト設計セクション）
+- **実装上の注意点**（実装上の注意点セクション）
+
+**反映形式**:
+```markdown
+## タスク: {タスク名} ({日付})
+
+**反映日時**: {現在日時}
+**ソース**: {タスクspecパス}
+
+### API仕様
+{抽出した内容}
+
+### コンポーネント設計
+{抽出した内容}
+
+---
+```
+
+#### 3.4 tasks.md への反映
+
+**対象**: `docs/specs/features/<feature-name>/tasks.md`
+
+**タスクspecから抽出する情報**（`tasks.md`から）:
+- タスク一覧（Phase別）
+- 依存関係情報
+- 完了基準
+
+**反映形式**:
+```markdown
+## タスク: {タスク名} ({日付})
+
+**反映日時**: {現在日時}
+**ソース**: {タスクspecパス}
+
+### 実装タスク
+{抽出したタスクリスト}
+
+---
+```
+
+### 4. Steering仕様書への反映【Task → Steering】
+
+すべてのタスクspecは、Steering仕様書にも反映されます。
+
+#### 4.1 architecture.md への反映
+
+**対象**: `docs/einja/steering/architecture.md`
+
+**タスクspecから抽出する情報**（`design.md`から）:
+- **システム構成図**（Mermaid図を含む）
+- **データフロー図**
+- **技術スタック表**
+- **パッケージ構造と依存関係**
+- **デプロイメント戦略**
+- **アーキテクチャパターン**（Clean Architecture、Repository Patternなど）
+- **開発ワークフロー**
+
+**反映形式**:
+```markdown
+## {タスク名} ({日付})
+
+**反映日時**: {現在日時}
+**ソース**: {タスクspecパス}
+
+### システム構成
+{抽出した構成図とMermaid}
+
+### 技術スタック
+{抽出した技術スタック表}
+
+### アーキテクチャパターン
+{抽出したパターン説明}
+
+---
+```
+
+**マージロジック**:
+- ファイルが空またはTODOのみの場合、目次構造を作成してから追記
+- 既存の同名セクションがある場合、タスクごとのサブセクションとして追記
+- Mermaid図は`<!-- Task: {タスク名} -->`コメントでラベル付け
+
+#### 4.2 db-design.md への反映
+
+**対象**: `docs/einja/steering/db-design.md`
+
+**タスクspecから抽出する情報**（`design.md`から）:
+- **ERD図**（Entity-Relationship Diagram）
+- **Prismaスキーマ定義**
+- **リポジトリパターン実装**
+- **データアクセス層設計**
+- **インデックス戦略**
+- **マイグレーション戦略**
+
+**反映形式**:
+```markdown
+## {タスク名} ({日付})
+
+**反映日時**: {現在日時}
+**ソース**: {タスクspecパス}
+
+### データベーススキーマ
+{抽出したスキーマ定義}
+
+### ERD
+{抽出したERD図}
+
+### リポジトリパターン
+{抽出したリポジトリ設計}
+
+---
+```
+
+#### 4.3 product.md への反映
+
+**対象**: `docs/einja/steering/product.md`
+
+**タスクspecから抽出する情報**:
+- **ビジネス価値と目標**（`requirements.md`から）
+- **ユーザーストーリー概要**（`requirements.md`から）
+- **主要API仕様**（`design.md`から）
+- **成功指標とKPI**（`requirements.md`から）
+- **タイムラインとフェーズ**（`requirements.md`から）
+
+**反映形式**:
+```markdown
+## {タスク名} ({日付})
+
+**反映日時**: {現在日時}
+**ソース**: {タスクspecパス}
+
+### ビジネス価値
+{抽出した内容}
+
+### 主要機能
+{抽出したユーザーストーリー概要}
+
+### 成功指標
+{抽出したKPI}
+
+---
+```
+
+### 5. インテリジェントマージの詳細ロジック
+
+#### 5.1 重複チェック
+
+各ファイルの先頭または各セクションで、以下のパターンを検索：
+```markdown
+## タスク: {タスク名} ({日付})
+```
+
+- 同じタスク名+日付が見つかった場合、重複として扱う
+- ユーザーに確認：「タスク『{タスク名}』は既に反映済みです。上書きしますか？」
+  - 上書き: 既存セクションを削除して新規追加
+  - スキップ: 反映をスキップ
+  - 差分マージ: 変更部分のみ更新（推奨）
+
+#### 5.2 セクション構造の維持
+
+**空ファイルまたはTODOのみの場合**:
+1. 標準的な目次構造を作成
+2. 各セクションにタスクの内容を追記
+
+**既存内容がある場合**:
+1. 既存のセクション構造を解析
+2. 対応するセクションを見つけて追記
+3. セクションが存在しない場合、適切な位置に新規作成
+
+**目次構造例（architecture.md）**:
+```markdown
+# システムアーキテクチャ
+
+## 概要
+
+## システム構成
+
+### タスク: Monorepo Setup (20251104)
+...
+
+## 技術スタック
+
+### タスク: Monorepo Setup (20251104)
+...
+
+## デプロイメント戦略
+
+### タスク: Monorepo Setup (20251104)
+...
+```
+
+#### 5.3 Mermaid図の扱い
+
+**図の識別**:
+- 各Mermaid図の直前にコメントを追加：
+  ```markdown
+  <!-- Task: {タスク名} ({日付}) -->
+  ```mermaid
+  ...
+  ```
+  ```
+
+**複数タスクの図の統合**:
+- 同種の図（例: システム構成図）が複数ある場合、並列配置
+- 重複や矛盾がある場合、ユーザーに確認して統合提案
+
+### 6. ユーザー確認・承認
+
+すべての変更内容を処理した後、以下を実行：
+
+1. **変更サマリーの表示**:
+   ```markdown
+   ## 変更サマリー
+
+   ### Feature仕様書
+   - features/login/requirements.md: 3セクション追加
+   - features/login/design.md: 5セクション追加
+
+   ### Steering仕様書
+   - steering/architecture.md: 7セクション追加
+   - steering/db-design.md: 4セクション追加
+   - steering/product.md: 3セクション追加
+   ```
+
+2. **各ファイルの詳細プレビュー**（オプション）:
+   - ユーザーが詳細を確認したい場合、各ファイルのdiffを表示
+
+3. **最終確認**:
+   - 「これらの変更を確定しますか？」
+   - 承認されたら、すべてのファイルを更新
+   - 却下された場合、変更をキャンセル
+
+### 7. エラーハンドリング
+
+**タスクspecが見つからない場合**:
+```
+エラー: タスク仕様書が見つかりません
+パス: {指定パス}
+確認事項:
+- パスが正しいか確認してください
+- requirements.md と design.md が存在するか確認してください
+```
+
+**requirements.md/design.md がない場合**:
+```
+警告: {ファイル名}が見つかりません
+タスク: {タスク名}
+対応: このタスクの反映をスキップして続行しますか？
+```
+
+**機能spec作成時の競合**:
+```
+警告: 機能spec『{feature-name}』は既に存在しますが、内容が空です
+対応: 既存ファイルを上書きして反映しますか？
+```
+
+## 重要な原則
+
+### 情報の忠実性
+- タスクspecの内容を改変せず、忠実に抽出して反映する
+- 要約や意訳は最小限にし、原文をできるだけ保持する
+- コードブロック、図表は完全な形で転記する
+
+### トレーサビリティ
+- すべての反映内容に「ソース」情報を記録する
+- タスク名と日付を明記し、後から追跡可能にする
+- 変更履歴が明確にわかるようにする
+
+### 非破壊的マージ
+- 既存の内容を削除しない（ユーザー確認がある場合を除く）
+- 追記を基本とし、上書きは最小限にする
+- 重複チェックを徹底し、不要な反復を避ける
+
+### 対話的な処理
+- 判断が必要な場合は必ずユーザーに確認する
+- 機能の判定、新規作成、重複処理などで対話する
+- 最終確認を必ず行い、ユーザーの承認を得る
+
+### 段階的な実行
+- 1つのタスクspecずつ処理する
+- 各ステップの結果を明確に表示する
+- エラーが発生しても他のタスクspecの処理を継続する
+
+## 出力フォーマット
+
+処理完了後、以下の形式でレポートを表示：
+
+```markdown
+# タスク仕様書反映完了
+
+## 処理したタスク
+1. ✅ Monorepo Setup (20251104)
+   - Feature: なし（Steeringのみ）
+   - 反映先: architecture.md, db-design.md, product.md
+
+2. ✅ Login Authentication (20251105)
+   - Feature: login
+   - 反映先: features/login/*, steering/*
+
+## 反映サマリー
+
+### Feature仕様書
+- **features/login/requirements.md**: 3セクション追加（412行）
+- **features/login/design.md**: 5セクション追加（823行）
+- **features/login/tasks.md**: 1セクション追加（156行）
+
+### Steering仕様書
+- **steering/architecture.md**: 7セクション追加（1,245行）
+- **steering/db-design.md**: 4セクション追加（567行）
+- **steering/product.md**: 3セクション追加（334行）
+
+## 次のステップ
+- 反映された内容を確認してください
+- 必要に応じて手動で調整してください
+- 変更をコミットする場合は、明確なコミットメッセージを記述してください
+```
+
+## 使用例
+
+### 例1: 単一タスクの反映
+```
+/update-docs-by-task-specs docs/specs/tasks/monorepo/20251104-monorepo-turborepo-nextjs-setup
+```
+
+### 例2: 複数タスクの反映
+```
+/update-docs-by-task-specs docs/specs/tasks/task1,docs/specs/tasks/task2,docs/specs/tasks/task3
+```
+
+### 例3: スペース区切り
+```
+/update-docs-by-task-specs docs/specs/tasks/monorepo/20251104-monorepo-turborepo-nextjs-setup docs/specs/tasks/auth/20251105-login-feature
+```

package/templates/turborepo-pandacss/.cursor/mcp.json

@@ -0,0 +1,45 @@
+{
+	"mcpServers": {
+		"vibe_kanban": {
+			"command": "npx",
+			"args": ["-y", "vibe-kanban@latest", "--mcp"]
+		},
+		"codex": {
+			"type": "stdio",
+			"command": "codex",
+			"args": ["mcp-server"]
+		},
+		"context7": {
+			"command": "npx",
+			"args": ["-y", "@upstash/context7-mcp"]
+		},
+		"playwright": {
+			"type": "stdio",
+			"command": "npx",
+			"args": ["-y", "@playwright/mcp", "--isolated"]
+		},
+		"serena": {
+			"command": "uvx",
+			"args": [
+				"--from",
+				"git+https://github.com/oraios/serena",
+				"serena-mcp-server",
+				"--context",
+				"ide-assistant",
+				".",
+				"--enable-web-dashboard=false"
+			]
+		},
+		"github": {
+			"type": "http",
+			"url": "https://api.githubcopilot.com/mcp/",
+			"headers": {
+				"Authorization": "Bearer ${GITHUB_TOKEN}"
+			}
+		},
+		"asana": {
+			"command": "npx",
+			"args": ["mcp-remote", "https://mcp.asana.com/sse"]
+		}
+	}
+}

package/templates/turborepo-pandacss/.cursor/rules/api-rules.mdc

@@ -0,0 +1,171 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# API開発ルール
+## ディレクトリ構成（1つ下の粒度の例・各階層の説明付き）
+
+```
+src/
+├── server/
+│   ├── domain/          # ドメイン層：ビジネスロジック・エンティティ・リポジトリ/サービスIF
+│   │   ├── models/        # ドメインモデル（エンティティ・値オブジェクト）
+│   │   ├── repositories/  # ドメインリポジトリインターフェース
+│   │   └── services/      # ドメインサービスインターフェース
+│   ├── application/     # アプリケーション層：ユースケース
+│   │   └── useCases/      # ユースケース実装
+│   ├── infrastructure/  # インフラ層: DB・外部サービス連携・マッパー
+│   │   ├── adapters/      # 外部サービス・DB接続ラッパー
+│   │   ├── repositories/  # ドメインリポジトリIFの実装（DBアクセス等）
+│   │   ├── prisma/        # Prisma関連（Client, Repository, schema, migrations）
+│   │   ├── mapper/        # 型変換の責務を担う（DB型・外部サービスの型 ⇔ ドメイン型）
+│   │   └── config/        # 環境変数・設定
+│   └── presentations/   # プレゼンテーション層: Honoアプリ（各botやWebhookのハンドラ）
+└── app/
+    └── api/             # Next.js App RouterのAPIエンドポイント
+```
+
+
+
+#### 原則
+- ドメイン層は外部の型に依存しない
+  - 外部の型をimportしない
+  - 外部の型を知らない
+- アプリケーション層（UseCase）は型変換を行わない
+  - 型変換はインフラ層のMapperに委譲
+  - ビジネスロジックに集中
+- インフラ層のAdapterは必要に応じてMapperを使用
+  - 外部サービスとの通信時に型変換
+  - DB操作時に型変換
+- 型変換のロジックはMapper層に集約
+  - 重複を避ける
+  - 一貫性を保つ
+  - テスト容易性を確保
+
+# API設計
+
+## RESTful API
+- リソースベースのURL設計
+- HTTPメソッドの適切な使用
+- ステータスコードの適切な使用
+
+## エンドポイント命名規則
+- 複数形の名詞を使用
+- 小文字のハイフン区切り
+- バージョン管理はURLに含める
+
+## リクエスト/レスポンス
+- JSON形式を使用
+- 日時はISO 8601形式
+- エラーレスポンスは統一フォーマット
+
+
+# HonoによるAPI実装ルール
+
+## 実装ルール
+- Honoの`app`インスタンスは`src/server/presentations/xxx/index.ts`で定義し、**メソッドチェーン形式で記述すること**
+- APIエンドポイント（`src/app/api/**/route.ts`）では`handle(app)`でHonoアプリをエクスポート
+- ルーティングはHonoの`app.route()`や`app.use()`を活用し、botごとに分岐
+- 共通ミドルウェア（署名検証・Webhookパース等）は`src/server/presentations/middleware/`に実装し、`app.use()`で適用
+- API仕様コメントはJSDoc形式で`app.post()`等の直前に記載
+
+## 記載例
+```ts
+// src/server/presentations/line-webhook/index.ts
+const app = new Hono<{ Variables: { rawBody: string } }>()
+  .use('*', createLineWebhookMiddleware())
+  /**
+   * @endpoint POST /api/webhook/line/:channelId
+   * @description LINEのWebhookエンドポイント。チャンネルIDをパラメータとして受け取り、対応するチャンネルのメッセージを処理する
+   */
+  .post('/api/webhook/line/:channelId', async (c) => {
+    const channelId = c.req.param('channelId');
+
+export default app;
+```
+
+## 命名・記法
+- ファイル名・ディレクトリ名はkebab-case
+- Honoの`app`インスタンス名は`app`で統一
+- ミドルウェアは`createXxxMiddleware`で命名
+- presentation層の各ファイル先頭に、対応APIエンドポイントをコメントで明記
+
+## レイヤー間の依存関係
+- 外側のレイヤーは内側のレイヤーに依存
+- 依存性逆転の原則を適用
+- インターフェースを介して通信
+
+
+# レイヤードアーキテクチャ
+## ユースケース（UseCase）実装方針
+
+- ユースケースはオブジェクトリテラル形式でexportする（例：`export const XxxUseCase = { ... }`）
+- メソッド単位でasync関数を定義する（例：`processMessage: async (...) => { ... }`）
+- 依存リポジトリやアダプタは直接importして利用し、引数で渡すDIは原則使わない
+- ユースケース名は「XxxUseCase」とする
+
+## domain層 設計方針
+- モデルはinterface＋クラス（IUser, UserModel等）、不変性・ファクトリメソッド重視
+- リポジトリ/サービスはinterfaceで定義し、ドメインモデルを引数・返り値に使う
+- ドメイン層はビジネスロジック・エンティティ・リポジトリ/サービスIFのみ、インフラ層の実装には依存しない
+- 責務分離を徹底
+
+## Domain層とInfra層の責務分離
+
+- Domain層はビジネスロジック・エンティティ・リポジトリインターフェースのみを持つ
+- Infra層はDBアクセス・外部サービス連携・リポジトリ実装のみを持つ
+- Domain層→Infra層への依存はinterface経由で行い、逆依存は持たない
+
+## infra層 設計方針
+- adapters/: 外部サービスやDB接続のラッパー（MongoAdapter, LineAdapter, OpenAIAdapter等）
+- repositories/: ドメイン層インターフェースを実装するリポジトリ（オブジェクトリテラル形式でexport、DBアクセス・外部サービス連携のみ責務、変換はinfra/mapperで行う）
+- prisma/: PrismaClient, PrismaUserRepository, schema.prisma, migrations等
+- mapper/: DB型⇔ドメイン型の変換（userMapper等）
+- config/: 環境変数や設定
+- アダプタは接続・状態管理を担い、オブジェクトリテラル形式でexport
+- PrismaClientはシングルトン、型は@prisma/clientからimport、変換はmapperで行う
+
+### Prisma利用方針
+- Prismaの型（User, UserCreateInput, UserUpdateInput等）は@prisma/clientからimportして利用する
+- DBから取得した値はUser型（PrismaUser型）として扱い、ドメインモデルへの変換はMapper経由で行う
+- Prismaの自動生成フィールド（id, createdAt, updatedAt）はcreate時に省略し、取得時のみ利用する
+- PrismaClientは開発環境のみシングルトン化し、型は@prisma/clientからimport、変換はmapperで行う
+
+### Mapper設計方針
+#### 責務
+- ドメイン層とインフラ層間の型変換に関するすべての責務を担う
+- ドメイン層は外部の型（DB・外部サービス）を知らない
+- 変換の種類：
+  - DB型 ⇔ ドメイン型
+  - 外部サービスSDKの型 ⇔ ドメイン型
+  - APIレスポンス/リクエスト型 ⇔ ドメイン型
+- ORMによる自動生成型（Prismaを用いてるUserドメインの場合、UserCreateInput, UserUpdateInput等）を返却型として明示し、型安全を担保する
+- MapperはDB型→ドメイン型に変換する関数（toModel）、ドメイン型→Prisma入力型（prismaの場合は`toPrismaCreate`/`toPrismaUpdate`）など用途ごとに明確に分割する
+
+
+#### 命名規則
+- `xxxMapper.ts`の形式（例：`messageMapper.ts`, `userMapper.ts`）
+- 変換メソッドは`toXxx`の形式（例：`toCoreMessages`, `toPrismaUser`）
+
+# セキュリティ
+
+## データ保護
+- 入力値のバリデーション
+- SQLインジェクション対策
+- XSS対策
+
+# パフォーマンス
+
+## キャッシュ戦略
+- 適切なキャッシュヘッダーの設定
+- CDNの活用
+- データベースクエリの最適化
+
+## モニタリング
+- ログの適切な出力
+- エラートレースの実装
+- パフォーマンスメトリクスの収集
+
+
+