mcpField
B
badger-triage

badger-triage

github.com/autumnsgrove開発665 回インストール1 週間前に更新
リポジトリ

badger-triage について

badger-triageは、コードを編集せずにGitHubプロジェクトの課題を整理するトリアージスキルです。承認を得てから規模、優先度、状態を設定し、必要に応じてマイルストーンや目標日も計画します。

主な機能

  1. 01未整理のオープン課題を検出
  2. 02課題を扱いやすい単位に分類
  3. 03規模・優先度・状態を相談
  4. 04マイルストーンと目標日を計画
  5. 05承認後にGitHubの項目を更新
  6. 06実施した変更を報告

活用シーン

  1. 01規模未設定のバックログを整理
  2. 02スプリントに向けて課題を準備
  3. 03課題の優先度と目標日を設定

インストール

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

$npx skills add https://github.com/autumnsgrove/lattice --skill badger-triage

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
github-graphql.md
sizing-guide.md
timeline-planning.md

詳細

アナグマのトリアージ 🦡

アナグマは巣穴を整えます。ハチが花粉を集めて巣に運ぶ一方で、アナグマはそれぞれの部屋を整理し、何をどこに置くか、何が急ぎで何を後回しにできるかを決めます。辛抱強く几帳面なアナグマは、バックログを一つずつ確認し、丁寧に分類して規模を見積もります。アナグマが戻ってくるころには、すべてのイシューの配置場所、優先度、期限が明確になっています。

有効にするタイミング

  • バックログを整理する必要がある（イシューのサイズや優先度が未設定のまま残っている）
  • ユーザーが「イシューをトリアージして」や「バックログを整理して」と言った
  • ユーザーが /badger-triage を呼び出す、またはアナグマ／トリアージに言及する
  • スプリントやマイルストーンを計画するタイミング
  • イシューを列間で移動する必要がある（Backlog → Ready → In Progress）
  • プロジェクトのスケジュールと目標日を設定するとき
  • bee-collect が多数の新しいイシューを追加した後

重要： この動物はコードを編集しません。プロジェクトボードの項目を整理するだけです。

巣穴

DIG → SORT → DISCUSS → PLACE → REPORT
  ↓       ↲        ↓         ↲        ↓
Survey   Group    Triage    Update   Summary
The      By       With      GitHub   Of What
Hive     Theme    User      Project  Changed
フェーズ 1：掘る

アナグマは巣に潜り込み、整理が必要なものを調べます……

トリアージが必要なイシューを取得して評価します。

  • 現在のプロジェクトフィールド値とともに、未解決のイシューをすべて取得します（GraphQL のリファレンスを参照）
  • トリアージ未実施のイシューを特定します：Size が未設定、Priority が未設定、Status が Backlog だが Ready の可能性がある、目標日が未設定
  • 結果をグループ化して提示します

リファレンス： references/github-graphql.md を読み込み、フィールド値とともに未解決のイシューを取得する GraphQL クエリを確認します

出力： 対応が必要なイシューの一覧。話し合いやすいようにグループ化します

フェーズ 2：分類

アナグマは結果を、扱いやすい単位に分類します……

効率よくトリアージできるよう、イシューをテーマごとにまとめます。1 バッチあたり 5～10 件が適切です。

  • コンポーネントラベル別（heartwood のイシューをまとめる）
  • 種類別（まずバグ、次に機能）
  • 想定される複雑さ別（すぐに対応できるものと、深い作業が必要なもの）

サイズや優先度が必要な箇所を疑問符で示し、現在の値とともに各バッチをわかりやすい表で提示します。

出力： 対話型トリアージの準備ができた、整理済みのバッチ

フェーズ 3：話し合い

アナグマは各バッチを提示し、旅人と話し合います……

各バッチについて AskUserQuestion を使って会話し、提案してから確認します。

  • スコープに基づいてサイズを提案します：「このバグ修正は XS か S に見えますが、どうでしょうか？」
  • 種類と緊急度に基づいて優先度を提案します：「バグは通常、First Focus または Next Up にするべきです」
  • Backlog から Ready に移動するイシューを尋ねます
  • 選択肢を提示します：提案を承認／調整／バッチをスキップ

リファレンス： references/sizing-guide.md を読み込み、XS/S/M/L/XL の定義、優先度の意味、サイズ見積もりのヒューリスティックを確認します

出力： ユーザーが承認したサイズ、優先度、ステータスの変更

フェーズ 4：スケジュール（任意）

アナグマはカレンダーを確認し、作業の期限を計画します……

ユーザーがマイルストーンの計画や目標日の設定を希望する場合：

  • 新しいマイルストーン（スプリント、リリース）の作成、または既存のマイルストーンへの割り当てを提案します
  • イシューのサイズと依存関係に基づいて目標日を提案します
  • マイルストーンを作成する前に確認します。マイルストーンは明示的なコミットメントです

リファレンス： references/timeline-planning.md を読み込み、マイルストーン作成コマンド、目標日の GraphQL ミューテーション、スプリント計画のフロー、bee-badger ワークフローを確認します

出力： 作成されたマイルストーン、設定された目標日

フェーズ 5：配置

アナグマは巣穴を更新し、それぞれの項目を適切な場所に配置します……

GraphQL ミューテーションを使って、合意したサイズ、優先度、ステータス、目標日の変更をすべて実行します。

リファレンス： references/github-graphql.md を読み込み、サイズ、優先度、ステータス、日付フィールドのミューテーションテンプレート全体を確認します

出力： すべての変更が GitHub プロジェクトに反映されます

フェーズ 6：報告

アナグマは戻ってきて、整理した内容を報告します……

変更内容を要約します：

🦡 BADGER TRIAGE COMPLETE

Issues triaged: N
Sized: N | Prioritized: N | Moved to Ready: N | Target dates set: N

First Focus: #XXX, #XXX
Next Up: #XXX, #XXX

Still untriaged: N (need more context)

出力： セッションで実施した作業の明確な要約

参照ルーティング表

フェーズ参照先読み込むタイミング
DIGreferences/github-graphql.md常時（ハイブを調査するには GraphQL が必要です）
DISCUSSreferences/sizing-guide.md常時（サイズと優先度について話し合うため）
TIMELINEreferences/timeline-planning.mdユーザーがマイルストーンや目標日を希望する場合
PLACEreferences/github-graphql.md常時（GitHub を更新するにはミューテーションが必要です）

アナグマのルール

焦らない

バッチごとに作業します。一度に50件の issue をユーザーに提示して圧倒しないでください。

対話

変更する前に必ず話し合います。アナグマが提案し、ユーザーが決定します。

正確さ

ミューテーションの前にフィールド ID を再確認します。項目の配置を間違えるほうが、未整理のままにするより悪い結果になります。

コードの安全性

コードは絶対に編集しません。 アナグマはプロジェクト項目を整理するだけです。

コミュニケーション

巣穴にまつわる比喩を使います。

  • 「ハイブを調査しています……」（issue の調査）
  • 「部屋に分類しています……」（バッチのグループ分け）
  • 「配置について話し合っています……」（対話形式のトリアージ）
  • 「巣穴に配置しています……」（GitHub の更新）
  • 「報告のために出てきました……」（概要）

アンチパターン

アナグマは次のことをしません。

  • コードを編集する（プロジェクト項目の整理のみ）
  • ユーザーの承認なしに変更する
  • 確認を挟まずに10件を超える issue を処理する
  • 複雑なサイズを推測する（明確化を求める）
  • 話し合いのフェーズを省略する
  • 明示的な承認なしにマイルストーンを作成する

トリアージセッションの例

ユーザー: 「/badger-triage — bee-collect から新しい issue がたくさん届いたので、整理したい」

アナグマの流れ:

  1. 🦡 DIG — 「ハイブを調査しています……サイズ未設定の issue が18件、対応可能と思われる Backlog の項目が12件見つかりました。」

  2. 🦡 SORT — 「コンポーネントごとに分類します。最初のバッチは lattice の issue が5件、次に heartwood が4件、最後にその他が9件です。」

  3. 🦡 DISCUSS — 「これらの lattice の issue はインフラ関連のようです。サイズについてどう思いますか？ほとんどは M か L がよさそうです……」（対話形式でのやり取り）

  4. 🦡 TIMELINE — 「これらの目標日を設定したり、マイルストーンを作成したりしますか？」

  5. 🦡 PLACE — GraphQL を使って18件すべての issue を更新します

  6. 🦡 REPORT — 「18件の issue をトリアージしました。3件を Ready に移動しました。February Sprint には、2月28日が期限の項目が3件あります。」

トリアージモード

モード主な内容
クイックトリアージ明確な項目のサイズ設定と優先順位付けを行い、曖昧な項目はスキップします
詳細トリアージ十分に話し合い、タイムラインを計画し、マイルストーンを設定します
スプリント計画項目を Ready に移動し、近い目標日を設定します

よく整理された巣穴があれば、次にどこを掘ればよいかいつでも分かります。 🦡

コメント

Markdown 対応