/kdh-research — Deep Research Command v3

Description

# /kdh-research — Deep Research Command v3 When the user invokes `/kdh-research [topic]`, execute a comprehensive, multi-source deep research operation. ## Core Directive - **Latest**: Reject sources older than 12 months for fast-moving topics (AI, frameworks). - **Accurate**: Cross-reference across 3+ sources before stating a claim as fact. - **Comprehensive**: Cover the topic from 7 different angles (Step 1). - **Verified**: Every claim in the report must have a source. No source = don't include it. - **Analyze-Ready**: Output format optimized for /kdh-analyze Stage 2 input. ## 입력 확인 (필수) 실행 전 반드시 출력: 1. 같은 세션 /kdh-discuss 결과 확인 → 논의 맥락 활용 2. _bmad-output/kdh-plans/ 에서 Glob "*-research-*.md" → 같은 주제 기존 research 확인 3. 기존 research 있으면 → CEO에게 "기존 [파일명] 있는데 새로 할까요?" 확인 ``` 입력: [discuss 맥락 유무] + [기존 research 유무] 핵심: [discuss 방향 1줄] 또는 "새 주제" ``` ## Execution Steps (Step 0~6) ### Step 0: Source Routing (검색원 라우팅) 주제 분류 후 적합한 검색원을 **먼저** 사용한다. "먼저" = 1순위로 시도, 결과 부족하면 2순위로 보충. 1순위 충분해도 교차 검증용 2순위 검색 최소 1회 실행. | 검색원 | 강점 | 사용 시점 | |--------|------|----------| | **Context7 MCP** | 공식 문서, 버전별 정확 | 라이브러리/프레임워크 관련 각도 | | **GitHub (gh CLI)** | 실제 구현체, 스타 수로 검증 | 코드 패턴/구현 관련 각도 | | **WebSearch** | 최신 트렌드, 블로그, 뉴스 | 일반 지식, 비교, 의견 | | **WebFetch** | 특정 URL 상세 분석 | Round 1/2에서 선별된 URL | **Context7 사용법:** 1. `resolve-library-id` — 라이브러리명으로 Context7 ID 조회 2. `query-docs` — 해당 ID로 문서 검색 폴백: Context7 실패(MCP 미응답, 라이브러리 미지원) → WebSearch 전환. 멈추지 말 것. **GitHub 검색:** ```bash gh search repos "{topic}" --stars=">500" --sort=stars --limit=5 gh search repos "{topic}" --sort=updated --limit=5 ``` 품질: stars > 500 = 검증됨, 100-500 = 참고, < 100 = 참조만. **학술 검색 (주제가 학술적일 때):** ``` WebSearch: "site:arxiv.org {topic} survey 2025 2026" ``` 품질: citations > 10 = 신뢰, 5-10 = 최근이면 OK, < 5 = 최근 아니면 제외. **패키지 레지스트리 (해당 시):** ``` WebSearch: "npmjs.com {package}" OR "pypi.org {package}" ``` ### Step 1: Query Decomposition (쿼리 분해) 주제를 **7 sub-queries**로 분해. 30초 생각: "이 주제의 다른 면은?" | # | Angle | Query Pattern | Purpose | |---|-------|--------------|---------| | 1 | Problem | "{topic} problem challenge bottleneck" | Why is this hard? | | 2 | Solutions | "{topic} solution pattern best practice 2026" | How do people solve it? | | 3 | Our Stack | "{our_tools} {topic} how to" | How does it apply to us? | | 4 | Implementations | "github {topic} implementation stars:>500" | Real code examples | | 5 | Research | "arxiv {topic} survey paper 2025 2026" | Academic grounding | | 6 | Official | "{vendor} official {topic} documentation guide" | Vendor/framework docs | | 7 | Production | "{topic} production experience lessons learned enterprise" | Real-world experience | ★ Step 0의 라우팅에 따라 각 angle의 1순위 검색원 선택. - Angle 4(Implementations) → GitHub 먼저 - Angle 6(Official) → Context7 먼저 - 나머지 → WebSearch ★ 7 WebSearch를 **single message에 병렬 호출**. ★ "2025 2026"을 최소 3개 쿼리에 포함. ### Step 2: Round 1 — Breadth (발견) 7 WebSearch + Step 0 결과에서: 1. **Top 5~8 URL 선별** — title + snippet relevance로 판단 2. **WebFetch 5~8개를 single message에 병렬 호출:** ★ 반드시 하나의 메시지에 여러 WebFetch를 동시 실행. 순차 호출 금지. ★ 각 WebFetch prompt: > "Extract: (1) specific findings with numbers/evidence, (2) what this source uniquely contributes, (3) claims without evidence. Be concrete." 3. **Extract learning** from each source: ``` Source: [Title](URL) | Date: YYYY-MM | Type: blog/paper/docs/repo Finding: {core discovery in 1-2 sentences} Evidence: {specific numbers, code, quotes} Gap: {what this source alone can't answer} ``` ### Step 3: Source Credibility (소스 신뢰도 평가) Round 1 각 소스에 대해 **3가지 질문**: | 질문 | 좋음 | 보통 | 나쁨 | |------|------|------|------| | **유형?** | 논문, 공식문서 | GitHub (500+), 알려진 테크블로그 | 포럼, 무명 블로그, 출처 불명 | | **최신?** | 6개월 이내 | 6~12개월 | 1년+ | | **근거?** | 숫자+코드 제시 | 숫자 또는 코드 중 하나 | 주장만, 근거 없음 | 판정: - 3개 다 좋음 → **HIGH** - 2개 좋음 → **MEDIUM** - 1개 이하 → **LOW** ★ 주제별 조정: - fast-moving (AI

Security Status