unity-issue-message
Unity 게임 프로젝트를 위한 GitHub 이슈(Issue) 작성 스킬. 사용자가 "이슈 작성해줘", "이슈 만들어줘", "이슈로 정리해줘", "태스크 등록해줘" 등으로 요청하거나, 대화 세션에서 새 기능 개발을 계획/논의하는 시점 또는 기능 개발을 마무리하는 시점에 반드시 이 스킬을 사용할 것. 하나의 대화 세션은 보통 기능 하나의 개발에 대응하며, 그
SKILL.md.claude/skills/unity-issue-message/SKILL.md
GitHubUnity Issue Message
Unity 게임 프로젝트를 위한 GitHub 이슈 작성 스킬입니다. commit-convention-helper 스킬과 짝을 이루는 워크플로우로 설계되어 있습니다: 이 스킬로 기능 이슈를 먼저 만들고, 개발을 진행하면서 나온 커밋들이 그 이슈 번호를 참조합니다.
언제 사용하는가
이 스킬은 두 가지 모드로 쓰입니다. 어느 모드인지는 대화 흐름으로 판단하고, 애매하면 사용자에게 짧게 확인합니다.
- 계획(Planning) 모드: 아직 구현을 시작하지 않은 새 기능에 대해, 개발을 시작하기 전에 이슈부터 만들고자 할 때. 이슈를 먼저 만들고 이후 구현이 그 이슈를 따라간다. 체크리스트 항목은 전부 미완료(
- [ ])로 작성. - 문서화(Retrospective) 모드: 기능 개발이 진행 중이거나 이미 끝난 뒤, 지금까지 한(또는 다 한) 작업을 이슈로 남길 때. 완료된 항목은
- [x], 아직 안 한 항목은- [ ]로 실제 진행 상태를 그대로 반영한다.
판단 기준은 단순하다: 개발 시작 전이면 계획 모드, 개발 도중이거나 완료 후면 문서화 모드.
입력은 대화 세션의 맥락입니다. 세션에서 논의되거나 구현된 기능의 목적과 세부 작업 단위를 추론해서 이슈를 구성합니다. 불확실한 부분(범위가 불명확한 작업, 세션에서 언급되지 않은 세부사항)은 지어내지 말고 사용자에게 확인하세요.
작업 순서
- 모드 판단: 계획 모드인지 문서화 모드인지 정한다.
- 기능의 목적/배경 정리: 이 기능이 왜 필요한지, 무엇을 해결하는지를 한두 문단으로 요약한다.
- 세부 작업 단위로 분해: 기능을 실제로 구현 가능한 작업 단위(체크리스트 항목)로 쪼갠다. 지나치게 크지도(한 항목이 사실상 기능 전체), 지나치게 잘게(사소한 한 줄 수정까지) 쪼개지 않는다 — 각 항목이 "완료 여부를 판단할 수 있는 단위"인지가 기준이다.
- scope/type 라벨 결정 (아래 표 참고).
commit-convention-helper스킬과 동일한 scope 목록을 사용한다. - 제목/본문 작성 (아래 형식 참고).
- 최종 결과를 코드 블록으로 제시하여 GitHub 이슈 생성 화면에 그대로 붙여넣을 수 있게 한다. 제목과 본문을 분리해서 보여준다.
- 이슈 등록은 사용자의 허용에 따라 한다. 이슈 초안(제목/본문/추천 라벨)을 제시한 뒤, 사용자의 허용을 받아 GitHub에 클로드가
ghCLI 등으로 대신 등록힌다. 사용자가 허용을 하지 않으면 이슈는 생성되지 않는다. - 등록 후 번호를 받아 확인한다. 사용자가 이슈를 등록하고 번호(예:
#12)를 알려주면, 그 번호를 되짚어 확인하고 — 이후 관련 커밋을 만들 때 (commit-convention-helper스킬 사용 시) footer에Refs #12또는Closes #12로 반영할 수 있다고 짧게 안내한다. 번호를 사용자가 알려주기 전에는 절대 추측해서 채우지 않는다.
이슈 형식
[<scope>] <제목>
## 설명
<배경과 목적 — 왜 이 기능/작업이 필요한지>
## 작업 목록
- [ ] <구현 작업 1>
- [ ] <구현 작업 2>
- [ ] <구현 작업 3>
- 제목은 한국어로, 간결하게.
[scope]접두어로 어느 영역인지 한눈에 보이게 한다. - 설명은 "무엇을 만드는지" 나열보다 "왜 필요한지/어떤 문제를 해결하는지"를 우선한다.
- 작업 목록은 실제 구현 순서나 논리적 순서를 따른다.
- 제목/본문 아래에 추천 라벨을 별도로 제시한다 (GitHub 이슈 생성 화면에서 라벨은 본문과 별개 필드이므로).
type 라벨
| label | 의미 |
|---|---|
feature |
새 기능 개발 |
bug |
버그 수정 |
refactor |
구조 개선 (기능 변화 없음) |
task |
그 외 작업 단위 (세팅, 문서화, 리서치 등) |
chore |
잡무성 작업 |
scope 라벨
commit-convention-helper 스킬과 동일한 목록을 사용합니다.
| scope | 대상 |
|---|---|
movement |
캐릭터 이동 로직 |
camera |
카메라 추적/줌/흔들림 |
skill-block |
스킬 블록 낙하, 체이닝(드래그), 슬롯 조작 로직 |
skill |
개별 스킬 데이터, 모션, 이펙트 |
resource |
자원(마나) 생성·누적·소모, 특수 스킬 생성 |
hit |
피격 판정, 기준 프레임 처리 |
ui |
전투 UI의 시각적 표현/레이아웃 (skill-block과 달리 로직이 아닌 뷰) |
core |
여러 시스템에 걸친 아키텍처성 작업 |
network |
멀티플레이(NGO) 관련 — 실제 멀티 개발 착수 전에는 사용하지 않음 |
프로젝트 구조와 맞지 않으면 새 scope를 제안하고 어떤 걸 새로 만들었는지 짚어준다.
예시
계획 모드 (구현 전)
[skill] 스킬 블록 3연쇄 콤보 발동 로직
## 설명
현재 스킬 블록이 단발성으로만 소모되어 전투가 단조로움. 슬롯 내 인접한
동일 종류 블록을 연속 선택해 이어지는 3연쇄 콤보를 추가해 전투 리듬감을
살리고, 이후 콤보 기반 스킬 확장의 기반을 마련한다.
## 작업 목록
- [ ] SkillComboHandler(MonoBehaviour) 설계 및 추가
- [ ] 콤보 입력 버퍼링 및 타이머 로직 구현 (Coroutine 기반)
- [ ] 콤보 단계별 Animator 파라미터/애니메이션 클립 연결
- [ ] 콤보 리셋 조건(시간 초과, 피격 등) 처리
- [ ] 콤보 판정용 Collider/데미지 값 밸런싱
추천 라벨: feature, skill
문서화 모드 (구현 후, 바로 닫는 용도)
[movement] 대시 중 이동 입력에 넉백이 씹히는 버그 수정
## 설명
대시 애니메이션 재생 중 이동 입력이 들어오면 Rigidbody 이동 처리가
Animator의 대시 이동과 동시에 적용되어 캐릭터가 제자리에서 미끄러지는
문제가 있었음. 대시 상태에서 이동 입력을 일시적으로 락하도록 수정.
## 작업 목록
- [x] 문제 재현 및 원인 파악 (이동 입력과 대시 이동이 동시 적용됨)
- [x] 대시 상태 플래그로 이동 입력 락 처리
- [x] 대시 종료 시 입력 락 해제 확인
추천 라벨: bug, movement
커밋 스킬과의 연계
이슈 등록은 사용자의 직접적인 요청이 없는 한, 클로드가 gh CLI 등으로 대신 등록합니다. 흐름은 다음과 같습니다.
- 이 스킬로 이슈 초안(제목/본문/추천 라벨)을 만들어 제시한 후 사용자에게 확인받는다.
- 사용자가 그 내용을 허용하면, 이슈 작성을 진행한다.
- 이후 관련 커밋을 만들 때(
commit-convention-helper스킬 사용 시) footer에 다음처럼 반영하도록 안내한다.
Refs #12 ← 작업이 진행 중일 때
Closes #12 ← 이 커밋으로 해당 이슈가 완전히 끝날 때 (머지 시 이슈 자동 종료)
이슈 번호는 사용자가 실제로 등록한 뒤 알려줘야만 알 수 있는 정보이므로, 스킬이 임의로 번호를 지어내지 않는다. 사용자가 번호를 아직 안 줬다면 footer의 이슈 참조 줄은 비워두거나 생략한다.
주의사항
- 세션에서 확인되지 않은 작업 항목을 지어내서 체크리스트에 채우지 않는다.
- 체크리스트 항목이 너무 많아지면(10개 이상) 이슈를 여러 개로 쪼갤지 사용자에게 먼저 물어본다.
- 문서화 모드에서 일부 작업만 완료됐다면 미완료 항목은
- [ ]로 남겨 실제 진행 상태를 정확히 반영한다.