원클릭으로 Manus에서 모든 스킬 실행

state-prompt

스타3

포크0

업데이트2026년 7월 14일 13:41

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

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

mskayyali

mskayyali/Stateful

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

관련 직업SOC

SOC 직업 분류 기준

소프트웨어 개발자컴퓨터 및 수학직·SOC 15-1252

SKILL.md

readonly

이 저장소의 다른 Skills

같은 저장소

reentry-pass

mskayyali/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.

2026-07-143

state-audit

mskayyali/Stateful

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

2026-07-143

state-graph

mskayyali/Stateful

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.

2026-07-143

state-list

mskayyali/Stateful

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.

2026-07-143

state-triage

mskayyali/Stateful

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.

2026-07-143

system-sentence

mskayyali/Stateful

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.

2026-07-143

name

state-prompt

description

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.

Take the user's generic prompt as input. Identify the system being designed and the rendering surface (web, mobile, email, etc.).
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.
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.
Collect the conditions that define the rendering surface: screen size, platform conventions, accessibility constraints, any brand or system-specific constraints the user can share.
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.
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.
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".