triage

triage スキルの概要

triage ができること

triage は、受け付けた GitHub issue を役割ベースの状態機械で振り分けるための GitHub issue triage スキルです。報告内容を分類し、追加情報が必要かどうかを判断し、AFK エージェントに回すか人間のメンテナーに渡すかを整理できます。Issue Tracking 向けの triage スキルを探しているなら、判断の迷いを減らし、issue 対応を一貫させるためのものです。

どんな人に向いているか

triage スキルは、issue キューが多い、繰り返し使える受付フローが欲しい、まとまりのないバグ報告を実行可能な作業に変換する枠組みが必要、という場合に向いています。特に、bug と enhancement を切り分けたうえで、各 issue を needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix のいずれかへ進めたいときに役立ちます。

何が違うのか

最大の差別化ポイントは、明示的な状態機械と役割の厳格さです。このスキルは単に「issue を要約する」だけではありません。必ず 1 つの category role と 1 つの state role を求め、さらに triage のコメントや issue メッセージはすべて開示ディスクレーマーで始める、という厳密な要件があります。予測可能な出力、ポリシーを意識した振り分け、別のエージェントへきれいに引き継げる triage ワークフローが必要なら、この点が重要です。

triage スキルの使い方

インストールして最初に読む

インストールは次のコマンドです:

npx skills add mattpocock/skills --skill triage

triage のインストール後は、まず SKILL.md を読み、次に AGENT-BRIEF.md と OUT-OF-SCOPE.md を確認してください。これらのファイルには、長く使える brief の形式と、採用されない案をどう記録するかが説明されています。どちらも実際の triage 品質に最も影響しやすい部分です。repo には補助スクリプトや追加の参照フォルダは含まれていないため、この 3 ファイルが実質的な中核になります。

スキルに適切な入力を与える

triage の使い方は、issue のタイトル、本文、既存ラベル、そして triage で何をしたいのかを具体的に渡すと最も効果的です。入力が明確だと、分類したいのか、追加情報が必要なのか、agent brief が欲しいのか、最終的に却下するのかをスキルが判断しやすくなります。

良いプロンプト例:

• “この GitHub issue を triage してください。bug か enhancement に分類し、適切な state role を選び、AFK agent に渡すべきか human に残すべきかを示してください。”
• “issue スレッドと現在のラベルはこれです。triage の状態機械を適用し、必須の disclaimer を含むコメントを下書きしてください。”
• “これは情報が不足しています。needs-info と ready-for-agent のどちらに入れるべきか判断し、不足している acceptance criteria を説明してください。”

ラベル付けだけで終わらせず、ワークフローとして使う

実用的な triage ガイドラインとしては、出力を分類結果ではなくルーティングとして扱うのがポイントです。まず、その issue が bug か enhancement かを確認します。次に、実行可能か、報告者の回答待ちか、あるいは明確に対象外かを見ます。agent 作業に進められる状態なら、brief には file path や実装手順ではなく、期待される振る舞いと acceptance criteria を書くべきです。

リポジトリのルールに注意する

出力品質に大きく影響する要素は 2 つあります。ディスクレーマー必須の要件と、「category role は 1 つ、state role も 1 つだけ」というルールです。issue の状態が曖昧なときは、スキルはその矛盾を指摘し、何かを変える前にメンテナーへ確認するよう求めます。無理にラベルを決め打ちするより、そこで一度止まって明確化するのが正しい対応です。

triage スキル FAQ

triage は GitHub issue のラベル付けだけのためのものですか？

いいえ。GitHub 風の issue tracking を前提にしていますが、中心となる仕事は issue の状態判断と作業の振り分けです。別のラベル文字列を使う tracker でも、canonical な役割は重要であり、実際に動かす前に自分のシステムへ対応付ける必要があります。

普通のプロンプトを書けるなら、これも必要ですか？

普通のプロンプトでも 1 件の issue は分類できますが、triage スキルは再利用しやすい状態モデル、brief 作成の型、そして out-of-scope の扱いを明示します。1 回限りの要約ではなく、多数の issue で一貫した判断をしたい場合に価値があります。

triage は初心者でも使えますか？

はい、基本的な issue ラベルを理解していれば使えます。triage スキルは、どの state があり、それぞれの遷移が何を意味するかを示してくれるため、独自のポリシープロンプトを作るより扱いやすいです。初心者にありがちな失敗は、issue の文脈を飛ばして、本文も議論も現状の state もないままラベルだけを求めることです。

どんなときに triage を使うべきではありませんか？

詳細な実装計画やコードレビューには使わないでください。これは受付、振り分け、対応可能性の判断のためのものです。issue にすでに完全な仕様があり、設計やコーディングの支援が必要なら、別のスキルか、直接的な実装プロンプトのほうが適しています。

triage スキルを改善するには

issue の文脈をもっと詳しく渡す

triage スキルは、issue 本文全体、見えているコメント、現在のラベル、メンテナーのメモまで含めると精度が上がります。タイトルだけでは、再現可能か、すでに回答済みか、重要な情報が欠けているかを判断できず、ルーティングが弱くなりがちです。

本当に欲しい判断をはっきり依頼する

目的が “ready for agent” なら、そのまま伝えてください。目的が “wontfix として閉じるべきか” なら、そう明示するべきです。triage の使い方で最も強いのは、判断の境界を具体的に指定することです。そうすれば、スキルは一般的な要約ではなく、必要な state に向けて最適化できます。

引き継ぎの質を上げる

issue を ready-for-agent に移すときは、振る舞い、制約、acceptance criteria を長く使える表現でまとめた agent brief を依頼してください。file 単位の実装指示は、本当に必要な場合を除いて避けたほうがよいです。repo のガイダンスは、コードベースの変化に耐えやすい behavioral contract を重視しています。

1 回目の結果をもとに詰める

最初の triage がやや慎重すぎる場合は、次の 3 つの要素のどれかを追加して再実行すると改善しやすくなります: 再現手順、期待動作と実際の動作の差分、またはユーザーにとってその issue がなぜ重要か。こうした情報は、その issue が needs-info、ready-for-human、wontfix のどれに入るかを決めることが多く、2 回目の triage をより निर्ण decisive にします。