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/chocolatey/choco 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 3d ago
• 7 active contributors
• Distributed ownership (top contributor 43% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{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 chocolatey/choco repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/chocolatey/choco.

What it runs against: a local clone of chocolatey/choco — 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 chocolatey/choco | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch develop exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of chocolatey/choco. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/chocolatey/choco.git
#   cd choco
#
# 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 chocolatey/choco and re-run."
  exit 2
fi

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

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

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

# 4. Critical files exist
test -f "build.ps1" \\
  && ok "build.ps1" \\
  || miss "missing critical file: build.ps1"
test -f "nuspec/chocolatey/chocolatey/chocolatey.nuspec" \\
  && ok "nuspec/chocolatey/chocolatey/chocolatey.nuspec" \\
  || miss "missing critical file: nuspec/chocolatey/chocolatey/chocolatey.nuspec"
test -f "nuspec/chocolatey/chocolatey/tools/chocolateyInstall.ps1" \\
  && ok "nuspec/chocolatey/chocolatey/tools/chocolateyInstall.ps1" \\
  || miss "missing critical file: nuspec/chocolatey/chocolatey/tools/chocolateyInstall.ps1"
test -f "nuspec/chocolatey/chocolatey/tools/chocolateysetup.psm1" \\
  && ok "nuspec/chocolatey/chocolatey/tools/chocolateysetup.psm1" \\
  || miss "missing critical file: nuspec/chocolatey/chocolatey/tools/chocolateysetup.psm1"
test -f ".github/workflows/build.yml" \\
  && ok ".github/workflows/build.yml" \\
  || miss "missing critical file: .github/workflows/build.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 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
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/chocolatey/choco"
  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).

Chocolatey is a package manager for Windows that brings yum/apt-get-like package management to the platform. It automates software installation, updates, and dependency resolution via command-line or PowerShell, with support for both community and business packages through a centralized repository. The repository is organized as a single-codebase project with C# as the primary implementation language, PowerShell scripts for testing and CI (Invoke-Tests.ps1, Invoke-AuthedTests.ps1), batch files for Windows compatibility, and shell scripts for non-Windows platforms. CI/CD is coordinated via .github/workflows/ (build.yml, test.yml, label-sync.yml) and .teamcity/settings.kts for JetBrains TeamCity integration.

Windows system administrators, DevOps engineers, and developers who need to automate software provisioning and updates at scale. Users range from individual developers managing their dev environment to enterprise teams automating infrastructure-as-code across hundreds of machines.

Highly mature and production-ready. The project shows active development with GitHub Actions CI/CD pipelines (build.yml, test.yml), comprehensive test coverage infrastructure (Invoke-Tests.ps1, Invoke-AuthedTests.ps1), a detailed CHANGELOG, and a clear governance structure with COMMITTERS.md and CONTRIBUTING.md. The repo has been actively maintained with modern tooling (GitVersion, GitReleaseManager).

Standard open source risks apply.

The project is actively developed with GitHub Actions workflows handling builds and tests automatically. Release templating infrastructure (GitReleaseManager.yaml, .templates/ with multiple locales) suggests regular releases. The .github/labels.yml and stale.yml workflow indicate active issue triage. Version management via GitVersion.yml suggests semantic versioning discipline.

Clone the repository with git clone https://github.com/chocolatey/choco.git. Review CONTRIBUTING.md and README.md for setup instructions. On Windows, use the build scripts referenced in the README (Compiling/Building Source section). On other platforms, follow the 'Other Platforms' prerequisite and build process documented in the README.

Daily commands: The README specifies platform-specific build processes. On Windows: follow the 'Compiling / Building Source' Windows section. On other platforms: install prerequisites listed in the README 'Other Platforms' section, then execute the build process outlined there. Use Invoke-Tests.ps1 for local test execution and Invoke-AuthedTests.ps1 for authenticated test scenarios.

• build.ps1 — Primary build orchestration script that coordinates the entire Chocolatey build pipeline; essential for understanding the development workflow.
• nuspec/chocolatey/chocolatey/chocolatey.nuspec — NuSpec manifest defining the Chocolatey package structure, versioning, and distribution metadata; critical for package lifecycle.
• nuspec/chocolatey/chocolatey/tools/chocolateyInstall.ps1 — Installation entry point executed during package deployment; handles core Chocolatey setup on target systems.
• nuspec/chocolatey/chocolatey/tools/chocolateysetup.psm1 — PowerShell module providing foundational setup functions and utilities used throughout the Chocolatey ecosystem.
• .github/workflows/build.yml — CI/CD pipeline definition for automated builds; defines how contributions are validated before merge.
• GitVersion.yml — Semantic versioning configuration controlling Chocolatey's version numbering and release tagging strategy.
• CONTRIBUTING.md — Contribution guidelines and code standards that all developers must follow when submitting changes.

Add a new PowerShell-based Chocolatey feature

1. Create or extend a PowerShell function in the core setup module (nuspec/chocolatey/chocolatey/tools/chocolateysetup.psm1)
2. Export the function and ensure it's loaded during initialization (nuspec/chocolatey/chocolatey/tools/init.ps1)
3. Add unit tests for the new functionality (Invoke-Tests.ps1)
4. Update documentation in the README or contributing guide (CONTRIBUTING.md)

Release a new version of Chocolatey

1. Update version in GitVersion configuration (GitVersion.yml)
2. Document changes in the changelog (CHANGELOG.md)
3. Ensure NuSpec metadata reflects new version and dependencies (nuspec/chocolatey/chocolatey/chocolatey.nuspec)
4. Trigger build pipeline which automatically packages and pushes to NuGet (.github/workflows/build.yml)

Modify the installation process

1. Edit the main installation script for new setup logic (nuspec/chocolatey/chocolatey/tools/chocolateyInstall.ps1)
2. Add any reusable utility functions to the setup module (nuspec/chocolatey/chocolatey/tools/chocolateysetup.psm1)
3. Test installation in Windows and Linux environments using Docker (docker/Dockerfile.windows)
4. Run validation tests and format checks (ScriptFormat.Tests.ps1)

Add a new CI/CD workflow or build step

1. Define the workflow in GitHub Actions format (.github/workflows/build.yml)
2. Update the main Cake build script with the corresponding build task (build.ps1)
3. Configure any build-time dependencies or settings (cake.config)
4. Document the new workflow in contributing guidelines (CONTRIBUTING.md)

• PowerShell (Core) — Chocolatey is a Windows package manager and relies on PowerShell as the primary scripting and automation language native to Windows; enables deep OS integration and package management automation.
• NuGet Package Format — Leverages existing Windows/.NET ecosystem tooling for package distribution, versioning, and dependency management; allows packages to be published to public NuGet repositories.
• GitHub Actions + Cake Build System — Enables reproducible, declarative CI/CD with version control; Cake provides cross-platform build automation abstracting PowerShell-specific logic.
• Docker (Windows & Linux) — Provides isolated, reproducible build and testing environments; enables validation across different Windows/Linux configurations without manual setup.
• Scriban Templating — Generates dynamic release notes and contributor documentation from structured data; reduces manual changelog maintenance.

• Windows-centric PowerShell over cross-platform alternatives

  • Why: Chocolatey's core mission is Windows package management; PowerShell is the native automation language for Windows.
  • Consequence: Limited portability; Linux/Mac users must use Docker or WSL; however, provides best-in-class Windows OS integration.

• Monolithic build script (build.ps1) vs modular task files

  • Why: Simplifies onboarding and reduces configuration complexity for contributors; all build logic in one location.
  • Consequence: Potential scaling challenges as the project grows; build.ps1 may become difficult to maintain if project complexity increases significantly.

• NuGet as distribution mechanism vs custom package format

  • Why: Reuses mature, trusted Windows package infrastructure; reduces implementation burden and leverages existing ecosystem tooling.
  • Consequence: Tightly coupled to NuGet versioning/naming conventions; less flexibility for custom metadata or package structures.

• Both GitHub Actions and TeamCity CI systems

  • Why: GitHub Actions is modern, visible to contributors; TeamCity may provide enterprise stability or existing organizational integration.
  • Consequence: Maintenance overhead of dual CI systems; potential for workflow drift between platforms.

• Not a cross-platform package manager—Windows-only (though Docker containers provide Linux support)
• Does not provide GUI package management—CLI/PowerShell-driven only
• Does not compete with system package managers (apt, yum)—Windows-specific complement
• Not a dependency resolver for compiled binaries—packages metadata only; installation scripts provided by package authors
• Does not provide package signing/cryptographic verification beyond NuGet's mechanisms

Chocolatey has both FOSS and licensed versions maintained in a single repo (CHANGELOG_LICENSED.md exists separately), requiring care when contributing to avoid licensing violations. Windows-specific APIs mean testing on actual Windows or CI is essential—local development on non-Windows may hide platform issues. The PowerShell test scripts (Invoke-Tests.ps1) may require administrator privileges on Windows. TeamCity configuration (.teamcity/settings.kts) suggests internal CI systems may differ from public GitHub Actions, creating potential configuration drift. The split between .github/workflows/ (public CI) and .teamcity/ (internal CI) suggests some features tested internally may not be visible in public PRs.

• Package Dependency Graph Resolution — Chocolatey must resolve transitive dependencies and version constraints across the package ecosystem; understanding how it builds and validates dependency trees is critical for fixing install failures and improving performance
• Semantic Versioning & Version Ranges — GitVersion.yml and package versioning throughout Chocolatey enforce SemVer discipline; contributors must understand how version constraints like >=1.0.0-beta <2.0.0 are parsed and matched
• Idempotent Infrastructure Automation — Chocolatey's core value is running install scripts repeatedly without breaking systems; understanding idempotency principles (scripts that are safe to re-run) is fundamental to how packages are authored and validated
• Windows Package Isolation & Versioning — Windows lacks built-in package managers with conflict resolution; Chocolatey implements custom versioning and side-by-side installation strategies that differ from UNIX package managers—understanding chocolateyinstall.ps1 scripts and shim generation is essential
• PowerShell Deserialization & Remote Execution — Chocolatey uses PowerShell extensively for package scripts (Invoke-*.ps1); understanding PowerShell's object serialization, remoting, and security execution policies is critical for debugging installation issues
• Source Control Automation & GitOps — The repo uses GitVersion, GitReleaseManager, and GitHub Actions workflows to automate versioning and releases; understanding how commits drive version bumps and release notes is essential for release management contributions
• Cross-Platform Compatibility Layers — Chocolatey supports Windows, non-Windows platforms via mixed C#/PowerShell/Shell scripts; the architecture must handle Windows-specific APIs (registry, WMI) while providing fallbacks for other OSes—contributors must understand this abstraction

• nuget/nuget.client — NuGet is the .NET package manager; Chocolatey's underlying package format and dependency resolution heavily leverage NuGet infrastructure
• Homebrew/brew — Homebrew is the macOS/Linux equivalent that inspired Chocolatey's design philosophy of simple, scriptable package management
• chocolatey/choco-wiki — Official documentation wiki for Chocolatey users and contributors; essential reference for understanding package standards and best practices
• chocolatey/chocolatey.org — The Chocolatey community repository website; hosts the package index and community packages that Chocolatey CLI consumes
• microsoft/winget-cli — Microsoft's modern package manager for Windows; represents the modern competitor in the Windows package management space

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 PowerShell script formatting validation

The repo contains ScriptFormat.Tests.ps1 which appears to be a test file for PowerShell script formatting, but there's no corresponding CI workflow to run these tests automatically. This is critical for a PowerShell-heavy project like Chocolatey to ensure code quality consistency across contributions. Adding a GitHub Actions workflow to run these tests on PRs would catch formatting issues early.

• [ ] Create .github/workflows/powershell-format-check.yml to run ScriptFormat.Tests.ps1 on pull requests
• [ ] Configure the workflow to fail if formatting violations are detected
• [ ] Add documentation in CONTRIBUTING.md about running local formatting checks before submitting PRs
• [ ] Reference the new workflow in the appropriate sections of README.md or TESTING.md

Implement Docker build workflow and image verification tests

The repo contains Dockerfile.linux and Dockerfile.windows in the docker/ directory, but there are no corresponding GitHub Actions workflows to build and verify these Docker images on each commit or PR. This is essential for maintaining Docker image quality and catching build failures early. Current .github/workflows show build.yml and test.yml but no Docker-specific automation.

• [ ] Create .github/workflows/docker-build.yml to build both Linux and Windows Docker images on PRs
• [ ] Add basic smoke tests to verify the Docker images install Chocolatey correctly (reference docker/Install-ChocolateyInContainer.ps1)
• [ ] Configure matrix strategy to build for both linux and windows platforms
• [ ] Update docker/README.md with information about automated build verification

Expand release notes template coverage and add validation tests

The repo has extensive release note templates in .templates/ (default, contributors, no variants) but lacks automated tests to validate that these templates produce valid output or that required fields are populated. Adding validation logic would prevent malformed release notes. CHANGELOG.md and CHANGELOG_LICENSED.md exist but template validation is missing.

• [ ] Create tests/integration/ReleaseNotesTemplate.Tests.ps1 to validate template rendering for all variants in .templates/
• [ ] Test that all required fields (version, date, issue-details, etc.) are populated in rendered output
• [ ] Add tests to verify .sbn template syntax is valid and renders without errors
• [ ] Add a step to GitHub Actions build workflow to run release notes validation tests

• Add or expand unit tests for existing PowerShell helper functions in the codebase. The repo has comprehensive test infrastructure (Invoke-Tests.ps1, test.yml) but many core PowerShell utilities likely lack full coverage—contribute tests that exercise edge cases in package installation and dependency resolution.
• Improve documentation coverage by adding inline code comments to frequently-used C# classes in the core package management logic. With 3.7M lines of C#, many architectural patterns are undocumented—pick a core module (inferred from the structure) and add clarifying comments for new contributors.
• Enhance the .github/workflows/test.yml to add platform-specific test matrix entries (e.g., explicit testing on Windows Server, Windows 10, non-Windows platforms). Currently the test coverage strategy is not visible in the file list, so proposing and implementing a more comprehensive matrix would improve reliability across environments.

The Chocolatey repository shows a generally reasonable security posture but has several areas requiring attention. The primary concerns are: (1) potential exposure of .snk key files used for assembly signing, (2) insufficient security measures around PowerShell script execution, (3) lack of Docker image vulnerability scanning, (4) potential credential exposure in build configuration files, and (5) missing security policy documentation. The codebase is actively maintained with CI/CD pipelines in place, but security scanning tools should be integrated more comprehensively. No obvious SQL injection or XSS vulnerabilities are

• Medium · Potential Sensitive File in Repository Root — chocolatey.snk. File 'chocolatey.snk' appears to be a strong name key file, which is used for .NET assembly signing. If this is a private key, it should not be committed to the repository as it could be used to forge signed assemblies. Fix: Verify that chocolatey.snk is a public key or has appropriate access controls. If it's a private key, remove it from the repository and use secure key management practices. Add *.snk to .gitignore if needed.
• Medium · PowerShell Scripts Without Execution Policy Validation — *.ps1 files (Invoke-AuthedTests.ps1, Invoke-Tests.ps1, build.ps1, ScriptFormat.Tests.ps1, docker/Install-ChocolateyInContainer.ps1). Multiple PowerShell scripts are present in the repository (Invoke-AuthedTests.ps1, Invoke-Tests.ps1, build.ps1, etc.) that could potentially be executed with elevated privileges. There is no visible validation or documentation of execution policies. Fix: Implement script signing, add execution policy checks, validate script integrity before execution, and document security requirements for running these scripts. Consider adding code review requirements for all PowerShell scripts.
• Medium · Docker Images Without Apparent Security Scanning — docker/Dockerfile.linux, docker/Dockerfile.windows, docker/choco_wrapper, docker/choco_official_wrapper. Docker configuration files are present (Dockerfile.linux, Dockerfile.windows, docker/choco_wrapper) but there is no evidence of automated security scanning or vulnerability assessment in the build pipeline. Fix: Implement Docker image scanning in CI/CD pipeline using tools like Trivy or Anchore. Ensure base images are minimal and regularly updated. Add security scanning to the build.yml GitHub Actions workflow.
• Medium · Build Configuration Exposure in Repository — .teamcity/settings.kts, cake.config, build.ps1, build.bat, build.sh, NuGet.config. Multiple build configuration files are present (.teamcity/settings.kts, cake.config, build.ps1, build.bat, etc.) that may contain sensitive build credentials or deployment information. Fix: Audit build configuration files for hardcoded credentials. Use secure credential injection methods (environment variables, secret managers). Ensure NuGet.config doesn't contain API keys in version control.
• Low · Notification Files in Repository — .notifications/discord.txt, .notifications/mastodon.txt, .notifications/slack.txt, .notifications/twitter.txt. Notification configuration files (.notifications/discord.txt, .notifications/slack.txt, etc.) are present in the repository which could potentially contain webhooks or API endpoints that should be protected. Fix: Verify these files don't contain active webhooks or credentials. Move sensitive notification endpoints to environment variables or secret management systems. Add .notifications/ to .gitignore if needed.
• Low · Missing SECURITY.md File — Repository root. The repository lacks a SECURITY.md file which is a best practice for disclosing security vulnerabilities responsibly. Fix: Create a SECURITY.md file documenting the process for reporting security vulnerabilities, expected response times, and any security policies.
• Low · Potential Secrets in GitHub Actions Workflows — .github/workflows/build.yml, .github/workflows/test.yml. GitHub Actions workflows are present but cannot be fully audited from file structure alone. Workflows may contain hardcoded tokens or exposed environment variables. Fix: Audit all GitHub Actions workflows to ensure no hardcoded secrets. Use GitHub Secrets for sensitive data. Implement branch protection rules and require code review before workflow changes.

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.