Run any Skill in Manus with one click

reentry-pass

Stars3

Forks0

UpdatedJuly 14, 2026 at 13:41

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

mskayyali

mskayyali/Stateful

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name

reentry-pass

description

Re-Entry Pass

Takes an in-scope active state and produces its re-entry specification by applying the five re-entry questions.

Output discipline

No preamble, no narration of the procedure, no restating the state or the questions. Deliver the output format below plus only what needs the user's decision. Terse but complete: specifications stay 2 to 4 sentences per applicable question; not-applicable verdicts get their one-line reason and nothing more.

Procedure

Before starting. Read STATEFUL.md from the working directory if it exists. Use the system sentence and triage context from it to interpret the state being passed. If no system sentence is present, ask the user for one.

Read the state's canonical rendering and the scope note from triage.
For each of the five questions, decide whether it applies to this state. Mark not-applicable explicitly; do not silently skip.
- Q1: What does the user see if they return to this state after time has passed?
- Q2: What does the user see if they arrive from a notification, deep link, or different device?
- Q3: What does the user see if they arrive without the preceding state having been shown?
- Q4: What does the user see if the underlying data has changed since they last saw this state?
- Q5: What does the user see if they arrive during or after a failure in the system?
For each applicable question, write a specification of 2–4 sentences. Describe the rendering under that re-entry condition and the system behaviour required.
Flag any specification that conflicts with the canonical rendering. These are design decisions, not errors; the user must choose.
If state-map.json exists in the working directory (the user opted in during the state-list step), update the relevant state's reentry_variants array with the new specifications. Leave the file untouched if it does not exist.
Return the state's re-entry specification, one paragraph per applicable question.

Working memory. Update STATEFUL.md in the working directory: append to the ## Re-entry specs section a line for the state just passed (state id + count of applicable variants). Full per-question specifications belong in the design file or a separate notes file, not in this summary. If STATEFUL.md does not exist, create it. Stamp Last updated: <date> by reentry-pass.

Inputs required

The state's name, category, and canonical rendering description.
The system sentence (context for what "re-entry" means for this system).
Optional: known constraints from triage (particularly which adjacent states are out and how that constrains the specification).

Output format

## State: <name>

**Canonical rendering.** <one-paragraph summary>

**Q1. Return after time has passed.** <specification, or "not applicable: reason">
**Q2. Arrival from notification, deep link, or different device.** <specification, or "not applicable: reason">
**Q3. Arrival without the preceding state.** <specification, or "not applicable: reason">
**Q4. Underlying data has changed.** <specification, or "not applicable: reason">
**Q5. Arrival during or after a failure.** <specification, or "not applicable: reason">

Common failure modes

Treating re-entry as a single variant. A "returning user" specification is not a re-entry pass. Each question is distinct.
Treating re-entry as copy work. Re-entry specifications affect data-model, session-scoping, and state-validation logic, not only language.
Omitting Q4 and Q5. Q4 (data changed) and Q5 (prior failure) are the two most commonly skipped, and the two that produce the most production incidents.
Designing re-entry on top of the canonical state. Re-entry conditions may contradict the canonical rendering. The specification is its own artefact, not a variant stylesheet.
Specifying without checking the token or data model. Re-entry specifications that assume consistent state on arrival repeat the failure they are meant to address.

Example

Input: State 8 from the password-reset state list: "New-password form, empty".

Output (abbreviated, see full version in the worked example):

## State: New-password form, empty

**Canonical rendering.** A form with password and confirm-password fields, policy hints, and a submit button. Account context (which account is being reset) is displayed.

**Q1. Return after time has passed.** The token has a validity window. If the user opens the form, leaves, and returns after the window has elapsed, submitting the form must not silently fail. The surface must detect token expiry on focus, not only on submit, and present the appropriate failure state with a path to re-request.

**Q2. Arrival from notification, deep link, or different device.** Canonical arrival. The link may arrive on a device that has never signed in to the account. The surface must not assume any session context; account identity must be derived from the token and shown explicitly.

**Q3. Arrival without the preceding state.** Validate the token presence and correctness before rendering the form. A forwarded link or a malformed URL must not present a submittable form.

**Q4. Underlying data has changed.** Between click and submit, the account's email may have changed, the account may have been deleted, or the user may have reset through another path. Submit must revalidate the token and account state, not only the password value.

**Q5. Arrival during or after a failure.** If the user arrives after a prior submit failed mid-commit, re-check the credential state before offering a second submit.

See EXAMPLES/password-reset/03-reentry-pass.md for the complete worked example.

More from this repository

same repository

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-prompt

mskayyali/Stateful

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

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

reentry-pass

description

Re-Entry Pass

Takes an in-scope active state and produces its re-entry specification by applying the five re-entry questions.

Output discipline

Procedure

Read the state's canonical rendering and the scope note from triage.
For each of the five questions, decide whether it applies to this state. Mark not-applicable explicitly; do not silently skip.
- Q1: What does the user see if they return to this state after time has passed?
- Q2: What does the user see if they arrive from a notification, deep link, or different device?
- Q3: What does the user see if they arrive without the preceding state having been shown?
- Q4: What does the user see if the underlying data has changed since they last saw this state?
- Q5: What does the user see if they arrive during or after a failure in the system?
For each applicable question, write a specification of 2–4 sentences. Describe the rendering under that re-entry condition and the system behaviour required.
Flag any specification that conflicts with the canonical rendering. These are design decisions, not errors; the user must choose.
If state-map.json exists in the working directory (the user opted in during the state-list step), update the relevant state's reentry_variants array with the new specifications. Leave the file untouched if it does not exist.
Return the state's re-entry specification, one paragraph per applicable question.

Inputs required

The state's name, category, and canonical rendering description.
The system sentence (context for what "re-entry" means for this system).
Optional: known constraints from triage (particularly which adjacent states are out and how that constrains the specification).

Output format

## State: <name>

**Canonical rendering.** <one-paragraph summary>

**Q1. Return after time has passed.** <specification, or "not applicable: reason">
**Q2. Arrival from notification, deep link, or different device.** <specification, or "not applicable: reason">
**Q3. Arrival without the preceding state.** <specification, or "not applicable: reason">
**Q4. Underlying data has changed.** <specification, or "not applicable: reason">
**Q5. Arrival during or after a failure.** <specification, or "not applicable: reason">

Common failure modes

Treating re-entry as a single variant. A "returning user" specification is not a re-entry pass. Each question is distinct.
Treating re-entry as copy work. Re-entry specifications affect data-model, session-scoping, and state-validation logic, not only language.
Omitting Q4 and Q5. Q4 (data changed) and Q5 (prior failure) are the two most commonly skipped, and the two that produce the most production incidents.
Designing re-entry on top of the canonical state. Re-entry conditions may contradict the canonical rendering. The specification is its own artefact, not a variant stylesheet.
Specifying without checking the token or data model. Re-entry specifications that assume consistent state on arrival repeat the failure they are meant to address.

Example

Input: State 8 from the password-reset state list: "New-password form, empty".

Output (abbreviated, see full version in the worked example):

## State: New-password form, empty

**Canonical rendering.** A form with password and confirm-password fields, policy hints, and a submit button. Account context (which account is being reset) is displayed.

**Q1. Return after time has passed.** The token has a validity window. If the user opens the form, leaves, and returns after the window has elapsed, submitting the form must not silently fail. The surface must detect token expiry on focus, not only on submit, and present the appropriate failure state with a path to re-request.

**Q2. Arrival from notification, deep link, or different device.** Canonical arrival. The link may arrive on a device that has never signed in to the account. The surface must not assume any session context; account identity must be derived from the token and shown explicitly.

**Q3. Arrival without the preceding state.** Validate the token presence and correctness before rendering the form. A forwarded link or a malformed URL must not present a submittable form.

**Q4. Underlying data has changed.** Between click and submit, the account's email may have changed, the account may have been deleted, or the user may have reset through another path. Submit must revalidate the token and account state, not only the password value.

**Q5. Arrival during or after a failure.** If the user arrives after a prior submit failed mid-commit, re-check the credential state before offering a second submit.

See EXAMPLES/password-reset/03-reentry-pass.md for the complete worked example.