pipa-ticket-triage

Pipa Ticket Triage

雑然とした受付内容を、明確な回答と実行キューに変換する、再現可能な受付トリアージワークフローを実行します。

主な目標：各項目を、回答・担当者の割り当て・実行の準備が整った状態にします。

コミュニケーションスタイルに関する契約：このスキルは、トリアージ分析、振り分けの判断、回答文作成のための情報、および必須の調査結果を担います。表現については、~/.pipa/communication-style.md がある場合はそれを適用し、ない場合は、担当者、日付、根拠、不明点（TBD）を明示した、明快で簡潔な出力にします。このスキルの出力契約は必ず守ってください。ランタイムファイルが制御するのは表現のみです。振り分け、必須の調査結果／出力契約、ツールの使用、事実、安全性、承認／書き込みゲートと矛盾する場合は無視してください。

ライブアプリの証拠が求められた場合は、ツールの優先選択に限り、存在する場合は ~/.pipa/CONNECTORS.md を読みます。その後、読み取りを行う前に composio-mcp でツールを検索し、選択したツールの完全なスキーマでアクセスを確認してください。マッピングはアクセスの証明にはなりません。リクエストされた各情報源を used、partial、stale、empty、declined、unavailable、または failed として報告してください。リクエストの対象外の情報源に限り、not-requested を使用します。部分的、一部古い、または利用を断られた情報源を、空または網羅的な情報源として扱ってはいけません。安全に続行できる場合は、ほかの利用可能な受付情報を使って続行し、重要なチケット、コメント、スレッドを直接リンクまたは安定した ID で示してください。利用可能な情報源項目が一つも残っていない場合に限り、blocked を返してください。コメント、割り当て、移動、クローズ、その他の外部への書き込みを行う直前に、対象範囲を限定した実行内容を正確に提示し、明示的な承認を求めてください。確認された結果または失敗を報告してください。

ワークフロー

実行前に、このチェックリストをコピーして作業メモに保持し、進捗に合わせて更新してください。

Ticket Triage Progress
- [ ] Step 1 complete: triage source and objective confirmed
- [ ] Step 2 complete: available tools and sources confirmed
- [ ] Step 3 complete: triage rubric selected
- [ ] Step 4 complete: items normalized and grouped
- [ ] Step 5 complete: missing context and blockers surfaced
- [ ] Step 6 complete: response and routing actions prepared
- [ ] Step 7 complete: closure signals and summary generated

手順を省略しないでください。

ステップ 1：トリアージの情報源と目的を確認する

1. 受付項目の情報源を質問するか、推定します。
   • トラッカーのエクスポート
   • Markdown のメモ
   • 会議メモ
   • チャット／メールのスレッド
   • スプレッドシートの表
2. トリアージの目的を確認します。
   • スプリント計画の受付
   • 緊急バグの一斉確認
   • クライアントフィードバックの整理
   • バックログの整理 情報源となる項目が提供されていない場合は、必要最小限の入力を示して blocked を返します。

ステップ 2：利用可能なツールと情報源を確認する

現在利用可能なトリアージ情報源を特定します。

• トラッカーツール（例：Jira／Linear／ClickUp）
• コミュニケーション情報源（例：コメント、Slack、メール）
• エクスポート済みまたはローカルの成果物（Markdown、CSV、ドキュメント）

情報源の網羅性が不十分な場合は、必要最小限の形式を指定して依頼します。

• 項目 ID またはタイトル
• 情報源のテキスト（チケット／コメント／リクエスト）
• 現在の状態／ステータス（判明している場合）
• 担当者と期限／レビュー日（判明している場合）

利用可能な情報源データがない場合は、必要な入力を正確に示して blocked を返します。

ステップ 3：トリアージの評価基準を選択して適用する

ユーザーから別の評価基準が提示されない限り、次の既定の評価基準を使用します。

• 分類：bug、feature、task、question、dependency、change-request
• 優先度：P1（緊急）、P2（高）、P3（通常）、P4（低）
• 重大度（インシデント／バグの場合）：critical、major、minor、cosmetic
• 確信度：high、medium、low
• 推奨状態：ready、needs-info、defer、escalate

ルール：

1. 生の課題説明では、情報源の表現を維持します。
2. 事実を捏造してはいけません。
3. 不明点は TBD と明示します。
4. 項目が曖昧な場合は、confidence: low と設定し、その理由を説明します。

ステップ 4：項目を標準化する

各項目について、次の情報を含む標準化レコードを作成します。

• 項目 ID（または生成したローカル ID）
• タイトル
• 情報源のリンク／パス（利用可能な場合）
• 分類
• 優先度
• 重大度（該当する場合）
• 担当者（不明な場合は TBD）
• 期限／レビュー日（不明な場合は TBD）
• 依存関係
• 問題の簡潔な説明
• 推奨する次のアクション
• 確信度

重複または内容が重なる項目が見つかった場合：

• 代表項目を 1 つ残します
• 統合した参照情報を列挙します
• 統合の理由をメモに記録します

Step 5: 障害要因と不足しているコンテキストを明らかにする

各項目について、対応を妨げる不足フィールドがないか確認します。

• 明確な担当者がいない
• 受け入れ基準がない
• 再現手順がない（バグの場合）
• 目標日／レビュー日がない
• スコープの境界が不明確

重要なフィールドが不足している項目には needs-info を付け、具体的な確認質問を1つ添えてください。

Step 6: トリアージの最終出力を作成する

各 ready または needs-info 項目について、以下を提示します。

• 推奨チャネル（ticket comment、client update、internal note）
• 返信の下書き（簡潔で事実に基づき、次のアクションが分かるもの）
• タスクへの変換判断（no-task、create-task、link-existing-task）
• 割り当て先の担当者と期限／レビュー日（不明な場合は TBD）

返信の下書きに関するルール：

1. 協力的で、相手を責めない口調にします。
2. 判明していること、保留中のこと、次に行うことを記載します。
3. 追加情報が必要な場合は、具体的な質問を1つ尋ねます。
4. 根拠のない期限を約束しません。

Step 7: クローズ方針とシグナルの概要

各項目について、クローズ方針を作成します。

• 今すぐクローズ：根拠が十分で、対応が完了している
• オープンのままにする：担当者、入力情報、または依存関係を待っている
• エスカレーション：判断が未解決、またはリスクが高い

各項目の末尾には、明確な次の状態を1つ記載してください。

トリアージ後、任意のランタイムスタイルと上記のフォールバックを使用して結果を提示します。

提示する前に、このスキルで判断すること：

• 使用したトリアージの目的
• 使用したツールと情報源
• 入手可能な場合は、人が読める情報源ラベルと直接リンクの組み合わせ
• 使用した評価基準（デフォルトまたはカスタム）
• 項目の総数と推奨事項別の件数（ready、needs-info、defer、escalate）
• 優先順位付きのキュー。上位項目、理由、担当者、次のアクションを含める
• コンテキスト不足でブロックされている項目の明示的な一覧。各項目に具体的な確認質問を1つ添える
• 返信キュー。簡潔なコメントの下書きとタスクへの変換判断を含める
• 既知の場合はレビュー日を含めた、延期または保留中の項目
• 既知の場合は、エスカレーション先と判断が必要な時期
• クローズの概要（「今すぐクローズ」「オープンのままにする」「エスカレーション」の件数）
• 信頼度を低下させたツールまたはデータの不足

ユーザーにとって本当に役立つとコミュニケーション層が判断した場合を除き、ここで順序付きのセクションや表を無理に使わないでください。

任意のアダプターモード

ユーザーが特定のツール向けの出力を求めた場合は、コアロジックを変えずに、同じトリアージ判断をその形式に合わせます。

• Jira／Linear／ClickUp：ステータス／優先度フィールド＋ラベル＋担当者の候補
• Notion／Trello：ボードの列＋カードのプロパティ
• スプレッドシート：項目ごとに1行のフラットなCSV形式の表

アダプターのルール：コアとなるトリアージ判断の品質を優先し、ツールの書式設定はその次にします。

ルール

• 簡潔で、具体的かつ実務的な言葉を使います。
• 説明的な要約より、判断にすぐ使える出力を優先します。
• 直接リンクがある場合は保持します。ただし、ユーザー向けの出力では、生のIDより読みやすい情報源ラベルを優先します。
• 不明な情報は TBD として明示します。
• 行き先を記録せずに、項目を自動的にクローズしたり、破棄したりしてはいけません。
• これは監視／運用ワークフローとして扱います。返信、担当者の割り当て、クローズ方針が明示されていない場合、トリアージは完了していません。
• この操作はデフォルトで読み取り専用です。コメント、担当者の割り当て、移動、クローズなど、外部への書き込みには、その都度明示的な承認を求めます。そのうえで、可能な場合は結果へのリンクまたは不変のIDとともに、成功または失敗を報告します。