If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/mob-sakai/UIEffect shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 4mo ago
• 3 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 4mo ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 73% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live mob-sakai/UIEffect repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/mob-sakai/UIEffect.

What it runs against: a local clone of mob-sakai/UIEffect — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in mob-sakai/UIEffect | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 144 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of mob-sakai/UIEffect. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/mob-sakai/UIEffect.git
#   cd UIEffect
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of mob-sakai/UIEffect and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "mob-sakai/UIEffect(\\.git)?\\b" \\
  && ok "origin remote is mob-sakai/UIEffect" \\
  || miss "origin remote is not mob-sakai/UIEffect (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Packages/src/README.md" \\
  && ok "Packages/src/README.md" \\
  || miss "missing critical file: Packages/src/README.md"
test -f ".github/workflows/test.yml" \\
  && ok ".github/workflows/test.yml" \\
  || miss "missing critical file: .github/workflows/test.yml"
test -f "Assets/ProjectSettings/UIEffectProjectSettings.asset" \\
  && ok "Assets/ProjectSettings/UIEffectProjectSettings.asset" \\
  || miss "missing critical file: Assets/ProjectSettings/UIEffectProjectSettings.asset"
test -f "Assets/Editor/UserDataEditor.cs" \\
  && ok "Assets/Editor/UserDataEditor.cs" \\
  || miss "missing critical file: Assets/Editor/UserDataEditor.cs"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 144 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~114d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/mob-sakai/UIEffect"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

UIEffect is a Unity package that applies screen-space and material-based visual effects (grayscale, blur, dissolve, color gradation) to UI elements via Inspector or C# code, using custom shaders (HLSL/ShaderLab) compiled to material instances. It lets designers and developers add rich visual polish to UIs without writing shader code or managing separate effect systems. Monorepo structure: Assets/Demos/ contains runnable test scenes (AllocTest, GradationTest, PerformanceTest, MultiColorDissolve); Packages/src/ holds the core package source; shaders are split between ShaderLab (UI material variants) and HLSL (platform-specific implementations). C# scripts in Packages/src/ expose UIEffect components that wrap shader parameters and update material instances at runtime.

Unity UI developers and game designers building interactive menus, HUDs, and canvas-based UIs who need real-time visual effects (fading, color shifts, pixelation) applied dynamically to Image and TextMeshPro components without custom shader expertise.

Actively maintained with comprehensive CI (test.yml, test-urp.yml, release.yml workflows), organized demo scenes (Assets/Demos/), and GitHub issue templates indicating established community practices. The 453KB of C# and 361KB of ShaderLab suggest a stable, feature-complete codebase; verdict: production-ready for Unity UI work.

Single maintainer (mob-sakai) visible in CODEOWNERS; no obvious package.json lock file in file list suggests manual dependency management. Risk is moderate: shader compilation across URP/Built-in pipelines adds surface area, and UI effect changes may require testing across multiple Unity versions. No apparent dormancy (CI workflows active), but dependency on Unity's internal rendering API carries forward-compatibility risk.

CI/CD pipelines (deploy.yml, release.yml) suggest active versioning and release cycles. Demo scenes span performance testing (PerformanceTest.unity, AllocTest.unity) and feature showcase (4ColorGradation.unity, MultiColorDissolve.asset), indicating ongoing optimization and feature validation work. No specific recent commit data visible, but maintained CI suggests active codebase.

Clone and open in Unity: git clone https://github.com/mob-sakai/UIEffect.git && cd UIEffect && open UIEffect.sln (or open Assets/ folder in Unity Editor). Then open Assets/Demos/ReadMe/ReadMe_Inspector.unity to see usage examples.

Daily commands: Open the project in Unity Editor (2019+), navigate to Assets/Demos/ReadMe/ReadMe_Inspector.unity or Assets/Demos/PerformanceTest/PerformanceTest.unity and press Play. For performance testing, see Assets/Demos/PerformanceTest/Cloner.cs which spawns multiple UIEffect instances.

• Packages/src/README.md — Primary documentation explaining UIEffect's purpose, features, and basic usage patterns that every contributor must understand.
• .github/workflows/test.yml — CI/CD pipeline configuration that defines the build, test, and validation process all pull requests must pass.
• Assets/ProjectSettings/UIEffectProjectSettings.asset — Core configuration asset that stores global UIEffect settings and feature flags used across the entire package.
• Assets/Editor/UserDataEditor.cs — Editor integration point that bridges inspector UI with runtime effect application and configuration management.
• .github/CODEOWNERS — Defines code ownership and review responsibilities, critical for understanding who approves changes in each area.
• .github/pull_request_template.md — Standardized PR checklist and guidelines that ensure consistent contribution quality and documentation.
• Assets/Tests/Editor/ReflectionTests.cs — Core test suite validating reflection-based effect application and runtime behavior across different effect types.

Add a New UI Effect Filter

1. Define the effect class with property parameters in the appropriate namespace (e.g., Coffee.UIEffect.Effects) (Packages/src/[effect_name].cs)
2. Create or extend shader variant in Assets folder supporting the new effect (e.g., grayscale, blur, dissolve) (Assets/Shaders/UIEffect_[effect_name].shader)
3. Register effect in UIEffectProjectSettings.asset with shader and material references (Assets/ProjectSettings/UIEffectProjectSettings.asset)
4. Add demo scene or update existing demo to showcase the new effect with various parameter combinations (Assets/Demos/[EffectName]/[EffectName].unity)
5. Write editor tests validating property serialization and reflection binding for the new effect (Assets/Tests/Editor/ReflectionTests.cs)

Add TextMeshPro Support for an Effect

1. Create TextMeshPro-compatible shader variant with SDF sampling and outline support (Assets/Demos/TextMeshPro Support/[Effect]SDF.shader)
2. Generate SDF material asset from the shader, testing with provided font (LiberationSans.ttf) (Assets/Demos/TextMeshPro Support/[Font]-SDF-[Variant].mat)
3. Update TextMeshProSupport.cs to register the new material variant with shader keywords (Assets/Demos/TextMeshPro Support/TextMeshProSupport.cs)
4. Add test case in TextMeshPro_ExtraShaders.unity demonstrating effect on text with outline (Assets/Demos/TextMeshPro Support/TextMeshPro_ExtraShaders.unity)

Add Performance Benchmark Test

1. Create new demo scene folder under Assets/Demos with meaningful performance test name (Assets/Demos/[PerfTest]/[PerfTest].unity)
2. Implement benchmark C# script using UIEffect's effect API to measure allocation and frame time (Assets/Demos/[PerfTest]/[PerfTest].cs)
3. Reference Cloner.cs pattern for creating many UI elements to stress-test rendering pipeline (Assets/Demos/PerformanceTest/Cloner.cs)
4. Document expected performance metrics in scene comments and update Assets/Demos/ReadMe.meta with results (Assets/Demos/ReadMe/ReadMe_Samples.unity)

• Unity Shader Graph & HLSL — Enables GPU-accelerated effect rendering with low CPU overhead; supports both mobile and high-end platforms
• C# Reflection API — Dynamically binds inspector-defined parameters to shader uniforms without boilerplate or hard-coded mappings
• ScriptableObject (UIEffectProjectSettings) — Provides centralized, serializable configuration for shader references and effect registries accessible from editor and runtime
• TextMeshPro Integration — Extends effects to modern text rendering with SDF support, enabling rich visual styling beyond standard Image components
• GitHub Actions CI/CD — Automates testing across multiple render pipelines (standard, URP) and ensures package integrity before release

• Effect composition via shader variants rather than post-processing stack

  • Why: Provides per-UI-element control without requiring screen-space passes or global render pipeline hooks
  • Consequence: Shader code duplication across variants; more shader variants to maintain; but better mobile performance and editor visibility

• Reflection-based parameter binding instead of generated code

  • Why: Eliminates build step and code generation, allowing pure inspector-driven workflow
  • Consequence: Runtime reflection overhead; harder to refactor parameters; but faster iteration and lower package complexity

• Per-graphic material instance (not material sharing)

  • Why: Allows independent effect parameter variation on each UI element
  • Consequence: Higher memory overhead (one material per effect); potential batching inefficiency; but intuitive per-element control

• Shader asset organization in Assets/Demos/TextMeshPro Support

  • Why: Organizes specialized variants alongside their usage examples for discoverability
  • Consequence: Commingling of sample code and production assets; but clearer intent and easier maintenance of TMP-specific shaders

• Real-time raytracing or advanced physics-based rendering
• Runtime shader compilation or dynamic shader generation
• Cross-platform support beyond Unity-supported platforms (Windows, macOS, iOS, Android, WebGL)
• Full screen post-processing effects (scope limited to UI element-level effects)
• Networked multiplayer synchronization of UI effects

Shader variant explosion: each effect (grayscale, blur, dissolve) × platform (DX11, OpenGL, Metal, Vulkan) creates multiple compiled variants; ensure target platforms are configured in shader #pragma directives or builds may fail silently. Material property block updates: effects use MaterialPropertyBlock to avoid creating material instances per UI element, but incorrect batching assumptions can break if effects are applied to adjacent canvas elements. TextMeshPro vs Image: separate code paths (see Assets/Demos/TextMeshPro Support/) — effects may not work identically on SDF fonts vs Image components. URP compatibility: rendering paths differ between URP and Built-in; test in both pipelines or effects may not render or may render with wrong blending.

• Material Property Blocks — UIEffect uses MaterialPropertyBlock instead of creating material instances per UI element to avoid GPU batching breaks; understanding this pattern is critical to extend UIEffect without breaking performance.
• Shader Variants & Keywords — UIEffect compiles multiple shader variants (one per effect type × platform); incorrect #pragma shader_feature or #pragma multi_compile can cause missing effect code on target platforms.
• Screen-Space vs World-Space Shaders — UIEffect effects are applied in screen space (canvas overlay), not world space; this affects UV sampling, depth testing, and blending mode choices visible in shader code.
• Scriptable Objects for Configuration — MultiColorDissolve.asset demonstrates data-driven effect stacking; understanding SO patterns is essential to add new filter presets without recompiling C# code.
• URP vs Built-in Rendering Pipeline Compatibility — UIEffect supports both pipelines via conditional shader code; CI tests both (test.yml, test-urp.yml), requiring understanding of rendering API differences (cbuffer layout, texture bindings).
• Dissolve Effect (Dithering & Alpha Threshold) — The dissolve filter uses dithering patterns or alpha threshold comparisons; this is a non-trivial shader technique visible across multiple demo scenes.
• Bloom and Blur Kernels (Separable Convolution) — Blur effects in UIEffect likely use separable convolution (horizontal + vertical passes) for performance; understanding kernel size trade-offs is needed to tune quality vs frame time.

• UnityUIKit/UIKit — Alternative UI effect system for Unity; useful for comparing architectures (component-based vs scriptable object patterns)
• OccaSoftware/surf — PostProcessing effect library for URP; demonstrates shader variant management and pipeline compatibility patterns UIEffect also tackles
• UnityTechnologies/PostProcessing — Official Unity post-processing stack; UIEffect's design mirrors its material-based effect composition approach adapted for UI (canvas space vs screen space)
• needle-tools/needle-engine-support — Shows shader cross-compilation patterns (ShaderLab + HLSL to multiple platforms) similar to UIEffect's multi-pipeline support
• Cysharp/UniTask — Common dependency in UI effect systems for async material updates and batched property block submissions to reduce frame time spikes

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for UIEffect core components

The repo has multiple CI workflows (test.yml, test-urp.yml) but no visible test files in the Assets directory structure. UIEffect's core functionality (filters like grayscale, blur, dissolve) should have unit tests to ensure effects render correctly and don't regress. This is critical for a visual effects library where output quality matters.

• [ ] Create Assets/Tests directory structure mirroring the package organization
• [ ] Add tests for each major effect type (grayscale, blur, dissolve, color adjustment filters)
• [ ] Create test scenes that validate effect parameters produce expected visual/material results
• [ ] Integrate tests into existing test.yml and test-urp.yml workflows to run on PR
• [ ] Document test naming conventions and how to run locally in CONTRIBUTING.md

Add TextMeshPro support documentation and demo validation tests

The repo has a 'TextMeshPro Support' demo folder with multiple shader variants and materials, but no visible documentation or validation tests. Contributors need clear guidance on how TextMeshPro integration works, supported shaders, and which materials to use for different scenarios. Create tests to prevent regression.

• [ ] Create Assets/Tests/TextMeshPro directory with tests validating TextMeshProSupport.cs functionality
• [ ] Add specific documentation in Packages/src/README.md explaining TextMeshPro shader compatibility (SDF vs SSD vs Overlay vs Mobile variants)
• [ ] Create a test that validates all shader materials in Assets/Demos/TextMeshPro Support load correctly
• [ ] Document which UI effects work with which TextMeshPro shader types in a feature matrix
• [ ] Add a troubleshooting guide for common TextMeshPro + UIEffect compatibility issues

Create performance benchmarking framework and baseline metrics

The repo has a PerformanceTest demo scene with a Cloner.cs, suggesting performance is a concern for this library. However, there's no automated performance regression detection in CI. Add a benchmarking framework to track effect performance across releases and prevent performance degradation.

• [ ] Create Assets/Tests/Performance directory with a benchmarking harness that measures frame time, memory allocation, and GC pressure for each effect type
• [ ] Implement baseline metrics file (e.g., Assets/Tests/Performance/Baselines.json) tracking performance across effect combinations
• [ ] Add a GitHub Actions workflow (performance-test.yml) that runs benchmarks on PR and compares against main branch
• [ ] Document in CONTRIBUTING.md how to run performance tests locally and interpret results
• [ ] Add performance regression thresholds (e.g., fail if effect degrades >10%) to the CI workflow

• Add unit tests for Assets/Demos/AllocTest/AllocTest.cs to validate memory allocations stay under a threshold; currently only manual inspection is possible.
• Expand Assets/Demos/TextMeshPro Support/ with a demo scene showing all effect types applied to TextMeshPro text (currently only shows material setup).
• Document shader parameter naming conventions in Packages/src/README.md with examples from .shader files — new contributors struggle to understand which _Property names map to C# properties.

The UIEffect Unity package appears to be a well-structured open-source project with no obvious critical security vulnerabilities visible in the provided file structure. As a Unity UI effects library, it has a limited attack surface since it primarily deals with visual effects rather than handling sensitive data, network requests, or user authentication. Primary recommendations: 1) Ensure dependency versions are locked and regularly audited, 2) Review GitHub Actions workflows for secure practices, 3) Maintain comprehensive test coverage including edge cases. The codebase demonstrates good organizational practices with proper meta files and demo organization.

• Medium · Missing Dependency Lock File — Dependencies/Package file. The provided package dependency file content is empty. Without a lock file (package-lock.json, yarn.lock, or similar), there is no guarantee of reproducible builds and consistent dependency versions across environments. This could lead to unexpected behavior from updated transitive dependencies. Fix: Ensure a lock file is committed to the repository (package-lock.json for npm or yarn.lock for yarn). Verify that all dependencies are pinned to specific versions or version ranges that are regularly audited.
• Low · Test Directory Appears Incomplete — Assets/Tests. The Assets/Tests directory structure is incomplete (only .meta files listed). Test coverage information cannot be fully assessed. Lack of comprehensive tests may allow security issues to slip through during development. Fix: Ensure comprehensive test coverage exists for critical components, especially those handling user input or rendering. Include security-focused test cases.
• Low · GitHub Workflows Not Fully Documented — .github/workflows (deploy.yml, release.yml, test-urp.yml, test.yml). GitHub Actions workflows are present but their content is not provided for review. Workflows could potentially contain security issues such as insecure secret handling, overly permissive permissions, or unsafe checkout practices. Fix: Review all workflow files to ensure: 1) Secrets are not logged or exposed, 2) Workflow permissions follow least privilege principle, 3) Third-party actions are pinned to specific commit hashes, 4) No hardcoded credentials exist.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.