Going further

You don't need any of this to graduate. Your tutor introduces these on demand during your real project, when they're actually relevant. But you don't have to wait; read whichever section is useful now, and ask your tutor (or any Claude) for help applying it.

One thing that lives elsewhere: if a session starts feeling slow or the AI seems to lose the plot, that's the context window filling up. The Hints and Tips page explains it and what to do.

Starting your own projects

Claude works in any folder, not just the tutor's. When you're ready to build something of your own — a game, a website, a tool — here's how to strike out on your own.

First: don't touch the tutor's files

Your tutor lives in the FLT folder, at ~/FLT/my-claude-project — on Windows that's the FLT folder inside your user folder in File Explorer; on a Mac it's the FLT folder in your home folder. (On Linux — no cage — it's ~/Documents/my-claude-project.) Don't move it, and don't edit the CLAUDE.md file inside it — that file is what makes the tutor your tutor. If you change it, the tutor breaks. A new project goes in its own new folder, well away from the tutor's.

The pattern for a new project

The rule of thumb: one folder per project, each its own git repo, and every project inside the FLT folder. Don't put two projects in the same folder; they'll get tangled. The FLT folder matters because it's the one place you can see from both sides of the wall — and the one place that survives an flt reset. (On Linux — no cage — projects go in ~/Documents as before.) Starting a project looks like this:

1. Ask Claude to set the project up. In any Claude conversation inside the cage, ask directly — for example: "Please make a new project folder in the FLT folder called my-game and start a git repo inside it." ("Start a git repo" just means turn on the save-point tracking from day one.)
2. Get a plan written down before you build. Ask Claude to write a plan.md for the project first (this is step 8 all over again). It matters for two reasons:
   • Claude forgets the whole project every time you clear the conversation — so a plan it can re-read is how a fresh Claude knows what it's meant to be building.
   • It helps you work through things in a logical order so nothing gets missed.
3. Navigate into the folder to work on it. Step into the cage first — type flt (see The cage and the flt command below) — then either cd into the folder (below), or use a one-word launcher you've set up (also below). On Linux there's no cage; just open your terminal.

Three terminal commands worth knowing

cd ~/FLT/my-game: "change directory." Takes you into the folder you name. cd .. takes you back up one level.

ls: "list." Shows everything in your current folder. Useful for "what was that project called again?"

alias: typed on its own, lists every launcher you have and what each one does. Useful for "what was that launcher called again?"

Using Claude outside the tutor

This happens inside the cage: type flt first, and when the [FLT cage] tag appears you're in. Then, once you're in a project folder, type claude and press Enter. That Claude won't be your tutor; it's a generic, helpful Claude, ready to build whatever you ask. Continue learning won't mean anything to it — just ask for what you actually want, plainly.

Making a one-word launcher for a new project

You already have one (tutor) for the learning project. Any project can have one — a short word you type inside the cage that opens Claude in the right folder. The cage keeps them in a launcher list: a small file in your FLT folder (~/FLT/.flt-projects.json) naming each word and the project folder it opens. Because the list lives in the FLT folder, your launchers survive an flt reset along with your projects. Four steps:

1. Decide what word you want to type. Short and memorable — game, play, recipe, whatever fits.
2. Ask Claude to add it to the launcher list. In the cage, open Claude (any folder is fine for this) and type a prompt like this — adapt the word and folder to yours:
   Example prompt "Please add a launcher called `game` for my project folder `my-game` to the cage's launcher list at ~/FLT/.flt-projects.json — it's a JSON list of entries with a name and a path; create the file if it doesn't exist."
   Claude handles the technical bits.
3. Leave the cage and come back in — type exit, then flt. The cage reads the launcher list each time you step in, so new words appear from the next visit.
4. Test it. Type your word and press Enter. You should land in the project folder with Claude running.

Launchers from the list open Claude in auto mode (the same mode your tutor uses). If you'd rather use a more cautious mode for a particular project, skip the launcher and start Claude by hand — see Permission modes below.

If something goes wrong (your word does nothing, or it says "command not found"), exit and flt again. If it still doesn't work, ask Claude to check the launcher list — it'll spot a typo in the file in seconds.

On Linux (no cage): the launcher list doesn't exist there — ask Claude for a plain terminal alias instead: "Please add a terminal alias called `game` that opens Claude in my ~/Documents/my-game folder, in auto mode." Close and reopen your terminal to pick it up.

Talking to a fresh Claude

The Claude in a new project folder has no shared history with the one that's been your tutor. So you have to tell it everything, like a stranger. The rule from step 3 of the curriculum applies: be specific, give context, leave no guesswork.

The launcher prompt above is one example of that. The same shape works for anything you'll ask a fresh AI: describe the outcome you want, not the mechanism. The AI figures out the mechanism.

The cage and the flt command

On Windows and Mac, your tutor lives inside the cage — the sealed-off environment the install set up, whose wall means nothing of yours is in reach beyond the FLT folder. Typing tutor opens the cage and starts the tutor, all in one step — which is why you never normally think about it. (On Linux there's no cage; you can skip this section.)

You can also step into the cage without starting the tutor. In PowerShell (Windows) or Terminal (Mac), type:

That opens a terminal session inside the cage — same place the tutor runs, no tutor running.

How to tell whether you're inside the cage: your prompt starts with an [FLT cage] tag. When the tag is there, you're inside; when it isn't, you're not. Type exit to step back out.

When would you want to? Mostly when you start projects of your own: inside the cage you can move into any of your project folders and type claude to work with a plain, non-tutor Claude (see Starting your own projects above). It's also where you'd poke around if you're simply curious what's in there.

While you've got the tutor (and the WhatsApp safety net), getting stuck has been pretty cushioned. As your projects get bigger and more your own, you'll want to be able to dig yourself out.

Three moves cover most situations:

1. Read the actual error message before guessing. Computers are bad at being helpful but they're usually specific. The error names what went wrong, often where. Don't paraphrase it; read the literal words first. Then you can ask "what does this mean?"
2. Paste the exact error to your AI. Not "my code is broken". Paste the error message word-for-word: "I'm seeing this: [paste] — what does it mean and how do I fix it?" Beginners often summarise errors in their own words and lose the bit the AI actually needs.
3. Search the error text on Google. Copy the most distinctive part of the error (not the bit about your specific file, but the general bit) and paste it into Google. Other people have hit it before and written about it. Adding "Stack Overflow" or "site:stackoverflow.com" sometimes helps.

The skill being built isn't "knowing the answers." It's knowing where to look. Errors → AI → search → WhatsApp safety net. In that order.

Working with APIs

An API is a way for one app to ask another app for information. That's the whole concept. When your weather app shows the temperature, it's asking a weather API. When a website shows a Google Map, it's asking Google's mapping API.

Your projects can use APIs too: to fetch live data, post to a service, or do anything a separate provider offers.

When you'll want one: when your project wants something it doesn't already have. Real weather. Live sports scores. Calendar events. A map. A list of stocks. The exchange rate. Anywhere a number, fact, or feed has to come from "somewhere on the internet."

The fiddly bits the AI handles for you:

• Signing up for an API key. Most APIs require you to register so they know who's asking. You usually do this on the API provider's website (the AI can't open a browser for you, but it'll give you the URL and tell you what to click).
• Storing the key safely. An API key is like a password; don't paste it into chat, don't commit it to git. The AI will set up a separate file (often .env) to hold it, and add that file to .gitignore so it doesn't get pushed to GitHub.
• Writing the actual code that calls the API and shows you what came back.

How to ask: describe what you want to see in plain words. "I want my page to show today's weather for Manchester. I think there's a free weather API, can you set it up?" The AI takes it from there, narrating each step.

What code "actually is"

You don't need to write code to use AI well, but a light mental model of what it's doing makes reviewing AI output much easier.

Almost all code does one (or more) of four things:

• Stores something. Saves a value, a list, a file, a setting. (Names, scores, the contents of a form.)
• Decides something. An "if": if the score is over 100, show the win screen. Branching logic.
• Repeats something. A "for each": for each name in the list, print "hi <name>". Loops.
• Communicates with something. Asks an API, reads a file, writes to a database, sends a notification. Anything crossing a boundary.

That's it. Every program is some mix of those four. When the AI shows you a chunk of code, asking "what's this storing / deciding / repeating / talking to?" usually surfaces the point.

When this is useful: when you want to understand what you're approving, or when you're trying to follow what changed. "Walk me through this code in terms of store / decide / repeat / communicate" is a pretty good prompt.

Project architecture — where new code goes

Early on, everything lives in one file. That's fine. Eventually one file gets too big: you scroll forever, the AI starts mixing unrelated bits when it edits, you can't remember where you put something.

The fix is splitting: pulling chunks of code out into separate files, each with a focused job. A login bit, a data-loading bit, a "show the page" bit.

When to do this: when your file is over a few hundred lines, or when you find yourself searching it for things. Trust the discomfort; that's the signal.

How to ask: "This file is getting big. Can you help me split it into a few smaller files, grouped by what they do? Show me the plan first before changing anything." The "show me the plan first" matters; splitting badly can make things worse. Review the plan, then approve.

Don't worry about "good architecture" as a thing. Worry about "can I find what I'm looking for." If yes, you're fine.

Branches and pull requests

In step 6 you learned about commits (local save-points). In step 7 you learned about pushing (sending commits up to GitHub). Branches and pull requests are the next layer up.

A branch is a parallel line of work. Imagine your project as a path through a forest: a branch is a side trail you can wander down, try something out, and either merge it back into the main path or abandon it.

A pull request (or "PR") is a proposal to merge one branch into another, with a description of what changed. PRs are how teams review each other's work before it lands.

When you'll want them:

• You're collaborating with someone else and want them to review your work before it goes into the main project.
• You want to try a big change without messing up what's working. (Branch off, try it, if it works merge back; if not throw the branch away.)
• You want a clear history of "what changed and why"; PRs give you a place to write the why.

How to ask: "I want to try adding levels to my game without breaking what works. Can you set me up on a new branch?" Or: "Can you make a pull request for the multiplayer changes? Here's what I want the description to say: …"

Permission modes — choosing your level of friction

Claude Code has "permission modes" that control when it asks you before doing something. Your tutor sets you up on auto mode: you don't get popup questions, but every action Claude takes is checked in the background against what you actually asked for, and anything that doesn't fit gets blocked. On top of that, the chat-level pause your tutor does before any change is your review moment. Once you're confident, you might want to change.

The three modes worth knowing:

• auto (where you are now): nothing pops up, and a background safety check vets each action against your request. Your tutor's chat-level pause before each change is where you review. Most flow, with a safety net.
• accept-edits: file edits happen silently, but terminal commands (like running a script) and network calls (like fetching from an API) still ask. Middle ground.
• default: every meaningful action asks. Slowest, safest. Best when you're doing something genuinely risky or want to slow down deliberately.

How to switch: the mode is picked when Claude starts, with a flag on the command. Your tutor — and every launcher from the cage's launcher list — starts Claude like this behind the scenes:

That last word is the mode. To work on a project in a different mode, skip the launcher: step into the cage, cd into the project folder, and start Claude by hand with the mode you want:

Or for default mode, just leave the flag off entirely:

(On Linux, where launchers are plain terminal aliases, you can also just tell Claude which mode you want baked into the alias; it fills in the right flag.)