← Resources VS Code track · Getting started

How to create anything

The seven step recipe for kicking off any project. New folder, Claude Code, a PRD, plan mode, then build. The same opening moves every time, so you never sit staring at an empty window wondering where to begin.

The whole page in four words

Slow is smooth.
Smooth is fast.

The recipe works because it forces you to think before you build.

Adapted from my own Code Explorer course.

This is the practical routine: what you actually click, in order, to start a project. The thinking method behind it is the 4D Build, and the ten projects to practise it on are in the VS Code Practice Lab.

The recipe

Seven steps, every project

Steps 1 to 3 take about two minutes. Steps 4 to 7 are the ones that decide whether the build goes well.

New project folder

Create a new folder on your desktop and give it a meaningful name. This is your workspace, and everything for this project lives inside it.

Open it in VS Code

Right click the folder and choose Open with Code. Or from inside VS Code, File → Open Folder.

Start Claude Code

View → Command Palette, then Open Claude Code in a new window. Now you have a coding agent sitting beside your files, able to see and edit them.

Write a PRD before anything else

Tell Claude what you are building: what it does, who uses it, and what it has to do. That is a product requirements document, and it is the difference between a build that lands and one that wanders. Do not skip this. If you want it done properly, the free prd skill interviews you and writes it for you.

Use voice and plan mode

Talking is faster than typing, so use voice input for the long explanations. Then turn on plan mode with Shift + Tab twice, which makes Claude design the approach and show it to you before it writes a single line of code.

Move slow

AI is optimised for speed, and it will hand you a fast answer that is not always a correct one. Move slow. Verify what it tells you. Do not just accept the first reply because it arrived quickly and sounded confident. This is the step people skip, and it is the one that costs them the afternoon.

Set up `/hello` and `/goodbye`

Claude does not remember your project between sessions. So for anything you will work on across more than one sitting, you write the handoff yourself: /goodbye saves where you got to and what comes next, and /hello reads it back at the start of the following session. Two commands, and the project picks up instead of starting over.

The setup prompt, straight from my Code Explorer course. Paste it once per project and Claude creates all three files.

Set up this project to solve Claude's memory problem across sessions. Create three files inside this project folder. File 1: .claude/commands/hello.md The user is starting a session on this project. BEFORE YOU RESPOND read these files in this order: 1. README.md, what this project is and where it's going 2. SESSION-NOTES.md, what's been done and what's next 3. Then list the project folder and read the main work files to see what actually exists right now If any of these files don't exist yet, this is session 1. Skip the missing files. Treat the conversation as a project-scoping discussion: ask the user what they want to build, help them draft a README, and create both README.md and SESSION-NOTES.md before going further. PROJECT RULES Match the project's existing stack. Read what's there before suggesting anything. Do not introduce new tools, frameworks, libraries, or build systems without asking the user first. Keep complexity proportional to actual needs. Do not add what was not asked for. NOW RESPOND in plain text (no markdown headers or bullet symbols) with a 6 to 8 line briefing covering: 1. What has been built so far based on the project files and session notes 2. Anything incomplete, broken, or worth flagging from last session 3. What we are working on today based on the plan in SESSION-NOTES.md 4. Any visible drift between what the README says the project should be and what is actually built Keep the briefing tight. The user wants context, not a lecture. File 2: .claude/commands/goodbye.md The session is ending. BEFORE YOU RESPOND work through these steps in order. STEP 1: Review actual work done Read the project files. Read the most recent entry in SESSION-NOTES.md (the previous session). Compare what is in the project now against what that previous entry said had been built. List the delta, what is actually new this session. Be specific. Name the features or changes, not just "made progress". STEP 2: Flag issues List anything broken, incomplete, or worth carrying forward. If nothing is broken, say so clearly. That is worth noting too. Read README.md and check if today's work conflicts with, extends, or is missing from the vision. If the README needs updating, note that for next session. STEP 3: Write the session summary Append a new entry to SESSION-NOTES.md with today's date and session number. Increment the session number from the previous entry. If SESSION-NOTES.md does not exist yet, create it and start with session 1. The entry includes three things: - What was built (3 to 5 specific points) - Any issues to carry forward - Plan for next session STEP 4: Close out End with one sentence summarising the session. Then say: "Type /hello next session to pick up where we left off." Use plain text throughout. No markdown symbols. No hashtags or asterisks. File 3: CLAUDE.md (in the project root, not inside .claude) This project uses two slash commands to solve Claude's memory problem across sessions. /hello at session start: loads README.md, SESSION-NOTES.md, and the current project state, then briefs the user /goodbye at session end: reads the actual project files, writes a session note so the next /hello has accurate context Data files the commands work with: - README.md, the project vision (created during session 1 if it does not exist) - SESSION-NOTES.md, the session log (appended by /goodbye) NUDGE BEHAVIOUR (you, Claude, follow this every session) When this CLAUDE.md loads at the start of a conversation, check the conversation's first user message: If the user begins project work without running /hello first this session, drop a single one-line nudge at the END of your first reply: "By the way, want to run /hello first? It will load README and SESSION-NOTES so I am caught up on the project." If the conversation appears to be wrapping up (the user says things like "thanks", "let us stop", "good for tonight", "let us continue tomorrow", "I am done", or similar closing language), drop a single one-line nudge: "Heads up, running /goodbye now will save what we did this session so the next /hello has it. Want to?" Discipline that keeps this from being annoying: - One nudge per session per command. Never repeat the same nudge in the same session. - If the user has already run the relevant command this session, never nudge for it. - If the user explicitly says they do not want to use /hello /goodbye this session, respect that. No further nudges that session. - Do not manufacture a wrap-up signal. Only nudge for /goodbye if the user's own words suggest they are closing the session. - Nudges go at the end of your reply, not at the start. They are gentle reminders, not blockers. After creating all three files, confirm they are in place and tell me to type /hello at the start of every session from now on.

What you learned

Every project starts the same way: a named folder, opened in VS Code, with Claude Code beside it.
The PRD is the real first step: say what you are building before anyone builds it.
Plan mode before code: see the approach, agree it, then let it run.
Fast answers are not always right answers: verify as you go.
Write the handoff if the project will outlive one session.

Slow is smooth. Smooth is fast.

Where next

You have the setup. Now build something with it: the VS Code Practice Lab → has ten projects with a ready made prompt for each one. For the thinking method behind the whole approach, meet the 4D Build →

McCloskey.ai · Resources. Built for people learning to build with AI in VS Code.