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/builtbybel/ThisIsWin11 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.

WAIT — Stale — last commit 3y ago

• 8 active contributors
• MIT licensed
• CI configured
• ⚠ Stale — last commit 3y ago
• ⚠ Single-maintainer risk — top contributor 88% of recent commits
• ⚠ No test directory detected

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

What it runs against: a local clone of builtbybel/ThisIsWin11 — 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 builtbybel/ThisIsWin11 | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 1099 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "builtbybel/ThisIsWin11(\\.git)?\\b" \\
  && ok "origin remote is builtbybel/ThisIsWin11" \\
  || miss "origin remote is not builtbybel/ThisIsWin11 (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 main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1099 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1069d)"
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/builtbybel/ThisIsWin11"
  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).

ThisIsWin11 is a Windows 11 customization and tweaking application written in C# that consolidates system configuration tools into a single UI. It replaces discontinued Microsoft PowerToys components (like TweakUI) with features like OpenTweaks for OS customization, PumpedApp for removing bloatware, and PowerUI for PowerShell automation—all accessible through a tabbed interface covering GetStarted, Action Center, Android Apps, Gaming, Privacy, and other Windows 11 subsystems. Single monolithic C# project: src/TIW11.sln is the root, containing src/TIW11/ with Controls/ (RoundedButton.cs custom UI), Helpers/ (DependenciesChecker, ThemeHelper, Utils, Strings), and App.config for configuration. Collections/ folder holds preset .ini files and batch scripts for common tweaks. No separation into DLLs or plugins yet—all logic is in the main executable.

Windows 11 power users and system administrators who want to customize OS behavior (disable TPM checks, enable classic context menus, remove preinstalled apps) without touching raw Registry keys or running separate tools. Contributors are C# WinForms/WPF developers comfortable with Windows API and batch scripting.

Moderately mature and actively maintained—the project has stable releases on GitHub with 1.2k+ stars and a 100% portable .exe distribution model. CI/CD is set up (ci.yml, codeql-analysis.yml workflows) and the codebase is well-organized under src/TIW11, but test coverage is not apparent from the file listing. The presence of collections/ presets and batch scripts suggests production use, though single-maintainer (builtbybel) means community patches may lag.

Primary risks: (1) Single maintainer with no visible test suite increases regression risk on Windows API calls; (2) C# WinForms is aging technology—future .NET 9+ updates may require migration; (3) Deep OS hooks (disabling TPM, enabling AutoAdminLogon) can break system stability if logic is flawed, and no rollback mechanism is documented. Dependency on Windows Package Manager (winget-cli) adds indirect risk.

Unable to determine current active work from file list alone—no recent commit hashes or PR metadata visible. However, the presence of github/workflows suggests CI runs on push. The collections/ folder shows community configurations being added (NoADS, drag_drop_fix, TPM toggles), indicating users are extending the tool.

git clone https://github.com/builtbybel/ThisIsWin11.git
cd src
opening TIW11.sln in Visual Studio 2019+ (or dotnet build TIW11.sln for CLI)
dotnet build
dotnet run --project TIW11/TIW11.csproj

OR download prebuilt .exe from Releases and run directly (100% portable, no installer needed).

Daily commands: Open src/TIW11.sln in Visual Studio 2019+ → Build Solution → Run (F5). Or: dotnet build src/TIW11.sln && dotnet run --project src/TIW11/TIW11.csproj. The .exe is self-contained; no dependencies to install except .NET Runtime. For end users, extract TIW11.zip and double-click TIW11.exe.

• src/TIW11/Helpers/Utils.cs: Core Registry/WMI access layer—all OS tweaks funnel through here; understanding this is mandatory for adding new customizations.
• src/TIW11/App.config: Application configuration and assembly binding redirects; controls .NET runtime and assembly versions.
• src/TIW11/Helpers/DependenciesChecker.cs: Validates system prerequisites (Windows 11 version, .NET runtime); failure here blocks app startup.
• collections/: User-facing preset configurations (.ini and .bat files); real-world examples of how tweaks are packaged and deployed.
• .github/workflows/ci.yml: Build and test automation pipeline; defines how releases are generated and distributed.

Start in src/TIW11/Helpers/: Strings.cs for UI text/labels, Utils.cs for Registry manipulation and system calls, ThemeHelper.cs for appearance. Controls/RoundedButton.cs for custom UI components. Adding a new tweak: create a new .cs file in Helpers/, add Registry key operations to Utils.cs, wire the UI button in Form1 (not shown but likely in src/TIW11/), and add corresponding .ini preset to collections/. Study existing batch scripts in collections/ to understand parameter passing.

No visible strong-name signing or code-signing on the .exe—users downloading from GitHub may get warnings. UAC elevation likely required for Registry writes but not documented in setup instructions—first run may fail silently without admin prompt. App.config specifies .NET Framework compatibility—check netVersion in App.config before upgrading to .NET 9+. No rollback mechanism—once a tweak is applied (e.g., TPM disable), users must manually revert via Registry or rerun the toggle batch script. Collections/ assumes cmd.exe/powershell.exe are available—non-standard shells will fail.

• Windows Registry Hives (HKLM, HKCU, HKU) — 95% of ThisIsWin11's tweaks work by reading/writing Registry keys; understanding hive structure (Local Machine vs. Current User) is essential for Utils.cs logic and avoiding permission errors.
• User Account Control (UAC) Elevation & Token Impersonation — Many Registry tweaks (TPM disable, AutoAdminLogon) require admin privileges; the app must detect and request elevation, or silently fail—critical for user experience.
• WMI (Windows Management Instrumentation) Queries — Likely used in DependenciesChecker.cs to detect Windows version and system properties; mismatches cause app to block on non-11 systems as intended.
• Group Policy Objects (GPO) & Local Group Policy Editor (gpedit.msc) — Some tweaks (e.g., 'Enable Classic Context menus') manipulate Group Policy settings; understanding GPO structure helps debug why a Registry change has no effect.
• Batch Scripting (.bat) vs. PowerShell (.ps1) for System Automation — Collections/ mixes .bat and .ps1 files; knowing when each is appropriate (batch for simple Registry reg.exe calls, PS for complex logic) is key to extending ThisIsWin11.
• Portable Executables & Zero-Install Distribution — ThisIsWin11 advertises 100% portability—no installer, no registration; understanding how .NET embeds dependencies and avoiding file system writes outside temp/ is critical for this model.
• Custom Control Inheritance & WinForms Theming (RoundedButton) — RoundedButton.cs shows how to extend base Button control for custom rendering; replicating this pattern is needed for any new UI elements matching the design language.

• microsoft/PowerToys — Official Microsoft PowerToys for Windows 10/11—ThisIsWin11 explicitly aims to replace discontinued TweakUI and fill gaps Microsoft abandoned.
• W4RH4WK/Debloat-Windows-10 — Similar debloating/tweaking philosophy using PowerShell; shares the goal of removing bloatware but uses script-only approach vs. ThisIsWin11's UI wrapper.
• ChrisLTD/Optimize-Windows11 — Another Windows 11 optimization tool; overlaps in features (TPM disable, context menu tweaks) and serves as competitive reference for feature parity.
• microsoft/winget-cli — Windows Package Manager CLI that ThisIsWin11's Packages component integrates with for app installation automation.
• PowerShell/PowerShell — PowerUI component runs PowerShell scripts for automation; understanding PS is essential for extending ThisIsWin11's scripting capabilities.

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 unit tests for DependenciesChecker.cs and Utils.cs helper classes

The src/TIW11/Helpers directory contains critical utility classes (DependenciesChecker.cs, ThemeHelper.cs, Utils.cs) that handle system checks and theme detection, but there are no visible test files in the repo. These helpers are foundational to the application's reliability. Adding unit tests would catch regressions early and make the codebase more maintainable for contributors.

• [ ] Create src/TIW11.Tests project in the solution
• [ ] Add unit tests for DependenciesChecker.cs covering dependency detection scenarios
• [ ] Add unit tests for Utils.cs covering utility method edge cases
• [ ] Configure CI workflow (.github/workflows/ci.yml) to run tests on PR submissions
• [ ] Document test setup in CONTRIBUTING.md or README

Refactor Assessments module: Extract common logic from individual assessment classes into AssessmentBase

The src/TIW11/Modules/OpenTweaks/Assessments directory contains many individual assessment classes (AccountInfo.cs, AppNotifications.cs, BackgroundApps.cs, Calendar.cs, Call.cs, etc.). These likely have duplicated registry/WMI query logic. Extracting common assessment patterns into AssessmentBase would reduce code duplication, improve maintainability, and make it easier for contributors to add new assessments.

• [ ] Analyze 5-10 existing assessment classes in src/TIW11/Modules/OpenTweaks/Assessments to identify common patterns
• [ ] Add template methods and utility properties to AssessmentBase.cs for common registry queries
• [ ] Refactor 3-4 assessment classes to use the new base class patterns
• [ ] Create ASSESSMENT_DEVELOPMENT.md documenting how to write new assessments
• [ ] Update existing assessment files incrementally to follow the new pattern

Add GitHub Actions workflow to validate .ini collection files and script syntax

The collections/ directory contains .ini configuration files and .bat scripts (tpm_on.bat, aal_on.bat, drag_drop_fix.zip, etc.) that users apply to their systems. There's no validation ensuring these files are syntactically correct or safe. Adding a linter workflow would prevent malformed configurations from being merged and improve user safety.

• [ ] Create .github/workflows/validate-collections.yml GitHub Action
• [ ] Add INI file validation step (using a tool like ini-parser or custom validation)
• [ ] Add batch script syntax validation step (using fxc.exe or similar)
• [ ] Configure the workflow to run on PR changes to collections/ directory
• [ ] Document validation requirements in CONTRIBUTING.md for collection contributors

• Add unit tests for src/TIW11/Helpers/Utils.cs Registry manipulation functions—currently no test suite exists, and Registry operations are error-prone; even 5 tests would catch common issues like missing HKLM access or malformed key paths.
• Document the .ini preset format and batch script parameters in a new DEVELOPMENT.md file—new contributors have no guide for creating custom tweaks in collections/; add examples of Registry vs. batch approaches and when to use each.
• Implement a rollback/undo feature by storing Registry snapshots before apply operations—currently no way to revert tweaks; add a simple Registry export to a timestamped .reg file in the App's temp folder, accessible via a new 'Revert Last Change' button.

• High · Batch Scripts with Potential Privilege Escalation — collections/*.bat files. The repository contains batch scripts (tpm_on.bat, tpm_off.bat, aal_on.bat, aal_off.bat) in the collections folder that appear to modify system-level settings. These scripts could potentially be exploited for privilege escalation or unauthorized system modifications if not properly validated or if executed with elevated privileges without user consent. Fix: Review all batch scripts for security implications. Implement code signing for executable scripts, add user confirmation prompts before executing system-level changes, and document what each script does. Consider using Windows Management Instrumentation (WMI) or PowerShell with proper error handling instead of batch scripts where possible.
• Medium · Unencrypted Configuration Files — collections/*.ini files. INI configuration files in the collections folder (e.g., 'Enable AutoAdminLogon.ini', 'Disable TPM 2.0 Check.ini', 'Join Domain.ini') may contain sensitive system configuration data. If these files are processed or stored without encryption, they could expose security-sensitive settings. Fix: Encrypt sensitive configuration files at rest. Implement access controls to restrict who can read/modify these files. Never store credentials in plain text. Add validation and sanitization when parsing INI files to prevent injection attacks.
• Medium · ZIP Archive Without Integrity Verification — collections/NoADS_for_TIW11.zip, collections/drag_drop_fix.zip. The repository includes ZIP files (NoADS_for_TIW11.zip, drag_drop_fix.zip) without apparent integrity verification mechanisms. Users downloading these files have no way to verify they haven't been tampered with during transit or storage. Fix: Implement code signing for all distributable files. Provide SHA-256 or SHA-512 checksums for all ZIP archives and document how users can verify them. Consider using Microsoft Authenticode signatures for Windows compatibility. Document the contents and purpose of each archive.
• Medium · Potential Registry Modification Without Validation — src/TIW11/Modules/OpenTweaks/Assessments/*. Given the purpose of ThisIsWin11 (a Windows 11 customization tool), there is likely registry modification code present. Without proper input validation and sanitization in the C# codebase, this could lead to registry injection attacks or unintended system modifications. Fix: Implement strict input validation for all registry operations. Use Windows Registry API safely through managed code. Never construct registry paths from user input directly. Implement rollback/undo functionality. Add logging for all registry modifications. Require administrative privileges and user confirmation before making system-level changes.
• Medium · Missing Dependency Information — src/TIW11/TIW11.sln, src/TIW11/App.config. The dependency/package file content is not provided in the analysis. This means potential vulnerable NuGet packages or .NET Framework dependencies cannot be assessed. The project appears to be a .NET/C# WinForms application but no package manifest (packages.config or .csproj) was provided for security review. Fix: Provide packages.config and .csproj files for analysis. Regularly audit all dependencies using tools like OWASP Dependency-Check or Snyk. Keep all NuGet packages updated to latest secure versions. Implement Software Composition Analysis (SCA) in the CI/CD pipeline.
• Low · No HTTPS Enforcement Documentation — src/TIW11/Helpers/Utils.cs, src/TIW11/Helpers/DependenciesChecker.cs. While this is a desktop application, if it performs any remote operations (checking for updates, downloading configurations), there is no visible documentation about HTTPS enforcement or certificate pinning. Fix: If the application makes network requests, enforce HTTPS only. Implement certificate pinning for critical operations. Validate SSL/TLS certificates properly. Document all remote communication endpoints and their security requirements.
• Low · Insufficient Code Review Evidence — Repository root. No evidence of security code review comments, security-focused test cases, or threat modeling documentation in the visible repository structure. Fix: Implement mandatory security code reviews. Add security-focused unit and integration tests. Create and maintain a threat model document. Include security guidelines in CONTRIBUTING.md. Consider third-party security audits given the privileged nature of this tool

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.