/ship
현재 작업을 커밋하고, 푸시하며, 풀 리퀘스트를 엽니다. 이 스킬을 호출하는 것은 브랜치 생성/전환, 커밋, 푸시, 그리고 gh pr create 실행에 대한 명시적 권한을 부여하는 것입니다.
엄격한 규칙
- 사용자의 Git 안전 프로토콜을 따릅니다: 절대 git config를 변경하지 않음; 절대 훅을 건너뛰지 않음; 절대
main/master에 강제 푸시하지 않음; 사용자의 수정 규칙이 완전히 충족된 경우에만 수정(amend) 허용. - 비밀 정보(
.env, 자격 증명, 개인 키, 토큰)를 절대 커밋하지 않음. 발견되면 경고하고 제외. - 이 변경 사항에 속하는 파일만 스테이징합니다. 트리가 명백히 의도적이고 정크가 없는 경우가 아니라면 포괄적인
git add ./git add -A를 사용하지 않음. - 커밋 메시지와 PR 본문에 HEREDOC을 사용합니다.
- 이 워크플로를 프로젝트에 구애받지 않게 유지합니다. 저장소에서 verify 명령어와 레이아웃을 추론하고, 앱이나 패키지 이름을 하드코딩하지 않음.
- 완료되면 PR URL을 반환합니다.
Conventional Commit 접두사
프로덕션 수준의 Conventional Commits를 사용합니다. 하나의 기본 유형을 선택합니다:
| 접두사 | 사용 시기 |
|---|---|
feat | 새로운 사용자 대상 기능 |
fix | 버그 수정 |
refactor | 동작 변경을 의도하지 않은 내부 재구성 |
perf | 성능 개선 |
chore | 유지보수, 도구, 의존성, 하우스키핑 |
docs | 문서 전용 |
test | 테스트 전용 |
ci | CI 구성/파이프라인 |
build | 빌드 시스템 또는 번들러 변경 |
style | 로직 변경이 없는 포맷팅/린트 기반 변경 |
revert | 이전 커밋 되돌리기 |
형식:
type(optional-scope): 명령형 요약
선택적 본문: 이 변경이 존재하는 이유 (1–2문장).
예시: feat(auth): 리프레시 토큰 로테이션 추가, fix: 결제 시 이중 제출 방지, chore: lint 구성 업데이트.
워크플로
1. 검사 (병렬 실행)
git statusgit diff및git diff --stagedgit branch -vv(현재 브랜치 + 트래킹)git log -8 --oneline(메시지 스타일)- 기본 베이스 브랜치 (
main선호, 없으면master또는 저장소 기본값) - 원격 동기화 상태 (
git status -sb, 푸시되지 않은 커밋)
커밋할 내용이 없고 이 작업과 관련된 푸시되지 않은 커밋도 없으면 중단합니다. 빈 PR을 열지 마십시오.
2. 올바른 브랜치 확인
목표: 최신 베이스를 기반으로 한 전용 기능 브랜치에 작업을 배치합니다.
-
현재 브랜치가 이 변경 사항을 위한 브랜치인지 확인합니다:
- 이미 이 작업을 위한 설명적인 토픽 브랜치(
feat/…,fix/…,chore/…또는 변경 의도와 명확히 일치)이고 기본 브랜치가 아닌 경우 예. main/master/기본 브랜치, 일치하지 않는 토픽 브랜치, 오래된 관련 없는 브랜치 또는 분리된 HEAD인 경우 아니오.
- 이미 이 작업을 위한 설명적인 토픽 브랜치(
-
현재 브랜치가 이 변경을 위한 것이 아닌 경우:
- 작업 트리가 더티하면 명확한 메시지와 함께 스태시합니다 (기본값, 스태시가 불가능하지 않으면 묻지 않음).
git checkout <base>git pull --ff-only(또는 트래킹 원격에서 상응하는 fast-forward 업데이트)- 새 설명 브랜치를 생성하고 체크아웃합니다 (예:
feat/short-topic,fix/short-topic,chore/short-topic) git stash pop을 새 브랜치에 적용하고 충돌이 있으면 해결합니다.
-
현재 브랜치가 이 변경을 위한 것인 경우:
- 그대로 유지합니다.
- 커밋하기 전에 필요에 따라 베이스에서 업데이트합니다 (저장소 규범에 따라 최신 베이스에서 리베이스 또는 병합; 비파괴 옵션 선호; 사용자가 명시적으로 요청하지 않는 한 강제 푸시하지 않음).
절대 기본 브랜치에서 직접 PR을 생성하지 않습니다.
3. 커밋
- 사용자가 분할을 요청하지 않는 한 하나의 일관된 커밋을 선호합니다.
- 메시지는 적절한 conventional 접두사와 명령형 요약을 사용합니다.
- 본문 (선택 사항): 파일 목록이 아닌 이유에 초점을 맞춥니다.
- 커밋 후
git status를 실행하여 예상 상태를 확인합니다. - 훅이 실패하면 문제를 수정하고 새로운 커밋을 생성합니다. 수정 규칙이 완전히 충족되지 않는 한 수정(amend)하지 않습니다.
4. 푸시
git push -u origin HEAD
샌드박스/네트워크/gh가 작업을 차단할 때 필요한 권한을 요청합니다.
5. PR 열기
베이스에 병합될 모든 커밋을 분석합니다 (최신 커밋뿐만 아니라).
제목: 커밋 요약과 동일한 정신 — 명확하고, 구체적이며, 도움이 될 때 conventional합니다. 모호한 제목은 사용하지 않습니다.
본문 템플릿 (필수):
## 요약
- 무엇이 배송되고 왜 중요한지에 대한 2–5개의 글머리 기호
## 이유
- 이 변경의 문제, 동기 또는 트리거
## 변경 사항
- 관심사별로 그룹화된 글머리 기호 (동작, API/계약, 데이터, UI, 인프라, 테스트, 문서)
- 브레이킹 체인지, 마이그레이션 또는 인증/세션 동작 변경을 명시적으로 언급
## 아키텍처 / 흐름
다음 중 하나 이상을 포함합니다:
1. 기본 경로에 대한 Mermaid 다이어그램 (시퀀스, 순서도 또는 상태)
2. 구조, 계층 또는 이전 → 이후에 대한 ASCII 다이어그램
제어 흐름에는 Mermaid를 사용하고, 트리 또는 레이어 맵에는 ASCII를 사용합니다.
다이어그램은 실제 diff와 일치해야 합니다. 아키텍처를 지어내지 마십시오.
## 리스크 / 롤백
- 가능한 실패 모드
- 안전한 되돌리기 / 완화 참고 사항
## 테스트 계획
- [ ] 리뷰어가 실행할 수 있는 구체적인 단계
- [ ] 프로젝트에서 발견한 저장소에 적합한 확인 명령어
gh pr create와 HEREDOC 본문으로 생성합니다. 필요할 때 --base를 명시적으로 설정합니다.
6. 결과 보고
짧게 유지합니다:
- 브랜치 이름
- 커밋 요약
- PR 제목
- PR URL
- 의도적으로 커밋되지 않은 파일