✎ DesignCore
Verified diagrams for documentation — draw.io, Mermaid, or Excalidraw, from a spec your AI agent can actually be trusted to write.
DesignCore turns a coordinate-free graph spec into a verified diagram, where
the model never places a shape and nothing counts as finished until it has
actually rendered. It ships three agent skills (architecture-diagram,
flow-diagram, concept-sketch) that carry the judgment layer on top.
🧭 What "verified" means
The spec compiled cleanly, every backend rendered successfully, and deterministic structural/density/geometry checks passed.
It does not mean the diagram is visually correct or that it communicates well — judgment about content stays with you.
⚖️ The two rules
| Rule | Enforcement | |
|---|---|---|
| 1️⃣ | The model never writes coordinates. | x, y, width, height, position are rejected at parse time. Geometry comes from Graphviz — always. |
| 2️⃣ | No diagram is complete without a successful render. | A missing backend raises BackendMissing naming its install command; a spec never degrades quietly into an unverified result. |
LLMs are good at structure and bad at pixels. DesignCore splits the job along exactly that line: judgment lives in the skills, mechanism lives in the package.
🚀 Install
Requires uv.
# As an installable CLI tool (from GitHub today; PyPI pending)
uv tool install git+https://github.com/BlinkVoid/DesignCore.git
# Or from a clone, for development
git clone https://github.com/BlinkVoid/DesignCore.git && cd DesignCore
uv sync
uv run designcore doctor
Render backends
designcore doctor reports what's available and names the exact install
command for anything missing:
| backend | used for |
|---|---|
mmdc (mermaid-cli) |
rendering Mermaid |
dot (graphviz) |
computing all node geometry |
drawio (snap) |
exporting .drawio to SVG/PNG |
node |
the Excalidraw SVG export helper |
The Excalidraw helper needs its own dependencies once:
npm install --prefix src/designcore/render/js
🔧 Platform notes & portability caveats
Verified on Linux. Full detail in docs/plans/2026-08-16-render-backend-findings.md.
| backend | caveat |
|---|---|
dot (graphviz) |
No sudo? Graphviz installs fine via apt-get download + dpkg -x into ~/.local with a GVBINDIR wrapper |
drawio (snap) |
Strict snap confinement: exports must run under $HOME, never /tmp; wrapper already injects --no-sandbox; headless export via xvfb-run -a |
mmdc |
Bundled Chromium may fail under AppArmor's userns restriction; renderer prefers a system browser, falls back to --no-sandbox only when none exists |
| Excalidraw helper | jsdom shims load before @excalidraw/utils |
macOS/Windows are untested for 0.1; spec/lint are pure Python — the risk sits entirely in the external backends.
🛠️ Commands
| command | does |
|---|---|
designcore new <id> --kind <kind> |
scaffold a spec with the question: prompt |
designcore render <id> |
compile → lay out → render → lint, and record a manifest entry |
designcore lint <id> |
structural, density, and geometry checks over spec and render |
designcore check |
validate diagrams.yaml against what is on disk (content-fingerprinted, clone-safe) |
designcore doctor |
report backend availability + install commands |
--root points at the diagram directory (default docs/diagrams). render
also takes --format, and the choice is sticky: an explicit flag wins over
the manifest's recorded format, which wins over the excalidraw default. A
diagram has one format and one manifest entry at a time — switching format
replaces the entry, and check reports the abandoned files as orphans.
💡 Mermaid is the right choice when the diagram lives in markdown: it renders natively on GitHub and diffs as text. See skills/_shared/references/format-selection.md.
📐 How it fits together
.spec.yaml ──► parse_spec ──► layout_spec (Graphviz) ──┬──► emit_* ──► source file
│ │
rejects coordinates │ ▼
at parse time │ render_* ──► svg + png
│ │
└────────────── lint ◄┘
│
diagrams.yaml
Judgment lives in the skills; mechanism lives in the package. The package makes no aesthetic decisions, and the skills compute no geometry.
📁 Example
A worked example lives in examples/docs/diagrams/:
one spec, its excalidraw render, and a populated manifest.
uv run designcore render designcore-pipeline --root examples/docs/diagrams
📚 Further reading
| doc | contents |
|---|---|
| ARCHITECTURE.md | layer map and module layout |
| docs/plans/2026-08-16-designcore-design.md | the design spec — and why each decision was made |
| docs/plans/2026-08-16-render-backend-findings.md | what each render backend actually does on real hardware |
📄 License
Metadata
Release files for designcore 0.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| designcore-0.1.0.tar.gz | 283.0 kB | With provenance | Details for designcore-0.1.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| designcore-0.1.0-py3-none-any.whl | Python 3 | none | any | Details for designcore-0.1.0-py3-none-any.whl |
Total release size: 327.5 kB
Release files / designcore-0.1.0.tar.gz
| Download URL | designcore-0.1.0.tar.gz |
|---|---|
| Size | 283.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
60170129f03a6d7fbaa529153f6f62d1b3c8a82f4f376ae2de486c7ea4b327f7
|
|
BLAKE2b-256 checksum How to use checksums |
9e111486efbde1d0c4c138509f1f760f3c7d198c86726a5910125797daa10114
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 25, 2026.
Transparency logRelease files / designcore-0.1.0-py3-none-any.whl
| Download URL | designcore-0.1.0-py3-none-any.whl |
|---|---|
| Size | 44.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
de1273abc59c06bb707f697936697ea369a5049f48d42a7c175d33c40b55413c
|
|
BLAKE2b-256 checksum How to use checksums |
d16b2e8c8aa64e788b8bd9377d1462ec028d8e51ddcfd75a14727c37c896e62a
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 25, 2026.
Transparency logSecurity for designcore 0.1.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for designcore-0.1.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Aug 25, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.