existing-repo

기존-repo 스킬 개요

existing-repo가 하는 일

existing-repo 스킬은 에이전트가 낯선 코드베이스에 안전하게 들어가도록 돕고, 스택과 컨벤션을 파악한 뒤, 기존 로컬 패턴을 망가뜨리지 않으면서 가드레일을 추가할 수 있게 해줍니다. 처음 다루는 저장소 작업, 유지보수 작업, 그리고 “수정하기 전에 이해하기”가 새 앱 로직 생성보다 중요한 설정 변경에 특히 잘 맞습니다.

이런 경우에 적합합니다

실제 저장소 작업을 위한 existing-repo guide가 필요하다면 existing-repo 스킬을 사용하세요. 예를 들어 성숙한 프로젝트에 온보딩할 때, linting이나 commit hook을 추가할 때, 또는 이미 자체 구조가 있는 코드베이스를 수정할 때 유용합니다. 반대로, 아직 히스토리를 존중할 필요가 없는 greenfield scaffolding에는 덜 적합합니다.

무엇이 다른가

이 스킬은 행동하기 전에 저장소를 먼저 읽는 데 최적화되어 있습니다. 단순한 코딩 도움말이 아니라 분석, 컨벤션 탐지, 안전한 가드레일에 초점을 맞춥니다. 그래서 existing-repo는 Git Workflows에서 저장소 고유의 가정을 깨뜨릴 위험이 클 때 특히 유용합니다. 핵심은 처음부터 코드를 짜는 일이 아니라, 저장소별 전제를 건드리지 않는 것입니다.

existing-repo 스킬 사용법

설치하고 활성화하기

existing-repo install을 하려면 이 스킬을 Claude skills 설정에 추가한 뒤, 막연한 “이 repo를 살펴봐” 대신 저장소별 작업부터 시작하세요. 이 스킬은 사용자가 호출하는 방식이며 read-first 작업을 전제로 하므로, 프롬프트에는 저장소 이름, 목표, 그리고 반드시 지켜야 할 제약을 명확히 적어야 합니다.

입력 형식을 제대로 주기

좋은 existing-repo usage 프롬프트에는 바꾸고 싶은 것, 그대로 유지해야 하는 것, 알면 스택, 저장소 위치나 브랜치 맥락이 들어가야 합니다. 더 나은 예: “이 existing repo에서 package layout이나 build commands는 바꾸지 말고 Python formatting용 pre-commit guardrails를 추가해줘.” 더 나쁜 예: “이 repository를 개선해줘.”

먼저 중요한 파일부터 읽기

먼저 SKILL.md를 보고, 그다음 README.md, AGENTS.md, metadata.json 같은 저장소의 주요 manifest와 policy 파일을 확인하세요. rules/, resources/, references/, scripts/ 폴더가 있다면 그것들도 살펴보는 것이 좋습니다. 이 repository에는 추가 지원 폴더가 없으므로, 설치 여부를 판단할 때는 거의 SKILL.md 자체와 앞으로 작업할 repo tree가 기준이 됩니다.

일회성 프롬프트가 아니라 워크플로로 쓰기

실용적인 existing-repo guide 흐름은 다음과 같습니다. 스택을 감지하고, 컨벤션을 맵핑하고, 이미 존재하는 가드레일을 확인한 뒤, 가장 작고 안전한 변경안을 제안합니다. 모델에게 무엇을 찾았는지 먼저 보고한 뒤 아무 것도 수정하지 않도록 요청하고, 사용자의 요구와 저장소의 현재 패턴 사이에 충돌이 있으면 반드시 짚어 달라고 하세요.

existing-repo 스킬 FAQ

existing-repo는 레거시 프로젝트에만 필요한가요?

아닙니다. existing-repo 스킬은 활발히 운영 중인 팀 저장소와 monorepo를 포함한 어떤 성숙한 코드베이스에도 잘 맞습니다. 중요한 기준은 이미 지켜야 할 컨벤션이 존재하느냐입니다.

모델에 직접 물어보면 굳이 이 스킬이 필요한가요?

직접 물을 수도 있지만, 이 스킬은 저장소 우선 분석과 더 안전한 기본값을 강제해 추측을 줄여줍니다. 일반 프롬프트는 구현으로 너무 빨리 넘어가곤 하지만, existing-repo는 코드를 손대기 전에 코드베이스를 이해하는 일이 핵심일 때 더 적합합니다.

초보자도 쓰기 쉬운가요?

네, 작업 내용을 설명할 수 있고 먼저 짧은 발견 단계가 필요하다는 점을 받아들일 수 있다면 충분합니다. 이 스킬은 저장소 컨벤션을 암묵적으로 전제하지 않고 명시해 주기 때문에 초보자에게 특히 도움이 됩니다.

언제는 쓰지 말아야 하나요?

존중해야 할 기존 코드베이스가 없을 때, 분리된 짧은 스크립트만 필요할 때, 또는 이미 아주 구체적인 변경 계획이 있어서 저장소 reconnaissance가 필요 없을 때는 existing-repo를 건너뛰세요.

existing-repo 스킬을 더 잘 쓰는 법

제약을 먼저 알려 주세요

가장 좋은 결과는 바뀌면 안 되는 것들을 처음부터 분명히 적을 때 나옵니다. 예를 들면 파일 레이아웃, build system, dependency manager, CI 규칙, hook 도구, 지원 runtime 같은 것들입니다. 이런 제약이야말로 Git Workflows에서 existing-repo의 가치를 만듭니다. 저장소의 실제 운영 규칙에 맞는 해결책만 남기기 때문입니다.

가장 작고 유용한 목표를 제시하세요

넓은 감사(audit)를 요청하기보다, 하나의 경계가 분명한 결과를 요청하세요. 예: “commit-message validation을 추가해줘”, “현재 lint setup을 감지해줘”, “이 repo를 위한 안전한 온보딩 요약을 준비해줘.” 목표를 좁히면 불필요한 refactor를 피하고 더 실행 가능한 가이드를 얻기 쉽습니다.

추측이 아니라 근거를 요구하세요

추천의 근거가 되는 파일, 명령어, 패턴을 명시하도록 모델에 요청하세요. 첫 결과가 너무 일반적이면, “repo files에서 확인된 것”과 “일반적인 관행을 바탕으로 한 추정”을 구분해서 다시 설명해 달라고 하세요. 그러면 신뢰도는 보통 올라가고, 의도치 않은 과잉 적용도 줄어듭니다.

발견에서 변경으로 이어 가세요

첫 출력으로 범위를 정한 뒤, 실제 repo 형태에 맞춰 다음 프롬프트를 다듬으세요. existing-repo를 가장 잘 활용하는 방식은 먼저 발견하고, 그다음 구현하는 것입니다. 에이전트가 스택과 가드레일을 파악한 뒤에는 훨씬 적은 위험으로 정확한 변경 계획이나 패치를 요청할 수 있습니다.