Adding a new script is often pretty easy. It needs a bare minimum comment block however to get picked up.

basic script

Create an UTF-8 ps1 file like:

# api: multitool
# title: my script
# description: does all the things..
# type: inline
# category: beta
#
# What could this mean?

Param(
    $username = Read-Host("username")
)

Write-Host "username is '$username'"
Write-Host "1+2 is $(1+2)"

And that's it.

Write-Host ain't bad

You've probably read that elsewhere. And while there's some truth to Write-Host not being your best friend; context is key, generalizations are not.

Libraries and reusable code should obviously avoid direct screen output. But you know, at some point some things do need to be written out.

Interestingly Write-Host is pretty much a no-brainer for this GUI. A simple alias already does the trick, and allows to send colorized output to the screen. (It's basically a poor mans Powershell Host.)

Param / Read-Host

Now the Param() section is redundant for the GUI version, as $machine and $username are defined by default.

This is mainly necessary for the CLI version, and to allow all scripts to still run standalone.

Read-Host within the script

Care should be taken not to overuse Read-Host. The GUI catches it, but shows up an inconvenient popup.

While standalone scripts may sometimes derail into a text adventure-style game, the ClickyColoury tools/ are meant to do one thing, and one thing mostly.

Thus too much interaction should be averted for the current implementation.

Category, version, etc.

Add more description fields as you go along. It usually makes sense to have a version: for each independent tool - even if it's already under version control. Because, why not? Just because scripts are minor parts, this does not imply they're not significant enough to go underdocumented.

Obviously the category: is quite essential for CC, as it decided where scripts show up in the GUI.