Varnan-Tech/opendirectory

LinkedIn 구인 공고 → 바이어 페인 맵(Buyer Pain Map)

LinkedIn 구인 공고를 분석하여 점수, 페인(pain), 아웃리치 접근법이 포함된 구조화된 바이어 페인 맵으로 변환합니다.

---

중요 규칙: 추론된 모든 페인(pain)은 구인 공고에 나온 구체적인 표현을 인용해야 합니다. 본문에 근거하지 않은 페인을 절대 만들어내지 마십시오. 만약 구인 공고가 너무 일반적이어서 페인을 추론할 수 없다면, 명시적으로 그렇게 말하고 신호 강도 점수를 낮게 할당하십시오.

윤리 규칙: 후보자에 대한 개인적 특성이나 보호받는 속성을 추론하지 마십시오. 회사 수준의 운영상의 어려움과 조직적 니즈에만 집중하십시오.

---

1단계: 설정 확인

필수 환경 변수 확인:

echo "GEMINI_API_KEY: ${GEMINI_API_KEY:+set}"

GEMINI_API_KEY가 없는 경우: 중단. 사용자에게 말합니다: "GEMINI_API_KEY가 필요합니다. aistudio.google.com에서 받으세요. .env 파일에 추가하세요."

---

2단계: 입력 수집

스킬에는 3개의 필수 입력이 필요합니다. 진행하기 전에 수집하십시오.

2a: 제품 브리프(Product Brief)

질문: "제품을 2~5문장으로 설명해 주세요. 무엇을 하고, 핵심 가치 제안은 무엇이며, 누구를 대상으로 합니까?"

사용자가 이미 프롬프트에 포함시킨 경우: 추출합니다. 확인: "제품 브리프 확인: [요약]."

2b: ICP 설명

질문: "이상적 고객 프로필(ICP)을 2~6개의 불릿 포인트로 설명해 주세요: 산업, 회사 규모, 판매 대상 역할, 기술 스택 힌트."

사용자가 이미 프롬프트에 포함시킨 경우: 추출합니다. 확인: "ICP 확인: [요약]."

2c: 채용 공고

질문: "분석할 구인 공고를 붙여넣어 주세요. 각 공고에 회사 이름, 직무 제목, 전체 설명 텍스트를 포함해 주세요. 1~15개 공고를 붙여넣을 수 있습니다."

허용 형식:

• 회사 이름과 직무 제목이 명확히 표시된 원시 텍스트
• 필드가 포함된 구조화된 JSON 객체: company_name, job_title, location(선택), seniority(선택), team_or_function(선택), job_description_text, job_url(선택)
• 명확한 구분자(--- 또는 번호)로 분리된 여러 개의 공고

필드가 누락된 경우: 설명 텍스트에서 추론할 수 있는 것은 추론합니다. company_name 또는 job_description_text가 누락된 경우, 진행하기 전에 물어보십시오.

2d: 선택적 입력

사용자가 다음 중 하나를 제공하면 캡처합니다:

• account_notes: 회사별 추가 컨텍스트 (자금 조달, 기술 스택, 알려진 도구, 연락처)
• focus_dimension: "pipeline" (점수 산정 및 우선순위 지정에 편향), "positioning" (메시징 접근법에 편향), 또는 "both" (기본값)

---

3단계: 신호 추출

각 구인 공고에 대해 파싱 및 추출:

1. 팀 / 기능: 이 역할은 어떤 팀에 속합니까? (GTM, Product, Infra, Data, RevOps, CS, Engineering 등)
2. 직급: IC, Senior IC, Manager, Director, VP, C-level
3. 책임 강조점: 주요 모드 분류:
   • 불안정 해소: "안정화", "수정", "다운타임 감소", "차단 해제"
   • 새로운 구축: "처음부터 구축", "0→1", "그린필드", "설계 및 구현"
   • 최적화: "확장", "최적화", "효율성 개선", "자동화"
   • 대체: "레거시 대체", "에서 마이그레이션", "현대화"
4. 요구 언어: 의도를 나타내는 키워드 확인: "첫 번째 X 채용", "중요 역할", "즉시", "필수"
5. 도구 / 스택 힌트: 사용자의 제품 영역과 겹치는 특정 도구, 플랫폼 또는 기술 범주에 대한 참조

회사별로 그룹화. 동일한 회사에서 여러 공고가 오는 경우 신호를 함께 그룹화합니다.

명시: "X개 회사의 Y개 공고에서 신호를 추출했습니다."

---

4단계: LLM으로 점수 산정

전체 점수 산정 모델은 references/scoring-rubric.md를 참조하십시오.

LLM 요청 구성:

cat > /tmp/pain-map-score-request.json << 'ENDJSON'
{
  "system_instruction": {
    "parts": [{
      "text": "You are a GTM analyst who specializes in decoding hiring signals into buyer intent. For each account provided, you will score three dimensions and infer company context. Rules: (1) Every score must include a one-sentence plain-text explanation. (2) signal_strength measures how many and how specific the hiring signals are relative to the user's product area. (3) urgency measures how time-sensitive the hiring need appears. (4) icp_fit measures how closely the company matches the user's ICP description. (5) Each score is 1-10. (6) overall_score = round((0.4 * signal_strength + 0.3 * urgency + 0.3 * icp_fit) * 10). (7) Infer buy_vs_build from job language. Use EXACTLY one of these labels: 'Leaning build', 'Leaning buy', 'Hybrid (buy-and-build)', 'Unknown'. (8) Infer stage_guess from company clues: funding stage, employee count, company type. (9) Output valid JSON only."
    }]
  },
  "contents": [{
    "parts": [{
      "text": "SCORING_CONTEXT_HERE"
    }]
  }],
  "generationConfig": {
    "temperature": 0.2,
    "maxOutputTokens": 4096
  }
}
ENDJSON
curl -s -X POST \
  "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d @/tmp/pain-map-score-request.json \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['candidates'][0]['content']['parts'][0]['text'])"

SCORING_CONTEXT_HERE를 다음으로 대체:

• 2단계의 제품 브리프 및 ICP 설명
• 3단계의 회사별 추출된 신호
• references/scoring-rubric.md의 점수 산정 루브릭 규칙
• 다음을 포함한 JSON 출력 지침: company_name, headline, overall_score, score_breakdown (signal_strength, urgency, icp_fit — 각각 점수 및 설명 포함), stage_guess, buy_vs_build_guess

---

5단계: 페인 맵 구축

각 계정에 대해 추출된 신호와 LLM 점수 산정 컨텍스트를 사용하여 바이어 페인 맵을 구축합니다.

cat > /tmp/pain-map-analysis-request.json << 'ENDJSON'
{
  "system_instruction": {
    "parts": [{
      "text": "You are a B2B pain analyst who reads job descriptions and identifies the operational pains a company is experiencing. Rules: (1) Every pain must have a short label, a 1-3 sentence description, and specific phrases quoted from the job post as supporting evidence. (2) Classify pains as primary (directly relevant to the user's product) or secondary (real pain but tangential to the product). (3) If a post is too generic to infer specific pain, state that explicitly — do not hallucinate. (4) For each account, also generate 1-3 recommended outreach angles. Each angle has: angle_name (short), narrative (1-2 sentences on how to lead), and talk_track_bullets (2-4 concrete talking points). (5) Outreach angles must reference specific pains and evidence, not generic value props. No banned words: synergy, leverage, innovative, cutting-edge, best-in-class, world-class, game-changing, disruptive, seamless, robust, comprehensive, revolutionize, transform, streamline. (6) Output valid JSON only."
    }]
  },
  "contents": [{
    "parts": [{
      "text": "ANALYSIS_CONTEXT_HERE"
    }]
  }],
  "generationConfig": {
    "temperature": 0.4,
    "maxOutputTokens": 8192
  }
}
ENDJSON
curl -s -X POST \
  "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d @/tmp/pain-map-analysis-request.json \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['candidates'][0]['content']['parts'][0]['text'])"

ANALYSIS_CONTEXT_HERE를 다음으로 대체:

• 제품 브리프 및 ICP 설명
• 각 회사의 구인 공고 (전체 텍스트)
• 4단계의 점수 및 컨텍스트
• 제공된 경우 계정 노트
• focus_dimension 선호도 (pipeline / positioning / both)
• 계정별 출력 지침: buyer_pain_map (primary_pains, secondary_pains) 및 recommended_outreach_angles

예상 출력 품질 및 깊이를 보정하려면 references/examples.md를 읽으십시오.

---

6단계: 핸드오프 객체 구축

각 계정에 대해 outreach-sequence-builder가 직접 사용할 수 있는 구조화된 핸드오프 블록을 생성합니다:

handoff:
  for_outreach_sequence_builder:
    account_summary: 2-3문장으로 회사 상황 및 채용 컨텍스트 요약
    key_pain: 가장 실행 가능한 단일 페인을 한 문장으로
    suggested_personas: 이 페인을 가장 많이 소유할 사람들의 2-4개 직무 제목
    tone: 권장되는 아웃리치 톤을 설명하는 한 문장

핸드오프는 누군가가 outreach-sequence-builder의 프롬프트에 붙여넣어 계정을 다시 조사하지 않고도 사용 가능한 시퀀스를 얻을 수 있을 정도로 구체적이어야 합니다.

---

7단계: 자체 QA

제시하기 전에 모든 검사를 실행하고 위반 사항을 수정하십시오:

• 추론된 모든 페인(pain)은 구인 공고의 최소 한 개의 특정 구문을 인용합니다.
• 일반적이거나 신호가 약한 공고(신호 강도 ≤ 3인 공고 확인)에 대해 페인이 만들어지지 않았습니다.
• 세 가지 점수(signal_strength, urgency, icp_fit) 모두 한 문장의 설명이 있습니다.
• 전체 점수가 공식 round((0.4 × signal + 0.3 × urgency + 0.3 × icp_fit) × 10)과 일치합니다.
• 구매 vs 자체 개발 레이블이 다음 중 하나입니다: "Leaning build", "Leaning buy", "Hybrid (buy-and-build)", "Unknown"
• 아웃리치 접근법에 금지된 단어가 없습니다: synergy, leverage, innovative, cutting-edge, best-in-class, world-class, game-changing, disruptive, seamless, robust, comprehensive, revolutionize, transform, streamline
• 각 아웃리치 접근법에는 2-4개의 토크 트랙 불릿이 있으며, 일반적인 가치 진술이 아닙니다.
• ICP 범위를 벗어난 계정은 우선순위를 낮추라는 명확한 권장 사항과 함께 플래그가 지정됩니다.
• 핸드오프 객체는 4개 필드(account_summary, key_pain, suggested_personas, tone) 모두가 완전합니다.
• 후보자에 대한 개인적 속성이나 보호받는 특성이 추론되지 않았습니다.
• 동일한 회사의 여러 공고는 회사별로 그룹화됩니다.

제시하기 전에 모든 위반 사항을 수정하십시오.

---

8단계: 출력 및 저장

사람이 읽을 수 있는 출력

전체 분석을 다음 형식으로 제시합니다:

## Buyer Pain Map — [YYYY-MM-DD]

**Product:** [브리프의 제품 이름]
**Posts analyzed:** Y개 회사의 X개 공고
**Focus:** [pipeline / positioning / both]

---

### [회사 이름] — Score: [N]/100

**Headline:** [채용이 무엇을 드러내는지 한 줄 요약]

| Dimension | Score | Explanation |
|-----------|-------|-------------|
| Signal Strength | N/10 | [한 문장] |
| Urgency | N/10 | [한 문장] |
| ICP Fit | N/10 | [한 문장] |

**Stage:** [단계 추측] | **Buy-vs-Build:** [포스처 레이블]

#### Primary Pains
- **[Pain label]:** [1-3문장 설명]
  - Evidence: "[구인 공고에서 인용된 구문]"

#### Secondary Pains
- **[Pain label]:** [1-3문장 설명]
  - Evidence: "[구인 공고에서 인용된 구문]"

#### Recommended Outreach Angles
1. **[Angle name]:** [내러티브]
   - [불릿 1]
   - [불릿 2]
   - [불릿 3]

#### Handoff → outreach-sequence-builder
> **Summary:** [2-3문장]
> **Key pain:** [한 문장]
> **Suggested personas:** [목록]
> **Tone:** [한 문장]

---

[각 회사에 대해 반복, overall_score 기준 내림차순 정렬]

파일로 저장

mkdir -p docs/pain-maps
OUTFILE="docs/pain-maps/$(date +%Y-%m-%d).md"
cat > "$OUTFILE" << 'EOF'
REPORT_CONTENT_HERE
EOF
echo "Pain map saved to $OUTFILE"

여러 회사가 분석된 경우, 슬러그화된 회사 이름(소문자, 공백 및 특수 문자를 하이픈으로 대체, 후행 하이픈 제거)을 사용하여 개별 파일도 저장합니다:

e.g., "ACME, Inc." → acme-inc.md, "CoolStartup Inc" → coolstartup-inc.md

SLUG=$(echo "COMPANY_NAME" | tr '[:upper:]' '[:lower:]' | sed 's/[^a-z0-9]/-/g' | sed 's/--*/-/g' | sed 's/-$//')
cat > "docs/pain-maps/${SLUG}.md" << 'EOF'
INDIVIDUAL_ACCOUNT_CONTENT_HERE
EOF

---

사용 시기

• 1~15개의 붙여넣은 구인 공고가 있고 각 회사가 느끼는 페인이 무엇인지 알고 싶을 때
• 계정 기반 아웃리치를 계획 중이고 시퀀스를 작성하기 전에 구조화된 페인 분석이 필요할 때
• 어떤 채용 신호 계정을 먼저 추구할지 우선순위를 지정하려고 할 때
• PMM이 포지셔닝을 개선하기 위해 구인 공고에서 실제 페인 언어를 원할 때

사용하지 말아야 할 시기

• 채용 중인 회사를 찾아야 할 때 (대신 linkedin-hiring-intent-scanner 또는 yc-intent-radar-skill 사용)
• 아웃리치 메시지를 작성해야 할 때 (대신 outreach-sequence-builder 사용 — 이 스킬의 핸드오프를 입력으로 제공)
• 시간이 지남에 따라 플랫폼을 모니터링하고 싶을 때 (대신 reddit-icp-monitor 또는 twitter-GTM-find-skill 사용)
• 연락처 정보나 이메일 보강이 필요할 때 (이 스킬은 이를 제공하지 않음)

함께 사용하기 좋은 스킬

• outreach-sequence-builder: 시퀀스를 구축할 때 handoff.for_outreach_sequence_builder 블록을 컨텍스트로 직접 전달하십시오.
• noise-to-linkedin-carousel: 기본 페인과 증거 인용문을 바이어 문제에 대한 캐러셀의 소스 자료로 사용하십시오.
• reddit-icp-monitor: 구인 공고의 페인 테마를 Reddit 토론에서 나타나는 페인 테마와 교차 참조하십시오.