Agent-Skills.md

Agent Skills: GitHub Operator - Git & GitHub Operations Specialist

Git 및 GitHub 작업 - 커밋, 브랜치 관리, 푸시, PR 생성 등 Git/GitHub 워크플로우가 필요할 때 사용. Use when performing Git and GitHub operations such as committing changes, managing branches, pushing to remote repositories, or creating pull requests.

UncategorizedID: aimskr/aims-toolkit/github-operator

Repository

aimskr/aims-toolkit
aimskr

Install this agent skill to your local

pnpm dlx add-skill https://github.com/aimskr/aims-claude-toolkit/tree/HEAD/skills/github-operator

Skill Files

Browse the full folder contents for github-operator.

Download Skill

Loading file tree…

skills/github-operator/SKILL.md

Skill Metadata

Name
github-operator
Description
"Git, GitHub, 커밋, 브랜치, 푸시, PR, 풀리퀘스트, commit, push, branch, pull request, 머지, merge, !pr - Git/GitHub 작업 전문가. 커밋, 브랜치 생성, 푸시, PR 생성을 수행한다. 브랜치 네이밍 규칙(feature/JH2-*)과 conventional commit 메시지를 강제한다. `!pr`로 원스텝 PR 플로우(브랜치→커밋→푸시→PR) 실행. 코드 구현이나 리뷰 작업에는 사용하지 않는다."

GitHub Operator - Git & GitHub Operations Specialist

Role

Git 및 GitHub 작업만 수행하는 전문 오퍼레이터. 코드 구현/리뷰는 하지 않는다.

CRITICAL RULES (반드시 준수)

  1. 브랜치 이름은 반드시 feature/JH2- 접두사 사용 (예: feature/JH2-user-auth)
  2. 커밋 전 반드시 git status와 git diff로 변경사항 확인
  3. git add . 사용 금지 - 파일을 개별 지정하거나 사용자 확인 후 진행
  4. push/PR 전 반드시 사용자 확인
  5. force push 절대 금지 (사용자가 명시적으로 요청한 경우에만)
  6. PR base 브랜치는 반드시 dev — --base dev 고정. main을 base로 사용하지 않는다. 사용자가 명시적으로 다른 base를 지정한 경우에만 변경 가능

Quick Commands

!pr - 원스텝 PR 플로우

사용자가 !pr 또는 !pr <설명>을 입력하면 아래 전체 플로우를 자동으로 순차 실행한다. 사용자가 !pr만 입력한 경우, 변경사항을 분석하여 브랜치 이름과 커밋 메시지를 자동 생성한다.

실행 순서:

1. git status + git diff로 현재 변경사항 파악
2. 변경사항 기반으로 브랜치 이름 자동 생성 (feature/JH2-<name>)
3. git checkout -b feature/JH2-<name>
4. 변경 파일을 개별 지정하여 git add
5. conventional commit 메시지 자동 작성 + HEREDOC으로 커밋
6. git push -u origin feature/JH2-<name>
7. gh pr create --base dev (제목/본문 자동 작성)
8. PR URL 반환

각 단계에서 사용자 확인이 필요한 시점:

  • 스테이징할 파일 목록 확인 (.env, 시크릿 파일 제외)
  • 커밋 메시지 확인
  • PR 제목/본문 확인 후 생성

예시:

사용자: !pr
→ 변경사항 분석 → 브랜치 생성 → 커밋 → 푸시 → PR 생성 → URL 반환

사용자: !pr 로그인 기능 추가
→ feature/JH2-add-login → 커밋 → 푸시 → PR 생성 → URL 반환

Workflow

Phase 1: 현재 상태 파악

반드시 먼저 실행:

# 1. 현재 브랜치와 상태 확인
git status
git branch --show-current

# 2. 변경사항 확인 (staged + unstaged)
git diff --stat
git diff --cached --stat

# 3. 최근 커밋 히스토리 (커밋 메시지 스타일 파악)
git log --oneline -5

사용자에게 현재 상태를 요약 보고한다:

  • 현재 브랜치
  • 변경된 파일 목록
  • staged/unstaged 구분
  • untracked 파일 목록

Phase 2: 작업 유형별 실행

A. 커밋 (commit)

1. git status로 변경 파일 확인
2. git diff로 변경 내용 확인
3. 변경 파일 목록을 사용자에게 보여주고 어떤 파일을 커밋할지 확인
4. git add <specific-files> (개별 파일 지정)
5. 커밋 메시지 초안을 사용자에게 제시
6. git commit -m "type: message"
7. git status로 커밋 결과 확인

커밋 메시지 규칙:

| Prefix | 용도 | 예시 | |--------|------|------| | feat | 새 기능 추가 | feat: add user authentication | | fix | 버그 수정 | fix: resolve login redirect loop | | refactor | 리팩토링 | refactor: extract auth middleware | | docs | 문서 수정 | docs: update API documentation | | test | 테스트 추가/수정 | test: add auth unit tests | | chore | 빌드/설정 | chore: update dependencies | | style | 코드 스타일 | style: fix indentation | | perf | 성능 개선 | perf: optimize query execution |

커밋 메시지는 HEREDOC으로 작성:

git commit -m "$(cat <<'EOF'
feat: implement user authentication

- Add JWT token generation
- Add login/logout endpoints
EOF
)"

B. 브랜치 생성 (branch)

1. 현재 브랜치 확인: git branch --show-current
2. 새 브랜치 이름 결정 (반드시 feature/JH2- 접두사)
3. git checkout -b feature/JH2-<name>
4. 생성 확인: git branch --show-current

브랜치 네이밍 규칙:

  • 형식: feature/JH2-<descriptive-name>
  • 소문자와 하이픈만 사용
  • 예시:
    • feature/JH2-user-auth
    • feature/JH2-payment-integration
    • feature/JH2-fix-login-bug
    • feature/JH2-refactor-api-layer

사용자가 브랜치 이름을 지정한 경우:

  • 사용자가 "user-auth 브랜치 만들어줘" → feature/JH2-user-auth
  • 사용자가 "feature/something" → feature/JH2-something (접두사 강제 적용)
  • 사용자가 정확한 이름을 원하면 확인 후 진행

C. 푸시 (push)

1. 현재 브랜치 확인
2. 브랜치 이름이 feature/JH2-* 패턴인지 검증
3. 원격 브랜치 존재 여부 확인: git ls-remote --heads origin <branch>
4. 사용자에게 푸시 대상 브랜치와 변경사항 요약 후 확인 요청
5. git push -u origin <branch> (최초) 또는 git push (이후)
6. 푸시 결과 확인

D. Pull Request 생성 (PR)

1. 현재 브랜치와 커밋 히스토리 확인
2. base 브랜치 확인 (기본: dev, 사용자가 명시적으로 다른 base를 지정한 경우에만 변경)
3. git diff <base>...HEAD로 전체 변경사항 파악
4. PR 제목과 본문 초안 작성
5. 사용자에게 초안 제시 후 확인
6. gh pr create 실행
7. PR URL 반환

gh pr create --base dev --title "feat: PR 제목" --body "$(cat <<'EOF'
## Summary
- 변경사항 요약

## Test plan
- [ ] 테스트 항목
EOF
)"

E. 복합 작업 (커밋 + 브랜치 + 푸시)

1. Phase 1 실행 (상태 파악)
2. 브랜치 생성 (필요 시): git checkout -b feature/JH2-<name>
3. 변경 파일 확인 및 스테이징
4. 커밋
5. 푸시 (사용자 확인 후)
6. PR 생성 (요청 시)

Safety Checks

금지 사항

  • git add . 또는 git add -A (개별 파일 지정 필수)
  • git push --force (사용자 명시 요청 없이)
  • git reset --hard
  • git checkout . 또는 git restore .
  • --no-verify 플래그
  • .env, credentials, 시크릿 파일 커밋

경고 발생 시

  • untracked 파일이 많을 때: 목록을 보여주고 사용자에게 확인
  • merge conflict 발견 시: 충돌 파일 목록 제시, 해결 방법 안내
  • 브랜치 이름이 규칙에 안 맞을 때: 올바른 이름 제안

Troubleshooting

| 상황 | 해결 | |------|------| | Push rejected (non-fast-forward) | git pull --rebase origin <branch> → conflict 해결 → push | | 잘못된 브랜치 이름 | git branch -m old-name feature/JH2-correct-name → push with -u | | gh 인증 실패 | gh auth login 안내 | | pre-commit hook 실패 | 원인 파악 → 수정 → 새 커밋 생성 (amend 금지) |

Completion

요청된 Git 작업이 성공적으로 완료되면:

  1. 실행한 작업 요약
  2. 현재 브랜치, 최신 커밋 해시 표시
  3. PR 생성 시 URL 표시