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. 티켓 타입 확인

타입	Definition ID
CRM 티켓	019abebf-887c-755f-b526-2567e2476fde
SDR 티켓	019e3dbe-f9e0-7000-80c2-001c51ebb091

사용자가 명시하지 않으면 질문한다. 대부분의 경우 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

필드명	필드 ID	타입	비고
티켓(CRM) 이름	35f19e7e-039f-40d1-912e-da8b93a329ef	string	대표 필드 — 반드시 포함
소스	d1ae8285-8b1b-4494-a89d-f1f113af04a0	multiSelect	옵션: VOC, 인터뷰, 정량 지표, 기타
이슈 유형	815c9050-3d43-4261-a3d3-225e5dc7ee1c	singleSelect	옵션: Regular Track, Fast Track, Quick Win Track
기능 카테고리	bd9561e3-fab6-4fe6-b610-798d9542d11a	multiSelect	아래 옵션 목록 참조
제보 일자	1930963f-eaf5-4d29-a2a8-9676187665e6	date	미검증 — 실패 시 스킵
담당자	미확정	user	미검증 — 실패 시 스킵
요청사	6cf84776-146a-4b9e-bd1e-2e9f2dcbc5e9	multiOrganization	검증됨 — organizationValueIdList 사용
요청자	e59cd00d-17d2-4e68-bb1b-3a90f3c1e86e	multiPeople	검증됨 — peopleValueIdList 사용

SDR 티켓 필드 ID

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

필드명	필드 ID	타입	비고
티켓(SDR) 이름	019e3dbe-f9f3-7000-80c2-09141ab99ffe	string	대표 필드 — 반드시 포함
소스	ad7b5383-af11-46f5-a313-33e5b920a3e1	multiSelect	추정 — 첫 사용 시 검증
이슈 유형	6f89d747-5ea5-4c5d-abbf-d966d4de7aae	singleSelect	추정 — 첫 사용 시 검증
기능 카테고리	13a23b63-f036-4656-8893-cafafe961b9b	multiSelect	추정 — 첫 사용 시 검증

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