sad-mcp 0.1.23 → 0.1.25
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/prompts.js +10 -1
- package/package.json +1 -1
- package/skills/bpmn-diagram/SKILL.backup.md +359 -0
- package/skills/bpmn-diagram/SKILL.md +82 -274
- package/skills/bpmn-render/SKILL.md +187 -0
package/dist/prompts.js
CHANGED
|
@@ -26,6 +26,14 @@ const SKILLS = [
|
|
|
26
26
|
description: "Create BPMN business process diagrams as interactive HTML/SVG files",
|
|
27
27
|
},
|
|
28
28
|
];
|
|
29
|
+
// Internal skills: loadable via GetPrompt but not shown in ListPrompts
|
|
30
|
+
const INTERNAL_SKILLS = [
|
|
31
|
+
{
|
|
32
|
+
id: "bpmn-render",
|
|
33
|
+
name: "BPMN Render",
|
|
34
|
+
description: "Internal: Render an approved BPMN structural model as HTML/SVG",
|
|
35
|
+
},
|
|
36
|
+
];
|
|
29
37
|
function loadSkill(skillId) {
|
|
30
38
|
const skillsDir = join(__dirname, "..", "skills");
|
|
31
39
|
return readFileSync(join(skillsDir, skillId, "SKILL.md"), "utf-8");
|
|
@@ -38,7 +46,8 @@ export function registerPromptHandlers(server) {
|
|
|
38
46
|
})),
|
|
39
47
|
}));
|
|
40
48
|
server.setRequestHandler(GetPromptRequestSchema, async (request) => {
|
|
41
|
-
const skill = SKILLS.find((s) => s.id === request.params.name)
|
|
49
|
+
const skill = SKILLS.find((s) => s.id === request.params.name) ||
|
|
50
|
+
INTERNAL_SKILLS.find((s) => s.id === request.params.name);
|
|
42
51
|
if (!skill) {
|
|
43
52
|
throw new Error(`Unknown skill: ${request.params.name}`);
|
|
44
53
|
}
|
package/package.json
CHANGED
|
@@ -0,0 +1,359 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: bpmn-diagram
|
|
3
|
+
description: Create BPMN (Business Process Model and Notation) diagrams as interactive HTML/SVG files. Use this skill when the user asks to create, model, or visualize a business process, workflow diagram, BPMN diagram, or process map. Handles Hebrew RTL processes, swim lanes, pools, gateways, data objects, data stores, message flows, and intermediate events. Outputs a single self-contained HTML file with embedded SVG.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# BPMN Diagram Creation Skill
|
|
7
|
+
|
|
8
|
+
This skill creates professional BPMN 1.1 diagrams rendered as interactive HTML files with embedded SVG. The diagrams support Hebrew (RTL) and English text.
|
|
9
|
+
|
|
10
|
+
**This skill operates in 3 phases. You MUST complete each phase fully before moving to the next.**
|
|
11
|
+
|
|
12
|
+
## NON-NEGOTIABLE RULES — READ BEFORE ANYTHING ELSE
|
|
13
|
+
|
|
14
|
+
These rules are violated most often. You MUST follow every one. No exceptions.
|
|
15
|
+
|
|
16
|
+
1. **GATEWAYS**: The diamond shape contains ONLY a marker symbol: **X** (XOR), **+** (AND), or **O** (OR). NEVER put text/labels inside the diamond. Labels go ABOVE the diamond. Every gateway (split AND merge) must have its marker.
|
|
17
|
+
|
|
18
|
+
2. **CUSTOMERS / EXTERNAL PARTIES get their own POOL**: If a customer, patient, citizen, or external company (e.g., חברת אשראי, ספק) acts independently — they are a SEPARATE POOL with message flows (dashed lines) between pools. They are NOT a lane. The only exception: if the organization fully controls the participant's actions within its system (e.g., customer using a bank app).
|
|
19
|
+
|
|
20
|
+
3. **DATA STORES are mandatory**: If any task involves "block account", "generate invoice", "credit account", "update record", "register", "look up", or any read/write to persistent state — you MUST draw a Data Store (cylinder) with data associations connecting it to the relevant tasks.
|
|
21
|
+
|
|
22
|
+
4. **NO ELEMENTS ON LANE BOUNDARIES**: Every task, gateway, and event must be fully inside one lane, centered vertically with clear spacing from lane borders.
|
|
23
|
+
|
|
24
|
+
5. **EVERY PARTICIPANT MUST APPEAR**: If the process description mentions a customer/patient/company — they MUST appear in the diagram. Never omit a participant.
|
|
25
|
+
|
|
26
|
+
## When to Use
|
|
27
|
+
|
|
28
|
+
- User asks to create a BPMN diagram, process model, or workflow diagram
|
|
29
|
+
- User describes a business process and wants it visualized
|
|
30
|
+
- User provides a process narrative in any language and wants a BPMN representation
|
|
31
|
+
- User asks to model a process with swim lanes, pools, gateways, or data flows
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
# ═══════════════════════════════════════════════════
|
|
36
|
+
# PHASE 1 — STRUCTURAL MODEL (text only, NO SVG)
|
|
37
|
+
# ═══════════════════════════════════════════════════
|
|
38
|
+
|
|
39
|
+
In this phase you analyze the process description and output a structured text model. Do NOT write any HTML, SVG, or code. Only text analysis.
|
|
40
|
+
|
|
41
|
+
## Step 1.1 — Identify Participants
|
|
42
|
+
|
|
43
|
+
List every actor/role mentioned in the process. For each one, classify as POOL or LANE:
|
|
44
|
+
|
|
45
|
+
- **POOL** (separate, independent): The participant acts on their own initiative and communicates with the organization from outside. Examples: a customer calling to cancel, a patient arriving at a clinic, a citizen filing a complaint, an external company (credit card company, supplier, contractor).
|
|
46
|
+
- **LANE** (within org pool): The participant is an internal role within the organization, OR the organization fully dictates and controls how they perform activities within its system (e.g., customer using the bank's app).
|
|
47
|
+
- **The test**: "Does the organization orchestrate this participant's actions, or do they act independently?" Independent → POOL.
|
|
48
|
+
|
|
49
|
+
## Step 1.2 — Identify Tasks
|
|
50
|
+
|
|
51
|
+
List every action/task mentioned in the process description. For each task, specify which lane or pool it belongs to. Also identify implied activities — phrases like "she can and is expected to be in phone contact" or "will coordinate directly" describe real tasks, NOT annotations.
|
|
52
|
+
|
|
53
|
+
## Step 1.3 — Identify Gateways (with type!)
|
|
54
|
+
|
|
55
|
+
List every decision point / conditional branch. For each gateway, specify:
|
|
56
|
+
- **Type**: XOR (exclusive — only one path), AND (parallel — all paths), or OR (inclusive — one or more paths)
|
|
57
|
+
- **Question/condition**: What is being decided
|
|
58
|
+
- **Outgoing branches**: The possible outcomes and where each leads
|
|
59
|
+
- **Merge**: Where the branches reconverge (if applicable) — merge gateways must also be listed with their type
|
|
60
|
+
|
|
61
|
+
## Step 1.4 — Identify Data Stores
|
|
62
|
+
|
|
63
|
+
Scan all tasks for persistent storage operations. **Trigger words**: "system", "database", "account", "record", "registry". **Action verbs**: "block account", "update record", "generate invoice", "credit account", "register", "log", "store", "look up", "check status".
|
|
64
|
+
|
|
65
|
+
If ANY task reads from or writes to shared persistent state → Data Store is required. A system = a data store. An account = a data store.
|
|
66
|
+
|
|
67
|
+
List each data store with a name and which tasks connect to it (read/write).
|
|
68
|
+
|
|
69
|
+
## Step 1.5 — Identify Data Objects
|
|
70
|
+
|
|
71
|
+
List specific pieces of data that flow between tasks (e.g., "בקשת ביטול", "חשבונית זיכוי"). These are different from data stores — data objects are transient documents, not persistent systems.
|
|
72
|
+
|
|
73
|
+
## Step 1.6 — Identify Flows
|
|
74
|
+
|
|
75
|
+
- **Sequence flows** (within a pool/between lanes): List the order of tasks within each pool
|
|
76
|
+
- **Message flows** (between pools): List every communication between separate pools. Check for bidirectional communication — every message that expects a response needs a return message flow.
|
|
77
|
+
- **Data associations**: List connections between tasks and data stores / data objects.
|
|
78
|
+
|
|
79
|
+
## Step 1.7 — Identify Events
|
|
80
|
+
|
|
81
|
+
- **Start events**: One per pool
|
|
82
|
+
- **End events**: One or more per pool (for different outcomes)
|
|
83
|
+
- **Intermediate events**: Use for passive waiting (not tasks). When a participant is waiting for a signal/message from another participant.
|
|
84
|
+
|
|
85
|
+
## Step 1.8 — Complete Each Participant's Flow
|
|
86
|
+
|
|
87
|
+
Verify that every pool has a complete internal sequence flow: start → tasks/gateways → end. Even external parties must have their full process modeled (receive → process → respond → close), not just a single task.
|
|
88
|
+
|
|
89
|
+
## Required Output Format
|
|
90
|
+
|
|
91
|
+
```
|
|
92
|
+
STRUCTURAL MODEL:
|
|
93
|
+
|
|
94
|
+
POOLS:
|
|
95
|
+
- [Pool name] — [reason: acts independently / external company]
|
|
96
|
+
Tasks: [task1] → [task2] → ...
|
|
97
|
+
Start: [description]
|
|
98
|
+
End(s): [description(s)]
|
|
99
|
+
|
|
100
|
+
ORGANIZATION POOL: [org name]
|
|
101
|
+
LANE: [lane name]
|
|
102
|
+
Tasks: [task1] → [task2] → ...
|
|
103
|
+
LANE: [lane name]
|
|
104
|
+
Tasks: ...
|
|
105
|
+
Start: [description]
|
|
106
|
+
End(s): [description(s)]
|
|
107
|
+
|
|
108
|
+
GATEWAYS:
|
|
109
|
+
- [G1] Type: XOR | Question: [question] | In: [lane/pool] | Branches: [branch1 → ..., branch2 → ...]
|
|
110
|
+
- [G2] Type: XOR (merge) | In: [lane/pool] | Merges: [branches from G1]
|
|
111
|
+
- ...
|
|
112
|
+
|
|
113
|
+
DATA STORES:
|
|
114
|
+
- [Store name] — reads: [task X, task Y] | writes: [task Z]
|
|
115
|
+
- ...
|
|
116
|
+
|
|
117
|
+
DATA OBJECTS:
|
|
118
|
+
- [Object name] — from: [task X] → to: [task Y]
|
|
119
|
+
- ...
|
|
120
|
+
|
|
121
|
+
MESSAGE FLOWS:
|
|
122
|
+
- [Pool A] → [Pool B]: [what is communicated]
|
|
123
|
+
- [Pool B] → [Pool A]: [response]
|
|
124
|
+
- ...
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
## ⛔ HARD STOP — DO NOT PROCEED
|
|
128
|
+
|
|
129
|
+
**STOP HERE.** Present the structural model above to the user. Do NOT write any HTML, SVG, or code yet.
|
|
130
|
+
|
|
131
|
+
Ask the user: "הנה המודל המבני של התהליך. האם לעבור לשלב הבא ולייצר את הדיאגרמה, או שיש שינויים שתרצה לבצע?"
|
|
132
|
+
|
|
133
|
+
Wait for the user to confirm or request changes. If they request changes, revise the model and present it again. Only proceed to Phase 2 after explicit user confirmation.
|
|
134
|
+
|
|
135
|
+
---
|
|
136
|
+
|
|
137
|
+
# ═══════════════════════════════════════════════════
|
|
138
|
+
# PHASE 2 — SVG RENDERING (only after Phase 1 approval)
|
|
139
|
+
# ═══════════════════════════════════════════════════
|
|
140
|
+
|
|
141
|
+
Take the approved structural model from Phase 1 and render it as an HTML file with embedded SVG. **Every participant, task, gateway, data store, data object, and flow from the approved model MUST appear in the SVG.** Do not add or remove elements.
|
|
142
|
+
|
|
143
|
+
## Architecture & Layout
|
|
144
|
+
|
|
145
|
+
### Pools and Lanes
|
|
146
|
+
|
|
147
|
+
- **External participant pools** get their own pool rectangle, visually separated from the organization pool
|
|
148
|
+
- Use a distinct color scheme for external pool headers (e.g., brown) to differentiate from the organization pool (dark gray)
|
|
149
|
+
- External pool tasks use a warm color (e.g., orange `#fff3e0` fill, `#e65100` stroke)
|
|
150
|
+
- **Organization pool** contains internal lanes
|
|
151
|
+
- Each lane gets a labeled sidebar and a subtle background tint
|
|
152
|
+
- Separate lanes with dashed divider lines
|
|
153
|
+
- Pool headers are vertical text bars on the left side of the pool
|
|
154
|
+
|
|
155
|
+
### Element Placement
|
|
156
|
+
|
|
157
|
+
**Every BPMN element (task, gateway, event) must be fully contained within a single lane or pool.** No element may overlap a lane divider line or sit on the boundary between two lanes. Center elements vertically within their lane with visible spacing from borders.
|
|
158
|
+
|
|
159
|
+
### Color Scheme
|
|
160
|
+
|
|
161
|
+
| Element | Fill | Stroke |
|
|
162
|
+
|---------|------|--------|
|
|
163
|
+
| External participant tasks | `#fff3e0` | `#e65100` |
|
|
164
|
+
| Reception/admin tasks | `#e3f2fd` | `#1976d2` |
|
|
165
|
+
| Clinical/operational tasks | `#f3e5f5` | `#7b1fa2` |
|
|
166
|
+
| XOR Gateways | `#fff8e1` | `#f9a825` |
|
|
167
|
+
| Start event | `#e8f5e9` | `#2e7d32` |
|
|
168
|
+
| End event | `#ffebee` | `#c62828` |
|
|
169
|
+
| Data objects | `#fff` | `#1565c0` |
|
|
170
|
+
| Data stores | `#fff` | `#2e7d32` |
|
|
171
|
+
|
|
172
|
+
### Pool Ordering
|
|
173
|
+
|
|
174
|
+
When multiple external pools exist, order to **minimize message flow crossing distance**:
|
|
175
|
+
- Place the primary actor (initiates and interacts with multiple parties) in the middle
|
|
176
|
+
- Place pools they interact with above and below
|
|
177
|
+
|
|
178
|
+
### Flow Types
|
|
179
|
+
|
|
180
|
+
- **Sequence flows** (within a pool): Solid lines with filled arrowheads (`#546e7a`)
|
|
181
|
+
- **Message flows** (between pools): Dashed lines (`stroke-dasharray: 10 5`) with open circle at source and filled arrow at target (`#37474f`)
|
|
182
|
+
- **Data associations**: Dashed lines (`stroke-dasharray: 4 3`) with small arrowheads:
|
|
183
|
+
- Data object associations: `#7986cb`
|
|
184
|
+
- Data store associations: `#4caf50`
|
|
185
|
+
|
|
186
|
+
## BPMN Element SVG Templates
|
|
187
|
+
|
|
188
|
+
### Gateways
|
|
189
|
+
|
|
190
|
+
**Gateway diamonds contain ONLY the marker symbol — NEVER text.** Labels go ABOVE the diamond.
|
|
191
|
+
|
|
192
|
+
```svg
|
|
193
|
+
<!-- XOR Gateway (split or merge) — X marker inside -->
|
|
194
|
+
<rect x="X" y="Y" width="34" height="34" class="gateway" transform="rotate(45, CX, CY)"/>
|
|
195
|
+
<line x1="CX-7" y1="CY-10" x2="CX+7" y2="CY+10" class="gateway-x"/>
|
|
196
|
+
<line x1="CX+7" y1="CY-10" x2="CX-7" y2="CY+10" class="gateway-x"/>
|
|
197
|
+
<text x="CX" y="CY-25" text-anchor="middle">label ABOVE</text>
|
|
198
|
+
```
|
|
199
|
+
|
|
200
|
+
**Anti-pattern — NEVER do this:**
|
|
201
|
+
```svg
|
|
202
|
+
<!-- WRONG: text inside gateway diamond -->
|
|
203
|
+
<polygon points="..." fill="..." stroke="..."/>
|
|
204
|
+
<text x="CX" y="CY">כמה ימים?</text> <!-- FORBIDDEN -->
|
|
205
|
+
```
|
|
206
|
+
|
|
207
|
+
### Intermediate Events (BPMN 1.1 style)
|
|
208
|
+
|
|
209
|
+
Plain double circle with NO icon inside:
|
|
210
|
+
|
|
211
|
+
```svg
|
|
212
|
+
<circle cx="X" cy="Y" r="16" fill="#fff" stroke="#1565c0" stroke-width="2"/>
|
|
213
|
+
<circle cx="X" cy="Y" r="12" fill="none" stroke="#1565c0" stroke-width="1.2"/>
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
### Data Objects (folded-corner document, blue)
|
|
217
|
+
|
|
218
|
+
```svg
|
|
219
|
+
<path d="M X,Y L X+26,Y L X+34,Y+8 L X+34,Y+38 L X,Y+38 Z" class="data-object-shape"/>
|
|
220
|
+
<path d="M X+26,Y L X+26,Y+8 L X+34,Y+8" class="data-object-fold"/>
|
|
221
|
+
```
|
|
222
|
+
|
|
223
|
+
### Data Stores (cylinder, green)
|
|
224
|
+
|
|
225
|
+
```svg
|
|
226
|
+
<ellipse cx="CX" cy="TOP" rx="28" ry="8" class="data-store-body"/>
|
|
227
|
+
<path d="M CX-28,TOP L CX-28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
|
|
228
|
+
<path d="M CX+28,TOP L CX+28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
|
|
229
|
+
<ellipse cx="CX" cy="BOTTOM" rx="28" ry="8" class="data-store-body"/>
|
|
230
|
+
```
|
|
231
|
+
|
|
232
|
+
### Data Artifact Placement
|
|
233
|
+
|
|
234
|
+
- Place data objects above or below their associated task, never overlapping flow lines
|
|
235
|
+
- Place data stores typically below their associated tasks
|
|
236
|
+
- Never place data artifacts where association lines cross sequence flow arrows
|
|
237
|
+
|
|
238
|
+
## Arrow Routing
|
|
239
|
+
|
|
240
|
+
**Arrows must never be ambiguous.**
|
|
241
|
+
|
|
242
|
+
### Split-Merge Pattern
|
|
243
|
+
|
|
244
|
+
1. YES task above the gateway's horizontal center line
|
|
245
|
+
2. NO task below
|
|
246
|
+
3. Merge gateway clearly to the right of BOTH tasks
|
|
247
|
+
4. YES path: task → right → down into merge (entering from top)
|
|
248
|
+
5. NO path: task → right → up into merge (entering from bottom)
|
|
249
|
+
6. From merge: single clean line to next task
|
|
250
|
+
|
|
251
|
+
### General Routing Rules
|
|
252
|
+
|
|
253
|
+
- Prefer orthogonal (right-angle) routing
|
|
254
|
+
- Leave at least 30px spacing between parallel flow lines
|
|
255
|
+
- Cross-lane flows use clear vertical drops/rises
|
|
256
|
+
- Label YES/NO (כן/לא) near the gateway, not at the end of the path
|
|
257
|
+
- Flow labels must not overlap other elements
|
|
258
|
+
|
|
259
|
+
## Modeling Rejection/Retry Loops
|
|
260
|
+
|
|
261
|
+
1. Model rejection as an explicit task (not just a gateway output)
|
|
262
|
+
2. After rejection, model the rejecting participant's next state (waiting/action)
|
|
263
|
+
3. Model the response to rejection as a concrete task sequence
|
|
264
|
+
4. Loop-back arrows return to the earliest meaningful re-entry point
|
|
265
|
+
|
|
266
|
+
## Typography & Hebrew
|
|
267
|
+
|
|
268
|
+
- Use `Noto Sans Hebrew` (imported from Google Fonts) for all text
|
|
269
|
+
- Set `lang="he"` and `dir="rtl"` on the HTML element
|
|
270
|
+
- Task text: 11.5px, font-weight 500, centered
|
|
271
|
+
- Gateway labels: 10.5px, font-weight 400, positioned above the diamond
|
|
272
|
+
- Data labels: 9.5px, font-weight 500
|
|
273
|
+
- Flow labels: 10px
|
|
274
|
+
|
|
275
|
+
## File Structure
|
|
276
|
+
|
|
277
|
+
Output a single self-contained HTML file with:
|
|
278
|
+
|
|
279
|
+
1. **Header bar**: Gradient background with process title in Hebrew + English subtitle. Must say "BPMN 1.1" (NOT 2.0)
|
|
280
|
+
2. **Legend**: Horizontal bar showing all BPMN symbols used (start, end, task, XOR gateway, intermediate event, data object, data store, message flow)
|
|
281
|
+
3. **SVG canvas**: The full BPMN diagram in a scrollable wrapper
|
|
282
|
+
4. **SVG definitions**: Drop shadow filters, arrow markers (sequence, message, data association)
|
|
283
|
+
|
|
284
|
+
### SVG Sizing
|
|
285
|
+
|
|
286
|
+
- Width: 1700–1800px typical (allow overflow scroll)
|
|
287
|
+
- Height: Scale based on pools and lanes (~130px per external pool, ~250px per lane, plus data artifacts)
|
|
288
|
+
- Use `viewBox` matching width/height
|
|
289
|
+
|
|
290
|
+
---
|
|
291
|
+
|
|
292
|
+
# ═══════════════════════════════════════════════════
|
|
293
|
+
# PHASE 3 — VALIDATION & FIX
|
|
294
|
+
# ═══════════════════════════════════════════════════
|
|
295
|
+
|
|
296
|
+
**Before delivering the diagram, go through EVERY item below. If ANY item fails, fix the SVG immediately. Do NOT deliver until all pass.**
|
|
297
|
+
|
|
298
|
+
## Structural Accuracy (cross-reference with Phase 1 model)
|
|
299
|
+
- [ ] Every participant from the Phase 1 model appears in the SVG — none are omitted
|
|
300
|
+
- [ ] External participants are in separate pools with message flows (not lanes with sequence flows)
|
|
301
|
+
- [ ] Every pool has a complete internal flow (start → ... → end)
|
|
302
|
+
- [ ] Every gateway from Phase 1 appears with the correct type marker
|
|
303
|
+
- [ ] Every data store from Phase 1 appears as a cylinder with data associations
|
|
304
|
+
- [ ] Every message flow from Phase 1 appears as a dashed line between pools
|
|
305
|
+
|
|
306
|
+
## BPMN Compliance
|
|
307
|
+
- [ ] Every gateway (split AND merge) has ONLY an X/+/O marker inside — no text inside the diamond
|
|
308
|
+
- [ ] Gateway labels are positioned ABOVE or BESIDE the diamond, never inside
|
|
309
|
+
- [ ] Every element (task, gateway, event) is fully inside a single lane — nothing sits on a lane boundary
|
|
310
|
+
- [ ] Passive waiting uses intermediate events, not regular tasks
|
|
311
|
+
- [ ] Data objects (folded document) and data stores (cylinder) use different icons
|
|
312
|
+
|
|
313
|
+
## Visual Quality
|
|
314
|
+
- [ ] No arrow paths overlap or cross ambiguously
|
|
315
|
+
- [ ] Flow labels (כן/לא) are clearly positioned near their gateway
|
|
316
|
+
- [ ] The legend includes every symbol type used in the diagram
|
|
317
|
+
- [ ] Data artifacts don't overlap with sequence flow paths
|
|
318
|
+
- [ ] Pool ordering minimizes message flow crossing distance
|
|
319
|
+
|
|
320
|
+
---
|
|
321
|
+
|
|
322
|
+
# APPENDIX
|
|
323
|
+
|
|
324
|
+
## Example Process Categories
|
|
325
|
+
|
|
326
|
+
This skill handles processes such as:
|
|
327
|
+
- Healthcare workflows (e.g., Tipat Halav clinic visits, hospital admissions)
|
|
328
|
+
- Government/municipal service processes
|
|
329
|
+
- Customer service and support flows
|
|
330
|
+
- Order fulfillment and logistics
|
|
331
|
+
- Employee onboarding
|
|
332
|
+
- Academic/educational administration processes
|
|
333
|
+
|
|
334
|
+
The skill works for any domain — adapt the color scheme and terminology to match the context.
|
|
335
|
+
|
|
336
|
+
## Hebrew Language Guidelines (שפה מגדרית נייטרלית)
|
|
337
|
+
|
|
338
|
+
When labels, names, actors, roles, or any text in the diagram are written in Hebrew, follow these rules:
|
|
339
|
+
|
|
340
|
+
### Use Male Form as Default
|
|
341
|
+
Always use the **male grammatical form** (זכר) when referring to people, roles, actors, classes, or participants — even when the role is traditionally associated with a specific gender.
|
|
342
|
+
|
|
343
|
+
**Examples of correct usage:**
|
|
344
|
+
- ✅ רופא (not אחות for a nurse role — use אח)
|
|
345
|
+
- ✅ אח (nurse, male form)
|
|
346
|
+
- ✅ מטופל (not מטופלת)
|
|
347
|
+
- ✅ לקוח (not לקוחה)
|
|
348
|
+
- ✅ מנהל (not מנהלת)
|
|
349
|
+
- ✅ עובד (not עובדת)
|
|
350
|
+
- ✅ משתמש (not משתמשת)
|
|
351
|
+
- ✅ סטודנט (not סטודנטית)
|
|
352
|
+
|
|
353
|
+
**Examples of stereotypic writing to avoid:**
|
|
354
|
+
- ❌ רופא ואחות — implies doctor=male, nurse=female
|
|
355
|
+
- ❌ מזכירה — use מזכיר instead
|
|
356
|
+
- ❌ אחות — use אח instead
|
|
357
|
+
|
|
358
|
+
### Rule Summary
|
|
359
|
+
> When in doubt, use the male form. This ensures gender neutrality and avoids reinforcing occupational gender stereotypes in diagram content.
|
|
@@ -1,317 +1,125 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: bpmn-diagram
|
|
3
|
-
description: Create BPMN (Business Process Model and Notation) diagrams as interactive HTML/SVG files. Use this skill when the user asks to create, model, or visualize a business process, workflow diagram, BPMN diagram, or process map.
|
|
3
|
+
description: Create BPMN (Business Process Model and Notation) diagrams as interactive HTML/SVG files. Use this skill when the user asks to create, model, or visualize a business process, workflow diagram, BPMN diagram, or process map. This is Phase 1 — structural modeling. It outputs a text model for user review before rendering.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# BPMN Diagram Creation
|
|
6
|
+
# BPMN Diagram Creation — Phase 1: Structural Model
|
|
7
7
|
|
|
8
|
-
This skill creates professional BPMN 1.1 diagrams
|
|
8
|
+
This skill creates professional BPMN 1.1 diagrams in two steps. **This is Step 1 — you will build a structural text model only. No HTML, no SVG, no code.**
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
After the user approves the model, you will use the `bpmn-render` prompt to generate the visual diagram.
|
|
11
11
|
|
|
12
|
-
|
|
12
|
+
## CRITICAL RULES
|
|
13
13
|
|
|
14
|
-
1. **GATEWAYS
|
|
14
|
+
1. **GATEWAYS have types**: Every gateway must be classified as XOR (exclusive), AND (parallel), or OR (inclusive). This determines the marker (X / + / O) drawn inside the diamond later.
|
|
15
15
|
|
|
16
|
-
2. **CUSTOMERS / EXTERNAL PARTIES get their own POOL**: If a customer, patient, citizen, or external company (e.g., חברת אשראי, ספק) acts independently — they are a SEPARATE POOL with message flows
|
|
16
|
+
2. **CUSTOMERS / EXTERNAL PARTIES get their own POOL**: If a customer, patient, citizen, or external company (e.g., חברת אשראי, ספק) acts independently — they are a SEPARATE POOL with message flows. They are NOT a lane. The only exception: if the organization fully controls the participant's actions within its system (e.g., customer using a bank app).
|
|
17
17
|
|
|
18
|
-
3. **DATA STORES are mandatory**: If any task involves "block account", "generate invoice", "credit account", "update record", "register", "look up", or any read/write to persistent state —
|
|
18
|
+
3. **DATA STORES are mandatory**: If any task involves "block account", "generate invoice", "credit account", "update record", "register", "look up", or any read/write to persistent state — a Data Store is required with data associations to the relevant tasks.
|
|
19
19
|
|
|
20
|
-
4. **
|
|
20
|
+
4. **EVERY PARTICIPANT MUST APPEAR**: If the process description mentions a customer/patient/company — they MUST appear in the model. Never omit a participant.
|
|
21
21
|
|
|
22
|
-
|
|
22
|
+
## Step 1 — Identify Participants
|
|
23
23
|
|
|
24
|
-
|
|
24
|
+
List every actor/role mentioned. For each, classify as POOL or LANE:
|
|
25
25
|
|
|
26
|
-
|
|
26
|
+
- **POOL** (separate): The participant acts independently and communicates with the organization from outside. Examples: customer calling to cancel, patient arriving at a clinic, citizen filing a complaint, external company (credit card company, supplier, contractor).
|
|
27
|
+
- **LANE** (within org pool): Internal role within the organization, OR the organization fully dictates how the participant performs activities within its system.
|
|
28
|
+
- **The test**: "Does the organization orchestrate this participant's actions, or do they act independently?" Independent → POOL.
|
|
27
29
|
|
|
28
|
-
|
|
29
|
-
- User describes a business process and wants it visualized
|
|
30
|
-
- User provides a process narrative in any language and wants a BPMN representation
|
|
31
|
-
- User asks to model a process with swim lanes, pools, gateways, or data flows
|
|
30
|
+
## Step 2 — Identify Tasks
|
|
32
31
|
|
|
33
|
-
|
|
32
|
+
List every action/task. For each task, specify which lane or pool it belongs to.
|
|
34
33
|
|
|
35
|
-
|
|
34
|
+
Look for implied activities — phrases like "is expected to be in phone contact" or "will coordinate directly" describe real tasks, not annotations.
|
|
36
35
|
|
|
37
|
-
|
|
38
|
-
- If the participant acts **independently** and communicates with the organization from outside (e.g., a customer calling to cancel a subscription, a patient arriving at a clinic, a citizen filing a complaint, an external company like a credit card company or supplier) → **separate pool** with message flows
|
|
39
|
-
- If the organization **dictates and controls** how the participant performs their activities within its own system (e.g., a customer using the bank's app to make a transaction, a user following a guided online workflow) → **lane** within the organization pool with sequence flows
|
|
40
|
-
- Internal roles within the same organization → **lanes** within one pool
|
|
41
|
-
- **The test**: "Does the organization orchestrate this participant's actions, or do they act on their own initiative?" If they act independently → separate pool
|
|
42
|
-
2. **Activities/Tasks**: List every action/task mentioned
|
|
43
|
-
3. **Decision Points**: Identify every conditional branch (if/else, exists/doesn't exist)
|
|
44
|
-
4. **Data**: What information is created, read, updated, or stored?
|
|
45
|
-
5. **Handoffs**: Where does work pass between participants? These become message flows between pools or sequence flows between lanes
|
|
46
|
-
6. **Waiting Points**: Is any participant passively waiting? Use intermediate events, not regular tasks
|
|
47
|
-
7. **Data Persistence — CRITICAL**: Model a Data Store whenever the process involves persistent storage. **Trigger words** that require a data store: "system", "database", "account", "record", "registry". **Action verbs** that imply a data store: "block account", "update record", "generate invoice", "credit account", "register", "log", "store", "look up", "check status". If a task reads from or writes to shared persistent state, it MUST have a data association to a data store. Do NOT substitute a lightweight Data Object when persistent shared storage is implied. A system = a data store. An account = a data store.
|
|
48
|
-
8. **Complete Each Participant's Flow**: Every pool must have its own complete internal sequence flow (start → tasks → end), even for external parties. If the description says "Company X will handle the complaint," model the full handling sequence inside that pool (receive → process → respond → close), not just the first step. Never collapse an external participant's process into a single task or annotation.
|
|
49
|
-
9. **Bidirectional Communication**: When one participant sends something to another, check: does the receiver send something back? Every message flow that triggers a response must have a corresponding return message flow. Model both directions explicitly. Common pairs: request→acknowledgment, notification→confirmation, complaint→response.
|
|
50
|
-
10. **Implied Activities**: Read the description for activities that are described but not explicitly named as "tasks." Phrases like "she can and is expected to be in phone contact" or "will coordinate directly" describe real activities that should be modeled as tasks, NOT as text annotations. Annotations are only for meta-information that clarifies context but isn't an executable step.
|
|
36
|
+
## Step 3 — Identify Gateways (with type!)
|
|
51
37
|
|
|
52
|
-
|
|
38
|
+
List every decision point. For each gateway specify:
|
|
39
|
+
- **Type**: XOR (only one path taken), AND (all paths taken in parallel), or OR (one or more paths)
|
|
40
|
+
- **Question/condition**: What is being decided
|
|
41
|
+
- **Branches**: The possible outcomes and where each leads
|
|
42
|
+
- **Merge**: Where branches reconverge — merge gateways must also be listed with their type
|
|
53
43
|
|
|
54
|
-
|
|
44
|
+
## Step 4 — Identify Data Stores
|
|
55
45
|
|
|
56
|
-
|
|
46
|
+
Scan all tasks for persistent storage operations.
|
|
57
47
|
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
1. PARTICIPANTS:
|
|
62
|
-
- [Name] → POOL (acts independently: [reason]) / LANE (org controls: [reason])
|
|
63
|
-
- ...
|
|
64
|
-
|
|
65
|
-
2. DATA STORES:
|
|
66
|
-
- [Store name] — triggered by: [task X writes/reads/updates ...]
|
|
67
|
-
- ...
|
|
68
|
-
|
|
69
|
-
3. MESSAGE FLOWS (between pools):
|
|
70
|
-
- [Pool A] ↔ [Pool B]: [what is communicated]
|
|
71
|
-
- ...
|
|
72
|
-
```
|
|
73
|
-
|
|
74
|
-
**The SVG diagram MUST match this analysis exactly.** If the analysis says "separate pool," the SVG must have a separate pool. If the analysis identifies a data store, the SVG must include it with data associations.
|
|
75
|
-
|
|
76
|
-
## Architecture & Layout Rules
|
|
77
|
-
|
|
78
|
-
### Pools and Lanes — CRITICAL
|
|
79
|
-
|
|
80
|
-
- **External participants** (e.g., patient, customer, citizen) get their own **pool** at the top of the diagram
|
|
81
|
-
- Use a distinct color scheme for the external pool header (e.g., brown) to differentiate from the organization pool (dark gray)
|
|
82
|
-
- External pool tasks use a warm color (e.g., orange `#fff3e0` fill, `#e65100` stroke)
|
|
83
|
-
- **Internal roles** within the organization are modeled as **lanes** within the organization pool
|
|
84
|
-
- Each lane gets a labeled sidebar and a subtle background tint
|
|
85
|
-
- Separate lanes with dashed divider lines
|
|
86
|
-
- Pool headers are vertical text bars on the left side of the pool
|
|
87
|
-
|
|
88
|
-
**Common Mistakes to Avoid:**
|
|
89
|
-
- Putting a customer/patient/citizen as a lane when they act independently — they need a separate pool with message flows, not sequence flows
|
|
90
|
-
- Using sequence flows between independent participants instead of message flows between separate pools
|
|
91
|
-
- Forgetting that external companies (e.g., חברת אשראי, ספק, קבלן) also need their own pool — they are not part of the organization
|
|
92
|
-
- Omitting a participant entirely — if the process description mentions a customer/patient/citizen, they MUST appear in the diagram as a pool with their own flow
|
|
93
|
-
|
|
94
|
-
### Element Placement — CRITICAL
|
|
95
|
-
|
|
96
|
-
**Every BPMN element (task, gateway, event) must be fully contained within a single lane or pool.** No element may overlap a lane divider line or sit on the boundary between two lanes. If an element belongs to a lane, it must be clearly centered vertically within that lane's area, with visible spacing from the lane borders above and below.
|
|
97
|
-
|
|
98
|
-
### Color Scheme by Participant Type
|
|
48
|
+
**Trigger words**: "system", "database", "account", "record", "registry".
|
|
49
|
+
**Action verbs**: "block account", "update record", "generate invoice", "credit account", "register", "log", "store", "look up", "check status".
|
|
99
50
|
|
|
100
|
-
|
|
101
|
-
|---------|------|--------|
|
|
102
|
-
| External participant tasks | `#fff3e0` | `#e65100` |
|
|
103
|
-
| Reception/admin tasks | `#e3f2fd` | `#1976d2` |
|
|
104
|
-
| Clinical/operational tasks | `#f3e5f5` | `#7b1fa2` |
|
|
105
|
-
| XOR Gateways | `#fff8e1` | `#f9a825` |
|
|
106
|
-
| Start event | `#e8f5e9` | `#2e7d32` |
|
|
107
|
-
| End event | `#ffebee` | `#c62828` |
|
|
108
|
-
| Data objects | `#fff` | `#1565c0` |
|
|
109
|
-
| Data stores | `#fff` | `#2e7d32` |
|
|
51
|
+
If ANY task reads/writes shared persistent state → Data Store required. A system = a data store. An account = a data store.
|
|
110
52
|
|
|
111
|
-
|
|
53
|
+
List each data store with its name and which tasks connect to it (read/write).
|
|
112
54
|
|
|
113
|
-
|
|
55
|
+
## Step 5 — Identify Data Objects
|
|
114
56
|
|
|
115
|
-
|
|
116
|
-
- Place pools they interact with **above and below** so message flows go in both directions naturally
|
|
117
|
-
- Rule of thumb: Count message flows between each pair of pools. Adjacent pools should be the pairs with the most message flows between them
|
|
57
|
+
List specific pieces of data flowing between tasks (e.g., "בקשת ביטול", "חשבונית זיכוי"). These are transient documents, not persistent systems.
|
|
118
58
|
|
|
119
|
-
|
|
59
|
+
## Step 6 — Identify Flows
|
|
120
60
|
|
|
121
|
-
|
|
61
|
+
- **Sequence flows** (within a pool): The order of tasks within each pool
|
|
62
|
+
- **Message flows** (between pools): Every communication between separate pools. Check bidirectional — every message expecting a response needs a return flow.
|
|
63
|
+
- **Data associations**: Connections between tasks and data stores / data objects.
|
|
122
64
|
|
|
123
|
-
|
|
124
|
-
- **Message flows** (between pools): Dashed lines (`stroke-dasharray: 10 5`) with open circle at source and filled arrow at target (`#37474f`)
|
|
125
|
-
- **Data associations**: Dashed lines (`stroke-dasharray: 4 3`) with small arrowheads, colored by type:
|
|
126
|
-
- Data object associations: `#7986cb`
|
|
127
|
-
- Data store associations: `#4caf50`
|
|
65
|
+
## Step 7 — Identify Events
|
|
128
66
|
|
|
129
|
-
|
|
67
|
+
- **Start events**: One per pool
|
|
68
|
+
- **End events**: One or more per pool (different outcomes)
|
|
69
|
+
- **Intermediate events**: For passive waiting (not tasks) — when a participant waits for a signal/message from another participant
|
|
130
70
|
|
|
131
|
-
|
|
71
|
+
## Step 8 — Verify Completeness
|
|
132
72
|
|
|
133
|
-
|
|
73
|
+
- Every pool has a complete flow: start → tasks/gateways → end
|
|
74
|
+
- External parties have their full process modeled, not just a single task
|
|
75
|
+
- Every message that expects a response has a return message flow
|
|
134
76
|
|
|
135
|
-
|
|
136
|
-
- AND (parallel): **+** marker inside the diamond
|
|
137
|
-
- OR (inclusive): **O** marker inside the diamond
|
|
77
|
+
## Required Output Format
|
|
138
78
|
|
|
139
|
-
|
|
79
|
+
Output the model in this exact format:
|
|
140
80
|
|
|
141
|
-
**Anti-pattern — NEVER do this:**
|
|
142
|
-
```svg
|
|
143
|
-
<!-- WRONG: text inside gateway diamond -->
|
|
144
|
-
<polygon points="..." fill="..." stroke="..."/>
|
|
145
|
-
<text x="CX" y="CY">כמה ימים?</text> <!-- FORBIDDEN -->
|
|
146
81
|
```
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
-
|
|
175
|
-
-
|
|
176
|
-
|
|
177
|
-
```svg
|
|
178
|
-
<!-- Data Object template (w≈34, h≈38) -->
|
|
179
|
-
<path d="M X,Y L X+26,Y L X+34,Y+8 L X+34,Y+38 L X,Y+38 Z" class="data-object-shape"/>
|
|
180
|
-
<path d="M X+26,Y L X+26,Y+8 L X+34,Y+8" class="data-object-fold"/>
|
|
181
|
-
```
|
|
182
|
-
|
|
183
|
-
**Data Stores** (cylinder icon, green):
|
|
184
|
-
- Represent persistent storage / databases (e.g., "מאגר כרטיסי תינוקות", "מאגר מדדים")
|
|
185
|
-
- Drawn as a cylinder (two ellipses connected by vertical lines)
|
|
186
|
-
|
|
187
|
-
```svg
|
|
188
|
-
<!-- Data Store template -->
|
|
189
|
-
<ellipse cx="CX" cy="TOP" rx="28" ry="8" class="data-store-body"/>
|
|
190
|
-
<path d="M CX-28,TOP L CX-28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
|
|
191
|
-
<path d="M CX+28,TOP L CX+28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
|
|
192
|
-
<ellipse cx="CX" cy="BOTTOM" rx="28" ry="8" class="data-store-body"/>
|
|
82
|
+
STRUCTURAL MODEL:
|
|
83
|
+
|
|
84
|
+
POOLS:
|
|
85
|
+
- [Pool name] — [reason: acts independently / external company]
|
|
86
|
+
Tasks: [task1] → [task2] → ...
|
|
87
|
+
Start: [description]
|
|
88
|
+
End(s): [description(s)]
|
|
89
|
+
|
|
90
|
+
ORGANIZATION POOL: [org name]
|
|
91
|
+
LANE: [lane name]
|
|
92
|
+
Tasks: [task1] → [task2] → ...
|
|
93
|
+
LANE: [lane name]
|
|
94
|
+
Tasks: ...
|
|
95
|
+
Start: [description]
|
|
96
|
+
End(s): [description(s)]
|
|
97
|
+
|
|
98
|
+
GATEWAYS:
|
|
99
|
+
- [G1] Type: XOR | Question: [question] | In: [lane/pool] | Branches: [branch1 → ..., branch2 → ...]
|
|
100
|
+
- [G2] Type: XOR (merge) | In: [lane/pool] | Merges: [branches from G1]
|
|
101
|
+
|
|
102
|
+
DATA STORES:
|
|
103
|
+
- [Store name] — reads: [task X, task Y] | writes: [task Z]
|
|
104
|
+
|
|
105
|
+
DATA OBJECTS:
|
|
106
|
+
- [Object name] — from: [task X] → to: [task Y]
|
|
107
|
+
|
|
108
|
+
MESSAGE FLOWS:
|
|
109
|
+
- [Pool A] → [Pool B]: [what is communicated]
|
|
110
|
+
- [Pool B] → [Pool A]: [response]
|
|
193
111
|
```
|
|
194
112
|
|
|
195
|
-
|
|
196
|
-
|
|
197
|
-
- Place data objects **above** or **below** their associated task, never overlapping flow lines
|
|
198
|
-
- Place data objects to the **left** of a task if vertical placement would cross flow paths
|
|
199
|
-
- Data stores typically go below their associated tasks
|
|
200
|
-
- **Never** place data artifacts in a location where their association lines cross or overlap with sequence flow arrows
|
|
201
|
-
|
|
202
|
-
## Arrow Routing — CRITICAL
|
|
203
|
-
|
|
204
|
-
The most important visual quality rule: **arrows must never be ambiguous**.
|
|
205
|
-
|
|
206
|
-
### Split-Merge Pattern (Two Outcome Paths)
|
|
207
|
-
|
|
208
|
-
When a gateway splits into two paths (e.g., "תקין" vs "דורש מעקב") and then merges:
|
|
209
|
-
|
|
210
|
-
1. Place the **YES task** above the gateway's horizontal center line
|
|
211
|
-
2. Place the **NO task** below the gateway's horizontal center line
|
|
212
|
-
3. Place the **merge gateway** clearly to the right of BOTH tasks
|
|
213
|
-
4. Route the YES path: task → **right** → **down** into merge gateway (entering from top)
|
|
214
|
-
5. Route the NO path: task → **right** → **up** into merge gateway (entering from bottom)
|
|
215
|
-
6. From the merge gateway, route a **single clean vertical line down** to the next task
|
|
216
|
-
|
|
217
|
-
**The merge area must have clear visual separation between all paths. No path should overlap another.**
|
|
218
|
-
|
|
219
|
-
### General Routing Rules
|
|
220
|
-
|
|
221
|
-
- Prefer orthogonal (right-angle) routing over diagonal lines
|
|
222
|
-
- Leave at least 30px spacing between parallel flow lines
|
|
223
|
-
- When routing a flow from one lane to another, use a clear vertical drop/rise
|
|
224
|
-
- Label YES/NO (כן/לא) near the gateway, not at the end of the path
|
|
225
|
-
- Flow labels should not overlap with other elements
|
|
226
|
-
|
|
227
|
-
## Modeling Rejection/Retry Loops
|
|
228
|
-
|
|
229
|
-
When a process includes an approval step where the participant can reject:
|
|
230
|
-
|
|
231
|
-
1. Model the **rejection action** as an explicit task in the rejecting participant's pool (e.g., "שליחת ביטול סגירה"), not just a gateway output
|
|
232
|
-
2. After rejection, model what the rejecting participant **does next** — typically a waiting intermediate event (e.g., waiting for follow-up contact)
|
|
233
|
-
3. In the receiving pool, model the **response to rejection** as a concrete task sequence (e.g., "contact customer" → "decide next step")
|
|
234
|
-
4. Loop-back arrows should return to the earliest meaningful re-entry point in the process, not to an arbitrary task
|
|
235
|
-
|
|
236
|
-
## Typography & Hebrew Support
|
|
237
|
-
|
|
238
|
-
- Use `Noto Sans Hebrew` (imported from Google Fonts) for all text
|
|
239
|
-
- Set `lang="he"` and `dir="rtl"` on the HTML element
|
|
240
|
-
- Task text: 11.5px, font-weight 500, centered in the task box
|
|
241
|
-
- Gateway labels: 10.5px, font-weight 400, positioned above the diamond
|
|
242
|
-
- Data labels: 9.5px, font-weight 500
|
|
243
|
-
- Flow labels (כן/לא): 10px
|
|
244
|
-
|
|
245
|
-
## File Structure
|
|
246
|
-
|
|
247
|
-
Output a single self-contained HTML file with:
|
|
248
|
-
|
|
249
|
-
1. **Header bar**: Gradient background with process title in Hebrew + English subtitle. Must say "BPMN 1.1" (NOT 2.0)
|
|
250
|
-
2. **Legend**: Horizontal bar showing all BPMN symbols used in the diagram (start, end, task, XOR gateway, intermediate event, data object, data store, message flow)
|
|
251
|
-
3. **SVG canvas**: The full BPMN diagram in a scrollable wrapper
|
|
252
|
-
4. **SVG definitions**: Drop shadow filters, arrow markers (sequence, message, data association)
|
|
253
|
-
|
|
254
|
-
### SVG Sizing
|
|
255
|
-
|
|
256
|
-
- Width: 1700–1800px typical (allow overflow scroll)
|
|
257
|
-
- Height: Scale based on number of pools and lanes (~130px per external pool, ~250px per lane, plus spacing for data artifacts)
|
|
258
|
-
- Use `viewBox` matching width/height for proper scaling
|
|
259
|
-
|
|
260
|
-
## Verification Gate — MANDATORY
|
|
261
|
-
|
|
262
|
-
**STOP before delivering the diagram. Verify EVERY item below. If any item fails, you MUST fix it before delivering. Do NOT skip this step.**
|
|
263
|
-
|
|
264
|
-
- [ ] Every gateway (split AND merge) has ONLY an X/+/O marker inside — no text inside the diamond
|
|
265
|
-
- [ ] Gateway labels (questions, conditions) are positioned ABOVE or BESIDE the diamond, never inside
|
|
266
|
-
- [ ] Every element (task, gateway, event) is fully inside a single lane — nothing sits on a lane boundary
|
|
267
|
-
- [ ] No arrow paths overlap or cross ambiguously
|
|
268
|
-
- [ ] Data objects (📄) and data stores (🗄️) use different icons
|
|
269
|
-
- [ ] Every participant mentioned in the process description appears in the diagram — none are omitted
|
|
270
|
-
- [ ] External participants are in separate pools with message flows
|
|
271
|
-
- [ ] Passive waiting uses intermediate events, not regular tasks
|
|
272
|
-
- [ ] Flow labels (כן/לא) are clearly positioned near their gateway
|
|
273
|
-
- [ ] The legend includes every symbol type used in the diagram
|
|
274
|
-
- [ ] Data artifacts don't overlap with sequence flow paths
|
|
275
|
-
- [ ] Every pool has a complete internal flow (start → ... → end), not just a single task
|
|
276
|
-
- [ ] A Data Store is modeled for every persistent system (accounts, invoices, records, registrations — see trigger words in Process Analysis step 7)
|
|
277
|
-
- [ ] Every message flow that expects a response has a return message flow
|
|
278
|
-
- [ ] Phone calls, emails, and direct contacts mentioned in the description are modeled as tasks, not annotations
|
|
279
|
-
- [ ] After a rejection/refusal gateway, the rejecting participant's subsequent state (waiting/action) is explicitly modeled
|
|
280
|
-
- [ ] Pool ordering minimizes message flow crossing distance
|
|
281
|
-
|
|
282
|
-
## Example Process Categories
|
|
283
|
-
|
|
284
|
-
This skill handles processes such as:
|
|
285
|
-
- Healthcare workflows (e.g., Tipat Halav clinic visits, hospital admissions)
|
|
286
|
-
- Government/municipal service processes
|
|
287
|
-
- Customer service and support flows
|
|
288
|
-
- Order fulfillment and logistics
|
|
289
|
-
- Employee onboarding
|
|
290
|
-
- Academic/educational administration processes
|
|
291
|
-
|
|
292
|
-
The skill works for any domain — adapt the color scheme and terminology to match the context.
|
|
113
|
+
## After Outputting the Model
|
|
293
114
|
|
|
294
|
-
|
|
115
|
+
Present the model and ask the user:
|
|
295
116
|
|
|
296
|
-
|
|
117
|
+
**"הנה המודל המבני של התהליך. האם לעבור לשלב הבא ולייצר את הדיאגרמה, או שיש שינויים?"**
|
|
297
118
|
|
|
298
|
-
|
|
299
|
-
Always use the **male grammatical form** (זכר) when referring to people, roles, actors, classes, or participants — even when the role is traditionally associated with a specific gender.
|
|
119
|
+
When the user confirms, use the **`bpmn-render`** prompt to generate the visual diagram. Pass it the approved structural model.
|
|
300
120
|
|
|
301
|
-
|
|
302
|
-
- ✅ רופא (not אחות for a nurse role — use אח)
|
|
303
|
-
- ✅ אח (nurse, male form)
|
|
304
|
-
- ✅ מטופל (not מטופלת)
|
|
305
|
-
- ✅ לקוח (not לקוחה)
|
|
306
|
-
- ✅ מנהל (not מנהלת)
|
|
307
|
-
- ✅ עובד (not עובדת)
|
|
308
|
-
- ✅ משתמש (not משתמשת)
|
|
309
|
-
- ✅ סטודנט (not סטודנטית)
|
|
310
|
-
|
|
311
|
-
**Examples of stereotypic writing to avoid:**
|
|
312
|
-
- ❌ רופא ואחות — implies doctor=male, nurse=female
|
|
313
|
-
- ❌ מזכירה — use מזכיר instead
|
|
314
|
-
- ❌ אחות — use אח instead
|
|
121
|
+
## Hebrew Language Guidelines
|
|
315
122
|
|
|
316
|
-
|
|
317
|
-
|
|
123
|
+
Use the **male grammatical form** (זכר) for all roles and participants:
|
|
124
|
+
- ✅ רופא, אח, מטופל, לקוח, מנהל, עובד, משתמש, סטודנט
|
|
125
|
+
- ❌ אחות, מטופלת, לקוחה, מנהלת, מזכירה
|
|
@@ -0,0 +1,187 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: bpmn-render
|
|
3
|
+
description: "Internal skill: Render an approved BPMN structural model as an interactive HTML/SVG file. Do not invoke directly — use bpmn-diagram first to build the model."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# BPMN Rendering — Phase 2 & 3
|
|
7
|
+
|
|
8
|
+
You have an approved structural model from the conversation above (output of the `bpmn-diagram` prompt). Now render it as an HTML file with embedded SVG, then validate.
|
|
9
|
+
|
|
10
|
+
**Every participant, task, gateway, data store, data object, and flow from the approved model MUST appear in the SVG. Do not add or remove elements.**
|
|
11
|
+
|
|
12
|
+
## NON-NEGOTIABLE RENDERING RULES
|
|
13
|
+
|
|
14
|
+
1. **GATEWAYS**: The diamond contains ONLY the marker symbol: **X** (XOR), **+** (AND), or **O** (OR). NEVER text inside. Labels go ABOVE the diamond. Every gateway (split AND merge) must show its marker.
|
|
15
|
+
|
|
16
|
+
2. **EXTERNAL PARTICIPANTS** are separate pools with message flows (dashed). NOT lanes.
|
|
17
|
+
|
|
18
|
+
3. **DATA STORES** appear as cylinders with data association lines to their tasks.
|
|
19
|
+
|
|
20
|
+
4. **NO ELEMENTS ON LANE BOUNDARIES**: Every element fully inside one lane, centered vertically.
|
|
21
|
+
|
|
22
|
+
## Architecture & Layout
|
|
23
|
+
|
|
24
|
+
### Pools and Lanes
|
|
25
|
+
|
|
26
|
+
- **External participant pools**: Own pool rectangle, visually separated. Brown header, orange tasks (`#fff3e0` fill, `#e65100` stroke).
|
|
27
|
+
- **Organization pool**: Dark gray header, contains internal lanes. Each lane has a labeled sidebar and subtle background tint. Dashed divider lines between lanes.
|
|
28
|
+
- Pool headers: Vertical text bars on the left side.
|
|
29
|
+
|
|
30
|
+
### Element Placement
|
|
31
|
+
|
|
32
|
+
Every BPMN element must be fully contained within a single lane or pool. Center elements vertically within their lane with visible spacing from borders.
|
|
33
|
+
|
|
34
|
+
### Color Scheme
|
|
35
|
+
|
|
36
|
+
| Element | Fill | Stroke |
|
|
37
|
+
|---------|------|--------|
|
|
38
|
+
| External participant tasks | `#fff3e0` | `#e65100` |
|
|
39
|
+
| Reception/admin tasks | `#e3f2fd` | `#1976d2` |
|
|
40
|
+
| Clinical/operational tasks | `#f3e5f5` | `#7b1fa2` |
|
|
41
|
+
| XOR Gateways | `#fff8e1` | `#f9a825` |
|
|
42
|
+
| Start event | `#e8f5e9` | `#2e7d32` |
|
|
43
|
+
| End event | `#ffebee` | `#c62828` |
|
|
44
|
+
| Data objects | `#fff` | `#1565c0` |
|
|
45
|
+
| Data stores | `#fff` | `#2e7d32` |
|
|
46
|
+
|
|
47
|
+
### Pool Ordering
|
|
48
|
+
|
|
49
|
+
When multiple external pools exist, minimize message flow crossing distance:
|
|
50
|
+
- Primary actor (initiates, interacts with multiple parties) in the middle
|
|
51
|
+
- Interacting pools above and below
|
|
52
|
+
|
|
53
|
+
### Flow Types
|
|
54
|
+
|
|
55
|
+
- **Sequence flows** (within a pool): Solid lines, filled arrowheads (`#546e7a`)
|
|
56
|
+
- **Message flows** (between pools): Dashed lines (`stroke-dasharray: 10 5`), open circle at source, filled arrow at target (`#37474f`)
|
|
57
|
+
- **Data associations**: Dashed lines (`stroke-dasharray: 4 3`), small arrowheads:
|
|
58
|
+
- Data object: `#7986cb`
|
|
59
|
+
- Data store: `#4caf50`
|
|
60
|
+
|
|
61
|
+
## SVG Templates
|
|
62
|
+
|
|
63
|
+
### XOR Gateway (split or merge)
|
|
64
|
+
|
|
65
|
+
```svg
|
|
66
|
+
<rect x="X" y="Y" width="34" height="34" class="gateway" transform="rotate(45, CX, CY)"/>
|
|
67
|
+
<line x1="CX-7" y1="CY-10" x2="CX+7" y2="CY+10" class="gateway-x"/>
|
|
68
|
+
<line x1="CX+7" y1="CY-10" x2="CX-7" y2="CY+10" class="gateway-x"/>
|
|
69
|
+
<text x="CX" y="CY-25" text-anchor="middle">label ABOVE diamond</text>
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
**WRONG — never do this:**
|
|
73
|
+
```svg
|
|
74
|
+
<polygon points="..." fill="..." stroke="..."/>
|
|
75
|
+
<text x="CX" y="CY">text inside diamond</text> <!-- FORBIDDEN -->
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### Intermediate Events (BPMN 1.1)
|
|
79
|
+
|
|
80
|
+
Plain double circle, NO icon inside:
|
|
81
|
+
```svg
|
|
82
|
+
<circle cx="X" cy="Y" r="16" fill="#fff" stroke="#1565c0" stroke-width="2"/>
|
|
83
|
+
<circle cx="X" cy="Y" r="12" fill="none" stroke="#1565c0" stroke-width="1.2"/>
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
### Data Objects (folded document, blue)
|
|
87
|
+
|
|
88
|
+
```svg
|
|
89
|
+
<path d="M X,Y L X+26,Y L X+34,Y+8 L X+34,Y+38 L X,Y+38 Z" class="data-object-shape"/>
|
|
90
|
+
<path d="M X+26,Y L X+26,Y+8 L X+34,Y+8" class="data-object-fold"/>
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
### Data Stores (cylinder, green)
|
|
94
|
+
|
|
95
|
+
```svg
|
|
96
|
+
<ellipse cx="CX" cy="TOP" rx="28" ry="8" class="data-store-body"/>
|
|
97
|
+
<path d="M CX-28,TOP L CX-28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
|
|
98
|
+
<path d="M CX+28,TOP L CX+28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
|
|
99
|
+
<ellipse cx="CX" cy="BOTTOM" rx="28" ry="8" class="data-store-body"/>
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
### Data Artifact Placement
|
|
103
|
+
|
|
104
|
+
- Data objects above or below their task, never overlapping flow lines
|
|
105
|
+
- Data stores typically below their tasks
|
|
106
|
+
- Association lines must not cross sequence flow arrows
|
|
107
|
+
|
|
108
|
+
## Arrow Routing
|
|
109
|
+
|
|
110
|
+
**Arrows must never be ambiguous.**
|
|
111
|
+
|
|
112
|
+
### Split-Merge Pattern
|
|
113
|
+
|
|
114
|
+
1. YES task above gateway center, NO task below
|
|
115
|
+
2. Merge gateway to the right of BOTH tasks
|
|
116
|
+
3. YES path: task → right → down into merge (from top)
|
|
117
|
+
4. NO path: task → right → up into merge (from bottom)
|
|
118
|
+
5. Single clean line from merge to next task
|
|
119
|
+
|
|
120
|
+
### General Rules
|
|
121
|
+
|
|
122
|
+
- Orthogonal (right-angle) routing preferred
|
|
123
|
+
- At least 30px between parallel flow lines
|
|
124
|
+
- Cross-lane flows: clear vertical drops/rises
|
|
125
|
+
- Labels (כן/לא) near the gateway, not at path end
|
|
126
|
+
- Flow labels must not overlap other elements
|
|
127
|
+
|
|
128
|
+
### Rejection/Retry Loops
|
|
129
|
+
|
|
130
|
+
- Rejection = explicit task (not just gateway output)
|
|
131
|
+
- After rejection: model the rejecting participant's next state
|
|
132
|
+
- Response to rejection = concrete task sequence
|
|
133
|
+
- Loop-back to earliest meaningful re-entry point
|
|
134
|
+
|
|
135
|
+
## Typography & Hebrew
|
|
136
|
+
|
|
137
|
+
- `Noto Sans Hebrew` from Google Fonts
|
|
138
|
+
- `lang="he"` and `dir="rtl"` on HTML element
|
|
139
|
+
- Task text: 11.5px, font-weight 500, centered
|
|
140
|
+
- Gateway labels: 10.5px, font-weight 400, above diamond
|
|
141
|
+
- Data labels: 9.5px, font-weight 500
|
|
142
|
+
- Flow labels: 10px
|
|
143
|
+
|
|
144
|
+
## File Structure
|
|
145
|
+
|
|
146
|
+
Single self-contained HTML file:
|
|
147
|
+
|
|
148
|
+
1. **Header bar**: Gradient, process title in Hebrew + English subtitle. Must say "BPMN 1.1"
|
|
149
|
+
2. **Legend**: All BPMN symbols used (start, end, task, XOR gateway, intermediate event, data object, data store, message flow)
|
|
150
|
+
3. **SVG canvas**: Full diagram in scrollable wrapper
|
|
151
|
+
4. **SVG definitions**: Drop shadow filters, arrow markers
|
|
152
|
+
|
|
153
|
+
### SVG Sizing
|
|
154
|
+
|
|
155
|
+
- Width: 1700–1800px (overflow scroll)
|
|
156
|
+
- Height: ~130px per external pool, ~250px per lane, plus data artifacts
|
|
157
|
+
- `viewBox` matching width/height
|
|
158
|
+
|
|
159
|
+
---
|
|
160
|
+
|
|
161
|
+
# PHASE 3 — VALIDATION
|
|
162
|
+
|
|
163
|
+
**Before delivering, verify EVERY item. Fix any failure before delivering.**
|
|
164
|
+
|
|
165
|
+
## Structural Accuracy (cross-reference with approved model)
|
|
166
|
+
- [ ] Every participant from the model appears — none omitted
|
|
167
|
+
- [ ] External participants are separate pools with message flows
|
|
168
|
+
- [ ] Every pool has complete flow (start → ... → end)
|
|
169
|
+
- [ ] Every gateway has the correct type marker (X/+/O) — no text inside
|
|
170
|
+
- [ ] Every data store appears as a cylinder with data associations
|
|
171
|
+
- [ ] Every message flow appears as dashed line between pools
|
|
172
|
+
|
|
173
|
+
## BPMN Compliance
|
|
174
|
+
- [ ] Gateway labels ABOVE or BESIDE the diamond, never inside
|
|
175
|
+
- [ ] Every element fully inside one lane — nothing on boundaries
|
|
176
|
+
- [ ] Passive waiting uses intermediate events, not tasks
|
|
177
|
+
- [ ] Data objects (folded document) and data stores (cylinder) are visually distinct
|
|
178
|
+
|
|
179
|
+
## Visual Quality
|
|
180
|
+
- [ ] No arrow paths overlap or cross ambiguously
|
|
181
|
+
- [ ] Flow labels clearly positioned near their gateway
|
|
182
|
+
- [ ] Legend includes every symbol type used
|
|
183
|
+
- [ ] Data artifacts don't overlap sequence flow paths
|
|
184
|
+
- [ ] Pool ordering minimizes message flow crossing distance
|
|
185
|
+
|
|
186
|
+
## Hebrew Language
|
|
187
|
+
- [ ] Male grammatical form used for all roles (רופא not אחות, אח not אחות, מטופל not מטופלת)
|