read
/gh-issue:read <N> [remote]
이슈 하나를 받아 본문과 코멘트를 손대지 않은 채 구조화해 출력한다. 요약도 재줄바꿈도 번역도 하지 않고, 이슈를 편집 · 종료 · 코멘트하지 않는다.
gh-issue skills
브랜치가 생기기 전의 카드 수명주기를 맡는 스킬 6개 — 아직 열린 질문을 Discussion 으로 남기는 일부터, 결론을 이슈로 등록하고 읽고, 그 이슈를 실제 파일 수정으로 바꾸는 일까지. 스킬마다 설명서 1건과 사용 예시 1건이 붙어 있습니다.
discussion-create─▶ discussion-convert또는 create─▶ read─▶ implement· proceed
여섯 중
read 하나만 아무것도 바꾸지 않습니다. 나머지 다섯은 살아 있는 저장소의 이슈 · Discussion · 보드 · 작업 파일에 씁니다. 어느 쪽인지가 SKILL.md 의 제약 목록 길이를 결정합니다 — read 는 다섯 줄, proceed 는 본문이 무슨 말을 하든 뒤집을 수 없는 금지 층으로 시작합니다.
1스킬 6개
create
/gh-issue:issue-create [options]
지금 대화를 conventional-commit 접두어 하나로 분류해 이슈로 올리고, 라벨 · 마일스톤 · 선행 이슈 의존을 자동으로 건다. 대화가 결론에 닿지 않았으면 요구사항을 지어내는 대신 멈추고 되묻는다.
discussion-create
/gh-issue:discussion-create [category]
아직 결정되지 않은 대화를 Open Questions 중심의 RFC 본문으로 만들어 Discussion 에 올린다 (기본 Ideas). 이미 결론 난 할 일은 거부하고 create 로 돌려보낸다.
discussion-convert
/gh-issue:discussion-convert <N> [remote]
결론이 난 Ideas Discussion 을 양방향 백링크가 달린 이슈로 승격한 뒤 원본을 닫고 잠근다. Ideas 아닌 카테고리는 강제 플래그 없이는 건드리지 않고, 이미 승격된 건은 다시 만들지 않는다.
implement
/gh-issue:implement <N> [mode] [remote]
이슈를 자기에게 할당하고 보드 카드를 In progress 로 옮긴 뒤, 수정 전 테스트 기준선을 먼저 잡고 파일을 고친다. 커밋하지도 PR 을 열지도 않고, 기본 브랜치나 더러운 작업트리에서는 시작하지 않으며 원래 깨져 있던 테스트는 고치지 않는다.
proceed
/gh-issue:proceed <N> [remote]
지시 이슈가 품고 있는 8개 섹션 프로토콜을 사람 개입 없이 끝까지 실행한다. 스키마가 어긋나면 이슈에 코멘트조차 남기지 않고 멈추고, 등록되지 않은 판정이나 동사는 지어내지 않고 그 자리에서 닫는다.
2세 개의 갈림길
여섯 개는 나란한 목록이 아니라 세 번의 선택으로 갈라집니다. 어느 쪽인지 정하는 것은 주제가 아니라, 대화가 어디까지 왔고 무엇을 건드릴 권한이 있느냐입니다.
결정 여부 — create / discussion-create
같은 대화를 담지만 수명주기가 다르다. 결론에 닿은 할 일은 이슈로, 아직 답이 없는 질문은 Discussion 으로 간다. 둘 다 라우팅 가드를 들고 있어 잘못 온 쪽을 반대편으로 돌려보내고, 질문이 결론이 된 뒤 돌아오는 길이 discussion-convert 다.
쓰기 여부 — read / 나머지 다섯
read 는 GitHub 상태를 하나도 바꾸지 않아 남의 저장소를 가리켜도 안전하고, 출력 자체가 산출물이라 다음 스킬의 입력이 된다. 나머지는 이슈 · Discussion · 보드 · 작업 파일에 실제로 쓴다.
입력의 종류 — implement / proceed
같은 자리의 형제지만 읽는 이슈가 다르다. implement 는 코드 변경 이슈를 받아 direct / plan / brainstorming 중 접근을 고른다. proceed 가 받는 지시 이슈는 이미 설계가 끝나 있어서 고를 것이 없다 — 모드는 항상 direct 이고, 대신 쓰기 단계마다 게이트가 붙는다.