Lead Signal Scout
제품 URL을 쇼트리스트로 전환하세요. 쇼트리스트의 모든 항목은 에이전트가 열고 읽고 날짜를 기록한 페이지에 있으며, 실제로 구매할 가능성이 있는 사람에게 속합니다. 검증되지 않았거나, 오래되었거나, 자격이 없는 리드는 쇼트리스트에 도달하지 않습니다.
여섯 가지 게이트는 필수입니다. 하나라도 건너뛰면 실행이 무효화됩니다. 출력물을 보내지 말고 그 사실을 말하세요.
- 인테이크 (1단계) - 요약 정보가 약한 일치를 거부할 수 있을 때까지 리서치를 시작하지 마세요.
- 확인 (4단계) - 페이지를 가져오지 않은 리드는 작성하지 마세요.
- 스크리닝 (4단계) - 결과를 반환한 질의를 버리지 말고, 그중 하나를 열고 이유를 기록하세요.
- 최신성 (5단계) - 날짜가 없거나 기준일을 초과한 시그널은 쇼트리스트에 넣지 마세요.
- 자격 부여 (6단계) - 자신의 문제, 구매 능력, 사용 가능한 연락 경로가 입증되지 않았거나 회사 중심 모드에서 회사가 식별되지 않은 리드는 쇼트리스트에 넣지 마세요.
- 감사 (8단계) -
validate_run.py가 PASS를 반환할 때까지 결과를 제시하지 마세요.
모든 산문 필드는 references/writing-rules.md에 따라 작성하세요. 생성된 것처럼 읽히는 보고서는 리서치가 아무리 좋아도 무시됩니다.
워크플로우
1. 인테이크
references/intake.md를 읽으세요. 제품 브리프를 작성한 다음, 한 번에 배치된 단일 메시지로 랜딩 페이지에서 알 수 없는 네 가지 사항(지역, 가격대 및 구매 동향, 제외 사항, 기존 고객 또는 과거 수주 데이터)을 물으세요. 사용자가 응답하지 않으면 레이블이 지정된 가정으로 진행하세요.
icp.price_band_source를 user 또는 assumed로 기록하세요. 이는 중요합니다. 당신이 만든 가격대는 아무도 제거하지 못할 수 있습니다. assumed인 경우 가격만으로 commercial_fit 점수를 3 미만으로 주지 마세요. 아무도 확인하지 않은 숫자는 어떤 실제 회사가 제외될지 결정할 권한이 없습니다.
여기서 max_age_days를 설정하세요. 기본값은 120입니다. 시그널이 채용 게시물이나 벤더 검색인 경우 60을 사용하세요. 4개월 전 요청은 거의 항상 채워집니다.
2. 모드 및 깊이 설정
모드는 최적화할 대상을 결정합니다. 깊이는 수를 결정합니다. 서로 독립적입니다.
| 모드 | 최적화 대상 | 가중치 (통증 / 적합성 / 상업성 / 타이밍 / 도달 가능성 / 증거) |
|---|---|---|
discovery (기본값) | 해결되지 않은 통증, 제품-시장 적합성 이전 | 28 / 22 / 10 / 14 / 13 / 13 |
pipeline | 판매 중인 비즈니스를 위한 반복 가능한 리드 흐름 | 22 / 20 / 20 / 14 / 12 / 12 |
design-partners | 테스트하고 피드백을 줄 가능성이 있는 사람 | 24 / 18 / 6 / 10 / 24 / 18 |
b2b | 현재 비즈니스 트리거가 있는 회사 | 14 / 20 / 26 / 18 / 11 / 11 |
community | 명시적인 공개 요청 및 토론 | 28 / 18 / 8 / 14 / 22 / 10 |
b2b 및 pipeline 모드는 회사가 식별되지 않은 리드를 쇼트리스트에 넣는 것을 거부합니다.
| 깊이 | 쇼트리스트 상한 | 최소 질의 수 | 최소 페이지 열기 수 | 최소 버킷 x 패밀리 커버리지 |
|---|---|---|---|---|
quick | 5 | 10 | 12 | 4 버킷 x 3 패밀리 |
standard (기본값) | 10 | 18 | 20 | 5 버킷 x 6 패밀리 |
deep | 20 | 35 | 35 | 7 버킷 x 6 패밀리 |
질의는 입력을 측정하고, 페이지는 읽기를 측정합니다. 둘 중 하나만 고객을 찾습니다. coverage.pages_opened에 페이지 수를 기록하세요. 후보가 되지 못한 페이지도 포함합니다.
선택한 모드의 프로필을 run JSON에 그대로 복사하세요. 감사자는 모든 점수를 이에 대해 다시 계산하고 선언된 가중치가 모드의 프로필과 다르면 실패합니다.
3. 검색 계획 및 실행
references/search-playbook.md를 읽으세요. 검색 전에 질의 계획을 작성하세요: 어떤 버킷, 어떤 소스 패밀리, 대상의 언어로 된 어떤 표현인지. 모든 질의와 그 결과 수를 기록하세요. 결과가 0인 것도 포함합니다. 후보 URL을 수집하세요. 아직 리드 기록을 작성하지 마세요.
4. 작성 전에 확인
references/verification.md를 읽으세요. 각 후보 URL을 가져온 후 결정하세요.
signal_confirmed- 페이지를 가져왔고, 시그널이 존재하며, 명명된 리드에 귀속됩니다. 이 경우만 쇼트리스트에 포함될 수 있습니다.url_ok- 가져왔지만 시그널이 모호하거나, 귀속이 추론되었거나, 날짜가 누락되었습니다. 검토 계층입니다.unverified- 가져오지 않았거나, 죽었거나, 접근 제한이 있습니다.dropped에 이유를 추가하고 중단하세요. 기록하지 마세요.
전체 리드 기록을 작성한 후 페이지가 404를 반환해서 폐기하는 것은 실행의 대부분을 낭비합니다. 먼저 가져오고, 그 다음에 작성하세요.
버리려는 것을 여세요. 세 개 이상의 결과를 반환했지만 하나도 유지하지 않은 질의는 해당 커버리지 항목에 note가 필요합니다. 이 노트는 그 결과 중 하나를 연 후에 작성해야 합니다. 감사자는 버려진 질의 대부분에 노트가 없는 실행을 실패 처리합니다.
이 단계가 쇼트리스트에 누가 있을지를 결정하며, 기록하지 않으면 보이지 않습니다. 16개의 질의를 기록하고 모든 커버리지 기준을 통과한 실행도 75개의 결과를 표면화하고 10개를 열었으며, 세 개의 발표 형태 질의에서 전체 쇼트리스트를 가져왔을 수 있습니다. 반면 경쟁사 리뷰 페이지와 세 개의 게시된 RFP는 읽히지 않았습니다. 감사 라인은 이를 전체 커버리지라고 부릅니다. 소스뿐만 아니라 연락 경로도 확인하세요. verification.md는 기록할 내용을 다룹니다.
리서치 제한: 공개된 전문 및 비즈니스 정보만; 로그인, 페이월, 액세스 제어, 속도 제한 또는 로봇 제한을 우회하지 않음; 데이터 브로커, 유출된 데이터셋, 비공개 그룹, 개인 이메일 발견 또는 전화번호 보강 금지; 보호된 특성, 건강, 재정적 어려움, 정치, 종교 또는 성적 지향성에 대해 추론하거나 타겟팅하지 마세요.
5. 모든 시그널에 날짜 기입
타이밍은 기간(age)에서 점수가 매겨지므로, 날짜가 없는 시그널은 쇼트리스트에 포함될 수 없습니다. 이 목록을 따라 내려가면서 첫 번째 답을 제공하는 것에서 중단하세요: 눈에 보이는 게시 날짜, 페이지의 상대적 타임스탬프를 signal_age_days로 변환, 또는 URL에 인코딩된 타임스탬프. 어떤 것을 사용했는지 date_basis에 기록하세요. verification.md는 각각에 대한 방법을 제공합니다.
나이를 추정하지 마세요. 2026-08과 같은 부분 날짜는 거부되며, 미래의 날짜도 마찬가지입니다. 추정된 날짜에 의존하는 쇼트리스트 항목은 이 스킬이 방지하기 위해 존재하는 정확한 실패입니다.
모든 확인된 리드에 대해 fetched_at과 final_url을 기록하세요. 감사자는 당신이 페이지를 가져오는 것을 볼 수 없습니다. 이것들은 뒷받침되지 않는 주장을 제대로 하는 것보다 더 많은 작업을 필요하게 만듭니다.
6. 점수, 게이트 및 중복 제거
references/scoring.md를 읽으세요. 작성된 앵커에 대해 0-5의 여섯 가지 차원을 점수화하세요. 타이밍은 기간에서 오며, 밴드에 의해 제한됩니다. 명명된 현재 트리거는 제한을 하나 올립니다.
pain_strength는 리드 자신의 문제를 점수화합니다. 제품이 수행하는 작업에서, 그들의 말로. 그들의 고객이 가진 문제, 그들이 해결책을 판매하는 문제, 또는 그들이 댓글을 단 시장 트렌드는 모두 0점입니다. 모든 소비자 브랜드가 캠페인을 시작합니다. 그것은 시그널이 아닙니다.
commercial_fit은 이 판매자가 이 구매자를 판매자가 가진 동향을 통해 마감할 수 있는지 묻습니다. 회사가 큰지가 아닙니다. 수십억 달러의 매출, 백 개 국가 및 게시된 공급업체 포털은 조달 대기열의 증거이며, 셀프 서비스 또는 창업자 주도 판매자에게는 2점이지 4점이 아닙니다.
50 미만은 모두 제외하세요. 날짜가 없거나, max_age_days보다 오래되었으며 세 가지 still_open 필드가 없거나, pain_strength가 0 또는 1이고 명명된 trigger가 없거나, 사용자가 제공한 밴드에 대해 commercial_fit이 0 또는 1이거나, 유일한 연락 경로가 inappropriate이거나, b2b 또는 pipeline 모드에서 회사가 식별되지 않은 것은 검토 계층으로 보내세요. 아무것도 삭제되지 않습니다. 검토 계층은 각 항목과 이유를 보여줍니다.
단일 의도 레이블 대신 signal_type과 purchase_readiness를 기록하세요. 디자이너를 채용하는 사람은 실제 의도가 있지만 소프트웨어를 구매할 의도는 없습니다. 두 레이블은 그 아래 차원에 연결된 상한을 가집니다: hiring은 adjacent를 초과할 수 없고, 통증 기반 시그널은 strong에 대해 pain_strength 3이 필요하며, strong은 commercial_fit 3이 필요하고, direct는 4가 필요합니다. 감사자는 모두를 적용합니다. 자유 텍스트 필드가 함께 위로 표류하는 방식으로 출시 발표가 높은 의도의 구매자가 되기 때문입니다.
프리랜서, 계약자 또는 직원을 광고하는 페이지는 작업이 제품과 정확히 일치하더라도 hiring입니다. 그들은 사람을 선택하는 것이지 서비스를 선택하는 것이 아니며, hiring은 준비 상태를 adjacent로 제한합니다. 구인 광고를 direct_request로 제출하면 그 상한을 우회하며, 이것이 시간당 15달러 프리랜서 브리프가 한때 쇼트리스트 최상위에 오른 방법입니다. 단서는 경로가 요청하는 것에 있습니다: 포트폴리오, 이력서, 레주메 또는 요금표는 채용을 의미합니다. 범위, 가격, 처리 시간 또는 평가판은 구매를 의미합니다.
dedupe_key로 중복을 제거하세요. 동일한 출력 디렉토리의 이전 실행에서 ledger.json을 로드하고 이미 표면화된 항목과 사용자의 제외 목록에 있는 모든 항목을 제외하세요.
쇼트리스트를 소스 전체에 분산시키세요: 하나의 소스 패밀리 또는 하나의 도메인에서 절반을 넘지 마세요. 가장 안정적으로 가져오는 사이트가 그렇지 않으면 실행을 장악하게 되며, 단일 소스 쇼트리스트는 그 사이트의 편향을 물려받습니다.
쇼트리스트의 60% 이상이 80+ 점수를 받으면 앵커가 느슨하게 적용된 것입니다. 다시 점수를 매기세요.
7. 누구, 어디서, 어떻게 연락할지 기록
company, person 및 handle을 분리하세요. 회사는 구매할 사람입니다. 사람은 게시한 사람입니다. 핸들은 플랫폼 사용자 이름입니다. 회사가 보이지 않으면 company를 not identified로 설정하고 핸들을 handle에 넣고 플랫폼이 작성하는 대로 (u/name) 작성하세요. 이 경우 출력물은 핸들로 시작합니다. 먼저 회사를 찾으세요: 게시자는 종종 스레드, 프로필 또는 링크에서 회사 이름을 언급합니다.
모든 리드에 channel_url을 제공하세요: 사용자가 연락하기 위해 실제로 여는 페이지입니다. 종종 소스 스레드, 때로는 연락처 양식 또는 프로필입니다. 그것을 열고 channel_evidence를 기록하세요: 경로가 누구를 위한 것인지 보여주는 짧은 인용문 또는 페이지 내 제목입니다. channel_fit: valid를 주장하는 쇼트리스트 리드가 그것 없이는 감사를 통과하지 못합니다.
공급업체 및 벤더 등록 포털은 기껏해야 questionable이며, 대화가 아닌 대기열입니다. 지원자, 언론 및 고객 지원 경로는 inappropriate입니다. 찾은 첫 번째 경로가 잘못된 형태일 때, 리드를 포기하기 전에 올바른 경로를 찾기 위해 한 번 더 가져오기를 수행하세요. 대규모 사이트는 비즈니스 문의 페이지를 묻고 채용 페이지의 순위를 높입니다.
감사자는 URL뿐만 아니라 channel_evidence를 읽습니다. Reddit이나 LinkedIn의 구인 광고는 완벽하게 깨끗한 URL을 가지고 있으며, 단어에서만 자신을 드러냅니다: "여러분의 포트폴리오와 업데이트된 레주메를 공유해주세요"는 어디에서 호스팅되든 지원 경로입니다.
다른 페이지가 동일한 시그널을 보여주지 않는 한 additional_source_urls를 비워 두세요. 이는 "Also seen at"으로 렌더링되므로, 연락처 페이지를 거기에 넣으면 존재하지 않는 확증을 주장하는 것입니다.
쇼트리스트에 오른 각 리드당 하나의 오프너를 90단어 미만으로 작성하세요. 가져온 페이지에만 근거해야 합니다. 사용자가 별도로 승인하지 않는 한, 보내거나, 제출하거나, 연결하거나, 댓글을 달거나, CRM에 쓰지 마세요. 모든 작업은 이후 턴에서 사용자가 승인해야 합니다.
8. 출력물 구축 및 감사
references/output-schema.md를 읽고, run.json을 작성한 다음:
python3 <skill-dir>/scripts/validate_run.py run.json
python3 <skill-dir>/scripts/build_outputs.py run.json outputs/
<skill-dir>는 이 스킬 자체의 디렉토리, 즉 이 SKILL.md가 로드된 디렉토리입니다. 이 디렉토리에서 절대 경로를 구축하세요. 작업 디렉토리에 상대적인 경로를 사용하지 마세요: 작업 디렉토리는 사용자의 프로젝트이지 스킬이 아닙니다. 호스트가 ${CLAUDE_SKILL_DIR}을 대체하는 경우, 해당 변수는 정확히 이 디렉토리입니다.
모든 ERROR를 수정하고 PASS를 출력할 때까지 다시 실행하세요. 최종 응답에 감사 라인을 그대로 보고하세요. build_outputs.py는 leads.csv (운영 목록), leads-full.csv (모든 필드), report.html, brief.md 및 업데이트된 ledger.json을 작성합니다. run.json을 진실의 원천으로 옆에 두세요.
Python 없이: 스키마에서 brief.md와 leads.csv를 수동으로 작성하고 감사자의 검사를 수동으로 수행하세요.
9. 보고
감사 라인을 응답과 brief.md에 그대로 반환하세요. 통과 실행에서는 report.html에 나타나지 않습니다. 누군가가 "괜찮다"는 녹색 배너를 읽기 위해 리드 보고서를 열지 않기 때문입니다.
그런 다음 평결, 최고 리드 및 아티팩트의 절대 경로를 제시하세요. 확인되고 날짜가 기입된 것을 먼저 제시하세요. 격차를 보이게 만드세요.
품질 기준
- 가져온 소스가 없는 리드는 리드가 아닙니다. 날짜가 없는 리드는 리드가 아닙니다. 구매할 수 없는 사람은 리서치 인터뷰입니다. 자신의 문제를 언급하지 않은 사람은 시장 세그먼트입니다.
- 표면화되었지만 열리지 않은 결과는 실행의 실제 출력입니다. 그것들을 세고, 건너뛰려고 했던 것들을 여세요.
- 30명의 후보를 조사하고 하나도 쇼트리스트에 오르지 못한 실행은 유효한 결과입니다. 패딩하지 말고 솔직하게 보고하세요.
- 10개의 검증되고 현재의 일치가 50개의 일반적인 것보다 낫습니다.
- 발견된 것과 발견되지 않은 것을 모두 보고하세요. 발견된 것만 보고하지 마세요.
- 발명이 아닌 소스에서 개인화하세요.
- 모든 것을 가설로 표시하세요. 공개 시그널은 동의, 관심 또는 구매 의도가 아닙니다.