State list

Skill mskayyali/Stateful/skills/state-list

A way of designing software where the conditions it can be in are treated as the work, not as edge cases to handle later.

Install

npx -y skills add mskayyali/Stateful --skill state-list

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Build a Stateful condition inventory for a confirmed system sentence across four related lenses: lifecycle states, failures, interruptions, and surfaces. Use after system-sentence on greenfield or feature-level work when the user needs systematic discovery with evidence, explicit coverage checks, typed relationships, and an optional v0.2 JSON mirror. For existing products, prefer state-audit. Do not treat the four lenses as equivalent state-machine node types or claim exhaustive completeness.

SKILL.md

3.7 KB, as published. Nobody here has run it

Condition Inventory

Create a sourced, saturation-tested inventory. The four lenses compose; they are not equivalent machine-state types.

Procedure

Read STATEFUL.md. Require a human-confirmed system sentence and note the surfaces, evidence, assumptions, and cross-cutting inventory.
Extract the sentence’s structural verbs and time-bearing nouns as the coverage anchor.
List lifecycle states from before/during/after and before/within/beyond probes.
For every lifecycle state or transition, ask what can reject or prevent the next change. Record failures and their cause: user-input, system, external, or policy.
For every lifecycle state, ask what happens when the user leaves, time passes, or actor, device, session, permission, network, dependency, or data changes. Record these as interruption contexts.
Inventory surfaces and their independent content, action, accessibility, freshness, authentication, and privacy constraints.
Connect conditions with typed relationships where evidence supports them:
- transition;
- interrupted-by;
- reenters-as;
- projects-to.
Attach at least one evidence reference to every condition. Use type: assumption when no stronger source exists.
Merge duplicates. Retain specialisations only when behavior or requirements materially differ.
Run the coverage check:
- every structural term generates a lifecycle state or is flagged as decorative;
- every lifecycle state has an explicit failure and interruption answer, including none;
- every surface connects to at least one condition;
- applicable cross-cutting conditions are referenced;
- every condition has evidence or an explicit assumption.
Stop after three successive probes produce only specialisations. Record unconsulted evidence and known unknowns; do not claim completeness.
Update STATEFUL.md with per-lens counts, evidence consulted, assumptions, and known unknowns.
Ask whether the user wants state-map.json. If yes, write a v0.2 working map with schema_version: "0.2", conditions, scenarios: [], relationships, and metadata.maturity: working. New conditions use status: discovered; scope and priority are intentionally absent until triage. Do not use the v0.1 states and transitions fields.

Output

## Lifecycle states
| ID | Condition | Evidence | Why distinct |

## Failures
| ID | Condition | Cause | Evidence | Prevents/rejects |

## Interruptions
| ID | Context | Applies to | Evidence | Re-entry implication |

## Surfaces
| ID | Surface | Presents | Evidence | Independent constraints |

## Relationships
| Type | From | To | Trigger |

## Coverage
- Structural terms: <covered>/<total>
- Lifecycle interrogation: <covered>/<total>
- Surfaces connected: <covered>/<total>
- Evidence: <sourced>/<total>; assumptions: <n>
- Known unknowns: <items>
- Stopping reason: <saturation result>

Failure modes

Calling every record a lifecycle state.
Generating a target number instead of testing coverage.
Treating a surface as a resized screen.
Inventing relationships without evidence.
Using source code as the only account of intended behavior.
Writing triage decisions during discovery.