Menu
전달과 실행 관점 진단. 일정 예측 가능성, WIP와 차단 요인, 작업 흐름, 재작업률, 자원과 역량 매칭에 집중. 사업, 제품, 기술 진단이 "무엇을, 왜" 라면 이 스킬은 "어떻게 흘러가고 있는가" 에 답한다.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | delivery-diagnosis |
| description | 전달과 실행 관점 진단. 일정 예측 가능성, WIP와 차단 요인, 작업 흐름, 재작업률, 자원과 역량 매칭에 집중. 사업, 제품, 기술 진단이 "무엇을, 왜" 라면 이 스킬은 "어떻게 흘러가고 있는가" 에 답한다. |
| when_to_use | 전달 진단, 일정 예측 가능성 점검, WIP와 차단 요인, 재작업률 확인. |
| disable-model-invocation | true |
| allowed-tools | Read, Write, Glob, Grep, Bash, WebSearch, AskUserQuestion, mcp__github__list_issues, mcp__github__list_pull_requests, mcp__github__search_issues |
일이 흘러가는가 를 본다. "약속한 것이 약속한 시기에 나오는가".
역할:
톤: 스크럼 마스터, DM, PM. 실무 호흡, 데이터 기반, 비난 금지. 사람이 아니라 시스템.
| 질문 | 담당 | 이 스킬에서 |
|---|---|---|
| "무엇을 만들까?" | /product-diagnosis | [FAIL] 다루지 않음 |
| "코드가 건강한가?" | /tech-diagnosis | [FAIL] 다루지 않음. 재작업률만 참조 |
| "돈이 충분한가?" | /business-diagnosis | [FAIL] 다루지 않음. 자원 배분 결과만 참조 |
| "왜 자꾸 일정이 밀리는가?" | /delivery-diagnosis | [OK] 핵심 |
| "WIP 가 너무 많은가?" | /delivery-diagnosis | [OK] 핵심 |
| "팀 어디에 차단이 쌓이는가?" | /delivery-diagnosis | [OK] 핵심 |
(근사 추정, 신뢰도 2/5) 표기| 소스 | 신뢰도 | 전달 관점에서의 가치 |
|---|---|---|
| issues/ (이슈 트래커) | 5/5 | 약속, 완료, 기한의 객관적 기록 |
| git log / PR | 5/5 | 실제 산출 시점, 리뷰 사이클 |
| daily-todos/ | 4/5 | 일일 작업 흐름, 차단 신호 |
| projects/*/ | 4/5 | 프로젝트별 진행 상태 |
| daily/ | 3/5 | 회고 (재작업과 차단 정성 신호) |
| briefing/ | 3/5 | 주간 변경 흐름 |
| meetings/ | 3/5 | 의사결정과 차단 해소 맥락 |
| memo/ | 2/5 | 비공식 관찰 (비난 금지 원칙 적용) |
| auto memory | 4/5 | 교정된 사실 |
| 데이터 | 경로 | 필수/선택 | 부재 시 동작 |
|---|---|---|---|
| 프로젝트 컨텍스트 | CLAUDE.md | 선택 | 일반 SW 가정으로 진행. 도메인 규칙 검증 생략, [프로젝트 규칙 미확인] 태그 |
| 봇 인덱스 | bot/INDEX.md 또는 .local.claude/ONBOARDING.md | 선택 | 디렉터리 Glob + Grep 으로 구조 추론 fallback |
| 인프라 정보 | .local.claude/INFRASTRUCTURE.md | 선택 | 배포와 CI/CD 관련 분석 영역 생략 + [인프라 데이터 부재] 안내 |
| 비즈니스 규칙 | .local.claude/biz-rules.md (4절 도메인 점검 카테고리) | 선택 | Tier 1(도메인 무관 일반 점검)만 수행 |
| 팀 정보 | .local.claude/team.md | 선택 | git author 그대로 표기, [담당자 미지정] 태그 |
| 모듈 상세 | .local.claude/modules/{name}.md | 선택 | 코드 Grep 직접 fallback, [코드 직접 확인] 태그 |
| 이전 진단 보고서 | .local.claude/reports/YYYY-MM-DD-*-diagnosis.md | 선택 | 초회 진단 모드로 진행 (변화/델타 분석 생략) |
| 일일 메모 | .local.claude/daily/ | 선택 | 선행 신호(WIP, 재작업) 포착 불가. 후행 지표(lead time, throughput)만 사용 |
| 회의록 | .local.claude/meetings/ | 선택 | 의사결정 맥락 부재. git log 패턴으로 추정 |
다음 파일이 존재하면 우선 read:
CLAUDE.md (자동 로드, 프로젝트 구조와 컨벤션)bot/INDEX.md 또는 .local.claude/INDEX.md.local.claude/team.md (팀 구성과 역량).local.claude/projects/*/ (진행 중 프로젝트)| 입력 | 모드 | 예상 소요 |
|---|---|---|
/delivery-diagnosis (기본) | 종합 진단: 6파트 전체 | ~25분+ |
flow 또는 흐름 | 워크플로우 심층: 파트 2만 | ~10분 |
blockers 또는 블로커 | 차단 분석: 파트 3만 | ~10분 |
predict 또는 예측 | 예측 가능성: 파트 1만 | ~10분 |
delta 또는 변화 | 델타: 이전 보고서 대비 변화만 | ~10분 |
quick | 요약: 2~3페이지 | ~10분 |
[1M 활용] 다음을 단일 메시지에서 병렬로 호출:
- Read:
.local.claude/team.md,.local.claude/projects/*/STATUS.md, 이전 /delivery-diagnosis + /business-diagnosis + /tech-diagnosis 보고서- Glob:
.local.claude/daily/*.md(최근 14),.local.claude/daily-todos/*.md(최근 14),.local.claude/briefing/*.md(최근 4),.local.claude/issues/*.md- Bash:
git log --since="30 days ago",git shortlog -sn,gh pr list --state merged --json number,createdAt,mergedAt,gh issue list --json number,createdAt,closedAt,labels, 차단 키워드 grep 전부 동시
1-1. 기존 보고서 확인
# 이전 /delivery-diagnosis
ls .local.claude/reports/ 2>/dev/null | grep -iE 'delivery-diagnosis' | sort | tail -3
# 인접 진단 (자원 맥락 참조)
ls .local.claude/reports/ 2>/dev/null | grep -iE '(business|tech)-diagnosis' | sort | tail -2
1-2. 전달 데이터 수집
# 활동 측정 (지난 30일 기준)
git log --since="30 days ago" --oneline | wc -l
git shortlog -sn --since="30 days ago"
# PR 사이클 (병합 vs 미병합)
gh pr list --state merged --limit 50 --json number,createdAt,mergedAt 2>/dev/null
gh pr list --state open --limit 50 --json number,createdAt,labels 2>/dev/null
# 이슈 흐름
gh issue list --state closed --limit 50 --json number,createdAt,closedAt 2>/dev/null
gh issue list --state open --limit 50 --json number,createdAt,labels,assignees 2>/dev/null
# 일일 작업 흐름
ls .local.claude/daily-todos/ 2>/dev/null | tail -14
ls .local.claude/daily/ 2>/dev/null | tail -14
[필수 Read]
.local.claude/team.md: 자원 매칭의 기준.local.claude/projects/*/STATUS.md (있으면): 프로젝트 상태[기간 내]
.local.claude/daily/ 최근 N건: 차단과 재작업 정성 신호.local.claude/daily-todos/ 최근 N건: 작업 흐름.local.claude/briefing/ 최근 4건: 주간 변경 패턴.local.claude/issues/: 약속 vs 완료 추적1-3. 메트릭 측정 (자동 산출)
| 메트릭 | 산식 | 데이터 소스 |
|---|---|---|
| Lead time (p50, p90) | PR createdAt 에서 mergedAt 까지 | gh pr list |
| Cycle time | 첫 커밋에서 merge 까지 | git log + PR |
| Throughput | 주당 PR merged 수 | gh pr list |
| WIP | 동시 open PR + 진행 중 issue | gh pr/issue list |
| 차단 신호 | "blocked", "stuck", "기다림" 키워드 | daily/, daily-todos/ Grep |
| 재작업률 | revert 및 핫픽스 PR / 전체 PR | PR title/label Grep |
| 추정 갭 | issue label 의 estimate vs 실제 종료 | gh issue list |
데이터 부족 시 (근사 추정, 신뢰도 2/5) 표기. 측정 불가 항목은 [측정 불가] 명시.
## 팩트 시트: 검증 요청
### 팀 (team.md 기준)
- 인원: N명, 활동 멤버: N명 (지난 30일 git author)
### 활동 (지난 30일)
- PR merged: N건 / open: N건
- Issue closed: N건 / open: N건
- 평균 Lead time: X시간 (p50) / Y시간 (p90)
### 핵심 가정 (검증 필요)
- [ ] 현재 진행 중 주요 프로젝트 N개
- [ ] 최근 일정 미준수 사례 (있으면)
- [ ] 가장 큰 차단 요인 1~2개
- [ ] [이전 보고서 미검증 항목]
**위 내용 중 틀린 것이 있으면 알려주세요.**
AskUserQuestion으로 검증 요청. 사용자 응답 후 교정 반영.
약속한 시점에 약속한 것이 나오는가
| 기간 | 약속 N건 | 정시 완료 | 지연 완료 | 미완료 | 준수율 |
|---|---|---|---|---|---|
| 지난 4주 | |||||
| 지난 12주 |
근거: issue label 의 due date / milestone, daily-todos 의 "오늘까지" 표기
| 작업 유형 | 추정 평균 | 실제 평균 | 갭 비율 | 패턴 |
|---|---|---|---|---|
| 신규 기능 | ||||
| 버그 수정 | ||||
| 리팩토링 |
오버런 비율 > 1.5 면 추정 방법 자체 점검 권고.
의사결정 포인트: 다음 사이클에서 일정 신뢰도 회복 핵심 1줄
작업이 흐르는가, 정체되는가
| 지표 | 현재 | 4주 전 | 추세 | 건전 기준 |
|---|---|---|---|---|
| Lead time p50 | <3일 (코드 변경) | |||
| Cycle time p50 | <2일 (코드 변경) | |||
| Throughput (주) | 안정 | |||
| WIP | 인원 × 1.5 이하 |
PR 라이프사이클 단계별 평균 시간:
| 단계 | 평균 시간 | 정체 신호 |
|---|---|---|
| 첫 커밋에서 PR open 까지 | ||
| PR open 에서 첫 리뷰까지 | (>24h 면 정체) | |
| 첫 리뷰에서 승인까지 | ||
| 승인에서 merge 까지 | (>4h 면 정체) |
| 멤버 | 동시 open PR | 진행 중 issue | WIP 합 | 한계 초과? |
|---|---|---|---|---|
| ... |
WIP 한계 초과 인원은 차단, 재작업, 번아웃 위험 시그널.
의사결정 포인트: 워크플로우에서 가장 급한 정체 구간 1줄
누가 무엇에 막혀 있는가
daily/, daily-todos/ 에서 blocked, stuck, 기다림, 요청 보냄, 응답 없음 키워드 grep:
| 차단 유형 | 빈도 | 평균 차단 시간 | 주요 원인 |
|---|---|---|---|
| 외부 응답 대기 | |||
| 의존 작업 미완 | |||
| 권한, 접근 부족 | |||
| 의사결정 보류 | |||
| 기술적 막힘 |
| 의존 대상 | 대기 중 건수 | 평균 대기 | 위험도 |
|---|---|---|---|
| ... |
같은 유형 차단이 N회 이상 반복되면 시스템 문제. 개선 후보:
의사결정 포인트: 가장 자주 발생하는 차단 1개 + 시스템 개선 방향
빨리 가다 부서지고 있는가, 너무 신중해 멈췄는가
| 지표 | 지난 4주 | 지난 12주 | 추세 |
|---|---|---|---|
| Hotfix PR / 전체 PR | |||
| Revert PR / 전체 PR | |||
| "fix:" 커밋 / 전체 커밋 | |||
| 같은 파일 재수정 (1주 내) |
재작업률 > 20% 면 품질 손실. 0% 에 가까우면 과도한 신중 또는 테스트 부족 가능성.
| 지표 | 현재 | 건전 기준 |
|---|---|---|
| 리뷰 의견/PR | 1~5개 | |
| Approve 즉시 비율 | 20~50% | |
| Self-merge 비율 | <10% |
상세 기술 부채 분석은 /tech-diagnosis. 여기선 전달 속도에 영향 주는 신호만.
의사결정 포인트: 품질-속도 균형에서 지금 어느 쪽으로 기울어야 하는지 1줄
일과 사람이 맞물려 있는가
| 멤버 | PR (4주) | Issue 담당 | WIP | 회고 신호 |
|---|---|---|---|---|
| ... |
회고 신호: daily/ 에서 "지친다", "오래 걸린다", "혼자 하고 있다" 등.
| 영역 | 필요 역량 | 가능 멤버 | 갭 |
|---|---|---|---|
| ... |
team.md 의 멤버 역량 + 진행 작업 매칭. 가능 멤버 1명뿐인 영역은 bus factor 위험.
의사결정 포인트: 자원 매칭에서 가장 급한 조정 1줄
"지금 무엇을 바꾸면 가장 큰 영향이 있는가"
PART 1~5 의 의사결정 포인트를 종합:
| # | 개선 항목 | 근거 (어느 PART) | 예상 효과 | 액션 |
|---|---|---|---|---|
| 1 | ||||
| 2 |
다음 보고서까지 추적할 메트릭:
Adversarial Review. 핵심 권고/판단 Top 1~2 각각에 대해:
반박 유효 시 본문 수정, 부분 반박 시 "단, {가능성}" 인라인 추가.
## 자기 검증 결과
1. **데이터 충실성**: 정량 메트릭 N개 / 정성 일화 N개
2. **인물 비난**: 0건 (사람 X, 시스템과 패턴 O)
3. **추정 표기**: 추정값에 모두 신뢰도(n/5) 부여
4. **다른 진단과 모순**: business / tech / product 진단과 충돌 없음
5. **실행 가능성**: 권고 1~2개가 다음 사이클에 실제 실행 가능한 크기
---
type: delivery-diagnosis
date: YYYY-MM-DD
mode: full | flow | blockers | predict | delta | quick
previous: YYYY-MM-DD
parts: 1,2,3,4,5,6
data-sources:
team: N명
prs-merged: N건 (30일)
issues-closed: N건 (30일)
daily: N건
daily-todos: N건
metrics:
lead-time-p50: Xh
wip-current: N
rework-rate: X%
---
# 전달과 실행 진단 보고서
> **기간**: YYYY-MM-DD ~ YYYY-MM-DD
> **관점**: 전달 책임 시각 / Delivery Manager
> **모드**: {모드}
> **참조**: business [날짜], tech [날짜] (없으면 생략)
## TL;DR (3줄)
- 현재 국면: [예측 가능성, 흐름, 차단 종합 1줄]
- 가장 급한 것: [1줄]
- 다음 액션: [1줄]
[PART 1~6]
[참조] business [날짜], tech [날짜], product [날짜]
.local.claude/reports/YYYY-MM-DD-delivery-diagnosis.md
/tech-diagnosis/business-diagnosis/product-diagnosis/coaching (1on1 준비)| 임계 | 동작 |
|---|---|
| ≤500줄 | 단일 보고서 유지 |
| >500줄 | PART 별 분리 권장 (6개 sub-doc) |
(근사 추정, 신뢰도 2/5) 표기공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.
[데이터 결함] daily/ 기록이 15일+ 공백
[도메인 특수성] 단일 배포 팀(역할 분리 없음)
지정 디렉터리의 문서를 심층 분석하여 지식을 추출하고, 기존 문서 갱신 + 신규 문서 생성으로 프로젝트 지식 베이스에 반영합니다.
기술 의사결정 기록 (Architecture Decision Record). 중요한 기술적 결정의 맥락, 대안, 근거를 구조화하여 기록합니다.
현재 디렉터리의 내용을 분석하여 어떤 목적의 폴더인지 파악
슬랙/메일/메신저로 받은 업무 요청 메시지를 분석하여 의도, 핵심 내용, 판단, 액션 플랜, 대응 가이드를 정리합니다.
비즈니스 규칙, 도메인 규칙, 상태 전이 규칙을 하나의 문서로 관리합니다. 변경 이력이 누적됩니다.
열린 질문, 문제 해결, 기술 의사결정, 아이디어 발산을 구조화합니다. 회의록이나 메모 파일 경로를 인자로 전달하거나 직접 질문하세요.