sad-mcp 0.1.24 → 0.1.25

package/dist/prompts.js

@@ -26,6 +26,14 @@ const SKILLS = [
         description: "Create BPMN business process diagrams as interactive HTML/SVG files",
     },
 ];
+// Internal skills: loadable via GetPrompt but not shown in ListPrompts
+const INTERNAL_SKILLS = [
+    {
+        id: "bpmn-render",
+        name: "BPMN Render",
+        description: "Internal: Render an approved BPMN structural model as HTML/SVG",
+    },
+];
 function loadSkill(skillId) {
     const skillsDir = join(__dirname, "..", "skills");
     return readFileSync(join(skillsDir, skillId, "SKILL.md"), "utf-8");
@@ -38,7 +46,8 @@ export function registerPromptHandlers(server) {
         })),
     }));
     server.setRequestHandler(GetPromptRequestSchema, async (request) => {
-        const skill = SKILLS.find((s) => s.id === request.params.name);
+        const skill = SKILLS.find((s) => s.id === request.params.name) ||
+            INTERNAL_SKILLS.find((s) => s.id === request.params.name);
         if (!skill) {
             throw new Error(`Unknown skill: ${request.params.name}`);
         }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sad-mcp",
-  "version": "0.1.24",
+  "version": "0.1.25",
   "description": "MCP server for Software Analysis and Design course materials at BGU",
   "type": "module",
   "bin": {

package/skills/bpmn-diagram/SKILL.backup.md

@@ -0,0 +1,359 @@
+---
+name: bpmn-diagram
+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.
+---
+
+# BPMN Diagram Creation Skill
+
+This skill creates professional BPMN 1.1 diagrams rendered as interactive HTML files with embedded SVG. The diagrams support Hebrew (RTL) and English text.
+
+**This skill operates in 3 phases. You MUST complete each phase fully before moving to the next.**
+
+## NON-NEGOTIABLE RULES — READ BEFORE ANYTHING ELSE
+
+These rules are violated most often. You MUST follow every one. No exceptions.
+
+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.
+
+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).
+
+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.
+
+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.
+
+5. **EVERY PARTICIPANT MUST APPEAR**: If the process description mentions a customer/patient/company — they MUST appear in the diagram. Never omit a participant.
+
+## When to Use
+
+- User asks to create a BPMN diagram, process model, or workflow diagram
+- User describes a business process and wants it visualized
+- User provides a process narrative in any language and wants a BPMN representation
+- User asks to model a process with swim lanes, pools, gateways, or data flows
+
+---
+
+# ═══════════════════════════════════════════════════
+# PHASE 1 — STRUCTURAL MODEL (text only, NO SVG)
+# ═══════════════════════════════════════════════════
+
+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.
+
+## Step 1.1 — Identify Participants
+
+List every actor/role mentioned in the process. For each one, classify as POOL or LANE:
+
+- **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).
+- **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).
+- **The test**: "Does the organization orchestrate this participant's actions, or do they act independently?" Independent → POOL.
+
+## Step 1.2 — Identify Tasks
+
+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.
+
+## Step 1.3 — Identify Gateways (with type!)
+
+List every decision point / conditional branch. For each gateway, specify:
+- **Type**: XOR (exclusive — only one path), AND (parallel — all paths), or OR (inclusive — one or more paths)
+- **Question/condition**: What is being decided
+- **Outgoing branches**: The possible outcomes and where each leads
+- **Merge**: Where the branches reconverge (if applicable) — merge gateways must also be listed with their type
+
+## Step 1.4 — Identify Data Stores
+
+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".
+
+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.
+
+List each data store with a name and which tasks connect to it (read/write).
+
+## Step 1.5 — Identify Data Objects
+
+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.
+
+## Step 1.6 — Identify Flows
+
+- **Sequence flows** (within a pool/between lanes): List the order of tasks within each pool
+- **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.
+- **Data associations**: List connections between tasks and data stores / data objects.
+
+## Step 1.7 — Identify Events
+
+- **Start events**: One per pool
+- **End events**: One or more per pool (for different outcomes)
+- **Intermediate events**: Use for passive waiting (not tasks). When a participant is waiting for a signal/message from another participant.
+
+## Step 1.8 — Complete Each Participant's Flow
+
+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.
+
+## Required Output Format
+
+```
+STRUCTURAL MODEL:
+
+POOLS:
+- [Pool name] — [reason: acts independently / external company]
+  Tasks: [task1] → [task2] → ...
+  Start: [description]
+  End(s): [description(s)]
+
+ORGANIZATION POOL: [org name]
+  LANE: [lane name]
+    Tasks: [task1] → [task2] → ...
+  LANE: [lane name]
+    Tasks: ...
+  Start: [description]
+  End(s): [description(s)]
+
+GATEWAYS:
+- [G1] Type: XOR | Question: [question] | In: [lane/pool] | Branches: [branch1 → ..., branch2 → ...]
+- [G2] Type: XOR (merge) | In: [lane/pool] | Merges: [branches from G1]
+- ...
+
+DATA STORES:
+- [Store name] — reads: [task X, task Y] | writes: [task Z]
+- ...
+
+DATA OBJECTS:
+- [Object name] — from: [task X] → to: [task Y]
+- ...
+
+MESSAGE FLOWS:
+- [Pool A] → [Pool B]: [what is communicated]
+- [Pool B] → [Pool A]: [response]
+- ...
+```
+
+## ⛔ HARD STOP — DO NOT PROCEED
+
+**STOP HERE.** Present the structural model above to the user. Do NOT write any HTML, SVG, or code yet.
+
+Ask the user: "הנה המודל המבני של התהליך. האם לעבור לשלב הבא ולייצר את הדיאגרמה, או שיש שינויים שתרצה לבצע?"
+
+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.
+
+---
+
+# ═══════════════════════════════════════════════════
+# PHASE 2 — SVG RENDERING (only after Phase 1 approval)
+# ═══════════════════════════════════════════════════
+
+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.
+
+## Architecture & Layout
+
+### Pools and Lanes
+
+- **External participant pools** get their own pool rectangle, visually separated from the organization pool
+  - Use a distinct color scheme for external pool headers (e.g., brown) to differentiate from the organization pool (dark gray)
+  - External pool tasks use a warm color (e.g., orange `#fff3e0` fill, `#e65100` stroke)
+- **Organization pool** contains internal lanes
+  - Each lane gets a labeled sidebar and a subtle background tint
+  - Separate lanes with dashed divider lines
+- Pool headers are vertical text bars on the left side of the pool
+
+### Element Placement
+
+**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.
+
+### Color Scheme
+
+| Element | Fill | Stroke |
+|---------|------|--------|
+| External participant tasks | `#fff3e0` | `#e65100` |
+| Reception/admin tasks | `#e3f2fd` | `#1976d2` |
+| Clinical/operational tasks | `#f3e5f5` | `#7b1fa2` |
+| XOR Gateways | `#fff8e1` | `#f9a825` |
+| Start event | `#e8f5e9` | `#2e7d32` |
+| End event | `#ffebee` | `#c62828` |
+| Data objects | `#fff` | `#1565c0` |
+| Data stores | `#fff` | `#2e7d32` |
+
+### Pool Ordering
+
+When multiple external pools exist, order to **minimize message flow crossing distance**:
+- Place the primary actor (initiates and interacts with multiple parties) in the middle
+- Place pools they interact with above and below
+
+### Flow Types
+
+- **Sequence flows** (within a pool): Solid lines with filled arrowheads (`#546e7a`)
+- **Message flows** (between pools): Dashed lines (`stroke-dasharray: 10 5`) with open circle at source and filled arrow at target (`#37474f`)
+- **Data associations**: Dashed lines (`stroke-dasharray: 4 3`) with small arrowheads:
+  - Data object associations: `#7986cb`
+  - Data store associations: `#4caf50`
+
+## BPMN Element SVG Templates
+
+### Gateways
+
+**Gateway diamonds contain ONLY the marker symbol — NEVER text.** Labels go ABOVE the diamond.
+
+```svg
+<!-- XOR Gateway (split or merge) — X marker inside -->
+<rect x="X" y="Y" width="34" height="34" class="gateway" transform="rotate(45, CX, CY)"/>
+<line x1="CX-7" y1="CY-10" x2="CX+7" y2="CY+10" class="gateway-x"/>
+<line x1="CX+7" y1="CY-10" x2="CX-7" y2="CY+10" class="gateway-x"/>
+<text x="CX" y="CY-25" text-anchor="middle">label ABOVE</text>
+```
+
+**Anti-pattern — NEVER do this:**
+```svg
+<!-- WRONG: text inside gateway diamond -->
+<polygon points="..." fill="..." stroke="..."/>
+<text x="CX" y="CY">כמה ימים?</text>  <!-- FORBIDDEN -->
+```
+
+### Intermediate Events (BPMN 1.1 style)
+
+Plain double circle with NO icon inside:
+
+```svg
+<circle cx="X" cy="Y" r="16" fill="#fff" stroke="#1565c0" stroke-width="2"/>
+<circle cx="X" cy="Y" r="12" fill="none" stroke="#1565c0" stroke-width="1.2"/>
+```
+
+### Data Objects (folded-corner document, blue)
+
+```svg
+<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"/>
+<path d="M X+26,Y L X+26,Y+8 L X+34,Y+8" class="data-object-fold"/>
+```
+
+### Data Stores (cylinder, green)
+
+```svg
+<ellipse cx="CX" cy="TOP" rx="28" ry="8" class="data-store-body"/>
+<path d="M CX-28,TOP L CX-28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
+<path d="M CX+28,TOP L CX+28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
+<ellipse cx="CX" cy="BOTTOM" rx="28" ry="8" class="data-store-body"/>
+```
+
+### Data Artifact Placement
+
+- Place data objects above or below their associated task, never overlapping flow lines
+- Place data stores typically below their associated tasks
+- Never place data artifacts where association lines cross sequence flow arrows
+
+## Arrow Routing
+
+**Arrows must never be ambiguous.**
+
+### Split-Merge Pattern
+
+1. YES task above the gateway's horizontal center line
+2. NO task below
+3. Merge gateway clearly to the right of BOTH tasks
+4. YES path: task → right → down into merge (entering from top)
+5. NO path: task → right → up into merge (entering from bottom)
+6. From merge: single clean line to next task
+
+### General Routing Rules
+
+- Prefer orthogonal (right-angle) routing
+- Leave at least 30px spacing between parallel flow lines
+- Cross-lane flows use clear vertical drops/rises
+- Label YES/NO (כן/לא) near the gateway, not at the end of the path
+- Flow labels must not overlap other elements
+
+## Modeling Rejection/Retry Loops
+
+1. Model rejection as an explicit task (not just a gateway output)
+2. After rejection, model the rejecting participant's next state (waiting/action)
+3. Model the response to rejection as a concrete task sequence
+4. Loop-back arrows return to the earliest meaningful re-entry point
+
+## Typography & Hebrew
+
+- Use `Noto Sans Hebrew` (imported from Google Fonts) for all text
+- Set `lang="he"` and `dir="rtl"` on the HTML element
+- Task text: 11.5px, font-weight 500, centered
+- Gateway labels: 10.5px, font-weight 400, positioned above the diamond
+- Data labels: 9.5px, font-weight 500
+- Flow labels: 10px
+
+## File Structure
+
+Output a single self-contained HTML file with:
+
+1. **Header bar**: Gradient background with process title in Hebrew + English subtitle. Must say "BPMN 1.1" (NOT 2.0)
+2. **Legend**: Horizontal bar showing all BPMN symbols used (start, end, task, XOR gateway, intermediate event, data object, data store, message flow)
+3. **SVG canvas**: The full BPMN diagram in a scrollable wrapper
+4. **SVG definitions**: Drop shadow filters, arrow markers (sequence, message, data association)
+
+### SVG Sizing
+
+- Width: 1700–1800px typical (allow overflow scroll)
+- Height: Scale based on pools and lanes (~130px per external pool, ~250px per lane, plus data artifacts)
+- Use `viewBox` matching width/height
+
+---
+
+# ═══════════════════════════════════════════════════
+# PHASE 3 — VALIDATION & FIX
+# ═══════════════════════════════════════════════════
+
+**Before delivering the diagram, go through EVERY item below. If ANY item fails, fix the SVG immediately. Do NOT deliver until all pass.**
+
+## Structural Accuracy (cross-reference with Phase 1 model)
+- [ ] Every participant from the Phase 1 model appears in the SVG — none are omitted
+- [ ] External participants are in separate pools with message flows (not lanes with sequence flows)
+- [ ] Every pool has a complete internal flow (start → ... → end)
+- [ ] Every gateway from Phase 1 appears with the correct type marker
+- [ ] Every data store from Phase 1 appears as a cylinder with data associations
+- [ ] Every message flow from Phase 1 appears as a dashed line between pools
+
+## BPMN Compliance
+- [ ] Every gateway (split AND merge) has ONLY an X/+/O marker inside — no text inside the diamond
+- [ ] Gateway labels are positioned ABOVE or BESIDE the diamond, never inside
+- [ ] Every element (task, gateway, event) is fully inside a single lane — nothing sits on a lane boundary
+- [ ] Passive waiting uses intermediate events, not regular tasks
+- [ ] Data objects (folded document) and data stores (cylinder) use different icons
+
+## Visual Quality
+- [ ] No arrow paths overlap or cross ambiguously
+- [ ] Flow labels (כן/לא) are clearly positioned near their gateway
+- [ ] The legend includes every symbol type used in the diagram
+- [ ] Data artifacts don't overlap with sequence flow paths
+- [ ] Pool ordering minimizes message flow crossing distance
+
+---
+
+# APPENDIX
+
+## Example Process Categories
+
+This skill handles processes such as:
+- Healthcare workflows (e.g., Tipat Halav clinic visits, hospital admissions)
+- Government/municipal service processes
+- Customer service and support flows
+- Order fulfillment and logistics
+- Employee onboarding
+- Academic/educational administration processes
+
+The skill works for any domain — adapt the color scheme and terminology to match the context.
+
+## Hebrew Language Guidelines (שפה מגדרית נייטרלית)
+
+When labels, names, actors, roles, or any text in the diagram are written in Hebrew, follow these rules:
+
+### Use Male Form as Default
+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.
+
+**Examples of correct usage:**
+- ✅ רופא (not אחות for a nurse role — use אח)
+- ✅ אח (nurse, male form)
+- ✅ מטופל (not מטופלת)
+- ✅ לקוח (not לקוחה)
+- ✅ מנהל (not מנהלת)
+- ✅ עובד (not עובדת)
+- ✅ משתמש (not משתמשת)
+- ✅ סטודנט (not סטודנטית)
+
+**Examples of stereotypic writing to avoid:**
+- ❌ רופא ואחות — implies doctor=male, nurse=female
+- ❌ מזכירה — use מזכיר instead
+- ❌ אחות — use אח instead
+
+### Rule Summary
+> When in doubt, use the male form. This ensures gender neutrality and avoids reinforcing occupational gender stereotypes in diagram content.

package/skills/bpmn-diagram/SKILL.md

@@ -1,93 +1,83 @@
 ---
 name: bpmn-diagram
-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.
+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.
 ---
 
-# BPMN Diagram Creation Skill
+# BPMN Diagram Creation — Phase 1: Structural Model
 
-This skill creates professional BPMN 1.1 diagrams rendered as interactive HTML files with embedded SVG. The diagrams support Hebrew (RTL) and English text.
+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.**
 
-**This skill operates in 3 phases. You MUST complete each phase fully before moving to the next.**
+After the user approves the model, you will use the `bpmn-render` prompt to generate the visual diagram.
 
-## NON-NEGOTIABLE RULES — READ BEFORE ANYTHING ELSE
+## CRITICAL RULES
 
-These rules are violated most often. You MUST follow every one. No exceptions.
+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.
 
-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.
+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).
 
-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).
+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.
 
-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.
+4. **EVERY PARTICIPANT MUST APPEAR**: If the process description mentions a customer/patient/company — they MUST appear in the model. Never omit a participant.
 
-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.
+## Step 1 — Identify Participants
 
-5. **EVERY PARTICIPANT MUST APPEAR**: If the process description mentions a customer/patient/company — they MUST appear in the diagram. Never omit a participant.
+List every actor/role mentioned. For each, classify as POOL or LANE:
 
-## When to Use
-
-- User asks to create a BPMN diagram, process model, or workflow diagram
-- User describes a business process and wants it visualized
-- User provides a process narrative in any language and wants a BPMN representation
-- User asks to model a process with swim lanes, pools, gateways, or data flows
-
----
-
-# ═══════════════════════════════════════════════════
-# PHASE 1 — STRUCTURAL MODEL (text only, NO SVG)
-# ═══════════════════════════════════════════════════
-
-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.
-
-## Step 1.1 — Identify Participants
-
-List every actor/role mentioned in the process. For each one, classify as POOL or LANE:
-
-- **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).
-- **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).
+- **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).
+- **LANE** (within org pool): Internal role within the organization, OR the organization fully dictates how the participant performs activities within its system.
 - **The test**: "Does the organization orchestrate this participant's actions, or do they act independently?" Independent → POOL.
 
-## Step 1.2 — Identify Tasks
+## Step 2 — Identify Tasks
 
-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.
+List every action/task. For each task, specify which lane or pool it belongs to.
 
-## Step 1.3 — Identify Gateways (with type!)
+Look for implied activities — phrases like "is expected to be in phone contact" or "will coordinate directly" describe real tasks, not annotations.
 
-List every decision point / conditional branch. For each gateway, specify:
-- **Type**: XOR (exclusive — only one path), AND (parallel — all paths), or OR (inclusive — one or more paths)
+## Step 3 — Identify Gateways (with type!)
+
+List every decision point. For each gateway specify:
+- **Type**: XOR (only one path taken), AND (all paths taken in parallel), or OR (one or more paths)
 - **Question/condition**: What is being decided
-- **Outgoing branches**: The possible outcomes and where each leads
-- **Merge**: Where the branches reconverge (if applicable) — merge gateways must also be listed with their type
+- **Branches**: The possible outcomes and where each leads
+- **Merge**: Where branches reconverge — merge gateways must also be listed with their type
+
+## Step 4 — Identify Data Stores
 
-## Step 1.4 — Identify Data Stores
+Scan all tasks for persistent storage operations.
 
-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".
+**Trigger words**: "system", "database", "account", "record", "registry".
+**Action verbs**: "block account", "update record", "generate invoice", "credit account", "register", "log", "store", "look up", "check status".
 
-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.
+If ANY task reads/writes shared persistent state → Data Store required. A system = a data store. An account = a data store.
 
-List each data store with a name and which tasks connect to it (read/write).
+List each data store with its name and which tasks connect to it (read/write).
 
-## Step 1.5 — Identify Data Objects
+## Step 5 — Identify Data Objects
 
-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.
+List specific pieces of data flowing between tasks (e.g., "בקשת ביטול", "חשבונית זיכוי"). These are transient documents, not persistent systems.
 
-## Step 1.6 — Identify Flows
+## Step 6 — Identify Flows
 
-- **Sequence flows** (within a pool/between lanes): List the order of tasks within each pool
-- **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.
-- **Data associations**: List connections between tasks and data stores / data objects.
+- **Sequence flows** (within a pool): The order of tasks within each pool
+- **Message flows** (between pools): Every communication between separate pools. Check bidirectional — every message expecting a response needs a return flow.
+- **Data associations**: Connections between tasks and data stores / data objects.
 
-## Step 1.7 — Identify Events
+## Step 7 — Identify Events
 
 - **Start events**: One per pool
-- **End events**: One or more per pool (for different outcomes)
-- **Intermediate events**: Use for passive waiting (not tasks). When a participant is waiting for a signal/message from another participant.
+- **End events**: One or more per pool (different outcomes)
+- **Intermediate events**: For passive waiting (not tasks) — when a participant waits for a signal/message from another participant
 
-## Step 1.8 — Complete Each Participant's Flow
+## Step 8 — Verify Completeness
 
-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.
+- Every pool has a complete flow: start → tasks/gateways → end
+- External parties have their full process modeled, not just a single task
+- Every message that expects a response has a return message flow
 
 ## Required Output Format
 
+Output the model in this exact format:
+
 ```
 STRUCTURAL MODEL:
 
@@ -108,252 +98,28 @@ ORGANIZATION POOL: [org name]
 GATEWAYS:
 - [G1] Type: XOR | Question: [question] | In: [lane/pool] | Branches: [branch1 → ..., branch2 → ...]
 - [G2] Type: XOR (merge) | In: [lane/pool] | Merges: [branches from G1]
-- ...
 
 DATA STORES:
 - [Store name] — reads: [task X, task Y] | writes: [task Z]
-- ...
 
 DATA OBJECTS:
 - [Object name] — from: [task X] → to: [task Y]
-- ...
 
 MESSAGE FLOWS:
 - [Pool A] → [Pool B]: [what is communicated]
 - [Pool B] → [Pool A]: [response]
-- ...
-```
-
-## ⛔ HARD STOP — DO NOT PROCEED
-
-**STOP HERE.** Present the structural model above to the user. Do NOT write any HTML, SVG, or code yet.
-
-Ask the user: "הנה המודל המבני של התהליך. האם לעבור לשלב הבא ולייצר את הדיאגרמה, או שיש שינויים שתרצה לבצע?"
-
-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.
-
----
-
-# ═══════════════════════════════════════════════════
-# PHASE 2 — SVG RENDERING (only after Phase 1 approval)
-# ═══════════════════════════════════════════════════
-
-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.
-
-## Architecture & Layout
-
-### Pools and Lanes
-
-- **External participant pools** get their own pool rectangle, visually separated from the organization pool
-  - Use a distinct color scheme for external pool headers (e.g., brown) to differentiate from the organization pool (dark gray)
-  - External pool tasks use a warm color (e.g., orange `#fff3e0` fill, `#e65100` stroke)
-- **Organization pool** contains internal lanes
-  - Each lane gets a labeled sidebar and a subtle background tint
-  - Separate lanes with dashed divider lines
-- Pool headers are vertical text bars on the left side of the pool
-
-### Element Placement
-
-**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.
-
-### Color Scheme
-
-| Element | Fill | Stroke |
-|---------|------|--------|
-| External participant tasks | `#fff3e0` | `#e65100` |
-| Reception/admin tasks | `#e3f2fd` | `#1976d2` |
-| Clinical/operational tasks | `#f3e5f5` | `#7b1fa2` |
-| XOR Gateways | `#fff8e1` | `#f9a825` |
-| Start event | `#e8f5e9` | `#2e7d32` |
-| End event | `#ffebee` | `#c62828` |
-| Data objects | `#fff` | `#1565c0` |
-| Data stores | `#fff` | `#2e7d32` |
-
-### Pool Ordering
-
-When multiple external pools exist, order to **minimize message flow crossing distance**:
-- Place the primary actor (initiates and interacts with multiple parties) in the middle
-- Place pools they interact with above and below
-
-### Flow Types
-
-- **Sequence flows** (within a pool): Solid lines with filled arrowheads (`#546e7a`)
-- **Message flows** (between pools): Dashed lines (`stroke-dasharray: 10 5`) with open circle at source and filled arrow at target (`#37474f`)
-- **Data associations**: Dashed lines (`stroke-dasharray: 4 3`) with small arrowheads:
-  - Data object associations: `#7986cb`
-  - Data store associations: `#4caf50`
-
-## BPMN Element SVG Templates
-
-### Gateways
-
-**Gateway diamonds contain ONLY the marker symbol — NEVER text.** Labels go ABOVE the diamond.
-
-```svg
-<!-- XOR Gateway (split or merge) — X marker inside -->
-<rect x="X" y="Y" width="34" height="34" class="gateway" transform="rotate(45, CX, CY)"/>
-<line x1="CX-7" y1="CY-10" x2="CX+7" y2="CY+10" class="gateway-x"/>
-<line x1="CX+7" y1="CY-10" x2="CX-7" y2="CY+10" class="gateway-x"/>
-<text x="CX" y="CY-25" text-anchor="middle">label ABOVE</text>
-```
-
-**Anti-pattern — NEVER do this:**
-```svg
-<!-- WRONG: text inside gateway diamond -->
-<polygon points="..." fill="..." stroke="..."/>
-<text x="CX" y="CY">כמה ימים?</text>  <!-- FORBIDDEN -->
 ```
 
-### Intermediate Events (BPMN 1.1 style)
-
-Plain double circle with NO icon inside:
-
-```svg
-<circle cx="X" cy="Y" r="16" fill="#fff" stroke="#1565c0" stroke-width="2"/>
-<circle cx="X" cy="Y" r="12" fill="none" stroke="#1565c0" stroke-width="1.2"/>
-```
-
-### Data Objects (folded-corner document, blue)
-
-```svg
-<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"/>
-<path d="M X+26,Y L X+26,Y+8 L X+34,Y+8" class="data-object-fold"/>
-```
-
-### Data Stores (cylinder, green)
-
-```svg
-<ellipse cx="CX" cy="TOP" rx="28" ry="8" class="data-store-body"/>
-<path d="M CX-28,TOP L CX-28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
-<path d="M CX+28,TOP L CX+28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
-<ellipse cx="CX" cy="BOTTOM" rx="28" ry="8" class="data-store-body"/>
-```
-
-### Data Artifact Placement
-
-- Place data objects above or below their associated task, never overlapping flow lines
-- Place data stores typically below their associated tasks
-- Never place data artifacts where association lines cross sequence flow arrows
-
-## Arrow Routing
-
-**Arrows must never be ambiguous.**
-
-### Split-Merge Pattern
-
-1. YES task above the gateway's horizontal center line
-2. NO task below
-3. Merge gateway clearly to the right of BOTH tasks
-4. YES path: task → right → down into merge (entering from top)
-5. NO path: task → right → up into merge (entering from bottom)
-6. From merge: single clean line to next task
-
-### General Routing Rules
-
-- Prefer orthogonal (right-angle) routing
-- Leave at least 30px spacing between parallel flow lines
-- Cross-lane flows use clear vertical drops/rises
-- Label YES/NO (כן/לא) near the gateway, not at the end of the path
-- Flow labels must not overlap other elements
-
-## Modeling Rejection/Retry Loops
-
-1. Model rejection as an explicit task (not just a gateway output)
-2. After rejection, model the rejecting participant's next state (waiting/action)
-3. Model the response to rejection as a concrete task sequence
-4. Loop-back arrows return to the earliest meaningful re-entry point
-
-## Typography & Hebrew
-
-- Use `Noto Sans Hebrew` (imported from Google Fonts) for all text
-- Set `lang="he"` and `dir="rtl"` on the HTML element
-- Task text: 11.5px, font-weight 500, centered
-- Gateway labels: 10.5px, font-weight 400, positioned above the diamond
-- Data labels: 9.5px, font-weight 500
-- Flow labels: 10px
-
-## File Structure
-
-Output a single self-contained HTML file with:
-
-1. **Header bar**: Gradient background with process title in Hebrew + English subtitle. Must say "BPMN 1.1" (NOT 2.0)
-2. **Legend**: Horizontal bar showing all BPMN symbols used (start, end, task, XOR gateway, intermediate event, data object, data store, message flow)
-3. **SVG canvas**: The full BPMN diagram in a scrollable wrapper
-4. **SVG definitions**: Drop shadow filters, arrow markers (sequence, message, data association)
-
-### SVG Sizing
-
-- Width: 1700–1800px typical (allow overflow scroll)
-- Height: Scale based on pools and lanes (~130px per external pool, ~250px per lane, plus data artifacts)
-- Use `viewBox` matching width/height
-
----
-
-# ═══════════════════════════════════════════════════
-# PHASE 3 — VALIDATION & FIX
-# ═══════════════════════════════════════════════════
-
-**Before delivering the diagram, go through EVERY item below. If ANY item fails, fix the SVG immediately. Do NOT deliver until all pass.**
-
-## Structural Accuracy (cross-reference with Phase 1 model)
-- [ ] Every participant from the Phase 1 model appears in the SVG — none are omitted
-- [ ] External participants are in separate pools with message flows (not lanes with sequence flows)
-- [ ] Every pool has a complete internal flow (start → ... → end)
-- [ ] Every gateway from Phase 1 appears with the correct type marker
-- [ ] Every data store from Phase 1 appears as a cylinder with data associations
-- [ ] Every message flow from Phase 1 appears as a dashed line between pools
-
-## BPMN Compliance
-- [ ] Every gateway (split AND merge) has ONLY an X/+/O marker inside — no text inside the diamond
-- [ ] Gateway labels are positioned ABOVE or BESIDE the diamond, never inside
-- [ ] Every element (task, gateway, event) is fully inside a single lane — nothing sits on a lane boundary
-- [ ] Passive waiting uses intermediate events, not regular tasks
-- [ ] Data objects (folded document) and data stores (cylinder) use different icons
-
-## Visual Quality
-- [ ] No arrow paths overlap or cross ambiguously
-- [ ] Flow labels (כן/לא) are clearly positioned near their gateway
-- [ ] The legend includes every symbol type used in the diagram
-- [ ] Data artifacts don't overlap with sequence flow paths
-- [ ] Pool ordering minimizes message flow crossing distance
-
----
-
-# APPENDIX
-
-## Example Process Categories
-
-This skill handles processes such as:
-- Healthcare workflows (e.g., Tipat Halav clinic visits, hospital admissions)
-- Government/municipal service processes
-- Customer service and support flows
-- Order fulfillment and logistics
-- Employee onboarding
-- Academic/educational administration processes
-
-The skill works for any domain — adapt the color scheme and terminology to match the context.
-
-## Hebrew Language Guidelines (שפה מגדרית נייטרלית)
+## After Outputting the Model
 
-When labels, names, actors, roles, or any text in the diagram are written in Hebrew, follow these rules:
+Present the model and ask the user:
 
-### Use Male Form as Default
-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.
+**"הנה המודל המבני של התהליך. האם לעבור לשלב הבא ולייצר את הדיאגרמה, או שיש שינויים?"**
 
-**Examples of correct usage:**
-- ✅ רופא (not אחות for a nurse role — use אח)
-- ✅ אח (nurse, male form)
-- ✅ מטופל (not מטופלת)
-- ✅ לקוח (not לקוחה)
-- ✅ מנהל (not מנהלת)
-- ✅ עובד (not עובדת)
-- ✅ משתמש (not משתמשת)
-- ✅ סטודנט (not סטודנטית)
+When the user confirms, use the **`bpmn-render`** prompt to generate the visual diagram. Pass it the approved structural model.
 
-**Examples of stereotypic writing to avoid:**
-- ❌ רופא ואחות — implies doctor=male, nurse=female
-- ❌ מזכירה — use מזכיר instead
-- ❌ אחות — use אח instead
+## Hebrew Language Guidelines
 
-### Rule Summary
-> When in doubt, use the male form. This ensures gender neutrality and avoids reinforcing occupational gender stereotypes in diagram content.
+Use the **male grammatical form** (זכר) for all roles and participants:
+- ✅ רופא, אח, מטופל, לקוח, מנהל, עובד, משתמש, סטודנט
+- ❌ אחות, מטופלת, לקוחה, מנהלת, מזכירה

package/skills/bpmn-render/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: bpmn-render
+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."
+---
+
+# BPMN Rendering — Phase 2 & 3
+
+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.
+
+**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.**
+
+## NON-NEGOTIABLE RENDERING RULES
+
+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.
+
+2. **EXTERNAL PARTICIPANTS** are separate pools with message flows (dashed). NOT lanes.
+
+3. **DATA STORES** appear as cylinders with data association lines to their tasks.
+
+4. **NO ELEMENTS ON LANE BOUNDARIES**: Every element fully inside one lane, centered vertically.
+
+## Architecture & Layout
+
+### Pools and Lanes
+
+- **External participant pools**: Own pool rectangle, visually separated. Brown header, orange tasks (`#fff3e0` fill, `#e65100` stroke).
+- **Organization pool**: Dark gray header, contains internal lanes. Each lane has a labeled sidebar and subtle background tint. Dashed divider lines between lanes.
+- Pool headers: Vertical text bars on the left side.
+
+### Element Placement
+
+Every BPMN element must be fully contained within a single lane or pool. Center elements vertically within their lane with visible spacing from borders.
+
+### Color Scheme
+
+| Element | Fill | Stroke |
+|---------|------|--------|
+| External participant tasks | `#fff3e0` | `#e65100` |
+| Reception/admin tasks | `#e3f2fd` | `#1976d2` |
+| Clinical/operational tasks | `#f3e5f5` | `#7b1fa2` |
+| XOR Gateways | `#fff8e1` | `#f9a825` |
+| Start event | `#e8f5e9` | `#2e7d32` |
+| End event | `#ffebee` | `#c62828` |
+| Data objects | `#fff` | `#1565c0` |
+| Data stores | `#fff` | `#2e7d32` |
+
+### Pool Ordering
+
+When multiple external pools exist, minimize message flow crossing distance:
+- Primary actor (initiates, interacts with multiple parties) in the middle
+- Interacting pools above and below
+
+### Flow Types
+
+- **Sequence flows** (within a pool): Solid lines, filled arrowheads (`#546e7a`)
+- **Message flows** (between pools): Dashed lines (`stroke-dasharray: 10 5`), open circle at source, filled arrow at target (`#37474f`)
+- **Data associations**: Dashed lines (`stroke-dasharray: 4 3`), small arrowheads:
+  - Data object: `#7986cb`
+  - Data store: `#4caf50`
+
+## SVG Templates
+
+### XOR Gateway (split or merge)
+
+```svg
+<rect x="X" y="Y" width="34" height="34" class="gateway" transform="rotate(45, CX, CY)"/>
+<line x1="CX-7" y1="CY-10" x2="CX+7" y2="CY+10" class="gateway-x"/>
+<line x1="CX+7" y1="CY-10" x2="CX-7" y2="CY+10" class="gateway-x"/>
+<text x="CX" y="CY-25" text-anchor="middle">label ABOVE diamond</text>
+```
+
+**WRONG — never do this:**
+```svg
+<polygon points="..." fill="..." stroke="..."/>
+<text x="CX" y="CY">text inside diamond</text>  <!-- FORBIDDEN -->
+```
+
+### Intermediate Events (BPMN 1.1)
+
+Plain double circle, NO icon inside:
+```svg
+<circle cx="X" cy="Y" r="16" fill="#fff" stroke="#1565c0" stroke-width="2"/>
+<circle cx="X" cy="Y" r="12" fill="none" stroke="#1565c0" stroke-width="1.2"/>
+```
+
+### Data Objects (folded document, blue)
+
+```svg
+<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"/>
+<path d="M X+26,Y L X+26,Y+8 L X+34,Y+8" class="data-object-fold"/>
+```
+
+### Data Stores (cylinder, green)
+
+```svg
+<ellipse cx="CX" cy="TOP" rx="28" ry="8" class="data-store-body"/>
+<path d="M CX-28,TOP L CX-28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
+<path d="M CX+28,TOP L CX+28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
+<ellipse cx="CX" cy="BOTTOM" rx="28" ry="8" class="data-store-body"/>
+```
+
+### Data Artifact Placement
+
+- Data objects above or below their task, never overlapping flow lines
+- Data stores typically below their tasks
+- Association lines must not cross sequence flow arrows
+
+## Arrow Routing
+
+**Arrows must never be ambiguous.**
+
+### Split-Merge Pattern
+
+1. YES task above gateway center, NO task below
+2. Merge gateway to the right of BOTH tasks
+3. YES path: task → right → down into merge (from top)
+4. NO path: task → right → up into merge (from bottom)
+5. Single clean line from merge to next task
+
+### General Rules
+
+- Orthogonal (right-angle) routing preferred
+- At least 30px between parallel flow lines
+- Cross-lane flows: clear vertical drops/rises
+- Labels (כן/לא) near the gateway, not at path end
+- Flow labels must not overlap other elements
+
+### Rejection/Retry Loops
+
+- Rejection = explicit task (not just gateway output)
+- After rejection: model the rejecting participant's next state
+- Response to rejection = concrete task sequence
+- Loop-back to earliest meaningful re-entry point
+
+## Typography & Hebrew
+
+- `Noto Sans Hebrew` from Google Fonts
+- `lang="he"` and `dir="rtl"` on HTML element
+- Task text: 11.5px, font-weight 500, centered
+- Gateway labels: 10.5px, font-weight 400, above diamond
+- Data labels: 9.5px, font-weight 500
+- Flow labels: 10px
+
+## File Structure
+
+Single self-contained HTML file:
+
+1. **Header bar**: Gradient, process title in Hebrew + English subtitle. Must say "BPMN 1.1"
+2. **Legend**: All BPMN symbols used (start, end, task, XOR gateway, intermediate event, data object, data store, message flow)
+3. **SVG canvas**: Full diagram in scrollable wrapper
+4. **SVG definitions**: Drop shadow filters, arrow markers
+
+### SVG Sizing
+
+- Width: 1700–1800px (overflow scroll)
+- Height: ~130px per external pool, ~250px per lane, plus data artifacts
+- `viewBox` matching width/height
+
+---
+
+# PHASE 3 — VALIDATION
+
+**Before delivering, verify EVERY item. Fix any failure before delivering.**
+
+## Structural Accuracy (cross-reference with approved model)
+- [ ] Every participant from the model appears — none omitted
+- [ ] External participants are separate pools with message flows
+- [ ] Every pool has complete flow (start → ... → end)
+- [ ] Every gateway has the correct type marker (X/+/O) — no text inside
+- [ ] Every data store appears as a cylinder with data associations
+- [ ] Every message flow appears as dashed line between pools
+
+## BPMN Compliance
+- [ ] Gateway labels ABOVE or BESIDE the diamond, never inside
+- [ ] Every element fully inside one lane — nothing on boundaries
+- [ ] Passive waiting uses intermediate events, not tasks
+- [ ] Data objects (folded document) and data stores (cylinder) are visually distinct
+
+## Visual Quality
+- [ ] No arrow paths overlap or cross ambiguously
+- [ ] Flow labels clearly positioned near their gateway
+- [ ] Legend includes every symbol type used
+- [ ] Data artifacts don't overlap sequence flow paths
+- [ ] Pool ordering minimizes message flow crossing distance
+
+## Hebrew Language
+- [ ] Male grammatical form used for all roles (רופא not אחות, אח not אחות, מטופל not מטופלת)