create-einja-app 0.1.1

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

@@ -0,0 +1,181 @@
+---
+description: 
+globs: 
+alwaysApply: false
+---
+# APIテストルール
+
+## Vitest
+VitestはVite公式の高速なユニットテスト・モック・カバレッジツールです。本プロジェクトではAPI層・ドメイン層・ユースケース層・プレゼンテーション層のテストに利用します。
+
+### 主な特徴・メリット
+- Viteと同じビルド基盤を利用し、テストの起動・実行が非常に高速
+- Jest互換API（describe, it, expect, vi など）で、Jest経験者もすぐに使える
+- TypeScriptとの親和性が高い（型推論・型チェックが強力）
+- モック・スナップショット・カバレッジ・UIテストなど多機能
+- ホットリロード対応でTDDや開発体験が良い
+
+### 環境変数
+- テスト時は`APP_ENV=test`とする
+- 環境変数の設定は`vite.config.ts`ファイルに記載されており、テスト実行時にこのファイルが読み込まれる
+
+
+## テストファイルの配置
+コロケーションパターンで配置する
+```
+src/
+└── server/
+    ├── application/
+    │   └── useCases/
+    │       └── {機能名}/
+    │           ├── UseCase.ts          # 実装
+    │           └── UseCase.test.ts     # テスト
+    ├── domain/
+    │   └── models/
+    │       └── {モデル名}/
+    │           ├── Model.ts            # 実装
+    │           └── Model.test.ts       # テスト
+    └── presentations/
+        └── {機能名}/
+            ├── index.ts                # 実装
+            └── index.test.ts           # テスト
+```
+
+### ファイル命名規則
+- 実装ファイルと同じディレクトリに配置
+- ファイル名は `{実装ファイル名}.test.ts`
+- インテグレーションテストは `{実装ファイル名}.integration.test.ts`
+
+## テストの構造
+
+### テストケースの分類
+```typescript
+describe('機能名', () => {
+  describe('正常系', () => {
+    it('期待する動作の説明', async () => {
+      // テストケース
+    });
+  });
+
+  describe('異常系', () => {
+    it('エラーケースの説明', async () => {
+      // テストケース
+    });
+  });
+});
+```
+
+### テストケースの命名
+- 正常系: 期待する動作を日本語で記述
+    - 例: `新規ユーザーの場合、会話を作成して応答を返すこと`
+- 異常系: エラーの種類と期待する動作を日本語で記述
+    - 例: `MongoDBとの接続エラー時にエラーをスローすること`
+
+## モック化のルール
+
+### 外部依存のモック
+- データベース接続
+- 外部APIリクエスト
+- 環境変数
+- 現在時刻
+
+```typescript
+// モックの例
+vi.mock(
+  '@/server/infrastructure/repositories/MongoLineMessageHistoryRepository',
+  () => ({
+    MongoLineMessageHistoryRepository: {
+      findByUserId: vi.fn(),
+      addMessage: vi.fn(),
+    },
+  }),
+);
+```
+
+### テストデータ
+- テストデータは各テストファイル内で定義
+- 共通のテストデータファクトリーや、テスト用共通ロジックは/src/server/tests内に配置
+- データは最小限の内容に留める
+
+## アサーション
+
+### 基本ルール
+- 1つのテストケースにつき、1つの機能をテスト
+- 複数の条件を確認する場合は、個別のテストケースに分割
+- エッジケースを必ずテスト
+- **テスト作成後は、必ずtestが通るかを確認**
+
+### アサーションの種類
+- 値の比較: `expect(result).toBe(expected)`
+- オブジェクトの比較: `expect(result).toEqual(expected)`
+- 関数呼び出しの確認: `expect(mockFn).toHaveBeenCalled()`
+- エラーの確認: `expect(promise).rejects.toThrow()`
+
+## APIエンドポイントのテスト
+
+### エンドポイントテストの構造
+```typescript
+describe('APIエンドポイント', () => {
+  describe('POST /api/webhook/line/{botId}', () => {
+    it('正常なリクエストの場合、200を返すこと', async () => {
+      const response = await fetch(url, {
+        method: 'POST',
+        headers: {
+          'Content-Type': 'application/json',
+          'x-line-signature': 'test',
+        },
+        body: JSON.stringify({
+          events: [{
+            type: 'message',
+            message: { type: 'text', text: 'こんにちは' },
+            source: { userId: 'test-user' },
+            replyToken: 'test-token',
+          }],
+        }),
+      });
+
+      expect(response.status).toBe(200);
+      expect(await response.json()).toEqual({ status: 'ok' });
+    });
+  });
+});
+```
+
+### テストすべき項目
+1. 正常系
+    - 正常なリクエストに対する応答
+    - ペイロードの処理
+    - ヘッダーの検証
+
+2. 異常系
+    - 不正なリクエストボディ
+    - 必須ヘッダーの欠落
+    - 認証エラー
+    - バリデーションエラー
+
+3. エッジケース
+    - 空のペイロード
+    - 大きなペイロード
+    - 特殊文字を含むメッセージ
+
+## テストの実行
+
+### 実行コマンド
+```bash
+# 全てのテストを実行
+npm test
+
+# 特定のテストファイルを実行
+npm test path/to/test.ts
+
+# 監視モードで実行
+npm test -- --watch
+
+# カバレッジレポートを生成
+npm test -- --coverage
+```
+
+### CI/CD
+- プルリクエスト時に全テストを実行
+- カバレッジが80%未満の場合はビルドを失敗させる
+- テスト失敗時はマージを禁止

package/templates/turborepo-pandacss/.cursor/rules/base-code.mdc

@@ -0,0 +1,70 @@
+---
+description: コード規約 - コーディング規約とリファクタリング方針
+globs: ["src/**/*.ts", "src/**/*.tsx"]
+alwaysApply: true
+---
+# コード規約
+## ディレクトリ構造
+```
+src/
+├── app/              # Next.js App Router
+├── components/       # 共通コンポーネント
+├── lib/             # ユーティリティ関数
+├── styles/          # スタイル関連
+└── types/           # 型定義
+```
+
+## コーディング規約
+
+### 命名規則
+- ファイル名: kebab-case
+- コンポーネント名: PascalCase
+- 変数・関数名: camelCase
+- 定数: UPPER_SNAKE_CASE
+- 型・インターフェース: PascalCase
+
+### コードスタイル
+- インデント: 2スペース
+- セミコロン: 必須
+- クォート: シングルクォート
+- 行の長さ: 100文字以内
+- if文などの1行ブロックでも必ず中括弧（{}）を付けること（省略禁止）
+  - 例: NG → `if (user) return user;` / OK → `if (user) { return user; }`
+
+### importパス
+- 相対パス（`../../`）は使用禁止
+- `@/`を使用した絶対パスを使用
+  - 例: `import { Component } from '@/components/Component'`
+  - 例: `import { useHook } from '@/hooks/useHook'`
+
+### 型定義
+- 明示的な型アノテーションを使用
+- anyは使用禁止
+- インターフェースはIプレフィックスを使用
+- 型定義はtypesディレクトリに集約
+
+## ツール設定
+
+### TypeScript
+- strictモードを有効化
+- 型チェックはビルド時に実行
+- 型定義は可能な限り厳密に
+
+# 使用パッケージ一覧
+**パッケージを更新したらこの一覧を必ず更新することをCursorから提案してください**
+- TypeScript: 型安全な開発のためのメイン言語
+- Next.js: フロントエンド/SSR/ルーティング
+- React, react-dom: UIコンポーネント・SPA開発
+- Prisma (@prisma/client, prisma): ORM・DBマイグレーション・型生成
+- Vitest, @vitest/ui, @vitest/coverage-v8: ユニットテスト・モック・テストランナー
+- Vite: フロントエンド開発環境・ビルドツール
+- dotenv, dotenv-cli: 環境変数管理
+- Biome (@biomejs/biome): Lint/Format/型チェック統合ツール
+- Hono, @hono/node-server: APIサーバ・ミドルウェア
+- MongoDB, mongoose: NoSQLデータベース・ODM
+- @line/bot-sdk: LINE Messaging API連携
+- openai: OpenAI API連携
+- axios: HTTPクライアント
+- eslint, eslint-config-next: Lintルール
+- @types/*: 型定義パッケージ
+- その他: 必要に応じて各層で利用するパッケージを適宜追加

package/templates/turborepo-pandacss/.cursor/rules/base-commit-rules.mdc

@@ -0,0 +1,174 @@
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# コミットルール
+## コミット分割ルールの厳守について
+
+- コミット分割ルールに違反した場合、重大なレビュープロセス阻害・履歴管理上の問題となるため、**絶対に違反しないこと**。
+- 万一違反が発生した場合は、必ず即座に報告し、再発防止策（作業前の分割計画明示・コミット粒度の事前確認など）を徹底すること。
+- 「まとめコミット」「複数目的の混在コミット」「コミット粒度の過剰肥大化」は**厳禁**。
+- このルールは全開発者・AIアシスタントが例外なく厳守すること。
+
+## コミットの流れ
+- 「コミット前の確認事項」を参照してコミットに入れる常態か確認
+- `git pull --rebase`で最新化
+- git statusでコンテキストを確認
+- 差分を「コミットの分割方針」に応じて分割し、具体的なコミット分割とその内容、コミットメッセージの合意を取る
+  - 分割された各コミットの内容は「コミット内容の確認事項」に留意する
+- 合意したコミット方針でコミットを行う
+- 忘れずに`git push`を行う
+
+### コミットの分割方針
+以下の場合は**必ず別々のコミットに分割してください**。違反した場合、重大なレビュープロセス阻害・履歴管理上の問題となるため、**絶対に違反しないこと**。万一違反が発生した場合は、必ず即座に報告し、再発防止策（作業前の分割計画明示・コミット粒度の事前確認など）を徹底すること。「まとめコミット」「複数目的の混在コミット」「コミット粒度の過剰肥大化」は**厳禁**。このルールは全開発者・AIアシスタントが例外なく厳守すること。
+
+1. 異なる目的や種類の変更
+   - ソースコードの変更とドキュメントの更新
+   - 機能追加と設定ファイルの変更
+   - リファクタリングとバグ修正
+
+2. 異なるコンポーネントやモジュールの変更
+   - 複数のマイクロサービスやコンポーネントの変更
+   - フロントエンドとバックエンドの変更
+   - インフラ構成とアプリケーションコードの変更
+
+3. レビューの容易さを考慮した分割
+   - 大規模な変更は小さな論理的なまとまりに分割
+   - 設定変更とその設定を使用するコードの変更は分割
+   - テストコードの追加・更新は実装とは別のコミット
+
+### コミット分割の具体例
+
+以下のような変更がある場合：
+- ディレクトリ構造の変更
+- 実装の修正
+- テストの追加
+- 設定ファイルの更新
+- ドキュメントの追加
+
+このように分割します：
+
+1. 構造的な変更
+```bash
+git commit -m "refactor: ディレクトリ構造の整理
+
+- 関連するファイルを適切なディレクトリに移動
+- 不要なファイルの削除
+- ファイル名の統一"
+```
+
+2. 実装の修正
+```bash
+git commit -m "fix: 実装の修正
+
+- バグの修正内容
+- 影響範囲
+- 修正理由"
+```
+
+3. テストの追加
+```bash
+git commit -m "test: テストの追加
+
+- 追加したテストの概要
+- テストでカバーする機能や条件
+- 既存テストの修正点"
+```
+
+4. 設定の更新
+```bash
+git commit -m "chore: 設定ファイルの更新
+
+- 更新した設定項目
+- 更新理由
+- 影響範囲"
+```
+
+5. ドキュメントの追加
+```bash
+git commit -m "docs: ドキュメントの追加
+
+- 追加したドキュメントの概要
+- 主な内容
+- 参照すべき関連ドキュメント"
+```
+
+### コミットメッセージの形式
+- プレフィックス: `feat:`, `fix:`, `docs:`, `style:`, `refactor:`, `test:`, `chore:`
+- 日本語で記述
+- 1行目に概要、2行目以降に詳細を記述
+
+プレフィックスの使い分け：
+- `feat:` : 新機能の追加
+- `fix:` : バグ修正
+- `docs:` : ドキュメントの更新
+- `style:` : コードスタイルの修正（フォーマット等）
+- `refactor:` : リファクタリング
+- `test:` : テストの追加・修正
+- `chore:` : ビルドプロセスやツールの変更
+
+### コミットメッセージの例
+
+良い例：
+```bash
+feat: ユーザー認証機能の追加
+
+- JWT認証の実装
+- ログイン・ログアウトエンドポイントの追加
+- 認証ミドルウェアの実装
+- テストケースの追加
+
+影響範囲：
+- /auth/*エンドポイント
+- ミドルウェア
+- ユーザーモデル
+```
+
+悪い例：
+```bash
+update files  # 変更内容が不明確
+
+fix some bugs  # 具体的な修正内容が不明
+
+various changes  # 変更の種類や目的が不明確
+```
+
+### コミットの粒度と単位
+- 1つのコミットは1つの論理的な変更のみを含める
+- 機能追加やバグ修正は1つずつコミット
+- リファクタリングは機能変更と分けてコミット
+- 複数のファイルを変更する場合も、関連する変更は1つのコミットにまとめる
+- 1つのコミットの変更量は、レビューしやすい程度（100行程度）に抑える
+- **コミット粒度の過剰肥大化・まとめコミットは禁止。違反時は必ず即座に報告し、再発防止策を徹底すること。**
+
+### コミットのタイミング
+- 機能の実装が完了した時点でコミット
+- テストが通る状態でコミット
+- 1日の作業終了時には必ずコミット
+- 他の開発者と共有する前にコミット
+- 大きな変更は小分けにしてコミット
+- **コミットタイミングの逸脱やまとめコミットは禁止。**
+
+### コミット前の確認事項
+- コードがコンパイルできる状態か
+- テストが通る状態か
+- 不要なデバッグコードやコメントが残っていないか
+
+### コミット内容の確認事項
+- 変更内容がコミットメッセージと一致しているか
+- 適切な粒度で分割されているか
+- 関連する変更が漏れなくコミットされているか
+
+### ブランチ戦略
+- main: 本番環境用
+- develop: 開発環境用
+- feature/*: 機能開発用
+- hotfix/*: 緊急修正用
+
+### コミット分割ルールの厳守について
+
+- 上記コミット分割ルールに違反した場合、重大なレビュープロセス阻害・履歴管理上の問題となるため、**絶対に違反しないこと**。
+- 万一違反が発生した場合は、必ず即座に報告し、再発防止策（作業前の分割計画明示・コミット粒度の事前確認など）を徹底すること。
+- 「まとめコミット」「複数目的の混在コミット」「コミット粒度の過剰肥大化」は**厳禁**。
+- このルールは全開発者・AIアシスタントが例外なく厳守すること。

package/templates/turborepo-pandacss/.cursor/rules/base-design.mdc

@@ -0,0 +1,12 @@
+---
+description:
+globs:
+alwaysApply: true
+---
+# デザインルール
+**画面の表示を修正する際は必ず守ってください**
+
+# MCP確認
+- figmaのURLを渡されたら、MCPでfigmaのデザインを確認して再現してください。
+- 画像の素材はMCPでダウンロードして適用してください。（絶対パス指定でダウンロードすること）
+-

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

@@ -0,0 +1,231 @@
+---
+description: 基本開発ルール - すべての作業で遵守すべき基本ルール
+globs: ["**/*"]
+alwaysApply: true
+---
+# 基本開発ルール
+## 重要：このルールは必ず守ってください
+
+**このルールファイルの内容は、すべての作業において絶対的に遵守する必要があります。**
+**ルールを無視したり、一部のみを適用したりすることは禁止されています。**
+
+### ルール確認プロセス
+1. 作業開始前に、必ずこのルールファイルを最初に確認してください
+2. ルールの内容を理解し、すべての項目を遵守してください
+3. ルールに従った作業計画を立ててください
+4. 計画をユーザーに提示し、承認を得てください
+
+**ルールを確認していない場合は、作業を開始しないでください。**
+
+## 障害対応・再発防止の基本理念（Cursor/AIアシスタント向け）
+
+- 作業の進め方や運用プロセスについてユーザーから指摘・指導、rulesの記載と行動の矛盾が発覚した場合、それを**Cursorにとって「障害」**と捉えること。
+- 指摘内容を「一時的な例外」や「その場限りの対応」とせず、**必ずrulesファイル（.mdc等）を更新し、次回以降の進め方に再現性を持たせる**こと。
+- **絶対に再発を防止することを基本理念とし、ルールファイルの更新・運用徹底を最優先で行動すること。**
+- ルール更新後は、以降の全作業で新ルールを厳守し、同様の指摘が二度と発生しないよう徹底する。
+
+# 作業の着手の流れ
+
+あなたは高度な問題解決能力を持つ AI アシスタントです。タスクを効率的かつ正確に実行するために、以下の指示に従ってください。
+
+まず、ユーザーから受け取った指示を確認します：
+
+<instructions>
+{{instructions}}
+</instructions>
+
+以下の指示に基づいて、以下のプロセスを進めてください：
+
+---
+
+
+## 0. 作業開始準備
+
+`git status` で現在の git のコンテキストを確認します。
+差分が存在する場合は、「.cursor/rules/base-commit-rules.mdc」のコミットルールに従い、コミットを実行してください。
+コミットの後は、pushも実行します。
+
+**もし未コミットの差分がある場合、即座にコミット作業に入り、指示された内容についての作業（「0. 作業開始準備」より後の作業）は開始しないでください。**
+
+## 1. 指示分析と計画、修正方針の確認
+
+### タスク分析
+**このセクションは必ず実行してください。省略や簡略化は禁止されています。**
+
+タスク実行の前に、以下のタスク分析を必ず行ってください。
+分析結果をもとに修正方針の確認を行い、実行してよいかどうかユーザに判断を仰いでください。
+ただし、APIエンドポイントやディレクトリ構成、既存実装のread系調査（list_dir, read_file, codebase_search, file_search, grep_search など）は、ユーザー確認なしで自律的に実行すること。
+
+**確認なしで勝手に修正作業を開始しないでください**
+**また、分析の途中で既存ファイルや公式ドキュメントの調査が必要と判明した場合は分析の途中でもすぐに調査を開始し、その後タスク分析を継続すること**
+
+```
+## タスク内容の整理
+目的、依頼内容をまず整理してください。
+明らかな不明点や不足情報がある場合はその時点ですぐに問いかけを行ってください。
+
+## 既存実装の確認
+- 修正を行う前に、既存実装はどのようになっているか調査を行うこと
+- 実装方針を合わせるため、実装を修正するファイルと同ディレクトリのファイルも確認して方針を踏襲すること
+- 例
+  - 環境変数を追加する場合は、環境変数は現状どのような仕組みで適用されてるか確認する
+  - APIを実装する場合は、修正・作成する層のファイルと同じ階層のファイルをいくつか確認し、実装ルールを確認する
+- タスク分析全体の完了を待たずにこの時点で即座に調査を行い、結果を出力
+
+**実装確認はタスク分析完了した後に回さず、確認完了してから先の分析結果出力に進んでください。**
+
+このセクションは後続のプロセス全体を導くものなので、十分な時間をかけてください。徹底的かつ包括的な分析を行ってください。
+
+
+## 関連情報の確認
+- SDKやフレームワーク等、特定のパッケージに依存する修正を行う場合は、公式ドキュメントを確認してから修正を行うこと
+  - 最初に確認を忘れた場合でも、エラーが起こった際などは自発的に確認すること
+- タスク分析全体の完了を待たずにこの時点で即座に調査を行い、結果を出力
+
+**関連情報の確認作業はタスク分析完了した後に回さず、確認完了してから先の分析結果出力に進んでください。**
+
+このセクションは後続のプロセス全体を導くものなので、十分な時間をかけてください。徹底的かつ包括的な分析を行ってください。
+
+
+## 重複実装の防止
+
+- 実装前に以下を調査し、修正対象箇所の判断を行ってください。
+  - 類似機能の存在
+  - 同一または類似の名前を持つ関数やコンポーネント
+  - 重複する API エンドポイント
+  - 共有できるプロセスの特定
+  - 修正しようとしている内容をすでに行っているファイルの探索
+- タスク分析全体の完了を待たずにこの時点で即座に調査を行い、結果を出力
+
+**重複実装の防止の確認作業はタスク分析完了した後に回さず、確認完了してから先の分析結果出力に進んでください。**
+
+このセクションは後続のプロセス全体を導くものなので、十分な時間をかけてください。徹底的かつ包括的な分析を行ってください。
+
+## 水平展開
+- 実装方針を修正する場合、同じ実装方針の箇所を探索し、水平展開対象を探索
+- 例
+   - パスや名称の修正を行ったら、修正されたパスや名称が使われている箇所を探索して修正対象とする
+   - APIのある層の実装課題を修正したら、同じ層の別ファイルにも同様の実装課題がある箇所を探索して、修正対象とする
+- タスク分析全体の完了を待たずにこの時点で即座に調査を行い、水平展開対象を出力
+
+**水平展開の確認作業はタスク分析完了した後に回さず、確認完了してから先の分析結果出力に進んでください。**
+
+
+## 修正対象の明示
+分析した内容を踏まえて、修正対象となるファイルや画面を簡潔に整理してください
+
+## 実装方針
+分析した内容を踏まえて、実装方針を簡潔に整理してください
+
+## 対応ステップ
+- タスク実行にあたり必要な作業をステップ化してまとめる
+```
+
+## 2. タスク実行
+
+- 特定されたステップを一つずつ実行する
+- 各ステップを完了した後、進捗を簡潔に報告する
+- 実装中は以下の点に注意する：
+  - 適切なディレクトリ構造の遵守
+  - わからないものがあれば @web を使用して適宜検索を行うこと
+  - 命名規則の一貫性
+  - 共有プロセスの適切な配置
+- タスク実行の中で、コミットルールに応じてコミットを提案・実行すること
+
+---
+
+## 3. 品質管理と問題解決
+
+- 各ステップのタスクの実装後、**必ず動作確認・検証記録を行い、その結果を明示的に報告すること**
+  - テストの実行、APIのcurl打鍵確認など
+      - 開発サーバの再起動を行う場合は、 すでに起動している開発サーバのプロセスをkillしてから起動を行うこと。
+      - 例）```pkill next && npm run dev```
+      - ただし、NextJSの場合は原則はホットリードが適用されるため、明らかに修正が反映されていない場合以外再起動は不要
+  - 動作確認方法がわからない場合は、ユーザに確認方法を質問すること**動作確認・検証記録をスキップして4. 最終確認に進まないこと**
+
+- エラーや不整合が発生した場合は、以下のプロセスで対処する：
+  - 問題の分離と原因特定（ログ分析、デバッグ情報の確認）
+    - SDKやフレームワークに依存するエラーであれば、公式ドキュメントの確認や、Webで同様の事例がないかの確認を実施
+  - 修正方針の提案（ユーザに確認をとる）
+  - 対策の作成と実装
+  - 修正後の動作検証
+  - （さらにエラーが発生したら繰り返し）
+
+- 検証結果を以下の形式で記録する：
+  a. 検証項目と期待される結果
+  b. 実際の結果と相違点
+  c. 必要な対策（該当する場合）
+
+
+## 4.ドキュメントの修正
+- .cursor/rules以下の.mdcファイルについて、以下に該当する場合は修正を実施する
+- 新規機能追加時、新規ディレクトリ追加時
+- ディレクトリ構造、アーキテクチャ変更時
+- 新規パッケージインストール時や、パッケージ削除・変更時
+- rulesファイルの記載と異なる指示があったとき
+- cursorのタスク実行の進め方に指摘があったとき
+
+
+## 5. 最終確認
+
+- すべてのタスクが完了したら、成果物全体を評価する
+- 動作確認が完了していない場合は「## 3. 品質管理と問題解決」に戻る
+- 元の指示との一貫性を確認し、必要に応じて調整を行う
+- コミットルールに従い、コミットを提案する
+
+
+## 6. 結果報告
+
+最終結果を以下の形式で報告してください：
+
+<最終結果>
+
+# 実行結果報告
+
+## 概要
+
+[全体的な要約の簡単な説明]
+
+## 実行ステップ
+
+1. [ステップ 1 の説明と結果]
+2. [ステップ 2 の説明と結果]
+   ...
+
+## 最終成果物
+
+[成果物の詳細、該当する場合はリンク]
+
+## 問題解決（該当する場合）
+
+- 遭遇した問題と対応
+- 今後の検討事項
+
+## 注記と改善提案
+
+- [観察事項や改善提案をリストアップ]
+  - 例
+    - 作業を進める中で、後回しにした事項や、懸念事項事項
+    - より堅牢、高セキュリティになる案
+    - リファクタリング方針（refactor-rules.mdc）に従ったリファクタリング案
+
+
+## 重要な注意事項
+
+- 既存の関連コードは指示がなくても確認する
+- 不明点がある場合は、作業を始める前に必ず確認する
+- 重要な決定や既存設計の変更が発生した場合は報告し、承認を得る
+  - 既存実装が場所によって複数の方針で実装されている場合はどの方針で実装するか確認する
+- 予期しない問題が発生した場合は直ちに報告し、解決策を提案する
+- **明示的に指示されていない変更は行わないでください。** 変更が必要と思われる場合は、まず提案として報告し、承認を得た後にのみ実装する
+- **UI/UX デザインの変更（レイアウト、色、フォント、間隔など）は**、正当な理由を提示して承認を得た後でない限り**禁止されています**
+- **技術スタックに記載されているバージョン**（API、フレームワーク、ライブラリなど）を**勝手に変更しないでください**。変更が必要な場合は、理由を明確に説明し、承認を待ってから変更を行ってください
+
+
+## コミット分割の提案
+- git statusで差分を確認する
+- 発生した差分を、次項目にbase-rules.mdc内に記載されている「コミットルール」に基づいて、どのようなコミットメッセージのコミットにわけ、どのファイルをコミットに含めるのかの方針を立てて記載する
+- 修正内容と、コミット分割に問題がなかった場合、ユーザの承諾を得たらコミット、pushを行うように反応を促すこと
+
+
+</最終結果>