Skip to main content

agent-research

에이전트 팀을 구성하여 종합 리서치 보고서를 작성하는 스킬. 조사 대상을 분석하여 전문가 풀에서 최적의 에이전트를 동적으로 선택·구성한다. (1) '조사해줘', '리서치해줘', '보고서 작성해줘' 요청 시, (2) '~기업 분석해줘', '~회사 조사해줘' 요청 시, (3) '~사람 조사해줘', '~인물 분석해줘', '~에 대해 알려줘' 요청 시, (4) 미디어 반응, 커뮤니티 의견, 경쟁 환경 등을 종합적으로 파악해야 할 때, (5) '에이전트 팀으로 조사', '팀 리서치' 요청 시, (6) 영상 스크립트, 기사, 보도자료 등을 바탕으로 배경 조사가 필요할 때.

소스 정보

저장소
revfactory/skills
최근 소스 활동
2026년 4월 12일 04:07
감지된 SKILL.md 언어
한국어
스타
161
포크
48

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
agent-research
description
에이전트 팀을 구성하여 종합 리서치 보고서를 작성하는 스킬. 조사 대상을 분석하여 전문가 풀에서 최적의 에이전트를 동적으로 선택·구성한다. (1) '조사해줘', '리서치해줘', '보고서 작성해줘' 요청 시, (2) '~기업 분석해줘', '~회사 조사해줘' 요청 시, (3) '~사람 조사해줘', '~인물 분석해줘', '~에 대해 알려줘' 요청 시, (4) 미디어 반응, 커뮤니티 의견, 경쟁 환경 등을 종합적으로 파악해야 할 때, (5) '에이전트 팀으로 조사', '팀 리서치' 요청 시, (6) 영상 스크립트, 기사, 보도자료 등을 바탕으로 배경 조사가 필요할 때.
# Agent Research 에이전트 팀 기반 종합 리서치 스킬. 조사 대상의 성격을 분석하여 **전문가 풀에서 최적의 에이전트를 동적으로 선택**하고, 교차 검증을 거쳐 분석적 종합 보고서를 산출한다. ## 실행 모드: 에이전트 팀 ## 전문가 풀 리더는 아래 11개 전문가 중에서 조사 대상에 맞는 **2~6개**를 선택한다. | ID | 전문가 | 조사 영역 | 적합한 대상 | |----|--------|----------|------------| | `official` | 공식 정보 조사관 | 공식 문서, 1차 소스, 기술 문서, GitHub, API | 기술/제품/서비스/기업/정책 | | `media` | 미디어 분석관 | 미디어 보도, 기사, 영상 콘텐츠, 인터뷰 | 거의 모든 대상 | | `community` | 커뮤니티 분석관 | Reddit, HN, Twitter, 포럼, 블로그 | 기술/제품/인물/논란 | | `academic` | 학술 연구관 | 논문, 학회, 연구 트렌드 | 기술/과학/의료/인물(학자) | | `financial` | 재무 분석관 | 재무제표, 투자, 밸류에이션, 주가 | 기업/산업/경제 이슈 | | `industry` | 산업·경쟁 분석관 | 시장 규모, 경쟁사, SWOT, 트렌드 | 기업/제품/산업 | | `reputation` | 평판 조사관 | 고객 리뷰, 직원 평판, 여론, 논란 | 기업/제품/인물 | | `career` | 경력·배경 조사관 | 학력, 경력, 인적 네트워크 | 인물 | | `works` | 업적·저작 조사관 | 논문, 특허, 수상, 프로젝트 성과 | 인물(학자/창업자/개발자) | | `technical` | 기술 심층 분석관 | 아키텍처, 벤치마크, 코드, 성능, 보안 | 기술/제품/오픈소스 | | `policy` | 규제·정책 분석관 | 법률, 규제, 정책, 윤리, 컴플라이언스 | 산업/기술/사회 이슈 | 프롬프트 템플릿: [references/agent-prompts.md](references/agent-prompts.md) ## 조사 깊이 선택 | 깊이 | 트리거 | 에이전트 수 | 검색 횟수/에이전트 | 특징 | |------|--------|-----------|-------------------|------| | **quick** | `간단히`, `빠르게`, `요약`, `개요` | 2~3개 | 5~8회 | 핵심 정보만. 교차 검증·보충 생략 | | **standard** (기본) | 미지정 | 3~4개 | 10~15회 | 기본 조사 + 교차 검증 + 선택적 보충 | | **deep** | `심층`, `깊이`, `상세히`, `철저히` | 4~6개 | 15~25회 | 다단계 검색 + 교차 검증 + 필수 보충 + 1차 소스 추적 | ## 워크플로우 ### Phase 1: 대상 분석 및 팀 설계 이 Phase가 핵심이다. 리더가 조사 대상을 분석하여 최적의 팀을 구성한다. **1단계: 대상 파악** 1. 사용자 입력에서 **조사 대상**, **조사 깊이**, **출력 경로**, **조사 기간** 파악 2. 입력이 파일이면 읽어서 주제 추출, 텍스트면 그대로 사용 3. **핵심 키워드 3~5개** 도출 **2단계: 조사 차원 식별** 조사 대상의 성격에 따라 어떤 차원의 조사가 필요한지 판단한다: | 대상 성격 | 필수 차원 | 선택 차원 | |----------|----------|----------| | AI 신기술 | official, technical | media, community, academic | | 상장 기업 | official, financial, industry | reputation, media | | 스타트업 | official, financial | industry, media, reputation | | 학자/연구자 | career, works, academic | media, influence→reputation | | CEO/창업자 | career, works | media, reputation, financial | | 정치인/공인 | career, media | reputation, policy | | 규제/정책 이슈 | policy, official | media, community, industry | | 오픈소스 프로젝트 | official, technical, community | media, academic | | 사회적 논란 | media, community | policy, reputation, official | | 제품/서비스 | official, technical | media, community, industry | > 위 표는 **가이드라인**이다. 리더는 대상의 고유한 특성을 분석하여 자유롭게 조합한다. > 사용자가 특정 관점을 명시적으로 요청한 경우 (예: "재무 중심으로", "커뮤니티 반응 위주로") 해당 전문가를 반드시 포함한다. **`media` 전문가 포함 판단 기준:** `media`를 제외하면 미디어 보도 수집이 다른 에이전트에 분산되어 깊이가 얕아질 수 있다. 다음 경우 `media`를 반드시 포함한다: - 대상이 **대중적 관심이 높은 이슈** (광범위한 미디어 보도 예상) - **미디어 논조 분석**(호의적/비판적 분류)이 보고서 핵심일 때 - **영상 콘텐츠**(YouTube, 팟캐스트) 분석이 필요할 때 - 에이전트 수 예산에 여유가 있을 때 (4개 이상) `media` 제외 시: `official`(공식 보도), `community`(여론/반응), `reputation`(평판 보도)이 미디어 영역을 분담. 단, **미디어 보도의 논조 분석 깊이는 떨어짐**을 인지. **3단계: 팀 구성 결정** 깊이에 따라 에이전트 수를 결정하고, 전문가 풀에서 선택한다: ``` 선택 기준: 1. 조사 대상에 필수적인 차원의 전문가를 먼저 선택 2. 깊이 예산 내에서 선택 차원의 전문가를 추가 3. 전문가 간 시너지를 고려 (예: financial + industry는 상호 보완적) 4. 사용자가 명시적으로 요청한 관점이 있으면 반드시 포함 ``` **결정 사항 기록** (리더가 팀 구성 근거를 `_workspace/team_design.md`에 기록): ```markdown # 팀 설계 ## 조사 대상: {target} ## 핵심 키워드: {keywords} ## 조사 깊이: {depth} ## 조사 기간: {time_range} ## 선택된 전문가 ({N}명) | # | 전문가 | 선택 이유 | |---|--------|----------| | 1 | {specialist} | {이 전문가가 필요한 이유} | | 2 | {specialist} | {이 전문가가 필요한 이유} | | ... | ... | ... | ## 제외된 전문가 (해당 시) | 전문가 | 제외 이유 | |--------|----------| | {specialist} | {불필요한 이유} | ## 보고서 구조 (예상) {선택된 전문가에 기반한 보고서 섹션 구조} ``` **4단계: 조사 기간 결정** (사용자 미지정 시 기본 3개월): | 옵션 | 기간 | 적용 시점 | |------|------|----------| | `최신` / `긴급` / `1주` | 최근 1주일 이내 | 방금 발표된 뉴스, 핫이슈 | | `최근` / `1달` | 최근 1개월 이내 | 비교적 최신 동향 | | 기본값 (미지정) | 최근 3개월 이내 | 일반적인 리서치 | ### Phase 2: 팀 구성 및 병렬 조사 시작 **1단계: TeamCreate로 팀 생성 + 팀원 스폰** ``` TeamCreate( team_name: "research-{slug}", members: [ { name: "{specialist-1}-researcher", agent_type: "general-purpose", model: "opus", prompt: // references/agent-prompts.md 템플릿을 커스터마이즈 (아래 규칙 참조) }, { name: "{specialist-2}-researcher", agent_type: "general-purpose", model: "opus", prompt: // ... }, // ... N개 팀원 ] ) ``` > TeamCreate 호출 시 모든 팀원이 즉시 스폰된다. 별도로 에이전트를 개별 실행할 필요 없다. **2단계: TaskCreate로 작업 등록** ``` TaskCreate(tasks: [ { title: "{specialist-1} 조사", description: "{조사 지시}", assignee: "{specialist-1}-researcher" }, { title: "{specialist-2} 조사", description: "{조사 지시}", assignee: "{specialist-2}-researcher" }, // ... N개 조사 태스크 { title: "교차 검증", description: "리더가 수행", assignee: "leader", depends_on: ["조사 태스크 전체"] }, { title: "종합 보고서", description: "리더가 수행", assignee: "leader", depends_on: ["교차 검증"] } ]) ``` > 팀원들은 자신에게 할당된 태스크를 자동으로 수행하고, 완료 시 TaskUpdate로 상태를 갱신한다. **프롬프트 커스터마이즈 규칙:** - references/agent-prompts.md의 해당 전문가 기본 템플릿을 가져온다 - `{target}` 변수를 조사 대상으로 치환 - `{keywords}` 변수를 핵심 키워드로 치환 - `{teammate_list}`를 실제 선택된 팀원 목록으로 치환 - **교차 공유 트리거**를 실제 팀원 구성에 맞게 조정 (없는 팀원에게 공유하도록 되어 있으면 가장 가까운 역할의 팀원으로 대체하거나, 없으면 리더에게 공유) - 대상 특성에 맞는 **추가 조사 지시**를 프롬프트에 삽입 ### Phase 3: 리더 모니터링 및 팀 조율 TeamCreate 후 팀원들은 자율적으로 조사를 수행한다. 리더는 다음을 수행: **모니터링:** - `TaskGet`으로 전체 태스크 진행 상황 확인 - 팀원이 유휴 상태가 되면 자동 알림 수신 - 특정 팀원이 막혔다는 SendMessage를 보내면 키워드 제안 등으로 지원 **개입이 필요한 상황:** - 팀원이 조사 범위 확장을 요청 → 승인/거부 판단 - 상충 정보가 교차 공유됨 → Phase 4에서 해결할 것을 메모 - 팀원이 에러로 중지 → 1회 재시도 또는 나머지 결과로 진행 결정 모든 팀원 공통 행동: - `general-purpose` 타입 (WebSearch, WebFetch 필요) - **교차 공유 의무**: 조사 중 다른 팀원에게 유용한 정보 발견 시 `SendMessage`로 즉시 공유 - 완료 시 `TaskUpdate`로 태스크 완료 처리 + `SendMessage`로 리더에 보고 #### 에이전트 간 교차 공유 프로토콜 에이전트들은 조사 중 다음 상황에서 다른 팀원에게 `SendMessage`로 정보를 공유한다: | 발견 상황 | 공유 행동 | |----------|----------| | 다른 팀원 전문 영역의 중요 정보 발견 | 해당 팀원에게 직접 공유 | | **상충 정보** 발견 | 관련 팀원 + 리더에게 공유 | | 새로운 핵심 키워드/인물/조직 발견 | 전체 팀원에게 공유 | | 조사 범위 확장이 필요한 영역 발견 | 리더에게 보고 (보충 조사 판단용) | **SendMessage 형식:** ``` [교차공유] {발견 유형}: {핵심 내용} (출처: {URL}) → {수신자}에게 권장 행동: {추가 조사 방향} ``` **교차 공유 수신 시 의무:** - 다른 팀원으로부터 교차 공유를 수신한 에이전트는 해당 정보가 자신의 조사 방향에 영향을 미쳤는지 기록해야 한다 - 조사 결과 파일의 `## 교차 공유 로그` 섹션에 **수신한 공유 + 이에 따른 조사 방향 변경**을 기록: ``` | 수신 | 발신자 | 내용 | 조사 방향 변경 | |------|--------|------|---------------| | 예 | {sender} | {내용} | {변경 사항 또는 "영향 없음"} | ``` - 이 기록은 Phase 4 교차 검증에서 에이전트 간 협업 효과를 평가하는 데 사용 ### Phase 4: 교차 검증 (quick 모드에서는 생략) 모든 에이전트 조사 완료 후, 리더가 직접 수행: 1. N개 조사 파일을 `Read`로 읽기 2. **상충 정보 식별**: 에이전트 간 모순되는 정보를 추출 3. **검증 조사**: 상충 정보에 대해 리더가 직접 WebSearch로 추가 검증 (최대 3건) 4. **신뢰도 판정**: 각 상충 정보에 대해 어느 쪽이 더 신뢰할 수 있는지 판정하되, 판정 불가 시 양론 병기 5. 검증 결과를 `_workspace/cross_validation.md`에 기록 **상충 정보 해결 우선순위:** 1. 1차 소스 (공식 문서, 당사자 발언, 원본 데이터) > 2차 소스 (미디어 보도, 분석) 2. 최신 정보 > 오래된 정보 3. 다수 소스 일치 > 단일 소스 4. 해결 불가 시: 양론 병기 + 각 출처 명시 ### Phase 5: 갭 분석 및 보충 조사 (quick 모드에서는 생략) 교차 검증 결과를 바탕으로 **갭 분석은 standard/deep 모두 필수** 수행: **5-1. 갭 분석 (standard/deep 필수)** 1. **정보 갭 식별**: 보고서 예상 구조의 각 섹션에 대해 다음 체크리스트로 평가: - [ ] 해당 섹션에 1차 소스가 1개 이상 있는가? - [ ] 핵심 수치/주장이 2개 이상 소스에서 확인되었는가? - [ ] 반대 관점/리스크가 포함되었는가? 2. **갭 목록 작성**: 부족한 영역을 심각도 순으로 정렬 (최대 3개) 3. **갭 분석 결과를 `_workspace/cross_validation.md`에 추가 기록** **5-2. 보충 에이전트 실행 (조건부)** | 모드 | 보충 에이전트 실행 조건 | |------|----------------------| | standard | 갭 심각도 "높음" (핵심 섹션에 데이터 부재)인 경우에만 | | deep | 갭 목록이 1개 이상이면 항상 실행 | - 보충 에이전트는 **서브 에이전트**로 실행한다 (팀원 간 통신 불필요, 결과 전달만 필요하므로) - `Agent(subagent_type: "general-purpose", model: "opus", run_in_background: true)` 로 1~2개 실행 - 전문가 풀에서 추가 전문가를 선택하거나, 이미 투입된 전문가의 범위를 좁힌 보충 조사도 가능 - 보충 결과를 `_workspace/supplement_{area}.md`에 저장 ### Phase 6: 종합 보고서 작성 모든 조사 + 검증 + 보충 완료 후: 1. 전체 조사 파일 + 교차 검증 결과를 `Read`로 읽기 2. **보고서 구조를 동적으로 설계**: 선택된 전문가와 수집된 데이터에 기반하여 보고서 섹션을 구성 #### 보고서 구조 동적 생성 규칙 보고서 구조는 고정이 아니라, 다음 원칙에 따라 동적으로 결정한다: ``` 1. 핵심 요약 (Executive Summary) — 항상 포함 2. 개요/배경 — 항상 포함 3. [선택된 전문가별 핵심 섹션] — 각 전문가의 조사 결과에서 도출 4. 교차 분석 — 에이전트 간 교차 발견 패턴 5. 결론 및 전망 — 항상 포함 6. 참고 자료 — 항상 포함 부록 A: 교차 검증 결과 부록 B: 정보 갭 및 한계 ``` **전문가별 → 보고서 섹션 매핑 가이드:** | 전문가 | 보고서 섹션 후보 | |--------|----------------| | `official` | 공식 개요, 기술 구조, 연혁/타임라인 | | `media` | 미디어 보도 분석, 전문가 평가 | | `community` | 커뮤니티 반응, 여론 분석, 주요 논쟁점 | | `academic` | 관련 학술 연구, 이론적 배경 | | `financial` | 재무 현황, 투자/펀딩, 비즈니스 모델 | | `industry` | 산업 환경, 경쟁 분석, SWOT, 시장 전망 | | `reputation` | 평판 분석, 고객/직원 리뷰, 논란/이슈 | | `career` | 인물 개요, 학력 및 경력, 인적 네트워크 | | `works` | 주요 업적, 학술 논문, 저작/특허 | | `technical` | 기술 심층 분석, 아키텍처, 성능/벤치마크 | | `policy` | 규제 환경, 법적 리스크, 정책 동향 | > 리더는 위 매핑을 참고하되, 수집된 데이터의 실제 분량과 중요도에 따라 섹션을 병합하거나 세분화한다. #### 분석적 종합 프레임워크 보고서의 각 섹션은 다음 3층 구조를 **가이드라인으로** 따른다: | 층 | 내용 | 비중 | |----|------|------| | **사실 층** | 검증된 팩트, 데이터, 인용 (출처 명시) | 50% |
GitHub에서 보기
이 SKILL.md는 매우 커서 SkillsMP가 여기에는 첫 섹션만 미리 보여줍니다. GitHub에서 보기