s-skill-interview-to-ticket

name: s-skill-interview-to-ticket version: 1.1.0 description: | 인터뷰 피드백에서 SAL(Engineering) 팀 티켓 초안을 작성할 때 사용. "인터뷰 티켓", "피드백 티켓", "SAL 티켓 만들어" 등의 요청 시 자동 호출. allowed-tools: - Bash - Read - Write - AskUserQuestion - ToolSearch - mcp__claude_ai_Notion__notion-fetch - mcp__linear-server__linear_getIssueById

Interview to Ticket

고객 인터뷰 피드백을 세일즈맵 CRM 커스텀 오브젝트 티켓으로 생성한다.

입력

• $ARGUMENTS: 피드백이 담긴 소스 (URL, 텍스트 등 형식 무관)
• 입력이 없으면 사용자에게 요청한다.

작업 프로세스

1. 피드백 수집

입력 형식을 자동 판별하여 내용을 가져온다:

• Notion URL → notion-fetch로 페이지 내용을 가져온다.
• Linear URL → linear_getIssueById로 이슈 내용을 가져온다.
• 텍스트 → 그대로 사용한다.
• 추출 대상:
  • 고객사/담당자 (누구의 피드백인지)
  • 문제 상황 (무엇이 안 되는지, 불편한지)
  • 고객이 제안한 해결책 (있다면)
  • 인터뷰 날짜

2. 초안 작성

아래 양식으로 초안을 작성하여 사용자에게 보여준다:

**제목**: [{기능영역}] {핵심 문제 요약}

**1. 주관적 온도 (10점 척도)**
{사용자가 제공한 점수, 없으면 사용자에게 질문}

**2. 배경/문제 상황**
- {고객사} {담당자}님 인터뷰({날짜})에서 접수된 피드백
- {확인된 문제 상황 서술}
- {비교 대상이 있으면 언급 (예: 타 서비스에서는 되는데 세일즈맵에서는 안 됨)}

**3. 해결책 (있다면)**
- {구현 방식을 한정짓지 않는 열린 형태로 작성}
- {고객이 제안한 방식은 예시로만 포함}

제목 규칙

• 패턴: [기능영역] 핵심 문제 요약
• 해결책이 아닌 문제를 쓴다 (예: "표 형태 보기/내보내기 기능" X -> "표 형태로 볼 수 없음" O)
• 기능영역 예시: 이메일, 에디터, 파이프라인, 연락처, 대시보드 등
• 고객사명은 제목에 넣지 않음

해결책 작성 규칙

• 고객이 특정 해결책을 언급했더라도, 그것만이 답이 아닐 수 있음
• "예: ~" 형태로 예시를 나열하되 열린 형태로 작성
• 구현 방식을 한정짓지 않음

3. 검증 질문

초안을 보여준 뒤 다음을 확인한다:

• 문제 상황이 확인된 사실인지, 고객 제보 수준인지
• 주관적 온도가 적절한지 (빈도, 심각도 고려)
• 해결책 방향이 맞는지
• 제목의 기능영역이 맞는지

사용자 피드백을 반영하여 최종본을 확정한다.

4. CRM 티켓 생성

최종본 확정 후 세일즈맵 CRM에 커스텀 오브젝트 티켓을 생성한다.

4-1. 티켓 타입 확인

사용자가 명시하지 않으면 질문한다. 대부분의 경우 CRM 티켓이다.

4-2. API 인증

중요: 환경변수 $SALESMAP_API_TOKEN이 Bash 세션에서 로드되지 않을 수 있다. 실패 시 ~/.zshrc에서 토큰 값을 직접 읽어서 사용한다.

# 환경변수 먼저 시도, 실패 시 zshrc에서 추출
TOKEN=${SALESMAP_API_TOKEN:-$(grep SALESMAP_API_TOKEN ~/.zshrc | sed 's/.*"\(.*\)"/\1/')}

4-3. 커스텀 오브젝트 생성 — 검증된 필드 ID 매핑

중요: 필드 정의 API(GET /v2/field/custom-object)는 모든 커스텀 오브젝트의 필드를 섞어서 반환한다. 동일 이름 필드가 여러 개 나오므로 반드시 아래 검증된 필드 ID를 사용한다. 필드 정의 API를 호출하여 필드를 탐색하지 않는다.

CRM 티켓 필드 ID

SDR 티켓 필드 ID

SDR 티켓은 CRM 티켓과 필드 ID가 다르다. 아래는 추정이며, 첫 사용 시 필드 정의 API로 검증 필요.

SDR 티켓 필드 ID가 검증되면 이 표를 업데이트할 것.

기능 카테고리 옵션 (CRM 티켓 기준, SDR도 동일 옵션명)

노트, 검색, 다국어, 데이터 업로드, 데이터 필드 관리, 레이아웃, 목록/파이프라인, 마케팅 이메일, 문서, 미리보기, 미팅, 병합, 뷰(필터/정렬/컬럼), 사용자 관리, 상세 페이지, 상품/견적서, 시퀀스, 알림, 에디터, 연동, 워크플로우, 웹 폼, 이메일, 차트/대시보드, 커스텀 오브젝트, AI, UX/UI, API/웹훅, TODO/캘린더, 타임라인/히스토리, SMS/알림톡, 전체 선택, 권한, 기타, 그룹, 모바일

요청 형식

{
  "customObjectDefinitionId": "{definitionId}",
  "name": "[기능영역] 핵심 문제 요약",
  "fieldList": [
    {"id": "{대표필드ID}", "name": "{대표필드명}", "stringValue": "[기능영역] 핵심 문제 요약"},
    {"id": "{소스ID}", "name": "소스", "stringValueList": ["인터뷰"]},
    {"id": "{이슈유형ID}", "name": "이슈 유형", "stringValue": "Regular Track"},
    {"id": "{기능카테고리ID}", "name": "기능 카테고리", "stringValueList": ["목록/파이프라인"]}
  ]
}

핵심 규칙:

• fieldList에 대표 필드(티켓 이름)를 반드시 포함해야 한다. 누락 시 "대표 필드를 입력해 주세요" 오류 발생.
• name (최상위)과 대표 필드의 stringValue에 동일한 제목을 넣는다.
• multiSelect -> stringValueList (배열), singleSelect -> stringValue (문자열), user -> userValueId, date -> dateValue
• 필드 ID를 반드시 함께 전달한다. 이름만으로는 중복 필드 구분이 안 된다.

4-4. 요청사/요청자 연결

인터뷰 대상 고객사/담당자가 특정되면 티켓에 연결한다. 연결 가능하면 묻지 않고 바로 연결한다.

검색 API 스키마 (검증됨)

POST /v2/object/{targetType}/search

• targetType: people, organization, deal, lead
• 요청 바디:

{
  "filterGroupList": [
    {
      "filters": [
        {
          "fieldName": "이름",
          "operator": "CONTAINS",
          "value": "검색어"
        }
      ]
    }
  ]
}

• fieldName: 한글 필드명 사용 (예: "이름", "이메일")
• operator: 대문자 (예: EQ, CONTAINS, IN, EXISTS, NOT_EXISTS, LT, GTE 등)
• filterGroupList: 최대 3개 그룹, 그룹 간 OR
• filters: 그룹 내 최대 3개, 필터 간 AND
• 응답: ID와 name만 포함

연결 절차

1. 요청사 (회사) 검색 및 연결:
   • POST /v2/object/organization/search로 회사명 검색하여 UUID 확보
   • 티켓 수정 시 { "name": "요청사", "organizationValueIdList": ["<ORG_UUID>"] }로 설정
2. 요청자 (고객) 검색 및 연결:
   • POST /v2/object/people/search로 담당자명 검색하여 UUID 확보
   • 티켓 수정 시 { "name": "요청자", "peopleValueIdList": ["<PEOPLE_UUID>"] }로 설정
3. 검색 결과가 여러 건이면 사용자에게 확인
4. 티켓 수정은 POST /v2/custom-object/{id} (PATCH 아님)

4-5. 노트(메모)로 상세 내용 작성

생성된 티켓에 메모를 추가하여 상세 설명을 기록한다.

메모 포맷 (반드시 이 형식을 따른다):

1. 주관적 온도(10점 척도)
{N}
2. 배경/문제 상황
- {항목 1}
- {항목 2}
3. 해결책(있다면)
- {항목 1}
- {항목 2}

• 번호 + 제목 줄 -> 바로 아래에 값/내용
• 섹션 사이는 \n\n(빈 줄)으로 구분하되, CRM UI가 연속 줄바꿈을 무시하므로 실제 표시에서는 빈 줄 없이 붙어 보임 (API 한계)
• 2, 3번 섹션의 항목은 - bullet list로 작성
• 초안의 전체 내용(주관적 온도, 배경/문제 상황, 해결책)을 이 포맷으로 작성

POST https://salesmap.kr/api/v2/custom-object/{생성된 티켓 ID}
{
  "memo": "1. 주관적 온도(10점 척도)\n{N}\n\n2. 배경/문제 상황\n- {항목1}\n- {항목2}\n\n3. 해결책(있다면)\n- {항목1}\n- {항목2}"
}

4-6. 결과 확인

• 성공 시: 생성된 티켓 ID와 이름을 출력
• 실패 시: 에러 메시지를 보여주고 원인 분석 후 재시도 여부를 묻는다

주의사항

• 문제가 확인된 사실인지, 고객 제보인지 구분하여 서술 톤을 맞춘다
  • 확인됨: "이 차단됨", "이 불가함"
  • 미확인: "이 안 된다는 피드백 접수", "라고 함"
• 하나의 인터뷰에서 여러 피드백이 나올 수 있음. 티켓은 이슈별로 분리하여 각각 생성
• 주관적 온도를 사용자가 제공하지 않으면 반드시 질문 (임의로 채우지 않음)
• CRM API 호출 시 rate limit 준수 (0.1~0.15초 간격)
• 여러 티켓을 한번에 생성할 때는 하나씩 순차 생성하고, 각각 결과를 보고한다
• 필드 정의 API를 호출하여 필드를 탐색하지 않는다 — 위 검증된 필드 ID 표를 사용한다

$ARGUMENTS