Before you point Claude at a problem, give it a home: a small project folder with standing instructions and version control from line one. Two minutes of setup buys Claude context and buys you an undo button.
CLAUDE.md so Claude knows the project, and
git init + commit the whole thing locally so every change
after that is something you can see and undo. No GitHub account required.
A predictable layout means you and Claude always know where inputs, generated code, and finished artifacts live. A good default:
my-project/ ├─ CLAUDE.md # standing instructions: what this project is, conventions ├─ .gitignore # keep junk and secrets out of version control ├─ data/ # inputs YOU bring: CSVs, PDFs, datasheets, drawings ├─ src/ # code Claude writes: scripts, solvers, notebooks ├─ out/ # generated artifacts: HTML explorers, PDFs, charts └─ notes/ # scratch, references, decisions worth keepingfolder layout
The split matters: data/ is read-only source you provide,
out/ is disposable and regenerable, and src/ is
the reproducible recipe between them. When something looks wrong, you know
which drawer to open.
mkdir -p my-project/{data,src,out,notes} && cd my-projectbash / zshNew-Item -ItemType Directory my-project\data, my-project\src, my-project\out, my-project\notes -Force cd my-projectPowerShell
This is the file Claude reads first, every session. Keep it short and declarative — what the project is, what conventions to follow, where things go:
# Project: Pump skid sizing What this is: calculations and reports for selecting the pump, motor, and bearings on the CW-2 skid. Conventions: - Inputs live in data/ (read-only). Never edit them in place. - Scripts go in src/ and must run start-to-finish unattended. - Reports render to out/ as both a self-contained .html and a PDF. - Units are SI unless a datasheet forces otherwise; state assumptions. - Verify every result against an independent check before I see it.CLAUDE.md
Keep generated clutter and anything secret out of the commit:
# generated / disposable out/ *.pdf __pycache__/ .venv/ node_modules/ # secrets — never commit these .env *.key.gitignore
out/
keeps the repo lean since artifacts regenerate from src/. If
a particular PDF is the deliverable you want to track, commit
that one explicitly with git add -f out/report.pdf.
git init git add -A git commit -m "Initial project scaffold"bash / PowerShell
That's the baseline. From here, commit after every meaningful step — before and after you let Claude make a big change — so you can always see exactly what moved and roll back if it went sideways.
git init on
your laptop already gives you the two superpowers that matter:
git diff shows precisely what Claude changed, and
git restore / git checkout rewinds a bad edit in
one command. Pushing to GitHub is a separate, optional step for when you
want a backup or collaborators.
You can hand the whole thing to Claude in one prompt:
data/ src/ out/ notes/, write a CLAUDE.md describing ‘pump skid sizing’ with the conventions above, add a sensible .gitignore that ignores out/ and secrets, then git init and make the first commit. Show me the git status and the diff before committing.
Asking it to show status and the diff before
committing is the habit worth keeping: you review, then it commits. Never
a black box.
CLAUDE.md gives standing instructions per project.
The other half of setup is standing instructions per role —
and the cheap way to get them is a tiny shell script that launches
claude preconfigured. Put a few on your PATH and
you start exactly the right Claude with one word: a fast, cheap document
worker; a careful reviewer; a heavyweight solver.
A profile script bakes in four things — system prompt, model, effort, and which credentials to use — then hands the session to you:
#!/usr/bin/env bash # claude-transcribe — cheap, faithful document worker (the Sonnet worker) export ANTHROPIC_API_KEY="$(cat ~/.secrets/anthropic.key)" exec claude --model sonnet --effort low \ --append-system-prompt "Transcribe faithfully; never summarize or round. \ YAML for tables and specs, Markdown for prose. Flag anything illegible." "$@"~/bin/claude-transcribe
#!/usr/bin/env bash # claude-review — meticulous reviewer on the heavy model export ANTHROPIC_API_KEY="$(cat ~/.secrets/anthropic.key)" exec claude --model opus --effort high \ --append-system-prompt "You are a meticulous reviewer. Surface correctness \ bugs only, cite file:line, and skip style nits." "$@"~/bin/claude-review
chmod +x ~/bin/claude-transcribe ~/bin/claude-review # then: claude-transcribe data/datasheet.pdf | claude-reviewmake them runnable
The flags are real: --append-system-prompt (or
--system-prompt-file for a longer one), --model,
and --effort all apply to that launch. exec hands
your terminal straight to Claude. "$@" passes through anything
you add — a file, a -p prompt — so the profile
composes with normal use.
ANTHROPIC_API_KEY (read from a
chmod 600 secrets file, never hard-coded), a
CLAUDE_CODE_OAUTH_TOKEN from claude setup-token,
or an apiKeyHelper setting that fetches a rotating key from a
vault. One trap to skip: CLAUDE_CONFIG_DIR does not
isolate accounts — it only moves where credentials are stored, not
which identity you are. Set the key or token explicitly.
.claude/output-styles/<name>.md) give committable,
shareable system-prompt personas you switch with /config
— but they don't set model, effort, or auth. So: output styles for
tone, a wrapper script when you also want the right model, effort, and
account in one word.
This is also where the
token-economy routing stops being a
decision you make each time and becomes a default you launched into:
claude-transcribe is the Sonnet worker from
feed it documents — right model, low
effort, transcription prompt, baked in.
Every problem on this site assumes you have somewhere to put the inputs, somewhere for Claude to write code, and a way to undo a wrong turn. A scaffolded folder under local git is that somewhere. Set it up once; reuse the shape for every project. Next on the trunk: feeding it documents efficiently, then shipping the work.