Start with the visual design. If your workspace can generate images, first create concept art for the main screens and their mobile layouts, then use it as the visual reference while implementing the real app. If image generation is unavailable, create a coherent design system and working HTML/CSS or native UI prototype first; continue the complete build without waiting for an image tool. Adapt the style to this app, with polished typography, consistent spacing, purposeful colour, clear navigation and restrained motion. Use original artwork and icons, keep text readable, and never bake interactive controls or page text into screenshots. Build all controls with real accessible components. Compare the implemented screens against the chosen design at desktop and phone sizes, correct spacing, contrast, clipping, empty states and visual inconsistencies, and verify keyboard, touch and reduced-motion behaviour. A beautiful mockup alone is not a completed application.
Work as a senior product engineer and finish the application in this specification. This is a real application, not a mockup. Create the complete source tree, configuration, migrations or schemas, working UI, persistence, error handling, and tests. Do not leave stub handlers, simulated production data, TODO features, inert buttons, or invented successful test results.
Start by inspecting the workspace and available tools. Choose compatible maintained dependency versions and pin them in a lockfile. Write a short implementation plan and an acceptance checklist, then implement and run the work without stopping after planning. Use stages to manage complexity, but carry every required stage to completion. If context runs low, save progress and remaining acceptance checks in a local handoff document and resume from it. Ask only about decisions that cannot safely be inferred.
Keep modules small and put domain logic outside presentation components. Validate inputs at trust boundaries, handle cancellation and failures, preserve user data, and provide clear recovery actions. Include keyboard access, labelled controls, visible focus, useful empty/loading/error states, sensible contrast, and reduced-motion support. No advertising, subscriptions, analytics, hidden cloud dependencies, or remote executable loading.
Before finishing, run the compiler/type checker, linting, unit/integration tests, and a production build. Add real workflow tests for the acceptance checklist and run them against the built application where possible. Fix failures and repeat affected checks. Report exact commands, actual results, any environment-blocked checks, setup instructions, and remaining limitations. Never call an unfinished or untested feature complete. Include a README explaining architecture, development, packaging, data locations, permissions, and recovery. Use clean generated sample data only in explicit tests and previews.
Build {{app_name}}, a complete private local music player for Windows, macOS, Linux desktops and Android phones. Deliver both a real desktop application and an Android application, not a stretched phone mockup or a desktop-only player. Use Kotlin Multiplatform and Compose Multiplatform for shared domain models, queue policies, repository contracts and adaptive UI. Pick and pin compatible maintained toolchain versions after inspecting the available host. {{accent_colour}} customizes the warm coral accent. Match the supplied Lilt concept art: nocturnal plum, cream text, dusty violet panels, album artwork, clear transport controls and an Albums-first home. No network permissions, streaming catalogue, analytics, ads, accounts, subscriptions or hidden cloud dependency in the finished applications.
Platform boundaries: Android uses MediaStore, Room and AndroidX Media3 ExoPlayer in a MediaLibraryService, supporting Android 8/API 26 and later with current permission and foreground-service requirements. Desktop uses a genuine JVM-compatible local-audio engine such as libVLC via vlcj, local SQLite and user-selected music folders. Package the required runtime and native audio libraries with the application where their licenses permit; account for architecture, codec distribution and native initialization. Android Media3, MediaStore, Android lifecycle and foreground services must never appear in common or desktop source. Use explicit expect/actual implementations or platform interfaces for audio, storage, artwork, file access and media controls. Ship usable playback on each selected platform; no fake desktop backend, dummy transport handlers or unsupported claim of cross-platform completion.
Library: Android requests only needed local-audio permissions and queries MediaStore on background dispatchers, reconciling additions/deletions into the Room index. Desktop opens a native directory picker, persists approved folders, scans lazily in the background and detects changes with bounded watchers or an explicit rescan. Do not scan the whole disk, follow symlink loops, require administrator rights or copy music into app storage. Keep stable logical IDs and separate platform file/content-URI resolvers; never assume a phone URI or desktop absolute path is portable. Model tracks, albums, artists, favorites, skip preferences, history and saved queues. Handle unknown metadata, duplicate names, missing artwork, disconnected/removable drives, denied access and files disappearing. Search and sort albums/tracks/artists and browse folders. Lazy artwork loading, bounded image caching, cancellation and keyed virtualized lists must keep large libraries responsive.
Playback: the Android engine is owned by a foreground media-library service, never a screen or activity. The desktop engine has an application-scoped lifecycle independent of individual windows. Provide synchronized play/pause, seek, next/previous, shuffle, repeat off/one/all, queue reorder, play-next, favorites, automatic skip preferences, persisted queue and position. Restart paused unless the user deliberately requests playback. Handle audio focus, interruption/ducking and headphone removal on Android; integrate desktop media keys/session controls where supported and accurately document OS limitations. Device loss, unsupported files or a missing native codec must produce a useful recoverable state. Test skip/shuffle/repeat policies so unavailable or skipped tracks cannot cause infinite loops. Seek, duration and state stay synchronized across mini-player, now-playing and each available OS playback surface.
Adaptive UI: desktop has collection/sidebar, album or playlist detail and an anchored transport bar; resizing never turns controls inert or clips the queue. Phone has collection, mini-player and bottom destinations, and a focused now-playing view. Tablet/foldable layouts add panes around 700 dp. Rotation, folding, window resize, recreation and screen lock preserve playback and browsing state. Use a clear generous primary transport control, rounded album art and an 8 dp spacing system. Support keyboard shortcuts, accessible labels, visible focus, contrast, reduced motion and 200% text size. Do not continuously crossfade all artwork or rebuild the library each playback tick. Adapt the visual concept to each platform rather than scaling a screenshot.
Privacy and storage: every library index, setting, queue, favorite and history remains on-device. No broad Android all-files access, silent cloud backup, telemetry or runtime music download. Decide and document backup behavior. Include clear-history, forget-folder, rescan, permission-revocation handling and safe versioned schema migrations on both platforms. Keep release signing credentials outside source. Use original or openly licensed test audio fixtures; never bundle commercial music or copyrighted album artwork.
Engineering and delivery: separate shared models/policies, platform repositories and playback adapters from Compose presentation. Use lifecycle-aware state collection on Android and scoped cancellation/disposal on desktop. Provide a pinned Gradle wrapper, reproducible dependencies, a setup task that checks/downloads required developer tooling where permitted, lint, compiler checks, policy tests, persistence/migration tests and real platform workflow tests. Use Compose desktop native distribution tooling/jpackage for launchable Windows, macOS and Linux artifacts with bundled Java runtime and correctly resolved native audio libraries. Build the Android installable APK on the available compatible host. Explain platform-host constraints for native packaging/signing; do not invent executables for systems the host cannot build. Hand over the actual artifacts you built, a single clear launch/install action and source. Do the environment setup, coding, testing and packaging yourself. The user should paste this prompt and open the delivered artifact, without arranging a coding environment manually.
Acceptance: import a fixture album and play without internet on both editions; search and sort a large library; favorite/reorder then restart; verify shuffle/repeat/skip/seek; remove the currently playing file; disconnect a library drive; deny/revoke audio permission; handle malformed metadata and missing artwork; check mobile audio focus/headphone removal, lock screen and rotation/fold/unfold; check desktop resizing, keyboard and engine shutdown; migrate saved data and try 200% text. Android must declare no INTERNET permission. Identify exactly which desktop hosts and Android emulator/devices were built and tested, with commands and actual results. Report blocked platform checks honestly and distinguish concept art from screenshots of a tested application.
Build and completion requirements
Application type: Desktop & mobile. Target: Windows, macOS, Linux and Android.
Use Kotlin Multiplatform and Compose Multiplatform with shared domain logic and suitable shared UI, plus real platform-specific adapters for media, files, permissions and lifecycle. Keep Android-only APIs out of common and desktop code. Pin compatible stable Gradle/Kotlin/Compose dependencies and package each selected platform, with shared policy tests and native integration/UI checks.
Implement a complete working application for the idea above. Create every necessary source/configuration file, data model, migration, interface and setup instruction. No production mocks, stub handlers, inert controls, placeholder features or invented successful tests.
Inspect the available workspace and OS, then set up the coding environment yourself: obtain missing runtimes and build tools from official sources in an isolated project environment, install locked dependencies, and configure necessary local services. Make a short plan and acceptance checklist, then implement every stage without stopping at a scaffold. Keep a handoff file if context becomes limited. Ask only for credentials, permissions, or unavoidable platform decisions you cannot supply yourself.
Use the actual APIs and filesystem behavior of the selected OS. Handle supported versions, paths, permissions, installation, lifecycle, offline behavior and packaging. Do not claim support for an OS you did not build/test; document environment-blocked verification honestly.
Keep performance measurable: bound memory and work queues, move costly operations off the UI thread, paginate or virtualize large datasets, index database queries, avoid N+1 queries, optimize images/assets and cancel stale requests. Test representative large inputs and report measurements rather than promising excellent performance without evidence.
Keep architecture clear: separate UI, domain logic, persistence and integration boundaries; use explicit types where supported, validated inputs, meaningful error handling, versioned data migrations and pinned compatible maintained dependencies.
Protect credentials and user data. Never put secrets in prompts, renderer code, public bundles, logs or version control. Validate authorization on the server/native boundary, use safe session/token storage, sanitize untrusted content, and preserve originals before destructive changes. Use only permissions and network access the app needs.
Make the interface understandable and accessible: keyboard operation, labelled controls, visible focus, readable contrast, responsive/adaptive layouts, large touch targets, reduced motion, useful empty/loading/error states and recoverable failures. Keep default screens simple and disclose advanced details when needed.
Write meaningful unit/integration and real workflow tests for the core features, security boundaries and failure cases. Run type/compiler checks, lint/format checks, tests and a production build, fix failures and repeat affected checks. For websites, also run mobile browser accessibility checks and Lighthouse. Do not replace tests with assertions that merely mirror the implementation.
Complete and run the production build, then package a launchable artifact for the selected OS. Desktop: provide a runnable app/installer and launcher; mobile: a real installable package with supported signing instructions; browser: a built local app with a one-action launcher for any required server. Perform all setup, tests and packaging yourself. The person should only need to paste this prompt into their AI coding workspace, then open the finished app. Include a concise launch guide and report actual test results, artifact paths, costs and any genuinely blocked checks. Never invent successful builds; explain unavoidable signing or permission requirements. Avoid paid services unless explicitly required.
Required setup/run behavior:
Set up the required coding environment yourself. Implement every stage, run all tests, fix failures and package the finished application for the selected OS. Provide the runnable artifact and a simple launch action. Ask for permission only for signing, credentials, or disruptive desktop-session operations you cannot perform safely.
Acceptance checks:
Play a local fixture album offline in desktop and Android builds.
Search, favorites, queue and playback position survive restart on both editions.
Shuffle/repeat/skip never loop indefinitely, and missing files recover cleanly.
Android permissions, foreground playback and headphone handling work.
Desktop packaging includes the runtime and real native audio adapter.
Keyboard, resizing, fold/rotation and 200% text remain usable.
Report actual build/test results separately for every platform.
Costs and dependencies:
No subscription or cloud service required. Uses free development tools and local music you own; native distribution and signing requirements depend on the target platform.
Permissions and data constraints:
Reads user-selected desktop music folders or Android local audio. Saves index, settings and history locally. Android uses a playback foreground service and optional media notifications. No internet access.
Paste this into your preferred AI assistant. Review its output before running it.