Update Copilot guidance and PR prompt workflow (This PR summary and commit are generated accordingly) (#42634)

## Summary of the Pull Request
- Added new Copilot agent prompts in
`.github/prompts/create-commit-title.prompt.md`,
`.github/prompts/create-pr.prompt.md`, and
`.github/prompts/fix-spelling.prompt.md` to streamline contributor
workflows.
- Refreshed `.github/copilot-instructions.md` with front matter and
clarified build/test guidance.
And added a new section titled `Language Style Rules` to help reduce
style issues in auto-generated code.

## Screenshot
a. For the new prompts, in VSCode, just type "/" and its name
<img width="477" height="124" alt="image"
src="https://github.com/user-attachments/assets/37c7330d-6fdc-45b4-9030-95920920c964"
/>
<img width="446" height="105" alt="image"
src="https://github.com/user-attachments/assets/55d3bb49-46cc-4441-9fb5-fed3a22983d9"
/>
b. All the spelling check problem, PR description, Commit title, are
generated and fixed by above prompts as demonstration (Except this
section)

## PR Checklist
- [x] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [x] **Tests:** N/A on doc updates.
- [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: #xxx (N/A)

## Detailed Description of the Pull Request / Additional comments
- Introduced prompt definitions so local tooling can generate commit
titles, PR descriptions, and resolve spell-check alerts using consistent
instructions.
- Added GitHub CLI prerequisites inside
`.github/prompts/fix-spelling.prompt.md` to ensure `gh` commands succeed
for new contributors.
- Converted `.github/copilot-instructions.md` to YAML-front-matter
format while aligning headings and terminology with current contributor
guidance.

## Validation Steps Performed
- No automated tests were run; changes are documentation and
configuration only.

.github/actions/spell-check/expect.txt

@@ -94,6 +94,7 @@ ASSOCSTR
 ASYNCWINDOWPLACEMENT
 ASYNCWINDOWPOS
 atl
+ATX
 ATRIOX
 aumid
 Authenticode
@@ -113,6 +114,7 @@ azman
 bbwe
 BCIE
 bck
+backticks
 BESTEFFORT
 bezelled
 bhid
@@ -268,6 +270,7 @@ countof
 covrun
 cpcontrols
 cph
+cppcoreguidelines
 cplusplus
 CPower
 cpptools

.github/copilot-instructions.md

@@ -1,43 +1,59 @@
-# PowerToys – Copilot guide (concise)
+---
+description: PowerToys AI contributor guidance.
+applyTo: pullRequests
+---
+
+# PowerToys - Copilot guide (concise)
 
 This is the top-level guide for AI changes. Keep edits small, follow existing patterns, and cite exact paths in PRs.
 
-Repo map (1‑line per area)
+# Repo map (1-line per area)
 - Core apps: `src/runner/**` (tray/loader), `src/settings-ui/**` (Settings app)
 - Shared libs: `src/common/**`
 - Modules: `src/modules/*` (one per utility; Command Palette in `src/modules/cmdpal/**`)
 - Build tools/docs: `tools/**`, `doc/devdocs/**`
 
-Build and test (defaults)
+# Build and test (defaults)
 - Prerequisites: Visual Studio 2022 17.4+, minimal Windows 10 1803+.
 - Build discipline:
-  - One terminal per operation (build → test). Don’t switch/open new ones mid-flow.
+  - One terminal per operation (build -> test). Do not switch or open new ones mid-flow.
   - After making changes, `cd` to the project folder that changed (`.csproj`/`.vcxproj`).
-  - Use script(s) to build, synchronously block and wait in foreground for it to finish: `tools/build/build.ps1|.cmd` (current folder), `build-essentials.*` (once per brand new build for missing nuget packages)
-  - Treat build **exit code 0** as success; any non-zero exit code is a failure, have Copilot read the errors log in the build folder (e.g., `build.*.*.errors.log`) and surface problems.
-  - Don’t start tests or launch Runner until the previous step succeeded.
-- Tests (fast + targeted):
-  - Find the test project by product code prefix (e.g., FancyZones, AdvancedPaste). Look for a sibling folder or 1–2 levels up named like `<Product>*UnitTests` or `<Product>*UITests`.
-  - Build the test project, wait for **exit**, then run only those tests via VS Test Explorer or `vstest.console.exe` with filters. Avoid `dotnet test` in this repo.
-  - Add/adjust tests when changing behavior; if skipped, state why (e.g., comment-only, string rename).
+  - Use scripts to build, synchronously block and wait in foreground for completion: `tools/build/build.ps1|.cmd` (current folder), `build-essentials.*` (once per brand new build for missing nuget packages).
+  - Treat build exit code 0 as success; any non-zero exit code is a failure. Read the errors log in the build folder (such as `build.*.*.errors.log`) and surface problems.
+  - Do not start tests or launch Runner until the previous step succeeded.
+- Tests (fast and targeted):
+  - Find the test project by product code prefix (for example FancyZones, AdvancedPaste). Look for a sibling folder or one to two levels up named like `<Product>*UnitTests` or `<Product>*UITests`.
+  - Build the test project, wait for exit, then run only those tests via VS Test Explorer or `vstest.console.exe` with filters. Avoid `dotnet test` in this repo.
+  - Add or adjust tests when changing behavior; if skipped, state why (for example comment-only or string rename).
 
-Pull requests (expectations)
-- Atomic: one logical change; no drive‑by refactors.
-- Describe: problem / approach / risk / test evidence.
+# Pull requests (expectations)
+- Atomic: one logical change; no drive-by refactors.
+- Describe: problem, approach, risk, test evidence.
 - List: touched paths if not obvious.
 
-When to ask for clarification
+# When to ask for clarification
 - Ambiguous spec after scanning relevant docs (see below).
-- Cross-module impact (shared enum/struct) not clear.
-- Security / elevation / installer changes.
+- Cross-module impact (shared enum or struct) not clear.
+- Security, elevation, or installer changes.
 
-Logging (use existing stacks)
-- C++: `src/common/logger/**` (`Logger::info|warn|error|debug`). Keep hot paths quiet (hooks, tight loops).
-- C#: `ManagedCommon.Logger` (`LogInfo|LogWarning|LogError|LogDebug|LogTrace`). Some UIs use injected `ILogger` via `LoggerInstance.Logger`.
+# Logging (use existing stacks)
+- C++ logging lives in `src/common/logger/**` (`Logger::info`, `Logger::warn`, `Logger::error`, `Logger::debug`). Keep hot paths quiet (hooks, tight loops).
+- C# logging goes through `ManagedCommon.Logger` (`LogInfo`, `LogWarning`, `LogError`, `LogDebug`, `LogTrace`). Some UIs use injected `ILogger` via `LoggerInstance.Logger`.
 
-Docs to consult
+# Docs to consult
 - `tools/build/BUILD-GUIDELINES.md`
-- `doc/devdocs/core/architecture.md`, `doc/devdocs/core/runner.md`, `doc/devdocs/core/settings/readme.md`, `doc/devdocs/modules/readme.md`
+- `doc/devdocs/core/architecture.md`
+- `doc/devdocs/core/runner.md`
+- `doc/devdocs/core/settings/readme.md`
+- `doc/devdocs/modules/readme.md`
 
-Done checklist (self review before finishing)
-- Build clean? Tests updated/passed? No unintended formatting? Any new dependency? Documented skips?
+# Language style rules
+- Always enforce repo analyzers: root `.editorconfig` plus any `stylecop.json`.
+- C# code follows StyleCop.Analyzers and Microsoft.CodeAnalysis.NetAnalyzers.
+- C++ code honors `.clang-format` plus `.clang-tidy` (modernize/cppcoreguidelines/readability).
+- Markdown files wrap at 80 characters and use ATX headers with fenced code blocks that include language tags.
+- YAML files indent two spaces and add comments for complex settings while keeping keys clear.
+- PowerShell scripts use Verb-Noun names and prefer single-quoted literals while documenting parameters and satisfying PSScriptAnalyzer.
+
+# Done checklist (self review before finishing)
+- Build clean? Tests updated or passed? No unintended formatting? Any new dependency? Documented skips?

.github/prompts/create-commit-title.prompt.md

@@ -0,0 +1,16 @@
+---
+mode: 'agent'
+model: GPT-5-Codex (Preview)
+description: 'Generate an 80-character git commit title for the local diff.'
+---
+
+**Goal:** Provide a ready-to-paste git commit title (<= 80 characters) that captures the most important local changes since `HEAD`.
+
+**Workflow:**
+1. Run a single command to view the local diff since the last commit:
+   ```@terminal
+   git diff HEAD
+   ```
+2. From that diff, identify the dominant area (reference key paths like `src/modules/*`, `doc/devdocs/**`, etc.), the type of change (bug fix, docs update, config tweak), and any notable impact.
+3. Draft a concise, imperative commit title summarizing the dominant change. Keep it plain ASCII, <= 80 characters, and avoid trailing punctuation. Mention the primary component when obvious (for example `FancyZones:` or `Docs:`).
+4. Respond with only the final commit title on a single line so it can be pasted directly into `git commit`.

.github/prompts/create-pr-summary.prompt.md

@@ -0,0 +1,22 @@
+---
+mode: 'agent'
+model: GPT-5-Codex (Preview)
+description: 'Generate a PowerToys-ready pull request description from the local diff.'
+---
+
+**Goal:** Produce a ready-to-paste PR title and description that follows PowerToys conventions by comparing the current branch against a user-selected target branch.
+
+**Repo guardrails:**
+- Treat `.github/pull_request_template.md` as the single source of truth; load it at runtime instead of embedding hardcoded content in this prompt.
+- Preserve section order from the template but only surface checklist lines that are relevant for the detected changes, filling them with `[x]`/`[ ]` as appropriate.
+- Cite touched paths with inline backticks, matching the guidance in `.github/copilot-instructions.md`.
+- Call out test coverage explicitly: list automated tests run (unit/UI) or state why they are not applicable.
+
+**Workflow:**
+1. Determine the target branch from user context; default to `main` when no branch is supplied.
+2. Run `git status --short` once to surface uncommitted files that may influence the summary.
+3. Run `git diff <target-branch>...HEAD` a single time to review the detailed changes. Only when confidence stays low dig deeper with focused calls such as `git diff <target-branch>...HEAD -- <path>`.
+4. From the diff, capture impacted areas, key file changes, behavioral risks, migrations, and noteworthy edge cases.
+5. Confirm validation: list tests executed with results or state why tests were skipped in line with repo guidance.
+6. Load `.github/pull_request_template.md`, mirror its section order, and populate it with the gathered facts. Include only relevant checklist entries, marking them `[x]/[ ]` and noting any intentional omissions as "N/A".
+7. Present the filled template inside a fenced ```markdown code block with no extra commentary so it is ready to paste into a PR, clearly flagging any placeholders that still need user input.

.github/prompts/fix-spelling.prompt.md

@@ -0,0 +1,22 @@
+---
+mode: 'agent'
+model: GPT-5-Codex (Preview)
+description: 'Resolve Code scanning / check-spelling comments on the active PR.'
+---
+
+**Goal:** Clear every outstanding GitHub pull request comment created by the `Code scanning / check-spelling` workflow by explicitly allowing intentional terms.
+
+**Guardrails:**
+- Update only discussion threads authored by `github-actions` or `github-actions[bot]` that mention `Code scanning results / check-spelling`.
+- Resolve findings solely by editing `.github/actions/spell-check/expect.txt`; reuse existing entries.
+- Leave all other files and topics untouched.
+
+**Prerequisites:**
+- Install GitHub CLI if it is not present: `winget install GitHub.cli`.
+- Run `gh auth login` once before the first CLI use.
+
+**Workflow:**
+1. Determine the active pull request with a single `gh pr view --json number` call (default to the current branch).
+2. Fetch all PR discussion data once via `gh pr view --json comments,reviews` and filter to check-spelling comments authored by `github-actions` or `github-actions[bot]` that are not minimized; when several remain, process only the most recent comment body.
+3. For each flagged token, review `.github/actions/spell-check/expect.txt` for an equivalent term (for example an existing lowercase variant); when found, reuse that normalized term rather than adding a new entry, even if the flagged token differs only by casing. Only add a new entry after confirming no equivalent already exists.
+4. Add any remaining missing token to `.github/actions/spell-check/expect.txt`, keeping surrounding formatting intact.