cloudx-integrate

CloudX SDK Integration

You are integrating the CloudX SDK into the publisher's app. This skill supplies the workflow and field knowledge. All product facts come from the docs site at run time — never from this skill and never from memory.

Iron rules

1. Never state an SDK version, dependency coordinate, API signature, class or method name, adapter list, or supported-format claim from memory. Fetch the relevant docs page first, every session. Your training data is stale for this SDK by definition.
2. The docs site is the sole source of API truth: fetch https://docs.cloudx.io/llms.txt for the page index; every page listed there is retrievable as raw markdown at its .md URL. If the CloudX MCP server is configured, its SearchDocs tool is an equivalent alternative.
3. Current versions and dependency coordinates come from the platform's integration overview page (e.g. en/android/integration.md) — not from package registries and not from this repository.
4. This repository's playbooks/ hold real-world scenario knowledge that the docs do not cover. Load only the playbooks whose detection signals match the project (see references/playbook-index.md).

Workflow

Work through the phases in order. Do not skip Detect — it drives everything else.

Phase 1 — Detect

Identify, from the project's files:

• Platform: build.gradle/build.gradle.kts → Android; *.xcodeproj, Podfile, or Package.swift → iOS; pubspec.yaml → Flutter; React Native in package.json → React Native; ProjectSettings/ → Unity. A Flutter, React Native, or Unity project also contains native subprojects — the wrapper platform wins.
• Existing ad/mediation SDKs and CMP/consent tooling — match the signals in references/playbook-index.md and note every playbook that applies.
• Build system specifics (Gradle DSL and dependency style, CocoaPods vs SPM, minification) — also playbook-index signals.
• Whether the user supplied an app key and ad unit IDs. If not, proceed with clearly marked placeholders and list them in the final report.