From research-toolkit
학술 논문(PDF 또는 arXiv/학회 URL)을 받아서 CPR(Context-Problem-Response) 프레임으로 한국어 요약을 작성. 사용자가 "이 논문 요약해줘", "이 PDF 정리해줘", arxiv.org 링크나 .pdf 경로를 줄 때 사용.
How this skill is triggered — by the user, by Claude, or both
Slash command
/research-toolkit:paper-summaryThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
연구실 석사/박사 과정생들을 위한 논문 요약 스킬. *The Craft of Research* (Booth, Colomb, Williams)의 **CPR(Context-Problem-Response)** 구조를 따른다. 논문 섹션 순서가 아니라 저자의 **수사적 논증 구조**를 복원하는 게 목적이다.
연구실 석사/박사 과정생들을 위한 논문 요약 스킬. The Craft of Research (Booth, Colomb, Williams)의 CPR(Context-Problem-Response) 구조를 따른다. 논문 섹션 순서가 아니라 저자의 수사적 논증 구조를 복원하는 게 목적이다.
사용자가 제공한 입력이 무엇인지 먼저 판단:
~/Downloads/paper.pdf)
→ Read 도구로 PDF 직접 읽기. 10쪽 초과 시 pages 파라미터로 범위 지정 (예: pages: "1-10")arxiv.org/abs/2401.12345)
→ https://arxiv.org/pdf/2401.12345.pdf로 변환 후 WebFetch. abstract 페이지보다 PDF가 본문 정보 풍부함WebFetch로 본문 가져오기. PDF 링크가 있으면 우선WebSearch로 원문 위치 먼저 찾기PDF가 길면 분할 읽기:
CPR은 Introduction과 Conclusion에 가장 명확히 드러난다. 이 두 부분을 먼저 정독.
논문 요약의 핵심은 다음 세 가지를 복원하는 것:
핵심 통찰: Problem의 Cost가 곧 논문의 "기여 동기"다. Cost가 약하면 그 논문은 "그래서 뭐?" 라는 비판을 못 견딘다. 요약할 때 Cost를 명시적으로 적어주면, 독자가 그 논문을 자기 연구 맥락에서 평가하기 쉬워진다.
아래 구조를 정확히 이 순서, 이 제목으로 작성. 정보가 없으면 "논문에서 명시되지 않음"이라고 적기.
# {논문 제목 원문}
**저자:** {저자 1, 저자 2, ...} ({소속})
**발표:** {학회/저널명}, {연도}
**원문:** {URL 또는 파일 경로}
## 한 줄 요약
{Context-Problem-Response를 한 문장으로 압축. 예시 형식:
"[Context]에서 [Problem]을 해결하기 위해 [Response]를 제안한 논문."
모델명/방법명/데이터셋명은 영문 원문 유지.}
---
## Context — 공통 기반
{저자가 독자와 공유한다고 가정하는 배경 지식. 다음 두 가지를 분리해서 적기:
**받아들여지고 있는 사실:** 이 분야에서 이미 합의된 것 (예: "Transformer 기반 LLM이 NLP의 표준 아키텍처가 되었다")
**저자가 의존하는 선행 연구:** 이 논문이 발 딛고 선 baseline/방법론 (예: "RLHF의 InstructGPT 방식을 따른다")
Related Work를 전부 옮기지 말고, 본 논문의 출발점이 되는 것만.}
---
## Problem — 무엇이 문제인가
### Condition (무엇이 불완전한가)
{Context에서 무엇이 부족한가/모르는가/오해되고 있는가. 저자가 "그런데 ~", "그러나 ~", "However" 등으로 분기하는 지점이 여기. 가능하면 직접 인용 한 구절 포함.}
### Cost (So what? — 왜 신경 써야 하는가)
{이 Condition이 해결되지 않으면 누가 어떤 손해를 보는가. 다음 중 하나 이상으로 답:
- 실용적 비용: 응용/제품/사용자에게 어떤 손해인지
- 이론적 비용: 우리 이해가 어떻게 잘못되는지
- 후속 연구의 비용: 다른 연구가 이 때문에 막혀 있는지
저자가 명시 안 했으면 "저자는 명시적 Cost를 제시하지 않음. 추정컨대 ~"라고 솔직히 적기. 추측인지 인용인지 반드시 구분.}
---
## Response — 어떻게 답하는가
### 핵심 주장 (Claim)
{이 논문이 결국 무엇을 주장하는가. Conclusion 첫 문단에 보통 명시됨. 한 두 문장.}
### 방법 (How)
{주장을 뒷받침하기 위해 어떤 방법/시스템/실험을 설계했나. 핵심 메커니즘만. 수식은 변수 의미 포함해서 핵심 한두 개만. Figure가 핵심이면 그림 번호 언급.}
### 근거 (Evidence)
{사용 데이터셋, 비교 baseline, 핵심 메트릭 수치. 표 전체 옮기지 말고 가장 인상적인 2-3개만. 예: "GLUE에서 BERT-base 대비 +2.3점, 추론 속도 1.8배". 단위(%, ms, M params) 빠뜨리지 말 것.}
---
## 한계 및 열린 질문
{저자가 limitations 섹션에 적은 것 + 읽으면서 의문이 든 점을 **구분해서** 적기:
**저자가 인정한 한계:** ...
**리뷰어 관점에서의 의문:** ...
이 구분이 중요한 이유: 다른 연구실원이 이 논문을 인용할 때 "저자가 말한 것"과 "당신 해석"을 섞으면 안 됨.}
---
## 우리 연구와의 관련성
{사용자가 자기 연구 주제를 미리 말했다면 그 맥락에서 작성. 아니면 다음 관점에서:
- 이 논문의 **Response**가 어떤 종류의 연구에 재사용 가능한지
- 이 논문의 **Problem**(특히 Cost)이 어떤 다른 분야에서도 성립하는지
- 한계 부분이 후속 연구 기회로 보이는 지점
마지막에 "→ 본인 연구 주제를 알려주시면 더 구체적으로 연결해드릴 수 있습니다" 추가.}
요약 출력 후 사용자에게 물어볼지 판단:
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub baekdusan/lab-claude-tools --plugin research-toolkit