When we finish a project, the client keeps the code. That used to be the whole list. Now the layer that drafted the code has to come with it, or the client's own team cannot extend the system the way we did. This is what we leave in the repo, in the order we hand it over.
The instruction files
At the root of every repo we hand back sits an AGENTS.md. It says how the system is built, what the pull request gates are, which data may never appear in a prompt, and where the runbooks live. It is the first thing an agent reads and the first thing a new engineer reads, and it is the same file. That is the point.
The specs
Requirements that live in chat history die with the session. We keep them in the repo with OpenSpec, an open source spec driven development tool that works with Claude Code, Cursor, Copilot, and most other coding agents. Two folders. openspec/specs holds the current truth about how the system behaves. openspec/changes holds each proposed change as a small folder: a proposal, a design, a task list, and the delta to the specs. The agent works the task list, a person reviews the proposal, and when the change ships the delta folds back into the specs and the folder is archived with a date on it. That archive is where a new engineer goes to learn why the system behaves the way it does.
The skills
A skill is a folder of instructions an agent loads when a task calls for it: how to write a migration for this database, how this framework wants a route structured, how to score a support call against the client's own quality rubric.
Most of a modern stack already has one. Frameworks and databases ship them, or the community maintains them, and they install with one command. When a maintained skill exists for Next.js or Supabase or the agent framework we picked, we use it and stop there. Maintaining our own copy of someone else's knowledge is a way to fall behind.
When nothing fits, we write our own. The ones we write most often are for the client's own process, because nobody else can: the integration playbook, the rubric a support team uses to grade its own calls, the escalation rules a voice agent has to follow before it hands a caller to a person. Those live in the repo next to the code and change in the same pull requests. An engineer who joins next year and asks the agent to onboard a new data source gets the answer the team agreed on, not the answer the model guessed.
DESIGN.md
Design systems used to live in Figma and in the heads of the designers who made them. That worked while people built every screen. Now agents build screens too, and an agent that has never seen your design system produces the internet's average: default spacing, default blue, a card that looks like every other card.
DESIGN.md is the fix. It is a plain markdown file at the root of the repo, a format Google Stitch introduced, that gives an agent the design system in the form it can use: tokens with their real values, the type ramp, the spacing habits, the component rules, and the reasoning behind them. When we deliver a design system, the Figma library gets a DESIGN.md twin and the file ships with the code.
The result is simple to state. A feature the client's team builds with AI six months after we leave looks like it belongs.
Two cautions we give every client. The file goes stale unless it is versioned with the product, so it changes in the same pull requests as the components. And it does not replace review. Generated UI is still work someone signs.
The MCP server
On a customer journey platform we built for a US airline, leadership used to wait two weeks for an analyst to score a handful of calls by hand. Now they ask a conversational agent a question in plain language and get an answer the same day, grounded in every conversation rather than a sample. The agent reads results that were already analyzed and scored. It searches and synthesizes. It never runs the analysis again, which is why the answer comes back in seconds.
That is the pattern we hand over whenever the data warrants it: an MCP server on the system's APIs, so a person who is not an engineer can connect Claude or ChatGPT and ask for the number instead of hunting for it.
Picture a VP building a board update. Instead of five dashboards, three filters each, and a screenshot, she asks for last quarter's figures and gets them from the system of record, with the query logged. Signed in, role scoped, logged like any other call. Turning it off is a gateway rule.
How the first draft gets made
The same pattern runs through the whole cycle, and in every stage a person is doing the work. The agent holds the pen for the first pass. In discovery, we still run the interviews and sit with the stakeholders. What changes is that an agent turns the transcripts, the existing documentation, and our notes into a first draft of the glossary and the requirements, with a source cited on every line, and we spend our time arguing with the draft instead of typing it. In design, our designers set the direction and make the calls; agents fan out the variations, the alternate flows, the content, and the edge cases so there is more to choose from, and DESIGN.md keeps all of it on brand. In engineering, the engineer decides the architecture, writes the parts that matter, and hands the agent the scaffolding, the tests, the documentation, and the boring half of debugging. In QA, our people define what has to be true; agents widen the coverage, propose edge cases, run accessibility and responsive checks, and diff the approved design system against what shipped.
The drafts are wrong in predictable ways. An agent reads a nullable column as required, or names a field by its comment instead of its use. That is why every draft cites its source and every change goes through a reviewed PR with the same CI gates, whoever wrote it.
Two habits from our agent work carry over. The evaluator is never the generator, because a model grading its own homework is generous. And anything deterministic gets code, not a model: schema validation, PII redaction, ID mapping. On a nine agent pipeline we built for a developer platform, two of the nine agents make no model calls at all, and those two are the ones that cannot hallucinate.
Architecture, security, production code, and the final deliverable stay under human review and ownership. AI moves the hours. It does not remove the people who sign.
The rules that do not move
No sensitive data goes into a prompt. On the airline platform, PII is stripped before anything reaches the model, deterministically, on every conversation, at zero tokens. On a voice booking agent we built on Amazon Connect, the model creates the payment link and never sees the payment data.
Nothing generated reaches main without a named reviewer.
The tooling runs under the client's security, privacy, data governance, and IP requirements, inside boundaries they approve, and nothing about their data trains a model.
The handoff has a test
The client names the engineers who will own the system in the first phase, and those engineers get the repos, the instruction files, and the skills in week one. One of them works inside the first build. By the second build, their engineers drive and we review.
The exit test is simple: their team onboards a full source, or ships a full feature, with us in review only. We write that into acceptance so it is a gate, not a hope. If a team can only do this with us in the room, we did not finish.
After the last phase, support is PR review and office hours for the first couple of solo runs. After that it is the phone number, which every client already has.