How do I install the Per User Msi Review Gate skill?

Run npx skillmds add majiayu000/per-user-msi-review-gate in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Per User Msi Review Gate skill do?

How to gate a Windows MSI installer that must install without admin access It is listed under Coding & Dev Tools on SkillMD.

Is Per User Msi Review Gate safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Per User Msi Review Gate?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Per User Msi Review Gate free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Per User Msi Review Gate?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Per User Msi Review Gate by majiayu000

Name: Per User Msi Review Gate
Rating: 4.5 (4 reviews)
Author: majiayu000

File contents

Context

Use this when a desktop app adds an MSI installer and the slice specifically requires standard-user, non-admin installation.

Pattern

Require one repo-root build command that produces the MSI artifact deterministically.
Verify installer metadata really declares per-user scope and limited privileges for the packaging tool in use.
Treat the installed payload as the product: confirm the installed directory contains the app exe, runtime files, bundled content, and supporting assemblies.
If the ask is for a single-file MSI, verify the Release output directory contains the .msi and no sibling external .cab; do not infer this only from WiX metadata. If possible, corroborate with the built MSI Media table showing an embedded cabinet entry such as #cab1.cab.
Run one install/launch/uninstall cycle from a non-elevated user context.
Re-run the existing app regression baseline so packaging work does not quietly break the app itself.
Check that mutable app data remains user-scoped and is not removed accidentally on uninstall.
After first launch, inspect the install root for app-created runtime caches (especially WebView2 *.exe.WebView2 folders). If launch repopulates the install directory, the lifecycle is not clean enough to trust.

Good signs

No UAC prompt during install or uninstall
Install location is under a user profile path rather than Program Files
Release output contains the MSI only, with no external cabinet beside it
Installed app launches successfully from the installed path or shortcut
Existing solution tests and Web UI build still pass
First launch does not create runtime profile/cache data under the install folder

Anti-patterns

Trusting an MSI only because the file exists
Assuming Compressed="yes" or a MediaTemplate change automatically means "single-file MSI" without checking the actual build output
Building the installer from hand-staged binaries outside the repo workflow
Verifying the build output directory but never launching the installed copy
Allowing uninstall to remove user data without an explicit, documented choice
Ignoring framework-default runtime caches that respawn inside the install folder after launch

---name: per-user-msi-review-gatedescription: How to gate a Windows MSI installer that must install without admin access--- ## Context Use this when a desktop app adds an MSI installer and the slice specifically requires standard-user, non-admin installation. ## Pattern 1. Require one repo-root build command that produces the MSI artifact deterministically. 2. Verify installer metadata really declares per-user scope and limited privileges for the packaging tool in use. 3. Treat the installed payload as the product: confirm the installed directory contains the app exe, runtime files, bundled content, and supporting assemblies. 4. If the ask is for a single-file MSI, verify the Release output directory contains the `.msi` and no sibling external `.cab`; do not infer this only from WiX metadata. If possible, corroborate with the built MSI `Media` table showing an embedded cabinet entry such as `#cab1.cab`. 5. Run one install/launch/uninstall cycle from a non-elevated user context. 6. Re-run the existing app regression baseline so packaging work does not quietly break the app itself. 7. Check that mutable app data remains user-scoped and is not removed accidentally on uninstall. 8. After first launch, inspect the install root for app-created runtime caches (especially WebView2 `*.exe.WebView2` folders). If launch repopulates the install directory, the lifecycle is not clean enough to trust. ## Good signs - No UAC prompt during install or uninstall - Install location is under a user profile path rather than `Program Files` - Release output contains the MSI only, with no external cabinet beside it - Installed app launches successfully from the installed path or shortcut - Existing solution tests and Web UI build still pass - First launch does not create runtime profile/cache data under the install folder ## Anti-patterns - Trusting an MSI only because the file exists - Assuming `Compressed="yes"` or a `MediaTemplate` change automatically means "single-file MSI" without checking the actual build output - Building the installer from hand-staged binaries outside the repo workflow - Verifying the build output directory but never launching the installed copy - Allowing uninstall to remove user data without an explicit, documented choice - Ignoring framework-default runtime caches that respawn inside the install folder after launch

Frequently asked questions