Three.js post-processing - EffectComposer, bloom, DOF, screen effects. Use when adding visual effects, color grading, blur, glow, or creating custom screen-space shaders.
68
82%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that concisely covers specific capabilities (EffectComposer, bloom, DOF, screen effects), uses natural trigger terms users would actually say, and includes an explicit 'Use when' clause. It is well-scoped to a distinct niche within Three.js development, minimizing conflict risk with other potential skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and technologies: EffectComposer, bloom, DOF, screen effects, color grading, blur, glow, and custom screen-space shaders. | 3 / 3 |
Completeness | Clearly answers both 'what' (Three.js post-processing with EffectComposer, bloom, DOF, screen effects) and 'when' (explicit 'Use when' clause covering visual effects, color grading, blur, glow, or custom screen-space shaders). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'bloom', 'DOF', 'blur', 'glow', 'color grading', 'visual effects', 'post-processing', 'screen-space shaders'. These cover common variations of how users describe post-processing needs. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to Three.js post-processing specifically, with distinct triggers like 'EffectComposer', 'bloom', 'DOF', and 'screen-space shaders' that are unlikely to conflict with other skills such as general Three.js scene setup or CSS effects. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a comprehensive, highly actionable reference for Three.js post-processing with excellent executable code examples covering a wide range of effects. Its main weaknesses are length/repetition (bloom appears multiple times, custom shaders are verbose) and the lack of explicit workflow guidance around pass ordering rules, common pitfalls, and debugging strategies. The content would benefit from being split across files given its size.
Suggestions
Deduplicate the bloom setup code — show it once in Quick Start and reference it from other sections rather than repeating the full constructor
Add an explicit 'Pass Ordering Rules' section explaining which passes should come first/last and common ordering mistakes (e.g., gamma correction before vs after bloom)
Consider splitting individual effect recipes into a separate EFFECTS_CATALOG.md to keep the main skill lean and focused on the EffectComposer workflow
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with code-forward examples, but there's significant repetition (e.g., bloom setup appears three times across Quick Start, Common Effects, and Combining Multiple Effects). Some sections like the custom shader examples could be trimmed since Claude knows GLSL basics. The sheer volume (~400 lines) could be tightened. | 2 / 3 |
Actionability | Every section provides fully executable, copy-paste ready code with correct imports, parameter annotations, and runtime update patterns. The examples cover setup, configuration, dynamic updates, and resize handling — all concrete and immediately usable. | 3 / 3 |
Workflow Clarity | The combining multiple effects section implicitly shows ordering (render → bloom → vignette → gamma → AA) with a helpful comment about AA being last, but there's no explicit validation or troubleshooting guidance. For a domain where pass ordering matters and mistakes produce subtle visual bugs, explicit ordering rules and common pitfalls would improve clarity. | 2 / 3 |
Progressive Disclosure | The content is well-organized with clear section headers and a 'See Also' section referencing related skills. However, the document is quite long and monolithic — the extensive custom shader examples and many individual effect sections could be split into referenced files. No bundle files exist to offload content to. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (603 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
b1c6230
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.