> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dureai.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# 리드 에이전트로 팀 운영

> 목표를 추적 가능한 이슈로 나누고, 이슈마다 전용 worktree에서 워커 Run을 시작하고, 진행을 지켜본 뒤 보고하는 리드 에이전트 하나를 시작합니다.

리드 Run은 프롬프트가 "목표 + 번들된 리드 브리프"인 평범한 `dure run`입니다. 리드는 직접 코드를 쓰지 않습니다. 작업 항목마다 GitHub 이슈를 하나 열고, 이슈마다 전용 worktree에서 워커 Run을 하나 시작하고, 워커를 기다리고, 검사를 통과한 pull request를 병합한 뒤 보고서 하나로 마칩니다. 워커 역시 평범한 Run이며, 리드가 건네는 브리프가 워커를 워커로 만듭니다. 새로 저장되는 것은 없습니다. 계획은 GitHub에, Run은 Dure에 있습니다.

## 시작하기 전에

* 등록된 프로젝트(`dure projects list`)가 GitHub 원격을 가진 Git 체크아웃이어야 하고, 그 저장소에 이슈와 pull request를 열 수 있는 권한으로 `gh`에 로그인되어 있어야 합니다.
* 실행 호스트에 로그인된 제공자가 필요합니다. 예시는 Claude Code를 사용합니다.
* Claude 워커를 쓴다면 그 계정에서 프로젝트 폴더를 한 번 신뢰해 두세요. Claude Code는 계정이 폴더를 처음 열 때 폴더 신뢰 프롬프트를 보여주며, 거기서 멈춘 워커는 브리프를 아직 읽지 않은 상태입니다. 프로젝트 루트를 신뢰하면 Dure가 `<project>/.worktrees/` 아래에 만드는 worktree도 함께 신뢰됩니다. 같은 계정으로 프로젝트 루트에서 Claude 세션을 하나 열어 프롬프트를 수락한 뒤 리드를 시작하세요.
* 동시에 실행할 워커 수를 정하세요. 기본값은 3이며, 다른 상한은 목표에 적습니다.

## 리드 시작

```sh theme={"system"}
dure run --project PROJECT_ID --provider claude --name lead-onboarding \
  --permission-override bypass_approvals \
  --lead "열려 있는 온보딩 이슈 세 건(#118, #119, #121)을 닫아줘. 상한: 워커 2개."
```

`--lead`는 목표 앞에 리드 브리프를 붙입니다. 브리프는 에이전트를 CLI에 번들된 전체 절차인 `dure skills get dure-lead`로 안내합니다. 나머지는 일반 Run과 같습니다. `--project`나 `--path`가 프로젝트를, `--space`가 pane 위치를 정하고, `--json`은 영수증을 돌려줍니다. 리드는 읽기와 `gh`, `dure` 실행만 하므로 프로젝트 루트에 머물러도 되고, 워커가 worktree를 받습니다. `bypass_approvals`는 이런 명령을 승인 대기 없이 실행하게 합니다. pane에서 명령마다 승인하려면 생략하세요.

아무것도 시작하지 않고 절차만 읽으려면:

```sh theme={"system"}
dure skills get dure-lead
```

## 그다음 일어나는 일

이슈 세 건짜리 작은 예시입니다.

| 단계 | 리드가 하는 일 | 사용자가 보는 것 |
| - | - | - |
| 분할 | 프로젝트 ID와 저장소를 확인하고, 항목마다 이슈를 열거나 기존 이슈를 재사용하고, 추적 이슈에 계획 표를 남기고, 맡긴 이슈마다 `lead:claimed` 레이블을 붙입니다 | 이슈 세 건과 계획 댓글 하나 |
| 디스패치 | 항목마다 상한까지 `dure run --project … --name work-118 --worktree work-118 --permission-override bypass_approvals "<brief>"` | `dure ls`에 보이는 워커 pane 또는 화면 없는 세션, `agent/work-118`, `agent/work-119`, … 브랜치 |
| 추적 | 워커마다 `dure wait`, 상태는 `dure inspect`, 결과는 `gh pr list`와 `gh pr checks` | `Closes #118`이 적힌 pull request와 CI 실행 |
| 복구 | 알려진 불안정 CI 작업은 한 번 재실행하고, 실제 실패에는 워커에게 메시지를 한 번 보내고, 중단된 워커는 한 번 재개하고, 결정이 필요한 이슈에는 `needs:founder` 레이블을 붙입니다 | 각 조치를 설명하는 이슈 댓글 |
| 병합과 보고 | 워커가 병합하지 못한 초록색 pull request를 병합한 뒤 보고서를 올립니다 | 이슈마다 한 줄씩 적힌 보고 댓글 |

워커 브리프는 각 워커에게 이슈를 읽고, 자기 worktree에만 머물고, 동작이 있는 수준에서 테스트하고, 기본 브랜치를 대상으로 `Closes #n`이 적힌 pull request를 열고, CI를 기다리고, 알려진 불안정 작업은 한 번만 재실행하고, 저장소 규칙이 허용하면 병합하고, pull request를 적은 댓글로 마치라고 지시합니다. 제품 결정이 필요한 워커는 추측하는 대신 이슈에 `needs:founder` 레이블을 붙이고 멈춥니다.

## 리뷰 후 병합

기본적으로 각 워커는 CI가 초록색이 되면 자기 pull request를 직접 병합합니다. 모든 pull request를 병합 전에 검토하려면 `--merge-policy review`로 리드를 시작하세요.

```sh theme={"system"}
dure run --project PROJECT_ID --provider claude --name lead-onboarding \
  --permission-override bypass_approvals --merge-policy review \
  --lead "열려 있는 온보딩 이슈 세 건(#118, #119, #121)을 닫아줘. 상한: 워커 2개."
```

이 정책은 리드 브리프에 들어가므로 첫 디스패치부터 모든 워커 브리프에 병합하지 말라고 적힙니다. 워커는 pull request를 열고, CI가 초록색이 될 때까지 기다리고, 리뷰할 준비가 됐다는 댓글을 남긴 뒤 멈춥니다. 병합을 허락하려면 GitHub에서 승인하세요. 내 계정이 연 pull request라서 GitHub가 승인을 막는다면 `lead:approved` 레이블을 붙이면 됩니다. 변경을 요청하거나 리뷰 댓글을 남기면 리드가 그 내용을 워커에게 전달하고, 워커는 수정을 푸시한 뒤 다시 기다립니다. 리뷰를 기다리는 pull request만 남으면 리드는 그 항목을 `awaiting review`로 적은 보고서를 올리고 기다립니다. 리뷰를 마친 뒤 `dure send lead-onboarding "reviewed"` 같은 메시지를 보내면 승인된 pull request를 병합합니다. 리드는 pull request를 스스로 승인하거나 레이블을 붙이지 않습니다. 목표에 병합 전 리뷰를 요구하는 내용이 있으면 플래그 없이도 같은 정책이 적용됩니다.

## 직접 지켜보기

```sh theme={"system"}
dure ls                         # ACTIVITY: working, waiting, input_required
dure read work-118 -n 60        # 클라이언트가 등록한 뒤에는 이름으로 워커 화면 읽기
dure runs list --json           # 화면 없는 워커를 포함한 영구 Run 기록
```

시작 직후 ACTIVITY가 `input_required`인 워커는 첫 실행 프롬프트에서 기다리는 중입니다. Claude의 폴더 신뢰 프롬프트이거나, 워커의 Codex 계정 로그인이 더 이상 유효하지 않을 때 나타나는 Codex 로그인 화면입니다. 그 `dure run` 영수증은 `startup_gate`(`workspace_trust` 또는 `login`)와 함께 `prompt_delivery_uncertain`으로 끝납니다. 브리프는 에이전트 안에 대기 중이므로 다시 보내면 안 됩니다. 위에서 설명한 대로 폴더를 신뢰하거나, 그 워커의 pane에서 프롬프트에 답하거나 로그인하면 워커가 스스로 이어갑니다. 리드는 워커가 시작했다고 가정하지 않고 이 상태를 보고합니다.

## 보고서 읽기

```md theme={"system"}
## Lead report: 열려 있는 온보딩 이슈 세 건 닫기

Project `…` on `acme/app` · 3 items · 3 workers started · 2 PRs merged · 1 open · 1 escalated

| Issue | Item | Worker | PR | Result |
| --- | --- | --- | --- | --- |
| #118 | 초대 폼 검증 | work-118 | #130 merged | done |
| #119 | 확인 메일 재발송 | work-119 | #131 merged | done |
| #121 | 온보딩 탭 이름 변경 | work-121 | #132 open | needs:founder: 어떤 이름으로? |
```

리드는 보고서를 추적 이슈에 올리고 자기 세션에도 출력합니다. 끝내지 못한 항목에는 필요한 결정이 적혀 있습니다. 멈춘 워커는 worktree와 대화를 그대로 두므로, pane에서나 `dure runs resume`으로 어느 워커든 이어갈 수 있습니다.

## 제한

* 리드 하나, 프로젝트 하나, 백엔드 하나입니다. 리드는 자신이 실행 중인 백엔드에서 워커를 시작합니다.
* 워커 하나는 제공자 세션 하나 전체입니다. 상한은 정확성이 아니라 머신과 계정 한도를 보호합니다.
* 리드는 신뢰나 권한 프롬프트에 답하지 않고, 제품 선택지 사이에서 고르지 않으며, 목표가 명시하고 저장소가 허용할 때만 관리자 권한으로 병합합니다.
* Dure는 아직 어떤 워커가 어떤 이슈를 맡았는지 기록하지 않습니다. `lead:claimed` 레이블과 pull request가 공유 기록입니다.

리드가 사용하는 Run 옵션은 [CLI 실행과 예약](https://docs.dureai.dev/ko/cli-and-automation.md)에서, 작업을 직접 나누는 방법은 [병렬 작업](https://docs.dureai.dev/ko/first-parallel-workflow.md)에서 확인하세요.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.