briefing

name	briefing
description	아침 브리핑. 최근 커밋을 분석하여 오늘 개발 시작 전에 알아야 할 변경 사항, 영향 범위, 주의 사항을 요약합니다.
when_to_use	오늘 뭐 바뀌었어, 아침 브리핑, 최근 커밋 요약, 개발 시작 전 알아야 할 것.
allowed-tools	Read, Write, Glob, Grep, Bash

역할

현재 브랜치에서 최근 커밋을 분석하여 아침 브리핑 문서를 작성한다.

이 문서의 목적: "오늘 개발을 시작하기 전에 알아야 할 것"을 빠르게 파악하는 것.

톤: 팀 리드 스탠드업. 핵심 우선, 주의사항은 정확히.

외부 데이터 의존

데이터	경로	필수/선택	부재 시 동작
프로젝트 컨텍스트	CLAUDE.md	선택	일반 SW 가정으로 진행, [프로젝트 규칙 미확인] 태그
봇 인덱스	bot/INDEX.md 또는 .local.claude/ONBOARDING.md	선택	디렉터리 Glob 으로 fallback
비즈니스 규칙	.local.claude/biz-rules.md	선택	Tier 1(도메인 무관) 점검만 수행
모듈 상세	.local.claude/modules/{name}.md	선택	코드 Grep 직접 fallback
최근 commits	git log (기간 기본 3일)	필수	git 없음 안내 후 종료
이전 briefing	.local.claude/briefing/	선택	첫 브리핑 모드
팀원 매핑	.local.claude/team.md	선택	git author 그대로 표기

프로젝트 컨텍스트 (필수, 분석 시작 전 read)

다음 파일이 존재하면 먼저 read 하여 프로젝트 도메인, 구조, 규칙을 파악:

파일	용도
CLAUDE.md (자동 로드됨)	프로젝트 빌드, 구조, 컨벤션, 금지 사항
bot/INDEX.md 또는 .local.claude/INDEX.md	사실 카탈로그 진입점
.local.claude/biz-rules.md (있을 시)	도메인 규칙과 상태 전이. 변경의 도메인 영향 해석에 필요
.local.claude/modules/*.md (있을 시)	변경된 모듈의 서비스, 테이블, 이벤트 연동
bot/*.md 또는 .local.claude/ONBOARDING.md (있을 시)	모듈 간 흐름과 이벤트
팀원 매핑 파일 (있을 시)	git author를 팀원 닉네임으로 매핑

위 파일이 없으면 일반 git diff 분석만 수행. 도메인 영향 해석은 생략하고 변경 사실만 기록.

기간 설정

입력	기간
/briefing (기본)	최근 3일
/briefing 1일 또는 /briefing today	오늘
/briefing 7일 또는 /briefing 1주	최근 7일
/briefing YYYY-MM-DD..YYYY-MM-DD	지정 기간

정보 수집

[1M 활용] 아래 5개 스텝은 단일 메시지에서 병렬 호출로 처리:

• Bash: git branch --show-current, git log --since="N days ago" --oneline --format="%h %an %ad %s", git log --since="N days ago" --name-only, git log --merges, git shortlog -s -n
• Read: CLAUDE.md, .local.claude/biz-rules.md, .local.claude/team.md, 관련 .local.claude/modules/*.md
• Glob/Bash: ls .local.claude/briefing/ | tail -5, 이전 브리핑 3~5개 Read
• gh CLI: gh pr list --state open --json ...

1. 커밋 수집

# 현재 브랜치
git branch --show-current

# 최근 N일 커밋 목록 (기본 3일)
git log --since="3 days ago" --oneline --format="%h %an %ad %s" --date=short

# 커밋 수
git log --since="3 days ago" --oneline | wc -l

# 머지 커밋 (PR 머지 = 배포 단위)
git log --since="3 days ago" --merges --oneline

2. 변경 파일 및 diff 확인

# 변경된 파일 목록
git log --since="3 days ago" --name-only --oneline

# 특정 커밋의 상세 diff
git show {커밋해시} --stat
git show {커밋해시} -- {특정파일}

# 전체 기간의 diff 요약
git diff $(git log --since="3 days ago" --format="%H" | tail -1)..HEAD --stat

3. 변경자 매핑

.local.claude/team.md (조직 구조 + 닉네임-실명 매핑) 가 있으면 read 후 git author를 팀원 닉네임으로 매핑.

4. 도메인 맥락 ("프로젝트 컨텍스트" 절의 파일에서 read)

• biz-rules.md: 상태 전이, 비즈니스 규칙 위반 여부 점검
• modules/{name}.md: 변경된 모듈의 서비스와 이벤트 연동
• bot/*.md 또는 .local.claude/ONBOARDING.md: 모듈 간 이벤트 흐름

5. 이전 브리핑 연속성

# 기존 브리핑 파일 확인
ls .local.claude/briefing/ 2>/dev/null | tail -5

• 이전 브리핑이 있으면 최근 3~5개를 Read로 읽는다
• 이전에 언급된 모듈/기능과 오늘 변경된 모듈을 대조
• 이전 브리핑의 "주의가 필요한 부분"이 해소되었는지 확인
• 이전 브리핑이 없으면 이 단계 생략

분석 방법

1. 커밋 메시지 + 실제 diff를 함께 확인한다. 메시지만으로는 실제 변경의 절반도 파악 못 함.
2. 커밋 메시지만으로 목적이 불명확하면 diff 내용으로 추론하고 [추정] 표기.
3. 관련 커밋들을 목적별로 그룹핑 (기능 추가, 버그 수정, 리팩토링, 설정/인프라).
4. 프로젝트 구조에 따라 영향 범위를 분리 (예: 프론트/백엔드, 모듈별).
5. 공통 모듈 변경은 전체 영향이므로 반드시 주의사항에 기재. 공통 모듈 식별은 CLAUDE.md 의 구조 섹션 또는 bot/INDEX.md 참조.

문서 구성

1. 한눈에 보기

• 분석 기간, 브랜치명, 총 커밋 수
• 이 기간의 핵심 변경을 1~2문장으로 요약 (경영진에게 설명하듯 간결하게)

2. 작업 요약

관련 커밋들을 목적별로 그룹핑하여 정리:

그룹	기준
기능 추가	새 API, 새 화면, 새 기능
버그 수정	기존 기능의 오류 수정
리팩토링	동작 변경 없는 코드 개선
설정/인프라	yml, pom.xml, 빌드, 배포 관련

각 그룹마다:

• 무엇을 왜 변경했는지
• 관련 커밋 해시 병기
• 변경자(닉네임) 표기
• 도메인 맥락 해석: 기술 변경이 비즈니스/도메인에서 무엇을 의미하는지 설명. 컨텍스트 파일 (biz-rules, modules) 참조하여 해석. 도메인 해석이 확실하지 않으면 [추정] 표기

3. 연속 변경 추적 (이전 브리핑 대비)

이전 브리핑이 있을 때만 작성. 없으면 "첫 브리핑 (이전 데이터 없음)"으로 표기.

며칠에 걸쳐 점진적으로 배포되는 변경을 추적:

#### 진행 중인 변경 흐름
| 기능/모듈 | 시작일 | 진행 상황 | 오늘 변경 |
|----------|--------|----------|----------|

#### 이전 주의사항 추적
| 이전 브리핑 날짜 | 주의사항 | 현재 상태 |
|----------------|---------|----------|

추적 관점:

• 같은 모듈이 연속으로 변경: 기능 개발 진행 중
• Revert 후 재적용: 문제 있었다는 신호
• 이전 주의사항 미해소
• 새로 등장한 모듈

4. 비즈니스/도메인 영향

작업 요약의 도메인 해석을 바탕으로, 이번 배포가 현업 사용자에게 미치는 영향을 한 테이블로 요약:

| 변경 | 영향받는 업무 | 사용자 관점 변화 | 영향도 |
|------|------------|----------------|--------|

영향도 기준:

• 높음: 기존 업무 흐름과 데이터 처리 변경, 사용자 안내 필요 가능
• 중간: UX 개선, 검증 강화. 세부 동작 변경
• 낮음: UI 텍스트 등 기능 변화 없는 변경

인프라/리팩토링만 있으면 "해당 사항 없음 (사용자 영향 없는 변경)"으로 표기.

5. 변경 영향 범위

프로젝트 구조 (CLAUDE.md 참조) 에 맞춰 정리. 예: 프론트엔드/백엔드/API 변경 등.

#### 백엔드 (또는 해당 영역)
| 모듈 | 변경 영역 | 변경 내용 요약 |
|------|----------|--------------|

#### 프론트엔드 (있을 시)
| 모듈 | 화면(메뉴) | 변경 내용 요약 |
|------|-----------|--------------|

#### API 변경 (엔드포인트 변경이 있을 때만)
| 변경 유형 | URL | 내용 |
|----------|-----|------|

6. 주의가 필요한 부분

아래 관점에서 실제 diff를 검토하고, 해당 사항이 있을 때만 기재.

Tier 1: 도메인 무관 일반 점검 (모든 프로젝트 공통):

카테고리	확인 포인트
공통 모듈 변경	전체 영향 가능성 (CLAUDE.md "프로젝트 구조" 의 공통 모듈 식별)
DB/SQL 변경	NULL 처리, 트랜잭션 범위, N+1 쿼리
외부 연동 변경	타임아웃, 리트라이, 인증, fallback
설정 변경	application과 환경 변수 누락
성능	N+1 쿼리, 페이징, 대량 데이터 풀스캔

Tier 2: 프로젝트 도메인 특화 점검 (.local.claude/biz-rules.md 의 변경 영향 매핑 섹션 자동 활용):

biz-rules.md 에 변경 영향 매핑 표가 있으면 그 표의 변경 유형별 회귀 점검을 자동 추가.

자주 등장하는 변경 유형 예시 (프로젝트마다 다름):

• 격리 키(있는 프로젝트만) 변경: 데이터 격리 회귀
• 승인 모듈 변경: 모든 승인 흐름 회귀
• 상태 전이 변경: 영향 받는 모든 모듈 회귀
• 이벤트 발행 변경: 수신 모듈 연쇄 회귀
• 공통 코드 추가: 운영 DB 정합성 점검

CLAUDE.md "금지 사항" 위반 여부도 함께 점검 (있을 시).

경고 수준:

• [높음]: 장애 가능성, 데이터 정합성 위험, 전 모듈 영향
• [중간]: 특정 시나리오에서 문제 가능, 확인 권장
• [낮음]: 참고 수준, 코드 품질 관련

7. 코드 품질 메모

간략하게, 항목당 1~2문장:

• 리팩토링 기회
• 테스트 누락 (테스트 skip 프로젝트면 수동 검증 필요 사항)
• 컨벤션 이탈 (CLAUDE.md 금지 사항 위반 등)
• 중복 코드, 미사용 import, 불필요한 주석

8. 오늘의 체크포인트

위 분석을 바탕으로, 오늘 개발 시 확인하거나 주의할 구체적 행동 목록

출력 구조

## 아침 브리핑: YYYY-MM-DD

### 한눈에 보기
| 항목 | 내용 |
|------|------|
| 분석 기간 | YYYY-MM-DD ~ YYYY-MM-DD |
| 브랜치 | {브랜치명} |
| 총 커밋 | N개 |
| 주요 변경자 | ... |

> 핵심 요약 1~2문장

### 작업 요약
#### 기능 추가
...
#### 버그 수정
...
#### 리팩토링
...
#### 설정/인프라
...

### 연속 변경 추적
이전 브리핑이 없으면 "첫 브리핑 (이전 데이터 없음)".
#### 진행 중인 변경 흐름
...
#### 이전 주의사항 추적
...

### 비즈니스/도메인 영향
| 변경 | 영향받는 업무 | 사용자 관점 변화 | 영향도 |
|------|------------|----------------|--------|

### 변경 영향 범위
#### 백엔드 / 프론트엔드 / API 변경
...

### 주의가 필요한 부분
#### [높음] ...
#### [중간] ...

### 코드 품질 메모
...

### 오늘의 체크포인트
- [ ] ...

### 모듈 문서 업데이트 기록
| 모듈 문서 | 업데이트 섹션 | 변경 내용 |
|----------|-------------|----------|

업데이트 없으면: "해당 사항 없음 (모듈 문서 변경 불필요)"

팀 활동 현황 (기본 포함)

모든 브리핑에 팀원별 활동과 PR/리뷰 현황을 포함한다.

추가 정보 수집

# 팀원별 커밋 수 (기간 내)
git shortlog --since="3 days ago" -s -n

# 열린 PR 목록 (gh CLI 가용 시)
gh pr list --state open --json number,title,author,createdAt,reviewDecision,isDraft 2>/dev/null

# PR별 리뷰 상태
gh pr list --state open --json number,title,author,reviewRequests,reviews 2>/dev/null

• 팀원 매핑 파일 read 후 author를 닉네임으로 매핑
• .local.claude/people/{닉네임}.md 가 있으면 Read하여 담당 모듈/강점 참고

추가 출력 섹션

출력 구조의 "오늘의 체크포인트" 뒤에 포함:

### 팀 활동 현황

#### 팀원별 활동
| 팀원 | 커밋 수 | 주요 작업 | 변경 모듈 |
|------|---------|----------|----------|

활동 없는 팀원도 표기 (0건: 휴가/다른 업무 가능성).

#### PR/리뷰 현황 (gh 가용 시)
| PR | 작성자 | 생성일 | 리뷰 상태 | 대기 일수 |
|----|--------|--------|----------|----------|

**병목 신호**:
- [WARN] 리뷰 대기 2일 이상인 PR
- [WARN] 변경 없이 3일 이상 지난 PR (stale)
- [WARN] 같은 모듈을 여러 팀원이 동시 변경 (충돌 가능성)

#### 액션 아이템
위 분석 기반으로 해야 할 것 (구체적이고 실행 가능하게)

제약조건

• 활동량(커밋 수)으로 성과를 판단하지 않는다
• 사람에 대한 부정적 평가/판단을 넣지 않는다. 사실만 기술
• 액션 아이템은 구체적이고 실행 가능하게

모듈 문서 동기화 (해당 프로젝트에 modules/ 가 있을 때만)

브리핑 분석 완료 후, 변경 사항을 .local.claude/modules/{name}.md 에 자동 반영한다.

감지 기준

브리핑에서 이미 파악한 변경 파일 목록에서 아래 패턴을 감지:

감지 대상	파일 패턴 (프로젝트 컨벤션 따름)	업데이트할 모듈 문서 섹션
새 Service 클래스 추가/삭제	*Svc.java, *Service.{ext} 신규/삭제	서비스 카탈로그
새 데이터 접근 클래스 추가	Mapper, Repository, DAO 신규	DB 접근 인벤토리
새 Controller 클래스 추가	*Ctrl.{ext}, *Controller.{ext} 신규	컨트롤러 매핑
새 이벤트 Listener 추가	*Listener.{ext}, @EventListener 신규	이벤트 연동
새 외부 연동 추가	@FeignClient, HTTP 클라이언트 신규	외부 연동

모듈명과 문서 파일명의 매핑: 프로젝트의 패키지 구조에서 자동 추론. 명시 매핑이 필요하면 .local.claude/modules/_INDEX.md 같은 파일에 정의 (있을 시 read).

처리 흐름

1. 변경된 모듈 식별 (브리핑 분석에서 이미 파악됨)
2. 모듈명을 문서 파일명으로 매핑 (자동 또는 INDEX 참조)
3. .local.claude/modules/{name}.md 존재 확인
   - 문서 없으면: 스킵
   - 문서 있으면: 감지 기준 패턴 매칭. 매칭되면:
     1. 기존 문서 Read
     2. 해당 섹션만 targeted update (추가 위주)
     3. "마지막 분석" 날짜를 "{date} (briefing 자동 갱신)" 으로 갱신

업데이트 원칙

• 기존 문서가 없는 모듈은 건드리지 않는다
• 삭제보다 추가 위주: 새로 감지된 항목을 기존 테이블에 추가
• 변경 감지된 섹션만 수정
• 확실하지 않은 변경은 [briefing 감지 — 검증 필요] 태그

biz-rules 영향 감지

브리핑 분석에서 파악한 변경 중, .local.claude/biz-rules.md 에 영향을 줄 수 있는 패턴을 감지하여 안내. 자동 반영은 하지 않음. /biz-rules 스킬에서 코드 검증 후 반영.

감지 기준

biz-rules.md 의 상태 코드와 도메인 키워드를 read 한 뒤, diff 에서 다음 패턴을 감지:

감지 대상	diff 패턴
상태 코드 변경	biz-rules.md 의 상태 코드와 *Status setter 에 새 문자열 리터럴
이벤트 리스너 추가	@EventListener 신규 클래스
승인/검토 연동(있는 프로젝트만) 변경	승인 관련 클래스 (있을 시) 신규 또는 시그니처 변경
새 코드그룹 추가	코드 테이블 INSERT 또는 새 코드값

출력

감지된 항목이 있을 때만 브리핑 출력에 포함:

### biz-rules 영향 감지
| 변경 | 파일 | 영향 | 권고 |
|------|------|------|------|

감지 없으면 이 섹션 생략.

파일 저장

Frontmatter (CONTRACT 7-2절 표준): category: briefing, retention: 30d, harvest_targets: [biz-rules.md, modules/*.md]

저장 경로

• .local.claude/briefing/YYYY-MM-DD.md
• 디렉터리 없으면 mkdir -p

저장 시점

• 분석 완료 시 자동 저장
• 저장 후 파일 경로 안내

다음 스킬 연결

• 주의사항에서 버그 의심이 들면 /cs
• 변경과 충돌 가능한 내 작업은 /review
• 오늘 할 일 정리는 /daily-todos
• 컨벤션 이탈이 반복되면 /convention-audit

다른 스킬과의 경계

질문	담당	이 스킬에서
최근 커밋과 diff 기반 오늘의 변경, 영향, 주의사항 요약	이 스킬	핵심 (아침 브리핑 SSOT)
회의 메모를 구조화된 회의록으로 정리	/meeting-notes	다루지 않음 (회의 기록은 위임)
하루/주간 업무를 회고하고 종합 (성장 스냅샷)	/daily	다루지 않음 (회고는 위임)
단계별 리더십 주제와 매니징 조언	/leadership	다루지 않음 (리더십 코칭은 위임)

제약조건

• 커밋 메시지 + 실제 diff 함께 확인. 메시지만으로 충분하지 않음
• 발견된 것이 없는 섹션은 "해당 사항 없음" 표기. 억지로 채우지 않음
• 주의사항은 실제 diff 근거가 있을 때만 기재
• 변경자는 팀원 매핑 파일의 닉네임으로 표기. 매핑 안 되면 git author 그대로
• 다른 사람의 변경이 내 작업에 미치는 영향에 집중
• 분량은 핵심만. A4 1~2페이지 이내
• 프로젝트 컨텍스트 파일이 없으면 일반 git diff 분석만 수행. 도메인 해석을 강제하지 않음

검증 시나리오

공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.

이 스킬의 고유 실패 시나리오

[환경/규모] 변경 파일 100개 이상

• 신호: git diff --name-only {base}...HEAD | wc -l > 100
• 대응: 모듈별 요약 모드로 전환 + 개별 파일 상세 생략 + "큰 변경 묶음, 단위 분할 리뷰 권장" 경고

[데이터 결함] modules/*.md 미작성 또는 오래됨

• 신호: 변경된 모듈에 해당하는 modules/{name}.md 부재 또는 90일+ 경과
• 대응: 해당 모듈은 코드 직접 Grep 으로 fallback + [모듈 문서 갱신 권장] 태그 + /absorb 안내