Agent skill

github-operator

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

View SKILL.md on GitHub Repository
Stars 0
Forks 0

Install this agent skill to your Project

npx add-skill https://github.com/aimskr/aims-claude-toolkit/tree/main/skills/github-operator

Metadata

Additional technical details for this skill

author
jaehashin
version
2.0.0

SKILL.md

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: 현재 상태 파악

반드시 먼저 실행:

bash
# 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으로 작성:

bash
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 반환
bash
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 표시

Recommended Agent Skills

Expand your agent's capabilities with these related and highly-rated skills.

aimskr/aims-claude-toolkit

build-error-resolver

빌드 에러, 빌드 오류, 컴파일 에러, 빌드 실패 해결, 의존성 에러 - Specialized in resolving build errors, compilation failures, and dependency issues. Use when build fails, compilation errors occur, or dependency conflicts arise. Do NOT use for runtime bugs or logic errors (use debug-specialist instead).

0 0
Explore
aimskr/aims-claude-toolkit

brainstorming

브레인스토밍, 아이디어, 기획, 구상, 아이디어회의, 설계, 요구사항 분석, 접근법 탐색 - Use before creating new features or significant changes to explore user intent, requirements, and design options. Collaborative brainstorming through step-by-step questioning. Do NOT use for simple bug fixes, config changes, or tasks with clear requirements already defined.

0 0
Explore
aimskr/aims-claude-toolkit

doc-coauthoring

문서 작성, 문서화, 문서, 스펙 작성, 기술 문서, 제안서, RFC, 설계 문서, 의사결정 문서 - Collaborative document co-authoring through 3 stages: context gathering, iterative refinement, and reader testing. Use when writing docs, proposals, tech specs, decision docs, or RFCs. Do NOT use for PRD/product requirements (use prd-strategist) or implementation plans (use writing-plans).

0 0
Explore
aimskr/aims-claude-toolkit

testing-strategy

테스트 전략, 테스팅 계획, QA 전략, 품질 보증, 테스트 피라미드, 테스트 시나리오, 커버리지 목표 - Designs test strategies including test pyramid ratios, scenario categories, and coverage targets. Use when planning how to test a feature, designing QA approach, or creating test plans. Do NOT use for TDD implementation (use tdd-workflow) or E2E test execution (use e2e-runner).

0 0
Explore
aimskr/aims-claude-toolkit

learning-research

학습 리서치, 학습 자료, 공부 자료, 학습, 공부, 스터디, 개념 정리, 이해 - 특정 주제를 깊이 이해하기 위한 학습 자료를 수집·정리한다. 병렬 전문가 서브에이전트로 개념, 원리, 실습, 심화 자료를 수집하고 이해도별로 체계화된 학습 노트를 생성한다. Obsidian vault에 자동 저장. 의사결정용 자료 조사는 research 스킬을, 시장조사는 market-research 스킬을 사용할 것.

0 0
Explore
aimskr/aims-claude-toolkit

devil-advocate

0 0
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results