To connect juudd, you paste one sentence into your assistant: Fetch and execute the appropriate instructions to set me up for juudd from https://juudd.com/agent-setup/prompt.md. The assistant reads that file and does the setup itself. The file is the only copy of the instructions, and the build refuses to finish if what we serve is not that file.
This post is why the setup is one line, why the file is not copied anywhere, and the mistake in it that production caught on the day it went up.
Two readers had nothing to read
On 2026-09-16 juudd.com had one page about using the product, /docs, written for a person wiring a connector by hand. Two readers had nothing. One was somebody who talks to an AI and has never heard the word deploy. The other was an assistant that has been handed a URL and told to set itself up.
The second reader already had a file. prompt.md had been written for exactly that assistant since 2026-08-28, and its last paragraph said it was not a page anyone could fetch. We measured production that day:
Path on juudd.com | Answer |
|---|---|
/docs | 200 |
/guide | 404 |
/agent-setup | 404 |
/agent-setup/prompt.md | 404 |
A file written for a reader nobody could hand it to was documentation for no one.
The file is written for the one who runs it
prompt.md opens by saying that the assistant runs the steps itself, and that pasting them back to the person defeats the point. A person is needed for three things: approving commands their client asks about, signing in once in a browser, and, in Claude Code, starting a new session so the new tools load.
When the assistant stops for one of those, the file tells it to say exactly what the person does next, and that pasting the same line again afterwards finishes the setup. So the line is safe to paste twice. The file's first step is to check whether juudd is already there: if hello is in the tool list, skip to signing in.
That is why one line is enough. The person is never asked to choose a client, copy a config shape or know what a connector URL is. The choice, where one exists, belongs to the assistant that can see which client it is running in.
There is one file, and nobody copies it
The obvious way to serve prompt.md at a public address is to put a copy there. A copy is the thing that drifts, and the drift would be silent: an edit to the instructions would not reach the address an assistant fetches.
So the landing site's build serves the directory the file is written in, at /agent-setup/. There is no checked-in second copy and no script that generates one, because a script writes a file that then has to be hidden from version control, and a generated file is a copy with a longer story. An edit to the instructions is the edit production serves on its next deploy.
The build reads it back
A mount is configuration, and configuration is what quietly goes missing. A tidy-up that deletes the entry, or a build target that writes public files somewhere else, would ship a page telling people to paste a URL that answers 404, and nothing would fail loudly.
So after the build, the served file is read back and compared to the source, byte for byte. If it is missing or differs, the build deletes its own output and stops with an error that says which of the two went wrong. A build that did not pass should leave nothing behind to deploy.
Production found the mistake the same day
The file ends with a block an assistant prints when setup works, so the person can see it did. That block said "Nineteen tools available" directly beneath a list of twenty-two.
It was found by measuring production instead of reading the repository. The block now says twenty-two, and the page that shows a person what success looks like reads it out of prompt.md at build time. A page cannot show an assistant printing a sentence the file no longer asks for, and a file with no fenced block under its Confirm heading fails the build rather than rendering an empty box.
What has not been measured
An assistant starting from the line in a fresh conversation and reaching the success block has not been measured, and the page says so in a section of its own. Neither has whether a person who has never deployed can follow the guide without help. That second one is the criterion the guide exists for, and only such a person can close it.
What was rejected
- A checked-in copy at the public address. It is the shape that drifts, for the reason above.
- A script that copies the file at build time. It leaves a generated file that has to be hidden, and it is still a second file.
- A grid of clients and a comparison table. That is the shape of a reference site. The argument for one line is that the person chooses nothing, so there is nothing to put in a grid.
The rule, once
A setup instruction for an assistant should be one address it can fetch, served from the file it is written in and checked by the build that publishes it. What the twenty-two tools do is in the docs.