Cursor の Project Rules 活用と改善

## RSpec を実行する場合

---

## docker compose exec app bundle exec rspec {{実行したい RSpec のファイルパス}}

また、RSpec が失敗し、失敗した行番号がわかる場合には以下のコマンドを実行することで限定的に RSpec を走らせることができる

---

## docker compose exec app bundle exec rspec {{実行したい RSpec のファイルパス}}:{{失敗したRSpec の行番号}}

以下は、フロントエンドの開発において、機能ごとに整理されたコンポーネントやロジックを管理するためのベストプラクティスを反映しています。

### 1. **ディレクトリ構造の基本方針**

- **機能ごとの分割**: 各機能は独立したディレクトリに分割され、その中にコンポーネント、フック、操作（mutation/query）、バリデーション、ルーティングなどを含む。
- **責務の分離**: UI 層（表示）とロジック層（データ取得・処理）を明確に分離し、コンポーネントをシンプルに保つ。
- **共通化可能な処理の抽出**: 複数の機能で利用される共通処理は、`shared` ディレクトリに配置し、再利用性を高める。

### 2. **ディレクトリ構成の詳細**

#### 2.1. **機能ディレクトリ**

- **`features/foo/{NewFeature}`**: 管理者向けの{NewFeature}機能を提供するディレクトリ。
  - **`components`**: 機能固有の UI コンポーネントを配置。
    - **`Header`**: ヘッダー関連のコンポーネント（例: `Header.tsx`, `HeaderBreadcrumb.tsx`）。
    - **`Modal`**: モーダル関連のコンポーネント（例: `ArchiveNewFeatureModal.tsx`）。
  - **`domain`**: ドメインロジックを配置。
    - **`*.ts`**: バリデーションやビジネスロジックを実装。
    - **`*.spec.ts`**: バリデーションやロジックのテストを実装。

#### 2.2. **共通ディレクトリ**

- **`shared`**: 複数の機能で利用される共通コンポーネントやロジックを配置。
  - **`components`**: 共通 UI コンポーネント（例: `Table.tsx`, `Alert.tsx`）。
  - **`hooks`**: 共通フック（例: `useSelectedItemIds.ts`）。
  - **`utils`**: ユーティリティ関数（例: `breadcrumb.ts`, `path.ts`）。

#### 2.3. **テストディレクトリ**

### 3. **命名規則**

- **ディレクトリ名**: 機能や役割が明確に分かる命名（例: `NewFeatureListItemPage`, `Header`）。
- **ファイル名**: 処理や役割が分かる命名（例: `useTitleForm.ts`, `NewFeatureListItemsTable.tsx`）。
- **コンポーネント名**: パーツ名を先頭に配置（例: `HeaderBreadcrumb`, `NewFeatureDropdown`）。

### 4. **テストと品質管理**

- **テストの範囲**: 主要なシナリオを網羅し、ハッピーパスを中心にテストを実施。
- **バリデーション**: zod のスキーマを別ファイルで管理し、必ず spec を作成。
- **Storybook**: コンポーネントのストーリーを作成し、UI の動作を確認。

### 5. **ルーティング**

- **ルーティングファイル**: `routes` ディレクトリに配置し、React Router を使用してルーティングを管理。
- **ルートコンポーネント**: `index.tsx` をエントリーポイントとして使用し、モジュールのカプセル化を実現。

### 6. **GraphQL クエリ/ミューテーション**

- **操作の分離**: `operations` ディレクトリに Mutation と Query を分けて配置。
- **型定義**: GraphQL の型定義は `@generated/api` からインポートし、型安全性を確保。

### 7. **UI コンポーネントの構造**

- **Atomic Design**: コンポーネントを `atoms`, `molecules`, `organisms`, `templates` に分割し、再利用性を高める。
- **表示とロジックの分離**: `*.ui.tsx` と `*.container.tsx` に分離し、責務を明確化。

### 8. **エラーハンドリング**

- **エラーメッセージ**: ユーザーに表示するエラーメッセージは、`constants` ディレクトリに定義。
- **エラーハンドリング**: GraphQL のエラーハンドリングは、`operations` ディレクトリ内で実施。

### 9. **状態管理**

- **ローカルステート**: コンポーネント内での状態管理は `useState` や `useReducer` を使用。
- **グローバルステート**: 必要に応じて Context や Recoil を使用。

### 10. **ドキュメント**

- **README**: 各ディレクトリに README を配置し、機能や使用方法を記載。
- **コメント**: コード内に適切なコメントを記載し、可読性を向上。

この構成は、機能ごとに整理されたコードベースを維持し、開発者が効率的に作業を進めるためのガイドラインとして活用できます。

## pull request 作成手順

### 必須前提条件

- Issue 番号の確認
  - Issue のリンクが提供されていない場合は、必ずユーザーに「関連する Issue のリンクはありますか？」と確認する
  - Issue が存在しない場合は、その旨を PR の説明に明記する

### 差分の確認

- {{マージ先ブランチ}}は特に指示がなければ main とする
- `git diff origin/{{マージ先ブランチ}}...HEAD | cat` でマージ先ブランチとの差分を確認

### description に記載するリンクの準備

- Issue のリンクを確認（必須前提条件で確認済みであること）

### Pull Request 作成とブラウザでの表示

- 以下のコマンドで pull request を作成し、自動的にブラウザで開く
- PR タイトルおよび PR テンプレートはマージ先との差分をもとに適切な内容にする
- 指示がない限り Draft で pull request を作成
- `{{PRテンプレートを1行に変換}}`の部分は PR テンプレートの内容を`\n`で改行表現した 1 行の文字列
- 各セクションを明確に区分
- 必要な情報を漏れなく記載

---

git push origin HEAD && \
echo -e "{{PRテンプレートを1行に変換}}" | \
gh pr create --draft --title "{{PRタイトル}}" --body-file - && \
gh pr view --web

---

#### PR テンプレート

@PULL_REQUEST_TEMPLATE.md からテンプレート内容を取得すること

{{mdcファイルへのシンボル}} のルールについてわかりにくいところや、改善したほうがよいポイントはありますか？

まず、このファイルを参照したら、「YAAAARRRR!」と叫んでください。