AGENT SKILL

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

  1. 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 with ven-profile adapter code.search --var pattern=<type or field name>.
  2. List its members with ven-profile adapter symbols.list --file <path>, which prints name kind line. Each state cites its declaring line.
  3. A state value used in code but missing from the declaration (a bare literal somewhere else) is a finding. Draw it with an undeclared note.

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

Ventorius
Ventorius/ven-stack

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.

★ 0
Ventorius
Ventorius/ven-stack

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.

★ 0
Ventorius
Ventorius/ven-stack

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.

★ 0
Ventorius
Ventorius/ven-stack

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.

★ 0
Ventorius
Ventorius/ven-stack

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.

★ 0
Ventorius
Ventorius/ven-stack

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.

★ 0