스킬

IDD Skill: 이슈 기반 개발 워크플로 템플릿

AI 코딩 에이전트가 자신의 Git 저장소에서 이슈 인수부터 PR 머지까지 전체 개발 루프를 돌도록 하는 데 가장 적합합니다. 사용 전에 git, 인증된 gh CLI, jq, curl을 준비하고, 기본 완전 자동 머지 정책이 팀 규범에 맞는지 확인하세요.

Official source · IDD Skill

Install

Import and onboard github:kurone-kito/idd-skill's IDD into this repository.

이런 분께 적합합니다

  • 자신의 Git 저장소에서 일상 개발을 진행하면서 "이슈부터 머지까지"를 반복 가능한 절차로 만들고 싶은 개발자와 소규모 팀: 가져온 후에는 저장소 안의 AI 코딩 에이전트가 공식 설명된 워크플로에 따라 준비된 이슈를 발견하고, 인수를 선언하고, 브랜치에서 구현하고, PR을 열고, 리뷰 피드백을 처리하고, CI를 기다리고, 저장소가 선택한 머지 정책에 따라 머지하고 정리합니다. 공식은 이 워크플로를 "이식 가능"하다고 설명하며, 단일 도구에 묶이지 않고 저장소와 함께 가져와 쓰는 것입니다.
  • 여러 AI 코딩 도구를 함께 쓰면서 흐름을 단일 클라이언트에 묶고 싶지 않은 개발자: 공식 설명에 따르면 핵심 루프는 GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode, Antigravity CLI(구 Gemini CLI) 전반에서 동작합니다.
  • 여러 작업 세션이 서로 다른 이슈를 병렬로 진행해야 하는 팀: 공식 설명에 따르면 분산 모드의 기본 정책은 fully_autonomous_merge이며, 작업 세션이 머지까지 바로 진행될 수 있습니다. 세션 간 조율 방법과 충돌 회피 방법은 공식적으로 설명되어 있지 않습니다.
  • 도입 전 확인이 필요한 사항: 공식 페이지는 GitHub 외 호스팅 플랫폼 지원 여부를 설명하지 않으며, 이 부분은 미확인입니다. 팀이 완전 자동 머지를 받아들이지 않는다면 기본 정책을 먼저 평가하거나 조정해야 하는데, 조정 방법은 공식적으로 다뤄지지 않았습니다.

3분 만에 첫 시도하기

  • 전제: 브랜치를 만들고 PR을 열 권한이 있는 Git 저장소 한 개, 그리고 환경에 공식이 나열한 루프 전체 의존성 ― git, 인증된 gh CLI(또는 동등한 GitHub MCP 통합, 둘 중 하나만 충족되면 됨), jq, curl 같은 REST 클라이언트 ― 를 갖춰 둡니다.
  • 설치 위치와 방법: 파일을 수동으로 복사할 필요가 없습니다. 공식이 제시하는 연결 방식은 대상 저장소 안에서 AI 에이전트에게 가져오기 지시를 직접 내리는 것이며, 온보딩 가이드가 템플릿 복사를 완료합니다.
  • 시작: 저장소에서 지원되는 에이전트를 열고 아래 공식 지시를 한 글자도 바꾸지 말고 그대로 입력합니다.
Import and onboard github:kurone-kito/idd-skill's IDD into this repository.
  • 첫 시도는 저위험 작업에 묶어 두길 권합니다: 에이전트에게 워크플로 가이드를 읽게 하고, 기존 준비된 이슈를 나열하고 다음 단계 계획을 설명하게 하되, 인수도 코드 변경도 하지 않습니다. 공식이 설명한 루프의 출발점이 바로 "가이드 읽기, 준비된 이슈 발견, 인수"이므로, 인수가 일어나기 전이라면 언제든 중단할 수 있습니다.
  • 성공 신호: 에이전트가 워크플로 요점을 되풀이하고 기존 이슈를 정확히 나열하면 가져오기와 가이드 읽기가 작동한 것입니다. 템플릿 파일이 저장소에 복사되면 온보딩이 완료된 것입니다. 공식은 구체적인 저장 경로를 밝히지 않으므로 정확한 위치는 에이전트의 실제 출력을 기준으로 삼으세요(미확인).

활용 사례

사례 1: 준비된 이슈 하나를 끝까지 완수. 상황: 백로그에 준비됨 표시가 된 issue가 이미 있고, 인수부터 머지까지의 폐쇄 루프를 검증하고 싶습니다. 에이전트에게 "준비된 이슈 하나를 인수해서 구현을 완료해 줘"라고 지시합니다. 에이전트는 공식 전체 루프를 밟습니다 ― 워크플로 가이드 읽기, 이슈 인수, 브랜치 구현, PR 생성, 리뷰 피드백 처리, CI 대기, 저장소가 선택한 머지 정책에 따른 머지와 정리. 관찰 가능한 지점은 순서대로 브랜치 생성, PR 생성, CI 상태 변화, 머지와 브랜치 정리이며, 각 단계는 공식 루프의 고정 단계에 해당합니다. 기본 정책인 fully_autonomous_merge에서는 작업 세션이 머지까지 진행될 수 있으므로, 첫 실행 전에 CI 게이트와 브랜치 보호가 갖춰졌는지 확인하거나 지시에 이번엔 PR까지만 진행한다고 명시하세요.

사례 2: 발견과 계획만 하고 아무것도 바꾸지 않기. 상황: 이 절차가 저장소에 맞는지 먼저 평가하고 싶고, 아직 손대게 할 생각은 없습니다. 에이전트에게 "워크플로 가이드를 읽고, 준비된 모든 이슈를 각각 구현 방향과 함께 나열해 줘. 인수는 하지 마"라고 지시합니다. 이것은 루프의 전반부(가이드 읽기, 이슈 발견)만 사용하며 브랜치나 PR을 만들지 않습니다. 이슈가 어떻게 "준비됨"으로 표시되는지는 공식적으로 설명되지 않았으므로, 에이전트가 목록이 비었다고 보고하면 저장소 안의 이슈 상태 표기 방식을 먼저 확인하세요. 기대할 수 있는 결과는 이슈 목록과 구현 계획 텍스트이며, 구현에 들어갈지는 다음 지시가 결정합니다. 계획이 실효성 있다고 판단되면 사례 1에 따라 이슈 하나로 전체 루프를 돌릴 수 있습니다.

사용상의 한계

  • 부작용과 확인 지점: 가져오기는 저장소에 템플릿 파일을 복사합니다. 새 파일만 추가하는지 아니면 기존 파일도 변경하는지 공식적으로 설명되지 않았으므로, 가져온 뒤 에이전트가 제시하는 변경 목록을 먼저 확인하길 권합니다. 전체 루프는 브랜치 생성, 코드 커밋, PR 생성을 수행하고 기본 정책 fully_autonomous_merge에서는 머지까지 진행합니다. 어떤 작업이 사전 확인을 요청하는지 공식이 항목별로 설명하지 않으므로, 매 지시마다 허용 범위를 명시적으로 정해 주세요.
  • 네트워크와 명령 접근: 전체 루프에는 인증된 gh CLI나 동등한 GitHub MCP 통합이 필요하고 curl 같은 REST 클라이언트도 명시되어 있습니다. 즉 에이전트는 루프 중에 이 도구들을 통해 GitHub API에 접근합니다(이슈 읽기, PR 생성과 머지 등). 구체적으로 어떤 엔드포인트를 호출하는지, 그 밖의 네트워크 접근이 있는지는 공식이 항목별로 나열하지 않았습니다.
  • 실행 환경과 클라이언트 전제: 공식은 핵심 루프가 GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode, Antigravity CLI(구 Gemini CLI) 전반에서 동작한다고 나열합니다. 목록 밖의 에이전트 사용 가능 여부, 운영체제 추가 요구 사항, 의존성 결손 시의 축소 동작 여부는 모두 공식적으로 설명되지 않았습니다.
  • 공식이 명시한 제한과 미지수: 공식 자료는 GitHub 외 호스팅 플랫폼 지원에 대해 언급하지 않고, fully_autonomous_merge 외에 어떤 머지 정책이 있는지, 전환 방법도 설명하지 않습니다. CI 실패 후 에이전트의 재시도 동작 역시 미확인입니다. 이상 세부 사항은 저장소로 가져온 워크플로 가이드 원문을 기준으로 해야 합니다.