Compose Screen Splitter

Why this skill exists

Compose Screens accumulate UI sections (header, list, summary, dialog, sheet, …) until the file becomes hard to navigate, hard to review, and hard to preview. The Medium article "How to split Compose screens before they become unmanageable" names the symptoms (600-800 lines, 3-4 levels of nesting, six concerns sharing one file) and the cure (Screen↔Content split, name-driven extraction, feature-local component packages).

The NutriSport project has already adopted most of the cure as rules — Route↔Screen separation in conventions.md, :core:<name> for cross-feature reuse in architecture.md Rule 12, design-system primitives in :shared:ui/component/, Preview discipline in preview.md. What's missing is an executor: nobody is responsible for noticing when a Screen crossed the threshold and applying these rules without breaking the contract surface (DI in Routes, no DI in Screens, Preview light+dark for Screens, internal reuse never public).

This skill is that executor. It works in two modes — audit-only (read-only report) and execute (run the full split with compile + test verification).

When to invoke

Trigger phrases (English + Ukrainian, dictation-friendly):

• "split this Screen", "розпиляй цей екран", "decompose this composable file"
• "DetailsScreen is too long", "файл занадто довгий"
• "audit screen size", "перевір розмір екрана"
• "extract sections from XxxScreen", "винеси секції в окремі файли"
• After the feature pipeline finishes and the new Screen is ≥300 lines (Phase 4 wires this in automatically — see feature/SKILL.md Step 19.5).