shoji-shaders

Shoji shader workflow

Find the user's current config first. Public source and detailed map: https://github.com/howdeploy/kisa-stack/tree/main/dotfiles ; read docs/shaders.md and sources.json there or in a local checkout. No private project memory or author-specific path is required by this skill.

Read the reference and define the effect

Separate observed motion, code evidence and assumptions. A still image proves appearance, not trajectory or timing. For Shadertoy, inspect Image and the actual buffer dependencies when available; do not copy an unbounded simulation into a finite transition without lifecycle control. If a requested reference cannot be read, explain that limit instead of inventing what it shows.

Before editing, describe the intended geometry, material, motion and endpoints. Identify where the reveal starts, what remains fixed, whether particles carry source pixels or only sampled colors, and how the effect reverses. Preserve the user's accepted aesthetic; do not substitute a different effect based on keywords.

Select the real pipeline

The compositor does not accept Qt's #version 440 program or Shadertoy mainImage unchanged. Choose compileEffect, compileWindowEffect, compileLayerEffect or compilePopupEffect according to the target. Match the source type: a window replacement reads windowSource(), a backdrop reads backdropSource().

Read src/index.tsx assignments, the closest existing effect module and its callers. Read the fork's docs/docs/configuration/effects.md and shader API types for exact contracts. Paths passed to loadShader resolve from the config package root. Use texture UV for sampling, content-space coordinates for geometry. Framebuffer *_px and logical capture/damage padding are different units, especially on scaled outputs. Explicitly bind uniforms/textures; there is no automatic Shadertoy clock.