to-PRD + to-Issues: 그릴의 대화를 실행 가능한 수직 조각으로 압축합니다.

워크플로에서 이 섹션의 위치

Matt의 작업 흐름 다이어그램으로 돌아가서:

/grill-me 或 /grill-with-docs   ← 谈清楚
        ↓
   /to-prd                       ← 凝固成 PRD（你在这里）
        ↓
   /to-issues                    ← 切成可领取的 vertical slice（你在这里）
        ↓
   /tdd                          ← 一个 slice 一个 slice 跑红绿
        ↓
   /improve-codebase-architecture

/to-prd 및 /to-issues은 이전과 다음 사이의 링크입니다: 추상적인 대화 결정을 실행 가능한 작업 단위로 변환합니다. Matt의 실제 사용에서는 두 단계가 연속되어 있기 때문에 두 단계를 결합했습니다.

실패모드 : 굽고 난 뒤 아무것도 할 수 없음

많은 사람들이 /grill-me을 사용한 후 막히게 됩니다. 많은 결정을 내리기 위해 긴 대화를 나누지만 코드 작성을 시작하는 방법은 무엇입니까?

Claude에게 직접적으로 "해 주세요"라고 말하는 것은 잘못된 것입니다. 이유는 다음과 같습니다.

1. 한 번에 완전한 기능 구현 = AI 출력 1000개 이상의 라인 = 검토 어려움, 테스트 어려움, 버그 찾기 어려움
2. AI가 메모리를 잃으면 다음 세션에는 컨텍스트가 없습니다.
3. 추적 불가 - 우리가 어디에 도달했고 얼마나 남았는지 알 수 없습니다.

올바른 접근 방식은 결정을 아티팩트(PRD)로 동결한 다음 PRD를 독립적으로 완료할 수 있을 만큼 작은 작업 패키지(문제)로 자르는 것입니다. 이는 30년 동안 소프트웨어 공학에서는 상식이었지만 AI 시대에는 새로운 의미를 갖습니다.

AFK 에이전트(당신이 없을 때 실행되는 에이전트)가 독립적으로 픽업하여 완료할 수 있도록 잘게 자릅니다.

/to-prd: 대화를 PRD로 압축합니다.

기술의 주요 제약

/to-prd의 SKILL.md는 시작 부분에 매우 중요한 문장을 씁니다.

"This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know."

더 이상 질문하지 마세요. 그릴미 스테이지는 이런데, to-prd는 합성만 합니다. 따라서 컨텍스트를 지우지 말고 to-prd로 실행하세요. 이는 이전 그릴의 모든 대화에 의존합니다.

스킬 처리 흐름

1. 코드 베이스 탐색(아직 탐색하지 않은 경우) - 프로젝트의 CONTEXT.md 어휘를 사용하고 기존 ADR을 존중합니다.
2. 초안 모듈——인터페이스를 독립적으로 테스트할 수 있도록 심층 모듈로 추출할 수 있는 기회를 사전에 찾습니다.
3. 사용자에 맞게 모듈 정렬 - "이 모듈이 맞습니까? 어떤 모듈을 테스트해야 합니까?"
4. 템플릿에 따라 PRD를 생성하여 이슈 트래커로 보내고 needs-triage 태그를 지정합니다.

PRD 템플릿

Matt가 제공한 템플릿은 다음과 같습니다.

## Problem Statement
The problem that the user is facing, from the user's perspective.

## Solution
The solution to the problem, from the user's perspective.

## User Stories
A LONG, numbered list:
1. As a <actor>, I want a <feature>, so that <benefit>
2. ...

## Implementation Decisions
- The modules that will be built/modified
- The interfaces of those modules
- Technical clarifications from the developer
- Architectural decisions
- Schema changes / API contracts / Specific interactions

(NO specific file paths or code snippets — they rot fast.)

## Testing Decisions
- What makes a good test (test external behavior, not internals)
- Which modules will be tested
- Prior art (similar tests in the codebase)

## Out of Scope
What's NOT in this PRD.

## Further Notes

몇 가지 주요 디자인:

• 사용자 스토리가 대부분을 차지함: 요구 사항이 길고 번호가 매겨진 목록 - 전체 기능 포인트를 철저하게 열거해야 합니다. 이로써 '분명한 줄 알았는데'라는 사각지대를 피할 수 있게 됐다.
• 구현 시 파일 경로나 코드를 작성하지 않습니다: Matt는 "매우 빨리 구식이 될 수 있습니다"라고 직접 말했습니다. 이는 LLM 시대의 고유한 고려 사항입니다. 특정 경로는 재구성 직후 쓸모 없게 되지만 "모듈 경계" 및 "인터페이스 계약"은 수명 주기가 더 깁니다.
• 범위를 벗어나야 함: 이 단락은 대부분의 PRD 템플릿에서 무시되지만 나중에 문제를 잘라낼 때 경계 보험이 됩니다.

/to-issues: PRD를 수직 조각으로 자릅니다.

수직 슬라이스란 무엇입니까?

이는 Matt의 전체 방법론에서 가장 중요한 개념 중 하나입니다. SKILL.md는 직접적으로 다음과 같이 말했습니다.

Each issue is a thin vertical slice cutting through ALL integration layers end-to-end, NOT a horizontal slice of one layer.

가장 명확한 예는 "주석 기능"을 만드는 것입니다.

수평 슬라이싱(잘못된 방향):

• 문제 1: 데이터베이스 스키마
• 문제 2: API 엔드포인트
• 이슈 3: UI 컴포넌트
• 문제 4: 테스트

세로 절단(Tracer Bullet 방법):

• 이슈 1: "방문자가 익명으로 댓글을 제출할 수 있습니다" (스키마 + API + UI + 테스트가 모두 포함되지만 범위가 작아서 익명만 가능함)
• 문제 2: "로그인한 사용자의 댓글이 해당 계정과 연결되어 있습니다."
• 이슈 3: "댓글에 답글을 달 수 있습니다"
• 문제 4: "관리자는 댓글을 삭제할 수 있습니다."

수평 슬라이싱의 문제점: 각 슬라이스를 개별적으로 테스트할 수 없습니다. Issue 1이 완성된 후에는 시연할 내용이 없었고, Issue 4가 되어서야 전체 링크를 실행할 수 있었습니다. 그때서야 ​​스키마 설계가 잘못되었음을 발견했습니다.

완성된 각 수직 슬라이스는 종단 간 사용 가능한 기능적 하위 집합입니다. Pragmatic Programmer의 표현으로는 추적 총알(추적 총알)이라고 합니다. 먼저 한 발을 쏘아 십자선을 확인한 후 다음 발을 조정하세요.

HITL vs AFK

/to-issues은 또한 각 조각에 레이블을 지정합니다.

• HITL(Human in the Loop) - 사람들이 의사 결정에 참여해야 합니다. 건축 결정, 디자인 검토 등
• AFK (Away From Keyboard)——에이전트가 독립적으로 작업을 완료할 수 있으며, 다시 돌아와서 결과를 확인할 수 있습니다.

"가능한 경우 HITL보다 AFK를 선호합니다."

이는 Matt의 작업 흐름에서 매우 획기적인 아이디어입니다. 문제 편집을 마친 후 사용자가 부재 중일 때(예: 밤이나 주말) 실행되는 에이전트에 직접 문제를 보냅니다. 다음 날 다시 돌아오면 PR이 이미 거기 누워서 검토를 기다리고 있습니다. HITL 부분은 낮 동안 머물면서 에이전트와 협력합니다.

슬라이싱 확인 링크

/to-issues은 문제가 발생하는 즉시 문제를 생성하지 않습니다. 먼저 타일링 구성표를 번호가 매겨진 목록으로 표시합니다.

1. Title: 访客提交匿名评论
   Type: AFK
   Blocked by: None
   User stories covered: #1, #2

2. Title: 评论关联到登录账户
   Type: AFK
   Blocked by: #1
   User stories covered: #3

3. Title: 评论审核流程
   Type: HITL（需要确认审核 UI 设计）
   Blocked by: #1
   User stories covered: #4, #5

그런 다음 다음과 같이 질문하십시오.

• 세분성이 정확한가? 너무 두껍다 / 너무 얇다?
• 종속성이 올바른가요?
• 어떤 것을 병합/분할해야 하나요?
• HITL/AFK 표시가 정확합니까?

실제로 문제 추적기에 보내기 전에 종속성 순서(차단기 우선)로 고개를 끄덕일 때까지 반복하여 이후 문제가 첫 번째 문제의 실제 문제 ID를 참조할 수 있도록 합니다.

이슈 템플릿

## Parent
A reference to the parent issue (if any).

## What to build
A concise description. Describe end-to-end behavior, NOT layer-by-layer
implementation.

## Acceptance criteria
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Blocked by
- A reference to the blocking ticket
(or "None - can start immediately")

수직 슬라이스의 정신과 일치하는 "종단 간 동작 설명" 줄을 참고하세요. 승인 기준은 Claude가 /tdd 단계에서 하나씩 테스트로 변환하는 승인 목록입니다.

사용방법: 전체 프로세스 예시

블로그에 댓글 기능을 추가하고 싶다고 가정해 보겠습니다. 전체 프로세스:

你: 我想给博客加评论功能
    ↓
/grill-me  →  Claude 问 30 个问题（要不要登录？匿名？嵌套？审核？……）
    ↓
你回答完毕，达成共识
    ↓
/to-prd    →  Claude 生成结构化 PRD，提交到 GitHub Issues #42
    ↓
/to-issues  →  Claude 提议切成 4 个 vertical slice
                  让你确认粒度和依赖
                  你点头
                  按依赖顺序发布到 GitHub Issues #43~#46
    ↓
你回家睡觉
    ↓
夜里 AFK agent 抓 #43（无依赖），跑 /tdd 完成 → 提 PR
你早上 review、merge
    ↓
agent 抓 #44 / #45 ……

전체 과정에서 화면 앞에 앉아 모든 세부 사항을 볼 필요가 없습니다. 핵심 결정은 그릴미(grill-me) 단계에서 내려집니다.

설치 및 전제조건

npx skills@latest add mattpocock/skills

to-prd, to-issues, setup-matt-pocock-skills을 확인하세요.

**먼저 /setup-matt-pocock-skills**을 실행해야 합니다. 문제 추적기(GitHub / GitLab / local markdown)와 분류 레이블 어휘를 AGENTS.md/CLAUDE.md에 작성합니다. 그렇지 않으면 to-prd 및 to-issue는 문제를 보낼 위치를 알 수 없습니다.

지원되는 문제 추적기:

• GitHub 문제(기본값, gh CLI 사용)
• GitLab 문제(glab CLI 사용)
• 로컬 마크다운(.scratch/<feature>/ 아래에 파일 생성) - 개인 프로젝트 또는 원격이 없는 프로젝트에 적합
• 기타(Jira, Linear 등) - 산문을 사용하여 워크플로를 설명하면 설명에 따라 스킬이 호출됩니다.

FAQ

**Q: 이미 완성된 PRD가 있습니다. to-prd를 건너뛰고 to-issue로 바로 이동할 수 있나요? ** 답: 그렇습니다. /to-issues은 이슈 참조를 매개 변수("문제 #42를 수직 조각으로 나누기")로 받아들이고 이슈 콘텐츠를 가져온 다음 조각화합니다.

**Q: 내 프로젝트에서는 이슈 트래커를 사용하지 않습니다. 사용할 수 있나요? ** 답: 그렇습니다. 설정 중에 "로컬 마크다운"을 선택하면 모든 이슈가 .scratch/<feature>/001-foo.md과 같은 로컬 파일이 됩니다.

**Q: PRD가 너무 길어서 AI 자체가 처리할 수 없는 경우 어떻게 해야 하나요? ** A: 이는 슬라이스 세분화의 표시입니다. PRD는 하나의 거대한 PRD가 아닌 여러 개의 독립적인 PRD로 슬라이스되어야 합니다. 그릴 단계에서 느껴야 합니다. 50번째 이슈에 대해 이야기하고 여전히 새로운 기능을 도입하는 중이라면 먼저 멈추고 PRD를 두 개로 나누어 일괄적으로 수행하세요.

**Q: AFK 에이전트는 어떻게 자동으로 문제를 포착합니까? ** A: Matt의 저장소는 이 부분을 제공하지 않으며 자체 에이전트 배열과 조정되어야 합니다(예를 들어 GitHub Actions는 문제를 실행하기 위해 Claude Code를 트리거합니다). 가장 쉬운 방법은 cron을 사용하여 매시간 is:open no:assignee label:agent-ready을 확인하는 것입니다.

이 과정의 진정한 가치

/to-prd 및 /to-issues은 "자동화된 프로젝트 관리"처럼 보이지만 Matt는 더 깊은 이유 때문에 이를 자신의 작업 흐름의 중심에 두었습니다.

**"완전히 작은 것이 무엇인가"**라고 생각하게 만듭니다. 기능을 수직 조각으로 잘라야 한다면 소프트웨어 엔지니어링에서 가장 어려운 일 중 하나인 이음새를 찾는 것입니다. 이 두 가지 기술보다 생각 자체가 더 가치가 있습니다.

그리고 수직 슬라이스의 크기는 AI가 한번에 처리할 수 있는 크기입니다. 작업 크기를 AI 능력의 상한과 일치시키세요 - 이것이 LLM과의 협업의 기본 리듬입니다.

참조 리소스

다음 기사: TDD: 빨간색과 녹색 재구성을 사용하여 AI가 작은 단계를 거치도록 강제——문제가 해결된 후 AI가 실제로 작은 단계를 실현하도록 만드는 방법.