Folder Structure Blueprint Generator
Document and standardize how a solo builder’s repo is organized before adding features or onboarding collaborators.
Overview
Folder Structure Blueprint Generator is an agent skill most often used in Build (also Validate, Operate) that analyzes your repo and documents a consistent folder blueprint across diverse tech stacks.
Install
npx skills add https://github.com/github/awesome-copilot --skill folder-structure-blueprint-generatorWhat is this skill?
- Auto-detects stack flavor across .NET, Java, React, Angular, Python, Node.js, and Flutter (or manual override).
- Configurable depth (1–5 levels), visualization (ASCII, Markdown list, or table), and optional file-count statistics.
- Flags monorepo, microservices, and frontend presence via auto-detect or explicit toggles.
- Documents file naming and location patterns plus optional templates for new features.
- Technology-agnostic prompt you can rerun when the repo shape changes.
- Supports depth levels 1–5 for documented folder tiers.
- Auto-detects or accepts .NET, Java, React, Angular, Python, Node.js, and Flutter project types.
- Three visualization styles: ASCII, Markdown list, and table.
Adoption & trust: 8.7k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
Your repository grew organically and nobody—including your coding agent—agrees where new files should live.
Who is it for?
Solo builders documenting a real repo (mono or polyglot) who want ASCII or table blueprints plus naming rules before feature work.
Skip if: Greenfield projects with no files yet, or teams that only need a one-line README with no placement standards.
When should I use this skill?
You need to analyze and document an existing project’s folder structure with optional monorepo, microservices, and frontend detection.
What do I get? / Deliverables
You get a depth-controlled structure map, conventions, and optional feature templates you can paste into docs or team rules before the next implementation pass.
- Technology-aware folder structure blueprint with chosen visualization.
- Naming and file-placement pattern notes.
- Optional templates for new features or modules.
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the skill turns a live codebase into an actionable folder blueprint and templates for ongoing development. Docs is the best fit: output is structure documentation, naming rules, and placement patterns—not shipping code or running tests.
Where it fits
Compare current tree against a proposed microservices split before committing to the refactor.
Publish an ASCII or table blueprint plus file patterns for contributors and agents.
Align epic breakdown with physical modules so tasks map to folders.
Refresh the blueprint after a major directory move so agents stop citing stale paths.
How it compares
Use instead of copying a generic ‘best practice’ tree from a blog post that does not match your actual stack.
Common Questions / FAQ
Who is folder-structure-blueprint-generator for?
Solo and indie builders using Claude Code, Cursor, or Codex who need a written, stack-aware map of where code and config belong.
When should I use folder-structure-blueprint-generator?
During Validate when scoping a refactor, in Build when documenting or standardizing layout, and in Operate when onboarding agents to a legacy tree.
Is folder-structure-blueprint-generator safe to install?
It mainly guides analysis and documentation prompts; review the Security Audits panel on this Prism page before granting broad filesystem or shell access in your agent.
SKILL.md
READMESKILL.md - 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 repe