A blob can be beautiful in isolation and still make the interface worse. Fluid Blob Design began as a way to stop fixing the same almost-right results by hand.

Start with the near miss

When I asked an agent for a calm organic shape, the first result was usually recognizable. It moved. It had color. It looked like a blob. Then the details started to pull the page apart.

The original palette would turn into a generic rainbow. A soft edge would end on the straight side of a canvas. Hovering could make the whole composition jump. A shadow might reveal the rectangle behind the effect. None of these were dramatic failures, which made them easy to repeat.

Each correction sounded local: keep these exact colors, leave transparent space around the contour, let the wrapper extend past the viewport, keep the motion slow. Together they were not shader tweaks. They were design policy.

PaletteThe source colors stay recognizable after they start moving.

A blob does not belong because it is smooth. It belongs because the rest of the page still feels like itself.

Turn taste into rules

The skill starts before the renderer. It asks for a visual contract: the exact source colors, the blob's role, its visible size, how far it may sit off-screen, and whether pointer response, text, or shadow were actually requested.

Anything unspecified stays absent. The default is slow autonomous morphing, no pointer tracking, no hover displacement, no outer shadow, and no text inside the shape. Those choices are intentionally quiet. They leave the page's hierarchy alone.

From there, the skill keeps eight invariants. Colors remain data. The contour moves while the component stays put. Transparent pixels remain transparent. The canvas keeps a safety margin. The local wrapper stays visible while the page clips horizontal overflow. Resolution changes on resize, animation stops on cleanup, and reduced motion gets a still frame plus a faithful fallback.

ContourThe material changes shape without drifting around the layout.

Choose the renderer last

One early mistake was treating WebGPU as proof of quality. It is only the right tool when the visual needs it. A small decoration can use CSS gradients and an animated border radius. SVG is better when the contour needs to follow a directed path. A large hero with fluid internal color mixing earns the heavier renderer.

For that last case, the repository includes a reusable vgpu starter. The React component owns the canvas and palette. The renderer owns device setup, resize, one stable effect, and cleanup. The shader owns the signed-distance contour, material, antialiasing, and transparency. The CSS fallback waits underneath all of it.

The shader leaves clear space around the maximum deformation, uses derivatives to soften the edge, and returns premultiplied color. The runtime caps pixel ratio, compiles before revealing the canvas, and updates only the values that change. These details are not visible when they work. That is the point.

Test the page, not the blob

The correct unit of review is the whole page. A local wrapper needs overflow to stay visible so the organic edge can pass beyond its box. The page shell needs horizontal overflow clipped so that same choice does not create a scrollbar. Mixing those responsibilities is how a soft contour ends in a hard line.

The review checklist looks at narrow mobile, tablet, laptop, and wide desktop widths. It checks the exact moment a contour crosses a viewport edge. It checks that text remains selectable above the canvas. It also checks the unsupported path, because a browser without WebGPU should still see a composed page, not an empty rectangle.

BoundaryThe blob may leave its column. The document never leaves the viewport.

What the skill changed

The public repository is deliberately small. SKILL.md holds the workflow and the defaults. Two references cover the vgpu pattern and the visual review. A starter folder contains the component, renderer, shader, fallback, and type declarations.

That structure made me notice something about working with agents. The code is often the easiest part to save. The more reusable thing is the judgment around it: why one solution belongs, why another is almost right, and which details should never have been invented in the first place.

A skill does not finish the page for me. It narrows the set of repeatable mistakes, which leaves more attention for the part that still needs taste. Maybe that is the useful boundary. The goal is not to automate taste. It is to make good judgment less disposable.

Explore Fluid Blob Design Read the skill