| name | oas-render |
| description | Use when mapping OAS plans to a visual output — SVG, Canvas, or WebGL — including scale, axis orientation, and z-order layering. |
OAS Render
When to use
Use this skill when the task is about visualizing an OAS plan rather than authoring its data: picking a mm→px scale, choosing axis orientation, deciding layer order, producing SVG/Canvas/WebGL output. There are no new JSON object types here — this is a rendering contract over existing OAS entities.
Critical rules
- Pick one mm→px scale per render context. A single scale factor applies to every coordinate in the drawing; do not mix scales across entities or layers. Aspect ratio must be preserved.
- OAS Y-axis points up. Most screen renderers (SVG, Canvas) have Y pointing down. Invert Y at the render boundary; do not mutate the source data.
- Use the documented SVG group ids. Group output into
<g id="oas-rooms">, <g id="oas-walls">, <g id="oas-openings">, <g id="oas-circulation">, <g id="oas-labels"> — the spec depends on this naming for selection and theming.
- Walls render in one of two ways. Either as a
<line> with stroke-width = thickness_mm * scale, or as a polygon for full accuracy. Pick one strategy per renderer; don't mix.
- Follow the documented draw order. Room fills → room boundaries → walls → openings → circulation → labels → annotations. The spec lists the exact order — don't reinvent it.
- Renderers should not invent geometry. Doors, windows, labels, dimensions all come from existing OAS entities. Don't synthesize them from inferred adjacency.
Full schema
See docs/render.md for the full rendering rules, including layer ordering, recommended line weights, and target-specific guidance for SVG / Canvas / WebGL.
Related skills
oas-layout — the source data being renderedoas-geometry — for the coordinate conventions that the render transforms
