agentsclimarketplace

Release

Skill gagip/gagip-dev/.claude/skills/release

플러그인 릴리즈 전 과정을 수행하는 스킬. 스킬 검증 → 버전 업데이트 → CHANGELOG 작성 → 커밋 → 태그 → push 순으로 진행. "릴리즈해줘", "배포해줘", "버전 올려줘", "release 해줘", "publish 해줘", "버전 업데이트하고 배포해줘" 등의 표현이 나오면 반드시 이 스킬을 사용할 것.From its SKILL.md

Install
npx -y skills add gagip/gagip-dev --skill release

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.8 KB, ~2.1k tokens by cl100k_base, as published. Nobody here has run it

작업 순서

1. 사전 정보 수집 (자동)

아래 정보를 자동으로 수집한다.

플러그인 감지 — 변경된 파일 기준으로 자동 감지:

git diff --name-only HEAD~1..HEAD 2>/dev/null || git diff --name-only --cached
  • plugins/<name>/ 파일 변경 → 해당 <name> 플러그인 (디렉터리명이 곧 플러그인명, 하드코딩 금지)
  • 여러 플러그인 동시 변경 → 각 플러그인 모두 처리
  • plugins/ 외부 파일 변경(루트 .claude/ 등)은 릴리스 대상이 아니므로 무시한다

버전 유형 판단$ARGUMENTS에 버전 유형이 없으면 커밋 이력으로 자동 판단:

git log <마지막 태그>..HEAD --oneline 2>/dev/null || git log --oneline
  • feat!, fix!, BREAKING CHANGE 포함 → major
  • feat: 포함 → minor
  • 그 외 (fix:, chore:, docs: 등) → patch

신규 플러그인 예외 — 해당 플러그인의 기존 태그(<name>/v*)가 하나도 없으면 첫 릴리스다. 자동 범프하지 말고 plugin.json의 현재 버전을 그대로 첫 릴리스로 쓴다. 릴리스 계획에 "신규 플러그인 첫 릴리스 — 범프 없음"을 명시한다.

스킬 검증 — 대상 플러그인의 모든 SKILL.md 점검:

find plugins/<플러그인명>/skills -name "SKILL.md" 2>/dev/null

각 SKILL.md에 대해 frontmatter 필수 필드(name, description, allowed-tools)와 allowed-tools 일치 여부를 점검한다.

Critical 문제가 발견되면 즉시 중단하고 사용자에게 보고한다.

CHANGELOG 초안 작성 — 마지막 태그부터 HEAD까지 구현 커밋 이력을 분석해 초안을 메모리에 작성한다.

루트 CHANGELOG.md를 Read로 확인해 기존 형식을 그대로 따른다:

  • 헤더: ## [<플러그인명>/<새 버전>] — YYYY-MM-DD
  • 카테고리(해당하는 것만): ### ✨ New Features / ### 🐛 Bug Fixes / ### ♻️ Refactoring
  • 각 bullet 끝에 구현 커밋 short 해시를 ([hash])로 단다 — 릴리즈 커밋이 아닌 앞선 구현 커밋을 가리킨다 (자기 참조 금지)

2. 릴리즈 계획 확인 [STOP — 유일한 중단점]

수집한 모든 정보를 한 번에 출력하고 반드시 여기서 멈출 것:

릴리즈 계획
- 플러그인: <플러그인명>
- 현재 버전: <현재 버전>
- 새 버전: <새 버전> (<버전 유형>)
- 스킬 검증: ✅ 통과 (또는 ⚠️ 경고 N개)

[CHANGELOG 초안]
## [<플러그인명>/<새 버전>] — YYYY-MM-DD

### ✨ New Features
- ... ([`<구현 커밋 해시>`])

[커밋 메시지]
chore(<플러그인명>): 버전 <새 버전> 릴리즈

[Push 대상]
- 브랜치: <현재 브랜치>
- 태그: <플러그인명>/v<새 버전>

버전 유형을 바꾸려면 patch/minor/major 중 하나를 입력하세요.
승인하면 버전 업데이트 → CHANGELOG 저장 → 커밋 → 태그 → push까지 자동 진행합니다.
유형변경예시
majorx+1.0.00.2.1 → 1.0.0
minorx.y+1.00.2.1 → 0.3.0
patchx.y.z+10.2.1 → 0.2.2
x.y.z그대로 사용

수정 요청이 오면 반영한 뒤 다시 대기한다. 사용자가 명시적으로 진행("ok", "확인", "계속" 등)을 지시하기 전까지 3단계를 실행하지 말 것.


3. 실행 (승인 후 연속 진행)

사용자가 승인하면 아래 단계를 중단 없이 순서대로 자동 실행한다.

3-1. 버전 업데이트

plugin.json을 Read로 읽은 뒤 Edit으로 version 필드를 새 버전으로 수정:

plugins/<플러그인명>/.claude-plugin/plugin.json

3-2. CHANGELOG 저장

CHANGELOG 초안을 루트 CHANGELOG.md 최상단(기존 최신 항목 위)에 추가한다. 기존 항목과는 --- 구분선으로 나눈다. plugins/<플러그인명>/CHANGELOG.md는 건드리지 않고 루트만 갱신한다.

3-3. 커밋 생성

git add plugins/<플러그인명>/.claude-plugin/plugin.json CHANGELOG.md
git commit -m "chore(<플러그인명>): 버전 <새 버전> 릴리즈"

3-4. 태그 생성

git tag -a "<플러그인명>/v<새 버전>" -m "Release <플러그인명> v<새 버전>"

3-5. Push

push는 **개인 계정 gagip**로 한다. gh 활성 계정이 gagip가 아니면 gh auth switch --user gagip로 전환 후 push하고, 끝나면 원래 계정으로 복원한다.

git push origin <현재 브랜치>
git push origin "<플러그인명>/v<새 버전>"

4. 완료 알림

✅ 릴리즈 완료!

- 플러그인: <플러그인명>
- 버전: <이전 버전> → <새 버전>
- 태그: <플러그인명>/v<새 버전>
- 커밋: <short hash>

행동 원칙

  • 스킬 검증에서 Critical 문제가 있으면 즉시 중단하고 사용자에게 보고한다
  • 중단점은 2단계 한 번뿐이다. 승인 이후엔 끝까지 자동 진행한다
  • plugin.json 수정 전 반드시 Read로 현재 내용을 확인한다
  • 태그는 <플러그인명>/v<버전> 형식을 따른다
  • CHANGELOG는 루트 CHANGELOG.md의 기존 형식을 그대로 따른다 — 자체 형식을 만들지 않는다
  • push는 개인 계정 gagip로 한다 (다르면 전환 후 복원)

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 1 of the 12 instructions most ship operate skills give in ~2.1k tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07

  • Document a rollback plan before deploymentin 41 of 779, across 22 files
  • Update the changelogin 21 of 779, across 19 files
  • Run the test suitein 20 of 779
  • Create an annotated git taghere, and in 20 of 779
  • Clean up feature flags after full rolloutin 18 of 779, across 10 files
  • Verify deployment health after launchin 18 of 779, across 10 files
  • Test both feature flag statesin 17 of 779, across 9 files
  • Verify the working tree is cleanin 17 of 779
  • Make database migrations backward-compatiblein 16 of 779, across 8 files
  • Set up error monitoring before launchin 15 of 779, across 7 files
  • Monitor metrics at each rollout stagein 14 of 779, across 5 files
  • Create a GitHub releasein 14 of 779

Said here and by no other author read

  • detect modified plugins from recent commits
  • validate target plugin skill files
  • generate changelog draft from recent commit history
  • stop and present release plan to user
  • update version in plugin.json after approval
  • prepend changelog entry to root changelog

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,629. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.