Ryan Doser and Aaron Makelky make a useful case for GitHub as a home for work you want to carry between AI assistants. You do not need to become a developer to use a repository of plain-text instructions, project notes, and website code. But the "Google Drive on steroids" analogy has a limit: GitHub versions files; it does not automatically host your site, export every AI chat, or back up every connected service. The five public repos in their conversation are tools to consider after you understand that distinction.
Start with one private, small repo containing a README and a few approved Markdown notes. Learn to inspect a change and restore an earlier version. Then try a repo that matches a real job: Anthropic Skills for repeatable instructions, HyperFrames for editable video, Google Workspace CLI for authorized Workspace tasks, Search Console MCP for your own search data, or REA for lawful software analysis. Public code is not the same as zero cost or unrestricted rights.
Watch the Conversation
Credit: The examples and opinions in this article come from Ryan Doser's AI Rabbit Holes interview with Aaron Makelky and the supplied transcript. Aaron's written binder guide is a separate primary source. Ryan's products appear below as creator links, not as part of the five-repo list.
GitHub in Plain English
| Term | What a non-coder needs to know |
|---|---|
| Repository | A versioned folder you control. Choose private or public deliberately. |
| Commit | A named snapshot of changes. Read the changed lines before accepting an agent's work. |
| Push and pull | Send local changes to GitHub; bring remote changes back to your device. |
| Fork | Your own copy of someone else's repo. The license still governs what you may reuse. |
At 02:38, Ryan compares a repo to a shared folder and a commit to version history. That is a good entry point, though GitHub works best here for text, code, and change tracking, not as a dumping ground for raw video. GitHub documents file and repository limits; large media belongs in suitable storage. A repo can feed a publishing pipeline, but a separate host must serve the site.
Own the Work, Not Just the AI Conversation
Ryan reports running seven websites from GitHub-backed projects, with Claude Code or Codex editing files and Cloudflare publishing them (04:47). That is his workflow, not a measured comparison proving WordPress or other builders are obsolete. His staged septic-business ranking example shows a site can rank; it does not establish that an invented business is a trustworthy local result. A real client site still needs truthful identity, accurate service information, accessibility, analytics, and maintenance.
Aaron's stronger non-coder example is a portable working binder. In his article, he stores priorities, project notes, preferences, skills, and handoff notes as Markdown so different assistants can read the same current files. His starter prompt interviews you before creating a small folder and requires approval for public, paid, destructive, and production actions. That is more useful than exporting an unfiltered chat archive. The repo carries the files you choose to save, not hidden model memory or every integration setting.
Ryan also shows scheduled backups of his agent setup (13:09). Treat that as one recovery layer: confirm the automation actually ran, keep a separate copy of important files, and rehearse a restore. His transcript says API keys and NDA folders are excluded. GitHub's secret guidance supports keeping credentials out of files and using a dedicated secret manager or environment variables.
The Five Public Repos Worth Inspecting
| Repository | Useful first test |
|---|---|
| Anthropic Skills | Read one skill and use it to improve a repeated, low-risk task. |
| HyperFrames | Make a short video, change one scene, and render again. |
| Google Workspace CLI | List or summarize approved Drive files with a narrow read scope. |
| Google Search Console MCP | Ask a read-only question about a Search Console property you own. |
| REA | Inspect an app you own and compare the findings with its source or behavior. |
1. Anthropic Skills: reuse a process, not a mystery prompt
Ryan points to Anthropic's skills collection at 21:22, especially its skill creator. A skill is a package of instructions and optional resources an assistant reads for a specific task. Start by opening its SKILL.md, understanding what it asks the assistant to do, and trying it with non-sensitive material. Licenses vary by folder: public access to this repo does not grant blanket permission to copy, sell, or redistribute every included skill.
2. HyperFrames: create a video you can revise
HyperFrames turns HTML compositions into video. Aaron describes its desktop interface and editable timeline while discussing it at 21:22. The project documentation says the result remains an editable project folder, so your first test should include a revision, not just a one-shot render. Open-source tooling does not make licensed assets, optional voice models, compute, or hosting free.
3. Google Workspace CLI: connect only what you are allowed to access
Ryan uses Google Workspace CLI to let an agent work with Drive, Sheets, and other Workspace services (25:10). The CLI is a bridge to Google's APIs, not a replacement for Drive. Start with a read-only task in a test folder, inspect its OAuth scopes, and do not give a general-purpose agent mail-send or file-delete authority just to summarize a document.
4. Search Console MCP: ask about first-party search data
Suganthan Mohanadasan's Search Console MCP server offers questions such as which pages lost clicks or which queries may be cannibalizing each other. Its current setup documentation says consent is read-only by default, with broader permissions for sitemap and indexing actions. If you do not own or administer a Search Console property, this repo is not a source of SEO data for someone else's site. Verify conclusions against the underlying report before publishing them.
5. REA: inspect software, within your rights
The REA repo connects agents with reverse-engineering workflows. Ryan discusses a creator's Descript-like personal experiment, but Aaron pushes back on the idea that a weekend clone replaces mature recording and collaboration systems (25:10). REA's own README frames it for lawful research, interoperability, preservation, and software you own or are authorized to analyze. Reconstructing one screen or feature is not evidence of full parity, production readiness, or a right to copy a product.
What GitHub Does Not Solve
Versioned text and code, a reviewable record of changes, a portable copy, and a shared starting point for assistants that have authorized access.
Hosting, databases, domains, secrets, app integrations, model costs, permissions, recovery testing, and a second backup. A private repo is not a vault for credentials.
At 07:40, the conversation implies canceling an app builder can mean losing your site. That is a useful portability question but too broad as a statement about Lovable: Lovable documents code export and Git sync. An exported codebase can be deployed elsewhere; its backend data, secrets, and third-party connections still require separate migration. Likewise, a GitHub repository is not itself a live website or a complete backup strategy.
A First-Week Checklist
- Day 1: Decide what you may store. If work or client files are involved, check policy and permissions first. Open a private repo only for approved text.
- Day 2: Add a README and one small project note. Make a commit, then view exactly what changed.
- Day 3: Ask an assistant to propose a change to a non-sensitive file. Review the diff before allowing a push.
- Day 4: Retrieve the repo from another device or approved assistant. Confirm the instructions are understandable without the original chat.
- Day 5: Export a second copy and test recovery. Then pick one of the five repos for a measured, low-risk job.
Video Chapters
| Time | What Ryan and Aaron cover |
|---|---|
| 00:00 | Introduction and the non-coder angle |
| 01:17 | Why non-coders need versioned work |
| 02:38 | Repo, commit, push, and pull explained |
| 04:47 | Ryan's GitHub-backed websites |
| 07:40 | Portability and app-builder subscriptions |
| 08:16 | Ryan's move away from WordPress |
| 11:04 | GitHub as an assistant's working memory |
| 13:09 | Backing up an AI setup |
| 13:50 | Moving between assistants |
| 15:28 | GitHub compared with Drive |
| 16:55 | Reusable playbooks |
| 18:57 | Prompt-injection and repo safety |
| 19:29 | Aaron's chief-of-staff binder |
| 21:22 | Anthropic Skills and HyperFrames |
| 25:10 | Workspace CLI, Search Console MCP, and REA |
| 29:47 | How to begin with GitHub |
| 33:43 | Final thoughts |
Starter Prompt: A Small Workspace You Can Move
Aaron's full binder prompt is the deeper template. This shorter version starts with a private, reviewable experiment and does not assume you may put work data on GitHub.
One repo, one recovery test
Build a small binder with permission and review.
Sources and Credits
Primary account: Ryan and Aaron's conversation, supplied transcript, Aaron's article, and his binder prompt. Follow Aaron on YouTube or X. Project documentation: the five direct GitHub links in the repo map, plus Lovable's Git sync guide, GitHub's secret guidance, and repository limits. Repo features, access, and licenses can change; checked October 18, 2026.
Creator resources, separate from the five repos: Ryan's AI Rabbit Holes playlist, marketing skills, SEO system, and Blotato referral link. The latter is promotional; this post does not independently evaluate those products.