What this prompt does
This prompt puts the model in the role of a senior mobile UI engineer and asks it to specify a fitness studio class booking screen tightly enough to build, returning working component code rather than pseudocode. The booking moment is where revenue and trust both live, so the prompt is structured around removing ambiguity. Four variables steer it: [stack] sets the framework (React Native by default), [class_metadata] defines the fields on each class card, [booking_model] describes how bookings are paid or limited (class credits plus membership), and [brand_mood] sets the visual tone like "energetic, bold, high-contrast."
The deliverables center on a weekly schedule grid with a clear today marker, class cards showing instructor, duration, level, and a live spots-left state, and a book/join-waitlist CTA with full, almost-full, and waitlisted states. By surfacing credit balance and membership status before the user commits, and demanding empty, loading, and error states for the schedule fetch, the prompt closes the gaps where booking UIs quietly break — especially the waitlist transition where double-bookings and front-desk friction start. The instruction to return real code plus a sample data shape, rather than pseudocode, means the spots-left count, credit balance, and waitlist states all have concrete fields behind them, which is what keeps the booking moment trustworthy when scarcity is live and the schedule changes between fetches.
When to use it
- Building a class booking screen for a gym, studio, or fitness app
- Designing live spots-left and waitlist states that prevent double-bookings
- Surfacing
[booking_model]details like credits and membership before commit - Generating starter component code in your
[stack] - Defining the class card fields via
[class_metadata] - Setting a visual direction with
[brand_mood]for a studio brand
Example output
You get components with their props and types, a sample class and booking data shape, and a weekly schedule grid that scrolls by day with a today marker. Class cards show the metadata fields and a live spots-left state; the CTA renders full, almost-full, and waitlisted variants; and the screen includes credit balance, membership status, a confirmation and reminder flow, a post-class review prompt, and the empty, loading, and error states for the schedule fetch.
Pro tips
- Nail the waitlist states in deliverable three early — the full to almost-full to waitlisted transition is where most booking UIs quietly break.
- Set
[booking_model]precisely so credit and membership logic matches how your studio actually charges. - List exactly the fields you want in
[class_metadata]so cards stay scannable rather than cluttered. - Keep spots-left live and unambiguous; a stale count is what causes double-bookings and angry front desks.
- Use
[brand_mood]to push the visual tone, but ask for the data shape separately so logic and styling stay decoupled. - If the returned screen is dense, ask the model to split the schedule grid and the class card into reusable components.
