win-hooks 1.12.0

One command, and it decides for you

There is one thing to run when a plugin breaks on Windows: /win-hooks:patch. It looks first, tells you what it found, repairs whatever is not healthy, and shows you the result. A healthy machine is reported and left alone.

Before this you had to choose. /win-hooks:status checked, /win-hooks:fix repaired, and knowing which one you needed was your problem - though nobody inspects hooks for their own sake, and a broken one was always going to be repaired. The order that made the pair usable lived as steps in a prompt, so it held only as long as the model followed it. It is now one path through the engine.

New

• /win-hooks:patch replaces status and fix, and the separate diagnose skill folds into it. A skill is a superset of a command: it takes the same arguments when you type it, and it also recognizes the error on its own when you paste one in.
• The symptom table, the issue vocabulary, and the repair steps are written once instead of across four files.

Also

• The test suite is a single Node program. Fixture plugins are data rather than scripts in a second language, leaving one deliberate .cmd shim where Windows itself requires one. Coverage: 27 of 27 testable cases, one waived in writing.
• win-hooks describes itself the same way wherever you meet it - the marketplace, both plugin manifests, npm, and the top of the README all read Windows auto-patcher for vibe coders. Every one is a copy of a single line in package.json, and a release refuses to build if any of them has drifted.

Everything win-hooks repairs is listed in the README.

Install

# Claude Code
claude plugin marketplace add LilMGenius/win-hooks && claude plugin install win-hooks

# Codex
codex plugin marketplace add LilMGenius/win-hooks && codex plugin add win-hooks@win-hooks

# or a one-shot CLI fix
npx @lilmgenius/win-hooks