--- name: cloudx-integrate description: Integrate the CloudX SDK into a publisher app on any supported platform (Android, iOS, React Native, Flutter, Unity). Use when asked to integrate, add, install, or set up CloudX, CloudX ads, or CloudX mediation in an app, including alongside or replacing an existing mediation stack such as AppLovin MAX, LevelPlay, or AdMob. --- # 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. ### Phase 2 — Plan 1. Fetch `https://docs.cloudx.io/llms.txt`. 2. Establish the adapter set. The correct list is **the networks enabled for this app in the publisher's CloudX dashboard configuration** — adapters are activated by the server-provisioned config at runtime, so an adapter for a network that isn't enabled server-side is dead weight, and an enabled network with no adapter in the binary silently contributes nothing. Ask the publisher which networks are enabled (or read their config via the CloudX MCP/CLI `config/show` if they have it set up). Never guess and never default to "all". 3. Fetch the platform's integration overview page, the pages for each ad format the user wants (default: ask, or start with the formats the app already shows), and the adapter overview page for every network in the adapter set. `references/doc-map.md` explains which page stems answer which questions. 4. Read the playbooks selected in Detect. 5. Present a short plan: dependencies to add, files to create/modify, formats to implement, playbook considerations. Confirm with the user if anything is ambiguous (formats, networks, coexistence vs replacement intent). ### Phase 3 — Integrate Implement from the fetched docs pages only: - Add repositories/dependencies exactly as the integration overview specifies. - Apply each enabled adapter's overview page **in full** — beyond the dependency line, adapter pages can require additional Maven repositories, manifest/Info.plist entries, an SDK-track choice, or native asset/view requirements. Skipping these is a build or runtime failure, not an optional extra. - Initialize the SDK where the docs say to, with the app key. - Implement each ad format per its docs page, including listeners and lifecycle (destroy/cleanup) requirements. Match the page's object lifecycle exactly — if it reuses one instance and calls `load()` again for the next ad, do not create a fresh ad object per cycle (that leaks the old instance). - Apply every selected playbook's guidance (init ordering relative to a CMP, coexistence wiring, build-system adjustments). - Match the project's existing code style and language (Kotlin vs Java, Swift vs Objective-C). ### Phase 4 — Build-verify Run the project's own build (Gradle assemble, Xcode build, `flutter build`, etc.). Fix compile errors by re-reading the fetched docs pages — a signature mismatch means you mis-read or the docs page moved, never a reason to guess. Repeat until the build passes. If the build cannot be run in this environment, say so explicitly in the report instead of claiming verification. ### Phase 5 — Audit Before reporting, verify against the code you just wrote (and re-fetch docs pages if uncertain): - Init happens once, in the documented location, before any ad load. - Every created ad object has its documented lifecycle handled, and reload paths reuse instances the way the docs page shows — flag any per-cycle object creation the page doesn't. - Load/show error callbacks are handled; fullscreen ads check readiness before showing. - Every installed adapter's docs-page requirements are fully met (extra repositories, manifest/Info.plist entries, native view requirements), and the adapter set matches the networks enabled in the publisher's dashboard config. - If the app has an existing mediation stack: its code paths are untouched and still reachable (coexistence), or fully removed (migration) — per the intent established in Detect. - Privacy: a CMP writes IAB consent strings before ads load, per the docs privacy guidance and the `consent-and-cmp` playbook if selected. - No placeholder credentials silently left behind — every placeholder is listed in the report. ### Phase 6 — Report Summarize: files changed (with paths), formats implemented, networks/adapters enabled, playbooks applied, build result, and required follow-ups (replace placeholder app key / ad unit IDs, register the app's bundle ID in the CloudX dashboard, CMP configuration). Link the docs pages you used. ## Auditing an existing integration For "check / audit my existing CloudX integration" without new integration work, use the `cloudx-audit` skill instead (Detect + Audit phases only).