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 local-first freeform visual workspace inspired by Boredly. Use React, strict TypeScript, a maintained Vite build, Zustand for state, Dexie/IndexedDB behind a repository interface, and a secure Electron desktop shell. Support a browser edition and self-contained Windows and Linux desktop packages. Use original brand/artwork, with {{accent_colour}} as an optional accent. The experience should feel like a beautiful, tactile creative desk, with a top board header, compact creation rail, spacious infinite canvas, calm rounded cards and clear contextual controls.
Core board model: stable IDs, workspace and parent-board IDs, item type, document-space x/y coordinates, width/height, z-order, group, optional parent-column placement, labels and locks. Each board independently remembers its camera and appearance. Build notes, rich-text documents, task lists, images/SVG, links, nested boards, columns, tables, drawings, connectors, files, video, audio, colour swatches and comment cards through shared frames with typed discriminated item models. Every menu item must perform a real action. Add click-to-create, clipboard/drop import and keyboard shortcuts; retain unsorted items until the user places them. Use original generic demo material only in an explicitly identified optional example board; do not invent collaborators or cloud sync.
Canvas: smooth pointer-centred zoom, wheel/trackpad pan, space-drag, touch pan and pinch, fit/reset view, board minimap, zoom-correct dragging/resizing and marquee selection. Support dragging groups, keyboard nudging, multi-select, duplicate, copy/cut/paste, z-order, alignment/distribution, snapping/smart guides, and auto-pan near edges. Keep interaction responsive with requestAnimationFrame, bounded computations and viewport culling. Restrained jelly/drag motion may be enabled but must respect reduced motion. Hit testing, connector endpoints, selection and guides must stay correct at every zoom level. One drag gesture is one undo command, not hundreds of commands.
Content: safe rich-text formatting with independent editing undo, image captions and non-destructive cropping, real task reordering with due dates/priorities/assignees/reminders, editable table rows/columns, drawing tools and manually positioned stable connectors. Local card comments and mentions belong to this workspace; no fake online collaboration. Provide recoverable invalid-image/link/file states. A searchable recolourable library of at least 50 original SVG assets and local uploads should support creative work. Allow arbitrary valid hex colours, one-action copy of colour values, configurable board typography with twelve properly licensed local fonts and font fallbacks, and independent English/Dutch interface and spell-check preferences.
Navigation: nested board creation/opening, breadcrumbs, favourites, recent boards, custom ordering, archive/restore and all-board search. A search result opens its board and centres the actual matching item. Provide six editable original templates. Include persistent Trash for boards and cards, restore and permanent-delete confirmation, bounded grouped undo/redo, and recovery when an item is locked or a board is removed. Build polished context menus and accessible dialogs rather than relying on browser alerts.
Themes: complete Light, Dark, Seaside, Synthwave, Coffee, Food, Space and Urban themes, covering the canvas, cards, menus, dialogs, controls, selection, focus and every responsive layout. Generate original theme concept art when available, then reproduce the real interface with components, not a screenshot. Keep decorative art out of reading areas. Preserve comfortable contrast, large touch targets, keyboard operation, predictable focus and reduced motion.
Persistence and portability: use versioned transactional IndexedDB migrations with debounced autosave, repository-level import/export, schema validation and recoverable quota failures. In desktop mode ask for a data folder separately from the executable on first launch. Store media as validated content-addressed assets; use atomic writes, checksum-verified snapshots and a protected pre-upgrade backup. Keep current and previous recoverable workspace snapshots. Never delete existing user boards, original files or their data folder when updating or uninstalling.
Support versioned JSON import/export, safe Markdown import, a portable .boredly backup with media, whole-board PNG/PDF export and explicit reset controls. Validate schemas, archive paths, mime types and expanded sizes; reject path traversal, decompression bombs and executable payloads. Large exports must report progress and recover from cancellation. Take a recovery point before destructive import/reset and verify a snapshot before discarding any embedded media fallback. Explain honestly that a single Markdown file picker cannot resolve arbitrary adjacent media; provide a folder/archive import where supported.
Desktop/browser shared workspace: implement a narrow token-protected server bound exclusively to 127.0.0.1, managed by the desktop tray, so Open in browser uses the selected data folder. Require authentication, origin validation, scoped endpoints and safe concurrent revisions; never expose the helper to the LAN. Link metadata previews may contact the selected public website directly through a bounded local helper, with DNS/IP validation, redirect limits and SSRF protection; never route user URLs through a paid metadata service. Failed/blocked previews must retain a usable local link card. Desktop renderer windows must use sandboxing, context isolation and no Node integration; validate all IPC inputs and constrain file operations to selected roots.
Complete tests for camera coordinate transforms, dragging/resizing at different zooms, grouped undo/redo, card persistence, selection/culling, search navigation, task reminders, schema migrations, import validation, Trash/restore, rich-text sanitization, media quotas, recovery snapshots and desktop helper authorization. Add real browser workflows for each card type, themes and touch controls. Stress-test a representative 1,000-card board and report measured responsiveness and resource usage. Use temporary fixtures rather than the user's existing workspace.
Produce a production browser build and actual Linux AppImage and Windows portable/installer artifacts where toolchains allow. The user should not need Node or npm to open a desktop package. Test update/uninstall behaviour so the separate data folder survives. Run typecheck, lint, unit/integration checks, browser workflows, desktop smoke checks and production packaging, fix failures and report actual results. Set up all required tools yourself. Finish with artifact paths and a concise launch action; honestly identify any unavailable platform signing/toolchain checks.
Build and completion requirements
Application type: Desktop. Target: Windows and Linux.
Use Electron with strict TypeScript, sandboxed windows, context isolation, no renderer Node integration, narrow validated IPC and a restrictive CSP. Build a platform package for the selected OS.
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:
Create and edit all card types; restart and recover data. Test zoom-correct group interactions, all themes, keyboard/touch, safe imports, Trash and recovery. Measure a 1,000-card board. Validate Electron IPC and loopback-helper authorization. Smoke-test desktop packages without development tools.
Costs and dependencies:
No required accounts, paid services or cloud storage. Use free local build tools and licensed original assets; disclose optional signing costs.
Permissions and data constraints:
Keep boards, files and credentials local. Ask before accessing a selected data folder or fetching a chosen public link. Protect the loopback helper; never expose it to a network or modify original user media.
Paste this into your preferred AI assistant. Review its output before running it.
