fact-check

Name: fact-check
Author: tobyilee

77stars16forks

How to install fact-check?

tobyilee/book-writer/fact-check

$npx -y skills add tobyilee/book-writer --skill fact-check

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Fact Check
2
3	기술서 챕터 초안의 구체적 사실 주장을 검증한다. 문체가 아니라 정확성만 본다. 최신 기술 주제일수록 버전·API·릴리스 연도가 빠르게 변하므로 시점 명기와 출처 대조가 핵심이다.
4
5	> 활성 장르를 먼저 확인하자. 이 스킬은 기본적으로 `tech-book`에서 작동한다 (`genre`는 오케스트레이터 전달 → `{slug}/book_manifest.json` 순). tech-book이 아니면 오케스트레이터가 팩트체크 단계를 생략한다.
6
7	## 무엇을 검증하나 (검증 대상 주장)
8
9	구체적이고 검증 가능한 주장만 본다. 일반적 서술·의견·비유는 대상이 아니다.
10
11	\| 유형 \| 예시 \|
12	\|------\|------\|
13	\| 수치·통계·벤치마크 \| "응답이 3배 빨라진다", "메모리 40% 절감" \|
14	\| 인용·귀속 \| "Dijkstra가 말했듯이", "공식 문서에 따르면" \|
15	\| 버전 번호 \| "React 18", "Python 3.12" \|
16	\| 릴리스 연도·시점 \| "2023년에 도입된", "최신 버전에서는" \|
17	\| API·시그니처 \| 함수명·플래그·옵션명·기본값 \|
18	\| 단정 \| "최초의", "유일한", "가장 빠른" \|
19
20	## 절차
21
22	1. 활성 장르 확인 — tech-book이 아니면 중단
23	2. 원문 읽기 — `{NN}_draft.md` (style 합의 후 버전 우선)
24	3. 주장 추출 — 위 6유형에 해당하는 구체 주장을 모은다. `(사실 확인 필요)` 주석 지점을 최우선 목록에 올린다
25	4. 대조 — 각 주장을 `01_reference.md`(+ `research/*.md`)와 맞춘다
26	5. 에스컬레이션 (선택) — 레퍼런스로 판정 불가한 Critical 주장만 WebSearch/WebFetch로 공식 1차 출처 확인. 사소한 주장에 웹 호출 낭비 금지
27	6. 판정 + 정정안 — 라벨별로 정리, 근거 명기
28	7. 전달 — `SendMessage`로 `chapter-writer`에게 + `factcheck_log.md`에 append
29
30	## 판정 라벨
31
32	- ✅ 확인됨 — 근거 일치, 통과 (출처 한 줄 기록)
33	- ❌ 정정 필요 — 불일치/오류, 올바른 값 제시 (Critical)
34	- ⚠️ 출처 없음 — 근거 부재, 보강 또는 주장 약화 (Critical)
35	- 🕒 신선도 경고 — 시점 미명기/휘발성, "{버전}/{연도} 기준" 또는 경고 추가
36
37	`(사실 확인 필요)` 주석은 반드시 넷 중 하나로 해소한다. final에 미해소 주석이 남으면 안 된다.
38
39	## 의심 식별자 = 구속력 있는 검증 (절대 패시브 메모로 격하 금지)
40
41	팩트체커가 스스로 어떤 식별자를 "형식상 이례적"이라고 의심했다면(잘못된 형식 또는 미래 날짜의 arXiv ID, 해석되지 않는 DOI/URL, "너무 깨끗한"·검증 불가한 인용 등), 그 의심은 구속력 있는 웹 검증으로 에스컬레이션해야 한다 (비용 통제 규칙이 이미 Critical→웹 2차를 허용한다). 절대 editor에게 넘기는 수동적 메모로 격하해서는 안 된다.
42
43	- 단일 소스 = 통과 규칙을 의심 식별자에 적용하지 않는다. 한 곳에만 나오는 인용이라도, 의심스럽고 검증되지 않았다면 통과(✅)가 될 수 없다.
44	- 검증 불가·의심 식별자는 ❌ 또는 🕒로 판정한다 (HARD BLOCK) — 절대 ✅가 아니다.
45	- 자동 ❌ 규칙: 빌드 시점 기준 미래의 YYMM을 가진 arXiv ID는 자동 ❌. (arXiv ID `YYMM.NNNNN`의 YYMM이 빌드 날짜보다 미래면 존재할 수 없는 식별자다 — 날조 신호.)
46
47	이렇게 판정된 ❌ 항목은 BLOCKING이다. 원고가 최종 확정되기 전에 반드시 해소해야 한다 — 정정·출처 확보·삭제 셋 중 하나. 저술가 재량으로 그대로 둘 수 없다.
48
49	## 리뷰 메시지 포맷
50
51	```markdown
52	## 팩트체크: {NN}장 라운드 {N}
53
54	### ❌ 정정 필요
55	- [원문] "..." → [정정] "..."
56	근거: {레퍼런스 섹션 또는 URL}
57
58	### ⚠️ 출처 없음
59	- [원문] "..." → 근거 없음. {보강/약화 제안}
60
61	### 🕒 신선도 경고
62	- [원문] "..." → "{버전} 기준"으로 명기
63
64	### ✅ 확인됨
65	- "..." — {근거}
66
67	총평: {한 줄}
68	```
69
70	## 로그 파일 규약 (단일 파일)
71
72	pool 분할로 챕터를 나눠 처리해도 로그는 단일 파일(`factcheck_log.md`)에 챕터별 마크다운 섹션 `## {NN}장`으로 append한다 — 절대 `factcheck_log_1-6` 같은 샤드 파일을 만들지 않는다.
73
74	## 작업 원칙
75
76	- 사실만: 문체·구성 건드리지 않는다
77	- 구체적 정정: 올바른 값/표현을 제시 ("틀렸다"로 끝내지 않음)
78	- 근거 필수: 모든 판정에 출처 한 줄
79	- 추측 금지: 확인 못 한 건 "확인 불가". 그럴듯한 값 지어내기 금지
80	- 과잉 차단 주의: 정당한 일반 서술까지 출처 요구하지 않는다
81
82	## 재검증 / 미합의
83
84	- 라운드 2+: 이전 정정 반영 여부 확인 후 새 항목만 지적
85	- 3회 왕복 미합의 → 사실 오류는 저술가 재량으로 덮지 않는다. `factcheck_log.md`에 "미해소(위험)"로 명시하고 오케스트레이터·editor에 에스컬레이션
86
87	## 통합 원고 검증 (editor 요청 시)
88
89	- 챕터 간 사실 충돌(같은 수치/버전을 장마다 다르게 서술)이 있는지 교차 점검
90	- 콜로폰·책 소개에 들어가는 사실(버전·연도)도 본문과 일치하는지 확인

tobyileePublisher · 27 listings

Preview

tobyilee/book-writer

# Fact Check

기술서 챕터 초안의 **구체적 사실 주장**을 검증한다. 문체가 아니라 정확성만 본다. 최신 기술 주제일수록 버전·API·릴리스 연도가 빠르게 변하므로 시점 명기와 출처 대조가 핵심이다.

> **활성 장르를 먼저 확인하자.** 이 스킬은 기본적으로 `tech-book`에서 작동한다 (`genre`는 오케스트레이터 전달 → `{slug}/book_manifest.json` 순). tech-book이 아니면 오케스트레이터가 팩트체크 단계를 생략한다.

## 무엇을 검증하나 (검증 대상 주장)

Repotobyilee/book-writer

LicenseMIT

TypeSkills

CategoryTesting

UpdatedJul 2026

Repo stars77

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

fact-check

77stars16forks

View on GitHub

How to install fact-check?

tobyilee/book-writer/fact-check

$npx -y skills add tobyilee/book-writer --skill fact-check

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Fact Check
2
3	기술서 챕터 초안의 구체적 사실 주장을 검증한다. 문체가 아니라 정확성만 본다. 최신 기술 주제일수록 버전·API·릴리스 연도가 빠르게 변하므로 시점 명기와 출처 대조가 핵심이다.
4
5	> 활성 장르를 먼저 확인하자. 이 스킬은 기본적으로 `tech-book`에서 작동한다 (`genre`는 오케스트레이터 전달 → `{slug}/book_manifest.json` 순). tech-book이 아니면 오케스트레이터가 팩트체크 단계를 생략한다.
6
7	## 무엇을 검증하나 (검증 대상 주장)
8
9	구체적이고 검증 가능한 주장만 본다. 일반적 서술·의견·비유는 대상이 아니다.
10
11	\| 유형 \| 예시 \|
12	\|------\|------\|
13	\| 수치·통계·벤치마크 \| "응답이 3배 빨라진다", "메모리 40% 절감" \|
14	\| 인용·귀속 \| "Dijkstra가 말했듯이", "공식 문서에 따르면" \|
15	\| 버전 번호 \| "React 18", "Python 3.12" \|
16	\| 릴리스 연도·시점 \| "2023년에 도입된", "최신 버전에서는" \|
17	\| API·시그니처 \| 함수명·플래그·옵션명·기본값 \|
18	\| 단정 \| "최초의", "유일한", "가장 빠른" \|
19
20	## 절차
21
22	1. 활성 장르 확인 — tech-book이 아니면 중단
23	2. 원문 읽기 — `{NN}_draft.md` (style 합의 후 버전 우선)
24	3. 주장 추출 — 위 6유형에 해당하는 구체 주장을 모은다. `(사실 확인 필요)` 주석 지점을 최우선 목록에 올린다
25	4. 대조 — 각 주장을 `01_reference.md`(+ `research/*.md`)와 맞춘다
26	5. 에스컬레이션 (선택) — 레퍼런스로 판정 불가한 Critical 주장만 WebSearch/WebFetch로 공식 1차 출처 확인. 사소한 주장에 웹 호출 낭비 금지
27	6. 판정 + 정정안 — 라벨별로 정리, 근거 명기
28	7. 전달 — `SendMessage`로 `chapter-writer`에게 + `factcheck_log.md`에 append
29
30	## 판정 라벨
31
32	- ✅ 확인됨 — 근거 일치, 통과 (출처 한 줄 기록)
33	- ❌ 정정 필요 — 불일치/오류, 올바른 값 제시 (Critical)
34	- ⚠️ 출처 없음 — 근거 부재, 보강 또는 주장 약화 (Critical)
35	- 🕒 신선도 경고 — 시점 미명기/휘발성, "{버전}/{연도} 기준" 또는 경고 추가
36
37	`(사실 확인 필요)` 주석은 반드시 넷 중 하나로 해소한다. final에 미해소 주석이 남으면 안 된다.
38
39	## 의심 식별자 = 구속력 있는 검증 (절대 패시브 메모로 격하 금지)
40
41	팩트체커가 스스로 어떤 식별자를 "형식상 이례적"이라고 의심했다면(잘못된 형식 또는 미래 날짜의 arXiv ID, 해석되지 않는 DOI/URL, "너무 깨끗한"·검증 불가한 인용 등), 그 의심은 구속력 있는 웹 검증으로 에스컬레이션해야 한다 (비용 통제 규칙이 이미 Critical→웹 2차를 허용한다). 절대 editor에게 넘기는 수동적 메모로 격하해서는 안 된다.
42
43	- 단일 소스 = 통과 규칙을 의심 식별자에 적용하지 않는다. 한 곳에만 나오는 인용이라도, 의심스럽고 검증되지 않았다면 통과(✅)가 될 수 없다.
44	- 검증 불가·의심 식별자는 ❌ 또는 🕒로 판정한다 (HARD BLOCK) — 절대 ✅가 아니다.
45	- 자동 ❌ 규칙: 빌드 시점 기준 미래의 YYMM을 가진 arXiv ID는 자동 ❌. (arXiv ID `YYMM.NNNNN`의 YYMM이 빌드 날짜보다 미래면 존재할 수 없는 식별자다 — 날조 신호.)
46
47	이렇게 판정된 ❌ 항목은 BLOCKING이다. 원고가 최종 확정되기 전에 반드시 해소해야 한다 — 정정·출처 확보·삭제 셋 중 하나. 저술가 재량으로 그대로 둘 수 없다.
48
49	## 리뷰 메시지 포맷
50
51	```markdown
52	## 팩트체크: {NN}장 라운드 {N}
53
54	### ❌ 정정 필요
55	- [원문] "..." → [정정] "..."
56	근거: {레퍼런스 섹션 또는 URL}
57
58	### ⚠️ 출처 없음
59	- [원문] "..." → 근거 없음. {보강/약화 제안}
60
61	### 🕒 신선도 경고
62	- [원문] "..." → "{버전} 기준"으로 명기
63
64	### ✅ 확인됨
65	- "..." — {근거}
66
67	총평: {한 줄}
68	```
69
70	## 로그 파일 규약 (단일 파일)
71
72	pool 분할로 챕터를 나눠 처리해도 로그는 단일 파일(`factcheck_log.md`)에 챕터별 마크다운 섹션 `## {NN}장`으로 append한다 — 절대 `factcheck_log_1-6` 같은 샤드 파일을 만들지 않는다.
73
74	## 작업 원칙
75
76	- 사실만: 문체·구성 건드리지 않는다
77	- 구체적 정정: 올바른 값/표현을 제시 ("틀렸다"로 끝내지 않음)
78	- 근거 필수: 모든 판정에 출처 한 줄
79	- 추측 금지: 확인 못 한 건 "확인 불가". 그럴듯한 값 지어내기 금지
80	- 과잉 차단 주의: 정당한 일반 서술까지 출처 요구하지 않는다
81
82	## 재검증 / 미합의
83
84	- 라운드 2+: 이전 정정 반영 여부 확인 후 새 항목만 지적
85	- 3회 왕복 미합의 → 사실 오류는 저술가 재량으로 덮지 않는다. `factcheck_log.md`에 "미해소(위험)"로 명시하고 오케스트레이터·editor에 에스컬레이션
86
87	## 통합 원고 검증 (editor 요청 시)
88
89	- 챕터 간 사실 충돌(같은 수치/버전을 장마다 다르게 서술)이 있는지 교차 점검
90	- 콜로폰·책 소개에 들어가는 사실(버전·연도)도 본문과 일치하는지 확인

tobyileePublisher · 27 listings

Preview

tobyilee/book-writer

# Fact Check

## 무엇을 검증하나 (검증 대상 주장)

Repotobyilee/book-writer

LicenseMIT

TypeSkills

CategoryTesting

UpdatedJul 2026

Repo stars77

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type