Workspace + Pages repos

You need 2 repos to work effectively: a private workspace repo for work-in-progress, and a Pages repo for publishing. Both take about 2 minutes to set up. Claude does it for you.

Your workspace repo

A private repo where all your day-to-day work lives. Naming convention: your-name-workspace.

Inside, a simple folder structure

your-name-workspace/ ├── CLAUDE.md ← workspace-level rules ├── working/ ← active projects │ ├── client-acme/ │ ├── spring-promo/ │ └── weekly-reports/ └── archive/ ← finished / inactive work

Each sub-folder in working/ is a project with its own CLAUDE.md and files. When a project is done, move it to archive/.

Create it via Claude

Tell Claude

Create a private GitHub repo called [your-name]-workspace. Clone it to my local Claude Code folder. Set up the working/ and archive/ folders. Add a minimal workspace-level CLAUDE.md. Claude uses the gh CLI (installed in Module 01) to create the repo, clones it locally, and sets up the structure.

Your Pages repo

A repo dedicated to publishing. Naming convention: your-username.github.io OR your-name (depending on your GitHub setup).

Inside, a simpler structure

your-pages-repo/ ├── index.html ← your main landing page at username.github.io/ ├── reports/ │ └── client-weekly.html ← at username.github.io/reports/client-weekly.html ├── dashboards/ └── public-encrypted/ ← source files before encryption (optional)

Every HTML file in the repo becomes a live URL once pushed.

Create it via Claude

Create a GitHub Pages repo at [your-username].github.io. Enable GitHub Pages in the repo settings to deploy from the main branch. Clone it to my local Claude Code folder.

Claude creates the repo, enables Pages, clones. Pages takes a few minutes to provision on GitHub's end - first push might take a bit longer to appear.

The folder-to-URL mapping

Every file in your Pages repo maps to a URL

• index.html at root → username.github.io/
• reports/index.html → username.github.io/reports/
• reports/client-weekly.html → username.github.io/reports/client-weekly.html
• dashboards/overview.html → username.github.io/dashboards/overview.html

Folder structure = URL structure. No renaming, no routing config. Path in repo = path in URL.

Typical workflow across both repos

1. Work in your workspace repo (working/project-name/) - drafts, experiments, data files
2. When a deliverable is ready, tell Claude: "copy this file to my Pages repo at [path], commit, and push"
3. Claude copies, commits + pushes to both repos, gives you the live URL

Workspace = private work. Pages = published output.

Use a custom domain (recommended)

By default your Pages URL is your-username.github.io/... - functional but obviously not your brand. Point a custom domain at your Pages repo and everything deploys under your own URL instead.

Example: point yourdomain.com at your Pages repo, and every file that would have been at your-username.github.io/reports/weekly.html now lives at yourdomain.com/reports/weekly.html. Same deploy, same workflow - just your domain on the URL.

Why this matters for client-facing work

• Credibility - a report at yourdomain.com/reports/client-q2 feels far more professional than your-username.github.io/reports/client-q2
• Portability - if you ever move off GitHub Pages, you change the DNS, your URLs don't break
• Subpaths are free - one domain covers yourdomain.com/reports/, yourdomain.com/dashboards/, yourdomain.com/clients/, etc.
• HTTPS included - GitHub provisions the SSL certificate for you automatically

Setup (one-time, ~10 minutes + DNS wait)

1. Buy or use an existing domain - any registrar works (Namecheap, Cloudflar e Registrar, GoDaddy)
2. Tell Claude: "Walk me through pointing my domain yourdomain.com at my GitHub Pages repo. Include DNS records, the CNAME file, and HTTPS settings."
3. Claude walks you through: ○ Adding 4 A records (or one CNAME record) at your DNS provider ○ Creating a CNAME file at the root of your Pages repo containing yourdomain.com ○ Setting Custom Domain in your Pages repo's Settings > Pages ○ Ticking "Enforce HTTPS" once the cert provisions
4. Wait for DNS propagation (usually 10 minutes to a few hours, up to 24 hours worst case)
5. Visit yourdomain.com - your Pages content loads

What happens to the old github.io URLs

They still work. GitHub auto-redirects your-username.github.io/reports/weekly.html to yourdomain.com/reports/weekly.html. So any old links you've shared with clients keep working + deliver them to the branded URL.

Using a subdomain (e.g. reports.yourdomain.com)

Same process, use a subdomain in the CNAME file and DNS record. Useful if your main domain is already used for something else - e.g. your main site is at yourdomain.com and your Claude Code deliverables live at reports.yourdomain.com.

You can skip this

github.io URLs work fine. Members often start with github.io and add a custom domain once they're shipping client work regularly. Not required to get value from this module.

Power-user tips

• Treat workspace repo as scratch, Pages repo as ship - don't push drafts to Pages, don't organise Pages like a filesystem
• Use sub-folders per client in workspace - easier to find work
• Delete index.html in Pages repo root if you don't want a landing page - visitors get a 404 on bare URL, which is fine for unlinked deliverables
• Tell Claude to list all your repos - "show me all GitHub repos I have access to"
• useful when you forget what exists

Action items

☐ Tell Claude to create your workspace repo with working/ + archive/ folders

☐ Tell Claude to create your Pages repo + enable Pages in settings

☐ Confirm both are cloned to your local Claude Code folder

☐ Test by pushing a hello.html to Pages - confirm it's live at your URL

Next lesson: Committing, pushing, and deploying.

Exercises

1. Review the concepts covered in this lesson: Workspace + Pages repos.
2. Write down your key takeaway from this lesson.
3. Practice running any commands or prompts mentioned above inside your terminal.