@einja/dev-cli 0.1.6

package/presets/minimal/.claude/commands/einja/frontend-implement.md

@@ -0,0 +1,322 @@
+---
+description: "フロントエンド実装を自動化するコマンド。architect → design-engineer → frontend-coderの順でサブエージェントを呼び出し、設計からスタイリング、実装まで一貫した開発を行います。ARGUMENTS: 機能名または要件（必須）、Figma URL（オプション）"
+allowed-tools: Task, Read, Write, Edit, MultiEdit, Bash, Grep, Glob, mcp__figma_dev_mode__*
+---
+
+# フロントエンド実装自動化コマンド
+
+## あなたの役割
+
+あなたは**フロントエンド開発のオーケストレーター**です。以下の3つの専門エージェントを連携させ、設計からスタイリング、実装まで一貫したフロントエンド開発プロセスを管理します：
+
+1. **architect** 🏗️ - コンポーネントアーキテクチャ設計
+2. **design-engineer** 🎨 - Figmaデザインシステム連携とスタイリング
+3. **frontend-coder** 💻 - 実装とテスト
+
+## 実行フロー
+
+### Phase 0: 実装戦略の確認（Phase 1前）
+
+フロントエンド実装を開始する前に、以下の戦略を確認します。
+
+#### 0.1 コンポーネント構成
+
+```yaml
+AskUserQuestion:
+  question: "コンポーネント構成をどのように設計しますか？"
+  header: "構成選択"
+  options:
+    - label: "既存パターンに従う（推奨）"
+      description: |
+        推奨理由: プロジェクトの一貫性を維持し、チーム全体の開発効率を向上させます。
+        メリット: 既存コンポーネントとの整合性が高く、チーム内での理解が容易。学習コストが最小限。
+        デメリット: 新しいパターンが必要な場合は柔軟に対応できない可能性があります。
+    - label: "Atomic Design"
+      description: |
+        atoms/molecules/organisms/templates/pagesの階層構造で設計します。
+        メリット: 再利用性が非常に高く、大規模UIシステムに向いている。デザインシステムとの親和性が高い。
+        デメリット: 学習コストが高く、過度な抽象化によりコードの追跡が困難になるリスクがあります。
+    - label: "Feature-based構成"
+      description: |
+        機能単位でファイルをまとめる構成です。
+        メリット: 機能の独立性が高く、コードの関連性が分かりやすい。機能削除時の影響範囲が明確。
+        デメリット: 共通コンポーネントの管理が複雑になり、重複コードが発生しやすくなります。
+```
+
+#### 0.2 Figmaデザイン参照
+
+```yaml
+AskUserQuestion:
+  question: "Figmaデザイン参照は利用できますか？"
+  header: "Figma連携"
+  options:
+    - label: "既存デザインシステムで対応（推奨）"
+      description: |
+        推奨理由: 既存のトークンとレシピを活用し、実装速度と一貫性を両立します。
+        メリット: 既存のトークンとレシピを再利用でき、実装が迅速。既存コンポーネントとのスタイル統一が容易。
+        デメリット: 新しいデザインパターンに対応できない場合があり、デザイントークンの手動追加が必要になります。
+    - label: "Figma URLを提供する"
+      description: |
+        design-engineerエージェントがFigma MCPでデザイントークンを自動抽出します。
+        メリット: デザインとコードの一貫性が非常に高く、デザイナーとの連携が容易。トークン抽出が自動化される。
+        デメリット: Figma MCPの設定が必要。デザイン変更の同期に手間がかかり、初期セットアップコストが高い。
+    - label: "デザイン仕様書を参照"
+      description: |
+        別途提供されたデザイン仕様書（PDF、Markdown等）に従って実装します。
+        メリット: デザイナーの意図を詳細に理解でき、仕様書が実装の根拠となる。
+        デメリット: 仕様書の解釈にばらつきが出る可能性があり、手動でトークン定義が必要になります。
+```
+
+#### 0.3 状態管理の複雑さ
+
+```yaml
+AskUserQuestion:
+  question: "状態管理の複雑さはどの程度ですか？"
+  header: "状態管理"
+  options:
+    - label: "中程度（Server State + UI State）（推奨）"
+      description: |
+        推奨理由: TanStack Queryでサーバー状態を管理し、モダンな状態管理パターンを実現します。
+        メリット: サーバー状態とUIステートが明確に分離され、キャッシュ管理が自動化される。リアルタイムデータ同期が容易。
+        デメリット: TanStack Queryの学習が必要になり、初期セットアップに時間がかかります。
+    - label: "シンプル（UI Stateのみ）"
+      description: |
+        useState、useReducerで状態管理を行います。
+        メリット: シンプルで理解しやすく、学習コストが低い。Reactの標準機能のみで実装可能。
+        デメリット: サーバーとの同期やキャッシュ管理が手動になり、大規模アプリでは保守が困難になります。
+    - label: "複雑（複数の状態層の連携）"
+      description: |
+        グローバル状態管理（Zustand、Jotai等）の追加を検討します。
+        メリット: 複雑な状態の共有が容易になり、コンポーネント間のデータ受け渡しが簡潔になる。
+        デメリット: 状態管理ライブラリの追加が必要。過度な使用は保守性を下げ、デバッグが困難になります。
+```
+
+---
+
+### フェーズ1: アーキテクチャ設計 🏗️
+
+**architect**エージェントを呼び出し：
+- コンポーネント構造の設計（Atomic Design、Feature-based構成）
+- 状態管理アーキテクチャ（TanStack Query、Form State、UI State）
+- データフロー設計（Server/Client境界、Props Drilling回避）
+- パフォーマンス戦略（コード分割、レンダリング最適化）
+- 型アーキテクチャ（共有型、コンポーネント型、API型）
+- **成果物**: Architecture Decision Record (ADR)
+
+**プロンプト例**:
+```
+機能名: {$ARGUMENTS}
+
+以下を設計してください：
+1. コンポーネント構造（ディレクトリ構成、責務分離）
+2. 状態管理戦略（Query Keys、Form State、UI State）
+3. データフロー設計（Props、Context、Server State）
+4. パフォーマンス最適化（Code Splitting、Memoization）
+5. 型定義設計（共有型、Props型、State型）
+
+ADR形式で出力してください。
+```
+
+**完了条件**: ADRドキュメントの生成完了
+
+---
+
+### フェーズ2: デザインシステム連携とスタイリング 🎨
+
+**design-engineer**エージェントを呼び出し：
+- Figma MCPでデザイン分析（Figma URLが提供された場合）
+- デザイントークンの抽出と変換
+- Panda CSS レシピの生成
+- コンポーネントバリアントの定義
+- レスポンシブデザインの実装戦略
+- **成果物**: Panda CSS設定ファイル、レシピファイル、トークン定義
+
+**プロンプト例（Figma URLあり）**:
+```
+機能名: {$ARGUMENTS}
+Figma URL: {FIGMA_URL}
+
+以下を実行してください：
+1. Figma MCPでデザインファイルを分析
+2. カラー、タイポグラフィ、スペーシングをPanda CSSトークンに変換
+3. コンポーネントバリアントをPanda CSSレシピとして生成
+4. レスポンシブブレークポイントを定義
+
+以下のファイルを生成：
+- panda.config.ts への追加設定
+- recipes/{component-name}.ts
+- tokens/{design-tokens}.ts
+```
+
+**プロンプト例（Figma URLなし）**:
+```
+機能名: {$ARGUMENTS}
+
+Architectの設計に基づき、以下を実行してください：
+1. 既存のデザイントークンを活用
+2. 必要に応じて新しいレシピを生成
+3. 一貫したスタイリング戦略を提案
+
+以下のファイルを生成：
+- recipes/{component-name}.ts（必要に応じて）
+- スタイリングガイドライン
+```
+
+**完了条件**: Panda CSS設定・レシピファイルの生成完了
+
+---
+
+### フェーズ3: 実装とテスト 💻
+
+**frontend-coder**エージェントを呼び出し：
+- Architectの設計に基づくコンポーネント実装
+- Design-Engineerのスタイリングを適用
+- TanStack QueryによるServer State管理
+- React Hook Form + Zodによるフォームバリデーション
+- Vitestによる単体テスト
+- **成果物**: 実装ファイル、テストファイル
+
+**プロンプト例**:
+```
+機能名: {$ARGUMENTS}
+
+以下のアーティファクトを基に実装してください：
+1. Architectの設計（ADR）
+2. Design-Engineerのスタイリング（Panda CSSレシピ）
+
+実装内容：
+- コンポーネント実装（TypeScript strict mode）
+- TanStack Query統合（Query Keys、Mutations）
+- フォームバリデーション（React Hook Form + Zod）
+- Vitestテスト（正常系・異常系）
+
+実装規約：
+- any型の使用禁止
+- Props型定義必須
+- エラーハンドリング実装必須
+- アクセシビリティ考慮必須
+```
+
+**完了条件**: 実装・テスト完了、型エラーなし
+
+---
+
+## 入力パラメータ
+
+### 必須
+- **機能名または要件** (`$ARGUMENTS`の1つ目)
+  - 例: "ユーザープロフィール編集画面"
+  - 例: "商品検索フィルター機能"
+  - 例: "認証フォーム（ログイン・サインアップ）"
+
+### オプション
+- **Figma URL** (`$ARGUMENTS`の2つ目)
+  - 例: "https://www.figma.com/file/..."
+  - 提供された場合: Design-EngineerがFigma MCPで分析
+  - 提供されない場合: 既存デザインシステムを活用
+
+## 実行例
+
+```bash
+# 基本的な使用方法
+frontend-implement "ユーザープロフィール編集画面"
+
+# Figma URLを含む場合
+frontend-implement "商品検索フィルター機能" "https://www.figma.com/file/abc123..."
+
+# 複雑な機能の場合
+frontend-implement "認証フロー（ログイン・サインアップ・パスワードリセット）"
+```
+
+## エージェント間の連携
+
+### Architect → Design-Engineer
+- Architectが設計したコンポーネント構造をDesign-Engineerに引き継ぐ
+- 状態管理戦略をスタイリングに反映（例: Loadingステート、Errorステート）
+
+### Design-Engineer → Frontend-Coder
+- Design-Engineerが生成したPanda CSSレシピをFrontend-Coderが使用
+- デザイントークンを型定義に反映
+
+### フィードバックループ
+- Frontend-Coderが実装中に問題発見 → Architectに設計見直しを要求
+- スタイリングが不足 → Design-Engineerに追加レシピ生成を要求
+
+## 成果物
+
+### 1. Architecture Decision Record (ADR)
+- ファイル名: `docs/adr/{YYYYMMDD}-{feature-name}.md`
+- 内容: コンポーネント設計、状態管理、データフロー、型定義
+
+### 2. Panda CSS設定・レシピ
+- ファイル: `panda.config.ts`（追加設定）
+- ファイル: `src/styled-system/recipes/{component-name}.ts`
+- ファイル: `src/styled-system/tokens/{design-tokens}.ts`（必要に応じて）
+
+### 3. 実装ファイル
+- コンポーネント: `src/components/{category}/{ComponentName}/index.tsx`
+- テスト: `src/components/{category}/{ComponentName}/ComponentName.test.tsx`
+- 型定義: `src/components/{category}/{ComponentName}/types.ts`（必要に応じて）
+
+### 4. ページ固有コンポーネント（co-location）
+- ページコンポーネント: `src/app/{page}/_components/{ComponentName}/index.tsx`
+- テスト: `src/app/{page}/_components/{ComponentName}/ComponentName.test.tsx`
+
+## 品質保証
+
+### 各フェーズでの確認事項
+
+**Architectフェーズ**:
+- [ ] コンポーネント構造が単一責任の原則に従っているか
+- [ ] 状態管理が適切に分離されているか（Server/UI/Form）
+- [ ] パフォーマンス最適化が考慮されているか
+
+**Design-Engineerフェーズ**:
+- [ ] Figmaデザインと一致しているか（URLありの場合）
+- [ ] デザイントークンが適切に抽出されているか
+- [ ] レシピがバリアントを正しく表現しているか
+
+**Frontend-Coderフェーズ**:
+- [ ] any型を使用していないか
+- [ ] Props型定義が完全か
+- [ ] テストが正常系・異常系をカバーしているか
+- [ ] アクセシビリティが考慮されているか
+
+## 注意事項
+
+### モノレポ構造への対応
+- 共有UIコンポーネント → `packages/ui/`
+- アプリ固有コンポーネント → `apps/web/src/components/`
+- ページ固有コンポーネント → `apps/web/src/app/{page}/_components/`
+
+### 技術スタック
+- Next.js 15 (App Router)
+- React 19
+- TypeScript (strict mode)
+- Panda CSS
+- TanStack Query
+- React Hook Form + Zod
+- Vitest + React Testing Library
+
+### 禁止事項
+- any型の使用
+- インラインスタイルの使用（Panda CSSを使用）
+- グローバル状態の濫用（適切な状態分離を行う）
+
+## トラブルシューティング
+
+### Figma MCP接続エラー
+- Figma URLの形式確認
+- Figma Dev ModeのアクセストークンWARN確認
+
+### Panda CSS生成エラー
+```bash
+pnpm --filter @einja/web panda codegen
+```
+
+### 型エラー
+```bash
+pnpm typecheck
+```
+
+---

package/presets/minimal/.claude/commands/einja/spec-create.md

@@ -0,0 +1,254 @@
+---
+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__*
+---
+
+# タスク仕様書作成コマンド
+
+## あなたの役割
+プロダクト開発のシニアテクニカルアーキテクト兼シニアプロダクトエンジニアとして、ATDD（受け入れテスト駆動開発）に基づく仕様書を段階的に作成します。
+
+## タスク管理
+TodoWriteツールを使用して全体の進捗を可視化し、ユーザーに現在の状況を明確に伝えます：
+- 各仕様書作成フェーズ（requirements.md、design.md、QAテスト仕様、GitHub Issueへのタスク記述）をトップレベルタスクとして管理
+- エージェント起動前にタスクを「in_progress」に更新
+- エージェント完了後に「completed」に更新
+- ユーザー承認待ちの状態も明示的に表示
+
+## 命名規則
+
+⚠️ **重要**: ディレクトリ名とブランチ名の規則は異なります。混同しないこと。
+
+| 対象 | 規則 | 例 |
+|------|------|-----|
+| ディレクトリ | `issue{issue番号}-{機能名}` | `issue42-user-management` |
+| Issueブランチ | `issue/{issue番号}` | `issue/42` |
+| Phaseブランチ | `issue/{issue番号}-phase{N}` | `issue/42-phase1` |
+
+- **ディレクトリ**: 機能名を含める（人間が識別しやすくするため）
+- **ブランチ**: Issue番号のみ（[branch-strategy.md](../docs/einja/steering/branch-strategy.md)参照）
+
+## 実行手順
+
+### 0. 前提確認フェーズ（ワークフロー開始時）
+
+**⚠️ 重要**: 仕様書作成開始前に、以下の2つの質問で前提を確認すること。
+
+#### 0.1 TDD適用判定
+
+以下のいずれかに該当する場合、TDD採用を推奨：
+- ビジネスロジックが含まれる（計算・判定・状態遷移）
+- データ変換・加工がある
+- 外部API連携がある
+- 複数の分岐・条件がある
+- 金銭・認証・権限に関わる
+
+**質問1: TDD（テスト駆動開発）を適用しますか？**
+
+```yaml
+AskUserQuestion:
+  question: "このタスクにTDD（テスト駆動開発）を適用しますか？"
+  header: "TDD選択"
+  options:
+    - label: "はい、TDDで進める（推奨）"
+      description: "推奨理由: ビジネスロジック、データ変換、外部API連携では品質向上に効果的。メリット: バグの早期発見、設計品質向上。デメリット: 初期の開発時間増加"
+    - label: "実装後にテストを追加"
+      description: "メリット: 初期の開発速度が速い。デメリット: テスト漏れのリスク、後付けテストは設計改善に繋がりにくい"
+    - label: "テスト最小限"
+      description: "メリット: 最速で動作確認可能。デメリット: 品質保証が不十分、リグレッションリスクが高い"
+```
+
+#### 0.2 要件明確さ確認
+
+**質問2: 要件の明確さを確認**
+
+以下の観点で要件を確認してください：
+- 正常系: 一番よくある使われ方は明確か？
+- 境界条件: 「ギリギリOK」と「ギリギリNG」の境目は定義されているか？
+- エラー時: エラーの場合、ユーザーにどう見せるか決まっているか？
+- 暗黙の期待: 「当たり前」だと思っていることが言語化されているか？
+
+```yaml
+AskUserQuestion:
+  question: "タスクの要件は明確ですか？"
+  header: "要件確認"
+  options:
+    - label: "明確（仕様書作成を進める）"
+      description: "メリット: 仕様書作成をスムーズに進められる。デメリット: 見落としがあると後で手戻りが発生する可能性"
+    - label: "不明確（追加質問で明確化）"
+      description: "メリット: 要件を正確に把握してから進められる。デメリット: 追加の確認時間が必要"
+```
+
+**不明確が選択された場合の対応**:
+以下の深掘り質問を実施：
+1. **正常系**: 一番よくある使われ方は？
+2. **境界条件**: 「ギリギリOK」と「ギリギリNG」の境目は？
+3. **エラー時**: エラーの場合、ユーザーにどう見せたい？
+4. **暗黙の期待**: 「当たり前」だと思っていることは？
+
+### 1. 外部リソースの確認
+
+**AsanaタスクURL**の場合：
+- AsanaMCPでタスク情報を取得（タイトル、説明、カスタムフィールド）
+- タスクIDから適切なディレクトリ名を生成
+
+**FigmaURL**が含まれる場合：
+- FigmaDevModeMCPでデザイン分析
+- UI要件、コンポーネント仕様、デザイントークンを抽出
+
+### 2. GitHub Issue作成（最初に実行）
+
+1. **GitHub IssueをMCPで作成**
+   - タイトル: ユーザー指定またはAsanaタスクから取得
+   - 本文: 空または簡易的な説明
+   - `mcp__github__create_issue` を使用
+   - **Issue番号を取得して記録**
+
+2. **Issue番号に基づいてディレクトリパスを決定**
+   - パス指定あり → 指定ディレクトリを使用
+   - パス指定なし → `/docs/specs/issues/{機能カテゴリ名}/issue{issue番号}-{機能名}/` で自動作成
+
+### 3. 段階的仕様書作成
+**重要**: 各段階で必ずユーザー承認を得て、コミット＆プッシュしてから次へ進行すること。
+
+#### Phase 1: requirements.md（要件定義書）
+1. spec-requirements-generatorエージェントで作成
+   - エージェント内で既存コードの分析を実施
+   - ATDD形式のユーザーストーリーと受け入れ基準
+2. **ユーザーに内容確認を依頼**
+   - 作成したファイルのパスと概要を提示
+   - 確認ポイントを明示（要件の過不足、受け入れ基準の明確性など）
+3. **ユーザー承認後、コミット＆プッシュ**
+   - コミットメッセージ: `docs: add requirements for {feature-name}`
+   - ブランチは現在のブランチにプッシュ
+   - 他のメンバーがレビューできるようにする
+4. **承認を得てから次のステップ（design.md）に進む**
+
+#### Phase 2: design.md（設計書）
+1. spec-design-generatorエージェントで作成
+   - エージェント内で既存アーキテクチャの調査を実施
+   - 技術アーキテクチャとデータモデル
+   - requirements.mdの内容を参照
+2. **ユーザーに内容確認を依頼**
+   - 作成したファイルのパスと概要を提示
+   - 確認ポイントを明示（アーキテクチャの妥当性、実装方針など）
+3. **ユーザー承認後、コミット＆プッシュ**
+   - コミットメッセージ: `docs: add design for {feature-name}`
+   - ブランチは現在のブランチにプッシュ
+4. **承認を得てから次のステップ（QAテスト仕様生成）に進む**
+
+#### Phase 3: QAテスト仕様生成（シナリオテスト含む）
+1. spec-qa-generatorエージェントで作成
+   - requirements.mdとdesign.mdの内容を参照
+   - **シナリオテスト（scenarios.md）**: 複数タスクをまたぐ継続操作フローのテスト仕様
+   - **フェーズ別テスト仕様**: 各タスクグループのテスト仕様
+   - 受け入れ基準（AC）との対応付け
+2. **ユーザーに内容確認を依頼**
+   - 作成したqa-tests/ディレクトリの構成と概要を提示
+   - 確認ポイントを明示（シナリオテストの網羅性、実施タイミングの妥当性など）
+3. **ユーザー承認後、コミット＆プッシュ**
+   - コミットメッセージ: `docs: add qa-test specs for {feature-name}`
+   - ブランチは現在のブランチにプッシュ
+4. **承認を得てから次のステップ（GitHub Issueへのタスク記述）に進む**
+
+#### Phase 4: GitHub Issueへのタスク記述
+1. spec-tasks-generatorエージェントで作成
+   - エージェント内で実装の影響範囲を分析
+   - 実装タスクの分解と依存関係
+   - requirements.md、design.md、**qa-tests/scenarios.md**の内容を参照
+   - 各タスクに**シナリオテスト実施タイミング**を明記
+   - **GitHub Issueの説明文にタスク一覧を記述**
+2. **ユーザーに内容確認を依頼**
+   - 更新したGitHub IssueのURL（#{issue_number}）と概要を提示
+   - 確認ポイントを明示（タスク分解の粒度、依存関係の妥当性など）
+3. **ユーザー承認後、以下の処理を実行**
+
+   a. **Issueブランチ作成（MCP）**
+   - `mcp__github__create_branch` を使用
+   - branch: `issue/{issue番号}`（例: `issue/42`）
+   - ⚠️ **機能名は含めない**（ディレクトリ名とは異なる。上記「命名規則」参照）
+   - from_branch: デフォルトブランチ（main/masterなど）
+
+   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})`
+
+   c. **PR作成（MCP）**
+   - `mcp__github__create_pull_request` を使用
+   - base: デフォルトブランチ
+   - head: `issue/{issue番号}`
+   - title: `docs: {機能名} 仕様書`
+   - body: `Issue #{issue番号} の仕様書を作成しました。`
+   - **PR URLを記録**
+
+   d. **GitHub Issue説明文を更新（MCP）**
+   - `mcp__github__issue_write` を使用（method: update）
+   - 本文に以下を含める:
+     - Spec PR へのリンク
+     - 要件ドキュメントへのリンク（requirements.mdまたはrequirements/README.md）
+     - 設計ドキュメントへのリンク（design.mdまたはdesign/README.md）
+     - QAテスト仕様へのリンク（qa-tests/scenarios.md）
+     - タスク一覧（Phase別チェックボックス形式、シナリオテスト実施タイミング明記）
+
+4. **全ての仕様書作成が完了したことを報告**
+   - GitHub Issue URLを明記
+   - Spec PR URLを明記
+
+
+### 4. 既存ファイル処理
+- 既存ファイルは内容確認後に次段階へ進行
+- 修正指示がある場合のみ該当エージェントで再生成
+
+### 4. 成果物の構成
+
+#### 基本構成（各ファイルが1000行以下の場合）
+```
+/docs/specs/issues/
+└── {機能カテゴリ名}/
+    └── issue{issue番号}-{機能名}/
+        ├── requirements.md  # 要件定義書（ATDD形式）
+        ├── design.md        # 設計書（技術詳細）
+        └── qa-tests/        # QAテスト仕様
+            ├── scenarios.md # シナリオテスト（複数タスクをまたぐフロー）
+            └── phase{N}.md  # 各フェーズのテスト仕様
+
+（注: タスク一覧はGitHub Issueに記述）
+```
+
+#### 分割構成（ファイルが1000行超過の場合）
+```
+/docs/specs/issues/
+└── {機能カテゴリ名}/
+    └── issue{issue番号}-{機能名}/
+        ├── requirements/             # 要件定義書ディレクトリ
+        │   ├── README.md            # 目次
+        │   ├── overview.md          # 概要とスコープ
+        │   ├── stories.md           # ユーザーストーリー
+        │   └── technical.md         # 技術要件
+        ├── design/                  # 設計書ディレクトリ
+        │   ├── README.md            # 目次
+        │   ├── architecture.md      # アーキテクチャ
+        │   ├── implementation.md    # 実装詳細
+        │   └── quality.md           # 品質と運用
+        └── qa-tests/                # QAテスト仕様
+            ├── scenarios.md         # シナリオテスト（複数タスクをまたぐフロー）
+            └── phase{N}.md          # 各フェーズのテスト仕様
+
+（注: タスク一覧はGitHub Issueに記述）
+```
+
+**自動分割機能**:
+- 各エージェント（requirements/design）は生成後に自動的にファイルサイズをチェック
+- 1000行を超える場合、意味のあるまとまりで2-3個のパートに自動分割
+- README.mdで全体構成とナビゲーションを提供
+- 分割されたファイルも他エージェントから正しく参照可能
+
+## 重要な原則
+- 段階的開発：各フェーズの承認を必須
+- ATDD形式による受け入れ基準の明確化
+- Next.js + Hono + Prisma技術スタック対応
+- Asana/Figma連携によるトレーサビリティ確保
+
+実行を開始します...

package/presets/minimal/.claude/commands/einja/start-dev.md

@@ -0,0 +1,98 @@
+---
+description: "ローカル開発環境を起動します"
+allowed-tools: Bash
+---
+
+# ローカル開発環境起動コマンド
+
+## コマンドの目的
+
+開発サーバーを起動します。`pnpm dev` は自動的にWorktree環境を検出し、適切なポート・DB設定を行います。
+
+**新機能**: 複数のClaude CodeやCodexセッションが並列で実行されている場合でも、ポート競合を自動解決します。
+
+## 実行手順
+
+### 通常起動（フォアグラウンド）
+```bash
+# 開発サーバー起動（Worktree対応・自動セットアップ）
+# 同じポートを使用しているプロセスがあれば自動終了してから起動
+pnpm dev
+```
+
+### バックグラウンド起動（推奨：並列セッション時）
+```bash
+# バックグラウンドで起動（ログは log/dev.log に出力）
+pnpm dev:bg
+```
+
+## 管理コマンド
+
+```bash
+# 開発サーバーの状態確認
+pnpm dev:status
+
+# ログをリアルタイムで確認
+pnpm dev:logs
+
+# 開発サーバーを停止
+pnpm dev:stop
+```
+
+## オプション
+
+| オプション | 説明 |
+|-----------|------|
+| `--background`, `-b` | バックグラウンドで起動（ログはlog/dev.logに出力） |
+| `--no-kill` | 既存プロセスを終了せずにポート競合時はエラー |
+| `--setup-only` | 環境セットアップのみ（サーバー起動なし） |
+| `--stop` | 実行中の開発サーバーを停止 |
+| `--status` | 開発サーバーのステータス表示 |
+
+## 注意事項
+
+- 初回実行時は `pnpm dev:setup` で環境セットアップが必要です
+- `pnpm dev` はWorktree環境を自動検出してポート・DB名を調整します
+- **並列実行時**: 同じポートを使用しているプロセスは自動的に終了されます
+- ログファイルは `log/dev.log` に出力されます
+
+## ターミナルから直接実行する場合
+
+### 初回セットアップ
+```bash
+pnpm dev:setup  # .env作成、DB起動・初期化
+```
+
+### 開発サーバー起動
+```bash
+pnpm dev     # フォアグラウンド（全自動・Worktree対応）
+pnpm dev:bg  # バックグラウンド（Claude Code/Codex並列実行時推奨）
+```
+
+### セットアップのみ（開発サーバーは手動起動）
+```bash
+pnpm env:prepare
+```
+
+## トラブルシューティング
+
+### ポートが解放されない場合
+```bash
+# ステータス確認
+pnpm dev:status
+
+# 強制終了
+pnpm dev:stop
+
+# 特定ポートのプロセスを確認
+lsof -i :3000
+```
+
+### ログが見たい場合
+```bash
+# リアルタイムログ
+pnpm dev:logs
+
+# または直接
+tail -f log/dev.log
+```