| name | release |
| description | Release a new version of memradar to npm and GitHub in one flow — bumps package.json, runs the full test harness, publishes to npm, then pushes commit + tag to GitHub. Use when the user says "릴리즈", "릴리스", "배포", "새 버전", "publish", "release", or similar in the memradar repo. |
memradar Release
This skill releases a new version of memradar to npm and pushes the version commit + tag to GitHub, in one flow. It is scoped to this repository (on1659/memradar).
Arguments
The skill may receive an argument string. Parse these tokens (any order, all optional):
- Bump level:
patch | minor | major | an explicit semver like 0.2.0
- Flags:
--skip-tests (skips npm run test:harness — use only if tests are already known green)
- Anything else: treat as the release description (one-line commit message suffix)
If bump level is missing, ask the user via AskUserQuestion with options patch / minor / major. Also ask for a one-line description if it isn't in the args. Never guess either.
Preflight (all must pass — run in parallel)
Run these Bash checks together in a single message:
git rev-parse --abbrev-ref HEAD — must be master. If not, STOP and tell the user.git status --porcelain — must be empty. If dirty, STOP and list the dirty files; ask the user to commit/stash first. Never auto-commit.git fetch origin master && git rev-list --left-right --count HEAD...origin/master — local must not be behind origin. If behind, STOP and ask user to pull.npm whoami — must succeed. If it fails, STOP and tell the user to run npm login (this skill does not log in for them).git remote get-url origin — must contain on1659/memradar. If not, STOP (wrong repo).node -p "require('./package.json').version" — read current version for the confirmation prompt.
If any check fails, report concisely and stop. Do not attempt to auto-remediate.
Confirmation
Before making any changes, show the user:
Current: <current version>
Target: <new version> (<bump level>)
Description: <description>
Branch: master @ <short sha>
npm user: <whoami>
Tests: <run | skip>
Ask for explicit approval via AskUserQuestion (options: Proceed / Cancel). Do not proceed on ambiguity.
Flow (stop immediately on any failure)
-
Tests (unless --skip-tests):
npm run test:harness
— this is lint + build + CLI smoke + Playwright e2e. Takes a few minutes.
-
Version bump + commit + tag (atomic, via npm):
npm version <level> -m "%s — <description>"
— creates commit 0.2.0 — <description> and annotated tag v0.2.0, matching existing commit style (see git log).
— If an explicit semver was passed instead of a level, use npm version <version> -m "%s — <description>".
-
Publish to npm:
npm publish --access public
— npm version already ran the build via tests or we rely on the publish script. If files: ["dist","cli"] requires dist/ present, ensure npm run build has run. When --skip-tests is used, run npm run build explicitly before publish.
-
Push to GitHub (commit + tag together):
git push origin master --follow-tags
Post-verify (run in parallel)
npm view memradar version — must equal the new version (npm registry propagation is usually instant but can take ~30s).- Print these URLs for the user:
https://www.npmjs.com/package/memradar/v/<new version>https://github.com/on1659/memradar/releases/tag/v<new version> (note: a GitHub Release object is not created automatically by this flow — only the git tag. Mention this.)
- Suggest
npx memradar@<new version> for smoke verification.
Safety rules (hard)
- Never force-push.
- Never skip git hooks (
--no-verify forbidden).
- Never run
git push without --follow-tags in this flow — tag and commit must land together.
- Never run
npm unpublish — if the user wants to revert, advise publishing a patch version instead (npm disallows unpublish after 72h anyway).
- If
npm publish succeeds but git push fails, STOP and tell the user: the npm registry has the new version but GitHub doesn't. They must resolve (usually git push origin master --follow-tags after fixing the cause). Do not try to unpublish.
- If tests fail, STOP. Don't offer
--skip-tests as an escape hatch unless the user explicitly asks.
Rollback hints (only if the user asks)
- Before
npm publish (bump committed + tagged locally but nothing pushed/published yet):
git tag -d v<new version> && git reset --hard HEAD~1
- After
npm publish, before git push: do NOT unpublish. Just retry the push.
- After both succeed: publish a fixed patch version; do not try to rewrite history.
What this skill does NOT do
- Does not commit uncommitted working-tree changes (preflight stops on dirty tree).
- Does not create a GitHub Release object — only pushes the git tag. If the repo's GitHub Actions release workflow (
.github/workflows/release.yml) is active with NPM_TOKEN set up, pushing the tag would cause a duplicate publish attempt. Warn the user before pushing if they have that workflow enabled and NPM_TOKEN is registered — in that case this skill is redundant and they should use either this local flow OR the workflow, not both.
- Does not run
npm login.
- Does not modify changelogs or docs — user handles those in their own commits before invoking this skill.
