report-bug

GitHub

用于检测 ButterCut 自身故障并生成匿名 Bug 报告。自动过滤用户隐私数据,根据用户授权偏好决定是否发送错误详情至开发团队,确保仅上报技术故障而非业务内容。

skills/report-bug/SKILL.md barefootford/buttercut

Trigger Scenarios

ButterCut 命令失败且疑似软件自身错误 用户明确要求 'report this'、'send a bug report'、'tell the ButterCut team' 或 'this is broken'

Install

npx skills add barefootford/buttercut --skill report-bug -g -y
More Options

Use without installing

npx skills use barefootford/buttercut@report-bug

指定 Agent (Claude Code)

npx skills add barefootford/buttercut --skill report-bug -a claude-code -g -y

安装 repo 全部 skill

npx skills add barefootford/buttercut --all -g -y

预览 repo 内 skill

npx skills add barefootford/buttercut --list

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, run send with --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 with AskUserQuestion: "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 editing libraries/settings.yaml: set error_reporting: and error_report_email: (copy the commented block from templates/settings_template.yaml if 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, or other.
  • --class (required) — the exception class; without a real one use CommandFailed.
  • --frame — the topmost lib/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

Same Skill Collection

skills/analyze-video/SKILL.md
skills/backup-library/SKILL.md
skills/buttercut/SKILL.md
skills/contact-sheet/SKILL.md
skills/create-library/SKILL.md
skills/cut/SKILL.md
skills/full-transcript/SKILL.md
skills/misc-task/SKILL.md
skills/process-library/SKILL.md
skills/reprocess-with-contact-sheets/SKILL.md
skills/request-feature/SKILL.md
skills/setup/SKILL.md
skills/transcribe-audio/SKILL.md
skills/update-buttercut/SKILL.md
skills/bc/SKILL.md

Metadata

Files
0
Version
5d62523
Hash
c0510e9c
Indexed
2026-08-20 12:44

Accueil - Wiki
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-09-07 05:22
浙ICP备14020137号-1 $Carte des visiteurs$