GravionLabs/deliver

열려 있는 PBI 및 Bug를 하나씩 순서대로 전달합니다(작업 항목 = pbi 또는 bug 레이블이 붙은 열린 이슈; Bug는 동일한 루프를 실행, 브랜치 유형 fix, Closes #<nr> 사용). 하위 에이전트가 구현하고, 하위 에이전트가 검토하며, 이 세션이 PR을 열고, CI가 완료될 때까지 기다린 후 병합합니다. 모든 하네스(Claude Code, OpenCode, Copilot CLI)에서 동일한 단계를 따릅니다. 상태는 GitHub(이슈, 하위 이슈, 브랜치, PR)에만 저장되므로 언제든지 실행을 중단하고 /deliver <nr> 명령으로 중단된 지점부터 계속 진행할 수 있습니다. 핵심 게이트는 release/next의 규칙 세트입니다. 빨간색 또는 누락된 필수 검사는 이 세션이 무엇을 하든 병합을 차단합니다.

입력

help (또는 --help, -h): references/help.md 파일을 변경하지 않고 그대로 출력합니다. 다른 작업은 수행하지 않습니다.

/deliver status --milestone <name>: 상태 블록(## Status block)을 출력하고 중지합니다. 아무것도 전달되지 않습니다.

/deliver <nr> [<nr> …] [--milestone <name>] [--unattended] [--inline] [--max <n>]: 각 숫자는 PBI, Bug, Feature 또는 Epic입니다. --milestone <name>(릴리스, M<n> 또는 레거시 제목)은 해당 마일스톤의 열린 작업 항목을 추가합니다(마일스톤의 일괄 읽기(pwsh <skill-dir>/../github-milestone/scripts/Get-Milestones.ps1 -Mode issues -Name <name> -State open: REST, 모든 페이지, PR 제외); github-milestone 조회는 M4를 제목 M4로 확인하거나 close 후에는 M4 (0.2.0)으로 확인합니다. 반환된 목록을 레이블(pbi, bug)로 필터링합니다. 또한 해당 마일스톤의 Feature 및 Epic 아래에 있는 작업 항목도 포함됩니다). 해당 읽기의 milestone.title은 gh issue create --milestone의 제목입니다. <key>는 그 M<n> 또는 하위 번호 M<n>.<m>(레거시: 제목)이며 상태 파일과 힌트의 이름을 지정합니다. 누락된 경우: 한 번 질문합니다. --max <n>은 n개의 전달, 차단 또는 일시 중지된 PBI 이후에 중지되고 보고서를 출력합니다(scripts/Invoke-DeliverLoop.ps1은 새 세션당 --max 1을 사용, references/loop.md).

• 대화형(기본값): 일시 중지 규칙이 채팅에서 사용자에게 질문합니다. 차단된 PBI는 재시도, 건너뛰기 또는 지시 중에서 선택하도록 요청합니다.
• 제어 세션: deliver.loopThreshold(기본값 3)보다 많은 PBI가 있는 대화형 세션입니다(예: 모든 --milestone): 여기서 전달하지 말고 Invoke-DeliverLoop.ps1을 시작하고 결정을 위한 얇은 세션, interactive PBI 및 9단계로 유지합니다(references/control.md). --inline은 이 세션에서 모두 전달합니다(1단계에서 9단계까지). --no-preflight는 시작 3단계를 건너뜁니다.
• --unattended(claude -p, opencode run, copilot -p): 절대 묻지 않습니다. 일시 중지는 이슈에 댓글을 달고 needs-decision 레이블을 추가한 후, 해당 PBI에 의존하지 않는 다음 PBI로 계속 진행합니다.

시작

1. gh auth status가 작동하고 리포지토리에 release/next가 있습니다.
2. gh api repos/{owner}/{repo}/rules/branches/release/next --jq '.[].type': 출력에 required_status_checks가 없음 → 여기서 빨간색 CI가 병합 가능하다고 경고합니다(github-release의 규칙 세트). 그런 다음 계속 진행합니다.
3. 사전 점검(--no-preflight로 건너뜀): pwsh <skill-dir>/scripts/Test-DeliverPreflight.ps1 -Harness <claude|opencode|copilot> [-Unattended] -Text는 각 검사별로 한 줄씩 출력합니다(ok / fixed / action needed): 스택 스킬, 허용 목록(git, gh, pwsh <skill-dir>/scripts/*, AGENTS.md의 확인 명령; 하네스별 항목: references/permissions.md, 그렇지 않으면 무인 실행이 프롬프트에서 중단됨), 오래된 작업 트리; references/preflight.md의 반응. 따옴표 없는 $(…)로 명령을 작성합니다. 권한 검사는 이를 통해 볼 수 없습니다.
4. 진행 이벤트: AGENT_EVENTS_RUN 없이 pwsh <skill-dir>/scripts/Report-Progress.ps1 -Type run.started -Source session을 실행하고 출력된 실행 ID를 유지합니다. 이후 모든 호출(step.finished, attention, issue.finished, run.finished)에 -Run <id>를 추가합니다. Bash 호출은 셸 상태를 공유하지 않으며 AGENT_EVENTS_RUN을 접두사로 사용하면 허용 목록과 일치하지 않습니다. 모든 진행 라인, 주의 이유 및 종료는 Report-Progress.ps1을 통해 전달됩니다. 이 스크립트는 세션이 실행 중인 모든 터미널에 이를 표시합니다(references/terminal-backends.md).

단계

채팅에 각 단계별로 한 줄씩 출력합니다: #<nr> <step>: <result> (#12 review: 1 blocking → fix 1/2). 각 줄을 보고합니다: pwsh <skill-dir>/scripts/Report-Progress.ps1 -Type step.finished -Issue <nr> -Step <step> -Result "<result>" [-Pr <url>]. 또한 -Type attention(-Kind pr_opened with -Pr <url> after step 6, review_fix when a review or CI round starts a fix round, ci_red when step 7 is red; -Reason): 루프의 알림은 이러한 이벤트에서만 옵니다. 일시 중지, 차단된 PBI 또는 사용자가 필요한 지점: 대신 -Type attention (-Kind paused, blocked 또는 needs_you, -Reason). 각 PBI 후 -Type issue.finished -Issue <nr> -Outcome <outcome>.

채팅에서 언급하는 모든 PR 및 이슈는 전체 URL(https://github.com/<owner>/<repo>/pull/<n>, .../issues/<n>)로 작성되며, 단순한 #<n>이 아닙니다. 단순한 숫자는 터미널에서 링크가 아닙니다. 이는 진행 라인, 사용자에 대한 질문 및 보고서, 특히 사용자가 병합해야 하는 릴리스 PR(9단계)에 적용됩니다. gh에서 URL 가져오기(html_url), 절대 기억에서 빌드하지 마십시오.

1. 선택. 모든 번호와 그 하위 이슈(github-issue references/sub-issues.md, 재귀적으로 PBI 및 Bug까지)에 대해 gh api repos/{owner}/{repo}/issues/<nr> --jq '{number,title,state,labels:[.labels[].name],body}'를 실행합니다. 모든 번호와 마일스톤의 열린 작업 항목(pbi 또는 bug)을 수집하고, 중복을 제거하며, needs-decision이 없는 항목을 유지합니다(본문에 ADR 기준이 있는 항목은 #<nr> select: decision, write the ADR with adr로 보고됨). 모든 PBI에서 차단 링크별로 정렬하고, 동점인 경우 인수 순서를 유지합니다. --milestone을 사용하는 경우, 마일스톤의 Feature 또는 Epic을 통해 도달했지만 마일스톤이 없거나 다른 마일스톤이 있는 PBI 또는 Bug는 전달되지 않습니다(#<nr> select: outside M<n>, skipped, 힌트: 마일스톤 설정, github-issue references/milestones.md); --milestone 없이 /deliver <feature>를 사용하면 모든 PBI가 전달됩니다. 차단자가 아직 열려 있고 집합에 없는 PBI는 대기하고 보고됩니다(마일스톤 외부의 차단자는 절대 전달되지 않음). needs-refinement가 있는 PBI 또는 Bug, 또는 재현 단계나 승인 기준이 없는 Bug는 건너뜁니다(#<nr> select: needs refinement, skipped, 힌트 planner refine <nr>); 이러한 항목에 대한 /deliver <nr>은 거부됩니다. 무인 모드에서 interactive PBI는 건너뜁니다(#<nr> select: interactive, skipped, 힌트 세션에서 /deliver <nr>); 대화형 모드는 Feature, Epic 또는 마일스톤을 통해서도 전달합니다. release-test(마일스톤의 RC 테스트)가 있는 열린 PBI는 작업으로 선택되지 않습니다(1~8단계 및 제어 세션에서 제외, interactive 또는 명시적 <nr>로도 제외): #<nr> select: release test, left for step 9 (앞에 열린 항목이 있는 경우: release test, waits for <n> open items; 대기 중, 사용자 필요 아님; references/loop.md). 9단계와 사람을 위해 열려 있습니다(RC 테스트는 RC에서 실행됨). 다른 세션이 요청한 PBI 건너뛰기(#<nr> select: claimed, skipped), 오래된 요청 인수(references/claim.md); PBI 자체에 대한 /deliver <nr>은 요청에 관계없이 계속됩니다. 다음 PBI를 알리고 요청합니다: gh issue edit <nr> --add-assignee @me; 선택 라인은 계층과 모델을 지정합니다(#<nr> select: next (tier standard → sonnet/medium); Tier: 줄이 없으면 tier from size M 또는 default; references/roles.md).
   • PBI가 없는 Feature 또는 Epic 자식: 이 세션에서 planner(대화형)와 grill-me를 로드하고, 이슈를 만든 다음 다시 선택합니다. 무인 모드: 댓글을 달고 needs-decision 레이블을 추가합니다.
2. 재개. 브랜치 <type>/<nr>-<slug> (github-issue). git ls-remote --heads origin <branch> 및 gh api "repos/{owner}/{repo}/pulls?head=<owner>:<branch>&state=open" --jq '.[].number' (헤드에는 소유자 접두사 필요): 기존 브랜치는 계속 진행되고, 기존 PR은 7단계로 건너뜁니다.
3. 구현. 새 컨텍스트의 하위 에이전트: "implementation 로드, 역할 implement. origin/release/next의 <branch>에 있는 자신의 작업 트리에서 PBI #(Bug: 먼저 diagnose 로드, 그 다음 implementation)을 구현합니다(기존 브랜치: 전환 후 리베이스). 승인 기준: <이슈에서>. 커밋, 푸시, 최대 10줄로 보고: 완료 또는 차단, 커밋, 실행된 테스트 및 notes[](줄당 하나); 일치하는 specMap 항목이 사양 변경 없이 no spec change needed: <spec> — <reason> 노트를 제공합니다(implementation references/specs.md)."
4. 검토. 새 컨텍스트의 하위 에이전트: "code-review 로드, 역할 review. git diff origin/release/next...origin/<branch>를 다음 승인 기준과 비교하여 검토합니다: . governance 사용: Get-GovernanceMatches.ps1 -Head origin/<branch> 실행; 이슈 레이블 및 구현자 notes[] . 읽기 전용: 기존 체크아웃에서 stash, checkout, switch 또는 commit 없음; 파일이 필요하면 자체 임시 작업 트리를 사용하십시오. JSON만 반환: code-review의 review.schema.json당 결과(blocking[] with file, line, title, why; notes[], 최대 5개) 및 unmet[] (충족되지 않은 기준)." 차단 결함과 충족되지 않은 기준만 계산합니다. 이 세션(하위 에이전트 아님)은 각 라운드 후에 파일 <git-common-dir>/.agents/state/review-<nr>.json을 작성합니다(git rev-parse --git-common-dir, 모든 작업 트리에서 동일한 파일, 절대 커밋되지 않음), 이전 라운드를 덮어씁니다: { pbi, branch, sha, round, unmet, review }, sha = git rev-parse origin/<branch>, round = 1부터 시작하는 검토 라운드, review = 하위 에이전트의 결과; 스키마 schema/deliver-review.schema.json. 또한 pwsh <skill-dir>/../code-review/scripts/ConvertTo-Findings.ps1 -Review <result with unmet> -Sha <sha> -Worktree <pbi-worktree>는 poimen을 위해 <pbi-worktree>/.agents/state/findings.json을 작성합니다(절대 커밋되지 않음, 로컬에서 제외됨; references/findings.md).
5. 수정. 무언가 계산됨: 새 컨텍스트의 하위 에이전트가 implementation을 역할 fix로 로드하고, 자신의 작업 트리를 <branch>로 전환하고(git fetch origin <branch>, git switch -C <branch> origin/<branch>), 정확히 해당 결함(blocking[] 및 unmet[])을 가져와 커밋하고 푸시합니다. 그런 다음 4단계로 다시 이동합니다. PBI당 최대 2번의 수정 라운드(검토 및 CI 공유); 세 번째는 일시 중지입니다.
6. PR. github-pull-request ((#<nr>)가 추가된 수준 접두사가 없는 이슈 제목)와 함께 issue_number, branch: <branch> (작업은 다른 작업 트리에서 푸시되었으며, 이 체크아웃은 그대로 유지됨), review_notes (4단계의 notes[]), governance spec_notes (구현자 notes[] 줄 중 no spec change needed:로 시작하는 줄) 및 하위 에이전트의 테스트 결과.
7. CI. 파이프나 출력 필터(예: tail, head 또는 grep) 없이 gh pr checks <pr> --watch --required --interval 60을 직접 실행합니다(각 폴링은 GraphQL 쿼리임; 기본 10초는 예산을 소진함). 따라서 진행 상황이 세션에 도달합니다.
   • 이 변경으로 인해 빨간색(차이의 파일에서 테스트, 린트 또는 빌드 오류): 수정 라운드(5단계), 그런 다음 4단계와 7단계를 다시 수행합니다.
   • 다른 이유로 빨간색(불안정, release/next에서도 빨간색): PR에 댓글을 달고 PBI가 차단됩니다.
8. 병합. 묻지 않고 두 모드 모두에서: 마지막 검토에 차단 결함이나 충족되지 않은 기준이 없고 필수 검사가 통과되었습니다. gh pr merge <pr> --squash --delete-branch, 그런 다음 gh issue close <nr> --comment "Delivered in #<pr>" (Closes는 release/next에서 실행되지 않음); PBI의 열린 레거시 [Task] 하위 이슈도 함께 닫힙니다(github-issue references/sub-issues.md, "Legacy Task issues"); 그런 다음 gh issue edit <nr> --remove-assignee @me. 이 스킬의 스크립트 scripts/Remove-PbiWorktrees.ps1(스킬 디렉토리 ~/.claude/skills/deliver/에 전역, .claude/skills/deliver/에 프로젝트 설치)을 사용하여 하위 에이전트의 작업 트리와 브랜치를 정리합니다. 리포지토리에서 실행: pwsh <skill-dir>/scripts/Remove-PbiWorktrees.ps1 -Pr <pr> -Issue <nr>; #<nr> cleanup: <n> removed를 출력하고 보고서를 위해 left 항목(경로 또는 브랜치, 이유, 명령)을 유지합니다. 다음 PBI: 1단계.
9. 릴리스. --milestone이 있는 경우에만, 보고서 전에(--max 이후에도), 선택할 PBI가 남아 있지 않을 때. 마일스톤을 한 번 읽습니다. Get-Milestones.ps1 -Mode issues -Name <name> -State all (열림 및 닫힘); 열린 작업 확인, 마커, 라운드 수 및 닫힌 이슈의 기준은 해당 목록에서 가져옵니다. release-test 이슈를 제외하고 pbi 또는 bug 레이블이 있는 열린 이슈가 없어야 합니다(차단, 일시 중지, 대기 또는 건너뛰기 없음); RC 테스트는 절대 차단하지 않습니다.
   • 마일스톤의 닫힌 PBI 또는 Bug 중 needs-decision 레이블이 있는 것은 3라운드 릴리스 검토의 일시 중지 마커입니다: 검토를 건너뛰고 release: paused in round 3, waits for a decision을 출력합니다.
   • 릴리스 검토 (references/release-review.md): 새 컨텍스트의 하위 에이전트가 code-review, 역할 review를 로드하고, git diff origin/main...origin/release/next에서 마일스톤의 닫힌 PBI 및 Bug의 승인 기준과 함께, PBI 전반의 일관성에 초점을 맞추고 review.schema.json당 JSON을 반환합니다(읽기 전용: 기존 체크아웃에서 stash, checkout, switch 또는 commit 없음; 파일이 필요하면 자체 임시 작업 트리 사용); 이 세션은 <git-common-dir>/.agents/state/release-review-<key>.json을 작성합니다.
   • 차단 결함: 마일스톤당 하나의 [Bug] fix: … 이슈(대화형: 표시하고 먼저 질문), 릴리스 PR 없음; release: <n> blocking → #a, #b 출력. 마일스톤당 최대 2번의 릴리스 검토 라운드; 차단 결함이 있는 세 번째는 일시 중지이며, 해당 마커와 두 가지 방법을 설명하는 댓글로 기록됩니다(references/release-review.md, "Pause marker").
   • 깨끗함(차단 없음): RC를 생성하고, release-test 이슈에 게시하고 이전 항목을 닫습니다(references/release-review.md, "RC test"); release.test.gate: true는 이슈가 닫힐 때까지 needs you: RC test <issue URL>에서 중지됩니다. 그렇지 않으면 github-release를 로드하고 release_review_notes(notes[], 최대 5개)와 함께 finish를 실행합니다. release/next에서 main으로 릴리스 PR을 엽니다(auto_merge: false) 또는 기존 PR을 보고합니다. main이 release/next의 조상이 아닌 경우 중지합니다(먼저 백 병합, github-release), 해당 중지를 보고합니다. release: complete 또는 release: <state>를 출력합니다.

보고서

마지막 PBI 후(9단계 후 또는 --max 제한 후) /deliver는 요약을 인쇄합니다: ## Summary <n> of <m> (n = 전달됨/차단됨/일시 중지됨/건너뛰어짐/대기 중인 PBI, m = 총 PBI). 한 줄씩: #<nr> <상태> 및 작업의 notes[](있는 경우), ## Actions(차단된 PBI에 deliver <nr>, refine <nr>, needs-decision이 있는 PBI에 follow-up). 그런 다음 남은 정리 항목(있는 경우). 9단계 후 ## Release <상태>.

참조

다양한 마크다운 파일이 이 스킬의 동작을 문서화합니다. references/ 디렉토리를 참조하십시오.