Copy-paste prompts for Claude Code, and how to size a session.
Keep this open in a tab for your first few weeks. Everything here is the beginner-sized version of a real working practice — see README.md Part 6 for the reasoning.
Setting up for the first time? Use
WALKTHROUGH.mdinstead — eight stages from nothing to a live site, each with one short prompt. Come back here afterwards.
In this file: the shape of a good ask · what makes one session · the prompt library · anti-patterns
The prompts in the walkthrough all look like this:
Do Stage 4 of WALKTHROUGH.md.
That is not laziness — it is the most useful habit in this whole kit. Keep the instructions in a file, then point at the file. A long prompt gets retyped differently every time, half-remembered, and quietly drifts. A file does not: you can read it, correct it, and know that what you corrected is what runs next time.
So when you find yourself explaining the same thing to Claude Code twice, stop typing and
write it down instead — in AGENTS.md if it is a rule, in a task file if it is a job.
Then the prompt becomes one line.
A weak ask gets a weak result, and it is almost always weak in the same six ways. Before you hit enter, check that your ask answers these. Not all six every time — but if you cannot answer 1 and 6, stop and think, because nothing else will save it.
| # | The question | Weak | Strong |
|---|---|---|---|
| 1 | What is the one thing to produce? | “clean up my repo” | “write a .gitignore for this folder” |
| 2 | What shape should the output be? | “document this” | “a README.md at the repo root, under 200 lines” |
| 3 | What should it use? | — | “read START_HERE.md first; use the existing scripts/bootstrap” |
| 4 | What must it NOT touch? | — | “only edit files in src/. Do not touch data/ or anything already committed” |
| 5 | How much effort is this worth? | — | “quick pass, don’t over-engineer” / “this is the important one, take your time” |
| 6 | How will we know it worked? | “make it good” | “npm run build exits 0 and the page shows the new heading” |
Field 6 is the one beginners skip and the one that matters most. “Done” has to be
something you can check, not something the agent claims. An agent that says “I’ve
fixed it” has told you nothing. An agent that says “npm run build now exits 0, here is
the output” has told you something.
A session is one conversation with Claude Code, from opening it to closing it.
One session = one objective with one checkable finish.
If you cannot write the finish line in a sentence, you have more than one session.
| Good session | Why |
|---|---|
| “Set up git in this folder and make the first snapshot” | One outcome, obvious finish |
“Write a .gitignore for this folder and explain each line” |
Small, bounded, teaches you something |
| “Get this repo deploying to Netlify” | One outcome, checkable: the URL loads |
| “Fix this error: (paste the whole error)” | Finish = error is gone |
| Too big | Split into |
|---|---|
| “Build me a website and put it online” | (1) build the site locally, npm run build passes → (2) make it a repo and push → (3) connect the host and get a live URL |
| “Set up my whole workflow” | (1) install tools → (2) sign in to GitHub → (3) adopt the folder |
| “Clean up this project” | Pick one thing. “Clean up” has no finish line, so the session never ends and quality drifts. |
Do not open a session to run one command you already understand. If you know it is
git push, just run git push.
Adapt the bracketed bits. These are written to be pasted.
I've never used git or GitHub before. Check what's installed on this Mac
(git, gh, node) and tell me what's missing — but don't install anything yet.
Explain what each tool is for in one line.
Walk me through signing in to GitHub with the gh CLI. Go one step at a time:
run a step, show me what happened, and wait for me before the next one.
Tell me in advance which step needs me to do something in the browser.
Check my git setup is complete: am I signed in, does the `repo` scope exist,
and is my commit name and email set? Show me the actual output of each check,
not a summary.
Look at this folder and write me a .gitignore. For each line, tell me why it's
there — I want to understand the file, not just have one.
Flag anything that looks like a password, key, or token BEFORE we commit anything.
Turn this folder into a git repo and make the first snapshot.
Do the local part only — do NOT create anything on GitHub yet, and do not push.
Done when: `git log` shows one commit and `git status` is clean.
Make me a double-clickable file that saves a snapshot of this folder,
so I don't have to use the terminal. It should commit everything and print
my recent snapshots. Explain what it does before you write it.
Now push this to GitHub as a PRIVATE repo called [name].
Show me the URL when it's done. Confirm it's private before you create it.
I've been added to [owner]/[repo] on GitHub. Clone it into ~/code and then:
1. confirm the remote is right
2. prove I have write access WITHOUT changing anything real
3. find and summarise the project's own rules for me (README, START_HERE,
AGENTS.md, CLAUDE.md) — what am I not allowed to do here?
Don't edit any files this session.
Before I touch anything: read this repo's AGENTS.md and CLAUDE.md and tell me,
in plain English, the rules I'm most likely to break by accident as a newcomer.
I want to make my first change to this project: [describe it].
Read the project's rules first, then tell me your plan and which files you'd
touch — and stop. Don't make the change until I say go.
The fastest route is to adopt the starter pack — rules already written for someone new, so the agent knows what never to do before it touches anything:
Copy AGENTS.md and CLAUDE.md from [path to the starter folder] into this
project, then fill in the two placeholder sections in AGENTS.md:
- "About this project" — look at the folders and write a short, accurate
description. Don't invent a purpose; ask me if it isn't obvious.
- "How to check your work" — find the real command that proves this project
still works. If there genuinely isn't one, write that honestly instead of
making one up.
Leave every rule exactly as written. Show me the finished AGENTS.md before
you save it.
Or start from scratch:
Run /init and write a CLAUDE.md for this project.
Keep it short — it gets read at the start of every session, so length costs me.
Write an AGENTS.md for this repo covering: where things go, what must never
happen (deleting data, committing secrets, publishing without asking), and the
command to run to check the work. Then make CLAUDE.md a short pointer to it
so both Claude Code and other tools read the same rules.
Set up a minimal Astro site in this folder.
Done when `npm run build` exits 0 and `npm run preview` serves a page locally.
Don't add any features I didn't ask for — I want the smallest thing that works.
Make me a single index.html for a one-page site about [topic].
No frameworks, no CDN links, no build step — it has to work as a bare file
on GitHub Pages. Keep it readable on a phone.
This repo is ready to go live. Walk me through GitHub Pages setup one step at
a time. Tell me first: does this repo need to be public, and is there anything
in it I wouldn't want public?
Connect this repo to Netlify so it deploys on every push.
Pin the Node version in netlify.toml to match what I built with locally.
Done when: a push produces a live URL that loads.
Start from templates/ rather than a blank page — three finished academic
pages plus one theme.css that controls all of them.
templates/README.md holds the full set of design prompts —
changing fonts, self-hosting them, swapping the accent colour, adjusting line length,
adding pages, and checking a page before publishing. A taste:
I'm new to web design. Look at theme.css and explain, in plain English, what
each value in blocks 1-3 controls. Don't change anything yet — I want to
understand the file before I touch it.
Show me the same page with three different font pairings so I can compare
before I choose. Make three copies — font-a.html, font-b.html, font-c.html —
and tell me which one you'd pick for [my field] and why.
Don't touch the original files.
I want this to feel more [formal / warm / minimal / institutional].
Suggest three specific changes to theme.css, tell me what each one does, and
wait for me to pick before you change anything.
That last one is the pattern worth internalising for anything visual: ask for options and a recommendation, not a decision already made. Taste is yours; the CSS is the agent’s.
This is the one you will use most, so it is worth getting into your fingers. The shape of a good change request is four things: where · what · why · how careful.
Change request.
Page: About
Change: replace the second paragraph with this exact text —
[paste the text]
Why: the old version overstates what the project does.
Build it, show me the rendered result, and STOP. Don't deploy.
That last line is the whole discipline. Building and publishing are two decisions, and only one of them is the agent’s. Then, separately:
Approved. Commit, push, and once it's live, check the real URL and show me
the change is actually there.
Smaller, everyday versions:
On the home page, the intro paragraph is too long. Give me three shorter
versions and tell me which you'd pick. Don't change the file yet.
Add a publication to the list on index.html:
[paste the citation]
Match the format of the ones already there. Show me before you save.
Something looks wrong on my phone. Check the site at 375px wide and tell me
what breaks — don't fix it yet.
Log this in EDIT_REQUESTS.md as a new REQ, make the change, show me,
and wait. Mark it Done only after it's live and you've verified it.
⚠️ Never let “make the change” and “put it live” be the same sentence. The habit that protects you is boring and takes four extra words: show me, then wait.
Pull the latest, then show me what's changed since my last snapshot
before we do anything else.
Commit my changes with a sensible message and push.
Tell me the message before you use it.
I pushed 5 minutes ago and the live site hasn't changed.
Check whether the build actually succeeded, and show me the evidence.
This failed: [paste the ENTIRE error, all of it]
Tell me what it means in plain English and what my options are, with the risk
of each. Don't run anything yet — I want to understand before we act.
I think I've messed up my git history. Before you do ANYTHING:
tell me what state the repo is in and whether my work is safe.
Do not run any command that deletes, resets, or force-pushes.
⚠️ The most important prompt in this file is the last one. When something is wrong and you do not understand why, the danger is not the original problem — it is the confident fix that throws away your only copy. “Tell me first, don’t act” costs you thirty seconds.
We're stopping here. Write a handoff file in this folder covering:
- what's done and verified
- what's half-finished
- the exact next action
- anything you learned this session that isn't written down anywhere yet
Write it so that a fresh session with no memory of this conversation could
pick it up from the file alone.
Things that reliably produce bad sessions.
“Make it better.” No finish line, so it never finishes. Name the specific thing.
Letting it grind. If the same step fails three times, stop. The fix is not a fourth attempt — it is a better question. Ask “why is this failing?” instead of “try again.”
Trusting “done” without evidence. Ask for the output. “It builds now” is a claim; a build log exiting 0 is a fact.
Asking for four things at once. You get four half-done things and cannot tell which step broke. Ask for one.
Letting it work outside the folder. Say which folder it may write in, especially early on.
Keeping the plan only in chat. If the session ends — crashes, times out, you close the laptop — anything that existed only in the conversation is gone. Ask for it in a file, as it happens.
Handing vague work to a cheap fast model. Underspecified work needs the strong model, because working out what to do is the hard part. Once the spec is tight and the job is mechanical, a cheaper model is fine. The mistake is backwards-routing: giving the hard thinking to the fast model and the typing to the slow one.