mcpField
D
dby-feedback

dby-feedback

github.com/zizhanovoTesting & quality1143 installsUpdated 4w ago
Repository

About dby-feedback

dby-feedback is a feedback-writing and submission skill for agents, turning issues observed in a session into reports. It requires the user to review the full report and explicitly consent before sending, with local storage and manual delivery as fallbacks.

Key features

  1. 01Classifies bug, friction, and idea reports
  2. 02Writes reports from session evidence
  3. 03Scans for credentials and high-entropy content
  4. 04Sends only after user consent
  5. 05Supports local storage and manual delivery

Use cases

  1. 01Record reproduction steps and error text
  2. 02Report friction in a workflow
  3. 03Suggest feature improvements
  4. 04Keep a report when the endpoint is unavailable

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/zizhanovo/doubaoya-community --skill dby-feedback

After installing, type/dby-feedbackin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

.version
evals/
triggers.jsonl
references/
maintainer-loop.md
report-protocol.md
scripts/
endpoint.json
submit_feedback.py

Details

From the project README

dby-feedback：现场写好反馈，用户过目后提交

用户遇到问题或想提改进建议时，你（agent）当场把经过写成完整反馈——你在现场， 复现步骤、原始错误文本、实际 vs 期望这三样你天然拿得到，而它们恰恰是用户最难提供的。

什么时候动

  • 用户自然抱怨（「怎么又失败了」「这里好烦」「这个不对吧」「能不能改改」）→ 提议记一笔反馈： 一句话，不打断他正在做的事，不要求用户先学任何命令。例：「这个问题我可以当场写成反馈提交给维护者，要吗？」
  • 提议可忽略：用户没回应就继续原任务；同一问题在同一会话内不再提第二次（同一错误再次出现也不提）。
  • 用户直接点名（「给作者提个反馈」「报个 bug」）→ 直接进流程，不需要先制造一次失败。
  • 🔴 绝不自动发送。发送永远发生在用户看过全文并明确同意之后。

流程

1. 分类并成文

先判定 bug（做了某事没得到该有的结果）/ friction（结果对了但过程别扭）/ idea （希望多做点什么）三类之一，然后读 references/report-protocol.md，按该类分支的提问自查成文 （三支问的不是同一套东西；报告骨架固定、节内自由写）。写完按协议做真实性拦截： 每个细节必须对应本次会话真实发生过的工具调用，对不上的删掉或标「未核实」；观察与推测分开； 正文只取三类素材（本次会话的动作 / 错误与返回 / 白名单机器事实），绝不引用用户正文与资料。

报告存成一个临时 markdown 文件（如 feedback-report.md）。

2. 拼载荷（机器事实由脚本按白名单采集）
python3 scripts/submit_feedback.py prepare --category bug \
  --report feedback-report.md --out feedback-payload.json \
  --agent claude-code --command "1:node reconcile.mjs --dry-run"

--command 是本次会话里执行过的本仓命令与退出码（格式「退出码:命令」，可多次）。 机器事实只采白名单：各包 .dby/origin.json 的 slug/version/hash/ref/installedAt、scope 根 lock、 Node 版本、操作系统、agent 类型、上述命令。白名单之外一律不采——绝不采集 DOUBAOYA_API_KEY 或任何凭证、appid、author、publicAccountName、targetAccount、ipProfile、 用户文章正文、号章程、创作 DNA。别自己动手读配置文件“补充环境信息”，采集只走脚本。

脚本会对全部待发送内容（含你写的正文）跑凭证与高熵检测：命中则不发，按它指出的位置 处理后重新 prepare。

3. 用户过目全文

把 prepare 打印的全文原样呈现给用户——这就是将要发出去的那份（与 --out 文件逐字节一致）， 不是摘要、不是改写。呈现后明确问一句「确认提交吗？」。

4. 只在明确同意后发送
  • 用户明确说发 → python3 scripts/submit_feedback.py send --payload feedback-payload.json --user-consented
  • 用户拒绝或没回应 → 不发。想留底就 keep --payload feedback-payload.json（只落本地，零请求）； 不想留就删掉载荷与报告文件。--user-consented 只在用户明确同意后才许传。
5. 交代结果
  • 成功：告诉用户已提交，并给出返回的 requestId（后续追问可引用）。响应里出现 notice 字段就原样转达。
  • 端点不通 / 未配置 / 返回失败：脚本会把反馈落成本地 markdown（退出码 2），把它打印的绝对路径与 手动送达方式原样告诉用户——反馈已写好，不会因为端点不通而丢。

安装标识（对用户怎么说）

随反馈发送一个本地随机生成的安装标识：不含用户的任何身份信息（不从机器名/用户名/邮箱/密钥派生）， 用户可随时 python3 scripts/submit_feedback.py reset-id 重置。用户问起时照这句说， 别用「匿名」二字——措辞红线见 references/maintainer-loop.md（维护者侧的消费路径也在那里）。

出岔子了怎么办

  • 本机没有 python3 → 报告 markdown 已经写好了，直接给用户留存，并告诉他手动送达方式 （GitHub 仓库 zizhanovo/doubaoya-community 开 issue 贴入内容）。
  • 端点长期不通 → 每次都会落本地文件，如实告诉用户目前只能手动送达，别反复重试刷失败。
  • 用户中途改主意 → 立刻停下；已生成的本地文件按用户意愿保留或删除。

Comments

Markdown supported