statechart
Checks a TLA+ model of something that moves between states (a checkout, an upload, a protocol, a job with retries) with the TLC model checker and draws it as a Mermaid statechart in the reader's words, marking each state that breaks a rule and the shortest path to it. Use when asked to 'draw the states', 'chart how this flow works', 'statechart', 'can this ever happen', 'check this flow keeps the rule', 'model the lifecycle', or to show a bug about order, duplicates, retries or late events as a path through states. Declines work with no states, such as a pure function. Not for architecture or sequence diagrams (vd:archify, vd:diagram-design).
Target: Design & content creation. Automatically collected · unverified.
Excerpt from the author’s documentation
Extracted from a fixed version of SKILL.md in its original language. This is the author’s documentation; installation, compatibility and runtime results have not been verified by this site.
Read the original English text
Topics in the source
- statechart
- First: does the work have states?
- Steps
- Brownfield work (from shape)
- Toolchain
- Rules
A chart of how a system moves between states, checked by TLC, in the words of the person who decides whether the behavior is right: the reader. A hand-drawn diagram proves nothing; this one comes from every state the model can reach. SC= /scripts/statechart Use it when the work has three or more states, or a rule about order, duplicates or retries (charged twice, a late webhook, a retry after cancel). Otherwise decline: say the code or flow has no states worth charting (a pure function maps input to output; a single request and reply has no lifecycle), write no model and draw no diagram, and suggest a table of inputs and outputs as tests instead. 1. Name the states and the rules in the reader's words. Rules come from the reader. When you chart code, today's behavior is the code's: read every guard and every path that changes state, and keep what the code does, not what it should do. 2. Write the model in the folder the user names, else a scratch folder outside the repo: Spec.tla and Spec.cfg. Each rule the reader agrees to is an INVARIANT; never weaken one to make it hold. Keep constants small. Read references/spec.md before writing it: Next as a disjunction of named actions, and e
This is an excerpt. Refer to the complete source and its current requirements.
- Source repository
- vanducng/skills
- Source file
- skills/statechart/SKILL.md
- Fixed revision
- c20411b8df8f821988c87689f6aefe142b6f9025
Sources and evidence
This record was collected automatically. Its documentation, suitability and runtime behavior have not been manually verified.
Author: vanducng/skills · original repository metadata. Documentation review: Not reviewed. Last source check: 2026-11-11T14:02:27.577Z.
Categories are inferred from names, descriptions and paths. They do not establish compatibility.
License and attribution
MIT. Third-party content and copyright remain with their authors. Refer to the original license and terms.
Original license ↗Synchronization, copying and user-reported success do not mark a resource as runtime-tested.
Limitations and notes
- Collecting metadata does not mean this site has installed, adapted, runtime-tested or security-reviewed the resource.