TE MAN keeps every node file flat in the repository root

Forty node files sit directly in the repository root

The top level of the repository is the plugin. Every model-specific node is a file sitting next to the readme, named after what it calls:

GPT_Image_2_Generator.pyd
Gemini_Imagen_Generator.pyd
Grok_Image_Generator.pyd
Jimeng_Video_Generator.pyd
Sora_2_Video_Generator.pyd
TE_Bernini_R_Generator.pyd
TE_HappyH_Video.pyd
TE_VEO_Video.pyd

Alongside them are the feature nodes, with names like TE_MAN_Chat, TE_3D_Director, TE_Batch_Tools, TE_Audio_Save_Load, TE_Image_Comparer, TE_Video_Comparer, TE_Asset_Library and TE_H3_Prompt_Enhancer.

Two conventions run through that list and they do not meet. Node files use an upper-case prefix, while helpers use lower case with underscores: api_client, config_manager, image_codec, logger, task_runner, save_image_with_output_core, grid_split_core. The same feature therefore appears under two naming schemes, as with Save_Image_With_Output and save_image_with_output_core.

Two entries in the listing are worth stopping on. There is a grid_split_routes file in Python form and a grid_split_routes file in the node form used by everything else, with the same base name. And there is a file whose name begins with four z characters, a Grok autoscale patch, which is a convention for forcing a module to load late, since a name prefixed that way sorts after everything else.

There is also a test file for one image compression node sitting beside the node itself, and exactly one packaged subdirectory for the whole repository, which is where one model's backend lives. Everything else is loose files.

Configuration is an ini file driven by a module

Configuration runs through two files at the root, an ini file and a Python module that manages it. A dedicated config manager as a node-adjacent module is an unusual choice next to a plain ini file, and it implies the settings are edited by the plugin rather than by hand as often as by the user.

The other root-level modules describe the plumbing. A logger, an API client, a task runner, an image codec and the core for the save-with-output node. That is a small and sensible set for a plugin that has to call several hosted services, encode images and queue work.

One Python file is named for safety, in the sense of being a wrapper around a Grok call rather than the call itself, and one is named for a patch. Both sit at the root rather than in a package, which is consistent with a plugin ecosystem where ComfyUI discovers nodes by scanning directories and a node that is present but broken takes down the whole load rather than one feature.

The asset and skill directories are the two structured parts. Assets hold the library that nodes read from and write to, and skills hold the creation flows the chat surface can select. The web directory holds the server side routes, which is where the chat interface and the comparison nodes get their endpoints.

There is a licence file at the root while the licence recorded for the repository is unresolved, so read the file rather than the metadata if the terms matter to you.

The header says v3.7 while the changelog is three patches ahead

The title of the file names version 3.7. The change list under it starts at 3.7.3, then 3.7.2, then 3.7. So the version a reader takes away from the title is behind the one the newest entry describes. There are no GitHub releases to resolve it, since the repository has none, and the last push to the branch is dated 2026-09-26.

The newest entries are mostly repairs, and they describe the kind of defect that shows up when a node grows. Version 3.7.3 fixes nodes being stretched to an unbounded length, buttons misaligned, covered or unclickable, adapts to a redesigned node interface while still advising against enabling it, and fixes a prompt field that stayed narrowed after the properties panel was closed. Those are the symptoms of a node whose layout depends on its content, which is worth knowing before you build a workflow around one.

The runtime requirement is stated bluntly: a new feature is used and only Python 3.12 and 3.13 are supported. The suggested environment is not something the repository provides. The file points to a prebuilt ComfyUI bundle hosted on a third party file sharing service, described with a torch version, a CUDA version and Python 3.13, and a separate link for prompt enhancement model downloads with an instruction to place them in the text encoders folder.

So neither the Python environment nor the models are pinned by anything version controlled here. That is a distribution choice rather than an oversight, and it is the main thing to weigh before depending on the plugin.

Three prompt enhancement engines behind one node

The newest significant node targets one specific image model and offers three ways to improve a prompt, and the distinction between them is worth understanding.

The first runs the official prompt enhancer model locally, with separate choices for text to image and image to image. The second runs a local vision model with its companion projector file, and it exists because it can look at images. The third goes to an online model, configured with a base address, a key and a model name, which is the only one of the three that sends your prompt and images off the machine.

The official prompt engineering rules are built into the node rather than loaded from a template file, which means the behaviour travels with the code instead of depending on a file the user forgot to download.

Image to image mode accepts up to eight reference images, and the readme states what the model does with them: it identifies image content, relations between subjects, the scene and visual features, then folds that into the final prompt. That is the direct answer to the usual complaint that describing an image in words loses what the image already said.

Two output behaviours are specified and both are about restraint. The output language can be Chinese or English, and text that the user explicitly asked to appear in the frame is preserved, with no titles, slogans, logos or other readable text added on its own. Generation settings exposed are a maximum token count, a context length, a seed, and a switch to unload the model automatically after generation.

Five prompt modes are kept apart on purpose

The video prompt enhancer is organised around a distinction that most tools blur. It supports five task modes: full reference, text to video, first frame image to video, first and last frame video, and last frame image to video. Each mode has its own rules, and the stated reason is to stop the modes contaminating each other.

That is a real problem in prompt engineering rather than a hypothetical one. A rule that helps a text to video prompt, such as describing a subject from scratch, actively hurts a first frame prompt, where the frame already defines the subject and the rule produces a contradiction. Keeping the rule sets separate is the only way to avoid that, and the readme names the failure mode explicitly.

The output shapes differ too. Full reference mode emits six named fields, covering subject definitions, a summary, retention analysis, a detailed description, an overall soundscape and non-diegetic music. The other four modes emit three core fields instead.

Reference material is addressed by typed markers rather than prose. Reference images are inserted in order as picture markers, videos as video markers, audio as audio markers, and in the first and last frame case the first frame maps to the first picture marker and the last frame to the second. The text node that feeds these prompts accepts an at sign to insert the markers for whatever reference material is already connected, which is how a prompt stays consistent with the graph.

The readme also recommends against one of its own skills for this job, pointing at the enhancer node as the more convenient route for building these prompts.

Batch execution can be limited to the branch you connected

Batch nodes are the part of this plugin with a real engineering idea in it. A batch prompt node manages many prompts in one node with a card interface, supporting adding, editing, deleting, reordering and single selection, importing a text file split on line breaks, and importing a whole folder of text files so each file becomes one prompt. A matching batch image node does the same for images with a card layout, importing a single file or a folder.

Execution has two modes, running everything or running one selected entry, and stopping cleans up the tasks that had not started. That last detail is the one that separates a usable batch node from an unusable one: stop has to mean the queue actually empties.

The control node is where the design gets interesting. It can set an interval in seconds between tasks, resume from a given index such as the fifth prompt, randomise the order within a range, and, most importantly, restrict execution to the workflow branch the batch node is connected to. Without that last option a batch node sitting in a graph with an unrelated branch would execute everything connected to the same output.

That single option is what makes batch execution safe to add to an existing workflow rather than requiring the workflow to be rebuilt for it.

The save node cooperates with the batch nodes by accepting a filename input and a prompt input, the latter writing a same-named text file beside each saved image, plus a multi-image view for reviewing several results at once.

Editorial conclusion

TE MAN is a working plugin with a genuinely deep feature set, and the batch scoping option and the branch-aware execution are worth reading before you adopt it. Two practical cautions. The plugin now requires Python 3.12 or 3.13 and the recommended environment is a bundle hosted outside the repository, so nothing about the runtime is pinned for you. And the file layout is flat and partly duplicated, which means upgrades are a matter of replacing files rather than resolving dependencies, so keep your own copy of any workflow that depends on a specific node.

Frequently asked questions

Official sources

1. Issues
2. README
3. tl2012tl/TE_MAN on GitHub