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
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
Download the skill as a ZIP:
https://autogineer.com/agent-skills/k-dense-ai/markdown-mermaid-writing/downloadUnzip 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 matters | Mermaid in Markdown | Python / AI Image |
|---|---|---|
| Git diff readable | ✅ text source | Plotting code/SVG can also be text |
| Editable source | ✅ | Plotting scripts and vector sources are editable |
| Compact relationship notation | Often | Depends on representation |
| Native preview | Host/version dependent | Viewer/format dependent |
| Parseable by AI without vision | ✅ | ❌ |
| Works in destination | Check Mermaid support and version | Check image format support |
| Accessible (screen readers) | Check SVG metadata and text alternative | Provide 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 outputRetain 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 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
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 separationTables 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 configurationPrefer reusable
classDefwhere supported; style syntax is diagram-specificOne emoji per node max — at the start of the label
Use descriptive IDs with the type's syntax:
snake_caseworks 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 3Use
radar-betanotradar(the bare keyword doesn't exist)Use
axisto define dimensions, notx-axisUse
curveto define data series, not quoted labels with colonMermaid 12.0.0 radar emits
accTitle/accDescr; check older hosts and retain a visible description
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 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 figureWith 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 contentWith 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
| Guide | Path | Lines | What it covers |
|---|---|---|---|
| Markdown Style Guide | references/markdown_style_guide.md | see file | Headings, formatting, citations, tables, Mermaid integration, templates, quality checklist |
| Mermaid Style Guide | references/mermaid_style_guide.md | see file | Accessibility, emoji set, color classes, theme neutrality, type selection, complexity tiers |
| Current Rendering | references/current-rendering.md | see file | Mermaid 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.
Source: https://github.com/SuperiorByteWorks-LLC/agent-project
Author: Clayton Young / Superior Byte Works, LLC (@borealBytes)
License: Apache-2.0
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
- ATTRIBUTION.mdAdded by AutoGineer1.1 KiB
- LICENSEAdded by AutoGineer10.0 KiB
- SKILL.md16.3 KiB
- assets/examples/example-research-report.md3.4 KiB
- references/current-rendering.md7.6 KiB
- references/diagrams/architecture.md5.0 KiB
- references/diagrams/block.md5.0 KiB
- references/diagrams/c4.md6.7 KiB
- references/diagrams/class.md8.6 KiB
- references/diagrams/complex_examples.md16.8 KiB
- references/diagrams/er.md8.0 KiB
- references/diagrams/flowchart.md7.0 KiB
- references/diagrams/gantt.md6.0 KiB
- references/diagrams/git_graph.md2.2 KiB
- references/diagrams/kanban.md4.0 KiB
- references/diagrams/mindmap.md2.5 KiB
- references/diagrams/packet.md2.4 KiB
- references/diagrams/pie.md1.9 KiB
- references/diagrams/quadrant.md2.6 KiB
- references/diagrams/radar.md2.8 KiB
- references/diagrams/requirement.md3.0 KiB
- references/diagrams/sankey.md2.6 KiB
- references/diagrams/sequence.md5.9 KiB
- references/diagrams/state.md5.7 KiB
- references/diagrams/timeline.md4.5 KiB
- references/diagrams/treemap.md2.6 KiB
- references/diagrams/user_journey.md5.2 KiB
- references/diagrams/xy_chart.md2.6 KiB
- references/diagrams/zenuml.md2.5 KiB
- references/markdown_style_guide.md32.4 KiB
- references/mermaid_style_guide.md26.6 KiB
- templates/decision_record.md7.2 KiB
- templates/how_to_guide.md7.1 KiB
- templates/issue.md11.6 KiB
- templates/kanban.md10.6 KiB
- templates/presentation.md8.1 KiB
- templates/project_documentation.md11.5 KiB
- templates/pull_request.md11.8 KiB
- templates/research_paper.md10.1 KiB
- templates/status_report.md7.2 KiB
templates/pull_request.md
<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->
Pull Request Documentation Template
Back to Markdown Style Guide — Read the style guide first for formatting, citation, and emoji rules.
Use this template for: Documenting pull requests as persistent, searchable markdown records. It can serve as a companion record or the PR body, according to project conventions. It captures everything: what changed, why, how to verify, security impact, deployment strategy, and what was learned.
Key features: Summary with impact classification, change inventory with before/after, testing evidence, security review, breaking change documentation, deployment strategy, observability plan, rollback plan, and reviewer checklist.
Project convention: Use this optional file-based record only when the project requests it. Preserve the established tracker/PR workflow, link the live record, and replace all example paths. Editing this Markdown file does not update a hosted issue, PR, or board.
File Convention
docs/project/pr/pr-00000123-fix-auth-timeout.md
docs/project/pr/pr-00000124-add-job-retry-metrics.md
docs/project/pr/pr-00000125-refactor-ci-stage-order.mdDirectory:
docs/project/pr/Naming:
pr-+ PR number zero-padded to 8 digits +-+ short lowercase hyphenated descriptionCross-reference: Link to the live PR in the metadata table
GitHub PR body: Follow the repository template and include the actual summary and validation; optionally link this file (for example,
https://github.com/<org>/<repo>/blob/<branch>/docs/project/pr/pr-00000123-fix-auth-timeout.md)
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.
PR-[NUMBER]: [Concise Title — What This Changes]
| Field | Value |
|---|---|
| PR | #NUMBER (add tracker URL if your project uses one) |
| Author | [Name] |
| Date | [YYYY-MM-DD] |
| Status | [Open / Merged / Closed] |
| Branch | [feature/branch-name] → main |
| Related issues | #ISSUE (replace with the project link), #ISSUE2 (replace with the project link) |
| Deploy strategy | [Standard / Canary / Blue-green / Feature flag] |
📋 Summary
What changed and why
[2–4 sentences. What this PR does at a business/product level, not code level. Why was this change necessary? What problem does it solve or what feature does it enable?]
Impact classification
| Dimension | Level | Notes |
|---|---|---|
| Risk | 🟢 Low / 🟡 Medium / 🔴 High | [Why this risk level] |
| Scope | [Narrow / Moderate / Broad] | [What areas are affected] |
| Reversibility | [Easily reversible / Requires migration / Irreversible] | [Rollback complexity] |
| Security | [None / Low / Medium / High] | [Auth, data, or permissions changes?] |
🔍 Changes
Change inventory
| File / Area | Change type | Description |
|---|---|---|
[path/to/file] | [Added / Modified / Deleted / Renamed] | [What changed and why] |
[path/to/file] | [Type] | [Description] |
[path/to/file] | [Type] | [Description] |
Before and after
[For behavioral changes, show the difference. Use code blocks, screenshots, or diagrams as appropriate.]
Before:
[Previous behavior, output, or code pattern]After:
[New behavior, output, or code pattern]Architecture impact
[If this PR changes how components interact, include a diagram. Skip this section for small changes.]
flowchart LR
accTitle: Architecture Change
accDescr: How this PR modifies the component interaction pattern
a[⚙️ Component A] -->|New path| b[📦 Component B]
b --> c[💾 Data Store]<details> <summary><strong>📋 Detailed Change Notes</strong></summary>
[Extended context for complex PRs — design tradeoffs, alternative approaches considered, migration details, performance benchmarks, or anything that helps reviewers understand the depth of the change.]
</details>
🧪 Testing
How to verify
# Steps a reviewer can follow to test this change locally
[command 1]
[command 2]
[command 3 — with expected output]Test coverage
| Test type | Status | Notes |
|---|---|---|
| Unit tests | [Run result or Not run] | [N new / N modified] |
| Integration tests | [Run result or Not run] | [Details] |
| Manual testing | [Verified with evidence or Not run] | [What was tested manually] |
| Performance | ⬜ N/A | [Or benchmark results if relevant] |
Edge cases considered
[Edge case 1 — how it's handled]
[Edge case 2 — how it's handled]
[Edge case 3 — or "not applicable" for this change]
🔒 Security
Security checklist
[ ] No secrets, credentials, API keys, or PII in the diff
[ ] Authentication/authorization changes reviewed (if applicable)
[ ] Input validation added for new user-facing inputs
[ ] Injection protections maintained (SQL, XSS, CSRF)
[ ] Dependencies scanned for known vulnerabilities
[ ] Data encryption at rest/in transit maintained
Security impact: [None / Low / Medium / High] — [Brief justification]
[If security-sensitive: Reviewed by: [security reviewer name, date]]
<details> <summary><strong>🔐 Security Details</strong></summary>
[For security-sensitive changes: threat model, attack vectors considered, mitigations applied. This section helps future security audits understand what was evaluated.]
</details>
⚡ Breaking Changes
This PR introduces breaking changes: [Yes / No]
[If no, delete the rest of this section.]
What breaks
| What breaks | Who's affected | Migration path |
|---|---|---|
| [API endpoint / behavior / config] | [Service / team / users] | [How to migrate] |
Migration guide
Before:
[Old usage, API call, config, or behavior]After:
[New usage — what consumers need to change]Deprecation timeline: [When the old behavior will be removed, if applicable]
🔄 Rollback Plan
[How to revert this change if something goes wrong in production.]
Revert command:
git revert [commit-sha]Additional steps needed:
[ ] [Database migration rollback if applicable]
[ ] [Feature flag disable if applicable]
[ ] [Cache invalidation if applicable]
[ ] [Notify affected teams]
⚠️ Rollback risk: [Any caveats — data migration that's one-way, API consumers that may have adopted the new contract, etc.]
🚀 Deployment
Strategy
Approach: [Standard deploy / Canary (N% → 100%) / Blue-green / Feature flag]
Feature flags: [Flag name: [flag_name] — default: [off/on], rollout: [%/audience]]
Pre-deployment
[ ] [Database migrations applied]
[ ] [Environment variables set]
[ ] [Dependent services deployed first: [service names]]
[ ] [Feature flag configured in [flag management tool]]
Post-deployment verification
[ ] [Health check endpoint returns 200]
[ ] [Key user flow verified: [which flow]]
[ ] [Metrics baseline captured: [which metrics]]
[ ] [No error rate spike in first [N] minutes]
📡 Observability
Monitoring
Dashboard: [Link to relevant dashboard or "existing dashboards sufficient"]
Key metrics to watch: [Latency p95, error rate, throughput — be specific]
Watch window: [How long to monitor post-deploy: 15m / 1h / 24h]
Alerts
[New alerts added: [alert name, threshold, channel]]
[Existing alerts affected: [which ones and how]]
[Or: "No alert changes needed"]
Logging
[New log entries: [what's logged, at what level]]
[Changed log levels: [what changed and why]]
[Or: "No logging changes"]
Success criteria
[How do you know this deploy is healthy? Be specific: "p95 latency stays under 200ms, error rate stays below 0.1%, no new error types in logs for 1 hour."]
✅ Reviewer Checklist
[ ] Code follows project style guide and linting rules
[ ] No
TODOorFIXMEcomments introduced without linked issues[ ] Error handling covers failure modes (no empty catch blocks)
[ ] No secrets, credentials, or PII in the diff
[ ] Tests cover the happy path and at least one error path
[ ] Documentation updated if public API or behavior changed
[ ] Database migrations are reversible (if applicable)
[ ] Performance impact considered (no N+1 queries, no unbounded lists)
[ ] Breaking changes documented with migration guide (if applicable)
[ ] Feature flag configured correctly (if applicable)
[ ] Monitoring/alerting updated for new failure modes (if applicable)
[ ] Security review completed (if security-sensitive)
💬 Discussion
[Capture key review feedback and decisions made during the review process. This is the institutional memory — future developers will read this.]
Release note
Category: [Feature / Fix / Enhancement / Breaking / Security / Performance]
[One-line release note for changelog — written for end users, not developers]
Key review decisions
[Topic]: [What was discussed and what was decided]
[Topic]: [Discussion and resolution]
Follow-up items
[ ] Task that should happen after merge but isn't blocking (replace with the project link)
[ ] Technical debt to address later (replace with the project link)
🔗 References
Design document or ADR (replace with the project link)
Related issue (replace with the project link)
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