/report-bug

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 report fills in ButterCut's version and edition and the machine's OS version, processor type, and Ruby version on its own — nothing to pass for those, and nothing else about the machine goes.

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.