디브리프

디브리프은(는) 무엇을 하나요?

디브리프는 프로세스 자체를 개선하는 지속적인 메타 목표를 위한 도구입니다. 사람과 에이전트가 어떻게 함께 협력했는지 증거를 바탕으로 분석하고, 그 결과를 에이전트를 위한 교훈(지침, 스킬, 워크플로우, 훅), 사람을 위한 교훈(에이전트를 더 잘 이끄는 방법), 프로젝트 설정 변경 사항의 세 가지 형태로 출력합니다. 양방향으로 솔직하며 비판을 인위적으로 만들지 않습니다. 잘 진행된 세션은 짧은 보고서로 충분합니다.

MIT 라이선스의 두 스킬을 기반으로 구조와 규칙을 적용했습니다(감사 인사 전합니다): Wavez의 debrief(네 가지 검토 그룹, 모든 발견 사항은 특정 순간을 인용, 승인 없이 적용 불가)와 florianbuetow의 retrospective(보고서 이력 관리, 이전 권장 사항 확인 및 반복 문제 심각도 상향 조정, 각 발견 사항에 대한 근본 원인 및 제안). 코칭 섹션, 5-Why 습관 및 사용 스크립트는 이 스킬의 고유한 부분입니다.

입력

1. 대화 내용. 주요 출처: 도구 호출, 질문 및 질문 시점, 사용자의 수정 및 확인, 하위 에이전트 보고서, 오류 및 재시도. 세션이 압축(compaction)되었다면 보고서에 명시하고, 요약을 신뢰도가 낮은 증거로 취급하십시오. 볼 수 없는 부분에 대해 순간을 지어내지 마십시오.

2. 수치 데이터. 세션 사용량에 대한 번들 스크립트 실행: 턴 수, 도구 호출(이름별), 하위 에이전트 및 워크플로우(토큰 포함), 사용된 모델, 모델별 출력 토큰, 지속 시간, 압축 횟수. ~/.claude/projects/<프로젝트-슬러그>/ 아래의 세션 기록과 그 옆의 subagents/ 디렉토리를 읽습니다. 사용자가 다른 세션에 대해 물어볼 수 있습니다. 그때는 해당 세션 ID를 전달하십시오.

   python3 ${CLAUDE_PLUGIN_ROOT}/scripts/usage.py            # 현재 세션 (이 프로젝트의 가장 최근 기록)
   python3 ${CLAUDE_PLUGIN_ROOT}/scripts/usage.py <세션-id>
   

3. 프로젝트 기록. 지침 파일(CLAUDE.md, AGENTS.md), 프로젝트가 유지하는 백로그 및 결정 로그, 그리고 이 프로젝트에 대한 에이전트의 피드백 메모리(~/.claude/projects/<프로젝트-슬러그>/memory/). 이를 통해 반복된 실수를 인지할 수 있습니다.

4. 이전 디브리프. 보고서 디렉토리(아래 참조)의 최근 세 개 보고서. 각 권장 사항에 대해 조치되었는지, 반복되는지, 알 수 없는지 기록하고, 반복 문제는 심각도를 상향 조정합니다.

노력을 작업 기간에 맞추십시오: 짧고 깔끔한 세션은 빠르게 처리하고, 수주에 걸친 세션은 전체 분석과 큰 패턴에 대한 5-Why를 적용합니다.

검토 항목

다음 네 가지 그룹을 검토하십시오. 각 발견 사항에 대해 해당 순간(무엇이 언제 말해졌거나 행해졌는지), 왜 중요한지 인용하고, 프로세스 원인이나 원칙에 도달하거나 답이 프로젝트 통제 범위를 벗어날 때까지 "왜"를 반복하여 질문하십시오. 관찰과 처방은 분리하십시오: 관찰은 옳지만 제안된 수정이 틀릴 수 있습니다.

1. 효율성. 중복되거나 반복된 도구 호출, 스크립트나 스킬이 처리했어야 할 수동 로직, 추가 빌드 또는 테스트 주기, 배치로 처리할 수 있었던 작업, 놓치거나 효과를 본 하위 에이전트, 압축 후 재작업, 세션 종료와 함께 사라진 백그라운드 작업.
2. 협업. 너무 일찍, 너무 늦게, 또는 전혀 묻지 않은 질문; 준수되지 않은 상시 지침; 규칙이 의도된 곳에서 문자 그대로 받아들여진 예시; 장황함; 에이전트가 모호한 요청에 대해 어떤 해석을 선택했는지 말했는지 여부; 차단 질문이 실제로 차단되었는지 여부.
3. 정확성과 규율. 증거 없이做出的 주장; 늦게 발견된 제약 조건; 확인 없이 수행된 파괴적 또는 되돌릴 수 없는 작업; 간과된 프로젝트 규칙; "이 시나리오가 이것을 요구하는가"와 "무엇이 이것을 잡아냈을까" 질문을 건너뛴 경우.
4. 향후 전파. 메모리나 프로젝트 문서로 저장할 가치가 있는 선호 사항 및 결정; 스킬, 워크플로우, 훅, 상시 규칙 또는 백로그 항목이 될 제안; 작업 기간을 더 쉽게 만들었을 도구; 다음에 자동화할 수 있는 단계. 두 번의 수동 반복은 재사용 가능한 자산이 누락되었음을 의미합니다.

그런 다음 이 스킬을 개인화하는 두 부분:

• 사용자 코칭. 프롬프트를 작성하는 사람이 어떻게 더 효과적일 수 있었을까요? 그들의 어떤 행동이 가장 도움이 되었고(이름을 명시하여 반복되도록), 어떤 행동이 비용을 초래했습니까(모호한 범위, 예시의 누락된 레이블, 에이전트가 필요로 했으나 보류된 결정, 건너뛴 리뷰)? 동료가 슈퍼비전 그룹에서 말하듯 직접적이고, 구체적이며, 증거 기반으로, 아첨 없이, 순화하지 않고 작성하십시오.
• 모델과 노력. 수치 데이터를 기반으로: 모델과 노력 수준이 작업에 비례했습니까? 토큰이 어디에 사용되었습니까(메인 루프, 하위 에이전트, 워크플로우), 더 저렴한 모델이나 낮은 노력이 일부 작업에 충분했을까요? 높은 노력이 효과를 본 곳은 어디입니까?

보고서

보고서를 보고서 디렉토리에 작성하고 응답에 짧은 요약을 표시하십시오. 디렉토리는 현재 저장소에 docs/ 디렉토리가 있으면 docs/debriefs/이고, 그렇지 않으면 ~/.claude/debriefs/<프로젝트-슬러그>/입니다. 사용자가 다른 이름을 지정할 수 있습니다. 파일 이름은 YYYY-MM-DD.md이며, 동일한 날짜의 파일이 이미 있으면 -2 접미사를 붙입니다.

짧고 간결하게: 독자는 세션을 직접 경험한 사람이므로 보고서는 서술보다는 상기시키는 역할을 합니다. 미묘한 차이는 증거와 원인에 있으며, 그 주변의 문장에 있지 않습니다. 다음 템플릿을 사용하십시오:

# 디브리프 <날짜>: <작업 기간의 주제>

범위: <디브리프가 볼 수 있었던 내용, 압축 여부>. 이전 디브리프: <날짜 또는 없음>.

## 다섯 줄 요약
- <작업 기간이 달성한 것>
- <효과를 본 것>
- <비용이 들었던 것>
- <코칭 한 줄>
- <제안 수와 그중 가장 중요하지 않은 제안>

## 수치 데이터
<스크립트 결과: 지속 시간, 턴 수, 상위 도구 호출, 모델별 출력 토큰, 하위 에이전트, 압축 횟수>

## 잘된 점
- **<두 단어 레이블>.** <해당 순간> → <그로 인한 이점>.

## 비용이 든 점
- 🔴 / 🟡 / 🟢 **<레이블>.** <해당 순간, 한 줄>.
  원인: <'왜'를 반복한 후의 프로세스 원인>. <해결됨 또는 남은 문제>.

## <사용자>를 위한 코칭
계속할 것: <도움이 된 행동 목록, 한 줄로>.
1. **<습관>.** <증거>와 <대신 할 행동>, 한두 문장.

## 모델과 노력
<한 문단: 비례했는지 여부와 그를 말해주는 수치>

## 제안
| # | 제안 | 적용 대상 | 노력 | 결정 |
|---|---|---|---|---|
적용 대상: AGENTS.md 또는 CLAUDE.md 규칙, 메모리, 스킬, 워크플로우, 훅, 백로그, 공유 가이드, 채택할 도구.

## 이전 권장 사항
| 출처 | 권장 사항 | 상태 (조치됨 / 반복됨 / 알 수 없음) |

심각도: 🔴 실제 작업 비용이 발생하거나 손상 위험이 있었음; 🟡 시간이나 주의를 소모함; 🟢 작은 습관.

규칙

• 보고서만 작성합니다. 사용자가 제안을 승인하기 전까지는 지침 파일, 메모리 또는 백로그에 아무것도 기록하지 않습니다. 승인 후에는 정확히 그 하나만 적용합니다.
• 모든 발견 사항은 특정 순간을 인용합니다. 인용할 순간이 없으면 해당 발견 사항을 삭제합니다.
• 부풀리지 마십시오: 세 개의 실제 발견 사항이 열 개의 부풀려진 발견 사항보다 낫습니다. "이번 작업 기간은 잘 진행되었다"는 유효한 결과입니다.
• 코칭은 사용자의 이익을 위한 것이므로 솔직해야 합니다. 또한 기본적으로 비공개이므로 사용자가 공유를 요청하지 않은 내용은 외부에 유출하지 마십시오.
• 평이하고 실행 가능한 언어를 사용하십시오: 모든 항목은 세션에 참여하지 않은 사람이나 에이전트가 실행할 수 있도록 작성하십시오. 관행을 행동(누군가가 무엇을 하며 그것이 무엇을 달성하는지: "해결책이 아닌 결과를 명시하라")으로 명명하고, 세션에서 만든 별명("보류된 해결책", "회의론자", "눈대중")으로 지칭하지 마십시오. 약어가 인식에 도움이 된다면 정식 표현 뒤에 괄호 안에 넣으십시오. 테스트: 동료가 이 문장을 자신의 가이드에 복사하여 따를 수 있는가?
• 간결함: 굵은 글씨 레이블, 증거 한 줄, 원인 한 줄. 발견 사항에 문단이 필요하다면 두 개의 발견 사항이거나 아직 이해되지 않은 것입니다. 섹션당 한 화면을 목표로 하십시오.
• 교훈과 마찰 구분: 교훈은 다른 프로젝트의 다른 에이전트에게도 말해줄 수 있는 것입니다. 이 세션에만 적용되는 것은 마찰이며, 발견 사항에 포함시키고 상시 규칙 제안에는 포함시키지 마십시오.