mcpField
S
solid-nextjs

solid-nextjs

github.com/fusengine開発3448 回インストール2 週間前に更新
リポジトリ

solid-nextjs について

Next.js 16向けにSOLIDとDRYの設計指針を示すスキルです。コード構成と品質を整えたい開発者向けに、原則別のガイド、テンプレート、実装前の調査とコードベース確認の手順を提供します。

主な機能

  1. 01ファイル長とモジュール構成の規定
  2. 02型を独立したinterfacesディレクトリに配置
  3. 03エクスポートへのJSDocを必須化
  4. 045つのSOLID原則のガイド
  5. 0523種類のコードテンプレート

活用シーン

  1. 01機能モジュールとコアディレクトリの設計
  2. 02長すぎるページやコンポーネントの分割
  3. 03サービス、フック、APIルートのテンプレート選定
  4. 04実装前のドキュメントと既存コードの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/fusengine/agents --skill solid-nextjs

インストール後、Claude Code で/solid-nextjsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
architecture-patterns.md
dependency-inversion.md
interface-segregation.md
liskov-substitution.md
open-closed.md
single-responsibility.md
solid-principles.md
references/templates/
action.md
adapter.md
api-route.md
client-component.md
error.md
factory.md
hook.md
i18n.md
interface.md
middleware.md
prisma.md
query.md
server-component.md
service.md
store.md
test.md
validator.md

詳細

Next.js 16 プロジェクトで SOLID と DRY のアーキテクチャを徹底します。100 行未満（ページは 50 行未満、サーバーコンポーネントは 80 行未満、クライアントコンポーネントは 60 行未満、サーバーアクションは 30 行未満）のファイル、`interfaces/` ディレクトリへの型の分離（コンポーネントやページには記述しない）、エクスポートへの JSDoc の必須化、`module`／`modules/cores/` ディレクトリ構成を徹底します。コードを書く前に、現在の年を含めて Context7／Exa を使い、最新の Next.js／React／Prisma のドキュメントを調査することを必須とします。また、新しいユーティリティを作成する前に、既存のユーティリティを grep で検索します。

SOLID の各原則に対応した専用のリファレンスガイド（SRP のファイル分割、OCP のコンポジション／プラグインパターン、LSP の契約遵守、ISP の役割別インターフェース、DIP のコンストラクターインジェクション／ファクトリー）に加え、コンポーネント、フック、サービス、ストア、サーバーアクション、API ルート、バリデーター、Prisma シングルトン、i18n、クエリを網羅する、そのままコピーして使える 23 種類のテンプレートを提供します。これは複数の領域にまたがるコード品質向上のためのスキルであり、機能実装用のスキルではありません。Next.js の API 自体については、nextjs-16 および関連するスキルを参照してください。

SOLID Next.js - モジュラーアーキテクチャ

現在の日付（重要）

今日は 2026 年 1 月です — 検索には必ず現在の年を使用してください。 「2025」または「2026」を指定して検索し、過去の年は絶対に指定しないでください。

必須：コーディング前の調査

重要：コードを書く前に、まず今日の日付を確認し、ドキュメントとウェブを検索してください。

  1. Context7 を使用して Next.js／React の公式ドキュメントを調査します
  2. Exa のウェブ検索で現在の年の最新動向を調査します
  3. 当年の Vercel Blog を確認して新機能を調査します
  4. Next.js 16 との互換性についてパッケージのバージョンを確認します

検索クエリ（YYYY は現在の年に置き換えてください）：

  • Next.js [feature] YYYY best practices
  • React 19 [component] YYYY
  • TypeScript [pattern] YYYY
  • Prisma 7 [feature] YYYY

コードベースの分析（必須）

実装を始める前に必ず行うこと：

  1. プロジェクトの構造を調べ、アーキテクチャを把握します
  2. 関連する既存ファイルを読み、確立されたパターンに従います
  3. 使用されている命名規則、コーディングスタイル、パターンを特定します
  4. データフローと依存関係を把握します

DRY - 再利用または共有化（必須）

新しいコードを書く前に必ず行うこと：

  1. コードベースを grep で検索し、似た関数名、パターン、ロジックを探します
  2. 共有ディレクトリを確認します：modules/cores/lib/、modules/cores/components/、modules/cores/hooks/
  3. 似たコードがある場合 → 重複させず、拡張または再利用します
  4. 2 つ以上の機能で使うコードは → modules/cores/ に直接作成します
  5. 繰り返し出てくるロジック（3 回以上）は共有ヘルパーに切り出します
  6. 新しいファイルを作成した後に npx jscpd ./src --threshold 3 を実行します

エージェントのワークフロー（必須）

実装を始める前に、並行して 3 つのエージェントを起動します。それぞれに name を指定して、Agent を 1 回ずつ呼び出します。

  1. fuse-ai-pilot:explore-codebase - プロジェクトの構造と既存のパターンを分析します
  2. fuse-ai-pilot:research-expert - スタック内のすべての技術について最新ドキュメントを確認します
  3. mcp__context7__query-docs - 統合の互換性を確認します

実装後、検証のために fuse-ai-pilot:sniper を実行します。

絶対ルール（必須）

1. ファイルは 100 行未満
  • 90 行で分割します — 100 行を超えてはいけません
  • ページコンポーネントは 50 行未満（コンポジションを使用）
  • サーバーコンポーネントは 80 行未満
  • クライアントコンポーネントは 60 行未満
  • サーバーアクションはそれぞれ 30 行未満
2. モジュラーアーキテクチャ

機能モジュールと cores ディレクトリを含む完全な構成については、references/architecture-patterns.md を参照してください。

3. JSDoc の必須化
/**
 * Fetch user by ID from database.
 *
 * @param id - User unique identifier
 * @returns User object or null if not found
 * @throws DatabaseError on connection failure
 */
export async function getUserById(id: string): Promise<User | null>
4. インターフェースの分離
modules/auth/src/
├── interfaces/          # Types ONLY
│   ├── user.interface.ts
│   └── session.interface.ts
├── services/            # NO types here
└── components/          # NO types here

SOLID 原則（詳細ガイド）

各 SOLID 原則には、専用のリファレンスガイドがあります。

  1. references/single-responsibility.md - 1 つのクラス／関数につき、変更する理由は 1 つ

    • 90 行でのファイル分割（ページは 50 行未満、コンポーネントは 60 行未満、サービスは 80 行未満）
    • コンポーネントの合成パターン
    • Next.js のページとサーバーアクションの例

  2. references/open-closed.md - 変更ではなく、合成によって拡張する

    • プラグインアーキテクチャのパターン
    • 複数の実装に対応するプロバイダーパターン
    • アダプターとストラテジーのパターン
    • 既存コードを変更せずに機能を追加する方法

  3. references/liskov-substitution.md - 契約の遵守と振る舞いのサブタイピング

    • サブタイプは基底型と置き換え可能であること
    • 例外と戻り値の型に関する契約
    • LSP の遵守をテストする方法

  4. references/interface-segregation.md - 1 つの肥大化したインターフェースより、多数の目的を絞ったインターフェースを使う

    • ロールベースのインターフェース
    • 肥大化した契約を避ける方法
    • クライアント固有のインターフェース

  5. references/dependency-inversion.md - 実装ではなく、抽象に依存する

    • コンストラクターインジェクションのパターン
    • 生成に使うファクトリーパターン
    • IoC コンテナー
    • テストで簡単にモックできるようにする方法

概要とクイックリファレンスについては、references/solid-principles.md を参照してください。

コードテンプレート

references/templates/ に、すぐにコピーして使えるコードがあります。

テンプレート用途
server-component.mdデータ取得を行うサーバーコンポーネント
client-component.mdフックを使うクライアントコンポーネント
service.md依存性注入を使うサービス
hook.md状態を持つ React フック
interface.mdTypeScript インターフェース
store.md永続化機能付きの Zustand ストア
action.md検証機能付きのサーバーアクション
api-route.mdAPI ルートハンドラー
validator.mdZod の検証スキーマ
factory.mdファクトリーパターン
adapter.mdアダプターパターン
error.mdカスタムエラークラス
test.mdテストテンプレート
middleware.md認証ミドルウェア
prisma.mdPrisma シングルトン
i18n.md機能／グローバル翻訳
query.mdデータベースクエリ（Prisma 7）

応答ガイドライン

  1. まず調査する - 必須：コードを書く前に、必ず Context7 と Exa を検索する
  2. コード全体を示す - 断片ではなく、動作する例を示す
  3. 判断の理由を説明する - 他の選択肢よりこのパターンを選ぶ理由を説明する
  4. テストを含める - 常にテストケースを提案する
  5. エラーに対処する - 決して無視せず、エラーバウンダリーを使う
  6. すべてに型を付ける - 完全な TypeScript を使い、any は使わない
  7. コードを文書化する - 複雑な関数には JSDoc を付ける

禁止事項

  • ❌ ドキュメントを調査せずにコーディングすること（必ず調査する）
  • ❌ 現行年のドキュメントを確認せず、古い API を使うこと
  • ❌ 100 行を超えるファイル
  • ❌ コンポーネントファイル内のインターフェース
  • ❌ app/ ページ内のビジネスロジック
  • ❌ コンポーネント内でのデータベースへの直接呼び出し
  • ❌ モジュールが別のモジュールをインポートすること（コアを除く）
  • ❌ デフォルトで 'use client' を使うこと
  • ❌ データ取得に useEffect を使うこと
  • ❌ エクスポートに JSDoc がないこと
  • ❌ any 型
  • ❌ バレルエクスポート
  • ❌ 既存のユーティリティ／ヘルパーを複製する前に Grep で検索しないこと
  • ❌ 共通関数に切り出さず、ロジックのブロックをコピー＆ペーストすること

コメント

Markdown 対応