Design and review recoverable Go CLI errors, exit semantics, structured logging, debug modes, traces, profiles, redaction, and user-consented diagnostic bundles.
SkillScore91Maintained
Automatic
◆Coding pack
Last verified 8/16/2026
What it changes
Passed 20 of 22 test cases with the skill, and 17 of 22 without it.
Without skill77%
With skill91%
Checks it passed that the model alone missed
The response specifies an explicit allowlist for diagnostic fields and metadata.
The response mandates explicit opt-in user consent before diagnostic collection or telemetry uploads occur.
The response specifies testing recovery guidance, stdout/stderr output separation, redaction, and cancellation behavior.
and 1 more in the full report
3 fixed17 passed either way2 still failing0 broke
Pass-rate lift
+14 pp
Tokens
+4%
Agent turns
0%
Response time
-17%
Model gemini-3.6-flashMeasured 8/16/2026v120 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
I am building a Go command-line tool that interfaces with remote network services and local config files. Can you help me establish a clean error handling strategy and CLI diagnostics system for it? Please provide a structured design document covering failure classification, boundary handling, logging versus output separation, and safe diagnostic collection.
What was checked, without and with the skill
Checked
Without skill
With skill
The response mandates explicit opt-in user consent before diagnostic collection or telemetry uploads occur.
Missed
Passed
The response specifies an explicit allowlist for diagnostic fields and metadata.
Missed
Passed
The response assigns error formatting, logging, and exit mapping to a single terminal boundary owner.
Passed
Passed
case-01 · gemini-3.6-flash · 8/16/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md52 linessingle file
Go CLI Errors and Observability
Design failures for recovery first, then add the minimum safe evidence needed to
diagnose them. Keep internal detail out of the normal user contract.
Core Workflow
Classify failures by user action, dependency, cancellation, and internal defect.
Preserve machine-checkable causes with wrapping, types, or sentinels.
Map causes to concise user messages and stable exit behavior at the boundary.
Assign one terminal owner to render, log, and map each failure.
Preserve material cleanup failures without hiding the primary cause.
Add opt-in verbosity and structured logs on stderr or a dedicated sink.
Allowlist and redact diagnostic evidence; require consent before collection or upload.
Test recovery guidance, output separation, redaction, and cancellation.
Never log secrets, authorization headers, raw config, or unreviewed environment data.
Do not make normal stdout depend on log level.
Preserve cancellation and timeout identity with errors.Is.
Do not both log and return the same failure at intermediate layers.
Do not use panic for ordinary validation, dependency, or user errors.
Do not collect or upload diagnostics without a visible allowlist and consent.
Protect profiling or debug servers; default them off and bind locally.
Source Notes
Guidance is transformed and paraphrased from Marian Montagnino,
Building Modern CLI Applications in Go (Packt, 2023), especially Chapter 9,
and Ricardo Gerardi, Powerful Command-Line Applications in Go (2021).