deploylisted

**Scope — `deploy` is local only.** It makes the current code runnable *on this machine*: it installs the built app locally (Tauri / IntelliJ plugin / .NET) or starts the project's local server. It never ships anywhere public. Shipping outward is a different verb: | Means | Where it lives | | --- | --- | | Run it *here*, on this machine | this skill | | Cut a version: tag → CI → GitHub Release | the `release` skill | | Ship it outward, to where its users are | the `publish` skill, or the project's own CI | A project having both a local `deploy` and a publish path is normal and not a conflict — they are separate verbs with separate wrappers, so nothing outward-facing can happen from the command you run dozens of times a day. Which of the two publishes is a real decision, not a preference. CI builds a clean checkout with one pinned configuration; publishing from a working tree can let uncommitted work or the wrong environment's credentials reach production, and has. Where CI already publishes on push, the push *is* the ship and the project should have no local publish script at all. The `publish` skill exists for targets CI cannot reach on its own — chiefly a box you hold the SSH key for — and refuses to run on anything not committed and pushed. See `~/.claude/learnings/shell-environment.md` for the expected bash functions and verification checklist. ## Context - Deploy function in shell rc: !`cat ~/.bashrc ~/.zshrc ~/.bash_profile ~/.zprofile 2>/dev/null | grep -c "deploy