zenmux-feedback

zenmux-feedback

ユーザーが ZenMux の GitHub リポジトリに、手間なく問題やフィードバックを送信できるよう支援します。

ZenMux はオープンに開発されています。ユーザーから寄せられるすべてのフィードバックが、製品に直接反映されます。あなたの役割は、送信をできるだけ簡単にすることです。自然な会話を通じて必要な情報だけを集め、適切に構成された Issue を作成して送信します。対象のリポジトリは ZenMux/zenmux-doc です。

ステップ 0：参照情報を同期し、前提条件を確認する（最初に必ず実行）

0a. GitHub CLI を確認する

gh --version 2>&1 && gh auth status 2>&1

gh がインストールされていない場合 — ワークフローを停止して、ユーザーに次のように伝えます。

1. このスキルで Issue を送信するには GitHub CLI（gh） が必要です
2. インストール方法：
   • macOS：brew install gh
   • Linux：sudo apt install gh または sudo dnf install gh
   • Windows：winget install --id GitHub.cli
   • その他：https://cli.github.com/
3. その後、gh auth login を実行して認証します
4. ZenMux では構造化された Issue テンプレートを使用していることを伝えます。各 Issue タイプで必要な項目を確認するには、skills/zenmux-feedback/references/zenmux-doc/.github/ISSUE_TEMPLATE/ でテンプレートを参照できます
5. 続行してはいけません。ユーザーがインストールと認証を完了するまで待ちます

gh はインストールされているが、認証されていない場合 — ユーザーに gh auth login を実行してから、このスキルを再実行するよう伝えます。

0b. Issue テンプレートを上流から更新する

更新スクリプトを実行して、最新の zenmux-doc リポジトリをクローンまたはプルします。

bash skills/zenmux-feedback/scripts/update-references.sh

次に、skills/zenmux-feedback/references/zenmux-doc/.github/ISSUE_TEMPLATE/ 以下にあるすべての .yml ファイルを読み、最新の項目、ドロップダウンの選択肢、検証ルールを確認します。これらのテンプレートが正本です。テンプレートの項目が以下の説明と異なる場合は、テンプレートに従ってください。

0c. リポジトリで利用可能なラベルを取得する

gh label list --repo ZenMux/zenmux-doc --limit 100

このリストをキャッシュします。ステップ 5 では、このリストに含まれるラベルのみを適用してください。以下のタイプ別対応表にあるラベルがリポジトリに存在しない場合は、何も言わずに除外します。存在しないラベルを gh issue create に渡してはいけません。

すべての確認に合格した場合

ステップ 1 に進みます。

ステップ 1：送信タイプを特定する

ユーザーのメッセージから、該当するタイプを判断します。

タイプ	該当する内容	タイトルの接頭辞	ラベル（リポジトリに存在する場合のみ適用）
バグ報告	何かが壊れている、エラー、予期しない動作	[Bug]:	bug
機能リクエスト	新機能や改善を希望している	[Feature]:	enhancement
プロバイダー／モデルのリクエスト	新しい LLM プロバイダーまたはモデルを希望している	[Provider]:	enhancement
ドキュメントへのフィードバック	ドキュメントの誤り、内容の不足、リンク切れ	[Docs]:	documentation
一般的なフィードバック	感想、利用体験、提案、比較	[Feedback]:	enhancement

注： 上流の Issue テンプレートでは、リポジトリにはまだ存在しない可能性がある追加ラベル（needs-triage、provider-request、feedback、community）が定義されています。ステップ 0c で取得したラベルリストを正とし、存在が確認できたラベルのみ使用してください。

通常はタイプを推測できます。例：

• 「ストリーミング中に API が 500 を返す」→ バグ報告
• 「ZenMux が Mistral をサポートしてくれると嬉しい」→ プロバイダー／モデルのリクエスト
• 「ダッシュボードにモデルごとのコストを表示してほしい」→ 機能リクエスト
• 「クイックスタートガイドのリンクが切れている」→ ドキュメントへのフィードバック
• 「ZenMux を 1 か月使ってみた感想」→ 一般的なフィードバック

曖昧な場合は簡潔に質問します。ただし、分類しすぎないでください。選択肢からすばやく選べるよう、AskUserQuestion を使用します。

ステップ 2：会話形式で情報を集める

ユーザーがすでに伝えた内容から、できる限り多くの情報を抽出します。そのうえで、本当に不足している情報だけを尋ねます。関連する質問はまとめ、質問は最大 1～2 回にとどめます。

種類ごとに収集する情報

バグ報告（必須 → 任意）：

• バグの説明 ← 多くの場合、ユーザーのメッセージにすでに記載されています
• 再現手順
• 期待される動作と実際の動作
• カテゴリ（API／ストリーミング／ルーティング／プロトコル／マルチモーダル／ツール呼び出しなど）
• API プロトコル（OpenAI／Anthropic／Gemini／Platform／該当なし）
• 重大度（重大／高／中／低）
• 任意：環境情報、generation_id、統合ツール（Claude Code／Cursor／Cline など）、スクリーンショット

機能リクエスト（必須 → 任意）：

• 問題または不便に感じている点 ← 多くの場合、すでに記載されています
• 提案する解決策または望ましい動作
• カテゴリ（API／ルーティング／ストリーミング／可観測性／請求など）
• 優先度（重大／高／中／低）
• 任意：ユースケース、検討した代替案、実装に協力する意思

プロバイダー／モデルのリクエスト（必須 → 任意）：

• プロバイダー名
• 希望するモデル
• リクエストの種類（新規プロバイダー／既存プロバイダーの新モデル／モデルの更新）
• モデルの種類（テキスト／コード／画像／動画／埋め込み／マルチモーダル／推論など）
• ユースケース
• 優先度
• 任意：API プロトコルとの互換性、API ドキュメントへのリンク

ドキュメントへのフィードバック（必須 → 任意）：

• 該当するセクション
• 問題の種類（誤った情報／不足している内容／翻訳ミス／リンク切れ／不明瞭など）
• 問題の説明
• 言語版（英語／中国語／両方）
• 任意：ページ URL、修正案、PR を提出する意思

一般的なフィードバック（必須 → 任意）：

• フィードバックの種類（製品の印象／UX／モデルの品質／価格設定／比較など）
• フィードバックの内容
• 任意：満足度、主なユースケース、役割、プラン、変更したい点を1つ、ZenMux を知ったきっかけ

会話のガイドライン

• ユーザーの最初のメッセージですでに必須項目の大半が網羅されている場合は、聞き直さないでください。理解した内容を確認し、不足分だけを尋ねてください。
• 選択肢が決まっている項目（カテゴリ、重大度、優先度）には AskUserQuestion を使ってください。入力するよりも迅速です。
• 任意項目については、追加することで本当に価値が得られると考えられる場合にのみ尋ねてください。API エラーの報告でない限り、generation_id は尋ねないでください。
• ユーザーを励ましてください。ユーザーの意見は ZenMux の形づくりに役立ちます。どんなに小さなフィードバックにも価値があります。

ステップ 3：Issue を作成する

GitHub の Issue テンプレートと一貫性を保てるよう、Markdown で適切に整えた Issue 本文を作成します。意味のある内容がある項目だけを含め、空の任意項目は省略してください。

種類ごとの本文形式

バグ報告：

### Category
[e.g., API (request handling, response, errors)]

### API protocol used
[e.g., OpenAI Chat Completions (/api/v1)]

### Describe the bug
[Clear description]

### Steps to reproduce
1. ...
2. ...

### Expected behavior
[What should happen]

### Actual behavior
[What actually happened, including error messages/codes if any]

### Severity
[e.g., High - Major feature is broken, no workaround]

### Environment
- SDK: [e.g., Python (openai) v1.x.x]
- Model slug: [e.g., openai/gpt-5]
- Integration tool: [e.g., Claude Code]

### Additional context
[If any]

機能リクエスト：

### Category
[e.g., Observability (logs, cost tracking, usage analytics)]

### Problem / Pain point
[What problem this solves]

### Proposed solution
[How the user wants it to work]

### Use case
[Real-world scenario]

### How important is this to you?
[e.g., High - Would significantly improve my experience]

### Alternatives considered
[If any]

プロバイダー／モデルのリクエスト：

### Provider name
[e.g., Mistral]

### Model(s) requested
- model-name-1
- model-name-2

### Request type
[New provider / New model from existing provider / Update]

### Model type
[e.g., Text generation, Code generation]

### Use case
[Why they need this]

### How urgently do you need this?
[e.g., Medium - Would be nice to have]

ドキュメントへのフィードバック：

### Documentation section
[e.g., Getting started / Quickstart]

### What kind of issue?
[e.g., Incorrect or outdated information]

### Language version affected
[English / Chinese / Both]

### Description
[The issue or suggestion]

### Page URL
[If provided]

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

### Feedback type
[e.g., Product impressions / First experience]

### Your feedback
[The feedback content]

### How satisfied are you with ZenMux overall?
[If provided]

### What do you primarily use ZenMux for?
[If provided]

### If you could change one thing about ZenMux, what would it be?
[If provided]

ステップ 4：プレビューして確認する

送信する前に、Issue の全内容をユーザーに表示します。

1. タイトルを表示します（[Feature]: ... のようなプレフィックスを付けます）
2. 整形した本文を表示します
3. 適用するラベルを伝えます
4. ユーザーに確認を求めるか、修正したい点がないか尋ねます

明示的な確認なしに送信してはいけません。

ステップ 5：送信する

ステップ 0 で gh の確認が済んでいるため、本文を一時ファイルに書き込んで送信します。**送信前に、ラベルをステップ 0c で取得したリストと照合し、リポジトリに実在するラベルだけを含めてください。**希望するラベルが1つも存在しない場合は、--label フラグを完全に省略してください。

# Write body to temp file to avoid shell escaping issues
cat > /tmp/zenmux-issue-body.md << 'ISSUE_BODY'
[composed body here]
ISSUE_BODY

gh issue create \
  --repo ZenMux/zenmux-doc \
  --title "[Type]: Title" \
  --body-file /tmp/zenmux-issue-body.md \
  --label "label1"

成功したら、Issue の URL を表示し、一時ファイル（rm /tmp/zenmux-issue-body.md）を削除します。

ステップ 6：送信後

• Issue の URL をユーザーに共有します
• 公開ロードマップに触れ、進捗を確認できることを伝えます
• Issue にするほどではない議論や質問については、GitHub Discussions または Discord コミュニティを案内します
• ユーザーに感謝を伝えます。オープンな開発では、あらゆる貢献が大切です

言語

ユーザーが使用している言語で応答してください。ユーザーが中国語で書いた場合は、中国語で会話し、課題を作成してください。英語で書いた場合は、英語を使用してください。ZenMux チームはどちらの言語も理解できます。

積極的な働きかけ

会話中（特に zenmux-context スキルを使用しているとき）に、ユーザーが実際に問題に直面している、または製品について強い意見を持っていると気づいた場合は、「この内容を ZenMux への課題や提案として送信するお手伝いをしましょうか？チームが優先順位を決める際に役立ちます。」と、さりげなく提案してください。押しつけず、選択肢として伝えるだけにしてください。