[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CTW03T8EDSRKZW3DFMT7CC":3,"skill-same:01M7CTW03T8EDSRKZW3DFMT7CC":117},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":32,"install":33,"resources":46},"01M7CTW03T8EDSRKZW3DFMT7CC","mermaid-diagrams",null,"Use when architecture, ownership, state, sequence, dependencies, data flow, trust boundaries, or failure and recovery paths are difficult to understand from prose alone.","amoai-tech\u002Fmdeai","amoai-tech","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F320616881?v=4","01M7CTJYGWP82J2HHMQC5NN9JP","amo","01M7CTJYHE5YQRGQSDJES3Z0QE",2,"MIT","https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: mermaid-diagrams\ndescription: >-\n  Use when architecture, ownership, state, sequence, dependencies, data flow, trust boundaries, or failure and recovery paths are difficult to understand from prose alone.\nversion: \"2.0.0-mde.2\"\n---\n\n# Mermaid — MDE engineering reasoning standard\n\nMermaid is not decorative documentation. In MDE it is a **selective thinking, review, and defect-prevention tool**. Do not load it for trivial edits where prose or the diff is clearer.\n\nUse diagrams to answer questions prose hides:\n\n```text\nWhat talks to what?\nWho owns the write?\nWhere is auth enforced?\nWhat must happen before what?\nWhat can fail?\nWhat retries?\nWhat is irreversible?\nWhat blocks the task?\nWhat state is durable?\nWhere can tenant data cross?\nWhat evidence proves the journey?\n```\n\nMermaid's official purpose is to keep documentation closer to development using text-based diagrams that are easy to edit and version. Keep diagrams close to the task\u002Fcode they explain and update them when the implementation changes.\n\n## Mandatory MDE diagram pass\n\nUse this skill when a substantial `SAN-*` task has non-trivial relationships, state, sequence, ownership, dependencies, trust boundaries, or failure\u002Frecovery paths:\n\n1. **Task overview:** include one diagram showing the end-to-end user\u002Fsystem outcome.\n2. **Architecture\u002Fownership:** diagram every material boundary crossed by the task.\n3. **Dependencies\u002Fblockers:** show predecessor, downstream, external, and human-approval dependencies when material.\n4. **Each substantive task section or file\u002Fworkflow group:** add the diagram that best exposes its behavior, ownership, data, state, or failure path.\n5. **Negative\u002Frecovery:** include failure\u002Ferror\u002Fretry\u002Frollback branches for risky work.\n6. **Verification:** show how expected state\u002Fevidence is reached when the path is non-trivial.\n7. **PR:** include the smallest diagrams that let a reviewer understand changed architecture\u002Fuser flow without reconstructing it from code.\n8. **Post-merge:** update diagrams if the merged implementation differs from the planned model.\n\nIf a section truly has no meaningful relationship, state, dependency, sequence, or decision to visualize, write:\n\n```text\nDiagram: N\u002FA — no meaningful relationship\u002Fstate\u002Fsequence to model.\n```\n\nDo **not** create filler diagrams merely to satisfy the rule.\n\n## Diagram-first defect discovery\n\nBefore implementation, draw the current and target path. Then actively inspect the diagram for:\n\n| Red flag | What to look for in the diagram |\n|---|---|\n| Missing owner | node\u002Faction with no authoritative service\u002Fdomain owner |\n| Second source of truth | two durable stores claiming the same business truth |\n| Auth gap | browser\u002Fclient reaches protected state before server authorization |\n| Tenant leak | org\u002Fresource ID crosses boundary without revalidation |\n| Hidden write | read-looking path triggers mutation\u002Fwebhook\u002FRPC side effect |\n| HITL bypass | AI\u002Ftool reaches consequential write without explicit human gate |\n| Wrong approval | approval is not tied to exact artifact\u002Frevision\u002Fhash |\n| Retry duplication | retry\u002Fresume\u002Fcallback can traverse a write twice |\n| Dead end | failure branch has no recovery\u002Frollback\u002Foperator outcome |\n| Circular dependency | tasks\u002Fservices wait on each other |\n| Stale dependency | diagram points to deprecated route\u002Fservice\u002Fskill\u002Fprovider |\n| Unowned failure | external\u002Fprovider error has no caller handling or escalation |\n| Missing evidence | final state has no observable test\u002Freadback\u002Ftrace proving it |\n| Over-coupling | one file\u002Fservice owns unrelated responsibilities |\n| Race condition | concurrent paths can mutate the same state without arbitration |\n| Secret exposure | credential\u002Ftoken enters model, memory, snapshot, client, or trace path |\n\nIf the diagram reveals a red flag, **stop and correct the task\u002Farchitecture before coding** when the issue is load-bearing.\n\n## Choose the right diagram\n\nUse the smallest type that makes the hidden relationship obvious.\n\n| Development question | Preferred Mermaid type | Best MDE use |\n|---|---|---|\n| What is the end-to-end path or decision? | `flowchart` | task overview, request path, validation, fallback, failure branches |\n| Which actor\u002Fservice calls what, in what order? | `sequenceDiagram` | auth, API, CopilotKit\u002FAG-UI, Mastra tools, webhook\u002Fcallback, write\u002Freadback |\n| What states\u002Ftransitions are legal? | `stateDiagram-v2` | approvals, workflow lifecycle, booking, publish status, retry\u002Fcancel\u002Fexpiry |\n| What tables\u002Fentities relate? | `erDiagram` | Supabase schemas, FK\u002Fcardinality, durable ownership |\n| What classes\u002Ftypes\u002Finterfaces relate? | `classDiagram` | domain types, SDK interfaces, component\u002Fservice structure |\n| What services\u002Fresources are deployed together? | `architecture-beta` \u002F architecture diagram | Cloudflare, Supabase, queues, storage, CI\u002FCD\u002Fruntime topology |\n| What are the system\u002Fcontainer boundaries? | C4 | high-level platform context\u002Fcontainer\u002Fcomponent views; use carefully because Mermaid C4 remains marked experimental\u002Fbeta in official docs |\n| Where do responsibilities cross teams\u002Fservices? | swimlane\u002Fflowchart with subgraphs | frontend\u002Fbackend\u002FAI\u002Foperator handoffs |\n| What does the operator experience? | `journey` | user pain points\u002Fsatisfaction; use flowchart for system correctness details |\n| What must happen over time? | `timeline` | migrations, incidents, release history, dependency chronology |\n| What is scheduled and dependency-bound? | `gantt` | roadmap\u002Frelease\u002Fmigration sequencing; not runtime control flow |\n| Which requirement is satisfied by which design\u002Ftest? | `requirementDiagram` | acceptance-criteria traceability, safety requirements |\n| What is on the board now\u002Fnext\u002Flater? | `kanban` | execution planning\u002Fstatus, not architecture |\n| What branches\u002Fmerges occurred? | `gitGraph` | release\u002Fbranch history when it clarifies integration risk |\n| How do ideas\u002Ffeatures decompose? | `mindmap` | discovery, scope decomposition, product taxonomy; not proof of runtime behavior |\n| How should options be prioritized? | `quadrantChart` | impact vs effort\u002Frisk, vendor\u002Ffeature choice |\n| What quantity changes over time\u002Fcategory? | `xychart-beta` | performance, latency, test counts, trends |\n| How does quantity\u002Fvolume flow between stages? | `sankey-beta` | funnel\u002Fdata\u002Fmedia processing volume; not authorization flow |\n| What network\u002Fprotocol fields exist? | `packet-beta` | webhook\u002Fprotocol payload layouts when field order\u002Fwidth matters |\n| How are layout blocks related? | `block-beta` | compact topology\u002Flayout when flowchart positioning is insufficient |\n| What dimensions differ across options? | `radar-beta` | architecture\u002Fvendor comparison; label assumptions |\n| What events\u002Fcommands\u002Fread models form a domain flow? | event modeling | business process\u002Fevent-driven design |\n| What sets overlap? | Venn | capability\u002Fownership overlap, duplicate scope detection |\n| What causes a failure? | Ishikawa | root-cause analysis after incident\u002Ftest failure |\n| What capabilities create value vs maturity? | Wardley | strategic platform\u002Fvendor\u002Fbuild-vs-buy discussion only |\n| How uncertain\u002Fcomplex is a decision? | Cynefin | problem-classification workshop; not implementation proof |\n| What is the hierarchy\u002Ftree? | TreeView | route\u002Fcomponent\u002Fdomain hierarchy when hierarchy itself is the question |\n| What parts contribute proportionally? | treemap | code\u002Fdomain\u002Fportfolio composition; not workflow order |\n| What does control flow look like with richer loops\u002Fbranches? | ZenUML | complex call sequence when standard sequence syntax becomes unreadable |\n\nOfficial Mermaid 11.17.2 currently lists flowchart, swimlanes, sequence, class, state, ER, user journey, Gantt, pie, quadrant, requirement, GitGraph, C4, mindmaps, timeline, ZenUML, Sankey, XY, block, packet, Kanban, architecture, radar, event modeling, treemap, Venn, Ishikawa, Wardley, Cynefin, and TreeView among supported syntax families. Verify exact syntax\u002Ffeatures against the target renderer before relying on newer\u002Fbeta types.\n\n## MDE diagram set by development phase\n\n### 1. Task discovery\n\nMinimum useful set for a substantial task:\n\n```text\nflowchart       → current → target user\u002Fsystem journey\narchitecture    → ownership + source-of-truth boundaries\nrequirement     → AC → implementation\u002Ftest trace when requirements are complex\n```\n\nUse a **current-state diagram first**, then target state. The difference is the actual task scope.\n\n### 2. File\u002Fworkflow planning\n\nFor each substantive file\u002Fgroup, ask:\n\n```text\nDoes this file change call order?       → sequence\nDoes it change decisions\u002Fbranches?      → flowchart\nDoes it change lifecycle\u002Fstate?         → state\nDoes it change durable relationships?   → ER\nDoes it change service boundaries?      → architecture\u002FC4\nDoes it implement AC dependencies?      → requirement\nOtherwise                               → Diagram: N\u002FA with reason\n```\n\nA file diagram should show **why the file exists in the task**, not every import\u002Ffunction.\n\n### 3. Implementation\n\nKeep diagrams synchronized with discovered reality. If code inspection disproves the planned diagram:\n\n```text\nupdate diagram\n→ update task assumption\n→ update implementation plan\n→ only then code\n```\n\nDo not force code to match a stale diagram.\n\n### 4. Review \u002F pre-merge\n\nReview diagrams for structural defects before reading every changed line:\n\n```text\nentry → auth → trusted context → business logic → side effect → durable state → readback\n```\n\nMark critical branches explicitly:\n- unauthorized \u002F cross-org;\n- malformed\u002Fempty\u002Fstale input;\n- provider\u002Fnetwork failure;\n- retry\u002Fduplicate\u002Fconcurrent action;\n- reject\u002Fcancel\u002Fexpiry;\n- rollback\u002Fcompensation;\n- observable success.\n\n### 5. Post-merge \u002F incident\n\nUse:\n- sequence\u002Fflowchart to compare expected vs actual runtime path;\n- timeline for incident chronology;\n- Ishikawa for root-cause categories;\n- state diagram for invalid\u002Funexpected state transition;\n- architecture\u002FER for ownership or data-integrity drift.\n\nConvert the discovered failure branch into a permanent regression test when practical.\n\n## MDE canonical examples\n\n### AI proposal → approval → durable write\n\n```mermaid\nflowchart LR\n    U[Operator] --> UI[MDE UI]\n    UI --> API[Authenticated server boundary]\n    API --> AI[Mastra agent\u002Fworkflow]\n    AI --> P[Proposal artifact + revision + hash]\n    P --> R{Human review}\n    R -- Reject --> X[Terminal reject\u002Frevision path]\n    R -- Approve exact artifact --> V[Server revalidates org\u002Frun\u002Fstep\u002Fhash]\n    V --> W[Idempotent domain write]\n    W --> DB[(Supabase\u002Fdomain truth)]\n    DB --> RB[UI readback]\n```\n\nReview questions: Can AI bypass `R`? Can `V` receive stale\u002Fwrong tenant data? Can `W` run twice? Can UI claim success before `DB`?\n\n### External provider failure\u002Fretry\n\n```mermaid\nsequenceDiagram\n    actor Operator\n    participant API as MDE server\n    participant Provider\n    participant DB as Durable state\n\n    Operator->>API: Start action\n    API->>Provider: Request with operation\u002Fidempotency identity\n    alt provider succeeds\n        Provider-->>API: Success + provider ID\n        API->>DB: Commit\u002Freconcile once\n        DB-->>Operator: Durable success\n    else timeout \u002F response lost\n        Provider--xAPI: Unknown outcome\n        API->>DB: Reconcile by stable identity\n        API->>Provider: Retry only if safe\n    else provider rejects\n        Provider-->>API: Typed failure\n        API-->>Operator: Recoverable error; no fake success\n    end\n```\n\nThis makes the response-loss\u002Fidempotency hole visible before implementation.\n\n## Quality rules\n\n1. **One question per diagram.** Split views when one diagram tries to explain architecture + sequence + states + schedule simultaneously.\n2. **Model authoritative boundaries, not visual decoration.** Labels should name real MDE components\u002Fservices\u002Ftasks where known.\n3. **Current vs target must be distinguishable.** Never mix them without labels.\n4. **Show negative paths for risky work.** A happy-path-only security\u002FHITL\u002Fpayment\u002Fpublishing diagram is incomplete.\n5. **Show human gates explicitly.** Never imply AI self-approval.\n6. **Show durable stores explicitly.** Readers should see where truth is persisted.\n7. **Show external systems explicitly.** Do not hide provider behavior inside a generic backend box.\n8. **Show trust boundaries explicitly.** Browser-provided IDs are claims until server verified.\n9. **Prefer stable IDs\u002Fnames over volatile implementation detail.** Keep diagrams useful across refactors.\n10. **Keep diagrams readable.** If a diagram needs extensive prose to decode, split it.\n11. **Use labels on decision edges.** `Yes\u002FNo`, `valid\u002Finvalid`, `approved\u002Frejected`, `success\u002Ffailure`.\n12. **Do not invent facts.** Unknown edges\u002Fnodes should be marked `TBD \u002F unverified` until inspected.\n13. **Do not use a diagram as proof.** It defines expected structure; tests\u002Fruntime evidence prove actual behavior.\n14. **Validate syntax.** Unknown words\u002Fmisspellings can break Mermaid; parameters may fail silently. Use the target renderer or Mermaid Live Editor when needed.\n15. **Version-sensitive syntax:** newer\u002Fbeta diagram types must not be assumed supported by every Markdown renderer.\n16. **No secrets or protected payloads in diagram source.** Use stable IDs\u002Fplaceholders, not JWTs, cookies, service keys, provider credentials, passwords, raw customer records, or unnecessary PII. Diagram text is source content that may be rendered, stored, copied, indexed, or exported.\n17. **Do not weaken renderer security for convenience.** Mermaid's default `securityLevel` is `strict`; interactive links\u002FHTML require looser settings. Any change to renderer trust\u002Fsecurity is a separate implementation\u002Fsecurity decision, not a diagram-authoring shortcut.\n18. **Accessibility:** for important architecture, state, sequence, and user-journey diagrams, provide concise accessible title\u002Fdescription metadata when the target renderer supports it, and keep surrounding prose sufficient to understand the key conclusion without relying only on the visual.\n\n## Syntax pitfalls to remember\n\n- Diagram definitions start with a diagram type declaration; comments use `%%`.\n- Unknown words\u002Fmisspellings can break parsing, while some parameters can fail silently.\n- In flowcharts, lowercase `end` can break parsing; prefer `End`\u002F`END` when used as node text.\n- Certain leading `o`\u002F`x` characters immediately after an edge can be interpreted as special edge syntax; use spacing\u002Fcapitalization when needed.\n- Quote labels containing troublesome characters rather than relying on parser tolerance.\n- Validate against the same renderer\u002Fversion that will display the task\u002FPR\u002Fdocs when possible.\n\n## Agent checklist\n\nBefore coding:\n\n- [ ] Draw current-state path from verified code\u002Fruntime.\n- [ ] Draw target-state path.\n- [ ] Compare them and identify actual changed edges\u002Fnodes\u002Fstates.\n- [ ] Mark auth\u002Ftenant\u002Fsource-of-truth\u002Fexternal\u002FHITL boundaries.\n- [ ] Add failure\u002Fretry\u002Frecovery branches where material.\n- [ ] Identify blockers\u002Fcircular dependencies\u002Funowned responsibilities.\n- [ ] Identify where tests\u002Freadback prove each critical outcome.\n- [ ] Correct Linear if the diagram exposes stale assumptions.\n\nFor each task section\u002Ffile group:\n\n- [ ] Choose the diagram type from the decision table.\n- [ ] Add the smallest useful diagram, or explicit N\u002FA reason.\n- [ ] Re-check the diagram after code inspection\u002Fimplementation.\n- [ ] Convert newly discovered failure branches into tests or owned follow-ups.\n\nBefore Done:\n\n- [ ] PR diagrams match merged architecture.\n- [ ] No diagram claims a boundary\u002Ftest\u002Fowner contradicted by code\u002Fruntime.\n- [ ] Post-merge evidence reaches the same terminal state shown in the diagram.\n- [ ] Important diagrams remain understandable with surrounding prose\u002Faccessibility metadata.\n- [ ] No diagram source contains secrets or unnecessary protected data.\n\n## Sources and syntax\n\nAuthoritative current Mermaid sources:\n\n- Official docs: https:\u002F\u002Fmermaid.ai\u002Fopen-source\u002Fintro\u002Findex.html\n- Official syntax index: https:\u002F\u002Fmermaid.js.org\u002F\n- Official repository: https:\u002F\u002Fgithub.com\u002Fmermaid-js\u002Fmermaid\n- Live editor: https:\u002F\u002Fmermaid.live\n- Accessibility: https:\u002F\u002Fmermaid.js.org\u002Fconfig\u002Faccessibility\n- Security: https:\u002F\u002Fmermaid.js.org\u002Fcommunity\u002Fsecurity\n\nFor exact syntax, load only the relevant local `references\u002F*.md`, then verify newer\u002Fbeta syntax against the current official docs\u002Ftarget renderer. The local references are convenience material, not authority over a newer or older renderer.\n","# Mermaid — MDE engineering reasoning standard\n\nMermaid is not decorative documentation. In MDE it is a **selective thinking, review, and defect-prevention tool**. Do not load it for trivial edits where prose or the diff is clearer.\n\nUse diagrams to answer questions prose hides:\n\n```text\nWhat talks to what?\nWho owns the write?\nWhere is auth enforced?\nWhat must happen before what?\nWhat can fail?\nWhat retries?\nWhat is irreversible?\nWhat blocks the task?\nWhat state is durable?\nWhere can tenant data cross?\nWhat evidence proves the journey?\n```\n\nMermaid's official purpose is to keep documentation closer to development using text-based diagrams that are easy to edit and version. Keep diagrams close to the task\u002Fcode they explain and update them when the implementation changes.\n\n## Mandatory MDE diagram pass\n\nUse this skill when a substantial `SAN-*` task has non-trivial relationships, state, sequence, ownership, dependencies, trust boundaries, or failure\u002Frecovery paths:\n\n1. **Task overview:** include one diagram showing the end-to-end user\u002Fsystem outcome.\n2. **Architecture\u002Fownership:** diagram every material boundary crossed by the task.\n3. **Dependencies\u002Fblockers:** show predecessor, downstream, external, and human-approval dependencies when material.\n4. **Each substantive task section or file\u002Fworkflow group:** add the diagram that best exposes its behavior, ownership, data, state, or failure path.\n5. **Negative\u002Frecovery:** include failure\u002Ferror\u002Fretry\u002Frollback branches for risky work.\n6. **Verification:** show how expected state\u002Fevidence is reached when the path is non-trivial.\n7. **PR:** include the smallest diagrams that let a reviewer understand changed architecture\u002Fuser flow without reconstructing it from code.\n8. **Post-merge:** update diagrams if the merged implementation differs from the planned model.\n\nIf a section truly has no meaningful relationship, state, dependency, sequence, or decision to visualize, write:\n\n```text\nDiagram: N\u002FA — no meaningful relationship\u002Fstate\u002Fsequence to model.\n```\n\nDo **not** create filler diagrams merely to satisfy the rule.\n\n## Diagram-first defect discovery\n\nBefore implementation, draw the current and target path. Then actively inspect the diagram for:\n\n| Red flag | What to look for in the diagram |\n|---|---|\n| Missing owner | node\u002Faction with no authoritative service\u002Fdomain owner |\n| Second source of truth | two durable stores claiming the same business truth |\n| Auth gap | browser\u002Fclient reaches protected state before server authorization |\n| Tenant leak | org\u002Fresource ID crosses boundary without revalidation |\n| Hidden write | read-looking path triggers mutation\u002Fwebhook\u002FRPC side effect |\n| HITL bypass | AI\u002Ftool reaches consequential write without explicit human gate |\n| Wrong approval | approval is not tied to exact artifact\u002Frevision\u002Fhash |\n| Retry duplication | retry\u002Fresume\u002Fcallback can traverse a write twice |\n| Dead end | failure branch has no recovery\u002Frollback\u002Foperator outcome |\n| Circular dependency | tasks\u002Fservices wait on each other |\n| Stale dependency | diagram points to deprecated route\u002Fservice\u002Fskill\u002Fprovider |\n| Unowned failure | external\u002Fprovider error has no caller handling or escalation |\n| Missing evidence | final state has no observable test\u002Freadback\u002Ftrace proving it |\n| Over-coupling | one file\u002Fservice owns unrelated responsibilities |\n| Race condition | concurrent paths can mutate the same state without arbitration |\n| Secret exposure | credential\u002Ftoken enters model, memory, snapshot, client, or trace path |\n\nIf the diagram reveals a red flag, **stop and correct the task\u002Farchitecture before coding** when the issue is load-bearing.\n\n## Choose the right diagram\n\nUse the smallest type that makes the hidden relationship obvious.\n\n| Development question | Preferred Mermaid type | Best MDE use |\n|---|---|---|\n| What is the end-to-end path or decision? | `flowchart` | task overview, request path, validation, fallback, failure branches |\n| Which actor\u002Fservice calls what, in what order? | `sequenceDiagram` | auth, API, CopilotKit\u002FAG-UI, Mastra tools, webhook\u002Fcallback, write\u002Freadback |\n| What states\u002Ftransitions are legal? | `stateDiagram-v2` | approvals, workflow lifecycle, booking, publish status, retry\u002Fcancel\u002Fexpiry |\n| What tables\u002Fentities relate? | `erDiagram` | Supabase schemas, FK\u002Fcardinality, durable ownership |\n| What classes\u002Ftypes\u002Finterfaces relate? | `classDiagram` | domain types, SDK interfaces, component\u002Fservice structure |\n| What services\u002Fresources are deployed together? | `architecture-beta` \u002F architecture diagram | Cloudflare, Supabase, queues, storage, CI\u002FCD\u002Fruntime topology |\n| What are the system\u002Fcontainer boundaries? | C4 | high-level platform context\u002Fcontainer\u002Fcomponent views; use carefully because Mermaid C4 remains marked experimental\u002Fbeta in official docs |\n| Where do responsibilities cross teams\u002Fservices? | swimlane\u002Fflowchart with subgraphs | frontend\u002Fbackend\u002FAI\u002Foperator handoffs |\n| What does the operator experience? | `journey` | user pain points\u002Fsatisfaction; use flowchart for system correctness details |\n| What must happen over time? | `timeline` | migrations, incidents, release history, dependency chronology |\n| What is scheduled and dependency-bound? | `gantt` | roadmap\u002Frelease\u002Fmigration sequencing; not runtime control flow |\n| Which requirement is satisfied by which design\u002Ftest? | `requirementDiagram` | acceptance-criteria traceability, safety requirements |\n| What is on the board now\u002Fnext\u002Flater? | `kanban` | execution planning\u002Fstatus, not architecture |\n| What branches\u002Fmerges occurred? | `gitGraph` | release\u002Fbranch history when it clarifies integration risk |\n| How do ideas\u002Ffeatures decompose? | `mindmap` | discovery, scope decomposition, product taxonomy; not proof of runtime behavior |\n| How should options be prioritized? | `quadrantChart` | impact vs effort\u002Frisk, vendor\u002Ffeature choice |\n| What quantity changes over time\u002Fcategory? | `xychart-beta` | performance, latency, test counts, trends |\n| How does quantity\u002Fvolume flow between stages? | `sankey-beta` | funnel\u002Fdata\u002Fmedia processing volume; not authorization flow |\n| What network\u002Fprotocol fields exist? | `packet-beta` | webhook\u002Fprotocol payload layouts when field order\u002Fwidth matters |\n| How are layout blocks related? | `block-beta` | compact topology\u002Flayout when flowchart positioning is insufficient |\n| What dimensions differ across options? | `radar-beta` | architecture\u002Fvendor comparison; label assumptions |\n| What events\u002Fcommands\u002Fread models form a domain flow? | event modeling | business process\u002Fevent-driven design |\n| What sets overlap? | Venn | capability\u002Fownership overlap, duplicate scope detection |\n| What causes a failure? | Ishikawa | root-cause analysis after incident\u002Ftest failure |\n| What capabilities create value vs maturity? | Wardley | strategic platform\u002Fvendor\u002Fbuild-vs-buy discussion only |\n| How uncertain\u002Fcomplex is a decision? | Cynefin | problem-classification workshop; not implementation proof |\n| What is the hierarchy\u002Ftree? | TreeView | route\u002Fcomponent\u002Fdomain hierarchy when hierarchy itself is the question |\n| What parts contribute proportionally? | treemap | code\u002Fdomain\u002Fportfolio composition; not workflow order |\n| What does control flow look like with richer loops\u002Fbranches? | ZenUML | complex call sequence when standard sequence syntax becomes unreadable |\n\nOfficial Mermaid 11.17.2 currently lists flowchart, swimlanes, sequence, class, state, ER, user journey, Gantt, pie, quadrant, requirement, GitGraph, C4, mindmaps, timeline, ZenUML, Sankey, XY, block, packet, Kanban, architecture, radar, event modeling, treemap, Venn, Ishikawa, Wardley, Cynefin, and TreeView among supported syntax families. Verify exact syntax\u002Ffeatures against the target renderer before relying on newer\u002Fbeta types.\n\n## MDE diagram set by development phase\n\n### 1. Task discovery\n\nMinimum useful set for a substantial task:\n\n```text\nflowchart       → current → target user\u002Fsystem journey\narchitecture    → ownership + source-of-truth boundaries\nrequirement     → AC → implementation\u002Ftest trace when requirements are complex\n```\n\nUse a **current-state diagram first**, then target state. The difference is the actual task scope.\n\n### 2. File\u002Fworkflow planning\n\nFor each substantive file\u002Fgroup, ask:\n\n```text\nDoes this file change call order?       → sequence\nDoes it change decisions\u002Fbranches?      → flowchart\nDoes it change lifecycle\u002Fstate?         → state\nDoes it change durable relationships?   → ER\nDoes it change service boundaries?      → architecture\u002FC4\nDoes it implement AC dependencies?      → requirement\nOtherwise                               → Diagram: N\u002FA with reason\n```\n\nA file diagram should show **why the file exists in the task**, not every import\u002Ffunction.\n\n### 3. Implementation\n\nKeep diagrams synchronized with discovered reality. If code inspection disproves the planned diagram:\n\n```text\nupdate diagram\n→ update task assumption\n→ update implementation plan\n→ only then code\n```\n\nDo not force code to match a stale diagram.\n\n### 4. Review \u002F pre-merge\n\nReview diagrams for structural defects before reading every changed line:\n\n```text\nentry → auth → trusted context → business logic → side effect → durable state → readback\n```\n\nMark critical branches explicitly:\n- unauthorized \u002F cross-org;\n- malformed\u002Fempty\u002Fstale input;\n- provider\u002Fnetwork failure;\n- retry\u002Fduplicate\u002Fconcurrent action;\n- reject\u002Fcancel\u002Fexpiry;\n- rollback\u002Fcompensation;\n- observable success.\n\n### 5. Post-merge \u002F incident\n\nUse:\n- sequence\u002Fflowchart to compare expected vs actual runtime path;\n- timeline for incident chronology;\n- Ishikawa for root-cause categories;\n- state diagram for invalid\u002Funexpected state transition;\n- architecture\u002FER for ownership or data-integrity drift.\n\nConvert the discovered failure branch into a permanent regression test when practical.\n\n## MDE canonical examples\n\n### AI proposal → approval → durable write\n\n```mermaid\nflowchart LR\n    U[Operator] --> UI[MDE UI]\n    UI --> API[Authenticated server boundary]\n    API --> AI[Mastra agent\u002Fworkflow]\n    AI --> P[Proposal artifact + revision + hash]\n    P --> R{Human review}\n    R -- Reject --> X[Terminal reject\u002Frevision path]\n    R -- Approve exact artifact --> V[Server revalidates org\u002Frun\u002Fstep\u002Fhash]\n    V --> W[Idempotent domain write]\n    W --> DB[(Supabase\u002Fdomain truth)]\n    DB --> RB[UI readback]\n```\n\nReview questions: Can AI bypass `R`? Can `V` receive stale\u002Fwrong tenant data? Can `W` run twice? Can UI claim success before `DB`?\n\n### External provider failure\u002Fretry\n\n```mermaid\nsequenceDiagram\n    actor Operator\n    participant API as MDE server\n    participant Provider\n    participant DB as Durable state\n\n    Operator->>API: Start action\n    API->>Provider: Request with operation\u002Fidempotency identity\n    alt provider succeeds\n        Provider-->>API: Success + provider ID\n        API->>DB: Commit\u002Freconcile once\n        DB-->>Operator: Durable success\n    else timeout \u002F response lost\n        Provider--xAPI: Unknown outcome\n        API->>DB: Reconcile by stable identity\n        API->>Provider: Retry only if safe\n    else provider rejects\n        Provider-->>API: Typed failure\n        API-->>Operator: Recoverable error; no fake success\n    end\n```\n\nThis makes the response-loss\u002Fidempotency hole visible before implementation.\n\n## Quality rules\n\n1. **One question per diagram.** Split views when one diagram tries to explain architecture + sequence + states + schedule simultaneously.\n2. **Model authoritative boundaries, not visual decoration.** Labels should name real MDE components\u002Fservices\u002Ftasks where known.\n3. **Current vs target must be distinguishable.** Never mix them without labels.\n4. **Show negative paths for risky work.** A happy-path-only security\u002FHITL\u002Fpayment\u002Fpublishing diagram is incomplete.\n5. **Show human gates explicitly.** Never imply AI self-approval.\n6. **Show durable stores explicitly.** Readers should see where truth is persisted.\n7. **Show external systems explicitly.** Do not hide provider behavior inside a generic backend box.\n8. **Show trust boundaries explicitly.** Browser-provided IDs are claims until server verified.\n9. **Prefer stable IDs\u002Fnames over volatile implementation detail.** Keep diagrams useful across refactors.\n10. **Keep diagrams readable.** If a diagram needs extensive prose to decode, split it.\n11. **Use labels on decision edges.** `Yes\u002FNo`, `valid\u002Finvalid`, `approved\u002Frejected`, `success\u002Ffailure`.\n12. **Do not invent facts.** Unknown edges\u002Fnodes should be marked `TBD \u002F unverified` until inspected.\n13. **Do not use a diagram as proof.** It defines expected structure; tests\u002Fruntime evidence prove actual behavior.\n14. **Validate syntax.** Unknown words\u002Fmisspellings can break Mermaid; parameters may fail silently. Use the target renderer or Mermaid Live Editor when needed.\n15. **Version-sensitive syntax:** newer\u002Fbeta diagram types must not be assumed supported by every Markdown renderer.\n16. **No secrets or protected payloads in diagram source.** Use stable IDs\u002Fplaceholders, not JWTs, cookies, service keys, provider credentials, passwords, raw customer records, or unnecessary PII. Diagram text is source content that may be rendered, stored, copied, indexed, or exported.\n17. **Do not weaken renderer security for convenience.** Mermaid's default `securityLevel` is `strict`; interactive links\u002FHTML require looser settings. Any change to renderer trust\u002Fsecurity is a separate implementation\u002Fsecurity decision, not a diagram-authoring shortcut.\n18. **Accessibility:** for important architecture, state, sequence, and user-journey diagrams, provide concise accessible title\u002Fdescription metadata when the target renderer supports it, and keep surrounding prose sufficient to understand the key conclusion without relying only on the visual.\n\n## Syntax pitfalls to remember\n\n- Diagram definitions start with a diagram type declaration; comments use `%%`.\n- Unknown words\u002Fmisspellings can break parsing, while some parameters can fail silently.\n- In flowcharts, lowercase `end` can break parsing; prefer `End`\u002F`END` when used as node text.\n- Certain leading `o`\u002F`x` characters immediately after an edge can be interpreted as special edge syntax; use spacing\u002Fcapitalization when needed.\n- Quote labels containing troublesome characters rather than relying on parser tolerance.\n- Validate against the same renderer\u002Fversion that will display the task\u002FPR\u002Fdocs when possible.\n\n## Agent checklist\n\nBefore coding:\n\n- [ ] Draw current-state path from verified code\u002Fruntime.\n- [ ] Draw target-state path.\n- [ ] Compare them and identify actual changed edges\u002Fnodes\u002Fstates.\n- [ ] Mark auth\u002Ftenant\u002Fsource-of-truth\u002Fexternal\u002FHITL boundaries.\n- [ ] Add failure\u002Fretry\u002Frecovery branches where material.\n- [ ] Identify blockers\u002Fcircular dependencies\u002Funowned responsibilities.\n- [ ] Identify where tests\u002Freadback prove each critical outcome.\n- [ ] Correct Linear if the diagram exposes stale assumptions.\n\nFor each task section\u002Ffile group:\n\n- [ ] Choose the diagram type from the decision table.\n- [ ] Add the smallest useful diagram, or explicit N\u002FA reason.\n- [ ] Re-check the diagram after code inspection\u002Fimplementation.\n- [ ] Convert newly discovered failure branches into tests or owned follow-ups.\n\nBefore Done:\n\n- [ ] PR diagrams match merged architecture.\n- [ ] No diagram claims a boundary\u002Ftest\u002Fowner contradicted by code\u002Fruntime.\n- [ ] Post-merge evidence reaches the same terminal state shown in the diagram.\n- [ ] Important diagrams remain understandable with surrounding prose\u002Faccessibility metadata.\n- [ ] No diagram source contains secrets or unnecessary protected data.\n\n## Sources and syntax\n\nAuthoritative current Mermaid sources:\n\n- Official docs: https:\u002F\u002Fmermaid.ai\u002Fopen-source\u002Fintro\u002Findex.html\n- Official syntax index: https:\u002F\u002Fmermaid.js.org\u002F\n- Official repository: https:\u002F\u002Fgithub.com\u002Fmermaid-js\u002Fmermaid\n- Live editor: https:\u002F\u002Fmermaid.live\n- Accessibility: https:\u002F\u002Fmermaid.js.org\u002Fconfig\u002Faccessibility\n- Security: https:\u002F\u002Fmermaid.js.org\u002Fcommunity\u002Fsecurity\n\nFor exact syntax, load only the relevant local `references\u002F*.md`, then verify newer\u002Fbeta syntax against the current official docs\u002Ftarget renderer. The local references are convenience material, not authority over a newer or older renderer.\n",{"name":5,"version":24,"description":7},"2.0.0-mde.2","main","9955f6a8aa5de3c14fea562c7e6b72973366ba3c",".claude\u002Fskills\u002Fmermaid-diagrams",1,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai","https:\u002F\u002Fmdeai-psi.vercel.app","https:\u002F\u002Fgithub.com\u002Famoai-tech","2026-11-13 03:54:16",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add amoai-tech\u002Fmdeai --skill mermaid-diagrams",{"tool":39,"command":40},"bunx","bunx skills add amoai-tech\u002Fmdeai --skill mermaid-diagrams",{"tool":42,"command":43},"pnpm","pnpm dlx skills add amoai-tech\u002Fmdeai --skill mermaid-diagrams","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002FSKILL.md",true,[47,53,57,61,65,69,73,77,81,85,89,93,97,101,105,109,113],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"evals\u002Fevals.json","REFERENCE","参考文档",1266,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Fevals\u002Fevals.json",{"path":54,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":55,"sourceHtmlUrl":56},"references\u002Fadvanced-features.md",11731,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fadvanced-features.md",{"path":58,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":59,"sourceHtmlUrl":60},"references\u002Farchitecture-diagrams.md",4862,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Farchitecture-diagrams.md",{"path":62,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":63,"sourceHtmlUrl":64},"references\u002Fblock-diagrams.md",5003,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fblock-diagrams.md",{"path":66,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Fc4-diagrams.md",16078,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fc4-diagrams.md",{"path":70,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Fclass-diagrams.md",7963,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fclass-diagrams.md",{"path":74,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Ferd-diagrams.md",13125,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Ferd-diagrams.md",{"path":78,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fflowcharts.md",11777,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fflowcharts.md",{"path":82,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fgantt-charts.md",5335,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fgantt-charts.md",{"path":86,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fmde-domain.md",848,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fmde-domain.md",{"path":90,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fquadrant-charts.md",4284,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fquadrant-charts.md",{"path":94,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Frequirement-diagrams.md",5734,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Frequirement-diagrams.md",{"path":98,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fsequence-diagrams.md",10480,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fsequence-diagrams.md",{"path":102,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fstate-diagrams.md",4183,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fstate-diagrams.md",{"path":106,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Ftreemap-diagrams.md",4348,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Ftreemap-diagrams.md",{"path":110,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fuser-journey-diagrams.md",3221,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fuser-journey-diagrams.md",{"path":114,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":115,"sourceHtmlUrl":116},"references\u002Fzenuml-diagrams.md",4418,"https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fmermaid-diagrams\u002Freferences\u002Fzenuml-diagrams.md",[118,125,132,139,146,153],{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":19},"01M7CV3D59CQX8N178NN3W5DEQ","mde-pr-review-supabase","Use when reviewing MDE Supabase SQL, Auth and RLS changes in a pull request.","https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002Fscripts\u002Fpr-agent\u002Fskills\u002Fsupabase\u002FSKILL.md",[],[],{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":19},"01M7CV39XR1SPH7C4FNXAXMM36","mde-pr-review-stripe","Use when reviewing MDE Stripe payments and webhooks changes in a pull request.","https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002Fscripts\u002Fpr-agent\u002Fskills\u002Fstripe\u002FSKILL.md",[],[],{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":19},"01M7CV37HHNM5A144SEX2VE05N","mde-pr-review-nextjs","Use when reviewing MDE Next.js App Router changes in a pull request.","https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002Fscripts\u002Fpr-agent\u002Fskills\u002Fnextjs\u002FSKILL.md",[],[],{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":19},"01M7CV34C1M5STTKHX5CGVN3VS","mde-pr-review-mastra","Use when reviewing MDE Mastra agent, tool and workflow changes in a pull request.","https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002Fscripts\u002Fpr-agent\u002Fskills\u002Fmastra\u002FSKILL.md",[],[],{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":19},"01M7CV31A37VPRRASAVGE8K8SN","mde-pr-review-maps","Use when reviewing MDE Google Maps and Places changes in a pull request.","https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002Fscripts\u002Fpr-agent\u002Fskills\u002Fmaps\u002FSKILL.md",[],[],{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":19},"01M7CV2Y70DQJ1VXFHS732CSQ4","mde-pr-review-copilotkit","Use when reviewing MDE CopilotKit and AG-UI changes in a pull request.","https:\u002F\u002Fgithub.com\u002Famoai-tech\u002Fmdeai\u002Fblob\u002Fmain\u002Fscripts\u002Fpr-agent\u002Fskills\u002Fcopilotkit\u002FSKILL.md",[],[]]