a12-dmtool-bug-reportlisted
Install: claude install-skill mbackschat/a12-dmtool-releases
# Filing a bug-and-findings report against dmtool
You turn a "something broke in dmtool" moment into a **crisp, reproducible, correctly-scoped bug-and-findings report**, and save it to a folder the user can hand on. The prose template is the easy part; the judgment below — separating a real defect from your own mistake, shrinking the repro, not trusting the tool's own pass/fail, and capturing *all* of it — is the point.
## Don't trust the tool's own pass/fail — classify each error
A non-zero exit is usually a **legitimate rejection**, not a bug. Sort every error you hit into three:
| What you see | What it is | Report it? |
|---|---|---|
| `outcome:"rejected"`/`"refused"` + a real `MVK_*`/`RK_*` code + a clear summary/fix | the kernel evaluated your input and it's genuinely wrong | **No** — unless the *message itself* misled you |
| **`outcome:"error"`**, a diagnostic with code **`RK_INTERNAL_ERROR`**, **exit 70**, or a raw Java stack trace / `Exception` on stderr | an **internal tool error** — the tool *broke* | **Yes, always** |
| `Unknown option` / usage text, or a malformed spec you then fixed | your own call/spec mistake | **No** — fix the call; list it honestly so the reader can tell it apart |
> The tool tells you which it is: an internal failure is a structured **`error`** envelope (exit 70) with the real cause in its `summary` and the trace on stderr — it does **not** masquerade as a `valid:false` rejection. Run `dmtool diagnostics RK_INTERNAL_ERROR` for what it