Files
santifer--career-ops/modes/ko/jiwon.md
T
wehub-resource-sync d083df1fdb
CodeQL Analysis / Analyze (javascript-typescript) (push) Failing after 2s
Web CI / web typecheck + build (push) Failing after 1s
Release Please / release-please (push) Failing after 1s
CodeQL Analysis / Analyze (go) (push) Failing after 16s
chore: import upstream snapshot with attribution
2026-07-13 12:02:43 +08:00

5.7 KiB

모드: jiwon -- 지원서 작성 live assistant

후보자가 Chrome에서 지원서 폼을 작성하는 순간 사용하는 interactive mode입니다. 화면에 보이는 내용을 읽고, 이전에 평가한 채용 공고의 context를 불러온 뒤, 폼의 각 질문에 맞는 개인화 답변을 생성합니다.

사전 조건

  • Visible Playwright가 가장 이상적: visible mode에서는 후보자가 브라우저를 직접 볼 수 있고, Claude가 페이지와 상호작용할 수 있습니다.
  • Playwright 없이 진행하는 경우: 후보자가 스크린샷을 공유하거나 질문을 직접 붙여넣습니다.

Workflow

1. DETECT      -> 활성 Chrome 탭 읽기 (스크린샷/URL/title)
2. IDENTIFY    -> 페이지에서 회사 + 역할 추출
3. SEARCH      -> reports/ 안의 기존 report와 매칭
4. LOAD        -> 전체 report + 블록 G(있다면) 읽기
5. COMPARE     -> 화면의 역할이 평가한 역할과 같은지 확인. 바뀌었다면 알림
6. ANALYZE     -> 화면에 보이는 모든 지원서 질문 식별
7. GENERATE    -> 각 질문에 대해 개인화 답변 생성
8. PRESENT     -> 복사/붙여넣기 가능한 형식으로 답변 표시

Step 1 -- 공고 감지

Playwright 사용 시: 활성 페이지 snapshot을 뜹니다. title, URL, 보이는 내용을 읽습니다.

Playwright 없이 진행 시: 후보자에게 다음 중 하나를 요청합니다.

  • 지원서 폼 스크린샷 공유 (Read tool이 이미지를 읽을 수 있음)
  • 또는 지원서 질문을 텍스트로 붙여넣기
  • 또는 회사 + 역할을 알려주면 context를 검색

Step 2 -- context 식별 및 불러오기

  1. 페이지에서 회사명과 역할명을 추출합니다.
  2. reports/에서 회사명으로 검색합니다 (case-insensitive grep).
  3. 매칭되는 report가 있으면 전체 report를 불러옵니다.
  4. 블록 G가 있으면 이전 답변 초안을 base로 불러옵니다.
  5. 매칭되는 report가 없으면 후보자에게 알리고 빠른 auto-pipeline 실행을 제안합니다.

Step 3 -- 역할 변경 감지

화면의 역할이 평가한 역할과 다르면:

  • 후보자에게 알림: "역할이 [X]에서 [Y]로 바뀐 것 같습니다. 새 역할로 다시 평가할까요, 아니면 새 title에 맞춰 답변만 조정할까요?"
  • 조정 선택 시: 재평가 없이 새 역할에 맞춰 답변을 조정합니다.
  • 재평가 선택 시: 전체 A-F 평가를 실행하고, report를 업데이트하고, 블록 G를 다시 생성합니다.
  • tracker 업데이트: 필요한 경우 applications.md의 역할명을 수정합니다.

Step 4 -- 지원서 질문 분석

화면에 보이는 모든 질문을 식별합니다.

  • 자유 입력 필드 (커버레터, "왜 이 역할인가요", 지원 동기 등)
  • 드롭다운 (어디서 공고를 봤는지, 근무 자격 등)
  • Yes/No 질문 (이직 가능 여부, 비자, 근무 가능 지역 등)
  • 연봉 입력 필드 (희망 연봉, range, 총보상 기대치)
  • 업로드 필드 (CV, 커버레터 PDF, 추천인 등)

각 질문을 분류합니다.

  • 이미 블록 G에서 답변한 질문 -> 기존 답변을 가져와 조정
  • 새 질문 -> report + cv.md를 바탕으로 답변 생성

Step 5 -- 답변 생성

각 질문에 대해 다음 구조로 답변을 만듭니다.

  1. Report context: 블록 B의 proof point와 블록 F의 STAR story 사용
  2. 이전 블록 G: 기존 초안이 있으면 base로 가져와 다듬기
  3. "제가 귀사를 선택합니다" 톤: auto-pipeline과 같은 framework 사용 -- 자신감 있게, 애원하지 않게
  4. 구체성: 화면에 보이는 공고 내용 중 구체적인 요소 언급
  5. career-ops proof point: "추가 정보" 같은 필드가 있으면 포함

한국 지원서 폼에서 자주 나오는 필드:

  • 희망 연봉 / 처우 -> profile.yml의 range를 사용. 세전 연봉 기준인지 명확히 쓰고, "전체 보상 패키지에 따라 협의 가능"이라고 덧붙임
  • 입사 가능일 -> 현재 재직/퇴사 통보 기간을 고려한 현실적인 날짜
  • 근무 가능 지역 / 출근 가능 여부 -> 실제 가능한 지역과 출근 빈도를 명확히 작성
  • 비자 / 근무 자격 -> 사실에 맞게 간결히 답변
  • 언어 능력 -> 실제 수준에 맞춰 작성. 필요하면 CEFR 또는 비즈니스/실무 가능 수준으로 표현
  • 포트폴리오 / GitHub / 블로그 -> profile.yml, cv.md, article-digest.md에 있는 검증된 링크만 사용

출력 형식:

## [회사] -- [역할] 지원서 답변

Base: Report #NNN | Score: X.X/5 | Archetype: [type]

---

### 1. [지원서의 정확한 질문]
> [바로 복사/붙여넣기 가능한 답변]

### 2. [다음 질문]
> [답변]

...

---

Notes:
- [역할 변경, 공고 관련 관찰 등]
- [후보자가 직접 확인해야 할 개인화 포인트]

Step 6 -- 지원 후 처리 (선택)

후보자가 지원서를 제출했다고 확인하면:

  1. tracker status 변경은 data/applications.md를 직접 수정하지 않습니다. batch/tracker-additions/Applied 상태의 TSV update를 쓰고 node merge-tracker.mjs로 병합합니다.
  2. 최종 답변을 report의 블록 G에 업데이트합니다.
  3. 다음 단계로 /career-ops contacto를 제안해 hiring manager 또는 recruiter에게 LinkedIn outreach를 할 수 있게 합니다.

스크롤 처리

지원서 폼에 화면에 보이는 것보다 질문이 더 많으면:

  • 후보자에게 아래로 스크롤한 뒤 다른 스크린샷을 공유해달라고 요청합니다.
  • 또는 남은 질문을 붙여넣어달라고 요청합니다.
  • 전체 폼을 다룰 때까지 반복해서 처리합니다.