GitHub Research
사용자의 주제 또는 질문에 관련된 모든 저장소와 추출 가능한 구성 요소를 찾습니다: $ARGUMENTS (Claude Code에서 자동으로 채워집니다; 다른 에이전트에서는 사용자의 요청이 됩니다)
리터럴 키워드 검색은 특정 주제에서 실패합니다: 개발자는 저장소 이름을 그들이 다루는 대상(웹사이트, API, 조직, 라이브러리)의 이름을 따서 짓지, 개념의 이름을 따서 짓지 않기 때문입니다. 모든 구현체가 반드시 포함해야 하는 아티팩트를 여러 방향(코드, 저장소, 커밋, 이슈, 다른 호스트, 웹)에서 검색하고, 모든 적중을 확인한 후, 후보를 재사용 가능한 조각으로 분해하여 우리의 대상 솔루션에 혼합합니다.
rotless 제품군
rotless의 일부이며, 단독으로도 완전히 사용 가능합니다. 연구 결과가 어떤 스킬에 대한 선행 기술일 때, 호출자는 파일 이름과 그 형식(prior-art.md, rotless-skill-modernizer에 정의됨)을 지정합니다: 그 형식에 맞춰 보고서를 작성합니다. 호출자: rotless-skill-creator (0단계, 구축 전), rotless-skill-modernizer (fix는 대체된 도구에 대해, refresh는 전체 환경에 대해), rotless-skill-refiner ('더 나은 방법' 교훈을 채택하기 전에 기존 것을 확인할 때).
도구 상자
도우미는 이 스킬의 scripts/ 폴더에 있습니다. S를 이 스킬의 기본 디렉터리(이 SKILL.md가 포함된 폴더; Claude Code는 스킬이 로드될 때 "Base directory for this skill: …"를 출력)의 절대 경로로 한 번 설정하고, 항상 $S를 통해 도우미를 호출합니다(cwd는 사용자의 프로젝트입니다); -h는 플래그를 나열합니다; python3을 사용하고 Windows에서는 python을 사용합니다. GitHub 외 엔드포인트는 references/sources.md(같은 폴더)에 있습니다. POSIX 셸(bash; Windows에서는 Git Bash)을 PowerShell(-, !, jq의 quoting)보다 선호합니다. sarkari/UPSC 예제는 설명 목적으로만 사용됩니다.
| 도구 | 검색 대상 | 최적 사용 사례 |
|---|---|---|
grepapp.py (= searchGitHub 도구, grep MCP가 설치된 경우) | 파일 내용, ~100만 인기 저장소, 정규식, 인증 불필요 | 하드코딩된 도메인, 임포트 라인, 구성 키 |
gh api -X GET search/code -f q='…' | 파일 내용, GitHub의 레거시 인덱스(더 많은 저장소, 정규식 없음) | 두 번째 코드 소스; path:/filename: 시그니처 |
ghsweep.py | 저장소 이름/설명/README/토픽, 여러 쿼리, 중복 제거 | 폭 검색; 총 개수, 공통 토픽, [noise?] 태그 |
gh search commits … | 커밋 메시지 | 이름/README가 아무것도 알려주지 않는 저장소 |
gh search issues … --include-prs | 이슈/PR 텍스트 | 저장소 + 실제 문제점 (구체적인 구문 필요; 일반적인 단어는 봇 이슈에 묻힘) |
ghverify.py | GraphQL 배치, 호출당 25개 저장소 | 존재 여부, 이름 변경, 실제 활동, 건전성, 증거, 경고 플래그 |
gh repo read-dir / read-file, gh api …/contents | 하나의 저장소 파일, 클론 불필요 | 실제 코드 확인 |
srcsweep.py | npm, crates, Packagist, Hex, NuGet, Maven, RubyGems, Hackage, Docker Hub, ArtifactHub, AUR, Open VSX, GitLab, Codeberg, MCP Registry, skills.sh, Hugging Face (모델/데이터셋/스페이스/논문, 논문이 링크하는 코드 저장소 포함), Hacker News 등 21개의 비-GitHub 소스를 병렬로 검색 | GitHub 외 선행 기술; 검색된 소스 / 도달하지 못한 소스의 원장으로 종료; --repos는 GitHub 저장소를 ghverify.py -로 파이프 |
references/sources.md | 엔드포인트 노트 + 검색 API가 없는 소스 (PyPI, Homebrew, pkg.go.dev, Product Hunt, Reddit) | 수동 후속 조치 |
중요한 gh 검색 규칙 (테스트 완료; 무시하면 자동으로 [] 또는 잘못된 결과 반환)
- 인용:
gh search <종류> "두 단어"= 정확한 구문. AND는 인용 부호 없이 단어를 전달합니다;OR는 인용 부호 없이 작동합니다. - 간단하지 않은 경우 원시 API 사용 (전체 구문 +
total_count):gh api -X GET search/{repositories|code|commits|issues} -f q='<query>' -f per_page=100 --cache 1h - 저장소 검색에서는 모든 단어가 일치해야 합니다. 따라서 각 쿼리는 2-3단어로 유지하고, 하나의 쿼리에 많은 단어를 쌓지 말고 다양한 표현을 사용하세요. 스윕이 5개 미만의 저장소를 반환하면 쿼리를 줄이세요.
- 제외:
NOT word가 있는 단어;-qualifier:value가 있는 한정자.-word는 0을 반환합니다.gh search에서는 제외 조건을--뒤에 넣으세요. - API를 통한 코드 검색 = 레거시 엔진: 정규식 없음;
OR/NOT,path:,filename:,extension:,language:작동. 기본 브랜치만 검색하며 대용량 파일은 건너<0xEB><0x8A><0xB0>니다. 정규식이 필요하면 grep.app를 사용하세요. - 쿼리당 결과 한도 1000개. 대규모 결과 집합은 다음으로 분할:
created:A..B,pushed:>DATE, star 밴드stars:0..24,stars:25..99,stars:100..499(저가시성 숨은 보석도 표면화),language:. - 속도 제한: 검색 30/분; 코드 검색 10/분 (
gh skill search가 공유); GraphQL 5000 포인트/시간. 확인:gh api rate_limit --jq '.resources | {search: .search.remaining, code: .code_search.remaining, graphql: .graphql.remaining}'. 반복 호출에는--cache 1h사용; 코드 검색이 소진되면 벡터를 전환하고 대기하지 마세요. - 개인 정보 보호: 인증된 검색은 계정이 볼 수 있는 비공개 저장소도 반환합니다. 절대 보고하지 마세요: jq에
select(.repository.private == false)(코드) /select(.private == false)(저장소) 추가;ghsweep.py에서 필터링합니다. 사용자의 비공개/내부 이름을 검색 쿼리에 절대 넣지 마세요. gh repo read-file/read-dir/gh discussion/gh skill은 최신 gh가 필요합니다 (2.103에서 테스트). 이전 버전이면 3단계의gh api폴백을 사용하거나winget upgrade GitHub.cli/brew upgrade gh를 제안하세요.
0단계 — 브리프 (짧은 블록 하나, 진정으로 모호한 경우가 아니면 왕복 없음)
다음을 작성하세요: 목표 · 대상 솔루션 분해 (모듈식 하위 문제: 예: 인증/세션, 스크래퍼/파서, 정규화/스키마, 저장소, API/인터페이스 — 어디서 무엇을 활용할 수 있는지 식별) · 필수 사항 · 있으면 좋은 사항 · 안티 패턴 (예: 얇은 래퍼, 유지보수 중단, 유료 API 필요, GPU 전용) · 제약 조건 (언어, 오프라인…: 검색어가 아닌 통과/실패 검사) · 컷오프 (절대 날짜, "최근" → pushed:>2025-10-24) · 노력: 빠른 패스 (저렴하고 되돌릴 수 있는 선택: ~10개 쿼리, 상위 5개) 또는 전체 방법 (선행 기술 / 자체 구축 대 구매 / 혼합의 기본값).
요청이 "X의 대안 / X와 유사 / X 클론"인 경우, 먼저 X를 해당 저장소로 확인하고 해당 저장소(토픽, README, 종속 저장소)를 기반으로 시드하세요.
먼저 로컬을 확인하세요 (무료, 10초): 이미 설치된 것이 답을 줄 수 있습니다: 에이전트가 로드하는 스킬 폴더(프로젝트 및 사용자 수준: .agents/skills/, .claude/skills/, ~/.codex/skills/…), MCP 서버 목록(예: claude mcp list), gh extension list. 전 세계를 검색하기 전에 적중을 보고하세요.
1단계 — 주제 지문 채취
15-30개의 구체적인 검색어를 작성하세요:
- 접점 — 모든 구현체가 접촉해야 하는 도메인, URL, API 엔드포인트, 호스트 이름, RSS 경로, 앱 ID.
- 코드 시그니처 — 임포트 라인, SDK 클래스/함수 이름, 환경 변수, 구성 키, CSS 선택자, 독특한 상수.
- 여러 관점에서의 어휘 — 빌더, 최종 사용자, 학계, 인프라, 그리고 아마도 먼저 해결한 인접 분야; 지역/비영어 용어, 약어, 오타. 모호한 단어는 동반 용어가 필요합니다 (
agent+llm,agent단독이 아님). - 형태 — 봇, 스크래퍼, API, CLI, 라이브러리, 확장, MCP 서버, 에이전트 스킬, 데이터셋, 모델, GitHub Action; 및 해당 파일 시그니처 (
.github/workflowscron,manifest.json,SKILL.md,.claude-plugin/marketplace.json). 에이전트 스킬과 플러그인은 종종 더 큰 저장소 내부에 있습니다 (80k★ 모노레포의skills/x/SKILL.md), 저장소 검색으로는 보이지 않습니다: 코드 검색filename:SKILL.md "<설명의 구문>"으로 찾으세요 (잡음이 많음: 수백에서 수천 개의 적중, 따라서 2개의 독특한 구문을 사용하고 2-3페이지를 스캔) 및 skills.sh (srcsweep.py --sources skills; 의미론적, 목적보다 스킬의 이름에 대해 더 잘 작동). 스킬 검색은 가장 약한 벡터입니다: 앵커 스킬이 전혀 발견되지 않으면 직접 이름을 검색하고 적용 범위 노트에 그렇게 명시하세요. - 앵커 — 좋은 답변에 포함될 것으로 예상되는 3-10개의 잘 알려진 프로젝트/제품. 2단계에서 리콜 검사로 사용됩니다.
- 이상적인 README 단락 — 완벽한 저장소를 설명하는 두 문장, 작성자가 쓸 것 같은 방식으로 작성; 검색어를 추출하세요.
2단계 — 모든 벡터에서 검색
벡터를 병렬로 실행합니다. 각 저장소를 찾은 쿼리를 기록합니다(found_by: 더 많은 쿼리 = 더 강력한 관련성).
A. 코드 검색 (가장 높은 신호). 많은 좁은 쿼리, 접점/시그니처당 하나:
S="<이 스킬의 기본 디렉터리>/scripts" # 예: S="$HOME/.agents/skills/rotless-github-research/scripts" (또는 Claude Code의 ~/.claude/skills/…)
python "$S/grepapp.py" "sarkariresult.com" --repos-only
python "$S/grepapp.py" "(sarkariresult|freejobalert)\.com" --regex --lang Python --lang JavaScript --repos-only
python "$S/grepapp.py" "upsc.gov.in" --path .github/workflows/ --repos-only # 예약된 봇
gh api -X GET search/code -f q='sarkariresult OR freejobalert language:python' -f per_page=100 \
--jq '"total \(.total_count)", (.items[] | select(.repository.private == false) | "\(.repository.full_name)\t\(.path)")'
grep.app는 쿼리당 ~10개 파일을 반환하고 광범위한 정규식에서 504 오류를 반환합니다: 드문 리터럴에 고정하고 --lang/--path를 추가하세요. 잡음 제거: 크롤링된 URL 데이터셋, 광고 차단 목록, 용어가 한 번만 나타나는 모노레포.
B. 저장소 검색 (폭 + 환경 규모).
python "$S/ghsweep.py" --pushed ">2024-01-01" --order hits "sarkari OR naukri NOT resume" "freejobalert" "topic:government-jobs"
python "$S/ghsweep.py" --sort stars "topic:sarkari-result" # 설명이 일반 단어를 건너뛰는 플래그십
python "$S/ghsweep.py" --sort updated "sarkari scraper" # 최고 일치에 묻힌 신선한 작업
python "$S/ghsweep.py" --must "scrap|crawl|alert|job" --exclude "resume|linkedin" "sarkari OR naukri" # 관련성 필터; 동음이의어("prior art" = 특허)는 결과를 범람시킴
gh api -X GET search/topics -f q=sarkari --jq '.items[].name' # 토픽 슬러그 발견
ghsweep.py는 총 개수(공간이 얼마나 붐비는지), 가장 일반적인 토픽(→ 다음 쿼리; 또한 상위 적중 2개 이상이 공유하는 토픽 쌍 시도: topic:a topic:b), [noise?] 태그(튜토리얼/템플릿/데모/dotfiles/awesome: 평가 절하, 자동 탈락 금지)를 출력합니다. 연령에 관계없이 선행 기술의 경우 --pushed를 생략하세요.
C. 커밋 검색: gh search commits sarkariresult --limit 50 --json repository,commit --jq '.[] | "\(.repository.fullName)\t\(.commit.message | split("\n")[0])"'
D. 이슈/PR 검색: gh search issues "freejobalert" --include-prs --limit 50 --json repository,title,url (구체적인 구문만).
E. 최고 적중(상위 3-5개)에서 스노볼링:
- 래핑된 의존성 추적: 적중이 X를 "래핑", "기반으로 구축" 또는 "사용"하면, X도 조사하세요: 종종 실제 강자입니다. 너무 일찍 멈추는 가장 흔한 지점입니다.
- Awesome 목록:
python "$S/ghsweep.py" --sort stars "awesome <kw> in:name"; 200★ 이상의awesome-*목록을 가져와 저장소 링크를 추출하고(gh repo read-file README.md --repo o/awesome-x | grep -oE 'github\.com/[A-Za-z0-9_.-]+/[A-Za-z0-9_.-]+' | sort -u)ghverify.py -로 파이프합니다. 목록에 포함되는 것은 약한 품질 신호입니다. - 유사 저장소: 상위 적중의 토픽 + 언어 →
topic:a topic:b language:x, 유사한 별 등급 선호. - README의 "대안 / 유사 / 영감 / 크레딧" 섹션; 독특한 코드 문자열 → grep.app (복사본 및 포트 찾기); 작성자의 다른 저장소 (
gh repo list <owner> --limit 100); 자체 작업이 있는 포크 (gh api "repos/o/r/forks?per_page=100" --jq '.[] | select(.pushed_at > .created_at) | .full_name'); 웹 가져오기 도구 또는curl을 통한 라이브러리 종속 페이지 (github.com/o/r/network/dependents).
F. GitHub 외: 하나의 명령, 여러 표현 (각 1-3단어; 레지스트리 AND 용어):
python "$S/srcsweep.py" "repository discovery" --limit 4 # 21개 소스, ~10초, 검색됨 / 도달하지 못한 원장으로 종료
python "$S/srcsweep.py" "sarkari" --repos | python "$S/ghverify.py" - # 결과에서 연결된 GitHub 저장소, 검증됨
그런 다음 검색 API가 없는 것(PyPI site:pypi.org, Homebrew, pkg.go.dev, Product Hunt, Reddit, 블로그, awesome <topic>)은 웹 검색을 사용하세요. 선행 기술/경쟁사 연구를 위해 주목할만한 상용 제품도 나열하세요. 비-GitHub 적중(GitLab, Codeberg, 레지스트리 전용)은 ghverify.py를 통과할 수 없습니다: 수동으로 확인하고 증거를 Documented/Metadata로 표시하세요.
중지 및 리콜. 새 쿼리가 주로 알려진 저장소를 반환할 때 중지하지만, 세 쿼리가 동일한 저장소를 반환하는 것은 지역 최소값일 뿐 적용 범위가 아닙니다. 1단계의 앵커를 확인하세요: 검색에서 발견되지 않은 앵커는 어휘 격차를 의미합니다: 앵커가 사용하는 단어를 찾아 검색하세요. 결과가 0이면 "이 경로로는 볼 수 없다"는 뜻이지 "존재하지 않는다"는 뜻이 아닙니다: 결론을 내리기 전에 한 번 다른 표현으로 바꾸거나 경로를 변경하세요.
3단계 — 확인 및 평가
모든 후보는 ghverify.py를 통과합니다 (가상 이름은 NOT FOUND로 표시; 이름이 변경된 것은 현재 이름 표시):
python "$S/ghverify.py" owner/repo https://github.com/o2/r2 ... # 또는: ... | python "$S/ghverify.py" -
다음 열을 읽으세요: 마지막 실질적 커밋 (bump/chore/deps/merge/typo/docs 무시) pushedAt 아님; 이슈 해결 %; 병합된 PR; 사람 수; 조직/사용자; 릴리스/년; 증거 (테스트, ci, manifest, security.md; NONE = README 전용, 확실히 확인); 플래그 !velocity (>100★/일: 바이럴 또는 구매됨, 맥락 필요), !lowfork (≥1000★, 포크/별 < 0.005), new (<14일), stale Ny (2년 이상 실질적 커밋 없음: 플래그 지정, 평가 절하 금지: 버려진 도구라도 아이디어가 구축되었음을 증명), noise?.
그런 다음 보고할 모든 저장소에 대해 실제 코드를 확인하세요 (README는 양방향으로 거짓말을 합니다). 증거를 커밋에 고정하세요:
sha=$(gh api repos/o/r/commits/HEAD --jq .sha)
gh repo read-dir src --repo o/r --ref $sha # JSON: --json name,type --jq '.entries[]'
gh repo read-file path/to/main.py --repo o/r --ref $sha # 폴백: gh api "repos/o/r/contents/PATH?ref=$sha" -H "Accept: application/vnd.github.raw"
gh api "repos/o/r/git/trees/$sha?recursive=1" --jq '"\(.tree|length) files", (.tree[:80][] | .path)'
영구 링크 https://github.com/o/r/blob/<sha>/<path>#L10-L40를 인용하고, 브랜치 링크는 사용하지 마세요.
- 적합성 및 추출 가능성: 강함 / 부분 / 약함 / 대상_벗어남, 나열
…
8단계 — 보고서 완성 (회고 제외 모든 단계 후)
보고서를 prior-art.md(또는 호출자가 지정한 파일)에 씁니다. 각 적중에 대해:
- 신호 대비 잡음 비율 (쿼리 반환률, 저장소당 발견 쿼리 수). 0.5% 미만이면 벡터가 손상되었거나 주제가 GitHub에 적합하지 않음을 나타냅니다.
- 적용 범위 격차 (검색하지 않은 것, 검색했는데 찾지 못한 것, 검색할 수 없는 것). 스킬 검색 결과가 불완전한 경우 명시하세요.
- 권장 사항: 저장소를 새 항목으로 채택, 저장소 구성 요소 추출, 처음부터 구축, 구매, 패스. 추출할 구성 요소의 의사 코드 스케치.
- 모든 구체적 제안에는 파일/디렉터리/리소스 이름과 한 줄 사용 사례를 포함하세요.