project-structure-guide
Skill4 starsChanged 28 days agoMITView on GitHub
Guide for organizing project directories following language-specific best practices. Use when: creating projects, reorganizing structure, adding modules, setting up builds, deciding file placement. Not for: structuring specifically for AI navigation — use /ai-friendly-architecture; restructuring existing code in place — use /refactor. Keywords: project, structure, directory, layout, gitignore, scaffold, file placement, utils, helpers, shared, where to put.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- AsiaOstrich/universal-dev-standardsword for word, first seen Nov 4, 2026
Other versions1 project uses a version of this.
Word for word · 1
- AsiaOstrich/universal-dev-standards★ 84100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository55 other files it gives its agents.
- AGENTS.mdAGENTS.md
- ac-coverageSkill
- adrSkill
- ai-collaboration-standardsSkill
- ai-friendly-architectureSkill
- ai-instruction-standardsSkill
- api-designSkill
- atddSkill
- auditSkill
- bddSkill
- brainstormSkill
- changelogSkill
- checkinSkill
- ci-cdSkill
- code-reviewSkill
- commitSkill
- contract-testSkill
- databaseSkill
- deploySkill
- methodologySkill
- dev-workflowSkill
- docgenSkill
- documentation-guideSkill
- durableSkill
- e2eSkill
- error-code-guideSkill
- git-workflow-guideSkill
- incidentSkill
- journey-test-assistantSkill
- knowledge-graphSkill
- logging-guideSkill
- metricsSkill
- migrateSkill
- observabilitySkill
- orchestrateSkill
- planSkill
- prSkill
- discoverSkill
- pushSkill
- refactorSkill
- releaseSkill
- requirementSkill
- retrospectiveSkill
- reverseSkill
- runbookSkill
- securitySkill
- scanSkill
- skill-builderSkill
- sloSkill
- spec-deriveSkill
- sddSkill
- sweepSkill
- tddSkill
- coverageSkill
- testing-guideSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 11 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
Before confirming the project structure is valid, you MUST:
- Very specific: line 28
Run the validator: uds check --standard project-structure
- Distinctive: line 30
Read the error message (e.g., "Missing required directories").
- Distinctive: line 37
Use this skill when:
- Distinctive: line 133
When asked to create a project:
- Distinctive: line 134
Ask for language/framework
- Distinctive: line 136
Create essential config files
- Distinctive: line 141
When reviewing existing structure:
- Distinctive: line 150
Separate concerns: - Keep source, tests, docs separate
- Distinctive: line 151
Gitignore build outputs: - Never commit dist/, build/, out/
- Distinctive: line 152
Consistent naming: - Use language-appropriate casing
- Distinctive: line 153
Config at root: - Place config files at project root
- Very specific: line 156
Generated code separated: - Place in src/generated/{type}/, never mix with hand-written code
- Very specific: line 160
After /project-structure completes, the AI assistant should suggest:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Project Structure Guide
Language: English | 繁體中文
Version: 1.1.0 Last Updated: 2026-03-04 Applicability: Claude Code Skills
Purpose
This skill provides guidance on structuring projects according to language and framework conventions. It helps create consistent, maintainable directory layouts.
[Physical Binding]
Reality Check
Before confirming the project structure is valid, you MUST:
- Run the validator:
uds check --standard project-structure - IF exit_code != 0:
- Read the error message (e.g., "Missing required directories").
- Report the violation to the user.
- Suggest specific commands (
mkdir ...) to fix it. - RETRY validation after fixes are applied.
Trigger
Use this skill when:
- Creating a new project
- Reorganizing existing project structure
- Adding new modules or features
- Setting up build configuration
- Creating .gitignore files
- Deciding where to place a file (code, docs, config, asset)
- Choosing between utils/, helpers/, shared/, lib/, or internal/
- Placing development artifacts (brainstorms, RFCs, POCs, investigations)
Supported Languages
| Language | Frameworks/Patterns |
| Node.js | Express, NestJS, Next.js |
| Python | Django, Flask, FastAPI |
| Java | Spring Boot, Maven, Gradle |
| .NET | ASP.NET Core, Console |
| Go | Standard layout, cmd/pkg |
| Rust | Binary, Library, Workspace |
| Kotlin | Gradle, Android, Multiplatform |
| PHP | Laravel, Symfony, PSR-4 |
| Ruby | Rails, Gem, Sinatra |
| Swift | SPM, iOS App, Vapor |
Common Structure Patterns
Standard Directories
project-root/
├── src/ # Source code
├── tests/ # Test files
├── docs/ # Documentation
├── tools/ # Build/deployment scripts
├── examples/ # Usage examples
├── config/ # Configuration files
└── .github/ # GitHub configurationBuild Output (Always gitignore)
dist/ # Distribution output
build/ # Compiled artifacts
out/ # Output directory
bin/ # Binary executablesLanguage-Specific Guidelines
Node.js
project/
├── src/
│ ├── index.js
│ ├── routes/
│ ├── controllers/
│ ├── services/
│ └── models/
├── tests/
├── package.json
└── .gitignorePython
project/
├── src/
│ └── package_name/
│ ├── __init__.py
│ └── main.py
├── tests/
├── pyproject.toml
└── .gitignoreGo
project/
├── cmd/
│ └── appname/
│ └── main.go
├── internal/
├── pkg/
├── go.mod
└── .gitignoreQuick Actions
Create Project Structure
When asked to create a project:
- Ask for language/framework
- Generate appropriate directory structure
- Create essential config files
- Generate .gitignore
Review Structure
When reviewing existing structure:
- Check language conventions
- Verify gitignore patterns
- Suggest improvements
- Identify misplaced files
Rules
- Follow language conventions - Each language has established patterns
- Separate concerns - Keep source, tests, docs separate
- Gitignore build outputs - Never commit dist/, build/, out/
- Consistent naming - Use language-appropriate casing
- Config at root - Place config files at project root
- Disambiguate directories - utils/ (stateless, generic), helpers/ (layer-bound), shared/ (cross-module), lib/ (wrapped deps)
- Working docs in docs/working/ - Brainstorms, RFCs, POCs, investigations go in docs/working/ with lifecycle management
- Generated code separated - Place in src/generated/{type}/, never mix with hand-written code
Next Steps Guidance | 下一步引導
After /project-structure completes, the AI assistant should suggest:
專案結構已建立或審查完成。建議下一步 / Project structure created or reviewed. Suggested next steps:
- 執行
/sdd開始規格驅動開發,將專案結構納入正式規格 ⭐ Recommended / 推薦 — 確保結構決策有規格追蹤 / Ensures structure decisions are tracked in specs- 執行
/docs產生專案文件(README、ARCHITECTURE.md 等) — 讓結構決策有文件記錄 / Document structure decisions- 執行
/ai-friendly-architecture設定 AI 上下文配置 — 讓 AI 助手更好地理解專案結構 / Help AI assistants understand the project structure
Related Standards
- Language-specific patterns — concrete directory layouts per language (Node.js/TypeScript, Python, Go, and others). Read it when laying out a project in a specific language.
- Core: Project Structure
- Core: Documentation Structure
- Guide: File Placement Decision Guide
- AI: Project Structure Options
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

