Build and verify procedural visuals with ak:shader

Use ak:shader to turn an effect brief into GLSL fragment-shader code and integration guidance. Its bundled references cover coordinates, shaping functions, color, signed distance fields, tiling, transformations, noise, fBm, Voronoi patterns, and procedural textures. The project runtime still determines whether the result compiles, renders, and performs acceptably.

Choose ak:shader for procedural pixel effects

Use ak:shader when

• You need a procedural background, texture, transition, mask, generative visual, or custom WebGL or Three.js material effect.
• You want shapes built from distance fields or patterns built from tiled and transformed coordinates.
• You need noise, fBm, cellular, Voronoi, cloud, marble, wood, terrain, fire, smoke, water, or related shader techniques.
• You already know the host graphics API and can render the result for review.

Choose another workflow when

• A CSS gradient, SVG, canvas drawing, image asset, or existing material can meet the outcome with less runtime complexity.
• You need an entire Three.js scene or interaction system. Use ak:threejs and bring this Skill in for the fragment effect.
• You need a standalone bitmap rather than code. Use an approved image-generation or media workflow.
• You cannot run the target renderer. Ask for an implementation sketch and mark visual and performance verification as blocked.

Prepare the target graphics contract

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the active runtime and scope.
• Identify the exact shader language and version, host API, framework, material interface, vertex shader, precision requirements, output color convention, and supported devices.
• Provide the uniforms and coordinate conventions already used by the project. The Skill's examples commonly use u_time, u_resolution, u_mouse, gl_FragCoord, and gl_FragColor; those names and APIs are not universal.
• State the visual target, motion behavior, color constraints, performance budget, fallback behavior, and files that may be edited.
• Make the project's shader compiler, browser, graphics test harness, or preview route available for verification.

See Runtime adapters for component-level differences across targets.

Run the Skill

Pass the effect and host contract in natural language. The Skill declares an effect-or-pattern argument, not flags or a fixed output path.

/ak:shader "Create a WebGL 1 fragment shader for a subtle animated marble background using the project's u_time and u_resolution uniforms. Keep motion slow, preserve text contrast, add a reduced-motion static path, and verify it in the existing preview without adding dependencies."

/ak:shader "Create a WebGL 1 fragment shader for a subtle animated marble background using the project's u_time and u_resolution uniforms. Keep motion slow, preserve text contrast, add a reduced-motion static path, and verify it in the existing preview without adding dependencies."

$ak:shader "Create a WebGL 1 fragment shader for a subtle animated marble background using the project's u_time and u_resolution uniforms. Keep motion slow, preserve text contrast, add a reduced-motion static path, and verify it in the existing preview without adding dependencies."

For Three.js, name the existing material, geometry, varying values, renderer version, color-space handling, and whether the Skill may change the vertex shader or JavaScript integration.

Describe the effect precisely

A useful brief gives the Skill:

• Visual outcome: Name the material, motion, density, scale, palette, and focal behavior you expect.
• Host contract: Name GLSL or GLSL ES version, WebGL generation, uniform and varying names, texture inputs, and output convention.
• Performance boundary: State target devices, resolution, frame target, and acceptable octave or loop complexity.
• Access boundary: State whether online editors, external shader libraries, package changes, browser automation, or asset downloads are allowed.
• Acceptance evidence: Define the scenes, viewports, timestamps, static states, screenshots, compile checks, and performance observations required.

Observe an evidence-led shader workflow

1. The run inspects the host. It reads the existing shader, material setup, uniforms, coordinate transforms, and target graphics version.
2. The run chooses a minimal technique. It selects SDFs, gradients, tiling, noise, cellular distance, fBm, or domain warping according to the requested effect rather than combining every technique.
3. The run writes the shader and integration. It keeps inputs and outputs aligned with the project and isolates new uniforms or helpers.
4. The run compiles in the real target. It reports shader compile and link errors literally and corrects version, precision, type, or interface issues.
5. The run renders representative states. It checks different resolutions, aspect ratios, times, mouse values, device classes, and reduced-motion or fallback states where relevant.
6. The run measures and reviews. It records visual evidence, frame or GPU observations available in the project, accessibility impact, and remaining browser or device gaps.

Keep generated visuals and runtime effects safe

• Do not copy a third-party shader or library function without checking its license and attribution requirements.
• Ask before using online editors or external libraries; they can send source code over the network or add dependencies.
• Preserve a static or lower-cost fallback where motion preferences, device capability, or rendering failure requires one.
• Avoid exposing sensitive texture inputs, screenshots, or proprietary shader source through public playgrounds.
• Treat package installation, asset generation, publication, deployment, and production feature flags as separate authority boundaries.

Verify code and visual evidence

A complete implementation should provide:

• The final fragment shader and any approved host integration changes.
• The exact shader version, uniforms, varyings, textures, precision, and output assumptions.
• Fresh compiler and linker results from the actual target.
• Screenshots or recordings at representative sizes and states, including the fallback or reduced-motion behavior when required.
• Performance observations on named devices or environments, not a generic claim that GPU execution is fast.
• Contrast, readability, motion-safety, browser-support, and known artifact findings, plus exact files changed and checks skipped.

Reference snippets are ingredients, not a complete program. Functions such as noise, fbm, and constants such as PI must be defined or imported in the final compilation unit when a selected recipe depends on them.

Troubleshoot or continue

Continue with Frontend design for the surrounding surface, or review Projects, artifacts, and checkpoints.

Know the current limits

• The Skill is a GLSL reference library; it bundles no compiler, renderer, browser, GPU profiler, executable, or test suite.
• Its built-in API reference targets GLSL ES 1.0 and WebGL-style functions. Other targets require deliberate syntax and interface adaptation.
• A screenshot cannot prove stable performance or correctness across GPUs, drivers, browsers, color spaces, and accessibility settings.
• Stable and beta contain identical ak:shader content for this release pair.