| name | developing-frontend |
| description | フロントエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとアウトサイドインアプローチで品質の高い UI を実装する。「フロントエンドを実装したい」「画面を作りたい」「コンポーネントを追加したい」「フロントエンドのテストを書きたい」といった場面で発動する。TDD で開発することで、UI の振る舞いを自動テストで保証し、安全なリファクタリングを可能にする。 |
フロントエンド開発
TDD サイクルに従いフロントエンドを開発する。アウトサイドインアプローチ（UI 層→ロジック層→データ層）で、ユーザー視点から内側へ段階的に構築する。
アウトサイドインの利点は、ユーザーが実際に操作する画面から始めるため、不要な機能を作らずに済むこと。テストがユーザーの振る舞いに基づくため、実装の詳細に依存しにくい。
参照ドキュメント
| 種類 | パス |
|---|
| ワークフロー | @docs/reference/コーディングとテストガイド.md |
| アーキテクチャ | @docs/design/architecture_frontend.md |
| UI 設計 | @docs/design/ui-design.md |
| 技術スタック | @docs/design/tech_stack.md |
| テスト戦略 | @docs/design/test_strategy.md |
TDD サイクル
10-15 分で 1 サイクルを完了させる。サイクルが長引くなら、タスクの粒度が大きすぎる。
- Red: 失敗するテストを最初に書く
- Green: テストを通す最小限のコードを実装する
- Refactor: 重複を除去し設計を改善する
アプローチ
- アウトサイドイン（推奨）: UI から開始しロジックを段階的に実装する
- インサイドアウト: ユーティリティ/hooks から開始し上位層へ展開する
テストコマンド
cd apps/frontend && npm run test
cd apps/frontend && npm run test:watch
cd apps/frontend && npm run test:coverage
cd apps/frontend && npm run test:e2e
品質チェックリスト
コミット前に必ず確認する。
途中から再開
開発セッションの途中から再開する場合は、まず現在のテスト状態を確認する。
Example:
ユーザー: 「ログイン画面のコンポーネントは作った。バリデーションを追加したい」
回答: 既存テストを実行して Green 状態を確認する。
バリデーションの失敗するテスト（Red）を書いてから実装に進む。
ユーザーが不正な入力をした場合のエラー表示をテストする。
コンテキスト管理
タスクの区切りごとに /compact を実施して Context limit reached エラーを回避する。
- TDD サイクルを数回繰り返した後、コンポーネント完了時、コミット完了後に実施する
/compact 前に現在の作業状態と次のタスクをメモとして出力する
注意事項
- Node.js/npm のテスト環境が設定済みであること（前提条件）
- TDD の三原則を厳密に守る。テストなしでプロダクションコードを書かない
- コミット前に必ず品質チェックリストを実行する
- 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
- コンポーネントは単一責任の原則に従い小さく保つ。TODO 駆動で分割し、Rule of Three でリファクタリングする
関連スキル
developing-backend — バックエンド TDD 開発orchestrating-development — 開発フェーズ全体のワークフローgit-commit — Conventional Commits 準拠のコミット
