If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/microsoft/winget-cli shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 18 active contributors
• Distributed ownership (top contributor 42% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live microsoft/winget-cli repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/microsoft/winget-cli.

What it runs against: a local clone of microsoft/winget-cli — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in microsoft/winget-cli | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of microsoft/winget-cli. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/microsoft/winget-cli.git
#   cd winget-cli
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of microsoft/winget-cli and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "microsoft/winget-cli(\\.git)?\\b" \\
  && ok "origin remote is microsoft/winget-cli" \\
  || miss "origin remote is not microsoft/winget-cli (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f ".github/copilot-instructions.md" \\
  && ok ".github/copilot-instructions.md" \\
  || miss "missing critical file: .github/copilot-instructions.md"
test -f ".github/PULL_REQUEST_TEMPLATE.md" \\
  && ok ".github/PULL_REQUEST_TEMPLATE.md" \\
  || miss "missing critical file: .github/PULL_REQUEST_TEMPLATE.md"
test -f ".editorconfig" \\
  && ok ".editorconfig" \\
  || miss "missing critical file: .editorconfig"
test -f ".config/configuration.winget" \\
  && ok ".config/configuration.winget" \\
  || miss "missing critical file: .config/configuration.winget"
test -f ".github/ISSUE_TEMPLATE/Feature_Request.yml" \\
  && ok ".github/ISSUE_TEMPLATE/Feature_Request.yml" \\
  || miss "missing critical file: .github/ISSUE_TEMPLATE/Feature_Request.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/microsoft/winget-cli"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

WinGet is the Windows Package Manager CLI, providing automated software installation and management from the command line and PowerShell. It surfaces packages from the Microsoft Store (msstore source) and the WinGet community repository (winget-pkgs), giving Windows users apt/brew/chocolatey-like package management natively integrated into Windows 10+ via the App Installer package. Layered architecture: C++ core engine (likely in src/AppInstallerCLI and related native modules) handles package resolution, sources, and installation; C# components wrap COM interfaces for PowerShell and programmatic access; PowerShell modules (2.2M LoC) provide user-facing cmdlets; JavaScript/web components in .github suggest web UI or browser-based tooling. Configuration files in .config/ indicate multi-build variant support (Enterprise, Professional, default).

Windows system administrators, power users, and DevOps engineers who need automated software provisioning and updates; also contributors building package managers or maintaining corporate software deployment pipelines. Contributors include C++/C# engineers working on package management infrastructure and PowerShell developers integrating package management into automation workflows.

Production-ready and actively maintained by Microsoft. The project is 7+ years old with substantial C++ codebase (7.8M LoC), distributed via the Microsoft Store with mandatory Windows 10 1809+ support, and tightly integrated into Windows ecosystem. CI/CD infrastructure exists (.github/workflows and .config/configuration.winget files), and the codebase is actively developed with regular releases and backport support.

Standard open source risks apply.

Active development visible via GitHub issue templates (Bug_Report.yml, Feature_Request.yml, Localization_Issue.yml) and PR workflow (.github/PULL_REQUEST_TEMPLATE.md). The .copilot-instructions.md file indicates AI-assisted development workflow integration. Localization and spelling automation workflows (.github/actions/spelling) suggest continuous quality and internationalization focus. Specific ongoing work likely tracked in microsoft/winget-pkgs (the package repository) and feature flags visible via winget features command.

git clone https://github.com/microsoft/winget-cli.git
cd winget-cli
# Build requires Visual Studio 2019+ (C++ workload) and Windows 10 1809+
# Development setup likely via .config/configuration.winget
msuild /path/to/solution  # or build via VS IDE
# Or install from Microsoft Store for testing

Consult .config/configuration.winget and .editorconfig for environment setup.

Daily commands: From release: winget search <package>, winget install <package>, winget upgrade --all. For development: Build via Visual Studio (solution files likely in root or src/), then run compiled CLI binary. PowerShell module: Import-Module Microsoft.WinGet.Client; Get-WinGetPackage after installation. See README for Microsoft Store installation or insider build instructions.

• .github/copilot-instructions.md — Development guidelines and contribution standards for the WinGet project—essential for understanding code style and architectural decisions
• .github/PULL_REQUEST_TEMPLATE.md — PR submission requirements and checklist—every contributor must follow this to ensure quality and consistency
• .editorconfig — Project-wide coding style and formatting rules enforced across all source files—foundational for code consistency
• .config/configuration.winget — Default build and runtime configuration for the WinGet CLI—critical for understanding project defaults and feature flags
• .github/ISSUE_TEMPLATE/Feature_Request.yml — Standardized feature request workflow—guides contributors on proposing and scoping new functionality
• .github/actions/spelling/allow.txt — Spelling validation rules that gate CI/CD—contributors must understand naming conventions and approved terminology

• Issue Template System (YAML, GitHub Issues API) — Standardizes bug reports, feature requests, and doc issues; gates intake with required metadata
  • Failure mode: Incomplete or off-topic issues if templates are not enforced or users skip form fields
• CI/CD Quality Gates (GitHub Actions, pattern matching, EditorConfig) — Validates spelling, style, and PR template compliance before merge
  • Failure mode: Allows inconsistent or non-compliant code if linters are misconfigured or skipped
• Build Configuration (.winget config files, MSBuild) — Provides named profiles for different build targets (default, Professional, Enterprise)
  • Failure mode: Builds with wrong features/dependencies if profile selection is ambiguous or missing
• Contribution Guidelines (Markdown, Copilot instructions) — Documents development standards and Copilot usage patterns
  • Failure mode: New contributors produce code inconsistent with project conventions if guidelines are unclear

• Developer local environment → PR submission — Source changes committed and pushed; validated against .editorconfig locally
• PR submission → GitHub Actions CI/CD — PR triggers automated checks (spelling, style, template validation)
• GitHub Actions CI/CD → Spelling & Pattern Linting — CI runs allow.txt, reject.txt, patterns.txt checks on PR diff
• Linting results → PR feedback — Pass/fail status and violation details returned to PR for developer review
• Approved PR → master branch merge — Code merged to master after all quality gates pass
• master branch → Build system — Selected .config profile (e.g., configuration.winget) drives compilation and feature inclusion

Add a New Issue Type Template

1. Create a new YAML issue template file following the naming convention in .github/ISSUE_TEMPLATE/ (.github/ISSUE_TEMPLATE/Feature_Request.yml)
2. Define form fields, validation, and labels following the Bug_Report.yml structure (.github/ISSUE_TEMPLATE/Bug_Report.yml)
3. Register the new template in the config.yml to make it discoverable (.github/ISSUE_TEMPLATE/config.yml)

Update Code Style & Formatting Rules

1. Modify the .editorconfig to add or change indentation, line length, or language-specific rules (.editorconfig)
2. Document the rationale in .github/copilot-instructions.md under style guidelines (.github/copilot-instructions.md)
3. Update the PR template to highlight the style change requirement (.github/PULL_REQUEST_TEMPLATE.md)

Enforce New Terminology & Spelling Rules

1. Add approved terms to .github/actions/spelling/allow.txt (.github/actions/spelling/allow.txt)
2. Add forbidden patterns to .github/actions/spelling/reject.txt (.github/actions/spelling/reject.txt)
3. Define complex pattern rules in .github/actions/spelling/patterns.txt if needed (.github/actions/spelling/patterns.txt)

Create a New Build Configuration Profile

1. Create a new configuration file in .config/ (e.g., configuration.custom.winget) (.config/configuration.winget)
2. Reference the naming convention used in existing profiles like configuration.vsProfessional.winget (.config/configuration.vsProfessional.winget)
3. Document the profile purpose in .github/copilot-instructions.md (.github/copilot-instructions.md)

• GitHub Actions — Native CI/CD integrated with repository; no external service dependencies for basic quality gates
• YAML-based Issue Templates — Structured, version-controlled issue intake; enforces consistent metadata collection from contributors
• .editorconfig — Editor-agnostic code formatting standard; ensures consistent whitespace and indentation across IDE/tool choices
• Spelling & Pattern-based Linting — Language-independent validation; gates PRs on terminology and naming conventions to maintain codebase cohesion

• Configuration profiles in .config/ (vs. environment variables)

  • Why: Enables version control of build configurations and multiple named profiles (Professional, Enterprise, default)
  • Consequence: Requires explicit profile selection at build time; less flexible for dynamic runtime configuration

• Spelling validation via file-based allow/reject lists (vs. dictionary-only)

  • Why: Allows domain-specific terminology (WinGet, msstore, etc.) and forbidden patterns to be curated by maintainers
  • Consequence: Manual maintenance of allow/reject lists; pattern.txt complexity grows as rules accumulate

• YAML-based issue templates with form fields (vs. free-text markdown)

  • Why: Structured intake ensures required fields are always collected; easier automated triage and classification
  • Consequence: Less flexibility for edge-case issue descriptions; form field changes require repo updates

• Does not manage runtime package repositories or sources (that is handled by the WinGet CLI/PowerShell modules, not this repo's config)
• Does not implement package installation logic (CLI and COM API layers handle execution)
• Does not provide GUI or UX layer for package discovery (focuses on CLI and underlying infrastructure)
• Does not handle Windows authentication or elevation outside of the main CLI flow
• Linux/macOS compatibility is not a goal (Windows-only project per README)

• Manual spelling list maintenance (Medium) — .github/actions/spelling/ (allow.txt, reject.txt, patterns.txt): As the codebase grows, manually maintaining terminology whitelists/blacklists scales poorly; no automated suggestions for new violations
• Multiple configuration profiles without hierarchy/inheritance (Low) — .config/ (configuration.winget, configuration.vsProfessional.winget, configuration.vsEnterprise.winget): Potential duplication of settings across profiles; no clear mechanism to inherit defaults and override selectively

Windows-only development: Requires Windows 10 1809+ or Windows 11; no cross-platform support. Build system expects Visual Studio toolchain (msbuild); Linux/macOS contributors face significant friction. Multi-variant builds: .config/configuration.*.winget files suggest conditional compilation for Enterprise/Professional/open editions—wrong config at build time produces incompatible binaries. Store distribution lock: Installation via Microsoft Store means local dev builds won't auto-update; testing requires manual version swaps. COM/WinRT COM threading: C# COM interop requires apartment threading model awareness; improper threading causes silent failures. PowerShell Gallery lag: PowerShell module (Microsoft.WinGet.Client) is published separately; local builds don't affect installed cmdlets unless you modify PSModulePath. Spelling automation: .github/actions/spelling/ has strict rules (allow.txt, expect.txt, reject.txt)—misspellings or new terms block merges.

• COM (Component Object Model) — WinGet exposes a COM API for programmatic package management; understanding COM apartments, HRESULT error codes, and interface marshaling is essential for C# interop layers and debugging cross-process calls
• WinRT (Windows Runtime) — The modern Windows API layer underlying Store integration and async operations in WinGet; C++/CX and C++/WinRT code patterns are used throughout the core
• MSIX (Microsoft Application Installer eXtension) — WinGet itself is distributed as an MSIX package via the Microsoft Store; understanding MSIX manifests, signing, and deployment is critical for release and testing
• Package Sources and Indexing — WinGet's architecture uses pluggable sources (MSStore, community repo); understanding how sources are indexed, queried, and manifests are validated (YAML schema) is core to extension work
• PowerShell Module Publishing and Versioning — The Microsoft.WinGet.Client PowerShell module is distributed separately via PSGallery; understanding module manifests (.psd1), versioning, and dependency declaration prevents breaking end-user automation
• YAML Manifest Schema for Packages — All packages in winget-pkgs are defined as YAML manifests with strict schemas; contributors must validate manifests against the schema, and core team maintains schema versioning
• Group Policy Object (GPO) Integration — README mentions that Group Policy can configure sources and restrict package installation; understanding how WinGet reads GPO policies affects deployment scenarios and testing

• microsoft/winget-pkgs — The official community package repository that winget-cli sources packages from; contributors to one often work on both
• microsoft/winget-create — Tool for creating and validating YAML manifests for winget-pkgs; essential companion for package maintainers using winget-cli
• microsoft/winget-cli-resumes — Official documentation and quick-start guides; separate from this repo but tightly coupled for user onboarding
• Homebrew/brew — Spiritual predecessor/sibling for macOS; winget-cli architecture borrowed concepts from Homebrew's tap system and manifest structure
• Chocolatey/choco — Pre-existing Windows package manager that winget-cli partly aims to replace; many users migrate from Chocolatey to winget

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for COM API interfaces

The repo includes a COM (Component Object Model) API but there are no visible test files in the provided structure. COM APIs are critical for third-party integrations and require rigorous testing. New contributors could add unit tests for COM interface contracts, error handling, and marshaling scenarios to prevent regressions.

• [ ] Locate COM API source files (likely in src/ directory not shown in structure)
• [ ] Create tests/COM/ directory structure mirroring the API interfaces
• [ ] Write tests for interface initialization, method calls, and error conditions
• [ ] Add tests for HRESULT return codes and exception handling
• [ ] Document COM API test patterns in a new CONTRIBUTING_COM_TESTS.md file

Create GitHub Actions workflow for PowerShell module validation

The repo includes PowerShell modules (mentioned in description) but there's no visible .github/workflows/ directory in the file structure. A dedicated workflow could validate PowerShell module syntax, run Pester tests, check code style with PSScriptAnalyzer, and verify manifest files—catching issues before merge.

• [ ] Create .github/workflows/powershell-validation.yml
• [ ] Add jobs for PSScriptAnalyzer linting against PowerShell best practices
• [ ] Add Pester test execution for all .tests.ps1 files in the PowerShell module directory
• [ ] Add validation for module manifest files (.psd1) integrity
• [ ] Document PowerShell testing requirements in docs/

Expand spelling/localization GitHub Action configuration for non-English documentation

The .github/actions/spelling/ directory exists with configuration files (allow.txt, reject.txt, patterns.txt) but there's no corresponding localization workflow. Given the Localization_Issue.yml template exists, contributors could enhance the action to validate translations, check for untranslated strings, and prevent common localization bugs across supported languages.

• [ ] Analyze existing .github/actions/spelling/ configuration files
• [ ] Create .github/workflows/localization-check.yml workflow
• [ ] Add configuration files in .github/actions/localization/ for each supported language
• [ ] Implement checks for translated string consistency between resource files
• [ ] Document localization contribution guidelines in docs/LOCALIZATION.md

• Add unit tests for Package source resolution logic: The C++ source handlers (likely in src/AppInstallerCLI/Managers/) lack isolated test coverage visible in this file list; create googletest cases for MSStore and community-repo fetch failures, timeout handling, and manifest parsing edge cases.
• Improve documentation for COM API usage in src/COM/: Add markdown examples in a docs/ folder showing C# consumers how to instantiate IPackageManager, call InstallPackage(), and handle HRESULT exceptions; currently only inferred from .cpp headers.
• Localize error messages in PowerShell module: The PowerShell module (2.2M LoC) likely has hard-coded English strings; extract them to resource files (.resx) and add a GitHub issue tracking translations for French, German, Spanish, and Japanese to expand LOC support.

The WinGet project demonstrates good security practices with a proper vulnerability disclosure policy and Microsoft's backing. However, several security concerns exist: (1) No dependency manifest analysis possible due to incomplete information provided, (2) Supply chain risks from accepting community-contributed packages that require robust verification, (3) The package manager's core function of installing third-party software inherently carries execution risk. Recommendations include implementing cryptographic package verification, automated dependency scanning, malware detection for community packages, and maintaining comprehensive security documentation. The low score reflects the inability to fully assess dependencies and the inherent supply chain risks of a package manager without seeing specific mitigation controls in place.

• Medium · Dependency Management Visibility — Repository root / Dependencies. No package dependency files (package.json, requirements.txt, .csproj, etc.) were provided for analysis. WinGet CLI is a C++ application that may have dependencies through vcpkg, NuGet, or other package managers. Without visibility into dependencies, vulnerabilities in third-party libraries cannot be assessed. Fix: Provide dependency manifests for analysis. Implement automated dependency scanning using tools like OWASP Dependency-Check, Snyk, or GitHub's Dependabot to identify vulnerable packages.
• Medium · Package Manager Supply Chain Attack Surface — Package source architecture. WinGet aggregates packages from multiple sources (Microsoft Store and winget-pkgs community repository). This creates a supply chain risk where malicious or compromised packages could be distributed to users. The community repository (winget-pkgs) accepts external contributions. Fix: Implement package verification mechanisms: cryptographic signing verification, checksum validation, sandboxed execution for package installation detection, and automated scanning of community packages for malware patterns.
• Low · Security Policy Visibility — SECURITY.md. While SECURITY.md exists and properly directs security issues to Microsoft Security Response Center (MSRC), the file appears truncated in the provided content. Incomplete security policy documentation could confuse reporters. Fix: Ensure SECURITY.md is complete with: full MSRC reporting instructions, expected response timelines, supported versions, and guidelines for disclosure embargoes. Reference: https://msrc.microsoft.com/create-report
• Low · Potential Executable Distribution from Assets — .github/images/. The .github/images directory contains image assets. While images themselves are typically safe, the project structure suggests asset hosting which could be misused if access controls aren't properly configured. Fix: Ensure GitHub repository settings restrict who can commit to protected branches. Implement branch protection rules requiring code review before merges. Monitor for unexpected binary files in version control.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.