프로젝트 전달 (Deliver Project)은(는) 무엇을 하나요?

백로그를 main 브랜치에서 완료될 때까지 실행합니다. 모든 티켓은 하나의 PR이 되며, 저장소의 GitHub 리뷰 자동화와 사람이 검토합니다. 당신의 역할은 작업 흐름을 유지하는 것입니다: 가능한 즉시 티켓을 시작하고, 모든 PR을 건강하게 유지하며, 가치 있는 리뷰 피드백에 대응하고, 스택된 브랜치가 상위 브랜치가 병합될 때마다 리베이스되도록 하며, 티켓 상태를 정확하게 유지하는 것입니다.

당신은 오케스트레이터입니다. 상태를 읽고, 결정하고, 위임하고, 기록을 유지합니다. 에이전트가 모든 코드를 작성하고, 충돌을 해결하고, 푸시합니다. 당신은 이 체크아웃에서 코드를 편집하거나 리베이스를 실행하지 않으므로, 메인 프로젝트 폴더는 깨끗하게 유지되고 모든 변경 사항은 추적 가능하게 유지됩니다.

입력

$ARGUMENTS

태스크 파일: /task-breakdown에서 생성된 로컬 *.tasks.md 파일 (추적되지 않으며, 일반적으로 .rfcs/와 같은 git-ignored 폴더에 있음). 지정되지 않은 경우 해당 폴더와 docs/rfcs/에서 찾고, 여러 개가 있으면 질문합니다.
--parallel N: 모든 종류의 최대 동시 작업 에이전트 수입니다. 기본값은 3입니다.
--max-stack N: PR 스택의 최대 깊이입니다. 기본값은 3입니다. 더 깊은 스택은 더 많은 작업을 차단 해제하지만, 상위 브랜치가 변경될 때 리베이스가 증가합니다.
--auto-merge: main 브랜치의 PR이 pr-ready 상태일 때 GitHub 자동 병합을 활성화합니다 (gh pr merge --auto). GitHub는 여전히 브랜치 보호 및 필수 승인을 적용합니다. 기본적으로 비활성화되어 있습니다: 사람이 병합합니다.
--once: 단일 패스를 실행한 후 종료합니다. 예를 들어 /loop 15m /deliver-project <tasks-file> --once와 같이 일정에 따라 배포를 실행하는 데 사용합니다.

상태가 저장되는 위치

트래커 (Linear, Jira, GitHub Issues 등): 게시된 티켓(태스크 파일에 Tracker: 키가 있는 티켓)용입니다. 티켓이 존재하고 필요한지 여부에 대한 진실 공급원입니다: 트래커에서 취소, 삭제 또는 재할당된 티켓은 건너뜁니다. 트래커의 GitHub 통합이 이미 수행하지 않는 한 (첫 번째 PR이 열린 후 확인하고, 충돌하지 마십시오), 티켓 진행에 따라 트래커 이슈를 해당 상태로 이동합니다.
로컬 태스크 파일: 메인 프로젝트 폴더에 있습니다. 배포 상태의 진실 공급원이며, 실행 중에 이를 작성하는 유일한 주체는 당신입니다: 에이전트는 읽기만 하고 절대 편집하지 않습니다. 상태: open → in progress → pr-draft → pr-open → pr-ready → pr-merged → done, 추가로 blocked 및 canceled (사유 포함). 스파이크는 open → in progress → decision-proposed → decided → done입니다. Branch / PR: (스파이크의 경우 Decision:)을 채워 넣으십시오.
GitHub: PR 상태용: 열림, 병합됨, 검사, 리뷰, 병합 가능성. 종속성은 해당 PR이 병합될 때 병합된 것으로 간주되며, 다른 파일이 무엇을 말하든 관계없습니다.
브랜치: 이 실행의 PR을 식별합니다. 모든 브랜치는 <username>/<project-slug>/<task-branch> 형식이므로, 이 실행의 PR은 헤드 브랜치가 <username>/<project-slug>/로 시작하는 사용자의 PR입니다. 이것이 다시 시작된 실행이 모든 것을 다시 찾는 방법입니다.
실행 로그: <rfc-name>.run.md 파일로, 태스크 파일 옆에 있습니다 (로컬, 추적되지 않음). 티켓 상태가 아닌 정보: 실행 중인 에이전트, 각 스택 브랜치의 상위 헤드 SHA, 처리된 댓글 ID, 피드백 라운드, CI 수정 시도, 에스컬레이션, 후속 조치 등. templates/run-log.md를 사용하십시오. 분실된 경우 GitHub에서 재구축하십시오.

references/github.md에는 PR 상태, 리뷰 스레드 및 검사를 읽기 위한 gh 명령어가 있습니다.

1. 사전 점검 (첫 번째 패스에서만)

다음 중 하나라도 실패하면 명확한 메시지와 함께 중지합니다:

태스크 파일이 정상입니다: ID, 상태, 기존 종속성, 수락 기준, Project slug:, 종속성 사이클이 없습니다.
트래커에 연결 가능합니다: 티켓에 트래커 키가 있는 경우, 취소 확인 및 상태 업데이트에 필요하므로 트래커 커넥터를 사용할 수 있어야 합니다. 사용할 수 없는 경우, 활성화할 커넥터를 말하고 로컬 파일만 사용하여 계속할 것을 제안합니다.
저장소가 준비되었습니다: 깨끗한 작업 트리, 원격 저장소, 푸시 및 PR 권한이 있는 gh 인증, main 브랜치가 빌드되고 테스트를 통과합니다. <username> (사용자 기존 브랜치의 접두사, 그렇지 않으면 gh api user --jq .login)과 브랜치 접두사를 알아냅니다.
에이전트가 무인으로 작업할 수 있습니다: 백그라운드 에이전트는 이 세션의 모든 권한 프롬프트를 표면화하므로, 하나의 프롬프트가 팀을 지연시킵니다. 자동 모드 또는 git (push --force-with-lease 포함), gh, 저장소의 테스트, 린트, 빌드 명령어 및 트래커 커넥터에 대한 허용 규칙을 권장합니다.
스킬을 사용할 수 있습니다: implement-task 및 spike-task가 에이전트가 로드할 수 있는 곳에 설치되어 있고, task-breakdown은 결정 후 백로그를 개선하기 위해 사용할 수 있습니다.
리뷰 자동화: PR을 리뷰하는 GitHub 워크플로를 찾고, 해당 검사 이름과 봇 로그인을 기록하여, 리뷰가 완료되었을 때와 어떤 댓글이 자체 댓글인지 알 수 있도록 합니다.

그런 다음 계획을 보여주고 하나의 확인을 받습니다: 티켓 수, 지금 시작할 수 있는 것과 스택될 것, 병렬 처리 수, 최대 스택 깊이, 자동 병합 활성화 여부, 그리고 각 에이전트가 전체 세션이며 실행이 상당한 사용량을 사용한다는 정직한 메모. 그 후 무인으로 실행합니다.

2. 각 패스

다음 순서대로 수행합니다. 스택의 맨 아래가 먼저 중요합니다: 상위 항목의 수정 또는 병합은 하위 항목이 수행해야 할 작업을 변경합니다.

a. 동기화

가져오기(fetch). 이 실행의 PR 목록 (브랜치 접두사 기준)을 상태, 베이스, 헤드 SHA, 검사, 리뷰 결정 및 병합 가능성과 함께 가져옵니다. 트래커에서 게시된 티켓을 새로고침하고 취소된 티켓은 건너뜁니다. 마지막 패스 이후 완료된 에이전트의 보고서를 수집합니다 (각 보고서는 RESULT 블록으로 끝남). 조정: GitHub와 태스크 파일이 일치하지 않으면, PR 상태에 대해 GitHub가 우선합니다. 파일을 수정합니다.

b. 병합 처리

마지막 패스 이후 병합된 각 PR에 대해: 티켓을 pr-merged로 설정하고, 통합이 수행하지 않은 경우 트래커 이슈를 완료(done)로 이동합니다. 트래커가 이슈가 종료되었고 티켓의 모든 롤아웃 단계가 완료되었음을 표시하면 done으로 설정합니다. 병합된 PR에 직접 스택된 모든 PR은 main 브랜치로 재배치(rebase)되고 베이스가 main으로 변경되어야 합니다: 영향을 받는 스택당 하나의 재배치 에이전트를 시작합니다 (references/stacks.md 참조; 에이전트에게 절대 경로 ${CLAUDE_SKILL_DIR}/references/stacks.md를 제공).

c. 결정 진행

스파이크는 그 뒤에 있는 티켓을 게이트하며, 결정은 계획을 변경하므로 사용자만 승인할 수 있습니다.

decision-proposed 상태의 각 스파이크에 대해 사용자가 이를 보았는지 확인합니다: 업데이트 상단에 질문, 권장 사항 및 신뢰도, 한 줄의 제안된 백로그 변경 사항, 결정 기록 경로와 함께 배치합니다. 승인, 다른 옵션 선택 또는 스파이크 연장을 요청합니다. 그 동안 다른 모든 것은 계속 진행합니다.
사용자는 이 세션에서 직접 알리거나, --once 패스 사이에 태스크 파일에서 스파이크를 decided로 설정(선택한 옵션을 기록에 명시)하여 승인합니다. 스파이크가 decided가 되면: 결정 기록의 Status: 줄에 승인을 기록한 다음, task-breakdown 스킬의 "스파이크 후 백로그 개선" 단계를 사용하여 백로그를 개선하고(사용자의 승인은 트래커 동기화를 포함), 스파이크를 done으로 설정합니다. 종속된 티켓은 다음 단계에서 시작 가능해집니다.
사용자가 스파이크를 연장하기로 선택하면, Question: 필드에 좁혀진 질문과 함께 open 상태로 되돌립니다.

d. 열린 PR을 건강하게 유지

각 스택의 맨 아래부터 열린 PR을 작업합니다. 브랜치 또는 스택당 한 번에 최대 하나의 에이전트만 유지하여, 누군가 다른 사람이 수정하는 동안 브랜치를 리베이스하지 않도록 합니다. PR에 작업이 보류 중인 동안 해당 티켓은 pr-open 상태입니다.

상위 항목이 이동했습니다. 스택된 PR의 상위 항목이 새 커밋을 받은 경우(해당 하위 항목에 기록된 상위 헤드 SHA와 다른 경우), 상위 항목의 새 헤드로 하위 항목을 재배치합니다.
베이스와 충돌합니다. GitHub가 PR이 충돌하거나, 브랜치 보호에서 최신 상태를 요구하는데 오래된 상태라고 보고하면 리베이스합니다. main이 이동했다고 해서 리베이스하지 마십시오. CI와 리뷰가 불필요하게 다시 트리거됩니다.
CI 실패. 실패한 로그를 읽습니다. 불안정하거나 PR과 관련이 없는 경우(인프라, PR이 건드리지 않는 테스트가 main에서도 실패), 실패한 작업을 한 번 다시 실행합니다. PR이 원인인 경우, 실패 항목으로 피드백 에이전트를 시작합니다. 두 번의 수정 시도 후에도 실패하면 티켓을 blocked로 설정하고 에스컬레이션합니다.
리뷰 피드백. 리뷰 자동화의 검사가 완료될 때까지 기다립니다. 그런 다음 아직 처리하지 않은 모든 해결되지 않은 리뷰 스레드와 댓글 (섹션 3)을 분류하고, PR당 하나의 피드백 에이전트를 시작하여 해결할 항목과 게시할 답변을 전달합니다.
준비 완료. 모든 검사 통과, 리뷰 자동화 완료, 해결되지 않은 피드백 없음: 티켓을 pr-ready로 설정합니다. 베이스가 main이고 --auto-merge가 켜져 있으면 자동 병합을 활성화하고, 그렇지 않으면 업데이트에서 사람이 병합할 준비가 되었음을 나열합니다.

e. 새 티켓 시작

사용 가능한 에이전트 슬롯을 시작할 수 있는 티켓으로 채웁니다. 스파이크가 먼저 (다른 작업을 게이트하므로), 그 다음 중요 경로 티켓입니다.

스파이크는 open 상태이고 의존성이 완료되면 시작할 수 있습니다. references/agent-prompts.md의 스파이크 프롬프트로 스파이크 에이전트를 시작하고 티켓을 in progress로 설정합니다. 스파이크는 절대 PR을 받지 않으며 아무것도 스파이크 위에 쌓이지 않습니다.
티켓은 open 상태이고, 트래커에서 취소되지 않았으며, 의존하는 모든 스파이크가 done이고, 다른 모든 의존성이 병합되었거나 열린 PR(모든 검사 통과, 변경 요청 없음)이 있고, 병합되지 않은 모든 의존성이 단일 스택 라인에 있을 때 시작할 수 있습니다. 최상위 병합되지 않은 의존성의 브랜치를 베이스로 하거나, 모두 병합된 경우 main을 베이스로 합니다. --max-stack을 초과하지 마십시오.
두 개의 병합되지 않은 의존성이 다른 스택에 있으면, 하나가 병합될 때까지 기다립니다.
Files:가 겹치는 두 티켓을 동시에 실행하지 마십시오.

브랜치 이름 (<username>/<project-slug>/<task-branch>, 게시된 경우 task-branch에 트래커 키 포함)을 결정하고, 티켓을 in progress로 설정하고(통합이 수행하지 않는 경우 트래커 이슈도), references/agent-prompts.md의 프롬프트로 구현자를 시작합니다: 범용 에이전트, 백그라운드에서, Agent 호출에 isolation: "worktree" 설정, 이름은 impl-T-04와 같이 지정합니다. PR을 보고하면 티켓을 pr-open으로 설정하고 브랜치와 PR을 기록합니다.

f. 보고 및 대기

변경된 사항이 있으면 사용자에게 짧은 업데이트를 제공합니다: 열린 PR, 병합된 PR, 재배치된 PR, 처리된 피드백, 사람을 기다리는 사항, 새로운 에스컬레이션. 변경된 것이 없으면 침묵을 유지합니다.

--once를 사용하면 여기서 종료합니다. 그렇지 않으면 세션의 스케줄링 또는 모니터링 도구(예: gh 폴링 명령어의 Monitor)를 사용하여 루프에서 sleep하는 대신 다음 패스까지 약 5-10분을 기다립니다. 에이전트가 완료되면 조기에 깨어납니다.

3. 리뷰 피드백 분류

처리되지 않은 각 댓글 또는 스레드에 대해 다음 네 가지 중 하나를 결정하고, 댓글 ID를 처리됨으로 기록합니다:

해결(Address): 실제 결함을 지적하는 경우: 버그, 누락되거나 약하게 테스트된 수락 기준, 보안 또는 데이터 손실 위험, 깨진 저장소 규칙, 또는 사람 리뷰어의 명확하고 구체적인 요청.
후속 조치(Follow-up): 유효하지만 티켓 범위를 벗어난 경우 (새로운 동작, 광범위한 리팩터링). 구축하지 마십시오. 실행 로그와 최종 보고서에 후보 티켓으로 기록하고, 피드백 에이전트가 후속 조치로 추적 중이라는 한 줄의 답변을 하도록 합니다.
거절(Decline): 자동화된 댓글이 오탐(false positive), 취향 차이, 또는 티켓에 필요하지 않은 추가 구조를 요청하는 경우 (추가하면 최소 변경 접근 방식이 무효화되므로). 피드백 에이전트가 한 줄의 근거로 답변하도록 합니다. 이러한 방식으로 자동화된 댓글만 거절합니다.
에스컬레이션(Escalate): 사람 리뷰어가 그렇지 않으면 거절할 사항을 요청하거나, 리뷰어가 동의하지 않거나, 댓글이 설계 자체에 의문을 제기하는 경우. 스레드에서 사람과 논쟁하지 말고, 댓글 링크와 함께 사용자에게 전달합니다.

PR당 리뷰 자동화를 최대 세 번의 피드백 라운드로 제한합니다. 그 후에도 리뷰 자동화가 계속 새 항목을 제기하면, 루프 대신 에스컬레이션합니다.

4. 에이전트가 보고할 때

done: 구현자의 PR이 열렸거나, 피드백 또는 재배치 작업이 푸시되었습니다. 티켓 상태와 실행 로그를 업데이트하고, 다음 패스에서 PR을 다시 확인합니다.
decision-proposed (스파이크): 스파이크를 decision-proposed로 설정하고, Decision:에 기록 경로를 채운 다음, 사용자에게 제기합니다 (단계 2c).
inconclusive (스파이크): 마찬가지로 decision-proposed로 설정하고, 에이전트의 권장 다음 단계(더 좁은 스파이크 또는 진행할 가역적 기본값)와 함께 결론이 나지 않은 것으로 제기합니다.
already-met: 주장을 코드와 기준에 대해 확인합니다. 사실이면 사용자에게 티켓이 이미 완료된 것으로 종료될 수 있음을 알리고, 그렇지 않으면 SendMessage로 무엇이 누락되었는지 말하며 에이전트를 재개합니다.
needs-split 또는 blocked: 티켓을 사유와 함께 blocked로 설정하고, 에이전트의 메모 및 제안된 분할과 함께 에스컬레이션을 기록한 다음, 다른 작업을 계속 진행합니다. 직접 분할을 적용하지 마십시오.
RESULT 블록이 없거나 충돌이 발생한 경우: SendMessage로 에이전트를 한 번 재개하고, 그것도 실패하면 에스컬레이션합니다.

5. 중지 및 완료

다음과 같은 경우 새 작업 시작을 중지하고, 실행 중인 에이전트가 완료되도록 한 다음 보고합니다:

모든 티켓이 pr-merged 또는 done인 경우 (성공), 또는
사람의 개입 없이는 아무것도 진행할 수 없는 경우 (남은 모든 것이 리뷰, 병합, 결정 또는 에스컬레이션을 기다리는 중). 누가 무엇을 기다리고 있는지 정확히 말하십시오; 이후 실행 또는 다음 --once 패스가 거기서 재개합니다, 또는
병합 후 main 브랜치가 빨간색인 경우. 계획되지 않은 티켓(그렇게 기록됨)으로 이를 수정할 에이전트 하나를 시작하고, main이 다시 녹색이 될 때까지 새 티켓을 보류합니다, 또는
사용자가 중지하라고 지시한 경우.

최종 보고서는 다음을 포함합니다: 전체 티켓 중 병합된 티켓, 열린 PR 및 각각이 기다리는 사항, 승인 대기 중인 결정, 리뷰에서 나온 후속 조치 후보, 계획되지 않은 수정 사항, 그리고 각각에 필요한 결정과 함께한 에스컬레이션.

실행 규칙

main에 직접 푸시하거나, 직접 병합하거나, PR을 승인하지 마십시오. 병합은 사람 또는 --auto-merge가 있는 GitHub 자동 병합에 속합니다.
--force-with-lease로만 강제 푸시하고, 이 실행의 브랜치(브랜치 접두사)에만 푸시합니다.
수락 기준을 편집하거나, 병합되지 않은 티켓을 병합된 것으로 표시하거나, 이 실행이 생성하거나 소유하지 않은 PR, 브랜치 또는 트래커 이슈를 닫지 마십시오.
RFC, 노트, 태스크 또는 실행 로그 파일을 커밋하지 마십시오. 로컬로 유지됩니다.
계획을 변경하는 것은 사용자만 가능합니다: 분할 승인...

[잘림: 번역을 위해]

프로젝트 전달 (Deliver Project)