203 lines
11 KiB
Markdown
203 lines
11 KiB
Markdown
---
|
||
name: lucid
|
||
description: >
|
||
This skill should be used for any task involving Lucidchart or Lucidspark documents.
|
||
Triggers on: "find my Lucid diagram", "search Lucidchart", "create a diagram in Lucid",
|
||
"build a flowchart", "make a process diagram", "generate a sequence diagram", "create
|
||
an org chart", "build an org chart from this data", "share a Lucid document", "create
|
||
a share link for", "summarize this Lucid board", "what's on my Lucid canvas",
|
||
"turn this into a diagram", "diagram this workflow", "visualize this process",
|
||
"create a user flow", "build an architecture diagram in Lucid", "convert this SVG to
|
||
Lucid", "push this diagram to Lucid", "make this editable in Lucidchart", or any
|
||
reference to Lucidchart, Lucidspark, or Lucid documents.
|
||
metadata:
|
||
version: "0.2.1"
|
||
author: "Message Point Media"
|
||
---
|
||
|
||
# Lucid MCP Skill
|
||
|
||
This skill connects CoWork to the Lucid MCP server, enabling Claude to search, read, generate, and share Lucidchart and Lucidspark documents on behalf of the user.
|
||
|
||
## Available Tools
|
||
|
||
The `lucid` MCP server exposes the following capabilities. Use them directly when the user's request maps to one of these actions:
|
||
|
||
### 1. Search Documents
|
||
Find diagrams or boards across the user's Lucid library using natural language.
|
||
|
||
**When to use:** User asks to find a diagram, locate a board, retrieve a document, or asks "do I have a diagram for X?"
|
||
|
||
**Approach:** Call the Lucid search tool with descriptive query terms. Return the document title and a direct link. If multiple results, list them with titles and ask which one to use.
|
||
|
||
### 2. Summarize / Read Document Content
|
||
Get the content, structure, or key elements of an existing Lucid document.
|
||
|
||
**When to use:** User asks "what's in this diagram?", "summarize this board", "what does this architecture diagram show?", or attaches a Lucid link and asks questions about it.
|
||
|
||
**Approach:** Retrieve the document content and synthesize a clear summary. Reference specific shapes, labels, and connections by name. Always include a link back to the source document.
|
||
|
||
### 3. Create a Diagram (SVG path — preferred for most diagrams)
|
||
Generate a new Lucid diagram by first producing an SVG, then converting it directly to Lucidchart.
|
||
|
||
**TOOL ROUTING RULE — read this every time:**
|
||
- **Use `lucid_convert_svg_to_diagram`** (SVG path) when the diagram is a flowchart, process flow, network diagram, ER diagram, user flow, architecture diagram, or any diagram built from standard shapes. This is the preferred path — it produces better output, preserves colors, and handles custom/branded shapes.
|
||
- **Use `lucid_create_diagram_from_specification`** (JSON spec path) ONLY when the diagram requires Lucid-native shape types with no natural SVG equivalent: BPMN pools, UML class blocks, named AWS/GCP/Azure library shapes, lucidCard, or tables.
|
||
- **Use `lucid_create_sequence_diagram`** for sequence diagrams (PlantUML input).
|
||
- **Use `lucid_create_org_chart`** for org/hierarchy charts.
|
||
|
||
**SVG path approach:**
|
||
1. Generate the SVG in full — use `<rect>`, `<polygon>`, `<ellipse>`, `<circle>`, `<line>`, `<path>`, `<text>`. Apply colors via inline fill/stroke attributes. Include `<defs><marker>` for arrow heads.
|
||
2. Pass the SVG **verbatim** to `lucid_convert_svg_to_diagram` — do NOT simplify or rewrite it first.
|
||
3. Return the edit link to the created document.
|
||
|
||
**Custom shapes via SVG:**
|
||
If the user has a custom shape (an icon, hardware outline, branded element), it can be embedded directly into the SVG before conversion. The resulting Lucid document contains it as an editable element — equivalent to using it from a shape library. Ask the user to provide the SVG source of their custom shape, then compose it into the diagram SVG before calling the tool.
|
||
|
||
**Note:** Custom user shape libraries ("My Library" in Lucid) are NOT accessible via the MCP API. Only AWS 2024, GCP 2021, and Azure 2024 libraries are exposed via `get_mcp_resource`. Use the SVG embed approach for custom shapes.
|
||
|
||
**Common diagram types at MPM:**
|
||
- Transit display network architecture diagrams
|
||
- Hardware/software integration flows
|
||
- Helpdesk escalation process flows
|
||
- Onboarding workflows
|
||
- API sequence diagrams (RDMC ↔ display comms)
|
||
- Project milestone flows
|
||
|
||
### 4. Create an Org Chart
|
||
Generate an org chart from a text description of hierarchy or a CSV dataset.
|
||
|
||
**When to use:** User says "build an org chart", "visualize our team structure", "create a hierarchy diagram", "map out reporting lines", or uploads a CSV with employee/role data.
|
||
|
||
**Approach:**
|
||
- If given a text description, parse out the hierarchy (who reports to whom)
|
||
- If given a CSV, confirm the column mapping (name, title, manager, department) before generating
|
||
- Invoke the Lucid org-chart tool
|
||
- Return the link to the created diagram
|
||
|
||
### 5. Share a Document
|
||
Share a Lucid document with a specific person by email, with defined permission level.
|
||
|
||
**When to use:** User says "share this Lucid document with [person]", "give [email] access to this diagram", "send this board to my team"
|
||
|
||
**Permission levels** (confirm with user if not specified):
|
||
- View only
|
||
- Comment
|
||
- Edit
|
||
- Edit and share
|
||
|
||
**Approach:** Confirm the email address and permission level before executing. Report success and the document link.
|
||
|
||
### 6. Create a Share Link
|
||
Generate a shareable link to a Lucid document with configurable permissions.
|
||
|
||
**When to use:** User says "create a share link for this diagram", "get a link I can send out", "make this publicly viewable"
|
||
|
||
**Approach:** Confirm the permission type (view, comment, edit). Return the link immediately. If the user needs to send it via email or Slack, offer to do that next.
|
||
|
||
## Workflow Patterns
|
||
|
||
### Find → Summarize → Act
|
||
The most common pattern: search for a relevant document, pull its content, then use it in the current task (draft, proposal, report).
|
||
|
||
Example: "Pull the architecture diagram for the Birmingham transit deployment and summarize the display topology."
|
||
→ Search for Birmingham architecture doc → Retrieve content → Summarize shape labels and connections → Return summary + link
|
||
|
||
### Describe → Diagram → Share
|
||
Second most common: user describes a process or system, Claude turns it into a diagram, then optionally shares it.
|
||
|
||
Example: "Build a flowchart for our display installation process and share it with the field team."
|
||
→ Ask for process steps if not provided → Generate SVG → Convert via lucid_convert_svg_to_diagram → Share with specified emails or generate link
|
||
|
||
### SVG → Lucid (new as of v0.2.0)
|
||
When Claude has already generated an SVG (e.g. as a visualize widget in chat, or as a standalone SVG file), push it directly to Lucid without regenerating.
|
||
|
||
Example: "Take that diagram you just drew and push it into Lucid so I can edit it."
|
||
→ Take the existing SVG verbatim → Call lucid_convert_svg_to_diagram → Return edit link
|
||
|
||
### Custom Shape Embed
|
||
User has an MPM-specific or custom shape (hardware icon, branded element, custom SVG symbol).
|
||
|
||
Example: "Build an architecture diagram using our Escalator shape for the transit displays."
|
||
→ Ask user to share the SVG source of the custom shape → Compose it into the diagram SVG as a `<g>` element → Convert via lucid_convert_svg_to_diagram
|
||
|
||
## Behavior Rules
|
||
|
||
- Always return a direct link to any Lucid document you retrieve or create.
|
||
- Do not guess document names — use the search tool to find exact titles.
|
||
- When creating diagrams, confirm the diagram type and key elements with the user before invoking the tool if the request is ambiguous.
|
||
- For org charts from CSV, always confirm column mapping before generating.
|
||
- For sharing, always confirm email and permission level before executing.
|
||
- If the Lucid MCP server returns an error or the user is not authenticated, instruct them to connect their Lucid account: go to their AI tool's MCP settings and connect `https://mcp.lucid.app/mcp`, or enable the Lucid MCP Server in their Lucid Admin Panel.
|
||
|
||
## Diagram Text & Legibility Standards
|
||
|
||
> **CRITICAL — READ BEFORE WRITING ANY DIAGRAM JSON**
|
||
>
|
||
> The `"type": "text"` shape in Lucid Standard Import renders at a tiny default font size — typically appearing as a near-invisible gray line in exported PNGs. **Never use `"type": "text"` for any label that needs to be visually readable** — this includes document titles, section headers, group labels, annotations, legend rows, and sub-labels.
|
||
|
||
### Rule 1 — Use Rectangle Shapes for All Labels
|
||
|
||
Replace every `"type": "text"` shape with `"type": "rectangle"` styled to blend into the diagram background:
|
||
|
||
```json
|
||
{
|
||
"id": "header_label",
|
||
"type": "rectangle",
|
||
"boundingBox": {"x": 30, "y": 15, "w": 980, "h": 50},
|
||
"text": "Diagram Title Goes Here",
|
||
"style": {
|
||
"fill": {"type": "color", "color": "#FFFFFF"},
|
||
"stroke": {"color": "#FFFFFF", "width": 0, "style": "solid"},
|
||
"textColor": "#998643"
|
||
}
|
||
}
|
||
```
|
||
|
||
- Set `fill.color` to match the diagram background (white `#FFFFFF` for default backgrounds)
|
||
- Set `stroke.color` to match fill — this creates an invisible border
|
||
- Set `textColor` to the appropriate label color (e.g., MPM Dark Gold `#998643` for titles)
|
||
- If the diagram has a colored background region, match the fill to that region's color
|
||
|
||
### Rule 2 — Minimum Bounding Box Heights for Readable Text
|
||
|
||
| Label Role | Minimum `h` | Recommended `h` |
|
||
|---|---|---|
|
||
| Document title | 50 | 60 |
|
||
| Section / group header | 40 | 48 |
|
||
| Sub-label / annotation | 30 | 36 |
|
||
| Legend row label | 24 | 28 |
|
||
| Note / caption text | 28 | 36 |
|
||
|
||
**Width rule:** Always generous — at minimum 2× the expected character count in pixels. A 25-character label needs at least `w: 250`. Never constrain width to force wrapping on labels; wrapping a header is never correct.
|
||
|
||
### Rule 3 — Verify Text Legibility Before Delivering
|
||
|
||
After creating any diagram, always export as PNG using `lucid_export_document_as_PNG` and inspect the image before delivering. Reject and rebuild if:
|
||
|
||
- Any title text is smaller than the diagram's primary shape text
|
||
- Any label renders as a gray line, dot, or is illegible without zooming
|
||
- Section headers are not visually distinct from body/shape text
|
||
- Legend text cannot be read at 1:1 zoom
|
||
|
||
If legibility fails, increase the `h` value of the offending shapes (add 20px increments) until the text renders at a readable size, then re-export.
|
||
|
||
### Rule 4 — Proportional Visual Hierarchy
|
||
|
||
Enforce clear hierarchy through bounding box sizing:
|
||
- Title `h` ≥ 2× sub-label `h`
|
||
- Section header `h` falls between title and sub-label
|
||
- Never use the same `h` value for both title and sub-labels
|
||
|
||
**Example hierarchy for a standard diagram:**
|
||
- Document title: `h: 55`, `w: 900+`
|
||
- Section header: `h: 44`, `w: 300+`
|
||
- Sub-label / note: `h: 32`, `w: 200+`
|
||
- Legend row: `h: 26`, `w: 220+`
|
||
|
||
---
|
||
|
||
## Reference Files
|
||
|
||
- `references/tool-guide.md` — Detailed tool parameters, example prompts, and edge cases
|