canvas-design-codex
Skill27 starsChanged 3 months agoMITView on GitHub
Use when Codex needs to build, revise, debug, or verify canvas, SVG, WebGL, Three.js, custom charting, diagram, game, generative visual, or pixel-based browser artwork where screenshot, pixel, animation, or image bounds evidence matters.
In this repository16 other files it gives its agents.
- adversarial-plan-review-codexSkill
- code-intelligenceSkill
- code-mapper-skillSkill
- deep-planning-codexSkill
- document-handoffSkill
- docx-winSkill
- frontend-design-codexSkill
- grill-me-codexSkill
- grill-with-docs-codexSkill
- handoff-codexSkill
- pptx-winSkill
- repo-map-codexSkill
- ultraplan-codexSkill
- verification-plan-codexSkill
- web-artifacts-builder-codexSkill
- xlsx-winSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use this skill for visual work where the primary output is drawn rather than ordinary DOM layout.
- Distinctive: line 21
Use existing libraries for established mechanics or 3D rendering instead of hand-rolling complex engines.
- Distinctive: line 23
Add loading, error, empty, and reduced-motion behavior when relevant.
- Very specific: line 29
Use .shared\visual-runtime for visual evidence:
- Distinctive: line 36
No Office COM is required.
- Distinctive: line 45
run visual lint for surrounding controls and labels.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Canvas Design Codex
Overview
Use this skill for visual work where the primary output is drawn rather than ordinary DOM layout. Prefer proven rendering libraries for established rules, physics, charting, or 3D behavior.
Design Upskill Contribution
This skill teaches Codex to verify drawn visuals through rendered pixels. It improves no-template design by requiring screenshot evidence, image bounds, animation sanity checks, and visual lint around the surrounding page.
It matters because canvas and SVG work can look correct in code while rendering blank, cropped, blurry, or misframed. Codex must prove that the pixels exist and communicate the intended design.
Workflow
- Identify the rendering mode: canvas, SVG, WebGL, Three.js, charting library, or mixed DOM and drawing.
- Use existing libraries for established mechanics or 3D rendering instead of hand-rolling complex engines.
- Set stable canvas or SVG dimensions with responsive constraints.
- Add loading, error, empty, and reduced-motion behavior when relevant.
- Capture screenshots and inspect image bounds after meaningful changes.
- For animated or interactive work, verify the scene is nonblank and correctly framed after a short wait.
Shared Visual Runtime
Use .shared\visual-runtime for visual evidence:
capture_page.mjswith--wait-msfor animated or async drawing.image_bounds.pyto confirm screenshot width, height, aspect ratio, and bytes.make_contact_sheet.pyto compare states or viewports.visual_lint.mjsfor surrounding DOM text, contrast, and console findings.
No Office COM is required. If drawn output is exported into an Office file later, keep the pixel evidence here and move only the Office embedding to the Office skill.
Verification
Before completion:
- capture a screenshot after the canvas or visual has rendered;
- confirm image bounds and nonzero file size;
- inspect for crop, blur, blank canvas, offscreen objects, and overlapping UI;
- run visual lint for surrounding controls and labels;
- preserve screenshot or contact sheet evidence.
Common Mistakes
- Verifying source code but not pixels.
- Allowing hover text, loading labels, or controls to resize the canvas.
- Using viewport-scaled type that breaks at narrow sizes.
- Forgetting to wait for async drawing before screenshot capture.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

