file-management

name	file-management
model	sonnet
description	Produces a documented directory structure plan — tree layout diagram, naming convention decision, and organizational philosophy — applying patterns such as feature-domain grouping, temporal prefixes for dated artifacts, numbered directories for ordered sequences, and pointer READMEs for navigating large trees. Use when: 'organize this project structure', 'plan a file layout', 'design a directory hierarchy', 'improve folder organization', 'create a project structure'.
category	skill-forge
triggers	["organize this project structure","plan a file layout","design a directory hierarchy","improve folder organization","create a project structure"]
tier	1
agents	["primary"]
tool_dependencies	["file_system"]
inputs	[{"name":"project_description","type":"string","description":"Description of the project or codebase to organize","required":true},{"name":"constraints","type":"string","description":"Naming or organizational constraints to apply","required":false}]
outputs	[{"name":"directory_plan","type":"string","description":"Documented directory structure plan with tree layout diagram, naming convention decision, and organizational philosophy"}]

File Management & Organization Skill

I. Recommended Patterns

These are flexible patterns that can be adapted to different environments.

1. The Generic Web Application

This is a good starting point for many web applications.

/
├── public/             # Static assets (images, fonts, etc.)
├── src/                # Source code
│   ├── api/            # Backend API handlers/controllers
│   ├── components/     # Reusable UI components
│   ├── lib/            # Shared libraries, utilities, and helpers
│   ├── pages/          # Page-level components (if using a framework like Next.js)
│   ├── services/       # Business logic and external API clients
│   └── styles/         # Global styles
├── tests/              # Tests
├── .env                # Environment variables
├── .gitignore
├── package.json
└── README.md

2. The AROMA-style Contemplative Repository

This pattern is optimized for knowledge bases and contemplative practice repositories.

/
├── seeds/              # Reusable patterns of thinking
├── thinking/           # Philosophical reflections and insights
├── conversations/      # Summaries of key discussions
├── docs/               # Formal documentation (specifications, retrospectives)
├── SKILLS/             # Reusable workflow skills
├── prompts/            # Prompts for other agents (e.g., implementation agents)
├── .gitignore
└── README.md

3. The Go Backend Service

A common structure for a Go backend service.

/
├── cmd/                # Main application entry points
│   └── api/            # The main API server
├── internal/           # Private application and library code
│   ├── handlers/       # HTTP request handlers
│   ├── models/         # Database models
│   └── store/          # Database access layer
├── pkg/                # Public library code (if any)
├── .gitignore
├── go.mod
└── README.md

---

II. Naming Conventions

Apply one of these consistently across the project:

• kebab-case (my-component.js) — preferred for web projects and knowledge bases
• snake_case (my_component.py) — preferred for Python and data projects
• PascalCase (MyComponent.tsx) — reserved for class files and React components only; do not apply to directories

Temporal prefix pattern — prefix dated artifacts with YYYY-MM-DD_ so they sort chronologically without a separate timestamp field:

docs/
├── 2026-01-15_architecture-decision.md
├── 2026-03-02_retrospective.md
└── 2026-04-07_migration-plan.md