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 a complete, accessible browser application called {{app_name}}.
What it should do
A canvas drawing app with brush size and colour, eraser, undo and redo, clear confirmation, and transparent or solid-background PNG export.
Deliverable
Provide one complete self-contained HTML file with embedded CSS and JavaScript, followed by short instructions for saving and opening it. Use no build process, external scripts, paid APIs, server or account system. If a feature cannot be implemented reliably within those constraints, explain the limit before changing the scope.
Design
Use a calm, clear interface with labelled controls, visible keyboard focus, responsive layouts, comfortable contrast and reduced-motion support. Use {{accent_colour}} as an accent while preserving contrast. Provide useful empty and error states.
Data and safety
All user data stays on the device. Make no network requests. Never execute imported text or insert user data as raw HTML. Preserve original files. Explain any browser storage or permissions used and provide a clear way to remove saved data.
Quality
Handle invalid and empty input, avoid fake functionality and explain browser limitations. Include a short checklist with normal and edge cases. Do not claim the result is verified or secure without testing it. Return complete code rather than a partial outline.
Build and completion requirements
Application type: Browser. Target: Modern browsers.
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:
Try the main feature with a small sample.
Try empty or invalid input and check the error message.
Check keyboard use and the mobile layout.
Confirm data stays local and exported files are correct.
Costs and dependencies:
No paid app services required.
Permissions and data constraints:
Only files you choose and browser storage where needed.
Paste this into your preferred AI assistant. Review its output before running it.
