Commands
Commands are shortcuts typed into the chat. Instead of describing the whole job, the user types a slash and a name, and the agent starts the matching piece of work.
They only exist in Claude Code. Describing the same thing in plain words works just as well - the commands are a convenience, not a requirement.
Each step of the process has its own command. That way the app can be rebuilt without also launching it and running a payment, and when something fails, the name of the command says which step it was.
Adding the MCP server does not add the commands. They are files written into the
project (.claude/commands/), and Claude Code only reads them when a session starts.
There are two ways to get them:
- Before the first session - run the bootstrap command
(
nuvei-mcp-builder-init, see Setup). The commands are there as soon as Claude Code opens. - During a session - the agent installs them with the
install_skillstool. They do not work in that session. Restart Claude Code to use them.
In the future, the commands will be distributed through a Claude Code plugin.
Installing the plugin from inside Claude Code (/plugin install) will be enough to
get them, with no bootstrap step and no restart. Plugin commands carry the plugin's
name as a prefix, so /design-app would become /<plugin-name>:design-app.
Start
/design-app
Starts the whole thing, or picks it up where it left off.
It looks at the project folder first and decides what kind of job this is: building a new app, or adding payments to the app that is already there. Then it asks about whatever is still undecided, saves the answers, and builds the app around the payment code. After that it hands over to the commands below for the backend, the build, the launch and the payment test.
If the builder has run on this project before, it reads back what was already decided instead of asking everything a second time. If the app already takes payments with Nuvei, this is the wrong place to start - the module commands further down are for changing it.
/setup-backend
Decides how the backend is handled, and gets it running.
There are three options: the builder writes and runs an example backend, the app connects to a backend the user already has, or the backend is left for later. For the example backend it also checks that the account details are stored, and asks to open the setup terminal if they are not. The secret key always stays on the backend.
/credentials
Opens the setup terminal again, to correct account details that were entered wrong.
The details are typed into a separate terminal window and stored in the operating system's keychain. The agent never sees them. This only applies when the builder runs its own example backend.
Build, launch, test
/build
Builds the app, and nothing else.
It checks the tools needed to compile, installs whatever is missing, and builds. If the build finds an account detail written into a file, it stops and says where - the user removes it, not the agent.
/launch-emulator
Starts the app on an Android emulator.
If no emulator is running it starts one, and if none exists it creates one. Creating
one downloads a system image, which takes a while. It does not build - run /build
first if the code has changed.
/launch-device
Starts the app on a real phone connected over USB.
If no phone is connected, it explains how: turn on developer options and USB debugging, connect the cable, and accept the prompt on the phone. It also points the app at the backend so the phone can reach it. Google Pay can only be tested this way - the emulator has no Play Store.
/test-payment
Runs a real test payment through the app.
It first works out, from the app's code, how to get to the payment screen. Then the tool drives the app there and types a test card itself - the agent never handles a card number. A payment declined by Nuvei still counts as a pass: it proves the whole connection works. Only a checkout that never appears, or a crash, is a failure.
/build-and-verify
Runs the four steps above in order - backend, build, launch, payment test - and stops at the first one that fails.
Use the single commands when only one step needs to run again. Use
/build-and-verify to check everything after a change.
Change an app that already takes payments
These four change which Nuvei payment methods the app uses. Each one takes the name
of a module, for example /add-module google-pay.
| Module | Platforms |
|---|---|
simply-connect | Android and iOS |
fields | Android and iOS |
google-pay | Android |
apple-pay | iOS |
After any of them, the app's own screens may need updating, the app needs to be rebuilt, and the route to the payment screen is worked out again before the next payment test.
/add-module <module>
Adds a payment method that is not in the app yet. Only the new method's files are written - everything already there, including changes made by hand, stays as it is.
/remove-module <module>
Removes a payment method. Only its own files are deleted; anything the remaining methods still use is kept. Removing the last one removes all Nuvei code from the app, so the agent asks first.
/replace-module <module>
Switches the app to that one payment method. It adds it if needed and removes all the others in one step. The agent names what will be removed and asks first.
/refresh-module <module>
Writes one payment method's code again from scratch, for example after the builder was updated. Any changes made by hand to that code are lost, so the agent asks first.