What this prompt does
This prompt turns the model into a senior mobile product designer and asks it to design a complete journal entry composer screen, returning real component code rather than a mockup description. It is opinionated about which six pieces matter: a distraction-free writing area, a mood selector, photo attachments, a daily writing prompt, word count plus tags plus a markdown preview, and autosave with safe crash recovery. By naming the deliverables explicitly, you stop the model from wandering into nice-to-haves and force it onto the parts that make journaling tools usable.
The three variables steer the result. [stack] decides the actual framework and component idioms (the default is React Native + Expo). [mood] shapes the visual tone, so a value like "calm, minimal, warm paper feel" pushes toward soft spacing and muted color rather than dense chrome. [writing_context] tells the model when and why someone journals, which changes copy and defaults — a nightly reflection screen behaves differently from a quick gratitude log. The autosave requirement is the load-bearing part: it makes the model treat persistence as a first-class concern instead of an afterthought.
When to use it
- You are building a journaling, notes, or diary app and need a composer screen, not a full design system.
- The brief asks for a "calm" or distraction-free writing experience and your first draft feels button-heavy.
- You want autosave and crash recovery designed in from the start rather than retrofitted.
- You need working component code in a specific stack to hand to engineering or iterate on yourself.
- You are prototyping mood tracking tied to written entries and want the selector to not break writing flow.
- You want a markdown preview toggle and tagging without overcomplicating the primary writing surface.
Example output
Expect a composer component (or small set of components) in your chosen [stack], with a growing text area that hides chrome while typing, an inline mood selector, an add/remove/reorder photo gallery, an acceptable-or-dismissable daily prompt, and a live word count with tags and a preview toggle. It closes with a one-line note on the autosave and recovery strategy — typically debounced local persistence plus a visible "saved" state and a recovery path after a crash. It is a starting implementation you refine, not a finished product.
Pro tips
- Make
[mood]concrete and sensory ("warm paper feel," "soft, low-contrast") rather than abstract; vague tone values produce generic UI. - Set
[writing_context]to the real moment of use so defaults, prompt copy, and tone match how people actually write. - Build and verify the autosave behavior before touching styling — losing an entry once destroys trust in the whole app.
- Ask for the "saved" state to be honest and visible; a fake or optimistic indicator is worse than none.
- If the first pass over-decorates, re-run with
[mood]emphasizing restraint and explicitly request that chrome hide while typing. - Swap
[stack]to match your real project so the generated code uses idiomatic components instead of needing translation.
