0x6869726f6b69/claude-skills

Paper Review Loop: 리뷰 → 수정 → 재리뷰

논문 PDF를 전문가로서 리뷰하고, 그 지적에 따라 원고를 수정하여 PDF를 다시 만든 후, 수정된 버전을 다시 리뷰합니다. 사용자가 정한 제한 시간 내에 가능한 한 많이 이 주기를 반복합니다. 마지막에 사용자에게 전달하는 것은 다음 세 가지입니다.

• 수정된 PDF(최종 버전)와 각 라운드의 PDF
• 각 라운드의 리뷰 리포트(7개 항목)와 평가·지적 상태의 추이
• 저자만 할 수 있는 작업 목록(추가 실험 등. 날조를 피하기 위해 본문 대신 여기에 배치한 것)

이하, <skill_dir>은 이 SKILL.md가 있는 디렉토리, <ws>는 작업 폴더입니다. loop_state.py 등의 스크립트 이름은 python <skill_dir>/scripts/loop_state.py의 약자입니다. python이 없는 환경에서는 python3를 사용하세요.

0. 먼저: 제한 시간 묻기

1. 대상 PDF를 특정합니다. 메시지에 없으면 물어봅니다. PDF와 같은 위치나 첨부에 LaTeX 소스(폴더, .zip, arXiv의 .tar.gz, .tex)가 있는지도 확인합니다. 소스가 있으면 수정의 질과 속도가 크게 향상됩니다.
2. 제한 시간을 묻습니다. AskUserQuestion과 같은 질문 도구가 있으면 그것을 사용하고, 없으면 채팅으로 물어서 답변을 기다립니다. 시작 메시지에 이미 시간이 명시되어 있으면 그것을 사용하고 다시 묻지 않습니다.
   • 질문1 "제한 시간": 리뷰만 (수정 루프 없음) / 1시간 / 2시간 / 3시간 (그 외에 "30분", "5시간" 등도 가능)
   • 질문2 "투고처·평가 기준"(같은 질문 다이얼로그에 통합합니다. 이미 알고 있으면 생략): 지정 없음 (최고 국제 학회 기준) / NeurIPS·ICML·ICLR / 저널 (Accept / Minor / Major / Reject)
3. 답변을 받으면 즉시 시계를 시작합니다. 설정 시간도 예산에 포함됩니다.

   python <skill_dir>/scripts/loop_state.py init <ws> --hours 2 --paper <pdf> --venue "<투고처>"
   

   (--minutes 90 또는 --review-only도 가능)
4. 슬립 방지 도구(Claude 데스크톱의 keep-awake 등)가 있으면 예산 시간만큼 활성화합니다. PC가 슬립하면 장시간 루프가 멈출 수 있습니다.
5. 사용자에게 2~3줄로 전달합니다: 마감 시간, 작업 폴더, 이후에는 확인 없이 자율적으로 반복한다는 점, 언제든지 중단 가능하다는 점.

1. 설정

작업 폴더는 <PDF가 있는 폴더>/<PDF 이름>_review_loop/입니다(쓸 수 없으면 작업 디렉토리 아래).

<ws>/
├── state.json          타이머와 각 페이즈 기록 (loop_state.py가 관리)
├── original/           받은 PDF·소스. 변경하지 않음
├── src/                편집용 소스 (main.tex, figures/, *.bib)
├── work/               페이지 이미지 등 작업용 임시 파일
├── rounds/
│   ├── r01/            paper.pdf(=원본 PDF) paper.txt review.md issues.json response.md src/
│   ├── r02/            paper.pdf(1차 수정) paper.txt review.md issues.json response.md src/ changes.diff
│   └── ...
├── issue_tracker.md    평가와 지적 상태 추이 (loop_state.py summary가 생성)
├── author_todo.md      저자만 해결할 수 있는 과제 (추가 실험 등)
└── final_report.md

1. loop_state.py start <ws> --round 0 --phase setup
2. PDF를 original/과 rounds/r01/paper.pdf에 복사하고 텍스트를 추출합니다: python <skill_dir>/scripts/pdf_tools.py text <ws>/rounds/r01/paper.pdf -o <ws>/rounds/r01/paper.txt
3. 편집용 소스를 src/에 준비합니다(리뷰 전용 모드에서는 필요 없으므로 건너뜁니다).
   • LaTeX 소스가 있는 경우: src/에 복사/압축 해제합니다(\documentclass와 \begin{document}를 포함하는 파일이 메인입니다). build_pdf.py로 한 번 빌드하여 통과하는지 확인합니다.
   • PDF만 있는 경우: references/pdf_to_latex.md의 절차에 따라 LaTeX 소스를 재구성합니다. 가장 무거운 공정(10페이지에 20~40분 정도)이므로 예산을 많이 사용한다는 점을 사용자에게 한마디 전합니다.
4. python <skill_dir>/scripts/snapshot.py <ws>/src <ws>/rounds/r01
5. loop_state.py end <ws> --round 0 --phase setup

라운드 1의 리뷰는 원본 PDF가 대상이므로 소스 재구성과 병렬로 진행해도 좋습니다. 서브 에이전트를 사용할 수 있다면 리뷰 담당과 재구성 담당을 동시에 시작합니다.

2. 루프

역할 분담과 그 이유

• 리뷰는 라운드마다 새로운 서브 에이전트(Agent 도구)에게 맡깁니다. 수정한 사람의 맥락을 가지지 않은 리뷰어는 "무엇을 고친 셈인지"가 아니라 "PDF에 실제로 무엇이 쓰여 있는지"만으로 판단할 수 있습니다. 같은 맥락에서 자체 평가하면 평가가 관대해집니다.
• 수정도 서브 에이전트에게 맡기고, 메인은 오케스트레이션(시계, 시작, 검증, 집계)에 집중합니다. 몇 시간의 루프에서도 메인의 맥락이 팽창하지 않고 상태는 모두 파일에 남습니다.
• 서브 에이전트를 사용할 수 없는 환경에서는 모든 것을 직접 순서대로 수행합니다. 그 경우에도 리뷰 전에 새로운 PDF에서 텍스트를 다시 추출하여 그것을 읽고, 기억이 아니라 지면으로 평가합니다.

라운드 r (r = 1, 2, …)

(a) 리뷰

1. loop_state.py start <ws> --round r --phase review
2. 아래 "리뷰 담당자에게 보내는 요청문"으로 서브 에이전트를 시작하고 완료를 기다립니다.
3. 출력을 검증합니다: review.md에 필요한 절(r≥2에서는 제0절도)이 있는지, issues.json이 JSON으로 읽을 수 있는지 확인합니다. 부족하면 같은 리뷰 담당자에게 수정시킵니다.
4. loop_state.py end <ws> --round r --phase review, 이어서 loop_state.py summary <ws>(issue_tracker.md 갱신).
5. 사용자에게 한 줄만 진행 상황을 알립니다. 예: r02 리뷰 완료: 종합 3→4, Major 미해결 5→2, 남은 시간 1h12m

(b) 계속할지 판단

1. loop_state.py status <ws>를 실행합니다. Claude는 경과 시간을 감지할 수 없으므로 시간 판단은 반드시 이 출력에 따라야 합니다.
2. NEXT: STOP이면 §3으로 이동합니다. 판단은 리뷰 직후에 이루어지므로 최종 PDF는 반드시 리뷰된 상태가 됩니다.
3. CONTINUE라도 최신 issues.json에 status가 open / partially_resolved인 지적이 남아 있지 않으면(모두 resolved이거나, [AUTHOR TODO]로 보류한 needs_author) 종료해도 좋습니다. 본문에서 고칠 수 있는 것이 다 떨어져서 더 이상 돌려도 문구를 다듬는 것뿐입니다. 이유는 final_report에 씁니다.

(c) 수정(라운드 r의 리뷰에 대응하여 r+1의 PDF를 만듭니다)

1. loop_state.py start <ws> --round r --phase revise. status에 나오는 revise by 시각을 기록합니다.
2. 아래 "수정 담당자에게 보내는 요청문"으로 서브 에이전트를 시작하고 완료를 기다립니다.
3. 검증합니다: rounds/r{r+1}/paper.pdf와 paper.txt가 있는지, 빌드가 성공하고 미정의 참조가 0인지, rounds/r{r}/response.md가 있는지 확인합니다. 빌드가 통과되지 않으면 망가진 파일을 rounds/r{r}/src/에서 되돌려 변경을 다시 수행합니다. 오래된 PDF를 수정판으로 리뷰에 넘겨서는 안 됩니다.
4. loop_state.py end <ws> --round r --phase revise → r+1로 (a)로 이동합니다.

수정 담당자는 revise by를 넘으면 새로운 수정을 시작하지 않고 빌드를 통과시켜 마무리합니다. 다음 리뷰의 시간을 남기기 위해서입니다.

리뷰 담당자에게 보내는 요청문

당신은 이 논문의 리뷰어입니다. 먼저 <skill_dir>/references/reviewer_guide.md와
<skill_dir>/references/review_template.md를 끝까지 읽고, 리뷰어상·기준·출력 형식에 따라 주세요.

- 리뷰 대상: <ws>/rounds/rNN/paper.pdf (추출 텍스트: <ws>/rounds/rNN/paper.txt)
- 라운드: NN
- 이전 라운드의 지적: <ws>/rounds/r(NN-1)/issues.json   ← 라운드 2 이후만
- 투고처·평가 척도: <venue 또는 "지정 없음">
- 리뷰 리포트 언어: 한국어
- 출력: <ws>/rounds/rNN/review.md 와 <ws>/rounds/rNN/issues.json
- 보조: python <skill_dir>/scripts/pdf_tools.py (render로 그림·표가 있는 페이지를 이미지로 확인 가능)

평가의 근거는 이 PDF에 쓰여 있는 내용뿐입니다. 수정자의 의도나 답변서는 전달하지 않았습니다.
[AUTHOR TODO]라고 쓰인 부분은 약속에 불과하므로 미해결로 처리해 주세요.
마지막으로 "종합 평가 / Confidence / Major 미해결 수 / 새 지적 수"를 4줄로 반환해 주세요.

수정 담당자에게 보내는 요청문

당신은 이 논문의 저자로서 리뷰에 기반하여 원고를 수정합니다. 먼저
<skill_dir>/references/revision_guide.md를 끝까지 읽고, 특히 "날조하지 않는다" 규칙을 지켜 주세요.

- 편집할 소스: <ws>/src/ (메인: <main>.tex)
- 이번 리뷰: <ws>/rounds/rNN/review.md, <ws>/rounds/rNN/issues.json
- 추이: <ws>/issue_tracker.md (자동 생성이므로 읽기만. 편집하지 않음)
- 저자 TODO: <ws>/author_todo.md (없으면 만들고, 추기·갱신)
- 시간: <revise_by>까지 빌드까지 마칠 것. 남은 시간은
  python <skill_dir>/scripts/loop_state.py status <ws>로 확인 가능.
- 끝나면:
  1. python <skill_dir>/scripts/build_pdf.py <ws>/src/<main>.tex --out <ws>/rounds/r(NN+1)/paper.pdf
     (에러와 미정의 참조가 0이 될 때까지 수정)
  2. python <skill_dir>/scripts/pdf_tools.py text <ws>/rounds/r(NN+1)/paper.pdf -o <ws>/rounds/r(NN+1)/paper.txt
  3. python <skill_dir>/scripts/snapshot.py <ws>/src <ws>/rounds/r(NN+1) --prev <ws>/rounds/rNN
  4. <ws>/rounds/rNN/response.md 작성 (형식은 revision_guide.md 참조)
마지막으로 "대응한 지적 ID / 저자TODO로 돌린 ID / 빌드 결과(페이지 수·미정의 참조·AUTHOR TODO 수)"를 반환해 주세요.

PDF에서 재구성을 맡길 경우는 "<skill_dir>/references/pdf_to_latex.md를 읽고, <ws>/original/<name>.pdf를 <ws>/src/에 재구성하고, 빌드한 PDF를 <ws>/rounds/r01/reconstructed.pdf에 저장하고, 차이를 <ws>/src/RECONSTRUCTION_NOTES.md에 써 주세요"라고 요청합니다.

3. 종료 처리

1. loop_state.py finish <ws> --reason "<마감 / 본문에서 고칠 지적이 다 떨어짐 / 리뷰만>" → loop_state.py summary <ws>
2. 수정을 1회 이상 했다면 최신 PDF를 <ws>/<PDF 이름>_revised.pdf로 복사합니다.
3. <ws>/final_report.md를 작성합니다:

# 리뷰·수정 리포트: <논문 제목>
- 제한 시간 / 사용 시간 / 라운드 수 / 종료 이유
## 평가 추이            (issue_tracker.md의 표)
## 원본 원고(r01)의 리뷰 요점   (Justification 요약과 주요 Weakness)
## 수정으로 해결한 주요 지적
## 남아 있는 과제
### 본문 수정으로 대응 가능하지만 시간 내에 끝나지 않은 것
### 저자의 작업이 필요한 것 (author_todo.md의 우선순위 상위)
## 최종 라운드 평가와, 채택 측으로 움직이기 위한 조건
## 파일 목록

4. 사용자에 대한 응답은 짧게 정리합니다: 라운드 수, 평가 추이, 해결한 주요 지적, 남은 중요 과제와 저자 TODO 상위 3건, 파일 위치. 리뷰 전문은 붙이지 않고 파일을 가리킵니다. 리뷰 전용 모드라면 r01의 review.md 요점(Justification·Rating·주요 Weakness·Rebuttal 질문)을 응답에 포함합니다.

중단에서 재개

<ws>/state.json이 있고 status가 running이면 loop_state.py status <ws>와 rounds/의 내용을 보고, 마지막으로 완료한 페이즈의 다음부터 재개합니다. init을 다시 하면 시계가 리셋되므로, 사용자가 새 예산을 원할 때만 --force로 수행합니다.

원칙과 그 이유

• 날조하지 않음: 실험 결과·수치·데이터·인용·증명을 만들지 않습니다. 이것은 실제 연구 원고이며, 만든 수치가 하나라도 섞이면 연구 부정이 되어 사용자에게 심각한 피해를 줍니다. 새로운 결과가 필요한 지적은 본문에서는 주장을 증거의 범위에 맞추고, 필요한 실험은 [AUTHOR TODO]와 author_todo.md로 돌립니다.
• 리뷰 기준을 완화하지 않음: 라운드가 진행되어도 같은 기준으로 평가합니다. [AUTHOR TODO]는 미해결이며, 말을 바꾼 것만으로는 새로운 증거가 되지 않습니다. 평가가 오르는 것은 지면 상에서 문제가 해결되었을 때뿐입니다. 그렇지 않으면 이 루프는 겉보기 점수를 올리는 작업이 되어 버립니다.
• 시간 판단은 스크립트에 맡김: 경과 시간을 추측하지 않습니다. 매 라운드 status를 봅니다.
• 라운드 사이에 사용자에게 확인하지 않음: 제한 시간을 받은 시점에서 루프 전체의 실행은 승인된 것입니다. 보고는 한 줄의 진행 상황만으로 하고, 멈춰서 상담하는 것은 블로커(빌드를 고칠 수 없음, PDF를 읽을 수 없음 등)가 있을 때만입니다.
• 원본 파일은 변경하지 않음: original/은 읽기 전용으로 취급하고, 편집은 src/의 복사본에서 수행합니다.