Last spring I was setting up a new dodging-and-burning action for a cosmetics client, one of those workflows where consistency really matters because the same action runs across 300 product shots in a single batch. The action broke on the third image. Not a layer issue, not a color mode conflict. The brush I had defined for the Healing Brush step had a texture applied that referenced a pattern the client’s machine didn’t have loaded. Three hours of debugging traced back to one checkbox I had ignored during brush creation.

That’s the thing about brushes inside actions: they carry more hidden state than most people realize, and if you don’t build them deliberately, they will fail you at scale.

Why Brush Presets Are Not Just Saved Settings

When you save a brush preset in Photoshop, you are saving the tip shape and a specific set of dynamics, but the tool state at the time the action records is what actually gets written into the action step. Those are two different things. The preset is a reference. The action captures the actual parameters in memory at the moment you hit record.

This means if your Hardness is at 73%, your Spacing at 18%, and your Scatter is enabled when you record, those values go into the action even if the preset you think you’re using says something different. Run that action on another machine where someone has overridden the preset, and the action uses the recorded values, not the current preset. This is actually useful once you understand it, because it means you can bake specific brush behavior directly into an action step without relying on the user having the right preset installed.

The problem comes with texture and pattern references. Those are pulled from the loaded library at runtime, not embedded in the action. A brush with a Canvas texture applied is a brush with a broken dependency waiting to happen.

The Brush Settings That Actually Matter for Repeatability

For any brush that will live inside an action or be shared across machines, I work from a short list of parameters I trust and a longer list I avoid.

Trust these: Size (set it explicitly, don’t leave it at whatever you last used), Hardness (0-100, no ambiguity), Spacing (I almost always set this between 1% and 25% depending on the tool), and the basic Shape Dynamics tied to pen pressure if the workflow uses a tablet. Roundness, Angle, and Flip settings are fine. These are all self-contained values.

Avoid these inside shared or action-embedded brushes: Texture (pattern dependency, as above), Dual Brush (references a second tip that may not exist on another machine), and any Scattering or Color Dynamics tied to Fade steps, because Fade counts strokes from the beginning of a session and will behave differently depending on workflow order.

For a healing or cloning brush in a product retouching action, my standard setup is: Hardness 0%, Spacing 1%, Size set explicitly in the action step, Opacity and Flow recorded at 100% with the action managing those values through layer opacity instead. The brush itself stays simple. The action does the nuanced work.

Building the Tip Shape from Scratch vs. Sampling

Photoshop lets you define a brush tip from any selection, which is where custom brushes get genuinely interesting. For texture overlays, light leak effects, or edge-darkening tools, I create my tip shapes in a 2500x2500 pixel canvas at 300 DPI, working in grayscale. Black areas become full bristle, white areas are transparent, and gray values control the density in between. I export the tip at no smaller than 1000px on the longest edge because Photoshop allows you to scale a tip down but interpolation going up looks terrible.

When I define the brush (Edit > Define Brush Preset), I immediately open the Brush Settings panel and set my Spacing to 25% or lower, save a second preset with a descriptive name that includes the size and intent, and then export that preset as a .abr file to my shared drive. My brush library folder currently has 34 .abr files, each named by project type and year, stored on two separate drives. Yes, two. I have backup drives for my backup drives, and I am not sorry about it.

The One Test I Run Before Any Brush Goes Into Production

Before a brush earns a spot in a delivered action set, I test it in a specific way. I record a ten-step action that does nothing except apply the brush, flatten, undo, and apply it again from a fresh history state. I run that action on five different file types: an 8-bit RGB JPEG, a 16-bit TIFF, an sRGB file, a ProPhoto RGB file, and a CMYK document. If the brush behaves consistently across all five, it ships. If it breaks on CMYK (which texture brushes often do because the color engine handles pattern fills differently), I strip the texture and rebuild.

This test has caught more problems than I can count. It costs about twelve minutes per brush and has saved me from shipping broken tools to clients who are running on tight deadlines and do not want a debugging conversation.

One Mistake I Made Early That Shaped Everything After

When I built my first serious action set, around age 26, I treated brushes as an afterthought. The actions were solid, the layer logic was clean, and the brushes were just whatever I had been using that week. Within a month I was getting support emails from other people in my studio saying the retouching steps weren’t working. Every single problem traced back to brush state or brush dependencies.

I rebuilt the whole set with deliberately constructed, dependency-free brushes, documented every setting in a plain text file sitting next to the .abr export, and never had the same category of problem again. That documentation habit is now a non-negotiable part of how I deliver any tool to a client.

The brush is not decoration. It is part of the tool’s architecture, and if you treat it like one, it will hold up the same way the rest of your workflow does.