How it was built with skills

The whole education showcase was built by an AI coding agent guided by the skills published on this marketplace. No SDK was hand-studied and no API reference was read by a human: for each integration step the agent loaded the matching skill, followed its contract, and validated against its done-criteria. This page maps every step to the skill that carried it, with the kind of prompt an integrator gives.

Before you start

Two things gate the whole build and are easy to skip. Plan for both from the start; the build works against a real Wallet only when both are done.

• API keys. One OWS API key per sandbox organisation: the Ministry of Education (issuer and the sign-in and payment verifier) and the employer, CivicWorks (the qualification verifier). Each key stays on the server, in an environment variable or a secret manager; the browser never sees it. Step 2 creates the keys. The consent service (Step 9) runs on a third, main-tenant key, not a sandbox key.
• Trust list registrations. One x509 certificate per definition, registered on the trust list, so the Wallet trusts the credentials and the requests. The issuer certificates (Student ID, diploma) go on the NXD Pub-EAA list; the verifier certificates (sign-in, payment, employer) go on the NXD WRPAC list. Until a certificate answers granted, the Wallet shows an untrusted service provider warning. Step 3 covers this.

You also need:

• A tenant account on the iGrant.io Organisation Wallet Suite (OWS) with the ability to create sandbox organisations. Environment: demo (https://demo-api.igrant.io).
• An AI coding agent and a model.
• The iGrant.io Data Wallet on a phone, with a PID and a payment credential from the two demo issuers.
• A clean working directory.

Setting up

Install the skills into your coding agent straight from the source repository:

npx skills add l3-igrant/skills

To pick exactly the skills this showcase uses, open the skills repository, filter by the education category, select all, and copy the one install command it builds.

Then describe the product you want. The agent picks the right skill per task; your job is to make decisions when the skill's intake asks for them (environment, tenancy, where the backend runs) and to test with a real Wallet on a phone. The showcase, with its three portals, registry, issuance, payment, verification, revocation and consent, was built this way in a single working session, for example:

Build a National Learner Registry and Education Wallet showcase: a learner registers with a PID from their Wallet, receives a Student ID and a diploma as verifiable credentials, pays the diploma fee with a payment credential, and applies for a job with selective disclosure. Separate, real-world-looking portals under one domain. Next.js, browser-local demo state, no low-code machinery.

Step 1: orientation

igrantio-ows-overview is the map: the issuer and verifier architecture, the glossary, and an integrator intake that settles the environment, the API key, tenancy and webhook reachability one question at a time before any code is written. Load it first; every other skill assumes its vocabulary.

Step 2: one organisation per role

The registry (issuer) and the employer (verifier) must be separate organisations so the Wallet shows two genuinely different parties. igrantio-api-sandboxes created the two organisations with their own names and logos, and igrantio-api-api-keys issued a scoped API key bound to each, so every later call lands in the right organisation without extra headers.

Create appropriate sandbox organisations for the Ministry of Education and the employer, with logos, and bind a separate API key to each.

Step 3: keys, certificates, trust

A Wallet warns about an untrusted service provider unless the requesting party's certificate is on a trust list. igrantio-api-key-management covered creating the signing keys, generating a certificate signing request per key, and uploading the signed chains; igrantio-trustlist-entries covered registering each certificate on the trust list as an OAuth2 client; and igrantio-api-trust-anchorexplained how the issuer and verifier side consume those registrations. The showcase uses five signing keys and certificates, one per role: Student ID issuance, diploma issuance, sign-in verification, payment verification (shared by the account and card payment definitions), and the employer's check.

I am getting an untrusted service provider warning in the Wallet. Make sure every credential and presentation definition uses x509, use separate certificates for all definitions, and register them all on the trust list.

Step 4: credential schemas

The claim sets came from the schema skills rather than guesswork: igrantio-credential-schema-student-id supplied the sixteen-claim student identity set the registry issues, igrantio-credential-schema-diploma the nine-claim diploma a graduate later shares with an employer, igrantio-credential-schema-pid described the person identification credential the sign-in relies on, and igrantio-credential-schema-sca-payment-account (with its card counterpart) described the payment credentials the fee confirmation accepts. The exact resulting definitions are on the credentials and presentations page.

Create the credential definitions with the exact claim fields but fresh, unique labels so nothing existing breaks: a sixteen-claim Student ID and a nine-claim diploma. Turn on revocation, and enable the interactive authorisation endpoint on the diploma so it can be issued during the payment.

Step 5: presentation queries

Each verification is a DCQL query naming exactly the fields it needs, nothing more. igrantio-dcql-query-pid shaped the five-field sign-in request, igrantio-dcql-query-sca-payment-account (with its card counterpart) the payment presentations, and igrantio-dcql-query-diplomathe employer's combined qualification check: three identity fields from the PID plus five diploma fields in one request.

The employer must request only the qualification fields it needs: name, qualification, awarding institution, qualification code and award date. Nothing else.

Step 6: issuing credentials

igrantio-issuer-backend is the issuance contract: create the credential definition, start an issuance, correlate on the exchange identifier, and render the offer. The Student ID uses the pre-authorised code flow with a one-time transaction code shown under the QR, exactly as the skill documents it.

The Student ID issuance should use the pre-authorised code flow with a one-time user PIN.

Step 7: verifying, and paying inside an issuance

igrantio-verifier-backend covered ordinary verifications and the two special shapes the showcase leans on: transaction data, which binds the payment presentation to a signed amount and payee the Wallet displays before consent, and the dynamic credential request, where the diploma issuance embeds the payment presentation so one scan pays the fee and delivers the credential in the same Wallet session.

When the learner chooses pay by account or pay by card, make it a dynamic credential request: the Wallet presents the payment credential with the transaction data and the diploma is issued automatically in the same session.

Step 8: showing it live

OWS makes exactly one webhook delivery attempt with no retry, so the showcase runs no webhook receiver at all: it polls the OWS exchange record, which is the more robust channel. The browser polls a small status route every three seconds; that route reads the credential or verification history straight from OWS and returns the update in the webhook topic vocabulary, so the client reads one language. The QR flips to a progress state the moment the phone scans, with no relay storage and no signed callback to secure. igrantio-qr-code set the QR conventions: requests by reference, the right sizing and error correction, and a logo in the centre. For a production deployment with a public HTTPS endpoint, igrantio-backend-webhooks adds a verified webhook receiver (timestamped HMAC compared in constant time) and igrantio-backend-sse streams the stored events to the browser.

Make all the QR codes by-reference ones. Do not stand up a webhook receiver; poll the OWS exchange record every few seconds and update the screen the moment the Wallet acts.

Step 9: consent and the individual

igrantio-individuals established the pattern for onboarding each learner as an individual in the consent service, keyed to the local user so the mapping is recoverable. igrantio-consent-recordscovered recording an opt-in or opt-out against each data agreement, reading the live state (the school review shows it), and the delete-all call behind the learner's Delete my account. The resulting agreements are on the data agreements page.

Create an individual in the consent service for each student and record consent against the data agreements. If the student opts out of analytics in the education portal, the school must see it immediately.

What the integrator actually does

• Decide, do not implement. The prompts above are decisions and acceptance criteria, not instructions on how to call an API. The skills carry the how.
• One skill per step. Load the overview first, then exactly the skill for the integration at hand. Each skill ends with done-criteria; hold the agent to them.
• Keep secrets server-side. Every skill assumes API keys live only in the backend environment; the browser talks to your own endpoints. The showcase enforces this with server-only modules, so a leaked key is a build error rather than an incident.
• Make provisioning idempotent. Definitions and trust entries are created by a script that searches by label first and can run twice without duplicating anything.
• Test with a real Wallet early. The trust warnings a Wallet shows are the fastest way to find a missing certificate registration, and only a real presentation exercises selective disclosure and revocation. The phone finds what curl cannot.
• When behaviour surprises you, reread the skill. Almost every error in the build (a rejected transaction data shape, a missing interactive-authorisation flag, a header ignored under API-key authentication) was answered by a line already present in the loaded skill.

Per-portal build prompts

These are the full, copy-and-paste prompts to rebuild each portal end to end. Give the shared foundation once (it provisions the definitions, keys and trust), then one portal prompt per build. The fields match the live showcase exactly, with fresh (rebuild) labels so nothing deployed breaks. Copy a prompt and hand it to your coding agent, or open the raw file to keep it under version control.