بنقرة واحدة
pro-commit
브랜치명에서 이슈 번호를 자동 추출해 커밋 메시지를 완성하고 커밋한다. 이슈 연동 커밋, 커밋 메시지 자동 생성이 필요할 때 사용. /commit 호출 시 사용.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
브랜치명에서 이슈 번호를 자동 추출해 커밋 메시지를 완성하고 커밋한다. 이슈 연동 커밋, 커밋 메시지 자동 생성이 필요할 때 사용. /commit 호출 시 사용.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
develop 브랜치를 push하고 main으로 릴리스 PR(deploy PR)을 생성한 뒤 즉시 릴리스 노트를 작성해 RELEASE-CHANGELOG 워크플로우가 CodeRabbit 10분 대기 없이 automerge를 진행하게 한다. automerge 실패 시 기존 PR을 닫고 새 PR을 열어 재트리거하는 fix 기능도 포함. 앱스토어/플레이스토어 심사로 직결되는 레포(앱 심사 인지)는 릴리스 노트에 심사 경고 배너를 띄우고 정제를 더 엄격히 적용한다. 'deploy해줘', '배포해줘', 'deploy PR 올려줘', 'changelogfix', 'deploy 머지 안 됐어', 'PR 다시 열어줘' 등의 요청 시 사용.
GitHub Mode - 독립적인 GitHub 제어 스킬. GitHub로 하는 모든 이슈/PR 작업을 단독으로 수행한다. 이슈 생성(작성+등록), 이슈 조회/수정/검색/닫기/열기, 댓글 추가/수정/삭제, 라벨 추가/제거/교체, 담당자 추가/제거, PR 생성/조회/수정/머지/닫기, PR 릴리스노트, 레포 탐색, GitHub Actions 로그, Actions Secret 관리. 이슈 만들어줘, 이슈 올려줘, 이슈 등록, 버그 리포트, 기능 요청 이슈, QA 요청 이슈, 디자인 요청 이슈, PR 생성, PR 올려줘, PR 머지해줘, 이슈 댓글, 댓글 달아줘, 댓글 수정, 댓글 삭제, 이슈 확인해줘, 이슈 닫아줘, 이슈 수정해줘, 라벨 추가/바꿔줘/빼줘, 담당자 추가해줘, '/github', '/issue', 내 레포 보여줘, 레포 목록 탐색해줘, README 가져와줘, {레포명} 정보 봐줘, Org 레포 탐색해줘, secret 업데이트해줘, Actions secret 등록해줘, 환경변수 secret 올려줘, BACKEND_ENV_FILE 업데이트 등 GitHub 이슈/PR/레포/Actions/Secret 관련 요청이면 반드시 이 skill을 사용한다. 다른 스킬보다 먼저 트리거되어야 한다.
Plan Mode (WHAT 전략 수립) - 구현 전 '무엇을, 왜' 만들 것인지 확정한다. 사용자가 새 기능, 버그 수정, 리팩토링, 아키텍처 변경을 요청하거나 /plan을 호출할 때 사용. HOW(파일/함수/라인 단위 구현 계획)는 절대 포함하지 않는다 — 그건 analyze 책임. 코드 수정은 금지.
원격 서버에 SSH로 접속해 명령을 실행하고 결과를 확인하는 skill. AWS EC2, 시놀로지 NAS, 일반 Linux 서버 등 모든 SSH 접근 가능한 서버에 사용한다. 사용자가 '서버 확인해줘', '로그 봐줘', 'EC2 접속해', '시놀로지 접속해', 'prod 검수해줘', '서버 상태 확인', '배포 됐는지 확인해줘', '서버에서 ~해줘' 등을 언급하면 이 skill을 사용한다.
Report Mode - 구현 보고서 생성 전문가. Git diff와 이슈 분석을 통해 구현 내용을 정리한 보고서를 생성하고 GitHub PR 댓글로 자동 포스팅한다. 기능 흐름은 mermaid 플로우차트로 시각화한다. 구현 완료 후 보고서가 필요할 때, PR 설명 작성 시 사용. /report 호출 시 사용.
Review Mode - 코드 리뷰 전문가. 코드의 품질, 보안, 성능을 보안/성능/버그/품질 6관점으로 검토하고 Critical/Major/Minor 우선순위별 피드백을 제공한다. PR 리뷰, 파일 리뷰, 구현 후 셀프 검증이 필요할 때 사용. /review 호출 시 사용.
| name | pro-commit |
| description | 브랜치명에서 이슈 번호를 자동 추출해 커밋 메시지를 완성하고 커밋한다. 이슈 연동 커밋, 커밋 메시지 자동 생성이 필요할 때 사용. /commit 호출 시 사용. |
브랜치명에서 이슈 번호를 추출하고, GitHub API로 이슈 정보를 조회해 커밋 컨벤션에 맞는 메시지를 자동 완성하고 커밋한다.
git add한다 — 사용자가 멈춰서 직접 스테이징할 필요 없음git push는 절대 실행하지 않는다 — 커밋까지만 담당 (CLAUDE.md 규칙: push는 명시 허락 시에만)Co-Authored-By, Generated with Claude, 🤖, @claude 등 AI 서명/푸터/GitHub @mention trailer 일절 금지. 변경설명·푸터 어디에도 @username GitHub mention을 포함하지 않는다(이슈 본문에서 가져온 mention도 제거). 사용자의 git 설정으로만 커밋되어 사용자가 직접 작성한 것처럼 보여야 한다. 커밋 메시지는 본문만 작성한다.auto_approve == true)에서도 제안 메시지는 사용자에게 보여준 뒤 커밋한다 — 표시만 하고 즉시 진행. 응답을 기다리지 않는다.references/common-rules.md의 커밋 컨벤션 규칙을 숙지한다.
Read 도구로 config 파일을 읽는다. 이 고정 경로 한 곳만 본다 — ls·glob으로 탐색하거나 플러그인 캐시(~/.claude/plugins/cache/...)를 뒤지지 마라.
C:\Users\<사용자>\.projectops\config\config.json~/.projectops/config/config.jsongithub 섹션에서 auto_approve 값을 결정한다. 해석 우선순위 (위→아래로 검사, 먼저 발견되는 값 채택):
github.repos[] 중 owner == 현 OWNER && repo == 현 REPO인 항목의 commit.auto_approvegithub.commit.auto_approve (글로벌 기본값)false (안전 default — 수동 승인)판정 결과를 두 값으로 기억한다:
AUTO_APPROVE — boolean (true / false)CONFIG_HAS_KEY — boolean (true면 위 우선순위 1 또는 2에서 키 발견. false면 둘 다 없어 첫 실행 케이스)CONFIG_HAS_KEY=false인 경우는 5.5단계의 첫 실행 안내 분기 트리거로 사용한다.
사용자에게 노출하는 안내는 자연어로만 한다. "auto_approve", "config.json", "commit 섹션" 같은 키 이름·파일 경로를 사용자 메시지에 절대 쓰지 않는다. 사용자는 "자동으로 진행" / "매번 확인" 같은 자연어로 의사 표시하며 agent가 config를 직접 갱신한다.
$ARGUMENTS
PROJECT_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
git diff --cached --stat
git status --short
staged 파일이 있으면 그대로 진행한다.
staged 파일이 없으면 변경된(추적/미추적) 파일을 자동으로 스테이징한다:
git add -A
스테이징 후 다시 확인하고 진행한다:
git diff --cached --stat
이슈별로 따로 커밋하려는 경우(사용자가 명시), 해당 이슈 관련 파일만 골라서
git add <파일들>한다. 그 외엔git add -A로 일괄 스테이징한다.
브랜치명에서 이슈 번호를 추출한다:
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "")
ISSUE_NUMBER=$(echo "$BRANCH" | grep -oE '#[0-9]+' | grep -oE '[0-9]+' | head -1)
브랜치명 형식 예시: 20260422_#260_기능개선_제목 → 이슈 번호 260 추출
이슈 번호가 추출된 경우 — GitHub API로 이슈 정보 조회:
REMOTE_URL=$(git remote get-url origin 2>/dev/null || echo "")
OWNER=$(echo "$REMOTE_URL" | sed -E 's|.*github\.com[:/]([^/]+)/.*|\1|')
REPO=$(echo "$REMOTE_URL" | sed -E 's|.*github\.com[:/][^/]+/([^/.]+)(\.git)?$|\1|')
이슈 조회는 인라인 Python으로 하지 않는다. skills/pro-commit/scripts/commit_cli.py의 get-issue 서브커맨드로 이슈 정보를 가져온다. PAT는 commit_cli가 config.json에서 자동 로드하므로 직접 추출할 필요가 없다(환경변수가 있으면 우선 사용).
PROJECT_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
PYTHON=$(for _py in python3 python; do _path=$(command -v "$_py" 2>/dev/null) || continue; "$_path" -c "import sys; sys.exit(0)" 2>/dev/null && echo "$_path" && break; done)
[ -z "$PYTHON" ] && { echo "Python not found"; exit 1; }
SCRIPTS=$(ls -d ~/.claude/plugins/cache/*/projectops/*/skills/pro-commit/scripts 2>/dev/null | sort -V | tail -1); [ -z "$SCRIPTS" ] && SCRIPTS="$PROJECT_ROOT/skills/pro-commit/scripts"; cd "$SCRIPTS" || exit 1
PYTHONIOENCODING=utf-8 "$PYTHON" commit_cli.py get-issue {owner} {repo} {추출된 이슈번호}
출력 JSON에서 title(원본 제목)과 html_url을 얻는다. 이슈 제목은 agent가 임의 요약/재작성하지 않고, 아래 규칙으로 결정적으로 정제해 커밋 메시지에 쓴다 (SUH-ISSUE-HELPER의 extractIssueTitle과 동일):
[태그] 형식([버그], [기능개선] 등)을 모두 제거get-issue가 [ERROR] ... github_api_401(PAT 만료) 또는 github_api_404(이슈 없음)을 stderr로 내면, 그 사유를 안내하고 사용자에게 제목을 직접 입력받는다. → 4단계로 진행
이슈 번호가 없는 경우 — 즉시 멈추고 선택지 제시:
브랜치명에서 이슈 번호를 찾을 수 없습니다. (현재 브랜치: {브랜치명})
어떻게 할까요?
1. 이슈 번호를 직접 입력할게요
2. 이슈 없이 자유 형식으로 커밋할게요
3. 취소
staged 파일 목록과 diff를 분석하여 적절한 타입 추천:
| 변경 내용 | 추천 타입 |
|---|---|
| 새 기능, 새 파일 추가 | feat |
| 버그 수정, 에러 처리 | fix |
| 코드 구조 변경 (로직 유지) | refactor |
| 문서, 주석, README | docs |
| 설정 파일, 빌드 관련 | chore |
| 테스트 추가/수정 | test |
| 스타일, 포맷 | style |
references/common-rules.md 커밋 컨벤션에 따라 메시지를 구성한 뒤 제안만 한다.
형식: {clean_title} : {타입} : {변경설명} {html_url}
| 부분 | 결정 방식 |
|---|---|
clean_title | 3단계 정적 추출 스크립트의 clean_title 그대로 — agent가 다시 요약/재작성하지 않는다 |
html_url | 3단계 스크립트의 html_url 그대로 |
{타입} | 4단계 diff 분석으로 agent 추천 (사용자 승인) |
{변경설명} | staged diff 분석으로 agent 작성 (사용자 승인) |
{변경설명}에 @username GitHub mention(@claude 등)을 절대 포함하지 않는다. 이슈 본문·제목에서 따온 문구에 mention이 있으면 제거 후 사용한다.[시작 전]에서 판정한 AUTO_APPROVE / CONFIG_HAS_KEY 값에 따라 5.5단계로 분기한다.
AUTO_APPROVE == true)메시지를 사용자에게 표시만 하고 즉시 6단계로 진행한다. 응답을 기다리지 않는다.
🤖 이 레포는 확인 없이 바로 커밋되도록 설정돼 있어 메시지만 안내드리고 커밋합니다.
(다시 매번 확인받고 싶으시면 "확인받게 해줘"라고 말씀해주세요.)
📝 커밋 메시지:
{완성된 커밋 메시지}
커밋을 실행합니다.
이후 6단계 진행.
사용자가 메시지를 보고 "확인받게 해줘", "수동으로 바꿔줘", "다음부턴 확인받아줘" 같은 자연어로 응답하면, 6단계를 진행하기 전에 Read/Write 도구로
config.json을 갱신한다. 우선순위 1(레포별)에 키가 있었다면 그 값을false로, 없었다면 우선순위 2(글로벌)를false로 설정한다. 갱신 후 메시지는 그대로 두고 다시 사용자 승인을 받는다(B 분기로 전환).
AUTO_APPROVE == false)📝 제안 커밋 메시지:
{완성된 커밋 메시지}
이 메시지로 커밋할까요?
1. 네, 커밋합니다
2. 타입을 바꾸고 싶어요 (feat/fix/refactor/docs/chore/test/style)
3. 설명을 직접 수정할게요
4. 취소
사용자 응답을 기다린다. 응답 전까지 커밋을 절대 실행하지 않는다.
응답 분기:
CONFIG_HAS_KEY == false(첫 실행)이면 6단계 직전에 아래 [C. 첫 실행 자동화 제안]을 한 번만 실행한다CONFIG_HAS_KEY == false일 때만, 한 번)💡 다음 커밋부터 어떻게 진행할까요?
매번 커밋 직전에 메시지를 보여드리고 확인받는 방식이 기본입니다.
원하시면 이 확인 단계를 건너뛰고 곧바로 커밋이 진행되도록 바꿀 수 있습니다.
1. 이 레포 커밋은 앞으로 확인 없이 바로 진행해주세요
2. 모든 레포 커밋을 앞으로 확인 없이 바로 진행해주세요
3. 지금처럼 매번 커밋 메시지 확인받겠습니다
(언제든 "다시 확인받게 해줘" / "자동으로 바꿔줘"라고 말씀하시면 바꿀 수 있습니다)
응답에 따라 agent가 Read/Write 도구로 config.json을 갱신한다:
github.repos[]에서 현 OWNER/REPO 매칭 항목에 commit.auto_approve: true 추가github.commit.auto_approve: true 추가 (객체 없으면 생성)github.commit.auto_approve: false 추가 (다음 실행부터 묻지 않도록 키 자체는 남긴다)갱신 후 안내:
이후 6단계 진행.
갱신 시 주의:
references/config-rules.md §4규칙대로 전체 파일을 Read로 먼저 읽고 다른 섹션을 보존한 채 해당 키만 추가/수정해 Write한다. PAT·다른 repos 항목을 절대 날리지 않는다.
사용자가 1번(확인)을 선택했거나 자동 모드인 경우에만 실행한다.
커밋 메시지에 AI 서명/푸터를 절대 추가하지 않는다. Co-Authored-By, Generated with Claude, 🤖, @claude 등 GitHub @mention trailer 금지. 아래 명령 외에 --author 옵션이나 추가 trailer를 붙이지 않는다 — 사용자 git 설정 그대로 커밋한다.
커밋 직전, 메시지 끝의 @username mention trailer를 무조건 자동 제거한다(skill 차원 강제 sanitize). 5단계 검열을 우회한 경우의 마지막 방어선:
RAW_MSG="{최종 커밋 메시지}"
CLEAN_MSG=$(printf '%s' "$RAW_MSG" | sed -E ':a;$!N;$!ba;s/[[:space:]]*(@[A-Za-z0-9_-]+([[:space:]]+@[A-Za-z0-9_-]+)*)[[:space:]]*$//')
git commit -m "$CLEAN_MSG"
커밋 성공 후 결과 출력:
✅ 커밋 완료!
메시지: {커밋 메시지}
해시: {커밋 해시 앞 7자리}
push가 필요하면 직접 실행하세요:
git push origin {현재 브랜치명}