Plan the integration with your AI agent

npx nordva@latest init gets you keys, an MCP server and a working API call. It does not put a waitlist form on your landing page or a feedback button in your product. That part depends on your codebase, so it is a job for the agent that can read it.

This prompt asks the agent for a plan first. It writes NORDVA_PLAN.md and then stops and asks which step to build.

What the agent does

1. Reads NORDVA.md and, if the MCP server is connected, calls setup_check to see your project and plan.
2. If your project is still called “My Project”, suggests a name and a public address and asks before renaming it.
3. Reads your codebase: framework and routing, the landing page, sign-in, Stripe, how you release.
4. Writes NORDVA_PLAN.md. For each part of Launch it says whether it fits your product now, which files it would change, which key and plan it needs, and roughly how long it takes. The order is quickest visible win first.
5. Shows you a summary and asks which step to build. It builds nothing before you answer.

Three ways to run it

From the CLI. init ends by offering it. With Claude Code installed it can start Claude Code with the prompt already sent; otherwise it offers to copy the prompt to your clipboard.

As an MCP prompt. With the nordva MCP server connected, the prompt is called plan_integration. In Claude Code, type /mcp__nordva__plan_integration. Other clients list it under their prompts or slash commands.

By hand. Copy it from here, or from the checklist on the dashboard’s Overview page, and paste it into your agent’s chat inside your project:

Plan how to add Nordva Launch to this project. Do not change any code yet: I want a plan I can approve first.

1. Get your bearings. Read NORDVA.md if it exists. If the nordva MCP server is connected, call setup_check once to see the project, the plan and what is unlocked. The full reference is https://launch.nordva.dev/llms.txt and the endpoints are at https://docs.nordva.dev/endpoints/. Do not invent endpoints or fields that are not in there.

2. Check the project's name. If setup_check reports the name "My Project", suggest a name and a URL slug based on this repository (package name, README, site title), and ask me before calling update_project. The slug is public: it is the address of the hosted waitlist and changelog pages.

3. Read this codebase. Find out: the framework and how routing works; where the landing or marketing page is; whether there is sign-in and what identifies a user; whether Stripe is used; how releases or deploys happen; and whether there is already an email capture form, a changelog, a feedback form or in-app notifications that Launch would replace or sit next to.

4. Write NORDVA_PLAN.md with one section for each of these, in the order I should build them, quickest visible win first:
   - Waitlist: a signup form on the landing page (the zero-code widget or my own form calling POST /v1/waitlist/signups), passing the referrer and UTM values as "source" so signups can be attributed later.
   - Web analytics: the script tag in the head of every page (the snippet and the allowed domains are in GET /v1/analytics/settings), and, if there is sign-in, nordva('identify', { user_id, email }) after login and whenever a signed-in page of the app loads (once when a single-page app starts), so a later payment can be traced to the first visit and a browser that clears its cookies is linked again each day. Any form that already takes an email (contact, newsletter, login) gets data-nordva-identify on the form instead, which does the same without code. Where people come in without a web visit to read (an app, an import, a partner form), name it: identify's source ("ios-app") or data-nordva-source on the form, so the contact still shows where they came from. If the site already has a cookie banner, call nordva('consent', true) or nordva('consent', false) from it; if there is none and the visitors are European, the script can show its own with data-banner. In the site's privacy or cookie policy, name Nordva Launch as the analytics provider and link its policies (https://launch.nordva.dev/privacy/ and https://launch.nordva.dev/cookies/) instead of copying what it collects: those pages are kept current, and a copy goes stale when they change.
   - Goals, in the same step as the script, not later: a goal is a named action, and a visit that happened before it was named can never be counted. Start with the two that have attributes of their own, because they are where the Signups number comes from: data-nordva-signup on the signup button (or on the signup form, where only the submit counts) and data-nordva-signin on log in. Without them a product that has no Launch waitlist shows zero signups for ever. For sign-up through OAuth or a magic link, call nordva('goal', 'signup') on the page they land on afterwards. Then add data-nordva-goal="name" to the other elements that already exist in this codebase (no JavaScript needed), and call nordva('goal', 'name') only for things that are not a click, such as a form that submits by code. Go through the routes and components and list every place worth naming: the signup or "start free" button, a demo or "try it" link, the pricing page's plan buttons, the start of checkout, the first real action inside the product (the thing the product is for), an invite, a share, a docs or install command copy. Name them in lower case with hyphens and keep the name forever (renaming splits the history): signup, start-free, demo-open, checkout-start, first-project, invite-sent. Put the list in the plan with the file and line for each one, so I can tick them off.
   - A funnel, once those goals exist: the path you expect people to take (for example landing page, pricing, signup, first action) with create_funnel, so the step that loses people shows up. Free allows one funnel of three steps, Indie five of five.
   - Changelog: the widget or the hosted page, plus where in my release flow an entry gets published.
   - Feedback: a widget or form inside the product, passing my own user id.
   - Notifications: in-app notices for signed-in users.
   - Revenue, contacts and attribution: only if this project takes payments through Stripe. I connect Stripe myself in the dashboard; your part is only what reads the numbers.
   For each one give: whether it fits this product now (yes, later or no, with one line of why), the exact files you would add or change, which key it uses, which plan it needs, and a rough size (minutes or hours). Leave out anything that does not fit rather than padding the plan.

5. Show me a short summary of the plan and ask which step to build first. Build nothing until I answer.

Rules:
- NORDVA_SECRET_KEY is for server code only. Browser code uses the publishable key. Never print either key, and never commit the env file.
- Never ask me for a Stripe key and never put one in code. Stripe is connected read-only, by me, at https://app.nordva.dev/revenue.
- If something needs a higher plan, say so in the plan and carry on with the rest. Do not try to work around a plan limit.
- Prefer the zero-code widgets where they do the job. Write custom code only where the widget cannot do what this product needs.

What it will not do

• Change code before you pick a step.
• Ask for a Stripe key. You connect Stripe yourself, read-only, at app.nordva.dev/revenue. See Revenue from Stripe.
• Work around a plan limit. If a step needs a higher plan, the plan says so and carries on with the rest.

If you would rather not use an agent

The plan covers the same ground as the integration guides: waitlist, changelog, feedback and notifications. Start with the waitlist; it is one script tag.