System sentence

Skill mskayyali/Stateful/skills/system-sentence

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 system-sentence

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

Produce and confirm a structural system sentence describing what a software feature or surface is as an object that exists over time, with enough temporal and lifecycle structure to generate 3–5 materially distinct conditions. Use at the start of Stateful work, when a description is feature-framed or flow-framed, or when an existing-feature audit lacks a clear structural anchor. Do not use for static marketing pages or as generic prompt optimisation.

SKILL.md

2.9 KB, as published. Nobody here has run it

System Sentence

Produce a structural sentence at feature or surface scale. Do not list the full condition map until the user confirms it.

Procedure

Read STATEFUL.md if present. If it already contains a sentence, ask before replacing it.
Classify the input as feature-framed, flow-framed, or structural.
Check altitude. If it describes a whole product, narrow to one feature or surface. Use a separate cross-cutting inventory for recurring product-wide conditions.
Gather only missing raw material in one round:
- time: schedules, windows, deadlines, expiries;
- lifecycle: creation, resolution, cancellation, expiry, supersession, abandonment;
- channels: email, push, other people, devices, or systems;
- completion differences: changed data, actor, session, permission, dependency, or elapsed time;
- surfaces: every place the system presents itself.
Cite the source of each answer when known. Mark unsupported answers as assumptions.
Draft a 15–35 word sentence describing what the system is, not what it helps a user do or the order of steps.
Extract structural verbs and time-bearing nouns. Derive 3–5 materially distinct lifecycle conditions directly from them.
If derivation is thin or relies on facts absent from the sentence, revise the sentence.
Present the sentence, structural terms, derived conditions, evidence/assumptions, and why it works. Stop for confirmation.
After confirmation, update STATEFUL.md with the sentence, raw material, evidence, and known unknowns. Do not start the condition inventory unless the user asks.

Output

Classification: <feature-framed | flow-framed | structural>

Proposed system sentence:
<sentence>

Structural terms:
- <term>

Initial lifecycle conditions:
- <condition>

Evidence and assumptions:
- <source or explicit assumption>

Why it works:
<one or two lines>

Confirm or adjust?

Done gate

The sentence is at feature or surface scale.
Three to five materially distinct conditions derive directly from it.
Sources and assumptions are visible.
A human confirms it before write-back or listing.

Failure modes

Feature language such as “helps,” “lets,” or “allows.”
A sequence disguised as a sentence.
Whole-product altitude.
A sentence that lists states instead of generating them.
Treating assumptions as discovered facts.
Continuing before confirmation.