windows-gui-visual-testing
mlidbom/Compze
Autonomously verify what a Windows desktop GUI app you are developing (WPF, WinForms, Win32) actually RENDERS — without Computer Use. Instrument the app itself with a self-capture channel (a trigger file makes the app screenshot its OWN window to a PNG you read), plus a file log, topmost-and-foreground pinning, a single-instance guard, and a tight edit→build→launch→capture→read loop. Use this whenever you are iterating on a Windows desktop app and need to SEE its rendered output — a window's pixels, layout, a visual bug, animation or liveness, or DWM/DirectComposition/Direct3D/GPU-composited content such as live thumbnails, video, or custom drawing — especially when Computer Use is too slow, masks ungranted windows, or gets occluded. Strongly prefer it over Computer Use for any local build-and-look loop on a native Windows GUI you are building; it lets you iterate solo at build speed instead of one screenshot per round-trip. Not for: CI or packaging builds, diagnosing a crash from a stack trace, unit or logic
desktop-takeover-gate
mlidbom/Compze
Use BEFORE running anything that takes over the user's desktop in the foreground — a lab's experiment/takeover mode, a UI-automation or visual GUI test, a focus/virtual-desktop-switch harness, the Hyper-V-matrix drivers run locally, or an ad-hoc window-driving script you wrote. It pops a topmost, all-desktops permission prompt ("I am about to run X in the foreground; while it runs you can't use the computer; runs automatically in 5s") with [OK]/[Cancel], runs the command in the foreground, then shows a symmetric "done" notification so the user knows their computer is free again. Cancel returns exit code 64 — a unique signal to STOP and tell the user they cancelled, never retry silently. This is HOW you satisfy the never-background rule (002): never background such a run; run it foreground through this gate. Not for: ordinary builds, file edits, code-intelligence/MCP calls, or any command that does not seize the screen.
team-review-and-fix-code-standard-issues
mlidbom/Compze
Multi-agent hunt for violations of the project's own coding standards. One agent distills the standards (and their rationale sidecars) into actionable, searchable checks; a fleet of hunters each sweep the whole codebase for one check and propose fixes; a judge dedups and ranks; independent skeptics (validity / improvement / risk) try to kill each candidate before it survives. Produces a vetted refactor worklist; on approval, applies in build-gated waves with per-wave commits. Use when asked to audit, review, or refactor for code-style / cohesion / rich-types / standards compliance, or to "run the style review". Not for: bug hunting (use /code-review), one-off single-file edits, or reviewing a PR diff.
jetbrains-inspect
mlidbom/Compze
Headless JetBrains code inspections for findings the IDE MCP can't give you: the sub-warning tier (suggestions / style hints like "use var", "can be made static"), whole-solution scans, no-IDE / CI runs, and non-.NET languages. FIRST check the fast path — for .NET errors + warnings on specific files, use the Rider MCP directly (`lint_files` or `get_file_problems errorsOnly:false`, Rider 2026.2+); it's live and needs no temp files, so don't reach for this slower tool just for warnings. Use this skill when you need severities BELOW warning, the whole solution at once, no running IDE, or a non-.NET language (Python / JS-TS / Java-Kotlin / Go / SQL via that IDE's `inspect` CLI; .NET via `jb inspectcode`). Not for: navigation or refactor/build (use the code-intelligence MCPs).
run-and-fix-resharper-inspections
mlidbom/Compze
Run a headless ReSharper inspection pass (jb inspectcode) over a .NET solution and systematically correct the findings: parse the SARIF output, scope to one inspection type at a time, fix in build-gated batches grouped by file, dodge the known traps (override chains, Newtonsoft silently losing data on internal getters, making the wrong overload private), then build + full test suite and re-run to confirm zero. Use for whole-solution inspection sweeps and systematic cleanup campaigns — "fix all MemberCanBeInternal", "clean up inspection warnings", severities below warning, or when no IDE is running. Not for targeted per-file diagnostics — a live ReSharper-backed MCP (get_diagnostics / lint_files) is faster when one is available.
