| name | fact-check |
| description | Verify concrete factual claims in a tech-book chapter draft — numbers, statistics, benchmarks, quotes, version numbers, release years, API signatures, superlatives — against the reference document, and resolve "(사실 확인 필요)" markers. Use when checking a chapter for factual accuracy, validating version/API claims in fast-moving tech content, or resolving fact-check annotations. Triggers on "팩트체크", "사실 확인", "fact check", "출처 검증", "버전 맞는지 확인". |
Fact Check
기술서 챕터 초안의 구체적 사실 주장을 검증한다. 문체가 아니라 정확성만 본다. 최신 기술 주제일수록 버전·API·릴리스 연도가 빠르게 변하므로 시점 명기와 출처 대조가 핵심이다.
활성 장르를 먼저 확인하자. 이 스킬은 기본적으로 tech-book에서 작동한다 (genre는 오케스트레이터 전달 → {slug}/book_manifest.json 순). tech-book이 아니면 오케스트레이터가 팩트체크 단계를 생략한다.
무엇을 검증하나 (검증 대상 주장)
구체적이고 검증 가능한 주장만 본다. 일반적 서술·의견·비유는 대상이 아니다.
| 유형 | 예시 |
|---|
| 수치·통계·벤치마크 | "응답이 3배 빨라진다", "메모리 40% 절감" |
| 인용·귀속 | "Dijkstra가 말했듯이", "공식 문서에 따르면" |
| 버전 번호 | "React 18", "Python 3.12" |
| 릴리스 연도·시점 | "2023년에 도입된", "최신 버전에서는" |
| API·시그니처 | 함수명·플래그·옵션명·기본값 |
| 단정 | "최초의", "유일한", "가장 빠른" |
절차
- 활성 장르 확인 — tech-book이 아니면 중단
- 원문 읽기 —
{NN}_draft.md (style 합의 후 버전 우선)
- 주장 추출 — 위 6유형에 해당하는 구체 주장을 모은다.
(사실 확인 필요) 주석 지점을 최우선 목록에 올린다
- 대조 — 각 주장을
01_reference.md(+ research/*.md)와 맞춘다
- 에스컬레이션 (선택) — 레퍼런스로 판정 불가한 Critical 주장만 WebSearch/WebFetch로 공식 1차 출처 확인. 사소한 주장에 웹 호출 낭비 금지
- 판정 + 정정안 — 라벨별로 정리, 근거 명기
- 전달 —
SendMessage로 chapter-writer에게 + factcheck_log.md에 append
판정 라벨
- ✅ 확인됨 — 근거 일치, 통과 (출처 한 줄 기록)
- ❌ 정정 필요 — 불일치/오류, 올바른 값 제시 (Critical)
- ⚠️ 출처 없음 — 근거 부재, 보강 또는 주장 약화 (Critical)
- 🕒 신선도 경고 — 시점 미명기/휘발성, "{버전}/{연도} 기준" 또는 경고 추가
(사실 확인 필요) 주석은 반드시 넷 중 하나로 해소한다. final에 미해소 주석이 남으면 안 된다.
의심 식별자 = 구속력 있는 검증 (절대 패시브 메모로 격하 금지)
팩트체커가 스스로 어떤 식별자를 "형식상 이례적"이라고 의심했다면(잘못된 형식 또는 미래 날짜의 arXiv ID, 해석되지 않는 DOI/URL, "너무 깨끗한"·검증 불가한 인용 등), 그 의심은 구속력 있는 웹 검증으로 에스컬레이션해야 한다 (비용 통제 규칙이 이미 Critical→웹 2차를 허용한다). 절대 editor에게 넘기는 수동적 메모로 격하해서는 안 된다.
- 단일 소스 = 통과 규칙을 의심 식별자에 적용하지 않는다. 한 곳에만 나오는 인용이라도, 의심스럽고 검증되지 않았다면 통과(✅)가 될 수 없다.
- 검증 불가·의심 식별자는 ❌ 또는 🕒로 판정한다 (HARD BLOCK) — 절대 ✅가 아니다.
- 자동 ❌ 규칙: 빌드 시점 기준 미래의 YYMM을 가진 arXiv ID는 자동 ❌. (arXiv ID
YYMM.NNNNN의 YYMM이 빌드 날짜보다 미래면 존재할 수 없는 식별자다 — 날조 신호.)
이렇게 판정된 ❌ 항목은 BLOCKING이다. 원고가 최종 확정되기 전에 반드시 해소해야 한다 — 정정·출처 확보·삭제 셋 중 하나. 저술가 재량으로 그대로 둘 수 없다.
리뷰 메시지 포맷
## 팩트체크: {NN}장 라운드 {N}
### ❌ 정정 필요
- [원문] "..." → [정정] "..."
**근거:** {레퍼런스 섹션 또는 URL}
### ⚠️ 출처 없음
- [원문] "..." → 근거 없음. {보강/약화 제안}
### 🕒 신선도 경고
- [원문] "..." → "{버전} 기준"으로 명기
### ✅ 확인됨
- "..." — {근거}
총평: {한 줄}
로그 파일 규약 (단일 파일)
pool 분할로 챕터를 나눠 처리해도 로그는 단일 파일(factcheck_log.md)에 챕터별 마크다운 섹션 ## {NN}장으로 append한다 — 절대 factcheck_log_1-6 같은 샤드 파일을 만들지 않는다.
작업 원칙
- 사실만: 문체·구성 건드리지 않는다
- 구체적 정정: 올바른 값/표현을 제시 ("틀렸다"로 끝내지 않음)
- 근거 필수: 모든 판정에 출처 한 줄
- 추측 금지: 확인 못 한 건 "확인 불가". 그럴듯한 값 지어내기 금지
- 과잉 차단 주의: 정당한 일반 서술까지 출처 요구하지 않는다
재검증 / 미합의
- 라운드 2+: 이전 정정 반영 여부 확인 후 새 항목만 지적
- 3회 왕복 미합의 → 사실 오류는 저술가 재량으로 덮지 않는다.
factcheck_log.md에 "미해소(위험)"로 명시하고 오케스트레이터·editor에 에스컬레이션
통합 원고 검증 (editor 요청 시)
- 챕터 간 사실 충돌(같은 수치/버전을 장마다 다르게 서술)이 있는지 교차 점검
- 콜로폰·책 소개에 들어가는 사실(버전·연도)도 본문과 일치하는지 확인
