Proposal: add `npx @blader/humanizer` installer

[shawnyeager]

Hi @blader — opening this as a proposal before sending a PR, because adding Node tooling to a Markdown-only repo is a real shape change and I want to confirm direction with you first.

What

Add a tiny zero-dep Node CLI so users can run:

npx @blader/humanizer            # install (auto-detects Claude Code / OpenCode)
npx @blader/humanizer upgrade
npx @blader/humanizer uninstall

The CLI copies the bundled SKILL.md into ~/.claude/skills/humanizer/ and/or ~/.config/opencode/skills/humanizer/. SKILL.md stays the single source of truth — package.json's version is derived from its frontmatter via prepublishOnly.

Why

Issue #104 ("code for claude not able to download") points at install friction with the current git clone flow. npx is the Node-ecosystem standard for one-command installs, and several adjacent skill projects already ship this way:

• vercel-labs/skills — npx skills add <repo> -a claude-code
• numman-ali/openskills — npx openskills install <source>

Neither is a single-skill installer like this would be, but both validate the pattern.

Shape (strictly additive)

• New files only: package.json, bin/humanizer.mjs (~360 LOC, zero runtime deps), bin/humanizer.test.mjs (38 tests covering install/upgrade/uninstall + helpers + symlink defense), scripts/sync-version.mjs, .gitignore, .github/workflows/test.yml, .github/workflows/publish.yml.
• Existing files: only README.md is modified, additively (a new "Quick install" section above the current ## Installation section). The existing git clone instructions stay untouched. SKILL.md, WARP.md, and LICENSE are unchanged.
• Releases use npm OIDC trusted publishing with a one-time "pending publisher" configuration on npmjs.com — no NPM_TOKEN secret in the repo, ever. First-time setup takes about two minutes; every subsequent release is just git tag vX.Y.Z && git push --tags.

On PR #63

I noticed #63 was closed with "no longer matches the repo's current direction." I read that as a soft no on infrastructure-first scaffolding rather than a no on packaging in general. This proposal is intentionally framed differently: user-pain-led (installer fixes #104), strictly additive (no plugin manifests, no marketplace JSON, no skill content changes), and small enough to audit by eye.

If the framing or scope still doesn't fit, I'd rather hear that now than land a PR that bounces.

Implementation status

I have the full implementation ready to PR from my fork (shawnyeager/humanizer:feat/npx-installer) — 8 files, 956 insertions, 0 deletions. Tests pass on Linux locally; CI matrix covers Linux + Windows.

One question

Are you happy with this shape, or would you prefer something different? Some axes I can adjust:

• npm name — I assumed @blader/humanizer since that's the cleanest match to the repo. Unscoped humanizer is taken on npm. If you'd prefer a different scope or are okay creating a @blader org, just say.
• CI in v1 — happy to drop the GitHub Actions workflows and ship just the package + bin if you'd rather add CI yourself later.
• Smaller surface — could ship install only and drop upgrade/uninstall if you want a smaller initial contract.

Thanks for considering it.