Everything from today, whenever you need it.
Prompts to copy and paste while we're working together, plus a reference you can come back to on your own, whenever you're starting something new.
Assembled by a human operating on vibes,
in partnership with Claude, who tried to bring some logic.
Proceed with low expectations and high curiosity. ✦
Copy, paste, go.
Two prompts worth keeping around — one for setting a new machine up, one for kicking off a new project the right way.
Toolchain check
Run this first on any machine, to make sure everything you need is installed before you start building.
Check what's installed on this machine for building and deploying a small
web project. I'll need Xcode command line tools, Node.js, npm, Wrangler,
and the GitHub CLI. Tell me what's already there and what's missing, then
install each missing one, asking me before you run anything. Let me know
when everything's installed and confirmed working.Project kickoff
Use this any time you're starting something new. Fill in the brackets with your own idea — Claude will ask questions before it creates anything.
I want to start a new project called [PROJECT NAME]. Here's what it does:
[ONE OR TWO SENTENCE DESCRIPTION].
Before creating anything, do this:
1. Always ask me questions to ensure you have everything you need before executing.
2. Propose a local folder structure. Default to something small, a CLAUDE.md
file at the root. A Docs folder with Design documentation, Standards
documentation, and Change Log inside it. Suggest a Data folder and or a
Preview folder if this project needs them.
3. Draft the CLAUDE.md content and show it to me before creating it.
Keep it short, just what this project is, the stack, and any hard rules
I give you.
4. Propose a name for a new GitHub repo for this project.
5. Wait for me to say go before creating anything.
6. Always update applicable project documentation as we go so it stays up
to date.Two ideas worth understanding.
Not exhaustive — just the two things that make everything else make more sense.
What CLAUDE.md is
A file Claude re-reads at the start of every session. It's how you stop repeating yourself — notes you leave for yourself, not documentation in the boring sense. What the project is, how it's built, and any rules you don't want forgotten.
What Plan Mode does
It separates thinking from doing. Claude proposes an approach first, and nothing gets written until you approve it. Nothing breaks until you say go — which makes it a good default whenever you're not sure what you want yet.
For whatever you build next.
A working reference, not a rulebook — pick it back up any time you start something new.
Getting set up
- Keep one project folder for everything you build — not the Desktop — with a clear, consistent name per project.
- Install the toolchain once, up front: Xcode command line tools, Node.js, npm, Wrangler, and the GitHub CLI. The toolchain check prompt does this for you.
- Where a tool supports it, prefer installing at the project level over installing globally — it keeps one project's setup from quietly affecting another. This mostly applies to npm packages; CLIs like Wrangler and the GitHub CLI are inherently machine-wide.
Working with Claude
- Use Plan Mode before code gets written — talk through the approach first, approve it, then build.
- State your objective and any specifics up front, and let Claude ask clarifying questions rather than guessing at what you meant.
- Budget iteration by scope, not a fixed number. A real feature might take ten to twenty rounds of back and forth; a small one-off might only need a few.
Keeping projects legible over time
- Keep living docs: CLAUDE.md at the root, plus a Docs folder with Design documentation, Standards documentation, and a Change Log.
- When something needs correcting, say "read the CLAUDE.md" or "read the standards" instead of re-explaining the rule each time — this only works if the files stay short.
- Update the change log as you go, not just at the very end.
Shipping without fear
- Start with the smallest real version of the thing — one page live beats a big unfinished one.
- Use checkpoints and rewind freely. You cannot permanently break anything, so it's safe to experiment.
- Follow the same lifecycle every time: local dev, then commit, then a preview deploy, then production. Look at the preview before you promote it.
- With no build step, you can just open the HTML file locally to see a change — no Wi-Fi or deploy needed to keep iterating.
Leveling up
- Test a risky or complicated idea on a small, low-stakes project first — before you bet it on something that actually matters to you.