# Git Pr Workflows Git Workflow > 코드 리뷰 단계부터 PR 생성까지 아우르는 포괄적인 Git 워크플로우. 전문적인 에이전트를 활용하여 품질 보증, 테스트 및 배포 준비 상태를 점검합니다. 이 워크플로우는 Conventional Commits, 자동화된 테스트 및 체계적인 PR 생성을 포함한 최신 Git 모범 사례를 구현합니다. - Skill: `dozerojeong/git-pr-workflows-git-workflow` (Agent Skill) - Install (CLI): `npx skillmds@latest add dozerojeong/git-pr-workflows-git-workflow` - Raw SKILL.md: https://api.skillmd.com/api/skills/dozerojeong/git-pr-workflows-git-workflow/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: DoZeroJeong (https://skillmd.com/u/dozerojeong) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/dozerojeong/git-pr-workflows-git-workflow --- # 다중 에이전트 오케스트레이션을 통한 완전한 Git 워크플로우 코드 리뷰 단계부터 PR 생성까지 아우르는 포괄적인 Git 워크플로우입니다. 품질 보증, 테스트 및 배포 준비 상태 점검을 위해 전문 에이전트들을 활용합니다. 본 워크플로우는 Conventional Commits(일관된 커밋 메시지 작성법), 자동화 테스트 및 구조화된 PR 생성을 포함하는 최신 Git 모범 사례를 적용합니다. [심층 분석: 이 워크플로우는 코드가 커밋되기 전 품질을 보장하기 위해 여러 에이전트를 조율합니다. `code-reviewer` 에이전트가 초기 품질 검토를 수행하고, `test-automator`가 모든 테스트 통과 여부를 확인하며, `deployment-engineer`가 프로덕션 배포 준비 상태를 검증합니다. 컨텍스트 전달과 함께 순차적으로 에이전트를 배치함으로써, 빠른 개발 속도를 유지하면서 손상된 코드가 저장소에 유입되는 것을 방지합니다. 또한, 여러 팀의 니즈에 맞게 구성 가능한 옵션으로 Trunk-based 및 Feature-branch 전략 모두를 지원합니다.] ## 이 워크플로우를 사용할 때 - 다중 에이전트 오케스트레이션을 동반한 포괄적 Git 워크플로우 작업 시 - 해당 워크플로우에 대한 가이드, 모범 사례 또는 체크리스트가 필요할 때 ## 이 스킬의 사용을 지양할 때 - 작업이 포괄적 Git 워크플로우 및 멀티 에이전트 오케스트레이션과 무관할 때 - 이 범위를 벗어난 다른 도메인이나 도구가 필요할 때 ## 지시사항 - 목표, 제약 조건 및 필요한 입력을 명확히 하세요. - 관련된 모범 사례를 적용하고 결과를 검증하세요. - 사용자에게 제안할 실행 가능한 명령어(단계)와 검증 방법을 명확히 제공하세요. - 상세한 예제가 필요하다면 `resources/implementation-playbook.md`를 열어 확인하세요. ## 설정 (Configuration) **타겟 브랜치 (Target branch)**: `$ARGUMENTS` (명시되지 않을 경우 기본값은 'main') **지원되는 플래그 (Supported flags)**: - `--skip-tests`: 자동화 테스트 실행 건너뛰기 (주의해서 사용 요망) - `--draft-pr`: 작업 진행 중(WIP) 상태를 위한 Draft PR로 생성 - `--no-push`: 모든 분석을 수행하되 리모트 저장소로 푸시하지 않음 - `--squash`: 리모트 푸시 전 커밋 스쿼시(Squash) - `--conventional`: 엄격한 Conventional Commits 포맷 강제 - `--trunk-based`: 트렁크 기반(Trunk-based) 개발 워크플로우 사용 - `--feature-branch`: 기능 브랜치(Feature branch) 개발 워크플로우 사용 (기본값) ## 1단계: 사전 커밋 리뷰 및 분석 (Phase 1: Pre-Commit Review and Analysis) ### 1. 코드 품질 평가 - `subagent_type="code-reviewer"`인 Task 도구를 사용합니다. - 프롬프트: "코드 품질 문제에 대해 아직 커밋되지 않은 모든 변경 사항을 검토하세요. 1) 코드 스타일 위반, 2) 보안 취약점, 3) 성능 우려 사항, 4) 누락된 예외 처리, 5) 불완전한 구현을 확인하세요. 심각도 수준(critical/high/medium/low)과 라인별 구체적인 피드백이 담긴 상세 보고서를 생성하세요. 출력 포맷: JSON 형식 `{issues: [], summary: {critical: 0, high: 0, medium: 0, low: 0}, recommendations: []}`" - 예상 출력: 다음 단계를 위한 구조화된 코드 리뷰 보고서 ### 2. 의존성 및 하위 호환성 침해(Breaking Change) 분석 - `subagent_type="code-reviewer"`인 Task 도구를 사용합니다. - 프롬프트: "다음 사항에 대해 변경 분을 분석하세요: 1) 새로운 의존성이나 버전 변경, 2) Breaking API 변경, 3) 데이터베이스 스키마 수정, 4) 환경 설정 변경, 5) 하위 호환성 문제. 이전 리뷰에서 생성된 컨텍스트: [이슈 요약 입력]. 마이그레이션 스크립트나 문서 업데이트가 필요한 변경 사항을 식별하세요." - 이전 단계로부터의 컨텍스트: Breaking Change를 암시할 수 있는 코드 품질 문제 - 예상 출력: Breaking change 평가 및 마이그레이션 요구사항 목록 ## 2단계: 테스트 및 검증 (Phase 2: Testing and Validation) ### 1. 테스트 실행 및 커버리지 - `subagent_type="unit-testing::test-automator"`인 Task 도구를 사용합니다. - 프롬프트: "수정된 코드에 대해 사용자에게 테스트 스위트 실행 명령어를 제안하고, 실행 결과를 전달받아 분석하세요. 1) 유닛 테스트, 2) 통합 테스트, 3) End-to-end 테스트(해당 시)를 실행할 것을 권고합니다. 커버리지 보고서를 생성하고 테스트되지 않은 코드 경로를 식별하세요. 리뷰에서 나온 문제점들 [critical/high 이슈 입력] 을 참고하여 리스크 영역을 테스트가 커버하는지 확인하십시오. 테스트 결과를 다음 형식으로 제공하세요: `{passed: [], failed: [], skipped: [], coverage: {statements: %, branches: %, functions: %, lines: %}, untested_critical_paths: []}`" - 이전 단계로부터의 컨텍스트: 테스트 커버리지가 필요한 치명적 코드 리뷰 이슈 - 예상 출력: 전체 테스트 결과 및 커버리지 메트릭 ### 2. 테스트 권장 사항 및 갭(Gap) 분석 - `subagent_type="unit-testing::test-automator"`인 Task 도구를 사용합니다. - 프롬프트: "테스트 결과 [요약 입력] 및 코드 변경을 기반으로 다음을 식별하세요: 1) 누락된 테스트 시나리오, 2) 커버되지 않은 예외(Edge) 케이스, 3) 검증해야 할 통합 포인트, 4) 필요한 성능 벤치마크. 리스크 우선순위에 따라 추가적 테스트 구현 권장 사항을 생성하세요. 파악된 Breaking Change를 고려하십시오: [Breaking changes 입력]." - 이전 단계로부터의 컨텍스트: 테스트 결과, Breaking Changes, 미테스트 경로 등 - 예상 출력: 우선순위가 정해진 추가 테스트 필요 목록 ## 3단계: 커밋 메시지 생성 (Phase 3: Commit Message Generation) ### 1. 변경 요약 및 범주화 (Categorization) - `subagent_type="code-reviewer"`인 Task 도구를 사용합니다. - 프롬프트: "Conventional Commits 사양에 따라 모든 변경을 분석하고 범주화하세요. 기본 변경 유형(feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert)과 범위를 식별하세요. 변경 대상: [파일 리스트 및 요약 입력]. 이것이 단일 커밋이어야 하는지 원자적(Atomic) 다수 커밋이어야 하는지 결정하세요. 다음 테스트 결과를 고려하세요: [테스트 요약 입력]." - 이전 단계로부터의 컨텍스트: 테스트 결과, 코드 리뷰 요약 - 예상 출력: 커밋 구조 제안(단일 커밋 vs 다중 커밋) ### 2. Conventional 커밋 메시지 작성 - `subagent_type="llm-application-dev::prompt-engineer"`인 Task 도구를 사용합니다. - 프롬프트: "할당된 범주 분류 결과 [분류 결과 입력] 에 따라 Conventional Commits 포맷 메시지들을 생성하세요. 포맷: `(): ` 다음 빈 줄 1개 추가 후 작업에 대한 내용과 이유를 ``에 적고, 필요한 경우 `