Generated banner for Markdown Mermaid Writing
Generated logo for Markdown Mermaid Writing

Markdown Mermaid Writing

K-DenseCommunityCreated by Clayton Young / Superior Byte Works, LLC (@borealBytes)Distributed by K-Dense

  • Skill
  • Tool integration
  • Documents and content
  • Apache-2.0
  • Low risk

From the author

Writes scientific Markdown documentation and Mermaid diagrams for workflows, relationships, timelines, and schemas. Provides syntax references, document templates, accessibility guidance, and version-aware rendering checks. Use when a user requests Markdown, Mermaid, or a text-based structural diagram; quantitative scientific figures require suitable plotting tools.
— the description by Clayton Young / Superior Byte Works, LLC (@borealBytes)

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to creating technical and scientific documentation using Markdown and Mermaid. It emphasizes the use of text-based diagrams for structural clarity, ensuring that workflows, architectures, and data models remain editable, version-controlled, and accessible. The skill includes templates for various document types and comprehensive guides for 23 different Mermaid diagram types, ensuring consistent formatting and adherence to accessibility standards.

What it does

  • Writes scientific Markdown reports, READMEs, and research documentation.
  • Creates structural Mermaid diagrams for workflows, timelines, schemas, and architectures.
  • Provides templates for common technical documents like ADRs, pull requests, and status reports.
  • Offers style guides for consistent Markdown formatting and Mermaid diagram design.
  • Includes accessibility guidance for diagrams using titles and descriptions.
  • Supports version-aware rendering checks for Mermaid diagrams.

When to use it

  • When you need to document complex workflows, system architectures, or data relationships.
  • When you want to maintain diagrams as editable text within a Git repository.
  • When creating technical reports that require a consistent, professional house style.
  • When you need to ensure your diagrams are accessible and renderable across different platforms.

Advantages

  • Diagrams are stored as plain text, making them easily diffable and version-controlled.
  • Reduces token usage compared to long-form text descriptions of relationships.
  • Promotes a consistent documentation style across projects.
  • Supports accessibility through standardized metadata.
  • Facilitates easy updates to diagrams without needing specialized image editing software.

Usage examples

“Create a Mermaid flowchart for a data processing pipeline.”
Generates a Markdown-formatted document containing a Mermaid flowchart block that maps the data pipeline steps, following the established style guide.
“Draft an Architecture Decision Record (ADR) for a new database choice.”
Produces a structured Markdown document using the ADR template, including placeholders for context, decision, and consequences.
“How do I create a sequence diagram for an API interaction?”
Provides the specific Mermaid sequence diagram syntax, a copy-paste template, and tips on how to style it according to the project's guidelines.
“Check if my Mermaid diagram is accessible.”
Reviews the diagram code for required accessibility metadata (accTitle/accDescr) and suggests improvements based on the Mermaid style guide.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/k-dense-ai/markdown-mermaid-writing/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip markdown-mermaid-writing.zip -d .agents/skills

Documentation by Clayton Young / Superior Byte Works, LLC (@borealBytes)

Markdown and Mermaid Writing

Overview

This skill provides an optional house style for Markdown documentation with Mermaid structural diagrams. Follow the requested output format, existing repository conventions, and journal requirements first. This skill does not replace scientific analysis or plotting.

A relationship expressed as Mermaid inside a .md file is editable text that diffs cleanly in git. A compatible host renders it without a separate user build step. It renders where the host has Mermaid support; plain Markdown viewers may show only code, and platforms/extensions ship different Mermaid versions. It uses a compact source representation, though token use depends on the diagram. Exporting SVG/PNG requires a renderer; retain the diagram source alongside exported figures.

"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:

  • Writing a requested Markdown report, README, methods overview, or research note

  • Diagramming a workflow, data pipeline, schema, state machine, or conceptual relationship

  • Maintaining editable Mermaid sources and their rendered SVG/PNG exports

Use scientific plotting tools directly for measured data, uncertainty, statistical graphics, exact geometry, or publication figures that Mermaid cannot faithfully represent. Mermaid is not a required precursor to a quantitative chart or an existing SVG/code-native asset.

🎨 The Source Format Philosophy

Why text-based diagrams win
What mattersMermaid in MarkdownPython / AI Image
Git diff readable✅ text sourcePlotting code/SVG can also be text
Editable source✅Plotting scripts and vector sources are editable
Compact relationship notationOftenDepends on representation
Native previewHost/version dependentViewer/format dependent
Parseable by AI without vision✅❌
Works in destinationCheck Mermaid support and versionCheck image format support
Accessible (screen readers)Check SVG metadata and text alternativeProvide alt text/data table
Convertible to image later✅ anytime— already image
The three-phase workflow
flowchart LR
    accTitle: Three-Phase Documentation Workflow
    accDescr: Markdown holds the structural diagram source. Quantitative charts come from data and plotting code; optional illustrations require a separate factual review.

    p1["📄 Phase 1<br/>Mermaid in Markdown<br/>(structural source)"]
    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
    data["Data and plotting code"] --> 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

Retain Mermaid for structural diagrams and data/code for quantitative charts. An AI illustration is not a quantitative conversion; verify every label and relationship against its sources.

What Mermaid can express

This skill includes 23 diagram-type guides plus a composition guide. Mermaid supports additional types; these references are a curated subset, not an exhaustive version catalogue:

Use caseDiagram typeFile
Experimental workflow / decision logicFlowchartreferences/diagrams/flowchart.md
Service interactions / API calls / messagingSequencereferences/diagrams/sequence.md
Data model / schemaER diagramreferences/diagrams/er.md
State machine / lifecycleStatereferences/diagrams/state.md
Project timeline / roadmapGanttreferences/diagrams/gantt.md
Proportions / compositionPiereferences/diagrams/pie.md
System architecture (zoom levels)C4references/diagrams/c4.md
Concept hierarchy / brainstormMindmapreferences/diagrams/mindmap.md
Chronological events / historyTimelinereferences/diagrams/timeline.md
Class hierarchy / type relationshipsClassreferences/diagrams/class.md
User journey / satisfaction mapUser Journeyreferences/diagrams/user_journey.md
Two-axis comparison / prioritizationQuadrantreferences/diagrams/quadrant.md
Requirements traceabilityRequirementreferences/diagrams/requirement.md
Flow magnitude / resource distributionSankeyreferences/diagrams/sankey.md
Numeric trends / bar + line chartsXY Chartreferences/diagrams/xy_chart.md
Component layout / spatial arrangementBlockreferences/diagrams/block.md
Work item status / task columnsKanbanreferences/diagrams/kanban.md
Cloud infrastructure / service topologyArchitecturereferences/diagrams/architecture.md
Multi-dimensional comparison / skills radarRadarreferences/diagrams/radar.md
Hierarchical proportions / budgetTreemapreferences/diagrams/treemap.md
Binary protocol / data formatPacketreferences/diagrams/packet.md
Git branching / merge strategyGit Graphreferences/diagrams/git_graph.md
Code-style sequence (programming syntax)ZenUMLreferences/diagrams/zenuml.md
Multi-diagram composition patternsComplex Examplesreferences/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 typeTemplate
Pull request recordtemplates/pull_request.md
Issue / bug / feature requesttemplates/issue.md
Sprint / project boardtemplates/kanban.md
Architecture decision (ADR)templates/decision_record.md
Presentation / briefingtemplates/presentation.md
Research paper / analysistemplates/research_paper.md
Project documentationtemplates/project_documentation.md
How-to / tutorialtemplates/how_to_guide.md
Status reporttemplates/status_report.md
Step 2: Read the style guide

For this Markdown workflow, read references/markdown_style_guide.md. Treat emoji, heading counts, and horizontal rules as house style rather than Markdown syntax requirements.

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

  • Support factual claims — use verified sources and the requested citation format

  • Bold sparingly — max 2-3 bold terms per paragraph, never full sentences

  • Optional horizontal rules after </details> when they improve separation

  • 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.

Add accessibility metadata for types that emit it in the chosen renderer:

accTitle: Short Name 3-8 Words
accDescr: One or two sentences explaining what this diagram shows.
  • Prefer host themes; %%{init} directives are deprecated in favor of YAML configuration

  • Prefer reusable classDef where supported; style syntax is diagram-specific

  • One emoji per node max — at the start of the label

  • Use descriptive IDs with the type's syntax: snake_case works for flowcharts; ER/class/state conventions differ

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.

Render in the actual destination before delivery. Check its Mermaid version and plugin requirements before choosing newer diagram types; GitHub documents an info diagram for this check. A successful latest-version local preview does not establish GitHub or another host will render it. Where Mermaid is unsupported, supply a rendered SVG/PNG with a text description alongside the retained .md source.

Step 5: Retain source and verification

Keep the .md source, rendered deliverable, and tested renderer version together. Follow the project's version-control workflow; this skill does not itself authorize a commit or publication. For CLI export, embedding, and the tested accessibility matrix, read Current rendering and validation.


⚠️ Common pitfalls

Radar chart syntax (radar-beta)

WRONG (shown as text so it does not break the document renderer):

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

CORRECT:

radar-beta
accTitle: Example Radar Scores
accDescr: Illustrative values of one, two, and three on a shared zero-to-three scale.
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

  • Mermaid 12.0.0 radar emits accTitle/accDescr; check older hosts and retain a visible description

XY Chart vs Radar confusion
DiagramKeywordAxis syntaxData syntax
XY Chart (bars/lines)xychart-betax-axis ["Label1", "Label2"]bar [10, 20] or line [10, 20]
Radar (spider/web)radar-betaaxis 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 on a stated, common score scale. See the data table for exact values.

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

For a manuscript that uses Mermaid structural figures, this skill handles diagram syntax. Follow the manuscript's required figure formats and scientific visualization conventions.

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 plotting or schematic tools where appropriate to the scientific content
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 a document using this skill, check:

  • [ ] Does the document use a template? If so, did I start from the right one?

  • [ ] Is each diagram in an appropriate format, with working accessibility metadata or a text alternative?

  • [ ] Is configuration supported by the destination and tested in light/dark themes?

  • [ ] Do citations support external claims, and are synthetic values labeled?

  • [ ] One H1, emoji on H2 only?

  • [ ] Does the final Markdown/HTML structure render correctly?


📚 Reference index

Style guides
GuidePathLinesWhat it covers
Markdown Style Guidereferences/markdown_style_guide.mdsee fileHeadings, formatting, citations, tables, Mermaid integration, templates, quality checklist
Mermaid Style Guidereferences/mermaid_style_guide.mdsee fileAccessibility, emoji set, color classes, theme neutrality, type selection, complexity tiers
Current Renderingreferences/current-rendering.mdsee fileMermaid 12 changes, CLI export, browser APIs, tested accessibility matrix, scientific checks
Diagram guides (23 types plus composition)

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 synthetic quality-control report with explicitly invented data, an auditable count table, a structural flowchart, a bar chart, and a chronology. It makes no experimental or software API claims.


📝 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/

Files

templates/research_paper.md

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

Research Paper / Technical Analysis Template

Back to Markdown Style Guide — Read the style guide first for formatting, citation, and emoji rules.

Use this template for: Research papers, technical analyses, literature reviews, data-driven reports, competitive analyses, market research, or any document built around evidence and methodology. Designed for heavy citation, structured argumentation, and reproducible findings.

Key features: Abstract for quick assessment, methodology section for credibility, findings with supporting data/diagrams, rigorous footnote citations throughout, and a complete references section.

Philosophy: A great research document lets the reader evaluate your conclusions independently. Show your work. Cite your sources. Present counter-arguments. The reader should trust your findings because the evidence is right there — not because you said so.


How to Use

  1. Copy this file to your project

  2. Replace all [bracketed placeholders] with your content

  3. Adjust sections — not every paper needs every section, but the core flow (Abstract → Introduction → Methodology → Findings → Conclusion) should stay intact

  4. Cite aggressively — every claim, every statistic, every external methodology reference gets a [^N] footnote

  5. Add Mermaid diagrams for any process, architecture, data flow, or comparison


Template Structure

1. Abstract — What you did, what you found, why it matters (150-300 words)
2. 📋 Introduction — Problem statement, context, scope, research questions
3. 📚 Background — Prior work, literature review, industry context
4. 🔬 Methodology — How you did the research, data sources, approach
5. 📊 Findings — What you discovered, with evidence and diagrams
6. 💡 Analysis — What the findings mean, implications, limitations
7. 🎯 Conclusions — Summary, recommendations, future work
8. 🔗 References — All cited sources with full URLs

The Template

Everything below the line is the template. Copy from here; commands, API routes, versions, thresholds, and numerical values are illustrative placeholders. Verify them against the actual project before publishing. Follow its existing tracker and PR conventions.


[Paper Title: Descriptive and Specific]

[Author(s) or Team] · [Organization] · [Date]


Abstract

[150–300 word summary structured as: Context (1–2 sentences on the problem space), Objective (what this paper investigates), Method (how the research was conducted), Key findings (the most important results), Significance (why this matters and who should care).]

Keywords: [keyword 1], [keyword 2], [keyword 3], [keyword 4], [keyword 5]


📋 Introduction

Problem statement

[What problem exists? Why does it matter? Who is affected? Be specific — include metrics where available.]

[The scope of the problem, with citation][^1].

Research questions

This paper investigates:

  1. [RQ1] — [Specific, answerable question]

  2. [RQ2] — [Specific, answerable question]

  3. [RQ3] — [Specific, answerable question]

Scope and boundaries
  • In scope: [What this paper covers]

  • Out of scope: [What this paper deliberately excludes and why]

  • Target audience: [Who will benefit from these findings]

<details> <summary><strong>💬 Context Notes</strong></summary>

  • Why this research was initiated

  • Organizational context or business driver

  • Relationship to prior internal work

  • Known constraints that shaped the scope

</details>


📚 Background

Industry context

[Current state of the field. What's known. What the established approaches are. Cite existing work.]

[Key finding from prior research][^2]. [Another relevant study found][^3].

Prior work
Study / SourceKey FindingRelevance to Our Work
[Author (Year)][^4][What they found][How it connects]
[Author (Year)][^5][What they found][How it connects]
[Author (Year)][^6][What they found][How it connects]
Gap in current knowledge

[What's missing from existing research? What question remains unanswered? This is the gap your paper fills.]

<details> <summary><strong>📋 Extended Literature Review</strong></summary>

[Deeper discussion of related work, historical context, evolution of approaches, and detailed comparison of methodologies used by prior researchers. This depth supports the paper's credibility without cluttering the main flow.]

</details>


🔬 Methodology

Approach

[Describe your research methodology — qualitative, quantitative, mixed methods, experimental, observational, case study, etc.]

flowchart LR
    accTitle: Research Methodology Flow
    accDescr: Four-phase research process from data collection through analysis to validation and reporting

    collect[📥 Data collection] --> clean[⚙️ Data cleaning]
    clean --> analyze[🔍 Analysis]
    analyze --> validate[🧪 Validation]
    validate --> report[📤 Report findings]

    classDef process fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
    class collect,clean,analyze,validate,report process
Data sources
SourceTypeSize / ScopeCollection Period
[Source 1][Survey / API / Database / etc.][N records / respondents][Date range]
[Source 2][Type][Size][Date range]
Tools and technologies
  • [Tool 1] — [Purpose and version]

  • [Tool 2] — [Purpose and version]

  • [Analysis framework] — [Why this was chosen]

Limitations of methodology

⚠️ Known limitations: [Be upfront about what could affect the validity of your results — sample size, selection bias, time constraints, data quality issues. This builds credibility, not weakness.]

<details> <summary><strong>🔧 Detailed Methodology</strong></summary>

Data collection protocol

[Step-by-step description of how data was gathered]

Cleaning and preprocessing

[What transformations were applied, what was excluded and why]

Statistical methods

[Specific tests, confidence levels, software used]

Reproducibility

[How someone else could replicate this research — data availability, code repositories, environment setup]

</details>


📊 Findings

Finding 1: [Descriptive title]

[Present the finding clearly. Lead with the conclusion, then show the evidence.]

[Data supporting this finding][^7]:

MetricBeforeAfterChange
[Metric 1][Value][Value][+/- %]
[Metric 2][Value][Value][+/- %]

📌 Key insight: [One-sentence takeaway from this finding]

Finding 2: [Descriptive title]

[Present the finding. Include a diagram if the finding involves relationships, processes, or comparisons.]

xychart-beta
    title "[Chart title]"
    x-axis ["Category A", "Category B", "Category C", "Category D"]
    y-axis "Measurement" 0 --> 100
    bar [45, 72, 63, 89]

[Explanation of what the data shows and why it matters.]

Finding 3: [Descriptive title]

[Present the finding with supporting evidence.]

<details> <summary><strong>📊 Supporting Data Tables</strong></summary>

[Detailed data tables, raw numbers, statistical breakdowns that support the findings but would interrupt the reading flow if placed inline. Readers who want to verify can expand.]

</details>


💡 Analysis

Interpretation

[What do the findings mean? Connect back to your research questions. Explain the "so what?"]

  • RQ1: [How Finding 1 answers Research Question 1]

  • RQ2: [How Finding 2 answers Research Question 2]

  • RQ3: [How Finding 3 answers Research Question 3]

Implications

For [audience 1]:

  • [What this means for them and what action they should consider]

For [audience 2]:

  • [What this means for them and what action they should consider]

Comparison with prior work

[How do your findings compare with the studies referenced in the Background section? Do they confirm, contradict, or extend prior work?]

Limitations

[What caveats should the reader keep in mind? What factors might affect generalizability? Be honest — this is where credibility is built.]

<details> <summary><strong>💬 Discussion Notes</strong></summary>

  • Alternative interpretations of the data

  • Edge cases or outliers observed

  • Areas where more data would strengthen conclusions

  • Potential confounding variables

</details>


🎯 Conclusions

Summary

[3–5 sentences. Restate the problem, summarize the key findings, and state the primary recommendation. A reader who skips to this section should understand the entire paper's value.]

Recommendations
  1. [Recommendation 1] — [Specific, actionable. What to do, who should do it, expected impact]

  2. [Recommendation 2] — [Specific, actionable]

  3. [Recommendation 3] — [Specific, actionable]

Future work
  • [Research direction 1] — [What it would investigate and why it matters]

  • [Research direction 2] — [What it would investigate and why it matters]


🔗 References

All sources cited in this paper:

[^1]: [Author/Org]. ([Year]). "[Title]." [Publication]. https://example.com

[^2]: [Author/Org]. ([Year]). "[Title]." [Publication]. https://example.com

[^3]: [Author/Org]. ([Year]). "[Title]." [Publication]. https://example.com

[^4]: [Author/Org]. ([Year]). "[Title]." [Publication]. https://example.com

[^5]: [Author/Org]. ([Year]). "[Title]." [Publication]. https://example.com

[^6]: [Author/Org]. ([Year]). "[Title]." [Publication]. https://example.com

[^7]: [Author/Org]. ([Year]). "[Title]." [Publication]. https://example.com


Last updated: [Date]

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Declares allowed tools, Needs Node.js

The author says: Markdown authoring needs no runtime. Local rendering targets Mermaid and Mermaid CLI 12.0.0, Node.js 22.13+ and a supported Chromium browser. Package or CDN installation needs network access; no credentials required.

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Clayton Young / Superior Byte Works, LLC (@borealBytes)
Publisher
K-Dense (Community)
Distributed by
K-Dense
Source
K-Dense-AI/scientific-agent-skills · skills/markdown-mermaid-writing · commit a25cf9e
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (written by AutoGineer)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Clayton Young / Superior Byte Works, LLC (@borealBytes) or K-Dense.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download markdown-mermaid-writing.zip