Important: This requires you to install bethkit.exe since unfortunately even with the last update being 4 years ago I have to honor the author's permissions to not repost. However even at that point it was uploaded by a designated reposter who now seems to also be inactive. If anyone with authority sees this post and can allow me to pack the exe please let me know. Until then you must place bethkit.exe in the same folder as the wrapper app, which should by default be "C:/Program Files/elbadcode/Bethkit Wrapper"

New version:

While I don't think anyone was using this or anxiously awaiting an update, I had one nearly finished from months ago I polished up because I personally find this very useful. Quick overview of current features and changes:

Previous version was a batch script with a tiny python script for dumping EDIDS, now the full script is written in python and comes as a standalone exe - meaning you don't need to install python

You can download the python script independently but you are missing out on half the featureset if you don't use the installer. After installation you will need to either restart windows explorer, log out, or restart your PC. Afterwards you will have new "Open with" prompts for several file formats, which can be activated either by double clicking the file if an associated app is not already set, or by right clicking and mousing over to the open with drop down list. This works on windows 10 and 11. Due to this feature you will likely need to install as an admin

These are the formats covered and actions taken:

esp, esl, esm -> convert "directly" to xml and dump 3 info files based on configuration file found in the install dir
esx, xml -> convert back to esp - does not currently handle esl/esm naming. These formats will work but you have to rename the esp yourself. This is easily fixable if requested but I did not see a point. If you havent installed creation kit than most likely after installing this you will automatically run bethkitwrapper anytime you double click a bethesda plugin and you can force this behavior as you would any other windows program

Regarding esx format, this is the default format bethkit spits out and takes in. It is equivalent to xml but doesnt have text file associations so I am making your life easier by automatically converting to/from xml, meaning you should be able to just double click on the outfit file to open in your default text handler. At one point this app used to automatically open the xml afterwards and I can make that a feature again, but don't personally need it. Anyway I have left esx support so that if you choose to actually edit the xml outputs you could rename them to esx if you want to denote to yourself that the file is ready for reconversion or if you want to set bethkitwrapper as the default esx handler which you probably don't want to do with xmls. 

So what's the actual use case?

Personally I have not and don't particularly recommend using this to edit plugins. Its certainly faster than xedit while losing basically all features. If you have a simple find and replace type patch this could be useful however I would warn that relying on bethkit will make any batch operations pretty slow and that will be the weaklink. If you need batch operations probably xedit is better, I'm certainly thinking about making my own patcher as I also find xedit a bit slow and unwieldy for batch ops. For something like patching 3BA armors for UBE I think text based parsing could be useful but I haven't gotten around to that yet.

So aside from editing the main use case and the reason to even bother posting this is the info dumpers. Currently you will get one with the EDIDS suffix, that is rather self-explanatory but personally I find that grabbing edids is often the main reason I'd want to look inside a plugin file, and consider it useful enough to be its own output. The other two outputs will depend on the parser_cfg.json file which comes preloaded with some useful tags. The script will attempt to find any text or attributes related to each tag using stand xml parsing, which will do perfectly fine with some stuff and completely fail at others. The last output foregoes any xml parsing and instead runs regex searches on the raw text. This can get you some stuff that xml parsing misses. The cfg comes preloaded with the following example regex"DATA>\n.+<struct"
Both versions will attempt to use all available variables in the cfg but simply don't print blank outputs so the two methods conveniently work together without needing to be designated. All regex tags are actually wrapped in the following statement
(<{parse_var}(>(\\s|.+)?<| (.+))>)|(<{parse_var}>(.+)<)

Please don't ask me to make sense of this I wrote it 6 months ago. You can use regex101.com if you really need to know the nitty gritty details but essentially this looks for opening and closing tags and pulls out the info between. General rule of thumb, regex is much slower than matching based parsers, however it is much more flexible with the main limitation here being that the json file might muck up some symbols. While I like using regex and have used it extensively this is the first time I've written a script to dynamically construct regex from user input, so this may have some errors. If anyone wants to try using this app for batch processing then the next update would include features to streamline that and I would simply strip out the regex as it will be a slowing factor.

The final thing to note regarding the json is that the entire parsing script will break if you break the json format. This is easily avoided if you simply add members to the list following the existing format. The final entry before the closing square bracket must not have a comma afterwards 
    ["WEAP","MGEF"] ["WEAP", "MGEF",] 

Here the first example is correct while the second will completely break it. If you're unsure just use an online json formatter (or install devtoys in the windows store)

If your antivirus or virustotal says its a virus and you choose to believe that instead of looking through the easily understandable source code yourself then that is your prerogative but don't post about it here. 

This is a totally nondestructive process and your original plugins will never be touched, do note that repeated conversion ops will increase filename and after a couple goes it will break the script soooo don't do that

Genuinely hope someone finds this useful