# Custom Windows Wpf Teacher App

> Use when designing or implementing a Windows-first WPF/.NET teacher or classroom application where touch, pen, presentation files, dual-screen, recovery, local data, screenshots, or UI Automation are product requirements. Do not use for generic WPF/.NET errors, dependency injection, build failures, or backend debugging; use a dedicated .NET/debugging skill instead.

- Skill: `sciman-top/custom-windows-wpf-teacher-app` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add sciman-top/custom-windows-wpf-teacher-app`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sciman-top/custom-windows-wpf-teacher-app/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sciman-top (https://skillmd.com/u/sciman-top)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sciman-top/custom-windows-wpf-teacher-app

---


# Windows WPF Teacher App

Use this skill for practical classroom software on Windows machines.

## Product Priorities

1. Teacher workflow speed beats decorative novelty.
2. Touch, pen, projector, and low-friction file handling are first-class.
3. Offline/local-first behavior should remain usable without cloud services.
4. Recovery and export matter: a teacher should not lose classroom state after a crash or power issue.

## Engineering Checks

- Keep domain/application logic away from WPF views and interop.
- Use explicit dispatcher boundaries for UI thread work.
- Treat second-screen, full-screen, topmost, slideshow control, and overlay behavior as contracts with tests or probes.
- For settings and startup, verify load latency and corrupt-config fallback.
- For file workflows, test Chinese paths, OneDrive paths, locked files, and removable media.

## Desktop UI Observation

- First identify the real running entrypoint, process name, window title, config/state path, and whether the app is single-instance.
- Prefer non-invasive evidence first: screenshot, window bounds, logs, current config, and command output.
- For WPF/.NET apps, prefer Microsoft UI Automation based probes, then FlaUI for .NET test code, or pywinauto for ad-hoc Python inspection when a repo already supports Python.
- WinAppDriver/Appium-style routes are acceptable only when the project already carries that dependency or the user explicitly wants a broader desktop E2E harness.
- Do not treat Playwright browser success as proof that a native Windows desktop surface works. Browser automation only verifies web/Electron/webview surfaces.
- Ask before starting, stopping, rebuilding, or replacing a long-running desktop app when that could interrupt the user's current session.

## Desktop UI Operation

- Use stable automation identifiers, accessible names, and window handles before image-coordinate clicks.
- If coordinate/pixel actions are unavoidable, record the screenshot, region, DPI/scaling assumptions, and rollback path.
- For touch-first classroom flows, verify tap targets, drag/ink gestures, full-screen mode, projector/secondary display behavior, and recovery after window focus changes.
- For visible app changes, capture before/after screenshots or a short manual probe transcript with the exact commands and observed result.

## UI Checks

- Verify touch targets at the intended Windows scaling and classroom hardware; a desktop screenshot at 100% DPI is not sufficient touch evidence.
- Avoid tiny toolbar-only affordances for core teaching actions.
- Support presenter view, navigation/search/bookmarks, richer ink tools, and accessible labels where relevant.
- Verify keyboard-only access, visible focus, high-contrast behavior, and meaningful UI Automation names for core teaching controls. Treat automated UIA inspection as structural evidence, not proof of a complete screen-reader experience.

## Deliverable Boundary

- For design work, return the classroom flow, product constraints, recovery/data contract, architecture seams, and acceptance probes that remain open.
- For implementation work, modify the real repository entrypoint, keep domain/application logic outside WPF views and interop, and finish with the repository's focused build/test gate plus a UI or classroom-flow probe. Do not stop at a design sketch when working code was requested.

## Verification

- Run the target repository's real build and focused test gates. Only fall back to `dotnet build` when the repository defines no build contract.
- Use `-p:UseSharedCompilation=false` when compiler server locks cause noisy local failures.
- For UI changes, capture before/after screenshots or run a manual classroom-flow probe.