competitive-research

name	competitive-research
description	경쟁 제품·외부 프로젝트 비교 분석 시 검증 기준·출력 형식 지침 주입
triggers	["리서치해줘","비교해줘","차별점","경쟁사","hermes","openclaw","경쟁 제품","분석해줘","벤치마크"]

경쟁 제품 리서치 지침

사실 신뢰도 등급 표시 (의무)

리서치 결과를 작성할 때 모든 항목을 세 등급으로 구분해 표시한다. 혼용 금지.

등급	표기	사용 조건
확인됨	확인됨 — [출처]	공식 문서·README·changelog·코드에서 직접 확인
추론	추론 — 근거: [이유]	코드 구조·아키텍처에서 합리적으로 유추
미검증	~X (미검증, 출처 불분명)	수치·통계·기능 등 출처를 확인 못 한 경우

수치(토큰 수, 응답 시간, 사용자 수 등)는 반드시 출처를 병기하거나 "(미검증 추정)"으로 표기. 출처 없는 수치를 사실처럼 제시 금지.

체크리스트 — 경쟁 제품 리서치 4항목

리서치 대상 제품마다 아래 4항목을 순서대로 확인한다. 확인 못 한 항목은 "미확인" 명시.

1. 아키텍처: LLM API 직접 호출 vs CLI wrapper(claude/codex/aider 등) vs 혼합
2. 토큰 소모: 실제 측정치 vs 추정치 구분, 측정 조건(모델·컨텍스트 크기) 명시
3. 기능 목록: 공식 changelog/README 기준, 버전 명시 (날짜 기반이면 "확인 시점: YYYY-MM-DD" 표기)
4. 한계점: 공식 이슈트래커 또는 커뮤니티 피드백 기반, 출처 명시

WebFetch/WebSearch 선제 시도 원칙

사용자가 외부 공지·문서·블로그를 언급하면:

1. 먼저 WebSearch로 탐색 시도
2. 탐색 성공 시 → 내용 직접 확인 후 등급 표시
3. 탐색 실패 시 → 그때 사용자에게 URL 요청

"확인할 수 없다"고 먼저 말하기 전에 반드시 탐색을 시도할 것.

리서치 결과 재확인 기준

이미 제시한 리서치 결과라도 다음 경우 즉시 재확인:

• 사용자가 수치·사실에 의문 제기
• 아키텍처 분류가 실제와 다를 가능성 언급
• 새로운 공식 문서·URL 제공

재확인 후 달라진 내용은 "정정: ~" 형식으로 명시.