flex-team/oncall-summarize

온콜 슬랙 요약 (Summarize)

역할

조사 결과(또는 직접 입력)를 받아 슬랙 공유용 한글 메시지를 생성하는 출력 스킬. 이슈 접수/분류는 /oncall-triage, 코드 조사는 /oncall-investigate의 역할이다.

Input

$ARGUMENTS — /oncall-investigate의 Output, /oncall-triage의 Output, 또는 직접 입력. 아래 정보가 필요하다:

| 필드 | 필수 | 예시 | |------|------|------| | 티켓번호 | O | CI-4500 | | 이슈 제목 | O | "영수증 500건 이상 조회 안 됨" | | 원인 분류 | O | FE 이슈, BE 이슈, 스펙 이슈, Won't fix, Not a bug | | 원인 설명 | O | "DEFAULT_PAGE_SIZE = 500 하드코딩" | | 관련 파일 | △ | src/query/receipt/getReceiptsQueryOptions.ts:12 | | 재현 경로 | △ | 단계별 재현 방법 |

• 대화 컨텍스트에 investigate 결과가 있으면 그대로 사용한다.
• 직접 호출 시 위 필드를 제공하면 된다. 원인 분류가 없으면 어떤 포맷이 필요한지 물어본다.

Output

원인 분류에 맞는 슬랙 메시지 (아래 포맷 중 하나). 메시지 생성 후 slack_send_message_draft 도구로 슬랙 초안을 자동 생성한다. 사용자는 슬랙 Drafts에서 확인·수정 후 전송하면 된다.

슬랙 초안 전송 절차

1. 아래 포맷에 맞춰 메시지 내용을 먼저 생성한다.
2. triage 결과에 슬랙 스레드 정보(channel_id, thread_ts)가 있으면 해당 스레드에 답장 초안으로 생성한다. 채널/스레드 확인을 사용자에게 다시 묻지 않는다.
3. 슬랙 스레드 정보가 없으면, 사용자에게 전송할 채널을 확인한다 (예: "어느 채널에 초안을 생성할까요?"). 이전 대화에서 채널이 이미 특정된 경우 재확인 없이 진행한다.
4. 채널명만 알고 있으면 slack_search_channels를 호출하여 channel_id를 조회한다.
5. slack_send_message_draft로 초안을 생성한다. thread_ts가 있으면 함께 전달하여 스레드 답장으로 생성한다.
6. 생성된 초안 링크를 사용자에게 공유한다.

포맷 선택 가이드

| 원인 분류 | 사용 포맷 | |-----------|-----------| | FE 이슈 (원인 파악됨) | FE 분석 결과 포맷 | | BE 이슈 (opensearch/코드만 확인) | BE 확인 요청 포맷 | | BE 이슈 (FE↔BE 교차 조사 완료) | BE 제보 포맷 | | 스펙 이슈 / Not a bug | 스펙 이슈 포맷 | | Won't fix (구조적 한계) | Won't fix 포맷 |

포맷 1: FE 분석 결과

**[티켓번호] 이슈 제목 — 원인 분석**

**요약**
(1-2문장으로 핵심 원인 설명)

**원인**
(구체적 원인 설명, 코드 참조 포함)

**재현 경로**
1. (단계별 재현 방법 — 누구나 따라할 수 있을 정도로 상세하게)
2. ...

**관련 파일**
- `파일 경로:라인번호` — 역할 설명

포맷 2: BE 확인 요청

**[티켓번호] 이슈 제목 — BE 확인 요청**

(이슈 설명 1-2문장)

**추정 원인**
(FE에서 추적한 원인 — 어떤 API에서 어떤 데이터가 기대와 다른지 구체적으로)

**확인 부탁드리는 부분**
(어떤 API/로직을 확인해야 하는지 구체적으로)

**재현 경로**
1. ...

포맷 3: BE 제보 (FE↔BE 교차 조사 완료)

FE에서 교차 조사를 완료한 후, BE 개발자가 바로 작업에 착수할 수 있도록 정리한다. 기존 "BE 확인 요청"보다 구체적인 포맷으로, FE 정상 확인 근거와 BE 의심 지점을 함께 제공한다.

**[티켓번호] 이슈 제목 — BE 확인 요청 (FE 교차 조사 완료)**

**요약**
(1-2문장: FE에서 확인한 결과 + BE 의심 지점)

**FE 확인 결과**
- 호출 API: `{method} {endpoint}`
- 요청 파라미터: {주요 파라미터}
- FE 코드: 정상 확인됨 (파서, 폼 바인딩, 렌더링 모두 정상)
- 문제 지점: API 응답의 `{필드명}`이 {기대값}이어야 하나 {실제값}으로 내려옴

**BE 의심 지점**
- 관련 API: `{endpoint}` → `{Controller}` → `{Service}`
- 의심 로직: `{파일경로:라인}` — {왜 의심하는지 한 줄}
- 로그 확인 결과: {opensearch에서 확인한 내용 — 에러 로그, 응답 시간 등}
- (있으면) 관련 DB 상태: {테이블.컬럼 = 값}

**재현 경로**
1. ...

**관련 파일**
- FE: `{파일경로:라인}` — {역할 — 정상 확인됨}
- BE: `{파일경로:라인}` — {역할 — 의심 지점}

포맷 4: 스펙 이슈 / Not a bug

**[티켓번호] 이슈 제목 — 확인 결과**

**요약**
(1-2문장: 버그가 아닌 이유 또는 이미 해결된 경위)

**확인 내용**
(현재 동작이 의도된 스펙인 근거, 또는 기존 수정 이력)

**추가 확인 사항**
(개선이 필요한지, CS 안내 방향 등)

포맷 5: Won't fix (구조적 한계)

**[티켓번호] 이슈 제목 — 확인 결과 (Won't fix)**

**요약**
(원인 1-2문장 + 당장 수정이 어려운 이유)

**원인**
(어떤 API/로직이 문제이고, 왜 수정 비용이 큰지)

**현재 동작**
(현재 어떻게 동작하는지 사실 기반으로 설명)

**권고**
(CS 안내 방향 + 개선이 필요하면 VoC/별도 티켓으로 전환 권고)

주의사항

• 추측과 확인된 사실을 명확히 구분하여 "추정 원인"이라고 명시한다.
• 재현 경로는 누구나 따라할 수 있을 정도로 상세하게 작성한다.
• BE 확인 요청 시, BE 개발자가 어떤 API/로직을 확인해야 하는지 구체적으로 명시한다.
• 코드 참조 시 파일 경로와 라인 번호를 포함한다.