What this prompt does
This prompt makes the model a senior mobile UI engineer building map-based apps and asks it to specify an EV charging station finder tightly enough to build, returning working component code rather than pseudocode. It defines six deliverables: a map with availability-styled pins and a list/map toggle, connector and speed filters that update pins and list together, live availability and pricing with a freshness timestamp, a route planner that inserts charging stops, an active charging-session status with progress and stop control, and a payment history list with proper empty, loading, and stale-data states. The structure forces the model to treat live data as fallible, which is the whole challenge of EV finders.
Four variables drive it. [stack] sets the framework and map library (default React Native + Mapbox). [connectors] lists the plug types to filter, like CCS, CHAdeMO, and Tesla. [live_data] names the source of availability, such as an OCPP roaming network API, which determines how freshness is modeled. [core_jobs] captures the primary user tasks — find, route with stops, pay, track session — keeping the build focused. The recurring theme is freshness: a pin that says available when it isn't strands a driver, so the prompt asks for stale states and timestamps from day one.
When to use it
- You are building an EV charging finder or any map app where live availability can be wrong.
- You need connector and speed filters that keep the pins and the list in sync.
- Route planning with inserted charging stops is part of the experience.
- You want active session tracking with progress and a stop control.
- Showing data freshness and handling stale data are real requirements, not nice-to-haves.
- You need components, props/types, and a sample data shape to start building immediately.
Example output
Expect components in your [stack] along with props/types and a sample station/session data shape. The map renders charger pins styled by availability with a list/map toggle; filters for [connectors] and speed update both views together; each station shows live availability and pricing with a freshness timestamp tied to [live_data]; a route planner inserts stops along a destination; an active-session panel shows progress and a stop control; and a payment history list ships with explicit empty, loading, and stale-data states. It is a buildable scaffold, not a finished app.
Pro tips
- Name a real
[live_data]source so the model can model freshness and timestamps realistically instead of guessing. - List the exact
[connectors]you support; filters are only useful if they match your network's plug types. - Keep
[core_jobs]tight so the model prioritizes find, route, pay, and track rather than sprawling. - Build the freshness and stale-data states first — never render availability without showing how old it is.
- Swap
[stack]to your real map library so pin styling and clustering are idiomatic. - If the route planner is weak, re-run asking specifically how charging stops are inserted and recalculated when a waypoint changes.
