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.
Build {{app_name}}, a complete, polished macOS-style application dock for Windows and Linux, with original visuals and deep customization. It should replace the need to hunt through a taskbar without modifying the user's desktop defaults unless they explicitly choose that. Use {{accent_colour}} as an optional accent. Start with a clear feature acceptance checklist and a coherent concept for the dock, its settings and theme editor. Build the whole working app, not a mockup or wallpaper containing icons.
Inspect the target OS/session and official native APIs first. Separate a lightweight presentation layer, typed shared configuration/domain logic and real platform adapters. Select a maintained compatible stack that can deliver actual native integration and smooth low-resource animations; do not force an Electron browser window to imitate capabilities it cannot access. Support Windows 10/11, and Linux with a working GNOME Shell integration in supported sessions plus documented X11 support. Provide a useful standalone launcher on other desktops; implement any advertised additional compositor adapter fully, or identify it as unavailable. Declare exact versions actually tested. Check current GNOME Shell APIs rather than claiming all versions are compatible. For GNOME Wayland window tracking and activation use supported Shell integration; generic Wayland clients do not receive unrestricted global window access. On Windows use validated native application/window APIs and appbar work-area integration when docked. Handle elevated or protected windows honestly without requesting administrator access by default.
Build app discovery and launch for installed applications, manual shortcuts, pinned files/folders/URLs and application groups. Resolve launch identities safely; never concatenate a user-controlled shell command. Support pin/unpin, drag reorder, drag to create groups, keyboard reordering, multi-window app menus, launch/focus/minimize behavior, running indicators, middle-click/new-instance where supported, and validated context actions. Use actual OS-provided window/application state, not periodic random indicators. Preserve the user's current desktop panels/taskbar by default. Make any hide-existing-panel option explicit, per-user, recoverable and reversible, with backup/restore and an uninstall path.
Customization: top/bottom/left/right placement, per-monitor or primary-monitor-only docks, anchored or floating layout, centre/start/end alignment, icon size, spacing, dock thickness, corner radius, margins and screen offsets. Add always-visible, auto-hide and supported intelligent-hide modes with adjustable reveal delay, trigger width and dodge behavior; fullscreen apps should work without stealing input. Correctly account for display scaling, mixed DPI, work areas, hotplug, monitor removal, sleep/resume and virtual desktops. Docks must not cover critical content or interfere with native dragging/click targets.
Create several original polished themes: cosy peach/lavender, glossy berry glass, warm ivory, translucent dark plum and restrained flat styles. Include a real visual theme editor for background colour/opacity, supported blur, borders, shadows, accent, separators, icon background/shape and tooltip typography. Provide live preview, reset and import/export of versioned validated themes. Accept safe local icon packs and user-selected PNG/WebP/SVG with size limits and sanitization. Use original or properly licensed icons, never unlicensed copied macOS artwork. Do not require remote themes, ads, subscriptions, analytics or accounts.
Effects: tasteful cursor-following magnification with controllable scale/radius, spring easing and duration, hover highlight, launch bounce, running-dot pulses, group expansion and show/hide transitions. Make each effect optional and adjustable with sensible bounds. Respect reduced motion and battery-saving mode; when disabled the app must remain fully usable with no hidden animation dependency. Keep icons crisp at fractional scaling and high DPI. Use frame-synchronized transforms and native composition where possible, avoid layout thrashing, bound animations and memory, and stop animation work when the dock is idle or hidden. A dramatic blur must not force a permanently busy CPU/GPU.
Settings should be beautiful and easy to understand: clear grouped panels for Layout, Apps, Appearance and Motion, with visual previews and a single Restore defaults action. Support keyboard navigation, accessible names, visible focus, contrast, large click targets, tooltips with readable text and screen-reader-friendly lists. Persist settings atomically and migrate schemas safely. Handle malformed imported themes, missing apps, disconnected drives, corrupt icons, permission denial, failed launches and unavailable compositor capabilities with recoverable messages.
Security and lifecycle: no automatic privileged changes, unsigned remote executable loading, hidden global keyboard interception or credential collection. Validate native arguments, external URLs and file operations. Offer explicit optional launch-at-login and reversible desktop integration. Single-instance handling, orderly shutdown, crash recovery, clean uninstall and theme/settings preservation must work. Restore any explicitly changed desktop panel settings when disabled/uninstalled. Use temporary test profiles, never alter the user's live session for automated checks.
Test configuration validation/migrations, pin/group/reorder operations, launch identity resolution and command-injection rejection, hide/reveal state machines, multi-monitor geometry and scaling, keyboard accessibility, reduced motion, settings/theme imports, startup/shutdown and restoration. Add real native integration tests or clearly documented target-environment smoke checks for Windows and GNOME Linux. Measure idle resource use, launch/reveal latency and animation frame timings with a populated dock; fix excessive wakeups and memory growth. Do not invent passing tests or working Wayland integration.
Set up the coding environment yourself, implement all stages, run affected checks, build production Windows and Linux packages and provide a launchable artifact with a simple open/install action. Package GNOME integration with valid metadata, preferences, enable/disable cleanup and exact supported Shell versions. Include a concise guide for unavoidable OS permissions or signing requirements. Do not stop at source files, an environment checklist or a design concept.
Build and completion requirements
Application type: Desktop. Target: Windows and Linux.
Choose an appropriate maintained stack for this app and its target OS. Explain the choice briefly, use compatible stable dependencies and commit a lockfile. Prefer native capabilities and avoid unnecessary frameworks.
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 environment, implement the complete app, run all checks and build a launchable package. Give the user the finished artifact and simple launch instructions.
Acceptance checks:
Test app launch/focus/grouping, native running indicators, auto-hide, themes/effects, keyboard/reduced motion, multi-monitor DPI, startup/shutdown and restoration. Measure real idle resources and animation timings; report target-environment limits honestly.
Costs and dependencies:
Use free local dependencies and original licensed art. No account, ads, paid API or cloud service required. Disclose optional platform signing costs before use.
Permissions and data constraints:
Read installed app/window metadata and launch user-selected items. Desktop-panel changes and launch-at-login require explicit opt-in. Keep settings local and never collect credentials or replace system defaults automatically.
Paste this into your preferred AI assistant. Review its output before running it.
