after-production-releaselisted

What to tell the user right after publishing a noisy-coding release — derive the minimal refresh steps (image? plugin? per-session reloads?) from what actually changed and present them as a short spoken summary plus a bulleted console checklist. Use every time a release/tag is pushed, when the user asks "what do I need to do now?", or after the Docker image lands on the Hub.
noisy/noisy-coding · ★ 9 · AI & Automation · score 72

Install: claude install-skill noisy/noisy-coding

# After a production release: tell the user exactly how to refresh Every release ends with the same user question: *"what do I do now?"* Sometimes it is one step, sometimes three — never make the user derive it. After the image lands on Docker Hub (verify — don't announce before the build is green), ALWAYS deliver: 1. **aloud**: one sentence naming the release and how many steps it costs ("2.7.7 — one command, container only"); speak the user's language, the examples here are just templates; 2. **in the console**: a numbered checklist of ONLY the required steps, in order, with nothing optional mixed in. ## Deriving the steps — look at what the release actually changed | Changed in this release | Required step | |---|---| | `src/noisy_coding/**`, `Dockerfile`, `dashboard/**` | **container**: `/noisy-coding:update` once, any production thread (pulls, quotes Highlights, recreates; volume/key survives) | | `hooks/**`, `commands/**`, `skills/**`, `.claude-plugin/**` (plugin payload) | **plugin**: `claude plugin update noisy-coding@noisy` — ONCE PER PROFILE (work + `CLAUDE_CONFIG_DIR=~/.claude-personal` for personal) | | plugin payload (as above) | **reload**: `/reload-plugins` (or restart) IN EVERY LIVE SESSION — sessions opened after the update pick it up themselves | Compose the checklist from the rows that apply. Common shapes: - **Image-only** (daemon/server/dashboard fix): 1 step — `/noisy-coding:update`. - **Plugin-only** (hooks/commands/skills): 2 steps × pro