mcpField
T
to-issues

to-issues

github.com/guillermomurillo開発439 回インストール16 週間前に更新
リポジトリ

to-issues について

to-issuesは、計画を個別に検証できる小さなエンドツーエンドの縦割り課題に分解するスキルです。依存関係と種別を確認し、承認後に課題トラッカーへ登録する手順を案内します。

主な機能

  1. 01計画を縦割りスライスに分解
  2. 02HITLまたはAFKに分類
  3. 03依存関係と粒度の確認
  4. 04依存順に承認済み課題を登録
  5. 05種別ごとに登録課題を要約

活用シーン

  1. 01プロジェクト計画を実装可能な課題に分割
  2. 02登録前に課題の依存関係を確認
  3. 03人間主導またはAFK実装の作業を準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/guillermomurillo/memo-flow --skill to-issues

インストール後、Claude Code で/to-issuesを入力して読み込まれたか確認します。

詳細

Issue 化

計画を、縦方向のスライス（トレーサーバレット）を使って、個別に着手できる Issue に分割します。

Issue トラッカーとトリアージ用ラベルの語彙が提供されているはずです。提供されていない場合は、/memo-flow を実行してください。

プロセス

1. コンテキストを集める

会話のコンテキストにすでにある情報を使ってください。ユーザーが引数として Issue の参照（Issue 番号、URL、またはパス）を渡した場合は、Issue トラッカーから取得し、本文とコメントをすべて読んでください。

2. コードベースを調べる（任意）

コードベースをまだ調べていない場合は、現在のコードの状態を把握するために調査してください。Issue のタイトルと説明では、プロジェクトのドメイン用語集を使い、対象領域の ADR に従ってください。

3. 縦方向のスライスを作成する

計画をトレーサーバレット Issue に分割してください。各 Issue は、1 つのレイヤーだけを対象とする横方向のスライスではなく、すべての統合レイヤーをエンドツーエンドで貫く薄い縦方向のスライスです。

スライスは「HITL」または「AFK」にできます。HITL スライスには、アーキテクチャ上の判断やデザインレビューなど、人間による対応が必要です。AFK スライスは、人間の対応なしで実装してマージできます。可能な場合は、HITL より AFK を優先してください。

- 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を貫く、範囲は狭くても完全な一連の処理を実現します - 完了したスライスは、それ単独でデモまたは検証できます - 厚いスライスを少数作るより、薄いスライスを多数作ることを優先します
4. ユーザーに確認する

提案する分割案を番号付きリストで提示してください。各スライスについて、以下を示します。

  • タイトル：短く説明的な名前
  • タイプ：HITL / AFK
  • 依存先：先に完了する必要がある他のスライス（あれば）
  • 対象となるユーザーストーリー：このスライスが対応するユーザーストーリー（元の資料にある場合）

ユーザーに以下を確認してください。

  • 粒度は適切ですか？（粗すぎる／細かすぎる）
  • 依存関係は正しいですか？
  • 統合またはさらに分割すべきスライスはありますか？
  • HITL と AFK の分類は適切ですか？

ユーザーが分割案を承認するまで、調整を繰り返してください。

5. Issue を Issue トラッカーに登録する

承認された各スライスについて、Issue トラッカーに新しい Issue を登録してください。以下の Issue 本文テンプレートを使用してください。これらの Issue は AFK エージェントがすぐに作業できるものとして扱われるため、別途指示がない限り、適切なトリアージラベルを付けて登録してください。

依存関係の順序（ブロッカーを先）に Issue を登録し、「依存先」欄で実際の Issue 識別子を参照できるようにしてください。

## 親 Issue

Issue トラッカー上の親 Issue への参照（元の資料が既存の Issue の場合。そうでなければ、このセクションは省略してください）。

実装内容

この縦方向のスライスについて、簡潔に説明してください。レイヤーごとの実装方法ではなく、エンドツーエンドの動作を説明してください。

具体的なファイルパスやコードスニペットは避けてください。すぐに古くなるためです。例外として、プロトタイプで作成したスニペットが文章よりも正確に判断内容を表現できる場合（状態機械、リデューサー、スキーマ、型の形状など）は、ここにインラインで記載し、プロトタイプから作成したことを簡潔に注記してください。判断に必要な部分だけに絞ってください。動作するデモではなく、重要な要点のみを記載します。

受け入れ条件

  • 条件 1
  • 条件 2
  • 条件 3

依存先

  • ブロッカーとなるチケットへの参照（あれば）

ブロッカーがなければ「なし - すぐに着手できます」と記載してください。

親 Issue をクローズまたは変更してはいけません。

6. 完了報告

すべての Issue を登録した後、新しい Issue 番号とタイトルをタイプ（AFK / HITL）ごとにまとめて簡潔に報告してください。その後、以下の案内を一字一句そのまま出力して終了してください。具体的な Issue 番号は含めないでください。

  • AFK スライス：afk-cook スキルに引き継いでください。このスキルは依存関係を解決し、ready-for-agent のスライスを正しい順序ですべて実行します。起動方法はスキルのドキュメントに記載されています。ここではスクリプトのパスやフラグを指定しないでください。
  • HITL スライス：各 Issue を開き、対話形式で /tdd を実行してください。

特定の Issue 番号を指定して afk-cook の実行を提案してはいけません。実行順序の判断はランナーが行います。ここで Issue を指定すると、実行時にランナーが再度行う判断を先取りすることになります。

コメント

Markdown 対応