Get to Know GitHub 1: Why we're doing this
Slides 1 to 4 (cover, where it lives, five reasons, the rule). 0:00 to 0:02 is the join buffer, then this section runs 0:02 to 0:06.
What this section has to do
In four minutes, everyone should understand that this isn't a developer thing being pushed on them. It's a fix for a real problem they already have: the stuff they've built with AI lives on their laptops, where nobody else can find it, check it or see what changed. By the end of slide 4 they should know the rule and believe it's reasonable.
Talk track
Cover (30 seconds).
- Hello
- About an hour long, ~15 minutes of it hands-on
- Have a browser handy
- Are you set up and signed in to the GitHub account invited to AIMCLEAR?
- Recording this for anyone who's out
- No scary command line, Actions or deployments today
- Want any of that? Grab me for a 1:1
Where it lives right now (1 minute).
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 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.
Five reasons (2 minutes). Walk the five rows. Open with this: our laptops are already backed up, so this isn't about losing files. It's about everyone else being able to find and use what you build. Spend the most time on "It can be audited" and "A second set of eyes," because those are the two that are new to people.
- 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. Put it in your own project folder in AIMCLEAR's GitHub, and it can actually be checked for security and safety.
- A second set of eyes. This isn't a new approval step. 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. Everything that goes into GitHub, browser uploads included, is checked for API keys and passwords, so a pasted key gets flagged before it's added to the final version.
- You can see what changed. When a report suddenly looks off, the history shows what changed, who changed it and why, and you can roll it back.
The rule (30 seconds). Read it out and stop. If you've built it and you might use it again, it goes in AIMCLEAR's GitHub. This is the rule from leadership, and it's the one thing I want everyone to walk out with. Everything else today is how.
What counts as "stuff you've built"
People will ask where the line is. Concrete examples help more than a definition.
| Goes in GitHub | Doesn't need to |
|---|---|
| An Apps Script that pulls numbers into a sheet | A one-off prompt you typed once and never reused |
| A little HTML calculator or landing page mockup you built with Claude | The client deliverable itself (that lives where client work lives) |
| A Python or Node script that cleans an export | A spreadsheet of client data (that never goes in, see section 5) |
| A prompt file or Claude project instructions you reuse | Screenshots and notes for your own reference |
| A bookmarklet, a browser snippet, a Zapier code step |
Rule of thumb: if you'd be annoyed to lose it, or someone else might need to run it, it goes in.
Likely pushback and how to answer it
- "I'm not a developer, this isn't for me." That's exactly who it's for. Developers already do this. It's built for people who haven't needed it before.
- "Can't I just keep it in Drive?" Drive keeps a copy, but nobody can see what changed inside a script, and there's no easy way to ask a teammate to look at just the lines that changed. Drive also doesn't check every upload for API keys and passwords.
- "Is someone going to read all my stuff?" Your repo is private to AIMCLEAR, so it's not public to the world. Reviews only happen on changes you ask to merge.
- "What if my script is embarrassing?" Everyone's is. Nobody's grading code quality. The goal is that it's somewhere the team can find it.
- "Do I have to move everything today?" No. Homework comes at the end, with a deadline.
Watch out for
- This section runs long if you take questions here. Park them: "Hold that, we'll get there."
- Don't oversell security in a way that sounds like blame. The tone is "this protects you," not "we caught you."
- Avoid naming anyone's specific laptop script as an example unless they've said it's fine.
Done when
People can say the rule back, and the room isn't arguing about whether to do it, only how.