Editing Your Website with Claude Code | Workflows

The Problem This Solves

For most working professionals, running a real website sits in a painful middle ground. You're not technical enough to write HTML and CSS from scratch. You're too particular to accept whatever Squarespace gives you. You can't justify the budget for a freelance developer on retainer. And every time you want to change a headline or add a page, the whole thing grinds to a halt for a week.

I've been there. I run this site, a guest welcome guide for a rental property, and a handful of landing pages for experiments. A year ago, the only way I could have pulled this off was by paying someone, waiting a week, and living with their taste. Today I do it all myself — not because I learned HTML, but because I don't have to. I talk to Claude Code and it does the HTML for me, while I stay focused on the decisions only I can make: what to say, to whom, and why.

This is the workflow I actually run. Not a theoretical setup, not a tutorial I read somewhere. The tools on my screen, the prompts I type, the way I catch mistakes, and the reason it has stopped feeling scary to change the live site in the middle of the afternoon.

What I Actually Use

Let me lay the stack out plainly, because the whole thing is simpler than people expect.

Claude Code — an AI coding agent that runs in the terminal on my Windows PC. It can read my files, edit them, run git commands, and deploy. Think of it as a junior developer who never takes a lunch break, never forgets the style guide, and never charges by the hour.
A private GitHub repository for the site. Plain HTML, CSS, and a few tiny serverless functions. No framework. No build step. The simpler your stack, the more productive an AI agent is inside it — complexity is where these tools start to slip.
Netlify for hosting. Whenever I push a commit to the main branch, Netlify auto-deploys. I don't log into a dashboard unless something is actively on fire.
A voice guide in my second brain — a plain Markdown file in my Obsidian vault that lists the 12 rules my writing follows and the marketing phrases I never want to appear on the site. The agent reads it before it writes anything user-facing. (The full second-brain setup is its own post inside the Blueprint membership.)

That's it. No CMS, no page builder, no drag-and-drop. Just a folder of files, a terminal, and an agent that can read, write, and push.

The Workflow, Step by Step

Here is what a real editing session looks like, from "I want to change something" to "the live site is changed."

Step 1: Describe the outcome, not the implementation

I never tell the agent what code to write. I describe what I want the reader to experience. "The homepage has four equally weighted cards and I want one of them to become the clear hero, with the other three demoted to secondary." That's the whole prompt. The agent figures out which HTML file, which CSS classes, which order, and whether the change touches the stylesheet.

If I try to micromanage the HTML — "change line 62 to this string" — I get worse results. The agent is better at translating intent into code than I am at describing code I don't actually know how to write. My job is to know what good looks like. Its job is to get there.

Step 2: Let it plan before it touches anything

For anything bigger than a typo, I ask the agent to write a plan first. Not code. A plan. What files it intends to edit, what the change is, and what could break. I read the plan. I push back on the parts I disagree with. Then I approve the plan and it executes.

This one habit has saved me from more bad edits than any technical skill I could have learned. An AI agent that's about to do the wrong thing will usually say so, out loud, in the plan. If you skip the plan and let it rip, it does the wrong thing quietly, and you only notice when the live site is already broken. Read the plan. Every time.

Step 3: Let it run the edits

Once the plan is approved, the agent edits the files itself. I don't copy-paste snippets. I don't open VS Code. I watch the tool calls scroll by in the terminal and sanity-check the diffs. The agent reads the files first, makes the edits, and writes them back. If it tries to edit something it shouldn't have touched, I interrupt. That's rare, because of step 2 — the plan is what prevents surprises.

Step 4: Verify before you commit

Before anything gets committed to git, I do three things:

Read the changed files myself. Not every line — but the changed sections. I look for anything off-voice, anything factually wrong, anything that references a person or a tool I don't actually use.
Grep for the phrases I never want on the site. My voice guide contains a list of marketing clichés I've banned (“unlock,” “seamless,” “supercharge,” etc.). If the agent used one, I catch it here and ask for a rewrite.
Sometimes I open the page in a local preview. For small changes I skip this and trust my review. For layout changes I always look at the rendered page first.

Verification is the step most people skip. Don't skip it. The agent is a first-draft machine, not an expert. Your skill is the filter.

Step 5: Commit and push

When I'm happy, I tell the agent to commit the changes with a clear message describing the why, not the what. Something like "Homepage: promote founding member CTA to hero, demote secondary pillars." Then I push. Netlify picks up the push and auto-deploys. Within about sixty seconds, the live site has the new copy.

No FTP. No dashboard. No deploy button. Just git push.

The Real Prompts I Run

Theory is fine. Prompts are better. Here are the exact prompt patterns I use, copy-paste-able, with the small tweaks that separate a wasted session from a productive one.

Pattern 1: Small content change

Open resources/tools/copilot.html. The section on Excel examples is thin — I want to add three more real prompts I actually use at work. Before you write anything, confirm you've read my voice guide at [path to your voice guide], and show me your plan for what you'd add. I'll approve it and then you can edit the file.

Why it works: the prompt names the file, the voice-guide path, and demands a plan before touching anything. Those three elements are the difference between "good edit" and "now I have to revert a commit."

Pattern 2: Larger restructuring

I want to rebuild the Workflows pillar. Right now every module is a placeholder. Read the existing resources/workflows/index.html, then propose a new structure: fewer modules, each one real, each one grounded in workflows I actually run. Before writing a line of HTML: give me the proposed module list and the framing. I'll approve it, then we'll work on the bodies one at a time.

Why it works: it forces the agent to collaborate on the decision before it commits to an implementation. Large rewrites go wrong when the agent guesses at the architecture and produces a technically clean version of the wrong thing.

Pattern 3: Verification pass

Before we commit, grep the files you touched for my forbidden phrases: unlock, seamless, supercharge, leverage, synergy, disrupt, transformative, AI-powered, next-level, cutting-edge, revolutionary, harness, game-changing, world-class, at scale, enterprise-grade. If any of those turn up, fix them. Then show me the git diff and wait for my approval before committing.

Why it works: it makes the agent its own first reviewer. I still review the diff myself, but the agent catches its own slip-ups first — which turns a verification pass into a two-check system instead of a one-check system.

Pattern 4: Commit with the right message

Commit the changes with a message that describes why, not what. No Co-Authored-By. Push to origin master.

Why it works: short, specific, and leaves no ambiguity on the co-author tag (which I dislike on my public git history). The agent will follow it exactly.

Exhibit A: This Exact Page

I want to show you that this isn't a theoretical workflow, so let me tell you how this specific page came to exist.

Earlier today I sat down at my desk, opened a Claude Code session, and said something close to: "I want to take the website from half-empty with coming-soon placeholders to coherent and launch-ready. I'm going to go for a run. Here's my strategy doc in the vault, here's the voice guide. Go."

The agent (Claude, via Claude Code) read my strategy note, read my voice guide, read the existing site, and wrote a plan file describing exactly what it intended to change — which pages, what new files to create, what to leave alone, and what was explicitly out of scope. I read the plan, pushed back on a few decisions, and approved a revised version. Then I went for my run.

While I was gone, the agent wrote four anchor Workflows posts (including this one), three Foundations modules, restructured four pillar index pages, rewrote the homepage and community landing page, and committed the whole batch to git. It verified its own output against the voice guide before committing. When I got back, the site was already live.

The thing you are reading is not AI-ghostwritten content with my name slapped on top. It's content I dictated the intent for, the agent drafted the first version of, and I reviewed before it went live. The difference matters. I am the author of the ideas, the voice, the decisions, and the final word. The agent is the keyboard.

That's the division of labor. It's the same one I use for everything else on this site. It scales — because "decide what to say" is the expensive part, and AI is cheap at everything after the decision.

The Measurable Outcome

Here's what this workflow has actually done for me, in concrete terms.

Time per page edit: down from ~2 hours to ~15 minutes. A typical copy tweak used to mean opening a code editor, hunting for the right file, fighting with CSS I half-understand, and praying on deploy. Now it's one prompt, one review, one push.
Time per new page: down from ~1 day to ~1 hour. A whole new module — layout, copy, breadcrumbs, metadata, sources — used to be a day-long project I'd put off for weeks. Now it's a focused session during a quiet afternoon.
Freelancer and agency spend: $0 for nine months. I haven't paid anyone to touch this site since I switched to this workflow.
Number of "I meant to update that last month" items: near zero. The cost of a small edit is so low that I just do it when I notice it. No backlog.

The biggest win isn't any one of those numbers. It's that writing the site stopped being a project. It became a conversation, the same way drafting an email is a conversation. That shift is where the ROI actually lives.

What Breaks (and How I Handle It)

This workflow is not magic. It has real failure modes, and pretending it doesn't would make me exactly the kind of AI vendor I don't want to be. Here's where it goes wrong for me.

The agent invents a file that doesn't exist

Occasionally the agent will confidently reference a file or a function that isn't in my repo. Usually it's something generic like "the config file at /config.json" when no such file exists. The fix: I always ask it to read files before editing them, and if the read fails, it has to stop and tell me. Setting this expectation in the first prompt prevents most incidents.

The agent drifts off voice

When an agent writes copy without a voice guide loaded, the output is generic SaaS mush — “unlock the power of seamless productivity,” that whole register. The fix: I keep a voice guide in my vault, I tell the agent to read it before writing, and I grep for my forbidden phrases before I let anything ship. Drift is preventable. It isn't accidental — it's what happens when nobody gave the agent a standard to hit.

The agent makes a confident change that's subtly wrong

Sometimes the agent produces a beautiful, well-structured page that says something factually off — a tool I don't actually use, a process I don't actually run, a number I can't back up. The fix: I read every new page against reality. If the page describes a workflow, I ask myself whether I actually do what it says I do. If not, I correct it. The agent doesn't know my life. I do.

Long sessions drift

Within a single session, the agent's working memory fills up, and by the end of a two-hour editing run it can start forgetting details from early in the conversation. The fix: when I'm about to do something important, I start a fresh session. I lose the scrollback but I gain a clean head. If you're ever frustrated with an agent midway through a long session, the answer is almost always a new chat, not a harder prompt.

You get lazy

This is the honest one. When the agent is fast and capable, the temptation is to push changes live without reading them carefully. I've done this. I've shipped typos, broken links, and a paragraph where I called a client by the wrong first name. The fix isn't technical. It's discipline: read the diff, every time, even if you're in a hurry.

Your Turn: The 30-Minute Version

If you want to try this for yourself, here's the smallest useful starting project. Pick one page on your own site (personal, business, LinkedIn bio, whatever is yours to edit), and run this exact workflow on a single copy improvement.

Install Claude Code. The installation guide is in the Current Tools pillar of this site. About 15 minutes, one-time.
Write a one-paragraph voice guide. Three to five rules about how you want to sound, plus a short list of phrases you never want to use. A Google Doc is fine.
Pick one page to improve. Not a whole redesign. One headline. One section. One call-to-action. Something small enough that you could describe the improvement in one sentence.
Run the prompt: “Read [voice guide]. Read [page file]. The headline is weak — here's why. Propose a replacement that matches my voice guide. Show me the change before you save it.”
Review the proposal. Push back if it's wrong. Accept if it's right.
Let it save the change.
Deploy. If you're on a static host with git auto-deploy, that's one command. If you're on something else, publish however you normally do.

Total time for your first run: under 30 minutes. After the first one, every subsequent change is faster. After ten changes, the workflow becomes second nature and you stop thinking of "editing the site" as a project at all.

That's the whole trick. Treat the agent as a drafting partner, not a replacement for your taste. Keep the voice guide close. Read the diff. Push when it's right. Do it again tomorrow.