to-issuelisted

# To Issue Skill `/to-issue` 는 GitHub issue 작성/등록 흐름이다. 메인 Claude 가 사용자와 직접 대화하며 모호함을 해소하고, 표준 Issue Brief 초안을 만든 뒤, 사용자 승인 후에만 GitHub issue 를 생성한다. ## 범위 - 메인 Claude 전담 흐름이다. 서브에이전트, planner, validator 를 호출하지 않는다. - 버그를 바로 고칠 요청은 `/impl`, GitHub issue 로 추적할 요청은 `/to-issue` 가 처리한다. - `/to-issue` 는 이미 "issue 로 만들겠다"는 의도가 있는 문제/작업 후보를 durable 작업 계약으로 바꾸는 흐름이다. - `/spec` 의 epic/story 일괄 생성 흐름은 제품 계획 산출물 전용이다. `/to-issue` 는 단발 issue 또는 승인된 vertical slice 묶음을 다룬다. - `/to-issue` 는 권장 도우미다. `/to-issue` 외에 이미 승인된 대화나 다른 agent workflow 가 issue 를 만들 때도 `scripts/check_issue_body.mjs` pre-create validation 을 통과한 뒤 `gh issue create` 를 실행해야 한다. ## 원칙 - Issue Brief 는 agent 나 사람이 작업할 계약이다. 원래 대화와 코멘트는 context 이고, 작업 기준은 brief 다. - 오래 살아도 유효해야 하므로 구현 파일 경로, line number, 현재 코드 구조에 의존하지 않는다. - 무엇을 만들지와 어떤 동작이 되어야 하는지를 쓴다. 어떻게 구현할지는 `/impl` 또는 작업자가 판단한다. - 코드 조각, 해결책 지시, layer-by-layer 작업 계획은 기본적으로 넣지 않는다. prototype 의 state machine, schema, type shape 가 prose 보다 결정을 정확히 담는 경우만 짧게 포함하고 prototype 출처를 명시한다. - Acceptance criteria 는 각각 독립적으로 검증 가능해야 한다. - 큰 계획을 여러 issue 로 나누는 경우 horizontal layer 가 아니라 end-to-end vertical slice 로 나눈다. 완료된 slice 는 독립적으로 demo 또는 검증 가능해야 한다. - parent issue 가 있더라도 `/to-issue` 는 parent issue 를 닫거나 임의 수정하지 않는다. ## 기준 파일 - IssueType, Priority, repo label 매핑은 [`issue-fields.md`](issue-fields.md)를 SSOT 로 사용한다. - Project lifecycle 전체 축과 status 전이는 [`../../docs/plugin/github-project.md`](../../docs/plugin/github-project.md)를 SSOT 로 사용한다. - Issue Brief 본문 구조는 [`templates/i