GitHub for operators

Why git, when you don't write code

Everything you have built moves into a shared GitHub repo with full history in this lesson, and @claude starts answering issues in it without your laptop open. Look at what you have built in three weeks: a CLAUDE.md, settings with permissions and hooks, a skills library, .mcp.json connections, API workflows. That is a real system, and it currently lives on laptops. Git gives it history (every change, by whom, when, undoable); GitHub gives it a shared home plus automation that runs with no laptop involved.

The mental model in four words each: a repo is a folder with memory. A commit is a named save point. Push sends your saves to the shared copy; pull brings down everyone else's. A pull request is a proposed change someone reviews before it lands. That vocabulary covers 95% of operator git life.

Set up the team's GitHub

One person does this setup once; everyone else just clones. If your company already has a GitHub organization, you are adding two repos, not building infrastructure.

1. Create a GitHub organization for the company (or use the existing one - check with whoever runs engineering, if you have one).
2. Create two private repos to start: the workspace repo (brain, CLAUDE.md, settings, project configs) and the skills repo from week three if you have not already.
3. In Claude Code, in your workspace folder: "Initialize git here, add a sensible .gitignore - make sure .env and anything secret-shaped is excluded - and push to the new repo."
4. Teammates clone: "Clone the workspace repo and walk me through what's in it." They inherit settings, CLAUDE.md, skills, and connections in one step.
5. Agree the one team habit: pull when you start, commit and push when you finish something meaningful. Claude can do both ends of that automatically when asked.

Claude on GitHub itself

So far Claude works on your machine and pushes to GitHub. The next level: Claude living in GitHub, responding to issues and pull requests with no laptop involved.

• Run /install-github-app from a session to wire your repo up - it walks the whole flow.
• After that, mention @claude in any issue or PR comment: "@claude the weekly-report skill mislabels the date column, fix it" - and it answers with analysis or a proposed change as a pull request.
• Under the hood this is the official claude-code-action for GitHub Actions. If you find older tutorials configuring inputs like direct_prompt, know the action's inputs were consolidated - current docs use prompt and claude_args.
• There is also a separate GitHub Code Review product that reviews every pull request automatically, no trigger comment needed - worth enabling on the skills repo so shared skills get a second pair of eyes by default.

The asset mindset

The principle under this lesson: your skills, brain, and automations are company assets, and assets get version control. Six months from now the workspace repo's history tells the story of how your operation evolved - and any new tool or teammate can be onboarded from it in an afternoon.

It also quietly future-proofs you. Everything you have built is files in folders in an open format - readable by any tool, portable to any vendor, owned by you. That is not an accident; it is the architecture.

Do this now

Sources and further reading

• Claude Code documentation
• Connectors directory - includes the GitHub MCP server