구조화된 출력
모든 버그 리포트는 이 구조를 따라요.
- 제목 — 간결한 요약 (최대 8단어)
- 무슨 일이 일어나나 — 버그 동작에 대한 설명
- git 컨텍스트 — 현재 브랜치와 최근 변경
- 재현 단계 — 설명에서 추론하거나 플레이스홀더 단계로
- 예상 vs 실제 — 비교 형식
심각도 자동 감지
시스템은 설명에서 심각도를 추론해요.
| 심각도 | 트리거 단어 | 예시 |
|---|---|---|
| Critical | 크래시, 데이터 손실, 보안, 다운, 차단 | ”앱이 시작할 때 죽어요” |
| High | 고장, 실패, 안 돼요, 회귀 | ”로그인 폼 검증이 실패해요” |
| Medium | 잘못, 오작동, 예상과 다름, 느림 | ”API가 잘못된 데이터를 반환해요” |
| Low | 사소함, 외형, 오타, 정렬 | ”모바일에서 버튼 정렬이 어긋나요” |
git 연동
한 번의 Bash 호출로 다음을 가져와요.
- 현재 브랜치 이름
- 최근 변경 요약 (최근 커밋 몇 개)
- 버그 영역과 관련된 수정 파일
이 컨텍스트는 버그 리포트에 자동으로 포함돼요. 그래서 다음 개발자가 버그 근처에서 무엇이 바뀌었는지 볼 수 있어요.
/note-bug, 언제 쓸까
다음이 필요할 때 /note 대신 /note-bug를 쓰세요.
- 심각도 자동 태깅
- 리포트에 담기는 git 컨텍스트
- 구조화된 재현 단계 형식
- 한눈에 알아보기 좋은 핑크 색상 코딩