# 지원 티켓 만들기
보고된 bug 또는 사용자 이슈에 대한 Linear 티켓을 만듭니다.

## 형식
- **제보자 정보:** 이메일, 계정 ID, 플랫폼, 앱 버전
- **요약:** 1~2문장으로 된 간단한 설명
- **예상 결과와 실제 결과:** 어떻게 되어야 하는지와 실제로 어떻게 되는지
- **재현 단계:** 번호가 매겨진 목록

## 참고
- 티켓을 만들기 전에 로그에서 사용자 정보를 수집합니다
- 가능하면 요청 ID 또는 trace ID를 포함합니다
- 관련 로그 쿼리 또는 대시보드 링크를 추가합니다
- 별도 지정이 없으면 기본 우선순위는 Medium으로 합니다

# 고객 답변 초안 작성
고객의 이슈에 대한 답변 초안을 작성합니다.

## 가이드라인
- 공개된 제품 이름만 사용합니다
- 내부 서비스 이름, 코드명 또는 인프라 정보는 피합니다
- 내부 오류 코드, 파일 경로 또는 환경 변수는 공유하지 않습니다
- 공개 문서에 나온 기능과 표준 문제 해결 단계만 사용합니다

## 확실하지 않을 때
다음과 같이 자문하세요. "고객이 일반적인 제품 사용 과정에서 이 정보를 알 수 있을까?"
그렇지 않다면, 일반적인 디버깅 방식으로 바꿔 표현합니다.

# 알려진 이슈 검색
이슈가 이미 알려진 것인지 확인하기 위해 Slack을 검색합니다.

## 워크플로우
1. 식별자(티켓 ID, 오류 코드, 정확한 오류 메시지)로 검색합니다
2. 채널과 시간 범위로 좁힙니다
3. 상태, 우회 방법 또는 담당자 정보가 있는 스레드를 찾습니다

## 출력
- **판정:** 알려짐 / 알려졌을 가능성 있음 / 찾지 못함
- **가장 적절한 스레드:** 퍼머링크 + 요약
- **다음 검색:** 결과가 부족할 경우 시도할 쿼리

# 로그 검색
지정된 요청, 사용자 또는 오류에 대해 Datadog 로그를 쿼리합니다.

## 일반적인 패턴
- @requestId:{id} — 특정 요청을 찾습니다
- @userId:{id} or @email:{email} — 사용자 활동을 찾습니다
- status:error — 오류만 필터링합니다
- service:{name} — 서비스별로 필터링합니다

## 참고
- 항상 시간 범위를 지정합니다(기본값: 최근 7일)
- 필드 이름은 소스에 따라 다르므로 여러 패턴을 시도합니다
- 넓게 시작한 다음 발견 사항을 바탕으로 범위를 좁혀 갑니다

# Skill: 고객 답변(안전하고 실행 가능)

## 필요한 입력
- 고객 증상(고객에게 보이는 현상)
- 확인한 내용(근거 기반 요약)
- 다음 단계/우회 방법(있는 경우)
- 요청이 필요한 누락 데이터 0~2개

## 출력 형식
- 짧은 안내 메시지
- 확인한 내용(내부 정보 제외)
- 다음에 시도할 사항(번호 매긴 단계)
- 필요한 경우: 질문 최대 2개(조사를 진행하는 데 필요한 내용)
- 우리 측의 다음 조치를 덧붙이며 마무리

## 가드레일
- 내부 구현 세부 정보와 내부 전문 용어는 피하기
- 추측보다 구체적인 단계를 우선하기
- 간결하게 유지하고 "처음으로 유용한 답변"에 최적화하기

# Skill: 품질 높은 버그 티켓 초안 작성

## 필요한 입력
- 증상(고객에게 보이는 현상)
- 시간 범위
- 관련 ID(request id, user/team id)
- 증거 스니펫(민감 정보 제거됨)

## 출력 형식
## 요약
## 예상 결과 vs 실제 결과
## 재현 단계
## 증거
## 범위/심각도
## 권장되는 다음 디버깅 단계

## 품질 기준
- 구체적인 조건 없이 모호한 표현("가끔", "작동하지 않음") 사용 금지
- title에 내부 전용 전문 용어 사용 금지
- 명시적으로 승인되지 않은 한 고객별 정보는 가리기

# Skill: 알려진 이슈 조사자(Slack + Notion)

## 필요한 입력
- 정확한 오류 문구(또는 가장 가까운 표현)
- 기능 영역 키워드
- 시간 범위(기본값: 최근 30일)

## 워크플로우
- 먼저 정확한 문구와 식별자로 Slack을 검색합니다.
- 결과가 충분하지 않으면 기능 키워드와 시간 필터로 범위를 넓힙니다.
- 동일한 기능 영역의 런북/FAQ를 Notion에서 검색합니다.

## 출력 형식
- 판단: 알려진 이슈 / 알려진 이슈일 가능성 있음 / 찾지 못함
- 가장 관련성 높은 thread: 링크 1~3개와 한 줄짜리 "관련 이유"
- 우회 방법 / 완화책(있는 경우)
- 다음 검색 구체화: 다음에 실행할 정확한 쿼리

supportInvestigationPack:
  goal: >
    Produce a grounded investigation summary, a draft bug ticket,
    and a customer reply by running specialized agents in parallel.
  inputs:
    - customer_symptom
    - time_window
    - identifiers:
        request_id: ""
        user_or_team_id: ""
        error_text: ""
    - investigation_notes
  agents:
    - name: LogInvestigator
      focus: "Datadog: identify the most likely failure point and supporting evidence."
      output:
        - suspected_root_cause
        - strongest_evidence
        - disconfirming_checks
        - open_questions
    - name: KnownIssueMiner
      focus: "Slack/Notion: find prior art, current status, and workaround."
      output:
        - verdict
        - best_links
        - workaround
        - next_search_query
    - name: TicketWriter
      focus: "Write an engineering-facing bug ticket from evidence + notes."
      output:
        - title
        - summary
        - expected_vs_actual
        - steps_to_repro
        - evidence
        - suggested_next_debug_step
    - name: CustomerReplyDrafter
      focus: "Draft a customer reply: clear, safe, and actionable."
      constraints:
        - "Do not include internal implementation details."
        - "Ask for at most two missing data points."
      output:
        - reply_text
        - questions_for_customer
  final_assembler:
    merges:
      - LogInvestigator
      - KnownIssueMiner
      - TicketWriter
      - CustomerReplyDrafter
    produces:
      - investigation_summary
      - ticket_draft
      - customer_reply