Yes2SDK

View saved version →

---
name: yes2sdk-diagnose
description: Diagnoses a Yes2SDK symptom or compliance failure. Use when ads will not show, audio stays dead after an ad, a reward is not granted, a loading screen never dismisses, a verify run FAILs on a rule id, or a platform may not support a module.
---

# Diagnosing a Yes2SDK integration

Four questions, four tools. Pick by the question actually being asked rather than
running all four.

| The question | Route to |
| --- | --- |
| "it does not work", an error or a symptom | `yes2sdk:troubleshoot` |
| "why did this check fail", a rule id in hand | `yes2sdk:get_compliance_rule` |
| "does this platform support X" | `yes2sdk:get_platform_capabilities` |
| "what modules exist", an unfamiliar module name | `yes2sdk:list_sdk_modules` |

## Drilling into a verify failure

A `$yes2sdk-verify` run reports findings with a rule id and a short fix hint. The
hint is a summary; the rule is the thing the platform rejects on.

1. Take the rule id off the finding.
2. `yes2sdk:get_compliance_rule` with that id returns the full rule text, severity,
   and why the platform enforces it.
3. If the finding is a symptom rather than a rule violation (audio dead after an
   ad, loading screen never dismissing, rewards not granting), go to
   `yes2sdk:troubleshoot` instead. Those have known causes that the static rule
   text does not explain.
4. Re-run `$yes2sdk-verify` for that platform after the fix. Do not mark a FAIL
   resolved on reasoning alone.

## Before blaming the code

Check the feature exists on that platform. `yes2sdk:get_platform_capabilities`
answers it. An `isSupported()` guard returning false is the SDK working correctly,
not a bug. The fix is to handle the unsupported path, not to force the call.

## Reference

`references/tool-routing.md` covers all 11 `yes2sdk` MCP tools: which question each
answers, its preconditions, and the failure modes observed in practice. Read it
when a tool returns nothing useful or rejects its arguments.

## Never answer from memory

Rule text, limits and capability matrices change server-side. Fetch them. This
skill carries routing knowledge only; the server is the single source of truth
for what any rule says.

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: yes2sdk-docs
description: Searches the Yes2SDK documentation. Use for an open-ended Yes2SDK docs question when no more specific skill fits.
---

# Searching the Yes2SDK docs

1. Call `yes2sdk:search_docs` with the user's query.
2. Present the top matches: for each, the doc slug, the heading, and a one-line
   excerpt.
3. If a result looks like the full answer, offer to pull it with
   `yes2sdk:get_quickstart` (a platform guide) or `yes2sdk:get_api_reference` (a
   module's method signatures).

A concrete error message or symptom is better answered by the `$yes2sdk-diagnose`
skill than by keyword search.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: yes2sdk-install
description: Adds Yes2SDK to a Unity, Defold or JS project and confirms it resolves. Use before writing Yes2SDK code, when setting up or onboarding a project, or when a Yes2SDK reference will not compile.
---

# Installing Yes2SDK

Install comes before code on Unity and Defold. `Yes2SDK` (Unity) and the `yes2sdk`
module (Defold) do not resolve until the package is added, so code written first
does not compile and the failure reads as a coding error. JS is different, see the
first precondition.

## Routing order

1. `yes2sdk:detect_sdk` reports the engine and the install state. This replaces
   asking the user which engine they are on, and replaces guessing from the file
   tree.
2. `yes2sdk:get_install_instructions` for that engine, when an install is still
   required. The steps it returns are version-pinned; use them as returned rather
   than a remembered install procedure.

## Preconditions

- **`installed: no` is a blocker on Unity and Defold only.** On a JS project it is
  the expected and permanent state: there is no dev-time package, because the web
  runtime is injected into the build by the dashboard at upload time. Blocking there
  blocks every JS project forever. Read the report, not just that line.
- `yes2sdk:detect_sdk` takes exactly one of two input modes, and the wrong one is
  the most common way this fails. This plugin registers the **hosted** server, which
  has no disk access. Read the engine-marker files locally and pass them inline as
  `files` (repo-relative path to contents). `projectPath` there returns an error
  result, not a thin answer; pass it only when the user runs the server on their own
  machine.
- **Unity needs two markers, not one:** `Packages/manifest.json` *and* a
  `ProjectSettings/` file (`ProjectSettings/ProjectVersion.txt` will do). With only
  one, detection returns `Engine: unknown` and every downstream step is wrong.
  Defold needs `game.project`; JS needs `package.json`.
- Read those markers from the project ROOT. Detection keys off root-level files;
  markers picked up from a subfolder identify the wrong engine or none.
- The engine passed to `yes2sdk:get_install_instructions` comes from
  `yes2sdk:detect_sdk`. Do not pass an engine the user merely mentioned in passing.
- Yes2SDK targets HTML5/WebGL only. On a non-web target the modules are no-op
  stubs, so an install that looks fine still produces no platform behaviour.

## Failure modes worth naming

- Detection reporting an engine but no install is the normal state on a fresh Unity
  or Defold project. Treat it as the install path, not an error.
- A project that already has a platform SDK (Poki, CrazyGames, and so on) wired
  directly is not "already integrated". Yes2SDK replaces those direct calls, and
  leaving both wired double-fires ad and lifecycle events.
- After installing, re-run `yes2sdk:detect_sdk` before generating code. An install
  that needs an editor step (Unity package import plus its WebGL template, Defold
  library fetch) is not complete when the manifest edit lands.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: yes2sdk-integrate
description: Scaffolds a Yes2SDK integration into the current project. Detects the engine, checks the install, then writes the init and ad loop with isSupported() guards.
---

# Scaffolding a Yes2SDK integration

Yes2SDK is one unified API that runs on every supported platform (poki,
crazygames, yandex, gamedistribution, youtube). Write the integration once and guard
platform-specific features with `isSupported()` so unsupported features no-op
instead of breaking.

Target platform: the one the user named. Default to `poki` when none was named.

## Steps

1. Establish the engine and the install state by following the `$yes2sdk-install`
   skill, which holds the detection procedure and its preconditions. Do not ask the
   user which engine they are on. Ask only if detection cannot determine one:
   Defold (Lua, `yes2sdk.*`), Unity (C#, `Yes2SDK.Yes2SDK.*`), or plain TS/JS
   (`Yes2SDK.*`). Use the matching naming convention in all generated code.
2. **Stop here when the engine is `unity` or `defold` and the SDK is not
   installed.** Generated code would reference a namespace or module that does not
   resolve, so it cannot compile. Surface the install steps and write NO code
   referencing `Yes2SDK`, the `yes2sdk` module or `window.Yes2SDK`. Say the install
   is the blocker and offer to continue after it.

   Do not stop on a `js` project. There `installed: no` is expected and permanent:
   the web runtime is injected into the build at upload time, and its report lists
   steps that are the build-and-upload flow, not a package to add. Generate the
   code.
3. Call `yes2sdk:get_quickstart` for the target platform.
4. Call `yes2sdk:get_api_reference` for the `ads` and `lifecycle` modules to get
   exact method signatures.
5. Generate the integration following the mandatory loop, in this order:
   - `initializeAsync()`: await it before any other SDK call.
   - `startGameAsync()`: call only when the game is loaded and interactable,
     never during a loading screen.
   - `game.gameplayStart()` when play begins.
   - `game.gameplayStop()` BEFORE showing any ad.
   - `ads.showInterstitial(...)` (or rewarded): pause/mute in `beforeAd`, restore
     in `afterAd`; for rewarded, grant the reward only in `adViewed`.
   - `game.gameplayStart()` to resume after the ad.
   - Wrap every optional-feature call (`auth`, `banners`, `friends`, and so on) in
     its `isSupported()` guard.
6. After writing the code, if the user has a built and extracted WebGL build,
   follow the `$yes2sdk-verify` skill for the target platform and report any
   FAILs and WARNs with fix hints. Otherwise say that verification runs once there
   is a build.

Do not call any platform SDK directly and do not invent SDK methods. Use only what
the quickstart and API reference document.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: yes2sdk-platform-rules
description: Cross-platform Yes2SDK rules; the yes2sdk MCP is source of truth. Use when integrating Yes2SDK or fixing compliance for Poki, CrazyGames, Yandex, GameDistribution, YouTube.
---

# Yes2SDK platform rules

Yes2SDK is one unified API across every supported platform. Write the integration
once and gate platform-specific features with `isSupported()` so unsupported
features no-op. Never call a platform SDK directly. Never invent SDK methods.

## Highest-leverage rules (apply everywhere)

1. `await initializeAsync()` before any other SDK call. Call `startGameAsync()`
   only when the game is loaded and interactable, never during loading.
2. Call `game.gameplayStop()` BEFORE every interstitial; `game.gameplayStart()` to
   resume after.
3. Pause/mute in `beforeAd`, restore in `afterAd`. Grant rewarded-ad rewards in
   `adViewed` only, never `afterAd` (it fires even on dismissal).
4. No external `<script src="http...">`. All platforms sandbox or strip them.
5. Guard optional modules (`auth`, `banners`, `friends`) with `isSupported()`.

## This is a summary, not the source of truth

Per-platform rules diverge (Poki's 30s/60s ad timing, CrazyGames' 3-minute floor
and wrapper options, Yandex pause/resume and locale, GameDistribution's `gameId` and
event flow, YouTube's cert-mandatory pause/audio handling). These change. Do not
rely on this list for compliance decisions.

For the authoritative, current rule set, call the **yes2sdk MCP**:

- `yes2sdk:get_platform_requirements` (platform) returns the full rule list with
  severities.
- `yes2sdk:validate_integration` (platform, plus the build inline and/or an
  Inspector `eventLogJson`) runs the actual checks and surfaces FAILs. The
  `$yes2sdk-verify` skill holds the calling procedure; use it rather than guessing
  which build parameters the connected server can read.
- `yes2sdk:get_quickstart` (platform) and `yes2sdk:get_api_reference` (module) give
  exact call sequences and method signatures.

When in doubt, fetch from the MCP rather than guessing.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: yes2sdk-verify
description: Validates a Yes2SDK WebGL build against one platform or all of them (Poki, CrazyGames, Yandex, GameDistribution, YouTube). Use before an upload, or when asked whether a build would be rejected.
---

# Verifying a Yes2SDK build

This is the single source of the verify procedure. Single-platform checks,
all-platform sweeps and the check at the end of `$yes2sdk-integrate` all run it.
Edit the procedure here, not in the skills that call it.

## Inputs

- **Platform**: one of `poki`, `crazygames`, `yandex`, `gamedistribution`,
  `youtube`, or `all`. Take it from the request ("verify for Poki", "check every
  platform"). When the request names none, use `all`.
- **Build**: the user's **extracted** WebGL build folder. If the request gives no
  path, ask once, then reuse the same build for every platform in this run.
- **Event log** (optional): an exported Inspector event log.

## Procedure

1. Read the build once. The plugin registers the **hosted** server, and it has no
   disk access, so `buildPath` there comes back as a blocking `build-path` FAIL.
   Read the build locally and pass it inline as `indexHtml`, `fileList` and
   `jsContents`. `jsContents` is what makes the Yes2SDK-bundling check possible;
   without it that check cannot run. Pass `buildPath` only when the user has the
   server running on their own machine.
2. An Inspector event log may be passed as `eventLogJson`, in addition to or
   instead of the build. The static checks need the build; the behavioral rules
   (gameplayStop before ads, reward only on `adViewed`, no ads in the first 30s)
   exist only in the event log and cannot be derived from files. With only one of
   the two, state plainly which checks did not run.
3. Call `yes2sdk:validate_integration` once per platform being verified, reusing
   the same inline build.
4. For any FAIL whose fix is not obvious from its hint, call
   `yes2sdk:get_compliance_rule` with the rule id before reporting.
5. Report as below.
6. Never soften or reinterpret a FAIL, and never mark one resolved by reasoning.
   The rule set is the platform's, not this plugin's; if a finding looks wrong,
   report it as returned and say so.

## Report

**One platform:** blocking FAILs first, then WARNs, each with its rule id and the
fix hint carried on the finding.

**All platforms:** triage by cause, not by platform. One missing `gameplayStop()`
fails many platforms and is one fix, not one finding each.

1. A one-line verdict: which platforms this build can ship to as-is.
2. A table: `platform | blocking FAILs | WARNs`.
3. The fix list in this order, each with the rule id and the file it applies to
   when you can identify it:
   - **Blocks everywhere**: a FAIL that appears on 3 or more platforms. Fix first;
     it is usually a universal (`U-`) rule.
   - **Blocks one platform**: per-platform FAILs, grouped under that platform.
   - **Warnings**: after the FAILs, briefly.
4. Any checks that could not run, and why. A sweep with no event log did not run
   the behavioral rules at all, and reporting that as a clean pass is the worst
   failure this skill can have.

## What each platform usually rejects on

Use these only to explain a finding in the user's terms. They are a summary, not
the rule set; `yes2sdk:validate_integration` is authoritative.

| Platform | Usual causes of rejection |
| --- | --- |
| `poki` | `gameplayStop()` missing before an interstitial; ads in the first 30s; interstitials more often than 1/60s; ads during loading; rewards granted in `afterAd` instead of `adViewed`; external `<script src="http...">`; non-responsive canvas. |
| `crazygames` | Missing wrapper options on init; loading not reported (`setLoadingProgress` / `startGameAsync`); gameplay not bracketed with `gameplayStart()`/`gameplayStop()`; audio not muted during ads; interstitials under the 3-minute floor; an `'unfilled'`/`'adblock'` ad error treated as a dismissal. |
| `yandex` | `startGameAsync()` missing, so the loading screen never dismisses; pause/resume not handled, so audio keeps playing during ads; `gameplayStop()` missing before ads; locale not read from `session.getLocale()`. |
| `gamedistribution` | `gameId` not set before the SDK loads; mute/pause not wired to `beforeAd`/`afterAd`; rewards granted in `afterAd` instead of `adViewed`; external scripts beyond GD's own SDK. |
| `youtube` | Strictest, and the checks are cert-mandatory: `startGameAsync()` not gating `gameReady()` (called during loading); `pause` not stopping game loop, audio and network; audio state not honored (`session.isAudioEnabled()` + `audioEnabledChange`); external scripts (CSP sandbox); cloud saves over the 3 MiB cap. |

Referenced files: 1 — file references are metadata, not package contents.