Open a minimal skill
Enter the private-server builder tools and locate Skill Builder through the current Moveset, Awakening, Special, or Character block flow. Labels move as the system evolves, so follow the live menu hierarchy. Begin with a new test skill rather than editing your only working moveset.
Set a clear name and purpose: close-range starter, movement tool, extender, defense, or finisher. A skill designed for every purpose is difficult to balance and difficult for opponents to read.
Build the first timeline
Community captures show timeline building blocks such as animation, waits, hitboxes, sounds, velocity, properties, and conditions. Start with animation, a short intentional wait, one hitbox, visible or audible feedback, and recovery. Preview after every addition.
The order should match what a player sees. Telegraph begins, hitbox becomes active, contact feedback occurs, then recovery returns control. If damage happens before the visible action reaches the target, revise the timing. If the effect continues long after the active window, opponents cannot learn the move.
Keep the first version plain. Extra effects can hide whether the underlying hit and movement work.
Shape a fair hitbox
Place the hitbox where the animation communicates force. Test close, edge, vertical, and rear positions. Decide whether the skill should turn with the player, lock direction, or follow movement, then verify the live property that controls it.
An oversized invisible volume may make testing easy but creates dishonest play. Use a temporary debug view only if the in-game tool provides one, then make the final attack legible through animation and effects.
Test block, miss, interruption, ragdoll, walls, and multiple targets. Record exactly which state produced an unexpected hit.
Conditions and properties
Add conditions only after the basic timeline is stable. A condition might depend on hit success, player state, awakening, charge, direction, or another creator-defined branch. Build one branch, test both true and false outcomes, then add the next.
Properties such as movement, stun, knockback, cooldown, or resource behavior should support the skill’s role. Change one value at a time. If you increase reach, do not simultaneously increase speed and reduce recovery; you will not know which change broke counterplay.
Document unusual rules in the Workshop description so players understand the intended behavior.
Feedback and performance
Use sound and visual effects to communicate startup, active contact, and finish. More effects are not automatically clearer. Avoid full-screen flashes, persistent particles, or overlapping sounds that obscure other players’ decisions.
Test on a modest device and in a group. Repeated events can multiply load when several players use the skill. Remove hidden or redundant effects. Check that interruption cleans up attached objects, sounds, and hitboxes.
Respect Roblox asset and audio rules. Do not import content you lack permission to use.
Test matrix
Run the skill on hit, miss, block, interruption, death/reset, wall, slope, airborne target, multiple targets, high latency, and repeated use. Also test the skill after loading the saved item into a fresh server. A timeline that works only in the authoring preview is incomplete.
Ask whether an opponent can understand the threat, respond before a strong effect, and punish a careless miss. Ask whether the user knows why the skill failed. Fix clarity before adding damage.
Version each meaningful change and keep the last stable copy.
Combine it into a kit
Once the skill passes alone, test it with every other move in the custom moveset. Look for unintended loops, overlapping cooldown coverage, unavoidable stun, or movement that bypasses map bounds. The skill may need a different recovery inside a complete kit.
Use the custom movesets guide to assign complementary roles and the Workshop guide for safe sharing. After any major Jujutsu Shenanigans builder update, reload a duplicate and repeat the test matrix before publishing over the stable version.
Debug one failure at a time
When a preview fails, duplicate the skill and remove events after the first unexpected point. Confirm whether the animation starts, wait completes, hitbox appears, condition chooses the expected branch, and cleanup runs. Add later events back one by one. This is faster than changing several properties until the bug seems to disappear.
Record the smallest sequence that reproduces the problem, the expected result, live result, server date, and whether reload changes it. If the failure happens only with a wall, interruption, or multiple targets, preserve that condition in the report. Keep the working original untouched while debugging. A minimal reproduction helps both your future self and any creator-tool maintainer understand the actual fault.