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.

Setting up

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

npx skills add l3-igrant/skills

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 a separate key and certificate for each definition: Student ID issuance, diploma issuance, sign-in verification, payment verification, 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-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.

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 the payment presentations, and igrantio-dcql-query-student-idthe education credential requests, including the employer's combined query for three identity fields plus five diploma fields.

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.

All issuances should use the pre-authorised code flow with a 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: hearing back, and showing it live

The backend learns that a Wallet scanned, presented or accepted through webhooks; igrantio-backend-webhooks supplied the signature verification (timestamped HMAC compared in constant time), the topic-to-exchange mapping, and the idempotent registration. igrantio-backend-sse then streams those stored events to the browser, so the QR flips to a progress state the moment the phone scans, with a polling fallback. igrantio-qr-code set the QR conventions: requests by reference, the right sizing and error correction, and a logo in the centre.

Make all the QR codes by-reference ones, and detect the scanning so the screen updates the moment the Wallet picks it up.

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, webhooks and trust entries are created by a script that can run twice without duplicating anything, which the webhook skill models explicitly.
Test with a real Wallet early. Webhooks need a publicly reachable HTTPS address even during development, and the trust warnings a Wallet shows are the fastest way to find a missing certificate registration. 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.