Changelog Generator
Git 히스토리에서 사람이 읽기 좋은 체인지로그를 자동 생성합니다. Keep a Changelog 포맷을 따르며, 커밋 메시지를 사용자 친화적인 언어로 다듬고, 선택적으로 GitHub 릴리스를 생성합니다.
입력 해석
주요 입력은 Git 참조 범위입니다. 인수가 제공된 경우 다음과 같이 해석합니다:
...또는..포함 -> Git 참조 범위 (예:v1.0.0...v1.1.0)- 단일 태그/참조와 일치 -> 해당 참조에서 HEAD까지
- GitHub URL 또는
#\d+패턴과 일치 -> PR (해당 PR의 변경 사항만 추출). 단일 PR 입력의 경우: PR diff와 설명을 읽고 변경 사항을 분류하며, PR 제목을 항목으로 사용합니다. 버전 헤더는 건너뜁니다. 사용자에게 이 항목을 기존 체인지로그 버전에 추가할지 또는 새 버전을 만들지 물어봅니다. - 인수 없음 -> "체인지로그가 다룰 범위는 무엇인가요? Git 참조 범위(예: v1.0.0...v1.1.0), 태그(해당 태그 이후 변경 사항), 또는 PR 번호를 입력할 수 있습니다."라고 물어봅니다.
프로세스 흐름
digraph changelog {
rankdir=TB;
"입력 해석" [shape=box];
"1단계: 수집" [shape=box];
"2단계: 분류" [shape=box];
"3단계: 다듬기" [shape=box];
"4단계: 검토" [shape=box];
"승인됨?" [shape=diamond];
"5단계: 출력" [shape=box];
"입력 해석" -> "1단계: 수집";
"1단계: 수집" -> "2단계: 분류";
"2단계: 분류" -> "3단계: 다듬기";
"3단계: 다듬기" -> "4단계: 검토";
"4단계: 검토" -> "승인됨?";
"승인됨?" -> "3단계: 다듬기" [label="수정 요청"];
"승인됨?" -> "5단계: 출력" [label="예"];
}
단계를 건너뛰지 마십시오. 자연스러운 속도로 질문하십시오. 사용자가 한 번에 여러 질문에 답하면 번들로 받아들여 앞으로 건너뜁니다.
사용자가 "그냥 기본값을 선택해" 또는 이와 유사한 말을 하면, 합리적인 기본값을 선택하고, 선택한 내용을 설명한 후 단일 확인을 요청합니다.
1단계: 수집
1단계 - 커밋 및 PR 수집
두 참조 사이에 git log를 실행하여 모든 커밋을 수집합니다. 저장소가 PR을 사용하는 경우 gh pr list --state merged를 사용하여 해당 범위 내 병합된 PR도 확인합니다.
각 커밋/PR에 대해 다음을 추출합니다:
- 커밋 메시지 (제목 + 본문)
- 변경된 파일 (범위 결정)
- PR 제목 및 설명 (가능한 경우)
- 관례적 커밋 유형 접두사 (feat, fix, chore 등)
2단계 - 광범위한 제품 컨텍스트 읽기
존재하는 경우 다음을 읽습니다: README, package.json (또는 이와 동등한 파일). 목표: 사용자 친화적인 설명을 작성하기 위해 제품이 무엇인지 이해합니다.
찾을 수 없는 경우: "제품에 대해 간략히 설명해 주시겠어요? 사용자 친화적인 체인지로그 항목을 작성하려면 컨텍스트가 필요합니다."라고 물어봅니다.
3단계 - 기존 포맷 감지
저장소에 기존 CHANGELOG.md가 있는지 확인합니다. 있는 경우:
- 포맷 감지 (Keep a Changelog, 사용자 정의 등)
- 이모지 레이블(예: New, Bug fix, Breaking에 대한 이모지) 또는 일반 텍스트 카테고리를 사용하는지 감지
- 기존 스타일과 일치시킵니다.
기존 체인지로그가 없는 경우:
- 기본값으로 Keep a Changelog 포맷 사용
- "기존 체인지로그가 없습니다. 이모지 레이블(예: New, Bug fix)을 선호하시나요, 아니면 일반 텍스트 카테고리(Added, Fixed 등)를 선호하시나요?"라고 물어봅니다.
2단계: 분류
모든 변경 사항을 Keep a Changelog 카테고리로 정렬합니다. Breaking Changes는 상단에 전용 섹션을 둡니다:
- Breaking Changes - 기존 동작, API를 중단하거나 업그레이드에 사용자 작업이 필요한 변경 사항. 각 항목에 마이그레이션 노트를 포함합니다.
feat!:,fix!:,BREAKING CHANGE:바닥글, 또는 diff에서 제거되거나 이름이 변경된 API를 통해 감지합니다. - Added - 새로운 기능
- Changed - 기존 기능에 대한 변경 사항
- Deprecated - 제거될 기능
- Removed - 제거된 기능
- Fixed - 버그 수정
- Security - 취약점 수정
분류 규칙:
- 커밋이 관례적 커밋(
feat:,fix:등)을 따르는 경우, 유형을 사용하여 분류 - 그렇지 않은 경우, diff 및 커밋 메시지를 분석하여 카테고리 결정
- 사용자에게 영향을 미치지 않는 내부 전용 변경 사항(리팩터링, 테스트 추가, CI 변경, 종속성 범프)은 건너뜁니다.
- 변경 사항이 사용자에게 노출되는지 확실하지 않은 경우 포함시키고, 검토 중에 사용자가 제거할 수 있도록 합니다.
- 커밋이 50개 이상인 범위의 경우, 관련 변경 사항을 상위 수준 항목으로 그룹화합니다(예: 12개의 개별 API 수정을 나열하는 대신 "여러 엔드포인트에서 API 오류 처리 개선"으로 작성). 그룹화된 버전을 제시하고 사용자가 세부 정보를 원할 경우 그룹을 확장할 수 있도록 합니다.
분류된 목록을 제시합니다:
"이 범위에서 찾은 내용입니다:"
Added (3)
- 기능 A
- 기능 B
- 기능 C
Fixed (2)
- 버그 수정 A
- 버그 수정 B
"추가, 제거 또는 재분류할 사항이 있나요?"
사용자가 확인할 때까지 진행하지 마십시오.
3단계: 다듬기
각 항목을 사용자 친화적인 언어로 다시 작성합니다:
- 구현 세부 사항이 아닌 사용자 혜택을 먼저 제시합니다.
- "보고서 로딩 속도가 3배 빨라졌습니다" ("보고 모듈을 위한 SQL 쿼리 실행 계획 최적화" 아님)
- "이제 보고서를 PDF로 내보낼 수 있습니다" ("보고 서비스에 PDF 내보내기 기능 추가" 아님)
- 각 항목을 한 줄로 유지합니다(복잡한 변경 사항의 경우 최대 두 줄).
- 가능한 경우 PR/이슈 참조를 포함합니다(예:
(#123)).
버전 헤더
포맷: ## [버전] - YYYY-MM-DD
범위의 상한이 버전 태그(예: v1.2.0)인 경우, 해당 버전을 사용합니다. 상한이 HEAD 또는 브랜치 이름인 경우: "이 체인지로그에 사용할 버전 번호는 무엇인가요?"라고 물어봅니다.
범위 내 가장 최근 커밋의 날짜를 ISO 형식(YYYY-MM-DD)으로 사용합니다.
기술 부록
사용자 친화적인 체인지로그를 생성한 후, 다음과 같이 물어봅니다:
"기술 부록도 생성할까요? (개발자 대상 문서에 유용합니다)"
예라고 답하면, 기술적 세부 사항, Breaking Changes 마이그레이션 가이드 및 API 변경 사항이 포함된 더 자세한 섹션을 생성합니다.
작성 규칙
- 생성된 콘텐츠에 긴 대시(
---)를 절대 사용하지 마십시오. 대신 쉼표, 콜론, 마침표 또는 괄호를 사용하십시오. - 기본적으로 사용자 친화적인 언어 사용(전문 용어, 내부 기능 이름 없음)
- 항목당 한 줄, 복잡한 변경 사항의 경우 최대 두 줄
- 일관된 동사 시제(과거 시제: "Added", "Fixed", "Removed")
- 가능한 경우 PR/이슈 참조 포함
4단계: 검토
완전한 체인지로그 항목을 제시합니다:
"체인지로그입니다:"
## [1.2.0] - 2026-04-11 ### Added - 이제 보고서를 PDF로 내보낼 수 있습니다 (#123) ### Fixed - 페이지 로드 시 대시보드가 더 이상 깜빡이지 않습니다 (#456)"변경할 사항이 있나요?"
승인을 기다립니다. 사용자가 확인한 후에만 출력 단계로 진행합니다.
5단계: 출력
CHANGELOG.md
저장소 루트에서 기존 CHANGELOG.md를 감지합니다. 찾은 경우, 전체 파일을 읽고, 삽입 지점(첫 번째 ## [ 줄 앞)을 식별하고, 제안된 삽입 지점을 사용자에게 제시한 후 쓰기 전에 확인합니다. 찾지 못한 경우, 표준 헤더와 함께 새로 생성합니다:
# Changelog
이 프로젝트의 모든 주요 변경 사항은 이 파일에 기록됩니다.
포맷은 [Keep a Changelog](https://keepachangelog.com/)을 기반으로 합니다.
항상 쓰기 전에 확인합니다:
"이 내용을
CHANGELOG.md앞부분에 추가하겠습니다. 괜찮으신가요?"
GitHub 릴리스
체인지로그를 저장한 후, 물어봅니다:
"이 체인지로그로 GitHub 릴리스도 생성할까요?"
예라고 답하면, gh release create <태그> --notes "<체인지로그 내용>" 명령을 사용하여 릴리스를 생성합니다. gh를 사용할 수 없는 경우 사용자에게 알리고 건너뜁니다.
오류 처리
gh를 사용할 수 없는 경우 -> 사용자에게 알리고 PR 보강 및 GitHub 릴리스를 건너뛰며, git log만 사용- 유효하지 않은 참조/태그 -> 사용자에게 확인 요청
- 범위에 커밋이 없는 경우 -> 사용자에게 알리고 범위 확인 요청
- 제품 컨텍스트가 없는 경우 -> 사용자에게 제품 설명 요청
- 관례적 커밋이 아닌 경우 -> 분류를 위해 diff 분석으로 대체
이 스킬이 수행하지 않는 작업
- 버전 관리 전략 관리 (시맨틱 버전 관리 결정은 사용자의 몫)
- 패키지 레지스트리에 게시
- 블로그 게시물 또는 뉴스레터 생성 (
/blog-post또는/newsletter사용) - 브랜치 전략 또는 릴리스 워크플로우 처리