This is the complete list of what a handover of an AI-built software project needs to cover, with the reason each item exists. There is a free markdown template you can copy into any project. No email address, no gate, take it.
Generic project handover checklists exist by the dozen, written for construction projects and PM tools. Software built with AI coding agents needs its own version, because the failure modes moved. The risky part of a traditional handover was documentation nobody wrote. The risky part of an AI-assisted handover is knowledge that exists only in agent transcripts, claims nobody verified, and a builder who honestly cannot tell you which parts of the codebase were checked, because the agent moved faster than review did.
Use the checklist in the closing week of the project, not the closing hour. Several items produce questions only the build machine or the agent history can answer, and both have a way of becoming unavailable the moment the invoice is paid.
| Item | What done looks like |
|---|---|
| Repository transferred, with history | The recipient owns the repo, not a zip of its final state. History carries context that nothing else preserves. |
| Dependency manifest current | Lockfile committed, no floating versions doing silent upgrades, nothing installed globally that the manifest does not name. |
| Secrets out, template in | No credentials anywhere in the repo or its history. A .env.example names every required variable with a one-line note on where its value comes from. |
| Dead experiments removed or marked | AI-assisted builds accumulate abandoned approaches fast. Delete them or label them, because the recipient cannot tell exploration from product. |
| Item | What done looks like |
|---|---|
| Setup steps executed, not recited | Someone ran the written steps on a clean machine and they worked. Steps that should work are the single most common handover failure. |
| Build and tests pass from a fresh clone | Not on the build machine with its accumulated state. Fresh clone, clean environment, documented result. |
| External services enumerated | Every third-party API, database and queue the system touches, with which environment variable configures each and what happens when it is absent. |
| Local development story written | How to run it on a laptop, including the parts that need Docker, seeds or fixtures. |
| Item | What done looks like |
|---|---|
| Decisions recorded with their why | The choices that shaped the system and the trade-offs accepted at the time. In an AI-assisted build these live in agent transcripts and die with them unless extracted. |
| Claims separated from facts | What was independently checked versus what the coding agent said it did. A recipient treats these very differently, if you let them tell the difference. |
| Known gaps stated plainly | Unfinished work, untested paths, features that exist but were never exercised. The honest list, written down, beats discovery in production. |
| Architecture sketched | One page: the shape of the system, its modules and how data moves. Enough orientation that the recipient's first hour is reading, not archaeology. |
| Item | What done looks like |
|---|---|
| Verification results included | The output of the executed checks, with dates and environment, so the recipient knows what passed and when. |
| A way to re-check independently | The recipient can rerun the verification on their own machine and get a named answer, not a shrug, if anything diverges. |
| Item | What done looks like |
|---|---|
| Credentials rotated and transferred | Hosting, domains, databases, third-party dashboards. Rotated so the builder's access ends, transferred so the recipient's begins. |
| Admin access confirmed by the recipient | The recipient logs into each service themselves before the handover closes, while the builder is still there to fix it. |
| Operational notes | What to do when it breaks: where logs live, what the known failure modes are, who to call for the services it depends on. |
| Support arrangement stated | What the builder will answer, for how long, at what cost. An explicit zero is better than an implicit maybe. |
The template version is the same list as markdown checkboxes with space for evidence against each item. Drop it into the repository as HANDOVER.md, fill it in during the final week, and hand it over inside the project it describes. It is plain markdown under no licence restrictions, and it stays useful whether or not you ever touch our tooling.
Everything in the first four sections is mechanical extraction and execution, which is exactly what the free Mantyl CLI automates: it reads the repository and the agent history (Claude Code, Cursor and Codex), executes the setup in an isolated sandbox, and produces a project passport with every statement labelled by how it was established. The recipient re-checks it with one command. The fifth section, credentials and operations, stays human work, and the checklist exists so it does not get skipped. The wider argument for treating handover as an engineering step is in the AI code handover guide, and agencies shipping client work weekly should read the agency delivery version.