You have a second brain.
Now give it a front door.

Two separate things. Keeping them separate is the single most important decision in this guide, so it comes first.

You do not need to learn git. You need to understand it well enough to tell Claude what you want and to know when something has gone sideways. Here is the entire mental model.

This is the longest section and it is the only one with any real friction in it. Everything after this is one sentence to Claude and a button. Go slowly here and the rest is easy.

1a. The Terminal, in ninety seconds

If you have never used it: press Command and Space together, type Terminal, press Enter. You get a window with a line of text ending in a % sign. That is the prompt. It means the computer is sitting there waiting for you to tell it something.

You paste a line in, press Enter, it runs. Command + V pastes, same as everywhere else. That is the whole skill.

1b. Make a GitHub account

Go to github.com and sign up. Pick the username carefully: it becomes your web address, so it should be the name you want on the thing. Changing it later breaks every link you have ever shared.

1c. Do you need the Apple developer tools? Probably, and it is not Xcode

Short answer to the question you are about to ask: no, this is not the giant Xcode app. Xcode is the fifteen-plus gigabyte thing in the App Store, and you do not need it. What you need is a smaller bundle called the Command Line Tools, which is what actually puts git on your Mac. On my machine it is about 1.9 GB. Real, but a one-time download, and dozens of other things you will eventually install depend on it.

First, check whether you already have it. Paste this and press Enter:

If it prints something like git version 2.50.1, you are already done, skip ahead. If a dialog pops up offering to install developer tools, click Install and let it run. If you want to trigger it deliberately:

Then tell git who you are, using the same email as your GitHub account. These two print nothing. That is correct.

1d. Install GitHub Desktop, whichever lane you pick

Download it from desktop.github.com, open it, and sign in with your GitHub account when it asks.

I originally wrote this guide treating GitHub Desktop as the alternative to the terminal. That was wrong. Install it either way. Its real value is not the buttons, it is the window: it shows you, line by line and in color, exactly what changed since your last save point, which repos you have, and whether you have pushed. Claude Code can tell you all of that, but you have to ask, and when you are learning you do not yet know to ask. Having the picture open next to you is how the model in your head gets built.

Signing in here also handles authentication for anything you push from this app, so it doubles as a safety net if the command line login gives you trouble.

This is the view worth understanding, because it is the whole of git in one picture. Left side: which files changed since your last save point. Right side: exactly what changed inside the file you clicked, green for added, red for removed. Bottom left: the box where you write what you did, and the button that saves it.

Once you can read that screen, nothing in git is mysterious anymore. A commit is that list of changes plus the sentence you wrote about them. Everything else is logistics.

1e. Sign git in to GitHub, the step that trips absolutely everyone

GitHub stopped accepting plain passwords over the command line years ago. This is why half the tutorials you will find online are wrong, and why the wrong ones send you off to generate a long token and paste it somewhere. Do not do that. Pick one of these two.

gh auth login asks you five questions in a row. Use the arrow keys to move, Enter to choose. Here are the answers, in order, so you are not guessing:

To confirm it worked, any time, forever:

1f. Now pick which Claude does the work

These are not competing options so much as three surfaces on the same thing. You will probably end up using all three. What matters is knowing which one to reach for.

Do this first, before any website. It is the step with real value on day one, and it teaches you the whole loop on something where mistakes cost nothing.

Create the private repo

On GitHub, click New repository. Name it something like life-vault. Choose Private. Do not add a README, a license, or a gitignore, because you want an empty one. Create it, and leave that page open, because it shows you the two commands you need next.

Tell git to ignore Obsidian's noise

Obsidian constantly rewrites a couple of small housekeeping files, like which pane was open and how big the window was. If you track those, every single save looks like a change and your history fills up with junk. So you list them in a file called .gitignore and git pretends they do not exist.

That is the entire concept. You do not need to hand-craft this file. Hand it to Claude:

I have an Obsidian vault at [drag the folder in, or paste the path here]
and I am about to put it in a private GitHub repo.

Create a .gitignore at the root of the vault that ignores Obsidian's
churn files and macOS junk, but KEEPS my themes, hotkeys, and plugin
settings so they restore on a new machine.

Then explain in two sentences what you ignored and why, so I understand
what I just did.

For reference, what it should come out with is roughly four lines: the two Obsidian workspace files, the trash folder, and .DS_Store. If you would rather just make the file yourself, that is in the copy-paste kit at the bottom.

Turn the vault into a repo and push it

If you have Claude Code, open it in the vault folder and say "turn this folder into a git repo and push it to my new private repo called life-vault". It runs all of this for you. If you are on GitHub Desktop, skip to the paragraph after the commands. Either way, read the commands once, because you will see them a hundred times:

In GitHub Desktop instead: choose File, then Add Local Repository, point it at the vault folder, let it create the repo, write a summary, hit Commit, then Publish repository and make sure the "keep this code private" box is checked.

Refresh the GitHub page. Your notes are there, with history. From now on, saving your work is one sentence to Claude or one click in Desktop.

Give Claude a map of the vault

This is the piece nobody tells you about, and it is the difference between Claude being a chat window and Claude being something that actually knows your system. You put a file called CLAUDE.md at the root of your vault, describing the layout and the rules. Claude Code reads it automatically, every time, without being asked.

If your vault is already organized

You do not have to be able to explain your own structure, and you do not have to remember where everything lives. Let Claude read it and write the file for you:

Look at the structure of this Obsidian vault. Read the folder names,
sample a few notes from each, and work out how I actually organize
things and what my conventions are (frontmatter, naming, tags, where
new notes land).

Then write a CLAUDE.md at the root of the vault that describes it, so
that a future you starting fresh in this folder understands the system
immediately. Include a short "rules" section covering anything you can
infer about how I want files handled.

Do not move, rename, or reorganize anything. Describe what exists.
Show me the file before you write it.

That last line matters. Read what it produces. It will get one or two things subtly wrong about your intentions, you will correct them in a sentence, and the corrected version is better than anything you would have written cold.

If your vault is a pile

Also completely fine, and more common than anyone admits. A folder of 400 loose notes is still a second brain. Ask for a proposal rather than an action:

This Obsidian vault has grown without a system. Read what is in here
and propose an organization that fits the notes I actually write,
not a generic template.

Give me: the proposed folder structure with one line explaining each
folder, which existing notes would go where, and what you are unsure
about.

Propose only. Do not create, move, or rename a single file yet. I want
to approve the structure first, and then we will move things in small
batches so I can stop you if it feels wrong.

Once you approve a structure and things are in place, run the first prompt to generate the CLAUDE.md.

What one ends up looking like

Mine is longer than this, but this is the shape. Yours will look nothing like it, and should not:

Separate repo, public this time. The trick that makes this free and permanent: if you name a repo yourusername.github.io, GitHub serves it at https://yourusername.github.io automatically.

1. New repository. Name it exactly yourusername.github.io, all lowercase, matching your username. Set it Public.
2. Make a folder on your Mac for it, anywhere. One file inside, called index.html.
3. Add an empty file called .nojekyll next to it. This tells GitHub not to run an old blog engine over your files. Skipping it is the cause of a specific maddening bug where folders starting with an underscore silently vanish.
4. Commit and push, same as the vault.
5. On GitHub: Settings, then Pages in the sidebar. Under Source pick "Deploy from a branch", branch main, folder / (root). Save.
6. Wait about a minute, then load https://yourusername.github.io. It is live, on the actual internet, with a real address you can text someone.

The page itself: let Cowork build it

Do not write HTML. Describe what you want and have Claude produce the file. This is exactly the kind of contained make-me-a-thing job Cowork is good at, so if that is where you already live, start there and download the file it gives you into your site folder.

Build me a single self-contained index.html for a personal build log.
Everything inline, no frameworks, no external files or fonts, so it
works on GitHub Pages with zero setup and still opens if I
double-click it.

Contents:
- A header with my name, one line about who I am, and links to my
  email and GitHub.
- A "What I'm building" section with three project cards. Each card:
  title, one sentence, and a status chip reading LIVE, BUILDING,
  or PARKED.
- A "Log" section, newest first. Each entry is a date and two or
  three sentences.
- A footer with the date it was last updated.

Style: plain and readable, generous whitespace, system fonts, one
accent color. It should look like something a person made on purpose,
not a template. Mobile has to look right, most people will open this
on a phone.

Ask me for the name, the one-liner, and the three projects before
you write it.

That last line is the difference between a page about you and a page full of Lorem Ipsum you then have to edit. Answer the three questions, get the file, drop it in the folder, push it.

When you want to change it later, you do not start over. Open the same file with Claude and say what is different: "add a fourth project card for the asthma tracker, status BUILDING". It edits, you push, it is live in a minute.

Changing the page from then on

Edit index.html, commit, push. Pages redeploys in under a minute. With Claude Code that is one sentence: "add a log entry for today about the intubation checklist, then push it". There is nothing else to it. No deploy pipeline, no server, no cost.

The temptation, once both repos exist, is to automate the bridge. Sync the vault to the site. Publish a folder. Do not.

Publishing should stay a deliberate act with a human in it, for two reasons. The obvious one is exposure: an automated pipeline eventually publishes the note you wrote at 3am. The less obvious one is that a vault note and a public page are different objects. The note is for you and it is allowed to be raw. The page is for a reader and it owes them a point.

What works instead, and takes ten seconds:

Read [the note] in my vault.

Draft a log entry for my site from it: three sentences covering what
I built, what broke, and what's next. No jargon a non-physician would
trip on. Nothing identifiable about any patient.

Show me the draft. Don't touch index.html until I say go.

You read it. You fix the sentence that is not true. Then you say go. That review step is the whole wall, and it costs you almost nothing.

• Vault to site: always through a draft you read.
• Never publish: anything with a patient in it, anything about a colleague, anything you wrote angry.
• Assume permanence: git history keeps deleted content. Removing a line from a public page tomorrow does not remove it from the record. Treat every push to public as forever.

Setup is an afternoon. The habit is the actual project. What has worked for me, after several versions that did not:

Daily, thirty seconds

End of a work session, one sentence to Claude: "commit and push the vault". That is the entire daily ritual. In GitHub Desktop it is one click. Do not batch this. A week of uncommitted work is a week you will lose to a spilled coffee.

Weekly, ten minutes

Once a week, update the public page. One log entry. It does not need to be a milestone, and "spent four hours on a thing that did not work" is a better entry than silence. The log is a record of effort, not a highlight reel, and the weeks where nothing shipped are the ones that make the record honest.

When the ritual gets repetitive, automate the words not the judgment

Once you have done the same publish steps a dozen times, write them down as a Claude Code skill: a folder in ~/.claude/skills/ with a SKILL.md inside describing the procedure in plain language. After that, one slash command runs the whole sequence. Mine handles updating the board on my site: it recounts the project totals from the page itself, pushes, verifies the change is actually live, and reads the result back to me. That last part is not decoration, it is an ADHD safeguard against believing I shipped something I did not.

Every one of these happened to me. None of them cost me anything except an evening the first time.

The audience is not the point, and it is also not zero

For a long time the traffic is you, plus a few people you sent the link to. That is fine. The page still does its job as an accountability device on day one. Then at some point somebody you did not expect brings it up, and it turns out to have been a portfolio the whole time. Build it for the first reason. The second one arrives on its own or it does not.

Polish is the trap

The failure mode for people like us is spending four weekends on the design and never posting the log. The bottleneck is contact with a reader, not quality. Ugly and shipped beats beautiful and local, every single time. If you catch yourself picking fonts for the second hour, that is the tell.

Write for the version of you who forgot

The most valuable entries are the ones that record why you chose something, not what you chose. Six months later the what is visible in the code. The why is gone, and it is the only part you actually needed.

Let Claude do the typing, not the deciding

Claude will happily generate the HTML, the commit messages, the whole site. Let it. What you should not outsource is what goes on the page and what stays in the vault. Keep the judgment, delegate the syntax, and you will never be blocked by not knowing a command.

The full sequence

Starter .gitignore for an Obsidian vault

Sentences that do the work, once Claude Code is installed

• "Commit and push everything, with a sensible message."
• "What changed in this repo since last week?"
• "Add a log entry to index.html for today about X, then push."
• "Read this note and draft a public version. Show me before touching the site."
• "Revert the site to the last commit that worked."
• "Something broke, here is the error, walk me through it."