القائمة
Git 워크플로우 자동화(원자적 커밋 분리, 히스토리 정리, 변경 추적). 커밋 분리, rebase 계획/실행, 변경 이력 추적을 요청할 때 사용한다.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
GitHub PR URL을 인자로 받아 merge conflict(병합 충돌) 유무를 판정하고, 충돌이 없으면 즉시 종료한다. 충돌이 있으면 충돌 파일/원인 커밋을 추적해 어떤 PR/브랜치에서 유입된 변경인지 식별한 뒤, 양쪽 PR/이슈의 plans(또는 docs/plan) 문서를 찾아 의도한 구현을 모두 보존하는 형태로 충돌을 해결하고 commit+push 해서 PR이 다시 mergeable 해질 때까지 확인한다. PR 병합 충돌 해결을 요청받으면 사용한다.
GitHub PR URL을 인자로 받아 현재 브랜치가 PR의 head branch와 일치하는지 검증한 뒤, GitHub Actions CI 실패 원인을 분석/수정하고 commit+push 후 CI 성공을 폴링으로 확인하는 복구 루프를 수행한다. CodeRabbit/Copilot 같은 코드리뷰 체크는 제외하고 GitHub Actions run만 대상으로 한다. PR CI 실패 복구를 요청받으면 사용한다.
변경사항 커밋/푸시 워크플로우 자동화. 이슈 생성, 브랜치 생성, 원자적 커밋, 검증, push, PR 생성 후 CI 폴링/실패 복구까지 한 번에 진행해 달라는 명시적 요청에서 사용한다.
버그 상황과 로그를 받아 재현을 최우선으로 수행하고, git 변경/프로젝트 문서 기반 원인 가설을 반복 검증해 해결한다. 방향 변경이 필요하면 사용자 승인 후 진행한다.
구현 계획 문서를 6가지 관점으로 순차 리뷰하고, 수동 텍스트 승인 루프로 의견/승인을 받아 즉시 반영한 뒤 반복 루프를 수행한다.
GitHub 이슈 URL을 인자로 받아 이슈 정보를 확인하고 git worktree 기반 작업 브랜치를 생성한 뒤 이슈 계획 문서를 만든다. 이슈 URL 기준으로 브랜치/worktree/계획 문서 초기화를 요청할 때 사용한다.
| name | git-master |
| description | Git 워크플로우 자동화(원자적 커밋 분리, 히스토리 정리, 변경 추적). 커밋 분리, rebase 계획/실행, 변경 이력 추적을 요청할 때 사용한다. |
변경사항을 이해하고 논리적 단위로 원자적 커밋을 생성합니다.
사용자 요청에 따라 자동으로 모드를 선택한다. 명시적 지정도 가능.
git-master → 변경사항 분석 후 자동 모드 선택
git-master commit → COMMIT 모드 강제
git-master rebase → REBASE 모드 강제
git-master search 함수명 → HISTORY_SEARCH 모드
변경사항을 분석하여 논리적 단위로 분리하고 각각 원자적 커밋을 생성한다.
git status --porcelain
git diff --stat
git diff --cached --stat
git diff
git diff --cached
각 파일의 변경 내용을 실제로 읽고 이해한다:
변경 파일을 논리적 단위로 그룹핑:
파일 수 기반 분리 기준:
| 파일 수 | 전략 |
|---|---|
| 1~3개 | 단일 커밋 가능 |
| 4~10개 | 2~3개 커밋으로 분리 검토 |
| 10개 초과 | 반드시 논리적 단위로 분리 |
실행 전에 커밋 계획을 사용자에게 보여준다:
## 커밋 계획
1. feat(auth): 로그인 기능 추가
- src/auth/login.ts
- src/auth/login.test.ts
2. refactor(utils): 헬퍼 함수 정리
- src/utils/helper.ts
3. docs: README 업데이트
- README.md
중요: 사용자 확인 후 실행한다.
git add <파일1> <파일2>
git commit -m "<메시지>"
git add → git commit 순서대로 실행git add . 또는 git add -A는 사용하지 않는다<type>(<scope>): <subject>
[body]
type:
| 타입 | 설명 |
|---|---|
| feat | 새로운 기능 |
| fix | 버그 수정 |
| refactor | 리팩토링 (기능 변경 없음) |
| style | 코드 스타일/포맷 (기능 변경 없음) |
| test | 테스트 추가/수정 |
| docs | 문서 변경 |
| chore | 빌드/설정/도구 변경 |
| perf | 성능 개선 |
| ci | CI 설정 변경 |
규칙:
프로젝트별 컨벤션 우선:
AGENTS.md를 확인하여 커밋 컨벤션이 있으면 그것을 따른다주의:
git rebase명령은 파괴적 작업이므로 반드시 사용자 승인이 필요하다.
git log --oneline -20
정리 대상 커밋 범위와 전략을 제안한다:
## Rebase 계획
대상: HEAD~5 (최근 5개 커밋)
1. pick abc1234 feat(auth): 로그인 구현
2. squash def5678 fix: 로그인 오타 수정
3. squash ghi9012 fix: 로그인 버그 수정
4. pick jkl3456 feat(auth): 회원가입 구현
5. reword mno7890 wip → feat(auth): 비밀번호 재설정
결과: 3개 커밋으로 정리
반드시 사용자 승인을 받은 후 실행한다.
특정 코드/파일의 변경 이력을 추적한다.
사용자가 지정한 파일, 함수, 키워드를 기준으로 검색 전략을 결정한다.
파일 기반:
git log --oneline --follow -- <파일경로>
git log -p -- <파일경로>
키워드/함수 기반:
git log -S "<키워드>" --oneline
git log -G "<패턴>" --oneline
특정 라인 기반:
git log -L <시작>,<끝>:<파일>
git blame <파일>
조회한 이력을 정리하여 보여준다: