| name | changelog-sync-after-ship |
| description | 기능을 출시(ship)한 직후, 마지막 태그 이후의 커밋을 훑어 CHANGELOG.md의 [Unreleased] 섹션에 사용자 관점 항목을 채우고 conventional commits를 반영할 때까지 반복하는 수동 루프입니다. 사용자가 "체인지로그 업데이트해줘", "방금 출시한 거 CHANGELOG에 반영해줘", "릴리스 노트 정리해줘", "CHANGELOG 동기화", "changelog sync after ship", "update the changelog for this release", "sync CHANGELOG after shipping"처럼 출시·머지 직후 변경 이력을 사용자 친화적으로 정리하고 싶을 때 사용하세요. (구분: README·API 레퍼런스·주석 등 일반 문서 동기화는 looping:docs-sync-after-edits, openapi.yaml 스펙 동기화는 looping:openapi-sync-until-valid, API 응답이 계약과 맞는지 검증은 looping:api-contract-until-match, 작성한 spec.md 체크리스트대로 구현은 looping:spec-first-ship) |
출시 후 체인지로그 동기화 (Changelog Sync After Ship)
기능을 출시한 뒤, CHANGELOG.md에 사용자 관점 항목이 들어가고 conventional commits가 반영될 때까지 반복합니다.
| 항목 | 값 |
|---|
| 카테고리 | 문서(Docs) |
| 트리거 | 수동(manual) — 사람이 직접 시작 (보통 출시·머지 직후) |
| 종료 조건(Exit) | 체인지로그가 이번 출시의 사용자에게 보이는 변경을 모두 다룰 때 |
| 반복 한도(Max iterations) | 3 |
| 매 반복 체크 명령 | git log -5 --oneline |
| 가드레일 | 강화됨(Hardened) |
| 지원 에이전트 | Claude Code · Cursor |
이 루프는 언제 쓰나
기능을 출시하거나 PR을 머지한 뒤, "CHANGELOG 업데이트는 다음에 해야지" 하고 미루다 변경 이력이 코드와 어긋나는 일이 흔합니다. 이 루프는 출시 직후 한 번 시작하면, 에이전트가 마지막 릴리스 태그 이후의 커밋을 훑어 → 사용자 관점으로 항목을 쓰고 → 형식을 검증하는 과정을 스스로 반복합니다. 커밋 메시지 그대로 베끼는 게 아니라, "사용자가 무엇을 새로 할 수 있게 됐는지" 언어로 옮기는 게 핵심입니다. 결과물은 Keep-a-Changelog 형식의 [Unreleased] 항목(Added / Changed / Fixed)이며, 관련 이슈·PR이 링크됩니다.
루프 흐름
수동 시작 → 마지막 태그 이후 diff → 체인지로그 항목 작성 → 형식 검증 →〔피드백 게이트〕
↑ 사용자 노출 변경을 다 다뤘나?
└────────────────────────────────────────────────────────┘ 아니오
│ 예
종료
매 반복(pass)마다 하는 일
- 마지막 태그 이후 diff — 마지막 릴리스 태그(또는 직전 CHANGELOG 섹션) 이후의 커밋과 사용자에게 보이는 변경을 나열합니다.
git log $(git describe --tags --abbrev=0 2>/dev/null || echo HEAD~20)..HEAD --oneline
- 체인지로그 항목 작성 —
[Unreleased] 아래에 Keep-a-Changelog 항목을 추가합니다: Added, Changed, Fixed. 내부 구현 용어가 아니라 사용자 관점 언어로만 씁니다.
- 형식 검증 — CHANGELOG가 프로젝트 형식을 따르는지, 관련 이슈·PR이 적절히 링크됐는지 확인합니다.
가드레일 (점수 조작 방지 규칙)
종료 조건을 "가짜로" 통과시키지 못하게 막는 규칙입니다. 반드시 지키세요.
- 체크 명령이나 종료 기준을 고쳐서 억지로 성공시키지 않는다.
- 체크를 건너뛰거나 비활성화·우회해서 종료 조건을 통과시키지 않는다.
- 여러 번 반복해도 막히면, 지표를 조작하지 말고 멈추고 블로커를 보고한다.
Claude Code에서 실행하기
가장 간단합니다. 출시·머지를 끝낸 뒤, 아래 kickoff 프롬프트를 그대로 붙여넣으면 에이전트가 스스로 반복합니다.
"출시 후 체인지로그 동기화(Changelog Sync After Ship)" 루프를 시작합니다.
목표: CHANGELOG.md에 이번 출시의 정확한 [Unreleased] 항목이 들어 있다
최대 반복: 3
매 반복 사이 실행: git log -5 --oneline
종료 조건: 체인지로그가 사용자에게 보이는 변경을 모두 다룰 때
1단계: 최근 커밋을 살펴보고, 사용자에게 보이는 변경을 Keep-a-Changelog 형식으로 적은 뒤,
빠진 게 없는지 확인한다.
이 루프를 스스로 페이싱(self-pace)하라. 매 반복 후 체크 명령을 실행하고 출력을 읽어, 종료
조건이 충족되지 않았을 때만 계속한다. 종료 조건이 통과하거나 최대 반복에 도달하면 멈춘다.
매 회차마다 한 줄 상태 업데이트를 남긴다.
팁: git log -5 --oneline은 빠른 점검용 예시입니다. 변경 범위가 넓다면 1단계의 git log $(git describe --tags --abbrev=0 ...)..HEAD --oneline처럼 마지막 태그 이후 전체를 보는 명령으로 바꾸세요.
팁 / 변형
- conventional commits 활용: 커밋이
feat: / fix: 컨벤션을 따른다면 git log ... --grep '^feat\|^fix'로 사용자 노출 변경만 추려 Added/Fixed에 매핑하기 쉽습니다.
- 태그가 아직 없을 때: 첫 릴리스라 태그가 없으면 1단계 명령이 자동으로
HEAD~20로 폴백합니다. 범위를 더 좁히거나 넓히려면 HEAD~20 숫자를 조정하세요.
- 형식 검증 자동화:
keep-a-changelog 린터나 npx changelog류 도구가 있으면 3단계 체크를 그 명령으로 바꿔 형식 누락을 기계적으로 잡을 수 있습니다.
- 막힐 때: 같은 변경을 어떻게 표현할지 두 번 반복해도 안 잡히면, 가드레일대로 멈추고 사람에게 "이 커밋은 사용자 노출인가?"를 물어 에스컬레이션하세요.
- 연관 루프: 코드 변경 후 README·API 문서 일반 동기화는
looping:docs-sync-after-edits, openapi.yaml 스펙 동기화는 looping:openapi-sync-until-valid, PR 올리기 전 자기 diff 리뷰는 looping:pr-self-review.
원본 영어 kickoff (loops.elorm.xyz 원문)
Start the "Changelog Sync After Ship" loop.
Goal: CHANGELOG.md has accurate [Unreleased] entries for this ship
Max iterations: 3
Between iterations run: git log -5 --oneline
Exit when: changelog covers all user-visible changes
Step 1: Review recent commits, write Keep-a-Changelog entries for user-visible changes, and verify completeness.
Self-pace this loop. After each iteration, run the check command, read the output, and only continue if the exit condition is not met. Stop when the exit condition passes or max iterations is reached. Give a short status update each pass.
출처: https://loops.elorm.xyz/loops/changelog-sync-after-ship
