Enter planning mode. Deep-review all user-facing aspects of the app for professionalism and polish. Use maximum parallelism — spawn explore agents for independent areas.
Context
Making an AHK app feel native and professional on Windows is hard. Past reviews have surfaced valuable improvements — consistent theming, proper DPI handling, polished message boxes, etc. This review checks whether the app still feels professional as features have been added.
What to Look For
Visual polish
- Inconsistent fonts, sizes, or spacing across different windows/dialogs
- Controls that don't align properly or have uneven margins
- Windows that don't respect system DPI scaling
- Dark/light mode inconsistencies (see
theme.ahk — the theme system exists, but is it applied everywhere?)
- Flash or flicker when showing/hiding windows (see
gui_antiflash.ahk)
- Tray icon and menu looking native and consistent with Windows conventions
User-facing text
- Typos, grammatical errors, or awkward phrasing in any user-visible string
- Inconsistent capitalization (Title Case vs Sentence case across dialogs)
- Technical jargon exposed to end users who won't understand it
- Error messages that don't tell the user what to do next
- Tooltip text that's too vague or too verbose
UX quality of life
- Operations that block the UI without feedback (no progress indication)
- Dialogs that appear in unexpected positions (not centered on parent/monitor)
- Missing keyboard navigation (Tab order, Enter to confirm, Escape to cancel)
- Actions that can't be undone but have no confirmation prompt
- Config changes that require restart but don't tell the user
Native Windows behavior
- Message boxes that don't use
ThemeMsgBox() (the project's themed replacement)
- Windows that don't appear in taskbar when they should (or appear when they shouldn't)
- Improper window ownership (child dialogs that can go behind parent)
- Missing or wrong window icons
- Context menus that don't follow Windows conventions
Installer/update experience
- Wizard steps that are confusing or have unclear choices
- Update notifications that are intrusive or poorly timed
- Elevation prompts without explanation of why admin is needed
- Error recovery that leaves the user stranded
Config editor
- Settings descriptions that are unclear to non-technical users
- Missing validation feedback (user enters invalid value, nothing happens)
- Settings that interact but don't communicate this to the user
Explore Strategy
Split by user-facing surface:
- Overlay / Alt-Tab UI —
src/gui/gui_paint.ahk, gui_overlay.ahk — the main interaction surface
- Tray menu / launcher —
src/alt_tabby.ahk, launcher files — first impression and daily interaction point
- Config editor —
src/editors/ — where users spend time customizing
- Wizard / installation — wizard files, setup utilities — first-run experience
- Dialogs / message boxes — grep for
MsgBox, ThemeMsgBox, Gui() across all files
- User-facing strings — all strings shown to users (error messages, tooltips, menu items, descriptions)
Validation
After explore agents report back, validate every finding yourself. "Professionalism" is subjective — what one person calls polish, another calls unnecessary complexity.
For each candidate:
- Cite evidence: "I verified by reading
file.ahk lines X–Y" with the actual user-facing text or UI code quoted.
- User impact: Who sees this and when? A rough edge in the first-run wizard matters more than one in a diagnostic dialog.
- Counter-argument: "What would make this fix unnecessary or counterproductive?" — Is the current behavior actually fine and the "improvement" just taste? Would the fix add complexity for minimal visual gain?
- Observed vs inferred: Did you see the issue in the code, or infer it from the absence of something (e.g., "no DPI handling" — but did you check if AHK handles it automatically)?
Plan Format
Group by user-facing area:
| Area |
File |
Lines |
Issue |
User Impact |
Fix |
| Wizard |
launcher_wizard.ahk |
88 |
"Click OK to continue" — no explanation of what happens next |
Confusing first-run |
Rewrite to "This will install Alt-Tabby to Program Files and create a startup task." |
| Tray menu |
launcher_tray.ahk |
42 |
Menu item "Debug Viewer" — technical jargon |
Intimidating to non-technical users |
Rename to "Window Inspector" or similar |
| Config editor |
config_editor.ahk |
200 |
Setting description uses ms units without explanation |
User doesn't know what 150ms means |
Add "(lower = faster response)" hint |
Order by user exposure: high-traffic surfaces first (overlay, tray, config editor), rarely-seen surfaces last (wizard, error dialogs).
Ignore any existing plans — create a fresh one.
1---2name: review-professionalism3description: Review app polish — native feel, user-facing text, UX quality, and professional presentation4---5Enter planning mode. Deep-review all user-facing aspects of the app for professionalism and polish. Use maximum parallelism — spawn explore agents for independent areas.
6
7## Context
8
9Making an AHK app feel native and professional on Windows is hard. Past reviews have surfaced valuable improvements — consistent theming, proper DPI handling, polished message boxes, etc. This review checks whether the app still feels professional as features have been added.
10
11## What to Look For
12
13### Visual polish
14- Inconsistent fonts, sizes, or spacing across different windows/dialogs
15- Controls that don't align properly or have uneven margins
16- Windows that don't respect system DPI scaling
17- Dark/light mode inconsistencies (see `theme.ahk` — the theme system exists, but is it applied everywhere?)
18- Flash or flicker when showing/hiding windows (see `gui_antiflash.ahk`)
19- Tray icon and menu looking native and consistent with Windows conventions
20
21### User-facing text
22- Typos, grammatical errors, or awkward phrasing in any user-visible string
23- Inconsistent capitalization (Title Case vs Sentence case across dialogs)
24- Technical jargon exposed to end users who won't understand it
25- Error messages that don't tell the user what to do next
26- Tooltip text that's too vague or too verbose
27
28### UX quality of life
29- Operations that block the UI without feedback (no progress indication)
30- Dialogs that appear in unexpected positions (not centered on parent/monitor)
31- Missing keyboard navigation (Tab order, Enter to confirm, Escape to cancel)
32- Actions that can't be undone but have no confirmation prompt
33- Config changes that require restart but don't tell the user
34
35### Native Windows behavior
36- Message boxes that don't use `ThemeMsgBox()` (the project's themed replacement)
37- Windows that don't appear in taskbar when they should (or appear when they shouldn't)
38- Improper window ownership (child dialogs that can go behind parent)
39- Missing or wrong window icons
40- Context menus that don't follow Windows conventions
41
42### Installer/update experience
43- Wizard steps that are confusing or have unclear choices
44- Update notifications that are intrusive or poorly timed
45- Elevation prompts without explanation of why admin is needed
46- Error recovery that leaves the user stranded
47
48### Config editor
49- Settings descriptions that are unclear to non-technical users
50- Missing validation feedback (user enters invalid value, nothing happens)
51- Settings that interact but don't communicate this to the user
52
53## Explore Strategy
54
55Split by user-facing surface:
56
57- **Overlay / Alt-Tab UI** — `src/gui/gui_paint.ahk`, `gui_overlay.ahk` — the main interaction surface
58- **Tray menu / launcher** — `src/alt_tabby.ahk`, launcher files — first impression and daily interaction point
59- **Config editor** — `src/editors/` — where users spend time customizing
60- **Wizard / installation** — wizard files, setup utilities — first-run experience
61- **Dialogs / message boxes** — grep for `MsgBox`, `ThemeMsgBox`, `Gui()` across all files
62- **User-facing strings** — all strings shown to users (error messages, tooltips, menu items, descriptions)
63
64## Validation
65
66After explore agents report back, **validate every finding yourself**. "Professionalism" is subjective — what one person calls polish, another calls unnecessary complexity.
67
68For each candidate:
69
701. **Cite evidence**: "I verified by reading `file.ahk` lines X–Y" with the actual user-facing text or UI code quoted.
712. **User impact**: Who sees this and when? A rough edge in the first-run wizard matters more than one in a diagnostic dialog.
723. **Counter-argument**: "What would make this fix unnecessary or counterproductive?" — Is the current behavior actually fine and the "improvement" just taste? Would the fix add complexity for minimal visual gain?
734. **Observed vs inferred**: Did you see the issue in the code, or infer it from the absence of something (e.g., "no DPI handling" — but did you check if AHK handles it automatically)?
74
75## Plan Format
76
77Group by user-facing area:
78
79| Area | File | Lines | Issue | User Impact | Fix |
80|------|------|-------|-------|------------|-----|
81| Wizard | `launcher_wizard.ahk` | 88 | "Click OK to continue" — no explanation of what happens next | Confusing first-run | Rewrite to "This will install Alt-Tabby to Program Files and create a startup task." |
82| Tray menu | `launcher_tray.ahk` | 42 | Menu item "Debug Viewer" — technical jargon | Intimidating to non-technical users | Rename to "Window Inspector" or similar |
83| Config editor | `config_editor.ahk` | 200 | Setting description uses ms units without explanation | User doesn't know what 150ms means | Add "(lower = faster response)" hint |
84
85Order by user exposure: high-traffic surfaces first (overlay, tray, config editor), rarely-seen surfaces last (wizard, error dialogs).
86
87Ignore any existing plans — create a fresh one.