playbooks

home / skills / oimiragieo / agent-studio / recommended-folder-structure

recommended-folder-structure skill

/.claude/skills/_archive/dead/recommended-folder-structure

This skill enforces a standard root-level folder layout, guiding you to organize projects with cmd, internal, templates, static, and core modules.

npx playbooks add skill oimiragieo/agent-studio --skill recommended-folder-structure

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
1.5 KB
---
name: recommended-folder-structure
description: Enforces specific folder structure at root level.
version: 1.0.0
model: sonnet
invoked_by: both
user_invocable: true
tools: [Read, Write, Edit]
globs: '*'
best_practices:
  - Follow the guidelines consistently
  - Apply rules during code review
  - Use as reference when writing new code
error_handling: graceful
streaming: supported
---

# Recommended Folder Structure Skill

<identity>
You are a coding standards expert specializing in recommended folder structure.
You help developers write better code by applying established guidelines and best practices.
</identity>

<capabilities>
- Review code for guideline compliance
- Suggest improvements based on best practices
- Explain why certain patterns are preferred
- Help refactor code to meet standards
</capabilities>

<instructions>
When reviewing or writing code, apply these guidelines:

The recommended folder structure is:

cmd/
main.go
internal/
handlers/
models/
templates/
static/
css/
js/
go.mod
go.sum
</instructions>

<examples>
Example usage:
```
User: "Review this code for recommended folder structure compliance"
Agent: [Analyzes code against guidelines and provides specific feedback]
```
</examples>

## Memory Protocol (MANDATORY)

**Before starting:**

```bash
cat .claude/context/memory/learnings.md
```

**After completing:** Record any new patterns or exceptions discovered.

> ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.

Overview

This skill enforces a specific root-level folder structure for projects, ensuring consistent layout and predictable organization. It checks for required directories and files and flags missing or misplaced items to help maintain clean, idiomatic repositories. Use it to standardize projects across teams and simplify build and deployment scripts.

How this skill works

The skill scans the repository root and validates presence and placement of the canonical entries: cmd/, main.go, internal/, handlers/, models/, templates/, static/, css/, js/, go.mod, and go.sum. It reports mismatches, missing files, and extra top-level items that violate the recommended layout. It can also suggest concrete actions to add, rename, or move files and folders to meet the standard.

When to use it

  • Onboarding new projects to a team-wide convention
  • Automated CI checks to prevent structural regressions
  • Code reviews focused on repository hygiene
  • Refactoring legacy repositories for clarity
  • Before releases or packaging to ensure predictable builds

Best practices

  • Keep only build- and API-exposed binaries in cmd/ and place per-command subfolders there
  • Use internal/ for non-public packages and group related code into handlers/ and models/
  • Place HTML templates in templates/ and serve static assets from static/css and static/js
  • Keep go.mod and go.sum at the root to allow standard go tooling to function
  • Avoid other top-level folders; prefer nested locations to reduce root clutter

Example use cases

  • Run as a CI step that fails the pipeline when required root items are missing
  • Integrate into a pre-commit hook to catch misplaced files before pushing
  • Scan an existing monorepo and generate a migration plan to the recommended layout
  • Provide actionable feedback during code review: exact moves/renames to apply
  • Validate starter templates created by project generators to ensure compliance

FAQ

Can the structure be customized for my organization?

Yes. The skill is intended as a baseline; you can adapt the required entries and mapping rules to match organizational needs.

What if my project needs additional top-level folders?

Prefer nesting those folders under existing directories. If a top-level folder is essential, add it to the allowed list and document the exception.