⚠️ Superseded by /dev:batch (commands/dev/batch.md) for any Epic with a real Story→Sub-task hierarchy. This agent loops over epic.children flatly — it does not distinguish Story vs Sub-task, does not create an Epic branch, and does not apply the hierarchical branch strategy (branch-hierarchy). Use /dev:batch as the default entry point; call @issue-processor directly only when you deliberately want the simpler flat loop (e.g. an Epic whose children are all independent, parent-less issues).

@issue-processor — Epic 하위 이슈 평면 처리 (단순 폴백)#

한마디로#

큰 작업 묶음(Epic) 아래에 달린 여러 개의 작은 할 일(이슈)을, 순서대로 하나씩 알아서 처리해 주는 담당 일꾼입니다. 공장의 컨베이어 벨트처럼, 이슈를 한 건씩 집어 "작업 중 → 코드 작성 → 검토 요청 → 완료"까지 흘려보내고 다음 이슈로 넘어갑니다.

Story/Sub-task 계층을 구분하지 않는 평면 처리 방식입니다. Epic 아래 Story→Sub-task 계층이 실제로 있다면 /dev:batch(정식 계층 처리, 브랜치 분리)를 사용하세요. 이 에이전트는 @issue-processor로 직접 호출할 때만 씁니다.

누가·언제 쓰나요#

• Epic 자식들이 계층 없이(모두 독립적으로) 쌓여 있어, 굳이 Story/Sub-task 브랜치 분리가 필요 없을 때
• @issue-processor로 직접 호출해 단순 평면 처리를 원할 때 — 일반적인 경우에는 /dev:batch를 사용하세요.

무엇을 해주나요#

Epic에 속한 자식 이슈들을 순서대로 처리하고, 각 이슈마다 다음을 자동으로 진행합니다.

• ZenHub 보드에서 이슈 상태를 작업 중(In Progress) → 검토/QA(Review/QA) 로 이동
• 이슈별 작업 브랜치 생성과 커밋
• GitHub PR(Pull Request) 생성 및 코드 리뷰 반영
• 병합(merge) 후 이슈를 확실히 종료(Closed) 상태로 마감 (Done에 방치하지 않음)
• 마지막에 처리한 이슈 목록과 남은 이슈를 정리한 완료 보고

어떻게 쓰나요#

# 슬래시 명령으로 일괄 처리 실행
/dev:batch

# 또는 에이전트를 직접 호출
@issue-processor

위 명령은 Epic 아래 이슈들을 자동으로 순서대로 처리합니다. (별도 옵션·플래그는 없습니다.)

안에서 무슨 일이 벌어지나요#

크게 세 단계로 진행됩니다.

1. 이슈 분석 — Epic 아래 모든 자식 이슈를 조회하고, 의존 순서를 파악해 처리 계획을 세웁니다.
2. 이슈별 반복 처리 — 이슈 하나마다 다음을 차례로 수행합니다.
   • 상태를 "작업 중"으로 이동
   • 코드 구현(또는 기존 구현 확인) 후 작업 브랜치 생성·커밋
   • 상태를 "검토/QA"로 이동하고 PR 생성
   • 코드 리뷰를 기다려 피드백 반영
   • 병합 후 이슈가 실제로 종료됐는지 확인하고, 안 됐으면 직접 종료 처리
   • 다음 이슈로 이동
3. 완료 보고 — 처리한 이슈 목록을 출력하고 남은 이슈를 점검합니다.

이슈에 BDD 시나리오가 있으면, 시나리오를 읽어 코드와 대응시키고 빠진 구현을 보완한 뒤 화면에서 확인합니다. 또한 이슈 상태가 "Done"에 머무는 것을 막고, 병합 시 GitHub과 ZenHub가 모두 종료 상태로 동기화되도록 한 번 더 확인합니다.

const ws  = await mcp__zenhub__getWorkspacePipelinesAndRepositories();
const pid = (n) = >   { const p = ws.pipelines.find(p = >   p.name === n); if (!p) throw new Error(` ' ${n} '   없음. 라이브: ${ws.pipelines.map(p = >   p.name).join( " ,  " )}`); return p.id; };
const inProgressId = pid( " In Progress " ), reviewQaId = pid( " Review/QA " );

foreach issue in epic.children:
  1. moveIssueToPipeline({ issueId: issue.id, pipelineId: inProgressId })
  2. Implement code or verify existing implementation
  3. git checkout -b feature/{issue-number}-{short-desc}
  4. Commit changes
  5. moveIssueToPipeline({ issueId: issue.id, pipelineId: reviewQaId })
  6. gh pr create --title  " {issue.title} "   --body  " Closes #{issue.number} " 
   7. Wait for code review and apply feedback
  8. Squash merge (merge = Close): `Closes #` auto-closes GitHub → ZenHub syncs to Closed
  8.5. Verify + fallback: `gh issue view {n} --json state` → if not CLOSED, `gh issue close {n} --reason completed`;
       `searchClosedIssues  " #{n} " ` → if missing, `updateIssue state:CLOSED`. Never park in Done (Done ≠ closed).
  9. Move to next issue

{
   " tool " :  " mcp__zenhub__moveIssueToPipeline " ,
   " arguments " : {
     " issueId " :  " {graphql_issue_id} " ,
     " pipelineId " :  " {target_pipeline_id} " 
   }
}

{
   " tool " :  " mcp__zenhub__searchLatestIssues " ,
   " arguments " : {
     " query " :  " parent:{epic_number} " 
   }
}

{
   " tool " :  " mcp__zenhub__updateIssue " ,
   " arguments " : {
     " issueId " :  " {graphql_issue_id} " ,
     " state " :  " CLOSED " 
   }
}

const workspace = await mcp__zenhub__getWorkspacePipelinesAndRepositories();
const pipelines = workspace.pipelines;
// Find by name in pipelines:  " New Issues " ,  " In Progress " ,  " Review/QA " , etc.
// Done pipeline is NOT used (Done ≠ closed). Merge = Close: `Closes #` → GitHub closed
// → ZenHub syncs to Closed. Verify with searchClosedIssues + fallback updateIssue.