# Folder structure and project names ## Root folder structure A git repository should contain some (or all) of the following root-level folders:

Folder	Purpose
build	Build configuration and tooling Developer-written scripts, configuration files, environment setup files, and utilities to automate and orchestrate build-related tasks such as linting, compiling, bundling, transforming, and deploying source code.
config	Project configuration files Configuration files, environment settings, dependency injection configuration, etc.
data	Project data and schema Database schema definitions (DDL), migrations, seed and reference data, example datasets, fixtures, and any persistent project data files.
dist	Build output artifacts Compiled, bundled, and/or generated files produced by the build process. This folder represents the deployable or distributable form of the project. (It should be excluded from version control.)
docs	Project documentation Technical documentation related to the project. Includes markdown files, HTML files, API references, user guides, architecture overviews, or other documents that provide instructions, tutorials, and reference materials for developers.
public	Static web-visible resources Static files used in the project and intended to be publicly accessible. These might include images, icons, fonts, HTML/CSS/JS files, and other media assets.
src	Application source code Source code files for the project.
assets	(Optional) Private static resources used in the project and not intended to be publicly accessible. These might include images, fonts, and other media files.
source	(Optional) Source code files that specifically target Microsoft .NET Framework 4.8. This is not necessarily legacy code, therefore the term “legacy” is normally avoided. (This is intentionally separated from other source code because .NET Framework 4.8 projects are difficult to work with using VS Code.)

## Source code project names The name of a source code project that targets .NET uses Pascal Case: the first letter of each word in a multi-word identifier is capitalized, and there are no spaces or separators between words. Use dots in the project name (as needed) to indicate architectural boundaries. For example: * src/api/DanielMiller.Api * src/cli/Workday.Integration * src/lib/Shift.Assessment.Sdk --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.shiftiq.com/contributors/conventions/folder-structure-and-project-names.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.