Agent setup prompt: /agent-setup/prompt.md — one line to onboard a developer's agent onto NEXT

[next-devin]

Problem: developers now arrive with an agent already open — Claude Code, Codex,
Cursor — and the crawler numbers on this epic show those agents are hitting our surfaces
weekly. Cloudflare's developer docs meet that visitor with a one-line prompt ("fetch and
execute the instructions at developers.cloudflare.com/agent-setup/prompt.md") whose
target file contains per-agent, validated setup commands: skills for Claude Code, MCP
registration for Codex, JSON config blocks for Cursor and Windsurf. Thirty seconds later
the visitor's agent is a competent Cloudflare developer. We have nothing equivalent: a
developer's agent that wants to build on NEXT starts from scraping.

What it is: a hosted instruction file at a stable URL on the developers portal that a
developer's agent fetches and executes to set up a working NEXT development environment.
Version one is scoped to what is genuinely installable today, no new infrastructure:

• Scaffold a campaign project via campaign-init --non-interactive, which already
  downloads a starter template, seeds campaigns.json, and installs the AI context files —
  this is our existing "make the agent competent" payload, and this file becomes its
  distribution channel.
• Point the agent at the load-bearing docs: the developers llms.txt, the testing page
  (test cards and Test Gateway, developer-docs#40), and the campaigns quick start.
• Per-agent sections in the Cloudflare style: Claude Code, Codex, Cursor, and a generic
  fallback, each with exact commands or config, ending with a short completion readback
  telling the user what was installed and what to try first.

Explicitly out of scope for v1, noted so nobody blocks on them: a public skills repo and a
hosted docs MCP server. Both are the natural phase 2 (they are what make Cloudflare's
version rich) but each needs its own decision — a public skills repo forces the
internal/public skill boundary, and an MCP server is new hosted infrastructure.

Why the bar is high: the entire trust of this pattern rests on the commands working.
Cloudflare's file opens with "all commands are validated and ready to use," and that claim
is the product. A setup prompt that fails halfway in a fresh agent session is worse than no
prompt. The file must also stay conservative — explicit, inspectable commands only, no
credential handling, never overwriting existing config silently — because agent harnesses
treat fetched instructions as untrusted and will (correctly) refuse anything that smells
like injection.

Acceptance: from a clean directory, a fresh session of each named agent fetches the
file and completes setup end-to-end with no refusals and no manual repair, verified before
the URL is linked from anywhere. Fetches of the path are attributable in zone analytics.

---

Spec sketch (for the implementing agent)

• Serve as static markdown at a stable path on the developers portal, same mechanism
  family as the docs llms.txt route (docs#30 precedent); exact implementation depends on
  the portal framework. Absolute URLs throughout; version comment at top.
• Structure mirrors Cloudflare's file: preamble ("complete these steps yourself; do not
  ask the user to run commands") → per-agent sections → completion readback block →
  resources/troubleshooting links.
• v1 command inventory: prerequisites check (Node), campaign-init --non-interactive
  scaffold with AI context, docs pointers with ref=agent-setup markers. Nothing that
  requires auth.
• Validation: fresh-session run per agent (Claude Code, Codex, Cursor) from an empty
  directory; keep transcripts; re-run on every meaningful edit to the file. The
  six-probe harness from the 2026-08-17 substrate evaluation is the rig.
• Cross-link: file as related work on nextcommerce-site#92; sibling of the marketing-side
  evaluation prompt issue (payloads share the design rules, audiences differ).

[next-devin]

Two additions to v1 scope, from a closer look at Cloudflare's full /agent-setup/ hub (the page behind the prompt, not just the prompt file):

1. End with a first win, not with "setup complete." Every Cloudflare per-agent guide closes its quick start with a "Try a prompt" step — a concrete task the freshly-equipped agent can do in minutes. Ours should do the same, and we have the ingredients already: the scaffold from campaign-init, the Test Gateway, and the test cards. A closing step along the lines of "build a one-page campaign against the Test Gateway and place a test order" turns setup into a demonstrated capability inside the same session. The first impression of the platform is whatever the agent manages to do in the first ten minutes, so this step is the product, not decoration.

2. Make the setup surface itself agent-legible. Cloudflare serves a .md variant of every guide page and opens each one with a pointer to /agent-setup/llms.txt so any agent that lands on the human page can discover the whole surface. For us that is nearly free — the developers portal already serves llms.txt — so the human guide page and prompt.md should be two views of one content source, with the human page carrying the same index pointer.

Neither changes the v1 boundary (no public skills repo, no MCP server yet); both belong in the first cut because they are cheap and they are where the pattern's leverage actually is. The hub's remaining pieces — per-agent guide pages, the agent comparison and vocabulary section — are the growth path once there is more than one thing to install, and are noted on the epic rather than here.