kickoff

name	kickoff
description	Use when starting work on a GitHub issue — 이슈 번호/URL을 받아 스펙 파악(이슈·히스토리·코드베이스 탐색, 반문으로 미정사항 확정) 후, 구현 단위면 구현 계획 작성, 범위가 넓은 이슈면 하위 이슈 분해로 연결한다. Triggers on 이슈 번호·URL과 함께하는 모든 작업 착수 요청 — "이슈 N 시작하자/작업하자/진행하자/해보자/고치자", "킥오프", "#N 따서 시작". 이슈 언급 없이 코드 작업을 시작하려 할 때도 대응되는 이슈가 있는지 확인 후 이 스킬로 시작할 것. Does NOT trigger on 이슈 내용 조회·질문("이슈 N 뭐였지?", "N 요약해줘") — 작업 착수 의도가 있을 때만.
argument-hint	[issue-number]

Kickoff — 이슈 기반 작업 시작

전제: 이슈는 항상 불충분한 정보를 담고 있다. 게이트를 통과하기 전엔 산출물(플랜이든 분해든)을 만들지 않는다.

수집된 컨텍스트

!bash .claude/skills/kickoff/scripts/collect-context.sh $0

절차

1. 이슈 파악

• 위 주입된 이슈 본문·코멘트에서 목표·요구사항·제약을 추출한다.
• 인수가 없거나, 본문이 빈약해서 목표가 한 문장으로 추출되지 않으면 → 탐색하지 말고 유저에게 목표부터 묻는다.
• 코멘트의 마커는 이전 킥오프 기록이다: <!-- kickoff --> = 확정 스펙, <!-- kickoff-breakdown --> = 분해 브리프, <!-- kickoff-plan --> = 플랜 요약. 본문과 충돌 시 코멘트(최신)가 우선.

2. 탐색

히스토리 (주입된 데이터 기반):

• 관련 PR이 있으면 gh pr view <N> --json body로 본문(문제→접근→남은 과제)을 읽는다. 특히 "남은 과제"는 이번 이슈의 배경일 가능성이 높다.
• docs/spec/에서 관련 도메인 스펙 문서를 찾아 읽는다.
• 언급된 다른 이슈가 이번 작업의 선행/후속인지 판단한다.

코드베이스 — code-analyzer 서브에이전트(.claude/agents/code-analyzer.md)로 fan-out (독립 영역은 병렬로, Agent tool subagent_type: code-analyzer). 각 프롬프트에 분석 대상·축·목적을 지정한다:

• 축은 보통 로직 파악(현재 동작 file:line 근거) + 객체 관계(동종 컴포넌트 구조 패턴·rules 확인) 조합. 세부 보고 요구는 에이전트 정의가 담고 있다 — 프롬프트에 반복하지 않는다.
• 목적엔 "이 이슈의 스펙 브리프(충분성 게이트 5문항) 작성에 필요한 사실 수집"과 이슈 요약을 담는다.
• 보고가 길어질 규모면 산출 파일 경로(스크래치패드)를 지정한다 — 컨트롤러 컨텍스트에 전문을 싣지 않는다.
• 대상이 소수 파일로 특정되는 소규모(하네스 md·스크립트 등)면 fan-out 없이 직접 read로 갈음한다 — fan-out은 탐색 면적이 있을 때의 수단이다.

단, 이슈가 분해 단위로 보이면 탐색은 경계를 긋는 데 필요한 깊이까지만. file:line 수준 탐색은 하위 이슈의 킥오프로 미룬다.

3. 트랙 판정

탐색 결과로 이슈의 성격을 판정한다:

• 구현 단위 → 트랙 A: 완료 기준이 하나의 관찰 가능한 동작 변화 묶음으로 서술되고, 단일 플랜으로 커버 가능
• 분해 단위 → 트랙 B: 독립적으로 완료 가능한 목표가 여러 개 담겨 있거나, 목표가 추상적이라 구현 경계를 그을 수 없음

판정이 모호하면 유저에게 반문한다. "더 분해할 요소가 없다"는 판단이 서지 않을 때도 마찬가지 — 단정하지 말고 묻는다.

판정 직후, 결과와 남은 절차를 유저에게 명시 선언한다. 유저가 "분해가 끝났는지 / 이제 뭐가 남았는지"를 묻지 않아도 알 수 있어야 한다:

트랙 A (구현 단위) — 더 분해할 것 없음. 남은 절차: 충분성 게이트(반문) → 스펙 브리프 코멘트 → 플랜 작성 → 플랜 요약 코멘트

트랙 B (분해 단위) — 플랜 없이 분해로 감. 남은 절차: 분해 게이트 → 분해 브리프 코멘트 게시로 종료

---

트랙 A — 구현 단위

A-1. 충분성 게이트

계획 작성 전 다음 5문항에 답할 수 있어야 통과:

1. 완료 기준 — 뭐가 되면 끝인지, 관찰 가능한 동작 변화로 서술
2. 스코프 경계 — 건드릴/안 건드릴 레이어·모듈
3. 현재 동작 — 변경 대상의 지금 동작 (file:line 근거)
4. 설계 제약 — 따라야 할 기존 패턴·rules 조항
5. 미정 결정 포인트 — 이슈에 안 적힌 결정거리 전체 목록

5번의 각 항목을 셋 중 하나로 분류: 코드로 확정 / 프로젝트 관례로 확정 / 유저만 답 가능.

• 반문 판정 = 구현 분기 테스트: 한 항목을 두 가지로 해석했을 때 서로 다른 diff가 나오면 반문 대상. 해석이 달라도 같은 코드가 나오면 질문하지 않는다.
• "유저만 답 가능" 항목이 0이 될 때까지 AskUserQuestion 라운드를 반복한다. 좁은 해석을 recommended 첫 옵션으로 제시.
• 유저 답변이 새 미정 포인트를 만들면 그것도 게이트에 추가한다.

A-2. 스펙 브리프 기록

게이트 통과 후, 확정 내용을 이슈 코멘트로 남긴다 (gh issue comment <N> --body-file <file>):

<!-- kickoff -->
## Kickoff 스펙 브리프

**완료 기준**: <관찰 가능한 동작 변화>
**스코프**: <건드릴 것 / 안 건드릴 것>
**현재 동작**: <file:line 근거 요약>
**확정된 결정**: <반문 Q → A 요약, 항목별 한 줄>
**참고**: <관련 PR#, docs/spec 문서>

간결하게 — 읽는 사람이 한 번에 이해하는 데 필요한 최소량이 상한. 타 레포 이슈·PR 레퍼런스는 owner/repo#N 풀 형식으로 쓴다 (bare #N은 이 레포로 링크됨). 코멘트 게시 전 내용을 유저에게 먼저 보여주고 확인받는다.

A-3. 계획 작성으로 전환

프로젝트 plan 스킬을 invoke해 구현 계획을 작성한다 (plan은 superpowers writing-plans 위에 프로젝트 종속 요구 — 자족성·커밋 시퀀스·모델 티어 — 를 얹는 컴패니언이다). 스펙 브리프가 그 입력이다. kickoff 안에서 계획 방법론을 중복 구현하지 않는다.

단, 이슈나 유저가 작업 방식을 다른 스킬로 지정하면(예: 하네스 정비 이슈의 improve-skill) 플랜 대신 그 스킬 절차로 전환한다 — 전환 사실을 트랙 판정 선언에 포함한다. 이 경우 A-4는 그 스킬의 산출물이 갈음하므로 생략한다.

A-4. 플랜을 이슈에 기록

플랜 파일이 작성·승인된 후, 플랜 요약을 이슈 코멘트로 남긴다 (플랜 디렉토리 docs/superpowers/는 gitignore 대상 — 커밋을 전제하지 않고 로컬 경로를 표기한다. 코멘트의 단계 요약이 영속 기록 역할):

<!-- kickoff-plan -->
## 구현 플랜

**플랜 파일**: `<플랜 파일 로컬 경로>`
**단계**:
1. <단계별 한 줄 요약>
2. ...

• 플랜 전문을 복붙하지 않는다 — 플랜은 구현 중 갱신되는 문서라, 이슈 코멘트는 큰 그림 요약 + 최신본 링크 역할만 한다.
• 구현 중 플랜의 단계 구성이 크게 바뀌면(단계 추가·삭제 수준) 코멘트를 새로 단다. 자잘한 수정은 갱신하지 않는다.

---

트랙 B — 분해 단위

목표는 큰 꼭지 따기다. 하위 이슈의 디테일을 파는 게 아니다 — 분해는 하위 이슈의 추상화가 유지된 상태로 완료된다.

B-1. 분해 게이트

상위 목표와 분해 축만 확정한다:

1. 상위 목표 — 이 이슈가 최종적으로 이루려는 것
2. close 조건 — 뭐가 다 되면 상위 이슈가 닫히나
3. 분해 축 — 어떤 기준(레이어·기능·단계 등)으로 가를지

• 반문은 위 3개를 확정하는 데 필요한 것만 한다. 하위 이슈의 디테일에 대한 반문은 금지 — 그건 해당 하위 이슈의 킥오프에서 할 일이다.

B-2. 분해 브리프 기록

확정 내용을 이슈 코멘트로 남긴다:

<!-- kickoff-breakdown -->
## Kickoff 분해 브리프

**상위 목표**: <한 문장>
**close 조건**: <하위 목표 세트 소진 등>
**하위 이슈 리스트업**: <제목 + 한두 줄 목표. 이 수준 이상 구체화하지 않는다>
1. ...
2. ...
**미분해 잔여**: <아직 확신이 없어 가르지 않은 영역>

• lazy 분해: 한 번에 전부 분해하지 않아도 된다. 지금 확실한 꼭지만 따고, 나머지는 "미분해 잔여"로 명시해 남긴다. 잔여는 후속 킥오프에서 다시 분해한다.
• 리스트업 ≠ 깃 이슈 생성. 실제 이슈 전환은 항목별로 유저가 따로 지시할 때만 수행한다.
• 코멘트 게시 전 내용을 유저에게 먼저 보여주고 확인받는다.

B-3. 종료와 재진입

• kickoff는 분해 브리프 게시로 종료한다. 플랜을 작성하지 않는다.
• 하위 이슈(또는 리스트업 항목)에 착수할 땐 그 단위로 kickoff를 다시 실행한다. 하위도 또 분해 단위일 수 있다 — 트랙 판정부터 다시 탄다.
• 더 분해할 요소가 없는 단위만 트랙 A로 들어간다. 이 기준이 모호하면 반문한다.

재진입 경로 — 착수할 항목이 깃 이슈로 전환됐는지에 따라 갈린다:

• 독립 PR로 나갈 작업 → 이슈 전환 후 킥오프: 유저 지시로 이슈 생성(리스트업 한두 줄 + 상위 이슈 링크를 본문에) → /kickoff <새 번호>. 본문의 상위 이슈 언급으로 분해 브리프 맥락이 이어진다. 커밋·PR은 [#새번호]로 독립.
• 상위 이슈에 커밋 몇 개로 끝날 작업 → 전환 없이 재킥오프: /kickoff <상위 번호> + 착수 항목 지정. 주입된 분해 브리프 코멘트에서 해당 항목을 대상으로 트랙 판정부터 탄다. 스펙 브리프·플랜 코멘트와 커밋([#상위번호])이 상위 이슈에 쌓인다.