What this prompt does
This prompt positions the model as a senior product engineer for IoT apps and asks it to specify a smart home scene builder tightly enough to build, returning working component code rather than pseudocode. It lays out six deliverables: a scene creation flow (name, pick a trigger, save as draft), a conditions layer that gates whether actions run, a chained-actions editor with per-action delays and reordering, a visual node graph for complex scenes with a list fallback for simple ones, a test-run mode that simulates a scene and surfaces which step fires or fails, and scheduling plus enable/disable toggles with clear empty, loading, and error states. The structure works because it treats a scene builder honestly — as a tiny rules engine wearing a friendly UI.
Three variables shape it. [stack] sets the framework (default React Native). [devices] lists the controllable device categories like lights, climate, music, and blinds, which the chained-actions editor targets. [triggers] defines the available trigger types — time, location, voice, device state — that the creation flow lets users pick from. The test-run mode is the part that earns trust: non-technical users will not rely on automations they cannot dry-run, so the prompt insists the simulation show exactly which step would fire or fail before a scene goes live.
When to use it
- You are building a smart home, IoT, or automation app and need a scene or rules builder.
- Non-technical users must compose conditional logic without it feeling like programming.
- You need triggers, conditions, and chained actions modeled as distinct, composable layers.
- A visual node graph for complex automations plus a simple list view for basic ones is desirable.
- You want a test-run or dry-run mode so users can simulate before activating.
- You need component files plus a data-model note for how scenes are stored.
Example output
Expect scene builder component files in your [stack] plus a short data-model note covering how scenes, triggers, conditions, and actions are stored. The creation flow names a scene, picks from [triggers], and saves a draft; a conditions layer gates execution on weather, presence, or time window; a chained-actions editor sequences actions across [devices] with delays and reordering; a node graph handles complex scenes with a list fallback; a test-run mode simulates and flags which step fires or fails; and scheduling with enable/disable toggles ships with empty, loading, and error states. It is a buildable foundation, not a finished product.
Pro tips
- List your real
[devices]so the chained-actions editor targets actual capabilities rather than generic placeholders. - Set
[triggers]to what your platform truly supports; the creation flow only offers what you specify here. - Build the test-run mode early — users will not trust automations they cannot dry-run first.
- Ask the model to keep the node graph optional with a list fallback so simple scenes stay simple.
- Pay attention to the data-model note; it determines how cleanly conditions and chained actions persist.
- If the conditions layer feels shallow, re-run requesting explicit gating logic for weather, presence, and time windows.
