Multi-Agent Issue Automation
GitHub Issue를 안전한 다중 에이전트 작업 큐로 바꾸는 로컬 실행 모델. 저장소 역할, resolver, 승인 gate, PR evidence를 하나의 프로세스로 묶는다.
작업 요청과 승인 trail
로컬 격리 작업 공간
검증 로그와 변경 요약
Issue에서 PR까지, 자동화가 멈춰야 할 지점을 먼저 설계합니다.
핵심은 에이전트를 많이 부르는 것이 아니라, 어떤 상태에서 실행하고 어떤 증거가 없으면 멈추는지 시각적으로 고정하는 것입니다.
Project + labels + assignee
repo id -> local path
coordinator + workers + QA
tests + diff + policy
scope, approval, status, assignee, blocking labels
Project V2, approval label, target repo 중 하나라도 불명확하면 실행하지 않습니다.
개인 경로는 contract가 아니라 resolved-state artifact에만 남깁니다.
commit, push, merge는 target repo의 completion policy를 통과해야 합니다.
bounded workers, verification logs, PR-ready report
issue runner brief · portfolio detail
01작업 요약
GitHub Issue를 안전한 다중 에이전트 작업 큐로 바꾸는 로컬 실행 모델. 저장소 역할, resolver, 승인 gate, PR evidence를 하나의 프로세스로 묶는다.
이 기준이 흐려지면 페이지가 설명 자료로만 남고, 독자는 어떤 근거와 산출물을 확인해야 하는지 다시 물어봐야 합니다.
02입력 의존성
- Control unit: GitHub Issueready
작업 요청과 승인 trail
- Execution unit: Worktree / Branchready
로컬 격리 작업 공간
- Completion unit: PR evidenceready
검증 로그와 변경 요약
- 작업자용 상세 가이드watch
운영 절차, resolver 계약, safety gate, adoption checklist
03리스크 신호
| Signal | Severity | Meaning | First response |
|---|---|---|---|
01_무엇을_해결하는가 | high | 무엇을 해결하는가 | control repo, issue repo, work repo, pr repo 역할을 분리한다. |
02_실행이_시작되는_조건 | medium | 실행이 시작되는 조건 | Project Status 예: Ready for Agent |
03_에이전트_팀_운영 | low | 에이전트 팀 운영 | Coordinator는 issue와 resolver를 관리하고, Explorer는 affected files를 찾고, Worker는 제한된 slice를 구현한다. Test Engineer는 verification scope를 정하고, Reviewer는 증거와 위험을 확인한다. 병렬 작업은 파일 소유권이 분리될 때만 사용한다. |
04반복 절차
무엇을 해결하는가
이 페이지를 처음 읽을 때에이전트 자동화는 구현 속도보다 경계 관리가 어렵다. 이슈가 있는 저장소와 코드가 있는 저장소가 다를 수 있고, 로컬 path는 머신마다 다르며, 터미널 세션은 중간에 사라질 수 있다. 이 페이지는 issue, resolver, branch, verification, PR을 같은 작업 원장으로 묶는 방식을 보여준다.
control repo, issue repo, work repo, pr repo 역할을 분리한다.portable job contract에는 개인 머신 절대 경로를 넣지 않는다.local resolver가 work_repo_id를 실제 path로 바꾸고 remote URL을 검증한다.실행이 시작되는 조건
세부 기준을 검토할 때unattended 실행은 label 하나로 시작하지 않는다. Project Status, execution label, approval label, target repo allowlist, repo-local completion policy가 모두 맞을 때만 진행한다.
Project Status 예: Ready for AgentExecution label 예: auto-devApproval label 예: approved-for-agentPolicy blocker가 있으면 commit, push, merge, issue close를 하지 않는다.에이전트 팀 운영
세부 기준을 검토할 때Coordinator는 issue와 resolver를 관리하고, Explorer는 affected files를 찾고, Worker는 제한된 slice를 구현한다. Test Engineer는 verification scope를 정하고, Reviewer는 증거와 위험을 확인한다. 병렬 작업은 파일 소유권이 분리될 때만 사용한다.
에이전트 팀 운영Control unit작업자용 상세 가이드05역할 분담
| Role | Primary work | Handoff |
|---|---|---|
| Owner | 기준과 공개 범위 유지 | Decision / Boundary notes |
| Builder | 문서, 화면, 실행 산출물 반영 | Implementation notes |
| Reviewer | 누락, 과장, 공개 리스크 검토 | Review findings |
| Maintainer | 변경 후 다음 버전 동기화 | Update queue |
06완료 체크리스트
한 문장으로 설명 가능
이 페이지가 어떤 판단을 돕는지 제목, 요약, 첫 절차에서 바로 읽혀야 합니다.
근거와 산출물 연결
설명만 남기지 않고 기준, 결과물, 다음 페이지가 같은 맥락으로 이어져야 합니다.
공개 가능한 범위 확인
내부 경로, 계정, 고객 정보, 미검증 아이디어가 섞이지 않아야 합니다.
다음 행동이 남음
읽은 사람이 어디를 보고 무엇을 검토하면 되는지 링크와 체크 항목으로 남아야 합니다.