Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions app/llms.txt/route.ts
Original file line number Diff line number Diff line change
Expand Up @@ -73,8 +73,8 @@ function header(): string {
`- [Campaigns API spec, v1](${SITE}/api/campaigns/v1.yaml): raw OpenAPI`,
`- [Webhooks](${SITE}/docs/webhooks)`,
`- [Skills](${SITE}/docs/skills): AI agent skills for the platform`,
`- [Campaign agent quickstart](${SITE}/docs/agent-setup): optional wrapper around the current Campaign Page Kit docs and CLI that preserves developer choices`,
`- [Campaign agent quickstart prompt](${SITE}/agent-setup/prompt.md): stable plain-Markdown instructions for starting a new campaign project when that is the developer's requested task`,
`- [Campaign agent quickstart](${SITE}/docs/agent-setup): start from a funnel URL, existing repo or Map; preview locally and leave a resumable handoff`,
`- [Campaign agent quickstart prompt](${SITE}/agent-setup/prompt.md): stable plain-Markdown instructions for campaign intake, existing builds and continuation`,
`- [Prospect evaluation prompt](${SITE}/evaluate/prompt.md): source-grounded instructions for evaluating platform capabilities, fit, gaps, and a first pilot`,
`- [Testing](${SITE}/docs/testing)`,
`- [Agent guide (AGENTS.md)](https://github.com/NextCommerceCo/developer-docs/blob/main/AGENTS.md): navigation and evidence rules for agents reading this site`,
Expand Down
97 changes: 57 additions & 40 deletions content/agent-setup.md
Original file line number Diff line number Diff line change
@@ -1,44 +1,69 @@
<!-- next-commerce-agent-setup version=2 date=2026-09-04 -->
<!-- next-commerce-agent-setup version=3 date=2026-10-22 -->

# Start a Campaign Page Kit project with an AI agent
# Start or continue a NEXT campaign with an AI agent

Use this quickstart only when the user wants a new Campaign Page Kit workspace. It is an optional agent-friendly wrapper around the current Campaigns documentation and `campaign-init`; it is not a general Next Commerce development environment, a production architecture decision, or a replacement for the developer's chosen workflow.
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.

If the user wants to understand the platform, work in an existing project, build a storefront theme or app, or use the Admin API, do not scaffold a campaign. Read the [developer index](https://developers.nextcommerce.com/llms.txt?ref=agent-setup) and [platform capability map](https://developers.nextcommerce.com/capabilities.json?ref=agent-setup), identify the relevant documentation, and respond to that task instead.
For storefront themes, apps, or other platform work, use the [developer index](https://developers.nextcommerce.com/llms.txt?ref=agent-setup) and [capability map](https://developers.nextcommerce.com/capabilities.json?ref=agent-setup) instead.

## Before writing

- Confirm that the user's request calls for a new Campaign Page Kit project. If it is unclear, ask one concise question before installing packages or creating files.
- Inspect the current directory. If it contains an existing project, do not add a second project or replace its configuration. Ask whether to use that project or create a new subdirectory.
- Use the Node.js version required by the current [Campaigns quick start](https://developers.nextcommerce.com/docs/campaigns?ref=agent-setup). Do not impose a stricter version or relax the documented requirement.
- Preserve any template, source, project name, route slug, package manager, and agent-context choice the user has already made. The commands below use the docs' npm path for an empty project; do not replace an existing project's package-manager convention.
- Do not request, print, copy, or invent credentials. A workspace can be scaffolded and built without a Campaign API key.
- Do not call a live store or place an order unless the user has identified the store, authorized the action, and provided suitable test access.
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.

## Use the current Campaign Page Kit workflow
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](https://github.com/NextCommerceCo/campaigns-os/blob/main/docs/runtime-readiness.md).

Read the [Campaign Page Kit guide](https://developers.nextcommerce.com/docs/campaigns/page-kit?ref=agent-setup), then inspect the installed CLI contract before constructing a command:
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

| Supplied input | First action | Continue with |
| --- | --- | --- |
| Funnel/store URL or design | Read the source and distinguish observed facts from proposed behavior | A build brief, commerce dependency plan and local preview |
| Existing or cloned campaign repo | Read its instructions, build/configuration and retained evidence | Inspect current behavior and change only what the task requires |
| Existing external build | Inspect its own source, build and deployment conventions | The relevant Campaign Cart checks; retain its framework and host |
| Local CampaignSpec, saved Map or Build Packet | Identify the selected campaign and read existing intent/status | The Campaigns OS continuation command for that artifact |

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](https://github.com/NextCommerceCo/campaigns-os/blob/main/docs/campaign-build-brief.md) 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](https://github.com/NextCommerceCo/campaigns-os#quick-start) describes) and produce the [standardization report](https://github.com/NextCommerceCo/campaigns-os/blob/main/docs/campaign-standardization-report.md):

```bash
npx campaigns-os standardize --target /path/to/existing-campaign --no-doctor --json
Comment thread
next-devin marked this conversation as resolved.
```

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](https://github.com/NextCommerceCo/campaigns-os/blob/main/docs/build-packet.md) where it applies.

## Build a local preview before connecting commerce

For a new Page Kit workspace, read the [Page Kit guide](https://developers.nextcommerce.com/docs/campaigns/page-kit?ref=agent-setup). In an empty task directory:

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

If the user has not supplied a template, route slug, campaign name, and agent-context preference, ask for the missing choices together. Do not silently select a starter template or context file. Use the current template picker or catalog described by the CLI and docs rather than copying a fixed list from this prompt.

For a non-interactive agent run, replace every placeholder below with the developer-confirmed value:
Choose a family from the [template catalog](https://github.com/NextCommerceCo/campaign-cart-starter-templates/blob/main/templates.json): 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:

```bash
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
```

Choose the context value that matches the current tool, or `none` when the tool is unsupported or the developer does not want a generated context file:

| Tool | `--ai-context` value |
| --- | --- |
| Claude Code | `claude` |
Expand All @@ -47,36 +72,28 @@ Choose the context value that matches the current tool, or `none` when the tool
| GitHub Copilot | `copilot` |
| Other agents | `none` |

`campaign-init` is the authority for scaffold behavior, supported flags, conflict handling, and exit codes. Do not reproduce the scaffold manually if it fails. Preserve its output and follow the troubleshooting guidance in the Campaign Page Kit guide.

The [Next Commerce AI skills guide](https://developers.nextcommerce.com/docs/skills?ref=agent-setup) describes optional reusable skills. Installing `next-campaigns-setup` is not required for this quickstart. Use it only when the developer asks for the fuller guided setup/configuration workflow or another official tool routes the task to it.
The CLI owns scaffolding and conflict handling; preserve its failure output instead of recreating the scaffold by hand. A successful build writes `_site/`.

## Verify only what was requested
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.
Comment thread
next-devin marked this conversation as resolved.

Run the static build:
## Connect the approved implementation when ready

```bash
npm run build
```
The [next-campaigns-create skill](https://github.com/NextCommerceCo/skills/tree/main/next-campaigns-create) 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](https://developers.nextcommerce.com/docs/admin-api) or dashboard work. The Campaign Cart key and the Admin API token are different credentials. Use [next-campaigns-setup](https://github.com/NextCommerceCo/skills/tree/main/next-campaigns-setup) for Page Kit configuration; existing projects keep their own build procedure.

Use the JSON emitted by `campaign-init` and the generated project files to confirm that:
When real references and intended behavior are known, use the installed Campaigns OS [agent entry](https://github.com/NextCommerceCo/campaigns-os/blob/main/AGENTS.md) 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](https://github.com/NextCommerceCo/campaign-cart-starter-templates/tree/main/docs/fixtures/campaign-specs) show.

- the selected campaign is registered in `_data/campaigns.json`;
- its source directory exists under `src/`;
- the requested agent context file was created, or no context file was requested;
- the build exits successfully and writes the campaign to `_site/`.
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.

Inspect one generated entry page and briefly describe what the selected starter contains. Treat that as proof of a local scaffold only. Do not claim the project is connected to a store, production-ready, or tested end to end without the corresponding evidence.
## Leave work another session can continue

If the user explicitly wants to continue, follow the current Campaigns and testing documentation for configuration and test-store work. Otherwise stop after the verified local build; do not turn a quickstart into an unsolicited production setup.
Use the repository's README or existing handoff note and link the artifacts that exist rather than creating a second record. Include:

## Report back
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.

Tell the user:
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.

1. Which directory and existing/new project path you used.
2. Which developer-provided template, slug, name, and agent-context value you used.
3. Which official docs and CLI contract you followed.
4. Whether `campaign-init` and the static build passed.
5. What you verified in the generated output.
6. What remains unconfigured or untested, and the next step relevant to the user's stated goal.
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.
8 changes: 5 additions & 3 deletions content/capabilities.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -266,8 +266,9 @@ capabilities:
title: Campaigns
summary: >-
Campaigns are custom checkout funnels (landing, checkout, upsell, receipt pages)
backed by the CORS-enabled Campaigns API, built with the Campaign Page Kit and
starter templates. A campaign's checkout is separate from the storefront checkout,
backed by the CORS-enabled Campaigns API. Campaign Page Kit and starter templates
provide a reference build path; existing Campaign Cart applications retain their
tooling. A campaign's checkout is separate from the storefront checkout,
but its orders are ordinary store orders that share the orders list, inventory,
and subscriptions.
audiences: [merchant, developer]
Expand All @@ -279,14 +280,15 @@ capabilities:
developer_docs:
- /docs/campaigns
- /docs/campaigns/page-kit
- /docs/agent-setup
- /docs/campaigns/templates
- /docs/campaigns/api
- /docs/campaigns/admin-api
api_operations: [tag:campaigns]
webhooks: []
skills: [next-campaigns-create, next-campaigns-setup]
status: available
last_verified: 2026-09-14
last_verified: 2026-10-22

- id: storefront-themes
title: Storefront themes
Expand Down
Loading
Loading