MR / PR 제목 및 설명
MR/PR에 작성되는 모든 내용(제목, 설명)과 사용자에게 묻는 모든 질문은 프랑스어로 이루어집니다. GitLab에서는 « MR », GitHub에서는 « PR »이라고 표기합니다.
인자 (선택 사항)
받은 내용: $ARGUMENTS
| 인자 | 대상 |
|---|---|
https://github.com/<owner>/<repo>/pull/<n> | GitHub PR |
https://<host>/<group>/<repo>/-/merge_requests/<iid> | GitLab MR |
#<n> / <n> 단독 | 현재 저장소의 MR 또는 PR: git remote -v로 플랫폼 추론 |
| 없음 | 현재 브랜치의 MR 또는 PR: git remote -v로 플랫폼 추론 |
플랫폼을 추론할 수 없는 경우(자체 호스팅, 여러 개의 리모트) 사용자에게 직접 물어보세요.
엄격한 규칙
- 제목과 설명에 대한 명시적 확인 및 별도의 전송 승인 없이 MR/PR을 수정하지 마십시오.
- 사실(카드 번호, 컨텍스트, 테스트)을 지어내지 마십시오. 묻거나 생략하십시오.
- MR/PR 내용에 Claude에 대한 언급을 금지합니다.
단계
1. MR/PR 식별 및 가져오기
인자(위 표)에서 대상을 확인한 후, 명령을 실행하기 전에 해당 참조 문서를 읽으십시오.
references/sources/gitlab.mdreferences/sources/github.md
CLI(glab / gh)가 없거나 인증되지 않은 경우, 추측하지 말고 사용자에게 알리십시오(! glab auth login / ! gh auth login 제안).
현재 제목, 현재 설명, 소스/타겟 브랜치, 변경사항(diff 및 커밋 목록)을 참조 문서에 따라 검색하십시오. MR/PR의 실제 내용을 이해하기 위해 diff를 읽으십시오.
다음을 확인하십시오:
- 저장소 이름: 프로젝트 경로의 마지막 세그먼트, 대문자로 표기.
- 카드 번호: 기존 제목, 브랜치 이름, 커밋 및 설명에서 찾으십시오(예:
ABC-123,#123). 찾을 수 없으면 한 번 묻고, 사용자가 없다고 말하면 대괄호를 완전히 생략하십시오.
2. 제목
패턴(양 플랫폼 동일):
[<카드 번호>] <저장소 이름> - <주제> - 간단한 설명
- 대괄호와 카드 번호는 카드가 있을 경우에만 포함합니다.
<저장소 이름>: 저장소 이름을 대문자로 표기.<주제>: 항상 사용자에게 물어보십시오 (diff에서 추론한 제안을 기본 옵션으로 제시하되, 단독으로 결정하지 마십시오). 현재 제목에 이미 주제가 포함되어 있다면 유지할 것을 제안하십시오.- 간단한 설명: 간결하게, 프랑스어로, 소문자로 시작, 마침표로 끝나지 않음.
- 기존 제목이 이미 잘 구성되어 있고 MR/PR 내용에 여전히 적합하다면 그대로 유지하고 그 사실을 알리십시오. 더 이상 적합하지 않다면 수정된 제목을 제안하고 변경 전/후를 보여주십시오.
3. 설명
구조 (마크다운, 프랑스어):
# 설명
<MR/PR의 목표를 요약하는 한두 문장.>
## 컨텍스트
<수정 사항인 경우 코드의 현재 상태, 예상 결과: 제약 조건, 목표, 아키텍처, 전략.>
## 변경 사항
- <상위 수준 변경>
- ...
## 테스트
- <작성된 테스트 또는 수행된 수동 테스트>
섹션 지침:
- 설명: 목표에 대한 1-2문장. 초안을 제안하고 사용자에게 검증 또는 수정을 요청하십시오.
- 컨텍스트: (수정 사항의 경우) 변경 전 상태와 예상 결과(제약 조건, 목표, 아키텍처, 전략)를 설명합니다. 항목별로 진행하십시오: 각 항목을 사용자에게 검증을 위해 제출하고, 항목이 명확해질 수 있을 때마다 질문하십시오(왜 이 선택을 했는지, 어떤 제약 조건이 있는지, 어떤 대안이 거부되었는지). 검증되지 않은 가정으로 진행하지 마십시오.
- 변경 사항: 상위 수준 목록만 작성하십시오. 변경이 특정 세부 사항에 관한 경우 또는 MR/PR 전체를 이해하는 데 필수적인 경우에만 세부 내용을 다루십시오.
- 테스트: 작성된 자동화 테스트(포함된 파일/영역)와 수행된 수동 테스트의 개요입니다. 알 수 없는 경우 물어보고, 수행되지 않은 테스트를 주장하지 마십시오.
여러 번의 왕복 대신 AskUserQuestion을 사용하여 관련 질문(주제, 카드 번호, 컨텍스트 항목)을 배치하는 것을 선호하십시오.
4. 기존 설명 (업데이트 케이스)
MR/PR에 이미 설명이 있는 경우:
- 새 텍스트만 보여주지 말고, 섹션별로 변경될 내용(추가/수정/제거)을 보여주십시오.
- 사용자가 작성한 유용한 내용(링크, 스크린샷, 체크리스트, 템플릿 섹션,
Closes #12와 같은 종결 키워드)은 보존하고, 무언가 삭제될 경우 이를 명시하십시오. - 더 진행하기 전에 변경 사항에 대한 확인을 요청하십시오.
5. 확인 후 전송
- 최종 제목, 대상 MR/PR(URL, 브랜치) 및 전체 설명을 제시하고 세 가지 모두에 대한 확인을 요청하십시오.
- 그 후에만 별도의 질문으로 플랫폼에 수정 사항을 전송할 권한을 요청하십시오.
- 승인되면 설명을 스크래치패드/임시 파일에 작성하고 플랫폼 참조 문서의 명령을 사용하여 MR/PR을 업데이트하십시오. 이러한 명령은 의도적으로
allowed-tools에 포함되지 않아 사용자에게 권한 프롬프트가 표시됩니다. - 결과와 MR/PR URL을 보고하십시오. 실패하면 오류를 표시하고, 자동으로 재시도하지 마십시오.