devseunggwan/merge-briefing

merge-briefing은(는) 무엇을 하나요?

개요

병합은 되돌릴 수 없는 공유 상태이므로, 사용자의 명시적인 PR별 답변에 의해 승인됩니다. 이 게이트는 형식적으로는 충족하기 쉽고, 거짓으로 충족하기도 쉽습니다. 정직한 버전은 "열린 것이 없다"는 것을 뒷받침할 만큼 충분히 넓은 조사가 필요하며, 차단 발견 사항이 실제로 존재하는 표면(인라인 리뷰 스레드)은 gh pr view --json comments,reviews 호출이 묵묵히 생략하는 곳입니다.

이 스킬은 해당 절차를 위한 온디맨드 홈입니다. Pre-Merge Reporting 규칙(ETHOS.md → Rules praxis carries)이 게이트를 유지하며, 아래 4단계의 6개 파트 목록이 보고서의 형태입니다. 아래 단계는 "PR이 완료된 것처럼 보인다"에서 사용자가 한 단어로 답변할 수 있는 질문으로 가는 방법입니다.

핵심 원칙: 브리핑은 PR 상태에 대한 주장이므로, 모든 줄은 작성 시점에 조사됩니다. PR이 열렸을 때의 상태를 기억하는 것이 아닙니다.

사용 시기

• 사용자에게 병합 승인을 요청하려고 할 때
• 병합이 요청되었지만 아직 이번 턴에 브리핑을 제시하지 않은 경우
• 이전 요청이 응답되지 않았거나 CI/리뷰가 변경된 후 다시 요청하는 경우
• 동반, 후속 또는 재생성된 PR이 사용자가 이미 승인한 클러스터에서 다음 차례인 경우

철칙

• 하나의 PR, 하나의 브리핑, 하나의 답변. PR X 승인은 X만 승인합니다. 유일한 예외는 일괄 병합입니다: PR별로 별도의 브리핑 섹션이 있는 하나의 턴, 그것들을 나열하는 하나의 질문, 그리고 나열된 세트를 승인하는 답변입니다.
• 이번 턴의 조사 출력에서 브리핑을 작성하세요. 진입 시점의 CLEAN 상태는 영구적이지 않습니다. 오래된 앵커는 사용자가 당신이 잡았어야 할 충돌을 발견하게 만듭니다.
• 진행 신호에 병합하지 마세요. "계속", "ok", "진행"은 작업을 진행시키는 신호입니다. 공유 상태 변경에 대한 동의가 아닙니다.

프로세스

1단계: 세 가지 표면 모두 조사

발견 사항은 세 가지 표면에 존재하며, 단일 명령어로 모두를 다루지 않습니다. 브리핑 내용을 한 줄도 작성하기 전에 세 가지를 모두 실행하세요.

# 1 — CI
git pr checks <N> --repo <owner>/<repo>

# 2 — 대화 타임라인 + 리뷰 본문 + 병합 가능성 + 푸시된 HEAD
git pr view <N> --repo <owner>/<repo> \
  --json mergeable,mergeStateStatus,isDraft,headRefOid,reviews,comments

# 3 — 인라인 리뷰 스레드 (표면 #2에 포함되지 않음)
git api graphql --paginate -f query='
query($owner:String!, $repo:String!, $pr:Int!, $endCursor:String) {
  repository(owner:$owner, name:$repo) {
    pullRequest(number:$pr) {
      reviewThreads(first:100, after:$endCursor) {
        pageInfo { hasNextPage endCursor }
        nodes {
          id isResolved isOutdated path line
          comments(first:1) { nodes { author { login } body } }
        }
      }
    }
  }
}' -F owner=<owner> -F repo=<repo> -F pr=<N> \
  --jq '.data.repository.pullRequest.reviewThreads.nodes[]
        | select(.isResolved | not)
        | {id, path, line, author: .comments.nodes[0].author.login,
           body: .comments.nodes[0].body}'

body가 프로젝션에 포함된 이유는 레이블이 스레드 자체의 텍스트에 있고, 2단계에서 평가하는 대상이 바로 그 레이블이기 때문입니다. $endCursor와 함께 --paginate는 장식이 아닙니다. 두 봇이 작업한 PR은 100개가 넘는 스레드를 통과하며, 단일 페이지는 나머지를 묵묵히 버리므로 결과적으로 "열린 스레드 없음"으로 읽힙니다.

표면 #2도 100개에서 자르며, 마찬가지로 묵묵히 자릅니다. gh pr view --json comments,reviews는 comments(first: 100) / reviews(first: 100)을 커서 변수 없이 발행하므로, PR이 어느 한쪽 카운트를 넘으면 나머지는 단순히 존재하지 않습니다. 둘 중 하나가 100행인 경우, 평가 전에 페이지네이션된 REST 엔드포인트를 통해 해당 표면을 다시 수집하세요:

git api repos/<owner>/<repo>/pulls/<N>/reviews --paginate -q '.[] | {user: .user.login, state, body}'
git api repos/<owner>/<repo>/issues/<N>/comments --paginate -q '.[] | {user: .user.login, body}'

빈 결과는 아직 답변이 아닙니다. 이것은 "열린 스레드 없음"과 "쿼리가 잘못됨"을 동시에 의미하며, 이 정확한 쿼리가 스레드가 있는 것으로 알려진 PR에서 행을 출력하는 것을 확인하기 전까지는 그렇습니다. 그러한 PR에 대해 한 번 실행하십시오. 이것이 부정적 주장의 기반이 되는 양성 대조군입니다.

포크 클론에서는 모든 조사에서 --repo가 포크를 지정해야 합니다. 일반 gh pr 호출은 상위 리포지토리를 기준으로 확인합니다(worktree-merge-cleanup → 사전 호출 체크리스트 참조).

CI가 보류 중이거나 실패 중이면 여기서 중지하세요 — 아직 묻지 마십시오. 확인 행이 아직 움직이고 있는 브리핑은 사용자에게 추측을 승인하도록 요청하는 것입니다.

각 인간 승인이 어떤 커밋을 다루는지 읽으세요 "승인됨"이라고 쓰기 전에: reviewDecision: APPROVED는 이후 푸시에서도 유지됩니다. 리뷰어별로 리뷰를 그룹화하고 각각의 최신 APPROVED 리뷰를 가져옵니다(이전 승인은 재승인에 의해 대체됩니다. 동일 리뷰어의 이후 CHANGES_REQUESTED 또는 DISMISSED는 현재 승인이 없음을 의미합니다). 해당 리뷰의 commit_id를 headRefOid와 비교하고, 이후의 비병합 커밋(git log --no-merges <commit_id>..<head>)을 5부에 "<인간>이 리뷰하지 않음"으로 나열합니다(해당 명령어는 실패 모드 행 참조).

병합 상태는 허용 목록이지, "명백히 손상되지 않음" 확인이 아닙니다. mergeable이 MERGEABLE 이고 mergeStateStatus가 CLEAN 또는 HAS_HOOKS일 때만 요청하세요. 이 두 값만이 커밋 상태 통과와 함께 병합 가능함을 의미합니다. 다른 모든 값은 요청을 중단하고 브리핑에서 그 이름을 밝힙니다:

mergeStateStatus	의미	요청?
CLEAN	병합 가능하며 커밋 상태 통과	예
HAS_HOOKS	병합 가능, 통과, 사전 수신 훅 있음	예
UNSTABLE	통과하지 않는 커밋 상태로 병합 가능	아니오 — 위의 CI 실패입니다
BLOCKED	병합이 차단됨 (보호 규칙, 필수 리뷰)	아니오
BEHIND	헤드 ref가 최신이 아님	아니오 — 먼저 리베이스하세요
DIRTY	병합 커밋을 깨끗하게 생성할 수 없음	아니오 — 충돌
UNKNOWN	현재 상태를 확인할 수 없음	아니오 — 재폴링

초안 상태는 이 열거형에 없습니다. 이는 별도의 isDraft 필드이므로 초안 PR은 CLEAN을 보고할 수 있습니다. isDraft를 --json 목록에 추가하고, 병합 상태와 관계없이 초안을 준비되지 않은 것으로 처리하세요.

CLEAN은 브랜치가 생성된 이후에 추가된 베이스 커밋에 대해 아무 말도 하지 않습니다. 그것들을 세고(git fetch origin 후 git rev-list --count HEAD..origin/<base>) PR도 건드리는 파일을 나열하세요(git diff --name-only HEAD...origin/<base>). 각 공유 파일에 대해 해당 베이스 diff에서 이 PR이 변경하는 심볼을 grep하고 git merge-tree --write-tree HEAD origin/<base>를 실행하세요 — 심볼 히트가 0이고 종료 코드 0은 "의미론적 중복 없음"에 대한 증거이며, 5부에 인용됩니다. 병합 전 리베이스 트리거가 발생하면(베이스 커밋 3개 이상, 리뷰 라운드 완료), gh pr update-branch <N>으로 베이스를 가져오세요(병합 커밋, 재작성 절대 안 함). 그러면 CI와 봇 리뷰가 다시 시작됩니다. 새로운 헤드에서 둘 다 기다리고, 이동한 헤드로 앵커를 다시 수정한 다음, 새로운 헤드에 대해 1~3단계를 다시 실행하고 요청하기 전에 브리핑을 재구축하세요. 이전에 수집된 발견 사항, 병합 상태 및 승인 범위는 이전 헤드를 설명합니다.

2단계: 세 가지 표면의 모든 발견 사항 등급 매기기

열린 스레드 수는 차단 항목 수가 아니며, 스레드 표면이 전체 말뭉치가 아닙니다. 1단계에서 수집된 각 발견 사항(인라인 스레드, 대화 댓글, 리뷰 본문 모두)을 레이블이 아닌 장식에 따라 등급을 매기세요:

발견 사항의 첫 줄	병합을 차단합니까?
issue (blocking): / suggestion (blocking):	예 — 병합이 기다립니다
issue (non-blocking): / suggestion (non-blocking):	아니오
nitpick: / note:	아니오 — 설계상 미해결
레이블 없음	직접 등급 매기세요 — 본문을 읽으세요

suggestion은 issue보다 낮은 등급이 아닙니다. 둘 다 정확히 (blocking) / (non-blocking) 중 하나를 가지므로, 장식이 전체 판단이고 레이블은 어떤 종류의 발견 사항인지만 말합니다. 레이블을 읽는 것이 선언된 차단 항목이 "그냥 제안"으로 통과되는 방법입니다.

리뷰 본문은 스레드가 아니며 해결될 수 없습니다. 이것이 바로 읽히지 않는 이유입니다. 열려 있는 것처럼 보이는 것이 없습니다. CodeRabbit은 실행 가능한 발견 사항을 줄 댓글이 아닌 접을 수 있는 리뷰 본문 섹션에 제출하므로, 1단계에서 수집된 본문에서 Actionable, Nitpick, outside diff, 🧹를 grep하고 찾은 것을 등급 매기세요. 결함을 제기하는 대화 댓글도 같은 방식으로 등급이 매겨집니다. 두 표면에서 차단 발견 사항은 인라인 발견 사항과 마찬가지로 요청을 중단합니다. 단순히 닫을 스레드가 없으므로 브리핑의 열린 항목에 포함됩니다.

등급 매기기가 완료되기 전에 CodeRabbit 카운트를 조정하세요: 본문의 `LINES`: ** 마커로 발견 사항을 세고 리뷰 헤더에 명시된 총계(예: Major comments: N)와 일치시킵니다. 세트를 하나의 대화 댓글에 Fixed — <sha> (n) / Not fixed (n) / False positive (n)으로 그룹화하여 답변하세요. 해당 카운트는 총계와 합산되어야 합니다.

레이블이 없는 경우는 예외가 아니라 일반적인 경우입니다. 봇은 자신의 어휘로 작성합니다. CodeRabbit은 자체 심각도 줄(_🎯 Functional Correctness_ | _🟠 Major_ | …)로 시작하고, Copilot과 BugBot은 아무것도 없이 시작합니다. 봇의 심각도를 등급에 대한 입력으로 취급하고, 결코 등급 자체로 취급하지 마세요. 또한 "그냥 봇일 뿐"이라는 이유로 발견 사항을 건너뛰는 이유가 되지 않습니다.

차단으로 등급이 매겨진 스레드는 병합 전에 하나의 합법적인 종료 방법이 있습니다: 수정되고 닫히거나, 재등급 — 댓글을 (non-blocking)으로 편집하고 Revised — 공지를 게시합니다. 재등급 없이 차단 발견 사항을 후속 조치에 보관하면 모든 레이블이 비차단으로 읽히는 동안 브랜치가 잠긴 상태로 남습니다.

리뷰 수준의 REQUEST_CHANGES를 지우는 것은 별도의, 이후 단계입니다. 그 상태는 리뷰에 속하며, 여러 발견 사항을 포함할 수 있으므로 그 안의 모든 차단 발견 사항이 수정-및-닫히거나 재등급될 때만 지워집니다. 절대 하나의 발견 사항만으로 지워지지 않습니다. 마지막 차단 발견 사항을 재등급하는 것이 그것을 잠금 해제하는 것입니다. 그때까지 리뷰는 여전히 올바르게 차단합니다.

3단계: 앵커의 Unverified 격차 이월

PR의 검증 앵커를 열고 Unverified 목록을 읽으세요. "머지 후 실전송으로 확인"으로 작성된 격차는 PR과 함께 사라집니다. 무언가가 그것보다 오래 지속되지 않는 한.

• 다음 조치를 명명한 격차만 표면화하세요. 명시된 다음 조치가 없는 격차는 이월되지 않습니다.
• 브리핑의 일부로 후속 이슈를 열지 여부를 물으세요.
• 앵커의 최종 개정판에 Carried: #N 또는 Carried: none — <사유>로 답변을 작성하세요. 병합 전에.
• 해당 최종 개정판을 작성하려면 gh가 필요합니다. 유일한 GitHub 표면이 MCP 서버인 세션은 해당 서버의 활성 도구 목록에 댓글 update가 노출되지 않으면 댓글 본문을 업데이트할 수 없습니다(가정하기 전에 확인). 그곳에서는 Carried: 줄을 병합 커밋이나 PR 본문에 대신 넣고, 절대 두 번째 앵커 댓글에 넣지 마세요. anchor-comment-gate/spec.md → Procedure for a gh-less session 참조.
• 후속 조치를 자동으로 제출하지 마세요. 새 이슈는 여전히 자체 구현 접근 방식 검토가 먼저 필요합니다.
• 후속 조치가 댓글로 기록되는 경우(Carried: <comment URL>), 병합 후에도 열려 있는 이슈에 넣으세요. PR의 Ref: 이슈(예: 릴리스 단계에서 나중에 닫히는 허브/우산 이슈)에 넣고, 절대 Closes #N 이슈에 넣지 마세요. 후자는 병합 자체로 닫히며 아무도 다시 열지 않습니다. PR이 열려 있는 동안 작성된 범위 외 메모도 마찬가지입니다.
• 이월 이슈가 병합 후 릴리스 단계에서 닫히는 이슈(/release로 닫히는 허브 이슈)인 경우, 릴리스는 Closes 대상과 똑같이 이월을 묻습니다. 병합 보고서에서 그 충돌을 명명하세요(지금 릴리스하고 열린 항목을 잃거나, 확인된 후 릴리스) 어느 쪽이든 조용히 해결하지 마십시오. 또한 병합 후 Closes #N 대상을 확인하세요. GitHub는 PR이 리포지토리의 기본 브랜치로 병합될 때만 해당 이슈를 닫습니다. 따라서 기본이 dev일 때 prod와 같은 기본이 아닌 베이스로의 PR은 릴리스 단계를 위해 열려 있습니다.

4단계: 6개 파트 브리핑 작성

6개 파트, 이 순서대로(이 목록이 표준 형태입니다. 원래 작성자의 dotfiles PR-workflow 템플릿에서 파생되었습니다):

1. 변경된 사항 — PR이 무엇을 하는지, 병합되면 사용자에게 무엇이 바뀌는지(그리고 병합되지 않으면 무엇인지) 한 문장으로 시작한 다음, 범위(파일, 논리적 변경 사항)를 설명합니다. 이슈 제목을 다시 말하지 마세요. 카운트와 내부 약어로 만들어진 1부는 답변 대신 "무엇을 하나요?"라는 질문을 받게 되어 승인 창이 재설정되고 완전한 재브리핑이 필요합니다.
2. 검증된 사항 — 실제 출력, 명령어 인용 포함
3. 검증되지 않은 사항 — 건너뛴 것, 연기된 것, 차단된 것, CI 보류 중인 것
4. 위험 / 파급 범위 — 이것이 잘못되면 누가 망가지는가
5. 열린 항목 — 2단계에서 등급이 매겨지고 열려 있는 모든 발견 사항, 세 가지 표면 모두; 3단계의 격차
6. 명시적 질문 — 자체 줄에 Approve merge?를 텍스트로 작성하고, 바로 뒤에 5단계의 AskUserQuestion 호출을 넣습니다(도구가 묻더라도 줄은 남아 있습니다. 게이트가 평가하는 항목이기 때문입니다).

3부는 압박을 받는 부분이며, 브리핑이 존재하는 이유입니다.

검증되지 않은 항목이 병합이 촉발하는 바로 그 단계인 경우(병합 후 배포, CI가 실행하지 않은 에셋 빌드, 한 플랫폼에서 실행한 멀티 플랫폼 빌드) 그것은 각주가 아니라 위험입니다: 해당 단계가 실패하면 무엇이 망가지고, 같은 스택의 이후 배포 등 다른 누구를 차단하는지와 함께 4부에 넣으세요. 버전 핀, 카탈로그, 문서와 같은 기록 관리가 가치인 PR의 경우, 4부는 또한 병합되지 않으면 어떤 일이 일어나는지 한 줄로 말합니다. 사용자는 여전히 배포를 촉발하는 낮은 위험의 PR을 승인하기 전에 그것을 묻습니다.

3부 안티패턴: 증거 없이 "완료했습니다, 머지할까요?"; 생략된 검사가 후행 여담으로 강등됨; PR 준비 시간에 표면화되었어야 할 것을 병합 시간에 보고함.

관찰을 통해 3부 항목을 닫고, 읽지 마세요. 사용자가 검증되지 않은 항목을 확인해 달라고 요청하면, 항목별로 가장 저렴한 조사(구문 오류, 타입 오류에 대한 컴파일러, 네트워크에 대해 살아 있는 엔드포인트, 의존성 변경에 대해 기존 사용자와 동등한 테스트 실행)를 실행하여 그것을 해결하세요. 답변이 "모든 것 확인"이면 해당 항목을 3부에서 제거하세요. 그렇지 않으면 결과를 보고하고 다시 요청하세요.

5단계: AskUserQuestion 호출

1~4단계가 브리핑을 준비합니다. 이 단계는 브리핑을 제시하고 답변을 수집합니다.

<ask_question>
<question>
[위의 4단계 브리핑 전문, 줄바꿈 유지]

---
Approve merge?
</question>
</ask_question>

4부에서 나열된 정확한 PR 번호로 텍스트를 시작하세요(예: #142). 질문 단락 위의 모든 내용이 브리핑의 텍스트입니다.

AskUserQuestion 이전에 결론을 내리지 마세요. "모든 것이 깨끗해 보입니다"는 브리핑의 내용을 근거로 한 주장이며, 사용자가 확인할 수 없는 주장입니다. 브리핑을 말하게 하고, 침묵을 지키세요. 사용자가 예라고 말하면 6단계로 이동합니다.

6단계: 병합 커밋 작성

지금까지의 모든 작업은 이 커밋을 올바르게 만드는 데 있었습니다.

# 요약 줄: <PR 제목> (#N)
#
# 브리핑:
# …
#
# 이월:
# Carried: #M (또는 none — <사유>)

병합 커밋 본문은 세 섹션으로 구성됩니다:

1. 빈 줄 — GitHub은 요약 줄과 본문 사이에 하나를 기대합니다
2. 브리핑: — 불릿 없는 브리핑 텍스트 사본(4단계, 개.별. 줄, 원래 줄바꿈 유지). 각 줄 앞에 # 를 붙이면 브리핑이 커밋 본문에 주석 처리되며, GitHub UI는 첫 번째 빈 줄에서 렌더링된 설명을 중단합니다. 앞에 # 가 없는 브리핑은 그대로 표시되어 커밋 자체를 더 길게 만듭니다(병합 후 git log에서).
3. 이월: — 3단계의 주석 처리되지 않은 Carried: 줄(들).

스쿼시 병합이 활성화된 리포지토리에서는 sqash를 사용하세요. 그렇지 않으면 merge --no-ff를 사용하세요. 이 설정은 일반 저장소별 규칙(ETHOS.md → GitHub)에서 나옵니다. 로컬 git merge를 사용하는 경우, FETCH_HEAD가 아닌 PR의 헤드 SHA에서 병합하세요. 원격 추적 ref는 gh가 업데이트한 것을 반영하지 않을 수 있습니다.

일괄 병합: 여러 PR, 하나의 답변

사용자가 여러 PR의 묶음을 승인하도록 요청했습니다. 동일한 턴에 각 PR에 대해 별도의 브리핑 섹션을 제공하고(1~4단계), 하나의 질문(5단계)에 그들을 나열하고, 사용자가 하나의 예라고 답하면 각각에 대해 6단계를 실행합니다.

병합 순서는 아마도 베이스 브랜치별로 그룹화하고 종속성을 확인하여 결정하세요. 각 병합 전에 다른 PR이 브리핑 이후에 병합되었는지 다시 확인할 필요가 없습니다. 동일한 턴이므로 브리핑 시간 이후의 변경 사항은 없습니다.

번들은 일괄 병합 사용자가 명시적으로 말한 경우에만 허용됩니다: "이 PR들을 함께 승인" 또는 사용자가 이전 턴에서 "각각 승인"이라고 말했기 때문에 별도로 병합하는 "뭉치"가 아닙니다.

실패 모드

가장 비용이 많이 드는 실패는 병합 커밋이 실패하는 것이 아니라, 승인되지 않은 병합을 얻는 것입니다. 다음 검사는 그것을 방지합니다.

모드	방어	복구
mergeStateStatus가 CLEAN이 아니거나 mergeable이 MERGEABLE이 아님	1단계가 요청을 중단하고 브리핑에 상태를 보고함	실행: 1단계 검사가 자체적으로 문제를 해결했는지 확인하기 위해 재실행
isDraft	1단계가 요청을 중단하고 상태를 보고함	없음 — 초안은 요청할 준비가 되지 않음
CI 실패	1단계가 요청을 중단함	스스로 해결되지 않는 한 없음
CI 보류 중	1단계가 요청을 중단함	CI 완료 대기; 1~3단계 재실행
차단 레이블이 있는 열린 스레드	2단계가 차단 발견 사항으로 등급 매김; 5부가 그것들을 나열함	스레드를 수정-및-닫거나 재등급
CHANGES_REQUESTED 검토	4단계(호출되지 않음)가 2단계를 통해 열린 차단 항목에 의해 차단됨	마지막 차단 발견 사항을 닫거나 재등급하여 잠금 해제
리뷰 커밋이 headRefOid와 일치하지 않음	1단계가 "<인간>이 리뷰하지 않음"을 감지하고 5부에 나열함	사용자가 확인하도록 함; 리뷰어가 재승인할 수 있음
앵커의 Unverified 격차가 "머지 후 실전송으로 확인"	3단계가 이월하지 않음; 브리핑에서 언급되지 않음	손실; PR이 병합되면 격차가 사라짐. 이것이 스킬이 이월을 먼저 명시적으로 묻는 이유입니다
봇 발견 사항이 텍스트 누락으로 놓침	2단계가 body를 명시적으로 grep함	발견 사항이 브리핑에 없으면, PR은 미해결 차단 항목을 숨겨 병합될 수 있음. 복구 없음, 다음 PR에서 명시적 grep이 필요함
페이지만 조사하고 오프스크린 스레드는 조사하지 않음	1단계가 --paginate를 사용하여 모든 스레드 페이지를 반복함	발견되지 않은 차단 발견 사항이 있는 열린 스레드는 질문을 무효화함. 복구 없음, 재실행만 가능
사용자가 질문에 응답하지 않음	질문 도구가 타임아웃됨. 사용자는 브리핑 없이 병합을 요청합니다. "

• 표면 #2에서 100+ 댓글/리뷰는 REST 페이지네이션으로 재수집해야 함
• suggestion (blocking)은 suggestion을 넘어 읽어야 함
• CLEAN은 베이스 브랜치 의미론적 중복을 확인하지 않음

모드	방어	복구
사용자가 질문 도구 외부에서 "예"라고 말함 (예: "진행")"	도구가 응답을 등록하지 않음. "계속" 및 "예"에 대한 일반 텍스트 검사 필요	없음 — 사용자가 명시적으로 동의할 때까지 기다림. "진행"을 동의로 착각하지 마세요.
봇 발견 사항에 (blocking)/(non-blocking) 레이블이 없음	2단계가 텍스트를 기반으로 등급을 매김. "🎯 Functional Correctness"는 등급 입력	사용자에서 봇으로의 전환 시 발견 사항이 간과될 수 있음. 복구 없음, 각 PR에서 명시적 등급이 필요
사용자가 "이것이 맞는지 확인"이라고 말함	사용자가 꼼꼼히 확인하지 않음. 잘못된 긍정/부정의 위험	수동 확인이 없으면 복구 불가능. 프로세스가 실패를 방지하지 않음
mergeStateStatus가 UNKNOWN이고 재폴링되지 않음	1단계가 요청을 중단함	재폴링하여 해결되면 재시도
사용자가 이전에 승인한 PR과 병합 순서가 잘못됨	일괄 병합은 동일한 턴에서만 유효함	각 PR을 개별적으로 병합하여 순서 문제 방지
복잡한 종속성 (PR A가 B를 필요로 함)	수동 순서 지정 (사용자 확인)	자동화 실패 시 수동으로 병합
베이스 브랜치가 PR 이후에 업데이트됨	1단계가 git merge-tree를 실행하지만, gh pr update-branch가 필요할 수 있음. 브리핑은 강제로 다시 작성됨	사용자 확인으로 재실행
리뷰어가 APPROVED를 여러 번 제출함	1단계가 최신 승인을 기준으로 그룹화하고 필터링함	복구 없음, 올바르게 필터링됨
리뷰어가 CHANGES_REQUESTED를 제출한 후 APPROVED를 제출함	1단계가 최신 승인을 기준으로 그룹화하고 필터링함	복구 없음, 올바르게 처리됨
앵커의 Unverified 격차가 잘못된 유형	3단계가 다음 조치를 명명하는 격차만 이월함	놓친 격차에 대해 수동 이슈 생성 필요
사용자가 브리핑을 읽지 않음	위험 있음. 브리핑이 명확하지 않거나 길면 사용자가 건너뛸 수 있음	브리핑을 간결하게 유지하고 핵심 정보에 집중하세요. "Approve merge?"는 명확해야 함
MCP 서버에 댓글 업데이트 도구가 없음	3단계가 gh 없는 세션 절차로 전환	댓글 업데이트 없음. Carried: 줄을 병합 커밋에 넣음
브리핑이 "완료했습니다, 머지할까요?"로 요약됨	스킬이 체계적인 6부 브리핑을 강제함	사용자가 질문에 답변하기 전에 오해할 수 있음. 재브리핑 필요
사용자가 동의했지만 승인이 취소됨 (예: 새로운 푸시)	브리핑이 오래됨. 1단계가 새로운 mergeStateStatus를 확인함	재브리핑 필요. 사용자가 재동의해야 함
사용자가 동의했지만 다른 PR이 승인됨	일괄 병합만 여러 PR을 처리함. 철칙이 이를 금지함	개별 승인만 유효함. 재요청 필요
사용자가 동의했지만 병합이 실패함 (네트워크 오류)	6단계가 실패를 감지하고 재시도해야 함	수동 재시도 필요. 자동화된 재시도는 위험할 수 있음 (중복 병합)
사용자가 동의했지만 병합이 거부됨 (보호 규칙)	1단계가 병합 전에 거부를 감지하지 못함. mergeStateStatus가 BLOCKED일 수 있지만, 놓칠 수 있음	병합 거부를 처리하고 재브리핑 필요
사용자가 동의했지만 CI가 다시 실행됨	1단계가 CI 상태를 다시 확인하지 않음. 스킬은 브리핑 시간에 고정됨	재브리핑 필요. 사용자가 재동의해야 함
사용자가 동의했지만 리뷰가 업데이트됨	1단계가 리뷰 상태를 다시 확인하지 않음. 스킬은 브리핑 시간에 고정됨	재브리핑 필요. 사용자가 재동의해야 함
사용자가 동의했지만 앵커가 업데이트됨	3단계가 앵커 상태를 다시 확인하지 않음. 스킬은 브리핑 시간에 고정됨	재브리핑 필요. 사용자가 재동의해야 함
사용자가 "Approve merge?"에 대해 "예"가 아닌 다른 답변을 함	5단계가 답변을 구문 분석하고 "예"가 아니면 병합을 거부함	사용자가 거부 사유를 설명할 때까지 기다렸다가 재시도하거나 PR을 종료
사용자가 "Approve merge?"에 대해 "예"라고 답변했지만, 이후 동의를 철회함	스킬이 이미 병합을 진행 중일 수 있음. 철회가 병합 전에 도착하면 중단하고 재브리핑	병합이 이미 발생한 경우 되돌림이 필요할 수 있음. 스킬이 철회를 수용하도록 설계되어야 함
사용자가 "Approve merge?"에 대해 "예"라고 답변했지만, 다른 PR도 병합되었음	스킬이 이미 병합을 진행 중일 수 있음. 다른 PR의 병합이 충돌을 일으킬 수 있음	충돌이 발생하면 수동으로 해결해야 함. 스킬이 병합 전에 충돌을 확인해야 함
MCP 서버가 없음 (터미널 전용)	스킬이 gh CLI를 사용함. AskUserQuestion 도구가 없으면 5단계가 printf로 전환	사용자가 수동으로 질문에 답변해야 함 스킬이 병합을 진행할 수 없음
CI 실패가 일시적임 (재시도로 해결됨)	1단계가 CI 실패 시 요청을 중단함. 사용자가 재시도를 요청할 수 있음	스킬이 CI 재시도를 지원해야 함. 재시도 후 1~3단계 재실행
잘못된 리포지토리 (포크)	1단계가 --repo를 포크로 설정하도록 요구함. 설정되지 않으면 상위 리포지토리를 조사함	잘못된 리포지토리에서 브리핑이 생성될 수 있음. 복구 없음, 수동 확인 필요
잘못된 PR 번호	1단계가 gh 오류를 발생시킴. 브리핑이 생성되지 않음	올바른 PR 번호로 재시도
네트워크 오류	1~3단계 실패. 브리핑이 생성되지 않음	재시도
GitHub API 속도 제한	1~3단계 실패. 브리핑이 생성되지 않음	재시도, 나중에 재시도, 또는 인증 확인

참고

• 이 스킬은 gh CLI에 의존합니다. gh가 설치 및 인증되었는지 확인하세요.
• GraphQL API는 인라인 리뷰 스레드를 가져오는 데 직접 필요합니다. gh는 리뷰에 대한 기본 comments 필드를 노출하지만, 스레드 자체는 노출하지 않습니다.
• REST API는 gh pr view가 100개로 자르는 댓글 및 리뷰의 전체 목록을 가져오기 위한 폴백입니다.
• 브리핑이 이 턴에 작성되었는지 확인하세요. 이전 턴의 오래된 브리핑을 재사용하지 마세요.
• "Anchor"는 PR의 검증 상태를 문서화하는 댓글 또는 PR 본문의 섹션을 말합니다. 일반적으로 보류 중인 작업 항목이 포함됩니다.
• ETHOS.md에 대한 참조는 더 큰 컨텍스트의 규칙 세트를 가리키며, 이 스킬은 구현 세부 사항입니다.