to-issuelisted

# To Issue Skill `/to-issue` 는 GitHub issue 등록 흐름이다. 메인 Claude 가 대화 맥락으로 모호함을 해소하고 표준 Issue Brief 를 구성한 뒤, IssueType/Priority 를 추론하고 라벨을 붙여 초안 승인 대기 없이 바로 GitHub issue 를 등록한다. 사용자는 등록된 issue 를 GitHub web 에서 확인하고 수정 요청으로 교정한다. ## 범위 - 메인 Claude 전담 흐름이다. 서브에이전트, planner, validator 를 호출하지 않는다. - 버그를 바로 고칠 요청은 `/impl`, GitHub issue 로 추적할 요청은 `/to-issue` 가 처리한다. - `/to-issue` 는 이미 "issue 로 만들겠다"는 의도가 있는 문제/작업 후보를 durable 작업 계약으로 바꾸는 흐름이다. - `/spec` 의 epic/story 일괄 생성 흐름은 제품 계획 산출물 전용이다. `/to-issue` 는 단발 issue 또는 승인된 vertical slice 묶음을 다룬다. - GitHub issue 생성·등록은 `/to-issue` 를 기본 경로로 사용하고 직접 만들지 않는다 (작업 흐름 중 자발적으로 남기는 후속 이슈 포함). `/to-issue` 외 대화나 다른 agent workflow 가 issue 를 만들 때도 `scripts/check_issue_body.mjs` pre-create validation 을 통과하고 IssueType 라벨을 붙인 뒤 `gh issue create` 를 실행해야 한다. ## 원칙 - Issue Brief 는 agent 나 사람이 작업할 계약이다. 원래 대화와 코멘트는 context 이고, 작업 기준은 brief 다. - 이슈를 등록한 세션이 아닌 다른 세션이 처리·구현하는 것이 기본이다. 그래서 등록 세션이 이미 아는 배경·제약·의도는 대화에만 두고 생략하지 말고 Issue Brief(특히 Context)에 옮겨, 이슈 하나만 읽어도 자족적으로 착수할 수 있게 한다. 옮기는 대상은 목표와 판단 근거이지 구현 방법이 아니다. - 오래 살아도 유효해야 하므로 구현 파일 경로, line number, 현재 코드 구조에 의존하지 않는다. - 무엇을 만들지와 어떤 동작이 되어야 하는지를 쓴다. 어떻게 구현할지는 `/impl` 또는 작업자가 판단한다. - 코드 조각, 해결책 지시, layer-by-layer 작업 계획은 기본적으로 넣지 않는다. prototype 의 state machine, schema, type shape 가 prose 보다 결정을 정확히 담는 경우만 짧게 포함하고 prototype 출처를 명시한다. - Acceptance criteria 는 에이전트가 독립적으로 검증하고 완료할 수 있는 항목만 체크박스로 쓴다. command/eval/test 실행으로 판정하면 `[command]`, 산출물·diff·계약을 읽어 판정하면 `[agent-read]` 를 각 항목 앞에 붙인다. - 사람의 시각·취향·운