Stateful

Apply the five re-entry questions to an in-scope active state of a software system to specify how it behaves when entered from contexts other than the canonical one (after time has passed, from a notification or deep link, without preceding state, after underlying data has changed, or during/after a system failure). Use whenever a user has triaged states and is specifying behaviour for systems where re-entry matters: notifications, deep links, multi-device flows, out-of-band messages, push reminders, scheduled tasks the user returns to. Use also after a state audit on an existing product to specify gap states that are in-scope and active. The fourth step in the Stateful method. Do not use on `out` states or transient states that users do not meaningfully remain on (validation, commit). Do not collapse the five questions into a single "returning user" variant; that is the failure mode this skill exists to prevent.

Audit an existing software product or design by deriving its likely state space and comparing it to what the codebase actually handles, naming the gaps where states exist in the system but have not been designed. Use whenever a user is applying state-first thinking to an existing product (rather than greenfield work), wants to identify undesigned states in a product with a history of complaints or bug reports concentrated on specific surfaces, needs evidence to make the case for state-first work to stakeholders, or is the on-ramp for a designer/engineer/PM without team authority to restructure process; the audit produces a concrete artefact and a stakeholder-ready argument. The primary entry point for existing-project work in the Stateful methodology. Requires filesystem access to the codebase being audited; cites `file:line` evidence for the gaps it claims. Do not use for new projects (use system-sentence and state-list instead) or as a substitute for the method (it is a diagnostic, not a replacement). Do no

Render an existing Stateful state map as a Mermaid diagram, grouped by category (active, failure, interruption, surface) and styled by scope (in, out-with-implication, out). Use whenever a user wants to see their state map as a graph, diagram, or visual overview; wants to embed the map in STATEFUL.md, a README, a PR description, or any other place GitHub-flavoured markdown renders (GitHub renders Mermaid natively); or wants a shareable picture of the map for a stakeholder conversation. Requires an existing state map (state-map.json, a STATEFUL.md state list, or triage tables the user points at). Do not use this skill to create or invent states; the graph is a view of the map, not a source of it. Do not invent transitions between states that the map does not record.

List the states of a software system across four categories (active, failure, interruption, surface) using interrogation patterns derived from a structural system sentence. Use this whenever a user has a system sentence (or has just produced one) and needs a structured state list before triage or design work; whenever someone is moving from happy-path thinking to state-first thinking and needs an exhaustive-enough catalogue across the four categories; or as the second step in the Stateful method after the system sentence. Do not use before a system sentence exists, as listing without an anchor drifts into exhaustive taxonomy. For existing products, prefer the state-audit skill, which handles the listing as part of a comparative procedure rather than producing a list disconnected from what already exists.

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 use

Take a state list of software-system states and recommend a scope tag for each (`in` for designed this iteration, `out-with-implication` for deferred but constrains in-scope work, or `out` for deferred with no current implication), with implication notes on the middle category — for the human to confirm. Use whenever a user has a flat list of states from the state-list skill or a state audit and needs to make scope decisions before any design or remediation work begins; whenever someone needs to decide which states to design now versus later without losing the deferred ones; or as the third step in the Stateful method, after the state list in new projects and after audit in existing-project work. Do not use before the state list or audit is complete; partial lists produce partial triage and the missing states get silently dropped.

Produce a structural system sentence (what a software system *is* as an object that exists over time) from a feature-framed or flow-framed description, generative enough that 3–5 distinct states fall out of its nouns and verbs. Use this whenever a user is starting state-first design work on a software product, has described a system in feature terms ("helps the user…", "lets people…") or flow terms ("first X, then Y…"), needs to anchor a state audit on an existing product, or is otherwise trying to nail down what a stateful software system fundamentally is before listing states or designing screens. The first step in the Stateful method. Skip for systems that are not stateful (landing pages, marketing surfaces, static documents) and as a prompt-optimisation step for a generative model.