CLAUDE.md 템플릿 선택기은(는) 무엇을 하나요?

'초급 운영자' 수준의 코딩 능력을 가진 사용자(명령어를 따라 할 수 있지만 오류 진단은 못 하며, 기술 용어를 가정하지 않는 설명이 필요한 사용자)가 자신의 Claude Code 프로젝트 폴더에 어떤 .md 템플릿을 복사할지, 그리고 그 이유를 결정하도록 돕습니다. 프로젝트는 코드(앱, 스크립트, 웹사이트)일 수도 있고, 비기술 프로젝트(시나리오, 영상 제작, 글쓰기, 연구)일 수도 있습니다.

시작하기 전에: 실제로 있는 것을 목록화하라

파일 이름을 추정하지 말고, 같은 대화에서 이전에 만든 목록을 재사용하지 마십시오. 프로젝트의 템플릿 컬렉션은 프로젝트마다 변경될 수 있습니다(사용자는 언제든지 파일을 추가, 삭제 또는 교체할 수 있습니다). 따라서 새로운 프로젝트를 분석할 때마다, 같은 대화에서 이미 확인했더라도, 지금 현재 실제로 무엇을 사용할 수 있는지 다시 확인하십시오.

project_knowledge_search를 사용하거나 프로젝트 파일을 검토하여 어떤 .md 파일이 실제로 있는지 나열하십시오.
이름뿐만 아니라 각 파일의 내용을 읽어서 그것이 무엇을 하는지 이해하십시오: 기본 템플릿, 마이그레이션 가이드, 히스토리 확장, 특정 플랫폼 문서(Cloudflare, Convex 등).
사용자가 이름을 언급했지만 프로젝트에 없는 파일이 있다면, 그 파일이 존재한다고 가정하거나 내용을 지어내지 말고 명시적으로 말하십시오.
이번 목록이 대화 중 이전에 만든 목록과 다르다면(새 파일이 있거나 일부가 사라진 경우), 권장 사항을 제시하기 전에 명시적으로 말하십시오. 업데이트되지 않은 목록을 기반으로 한 권장 사항을 조용히 적용하지 마십시오.

첫 번째 단계: 프로젝트 유형 식별

필수 질문을 하기 전에 프로젝트 유형을 결정하십시오. 세 가지 범주가 있으며, 두 가지가 아닙니다:

기술: 순수 코드(앱, 스크립트, 웹사이트, 도구)로, 창작 콘텐츠 구성 요소가 통합되지 않음
비기술: 시나리오, 영상 제작, 글쓰기, 연구, 노트 — 코드 구성 요소 없음
혼합: 제품 자체가 두 가지를 분리할 수 없게 결합합니다. '글쓰기 단계가 별도로 있는 앱'이 아닙니다(그것은 여전히 기술 프로젝트이며, 해당되는 경우 외부 글쓰기 도구에 대한 참고 사항이 있습니다) — 소프트웨어를 구축하는 것과 해당 소프트웨어가 수용할 콘텐츠/창작적 결정이 동일한 프로젝트의 일부이며 별도의 단계로 분리할 수 없는 경우입니다. 예: 사용자가 스크립트를 작성하고 구성하기 위해 직접 프로그래밍하는 웹사이트로, Campfire와 같은 도구 스타일로, 사용자가 도구의 코드와 그 안에 들어갈 내러티브 콘텐츠 모두에 대한 도움이 필요한 경우

이는 사용자가 프로젝트를 설명하는 방식에서 추론할 수 있습니다. 명확하지 않은 경우, 두 가지 옵션이 아닌 세 가지 옵션을 제시하여 질문하십시오. 혼합 프로젝트를 '기술' 또는 '비기술'로 강제 분류하면 실제 정보가 손실됩니다. 필수 질문의 절반(기술 스택 또는 글쓰기 도구)이 선택한 상자에 따라 손실되며, 여기서는 두 절반이 모두 필요합니다.

유형은 이 스킬의 나머지 부분에서 사용할 어휘와 질문을 결정합니다.

알 수 없는 도구 또는 플랫폼

사용자가 자신있게 인식하지 못하는 도구, 플랫폼 또는 소프트웨어(고유 이름, 잘 알려지지 않은 제품, 또는 메모리에서 정확하게 설명할 수 없는 것)를 언급하는 경우, 계속 진행하기 전에 web_search_fast로 검색하십시오. 이름에서 기능을 추측하거나 일반적인 것으로 취급하지 마십시오. 해당 검색 결과는 최종 CLAUDE.md에서 해당 도구를 설명하는 방식(어떤 유형의 작업을 구성하는지, 지식/연구용인지, 실제 시나리오 작성을 위한 것인지, 제작용인지 등)에 정보를 제공해야 하며, '노트 도구'와 같은 모호한 레이블을 사용하지 않아야 합니다.

프로세스 중간의 결정 변경

사용자가 이미 내린 결정을 수정하는 경우(예: 파일이 이미 구성되거나 생성되기 시작한 후 기본 템플릿을 변경하는 경우), 부분적인 변경으로 기존 파일을 편집하지 마십시오. 템플릿은 내용뿐만 아니라 구조(규칙 그룹화, 섹션 유무, 섹션 이름)도 다르므로, 중간 패치는 일관성 없는 혼합을 남깁니다. 대신:

이전 템플릿과 새 템플릿 사이에 무엇이 변경되는지 명시적으로 확인하십시오(어떤 섹션이 재구성되고, 나타나거나 사라지는지) — 이것이 단순한 표면적 변경이 아님을 분명히 하기 위해
이전 결정으로 생성된 파일이 이미 파일로 존재하는 경우 삭제하십시오(찌꺼기로 남기지 말고)
새 템플릿으로 처음부터 전체 파일을 다시 생성하되, 이미 수집된 사용자별 콘텐츠(필수 질문에 대한 답변, 이미 채워진 빈칸)는 재사용하고, 이전 파일의 구조는 재사용하지 마십시오.

권장하기 전에 필수 데이터

사용자가 언급하는 각 새로운 프로젝트에 대해(같은 대화에서 해당 특정 프로젝트에 대해 아직 제공되지 않은 경우) 질문하십시오:

해당 프로젝트의 폴더에 이미 CLAUDE.md가 있습니까? 예 / 아니요 / 모르겠음
몇 주/몇 달 동안 활발히 유지 관리될 예정입니까, 아니면 일회성/실험적입니까?
프로젝트 유형에 따라:
- 기술: 기술 스택(프레임워크, 언어) — 모르는 경우 유효한 답변이므로 강요하지 마십시오
- 비기술: 작업 도구 및 형식(예: Fountain, Final Draft, Google Docs, Word, Obsidian 폴더, 제작 스프레드시트) — 마찬가지로 '모르겠음'은 유효합니다
- 혼합: 두 질문 모두, 기술 질문과 도구/형식 질문. 서로를 대체하지 않습니다 — 프로젝트는 두 답변이 모두 필요합니다. 또한, 자신의 도구를 구축하는 동안 사용자가 콘텐츠(시나리오, 지식)를 위해 다른 외부 도구를 병렬로 계속 사용하는지 물어보십시오. 이 참조를 놓치지 않도록

프로젝트에 여러 개의 별도 작업 단계가 있는 경우(예: 연구/지식을 위한 도구와 실제 시나리오 작성을 위한 별도의 도구) 이 도구에 대한 질문은 종종 처음에 불완전합니다. 초기 응답이 하나의 도구만 언급하지만 프로젝트 유형이 둘 이상의 단계(연구를 통한 내러티브 개발 + 작성, 사전 제작을 통한 제작 + 촬영 + 후반 제작 등)가 있을 수 있음을 시사하는 경우, 하나의 도구가 전체 프로젝트를 포괄한다고 가정하지 말고 다른 단계를 위한 별도의 도구가 있는지 명시적으로 질문하십시오.

반복 금지 규칙: 응답은 현재 대화에서 동일한 프로젝트에 대해 이름으로 식별되어 명시적으로 제공된 경우에만 재사용됩니다. 다른 프로젝트에 대해 제공된 응답은 일반적으로 보이더라도(예: '프로젝트를 몇 달 동안 유지 관리합니다'가 프로젝트 A에 대해 말해졌다고 해서 자동으로 프로젝트 B에 적용되지는 않음) 절대 추정되지 않습니다.

CLAUDE.md를 채우는 데 필요한 특정 데이터가 사용자가 이미 공유한 내용에 없고 누락된 경우, 질문하십시오. 지어내지 마십시오. 유형에 따라 질문할 내용의 예:

기술: 진입점, 테스트/린트 명령어, 스타일 규칙, 폴더 구조
비기술: 프로젝트 폴더/문서 구조, 형식 규칙(씬 번호 매기기, 버전 명명 규칙), 작업 검토 또는 검증 방법(소리내어 읽기, 연속성 검토, 협업자 패스)

결정 규칙

기존 CLAUDE.md가 있음 → 진행 방법을 결정하기 전에 두 가지 경우를 구분하십시오:
- 실제 코드와 확인되지 않음: 사용자가 직접 작성했거나, 다른 곳에서 상속했거나, 채워지지 않은 빈칸(예: [PENDING] 마커, 미완성 플레이스홀더)이 있습니다. 이 경우 프로젝트에서 사용 가능한 마이그레이션 가이드(있는 경우)를 사용하여 선택한 템플릿으로 전환하고 사용자별 콘텐츠를 보존하는 것이 적용됩니다.
- Claude Code가 실제 저장소와 이미 확인함: 파일에는 코드에서 직접 추출된 기술적 세부 정보(실제 파일에서 관찰된 규칙, 특정 git 훅, 일반 템플릿에 문서화되지 않은 프로젝트 시스템 또는 도구, 추정이 아닌 확인된 테스트/린트 명령어)가 포함되어 있습니다. 실제 예: 프로젝트 자체 '지식 그래프' 시스템(예: graphify 도구)이 CLAUDE.md에 정확한 재구축 명령어와 그래프를 손상시키므로 사용하지 말아야 할 명령어에 대한 경고와 함께 문서화되어 있습니다. 이러한 세부 정보는 병합에서 손실되면 복구할 수 없습니다. 왜냐하면 일반 템플릿에서 이를 다루지 않고 저장소를 다시 검사하지 않으면 재구축할 수 없기 때문입니다. 이의 신호: 저장소를 읽지 않고는 생성할 수 없는 정확성과 특수성. 이 경우, 새 템플릿 구조를 강제로 적용하지 마십시오. 해당 콘텐츠는 템플릿보다 더 가치가 있습니다. 왜냐하면 프로젝트 현실에 대해 확인되었고 템플릿은 그렇지 않기 때문입니다. 사용자에게 아무 작업을 하기 전에 질문하십시오: 선택한 템플릿으로 병합할 경우 무엇을 잃을지(템플릿에 해당 항목이 없는 섹션 또는 기술 세부 정보)와 무엇을 얻을지(히스토리 구조, 메모리 뱅크 등, 아직 없는 경우) 보여주고, 사용자가 선택적 병합(개발 히스토리와 같이 누락된 부분만 추가하고 나머지는 건드리지 않음)을 원하는지 아니면 그대로 두기를 원하는지 결정하도록 하십시오.
- 기존 CLAUDE.md가 두 경우 중 어디에 속하는지 의심스러우면, 가정하지 말고 사용자에게 질문하십시오.
기존 CLAUDE.md가 없음 → 선택한 기본 템플릿으로 처음부터 생성하십시오.
새 프로젝트 또는 소규모 프로젝트, 기존 CLAUDE.md가 없고, 유지 관리가 일회성/실험적임 → 사용 가능한 가장 간결한 템플릿을 우선시하고, 더 이상 질문할 필요가 없습니다.
새 프로젝트 또는 소규모 프로젝트이지만 수 주/월간 유지 관리가 예상됨 → 이것은 상충되는 신호의 경우입니다('새 프로젝트'는 간결함을, '장기 유지 관리'는 더 완전한 템플릿을 권장합니다). 둘 중 하나를 조용히 해결하지 마십시오. 권장하기 전에 이 특정 프로젝트에서 사용자에게 무엇이 더 중요한지 명시적으로 질문하십시오.
유지 관리가 수 주/월간 → 컬렉션에 개발 히스토리 템플릿이 있으면 추가하십시오(히스토리는 비기술 프로젝트에도 동일하게 적용됩니다: 예: 시나리오 결정, 내러티브 구조 변경, 제작 이정표).
유지 관리가 일회성/실험적 → 개발 히스토리를 제안하지 마십시오.
특정 플랫폼/인프라 문서(Cloudflare, Convex, 데이터베이스, 인증 등) → 기술 프로젝트에만 적용됩니다. 전부 아니면 전무의 이진 결정이 아닙니다: 이러한 문서는 종종 동일한 플랫폼의 여러 다른 서비스를 다룹니다(예: Cloudflare 문서는 Workers, D1, KV, R2, Queues, Workers AI, Sandbox, Containers 및 여러 프레임워크에 대한 배포 가이드를 다룰 수 있음). 결정하기 전에 프로젝트가 실제로 어떤 서비스를 사용하는지 식별하십시오.
- 프로젝트가 문서에서 다루는 어떤 것도 사용하지 않는 경우 → 문서에서 아무것도 복사하지 말고, 적용되는 내용(예: 정적 배포만)을 CLAUDE.md 내에 3-6줄의 수동 요약으로 작성하십시오.
- 프로젝트가 문서의 실제 서비스 중 하나 이상을 사용하지만 문서가 프로젝트가 사용하는 것보다 더 많은 서비스를 다루는 경우 → 전체 파일을 복사하지 마십시오. 프로젝트가 실제로 사용하는 서비스에 해당하는 섹션만 추출하고 복사하고, 사용되지 않은 서비스의 섹션은 제외하십시오(동일한 파일에 있더라도). 사용자에게 명시적으로 말하십시오: 어떤 섹션이 포함되었고 어떤 섹션이 제외되었으며 그 이유는 무엇인지.
- 프로젝트가 문서에서 다루는 모든 서비스 또는 거의 모든 서비스를 효과적으로 사용하는 경우에만 전체 문서를 자르지 않고 복사하십시오.
사용자가 두 기본 템플릿 사이에서 망설이는 경우, 권장하기 전에 먼저 프로젝트 규모와 장기 유지 관리에 대해 질문하십시오(위의 필수 질문에서 이미 다루어짐).

비기술 프로젝트에 기본 템플릿 적용

프로젝트가 코드가 아닌 경우, 소프트웨어 개발을 위해 설계된 섹션을 문자 그대로 복사하지 마십시오. 어휘가 아닌 논리를 유지하면서 적용하십시오:

원본 기술 섹션	비기술 적용
Tech Stack	작업 도구 및 형식
Build, Test & Verify	무언가 올바른지 확인하는 방법(연속성 검토, 소리내어 읽기, 협업자 패스, 제작 체크리스트)
Code Style & Conventions	형식 및 스타일 규칙(씬 번호 매기기, 문서 버전 명명 규칙, 폴더 구조)
Architecture	프로젝트 구조(폴더, 주요 문서, 부분 순서)

Core Rules, Memory Bank 및 Development History 섹션은 개념적으로 동일하게 유지됩니다(주장하기 전에 조사, 요청된 범위를 벗어나지 않음, 결정 히스토리). 각 섹션 내의 예제 도메인만 변경됩니다.

혼합 프로젝트에 대한 CLAUDE.md 구성

단일 섹션 템플릿을 선택하지 마십시오: 두 가지를 결합하십시오. 혼합 프로젝트의 CLAUDE.md에는 다음이 필요합니다:

Tech Stack(기술) 및 창작 콘텐츠를 위한 도구/형식(비기술)은 Project Overview 내에서 두 개의 별도 항목으로, 모호한 한 줄로 병합되지 않아야 함
Build, Test & Verify는 실제 코드 명령어와 함께, 비기술 어휘로 번역하지 않고 — 이것은 여전히 컴파일 및 테스트되는 실제 소프트웨어임
비기술 프로젝트에서 '무언가 올바른지 확인하는 방법'에 들어갈 내용을 위한 추가 섹션('콘텐츠 및 창작 결정' 또는 유사한 이름) — 사용자가 가지고 있는 경우 도구가 수용할 내러티브/창작 콘텐츠에 대한 검토 기준
사용자가 자신의 앱을 구축하는 동안 병렬로 외부 도구를 계속 사용하는 경우, 명시적으로 기록하고 그것이 일시적임을 표시하십시오('앱 내에서 동등한 기능이 개발되는 동안'). 이것은 정적 추적되지 않는 메모로 남아서는 안 됩니다. '히스토리 항목 생성' 체크포인트에서(Development History 섹션 참조), 항목이 기록될 때마다 해당 도구 사용이 여전히 활성 상태인지 확인하고, 더 이상 필요하지 않으면 제거되었음을 표시하십시오.

생략된 콘텐츠

기본 템플릿을 적용할 때, 사용자에게 전달하기 전에 기본 템플릿에 포함된 설명적 내용이나 지침(예: '이 섹션은 ...을 위해 설계되었습니다'와 같은 소개)을 제거하십시오. 사용자 CLAUDE.md에는 지침(사용자가 제공한 답변에서 나온 구체적인 데이터)만 포함되어야 하며, 지침을 작성한 방법에 대한 설명은 포함되지 않아야 합니다. 결과 CLAUDE.md가 사용자에게 표시될 때 템플릿 지침이 아닌 일반 규칙처럼 읽히도록 하십시오.

마이그레이션 가이드가 기본 템플릿과 함께 있는 경우, 사용자에게 제안할 때 사용자 CLAUDE.md에서 지침을 제거하는 것과 동일한 규칙을 적용하십시오: 마이그레이션 프로세스 자체를 설명하는 텍스트는 포함하지 말고, 전환된 데이터(사용자별 콘텐츠가 있는 채워진 섹션)와 구조 변경 사항(어떤 섹션이 추가/제거/이동되었는지)만 포함하십시오.

CLAUDE.md 템플릿 선택기