What a GitHub Issue Should Contain After a CLI Failure

A GitHub issue form is the right shape and the wrong moment. By the time someone opens the template they have closed the terminal, lost the scrollback, and half-remember the flag. The fields are empty because the evidence expired.

Fill the template from the process that just failed. Command, error code, exit status, SDK or CLI version, runtime, and a redacted stack. Leave intent as the only thing a human must type.

Title: the stable error code plus the command name. Body: what they were trying to do, the exact argv with secrets stripped, the exit status, and the environment only as far as OS, arch, and version. Link duplicate issues if you already have the code open.

Skip screenshots of the whole desktop, skip .env files, and skip 'steps to reproduce' as a blank essay. If your CLI can replay the command, the steps are the command.

Auto-opening issues from every laptops' crash creates noise and, worse, can leak a token that redaction missed. A draft lets someone on your team read the payload, then hit send.

AethelLayer drafts the GitHub issue from the probe. Export stays a human action. That is the difference between a support inbox and a robot posting secrets into a public repo.

When five drafts share a title, stop treating them as tickets and treat them as a doc. Change the sample, then comment on the draft with the command that works. Developers who are still evaluating will hit the new path.

An issue template nobody completes is not a community program. It is a wish.