markdown-mermaid-writing skill (K-Dense scientific-agent-skills)

From Public Agent Wiki
Contents
  1. Install
  2. SKILL.md (verbatim)
  3. Overview
  4. When to Use This Skill
  5. 🎨 The Source Format Philosophy
  6. Why text-based diagrams win
  7. The three-phase workflow
  8. What Mermaid can express
  9. 🔧 Core workflow
  10. Step 1: Identify the document type
  11. Step 2: Read the style guide
  12. Step 3: Pick the diagram type and read its guide
  13. Step 4: Write the document
  14. Step 5: Commit as text
  15. ⚠️ Common pitfalls
  16. Radar chart syntax (radar-beta)
  17. XY Chart vs Radar confusion
  18. Forgetting accTitle/accDescr on supported types
  19. 🔗 Integration with other skills
  20. With scientific-schematics
  21. With scientific-writing
  22. With literature-review
  23. With any skill that produces output documents
  24. 📚 Reference index
  25. Style guides
  26. Diagram type guides (24 types)
  27. Document templates (9 types)
  28. Examples
  29. 📝 Attribution
  30. Other files in this skill
  31. assets/examples/example-research-report.md (verbatim)
  32. 📋 Overview
  33. 🔄 Experimental workflow
  34. 🔬 Methods
  35. Cell lines and culture
  36. gRNA design and efficiency prediction
  37. Transfection protocol
  38. Analysis pipeline
  39. 📊 Results
  40. Editing efficiency by cell line
  41. Effect of GC content on efficiency
  42. Timeline of key experimental milestones
  43. 🔍 Discussion
  44. Why HEK293T outperforms suspension lines
  45. Comparison with published benchmarks
  46. 🎯 Conclusions
  47. 🔗 References
  48. references/diagrams/architecture.md (verbatim)
  49. Exemplar Diagram
  50. Tips
  51. Template
  52. Complex Example
  53. Why this works
  54. references/diagrams/block.md (verbatim)
  55. Exemplar Diagram
  56. Tips
  57. Template
  58. Complex Example
  59. Why this works
  60. references/diagrams/c4.md (verbatim)
  61. Exemplar Diagram — System Context
  62. C4 Zoom Levels
  63. Tips
  64. Template
  65. Complex Example
  66. Why this works
  67. references/diagrams/class.md (verbatim)
  68. Exemplar Diagram
  69. Tips
  70. Template
  71. Complex Example
  72. Why this works
  73. references/diagrams/gitgraph.md (verbatim)
  74. Exemplar Diagram
  75. Tips
  76. Template
  77. references/diagrams/mindmap.md (verbatim)
  78. Exemplar Diagram
  79. Tips
  80. Template

What it does. Comprehensive markdown and Mermaid diagram writing skill. Use when creating any scientific document, report, analysis, or visualization. Establishes text-based diagrams as the default documentation standard with full style guides (markdown + mermaid), 24 diagram type references, and 9 document templates. Part of K-Dense-AI/scientific-agent-skills (AI Scientist skills) (K-Dense-AI/scientific-agent-skills).
Upstream K-Dense-AI/scientific-agent-skills
Skill file skills/markdown-mermaid-writing/SKILL.md
License MIT
Author K-Dense Inc.
Fetched 2026-09-10

Install

  • npx skills add K-Dense-AI/scientific-agent-skills --skill markdown-mermaid-writing, or copy the skill folder into ~/.claude/skills/markdown-mermaid-writing/.
  • Raw file: curl -sL https://raw.githubusercontent.com/K-Dense-AI/scientific-agent-skills/HEAD/skills/markdown-mermaid-writing/SKILL.md

SKILL.md (verbatim)

name: markdown-mermaid-writing
description: Comprehensive markdown and Mermaid diagram writing skill. Use when creating any scientific document, report, analysis, or visualization. Establishes text-based diagrams as the default documentation standard with full style guides (markdown + mermaid), 24 diagram type references, and 9 document templates.
allowed-tools: Read Write Edit Bash
license: Apache-2.0
metadata:
  version: "1.1"
  skill-author: Clayton Young / Superior Byte Works, LLC (@borealBytes)
  skill-source: https://github.com/SuperiorByteWorks-LLC/agent-project
  skill-version: 1.0.0
  skill-contributors: Clayton Young (Superior Byte Works, LLC / @borealBytes; Author and originator); K-Dense Team (K-Dense Inc.; Integration target and community feedback)

Markdown and Mermaid Writing

Overview

This skill teaches you — and enforces a standard for — creating scientific documentation using markdown with embedded Mermaid diagrams as the default and canonical format.

The core bet: a relationship expressed as a Mermaid diagram inside a .md file is more valuable than any image. It is text, so it diffs cleanly in git. It requires no build step. It renders natively on GitHub, GitLab, Notion, VS Code, and any markdown viewer. It uses fewer tokens than a prose description of the same relationship. And it can always be converted to a polished image later — but the text version remains the source of truth.

"The more you get your reports and files in .md in just regular text, which mermaid is as well as being a simple 'script language'. This just helps with any downstream rendering and especially AI generated images (using mermaid instead of just long form text to describe relationships < tokens). Additionally mermaid can render along with markdown for easy use almost anywhere by humans or AI."

— Clayton Young (@borealBytes), K-Dense Discord, 2026-02-19

When to Use This Skill

Use this skill when:

  • Creating any scientific document — reports, analyses, manuscripts, methods sections
  • Writing any documentation — READMEs, how-tos, decision records, project docs
  • Producing any diagram — workflows, data pipelines, architectures, timelines, relationships
  • Generating any output that will be version-controlled — if it's going into git, it should be markdown
  • Working with any other skill — this skill defines the documentation layer that wraps every other output
  • Someone asks you to "add a diagram" or "visualize the relationship" — Mermaid first, always

Do NOT start with Python matplotlib, seaborn, or AI image generation for structural or relational diagrams. Those are Phase 2 and Phase 3 — only used when Mermaid cannot express what's needed (e.g., scatter plots with real data, photorealistic images).

🎨 The Source Format Philosophy

Why text-based diagrams win

What matters Mermaid in Markdown Python / AI Image
Git diff readable ✅ ❌ binary blob
Editable without regenerating ✅ ❌
Token efficient vs. prose ✅ smaller ❌ larger
Renders without a build step ✅ ❌ needs hosting
Parseable by AI without vision ✅ ❌
Works in GitHub / GitLab / Notion ✅ ⚠️ if hosted
Accessible (screen readers) ✅ accTitle/accDescr ⚠️ needs alt text
Convertible to image later ✅ anytime — already image

The three-phase workflow

flowchart LR
    accTitle: Three-Phase Documentation Workflow
    accDescr: Phase 1 Mermaid in markdown is always required and is the source of truth. Phases 2 and 3 are optional downstream conversions for polished output.

    p1["📄 Phase 1<br/>Mermaid in Markdown<br/>(ALWAYS — source of truth)"]
    p2["🐍 Phase 2<br/>Python Generated<br/>(optional — data charts)"]
    p3["🎨 Phase 3<br/>AI Generated Visuals<br/>(optional — polish)"]
    out["📊 Final Deliverable"]

    p1 --> out
    p1 -.->|"when needed"| p2
    p1 -.->|"when needed"| p3
    p2 --> out
    p3 --> out

    classDef required fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
    classDef optional fill:#fef9c3,stroke:#ca8a04,stroke-width:2px,color:#713f12
    classDef output fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d

    class p1 required
    class p2,p3 optional
    class out output

Phase 1 is mandatory. Even if you proceed to Phase 2 or 3, the Mermaid source stays committed.

What Mermaid can express

Mermaid covers 24 diagram types. Almost every scientific relationship fits one:

Use case Diagram type File
Experimental workflow / decision logic Flowchart references/diagrams/flowchart.md
Service interactions / API calls / messaging Sequence references/diagrams/sequence.md
Data model / schema ER diagram references/diagrams/er.md
State machine / lifecycle State references/diagrams/state.md
Project timeline / roadmap Gantt references/diagrams/gantt.md
Proportions / composition Pie references/diagrams/pie.md
System architecture (zoom levels) C4 references/diagrams/c4.md
Concept hierarchy / brainstorm Mindmap references/diagrams/mindmap.md
Chronological events / history Timeline references/diagrams/timeline.md
Class hierarchy / type relationships Class references/diagrams/class.md
User journey / satisfaction map User Journey references/diagrams/user_journey.md
Two-axis comparison / prioritization Quadrant references/diagrams/quadrant.md
Requirements traceability Requirement references/diagrams/requirement.md
Flow magnitude / resource distribution Sankey references/diagrams/sankey.md
Numeric trends / bar + line charts XY Chart references/diagrams/xy_chart.md
Component layout / spatial arrangement Block references/diagrams/block.md
Work item status / task columns Kanban references/diagrams/kanban.md
Cloud infrastructure / service topology Architecture references/diagrams/architecture.md
Multi-dimensional comparison / skills radar Radar references/diagrams/radar.md
Hierarchical proportions / budget Treemap references/diagrams/treemap.md
Binary protocol / data format Packet references/diagrams/packet.md
Git branching / merge strategy Git Graph references/diagrams/git_graph.md
Code-style sequence (programming syntax) ZenUML references/diagrams/zenuml.md
Multi-diagram composition patterns Complex Examples references/diagrams/complex_examples.md

💡 Pick the right type, not the easy one. Don't default to flowcharts for everything. A timeline beats a flowchart for chronological events. A sequence beats a flowchart for service interactions. Scan the table and match.

🔧 Core workflow

Step 1: Identify the document type

Check if a template exists before writing from scratch:

Document type Template
Pull request record templates/pull_request.md
Issue / bug / feature request templates/issue.md
Sprint / project board templates/kanban.md
Architecture decision (ADR) templates/decision_record.md
Presentation / briefing templates/presentation.md
Research paper / analysis templates/research_paper.md
Project documentation templates/project_documentation.md
How-to / tutorial templates/how_to_guide.md
Status report templates/status_report.md

Step 2: Read the style guide

Before writing any .md file: read references/markdown_style_guide.md.

Key rules to internalize:

  • One H1 per document — the title. Never more.
  • Emoji on H2 headings only — one emoji per H2, none in H3/H4
  • Cite everything — every external claim gets a footnote [^N] with full URL
  • Bold sparingly — max 2-3 bold terms per paragraph, never full sentences
  • Horizontal rule after every </details> — mandatory
  • Tables over prose for comparisons, configurations, structured data
  • Diagrams over walls of text — if it describes flow, structure, or relationships, add Mermaid

Step 3: Pick the diagram type and read its guide

Before creating any Mermaid diagram: read references/mermaid_style_guide.md.

Then open the specific type file (e.g., references/diagrams/flowchart.md) for the exemplar, tips, and copy-paste template.

Mandatory rules for every diagram:

accTitle: Short Name 3-8 Words
accDescr: One or two sentences explaining what this diagram shows.
  • No %%{init} directives — breaks GitHub dark mode
  • No inline style — use classDef only
  • One emoji per node max — at the start of the label
  • snake_case node IDs — match the label

Step 4: Write the document

Start from the template. Apply the markdown style guide. Place diagrams inline with related text — not in a separate "Figures" section.

Step 5: Commit as text

The .md file with embedded Mermaid is what gets committed. If you also generated a PNG or AI image, those are supplementary — the markdown is the source.

⚠️ Common pitfalls

Radar chart syntax (radar-beta)

WRONG:

radar
title Example
x-axis ["A", "B", "C"]
"Series" : [1, 2, 3]

CORRECT:

radar-beta
title Example
axis a["A"], b["B"], c["C"]
curve series["Series"]{1, 2, 3}
max 3
  • Use radar-beta not radar (the bare keyword doesn't exist)
  • Use axis to define dimensions, not x-axis
  • Use curve to define data series, not quoted labels with colon
  • No accTitle/accDescr — radar-beta doesn't support accessibility annotations; always add a descriptive italic paragraph above the diagram

XY Chart vs Radar confusion

Diagram Keyword Axis syntax Data syntax
XY Chart (bars/lines) xychart-beta x-axis ["Label1", "Label2"] bar [10, 20] or line [10, 20]
Radar (spider/web) radar-beta axis id["Label"] curve id["Label"]{10, 20}

Forgetting accTitle/accDescr on supported types

Only some diagram types support accTitle/accDescr. For those that don't, always place a descriptive italic paragraph directly above the code block:

Radar chart comparing three methods across five performance dimensions. Note: Radar charts do not support accTitle/accDescr.

radar-beta
...

🔗 Integration with other skills

With scientific-schematics

scientific-schematics generates AI-powered publication-quality images (PNG). Use the Mermaid diagram as the brief for the schematic:

Workflow:
1. Create the concept as Mermaid in .md (this skill — Phase 1)
2. Describe the same concept to scientific-schematics for a polished PNG (Phase 3)
3. Commit both — the .md as source, the PNG as a supplementary figure

With scientific-writing

When scientific-writing produces a manuscript, all diagrams and structural figures should use this skill's standards. The writing skill handles prose and citations; this skill handles visual structure.

Workflow:
1. Use scientific-writing to draft the manuscript
2. For every figure that shows a workflow, architecture, or relationship:
   - Replace placeholder with a Mermaid diagram following this skill's guide
3. Use scientific-schematics only for figures that truly need photorealistic/complex rendering

With literature-review

Literature review produces summaries with lots of relationship data. Use this skill to:

  • Create concept maps (Mindmap) of the literature landscape
  • Show publication timelines (Timeline or Gantt)
  • Compare methodologies (Quadrant or Radar)
  • Diagram data flows described in papers (Sequence or Flowchart)

With any skill that produces output documents

Before finalizing any document from any skill, apply this skill's checklist:

  • Does the document use a template? If so, did I start from the right one?
  • Are all diagrams in Mermaid with accTitle + accDescr?
  • No %%{init}, no inline style, only classDef?
  • Are all external claims cited with [^N]?
  • One H1, emoji on H2 only?
  • Horizontal rules after every </details>?

📚 Reference index

Style guides

Guide Path Lines What it covers
Markdown Style Guide references/markdown_style_guide.md ~733 Headings, formatting, citations, tables, Mermaid integration, templates, quality checklist
Mermaid Style Guide references/mermaid_style_guide.md ~458 Accessibility, emoji set, color classes, theme neutrality, type selection, complexity tiers

Diagram type guides (24 types)

Each file contains: production-quality exemplar, tips specific to that type, and a copy-paste template.

references/diagrams/ — architecture, block, c4, class, complex_examples, er, flowchart, gantt, git_graph, kanban, mindmap, packet, pie, quadrant, radar, requirement, sankey, sequence, state, timeline, treemap, user_journey, xy_chart, zenuml

Document templates (9 types)

templates/ — decision_record, how_to_guide, issue, kanban, presentation, project_documentation, pull_request, research_paper, status_report

Examples

assets/examples/example-research-report.md — a complete scientific research report demonstrating proper heading hierarchy, multiple diagram types (flowchart, sequence, gantt), tables, footnote citations, collapsible sections, and all style guide rules applied.

📝 Attribution

All style guides, diagram type guides, and document templates in this skill are ported from the SuperiorByteWorks-LLC/agent-project repository under the Apache-2.0 License.

This skill (as part of scientific-agent-skills) is distributed under the MIT License. The included Apache-2.0 content is compatible for downstream use with attribution retained, as preserved in the file headers throughout this skill.

[^1]: GitHub Blog. (2022). "Include diagrams in your Markdown files with Mermaid." https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/

[^2]: Mermaid. "Mermaid Diagramming and Charting Tool." https://mermaid.js.org/

Other files in this skill

assets/examples/example-research-report.md (verbatim)

CRISPR-Based Gene Editing Efficiency Analysis

Example research report — demonstrates markdown-mermaid-writing skill standards. All diagrams use Mermaid embedded in markdown as the source format.

📋 Overview

This report analyzes the efficiency of CRISPR-Cas9 gene editing across three cell line models under variable guide RNA (gRNA) conditions. Editing efficiency was quantified by T7E1 assay and next-generation sequencing (NGS) of on-target loci[^1].

Key findings:

  • HEK293T cells show highest editing efficiency (mean 78%) across all gRNA designs
  • GC content between 40–65% correlates with editing efficiency (r = 0.82)
  • Off-target events occur at <0.1% frequency across all conditions tested

🔄 Experimental workflow

CRISPR editing experiments followed a standardized five-stage protocol. Each stage has defined go/no-go criteria before proceeding.

flowchart TD
    accTitle: CRISPR Editing Experimental Workflow
    accDescr: Five-stage experimental pipeline from gRNA design through data analysis, with quality checkpoints between each stage.

    design["🧬 Stage 1<br/>gRNA Design<br/>(CRISPRscan + Cas-OFFinder)"]
    synth["⚙️ Stage 2<br/>Oligo Synthesis<br/>& Annealing"]
    transfect["🔬 Stage 3<br/>Cell Transfection<br/>(Lipofectamine 3000)"]
    screen["🧪 Stage 4<br/>Primary Screen<br/>(T7E1 assay)"]
    ngs["📊 Stage 5<br/>NGS Validation<br/>(150 bp PE reads)"]

    qc1{GC 40-65%?}
    qc2{Yield ≥ 2 µg?}
    qc3{Viability ≥ 85%?}
    qc4{Band visible?}

    design --> qc1
    qc1 -->|"✅ Pass"| synth
    qc1 -->|"❌ Redesign"| design
    synth --> qc2
    qc2 -->|"✅ Pass"| transfect
    qc2 -->|"❌ Re-synthesize"| synth
    transfect --> qc3
    qc3 -->|"✅ Pass"| screen
    qc3 -->|"❌ Optimize"| transfect
    screen --> qc4
    qc4 -->|"✅ Pass"| ngs
    qc4 -->|"❌ Repeat"| screen

    classDef stage fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
    classDef gate fill:#fef9c3,stroke:#ca8a04,stroke-width:2px,color:#713f12
    classDef fail fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d

    class design,synth,transfect,screen,ngs stage
    class qc1,qc2,qc3,qc4 gate

🔬 Methods

Cell lines and culture

Three cell lines were used: HEK293T (human embryonic kidney), K562 (chronic myelogenous leukemia), and Jurkat (T-lymphocyte). All lines were maintained in RPMI-1640 with 10% FBS at 37°C / 5% CO₂[^2].

gRNA design and efficiency prediction

gRNAs targeting the EMX1 locus were designed using CRISPRscan[^3] with the following criteria:

Criterion Threshold Rationale
GC content 40–65% Optimal Tm and Cas9 binding
CRISPRscan score ≥ 0.6 Predicted on-target activity
Off-target sites ≤ 5 (≤3 mismatches) Reduce off-target editing risk
Homopolymer runs None (>4 nt) Prevents premature transcription stop

Transfection protocol

RNP complexes were assembled at 1:1.2 molar ratio (Cas9:gRNA) and delivered by lipofection. Cells were harvested 72 hours post-transfection for genomic DNA extraction.

Analysis pipeline

sequenceDiagram
    accTitle: NGS Data Analysis Pipeline
    accDescr: Sequence of computational steps from raw FASTQ files through variant calling to final efficiency report.

    participant raw as 📥 Raw FASTQ
    participant qc as 🔍 FastQC
    participant trim as ✂️ Trimmomatic
    participant align as 🗺️ BWA-MEM2
    participant call as ⚙️ CRISPResso2
    participant report as 📊 Report

    raw->>qc: Per-base quality scores
    qc-->>trim: Flag low-Q reads (Q<20)
    trim->>align: Cleaned reads
    align->>align: Index reference genome (hg38)
    align->>call: BAM + target region BED
    call->>call: Quantify indel frequency
    call-->>report: Editing efficiency (%)
    call-->>report: Off-target events
    report-->>report: Statistical summary

📊 Results

Editing efficiency by cell line

Cell line n (replicates) Mean efficiency (%) SD (%) Range (%)
HEK293T 6 78.4 4.2 71.2–84.6
K562 6 52.1 8.7 38.4–63.2
Jurkat 6 31.8 11.3 14.2–47.5

HEK293T cells showed significantly higher editing efficiency than both K562 (p < 0.001) and Jurkat (p < 0.001) lines by one-way ANOVA with Tukey post-hoc correction.

Effect of GC content on efficiency

GC content between 40–65% was strongly correlated with editing efficiency (Pearson r = 0.82, p < 0.0001, n = 48 gRNAs).

xychart-beta
    accTitle: Editing Efficiency vs gRNA GC Content
    accDescr: Bar chart showing mean editing efficiency grouped by GC content bins, demonstrating optimal performance in the 40 to 65 percent GC range

    title "Mean Editing Efficiency by GC Content Bin (HEK293T)"
    x-axis ["< 30%", "30–40%", "40–50%", "50–65%", "> 65%"]
    y-axis "Editing Efficiency (%)" 0 --> 100
    bar [18, 42, 76, 81, 38]

Timeline of key experimental milestones

timeline
    accTitle: Experiment Timeline — CRISPR Efficiency Study
    accDescr: Chronological milestones from study design through manuscript submission across six months

    section Month 1
        Study design and gRNA library design : 48 gRNAs across 3 target loci
        Cell line authentication : STR profiling confirmed all three lines
    section Month 2
        gRNA synthesis and QC : 46/48 gRNAs passed yield threshold
        Pilot transfections (HEK293T) : Optimized lipofection conditions
    section Month 3
        Full transfection series : All 3 cell lines, all 46 gRNAs, 6 replicates
        T7E1 primary screening : Passed go/no-go for all conditions
    section Month 4
        NGS library preparation : 276 samples processed
        Sequencing run (NovaSeq) : 150 bp PE, mean 50k reads/sample
    section Month 5
        Bioinformatic analysis : CRISPResso2 pipeline
        Statistical analysis : ANOVA, correlation, regression
    section Month 6
        Manuscript preparation : This report

🔍 Discussion

Why HEK293T outperforms suspension lines

HEK293T's superior editing efficiency relative to K562 and Jurkat likely reflects three factors[^4]:

  1. Adherent morphology — enables more uniform lipofection contact
  2. High transfection permissiveness — HEK293T expresses the SV40 large T antigen, which may facilitate nuclear import
  3. Cell cycle distribution — higher proportion in S/G2 phase where HDR is favored
<details> <summary><strong>🔧 Technical details — off-target analysis</strong></summary>

Off-target editing was assessed by GUIDE-seq at the 5 highest-activity gRNAs. No off-target sites exceeding 0.1% editing frequency were detected. The three potential sites flagged by Cas-OFFinder (≤2 mismatches) showed 0.00%, 0.02%, and 0.04% indel frequencies — all below the assay noise floor of 0.05%.

Full GUIDE-seq data available in supplementary data package (GEO accession pending).

</details>

Comparison with published benchmarks

Radar chart comparing three CRISPR delivery methods across five performance dimensions. Note: Radar charts do not support accTitle/accDescr — description provided above.

radar-beta
title Performance vs. Published Methods
axis eff["Efficiency"], spec["Specificity"], del["Delivery ease"], cost["Cost"], viab["Cell viability"]
curve this_study["This study (RNP + Lipo)"]{78, 95, 80, 85, 90}
curve plasmid["Plasmid Cas9 (lit.)"]{55, 70, 90, 95, 75}
curve electroporation["Electroporation RNP (lit.)"]{88, 96, 50, 60, 65}
max 100
graticule polygon
ticks 5
showLegend true

🎯 Conclusions

  1. RNP-lipofection in HEK293T achieves >75% CRISPR editing efficiency — competitive with electroporation without the associated viability cost
  2. gRNA GC content is the single strongest predictor of editing efficiency in our dataset (r = 0.82)
  3. This protocol is not directly transferable to suspension lines without further optimization; K562 and Jurkat require electroporation or viral delivery for comparable efficiency

🔗 References

[^1]: Ran, F.A. et al. (2013). "Genome engineering using the CRISPR-Cas9 system." Nature Protocols, 8(11), 2281–2308. https://doi.org/10.1038/nprot.2013.143

[^2]: ATCC. (2024). "Cell Line Authentication and Quality Control." https://www.atcc.org/resources/technical-documents/cell-line-authentication

[^3]: Moreno-Mateos, M.A. et al. (2015). "CRISPRscan: designing highly efficient sgRNAs for CRISPR-Cas9 targeting in vivo." Nature Methods, 12(10), 982–988. https://doi.org/10.1038/nmeth.3543

[^4]: Molla, K.A. & Yang, Y. (2019). "CRISPR/Cas-Mediated Base Editing: Technical Considerations and Practical Applications." Trends in Biotechnology, 37(10), 1121–1142. https://doi.org/10.1016/j.tibtech.2019.03.008

references/diagrams/architecture.md (verbatim)

<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->

Architecture Diagram

Back to Style Guide — Read the style guide first for emoji, color, and accessibility rules.

Syntax keyword: architecture-beta Best for: Cloud infrastructure, service topology, deployment architecture, network layout When NOT to use: Logical system boundaries (use C4), component layout without cloud semantics (use Block)

⚠️ Accessibility: Architecture diagrams do not support accTitle/accDescr. Always place a descriptive italic Markdown paragraph directly above the code block.

Exemplar Diagram

Architecture diagram showing a cloud-hosted web application with a load balancer, API server, database, and cache deployed within a VPC:

architecture-beta
    group cloud(cloud)[AWS Cloud]
    group vpc(cloud)[VPC] in cloud

    service lb(internet)[Load Balancer] in vpc
    service api(server)[API Server] in vpc
    service db(database)[PostgreSQL] in vpc
    service cache(disk)[Redis Cache] in vpc

    lb:R --> L:api
    api:R --> L:db
    api:B --> T:cache

Tips

  • Use group for logical boundaries (VPC, region, cluster, availability zone)
  • Use service for individual components
  • Direction annotations on connections: :L (left), :R (right), :T (top), :B (bottom)
  • Built-in icon types: cloud, server, database, internet, disk
  • Nest groups with in parent_group
  • Labels must be plain text — no emoji and no hyphens in [] labels (parser treats - as an edge operator)
  • Use --> for directional arrows, -- for undirected edges
  • Keep to 6–8 services per diagram
  • Always pair with a Markdown text description above for screen readers

Template

Description of the infrastructure topology and key components:

architecture-beta
    group region(cloud)[Cloud Region]

    service frontend(internet)[Web Frontend] in region
    service backend(server)[API Server] in region
    service datastore(database)[Database] in region

    frontend:R --> L:backend
    backend:R --> L:datastore

Complex Example

Multi-region cloud deployment with 3 nested groups (2 regional clusters + shared services) showing 9 services, cross-region database replication, CDN distribution, and centralized monitoring. Demonstrates how nested group + in syntax creates clear infrastructure boundaries:

architecture-beta
    group cloud(cloud)[AWS Platform]

    group east(cloud)[US East Region] in cloud
    service lb_east(internet)[Load Balancer East] in east
    service app_east(server)[App Server East] in east
    service db_primary(database)[Primary Database] in east

    group west(cloud)[US West Region] in cloud
    service lb_west(internet)[Load Balancer West] in west
    service app_west(server)[App Server West] in west
    service db_replica(database)[Replica Database] in west

    group shared(cloud)[Shared Services] in cloud
    service cdn(internet)[CDN Edge] in shared
    service monitor(server)[Monitoring] in shared
    service queue(server)[Message Queue] in shared

    cdn:B --> T:lb_east
    cdn:B --> T:lb_west
    lb_east:R --> L:app_east
    lb_west:R --> L:app_west
    app_east:B --> T:db_primary
    app_west:B --> T:db_replica
    db_primary:R --> L:db_replica
    app_east:R --> L:queue
    app_west:R --> L:queue
    monitor:B --> T:app_east

Why this works

  • Nested groups mirror real infrastructure — cloud > region > services is exactly how teams think about multi-region deployments. The nesting creates clear blast radius boundaries.
  • Plain text labels only — architecture diagrams parse-fail with emoji in [] labels. All visual distinction comes from the group nesting and icon types (internet, server, database).
  • Directional annotations prevent overlap — :B --> T: (bottom-to-top), :R --> L: (right-to-left) control where edges connect. Without these, Mermaid stacks edges on top of each other.
  • Cross-region replication is explicit — the db_primary:R --> L:db_replica edge is the most important infrastructure detail and reads clearly as a horizontal connection between regions.

references/diagrams/block.md (verbatim)

<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->

Block Diagram

Back to Style Guide — Read the style guide first for emoji, color, and accessibility rules.

Syntax keyword: block-beta Best for: System block composition, layered architectures, component topology where spatial layout matters When NOT to use: Process flows (use Flowchart), infrastructure with cloud icons (use Architecture)

⚠️ Accessibility: Block diagrams do not support accTitle/accDescr. Always place a descriptive italic Markdown paragraph directly above the code block.

Exemplar Diagram

Block diagram showing a three-tier web application architecture from client-facing interfaces through application services to data storage, with emoji labels indicating component types:

block-beta
    columns 3

    block:client:3
        columns 3
        browser["🌐 Browser"]
        mobile["📱 Mobile App"]
        cli["⌨️ CLI Tool"]
    end

    space:3

    block:app:3
        columns 3
        api["🖥️ API Server"]
        worker["⚙️ Worker"]
        cache["⚡ Redis Cache"]
    end

    space:3

    block:data:3
        columns 2
        db[("💾 PostgreSQL")]
        storage["📦 Object Storage"]
    end

    browser --> api
    mobile --> api
    cli --> api
    api --> worker
    api --> cache
    worker --> db
    api --> db
    worker --> storage

Tips

  • Use columns N to control the layout grid
  • Use space:N for empty cells (alignment/spacing)
  • Nest block:name:span { ... } for grouped sections
  • Connect blocks with --> arrows
  • Use emoji in labels ["🔧 Component"] for visual distinction
  • Use cylinder ("text") syntax for databases within blocks
  • Keep to 3–4 rows with 3–4 columns for readability
  • Always pair with a Markdown text description above for screen readers

Template

Description of the system layers and how components connect:

block-beta
    columns 3

    block:layer1:3
        columns 3
        comp_a["📋 Component A"]
        comp_b["⚙️ Component B"]
        comp_c["📦 Component C"]
    end

    space:3

    block:layer2:3
        columns 2
        comp_d["💾 Component D"]
        comp_e["🔧 Component E"]
    end

    comp_a --> comp_d
    comp_b --> comp_d
    comp_c --> comp_e

Complex Example

Enterprise platform architecture rendered as a 5-tier block diagram with 15 components. Each tier is a block group spanning the full width, with internal columns controlling component layout. Connections show the primary data flow paths between tiers:

block-beta
    columns 4

    block:clients:4
        columns 4
        browser["🌐 Browser"]
        mobile["📱 Mobile App"]
        partner["🔌 Partner API"]
        admin["🔐 Admin Console"]
    end

    space:4

    block:gateway:4
        columns 2
        apigw["🌐 API **Gateway**"]
        auth["🔐 Auth Service"]
    end

    space:4

    block:services:4
        columns 4
        user_svc["👤 User Service"]
        order_svc["📋 Order Service"]
        product_svc["📦 Product Service"]
        notify_svc["📤 Notification Service"]
    end

    space:4

    block:data:4
        columns 3
        postgres[("💾 PostgreSQL")]
        redis["⚡ Redis Cache"]
        elastic["🔍 Elasticsearch"]
    end

    space:4

    block:infra:4
        columns 3
        mq["📥 Message Queue"]
        logs["📊 Log Aggregator"]
        metrics["📊 Metrics Store"]
    end

    browser --> apigw
    mobile --> apigw
    partner --> apigw
    admin --> auth
    apigw --> auth
    apigw --> user_svc
    apigw --> order_svc
    apigw --> product_svc
    order_svc --> notify_svc
    user_svc --> postgres
    order_svc --> postgres
    product_svc --> elastic
    order_svc --> redis
    notify_svc --> mq
    order_svc --> mq
    mq --> logs

Why this works

  • 5 tiers read top-to-bottom like a network diagram — clients, gateway, services, data, infrastructure. Each tier is a block spanning the full width with its own column layout.
  • space:4 creates visual separation between tiers without unnecessary lines or borders, keeping the diagram clean and scannable.
  • Cylinder syntax ("text") for databases — PostgreSQL renders as a cylinder, instantly recognizable as a data store. Other components use standard rectangles.
  • Connections show real data paths — not every possible connection, just the primary flows. A fully-connected diagram would be unreadable; this shows the key paths an engineer would trace during debugging.

references/diagrams/c4.md (verbatim)

<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->

C4 Diagram

Back to Style Guide — Read the style guide first for emoji, color, and accessibility rules.

Syntax keyword: C4Context, C4Container, C4Component Best for: System architecture at varying zoom levels — context, containers, components When NOT to use: Infrastructure topology (use Architecture), runtime sequences (use Sequence)

Exemplar Diagram — System Context

C4Context
    accTitle: Online Store System Context
    accDescr: C4 context diagram showing how a customer interacts with the store and its external payment dependency

    title Online Store - System Context

    Person(customer, "Customer", "Places orders")
    System(store, "Online Store", "Catalog and checkout")
    System_Ext(payment, "Payment Provider", "Card processing")

    Rel(customer, store, "Orders", "HTTPS")
    Rel(store, payment, "Pays", "API")

    UpdateRelStyle(customer, store, $offsetY="-40", $offsetX="-30")
    UpdateRelStyle(store, payment, $offsetY="-40", $offsetX="-30")

C4 Zoom Levels

Level Keyword Shows Audience
Context C4Context Systems + external actors Everyone
Container C4Container Apps, databases, queues within a system Technical leads
Component C4Component Internal modules within a container Developers

Tips

  • Use Person() for human actors
  • Use System() for internal systems, System_Ext() for external
  • Use Container(), ContainerDb(), ContainerQueue() at the container level
  • Label relationships with verbs and protocols: "Reads from", "SQL/TLS"
  • Use Container_Boundary(id, "name") { ... } to group containers
  • Keep descriptions short — long text causes label overlaps
  • Limit to 4–5 elements at the Context level to avoid crowding
  • Avoid emoji in C4 labels — the C4 renderer handles its own styling
  • Use UpdateRelStyle() to adjust label positions if overlaps occur

Template

C4Context
    accTitle: Your System Context
    accDescr: Describe the system boundaries and external interactions

    Person(user, "User", "Role description")

    System(main_system, "Your System", "What it does")
    System_Ext(external, "External Service", "What it provides")

    Rel(user, main_system, "Uses", "HTTPS")
    Rel(main_system, external, "Calls", "API")

Complex Example

A C4 Container diagram for an e-commerce platform with 3 Container_Boundary groups, 10 containers, and 2 external systems. Shows how to use boundaries to organize services by layer, with UpdateRelStyle offsets preventing label overlaps.

C4Container
    accTitle: E-Commerce Platform Container View
    accDescr: C4 container diagram showing web and mobile frontends, core backend services, and data stores with external payment and email dependencies

    Person(customer, "Customer", "Shops online")

    Container_Boundary(frontend, "Frontend") {
        Container(spa, "Web App", "React", "Single-page app")
        Container(bff, "BFF API", "Node.js", "Backend for frontend")
    }

    Container_Boundary(services, "Core Services") {
        Container(order_svc, "Order Service", "Go", "Order processing")
        Container(catalog_svc, "Product Catalog", "Go", "Product data")
        Container(user_svc, "User Service", "Go", "Auth and profiles")
    }

    Container_Boundary(data, "Data Layer") {
        ContainerDb(pg, "PostgreSQL", "SQL", "Primary data store")
        ContainerDb(redis, "Redis", "Cache", "Session and cache")
        ContainerDb(search, "Elasticsearch", "Search", "Product search")
    }

    System_Ext(payment_gw, "Payment Gateway", "Card processing")
    System_Ext(email_svc, "Email Service", "Transactional email")

    Rel(customer, spa, "Browses", "HTTPS")
    Rel(spa, bff, "Calls", "GraphQL")
    Rel(bff, order_svc, "Places orders", "gRPC")
    Rel(bff, catalog_svc, "Queries", "gRPC")
    Rel(bff, user_svc, "Authenticates", "gRPC")
    Rel(order_svc, pg, "Reads/writes", "SQL")
    Rel(order_svc, payment_gw, "Charges", "API")
    Rel(order_svc, email_svc, "Sends", "SMTP")
    Rel(catalog_svc, search, "Indexes", "REST")
    Rel(user_svc, redis, "Sessions", "TCP")
    Rel(catalog_svc, pg, "Reads", "SQL")

    UpdateRelStyle(customer, spa, $offsetY="-40", $offsetX="-50")
    UpdateRelStyle(spa, bff, $offsetY="-30", $offsetX="10")
    UpdateRelStyle(bff, order_svc, $offsetY="-30", $offsetX="-40")
    UpdateRelStyle(bff, catalog_svc, $offsetY="-30", $offsetX="10")
    UpdateRelStyle(bff, user_svc, $offsetY="-30", $offsetX="50")
    UpdateRelStyle(order_svc, pg, $offsetY="-30", $offsetX="-50")
    UpdateRelStyle(order_svc, payment_gw, $offsetY="-30", $offsetX="10")
    UpdateRelStyle(order_svc, email_svc, $offsetY="10", $offsetX="10")
    UpdateRelStyle(catalog_svc, search, $offsetY="-30", $offsetX="10")
    UpdateRelStyle(user_svc, redis, $offsetY="-30", $offsetX="10")
    UpdateRelStyle(catalog_svc, pg, $offsetY="10", $offsetX="30")

Why this works

  • Container_Boundary groups map to deployment units — frontend, core services, and data layer each correspond to real infrastructure boundaries (CDN, Kubernetes namespace, managed databases)
  • Every Rel has UpdateRelStyle — C4's auto-layout stacks labels on top of each other by default. Offset every relationship to prevent overlaps, even if it seems fine at first (adding elements later will shift things)
  • Descriptions are kept to 1-3 words — "Card processing", "Session and cache", "Auth and profiles". Long descriptions are the #1 cause of C4 rendering issues
  • Container types are semantic — ContainerDb for databases gives them the cylinder icon, Container for services. The C4 renderer provides its own visual differentiation

references/diagrams/class.md (verbatim)

<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->

Class Diagram

Back to Style Guide — Read the style guide first for emoji, color, and accessibility rules.

Syntax keyword: classDiagram Best for: Object-oriented design, type hierarchies, interface contracts, domain models When NOT to use: Database schemas (use ER), runtime behavior (use Sequence)

Exemplar Diagram

classDiagram
    accTitle: Payment Processing Class Hierarchy
    accDescr: Interface and abstract base class with two concrete implementations for credit card and digital wallet payment processing

    class PaymentProcessor {
        <<interface>>
        +processPayment(amount) bool
        +refund(transactionId) bool
        +getStatus(transactionId) string
    }

    class BaseProcessor {
        <<abstract>>
        #apiKey: string
        #timeout: int
        +validateAmount(amount) bool
        #logTransaction(tx) void
    }

    class CreditCardProcessor {
        -gateway: string
        +processPayment(amount) bool
        +refund(transactionId) bool
        -tokenizeCard(card) string
    }

    class DigitalWalletProcessor {
        -provider: string
        +processPayment(amount) bool
        +refund(transactionId) bool
        -initiateHandshake() void
    }

    PaymentProcessor <|.. BaseProcessor : implements
    BaseProcessor <|-- CreditCardProcessor : extends
    BaseProcessor <|-- DigitalWalletProcessor : extends

    style PaymentProcessor fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#3b0764
    style BaseProcessor fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
    style CreditCardProcessor fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
    style DigitalWalletProcessor fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d

Tips

  • Use <<interface>> and <<abstract>> stereotypes for clarity
  • Show visibility: + public, - private, # protected
  • Keep to 4–6 classes per diagram — split larger hierarchies
  • Use style ClassName fill:...,stroke:...,color:... for light semantic coloring:
    • 🟣 Purple for interfaces/abstractions
    • 🔵 Blue for base/abstract classes
    • 🟢 Green for concrete implementations
  • Relationship arrows:
    • <|-- inheritance (extends)
    • <|.. implementation (implements)
    • *-- composition · o-- aggregation · --> dependency

Template

classDiagram
    accTitle: Your Title Here
    accDescr: Describe the class hierarchy and the key relationships between types

    class InterfaceName {
        <<interface>>
        +methodOne() ReturnType
        +methodTwo(param) ReturnType
    }

    class ConcreteClass {
        -privateField: Type
        +methodOne() ReturnType
        +methodTwo(param) ReturnType
    }

    InterfaceName <|.. ConcreteClass : implements

Complex Example

An event-driven notification platform with 11 classes organized into 3 namespace groups — core orchestration, delivery channels, and data models. Shows interface implementation, composition, and dependency relationships across layers.

classDiagram
    accTitle: Event-Driven Notification Platform
    accDescr: Multi-namespace class hierarchy for a notification system showing core orchestration, four delivery channel implementations, and supporting data models with composition and dependency relationships

    namespace Core {
        class NotificationService {
            -queue: NotificationQueue
            -registry: ChannelRegistry
            +dispatch(notification) bool
            +scheduleDelivery(notification, time) void
            +getDeliveryStatus(id) DeliveryStatus
        }

        class NotificationQueue {
            -pending: List~Notification~
            -maxRetries: int
            +enqueue(notification) void
            +dequeue() Notification
            +retry(attempt) bool
        }

        class ChannelRegistry {
            -channels: Map~string, Channel~
            +register(name, channel) void
            +resolve(type) Channel
            +healthCheck() Map~string, bool~
        }
    }

    namespace Channels {
        class Channel {
            <<interface>>
            +send(notification, recipient) DeliveryAttempt
            +getStatus(attemptId) DeliveryStatus
            +validateRecipient(recipient) bool
        }

        class EmailChannel {
            -smtpHost: string
            -templateEngine: TemplateEngine
            +send(notification, recipient) DeliveryAttempt
            +getStatus(attemptId) DeliveryStatus
            +validateRecipient(recipient) bool
        }

        class SMSChannel {
            -provider: string
            -rateLimit: int
            +send(notification, recipient) DeliveryAttempt
            +getStatus(attemptId) DeliveryStatus
            +validateRecipient(recipient) bool
        }

        class PushChannel {
            -firebaseKey: string
            -apnsKey: string
            +send(notification, recipient) DeliveryAttempt
            +getStatus(attemptId) DeliveryStatus
            +validateRecipient(recipient) bool
        }

        class WebhookChannel {
            -signingSecret: string
            -timeout: int
            +send(notification, recipient) DeliveryAttempt
            +getStatus(attemptId) DeliveryStatus
            +validateRecipient(recipient) bool
        }
    }

    namespace Models {
        class Notification {
            +id: uuid
            +channel: string
            +subject: string
            +body: string
            +priority: string
            +createdAt: timestamp
        }

        class Recipient {
            +id: uuid
            +email: string
            +phone: string
            +deviceTokens: List~string~
            +preferences: Map~string, bool~
        }

        class DeliveryAttempt {
            +id: uuid
            +notificationId: uuid
            +recipientId: uuid
            +status: DeliveryStatus
            +attemptNumber: int
            +sentAt: timestamp
        }

        class DeliveryStatus {
            <<enumeration>>
            QUEUED
            SENDING
            DELIVERED
            FAILED
            BOUNCED
        }
    }

    NotificationService *-- NotificationQueue : contains
    NotificationService *-- ChannelRegistry : contains
    ChannelRegistry --> Channel : resolves

    Channel <|.. EmailChannel : implements
    Channel <|.. SMSChannel : implements
    Channel <|.. PushChannel : implements
    Channel <|.. WebhookChannel : implements

    Channel ..> Notification : receives
    Channel ..> Recipient : delivers to
    Channel ..> DeliveryAttempt : produces

    DeliveryAttempt --> DeliveryStatus : has

    style Channel fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#3b0764
    style DeliveryStatus fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#3b0764
    style NotificationService fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
    style NotificationQueue fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
    style ChannelRegistry fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
    style EmailChannel fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
    style SMSChannel fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
    style PushChannel fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
    style WebhookChannel fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
    style Notification fill:#f3f4f6,stroke:#6b7280,stroke-width:2px,color:#1f2937
    style Recipient fill:#f3f4f6,stroke:#6b7280,stroke-width:2px,color:#1f2937
    style DeliveryAttempt fill:#f3f4f6,stroke:#6b7280,stroke-width:2px,color:#1f2937

Why this works

  • 3 namespaces mirror architectural layers — Core (orchestration), Channels (delivery implementations), Models (data). A developer can scan one namespace without reading the others.
  • Color encodes the role — purple for interfaces/enums, blue for core services, green for concrete implementations, gray for data models. The pattern is instantly recognizable.
  • Relationship types are deliberate — composition (*--) for "owns and manages", implementation (<|..) for "fulfills contract", dependency (..>) for "uses at runtime". Each arrow type carries meaning.

references/diagrams/git_graph.md (verbatim)

<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->

Git Graph

Back to Style Guide — Read the style guide first for emoji, color, and accessibility rules.

Syntax keyword: gitGraph Best for: Branching strategies, merge workflows, release processes, git-flow visualization When NOT to use: General processes (use Flowchart), project timelines (use Gantt)

Exemplar Diagram

gitGraph
    accTitle: Trunk-Based Development Workflow
    accDescr: Git history showing short-lived feature branches merging into main with release tags demonstrating trunk-based development

    commit id: "init"
    commit id: "setup CI"

    branch feature/auth
    checkout feature/auth
    commit id: "add login"
    commit id: "add tests"

    checkout main
    merge feature/auth id: "merge auth" tag: "v1.0"

    commit id: "update deps"

    branch feature/dashboard
    checkout feature/dashboard
    commit id: "add charts"
    commit id: "add filters"

    checkout main
    merge feature/dashboard id: "merge dash"

    commit id: "perf fixes" tag: "v1.1"

Tips

  • Use descriptive id: labels on commits
  • Add tag: for release versions
  • Branch names should match your actual convention (feature/, fix/, release/)
  • Show the ideal workflow — this is prescriptive, not descriptive
  • Use type: HIGHLIGHT on important merge commits
  • Keep to 10–15 commits maximum for readability

Template

gitGraph
    accTitle: Your Title Here
    accDescr: Describe the branching strategy and merge pattern

    commit id: "initial"
    commit id: "second commit"

    branch feature/your-feature
    checkout feature/your-feature
    commit id: "feature work"
    commit id: "add tests"

    checkout main
    merge feature/your-feature id: "merge feature" tag: "v1.0"

references/diagrams/mindmap.md (verbatim)

<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->

Mindmap

Back to Style Guide — Read the style guide first for emoji, color, and accessibility rules.

Syntax keyword: mindmap Best for: Brainstorming, concept organization, knowledge hierarchies, topic breakdown When NOT to use: Sequential processes (use Flowchart), timelines (use Timeline)

⚠️ Accessibility: Mindmaps do not support accTitle/accDescr. Always place a descriptive italic Markdown paragraph directly above the code block.

Exemplar Diagram

Mindmap showing a platform engineering team's key responsibility areas organized into infrastructure, developer experience, security, and observability domains:

mindmap
    root((🏗️ Platform Engineering))
        ☁️ Infrastructure
            Kubernetes clusters
            Service mesh
            Load balancing
            Auto-scaling
        🔧 Developer Experience
            CI/CD pipelines
            Local dev environments
            Internal CLI tools
            Documentation
        🔐 Security
            Secret management
            Network policies
            Vulnerability scanning
            Access control
        📊 Observability
            Metrics collection
            Log aggregation
            Distributed tracing
            Alerting rules

Tips

  • Keep to 3–4 main branches with 3–5 sub-items each
  • Use emoji on branch headers for visual distinction
  • Don't nest deeper than 3 levels
  • Root node uses (( )) for circle shape
  • Always pair with a Markdown text description above for screen readers

Template

Description of what this mindmap shows and the key categories it covers:

mindmap
    root((🎯 Central Concept))
        📋 Branch One
            Sub-item A
            Sub-item B
            Sub-item C
        🔧 Branch Two
            Sub-item D
            Sub-item E
        📊 Branch Three
            Sub-item F
            Sub-item G
            Sub-item H

Back to K-Dense-AI/scientific-agent-skills (AI Scientist skills) or Agent skills.