Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →okhp3/okhp3-mermaid-publish
Rendering, exporting, and publishing finished Mermaid diagrams. Use after a diagram has passed okhp3-mermaid-core's three validation gates and needs to become a viewable artifact - local PNG/SVG render, embedding in a .md file, or publishing via the Mermaid Chart MCP for a shareable link. NEVER deletes rendered output; the render IS the deliverable.
Passed 17 of 22 test cases with the skill, and 14 of 22 without it.
and 4 more in the full report
5 fixed12 passed either way3 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
I have a system flow diagram saved in `architecture.mmd`. Please generate a PNG render from it for our project files, make sure the original source file isn't deleted during rendering, and report the final output file location.
| Checked | Without skill | With skill |
|---|---|---|
| Invokes references/render-pipeline.sh architecture.mmd to execute the local render | Missed | Passed |
| Preserves architecture.mmd without deleting the source file | Passed | Passed |
The instructions your model reads when the skill loads.
OverKill Hill P³ · overkillhill.com · github.com/OKHP3
The output layer. Runs after core's Gate 1-3 validation.
Use references/render-pipeline.sh <path.mmd> [output.png]. The script:
npx --yes @mermaid-js/mermaid-cli (downloads mmdc ephemerally on first use, ~30s).mmd or the output render. This directly addresses a defect found in mgranberry's community skill, which instructs deletion of "temporary" output after user approval - the rendered file is the deliverable, not scratch spaceIf the script reports mmdc syntax errors, return to okhp3-mermaid-core Gate 1 - do not attempt to patch syntax here, this skill only renders.
Confirm the requested format and destination before running a publish step. Prefer the local pipeline, preserve source and rendered artifacts, and report the actual path or link produced. External publication requires explicit user intent and available access. Never claim a render or link succeeded when it was not executed.
If the Mermaid Chart MCP connector is available, this is the preferred publish path for diagrams that need a shareable link (vs. a local file only). See references/mcp-publish-workflow.md for the check-then-publish sequence and how to capture the resulting share link back into DIAGRAMS.md (per core's naming-conventions.md registry pattern).
If the MCP is not connected, fall back to local render and note in the registry that the diagram is local-only.
Three output shapes - .mmd file, fenced ```mermaid block in a .md file, or both (source + embed). See references/output-formats.md for the selection logic (default .mmd; fenced block when user says "embed"/"add to docs"/"README", or target is already a .md file).
Never route diagram source through third-party rendering APIs (e.g., Kroki) without explicit user consent. This is a known issue in at least one reviewed community skill - diagram content may be proprietary, and a silent cloud fallback is a data governance failure, not a convenience.
Use this skill for the named capability and its local references. External publication, installation, credentials, and destructive actions require an explicit user request and suitable access. Do not change unrelated files.
test cases passed, vs 14 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.