Guardrails First: What Good Code Even Means

Vibe coding gets a bad rap, and for a weekend idea I think it's fine: jam it out, see if it's fun, add the tests later if it sticks. Flatbed is not that. This lesson is where I wrap process around Claude before it creates anything, and that starts with a question I've argued about more than once: what does code quality even mean? My answer is change. If you've maintained a code base for years, you know the feeling of touching one thing (say, a coupon on a checkout transaction) and watching the change ripple through six or seven files. Interfaces, providers, plugs, hexagonal architecture, all of it exists so that the change you'll need to make later is cheap. That's what I want the guardrails to protect.

The platform is Cloudflare, because I like deploying for free and everything you see me do here you can do on a free account. The stack is the React framework that runs there (I call it Vnext in the video), D1 for SQLite, R2 if I need storage, and Drizzle for data access. With that settled, I dictate one big prompt asking for skills and a CLAUDE.md, with my opinions baked in: interface-based programming, command and query separation, no repository pattern (I have my reasons), hexagonal, BDD-style tests with one assertion per test. I ran this one at medium effort, no Fable needed, since it's loading skills, not solving a hard problem.

I want to build this app out, but before I do, I need to add some skills as well as a global instruction set for CLAUDE.md. The stack is going to be, I believe Vnext is what it's called, that runs on Cloudflare, the React platform. And I'll be using Cloudflare's D1. I think that's the SQLite. R2 is the storage. If I need storage, I'll be using it there as well, which of course means I need to be working with Cloudflare. So ensure that I have the CLI set up for that as well. But we need to be adding skills here. And so I want to make sure that this application is built for change, which means I want to have solid principles implemented. I want to make sure that we use interface-based programming as much as possible. I do not want to use the repository pattern because I hate it. I love the command and query separation. I like using classes, but I don't want to have dependencies and high coupling between anything. I want things to be changed and changeable easily. I do like the hexagonal architectural pattern. And I also like behavior-driven design tests using a BDD style, Given, When, Then. And we can talk more about testing as we go along, but I prefer to have one assertion per test. So set me up with some skills for this. Also set me up with best practices for React and Vnext and Cloudflare and all that.

Oh, and the last thing is, I know that since I'm going to be working with React, Vnext, and all that, I'm going to probably need a data access tool. Typically, I will go with Drizzle. Let's make sure that we're working with Drizzle as well. Also for data access, as I mentioned, I want to use SQLite and it's going to be using the Drizzle data access tool.

And that's the last thing I should do too: draft up the CLAUDE.md as well. I'm going to be using agents in a fan-out, so make sure the CLAUDE.md is set up to be reasonable for that, and trimmed and slim. And to that end, add a note for yourself to use a lot of emojis in your responses so you can be terse. I don't like to read through a bunch of stuff, as I will get confused and overwhelmed with walls of text.

While that runs I take a quick tour of the session rail in the Claude desktop app, which is slowly turning itself into an IDE: environments, remote control for picking the session back up from my phone at lunch, connectors, the context meter (my rule is keep it under a third, at least under half), and the file changes with Markdown preview. Then we read what came back. The skills were written for this project, not pulled off someone's website, and that's a real choice you get to make: a generic hexagonal skill, or one tuned to your particulars. Mine says "no repositories," which is exactly what I wanted to see. The CLAUDE.md is slim, with a stack declaration, non-negotiables, a list of which skill to load for which area, and fan-out rules like "stay in your assigned slice." Refine yours until it captures what your project is actually doing; this isn't an architecture course and I'm not going to read every file on camera.

One thing was missing: project management. I want decisions tracked and a docs directory that tells the story of the app, so I add a PM skill and tell it about trunk-based development while I'm at it.

I like to have a lot of documentation and tracking as we go along here. So let's create another skill called PM, or project manager, whatever makes sense. And so whenever we make an architectural decision, a data decision, a spec decision, feature add, bug fix, pretty much anything, I want it logged in a decisions.md directory. In fact, I want all the documents to live in a docs directory that will tell the story of the application. Now, I know I have a Git repository that will help me do this, but I also want to have a PM that will actively follow the process, make sure that the spec is filled out completely according to good project running standards. And to that end, I want to use trunk-based development. Might as well tell the PM that so they can track that as well. I don't need to get into Agile and Scrum just yet, because this is a small app, we don't need that much process. So create that skill for me, and then make sure the CLAUDE.md is updated with it.

You walk away with the setup I use before any real code gets written: a set of opinionated skills, a CLAUDE.md that routes Claude to them, and a PM that logs every decision. Next up is the one skill I think matters more than all of these, and it gets its own video.