Files
PowerToys/doc/devdocs
Niels Laute 57b01a1c4e Add issue triage actions (#49828)
## Summary of the Pull Request

Replaces the retired GitHub Models-based automatic issue triage and
deduplication flows with the GitHub Agentic Workflow proven in the
`niels9001/powertoys-ai-triage-sandbox`.

This PR also:

- aligns `Needs-Author-Feedback` closure to 7 days for issues and PRs;
- removes the automatic GitHub Models issue/PR labeler;
- removes the automatic GitHub Models new-issue deduplicator;
- removes the Azure Pipelines XAML Styler verification step while
retaining the
  local styling script.

This is a draft because production rollout still requires the
appropriate
privacy and Responsible AI reviews.

## Issue triage rules

### Triggers and refresh behavior

- Runs when an issue is opened, edited, or reopened.
- Runs when the issue author attaches a `PowerToysReport_*.zip` in a
comment.
- Maintainers can force regeneration with `/triage refresh`.
- Ignores unrelated comments, unchanged issue edits, PR comments, and
  bot-initiated reopens.
- Uses per-issue concurrency so a newer run supersedes an older run.
- Maintains one canonical triage comment instead of adding repeated bot
  comments.

### Comment format

- Separates **For the issue author** from **For the PowerToys team**.
- Mentions the author once and lists each requested action as a bullet.
- Distinguishes blocking **Needed** actions from non-blocking
**Recommended**
  actions.
- Shows the product, issue kind, reported PowerToys version, concise
summary,
  diagnostic findings, possible duplicates, and collapsed investigation
  checks.
- Ends with a short disclosure that triage is AI-assisted and
maintainers make
  final decisions.

### Classification and labels

- Detects PowerToys bug-template issues deterministically.
- Reads the selected product area and adds a matching primary
`Product-*`
  label.
- Handles production aliases such as FancyZones Editor and File Explorer
  preview/thumbnail areas.
- Product labeling is additive: existing product and maintainer labels
are
  never removed.
- Normalizes the reported PowerToys version and adds a matching version
label
  when one exists.
- Applies `Needs-Author-Feedback` only when blocking information or an
English
  translation is required.
- Removes `Needs-Author-Feedback` when the issue becomes actionable.

### PowerToys version rule

- Compares the reported version with the latest stable PowerToys GitHub
  release.
- Older versions receive a recommended update-and-retest action.
- Current versions, newer preview/dev versions, missing versions, and
release
  lookup failures are not flagged as outdated.
- Updating is advisory and does not block triage by itself.

### Reproduction rule

- Concrete actions plus an observed result are sufficient.
- Concise steps can use the separate Actual Behavior section as the
observed
  result.
- Passive or intermittent failures are sufficient when the
timing/trigger and
  observed failure are clear.
- Vague statements without an actionable scenario remain insufficient.
- Clearly non-English steps are not treated as missing; reproduction is
  reassessed after the author translates the issue.

### Language rule

- Classifies author-written prose as English, non-English, or uncertain.
- Ignores template headings, code, logs, filenames, URLs, hidden
comments, and
  quoted text.
- Clearly non-English issues ask the author to translate the title and
  description to English.
- Short, mixed, code-heavy, or uncertain text is not flagged.

### Diagnostic report rule

- A report is **required** for diagnostic-heavy failures: crashes,
hangs,
startup/load failures, installation/update failures, performance
failures,
  and service/driver/shell-integration failures.
- A report is **optional** for clear reproducible UI/visual defects.
- A report is **recommended**, but not blocking, for other actionable
bugs.
- Missing or rejected reports block only when the deterministic
requirement is
  `REQUIRED`.

### Diagnostic report privacy and safety

- Accepts only PowerToys report attachment URLs matching the expected
pattern.
- Enforces archive size, decompressed size, file-count, per-file, path
  traversal, and encryption limits.
- Selects only bounded relevant metadata and product-log evidence.
- Redacts email addresses, IP addresses, user paths, URLs, GUIDs, SIDs,
  identity fields, tokens, secrets, and passwords.
- Sends only the sanitized evidence to Copilot.
- Never sends the raw ZIP or extracted files to Copilot, logs,
artifacts, or
  repository storage.
- Deletes the temporary archive after processing.

### Duplicate rule

- Searches only older issues using focused product, title/body, and
exact
  technical-signal queries.
- Ranks candidates deterministically before Copilot runs.
- Copilot judges only the supplied candidates and returns at most five
  high-confidence matches.
- Similar product area alone is not enough; the underlying request or
failure
  must match.
- The model never closes an issue directly.
- The workflow submits the strongest match as a native GitHub
duplicate-close
  suggestion.
- **When a maintainer accepts the suggestion, GitHub automatically
closes the
  issue as a duplicate and links it to the selected canonical issue.**
- Declining the suggestion leaves the issue open.
- A defensive safeguard reopens the issue and fails the run if GitHub
applies
  the close without holding it for review.

### AI cost and permission controls

- Uses the `small` model alias.
- Maximum 5 turns and 10 AI credits per run.
- Maximum 300 AI credits per day.
- Maximum 5 runs per user per 60-minute window.
- Content hashing skips unchanged work before inference.
- The agent receives only `contents: read`, `issues: read`, and
  `copilot-requests: write`.
- A separate validated safe-output job receives `issues: write`.

## Seven-day author-feedback lifecycle

The existing Microsoft GitHub Policy Service configuration remains
responsible
for stale closure:

- Open issues with `Needs-Author-Feedback` and no activity for 7 days
are
  closed with an explanatory comment.
- Open PRs with `Needs-Author-Feedback` and no activity for 7 days are
closed
  with an explanatory comment.
- An author comment removes `Needs-Author-Feedback` and returns the
issue/PR to
  team triage.
- An author push removes `Needs-Author-Feedback` from a PR.
- Manually removing the label immediately makes the issue or PR
ineligible for
  scheduled closure.

## Deprecated automation

- Deletes `.github/workflows/automatic-issue-deduplication.yml`.
- Deletes `.github/workflows/auto-labeler.yml`.
- Automatic PR product labeling from the old Models workflow is
intentionally
not replaced in this PR; a production PR ownership/path map should be
agreed
  separately.
- Keeps the manual batch deduplication workflow unchanged.
- Removes the passive XAML Styler verification step from
  `.pipelines/v2/templates/job-build-project.yml`.
- Keeps `.pipelines/applyXamlStyling.ps1` available for local developer
use.

## Validation Steps Performed

- Compiled `.github/workflows/issue-triage.md` with `gh aw compile`.
- Ran 32 focused Python tests for issue parsing, duplicate retrieval,
version
checks, reproduction rules, language signals, archive validation, report
  selection, redaction, and output privacy.
- Parsed the changed workflow and resource-management YAML.
- Verified the required production labels exist.
- Tested the workflow against the latest 20 PowerToys issues in the
sandbox;
  all 20 produced one canonical comment.
- Verified live variants for outdated versions, intermittent/passive
reproduction, non-English issues, rejected and analyzed reports,
optional UI
  reports, and title-only issues.

## PR Checklist

- [ ] **Communication:** Discussed with core contributors.
- [x] **Tests:** Added/updated and all focused tests pass.
- [ ] **Privacy / Responsible AI:** Complete required production reviews
before
  enabling.
- [x] **Localization:** No product UI strings are added.
- [x] **Dev docs:** Updated repository automation documentation.
- [x] **New binaries:** None.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 18a9b8ad-fd7e-4b9d-a06c-5e350bcde9d7
Copilot-Session: fd512b9b-db6f-4004-a65b-aa49404d568d
2026-08-14 14:57:02 +08:00
..
2026-05-21 17:27:52 +02:00
2026-08-14 14:57:02 +08:00
2023-03-21 10:27:29 +01:00

PowerToys Developer Documentation

Welcome to the PowerToys developer documentation. This documentation provides information for developers who want to contribute to PowerToys or understand how it works.

Getting Started

Prerequisites

  1. Windows 10 April 2018 Update (version 1803) or newer
  2. Visual Studio 2026 (recommended) or Visual Studio 2022 17.4+ with the following workloads/components:
    • Desktop Development with C++
    • WinUI application development
    • .NET desktop development
    • Windows 11 SDK (10.0.22621.0)
    • Windows 11 SDK (10.0.26100.3916)
  3. .NET 8 SDK
  4. Enable long paths in Windows (see Enable Long Paths for details)

Tip: You can install Visual Studio with all required workloads automatically using the WinGet configuration files in the repository:

winget configure .config\configuration.winget

Pick the file that matches your VS edition (e.g., configuration.vsProfessional.winget or configuration.vsEnterprise.winget).

Fork, Clone, and Set Up

  1. Fork the repo on GitHub if you haven't already
  2. Clone your fork locally
  3. Run the automated setup script (recommended):
.\tools\build\setup-dev-environment.ps1

This script will:

  • Enable Windows long path support (requires administrator privileges)
  • Enable Windows Developer Mode (requires administrator privileges)
  • Guide you through installing required Visual Studio components from .vsconfig
  • Initialize git submodules

Run with -Help to see all available options.

Manual setup (if you prefer not to use the script)

Install Visual Studio dependencies

  1. Open the PowerToys.slnx file.
  2. If you see a dialog that says install extra components in the solution explorer pane, click install

Alternatively, import the .vsconfig file from the repository root using Visual Studio Installer to install all required workloads.

Initialize submodules

This is a one-time step required before you can compile most parts of PowerToys.

  1. Open a terminal
  2. Navigate to the folder you cloned PowerToys to.
  3. Run git submodule update --init --recursive

Building

Using Visual Studio

  • Open PowerToys.slnx in Visual Studio.
  • In the Solutions Configuration drop-down menu select Release or Debug.
  • From the Build menu choose Build Solution, or press Control+Shift+b on your keyboard.
  • The build process may take several minutes depending on your computer's performance. Once it completes, the PowerToys binaries will be in your repo under x64\Release\.
    • You can run x64\Release\PowerToys.exe directly without installing PowerToys, but some modules (i.e. PowerRename, ImageResizer, File Explorer extension etc.) will not be available unless you also build the installer and install PowerToys.

Using Command Line

You can also build from the command line using the provided scripts in tools\build\:

# Build the full solution (auto-detects platform)
.\tools\build\build.ps1

# Build with specific configuration
.\tools\build\build.ps1 -Platform x64 -Configuration Release

# Build only essential projects (runner + settings) for faster iteration
.\tools\build\build-essentials.ps1

# Build everything including the installer (Release only)
.\tools\build\build-installer.ps1

Debugging

See Debugging for detailed debugging techniques, including Visual Studio setup, attaching to child processes, and troubleshooting build errors.

Creating a New PowerToy

See Creating a New PowerToy for an end-to-end guide covering module architecture, settings integration, installer packaging, and testing.

Building Command Palette Extensions

If you want to build your own extensions for Command Palette, check out the Command Palette extensibility documentation. It covers how to create, package, and distribute custom extensions that integrate with Command Palette.

Development Guidelines

Rules

  • Follow the pattern of what you already see in the code.
  • Coding style.
  • Try to package new functionality/components into libraries that have nicely defined interfaces.
  • Package new functionality into classes or refactor existing functionality into a class as you extend the code.
  • When adding new classes/methods/changing existing code, add new unit tests or update the existing tests.

GitHub Workflow

  • Before starting to work on a fix/feature, make sure there is an open issue to track the work.
  • Add the In progress label to the issue, if not already present. Also add a Cost-Small/Medium/Large estimate and make sure all appropriate labels are set.
  • If you are a community contributor, you will not be able to add labels to the issue; in that case just add a comment saying that you have started work on the issue and try to give an estimate for the delivery date.
  • If the work item has a medium/large cost, using the markdown task list, list each sub item and update the list with a check mark after completing each sub item.
  • Before opening a PR, ensure your changes build successfully locally and functionality tests pass. This is especially important for AI-assisted (vibe coding) contributions—always verify AI-generated code works as intended. Exploratory PRs or draft PRs for discussion are exceptions.
  • When opening a PR, follow the PR template.
  • When you'd like the team to take a look (even if the work is not yet fully complete) mark the PR as 'Ready For Review' so that the team can review your work and provide comments, suggestions, and request changes. It may take several cycles, but the end result will be solid, testable, conformant code that is safe for us to merge.
  • When the PR is approved, let the owner of the PR merge it. For community contributions, the reviewer who approved the PR can also merge it.
  • Use the Squash and merge option to merge a PR. If you don't want to squash it because there are logically different commits, use Rebase and merge.
  • Close issues automatically when referenced in a PR. You can use closing keywords in the body of the PR to have GitHub automatically link your PR to the issue.

Core Architecture

Common Components

  • Context Menu Handlers - How PowerToys implements and registers Explorer context menu handlers
  • Monaco Editor - How PowerToys uses the Monaco code editor component across modules

Tools

Processes

Other Resources

Building the Installer

Our installer is two parts, an EXE and an MSI. The EXE (Bootstrapper) contains the MSI and handles more complex installation logic.

  • The EXE installs all prerequisites and installs PowerToys via the MSI. It has additional features such as the installation flags (see below).
  • The MSI installs the PowerToys binaries.

The installer can only be compiled in Release mode; steps 1 and 2 must be performed before the MSI can be compiled.

  1. Compile PowerToys.slnx. Instructions are listed above.
  2. Compile BugReportTool.sln tool. Path from root: tools\BugReportTool\BugReportTool.sln (details listed below)
  3. Compile StylesReportTool.sln tool. Path from root: tools\StylesReportTool\StylesReportTool.sln (details listed below)
  4. Compile PowerToysSetup.slnx Path from root: installer\PowerToysSetup.slnx (details listed below)

See Installer for more details on building and debugging the installer.