TongyiDai/giants-shoulders

巨人之肩 (Giants' Shoulders)

"If I have seen further it is by standing on the shoulders of Giants." — Isaac Newton, 1675

개요

새로운 것을 만들기 전에, 누군가 이미 비슷한 것을 만들었는지 알아내십시오. 대부분의 아이디어는 이미 시도되었습니다: 잘 해결된 것, 잘못 해결된 것, 유익한 이유로 포기된 것, 그리고 진정으로 열려 있는 몇 가지가 있습니다. 목표는 복사하는 것이 아니라 빈 페이지 대신 현재의 최전선에서 시작하는 것입니다. 즉, 검증된 접근 방식을 재사용하고, 알려진 막다른 길을 피하며, 작업이 실제로 기존 것과 어디에서 다른지 명확히 보는 것입니다.

에이전트에 종속되지 않습니다: 웹을 검색할 수 있는 모든 에이전트(Claude Code, Codex, Cursor, TRAE 등)와 함께 작동합니다. 호스트가 제공하는 웹 검색 / 가져오기 도구를 사용하십시오. 작업 시작 시, 설계나 코딩 전에 실행하고, 비례적으로 유지하십시오 — 문헌 조사가 아닌 간단한 스캔입니다.

실행 시점 vs. 건너뛰기

실행해야 하는 경우 — 도구 / 스크립트 / 라이브러리 / CLI / 스킬 / 플러그인 / 에이전트 / 워크플로우 / 통합 / 프로토타입 / 제품을 만들거나, 아키텍처를 설계하거나, 프레임워크, 라이브러리, 알고리즘을 선택하는 등 새로운 것을 만들거나 접근 방식을 선택하는 작업일 때.

건너뛰기 — 간단한 작업(한 줄 번역, 변수 이름 변경, 시간 확인)이거나 외부 선례가 없는 작업(사용자의 개인 파일/데이터 편집)인 경우. 실행할 가치가 있는지 확실하지 않다면 한 문장으로 물어보십시오: "한 1-2분만 투자해서 기존에 있는 솔루션이 있는지 먼저 찾아볼까요?"

워크플로우

1. 문제를 한 문장으로 재정의

작업을 핵심 문제로 축약하십시오. 사용자가 선택한 솔루션이 아닌, 일반적인 용어로 설명합니다. 예: "CSV 중복 제거 스크립트 만들기" → 핵심 문제 = "테이블 형식 데이터의 행 중복 제거". 문제 정의가 너무 광범위하여 전체 도구 범주와 일치한다면, 검색 전에 정확히 한 개의 명확화 질문을 하십시오 (설문조사가 아닌 최대 3개의 예시 차원을 프롬프트로 제공).

2. 검색 전에 어휘 생성

다른 커뮤니티는 같은 것을 가리키는 다른 단어를 사용합니다. 쿼리를 실행하기 전에, 다양한 관점에서 문제에 대한 6-10가지 프레이밍을 작성하고 각 검색 쿼리를 하나의 프레이밍에 매핑하십시오. 이는 가장 흔한 실패 모드(다섯 개의 쿼리가 모두 동일한 의미 영역에 도달하는 것)를 방지합니다. 최소한 다음을 포함하십시오:

• 빌더 프레이밍 — 사용자의 자신의 표현
• 도구 사용자 프레이밍 — 이 문제를 검색하는 사람이 입력할 내용
• 학술/연구 프레이밍 — 해당되는 경우
• 인프라/구현 프레이밍 — 저수준 명칭
• 인접 커뮤니티 프레이밍 — 아마도 먼저 해결한 인접 분야

최소한 하나의 영어 프레이밍을 포함하십시오 — 대부분의 선례와 저장소는 영어로 더 잘 표면화됩니다.

3. 빌더가 실제로 게시하는 곳을 검색

호스트의 웹 도구를 사용하십시오 (먼저 검색한 다음 유망한 결과를 가져옵니다). 다양한 프레이밍과 소스에 걸쳐 3-6개의 타겟팅된 쿼리를 실행하십시오 — 하나의 일반 쿼리로 끝내지 마십시오.

소스	찾는 내용	방법
웹 검색	제품, 비교, "최고의 X for Y", 블로그 게시물	호스트 검색 도구
코드 호스트	실제 구현, 라이브러리, "awesome-*" 목록	site:github.com <문제>, GitLab; gh CLI가 있으면 gh search repos/code "<키워드>"
패키지 저장소	기존 라이브러리	npm, PyPI, crates.io, pkg.go.dev, Hugging Face (ML)
제품 / 커뮤니티	출시된 제품, 경험담	Product Hunt, Hacker News "Show HN", 관련 subreddit
Q&A / 포럼	함정, 접근 방식이 실패하는 이유	Stack Overflow, HN 스레드
도메인 전문 매체	정식 방식	공식 문서, RFC/표준, arXiv, 모델 카드

1차 소스(저장소, Show HN 스레드, 프로젝트 홈페이지)를 집계 요약 목록보다 선호하십시오. 200개의 별을 받은 GitHub 저장소가 Medium 요약 목록보다 낫습니다.

4. 모든 직접 일치 항목에서 한 단계 더 추적

이 부분이 스캔에서 가장 자주 실패하는 지점입니다 — 한 단계 너무 일찍 멈추는 것입니다. 프로젝트 문서에 "X 기반으로 구축됨", "Y를 래핑함", "Z의 공식 하네스", "W를 통해 실행됨"이라고 나와 있으면, 그 명명된 것이 종종 실제 현역이고 찾은 프로젝트는 얇은 래퍼일 수 있습니다. 직접 일치 항목에서 명명된 모든 종속성을 검색 단서로 취급하십시오: 결론을 내리기 전에 전용 쿼리로 추적하십시오. 처음 찾은 (아마도 작은) 프로젝트가 답을 고정하지 않도록 하십시오.

5. 결과를 네 가지 버킷으로 클러스터링

원시 결과를 덤프하지 마십시오. 그룹화하십시오:

• 직접 일치 — 동일한 문제, 동일한 접근 방식
• 인접 솔루션 — 동일한 문제, 다른 접근 방식
• 부분 솔루션 — 하위 집합을 해결
• 폐기됨 / 구식 — 존재했으나 현재는 죽음 (마지막 커밋 날짜와, 찾을 수 있다면 왜 죽었는지 기록 — 종종 가장 유익한 선례)

6. 표준 패턴 추출

일치 항목 전반에 걸쳐 반복되는 것은 무엇입니까? 공통 아키텍처, 라이브러리, 설계 결정, 명명, 가격 모델. 이것이 작업이 기반하거나 경쟁해야 하는 기본 플레이북입니다.

7. 작업의 각도를 정직하게 평가

한 단락으로, 사용자의 특정 프레이밍을 기존 것과 비교하십시오. 실제 차별점을 명명하거나, 없다면 인정하십시오. 친절하려고 새로움을 만들어내지 말고, 철저해 보이려고 경쟁자를 지어내지 마십시오.

8. 판결을 내린 후 계속 진행

하나의 판결을 선택하고 그것으로 시작하십시오 (정확한 출력 형태는 references/report-template.md 참조):

• 기존 사용 — 이미 잘 해결됨; 최상의 옵션(들)을 명명
• 포크 / 확장 — 가장 가까운 프로젝트 + 구체적으로 추가할 사항
• 기여 — 기능이 업스트림에 속함; 제안할 위치
• 구축 — 진정한 격차; 차별점이 명확하고 방어 가능함
• 먼저 조사 — 누군가 시도했다가 포기함; 시간을 투자하기 전에 이유를 이해

그런 다음 실제 작업으로 넘어가십시오, 찾은 내용을 바탕으로. 판결이 범위를 실질적으로 변경하지 않는 한 승인을 위해 지체하지 마십시오 (예: 성숙한 도구가 이미 정확히 이것을 수행) — 그런 경우에는 표면화하고 물어보십시오.

예산 및 가드레일

• 시간 제한. 총 ≤10개 쿼리를 목표로; 3-4개 후에 상황이 명확하고 최소 하나의 종속성을 한 단계 추적(4단계)했다면 더 일찍 중단하십시오. 이는 실제 작업에 앞서는 작업이며, 이를 지배해서는 안 됩니다.
• 정직하게 보고. "직접적인 선례를 찾을 수 없음"은 유효하고 가치 있는 결과입니다 — 약한 일치나 가짜 경쟁자로 채우기보다 어디를 찾았는지 말하십시오.
• 좋은 것이 존재할 때 '구축'을 권장하지 마십시오. 맞춤 구축은 지속적인 유지보수 비용을 수반하며, 이는 일상적으로 과소평가됩니다. 맞는 것이 없지 않는 한 사용/적응/기여를 기본값으로 하십시오.
• 별점뿐 아니라 유지보수도 확인. 최근 커밋, 이슈 응답, 릴리스 주기, 버스 팩터가 별점보다 더 많은 것을 알려줍니다. 안정적인 500-별 도구가 트렌딩하는 50k 도구를 이길 수 있습니다.
• 라이선스 존중. 재사용을 제안할 때 프로젝트의 라이선스를 명시하십시오.
• 출처 인용. 모든 명명된 항목에 링크를 제공하여 결과를 검증할 수 있도록 하십시오.
• 네트워크 없음? 그렇게 말하고, 스캔이 건너뛰어졌음을 기록하며, 아는 것에 의존하고 — 메모리 기반이며 오래되었을 수 있음을 표시한 후 — 진행하십시오.
• 나열만 하지 말고 종합하십시오. 가치는 비교(재사용 vs. 격차)에 있으며, 링크 더미가 아닙니다.

참조 파일

• references/report-template.md — 정확한 출력 구조와 작업된 예제. 브리프를 작성할 때 읽으십시오.

선택 사항: 기본 규칙으로 만들기

기본적으로 이 스킬은 설명이 작업과 일치할 때만 트리거됩니다. 처음부터 구축하는 모든 작업 전에 자동으로 실행되도록 하려면 호스트 에이전트의 지시 파일에 규칙을 추가하십시오. 한 번 실행하십시오 (옵트인, 멱등성, 재실행 안전):

scripts/install.sh

Giants' Shoulders를 기본 규칙으로 만들지 묻고, '예'이면 찾은 에이전트 지시 파일(Codex/TRAE/Cursor의 AGENTS.md, Claude Code의 CLAUDE.md)에 마커로 감싸진 규칙 블록을 추가합니다. 거절하면 아무것도 쓰지 않습니다. 비대화식으로 설치하려면 GIANTS_SHOULDERS_ASSUME_YES=1을 설정하십시오.