file-organization
Organize project files and folders for maintainability and scalability. Use when structuring new projects, refactoring folder structure, or establishing conventions. Handles project structure, naming conventions, and file organization best practices.
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o file-organization.zip https://jpskill.com/download/20901.zip && unzip -o file-organization.zip && rm file-organization.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/20901.zip -OutFile "$d\file-organization.zip"; Expand-Archive "$d\file-organization.zip" -DestinationPath $d -Force; ri "$d\file-organization.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
file-organization.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
file-organizationフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
[スキル名] file-organization
プロジェクトのファイル構成
このスキルを使用するタイミング
- 新規プロジェクト: 初期フォルダー構造の設計時
- プロジェクトの成長: 複雑さが増した際の構造のリファクタリング時
- チームの標準化: 一貫した構造を確立する際
手順
ステップ1: React/Next.js プロジェクト構造
src/
├── app/ # Next.js 13+ App Router
│ ├── (auth)/ # ルートグループ
│ │ ├── login/
│ │ └── signup/
│ ├── (dashboard)/
│ │ ├── layout.tsx
│ │ ├── page.tsx
│ │ └── settings/
│ ├── api/ # API ルート
│ │ ├── auth/
│ │ └── users/
│ └── layout.tsx
│
├── components/ # UI コンポーネント
│ ├── ui/ # 再利用可能な UI (Button, Input)
│ │ ├── Button/
│ │ │ ├── Button.tsx
│ │ │ ├── Button.test.tsx
│ │ │ └── index.ts
│ │ └── Input/
│ ├── layout/ # レイアウトコンポーネント (Header, Footer)
│ ├── features/ # 機能固有のコンポーネント
│ │ ├── auth/
│ │ └── dashboard/
│ └── shared/ # 機能間で共有されるもの
│
├── lib/ # ユーティリティ & ヘルパー
│ ├── utils.ts
│ ├── hooks/
│ │ ├── useAuth.ts
│ │ └── useLocalStorage.ts
│ └── api/
│ └── client.ts
│
├── store/ # 状態管理
│ ├── slices/
│ │ ├── authSlice.ts
│ │ └── userSlice.ts
│ └── index.ts
│
├── types/ # TypeScript 型定義
│ ├── api.ts
│ ├── models.ts
│ └── index.ts
│
├── config/ # 設定
│ ├── env.ts
│ └── constants.ts
│
└── styles/ # グローバルスタイル
├── globals.css
└── theme.ts
ステップ2: Node.js/Express バックエンド構造
src/
├── api/ # API レイヤー
│ ├── routes/
│ │ ├── auth.routes.ts
│ │ ├── user.routes.ts
│ │ └── index.ts
│ ├── controllers/
│ │ ├── auth.controller.ts
│ │ └── user.controller.ts
│ └── middlewares/
│ ├── auth.middleware.ts
│ ├── errorHandler.ts
│ └── validation.ts
│
├── services/ # ビジネスロジック
│ ├── auth.service.ts
│ ├── user.service.ts
│ └── email.service.ts
│
├── repositories/ # データアクセスレイヤー
│ ├── user.repository.ts
│ └── session.repository.ts
│
├── models/ # データベースモデル
│ ├── User.ts
│ └── Session.ts
│
├── database/ # データベース設定
│ ├── connection.ts
│ ├── migrations/
│ └── seeds/
│
├── utils/ # ユーティリティ
│ ├── logger.ts
│ ├── crypto.ts
│ └── validators.ts
│
├── config/ # 設定
│ ├── index.ts
│ ├── database.ts
│ └── env.ts
│
├── types/ # TypeScript 型定義
│ ├── express.d.ts
│ └── models.ts
│
├── __tests__/ # テスト
│ ├── unit/
│ ├── integration/
│ └── e2e/
│
└── index.ts # エントリーポイント
ステップ3: 機能ベースの構造 (大規模アプリケーション)
src/
├── features/
│ ├── auth/
│ │ ├── components/
│ │ │ ├── LoginForm.tsx
│ │ │ └── SignupForm.tsx
│ │ ├── hooks/
│ │ │ └── useAuth.ts
│ │ ├── api/
│ │ │ └── authApi.ts
│ │ ├── store/
│ │ │ └── authSlice.ts
│ │ ├── types/
│ │ │ └── auth.types.ts
│ │ └── index.ts
│ │
│ ├── products/
│ │ ├── components/
│ │ ├── hooks/
│ │ ├── api/
│ │ └── types/
│ │
│ └── orders/
│
├── shared/ # 機能間で共有されるもの
│ ├── components/
│ ├── hooks/
│ ├── utils/
│ └── types/
│
└── core/ # アプリケーション全体
├── store/
├── router/
└── config/
ステップ4: 命名規則
ファイル名:
Components: PascalCase.tsx
Hooks: camelCase.ts (useAuth.ts)
Utils: camelCase.ts (formatDate.ts)
Constants: UPPER_SNAKE_CASE.ts (API_ENDPOINTS.ts)
Types: camelCase.types.ts (user.types.ts)
Tests: *.test.ts, *.spec.ts
フォルダー名:
kebab-case: user-profile/
camelCase: userProfile/ (オプション: hooks/, utils/)
PascalCase: UserProfile/ (オプション: components/)
✅ 一貫性が重要です (チーム全体で同じルールを使用します)
変数/関数名:
// Components: PascalCase
const UserProfile = () => {};
// Functions: camelCase
function getUserById() {}
// Constants: UPPER_SNAKE_CASE
const API_BASE_URL = 'https://api.example.com';
// Private: _prefix (オプション)
class User {
private _id: string;
private _hashPassword() {}
}
// Booleans: is/has/can プレフィックス
const isAuthenticated = true;
const hasPermission = false;
const canEdit = true;
ステップ5: index.ts バレルファイル
components/ui/index.ts:
// ✅ 良い例: 名前付きエクスポートを再エクスポート
export { Button } from './Button/Button';
export { Input } from './Input/Input';
export { Modal } from './Modal/Modal';
// 使用法:
import { Button, Input } from '@/components/ui';
❌ 悪い例:
// すべてを再エクスポート (ツリーシェイキングを妨げます)
export * from './Button';
export * from './Input';
出力形式
プロジェクトテンプレート
my-app/
├── .github/
│ └── workflows/
├── public/
├── src/
│ ├── app/
│ ├── components/
│ ├── lib/
│ ├── types/
│ └── config/
├── tests/
├── docs/
├── scripts/
├── .env.example
├── .gitignore
├── .eslintrc.json
├── .prettierrc
├── tsconfig.json
├── package.json
└── README.md
制約
必須ルール (MUST)
- 一貫性: チーム全体で同じルールを使用すること
- 明確なフォルダー名: 役割を明示すること
- 最大深度: 5レベル以下を推奨すること
禁止事項 (MUST NOT)
- 過度なネスト: フォルダーの深さが7レベル以上になることを避けること
- 曖昧な名前: utils2/, helpers/, misc/ のような名前を避けること
- 循環参照: A → B → A のような参照を禁止すること
ベストプラクティス
- コロケーション: 関連ファイルを近くに配置すること (コンポーネント + スタイル + テスト)
- 機能ベース: 機能ごとにモジュール化すること
- パスエイリアス: インポートを簡素化するために使用すること
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Project File Organization
When to use this skill
- New Projects: Initial folder structure design
- Project Growth: Refactoring when complexity increases
- Team Standardization: Establish consistent structure
Instructions
Step 1: React/Next.js Project Structure
src/
├── app/ # Next.js 13+ App Router
│ ├── (auth)/ # Route groups
│ │ ├── login/
│ │ └── signup/
│ ├── (dashboard)/
│ │ ├── layout.tsx
│ │ ├── page.tsx
│ │ └── settings/
│ ├── api/ # API routes
│ │ ├── auth/
│ │ └── users/
│ └── layout.tsx
│
├── components/ # UI Components
│ ├── ui/ # Reusable UI (Button, Input)
│ │ ├── Button/
│ │ │ ├── Button.tsx
│ │ │ ├── Button.test.tsx
│ │ │ └── index.ts
│ │ └── Input/
│ ├── layout/ # Layout components (Header, Footer)
│ ├── features/ # Feature-specific components
│ │ ├── auth/
│ │ └── dashboard/
│ └── shared/ # Shared across features
│
├── lib/ # Utilities & helpers
│ ├── utils.ts
│ ├── hooks/
│ │ ├── useAuth.ts
│ │ └── useLocalStorage.ts
│ └── api/
│ └── client.ts
│
├── store/ # State management
│ ├── slices/
│ │ ├── authSlice.ts
│ │ └── userSlice.ts
│ └── index.ts
│
├── types/ # TypeScript types
│ ├── api.ts
│ ├── models.ts
│ └── index.ts
│
├── config/ # Configuration
│ ├── env.ts
│ └── constants.ts
│
└── styles/ # Global styles
├── globals.css
└── theme.ts
Step 2: Node.js/Express Backend Structure
src/
├── api/ # API layer
│ ├── routes/
│ │ ├── auth.routes.ts
│ │ ├── user.routes.ts
│ │ └── index.ts
│ ├── controllers/
│ │ ├── auth.controller.ts
│ │ └── user.controller.ts
│ └── middlewares/
│ ├── auth.middleware.ts
│ ├── errorHandler.ts
│ └── validation.ts
│
├── services/ # Business logic
│ ├── auth.service.ts
│ ├── user.service.ts
│ └── email.service.ts
│
├── repositories/ # Data access layer
│ ├── user.repository.ts
│ └── session.repository.ts
│
├── models/ # Database models
│ ├── User.ts
│ └── Session.ts
│
├── database/ # Database setup
│ ├── connection.ts
│ ├── migrations/
│ └── seeds/
│
├── utils/ # Utilities
│ ├── logger.ts
│ ├── crypto.ts
│ └── validators.ts
│
├── config/ # Configuration
│ ├── index.ts
│ ├── database.ts
│ └── env.ts
│
├── types/ # TypeScript types
│ ├── express.d.ts
│ └── models.ts
│
├── __tests__/ # Tests
│ ├── unit/
│ ├── integration/
│ └── e2e/
│
└── index.ts # Entry point
Step 3: Feature-Based Structure (Large-Scale Apps)
src/
├── features/
│ ├── auth/
│ │ ├── components/
│ │ │ ├── LoginForm.tsx
│ │ │ └── SignupForm.tsx
│ │ ├── hooks/
│ │ │ └── useAuth.ts
│ │ ├── api/
│ │ │ └── authApi.ts
│ │ ├── store/
│ │ │ └── authSlice.ts
│ │ ├── types/
│ │ │ └── auth.types.ts
│ │ └── index.ts
│ │
│ ├── products/
│ │ ├── components/
│ │ ├── hooks/
│ │ ├── api/
│ │ └── types/
│ │
│ └── orders/
│
├── shared/ # Shared across features
│ ├── components/
│ ├── hooks/
│ ├── utils/
│ └── types/
│
└── core/ # App-wide
├── store/
├── router/
└── config/
Step 4: Naming Conventions
File Names:
Components: PascalCase.tsx
Hooks: camelCase.ts (useAuth.ts)
Utils: camelCase.ts (formatDate.ts)
Constants: UPPER_SNAKE_CASE.ts (API_ENDPOINTS.ts)
Types: camelCase.types.ts (user.types.ts)
Tests: *.test.ts, *.spec.ts
Folder Names:
kebab-case: user-profile/
camelCase: userProfile/ (optional: hooks/, utils/)
PascalCase: UserProfile/ (optional: components/)
✅ Consistency is key (entire team uses the same rules)
Variable/Function Names:
// Components: PascalCase
const UserProfile = () => {};
// Functions: camelCase
function getUserById() {}
// Constants: UPPER_SNAKE_CASE
const API_BASE_URL = 'https://api.example.com';
// Private: _prefix (optional)
class User {
private _id: string;
private _hashPassword() {}
}
// Booleans: is/has/can prefix
const isAuthenticated = true;
const hasPermission = false;
const canEdit = true;
Step 5: index.ts Barrel Files
components/ui/index.ts:
// ✅ Good example: Re-export named exports
export { Button } from './Button/Button';
export { Input } from './Input/Input';
export { Modal } from './Modal/Modal';
// Usage:
import { Button, Input } from '@/components/ui';
❌ Bad example:
// Re-export everything (impairs tree-shaking)
export * from './Button';
export * from './Input';
Output format
Project Template
my-app/
├── .github/
│ └── workflows/
├── public/
├── src/
│ ├── app/
│ ├── components/
│ ├── lib/
│ ├── types/
│ └── config/
├── tests/
├── docs/
├── scripts/
├── .env.example
├── .gitignore
├── .eslintrc.json
├── .prettierrc
├── tsconfig.json
├── package.json
└── README.md
Constraints
Required Rules (MUST)
- Consistency: Entire team uses the same rules
- Clear Folder Names: Roles must be explicit
- Max Depth: Recommend 5 levels or fewer
Prohibited (MUST NOT)
- Excessive Nesting: Avoid 7+ levels of folder depth
- Vague Names: Avoid utils2/, helpers/, misc/
- Circular Dependencies: Prohibit A → B → A references
Best practices
- Colocation: Keep related files close (component + styles + tests)
- Feature-Based: Modularize by feature
- Path Aliases: Simplify imports with
@/
tsconfig.json:
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"@/*": ["./src/*"],
"@/components/*": ["./src/components/*"],
"@/lib/*": ["./src/lib/*"]
}
}
}
Usage:
// ❌ Bad example
import { Button } from '../../../components/ui/Button';
// ✅ Good example
import { Button } from '@/components/ui';
References
Metadata
Version
- Current Version: 1.0.0
- Last Updated: 2025-01-01
- Compatible Platforms: Claude, ChatGPT, Gemini
Tags
#file-organization #project-structure #folder-structure #naming-conventions #utilities
Examples
Example 1: Basic usage
<!-- Add example content here -->
Example 2: Advanced usage
<!-- Add advanced example content here -->