state-prompt

name

state-prompt

description

Rewrite a generic design prompt ("design a medication app", "make me a dashboard for X") into a state-first prompt that specifies one state of the target system under explicit conditions, ready to paste into a generative tool (Midjourney, DALL-E, v0, Lovable, Figma AI, Cursor, etc.). Use whenever a user is about to send a feature-level prompt to a generative model for a design artefact (image, component, screen, mockup) and would benefit from rendering one specific state under specific constraints rather than the system in the abstract; whenever someone has a state map (or partial map) and wants to generate visuals from specific states; or whenever the user's prompt to a generative tool is producing happy-path-only output and they want a specific failure, interruption, or re-entry state instead. Cross-cutting step in the Stateful method, applicable in both new-project and existing-project flows once at least a partial state map exists. Do not use as prompt-engineering optimisation for its own sake; if the user does not have a target state in mind, the resolution is the state map, not this skill. Do not use for non-stateful generation tasks (illustrations, brand assets, marketing imagery).

State Prompt

Rewrites a generic design prompt into a state-first prompt that specifies a single state of the target system under explicit conditions.

Output discipline

No preamble, no narration of the procedure, no restating the user's original prompt. Deliver the output format below plus only what needs the user's decision. Terse but complete: the paste-ready prompt block, the assumptions, the follow-up state suggestions, and nothing else.

Procedure

Before starting. Read STATEFUL.md from the working directory if it exists. Use it to find the target state and its conditions; the system sentence and re-entry specs sections are particularly useful. This skill does not write back to STATEFUL.md; its output is a prompt, not project state.

1. Take the user's generic prompt as input. Identify the system being designed and the rendering surface (web, mobile, email, etc.).
2. Ask the user which state they want to generate. If they do not have one, offer three candidates from the state map: typically one active failure-adjacent state, one interruption state, and one re-entry variant.
3. Collect the conditions that define the state: what has happened, what is true about the user's context, what data is present, what time has elapsed.
4. Collect the conditions that define the rendering surface: screen size, platform conventions, accessibility constraints, any brand or system-specific constraints the user can share.
5. If the target state has a cause annotation (typically true for failure states from the state map), use it to sharpen the prompt's framing. user-input calls for a coaching surface ("here's what we expected, here's how to fix it"); system calls for an "on our end" surface with retry; external calls for naming the dependency that failed; policy calls for explaining the rule without apologising. Bake this framing into the prompt's Render section so the generative tool produces the right kind of error surface rather than a generic one. If the target state is a failure with no cause annotation, ask the user which of the four applies before assembling.
6. Assemble the state-first prompt. Structure: name the surface, name the state, specify the conditions, specify the rendering requirements (including the cause-implied framing if applicable), specify the output format.
7. Return the prompt as a single paste-ready block, with a one-line note on what state it will produce and which cause framing was applied (if any).

Inputs required

• The user's original generic prompt.
• The target state (name it if the user does not).
• The rendering surface.
• Optional: known conditions from the state map (from 03-reentry-pass or 04-state-map.json).

Output format

State being generated: <state name>

Prompt:
---
<multi-line prompt, assembled from the inputs above>
---

Notes:
- <any assumptions made>
- <suggested follow-up states if the user wants to generate the full surface>

Common failure modes

• Generating a generic prompt dressed up as state-first. If the prompt could apply to any state of the system, it is not state-first. Check that removing the state name breaks the prompt.
• Omitting the conditions. A state name is not a state specification. The prompt must include what has happened and what is true.
• Pasting in the whole state map. Generative models produce better output from one state under specific conditions than from a dozen states described abstractly. One prompt, one state.
• Losing the rendering surface. A prompt without surface constraints produces a surface-agnostic artefact, which is no artefact at all.
• Using this skill to avoid design decisions. If the user does not know which state they want, the skill cannot resolve that; the resolution is the state map.

Example

Input (generic prompt): "Design a medication reminder app."

Interaction: The user names the target state as "overdue dose, user opened app from notification, current medication requires food within 30 minutes of administration".

Output:

State being generated: Overdue dose, arrival from notification, food-dependent medication.

Prompt:
---
Design the main screen of a medication tracker iOS app at iPhone 15 viewport size.

State: the user has an overdue dose. The most recent scheduled dose was 2 hours ago and has not been marked as taken. The medication in question must be taken within 30 minutes of eating food. The user has just opened the app from a push notification.

Render:
- The dose prominently, with its scheduled time and elapsed-since-due shown.
- A primary action to mark as taken, with a contextual secondary action relating to the food requirement (e.g., "I haven't eaten yet").
- A tertiary action to skip this dose, with a note that skipping is recorded.
- Other doses scheduled for today, visibly de-emphasised.
- Respect iOS Human Interface Guidelines. Support Dynamic Type up to accessibility-size large.

Output as a single screen mockup. Do not include other screens or flows.
---

Notes:
- Food-dependency UI is specific to this state. Other overdue-dose states without food constraints would render differently.
- Follow-up states worth generating after this: "dose taken late, with food confirmation", "dose skipped, reason requested".