Helmur Tactile Lab
← All modules
Module 0 · Week 1 · Day 1 Not started

Pick your project, set up your tools

Choose something fun to build and get Claude Code to make a first working piece of it on day one.

The brief Teacher's example

The brief

Pick something you would genuinely enjoy building. Two kinds of project work well:

  • A game. A word puzzle, a trivia game, a choose-your-own-adventure, a daily challenge.
  • A product you could build a brand around. A recipe finder, a gift picker, a habit tracker, a playlist namer.

The test: small enough to have a first version working by tomorrow, interesting enough that you’d tell a friend about it. You’ll spend the next three weeks with this thing, so pick something that makes you smile.

Why this matters

Every company starts as one person with an idea and a tool. You’re about to be both. The tool is Claude Code: an AI that can read, write and run things on your computer while you talk to it in plain English.

Where to start

You’ll be tempted to read about AI first. Don’t. Open Claude Code and tell it what you want to build. When it asks something you don’t understand, ask it to explain. When it does something you didn’t expect, ask why.

Getting lost is part of the course. The skill you’re building today is asking for help in a way that gets you unstuck.

If you finish early, ask Claude to make your first version a little more fun. Then save it.

Set up your project files

Do this before you build anything. Claude starts every session with no memory of the last one. These files are its memory, and yours.

FileWhat it’s for
CLAUDE.mdWhat the project is, how it’s built, and how Claude should work on it. Claude reads this first, every session.
README.mdWhat this is, for a person arriving cold
DECISIONS.mdChoices you’ve made and why, so you don’t argue them again next week
HANDOFFS.mdWhere the last session stopped and what’s next
TODO.mdWhat’s left, in order
CHANGELOG.mdEvery change worth noting, newest first
RELEASENOTES.mdNews for the people who use your thing

You don’t need to write them yourself. One prompt does it:

Set up project files for this project: CLAUDE.md, README.md, DECISIONS.md, HANDOFFS.md, TODO.md, CHANGELOG.md and RELEASENOTES.md. Fill in what you already know from our conversation and leave clear placeholders for the rest. In CLAUDE.md, add a rule that every session starts by reading CLAUDE.md, DECISIONS.md, TODO.md and HANDOFFS.md, and ends by updating them.

The test: close Claude Code, open a fresh session, and ask “what is this project and what should we do next?” If the answer is right, your files work.

What your reviewer will look for

These come up in almost every review of this module. Get ahead of them.

  • The project is too big. Cut it to one level, one feature, one screen.
  • Fear of the terminal. It's a chat window that can touch files. That's all.
  • Not asking Claude what something means. You're allowed to, every time.
  • Skipping the project files because they feel like admin. They're Claude's memory.

Skills this module tends to surface:

Specific promptingContext management

Submit for review

Fill this in, copy it, and post it in the cohort channel. Reviews focus on your process as much as the result, so be honest about where you got stuck.

Teacher's example

How Prashant did Module 0

The project: This site. Prashant's project for the course is the course itself: Helmur Tactile Lab and Course 01, Learning AI by Building.

The first working version was running on Prashant’s laptop the same day he dictated the pitch. Most of the effort wasn’t in any single prompt. It was in saying clearly what he wanted, then checking what came back.

Two things to notice. First, none of these prompts are clever. They’re plain requests, one with typos and one dictated with ums. Second, every time Claude got it wrong, the fix was more specifics, not a better phrasing.

Your project will be different, so don’t copy these choices. Copy the habits.

  1. 1Three sentences to start, then a better idea out loud
  2. 2Claude Code in a folder, and a name for the session
  3. 3A folder, then a private repo
  4. 4Project files: from an ambiguous ask to a reusable skill
  5. 5A reference, a goal, a constraint and a pace

Task 1 of 5 · A one-paragraph pitch for your project: what it is, who it's for, why it's fun

Three sentences to start, then a better idea out loud

The prompts

Prashant → Claude Code

This project is going to be us creating an online course for AI for my Marketer/non-tech friends. I'm going to call it Learning AI by Building. I think I will launch this on learn.helmur.com when it is read.

Day 1. Typo and all. It doesn't need to be polished to work.

Prashant → Claude Code Dictated
Hey, sorry, this fell off the radar a bit. Uh, I'm just coming back to it. Um, I read your uh, set of questions um, that will help shape everything else. And honestly, I want to take a slightly different approach here. I want to throw my Uh, let's call them my flock, uh, my sheep, uh, my kids, into the deep end of the pool. Um, my approach to helping them learn um, AI is to just directly go and start building somethi… Read the whole prompt (467 words)

ng. And that starts with first um, coming up with a project they have in mind. Um, and I've been Um, pushing people to towards something fun um, uh, like uh, building a game or uh, building something uh, product-y that uh, they can build a whole brand around. And so the course will take the shape of you build the game or the product You build the website, um, you build uh, the brand, the look and feel obviously, and the product and messaging that goes um, around that product and into the website and other assets. And uh, you also um, uh, start uh, building uh, certain channels like blog articles like building content or social media that help augment the presence um, of your product. Um, and in doing so, um, you learn how to build multiple pipelines using AI, right? So you learn how to build your uh, product pipeline, uh, your shipping pipeline, um, your content pipeline, um, your brand and positioning pipeline. So now you've essentially built yourself, I would say almost like a mini company um, and then we can also start venturing into okay, how do you integrate with email, build an MCP server and uh, almost CRM uh, your little operation. Uh, so that's the shape I want my course to take. Um, and it'll start by helping them pick the tool. I would like to prescribe the tool, preferably preferably Claude Code, but I'm open to if they use multiple tools. Um, and yeah, um, along the way, they will learn how to do uh, better prompts. They will learn how to do adversarial Uh, AI, they will learn how to do automation. Right. So the whole learning by building means I'm not prescribing the actual uh, tactical pieces, which is write better prompts. But as they're building their product, and I review their work, I will say, okay, get more specific with your prompt. You know, get better with this. Get better with that. Right. Uh, so that's kind of how I plan to go about um, teaching them this. So if you have, can take this and sort of build an outline into uh, a course for me, or build an outline of a course for me, uh, that would be amazing.

Five days later. Dictated, not typed, ums included. Claude doesn't mind, and talking is often faster than writing when the idea is still forming.

What Claude did

After the first prompt, Claude saved the project to memory and asked five questions: what learners build, which tools, what format, which site and what timeline. The questions went unanswered. The dictated prompt five days later replaced the original plan entirely, and Claude turned it into a full course outline: eight modules, each with a brief, a ship list and a definition of done.

What came out

Learners start building on day one and finish with a mini company: a game or product, the brand around it, a live website, content channels and the operations that run it. Nobody learns "prompting" as a lesson. They learn it because their build needs it, and their reviewer tells them where to get better.
The pitch, as it ended up in the outline

Reviewer's note

The first prompt was enough to start, and that's the point: three sentences got a project folder, a memory and good questions. Ignoring the questions was fine too, because the dictated prompt was the real pitch. It says who it's for, what they build, what tool, and how they learn. Next time, answer the one question that blocks building, even if you skip the rest.

Specific prompting

Task 2 of 5 · Claude Code installed and signed in

Claude Code in a folder, and a name for the session

The prompt

Prashant → Claude Code

/rename [PROJ] Course

A built-in command, not a request. It names the session so you can find it again.

What Claude did

Nothing visible. Claude Code was already installed and signed in from earlier projects, so Module 0's setup was opening an empty folder and starting Claude Code inside it.

What came out

mkdir ~/src/projects/AI_course
cd ~/src/projects/AI_course
claude
The whole setup

Reviewer's note

Naming the session is a small habit with a big payoff once you have ten projects on the go. If this is your first time, setup is where you'll spend most of day one. Do it in the kickoff session, not alone at 11pm.

Context management

Task 3 of 5 · A GitHub account and a project folder saved to it

A folder, then a private repo

The prompt

Prashant → Claude Code

Let's get our course landing page up on our infra on railway...walk me through setting up the subdomain on cloudflare

GitHub never got its own prompt. It came up when it was time to ship, and Claude handled it.

What Claude did

The folder existed from day one. Claude made it a git repository when the first version was ready, saving a snapshot of every change from then on. When it was time to deploy, it created a private GitHub repo and pushed the project to it.

What came out

git init
git add -A
git commit -m "Course site v0.1: landing, course dashboard, 8 module briefs, skills"
gh repo create prashantkaw/learning-ai-by-building --private --source . --push
What Claude ran, in order

Reviewer's note

Doing this late worked out, but only because nothing went wrong in between. Save to git from the first working version. It's your undo button, and Claude can use it to show you exactly what changed. Private is the right default until you've decided otherwise.

Verifying

Task 4 of 5 · Your project files: CLAUDE.md, README, decisions, handoffs, to-do, changelog and release notes

Project files: from an ambiguous ask to a reusable skill

In short

Checked whether a scaffold already existed, found the same files had drifted across Prashant's projects, built a reusable /new-project skill from the best example, ran it on this folder, and filled in everything it already knew. Every session since has started by reading these files.

Step by step

  1. 1

    Ask whether it already exists

    Prashant → Claude Code

    did we create a way to scaffold a new project?

    Claude read "scaffold" as a website framework and offered to set one up. Fair guess, wrong one. Asking before building is still the right instinct: maybe it already existed.

  2. 2

    Clarify with specifics, not volume

    Prashant → Claude Code

    No, I mean we have a standard set of files we use for projects - claude.md, changelog.md, releasenotes.md, crossover.md, handoffs,md, decisions.md, readme,md, todo.md

    Listing the exact files ended the confusion in one message. Claude then searched Prashant's other projects and found that no scaffold had ever existed. Each project had been set up by hand, and the copies had drifted: TODO.md in some, TODOS.md in others, lowercase names, one-off handoff files.

  3. 3

    Let the evidence decide the details

    Prashant → Claude Code

    use whatever is closest to standard

    Claude asked two questions: one shared CROSSOVER file or one per project, and which filename casing. Instead of deciding from memory, Prashant pointed Claude at the evidence. It picked what most projects already did: all-caps names, TODO.md, and one shared CROSSOVER file.

  4. 4

    Build it once so you never do it again

    Rather than hand-writing seven files, Claude built a /new-project skill: templates for each file, based on the best-run existing project, plus a script that fills in the project name and date and never overwrites a file that already exists. It works on any future project, and it can fill gaps in old ones.

  5. 5

    Run it, then fill in what's known

    The skill created seven files. Claude then added what the conversation had already established, like the audience and the open questions, so the to-do list started with real items instead of blanks.

  6. 6

    Let the files do their job

    Every session since starts the same way: read CLAUDE.md, then DECISIONS.md, TODO.md and HANDOFFS.md. When the course went from 14 weeks to 3 and became Helmur Tactile Lab, each choice was logged with its reasons, so no later session reopened it.

What came out

$ /new-project
create  CHANGELOG.md
create  CLAUDE.md
create  DECISIONS.md
create  HANDOFFS.md
create  README.md
create  RELEASENOTES.md
create  TODO.md
What the skill created
## Session start protocol

1. Read this file
2. Read `DECISIONS.md` — the load-bearing choices and *why*, so they are not re-litigated
3. Read `TODO.md` for the active queue
4. Read `HANDOFFS.md` for where the last session stopped

## Session end protocol

1. Update `HANDOFFS.md` — where things stand, what is next, anything half-done
2. Log any load-bearing choice in `DECISIONS.md`
3. Tick or add items in `TODO.md`
The part of CLAUDE.md that does the most work
D-001 · Learn by building a mini company, skills come from review
D-002 · Astro + Tailwind static site, Helmur brand, Railway
D-003 · Three weeks, not fourteen
D-004 · Child brand "Helmur Tactile Lab", served at lab.helmur.com
A week later: what DECISIONS.md holds

Reviewer's note

This is the habit to copy. "Scaffold" meant something specific to you and something else to Claude, so you added specifics instead of repeating yourself. "Use whatever is closest to standard" was a good delegation: a decision Claude could make better than you by looking at evidence you'd forgotten. Turning the result into a skill means you'll never do this by hand again. You don't need a skill for your project. One prompt (see the brief) gets you the same files.

Context managementSpecific promptingAutomation

Task 5 of 5 · A first working thing on your laptop, however ugly

A reference, a goal, a constraint and a pace

The prompt

Prashant → Claude Code

My friend JM3 at Fractional.ventures created his AI course. https://learnai.fractional.ventures/ Can you have a look at his UI. We might do something like this but better. Also I want to push our course to learn.helmur.com Can we build our site locally first? Get a first version going asap. Thanks!

Sent with four screenshots of the site he was referencing.

What Claude did

Looked at the screenshots and noted what to borrow (status on each level, progress inside a lesson, an "ask the professor" box) and what to do differently: that course is a tour of tools with lessons and quizzes, the opposite of building first. Then it found the Helmur website's code, reused its stack, colours and fonts, and built the site: landing page, course dashboard, eight module pages and a skills page. It checked every page with screenshots in light mode, dark mode and on a phone before calling it done.

What came out

v0.1, running on Prashant's laptop. Note the old name in the header and "Over 14 weeks". Both changed within a day.
v0.1, running on Prashant's laptop. Note the old name in the header and "Over 14 weeks". Both changed within a day.
A v0.1 module page, with the ship list on the right
A v0.1 module page, with the ship list on the right

Reviewer's note

This is a strong prompt. A reference you admire (with screenshots, which beat adjectives), a goal ("like this but better"), a constraint ("locally first") and a pace ("asap"). What's missing is what "better" means. Claude had to decide that itself, and it happened to guess well because the course outline already existed. Without that context, say what you'd change.

Giving referencesSpecific promptingVerifying
← Back to the brief Now do yours: submit for review