Back to Details

zenmux-feedback

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

zenmux-feedback

zenmux-feedback

Help users submit issues and feedback to the ZenMux GitHub repository with minimal friction.
ZenMux is built in public — every piece of user feedback directly shapes the product. Your job is to make submission feel effortless: gather just enough info through natural conversation, compose a well-structured issue, and submit it. The target repository is ZenMux/zenmux-doc.
帮助用户轻松向ZenMux的GitHub代码仓库提交issue和反馈。
ZenMux采用公开构建模式——每一条用户反馈都会直接影响产品的发展。你的任务是让提交过程尽可能顺畅：通过自然对话收集必要信息，撰写结构清晰的issue并完成提交。目标仓库为ZenMux/zenmux-doc。

Step 0: Sync references & check prerequisites (MUST run first)

步骤0：同步参考内容并检查前置条件（必须首先执行）

0a. Verify GitHub CLI

0a. 验证GitHub CLI

bash
gh --version 2>&1 && gh auth status 2>&1
If 
gh
is not installed — stop the workflow and tell the user:
  1. This skill requires GitHub CLI (
    gh
    )     to submit issues
  2. Install it:
    • macOS: 
      brew install gh
    • Linux: 
      sudo apt install gh
      or 
      sudo dnf install gh
    • Windows: 
      winget install --id GitHub.cli
    • Other: https://cli.github.com/
  3. Then run 
    gh auth login
    to authenticate
  4. Mention that ZenMux uses structured issue templates — the user can browse them at 
    skills/zenmux-feedback/references/zenmux-doc/.github/ISSUE_TEMPLATE/
    to preview the fields each issue type requires
  5. Do NOT proceed — wait for the user to install and authenticate first
If 
gh
is installed but not authenticated — tell the user to run 
gh auth login
, then re-run this skill.
bash
gh --version 2>&1 && gh auth status 2>&1
若未安装
gh
——终止流程并告知用户：
  1. 此技能需要**GitHub CLI (
    gh
    )**来提交issue
  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模板——可前往
    skills/zenmux-feedback/references/zenmux-doc/.github/ISSUE_TEMPLATE/
    浏览模板，预览每种issue类型所需填写的字段
  5. 请勿继续流程——等待用户完成安装和身份验证后再进行
若已安装
gh
但未完成身份验证——告知用户运行
gh auth login
，之后重新执行此技能。

0b. Update issue templates from upstream

0b. 从上游更新issue模板

Run the update script to clone or pull the latest zenmux-doc repository:
bash
bash skills/zenmux-feedback/scripts/update-references.sh
Then read all 
.yml
files under 
skills/zenmux-feedback/references/zenmux-doc/.github/ISSUE_TEMPLATE/
to get the latest fields, dropdown options, and validation rules. These templates are the source of truth — if template fields have changed from what's described below, follow the templates.
运行更新脚本以克隆或拉取最新的zenmux-doc仓库：
bash
bash skills/zenmux-feedback/scripts/update-references.sh
随后读取
skills/zenmux-feedback/references/zenmux-doc/.github/ISSUE_TEMPLATE/
下的所有
.yml
文件，获取最新的字段、下拉选项及验证规则。这些模板是唯一权威依据——若模板字段与下文描述不符，请以模板为准。

0c. Fetch available repo labels

0c. 获取仓库可用标签

bash
gh label list --repo ZenMux/zenmux-doc --limit 100
Cache this list. In Step 5, only apply labels that appear in this list. If a label from the type mapping below doesn't exist in the repo, silently drop it — never pass non-existent labels to 
gh issue create
.
bash
gh label list --repo ZenMux/zenmux-doc --limit 100
缓存此标签列表。在步骤5中，仅使用列表中存在的标签。若下文类型映射中的标签在仓库中不存在，请自动忽略——切勿将不存在的标签传入
gh issue create
命令。

If all checks pass

若所有检查通过

Proceed to Step 1.
继续执行步骤1。

Step 1: Identify submission type

步骤1：确定提交类型

From the user's message, determine which type fits:
TypeSignalsTitle prefixLabels (apply only if they exist in repo)
Bug ReportSomething broken, errors, unexpected behavior
[Bug]: 
bug
Feature RequestWants new functionality or improvements
[Feature]: 
enhancement
Provider/Model RequestWants a new LLM provider or model
[Provider]: 
enhancement
Doc FeedbackDoc errors, missing content, broken links
[Docs]: 
documentation
General FeedbackImpressions, experience, suggestions, comparisons
[Feedback]: 
enhancement
Note: The upstream issue templates define additional labels (
needs-triage
, 
provider-request
, 
feedback
, 
community
) that may not yet exist in the repo. The label list fetched in Step 0c is authoritative — only use labels confirmed to exist.
Usually you can infer the type. Examples:
  • "API returns 500 when streaming" → Bug Report
  • "Hope ZenMux can support Mistral" → Provider/Model Request
  • "Wish the dashboard showed per-model cost" → Feature Request
  • "The quickstart guide link is broken" → Doc Feedback
  • "Been using ZenMux a month, here's what I think" → General Feedback
If ambiguous, ask briefly — but don't over-classify. Use AskUserQuestion with the options above for quick selection.
根据用户的消息，判断对应的提交类型：
类型识别信号标题前缀标签（仅使用仓库中存在的标签）
Bug报告功能异常、报错、非预期行为
[Bug]: 
bug
功能请求希望新增功能或改进现有功能
[Feature]: 
enhancement
供应商/模型请求希望支持新的大语言模型供应商或模型
[Provider]: 
enhancement
文档反馈文档错误、内容缺失、链接失效
[Docs]: 
documentation
通用反馈使用印象、体验、建议、竞品对比
[Feedback]: 
enhancement
注意：上游issue模板定义了一些额外标签（如
needs-triage
、
provider-request
、
feedback
、
community
），这些标签可能尚未在仓库中创建。步骤0c获取的标签列表是权威依据——仅使用已确认存在的标签。
通常可直接推断类型，例如：
  • "流式传输时API返回500错误" → Bug报告
  • "希望ZenMux支持Mistral模型" → 供应商/模型请求
  • "希望仪表盘显示各模型的使用成本" → 功能请求
  • "快速入门指南的链接失效了" → 文档反馈
  • "使用ZenMux一个月了，想说说我的感受" → 通用反馈
若类型不明确，可简短询问——但无需过度分类。使用选项式提问让用户快速选择。

Step 2: Gather information conversationally

步骤2：通过对话收集信息

Extract as much as you can from what the user already said. Then ask only for what's truly missing — group related questions together and keep it to 1-2 rounds of questions at most.
先从用户已发送的消息中提取尽可能多的信息，仅询问确实缺失的内容——将相关问题分组，最多进行1-2轮提问。

What to gather per type

各类型需收集的信息

Bug Report (essential → optional):
  • Description of the bug ← often already in the user's message
  • Steps to reproduce
  • Expected vs actual behavior
  • Category (API / Streaming / Routing / Protocol / Multimodal / Tool calling / etc.)
  • API protocol (OpenAI / Anthropic / Gemini / Platform / N/A)
  • Severity (Critical / High / Medium / Low)
  • Optional: environment info, generation_id, integration tool (Claude Code / Cursor / Cline / etc.), screenshots
Feature Request (essential → optional):
  • Problem or pain point ← often already stated
  • Proposed solution or desired behavior
  • Category (API / Routing / Streaming / Observability / Billing / etc.)
  • Priority (Critical / High / Medium / Low)
  • Optional: use case, alternatives considered, willingness to help implement
Provider/Model Request (essential → optional):
  • Provider name
  • Model(s) requested
  • Request type (new provider / new model from existing provider / model update)
  • Model type (text / code / image / video / embedding / multimodal / reasoning / etc.)
  • Use case
  • Priority
  • Optional: API protocol compatibility, API docs link
Doc Feedback (essential → optional):
  • Which section is affected
  • What kind of issue (incorrect info / missing content / translation error / broken link / unclear / etc.)
  • Description of the problem
  • Language version (English / Chinese / Both)
  • Optional: page URL, suggested fix, willingness to submit PR
General Feedback (essential → optional):
  • Feedback type (product impressions / UX / model quality / pricing / comparison / etc.)
  • The feedback content itself
  • Optional: satisfaction level, primary use case, role, plan, one thing they'd change, how they found ZenMux
Bug报告（必填→可选）：
  • Bug描述 ← 通常已包含在用户消息中
  • 复现步骤
  • 预期行为 vs 实际行为
  • 分类（API / 流式传输 / 路由 / 协议 / 多模态 / 工具调用 / 等）
  • API协议（OpenAI / Anthropic / Gemini / Platform / 无）
  • 严重程度（Critical / High / Medium / Low）
  • 可选：环境信息、generation_id、集成工具（Claude Code / Cursor / Cline / 等）、截图
功能请求（必填→可选）：
  • 问题或痛点 ← 通常已包含在用户消息中
  • 提议的解决方案或期望行为
  • 分类（API / 路由 / 流式传输 / 可观测性 / 计费 / 等）
  • 优先级（Critical / High / Medium / Low）
  • 可选：使用场景、已考虑的替代方案、是否愿意协助实现
供应商/模型请求（必填→可选）：
  • 供应商名称
  • 请求的模型
  • 请求类型（新增供应商 / 现有供应商新增模型 / 模型更新）
  • 模型类型（文本 / 代码 / 图像 / 视频 / 嵌入 / 多模态 / 推理 / 等）
  • 使用场景
  • 优先级
  • 可选：API协议兼容性、API文档链接
文档反馈（必填→可选）：
  • 受影响的文档章节
  • 问题类型（信息错误 / 内容缺失 / 翻译错误 / 链接失效 / 表述模糊 / 等）
  • 问题描述
  • 语言版本（英文 / 中文 / 两者）
  • 可选：页面URL、建议修复方案、是否愿意提交PR
通用反馈（必填→可选）：
  • 反馈类型（产品印象 / 用户体验 / 模型质量 / 定价 / 竞品对比 / 等）
  • 反馈内容
  • 可选：满意度评分、主要使用场景、用户角色、使用计划、最想改进的一点、了解ZenMux的渠道

Conversation guidelines

对话准则

  • If the user's initial message already covers most required fields, don't re-ask. Confirm your understanding and only fill gaps.
  • Use AskUserQuestion for fields with fixed options (category, severity, priority) — it's faster than typing.
  • For optional fields, only ask when context suggests they'd add real value. Don't ask about 
    generation_id
    unless they're reporting an API error.
  • Encourage the user — their input shapes ZenMux. No feedback is too small.
  • 若用户初始消息已涵盖大部分必填字段，无需重复询问。确认你的理解并仅补充缺失内容。
  • 对于有固定选项的字段（分类、严重程度、优先级），使用选项式提问——比输入更快捷。
  • 可选字段仅在上下文表明其能提供实际价值时才询问。除非用户报告API错误，否则无需询问
    generation_id
    。
  • 鼓励用户——他们的输入会塑造ZenMux的发展。任何反馈都有价值。

Step 3: Compose the issue

步骤3：撰写issue

Build a well-formatted issue body in markdown. Structure it to match what GitHub issue templates produce for consistency. Only include fields that have meaningful content — skip empty optional sections.
使用markdown格式撰写结构清晰的issue正文。为保持一致性，结构需与GitHub issue模板生成的内容匹配。仅包含有实际内容的字段——跳过空的可选部分。

Body format by type

各类型正文格式

Bug Report:
markdown
undefined
Bug报告：
markdown
undefined

Category

分类

[e.g., API (request handling, response, errors)]
[e.g., API（请求处理、响应、错误）]

API protocol used

使用的API协议

[e.g., OpenAI Chat Completions (/api/v1)]
[e.g., OpenAI Chat Completions (/api/v1)]

Describe the bug

Bug描述

[Clear description]
[清晰的描述]

Steps to reproduce

复现步骤

  1. ...
  2. ...
  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]
[e.g., High - 核心功能失效，无替代方案]

Environment

环境信息

  • SDK: [e.g., Python (openai) v1.x.x]
  • Model slug: [e.g., openai/gpt-5]
  • Integration tool: [e.g., Claude Code]
  • SDK: [e.g., Python (openai) v1.x.x]
  • Model slug: [e.g., openai/gpt-5]
  • 集成工具: [e.g., Claude Code]

Additional context

额外上下文

[If any]

**Feature Request:**
```markdown
[如有]

**功能请求：**
```markdown

Category

分类

[e.g., Observability (logs, cost tracking, usage analytics)]
[e.g., 可观测性（日志、成本追踪、使用分析）]

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]
[e.g., High - 将显著提升使用体验]

Alternatives considered

已考虑的替代方案

[If any]

**Provider/Model Request:**
```markdown
[如有]

**供应商/模型请求：**
```markdown

Provider name

供应商名称

[e.g., Mistral]
[e.g., Mistral]

Model(s) requested

请求的模型

  • model-name-1
  • model-name-2
  • model-name-1
  • model-name-2

Request type

请求类型

[New provider / New model from existing provider / Update]
[新增供应商 / 现有供应商新增模型 / 更新模型]

Model type

模型类型

[e.g., Text generation, Code generation]
[e.g., 文本生成、代码生成]

Use case

使用场景

[Why they need this]
[需求原因]

How urgently do you need this?

需求紧急程度？

[e.g., Medium - Would be nice to have]

**Doc Feedback:**
```markdown
[e.g., Medium - 有则更好]

**文档反馈：**
```markdown

Documentation section

文档章节

[e.g., Getting started / Quickstart]
[e.g., 入门指南 / 快速开始]

What kind of issue?

问题类型

[e.g., Incorrect or outdated information]
[e.g., 信息错误或过时]

Language version affected

受影响的语言版本

[English / Chinese / Both]
[英文 / 中文 / 两者]

Description

描述

[The issue or suggestion]
[问题或建议]

Page URL

页面URL

[If provided]

**General Feedback:**
```markdown
[如有提供]

**通用反馈：**
```markdown

Feedback type

反馈类型

[e.g., Product impressions / First experience]
[e.g., 产品印象 / 首次使用体验]

Your feedback

您的反馈

[The feedback content]
[反馈内容]

How satisfied are you with ZenMux overall?

您对ZenMux的整体满意度如何？

[If provided]
[如有提供]

What do you primarily use ZenMux for?

您主要使用ZenMux做什么？

[If provided]
[如有提供]

If you could change one thing about ZenMux, what would it be?

如果您能改变ZenMux的一个地方，会是什么？

[If provided]
undefined
[如有提供]
undefined

Step 4: Preview and confirm

步骤4：预览并确认

Show the user the complete issue before submitting:
  1. Display the title (with prefix like 
    [Feature]: ...
    )
  2. Display the body formatted clearly
  3. Mention which labels will be applied
  4. Ask the user to confirm, or adjust anything
Never submit without explicit confirmation.
提交前向用户展示完整的issue内容：
  1. 展示标题（包含
    [Feature]: ...
    这类前缀）
  2. 清晰展示格式化后的正文
  3. 说明将添加的标签
  4. 请用户确认或调整内容
未经用户明确确认，切勿提交。

Step 5: Submit

步骤5：提交

Since 
gh
was verified in Step 0, write the body to a temp file and submit. Before submitting, cross-check labels against the list fetched in Step 0c — only include labels that actually exist in the repo. If none of the desired labels exist, omit the 
--label
flag entirely.
bash
undefined
由于步骤0已验证
gh
可用，将正文写入临时文件后提交。提交前，请对照步骤0c获取的标签列表——仅包含仓库中实际存在的标签。若所需标签均不存在，则完全省略
--label
参数。
bash
undefined

Write body to temp file to avoid shell escaping issues

将正文写入临时文件以避免shell转义问题

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"

After success, show the issue URL and clean up the temp file (`rm /tmp/zenmux-issue-body.md`).
cat > /tmp/zenmux-issue-body.md << 'ISSUE_BODY' [撰写好的正文内容] ISSUE_BODY
gh issue create
--repo ZenMux/zenmux-doc
--title "[Type]: Title"
--body-file /tmp/zenmux-issue-body.md
--label "label1"

提交成功后，向用户展示issue链接并清理临时文件（`rm /tmp/zenmux-issue-body.md`）。

Step 6: After submission

步骤6：提交后

  • Share the issue URL with the user
  • Mention the public roadmap — they can track progress there
  • For discussions or questions that aren't quite issues, suggest GitHub Discussions or the Discord community
  • Thank them — every contribution matters when building in public
  • 向用户分享issue链接
  • 提及公开路线图——用户可在此追踪进度
  • 对于不适合作为issue的讨论或问题，建议使用GitHub Discussions或Discord社区
  • 感谢用户——公开构建模式下，每一份贡献都至关重要

Language

语言

Respond in whatever language the user is using. If they write in Chinese, conduct the conversation and compose the issue in Chinese. If in English, use English. The ZenMux team reads both.
使用用户所使用的语言进行响应。若用户使用中文，则全程用中文对话并撰写issue；若使用英文，则全程用英文。ZenMux团队可阅读两种语言。

Proactive engagement

主动触发

If during a conversation (especially when using the zenmux-context skill) you notice the user has hit a real problem or has a strong product opinion, gently offer: "Would you like me to help submit this as an issue/suggestion to ZenMux? It helps the team prioritize." Don't push — just make the option visible.
若在对话中（尤其是使用zenmux-context技能时）发现用户遇到实际问题或有明确的产品意见，可主动询问："是否需要我协助将此问题/建议提交为ZenMux的issue？这有助于团队优先处理。"无需强行推荐，仅提供选项即可。