Skip to content
Back to skills

Stateloom Sequence

ASecurity

Design a sequence diagram (a usage scenario) conversationally through the stateloom MCP tools, as a .sqdf.json beside a system's state machines and ERD. Use when creating or editing a .sqdf.json, calling create_sequence, add_participant, update_participant, rename_participant, move_participant, remove_participant, add_message, update_message, remove_message, move_message, add_fragment, add_fragment_message, remove_fragment or validate_sequence, telling who sends what to whom and in which orde...

  • 4 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 9, 2026
ai-agents

Works with

  • cli
  • mcp

Security analysis

A100/100

Scanned October 9, 2026

npx -y skills add jgwill/miadi-orchestration-kit --skill stateloom-sequence --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Stateloom Sequence?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Stateloom Sequence
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/jgwill-stateloom-sequence/badge)](https://www.skillsdirectory.com/skills/jgwill-stateloom-sequence)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: stateloom-sequence
description: Design a sequence diagram (a usage scenario) conversationally through the stateloom MCP tools, as a .sqdf.json beside a system's state machines and ERD. Use when creating or editing a .sqdf.json, calling create_sequence, add_participant, update_participant, rename_participant, move_participant, remove_participant, add_message, update_message, remove_message, move_message, add_fragment, add_fragment_message, remove_fragment or validate_sequence, telling who sends what to whom and in which order, linking a message to the event it fires, the entity it carries or the state it leads to, writing alt / opt / loop fragments with their branch point, fixing S001-S006 errors, or designing new behaviour by telling it as a scenario first.
---

# Designing a sequence through the MCP tools

A sequence here is a `.sqdf.json` document: **SQDF**, the third document of the loom beside
SMDF (behaviour) and ERDF (data). It tells one usage scenario — who sends what to whom, in
order — and it names what its siblings define, so the loom can check it and walk it through
the machines.

Full specification: `rispecs/81-sqdf-format.spec.md` in `jgwill/smcraft`. The system that
joins a sequence to its machines and its ERD is `rispecs/82-sysdf-system.spec.md` and the
`stateloom-system` skill.

---

## Step 0 — The active document's type is its extension

`.smdf.json` machine, `.erdf.json` ERD, `.sqdf.json` sequence, `.sysdf.json` system. The
sequence tools act while the active document is a `.sqdf.json`. `create_sequence` also moves
the active document there.

```
get_project_file
create_sequence  { "namespace": "shop", "name": "PlaceOrder", "path": "/abs/diagrams/place_order.sqdf.json" }
```

---

## The tools

| Group | Tools |
|---|---|
| Create | `create_sequence(namespace, name, description?, path?, overwrite?)` |
| People and parts | `add_participant(name, actor?, service?, object?, holds?, description?, at?)`, `update_participant`, `rename_participant(name, to)` (every message follows), `move_participant(name, to)` (column, from 1), `remove_participant` (takes its messages with it) |
| The story | `add_message(from, to, label, event?, carries?, state?, machine?, optional?, reply?, at?)`, `update_message(ref, …)`, `remove_message(ref)`, `move_message(ref, to)` |
| Sometimes | `add_fragment(kind, label, after, messages?)`, `add_fragment_message(fragment, …)`, `remove_fragment(fragment)` |
| Check | `validate_sequence()`; the system's checks are `check_system`, `replay_scenario`, `reconcile_scenario` |
| Notes | `get_notes()`, `set_notes(target?, notes)` |

Messages are addressed by **ref**: `"9"` is main message 9, `"f1.2"` the second message of
the first fragment. Fragments are numbered from 1.

---

## What a participant is

Say what each participant IS, because that is what the system checks (L006):

| Field | Meaning | Checked against |
|---|---|---|
| `actor` | a person or an agent | the system's `actors` |
| `service` | a running service, free text | nothing — a label |
| `object` | the participant IS a machine's object (`settings.objects[].instance`) | the member machines |
| `holds` | entities it keeps | the ERD |

---

## What a message does

A message may do any of these, or none:

- **`event`** — fires that event in every member machine that defines it (only in `machine`,
  when several define it). Checked by L005, walked by the replay.
- **`carries`** — the entity it moves. Checked by L007.
- **`state`** — the state the machine is in once it is handled. The replay checks it, and
  **it is what lets reconcile add a transition** the machine lacks. When you invent a new
  behaviour, always say where it leads.
- **`optional`** — the scenario holds with or without it. The replay walks a second path
  without optional messages; if the rest depends on one, it is reported as not optional.
- **`reply`** — drawn dashed.

A message that only moves data or computes fires no event. That is normal.

---

## Fragments: say where the alternative begins

```
add_fragment { "kind": "alt", "label": "card declined", "after": 2,
               "messages": [ { "from": "Bank", "to": "Shop", "label": "declined", "event": "Decline" } ] }
```

- `alt` — **instead of** the main messages after `after`
- `opt` — may happen after `after`; the main messages continue
- `loop` — repeats after `after`; the main messages continue

`after` is a main message number (`0` = before the first). Inserting, removing or moving a
main message keeps each fragment on the message it branches after.

---

## Designing new behaviour by telling it

This is the loop the system exists for. In a system (see `stateloom-system`):

1. `add_message` with a **new event** and the **state** it leads to.
2. If the system's reconcile mode is **`auto`**, the tool already applied what the story
   implies — the event, the state, the transition, a carried entity — and its answer ends with
   one line such as `auto: OrderLifecycle +2, ShopData +1`. The person opening the machine
   finds it updated. Nothing to approve.
3. If the mode is **`propose`**, the answer ends with `N changes proposed`; run
   `reconcile_scenario` to read them and `reconcile_scenario { "apply": true }` to apply.
4. What the story does not say (a refusal with no `state`, a `state` that contradicts the
   machine) comes back as **left open**, in words. Decide, or ask the person.

---

## Rule errors

| Rule | Means | Fix |
|---|---|---|
| S001 | no `settings.name` | `create_sequence` sets it |
| S002 | a participant with no name, or twice | rename one |
| S003 | a message from or to someone who is not a participant | `add_participant` first |
| S004 | a message with no label | say what happens, in a few words |
| S005 | fragment kind unknown, or `after` outside the main messages | `alt`/`opt`/`loop`, and `after` ≤ the count |
| S006 | a fragment with no message | add one, or remove the fragment |

---

## Drawing it

`render_diagram` writes a Mermaid `sequenceDiagram` (`<name>.seq.mmd`): actors as actors,
the event after each label, optional messages in `opt`, an `alt` at its branch point with an
`else as written` holding the path it replaces. On the live canvas the sequence opens in its
own workspace; in a system, the strip at the top switches to the machines and the ERD.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.