Student Onboarding — your AI + GitHub foundation

Why this isn't just course setup

You're building two things at once. The obvious one: the accounts and habits your course projects require. The bigger one: your personal LLM foundation — the preferences, prompts, skills, and logs that make an AI assistant genuinely yours. Professionals who carry a tuned AI setup between jobs get dramatically more out of these tools than people who start from a blank chat window every time. You start building that setup today, with your bio and resume as the first project.

Step 1 — GitHub, done right (~15 min)

Every course on this site opens with Stage 0, and Stage 0 has two parts. This is part 1: the account, and the mechanics of saving work to it (the Git mechanics section below). Steps 4–5 get a bare repo and your first two files in place; part 2 then builds it out to the standard your courses expect — and it assumes you have finished this page.

What GitHub actually is (the 30-second version)

GitHub is Google Docs for code and documents — a cloud platform for version control. Three things it buys you, and why each one matters here:

Two copies: local and remote

Every repository exists in two places at once, and most first-week confusion is really confusion about which one you are looking at.

Saving a file changes nothing anyone else can see. Committing changes nothing anyone else can see. Only a push moves work from your machine to GitHub. This is why "I definitely did it" and "it is not in your repository" are both true more often than you would expect — the work exists, locally, and was never pushed.

The reverse trip is pull: it brings commits from the remote down to your machine. You need it when you have worked from a second computer, edited a file on github.com, or are working with anyone else.

The three verbs: add → commit → push

The whole of Git you need to start is three moves, run every time you finish a piece of work. There are two ways to run them — a visual app (GitHub Desktop, the easiest start) or the command line. The mental model is identical; pick whichever you like.

No install at all: edit right on github.com

You don't strictly need Desktop or a terminal to submit small text files — the GitHub website can do it. On your repo page:

• Add a file: Add file → Create new file, type (or paste) the contents, then Commit changes at the bottom. That single action is an add + commit + push in one.
• Name it: type the filename in the box at the top, e.g. docs/decisions/2026-08-01-lastname-hedge-framing.md.
• Make a folder: there's no "new folder" button — instead type the folder into that same filename box. Every / you type creates a folder, so docs/decisions/memo.md builds both folders and the file at once. That's how you stand up the skeleton straight from the browser.

.gitignore — deciding what never enters the history

Git's central promise is that nothing is lost. That promise runs in both directions: a file committed once stays in the repository history even after you delete it, because the history is the record of what was true at each commit. Deleting the file in a later commit records the deletion — it does not remove the earlier copy, and anyone can still read it. Removing something from history properly means rewriting every commit after it, which is disruptive and easy to get wrong.

So the only clean approach is to keep the file out in the first place. That is what .gitignore does: a plain-text file at the repository root listing patterns Git should pretend it cannot see.

Two categories belong in it. Junk — the hidden temp files Office and your operating system create constantly, which are noise in a diff and confusing to a reader. Anything that must never be published — credentials, personal data, licensed material. The full list and the reasoning are on AI conventions; the mechanical half is here.

Create the file at the repository root. The leading dot is required. On Windows, save it from a text editor with quotes around the name — ".gitignore" — or Notepad will append .txt and it will not work.

# Office and OS temp files
~$*.xlsx
~$*.xlsm
~$*.docx
~$*.pptx
.DS_Store
Thumbs.db

# Editor backups
*.tmp
*.bak
*~

# Never publish
.env
*.key
*.pem
secrets/
private/

If ~$model.xlsx or anything like it ever appears in your Changes panel, the file is missing, misnamed, or in the wrong folder. Fix that before committing rather than after.

Generate a .gitignore for a public GitHub repository that holds Excel workbooks,
Markdown documents, and exported chart images, worked on from both Windows and macOS.

Include patterns for Office lock and temp files, OS metadata files, editor backups,
and anything that would carry credentials or an environment file. Add a comment above
each group explaining what it catches. Do not exclude .xlsx, .md, .png, or .csv —
those are the deliverables.

How work is submitted

Committing and pushing is the submission. Work is graded by inspecting the repository at the deadline, so the commit history is both the deliverable and the record of when you did it. There is no separate upload of the files themselves.

The one thing that goes to Lamaku is the pointer: your public repository URL, submitted once. After that, everything you push is visible without any further action from you. Confirm the URL opens in a private browser window — if it asks for a login, the repository is still private and nothing you push can be read.

Two habits make this work in your favor rather than against it:

• Commit as you go, not at the end. A repository that shows steady work across the whole window reads as steady work. One commit an hour before a deadline reads as one hour of work, whether or not that is true.
• Push every time. A local commit is invisible. See local and remote above.

When something goes wrong (it will)

Six things trip up nearly everyone the first week. None are a big deal — Git tracks everything, so almost nothing is truly unrecoverable.

Git cheat sheet

Seven commands cover almost everything you'll do this term. Keep this open in a tab.

Step 2 — Tell your AI how you want to work (~5 min)

There's no single right way to use an LLM — there's a default pattern the courses recommend (AI drafts, you edit and own the result) and then there's your way. Pick what fits you below. Your choices are saved in this browser and Kumu reads them on every page, so the tutor adapts to you instead of lecturing you with rules.

Step 3 — Draft & review your bio and resume (~20 min)

Your portfolio needs a 150–200 word BIO.md and a one-page RESUME.md, both in Markdown. Kumu works these with you, in whatever role you chose above — career documents aren't graded analysis, so drafting help is fair game. Structured starting points: the course repo's bio template and resume template.

Draft my bio with Kumu Review my bio Review my resume

Career documents aren't graded analysis, so AI drafting help is fair game — use your own AI (Claude, ChatGPT) for this step. Same rules apply: edit until it sounds like you, and disclose the AI's help.

Step 4 — Start your personal LLM foundation

Four habits separate people who use AI from people who get compounding value from it. You'll practice all four in your courses; they're listed here because they're not really course habits — they're career habits.

Why decision memos matter more than they look like they do

The other three habits make an AI session start well. This one is what stops you from having the same session again in six weeks.

A decision memo is a short dated file recording something you settled — a tool, an approach, a structure, a thing you tried and rejected. It reads as bureaucracy until the first time you need one, and then it is the most valuable file in the repository, because it serves three readers at once:

• The teammate who joins in week six and asks why the project is built this way. Without the memo, the honest answer is "someone decided that before I got here," and the team relitigates it.
• You, in month nine, when somebody senior asks why you chose this. "It seemed right at the time" is a bad answer to a question you already answered well once.
• The model. This is the part people miss. An AI reading your repository reads docs/decisions/ along with everything else — so it stops proposing the approach you already rejected, and it stops needing to be told your constraints at the start of every session. A conventions file says how you work. Decision memos say what has already been settled, and why. Together they are the closest thing an AI has to a memory of working with you.

Four fields carry it: what was decided · why · who decided it · what would reverse it. The last one is what separates a decision record from a diary, and it is the one everybody skips. A decision nobody can name the conditions for undoing isn't a decision — it's a habit that hardened. The structure is on Deliverable templates; the courses here use it for every engagement's recommendation memo, so you will have written several before the term is out.

Created a skill in Step 2? Commit it to your portfolio repo now — .claude/skills/ is the conventional home — and it's real: version-controlled, portable, improvable.

Next stop, when a course project reaches the stage where an AI does the assembly: read the AI Tools Lab — which tool to open, how to hand it your repo, and how to stay the auditor while it types.

Onboarding checklist

• GitHub account created with my .edu email; GitHub Education benefits activated
• Professional username — checked how it reads on a business card
• GitHub Desktop installed; I can explain add → commit → push in one sentence each
• Public portfolio repo created with a README — verified it opens in an incognito window
• Working-style preferences saved above (Kumu now adapts to me on every page)
• BIO.md drafted, edited in my own words, committed — AI-disclosure line included if AI helped
• RESUME.md committed — one page, quantified bullets, disclosure line if AI helped
• Personal skill created with Kumu and committed (or pointed Kumu at my existing one)

Check yourself