Community연구 & 데이터 분석github.com

research-plan

"연구 및 계획 X" 요청에 사용합니다. 먼저 소스 접근성을 평가하고, 실제로 읽은 내용만 바탕으로 계획을 수립하며, plan.md와 주제별로 분류된 소스 파일을 작성합니다. 다운로드 후 재실행하여 업데이트합니다.

research-plan란 무엇인가요?

이 스킬은 AI 에이전트가 체계적인 문헌 조사 및 연구 계획을 수행할 수 있도록 설계된 오케스트레이터입니다. 'research-plan'은 세 가지 스킬(소스 분류, 연구 계획 수립, 증거 검증)로 구성된 제품군의 핵심으로, 사용자가 'X에 대해 조사하고 계획을 세워줘'라는 요청을 할 때 실행됩니다. 주요 기능은 다음과 같습니다: 먼저 `source-triage` 스킬을 통해 접근 가능한 소스와 차단된 소스를 식별한 후, 실제로 읽을 수 있는 소스만 엄격히 사용하여 plan.md와 소스 파일을 생성합니다. 깊이(depth) 모드(quick, deep, update)를 지원하며, 주제를 3-6 단어로 슬러그화하여 파일을 저장합니다. 모든 주장은 원본 텍스트에서 직접 인용하여 검증 가능하도록 하며, `claims.json`에 저장합니다. 마지막으로 `evidence-check` 스킬을 통해 독립적 감사를 수행하여 모든 주장이 실제 근거에 기반했는지 확인합니다. Claude Code, Cursor, Codex 등 다양한 AI 코딩 에이전트 플랫폼에서 사용할 수 있습니다.

지원 대상~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Pushkar1-GitHub/D2D_Meta_Skills/tree/HEAD/skills/research-plan

Installed? Explore more 연구 & 데이터 분석 skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

Research → plan.md + 소스 파일

세 가지 스킬로 구성된 제품군의 오케스트레이터:

  • source-triage: 소스를 찾고, 읽기 전에 접근성, 도달 가능성, 무결성 및 등급을 분류합니다.
  • research-plan (이 스킬): 도달 가능한 소스를 읽은 후, 계획과 소스 파일을 작성합니다.
  • evidence-check: 모든 주장이 실제이고 뒷받침되는지 확인하는 독립적 감사입니다.

형제 스킬이 없으면 이 요약의 단계를 인라인으로 수행하세요. 결정론적 검사기는 이 스킬 내부에 포함되어 있습니다: python3 <이 스킬 폴더>/scripts/research_checks.py. 표준 라이브러리 Python으로, 자체 코드 샌드박스에서 실행됩니다(PDF 텍스트는 pypdf 필요; 없으면 pip install pypdf). 결정론적 검사가 명명된 곳마다 사용하세요. 코드 실행이 불가능한 경우에만 수동으로 검사를 수행하고 그 사실을 명시하세요.

출력물 (고정 이름)

research/<topic-slug>/plan.md
research/<topic-slug>/sources__<topic-slug>__<YYYY-MM-DD>.md   ← 사람이 보기 위한 파일
research/<topic-slug>/ledger.md                                ← 작업 상태, 진행하면서 작성
research/<topic-slug>/notes/<citekey>.md                       ← 소스별 노트
research/<topic-slug>/notes/raw/<citekey>.txt                  ← 원본 전체 텍스트 (API XML/PDF 텍스트), 문자 그대로 보관
research/<topic-slug>/claims.json                              ← 지원되는 주장 + 인용문, 확인용
  • <topic-slug>: 3–6개의 구체적인 단어, 소문자-하이픈으로 연결 (starch-fructan-engineering-plants).
  • 이전 실행을 덮어쓰지 마세요. 동일 주제: 새 날짜의 소스 파일 + 변경 로그 항목. 새로운 관점: 새 슬러그.
  • 사용자의 연결된 폴더가 있으면 그곳에서, 없으면 작업 디렉토리에서 작업하세요. 마지막에 두 주요 파일을 모두 전송하세요.

모드

  • auto (기본값): 중단 없음; 마지막에 선택 사항을 나열하세요. step: 각 ◆에서 중단.
  • quick: 8–15개 소스 유지. 상위 5개 소스는 전체 읽기; 나머지는 sections: (초록 + 결과 + 논의). 반증: 최대 3회 검색. 눈덩이식 검색은 선택 사항.
  • deep: 25개 이상 소스, 눈덩이식 검색, 병렬 스카우트, 모든 A/B 소스 전체 읽기.
  • update: 사용자가 파일을 다운로드했거나 새로고침을 요청 → 6단계.
  • 요청의 하드 제약 조건 (2권의 책 장, 단어 제한, 필수 데이터베이스가 필요한 루브릭)은 요구사항이지 제안이 아닙니다. 검증된 소스로 충족시키거나, 충족되지 않은 사항을 명확히 말하세요.

0단계 — 프레임(Frame)

한 번의 메시지:

  • 계획의 목표와 용도 (에이전트 / 스킬 / MCP / 보고서 / 실험 / 의사 결정);
  • 범위, 연도, 깊이 및 모드;
  • 하드 제약 조건;
  • 2–6개의 MECE 축 (겹치지 않는 하위 질문).

작업 목록 생성: 프레임(Frame) → 분류(Triage) → 읽기(Read) → 종합(Synthesize) → 쓰기(Write) → 확인(Check). 작업 도구가 없으면 research/<slug>/run-notes.md 상단에 목록을 유지하세요. ◆ 체크포인트: 축 + 범위.

1단계 — 분류 (source-triage 실행)

도서관 먼저 → 발견 → 명명할 모든 항목의 무결성 확인 → 접근성 + 도달 가능성 → 등급 / 역할 / ⭐.

원장(ledger)은 진행하면서 작성됩니다. 각 검색과 분류된 각 소스를 즉시 추가하세요; 컨텍스트가 실행 중간에 손실될 수 있으며, 원장 파일이 유일하게 살아남는 정보입니다.

하위 에이전트가 있는 딥 모드에서는 축당 하나의 스카우트를 병렬로 보내세요. 각 스카우트:

  • ≤15회의 도구 호출 사용;
  • notes/<axis>.md 작성, 섹션: 주요 결과(Takeaway) · 인용된 발견(링크 포함) · 추론(Inferences) · 공백(Gaps);
  • 후보를 원장에 추가.

하위 에이전트가 없으면 축을 순차적으로 실행하세요. ◆ 체크포인트: 접근성 클래스별 개수 + ⭐ 후보 목록.

2단계 — 읽기

  • readable/held 소스를 가장 높은 등급부터 읽으세요. 원시(RAW) 경로(셸을 통한 Europe PMC XML, PDF 텍스트)를 선호하고 텍스트를 notes/raw/<citekey>.txt에 저장하세요.
  • WebFetch 읽기는 read: full (extracted)입니다. 이해를 위해 사용하지만, 이에 의존하는 주장은 ⚠ extracted를 받고 인용문으로 "지원"되지 않습니다.
  • 긴 텍스트의 경우 참고 문헌 목록에 도달할 때까지 청크 단위로 읽으세요. 빠른 모드에서는 sections: 읽기를 허용합니다; 레이블을 붙이세요.
  • 각 원장 행에 read 설정: full · sections:<which> · abstract · metadata.
  • 소스별로 notes/<citekey>.md에는 다음이 포함됩니다:
    • WHY (문제);
    • HOW (방법, 데이터);
    • WHAT (발견: 숫자를 정확히 복사, 섹션/페이지 위치 포함);
    • LIMITS, 각각 author-stated (위치 포함) 또는 my-inference로 태그. 전체 텍스트 없음: limits: not assessed (read: abstract).
  • 계획에서 주장을 담을 문장이 있을 때, 원시 텍스트에서 ≥40자의 축어적 인용문을 claims.json에 복사하세요: {"id","claim","source":"notes/raw/<citekey>.txt","quote","locator"}.
  • 기억에 의존하여 노트를 채우지 마세요. "내가 읽은 부분에는 없습니다"는 유효한 답변입니다.

3단계 — 종합

  • 증거 매트릭스: 소스 × 주제 (지지 / 반박 / 침묵). 소스별이 아닌 주제별로 그룹화하세요.
  • 수렴 (≥3 동의) · 발산 (방법, 모집단 또는 시간으로 설명) · 침묵 (<2 소스: 공백).
  • 독립성 개수: "4개 연구 (2개 독립적)". 공유 데이터 세트, 코호트, 팀 또는 시험은 한 번만 계산합니다.
  • 반증 검토: 주요 발견에 대해 널, 실패한 재현 및 비판을 검색하세요. 아무것도 나오지 않더라도 검색어를 기록하세요. 빠른 모드: 최대 3회 검색.
  • 부정적 주장 ("아무도 X를 하지 않았다")은 검색된 범위 내에서 그 뒤에 수행된 검색을 수반합니다.
  • 기여도 확인: 사용자가 이 계획으로 이전에 할 수 없었던 것은 무엇인가? 어떤 ⭐ 다운로드가 가장 큰 변화를 가져올까?
  • 악마의 대변인 검토: 가장 강력한 반론, 체리 피킹, 그리고 의심되지 않은 전제. 불편하다고 해서 반론을 버리지 마세요.

4단계 — 파일 작성

plan.md

  • 헤더: 목표 · 용도 · 범위 · 날짜 · 소스 파일 링크 · 증거 기반: N 전체(원시) · N 전체(추출) · N 섹션 · N 초록 · N 메타데이터.
  • 본문: 요청에 필요한 모든 것.
  • 인용: <sup>[3](sources__<slug>__<date>.md#s3)</sup>, 처음 사용된 순서로 번호 지정.
  • 인용 후 플래그:
    • ⚠ 초록 전용: 초록만 읽음;
    • ⚠ 메타데이터 전용: 제목/발행처만 알려짐;
    • ⚠ 추출됨: WebFetch를 통해 읽었으므로 축어적 확인 불가능;
    • ⚠ 사전 인쇄본.
  • 마무리: 미해결 질문 · ⭐ 다운로드가 가능하게 할 것 · 충족되지 않은 제약 조건 (있는 경우) · 변경 로그.

sources____.md

# 소스 — <읽기 쉬운 주제 제목> (<날짜>)
계획: [plan.md](./plan.md) · 질문: <한 줄> · 모드: <quick|deep> · 검색: <데이터베이스 + 날짜>
개수: N 전체 · ⭐ X · 읽기 가능 R · 무료지만 차단 B · 유료 P · 비논문 W · 제외 E     (전체 = 모든 원장 행)
증거 기반: <plan.md와 동일한 분석>

## ⭐ 1. 로컬 컨텍스트를 위해 다운로드하세요
| # | 소스 | 유형 | 등급 | 접근성 · 라이선스 | <구축 대상>에 중요한 이유 | 획득 방법 | 저장 이름 | 재배포 |

## 2. 공개 및 읽기 가능 (계획에 요약됨)
### <주제 A>
<a id="s1"></a>**[1]** 저자 (연도). [제목](URL). *저널 / 책 제목, 페이지*. [DOI](https://doi.org/…) — `gold · CC-BY` · `readable:europepmc-xml` · read: full · 등급 A · 증거
(사전 인쇄본은 이 줄에 `` `preprint` `` 레이블을 추가합니다; 그러면 검사기는 해당 인용에 `⚠ preprint`를 요구합니다)
- WHY … · HOW … · WHAT … · LIMITS …

## 3. AI 에이전트에게는 무료이지만 차단됨 (직접 열어보세요)
항목 + 관찰된 차단 + 직접 링크 + 그린 카피.

## 4. 유료
항목 + 그린 카피 링크 또는 "찾을 수 없음" + 사용된 경우 초록 수준의 요점.

## 5. 비논문 소스
종류별, 계층 T1–T5. 회색 문헌: URL + 접속 날짜 + 스냅샷 링크.

## 6. 제외됨 (그리고 이유)
제외된 각 레코드당 한 줄, **제외됨:** <이유>로 시작.

## 7. 검색 로그 및 접근 경로 보고서

규칙:

  • 모든 항목에는 계획의 번호와 일치하는 <a id="sN"> 앵커가 있습니다.
  • 모든 URL은 헤더 줄을 포함하여 [텍스트](URL) 링크입니다.
  • ⭐ 행은 주요 항목 번호를 가리킵니다.
  • 접근성 클래스별로, 그런 다음 주제별로 그룹화하세요.

5단계 — 확인 후 전달

  1. 결정론적 검사: python3 <이 스킬 폴더>/scripts/research_checks.py all research/<slug>/를 실행하세요. 모든 오류(누락된 앵커, 누락된 ⚠ 플래그, 개수 불일치, 어휘, 소스에 없는 인용문)를 수정하고 통과할 때까지 다시 실행하세요.
  2. 증거 확인: evidence-check를 실행하세요.
    • 하위 에이전트 사용: 새 에이전트에서 파일만 제공받아 실행.
    • 사용하지 않음: 동일 세션 검사로, 모든 파일을 디스크에서 다시 읽고 작성에 대한 기억을 사용하지 않습니다. same-session (not independent)로 레이블을 붙이고 사용자에게 의존하기 전에 새 채팅에서 evidence-check를 실행하도록 제안하세요.
  3. 접근성 클래스별로 3개 링크를 스팟 오픈하세요. 게시자의 403/429는 아무것도 증명하지 않습니다; 그렇게 말하세요.

한 줄로 두 파일을 전달하세요:

  • 계획의 헤드라인;
  • ⭐ 개수;
  • 수동 다운로드가 필요한 소스 수;
  • 충족되지 않은 제약 조건.

자동 모드에서는 선택 사항(축, 연도, 데이터베이스, 필터, 상한)도 나열하세요.

6단계 — 업데이트 (사용자 다운로드 후)

  1. 폴더의 파일을 저장 이름(Save-as names)과 일치시키세요.
  2. 검증하세요 (python3 <이 스킬 폴더>/scripts/research_checks.py pdf <files>).
  3. 각 파일을 읽고, 원시 텍스트를 저장한 후 held: user 및 read: full로 설정하세요.
  4. 등급을 다시 매기고, 잠정적인 ? 등급을 제거하세요.
  5. ⚠ 플래그를 인용문이 있는 지원되는 주장으로 전환하거나 새 텍스트가 모순되는 주장을 다시 작성하세요.
  6. 변경된 섹션에 대해 5단계를 다시 실행하세요.
  7. 새 날짜의 소스 파일을 작성하고 변경 로그 항목을 추가하세요.

위험 신호

생각현실
"읽은 후에 접근성을 확인하겠다"먼저 분류하세요. 그렇지 않으면 유료 초록이 계획에 조용히 영향을 미칩니다.
"OA니까 읽을 수 있다"경로를 테스트하세요. OA 기사도 테스트에서 차단되었습니다.
"WebFetch가 텍스트를 줬다"모델의 추출 결과를 준 것입니다. 읽기에는 사용하되, 인용에는 절대 사용하지 마세요.
"이 논문/장을 알고 있다"시험에서 기억으로 잘못된 제목, 잘못된 책, 존재하지 않는 논문을 생성했습니다. 먼저 확인하세요.
"DOI가 확인되므로 장이 맞다"책 제목과 페이지도 확인하세요.
"차단됐다, 미러를 시도해보겠다"절대 안 됩니다. 합법적인 그린 카피를 찾거나, 사용자에게 목록으로 제공하세요.
"마지막에 원장을 작성하겠다"컨텍스트 재설정으로 사라집니다. 진행하면서 작성하세요.
"세 연구가 동의한다"독립적인 연구를 세어보고, 반대 방향으로 간 연구를 검색하세요.

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

관련 스킬