Kickoff

---
name: kickoff
description: Use when starting work on a GitHub issue — 이슈 번호/URL을 받아 정찰(이슈·히스토리·코드베이스 탐색)로 사실과 미정 결정 목록을 수집한 후, 사이즈(XL/L/M/S)를 판정해 M·S 는 작전명령·구두지시로, L·XL 은 campaign(작전계획)으로 연결한다. 미정 결정의 확정은 이 스킬이 아니라 계획 스킬(opord·campaign) 소관. Triggers on 이슈 번호·URL과 함께하는 모든 작업 착수 요청 — "이슈 N 시작하자/작업하자/진행하자/해보자/고치자", "킥오프", "#N 따서 시작". 이슈 언급 없이 코드 작업을 시작하려 할 때도 대응되는 이슈가 있는지 확인 후 이 스킬로 시작할 것. Does NOT trigger on 이슈 내용 조회·질문("이슈 N 뭐였지?", "N 요약해줘") — 작업 착수 의도가 있을 때만.
argument-hint: "[issue-number]"
---

# Kickoff — 이슈 기반 작업 시작

**전제: 이슈는 항상 불충분한 정보를 담고 있다.** 킥오프는 그 불충분을 **확정하지 않고 목록화한다** — 소관은 접수·정찰·사이즈 판정·라우팅까지, 미정 결정의 확정(반문 라운드)은 계획 스킬(opord·campaign)의 질문 단계 소관이다. 킥오프가 남기는 반문은 둘뿐이다: 목표가 한 문장으로 추출되지 않을 때(§1), 사이즈 판정이 모호할 때(§3).

## 수집된 컨텍스트

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

## 절차

**유저 개입 종료 — 전 단계 공통.** 유저가 보류·중단·방식 전환·단계 생략을 지시하면 그 시점까지의 산출물(정찰 사실·미정 목록)로 킥오프를 끝낸다 — 남은 단계 미수행은 이탈이 아니라 이행이다. 판단·지시 근거를 사이즈 판정 선언(또는 종료 보고)에 한 줄 남긴다. 브리프 없이 끝나는 중단이면 그때까지 수집된 미정 목록을 이슈 **본문**에 반영하고(`gh issue edit`) 끝낸다 — 무엇이 미정인지는 그 자체로 확정된 사실이고 다음 킥오프의 입력이다. 코멘트를 새로 쌓지 않는다(A-2 코멘트 상한).

### 0. 착수 표시 — 보드와 상황판

킥오프 대상 이슈를 개발 대시보드(Project #2)의 `In Progress`로 옮기고, 같은 자리에서 상황판 진행 파일 씨앗을 만든다 (사이즈 무관 — 착수했다는 사실이 기준이다):

```bash
.claude/scripts/project-board.sh <이슈번호> "In Progress"

mkdir -p .operations/<이슈번호>
[ -f .operations/<이슈번호>/progress.md ] || cat > .operations/<이슈번호>/progress.md << 'EOF'
<!-- progress -->
명령 상태: 정찰
핵심: <이슈 제목>
EOF
.claude/scripts/campaign-board-sync.sh <이슈번호>
```

`핵심:` 은 이슈 제목을 그대로 넣는다 — 이슈 파악 전이라 목표 한 문장이 아직 없고, 요지로 갈아 쓰는 건 초안 저장 시점이다(opord §8). **제목을 셸 리터럴에 꽂지 말고 위 heredoc 그대로 쓴다** — 구분자를 `'EOF'` 로 따옴표 치면 제목 속 홑따옴표·백틱·`$` 가 전부 리터럴이 된다. 씨앗이 이미 있으면(재킥오프·진행 중 복귀) 덮어쓰지 않는다 — 앞의 `[ -f ]` 가드가 그걸 한다.

씨앗을 안 만들면 **계획이 서기 전까지 상황판에 그 이슈가 존재하지 않는다** — 상황판 파서는 `campaign.md` 나 `progress.md` 가 있는 이슈만 아이템으로 만든다. 작전명령을 안 쓰는 S 는 진행 파일이 생길 자리가 아예 없어 영영 안 뜬다. 이후 상태 전이(`초안`·`재가`…)와 서식은 opord §6·§8 소관이다 — 여기서는 씨앗만 놓는다.

이슈 파악 전에 실행한다 — 정찰·판정이 막혀 산출물이 안 나와도 착수는 착수다. 배선이 실패해도 킥오프는 계속하고, 실패 사실만 유저에게 한 줄로 알린다.

**진행 중 작업으로의 복귀는 옮기지 않는다** — 이미 작업 브랜치·커밋·PR이 있는 진행 중 작업으로 복귀·전환하는 경우다. 보드는 이미 그 이후 상태(`In Progress`·`Review + QA`)라 되돌리면 진행이 후퇴한 것으로 읽힌다.

### 1. 이슈 파악

- 위 주입된 이슈 본문·코멘트에서 목표·요구사항·제약을 추출한다.
- 인수가 없거나, 본문이 빈약해서 **목표가 한 문장으로 추출되지 않으면 → 탐색하지 말고 유저에게 목표부터 묻는다.**
- 코멘트의 마커는 이전 킥오프 기록이다: `<!-- kickoff -->` = 정찰 브리프 (구 스펙 브리프 — 옛 코멘트의 "확정된 결정" 항목은 여전히 유효한 확정이다. 구 `<!-- kickoff-breakdown -->` 분해 브리프는 폐지 — 작전계획 campaign.md 가 갈음한다). 본문과 충돌 시 코멘트(최신)가 우선 — 단 재가된 작전명령의 **핵심**은 본문에 미러되므로(opord §7) 본문이 곧 최신 확정 상태다. 전문은 본문에 없다 — 재가 원문 코멘트에 부록 D 단편명령 코멘트를 순서대로 적용한 것이 최신 전문이고, 실행에 들어가려면 그걸 읽어야 한다.

### 2. 탐색

**히스토리** (주입된 데이터 기반):
- 관련 PR이 있으면 `gh pr view <N> --json body`로 본문을 읽는다. "남은 과제" 항목이 있으면 이번 이슈의 배경일 가능성이 높다 — 없는 PR도 정상이다.
- `docs/spec/`에서 관련 도메인 스펙 문서를 찾아 읽는다.
- 언급된 다른 이슈가 이번 작업의 선행/후속인지 판단한다.
- `grep "#<이슈번호>" docs/troubleshooting/*.md` — 이 이슈를 참조하는 `resolution: deferred` 레코드가 있으면 **root cause가 이미 규명돼 있다.** 재규명하지 말고 레코드의 근본 원인·확정된 수정 방향을 정찰 브리프의 "현재 동작"에 싣고, 레코드 경로를 "참고"에 남긴다. 이 작업이 그 레코드를 해소한다는 사실도 함께 — implement 완료 판정이 이걸 받아 `resolution`을 갱신한다 (troubleshoot ③).

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

- 축은 보통 **로직 파악**(현재 동작 file:line 근거) + **객체 관계**(동종 컴포넌트 구조 패턴·rules 확인) 조합. 세부 보고 요구는 에이전트 정의가 담고 있다 — 프롬프트에 반복하지 않는다.
- 목적엔 "이 이슈의 정찰 브리프(A-1 5문항) 작성에 필요한 사실 수집"과 이슈 요약을 담는다.
- 보고가 길어질 규모면 산출 파일 경로(스크래치패드)를 지정한다 — 컨트롤러 컨텍스트에 전문을 싣지 않는다.
- 환경 제약(서브에이전트 호출 금지 등)으로 fan-out이 불가하면 직접 read/grep으로 같은 면적을 커버한다 — 이 대체는 이행이다.
- **판정 기준은 탐색 면적이지 대상 종류가 아니다** — 변경 대상이 이미 파일 단위로 특정됐고 직접 read 몇 번으로 A-1 5문항이 채워지면 fan-out 없이 간다. 하네스 md든 Scene 두엇이든 같다. fan-out은 "어디를 봐야 할지부터 모를 때"의 수단이다.

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

### 3. 사이즈 판정

탐색 결과로 이슈 사이즈를 판정한다 — **위에서부터 첫 "예"** (#1042 설계 세부 §2):

1. 캠페인 둘 이상이 한 목적을 공유 → **XL**
2. 독립 PR 둘 이상 + 앞 PR 결과가 뒤 PR 인터페이스·결정을 바꾸거나 중간에 외부 게이트(심사·실측·머지) → **L**
3. PR 하나지만 작전명령 생략 조건(A-3) 중 하나라도 어긋남 → **M** — 미정 결정 목록에 "유저만 답 가능" 항목이 남아 있으면 그 자체로 M 이다 (S 는 확정 자리가 없다)
4. 진행 중 작전명령 범위 안의 조정 → **단편명령** — 킥오프 대상이 아니다, opord 부록 D 로
5. 아니면 → **S**

**승격만 허용** — 실행 중 조건이 깨지면 멈추고 한 단계 위로. **판정이 모호하면 유저에게 반문한다** — 단정하지 말고 묻는다.

**진행 중 작업으로 복귀한 것이면 판정을 건너뛴다.** 기준은 §0과 같다 — **이번에 착수하려는 그 작업 단위**에 이미 브랜치·커밋·PR이 있어 이어서 하는 경우다. 사이즈가 이미 정해져 있으니 남은 작업이 무엇인지만 확인해 한 줄로 선언하고 해당 스킬(implement·commit·pr 등)로 바로 전이한다 — §0 보드 이동도 A-1~A-4도 돌지 않는다. 상위 캠페인에 앞선 DP 가 끝나 있어도 **새 DP 착수는 복귀가 아니다** — 그 DP 이슈로 킥오프를 다시 탄다.

**유저가 구체화를 요구해도 킥오프에서 확정 라운드를 열지 않는다.** "스펙이 구체적이지 않으니 구체화 먼저" 같은 요청은 계획 스킬의 질문 단계가 받을 일이다 — 판정을 마치고 opord·campaign 으로 넘어가 거기서 확정한다. 킥오프가 되묻는 건 판정 자체가 정보 부족으로 막혔을 때뿐이고, 그때도 판정에 필요한 만큼만 묻는다.

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

> 사이즈 M — 더 분해할 것 없음. 남은 절차: 정찰 브리프 코멘트 → 작전명령 작성(opord — 미정 확정은 그 질문 단계에서) → 이슈 본문 미러

> 사이즈 S — 작전명령 생략 조건 충족(미정 잔여 없음). 남은 절차: 정찰 브리프 + 구두지시 코멘트로 종료

> 사이즈 L(또는 XL) — PR 여러 개. 남은 절차: campaign 스킬(작전계획)로 위임

---

## M·S — 구현 단위

### A-1. 정찰 브리프 5문항

브리프는 다음 5문항에 답한다 — **1~4는 정찰로 채우는 사실이고, 5는 확정하지 않고 목록화만 한다**:

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

5번 규칙:

- **코드·관례로 확정되는 항목은 근거와 함께 확정해 적는다** — 이건 결정이 아니라 정찰 사실이다. 단 **"코드로 확정"은 그 코드가 그 결정을 위해 존재할 때만 성립한다.** 다른 목적의 값이 우연히 그 결정과 상관관계를 갖는 건 근거가 아니라 "유저만 답 가능"이다 — 목적이 다르면 그 값이 바뀌는 조건도 달라서, 지금 일치하는 건 우연이다.
- **"유저만 답 가능" 항목은 킥오프에서 묻지 않는다.** 목록에 남겨 계획 스킬로 넘긴다 — M 은 opord 질문 단계(opord §3-5), L·XL 은 campaign 작전구상 질문(campaign §2-2)이 받는다. 여기서 반문 라운드를 돌리는 건 계획 단계의 결정 여지를 선점하는 월권이다.
- **목록 등재 기준 = 구현 분기 테스트**: 한 항목을 두 가지로 해석했을 때 서로 다른 diff가 나오면 등재. 해석이 달라도 같은 코드가 나오면 등재하지 않는다.
- **해석 범위 상한 — 결정거리는 유저·이슈가 요구한 범위 안에서만 찾는다.** 요구에 없는 확장(재사용 컴포넌트화·일반화·미래 대비)을 상정해 생긴 분기는 목록 대상이 아니라 스코프 밖이다 — 2번 스코프 경계의 "안 건드릴 것"에 적는다.

### A-2. 정찰 브리프 기록

A-1 5문항이 채워지면 이슈 코멘트로 남긴다 (`gh issue comment <N> --body-file <file>`):

```markdown
<!-- kickoff -->
## Kickoff 정찰 브리프

**완료 기준**: <관찰 가능한 동작 변화>
**스코프**: <건드릴 것 / 안 건드릴 것>
**현재 동작**: <file:line 근거 요약>
**미정 결정 목록**: <항목별 한 줄 — 코드·관례 확정은 결론+근거, 유저만 답 가능은 질문 요지 (확정은 opord·campaign 몫)>
**참고**: <관련 PR#, docs/spec 문서>
```

간결하게 — 읽는 사람이 한 번에 이해하는 데 필요한 최소량이 상한. 타 레포 이슈·PR 레퍼런스는 `owner/repo#N` 풀 형식으로 쓴다 (bare `#N`은 이 레포로 링크됨). 코멘트 게시 전 내용을 유저에게 먼저 보여주고 확인받는다 — 보여주기는 **응답 본문에 전문을 직접 싣는 것**이다. 파일에 쓰고 툴 출력(cat)으로 내보내면 유저에게 안 보인다. 단 유저가 즉시 진행을 지시했으면(예: "바로 커밋해", "그냥 진행해") 확인 없이 게시한다 — 확인은 유저 시간을 아끼는 장치지 그 자체가 목적이 아니다.

**코멘트 상한** — kickoff이 이슈에 남기는 코멘트는 이 A-2 브리프뿐이다(§1 마커 1종과 같다). 작전명령은 kickoff 이 남기는 코멘트가 아니다(A-4) — 본문 핵심 미러도 재가 원문 코멘트도 opord §7 소관이라 이 상한 밖이다. A-3 생략 경로의 구두지시는 A-2 브리프에 붙는 것이 기본이고, A-2도 생략돼 단독 코멘트가 될 때만 이 상한의 예외다. 진행 상황·검증 인계·브리프 보완을 코멘트로 쌓지 않는다 — 그건 PR 본문 자리다.

**전제 붕괴 종료** — 정찰·브리프 확인 과정에서 이슈의 전제가 무너지면(요구가 이미 해소됨·성립하지 않음·유저가 안 하기로 결정) 브리프도 플랜도 만들지 않는다. 무너진 전제와 근거를 유저에게 보여주고 확인받은 뒤 이슈를 닫고(`gh issue close --comment`) 킥오프를 종료한다. 이 종료 코멘트는 위 코멘트 상한의 예외다 — 브리프 자리가 없어진 경로라 사유를 남길 데가 여기뿐이다.

- 닫은 뒤 `project-board.sh <이슈번호> "Archive"`로 보드를 되돌린다. §0이 옮긴 `In Progress`의 철회지 진척 이동이 아니다(진척 이동은 pr 스킬 규정대로 유저 소관). 안 되돌리면 닫힌 이슈가 보드에 `In Progress`로 남는다
- 같은 이유로 상황판 씨앗도 거둔다 — `rm -rf .operations/<이슈번호> ~/.claude/campaign-board/state/<이슈번호>` 뒤 `.claude/scripts/campaign-board-sync.sh <이슈번호>` 로 재렌더 — 원본이 사라졌으니 `원본이 이 워크트리에 하나도 없다` 경고가 뜨는데 이 경로에선 정상이고 실패가 아니다(재렌더는 된다). 안 거두면 닫힌 이슈가 `정찰` 상태로 상황판에 영구히 남는다
- 전제가 정말 무너졌는지 모호하면 닫지 말고 반문한다 — 이슈를 닫는 건 다른 판정 지점보다 정정 비용이 크다

**생략 조건** — 브리프 내용이 이미 이슈에 적혀 있어 재서술이 되면 게시하지 않는다. 둘 중 하나면 해당한다:

- 이슈 본문이 완료 기준·스코프·현재 동작을 담고 있고, 미정 결정 목록이 비어 있다
- 브리프 내용을 **새 이슈 본문에 실어** 그 이슈가 이번 작업 대상이 됐다 — 내용 **전체**가 그 본문에 들어갔을 때만이다. 일부만 옮겼으면 나머지는 원 이슈에 브리프로 남긴다

그 외엔 필수 — 정찰 사실과 미정 목록은 계획 스킬(opord·campaign)의 입력이라, 안 남기면 다음 세션이 정찰을 다시 돈다. 확정된 결정의 기록처는 여기가 아니라 opord.md·campaign.md(이슈 본문 미러)다.

### A-3. 작전명령 작성으로 전환

프로젝트 `opord` 스킬을 invoke해 작전명령을 작성한다 (`opord`는 superpowers writing-plans 를 대체하는 이 프로젝트의 플랜이다 — 템플릿 `docs/operations/templates/opord.md`). 정찰 브리프(미정 결정 목록 포함)가 그 입력이고, "유저만 답 가능" 미정의 확정은 opord 질문 단계(§3-5)가 맡는다. kickoff 안에서 계획 방법론을 중복 구현하지 않는다.

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

**작전명령 생략(S)** — 아래 다섯 조건을 **모두** 만족하면(§3 의 S 판정 기준) 작전명령 없이 정찰 브리프를 직접 실행한다:

1. 이슈 본문이 이미 실행 항목 수준으로 확정돼 작전명령이 재서술에 그친다
2. 단일 관심사 — 결정거리가 하나로 수렴한다. 여러 모듈·레이어에 걸치면 그 자체로 결정거리 복수로 본다 (레이어 경계는 작전명령에서 짚을 자리다). 단 동일 패턴의 기계적 치환은 예외 — 파일 수도 레이어 수도 따지지 않는다
3. TDD 사이클 0~1회 (문서·설정·리소스 변경 포함)
4. 서브에이전트 dispatch·병렬 실행 없음
5. 미정 결정 목록에 "유저만 답 가능" 항목이 없다 — 하나라도 남으면 확정 자리(opord 질문 단계)가 필요하므로 S 가 될 수 없다

하나라도 어긋나면 opord 스킬로 간다. 생략할 땐 구두지시(`docs/operations/templates/verbal-order.md` — 상황/임무/의도/분담과 자율/검증 5문장) 코멘트로 A-4를 갈음한다 — A-2를 게시하면 그 브리프 끝에 붙이고, A-2도 생략 조건에 해당하면 단독 코멘트로 남긴다. 판단 근거는 사이즈 판정 선언에 한 줄로 밝힌다.

### A-4. 작전명령을 이슈에 기록

작전명령이 재가되면 opord 스킬이 이슈 **본문**에 미러한다(`gh issue edit --body-file`) — 요약 코멘트는 없다.

---

## L·XL — campaign 위임

분해·계획은 campaign 스킬이 맡는다 — 분해 게이트·분해 브리프(`<!-- kickoff-breakdown -->`)는 폐지됐고, 작전계획 campaign.md 의 9항 DP 목록이 리스트업을, 미결 목록이 "미분해 잔여"를 갈음한다 (#1042 결정 5).

- 이 스킬의 몫은 정찰(§2)과 사이즈 판정 선언까지다. 선언 후 campaign 스킬을 invoke 한다 — kickoff 안에서 분해 방법론을 중복 구현하지 않는다.
- **DP 착수는 그 DP 이슈 단위로 킥오프 재진입** — DP = 이슈 = PR 필수라 이슈 없이 상위 이슈에 커밋을 쌓는 경로는 없다. DP 이슈 본문의 `상위 이슈: #N / DP-<x.y>` 좌표(issue 스킬)로 작전계획 맥락이 이어지고, 하위도 사이즈 판정부터 다시 탄다 (승격만 허용).
- 여러 DP 를 같은 세션이 이어서 실행할 땐 orchestrate 스킬 — campaign.md DP 목록·원장이 그 입력이다.