better-dsh 0.2.5-c → 0.2.5-e

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/docs/user-guide/skills/optional/creative/creative-draw-your-font.md

@@ -1,169 +0,0 @@
----
-title: "Draw Your Font — Turn a handwriting photo into an installable TTF font"
-sidebar_label: "Draw Your Font"
-description: "Turn a handwriting photo into an installable TTF font"
----
-
-{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}
-
-# Draw Your Font
-
-Turn a handwriting photo into an installable TTF font.
-
-## Skill metadata
-
-| | |
-|---|---|
-| Source | Optional — install with `hermes skills install official/creative/draw-your-font` |
-| Path | `optional-skills/creative\draw-your-font` |
-| Version | `0.1.0` |
-| Author | Danilo Znamerovszkij (https://github.com/danilo-znamerovszkij/draw-your-font), ported by Hermes Agent |
-| License | MIT |
-| Platforms | linux, macos, windows |
-| Tags | `font`, `handwriting`, `typography`, `ttf`, `woff`, `vision`, `creative` |
-| Related skills | [`pixel-art`](/docs/user-guide/skills/optional/creative/creative-pixel-art) |
-
-## Reference: full SKILL.md
-
-:::info
-The following is the complete skill definition that Hermes loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.
-:::
-
-# draw-your-font
-
-Photo of handwritten letters in → installable font out. You do the seeing
-(find and label letters, judge quality); the CLI does all geometry (trace,
-metrics, font assembly). Never edit SVG paths or coordinates yourself.
-
-## Setup in Hermes (once per session)
-
-The CLI is the pinned npm package `draw-your-font@0.1.0` — run it via npx (Node ≥ 18 required, no global install needed):
-
-```bash
-npx -y draw-your-font@0.1.0 --help
-```
-
-Wherever the examples below show `$DYF`, use `npx -y draw-your-font@0.1.0`. Shell variables do not persist between tool calls, so paste the full command each time. Everything runs locally; the user's handwriting never leaves the machine.
-
-Photos arrive in Hermes either as a file path in the message or via the gateway image cache — use the actual file path with the CLI. When a photo lands in the conversation with no path, ask the user for the file (the CLI needs a real file, not your memory of the image).
-
-Do the visual steps (contact sheets, previews, glyph sheets) by loading the PNGs with `vision_analyze`.
-
-## Decide the flow
-
-- **User has no photo yet** → offer the template: print, write, photograph.
-- **User shares photo(s) of handwriting** → main flow below.
-- **User pasted an image but there is no file path** → you can see it, but the
-  CLI needs a file. Ask them to drag the image file into the terminal (that
-  inserts its path) or give the path directly. Do not proceed from memory.
-- **User wants changes to a font built this session** → Refine section.
-
-## Template flow (best quality)
-
-```bash
-$DYF template -o template.pdf --charset minimal   # or: spanish
-```
-
-Tell the user: print it, write one character per box with a dark pen
-(0.5 mm+), keep the letter sitting on the solid line, then photograph each
-page from above in good light and share the file paths. The grid prints in
-light grey and vanishes during processing - only their ink survives.
-
-## Main flow: photo(s) → font
-
-**1. Segment.** Works for template pages and freeform photos alike:
-
-```bash
-$DYF segment photo1.jpg photo2.jpg -d work
-```
-
-**2. Look, then label.** Load `work/contact-1.png` with `vision_analyze` (one per photo): every
-detected blob is numbered. This is the step where your eyes matter - check:
-
-- Did every written character get exactly one box? A letter drawn with
-  separate strokes may appear as two boxes (relabel handles it: give the main
-  box the character and mark the fragment `""`), and two touching letters may
-  share one box (ask the user to re-shoot just those, or accept the gap).
-- Junk boxes (shadows, ruled lines, smudges, page edges) → label them `""`.
-
-Then write `work/labels.json` mapping blob id → character, e.g.
-`{"0": "A", "1": "B", "7": "", "8": "a"}`:
-
-- Template page: order is the charset order printed on the template - verify
-  against the sheet instead of trusting it blindly. minimal order: A–Z, a–z,
-  0–9, then `.,;:!?'"-()@#&+/$`; spanish appends `ÑñÁÉÍÓÚáéíóúü¿¡`.
-- Freeform: identify each letter from the contact sheet. Uppercase vs
-  lowercase for shape-twins (S/s, O/o, C/c, X/x…) is decided by relative size
-  and position - compare against neighbors you're sure of.
-- The user told you what they wrote (e.g. "ABC then abc")? Trust it, map in
-  reading order (top row first, left to right), and verify visually.
-- Same letter appears twice → label the better-drawn one, `""` the other.
-
-**3. Build.**
-
-```bash
-$DYF build -d work --labels work/labels.json --name "Dan's Hand"
-```
-
-Name the font after the user (ask if unclear - one short question max).
-
-**4. Judge before delivering.** Load `work/preview.png` and `work/glyphs.png` with `vision_analyze`
-and critique like an art director:
-
-- Broken or blotchy letters (bad trace) → often a faint pen stroke; try
-  `--weight 1`, or ask for a re-shoot of just that letter.
-- Everything too thin/thick → rebuild with `--weight 1` / `--weight -1`.
-- Jagged edges → rebuild with `--smooth 1.5` (up to 2).
-- A letter placed wrong (e.g. a `g` not descending) → usually a mislabel;
-  fix labels.json and rebuild.
-- Filled-in bowls (b, o, g look solid): should never happen - if it does,
-  the crop is smudged; ask for a re-shoot.
-
-Rebuilds are cheap and safe to iterate. Fix what you can yourself first;
-only bother the user for re-shoots when the source ink is the problem.
-
-**5. Deliver.** The font lands at `<workdir>/<NameWithoutSpaces>.ttf` (the
-build output prints the exact path). Give that path and how to install:
-macOS - double-click → "Install Font"; Windows - right-click → "Install".
-Mention what's missing (the build prints uncovered letters) and offer,
-without pushing:
-
-- Web formats + CSS: rebuild with `--formats ttf,woff,woff2,css`.
-- A legibility read (below).
-- Their next photo to fill missing characters: re-run segment with ALL
-  photos (old and new) into a fresh workdir - `$DYF segment p1.jpg p2.jpg -d
-  work2` - then relabel from the new contact sheets (blob ids renumber; the
-  old labels.json does not carry over) and build from the new workdir.
-
-## Refine (conversational iteration)
-
-| User says | Do |
-|---|---|
-| "smoother / rounder" | `build … --smooth 1.5` (max 2) |
-| "thicker / bolder" | `build … --weight 1` (max 2) |
-| "thinner / lighter" | `build … --weight=-1` (negative needs the `=` form) |
-| "the g looks bad" | show them `work/crops/<id>.png` for that letter; offer re-shoot or smooth |
-| "wrong letter" / swap | edit labels.json, rebuild |
-| "give me woff2 / web" | `build … --formats ttf,woff,woff2,css` |
-| custom preview text | `$DYF preview -d work --text "…"` (after a build) |
-
-All refine commands rebuild from the stored crops - no re-photographing
-needed unless the ink itself is the problem.
-
-## Legibility report (offer after delivering)
-
-```bash
-$DYF preview -d work --text "minimum mill rn m cl d I l 1 O 0 quick brown fox" -o work/legibility.png
-```
-
-Read it and give an honest, kind read: a score out of 10 for body-text use,
-the 2–3 letter pairs most likely to confuse (rn→m, cl→d, I/l/1, O/0), and one
-or two concrete fixes (rewrite those letters larger, more spacing). Note that
-display use (headings, notes) is more forgiving than paragraphs. Never gate
-delivery on this - it's advice, not a blocker.
-
-## Troubleshooting
-
-Segmentation found far too many / too few blobs, grey guide lines surviving,
-shadow blobs, faint ballpoint strokes → see
-`references/troubleshooting.md`.

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/docs/user-guide/skills/optional/creative/creative-dream-loop.md

@@ -1,297 +0,0 @@
----
-title: "Dream Loop — Build stunning 3D scenes via a concept-art fidelity loop"
-sidebar_label: "Dream Loop"
-description: "Build stunning 3D scenes via a concept-art fidelity loop"
----
-
-{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}
-
-# Dream Loop
-
-Build stunning 3D scenes via a concept-art fidelity loop.
-
-## Skill metadata
-
-| | |
-|---|---|
-| Source | Optional — install with `hermes skills install official/creative/dream-loop` |
-| Path | `optional-skills/creative/dream-loop` |
-| Version | `1.0.0` |
-| Author | Anshu Chimala (adapted by Nous Research) |
-| License | MIT |
-| Platforms | linux, macos |
-| Tags | `3d`, `games`, `webgl`, `threejs`, `image-generation`, `visual-fidelity`, `creative` |
-| Related skills | [`p5js`](/docs/user-guide/skills/bundled/creative/creative-p5js), [`claude-design`](/docs/user-guide/skills/bundled/creative/creative-claude-design), [`manim-video`](/docs/user-guide/skills/bundled/creative/creative-manim-video) |
-
-## Reference: full SKILL.md
-
-:::info
-The following is the complete skill definition that Hermes loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.
-:::
-
-# Dream Loop Skill
-
-An autonomous process for building extremely impressive visuals, especially 3D
-scenes (games, apps, usually browser three.js/WebGL): generate photorealistic
-concept art of the ideal result, build it, screenshot the live build, have a
-judge score screenshot vs concept against a gated ladder, and iterate until
-convergence. Goal: the most visually stunning result at an acceptable frame
-rate for the target platform (e.g. 60 fps browser, 120 fps modern mobile).
-
-This skill does NOT cover general web-app functionality, 2D UI design, or
-non-visual quality — only the visual-fidelity loop.
-
-## When to Use
-
-- User says "dream loop" or asks for a game/scene/app built to a very high
-  level of graphical fidelity.
-- Follow-up refinement passes on an existing visual product (see Follow-up
-  loops below).
-
-## Prerequisites
-
-- **Concept art**: the `image_generate` tool. If unavailable, stop and ask the
-  user for a concept image (or an image-generation API to connect to).
-- **Screenshots**: `browser_exec` — serve the build locally
-  (`python3 -m http.server` for static builds), then `new_tab(url)`,
-  `wait_for_load()`, `capture_screenshot()`.
-- **Judging**: `vision_analyze` (see Judge section for the one-image-per-call
-  workaround).
-- **Optional**: Blender for asset modeling — see the `blender-3d-automation`
-  skill. `delegate_task` for parallel asset work and fresh-context judging.
-
-If you don't have the tools needed for the full loop, flag that to the user
-early and stop.
-
-## Quick Reference
-
-| Stage | What happens | Artifacts (`.dream-loop/`) |
-|---|---|---|
-| 1. Target | Get/confirm the user's description | notes |
-| 2. Concept | Generate "in-engine screenshot" concept art | `concept.png` |
-| 3. Budget | Record time budget & start time (if given) | notes |
-| 4. Build | Implement the concept as well as possible in one go | source, plans |
-| 5. Screenshot | Capture live build at concept resolution | `round-N.png` |
-| 6. Self-check | Rigorous side-by-side audit before judging | assessment log |
-| 7. Judge | Ladder-scored comparison, actionable directives | verdict log |
-| 8. Iterate/Exit | Address directives or exit per criteria | — |
-
-## Procedure
-
-### 1. The target concept
-
-If the user provided a description of a game, scene, or app, proceed — don't
-ask for clarification unless it's too vague to generate concept art from. If
-they didn't, ask for it.
-
-Put working context/files in `.dream-loop/` and gitignore it (unless told
-otherwise).
-
-### 2. Concept art
-
-The concept is a realistic, high-quality, impressive target: the look of a
-current AAA game running in real time. Physically plausible materials (wet
-stone, brushed metal, cloth, glass) with real roughness and normal detail,
-correct proportions, atmosphere (fog, haze, rain, dust, volumetric light),
-cinematic lighting with a clear key and rich shadows. It should NOT be
-stylized or an artistic rendition — it should look like a true screenshot of
-the ideal result.
-
-Avoid these failure modes when generating with `image_generate`:
-
-- **Overbaked**: photographic clutter, film grain, hundreds of unique small
-  objects, excessive detail on every surface that reads as noise. A real-time
-  build with modeled assets won't match this, and it won't even look good.
-- **Oversimplified**: cartoon or toy look, flat shading, blobby primitive
-  shapes, empty surfaces. Boring; will not impress the user.
-
-Aim for the middle ground: beautiful surfaces and materials that shaders
-render well, strong atmosphere and lighting, an interesting palette, and
-focused hero elements with fine detail that draws the eye (not every element
-fighting for attention).
-
-Prompt for "in-engine screenshot" more than "concept art" and discourage the
-noisy/grainy look. Review the image with `vision_analyze`; if it hits a
-failure mode, pass it back to `image_generate` in edit mode and ask it to fix
-the issue. Save it as `.dream-loop/concept.png`.
-
-If you generated the art (the user didn't supply it), pause and confirm it
-matches the user's vision before starting the build loop.
-
-### 3. Time budget
-
-If the user gives a time budget, record the start time and check the clock
-between rounds. Don't degrade visual fidelity to hit the budget — strive for
-the absolute best result, and don't rush work to the judge. Parallelize or
-distribute work (e.g. `delegate_task` for independent assets) to hit the
-time goal, but no shortcuts: it's better to hit the time limit with
-meaningful, beautiful progress than with something broadly complete but ugly.
-
-If no time budget is given, run until an exit criterion — but warn upfront
-that this may consume a lot of tokens.
-
-### 4. Build loop
-
-Look at the concept art and implement it in one go, making that first pass
-count across every tier of the score ladder: composition, textures, lighting,
-details. Sculpt and model assets carefully (or use external ones if allowed);
-don't settle for basic procedural elements and flat surfaces unless the art
-style calls for it. Write intermediate files/plans to `.dream-loop/`.
-
-- If Blender is installed and the concept involves 3D assets, prefer modeling
-  in Blender (see the `blender-3d-automation` skill). For complex assets,
-  delegate to subagents via `delegate_task`.
-- If the user allows external assets, prefer them over modeling unless the
-  asset is simple. If unspecified, assume NO external assets from the web.
-- Do not be lazy with key environmental details (scenery, flooring,
-  buildings): simple shapes look blocky, shiny, flat, and fake. Tiny details
-  and texturing matter and need custom sculpting.
-- Use `image_generate` for textures, normal maps, skyboxes, etc. — better
-  looking and faster than procedural ones.
-
-### 5. Screenshot
-
-Serve the build (e.g. `python3 -m http.server` in the build dir), then via
-`browser_exec`: `new_tab('http://localhost:8000')`, `wait_for_load()`, allow
-the scene to settle, `capture_screenshot()`. Target the same resolution and
-aspect ratio as the concept art so the comparison is fair. Save as
-`.dream-loop/round-N.png`.
-
-### 6. Self-check before judging
-
-Each time, review the candidate screenshot yourself before submitting. Do not
-submit half-baked work. Compare screenshot and concept side by side and log an
-honest assessment of judge-readiness; only submit if confident you've
-significantly improved the score. Be rigorous and audit every pixel: big stuff
-(missing/incorrect objects, wrong scale, perspective, positioning) and small
-stuff (rendering glitches, flat untextured surfaces, ugly lighting, poor
-contrast, washed-out or oversaturated color, speckles, ugly shadows). Scan
-surface by surface, object by object, and list findings.
-
-### 7. Judge
-
-Judging should ideally be done by a fresh subagent with a clean context each
-round (`delegate_task`), to keep it objective and cheap. Give the judge the
-latest screenshot, the concept, and (from round 2 on) the previous round's
-screenshot and verdict.
-
-Mechanics: `vision_analyze` takes one image per call. Either have the judge
-make sequential calls (concept, then screenshot, then compare from memory of
-its own descriptions), or — better — stitch a labeled side-by-side composite
-with ImageMagick (`convert concept.png shot.png +append compare.png`) or PIL
-and analyze that single image.
-
-Judge prompt:
-
-> You are an art director reviewing a real-time render against its concept
-> art. Compare the screenshot to the concept and score it 0-10 using this
-> ladder. The ladder is gated: a frame cannot score above a tier's cap until
-> every requirement of the tiers below it is fully met. Be strict about the
-> gates.
->
-> - **Tier 1, shape (0-3):** camera, framing, composition, and the position
->   and rough scale of every major object match the concept. Layout, not
->   finish: every major element present, in the right region of the frame
->   (within ~10% of frame width/height), at roughly the right size (within
->   ~25%). Right place and vaguely correct outline passes even if edges and
->   surface are wrong; save precision nitpicks for Tier 4. Cap 3 until true.
-> - **Tier 2, light and color (3-5):** key light direction and color, overall
->   exposure (no clipping to black or white), shadow depth, palette,
->   contrast, atmosphere. Attend to reflections, glows, etc. Ensure the scene
->   is not too bright or dark relative to the concept. Judge the whole frame,
->   not tiny details (Tier 4). Cap 5 until lighting/reflections/color/
->   contrast are generally right.
-> - **Tier 3, materials and surfaces (5-7):** every surface reads as the
->   right material at a glance: textures, roughness, translucency, wetness,
->   reflections. Assets must not look procedural, blocky, smooth/plastic;
->   frame-dominating elements should be properly sculpted and detailed. Cap 7
->   until true.
-> - **Tier 4, fine detail (7-9):** the small things. Nitpick relentlessly;
->   inspect every little object up close. Layout aligns near-perfectly;
->   materials extremely convincing. Cap 9 until right.
-> - **Tier 5, indistinguishable (9-10):** holds up side by side and zoomed
->   in. Nitpick every pixel.
->
-> If a previous verdict and screenshot are provided: you are one reviewer in
-> a sequence, not the first. Maintain consistency. First mark each previous
-> directive LANDED, PARTIAL, or NOT DONE against the new screenshot; carry
-> forward anything PARTIAL or NOT DONE. Don't reverse a prior directive
-> unless the result is clearly worse — and if you do, say so and why.
->
-> Output format:
-> 1. Score on the first line; "Tier N" (highest fully-passed gate) on the
->    second.
-> 1b. If given a previous verdict: the LANDED / PARTIAL / NOT DONE list.
-> 2. "Blocking:" the specific failures of the *next* tier's gate. The builder
->    must clear these before anything else counts. Name the element and the
->    change, with magnitudes: "Rocks: replace the stacked ovoid boulders with
->    one continuous fractured slab; cracks 2-5cm wide, dark interiors, add
->    surface texture so they don't look flat/plastic" — not "the rocks look
->    artificial".
-> 3. Then at most 4 further directives from higher tiers, same style, ordered
->    by points recoverable.
->
-> No non-actionable feedback ("this looks synthetic") — name the specific
-> causes. Every directive must be actionable this round. Don't round up: if a
-> gate isn't fully passed, the cap holds.
-
-### 8. Exit criteria
-
-- **Score >= 8 and target FPS acceptable**: done. Show the user the latest
-  screenshot; ask if they want more iterations.
-- **Score >= 8 but FPS unacceptable**: optimize — lossless wins first, then
-  minimal-visual-impact ones. Re-judge afterwards to confirm no regression.
-- **Stall approaching** (best score hasn't improved a full point in 2 rounds,
-  or the judge named the same gap 3 times): stop incremental tweaks. Step
-  back and ask what about the *approach* is capping the score. Make one big
-  structural change in a round: swap asset strategy (sculpt in Blender, pull
-  real models/textures/HDRIs if allowed), rewrite the lighting model, rebuild
-  the composition, change the camera. Self-check carefully — big changes
-  break things. Only repeat parameter tuning if you can articulate why it
-  would work this time.
-- **Stalled** (already tried a big structural change, score flat 3 rounds,
-  judge is nitpicking or demanding intractable things like raytracing on a
-  GPU-less machine): stop, tell the user why you're blocked, give options.
-- **Otherwise**: address all or most heavy-hitting gaps this round, not just
-  the top one — rounds are expensive. Prioritize gaps that move the needle
-  most (lighting, textures, mesh detail). Only revert if the score dropped a
-  full point or more; small dips are judge noise, and reverting a whole round
-  throws out good changes with bad. If one change clearly regressed, undo
-  just that change. Loop.
-
-## Follow-up loops
-
-When building on an existing product (or the user re-invokes the skill for
-refinements), don't create new concept art in a vacuum — it may diverge from
-what exists. Instead capture a live screenshot of the current product and
-prompt `image_generate` to render the best possible version of it (current
-screenshot → AAA-graphics version of the same shot), then use that as the
-target. Multiple screens can run parallel judge loops if asked, at higher
-token cost.
-
-## Pitfalls
-
-- Overbaked or oversimplified concept art (see failure modes) — fix the
-  concept before building against it.
-- Submitting half-baked screenshots to the judge; the self-check gate exists
-  for a reason.
-- Screenshot at a different resolution/aspect than the concept — unfair
-  comparison, noisy verdicts.
-- Tunnel-visioning on incremental tweaks when the judge says you're off base.
-- Judging both images in one `vision_analyze` call — it takes one image;
-  composite them first.
-- Screenshotting before the scene loads/settles — add a wait after
-  `wait_for_load()` for asset streaming and animation warm-up.
-
-## Verification
-
-- `.dream-loop/concept.png` exists and passed the failure-mode review (and
-  user confirmation, if generated).
-- Each round has a screenshot, a logged self-assessment, and a judge verdict
-  with score + tier + directives.
-- Exit only via an explicit exit criterion; final screenshot shown to the
-  user with the final score and FPS measurement.
-
----
-Adapted from [dream-loop](https://github.com/achimala/dream-loop) by Anshu
-Chimala (MIT). Upstream license vendored as `LICENSE.txt`.

package/docs/80_upstream-docs-and-skills/hermes-dev-skill/src/docs/user-guide/skills/optional/creative/creative-excalidraw.md

@@ -1,212 +0,0 @@
----
-title: "Excalidraw — Hand-drawn Excalidraw JSON diagrams (arch, flow, seq)"
-sidebar_label: "Excalidraw"
-description: "Hand-drawn Excalidraw JSON diagrams (arch, flow, seq)"
----
-
-{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}
-
-# Excalidraw
-
-Hand-drawn Excalidraw JSON diagrams (arch, flow, seq).
-
-## Skill metadata
-
-| | |
-|---|---|
-| Source | Optional — install with `hermes skills install official/creative/excalidraw` |
-| Path | `optional-skills/creative\excalidraw` |
-| Version | `1.0.1` |
-| Author | Hermes Agent |
-| License | MIT |
-| Platforms | linux, macos, windows |
-| Tags | `Excalidraw`, `Diagrams`, `Flowcharts`, `Architecture`, `Visualization`, `JSON` |
-
-## Reference: full SKILL.md
-
-:::info
-The following is the complete skill definition that Hermes loads when this skill is triggered. This is what the agent sees as instructions when the skill is active.
-:::
-
-# Excalidraw Diagram Skill
-
-Create diagrams by writing standard Excalidraw element JSON and saving as `.excalidraw` files. These files can be drag-and-dropped onto [excalidraw.com](https://excalidraw.com) for viewing and editing. No accounts, no API keys, no rendering libraries -- just JSON.
-
-## When to use
-
-Generate `.excalidraw` files for architecture diagrams, flowcharts, sequence diagrams, concept maps, and more. Files can be opened at excalidraw.com or uploaded for shareable links.
-
-## Workflow
-
-1. **Load this skill** (you already did)
-2. **Write the elements JSON** -- an array of Excalidraw element objects
-3. **Save the file** using `write_file` to create a `.excalidraw` file
-4. **Optionally upload** for a shareable link using `scripts/upload.py` via `terminal`
-
-### Saving a Diagram
-
-Wrap your elements array in the standard `.excalidraw` envelope and save with `write_file`:
-
-```json
-{
-  "type": "excalidraw",
-  "version": 2,
-  "source": "hermes-agent",
-  "elements": [ ...your elements array here... ],
-  "appState": {
-    "viewBackgroundColor": "#ffffff"
-  }
-}
-```
-
-Save to any path, e.g. `~/diagrams/my_diagram.excalidraw`.
-
-### Uploading for a Shareable Link
-
-Run the upload script (located in this skill's `scripts/` directory) via terminal:
-
-```bash
-python skills/creative/excalidraw/scripts/upload.py ~/diagrams/my_diagram.excalidraw
-```
-
-This uploads to excalidraw.com (no account needed) and prints a shareable URL. Requires the `cryptography` pip package (`pip install cryptography`).
-
----
-
-## Element Format Reference
-
-### Required Fields (all elements)
-`type`, `id` (unique string), `x`, `y`, `width`, `height`
-
-### Defaults (skip these -- they're applied automatically)
-- `strokeColor`: `"#1e1e1e"`
-- `backgroundColor`: `"transparent"`
-- `fillStyle`: `"solid"`
-- `strokeWidth`: `2`
-- `roughness`: `1` (hand-drawn look)
-- `opacity`: `100`
-
-Canvas background is white.
-
-### Element Types
-
-**Rectangle**:
-```json
-{ "type": "rectangle", "id": "r1", "x": 100, "y": 100, "width": 200, "height": 100 }
-```
-- `roundness: { "type": 3 }` for rounded corners
-- `backgroundColor: "#a5d8ff"`, `fillStyle: "solid"` for filled
-
-**Ellipse**:
-```json
-{ "type": "ellipse", "id": "e1", "x": 100, "y": 100, "width": 150, "height": 150 }
-```
-
-**Diamond**:
-```json
-{ "type": "diamond", "id": "d1", "x": 100, "y": 100, "width": 150, "height": 150 }
-```
-
-**Labeled shape (container binding)** -- create a text element bound to the shape:
-
-> **WARNING:** Do NOT use `"label": { "text": "..." }` on shapes. This is NOT a valid
-> Excalidraw property and will be silently ignored, producing blank shapes. You MUST
-> use the container binding approach below.
-
-The shape needs `boundElements` listing the text, and the text needs `containerId` pointing back:
-```json
-{ "type": "rectangle", "id": "r1", "x": 100, "y": 100, "width": 200, "height": 80,
-  "roundness": { "type": 3 }, "backgroundColor": "#a5d8ff", "fillStyle": "solid",
-  "boundElements": [{ "id": "t_r1", "type": "text" }] },
-{ "type": "text", "id": "t_r1", "x": 105, "y": 110, "width": 190, "height": 25,
-  "text": "Hello", "fontSize": 20, "fontFamily": 1, "strokeColor": "#1e1e1e",
-  "textAlign": "center", "verticalAlign": "middle",
-  "containerId": "r1", "originalText": "Hello", "autoResize": true }
-```
-- Works on rectangle, ellipse, diamond
-- Text is auto-centered by Excalidraw when `containerId` is set
-- The text `x`/`y`/`width`/`height` are approximate -- Excalidraw recalculates them on load
-- `originalText` should match `text`
-- Always include `fontFamily: 1` (Virgil/hand-drawn font)
-
-**Labeled arrow** -- same container binding approach:
-```json
-{ "type": "arrow", "id": "a1", "x": 300, "y": 150, "width": 200, "height": 0,
-  "points": [[0,0],[200,0]], "endArrowhead": "arrow",
-  "boundElements": [{ "id": "t_a1", "type": "text" }] },
-{ "type": "text", "id": "t_a1", "x": 370, "y": 130, "width": 60, "height": 20,
-  "text": "connects", "fontSize": 16, "fontFamily": 1, "strokeColor": "#1e1e1e",
-  "textAlign": "center", "verticalAlign": "middle",
-  "containerId": "a1", "originalText": "connects", "autoResize": true }
-```
-
-**Standalone text** (titles and annotations only -- no container):
-```json
-{ "type": "text", "id": "t1", "x": 150, "y": 138, "text": "Hello", "fontSize": 20,
-  "fontFamily": 1, "strokeColor": "#1e1e1e", "originalText": "Hello", "autoResize": true }
-```
-- `x` is the LEFT edge. To center at position `cx`: `x = cx - (text.length * fontSize * 0.5) / 2`
-- Do NOT rely on `textAlign` or `width` for positioning
-
-**Arrow**:
-```json
-{ "type": "arrow", "id": "a1", "x": 300, "y": 150, "width": 200, "height": 0,
-  "points": [[0,0],[200,0]], "endArrowhead": "arrow" }
-```
-- `points`: `[dx, dy]` offsets from element `x`, `y`
-- `endArrowhead`: `null` | `"arrow"` | `"bar"` | `"dot"` | `"triangle"`
-- `strokeStyle`: `"solid"` (default) | `"dashed"` | `"dotted"`
-
-### Arrow Bindings (connect arrows to shapes)
-
-```json
-{
-  "type": "arrow", "id": "a1", "x": 300, "y": 150, "width": 150, "height": 0,
-  "points": [[0,0],[150,0]], "endArrowhead": "arrow",
-  "startBinding": { "elementId": "r1", "fixedPoint": [1, 0.5] },
-  "endBinding": { "elementId": "r2", "fixedPoint": [0, 0.5] }
-}
-```
-
-`fixedPoint` coordinates: `top=[0.5,0]`, `bottom=[0.5,1]`, `left=[0,0.5]`, `right=[1,0.5]`
-
-### Drawing Order (z-order)
-- Array order = z-order (first = back, last = front)
-- Emit progressively: background zones → shape → its bound text → its arrows → next shape
-- BAD: all rectangles, then all texts, then all arrows
-- GOOD: bg_zone → shape1 → text_for_shape1 → arrow1 → arrow_label_text → shape2 → text_for_shape2 → ...
-- Always place the bound text element immediately after its container shape
-
-### Sizing Guidelines
-
-**Font sizes:**
-- Minimum `fontSize`: **16** for body text, labels, descriptions
-- Minimum `fontSize`: **20** for titles and headings
-- Minimum `fontSize`: **14** for secondary annotations only (sparingly)
-- NEVER use `fontSize` below 14
-
-**Element sizes:**
-- Minimum shape size: 120x60 for labeled rectangles/ellipses
-- Leave 20-30px gaps between elements minimum
-- Prefer fewer, larger elements over many tiny ones
-
-### Color Palette
-
-See `references/colors.md` for full color tables. Quick reference:
-
-| Use | Fill Color | Hex |
-|-----|-----------|-----|
-| Primary / Input | Light Blue | `#a5d8ff` |
-| Success / Output | Light Green | `#b2f2bb` |
-| Warning / External | Light Orange | `#ffd8a8` |
-| Processing / Special | Light Purple | `#d0bfff` |
-| Error / Critical | Light Red | `#ffc9c9` |
-| Notes / Decisions | Light Yellow | `#fff3bf` |
-| Storage / Data | Light Teal | `#c3fae8` |
-
-### Tips
-- Use the color palette consistently across the diagram
-- **Text contrast is CRITICAL** -- never use light gray on white backgrounds. Minimum text color on white: `#757575`
-- Do NOT use emoji in text -- they don't render in Excalidraw's font
-- For dark mode diagrams, see `references/dark-mode.md`
-- For larger examples, see `references/examples.md`