winui: window sizing rubric, screenshot validation, anti-self-delegation

[nmetulev]

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 App

WinUI 3 has no SizeToContent, so a Window that doesn't call AppWindow.Resize defaults 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:

1. Inventory every row of the layout (don't just think about the "main" content)
2. Estimate width from the widest row, not the average
3. Sum heights row-by-row, including spacing
4. Round up to the nearest 20 (rounding down is how content clips)
5. Sanity-check against scale anchors (utility / form / multi-pane / editor)
6. Compactness vs. clipping — pick clipping-free every time
7. Aspect ratio follows the layout (don't default to landscape out of habit)
8. Validate after running — capture a screenshot and look for clipped labels, cropped hero elements, right-edge truncation, footer overlap, unintended scrollbars; bump 40–80px and rebuild if any appear

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.Resize snippet stays. Old "Step 4: Design Anti-Patterns" is renumbered to Step 5.

2. winui-ui-testing — new Step 3.5: Look at the Screenshots

Today 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 PASS while the app is visually broken.

This change:

• Adds a mandatory "Look at the Screenshots" step between "Run results" and "Fix and rerun".
• Tells the agent to capture screenshots at multiple states (initial, post-interaction, per mode), not just at the end.
• Tells the agent to view each PNG after the run (its view tool returns images as inspectable data).
• Provides a concrete visual checklist (no … truncation, hero elements fully visible, right-edge controls visible, no overlap, theming right, etc.).
• Cross-references the sizing rubric for the most common fix (window too small → grow AppWindow.Resize).
• Updates the test-script template to create a 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-dev agent, and the agent's first action is to call the task tool to delegate the entire request to a fresh winui-dev sub-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 (explore for unfamiliar codebases, rubber-duck for plan critique on non-trivial work). Includes a concrete check: "if you catch yourself about to call task with agent_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:

• the agent delegated to itself → clutters context, hides progress
• the resulting app launched at OS default size, then a follow-up landed too cramped → window sizing needs an explicit rubric
• UIA tests passed while the cramped UI was visibly broken → needs screenshot review

Happy to split into three PRs if preferred.