GitHub for Knowledge Work.
You did not sign up for the workshop to learn Git. You signed up to build an agent. But the workshop ships its course material through GitHub, and that means a handful of words (commit, push, branch, pull request) are about to start showing up in your day. This is the plain-English version. Read it once, and you have what you need.
- A working mental model of the three repos in your life and what flows between them.
- A plain-English vocabulary for commits, pushes, branches, and pull requests, with the technical name taught alongside.
- A single command to remember for pulling the latest course updates without breaking anything you wrote yourself.
How this fits in the OS.
A free GitHub account and the workshop installer finished on your computer.
Three repos that already exist for you: the course textbook, the copy on your computer, and your private notebook on GitHub.
The ability to pull new course material when AI Build Lab ships it, and to save your own work safely off your machine.
First, what GitHub actually is.
Strip away the jargon and GitHub is one simple thing: a place on the internet that stores your files and remembers every version of them. Every change, who made it, when, and what it replaced. Think of it as a cloud drive with a perfect memory. Nothing gets silently overwritten, and you can rewind to any earlier state.
It was built for software developers, and for years it belonged to them. Programmers needed a shared copy of their code, a record of every edit, a way to work on the same project without stepping on each other, and a way to review changes before they went live. GitHub became the standard home for all of that. Most of the world's open-source software lives there. When someone says "it is on GitHub," this is what they mean.
Here is the shift that matters for you. The powers GitHub gave developers (a full history of every change, an off-machine backup, one source of truth everyone pulls from, a safe way to collaborate) were never really about code. They are about files that change over time. And in an agent-native workflow, your work is exactly that: markdown notes, your CLAUDE.md, the skills you write, the decisions you capture. Once your knowledge lives in files, it deserves the same care code has always gotten. That is why GitHub sits at the center of this workshop from day one. Whether or not you have ever written a line of code, you are using it here for the same thing: as the backbone that keeps your thinking versioned, backed up, and safe.
The problem this solves.
If you have ever opened GitHub, seen the words "commit," "push," "branch," and "pull request" stacked on a page, and quietly closed the tab, you are the audience for this card. The vocabulary is dense, the diagrams are intimidating, and almost every tutorial assumes you already write code for a living.
You do not need to learn Git to take this workshop. You need a small, sturdy vocabulary and a clear picture of where things live. Once you have that, GitHub stops being a wall and starts being plumbing. Boring, reliable, ignorable plumbing. That is the goal.
Here is the whole story in one sentence. AI Build Lab maintains a course repository. You have a copy of it on your computer. You also have a private copy on GitHub that only you can see. Course updates flow into your computer from AI Build Lab. Your own work flows out from your computer to your private GitHub. That is it.
The three repos in your life.
The word "repo" is short for repository, and it is simpler than it sounds: a repo is just a folder of files that GitHub keeps track of, saving every version so nothing ever gets lost. Here is the part that makes this easy. When you installed and set up your agent-native OS, that setup process already created all three of these repos for you and connected them. You did not have to build anything, and you do not have to manage where they live. They exist right now: one working copy on your computer, plus two on GitHub. Each one plays a specific role, and once you know which is which, most of the confusion disappears.
The textbook. The course repository maintained by the AI Build Lab Team. This is the source of truth for workshop content: guides, blueprints, slash commands, skills. You read from it. You do not write to it. When the team ships an update, it lands here first.
The working copy on your computer. The folder Claude Code opens on your machine. This is where you actually do the workshop: read the guides, run the commands, write your own notes, build your own skills. Your computer is where the work happens.
Your private notebook on GitHub. Your own private GitHub repo, named something like your-username/agent-native-os-private. Nobody but you can see it. This is where your own work gets backed up safely, off your computer.
The split protects you from two different failure modes. Keeping upstream read-only means a course update can never overwrite your work. Keeping origin private means your personal notes, client context, and goals never leak into a public repo by accident.
The five terms that show up most.
These are the terms you will see in Claude Code output, in the workshop guides, and in any conversation about GitHub. Plain English first, technical name second.
Saving a checkpoint commit
A commit is a snapshot of your work at a moment in time. Think of it like saving a Word document, except every save is permanent and labeled with a short note about what changed. Those snapshots stack up into a complete version history, so you can scroll back through every commit, see exactly what changed and when, and jump back to any earlier version if something breaks. It is an undo button that never forgets. Claude Code makes commits for you most of the time. You rarely type the word yourself.
Uploading your checkpoints push
Picture the word literally. A push is you pushing your work away from you, off your computer and up to GitHub, the same motion as sliding a box across a table toward someone on the other side. It sends the commits on your machine up to GitHub so they live somewhere besides your hard drive. Pushing to origin is how your private notebook stays backed up. If your computer dies tomorrow, anything you pushed is safe.
Downloading new checkpoints pull
A pull is the exact opposite motion. Instead of pushing work away, you are pulling it toward you, down from GitHub onto your computer. It downloads commits from a GitHub repo to your machine. When the AI Build Lab Team ships a new guide or skill, you pull from upstream to get it. You almost never run this command directly: the workshop wraps it in one slash command, /update-course, that does the pull safely for you.
A safe sandbox off your main work branch
Picture a tree. Your main work is the trunk, solid and upright. A branch grows off to the side: a parallel copy of your repo where you can try something new without touching the trunk. If the experiment works, you fold it back in. If it does not, you cut the branch off and the trunk is exactly as it was.
This is how big software gets built safely. When a company like Facebook wants to test a new feature, an engineer spins up a branch and builds and breaks things on it freely, proving it out there without ever touching the version that millions of people are using every day. The real source of truth stays stable the whole time.
Branches are also how a team moves fast together. At AI Build Lab, several of us build different things at the same time, each in our own branch, so nobody overwrites anyone else's work and each piece merges back into the trunk only when it is ready. That parallelism is a big part of how a small team ships a lot, quickly. You almost certainly will not create a branch yourself in this workshop. It just helps to recognize the word when Claude Code mentions it.
A request to merge work in pull request (PR)
A pull request, usually shortened to PR, is the next step after a branch. You did your work on a branch, and now you want it folded into the main trunk. The pull request is you raising your hand and saying, "Here is what I changed, can someone look it over and pull it in?" That is the whole name: a request to pull your branch into the main work. The reason you do it, instead of merging on your own, is the review baked into it. Before your change reaches the version everyone relies on, a teammate reads exactly what you changed, asks questions, and gives a thumbs up. A second set of eyes catches the mistake you could not see.
A simple example: you fixed the wording on a shared help page. Instead of editing the live page directly, you make the change on a branch and open a pull request. A teammate skims it, confirms it reads right, and clicks merge. Now it is live, reviewed, and safe, and nothing risky ever went straight into the trunk. As a workshop student, you will not open pull requests against the course repo. The AI Build Lab Team does. You only need to recognize the term when you see it.
Claude Code can run all of these commands on your behalf. You will rarely type git commit or git push yourself. Your job is to recognize the words when Claude reports back ("I committed three files and pushed them to your private repo"), not to memorize the commands.
Better still, you talk to it in plain English and it fills in the Git for you. Say "save my work" and it makes a commit. Say "back this up to my private repo" and it commits and pushes. Say "grab the latest course updates" and it pulls. You never have to name the command yourself. The agent maps what you said to the right move, and when it is not certain, it asks you first before doing anything.
And here is the single most useful habit when any of this feels confusing: just ask. Type "what should I do here?" or "is there anything on GitHub I should run right now, and is it safe?" and the agent will check the state of your repos and walk you through it in plain language. You are never stuck on your own. The expert is sitting right there in the terminal. You only have to ask.
The two directions everything moves in.
There are only two flows you need to picture, and they go in opposite directions. Hold this in your head and the whole system collapses to something simple.
Course updates flow IN.
When the AI Build Lab Team ships a new guide, a new slash command, or a fix to an existing one, the change lands on upstream first. To bring it down to your computer, you run one slash command:
/update-course
That command does the careful work for you. It checks that your private repo is safe, pulls the updates from upstream, stops if it sees anything risky like conflicts with your own changes, and pushes the refreshed course content to origin so your private copy stays current. You will run this every week or two during the workshop, whenever the team announces an update.
Your own work flows OUT.
When you write your own notes, fill in your CLAUDE.md, build a skill, or capture a decision, those files live in local on your computer. To back them up to GitHub, they need to land on origin. This is the standard rhythm:
- You make changes on your computer (or Claude Code makes them for you).
- The changes get committed (a checkpoint is saved).
- The commit gets pushed to
origin(your private GitHub repo).
Claude Code can run all three steps in a single move. You can also ask in plain English: "Save what we just did and push it to my private repo." The agent translates that into the right commands.
Notice the asymmetry. You read from upstream, you write to origin. The two directions never cross. That is what makes it impossible to accidentally publish your private notes to the course repo, or to overwrite a course file with one of your own edits. The shape does the safety work for you.
What changes for you.
The mechanics are small. The mindset shift is the real win:
- You stop fearing the words. When Claude Code says "I committed your changes and pushed them to origin," you do not have to look it up. You know what each piece means.
- You start treating your repo like a notebook, not a code project. It is a folder of files that the agent reads from and writes to. Markdown notes, CLAUDE.md, skills you draft. The fact that GitHub is involved is plumbing.
- You get version-controlled work without thinking about it. Every commit is a save point you can return to. Six months in, you have a tracked record of every change you made and the reasoning that went with it. That is a quietly enormous asset.
Where to go next.
You have the vocabulary. These cards put it to work.