diagram-state
Draw the state machine of one entity, with states extracted from its enum, union or constants and each transition cited at the code that performs it or marked inferred. Use for "what states can X be in", "how does X move between them", or before adding a state or transition.
- License 许可
- MIT
- 最近更新
- 2026-11-04
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- diagram-state
- metadata
- { "layer": "L3" }
- description
- Draw the state machine of one entity, with states extracted from its enum, union or constants and each transition cited at the code that performs it or marked inferred. Use for "what states can X be in", "how does X move between them", or before adding a state or transition.
03 SKILL.md 正文
Diagram state
States come from the code that declares them. Transitions come from the code that changes them. A transition you can't point to is inferred, and it must look inferred.
The answer is a page, not a diagram in chat. Before you reply, open diagram-deps and write the page its badge protocol calls Rendering; the reply is the badge, a short summary and the page's path. A request to keep it short or quick shortens the summary, not this step.
1. Find the states
- Find the declaration of the entity's states: an enum, a union type, or a set of constants. Map the entity's domain name to code with
$(ven-profile path)/GLOSSARY.md, then search withven-profile adapter code.search --var pattern=<type or field name>. - List its members with
ven-profile adapter symbols.list --file <path>, which printsname kind line. Each state cites its declaring line. - A state value used in code but missing from the declaration (a bare literal somewhere else) is a finding. Draw it with an
undeclarednote.
On exit 3 from either adapter, read the declaring file and search yourself, per the no-adapter rule of the badge protocol in diagram-deps.
2. Find the transitions
For each state, find every place that sets the entity's state field to it. At each site, read the guard to learn the source state.
- Cited: the site shows the source (a guard, a match arm, a conditional write that filters on the current state) and the target. Cite the line that writes the target.
- Inferred: the target is clear but the source is not (no guard, or a write that accepts any state). Draw it with a
?after its label. - Initial state: where the entity is created or its default is declared. Cite that line on the
[*]edge. - A write that accepts any state is one row under the diagram ("any state → archived"), not an edge from every state.
3. Draw and check
stateDiagram-v2
[*] --> draft: create
draft --> published: publish
published --> archived: archive
draft --> archived: archive ?
Put the claim table that citation-check builds under the diagram: one row per state declaration and per cited transition. Run citation-check. The caption counts transitions: HYBRID (3/4 edges cited) while an inferred edge is on screen.
A saved state diagram has only cited transitions. Before saving per the badge protocol (as state-<entity>), drop each inferred edge from the diagram and list it under "Inferred transitions, not in the diagram" with the line that made you suspect it.
4. Findings
After the diagram, list what the picture reveals:
- States with no incoming transition (unreachable) and states with no outgoing one that are not meant to be final.
- Undeclared states, and transitions that skip a guard the others have.
- Writes that accept any state, since they bypass the machine.
Render it per Rendering in the badge protocol of diagram-deps.
04 同仓库更多 Skills
yeet
Take every local change green through the repo's own checks, slice it into conventional commits, push, and with --pr open a pull request on the code host. Use only when the user explicitly asks to yeet, or to commit and push everything; never on your own initiative.
write-docs
Write or update documentation from the code: gather facts, pick the shape for the reader, write it plain, and prove every command and path in it. Use when asked to document a repo, module or feature, or to bring stale docs up to date.
why
Find why code is shaped the way it is (design rationale, trade-offs, regressions, odd thresholds) from history, tickets, docs and chat, citing every claim and stating its confidence. Use for 'why does X work this way', 'why did we pick Y', or before changing code whose purpose is unclear.
verify
Prove a change works with the check that matches its type, do the read-back, and log the pass against the exact tree. Use when a change is ready to call done, before review, commit or stopping, and whenever ven-decisions end refuses an unverified tree.
unslop
Cut AI writing tells (filler, model vocabulary, metaphor nouns, hedging, formatting tics) from text while keeping every fact. Use when editing or checking any prose before it ships: docs, PR bodies, reports, skill text.
type-discipline
Apply when designing types or data shapes, reviewing a signature, or handling outside data, in any language. Make wrong states fail early: in the compiler for typed languages, in validated runtime contracts for untyped ones.