Git work report

git-work-report

Respond in the user's language throughout.

Turn your git commit history into structured work reports — resumes, performance reviews, and LinkedIn posts — in minutes.

Git 커밋 히스토리와 실제 코드 변경 내용(diff)을 본인 커밋 기준으로 분석하여, 6개월 단위 기술 성과 요약서를 자동 생성하는 스킬.

---

When to use

Use this skill when the user says:

• "Summarize my git commits" / "Generate a work report from my commits"
• "Create a resume-ready summary of my work" / "What did I work on this year?"
• 한국어: "내 커밋 히스토리를 요약해줘" / "기술 성과 요약서 만들어줘" / "이력서에 쓸 수 있게 작업 내용 정리해줘"

Or use shorthand presets:

• gwr — show tip and start from Q0
• gwr summary / gwr resume / gwr performance / gwr linkedin — prefills purpose
• gwr simple — prefills Simple Mode

---

Directory Structure

{output_dir}/work-summary/
├── README.md                          # 목차 (레포명 + 기간별 링크, 마지막 요약 날짜 기록)
├── report_summary.md                  # ★ 기본 최종 리포트 (항상 생성)
├── report_resume.md                   # 목적별 최종 리포트
├── report_performance.md
├── report_linkedin.md
├── {repo-a}/
│   ├── summary_{period_key}.md            # 중간 산출물
│   ├── summary_{period_key}_resume.md
│   ├── summary_{period_key}_performance.md
│   ├── summary_{period_key}_linkedin.md
│   └── _work/
│       └── {period_key}/
│           ├── v1/
│           │   ├── config.json            # fingerprint (재사용 판단용)
│           │   ├── 00_commit_list.md
│           │   └── {hash}.json
│           └── v2/ ...
└── {repo-b}/ ...

역할 분리:

파일	역할
{repo-name}/summary_{period_key}*.md	중간 산출물 (레포별, 기간별)
{repo-name}/_work/	커밋 단위 캐시 및 분석 근거
report_*.md	최종 deliverable (루트 하위)

{period_key} 규칙:

기간 선택	period_key 예시
전체 자동 분할 — 상반기	2026-H1
전체 자동 분할 — 하반기	2025-H2
사용자 지정 기간	202510_202603

---

Instructions

🔔 Step 0. User Configuration (Ask before starting)

Ask the user the following questions in order at skill start. Wait for all answers before beginning analysis.

If triggered by bare `gwr` (without any option), output the following before Q0:

💡 Tip: Use `gwr [option]` for quick access.
   gwr summary       — technical work summary
   gwr resume        — resume format
   gwr performance   — performance review format
   gwr linkedin      — LinkedIn post format
   gwr simple        — simple mode (git log only, faster)

Q0. Choose your analysis mode:
    1) Full analysis — git log + diff analysis (accurate, takes longer)
    2) Simple mode  — git log only, fast summary (commit message based)
    [Enter] (default = 1):

Q1. Where would you like to save the output?
    A 'work-summary' folder will be created inside this path.
    Examples: ~ → ~/work-summary/ | ~/Documents → ~/Documents/work-summary/
    [Enter] (default = current directory):

Q2. Enter the repository path(s) to analyze.
    Separate multiple repos with commas. Append `:branch-name` for non-default branch.
    Examples: (Enter) = current dir | ~/workspace/repo-a | ~/workspace/repo-a:release
    [Enter] (default = current directory):

Q3. Select the time period to analyze:
    1) Full history (auto-split into 6-month periods)
    2) Custom range (e.g., 2026-01 ~ 2026-03)
    3) Only new commits since last summary (incremental update)
    [Enter]:

Q4. What is the purpose of this report? (Select multiple: 1 3 or 1,3)
    1) Technical work summary (default)
    2) Resume — action-verb focused, concise, metrics-highlighted
    3) Performance review — context·background·results, references issue numbers
    4) LinkedIn post — English, starts with action verb
    [Enter] (default = 1):

Q5. Choose the output language:
    1) Korean (default) | 2) English | 3) Korean + English (bilingual) | 4) Other
    [Enter] (default = 1):
    (If Q4 included LinkedIn, default is 2 — English)
    (If 4 is selected, ask: "Please enter the language name (e.g., Japanese, French):")

답변을 바탕으로 아래 config를 구성하여 이후 모든 Step에서 참조한다:

config = {
  analysis_mode: "full" | "simple",              // Q0
  output_dir: "{path}/work-summary",             // Q1
  repos: [{path, branch}],                      // Q2
  period: "full" | "custom:{start}~{end}" | "incremental",  // Q3
  purposes: ["summary", "resume", "performance", "linkedin"], // Q4
  language: "ko" | "en" | "both" | "{custom}"   // Q5
}

---

Step 0.5. 최종 설정 확인

Q1~Q5 답변을 모두 받은 뒤, 분석 시작 전에 설정을 요약 출력하고 Y/n 확인을 받는다.

📋 Analysis Settings Summary
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
0) Analysis mode  : Full analysis (git log + diff)
1) Output path    : ~/Downloads/work-summary/
2) Repositories   : repo-a (main) | repo-b (release)
3) Period         : Full history (auto-split by 6 months)
4) Purpose        : Technical summary, Resume
5) Language       : Korean
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Proceed with these settings? (Y/n)
To edit a setting, enter its number (e.g., 2)

• Y (또는 Enter) → Step 1로 진행
• n → 수정할 항목 번호 입력 요청 → 해당 번호의 질문만 재질문 → 재확인 (최대 3회)

---

Step 1. 사전 확인 — 작성자 식별 → fingerprint 체크 → 커밋 범위 파악

각 레포에 대해 실행한다. 작성자를 먼저 식별한 후 fingerprint를 비교한다.

1-1. 작성자 식별

# 현재 git 설정 작성자 확인
git config user.name && git config user.email

# 전체 작성자 목록 확인
git --no-pager log --pretty=format:"%an | %ae" | sort | uniq -c | sort -rn

작성자 식별 규칙 (우선순위 순):

1. git config user.email → --author="{EMAIL}" 사용
2. user.email 없고 user.name 있음 → --author="{NAME}" fallback (동명이인 위험 시 사용자 확인)
3. 둘 다 없음 → 사용자에게 직접 입력 요청

# 본인 커밋 날짜 범위 확인
git --no-pager log {branch} --author="$AUTHOR" --pretty=format:"%ad" --date=short | sort -u

• 반드시 --author 옵션으로 본인 커밋만 필터링
• 점진적 업데이트 모드: README.md에서 마지막 요약 날짜를 읽어 그 이후 커밋만 대상

1-2. _work fingerprint 체크 (식별된 author 기준)

레포별로 {output_dir}/{repo-name}/_work/{period_key}/가 이미 존재하는지 확인한다. 존재하면 가장 큰 번호의 vN/config.json을 읽어 현재 설정과 비교한다.

비교 항목: repo_path, branch, author_email(또는 author_name), author_match_rule, period_range, language, analysis_mode

판단 규칙:

1. _work/{period_key}/가 처음 생성 → v1/ 생성
2. fingerprint 일치 → 기존 vN/ 재사용 (없는 커밋만 신규 분석, 00_commit_list.md만 갱신)
3. fingerprint 불일치 → 새 버전 디렉토리 생성 (예: v2/)

---

Step 2. 커밋 목록 생성 + Revert 쌍 제거 + 그룹핑 (Full Mode)

2-1. 커밋 해시 목록 추출 (Merge 커밋 제외)

git --no-pager log {branch} --author="$AUTHOR" --after="{START}" --before="{END}" \
  --pretty=format:"%H | %ad | %s" --date=short --no-merges

2-2. Revert 쌍 자동 감지 및 제거

Revert 커밋과 그 원본 커밋을 쌍으로 감지하여 목록에서 모두 제거한다. (Revert 후 재작성된 커밋은 유지)

git --no-pager log {branch} --author="$AUTHOR" --grep="^Revert" \
  --pretty=format:"%H %s" --no-merges

2-3. 유사 커밋 그룹핑 (클러스터링)

같은 파일·모듈을 건드린 커밋을 사전에 그룹핑한다. 그룹핑 기준 (우선순위 순):

1. 동일 파일명 패턴 (예: feature_pipeline*.yaml)
2. 커밋 메시지의 공통 키워드
3. 날짜 근접성 (3일 이내 연속 커밋)

00_commit_list.md 형식:

# {YYYY}-H1 커밋 목록

## [그룹 A] feature_pipeline 구축
| # | 해시 | 날짜 | 메시지 | 처리 |
|---|------|------|--------|------|
| A1 | dc820de | 2026-03-06 | feat: feature_pipeline 추가 | ⬜ |
| A2 | 7d1eddc | 2026-03-06 | fix: moving path 버그 수정 | ⬜ |

---

Step 2-S. 커밋 목록 생성 (Simple Mode)

config.analysis_mode == "simple" 일 때만 실행.

git --no-pager log {branch} --author="$AUTHOR" --after="{START}" --before="{END}" \
  --pretty=format:"%H | %ad | %s" --date=short --no-merges

Revert 쌍 제거: Step 2와 동일. 메시지 기반 그룹핑: diff 없이 커밋 메시지 패턴으로만 그룹핑 (feat/fix/refactor prefix 기준 1차 분류 → 공통 키워드 → 날짜 근접성).

Simple Mode에서 _work/{period_key}/vN/에는 config.json과 00_commit_list.md만 저장.

---

Step 3. 커밋별 diff 분석 → JSON 저장 (Full Mode)

그룹 순서대로 커밋을 처리한다. 이미 {hash}.json이 존재하면 스킵. 처리 완료 시 00_commit_list.md 해당 행 처리 컬럼을 ✅로 업데이트.

3-0. 커밋 규모 판별 (일반 vs 대형)

git --no-pager show {commit_hash} --stat --no-patch
git --no-pager show {commit_hash} --patch \
  -- '*.yaml' '*.py' '*.sql' '*.md' '*.json' \
  ':!*.lock' ':!*.png' ':!*.jpg' ':!*.gif' \
  | grep '^+' | grep -v '^+++' | wc -l

대형 커밋 기준: 필터링 후 추가 줄 300줄 이상 OR 변경 파일 10개 이상

3-1A. 일반 커밋 — diff 전체 읽기

git --no-pager show {commit_hash} --patch \
  -- '*.yaml' '*.py' '*.sql' '*.md' '*.json' \
  ':!*.lock' ':!*.png' ':!*.jpg' ':!*.gif' \
  | grep -v '^-' | grep -v '^@@' | grep -v '^diff' | grep -v '^index'

3-1B. 대형 커밋 — 단계적 추출 (4단계)

1단계: 메타데이터 수집 — 파일 목록, 변경 규모, 메시지, 커밋 본문

git --no-pager show {commit_hash} --stat --no-patch
git --no-pager show {commit_hash} --format="%B" --no-patch

2단계: 우선순위 파일 선별 및 상세 조회 — inline 문서 패턴(doc_md:, description:, GOAL:) → .sql/HiveQL → DAG 태스크 정의 → 신규 파일 순으로 우선

3단계: 의미 밀도 높은 패턴만 추출

grep -A5 'doc_md:\|description:\|GOAL:'
grep -E '^\+.*(FROM|INTO|INSERT|CREATE TABLE|database_name)'
grep -E '^\+.*(def |task_id|dag_id|BashOperator|PythonOperator)'
grep -E '^\+.*(JIRA-|#[0-9]+|[A-Z]+-[0-9]+|schedule_interval|retries)'

4단계: 추출 결과로 JSON 구조화 (전체 diff 미읽음)

3-2. 우선 추출 항목 (정확도 향상)

우선순위	항목	예시 패턴
1순위	inline 문서 패턴 (doc_md:, description:, GOAL:)	비즈니스 목적 명문화
1순위	JIRA·이슈 번호	JIRA-1234, PROJ-123
2순위	파일 상단 # 주석	GOAL:, 파이프라인 설명
3순위	테이블·DB명	FROM, INTO, database_name
4순위	기술 키워드	TEZ, TriggerDagRun, HiveQL

3-3. 분석 결과 저장 (경량 JSON)

{
  "hash": "dc820de",
  "date": "2026-03-06",
  "group": "A",
  "category": "feat",
  "files": ["yamls/hive_query/feature/feature_pipeline_step1.yaml"],
  "representative_files": ["feature_pipeline_step1.yaml"],
  "tables": ["myproject.feature_table"],
  "tech": ["HiveQL", "TriggerDagRun", "TEZ"],
  "business_logic": "Feature pipeline Step1 신규 구축",
  "jira": ["JIRA-1234"],
  "scale": "new_file",
  "large_commit": false,
  "summary": "feature_pipeline Step1 DAG 신규 구축"
}

scale 값: new_file | hotfix | refactor | config_change

---

Step 4. 최종 요약서 작성 (Full Mode)

_work/{YYYY}-H1/*.json을 모두 읽어 그룹 단위로 집계 후 요약서를 생성한다.

요약서 구성:

1. 기간 개요: 총 커밋 수, 활동 기간, 그룹 수, 주요 흐름
2. 주요 작업 분류 (카테고리 × 그룹): 근거 커밋 수, 대표 파일, 테이블명·비즈니스 로직·기술 스택, "구축 → 안정화" 흐름 서술
3. 기술적 하이라이트: 신기술 도입, 외부 시스템 연동
4. 성과 요약 (3~5개): 목적별 포맷으로 출력

JIRA/issue references는 performance review output에만 포함. summary/resume/LinkedIn에서는 제외.

---

Step 4-S. 커밋 메시지 기반 요약서 작성 (Simple Mode)

config.analysis_mode == "simple" 일 때만 실행.

00_commit_list.md의 커밋 메시지만을 바탕으로 요약서를 작성한다. 구성은 Step 4와 동일하나, 데이터는 메시지 기반.

출력 주의사항: 결과물 서두에 반드시 아래 문구를 포함:

> ⚠️ This summary is based on commit messages only (Simple Mode). Actual code changes are not reflected.

---

Step 5. 목적별 리포트 파일 생성

config.purposes에 따라 레포별 중간 산출물(summary_*.md)을 생성한다. 기존 JSON/summary를 재가공 (diff 재분석 금지).

파일명 매핑:

purposes 값	레포 중간 산출물	최종 리포트	생성 조건
summary (기본)	summary_{period_key}.md	report_summary.md	항상 생성 — JIRA 제외
resume	summary_{period_key}_resume.md	report_resume.md	purposes에 포함 시 — JIRA 제외
performance	summary_{period_key}_performance.md	report_performance.md	purposes에 포함 시 — JIRA 포함
linkedin	summary_{period_key}_linkedin.md	report_linkedin.md	purposes에 포함 시 — JIRA 제외

기술 성과 요약 (summary_{period_key}.md)

• 그룹별 작업 흐름과 기술 스택 서술, 커밋 수, 테이블명 포함 (JIRA 제외)

이력서용 (summary_{period_key}_resume.md)

• 동사 중심, 간결 (1~2줄), 수치 강조 (JIRA 제외)
• 예: Feature pipeline 설계·구축 (HiveQL, TEZ, Airflow K8s)

성과보고서용 (summary_{period_key}_performance.md)

• 기간·배경·결과 포함 상세 서술, JIRA 번호 병기
• 예: [2026.03] Feature pipeline 신규 구축 (JIRA-1234): 데이터 기반 이동 경로 탐색 DAG 개발. TEZ 엔진 전환으로 처리 안정성 개선.

LinkedIn용 (summary_{period_key}_linkedin.md, 영문)

• Present tense, action verb 시작 (JIRA 제외)
• 예: Designed and built feature pipeline (HiveQL, TEZ Engine, Airflow K8s).

---

Step 6. 최종 리포트 생성 (report_*.md)

레포별 summary_*.md와 _work/*.json을 집계하여 최종 리포트를 생성한다. 토큰 절약 원칙: JSON → summary → raw diff 순으로 우선 활용. diff 재읽기 금지.

report_summary.md (항상 생성)

# Technical Work Report
> 분석자: {author} | 생성일: {date} | 프로젝트: {N}개 | 작성 목적: {purposes}

## 핵심 성과 요약
- {전체 성과 1}
- {전체 성과 2}
- {전체 성과 3}

---

## Project: {repo-name}
> 레포: {repo-path} | 브랜치: {branch} | 분석 기간: {period}

### {period_key}
{summary}

---

정렬 규칙: 프로젝트(레포) 섹션 순서 = 사용자 입력 순서. 기간 섹션 = 연도 내림차순 (H2 > H1).

report_summary.md 작성 예시 (참고용):

# Technical Work Report
> 분석자: 홍길동 | 생성일: 2026-06-17 | 프로젝트: 2개 | 작성 목적: summary

## 핵심 성과 요약
- Feature pipeline 설계·구축 (HiveQL, TEZ, Airflow K8s): 이동 경로 탐색 DAG 3종 개발, TEZ 엔진 전환으로 처리 시간 40% 단축
- Batch pipeline 고도화: 스케줄러 재설계로 지연율 15%→2% 개선, 모니터링 대시보드 구축
- 레거시 ETL 마이그레이션: Hive → Spark SQL 전환, 5개 테이블 이관 완료

---

## Project: data-platform
> 레포: ~/workspace/data-platform | 브랜치: main | 분석 기간: 2026-H1

### 2026-H1
**Feature Pipeline 구축 (33 commits)**
Feature pipeline Step1~3 DAG 신규 구축. HiveQL 기반 피처 생성 로직 구현, TEZ 엔진 적용으로 쿼리 안정화. TriggerDagRun 패턴으로 파이프라인 체이닝 구성.

**Batch Pipeline 고도화 (15 commits)**
스케줄러 인터벌 재설계, 지연 알림 시스템 추가. Airflow K8s 환경에서 리소스 경합 문제 해결.

**레거시 마이그레이션 (8 commits)**
Hive → Spark SQL 전환. myproject.legacy_table 외 4개 테이블 이관 완료.

---

## Project: ml-service
> 레포: ~/workspace/ml-service | 브랜치: main | 분석 기간: 2026-H1

### 2026-H1
**모델 Serving API 구축 (12 commits)**
FastAPI 기반 추론 엔드포인트 개발, 배치 예측 파이프라인 연동. Redis 캐싱 도입으로 응답 시간 200ms → 50ms 개선.

멀티레포 전용 — 레포별 기여 비중 표 (레포 2개 이상인 경우에만 추가):

레포	기간	커밋 수	주요 기술 스택	비중
repo-a	2026-H1	33	HiveQL, TEZ, Airflow	90%
repo-b	2026-H1	4	Python, FastAPI	10%

목적별 리포트 (report_resume.md 등)

purposes에 해당하는 레포별 summary_{period_key}_{purpose}.md를 통합하여 각 report_{목적}.md를 생성한다. 구조는 report_summary.md와 동일.

---

Step 7. 마무리

1. {config.output_dir}/work-summary/README.md 목차 업데이트 (마지막 요약 날짜 기록 — 점진적 업데이트용)
2. _work/ 디렉토리 삭제 여부를 사용자에게 확인 후 처리

---

Output Format

Output format adapts to config.language. Use the appropriate language for section headings and report content.

Performance summary sentence format (Korean):

• [시스템명] 신규 설계 및 구축: [기술 스택·핵심 로직] 포함, [이슈] 연계
• [기술명] 전환/도입: [배경] → [개선 효과] 달성
• [작업명] 구현 및 운영 안정화: [반복 수정 횟수]회 수정 끝에 안정화

Performance summary sentence format (English):

• Designed and built [System Name]: including [tech stack · core logic], linked to [issue]
• Introduced/migrated to [Technology]: [background] → achieved [improvement]
• Implemented and stabilized [Feature]: stabilized after [N] iterative fixes

---

Notes

• Merge 커밋은 --no-merges 옵션으로 제외
• Revert 쌍(원본+Revert)은 Step 2에서 자동 제거. Revert 후 재작성 커밋은 유지
• 커밋 메시지가 모호한 경우(bug fix, no message) diff의 inline 문서 패턴·주석·테이블명으로 실제 내용 파악
• 대형 커밋(필터 후 추가 줄 300줄 이상 OR 변경 파일 10개 이상)은 Step 3-1B 단계적 추출 적용. 임의 라인 상한으로 자르지 않음
• 삭제 줄(-)은 분석에서 제외하여 토큰 절감
• user.email 미설정 시 user.name으로 fallback. 동명이인 위험 시 사용자에게 확인 요청