Baoyu Diagram
Generate consistent layered architecture diagrams for specs, READMEs, and infra reviews without ad-hoc box placement.
Overview
baoyu-diagram is an agent skill most often used in Build (also Validate and Operate) that applies a left-to-right or top-to-bottom layered layout algorithm for software architecture diagrams.
Install
npx skills add https://github.com/jimliu/baoyu-skills --skill baoyu-diagramWhat is this skill?
- Chooses primary flow as left-to-right (pipelines, requests) or top-to-bottom (layered stacks).
- Five-step layout algorithm: role layers, column/row assignment, 40px minimum internal gaps, region boundaries, routed co
- Standard layer roles: clients, gateways, services, data stores, and infrastructure grouped per column or row.
- LTR column spacing template: 200–220px between column starts with example x-coordinates (40, 250, 460, 670).
- TTB row templates for clients, gateway band, service row, and data layer with documented y-coordinates.
- 40px minimum gap between components within a layer
- 200–220px recommended spacing between LTR column starts
- 5-step layout algorithm (layers, assign columns/rows, gaps, regions, connectors)
Adoption & trust: 7.1k installs on skills.sh; 20.9k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need an architecture diagram but ad-hoc placement produces overlapping layers, unclear flow direction, and docs nobody can scan.
Who is it for?
Solo builders documenting a multi-service or layered backend who want LTR pipeline maps or TTB stack views with consistent column and row spacing.
Skip if: Builders who only need informal whiteboard doodles without publishable structure, or who need automated IaC/graph generation from live cloud APIs without manual layout rules.
When should I use this skill?
When you need to create or refine a publishable software architecture diagram with explicit LTR or TTB flow and layered grouping.
What do I get? / Deliverables
You get a layered diagram with explicit flow direction, minimum spacing, region boundaries, and routed connectors ready to paste into specs or READMEs.
- Layered architecture diagram layout (coordinates or ASCII/mermaid-ready structure)
- Labeled region boundaries for shared infrastructure
- Routed connectors between layers including bus/queue gaps where applicable
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Architecture diagrams most often ship with build-phase documentation and integration specs, so build/docs is the canonical shelf. The skill encodes layout rules for system-architecture visuals—the same artifact class as technical docs, runbooks, and design records.
Where it fits
Sketch service boundaries and data flow on a landing-scope doc before committing to a full build.
Produce a LTR request-flow diagram for a README or API integration guide with fixed column spacing.
Map gateways, internal services, and queues between layers with region boxes for a third-party stack.
Refresh a TTB layered view of clients, cluster, and data tier for an on-call runbook.
How it compares
Use for procedural diagram layout rules instead of asking the model to freestyle boxes and arrows in chat.
Common Questions / FAQ
Who is baoyu-diagram for?
Solo and indie developers and small teams who document system architecture in READMEs, design notes, or ops runbooks and want repeatable LTR or TTB layouts.
When should I use baoyu-diagram?
During Validate when you sketch scope and service boundaries; during Build when you write integration and backend docs; and during Operate when you refresh infra or monitoring architecture views.
Is baoyu-diagram safe to install?
Treat it as procedural documentation in your agent context; review the Security Audits panel on this Prism page before enabling it in automated workflows.
SKILL.md
READMESKILL.md - Baoyu Diagram
# Architecture Diagram Layout ## Flow Direction Choose one primary direction: - **Left-to-Right (LTR):** Best for data pipelines, request flows. Users/clients on left, data stores on right. - **Top-to-Bottom (TTB):** Best for layered architectures. Clients at top, infrastructure at bottom. ## Layout Algorithm 1. **Identify layers:** Group components by role (clients, gateways, services, data, infrastructure) 2. **Assign columns (LTR) or rows (TTB):** One layer per column/row 3. **Within each layer:** Stack components vertically (LTR) or horizontally (TTB), 40px gap minimum 4. **Region boundaries:** Draw around groups that share infrastructure (e.g., "AWS us-east-1", "Kubernetes Cluster") 5. **Connectors:** Route arrows between layers. For buses/queues between layers, place a thin connector bar in the gap. ## Typical Layer Structure (LTR) ``` Col 1 (x=40) Col 2 (x=250) Col 3 (x=460) Col 4 (x=670) ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Client │────▶│ Gateway │─────▶│ Services │─────▶│ Database │ │ Layer │ │ Layer │ │ Layer │ │ Layer │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ ``` Column spacing: 200-220px between column starts. Adjust if components are wider. ## Typical Layer Structure (TTB) ``` Row 1 (y=60): [ Browser ] [ Mobile App ] [ API Client ] Row 2 (y=160): [ Load Balancer / API Gateway ] Row 3 (y=280): [ Auth Svc ] [ User Svc ] [ Order Svc ] Row 4 (y=400): [ Redis ] [ PostgreSQL ] [ S3 Bucket ] ``` Row spacing: 120-140px between row starts. ## Connection Routing - Prefer straight horizontal or vertical lines - For connections that would cross components, use two-segment (L-shaped) paths: ```svg <path d="M x1,y1 L midX,y1 L midX,y2" fill="none" stroke="#64748b" marker-end="url(#arrow)"/> ``` - For busy diagrams, use `stroke-opacity="0.6"` on less important connections - Label important connections with a text element near the midpoint ## Message Bus / Event Bus Pattern When services communicate through a shared bus, draw it as a horizontal bar between the service layer: ``` Services: [ Svc A ] [ Svc B ] [ Svc C ] │ │ │ Bus: ════╪══════════════╪════════════╪═══════ │ │ │ Data: [ DB A ] [ DB B ] [ Cache ] ``` Use the Connector color (orange) for the bus bar. ## Multi-Region / Multi-Cloud Nest region boundaries: - Outer boundary: Cloud provider (AWS, GCP) - Inner boundary: Region or VPC - Innermost: Availability zones or subnets Use different dash patterns to distinguish nesting levels: - Outer: `stroke-dasharray="12,4"` - Middle: `stroke-dasharray="8,4"` - Inner: `stroke-dasharray="4,4"` # Flowchart Layout ## Shape Vocabulary | Shape | Meaning | SVG Element | |-------|---------|-------------| | Rounded rect (large radius) | Start / End | `<rect rx="25">` | | Rectangle | Process / Action | `<rect rx="6">` | | Diamond | Decision | `<polygon>` rotated 45° | | Parallelogram | Input / Output | `<polygon>` with skew | | Cylinder | Data store | Ellipse + rect combo | ## Flow Direction Primary flow: **top to bottom**. Branch flows go left/right from decisions. ## Layout Algorithm 1. **Identify the main path** (happy path / most common flow) — this runs straight down the center 2. **Branch from decisions:** "Yes" continues down center, "No" branches right (or left if space is tight) 3. **Merge paths:** Route branches back to the main path using L-shaped connectors 4. **Loop-backs:** Route upward on the far left/right side of the diagram with curved paths ## Spacing - Step-to-step vertical gap: 60-80px (enough for arrow + optional label) - Decision diamond height: 70px (point to point) - Decision diamond width: 100px (point to point) - Branch horizontal offset: 200px from center - Merge connector clearance: 20px from any box ## Decision Labels Place "Yes" / "No" (or "True" /