Skip to main content

새 작업 도구

new_task 도구 및 컨텍스트 관리 전략​

개요​

Cline은 복잡하거나 장기 실행되는 작업 중에 워크플로 연속성 및 컨텍스트 보존을 관리하는 데 도움이 되도록 설계된 강력한 내부 도구인 new_task를 포함합니다. 이 도구는 Cline의 자체 컨텍스트 창 사용량 인식 및 .clinerules의 유연성과 결합되어 작업을 분해하고 작업 세션 간의 원활한 전환을 보장하기 위한 정교한 전략을 가능하게 합니다.

핵심 기능과 사용자 지정 규칙과의 상호 작용 방식을 이해하는 것이 이 기능을 효과적으로 활용하는 데 중요합니다.

핵심 기능​

두 가지 기본 기능은 고급 컨텍스트 관리를 가능하게 합니다.

  1. new_task 도구:
    • 기능: Cline이 사용자 승인에 따라 현재 작업 세션을 종료하고 즉시 새 세션을 시작할 수 있도록 합니다.
    • 컨텍스트 사전 로드: 결정적으로 Cline은 도구의 <context> 블록 내에 제공된 특정 컨텍스트로 이 새 작업 세션을 사전 로드할 수 있습니다. 이 컨텍스트는 Caret 또는 .clinerules 파일이 정의하는 모든 것일 수 있습니다. 요약, 코드 스니펫, 다음 단계, 프로젝트 상태 등.
  2. 컨텍스트 창 인식:
    • 추적: Cline은 작업 중에 현재 사용 중인 사용 가능한 컨텍스트 창의 백분율을 내부적으로 추적합니다.
    • 가시성: 이 정보는 Cline의 프롬프트에 제공된 environment_details에서 볼 수 있습니다.

/newtask 슬래시 명령 사용​

Cline이 newtask 도구를 제안하거나 복잡한 규칙을 정의하는 빠른 대안으로, 슬래시 명령을 사용하여 프로세스를 직접 시작할 수 있습니다.

  • 방법: 채팅 입력 필드에 /newtask를 입력하기만 하면 됩니다.
  • 작업: Cline은 일반적으로 현재 세션을 기반으로 컨텍스트를 제안하여 새 작업을 생성할 것을 제안합니다(도구를 사용할 때의 기본 동작과 유사). 새 작업이 생성되기 전에 컨텍스트를 확인하고 잠재적으로 수정하기 위해 ask_followup_question 프롬프트를 계속 받게 됩니다.
  • 이점: Cline이 제안할 때까지 기다릴 필요 없이 분기 탐색 또는 긴 세션 관리를 위해 new_task 기능을 활용하는 빠르고 사용자 시작 방식입니다.
note

/newtask 슬래시 명령 사용에 대한 자세한 내용은 새 작업 명령 문서를 참조하십시오.

기본 동작 (.clinerules 없음)​

기본적으로 특정 .clinerules가 동작을 지시하지 않는 경우:

  • 도구 가용성: new_task 도구가 존재하며 Cline은 이를 사용할 수 있습니다.
  • 컨텍스트 인식: Cline은 컨텍스트 사용량 백분율을 인식합니다.
  • 자동 트리거 없음: Cline은 컨텍스트 사용량이 특정 백분율(예: 50%)에 도달하는 것만으로 작업 핸드오프를 자동으로 시작하지 않습니다. new_task 사용을 제안하는 결정은 전체 작업 진행 상황 및 프롬프트 지침을 기반으로 하는 AI 모델의 추론에서 비롯됩니다.
  • 기본 컨텍스트 사전 로드: new_task가 <context> 블록 구조를 정의하는 특정 규칙 없이 사용되는 경우, Cline은 현재 이해를 기반으로 관련 정보(예: 진행 상황 및 다음 단계에 대한 기본 요약)를 사전 로드하려고 시도하지만, 이는 규칙 기반 접근 방식보다 덜 포괄적일 수 있습니다.

.clinerules의 힘: 사용자 지정 워크플로 활성화​

핵심 기능은 기본적으로 존재하지만, new_task 및 컨텍스트 인식을 .clinerules에 정의된 사용자 지정 워크플로와 결합할 때 진정한 힘, 자동화 및 사용자 지정이 나타납니다. 이를 통해 Cline이 컨텍스트 및 작업 연속성을 관리하는 시기와 방법을 정확하게 제어할 수 있습니다.

new_task와 함께 .clinerules를 사용하는 주요 이점:

  • 자동화된 컨텍스트 관리: 특정 컨텍스트 백분율(예: >50%, >70%) 또는 토큰 수에서 핸드오프를 자동으로 트리거하는 규칙을 정의하여 최적의 성능을 보장하고 컨텍스트 손실을 방지합니다.
  • 모델별 최적화: 특정 토큰 수를 초과하면 성능이 저하되는 것으로 알려진 모델의 경우 더 일찍 트리거하는 등 다양한 LLM에 대한 알려진 임계값을 기반으로 핸드오프 트리거를 조정합니다.
  • 지능형 중단점: 컨텍스트 임계값이 통과된 후 논리적 중단점(예: 함수 또는 테스트 완료 후)을 찾도록 규칙을 통해 Cline에 지시하여 더 깔끔한 핸드오프를 보장합니다.
  • 구조화된 작업 분해: 계획 모드를 사용하여 하위 작업을 정의한 다음, .clinerules를 사용하여 Cline이 각 하위 작업 완료 시 new_task를 통해 새 작업을 자동으로 생성하고 다음 하위 작업에 대한 컨텍스트를 사전 로드하도록 합니다.
  • 사용자 지정 컨텍스트 패키징: 매우 상세하고 일관된 핸드오프를 위해 .clinerules에서 <context> 블록의 정확한 구조와 내용을 의무화합니다(아래 예시 참조).
  • 향상된 메모리 지속성: new_task 컨텍스트 블록을 세션 간에 정보를 유지하는 기본 통합 방식으로 사용하여 파일 기반 메모리 시스템을 대체하거나 보완할 수 있습니다.
  • 워크플로 자동화: 특정 유형의 작업을 시작할 때 항상 특정 설정 지침 또는 프로젝트 상용구를 사전 로드하는 것과 같은 특정 시나리오에 대한 규칙을 정의합니다.

예시 규칙 기반 워크플로: 작업 핸드오프 프로세스​

아래 예시와 같은 특정 .clinerules에 의해 구동되는 일반적인 워크플로는 다음 단계를 포함합니다.

  1. 트리거 식별 (규칙 기반): Cline은 규칙에 정의된 핸드오프 지점(예: 컨텍스트 사용량 > 50%, 작업 완료)을 모니터링합니다.

  2. 사용자 확인: Cline은 ask_followup_question을 사용하여 새 작업을 생성할 것을 제안하며, 종종 규칙에 정의된 의도된 컨텍스트를 보여줍니다.

    <ask_followup_question>
    <question>[특정 성과]를 완료했으며 컨텍스트 사용량이 높습니다(XX%). 다음 컨텍스트를 사전 로드하여 [남은 작업]을 계속하기 위해 새 작업을 생성하시겠습니까?</question>
    <options>["예, 새 작업 생성", "먼저 컨텍스트 수정", "아니요, 이 세션 계속"]</options>
    </ask_follow_question>

  3. 사용자 제어: 새 작업이 생성되기 전에 컨텍스트를 승인, 거부 또는 Cline에 수정하도록 요청할 수 있습니다.

  4. 컨텍스트 패키징 (new_task 도구): 승인되면 Cline은 .clinerules에 의해 의무화된 구조에 따라 컨텍스트를 패키징하여 new_task를 사용합니다.

  5. 새 작업 생성: 현재 작업이 종료되고 지정된 컨텍스트로 사전 로드된 새 세션이 즉시 시작됩니다.

핸드오프 컨텍스트 블록 (규칙 정의 구조)​

규칙 기반 핸드오프의 효과는 .clinerules가 <context> 블록을 정의하는 방식에 크게 좌우됩니다. 포괄적인 구조는 종종 다음을 포함합니다.

  • ## 완료된 작업: 성과, 수정/생성된 파일, 주요 결정 사항에 대한 상세 목록.
  • ## 현재 상태: 프로젝트 상태, 실행 중인 프로세스, 주요 파일 상태.
  • ## 다음 단계: 남은 작업, 구현 세부 정보, 알려진 문제에 대한 명확하고 우선순위가 지정된 목록.
  • ## 참조 정보: 링크, 코드 스니펫, 패턴, 사용자 기본 설정.
  • 실행 가능한 시작: 즉각적인 다음 작업에 대한 명확한 지침.

잠재적 사용 사례 및 워크플로​

new_task와 .clinerules의 유연성은 많은 가능성을 열어줍니다.

  • 사전 예방적 컨텍스트 창 관리: 최적의 성능을 유지하기 위해 특정 백분율(예: 50%, 70%) 또는 토큰 수에서 핸드오프를 자동으로 트리거합니다.
  • 지능형 중단점: 컨텍스트 임계값이 통과된 후 논리적 중단점(예: 함수 또는 테스트 완료 후)을 찾도록 Cline에 지시하여 더 깔끔한 핸드오프를 보장합니다.
  • 구조화된 작업 분해: 계획 모드를 사용하여 하위 작업을 정의한 다음, .clinerules를 사용하여 Cline이 각 하위 작업 완료 시 new_task를 통해 새 작업을 자동으로 생성하도록 합니다.
  • 자동화된 세션 요약: 이전 세션의 주요 논의 지점에 대한 요약을 항상 포함하도록 <context> 블록을 구성합니다.
  • 상용구/설정 사전 로드: 특정 프로젝트와 관련된 새 작업을 표준 설정 지침 또는 파일 템플릿으로 사전 로드하여 시작합니다.
  • "메모리 뱅크" 대안: new_task 컨텍스트 블록을 세션 간에 정보를 유지하는 기본 방식으로 사용하여 파일 기반 메모리 시스템을 잠재적으로 대체합니다.

필요에 가장 적합한 워크플로를 찾기 위해 .clinerules를 실험해 보는 것이 좋습니다!

예시 .clinerules: 작업 핸드오프 전략 가이드​

아래는 컨텍스트 창 관리를 위해 new_task를 사용하는 데 특별히 초점을 맞춘 .clinerules 파일의 예시입니다. 이는 단지 하나의 특정 전략일 뿐이며, 핵심 new_task 도구는 다른 사용자 지정 규칙과 다르게 사용될 수 있음을 기억하십시오.

# `new_task` 도구를 사용해야 합니다: 작업 핸드오프 전략 가이드

**⚠️ 중요 지침 - 다음 지침을 반드시 따라야 합니다 ⚠️**

이 가이드는 복잡한 작업을 효과적으로 분해하고 작업 간의 원활한 핸드오프 프로세스를 구현하기 위한 **필수** 지침을 제공합니다. 연속성, 컨텍스트 보존 및 효율적인 작업 완료를 보장하기 위해 다음 지침을 **반드시** 따라야 합니다.

## ⚠️ 컨텍스트 창 모니터링 - 필수 작업 필요 ⚠️

환경 세부 정보에 표시된 컨텍스트 창 사용량을 **반드시** 모니터링해야 합니다. 사용량이 사용 가능한 컨텍스트 창의 50%를 초과하면 `new_task` 도구를 사용하여 작업 핸드오프를 **반드시** 시작해야 합니다.

200K 컨텍스트 창에서 컨텍스트 창 사용량이 50%를 초과하는 예시:

\`\`\`text

# 컨텍스트 창 사용량

105,000 / 200,000 토큰 (53%)
모델: anthropic/claude-sonnet-4 (200K 컨텍스트 창)
\`\`\`

**중요**: 컨텍스트 창 사용량이 50% 이상인 경우 **반드시** 다음을 수행해야 합니다.

1.  현재 논리적 단계를 완료합니다.
2.  `ask_followup_question` 도구를 사용하여 새 작업을 생성할 것을 제안합니다.
3.  승인되면 포괄적인 핸드오프 지침과 함께 `new_task` 도구를 사용합니다.

## 계획 모드에서 작업 분해 - 필수 프로세스

계획 모드는 복잡한 작업을 분석하고 관리 가능한 하위 작업으로 분해하도록 특별히 설계되었습니다. 계획 모드에 있을 때 **반드시** 다음을 수행해야 합니다.

### 1. 초기 작업 분석 - 필수

-   사용자의 요청 전체 범위를 철저히 이해하는 것으로 **반드시** 시작해야 합니다.
-   작업의 모든 주요 구성 요소 및 종속성을 **반드시** 식별해야 합니다.
-   잠재적인 문제, 예외 사례 및 전제 조건을 **반드시** 고려해야 합니다.

### 2. 전략적 작업 분해 - 필수

-   전체 작업을 논리적이고 개별적인 하위 작업으로 **반드시** 분해해야 합니다.
-   종속성을 기반으로 하위 작업의 우선순위를 **반드시** 지정해야 합니다(무엇이 먼저 완료되어야 하는지).
-   단일 세션(15-30분 작업) 내에서 완료할 수 있는 하위 작업을 **반드시** 목표로 해야 합니다.
-   컨텍스트 전환이 합리적인 자연스러운 중단점을 **반드시** 고려해야 합니다.

### 3. 작업 로드맵 생성 - 필수

-   사용자에게 명확하고 번호가 매겨진 하위 작업 목록을 **반드시** 제시해야 합니다.
-   하위 작업 간의 종속성을 **반드시** 설명해야 합니다.
-   가능한 경우 각 하위 작업에 대한 예상 시간을 **반드시** 제공해야 합니다.
-   도움이 되는 경우 Mermaid 다이어그램을 사용하여 작업 흐름 및 종속성을 **반드시** 시각화해야 합니다.

\`\`\`mermaid
graph TD
A[주요 작업] --> B[하위 작업 1: 설정]
A --> C[하위 작업 2: 핵심 구현]
A --> D[하위 작업 3: 테스트]
A --> E[하위 작업 4: 문서화]
B --> C
C --> D
\`\`\`

### 4. 사용자 승인 받기 - 필수

-   제안된 작업 분해에 대한 사용자 피드백을 **반드시** 요청해야 합니다.
-   사용자 우선순위 또는 추가 요구 사항에 따라 계획을 **반드시** 조정해야 합니다.
-   시작할 하위 작업을 **반드시** 확인해야 합니다.
-   구현 준비가 되면 사용자에게 Act 모드로 전환하도록 **반드시** 요청해야 합니다.

## 작업 구현 및 핸드오프 프로세스 - 필수 절차

Act 모드에서 작업을 구현할 때 효과적인 작업 핸드오프를 위해 다음 지침을 **반드시** 따라야 합니다.

### 1. 집중 구현 - 필수

-   현재 하위 작업을 완전히 완료하는 데 **반드시** 집중해야 합니다.
-   주석 및 커밋 메시지를 통해 진행 상황을 명확하게 **반드시** 문서화해야 합니다.
-   논리적 완료 지점에서 체크포인트를 **반드시** 생성해야 합니다.

### 2. 완료 지점 인식 - 중요

다음과 같은 경우 자연스러운 핸드오프 지점을 **반드시** 식별해야 합니다.

-   현재 하위 작업이 완전히 완료되었습니다.
-   더 큰 하위 작업에서 논리적 중단점에 도달했습니다.
-   구현이 예상보다 오래 걸리고 나중에 계속할 수 있습니다.
-   작업 범위가 원래 계획을 넘어 확장되었습니다.
-   **중요**: 컨텍스트 창 사용량이 50%를 초과합니다(예: 200K 컨텍스트 창의 경우 100,000개 이상의 토큰).

### 3. 핸드오프 프로세스 시작 - 필수 작업

완료 지점에 도달하면 **반드시** 다음을 수행해야 합니다.

1.  지금까지 달성한 내용을 요약합니다.
2.  남은 작업을 명확하게 명시합니다.
3.  **필수**: `ask_followup_question` 도구를 사용하여 새 작업을 생성할 것을 제안합니다.

\`\`\`xml
<ask_followup_question>
<question>[특정 성과]를 완료했습니다. [남은 작업]을 계속하기 위해 새 작업을 생성하시겠습니까?</question>
<options>["예, 새 작업 생성", "아니요, 이 세션 계속", "생각해볼게요"]</options>
</ask_follow_question>
\`\`\`

### 4. 컨텍스트와 함께 새 작업 생성 - 필수 작업

사용자가 새 작업 생성을 동의하면 포괄적인 핸드오프 지침과 함께 `new_task` 도구를 **반드시** 사용해야 합니다.

\`\`\`xml
<new_task>
<context>

# 작업 연속: [간략한 작업 제목]

## 완료된 작업

-   [완료된 항목의 상세 목록]
-   [수정/생성된 특정 파일 포함]
-   [내려진 중요한 결정 사항 기록]

## 현재 상태

-   [프로젝트의 현재 상태 설명]
-   [실행 중인 프로세스 또는 환경 설정]
-   [주요 파일 및 현재 상태]

## 다음 단계

-   [남은 작업의 상세 목록]
-   [다룰 특정 구현 세부 정보]
-   [알려진 문제점]

## 참조 정보

-   [관련 문서 링크]
-   [따라야 할 중요한 코드 스니펫 또는 패턴]
-   [현재 세션 중에 기록된 사용자 기본 설정]

[특정 다음 작업]을 통해 구현을 계속하십시오.
</context>
</new_task>
\`\`\`

### 5. 상세 컨텍스트 전송 - 필수 구성 요소

새 작업을 생성할 때 **반드시** 항상 다음을 포함해야 합니다.

#### 프로젝트 컨텍스트 - 필수

-   프로젝트의 전반적인 목표와 목적을 **반드시** 포함해야 합니다.
-   주요 아키텍처 결정 및 패턴을 **반드시** 포함해야 합니다.
-   기술 스택 및 종속성을 **반드시** 포함해야 합니다.

#### 구현 세부 정보 - 필수

-   현재 세션에서 생성 또는 수정된 파일을 **반드시** 나열해야 합니다.
-   구현된 특정 함수, 클래스 또는 구성 요소를 **반드시** 설명해야 합니다.
-   따라야 할 디자인 패턴을 **반드시** 설명해야 합니다.
-   테스트 접근 방식을 **반드시** 개략적으로 설명해야 합니다.

#### 진행 상황 추적 - 필수

-   완료된 항목의 체크리스트를 **반드시** 제공해야 합니다.
-   남은 항목의 체크리스트를 **반드시** 제공해야 합니다.
-   발생한 모든 차단 또는 문제를 **반드시** 기록해야 합니다.

#### 사용자 기본 설정 - 필수

-   사용자가 언급한 코딩 스타일 기본 설정을 **반드시** 기록해야 합니다.
-   사용자가 요청한 특정 접근 방식을 **반드시** 문서화해야 합니다.
-   사용자가 식별한 우선순위 영역을 **반드시** 강조해야 합니다.

## 효과적인 핸드오프를 위한 모범 사례 - 필수 지침

### 1. 연속성 유지 - 필수

-   작업 간에 일관된 용어를 **반드시** 사용해야 합니다.
-   이전 결정 및 그 근거를 **반드시** 참조해야 합니다.
-   명시적으로 방향을 변경하지 않는 한 동일한 아키텍처 접근 방식을 **반드시** 유지해야 합니다.

### 2. 컨텍스트 보존 - 필수

-   핸드오프에 관련 코드 스니펫을 **반드시** 포함해야 합니다.
-   이전 세션의 주요 논의를 **반드시** 요약해야 합니다.
-   해당하는 경우 특정 파일 및 줄 번호를 **반드시** 참조해야 합니다.

### 3. 명확한 다음 작업 설정 - 필수

-   명확하고 실행 가능한 다음 단계로 핸드오프를 **반드시** 시작해야 합니다.
-   남은 작업의 우선순위를 **반드시** 지정해야 합니다.
-   내려야 할 모든 결정을 **반드시** 강조해야 합니다.

### 4. 가정 문서화 - 필수

-   구현 중에 이루어진 모든 가정을 **반드시** 명확하게 명시해야 합니다.
-   사용자 입력이 필요할 수 있는 영역을 **반드시** 기록해야 합니다.
-   잠재적인 대체 접근 방식을 **반드시** 식별해야 합니다.

### 5. 재개 가능성 최적화 - 필수

-   다음 세션이 즉시 작업을 시작할 수 있도록 핸드오프를 **반드시** 구성해야 합니다.
-   환경 구성이 필요한 경우 설정 지침을 **반드시** 포함해야 합니다.
-   빠른 컨텍스트 복원을 위해 상단에 빠른 요약을 **반드시** 제공해야 합니다.

## 예시 작업 핸드오프

### 효과적인 작업 핸드오프의 예시 #1:

\`\`\`xml
<new_task>
<context>

# 작업 연속: 사용자 인증 시스템 구현

## 완료된 작업

-   기본 Express.js 서버 구조 생성
-   MongoDB 연결 및 사용자 스키마 구현
-   비밀번호 해싱을 통한 사용자 등록 엔드포인트 완료
-   Joi를 사용한 입력 유효성 검사 추가
-   등록 엔드포인트에 대한 초기 테스트 스위트 생성

## 현재 상태

-   서버가 포트 3000에서 성공적으로 실행 중입니다.
-   MongoDB 연결이 설정되었습니다.
-   등록 엔드포인트(/api/users/register)가 완전히 작동합니다.
-   모든 등록 시나리오에 대한 테스트 스위트가 통과합니다.

## 다음 단계

1.  로그인 엔드포인트(/api/users/login) 구현
    -   비밀번호 비교를 위해 bcrypt 사용
    -   성공적인 로그인 시 JWT 토큰 생성
    -   잘못된 자격 증명에 대한 적절한 오류 처리 추가
2.  인증 미들웨어 생성
    -   JWT 토큰 확인
    -   사용자 정보 추출
    -   만료된 토큰 처리
3.  인증이 필요한 보호된 경로 추가
4.  비밀번호 재설정 기능 구현

## 참조 정보

-   JWT 비밀은 .env 파일에 저장되어야 합니다.
-   routes/users.js에 있는 기존 오류 처리 패턴을 따르십시오.
-   사용자 스키마는 models/User.js에 정의되어 있습니다.
-   테스트 패턴은 tests/auth.test.js에 설정되어 있습니다.

등록 엔드포인트에 설정된 동일한 패턴을 따라 로그인 엔드포인트를 구현하여 계속하십시오.
</context>
</new_task>
\`\`\`

### 비효율적인 작업 핸드오프의 예시 #2:

_(참고: 원본 규칙에 제공된 "YOLO MODE 구현" 예시는 직접적인 핸드오프 컨텍스트 블록이라기보다는 미래 고려 사항이 포함된 일반적인 상태 업데이트에 가깝습니다. 진정한 비효율적인 핸드오프는 '현재 상태' 또는 '다음 단계'에 대한 세부 정보가 부족할 수 있습니다.)_

## 작업 핸드오프 사용 시기 - 필수 트리거

다음 시나리오에서 작업 핸드오프를 **반드시** 시작해야 합니다.

1.  **중요**: 컨텍스트 창 사용량이 50%를 초과할 때(예: 200K 컨텍스트 창의 경우 100,000개 이상의 토큰)
2.  단일 세션을 초과하는 **장기 실행 프로젝트**
3.  여러 개의 개별 단계가 있는 **복잡한 구현**
4.  **컨텍스트 창 제한**에 접근할 때
5.  더 큰 프로젝트 내에서 **초점 영역을 전환할 때**
6.  작업의 다른 부분에 대해 **다른 전문 지식**이 도움이 될 수 있을 때

**⚠️ 최종 알림 - 중요 지침 ⚠️**

환경 세부 정보 섹션에서 컨텍스트 창 사용량을 **반드시** 모니터링해야 합니다. 50%를 초과하면(예: "105,000 / 200,000 토큰 (53%)"), `ask_follow_up_question` 도구와 `new_task` 도구를 사용하여 작업 핸드오프 프로세스를 **반드시** 사전에 시작해야 합니다. `new_task` 도구를 **반드시** 사용해야 합니다.

이러한 지침을 엄격하게 따르면 작업 간의 원활한 전환을 보장하고 프로젝트 추진력을 유지하며 복잡한 다중 세션 프로젝트에서 작업하는 사용자에게 최상의 경험을 제공할 수 있습니다.

```markdown
## 사용자 상호 작용 및 워크플로 고려 사항

-   **선형 흐름:** 현재 `new_task`를 사용하면 선형 시퀀스가 생성됩니다. 이전 작업이 종료되고 새 작업이 시작됩니다. 이전 작업 기록은 되돌아가기 위해 계속 액세스할 수 있습니다.
-   **사용자 승인:** 항상 제어권을 가지며, 핸드오프를 승인하고 Cline이 전달할 컨텍스트를 수정할 기회를 가집니다.
-   **유연성:** 핵심 `new_task` 도구는 유연한 구성 요소입니다. 엄격한 컨텍스트 관리, 작업 분해 또는 기타 창의적인 용도 등 필요에 가장 적합한 워크플로를 생성하기 위해 `.clinerules`를 실험해 보십시오.