Skip to main content

워크플로

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

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

워크플로 생성 및 사용 방법​

워크플로는 Caret 규칙과 함께 존재합니다. 생성하는 것은 간단합니다.

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

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

  • ask_followup_question, read_file, search_files, new_task와 같은 Cline의 내장 도구 활용
  • gh 또는 docker와 같이 이미 설치된 명령줄 도구 사용
  • Slack 또는 Whatsapp과 같은 외부 MCP 도구 호출 참조
  • 특정 순서로 여러 작업을 함께 연결

실제 예시​

저는 PR 검토 워크플로를 만들었는데, 이미 많은 시간을 절약하고 있습니다.

`gh` 터미널 명령에 액세스할 수 있습니다. 이미 인증했습니다. 검토를 요청한 PR을 사용하도록 검토하십시오. 이미 `caret` 저장소에 있습니다.

<detailed_sequence_of_steps>

# GitHub PR 검토 프로세스 - 상세 단계 시퀀스

## 1. PR 정보 수집

1.  PR 제목, 설명 및 주석 가져오기:

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

2.  PR의 전체 차이점 가져오기:
    ```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 -
    @username님, 이 PR에 감사드립니다! 구현이 좋습니다.

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

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

2.  개선이 필요한 경우 변경 사항을 요청합니다.

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

    # 적절한 공백 서식이 있는 여러 줄 주석의 경우:
    cat << EOF | gh pr review <PR-번호> --request-changes --body-file -
    @username님, 이 PR에 감사드립니다!

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

    1. 문제 1
    2. 문제 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

# 전체 차이점 가져오기
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
```

## 차이점 및 파일 명령

```bash
# PR의 전체 차이점 가져오기
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>
안녕하세요 @alejandropta님, 이 작업에 참여해 주셔서 감사합니다!

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

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

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

새 PR을 검토할 때 PR 설명 확인, 차이점 검사, 주변 파일 확인, 최종적으로 의견 형성 등 컨텍스트를 수동으로 수집했습니다. 이제는 다음만 수행합니다.

  1. 채팅에 /pr-review.md 입력
  2. PR 번호 붙여넣기
  3. 나머지는 Cline에게 맡기기

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

  • PR 설명 및 주석 가져오기
  • 차이점 검사
  • 컨텍스트를 위해 주변 파일 확인
  • 잠재적인 문제 분석
  • 모든 것이 좋으면 승인해야 하는 이유에 대한 정당성과 함께 승인해도 괜찮은지 묻습니다.
  • "예"라고 말하면 Cline은 gh 명령으로 PR을 자동으로 승인합니다.

이것은 PR 검토 프로세스를 수동의 여러 단계 작업에서 정보에 입각한 결정을 내리는 데 필요한 모든 것을 제공하는 단일 명령으로 전환했습니다.

이것은 워크플로 파일의 한 예시일 뿐입니다. 영감을 얻기 위해 프롬프트 저장소에서 더 많은 것을 찾을 수 있습니다.

자신만의 워크플로 구축​

워크플로의 아름다움은 필요에 따라 완전히 사용자 지정할 수 있다는 것입니다. 서비스 배포 또는 PR 제출과 같은 반복적인 작업에 대한 모든 종류의 워크플로를 만들 수 있습니다.

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

워크플로를 사용하면 상상력이 한계입니다. 진정한 잠재력은 항상 수행하는 성가신 반복 작업을 발견하는 데서 나옵니다.

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

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