← ClaudeAtlas

light-researchlisted

deep-research보다 훨씬 적은 토큰·에이전트로 빠르게 조사하는 축소판 리서치 스킬. "가볍게 조사해줘", "간단히 찾아봐줘", "라이트 리서치", "축소 리서치", "딥리서치 말고 가볍게", "토큰 아껴서 조사해줘" 같은 표현이 나오면 반드시 사용한다. deep-research 워크플로우가 방금 세션/토큰 한도(rate limit)에 걸려 실패했을 때의 대안으로도 우선 고려한다. 주장별 3-vote 반박 검증 없이 "검색 각도별 조사 → 바로 종합" 2단계로 끝내 에이전트 수를 4~7개 수준으로 제한한다. 정확한 사실검증보다 빠른 개요·배경 파악이 목적일 때 적합하다. 반대로 인용 신뢰도를 반박 검증까지 해야 하는 무거운 리서치 요청이면 이 스킬 대신 deep-research를 쓴다.
gagip/gagip-dev · ★ 0 · Data & Documents · score 63
Install: claude install-skill gagip/gagip-dev
# Light Research 스킬 `deep-research`는 Scope → Search → Fetch → Verify(주장별 3-vote) → Synthesize의 5단계 구조라, 검증 단계에서 주장 수 × 3만큼 에이전트가 늘어나 100개를 넘기기도 한다. 개인 Pro 요금제 세션 한도로는 여기서 자주 막힌다. 이 스킬은 검증 단계를 아예 없애고 "검색 각도별 조사 → 종합" 2단계로 줄여, 보통 에이전트 4~7개(검색 3~5개 + 종합 1개) 안에서 끝낸다. 정확성보다 속도와 개요 파악이 목적인 리서치, 또는 방금 deep-research가 rate limit로 실패한 상황의 대안으로 쓴다. 논쟁적 사실관계(수치·날짜·인용문)를 반박 검증까지 해야 하는 주제라면 이 스킬로 시작하되, 결과를 보여줄 때 "검증 없이 조사한 결과이니 중요한 사실은 deep-research로 재확인하는 게 좋다"고 알려준다. ## 절차 ### 1. 계획서 제시 → 승인 후 실행 바로 실행하지 않는다. deep-research와 동일한 승인 원칙을 따르되, 계획서는 짧게: - **목적**: 무엇을 알아내려는지, 왜 필요한지 - **탐색 각도**: 주제를 2~4개의 겹치지 않는 각도로 분해 (예: 배경/핵심원칙/사례/평가) - **규모**: 검색 각도 수 + 종합 1개 = 예상 총 에이전트 수 (보통 4~7개) 사용자가 승인하면 다음 단계로 진행한다. 이미 이전 대화에서 관련 리서치(예: deep-research 부분 성공 결과)가 있다면, 계획서에 "기존 확보한 사실 N개를 재사용해 중복 검색을 줄인다"고 명시한다. ### 2. Workflow 실행 `references/light-research-template.js`를 읽고, 그 구조를 그대로 따라 `Workflow` 툴에 인라인 스크립트로 전달한다. 템플릿에서 바꿀 부분은 `ANGLES` 배열(탐색 각도별 프롬프트)과 synthesis ���롬프트의 출력 구조뿐이다. 핵심 설계 원칙 (템플릿에 이미 반영되어 있음): - **검증(verify) 단계 없음.** 대신 각 검색 에이전트 프롬프트에 "신뢰할 수 있는 출처(위키백과, 주요 언론, 1차 인터뷰 등) 위주로 찾고 URL을 반드시 남겨라"를 넣어 출처 품질을 1차로 거른다. - **Search와 Fetch를 합친다.** 별도 Fetch 단계 없이 검색 에이전트가 WebSearch+WebFetch를 스스로 조합해 `{fact, url}` 쌍을 바로 반환한다. deep-research는 Search/Fetch를 분리해 에이전트가 그만큼 더 든다 — 이 스킬은 그 분리를 없애 절반 이하로 줄인다. - **종합은 항상 1개 에이전트.** 병렬 검색 결과 전체를 한 번에 모아(barrier) 종합 프롬프트에 넣는다 — 검증이 없으니 파이프라인으로 분산할 필요가 없다. - **시드 재사용.** 이전 대화에 이미 나온 신뢰도 높은 사실이 있다면 synthesis 프롬프트에 `seedClaims`로 같이 넣어, 그만큼 검색 각도를 줄이거나 검