| Task | Tool | Why |
|---|---|---|
| Plan a project | Claude chat | Skills + expert panels + widgets |
| Produce a new artifact | Claude chat | Skills produce the HTML file |
| Update manifest + registry | Claude chat | Reads from Project Knowledge |
| Edit the dashboard | Claude Code | Surgical edits, pushed to repo |
| Edit a project guide | Claude Code | Targeted changes, no dashboard risk |
| Rename or move files | Claude Code | Batch operations |
| Upload new files | GitHub Desktop | Drag, commit, push |
| Revert a bad change | GitHub Desktop | Right-click, revert. Zero tokens. |
| Sync repo to Project | Project settings | Click Sync now |
| Dashboard | thekingofconsulting.github.io/manor/ |
| Compendium | thekingofconsulting.github.io/manor/compendium.html |
| Any artifact | thekingofconsulting.github.io/manor/[folder]/[filename].html |
Your coworker is right. If you commit a manifest update and a dashboard style change together, reverting the style change also rolls back the data. The practical fix: when using Workflow B, do two separate commits. First commit the manifest and registry changes. Then paste the Claude Code instructions and let it commit separately. Two commits means two independent revert targets.
Shared reference files (manifest, registry, tool inventory) would need to be duplicated. Skills can't cross-reference projects in different repos. One repo with domain folders gives you all the organization with none of the sync headaches.
GitHub Pages has no built-in auth. Options: StatiCrypt (encrypts the HTML file with a password prompt), Cloudflare Access (email-based login, free tier), or Netlify with password protection ($15/month). For health and finance data, Cloudflare Access is the most robust free option.
Where you are now. Claude chat with skills produces HTML artifacts. GitHub repo hosts everything. Claude Code makes surgical edits. GitHub Desktop handles commits and rollback.
Static HTML files in a GitHub repo. Project manifest and link registry as markdown files in reference/. GitHub Pages serves everything. One Claude Project with skills, repo synced to Project Knowledge.
Zero coding required. Version history on every file. Free hosting. Skills handle all project creation logic. Manifest replaces full-dashboard uploads, cutting token consumption by 90%.
Reverting a UI change also reverts data changes unless you commit separately. No password protection on sensitive pages. Each new dashboard or display needs its own HTML file with no shared data source. Token cost is low but not zero since HTML artifacts are larger than markdown equivalents.
Everything below is one-time setup. Once done, you never repeat it.
Everything below is one-time setup. Once done, you never repeat it.
Sign up at github.com. Upgrade to GitHub Pro ($4/month) for private repo Pages.
Create a private repo named manor. Add a README. Skip .gitignore and license.
Rename your Manor Command Center HTML to index.html and upload it. This is the homepage.
Settings > Pages > Deploy from branch > main > / (root) > Save.
Wait 90 seconds, then visit your URL:
Download from desktop.github.com. Sign in. Clone your manor repo to your computer. This creates a regular folder you can drag files into.
fire-pit-build-guide.html not Fire Pit Guide (1).html.
Download the Claude Code desktop app from claude.ai/code. Requires Git for Windows (install from git-scm.com first). Sign in with your Anthropic account.
Open Claude Code. Navigate to your manor folder. All edits and pushes happen from here.
All Manor work lives in one Claude Project. Skills cost tokens only when read, not by existing. Use separate chats per domain. The chat is your unit of focus; the project is your unit of infrastructure.
In Project settings, connect your manor repo via GitHub integration. Select reference/project-manifest.md and reference/link-registry.md. These are available in every chat without uploading.
Upload manor-project-instructions.md to Project Knowledge. This tells Claude the architecture, workflow rules, and what it should and shouldn't do.
Install claude-code-manor-updater via Customize > Skills. This replaces the old Dashboard Updater for the new workflow.
reference/. Commit and push.reference/. Commit and push.| Fix a link | "Find the link that points to [wrong URL] and replace it with [correct URL]. Change nothing else." |
| Update status | "Change the status badge for [project] from [old] to [new]. Change nothing else." |
| Update next action | "In the [project] card, change the card-next text from [old] to [new]. Change nothing else." |
| Edit a guide | "In home/[filename].html, change [specific text] to [new text]. Change nothing else." |
| Rename a file | "Rename home/[old].html to home/[new].html. Commit and push to main." |
The manifest moves from a markdown file to a hosted database. The dashboard becomes a view that reads from the database instead of a static HTML file with hardcoded values. Content moves from HTML to markdown with a rendering layer.
Project data (statuses, phases, next actions, artifact URLs) moves to Supabase. The dashboard shell stays in GitHub but reads data from the database at load time. You can revert the dashboard UI without losing project data, and vice versa.
| Problem | Beginner workaround | Intermediate solution |
|---|---|---|
| Reverting UI also reverts data | Separate commits manually | Data lives in Supabase, UI lives in the repo. Independent rollback. |
| Multiple dashboards need same data | Shared reference/ folder | All views query one database. Update once, reflected everywhere. |
| HTML artifacts consume more tokens | Use the manifest instead of HTML | Content stored as markdown. Rendering layer converts to visual output. |
| New systems need project data | Not possible without manual sync | Any device with internet can query the Supabase API. |
Evaluate when you're ready, not now:
| Criteria | Supabase | Firebase | Vercel KV |
|---|---|---|---|
| Free tier | Yes (500MB, 50k API calls/month) | Yes (1GB, 50k reads/day) | Yes (256MB, 30k requests/month) |
| Ease of setup | Moderate (SQL, needs schema) | Easy (JSON, no schema) | Easy (key-value, simplest) |
| Query power | Full SQL (most powerful) | Limited queries | Key-value only |
| Auth built in | Yes (row-level security) | Yes (Firebase Auth) | No (needs separate auth) |
| Best for Manor | Recommended. Relational data, auth, free tier fits the use case. | Good alternative if SQL feels intimidating. | Too simple for multi-domain data. |
When your friction log tells you it's time, follow these steps in order. Each step is independently useful. You can stop at any point and still have a working system.
Go to supabase.com, sign up with your GitHub account (one click since you already have one). Create a new project called "manor". Choose the free tier. Pick a region close to you (US East).
Supabase gives you a project URL and an API key. Save both somewhere secure. These are how your dashboard and Claude Code will talk to the database.
Open the Supabase table editor (it looks like a spreadsheet). Create a table called projects with columns: name, domain, area, status, phase, next_action, description, artifact_url. This replaces your project-manifest.md.
Create a table called artifacts with columns: project_name, filename, folder, github_url, date_created. This replaces your link-registry.md.
Create a table called tools with columns: name, category, status (owned/wanted/wishlist), notes, priority. This replaces your tool inventory markdown.
Export your current manifest and link registry as CSV (Claude can do this). Import the CSVs into the Supabase tables using the table editor's import function. Your data is now in the database.
Have Claude Code add a small JavaScript block to index.html that imports the Supabase client library and connects using your project URL and API key. This is roughly 10 lines of code.
Have Claude Code replace the hardcoded project cards in the dashboard with JavaScript that queries the projects table and renders cards dynamically. The dashboard shell (nav, layout, styling) stays the same. Only the data source changes.
Open the dashboard. It should look identical to before but now reads from Supabase. Change a project status in the Supabase table editor and refresh the dashboard. It should update. If it does, the connection works.
Have Claude Code convert each HTML guide in your repo to a markdown file. The content stays the same, just the format changes. Keep the HTML versions as backup until you've verified the markdown versions render correctly.
Have Claude Code add a rendering layer to your dashboard that converts markdown to styled HTML at load time using a library like marked.js. Your Manor brand CSS applies on top of the rendered output.
Update your Claude chat skills to produce markdown guides instead of HTML. This cuts token consumption on guide creation by 30-40%.
Update the Claude Code Manor Updater skill so that instead of producing updated markdown files, it produces Supabase API calls that update the database directly. Claude Code runs the API calls. No more downloading and replacing manifest files.
Once the dashboard reads from Supabase and the updater writes to Supabase, the project-manifest.md and link-registry.md files become redundant. Keep them in the repo as a human-readable backup, but they're no longer the source of truth. The database is.
Point the Compendium at the same Supabase project. It reads from the tools table for inventory, from a new health table for biomarkers, and from the projects table for status. One data update, two dashboards reflect it.
Any device that can make an HTTP request can query the Supabase API. A Raspberry Pi running a simple Python or JavaScript script can pull project data and display it on a screen, a calendar, or an e-ink display.
artifacts table with the project name, filename, and URL.index.html directly. Data updates go to Supabase via API. UI updates (styling, layout) still go through Claude Code + GitHub Desktop, but they're independent of data. Revert one without losing the other.
One deployed application with domain-specific routes. Not six separate websites. One codebase, one database, one auth system, one deployment. Each domain is a route with its own UI and data model, but they share infrastructure.
A single Next.js or Astro app deployed on Vercel (free tier). Supabase handles data and authentication. Each life domain is a route within the app. Claude Code generates components and pushes to the repo. You review and merge.
Some routes are public, some require login. Same app, same codebase, different access rules per route. Supabase Auth handles login. Row-level security means you can even mix within a domain: the fire pit build guide is public, but your contractor quotes are private.
| Route | Access | Why |
|---|---|---|
| /home | Public | Build guides and project walkthroughs are shareable content |
| /finance | Private | Account numbers, debt details, reserve strategies |
| /career | Mixed | Newsletter and speaking content public; advisory pipeline and employer data private |
| /health | Private | Biomarkers, lab results, medication schedules |
| /inventory | Private | Tool values, purchase history, home contents |
| /skills | Public | Skill map could become portfolio content |
| /admin | Private | Data entry for all domains. Central management surface. |
| /meta | Private | Infrastructure health, deploy status, database metrics |
A dedicated /admin route where you can input data into any domain without touching code. Add a project, update a status, log a tool purchase, record a biomarker. The admin panel writes to Supabase. The domain routes read from Supabase. One entry point, every domain updated.
Claude Code generates React/Astro components, writes database queries, builds new route pages, and pushes to the repo. You review the pull request in GitHub, merge if it looks right. Claude chat with skills still handles the thinking (project kickoffs, expert panels, planning). Claude Code handles the building.
Six separate websites means six deployments, six auth configurations, six things that break independently, and six codebases to maintain. One app with routes gives you the same domain separation with shared infrastructure. Shared auth, shared database, shared deployment, shared styling. When you fix a bug in the nav, it's fixed everywhere.
This is the largest transition. You're moving from static HTML files with a database backend to a real deployed application. Claude Code does the heavy lifting. You review and approve.
Two strong options: Next.js (React-based, most ecosystem support, Claude Code knows it deeply) or Astro (simpler, faster for content-heavy sites, less JavaScript). For Manor, either works. Next.js is the safer bet because Claude Code has more training data on it.
Have Claude Code create the initial app in your manor repo. This replaces the static HTML files with a proper application structure. Your existing Supabase database stays the same. The app just reads from it differently.
Go to vercel.com, sign up with your GitHub account. Connect your manor repo. Vercel auto-detects the framework and deploys on every push. Free tier covers personal projects comfortably.
In Vercel's project settings, add your Supabase URL and API key as environment variables. This keeps your credentials out of the code. Vercel injects them at build time.
If you want manor.yourdomain.com instead of manor.vercel.app, add a custom domain in Vercel settings. Costs whatever your domain registrar charges (typically $10-15/year). Not required.
Have Claude Code create the /home route first. It reads projects from Supabase where domain = "home", renders them as cards with your Manor brand styling, and links to the markdown guides. This is your existing dashboard functionality, just in a new structure.
Create /home/back-yard, /home/front-yard, etc. Each sub-route filters by area. Within each area, split the view into DIY and Pro sections. Claude Code generates the components, you review.
Add /finance, /career, /health, /inventory, /skills as separate routes. Each has its own layout and data model but shares the nav shell, auth system, and database connection. Do one domain per week. Don't rush.
Turn on authentication in your Supabase project. Set up email/password login (just for you, so one account is fine). Supabase Auth is built in and free.
Have Claude Code create a simple login page at /login. Email + password, nothing fancy. Supabase handles the session management.
Have Claude Code add middleware that checks for an active session before serving /finance, /health, /inventory, /admin, and /meta. No session = redirect to login. Public routes (/home, /skills) skip the check.
For mixed routes like /career, set up row-level security in Supabase. Public rows (newsletter content) are readable without auth. Private rows (advisory pipeline, employer data) require a logged-in session. Claude Code writes the security policies, you review them in the Supabase dashboard.
Have Claude Code build a data entry interface at /admin. Forms for each domain: add a project, update a status, log a tool, record a biomarker. The forms write directly to Supabase. No file editing, no commits, no Claude involvement for routine data entry.
For efficiency: a "quick update" view that shows all active projects with inline-editable status and next action fields. Change five statuses, hit save, done. This replaces the entire Dashboard Updater workflow for simple status changes.
Your infrastructure health view. Shows: Vercel deployment status, Supabase database size and API usage, recent GitHub commits, uptime for each route, and links to all domain views. This is the "backend of the Manor" dashboard.
With the app running and the API live, any device can consume it. Your Raspberry Pi calendar reads from the same Supabase API. A wall-mounted tablet can display the /home route full-screen. A phone bookmark opens /health for quick biomarker logging.
Once the Vercel app is stable, your GitHub Pages URL (thekingofconsulting.github.io/manor) is no longer needed. The app runs on Vercel. The GitHub repo still exists for version control and Claude Code access, but Pages can be turned off.
The original index.html, static HTML guides, and markdown reference files can be moved to an archive/ folder in the repo. They served their purpose. The database and the app are the system now.
/admin in your browser. Find the project. Change the status, phase, or next action inline. Click save.You don't need to learn everything before starting. Learn each skill when you reach the tier that needs it, not before.
You're already reading and requesting changes to HTML. Formalizing this into "I understand what a div is, what a class does, and can change a color" is the goal. You don't need to write HTML from scratch. You need to read what Claude produces and know if it's right.
You're using GitHub Desktop as training wheels. Understanding branches, commits, merges, and reverts conceptually (not command-line) makes you confident instead of cautious.
Enough to understand how a page fetches data from a database and renders it. Not enough to write React from scratch. You need to read a fetch() call and know what it does.
Tables, rows, queries, relationships. Supabase has a spreadsheet-like UI that makes this approachable. You don't need SQL fluency. You need the mental model: "projects is a table, each project is a row, status is a column."
OAuth flows, row-level security in Supabase, API keys, environment variables. This is where "password protected" actually lives. Claude Code implements it, but you need to understand what it built.
Vercel or Netlify for hosting. Environment variables for secrets. Custom domain configuration if you want manor.yourdomain.com instead of a Vercel URL.
How your admin UI talks to Supabase. How each domain route reads from it. REST endpoints, query parameters, error handling. Claude Code writes the code, but you need to understand the flow.
React, Vue, Svelte deep dives. Claude Code writes components. You review them. You don't need to understand the virtual DOM or state management patterns.
Tailwind, Bootstrap, etc. Claude handles styling implementation. You describe what you want. Your Manor brand skills encode the design system.
Docker, CI/CD pipelines, Kubernetes. Overkill for a personal system. Vercel handles deployment automatically when you push to GitHub.
Even while running Beginner, these habits make the eventual transitions smoother:
When doing Workflow B, commit the manifest and registry first, then let Claude Code commit the dashboard edit separately. Two commits, two independent revert targets. This is the single most useful habit your coworker recommended.
Treat project-manifest.md as the source of truth, not the dashboard HTML. If they ever disagree, the manifest wins. This mental model maps directly to "the database is truth, the UI is a view," which is exactly how Intermediate and Advanced work.
The lowercase-hyphenated naming convention you're already using maps cleanly to database keys and URL routes. No migration headaches when filenames are already clean.
For the next 4-6 weeks, note every time you hit friction: a revert that lost data, a change that needed to propagate to two places, a guide that was expensive to regenerate, a page you wished was password protected. Those friction points tell you exactly which Intermediate features you actually need.
HTML/CSS basics and Git concepts. These are useful immediately and make every interaction with Claude Code and GitHub Desktop more confident. Start with freeCodeCamp's HTML/CSS course or The Odin Project's foundations track.