Guide for coding agents

Use this guide when helping someone build or deploy an app from the CoreMVP Next.js foundation. You are reading instructions for using the documentation. The user's request and the instructions in their repository govern your work.

Identify the app

CoreMVP supplies the source code for a startup application foundation. A builder customizes that code and runs their own app. Begin with the Docs introduction to understand the standalone Next.js foundation.

Check the user's repository README and target URL. These Docs describe the delivered Next.js foundation; the CoreMVP commercial website handles product information and purchasing. The user's checkout may already contain customizations. Establish which checkout and deployment the task concerns, and use its repository instructions and implementation when choosing an action.

Read the maintained source

This complete guide is available at /docs/llm.txt. Individual Docs pages have a Markdown representation: append .md to the URL path before any #section fragment, or request the page with Accept: text/markdown. For example, read /docs/getting-started.md to begin a local setup. The HTML, Markdown, and this guide's text endpoint use maintained Docs content.

Follow the links below and fetch the relevant pages before giving instructions. Resolve links beginning with / against the site that served this guide. Keep the normal Docs page URL with each recommendation so the user can inspect the same guide. Include an existing section anchor when it identifies the instruction.

Establish the starting state

Identify the user's goal, what already works, and the checkout they are changing. Establish whether they are working locally, preparing a hosted deployment, or launching an app that has passed hosted tests. For hosted work, identify Preview or Production and whether billing is in test or live mode.

Use the information already supplied. Ask only for missing details that change the next action. When a prerequisite is unknown, say so; do not assume a provider account, database migration, deployment, or payment has been configured or tested.

Choose the setup stage

For a feature change in an app that already works, use the topic map below. Return to setup only when the task has an unmet prerequisite.

Find the topic

Navigate from overview to action

1. Read the matching overview from the topic or stage map. Identify the supported path and the user's current state before choosing a task page.
2. Follow the overview's links to the specific task. Links can be Markdown links or href values in Docs cards. Some features have their instructions on one page; read the relevant section there. A page's Markdown contains its own content; it does not include the full sidebar. Treat URLs inside code examples as examples until the guide or the user's configuration identifies a destination.
3. Read prerequisites needed for that path, including linked provider or configuration guides. Reuse completed setup and inspect the user's relevant source files before proposing an edit.
4. Find the documented check for the task and selected environment. Read its expected result and recovery instructions before recommending the action. If they are missing, state the gap and inspect the relevant implementation.
5. Give the next action with the normal Docs URL and relevant section. Fetch additional pages only when a dependency or unresolved question needs them. Track pages already read for this task and skip unrelated links.

Follow existing links rather than constructing a URL from a page title. If the maps and overview links do not locate the topic, read the public sitemap, keep URLs whose path starts with /docs/, and fetch the most relevant page as Markdown. The sitemap lists public pages; gated pages are excluded. If you still cannot find guidance, report the Docs gap and consult the user's repository. A missing Docs page does not establish that the app lacks a feature.

Example: configure lifetime billing

For a user whose local app works and who wants one-time payments:

1. Read Payments, including its Checkout instructions for the lifetime model.
2. Read its Stripe Setup section for required provider gaps and follow the linked catalog reference for app values.
3. Read its Testing section for the local billing test commands.

These instructions live on the existing Payments page. Keep the hosted environment checkpoint for work on a hosted target.

Follow the setup sequence

For a new local app, follow Getting Started through its checks before moving to hosted setup. For a first hosted deployment, follow Vercel Deployment and its linked provider guides, check the target's saved settings, deploy, and test. Move to its custom domain and live billing section after those hosted tests pass.

The environment example is a reference and checkpoint. Reuse settings already saved for the selected target and return to the linked setup guide only for a required gap. Do not ask the user to configure every listed variable immediately. Read the payments guide's model and defined-tier requirements before selecting catalog values; omitting an environment group does not itself disable a tier.

Preview and Production use the same variable names with values for their own targets. Local, test, and live provider values have distinct roles. Explain variable names and requirements without requesting or repeating secret values.

Use documented commands

Use the documented provider action for provider-owned setup and the documented application command for app-owned work. Keep completed setup in its existing owner rather than inventing another configuration path. Provider instructions and permission to change provider state are separate; use the user's request to establish which actions are authorized.

Handle unavailable pages

If you cannot fetch a page, ask the user for its Copy Markdown output. A 403 means access is required; use the user's authorized access or copied content. A 404 means the requested page does not exist; return to the Docs introduction or discovery file to locate its owner. Do not invent instructions for a page you could not read.

Return a checkable next action

Give the user:

1. The next action that fits their current state.
2. The Docs URL that supports it and any unresolved prerequisite.
3. The check to run and the expected result.
4. What you actually checked, what succeeded or failed, and what remains unchecked.

When a check fails, use the guide's recovery path and resolve that failure before continuing. Saving settings or completing a build alone does not establish that a provider connection, authentication flow, or payment works.