report-bug
GitHub用于检测 ButterCut 自身故障并生成匿名 Bug 报告。自动过滤用户隐私数据,根据用户授权偏好决定是否发送错误详情至开发团队,确保仅上报技术故障而非业务内容。
Trigger Scenarios
Install
npx skills add barefootford/buttercut --skill report-bug -g -y
SKILL.md
Frontmatter
{
"name": "report-bug",
"description": "Report a ButterCut bug to the people who build it. Use automatically when a ButterCut command fails in a way that looks like ButterCut's own fault, and when the user says \"report this\", \"send a bug report\", \"tell the ButterCut team\", or \"this is broken\"."
}
Skill: Report a Bug
Something in ButterCut broke. Decide whether it's worth reporting, strip the user's work out of it, and send it to the ButterCut team.
The user's footage is theirs. A report contains no footage, no transcripts, no contact sheets, and no library or clip names — just what broke and where. Say it that way when you talk about it. Their email goes only if they've said it can.
Step 1 — Is this worth reporting?
Report when ButterCut itself broke on work that should have gone through: a crash, a stack trace, malformed XML, an export that produced nothing, a step that failed on footage the library says is ready.
Don't report: a command you called wrong, a file or library that isn't there, a missing dependency (that's the setup skill), or a message that's working as designed (like the daily update check). Try the obvious fix first — if your second attempt works, there's no bug. Don't report the same failure twice in a session.
Step 2 — What has the user agreed to?
ruby lib/buttercut/report.rb consent
Prints error_reporting=<always|ask|never|unset> email=<address or blank>.
never— stop. Don't send, don't mention it, don't re-ask.always— send (step 4).ask— build the report, runsendwith--dry-run, summarize it for the user in plain language (not the JSON — they're a video editor), and send only if they say yes.unset— ButterCut has never asked. Ask now withAskUserQuestion: "ButterCut just hit an error. Want me to send it to the team so they can fix it?" with three options — send automatically, ask me each time, never send — noting that reports never include footage, transcripts, or library/clip names. Unless they chose never, also ask whether to include their email so an engineer can follow up. Save both answers by editinglibraries/settings.yaml: seterror_reporting:anderror_report_email:(copy the commented block fromtemplates/settings_template.yamlif the keys aren't there yet). They can change either any time.
Step 3 — Take the user's work out of it
Everything you pass to report.rb is sent exactly as written. Before passing: /Users/anna/… becomes ~/…; library, clip, and roughcut names become <library>, <clip>.mov, <roughcut>.yaml; anything quoted from a transcript, summary, or script — and any names of people, companies, or clients — gets dropped entirely. Keep the error class, the shape of the message, which step failed, the ButterCut file.rb:line frames, and version numbers: those are the whole value of the report.
Step 4 — Send it
ruby lib/buttercut/report.rb send \
--kind bug \
--action export \
--class RuntimeError \
--message "no such file: ~/…/<library>/footage/<clip>.mov" \
--frame "lib/buttercut/export_core.rb:88" \
--narrative "Export of a 40-clip sequence failed partway through; the library reported every clip as ready."
--action(required) — the step, one word:export,transcribe,contact_sheet,process,cut,backup, orother.--class(required) — the exception class; without a real one useCommandFailed.--frame— the topmostlib/buttercut/…line in the trace, if there is one. Skip it rather than inventing one; it's part of how reports get grouped.--narrative— two sentences at most: what you were doing, what happened. Mention a workaround here if you found one.
The command prints sent bug report <uuid> or a one-line reason it didn't. Either way, that's the end of it. Never retry, never send twice, never let a failed report become its own topic.
Step 5 — Say one sentence and get back to work
"I've sent the error to the ButterCut team — no footage or transcripts, just the error itself. Let's see if we can get around it in the meantime."
Then go help them with the actual problem. Never show them JSON, a UUID, a status code, or a file path from this skill. If it didn't send, don't mention it unless they asked you to report it — then one sentence ("couldn't reach the team just now").
Developer mode. With .buttercut_mode present, report.rb send refuses — dev checkouts don't file reports against production. Use --dry-run to see what a real install would send.
Version History
- 5d62523 Current 2026-08-20 12:44


