プロジェクトフォルダ構造ブループリント生成器

設定変数

${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 フレームワークファイル(components、modules、pages)
• フロントエンドビルド設定(webpack、vite、rollup など)
• スタイルシート組織(CSS、SCSS、styled-components)
• 静的アセット組織(images、fonts、icons)" : ""}

1. 構造概要

${PROJECT_TYPE == "Auto-detect" ? "検出されたプロジェクトタイプ(群)" : PROJECT_TYPE} プロジェクトの組織原則とフォルダ構造の概要を提供します:

• フォルダ構造に反映されている全体的なアーキテクチャアプローチを記録
• 主な組織原則を識別(フィーチャー別、レイヤー別、ドメイン別など)
• コードベース全体で繰り返される構造パターンを注記
• 推測できる範囲で構造の根拠を記録

${IS_MONOREPO == "Auto-detect" ? "モノレポとして検出された場合、モノレポの構成方法とプロジェクト間の関係を説明します。" : IS_MONOREPO ? "モノレポの構成方法とプロジェクト間の関係を説明します。" : ""}

${INCLUDES_MICROSERVICES == "Auto-detect" ? "マイクロサービスが検出された場合、マイクロサービスの構造と組織方法を説明します。" : INCLUDES_MICROSERVICES ? "マイクロサービスの構造と組織方法を説明します。" : ""}

2. ディレクトリ可視化

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

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

${VISUALIZATION_STYLE == "Table" ? "パス、目的、コンテンツタイプ、規約の列を持つテーブルを作成します。" : ""}

${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 プロジェクト構造(検出された場合)

• コンポーネント組織:

  • コンポーネントフォルダ構造パターン
  • グループ化戦略(フィーチャー別、タイプ別など)
  • 共有 vs フィーチャー固有のコンポーネント

• 状態管理:

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

• ルーティング組織:

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

• API 統合:

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

• アセット管理:

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

• スタイル組織:

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

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

${INCLUDE_FILE_PATTERNS ? "異なるタイプのファイルをどこに配置するかを決定するパターンを記録します:

• 設定ファイル:

  • さまざまなタイプの設定の場所
  • 環境固有の設定パターン

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

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

• ビジネスロジック:

  • サービス実装場所
  • ビジネスルール組織
  • ユーティリティとヘルパー関数の配置

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

  • インターフェースと抽象化の定義場所
  • インターフェースのグループ化と組織方法

• テストファイル:

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

• ドキュメンテーションファイル:

  • API ドキュメント配置
  • 内部ドキュメント組織
  • README ファイル配布" : "主要なファイルタイプがプロジェクト内のどこに配置されているかを記録します。"}

5. 命名と組織規約

プロジェクト全体で観測された命名と組織規約を記録します:

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

  • 大文字小文字規約(PascalCase、camelCase、kebab-case)
  • プリフィックスとサフィックスパターン
  • ファイル名のタイプインジケータ

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

  • さまざまなフォルダタイプの命名規約
  • 階層型命名パターン
  • グループ化と分類規約

• 名前空間/モジュールパターン:

  • 名前空間/モジュールがフォルダ構造にどのようにマップされるか
  • インポート/使用ステートメント組織
  • 内部 vs パブリック API 分離

• 組織パターン:

  • コードの共配置戦略
  • フィーチャーカプセル化アプローチ
  • 横断的関心事組織

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

コードベース構造のナビゲーションと作業に関するガイダンスを提供します:

• エントリーポイント:

  • メインアプリケーションエントリーポイント
  • 主要な設定スタートポイント
  • プロジェクト理解の初期ファイル

• 一般的な開発タスク:

  • 新しいフィーチャーを追加する場所
  • 既存機能を拡張する方法
  • 新しいテストを配置する場所
  • 設定修正場所

• 依存パターン:

  • フォルダ間の依存関係の流れ方
  • インポート/参照パターン
  • 依存性注入登録場所

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

• ディレクトリあたりのファイル数分析
• コード分布メトリクス
• 複雑性集約エリア" : ""}

7. ビルドと出力組織

ビルドプロセスと出力組織を記録します:

• ビルド設定:

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

• 出力構造:

  • コンパイル/ビルト出力場所
  • 出力組織パターン
  • 配布パッケージ構造

• 環境固有ビルド:

  • 開発 vs 本番環境での違い
  • 環境設定戦略
  • ビルドバリアント組織

8. テクノロジー固有組織

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

• プロジェクトファイル組織:

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

• アセンブリ組織:

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

• リソース組織:

  • 埋め込みリソースパターン
  • ローカリゼーションファイル構造
  • 静的 Web アセット組織

• パッケージ管理:

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

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

• パッケージ階層:

  • パッケージ命名とネストング規約
  • ドメイン vs テクニカルパッケージ
  • 可視性とアクセスパターン

• ビルドツール組織:

  • Maven/Gradle 構造パターン
  • モジュール組織
  • プラグイン設定パターン

• リソース組織:

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

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

• モジュール組織:

  • CommonJS vs ESM 組織
  • 内部モジュールパターン
  • サードパーティ依存管理

• スクリプト組織:

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

• 設定管理:

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

9. 拡張と発展

プロジェクト構造を拡張するように設計されているかを記録します:

• 拡張ポイント:

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

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

  • より大きなフィーチャーのための構造スケール方法
  • 大規模モジュール分割アプローチ
  • コード分割戦略

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

  • 観測された一般的なリファクタリングアプローチ
  • 構造的変更の管理方法
  • 段階的な再編成パターン

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

プロジェクト規約に従う新しいコンポーネント作成用のテンプレートを提供します:

• 新規フィーチャーテンプレート:

  • 完全なフィーチャーを追加するためのフォルダ構造
  • 必要なファイルタイプと場所
  • 従うべき命名パターン

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

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

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

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

• 新規テスト構造:

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

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

プロジェクト構造がどのように保守され、強制されるかを記録します:

• 構造検証:

  • 構造を強制するツール/スクリプト
  • 構造的合致性の構築チェック
  • 構造に関連するリンティングルール

• ドキュメント慣行:

  • 構造的変更のドキュメント方法
  • アーキテクチャの意思決定の記録場所
  • 構造発展の履歴

最後に、このブループリントの保守方法と最後に更新された時期についてのセクションを含めてください。 "