How to Teach AI Tools: Do 90% of the Setup for Students and Spend Class Time on What Matters

Table of Contents

1. A 10-page tutorial, and 6 of the pages teach installation
2. The starter kit method: three parts
3. Part one: a one-line install script
4. Part two: a project template (hand out the skeleton)
5. Part three: CLAUDE.md, turning "setup" into "fill in the blanks"
6. What do you teach with the time you save?
7. This is not just a teaching method
8. 30-second checklist: build your own starter kit

This is the first post in the "work system" series. The earlier beginner series taught you how to get started with the tools; this series teaches you how to turn the tools into a system that actually runs every day. We start with "how to teach others", because the blind spots in teaching are the blind spots in system design. Not sure what CLAUDE.md is yet? Read Desktop step 5: write a CLAUDE.md so AI remembers your project first.

#A 10-page tutorial, and 6 of the pages teach installation

Recently I read a tutorial a friend wrote: "Doing Your Thesis with Claude Code". The content is solid. How to plan the folders, how to track progress, how to verify AI output: these are things you can only write after actually guiding students through it.

But of the whole 10-page document, the first 6 pages teach installation: download VS Code, click Next all the way through, install extensions, install Git, set your identity, sign up for GitHub...

That is not his fault. Almost every AI tool tutorial looks like this, because "starting from zero" sounds responsible.

The problem is that students have limited attention. A class is 90 minutes. If the first 60 go to "where is that button, why doesn't my screen look like the slide, what is PATH", then by the time you get to actually teaching "how to work with AI", the whole class is already tired. Worse, a third of them get stuck on some installation step and never open the tool again after class.

We call this: mistaking the cost for the curriculum.

Installing software, typing commands, creating folders, writing config files: these are the cost of using a tool, not its value. The value is what happens after installation. So the first principle of teaching design is:

Do 90% of the work for students, and get them to the terminal in the shortest time at the lowest cost.

#The starter kit method: three parts

"Doing 90%" is not a slogan. It is three concrete parts. We actually rebuilt that thesis tutorial with them, and 10 pages became 3 steps. The method carries over to any AI tool tutorial.

#Part one: a one-line install script

The 6 pages of installation instructions are, in essence, "a fixed series of commands", and anything fixed should be a script. The student does exactly one thing: open PowerShell and paste one line (illustrative only: replace 你的網域, "your domain", with the URL where you actually host the script):

irm https://你的網域/setup.ps1 | iex

What does the script do? It uses winget, which is built into Windows, to install VS Code, Git and the GitHub CLI, then installs the Claude Code extension. Anything already installed is skipped automatically, and the student never has to make a choice.

Writing a script like this involves three easily overlooked details, and they decide whether the class goes off the rails:

1. Report failures honestly. When winget fails to install something, the exit code is not 0. The script must check it, and on failure say plainly "this step did not succeed, run this line manually", rather than printing a fake "✓ Installation complete". A script that falsely reports success is worse than no script, because the student will get inexplicably stuck at some step 30 minutes later with no way to trace the cause.
2. Warn about system pop-ups in advance. Some installations (for example the GitHub CLI) need system permissions, and Windows will show a UAC prompt. Before running that step, the script prints one line: "A system prompt will pop up next, please click Yes." Then students do not panic and click the wrong thing.
3. Keep the script public and transparent. Drop | iex from the line and you can read the source first. Teaching students to "read someone else's script before running it" is a lesson in itself.

#Part two: a project template (hand out the skeleton)

Once the tools are installed, the next section of a traditional tutorial is "please create this folder structure... create these three tracking files...", another 30 minutes of copying by hand.

Instead: hand out a zip. Unzip it and the full skeleton is there:

論文工作站/
├── CLAUDE.md          ← the soul (covered in the next section)
├── 論文製作流程.md     ← roadmap for stages 0~6
├── PROGRESS.md        ← progress checklist
├── 研究日誌.md         ← running log of every step forward
├── 01_文獻回顧/
├── 02_研究資料/
├── 03_分析腳本/
├── 04_論文草稿/
└── 05_行政文件/

The key insight here: the project skeleton has nothing to do with the topic. Literature review, data, analysis scripts, drafts, admin paperwork: every graduate student needs these five drawers, and the only difference is what goes in them. Since the skeleton is the same for everyone, it should not be course content. It should be a handout.

(The same holds for templates in any field: first separate "the skeleton everyone shares" from "the content that differs for each person", turn the skeleton into a template, and teach only the content in class.)

#Part three: CLAUDE.md, turning "setup" into "fill in the blanks"

The section most easily taught badly is setting up the AI's long-term memory. The traditional approach is "tell Claude: please remember who I am, my topic is..." Every student improvises on the spot, and the quality of the resulting memory varies enormously.

Instead: the template includes a ready-written CLAUDE.md, and the student fills in only 5 【】 blanks (name, department, topic, format, deadline). The working rules are all pre-written: read the log at the start of a session, ask about direction before producing files, treat raw data as read-only, log the work automatically at the end of a session. Students do not have to think of a single word.

This step also fixes a trap that 90% of users fall into: files and memory are two different things.

What you bring to a new computer	Project files	AI memory
Copy only the folder (or git clone)	✅ Yes	❌ No
Copy the folder + log in to the same account	✅ Yes	❌ Still no
The folder contains a CLAUDE.md	✅ Yes	✅ Travels with it

Claude Code's auto memory is stored outside the project folder and tied to the computer's file path. Your account only handles login and billing; it does not carry your memory. The only memory that is portable across devices and across a team is the one written into CLAUDE.md, which travels with the folder. Pre-writing it in the template fills in this trap for students before they reach it. They do not even need to know it ever existed.

#What do you teach with the time you save?

The three parts compress "from zero to the terminal" into 10 minutes. The 80 minutes saved are where the real course begins: the work loop.

1. Check status: at the start, have the AI read the log and the progress checklist, and say "where things stand and what the next step is"
2. Discuss direction: have it give 2~3 options plus a recommendation, and a human decides. Do not let the AI quietly finish a pile of things you did not want
3. Do the work: read the literature, draft, run the analysis. The AI executes
4. Produce files: record-type documents in two formats (md for version control, HTML so the professor can read it on a phone)
5. Log and wrap up: write today's progress back into the log, update the progress checklist, push to the cloud as a backup

Notice that these five steps have nothing at all to do with "thesis". This is a general loop for working with AI on any knowledge work. Once students learn this loop on a thesis, it runs just as well on work reports, marketing plans or programming projects.

That is what is worth spending 80 minutes teaching. Tools go out of date and buttons move; the work loop does not.

#This is not just a teaching method

By now you may have noticed: "do 90% for the user" applies far beyond the classroom.

• Onboarding a new colleague: instead of a wiki page, give them a project template that runs as soon as it is cloned, plus a ready-written CLAUDE.md
• Product onboarding: instead of teaching users a seven-step setup, make the seven steps one click, so they touch the value in the first minute
• Delivering to customers: instead of attaching a manual, attach a finished product that works once three fields are filled in

All of our own products are built on this principle, because every time "the user has to follow a document", that is one more chance to lose them. It is true for teaching, and it is true for products.

#30-second checklist: build your own starter kit

Want to use this method in your field? Follow this order:

1. Lay out your existing tutorial documents and mark which sections are "fixed steps" (cost) and which are "judgement and method" (value)
2. Fixed steps → turn them into an install script or a template (remember: report failures honestly, warn about pop-ups, keep it public and transparent)
3. The project skeleton everyone shares → package it as a zip that includes a ready-written CLAUDE.md (leave at most 5 blanks to fill in, no more)
4. The remaining value sections → reorganise them into a "work loop". That is your course
5. Test it with a real person: if they have not reached the terminal within 10 minutes, go back to step 1 and cut more

---

As of 2026-07-09, this method is running in UltraLab's teaching, including the reworked version of the thesis tutorial from the start of this post, which our instructor beebee uses in university classrooms. The next post in the series takes on the most sensitive question in academia: "Is using AI to write a thesis cheating?"

FAQ

Should the first class on AI tools start with installation?

No. Installing software, typing commands, creating folders and writing config files are the cost of using a tool, not its value. If the first 60 minutes of a 90-minute class go to installation, the class is already tired by the time you teach how to work with AI, and some students get stuck on an installation step and never open the tool again after class. The approach is to do 90% of the work for students and get them to the terminal in the shortest time at the lowest cost.

What is the starter kit teaching method?

It has three parts: a one-line install script (using winget to install VS Code, Git and the GitHub CLI, then the Claude Code extension), a project template handed out as a zip, and a ready-written CLAUDE.md in which the student fills in only 5 blanks. Together they compress 'from zero to the terminal' into 10 minutes, and the time saved goes to teaching the work loop.

Does Claude Code's memory carry over to a new computer?

Auto memory does not. Claude Code's auto memory is stored outside the project folder and tied to the computer's file path, so copying the folder or logging in to the same account does not bring it along; the account only handles login and billing. The only memory that is portable across devices and across a team is the one written into CLAUDE.md, which travels with the folder.

What should a one-line install script for students get right?

Three details: report failures honestly (check winget's exit code and, on failure, say so and give the command to run manually instead of printing a fake success message), warn about system pop-ups (before a step that triggers a UAC prompt, tell students to click Yes), and keep the script public and transparent (drop | iex from the line to read the source first).

What are the steps of the work loop for collaborating with AI?

Five steps: check status (at the start, have the AI read the log and the progress checklist), discuss direction (have it give 2 to 3 options plus a recommendation, and a human decides), do the work (the AI executes), produce files (record-type documents in both md and HTML), and log and wrap up (write back to the log, update progress, push to the cloud as a backup). The loop has nothing to do with theses specifically; it is a general loop for working with AI on any knowledge work.