olivia-keiter-build-methodology

Spec-driven development that actually works

I built a local web design business called Keiter & Co. in a single day using Claude as a collaborator. This repo is the methodology behind that build: the documents, the agent specs, the kickoff prompts, and the thinking that made it work.

It is not a tutorial. It is not a polished framework. It is the actual system I used, made public so other people can steal it.

Who this is for

If you have ever wanted to build something with AI and felt like you were missing the connective tissue between “here is my idea” and “here is a working thing,” this is for you.

That applies whether you are a solo operator trying to launch a side project, a senior leader trying to prototype something fast, or a developer who wants to see how someone without an engineering background structures AI-assisted builds. The methodology is not locked to any particular skill level. The caveats exist precisely because no methodology is.

What “spec-driven development that actually works” means

The build worked because everything was specified before it was built. Each agent had a documented purpose, a defined scope, a set of inputs and outputs, and a kickoff prompt that gave Claude everything it needed to start producing useful work without a long back-and-forth to establish context.

That is the spec-driven part.

The honest part is that specs are only as good as the thinking that goes into them. Claude will do exactly what you ask it to do, which means vague specs produce vague outputs, and gaps in your thinking show up immediately in what the agent produces. The methodology assumes you are willing to iterate and that your first draft of anything is a starting point, not a deliverable.

It also assumes you are building something real. If you are just exploring, great, but these documents were written with the expectation that they would be used in production.

How the pieces fit together

There are four types of documents in this repo. Here is what each one does and why it exists.

CLAUDE.md

This is the first document Claude reads at the start of any build session. It establishes who I am, what I am building, what my working style is, and what I expect from Claude as a collaborator. Think of it as the briefing document for the entire engagement. Without it, every session starts from zero. With it, Claude already knows the project, the constraints, and the tone before a single prompt is written.

If you adapt this methodology for your own builds, CLAUDE.md is the document you rewrite first. Everything else flows from it.

agent-foundation.md

This document defines the shared standards that apply to every agent in the system. Tone, formatting, handoff behavior, how agents should handle ambiguity, what they should and should not do on their own. It is the common layer underneath all six agent specs, so I did not have to repeat the same constraints in every individual spec.

If you build more than one or two agents, you want something like this. It keeps your agents consistent and makes updates easier, because you change the foundation once instead of six times.

Agent specs (/agents)

Each agent has its own specification document. A spec defines what the agent is responsible for, what it is not responsible for, what it receives as input, what it produces as output, and any rules specific to its function. The specs are meant to be precise without being rigid. They leave room for Claude to exercise judgment within a defined scope.

The six agents in this system are:

Intake handles the initial client conversation. Its job is to gather everything the system needs to understand a project: scope, goals, constraints, tone, timeline. The design challenge for this agent is that clients are not project managers. They do not always know what information is relevant or how to articulate what they want. Intake is built to draw that out without making someone feel like they are filling out a form. What it produces is not just a transcript, it is a structured brief that every downstream agent can work from.
Proposal takes the structured brief from Intake and produces a scoped, professional proposal ready to send to a client. The translation work here is significant. A brief is written for the system. A proposal is written for a person who needs to understand what they are getting, trust that you know what you are doing, and feel good about saying yes. Proposal is built to do that without overselling, padding scope, or producing the kind of generic agency language that makes clients feel like they are reading a template. The output should sound like it came from someone who already understands their project.
Scaffolding builds the structural foundation of a website project: file organization, page architecture, naming conventions, and the decisions that feel small until you need to change them six months later. This agent exists because structure is where most fast builds fall apart. When you are moving quickly, it is tempting to skip the architecture conversation and just start building. Scaffolding makes that conversation happen before a single line of content is written, so the Copy and Analytics agents are working inside a structure that was designed intentionally rather than one that accumulated by accident.
Copy writes the actual website content. It works from the Intake brief and the Scaffolding structure to produce draft copy that sounds like the client, not like a template. This is the agent where the quality of your upstream work shows up most visibly. If the brief is vague, the copy will be generic. If the scaffold is loose, the copy will not fit the pages it is meant to fill. When everything upstream is solid, Copy can do something genuinely useful: produce a first draft that a real human can edit into shape rather than one they have to throw out and rewrite from scratch. The goal is not perfect copy. The goal is copy that is already most of the way there.
Analytics handles measurement setup: Analytics runs monthly. It takes live site data for a client and produces two outputs: a plain language snapshot email for the client and a detailed internal report for Olivia and Alex. The client email is honest and human, written like a neighbor giving a friendly update. The internal report is complete and actionable, designed to catch problems before clients notice them. Neither output goes anywhere without human review.
Shared foundation is the base spec that the other five agents inherit from. It defines the things that should be true of every agent in the system: tone, formatting, how to handle ambiguity, what to do at handoff points, and what not to do without being asked. Without it, you end up repeating the same constraints in every individual spec, and when something needs to change you have to find it in six places instead of one. For anyone adapting this methodology, shared foundation is worth reading first. The individual agent specs tell you what each agent does. This one tells you how the whole system behaves. One practical note: make sure your kickoff prompt instructs Claude to flag and propose updates to the shared foundation whenever a session produces a change that should apply system-wide. If you do not build that habit into the workflow, the foundation becomes stale and you are back to finding the same inconsistency in six places. The spec is a living document. Program it like one.

Kickoff prompts (/kickoff-prompts)

Each agent has a corresponding kickoff prompt. A kickoff prompt is what you actually paste into Claude to start a session with that agent. It activates the agent, loads the relevant context, and tells Claude what mode it is operating in.

The kickoff prompts are not magic. They are structured. They work because the specs behind them are clear, not because of any particular prompt engineering trick.

How to use this for your own builds

You can take this methodology and apply it to any project where you are using Claude to do real work.

The fastest path is to start with CLAUDE.md and rewrite it for your own context. Keep the structure, change the content. Then look at agent-foundation.md and decide which parts apply to your project and which parts need to change. From there, write specs for the functions you need covered. The Keiter & Co. specs are examples, not prescriptions.

The one thing I would not skip is the kickoff prompt layer. It feels like an extra step until you realize it is what makes each session consistent. Without kickoff prompts, you end up re-establishing context every time, and the agents drift.

A few honest notes:

These documents were written for a specific business in a specific context. Some of the specs will be directly reusable. Others will need significant adaptation.
The methodology assumes you are comfortable iterating in conversation with Claude. If you are used to one-shot prompting, this will feel different.
Specs are living documents. The versions in this repo are snapshots from the build. A production system needs a process for updating them.

The broader project

This repo is part of a larger public build practice I am documenting at building-out-loud. That project covers the thinking behind how I build with AI across different contexts, including production systems, side projects, and this kind of rapid methodology work.

Keiter & Co. is live at keiterandco.com.

A note on reuse

This is open source. Take it, adapt it, use it for your own builds. If you build something with it, I would genuinely like to hear about it.

Attribution is appreciated but not required. Claiming you invented the methodology is bad karma.

Built by Olivia Keiter, who builds things that actually run in production and documents them so you can too. Girl bosses don’t gatekeep.