folder-structure-blueprint-generator

プロジェクトフォルダ構造ブループリントジェネレーター

設定変数

${PROJECT_TYPE="Auto-detect|.NET|Java|React|Angular|Python|Node.js|Flutter|Other"}

${INCLUDES_MICROSERVICES="Auto-detect|true|false"}

${INCLUDES_FRONTEND="Auto-detect|true|false"}

${IS_MONOREPO="Auto-detect|true|false"}

${VISUALIZATION_STYLE="ASCII|Markdown List|Table"}

${DEPTH_LEVEL=1-5}

${INCLUDE_FILE_COUNTS=true|false}

${INCLUDE_GENERATED_FOLDERS=true|false}

${INCLUDE_FILE_PATTERNS=true|false}

${INCLUDE_TEMPLATES=true|false}

生成されたプロンプト

"プロジェクトのフォルダ構造を分析し、一貫したコード構成を維持するための決定版ガイドとして機能する包括的な「Project_Folders_Structure_Blueprint.md」ドキュメントを作成してください。以下のアプローチを使用します:

初回の自動検出フェーズ

${PROJECT_TYPE == "Auto-detect" ? "まず、プロジェクトの種類を識別する主要なファイルがないかフォルダ構造をスキャンします:

• .NET プロジェクトを識別するためにソリューション/プロジェクトファイル (.sln、.csproj、.fsproj、.vbproj) を探します
• Java プロジェクトのビルドファイル (pom.xml、build.gradle、settings.gradle) を確認します
• JavaScript/TypeScript プロジェクトの依存関係を含む package.json を識別します
• 特定のフレームワークファイル (angular.json、react-scripts のエントリ、next.config.js) を探します
• Python プロジェクトの識別子 (requirements.txt、setup.py、pyproject.toml) を確認します
• モバイルアプリの識別子 (pubspec.yaml、android/ios フォルダ) を調べます
• 見つかったすべてのテクノロジーの特徴とそのバージョンを記録します" : "${PROJECT_TYPE} プロジェクト構造に分析を集中させます"}

${IS_MONOREPO == "Auto-detect" ? "以下を確認して、これがモノレポであるかどうかを判断します:

• 独自の設定ファイルを持つ複数の異なるプロジェクト
• ワークスペース設定ファイル (lerna.json、nx.json、turborepo.json など)
• プロジェクト間の参照と共有依存関係のパターン
• ルートレベルのオーケストレーションスクリプトと設定" : ""}

${INCLUDES_MICROSERVICES == "Auto-detect" ? "マイクロサービスアーキテクチャの指標を確認します:

• 類似した/繰り返しの構造を持つ複数のサービスディレクトリ
• サービス固有の Dockerfile またはデプロイ設定
• サービス間の通信パターン (API、メッセージブローカー)
• サービスレジストリまたはディスカバリの設定
• API ゲートウェイの設定ファイル
• サービス間で共有されるライブラリまたはユーティリティ" : ""}

${INCLUDES_FRONTEND == "Auto-detect" ? "以下を探してフロントエンドコンポーネントを識別します:

• Web アセットディレクトリ (wwwroot、public、dist、static)
• UI フレームワークファイル (コンポーネント、モジュール、ページ)
• フロントエンドのビルド設定 (webpack、vite、rollup など)
• スタイルシートの構成 (CSS、SCSS、styled-components)
• 静的アセットの構成 (画像、フォント、アイコン)" : ""}

1. 構造の概要

${PROJECT_TYPE == "Auto-detect" ? "検出されたプロジェクトの種類" : PROJECT_TYPE} プロジェクトの構成原則とフォルダ構造の高レベルの概要を提供します:

• フォルダ構造に反映されている全体的なアーキテクチャアプローチを文書化します
• 主な構成原則 (機能別、レイヤー別、ドメイン別など) を特定します
• コードベース全体で繰り返される構造パターンを記録します
• 推測できる場合は、構造の背後にある根拠を文書化します

${IS_MONOREPO == "Auto-detect" ? "モノレポであると検出された場合は、モノレポがどのように構成されているか、およびプロジェクト間の関係を説明します。" : IS_MONOREPO ? "モノレポがどのように構成されているか、およびプロジェクト間の関係を説明します。" : ""}

${INCLUDES_MICROSERVICES == "Auto-detect" ? "マイクロサービスが検出された場合は、それらがどのように構造化され、構成されているかを説明します。" : INCLUDES_MICROSERVICES ? "マイクロサービスがどのように構造化され、構成されているかを説明します。" : ""}

2. ディレクトリの可視化

${VISUALIZATION_STYLE == "ASCII" ? "フォルダ階層を深さレベル ${DEPTH_LEVEL} まで ASCII ツリー表現で作成します。" : ""}

${VISUALIZATION_STYLE == "Markdown List" ? "ネストされた Markdown リストを使用して、フォルダ階層を深さレベル ${DEPTH_LEVEL} まで表現します。" : ""}

${VISUALIZATION_STYLE == "Table" ? "Path、Purpose、Content Types、Conventions の列を持つテーブルを作成します。" : ""}

${INCLUDE_GENERATED_FOLDERS ? "生成されたフォルダを含むすべてのフォルダを含めます。" : "bin/、obj/、node_modules/ などの自動生成フォルダを除外します。"}

3. 主要なディレクトリの分析

重要度の高い各ディレクトリの目的、内容、パターンを文書化します。

${PROJECT_TYPE == "Auto-detect" ? "検出された各テクノロジーについて、観察された使用パターンに基づいてディレクトリ構造を分析します。" : ""}

${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ? "#### .NET プロジェクト構造 (検出された場合)

• ソリューションの構成:

  • プロジェクトがどのようにグループ化され、関連付けられているか
  • ソリューションフォルダーの構成パターン
  • マルチターゲティングプロジェクトのパターン

• プロジェクトの構成:

  • 内部フォルダー構造のパターン
  • ソースコードの構成アプローチ
  • リソースの構成
  • プロジェクトの依存関係と参照

• ドメイン/機能の構成:

  • ビジネスドメインまたは機能がどのように分離されているか
  • ドメイン境界の適用パターン

• レイヤーの構成:

  • 関心の分離 (Controllers、Services、Repositories など)
  • レイヤー間の相互作用と依存関係のパターン

• 構成の管理:

  • 構成ファイルの場所と目的
  • 環境固有の構成
  • シークレットの管理アプローチ

• テストプロジェクトの構成:

  • テストプロジェクトの構造と命名
  • テストのカテゴリと構成
  • テストデータとモックの場所" : ""}

${(PROJECT_TYPE == "React" || PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect") ? "#### UI プロジェクト構造 (検出された場合)

• コンポーネントの構成:

  • コンポーネントのフォルダー構造のパターン
  • グループ化の戦略 (機能別、種類別など)
  • 共有コンポーネントと機能固有のコンポーネント

• 状態管理:

  • 状態関連ファイルの構成
  • グローバル状態のストア構造
  • ローカル状態管理のパターン

• ルーティングの構成:

  • ルート定義の場所
  • ページ/ビューコンポーネントの構成
  • ルートパラメーターの処理

• API 連携:

  • API クライアントの構成
  • サービスレイヤーの構造
  • データ取得のパターン

• アセットの管理:

  • 静的リソースの構成
  • 画像/メディアファイルの構造
  • フォントとアイコンの構成

• スタイルの構成:

  • CSS/SCSS ファイルの構造
  • テーマの構成
  • スタイルモジュールのパターン" : ""}

4. ファイル配置のパターン

${INCLUDE_FILE_PATTERNS ? "さまざまな種類のファイルをどこに配置すべきかを決定するパターンを文書化します。

• 構成ファイル:

  • 種類ごとの構成ファイルの場所
  • 環境固有の構成パターン

• モデル/エンティティ定義:

  • ドメインモデルを定義する場所
  • データ転送オブジェクト (DTO) の場所
  • スキーマ定義の場所

• ビジネスロジック:

  • サービス実装の場所
  • ビジネスルールの構成
  • ユーティリティおよびヘルパー関数の配置場所

• インターフェース定義:

  • インターフェースおよび抽象化を定義する場所
  • インターフェースのグループ化と構成の方法

• テストファイル:

  • ユニットテストの場所のパターン
  • 統合テストの配置場所
  • テストユーティリティとモックの場所

• ドキュメントファイル:

  • API ドキュメントの配置場所
  • 内部ドキュメントの構成
  • README ファイルの配置" : "プロジェクト内で主要なファイルの種類がどこに配置されているかを文書化します。"}

5. 命名と構成の規約

プロジェクト全体で見られる命名と構成の規約を文書化します：

• ファイル命名パターン：

  • 大文字小文字の規約（PascalCase、camelCase、kebab-case）
  • プレフィックスとサフィックスのパターン
  • ファイル名における型の指標

• フォルダー命名パターン：

  • さまざまなフォルダーの種類における命名規約
  • 階層的な命名パターン
  • グループ化と分類の規約

• 名前空間／モジュールのパターン：

  • 名前空間／モジュールがフォルダー構造にどのように対応するか
  • import／using ステートメントの整理
  • 内部 API と公開 API の分離

• 構成のパターン：

  • コードのコロケーション戦略
  • 機能のカプセル化のアプローチ
  • 横断的関心事の整理

6. ナビゲーションと開発ワークフロー

コードベースの構造をナビゲートし、作業するためのガイダンスを提供します：

• エントリーポイント：

  • メインアプリケーションのエントリーポイント
  • 主要な設定の開始点
  • プロジェクトを理解するための最初のファイル

• 一般的な開発タスク：

  • 新機能を追加する場所
  • 既存の機能を拡張する方法
  • 新しいテストを配置する場所
  • 設定を変更する場所

• 依存関係のパターン：

  • フォルダー間で依存関係がどのように流れるか
  • import／参照のパターン
  • 依存性注入の登録場所

${INCLUDE_FILE_COUNTS ? "- コンテンツ統計：

• ディレクトリごとのファイル分析
• コード分布の指標
• 複雑さが集中する領域" : ""}

7. ビルドと出力の構成

ビルドプロセスと出力の構成を文書化します：

• ビルド設定：

  • ビルドスクリプトの場所と目的
  • ビルドパイプラインの構成
  • ビルドタスクの定義

• 出力構造：

  • コンパイル済み／ビルド済み出力の場所
  • 出力の構成パターン
  • 配布パッケージの構造

• 環境固有のビルド：

  • 開発と本番の違い
  • 環境設定の戦略
  • ビルドバリアントの構成

8. テクノロジー固有の構成

${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ? "#### .NET 固有の構造パターン（検出された場合）

• プロジェクトファイルの構成：

  • プロジェクトファイルの構造とパターン
  • ターゲットフレームワークの設定
  • プロパティグループの構成
  • アイテムグループのパターン

• アセンブリの構成：

  • アセンブリの命名パターン
  • マルチアセンブリのアーキテクチャ
  • アセンブリ参照のパターン

• リソースの構成：

  • 埋め込みリソースのパターン
  • ローカライズファイルの構造
  • 静的 Web アセットの構成

• パッケージ管理：

  • NuGet 設定の場所
  • パッケージ参照の構成
  • パッケージバージョンの管理" : ""}

${(PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect") ? "#### Java 固有の構造パターン（検出された場合）

• パッケージ階層：

  • パッケージの命名とネストの規約
  • ドメインと技術的なパッケージ
  • 可視性とアクセスのパターン

• ビルドツールの構成：

  • Maven／Gradle の構造パターン
  • モジュールの構成
  • プラグイン設定のパターン

• リソースの構成：

  • リソースフォルダーの構造
  • 環境固有のリソース
  • プロパティファイルの構成" : ""}

${(PROJECT_TYPE == "Node.js" || PROJECT_TYPE == "Auto-detect") ? "#### Node.js 固有の構造パターン（検出された場合）

• モジュールの構成：

  • CommonJS と ESM の構成
  • 内部モジュールのパターン
  • サードパーティ依存関係の管理

• スクリプトの構成：

  • npm／yarn スクリプトの定義パターン
  • ユーティリティスクリプトの場所
  • 開発ツールのスクリプト

• 設定の管理：

  • 設定ファイルの場所
  • 環境変数の管理
  • シークレット管理のアプローチ" : ""}

9. 拡張と進化

プロジェクト構造がどのように拡張されるように設計されているかを文書化します。

• 拡張ポイント:

  • 規約を維持しながら新しいモジュール/機能を追加する方法
  • プラグイン/拡張機能のフォルダーパターン
  • カスタマイズ用ディレクトリ構造

• スケーラビリティパターン:

  • より大規模な機能に対して構造がどのようにスケールするか
  • 大きなモジュールを分割するためのアプローチ
  • コード分割戦略

• リファクタリングパターン:

  • 見られる一般的なリファクタリングのアプローチ
  • 構造の変更がどのように管理されているか
  • 段階的な再編成のパターン

${INCLUDE_TEMPLATES ? "### 10. 構造テンプレート

プロジェクトの規約に従った新しいコンポーネントを作成するためのテンプレートを提供します。

• 新機能テンプレート:

  • 完全な機能を追加するためのフォルダー構造
  • 必要なファイルの種類とその配置場所
  • 従うべき命名パターン

• 新規コンポーネントテンプレート:

  • 典型的なコンポーネントのディレクトリ構造
  • 含めるべき必須ファイル
  • 既存構造との統合ポイント

• 新規サービステンプレート:

  • 新しいサービスを追加するための構造
  • インターフェースと実装の配置
  • 設定と登録のパターン

• 新規テスト構造:

  • テストプロジェクト/ファイルのフォルダー構造
  • テストファイルの構成テンプレート
  • テストリソースの構成" : ""}

${INCLUDE_TEMPLATES ? "11" : "10"}. 構造の強制

プロジェクト構造がどのように維持され、強制されているかを文書化します。

• 構造の検証:

  • 構造を強制するツール/スクリプト
  • 構造への準拠に関するビルドチェック
  • 構造に関連するリンティングルール

• ドキュメントの慣行:

  • 構造の変更がどのように文書化されているか
  • アーキテクチャ上の決定がどこに記録されているか
  • 構造の進化の履歴

このブループリントの維持方法と、最後に更新された日時に関するセクションを末尾に含めてください。