Skip to main content

agent-research

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

ソース情報

リポジトリ
revfactory/skills
ソースの最終更新活動
2026年4月12日 04:07
検出された SKILL.md の言語
韓国語
スター
160
フォーク
45

インストール方法

デフォルトでは、最初にソースを確認する 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で見る