feat: add game-web-portal skill

[apyanzin-xsolla]

Adds an agentic onboarding skill for a PC/Steam Game Web Portal: the agent creates or resumes a verified portal and returns an evidence-backed partner handoff.

Additive only — two new files, no existing file modified.

skills/game-web-portal/SKILL.md                          126 lines
skills/game-web-portal/references/agentic-onboarding.md   185 lines

What the skill does

Covers the Home, News, Rewards, Web Shop, Community, and optional Launcher sections, plus catalog, Login, theme, localization, preview, and publication readiness. PC and Steam only — App Store and Google Play return needs_input.

The run is a state flow, with an existing-vs-desired-state check before every mutation and a read-back after:

Intake → Preflight → Discover → Draft → Verify → Human review →
Publish → Live verification → Handoff

The governing rule is that nothing is reported as completed until its effect is verified. Statuses are completed, placeholder, needs_input, needs_access, needs_human, blocked_capability, failed. Honest partial completion is the intended outcome; a clean-looking unverified report is treated as failure.

It delegates rather than duplicating recipes — merchant-setup for merchant/project/API key, shop-setup for pages, blocks, theme, localization and preview, catalog-design for catalog and pricing, login-setup for Login, headless-checkout-integration for checkout. Use shop-setup for a general zero-to-shop storefront; this is the PC/Steam portal path.

Conforms to CONTRIBUTING-skills.md

• One skill per directory, SKILL.md at its root
• 126 lines, under the 200-line limit; the specification lives in references/
• description: >- block, pushy, covering every trigger scenario and the out-of-scope case
• metadata: with owner: apyanzin-xsolla and domain: orchestrator (following shop-setup, the existing orchestrator)
• All four required sections: When to use, Prerequisites, Steps, Common pitfalls
• No curl and no raw HTTP — the flow describes intent and delegates

Agent test

Prompt:

Use Xsolla CLI to set up my PC Game Portal.

plus a Steam store URL, merchant ID, project ID, domain, and primary locale.

Result: 12/12 hard-case runs passed with this skill loaded, versus 6/12 with no context. Judge confidence 100%, first-try success 100%, pass@3 100%, zero safety errors. Mean token usage 1.41× the official-docs baseline against a ≤1.5× target. Evaluated across four hard PC onboarding scenarios, three variants, three repetitions each — 36 runs.

A live smoke check against an existing portal passed website discovery, structure read, preview enablement, and preview-link generation. Two failures were tooling-side rather than spec-side, and are worth a maintainer's eye:

• the public preview URL returned HTTP 403
• verify-website returned HTTP 400 because the request omits the required draftPagesIds

Note for reviewers

skills/README.md and the AGENTS.md skill inventory are deliberately untouched, so this PR stays purely additive. Both list every skill, so a maintainer may want a row added for game-web-portal — happy to include it here or leave it to a follow-up, whichever you prefer.

Source, including the specification and the eval harness: https://github.com/apyanzin-xsolla/game-web-portal

[JavadManashti]

Thanks for this, Andrey — went through it in detail.

Genuinely the most rigorous spec in the kit so far. The state flow, the evidence contract, and "nothing is completed until its effect is verified / simulated completion is failure" is the discipline I want across all our skills, not just this one. I'd like to lift that pattern into CONTRIBUTING-skills.md once this lands.

One blocker before merge:

The delegation targets don't exist yet. The skill routes "pages, blocks, theme, localization, preview" to shop-setup — but shop-setup has no Site Builder coverage at all (grepped for sitebuilder/site builder/portal/shop builder — zero hits). Nothing in the kit does; webhooks-impl even scopes itself explicitly to "headless web shop, without Site Builder." So Step 4 (Draft), where all the actual portal work happens, dead-ends for the agent.

Two ways forward, your call:

1. Bring the portal/Site Builder API calls into references/ so the skill is self-sufficient, or
2. Mark those operations blocked_capability and ship the governance layer now, wire up the APIs in a follow-up.

I'd lean toward (1) — the two failures you reported (preview 403, verify-website 400 on missing draftPagesIds) show you already have the real API knowledge, it just didn't make it into the skill. Right now the skill names no endpoints anywhere — SKILL.md or references — while the other skills put the concrete API calls in one or the other.

Small stuff, all quick:

• Please add the registry rows in this PR rather than a follow-up — a row in skills/README.md, plus the table row + trigger block in AGENTS.md. Without them the skill is invisible in the inventory.
• Add status: draft to the frontmatter to match the other draft skills.
• Owner format: you used the GitHub handle per CONTRIBUTING-skills.md, but repo convention is firstname.lastname style (see other skills' metadata.owner). The guide and the repo disagree here — I'll fix the guide, just flagging it so it's not a surprise.
• domain: orchestrator puts you next to shop-setup with overlapping trigger words (Web Shop, catalog, Login, checkout). I'll add a routing line to shop-setup pointing the other way so agents don't load both.

Nice work on the eval harness too — 12/12 vs 6/12 baseline over 36 runs is the kind of evidence I want on every skill PR. Ping me once the delegation question is sorted and I'll merge.

[aspringut-xsolla]

@apyanzin-xsolla really cool. Do you have an example of a portal that was set up with this skill?

[JavadManashti]

Closing in favor of #29, which supersedes this with the delegation blocker fixed (portal-api.md now documents the Shop Builder API directly instead of routing to non-existent shop-setup coverage).