creative

Files (7)

• SKILL.md
• discord-svg-infographic-cleanup.md · references/
• headless-blender-unity-prop-preview.md · references/
• personal-technical-blog-posts.md · references/
• slidev-mermaid-architecture-decks.md · references/
• slidev-mermaid-deck-polish.md · references/
• slidev-mermaid-deck-workflow.md · references/

SKILL.md (first lines)

# Creative Artifact Workflow

## Overview

Use this skill when the user wants something expressive, visual, audio, or presentation-like rather than a plain document or code artifact. This umbrella covers diagrams, infographics, mockups, ASCII art/video, generative art, slides, and stylized audio or text transformations.

The common pattern is: pick the medium, choose the rendering/style system, generate or edit with clear constraints, and verify the result in the target format.

## When to Use

- The user asks for a diagram, infographic, sketch, or design mockup
- The user wants ASCII art/video, generative art, or p5.js-style output
- The user wants slide or presentation-style visual composition
- The user wants audio or music generation, audio analysis, or stylized media output
- The user wants text humanization or a more natural creative rewrite

## Core Creative Families

### Diagrams and visual explanation
Use these when the goal is structure, architecture, or process clarity:

- architecture diagrams
- Excalidraw-style hand-drawn flows
- infographic layouts
- design-system inspired web mockups

### Slides and presentation assets
Use these when the output should be presentation-ready:

- PowerPoint-style decks
- polished design mockups
- structured content-to-slide workflows

### Generative visuals and code art
Use these when the work is expressive, animated, or interactive:

- ASCII art and ASCII video
- p5.js sketches
- Manim-style explanatory animations
- sketch/prototype-style HTML mockups
- pretext / browser-demo style creative artifacts

### Audio and music
Use these when the user wants sound, music, or audio-centric creative work:

- AI music generation workflows
- audio generation and transformation workflows
- audio feature / spectrogram analysis when the task is creative rather than purely technical

### Text style, humanization, and personal technical prose
Use these when the user wants prose to sound more natural, less robotic, or more polished:

- humanizer-style rewriting
- personal technical blog posts and portfolio writing, especially when turning real configs/repos into public-facing prose

For Semyon's personal technical blog workflow, see `references/personal-technical-blog-posts.md`: inspect the repo/content schema, match existing voice, write the actual content file, verify the build, and avoid leaking private infrastructure details.

## Practical Workflow

1. Identify the artifact type and medium.
2. Choose the narrowest rendering tool or workflow that matches the medium.
3. Define style constraints early: color palette, tone, layout, motion, size, audience.
4. When the request targets an existing site or portfolio page, inspect the actual repository, asset wiring, and locally rendered page *before* suggesting an image direction or generating anything. A request such as “check my portfolio” is an instruction to ground the work in that surface immediately, not an invitation to give general asset advice.
5. For a replacement batch of generated site imagery, check image-generation provider readiness before launching a multi-image job. Then generate into the stable public asset path, preserve the existing dimensions/aspect ratio where possible, wire or retain the content references, and visually inspect the real page at its card/hero size. Do not claim the assets were updated if generation has not produced files.
6. Generate a first pass quickly, then iterate on the strongest candidate rather than overfitting the first idea.
7. For Mermaid diagrams that must be embedded as images, render to a real web-safe image asset rather than handing off Mermaid/SVG text as if it were an image. A reliable pattern is: write `.mmd` source, render with Mermaid CLI to transparent PNG (`-b transparent`), convert/compress to WebP, and keep the source file for regeneration. For Slidev decks with zoomable SVG diagrams, also see `references/slidev-mermaid-deck-workflow.md` for SVG viewBox padding, autofit, and deployment verification patterns.
8. For Discord-ready SVG/PNG infographics, design for the actual preview surface: large readable type, explicit SVG text attributes, compact labels, no decorative text that can rasterize huge, and visual QA of the exported PNG before delivery. If a first-pass chart looks bad, use Gemini/vision-style critique to identify concrete layout problems, then regenerate rather than defending it. See `references/discord-svg-infographic-cleanup.md`.
9. Verify the artifact in the format the user will actually consume.

### Slidev + Mermaid Architecture Decks

When building a temporary technical deck from Mermaid/SVG assets:

1. Keep the deck visually human and opinionated. For Semyon's Oghma/OghmaNotes-style decks, restrained dark cards with warm orange/amber accents are acceptable and often preferred; do not reflexively strip them just because they look like template accents. If the user complains about “AI-smelly” styling, tune the specific offender and then re-check with them rather than flattening all personality.
2. Avoid silent clipping. Slidev/HTML frames with `overflow: hidden` can hide the bottom or right border of large rendered SVG diagrams. Prefer a zoomable component that reads the SVG `viewBox`, calculates a fit-to-frame scale, and centers the image on load/resize. Keep a manual `fit` control for recovery during a live demo.
3. Pad rendered Mermaid SVG `viewBox` values before publishing. Mermaid can calculate bounds exactly on the stroke/text edge, so scaling inside a clipped frame can shave off bottom/right borders. A small post-render script that expands `viewBox` by ~64–96px on all sides is safer than relying on CSS alone.
4. Do not use invalid inline comments inside the opening `<svg ...>` tag when marking processed SVGs; insert comments after the opening tag instead.
5. For code slides, avoid `overflow: hidden` unless the omission is deliberate. Use `overflow: auto` or split the snippet; clipped code looks like missing content.
6. Verify the actual served deck, not just the source: build, serve, load the page, fetch the hashed CSS asset, confirm expected accent/clipping CSS is present, and visually inspect at least the densest architecture slide.

Detailed recipe: `references/slidev-mermaid-architecture-decks.md`.

### Mermaid-to-Web Image Pattern

When a user asks for “Mermaid rendering” or an embeddable architecture image:

1. Write the `.mmd` source in the project near the consuming content, if that fits the repo structure.
2. Render with Mermaid CLI to PNG using transparent background and sufficient scale/resolution. If Puppeteer/Chromium needs setup, fix the render path (for example install a headless browser and use a Puppeteer config with `--no-sandbox` where appropriate) rather than claiming Mermaid cannot render.
3. Convert/compress the PNG to WebP for web delivery; keep PNG only if needed as a fallback.
4. Verify with real outputs: `file`, dimensions, byte size, MIME served by the dev server, and alpha-channel/corner transparency checks.
5. Visually inspect the embedded result at the actual page width. Wide flowcharts can look fine as source but become illegible in blog columns; simplify or use a vertical layout when needed.
6. For Slidev/fixed-frame SVG embeds, add a fit-to-frame layer that reads the SVG `viewBox`; do not trust browser `naturalWidth`/`naturalHeight` for SVGs. If borders look shaved off, pad the SVG `viewBox` after rendering.
7. Use a cache-busting/new filename if the dev server or browser appears to show an old image.

## Headless Blender source-model and render handoff

When a game/prototype needs original Blender assets but the host has no GUI, use portable Blender headlessly to generate the actual `.blend`, FBX exports, and a lit PNG proof render. Do not equate a Blender Python script with produced models: execute it, inspect the source/export files, render, and visually QA the PNG before sending. For Unity coordinate conversion, studio-preview composition, and archive/checksum handoff, see `references/headless-blender-unity-prop-preview.md`.

## Tool Choice Hints

- Use diagram tools for structure and architecture.
- Use infographic or slide workflows for executive-friendly presentation.
- Use ASCII or code-art workflows for playful or terminal-friendly output.
- Use generative image/video tools for polished visual composition.
- For SVG cleanup and imagery generation/editing, pick the lead with the `model-routing` skill. Use Gemini/Antigravity as the visual QA/description worker that reports what the image actually looks like back to the lead agent.
- For GPT image creation through Hermes, prefer the bundled `image_gen/openai-codex` backend rather than assuming the default FAL route. Enable it with `hermes plugins enable openai-codex`; it becomes available in a **fresh** Hermes session and uses the existing ChatGPT/Codex OAuth path with the Responses image-generation tool. For a multi-asset portfolio job, ask a fresh `hermes chat --provider openai-codex -m gpt-6.1-sol` worker to generate directly into the stable public asset directory, then independently verify file type/dimensions, render the real page, visually QA for generated text/watermarks/incorrect subject matter, and run the production build.
- Use music/audio workflows when the target medium is sound rather than text.
- Use humanizer-style rewrites when the artifact is textual but the voice needs to sound more natural.

## Pitfalls

- Picking a medium that is too heavy for the user's real goal
- Mixing style exploration with final production without a checkpoint
- Forgetting to verify export quality or aspect ratio
- Overcomplicating a quick mockup with full production polish
- Treating generative output as final without checking what it actually looks or sounds like
- Over-sanitizing presentation styling into generic AI-looking grey/blue minimalism; if the user prefers a warm/orange accent, preserve it while fixing actual legibility and clipping issues
- Assuming an SVG is visible because the source rendered; inspect the embedded browser frame for bottom/right clipping, especially when the frame uses pan/zoom with `overflow: hidden`
- Over-sanitizing a visual style after feedback. If the user dislikes one “AI-smelly” cue, remove that specific cue and preserve any parts they liked; do not flatten the whole deck into generic corporate grey. Semyon may prefer warm orange/amber accents when they add character.

From semyonfox/dotfiles, MIT.

More from semyonfox/dotfiles