agentleFS
AsiaOstrichAsiaOstrich/EngramGraph/.agents/skills/project-structure-guide/SKILL.md

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

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
  1. Distinctive:

    Before confirming the project structure is valid, you MUST:

    line 27
  2. Very specific:

    Run the validator: uds check --standard project-structure

    line 28
  3. Distinctive:

    Read the error message (e.g., "Missing required directories").

    line 30
  4. Distinctive:

    Use this skill when:

    line 37
  5. Distinctive:

    When asked to create a project:

    line 133
  6. Distinctive:

    Ask for language/framework

    line 134
  7. Distinctive:

    Create essential config files

    line 136
  8. Distinctive:

    When reviewing existing structure:

    line 141
  9. Distinctive:

    Separate concerns: - Keep source, tests, docs separate

    line 150
  10. Distinctive:

    Gitignore build outputs: - Never commit dist/, build/, out/

    line 151
  11. Distinctive:

    Consistent naming: - Use language-appropriate casing

    line 152
  12. Distinctive:

    Config at root: - Place config files at project root

    line 153
  13. Very specific:

    Generated code separated: - Place in src/generated/{type}/, never mix with hand-written code

    line 156
  14. Very specific:

    After /project-structure completes, the AI assistant should suggest:

    line 160

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  1. Run the validator: uds check --standard project-structure
  2. 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

LanguageFrameworks/Patterns
Node.jsExpress, NestJS, Next.js
PythonDjango, Flask, FastAPI
JavaSpring Boot, Maven, Gradle
.NETASP.NET Core, Console
GoStandard layout, cmd/pkg
RustBinary, Library, Workspace
KotlinGradle, Android, Multiplatform
PHPLaravel, Symfony, PSR-4
RubyRails, Gem, Sinatra
SwiftSPM, 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 configuration

Build Output (Always gitignore)

dist/                 # Distribution output
build/                # Compiled artifacts
out/                  # Output directory
bin/                  # Binary executables

Language-Specific Guidelines

Node.js

project/
├── src/
│   ├── index.js
│   ├── routes/
│   ├── controllers/
│   ├── services/
│   └── models/
├── tests/
├── package.json
└── .gitignore

Python

project/
├── src/
│   └── package_name/
│       ├── __init__.py
│       └── main.py
├── tests/
├── pyproject.toml
└── .gitignore

Go

project/
├── cmd/
│   └── appname/
│       └── main.go
├── internal/
├── pkg/
├── go.mod
└── .gitignore

Quick Actions

Create Project Structure

When asked to create a project:

  1. Ask for language/framework
  2. Generate appropriate directory structure
  3. Create essential config files
  4. Generate .gitignore

Review Structure

When reviewing existing structure:

  1. Check language conventions
  2. Verify gitignore patterns
  3. Suggest improvements
  4. Identify misplaced files

Rules

  1. Follow language conventions - Each language has established patterns
  2. Separate concerns - Keep source, tests, docs separate
  3. Gitignore build outputs - Never commit dist/, build/, out/
  4. Consistent naming - Use language-appropriate casing
  5. Config at root - Place config files at project root
  6. Disambiguate directories - utils/ (stateless, generic), helpers/ (layer-bound), shared/ (cross-module), lib/ (wrapped deps)
  7. Working docs in docs/working/ - Brainstorms, RFCs, POCs, investigations go in docs/working/ with lifecycle management
  8. 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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.