Before we release scripts “in the wild” we work our way through the below checklist.
The list is more of a guide than it is a “must do” but it helps us increase the likelihood that the scripts we release work for most people.
Are there any you do that we should add? Let me know!
I recommend you take it, or just use your own, and put it into our “Simple Checklist” tool.
- Include #requires directive – Enforces the correct interpreter version up front so users don’t accidentally run it under v1 and hit cryptic errors.
- Standard directives (#SingleInstance Force, #Warn, #ErrorStdOut) – Prevent duplicate instances, avoid legacy environment quirks, and surface warnings or runtime errors immediately.
- Added script object – Include our Script object at the top that embeds structured metadata (title, author, version, download URL).
- Add About item to the Traymenu (script object creates it) –
- Add object of other Downloads IDs: – DownloadIDs of other Automator tools they may like. The IDs will be used in an API call to pull in description
- Add license – Append or reference an open source license (MIT, GPL, etc.) in your code and download package so users know the legal terms.
- Did we build in checks for errors – Embed error‑handling routines (try/catch, input/path validations) to prevent crashes and handle edge cases gracefully.
- Are we logging errors – Write errors to a log file or Windows Event Log for post‑mortem diagnosis and support.
- Remove default menu (tray.Delete()) – Strip out the stock AHK tray entries before adding your own for a clean, custom menu.
- Added custom icon – Replace the generic AHK icon with your own .ico embedded in the EXE or script to reinforce branding and aid identification.
- Add Open Folder – to system tray so users can easily access the folder
- Should we use the icon to indicate status of script? – Consider dynamic icons (green = running, red = error) to give instant visual feedback on script health.
- Hotkey Preference selection – Provide a GUI or config file so users can remap hotkeys without editing the script, avoiding collisions.
- Should we have a preference center – Add a small UI or web widget where users can manage Hotkeys and other preferences centrally.
- Is Hotkey dynamically mentioned in the System Tray menu – List active hotkey(s) in your tray entries for easy reference.
- Dependency listing – Declare any required AHK libraries, external tools, or Windows components in your metadata and README so users know what they need.
- Option for “Add to startup” – Include a checkbox or command‑line flag to install the script into the user’s Windows startup folder or registry.
- Change DPI – Test your GUIs and tray icons at 100%, 150%, and 200% DPI to ensure crisp, correctly scaled elements.
- Run at different resolution – Test at 1080p, 1440p, 4K, etc., to confirm UI scaling and graphics behave correctly across monitors.
- Run on other monitor – Verify coordinate‑based routines (mouse moves, GUI placement) still work when the primary display changes.
- Run on other computer – Verify that the script looks / works similarly on more than one computer
- OS compatibility testing – Explicitly test (and document) on Windows 7/8/10/11, various CPU architectures, and locales to catch edge cases early.
- Clean‑up on exit – Ensure all hotkeys, timers, GUIs, COM objects, etc., are properly released so no orphan processes or hooks linger.
- Incremented Semantic version – Bump your version number (e.g., from 1.2.0 to 1.2.1) consistently in code, docs, and installer to signal meaningful updates.
- Created a pretty link – Generate a short, CamelCase URL (e.g., MyCoolTool) instead of a long raw link; it’s easier to share and brand.
- Created thumbnail on Canva – Design a crisp graphic for video previews or script galleries to draw more attention.
- Created a video – Record a short demo or walkthrough on YouTube/Vimeo to reduce support load, showcase usage, and boost SEO.
- Include video link in download – Embed your tutorial link in the Script object so offline users can still view it.
- Automatic update checker – Optional code that polls your release API or download page and notifies users when a new version is available.
- Create zip file for download – Bundle the .ahk file, icons, libraries, README, and license into one archive for a one‑and‑done download.
- Be sure to include Lib, Resources, etc. – Double‑check that all required assets (.ahk libraries, images, INI files) are inside the zip or installer.
- Created the download – Upload your ZIP or EXE to your server, GitHub Releases, or CDN; verify the file integrity and correct MIME types.
- If EXE put on git or DropBox – Add compiled .exe to your repo’s Releases section or a dedicated branch so source and binaries stay in sync.
- Put Update Date and Version on download page – Display “Last Updated: July 21, 2025 (v1.2.1)” so visitors immediately know how fresh it is.
- Banner / Promo at top with link to Discover – Add a header linking back to your main portal to drive traffic and reinforce branding.
- Pretty link mentioned in About GUI & code – Surface that friendly URL in dialogs and comment headers for easy access to docs/support.
- Donate link mentioned in About GUI & code – Embed a “Support the author” link or button so appreciative users can contribute.
- Add variable pricing or set price – If charging, implement a license‑key/payment gateway or clearly state tiers so users know what to expect.
- Select upsell/cross‑sell to relevant downloads/courses – Recommend related tools or courses on your download page to keep users engaged.
- Selected default image – Choose a fallback icon or preview so scripts without a custom graphic still look polished.
- CONTRIBUTING.md / ISSUE_TEMPLATE.md (for open source) – Provide guidelines on reporting bugs, requesting features, and submitting pull requests.
If you want to learn more about any of the above, I recommend joining the AHK Hero club, we’re happy to explain in detail how it is done
