to-PRD + to-Issues: グリルからの会話を実行可能な垂直スライスに凝縮します。

Matt Pocock のワークフローの中間部分 - /to-prd は会話を PRD に変換し、/to-issues は PRD を垂直方向にスライスされた問題に分割し、個別に収集できます。 AI 時代における「曳光弾」と「垂直スライス」という 2 つの古い概念の新しい役割の詳細な解釈

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

Matt Pocockto-issues SKILL.md

移動

ワークフロー内のこのセクションの位置

Matt のワークフロー図に戻ります。

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

/to-prd と /to-issues は、抽象的な対話による決定** を実行可能な作業単位** に変換するという、前と次の間のリンクです。マットの実際の使用では、これらは 2 つの連続したステップであるため、これらを組み合わせます。

失敗モード: グリルした後は何もしない

多くの人が /grill-me を使用した後に行き詰まってしまいます。多くの決定事項を伴う長い会話になりますが、コードの作成をどのように開始すればよいのでしょうか?

クロードに直接「やってください」と言うのは間違いです。理由は次のとおりです。

完全な機能を一度に実装 = AI 出力 1000 行以上 = レビューが難しく、テストが難しく、バグを見つけるのが難しい
AI が記憶を失うと、次のセッションにはコンテキストがなくなります。
追跡がない - どこに到達したか、どれだけ残っているかを知る方法がありません

正しいアプローチは、決定を成果物 (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."

もう質問しないでください。これは、grill-me ステージが行うことです。to-prd は合成のみを行います。したがって、コンテキストをクリアせずに to-prd を実行してください*。前のグリルからのすべてのダイアログに依存します。

スキル処理の流れ

コードベースを探索します (まだ探索していない場合) - プロジェクトの CONTEXT.md ボキャブラリーを使用し、既存の ADR を尊重します
ドラフトモジュール——インターフェイスを独立してテストできるように、深いモジュールとして抽出できる機会を積極的に探します。
モジュールをユーザーと調整する - 「これらのモジュールは正しいですか?どれをテストする必要がありますか?」
テンプレートに従って 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 の方法論全体の中で最も重要な概念の 1 つです。 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: 「管理者はコメントを削除できる」

水平スライスの問題: 各スライスを個別にテストすることができません。問題 1 が完了した後は、実証するものが何もなく、リンク全体を実行できるようになったのは問題 4 でした。そのときになって初めて、スキーマ設計が間違っていたことがわかりました。

完成した各垂直スライスは、エンドツーエンドで利用可能な機能サブセットであり、プラグマティックプログラマーの言葉では トレーサーブレット (トレーサーブレット) と呼ばれます。最初に 1 ラウンドを撃って照準を確認し、次のラウンドを調整します。

HITL vs AFK

/to-issues は各スライスにもラベルを付けます。

HITL (Human in the Loop) - 人々が意思決定に参加することが求められます。アーキテクチャ上の決定、設計レビューなど
AFK (キーボードから離れた状態) - エージェントは独立して作業を完了でき、あなたは結果を確認するために戻ってくることができます。

「可能な限り 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")

「エンドツーエンドの動作を説明する」という行に注目してください。これは垂直スライスの精神と一致しています。合格基準は合格リストであり、クロードはこれを /tdd 段階で 1 つずつテストに変換します。

使用方法: 完全なプロセスの例

自分のブログにコメント機能を追加したいとします。完全なプロセス:

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

プロセス全体で、画面の前に座って細部まで監視する必要はありません。重要な決定はグリルミーの段階で行われます。

インストールと前提条件

npx skills@latest add mattpocock/skills

to-prd、to-issues、setup-matt-pocock-skills を確認してください。

最初に /setup-matt-pocock-skills を実行する必要があります。これにより、問題トラッカー (GitHub / GitLab / ローカルマークダウン) とトリアージラベルの語彙が AGENTS.md/CLAUDE.md に書き込まれます。そうしないと、to-prd および to-issue は問題の送信先を認識できなくなります。

サポートされている問題トラッカー:

GitHub の問題 (デフォルト、gh CLI を使用)
GitLab の問題 (glab CLI を使用)
ローカルマークダウン (.scratch/<feature>/ の下にファイルを作成) - 個人プロジェクトまたはリモートのないプロジェクトに適しています
その他 (Jira、Linear など) - 散文を使用してワークフローを説明すると、その説明に従ってスキルが呼び出されます。

よくある質問

**Q: 既製の PRD はすでに存在します。 to-prd をスキップして to-issue に直接移動できますか? ** A: はい。 /to-issues は、問題の参照をパラメーターとして受け入れ (「問題 #42 を垂直方向のスライスに分割する」)、問題のコンテンツをフェッチしてスライスします。

**Q: 私のプロジェクトでは課題トラッカーを使用していませんが、使用できますか? ** A: はい。セットアップ中に「ローカルマークダウン」を選択すると、すべての課題が .scratch/<feature>/001-foo.md のようなローカルファイルになります。

**Q: PRD が長すぎて AI 自体が処理できない場合はどうすればよいですか? ** A: これはスライスの粒度の兆候です。PRD は 1 つの巨大な PRD ではなく、複数の独立した PRD にスライスされる必要があります。グリルの段階でそれを感じるはずです。50 号について話しており、まだ新しい機能を導入している場合は、まず停止して 2 つの PRD に分割し、バッチで実行してください。

**Q: AFK エージェントはどのようにして問題を自動的に検出しますか? ** A: Matt のリポジトリにはこの部分が提供されていないため、独自のエージェントの手配と調整する必要があります (たとえば、GitHub Actions が Claude Code をトリガーして問題を実行します)。最も簡単な方法は、cron を実行して is:open no:assignee label:agent-ready を 1 時間ごとにチェックすることです。

このプロセスの真価

/to-prd と /to-issues は「自動プロジェクト管理」のように見えますが、Matt がワークフローの中心に置いているのには、より深い理由があります。

「完全に小さなこととは何か」を考えざるを得ません。機能を垂直方向のスライスに切り分けなければならないとき、ソフトウェアエンジニアリングで最も難しい作業の 1 つである継ぎ目を見つけることになります。思考そのものは、これら 2 つのスキルよりも価値があります。

そして、垂直スライスのサイズはAIが一度に処理できるサイズです。 タスクのサイズを AI の能力の上限に合わせます - これが LLM とのコラボレーションの基本的なリズムです。

参考リソース

to-prd/SKILL.md

The full PRD template and synthesis instructions.

Matt PocockGitHub2026

移動

to-issues/SKILL.md

Vertical slice rules, HITL/AFK distinction, full issue template.

Matt PocockGitHub2026

移動

Real-world feature build with Claude Code: every step explained

Matt's full walkthrough of grill → PRD → issues → TDD on a real feature.

Matt Pocockaihero.dev2026

移動

次の記事: TDD: 赤と緑の再構築を使用して AI にスモールステップを実行させる——問題を切り取った後、実際に AI にスモールステップを実行させるにはどうすればよいでしょうか?

to-PRD + to-Issues: グリルからの会話を実行可能な垂直スライスに凝縮します。

to-prd/SKILL.md

to-issues/SKILL.md

Real-world feature build with Claude Code: every step explained

コメント

目次