winui: window sizing rubric, screenshot validation, anti-self-delegation#84
winui: window sizing rubric, screenshot validation, anti-self-delegation#84nmetulev wants to merge 4 commits into
Conversation
Three connected improvements to the WinUI dev skills, motivated by repeated failure modes when building small apps: 1. winui-design SKILL.md - new Step 4 'Size the Window to the App' WinUI 3 has no SizeToContent, so apps default to ~1024x768 regardless of content - which makes utilities feel oversized. Adds an 8-step reasoning rubric (inventory rows, derive widest-row width, sum heights, round up, sanity-check ranges, prefer compact-but-not-clipping, aspect-ratio follows content, validate after running) and a worked example. Old 'Step 4: Design Anti-Patterns' renumbered to Step 5. 2. winui-ui-testing SKILL.md - new Step 3.5 'Look at the Screenshots' UIA assertions can't see clipping, overlap, cramped layout, or theming bugs. Adds explicit guidance to capture screenshots at multiple states (initial, post-interaction, per mode), view them after each run, and apply a visual checklist. Test-script template now creates a screenshots/ directory and captures intermediate state, not just a single final shot. 3. winui-dev.agent.md - 'Do The Work Yourself' section Agents kept re-delegating user requests to a fresh winui-dev sub-agent, wasting context and hiding progress. Adds an explicit prohibition against self-delegation while still permitting narrow helpers (explore for unfamiliar codebases, rubber-duck for plan critique). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Summary
Coverage
Findings
DetailsH1 — DPI snippet won't compile in a default WinUI 3 project
var hwnd = WinRT.Interop.WindowNative.GetWindowHandle(this);
var dpi = (uint)PInvoke.User32.GetDpiForWindow(hwnd); // ← compile error
var scale = dpi / 96.0;
AppWindow.Resize(new SizeInt32((int)(460 * scale), (int)(860 * scale)));
Recommendation — pick one:
There is no built-in WinAppSDK helper that removes the DPI lookup entirely — M1 — The "every app must size its window" outcome should also live at Tier 1
The 8-step rubric mixes two kinds of guidance:
A senior maintainer would not bet shipping correctness on every agent reading 80 lines of prose to avoid the OS default 1024×768. Recommendation:
M2 — Visual-validation checklist is duplicated across both new sections
Both sections enumerate substantially the same items: text ending in Recommendation: Pick one home for the visual checklist. The screenshot review step in M3 —
|
1 participant
Three connected improvements to the WinUI dev skills, motivated by repeated failure modes I hit when building small apps.
1.
winui-design— new Step 4: Size the Window to the AppWinUI 3 has no
SizeToContent, so aWindowthat doesn't callAppWindow.Resizedefaults to whatever Windows hands it (~1024×768) — which makes utilities and forms feel comically oversized vs. e.g. SwiftUI, which auto-fits.Adds an 8-step reasoning rubric rather than a fixed lookup table:
Includes a worked example (focus timer → 460×860) and a named anti-pattern (the same app squeezed to 440×720, which clips "Long Break", crops the timer digits, and truncates the toggle label).
DPI-aware
AppWindow.Resizesnippet stays. Old "Step 4: Design Anti-Patterns" is renumbered to Step 5.2.
winui-ui-testing— new Step 3.5: Look at the ScreenshotsToday the skill captures one final screenshot and never tells the agent to look at it. UIA assertions tell you whether an element exists and what its value is — they tell you nothing about how the app actually looks. Clipped labels, overlap, cramped layout, broken theming, off-screen flyouts: UIA happily reports
PASSwhile the app is visually broken.This change:
viewtool returns images as inspectable data).…truncation, hero elements fully visible, right-edge controls visible, no overlap, theming right, etc.).AppWindow.Resize).screenshots/directory and capture intermediate states alongside the existing final shot.3.
winui-dev.agent.md— "Do The Work Yourself"Repeatedly observed: a user explicitly invokes the
winui-devagent, and the agent's first action is to call thetasktool to delegate the entire request to a freshwinui-devsub-agent. This wastes a context window, hides progress from the user, and adds latency.Adds an explicit prohibition against self-delegation at the top of the agent file, while still permitting narrow helpers (
explorefor unfamiliar codebases,rubber-duckfor plan critique on non-trivial work). Includes a concrete check: "if you catch yourself about to calltaskwithagent_type: winui:winui-dev, stop — you're the one who should be doing it."Why bundle them
All three came out of the same end-to-end build session (a Pomodoro / focus timer app). Each one fixes a real failure mode I observed:
Happy to split into three PRs if preferred.