project-setup
Set up a new project with standard structure, git, README, CLAUDE.md, and dev server config. Use when starting a new project or bootstrapping a workspace for a new initiative.
Best use case
project-setup is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Set up a new project with standard structure, git, README, CLAUDE.md, and dev server config. Use when starting a new project or bootstrapping a workspace for a new initiative.
Teams using project-setup should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/project-setup/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How project-setup Compares
| Feature / Agent | project-setup | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Set up a new project with standard structure, git, README, CLAUDE.md, and dev server config. Use when starting a new project or bootstrapping a workspace for a new initiative.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Project Setup Skill
Use this skill when creating a new project. It establishes a consistent structure across all projects.
## When to Use
- Starting a new project
- User asks to "set up a project" or "create a new project"
- Bootstrapping a workspace for a new initiative
## Project Location
All projects live in: `~/Developer/Projects/{project-name}/`
Use kebab-case for project names (e.g., `site-editor-navigation`, `wp-cowork-plugin`).
## Standard Structure
```
{project-name}/
├── .git/ # Initialized git repo
├── .gitignore # Standard ignores (see below)
├── README.md # Project overview, quick start
├── CLAUDE.md # Guidance for Claude Code / AI agents
├── docs/ # Documentation
│ ├── overview.md # Project overview (always create this)
│ └── (other docs)
└── logs/ # Session logs, dev notes (git-ignored)
└── (daily logs)
```
## File Templates
### README.md
```markdown
# {Project Name}
{One-line description}
## Overview
{Brief explanation of what this project does and why it exists}
## Quick Start
```bash
cd ~/Developer/Projects/{project-name}
# Add setup commands here
```
## Documentation
| Doc | Description |
|-----|-------------|
| [docs/](docs/) | Project documentation |
## Structure
```
{project-name}/
├── docs/ # Documentation
├── logs/ # Development logs (git-ignored)
└── README.md # This file
```
## Related
- {Links to related issues, PRs, projects}
```
### CLAUDE.md
```markdown
# CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
## Project Overview
{One-line description of what this project is and its goal}
## Development
```bash
# Add common commands here
```
## Architecture
{Brief description of tech stack, key patterns, important files}
## Documentation
The `/docs/` folder contains:
- {List key docs}
## Scope
- **In scope**: {What this project covers}
- **Out of scope**: {What it doesn't cover}
```
### docs/overview.md
Always create this file. It's the canonical project overview document — the first thing someone reads to understand the project.
```markdown
# {Project Name} — Overview
## What Is This?
{2-3 paragraphs explaining what the project does, why it exists, and how it works}
## Architecture
{How the project is structured — tech stack, key patterns, data flow}
## Links
- **Repo:** {URL}
- **P2/Discussion:** {URL if applicable}
- **Related:** {Other relevant links}
## Key People
- **{Name}** — {Role/context}
## What's Next
{Current focus, open questions, next steps}
```
**Required sections:** What Is This, Links. Other sections should be included when the information is available. Always capture links — they go stale fast and are hard to recover later.
### .gitignore
```gitignore
# Logs - development session logs, not for version control
logs/
# Dependencies
node_modules/
vendor/
.venv/
__pycache__/
# Build outputs
dist/
build/
*.egg-info/
# Environment
.env
.env.local
.env*.local
# IDE / Editor
.idea/
.vscode/
*.swp
*.swo
*~
# OS
.DS_Store
Thumbs.db
# Package manager locks (uncomment if not needed)
# package-lock.json
# pnpm-lock.yaml
# composer.lock
```
## Setup Procedure
1. **Create project directory**
```bash
mkdir -p ~/Developer/Projects/{project-name}
cd ~/Developer/Projects/{project-name}
```
2. **Create folder structure**
```bash
mkdir -p docs logs
```
3. **Create .gitignore** (use template above)
4. **Create README.md** (use template above, fill in project details)
5. **Create CLAUDE.md** (use template above, fill in project details)
6. **Create docs/overview.md** (use template above — always include What Is This and Links sections at minimum)
7. **Initialize git**
```bash
git init
git add -A
git commit -m "Initial project setup"
```
8. **Report to user**
- Confirm project location
- List created files
- Suggest next steps (e.g., "Ready for docs, or should I scaffold something specific?")
## Optional Additions
Depending on project type, may also create:
- **package.json** — For Node.js projects
- **requirements.txt** — For Python projects
- **composer.json** — For PHP projects
- **Makefile** — For projects with build steps
- **docker-compose.yml** — For containerized projects
Ask the user if they want any of these, or infer from context.
## Dev Server Projects
For projects with a dev server (Vite, webpack, Next.js, etc.):
### 1. Reserve a Port
Use portkeeper to avoid conflicts:
```bash
portman reserve {PORT} --name "{project-name}" --desc "{description}" --tags {tags}
```
### 2. Configure Network Access
Always expose dev servers on the local network so they're accessible from phones/tablets.
**Vite (vite.config.js):**
```js
export default defineConfig({
server: {
port: {PORT},
host: true, // Expose on local network
},
})
```
**Next.js (package.json):**
```json
"scripts": {
"dev": "next dev -p {PORT} -H 0.0.0.0"
}
```
**Webpack (webpack.config.js):**
```js
devServer: {
port: {PORT},
host: '0.0.0.0',
}
```
**Generic Node/Express:**
```js
app.listen(PORT, '0.0.0.0', () => { ... })
```
### 3. Document Access
In README.md, include:
```markdown
## Development
Dev server: http://localhost:{PORT}
Network: http://{machine-ip}:{PORT} (for mobile testing)
```
The network IP can be found with `ipconfig getifaddr en0` (macOS).
## Logs Convention
The `logs/` folder is for development session notes:
- Format: `MM-DD-YYYY-HHMM.md` (e.g., `02-06-2026-1015.md`)
- Git-ignored so they don't clutter history
- Useful for tracking decisions, debugging sessions, progress
- **Create an initial log entry during project setup**
### Sample Log (logs/MM-DD-YYYY-HHMM.md)
```markdown
# {MM-DD-YYYY} {HH:MM}
## Session Focus
{What was worked on this session — one line}
## Notes
- {Key decisions, observations, or context}
- {Things tried, what worked, what didn't}
## Changes
- {Files created/modified}
- {Features added or bugs fixed}
## Next
- {What to pick up next time}
- {Open questions or blockers}
```
## After Setup
Once project is created:
1. Update Moneypenny (`~/Developer/Projects/moneypenny/projects.json`) if it's a tracked project
2. Add to memory if significant
3. Proceed with project-specific workRelated Skills
wordpress-mockups
Build accurate WordPress/Gutenberg UI mockups using pre-extracted design tokens, icons, and components. Use when prototyping WordPress admin interfaces or Site Editor concepts.
skill-creator
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
pressable
Manage Pressable WordPress hosting via API. Use when creating/cloning sites, managing backups, purging cache, updating PHP versions, managing plugins, checking site status, or any Pressable hosting operations.
headless-browser
Browse the web invisibly using a headless Chromium in Docker. Take screenshots, extract content, and generate PDFs without interrupting the user's screen.
design-mockups
Build and present HTML/CSS design mockups with a local preview server. Use when prototyping website designs, iterating on visual concepts, or presenting design options.
design-critique
Premium UI/UX design audit with Jobs/Ive philosophy. Evaluates hierarchy, whitespace, typography, color, motion, and responsiveness. Produces phased improvement plans without touching functionality.
design-atelier
End-to-end design pipeline from brief to coded prototypes. Gathers visual references, builds design systems, and produces HTML/CSS mockups via parallel sub-agents. Supports multi-prompt projects.
ddg-search
Search the web. Use for general lookups, research, and finding information online.
blogger
Create, edit, and publish blog posts with consistent voice and style. Helps build and maintain a style guide, write drafts, edit for quality, optimize SEO, and fact-check claims before publishing.
VibeCollab — Setup Instructions for AI Assistants
You are helping a user set up VibeCollab in their project.
plan-creating-project-plans
Comprehensive project planning standards for plans/ directory including folder structure (ideas.md, backlog/, in-progress/, done/), stage-aware naming convention (backlog/done use YYYY-MM-DD__identifier/, in-progress uses identifier/ with no date prefix), five-document file organization (README.md, brd.md, prd.md, tech-docs.md, delivery.md for multi-file default; single README.md for trivially-small single-file exception), BRD/PRD content-placement rules, Gherkin acceptance criteria, and the mandatory structured multiple-choice grilling gates (pre-write and post-write) for resolving design decisions with the user. Essential for creating structured, executable project plans.
LinkedIn Auto-Commenter — Project Standards
## Comment Quality