Skills

Skills are the step-by-step guides the agent follows. Each one covers a single job - deciding whose backend holds the secret key, adding payments to an app that already exists, restyling the checkout screen - and says which tools that job needs and in what order.

They are written into the project as plain files (one folder per skill, each with a SKILL.md inside), and they point at the rules for anything that has to be exactly right.

install_skills copies the whole set in one go: the shared skills, plus every skill for the chosen platform. Nothing is left out because a payment method wasn't picked - the agent reads the one it needs when it needs it.

The names below are the real folder names, the ones the agent will say out loud when it tells you which skill it is following.

The main path

These run, roughly in this order, in a normal session.

Skill	What it covers
design-app	The scan-first opening move. Runs init, looks at the folder, and branches on what is there: an app with no payments yet, an app that already has them, or nothing at all. Only in the last case does it interview - app name, domain, screens, theme, and where in the app a payment happens - and save the answers with save_app_spec. It also checks the machine can build the chosen platform (iOS needs macOS) and says so before the design is saved.
resume-project	For when a design was already saved in an earlier session. No second interview: the saved design is the design. It checks what is actually on disk - skills installed, backend generated, build foundation laid - and skips whatever is already done. The backend process never survives a session, so this usually still means starting it again.
choose-backend	Decides whose server holds the merchant secret key. That the key must live server-side is fixed and never a question; who runs that server is. Three answers: scaffold (the builder generates one), existing (the user already runs one - the agent checks the URL and points the app at it), or deferred (the user will write the endpoint themselves). This decision sets the app's base URL, and it decides whether the credentials step happens at all - so it comes first.
configure-credentials	A blocking gate, and only for scaffold. It confirms the account details are already in the OS keychain, using a check that returns yes/no and never values. If they are missing it opens a real terminal window for the user to type them into. Credentials are never collected in the chat and never passed as tool arguments. For existing and deferred the builder injects nothing into anyone's service, so this skill is skipped outright - an empty keychain is correct there, not a blocker.
scaffold-backend	Generates the reference payments backend - Python/FastAPI, one endpoint, /openOrder - which builds the SHA-256 checksum and mints the session token. The secret key is read from the process environment, never written into a file. Then it starts the service with the keychain values injected. It also handles the port already being busy: say who is holding it, and either stop that one or move to the next port and re-point the app.
build-your-own-app	The empty-folder case. There is no whole-app generator - the agent writes the app. A tool lays only the build plumbing (the Gradle wrapper, the project file), because that is the part that has to be exact and was got wrong when hand-written. Everything above it is designed and written by the agent, and only then does the payment layer go in.
integrate-existing-app	The one skill that adds the Nuvei layer, used the same way for an app the user already had and for one the agent just built. It only ever adds - it never scaffolds over, or overwrites, hand-written source. It can point at the folder the session opened in, a subfolder, or an app anywhere on disk. It finishes by checking the integration is complete and coherent.
modify-integration	For an app that already has payments in it. Never a second full integration - that would rewrite every generated file and could lose a hand-edit. Instead it adds, removes, replaces or refreshes one payment method at a time, leaving the other files byte-for-byte alone. Adding something already present does nothing.
build-and-verify	Compile, launch, and confirm. What it does about the backend depends on the earlier decision: start it (scaffold), leave it to the user and don't go probing a remote service (existing), or say plainly that no payment can succeed yet (deferred). It also checks no account detail ended up in a file.

Situational

Installed with the rest, read only if the app calls for it. Skipping any of them is always fine - the SDK ships sensible defaults.

Skill	What it covers
customize-ui	Restyle the checkout sheet or the card field to match the app's own look, through the spot the generated code leaves for exactly that. Plain values - colours, corner radii, fonts - never SDK types. A good moment to offer it is right after the app's theme is designed. It carries one Android warning: "match my theme" must not turn into swapping the app-wide theme for a raw platform one, which breaks the 3-D Secure challenge screen.
customize-i18n	Change the payment screen's captions, placeholders and validation messages - a translation, or just different wording. Same customization spot as customize-ui; anything left unset keeps the SDK's own English string.
block-cards	The merchant's card-acceptance policy - "no prepaid cards", "no Amex", "nothing issued in X" - written as a plain list of rules on the generated config rather than as code. Each rule is a set of conditions that must all match for a card to be turned away. No policy means every card is accepted.

One per payment method

The agent reads the one for the method being wired. Each explains the same four things: the seam the app calls, what the generated layer does with the SDK behind it, what the method needs to work, and what to check when it misbehaves.

Skill	Platform	What it covers
simply-connect	Android, iOS	Nuvei's ready-made checkout screen. The app calls one entry point; the generated layer opens the order against the backend, hands the SDK the session token, and reports the outcome back. Covers the platform's own traps and how to restyle the sheet.
fields	Android, iOS	Card details typed on the app's own screen. The app hosts the card view the SDK provides - card number, expiry and CVV are collected inside it, so no card data ever passes through the app's code - and calls a prepare step, then a pay step.
google-pay	Android	Placing the Google Wallet button, connecting it to the payment layer, and the wallet ids and merchant setup it needs.
apple-pay	iOS	Getting the Apple Pay button from the generated layer, plus the entitlement and merchant id the app must carry before it will work at all.

📄 The rules are the reference material these skills point at - in particular the API reference, which the skills treat as the only authority on SDK signatures. Nothing is looked up on the web.