to-PRD + to-Issues: Condensate the conversation from the grill into an executable vertical slice

The position of this section in the workflow

Back to Matt’s workflow diagram:

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

/to-prd and /to-issues are a link between the previous and the following: translating abstract dialogue decisions** into executable work units**. I combine them because in Matt's actual use they are two consecutive steps.

Failure mode: Nothing to do after grilling

Many people get stuck after using /grill-me: they get a long conversation with a bunch of decisions, but how to start writing code?

Giving Claude a "please do it" directly is wrong - because:

1. Implementing complete functions at one time = AI output 1000+ lines = difficult to review, difficult to test, difficult to locate bugs
2. After AI loses its memory, the next session has no context.
3. No tracking - no way to know where we have reached and how much is left

The correct approach is to freeze the decision into an artifact (PRD), and then cut the PRD into work packages (issues) that are small enough to be completed independently. This has been common knowledge in software engineering for 30 years, but it takes on new meaning in the AI era:

Chop it finely enough so that the AFK agent (the agent that runs when you are not present) can pick up and complete it independently.

/to-prd: compress the conversation into PRD

Key Constraints of Skill

/to-prd's SKILL.md writes a very important sentence at the beginning:

"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."

Ask no more questions. This is what the grill-me stage does, to-prd only does synthesis. So don't clear the context and run to-prd - it relies on all the dialogue from the previous grill.

Skill processing flow

1. Explore the code base (if you haven’t explored it yet) - use the project’s CONTEXT.md vocabulary and respect existing ADRs
2. Draft module——Proactively look for opportunities that can be extracted as deep modules so that the interface can be independently tested
3. Align modules with users - "Are these modules correct? Which ones need to be tested?"
4. Generate PRD according to the template, send it to issue tracker, and tag it with needs-triage

PRD Template

The template given by Matt is as follows:

## 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

Several key designs:

• User Stories account for the majority: Requirements LONG, numbered list - forcing you to exhaustively enumerate complete function points. This avoids the blind spot of "I thought it was clear"
• Implementation does not write file paths or code: Matt directly said "they may end up being outdated very quickly". This is a unique consideration in the LLM era - the specific path will become obsolete immediately after reconstruction, but the "module boundary" and "interface contract" have a longer life cycle
• Must have Out of Scope: This paragraph is ignored in most PRD templates, but it is the boundary insurance when cutting issues later.

/to-issues: Cut PRD into vertical slices

What is Vertical Slice?

This is one of the most important concepts in Matt’s entire methodology. SKILL.md said directly:

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

The clearest example is to create a “comment function”.

Horizontal slicing (wrong way):

• Issue 1: Database schema
• Issue 2: API endpoints
• Issue 3: UI components
• Issue 4: Testing

Longitudinal slicing (Tracer Bullet method):

• Issue 1: "Visitors can submit an anonymous comment" (schema + API + UI + test are all included, but the scope is so small that it can only be anonymous)
• Issue 2: "Comments from logged in users are associated with the account"
• Issue 3: "Comments can be replied to"
• Issue 4: "Administrators can delete comments"

The problem with horizontal slicing: each slice cannot be tested individually. After Issue 1 was completed, there was nothing to demonstrate, and it was not until Issue 4 that the entire link could be run through—it was only then that I discovered that the schema design was wrong.

Each completed vertical slice is a end-to-end available functional subset - called a tracer bullet (tracer bullet) in the words of the Pragmatic Programmer. Shoot one round first to check the crosshair, and then adjust the next round.

HITL vs AFK

/to-issues also labels each slice:

• HITL (Human in the Loop) - requires people to participate in decision-making. Such as architectural decisions, design reviews
• AFK (Away From Keyboard)——The agent can complete the work independently, and you can come back to see the results.

"Prefer AFK over HITL where possible."

This is a very radical idea in Matt's workflow: after you finish cutting the issue, you send it directly to an agent that runs when you are not present (such as at night or on weekends). When you come back the next day, the PR is already lying there waiting for review. The HITL part stays during the day and works with the agent.

Slicing confirmation link

/to-issues will not generate an issue as soon as it comes up - it will first show you the tiling scheme as a numbered list:

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

Then ask you:

• Is the granularity correct? Too thick / too thin?
• Are the dependencies correct?
• Which ones should be merged/split?
• Are the HITL/AFK marks correct?

Iterate until you nod before actually sending it to the issue tracker, in order of dependency (blocker first), so that later issues can reference the real issue ID of the first issue.

Issue Template

## 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")

Note the "describe end-to-end behavior" line - consistent with the spirit of vertical slice. Acceptance criteria is an acceptance list, which Claude will convert into tests one by one in the /tdd stage.

How to use: Complete process example

Suppose you want to add comment functionality to your blog. Complete process:

你: 我想给博客加评论功能
    ↓
/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 ……

The entire process does not require you to sit in front of the screen and watch every detail. The key decisions are made in the grill-me stage.

Installation and prerequisites

npx skills@latest add mattpocock/skills

Check to-prd, to-issues, setup-matt-pocock-skills.

You must run /setup-matt-pocock-skills first - it will write your issue tracker (GitHub / GitLab / local markdown) and triage label vocabulary to AGENTS.md/CLAUDE.md, otherwise to-prd and to-issues will not know where to send issues.

Supported issue trackers:

• GitHub Issues (default, uses gh CLI)
• GitLab Issues (using glab CLI)
• Local markdown (create files under .scratch/<feature>/) - suitable for personal projects or projects without remote
• Others (Jira, Linear, etc.) - Use a piece of prose to describe the workflow, and the skill will be called according to your description

FAQ

**Q: There is already a ready-made PRD. Can I skip to-prd and go directly to to-issues? ** A: Yes. /to-issues accepts an issue reference as a parameter ("Break down issue #42 into vertical slices"), and it will fetch the issue content and then slice it.

**Q: My project does not use issue tracker, can it be used? ** A: Yes. Select "Local markdown" during setup, and all issues will become local files like .scratch/<feature>/001-foo.md.

**Q: What should I do if the PRD is too long and the AI itself can’t handle it? ** A: This is a sign of slice granularity - the PRD should be sliced into multiple independent PRDs rather than one giant PRD. You should feel it during the grill stage: If you talk about the 50th issue and are still introducing new features, stop first and cut into two PRDs and do them in batches.

**Q: How does AFK agent automatically catch issues? ** A: Matt's repo does not provide this part, and it must be coordinated with your own agent arrangement (for example, GitHub Actions triggers Claude Code to run issues). The easiest thing to do is to cron to check is:open no:assignee label:agent-ready every hour.

The true value of this process

/to-prd and /to-issues look like "automated project management", but Matt puts them at the heart of his workflow for a deeper reason:

It forces you to think "What is a complete little thing". When you are forced to cut functionality into vertical slices, you are doing one of the hardest things in software engineering - finding seams. The thought itself is more valuable than these two skills.

And the size of the vertical slice is the size that the AI can handle at one time. Let the task size match the upper limit of the AI's capabilities - This is the fundamental rhythm of collaboration with LLM.

Reference resources

Next article: TDD: Use red and green reconstruction to force AI to take small steps——After the issue is cut, how to make AI really realize small steps.