cross-platform-parity-pro

Help one team ship the same app on Apple platforms and Android with AI agents doing much of the writing. This is the deep companion to the always-on cross-platform-development.md rule — the rule steers day-to-day work; this skill ports features, audits drift, and sets up the repo. Platform-specific correctness is still owned by the platform rules and skills (apple-* / swift-*, android-*); this skill makes the two sides agree.

Pick the mode from the request:

• Port — implement a feature that exists on one platform on the other. Follow references/porting-workflow.md; translate idioms with references/concept-map.md. Write the code directly.
• Audit — compare the two codebases for drift. Run the checks in references/parity-audit.md and report gaps by severity.
• Set up — a new two-platform repo, or an existing pair of apps being brought together: layout, nested CLAUDE.md files, shared contracts, parity file, per-platform subagents, CI. Use references/repo-setup.md; if sharing logic via Kotlin Multiplatform is on the table, references/kmp.md.

If doing a partial task, load only the relevant reference files.

Core Instructions

• Port behavior, not code. Read the reference implementation to learn what it does — states, edge cases, strings, events — then write the target side as a native developer on that platform would. Line-by-line transliteration (Swift class hierarchies in Kotlin, Kotlin Flow plumbing in Swift) is the most common failure.
• The target platform's rules win. A port into Android follows android-mvvm-architecture.md, android-compose-best-practices.md, and friends; a port into Apple follows apple-swiftui-mvvm.md, apple-swift6-strict-concurrency.md, and friends. Where platform conventions differ (navigation, sheets, back behavior, typography), use the target's.
• Same names, mechanically mappable. Types, files, modules, string keys, icon vocabulary entries, analytics events, and flag keys use the same names on both sides (casing per language). Renames are flagged, not silently accepted.
• Shared contracts are generated, not copied. API clients, design tokens, and event APIs come from the shared source; a hand-written duplicate on one side is a finding.
• Specs before ports. If no spec exists for the feature, write docs/features/<feature>.md from the reference implementation first (states, strings, events, links, accessibility, acceptance checks) — it becomes the checklist for the port and for review.
• Verify both sides. Build and run tests on the target platform after a port; after any shared-contract change, regenerate and build both. Say which commands ran and what passed; never claim parity you didn't check.
• Severity by user impact: broken (feature missing or wrong on one platform with no parity note, a contract mismatch that crashes or drops data, untranslated or missing strings, a deep link that opens on one platform only) > drift (renamed concepts, hand-written duplicate DTOs/tokens, differing event names or flag defaults) > polish (naming nits, structure that could mirror more closely).
• Cross-reference, don't duplicate: design-system specifics go to swift-design-system-pro / android-design-system-pro; Swift concurrency to swift-concurrency-pro; coroutines to android-coroutines-pro; Gradle multi-module structure to android-gradle-architecture-pro; SPM structure to swift-package-pro.