티켓으로 만들기 (To Tickets)
계획, 명세서 또는 대화 내용을 일련의 티켓(tracer-bullet vertical slices)으로 분해합니다. 각 티켓은 자신을 **차단(block)**하는 티켓을 명시합니다.
이슈 트래커와 분류 레이블 용어는 이미 제공되어야 합니다. 제공되지 않았다면 사용자에게 /setup-matt-pocock-skills를 실행하라고 알리세요.
절차
1. 컨텍스트 수집
이미 대화 컨텍스트에 있는 정보를 바탕으로 작업합니다. 사용자가 인수(명세서 경로, 이슈 번호 또는 URL)로 참조를 전달하면, 이를 가져와 본문과 댓글을 모두 읽습니다.
2. 코드베이스 탐색 (선택 사항)
아직 코드베이스를 탐색하지 않았다면, 현재 코드 상태를 이해하기 위해 탐색하세요. 티켓 제목과 설명은 프로젝트의 도메인 용어집을 사용하고, 수정하는 영역의 ADR을 존중해야 합니다.
구현을 더 쉽게 만들기 위해 코드를 사전 리팩터링(prefactor)할 기회를 찾으세요. "변경을 쉽게 만든 후, 쉬운 변경을 하라 (Make the change easy, then make the easy change)."
3. 수직 슬라이스 초안 작성
작업을 트레이서-불렛 티켓으로 분해합니다.
- 각 슬라이드는 모든 계층(스키마, API, UI, 테스트)을 관통하는 좁지만 완전한 경로를 자릅니다: 수직(vertical)적이어야 하며, 한 계층의 수평(horizontal) 슬라이스가 아닙니다.
- 완료된 슬라이스는 그 자체로 데모 가능하거나 검증 가능해야 합니다.
- 각 슬라이스는 하나의 새로운 컨텍스트 창에 들어갈 크기여야 합니다.
- 사전 리팩터링(prefactoring)은 먼저 수행되어야 합니다.
각 티켓에 **차단 관계(blocking edges)**를 부여하세요: 해당 티켓이 시작되기 전에 완료되어야 하는 다른 티켓들입니다. 차단자가 없는 티켓은 즉시 시작할 수 있습니다.
넓은 리팩터링(Wide refactors)은 수직 슬라이스의 예외입니다. 넓은 리팩터링은 하나의 기계적 변경(열 이름 변경, 공유 심볼 재타입)으로 코드베이스 전체에 **파급 효과(blast radius)**가 퍼져, 단일 편집이 수천 개의 호출 사이트를 동시에 깨뜨리고 어떤 수직 슬라이스도 녹색 상태를 유지할 수 없는 경우입니다. 이를 트레이서-불렛에 강제로 집어넣지 말고, 확장-축소(expand-contract) 순서로 구성하세요. 먼저 확장: 아무것도 깨지지 않도록 기존 형식 옆에 새 형식을 추가합니다. 그런 다음 파급 효과(패키지별, 디렉터리별)에 따라 호출 사이트를 배치 단위로 마이그레이션하고, 각 배치는 확장에 의해 차단된 자체 티켓이며, 기존 형식이 여전히 존재하므로 CI가 배치마다 녹색을 유지합니다. 마지막으로 축소: 호출자가 더 이상 없으면 모든 마이그레이션 배치에 의해 차단된 티켓에서 기존 형식을 삭제합니다. 배치조차 단독으로 녹색을 유지할 수 없는 경우, 순서는 유지하지만 통합 브랜치를 공유하도록 하고, 모든 배치가 최종 통합 및 검증 티켓을 차단하도록 합니다. 녹색은 그곳에서만 보장됩니다.
4. 사용자에게 질문하기
제안된 분해 결과를 번호가 매겨진 목록으로 제시합니다. 각 티켓에 대해 다음을 보여줍니다:
- 제목: 짧은 설명적 이름
- 차단 대상: 먼저 완료되어야 하는 다른 티켓 (있는 경우)
- 제공 결과: 이 티켓이 작동하게 하는 종단 간 동작
사용자에게 질문합니다:
- 세분화 수준이 적절한가요? (너무 굵거나 / 너무 가늘거나)
- 차단 관계가 올바른가요? 각 티켓이 진정으로 자신을 게이트(gate)하는 티켓에만 의존하고 있나요?
- 병합하거나 더 분할해야 할 티켓이 있나요?
사용자가 분해 결과를 승인할 때까지 반복합니다.
5. 설정된 트래커에 티켓 게시
승인된 티켓을 게시합니다. 방법은 /setup-matt-pocock-skills가 설정한 트래커에 따라 다릅니다. 티켓 자체는 동일하며, 차단 관계의 형태만 변경됩니다:
- 로컬 파일 →
.scratch/<feature-slug>/issues/<NN>-<slug>.md에 티켓당 하나의 파일을 작성하며,01부터 의존성 순서(차단자가 먼저)로 번호를 매깁니다. 각 파일의 "차단 대상"은 의존하는 번호/제목을 나열합니다. 아래 티켓당 파일 템플릿을 사용하세요: 파일당 하나의 티켓, 절대 단일 결합 파일을 만들지 마세요. - 실제 이슈 트래커 (GitHub, Linear, …) → 각 티켓의 차단 관계가 실제 식별자를 참조할 수 있도록 의존성 순서(차단자가 먼저)로 티켓당 하나의 이슈를 게시합니다. 플랫폼이 기본 차단/하위 이슈 관계를 제공하는 경우 이를 사용하고, 그렇지 않으면 각 티켓의 "차단 대상"을 차단하는 이슈로 설정합니다. 다른 지시가 없는 한
ready-for-agent분류 레이블을 적용하세요. 티켓은 구조상 에이전트가 가져갈 수 있습니다(agent-grabbable).
프론티어(frontier) 작업: 차단자가 모두 완료된 티켓을 작업하세요. 순수한 선형 체인의 경우 위에서 아래로 진행됩니다.
부모 이슈를 닫거나 수정하지 마세요.
: <티켓 제목>
구축할 내용: 이 티켓이 작동하게 하는 종단 간 동작을 사용자 관점에서 설명하며, 계층별 구현 목록이 아닙니다.
차단 대상: 이 티켓을 게이트하는 티켓의 번호/제목, 또는 "없음 (즉시 시작 가능)".
상태: ready-for-agent
- 수락 기준 1
- 수락 기준 2
부모
트래커의 부모 이슈에 대한 참조 (소스가 기존 이슈인 경우, 그렇지 않으면 이 섹션을 생략).
구축할 내용
이 티켓이 작동하게 하는 종단 간 동작을 사용자 관점에서 설명하며, 계층별 구현이 아닙니다.
수락 기준
- 기준 1
- 기준 2
차단 대상
- 각 차단 티켓에 대한 참조, 또는 "없음 (즉시 시작 가능)".
어느 형식이든, 특정 파일 경로나 코드 스니펫은 피하세요: 빠르게 구식이 됩니다. 예외: 프로토타입이 텍스트보다 더 정확하게 결정을 인코딩하는 스니펫(상태 머신, 리듀서, 스키마, 타입 형태)을 생성한 경우, 이를 인라인으로 포함하고 프로토타입에서 비롯되었음을 간략히 언급하세요. 결정이 풍부한 부분으로만 자르고, 작동하는 데모가 아닌 중요한 부분만 남기세요.