The following AI-generated aka vibe-coded software. The software is specific to my needs and my system and may not work for you or your system. Support is limited, but if you report a bug I'll certainly look into it. All code is provided in a zip file for you to review should you choose.

Scriptary

A desktop library for the scripts you keep re-running.

Scriptary registers your Python, PowerShell and batch scripts, works out what arguments each one takes, and gives you a form to fill in instead of a command line to remember. It saves what you typed last time, runs scripts in tabs with live output, and colour-codes what succeeded and what didn’t.

It is a single file with no required dependencies beyond the Python standard library.

Requirements

• Python 3.9+ with tkinter (bundled with the standard Windows installer)
• Windows — the runner uses Windows-only process flags and shell handling
• Optional: pystray and Pillow for the system-tray icon. Without them the app runs normally and simply has no tray support.

Getting started

python scriptary.pyw

Then use + Add to register a script, or 🔍 Scan Folder to walk a directory tree and register everything it finds.

Select a script and its arguments appear as a form. Fill it in, press ▶ Run, and the output opens in a tab. Save params remembers the values for next time.

How arguments are detected

Scriptary reads your scripts; it does not run them.

For Python it parses the source and finds the add_argument calls, so flags, types, defaults, choices and help text all come through. For PowerShell it reads the param() block, taking the description from .SYNOPSIS. For batch files it scans for positional tokens %1 through %9. Nothing is executed at any point, so adding or refreshing a library is always safe — even if it contains something destructive.

Static analysis can’t see everything. A parser built dynamically at runtime, or a click/typer CLI, may come back with no arguments. For those cases there is a runtime probe that starts the script, intercepts its argument parser, and reads the real thing. It is more accurate, and it genuinely runs your code.

Because of that it’s off by default and there are two deliberate ways to turn it on:

• Once, for one script — right-click it and choose Detect Arguments by Running Script…. You get a confirmation prompt first.
• Always — tick Argument detection → Run Python scripts to detect their arguments in the settings drawer. Every Add, Refresh and Scan will then execute Python scripts.

The detail panel shows which method was used for the selected script:

The script list

Each row carries its state at a glance:

• A coloured dot — green if the last run succeeded, red if it failed, grey if it has never run. The timestamp beside it takes the same colour.
• A language badge — py, ps1, bat.
• ⓘ — hover for the full path.
• ⧉ — this script opens a graphical interface (see below).
• ✎ — this script has a note. Hover to read it.

Scripts are organised into groups you create, or fall under a header named for their parent folder. Groups and folder headers are sorted together in one alphabetical run. Right-click a script to move it between groups, rename its label, clone it, or remove it.

When a script moves

A script whose file has gone stays in the list, struck through and greyed, rather than silently disappearing — and its detail panel gains a red banner with a Locate file… button. The same action is on the right-click menu as Locate File… (or Change File… for a script that isn’t broken, if you want to repoint it at something else).

Relocating fixes the whole folder, not one file. A moved directory breaks every script inside it at once, so once you have corrected one path the change is applied as a prefix rewrite: other missing scripts that lived in the old folder are looked for in the new one, subfolders included, and you get a confirmation listing what was found before anything changes.

Everything that isn’t the file survives the move — label, note, group, run history and saved parameters all stay attached, because they are keyed to the entry rather than to its path. That is the difference between relocating and removing-then-re-adding, which loses all of it.

GUI detection

Scriptary flags scripts that open a window, so you know which ones will take over your screen before you run them. It works by reading imports — tkinter, PyQt, PySide, wxPython, Kivy, Pygame and others — plus Windows Forms and WPF for PowerShell, and mshta or pythonw for batch files. A .pyw extension counts on its own.

This is a strong hint rather than a guarantee. A toolkit imported inside a branch that never executes will still be flagged, and a GUI launched indirectly through subprocess will be missed. Web frameworks that start a server rather than open a window — Streamlit, Gradio, Flask — are not counted.

Search and filters

The search box matches on name, label, description and path.

The Filter dropdown beside it narrows by attribute:

Filters combine with AND, so each one you tick narrows the result further. That means some combinations can’t match anything by construction — a script can’t be both GUI and No GUI, and a file has only one extension, so ticking .bat and .ps* together matches nothing. When that happens the list says so rather than just going blank.

Notes

Any script can carry a free-text note — a warning, a reminder of which host to point it at, what to do when it fails.

Add one from the ✎ Add note button beside the script title, or by right-clicking the script in the list. Notes appear under the title, showing the first four lines immediately with a Show all… toggle for longer ones. Scripts without a note show nothing at all, so the panel stays clean.

Running scripts

Each run opens its own tab with live output. While it runs you can type into the Input field to send text to the process’s stdin, and ⏹ Stop ends it. ANSI colour escapes from the script are rendered rather than shown raw.

When a run finishes, the outcome shows up in four places at once: the tab label gains a green ✓ or red ✗ and keeps that colour, the footer reports the exit code, the status bar echoes it, and the script’s dot in the list updates.

Output can be copied or saved to a file from the footer buttons.

Interpreters and execution

The collapsible drawer at the top of the window sets which interpreters get used:

Each field keeps a history of what you have entered before, reachable from its dropdown; 🗑 removes the current entry from that history.

Keyboard shortcuts

Command line

Scriptary is usable without the GUI:

python scriptary.pyw                      # launch the GUI
python scriptary.pyw list                 # list registered scripts
python scriptary.pyw add <script.py>      # register a script
python scriptary.pyw remove <name>        # remove a script by name
python scriptary.pyw run <name>           # run with its saved parameters
python scriptary.pyw --help

add uses static analysis only.

Where things are stored

Three JSON files, prefixed with the machine’s name so one synced folder can hold settings for several machines:

They live beside scriptary.pyw by default. To put them elsewhere:

python scriptary.pyw --config-dir D:\config
python scriptary.pyw --config-dir ./config      # relative to the script

The flag works with every command, so a portable install and a CLI cron job can share one library.

Portable script paths

Script paths are stored against an environment token wherever one fits, so a library survives being synced to another machine where the profile, OneDrive root or install drive sit somewhere else:

C:\Users\ada\scripts\backup.py        →  %USERPROFILE%\scripts\backup.py
C:\Users\ada\OneDrive\ops\deploy.ps1  →  %OneDrive%\ops\deploy.ps1
D:\Scriptary\lib\helper.py            →  %SCRIPTARY_HOME%\lib\helper.py

The longest matching prefix wins, so a file under OneDrive is stored against %OneDrive% rather than %USERPROFILE%.
%SCRIPTARY_HOME% is not a real environment variable — it stands for the folder holding scriptary.pyw, which makes a portable install work whatever drive letter it is mounted under.
Anything outside all of them is stored as a plain absolute path.

Tokens are resolved on every read, so on the machine that wrote them the paths mean exactly what they always did, and existing libraries are converted the first time they are opened. You can also type a token by hand — %OneDrive%\… in the Add dialog is stored and resolved the same way.

One consequence worth knowing: %USERPROFILE% resolves per user. If two Windows accounts share one machine, and therefore one registry file, a script stored under one profile will resolve into the other’s. Locate File… fixes it if that ever bites.

Notes on behaviour

• One instance. Launching Scriptary while it is already running brings the existing window forward instead of opening a second one.
• Refresh re-reads any script whose file has changed on disk and updates its arguments. Files that have not changed are skipped.
• Missing files. A script whose file has been deleted or moved stays in the list, struck through and greyed, so you can see what broke rather than having it silently vanish. Use Locate File… to repoint it; see When a script moves above.
• Unsaved parameters are tracked per script. The ● Unsaved button jumps to the first script with pending changes, and closing the app with unsaved values asks before discarding them.
• System tray. With pystray and Pillow installed, the window can minimise to the tray and be restored from its icon.