Affinity Photoshop Plugin Plan
The Affinity bridge that rides on Photoshop plugin compatibility
- affinity_plugin_plan_json
- manifest_line
- summary_json
Here's the genuinely clever part of the MKRShift Affinity lane: it doesn't build a native Affinity extension at all. Affinity Photo can run Photoshop plugins, so this node plans a handoff that reuses the Photoshop-plugin route instead. Affinity Photoshop Plugin Plan is the node that declares that handoff - which plugin name to use, what kind of plugin it is, where the plugin lives, and how the asset should travel.
It's a plan node, so it does zero file I/O and zero plugin invocation. What it produces is a structured mkrshift_affinity_photoshop_plugin_plan_v1 JSON describing the whole arrangement, which is the kind of documentation that saves you from rediscovering, three projects later, exactly how you hooked the thing up.
How it works
The required inputs are all about describing the plugin-based handoff:
plugin_name- defaults to "MKRShift Photoshop Filter"plugin_kind- filter / automation / import_export, describing what the plugin doesplugin_search_folder/plugin_support_folder- where the plugin (and its support files) live on disk, which Affinity's Photoshop-plugin compatibility layer needs to find itasset_path- the generated image you're handing overhandoff_mode- the three flavors:ps_plugin_filter(run as a filter),ps_plugin_io(plugin import/export), orpsd_roundtrip(exchange via PSD file)
psd_roundtrip is the one to sit up for: it means the plan is built around shipping a PSD through the compatibility route, which is the most robust path for Affinity because PSD is the format both sides understand natively. The optional transport_plan_json attaches a network transport plan if you want the handoff to travel over an endpoint or webhook rather than a local path, and notes is free text for the human who inherits the workflow.
Outputs
affinity_plugin_plan_json- the full plugin handoff planmanifest_line- plugin name, kind, handoff mode, asset path as a comma-joined linesummary_json- whether folders and path are set, transport attached, warnings
Installation
cd ComfyUI/custom_nodes
git clone https://github.com/criskb/MKRShift_Nodes
Restart ComfyUI, or use ComfyUI Manager ("MKRShift Nodes"). No pip dependencies - pure JSON planning.
Common issues
The honest caveats are about the compatibility layer, which is exactly where people get burned. Affinity's Photoshop-plugin support is real but not universal - not every PS plugin works, and the folders it searches for plugins need to point at a location Affinity's scanner actually checks. An empty plugin_search_folder produces a plan with has_search_folder: false and a warning, and nothing downstream will magically find the plugin. Second, the plan is not an execution: nothing runs until a plugin/addon actually reads the plan and acts on it - pair this with the actual addons/affinity/ scaffold or you've written a very detailed wish. And psd_roundtrip assumes a PSD roundtrip is set up on the host side; if your Affinity doc is open in a non-Photoshop persona the path gets fuzzier. For planning a bridge that leans on compatibility, this is the node that makes the trick explicit instead of accidental.
Inputs (8)
| Name | Type | Default | Description |
|---|---|---|---|
| plugin_name | STRING | MKRShift Photoshop Filter | — |
| plugin_kind | COMBO | filter | 3 options: filter, automation, import_export |
| plugin_search_folder | STRING | — | |
| plugin_support_folder | STRING | — | |
| asset_path | STRING | — | |
| handoff_mode | COMBO | ps_plugin_filter | 3 options: ps_plugin_filter, ps_plugin_io, psd_roundtrip |
| transport_plan_jsonopt | STRING | — | |
| notesopt | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| affinity_plugin_plan_json | STRING | — |
| manifest_line | STRING | — |
| summary_json | STRING | — |