The full new-project workflow
Here's the exact sequence you'll use every time you start something new:
Step 1: Create and navigate to your project folder
cd ~/Developer/Personal
mkdir my-app
cd my-app
Step 2: Initialize Git
git init
Step 3: Set up your project
For a Next.js app:
bun x create-next-app@latest .
For a blank TypeScript project:
bun init
Step 4: Make your initial commit
git add .
git commit -m "chore: initial setup"
Step 5: Create the GitHub repository and push
gh repo create my-app --private --source=. --remote=origin --push
The flags mean:
--private— only you can see it (change to--publicfor open source)--source=.— use the current folder--remote=origin— name the remote "origin"--push— push your first commit automatically
Step 6: Open in VS Code and Claude Code
code .
claude
Your workflow from here: make changes in VS Code, run commands in Ghostty, use Claude Code to get help.
Cloning an existing repo
When you want to work on an existing GitHub project:
cd ~/Developer/GitHub
gh repo clone owner/repo-name
cd repo-name
bun install
code .
claude
Good first prompts
Once you're in Claude Code, start with this to help Claude understand the project:
Read CLAUDE.md and the project structure. Summarize what this project does, the main commands, and any conventions you notice. Don't edit anything yet.
Then for any task:
Implement this incrementally. Before editing, explain which files you plan to touch. Keep changes small and follow CLAUDE.md.
Repo starter files
Every project should have these files from day one:
| File | Purpose |
|---|---|
README.md | What the project is and how to run it |
.gitignore | What files Git should ignore |
.env.example | Template showing what env vars are needed (no real values) |
CLAUDE.md | Instructions for Claude Code |
Never commit .env files
Keep your real .env file out of Git. Use .env.example to show what variables are needed, with placeholder values. Anyone cloning the repo can copy .env.example to .env and fill in their own values.