tres-request-skill-update

TRES プラグインへのフィードバック

ユーザーが TRES Claude プラグインについて、明確で実行可能なフィードバックを送信できるように案内し、save_ai_conversation_feedback TRES MCP ツールを使って保存します。追加の設定は不要です。TRES API トークンを持つユーザーなら誰でも利用できます。

このスキルは、次の 2 つのモードで動作します。

1. 明示的なフィードバック — ユーザーがフィードバックの送信やバグの報告などを依頼した場合、ステップ 1 から案内を開始します。
2. 会話終了時のプロンプト — 会話が終わりに近づいている場合、簡単で押しつけがましくない声かけをします（ステップ 0 を参照）。ユーザーが希望した場合のみ、詳しい案内に進みます。

---

ステップ 0 — 会話終了時のプロンプト

会話が終わりに近づいていると思われる場合（ユーザーが「ありがとう」「これで全部です」「よさそうです」などと言った場合）に、このスキルが自発的に起動されたときは、次のように気軽に尋ねます。

お帰りになる前に、今回のセッションについて何かフィードバックはありますか？バグやアイデア、改善できそうな点など、30 秒ほどでチームに共有できます。

• ユーザーが断った場合（「いいえ」「大丈夫です」「結構です」など） — 「わかりました。それでは、よい一日を！」と伝えて終了します。それ以上、勧めてはいけません。
• ユーザーが何か共有した場合 — ステップ 1 に進み、詳しい案内を行います。ただし、軽いやり取りを心がけます。会話の中ですでに回答済みの質問は省略し、手短に完了することを目指します。
• 気軽で任意のものとして受け取れる口調を保ちます。必須のアンケートだと感じさせてはいけません。

---

ステップ 1 — 送信者の特定

1. get_viewer（TRES MCP、引数なし）を呼び出して、送信者を特定します。

   • 応答から組織名を取得します。
   • get_viewer が失敗した場合は、送信者を "Unknown org" として続行します。

2. フィードバック記録に使用するユーザーの git ID を取得します。

   git config user.name && git config user.email
   

   1 行目を agent_name、2 行目を agent_email として使用します。git を利用できない場合は、システムのユーザー名を使用し、メールアドレスは空欄にします。

ユーザーに次のように伝えます。「{orgName} として接続されています。どのようなフィードバックを共有しますか？」

---

ステップ 2 — フィードバックを把握する

まず、ユーザー自身の言葉でフィードバックを説明してもらいます。その後、内容に基づいて次のいずれかのカテゴリに分類します。

カテゴリ	使用するタイミング
バグ報告	何かが動作しない、エラーが発生する、または誤った結果が生成される
機能リクエスト	まだ存在しない新しい機能
改善	既存の機能は動作するものの、より良くできる（UX、書式、流れ、パフォーマンス）
新しいスキルのアイデア	まったく新しいスキルの提案
MCP／データの問題	TRES MCP が誤ったデータを返す、フィールドが不足している、または予期しない動作をする
ポジティブなフィードバック	うまく動作しており、チームに知らせたいこと
一般的なフィードバック	その他すべて — ワークフロー上の不便、混乱、ドキュメント、オンボーディング

ユーザーにカテゴリを確認します：「{category} に関する内容のようですが、合っていますか？」

フィードバックが特定のスキルや MCP ツールに関するものであれば、どれに該当するか特定します。全般的な内容、またはプラグイン全体に関する内容であれば、その旨を記録します。

既知のスキル：

スキル	説明
tres-asc845-swap-reprice-skill	ASC 845 のスワップ再評価を行い、クリアリングアカウントの残高をゼロにする
tres-explorer-tx-to-ledger	エクスプローラーの TX を TRES 台帳に追加する
tres-tx-story	TX フロー図と説明
tres-recon-gaps	照合差異の解消
tres-asset-balance-validation	DeBank と照合した残高の検証
tres-report-analyzer	TRES レポートの XLSX エクスポートを分析する
tres-report-advisor	適切な TRES レポートを提案する
tres-invoice-bill-matching	TX を ERP の請求書／支払請求書と照合する
tres-export-3rd-party-contacts	未識別の取引相手を XLSX にエクスポートする
tres-import-contacts	CSV／XLSX から連絡先をインポートする
tres-cost-basis	取得原価の計算、戦略、問題、再評価、エクスポート
tres-rollup-rules	サブトランザクションのロールアップルール（TX を集約する）
tres-onboarding	エンティティの全オンボーディング（サブスキルを調整する）
tres-settings-management	組織とプラットフォームの設定
tres-wallets-upload	ウォレットのオンボーディング
tres-upload-tx-header-validation	一括取引 CSV のヘッダー名の検証
tres-request-skill-update	このフィードバックスキル

メンテナー向けメモ：プラグインに新しいスキルを追加したときは、この表も更新してください。

---

ステップ 3 — さらに詳しく聞く

カテゴリーに応じて、フィードバックを実行可能な内容にするため、的を絞った追加の質問をします。 一度に質問するのは1つか2つにして、尋問のようにならないよう、会話調を保ちます。

バグ報告の場合：

• 具体的に何が起きましたか？何を目にしましたか？
• 代わりにどのような動作を期待していましたか？
• 発生したとき、何をしていましたか？（再現手順）
• エラーメッセージは表示されましたか？表示された場合、何と書かれていましたか？
• 具体例を共有できますか？（トランザクションハッシュ、ウォレットアドレス、使用した入力など）

機能リクエストと改善の場合：

• これによって、どのような問題を解決できますか？
• この機能がない現在、どのように対応していますか？
• 理想的な利用体験がどのようなものか説明できますか？
• このニーズにどれくらいの頻度で直面しますか？

新しいスキルのアイデアの場合：

• このスキルで、どのようなワークフローやタスクを自動化できますか？
• チームの誰が、どれくらいの頻度で使いますか？
• どのように利用するか、具体例を挙げて説明できますか？
• どのデータソースが必要ですか？（TRES MCP、外部 API、ローカルファイル）

MCP／データに関する問題の場合：

• どの MCP ツールまたはクエリが関係していましたか？
• どのようなデータが返され、何が問題でしたか？
• どのようなデータを期待していましたか？
• 使用した具体的なクエリや識別子を共有できますか？

肯定的なフィードバックの場合：

• 具体的に何がうまくいきましたか？
• 良い意味で、何か驚いたことはありましたか？
• 特に効果を発揮したワークフローやユースケースはありますか？
• さらに良くするために、変更したい点はありますか？

一般的なフィードバックの場合：

• 利用体験のどの部分についてのフィードバックですか？
• 分かりにくかった点や不明瞭だった点はありましたか？
• 何があれば、もっと良くなっていましたか？

ユーザーがすでに伝えた内容に応じて質問を調整し、回答済みの質問は省きます。 フィードバックを読む人が、追加の質問をしなくても背景を理解し、対応できるだけの詳細を得ることが目標です。

---

ステップ 4 — フィードバックを確認する

フィードバックをまとめ、確認のためユーザーに提示します。分かりやすく書式を整えます。

Headline: {concise summary — max 80 chars}

Category: {Bug report | Feature request | Improvement | New skill idea | MCP issue | Positive feedback | General}
Area: {skill name, "MCP", or "General"}
Org: {orgName}

---

{Well-structured description that includes:
 - What the feedback is about (context)
 - The core issue, idea, or praise (substance)
 - Supporting details — steps to reproduce, examples, expected behavior, etc.
 - Impact — how often this comes up, how many people it affects, how it blocks work}

Tags: {comma-separated list}

説明文の作成：

• ユーザーの回答を、明確で読みやすい文章にまとめます。質疑応答をそのまま並べるだけにしないでください。
• 最も重要な点から始めます。
• 具体的な詳細（トランザクションハッシュ、エラーメッセージ、具体的な手順など）を含めます。こうした情報がフィードバックを実行可能なものにします。
• 肯定的なフィードバックでは、何がうまくいき、なぜ重要だったのかを具体的にします。

また、送信する会話の抜粋もユーザーに提示します（ステップ 5 の形式を参照）。 これにより、ユーザーは自分のマシンから送信される内容を把握できます。

次のように尋ねます：「送信する内容はこちらです。すべて反映されていますか？変更したい点はありますか？」

ユーザーが編集を希望する場合は、修正を繰り返します。明示的な確認を得てから、次に進みます。

---

ステップ 5 — フィードバックを送信する

次の引数を指定して save_ai_conversation_feedback を呼び出します。

引数	値
headline	簡潔な要約（最大80文字）。カテゴリーを先頭に付けます：[Bug]、[Feature]、[Improvement]、[New Skill]、[MCP Issue]、[Praise]、[Feedback]
description	ステップ 4 で作成した、構成の整った説明全文
conversation	対象範囲を絞り、機密情報を伏せた会話の抜粋（以下の形式を参照）
tags	配列。"plugin-feedback"を必ず含め、カテゴリータグ（"bug"、"feature"、"improvement"、"new-skill"、"mcp-issue"、"praise"、"general"）と、該当する場合はスキル名も含めます
agent_name	git config から取得（ステップ 1）
agent_email	git config から取得（ステップ 1）

会話の形式 — セッションの履歴全体ではなく、コンテキストウィンドウ内の直近30回のやり取り（ユーザーとアシスタントのペア）のみを含めます。各メッセージを含める前に、機密情報を伏せる処理を行います。

• Bearer [A-Za-z0-9._\-]{20,} に一致する文字列を Bearer [REDACTED] に置き換えます
• 単独の64文字の16進文字列を [REDACTED_HEX] に置き換えます
• /Users/<name>/ または /home/<name>/ に一致するファイルパスを /Users/[REDACTED]/ に置き換えます
• BIP-39 のニーモニックフレーズと思われるもの（辞書にある12〜24語）を削除します

形式：

USER: <text, redacted>

ASSISTANT: <text, redacted>

TOOL_CALL: <tool_name>(arg1=value1, arg2=value2)
TOOL_RESULT: <one-line summary of the result>

... continue for the last 30 exchanges only ...

---

ステップ 6 — 結果を報告する

成功した場合： ユーザーに次のように伝えます。

フィードバックを送信しました。ありがとうございます！チームが確認します。

フィードバックがバグまたはブロッカーに関するものの場合は、次の文も追加します。

緊急の場合は、チームにも直接ご連絡ください。

失敗した場合： MCP ツールのエラーを提示し、次のことを提案します。

• TRES API トークンが有効か確認する
• 再試行する。一時的な問題の可能性があります

---

エラー処理

状況	対応
get_viewer が失敗した	送信者を「不明な組織」として続行する
save_ai_conversation_feedback が失敗した	エラーを提示し、TRES API トークンの確認を提案する
ユーザーがプレビュー画面でキャンセルした	「問題ありません。フィードバックは送信されませんでした」と伝えて終了する
ユーザーが空の説明を入力した	説明が必要であることを伝え、再入力を求める
git config を利用できない	エージェント名にはシステムのユーザー名を使用し、エージェントのメールアドレスは空欄にする