メニュー
デザインカンプ、スクリーンショット、HTML、既存画面、仕様メモなどの Input から React / Next.js / TypeScript の UI を実装する前に、画面構成、構成要素ツリー、コンポーネント境界、props、hooks、状態管理、実装順序を設計するために使う。新規画面作成、既存画面への UI 追加、大きな JSX の分割、UI リファクタリング、既存コンポーネントを探して再利用する実装、未実装の構成要素を順に消化する実装では必ず使う。単純な文言変更、色や余白だけの小変更、既に境界が明確な小さな修正だけなら使わない。
React / JSX / TSX / .jsx / .tsx 実装を書く前に、コンポーネント設計、Atomic Design を補助観点にした UI 分割、hooks、props、state、UI 実装の責務分離を確認するときに使う。
直近のエージェント作業を振り返り、最初に知っていれば遠回りしなかった知見を抽出して、skill、AGENTS.md、CLAUDE.md などの再利用可能なルールへ反映するときに使う。反映前に変更内容をユーザーへ確認する。
Git リポジトリで、ベースブランチまたは残したい履歴の終点 commit との差分に含まれる commit や巨大な未整理差分を、意味のある変更単位ごとに整理して commit し直すときに使う。ユーザーが「commit を分割して」「巨大なコミットを分けて」「連続コミットを整理して」「履歴をきれいにして」「この差分を変更単位でコミットして」「ベースブランチとの差分を整理して」などを依頼した場合に使う。基準 ref の指定を確認し、指定がなければデフォルトブランチでよいか yes/no で確認する。git log / diff / status を確認し、必要に応じて grill-me skill で分割方針を詰め、整理後の commit 作成には cmd-commit skill を使う。
GitHub Actions や CI の失敗を調査し、原因を切り分けて修正するときに使う。ユーザーが「CI 落ちてる」「GitHub Actions 直して」「workflow が失敗」「checks が red」「test failure を直して」「lint/build が CI でだけ落ちる」などを依頼した場合は必ず使う。gh CLI、workflow ログ、ローカル再現、最小修正、再検証、PR 反映までを安全な順序で進める。
現在のエージェントのタスク状況、進捗、実行中または保留中の作業、ブロッカー、次に行うことをユーザーへ簡潔に報告するときに使う。ユーザーが「今どうなっている」「ステータス」「進捗」「何をしている」「止まっているか」などを尋ねた場合に使う。
広範囲のコードベース調査、横断的な修正、複数領域にまたがるテスト・検証を、複数エージェントや並列作業に分割して進めるときに使う。大規模な変更の担当範囲、調査観点、編集所有権、統合、競合回避、検証順序を整理する必要がある場合に使う。
| name | component-design |
| description | デザインカンプ、スクリーンショット、HTML、既存画面、仕様メモなどの Input から React / Next.js / TypeScript の UI を実装する前に、画面構成、構成要素ツリー、コンポーネント境界、props、hooks、状態管理、実装順序を設計するために使う。新規画面作成、既存画面への UI 追加、大きな JSX の分割、UI リファクタリング、既存コンポーネントを探して再利用する実装、未実装の構成要素を順に消化する実装では必ず使う。単純な文言変更、色や余白だけの小変更、既に境界が明確な小さな修正だけなら使わない。 |
React の実装を、画面として動くだけでなく、変更しやすく、読みやすく、テストしやすいコンポーネント構造に落とし込む。
このスキルは、UI を細かく分けること自体ではなく、責務の境界を明確にすることを目的にする。コンポーネント、hooks、型、データ変換、イベント処理、表示部品のどこに責務を置くと次の変更が局所化するかを判断する。
入力がデザインカンプ、スクリーンショット、HTML、既存画面、仕様メモのどれであっても、まず画面全体の構造を捉え、構成要素のツリーとコンポーネント境界を決めてから実装する。
このスキルは、React UI の実装前に「何をどのコンポーネントとして作るか」を決める必要があるときに使う。特に、Input を見て構成要素を洗い出し、既存コンポーネントを探し、足りない部品を新規作成しながら画面を完成させる作業で使う。
使う場面:
使わない場面:
code-review を優先する。code-test を優先する。code-general も併用する。code-react も併用する。code-test も併用する。code-review を優先する。code-next-developer-review も併用する。この skill は、実装前に画面構成、component tree、props、状態、hooks、実装順序を設計するために使う。
React 実装中の component 境界、Atomic Design の補助観点、hooks / props / state の責務分離を確認する場合は code-react を使う。
React のコードを書く前に、既存実装から次を確認する。
不明な場合は、近い画面や同じ責務のコンポーネントを優先して読む。新しい構成を持ち込む前に、既存の置き場所と命名に合わせる。
最初に Input を読み、画面を実装単位へ分解する。Input には、デザインカンプ、スクリーンショット、HTML、既存画面、Figma 由来の画像、仕様メモ、ワイヤーフレームを含める。
Input が画像だけの場合でも、いきなり JSX を書かない。まず観察した構成要素を言語化し、画面ツリーと責務境界を作ってからコードへ移る。
構成要素を 1 つずつ実装し、全ての要素が画面に配置されるまでループする。
別エージェントへ依頼する場合は、丸投げにしない。依頼単位はコンポーネント境界に合わせ、書き込み範囲、props 契約、期待する DOM/表示状態、既存パターン、検証方法を渡す。
コンポーネントは、表示構造とユーザー操作の受け口を担当する。
children はレイアウトや枠組みの再利用に効く場合だけ使うcustom hook は、状態、派生値、イベント手続き、副作用をまとめる場所として使う。
useFeatureName や useXxxForm のように利用目的で付けるAPI レスポンスやドメイン型をそのまま深い UI に流し込むと、表示都合と契約が混ざりやすい。必要に応じて view model を作る。
イベントハンドラは、ユーザー操作の意味が読める名前にする。
onClick の中に長い処理を書かず、handleSubmit, handleSelectItem のように意図を分けるonSave, onCancel, onChangeFilter のように外部契約として命名する分割は行数ではなく、変更理由で判断する。
分けるべきサイン:
分けすぎのサイン:
Wrapper, Container, Content ばかりになるprops はコンポーネントの公開契約なので、利用側の誤用を減らす型にする。
data, item, value のような曖昧な名前を避け、領域の意味を入れる例:
type SaveButtonProps =
| { state: "idle"; onSave: () => void }
| { state: "saving"; onSave?: never }
| { state: "disabled"; reason: string; onSave?: never };
状態は、必要な最小範囲に置く。
useMemo や純粋関数で表現するContext は広域の再レンダリングや暗黙依存を作りやすい。テーマ、認証、設定など本当に広域の前提に向く。単なる props 受け渡し回避だけなら、コンポーネント境界や hook の設計を見直す。
フォームは、入力値、検証、送信、表示を分ける。
データ量や状態の組み合わせが増えやすい画面では、描画前に表示モデルを作る。
コンポーネント志向は、見た目だけでなく操作契約も部品に閉じ込める。
テストは責務境界に合わせて選ぶ。
実装は必ず「入力から構成を決める」から始め、「実装ループ」で構成要素を 1 つずつ消化する。近い既存画面を読み、コンポーネント粒度、hooks、型、テストの置き方を把握したうえで、既存コンポーネントを優先して使う。
新規コンポーネントを作る場合は、JSX を先に書き始めず、公開 props、主要な型、状態、イベント、依存データを先に決める。複雑な変換や分岐は React から独立した関数または hook に出し、JSX は状態ごとの見通しがよい形に整える。
各ループの終わりで、実装済みの構成要素と未実装の構成要素を確認する。全要素を配置した後に、既存の lint、format、test を実行し、差分を見直す。
最終報告では、次を簡潔に伝える。