Skip to main content

release

Run the dev-process-kit release flow end-to-end. Use when the user asks to release patch, minor, major, beta, or an explicit semver; bumps the version with `npm version`, pushes the signed tag, watches the Release workflow that publishes to npm, and publishes the GitHub Release.

소스 정보

저장소
d-kimuson/dev-process-kit
최근 소스 활동
2026년 9월 24일 02:30
감지된 SKILL.md 언어
영어
스타
4
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
release
description
Run the dev-process-kit release flow end-to-end. Use when the user asks to release patch, minor, major, beta, or an explicit semver; bumps the version with `npm version`, pushes the signed tag, watches the Release workflow that publishes to npm, and publishes the GitHub Release.
metadata
{"internal":true}
# dev-process-kit Release A release is a version of the npm package `dev-process-kit`. Pages load it from jsDelivr pinned to that exact version, and its documentation is `docs/` at the `v<version>` tag, so a published version is never changed: a fix is a new version. ## Inputs Interpret the user's argument as the release version spec: | Spec | `npm version` argument | Example | | --------------------------- | ------------------------- | ------------------------------------------------- | | `patch` / `minor` / `major` | the same | `0.1.0` → `0.1.1`; `0.1.1-beta.2` → `0.1.1` | | `beta` | `prerelease --preid beta` | `0.1.0` → `0.1.1-beta.0`; `…-beta.0` → `…-beta.1` | | an explicit semver | the version | `0.2.0`, `0.2.0-beta.0` | If no version spec is present, ask the user which one to use. A `beta` goes to the npm dist-tag `beta`, so `@latest` is untouched; use it to try a build from a real Artifact before releasing it. ## Preconditions 1. Work from the repository root on `main`, with a clean working tree: ```bash git branch --show-current git status --short ``` 2. If there are unrelated uncommitted changes, stop and ask the user how to handle them. Commit release-related changes first: `npm version` refuses a dirty tree. 3. The commit and the tag are signed with SSH: ```bash git config --get gpg.format # ssh git config --get commit.gpgsign # true git config --get tag.gpgsign # true ``` 4. The npm package exists and has a trusted publisher for `.github/workflows/release.yml`. The first version is published by hand, because npm cannot configure a trusted publisher for a package that does not exist yet. ## Release command ```bash npm version <argument> -m "chore: release v%s" git push --follow-tags ``` `npm version` runs the `preversion` script first (lint, typecheck, test, build), then updates `package.json`, creates the signed commit `chore: release v<version>` and the signed annotated tag `v<version>`. `--follow-tags` pushes the commit together with that tag. If the push fails, the commit and the tag already exist locally. Fix the cause and push again; do not rerun `npm version`. ## Monitor GitHub Actions The tag triggers the Release workflow, which builds, strips the development fields from `package.json` (`clean-pkg-json`) and publishes with provenance under the dist-tag of the version (`latest`, or `beta` for a prerelease). ```bash TAG="v0.0.0" # replace RUN_ID="$(gh run list --workflow Release --limit 20 --json databaseId,headBranch,event --jq ".[] | select(.headBranch == \"$TAG\" and .event == \"push\") | .databaseId" | head -n 1)" test -n "$RUN_ID" && gh run watch "$RUN_ID" --exit-status ``` If the workflow fails, inspect the logs before taking corrective action: ```bash gh run view "$RUN_ID" --log-failed ``` A version npm has not published can be retried by rerunning the workflow. Once npm has it, the number is spent: release the fix as the next version. ## Verify publish ```bash VERSION="0.0.0" # replace npm view "dev-process-kit@$VERSION" version npm dist-tag ls dev-process-kit curl -sfI "https://cdn.jsdelivr.net/npm/dev-process-kit@$VERSION/dist/index.js" | head -n 1 curl -sfI "https://raw.githubusercontent.com/d-kimuson/dev-process-kit/v$VERSION/docs/index.md" | head -n 1 ``` The last two are what a consumer loads: the bundle from jsDelivr and the documentation at the tag. ## GitHub Release Create the release from the tag with generated notes as a draft, then rewrite the notes: ```bash TAG="v0.0.0" # replace gh release create "$TAG" --verify-tag --draft --generate-notes $([[ "$TAG" == *-* ]] && echo --prerelease) gh release view "$TAG" --json body --jq .body ``` Rewrite the notes for people who generate pages with dev-process-kit: - Use concise, user-focused English. - Prefer these sections when relevant: `Features`, `Bug Fixes`, `Breaking Changes`, `Internal`. - Describe the impact on pages and on the public contract (elements, attributes, events, slots), not implementation details. - Remove trivial items such as formatting, typo-only, dependency-only and purely internal refactors unless they affect users. - Merge intermediate same-release fixes into their related feature or fix. Publish the draft with the rewritten notes: ```bash NOTES_FILE="/tmp/dev-process-kit-$TAG-release-notes.md" # write it with the file tool gh release edit "$TAG" --notes-file "$NOTES_FILE" --draft=false gh release view "$TAG" --json tagName,isDraft,isPrerelease,url ``` ## Final report Report: - released tag/version and its npm dist-tag - the `npm version` command used - GitHub Actions run ID and result - npm and jsDelivr verification results - GitHub Release URL and draft/public state - any follow-up commits created for release automation or this skill
GitHub에서 보기