to-issues について
to-issuesは、計画を個別に着手できるチケットへ分解するスキルです。エンドツーエンドの縦割りスライスを作り、粒度や依存関係をユーザーと確認してから、承認済みのissueを依存順に登録します。
主な機能
- 01エンドツーエンドの縦割り分割
- 02HITLまたはAFKの分類
- 03粒度と依存関係の確認
- 04承認済みissueの依存順登録
活用シーン
- 01プロジェクト計画の実装可能なissue化
- 02Agentが個別に進めるタスクの準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ polya20/ grill-me --skill to-issuesインストール後、Claude Code で/to-issuesを入力して読み込まれたか確認します。
詳細
To Issues
計画を、垂直スライス(トレーサーバレット)を使って、それぞれ独立して取り組める課題に分割します。
課題トラッカーとトリアージ用ラベルの語彙は、あらかじめ提供されているはずです。提供されていない場合は、/setup-matt-pocock-skills を実行してください。
プロセス
1. コンテキストを集める
会話のコンテキストにすでにある情報をもとに進めます。ユーザーが引数として課題への参照(課題番号、URL、パス)を渡した場合は、課題トラッカーから取得し、本文とコメントをすべて読みます。
2. コードベースを調べる(任意)
まだコードベースを調べていない場合は、コードの現状を把握するために調査します。課題のタイトルと説明には、プロジェクトのドメイン用語集の語彙を使い、対象領域の ADR に従ってください。
3. 垂直スライスを作成する
計画をトレーサーバレットの課題に分割します。各課題は、単一レイヤーの水平スライスではなく、すべての統合レイヤーをエンドツーエンドで貫く薄い垂直スライスです。
スライスには「HITL」と「AFK」があります。HITL スライスでは、アーキテクチャ上の判断やデザインレビューなど、人間の作業が必要です。AFK スライスは、人間の作業なしで実装してマージできます。可能であれば、HITL より AFK を優先してください。
- 各スライスは、すべてのレイヤー(スキーマ、API、UI、テスト)を通じた、範囲は狭くても完全な経路を提供します - 完了したスライスは、それだけでデモまたは検証ができます - 少数の厚いスライスより、多数の薄いスライスを優先します4. ユーザーに確認する
提案する分割案を番号付きリストで提示します。各スライスについて、以下を示してください。
- タイトル:短く、内容がわかる名前
- タイプ:HITL / AFK
- ブロック要因:先に完了する必要がある他のスライス(あれば)
- 対象となるユーザーストーリー:このスライスが対応するユーザーストーリー(元の資料にある場合)
ユーザーに以下を尋ねてください。
- 粒度は適切ですか?(粗すぎる / 細かすぎる)
- 依存関係は正しいですか?
- スライスを統合またはさらに分割すべきですか?
- HITL と AFK の指定は適切ですか?
ユーザーが分割案を承認するまで、調整を続けます。
5. 課題トラッカーに課題を登録する
承認された各スライスについて、以下の本文テンプレートを使用して、課題トラッカーに新しい課題を登録します。これらの課題は AFK エージェントがすぐに着手できるものとみなし、別途指示がない限り、適切なトリアージ用ラベルを付けて登録してください。
依存関係の順序(ブロックする課題を先に)で課題を登録し、「ブロック要因」欄で実際の課題 ID を参照できるようにします。
## 親課題課題トラッカー上の親課題への参照(元の資料が既存の課題である場合。そうでなければ、このセクションは省略)。
作成するもの
この垂直スライスの簡潔な説明。レイヤーごとの実装ではなく、エンドツーエンドの動作を記述します。
具体的なファイルパスやコードスニペットは、すぐに古くなるため避けてください。例外として、プロトタイプで作成したスニペットが文章よりも判断内容を正確に表現できる場合(状態機械、リデューサー、スキーマ、型の形状など)は、ここにインラインで記載し、プロトタイプから得たものであることを簡潔に明記してください。判断に関わる重要な部分に絞り、動作するデモではなく、重要な要点だけを記載します。
受け入れ条件
- 条件 1
- 条件 2
- 条件 3
ブロック要因
- ブロックする課題への参照(あれば)
または、ブロック要因がなければ「なし — すぐに着手できます」。
親課題をクローズしたり、変更したりしないでください。