Prompt file imported from karasu354/team-balancer (.github/prompts/implement.prompt.md). Copyright stays with the author.

機能実装

Name: implement
Author: karasu354

操作可能範囲（明確化）

✅ 操作可能（コード実装＆テスト実装）:
  - utils/（ドメインロジック・型定義）
  - components/（UI コンポーネント）
  - composable/（API ラッパー）
  - pages/api/（API Routes）
  - test/utils/（ユニットテスト）
  - test/api/（API テスト）
  - e2e/（E2E テスト・統合テスト）
  - .steering/[対象フォルダ]/tasks.md（チェック完了マークのみ）

🔍 参照のみ（変更禁止）:
  - docs/
  - .github/copilot-instructions.md
  - .steering/[対象フォルダ]/requirements.md
  - .steering/[対象フォルダ]/design.md
  - pages/（routing の構造変更は避ける）

実行前ガード（必須）

以下をすべて満たす場合のみ実装を開始してください。

.steering/ 配下に作業フォルダが1件以上存在する
最新フォルダ（YYYYMMDD-[連番]-[機能名] で最大のもの）が特定できる
最新フォルダに requirements.md / design.md / tasks.md が存在する

上記を満たさない場合は実装を中止し、次の形式で返答してください。

実装を開始できません。
理由:
- 最新の .steering が存在しない、または requirements.md / design.md / tasks.md が不足しています。

対応:
- 先に /requirements を実行して .steering を作成してください。

この中止ケースでは、コード変更・ファイル作成を行わないこと。

実装開始前の意思決定（実装前にユーザーに確認）

以下のセクションで実装方針を複数の選択肢から選んでもらいます。

優先度・進め方の確認

📋 以下のいずれで進めますか？（◎は推奨）
   ⚠️ 全選択肢でテスト実装（ユニット / E2E / 統合テスト）は必須です。

A) ◎ デフォルト進行
   - ドメインロジック → UI → API ルートの順で実装
   - 各レイヤーごとにテストを追加・更新
   - ドキュメント（docs/ 内 API/仕様）も同時更新

B) 段階的リリース
   - まずドメインロジックのみ完成（+ 対応するユニットテスト）
   - その後 UI / API Routes を別フェーズで実装
   - 各フェーズでテスト完了・ドキュメント更新

C) 並列実装
   - utils/ と components/ を並列で進める
   - テストも並行実装（後回しにしない）
   - 最終段階で E2E テストを追加

実装開始前の仕様確認テスト（チェックリスト形式）

実装を始める前に、以下のチェックリストに答えてください。不確実な場合は実装を中止し、/requirements-update で仕様を確認してください。

ユーザーへの確認質問：

【機能要件の確認】
□ このタスクで実装する「主な機能」を1文で説明できますか？
□ 参加プレイヤー、評価ロジック、チーム数など「制約条件」を2つ以上列挙できますか？
□ このタスク完了後「プレイヤーの操作フロー」は変わりますか？ 変わる場合は簡潔に説明してください。

【API・互換性の確認】
□ 実装に伴い API スキーマ（入出力）の変更がありますか？ ある場合は `docs/team-balancer.v1.yaml` 更新が必要です。
□ `fromJson` / `playersInfo` の互換性に影響がありますか？ある場合は `utils/player.ts` で互換層を作成してください。

【テスト実装の確認】⚠️ テスト実装は必須です
□ utils/ の変更に対応するユニットテスト（test/utils/）を追加しますか？
   ➡️ 必須: 正常系・異常系・境界値を全てカバー
□ コンポーネント/UI の変更に対応する E2E テスト（e2e/）を追加しますか？
   ➡️ 必須: ユーザーのインタラクション・フローを検証
□ API Routes に変更がある場合、API テスト（test/api/）を追加しますか？
   ➡️ 必須: 入出力検証・エラーハンドリング・ステータスコードを検証

➡️ 全てにチェック＆説明できた場合のみ「実装開始」にすすむ

`.steering/` ディレクトリ内の要件・設計・タスクを参照

requirements.md — 何を実装するか（機能要件・制約）
design.md — どう実装するか（型定義・ロジック設計・コンポーネント構成）
tasks.md — どのタスクを対象とするか（未完了チェックボックスを確認）

実装完了後は、tasks.md の対応するチェックボックスを完了済みに更新してください。

実装完了時の最終確認（必須）

コミット前に、必ず以下をこの順で実行してください。

npm run format
npm run format:test
npm run typecheck
npm run test
npm run test:e2e

npm run format:test が失敗した場合は、整形・修正後に再実行する
npm run typecheck が失敗した場合は、型エラーを修正して再実行する
npm run test が失敗した場合は、失敗原因を修正して再実行する
npm run test:e2e が失敗した場合は、失敗原因を修正して再実行する
5つのコマンドが成功するまで、タスクを完了扱いにしない

このプロンプトの境界線

やること（コード実装 + テスト実装）:
- 最新 .steering の tasks.md にある未完了タスクを実装する
- ✅ 実装に対応するすべてのテストを追加・更新する（ユニット / E2E / 統合テスト）
- テスト・ドキュメント更新を行う
- 実装完了タスクを tasks.md で完了に更新する
やらないこと:
- .steering の新規作成（これは /requirements の責務）
- レビュー専用の指摘出力（これは削除済み）
- コミットメッセージ生成（これは削除済み）

実装順序

必ず以下の順で実装してください。各レイヤーが完成してから次へ進む。 ⚠️ テスト実装も含まれます。各レイヤーの実装＋テストを同時に完成させてください。

1. utils/ + test/utils/
   - ドメインロジック・型定義（TeamBalancer, Player 等）の実装
   - ユニットテスト追加・更新（境界値・正常系・異常系）

2. components/ + (e2e/関連テスト)
   - React コンポーネント（UI の描画・イベント委譲）の実装
   - E2E テスト追加・更新（UI インタラクション検証）

3. composable/ + (e2e/関連テスト)
   - API 呼び出しラッパー（composable/api.ts）の実装
   - E2E / 統合テスト追加・更新

4. pages/api/ + test/api/
   - API Routes（入力検証・Redis 操作）の実装
   - API テスト追加・更新（正常系・異常系・エラーハンドリング）

5. docs/
   - 仕様・API 仕様の更新（docs/team-balancer-spec.md / docs/team-balancer.v1.yaml）

実装ルール

TypeScript

strict: true 準拠：any 禁止、戻り値型を必ず明示
既存の型（PlayersJson, PlayerJson, Player, TeamBalancer 等）を再利用する
as キャストは原則禁止（使う場合はコメントで理由を説明）

ドメインロジック（`utils/`）

チーム分割ロジックは utils/teamBalancer.ts に集約する
プレイヤーロジックは utils/player.ts に集約する
副作用のない純粋関数のみ utils/utils.ts に置く
不変条件を守る：参加プレイヤーがちょうど10人のときのみ分割実行
評価スコアの重み（0.3 / 0.5 / 0.2）は仕様変更がない限り変更しない
fromJson / playersInfo の入出力互換性を壊さない

React コンポーネント（`components/`）

Props は必ず型定義する：interface XxxProps { ... }
イベントハンドラは型を明示する：React.MouseEvent, React.ChangeEvent 等
ビジネスロジックをコンポーネントに書かない（utils/ に委譲）
1ファイル100行以内を目安
Tailwind CSS のみ（インラインスタイル禁止）

API Routes（`pages/api/`）

入力値の型と必須項目を必ず検証する
HTTP ステータスを適切に返す（400 / 404 / 405 / 500）
機密情報・内部スタックトレースをレスポンスに含めない
API 仕様を変更した場合は docs/team-balancer.v1.yaml を同時更新する

ユニットテスト（`test/utils/` / `test/api/`）

✅ 必須: utils/ の変更には必ず対応するテストを追加・更新する
✅ 必須: 境界値を必ずカバーする：0件・10件・11件・50件
✅ 必須: 正常系・異常系・エッジケースを網羅する
✅ 必須: API Routes に変更がある場合、入出力検証・エラーハンドリングテストを追加
実行：npm run test:unit
実行：npm run test (全テスト)

E2E テスト（`e2e/`）

✅ 必須: UI コンポーネント追加・修正時は E2E テストを追加・更新する
✅ 必須: ユーザーのインタラクションフロー全体を検証する
✅ 必須: 画面遷移・フォーム入力・データ表示・エラーハンドリングをテストする
実行（通常）：npm run test:e2e
実行（ブラウザ表示）：npm run test:e2e:headed

# 機能実装 ## 操作可能範囲（明確化） ``` ✅ 操作可能（コード実装＆テスト実装）: - utils/（ドメインロジック・型定義） - components/（UI コンポーネント） - composable/（API ラッパー） - pages/api/（API Routes） - test/utils/（ユニットテスト） - test/api/（API テスト） - e2e/（E2E テスト・統合テスト） - .steering/[対象フォルダ]/tasks.md（チェック完了マークのみ） 🔍 参照のみ（変更禁止）: - docs/ - .github/copilot-instructions.md - .steering/[対象フォルダ]/requirements.md - .steering/[対象フォルダ]/design.md - pages/（routing の構造変更は避ける） ``` --- ## 実行前ガード（必須）以下をすべて満たす場合のみ実装を開始してください。 1. `.steering/` 配下に作業フォルダが1件以上存在する 2. 最新フォルダ（`YYYYMMDD-[連番]-[機能名]` で最大のもの）が特定できる 3. 最新フォルダに `requirements.md` / `design.md` / `tasks.md` が存在する上記を満たさない場合は**実装を中止**し、次の形式で返答してください。 ``` 実装を開始できません。理由: - 最新の .steering が存在しない、または requirements.md / design.md / tasks.md が不足しています。対応: - 先に /requirements を実行して .steering を作成してください。 ``` この中止ケースでは、コード変更・ファイル作成を行わないこと。 --- ## 実装開始前の意思決定（実装前にユーザーに確認）以下のセクションで実装方針を複数の選択肢から選んでもらいます。 ### 優先度・進め方の確認 ``` 📋 以下のいずれで進めますか？（◎は推奨） ⚠️ 全選択肢でテスト実装（ユニット / E2E / 統合テスト）は必須です。 A) ◎ デフォルト進行 - ドメインロジック → UI → API ルートの順で実装 - 各レイヤーごとにテストを追加・更新 - ドキュメント（docs/ 内 API/仕様）も同時更新 B) 段階的リリース - まずドメインロジックのみ完成（+ 対応するユニットテスト） - その後 UI / API Routes を別フェーズで実装 - 各フェーズでテスト完了・ドキュメント更新 C) 並列実装 - utils/ と components/ を並列で進める - テストも並行実装（後回しにしない） - 最終段階で E2E テストを追加 ``` --- ## 実装開始前の仕様確認テスト（チェックリスト形式） **実装を始める前に、以下のチェックリストに答えてください。不確実な場合は実装を中止し、`/requirements-update` で仕様を確認してください。** ユーザーへの確認質問： ``` 【機能要件の確認】 □ このタスクで実装する「主な機能」を1文で説明できますか？ □ 参加プレイヤー、評価ロジック、チーム数など「制約条件」を2つ以上列挙できますか？ □ このタスク完了後「プレイヤーの操作フロー」は変わりますか？変わる場合は簡潔に説明してください。【API・互換性の確認】 □ 実装に伴い API スキーマ（入出力）の変更がありますか？ある場合は `docs/team-balancer.v1.yaml` 更新が必要です。 □ `fromJson` / `playersInfo` の互換性に影響がありますか？ある場合は `utils/player.ts` で互換層を作成してください。【テスト実装の確認】⚠️ テスト実装は必須です □ utils/ の変更に対応するユニットテスト（test/utils/）を追加しますか？ ➡️ 必須: 正常系・異常系・境界値を全てカバー □ コンポーネント/UI の変更に対応する E2E テスト（e2e/）を追加しますか？ ➡️ 必須: ユーザーのインタラクション・フローを検証 □ API Routes に変更がある場合、API テスト（test/api/）を追加しますか？ ➡️ 必須: 入出力検証・エラーハンドリング・ステータスコードを検証 ➡️ 全てにチェック＆説明できた場合のみ「実装開始」にすすむ ``` --- ## `.steering/` ディレクトリ内の要件・設計・タスクを参照 - `requirements.md` — 何を実装するか（機能要件・制約） - `design.md` — どう実装するか（型定義・ロジック設計・コンポーネント構成） - `tasks.md` — どのタスクを対象とするか（未完了チェックボックスを確認）実装完了後は、`tasks.md` の対応するチェックボックスを完了済みに更新してください。 --- ## 実装完了時の最終確認（必須）コミット前に、必ず以下をこの順で実行してください。 ```bash npm run format npm run format:test npm run typecheck npm run test npm run test:e2e ``` - `npm run format:test` が失敗した場合は、整形・修正後に再実行する - `npm run typecheck` が失敗した場合は、型エラーを修正して再実行する - `npm run test` が失敗した場合は、失敗原因を修正して再実行する - `npm run test:e2e` が失敗した場合は、失敗原因を修正して再実行する - 5つのコマンドが成功するまで、タスクを完了扱いにしない --- ## このプロンプトの境界線 - やること（コード実装 + テスト実装）: - 最新 `.steering` の `tasks.md` にある未完了タスクを実装する - **✅ 実装に対応するすべてのテストを追加・更新する**（ユニット / E2E / 統合テスト） - テスト・ドキュメント更新を行う - 実装完了タスクを `tasks.md` で完了に更新する - やらないこと: - `.steering` の新規作成（これは `/requirements` の責務） - レビュー専用の指摘出力（これは削除済み） - コミットメッセージ生成（これは削除済み） --- ## 実装順序必ず以下の順で実装してください。各レイヤーが完成してから次へ進む。 **⚠️ テスト実装も含まれます。各レイヤーの実装＋テストを同時に完成させてください。** ``` 1. utils/ + test/utils/ - ドメインロジック・型定義（TeamBalancer, Player 等）の実装 - ユニットテスト追加・更新（境界値・正常系・異常系） 2. components/ + (e2e/関連テスト) - React コンポーネント（UI の描画・イベント委譲）の実装 - E2E テスト追加・更新（UI インタラクション検証） 3. composable/ + (e2e/関連テスト) - API 呼び出しラッパー（composable/api.ts）の実装 - E2E / 統合テスト追加・更新 4. pages/api/ + test/api/ - API Routes（入力検証・Redis 操作）の実装 - API テスト追加・更新（正常系・異常系・エラーハンドリング） 5. docs/ - 仕様・API 仕様の更新（docs/team-balancer-spec.md / docs/team-balancer.v1.yaml） ``` --- ## 実装ルール ### TypeScript - `strict: true` 準拠：`any` 禁止、戻り値型を必ず明示 - 既存の型（`PlayersJson`, `PlayerJson`, `Player`, `TeamBalancer` 等）を再利用する - `as` キャストは原則禁止（使う場合はコメントで理由を説明） ### ドメインロジック（`utils/`） - チーム分割ロジックは `utils/teamBalancer.ts` に集約する - プレイヤーロジックは `utils/player.ts` に集約する - 副作用のない純粋関数のみ `utils/utils.ts` に置く - 不変条件を守る：参加プレイヤーがちょうど10人のときのみ分割実行 - 評価スコアの重み（0.3 / 0.5 / 0.2）は仕様変更がない限り変更しない - `fromJson` / `playersInfo` の入出力互換性を壊さない ### React コンポーネント（`components/`） - Props は必ず型定義する：`interface XxxProps { ... }` - イベントハンドラは型を明示する：`React.MouseEvent`, `React.ChangeEvent` 等 - ビジネスロジックをコンポーネントに書かない（`utils/` に委譲） - 1ファイル100行以内を目安 - Tailwind CSS のみ（インラインスタイル禁止） ### API Routes（`pages/api/`） - 入力値の型と必須項目を必ず検証する - HTTP ステータスを適切に返す（400 / 404 / 405 / 500） - 機密情報・内部スタックトレースをレスポンスに含めない - API 仕様を変更した場合は `docs/team-balancer.v1.yaml` を同時更新する ### ユニットテスト（`test/utils/` / `test/api/`） - ✅ **必須**: `utils/` の変更には必ず対応するテストを追加・更新する - ✅ **必須**: 境界値を必ずカバーする：0件・10件・11件・50件 - ✅ **必須**: 正常系・異常系・エッジケースを網羅する - ✅ **必須**: API Routes に変更がある場合、入出力検証・エラーハンドリングテストを追加 - 実行：`npm run test:unit` - 実行：`npm run test` (全テスト) ### E2E テスト（`e2e/`） - ✅ **必須**: UI コンポーネント追加・修正時は E2E テストを追加・更新する - ✅ **必須**: ユーザーのインタラクションフロー全体を検証する - ✅ **必須**: 画面遷移・フォーム入力・データ表示・エラーハンドリングをテストする - 実行（通常）：`npm run test:e2e` - 実行（ブラウザ表示）：`npm run test:e2e:headed`

{ "prompt": "# 機能実装\n\n## 操作可能範囲（明確化）\n\n```\n✅ 操作可能（コード実装＆テスト実装）:\n - utils/（ドメインロジック・型定義）\n - components/（UI コンポーネント）\n - composable/（API ラッパー）\n - pages/api/（API Routes）\n - test/utils/（ユニットテスト）\n - test/api/（API テスト）\n - e2e/（E2E テスト・統合テスト）\n - .steering/[対象フォルダ]/tasks.md（チェック完了マークのみ）\n\n🔍 参照のみ（変更禁止）:\n - docs/\n - .github/copilot-instructions.md\n - .steering/[対象フォルダ]/requirements.md\n - .steering/[対象フォルダ]/design.md\n - pages/（routing の構造変更は避ける）\n```\n\n---\n\n## 実行前ガード（必須）\n\n以下をすべて満たす場合のみ実装を開始してください。\n\n1. `.steering/` 配下に作業フォルダが1件以上存在する\n2. 最新フォルダ（`YYYYMMDD-[連番]-[機能名]` で最大のもの）が特定できる\n3. 最新フォルダに `requirements.md` / `design.md` / `tasks.md` が存在する\n\n上記を満たさない場合は**実装を中止**し、次の形式で返答してください。\n\n```\n実装を開始できません。\n理由:\n- 最新の .steering が存在しない、または requirements.md / design.md / tasks.md が不足しています。\n\n対応:\n- 先に /requirements を実行して .steering を作成してください。\n```\n\nこの中止ケースでは、コード変更・ファイル作成を行わないこと。\n\n---\n\n## 実装開始前の意思決定（実装前にユーザーに確認）\n\n以下のセクションで実装方針を複数の選択肢から選んでもらいます。\n\n### 優先度・進め方の確認\n\n```\n📋 以下のいずれで進めますか？（◎は推奨）\n ⚠️ 全選択肢でテスト実装（ユニット / E2E / 統合テスト）は必須です。\n\nA) ◎ デフォルト進行\n - ドメインロジック → UI → API ルートの順で実装\n - 各レイヤーごとにテストを追加・更新\n - ドキュメント（docs/ 内 API/仕様）も同時更新\n\nB) 段階的リリース\n - まずドメインロジックのみ完成（+ 対応するユニットテスト）\n - その後 UI / API Routes を別フェーズで実装\n - 各フェーズでテスト完了・ドキュメント更新\n\nC) 並列実装\n - utils/ と components/ を並列で進める\n - テストも並行実装（後回しにしない）\n - 最終段階で E2E テストを追加\n```\n\n---\n\n## 実装開始前の仕様確認テスト（チェックリスト形式）\n\n**実装を始める前に、以下のチェックリストに答えてください。不確実な場合は実装を中止し、`/requirements-update` で仕様を確認してください。**\n\nユーザーへの確認質問：\n\n```\n【機能要件の確認】\n□ このタスクで実装する「主な機能」を1文で説明できますか？\n□ 参加プレイヤー、評価ロジック、チーム数など「制約条件」を2つ以上列挙できますか？\n□ このタスク完了後「プレイヤーの操作フロー」は変わりますか？変わる場合は簡潔に説明してください。\n\n【API・互換性の確認】\n□ 実装に伴い API スキーマ（入出力）の変更がありますか？ある場合は `docs/team-balancer.v1.yaml` 更新が必要です。\n□ `fromJson` / `playersInfo` の互換性に影響がありますか？ある場合は `utils/player.ts` で互換層を作成してください。\n\n【テスト実装の確認】⚠️ テスト実装は必須です\n□ utils/ の変更に対応するユニットテスト（test/utils/）を追加しますか？\n ➡️ 必須: 正常系・異常系・境界値を全てカバー\n□ コンポーネント/UI の変更に対応する E2E テスト（e2e/）を追加しますか？\n ➡️ 必須: ユーザーのインタラクション・フローを検証\n□ API Routes に変更がある場合、API テスト（test/api/）を追加しますか？\n ➡️ 必須: 入出力検証・エラーハンドリング・ステータスコードを検証\n\n➡️ 全てにチェック＆説明できた場合のみ「実装開始」にすすむ\n```\n\n---\n\n## `.steering/` ディレクトリ内の要件・設計・タスクを参照\n\n- `requirements.md` — 何を実装するか（機能要件・制約）\n- `design.md` — どう実装するか（型定義・ロジック設計・コンポーネント構成）\n- `tasks.md` — どのタスクを対象とするか（未完了チェックボックスを確認）\n\n実装完了後は、`tasks.md` の対応するチェックボックスを完了済みに更新してください。\n\n---\n\n## 実装完了時の最終確認（必須）\n\nコミット前に、必ず以下をこの順で実行してください。\n\n```bash\nnpm run format\nnpm run format:test\nnpm run typecheck\nnpm run test\nnpm run test:e2e\n```\n\n- `npm run format:test` が失敗した場合は、整形・修正後に再実行する\n- `npm run typecheck` が失敗した場合は、型エラーを修正して再実行する\n- `npm run test` が失敗した場合は、失敗原因を修正して再実行する\n- `npm run test:e2e` が失敗した場合は、失敗原因を修正して再実行する\n- 5つのコマンドが成功するまで、タスクを完了扱いにしない\n\n---\n\n## このプロンプトの境界線\n\n- やること（コード実装 + テスト実装）:\n - 最新 `.steering` の `tasks.md` にある未完了タスクを実装する\n - **✅ 実装に対応するすべてのテストを追加・更新する**（ユニット / E2E / 統合テスト）\n - テスト・ドキュメント更新を行う\n - 実装完了タスクを `tasks.md` で完了に更新する\n- やらないこと:\n - `.steering` の新規作成（これは `/requirements` の責務）\n - レビュー専用の指摘出力（これは削除済み）\n - コミットメッセージ生成（これは削除済み）\n\n---\n\n## 実装順序\n\n必ず以下の順で実装してください。各レイヤーが完成してから次へ進む。\n**⚠️ テスト実装も含まれます。各レイヤーの実装＋テストを同時に完成させてください。**\n\n```\n1. utils/ + test/utils/\n - ドメインロジック・型定義（TeamBalancer, Player 等）の実装\n - ユニットテスト追加・更新（境界値・正常系・異常系）\n\n2. components/ + (e2e/関連テスト)\n - React コンポーネント（UI の描画・イベント委譲）の実装\n - E2E テスト追加・更新（UI インタラクション検証）\n\n3. composable/ + (e2e/関連テスト)\n - API 呼び出しラッパー（composable/api.ts）の実装\n - E2E / 統合テスト追加・更新\n\n4. pages/api/ + test/api/\n - API Routes（入力検証・Redis 操作）の実装\n - API テスト追加・更新（正常系・異常系・エラーハンドリング）\n\n5. docs/\n - 仕様・API 仕様の更新（docs/team-balancer-spec.md / docs/team-balancer.v1.yaml）\n```\n\n---\n\n## 実装ルール\n\n### TypeScript\n\n- `strict: true` 準拠：`any` 禁止、戻り値型を必ず明示\n- 既存の型（`PlayersJson`, `PlayerJson`, `Player`, `TeamBalancer` 等）を再利用する\n- `as` キャストは原則禁止（使う場合はコメントで理由を説明）\n\n### ドメインロジック（`utils/`）\n\n- チーム分割ロジックは `utils/teamBalancer.ts` に集約する\n- プレイヤーロジックは `utils/player.ts` に集約する\n- 副作用のない純粋関数のみ `utils/utils.ts` に置く\n- 不変条件を守る：参加プレイヤーがちょうど10人のときのみ分割実行\n- 評価スコアの重み（0.3 / 0.5 / 0.2）は仕様変更がない限り変更しない\n- `fromJson` / `playersInfo` の入出力互換性を壊さない\n\n### React コンポーネント（`components/`）\n\n- Props は必ず型定義する：`interface XxxProps { ... }`\n- イベントハンドラは型を明示する：`React.MouseEvent`, `React.ChangeEvent` 等\n- ビジネスロジックをコンポーネントに書かない（`utils/` に委譲）\n- 1ファイル100行以内を目安\n- Tailwind CSS のみ（インラインスタイル禁止）\n\n### API Routes（`pages/api/`）\n\n- 入力値の型と必須項目を必ず検証する\n- HTTP ステータスを適切に返す（400 / 404 / 405 / 500）\n- 機密情報・内部スタックトレースをレスポンスに含めない\n- API 仕様を変更した場合は `docs/team-balancer.v1.yaml` を同時更新する\n\n### ユニットテスト（`test/utils/` / `test/api/`）\n\n- ✅ **必須**: `utils/` の変更には必ず対応するテストを追加・更新する\n- ✅ **必須**: 境界値を必ずカバーする：0件・10件・11件・50件\n- ✅ **必須**: 正常系・異常系・エッジケースを網羅する\n- ✅ **必須**: API Routes に変更がある場合、入出力検証・エラーハンドリングテストを追加\n- 実行：`npm run test:unit`\n- 実行：`npm run test` (全テスト)\n\n### E2E テスト（`e2e/`）\n\n- ✅ **必須**: UI コンポーネント追加・修正時は E2E テストを追加・更新する\n- ✅ **必須**: ユーザーのインタラクションフロー全体を検証する\n- ✅ **必須**: 画面遷移・フォーム入力・データ表示・エラーハンドリングをテストする\n- 実行（通常）：`npm run test:e2e`\n- 実行（ブラウザ表示）：`npm run test:e2e:headed`", "variables": [], "notes": "機能を utils → components → composable → pages/api の順で一貫して実装する", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/karasu354/team-balancer", "path": ".github/prompts/implement.prompt.md", "ref": "8497ab6e73a6c7a61c97073f0c41b6449fdb163f", "url": "https://github.com/karasu354/team-balancer/blob/8497ab6e73a6c7a61c97073f0c41b6449fdb163f/.github/prompts/implement.prompt.md", "key": "karasu354/team-balancer/.github/prompts/implement.prompt.md" } } }

implement

About

機能実装

操作可能範囲（明確化）

実行前ガード（必須）

実装開始前の意思決定（実装前にユーザーに確認）

優先度・進め方の確認

実装開始前の仕様確認テスト（チェックリスト形式）

`.steering/` ディレクトリ内の要件・設計・タスクを参照

実装完了時の最終確認（必須）

このプロンプトの境界線

実装順序

実装ルール

TypeScript

ドメインロジック（`utils/`）

React コンポーネント（`components/`）

API Routes（`pages/api/`）

ユニットテスト（`test/utils/` / `test/api/`）

E2E テスト（`e2e/`）

Use it

Manifest

Reviews

About

機能実装

操作可能範囲（明確化）

実行前ガード（必須）

実装開始前の意思決定（実装前に ユーザーに確認）

優先度・進め方の確認

実装開始前の仕様確認テスト（チェックリスト形式）

.steering/ ディレクトリ内の要件・設計・タスクを参照

実装完了時の最終確認（必須）

このプロンプトの境界線

実装順序

実装ルール

TypeScript

ドメインロジック（utils/）

React コンポーネント（components/）

API Routes（pages/api/）

ユニットテスト（test/utils/ / test/api/）

E2E テスト（e2e/）

Use it

Manifest

Reviews

実装開始前の意思決定（実装前にユーザーに確認）

`.steering/` ディレクトリ内の要件・設計・タスクを参照

ドメインロジック（`utils/`）

React コンポーネント（`components/`）

API Routes（`pages/api/`）

ユニットテスト（`test/utils/` / `test/api/`）

E2E テスト（`e2e/`）