skills/mermaid-pastel-style/SKILL.md
Apply consistent pastel color styling to mermaid diagrams. Use whenever creating or editing mermaid diagrams in documentation, specs, or PRDs.
npx skillsauth add mpurbo/purbo-skills mermaid-pastel-styleInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
When creating or editing mermaid diagrams, apply this pastel color palette using the %%{init}%% directive and per-node style directives.
Every mermaid block must start with this line immediately after the opening fence:
%%{init:{'theme':'base','themeVariables':{'primaryTextColor':'#1e293b','lineColor':'#475569','edgeLabelBackground':'#ffffff','tertiaryTextColor':'#1e293b'}}}%%
This ensures:
#1e293b) — readable on pastel backgrounds#475569) — visible connectors#ffffff) — clean label readability#1e293b) — black text on white backgroundAll node styles must include color:#1e293b for readable text.
| Role | Fill | Stroke | Use For |
|------|------|--------|---------|
| Process / Action | #f3e8ff | #7c3aed | Steps, tasks, operations, computations |
| Decision | #fef3c7 | #d97706 | Yes/no questions, validation checks, conditionals |
| Routing / Flow Control | #e0e7ff | #4f46e5 | Loop conditions, "more items?" checks, navigation |
| Success / Terminal | #d1fae5 | #059669 | Completion, done, exit success, output artifacts |
| Error / Failure | #fee2e2 | #dc2626 | Failures, error exits, log failures |
| External / IO | #fef3c7 | #d97706 | External APIs, third-party services |
| Interface / Trait | #e0e7ff | #4f46e5 | Trait definitions, abstract interfaces |
| Implementation | #dbeafe | #2563eb | Concrete implementations, provider-specific blocks |
| Start / Entry | #e0e7ff | #4f46e5 | Entry points, start nodes |
Subgraphs use dashed borders with no fill. Assign distinct stroke colors to differentiate groups:
style subgraph_a fill:none,stroke:#7c3aed,stroke-dasharray: 5 5,stroke-width:2px,color:#7c3aed
style subgraph_b fill:none,stroke:#2563eb,stroke-dasharray: 5 5,stroke-width:2px,color:#2563eb
style subgraph_c fill:none,stroke:#059669,stroke-dasharray: 5 5,stroke-width:2px,color:#059669
Available subgraph stroke colors (cycle through as needed):
#7c3aed (purple)#2563eb (blue)#059669 (green)#d97706 (amber)#dc2626 (red)Important: Subgraph IDs must be unquoted identifiers (e.g., subgraph my_group ["Display Label"]), not quoted strings, for style directives to work.
%%{init:{'theme':'base','themeVariables':{'primaryTextColor':'#1e293b','lineColor':'#475569','edgeLabelBackground':'#ffffff','tertiaryTextColor':'#1e293b'}}}%%
flowchart TD
subgraph phase_a ["Phase A: Capture Intent"]
A["1. Brain-dump PRD"]
B["2. AI structures PRD"]
C{"3. Review PRD — Satisfied?"}
A --> B
B --> C
C -- No --> B
end
C -- Yes --> D["4. Done"]
style phase_a fill:none,stroke:#7c3aed,stroke-dasharray: 5 5,stroke-width:2px,color:#7c3aed
style A fill:#f3e8ff,stroke:#7c3aed,color:#1e293b
style B fill:#f3e8ff,stroke:#7c3aed,color:#1e293b
style C fill:#fef3c7,stroke:#d97706,color:#1e293b
style D fill:#d1fae5,stroke:#059669,color:#1e293b
%%{init}%% directive for global text/line/label colors.color:#1e293b to every node style directive for dark text on pastel fills.style lines at the end of the mermaid block, after edge definitions.development
Use when turning a user's early brain-dump, product idea, architecture prompt, or "write a high-level system spec" request into a System Spec markdown document. This is Step 1 of the spec-driven workflow and should be used alongside superpowers:brainstorming when available. It decomposes the system into independently developable subsystems, defines contract boundaries, maps subsystem dependencies and parallelization order, and includes Mermaid dependency diagrams. Use this before subsystem-design-spec and before any OpenSpec artifacts. Trigger on phrases like "high-level system spec", "system specification", "system spec", "brain-dump to spec", "turn this into a spec", "write the spec", "architecture spec", "identify subsystems", "subsystem boundaries", "subsystem dependencies", "contract boundaries", "input/output contracts", "development order", "parallel development", "dependency map", "mermaid diagram", "docs/spec/system-spec.md", and any request to create a System Spec for Step 1 Brainstorming.
development
Use when creating or iterating on a detailed per-subsystem technical design specification from a system spec, before starting OpenSpec workflow. Triggers: "design spec", "subsystem spec", "write the spec for S1", "phase breakdown", "implementation phases", "mid-level spec", "technical design". Encodes opinionated progressive phase discipline with FP progression and contract boundaries. Do NOT use for high-level system specs (use brainstorming) or for OpenSpec artifacts (use openspec directly).
development
Use when setting up or updating OpenSpec's config.yaml for a project, or when OpenSpec workflow isn't picking up development disciplines (TDD, progressive phases, FP conventions). Triggers: "configure openspec", "setup openspec", "openspec config", "why didn't openspec use TDD", "openspec not invoking skills", "grounding config". Generates config.yaml with project context and skill invocation rules across sessions. Do NOT use for non-OpenSpec projects or for general CLAUDE.md configuration.
development
Functional Programming in Rust — opinionated guidelines for writing idiomatic, FP-first Rust code. Use this skill whenever writing, reviewing, refactoring, or scaffolding Rust code. Covers: functional core / imperative shell architecture, immutability-first patterns, pure functions, algebraic data types, pipeline-oriented programming with iterators and Result chains, error handling as data, dependency rejection over dependency injection, type-driven design (parse don't validate, typestate), and concurrency via message passing. Also use when the user asks about Rust project structure, Rust error handling patterns, Rust iterator pipelines, Cargo.toml setup for a new Rust project, or Rust code review. Apply these guidelines even when the user doesn't explicitly mention "functional programming" — this is the default coding style for all Rust work.