docs(spelling): clarify guidelines for resolving check-spelling comments

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

@@ -6,13 +6,45 @@ description: 'Generate an 80-character git commit title for the local diff'
 
 # Generate Commit Title
 
-**Goal:** Provide a ready-to-paste git commit title (<= 80 characters) that captures the most important local changes since `HEAD`.
+## Purpose
+Provide a single-line, ready-to-paste git commit title (<= 80 characters) that reflects 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`.
+## Input to collect
+- Run exactly one command to view the local diff:
+  ```@terminal
+  git diff HEAD
+  ```
+
+## How to decide the title
+1. From the diff, find the dominant area (e.g., `src/modules/*`, `doc/devdocs/**`) and the change type (bug fix, docs update, config tweak).
+2. Draft an imperative, plain-ASCII title that:
+   - Mentions the primary component when obvious (e.g., `FancyZones:` or `Docs:`)
+   - Stays within 80 characters and has no trailing punctuation
+
+## Final output
+- Reply with only the commit title on a single line—no extra text.
+
+## PR title convention (when asked)
+Use Conventional Commits style:
+
+`<type>(<scope>): <summary>`
+
+**Allowed types**
+- feat, fix, docs, refactor, perf, test, build, ci, chore
+
+**Scope rules**
+- Use a short, PowerToys-focused scope (one word preferred). Common scopes:
+  - Core: `runner`, `settings-ui`, `common`, `docs`, `build`, `ci`, `installer`, `gpo`, `dsc`
+  - Modules: `fancyzones`, `powerrename`, `awake`, `colorpicker`, `imageresizer`, `keyboardmanager`, `mouseutils`, `peek`, `hosts`, `file-locksmith`, `screen-ruler`, `text-extractor`, `cropandlock`, `paste`, `powerlauncher`
+- If unclear, pick the closest module or subsystem; omit only if unavoidable
+
+**Summary rules**
+- Imperative, present tense (“add”, “update”, “remove”, “fix”)
+- Keep it <= 72 characters when possible; be specific, avoid “misc changes”
+
+**Examples**
+- `feat(fancyzones): add canvas template duplication`
+- `fix(mouseutils): guard crosshair toggle when dpi info missing`
+- `docs(runner): document tray icon states`
+- `build(installer): align wix v5 suffix flag`
+- `ci(ci): cache pipeline artifacts for x64`

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

@@ -22,3 +22,4 @@ description: 'Generate a PowerToys-ready pull request description from the local
 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.
+8. Prepend the PR title above the filled template, applying the Conventional Commit type/scope rules from `.github/prompts/create-commit-title.prompt.md`; pick the dominant component from the diff and keep the title concise and imperative.

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

@@ -10,8 +10,8 @@ description: 'Resolve Code scanning / check-spelling comments on the active PR'
 
 **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.
+- Prefer improving the wording in the originally flagged file when it clarifies intent without changing meaning; if the wording is already clear/standard for the context, handle it via `.github/actions/spell-check/expect.txt` and reuse existing entries.
+- Limit edits to the flagged text and `.github/actions/spell-check/expect.txt`; leave all other files and topics untouched.
 
 **Prerequisites:**
 - Install GitHub CLI if it is not present: `winget install GitHub.cli`.
@@ -20,5 +20,6 @@ description: 'Resolve Code scanning / check-spelling comments on the active PR'
 **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.
+3. For each flagged token, first consider tightening or rephrasing the original text to avoid the false positive while keeping the meaning intact; if the existing wording is already normal and professional for the context, proceed to allowlisting instead of changing it.
+4. When allowlisting, 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.
+5. Add any remaining missing token to `.github/actions/spell-check/expect.txt`, keeping surrounding formatting intact.

.vscode/settings.json

@@ -0,0 +1,17 @@
+{
+    "github.copilot.chat.reviewSelection.instructions": [
+        {
+            "file": ".github/prompts/review-pr.prompt.md"
+        }
+    ],
+    "github.copilot.chat.commitMessageGeneration.instructions": [
+        {
+            "file": ".github/prompts/create-commit-title.prompt.md"
+        }
+    ],
+    "github.copilot.chat.pullRequestDescriptionGeneration.instructions": [
+        {
+            "file": ".github/prompts/create-pr-summary.prompt.md"
+        }
+    ]
+}