Community연구 & 데이터 분석github.com

아이디어 체크

제품 또는 스타트업 아이디어를 종단 간 검증하고, 선행 기술, 인접 기업, 실패 사례, 구매자 경제성, 상품화 한계를 포함한 연구 기반 시장 조사 보고서를 반환합니다. 사용자가 아이디어의 존재 여부, 실현 가능성, 경쟁사, 시장 조사를 요청할 때 사용합니다.

아이디어 체크란 무엇인가요?

이 스킬은 사용자가 제품이나 스타트업 아이디어에 대해 질문할 때 (예: '이미 있는 건가요?', '이거 될까요?', '누가 해봤나요?') 포괄적인 시장 조사 보고서를 생성합니다. 아이디어의 존재 여부에 대한 단순한 판단을 내리는 대신, 선행 기술(기존 제품, GitHub 저장소, 특허, 학술 논문), 인접 기업(아이디어를 기능으로 포함할 수 있는 대기업), 실패 사례(파산, 저가 인수, 피벗), 구매자 경제성(실제 구매자와 지불 의사), 그리고 상품화 한계(무료 오픈소스 또는 AI 모델이 이미 제공하는 기능)를 조사합니다. 네 가지 병렬 서브에이전트가 각각 조사하고, 세 번의 독립적인 시장 판독(개방형, 혼잡형, 포화형)을 거쳐 종합 보고서를 작성합니다. 이 스킬은 Claude Code에 최적화되어 있으며, 결과는 마크다운 파일과 대화 요약으로 제공됩니다.

지원 대상✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/sakzgupzzz/idea-check/tree/HEAD

Installed? Explore more 연구 & 데이터 분석 skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

아이디어 체크 (idea-check)

아이디어를 종단 간 조사하고 시장 조사 보고서를 반환합니다. 아이디어의 성공 여부에 대한 판단을 반환하지 마십시오. 증거와 아이디어가 살아남을 수 있는 조건을 반환합니다.

시작하기 전에

이해한 대로 아이디어를 한 문단으로 다시 설명하고, 사용자에게 조사를 시작한다고 알립니다. 확인을 기다리지 마십시오. 재진술은 보고서에도 포함되므로 사용자가 양쪽 방향으로 오독을 잡을 수 있습니다. 모호성이 어떤 시장을 조사할지 변경하는 경우에만 먼저 질문을 하나 하십시오 (예: "법률가를 위한 AI"는 계약 검토 또는 소송 증거 개시를 의미할 수 있으며, 이들은 서로 다른 기존 업체와 실패 사례를 가집니다).

엔터티 유형을 선택하십시오: 소프트웨어 제품, 하드웨어 제품, 서비스, 연구 방향, 또는 콘텐츠. 이에 따라 중요한 출처가 달라집니다. 소프트웨어는 패키지 레지스트리와 GitHub에 의존하고, 하드웨어는 특허에, 서비스는 지역 시장 및 노동 데이터에, 연구는 논문과 프리프린트에 의존합니다.

그런 다음 이전 실행을 확인하십시오. 스킬 디렉토리에서 checks/를 나열하고 주제가 관련 있어 보이는 파일의 머리말을 읽으십시오. 이전 검사가 중복되는 범위를 포함하는 경우, 미리 그 사실을 말하고 파일 이름을 지정한 다음, 사용자와 새 조사를 실행할지 아니면 이전 보고서를 확장할지 결정하십시오. 이미 실행한 검사를 반복하는 것은 이 워크플로우에서 가장 흔한 낭비입니다.

이번 실행을 위해 스크래치패드에 노트 디렉토리를 만드십시오. 각 스레드는 여기에 결과를 기록하여 합성이 네 개의 긴 서브에이전트 응답을 기억하는 대신 파일에서 작업할 수 있도록 합니다.

네 개의 스레드

네 개 모두를 단일 메시지에서 병렬 서브에이전트로 시작하십시오. 일반(general-purpose) 유형의 Agent 도구를 사용하십시오. 각 스레드는 웹 검색과 가져오기(fetch)가 필요합니다. 분해는 고정되어 있습니다. 자신의 것으로 대체하거나, 스레드를 병합하거나, 다섯 번째를 추가하지 마십시오. 각 스레드의 전체 프롬프트는 references/thread-prompts.md에 있습니다. 해당 파일을 읽고 템플릿을 작성된 그대로 사용하되, 아이디어, 엔터티 유형, 노트 경로를 대체하십시오.

1. 선행 기술 (Prior art)

누가 이미 이 제품을 출시했는가. 게시된 가격이 있는 상용 제품, 별표, 라이선스 및 마지막 커밋 날짜가 있는 GitHub 저장소, 학술 연구, 특허. 각 점유자에 대해 아이디어와 얼마나 가까운지, 그리고 무엇을 다루지 않는지 명시하십시오. 목록보다 격차가 더 유용합니다.

2. 인접 기존 업체 (Adjacent incumbents)

어떤 기존 카테고리가 이미 이 기능을 해결하고 있으며, 누가 성공할 경우 이를 흡수할 것인가. 이는 직접적인 경쟁자보다 더 중요합니다. 이 공간의 제품은 스타트업과 정면 승부를 벌이는 것보다 기존 업체가 위에서 기능을 번들링하여 죽는 경우가 더 많습니다. 가장 가능성 높은 흡수자를 지정하십시오.

3. 실패 사례와 경제성 (Graveyard and economics)

여기서 이미 시도되어 실패한 것: 폐업, 저가 인수, 피벗, 해고, 인접 상장 기업의 쇠퇴. 그런 다음 구매자가 누구인지, 실제로 지불하는 금액, 그리고 그 세그먼트가 지불할 수 있는지 여부. 비즈니스 사례에 대해 적대적으로 임하십시오. 경쟁사를 찾도록 지시받은 스레드는 결코 실패 사례를 찾지 못할 것입니다. 이것이 이 스레드가 분리된 이유입니다.

4. 상품화 한계 (Commodity floor)

이 중 얼마나 많은 부분이 이미 무료이거나 번들로 제공되는가: 프론티어 모델 기능, 오픈 소스, 사용자가 이미 보유한 구독 내 기능. 유능한 모델과 웹 검색이 80%를 무료로 수행한다면, 그렇게 말하고 남은 델타를 지정하십시오. 델타만이 판매 가능한 유일한 것이기 때문입니다.

필수 서브에이전트 지침

모든 스레드 프롬프트에는 이 블록을 그대로 포함해야 합니다. 템플릿에 이미 포함되어 있습니다. 대체할 때 잘라내지 마십시오.

  • "선행 기술이 존재한다고 가정하고 찾으십시오. 당신의 임무는 이 공간을 누가 점유하고 있는지 찾는 것이지, 비어 있다는 것을 확인하는 것이 아닙니다. 누가 이 공간을 점유하고 있는지 직설적으로 보고하십시오."
  • "아무것도 찾지 못한 경우 '아무것도 찾지 못했으며, 이는 부재와 동일하지 않음'이라고 쓰고 확인하지 않은 사항을 나열하십시오."
  • "모든 사실 주장에는 출처 URL이 필요합니다."
  • "AI 생성 목록, '최고의 도구 2026' 요약 페이지, 프로그래매틱 가격 책정 사이트, 그리고 신디케이티드 시장 규모 판매자를 모든 사실 주장에서 제외하십시오. 폐기한 출처의 이름을 지정하십시오. 이 도메인의 검색 결과 중 약 3분의 1은 서로에 대해 SEO를 작성하는 벤더입니다. 해당 볼륨을 발견 사항으로 보고하되, 인용하지 마십시오."
  • "모든 발견에서 벤더 주장과 독립적인 증거를 구별하십시오."

첫 번째 줄은 이 스킬에서 가장 가치 있는 줄입니다. 연구 과제를 반증보다 확인 쪽으로 프레이밍하면 발표된 측정치에서 결론이 34~66% 포인트 이동합니다. 이는 프레이밍을 어조 선호도가 아니라 정확성 요구사항으로 만듭니다. 공간이 비어 있는지 확인하도록 지시된 스레드는 비어 있다고 보고할 것입니다.

"아무것도 찾지 못함" 구문은 여기서 증거 부재가 약한 증거이기 때문에 존재합니다. 소규모 경쟁자와 사라진 회사는 모두 인덱싱이 잘 안 되어 있습니다. 확인되지 않은 사항을 나열하면 독자가 침묵이 얼마나 의미하는지 판단할 수 있습니다.

합성 (Synthesis)

네 개의 스레드가 모두 반환되면 노트 파일을 읽으십시오. 그런 다음 두 가지 작업을 수행하십시오.

세 번의 독립적인 시장 판독 (Three independent landscape reads)

시장을 개방형(Open), 혼잡형(Crowded), 또는 포화형(Saturated)으로 레이블을 지정하십시오. 해당 레이블을 세 번 독립적으로 생성하고, 실제로 독립적으로 유지하십시오. 세 개의 병렬 서브에이전트를 시작하고, 각각에게 네 개의 노트 파일과 아래 레이블 정의만 제공하고, 각각 하나의 레이블과 최대 세 문장의 추론을 요청하십시오. 서로의 출력이나 사용자 자신의 초안을 제공하지 마십시오. 사용자 자신의 컨텍스트에서 직접 레이블을 생성한 다음 "재도출"하지 마십시오. 동일한 컨텍스트에서 두 번째 읽기는 첫 번째에 고정되기 때문입니다.

각 판독기에 전달할 정의:

  • 개방형(Open): 어떤 점유자도 아이디어의 핵심을 다루지 않음; 상품화 한계가 실제 델타를 남김; 실패 사례는 비어 있거나 더 이상 유효하지 않은 이유로 실패함.
  • 혼잡형(Crowded): 여러 점유자가 대부분을 다룸; 틈새가 존재하지만 기존 업체가 가까움; 경제성이 좁혀진 세그먼트에 대해 타당함.
  • 포화형(Saturated): 게시된 가격이 있는 직접 점유자, 이미 번들링하는 기존 업체, 또는 세그먼트가 지불할 수 없음을 보여주는 실패 사례.

세 개의 레이블을 모두 보고하고 의견 차이를 표시하십시오. 평균을 내지 말고, 본문에서 다수결로 승자를 선택하지 마십시오. 독자가 분할을 볼 수 있게 하십시오. 벤치마크된 참신성 판단은 프롬프트 표현만으로 정확도가 93.5%에서 40.9%로 변동하며, 3중 호출 투표는 12배 더 비싼 목적별 단일 패스 도구보다 성능이 뛰어났습니다. 판독 간의 의견 차이는 보고서에서 가장 정보가 많은 단일 줄입니다.

비평가 레이어 없음 (No critic layer)

합성 위에 비평가, 레드팀, 또는 토론 에이전트를 추가하지 마십시오. 발표된 결과에 따르면 다중 에이전트 토론은 단일 강력한 패스보다 성능이 떨어지며, 테스트된 대부분의 구성에서 정확도를 저하시킵니다. 노트 파일에서 하나의 신중한 합성이 위원회보다 낫습니다.

출력 (Output)

세 개의 대상. 이 순서대로. 파일이 인도물이며, 대화에는 요약만 제공됩니다.

1. 보고서 파일, 항상 (The report file, always)

전체 보고서를 스킬 디렉토리의 checks/YYYY-MM-DD-<slug>.md에 작성하십시오. 여기서 <slug>는 아이디어의 짧은 케밥-케이스 이름입니다. checks/가 없으면 생성하십시오. 파일을 YAML 머리말로 시작하여 이후 실행이 전체 보고서를 읽지 않고도 일치시킬 수 있도록 하십시오:

---
아이디어(idea): 아이디어에 대한 한 줄 설명
슬러그(slug): 케밥-케이스-이름
날짜(date): YYYY-MM-DD
레이블(label): 개방형(Open) | 혼잡형(Crowded) | 포화형(Saturated)
레이블_판독(label_reads): [판독1, 판독2, 판독3]
주요_점유자(top_occupants): [이름1, 이름2, 이름3]
---

세 판독이 일치하지 않는 경우 레이블을 가장 많이 나타난 것으로 설정하거나, 세 개가 모두 다른 경우 분할(Split)로 설정하십시오. 머리말은 조회 키이며, 본문은 의견 차이가 표시되는 곳입니다.

본문: 마크다운, 1,200단어 미만. 기본적으로 산문, 비교가 실제로 필요한 경우에만 표 사용(예: 여러 점유자의 가격). 엠 대시(em dash) 사용 금지. 다음 순서와 제목으로 섹션 구성:

  1. 이해된 아이디어 (The idea, as understood). 한 문단. 사용자가 먼저 확인합니다.
  2. 이미 있는 사람들 (Who is already there). 이름, URL, 게시된 가격, 각각이 아이디어와 얼마나 가까운지. 벤더 주장은 표시합니다.
  3. 실패 사례 (The graveyard). 무엇이 실패했고 그 이유.
  4. 경제성 (The economics). 누가 지불하고, 얼마나, 그리고 세그먼트가 지불할 수 있는지.
  5. 상품화 한계 (The commodity floor). 이미 무료 또는 번들로 제공되는 것.
  6. 시장 레이블 (Landscape label). 세 판독 모두, 의견 차이가 있으면 표시.
  7. 사실이어야 할 조건 (What would have to be true). 아이디어가 살아남기 위한 특정 조건, 각 조건에 대해 이를 결정할 증거. 연구에서 이미 반증된 조건은 표시.
  8. 출처 및 폐기된 출처 (Sources, and sources discarded). 인용된 모든 URL, 그런 다음 네 스레드에서 폐기된 출처와 각각에 대한 한 구문 이유.

2. 대화 요약, 항상 (The conversation summary, always)

최대 150단어 출력: 시장 레이블과 세 판독의 일치 여부, 가장 가까운 2~3개 점유자, 가장 결정적인 단일 발견, 보고서 파일 경로. 터미널에서 1,200단어를 읽는 사람은 없습니다.

3. 공유 가능한 페이지, 가능한 경우에만 (A shareable page, only if available)

아티팩트나 페이지를 게시하는 도구가 세션에 존재하는 경우, 보고서를 페이지로도 게시하고 사용자에게 링크를 제공하십시오. 선택 사항으로 취급하십시오. 실행을 실패하게 만들지 말고, 파일이나 요약을 보류하지 마십시오. 이 도구가 없기 때문입니다. 이 스킬이 일반적으로 설치되는 많은 Claude Code 세션에서는 이 도구가 없습니다.

알려진 한계 (Known limits)

해당되는 경우 보고서에 명시하십시오.

  • 여기서 증거 부재는 약한 증거입니다. 소규모 경쟁자와 사라진 회사는 모두 인덱싱이 잘 안 되어 있습니다.
  • 엔터프라이즈 도구의 가격은 일반적으로 세일즈 게이트가 있으며 확인할 수 없습니다.
  • 검색 결과의 양은 시장 규모의 증거가 아닙니다. 그 중 상당수는 서로에 대해 글을 쓰는 벤더입니다.
  • 이 보고서는 공간이 점유되었는지 여부를 말합니다. 이 사용자가 승리할 수 있는지는 말하지 않습니다. 이는 연구가 볼 수 없는 정보에 달려 있습니다.

관련 스킬