github-repo-structure-builder
Skill2 starsChanged 7 months agoMITView on GitHub
Scaffold, design, and output standardized GitHub repository directory structures based on project type, language, or framework. Use when the user requests a new repo layout, asks for best-practice folder organization, or needs essential configuration files (.gitignore, CI/CD, docs, src, tests) generated. Do NOT use for executing git commands, writing full application code, managing remote repositories, or generating non-code documentation structures.
- Reads credentials
In this repository20 other files it gives its agents.
- api-design-standardizerSkill
- api-documentation-generatorSkill
- cloud-infrastructure-architectSkill
- cobol-to-javaSkill
- code-reviewSkill
- compliance-policy-auditorSkill
- database-performance-auditorSkill
- data-cleanupSkill
- incident-post-mortem-generatorSkill
- kaggle-notebook-generatorSkill
- meeting-transcriberSkill
- pdf-extractSkill
- python-structure-generatorSkill
- python-type-hinterSkill
- refactor-simplifySkill
- security-vulnerability-scannerSkill
- sql-query-optimizerSkill
- unit-test-generatorSkill
- user-story-generatorSkill
- web-researchSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 39
IF user intent includes running git commands (git init, push, clone)
- Distinctive: line 40
IF user requests full implementation code instead of structure
- Distinctive: line 41
IF user asks to manage remote repositories
- Distinctive: line 42
IF request is unrelated to software project structure
- Distinctive: line 51
IF project context is provided: Extract language, framework, project type, CI needs, constraints ELSE: Assume standard single-language …
- Distinctive: line 102
No secrets or unsafe placeholders
≈ “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
GitHub Repository Structure Builder
This skill guides the systematic generation of GitHub-ready directory trees and foundational configuration files. The user provides project context (language, framework, scope) and optionally requests specific tooling or conventions.
🎯 When to Use
- User asks to create a repo structure, scaffold a project, or organize folders
- User specifies a tech stack (Python/FastAPI, Node/Express, React/Next.js, Rust)
- User requests standard files such as
.gitignore,LICENSE,README.md, CI/CD workflows, ordocs/ - User wants best-practice conventions for monorepos, packages, or libraries
Do NOT Use
- IF user intent includes running git commands (
git init, push, clone) - IF user requests full implementation code instead of structure
- IF user asks to manage remote repositories
- IF request is unrelated to software project structure
🧠 Core Workflow
Step 1 — Ingest & Identify Context
IF project context is provided:
Extract language, framework, project type, CI needs, constraints
ELSE:
Assume standard single-language application layout
Step 2 — Blueprint & Structure Design
Map context → standard structure
INCLUDE:
- src/ | lib/ | app/
- tests/ | tests/
- config files (.env.example, package.json, pyproject.toml, Cargo.toml)
- .github/workflows/
- docs/, README.md, CHANGELOG.md
APPLY naming conventions based on ecosystem
Step 3 — Generate & Annotate
OUTPUT:
- ASCII directory tree
- File annotations (purpose / template hints)
- ⚠️ requires-configuration flags for sensitive fields
Step 4 — Validate
CHECK:
- No redundant paths
- CI/CD matches stack
- Required files present
- No secrets or unsafe placeholders
Step 5 — Return Output
RETURN:
- Directory tree (markdown code block)
- Structure manifest (JSON)
- Change log
📋 Output Format
Section 1 — Directory Structure
Return a Markdown fenced code block containing the generated tree.
Section 2 — Structure Manifest
{
"status": "success | partial | error",
"summary": {
"project_type": "",
"language_stack": "",
"files_generated": 0,
"directories_created": 0,
"config_files_included": []
},
"structure": [
{
"path": "src/",
"type": "directory | file",
"detail": "Purpose and recommended content or template reference"
}
],
"warnings": [
{
"path": ".github/workflows/ci.yml",
"issue": "Requires repository secrets or environment variables to function",
"rows_affected": ["CI_TOKEN", "DATABASE_URL"]
}
]
}
⚠️ Fallback Behavior
IF missing project context:
RETURN:
{
"status": "error",
"message": "Input does not specify a project type or technology stack.",
"suggestion": "Please specify the primary language, framework, or project goal (e.g., 'Python FastAPI web app', 'React frontend library')."
}
IF request is ambiguous:
ASK one targeted clarifying question
DO NOT assume architecture
DO NOT generate unsafe configs
🔁 Change Log
- v1.0 — Initial structured skill aligned to SKILL.md specification
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.

