Start or continue a campaign with an agent

Give your coding agent this instruction:

Read https://developers.nextcommerce.com/agent-setup/prompt.md and help me start or continue this campaign from the URL, repository or Map I provide. Preserve my build and hosting choices. Prepare a local preview and resumable handoff; keep live merchant state untouched.

The fetched file is plain Markdown at a stable URL. It uses the same source as the instructions below, contains no credentials, and keeps the current CLI and Campaigns docs authoritative. It covers campaign intake, existing builds and continuation. It does not require a new project or store credentials before source inspection and local planning.

Instructions your agent receives

Use this procedure when the user supplies a funnel URL, design, existing campaign repository, or saved Map and wants to build, change, preview, or resume a campaign. Keep their build and hosting choices. Campaign Page Kit is the reference path for a new static campaign; an existing application does not need to become a Page Kit project.

For storefront themes, apps, or other platform work, use the developer index and capability map instead.

Before writing

Inspect the supplied files and current directory: the intended change, source URL or design, existing repo, campaign identity if known, build command, output directory, hosting method, and any saved brief, spec, Map or evidence. Preserve existing work; do not scaffold over an existing project.

Ask for missing business decisions together, such as target products, offer changes or which source design to follow, and keep inspecting and planning while answers or credentials are missing. Record installed versions and the source commit of any reused template or repo. For work that includes Campaigns OS, follow its runtime guidance.

Store access, repository publishing, deployment, test orders and analytics sends are separate effects; a source URL or API key authorizes none of them. Never print credentials or put them in the brief, handoff, committed files or command output.

Choose the entry point

These entries can join the same work at different points. Do not replay provisioning or scaffolding because a new session starts.

From a source URL to a proposal

Read public HTML or user-provided source without submitting forms or using cart or checkout endpoints. Record source URLs and capture dates. Describe the observed products, variants, prices and currency, offer wording, page structure and navigation; mark checkout rules, shipping, subscriptions and post-purchase behavior unknown when the source does not establish them. A displayed price is not proof of a NEXT package or offer.

Save presentation intent in the Campaign Build Brief format (schema_version: campaigns-os-build-brief/v1, brief_mode: guided, status: needs_answers). In the project's README or handoff note, record the proposed page journey and the commerce dependencies: catalogue products and prices, packages, offers and shipping, page behavior, and the domains, payment linking and analytics still needed. Do not invent package IDs, campaign keys or a saved Map to make validation pass.

Inspect an existing or cloned build

Read the repository's brief, spec and generated records before deriving intent from code; code shows what was implemented, not what the merchant wanted. If Campaign Cart is present, run the project's pinned Campaigns OS (or install it as the quick start describes) and produce the standardization report:

npx campaigns-os standardize --target /path/to/existing-campaign --no-doctor --json

The report inspects source without modifying the target and does not migrate the project, prove checkout or certify a launch. If the application is not recognized, record that and inspect its own integration rather than changing frameworks to satisfy the detector.

For a clone, record the source commit and list the bindings to replace: campaign and store identity, packages, offers, domains, analytics IDs, URLs and custom business logic. Prior QA applies to the source campaign; new bindings need their own proof. For a maintenance task, compare the requested change with the existing brief, spec and commerce configuration, following the reconciliation and handoff procedure where it applies.

Build a local preview before connecting commerce

For a new Page Kit workspace, read the Page Kit guide. In an empty task directory:

npm init -y
npm install next-campaign-page-kit
npx campaign-init --help

Choose a family from the template catalog: preserve a template the user already chose, otherwise recommend one for the product, variant and page requirements and record why. For a non-interactive run, replace the placeholders with the selected values:

npx campaign-init --non-interactive --json \
  --template <selected-template> \
  --slug <selected-route-slug> \
  --name "<selected-campaign-name>" \
  --ai-context <claude|codex|cursor|copilot|none>
npm run build

The CLI owns scaffolding and conflict handling; preserve its failure output instead of recreating the scaffold by hand. A successful build writes _site/.

A scaffold made without a campaign key runs against the starter templates' demo campaign: the prices, cart and checkout it shows are the demo store's. Use it to review layout and flow, place no orders against it, and record in the handoff that the preview is demo-bound; it is not evidence about the merchant's campaign. Bind the real campaign with npm run config before any check that is meant to count, which needs the authorization steps below. The preview shows the stock template, not a rebuild of the source funnel.

Connect the approved implementation when ready

The next-campaigns-create skill creates, edits, adopts and clones Campaigns App configuration behind its plan-approval gate; it reads existing catalogue products, and missing products or prices need the Admin API or dashboard work. The Campaign Cart key and the Admin API token are different credentials. Use next-campaigns-setup for Page Kit configuration; existing projects keep their own build procedure.

When real references and intended behavior are known, use the installed Campaigns OS agent entry to choose local-spec or saved-Map intake; its --help lists start for intake and next for continuation. Current authoring is CampaignSpec v5: select chooses before payment, checkout_step collects a form step, and checkout takes payment, as the public multi-step examples show.

Do not save a Map, publish a repo, deploy, submit an order or send analytics as a side effect of this procedure. Record what is authorized, then invoke the matching capability, and say which evidence was obtained: a doctor pass, an intercepted analytics request and a vendor receipt are different things.

Leave work another session can continue

Use the repository's README or existing handoff note and link the artifacts that exist rather than creating a second record. Include:

1. The requested outcome, chosen implementation and host, source URLs or clone commit, and unresolved business questions.
2. Brief, spec, Map or Build Packet paths that exist; list absent artifacts as absent. Keep credentials out.
3. Installed tool and skill versions, working directory, build command and output directory.
4. Which commerce bindings are verified, missing or inherited, and which actions remain unauthorized.
5. The checks run, what they prove, outstanding defects, and the next local action or the specific missing input.

A returning session reads that note, checks the current revision and installed versions, and resumes without resetting the project or replaying completed writes. Let Campaigns OS commands create their own stage records; never hand-write a passing Assembly Report or reuse a source campaign's QA for a clone.

Report in plain language: what can be reviewed now, what is still unconfigured or unproved, and what is needed to continue. Stop at the user's requested boundary.