Render a big-block-brief.md (v1.0) into a structured solution architecture diagram using Excalidraw MCP — tier-banded grid with solution blocks, path connections, SPIs, foundations, and implementation roadmap. Use this skill whenever: the user asks to "render big block", "render the big block", "draw the solution architecture", "visualize the big block", "create excalidraw from big block brief", "Big Block rendern", "Lösungsarchitektur zeichnen", "render my big-block-brief", or when any upstream agent or skill produces a big-block-brief.md and needs it rendered into an Excalidraw diagram. Do NOT confuse with story-to-big-block (which creates the brief from value-modeler data) — this skill takes an existing brief and renders it into a visual diagram. If the user has a brief file ready, this is the right skill. If they have value-modeler output and want a brief first, use story-to-big-block instead. Pipeline: Parse brief → canvas setup → title banner → tier bands → solution blocks → path connections → SPI/Foundation cards → roadmap timeline → footer → export. Dark/light color mode auto-detected. ~150-250 Excalidraw elements.
From cogni-visualnpx claudepluginhub cogni-work/insight-wave --plugin cogni-visualThis skill is limited to using the following tools:
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Render a big-block-brief.md (v1.0) into a structured Excalidraw diagram. The Big Block is a data-driven grid — tier bands with solution blocks, path connections, SPIs, foundations, and a roadmap timeline. This is fundamentally different from the Big Picture's illustrated landscape: here, precision and clarity matter more than artistic expression.
| Parameter | Required | Description |
|---|---|---|
| brief_path | Yes | Path to big-block-brief.md |
| output_path | No | Path for .excalidraw output (default: {brief_dir}/big-block.excalidraw) |
Return a single-line JSON response:
Success:
{"ok":true,"excalidraw_path":"{path}","share_url":"{url}","solutions":{N},"tiers":[{t1},{t2},{t3},{t4}],"connections":{N},"elements":{count},"color_mode":"{mode}"}
Error:
{"ok":false,"e":"{error}","phase":"{phase_number}"}
The pipeline renders the Big Block in 9 sequential phases. Element count targets are specified per section to ensure consistent output.
Phase 1: Parse & Setup → 1 element Extract all data from brief
Phase 2: Title Banner → 5 elements Dark banner + title + subtitle + scoring + accent
Phase 3: Tier Bands → 2 per tier (8 total) Background band + tier label
Phase 4: Solution Blocks → 6 per block Rect + name + score/stars + category + portfolio + wave
Phase 5: Path Connections → 1-2 per connection Line + optional label
Phase 6: SPI + Foundation Cards → 3 per SPI, 4 per fdn Card + name + link(s) [+ maturity for fdns]
Phase 7: Roadmap Timeline → 3 + 3 + N badges Wave bands + labels + solution pills
Phase 7.5: Visual Validation → 0 elements Screenshot review checkpoint
Phase 8: Footer + Export → 4 elements Background + customer + date + methodology
Target element counts (use these to self-check after each phase):
Save snapshots at every phase boundary for recovery. Use snapshot_scene after each phase — this enables restore_snapshot if a later phase fails.
Why: This phase converts the brief's structured data into computed positions and a color palette that all subsequent phases depend on. Getting tier heights and block grid positions right here prevents cascading layout errors in later phases.
brief_path via Read tooltitle, subtitlecustomer, provider, industry, languagecanvas_size (A0/A1/A2/A3), canvas_pixels (width x height)theme, theme_pathscoring (formula, solutions_ranked, avg_ranking, portfolio_gaps)generated dateRead $CLAUDE_PLUGIN_ROOT/libraries/big-block-layouts.md. Look up:
canvas_sizeIf theme_path exists, read it and extract background color. Apply luminance formula:
luminance = 0.299*R + 0.587*G + 0.114*B
if luminance < 128 → "dark" mode
else → "light" mode
If no theme found, default to light mode.
Build a color palette object from the layouts spec's color tables for the detected mode. This palette is used by all subsequent phases.
Distribute tier zone height proportionally to solution count per tier, respecting minimum heights from the layouts spec:
If a tier has 0 solutions, collapse to 30px label-only row.
Compute exact y-position and height for each tier band within the Tier Zone.
For each tier, lay out blocks in a grid:
Record the (x, y, width, height) of every block — this is needed for connection routing in Phase 5.
Why: The Excalidraw canvas is a shared resource — if a previous rendering left elements behind, they would corrupt the new diagram. Starting with
clear_canvasguarantees a clean slate.
mkdir -p "{output_dir}"clear_canvas first, before any other Excalidraw MCP call, because it ensures no stale elements contaminate the new diagramread_diagram_guide — load Excalidraw best practicestype: rectangle
x: 0, y: 0
width: {canvas_width}, height: {canvas_height}
backgroundColor: "#F7F7F7" (light) or "#0D0D0D" (dark)
strokeColor: "transparent"
strokeWidth: 0
roughness: 0
snapshot_scene name="phase1-setup"Why: The banner is the first element viewers see and establishes the color mode and branding context that all subsequent elements inherit.
The title banner is a dark bar across the top with white text, followed by an accent-colored separator.
#1A1A1Atitle field, font size from layouts specsubtitle field, smaller fontUse batch_create_elements with all 5 elements. Group them as "title-banner".
Save snapshot: "phase2-banner"
Why: Tier bands create the visual hierarchy that communicates Business Relevance at a glance — Tier 1 at the top draws the eye first, reinforcing the prioritization from the value-modeler ranking.
Create the horizontal tier bands within the Tier Zone. Each band gets a tinted background and a tier label.
Use batch_create_elements for all tier bands + labels (8-16 elements).
Group each tier's elements (band bg + label) as "tier-{N}".
Save snapshot: "phase3-tiers"
Why: Each block is the atomic information unit of the diagram. Positioning it in the correct tier band is what makes the Big Block useful as a decision tool — stakeholders can scan from top to bottom in order of business relevance.
This is the core visual content. Each solution block is a rounded rectangle with structured internal text.
Create these elements at the block's computed grid position:
Block background — rounded rectangle (cornerRadius from spec)
portfolio_status: gap: stroke color = red (#E53E3E / #FC8181)Solution name — bold text, name_short value, top of block
BR score + stars — "BR: {score} {stars}"
br_stars for filled count, pad to 5 totalCategory tag — "Category: {category}" in muted text
Portfolio reference — either:
Wave + paths — "Wave {N} | {count} paths" in smallest font, bottom of block
Use batch_create_elements in batches of up to 50 elements (roughly 7-8 blocks per batch at ~7 elements each).
Group each block's elements as "block-{block_id}".
Save snapshot: "phase4-blocks"
Why: Connection lines reveal shared TIPS paths between solutions, exposing synergies that are invisible in the flat ranking list. A stakeholder seeing two Tier 1 solutions linked by the same path can prioritize them as a package.
Draw dashed bezier lines between blocks that share a TIPS path. Connections are rendered BEHIND blocks (lower z-order — they were created before blocks, but since we created blocks after tier bands, we need to ensure connections sit between tier bands and blocks visually).
startArrowhead: null, endArrowhead: null for bidirectional linesstrokeStyle: "dashed"strokeWidth: 2strokeColor: tier color of highest-tier block in connectionopacity: 40 (light) or 60 (dark)Use batch_create_elements for all connections.
Save snapshot: "phase5-connections"
Why: SPIs and foundations are the enablers that make solutions viable. Placing them below the tier grid creates a visual dependency stack — stakeholders see what organizational changes and infrastructure prerequisites must be in place before solutions can deliver value.
For each SPI, create a card:
Layout: cards arranged in a 2-column grid within the left half of the zone.
For each Foundation, create a card:
Layout: cards arranged in a 2-column grid within the right half of the zone.
Add "Process Changes (SPIs)" / "Prozessanpassungen" label above SPI cards. Add "Foundation Requirements" / "Voraussetzungen" label above Foundation cards.
Use batch_create_elements for all SPI + Foundation elements.
Group SPIs as "spi-section", Foundations as "foundation-section".
Save snapshot: "phase6-cards"
Why: The timeline converts abstract wave assignments into a temporal sequence that stakeholders can commit to. Without it, the tier grid shows what matters but not when to act.
The roadmap is a horizontal timeline at the bottom showing implementation waves.
name_shortUse batch_create_elements for all roadmap elements.
Group as "roadmap".
Save snapshot: "phase7-roadmap"
Why: A screenshot checkpoint catches layout issues (overlapping blocks, misaligned tier bands, invisible connections) before export, avoiding the cost of re-running the full pipeline.
After rendering all content (Phases 2-7), take a screenshot to verify the diagram looks correct before exporting.
get_canvas_screenshot — this returns a visual snapshot of the current canvasupdate_element or delete_element to fix before exportingsnapshot_scene name="phase7.5-validated"This phase adds no elements — it's a quality gate. Skip only if get_canvas_screenshot is unavailable.
Why: The footer closes the canvas with attribution and methodology provenance — a diagram without metadata looks unfinished and loses traceability to the TIPS analysis that produced it.
Create footer elements:
Use batch_create_elements. Group as "footer".
Save snapshot: "phase8-footer"
Primary method — use export_scene:
export_scene:
filePath: "{output_path}"
Fallback — if export_scene fails or is unavailable, use describe_scene to get the element data, then write the .excalidraw JSON file directly via Write tool. The .excalidraw format is:
{
"type": "excalidraw",
"version": 2,
"source": "render-big-block",
"elements": [... all elements from describe_scene ...],
"appState": {"viewBackgroundColor": "{palette.canvas_frame_bg}"}
}
Call describe_scene and count elements. Compare against the target counts from the Pipeline Overview. Log the final count in the result JSON.
Call export_to_excalidraw_url. If unavailable, set share_url to "n/a" in the result.
{"ok":true,"excalidraw_path":"{output_path}","share_url":"{url}","solutions":{N},"tiers":[{t1},{t2},{t3},{t4}],"connections":{conn_count},"elements":{total},"color_mode":"{mode}"}
batch_create_elements, group_elements, snapshot_scene, export_scene etc. MCP maintains element IDs, grouping, and z-order that manual JSON writing cannot guarantee. Only fall back to manual JSON if MCP export fails (see Step 8.2 fallback).roughness: 0 for all elements — the Big Block is a precise data-driven diagram, not a hand-drawn illustration. Roughness would undermine the structured grid aesthetic.fontFamily: 2 (Helvetica/sans-serif) for all text — clean, professional typography that matches the precision of the grid layout.group_elements — groups make the diagram editable (users can select and move entire blocks/sections). Group IDs: "title-banner", "tier-{N}", "block-{block_id}", "spi-section", "foundation-section", "roadmap", "footer".snapshot_scene — enables restore_snapshot recovery without re-rendering completed phases.language field.