Prove It: The Public-Track Capstone

You have deployed something and shared it. Before you take it to work, prove it works for someone who did not build it. This is the capstone for the public tracks — beginner, intermediate, and developer — and it is the last thing those tracks build before the next lesson takes you into the workplace.

ℹOn a domain track?

Your track has a capstone build of its own — the biotech, business, government, and other tracks each carry one inside their module. Do that one. The next lesson asks for a result you can show and a verification you can describe: your track’s build is the result, and the cold-check method below is worth two minutes for the verification even if you build nothing more here. The “Record it” section at the end says exactly what the next lesson expects.

What “prove it” means here

Every lesson so far let you check your own work. That is not proof. Proof is when the checks pass on a run you did not drive.

The method is a cold check. You write a short list of yes/no checks before you build and save them in a file named CHECKS.md next to the build. You build. Then you hand the folder to a cold runner — a colleague who has never seen it, or a second AI CLI tool in a fresh session, meaning a brand-new conversation with no memory of the build and nothing in front of it but the folder, README.md, and CHECKS.md — and you say nothing while they run every check.

A check is one yes/no question with one command (or one click) and one expected result. A check can hold several cases — the ten questions in the first project below are cases inside one check — but each check gets exactly one PASS or FAIL.

The grade is the checks. Module 19’s capstone hands a runbook to a cold agent and counts the questions it asks; this one hands a finished thing to a cold checker and counts the failed checks — the same idea, applied to a build instead of a document. A question the runner has to ask you still gets written down, as a defect in your README, but it does not change the grade. The one exception is mechanical: if missing documentation stops a check from being run at all, that check is a FAIL on its own.

Start with the prompt, before there is anything to build:

Before we build anything: I want a tool that <one sentence — what it does,
for whom, from what input>. Write <three or five — your bar's number, from
the next section> yes/no checks that a stranger could run, all of them
together, in under ten minutes. Each check needs the exact command or click
and the exact result that counts as a pass. Save them as CHECKS.md.
Do not build anything yet.

That prompt is the third question of Module 10’s planning exercise — what does “done” look like? — turned into something a stranger can run. The AI will draft checks that are too generous (“the output looks right”). Push back until every one of them names a command and a result you could show someone in ten seconds.

The three bars

Same method, three heights. Pick the one that matches the track you chose at the start of the course — beginner, intermediate, or developer — not the difficulty badge at the top of this page, which rates the lesson. Write your bar on the first line of CHECKS.md so the runner knows what they are grading. A README is required from the intermediate bar up; on the beginner bar, CHECKS.md alone is the handoff.

Beginner — three checks. The runner is a second AI CLI tool in a fresh session, or a colleague. The build runs on your own machine.
Intermediate — five checks. The runner is a colleague if you have one, otherwise a second AI CLI tool in a fresh session; either way they set up and run the build from your README alone — the “how to run it” section that Share and Collaborate had you write — without asking you anything. A question they do ask is a README defect you fix afterwards.
Developer — five checks. The runner is a second AI CLI tool, not the one you built with. The build is in version control, and what failed and what you changed is written up as the thing you bring to the next lesson.

Pick one project

All three are built the way everything in this course is built: you describe, the AI CLI tool builds, you verify. You bring the material — a folder, a chore, a thing people already use — and there are no starter files from us, because a check against your own documents or your own weekly chore is the only kind that tells you anything. The table gives the checks each project must include; the rest of your bar’s count comes from your own build.

#	Project	You bring	The checks it must include
1	The Answer Desk — point your tool at a folder of your own documents and get answers that quote before they answer	A folder of documents you know well	One check holding ten cases: eight questions you know the answer to, each with the passage you expect written into `CHECKS.md`, and two the documents cannot answer. PASS only if every answer quotes a passage that actually contains the claim, and both unanswerables get a refusal, not a guess.
2	The Weekly Chore — automate one recurring thing you do by hand	One task you do every week that takes at least an hour	Two saved input files of the same shape, named in `CHECKS.md`, each producing the result you expect. A dry-run option that leaves every file untouched. A run with the input missing that prints an error naming the missing file and exits with a failure status, not silently.
3	The One-Notch Upgrade — improve something real that people already use	Something you or your team already rely on	One executable check the runner runs, plus acceptance evidence you record afterwards: the accepter’s name, what they did — merged the change, adopted the document, retired the manual step — and where that evidence is, a link or a message. Acceptance is separate from the cold check’s grade.

Project 1 is the one-folder, one-person version of a much larger discipline; the organization-scale version is Grounded Answers From Documents, a separate training in this series.

The hour

The badge on this lesson says sixty minutes. Here is where they go, and the checks come before the build on purpose:

Minutes	Spend them on
10	Choose the project and shrink it until one hour is plausible
10	Write the checks — the prompt above, then push back until each names a command and a result
20	Build it with the tool, the way Module 10 taught you to plan first and chunk the work
15	The cold run — you say nothing
5	One repair pass, then run the failed checks again

At twenty minutes of building, stop adding scope and shrink what is left. The cold run and the repair pass are reserved; a build that eats them was never going to be proved today.

Run the cold check

CHECKS.md is the whole handoff, for a person or a tool, so it carries the runner’s instructions as well as the checks. Its first lines say which bar this is, then: run the checks in order; do not fix anything; under each check, write the command you ran, what it produced, and PASS or FAIL; put any question you needed to ask in a “Questions” section at the bottom instead of asking it.

If the runner is a person: give them the folder, point at the first line of CHECKS.md, and leave the room — or at least the conversation. If the runner is a tool, open a fresh session in the tool you did not build with — Codex CLI if you built with Claude Code, Copilot CLI if you built with Codex — and hand it this:

Read CHECKS.md in this folder, and README.md if there is one. Run every
check exactly as written, in order. Under each check in CHECKS.md, write the command you ran,
what it produced, and PASS or FAIL. Do not fix anything. If a check cannot
be run as written, mark it FAIL and say what was missing. Put any question
you would have asked me in the Questions section at the bottom.

A runner that starts fixing things is no longer cold. Stop it and restate the “do not fix anything” line.

Record it

Two lists, and together they are the gap log — the record of what a stranger found:

Failed checks — for each, three lines: what failed, what you changed, and the one check you would add next time.
Runner questions — each one with the README fix that answers it. These are documentation defects, not the grade.

Keep the gap log. Your First Week with AI at Work is next, and it shows how to use exactly this kind of verification evidence when you introduce the result to people who did not watch you build it.

💬The pass bar

Every check passes on a run you did not drive. Not “it worked when I ran it.” Not “it works if you know to run it from the right folder.” Finding that out here, on a small thing, is the whole point of doing it before work.

Key takeaways

Write the checks first. Three to five yes/no checks, each with a command and a result, saved as CHECKS.md before the tool builds anything.
Cold means cold. The runner has never seen the build and you say nothing while they run it. A second CLI tool in a fresh session counts.
Failed checks are the grade. Questions are README defects to fix; unlike the runbook capstone, zero questions is not what you are measuring.
Keep the gap log. What failed, what you changed, what you would add — it is the verification evidence you take to work.

KNOWLEDGE CHECK

Which of these makes a check count toward passing this capstone?