#!/bin/sh
# Claude Code Skill 설치 스크립트
# 생성: 2026-08-13 · Skill 1개 · 파일 1개
#
#   ./install-skills.sh            ~/.claude/skills/ 에 설치 (모든 프로젝트에서 사용)
#   ./install-skills.sh ./myrepo   ./myrepo/.claude/skills/ 에 설치 (그 저장소 전용)
set -e

DEST="${1:+$1/.claude/skills}"
DEST="${DEST:-$HOME/.claude/skills}"
mkdir -p "$DEST"
echo "설치 위치: $DEST"


mkdir -p "$DEST/corresponding-author-verify"
cat > "$DEST/corresponding-author-verify/SKILL.md" <<'SKILL_PAYLOAD_EOF'
---
name: corresponding-author-verify
description: 논문의 교신저자를 실제로 확정한다. PubMed·KoreaMed 메타데이터에는 교신저자 필드가 없고 '마지막 저자' 추정은 실측 39.7%만 맞는다. 소속란 이메일 local part, PMC 전문, 원문 PDF 1면 세 경로로 판정하고 대조군으로 추출기 자체를 검증한다. TRIGGER - "교신저자", "corresponding author", "제1저자·교신저자 판정", "저자 역할", 마지막 저자를 교신저자로 가정해도 되는지 확인해야 할 때.
---

# 교신저자 판정

## 왜 어려운가 — 숫자부터

정본 코드에 실측이 박혀 있다.

> 교신저자 642편(24.8%)이 '마지막 저자' 추정이고 그 가정은 **실측 대비 39.7% 만 맞는다.** KoreaMed·PubMed 메타데이터에는 교신저자 필드가 아예 없어(**8편 전수 조회 0건**) 원문 PDF 를 읽는 것 외에 방법이 없다.

관행처럼 쓰는 '마지막 저자 = 교신저자' 가정이 **10편 중 6편은 틀린다.** 저자 기여도나 KOL 분석의 근거로 쓰면 결과가 통째로 흔들린다.

## 정본 코드

```
~/Documents/혜연/BTC_KOL_PoC/
  corr_email.py                 228줄  ① 소속란 이메일 local part
  verify_corresponding_pmc.py   368줄  ② PMC 전문 (독립 3자 대조)
  verify_corresponding_pdf.py   528줄  ③ 원문 PDF 1면
```

세 파일 모두 `--selfcheck` 를 가지고 있다. **`python3.11` 로 실행해야 한다** — 툴킷이 `str | None`(3.10+) 문법을 쓴다.

---

## ① 이메일 local part 로 지목한다

PubMed 는 교신저자 전용 필드를 안 준다. 대신 교신저자 이메일을 소속란 끝에 붙인다. **문제는 그 이메일이 모든 저자에게 똑같이 복사되어 온다는 것이다(221편 중 199편).**

그래서 "이메일이 붙어 있다"는 사실만으로는 누구인지 알 수 없다. 알아낼 수 있는 이유는 **local part 자체가 사람을 지목하기 때문**이다.

```
ymhan@jbnu.ac.kr  →  성 han + 이니셜 ym  →  저자 배열의 Han Y M
```

**모호하면 답을 내지 않는다.** 성만 걸리는 후보가 둘 이상이면(김이 셋인 논문) 빈 값으로 둔다. 틀린 교신저자를 넣는 것보다 비워두는 게 낫다.

## ② PMC 전문 — 독립된 세 번째 근거

> 지금 교신저자는 WoS 리프린트 주소와 OpenAlex 두 곳에만 의존한다. 둘이 갈리는 논문이 있어도 어느 쪽이 맞는지 판단할 근거가 없었다. PMC 전문은 **출판사가 논문 안에 직접 표시한 값**이라 둘과 독립된 세 번째 근거다.

두 소스가 충돌할 때 **다수결이 아니라 독립 근거를 하나 더 구하는 것**이 답이다. 이메일도 함께 들어 있어 ①의 검증에도 쓰인다.

캐시(`pmc_cache.json`)는 배치마다 증분 저장한다. 전량 처리 중 끊겨도 이어서 한다.

## ③ 원문 PDF — 최후 수단

PDF 를 받아 1면의 교신저자 표기를 읽는다. 느리고 실패율이 있지만 메타데이터에 없는 건은 이 방법뿐이다.

---

## 대조군 없이는 추출기를 못 믿는다

이 프로젝트의 가장 중요한 설계다.

> 세 구간을 함께 검증한다. **대조군이 없으면 추출기 자체를 믿을 수 없다.**
> `est` 교신 추정 구간 — 원래 목표

추정 구간만 검증하면 "추출기가 100% 맞다"는 결과가 나와도 그게 추출기가 좋아서인지 그 구간이 쉬워서인지 모른다. **정답을 이미 아는 구간을 함께 넣어야** 추출기의 실력이 분리된다.

`--pilot` 로 3구간 표본 25편을 먼저 돌려 추출기를 검증하고, 그 다음 전량으로 간다.

## 검증 먼저, 적용은 나중

```bash
python3 corr_email.py --validate   # 정답 보유 논문에서 정확도 실측
python3 corr_email.py --apply      # Email_Corresponding 필드를 채운다
```

**`--validate` 와 `--apply` 를 분리한다.** 정확도를 모르는 채로 필드를 채우면 나중에 그 값을 얼마나 믿어야 할지 알 수 없다.

## 함정

- 판정 경로를 필드에 남겨라. 이메일로 찾은 것과 PDF 로 확인한 것은 신뢰도가 다르다.
- 저자 배열과 맞출 때 인덱스를 쓰지 마라 — `[[paper-merge-provenance]]` 참조.
- PDF 다운로드는 실패한다. 실패를 오류가 아니라 '미확인'으로 기록한다.

## 연관 skill

`[[paper-merge-provenance]]`, `[[author-disambiguate]]`, `[[kol-profile]]`, `[[paper-collect]]`
SKILL_PAYLOAD_EOF

echo ""
echo "완료 — Skill 1개를 설치했습니다."
echo "Claude Code를 다시 시작하면 인식됩니다."