feat(levelplay): align with the plugin copy and add the install gate

[ziyiunity]

Restructures this skill so SKILL.md is the workflow spine and detail lives in references/, and adds a hard install-verification gate. Net size is about even: +1457 -1413.

The restructure

SKILL.md goes from about 1,100 lines to 435. The dependency-resolution, testing-and-validation and troubleshooting material that was inlined in it moves into references/, which grows from nine files to twelve.

Nothing is dropped. Every section that was inline is still present, in a file linked from the step that needs it. That was checked heading by heading rather than assumed.

The reason to prefer this shape is mechanical. SKILL.md is loaded in full every time the skill fires; a reference file is read only when the agent reaches the step that links it. Moving 660 lines of detail out of the always-loaded part is a straight saving on every invocation that does not need it, and most invocations do not: someone adding a rewarded ad has no use for the Maven Central failure path.

CONTRIBUTING.md already asks for this: "Keep SKILL.md focused on instructions and move long reference material into separate files it links to."

The install gate, which is the substantive addition

Step 3 now refuses to write any LevelPlay code until com.unity.services.levelplay is confirmed present in Packages/packages-lock.json, read from the project rather than taken from the Package Manager window, an earlier turn, or the user's recollection.

The failure it prevents is specific. The package is easy to believe is installed: the Package Manager display name is Ads Mediation while the id recorded in project files is com.unity.services.levelplay, there are two similarly named packages that are the wrong ones, and the install prompts for a second package partway through. Code written before the id resolves looks entirely correct and fails with CS0246 on every LevelPlay symbol, which reads as a code problem rather than an install problem, so the next move is usually to rewrite working code.

The gate also separates two states that look the same and need different fixes. An id absent from manifest.json means the install never happened. An id in manifest.json but not in packages-lock.json means Unity has not resolved it yet, so the Editor may still be importing or resolution failed. Both files are plain JSON in the project, so the check needs no Editor, no CLI, and nothing from the user.

One correctness change in the privacy reference

SetGDPRConsents(Dictionary) is no longer listed as a deprecated API. It is the correct GDPR call on SDK 9.4.x and only becomes [Obsolete] on 9.5.0+, where SetGDPRConsent(bool) replaces it. It now sits outside the deprecated list with an explicit note not to treat the per-network dictionary as deprecated on 9.4.x.

Listing an API under a "Deprecated" heading and then adding "but it is correct on 9.4.x" is the shape that gets read backwards. Keeping it out of the list removes the possibility. This is consent-management code, so a wrong reading is a compliance problem rather than a broken build.

Kept as they were

CHANGELOG.md gains a v0.10.0 entry. README.md keeps its content; only the file tree changed, and note it had already gone stale before this change, since it never listed migration-sdk-9.md from v0.9.0.

references/migration-sdk-9.md is untouched.

Checked

• All twelve references/*.md mentioned in the body exist, and every file present is reachable from the body. No orphans in either direction.
• Frontmatter convention preserved: name: is declared and matches the folder, as in all 22 skills here.
• Nothing previously in this copy was lost. Verified by reading rather than by comparing lines: the threading notes, the explicit-load semantics and the deprecated-API guidance are all present, several in stronger form, and in one case as a code comment rather than a prose paragraph, which a line-level comparison reports as missing when it is not.

[kimberleymday]

Verified on my side: migration-sdk-9.md is byte-identical to what shipped in v0.9.0, Step 0 and its compile-check behavior survived the restructure, and our 5-scenario migration eval suite passes against this branch apart from the gate finding noted inline. Two changes requested: the description sentence and the gate edge case.

[kimberleymday]

This description comes from the muse-skills repo copy, which never got the migration trigger sentence (we deferred description changes there). But the Unity Skills repo copy shipped it in v0.9.0, and activation on migration-phrased prompts depends on it: "Also use when upgrading the LevelPlay or IronSource SDK version, migrating from deprecated IronSource.Agent APIs, or migrating a game from Unity Ads to LevelPlay." Is it possible to append it here, and I can follow up with the same one-line addition to the muse-skills repo description so future propagation carries it (or propose it as an additional change for PR #146)? It fits the 1024-char limit in both.

[ziyiunity]

Fixed. This happened because the agent has a mistake when reading diff..

[kimberleymday]

I ran our migration eval suite against this branch. One finding on this gate: in a run where the agent had added the package id to manifest.json itself and had no Editor available, the "must appear in packages-lock.json before any code" requirement pushed the agent to write the levelplay entry into packages-lock.json itself to satisfy the gate: exactly the hand-edit the migration guide forbids, and a false "resolved" signal. Could the gate get an explicit branch for that case? Something like: "If you added the id to manifest.json yourself and no Editor has run since, the lock will not show it yet. That is expected, not a failure. Never write the entry into packages-lock.json yourself; ask the user to open the Unity Editor so resolution runs, then re-read the file."

[ziyiunity]

Added, using your wording plus one extra sentence at the end. The extra bit is the last sentence. Your version tells it what to do instead, which covers the case where an Editor exists. If there's no Editor at all, it still has a hard requirement and no legal way to satisfy it, which is the situation that produced the hand-edit in the first place. So it now has an explicit permitted place to stop.