Slide 1 · Speaker notes

Quick hello. This is about an hour, and about 15 minutes of it is you doing it yourself, so have a browser handy and make sure you can sign in to GitHub. I’m recording this for anyone who’s out. Not covering the command line, Actions or deployments today. If you want any of that, grab me for a 1:1.

Slide 2 · Speaker notes

This came out of the AI/Software Governance meeting on Oct 7. Most of us are building scripts, Apps Script, little HTML tools and prompt files with ChatGPT and Claude now, and almost all of it lives on somebody’s laptop. Laura’s ask was pretty simple: show everyone how GitHub works, then make it where that stuff goes. Nobody here needs to become a developer. You already work in systems with drafts, versions, approvals and rollbacks every day. GitHub is the same idea, just for files.

Slide 3 · Speaker notes

Our laptops are backed up, so this isn’t about losing files. It’s about everyone else being able to see and use what you build. The team can find it: a backup gets your laptop back, but it doesn’t help the next person on the account find the tool you built, or even know it exists. It can be audited: nobody can reasonably go through everyone’s laptops checking everything that’s been built for safety. Put it in AIMCLEAR’s GitHub and it can actually be reviewed for security and safety. A second set of eyes: this isn’t a new approval step. It means when you want someone to look before a script touches a client’s ad account or data, you can ask, and they see exactly which lines changed. Drive and Box can tell you a file changed, but not what changed inside a script. Keys get caught: every upload is scanned for API keys and passwords, so a pasted key gets flagged before it’s merged into main. And you can see what changed: when a report suddenly looks off, history shows what changed, who changed it and why, and you can roll it back.

Slide 4 · Speaker notes

This is the rule from leadership, and it’s the one thing I want everyone to walk out with. Everything else today is how.

Slide 5 · Speaker notes

Before the vocabulary, two problems everyone in this room has had. Last save wins: two people are in the same file, and whoever saves last wipes out the other person’s work. Usually nobody notices until something’s missing. And which version is this? We’ve all seen campaign_brief_v2_REAL_final.docx sitting next to campaign_brief_v2_FINAL.docx. GitHub fixes both. Every version is kept with a note on what changed, so there’s only ever one current file. And nobody saves over anybody, because changes get proposed and looked at before they land. We’ll see exactly how in a minute. Hold onto those two problems. Everything on the next few slides is how GitHub solves them.

Slide 6 · Speaker notes

If you’ve worked in Google Docs, you already get most of this. A repo is a shared Drive folder for one project, with every version kept. A branch is making a copy to work in, so the original stays untouched. A commit is a named version in version history, with a note on what changed, and small and often beats one giant save at the end. A pull request is suggesting mode: you’re asking to merge your branch into main, and someone sees exactly what changed before it’s accepted. The strip along the bottom is that first half: branch off main, save a few commits, open the pull request. The next slide finishes it.

Slide 7 · Speaker notes

Same idea for the back half. Review is an approval round, with comments on specific lines. Merge is accepting the suggestions. Main is the approved, final version. An AIMCLEAR org rule protects it, so changes come in through a pull request. An issue is a ticket that lives with the code, basically a ClickUp task stuck to the repo. The strip along the bottom picks up where the last slide left off: the pull request gets reviewed and approved, then merged back into main.

Slide 8 · Speaker notes

Branch, commit, pull request, review, merge. That’s the whole loop, and it’s the same loop whether you click through it yourself or Claude does it for you. Next I’ll run it once in the browser so you can see it.

Slide 9 · Speaker notes

Share screen in the practice repo and run the loop once. As you click each step, name it out loud: that’s the branch, that’s the commit, that’s the pull request. That way the words from the Google Docs slides land on something real. Tour the repo: files, the README, who changed what last. Open a file and hit History to see every version of it. Edit it with the pencil icon. Commit changes, write a short note, pick Create a new branch for this commit and start a pull request, then Propose changes. Create the pull request, write a description, and pick a reviewer from Reviewers on the right. A dev team helper is on deck to approve it, so there’s no switching accounts. Files changed tab: red is what came out, green is what went in. Leave a comment on a line, the helper approves with Submit review, then resolve the comment and merge. Last, Add file then Upload files, for something that already lives on your laptop. Three things to point out as they happen: main is protected by an AIMCLEAR org rule, so GitHub won’t let you commit straight to it and offers a new branch for you. You can’t approve your own PR, so someone else has to. And an open comment has to be resolved before Merge unlocks. If the live demo misbehaves, the backup recording is github_training_pr_loop_demo.gif in your Downloads folder, and the real example is PR #2 in aimclear/TimothyEastvold.

Slide 10 · Speaker notes

Pairs are posted in the Meet chat, and I’ll post them again right now for anyone who joined late. If you can’t get into the repo, your partner shares their screen and drives, and you follow along. A couple of dev team folks are hanging out in the chat for anyone who gets stuck. Everyone: open the shared practice repo, github.com/aimclear/github-practice. The link is in the chat too. It’s one repo for the whole group, so you can review each other’s PRs, and your own repo comes after. Then Add file, Create new file, name it people/ plus your first name and last initial, like people/laura-w.md. We have two Lauras and two Joes, so the initial keeps names from colliding. Three lines: your name, your team, and one script or AI tool you’ve built or want to build. Commit changes, choose Create a new branch for this commit and start a pull request, call it add-firstname-lastinitial, then Propose changes and Create pull request. Pick your partner under Reviewers on the right. Then review your partner’s: Files changed, leave one comment, then Submit review with Approve. Don’t click Merge. I’ll merge a few live so everyone sees it land. If the check says Waiting for a runner, keep going, I’ll merge after. Hard stop at 37 minutes in. Done early? Make your own repo from AIMCLEAR’s template at github.com/aimclear/employee-repo-template. Hit the green Use this template button, choose Create a new repository, and set Owner to AIMCLEAR. Then upload a script from your laptop that you’ve already checked for keys, on a new branch, and open a PR for it. The template brings the Gitleaks check along, so every upload gets scanned for keys and passwords. If it flags something, stop and ask the dev team.

Slide 11 · Speaker notes

Never commit passwords, API keys or tokens. Use a placeholder like YOUR_API_KEY_HERE. Real keys go in LastPass, or ask the dev team where they belong. No client data: exports, customer lists, emails, ad account data. Test with dummy data, like the alias account from the governance meeting. And no personal stuff: your own logins, or private details about someone, like HR, health or home addresses. Notes on client work are fine.

Slide 12 · Speaker notes

If you commit a secret anyway, tell the dev team right away. Nobody’s going to be mad, we just need to move fast. Deleting the file doesn’t fix it. Git keeps every version, so the key has to be rotated, which means the old one gets turned off and a new one is made. It happens, we’ve all done it. We fix it and move on.

Slide 13 · Speaker notes

To make your own repo, open AIMCLEAR’s template at github.com/aimclear/employee-repo-template. It’s a different repo from the practice one we just used, and it’s there so everyone starts from the same setup. Hit the green Use this template button, then Create a new repository. Starting from the template brings the Gitleaks check along, which scans every upload for keys and passwords. Main’s protection comes from an AIMCLEAR org rule, so you don’t set that up yourself. After that, there are really only three choices that matter, and they’re all on that first screen. Owner: pick AIMCLEAR from the dropdown, not your personal account. Stuff on laptops can’t be audited, but stuff in AIMCLEAR’s GitHub can, and the team can find it. Visibility: Private. Public means anyone on the internet can read it, so nothing gets flipped to public without asking first. And what goes in is your stuff, the stuff you built with AI. Don’t download something you found online and run it. New tools get approved first, per the new software policy.

Slide 14 · Speaker notes

Slide walk only, no live demo, about two minutes. If you’d rather not do this in the browser, GitHub Desktop is the same loop as an app on your laptop, for Windows or Mac. You sign in with your GitHub account and clone your repo, which downloads a copy that stays linked to GitHub, as a normal folder. Before you change anything, pick or make a branch from Current Branch. Then open and save files in it like you do anything else. When you come back to Desktop, the Changes tab shows exactly what’s different, red out and green in. Write a short summary, hit Commit, then Push origin. Origin just means the copy on GitHub. Gitleaks runs on GitHub for every push, so there’s always a check on our side. The better habit is having it on your laptop too, because then it runs every time you commit from Desktop and catches a key before it ever leaves your machine. That setup happens once per laptop, since the template can’t install it for you, and the dev team can help. Make sure Desktop is on version 3.5.5 or newer so it runs. Desktop has a Bypass Commit Hooks option. Don’t use it. When you’re ready, Preview Pull Request and finish it on GitHub, same review and merge as before. This is what Claude Desktop and Claude Code are doing under the hood too, which is next.

Slide 15 · Speaker notes

Most of you are in Claude Desktop or Claude Code every day already, and that’s probably how a lot of this will actually happen. Claude knows how to do every step we just did: branches, commits, PRs, all of it. What it needs from you is what you’re aiming for. Show the pre-recorded clip of Claude taking a script and one of these prompts, then look at the PR it opened together. If there’s time, run one live. Why we did it by hand first: it helps to know what Claude is doing for you. When it opens a PR, you don’t need to judge the code yourself. Add a quick note on what the script is for, and someone on the dev team reviews it. If Claude can’t reach GitHub from your machine, ping me and we’ll get you set up.

Slide 16 · Speaker notes

The rule one more time: if you’ve built it and might use it again, it goes in AIMCLEAR’s GitHub. Your homework is to hit Use this template on github.com/aimclear/employee-repo-template, make your own repo under AIMCLEAR, and move everything you’ve built that you still use into it by [date]. If you get stuck, email me at timothy@aimclear.com or grab anyone on the dev team. I’m happy to field them, and no question is too basic. Two things you already saw today have names, if you want to look them up later. Actions are automatic checks, like Gitleaks scanning every upload. Branch protection is why main wouldn’t take a direct edit in the demo. The template brings the Gitleaks check, and an AIMCLEAR org rule protects main, so you don’t set either up yourself. Anyone who wants the command line, more on Actions, or help getting Claude Code working with GitHub, grab time with me.

Slide 17 · Speaker notes

Open floor.