agentic-mermaid 0.4.1 → 0.5.3

package/skills/agentic-mermaid-diagram-workflow/references/upstream/classDiagram.md

@@ -72,6 +72,129 @@ classDiagram
     }
 ```
 
+## Default theme, look and layout (v12.0.0+)
+
+Class diagrams use the `redux-color` theme and the `neo` look by default, and are laid out by [ELK](https://www.eclipse.org/elk/) rather than Dagre. Not every diagram type
+does — see [Per-diagram defaults](../config/theming.md#per-diagram-defaults) for the list and
+for the order in which Mermaid decides.
+
+The same diagram, drawn both ways:
+
+### With the defaults
+
+```mermaid-example
+classDiagram
+  class Customer {
+    +String name
+    +String email
+  }
+  class Order {
+    +String id
+    +Date placedAt
+    +total() Money
+  }
+  class LineItem {
+    +int quantity
+  }
+  class Payment {
+    <<interface>>
+    +authorise() bool
+  }
+  Customer "1" --> "*" Order : places
+  Order "1" *-- "*" LineItem : contains
+  Order --> Payment : settled by
+```
+
+```mermaid
+classDiagram
+  class Customer {
+    +String name
+    +String email
+  }
+  class Order {
+    +String id
+    +Date placedAt
+    +total() Money
+  }
+  class LineItem {
+    +int quantity
+  }
+  class Payment {
+    <<interface>>
+    +authorise() bool
+  }
+  Customer "1" --> "*" Order : places
+  Order "1" *-- "*" LineItem : contains
+  Order --> Payment : settled by
+```
+
+### The previous appearance
+
+Both are only defaults, so anything you set yourself wins. Naming the previous theme and look
+in a diagram's front matter draws it the way Mermaid did before:
+
+```mermaid-example
+---
+config:
+  theme: default
+  look: classic
+  layout: dagre
+---
+classDiagram
+  class Customer {
+    +String name
+    +String email
+  }
+  class Order {
+    +String id
+    +Date placedAt
+    +total() Money
+  }
+  class LineItem {
+    +int quantity
+  }
+  class Payment {
+    <<interface>>
+    +authorise() bool
+  }
+  Customer "1" --> "*" Order : places
+  Order "1" *-- "*" LineItem : contains
+  Order --> Payment : settled by
+```
+
+```mermaid
+---
+config:
+  theme: default
+  look: classic
+  layout: dagre
+---
+classDiagram
+  class Customer {
+    +String name
+    +String email
+  }
+  class Order {
+    +String id
+    +Date placedAt
+    +total() Money
+  }
+  class LineItem {
+    +int quantity
+  }
+  class Payment {
+    <<interface>>
+    +authorise() bool
+  }
+  Customer "1" --> "*" Order : places
+  Order "1" *-- "*" LineItem : contains
+  Order --> Payment : settled by
+```
+
+Passing the same three keys to `mermaid.initialize()` does it for every diagram on the page,
+and scoping the theme and look to one diagram type — `mermaid.initialize({ layout: 'dagre', class: { theme: 'default', look: 'classic' } })` —
+does it for that type alone. `layout` is a top-level option, so it applies to every diagram.
+
 ## Syntax
 
 ### Class

package/skills/agentic-mermaid-diagram-workflow/references/upstream/cynefin.md

@@ -228,7 +228,12 @@ Cynefin diagrams accept the following configuration under the `cynefin` key in t
 Example:
 
 ```
-%%{init: {'cynefin': {'width': 1000, 'showDomainDescriptions': false}}}%%
+---
+config:
+  cynefin:
+    width: 1000
+    showDomainDescriptions: false
+---
 cynefin-beta
   complex
     "Adaptive work"

package/skills/agentic-mermaid-diagram-workflow/references/upstream/entityRelationshipDiagram.md

@@ -80,6 +80,129 @@ erDiagram
 
 When including attributes on ER diagrams, you must decide whether to include foreign keys as attributes. This probably depends on how closely you are trying to represent relational table structures. If your diagram is a _logical_ model which is not meant to imply a relational implementation, then it is better to leave these out because the associative relationships already convey the way that entities are associated. For example, a JSON data structure can implement a one-to-many relationship without the need for foreign key properties, using arrays. Similarly an object-oriented programming language may use pointers or references to collections. Even for models that are intended for relational implementation, you might decide that inclusion of foreign key attributes duplicates information already portrayed by the relationships, and does not add meaning to entities. Ultimately, it's your choice.
 
+## Default theme, look and layout (v12.0.0+)
+
+Entity relationship diagrams use the `redux-color` theme and the `neo` look by default, and are laid out by [ELK](https://www.eclipse.org/elk/) rather than Dagre. Not every diagram type
+does — see [Per-diagram defaults](../config/theming.md#per-diagram-defaults) for the list and
+for the order in which Mermaid decides.
+
+The same diagram, drawn both ways:
+
+### With the defaults
+
+```mermaid-example
+erDiagram
+  CUSTOMER ||--o{ ORDER : places
+  ORDER ||--|{ LINE_ITEM : contains
+  PRODUCT ||--o{ LINE_ITEM : "appears in"
+  CUSTOMER {
+    string name
+    string email
+  }
+  ORDER {
+    int id
+    date placedAt
+  }
+  LINE_ITEM {
+    int quantity
+    float price
+  }
+  PRODUCT {
+    string sku
+    string title
+  }
+```
+
+```mermaid
+erDiagram
+  CUSTOMER ||--o{ ORDER : places
+  ORDER ||--|{ LINE_ITEM : contains
+  PRODUCT ||--o{ LINE_ITEM : "appears in"
+  CUSTOMER {
+    string name
+    string email
+  }
+  ORDER {
+    int id
+    date placedAt
+  }
+  LINE_ITEM {
+    int quantity
+    float price
+  }
+  PRODUCT {
+    string sku
+    string title
+  }
+```
+
+### The previous appearance
+
+Both are only defaults, so anything you set yourself wins. Naming the previous theme and look
+in a diagram's front matter draws it the way Mermaid did before:
+
+```mermaid-example
+---
+config:
+  theme: default
+  look: classic
+  layout: dagre
+---
+erDiagram
+  CUSTOMER ||--o{ ORDER : places
+  ORDER ||--|{ LINE_ITEM : contains
+  PRODUCT ||--o{ LINE_ITEM : "appears in"
+  CUSTOMER {
+    string name
+    string email
+  }
+  ORDER {
+    int id
+    date placedAt
+  }
+  LINE_ITEM {
+    int quantity
+    float price
+  }
+  PRODUCT {
+    string sku
+    string title
+  }
+```
+
+```mermaid
+---
+config:
+  theme: default
+  look: classic
+  layout: dagre
+---
+erDiagram
+  CUSTOMER ||--o{ ORDER : places
+  ORDER ||--|{ LINE_ITEM : contains
+  PRODUCT ||--o{ LINE_ITEM : "appears in"
+  CUSTOMER {
+    string name
+    string email
+  }
+  ORDER {
+    int id
+    date placedAt
+  }
+  LINE_ITEM {
+    int quantity
+    float price
+  }
+  PRODUCT {
+    string sku
+    string title
+  }
+```
+
+Passing the same three keys to `mermaid.initialize()` does it for every diagram on the page,
+and scoping the theme and look to one diagram type — `mermaid.initialize({ layout: 'dagre', er: { theme: 'default', look: 'classic' } })` —
+does it for that type alone. `layout` is a top-level option, so it applies to every diagram.
+
 ## Syntax
 
 ### Entities and Relationships
@@ -448,7 +571,7 @@ Possible diagram orientations are:
 - RL - Right to left
 - LR - Left to right
 
-### Subgraphs (v\<MERMAID_RELEASE_VERSION>+)
+### Subgraphs (v11.17.0+)
 
 Subgraphs allow grouping entities into logical sections within an ER diagram. They are useful for organizing
 complex diagrams and improving readability.
@@ -853,14 +976,14 @@ erDiagram
 
 ### Layout
 
-The layout of the diagram is handled by [`render()`](../config/setup/mermaid/interfaces/Mermaid.md#render). The default layout is dagre.
+The layout of the diagram is handled by [`render()`](../config/setup/mermaid/interfaces/Mermaid.md#render). The default layout is the ELK (Eclipse Layout Kernel) layout, which suits larger and more-complex diagrams. For more information, see [Customizing ELK Layout](../intro/syntax-reference.md#customizing-elk-layout).
 
-For larger or more-complex diagrams, you can alternatively apply the ELK (Eclipse Layout Kernel) layout using your YAML frontmatter's `config`. For more information, see [Customizing ELK Layout](../intro/syntax-reference.md#customizing-elk-layout).
+To use the classic Dagre layout instead, set it in your YAML frontmatter's `config`:
 
 ```yaml
 ---
 config:
-  layout: elk
+  layout: dagre
 ---
 ```
 
@@ -870,7 +993,7 @@ Your Mermaid code should be similar to the following:
 ---
 title: Order example
 config:
-    layout: elk
+    layout: dagre
 ---
 erDiagram
     CUSTOMER ||--o{ ORDER : places
@@ -882,7 +1005,7 @@ erDiagram
 ---
 title: Order example
 config:
-    layout: elk
+    layout: dagre
 ---
 erDiagram
     CUSTOMER ||--o{ ORDER : places
@@ -890,7 +1013,4 @@ erDiagram
     CUSTOMER }|..|{ DELIVERY-ADDRESS : uses
 ```
 
-> **Note**
-> Note that the site needs to use mermaid version 9.4+ for this to work and have this featured enabled in the lazy-loading configuration.
-
 <!--- cspell:locale en,en-gb --->

package/skills/agentic-mermaid-diagram-workflow/references/upstream/eventmodeling.md

@@ -68,6 +68,8 @@ tf 03 evt ItemAdded
 
 Each Time Frame is referenced by a **unique number** in order to distinguish one from another and also to be able to reference it when needed. Depending on the complexity of the diagram it should be enough to have just two digit number or more. Imagine you are typing a BASIC program on your ZX Spectrum always starting with a two digit number, but the order of the numbers does not matter, just the uniqueness in the whole timeline.
 
+Reusing a number for another Time Frame or Reset Frame produces an error. Give each frame its own number before referring to it with `->>`.
+
 The Time Frame also contains an **Entity Identifier**, e.g. in case of `01` Time Frame it is `CartUI`. One Entity Identifier can be used multiple times in the timeline for example when you want to express invocations of the same event in different points in time.
 
 Relaxed notation would look like this:
@@ -246,6 +248,8 @@ data ItemAdded {
 
 By default the diagram builds the relations based on the inference. But modeling a more complex business flow requires to break such inference from time to time. For that you can use a different type of Time Frame called **Reset Frame**. It is represented by a `rf` / `resetframe` token.
 
+A reset frame stops the inferred relation from the preceding frame. You can still connect it to a specific earlier frame with `->>`.
+
 Compact version:
 
 ```mermaid-example
@@ -302,6 +306,24 @@ timeframe 06 command ChangeInventory
 timeframe 07 event Cart.InventoryChanged
 ```
 
+For example, this read model receives input from `ItemAdded` without inferring a relation from `OtherUI`:
+
+```mermaid-example
+eventmodeling
+
+tf 01 evt ItemAdded
+tf 02 ui OtherUI
+rf 03 rmo CartItems ->> 01
+```
+
+```mermaid
+eventmodeling
+
+tf 01 evt ItemAdded
+tf 02 ui OtherUI
+rf 03 rmo CartItems ->> 01
+```
+
 ### Multiple relations
 
 There are situations where you need to specify multiple relations for an entity. For example when a **Read Model** is built of multiple **Events**. You can use `->>` token for that.