Kumu / Stage 0 · part 2

Stage 0, part 2 — Set up your workspace

Every course · do it once Part 1 is the GitHub account

Stage 0 has two parts, and this is the second. Part 1 is the account itself: create it, or sign in to the one you already have, and learn add → commit → push. This page is what you do next — build the repository every deliverable in every course here commits into.

Objective

One public repository, named for you, built to the portfolio-repo standard, with your instructor invited as a collaborator. That is the whole stage. No analysis happens here.

It belongs to the course, not to any one case or project, for a practical reason: the workspace has to be finished before the first deliverable is written, not half-built alongside it. Every engagement afterwards commits into it, and it is the one artifact here that outlives the course — a repository stood up properly at the start is a portfolio by the end of term; one assembled on the way to a deadline is a folder of homework. Build it once and every course on this site uses the same one.

Part 1 first: the account, and the three verbs

This page assumes you can already save work to a repo, so it does not re-teach the mechanics. If you cannot yet, that is Stage 0, part 1, and its Git mechanics walkthrough covers local versus remote, add → commit → push in the desktop app and on the command line, editing files straight on github.com, and the fixes for the mistakes everyone makes the first time. If you already have a GitHub account you can use that — one account, one portfolio, every course. If you don't, create one there. Any email works for your GitHub account; for the free GitHub Education benefits, add your school address under Settings › Emails and apply, which is optional and never graded.

Learn — why it is organized this way

The repository is organized by capability and engagement, never by course. A folder named for a class stops meaning anything the moment the class ends, and a reader who opens week3/final_v2.xlsx learns nothing about what you can do. capabilities/<capability>/ — marginal-analysis, pricing-power, fx-hedging, whatever you turn out to be able to do — names a capability; docs/, data/, and analysis/ hold the work that proves you exercised it.

Two mechanical facts about Git decide most of what goes wrong in this stage, and both are cheaper to know now than to discover later:

Git tracks files, not folders. An empty directory does not survive a push — it simply is not there when you look at github.com. Every directory in the skeleton needs at least one file, and a one-line README.md saying what belongs there is more useful to a reader than an empty folder anyway.
History is permanent. A file committed once stays in the repository's history even after you delete it. That is why .gitignore goes in before the first workbook, rather than after the first accidental commit of a ~$ temp file.

Do — set up the workspace

Do — check what you built

If you used the starter prompt, you handed a mechanical job to a model, which is the right call — and it means the verification is yours. Three things to check before you commit, each of which a generated skeleton gets wrong often enough to be worth looking for:

No folder is named after a course, a term, or a week. Models default to the shape they have seen most, and most public student repositories are course-shaped.
Every directory contains something. Otherwise Git silently drops it and your skeleton has holes you will not notice until a deliverable has nowhere to go.
Your bio is untouched. README.md already holds the bio you wrote, and a model asked for a portfolio will cheerfully overwrite it with an invented one. Generic AI-written filler as your bio is obvious to any reader, and it is the first thing anyone sees.

AI boundary for this stage: everything here except your bio is a means to the work, so AI may build it and you verify. Your bio is a human draft first: 200–400 words, written by you in your repo's README.md. AI may review it, never draft it. Once your course starts, briefs, analyses, memos and reflections are yours, first draft included.

Invite your instructor as a collaborator

On github.com:

Open your repository and click Settings (the tab on the right of the repository's top bar).
In the left sidebar, choose Collaborators (it may sit under Access). GitHub may ask for your password.
Click Add people, type adamwstauffer (with the w) and pick that account from the list.
The invitation now shows as pending. That is the finished state: you do not need to wait for it to be accepted, and nothing in the course waits on it.

To check it with an assistant, open Claude Code or Codex in your repository and paste:

List the collaborators and pending invitations on this GitHub repository
and tell me whether adamwstauffer is among them. Do not change any settings.

Optional, for the command line: gh api repos/<you>/<repo>/invitations.

Deliverable

What	Where it goes
Portfolio repo, public, named for you	`github.com/{you}/{firstname-lastname}`
Bio + engagement index	`README.md`
AI conventions	`AGENTS.md` (+ `CLAUDE.md` pointing at it)
Resume + prompt log, started	`RESUME.md` and `prompt-log.md` at the root — rough is fine on day one
Exclusion rules	`.gitignore`
Instructor access	`adamwstauffer` invited as a collaborator (how)

Repo is public — the URL opens in a private browser window without logging in
Named for you (firstname-lastname), not for a course
README.md holds your own 200–400 word bio and the start of an engagement index
AGENTS.md tailored to you — it names your own never-paste data and your own working preferences (the setup prompt drafts it from your resume; you read and edit it); CLAUDE.md is the one-line pointer
RESUME.md and prompt-log.md exist at the root — rough is fine
.gitignore filters Office and OS temp files
Every skeleton directory holds at least one file
adamwstauffer (with the w) invited as a collaborator — a pending invitation is the finished state
At least two commits, each with a message that says what changed

When review comes as a pull request: answer each comment by accepting it, modifying it, or rejecting it with a reason; cite the commit that made the change; then resolve the thread. If no review pull request arrives, check that adamwstauffer is a Write collaborator on your repo.