워크플로

워크플로를 사용하면 서비스 배포 또는 PR 제출과 같이 반복적인 작업 집합을 통해 Cline을 안내하는 일련의 단계를 정의할 수 있습니다.

워크플로를 호출하려면 채팅에 /[workflow-name.md]를 입력합니다.

워크플로 생성 및 사용 방법

워크플로는 Cline 규칙과 함께 존재합니다. 만드는 방법은 간단합니다.

1. Cline이 수행해야 할 단계에 대한 명확한 지침이 포함된 마크다운 파일을 만듭니다.
2. 워크플로 디렉터리에 .md 확장자로 저장합니다.
3. 워크플로를 트리거하려면 / 다음에 워크플로 파일 이름을 입력하기만 하면 됩니다.
4. 메시지가 표시되면 필요한 매개변수를 제공합니다.

진정한 힘은 워크플로 파일을 구성하는 방식에서 비롯됩니다. 다음을 수행할 수 있습니다.

• ask_followup_question, read_file, search_files 및 new_task와 같은 Cline의 기본 제공 도구를 활용합니다.
• gh 또는 docker와 같이 이미 설치한 명령줄 도구를 사용합니다.
• Slack 또는 Whatsapp과 같은 외부 MCP 도구 호출을 참조합니다.
• 여러 작업을 특정 순서로 함께 연결합니다.

실제 예시

많은 시간을 절약해 주는 PR 검토 워크플로를 만들었습니다.

pr-review.md [확장 가능]

`gh` 터미널 명령어에 액세스할 수 있습니다. 이미 인증해 드렸습니다. 검토하도록 요청한 PR을 사용하려면 검토하십시오. 이미 `cline` 리포지토리에 있습니다.

<detailed_sequence_of_steps>

# GitHub PR 검토 프로세스 - 상세 단계 순서

## 1. PR 정보 수집

1. PR 제목, 설명 및 댓글 가져오기:

    ```bash
    gh pr view <PR-번호> --json title,body,comments
    ```

2. PR의 전체 diff 가져오기:
    ```bash
    gh pr diff <PR-번호>
    ```

## 2. 컨텍스트 이해

1. PR에서 수정된 파일 식별:

    ```bash
    gh pr view <PR-번호> --json files
    ```

2. 컨텍스트를 이해하기 위해 기본 브랜치의 원본 파일 검토:

    ```xml
    <read_file>
    <path>path/to/file</path>
    </read_file>
    ```

3. 파일의 특정 섹션에 대해 search_files를 사용할 수 있습니다.
    ```xml
    <search_files>
    <path>path/to/directory</path>
    <regex>검색어</regex>
    <file_pattern>*.ts</file_pattern>
    </search_files>
    ```

## 3. 변경 사항 분석

1. 수정된 각 파일에 대해 다음을 이해합니다.

    - 변경된 내용
    - 변경된 이유(PR 설명 기준)
    - 코드베이스에 미치는 영향
    - 잠재적인 부작용

2. 다음을 찾습니다.
    - 코드 품질 문제
    - 잠재적인 버그
    - 성능 영향
    - 보안 문제
    - 테스트 커버리지

## 4. 사용자 확인 요청

1. 결정을 내리기 전에 평가 및 근거를 제공하여 PR을 승인해야 하는지 사용자에게 문의합니다.

    ```xml
    <ask_followup_question>
    <question>PR #<PR-번호> 검토 결과 [승인/변경 요청]을 권장합니다. 근거는 다음과 같습니다.

    [PR 품질, 구현 및 우려 사항에 대한 주요 내용이 포함된 상세한 근거]

    이 권장 사항을 진행하시겠습니까?</question>
    <options>["예, PR 승인", "예, 변경 요청", "아니요, 추가 논의가 필요합니다"]</options>
    </ask_followup_question>
    ```

## 5. 사용자에게 댓글 초안 작성 여부 문의

1. 사용자가 승인/거부를 결정한 후 댓글 초안 작성을 원하는지 문의합니다.

    ```xml
    <ask_followup_question>
    <question>복사하여 붙여넣을 수 있도록 이 PR에 대한 댓글 초안을 작성하시겠습니까?</question>
    <options>["예, 댓글 초안을 작성해 주세요", "아니요, 제가 직접 댓글을 작성하겠습니다"]</options>
    </ask_followup_question>
    ```

2. 사용자가 댓글 초안 작성을 원하는 경우 복사할 수 있는 잘 구성된 댓글을 제공합니다.

    ```
    이 PR에 감사드립니다! 평가는 다음과 같습니다.

    [PR 품질, 구현 및 제안 사항에 대한 주요 내용이 포함된 상세한 평가]

    [코드 품질, 기능 및 테스트에 대한 특정 피드백 포함]
    ```

## 6. 결정 내리기

1. 품질 표준을 충족하는 경우 PR 승인:

    ```bash
    # 한 줄 댓글의 경우:
    gh pr review <PR-번호> --approve --body "승인 메시지"

    # 적절한 공백 서식이 지정된 여러 줄 댓글의 경우:
    cat << EOF | gh pr review <PR-번호> --approve --body-file -
    이 PR에 대해 @username님께 감사드립니다! 구현이 좋아 보입니다.

    특히 X와 Y를 처리한 방식이 마음에 듭니다.

    훌륭한 작업입니다!
    EOF
    ```

2. 개선이 필요한 경우 변경 요청:

    ```bash
    # 한 줄 댓글의 경우:
    gh pr review <PR-번호> --request-changes --body "피드백 메시지"

    # 적절한 공백 서식이 지정된 여러 줄 댓글의 경우:
    cat << EOF | gh pr review <PR-번호> --request-changes --body-file -
    이 PR에 대해 @username님께 감사드립니다!

    구현이 유망해 보이지만 몇 가지 해결해야 할 사항이 있습니다.

    1. 문제 하나
    2. 문제 둘

    이러한 변경 사항을 적용하면 병합할 수 있습니다.
    EOF
    ```

    참고: `cat << EOF | ... --body-file -` 접근 방식은 임시 파일 없이 모든 공백과 서식을 유지합니다. `-` 매개변수는 명령이 표준 입력에서 읽도록 지시합니다.
    </detailed_sequence_of_steps>

<example_review_process>

# 예제 PR 검토 프로세스

Claude 3.7 모델의 생각 모드 계산을 수정하는 PR #3627을 검토하는 실제 예를 살펴보겠습니다.

## 1단계: PR 정보 수집

```bash
# PR 세부 정보 가져오기
gh pr view 3627 --json title,body,comments

# 전체 diff 가져오기
gh pr diff 3627
```

## 2단계: 컨텍스트 이해

```xml
# 변경되는 내용을 이해하기 위해 원본 파일 검토
<read_file>
<path>src/shared/api.ts</path>
</read_file>

# ThinkingBudgetSlider 구성 요소 구현 살펴보기
<read_file>
<path>webview-ui/src/components/settings/ThinkingBudgetSlider.tsx</path>
</read_file>

# API 공급자에서 현재 생각 모드가 처리되는 방식 확인
<search_files>
<path>src/api/providers</path>
<regex>reasoningOn</regex>
<file_pattern>*.ts</file_pattern>
</search_files>
```

## 3단계: 변경 사항 분석

PR 정보 및 코드 검토를 통해 다음을 알 수 있습니다.

1. PR은 Claude 3.7 모델의 생각 모드 예산 계산 문제를 수정합니다.
2. 현재 생각 예산은 maxTokens(8192)의 80%로 잘못 계산되어 6553개의 토큰이 됩니다.
3. Claude 3.7은 실제로 훨씬 더 큰 생각 예산(최대 64000개 토큰)을 지원합니다.
4. PR은 모델 정의에 `maxBudget: 64000`이 있는 `thinkingConfig` 속성을 추가합니다.
5. 추론 모드가 활성화되면 이 값을 사용하도록 API 처리기를 업데이트합니다.
6. 모델별 백분율을 기반으로 최대값을 계산하도록 슬라이더 구성 요소를 향상시킵니다.
7. 계산을 확인하기 위해 포괄적인 테스트가 추가되었습니다.

## 4단계: 사용자 확인 요청

```xml
<ask_followup_question>
<question>PR #3627 검토 결과 이 PR을 승인하는 것이 좋습니다. 근거는 다음과 같습니다.

1. PR은 Claude 3.7 모델의 생각 모드 예산 계산을 올바르게 수정합니다.
2. Claude 3.7 모델에 대해 thinkingConfig.maxBudget 속성(64000)을 올바르게 구현합니다.
3. 슬라이더 계산에 적절한 백분율(50%)을 적용합니다.
4. 변경 사항은 포괄적인 단위 테스트를 통해 잘 테스트되었습니다.
5. 구현이 깔끔하고 프로젝트의 코딩 표준을 따릅니다.
6. PR에는 수정 사항을 보여주는 유용한 스크린샷이 포함되어 있습니다.

이 PR 승인을 진행하시겠습니까?</question>
<options>["예, PR 승인", "아니요, 추가 논의가 필요합니다", "먼저 직접 검토하겠습니다"]</options>
</ask_followup_question>
```

## 5단계: 사용자에게 댓글 초안 작성 여부 문의

```xml
<ask_followup_question>
<question>복사하여 붙여넣을 수 있도록 이 PR에 대한 댓글 초안을 작성하시겠습니까?</question>
<options>["예, 댓글 초안을 작성해 주세요", "아니요, 제가 직접 댓글을 작성하겠습니다"]</options>
</ask_followup_question>
```

## 6단계: 결정 내리기

```bash
# 옵션 1: 간단한 한 줄 댓글
gh pr review 3627 --approve --body "이 PR은 좋아 보입니다! Claude 3.7 모델의 생각 모드 예산 계산을 올바르게 수정합니다."

# 옵션 2: 적절한 공백 서식이 지정된 여러 줄 댓글
cat << EOF | gh pr review 3627 --approve --body-file -
이 PR은 좋아 보입니다! Claude 3.7 모델의 생각 모드 예산 계산을 올바르게 수정합니다.

특히 마음에 드는 점은 다음과 같습니다.
1. thinkingConfig.maxBudget 속성(64000)의 올바른 구현
2. 슬라이더 계산을 위한 적절한 백분율(50%)
3. 포괄적인 단위 테스트
4. 프로젝트 코딩 표준을 따르는 깔끔한 구현

훌륭한 작업입니다!
EOF
```

</example_review_process>

<common_gh_commands>

# PR 검토를 위한 일반적인 GitHub CLI 명령어

## 기본 PR 명령어

```bash
# 열린 PR 목록
gh pr list

# 특정 PR 보기
gh pr view <PR-번호>

# 특정 필드가 있는 PR 보기
gh pr view <PR-번호> --json title,body,comments,files,commits

# PR 상태 확인
gh pr status
```

## Diff 및 파일 명령어

```bash
# PR의 전체 diff 가져오기
gh pr diff <PR-번호>

# PR에서 변경된 파일 목록
gh pr view <PR-번호> --json files

# 로컬에서 PR 체크아웃
gh pr checkout <PR-번호>
```

## 검토 명령어

```bash
# PR 승인(한 줄 댓글)
gh pr review <PR-번호> --approve --body "승인 메시지"

# PR 승인(적절한 공백이 있는 여러 줄 댓글)
cat << EOF | gh pr review <PR-번호> --approve --body-file -
여러 줄
승인 메시지(적절한 공백 서식 지정 포함)
EOF

# PR 변경 요청(한 줄 댓글)
gh pr review <PR-번호> --request-changes --body "피드백 메시지"

# PR 변경 요청(적절한 공백이 있는 여러 줄 댓글)
cat << EOF | gh pr review <PR-번호> --request-changes --body-file -
여러 줄
변경 요청(적절한 공백 서식 지정 포함)
EOF

# 댓글 검토 추가(승인/거부 없이)
gh pr review <PR-번호> --comment --body "댓글 메시지"

# 적절한 공백이 있는 댓글 검토 추가
cat << EOF | gh pr review <PR-번호> --comment --body-file -
여러 줄
댓글(적절한 공백 서식 지정 포함)
EOF
```

## 추가 명령어

```bash
# PR 검사 상태 보기
gh pr checks <PR-번호>

# PR 커밋 보기
gh pr view <PR-번호> --json commits

# PR 병합(권한이 있는 경우)
gh pr merge <PR-번호> --merge
```

</common_gh_commands>

<general_guidelines_for_commenting>
PR을 검토할 때는 평소처럼 친근한 검토자처럼 이야기하십시오. 간결하게 작성하고 PR 작성자에게 감사 인사를 전하고 @ 언급하는 것으로 시작해야 합니다.

PR을 승인하든 안 하든 너무 장황하거나 단정적이지 않게 변경 사항에 대한 간략한 요약을 제공하고 이것이 변경 사항에 대한 귀하의 이해라는 겸손한 태도를 유지해야 합니다. 지금 제가 당신에게 말하는 방식과 비슷합니다.

제안 사항이나 변경해야 할 사항이 있으면 PR을 승인하는 대신 변경을 요청하십시오.

코드에 인라인 댓글을 남기는 것은 좋지만 코드에 대해 구체적으로 할 말이 있는 경우에만 그렇게 하십시오. 그리고 해당 댓글을 먼저 남긴 다음 변경하도록 요청하는 내용의 전반적인 주제를 설명하는 짧은 댓글과 함께 PR에 변경을 요청하십시오.
</general_guidelines_for_commenting>

<example_comments_that_i_have_written_before>
<brief_approve_comment>
좋아 보이지만 언젠가는 모든 공급자 및 모델에 대해 일반화해야 합니다.
</brief_approve_comment>
<brief_approve_comment>
OR/Gemini에서 일치하지 않을 수 있는 모델(예: 생각 모델)에서도 작동합니까?
</brief_approve_comment>
<approve_comment>
정말 멋져 보입니다! 전역 엔드포인트 지원을 처리한 방식이 마음에 듭니다. 다른 모델 기능을 처리하는 방식과 유사하게 ModelInfo 인터페이스에 추가하는 것이 합리적입니다.

필터링된 모델 목록 접근 방식은 깔끔하며 전역 엔드포인트와 함께 작동하는 모델을 하드코딩하는 것보다 유지 관리가 더 쉬울 것입니다. 그리고 이것이 작동하려면 genai 라이브러리를 범핑해야 했습니다.

제한 사항에 대한 문서도 추가해 주셔서 감사합니다. 사용자가 전역 엔드포인트와 함께 컨텍스트 캐시를 사용할 수 없지만 429 오류가 줄어들 수 있다는 것을 아는 것이 좋습니다.
</approve_comment>
<requesst_changes_comment>
정말 멋집니다. @scottsus님 감사합니다.

하지만 제 주요 관심사는 이것이 가능한 모든 VS Code 테마에서 작동하는지 여부입니다. 처음에는 이것 때문에 어려움을 겪었기 때문에 현재는 스타일이 그다지 적용되지 않았습니다. 병합하기 전에 다른 테마로 테스트하고 스크린샷을 공유해 주십시오.
</request_changes_comment>
<request_changes_comment>
안녕하세요, PR은 전반적으로 좋아 보이지만 해당 시간 초과를 제거하는 것에 대해 우려됩니다. 해당 시간 초과는 아마도 이유가 있었을 것입니다. VSCode의 UI는 타이밍에 민감할 수 있습니다.

사이드바에 포커스를 맞춘 후 시간 초과를 다시 추가해 주시겠어요? 다음과 같이요.

```typescript
await vscode.commands.executeCommand("claude-dev.SidebarProvider.focus")
await setTimeoutPromise(100) // UI가 업데이트될 시간을 줍니다.
visibleWebview = WebviewProvider.getSidebarInstance()
```

</request_changes_comment>
<request_changes_comment>
안녕하세요 @alejandropta님, 이 작업에 참여해 주셔서 감사합니다!

몇 가지 참고 사항:
1 - 환경 변수에 추가 정보를 추가하는 것은 환경 변수가 **모든 단일 메시지**에 추가되기 때문에 상당히 문제가 됩니다. 다소 틈새 사용 사례에 대해 이것이 정당화될 수 있다고 생각하지 않습니다.
2 - 이를 포함하도록 설정에 이 옵션을 추가하는 것은 옵션이 될 수 있지만 새로운 사용자를 위해 옵션이 간단하고 명확하기를 바랍니다.
3 - 설정 페이지가 표시/구성되는 방식을 재시각화하는 작업을 진행 중이며 설정 페이지가 더 명확하게 구분되면 잠재적으로 조정될 수 있습니다.

따라서 설정 페이지가 업데이트되고 이것이 새로운 사용자를 혼란스럽게 하지 않는 깔끔한 방식으로 설정에 추가될 때까지는 이것을 병합할 수 없을 것 같습니다. 양해 바랍니다.
</request_changes_comment>
<request_changes_comment>
또한 사용자에게 영향을 미치는 버그를 수정하므로 변경 집합을 추가하는 것을 잊지 마십시오.

아키텍처 변경은 견고합니다. 포커스 논리를 명령어 처리기로 옮기는 것이 합리적입니다. 단지 해당 시간 초과를 제거하여 미묘한 타이밍 문제를 발생시키고 싶지 않을 뿐입니다.
</request_changes_comment>
</example_comments_that_i_have_written_before>

검토할 새 PR을 받으면 수동으로 컨텍스트를 수집하곤 했습니다. PR 설명을 확인하고, diff를 검토하고, 주변 파일을 살펴보고, 마침내 의견을 형성했습니다. 이제는 다음을 수행합니다.

1. 채팅에 /pr-review.md를 입력합니다.
2. PR 번호를 붙여넣습니다.
3. 나머지는 Cline이 처리하도록 합니다.

제 워크플로는 gh 명령줄 도구와 Cline의 기본 제공 ask_followup_question을 사용하여 다음을 수행합니다.

• PR 설명 및 댓글 가져오기
• diff 검토
• 컨텍스트를 위해 주변 파일 확인
• 잠재적인 문제 분석
• 모든 것이 좋아 보이면 승인해야 하는 이유와 함께 승인해도 괜찮은지 묻습니다.
• “예”라고 말하면 Cline이 gh 명령으로 PR을 자동으로 승인합니다.

이를 통해 PR 검토 프로세스가 수동적인 다단계 작업에서 정보에 입각한 결정을 내리는 데 필요한 모든 것을 제공하는 단일 명령으로 바뀌었습니다.

이것은 워크플로 파일의 한 가지 예일 뿐입니다. 영감을 얻기 위해 프롬프트 리포지토리에서 더 많은 것을 찾을 수 있습니다.

나만의 워크플로 구축

워크플로의 장점은 필요에 따라 완전히 사용자 지정할 수 있다는 것입니다. 다음과 같은 모든 종류의 반복적인 작업에 대한 워크플로를 만들 수 있습니다.

• 릴리스의 경우 병합된 모든 PR을 가져오고, 변경 로그를 빌드하고, 버전 범프를 처리하는 워크플로를 가질 수 있습니다.
• 새 프로젝트 설정은 워크플로에 적합합니다. 하나의 명령만 실행하여 폴더 구조를 만들고, 종속성을 설치하고, 구성을 설정합니다.
• 보고서를 만들어야 합니까? 다른 소스에서 통계를 가져와 원하는 대로 정확하게 서식을 지정하는 워크플로를 만듭니다. 차트 라이브러리로 시각화한 다음 slidev와 같은 라이브러리로 프레젠테이션을 만들 수도 있습니다.
• PR을 제출한 후 Slack 또는 Whatsapp과 같은 MCP 서버를 사용하여 팀에 메시지 초안을 작성하는 데 워크플로를 사용할 수도 있습니다.

워크플로를 사용하면 상상력에 한계가 없습니다. 진정한 잠재력은 항상 수행하는 성가신 반복적인 작업을 발견하는 데서 비롯됩니다.

“먼저 X를 하고, 그런 다음 Y를 하고, 그런 다음 Z를 한다”고 설명할 수 있다면 완벽한 워크플로 후보입니다.

자신을 괴롭히는 작은 것부터 시작하여 워크플로로 만들고 계속 구체화하십시오. 이런 식으로 하루 중 얼마나 많은 부분을 자동화할 수 있는지 놀라게 될 것입니다.