Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Audit the two latency-critical paths for blocking work, redundant computation, and micro-optimization opportunities
user-invocable
true
disable-model-invocation
true
Enter planning mode. Deep-audit both latency-critical paths for anything that adds delay — from micro-optimizations to architectural blockers. Use maximum parallelism — spawn explore agents for independent paths.
Context
This is the highest-priority performance surface. The project's overriding goal is responsiveness — the user must never feel lag when Alt-Tabbing. Every microsecond matters on these paths because costs compound: a 50μs waste in an eligibility check runs 50× per focus event = 2.5ms. A cache miss in display list building runs every paint. Micro-optimizations are not just welcome, they're the point.
The architecture is single-process: producers, window store, and GUI all run in MainProcess. There is no IPC on the critical path — the enrichment pump (icon/process resolution) is async and off the hot path.
Scope Boundaries
This skill covers the control flow around rendering — everything from keypress to "start painting" and from "painting done" to "window visible." It does NOT cover per-frame rendering internals, which have dedicated skills:
However, the frame pacing mechanism IS in scope for this skill — the three-tier pacing in gui_animation.ahk (compositor clock → waitable swap chain → QPC spin-wait) directly affects input-to-photon latency. The decision of when to render (frame pacing) is latency-critical; what to render (paint internals) is not.
Similarly, DComp operations that affect overlay visibility timing are in scope: D2D_SetClipRect, D2D_Commit, DWM cloaking/uncloaking sequences. Present(0,0) is non-blocking post-Phase 1 — verify this hasn't regressed.
If you find a latency issue that lives inside the rendering pipeline (e.g., "paint takes too long because of X"), note it briefly and defer to the appropriate skill.
The Two Hot Paths
Path 1: Window Change → Store
An external event (focus change, window created/destroyed, komorebi workspace switch) must update the window store as fast as possible so the data is fresh when the user Alt-Tabs.
How much work does each producer callback do? Is any of it deferrable?
Are eligibility checks doing redundant work (re-checking things that haven't changed)?
Is the store upsert doing unnecessary copies or recomputations?
Are caches (komorebi state cache, blacklist compiled patterns, etc.) actually effective? Any cache misses on the hot path?
Is dirty tracking granular enough, or does a single-window change trigger broader recomputation?
Path 2: User Action → Pixels
The user presses Alt → Tab and must see the overlay with correct data as fast as possible. Then each subsequent Tab press must update the selection and repaint instantly.
This skill focuses on the control flow and data preparation — from keypress through state machine to the point where rendering begins, and from rendering completion to overlay visibility. The rendering pipeline itself (D2D draw calls, effects, compositing) is covered by /review-paint.
Alt down ──► Pre-warm (refresh data early)
Tab down ──► Freeze list ──► Build display items ──► [Paint — see /review-paint] ──► Show overlay
Tab again ──► Move selection ──► [Repaint]
Alt up ──► Activate window ──► Hide overlay
Escape ──► Cancel ──► Hide overlay
D2D operations outside the paint path (e.g., resource creation triggered by config change)
Any DllCall that might block (synchronous Win32 calls)
This is separate from the two paths above — even if Path 1 and Path 2 are individually fast, a long-running timer callback between Alt-down and Tab-down steals time from hook processing.
Explore Strategy
Split by hot path (run in parallel):
Path 1 agent: All producers in src/core/, eligibility in blacklist.ahk, store internals in window_list.ahk. Focus on per-event callback cost.
Path 2 agent: gui_interceptor.ahk, gui_state.ahk, gui_input.ahk, gui_data.ahk, gui_overlay.ahk, src/shared/gui_antiflash.ahk, gui_workspace.ahk. Focus on keypress-to-paint-call and paint-done-to-visible sequences. Do NOT audit the rendering pipeline itself.
Cross-cutting agent: query_timers.ps1 output, Critical section durations, any synchronous I/O on the main thread. Scan all src/gui/ and src/core/ files for blocking operations.
Tools
query_timers.ps1 — inventory all timers, find heavy callbacks
query_state.ps1 — trace state machine transitions for the Alt-Tab flow
query_interface.ps1 <file> — public API surface of hot path files
query_function.ps1 <func> — extract function bodies without loading full files
query_callchain.ps1 <func> — trace call depth from hot path entry points
Assessment Format
Surface everything — do not auto-exclude findings based on estimated size. Micro-optimizations on high-frequency paths are the point of this review.
For each finding, provide an honest assessment:
Finding
File:Lines
Current Cost
Frequency
Compound Cost
Complexity
Fix
Eligibility re-checks cloaked state on every focus event
blacklist.ahk:142
~30μs
50×/focus burst
~1.5ms
One-line cache
Cache cloaked state, invalidate on EVENT_OBJECT_CLOAKED
Display list rebuilds workspace labels every paint
gui_data.ahk:88
~200μs
Every Tab press
~200μs
Medium — need invalidation signal
Pre-compute during pre-warm, cache until workspace change
Columns explained:
Current Cost: Estimated per-invocation cost (use flight recorder / paint timing data if available, otherwise estimate from code complexity)
Frequency: How often this runs in the critical path (1× per Alt-Tab? 50× per focus burst? Per-pixel? Per-window?)
Compound Cost: Current Cost × Frequency — the actual user-felt impact
Complexity: How hard is the fix? One-line change, medium refactor, architectural change?
Do not filter. A 10μs saving that runs 100× per paint (1ms compound) is worth knowing about even if the fix is complex. The user decides the tradeoff.
Validation
After explore agents report back, validate every finding yourself. This codebase has extensive caching and optimization already — what looks like a miss may be handled elsewhere.
For each candidate:
Cite evidence: "I verified by reading file.ahk lines X–Y" with actual code quoted. Trace the full execution path, not just one function.
Trace the frequency: Don't guess — trace when and how often this code actually runs. A function called once at startup is not a hot path finding.
Check for existing optimization: This codebase has been through multiple optimization passes. Before flagging something, check if there's already a cache, early-exit, or pre-computation handling it.
Counter-argument: "What would make this optimization unnecessary or counterproductive?" — Does it add complexity that makes the next optimization harder? Does it break an invariant?
Observed vs inferred: Did you trace the execution path through all branches, or infer the cost from reading one function in isolation?
