search-first

name	search-first
description	코딩 전 리서치 워크플로우. 커스텀 코드를 작성하기 전에 기존 도구, 라이브러리 및 패턴을 검색합니다. "구현하기 전에 기존 솔루션을 검색하는" 접근 방식을 체계화합니다. 새 기능을 시작하거나 기능을 추가할 때 사용하세요.
metadata	{"origin":"ECC"}

/search-first — 코딩 전 리서치 (Research Before You Code)

"구현하기 전에 기존 솔루션을 검색하는" 워크플로우를 체계화합니다.

트리거 (Trigger)

다음과 같은 경우 이 스킬을 사용하세요:

• 기존 솔루션이 있을 법한 새 기능을 시작할 때
• 의존성(dependency) 또는 통합(integration)을 추가할 때
• 사용자가 "X 기능을 추가해줘"라고 요청하고 코드를 작성하려 할 때
• 새 유틸리티, 헬퍼 또는 추상화 계층을 만들기 전

워크플로우

┌─────────────────────────────────────────────┐
│  1. 니즈 분석 (NEED ANALYSIS)                │
│     필요한 기능 정의                         │
│     언어/프레임워크 제약 사항 식별            │
├─────────────────────────────────────────────┤
│  2. 병렬 검색 (리서처 에이전트)               │
│     ┌──────────┐ ┌──────────┐ ┌──────────┐  │
│     │  npm /   │ │  MCP /   │ │  GitHub / │  │
│     │  PyPI    │ │  Skills  │ │  Web      │  │
│     └──────────┘ └──────────┘ └──────────┘  │
├─────────────────────────────────────────────┤
│  3. 평가 (EVALUATE)                         │
│     후보 점수 매기기 (기능, 유지보수, 커뮤니티,│
│     문서, 라이선스, 의존성)                  │
├─────────────────────────────────────────────┤
│  4. 결정 (DECIDE)                           │
│     ┌─────────┐  ┌──────────┐  ┌─────────┐  │
│     │  채택   │  │  확장     │  │  자체    │  │
│     │ (Adopt) │  │  (Extend) │  │  구축    │  │
│     └─────────┘  └──────────┘  └─────────┘  │
├─────────────────────────────────────────────┤
│  5. 구현 (IMPLEMENT)                        │
│     패키지 설치 / MCP 구성 /                 │
│     최소한의 커스텀 코드 작성                 │
└─────────────────────────────────────────────┘

결정 매트릭스 (Decision Matrix)

신호 (Signal)	행동 (Action)
정확히 일치, 유지보수 잘 됨, MIT/Apache 라이선스	채택 (Adopt) — 직접 설치 및 사용
부분적으로 일치, 좋은 토대	확장 (Extend) — 설치 + 얇은 래퍼(wrapper) 작성
여러 개의 약한 일치 항목들	구성 (Compose) — 2~3개의 작은 패키지 결합
적절한 항목을 찾지 못함	자체 구축 (Build) — 커스텀 코드를 작성하되, 리서치 결과 참고

사용 방법

퀵 모드 (Inline)

유틸리티를 작성하거나 기능을 추가하기 전에 다음 사항을 점검하세요:

0. 저장소(repo)에 이미 존재하나요? → 관련 모듈/테스트를 먼저 검색하세요.
1. 흔한 문제인가요? → npm/PyPI를 검색하세요.
2. 이를 위한 MCP가 있나요? → MCP 구성을 확인하고 검색하세요.
3. 이를 위한 스킬이 있나요? → 사용 가능한 스킬을 확인하세요.
4. GitHub 구현체/템플릿이 있나요? → 완전히 새로운 코드를 작성하기 전에 유지보수되고 있는 OSS를 GitHub 코드 검색으로 찾아보세요.

풀 모드 (Subagent)

복잡한 기능의 경우, 리서치 전용 서브 에이전트에게 위임하세요:

다음 프롬프트로 서브 에이전트 호출:
  "다음에 대한 기존 도구를 리서치해줘: [설명]
   언어/프레임워크: [언어]
   제약 사항: [제약 사항]

   검색 대상: npm/PyPI, MCP 서버, 스킬, GitHub
   결과: 추천이 포함된 구조화된 비교 리포트"

카테고리별 검색 단축키

개발 툴링

• 린팅(Linting) → eslint, ruff, textlint, markdownlint
• 포매팅(Formatting) → prettier, black, gofmt
• 테스트 → jest, pytest, go test
• Pre-commit → husky, lint-staged, pre-commit

AI/LLM 통합

• Claude SDK → 최신 문서를 확인하세요.
• 프롬프트 관리 → MCP 서버를 확인하세요.
• 문서 처리 → unstructured, pdfplumber, mammoth

데이터 및 API

• HTTP 클라이언트 → httpx (Python), ky/got (Node)
• 검증(Validation) → zod (TS), pydantic (Python)
• 데이터베이스 → 먼저 MCP 서버를 확인하세요.

콘텐츠 및 퍼블리싱

• 마크다운 처리 → remark, unified, markdown-it
• 이미지 최적화 → sharp, imagemin

통합 포인트

플래너(Planner) 에이전트와 함께

플래너는 1단계(아키텍처 리뷰) 전에 리서처를 호출해야 합니다:

• 리서처가 사용 가능한 도구를 식별합니다.
• 플래너가 이를 구현 계획에 통합합니다.
• 계획 단계에서 "바퀴를 다시 발명하는" 것을 방지합니다.

아키텍트(Architect) 에이전트와 함께

아키텍트는 다음 사항에 대해 리서처와 상담해야 합니다:

• 기술 스택 결정
• 통합 패턴 발견
• 기존 참조 아키텍처

반복적 검색(Iterative-retrieval) 스킬과 함께

점진적인 발견을 위해 결합하세요:

• 1주기: 광범위한 검색 (npm, PyPI, MCP)
• 2주기: 상위 후보 상세 평가
• 3주기: 프로젝트 제약 조건과의 호환성 테스트

예시

예시 1: "데드 링크(Dead link) 체크 기능 추가"

니즈: 마크다운 파일의 깨진 링크 확인
검색: npm "markdown dead link checker"
발견: textlint-rule-no-dead-link (점수: 9/10)
행동: 채택 (ADOPT) — npm install textlint-rule-no-dead-link
결과: 커스텀 코드 0줄, 검증된 솔루션 사용

예시 2: "HTTP 클라이언트 래퍼 추가"

니즈: 재시도(retry) 및 타임아웃 처리가 포함된 회복 탄력성 있는 HTTP 클라이언트
검색: npm "http client retry", PyPI "httpx retry"
발견: got (Node) - retry 플러그인 포함, httpx (Python) - 기본 retry 포함
행동: 채택 (ADOPT) — retry 설정과 함께 got/httpx 직접 사용
결과: 커스텀 코드 0줄, 프로덕션 수준의 라이브러리 사용

예시 3: "설정 파일 린터 추가"

니즈: 스키마에 따라 프로젝트 설정 파일 검증
검색: npm "config linter schema", "json schema validator cli"
발견: ajv-cli (점수: 8/10)
행동: 채택 + 확장 (ADOPT + EXTEND) — ajv-cli 설치, 프로젝트별 스키마 작성
결과: 패키지 1개 + 스키마 파일 1개, 커스텀 검증 로직 없음

안티 패턴 (Anti-Patterns)

• 바로 코드부터 작성: 이미 존재하는 유틸리티가 있는지 확인하지 않고 작성하는 경우
• MCP 무시: MCP 서버가 이미 해당 기능을 제공하는지 확인하지 않는 경우
• 과도한 커스텀: 라이브러리를 너무 과하게 감싸서 이점을 잃는 경우
• 의존성 비대화: 작은 기능 하나를 위해 거대한 패키지를 설치하는 경우

이 스킬을 사용하는 시점

• 새 기능을 시작할 때
• 의존성 또는 통합을 추가할 때
• 유틸리티나 헬퍼를 작성하기 전
• 기술 선택을 평가할 때
• 아키텍처 결정을 계획할 때