Intro to Website Vibe Coding: Setup & Documentation (Part II)

Intro to Website Vibe Coding: Setup & Documentation (Part II)

This is Part II. Read Part I: Foundational Considerations first.

In case you didn’t heed the instructions above, make sure you’ve backed up anything that exists and have a record of important pages, posts, and customizations.

Chat to Research & Refine, Code to Implement

AI’s chat tool is much better at research and ideation than Code. Code does the technical very well; chat, not so much. Use chat for design iterations, functionality ideation—anything that’s directly related to the implementation of code (or other technical implementation).

The Challenge: Chat and Code Don’t Talk

Claude Chat and Claude code do not automatically communicate. I found myself having to manually upload and download, reexplain, or try to figure out what one was thinking.

Like others, I created a source .md file that explained who I was and what I was looking for. The problem is that things change quickly when you’re “working on the go.” It was a nightmare to remember what to update and where.

I’m a heavy Notion.so user – I use it for notes, databases, and a lot more. And Notion happens to be configurable as an MCP with Claude desktop.


What is an MCP?

MCP or Model Context Protocol. It’s a way for LLMs to integrate and share data with external tools.


Once the MCP was connected, I created a Notion “hub” for my project documentation. The beauty of this is that instead of me updating and uploading/downloading, I have Claude do it.

Example: I’ll have Claude Chat create a competitor analysis for a website idea, then a concept, and ultimately a design template. I’ll ask Claude Chat to update the Notion documentation for Claude Code to implement and even have it create a message to send to Code to get started.

Doing it this way will actually help you save usage credits, since Claude desktop will automatically read any files you’ve updated to Claude projects.

That’s the basic concept. Let’s dig into the details of structuring your Claude Website Hub.

Documentation

I use both a desktop folder and Notion when I vibe code.

The desktop file contains any documents I might upload to Claude or even Claude outputs (HTML design mockups, for example). Each project has a single folder (potentially with subfolders, but that’s up to you).

In Notion, I’ll create a page for each project. This is where I’ll put any source documents (what the project is, for example) and where Claude will update its documentation.

I’ll use one of my websites as an example throughout: it’s a WordPress website I built that catalogs horror movies. First, I set up a folder on my desktop and then created a page in Notion named “Horror Hating Claude Hub.”

There are a few pages I recommend when vibecoding:

Onboarding Guide

The onboarding guide’s purpose is to get Claude up to speed on your project and preferred workflow as quickly as possible. This will likely need to be updated as you go along, but I recommend including:

Keep the entire thing as brief as possible. Detailed information should be in a subpage unless it’s a critical to every project within your site.

Changelog

This might be the thing that saves you when you’re vibe coding. AI often forgets or will roll back changes when you least expect it, particularly when you’re working on a site over time.

What you include in your changelog is up to you. I recommend thorough but not granular.

Through Notion, Claude can set up a database structure:

Claude Code knows what a changelog is, so it’s likely to include more details within the body of the Notion database item. Still, either instruct it to include enough details to know what’s been done or double-check the entries after they’re created to ensure the information you want is being saved.

The beauty of the backlog is that it’s easier for Claude to identify (through categories) and review data that’s directly relevant vs having to sort through all the content to find the right information.

Queue/Backlog

It’s not necessary to have a backlog of tasks, but it is very helpful for multi-step/extended projects or complex tasks. You can absolutely use some kind of project or task manager and manage this manually, but I like to have Claude help me update these items (and create the database in the first place).

The queue database can range from simple to thorough—and you already know mine falls on the thorough side. 😉 At minimum, I’d include:

The reason you want the idea and why it matters is because sometimes we—Claude included—get stuck in the tool or function and loses sight of why it exists in the first place. If your tasks are on the simpler side, you can always combine the two or use Notion’s content area to put both.

For longer or more complex queues, include:

Use the content area to add further or extended detail.

You can add items manually: it’s essentially a task or project list, so add tasks as you think of them. You can also use these task items as a place to upload source content. For example, you want Claude to create an editorial calendar for you. Add files (Notion lets you do that), links, suggestions, lists—that way, Claude has all the source materials in one location.

You can also have Claude add to the database: this seems to happen while I’m having Claude complete something else. We’ll be working on a task that then surfaces a new subtask, so I have Claude add that to the queue.

It can also become part of your onboarding document: for example, you use GitHub tokens and need to change every 30 days. Include the schedule or spec in the onboarding document to have Claude check that task. (Bonus: if you’ve got Gmail connected, you could have Claude watch for the GitHub email warning you it’s time to change your token.)

Version Log

Honestly, you could have a version log for many things. I have a version log for my writing, page content, design templates, snippets…the point is to track versions so you could

  1. rollback to them,
  2. borrow for a future version, or
  3. review what worked/didn’t.

Despite having memory and search capabilities, Claude doesn’t remember everything, and this will shorten the response time and save on usage.

Here’s how I use this type of log:

Content Draft Log

I’m a writer, so I typically go through a few drafts before finalizing. I use my content log manually because I don’t use Claude to write for me, but you could. Or, reference it in Claude to have it edit for grammar, brainstorm titles, or create draft social posts for you.

Claude cannot relate content within Notion, but you can manually relate items if it benefits you. I do this for my content: I have one database that houses the main piece of content/idea (the parent) and then relate drafts to it (the children). (I automate this within Notion, but that’s a tutorial for another day).

I recommend this type of version log if you’re updating/refining content on a site page over time. I’ll often remember something I wrote from a previous version.

Putting it in Notion makes it searchable, too, so it’s easier to find.

Template Log

I highly recommend this if you’re doing any design work on your site. Even if GitHub keeps a version of it, it’s going to be a PITA to find in folders vs Notion’s searchable database. It’s easier of Claude does this—ask it what format it wants the version in. Claude and I use PHP code, so that’s what we record. You can either put the content directly into Notion, or reference the location of where it’s located on your desktop.

It can help to keep screenshots of the design, as most of us aren’t going to be visualizing code ourselves. I don’t do this very often because either I have to do it (and it takes a lot of time) or Claude does (and it takes a lot of time and resources). I screenshot elements of the design I like that I’m not using but I like and I could use later. Like if you’re designing something, and the section isn’t right for the page, but maybe you can use it somewhere else—that’s when it’s good to take a visual snapshot.

Stay in Context

Enjoyed this? Get more like it.

One email per week. Strategy, tools, and frameworks — no filler.