folder-structure-blueprint-generator

# Project Folder Structure Blueprint Generator

## Configuration Variables

${PROJECT_TYPE="Auto-detect|.NET|Java|React|Angular|Python|Node.js|Flutter|Other"} 
<!-- Select primary technology -->

${INCLUDES_MICROSERVICES="Auto-detect|true|false"} 
<!-- Is this a microservices architecture? -->

${INCLUDES_FRONTEND="Auto-detect|true|false"} 
<!-- Does project include frontend components? -->

${IS_MONOREPO="Auto-detect|true|false"} 
<!-- Is this a monorepo with multiple projects? -->

${VISUALIZATION_STYLE="ASCII|Markdown List|Table"} 
<!-- How to visualize the structure -->

${DEPTH_LEVEL=1-5} 
<!-- How many levels of folders to document in detail -->

${INCLUDE_FILE_COUNTS=true|false} 
<!-- Include file count statistics -->

${INCLUDE_GENERATED_FOLDERS=true|false} 
<!-- Include auto-generated folders -->

${INCLUDE_FILE_PATTERNS=true|false} 
<!-- Document file naming/location patterns -->

${INCLUDE_TEMPLATES=true|false} 
<!-- Include file/folder templates for new features -->

## Generated Prompt

"Analyze the project's folder structure and create a comprehensive 'Project_Folders_Structure_Blueprint.md' document that serves as a definitive guide for maintaining consistent code organization. Use the following approach:

### Initial Auto-detection Phase

${PROJECT_TYPE == "Auto-detect" ? 
"Begin by scanning the folder structure for key files that identify the project type:
- Look for solution/project files (.sln, .csproj, .fsproj, .vbproj) to identify .NET projects
- Check for build files (pom.xml, build.gradle, settings.gradle) for Java projects
- Identify package.json with dependencies for JavaScript/TypeScript projects
- Look for specific framework files (angular.json, react-scripts entries, next.config.js)
- Check for Python project identifiers (requirements.txt, setup.py, pyproject.toml)
- Examine mobile app identifiers (pubspec.yaml, android/ios folders)
- Note all technology signatures found and their versions" : 
"Focus analysis on ${PROJECT_TYPE} project structure"}

${IS_MONOREPO == "Auto-detect" ? 
"Determine if this is a monorepo by looking for:
- Multiple distinct projects with their own configuration files
- Workspace configuration files (lerna.json, nx.json, turborepo.json, etc.)
- Cross-project references and shared dependency patterns
- Root-level orchestration scripts and configuration" : ""}

${INCLUDES_MICROSERVICES == "Auto-detect" ? 
"Check for microservices architecture indicators:
- Multiple service directories with similar/repeated structures
- Service-specific Dockerfiles or deployment configurations
- Inter-service communication patterns (APIs, message brokers)
- Service registry or discovery configuration
- API gateway configuration files
- Shared libraries or utilities across services" : ""}

${INCLUDES_FRONTEND == "Auto-detect" ? 
"Identify frontend components by looking for:
- Web asset directories (wwwroot, public, dist, static)
- UI framework files (components, modules, pages)
- Frontend build configuration (webpack, vite, rollup, etc.)
- Style sheet organization (CSS, SCSS, styled-components)
- Static asset organization (images, fonts, icons)" : ""}

### 1. Structural Overview

Provide a high-level overview of the ${PROJECT_TYPE == "Auto-detect" ? "detected project type(s)" : PROJECT_TYPE} project's organization principles and folder structure:

- Document the overall architectural approach reflected in the folder structure
- Identify the main organizational principles (by feature, by layer, by domain, etc.)
- Note any structural patterns that repeat throughout the codebase
- Document the rationale behind the structure where it can be inferred

${IS_MONOREPO == "Auto-detect" ? 
"If detected as a monorepo, explain how the monorepo is organized and the relationship between projects." : 
IS_MONOREPO ? "Explain how the monorepo is organized and the relationship between projects." : ""}

${INCLUDES_MICROSERVICES == "Auto-detect" ? 
"If microservices are detected, describe how they are structured and organized." : 
INCLUDES_MICROSERVICES ? "Describe how the microservices are structured and organized." : ""}

### 2. Directory Visualization

${VISUALIZATION_STYLE == "ASCII" ? 
"Create an ASCII tree representation of the folder hierarchy to depth level ${DEPTH_LEVEL}." : ""}

${VISUALIZATION_STYLE == "Markdown List" ? 
"Use nested markdown lists to represent the folder hierarchy to depth level ${DEPTH_LEVEL}." : ""}

${VISUALIZATION_STYLE == "Table" ? 
"Create a table with columns for Path, Purpose, Content Types, and Conventions." : ""}

${INCLUDE_GENERATED_FOLDERS ? 
"Include all folders including generated ones." : 
"Exclude auto-generated folders like bin/, obj/, node_modules/, etc."}

### 3. Key Directory Analysis

Document each significant directory's purpose, contents, and patterns:

${PROJECT_TYPE == "Auto-detect" ? 
"For each detected technology, analyze directory structures based on observed usage patterns:" : ""}

${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ? 
"#### .NET Project Structure (if detected)

- **Solution Organization**: 
  - How projects are grouped and related
  - Solution folder organization patterns
  - Multi-targeting project patterns

- **Project Organization**:
  - Internal folder structure patterns
  - Source code organization approach
  - Resource organization
  - Project dependencies and references

- **Domain/Feature Organization**:
  - How business domains or features are separated
  - Domain boundary enforcement patterns

- **Layer Organization**:
  - Separation of concerns (Controllers, Services, Repositories, etc.)
  - Layer interaction and dependency patterns

- **Configuration Management**:
  - Configuration file locations and purposes
  - Environment-specific configurations
  - Secret management approach

- **Test Project Organization**:
  - Test project structure and naming
  - Test categories and organization
  - Test data and mock locations" : ""}

${(PROJECT_TYPE == "React" || PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect") ? 
"#### UI Project Structure (if detected)

- **Component Organization**:
  - Component folder structure patterns
  - Grouping strategies (by feature, type, etc.)
  - Shared vs. feature-specific components

- **State Management**:
  - State-related file organization
  - Store structure for global state
  - Local state management patterns

- **Routing Organization**:
  - Route definition locations
  - Page/view component organization
  - Route parameter handling

- **API Integration**:
  - API client organization
  - Service layer structure
  - Data fetching patterns

- **Asset Management**:
  - Static resource organization
  - Image/media file structure
  - Font and icon organization
  
- **Style Organization**:
  - CSS/SCSS file structure
  - Theme organization
  - Style module patterns" : ""}

### 4. File Placement Patterns

${INCLUDE_FILE_PATTERNS ? 
"Document the patterns that determine where different types of files should be placed:

- **Configuration Files**:
  - Locations for different types of configuration
  - Environment-specific configuration patterns
  
- **Model/Entity Definitions**:
  - Where domain models are defined
  - Data transfer object (DTO) locations
  - Schema definition locations
  
- **Business Logic**:
  - Service implementation locations
  - Business rule organization
  - Utility and helper function placement
  
- **Interface Definitions**:
  - Where interfaces and abstractions are defined
  - How interfaces are grouped and organized
  
- **Test Files**:
  - Unit test location patterns
  - Integration test placement
  - Test utility and mock locations
  
- **Documentation Files**:
  - API documentation placement
  - Internal documentation organization
  - README file distribution" : 
"Document where key file types are located in the project."}

### 5. Naming and Organization Conventions
Document the naming and organizational conventions observed across the project:

- **File Naming Patterns**:
  - Case conventions (PascalCase, camelCase, kebab-case)
  - Prefix and suffix patterns
  - Type indicators in filenames
  
- **Folder Naming Patterns**:
  - Naming conventions for different folder types
  - Hierarchical naming patterns
  - Grouping and categorization conventions
  
- **Namespace/Module Patterns**:
  - How namespaces/modules map to folder structure
  - Import/using statement organization
  - Internal vs. public API separation

- **Organizational Patterns**:
  - Code co-location strategies
  - Feature encapsulation approaches
  - Cross-cutting concern organization

### 6. Navigation and Development Workflow
Provide guidance for navigating and working with the codebase structure:

- **Entry Points**:
  - Main application entry points
  - Key configuration starting points
  - Initial files for understanding the project

- **Common Development Tasks**:
  - Where to add new features
  - How to extend existing functionality
  - Where to place new tests
  - Configuration modification locations
  
- **Dependency Patterns**:
  - How dependencies flow between folders
  - Import/reference patterns
  - Dependency injection registration locations

${INCLUDE_FILE_COUNTS ? 
"- **Content Statistics**:
  - Files per directory analysis
  - Code distribution metrics
  - Complexity concentration areas" : ""}

### 7. Build and Output Organization
Document the build process and output organization:

- **Build Configuration**:
  - Build script locations and purposes
  - Build pipeline organization
  - Build task definitions
  
- **Output Structure**:
  - Compiled/built output locations
  - Output organization patterns
  - Distribution package structure
  
- **Environment-Specific Builds**:
  - Development vs. production differences
  - Environment configuration strategies
  - Build variant organization

### 8. Technology-Specific Organization

${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ? 
"#### .NET-Specific Structure Patterns (if detected)

- **Project File Organization**:
  - Project file structure and patterns
  - Target framework configuration
  - Property group organization
  - Item group patterns
  
- **Assembly Organization**:
  - Assembly naming patterns
  - Multi-assembly architecture
  - Assembly reference patterns
  
- **Resource Organization**:
  - Embedded resource patterns
  - Localization file structure
  - Static web asset organization
  
- **Package Management**:
  - NuGet configuration locations
  - Package reference organization
  - Package version management" : ""}

${(PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect") ? 
"#### Java-Specific Structure Patterns (if detected)

- **Package Hierarchy**:
  - Package naming and nesting conventions
  - Domain vs. technical packages
  - Visibility and access patterns
  
- **Build Tool Organization**:
  - Maven/Gradle structure patterns
  - Module organization
  - Plugin configuration patterns
  
- **Resource Organization**:
  - Resource folder structures
  - Environment-specific resources
  - Properties file organization" : ""}

${(PROJECT_TYPE == "Node.js" || PROJECT_TYPE == "Auto-detect") ? 
"#### Node.js-Specific Structure Patterns (if detected)

- **Module Organization**:
  - CommonJS vs. ESM organization
  - Internal module patterns
  - Third-party dependency management
  
- **Script Organization**:
  - npm/yarn script definition patterns
  - Utility script locations
  - Development tool scripts
  
- **Configuration Management**:
  - Configuration file locations
  - Environment variable management
  - Secret management approaches" : ""}

### 9. Extension and Evolution
Document how the project structure is designed to be extended:

- **Extension Points**:
  - How to add new modules/features while maintaining conventions
  - Plugin/extension folder patterns
  - Customization directory structures
  
- **Scalability Patterns**:
  - How the structure scales for larger features
  - Approach for breaking down large modules
  - Code splitting strategies
  
- **Refactoring Patterns**:
  - Common refactoring approaches observed
  - How structural changes are managed
  - Incremental reorganization patterns

${INCLUDE_TEMPLATES ? 
"### 10. Structure Templates

Provide templates for creating new components that follow project conventions:

- **New Feature Template**:
  - Folder structure for adding a complete feature
  - Required file types and their locations
  - Naming patterns to follow
  
- **New Component Template**:
  - Directory structure for a typical component
  - Essential files to include
  - Integration points with existing structure
  
- **New Service Template**:
  - Structure for adding a new service
  - Interface and implementation placement
  - Configuration and registration patterns
  
- **New Test Structure**:
  - Folder structure for test projects/files
  - Test file organization templates
  - Test resource organization" : ""}

### ${INCLUDE_TEMPLATES ? "11" : "10"}. Structure Enforcement

Document how the project structure is maintained and enforced:

- **Structure Validation**:
  - Tools/scripts that enforce structure
  - Build checks for structural compliance
  - Linting rules related to structure
  
- **Documentation Practices**:
  - How structural changes are documented
  - Where architectural decisions are recorded
  - Structure evolution history

Include a section at the end about maintaining this blueprint and when it was last updated.
"