Skill.md検索

React・Next.js のコンポーネントをTypeScript で記述する際に、統一された規約に基づいた実装を自動チェック・生成できます。 アロー関数のみの実装、Readonly 型の強制、配列の readonly 化などの規約を厳密に適用します。 Server Components（純粋関数・副作用なし）と Client Components（hooks必要な場合のみ）の使い分けを自動判定し、適切な実装パターンを提案します。 Server Actions を neverthrow の Result 型で返すなど、エラーハンドリングの規約を統一します。 ファイル構成（src/app/、src/features/など）の推奨レイアウトに基づき、機能の整理・配置をガイドします。 React・Next.js で大規模プロジェクトを進めており、チーム全体の実装スタイルを統一したい方 TypeScript の型安全性と函数型プログラミングのベストプラクティスを重視する方 Server Components と Client Components の使い分けに迷っている Next.js ユーザー Server Actions のエラーハンドリングを堅牢に設計したい方 このスキルは React・Next.js の実装規約を以下のルールで定めます。コンポーネント はアロー関数のみ、class コンポーネントと React.FC は禁止。Props は Readonly の type alias（interface 非推奨）で定義し、配列は常に readonly とします。Hooks は useMemo などで依存配列を厳密に管理。State は常に不変（setItems((prev) => [...prev, ...]) パターン）。イベントハンドラ は実装を handle 接頭辞、props を on 接頭辞で統一。Server Components（App Router デフォルト）は純粋・副作用なし・hooks なしとし、データは直接 fetch。Client Components は "use client" を最小限に、末端に配置。Server Actions は neverthrow の Result で返却し、境界でバリデーション実施。プロジェクト構成は src/app/（ルート）、src/features/（純粋ロジック+actions）、src/ui/（UI共有）、src/lib/（ユーティリティ）に整理。

アプリUIとプレビュー領域で異なるスタイリング手法を正確に使い分けられます。 Tailwind CSS v4のユーティリティクラスを使ってアプリUIの見た目を効率的に構築できます。 プレビュー領域ではinline styles（React.CSSProperties）でユーザーが操作するスタイル属性を柔軟に適用できます。 TailwindとCSSの混在による不具合を根本的に防ぎ、コードの一貫性を保ちやすくなります。 React + Tailwind CSS v4でUIコンポーネントを実装するフロントエンド開発者 タイポグラフィやスタイルプレビュー機能を作る開発者 Tailwindとinlineスタイルをどちらにするか判断に迷う方 コンポーネント設計時のスタイリングルールを明確にしたい方 スタイリング規約は、Tailwind CSS v4とinline stylesの厳密な使い分けを定めています。アプリUIの領域（ヘッダー、コントロールパネル、ボタン、レイアウト）ではTailwindユーティリティクラスを使用し、プレビュー領域ではinline styles（React.CSSProperties）でユーザー操作対象のスタイルのみ適用します。両者を混在させることは禁止です。Tailwindはレスポンシブブレークポイントやdarkモードプレフィックスに対応し、カスタム値は[]記法で指定します。プレビュー領域のコンテナ（レイアウト、パディング、背景色）はTailwind使用が許可されますが、ユーザーが操作するCSSプロパティのみstyle属性で設定します。@applyやプレビューへのTailwindクラス、アプリUIへのinline styles使用は禁止パターンです。

コミットメッセージを統一フォーマット（Conventional Commits形式）で自動生成し、チーム内の品質にばらつきがなくなります 日本語で「何を変更したか」を明確に記録でき、後から変更理由がすぐに分かります APIの仕様変更など破壊的な変更を明確にマークできるため、他チームメンバーへの影響を一目で判断できます コミット前の差分（dff）確認が自動ガイドされるため、意図しない変更をプッシュするミスが減ります 複数人でGitを使用しており、コミットメッセージのルールを統一したい開発チーム コードレビュー時にコミット履歴から変更背景をすぐに理解したい人 自動生成ツールやリリースノートの品質を上げたいプロジェクトマネージャー Conventional Commits形式に基づき、日本語でコミットメッセージを作成します。フォーマットは (): で、scopeとbodyは任意、subjectは50文字以内を目安に簡潔に記載します。typeは feat（新機能）、fix（バグ修正）、refactor（リファクタリング）、style（フォーマット）、docs（ドキュメント）、test（テスト）、chore（ビルド・CI）、perf（パフォーマンス）の8種類から選択します。bodyは「なぜ」を箇条書きで記載し、破壊的変更は type の後ろに "!" を付与し body に "BREAKING CHANGE:" を記載します。ルールとして、1コミット = 1つの論理的変更、WIPコミットは chore: WIP で仮置き、コミット前に git diff --staged で確認、Co-Authored-By 行は一切禁止とします。

テスト駆動開発（TDD）のRed → Green → Refactorサイクルに従うことで、思わぬバグを事前に防ぎ、後からの修正コストを削減できます。 実装を始める前にテストを書くことで、仕様を明確にしながら開発を進めることができ、後々の要件変更時の対応も容易になります。 テストが常に通った状態を保ちながらコードを改善（リファクタリング）できるため、安心して古いコードを新しく書き直せます。 新しい機能追加やバグ修正の時に同じワークフローを繰り返すことで、チーム全体の品質標準を統一できます。 バグを減らしたい、品質の高いコードを書きたいプログラマー チームメンバーのコード品質を統一したい開発リーダー レガシーコード（古く複雑なコード）を安全にリファクタリングしたい保守担当者 長期的に保守しやすいコードベースを作りたい全てのエンジニア

Vitestを使ったTypeScriptテストの書き方を統一することで、すべてのテストが理解しやすく、修正しやすい状態を保つことができます。 純関数、非同期処理（ResultAsync）、Reactコンポーネントなど、異なる種類の機能に応じた適切なテスト方法をAIが提案し、効率的なテスト設計ができます。 ユーザーの実際の操作を再現するテスト（Testing Library）により、実装の詳細に左右されない堅牢なテストが書けるため、リファクタリング時のテスト修正を最小化できます。 モック（疑似オブジェクト）の使用ルールを明確にすることで、本来テストすべき部分に集中でき、テストの保守コストを削減できます。 テストコードの品質にばらつきがあるチーム TypeScriptのテスト規約を統一したいプロジェクトマネージャー テストの保守に時間がかかっていると感じる開発チーム 新しいテストコードを書く際の「どう書くか」を統一したい全てのエンジニア

型安全性を自動で厳格に管理 — Readonly型やブランド型などの型ルールが自動適用され、予期しないバグを防げます エラーハンドリングを統一 — Result型（neverthrow）でエラーをハンドリング（スロー例外をしない）し、予測可能なコードになります 不変性パターンを自動遵守 — 配列やオブジェクトを修正（ミューテーション）せず、新しい値を生成するパターンが自動で適用されます 命名・インポート・関数形式を統一 — アロー関数の使用、適切なスコープ管理など、チーム全体で一貫したコードスタイルを維持できます TypeScriptを使ったフロントエンド・バックエンド開発者：このルール集を導入すれば、コードレビューの時間を短縮でき、品質の高いコードが自動的にチェックされます エラーハンドリングを厳密にしたいプロジェクトチーム：例外スロー（throw）を避け、エラー情報を構造化して返すパターンで、予測可能な処理フローが実現できます 関数型プログラミングを導入したいが、ルールが曖昧なチーム：スコープ別に厳格度を変えることで、バランスの取れた開発が可能になります