Skip to content
cccskills
FreePublished on GitHub

mermaid

Create concise, syntax-verified Mermaid architecture diagrams. Use when the user asks to diagram a repository component, document, system, dependency flow, or supplied description in Mermaid.

The English summary is being prepared. Showing the original description.

bex-co/bex574 stars(GitHub 574 + cccskills 0)

Run score Not tested

See how to install

Files included (2)

  • SKILL.md2.9 KB
  • agents/openai.yaml215 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

Draw a mermaid architecture diagram in markdown for: $ARGUMENTS

Conventions

  • Boxes are services/components: svc[bex-api]. Use [(...)] for datastores. Humans (user, developer, operator) are triangles: user@{ shape: tri, label: "user" }.
  • A box that is not a long-running service must say so in its label — readers assume boxes are services and ask "where is this running?". Mark scheduled/ephemeral work (cron["backup pod (spawned nightly, exits when done)"]) and inert config objects (secret["Secret foo (k8s object, created once)"]). Draw humans as triangles: operator@{ shape: tri, label: "operator" }. Never draw a manual procedure as a peer box of running infrastructure: give runbook/recovery flows their own subgraph whose title says it's manual and where it runs (subgraph "disaster recovery — manual runbook, any docker host"), with the human actor inside.
  • Arrows are dependency direction: A --> B means A depends on (calls, reads, deploys to) B — never the reverse.
  • Concise but to the point: only load-bearing services and edges. No styling, no colors, no legend. Label an edge (A -->|gRPC| B) only when the relationship isn't obvious. Default to flowchart TB; use LR only if the graph is much wider than deep. Use subgraph only for real boundaries (cluster, node, network, trust zone, automated vs. manual) — subgraphs are how the diagram answers "where does this run?". An edge may target a whole subgraph by id (subgraph cluster["app cluster"] … op --> cluster).
  • If $ARGUMENTS refers to this repo, read the relevant docs/code first (docs/ADR002-architecture.md is the map) — don't diagram from guesswork.

Syntax gotchas that break rendering: quote labels containing (, ), [, {, or -->-like text (a["Queue (SQS)"]); never name a node bare end or graph; subgraph titles with spaces need quotes.

Verify (mandatory, before answering)

  1. Write the diagram body (no ```mermaid fence) to a .mmd file in the scratchpad (e.g. /tmp/diagram.mmd or the current workspace).
  2. Run: npx -y @mermaid-js/mermaid-cli@11.16.0 -i <file>.mmd -o <file>.svg — exit 0 means the syntax is valid. (First run downloads a headless browser; that's expected.) The version is pinned deliberately (supply-chain: codex-security #17) — bump it consciously, don't revert to floating.
  3. On failure, read the parse error, fix the diagram, and re-verify. Never output a diagram that hasn't passed.

Output

A single ```mermaid fenced block, followed by a brief explanation of the key dependency flow. If the user asked to put the diagram into a file, insert the verified block there instead.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Deploy a bex App to the current Kubernetes cluster and verify it reaches Ready. Use when the user asks to deploy a render.yaml (or legacy bex.yml) or the sample app and validate the rollout end to end. Optional argument: path to render.yaml.

The English summary is being prepared. Showing the original description.

bex-co/bex574Updated Oct 26, 2026

Deploy a local checkout to a production Hetzner App using the manual image-import runbook. Use when the user asks to ship local working-tree code to a live bex App rather than deploy from remote Git. Arguments are the local repo path and app name.

The English summary is being prepared. Showing the original description.

bex-co/bex574Updated Oct 26, 2026

loopx

Free

Autonomously drain a `.pm` workstream — triage every open item (milestone or inbox-note task), then work it to done, park it in `blocked/`, or delete it as invalid, until the workstream has no open items left. Use when the user asks to "loop", drain, or clear a whole workstream's backlog (e.g. `/loopx w1`). Sequential, not interval-based; for a timed poll use /loop.

The English summary is being prepared. Showing the original description.

bex-co/bex574Updated Oct 26, 2026

Stand up or scale the local CAPD mock cluster and deploy the bex operator into it. Use when the user asks to create, inspect, or resize the repository's local development cluster. Optional argument: scale N.

The English summary is being prepared. Showing the original description.

bex-co/bex574Updated Oct 26, 2026

pm

Free

Inspect and maintain the repository's .pm workstreams, inbox notes, milestones, and tasks. Use when the user asks for PM board status or requests a supported board mutation such as creating, promoting, adding, or completing work.

The English summary is being prepared. Showing the original description.

bex-co/bex574Updated Oct 26, 2026

Analyze and decompose a product topic into a text-only proposal for the repository's .pm board. Use when the user wants to pressure-test scope, size milestones, identify dependencies, or prepare exact PM board commands without writing board files.

The English summary is being prepared. Showing the original description.

bex-co/bex574Updated Oct 26, 2026

See all skills by bex-co

Report a problem with this skill