to-issues

to-issues skill の概要

to-issues でできること

to-issues は、計画書、仕様書、PRD を、1 件ずつ着手できる issue tracker 用チケットに変換します。to-issues skill は tracer-bullet の縦割りスライスを前提に作られているため、各 issue は大きな横断的塊ではなく、薄くて end-to-end の経路を表すべきです。

どんな人に向いているか

実行にそのまま移せる implementation ticket が必要なら、to-issues を使うとよいでしょう。特に、プロダクト作業、リファクタリング、移行、機能リリースに向いています。issue tracker に、ゆるい backlog ではなく、実際の順序、依存関係、担当分担を反映させたいときに強くフィットします。

何が違うのか

to-issues skill の主な価値は、スライスの規律にあります。必要に応じて schema、API、UI、テストをまたぎつつ、個別に拾って着手できる issue を優先します。また、AFK slice と HITL slice を区別するため、マージ可能な作業と、人の確認や判断が必要な項目を切り分けやすくなります。

to-issues skill の使い方

インストールとセットアップ

npx skills add mattpocock/skills --skill to-issues で to-issues skill をインストールします。使う前に、issue tracker、labels、triage 用語がエージェントから参照できる状態になっているか確認してください。この skill はその前提を置いており、未整備であれば /setup-matt-pocock-skills が必要になる可能性があると明記しています。

適切な入力を渡す

to-issues usage をよくするには、分解したい元資料を渡すのが重要です。短い計画、仕様書、PRD、コメント付きのリンク済み issue などが適しています。既存 ticket を参照する場合は、issue 番号、URL、または path を含めてください。そうすれば、タイトルだけで推測せずに、本文とコメント全体を取得できます。

おすすめのワークフロー

まず現在の会話コンテキストを起点にし、必要な追加情報を skill に集めさせ、必要ならコードベースを確認し、tracer-bullet のスライスを下書きします。to-issues guide としては、次の条件を満たす issue を求めるのが有効です。

• 狭いが、end-to-end で完結している
• プロジェクト固有の用語に沿って命名されている
• ファイル構成ではなく、実際の依存関係順に並んでいる
• 人の入力なしでマージできるものは AFK としてマークされている

最初に読むべきファイルと手がかり

to-issues を評価したり拡張したりする場合は、まず SKILL.md から確認してください。この repository には、現時点で補助的な README.md、AGENTS.md、追加のルールファイルがありません。実用的な手がかりは process の説明文と vertical-slice のルールにあるため、隠しスクリプトや追加設定を探すより、process セクションに集中するのが適切です。

to-issues skill の FAQ

to-issues は Issue Tracking 専用か？

おおむね、そのとおりです。to-issues は一般的なブレインストーミングやロードマップ作成ではなく、issue tracking と作業分解に特化しています。リリースノート、アーキテクチャ文書、issue tracker に入れる前提ではない task list が必要なら、汎用プロンプトのほうが適している場合があります。

使う前に何を用意すべきか？

最適な入力は、明確な計画、現状のコードベースのコンテキスト、そして labels や triage ルールなど重要な tracker の慣習です。これがなくても to-issues は issue を下書きできますが、タイトルの精度が下がり、順序付けも甘くなり、スコープのずれが起きやすくなります。

初心者でも使いやすいか？

はい、作業内容をはっきり説明できるなら使いやすいです。大きな目標を実行可能なスライスに変換する難しい部分は skill が担ってくれますが、初心者でも、1 つの具体的な目的を伝え、プロジェクト固有の用語で issue 化するよう依頼すると効果が出ます。

どんなときに使わないほうがよいか？

すぐに使う todo list だけが必要なとき、分解するには曖昧すぎる作業のとき、issue tracker 自体が存在しないときは、to-issues を使わないでください。複数の独立して届けられる issue ではなく、1 つの大きな ticket が欲しい場合にも向きません。

to-issues skill を改善する方法

元資料をもっと強くする

to-issues の結果をよくする一番の方法は、明確な source of truth を渡すことです。たとえば、PRD の該当セクション、デザインノート、あるいは分解したい issue そのものが有効です。実装に影響する制約も含めてください。たとえば、ロールアウト要件、影響範囲、従うべき ADR などです。

件数だけでなく、スライスの質を求める

よくある失敗は、チケットが広すぎる、レイヤーが多すぎる、あるいは互いに依存しすぎることです。to-issues の出力には、end-to-end のスライスを優先し、各 ticket がデモ可能で、AFK 作業と HITL 判断が分かれていて、キューとして実行しやすい状態を求めてください。

タイトル、スコープ、順序を反復で整える

最初の結果を見たら、チームの用語に合うよう issue タイトルを調整し、まだ横断的すぎる ticket は絞り込みます。分解の方向性は近いが少しずれている場合は、依存順を調整する、リスクの高いスライスを分割する、使っている tracker に合わせて acceptance criteria をより具体的にする、といった修正版を依頼してください。