Connecting an agent to the repository takes about ten minutes. Getting to the point where you are comfortable doing it takes a little longer, and it is mostly unglamorous setup you do once.

Protect the branch first

Do this before anything else, because every other safeguard assumes it. On GitHub, require a pull request for main and require the checks to pass. Whatever the agent does after that lands as a branch and a PR by construction, not by good behaviour.

Required checks on a private repository need a paid plan. If the client's repo is private and on the free tier, you get the PR requirement but not enforced checks, and you review manually. Worth knowing before you promise it.

Fill in the manifest

harness.config.json is the one file the generator reads. Project name, live host, commands, which platforms are in play, and the capability probes.

Those probes matter more than they look. An agent asked to add a contact form will happily wire one up and tell the client it works. The probe is what makes it say the opposite:

Form submissions: CANNOT (SLACK_WEBHOOK_URL is not set)
  -> ask the site owner to add it in the Vercel dashboard

scripts/preflight.sh runs those probes at session start and puts the results in front of the agent before it can claim anything. Run it yourself with sh scripts/preflight.sh.

Regenerate the platform files

Run pnpm harness. It writes CLAUDE.md and the mirrored skills under .claude/skills/ from one source: AGENTS.md plus the manifest.

Do not hand-edit the generated files. pnpm harness:check fails CI on a drift, which is deliberate.

Check the client can open a preview

The client's half of the loop is looking at the change before it merges, and that is the step most likely to be broken on day one. Preview deployments are usually protected by default: the URL works for you, because you are signed in, and returns a login wall for them.

Open a preview URL in a private browser window. If it asks you to sign in, so will the client. Fix it before handover by giving them access to the hosting project, issuing a bypass link, or making previews public. Which one is right depends on the client and the content, but the wrong answer is finding out on their first request.

Then watch the first pull request

Have the client make a real change on their own, and read what comes back. You are looking for three things:

  1. The change landed on a branch, never on main
  2. Only files under content/ were touched
  3. The preview deployment built

If all three hold, the setup is right. If the first one fails, the branch protection isn't on. If the second fails, the agent didn't read AGENTS.md, which usually means the platform file for that agent was never generated.

What clients actually ask for

Mostly copy. Prices, dates, a stat that went up, a testimonial from a customer who finally agreed to be quoted, a blog post about a launch. All of it is a paragraph in an MDX file, which is exactly the kind of change that used to arrive as an email and sit for a day.

The requests that need you are the ones asking for a shape that doesn't exist yet: a comparison table, a case study layout, a pricing page with a third column. That is a new Block, it takes an afternoon, and afterwards the client can use it as freely as the rest.

The part people skip

Read AGENTS.md yourself, start to finish, before you hand it to anyone. It is the ruleset every agent on every platform reads, and it ships with an empty appendix at the bottom for the incidents and quirks specific to your project.

Fill that appendix in as things go wrong. A rule with a story attached survives contact with the next agent session. A rule without one gets rewritten by the next person who thinks they know better.