I'd Been Running a Claude Project for Months Without Knowing It

Today’s lesson was Claude Projects, and about ninety seconds in I started laughing, because I’d been running one by hand for months without ever having the name for it.

A Project, the course says, is a self-contained workspace: its own memory, its own files, its own instructions, and every chat inside it follows them. Upload your reference docs once and Claude carries them across every conversation — no re-explaining yourself each time.

That’s just my terminal. The CLAUDE.md file that tells my learning pipeline how to behave? Those are project instructions. The folder of cached lessons and notes it reads from? That’s the knowledge base. I’d built the thing the GUI quietly packages for everyone else — I just did it the hard way, in a text file, because that’s where I live.

Here’s the honest part. The second I understood it, I stopped wanting to learn and started wanting to build. Every concept fired off an idea — a tool, a site, a feature. That’s the trap. A lesson that sparks a build is a lesson that landed, but if I down tools and start hammering, I finish neither. So the rule I wrote today: capture the spark, keep learning. An idea is safe on a list; a half-built thing just rots.

But one spark was small enough to actually ship. The course breaks good project instructions into four ingredients — context, process, tone, and the non-negotiable rules. So I made a free prompt that interviews you and writes those instructions for whatever you’re working on. It’s on the site now. Grab it.

On rail, the manual usually just names the thing you already half-know from doing it. Today was that.