Commit Graph

18 Commits

Author SHA1 Message Date
Gleb Khmyznikov
5759a62d4a [UITests][Keyboard Manager] UI tests for new keyboard manager. (#50059)
<!-- Suggested title: [UITests][Keyboard Manager] Add and stabilize UI
tests for the unified editor -->

## Summary of the Pull Request

Closes: #40662

Adds a new `Microsoft.PowerToys.UITest.Next` end-to-end suite for
Keyboard Manager and hardens the unified editor behavior uncovered while
exercising it on Windows 10, Windows 11, x64, and ARM64.

The Keyboard Manager suite executes 32 test cases covering:

- Unified editor create, edit, save, enable/disable, delete, restart
persistence, missing-profile recovery, validation, and special actions.
- Single-key, key-to-shortcut, shortcut-to-shortcut, shortcut-to-key,
disabled-key, and app-specific remapping.
- Modifier ordering and release behavior, including Alt+Tab and Alt+F4
targets.
- Real keyboard behavior through Windows Notepad and Calculator fixtures
rather than synthetic input windows.

The PR also adds 26 managed unit tests around settings normalization,
profile reconciliation, metadata ownership, active-state changes, and
canonical modifier ordering.

## Detailed Description of the Pull Request / Additional comments

### Keyboard Manager UI tests

Adds `src/modules/keyboardmanager/Tests/KeyboardManager.UITests` as a
Microsoft Testing Platform executable using `UITestAutomation.Next` and
winappcli.

The suite includes:

- `KeyboardManager.Editor.CreateEditPersistDelete`
  - Creates and edits mappings.
- Verifies native profile and editor metadata persistence across
restarts.
- Exercises active-state toggling, row deletion, and missing
native-profile recovery.
- `KeyboardManager.Editor.InputAndValidation`
- Covers key recording, dropdown input, keyboard navigation,
cancellation, and app-specific validation.
- `KeyboardManager.Editor.ActionPersistence`
- Covers Open URL, Open app, and Insert text actions and verifies
canonical readback after restart.
- Parameterized runtime tests for key/shortcut combinations, disabled
targets, app-specific mappings, modifier release order, Alt+Tab, and
Alt+F4.

The test support code provides:

- A shared cross-process fixture lock and isolated Keyboard Manager
settings scope.
- Real Notepad documents with exact window/document ownership and
cleanup.
- Win10/Win11-aware Calculator window ownership for Alt+F4 assertions.
- A low-level keyboard event recorder that validates injected
key-down/key-up sequences and flags.
- Authoritative persisted JSON assertions instead of relying only on
transient UI state.

### Keyboard Manager correctness fixes found by the suite

The tests exposed product races and persistence issues that are fixed in
the same PR:

- Native profile JSON is written through checked same-directory atomic
replacement instead of a truncation-prone direct write.
- Editor metadata and native mappings are normalized and reconciled per
profile.
- Create, edit, delete, and active-state mutations commit metadata and
native state transactionally under a cross-process lock.
- Startup reconciliation preserves inactive metadata owned by other
profiles and repairs legacy/profileless settings.
- Native Boolean return values use one-byte marshaling to match the C++
ABI.
- Modifier keys and serialized targets are canonicalized consistently.
- Unit-test initialization no longer starts real settings
synchronization.

### CI stability hardening

The editor workflows use coordinate-free UIA invocation for command
buttons and authoritative-signal retries for idempotent row
interactions. Window fixtures bind exact top-level HWNDs and distinguish
the Win10 Calculator `ApplicationFrameWindow` from its child content
window.

The child-specific `UITestAutomation.Next` updates add or improve:

- `WindowShowWatcher` lifecycle handling used by the Keyboard Manager
window fixtures.
- Exact HWND foreground, close, and process-tree cleanup helpers
required by the Win10/Win11 tests.

### Pipeline workflow

Adds the internal `ui-tests-pipeline-ci` skill and Azure DevOps helper
used during stabilization:

- Uses an existing Azure CLI session plus Azure DevOps REST APIs without
per-call authentication prompts.
- Supports paged branch/build discovery, preview and queue operations,
exact-SHA reconciliation, stage retry/cancel, logs, test results,
artifacts, and direct result-attachment downloads.
- Uses build-scoped one-shot completion monitoring and retains the
three-run stabilization guardrail.

## Validation Steps Performed

### Azure DevOps UI Test Automation

Final verification build: 
-
https://microsoft.visualstudio.com/Dart/_build/results?buildId=155512681&view=results
-
https://microsoft.visualstudio.com/Dart/_build/results?buildId=155525972&view=results

## Reviewer guide

Suggested review order:

1. `src/modules/keyboardmanager/Tests/KeyboardManager.UITests/` -
intended workflows and assertions.
2. `KeyboardManagerEditorUI/Settings/SettingsManager.cs` and
`Pages/MainPage.xaml.cs` - transaction and reconciliation ownership.
3. `common/MappingConfiguration.cpp` and
`Interop/KeyboardManagerInterop.cs` - native persistence and ABI fixes.
4. `src/common/UITestAutomation.Next/WindowControl.cs` and
`WindowShowWatcher.cs` - child-specific window lifecycle hardening.
5. `.github/skills/ui-tests-pipeline-ci/` - internal Azure CLI/REST
stabilization workflow.

Local evidence: 
<img width="1237" height="854" alt="image"
src="https://github.com/user-attachments/assets/ff49652e-fbc8-4581-a48f-836dbed37b6e"
/>
2026-08-21 17:35:13 -07:00
Gleb Khmyznikov
d68980a81b [UITests][FancyZones + Editor] Migrate FZ UI tests to .Next framework + add new tests (#49985)
# test(fancyzones): migrate and expand UI tests to winappcli

## Summary of the Pull Request

Part of #40658.

Adds `FancyZones.UITests.Next`, a Microsoft.Testing.Platform test
executable built on `UITestAutomation.Next` and winappcli. It ports the
18 active legacy FancyZones tests and adds 3 conservative backend
scenarios selected from the larger manual plan:

- quick-layout switching during an active window drag
- excluded-app enforcement
- one-monitor keyboard snapping, zone cycling, and last-zone restore on
reopen

The suite now contains 21 tests. Editor CRUD and layout-authoring
coverage remains in the separate `FancyZonesEditor.UITests` project.

The migration also fixes two FancyZones defects exposed by the new
tests: swallowed Shift input did not update drag state, and the first
Shift-triggered zone highlight was reset after it was calculated.

## PR Checklist

- [ ] Closes: #49426 
- [x] CI Green
https://microsoft.visualstudio.com/Dart/_build/results?buildId=155118915

## Detailed Description of the Pull Request / Additional comments

### FancyZones test migration

- Registers `FancyZones.UITests.Next` for x64 and ARM64 in
`PowerToys.slnx`.
- Ports dragging, quick-layout, virtual-desktop, window-switching,
transparency, editor-launch, and process-start coverage.
- Adds focused coverage for excluded apps, keyboard snap
override/cycling, last-zone restore, and quick-layout switching during a
drag.
- Uses per-monitor-v2 DPI awareness and keeps the legacy WinAppDriver
suite in place.

### Stable behavioral signals

- Uses `app-zone-history.json`, `applied-layouts.json`, and per-HWND
`FancyZones_zones` properties instead of relying on visual geometry
alone.
- Uses WinEvent hooks for transient zone flashes and Win32
window/process queries for cheap readiness checks.
- Drives the layout editor through its named event and verifies the
resulting files.
- Tracks Explorer windows by HWND, validates title-bar point ownership,
recomputes grab coordinates after failures, and retries the complete
drag gesture.
- Keeps modifier state through `MOVESIZEEND` and avoids cursor movement
that changes the selected zone.

### Product fixes

- Records Shift state before the low-level hook swallows the key during
an active move loop.
- Enters snapping mode before calculating the first highlighted zone so
the transition does not reset that result.

### Shared framework and CI hardening

- Adds reusable named-event, window-show watcher, keyboard-state,
window-property, alpha, foreground, and capture helpers to
`UITestAutomation.Next`.
- Advances the centrally managed .NET package set from `10.0.10` to
`10.0.11` to match the runtime packs selected by SDK `10.0.400` and
prevent dependency-audit collisions.
- Documents Azure Artifacts runtime-pack cache misses and the
authenticated upstream-cache workflow.

The broader manual checklist remains intentionally manual where
automation would be costly or fragile: multi-monitor/span scenarios,
lock/reboot and device reconnect, administrator boundaries, child/popup
windows, appearance color rendering, and overlap-algorithm visuals.
FancyZones Editor creation/copy/delete/grid/canvas workflows are already
covered by its dedicated UI-test project.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: khmyznikov <6115884+khmyznikov@users.noreply.github.com>
2026-08-21 23:43:32 +02:00
Boliang Zhang
e753ec51fb feat(release): automate draft preview release preparation (#49797)
## Summary of the Pull Request

Adds a `Prepare Preview Release` custom agent that autonomously turns a
successful PowerToys Azure DevOps release-candidate build into a
complete GitHub draft prerelease for final human review.

The implementation extends the existing `release-note-generation` skill
instead of duplicating it. It adds exact-build metadata resolution,
published-release baseline selection, semantic PR deltas across `main`
and `stable`, release asset validation, idempotent draft-only release
updates, and final draft verification.

## PR Checklist

- [x] **Communication:** The autonomous preview-release design was
reviewed and approved before implementation
- [x] **Tests:** Added/updated and all pass
- [x] **Localization:** N/A; no end-user-facing strings were added
- [x] **Dev docs:** Added preview scenario, delta, draft safety, and
reporting references

## Detailed Description of the Pull Request / Additional comments

- Adds `.github/agents/prepare-preview-release.agent.md` with a
no-mid-run-decision workflow and a strict prohibition on publishing
releases.
- Extends `.github/skills/release-note-generation/SKILL.md` with
stable/preview scenario routing while preserving the existing
stable-release workflow.
- Adds canonical scripts under
`.github/skills/release-note-generation/scripts/` to:
  - Resolve and validate ADO build metadata.
- Select the latest published stable or preview baseline before build
queue time.
- Calculate same-lineage or branch-transition PR deltas using PR
numbers, cherry-pick provenance, and patch-ID equivalence.
  - Collect normalized PR metadata and create `release-manifest.json`.
- Download and validate installers, symbols, and GPO assets, including
hashes, signatures, and ZIP contents.
- Create or update draft prereleases while preserving human text outside
managed markers.
- Verify draft flags, immutable target commit, body markers, and
uploaded assets.
- Updates `.pipelines/resolveBuildMetadata.ps1` and
`.pipelines/v2/release.yml` with explicit `auto`, `preview-release`, and
`stable-release` intent handling so preview candidates can be built from
either `main` or `stable`.
- Adds `.pipelines/writeReleaseMetadata.ps1` so each signed build
artifact records its resolved version, channel, intent, source branch,
and immutable source commit.
- Keeps release publication outside the agent: the automation can only
create or update a draft prerelease.

## Validation Steps Performed

- `Invoke-Pester` for:
  - `.pipelines/tests/resolveBuildMetadata.Tests.ps1`
  - `.pipelines/tests/writeReleaseMetadata.Tests.ps1`
-
`.github/skills/release-note-generation/tests/preview-release.Tests.ps1`
- 37 tests passed, covering stable-branch preview intent, metadata
contracts, baseline selection, same-lineage and branch-transition
deltas, patch-ID equivalence, managed-body preservation, and
published-release refusal.
- Parsed all added or modified PowerShell scripts with the PowerShell
AST parser.
- Parsed the modified pipeline YAML files with `ConvertFrom-Yaml`.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85
Copilot-Session: e9f79ac2-9a7b-4083-834c-0d87e8c83bfd
Copilot-Session: 1ecea747-b313-49a1-9969-543c01ba1be8
2026-08-17 14:47:18 +08:00
Gleb Khmyznikov
e48152c52d [UITests] Add UITest.Next suites (Image Resizer, Peek, File Explorer add‑ons, File Locksmith) + local‑VM tooling and CI test‑signing (#49671)
## Summary

Adds end‑to‑end UI tests on the `Microsoft.PowerToys.UITest.Next`
(winappcli) framework for three
modules, grows the shared `.Next` test framework with the helpers those
suites needed, and adds the
CI plumbing that lets shell‑extension tests exercise the **real**
Windows 11 modern context menu.
Also ships two agent skills that document how to write and run these
tests.

Product runtime behavior is **unchanged** — the only product edits are
test‑observability hooks in Peek
and a unit‑test project exclude.

Closes: https://github.com/microsoft/PowerToys/issues/40660
https://github.com/microsoft/PowerToys/issues/49424
https://github.com/microsoft/PowerToys/issues/40661

## What's added

### New UI test suites
- **Image Resizer** —
`src/modules/imageresizer/tests/ImageResizer.UITests`: context‑menu
enable/disable
tracking, the resize dialog, custom presets, every fit mode, every unit,
filename format, keep‑date,
  shrink‑only, replace‑in‑place, and orientation.
- **Peek** — `src/modules/peek/Peek.UITests.Next`: file‑preview coverage
across image/text/archive/
  markdown types with per‑arch visual baselines.
- **File Explorer add‑ons** —
`src/modules/previewpane/PreviewPane.UITests`: Preview Pane handlers and
  thumbnail providers.

### `UITestAutomation.Next` framework
- New helpers: `ExplorerShell` (Shell selection/view‑mode interop),
`WaitHelper` (structured stable
waits), `WindowControl` (foreground/context‑menu/process control),
`VisualAssert` (image compare),
  `WindowHelper`.
- Updates to `Session`, `UITestBase`, `SettingsConfigHelper`,
`WinappCli`.
- New `UITestAutomation.Next.UnitTests` project covering the new
wait/settings/CLI helpers.

### CI — sign sparse MSIX so the modern menu registers
- **`.pipelines/signSparsePackages.ps1`** — self‑signs each sparse
context‑menu MSIX with a
publisher‑matching test certificate and force‑trusts it (machine
stores), so
`AddPackageByUriAsync` succeeds on otherwise‑unsigned PR builds. Robust
`signtool` discovery with a
  NuGet fallback; test‑only trust that asserts no security.
- Wired into **`.pipelines/v2/templates/job-test-project.yml`** as a
best‑effort step covering the
run‑in‑place, machine‑install, and per‑user‑install locations. Signs
nothing it can't (skips
  already‑signed packages) and never fails the job.

### Product changes (test observability only)
- **Peek `FilePreview.xaml` / `.xaml.cs`** — a named `LoadingIndicator`
and a hidden automation peer
that exposes the current preview state as text, so tests can read load
state deterministically. No
  runtime behavior change.
- **`ImageResizer.UnitTests.csproj`** — exclude the sibling
`ImageResizer.UITests\**` folder from the
  unit‑test compilation.

### Agent skills & docs
- **New `ui-tests-local-vm` skill** — run `.Next` suites in persistent
dockur/windows VMs: setup,
agentic loop, image customization, troubleshooting, the shell‑extension
**signing** reference, plus
  controller/guest scripts and VM templates.
- **Updated `ui-tests-migration` skill** — WinAppDriver/Selenium →
`.Next` porting guidance
(CI stability, Explorer/shell‑extension test design, patterns &
pitfalls).
- **`doc/devdocs/development/ui-tests.md`** — updated for the `.Next`
workflow.

## Testing
- All three suites pass locally and in CI across **x64 Win10**, **x64
Win11**, and **arm64** (machine
  and per‑user install legs).

## Reviewer notes
- No product runtime behavior changes; product edits are limited to the
Peek test hooks above.
- The CI signing step is a **test‑only** trust anchor (self‑signed,
scoped to the agent) and is
best‑effort, so it can only add modern‑menu coverage and never regress
the job.
2026-08-10 19:55:03 +02:00
Boliang Zhang
558e633c59 Add preview release versioning and update channel support (#49414)
## Summary
- Publish scheduled `main` builds as GitHub prereleases while keeping
manual `main` runs as preview validation builds.
- Add an opt-in Settings switch for prerelease update checks; stable
updates remain the default.
- Use one MSI-safe version across bundles, MSI packages, binaries,
symbols, and package manifests.
- Prevent preview releases from triggering Microsoft Store, WinGet, or
public-symbol publication.
- Label preview builds explicitly in Settings, update notifications, and
What's New.

## Build intent

| Source | Trigger | Intent |
| --- | --- | --- |
| `main` | Scheduled | Publish a preview release |
| `main` | Manual | Validate a preview build without publishing |
| `stable` | Manual | Produce a stable release |
| Other branches | Any supported trigger | Produce a private validation
build |

## MSI-safe release versioning

Windows Installer compares only `major.minor.build` and ignores the
fourth version component. Preview and stable release builds therefore
use:

```text
major.minor.YDDDB.0
```

- `Y`: zero-based number of calendar years since `ReleaseTrainEpoch`.
- `DDD`: three-position calendar day of year.
- `B`: daily release sequence `1-9`.
- The fourth component is always `0`.

With `ReleaseTrainVersion=0.100` and `ReleaseTrainEpoch=2026-01-01`:

```text
0.100.2111.0   = July 30, 2026, release build 1
0.100.3659.0   = December 31, 2026, release build 9
0.100.10011.0  = January 1, 2027, release build 1
```

The allocator formats `DDD` as exactly three digits before converting
the MSI component to its numeric representation. Leading zeros may not
be displayed because Windows version components are numeric; decoding
remains positional:

```text
B   = component % 10
DDD = (component / 10) % 1000
Y   = component / 10000
```

`ReleaseTrainVersion` and `ReleaseTrainEpoch` are checked in under
`src/Version.props`. The epoch remains January 1 of the active epoch
year and advances on the first release-train minor change in a new year.

## Daily release counter

Azure DevOps persists the daily sequence server-side using a counter
keyed as `release-YYYYMMDD`.

- `main` and `stable` share the same daily counter.
- Other branches do not evaluate or consume the release counter.
- Failed or canceled `main`/`stable` runs may leave gaps.
- The build fails when the daily sequence exceeds `9`.
- The counter date and encoded `YDDD` date both use
`pipeline.startTime`.

Private branches retain independent `0.0.<extended-day><NN>.0`
validation versions.

## Update behavior
- Stable users continue to query GitHub's stable latest-release path.
- Users who explicitly enable preview updates can select newer GitHub
prereleases.
- Preview releases and notifications are labeled as PowerToys Preview.
- What's New separates preview entries from stable release history and
hides previews by default.

## Validation
- 17 Pester tests cover `main`, `stable`, private branches, year
rollover, epoch reset, monotonicity, override validation, sequence
limits, and date alignment.
- Version propagation verified `0.100.2111.0` in `Version.props` and all
affected AppX/MSIX manifests.
- Azure DevOps pipeline dry-runs succeeded for both `refs/heads/main`
and `refs/heads/stable`.
- The affected native version project builds successfully.
- PR CI is green for x64, ARM64, Command Palette SDK, dependency review,
telemetry detection, and CLA.

## Remaining end-to-end checks
- Install two locally or officially produced installers with consecutive
MSI-visible `YDDDB` versions and verify the upgrade preserves binaries,
package registrations, hardlinks, and shell integrations.
- On the first natural post-merge `main` or `stable` run, verify the
production counter value and resolved version in the release logs.
## Local GPO verification

Validated locally with the signed `v0.100.2171` build from Azure DevOps
build
[153961073](https://microsoft.visualstudio.com/Dart/_build/results?buildId=153961073).
These checks cover the administrative-template integration and Settings
behavior.

### Policy enabled: preview updates are disabled

With `PreviewUpdatesDisabled=1`, **Include prerelease updates** is
forced off and locked, and Settings displays the
managed-by-your-organization notice.

![PowerToys Settings with preview updates disabled by
policy](https://raw.githubusercontent.com/LegendaryBlair/PowerToys/df808630b04e65ba437081aff9401c4efd58e67f/.github/pr-assets/49414/gpo-policy-enforced.png)

### Policy removed: the user preference is preserved

After removing `PreviewUpdatesDisabled` and restarting PowerToys, the
previously selected preview-update preference is restored and editable.
The policy suppresses the preference without overwriting it.

![PowerToys Settings with the preview-update preference
restored](https://raw.githubusercontent.com/LegendaryBlair/PowerToys/df808630b04e65ba437081aff9401c4efd58e67f/.github/pr-assets/49414/gpo-preference-restored.png)

### Group Policy Editor

After importing the updated ADMX/ADML templates, **Disable preview build
updates** appears under **Microsoft PowerToys > Installer and Updates**.
The policy dialog documents that **Enabled** blocks preview updates,
while **Disabled** or **Not Configured** leaves the choice available to
the user.

![Disable preview build updates in Local Group Policy
Editor](https://raw.githubusercontent.com/LegendaryBlair/PowerToys/e9e5c12f4480ef895d263460a59982246b7654dc/.github/pr-assets/49414/group-policy-editor-policy-dialog.png)

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: ad8b7909-0472-4464-bdee-deaeca726f94
Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85
2026-08-06 23:45:11 +08:00
moooyo
160492abcf docs(skills): recommend WindowEx for WinUI 3 migrations (#49303)
## Summary of the Pull Request

Updates the WPF-to-WinUI 3 migration skill to make the established
PowerToys windowing pattern explicit:

- Default WinUI 3 top-level windows to `WinUIEx.WindowEx` or an existing
PowerToys base derived from it, such as `TransparentWindow` for
transient overlays.
- Keep supported size, presenter, title bar, topmost, backdrop, and
persistence behavior declarative in XAML instead of manual `AppWindow` /
`OverlappedPresenter` code-behind.
- Document the centrally managed `<PackageReference Include="WinUIEx"
/>`, WPF-to-`WindowEx` property mappings, and existing repository
examples.
- Add a value-converter decision guide that prefers
`VisualStateManager`, direct `x:Bind` conversion, WinUI theme resources,
and `CommunityToolkit.WinUI.Converters` over mechanically porting WPF
converters.

This follows the migration-skill feedback from @niels9001 in [PR
#49174](https://github.com/microsoft/PowerToys/pull/49174#discussion_r3535181101).

## PR Checklist

- [x] **Communication:** This change follows review feedback from a core
contributor in PR #49174.
- [x] **Tests:** The updated guidance passed 5/5 fresh agent migration
scenarios.
- [x] **Dev docs:** Added/updated.

## Detailed Description of the Pull Request / Additional comments

`SKILL.md` now states the default PowerToys pattern and limits raw
`AppWindow` / presenter code to behavior that `WindowEx` does not
expose. The package mapping reference records the exact centrally
managed dependency. The windowing reference adds a complete XAML
example, a WPF-to-`WindowEx` mapping table, regular-window examples, and
the `TransparentWindow` overlay exception.

The XAML migration reference now also documents converter selection and
reuse: control state belongs in `VisualState`s, count visibility can
share one Toolkit `DoubleToVisibilityConverter` with
`ConverterParameter=True`, and corner-radius converter resources come
from `XamlControlsResources`.

This is an atomic documentation-only change; no product code or
dependencies are modified.

## Validation Steps Performed

- Verified the documented `WindowEx` APIs and `TransparentWindow`
inheritance against the repository and compiled WinUIEx assembly.
- Verified all cited repository paths, the Markdown anchor, and central
package management entry.
- Ran five fresh current-branch agent scenarios; all selected
`<PackageReference Include="WinUIEx" />` without a version, `WindowEx`,
XAML-declared properties, and `CenterOnScreen()` only where required.
- Ran a focused converter migration scenario before and after the
guidance update; the updated skill selected `VisualState`s, one reusable
Toolkit numeric converter, and existing WinUI corner-radius resources
without custom converters.
- Ran `git diff --check` with no errors.
- Completed an independent read-only review with no findings.
- Product builds and unit tests were not run because this change only
updates agent guidance.

---------

Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: fe9b24eb-99f0-43e8-aaa4-839f4579f6f9
Copilot-Session: d5afc36b-3356-46af-b8cb-071b87a64532
2026-07-31 16:28:38 +08:00
Gleb Khmyznikov
d5fe397b05 Follow-up: UITest framework Next - stability improvements (#49242)
This pull request addresses several CI flakiness and reliability issues
in the UI test automation harness, especially around foreground window
handling and build artifact resolution. The main improvements ensure
that UI interactions (like real mouse clicks) reliably target the
correct window, even in complex CI and build environments, and that test
code accurately locates module executables regardless of output layout.

**Foreground window handling and input reliability:**

* Added `Session.EnsureForeground()` and improved
`WindowControl.TryBringToForeground()` to reliably raise the target
window above others, defeating the Win32 foreground lock using
`AttachThreadInput` and related APIs. This prevents coordinate-based
clicks from landing on the wrong window, a common cause of CI test
flakiness. (`src/common/UITestAutomation.Next/Session.cs`,
`src/common/UITestAutomation.Next/WindowControl.cs`,
`src/common/UITestAutomation.Next/Element/Element.cs`,
`.github/skills/ui-tests-migration/references/ci-stability.md`,
`src/modules/MeasureTool/Tests/ScreenRuler.UITests.Next/TestHelper.cs`)
[[1]](diffhunk://#diff-713524f4ead9951000b3578248f2740088729981051b68c3fa3655ebb548f20fR91-R118)
[[2]](diffhunk://#diff-60be6ec24a99f8974cff00414fc47ea1e60e3ab9aee706b5d6845eb8df19165fR59-R76)
[[3]](diffhunk://#diff-60be6ec24a99f8974cff00414fc47ea1e60e3ab9aee706b5d6845eb8df19165fL247-R332)
[[4]](diffhunk://#diff-3c00581cb1d2b6a4302b8378b87c27cdad2f87c2aefc37eec0bdc6c39af9291aR100-R103)
[[5]](diffhunk://#diff-98e5aea12baaac99aba10e7dd341ed3f2efdd24cb80b29306bb500816de09e2fR96-R114)
[[6]](diffhunk://#diff-d8766b48614fe4a99e3f100e69e611ca2464de6ba0be257586c12d51f9278ed0L498-R504)

**Build artifact and executable path resolution:**

* Refactored `ModuleInfo.GetDevelopmentPath()` to dynamically walk up
from the test assembly and find the module executable in various build
output layouts, including CI artifacts and local builds. This eliminates
hardcoded path offsets and makes test launches robust to different build
structures. (`src/common/UITestAutomation/ModuleInfo.cs`)
* Updated `ModuleConfigData.GetModulePath()` to use the improved path
resolution and fall back to installed builds if necessary, ensuring that
test runs can always locate the correct executable.
(`src/common/UITestAutomation/ModuleConfigData.cs`)
* Simplified `SessionHelper` so that `locationPath` is always empty,
leveraging the fact that module paths are now absolute.
(`src/common/UITestAutomation/SessionHelper.cs`)
[[1]](diffhunk://#diff-c001f0fd3432c8b6102c3120597fc48f24902eaa0d755f51adfa7646344b3833L7-L10)
[[2]](diffhunk://#diff-c001f0fd3432c8b6102c3120597fc48f24902eaa0d755f51adfa7646344b3833L46-R54)

These changes collectively improve test reliability, especially in CI
environments, and make the harness more resilient to changes in build
output structure.

---------

Co-authored-by: Boliang Zhang (from Dev Box) <bozhang@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-09 20:57:18 -07:00
Gleb Khmyznikov
85f698677a [UITests] AI migration skill + ScreenRuler tests example port. (#48842)
This PR is build on top of
https://github.com/microsoft/PowerToys/pull/48717 and
https://github.com/microsoft/PowerToys/pull/48467

It adds the ui-tests-migration skill which should be used to migrate the
old UITest module by module to use new .Next UI framework.

As an example, the screen ruller tests was ported here.

---------

Co-authored-by: Boliang Zhang (from Dev Box) <bozhang@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-09 11:02:54 +08:00
Boliang Zhang
4395b1d0ca [skill] Generalize verification skill into 2 scenarios (module checklist / PR validation) (#48848)
## Summary of the Pull Request

Generalizes the `powertoys-verification` agent skill from "one module
checklist" into a **single shared engine that serves two verification
scenarios**, using the *shared engine + per-scenario reference docs*
design (no duplication of the winapp mechanics):

- **A — Module checklist**: verify a supplied module checklist against
the installed build.
- **B — PR validation**: derive each PR's checklist from its description
+ diff, then drive it. A single **bits sub-decision** picks the target —
drive the **installed** build when the PR's code is already shipped (a
merged PR, or a whole release/hotfix set, e.g. the 0.100.1 14-PR
sign-off), or **build + sideload** the affected module when it isn't (an
unmerged or not-yet-released PR, e.g. #45242).

Both scenarios share the same `winapp ui` drive techniques, helper
scripts, per-module profiles, taxonomy, and report format. They differ
mainly on **what bits you run**, so the only new content is a thin
scenario layer.

## PR Checklist

- [ ] **Closes:** N/A (follow-up to the merged `powertoys-verification`
skill)
- [x] **Communication:** design discussed and agreed before
implementation
- [x] **Tests:** N/A — docs/skill-only change; validated link/constraint
checks (see below)
- [x] **Localization:** N/A
- [x] **Dev docs:** this PR *is* skill documentation
- [x] **New binaries:** none

## Detailed Description of the Pull Request / Additional comments

**`SKILL.md` (shared engine)** — broaden `description` + "When to use"
to cover both scenarios, add a **Step-0 scenario router** (plus, for B,
the bits sub-decision "is the PR's code in the build under test?"), keep
the supplied-checklist read **Scenario-A-only**, and make the
bootstrap/placeholders/"What NOT to do" scenario-aware.

**`references/scenarios/`:**
- `index.md` — router table (A/B); the **"bits under test" contract**
(the one real conflict: installed-and-immutable, vs build-and-sideload
when the PR's code isn't in the build, echoed in the report header so
the evidence chain is trustworthy); and a verdict-vocabulary mapping
(engine `PASS/FAIL/BLOCKED` <-> legacy labels).
- `module-checklist.md` (A) — supplied checklist, installed bits.
- `pr-validation.md` (B, **new — merges the former release-PR and
active-PR docs**) — derive each PR's checklist from `gh pr view/diff`;
the **bits sub-decision**; a **PR-discovery model with a size gate**
(auto-verify hotfix-sized sets <=25; for full ~100-PR releases,
scope-and-confirm instead of blind-looping) and a non-runtime-PR
pre-filter; per-PR folders + roll-up; and the **build + sideload**
front-end (in-repo worktree helper + build commands), unpackaged (run
the built runner, dismiss the expected partial-build dialogs) vs
packaged/CmdPal (`Add-AppxPackage -Register`) deploy recipes,
prove-your-bits, and restore-to-shipped cleanup.

Removed the separate `release-pr-signoff.md` and
`active-pr-validation.md` (folded into `pr-validation.md`). The existing
engine docs (`winapp-ui-testing.md`, `pre-flight.md`,
`reporting-format.md`), per-module profiles, and helper scripts are
reused unchanged — single source of truth. The `BITS:` header version is
a `<version>` placeholder (not pinned to a release).

## Validation Steps Performed

- `SKILL.md` within authoring limits: **331 lines** (< 500) and
**description 999 chars** (< 1024).
- All relative markdown links in `references/scenarios/*.md` resolve,
and every engine doc they cite exists.
- Scenario B exercised end-to-end both ways: the 0.100.1 14-PR sign-off
(8 PASS / 6 BLOCKED, installed bits) and PR #45242 (Advanced Paste, 3/3
PASS, build + sideload).

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-08 14:53:38 -07:00
moooyo
d6319516d0 [Skills] Fix wpf-to-winui3-migration SKILL.md failing to load (#49059)
## Summary of the Pull Request

The `wpf-to-winui3-migration` agent skill failed to load. The
`description` field in its `SKILL.md` YAML frontmatter was an
**unquoted** plain scalar containing `Keywords: ` (a colon followed by a
space). YAML interprets `: ` as a mapping key/value separator, so the
skill loader failed with:

> failed to parse YAML frontmatter: mapping values are not allowed in
this context at line 2 column 651

Because `.claude/skills` is a symlink to `.github/skills`, the CLI
enumerates the same file twice, so this single defect surfaced as
**two** skill load errors (`skill_error_count: 2`).

Fix: wrap the `description` value in single quotes so the colon is
treated literally. No wording changes; the description stays 926
characters (well under the 1024 limit).

## PR Checklist

- [ ] Closes: #xxx — N/A, trivial metadata fix, no tracking issue
- [x] **Communication:** Metadata-only fix; no design discussion needed
- [ ] **Tests:** N/A — no test harness for skill frontmatter; validated
by YAML parsing (see below)
- [x] **Localization:** N/A — not end-user-facing
- [ ] **Dev docs:** N/A
- [ ] **New binaries:** N/A

## Detailed Description of the Pull Request / Additional comments

`.github/skills/wpf-to-winui3-migration/SKILL.md` line 3 changed from:

```yaml
description: Guide for migrating ... after migration. Keywords: WPF, WinUI, ... SoftwareBitmap.
```

to:

```yaml
description: 'Guide for migrating ... after migration. Keywords: WPF, WinUI, ... SoftwareBitmap.'
```

The three other top-level skills already quote (or avoid `: ` in) their
descriptions, so only this one was affected. Single quotes are used
because the description contains no quote characters, so no escaping is
required.

## Validation Steps Performed

- Reproduced the loader error from the Copilot CLI logs: `mapping values
are not allowed in this context at line 2 column 651`.
- Parsed the frontmatter of all 9 `SKILL.md` files with a YAML parser:
before = 1 failure (this file), after = **0 failures**.
- Confirmed parsed `name` (`wpf-to-winui3-migration`), `description`
(926 chars, ≤ 1024), and `license` are intact and the literal `Keywords:
WPF...` text is preserved.

Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-07-02 10:48:23 +08:00
Boliang Zhang
7e877558b9 Add powertoys-module-verification agent skill (#48717)
## Summary of the Pull Request

Adds a new **GitHub Copilot Agent Skill**,
`powertoys-module-verification`, under `.github/skills/`. It packages
the workflow, drive techniques, helper scripts, and per-module reference
data an AI agent uses to verify a single PowerToys module's
release-checklist items end-to-end (each checkbox → a structured PASS /
FAIL / BLOCKED verdict with evidence).

This is **docs/automation tooling only** — no product code, binaries, or
end-user strings are touched.

## PR Checklist

- [ ] Closes: #xxx
- [x] **Communication:** Internal tooling for release sign-off; happy to
adjust scope/placement based on review.
- [x] **Tests:** N/A — documentation/skill bundle only (no product code
paths). The 12 bundled `.ps1` helpers are agent utilities, not part of
the product build/test.
- [x] **Localization:** N/A — no end-user-facing strings.
- [x] **New binaries:** N/A — no binaries added.
- [x] **Dev docs:** This PR *is* developer-facing documentation/tooling.

## Detailed Description of the Pull Request / Additional comments

Layout follows the repo's Agent Skill guidelines
(`.github/instructions/agent-skills.instructions.md`) and matches the
existing skills under `.github/skills/`:

```
.github/skills/powertoys-module-verification/
├── SKILL.md            # single entry doc (name/description/license frontmatter)
├── LICENSE.txt         # Apache 2.0 (matches existing skills)
├── scripts/            # 12 PowerShell helper utilities used by the agent
└── references/
    ├── winapp-ui-testing.md         # UIA-mechanics prerequisite doc
    ├── pre-flight.md / reporting-format.md / environment-setup.md / explorer-context-menu-flow.md
    ├── modules/                     # per-module verification profiles
    └── release-checklist/           # per-module checklists + index
```

Notes for reviewers:
- **`references/winapp-ui-testing.md`** is adapted from the
`winui-ui-testing` skill in
[microsoft/win-dev-skills](https://github.com/microsoft/win-dev-skills)
(MIT, © Microsoft Corporation and Contributors), with PowerToys-specific
edits. Provenance is recorded in the file header. Its skill frontmatter
was intentionally stripped so it is treated as a reference doc, not a
separately-discovered skill.
- **Checklist scope:** only modules already verified end-to-end (with a
sign-off report) are included for now — Environment Variables, File
Locksmith, Image Resizer, New+, Peek, PowerRename. Remaining modules'
checklists will be added as each is verified.
- No existing files are modified; this is purely additive under
`.github/skills/`.

## Validation Steps Performed

- Validated the bundle against the Agent Skill checklist in
`.github/instructions/agent-skills.instructions.md`: valid `name` (≤64
chars) + `description` + `license` frontmatter; `SKILL.md` body under
the 500-line guidance; single `SKILL.md`; `scripts/` + `references/`
resource buckets; all resource references use relative paths.
- Verified internal cross-references resolve after the migration (no
stale `helpers/`, `Winapp-SKILL.md`, or absolute-path tokens;
`src/modules/...` source citations left intact).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-06-24 13:45:26 -07:00
moooyo
d221f84d8f [Skills] Update WinUI3 migration skills to add more migration mapping item (#47043)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist

- [x] Closes: #46464
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

---------

Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-06-18 12:17:49 +02:00
Boliang Zhang
3948fcc19d [release-notes skill] Use local agent for PR summaries; vendor prepare-release-assets.ps1 (#47651)
## Summary

Two related changes to the `release-note-generation` agent skill:

### 1. Step 3 reviews: use the local agent instead of
`mcp_github_request_copilot_review`

Step 3.1 previously instructed the agent to call
`mcp_github_request_copilot_review` for every milestone PR so that the
`CopilotSummary` column in `sorted_prs.csv` would be populated by the
GitHub-side Copilot bot.

When this skill is driven from a CLI / coding agent, that request comes
from a bot identity, and the GitHub API rejects it (`Bot reviewers
cannot be requested`). The PR ends up with no Copilot review and
`CopilotSummary` stays empty.

`references/step3-review-grouping.md` has been rewritten to instead have
**the local agent** that is running the skill perform the review itself:

- Fetch each PR's diff with a non-mutating tool
(`mcp_github_pull_request_read` `get_diff` / `get_files`, or `gh pr
diff`).
- Produce a 1-3 sentence user-facing summary in the same style as a
Copilot PR review.
- Write the summary directly into the `CopilotSummary` column of
`Generated Files/ReleaseNotes/sorted_prs.csv`, preserving row order and
skipping rows that already have a non-empty summary.

Step 3.2 (re-run `dump-prs-since-commit.ps1`) is demoted to optional,
with a note that re-running the dump will overwrite the
locally-generated summaries.

`SKILL.md` was updated to match: front-matter description, "When to
Use", workflow diagram, the 3.1-3.3 row in the summary table,
prerequisites (no longer requires "GitHub Copilot code review enabled
for the org/repo"; mentions MCP for fetching diffs), and the
troubleshooting row for empty `CopilotSummary` now points at Step 3.1
with the bot-rejection caveat.

### 2. Vendor `prepare-release-assets.ps1` into the skill

Added `scripts/prepare-release-assets.ps1` -- previously kept in
OneDrive at `Tools/prepare-release.ps1`. Renamed because the script does
more than download installers: it also pulls per-arch symbol archives,
computes SHA256, and emits the **Installer Hashes** markdown table for
the GitHub release page. "Release assets" captures all of that.

Header `.SYNOPSIS` / `.DESCRIPTION` / `.EXAMPLE` blocks were updated to
reflect the new filename and the symbol-archive behavior (the original
synopsis only mentioned installers).

`SKILL.md` registers the new script in the "Available Scripts" table,
lists Azure CLI + the `azure-devops` extension as a prerequisite (only
when running this script), adds a "Prepare GitHub release assets" entry
to "When to Use", and adds a troubleshooting row for the most common
failure (`Failed to acquire ADO access token` -> `az login`).

## Files changed

| File | Change |
|------|--------|
| `.github/skills/release-note-generation/SKILL.md` | Updated
description, prerequisites, workflow, scripts table, troubleshooting |
|
`.github/skills/release-note-generation/references/step3-review-grouping.md`
| Rewritten to use local-agent review; demoted refresh step |
|
`.github/skills/release-note-generation/scripts/prepare-release-assets.ps1`
| New (vendored from OneDrive) |

## Validation

- PowerShell parser ([`Parser]::ParseFile`) reports no errors on the new
script.
- Documentation-only / scripts-only change -- no product code touched,
so the standard PowerToys build / test gates do not apply.
- The change preserves the existing CSV schema (`Id, Title, Labels,
Author, Url, Body, CopilotSummary, NeedThanks`), so downstream Step 3.3
(`group-prs-by-label.ps1`) and Step 4 summarization continue to work
without modification.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-05-14 22:07:38 +08:00
Niels Laute
f8a10550f3 Update release notes skill (#47158)
Change the formatting from:

"PR description in #123. Thanks @user"

to

"PR description in #123 by @user"

----

this follows the GitHub release notes format and makes sure people are
correctly listed at the bottom of the release page
2026-04-24 10:56:32 +08:00
moooyo
7051b8939b [Skills] Add WPF to WinUI 3 migration agent skill (#46462)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
With this skills, we can easily enable AI to complete most of the tasks
involved in migrating from WPF to WinUI3.

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist

- [x] Closes: #46464
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

---------

Co-authored-by: Yu Leng <yuleng@microsoft.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-24 09:40:33 +00:00
Gordon Lam
eeeb6c0c93 feat(winmd-api-search): add WinMD cache generator script and related files (#45606)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request

Adds a new Copilot agent skill (`winmd-api-search`) that lets AI agents
discover and explore Windows desktop APIs by searching a local cache of
WinMD metadata. The skill covers Windows Platform SDK, WinAppSDK/WinUI,
NuGet package WinMDs, and project-output WinMDs — providing full API
surface details (types, members, enumeration values, namespaces) without
needing external documentation lookups.

**Key components:**

- `.github/skills/winmd-api-search/SKILL.md` — Skill definition with
usage instructions, search/detail workflows, and scoring guidance
- `scripts/Invoke-WinMdQuery.ps1` — PowerShell query engine supporting
actions: `search`, `type`, `members`, `enums`, `namespaces`, `stats`,
`projects`
- `scripts/Update-WinMdCache.ps1` — Orchestrator that builds the C#
cache generator, discovers project files, and runs the generator
- `scripts/cache-generator/CacheGenerator.csproj` + `Program.cs` — .NET
console app using `System.Reflection.Metadata` to parse WinMD files from
NuGet packages, project references, Windows SDK, and packages.config
into per-package JSON caches
- `scripts/cache-generator/Directory.Build.props`,
`Directory.Build.targets`, `Directory.Packages.props` — Empty isolation
files to prevent repo-level Central Package Management and build targets
from interfering with this standalone tool

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist

- [ ] Closes: #xxx <!-- Replace with issue number if applicable -->
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass — N/A: This is an offline
agent skill (PowerShell + standalone .NET tool) with no integration into
the main product build or runtime. Validated manually by running the
cache generator across multiple project contexts (ColorPickerUI,
CmdPal.UI, runner, ImageResizer, etc.) and exercising all query actions.
- [ ] **Localization:** All end-user-facing strings can be localized —
N/A: No end-user-facing strings; this is an internal developer/agent
tool
- [ ] **Dev docs:** Added/updated — The SKILL.md itself serves as the
documentation
- [ ] **New binaries:** Added on the required places — N/A: The cache
generator is a standalone dev-time tool, not shipped in the installer
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: N/A

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

### Cache Generator (`Program.cs`, ~1000 lines)

A self-contained .NET console app that:

1. **Discovers WinMD sources** from four channels:
   - `project.assets.json` (PackageReference — modern .csproj/.vcxproj)
   - `packages.config` (legacy NuGet format)
- `<ProjectReference>` bin/ output (class libraries producing `.winmd`)
   - Windows SDK `UnionMetadata/` (highest installed version)

2. **Parses WinMD files** using `System.Reflection.Metadata` /
`PEReader` to extract:
- Types (classes, structs, interfaces, enums, delegates) with full
namespace
- Members (methods with decoded signatures/parameters, properties with
accessors, events)
   - Enum values
   - Base types and type kinds

3. **Outputs per-package JSON** under `Generated Files/winmd-cache/`:
- `packages/<Id>/<Version>/meta.json` — package summary
(type/member/namespace counts)
   - `packages/<Id>/<Version>/namespaces.json` — ordered namespace list
- `packages/<Id>/<Version>/types/<Namespace>.json` — full type detail
per namespace
- `projects/<ProjectName>.json` — maps each project to its package set

4. **Deduplicates** at the package level — if a package+version is
already cached, it's skipped on subsequent runs.

### Build Isolation

Three empty MSBuild files (`Directory.Build.props`,
`Directory.Build.targets`, `Directory.Packages.props`) in the
cache-generator folder prevent the repo's Central Package Management and
shared build configuration from interfering with this standalone tool.

### Query Engine (`Invoke-WinMdQuery.ps1`)

Supports seven actions: `search` (fuzzy text search across
types/members), `type` (full detail for a specific type), `members`
(filtered members of a type), `enums` (enumeration values), `namespaces`
(list all namespaces), `stats` (cache statistics), and `projects` (list
cached projects with their packages).

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

1. **Cache generation:** Ran `Update-WinMdCache.ps1` across 310+ project
files in the repo — 8 packages parsed, 316 reused from cache, all
completed without errors
2. **Query testing on multiple projects:**
   - `ColorPickerUI` — verified Windows SDK baseline (7,023 types)
- `Microsoft.CmdPal.UI.ViewModels` (after restore) — verified 13
packages, 49,799 types, 112,131 members including WinAppSDK,
AdaptiveCards, CsWinRT, Win32Metadata
   - `runner` (C++ vcxproj) — verified packages.config fallback path
   - `ImageResizerExt` — verified project reference WinMD discovery
3. **All seven query actions validated:** `stats`, `search`,
`namespaces`, `type`, `enums`, `members`, `projects` — all returned
correct results
4. **Spell-check compliance:** SKILL.md vocabulary reviewed against
repo's check-spelling dictionaries; replaced flagged words with standard
alternatives

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-03-11 10:15:32 +08:00
Kai Tao
d28f312b81 Copilot Skills: Release note generation skill should also quote co-authors (#45819)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request

Release note generation skill add support for quoting co-authors

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist

- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

Result may vary because of uncertainty of LLM, while I can get this
result during my tests

<img width="696" height="147" alt="image"
src="https://github.com/user-attachments/assets/9d20670f-b9fb-4630-b6b4-f94c2a5d2284"
/>
2026-03-04 16:40:08 +08:00
Gordon Lam
5422bc31bb docs(prompts): Enhance release notes generation and implement GitHub issue tools (#44762)
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This update improves the release notes generation process by
restructuring documentation for clarity and enhancing workflows. It
introduces new tools for handling GitHub issue images and attachments,
along with automated tests to ensure functionality.

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist

- [ ] Closes: N/A
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [x] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [x] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: N/A

<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
The changes include updates to the release notes summarization process
and workflow documentation for better clarity. New scripts for managing
PR diffs, grouping, and milestone assignments have been added.
Additionally, tools for downloading images and attachments from GitHub
issues have been implemented, ensuring a more streamlined process.

<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Automated tests were added for the new GitHub issue tools, and all tests
passed successfully. Manual validation included testing the new
workflows and ensuring the documentation accurately reflects the changes
made.
```
2026-01-21 16:18:57 +08:00