릴리스 스킬
저장소 인식 기반의 가벼운 릴리스 어시스턴트입니다. 처음 실행 시 프로젝트와 CI를 검사하여 릴리스 규칙을 도출하고, 이를 .omc/RELEASE_RULE.md에 저장하여 이후에 사용합니다. 그런 다음 해당 규칙을 사용하여 릴리스를 안내합니다.
사용법
/oh-my-claudecode:release [version]
version은 선택 사항입니다. 생략하면 스킬이 물어봅니다.patch,minor,major또는2.4.0과 같은 명시적인 semver를 허용합니다.--refresh를 추가하면 캐시된 규칙 파일이 있어도 저장소를 강제로 다시 분석합니다.
실행 흐름
단계 0 — 릴리스 규칙 로드 또는 빌드
.omc/RELEASE_RULE.md 파일이 있는지 확인합니다.
파일이 존재하지 않는 경우(또는 --refresh가 전달된 경우): 아래 전체 저장소 분석을 실행하고 파일을 작성합니다.
파일이 존재하는 경우: 파일을 읽습니다. 그런 다음 빠른 델타 검사를 수행합니다 — .github/workflows/(또는 이에 준하는 CI 디렉토리: .circleci/, .travis.yml, Jenkinsfile, bitbucket-pipelines.yml, gitlab-ci.yml)를 스캔하여 규칙 파일의 last-analyzed 타임스탬프보다 최근에 수정된 파일이 있는지 확인합니다. 관련 워크플로 파일이 변경된 경우 해당 섹션에 대한 분석을 다시 실행하고 파일을 업데이트합니다. 변경된 사항을 보고합니다.
단계 1 — 저장소 분석 (첫 실행 또는 --refresh)
저장소를 검사하고 다음 질문에 답합니다. 답변을 .omc/RELEASE_RULE.md에 작성합니다.
1a. 버전 소스
package.json/pyproject.toml/Cargo.toml/build.gradle/VERSION파일 등에서 현재 버전과 일치하는 버전 문자열을 포함하는 모든 파일을 찾습니다.- 각 파일과 버전을 찾는 데 사용된 필드 또는 정규식 패턴을 나열합니다.
- 릴리스 자동화 스크립트가 있는지 감지합니다 (예:
scripts/release.*,Makefile release타겟,bump2version,release-it,semantic-release,changesets,goreleaser).
1b. 레지스트리 / 배포
- npm (
publishConfig가 있는package.json또는 CI에서npm publish), PyPI (pyproject.toml+twine/flit), Cargo (Cargo.toml), Docker (Dockerfile+ 푸시 단계), GitHub Packages, 기타. - 태그 푸시 시 자동으로 게시하는 CI 단계가 있습니까? 어떤 워크플로 파일과 작업인가요?
1c. 릴리스 트리거
- 릴리스를 시작하는 것을 식별합니다: 태그 푸시 (
v*), 수동 디스패치 (workflow_dispatch), 메인/마스터로 병합, 릴리스 브랜치 병합, 커밋 메시지 패턴.
1d. 테스트 게이트
- 테스트 명령과 CI에서 실행되는 위치를 식별합니다.
- 게시 전에 테스트 통과가 필수인가요? 우회 플래그가 있다면 기록합니다.
1e. 릴리스 노트 / 체인지로그
CHANGELOG.md또는CHANGELOG.rst가 존재합니까?- 어떤 규칙을 사용합니까: Keep a Changelog, Conventional Commits, GitHub 자동 생성, 없음?
- 태그 이전에 커밋된 릴리스 본문 파일이 있습니까 (예:
.github/release-body.md)?
1f. 첫 사용자 확인
.github/workflows/(또는 이에 준하는 디렉토리)에 릴리스 워크플로가 존재합니까? 존재하지 않으면 플래그를 지정하고 스캐폴딩을 제안합니다.- 빌드 아티팩트가 커밋되지 않도록
.gitignore항목이 있습니까? 없으면 플래그를 지정합니다. - Git 태그가 사용되고 있습니까?
git tag --list를 실행하여 확인합니다. 태그가 없으면 플래그를 지정하고 모범 사례를 설명합니다.
단계 2 — .omc/RELEASE_RULE.md 작성
다음 구조로 파일을 생성하거나 덮어씁니다:
# 릴리스 규칙
<!-- last-analyzed: YYYY-MM-DDTHH:MM:SSZ -->
## 버전 소스
<!-- 파일 + 패턴 목록 -->
## 릴리스 트리거
<!-- 릴리스를 시작하는 항목 -->
## 테스트 게이트
<!-- 명령 + CI 작업 이름 -->
## 레지스트리 / 배포
<!-- npm, PyPI, Docker 등 + 게시하는 CI 작업 -->
## 릴리스 노트 전략
<!-- 규칙 + 파일 -->
## CI 워크플로 파일
<!-- 관련 워크플로 파일의 경로 -->
## 첫 설정 격차
<!-- 분석 중 발견된 누락된 부분, 또는 "없음" -->
단계 3 — 버전 결정
사용자가 버전 인수를 제공한 경우 이를 사용합니다. 그렇지 않은 경우:
- 현재 버전(기본 버전 파일에서)을 표시합니다.
patch,minor,major가 각각 어떤 버전이 될지 보여줍니다.- 사용자에게 사용할 버전을 묻습니다.
선택한 버전이 유효한 semver 문자열인지 확인합니다.
단계 4 — 릴리스 전 체크리스트
릴리스 규칙에서 파생된 체크리스트를 제공합니다. 최소한 다음을 포함합니다:
- 이번 릴리스에 포함된 모든 변경 사항이 커밋되고 푸시되었습니다.
- 대상 브랜치에서 CI가 정상입니다.
- 로컬에서 테스트가 통과합니다(테스트 게이트 명령 실행).
- 모든 버전 소스 파일에 버전 업데이트가 적용되었습니다.
- 릴리스 노트/체인지로그가 준비되었습니다(단계 5 참조).
진행하기 전에 사용자에게 확인을 요청하거나, 사용자가 "계속 진행"이라고 말하면 각 단계를 실행합니다.
단계 5 — 릴리스 노트 가이드
사용자가 좋은 릴리스 노트를 작성할 수 있도록 도와줍니다. 저장소에서 사용하는 규칙을 적용합니다. 규칙이 감지되지 않은 경우 기본 가이드:
좋은 릴리스 노트의 조건:
- 내부 구현 세부 사항이 아닌 사용자를 위해 변경된 사항을 먼저 서술합니다.
- 유형별로 그룹화합니다:
새로운 기능,버그 수정,호환되지 않는 변경 사항,폐기 예정,내부 / 작업. - 각 항목: 한 문장으로, PR 또는 이슈에 대한 링크를 포함하고 외부 기여자의 경우 작성자를 표시합니다.
- 호환되지 않는 변경 사항은 먼저 나열되어야 하며 마이그레이션 경로를 포함해야 합니다.
- 사용자가 절대 볼 수 없는 변경 사항(리팩터링, CI 조정, 테스트 전용 변경)은 빌드 재현성에 영향을 미치지 않는 한 생략합니다.
항목 형식 예시:
### 버그 수정
- 토큰 만료 시 세션 드롭 수정 (#123) — @기여자
저장소가 Conventional Commits을 사용하는 경우, git log <이전-태그>..HEAD --no-merges --format="%s"에서 커밋 유형별로 그룹화된 드래프트 체인지로그를 생성합니다. 사용자에게 보여주고 편집할 수 있도록 합니다.
단계 6 — 릴리스 실행
발견된 규칙을 사용하여 다음 단계를 진행합니다:
- 버전 업데이트 — 각 버전 소스 파일에 적용합니다.
- 테스트 실행 — 테스트 게이트 명령을 실행합니다.
- 커밋 —
git add <버전 파일> CHANGELOG.md실행 후chore(release): vX.Y.Z 버전으로 업데이트메시지로 커밋합니다. - 태그 —
git tag -a vX.Y.Z -m "vX.Y.Z"(경량 태그보다 주석 태그를 선호합니다). - 푸시 —
git push origin <브랜치> && git push origin vX.Y.Z. - CI가 처리 — 릴리스 트리거가 태그 푸시인 경우, 나머지 작업(게시, GitHub 릴리스 생성)은 CI가 처리할 것임을 사용자에게 상기시킵니다. 예상되는 CI 워크플로 파일을 보여줍니다.
- 수동 게시 — CI 자동화가 없는 경우, 수동 게시 명령을 나열합니다 (예:
npm publish --access public,twine upload dist/*).
단계 7 — 첫 설정 제안
단계 1f에서 격차가 발견된 경우 구체적인 도움을 제공합니다:
릴리스 워크플로 없음:
저장소에 릴리스 CI 워크플로가 없습니다.
v*태그 푸시 시 트리거되는 GitHub Actions 워크플로가 가장 일반적인 모범 사례입니다. 다음을 수행할 수 있습니다:
- 테스트 실행
- npm/PyPI 등에 게시
- 릴리스 노트로 GitHub 릴리스 생성
스택에 맞는
.github/workflows/release.yml을 스캐폴딩할까요?
Git 태그 없음:
이것이 첫 번째 릴리스로 보입니다. Git 태그는 GitHub, npm 및 기타 도구가 버전 기록을 이해할 수 있게 해줍니다. 단계 6에서 첫 번째 태그를 생성하겠습니다.
빌드 아티팩트가 gitignore되지 않음:
빌드 아티팩트가 git 기록에 있거나 gitignore되지 않았습니다. 이는 저장소 크기를 증가시키고 병합 충돌을 유발합니다.
.gitignore에 추가할까요?
단계 8 — 확인
푸시 후:
- CI 상태 확인:
gh run list --workflow=<릴리스 워크플로> --limit=3(gh를 사용할 수 있는 경우). - 몇 분 후 레지스트리(npm, PyPI)에서 새 버전을 확인합니다.
- GitHub 릴리스가 생성되었는지 확인:
gh release view vX.Y.Z.
성공 또는 실패를 보고합니다.
참고 사항
- 이 스킬은 프로젝트별 버전 파일이나 명령을 하드코딩하지 않습니다. 모든 것은 저장소 검사에서 파생됩니다.
.omc/RELEASE_RULE.md는 로컬 캐시입니다. 팀과 파생된 규칙을 공유하려면 저장소에 커밋하고, 로컬로 유지하려면.gitignore에 추가하세요.- 복잡한 모노레포 또는 다중 패키지 워크스페이스의 경우 스킬이 워크스페이스 패턴(npm 워크스페이스, pnpm 워크스페이스, Cargo 워크스페이스)을 감지하여 그에 맞게 조정합니다.